AI 코딩 에이전트를 처음 써보면 대부분 비슷한 경험을 한다. 처음 며칠은 믿기 어려울 만큼 빠르고, 한 주쯤 지나면 뭔가 이상해지기 시작한다. 에이전트가 이전 대화를 기억 못 하거나, 같은 맥락을 반복 설명하고 있거나, 어느 순간부터 응답이 느려지고 비용이 오르기 시작한다. 문제는 에이전트의 능력이 아니다. 컨텍스트를 설계하지 않은 채로 일을 시작했기 때문이다.
최근 세 편의 글이 이 문제를 서로 다른 각도에서 조명한다. Claude Code와 함께 실제 아키텍처 결정을 내린 경험, 코딩 에이전트에 플러그인을 설치하기 전 컨텍스트 비용을 직접 측정할 수 있는 오픈소스 도구, 그리고 토큰 사용량을 85% 줄인 운영 프로토콜. 각각은 독립된 이야기지만 하나의 메시지로 수렴한다. 에이전트와 잘 일하려면 코드가 아니라 컨텍스트 구조를 먼저 설계해야 한다.
에이전트는 코드를 짠다, 결정은 사람이 한다
dev.to에 올라온 Alejandra Arocha의 회고는 '나는 AI가 다 짜줬다'는 류의 자랑이 아니다. 그는 2주 동안 Claude Code와 함께 실시간 협업 보드와 Jira 연동 기능을 갖춘 회고 도구 Retro Dynamics Agent를 만들면서, 에이전트와의 협업이 실제로 어떻게 분업되는지를 세 가지 아키텍처 결정을 통해 구체적으로 보여준다.
첫 번째 사례는 서버리스 환경에서의 OAuth 연동이다. 서버리스 함수는 요청 사이에 상태를 유지하지 않고, 프론트엔드도 자체 상태를 갖지 않는다. OAuth 로그인은 외부 서비스로 나갔다가 다시 돌아오는 구조인데, '돌아왔을 때 어디로 복귀할지'를 아무도 기억하지 못한다. Alejandra는 구현 전에 에이전트에게 변경이 필요한 파일, 설계 결정, 범위를 담은 완전한 구현 계획을 먼저 작성하게 했고, 이를 풀 리퀘스트 리뷰하듯 검토했다. Azure DevOps는 일단 수동 토큰 방식으로 남겨두고, 토큰은 평문이 아닌 암호화된 형태로 저장하며, 기존 수동 연결 폼을 폴백으로 유지한다는 결정은 모두 그의 몫이었다. 에이전트는 서명된 HMAC 상태 파라미터를 제안하고 구현했다. OAuth 라운드트립 내내 세션 ID를 실어 나르는 방식으로 컨텍스트 손실 없이 화면을 복원하는 해법이었다.
두 번째는 실시간 보드의 동기화 전략이다. 이미 Supabase를 쓰고 있었으니 같은 제공자의 실시간 기능을 쓰는 것이 가장 단순한 선택이었다. 하지만 그는 선택하지 않았다. 자유로운 드래그, 라이브 커서, 동시 편집이 일어나는 캔버스에서 두 명이 같은 객체를 동시에 건드리는 것은 엣지 케이스가 아니라 일상적으로 발생하는 일이다. Supabase Realtime으로는 그 충돌 처리 로직을 직접 짜야 했다. 결국 협업 캔버스에 특화된 Liveblocks를 별도 도입하기로 했고, 에이전트는 세션이 활성화된 동안은 Liveblocks를 단일 진실 공급원으로 쓰고 세션 종료 시 Postgres에 한 번만 쓰는 동기화 모델을 제안했다. 그는 또 초반에 노트와 그룹을 분리된 테이블로 관리하려 했는데, 에이전트가 두 데이터는 항상 함께 생성되고 소비되므로 분리가 오히려 복잡성만 늘린다고 교정해줬다.
세 번째는 투표 동시성 문제다. 여러 사람이 동시에 투표할 때 하나의 카운터를 공유하면 쓰기 충돌이 생긴다. 해법은 충돌을 해결하는 것이 아니라 충돌 자체를 제거하는 데이터 모델로 바꾸는 것이었다. 각 참가자가 자신이 투표한 노트 목록만 관리하고, 총 득표수는 그 목록들을 집계해서 계산한다. 두 사람이 같은 값을 동시에 쓰려고 경쟁하는 일이 구조적으로 불가능해진다. 이것은 제품 결정처럼 보이지만 데이터 모델을 통째로 바꾸는 아키텍처 결정이기도 하다.
세 사례에서 반복된 패턴은 명확하다. 구현 전에 아키텍처를 먼저 논의하고, 제약과 트레이드오프를 사람이 정의하면, 에이전트는 그 안에서 구체적인 기술 해법을 찾아 구현한다. 그리고 '이게 실제로 동작하는지'를 증명하는 일은 다시 사람의 몫이 된다. OAuth는 프로덕션 로그에서, 실시간 아키텍처는 두 개의 실제 클라이언트를 연결한 스크립트로, 투표 로직은 Liveblocks 의존성 없이 독립적으로 테스트 가능한 순수 함수로. "누가 코드를 짰냐"는 점점 덜 중요한 질문이 되고, "누가 제약을 정하고 트레이드오프를 선택했냐"가 핵심 질문이 된다.
플러그인 설치 전에 컨텍스트 비용을 먼저 재라
에이전트와 일할 때 컨텍스트 비용은 눈에 잘 안 띈다. 컨텍스트 플러그인 하나를 설치하면 비용이 줄어든다고 홍보하지만, 정작 내 코드베이스에 적용했을 때 얼마나 달라지는지 미리 알 방법이 없었다. 그래서 chamnan 1.23.1은 측정 페이지를 먼저 출시했다.
사용법은 단순하다. arcticfox2029.github.io/chamnan-measure에 공개 GitHub 저장소 URL을 붙여넣으면, 브라우저 탭 안에서 소스를 내려받아 chamnan의 실제 모듈(mapper, rollup, redactor)을 Pyodide로 실행한다. 서버도, 업로드도, API 키도 없다. 에이전트 세션마다 컨텍스트에 주입될 내용, redactor가 수정할 부분, 해당 저장소 파일 기준 50턴 시뮬레이션 결과가 나온다.
측정 결과에서 흥미로운 건 압축 비율이 아니라 주입 블록의 절대 크기가 수렴한다는 점이다. chalk(56KB)부터 vuejs/core(3,782KB)까지 소스는 67배 커지지만, 주입되는 컨텍스트는 6.2~6.7KB 사이에 묶여 있다. 저장소가 커질수록 더 정교한 맵이 아니라 더 거친 맵을 만드는 방식으로 토큰 예산을 지킨다. 압축률 숫자만 강조하는 것은 유리한 데이터만 고른 것일 수 있다는 점도 스스로 인정하는데, 바이너리 첨부 파일로 채운 코퍼스에서는 223x가 나왔지만 그게 '정직한 수치'는 아님을 명시한다.
이 도구가 전달하는 진짜 메시지는 이것이다. 에이전트에게 컨텍스트를 주기 전에, 그 컨텍스트가 얼마나 무거운지를 먼저 측정할 수 있어야 한다. 설치 후에 비용을 확인하는 것이 아니라, 설치 전에 내 코드베이스 기준으로 미리 시뮬레이션해보는 것. 이것이 컨텍스트를 설계한다는 것의 가장 실천적인 형태다.
3,223턴 마라톤 세션을 85% 줄인 방법
컨텍스트 설계 실패의 가장 극단적인 형태가 있다. dev.to에 공유된 사례에서 Antigravity 세션은 3,223턴에 달했고, 스튜디오 전체 운영 스텝의 46%를 혼자 차지했다. 세션을 닫으면 작업 합의, 파일 경로, 아키텍처 맥락을 잃을까봐 두려워서 끊지 못한 것이다.
그 비용은 조용하지만 치명적이었다. 3,200턴 시점에서 추론 한 번에 80,000~120,000 토큰이 전송됐다. 4단계짜리 단순한 도구 루틴 하나가 입력 토큰 40만 개를 소모했다. 11개의 서브에이전트를 병렬로 실행하면서 진단 로그 37,000단어가 그대로 부모 스레드의 프롬프트 창에 쏟아졌다. 73,000자짜리 파일을 반복해서 열어볼 때마다 통째로 워킹 메모리에 올라갔다.
해법은 세 가지 운영 원칙으로 정리된다. 첫째, 마일스톤 세션 로테이션이다. SQLite FTS5 기반 로컬 MCP 메모리 서버가 있으니 이전 결정을 8ms 안에 불러올 수 있다. 세션을 닫아도 맥락을 잃을 이유가 없다. 25~40턴마다 세션을 교체하면 입력 컨텍스트가 110,000토큰에서 6,000토큰으로 떨어진다. 둘째, 사일런트 워커 프로토콜이다. 서브에이전트는 완전한 분석 리포트를 디스크에 쓰고, 부모 스레드에는 두 문장 요약과 파일 경로만 반환한다. 40,000토큰짜리 요약이 부모 컨텍스트를 오염시키는 일을 막는다. 셋째, 외과적 파일 슬라이싱이다. 75,000자짜리 파일 전체를 읽는 대신 ripgrep으로 대상 패턴을 찾고 정확히 20줄만 읽는다.
결과는 명확하다. 턴당 입력 토큰이 105,000에서 7,800으로 줄었다(85% 감소). 컨텍스트 손실은 0%. 핵심은 MCP 메모리 서버를 갖추는 것이 아니라 그것을 활용해서 컨텍스트 공포를 제거하는 운영 방식을 만드는 것이다. 도구가 있어도 사용 방식을 설계하지 않으면 마라톤 세션의 함정에서 벗어나지 못한다.
컨텍스트 설계가 에이전트 협업의 진짜 인터페이스다
세 이야기를 나란히 놓으면 하나의 구조가 보인다. Alejandra는 에이전트에게 일을 시키기 전에 제약과 트레이드오프를 먼저 정의했다. chamnan은 플러그인을 설치하기 전에 내 코드베이스 기준으로 비용을 미리 측정할 수 있게 했다. Antigravity 팀은 세션을 닫는 것이 두려워지지 않도록 로컬 메모리 검색 구조를 먼저 갖췄다. 공통점은 하나다. 에이전트에게 일을 넘기기 전에 컨텍스트를 설계했다는 것.
에이전트 협업에서 병목은 더 이상 코드 작성 속도가 아니다. 어떤 컨텍스트를 어떤 형태로, 얼마나 담아서, 어떤 타이밍에 전달하는가가 품질과 비용을 동시에 결정한다. 컨텍스트는 에이전트에게 건네는 브리핑이자, 협업의 인터페이스이자, 비용의 실체다. 설계되지 않은 컨텍스트는 결국 설계되지 않은 결과를 만든다.
에이전트가 더 강력해질수록 이 질문은 더 중요해진다. 코드를 얼마나 빠르게 생성하느냐가 아니라, 무엇을 컨텍스트에 담고 무엇을 버릴지를 결정하는 사람이 누구냐가 협업의 품질을 가른다. 그 판단은 아직, 그리고 당분간은 사람의 몫이다.