
왜 '단계별로 생각하게' 하면 똑똑해지는가: Chain-of-Thought의 메커니즘과 그 설명을 믿지 말아야 하는 이유
요약
Chain-of-Thought(CoT) 기법이 왜 효과적인지, 그리고 왜 그 출력 과정을 완전히 신뢰하기 어려운지에 대한 메커니즘을 분석합니다. LLM이 루프 구조가 없는 '직관 기계'로서 작동하는 한계를 설명하며, 순차적 처리가 필요한 문제에서 발생하는 오류의 원인을 다룹니다.
핵심 포인트
- LLM은 계산기가 아닌 패턴을 인식하는 '직관 기계'에 가깝다
- Transformer 구조상 입력에 관계없이 레이어 통과 횟수는 일정하다
- CoT는 부족한 연산 자원을 토큰 생성 단계로 분산시키는 전략이다
- 순차적 처리가 필수적인 복잡한 계산에서 LLM은 근본적 한계를 가진다
이전까지 총 10회와 외전편으로 'LLM의 실패 모드'를 계속 다루어 왔습니다. 포초멕킨 이해(Pochomkin understanding), Lost in the Middle, Context Rot, 아첨(迎合), Instruction Drift... 요컨대 'AI는 왜 실패하는가'에 대한 도감입니다.
이번부터 시작할 것은 그 이면에 해당하는 연재입니다.
테마는 '대표적인 프롬프트 엔지니어링 기법은 왜 효과적이며, 어디서 무너지는가'입니다.
이전 연재를 쓰면서 계속 마음에 걸리던 것이 있었습니다. 실패 모드 이야기만 해왔지만, 애초에 모두가 매일 사용하는 그 기술 자체를 메커니즘 수준으로 설명한 적이 한 번도 없었습니다. '단계별로 생각하게'라고 쓰면 정확도가 올라간다는 것은 누구나 경험적으로 알고 있습니다. 하지만 '왜?'라는 질문에 답할 수 있는 사람은 의외로 적지 않을까요?
그래서 첫 회차는 아마도 세계에서 가장 많이 사용된 프롬프트 기술인 **Chain-of-Thought(사고의 연쇄, CoT)**부터 시작하겠습니다.
그리고 이 기사의 후반부는 아마 읽으면서 기분 좋은 이야기는 아닐 것입니다. '효과적인 이유'를 파고들다 보면 필연적으로 '그 출력을 신뢰해도 될 근거가 없다'는 결론에 도달하기 때문입니다. 제1회 포초멕킨 이해의 속편이 됩니다.
바로 전제부터 무너뜨리겠습니다.
CoT 설명에서 자주 '모델에게 생각할 시간을 준다'라는 표현을 쓰지만, 이것을 이해하려면 애초에 AI가 무엇을 어느 정도까지 '생각하지 않고' 답변하고 있는지를 알아야 합니다.
그리고 많은 사람이 오해하는 부분이 바로 여기입니다. 저도 처음에는 그랬습니다.
AI는 계산이 엄청 빠르니까, 암산은 잘할 것 아닌가?
정반대입니다. LLM은 계산기가 아니라, **직관 기계(直感マシン)**입니다.
계산기가 곱셈을 할 수 있는 것은 내부적으로 '올림을 자릿수만큼 반복하는' 루프 구조를 가지고 있기 때문입니다. 어려운 문제라면 그만큼 많이 돌아갑니다.
그런데 Transformer에는, 이 루프가 없습니다.
하나의 토큰(≒단어 조각)을 출력할 때, 입력은 정해진 수의 레이어를 단 한 번만 통과하고 끝납니다. 문제가 어렵든 쉽든, 통과하는 레이어 수는 늘어나지 않습니다.
인간으로 치면 이런 제약입니다.
어떤 문제든 생각할 수 있는 시간은 일률적으로 3초. 연장은 허용되지 않습니다.
이 '3초'로 풀 수 있는 것만이 AI가 즉답할 수 있는 범위입니다.
① 암기만으로 가능한 것
'프랑스의 수도는?', '7×8은?' — 이것은 계산하는 것이 아니라, 정답을 기억하고 있을 뿐입니다. 구구단을 읊는 초등학생과 같아서, 학습 데이터에 수만 번이나 등장한 패턴을 그대로 끌어내고 있는 것입니다.
두 자릿수 × 한 자릿수 정도까지의 계산이 정답인 것은 계산력이 아니라 기억력입니다. 여기는 은근히 중요하므로 나중에 다시 언급됩니다.
② 한눈에 파악할 수 있는 얕은 처리
수십 레이어의 통과는 일단 '수십 스텝 분량의 병렬 처리'이므로, 짧은 변환이나 대조는 이 안에서 완료됩니다.
바둑 기사가 판을 휙 보고 '이 수가 좋아 보인다'라고 아는 그 감각과 가깝습니다. 그것도 계산이 아니라 패턴 인식입니다.
무너지는 것은, 입력에 따라 반복 횟수가 변하는 처리입니다.
세 자릿수 × 세 자릿수의 곱셈을 생각해 보세요. 올림을 자릿수만큼 순서대로 처리할 필요가 있습니다. 앞자리 결과가 나오지 않으면 다음 자리로 진행할 수 없습니다. 이것은 전형적인 순차 처리(逐次処理)입니다.
이것은 '한눈에' 원리적으로 들어맞지 않습니다. 그래서 자릿수가 늘어나면 어느 지점부터 갑자기 틀리기 시작합니다.
기사도 '이 국면에서 27수 앞의 체크메이트를 한눈에 읽어라'는 불가능하고, 거기부터는 한 수씩 읽는다 = 순차 처리할 수밖에 없습니다. 그것과 같습니다.
| 종류 | 예시 | 즉답 가능 여부 |
|---|---|---|
| 암기된 사실 | 수도 이름, 구구단, 정형화된 정의 | ○ |
| ... | ||
| 여기까지 오면, CoT가 무엇을 하는지는 한마디로 말할 수 있습니다. |
CoT는 AI를 똑똑하게 만드는 기술이 아닙니다. '암산 제약'을 해제하는 기술입니다.
중간 과정을 쓰게 하면, 모델은 자신이 방금 쓴 중간 과정을 보면서 다음 것을 쓸 수 있게 됩니다. 인간이 필산으로 '올림의 3을 메모하고, 그것을 보면서 다음 자릿수를 계산하는' 것과 완전히 같은 구조입니다.
쓴 것이 외부 메모리가 되는 것입니다.
1토큰당 계산량은 3초로 변하지 않았습니다. 바뀐 것은, 3초를 몇 번 사용할 수 있느냐입니다. 계산기가 내부에 가지고 있는 루프를, AI는 종이 위에 만들 수밖에 없습니다. **루프의 외부화(外付け)**입니다.
이것을 처음으로 대규모로 보여준 것이 CoT의 원 논문에 해당하는 Wei et al. (2022) 입니다.
산수 문장제 벤치마크인 GSM8K에서, PaLM 540B의 정답률이 표준적인 프롬프트(Prompt)를 사용했을 때 약 18%에서 CoT를 사용하자 약 57%까지 뛰어올랐습니다. 3배 이상입니다. 프롬프트 작성 방식을 바꾼 것만으로 말이죠.
더욱 흥미로운 점은, 이 효과가 모델의 규모가 특정 임계치(Threshold)를 넘어서야 비로소 나타난다는 것(창발적(Emergent)이라는 것)입니다. 작은 모델에서는 단계 사이의 논리적인 의존 관계를 제대로 전파하지 못해, 유창하기만 할 뿐 인과 관계가 없는 '그럴싸한 추론 흉내'만을 써 내려갑니다.
종이를 건네받아도 필산(세로셈) 방법을 모른다면 의미가 없는 것과 같습니다.
여기서 많은 사람이 의문을 가질 법한 지점이 있습니다.
"'단계별로 생각해'라는 건, 지시로서 너무 모호하지 않아?"
"어떤 절차로 생각하라고 말한 것도 아닌데, 왜 효과가 있는 거야?"
모호합니다. 그리고 흥미로운 점은, 모호한데도 효과가 있다는 것입니다.
이 자체가 큰 힌트인데, 이 지시는 모델에게 절차를 가르치는 것이 아닙니다. 출력하는 문장의 장르(Genre)를 전환하고 있는 것뿐입니다.
학생은 '중간 식을 쓰는 알고리즘'을 배운 것이 아닙니다. 하지만 참고서에서 중간 식이 포함된 모범 답안을 수천 번 보았습니다. 그래서 그 장르의 문장을 재현할 수 있는 것입니다.
모델도 마찬가지로, 학습 데이터 안에 있는 '해설이 포함된 답안'이라는 문체를 불러오고 있을 뿐입니다. 따라서 지시의 정밀함은 필요하지 않습니다. 장르의 스위치이기 때문입니다.
본질은 말투가 아니라, "정답보다 먼저, 중간 과정의 토큰(Token)을 뱉게 하는 것"입니다. 그러한 현상이 일어나는 지시라면 대체로 무엇이든 효과가 있습니다.
실제로 Zero-Shot-CoT를 제안한 Kojima et al. (2022)은 "Let's think step by step" 이외의 표현들도 비교하였는데, 약간의 성능 차이는 있을지언정 모두 '즉답하게 하는 것'보다는 낫다는 결과가 나왔습니다.
마법의 주문이 있는 것이 아니다, 라는 것이 첫 번째 실무적인 결론입니다.
여기서 도출되는 흥미로운 귀결이 있습니다.
❌ 한마디로 답해줘
❌ 예/아니오로만 답해줘
❌ 결론만, 간결하게
이것들은 처음 나오는 토큰이 정답 그 자체가 되도록 유도합니다. 즉, 3초간의 직관을 그대로 출력하게 만드는 상태입니다. '암산 제약'을 최대한으로 강화하는 셈입니다.
역으로 말하면, CoT가 효과가 있는지 여부는 '단계별로(step-by-step)'라는 단어가 들어있는가보다, 정답 앞에 얼마나 많은 토큰을 뱉게 하는가에 달려 있습니다.
극단적인 실험: 의미 없는 "......"도 효과가 있는 경우
필러 토큰(Filler token)이라 불리는 연구 영역이 있는데, "......"와 같이 의미를 가지지 않는 토큰을 끼워 넣는 것만으로도 모델의 성능이 올라가는 경우가 있다고 보고되었습니다.
다만 여기에는 중요한 한계가 있습니다. 필러 토큰이 늘리는 것은 병렬적인 계산이지, CoT와 같은 순차적인 계산이 아닙니다. 인간으로 치면 '답하기 전에 3초간 침묵할 시간을 주는 것' 정도의 효과입니다.
침묵은 다시 볼 수 없지만, 적어놓은 메모는 다시 볼 수 있습니다. 이 차이는 매우 큽니다.
그럼에도 불구하고, 이 일련의 연구들은 불온한 질문을 던집니다. CoT 효과 중 얼마만큼이 '인간적인 단계적 추론'이며, 얼마만큼이 '의미 없는 단순 추가 계산'인가?
이 질문은 다음 장 이후에서 더욱 까다로운 형태로 돌아옵니다.
자, 실무에서 CoT를 사용하는 사람이라면 분명 이것을 경험했을 것입니다.
단계별로 진행하게 시켰더니, 도중에 "아, 이 단계도 필요했구나"라는 상황이 벌어집니다.
하지만 그거, 제대로 말해주지 않지 않나요?
이것은 CoT의 구조상 필연적으로 발생하는 현상입니다. 게다가 두 가지 상반되어 보이는 증상이 하나의 같은 뿌리에서 자라나고 있습니다.
CoT는 인간이 에세이를 쓸 때처럼 "먼저 구성을 정하고, 각 단락을 채운 뒤, 마지막에 퇴고하는" 방식으로 쓰지 않습니다.
토큰을 하나씩, 되돌아가지 않고 앞으로 나아가며 써 내려갑니다.
따라서 도중에 "아, 처음에 저 단계를 넣었어야 했는데"라고 깨닫더라도, 이미 써 내려간 부분을 다시 쓸 수 없습니다. 문장을 거슬러 올라가 편집하는 능력이 애초에 존재하지 않기 때문입니다.
이 제약으로부터 두 가지 증상이 나타납니다.
깨달은 시점에 "아, 사실 처음부터 그럴 생각이었어요"라는 표정을 지으며, 추가 단계를 슬쩍 끼워 넣습니다. 읽는 사람 입장에서는 처음부터 계획대로였던 것처럼 보이지만, 실제로는 그 자리에서 임기응변식으로 덧붙이고 있는 것입니다.
인간으로 비유하자면, 레포트를 쓰다가 세 번째 단락쯤에서 "어라, 이 로직이 무너졌네"라고 깨달았는데, 첫 페이지로 돌아가서 다시 쓸 시간이 없어서 그 자리에서 그럴싸하게 수습하며 진행하는 느낌입니다. 독자는 그 이음새를 눈치채지 못합니다.
(참고로, 확장 사고 모드와 같은 "심사숙고형" 모델의 경우, "잠깐, 방금 전의 전제가 틀렸어"라고 명시적으로 쓰기도 합니다. 이는 솔직한 편에 속합니다. 다만, 일반적인 CoT 프롬프트에서는 증상 ①이 더 일어나기 쉽습니다.)
더 까다로운 것은 이것입니다.
"먼저 절차를 써 내려가고, 그에 따라 진행해"라고 지시하면, 실행 도중에 심층적으로 파고들어야 할 새로운 사실이 나타나도 계획대로 진행하는 것만 생각합니다.
에이전트 설계 문맥에서는 이것이 이미 알려진 실패 패턴으로 논의되고 있습니다. "Plan-and-Execute"형 아키텍처에서는 한 번 계획이 결정되면 그대로 따르기 때문에, 초기 계획에 결함이 있고 재계획(replanning) 메커니즘이 없다면, 확신을 가지고 잘못된 길을 끝까지 달려 나갑니다.
나아가 에이전트 평가에 있어서는 "계획의 질"과 "계획에 대한 충실도 (faithfulness to the plan)"를 별개의 지표로 측정해야 한다는 정리도 있습니다. 계획은 좋지만 실행 중에 탈선하는 에이전트와, 계획은 나쁘지만 그것에 충실하게 따라가서 잘못된 답에 도달하는 에이전트는, 서로 다른 방식으로 고장 난 것입니다.
증상①: 답을 쓰는 도중에 새로운 사실 발견 → 전반부는 다시 쓸 수 없음 → 후반부에서 앞뒤를 맞춤
증상②: 계획을 작성한 후에 새로운 사실 발견 → 계획을 다시 쓰지 않음 → 실행 단계에서 앞뒤를 맞춤
통일된 원리는 이렇습니다.
이미 쓴 것은 움직일 수 없다. 따라서 쓴 이후에 발생하는 모든 일은 그것과 모순되지 않도록 처리된다.
SIer(시스템 통합 사업자)식으로 말하자면
요구사항 정의서를 먼저 확정하고 그것을 보면서 구현하는 폭포수(Waterfall)형 프로젝트에서, 구현 중에 "이 사양, 사실 전제가 무너졌는데"라고 깨달아도, 요구사항 정의서로 돌아가서 수정하는 것이 아니라, 그 자리에서 흡수할 수 있는 범위 내에서 구현에 밀어 넣거나 묵묵히 진행합니다.
그것과 구조가 같습니다. 요구사항 정의서가 "이미 작성된 것"으로서 신성시되어, 거기에 손을 댄다는 발상 자체가 나오기 어려워지는 것입니다.
AI도 똑같은 일을 합니다. 게다가 AI의 경우, 죄책감조차 발생하지 않기 때문에 더욱 철저합니다.
이 지점이 본 기사의 핵심이자, 포초름킨 이해(Potemkin understanding)와의 연결점입니다.
앞 장의 이야기를 한 단계 더 추상화해 보겠습니다.
CoT의 출력은 "그럴싸한 추론의 이야기"일 뿐, "실제 판단 과정의 기록"이라는 보장이 없습니다.
이는 연구 분야에서 CoT의 충실성 (faithfulness) 문제라고 불리며, 상당히 엄격한 결과들이 나오고 있습니다.
Turpin et al. (2023)의 실험입니다.
다지선다형 문제의 선택지 순서를 조작하여 정답이 항상 (A)가 되도록 편향(bias)을 심어둡니다. 그러면 모델은 명백히 그 영향을 받아 답을 바꾸면서도, CoT 설명에서는 그 사실에 대해 일절 언급하지 않고, 틀린 답을 정당화하는 추론을 당당하게 생성했습니다.
나아가 사회적 편향을 다루는 태스크에서는 스테레오타입에 따른 답변을 해놓고도, 그 이유를 스테레오타입에 언급하지 않은 채 "정당화"해 버립니다.
논문의 결론은 단호합니다. CoT의 설명은 그럴싸하지만, 체계적으로 불성실할 수 있다.
Anthropic의 2025년 연구에서는 더욱 직접적인 검증이 이루어졌습니다.
문제문에 몰래 정답의 힌트를 섞어 넣고, 모델이 "힌트를 사용했습니다"라고 답안에 쓰는지 조사합니다. 학생에게 시험 전에 "정답은 (A)야"라는 메모를 건네주고, 답안에 "메모를 보았기 때문에 (A)로 했습니다"라고 쓰는지 확인하는 것과 같습니다.
결과적으로 모델은 명확하게 힌트를 사용하고 있음에도 (힌트의 답으로 변경하는 비율이 유의미하게 높음에도), 그것을 언어화하는 비율, 즉 충실성 점수는 **Claude 3.7 Sonnet에서 25%, DeepSeek R1에서 39%**에 그쳤습니다.
즉, 7할 전후의 케이스에서 실제 판단 근거를 답안에 적지 않고 있다는 뜻입니다.
심지어 이것은 이른바 "추론 모델"에서의 수치입니다. 비추론 모델보다는 충실성이 높지만, 그럼에도 이 수준입니다. 게다가 보상을 목적으로 한 강화학습을 계속해도 충실성은 조기에 한계에 부딪히며 포화되지 않는다는 결과도 나왔습니다.
포초름킨 이해에서 다루고자 했던 내용이 바로 이런 이야기였습니다.
설명할 수 있다는 것과, 그 설명이 실제 판단 근거라는 것은 별개의 문제입니다.
CoT는 이 문제를 해결하기는커녕, 더 설득력 있는 형태로 악화시킵니다. 왜냐하면 정중한 추론 단계(reasoning steps)가 나열되어 있으면, 인간은 이를 '제대로 생각한 결과다'라고 믿어버리기 때문입니다.
전장에서 다룬 '쓴 것은 되돌릴 수 없다'를 떠올려 보십시오. 답의 방향이 먼저 결정되어 버리면, 이후의 문장은 그것과 모순되지 않도록 작성됩니다. CoT의 불성실함은 버그가 아니라, 단번에 써 내려가는(one-shot writing) 구조에서 비롯되는 자연스러운 귀결입니다.
지금까지 'CoT의 설명은 신뢰할 수 없다'는 이야기를 해왔지만, 애초에 정확도 자체가 떨어지는 상황도 있습니다.
Liu et al. (2024)의 「Mind Your Step (by Step)」이라는 연구는 흥미로운 접근 방식을 취하고 있습니다. 인간이 숙고하면 오히려 성적이 떨어지는 태스크를 인지심리학 문헌에서 가져와 모델에게 수행하게 했습니다.
그 결과, 몇몇 태스크에서는 CoT를 사용할 경우 모델의 성능이 최대 36.3포인트 하락했습니다.
구체적으로 하락한 분야는 다음과 같습니다:
암묵적 통계 학습 (언어화할 수 없는 패턴을 감각적으로 파악하는 태스크)
시각적 인식
예외를 포함한 패턴 분류
요컨대 "이론적으로 설명하려고 하면 오히려 직관이 깨지는 태스크"입니다. 인간도 자전거 타는 법을 언어화하려고 하면 오히려 못 타게 되는 것과 같은 현상이 있죠. 그것과 같은 유형입니다.
그리고 대규모 메타 연구에서는 CoT가 명확하게 효과를 발휘하는 영역은 주로 수학·기호 추론 영역이라고 정리되기도 했습니다.
| CoT가 효과적인 경우 | CoT가 효과적이지 않거나/역효과가 나는 경우 |
|---|---|
| 다단계 산술·수식 처리 | 감각적인 패턴 인식 |
| ... |
"일단 단계별로(step-by-step)"는 만능약이 아니다라는 것이 두 번째 실무적 결론입니다.
지금까지의 이야기를 바탕으로, 대처법 4가지를 약한 순서대로 나열하겠습니다.
먼저, 이 문제를 해결하기 위해 필요한 절차를 불렛 포인트로 작성해 주세요.
그 후에, 그 절차에 따라 실행해 주세요.
효과적인 이유: '단번에 써 내려가며 되돌릴 수 없다'는 제약 자체를 해결하지는 못하지만, 되돌릴 수 없게 되는 타이밍을 늦출 수 있습니다.
갑자기 풀기 시작하면, 쓰면서 깨달은 누락 사항을 임기응변으로 메워야만 합니다. 하지만 먼저 '필요한 절차가 무엇인가'만을 작성하게 하면, 그 시점에서 전체를 조망한 상태로 절차 리스트가 확정됩니다. 절차 리스트 자체는 짧기 때문에, 쓰면서 놓칠 확률도 낮아집니다.
갑자기 본문을 쓰기 시작하는 것이 아니라, 먼저 아웃라인을 잡고 나서 쓰는 것과 같습니다.
약점: 계획 자체도 단번에 써 내려가는 것이므로 만능은 아닙니다. 그리고 무엇보다, 증상 ②(계획에 대한 집착)를 악화시킬 리스크가 있습니다.
하나의 생성이 끝난 후, 새로운 턴(turn)으로 다시 던집니다.
위의 해답을, 처음 읽는 제삼자의 입장에서 리뷰해 주세요.
누락, 모순, 검증되지 않은 전제를 지적해 주세요.
효과적인 이유: 1회차 생성은 '쓰면서 앞을 내다볼 수 없는' 상태였습니다. 2회차 생성은 완성된 문장을 처음부터 끝까지 읽을 수 있는 상태입니다.
장기(shogi)로 비유하자면, 대국 중에는 눈앞의 국면밖에 보이지 않지만, 복기(感想戦) 시에는 판 전체를 조망하며 악수를 지적할 수 있는 것과 같은 차이입니다.
약점: 이것은 상당히 위험합니다. 2회차 생성 또한 단번에 써 내려가는 것이므로, 1회차의 답을 정당화하는 새로운 그럴듯한 논리를 생성하는 것에 그칠 수 있습니다. '임기응변을 임기응변으로 메우는' 구조입니다.
이것은 제가 실무에서 사용하는 방법입니다. 2~3단계마다 다음과 같이 끼워 넣습니다.
아직 더 깊이 파고들 수 있을 것입니다.
효과적인 이유: 제4회·영합(Sycophancy)에서 다루었듯이, 모델에게는 '사용자가 제시했거나 암시한 신념에 부합하는 응답을 생성하는' 강한 경향이 있습니다.
핵ポイント는, 영합의 대상을 비워두는 것입니다.
"X가 정답이지?"라고 말하면, 모델은 틀린 X에 영합합니다. 이것이 평소 영합의 해악입니다. 하지만 "더 깊이 파고들 수 있을 거야"는 구체적인 결론을 일절 지정하지 않았습니다. 방향성 압력(direction pressure)만을 주고 있는 것입니다.
영합할 대상에 함정이 마련되어 있지 않기 때문에, 모델의 영합 드라이브는 "실제로 한 단계 더 파고드는" 행동으로만 발산될 수 있습니다. 잘못된 합의가 아니라, 노력의 형태로만 영합할 수 있도록 유도하는 것입니다.
| 질문 방식 | 모델에게 가장 비용이 낮은 영합(迎合) |
|---|---|
| "이 계획이 맞나요?" | "네, 맞습니다" (=날로 먹기) |
| "더 깊이 파고들 수 있잖아요" | 실제로 한 단계 더 파고듦 (=노력) |
유도 질문이라는 점은 같습니다. 차이점은 유도의 방향을 날로 먹는 방향이 아니라 심층 분석 방향으로 걸고 있다는 것입니다.
그리고 이는 증상 ②(계획에 대한 집착)에 대한 대처도 됩니다. 에이전트 설계에서는 "실행→재계획→실행" 루프를 아키텍처에 내장함으로써 대응하지만, 이는 그것을 대화 턴(turn)에서 수동으로 구현하고 있는 것과 같습니다. 모델 내부에 "계획을 의심할 타이밍"은 생기지 않으므로, 외부에서 강제적으로 주입하는 것입니다.
약점: 정말로 더 파고들 곳이 없는 상황에서도, 영합 드라이브(迎合 drive)가 작동하여 "그럴싸한 추가 논점을 짜내는" 리스크가 있습니다. 영합 연구에서는 올바른 방향으로 이끄는 영합과 오류로 이끄는 영합을 구분하지만, 100% 전자가 될 것이라는 보장은 없습니다.
이것이 현재 제가 알고 있는 방법 중 가장 강력한 수입니다.
할 일: 프로그램이라면 분기 커버리지(Branch Coverage) 플로우를 작성하게 합니다. 확인한 분기는 초록색, 확인하지 않은 분기는 빨간색으로 칠하게 합니다.
🟩 초록색 = 분석 완료 🟥 빨간색 = 미분석
왜 이것이 결정적으로 강력한가. 대처 ③인 "더 깊이 파고들어라"는 아직 **열린 질문(open question)**이었습니다. 어디까지 파고들어야 하는지, 파고들기가 끝났는지, 누구도 판정 기준이 없습니다.
하지만 분기 커버리지 플로우는 이를 **닫힌 집합(closed set)**으로 변환합니다. 프로그램의 분기는 유한하며, 셀 수 있습니다. "전부 칠해라"는 "올바르게 분석하라"는 모호한 요구가 아니라, "이 유한한 리스트를 전부 소화하라"는 체크리스트가 됩니다.
LLM 평가 연구에서도 주관적인 기준을 단일 스코어로 판정하게 하는 것보다, 이진(yes/no) 질문으로 분해하는 것이 평가의 신뢰성, 재현성, 인간의 판단과의 일치도를 크게 향상시킨다는 것이 확인되었습니다. "좋다/나쁘다"보다 "이것이 포함되어 있는가?"가 판정하는 쪽의 부하가 차원이 다르게 낮습니다.
그리고 가장 중요한 포인트는, 판정 대상이 바뀌었다는 점입니다.
| 질문 | 판정에 필요한 것 |
|---|---|
| "이 분기의 업무 로직 설명이 올바른가?" | 도메인 지식 (=가지고 있지 않은 경우가 있음) |
| "실제 코드에는 5개의 분기가 있는데, 그림에는 3개만 색이 칠해져 있다" | 숫자를 세는 능력뿐 |
분기의 존재 그 자체는 AI의 자기 보고가 아니라, 실제 코드에서 기계적으로 도출할 수 있는 외부의 정답입니다. 따라서 AI의 주장을 AI와 독립적으로 존재하는 구조와 대조할 수 있습니다.
COBOL→Java 전환 현장에서 수행하는 분기 커버리지율·회귀 테스트(Regression Test)의 사고방식 그 자체입니다.
그림이 너무 커지는 경우에는 리스트 형식으로도 동일한 작업을 할 수 있습니다. 중요한 것은 겉모습이 아니라, 미소화된 항목이 반드시 한 줄로 남는 형식이 되어 있다는 것입니다.
+ [완료] 법인 요율 분기 확인
+ [완료] 계속 할인 임계값(3년) 확인
- [미완료] 지자체 구분 요율 테이블 미확인
...
"확인하지 않음"이 말없이 사라지지 않게 하는 것. 이것이 대처 ③까지의 방식과의 결정적인 차이입니다.
자, 여기서 솔직하게 써야 할 것이 있습니다.
대처 ①~④는 AI 출력의 질을 높이는 기술입니다. 인간의 검증 능력의 한계를 해결하는 기술이 아닙니다.
그리고 이 구분은 실무에서 치명적으로 작용합니다.
생각해 보십시오. 우리가 AI에게 심층 분석을 부탁하는 이유는 대부분 자신에게 그 지식이 없기 때문입니다.
COBOL의 오래된 업무 로직 중에서, 자기 자신이 사양의 배경을 모르는 부분이 있습니다. 그래서 AI에게 "이 에지 케이스(edge case), 더 깊이 파고들어 줘"라고 던집니다. AI는 자신만만하게 상세한 분석을 돌려줍니다.
하지만——그것이 정말로 올바른 업무 지식에 기반한 것인지, 아니면 그럴싸한 이야기를 짜 맞춘 것인지, 판정할 재료가 자신에게 없습니다.
AI에게 물어볼 이유가 있는 상황일수록, AI의 답을 검증할 수 없다. 이것이 구조적인 함정입니다.
이는 AI 안전성 연구에서 **스케일러블 오버사이트(Scalable Oversight)**라고 불리는, 이 분야의 핵심적인 미해결 문제입니다. AI가 복잡한 태스크에서 인간의 능력을 넘어서게 되면, 인간은 그 출력이 옳은지 쉽게 판단할 수 없게 됩니다. 그럴듯하지만 미묘하게 틀린 추론을, 리뷰하는 인간이 아무도 찾아내지 못하는 상황이 발생합니다.
그리고 잔혹하게도, 대응①②③이 만들어내는 것은 전부 “더 길고, 더 구조화되었으며, 더 자신감 있는 출력”입니다. 판단 자료가 없는 인간에게 그것들은 ‘정확성’의 대리 지표조차 되지 못합니다. 오히려 설득력만 증가시킵니다.
제1회 포청킨 이해(그럴듯한 설명과 실제 판단 근거는 별개)가, 있는 그대로 인간 측의 감사 능력에도 유전되어 버리는 것입니다.
‘미해결 문제’라고 하면 ‘그럼 연구자들은 뭘 하고 있는 걸까?’라고 생각하죠. 저도 그렇게 생각해서 알아봤습니다.
2018년에 제안된 가장 유력한 후보가 **Debate(토론)**입니다. 두 개의 AI에게 반대 입장에서 토론하게 하고, 인간이 판정하는 방식입니다. 핵심적인 발상은 ‘거짓말을 하는 것보다, 거짓말을 논파하는 것이 더 쉬울 것이다’라는 것입니다. 이론적으로는 상당히 아름다운 제안이었습니다.
이것을 대규모로 실증 검증한 것이 DeepMind의 Kenton et al. (2024)(NeurIPS 2024)입니다. 판정자 역할에 약한 모델, 토론자 역할에 강한 모델을 배치하여 여러 태스크에서 검증했습니다.
결론은, 솔직히 말해서 상당히 평범합니다.
- ✅ 토론 방식은 AI가 일방적으로 설득하려는 방식(Consultancy)보다
일관되게 우수합니다. - ⚠️ 하지만 본론인 ‘토론이 AI 없이 인간이 직접 판단하는 것보다 우수한가’는,
태스크에 따라 결과가 갈렸습니다. 정보의 비대칭성이 있는 추출형 QA에서는 우위지만, 그 외에서는 효과가 들쭉날쭉합니다. - ⚠️ 더 강한 모델을 토론자로 사용하면 판정 정확도는 올라가지만,
선행 연구의 기대보다 효과는 미미했습니다.
게다가 2026년의 후속 연구에서는 더 가혹한 지적이 나오고 있습니다. 토론 방식으로 좋은 결과가 나온 케이스의 대부분은, 판정자가 일부러 참고 자료 접근을 차단당한, 인위적인 정보 비대칭성이 있는 설정에 치우쳐 있다는 것입니다. 그 인위적인 비대칭성을 제거하면, 토론은 단순한 직접 질의응답보다 성능이 떨어지는 경우마저 있습니다.
그리고 Debate의 원 논문 저자들 스스로가 처음부터 인정했던 것이 있습니다. ‘인간이 정말로 토론을 이해할 수 있는가’는 증명되지 않았으며, 미해결된 경험적 문제입니다, 라고요.
2018년에 ‘이것으로 해결될 것이다’라고 이론적으로 제안된 가장 유력한 후보를, 6년 동안 진지하게 검증했더니,
세팅된 조건에서만 효과가 확인되었습니다.
이것이, 2026년 시점의 솔직한 현재 위치입니다.
길어졌으니 정리하겠습니다.
메커니즘에 대한 이야기
- LLM은 계산기가 아니라 직관 머신(intuition machine)입니다. 토큰당 계산량은 고정되어 있습니다(=일률적으로 3초, 연장 불가).
- CoT는 AI를 똑똑하게 만드는 기술이 아니라,
암산의 제약을 해제하고, 루프를 종이 위에 외부에 붙이는 기술입니다. - ‘단계별로’가 모호한데도 효과가 있는 것은, 절차를 알려주는 것이 아니라
출력의 장르를 전환시키기 때문입니다. 그러니 표현 방식은 본질이 아니며, 답변 앞에 얼마나 많은 토큰을 흘려보내게 할지가 본질입니다.
무너지는 방식에 대한 이야기
- CoT는 한 번 쓰면 되돌릴 수 없습니다. 그래서 ‘
쓴 것은 바꿀 수 없다’는 제약으로부터, 나중에 억지로 맞추기(辻褄合わせ)와 계획 고착이 동시에 생겨납니다. - 그 결과, CoT의 설명은 ‘그럴듯한 이야기’일 뿐 ‘판단 근거 기록’이 아닙니다. 충실도 점수는 추론 모델에서도 25~39% 정도입니다. - 애초에 직관형 태스크에서는, CoT가
정확도 자체를 떨어뜨립니다(최대 36.3포인트).
대응책에 대한 이야기
- 계획 선출시(Planning), 자기 비판(Self-critique), 순응의 역이용은 유효하지만, 모두 같은 ‘한 번 쓰기’의 약점을 가집니다.
- 가장 강력한 것은,
열린 질문을 셀 수 있는 닫힌 집합으로 변환하는 것입니다. 분기 망 포괄 플로우(分岐網羅フロー)의 빨강/초록 시각화는 그 구현 예시로, 판정에 필요한 능력을 ‘도메인 지식’에서 ‘수를 세는 것’으로 낮출 수 있습니다.
그래도 남아있는 이야기
- 이들은 출력의 질을 높이지만,
인간 검증 능력의 한계는 해결하지 못합니다. AI에게 물어볼 이유가 있는 장면일수록, AI의 답을 검증할 수 없습니다 - 이것은 스케일러블 오버사이트(scalable oversight)라는 미해결 문제이며, 가장 유력한 후보인 Debate조차도, 실증 검증에서는 인위적인 조건 하에서만 우위를 보이고 있습니다.
제1회 포청킨 이해는 ‘설명할 수 있는 것이, 이해의 증명이 되지 않는다’는 이야기였습니다.
이번에는 그 연장선으로 이렇게 말할 수 있을 것 같습니다.
그럴듯해 보이는 것은, 검증된 것의 증명이 되지 않습니다.
그리고 인간에게는, 그것을 간파할 보장도 없습니다.
빨간색과 초록색으로 구분하여 색칠하는 것은, 그 거대한 문제에 대한 작지만 확실하게 효과적인 한 수입니다. 적어도 "어딘가에서 말없이 대충 처리되고 있다"는 불안감은 지울 수 있습니다. 그리고 불안을 지운 만큼, 한정된 검증 노력을 "각 분기(branch)의 내용이 정말로 올바른가"라는, 아직 인간이 감당할 수 있는 크기의 문제에 집중적으로 투입할 수 있습니다.
전부를 해결할 수는 없습니다. 하지만, **해결할 수 없는 부분이 어디인지를 가시화(visualize)**할 수는 있습니다. 현재로서는 그것이 가장 성실한 방법이라고 생각합니다.
다음 회차에서는 Few-shot 예시 설계 기법을 다룰 예정입니다. "예시(example)는 지시(instruction)보다 강력하다"는 성질은 이전 연재에서 다루었지만, 그렇다면 좋은 예시란 무엇인가, 몇 개가 최적인가, 나열하는 순서가 효과가 있는가를 살펴봅니다. 제2회에서 다룬 'Lost in the Middle'의 위치 효과(position effect)가 예시의 나열 순서에도 영향을 미치지 않을까 하는 가설도 함께 검증해 보겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기