에이전트를 탓하기 전에 티켓을 다시 읽어라
팀에 AI 에이전트를 도입하고 나서 가장 먼저 듣는 말이 있다. "이 모델, 생각보다 별로네요." 그런데 내 경험상 에이전트가 엉뚱한 걸 만들었을 때 모델을 교체해서 해결된 경우는 거의 없다. 문제는 보통 세 곳에 숨어 있다. 명세가 검증 불가능한 문장으로 쓰여 있거나, 에이전트가 전 세션에서 배운 걸 다음 세션에서 기억 못 하거나, 여러 에이전트가 같은 프로젝트에서 서로 모르는 채로 달리고 있거나. 이 세 가지가 동시에 터지면 결과물은 언제나 '그럴듯하지만 틀린 코드'다.
명세: 형용사를 숫자로 바꾸는 게 전부다
dev.to에 올라온 한 글이 이 문제를 정확히 짚었다. 저자는 AI 에이전트가 잘못된 걸 계속 만들자 모델을 의심했다. 그러다 직접 작성한 acceptance criteria를 다시 읽어봤더니 원인이 거기 있었다. "대용량 파일을 gracefully하게 처리해야 한다" — 이 한 문장에 지뢰가 세 개다. '대용량'이 몇 MB인지, 'gracefully'가 어떤 동작인지, 타임아웃 기준이 어디인지. 사람 개발자라면 Slack으로 물어보거나 refinement에서 짚고 넘어간다. 에이전트는 묻지 않는다. 즉시 가정하고 즉시 커밋한다.
해결책은 단순하다. 모든 기준을 pass/fail로 판단할 수 있게 바꾸는 것. Given / When / Then 형식으로 작성하고, 형용사가 나오면 반드시 숫자로 대체한다. "빠르게" → "p95 기준 200ms 이내", "대용량" → "100,000행 CSV". 그리고 unhappy path를 명시적으로 써야 한다. 빈 입력, 중복 데이터, 권한 오류—에이전트는 명세에 없는 케이스를 스스로 '발명'하고, 그 발명이 항상 기대에 부합하지는 않는다.
여기서 중요한 포인트가 있다. 좋은 acceptance criteria는 필요조건이지 충분조건이 아니다. 에이전트가 기준을 완벽히 충족해도, 다른 파일에 이미 존재하는 유틸 함수를 모르고 새로 만들거나, 아키텍처 결정 사항을 위반할 수 있다. 그 컨텍스트가 다른 탭, 다른 문서, 다른 세션에 흩어져 있기 때문이다. 명세 품질은 올렸는데 에이전트 출력은 여전히 어긋난다면, 다음 레이어를 봐야 한다.
메모리: 매 세션 리셋되는 에이전트는 매번 신입이다
두 번째 문제는 더 현실적이다. Claude Code든 GitHub Copilot이든, 세션이 새로 시작되면 에이전트는 어제 내가 뭘 했는지 모른다. 어떤 버그를 3시간 씨름해서 잡았는지, 왜 그 함수가 그렇게 생겼는지, 어떤 리팩터링을 의도적으로 미뤘는지. 매번 다시 설명하거나 CLAUDE.md에 욱여넣는 방식은 프로젝트가 커질수록 한계가 온다.
dev.to의 또 다른 글에서는 이 문제를 해결하려고 'Glutamate'라는 MCP 툴킷을 직접 만든 사례를 소개한다. 핵심 개념은 세 가지다. 첫째, Failure Memory — 에이전트가 버그를 잡은 순간 그 경로를 기록해두고, 다음 세션에서 같은 버그가 나오면 즉시 꺼낸다. "지난번에 3시간 걸린 걸 이번엔 30초에 해결"이 실측 결과다. 둘째, Code Intelligence — tree-sitter로 코드 구조를 파악해서 2,000줄 파일 전체를 읽는 대신 필요한 심볼 20줄만 읽는다. 세션이 길어질수록 컨텍스트 오염을 막는 효과가 크다. 셋째, Parallel Session Awareness — 같은 프로젝트에서 여러 Claude Code 창이 동시에 돌 때 에이전트끼리 서로의 상태를 인식하게 한다.
특별한 툴 없이도 당장 실행할 수 있는 방법은 있다. 의미 있는 세션 전환 시점마다 '체크포인트 문서'를 남기는 것이다. 결정 사항, 막힌 지점, 현재 상태를 마크다운으로 정리해두면 도구를 바꿔도 컨텍스트를 이어받을 수 있다. Datopian의 CTO 사례에서도 같은 방법이 등장한다. 이건 에이전트를 위한 게 아니라 나를 위한 기록이기도 하다.
오케스트레이션: 병렬 에이전트의 병목은 스펙 업스트림에 있다
세 번째 레이어는 여러 에이전트를 동시에 돌리는 팀에서 특히 선명하게 드러난다. Datopian의 Rufus Pollock과 Anuar Ustayev가 멀티 에이전트 워크플로우를 실제 운영한 경험을 정리한 글에서 핵심 진단이 나온다. "병목이 이동했다." 1년 전엔 구현 용량이 부족했다. 지금은 정의 용량이 부족하다. Claude Code나 Codex로 에이전트를 병렬로 돌리는 건 가능해졌는데, 그 에이전트들이 제대로 달릴 수 있도록 스펙을 만드는 데 오히려 더 많은 시간이 걸린다.
Rufus는 솔직하게 인정한다. "사람 개발자였으면 스크린샷 하나로 30초에 이해할 걸 AI에게 설명하는 데 20분을 쓴다." 스펙 작성이 느린 이유는 도구 문제가 아니다. 개발자들이 shaping 단계를 건너뛰기 때문이다. 거칠게 잡은 아이디어를 바로 에이전트에 던지면 에이전트는 '완성된 것처럼 보이지만 틀린 것'을 만들어낸다. 그걸 다시 풀어내는 비용이 처음부터 제대로 스펙을 쓰는 비용보다 크다.
또 하나의 구조적 문제는 세션 단절이다. ChatGPT로 리서치하고, Claude로 설계하고, Codex로 구현하고, Gemini로 디버깅하는 하루가 현실이다. 각 세션은 고립되어 있다. 통합 히스토리가 없고, 검색도 안 된다. 이를 해결하는 도구는 아직 없다. 현실적인 대응은 하나의 도구에 일관성 있게 머무르거나, 체크포인트 문서로 세션 간 연결고리를 직접 만드는 것이다.
시사점: 팀이 설계해야 할 것은 에이전트가 아니라 환경이다
세 편의 기사가 서로 다른 각도에서 같은 결론을 가리킨다. AI 에이전트 실패의 원인은 모델 성능이 아니라 모델이 놓인 환경이다. 명세가 검증 가능한 형태로 작성되어 있는가, 이전 세션의 지식이 다음 세션에 전달되는가, 병렬로 달리는 에이전트들이 같은 컨텍스트를 공유하는가. 이 세 가지가 갖춰지지 않으면 더 좋은 모델로 바꿔도 결과는 크게 달라지지 않는다.
AI-First 팀을 리빌딩할 때 내가 가장 먼저 점검하는 것도 이 삼각형이다. 티켓에 형용사가 몇 개나 있는지, 에이전트가 세션을 넘어 무언가를 기억하는 구조가 있는지, 여러 에이전트가 동시에 달릴 때 누가 전체 상태를 보고 있는지. 이 환경을 설계하는 게 이제 테크 리드의 핵심 역할이다.
전망: 플랫폼이 해결하지 못할 것
멀티 에이전트 오케스트레이션 도구는 빠르게 성숙하고 있다. Claude Code의 서브에이전트 지원, 통합 세션 히스토리, 자동 모델 라우팅—이런 기능들은 플랫폼이 결국 해결할 것이다. 하지만 플랫폼이 해결하지 못할 게 하나 있다. 스펙을 검증 가능하게 쓰는 훈련, 세션을 끊기 전에 체크포인트를 남기는 습관, 에이전트를 돌리기 전에 shaping을 완료하는 규율. 이건 팀 문화의 문제다.
지금 당장 할 수 있는 것은 명확하다. 다음 티켓을 에이전트에 넘기기 전에, acceptance criteria에서 형용사를 모두 찾아 숫자로 바꿔라. unhappy path를 한 줄씩 추가해라. 그리고 세션을 닫기 전에 결정 사항 세 줄을 마크다운으로 남겨라. 모델을 바꾸는 것보다 이게 먼저다.