Context Anchoring

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 AI 개발 세션에서 사라지기 쉬운 의사결정의 맥락을 기능 단위의 살아 있는 문서로 외부화해, 대화가 끝나도 인간과 AI가 같은 판단 근거를 공유하도록 만드는 ‘컨텍스트 앵커링’을 제안한다.

📌 핵심 요약

저자는 개발자가 AI와의 긴 대화를 붙잡는 이유가 긴 세션이 생산적이어서가 아니라, 기능 수준의 결정·제약·이유가 대화 기록 말고는 보존되는 곳이 없기 때문이라고 진단한다.
대규모 언어 모델은 유한한 컨텍스트 창을 가지며, 긴 맥락의 중간에 있는 정보는 더 잘 잊히는 경향이 있다. 특히 저자는 실제 경험상 결정 자체보다 그 결정을 내린 이유가 더 빨리 약해진다고 말한다.
자동 요약이나 압축 기능은 무엇이 보존되고 무엇이 사라졌는지 개발자가 확인하기 어렵기 때문에, 특정 설계 결정의 미묘한 근거를 안정적으로 지킨다고 보기 어렵다.
해결책은 프로젝트 수준의 프라이밍 문서와 별도로, 기능 단위의 살아 있는 문서를 두어 결정, 이유, 거절한 대안, 남은 질문, 진행 상태를 세션 밖에 저장하는 것이다.
이 기능 문서는 코드가 보여주지 못하는 설계의 이유를 보존하고, 팀원 각자의 AI 세션 사이에서도 같은 맥락을 공유하게 하며, 실시간으로 진화하는 ADR에 가까운 역할을 한다.

🧩 주요 포인트

저자는 개발자가 AI와의 긴 대화를 붙잡는 이유가 긴 세션이 생산적이어서가 아니라, 기능 수준의 결정·제약·이유가 대화 기록 말고는 보존되는 곳이 없기 때문이라고 진단한다.
대규모 언어 모델은 유한한 컨텍스트 창을 가지며, 긴 맥락의 중간에 있는 정보는 더 잘 잊히는 경향이 있다. 특히 저자는 실제 경험상 결정 자체보다 그 결정을 내린 이유가 더 빨리 약해진다고 말한다.
자동 요약이나 압축 기능은 무엇이 보존되고 무엇이 사라졌는지 개발자가 확인하기 어렵기 때문에, 특정 설계 결정의 미묘한 근거를 안정적으로 지킨다고 보기 어렵다.
해결책은 프로젝트 수준의 프라이밍 문서와 별도로, 기능 단위의 살아 있는 문서를 두어 결정, 이유, 거절한 대안, 남은 질문, 진행 상태를 세션 밖에 저장하는 것이다.
이 기능 문서는 코드가 보여주지 못하는 설계의 이유를 보존하고, 팀원 각자의 AI 세션 사이에서도 같은 맥락을 공유하게 하며, 실시간으로 진화하는 ADR에 가까운 역할을 한다.

🧠 상세 정리

1. 문제의 출발점: AI 대화는 오래 남지 않는다

글의 핵심 문제의식은 AI와의 개발 대화가 본질적으로 일시적이라는 데 있다. 세션 초반에 정한 결정은 대화가 길어질수록 희미해지고, 세션 경계를 넘으면 기본적으로 아무것도 살아남지 않는다. 개발자들이 길어진 대화를 계속 붙잡는 이유도 긴 세션 자체가 더 생산적이어서가 아니라, 그 안에 담긴 맥락이 다른 곳에 없기 때문이다. 저자는 이 불안을 줄이기 위해 의사결정 맥락을 대화 밖의 살아 있는 문서로 외부화해야 한다고 제안한다. 그렇게 하면 일시적인 정렬 상태가 세션이 끝나도 지속되는 공유 이해로 바뀔 수 있다.

2. 동료 협업 문서와 AI 협업의 차이

저자는 며칠에 걸쳐 동료와 기능을 개발할 때 공유 문서를 두는 경험을 예로 든다. 그 문서는 정식 문서라기보다 무엇을 결정했고, 왜 그렇게 했으며, 무엇을 거절했고, 어떤 질문이 남았는지를 기록하는 작업용 기억 장치다. 한 사람이 하루 자리를 비워도 다른 사람이 이어서 작업할 수 있는 이유는 개인의 기억만 믿지 않기 때문이다. 반면 AI 코딩 어시스턴트와의 협업에서는 아직 대화 자체가 사실상 기록의 역할을 하는 경우가 많다. 프로젝트 수준의 메모리나 규칙 파일은 존재하더라도, 특정 기능에서 어제 왜 어떤 추상화를 거절했는지까지 안정적으로 보존하지는 못한다.

3. 긴 대화가 만드는 악순환

기능 수준의 결정, 제약, 논리는 대개 채팅 기록 안에만 남기 때문에 개발자는 세션을 닫는 순간 중요한 것을 잃는다고 느낀다. 이 때문에 대화는 필요 이상으로 길어지고, 길어진 대화는 다시 AI가 앞선 결정을 정확히 떠올리기 어렵게 만든다. 저자는 이를 악순환으로 본다. 붙잡고 있는 시간이 길어질수록 붙잡고 있는 대상의 신뢰성은 오히려 낮아진다. 그래서 그는 지금 당장 이 대화를 닫고 새 대화를 시작해도 불안하지 않은지 묻는 테스트를 제안한다. 그 질문이 불편하다면 맥락이 보존에 적합하지 않은 매체 안에 갇혀 있다는 신호다.

4. 컨텍스트가 약해지는 기술적 이유

컨텍스트 침식은 무작위로 일어나는 현상이 아니라 대규모 언어 모델이 맥락을 처리하는 방식에서 비롯된다. 모든 모델에는 한 번에 주의를 기울일 수 있는 토큰 수의 한계가 있으며, 현대 모델의 창이 수십만에서 백만 토큰 이상으로 커졌더라도 개발 세션의 정보량은 빠르게 늘어난다. 코드 조각, 설계 토론, 결정 근거, 파일 내용이 쌓이면 창은 예상보다 빨리 찬다. 저자는 Stanford와 Berkeley의 2023년 연구인 “Lost in the Middle”을 언급하며, 긴 맥락의 중간에 놓인 정보는 시작이나 끝에 있는 정보보다 훨씬 덜 잘 회상된다고 설명한다. 최근 토큰과 시스템 수준 지시가 더 큰 비중을 얻고, 중간의 정보는 모델의 제한된 주의를 두고 경쟁하게 된다.

5. 결정보다 먼저 사라지는 것은 결정의 이유

저자가 실무에서 반복적으로 관찰한 더 중요한 문제는 무엇이 먼저 흐려지는가이다. AI는 “PostgreSQL을 사용한다”는 결정 자체는 기억할 수 있지만, 왜 MongoDB 대신 PostgreSQL을 선택했는지는 잊을 수 있다. 예를 들어 JSONB 지원, 팀의 운영 경험, 멀티테넌시 요구사항 같은 이유가 사라지면 AI는 표면적으로는 결정을 따르면서도 그 의도에 어긋나는 제안을 할 수 있다. PostgreSQL을 쓰자는 결정에는 맞지만 문서 저장소에 더 어울리는 스키마 구조를 제안하는 식이다. 이 실패는 기술적으로는 지시를 따르는 것처럼 보여도 아키텍처 관점에서는 잘못된 방향으로 이어질 수 있다는 점에서 비용이 크다.

6. 자동 압축과 기존 정렬 기법의 한계

일부 도구는 컨텍스트 창이 차면 이전 대화 기록을 자동으로 압축하거나 요약해 문제를 관리하려 한다. 그러나 저자는 이 방식이 불투명하다는 점을 우려한다. 개발자는 무엇이 원문 그대로 보존됐고, 무엇이 요약됐으며, 무엇이 조용히 삭제됐는지 알 수 없다. 자동 압축은 일반적 일관성을 목표로 할 뿐, 특정 설계 결정에 중요한 미묘한 맥락을 보존하도록 보장되지 않는다. 특히 결정의 이유는 길고 설명적이며 문맥 의존적인 경우가 많아 압축 과정에서 가장 취약하다. 저자는 프로젝트 맥락을 공유하는 Knowledge Priming이나 단계적 설계 대화인 Design-First collaboration도 결국 대화 안에서 만든 정렬이기 때문에, 이를 오래 지속시키려면 별도의 고정 장치가 필요하다고 본다.

7. 외부 기억으로서의 기능 문서

컨텍스트 앵커링의 핵심은 의사결정 맥락을 대화 밖의 외부 상태로 다루는 것이다. 저자는 프로젝트 수준의 프라이밍 문서와 기능 수준의 기능 문서를 구분한다. 프라이밍 문서는 기술 스택, 아키텍처 패턴, 명명 규칙, 코드 예시처럼 비교적 안정적인 프로젝트 맥락을 담고, 기능 문서는 특정 기능을 개발하면서 내린 결정, 그 결정을 만든 제약, 검토했다가 거절한 대안, 남은 질문, 현재 진행 상태를 담는다. 새 세션을 시작할 때 두 문서를 함께 불러오면 프로젝트 문서는 공통 어휘와 기반을 제공하고, 기능 문서는 지금 어디까지 왔으며 왜 그렇게 왔는지를 알려준다. 즉 하나는 프로젝트가 어떻게 작동하는지 설명하고, 다른 하나는 특정 작업의 역사를 보존한다.

8. 코드가 담지 못하는 이유와 팀 단위 조정

저자는 AI가 코드베이스를 읽을 수 있는데도 별도 문서가 필요한 이유를 분명히 한다. 코드는 결과를 보여줄 뿐, 그 결과에 이르기까지 어떤 대안이 논의되고 거절됐는지, 어떤 제약이 선택을 이끌었는지, 어떤 질문이 아직 열려 있는지는 보여주지 못한다. 예를 들어 코드가 BullMQ를 직접 사용한다고 해서 RetryQueue 추상화가 불필요한 간접층이라 판단되어 거절됐는지, 아니면 단순히 처음 생성된 방식이 그대로 남은 것인지는 알 수 없다. 이 지점에서 기능 문서는 ADR과 비슷한 역할을 하며, 완성 후 쓰는 문서가 아니라 의사결정이 일어나는 동안 함께 진화하는 살아 있는 ADR에 가깝다. 여러 개발자가 각자 AI 세션을 쓰는 팀에서는 한 개발자의 세션에서 정한 결정이 다른 개발자의 AI 세션에도 전달되어, 이미 거절한 추상화를 다시 제안받는 반복을 줄일 수 있다.

9. 실제 예시: 알림 서비스 기능 문서

저자는 앞서 다룬 알림 서비스 설계 사례를 통해 기능 문서가 어떤 모습인지 보여준다. 설계 대화 후에는 BullMQ를 재시도 처리에 직접 사용하고 별도 래퍼 추상화를 두지 않으며, 클래스가 아니라 함수형 서비스를 쓰고, v1에서는 이메일만 지원하고, 전달 서비스로 SendGrid를 사용한다는 결정이 남았다. 중요한 점은 결정만 적는 것이 아니라 각 결정의 이유와 거절한 대안도 함께 기록한다는 것이다. 예시 문서에는 BullMQ의 네이티브 재시도와 백오프가 충분하므로 RetryQueue 추상화는 불필요한 간접층으로 거절했다는 내용, 코드베이스 관례에 맞춰 함수형 서비스를 선택했다는 내용, SendGrid를 전달성과 팀 경험 때문에 선택했다는 내용이 들어간다. 또한 모든 쿼리에 tenantId를 포함해야 하는 멀티테넌시 제약, 기존 인증 미들웨어 사용, 제품 입력을 기다리는 rate limiting 전략 같은 열린 질문도 함께 보존된다.

🧾 핵심 주장 / 시사점

AI 협업에서 진짜 위험은 결정을 잊는 것보다 결정의 이유를 잃는 것이다. 이유가 사라지면 AI는 표면적으로는 지시를 따르면서도 설계 의도와 어긋나는 제안을 할 수 있다.
기능 문서는 긴 대화를 계속 유지하기 위한 보조물이 아니라, 대화를 안전하게 종료하고 새 세션을 시작할 수 있게 만드는 장치다. ‘지금 이 세션을 닫아도 불안하지 않은가’라는 질문은 맥락 관리 상태를 점검하는 실용적인 기준이 된다.
코드, 프로젝트 메모리, 자동 요약은 각각 한계가 있으므로 기능 단위의 살아 있는 기록이 별도로 필요하다. 이 문서는 토큰 비용을 낮추는 부수 효과도 있지만, 핵심 가치는 코드에 남지 않는 판단 근거와 거절된 대안을 보존하는 데 있다.