안녕하세요, Maneshwar입니다. 저는 모든 커밋에서 실행되는 마이크로 AI 코드 리뷰어인 git-lrc를 만들고 있습니다. 이 프로젝트는 Github에서 무료로 이용 가능하며 소스 코드가 공개되어 있습니다. 개발자들이 이 프로젝트를 발견할 수 있도록 git-lrc에 Star를 눌러주세요. 꼭 한번 사용해 보시고 피드백을 공유해 주세요.

컨텍스트 엔지니어링 (context engineering) 시리즈의 파트 2입니다. 파트 1은 전체적인 지형도였습니다. 이번 편은 다루기 어려운 영역 중 하나인, 흐름(plot)을 놓치지 않으면서도 불필요한 것들을 버리는 규율에 관한 내용입니다.

장기 실행 에이전트 (long-running agent)를 구축하는 모든 이들에게 발생하는 현상이 있습니다.

10번째 턴(turn)에서는 정말 천재적입니다.

날카롭고, 빠르며, 당신이 요청한 것을 정확히 기억하고, 까다로운 버그를 정교하게 해결합니다.

당신은 마치 마법사가 된 기분을 느낍니다.

80번째 턴이 되면, 그것은 전혀 다른 생명체가 되어 있습니다.

이미 거절했던 수정 사항을 다시 제안합니다.

20턴 전에 편집했던 파일을 "잊어버립니다".

초기에 함께 내렸던 결정을 스스로 부정합니다.

동일한 모델, 동일한 프롬프트 (prompt), 동일한 작업임에도 불구하고, 더 많은 것을 학습할수록 왠지 모르게 더 "멍청해진" 것입니다.

이것은 모델의 버그가 아닙니다.

책상 위가 가득 찼기 때문입니다.

파트 1에서 저는 컨텍스트 윈도우 (context window)가 하드 드라이브가 아니라 RAM, 즉 명확한 한계가 있는 작업 기억 장치(working memory)라는 점을 논증했습니다.

모델이 추론할 수 있는 모든 것은 책상 위에 올라가 있어야 합니다.

긴 대화란 그 책상 위에 종이를 계속 쌓아두기만 하고 한 번도 치우지 않을 때 발생하는 현상입니다.

결국 중요한 문서가 400줄에 달하는 도구 출력값 (tool output) 아래에 파묻히게 되고, 모델은 종이 눈사태 속에 서서 파티 중에 당신의 세금 계산을 하고 있는 꼴이 됩니다.

압축 (Compaction)은 중요한 문서를 쓰레기통에 쓸어 넣지 않으면서 책상을 정리하는 방법입니다.

파트 1에서 다룬 네 가지 단계인 쓰기 (write), 검색 (retrieve), 압축 (compact), 격리 (isolate) 중에서 사람들이 가장 자신 있게 틀리는 것이 바로 이 압축입니다.

겉보기에는 사소해 보이기 때문입니다: "그냥 대화를 요약하면 되잖아."라고 생각하죠. 그러고는 요약기 (summarizer)를 배포하지만, 그들의 에이전트는 조용히 정신을 잃기 시작합니다.

제대로 해봅시다.

압축의 실제 정의 (그리고 정의가 아닌 것)

압축은 _의미 (meaning)_를 위한 손실 압축 (lossy compression)입니다.

길고 방대한 이력을 가져와서, 다음 단계에 중요한 것은 보존하고 그렇지 않은 것은 버리는 더 짧은 표현(representation)으로 교체하는 것입니다.

'손실(lossy)'이라는 부분이 핵심입니다.

만약 무손실(lossless)이라면 도움이 되지 않을 것입니다. 그저 다른 글꼴로 쓰인 동일한 토큰들을 갖게 될 뿐이니까요.

압축(Compaction)은 정확히 정보를 버리기 때문에 작동합니다.

기술의 핵심은 무엇을 버리느냐에 있습니다.

다음 두 가지는 압축이 아니며, 이 둘을 혼동하면 문제가 생길 것입니다:

**삭제 (Clearing)**는 기억상실입니다. /clear는 이력을 모두 지우고 새로 시작합니다. 작업(task)을 전환할 때는 유용하지만, 작업 도중에는 재앙입니다.
**다듬기 (Trimming)**는 기계적입니다. 모델의 개입 없이 엄격한 규칙에 따라 가장 오래된 N개의 메시지를 삭제합니다. 저렴하고, 빠르며, 멍청합니다. 가장 오래된 메시지가 전체 작업의 핵심이 되는 결정 사항이라는 것을 알지 못합니다.

압축(Compaction)은 그 사이에 위치합니다. 다듬기(trimming)보다는 똑똑하고, 삭제(clearing)보다는 덜 파괴적입니다.

압축은 모델을 사용하여 무엇을 유지할 가치가 있는지 결정하고, 나머지는 밀도 높은 무언가로 다시 작성합니다.

왜 "그냥 요약하세요"가 잘못되는가

단순한 압축은 이름을 붙일 만한 방식으로 실패합니다. 이름을 붙일 수 있게 되면, 그에 대비하여 설계할 수 있기 때문입니다.

Drew Breunig은 긴 컨텍스트(long context)가 어떻게 부패하는지에 대한 명확한 분류 체계(taxonomy)를 제시했는데, 이 모든 현상은 부주의한 압축에 의해 유발될 수 있습니다:

• 오염 (Poisoning): 환각(hallucination)이 요약본에 포함되고, 이제 그것은 기반이 됩니다. 모델은 자신의 이전 실수를 확립된 사실로 취급하고 그 위에 내용을 쌓아갑니다. 압축은 추측을 "결정"으로 세탁할 수 있습니다.
• 주의 분산 (Distraction): 요약본이 너무 많은 것을 유지하여 원래의 비대함(bloat)을 그대로 재현합니다. 축하합니다, 50K 대화 내용을 48K로 압축하셨군요.
• 혼란 (Confusion): 불필요한 세부 사항이 걸러지지 않고 살아남아 모델을 무관한 작업으로 끌어들입니다.
• 충돌 (Clash): 요약본과 실시간 메시지가 서로 일치하지 않으며, 모델은 두 가지 현실 버전 사이의 싸움을 중재해야 합니다.

그리고 반복적인 압축에서만 나타나는 고유한 실패 모드가 있는데, 이것이 가장 무서운 것입니다: 바로 **누적 침식 (cumulative erosion)**입니다.

각각의 압축 (compaction)은 손실이 발생합니다 (lossy).

압축된 내용을 다시 압축하면 조금씩 더 많은 것을 잃게 됩니다.

마라톤 세션 동안 이를 다섯 번 반복하면, 당신은 자신의 작업과 '전화기 놀이 (telephone game)'를 한 셈이 됩니다. 에이전트는 이제 요약의 요약, 그리고 또 그 요약의 요약을 바탕으로 작업하고 있으며, 당신이 3번째 턴에 설정한 구체적인 제약 조건(

“사용자가 인증 모듈을 건드리지 말라고 말했다”는 오래된 대화 노이즈처럼 보입니다.

두 번째 것은, 이것을 잃었을 때 에이전트가 자신이 만지지 말라는 지시를 받은 바로 그 일을 자신감 있게 수행하게 만드는 것입니다.

제약 조건(constraints)을 고정하세요.

그것들은 모든 압축 과정에서도 변경되지 않고, 절대 의역되어서는 안 됩니다.

실제 도구들이 하는 방식

두 가지 상용 코딩 에이전트를 비교할 가치가 있습니다. 왜냐하면 이들은 문제에 대해서는 동의하지만, 해결 방식에는 의견 차이가 있기 때문입니다.

Claude Code는 자동화에 의존합니다.

수동 /compact 명령어가 있지만, 주요 동작은 컨텍스트 창의 약 95%에서 자동으로 압축이 발생하며, 전체 과정을 요약하고 그 요약을 시드(seed)로 삼아 새로 시작합니다.

사용자가 이를 유도할 수 있습니다(` /compact

모델에는 지금 당장 일어나고 있는 일에 대한, 의역되지 않은 생생한 스레드(thread)가 필요합니다.

제약 사항을 고정(Pin)하고, 사용자에게 그 사실을 알리세요. 사용자의 제약 사항을 모든 압축(compaction) 과정에서 정확한 텍스트로 유지해야 합니다. 이 제약 사항들은 유실되었을 때 가장 큰 피해를 주는 요소이기 때문입니다.

작업 도중에 동작을 변화시키는 조용한 압축은 마치 에이전트가 갑자기 성능이 저하된 것처럼 느껴지게 만듭니다. 하지만 한 줄의 설명("컨텍스트 확보를 위해 히스토리를 압축했습니다")은 이 미스터리를 하나의 트레이드오프(tradeoff)로 바꿔줍니다.

그리고 시작 프롬프트(starting prompt)가 필요하므로, 하나를 예로 들겠습니다:

이 코딩 세션이 새로운 컨텍스트에서 계속될 수 있도록 핸드오프 요약(handoff summary)을 생성하세요.
이 요약본이 사용 가능한 유일한 히스토리가 될 것이므로, 다음을 보존하세요:

...

마지막 줄인 — 지어내지 마세요(do not invent) — 는 오염(poisoning)에 맞서는 가장 저렴한 방어 수단입니다.

요약기(summarizer)의 역할은 압축이지, 창의성이 아닙니다.

요약기가 빈틈을 채우기 시작하는 순간, 그것은 80번째 턴에서 마치 진리처럼 받아들여질 환각(hallucination)을 제조하게 됩니다.

불편한 부분

압축은 나머지 스택(stack)이 회피하게 해주는 사실을 인정하도록 강요합니다: 모든 것을 유지할 수는 없으므로, 에이전트가 무엇을 잊어도 될지 결정해야 합니다.

외부 메모리(External memory)와 검색(retrieval)을 사용하면 이를 회피하여, 나중에 다시 꺼내 쓸 수 있도록 저장해 둘 수 있습니다.

하지만 유한한 책상 위에서 진행되는 단일 장기 작업(long-running task) 내부에서는 더 이상 회피할 방법이 없습니다.

무언가는 사라져야 하며, 압축은 컨텍스트 윈도우(context window)가 가장 중요한 제약 사항을 주의력의 가장자리 밖으로 조용히 밀어내어 스스로 결정하게 두는 대신, 무엇을 살아남길 원하는지 의도적으로 선택하는 과정입니다.

최고의 엔지니어링이 그러하듯, 최고의 압축 또한 대부분은 뺄셈입니다.

documents_v2는 유지하고 JSON은 태워버리는 것, 단 한 줄의 제약 사항이 수천 줄의 잡담보다 더 오래 살아남게 하는 것입니다.

1부에서 언급한 만트라(mantra)가 여기서 더욱 날카로워집니다: 최고의 토큰은 당신이 보낼 필요가 없었던 토큰입니다.

압축은 어떤 토큰이 바로 그 토큰이었는지 찾아내고, 그것들을 삭제할 배짱을 갖는 방법입니다.

면책 조항: 이 글은 제가 작성하였으며, 문법 수정 및 가독성 향상을 위해 AI가 사용되었습니다.

AI 에이전트(AI agents)는 코드를 빠르게 작성합니다. 하지만 사용자에게 알리지 않고 로직을 조용히 삭제하거나, 동작을 변경하고, 버그를 유발하기도 합니다. 이러한 문제는 종종 프로덕션(production) 환경에서 발견되곤 합니다.

git-lrc는 이 문제를 해결합니다. 이 도구는 git 커밋(commit)에 후킹(hook)하여, 변경 사항이 반영되기 전에 모든 디프(diff)를 검토합니다. 설정에는 60초면 충분하며, 완전히 무료입니다.

모든 피드백과 기여자를 환영합니다! 이 프로젝트는 온라인에 공개되어 있으며, 소스 공개(source-available) 상태로 누구나 사용할 준비가 되어 있습니다.

⭐ GitHub에서 Star를 눌러주세요:

HexmosTech / git-lrc

커밋 시 실행되는 무료 마이크로 AI 코드 리뷰 (Micro AI Code Reviews)

| 🇩🇰 덴마크어 | 🇪🇸 스페인어 | 🇮🇷 페르시아어 | 🇫🇮 핀란드어 | 🇯🇵 일본어 | 🇳🇴 노르웨이어 | 🇵🇹 포르투갈어 | 🇷🇺 러시아어 | 🇦🇱 알바니아어 | 🇨🇳 중국어 | 🇮🇳 힌디어 |

git-lrc

커밋 시 실행되는 무료 마이크로 AI 코드 리뷰 (Micro AI Code Reviews)