문맥이 길어지면 규칙부터 흐려집니다. 다 다시 넣지 말고 골라서 넣으세요.
AI 도구와 오래 대화하면 어느 순간부터 답이 조금씩 어긋납니다. 틀린 답이 아니라 앞에서 정한 것과 다른 답이라 알아채기 어렵습니다. 이때 흔히 하는 대응이 두 가지인데 둘 다 잘 안 됩니다. 하나는 지금까지의 내용을 통째로 다시 붙여넣는 것이고, 다른 하나는 대화를 새로 열고 처음부터 설명하는 것입니다. 앞의 방법은 흐려진 상태를 더 길게 만들고, 뒤의 방법은 결정과 예외를 잃습니다. 실제로 효과가 있었던 것은 무엇이 흐려졌는지 먼저 확인하고 그 부분만 다시 넣는 방식이었습니다. 한 번에 다룰 수 있는 분량은 도구와 설정에 따라 다르므로, 숫자를 외우기보다 신호를 읽는 편이 실용적입니다.
흐려졌다는 신호
문맥이 잘리거나 약해질 때는 오류가 나지 않습니다. 대신 아래 같은 장면이 반복됩니다.
신호가 하나 보이면 그냥 다시 말해 주고, 두 개 이상 겹치면 정리할 때가 된 것으로 봤습니다.
특히 이미 폐기한 안으로 되돌아가는 제안이 나오면 늦은 편입니다. 결정 기록이 이미 빠진 상태입니다.
| 보이는 장면 | 무슨 뜻인가 | 그때 할 일 |
|---|---|---|
| 같은 규칙을 다시 설명하게 된다 | 지시가 흐려졌다 | 규칙만 짧게 다시 넣는다 |
| 이미 고친 자리를 또 고치자고 한다 | 변경 내역이 빠졌다 | 최근 변경만 다시 넣는다 |
| 폐기한 안을 다시 제안한다 | 결정 기록이 빠졌다 | 결정 목록을 다시 넣는다 |
| 파일 이름이나 경로를 다시 묻는다 | 세부가 잘렸다 | 경로 목록을 다시 넣는다 |
| 답이 점점 일반론이 된다 | 근거 자료가 빠졌다 | 근거 문서 한 개만 다시 넣는다 |
요약이 먼저 잃는 것
긴 대화를 줄일 때 요약을 만드는 것은 자연스러운 선택입니다. 다만 요약은 원문이 아니라는 점을 감안해야 합니다.
요약에서 가장 먼저 사라지는 것은 짧고 구체적인 정보입니다. 숫자, 경로, 예외 조건, 하지 않기로 한 것이 그렇습니다.
반대로 잘 살아남는 것은 목적과 방향처럼 문장으로 길게 쓰인 부분입니다. 그래서 요약본만 남기면 방향은 맞는데 세부가 틀린 결과가 나옵니다.
저는 요약을 안내용으로만 쓰고, 판단에 쓰이는 값은 원문 그대로 따로 모아 둡니다.
| 항목 | 요약에서 | 어떻게 다루나 |
|---|---|---|
| 목적과 방향 | 대체로 남는다 | 요약으로 충분 |
| 결정과 이유 | 이유가 먼저 빠진다 | 결정 목록을 따로 |
| 숫자와 경로 | 자주 사라진다 | 원문 그대로 보관 |
| 예외 조건 | 가장 먼저 사라진다 | 원문 그대로 보관 |
| 하지 않기로 한 것 | 거의 남지 않는다 | 금지 목록을 따로 |
다시 넣을 것과 빼도 되는 것
정리할 때 기준이 없으면 결국 전부 다시 붙여넣게 됩니다. 그러면 같은 문제가 조금 뒤에 다시 옵니다.
기준은 하나로 잡았습니다. 틀리면 되돌리기 어려운 것을 남기고 나머지는 뺍니다.
그래서 규칙, 결정, 금지 사항, 현재 상태, 경로는 남깁니다. 중간에 오갔던 논의, 시도했다가 접은 방법의 상세, 이미 반영된 지시는 뺍니다.
빼는 것이 아깝다면 그건 대화가 아니라 파일에 있어야 할 내용입니다. 대화에서 빼고 파일에서 필요할 때 다시 꺼냅니다.
| 항목 | 남기나 | 이유 |
|---|---|---|
| 지켜야 할 규칙 | 남긴다 | 어기면 되돌리기 어렵다 |
| 확정된 결정 | 남긴다 | 폐기한 안이 되살아난다 |
| 하지 않기로 한 것 | 남긴다 | 가장 먼저 잊힌다 |
| 현재 상태와 경로 | 남긴다 | 틀리면 엉뚱한 곳을 고친다 |
| 오갔던 논의 과정 | 뺀다 | 결론만 있으면 된다 |
| 접은 방법의 상세 | 뺀다 | 결정 목록에 한 줄이면 충분 |
| 이미 반영된 지시 | 뺀다 | 결과가 이미 코드에 있다 |
대화를 나누는 기준
언제 새 대화를 열지도 정해 두면 편합니다. 감으로 하면 늘 늦습니다.
주제가 바뀔 때 나눕니다. 같은 대화에서 다른 일을 시작하면 앞 주제의 규칙이 뒤 주제에 섞여 들어옵니다.
한 단위 작업이 끝났을 때도 나눕니다. 끝난 일의 세부는 다음 일에 도움이 되지 않으면서 자리만 차지합니다.
반대로 한 작업을 하는 중간에는 나누지 않습니다. 이때 나누면 방금 합의한 세부를 다시 설명하게 됩니다.
새 대화로 넘길 때 옮기는 것
새로 열 때 "아까 하던 것 이어서"라고 말하면 도구는 그 아까를 모릅니다. 무엇을 옮길지 정해 두면 몇 줄이면 끝납니다.
네 가지면 대개 충분합니다. 지금 무엇을 하는 중인지, 무엇은 건드리지 않기로 했는지, 마지막으로 확인한 상태가 무엇인지, 다음에 할 일 한 가지가 무엇인지입니다.
여기에 확인하지 못한 항목을 한 줄 덧붙이면 더 좋습니다. 비워 두면 확인했다는 뜻으로 읽힙니다.
이 네다섯 줄을 매번 손으로 쓰기보다 파일 한 장으로 두고 갱신하는 편이 오래갑니다.
매번 다시 보내는 비용
문맥을 길게 유지하면 편하지만 대가가 있습니다. 대부분의 도구는 주고받은 내용을 기준으로 사용량을 계산합니다.
대화가 길어질수록 매 요청마다 앞부분이 함께 전달되므로, 같은 질문이어도 뒤로 갈수록 비싸집니다.
정확한 계산 방식과 요금은 도구와 요금제에 따라 다르고 자주 바뀌므로 단정하기 어렵습니다. 다만 길어질수록 늘어난다는 방향은 공통입니다.
그래서 문맥을 줄이는 일은 정확도만의 문제가 아닙니다. 필요한 것만 남기면 답도 좋아지고 비용도 줄어듭니다.
자주 묻는 질문
Q. 문맥 한계는 몇 자인가요?
A. 도구와 설정에 따라 다르고 자주 바뀝니다. 같은 규칙을 다시 설명하게 되는 시점을 신호로 삼는 편이 확실합니다.
Q. 전체를 다시 붙여넣으면 안 되나요?
A. 흐려진 상태를 더 길게 만듭니다. 무엇이 빠졌는지 먼저 확인하고 그 부분만 넣는 편이 결과가 좋습니다.
Q. 요약본만 남기면 안 되나요?
A. 요약은 안내로는 좋지만 판단 기준으로는 위험합니다. 숫자, 경로, 예외 조건은 원문 그대로 따로 보관하세요.
Q. 대화를 자주 나누면 손해 아닌가요?
A. 주제가 바뀔 때와 한 단위가 끝났을 때만 나누면 손해가 크지 않습니다. 한 작업 중간에 나누는 것이 실제로 손해입니다.
확인 자료
- 자체 개발 운영 문서 · 개발루틴 템플릿 v1.3 중 대화 문맥 유실 대비 규칙
- 같은 문서의 인수인계 항목 구성
- 장기 대화에서 반복 관찰한 증상 기록
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.