생각을 길게 쓰면 답이 더 좋아질까(4편)

생각을 길게 생성하는 것은 모델에 더 많은 계산 단계를 주는 방법이지, 정답을 확인하는 절차는 아닙니다. 중간 단계를 나누면 복잡한 문제에서 도움이 될 수 있지만, 잘못된 전제와 부족한 지식도 더 긴 문장으로 이어질 수 있습니다. 추론의 길이보다 결론을 확인할 기준이 있는지가 더 중요합니다.

편집자 노트 · B2B 도입 관점 — 도입 이후 가장 먼저 돌아오는 질문이 「그래서 얼마나 정확합니까」입니다. 이 편은 그 질문에 하나의 숫자로 답할 수 없는 이유와, 과제별로 수용 기준을 세우는 방법을 다룹니다. PoC 합격 기준이나 운영 SLA를 정의하실 때 참고하실 수 있습니다.

짧은 오답과 긴 오답은 모두 오답이었습니다

모델에게 어려운 문제를 한 번에 답하게 하면 중간 계산을 건너뛰는 경우가 있습니다. “단계별로 생각해보라”고 요청하면 식을 나누고 조건을 확인하며 답을 고치는 모습이 나타납니다. 이 차이는 추론 기능을 설명할 때 가장 눈에 잘 보이는 장면입니다.

문제는 설명이 길어지는 순간 신뢰감도 함께 커진다는 점입니다. 번호가 붙은 단계와 자연스러운 접속어, 마지막의 단정적인 결론은 사람이 작성한 검토 기록처럼 보입니다. 하지만 그 안의 첫 전제가 틀리면 이후 단계가 문법적으로 잘 이어져도 결론은 틀립니다.

저희가 결과를 볼 때 먼저 나눈 것도 길이가 아니라 역할이었습니다. 중간 생성은 후보를 탐색하고 문제를 분해하는 데 쓸 수 있습니다. 정답 판정은 계산기, 원문, 테스트, 업무 규칙처럼 모델 출력과 독립된 근거가 맡아야 합니다.

중간 토큰은 문제를 나눌 작업 공간을 만듭니다

다음 토큰을 반복해 만드는 모델은 한 번의 계산으로 먼 결론에 바로 도달하기 어려울 수 있습니다. 중간 단계에 변수와 부분 결과를 적으면 이후 토큰이 그 내용을 다시 문맥으로 사용할 수 있습니다. 사람이 복잡한 계산을 머릿속으로만 하지 않고 종이에 적는 것과 비슷한 효과입니다.

Chain-of-Thought 논문은 풀이 과정이 포함된 예시를 프롬프트에 제공했을 때 충분히 큰 모델의 산술, 상식, 기호 추론 과제 성능이 개선되는 현상을 보고했습니다. 모든 모델과 모든 문제에서 항상 좋아진다는 주장이 아니라, 특정 규모와 과제에서 중간 추론 예시가 유효했다는 결과입니다.

중간 토큰이 도움이 되는 경우에는 공통점이 있습니다. 문제를 작은 단계로 나눌 수 있고, 앞 단계의 결과가 뒤 단계의 입력이 되며, 중간 오류를 발견해 수정할 여지가 있습니다. 계획 수립, 다단계 계산, 여러 조건을 대조하는 과제가 여기에 가깝습니다.

반대로 단순한 분류와 짧은 추출은 긴 추론이 불필요할 수 있습니다. 답에 필요한 사실이 모델과 문맥에 없으면 생각을 오래 해도 새로운 근거가 생기지 않습니다. 토큰과 지연은 늘고, 잘못된 가정이 반복되면서 더 단단해질 수도 있습니다.

설명된 추론과 실제 원인은 같지 않을 수 있습니다

모델이 보여준 생각 과정을 내부 판단의 투명한 로그로 읽고 싶어질 때가 있습니다. 그러나 화면에 나온 추론도 다음 토큰으로 생성된 텍스트입니다. 자연스러운 설명을 만든다는 사실과 그 설명이 결론의 실제 원인을 충실히 드러낸다는 사실은 별개입니다.

연쇄적 사고 설명의 충실성을 조사한 연구는 객관식 보기 순서 같은 편향 신호를 입력에 넣었을 때 모델의 답이 영향을 받으면서도, 생성된 설명에서는 그 영향을 언급하지 않는 사례를 보였습니다. 일부 조건에서는 먼저 기울어진 답을 고른 뒤 그럴듯한 이유를 구성하는 행동이 나타났습니다.

따라서 추론 텍스트는 디버깅 단서와 설명 자료로 쓸 수 있지만 완전한 감사 로그를 대신하지는 못합니다. 입력, 도구 호출, 실제 관측값, 최종 결과를 별도로 기록해야 합니다. 숨겨진 내부 추론을 전부 노출하는 것보다 검증 가능한 외부 사건을 남기는 편이 운영에서는 더 직접적입니다.

환각은 사실 하나를 지어내는 문제보다 넓습니다

환각은 흔히 존재하지 않는 사람이나 논문을 만들어내는 현상으로 설명됩니다. 실제 결과를 검토할 때는 오류를 더 작게 나누는 편이 대응에 도움이 됩니다.

유형이 다르면 고치는 곳도 다릅니다. 외부 사실이 없으면 검색이 필요하고, 검색 결과가 있는데 답이 어긋나면 근거 사용을 검증해야 합니다. 계산은 자연어 설명을 더 요구하기보다 실행 가능한 식과 결과를 비교하는 편이 빠릅니다.

TruthfulQA 연구는 당시 여러 언어 모델을 사람들이 흔히 잘못 믿는 내용을 묻는 817개 질문으로 평가했습니다. 해당 실험에서 가장 좋은 모델의 진실성 점수는 58%였고 사람 평가는 94%였습니다. 오늘의 모든 모델에 그대로 적용할 수치는 아니지만, 학습 문장에서 널리 반복된 오해도 다음 토큰 예측의 패턴이 될 수 있음을 보여준 사례입니다.

하나의 점수는 서로 다른 실패를 평균냅니다

모델 평가표에는 종합 점수 하나가 자주 등장합니다. 후보를 빠르게 줄일 때는 편리하지만, 어떤 업무를 맡길지 결정하려면 점수의 구성으로 내려가야 합니다.

HELM 연구는 언어 모델을 정확도 하나가 아니라 정확성, 보정, 견고성, 공정성, 편향, 독성, 효율 등 여러 지표와 시나리오로 평가했습니다. 한 지표의 개선이 다른 지표의 개선을 뜻하지 않으므로 동일 조건에서 여러 측면을 함께 공개하려는 접근이었습니다.

실무 과제도 정답 조건이 서로 다릅니다.

글쓰기처럼 정답이 하나가 아닌 과제는 루브릭이 필요합니다. “좋은 글” 대신 사실 보존, 대상 독자 적합성, 금지 표현, 구조, 수정에 걸린 시간처럼 판단 항목을 나눕니다. 모델을 판정기로 쓸 수도 있지만, 판정 프롬프트와 모델에 따라 점수가 달라지므로 사람 표본 검토와 규칙 기반 검사를 함께 두는 편이 좋습니다.

같은 질문보다 같은 조건이 먼저입니다

두 모델에 같은 문장을 보냈다고 공정한 비교가 끝나지는 않습니다. 컨텍스트 자료, 출력 상한, 샘플링, 추론 단계, 도구와 재시도 횟수가 다르면 최종 시간과 품질에는 모델 바깥의 차이가 함께 들어갑니다.

평가 기록에는 적어도 입력 버전, 모델과 설정, 실제 출력 토큰, 도구 호출, 종료 이유를 남깁니다. 한 번의 최고 점수보다 여러 번의 분포와 실패 사례를 봅니다. 평균이 같아도 한쪽이 가끔 크게 실패한다면 운영에서 필요한 대응이 달라집니다.

저희가 유용하게 본 순서는 다음과 같습니다.

1. 실제 업무에서 성공과 실패를 먼저 정의합니다.
2. 입력과 도구, 실행 상한을 고정합니다.
3. 자동으로 확인할 수 있는 규칙과 테스트를 만듭니다.
4. 열린 품질은 명시적 루브릭으로 표본 평가합니다.
5. 점수와 함께 실패 이유, 비용, 지연의 분포를 남깁니다.

이 순서를 따르면 긴 추론이 필요한 과제와 짧은 답이 나은 과제를 분리할 수 있습니다. 모르는 경우에 답을 보류하는 행동도 실패가 아니라 정책에 맞는 성공으로 정의할 수 있습니다. 평가가 모델의 순위를 매기는 표에서 실제 역할의 경계를 정하는 도구로 바뀝니다.

다음 편에서는 답을 생성하는 LLM과 환경에서 행동하는 에이전트를 구분합니다. 모델의 도구 호출이 실제 실행이 되기까지 어떤 구성 요소가 필요하고, 반복·권한·종료 조건을 왜 모델 바깥에서 관리해야 하는지 살펴보겠습니다.

도입을 검토한다면

「얼마나 정확한가」를 계약과 운영의 언어로 옮기면 이렇게 됩니다.

첫째, 과제별로 수용 기준을 따로 정합니다. 요약의 기준은 원문 보존이고, 사실 조회의 기준은 출처 일치이며, 계산의 기준은 결과 대조입니다. 하나의 정확도 숫자로 묶으면 어느 쪽도 관리되지 않습니다.

둘째, 보류를 성공으로 정의합니다. 근거가 부족할 때 모델이 답을 만들어내지 않고 멈추는 것은 실패가 아니라 정책대로 동작한 것입니다. 이 정의가 없으면 현장은 「무조건 답하는」 설정을 선호하게 되고, 그 대가는 나중에 옵니다.

셋째, 평가셋을 자산으로 관리합니다. 실제 업무에서 모은 문항과 정답 기준은 모델을 바꿀 때마다 다시 쓰입니다. 도입 초기에 만들어두면 이후의 모든 교체 판단이 빨라집니다.

다음 편 → LLM은 어떻게 ‘답변’을 넘어 ‘실행’할 수 있을까? (5편)