추론 유도와 검증 루프

긴 생각을 보여 달라는 요청의 함정

복잡한 문제를 ChatGPT에 맡길 때 많은 사용자가 가장 먼저 떠올리는 문장이 있습니다. '단계별로 생각해 봐.' 이 말은 한동안 거의 마법 주문처럼 쓰였습니다. 실제로 산수 문제, 논리 퍼즐, 조건이 많은 업무 판단에서는 답만 바로 요구하는 것보다 중간 과정을 요구했을 때 결과가 좋아지는 경우가 많았습니다.

하지만 실무에서 중요한 것은 AI가 길게 생각하는 것처럼 보이게 만드는 일이 아닙니다. 중요한 것은 더 나은 답을 얻고, 그 답이 맞는지 확인할 수 있는 구조를 만드는 일입니다. 긴 설명은 때로 도움이 되지만, 긴 설명 자체가 정확성을 보장하지는 않습니다. 오히려 장황한 설명이 붙으면 사용자는 그럴듯함에 속기 쉽습니다. 틀린 계산, 없는 근거, 지나친 추정도 문장이 길어지면 더 믿음직해 보입니다.

앞 장에서 역할 설계와 지시의 계층을 다뤘다면, 이제 그 위에 작업의 흐름을 올려야 합니다. 역할은 안전벨트이고, 검증 루프는 브레이크입니다. 빠르게 달릴 수 있어도 멈추고 확인할 수 없다면 실무 도구로 쓰기 어렵습니다.

Chain-of-Thought는 왜 주목받았나

Chain-of-Thought, 줄여서 CoT는 우리말로 흔히 '생각의 사슬' 또는 '단계적 추론'이라고 부릅니다. 핵심은 단순합니다. 모델에게 최종 답만 내라고 하지 않고, 문제를 풀기 위한 중간 단계를 함께 만들게 하는 방식입니다. 2022년에 발표된 대표 연구는 대규모 언어 모델이 몇 개의 단계적 풀이 예시를 받았을 때 산술, 상식, 기호 추론 과제에서 성능이 좋아질 수 있음을 보였습니다.¹

왜 이런 일이 생겼을까요? 사람도 복잡한 문제를 한 번에 맞히기 어렵습니다. 'A와 B 중 무엇이 더 유리한가?'라는 질문을 받으면 먼저 기준을 세우고, 자료를 나누고, 예외를 확인하고, 결론을 냅니다. CoT는 모델에게 이런 중간 다리를 놓아 주는 방식이었습니다. 특히 다음과 같은 문제에서 효과가 컸습니다.

• 계산 과정이 여러 단계인 산수 문제

• 조건을 하나씩 적용해야 하는 논리 문제

• 원인과 결과를 구분해야 하는 상식 추론

• 예시의 규칙을 찾아 새로운 입력에 적용하는 문제

예를 들어 이런 질문을 생각해 봅시다.

내가 6살이었을 때 여동생은 내 나이의 절반이었다.
지금 내가 70살이면 여동생은 몇 살인가?

답만 성급히 내는 모델은 '70의 절반'에 끌려가 35라고 답할 수 있습니다. 하지만 올바른 풀이는 '내가 6살일 때 여동생은 3살이었고, 나이 차이는 3살이며, 나이 차이는 시간이 지나도 변하지 않으므로 지금 여동생은 67살'입니다. 단계가 드러나면 어디서 실수했는지도 보입니다.

다만 여기서 조심해야 합니다. CoT가 보여 주는 것은 인간의 머릿속 생각과 같은 것이 아닙니다. 그것은 모델이 만들어 낸 풀이 형식의 텍스트입니다. 좋은 풀이 형식은 정답 가능성을 높일 수 있지만, 그 자체가 진실의 보증서는 아닙니다.

Self-Consistency는 한 번 더 의심하는 기술이다

CoT에도 약점이 있습니다. 하나의 풀이 경로가 처음부터 잘못 잡히면 끝까지 그럴듯하게 틀릴 수 있습니다. 그래서 등장한 아이디어가 Self-Consistency, 즉 자기 일관성 기법입니다. 이 방법은 하나의 답만 받지 않고 여러 개의 추론 경로를 샘플링한 뒤, 최종 답이 가장 많이 일치하는 쪽을 고르는 방식입니다. 대표 연구는 CoT에서 단일 경로를 고르는 대신 다양한 추론 경로를 만든 다음 가장 일관된 답을 선택하면 여러 산술·상식 추론 벤치마크에서 성능이 개선될 수 있음을 보였습니다.²

쉽게 말해, 한 명에게 한 번 물어보는 대신 같은 문제를 여러 풀이 방식으로 풀어 보게 한 뒤 답이 모이는지 보는 것입니다. 서로 다른 길로 갔는데 같은 결론에 도착한다면 그 결론에 대한 신뢰가 조금 올라갑니다. 반대로 답이 제각각이면 문제 자체가 모호하거나, 필요한 정보가 부족하거나, 모델이 안정적으로 풀지 못하는 과제일 수 있습니다.

실무에서는 Self-Consistency를 이렇게 재해석할 수 있습니다.

아래 문제를 서로 다른 3가지 관점으로 검토하라.
각 관점의 최종 판단을 한 줄로 요약한 뒤,
일치하는 결론과 갈리는 지점을 분리하라.
마지막에는 확정 결론이 아니라 검토자가 확인해야 할 쟁점을 제시하라.

문제:
[여기에 질문]

이 프롬프트는 모델에게 장황한 생각을 전부 보여 달라고 요구하지 않습니다. 대신 여러 관점의 결론이 어디서 일치하고 어디서 갈리는지 보게 합니다. 특히 정책 검토, 기획안 비교, 보고서 리스크 분석처럼 정답이 하나로 딱 떨어지지 않는 업무에서는 다수결보다 '불일치 지점'을 찾는 것이 더 중요합니다.

물론 Self-Consistency에도 한계가 있습니다. 같은 모델이 같은 오해를 반복하면 여러 번 물어봐도 같은 틀린 답이 나올 수 있습니다. 자료가 틀렸거나 질문이 잘못되었거나 한국어 표현이 모호하면 일관된 오답이 만들어질 수도 있습니다. 그래서 자기 일관성은 검증의 끝이 아니라 시작입니다. 숫자는 계산기로 확인하고, 법령은 원문으로 확인하고, 코드는 테스트로 확인하고, 조직 정책은 담당자에게 확인해야 합니다.

최신 reasoning 모델에서는 질문 방식이 달라진다

최근의 reasoning 모델은 내부적으로 더 많은 계산 시간을 쓰며 복잡한 문제를 처리하도록 설계되어 있습니다. OpenAI의 API 문서도 reasoning 모델을 다룰 때 reasoning effort, reasoning tokens, 대화 간 reasoning 상태 관리 같은 개념을 별도로 설명합니다.³ 사용자의 눈에 보이는 답변은 짧아도, 모델 내부에서는 더 많은 계산이 일어날 수 있다는 뜻입니다.

이 변화는 프롬프트 습관도 바꿉니다. 예전에는 '단계별로 생각해'라는 한 문장이 성능을 끌어올리는 대표적인 요령처럼 쓰였습니다. 그러나 reasoning 모델을 실무에서 쓸 때는 무조건 긴 사고 과정을 출력하게 만드는 것보다 다음이 더 중요합니다.

• 목표와 성공 기준을 분명히 말한다.

• 정보가 부족하면 먼저 질문하게 한다.

• 출력 형식을 검토 가능한 구조로 정한다.

• 불확실한 부분과 가정을 따로 표시하게 한다.

• 최종 답 뒤에 자기 점검 또는 수정 제안을 붙인다.

특히 민감한 업무에서는 '생각을 전부 보여 줘'보다 다음과 같은 지시가 더 실용적입니다.

문제를 내부적으로 충분히 검토하되,
출력에는 다음 네 가지만 제시하라.

1. 한 줄 결론
2. 핵심 근거 3개
3. 불확실하거나 추가 확인이 필요한 항목
4. 최종 점검 결과

이 방식은 모델의 답변을 짧게 만들기 위한 꼼수가 아닙니다. 검토자가 확인해야 할 정보만 앞으로 꺼내는 방법입니다. 실무자는 AI의 장문 풀이를 감상하는 사람이 아니라, 그 결과를 판단하고 책임지는 사람입니다.

계획-실행-검토 패턴

복잡한 업무는 한 번에 끝내려고 하면 흔들립니다. 좋은 프롬프트는 모델에게 '정답을 맞혀라'라고 말하지 않고, 일을 처리하는 순서를 만들어 줍니다. 가장 기본적인 흐름은 계획, 추가정보 요청, 초안 작성, 자기 점검, 수정입니다.

이 흐름을 하나의 업무 루프로 보면 다음과 같습니다.

이 패턴은 보고서, 이메일, 기획안, 수업안, 고객 응대, 코드 리뷰, 계약 검토 등 대부분의 업무에 적용할 수 있습니다. 핵심은 모델이 처음 낸 답을 최종본으로 취급하지 않는 것입니다. 첫 답변은 초안입니다. 초안은 검토되어야 하고, 검토 결과는 수정으로 이어져야 합니다.

기본 템플릿: 한 번에 답하지 말고 루프로 처리하라

아래 템플릿은 한국어 업무 환경에서 바로 쓸 수 있는 기본형입니다. 앞 장의 역할 설계와 결합하면 더 안정적으로 작동합니다.

[역할]
당신은 한국어 업무 문서를 돕는 분석 및 편집 보조 도구다.
확인되지 않은 사실을 단정하지 않고, 부족한 정보는 추가 확인 필요로 표시한다.

[업무]
아래 자료를 바탕으로 [원하는 산출물]을 작성하라.
대상 독자는 [대상 독자]다.

[진행 순서]
1) 먼저 작업 계획을 3단계로 제시하라.
2) 답변 품질에 꼭 필요한 추가정보가 있으면 최대 5개만 질문하라.
3) 정보가 부족해도 초안이 가능하면, 가정을 명시한 뒤 초안을 작성하라.
4) 초안 뒤에 자기 점검표를 붙여라.
5) 점검 결과 문제가 있으면 수정본을 제시하라.

[점검 기준]
- 원문에 없는 사실을 추가했는가?
- 중요한 조건이나 예외를 빠뜨렸는가?
- 근거보다 결론이 앞서 나갔는가?
- 요청한 형식과 분량을 지켰는가?
- 한국어 문체가 대상 독자에게 맞는가?

[자료]
...

이 템플릿의 장점은 모델에게 '똑똑하게 답하라'고 추상적으로 요구하지 않는다는 점입니다. 대신 어떤 순서로 생각하고, 어디서 멈추고, 무엇을 확인하고, 어떻게 고칠지 정합니다. 실무에서 필요한 추론은 머릿속 천재성이 아니라 절차입니다.

추가정보 요청은 게으름이 아니라 품질 관리다

좋은 답변을 얻고 싶다면 모델이 바로 답하지 않는 상황도 허용해야 합니다. 많은 사용자가 AI가 질문을 되돌려 주면 답답해합니다. 하지만 정보가 부족한데도 곧바로 결론을 내는 모델이 더 위험합니다.

예를 들어 사용자가 이렇게 요청했다고 합시다.

다음 분기 마케팅 전략을 짜 줘.

이 요청만으로는 좋은 전략이 나오기 어렵습니다. 제품, 예산, 타깃, 현재 성과, 경쟁 상황, 채널, 목표 지표가 모두 빠져 있기 때문입니다. 이때 좋은 모델은 바로 멋진 전략 문구를 쓰기보다 먼저 질문해야 합니다.

전략 초안을 만들기 전에 다음 정보가 필요합니다.
1. 이번 분기의 핵심 목표는 매출, 리드, 인지도 중 무엇입니까?
2. 주 타깃 고객은 누구입니까?
3. 사용할 수 있는 예산과 인력은 어느 정도입니까?
4. 지난 분기 성과에서 가장 좋았던 채널은 무엇입니까?
5. 반드시 피해야 할 메시지나 법무 검토가 필요한 표현이 있습니까?

답을 주시면 이를 반영해 전략 초안을 작성하겠습니다.
정보가 아직 없다면 합리적 가정을 표시한 임시 초안을 만들 수 있습니다.

추가정보 요청은 작업을 지연시키는 과정이 아닙니다. 잘못된 가정을 줄이는 과정입니다. 한국 조직에서는 특히 배경 정보가 말로만 공유되고 문서에는 빠지는 경우가 많습니다. AI에게 '모르면 질문하라'고 명시하지 않으면, 모델은 빈칸을 그럴듯한 문장으로 채워 버릴 수 있습니다.

자기 점검은 별도 역할로 분리하라

자기 점검을 시킬 때는 '다시 확인해 줘'라고만 말하면 약합니다. 모델은 자신이 방금 쓴 답을 대체로 좋게 평가하려는 경향을 보일 수 있습니다. 그래서 점검 역할을 분리하는 것이 좋습니다.

이제 작성자 역할을 멈추고 검토자 역할로 전환하라.
아래 초안을 다음 기준으로 점검하라.

1. 사실성: 원문에 없는 사실, 틀린 수치, 확인되지 않은 고유명사가 있는가?
2. 누락: 사용자의 요청, 조건, 대상 독자, 제한사항 중 빠진 것이 있는가?
3. 논리: 결론을 뒷받침하는 근거가 충분한가? 인과관계를 과장했는가?
4. 형식: 요청한 구조, 분량, 표기 방식, 문체를 지켰는가?
5. 위험: 법률, 의료, 금융, 개인정보, 보안 관련 단정이 있는가?

출력 형식:
- 문제 없음
- 수정 필요 항목
- 수정 이유
- 수정 제안 문장

이 프롬프트의 포인트는 '검토자 역할'입니다. 같은 모델을 쓰더라도 작성 모드와 검토 모드를 분리하면 답변의 방향이 달라집니다. 작성자는 문장을 완성하려고 하고, 검토자는 흠을 찾으려고 합니다. 사람의 업무에서도 초안 작성과 리뷰가 다르듯, AI 작업에서도 두 단계를 나누는 편이 안전합니다.

수정은 감상이 아니라 변경 목록으로 하라

검토까지 했는데 수정 지시가 흐릿하면 결과가 다시 흔들립니다. '더 좋게 고쳐 줘'라는 말은 너무 넓습니다. 무엇을 더 좋게 해야 하는지 알 수 없기 때문입니다. 검토 결과를 수정으로 연결하려면 변경 목록을 만들어야 합니다.

위 점검 결과를 반영해 수정하라.
단, 다음 규칙을 지켜라.

1. 사실 확인이 필요한 내용은 단정하지 말고 추가 확인 필요로 표시한다.
2. 중복 문장은 삭제한다.
3. 결론을 먼저 제시하고, 근거는 그다음에 배치한다.
4. 임원 보고용 문체로 간결하게 쓴다.
5. 수정 후 어떤 항목을 고쳤는지 변경 요약을 붙인다.

이렇게 하면 AI는 단순히 문장을 새로 쓰는 것이 아니라, 검토 결과를 처리하는 편집자가 됩니다. 좋은 검증 루프는 '초안 → 지적 → 수정'이 끊기지 않고 이어지는 구조입니다.

한국어 검증 체크리스트

한국어 업무 문서는 영어 프롬프트 예시를 그대로 가져오면 놓치는 부분이 많습니다. 주어가 생략되고, 책임 주체가 흐려지고, 높임말 때문에 결론이 완곡해지며, 보고서 문체에서는 명사형 표현이 과도하게 늘어납니다. 그래서 한국어 답변은 별도의 체크리스트로 검증하는 편이 좋습니다.

이 체크리스트는 길어 보이지만, 실제로는 반복 사용하기 쉽습니다. 팀에서 자주 쓰는 업무라면 custom GPT나 프로젝트 지침에 넣어 두면 됩니다. 중요한 것은 매번 '잘 썼나?'라고 감으로 묻지 않는 것입니다. 무엇을 확인할지 항목화해야 검증이 됩니다.

보고서 작성에 적용하기

다음은 회의 메모를 임원 보고용 초안으로 바꾸는 예시입니다. 핵심은 초안 작성보다 검증 단계를 더 분명히 둔다는 점입니다.

[역할]
당신은 한국어 임원 보고서를 다듬는 문서 편집 보조자다.
원문에 없는 사실을 추가하지 않고, 불확실한 내용은 추가 확인 필요로 표시한다.

[업무]
아래 회의 메모를 임원 보고용 1페이지 요약으로 바꿔라.

[출력 순서]
1. 작업 계획 3단계
2. 추가 확인이 필요한 정보 최대 5개
3. 임원 보고용 초안
4. 자기 점검표
5. 점검 결과를 반영한 수정본

[초안 형식]
- 핵심 결론
- 주요 근거
- 리스크
- 다음 행동

[검증 기준]
- 숫자와 날짜를 임의로 만들지 말 것
- 담당자가 불분명한 행동은 담당 주체 미정으로 표시할 것
- 리스크를 축소하지 말 것
- 중복 문장을 제거할 것

[회의 메모]
...

이 프롬프트는 한 번에 완성본을 요구하지 않습니다. 먼저 계획을 세우고, 부족한 정보를 묻고, 초안을 만들고, 그 초안을 점검하고, 수정본을 냅니다. 사람의 업무 흐름과 비슷합니다. 좋은 AI 활용은 인간의 업무 절차를 없애는 것이 아니라, 그 절차를 더 빠르고 일관되게 만드는 일입니다.

검증은 AI 안에서만 끝나지 않는다

자기 점검은 유용하지만 충분하지 않습니다. 모델이 스스로 오류를 찾을 수는 있어도, 모든 오류를 잡아낼 수는 없습니다. 특히 계산, 코드, 법령, 의학 정보, 금융 수치처럼 외부 기준이 분명한 영역에서는 별도의 검증 도구가 필요합니다.

소프트웨어 검증 연구에서도 비슷한 교훈을 볼 수 있습니다. ChatGPT가 프로그램의 루프 불변식, 즉 반복문이 실행되는 동안 항상 유지되어야 하는 조건을 제안할 수는 있었지만, 그 조건이 실제로 유효하고 유용한지는 Frama-C 같은 검증 도구로 확인해야 했습니다. 연구 역시 LLM이 보조 역할을 할 수는 있으나 개념적·실무적 개선이 더 필요하다고 정리합니다.⁴

이 원리는 코드에만 해당하지 않습니다. AI가 만든 숫자는 계산기로 확인해야 합니다. AI가 요약한 계약 쟁점은 원문 조항과 전문가 검토로 확인해야 합니다. AI가 작성한 고객 답변은 내부 정책과 상담 권한으로 확인해야 합니다. AI가 만든 보고서 초안은 출처 문서와 의사결정자의 판단을 통과해야 합니다.

따라서 실무 검증은 세 겹으로 생각하는 것이 좋습니다.

• 1차 검증: AI의 자기 점검으로 명백한 누락과 형식 오류를 잡는다.

• 2차 검증: 사용자가 원문, 수치, 맥락, 조직 기준과 대조한다.

• 3차 검증: 고위험 영역은 전문가, 승인권자, 테스트 도구, 공식 출처로 확인한다.

이 세 겹을 거치면 AI는 위험한 자동 판단자가 아니라 강력한 초안 생성기와 검토 보조자가 됩니다.

위험도에 따라 루프의 강도를 조절하라

모든 작업에 같은 수준의 검증이 필요한 것은 아닙니다. 점심 메뉴 추천에 자기 점검표를 붙일 필요는 없습니다. 반대로 고객에게 발송될 보상 안내문이나 투자 설명 자료를 아무 검토 없이 내보내는 것은 위험합니다. 검증 루프는 업무의 위험도에 맞춰 조절해야 합니다.

위험도가 높을수록 AI의 답변은 최종본이 아니라 검토 대기 상태여야 합니다. 자동화는 편리하지만, 자동화된 오류는 더 빠르게 퍼집니다. 그래서 중요한 업무일수록 인간 승인 단계와 로그, 근거, 이관 기준이 필요합니다.

좋은 추론 프롬프트의 기준

좋은 추론 프롬프트는 복잡한 문장을 많이 넣은 프롬프트가 아닙니다. 좋은 추론 프롬프트는 모델이 일을 잘게 나누고, 부족한 정보를 묻고, 답을 검토하고, 수정할 수 있게 만드는 프롬프트입니다. 다음 기준을 만족하면 대부분의 업무에서 안정성이 크게 올라갑니다.

• 목표가 분명하다.

• 성공 기준이 있다.

• 부족한 정보를 질문하게 한다.

• 가정과 사실을 분리한다.

• 출력 형식이 검토 가능하다.

• 자기 점검 기준이 구체적이다.

• 수정 단계가 포함되어 있다.

• 고위험 판단은 사람이나 도구로 넘긴다.

반대로 나쁜 프롬프트는 모델에게 모든 책임을 한 번에 떠넘깁니다. '완벽하게 분석해 줘', '전문가처럼 판단해 줘', '알아서 좋은 방향으로 써 줘' 같은 요청은 편하지만 위험합니다. 실무에서 필요한 것은 완벽한 한 방이 아니라 반복 가능한 루프입니다.

출력할 생각보다 확인할 기준을 설계하라

AI를 잘 쓰는 사람은 모델에게 더 길게 생각하라고만 말하지 않습니다. 무엇을 기준으로 생각해야 하는지, 무엇을 모르면 멈춰야 하는지, 어떤 형식으로 결과를 내야 검토할 수 있는지 설계합니다.

Chain-of-Thought는 복잡한 문제를 중간 단계로 나누는 가능성을 보여 주었습니다. Self-Consistency는 하나의 추론 경로만 믿지 말고 여러 경로의 일치를 보라는 교훈을 주었습니다. 최신 reasoning 모델은 그 흐름을 더 강력하게 만들었지만, 실무의 결론은 오히려 단순합니다.

긴 사고 과정을 요구하는 것보다 중요한 것은 검증 가능한 작업 흐름입니다. 계획하고, 묻고, 쓰고, 점검하고, 고치는 루프. 이 루프를 만들 수 있을 때 ChatGPT는 단순한 답변 기계가 아니라, 한국어 업무 현장에서 함께 일할 수 있는 검토 가능한 파트너가 됩니다.

참고

¹Chain-of-Thought Prompting Elicits Reasoning in Large Language Models

²Self-Consistency Improves Chain of Thought Reasoning in Language Models

³Reasoning models | OpenAI API

⁴Can ChatGPT support software verification?