Reasoning LLM이 긴 풀이를 쓴다고 곧바로 인간처럼 생각한다고 결론 내릴 수는 없습니다. 여기서 System 2는 모델의 의식을 뜻하기보다, 여러 경로를 탐색하고 결과를 검증하며 오류를 고치는 계산 방식을 설명하는 틀에 가깝습니다.
이 글은 설문 논문 From System 1 to System 2: A Survey of Reasoning Large Language Models에 소개된 발전 방향을 독자 관점에서 다시 묶습니다.
Reasoning LLM이 긴 중간 과정을 출력한다는 사실만으로 인간처럼 사고하거나 정답을 보증하는 것은 아닙니다. 문제 난도에 맞게 추가 계산을 쓰고 그 결과를 외부 검증으로 확인할 때만 느린 추론의 가치가 드러납니다.
논문이 빌려온 구분은 다음과 같습니다.
| 구분 | 처리 방식 | 대표 과제 | LLM에 대응한 목표 |
|---|---|---|---|
| System 1 | 빠른 직관과 패턴 인식 | 얼굴 인식, 단순 계산 | 즉시 다음 답을 생성 |
| System 2 | 분석, 계획, 다단계 검토 | 복잡한 수학, 전략 계획 | 탐색하고 검증한 뒤 답을 선택 |
이 구분을 모델 이름에 그대로 붙이면 오해하기 쉽습니다. 빠르게 맞힌 답도 실제로는 복잡한 패턴을 학습한 결과일 수 있고, 길게 쓴 풀이도 잘못된 전제를 반복할 수 있습니다. 따라서 추론 모델의 핵심 질문은 “몇 토큰을 썼는가”가 아니라 “대안을 만들고, 잘못된 경로를 버리고, 최종 결과를 검증했는가”입니다.
설문이 말하는 발전은 한 번의 직관적 생성에서 다음 과정으로 이동하는 것입니다.
1
2
3
4
5
6
문제 파악
→ 후보 풀이 생성
→ 경로별 검토
→ 오류 시 되돌리기
→ 보상 또는 검증으로 선택
→ 최종 답
이 과정이 항상 외부에 그대로 출력될 필요는 없습니다. 중요한 것은 답변 형식이 아니라 모델과 시스템이 실제로 선택, 검증 절차를 수행하는지입니다.
설문은 추론 능력을 높이는 접근을 다섯 가지로 정리합니다.
하나의 답을 끝까지 밀어붙이지 않고 여러 후보 경로를 만듭니다. Tree-of-Thought처럼 분기를 두거나, 잘못된 경로에서 되돌아가는 backtracking이 여기에 해당합니다. 장점은 첫 선택의 오류를 수정할 기회가 생긴다는 것이고, 한계는 탐색할 경로가 늘수록 계산도 늘어난다는 점입니다.
단순히 자연스러운 문장보다 올바른 단계와 결론에 높은 점수를 주도록 학습합니다. RLHF와 같은 보상 기반 접근을 사용할 수 있지만, 무엇을 “좋은 추론”으로 점수화하는지가 결과를 좌우합니다. 최종 답만 맞았는지와 중간 과정도 타당한지는 서로 다른 평가 기준입니다.
모델이 자신의 답을 비평하고, 여러 답안을 비교하고, 오류를 발견하면 다시 풉니다. self-criticism과 multi-path exploration이 대표적입니다. 다만 처음부터 오류를 알아볼 기준이 없다면 같은 실수를 다른 문장으로 반복할 수 있으므로, 자기 검토 자체를 정확성의 증거로 삼을 수는 없습니다.
Chain-of-Thought와 Tree-of-Thought처럼 복잡한 해결 과정을 재사용 가능한 큰 단계로 구성합니다. 모든 작은 토큰 선택을 즉흥적으로 처리하는 대신 “문제 분해”, “후보 비교”, “검산” 같은 동작 단위로 진행한다는 관점입니다.
수학, 코딩, 법률, 의료처럼 특정 분야의 추론 자료로 모델을 조정합니다. 쉬운 문제에서 어려운 문제로 난도를 올리거나 전문가 시연을 사용하는 방식이 소개됩니다. 분야별 미세 조정은 해당 분포에서의 능력을 높일 수 있지만, 다른 분야까지 같은 수준으로 일반화됐다는 증거는 별도로 필요합니다.
원문은 수학의 AIME, Olympiad Bench, 코딩의 Codeforces, SWE-Bench, 과학의 GPQA Diamond, MMLU-Pro, 멀티모달의 MMMU, MathVision, 에이전트의 WebShop, SciWorld 같은 평가 범주를 예로 듭니다.
기존 글에 있던 모델별 퍼센트 표는 “모든 수치는 예시”라고 명시돼 있었습니다. 검증된 실험 결과가 아닌 예시 숫자는 모델 비교 근거로 쓰면 안 되므로, 여기서는 성능 수치 대신 평가 설계를 봅니다.
Reasoning LLM을 평가할 때 최소한 세 층을 나눠야 합니다.
수학 정답률이 높다고 장기 계획이나 웹 상호작용까지 잘한다는 뜻은 아닙니다. 반대로 에이전트 과제는 추론뿐 아니라 도구 사용과 환경 상태 관리가 결과에 섞입니다. 여러 벤치마크를 한 줄의 “추론 점수”로 합치기 어려운 이유입니다.
자기 교정 능력도 독립적으로 봐야 합니다. 첫 답이 틀렸을 때 오류를 정확히 지적하는지, 수정 후 새로운 오류를 만들지 않는지, 이미 맞은 답을 불필요하게 바꾸지 않는지를 따로 측정해야 합니다.
추론 중심 접근이 필요한 경우는 여러 제약을 동시에 만족해야 하거나, 계획이 길고, 중간 결과를 검증할 수 있는 문제입니다. 복잡한 수학 풀이, 코드 문제 해결, 도구를 사용하는 에이전트가 대표적인 예입니다.
반면 단순한 분류나 짧은 질의처럼 즉시 답해도 되는 일에 모든 탐색 절차를 붙이면 응답 시간과 계산량만 늘 수 있습니다. 업무에 적용할 때는 문제 난도에 따라 빠른 경로와 깊은 추론 경로를 나누는 판단이 필요합니다.
설문이 제시한 향후 과제도 이 한계와 연결됩니다.
특히 의료, 법률처럼 결과의 위험이 큰 분야에서는 그럴듯한 풀이 과정이 검증을 대신할 수 없습니다. 분야별 학습, 외부 근거, 전문가 검토를 함께 설계해야 합니다.
System 2라는 이름의 가치는 AI가 사람과 같은 마음을 가졌다고 선언하는 데 있지 않습니다. 한 번 생성한 답을 그대로 믿는 구조에서 벗어나 탐색, 검증, 수정이 가능한 시스템을 만들고, 그 과정이 실제 정답률과 일반화로 이어지는지 시험하게 한다는 데 있습니다.
정해진 형식 변환, 정보 추출, 짧은 요약은 한 번의 응답으로 충분할 수 있습니다. 반면 여러 제약이 얽힌 일정, 수학 증명, 저장소 전체를 넘나드는 bug는 후보를 만들고 검토하는 과정이 도움이 됩니다. 요청 길이가 아니라 필요한 의존 단계와 되돌릴 수 있는 검증 수단을 기준으로 난도를 나누는 편이 좋습니다.
간단한 router를 만든다면 먼저 일반 모드로 답하고 confidence와 검증 결과를 봅니다. 형식 검사가 실패하거나 계산기, compiler가 오류를 내면 reasoning 모드로 재시도합니다. 모든 요청을 처음부터 긴 모드로 보내는 것보다 실패 신호가 있는 문제에 계산을 집중할 수 있습니다.
수학은 최종 수치와 식을 다시 계산하고, code는 clean 환경에서 test와 type check를 실행하며, 문서 답변은 인용한 문장이 실제 source에 있는지 확인합니다. 모델이 제시한 reasoning이 자연스러워도 이 검사를 통과하지 못하면 완료가 아닙니다. 반대로 내부 사고를 공개하지 않아도 산출물이 검증되면 업무 품질을 판단할 수 있습니다.
같은 질문을 여러 번 실행해 답과 비용의 분산도 봅니다. 한 번의 최고 결과보다 정해진 token 예산 안에서 안정적으로 통과하는 비율이 중요합니다. 추론이 길어지면서 같은 내용을 반복하거나 결론이 흔들리면 reasoning token 증가가 품질로 이어지지 않은 것입니다.
정답률, 총 출력 token, 첫 응답과 완료까지의 시간, 외부 검증 통과율을 한 행에 기록합니다. Agent라면 tool 호출 수와 실패 복구 횟수도 추가합니다. 빠른 모델이 두 번 재시도한 비용과 reasoning 모델이 한 번에 끝낸 비용을 end-to-end로 비교해야 합니다.
Reasoning LLM의 선택 기준은 “깊게 생각한다”는 표현이 아니라 특정 문제군에서 검증 통과율이 얼마나 오르고 그 대가로 지연과 비용이 얼마나 늘어나는지입니다. 답을 자동 검증하기 어려운 고위험 분야에서는 긴 추론을 신뢰 신호로 쓰지 말고 전문 검토를 남겨야 합니다.
보장되지 않습니다. 반복되거나 잘못된 전제를 길게 전개할 수 있으므로 계산기, test, 원문 인용 같은 외부 검증이 필요합니다.
아닙니다. 형식 변환과 단순 추출은 일반 모드로 충분할 수 있습니다. 실패 신호와 문제 단계 수에 따라 추가 계산을 배정하는 편이 효율적입니다.
정답률뿐 아니라 총 token, 완료 시간, 외부 검증 통과율과 재시도 횟수를 같은 업무 세트에서 비교해야 합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.