15. 대화 누적과 컨텍스트 관리

"왜 갈수록 이상해질까"

긴 대화를 이어가다 보면 모델이 점점 이상해지는 경험, 다들 해봤을 겁니다. 앞에서 한 말을 까먹거나, 엉뚱한 맥락을 끌어오거나, 처음 정한 톤·형식에서 벗어나거나. 이것은 모델이 "지쳐서"가 아니라, 컨텍스트가 누적되며 생기는 구조적 현상입니다. 이 장은 그 원인과 대응입니다.

멀티턴 대화는 어떻게 쌓이나

12장에서 출력도 같은 윈도우를 쓴다고 했습니다. 대화에서는 한 발 더 나아갑니다. 매 턴마다, 이전의 모든 주고받음이 컨텍스트에 누적되어 다시 모델에게 전달됩니다.

flowchart TB
    t1["턴 1: 질문 A + 답 A"] --> t2["턴 2 컨텍스트:<br/>질문 A + 답 A + 질문 B"]
    t2 --> t3["턴 3 컨텍스트:<br/>A + 답A + B + 답B + 질문 C"]
    t3 --> grow["...계속 누적..."]
    grow --> full["윈도우가 차면<br/>오래된 것부터 잘림 / 신호 희석"]

    classDef step fill:#ede9fe,stroke:#8b5cf6,color:#4c1d95
    classDef warn fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    class t1,t2,t3,grow step
    class full warn

🔧 개발자 노트: 모델에는 턴 사이의 기억이 없습니다(2장). 챗 인터페이스가 "기억하는 것처럼" 보이는 이유는, 매 요청마다 전체 대화 기록을 다시 보내기 때문입니다. API로 멀티턴을 구현할 때 직접 해야 하는 일이 바로 이것 — 이전 메시지들을 누적해 매번 함께 전송하는 것입니다. 그래서 대화가 길수록 매 요청의 토큰·비용·지연이 늘고, 윈도우 한도에 다가갑니다.

세 가지 문제: 누적·오염·부패

긴 대화에서 생기는 문제를 셋으로 나눠봅시다.

문제 1: 누적 (단순히 길어짐)

대화가 쌓이며 윈도우를 잠식합니다. 14장의 중간 소실과 결합하면, 초반에 정한 중요한 규칙(역할·형식·제약)이 대화 중간에 묻혀 점점 무시되기 쉽습니다.

문제 2: 오염 (관련 없는 것이 섞임)

대화가 여러 주제를 오가면, 앞 주제의 정보가 뒤 주제에 잘못 끌려옵니다. 예를 들어 마케팅 카피를 쓰다가 갑자기 코드 리뷰를 부탁하면, 모델이 앞의 마케팅 톤을 코드 설명에 섞을 수 있습니다(3장 컨텍스트 의존의 나쁜 면).

문제 3: 부패 (오류·잘못된 전제가 굳어짐)

대화 중 모델이 한 번 틀린 사실이나 잘못된 전제를 말하면, 그것이 컨텍스트에 남아 이후 답의 토대가 됩니다. 틀린 전제 위에 계속 쌓으면, 대화가 길어질수록 점점 더 어긋납니다. 한 번 잘못 든 길을 계속 가는 셈입니다.

⚠️ 흔한 실수·미신: "대화를 길게 이어가면 모델이 맥락을 더 잘 이해한다"는 항상 참이 아닙니다. 관련 맥락이 쌓이면 도움이 되지만, 무관·모순·오류가 쌓이면 오히려 방해가 됩니다. 길이 자체가 이해를 보장하지 않습니다.

대응 1: 능동적으로 정리하기

가장 강력한 도구는 새로 시작하기입니다. 주제가 바뀌거나, 대화가 길어져 모델이 헤매기 시작하면, 새 대화창을 열고 핵심만 추려 다시 주세요.

긴 대화에서 헤맬 때:
1. 지금까지의 핵심 결론·결정·제약을 직접 요약
2. 새 창에 그 요약 + 다음 할 일만 전달
3. 누적된 잡음(중간 시행착오, 오류, 곁가지)은 버림

💡 팁: 이것은 비개발자도 매일 할 수 있는 컨텍스트 엔지니어링입니다(3장). "대화가 꼬였다" 싶으면 끝까지 우기지 말고, 핵심만 들고 새 창에서 깨끗하게 다시 시작하는 게 빠를 때가 많습니다.

대응 2: 요약·압축 (compaction)

대화를 완전히 버리지 않되 줄이는 방법입니다. 긴 대화의 핵심을 요약해 그것으로 이전 기록을 대체하면, 맥락은 유지하면서 윈도우를 절약합니다. 한 제공자는 이를 장기 작업을 위한 compaction(압축)이라 부르며, 긴 호흡의 작업에서 핵심 기법으로 소개합니다.

[압축 예]
"지금까지의 대화를 다음 형식으로 요약해줘:
- 확정된 결정사항
- 미해결 질문
- 지켜야 할 제약
이 요약으로 계속 진행하자."

이렇게 만든 요약을 새 대화의 출발점으로 삼으면, 잡음은 버리고 신호만 이어갈 수 있습니다.

무엇을 남기고 무엇을 버리나

🧪 직접 검증법: 긴 대화에서 모델이 초반 규칙(예: "항상 존댓말로")을 잊기 시작하면, 그 규칙을 지금 다시 명시해보세요. 그것만으로 회복되면 "누적에 의한 묻힘"이었던 것이고, 회복이 잘 안 되면 새 창 + 요약으로 옮길 때입니다.

대응 3: 한 대화 = 한 작업

오염을 막는 예방책입니다. 가능하면 서로 다른 작업은 서로 다른 대화에서 하세요. 13장 개발자 노트의 isolate(격리) 전략 — 작업별로 컨텍스트를 분리 — 이 일상 사용에 적용된 형태입니다. 마케팅은 마케팅 창에서, 코딩은 코딩 창에서. 한 창에 여러 작업을 욱여넣으면 서로 간섭합니다.

정리: 대화 관리 의사결정

flowchart TB
    long["대화가 길거나<br/>모델이 헤매기 시작"] --> q1{"주제가<br/>바뀌었나?"}
    q1 -->|예| fresh["새 창에서 시작<br/>(작업 격리)"]
    q1 -->|아니오| q2{"맥락을<br/>이어야 하나?"}
    q2 -->|꼭 필요| compact["핵심 요약(압축)<br/>→ 새 출발점으로"]
    q2 -->|초반 규칙만 묻힘| restate["규칙을 지금<br/>다시 명시"]

    classDef dec fill:#fef9c3,stroke:#eab308,color:#713f12
    classDef act fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    class long,q1,q2 dec
    class fresh,compact,restate act

이 장에서 배운 것

• 멀티턴 대화는 매 턴 이전 기록 전체가 누적되어 다시 전달되므로, 길어질수록 윈도우를 잠식하고 비용·지연이 는다.
• 긴 대화의 세 문제는 누적(길어짐), 오염(무관한 것이 섞임), 부패(오류·잘못된 전제가 굳어짐)이다.
• 길이가 곧 이해는 아니다. 관련 맥락은 도움이 되지만 무관·모순·오류의 누적은 방해가 된다.
• 대응은 셋이다: 새 창에서 시작(격리), 핵심 요약으로 압축, 묻힌 규칙 재명시. 주제가 바뀌면 새 창, 맥락이 필요하면 압축이 기본이다.
• 가능하면 한 대화에 한 작업만 두어 오염을 예방한다.

✍️ 확인 문제

1. "대화를 길게 이어갈수록 모델이 더 똑똑해진다"는 주장을, 이 장의 세 문제(누적·오염·부패)를 사용해 비판적으로 검토해보세요.

1. 코딩 작업을 한참 하다가 같은 창에서 "이제 이걸 블로그 글로 소개해줘"라고 했더니 글이 지나치게 기술적으로 나왔습니다. 어떤 문제이고, 어떻게 대응하면 좋을까요?

1. (실습) 1시간짜리 기획 회의를 모델과 진행해 여러 결정을 내렸습니다. 이 대화를 다음 작업으로 이어가기 위한 "압축 요약" 프롬프트를 작성하고, 남길 것과 버릴 것을 구분해보세요.

다음 → 16. 관련 자료를 효과적으로 제공하기
이전 ← 14. 긴 컨텍스트와 중간 소실 · 목차