코딩 에이전트가 제 성능을 내는 팀의 세 가지 설계 기준

코딩 에이전트가 제 성능을 내는 팀의 세 가지 설계 기준

명세 포맷·컨텍스트 구조·에이전트 허브—세 글감이 함께 가리키는 건 에이전트를 '잘 쓰는 것'이 아니라 '제대로 쓸 수 있는 구조'를 먼저 설계해야 한다는 사실이다

코딩 에이전트 ANSS 명세 Claude Code 토큰 최적화 컨텍스트 윈도우 Devin Desktop 에이전트 오케스트레이션 AI-First 워크플로우
광고

에이전트가 코드를 망가뜨리는 건 모델이 나빠서가 아니다. 팀이 에이전트를 위한 구조를 설계하지 않았기 때문이다. 최근 세 가지 실전 사례—Devin Desktop의 에이전트 허브 전략, ANSS 명세 포맷, Claude Code 토큰 분석—를 들여다보면, 같은 결론이 반복된다. 에이전트가 제 성능을 내려면 팀이 먼저 세 가지를 설계해야 한다.

1. 명세는 사람이 아니라 에이전트를 위해 써야 한다

dev.to에 공개된 ANSS(AI-Native System Specification Standard) 사례는 이 문제를 정면으로 건드린다. IEEE 830, ISO/IEC 29148 같은 기존 스펙 포맷은 수십 년 전에 만들어졌다. 인간 독자가 "맥락상 당연히 이렇게 하겠지"라고 넘어가는 모호함을 에이전트는 그냥 채워버린다—훈련 데이터가 제안하는 방향으로. 그 결과가 "요구사항대로 했는데 세 군데가 깨진" 상황이다.

ANSS가 제안하는 핵심은 세 층 마크업과 불변성(Invariant) 선언이다. [A] 태그로 에이전트 전용 섹션을 분리하고, INV-001: No external npm packages처럼 검증 가능한 규칙을 명시적으로 박아둔다. "코드베이스를 최소화하라"는 주석이 에이전트에겐 npm 패키지 세 개를 추가할 면허가 된다는 걸 경험한 사람이라면, 이 접근이 왜 필요한지 바로 납득할 것이다. 도입 비용은 낮다. 5분짜리 온보딩 루틴(용어집 10개, 불변성 3~5개, 사용자 스토리)으로 시작할 수 있고, GitHub에 두 개의 실제 작성 예시가 공개되어 있다.

내가 특히 주목한 건 'Agent Review' 단계다. 코드를 쓰기 전에 에이전트가 먼저 스펙을 감사한다. 모순 탐지, 엣지 케이스 누락, 불변성 충돌을 체크하고, 문제가 3개 이상이면 멈추고 묻는다. 이 순서 하나만 바꿔도 반복 이터레이션이 5~7회에서 2~3회로 줄었다는 게 사례의 주장이다. 팀 리드 입장에서 이건 PR 리뷰 전에 에이전트가 스스로 스펙 QA를 돌리는 구조다.

2. 컨텍스트 낭비 구조를 먼저 측정해야 한다

Claude Code MAX 플랜 쿼터가 3일 만에 소진됐다. 왜일까. 한 개발자가 세션 JSONL을 직접 분석한 결과, 188,000 토큰 중 164,000 토큰(87%)이 대화 이력이었다. CLAUDE.md는 12,700 토큰, MCP 툴 정의는 3,900 토큰—합쳐봤자 9%다. 많은 팀이 CLAUDE.md를 줄이고 프롬프트를 다듬는 데 공을 들이는데, 그건 9%짜리 문제를 공략하는 셈이다.

진짜 문제는 Tool I/O 누적이다. 파일 읽기 결과, bash 출력, grep 결과—에이전트가 그 순간 판단하고 끝낸 데이터가 컨텍스트 윈도우에 영원히 남아 매 턴마다 토큰을 먹는다. 50턴 세션에서 초반 grep 결과가 아직도 컨텍스트에 살아있는 구조다. /compact는 역설적으로 토큰을 대량 소비해 요약하는 방식이라 근본 해결이 아니다.

이 분석에서 나온 Throughline의 3계층 모델은 하나의 설계 기준으로 읽힌다. 대화 본문(L2, 최근 20턴)은 손실 없이 유지하고, Tool I/O(L3)는 SQLite로 퇴출해 컨텍스트에서 제거한다. 오래된 턴은 경량 모델이 10토큰짜리 한 줄 요약(L1)으로 압축한다. 결과는 50턴 기준 125,000 토큰에서 13,000 토큰으로 약 90% 감소다. 핵심 설계 원칙은 '시간 기반 압축'이 아니라 '타입 기반 분리'—이 관점 전환이 실질적인 차이를 만든다.

3. 에이전트 허브는 분산된 세션을 하나로 묶는다

Devin Desktop(구 Windsurf)이 'Agent Command Center'를 표방하며 방향을 전환한 것도 같은 맥락이다. Claude Code, Codex, Copilot CLI, Cursor 등 여러 에이전트를 팀이 동시에 쓰는 현실에서, 터미널·에디터·구독 서비스가 분산된 구조는 관리 비용을 올린다. ACP(Agent Client Protocol)를 통해 외부 에이전트를 단일 인터페이스에서 조율한다는 발상은 '에이전트 오케스트레이션 레이어'가 팀 워크플로우의 필수 요소가 되고 있음을 시사한다.

도입 장벽은 솔직히 아직 있다. Windsurf에서 Devin Desktop으로 마이그레이션한 일부 사용자가 익스텐션 유실을 보고했고, Codeium → Windsurf → Devin으로 이어지는 브랜드 변경 이력은 장기 플랫폼 신뢰도에 물음표를 남긴다. 그럼에도 ACP 기반 멀티 에이전트 허브 방향성 자체는 팀 규모가 커질수록 더 설득력을 갖는다.

설계 기준 세 줄 요약

세 글감이 함께 가리키는 설계 기준은 명확하다. 첫째, 명세는 에이전트가 읽는 문서로 다시 써라. 불변성과 Agent Review 단계가 없는 스펙은 모호함을 에이전트에게 위임하는 것과 같다. 둘째, 컨텍스트 낭비를 측정하지 않으면 통제할 수 없다. CLAUDE.md 최적화 전에 세션 JSONL을 열어보는 게 먼저다. 셋째, 에이전트가 늘어날수록 오케스트레이션 레이어가 필요하다. 단일 에디터에서 여러 에이전트를 관리하는 구조가 팀 생산성의 다음 병목이 된다.

에이전트 도구의 성능 자체는 빠르게 올라가고 있다. 하지만 팀이 그 성능을 온전히 끌어내려면, 도구를 고르기 전에 구조를 설계해야 한다. 명세 포맷, 컨텍스트 관리, 에이전트 허브—이 세 가지는 내일 당장 팀 회의 안건에 올릴 수 있는 수준의 실행 가능한 설계 문제다.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요