AI의 속내 엿보기: Gemini 3.1 사고 사슬(CoT) 노출로 코드 로직 디버깅하기

Easton editorial illustration: personal agent daily-operations hub

Gemini 3.1 Pro가 생성한 재귀 함수를 세 번 테스트했는데 결과가 매번 달랐습니다. 난수 문제가 아니라 특정 분기에서 로직이 ‘표류’한 것이었습니다. AI로 코드를 작성할 때는 줄곧 AI를 블랙박스로 여겼습니다. 프롬프트를 입력하면 코드가 나오고, 그 사이에 무슨 일이 일어나는지는 알지도 못했고 관심도 없었습니다. 코드에 문제가 생기기 전까지는 말입니다.

특정한 프롬프트 설계를 사용하면 Gemini가 ‘사고 연습장’을 드러내게 할 수 있습니다. 보기 좋게 다듬은 요약이 아니라 실제로 생성된, 원초적이고 다소 혼란스럽기까지 한 내부 추론 사슬입니다. 이렇게 노출된 사고 사슬에서는 숨은 가정, 추론 생략, 자기모순을 볼 수 있습니다.

여기서는 사고 사슬(CoT)을 활용해 AI 코드를 디버깅하는 방법을 다룹니다. Gemini 3.1 Pro의 thinking_level 매개변수, 노출을 유도하는 조건, 진단 사례, 프롬프트 개선 방법을 차례로 살펴봅니다. 막연한 요령이 아니라 실제로 적용할 수 있는 기술적 방법입니다.

사고 사슬(CoT) 노출이란 무엇인가

먼저 몇 가지 개념부터 정리하겠습니다.

**사고 사슬(Chain of Thought, CoT)**은 오늘날 대규모 언어 모델이 복잡한 추론을 수행할 때 사용하는 핵심 메커니즘입니다. 간단히 말하면 모델이 최종 답을 내놓기 전에 사고 과정을 먼저 적도록 하는 방식입니다. 수학 문제를 풀 때 연습장에 풀이 과정을 먼저 쓰는 것과 같습니다.

Gemini 3/3.1 Pro에는 모델의 내부 추론 깊이를 조절하는 thinking_level 매개변수가 있습니다. 낮은 수준에서는 모델이 바로 답을 내놓지만, 높은 수준에서는 다단계 추론, 자기 교정, 경로 계획을 수행합니다.

다만 함정이 하나 있습니다. 공식적으로 표시되는 ‘Thinking’ 블록은 사실 한 번 더 가공된 요약이며 원래의 사고 사슬이 아닙니다.

Reddit의 한 개발자는 특정 입력을 사용하면 Gemini 3 Pro가 실제 원본 사고 사슬을 노출한다는 사실을 발견했습니다. 자기 의심, 잘못된 시도, 심지어 ‘재귀 루프’까지 포함된 진짜 추론 과정입니다.

AI가 머릿속으로 이렇게 중얼거리는 모습을 볼 수 있다고 상상해 보세요.

“음, 사용자는 정렬 알고리즘을 원하네… 퀵 정렬? 아니야, 데이터가 너무 적어서 재귀 오버헤드가 커… 그럼 버블 정렬? 너무 단순한데… 잠깐, Python 내장 sorted를 쓸 수도 있지만 직접 구현하라고 했지… 그렇다면 안정적이고 효율도 괜찮은 병합 정렬로 하자…”

이런 ‘내적 독백’ 수준의 정보는 프롬프트를 디버깅하고 코드 품질을 높이는 데 큰 도움이 됩니다.

사고 사슬 노출을 유도하는 방법

이제 직접 적용하는 방법을 살펴보겠습니다.

Gemini 3.1 Pro의 사고 사슬은 일반적으로 다음과 같은 상황에서 노출됩니다.

상황 1: 극도로 복잡한 논리 문제

문제의 복잡도가 일정 임계치를 넘으면 모델은 정확한 답을 내기 위해 더 많은 중간 추론 단계를 드러낼 수밖에 없습니다. 이때 API가 반환하는 원본 토큰 스트림을 자세히 살펴보면 <thinking> 태그 안의 내용이 평소보다 훨씬 풍부한 경우가 있습니다.

상황 2: 모델이 막혔을 때의 자기 교정

Reddit 사용자가 보고한 사례가 있습니다. Gemini가 재귀 루프나 논리적 막다른 길에 빠지면 다소 ‘unhinged’(통제력을 잃은 듯한) 상태를 보입니다. 이 상태에서는 모델의 내부 검증 메커니즘이 사고 사슬을 제때 ‘sanitize’(정리)하지 못해 원본 추론이 노출될 수 있습니다.

상황 3: 특정 프롬프트 설계

다음과 같은 프롬프트 기법으로 노출 가능성을 높일 수 있습니다.

“잘못된 시도를 포함해 사고 과정을 보여 주세요”라고 명확히 요청합니다.
“연습장” 프레임을 사용합니다. 예: “먼저 연습장에서 문제를 분석한 뒤 답을 제시해 주세요.”
후속 질문형 프롬프트를 사용합니다. 예: “방금 추론에 비약이 있으니 각 단계를 자세히 설명해 주세요.”

실용적인 방법 하나: Gemini API 호출에서 thinking_level: "high"로 설정한 뒤 반환된 thinking 필드를 파싱해 보세요. 때로는 그 안에 text 필드보다 더 유용한 정보가 담겨 있습니다.

사고 사슬에서 논리 문제 진단하기

노출된 사고 사슬을 어디에 활용할 수 있을까요? 실제 사례를 몇 가지 살펴보겠습니다.

사례 1: 숨은 가정 발견하기

한번은 Gemini에게 사용자 입력을 처리하는 함수를 작성해 달라고 했습니다. 코드는 문제가 없어 보였지만 사고 사슬에서 다음 문장을 발견했습니다.

“사용자 입력은 항상 유효한 JSON 형식이라고 가정…”

잠깐, 입력이 반드시 JSON이라고 말한 적은 없습니다. 모델이 스스로 추가한 가정입니다. 사고 사슬을 보지 못했다면 이 위험 요소가 프로덕션 환경까지 들어갔을 수도 있습니다.

사례 2: 추론 생략 발견하기

다른 사례로 Gemini에게 데이터베이스 쿼리를 최적화해 달라고 요청했습니다. 생성된 코드는 인덱스를 사용했고 꽤 전문적으로 보였습니다. 그러나 사고 사슬에는 이렇게 적혀 있었습니다.

“사용자가 쿼리 최적화를 원하네… 음, 인덱스 추가가 가장 흔한 최적화 방법이지… 인덱스를 추가하라고 제안하자…”

문제가 보이시나요? 모델은 기존 쿼리 계획이나 데이터 분포를 전혀 분석하지 않았고, 인덱스가 이미 있는지도 확인하지 않았습니다. ‘가장 정확한’ 답이 아니라 ‘가장 손쉬운’ 답을 선택한 것입니다.

사례 3: 자기모순 발견하기

가장 흥미로운 순간은 모델이 ‘자기 말을 스스로 뒤집을’ 때입니다. 사고 사슬에 다음과 같은 내용이 나타날 수 있습니다.

“방법 A는 이 경계 조건에서 실패한다… 하지만 대부분의 상황에서 잘 작동하므로 그래도 방법 A를 추천하겠다.”

이런 자기모순이 드러나면 어느 부분에 방어 코드를 추가하거나 테스트 사례를 더 만들어야 하는지 알 수 있습니다.

CoT 디버깅으로 프롬프트 개선하기

사고 사슬은 코드를 디버깅하는 도구일 뿐 아니라 프롬프트를 개선하는 X선 장비이기도 합니다.

방법 1: 프롬프트를 어떻게 이해했는지 확인하기

내가 분명하게 말했다고 생각해도 모델은 다르게 이해할 수 있습니다. 사고 사슬을 살펴보면 모델이 무엇을 ‘들었는지’ 확인할 수 있습니다.

예를 들어 “효율적인 함수를 작성해 줘”라고 요청했다고 해 보겠습니다.

모델은 사고 사슬에서 다음과 같이 이해할 수 있습니다.

“효율적 = 시간 복잡도가 낮음”
“효율적 = 메모리 사용량이 적음”
“효율적 = 코드가 간결함”

해석에 따라 완전히 다른 코드가 나옵니다. 이런 모호함을 발견하면 프롬프트를 더 정확하게 작성해야 한다는 것을 알 수 있습니다.

방법 2: 지식의 빈틈 발견하기

모델이 사고 사슬에서 “음… 확실하지 않은데…”, “아마도…” 같은 표현을 사용한다면 해당 지식에 자신이 없다는 뜻입니다. 이때는 다음과 같이 대응해야 합니다.

프롬프트에 더 많은 맥락을 제공합니다.
또는 더 간단한 구현 방식으로 바꿉니다.

방법 3: 추론 방향 유도하기

모델이 어떻게 생각하는지 볼 수 있다면 그에 맞게 프롬프트를 조정해 추론을 유도할 수 있습니다.

예를 들어 모델이 항상 재귀 방식부터 검토한다면 “재귀가 분명히 더 간결한 경우가 아니라면 반복 방식을 우선 고려하세요”라는 문장을 추가할 수 있습니다.

또는 모델이 경계 조건을 무시한다면 “빈 입력과 극단값의 경계 조건 처리에 특히 주의하세요”라고 덧붙일 수 있습니다.

한계와 주의 사항

솔직히 말해 이 방법이 만능은 아닙니다.

한계 1: 노출이 불안정함

Google은 분명히 사고 사슬의 노출을 통제하려고 합니다. 얼마나 볼 수 있는지는 모델 버전, 매개변수 설정, 심지어 운에 따라서도 크게 달라집니다. 오늘 작동하는 기법이 내일은 막힐 수 있습니다.

한계 2: 사고 사슬도 틀릴 수 있음

사고 사슬은 모델의 ‘사고 과정’을 보여 줄 뿐 그 과정이 정확하다는 뜻은 아닙니다. 모델이 사고 사슬 안에서 확신에 차 추론해도 마지막 결론은 틀릴 수 있습니다.

한계 3: 지나친 의존은 효율을 떨어뜨림

사고 사슬을 분석하려면 시간이 많이 듭니다. 간단한 작업에서는 코드 출력만 바로 확인하는 편이 더 빠릅니다. 복잡한 로직을 다루거나 문제가 반복될 때만 이 방법을 사용하세요.

윤리적 주의 사항

Google은 공식적으로 원본 사고 사슬을 보여 주려 하지 않습니다. 이런 ‘노출’은 모델의 내부 메커니즘을 엿보는 행위로 간주될 수 있습니다. 실제 프로젝트에서 사용할 때는 다음 사항에 주의하세요.

노출된 사고 사슬에 의존해 중요한 결정을 내리지 마세요.
API 문서의 변경 사항을 확인하세요. 공식 동작은 언제든 바뀔 수 있습니다.
서비스 약관을 준수하세요.

마무리

결국 사고 사슬 노출을 이용해 AI 코드를 디버깅하는 일은 일종의 ‘리버스 엔지니어링’ 사고방식입니다.

우리는 AI를 블랙박스 속 신탁처럼 대하는 데 익숙합니다. 질문을 입력하고 정답을 기대합니다. 하지만 현실에서 AI도 실수하고, 모르는 영역이 있으며, 지름길을 택하기도 합니다.

AI의 ‘연습장’을 볼 수 있게 되면 수동적인 ‘답변 수신자’에서 능동적인 ‘추론 검토자’로 바뀝니다. 이런 관점의 전환은 더 나은 프롬프트를 작성하고 더 신뢰할 수 있는 코드를 생성하는 데 실질적인 도움이 됩니다.

그날 새벽 3시, 저는 Gemini의 사고 사슬을 분석하다가 재귀 종료 조건에서 경계 조건 하나를 빠뜨렸다는 사실을 발견했습니다. 프롬프트에 명확한 주의 문장을 하나 추가해 다시 생성하자 문제가 해결됐습니다.

코드는 올바르게 작동했습니다. 하지만 기억에 남은 것은 최종 답이 아니라 사고 사슬 안에서 스스로 잘못을 고치던 AI였습니다. AI도 실수하지만 더 나아지려고 시도합니다. 우리가 할 수 있는 일은 그 시도를 읽는 법을 배우는 것입니다.

직접 시험해 보고 싶다면 조금 복잡한 프로그래밍 문제를 골라 높은 thinking_level로 Gemini 3.1 Pro를 호출한 다음, ‘Thinking…’ 뒤에 무엇이 숨어 있는지 자세히 살펴보세요. 생각지 못한 것을 발견할 수도 있습니다.

어쩌면 AI의 ‘속내’도 엿볼 수 있을 것입니다.

FAQ

Chain of Thought(사고 사슬)란 무엇이며 AI 코드 디버깅에 왜 유용한가요?

Chain of Thought(CoT, 사고 사슬)는 대규모 언어 모델이 답을 내놓기 전에 사고 과정을 먼저 보여 주도록 하는 기술입니다.

AI 코드를 디버깅할 때 유용한 이유는 다음과 같습니다.
• 모델이 어떤 숨은 가정을 했는지 확인할 수 있습니다(예: '입력은 항상 JSON 형식이라고 가정').
• 모델이 문제를 실제로 이해했는지, 아니면 추론의 지름길을 택했는지 알 수 있습니다.
• 모델의 자기모순을 찾아 잠재적 버그를 미리 예측할 수 있습니다.

간단히 말해 사고 사슬은 AI의 '연습장'이며, 그 안에는 '내적 독백'에 가까운 추론 세부 사항이 담겨 있습니다.

Gemini 3.1 Pro에서 사고 사슬 노출을 어떻게 유도하나요?

사고 사슬 노출을 유도하는 방법은 다음과 같습니다.

1. **thinking_level 매개변수 설정**: 추론 깊이를 늘리려면 'high' 수준을 사용합니다.
2. **복잡한 문제로 유도**: 문제 복잡도가 임계치를 넘으면 모델이 더 많은 추론 단계를 드러내게 됩니다.
3. **특정 프롬프트 설계**:
- '잘못된 시도를 포함해 사고 과정을 보여 달라'고 요청합니다.
- '연습장' 프레임을 사용합니다. 예: '먼저 연습장에서 문제를 분석해 주세요.'
- 후속 질문형 프롬프트를 사용합니다. 예: '방금 추론에 비약이 있으니 각 단계를 자세히 설명해 주세요.'

주의: 노출은 불안정하며 모델 버전과 공식 제한 정책에 따라 달라집니다.

사고 사슬에서 어떤 유형의 논리 문제를 찾을 수 있나요?

사고 사슬을 분석하면 크게 세 가지 문제를 찾을 수 있습니다.

**숨은 가정**: 입력 형식이나 데이터 범위처럼 모델이 검증 없이 임의로 추가한 가정입니다.

**추론 생략**: 모델이 수고를 줄이려고 분석 단계를 건너뛰고 '가장 정확한' 답이 아니라 '가장 흔한' 답을 바로 내놓는 경우입니다.

**자기모순**: 모델이 어떤 방법에 문제가 있음을 인식하면서도 계속 그 방법을 권하는 경우입니다. 이런 모순은 추가 검증이 필요한 경계 조건을 드러냅니다.

이러한 문제를 발견한 뒤에는 프롬프트에 제약이나 주의 사항을 명시해 수정할 수 있습니다.

사고 사슬로 프롬프트를 디버깅할 때 유용한 방법은 무엇인가요?

핵심 방법은 세 가지입니다.

**이해의 어긋남 확인**: 사고 사슬에서 모델이 지시를 어떻게 해석했는지 살펴보고 의도와 다른 모호성을 찾습니다.

**지식의 빈틈 발견**: '확실하지 않다', '그럴 수 있다' 같은 망설이는 표현에 주목합니다. 모델이 해당 지식에 자신이 없다는 뜻이므로 더 많은 맥락을 제공해야 합니다.

**추론 방향 유도**: 관찰한 사고 패턴에 따라 프롬프트를 조정합니다. 예를 들어 '반복 방식을 우선 고려할 것', '경계 조건 처리에 특히 주의할 것' 같은 지침을 추가합니다.

사고 사슬은 프롬프트의 X선 사진과 같습니다. 내가 무엇을 '말했는지'가 아니라 모델이 무엇을 '들었는지' 보여 줍니다.

사고 사슬 노출을 이용할 때 어떤 한계와 위험이 있나요?

주요 한계와 위험은 다음과 같습니다.

**불안정성**: Google은 사고 사슬 노출을 통제하고 있으므로 모델 업데이트에 따라 방법이 더 이상 작동하지 않을 수 있습니다.

**신뢰성 문제**: 사고 사슬 자체도 틀릴 수 있으며, 표시된 사고 과정이 정답임을 뜻하지 않습니다.

**효율 비용**: 사고 사슬 분석에는 시간이 많이 들어 간단한 작업에는 적합하지 않습니다.

**윤리적 위험**: 공식적으로는 모델 내부 메커니즘을 엿보는 행위를 권장하지 않으며, 프로덕션 환경에서는 노출된 사고 사슬에 의존해 중요한 결정을 내려서는 안 됩니다.

디버깅과 학습 도구로만 활용하고 실제 프로젝트에서는 신중하게 사용하는 것이 좋습니다.

1분 읽기 · 게시일: 2026년 2월 27일 · 수정일: 2026년 9월 4일

Easton

AI와 지능

AI의 속내 엿보기: Gemini 3.1 사고 사슬(CoT) 노출로 코드 로직 디버깅하기

사고 사슬(CoT) 노출이란 무엇인가