틀렸다는 말 너머를 묻는 수치 지능, ADSD를 읽다

Training Numerical Intelligence via Auto-Diagnosis and Skill Discovery는 arXiv 번호 2610.03872로 공개된 연구이다. 원문 링크는 제목 아래에 걸어두었다.

이 연구가 내세우는 주장은 하나의 문장으로 정리된다. 과학 계산용 solver가 왜 틀리는지를 먼저 진단하고, 그 진단에서 길어 올린 수치 기법을 재사용 가능한 skill로 쌓아 solver 스스로를 고치게 한다는 것이다. 이 글에서는 그 문제의식에서 출발해 실행 피드백의 빈틈과 진단 우선 접근, 재사용 가능한 skill의 구조, 그리고 네 가지 영역에서의 검증 결과를 차례로 따라간다.

왜 코드를 짜는 일과 식을 푸는 일은 다를까

제가 이 논문에서 가장 오래 머문 대목은 출발점의 문장이다. AI 에이전트는 과학 계산 코드를 점점 잘 짜지만, 코드를 짜는 일과 그 뒤의 알고리즘을 뜯어고치는 일은 서로 다른 층위에 있다는 것이다. 코드를 짠다는 것은 문법을 맞추고 실행되게 만드는 일에 가깝고, 식을 푼다는 것은 오차가 어디에서 자라고 어디에서 잦아드는지를 다루는 일이기 때문이다. 그렇다면 무엇이 사람을 붙잡을까. 실행은 되지만 답이 미묘하게 어긋나는 그 구간이 바로 붙잡는 지점이다.

생각해보면 사람도 비슷하게 배운다. 수학 문제를 풀 때 답만 틀렸다는 말을 듣는 것과, 어디에서 식이 어긋났는지를 짚어주는 말을 듣는 것은 전혀 다른 도움을 준다. 전자는 다시 풀라는 독촉에 가깝고, 후자는 다음에도 쓸 수 있는 요령을 남기기 때문이다. 수치 solver도 마찬가지다. 실행됐다는 사실만으로는 다음 시도를 어디로 옮겨야 할지 알기 어렵기 때문이다. 저는 이 간격을 논문이 정확히 짚었다고 봤다. 생성과 개선을 같은 능력으로 뭉뚱그리지 않고, 개선에는 별도의 장치가 필요하다고 말하는 대목이기 때문이다.

여기서는 조금 조심해서 읽을 필요가 있다. 코드 생성이 쓸모없다는 이야기가 아니기 때문이다. 생성은 여전히 solver 실험의 속도를 올려주죠. 그런데 속도가 빨라진다고 해서 방향까지 잡히는 것은 아니다. 방향을 잡는 일은 오차의 원인을 언어로 설명하는 데에서 시작되기 때문이다. 이 차이를 어떻게 메울까. 그 물음이 다음 장면으로 이어진다.

틀렸다는 말만으로는 어디까지 고칠 수 있을까

실행 피드백은 정직하지만 말이 없다. solver를 돌려보면 오차가 얼마인지, 수렴이 늦는지, 어느 사례에서 터지는지는 드러나지만, 왜 그런 일이 생기는지는 말해주지 않기 때문이다. 연구진이 짚은 지점도 여기다. 실행 결과만으로는 성능이 나쁘다는 사실은 드러나도 그 밑의 원인과 처방까지는 좀처럼 닿지 않는다는 것이다. 그래서 고치는 일은 다시 손으로 더듬는 일이 되고, 어떤 수정을 했을 때 왜 나아졌는지도 설명 없이 남는다.

월요일 아침 운영 장면을 떠올려보자. 전력 계통 해석 프로그램이 특정 모선 조건에서만 오차를 크게 낸다고 해보자. 로그에는 수렴 반복 횟수가 늘어났다는 기록만 남는다. 그 기록만 보고는 초기값이 문제인지, 선형 solver의 전처리가 문제인지, 아니면 식 자체의 강성 때문인지 가리기 어렵기 때문이다. 엔지니어는 하나씩 바꿔보면서 감으로 잡아낸다. 이 방식은 그날은 통해도 다음 달에는 다시 흔들리는데, 고친 것과 나아진 것 사이의 연결이 문서로 남지 않기 때문이다.

저는 여기서 멈칫했다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 실행 피드백이 주는 숫자는 출발선이지 도착선이 아니다. 숫자에서 원인으로 건너가는 다리가 없으면 개선은 매번 처음부터 헤매게 되기 때문이다. 그렇다면 그 다리는 어떤 모양이어야 할까. 논문은 그 다리를 진단이라고 부른다.

그렇다면 진단은 무엇을 설명해야 할까

ADSD라는 이름에 들어간 Auto-Diagnosis and Skill Discovery는 순서가 곧 주장이다. 왜 틀리는지를 먼저 말로 풀어내고, 그 설명을 길잡이 삼아 수치 기법을 찾아낸다는 것이다. 진단은 점수 대신 문장으로 남는데, 어디에서 오차가 자라는지, 어떤 가정 아래 solver가 흔들리는지, 무엇을 바꾸면 그 흔들림이 잦아들지를 서술하는 일이기 때문이다. 이 서술이 있어야 다음 단계의 탐색이 허공을 찌르지 않는다.

여기서 재미있는 질문이 생긴다. 진단은 얼마나 구체적이어야 할까. 너무 뭉뚱그리면 실행 피드백과 다를 바가 없고, 너무 잘게 들어가면 한 사례에만 붙어버리기 때문이다. 논문이 겨냥한 자리는 그 중간이다. 특정 실패를 설명하면서도 다른 사례로 옮겨갈 수 있는 형태로 적는 것이다. 예를 들어 전력 조류 계산에서 전압 위상이 크게 벌어지는 구간을 두고, 그 구간에서 야코비안의 조건이 나빠진다는 식으로 적는 것이다. 이렇게 적으면 처방도 함께 따라온다. 전처리를 바꾸거나 스텝을 나누거나 식을 다시 쓰거나 하는 식으로 말이다.

개인적으로 눈에 들어온 점은, 진단이 사람을 설득하려고 쓰이기보다 탐색을 이끌려고 쓰인다는 것이다. 진단은 보고서의 마지막 줄을 넘겨 다음 실험의 첫 줄이 된다. 무엇을 시도할지를 좁혀주기 때문이다. (참고로 과학 계산에서 이런 설명은 흔히 통찰로만 소비되고 맙니다. 이번 연구는 그 설명을 바로 다음 탐색의 입력으로 넣었다는 점에서 결이 다릅니다.) 이 연결이 있어야 시행착오가 순서 있는 일로 바뀐다. 그렇다면 길어 올린 기법은 어떻게 쌓아둘까.

한 번 배운 요령을 다음 문제에도 쓸 수 있을까

논문에서 말하는 solver skill은 겉으로는 비유처럼 들리지만 실제로는 보관 단위이다. 한 번의 진단과 발견에서 얻은 수치 기법을 다음 문제에도 꺼내 쓸 수 있도록 묶어두는 것이다. 수정 조각 하나를 넘어 언제 쓰고 어떻게 끼우는지를 함께 담은 꾸러미에 가깝기 때문이다. 이렇게 묶어두면 고친 내용이 특정 파일에 박혀 사라지지 않고, 다른 식과 다른 조건에서도 다시 불려 나온다.

오답 노트를 떠올리면 감이 온다. 틀린 문제를 답만 고쳐 적어두는 것과 풀이 요령째 적어두는 것은 몇 달 뒤의 쓰임이 다르기 때문이다. 전자는 그 문제에만 붙고, 후자는 비슷한 유형 전체에 붙는다. solver skill도 같은 갈래인데, 어떤 실패 형태에서 어떤 처방이 통했는지를 함께 적어두기 때문에 다음 실패에서 바로 꺼낼 수 있다. 저는 이 대목에서 논문의 태도가 읽혔다. solver 개선을 편집의 연속으로 보지 않고, 쌓이는 자산의 문제로 보고 있다는 것이다.

문제는 그다음이다. 쌓는다고 다 쓸모 있어지는 것은 아니다. skill이 늘수록 무엇을 꺼낼지가 새로운 문제가 되기 때문이다. 그래서 진단이 다시 등장한다. 현재 실패의 설명과 보관된 skill의 설명이 만나야 연결이 생기기 때문이다. 맞는 skill을 고르는 일이 또 하나의 판단이 되는 셈이다. 논문은 이 고르는 일을 진단의 언어로 풀어낸다. 이 구조가 실제로 돌아갈까. 시험대를 보면 감이 잡힌다.

시행착오를 순서 있는 일로 바꾸면 어떻게 달라질까

논문이 그리는 과정은 세 고리로 이어진다. 먼저 실패를 진단하고, 그 진단을 따라 수치 기법을 찾아내고, 찾아낸 기법을 solver 안에 실제로 넣는 것이다. 이렇게 적으면 평범해 보이지만, 실제로는 그렇지 않다. 순서가 바뀌면 탐색의 성격 자체가 바뀌기 때문이다. 진단 없이 기법을 찾으면 운에 기대게 되고, 구현 없이 진단만 하면 말로 끝나는데, 세 고리가 이어질 때만 개선이 남기 때문이다.

이 차이는 생각보다 크다. 시행착오에서는 사람이 매번 판단의 자리를 채워야 하기 때문이다. 무엇을 바꿔볼지, 바꾼 뒤의 숫자를 어떻게 읽을지, 그 숫자를 다음 시도에 어떻게 반영할지를 매번 정해야 하죠. 반면 진단이 앞에 서면 시도할 방향이 좁혀지고, skill이 뒤에 서면 한 번의 성공이 다음 시도의 출발점이 된다. 저는 이 숫자보다 그 뒤의 구조가 더 오래 남는다고 봅니다. 숫자는 그날의 조건에 붙지만, 구조는 다음 달의 실험에도 붙기 때문이다.

실제 시스템 관점에서 보면 다음 질문이 바로 생긴다. 이런 순환을 돌리는 데 드는 품은 누가 감당할까. 진단을 쓰고 skill을 쌓는 일에도 계산과 시간이 든다. 그 품이 solver를 손으로 고치는 품보다 적어야 수지가 맞기 때문이다. 논문은 네 가지 영역에서 그 수지를 묻는다. 품을 들인 만큼 solver가 여러 과제에서 고르게 나아지는지를 보는 것이다. 저는 이 선택이 솔직하다고 봤다. 한 문제에서만 통하는 요령이라면 구조라고 부르기 어렵기 때문이다.

네 가지 시험대가 말해주는 것은 무엇일까

연구진이 고른 시험대는 네 가지이다. 전력 조류 방정식과 교류 최적 조류 제어, 강성 상미분방정식, 그리고 비균질 확산 편미분방정식이 그것인데, 겉보기에는 따로 놀아 보이지만 속으로는 하나의 질문으로 묶인다. 수치적으로 까다로운 식 앞에서 진단과 skill이 통하는지를 묻는 것이다. 전력 쪽은 실제 계통 운영과 닿아 있고, 강성 방정식과 비균질 확산은 시간과 공간의 간격이 크게 벌어지는 경우를 다루기 때문이다.

질문도 바뀌었다. solver를 돌릴 수 있는가에서 solver를 고칠 수 있는가로 말이다. 예전에는 에이전트가 코드를 짜서 실행되면 절반은 온 셈이었다. 이제는 실행된 solver가 틀리는 이유를 설명하고 고쳐낼 수 있는지가 묻게 되기 때문이다. 네 가지 영역은 그 물음에 어울리는 자리인데, 한 영역에서만 통하는 처방과 여러 영역에서 통하는 처방을 가려낼 수 있기 때문이다. 전력에서 통하던 요령이 확산 방정식에서도 통한다면, 그것은 우연을 넘어 수치 계산에 대한 이해에 가깝다.

여기서는 조금 조심해서 읽을 필요가 있다. 네 가지라고 해서 모든 과학 계산을 덮는 것은 아니기 때문이다. 유체나 파동이나 확률 미분방정식처럼 이번 시험에 없는 영역도 여전히 많다. 그래서 네 가지라는 숫자를 전부로 읽으면 안 되기 때문이다. 그럼에도 이 구성이 눈에 밟히는 이유는, 정확도와 견고함과 효율을 함께 묻기 때문이다. 하나만 좋아지는 개선은 운영에서 오래 못 가는데, 세 가지를 함께 보면 개선의 결이 드러나기 때문이다. 그렇다면 숫자는 어떻게 나왔을까.

71배라는 숫자를 어떻게 읽어야 할까

GOC-500 전력 조류 계산에서 평균 solver 오차가 71배 가까이 줄었다는 대목은 논문에서 가장 눈에 띄는 숫자이다. 평균 오차가 71분의 1 수준으로 떨어졌다는 뜻인데, 체감으로는 답이 어긋나던 자리수가 두 자리 가까이 좁혀진 셈이기 때문이다. 같은 식을 같은 조건에서 풀었을 때 solver가 내놓는 답이 참값에 훨씬 바짝 붙었다는 것인데, 저는 이 숫자를 정확도의 문제로만 읽지 않았다. 진단이 처방으로 이어졌다는 증거로 읽었기 때문이다.

이 숫자는 그대로 믿기 전에 조건을 봐야 한다. 평균이라는 말 뒤에는 분포가 숨어 있다. 몇몇 어려운 사례만 극적으로 좋아졌는지, 아니면 전체가 고르게 내려왔는지를 함께 봐야 하기 때문이다. 논문이 정확도와 함께 견고함과 효율을 내세운 것도 같은 맥락이다. 평균 하나가 좋아졌다고 해서 solver가 맡길 만해지는 것은 아니기 때문이다. 어려운 조건에서도 터지지 않고, 시간과 품을 덜 쓰면서 답에 닿아야 운영의 선택지에 오를 수 있다. 그런 눈으로 보면 71배는 끝보다 입구에 가깝다. 무엇이 좋아졌는지를 묻고 나서 어떻게 좋아졌는지를 묻게 되기 때문이다.

여기서 겉보기에 좋아 보이는 해석을 하나 걷어낼 필요가 있다. 오차가 줄었다고 해서 식이 쉬워진 것은 아니다. 식의 어려움은 그대로 있고 solver가 그 어려움을 다루는 법을 배운 것이기 때문이다. 전력 조류처럼 비선형이 얽힌 식은 조건이 조금만 바뀌어도 해가 멀어지는데, solver가 그 민감한 구간을 진단으로 짚고 skill로 메웠다는 것이 이번 결과의 결이다. 그렇다면 다음 물음은 자연스럽다. 배운 요령은 처음 보는 조건에서도 통할까.

본 적 없는 전력망에서도 통할까

논문이 덧붙인 대목 가운데 저에게는 이 장면이 유난히 오래 남았다. 개선된 solver가 학습 때 보지 못한 전력망 구조와 운영 조건에서도 나아진 모습을 이어간다는 보고다. 새로운 결선 형태나 부하 분포 앞에서도 오차 감소가 유지된다는 뜻이기 때문이다. 이 대목이 눈에 밟히는 이유는 따로 있다. 외운 답을 내놓는 경우보다 푸는 법을 갖춘 경우에 기대할 수 있는 모습이기 때문이다. 이유는 단순하다. 외운 답은 문제가 바뀌면 무너지지만, 푸는 법은 문제가 바뀌어도 버티니까요. 그렇다면 이 정도의 전이를 두고 푸는 법을 갖췄다고 불러도 될까. 저는 아직 반쯤만 그렇다고 봤다.

여름철 저녁 피크 시간대를 떠올려보자. 그 시간대에는 낮에는 없던 부하가 몰리고, 일부 선로는 보수 때문에 빠져 있으며, 전압 조건도 평소와 다르게 걸리기 때문이다. 이런 날에 solver가 특정 결선에서만 통하는 요령을 들고 오면 운영자는 쓸 수 없다. 조건이 바뀌는 날일수록 시험이 오히려 더 엄격해지기 때문이다. 반면 조건이 바뀌어도 통하는 요령이라면 이야기가 달라지는데, 그 요령은 특정 사례의 기억을 넘어 수치 구조에 대한 대응에 가깝기 때문이다. 그래서 저는 전이 결과를 정확도 숫자와 같은 무게로 눈여겨봤다. 이런 버팀이야말로 운영의 아침을 지키는 성질이기 때문이다.

다만 이 결과를 너무 멀리 일반화하기에는 자료가 아직 부족하다. 보지 못한 구조라고 해도 아직은 전력망이라는 같은 갈래 안에서의 이동이니까요. 완전히 다른 물리 영역으로 건너가도 같은 skill이 통하는지는 이 대목만으로 단정하기 어렵기 때문이다. 이 조심스러움과 별개로 구분할 것은 분명하다. 네 가지 영역에서 고르게 나아졌다는 결과와 같은 영역 안에서 새로운 조건으로 옮겨갔다는 결과는 서로 다른 주장이기 때문이다. 그래서 둘을 섞어 읽으면 안 된다. 하나는 넓이에 대한 주장이고 다른 하나는 낯섦에 대한 주장이기 때문이다. 그렇다면 이 둘을 어떻게 함께 읽어야 할까. 다음 장면이 그 쓰임을 묻는다.

숫자 계산에 강한 지능은 어디에서 쓰일까

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. ADSD를 운영의 눈으로 보면 묻는 것이 달라진다. solver가 얼마나 정확해졌는지를 넘어 그 정확함이 어떤 품으로 유지되는지를 묻게 되기 때문이다. 진단과 skill을 쌓는 데 든 시간, solver를 고쳐 넣는 데 든 손질, 그리고 고쳐진 solver가 아낀 반복 계산을 한 저울에 올려야 한다.

좋은데, 이걸 어디에 올릴까요. 전력 계통처럼 매일 같은 식을 조금씩 다른 조건에서 푸는 자리가 먼저 떠오른다. 아침마다 부하가 바뀌고 결선이 바뀐다. solver를 매번 손으로 만질 수는 없기 때문이다. 이런 자리에서는 한 번 쌓은 skill이 매일의 계산에 얹히면서 품을 갚는다. 강성 방정식이나 비균질 확산처럼 간격이 벌어지는 식에서도 사정은 비슷한데, 스텝을 어떻게 나누고 어디에 정밀도를 쓸지를 한 번 배워두면 다음 계산이 가벼워지기 때문이다.

여기서도 과하게 읽지 않으려 한다. solver가 스스로 고쳐진다고 해서 사람이 빠지는 것은 아니다. 무엇을 진단할지와 무엇을 skill로 남길지를 정하는 눈은 여전히 사람의 몫이기 때문이다. 자동화가 깊어질수록 무엇을 맡길지의 결정이 더 무거워진다. 맡길 수 있는 것과 맡겨서는 안 되는 것을 가르는 일이 남기 때문이다. 이 구분이 있어야 효율이라는 말이 현장에서 뜻을 갖는다. 그렇다면 남은 물음은 무엇일까.

그렇다면 사람의 역할은 무엇일까요

질문도 바뀌었다. solver를 돌릴 수 있는가에서 solver가 왜 틀리는지를 물을 수 있는가로 말이다. ADSD가 던진 물음도 같은 갈래인데, 실행 피드백의 숫자를 원인의 문장으로 바꾸고, 그 문장을 다음에도 쓸 수 있는 기법으로 남길 수 있는가이다. 네 가지 영역에서의 결과와 GOC-500에서의 오차 감소, 그리고 보지 못한 조건으로의 전이는 그 물음에 대한 첫 답인데, 진단이 탐색을 이끌 때 solver가 스스로 나아질 수 있다는 것이다.

제가 앞으로 보고 싶은 것은 진단의 언어가 어디까지 정교해질 수 있는지이다. 지금은 실패의 원인을 짚어 다음 기법으로 잇는 수준인데, 이 언어가 더 잘게 쪼개지고 서로 비교될 수 있다면 skill을 고르는 일도 더 단단해질 것이기 때문이다. 또한 한 영역에서 길어 올린 skill이 다른 영역의 진단과 만날 때 어떤 일이 생기는지도 궁금한데, 전력에서 배운 요령이 확산 방정식의 진단을 만났을 때 서로 말이 통하는지가 수치 지능의 다음 시험이 되기 때문이다.

처음 이 논문을 펼쳤을 때 든 생각은 단순했다. 또 하나의 solver 고치기 이야기겠거니 하고 말이다. 그런데 다 읽고 나니 남는 것은 solver보다 공부법이다. 틀렸다는 말을 듣고 다시 푸는 공부와, 왜 틀렸는지를 적어두고 요령으로 쌓는 공부는 몇 달 뒤에 전혀 다른 실력이 된다. ADSD는 후자를 기계의 일로 옮긴 셈이기 때문이다. 그렇다면 사람의 역할은 무엇일까요. 무엇을 틀려볼지, 무엇을 남길지, 그리고 어떤 답을 좋은 답으로 부를지를 정하는 일이 아닐까. 저는 그 물음 앞에서 글을 닫는다.