에이전트 속도가 기대보다 느리다면, 모델 탓을 하기 전에 컨텍스트 구조를 먼저 보자. 실제로 AI 코딩 에이전트가 느려지는 원인 대부분은 모델 성능이 아니라 컨텍스트 낭비에 있다. 50,000줄짜리 코드베이스를 통째로 던지거나, 멀티턴 루프가 쌓일수록 토큰 비용이 전화번호처럼 불어나거나, 에이전트가 어떤 파일이 진짜 구현체인지 판단하지 못하고 grep을 반복하는 것—이 세 가지 현상은 사실 하나의 근본 문제를 가리킨다. 컨텍스트 설계가 없다는 것이다.
최근 dev.to에 올라온 세 편의 실전 글—Cursor 최적화 가이드, AI 에이전트 토큰 비용 90% 절감 사례, 그리고 코드베이스 맵 도구 Satori 소개—은 각각 다른 층위의 문제를 다루고 있지만, 묶어 읽으면 팀 리드가 설계해야 할 컨텍스트 전략의 세 층위가 보인다. 입력 품질, 전송 효율, 탐색 구조다.
1층위: 입력 품질 — 에이전트에게 무엇을 줄 것인가
Cursor 최적화 가이드가 가장 강조하는 건 .cursorrules 파일과 @ 참조의 전략적 활용이다. 당연한 얘기처럼 들리지만, 팀 대부분은 이걸 제대로 안 한다. 규칙 파일 없이 Cursor를 쓰면 에이전트는 프로젝트 컨벤션을 모른 채 코드를 생성한다. any 타입이 난무하고, Next.js App Router 프로젝트에서 getServerSideProps가 튀어나오고, Prisma 쿼리가 컴포넌트 안에 직접 박힌다.
핵심은 .cursorrules를 '개발자를 위한 코딩 가이드'가 아니라 'AI 독자를 위한 컨텍스트 문서'로 설계하는 것이다. 어떤 파일이 어떤 역할을 하는지, 어떤 패턴은 금지인지, 에러 핸들링 구조는 어떻게 되는지—이걸 명시해두면 에이전트가 생성한 코드가 처음부터 팀 패턴에 맞아 들어온다. 리포매팅에 쓰는 시간이 사라진다.
@Files는 스캐너가 아니라 스캘펠로 쓰야 한다. 관련 없는 파일을 컨텍스트에 포함시키는 순간, 모델은 집중력을 잃고 할루시네이션 확률이 올라간다. 넓은 컨텍스트보다 좁고 정확한 컨텍스트가 항상 더 나은 결과를 낸다. 이건 팀 가이드라인으로 명문화해야 할 원칙이다.
2층위: 전송 효율 — 토큰을 얼마나 지능적으로 쓸 것인가
토큰 비용 최적화 사례는 더 직접적인 문제를 다룬다. Discord 기반 자율 코딩 에이전트를 운영하던 개발자는 멀티턴 루프가 쌓일수록 git diff, DB 구조, 디렉토리 탐색 결과가 누적되면서 매월 청구서가 폭발하는 경험을 했다. 문제는 에이전트가 이전 컨텍스트를 계속 들고 다닌다는 것이다. 같은 정보를 매 턴마다 다시 읽는다.
그가 선택한 해법은 Headroom AI라는 오픈소스 도구였다. Tree-sitter로 코드 AST를 파싱하고, SmartCrusher로 JSON을 압축해 컨텍스트를 60~95% 줄이는 구조다. 하지만 단순 프록시 방식은 멀티프로바이더 환경에서 깨졌다—TCP 레이스 컨디션, 잘못된 API 키 라우팅, 401 오류가 줄줄이 터졌다. 그가 찾아낸 해결책은 네트워크 레이어가 아니라 인프로세스 TypeScript 미들웨어였다. 압축은 메모리 안에서, 실제 API 호출은 에이전트가 직접—이 분리가 안정성을 만들었다.
팀 입장에서 이 사례의 진짜 교훈은 압축률 숫자가 아니다. 멀티턴 루프를 운영하는 에이전트는 컨텍스트 팽창이 구조적으로 내재되어 있다는 것, 그리고 이를 소프트웨어 아키텍처 결정으로 다뤄야 한다는 것이다. 비용 최적화는 프롬프트 작성 후의 문제가 아니라 에이전트 설계 단계의 문제다.
3층위: 탐색 구조 — 에이전트가 코드베이스를 어떻게 이해할 것인가
Satori가 지적하는 문제는 더 근본적이다. 에이전트가 파일 검색을 할 수 있다는 것과 코드베이스를 이해한다는 것은 다르다. 실제 코드베이스에는 심볼 소유권, 래퍼와 실제 구현체의 구분, 호출자·피호출자 관계, 오래된 파일과 생성된 파일의 구분이 있다. 이런 구조 없이는 에이전트가 어떤 파일이 진짜 동작을 소유하는지 알 수 없고, 결국 파일 전체를 컨텍스트에 쌓아 올린다.
Satori는 이 문제를 MCP 도구 인터페이스로 해결하려는 시도다. 평문 의도 검색 → 소유 심볼 특정 → 파일 아웃라인 → 정확한 심볼·라인 읽기 → 호출자·피호출자 확인 → 인덱스 신선도 검증으로 이어지는 탐색 경로를 에이전트에게 제공한다. grep 체이닝 대신 증거 기반 탐색이다. 아직 pre-alpha지만, 이 접근 방식이 다루는 문제—에이전트가 넓게 추측하는 대신 좁게 확인하도록 만드는 것—는 지금 당장 팀 워크플로우 설계에 반영할 수 있는 원칙이다.
"더 많은 컨텍스트가 더 나은 증거와 같지 않다"는 Satori의 핵심 명제는, 사실 Cursor 가이드의 @Files 원칙과 Headroom의 압축 전략이 모두 도달하는 같은 결론이다. 컨텍스트는 많을수록 좋은 게 아니다. 정밀할수록 좋다.
팀 리드가 지금 해야 할 것
세 층위를 팀 설계 관점으로 정리하면 이렇다. 입력 품질 층위에서는 .cursorrules와 .mdc 파일을 팀 컨벤션 문서화의 일환으로 만들고, @ 참조 범위를 좁게 유지하는 걸 리뷰 기준에 포함시킨다. 전송 효율 층위에서는 멀티턴 에이전트를 운영한다면 컨텍스트 팽창을 설계 단계에서 다루고, 압축 미들웨어 도입 여부를 비용 구조와 함께 검토한다. 탐색 구조 층위에서는 에이전트가 파일을 광범위하게 로딩하지 않아도 되도록 코드베이스의 심볼 구조와 모듈 경계를 명시적으로 문서화하거나, Satori 같은 도구의 도입을 파일럿해본다.
솔직히 말하면, 이 세 층위는 AI 도구의 문제가 아니라 팀의 설계 부채 문제다. .cursorrules가 없는 건 코딩 컨벤션 문서가 없는 것과 같고, 탐색 구조가 없는 건 온보딩 가이드 없이 신입을 투입하는 것과 같다. 에이전트가 느리고 비싸고 엉뚱한 결과를 낸다면, 모델을 교체하기 전에 이 세 층위부터 점검하는 게 맞다. 컨텍스트 설계는 에이전트 시대의 기초 인프라다.