약 19분

힐을 신으면 키가 줄어든다고 믿는 모델 — 들쭉날쭉한 지능에 대하여

ICML 2026. Subbarao Kambhampati의 강연 — 검증자와 사고 흔적의 역할.

목차

이 글은 ICML 2026 워크숍에서 Subbarao Kambhampati의 강연 “On the Role of Verifiers and Thinking Traces in Reasoning Models”를 발표자 1인칭 시점으로 재구성한 것입니다.

우리는 꽤 신기한 시대를 살고 있다. 지금 이 순간의 추론 모델은 에르되시가 남긴 오래된 난제인 유닛 디스턴스 추측 같은 문제를 풀어낸다. 그런데 똑같은 모델에게 “저는 키가 180센티미터인데 150센티미터가 되고 싶어요, 어떻게 해야 하나요”라고 물으면, “30센티미터짜리 하이힐을 신으세요”라고 답한다. 굽 높이와 사람 키를 더하면 총 신장이 나오니까, 그렇게 하면 자동으로 150센티미터가 된다는 논리다. 나는 이 두 가지 사례를 나란히 놓고 볼 때마다 이상한 기분이 든다. 같은 모델이 한쪽에서는 수십 년 묵은 수학 난제를 풀고, 다른 쪽에서는 초등학생도 웃을 만한 실수를 저지른다. 이걸 우리는 들쭉날쭉한 지능(jagged intelligence)이라고 부르기 시작했다. 그리고 이 들쭉날쭉함의 핵심은, 아무 보장이 없다는 것이다. 사람이라면 부분적분을 할 줄 알면 덧셈과 곱셈도 당연히 할 줄 안다고 가정해도 된다. 그런데 기억에 기반한 시스템에서는 그런 보장이 존재하지 않는다.

내가 계속 곱씹게 되는 트윗이 하나 있다. 언젠가 내가 직접 썼던 글인데, 각 연구소들이 아키텍처, 최적화 목적함수, 내부를 어떻게 스케일링했는지까지 논문으로 전부 공개하면서 딱 하나, 무엇으로 학습시켰는지 그 데이터만큼은 절대 공개하지 않는다는 내용이었다. 그러면 학계는 매번 놀란다. 도대체 비밀 소스가 뭐길래 이런 성능이 나오는 걸까 하고. 이걸 굳이 다시 꺼내는 이유는, LLM이 지금 당장 우리에게 굉장히 쓸모 있는 도구인 건 분명하지만 정작 그 성능 중 얼마가 학습 데이터와의 근접성에서 나오고 얼마가 진짜 일반화된 인지에서 나오는지 우리는 제대로 모르기 때문이다. 나는 그걸 알아내고 싶었다. 특히 플래닝이라는 관점에서 성능을 기반(substrate)과 분리해서 보는 일에 오랫동안 관심을 가져왔다. 사전학습된 거대언어모델에 추론 기능을 얹었다고 해도, 답을 통째로 외울 수 없는 종류의 문제 — 플래닝처럼 일반화된 해법이 반드시 필요한 문제 — 에서 그 시스템이 실제로 어떻게 작동하게 만들 것인가.

블록 쌓기가 유명해진 사연

이야기는 예전 자기회귀 방식의 트랜스포머 LLM에서 시작한다. 우리는 처음부터 이렇게 주장했다. 일부 벤치마크가 그럴듯해 보여도, 자기회귀 학습만으로는 플래닝 문제를 실제로 풀지 못한다고. 검증을 위해 일부러 아주 단순한 도메인들을 골랐다. 블록스월드, 물류(logistics) 같은, 플래닝 커뮤니티 안에서는 오히려 너무 쉽다고 놀림받는 도메인들이다. 그런데 GPT-4까지의 모델들이 여기서도 형편없는 성적을 냈다. 부분목표들 사이에 상호작용이 조금이라도 생기면, 단순한 근사 검색(approximate retrieval)만으로는 답이 안 나오고, 바로 그 지점에서 LLM이 무너졌다. 도메인 이름을 바꿔서 겉모습만 다르게 만드는 실험도 해봤다. 구조는 똑같은데 이름만 바꿨을 뿐인데도 성능이 더 떨어졌다. 체인오브소트, ReAct, 파인튜닝 같은 방법들도 별 도움이 되지 않았다. 일반화가 애초에 거기서 오는 게 아니었기 때문이다.

가장 상징적인 건 마지막 글자 이어붙이기 과제였다. 단어 세 개를 주고 각 단어의 마지막 글자만 뽑아서 이어 붙이라는, 사람이라면 백 개를 줘도 그냥 기계적으로 해낼 수 있는 과제다. 그런데 체인오브소트로 서너 단어짜리 예시를 하나 보여주면, LLM은 서너 개, 다섯 개짜리 문제까지는 눈에 띄게 잘하다가 단어 수가 늘어나면 급격히 무너진다. 다섯 단어로 학습시켰으면 쉰 단어를 시키려면 다시 학습시켜야 하고, 백 단어를 원하면 또 학습시켜야 한다. 알고리즘 자체를 배운 게 아니라, 그 알고리즘이 펼쳐지는 특정 길이의 형태를 그때그때 외운 것이다. 그리고 이 문제는 안타깝게도 추론 모델이 나온 지금도 크게 바뀌지 않았다. 이 연구가 실질적으로 남긴 가장 큰 유산이라면, 블록스월드가 LLM 커뮤니티에서 다시 유명해졌다는 점이다. 최근 어느 학회 논문 초록에서는 “마침내 우리의 프레임워크를 블록스월드 같은 실제 세계의 플래닝 벤치마크에 적용해보았다”는 문장을 봤다. 블록스월드를 다시 유명하게 만든 공로로 상이라도 하나 받아야 하는 게 아닌가 싶을 정도다.

검증자를 빌려 써야 하는 이유

물론 오늘 진짜 하고 싶은 이야기는 그 뒤에 등장한 추론 모델들이다. o1이 나오면서 뭔가 달라진 것처럼 보였다. 그런데 정말 달라진 걸까, 아니면 자기회귀 모델이 그랬던 것처럼 결국 우연한 상관관계와 지름길에 기대고 있는 걸까. 나는 이 질문에 답하기 전에 “왜 작동하는가”를 이해하는 일 자체의 가치를 먼저 말하고 싶다. 태양이 지구를 돈다고 믿던 시절에도 햇빛은 충분히 쓸모 있었다. 태양이 도느냐 지구가 도느냐가 햇빛의 유용성 자체를 바꾸지는 않는다. 다만 올바른 모델을 갖는다는 건, 그 지식으로 또 무엇을 더 할 수 있는지를 알게 해준다는 뜻이다.

추론 모델을 나는 아주 단순한 아이디어 하나로 설명하고 싶다. 생성하고 검증한다(generate-and-test). LLM이 후보 해답을 만들면, 검증자가 그 후보를 확인하고, 만족스럽지 않으면 돌려보낸다. 이게 우리가 LLM-모듈로(LLM-Modulo)라고 부른 구조다. 검증자가 “이 파라미터가 틀렸다”는 식의 피드백을 언어로 주면, 그게 컨텍스트 윈도우에 들어가고, 다음 후보는 그 피드백의 영향을 받는다. 이 루프에서 뭔가가 빠져나오려면 오직 하나, 검증자가 만족했을 때뿐이다. 여기서 흥미로운 건, “생성하고 검증한다”는 게 원래는 시시한 방법이라는 것이다. 인생은 무한 원숭이 정리를 기다리기엔 너무 짧으니까. 하지만 LLM은 무한 원숭이보다 훨씬 낫다. 그럴듯한 후보를 던져줄 줄 안다. 다만 그게 실제로 맞다는 보장이 없을 뿐이고, 검증자가 정답을 알고 있다면 이 루프는 제대로 작동한다.

검증자는 도메인마다 다르게 구할 수 있다. PDDL을 쓰는 사람이라면 VAL로 플랜의 유효성을 확인하면 되고, 코딩이라면 유닛 테스트를 파이썬 인터프리터에 돌려서 통과율을 보면 된다. LLM 스스로 자기 답을 검증하게 하는 방법도 있지만, 이건 결함 있는 아이디어다. LLM은 검증에서도 생성만큼이나 서투르기 때문이다. 실제로 우리가 리파이너리 벤치마크에서 이 방식을 시험했을 때, 단 열다섯 번의 반복만으로도 기본 모델보다 정확도가 눈에 띄게 올라갔다. 그리고 검증자가 완전할 필요도 없다. 부분적이어도, 그 검증자가 만족하는 한 더 나은 보장을 얻을 수 있다. AlphaGeometry나 AlphaProof 같은 시스템들도 결국 LLM을 생성기로, 다른 무언가를 검증자로 쓰는 구조다.

문제는 이 루프가 사용자와 대면한 채로 일어난다는 점이다. 사용자는 성격이 급하다. 커피 한 잔 마시고 올 여유가 없다. 그래서 이 검증 루프를 사용자 앞이 아니라 후처리 학습(post-training) 단계로 옮기자는 아이디어가 나왔다. 합성 데이터를 대량으로 만들고, LLM-모듈로를 계속 돌려서 정답이 나올 때까지 반복한 다음, 정답이 나온 문제-해답 쌍을 파인튜닝용 데이터로 쓰는 것이다. 여기서 요즘 모델들은 문제와 정답 사이에 중간 토큰들, 그러니까 스크래치패드 역할을 하는 추론 흔적을 끼워 넣고 학습한다. 이게 바로 RLVR이라는 이름으로 불리는 것이다. Verified Reward, 검증된 보상이라는 뜻이고, 핵심은 LLM 스스로가 아니라 외부 검증자가 그 신호를 준다는 데 있다.

DeepSeek이 여기서 재미있는 선택을 한다. SFT 대신 RL로, 그것도 GRPO라는 방식으로 파인튜닝을 했는데, 이들은 이게 결과(outcome) 기반 보상이라고 강조하면서도 동시에 중간 과정이 저절로 점점 더 “추론다워질” 거라고 기대한다. 그런데 결과만 가지고 학습한다면, 중간 토큰이 왜 저절로 의미를 갖게 되는지는 사실 아무 근거가 없다. GRPO를 뜯어보면, 여러 개의 궤적(trajectory)이 있을 때 각 궤적의 어드밴티지를 전체 평균 대비로 계산하고, 그 어드밴티지를 궤적 안의 모든 토큰에 균등하게 나눠준다. 이건 직관에 어긋난다. 게임에서 이겼다고 해서 그 과정에서 뒀던 모든 수가 똑같이 중요했다고 가정하지는 않는다. 이기는 팀에 속해 있었다는 이유만으로 실제로 기여하지 않았어도 함께 상장을 받는 셈이다. 그리고 이 균등 분배 때문에 RL이 사실상 SFT에 가까워지는 이상한 부작용이 생긴다. 우리는 논문에서 이걸 그대로 재현해 보였다. 베이스라인을 낮추고, 어드밴티지 분배를 균등하게 처리하고, 온폴리시(on-policy)로 만든 다음, 잘 안 되는 부분을 걸러내는 식으로 시작하면 SFT에서 출발해도 GRPO와 똑같은 효과를 얻을 수 있다.

이 이해는 DeepSeek 논문이 내놓은 또 다른 주장, 학습이 진행될수록 중간 토큰의 길이가 계속 길어지는데 이게 “모델이 생각하는 법을 배우고 있다”는 증거라는 주장에도 의문을 던진다. 길어졌다고 해서 곧바로 그런 결론으로 건너뛸 수는 없다. 우리가 보여준 건, 어드밴티지를 토큰 전체에 균등하게 나누는 구조 때문에 모델이 정답으로 이어질 가능성이 낮아도 일단 토큰을 계속 채워 넣도록 유인된다는 것이었다. 그렇게 하지 않으면 보상이 더 작은 숫자로 나뉘어버리기 때문이다. 사고 길이의 증가는, 오답 궤적이 정답 궤적과 비교되는 방식에서 나온 결과였다. 결과 자체가 바뀌는 건 아니지만, 그걸 어떻게 이해해야 하는지는 완전히 달라진다.

이 작업의 시작에는 개인적인 사연도 있다. 2024년 8월 ACL 기조연설에서 자기회귀 LLM이 플래닝에서 왜 부족한지 이야기했는데, 얼마 뒤 노암 브라운이 나에게 연락해서 “이제 o1이 나왔다, 우리가 얘기했던 그거다, 스도쿠 같은 걸 잘 풀 것”이라고 했다. 그래서 오픈AI와 함께 PlanBench 벤치마크로 o1을 실제로 검증하는 작업을 했는데, 그 과정에서 재미있게도 테스트 비용을 지불하는 쪽이 뒤바뀌었다. 의사가 나에게 건강 검진 비용을 내줬으면 좋겠다는 농담을 하곤 하는데, 실제로는 우리가 오픈AI에 비용을 내고 그들의 시스템을 테스트해야 했다. 결과는 우리 설명과 대체로 일치했다. 문제 길이가 짧을 때는 기본 성능이 올라가지만, 길어지면 다시 떨어졌다. 여전히 알고리즘 자체를 일반화한 게 아니라, 점점 더 긴 전개(unrolling)에 맞춰 적합화하고 있었다는 뜻이다. 풀 수 없는 문제(unsolvable instances)에서는 더 뚜렷했다. “다섯 단계짜리 플랜은 없다”고 말하는 것과 “어떤 길이의 플랜도 없다”고 말하는 건 완전히 다른데, 이런 유의 방법들은 후자에서 실패한다. 사이버 공격에 뚫리지 않는다는 걸 증명하려면 결국 “침투 가능한 플랜이 존재하지 않는다”는 걸 보여야 하니, 이 불가능성 검증은 실용적으로도 중요하다.

이 즈음 나는 LRM(Large Reasoning Model)이라는 이름도 만들었는데, 처음엔 다들 내가 억지로 유행어를 만들려 한다고 웃었지만 지금은 다들 그 이름을 쓴다. o1을 LLM-모듈로 안에 넣어봤더니, 검증자가 루프 안에 있다는 조건에서 o1 자체의 정확도를 보장까지 얹어서 더 끌어올릴 수 있었다. 결국 추론 모델을 이해하는 가장 정확한 방식은, 검증자의 신호가 합성 데이터라는 매개를 통해 서서히 모델 가중치 속으로 컴파일되어 들어가는 과정이라는 것이다. 이 과정은 상당히 비효율적이고, 작동한다는 사실이 그 비효율성을 없애주지는 않는다. 결국 이 비효율은 초당 토큰 수라는 형태로 언젠가 우리에게 다시 청구서로 돌아올 것이다. 참고로 이 작업은 나중에 애플의 새미(Sami)와 동료들이 다시 진행했는데, 애플이다 보니 언론의 주목을 훨씬 더 받았다. 다만 애플 쪽 사람들이 언론과 잘 이야기하지 않는 편이라, 결국 기자들은 나에게 연락해왔고 나는 그 글들이 우리가 먼저 했던 작업이라는 걸 꼭 언급하도록 했다.

사고의 흔적은 누구를 위한 것인가

이제 두 번째로 하고 싶은 이야기, 중간 토큰들 — 이른바 “사고의 흔적(thinking trace)“에 관한 것이다. 이 토큰들이 컨텍스트에 추가되기 시작하면서 사람들은 이걸 “생각”이라 부르기 시작했다. 모델이 “아하, 여기 증명이 있다”는 식으로 말하니, 사람들은 이게 진짜로 추론하고 있다는 증거라고 받아들였다. 하지만 이건 상당히 의심스러운 가정이다. 나는 어떤 말을 한다고 해서 그 말대로 실제로 하고 있다는 뜻은 아니라고 늘 생각해왔다.

내가 좋아하는 비유가 하나 있다. 서울에서 그렇게 많이 걸어다녔는데도 살이 찌는 것 같아서 운동을 해야 하는데, 게을러서 트레이너에게 전화로 대신 운동을 해달라고 부탁했다고 해보자. 트레이너가 “자, 크런치 열 개 합시다”라고 하면 나는 전화기에 대고 크런치 하는 소리를 잔뜩 낸다. 트레이너는 그 소리만으로 내가 실제로 크런치를 했는지 알 수 있을까. 어쩌면 나는 TV를 보고 있었을 수도 있다. 나중에 살이 빠졌다고 말하면 사람들은 “말한 대로 했구나”라고 생각하겠지만, 사실은 지방흡입을 했을 수도 있다. 무언가를 말한다고 해서 그걸 실제로 하고 있다는 뜻은 아니고, 결과가 좋았다고 해서 그 사이의 이야기가 맞았다는 뜻도 아니다.

DeepSeek R1에게 이름만 바꾼 세 블록 쌓기 문제를 줬을 때 실제로 무슨 일이 일어나는지 들여다본 적이 있다. 사고의 흔적을 읽어보면 “오브젝트”, “서브젝트”, “내 기둥은 2다” 같은 표현들이 그럴듯한 영어로 이어진다. 언뜻 보면 이게 정답으로 이어지는 자연스러운 사고 과정처럼 보인다. 그런데 실제로 그 흔적을 처음부터 끝까지 읽어봤더니, 블록 세 개짜리 문제 하나에 다섯 페이지에 달하는 알쏭달쏭한 영어 중얼거림이 이어졌다. 요즘 프런티어 모델들이 사고 흔적을 더 이상 사용자에게 보여주지 않는 이유 중 하나는 남들이 그걸 베낄 수 있어서겠지만, 어쩌면 그 흔적 자체가 별다른 의미를 갖지 않는다는 걸 알고 있어서일 수도 있다.

이걸 제대로 검증하려면 그럴듯해 보이는 것과 실제로 정답으로 이어지는 것을 구분할 방법이 필요했다. 그래서 서로 다른 분포에서 생성한 30×30 크기의 미로 50만 개를 만들고, 각각을 A* 서치로 풀었다. A* 서치는 open list와 closed list라는 자료구조를 조작하는 과정이라, 이 조작 하나하나를 중간 추론 토큰으로 그대로 사용할 수 있었다. 이 데이터로 수십억 파라미터 규모의 트랜스포머를 SFT한 다음 RL을 얹었다. A* 서치 흔적이었기 때문에, 그 흔적 자체를 다시 A* 서치로 시뮬레이션해서 실제로 정답 경로로 이어지는지 확인할 수 있었다. 정답이 맞았던 경우들만 놓고 봐도, 그 흔적이 실제로 유효했던 경우는 대략 80%뿐이었다. 나머지 20%는 정답은 맞혔지만 흔적 자체는 그 정답으로 이어지지 않는, 말하자면 그럴듯하게 지어낸 이야기였다.

그래서 같은 50만 개 데이터셋에서 문제 쌍을 골라 흔적을 서로 바꿔치기하는 실험을 해봤다. 문제 1의 정답에 문제 2의 흔적을 붙이고, 문제 2의 정답에 문제 1의 흔적을 붙이는 식이다. 문법적으로는 여전히 그럴듯한데 내용은 완전히 틀린 흔적이 된다. 성능이 나빠질 거라 예상했는데, 놀랍게도 전혀 나빠지지 않았다. 오히려 정답 흔적으로 학습한 모델보다 아웃오브디스트리뷰션 일반화 성능이 더 좋았다. 이게 놀랍게 느껴진다면, 그건 애초에 흔적이 어떤 의미를 담고 있어야 한다고 전제했기 때문일 뿐이다. 트랜스포머 다섯 개를 각각 정답 흔적 100%, 그리고 25%, 50%, 75%를 뒤섞은 흔적으로 학습시켜봤더니, 흔적의 유효성(trace validity)은 뒤섞은 비율이 늘어날수록 단조롭게 떨어졌지만, 실제 정답률은 U자 곡선을 그렸다. 완전히 정확한 흔적일 때도 높고, 완전히 틀린 흔적일 때도 다시 높았고, 중간 어딘가에서만 나빴다. RL을 얹어봐도 흔적의 유효성 자체는 거의 바뀌지 않았고, 오직 정답률만 올라갔다.

또 하나 눈에 띄었던 건 중간 토큰의 길이였다. 30×30 미로로 학습한 모델에게 장애물이 하나도 없는 텅 빈 미로를 줘봤다. A* 서치라면 즉시 풀 만큼 사소한 문제인데, 이 모델은 오히려 엄청난 양의 중간 토큰을 쏟아내고도 경로를 제대로 찾지 못했다. A* 서치 흔적의 실제 길이 — 그 문제 인스턴스의 계산적 난이도에 가까운 지표 — 를 x축에, 모델이 실제로 생성한 토큰 수를 y축에 놓고 산점도를 그려봐도 깨끗한 선형 관계가 전혀 없었다. 쉬운 문제인데 토큰을 많이 쓰는 경우도 있고, 어려운 문제인데 적게 쓰는 경우도 있었다. 중간 토큰의 길이는 문제의 계산적 난이도보다는, 그 문제가 학습 데이터에서 본 것과 얼마나 가까운지에 훨씬 더 좌우되고 있었다. 이 흐름을 이어받아 학생 한 명이 최근 발표한 마스크드 디스틸레이션(masked distillation) 연구도 같은 결을 보여준다. 중간 토큰 수를 줄이는 게 목표라면, 정답 토큰만 보여주고 추론 토큰은 가리는 식으로 학습시켜서 더 적은 토큰으로도 같은 결론에 도달하게 만들 수 있다. 이건 결국 계산을 더 많이 암기해버리는 것에 가깝고, 실제로 이렇게 압축된 모델은 아웃오브디스트리뷰션 성능이 더 나빴다. 일부 벤더들이 중간 토큰에도 요금을 매기기 시작하면서 토큰 수를 줄이는 논문들이 쏟아지고 있는데, 그 결과를 볼 때는 이 점을 염두에 둬야 한다.

마지막으로 짚고 싶은 건 이게 그저 학술적인 흥밋거리가 아니라는 점이다. 실제로 사람들을 대상으로 실험을 해봤다. 문제에 대한 답을 정말 모르는 사람들에게 LLM의 사고 흔적, 혹은 그 요약본을 보여주고 얼마나 신뢰하는지 물었다. 사고 흔적을 보여줬을 때 사람들은 — 아마 우리 모두가 가진 인지적 결함 때문에 — 더 신뢰하는 경향을 보였고, 그 신뢰는 실제 정답 여부와 무관하게 커졌다. 강력한 시스템이 우리의 이런 인지적 약점을 이용하게 두는 건 좋은 일이 아니다. 게다가 에이전틱 시스템에서는 사고 흔적 사이사이에 실제로 의미를 가져야 하는 도구 호출(tool call)이 끼어 있다. 그 호출과 결과는 진짜 의미를 갖고, 일단 도구를 호출하고 나면 그건 되돌릴 수 없는 확정된 결정이 된다. 그러니까 모든 중간 토큰이 똑같이 무의미한 것도 아니다. 어떤 부분은 그저 모델이 자기 자신에게 하는 중얼거림이고, 어떤 부분은 실제로 세상과 맞닿아 있다. 이 둘을 구분하지 못하고 사고 흔적 전체가 어떤 의미를 담고 있다고 전제한 채 시스템을 설계하면, 결국 곤란해진다.

정리하면 이렇다. LLM 홀로는 플랜의 정확성을 보장할 수 없다. 생성과 검증을 테스트 시점에 반복해서 정확도를 끌어올릴 수도 있고, 그 반복 과정을 학습 단계로 옮겨서 검증자의 신호를 모델 가중치 안에 미리 컴파일해둘 수도 있다. 다만 후자로 만든 모델은 더 나은 생성기가 될 뿐, 정답이라는 보장은 여전히 없다. 보장이 필요하다면 결국 다시 검증자를 루프 안에 넣어야 한다. 그리고 중간 토큰들은 어떤 고유하고 필연적인 의미를 가질 필요가 없다. 사고 흔적이 어떤 의미를 가진다는 전제 위에 시스템 전체를 쌓아 올리면 곤란해진다는 게 내가 하고 싶은 말이었다.

갈릴레오가 태양이 아니라 지구가 돈다고 말했을 때, 그 말이 우리가 매일 쬐는 햇빛을 바꾸지는 않았다. 하지만 그 이해는 우리가 그 지식을 가지고 무엇을 더 할 수 있는지, 어떻게 더 합리적인 판단을 내릴 수 있는지를 바꿔놓았다. 나는 추론 모델에 대한 이 모든 이야기도 결국 그런 자리에 가 닿기를 바란다. 무엇이 작동하는지는 이미 잘 알려져 있다. 내가 하고 싶었던 건, 왜 작동하는지를 조금 더 정직하게 들여다보는 일이었다.