L2G-SR이 수치 오차 곁에 구조 점수를 놓은 이유

이번에 다룰 논문은 L2G-SR: Learning to Guide LLM-based Symbolic Regression으로, arXiv:2610.20685 번호로 arXiv에 공개된 연구입니다. 원문 논문으로 이어지는 링크는 제목 아래에 붙여 두었습니다. 이 연구가 내세우는 주장은 한 문장으로 정리됩니다. 언어 모델로 수식을 찾는 탐색 과정에서 수치 오차만으로 부모 후보를 고르던 관행을 벗어나, 학습된 구조 검증기(structural verifier)가 구조 점수를 함께 매기도록 만들면 진짜 식에 더 가까워진다는 것입니다.

제가 이 논문을 읽기 시작한 이유는 꽤 실무적이었습니다. 데이터를 보고 식을 찾는 일은 과학 계산이나 엔지니어링 분석에서 자주 등장하는데, 막상 언어 모델에게 시키면 그럴듯한데 어딘가 어색한 식이 돌아올 때가 있거든요. 오차 숫자는 작은데 어딘가 믿음이 가지 않는 경우죠. 그래서 이 논문이 말하는 수치와 구조의 간극이 남의 이야기로 느껴지지 않았습니다. 이 글에서는 그 간극이 왜 생기는지, 구조 점수를 어떻게 가르치는지, 그리고 탐색이 실제로 어떻게 달라지는지를 순서대로 따라가겠습니다.

숫자는 맞는데 어딘가 찜찜했던 경험

실험 데이터를 앞에 두고 식을 찾을 때, 저는 먼저 그래프를 그려보는 편입니다. 점들이 어떤 곡선을 그리는지 눈으로 확인하면 후보 식의 모양이 어느 정도 좁혀지기 때문입니다. 그런데 언어 모델에게 같은 일을 시키면 과정이 꽤 다릅니다. 모델은 여러 후보 식을 만들어내고, 주어진 데이터에 대입해 보고, 오차가 작은 쪽을 살려서 다음 세대로 넘기죠. 이 방식은 직관적으로 합리해 보이는데, 막상 결과를 보면 고개를 갸웃하게 되는 경우가 생깁니다.

문제는 그다음에 드러납니다. 오차가 작다는 이유만으로 살아남은 식이, 실제로는 관측 구간에서만 우연히 잘 맞는 대역물(surrogate)일 수 있기 때문입니다. 구간 안에서는 거의 겹쳐 보이는데, 식을 풀어보면 원래 현상을 설명하는 항이 빠져 있거나 전혀 다른 연산으로 근사해 둔 경우죠. 저는 이런 경우를 보면 시험 답안지가 떠오릅니다. 정답과 숫자는 같은데 풀이 과정이 전혀 다른 답안 같은 느낌이랄까요. 채점 기준이 최종 숫자에만 있으면 그 답안은 만점을 받습니다. 그런데 그 답안을 다음 문제에 그대로 적용하면 바로 틀리죠.

그렇다면 탐색의 채점 기준을 어떻게 바꿔야 할까요. 저자들은 여기서 수치 오차라는 단일 잣대에 질문을 던집니다. 오차가 작다는 사실이 구조까지 옳다는 뜻은 아니니, 구조가 맞는지를 따지는 또 하나의 눈이 필요하다는 것이 이 연구의 출발점입니다. 이 지점에서 뒤에 등장하는 verifier의 역할이 자연스럽게 예고됩니다.

오차만 보고 고르면 벌어지는 일

언어 모델 기반 symbolic regression의 일반적인 탐색을 떠올려 보시면 이해가 빠릅니다. 모델이 여러 후보 식을 제안하면 각 식의 예측값과 관측값 사이의 차이를 계산하고, 오차가 작은 식을 부모(parent)로 골라 다음 변형의 재료로 삼습니다. 세대를 거듭할수록 오차는 줄어들고, 표면적으로는 탐색이 잘 되고 있는 것처럼 보이죠. 그런데 이 과정에는 눈에 잘 띄지 않는 함정이 있습니다.

그 함정은 오차가 구조 정보를 담지 못한다는 데 있습니다. 식의 생김새가 완전히 달라도 주어진 점들 근처에서는 비슷한 값을 낼 수 있기 때문입니다. 특히 관측 구간이 좁거나 잡음이 섞여 있으면, 진짜 구조를 가진 후보보다 매끈하게 근사한 대역물이 오차 경쟁에서 이기기도 합니다. 대역물이 부모가 되면 다음 세대는 그 대역물을 닮은 변형들로 채워지고, 탐색은 진짜 구조에서 점점 멀어집니다. 그래서 오차 곡선은 내려가는데 정답 식과의 거리는 그대로인 어색한 상황이 벌어지죠.

생각해 보면 사람도 비슷한 실수를 합니다. 중간고사 범위에만 맞춰 외운 학생이 그 범위 안에서는 만점을 받지만, 범위를 조금만 벗어나도 막히는 경우와 비슷하죠. 저는 이 대목을 읽으면서 수치만 보는 선택이 탐색을 얼마나 쉽게 좁은 골목으로 몰아넣는지 다시 느꼈습니다. 그렇다면 구조가 맞는지를 재는 자를 어떻게 만들 수 있을까요. 그 이야기는 다음 장면으로 이어집니다.

구조가 가깝다는 말의 뜻을 정하는 일

수식의 구조가 비슷하다는 말을 실제로 가르치려면 먼저 거리를 정의해야 합니다. 저자들은 여기서 트리 편집 거리(tree edit distance, TED)를 가져옵니다. 수식을 트리로 펼친 뒤, 한 트리를 다른 트리로 바꾸는 데 필요한 편집 횟수를 세는 방식이죠. 연산자를 더하거나, 항을 지우거나, 노드를 바꾸는 조작이 몇 번 필요한지를 셉니다. 이 거리가 짧을수록 두 식의 구조가 가깝다고 말할 수 있습니다.

그런데 수식에는 같은 뜻을 다르게 쓰는 경우가 많아서 단순히 글자만 비교하면 곤란해집니다. 덧셈이나 곱셈처럼 교환 법칙이 성립하는 연산자는 순서를 바꿔 써도 같은 식인데, 트리 비교에서는 순서가 달라진 것으로 셀 수 있기 때문입니다. 그래서 저자들은 교환 가능한 연산자를 고려한 비교 방식을 쓰고, 같은 식의 다른 표현 형태도 같은 구조로 인정하도록 감독 신호를 구성합니다. 이 처리는 얼핏 사소해 보이지만, 실제로는 학습 신호의 질을 좌우합니다. 같은 것을 다르다고 가르치면 verifier는 엉뚱한 구분을 배우게 되니까요.

저는 이 선택이 꽤 신중하다고 느꼈습니다. 구조라는 말을 추상적으로 두지 않고, 연산 규칙을 반영한 거리로 바꿔서 학습 가능한 형태로 만든 셈이니까요. 물론 트리 거리가 물리적 의미를 전부 담지는 못합니다. 같은 거리라도 어떤 항이 틀렸는지에 따라 의미가 달라질 수 있죠. 그럼에도 탐색을 이끄는 보조 신호로 쓰기에는 충분히 단단한 출발점입니다. 이제 남은 질문은 이 거리를 실제로 어떻게 학습시키느냐는 것입니다.

숫자와 식을 나란히 놓고 읽는 연습부터 시킵니다

verifier의 학습은 두 단계로 생각하면 편합니다. 첫 단계에서는 수치 관측과 수식을 서로 연결 짓는 정렬(alignment)을 배웁니다. 다시 말해, 어떤 데이터 패턴이 어떤 형태의 식과 어울리는지를 먼저 익히는 것이죠. 이 과정이 없으면 verifier는 기호만 보고 판단하는 문자 판독기가 되기 쉽습니다. 숫자가 어떤 식에서 나올 수 있는지를 알아야 구조 판단에도 현실감이 생기니까요.

두 번째 단계에서는 목표 식과의 구조적 유사도를 점수로 매기는 법을 배웁니다. 학습 때는 정답 식이 주어지므로 앞에서 정한 트리 편집 거리를 정답 신호로 쓸 수 있습니다. 관측 데이터와 후보 식이 입력되면, 이 후보가 정답 구조와 얼마나 가까운지를 점수로 내뱉도록 훈련하는 것이죠. 여기서 배우는 것은 단순한 오차 계산을 넘어, 관측 패턴을 단서 삼아 구조적 거리를 어림하는 감각에 가깝습니다. 사람으로 치면 답지를 보고 채점하는 연습을 반복하면서, 나중에는 답지 없이도 어림할 수 있게 되는 과정과 비슷합니다.

(참고로 이 정렬 단계를 두는 방식은 저자들이 꽤 의도적으로 설계한 대목으로 읽혔습니다. 숫자와 식을 따로 보지 않고 둘 사이의 대응을 먼저 다지게 하니까요.) 저는 이 순서가 마음에 들었습니다. 실제 시스템 관점에서 보면 관측과 기호를 따로 처리하는 모듈은 나중에 꼭 어긋나는 지점이 생기는데, 처음부터 함께 묶어두면 그런 어긋남이 줄어들기 때문입니다. 그렇다면 이렇게 배운 verifier는 탐색 현장에서 어떻게 쓰일까요.

정답을 가리고도 구조를 어림하는 장치

탐색이 실제로 돌아갈 때는 정답 식이 숨겨져 있습니다. 당연한 이야기지만, 현장에서 답지를 볼 수는 없으니까요. 그런데도 verifier는 구조 점수를 계속 내놓습니다. 학습 때 익힌 관측과 구조 사이의 대응을 바탕으로, 지금 눈앞의 후보가 목표 구조에 가까울 것 같은지를 어림하는 것이죠. 수치 오차는 여전히 계산되지만, 부모를 고를 때는 구조 점수가 함께 고려됩니다.

이 장면이 왜 달라졌는지 짚어볼 필요가 있습니다. 예전에는 오차가 작으면 무조건 좋은 부모였는데, 이제는 오차가 작아도 구조 점수가 낮으면 다음 세대의 재료에서 밀려날 수 있기 때문입니다. 반대로 오차가 아주 작지는 않아도 구조적으로有望한 후보, 그러니까 뼈대는 맞는데 계수나 세부 항만 손보면 될 것 같은 후보가 살아남을 기회를 얻습니다. 탐색의 초기에는 이런 후보를 살려두는 일이 특히 소중합니다. 초반에 뼈대 맞는 후보를 잃어버리면 나중에 아무리 변형을 가해도 되돌리기 어렵거든요.

여기서는 조금 조심해서 읽을 필요가 있습니다. verifier의 점수가 완벽하다는 뜻과는 거리가 멉니다. 오차 하나만 보던 선택에 두 번째 축이 생겼다는 뜻이니까요. 두 축이 서로를 견제하면서 부모 집단을 고르게 되는데, 저는 이 균형이 이 논문에서 가장 눈여겨볼 대목이라고 봅니다. 점수를 매기는 장치가 하나 더 생겼을 뿐인데 탐색의 궤적 자체가 달라지니까요. 다음으로 궁금해지는 것은 점수를 알았다면 그 점수를 어떻게 고치는 데 쓰느냐는 점입니다.

점수에서 멈추지 않고 고치는 쪽으로 넘깁니다

L2G-SR의 탐색 고리에는 점수만 매기는 장치를 넘어서는 움직임이 있습니다. 분석가(analyst)라는 역할이 verifier의 피드백과 진단 도구를 함께 보면서 수정 방향을 제안하고, 생성기(generator)가 그 제안을 받아 다듬어진 식으로 바꾸는 구조죠. 점수가 낮게 나왔다는 사실에서 멈추지 않고, 어디가 문제처럼 보이는지를 언어로 풀어서 다음 생성에 넘기는 셈입니다.

이 흐름을 일상적인 작업에 비유하면 코드 리뷰와 비슷하게 읽힙니다. 테스트 점수만 통보하는 데서 멈추지 않고, 리뷰어가 실패한 지점을 짚고 어디를 어떻게 손보면 좋을지를 적어주면 작성자가 그 의견을 반영해 다시 제출하는 과정이랄까요. 물론 사람이 하는 리뷰만큼 풍부하지는 않겠지만, 방향 없는 무작위 변형보다는 훨씬 효율적입니다. 진단 도구가 수치적인 단서를 제공하고 verifier가 구조적인 단서를 주면, 분석가는 두 단서를 엮어서 다음 시도에서 바꿔야 할 부분을 좁힐 수 있습니다.

저희가 새로운 AI 구조를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템 안에서 어떤 비용과 절차를 만드는지를 함께 봅니다. 그런 눈으로 보면 이 분석가와 생성기의 분업은 꽤 현실적인 선택입니다. 점수를 매기는 일과 고치는 일은 서로 다른 능력을 요구하는데, 이를 한 모델에 몰아넣으면 둘 다 어중간해지기 쉽기 때문입니다. 역할을 나누면 각자의 입력과 출력이 분명해지고, 실패했을 때 어디서 어긋났는지도 추적하기 쉬워집니다.

부모를 고르는 자리가 탐색의 방향을 정합니다

진화 탐색에서 부모 선택은 생각보다 큰 자리입니다. 어떤 후보를 살려두느냐가 다음 세대의 유전자 풀을 정하고, 그 유전자 풀이 갈 수 있는 방향을 사실상 가두기 때문입니다. L2G-SR은 바로 이 자리를 손봅니다. 수치 오차 순서대로 줄을 세우던 기존 방식 곁에 구조 점수를 놓고, 두 기준을 함께 쓰는 선택으로 바꾼 것이죠.

이 변화가 가져오는 차이는 시간이 지날수록 벌어집니다. 초반에는 차이가 작아 보일 수 있습니다. 오차가 작은 후보와 구조가 맞는 후보가 어느 정도 겹치기 때문입니다. 그런데 세대가 쌓이면서 대역물이 득세하는 국면이 오면 두 방식의 길이 갈라집니다. 오차만 보는 선택은 대역물의 자손들로 채워지고, 구조를 함께 보는 선택은 뼈대가 맞는 계열을 붙잡고 버팁니다. 뒤집어 말하면 verifier가 하는 일은 매 세대마다 작은 교정을 거는 일인데, 그 작은 교정이 쌓여서 최종 도착지를 바꾸는 셈입니다.

그렇다면 구조 점수를 얼마나 세게 반영해야 할까요. 이 비중 조절은 논문을 읽을 때 제가 자꾸 멈칫했던 지점입니다. 구조 점수를 너무 세게 걸면 초반부터 특정 모양에 갇힐 수 있고, 너무 약하게 걸면 대역물을 막지 못하니까요. 논문에서 말하는 보완(complement)이라는 표현은 그래서 정확합니다. 구조 점수가 오차를 대체하지 않고 곁에서 함께 작용한다는 뜻이니까요. 저는 이 균형 감각이 탐색 설계의 오래된 질문과 맞닿아 있다고 봅니다. 지금 당장 잘하는 개체와 나중에 될 것 같은 개체 사이에서 어디에 표를 줄 것인가 하는 문제 말이죠.

벤치마크 결과는 어떻게 읽는 게 좋을까

평가 무대는 LLM-SRBench이며, 보고된 바에 따르면 L2G-SR은 수치 적합과 식 단위 정확도, 트리 편집 거리에서 앞선 결과를 보였다고 합니다. 여러 언어 모델 백본과 여러 도메인에 걸쳐 그런 경향이 확인됐다는 점도 함께 적혀 있습니다. 저는 이 대목을 읽으면서 숫자보다 그 뒤의 구성을 더 눈여겨봤습니다. 적합도와 정확도, 거리라는 서로 다른 축을 함께 본 구성 말이죠.

왜 세 축을 함께 봐야 할까요. 수치 적합만 보면 대역물 문제를 다시 만날 수 있고, 식 단위 정확도만 보면 얼마나 아깝게 틀렸는지를 알 수 없기 때문입니다. 트리 편집 거리는 그 사이를 메웁니다. 정확도에서는 틀렸지만 구조적으로는 얼마나 가까워졌는지를 보여주니까요. 세 지표가 같은 방향을 가리킬 때, 그 개선은 우연한 과적합을 넘어 구조 쪽으로의 이동일 가능성이 커집니다. 여러 백본과 도메인에 걸친 확인도 같은 맥락에서 읽힙니다. 특정 모델이나 특정 식 패밀리에만 붙어 있는 요령을 넘어, 탐색을 이끄는 방식 자체가 달라졌다는 뜻에 가까우니까요.

다만 여기서 한 가지 짚고 넘어갈 점이 있습니다. 벤치마크라는 말 자체가 모든 것을 말해주지는 않는다는 점입니다. 어떤 식 패밀리가 포함됐는지, 관측 잡음이나 구간 설정이 어떠했는지에 따라 결과의 결이 달라질 수 있으니까요. 저는 그래서 이 결과를 구조 안내라는 발상이 여러 조건에서 통했다는 신호로 읽되, 그 신호의 세기를 재는 일은 뒤에 나오는 분석과 함께 봐야 한다고 봅니다.

이 결과를 어디까지 믿어야 할까

앞에서 좋은 이야기를 많이 했으니, 여기서는 잠시 속도를 늦추고 싶습니다. 구조 점수를 배운다는 발상은 분명 매력적이지만, 그 점수를 가르치는 데 쓰인 거리 자체가 완전한 정답은 아니기 때문입니다. 트리 편집 거리는 기호 구조의 차이를 세는 데에는 능숙하지만, 물리적 의미의 차이를 그대로 반영하지는 못합니다. 어떤 항 하나가 바뀌었을 때와 연산자 하나가 바뀌었을 때, 편집 횟수는 같아도 현상 설명으로서의 차이는 크게 벌어질 수 있죠.

또 하나 생각해 볼 점은 verifier가 학습한 대응이 미지의 식에도 그대로 통할지입니다. 학습 때 본 적 없는 형태의 식이나 관측 패턴 앞에서는 점수의 신뢰도가 떨어질 수 있습니다. 탐색 현장에서는 바로 그런 미지의 후보를 만나게 되는데, 이때 verifier가 과신한 점수를 내놓으면 탐색이 엉뚱한 뼈대에 갇힐 수도 있습니다. 그래서 구조 점수를 오차와 함께 쓰는 보완 구조는 안전장치로서도 읽힙니다. 한쪽이 흔들려도 다른 쪽이 버텨주는 형태니까요.

그렇다면 앞으로 보고 싶은 것은 무엇일까요. 저는 verifier의 점수와 실제 구조 거리 사이의 간극이 탐색 세대에 따라 어떻게 움직이는지, 그리고 점수가 틀렸을 때 탐색이 스스로 회복되는지를 보고 싶습니다. 실패 사례를 모아보면 이 방법이 강한 경우와 약한 경우의 경계가 드러날 텐데, 그 경계야말로 실제 적용에서 가장 쓸모 있는 정보가 되기 때문입니다. 좋은 결과 뒤에는 늘 다음 질문이 따라붙죠. 이 논문도 예외는 아닙니다.

식을 더 만드는 법보다 알아보는 눈을 기르는 일

처음으로 돌아가 보겠습니다. 이 연구는 식을 더 많이 만들어내는 법을 말하지 않습니다. 식을 알아보는 눈을 하나 더 기르고, 그 눈으로 탐색을 이끄는 법을 말합니다. 수치 오차가 말해주지 못하는 구조의 기미를 verifier가 맡고, 분석가와 생성기가 그 기미를 다음 시도로 옮기며, 부모 선택에서 두 신호가 함께 작동하는 흐름이죠. 저는 이 흐름을 읽으면서 예전에 들었던 오답 노트 이야기가 떠올랐습니다. 틀린 답을 모아두는 데서 그치지 않고 왜 틀렸는지를 적어두면 다음 시험에서 같은 실수를 줄일 수 있다는, 꽤 평범하면서도 잘 통하는 방식 말이죠.

실제 적용을 상상하면 다음 장면이 그려집니다. 밤사이 들어온 센서 데이터를 아침에 식으로 정리해야 하는 팀이 있다고 해보죠. 오차만 작은 식을 뽑으면 당장 보고서는 매끈해 보이지만, 조건이 조금만 바뀌어도 깨지는 모형이 될 수 있습니다. 반면 구조 점수까지 함께 본 식은 당장 오차가 아주 작지 않아도 나중에 고쳐 쓸 여지가 남습니다. 운영 측면에서 보면 이 차이는 보고서 한 장의 문제를 넘어, 모형을 얼마나 오래 쓸 수 있는지의 문제입니다.

그렇다면 사람의 역할은 무엇일까요. 저는 이 질문이 이 논문을 읽고 남는 가장 긴 여운이라고 봅니다. 탐색을 이끄는 눈을 기르는 일이 자동화될수록, 어떤 구조를 좋은 구조라고 부를지, 그리고 무엇을 위해 식을 찾는지를 정하는 일은 여전히 사람의 몫으로 남으니까요. 다음에 비슷한 논문을 만나면 저는 아마 같은 질문부터 던질 것 같습니다. 이 방법은 숫자를 낮추는 데서 끝나는지, 아니면 우리가 믿고 쓸 수 있는 형태에 가까워지는지 말이죠.