팀에서 AI 코딩 에이전트 도입 논의가 시작되면 어김없이 같은 질문이 먼저 나온다. "Claude로 갈까요, GPT로 갈까요?" 모델 선택이 첫 번째 의사결정이 되는 순간, 팀은 이미 잘못된 방향을 보고 있는 것이다.
지난 5월, VS Code 팀이 공개한 에이전트 하네스 분석 글에는 눈길을 끄는 차트 하나가 묻혀 있었다. VSC-Bench라는 내부 벤치마크에서 8가지 모델-추론 설정을 40개 컨테이너 환경에 돌린 결과였다. 예상대로 추론 노력을 높일수록 해결 과제 수는 올라갔다—high 설정까지는. 그런데 xhigh에 도달하는 순간 그래프가 꺾였다. 토큰 소비는 늘어났고 해결 과제 수는 오히려 줄었다. VS Code 팀의 설명은 건조했다. "유용한 노력의 최적점을 지났을 가능성이 있다." 벤더가 스스로 "가장 비싼 설정이 가장 나쁜 결과를 낸다"는 차트를 공개한 것은 이례적이다. 그리고 이 사실이 측정 가능했던 유일한 이유는, 전체 에이전트 루프를 end-to-end로 구동하는 평가 하네스가 존재했기 때문이다.
하네스란 무엇인가. 마케팅 언어를 걷어내면 세 가지 책임과 하나의 루프다. 컨텍스트 어셈블러는 모델에 무엇을 넣을지 결정한다. 열린 파일, 최근 편집 이력, 터미널 출력, 이전 툴 호출 결과, 고정 메모리—맥락 창은 유한하고, 무엇을 버릴지 누군가는 결정해야 한다. 모델이 "세 턴 전에 말한 것을 잊었다"고 느껴질 때, 책임은 대부분 여기에 있다. 툴 노출 레이어는 에이전트가 할 수 있는 행동을 모델이 호출 가능한 JSON 스키마로 변환한다. VS Code 팀 문서에 따르면 Claude 모델은 replace_string_in_file을 쓰고 GPT 모델은 apply_patch를 쓴다. 단순히 이름이 다른 게 아니라 실패 방식 자체가 다른 도구다. Gemini는 툴을 호출하는 대신 "지금 이것을 하려고 한다"고 서술하는 경향이 있어 하네스가 이를 감지하고 교정해야 한다. 툴 실행기는 인자를 검증하고 프로세스를 구동하고 출력을 모델에게 돌려보낸다. 1.120 업데이트에서 추가된 chat.tools.compressOutput.enabled 설정이 여기에 해당한다. 12,000줄짜리 npm install 로그를 "lockfile diff 생략" 한 줄로 압축해 컨텍스트 오염을 막는다. 이 세 레이어를 감싸는 것이 에이전트 루프—생각, 행동, 관찰, 반복. 루프의 어느 것도 모델이 아니다.
여기서 현장 팀들이 가장 많이 저지르는 실수가 드러난다. 모델 선택기를 만들고 model_id만 교체하면 된다고 생각하는 것. 하나의 컨텍스트 어셈블러, 하나의 툴 레지스트리, 몇 개의 조건 블록이 붙은 단일 프롬프트 템플릿. 시작점으로는 맞다. 멈춰야 할 지점은 아니다. VS Code 팀은 모델 패밀리별로 다른 시스템 프롬프트를 쓰고, 모델 출시 전 사전 릴리스 체크포인트를 기준으로 하네스를 다시 튜닝한다. 사용자가 "Claude X.Y 가용"이라는 알림을 받는 시점에, 누군가는 이미 며칠을 하네스 재설계에 썼다는 뜻이다. 팀에 모델 선택 드롭다운이 생기는 순간, 이 문제는 팀의 문제가 된다. 하네스를 재조정하지 않고 모델만 바꾸면 해당 모델이 낼 수 있는 품질보다 낮은 결과가 나온다.
두 번째 현장 문제는 컨텍스트 재사용이다. 에이전트에게 같은 내용을 반복 설명하는 비용은 눈에 잘 띄지 않는다. 프로젝트마다 스택 설명, 비즈니스 규칙, 서드파티 API 특이점을 다시 붙여넣는 시간이 개인 단위에서는 몇 분처럼 보이지만, 팀 전체로 곱하면 주당 몇 시간이 된다. dev.to에서 공개된 context-window 오픈소스 프로젝트는 이 문제를 정면으로 파고든다. 핵심 아이디어는 간단하다. 컨텍스트를 일급 객체로 만드는 것. 한 번 작성한 코딩 컨벤션, 아키텍처 결정, API 특이 사항을 MCP 서버를 통해 프로젝트에 연결하면, 모델은 세션 시작 시 매니페스트를 읽고 필요한 내용만 요청해 가져간다. 전체 내용을 매번 주입하는 대신, 모델이 무엇이 있는지 파악하고 필요할 때 꺼내 쓰는 구조다. 특히 흥미로운 설계는 사용 분석이다. 어떤 컨텍스트가 실제로 호출되는지, 어떤 클라이언트가 사용하는지 로그가 쌓인다. 정성껏 작성한 컨텍스트가 에이전트에게 실제로 쓰이고 있는지 확인할 방법이 없으면, 컨텍스트 설계는 감으로 하는 일이 된다.
세 번째 현장 문제는 프로덕션 수준 에이전트 설계의 구조다. AI 에이전트 개발을 다룬 또 다른 분석에서 지적하는 핵심은 "열린 추론 루프"의 위험이다. 에이전트가 전체 플로우를 즉흥적으로 판단하게 두면 예측 불가능한 반복 루프, 외부 툴 오류 시 전체 중단, 비결정적 컨텍스트 검색 실패가 누적된다. 대안은 상태 머신 기반 프롬프트 엔지니어링이다. 각 상태가 단 하나의 명확한 목표를 갖고, LLM은 현재 상태를 처리해 다음 노드로 전환하는 조건을 만족시키는 출력을 낸다. 에이전트의 결정 로직과 툴 실행을 분리하면 디버깅, 테스트, 환경 간 이식이 수월해진다. 이것이 하네스 설계의 본질이기도 하다.
지금 팀에서 AI 코딩 에이전트 ROI를 측정하지 못하고 있다면, 가장 먼저 봐야 할 질문은 모델이 아니다. 전체 에이전트 루프를 end-to-end로 구동하는 평가 파이프라인이 있는가. 컨텍스트 어셈블러가 각 모델의 특성에 맞게 조정되어 있는가. 프로젝트 컨텍스트가 재사용 가능한 구조로 관리되고 있는가. 이 세 가지가 없으면 "최신 모델로 업그레이드했더니 더 나빠진 것 같다"는 인상을 반복하게 된다. VS Code 팀의 차트가 증명했듯, 그 인상은 틀리지 않을 수 있다.
하네스 설계에 투자하지 않은 채 모델 업그레이드를 반복하는 것은, 엔진만 교체하면서 핸들 없이 달리는 것과 같다. 모델은 계속 좋아진다. 그 모델이 팀에서 실제로 내는 결과는, 모델을 감싸는 구조가 결정한다.