AI 에이전트의 기억은 어떻게 사라지는가: 컴팩션 리스크 5가지

AI 코딩 에이전트와 두 시간 넘게 대화하다 보면 갑자기 에이전트가 방금 정한 규칙을 까먹는다. 분명 "이 파일은 건드리지 말라"고 못 박았는데 다음 지시에서 그 파일을 고친다. 배신이 아니다. 기억이 물리적으로 잘려 나간 것이다.

이 글은 그 절단면이 왜 생기는지, 실무에서 어떤 사고로 이어지는지, 사고를 줄이려면 무엇을 확인해야 하는지를 다룬다. 특정 제품의 내부 함수명이 아니라 어떤 AI 코딩 에이전트에도 적용되는 구조 원리로 설명한다.

대화가 길어지면 왜 요약이 필요한가

AI 에이전트는 대화 전체를 "맥락 창(컨텍스트 윈도우, Context Window)"이라는 제한된 작업대 위에 올려 두고 일한다. 도서관이 아니라 책상이라고 생각하면 쉽다. 책상은 넓어 보여도 결국 끝이 있다. 대화가 길어지면 이전 메시지, 읽은 파일, 실행한 명령 로그가 쌓이면서 이 책상이 꽉 찬다.

책상이 넘치기 직전, 에이전트는 오래된 내용을 압축해서 요약본 하나로 바꾼다. 이 압축 작업을 컴팩션(Compaction, 맥락 압축)이라고 부른다. 이사 갈 때 박스 열 개를 상자 하나에 욱여넣는 것과 비슷하다. 부피는 줄지만 무언가는 버려야 들어간다. 무엇을 버릴지 정하는 그 판단이 이 글의 핵심 주제다.

압축은 한 가지 방식으로만 일어나지 않는다. 대화가 자연스럽게 끝나는 시점에 정리하는 경우도 있고, 책상이 거의 다 찼을 때 급하게 줄이는 경우도 있고, 대화 도중 조용히 조금씩 다듬는 경우도 있다. 방식은 달라도 목적은 같다. 다음 대화까지 살아남을 정보를 고르는 것이다. 이 선별 과정에서 실무에 영향을 주는 손실이 발생한다.

컴팩션에서 사라지기 쉬운 것 5가지

같은 압축이라도 무엇이 빠지느냐에 따라 사고 유형이 갈린다. 다섯 가지로 정리했다.

위험	무엇이 사라지는가	실무에서 벌어지는 일
낡은 기억(Stale Memory)	이미 바뀐 결정·상태가 최신인 것처럼 남는다	지운 함수를 다시 쓰라고 지시하거나, 어제 뒤집은 방침을 오늘도 따른다
잊힌 숙제(Lost Obligation)	아직 안 끝난 작업, 막힌 지점이 요약에서 빠진다	"거의 다 했다"던 작업이 다음 대화에서 통째로 사라진 취급을 받는다
출처 실종(Source Drift)	주장은 남고 그 주장이 어디서 왔는지는 빠진다	왜 그렇게 결정했는지 되물으면 답을 못 하고 그럴듯하게 지어낸다
사생활 승격(Privacy Leak)	이번 대화 한정이어야 할 민감 내용이 장기 기억으로 넘어간다	일회성으로 공유한 키·개인정보가 다음 세션 요약에도 계속 등장한다
과잉 압축(Over-Compression)	검증 근거와 "확실하지 않다"는 단서가 지워진다	불확실했던 추정이 다음 대화에서는 검증된 사실처럼 단정된다

위험1·2 — 낡은 기억과 잊힌 숙제

낡은 기억부터 보자. 압축은 보통 "가장 최근 내용이 가장 중요하다"는 규칙으로 오래된 부분을 먼저 줄인다. 문제는 오래됐다고 다 낡은 게 아니라는 점이다. 프로젝트 초반에 정한 원칙, 예를 들어 "이 API는 절대 외부에 노출하지 않는다" 같은 결정은 시간이 지나도 여전히 유효하다. 그런데 압축 알고리즘이 "오래됨 = 덜 중요함"으로 단순화하면 이런 원칙이 요약본에서 통째로 빠질 수 있다.

결과는 재발이다. 이미 한 번 논의하고 폐기한 방식을 에이전트가 다시 제안한다. 사람이었다면 "그거 지난주에 안 되는 거 확인했잖아요"라고 짜증 낼 상황인데, 에이전트 입장에서는 정말 처음 듣는 이야기다. 요약본에 그 결론이 없었으니까.

잊힌 숙제는 조금 다른 결이다. 압축은 "완결된 대화"를 요약하기 좋아한다. 질문하고 답하고 끝난 흐름은 한 문장으로 정리하기 쉽다. 반면 "지금 절반쯤 진행 중이고 다음에 이어서 할 일"은 요약하기 애매하다. 끝나지 않았으니 결론이 없고, 결론이 없으니 요약 문장으로 압축할 때 우선순위에서 밀린다.

그래서 실무에서는 이런 일이 생긴다. "결제 모듈 리팩터링 80%까지 했고 남은 20%는 에러 처리다"라는 상태가 압축을 거치며 "결제 모듈 작업함" 정도로 뭉뚱그려진다. 다음 대화에서 에이전트는 남은 20%가 있었다는 사실 자체를 모른다. 진행 중이던 일이 완료된 일처럼 보이거나, 아예 존재하지 않았던 일처럼 지워진다.

위험3·4 — 출처 실종과 사생활 승격

출처 실종은 겉으로 잘 안 보여서 더 위험하다. 압축은 보통 결론만 남기고 그 결론에 이른 과정은 지운다. "이 라이브러리 대신 저걸 쓰기로 했다"는 남지만 "왜냐하면 공식 문서 몇 페이지에 이런 제약이 있어서"는 사라진다. 결론과 근거가 분리되면 결론은 남되 검증 가능성이 없어진다.

이게 왜 문제인가 하면, 나중에 그 결론이 틀렸다는 게 밝혀져도 왜 그런 결론을 냈는지 추적할 방법이 없기 때문이다. 사람이 회의록 없이 "그때 그렇게 하기로 했잖아"라고만 기억하는 상황과 같다. 다시 확인하려면 원점부터 다시 조사해야 한다. 에이전트에게 "그 근거가 뭐였냐"고 물으면, 진짜 기억이 없는데도 그럴듯한 답을 지어내는 경우까지 생긴다. 확신에 찬 말투와 실제 근거의 유무는 별개다.

사생활 승격은 방향이 반대다. 어떤 정보는 오히려 너무 오래 남는다. 대화 중에 임시로 붙여넣은 접속 정보나 특정 프로젝트의 민감한 세부사항은 그 대화 안에서만 쓰이고 끝나야 한다. 그런데 압축 과정이 "이번 대화에서 자주 언급됐다"는 이유만으로 그 내용을 장기 기억 후보로 승격시키면, 원래는 한 번 쓰고 버려져야 할 정보가 다음 세션까지 따라온다.

이 두 위험은 서로 거울상이다. 지켜야 할 근거는 지워지고, 지워야 할 임시 정보는 남는다. 압축 로직이 "중요도"를 판단하는 기준이 실제 보안·검증 기준과 다르게 작동하기 때문에 생기는 어긋남이다.

위험5 — 확신만 남고 근거가 사라진다

마지막은 과잉 압축이다. 앞의 넷이 "무엇이 빠지는가"의 문제라면 이건 "남은 것의 어조가 어떻게 바뀌는가"의 문제다. 원래 대화에서는 "이 방식이 맞을 가능성이 높지만 A 케이스는 아직 테스트 안 했다"처럼 단서가 붙어 있었다. 압축을 거치면 이 단서가 문장 길이를 줄이는 과정에서 가장 먼저 잘려 나간다. 남는 문장은 "이 방식이 맞다"뿐이다.

불확실성 표현은 문장에서 부피는 크고 핵심 정보 밀도는 낮아 보인다. 그래서 압축 알고리즘 입장에서는 지우기 좋은 부분이다. 하지만 그 몇 마디가 사실은 제일 중요한 안전장치였다. "아직 검증 안 됨"이라는 꼬리표가 없어지면 추정이 사실로 둔갑한다.

이게 실무에서 어떻게 터지는가. 초반에 "이 성능 개선안은 이론상 맞는데 실측은 안 해봤다"고 나눈 대화가 압축되면 "성능 개선안 적용함"으로 남는다. 몇 주 뒤 다른 작업을 하다가 이 개선안을 전제로 새 기능을 얹는다. 그런데 애초에 실측을 안 했으니 전제 자체가 무너져 있을 수 있다. 검증되지 않은 가정 위에 새 결정이 쌓이는 구조다.

다섯 가지를 관통하는 원리는 하나다. 압축은 "짧게 만드는 일"이 아니라 "무엇을 남기고 무엇을 버릴지 판단하는 일"이다. 판단 기준이 실무 우선순위와 다르면, 짧아진 결과물은 매끈하지만 위험하다. 관련해서 여러 AI 에이전트를 동시에 굴릴 때 생기는 다른 유형의 사고는 멀티 에이전트 실패 패턴 글에서 따로 다뤘다.

체크리스트 — 압축 전에 5초만 확인한다

완벽하게 막을 방법은 없다. 다만 압축이 일어나기 전이나 직후에 몇 가지만 확인해도 사고 절반은 피할 수 있다.

• 지금까지 정한 결정 중 "여전히 유효한 원칙"이 있다면 대화와 별개로 문서나 별도 메모에 따로 적어 뒀는가.
• 진행 중인 작업의 완료 비율과 남은 단계를 에이전트에게 명시적으로 다시 확인시켰는가.
• 중요한 결론에는 "왜 그렇게 정했는지" 근거나 출처를 함께 남겼는가.
• 이번 대화에서만 쓰고 끝나야 할 민감 정보(키, 개인정보, 내부 세부사항)를 대화 후 직접 정리하거나 삭제했는가.
• "아직 검증 안 됨", "가능성이 높음" 같은 불확실성 표현이 요약 이후에도 그대로 남아 있는지 확인했는가.
• 긴 작업을 시작하기 전에 중간 저장 지점(체크포인트)을 만들어 뒀는가.

이 중 가장 효과가 큰 습관은 첫 번째와 세 번째다. 정말 중요한 결정은 애초에 에이전트의 기억력에만 맡기지 않는다. 별도 문서에 "결정: OO, 이유: OO, 날짜: OO"로 세 줄만 남겨도 압축이 무엇을 지우든 원본이 살아 있다. 기억은 압축되지만 기록은 압축되지 않는다.

남은 숙제도 있다. 지금은 사람이 수동으로 "이건 중요하니 따로 적어 두자"고 판단해야 한다. 다음 단계는 이 판단 자체를 에이전트가 압축 시점에 스스로 체크리스트처럼 돌리게 만드는 일이다. 관련 논의는 프로그래밍 카테고리에서 계속 이어간다.

압축 전후를 비교하는 체크포인트 형식

컴팩션 사고는 요약이 짧다는 이유만으로 발견되지 않는다. 압축 전 원본과 압축 후 요약을 같은 항목으로 비교해야 무엇이 사라졌는지 보인다. 이를 위해 긴 작업을 시작할 때 대화 바깥의 파일이나 메모에 체크포인트를 하나 만든다. 도구가 자동으로 만든 자유 형식 요약을 그대로 저장하는 대신, 결정·미완료 작업·근거·민감 정보·확신 수준을 분리해 적는다.

현재 목표: 이번 작업이 끝났다고 판정할 조건
유효한 결정: 결정 내용 / 이유 / 정한 시점
손대지 않을 범위: 파일, 데이터, 권한
완료한 일: 결과와 확인 근거
남은 일: 다음 행동 / 막힌 이유 / 담당
출처: 결론을 다시 확인할 원문 위치
확신 수준: 확인됨 / 일부만 확인 / 아직 검증 안 됨
민감 정보: 기록하지 않음, 별도 안전한 위치만 표시

여기서 완료한 일과 남은 일을 반드시 다른 줄에 둔다. "결제 모듈 작업함"처럼 상태와 행동을 섞으면 압축 뒤 완료 여부를 알 수 없다. "결제 요청 저장 완료, 중복 콜백 처리는 남음"처럼 결과와 숙제를 나누면 다음 세션에서 첫 행동이 바로 보인다. 완료 비율은 근거가 있을 때만 보조로 쓰고, 남은 단계의 이름을 생략하지 않는다.

1. 압축이 예상되기 전 현재 대화에서 결정 문장과 미완료 표현을 찾는다. "하기로 함", "하지 않음", "남음", "막힘", "검증 안 됨"처럼 상태를 바꾸는 문장을 우선 확인한다.
2. 각 결정을 체크포인트의 항목으로 옮기되, 결론과 이유를 같은 줄에 둔다. 링크나 파일 경로가 근거라면 설명으로 바꾸지 말고 다시 열 수 있는 위치를 남긴다.
3. 일회성 접속 정보나 개인정보는 요약에 복사하지 않는다. 필요한 경우 값이 아니라 "별도 안전한 저장 위치에서 확인"처럼 존재와 접근 경로만 기록한다.
4. 압축이 끝난 뒤 새 요약을 체크포인트와 한 줄씩 대조한다. 새 요약에 없는 항목은 기억에 맡기지 말고 다음 지시에서 명시적으로 복원한다.
5. 서로 충돌하는 내용이 있으면 최신처럼 보이는 문장을 자동 채택하지 않는다. 원본 근거와 변경 시점을 확인할 때까지 충돌 상태로 표시한다.

비교 결과	위험 신호	복구 행동
결정은 남고 이유가 없다	출처 실종	원문 위치와 결정 이유를 다시 연결
진행한 일만 있고 남은 일이 없다	잊힌 숙제	미완료 단계와 막힌 이유를 다음 지시에 복원
"검증 안 됨"이 단정문으로 바뀌었다	과잉 압축	원래 확신 수준을 되살리고 검증 전 사용 중단
폐기한 결정과 새 결정이 함께 남았다	낡은 기억	결정 시점과 대체 관계를 표시
민감한 값이 요약에 그대로 있다	사생활 승격	값을 제거하고 노출 범위와 후속 조치 확인

이 절차의 한계도 분명하다. 원본 대화 자체가 남아 있지 않거나 체크포인트를 만들기 전에 내용이 잘렸다면, 나중에 정확한 이유를 복원할 수 없다. 그때는 그럴듯한 이유를 다시 만들어 채우지 말고 "근거를 복구하지 못함"으로 남겨야 한다. 또한 체크포인트가 오래되면 그 문서 자체가 낡은 기억이 될 수 있으므로, 결정을 뒤집을 때는 이전 문장을 조용히 덮어쓰지 말고 무엇이 무엇을 대체했는지 표시해야 한다.

체크포인트는 대화를 더 길게 보존하려는 장치가 아니다. 다음 세션이 최소한 같은 목표, 같은 금지 범위, 같은 미완료 목록에서 다시 시작하게 만드는 인계 장치다. 자동 요약이 잘됐는지 평가하는 기준도 문장 품질이 아니라, 이 항목들을 잃지 않았는지다. 읽기 좋은 요약보다 다시 실행 가능한 상태 기록이 실무에서는 더 중요하다.

자주 묻는 질문

중요한 결정을 대화 요약에만 남겨도 되는가?

중요한 결정은 에이전트 기억에만 맡기지 않는 편이 안전하다. 별도 문서에 결정·이유·날짜를 함께 적어 두면 압축 과정에서 오래된 원칙이나 근거가 빠져도 원본 기록을 기준으로 다시 확인할 수 있다.

진행 중인 작업이 압축 뒤에 완료된 것처럼 보일 수 있는가?

그럴 수 있다. 결론이 없는 미완료 작업은 요약 우선순위에서 밀려 남은 단계가 사라지기 쉽다. 압축 전후에 완료 비율과 남은 일을 명시적으로 확인하고, 긴 작업에는 중간 저장 지점을 만들어야 한다.

대화에서 자주 언급한 민감 정보는 장기 기억에 남겨도 되는가?

자주 언급됐다는 이유만으로 접속 정보나 프로젝트의 민감한 세부사항을 승격하면 안 된다. 이번 대화에서만 쓸 정보는 대화 후 직접 정리하거나 삭제해 다음 세션 요약까지 따라가지 않게 해야 한다.

요약에서 결론만 남고 ‘아직 검증 안 됨’이 빠지면 왜 위험한가?

불확실성 꼬리표가 사라지면 추정이 검증된 사실처럼 바뀐다. 이후 작업이 그 단정적인 결론을 전제로 쌓일 수 있으므로, 근거와 함께 ‘가능성이 높음’ 같은 확신 수준도 압축 뒤에 그대로 남았는지 확인해야 한다.