AI 코딩 세션이 잘 굴러가다가 어느 순간부터 답변이 이상해진 경험, 있으신가요? 세션을 새로 시작하면 나아질 것 같아서 껐다 켰는데, 사실 그게 문제를 고친 게 아니라 더 나쁜 상태를 만든 것일 수 있습니다.

소프트웨어 엔지니어이자 저자인 Andrew Stellman이 O’Reilly Radar에 연재 중인 에이전틱 엔지니어링 시리즈의 6번째 글을 발표했습니다. 주제는 컨텍스트 관리(context management) — AI 개발에서 실제 결과물의 품질을 좌우하는 핵심 기술이지만, 프롬프트 엔지니어링이나 모델 선택에 비해 거의 다뤄지지 않는 분야입니다.

출처: Why Doesn’t Anyone Teach Developers About Context Management? – O’Reilly Radar

컨텍스트 손실은 에러 메시지 없이 일어난다

컨텍스트란 AI가 지금 이 순간 “생각하고 있는 것” 전부입니다. 지금까지의 대화, 읽어들인 파일, 함께 내린 결정들이 모두 포함됩니다. 컨텍스트 윈도우(context window)는 AI가 한 번에 처리할 수 있는 이 정보의 최대량인데, 이게 가득 차면 AI는 자동으로 압축(compaction)을 시작합니다. 무엇을 버릴지는 AI가 결정하고, 개발자는 그 과정을 통제할 수 없습니다.

문제는 이 손실이 조용히 일어난다는 겁니다. 스택 트레이스도, 에러 메시지도 없습니다. AI는 그냥 계속 답변을 내놓는데, 그 답변이 조금씩 나빠지기 시작합니다. Stellman은 이걸 소프트웨어 개발에서 누락된 요구사항에 비유합니다. 요구사항이 빠지면 코드가 잘못 만들어지지만 그 이유를 알 수 없듯, 컨텍스트가 사라지면 AI 답변이 나빠지지만 무엇이 사라졌는지 알 방법이 없습니다.

Microsoft 개발자 블로그에 따르면, 한 개발자가 AI에게 이전 세션에서 이미 설명했던 내용을 다시 설명하는 데 하루 68분을 쓰고 있다는 사실을 직접 측정했습니다. 컨텍스트 손실의 비용은 이처럼 실제로 측정 가능한 수준입니다.

세션 재시작은 압축이 아니라 기억 상실이다

많은 개발자들이 Cursor나 Copilot에서 “Compacting conversation” 메시지를 보거나 컨텍스트 게이지가 차오르면 세션을 닫고 새로 시작합니다. 뭔가 해결된 것 같은 느낌이 들기 때문입니다.

하지만 Stellman은 이것이 잘못된 직관이라고 지적합니다. 압축은 손실이 있지만 이전까지 축적된 이해의 일부는 살아 있습니다. 반면 새 세션은 완전한 기억 상실입니다. AI는 여전히 코드를 만들고 답변을 줍니다. 표면적으로는 정상처럼 보입니다. 하지만 이전 세션에서 파악했던 패턴, 내려놓은 결정들, 발견한 주의사항들은 전부 사라진 채로 작업을 이어갑니다.

가비지 컬렉션으로 이해하는 컨텍스트 압축

Stellman이 제안하는 비유가 특히 개발자들에게 직관적입니다. Java의 GC(가비지 컬렉션) 그래프를 떠올려 보세요. 메모리가 서서히 차오르다 GC가 실행되면 한 번에 뚝 떨어집니다. 런타임이 아직 참조되고 있는 것만 남기고 나머지를 버리는 과정입니다.

컨텍스트 윈도우도 같은 방식으로 동작합니다. 대화가 쌓이고 컨텍스트가 꽉 차면, 압축이 일어나고 무엇이 살아남을지는 모델(또는 도구)이 결정합니다. Java 개발자들이 GC가 중요한 객체를 날려버리지 않도록 메모리 할당 패턴을 설계하는 법을 익혔듯, AI 개발자도 컨텍스트 압축이 중요한 정보를 날려버리지 않도록 워크플로우를 설계해야 합니다.

그 방법의 핵심은 중요한 정보를 컨텍스트 윈도우 밖으로 내보내는 것입니다. 마크다운 파일에 써두면 압축이 건드릴 수 없습니다. 새 세션을 시작해도 파일을 읽으면 다시 불러올 수 있습니다.

“왜”를 기록하지 않으면 AI가 과거 결정을 되돌린다

컨텍스트를 파일로 남길 때, 결정만 기록하는 것으로는 부족합니다. 이유(reasoning)까지 함께 남겨야 합니다.

Stellman이 실제로 겪은 사례입니다. Octobatch 프로젝트에서 자동 새로고침 구현에 set_interval() 대신 set_timer()를 재귀적으로 사용했습니다. 특정 화면 전환 상태에서 set_interval() 콜백이 신뢰할 수 없게 동작하기 때문이었습니다. 이 이유가 컨텍스트 파일에 없었다면, 새 세션의 AI는 “더 깔끔한” set_interval() 방식으로 리팩터링을 제안했을 겁니다. 합리적인 판단으로, 의도적인 결정을 조용히 무너뜨리는 것입니다.

이유 없이 기록된 모든 기술적 결정, 품질 기준, 비관습적인 코드 패턴은 나중 세션의 AI가 “최적화”라는 이름으로 제거할 위험에 노출됩니다.

너무 적게, 너무 많이 — 양쪽 다 함정이다

컨텍스트 외재화가 답처럼 들리지만, 과도하게 하면 역효과가 납니다. Stellman이 Quality Playbook을 virtio-win에 적용했을 때, 분석 대상을 10개 파일에서 60개로 늘리자 버그 발견율이 75% 감소했습니다. AI가 실제 버그가 있는 전송 계층을 깊이 파고드는 대신, 수십 개의 참조 파일 사이를 오가는 데 컨텍스트를 소진해버린 겁니다.

좋은 컨텍스트 파일의 기준은 “이 세션에 필요한 것만, 그리고 그것 전부”입니다. 저장해야 할 것, 컨텍스트 안에 유지할 것, 버려도 되는 것을 구분하는 판단 자체가 AI 개발의 핵심 역량이 됩니다.

AI 개발의 암묵지가 명시지로 바뀐다

Stellman이 이 글에서 짚는 흥미로운 지점이 있습니다. 컨텍스트 파일에 결정과 이유를 기록하는 일은, 사실 개발자들이 원래 해야 했던 것 — ADR(아키텍처 결정 기록), 설계 문서, 코드 주석 — 과 다르지 않습니다. 차이는 AI와 함께 일하면 그것을 안 했을 때의 대가가 즉각적이고 눈에 보인다는 점입니다.

AI 개발이 강제하는 이 습관은, 결국 프로젝트 문서화 수준 자체를 높이는 부수효과를 만들어냅니다.

참고자료: I wasted 68 minutes a day re-explaining my code. Then I built auto-memory. – Microsoft Dev Blog