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"로 세 줄만 남겨도 압축이 무엇을 지우든 원본이 살아 있다. 기억은 압축되지만 기록은 압축되지 않는다.

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