3개월 동안 AI 에이전트로 사이드 프로젝트를 개발한 개발자가 있다. 기능은 빠르게 쌓였고, 테스트는 계속 그린이었다. 그런데 어느 날 파일을 열었더니 3,000줄짜리 뷰 파일이 눈앞에 있었다. complexipy를 돌려보니 함수 하나의 순환 복잡도가 58이었다. '비슷하지만 조금 다른 기능'을 요청할 때마다 에이전트는 기존 구현을 복붙하고 몇 줄만 바꿨다. 리팩터링보다 복사가 안전하니까. Dev.to에 공개된 이 사례는 AI 코딩의 구조적 실패를 가장 솔직하게 보여주는 글 중 하나다.
비슷한 시기, 다른 개발자는 다른 방식으로 같은 벽에 부딪혔다. 하나의 전략 에이전트에게 WebSearch 권한을 주고 '오늘 주제 5개 고르고 글 써라'고 시켰다. 토픽 하나마다 3~4번 웹 검색, 총 15~20회. 컨텍스트에는 4만 토큰 이상의 검색 결과가 쌓였고, 에이전트는 내 콘텐츠 자산이 아니라 '최근 뉴스에서 확인된 것'을 기준으로 주제를 골랐다. 실행 시간은 20분. Dev.to의 이 글이 내린 진단은 단순하다: WebSearch를 판단 루프에 넣지 말라.
두 사례는 표면적으로 다르지만 실패 구조는 동일하다. 에이전트에게 너무 많은 권한을 주고, 피드백 루프를 설계하지 않고, '일단 돌아가면 OK'로 넘어간 것. 에이전트는 그 환경에서 합리적으로 행동했다. 문제는 에이전트가 아니라 환경이었다. 첫 번째 글의 표현을 빌리면: "에이전트는 내가 만들어준 환경에서 정확하게 행동했다. 버그는 에이전트가 아니라 환경이었다."
여기서 테크 리드로서 냉정하게 짚어야 할 포인트가 있다. AI 에이전트의 속도는 실제로 빠르다. 하지만 그 속도는 코드 생산 속도이지, 코드 이해 속도가 아니다. 인간의 멘탈 컨텍스트 윈도우는 에이전트를 도입한다고 늘어나지 않는다. 코드베이스 성장 속도만 늘어난다. 품질 게이트—린터, 타입 체커, 복잡도 임계값, 중복 탐지—가 '좋은 엔지니어링 관행'에서 '에이전트 실행의 전제 조건'으로 지위가 바뀐 이유가 여기 있다. 에이전트가 첫 줄을 쓰기 전에 설치해야 한다. 나중에 설치하면 이미 늦다.
멀티 에이전트 사례는 해법의 방향을 더 구체적으로 보여준다. 전략 에이전트에서 WebSearch를 제거하고 역할을 셋으로 분리했다. Observer(데이터 수집), Strategist(판단, 인터넷 차단), Marketer(실행, WebSearch 허용). Strategist의 토큰 소비는 8만에서 2만으로 줄었고, 실행 시간은 20분에서 3분이 됐다. 비용은 60% 감소. 핵심은 에이전트를 더 똑똑하게 만든 게 아니라 더 멍청하게 만든 것이다. 각 에이전트가 맡은 일만 하고, 그 일에 필요한 도구만 가지게 했다. 단일 책임 원칙이 에이전트 설계에서도 작동한다는 실증이다.
토큰 비용 문제는 코드 검색 레이어에서도 반복된다. MinishLab이 공개한 Semble은 grep+read 대비 토큰을 98% 절감하는 에이전트용 코드 검색 도구다. 에이전트가 낯선 코드베이스를 탐색할 때 파일 전체를 읽는 대신, tree-sitter로 코드 인식 청크를 나누고 BM25와 임베딩을 결합해 관련 스니펫만 반환한다. 2k 토큰으로 94% 재현율을 달성하는 반면, grep+read는 100k 컨텍스트로 85%에 그친다. 인덱싱은 250ms, 쿼리는 1.5ms. Claude Code, Cursor 등 MCP 호환 환경에서 바로 쓸 수 있다. 다만 Hacker News의 현장 피드백에는 주목할 만한 반론도 있다. 에이전트가 도구 결과를 신뢰하지 않고 계속 재검색하면 토큰 절감분이 사라진다는 것, 그리고 전체 에이전트 루프를 측정하지 않으면 '검색 토큰 감소'가 '작업 완료 비용 감소'와 다른 이야기가 될 수 있다는 것. 툴 자체가 좋다고 워크플로우가 자동으로 좋아지지는 않는다.
세 사례를 하나의 테제로 묶으면 이렇다: 구조 없이 속도를 올리면, 속도가 부채를 쌓는다. 순환 복잡도 58은 3개월 무구조 개발의 영수증이다. 20분 실행 시간은 단일 에이전트에 모든 권한을 몰아준 설계의 영수증이다. 98% 토큰 낭비는 에이전트가 코드베이스를 탐색하는 방식을 한 번도 설계하지 않은 팀의 영수증이다. 숫자는 다르지만 청구서의 원인은 같다.
팀 리드 입장에서 지금 당장 적용 가능한 설계 원칙 세 가지를 정리하면 다음과 같다. 첫째, 에이전트보다 피드백 루프가 먼저다. 린터, 복잡도 게이트, 타입 체커를 에이전트 첫 실행 전에 심어라. 'AGENTS.md'나 '.cursorrules'에 최대 함수 길이, 레이어 규칙, 복붙 금지 조항을 명시하라. 규칙은 에이전트가 하지 말 것을 알려주고, 스킬은 에이전트가 무엇을 써야 하는지를 알려준다—둘 다 필요하다. 둘째, 권한은 역할에만 붙여라. WebSearch가 판단 루프에 들어가는 순간 컨텍스트는 오염된다. 도구 허용 목록을 역할별로 명시적으로 잠가라. 셋째, 토큰 절감 도구는 에이전트 루프 전체로 검증하라. 검색 토큰이 줄어도 에이전트가 결과를 믿지 않아 재시도를 반복하면 전체 비용은 오히려 오른다. 도구 벤치마크가 아니라 실제 작업 완료 비용으로 측정해야 한다.
앞으로 AI 에이전트의 실행 능력은 계속 좋아질 것이다. 하지만 구조를 설계하는 일은 여전히 인간의 몫이다. 에이전트가 더 빠르게 코드를 쏟아낼수록, 그 코드가 쌓이는 구조를 잡는 데 더 많은 시간을 써야 한다. 아이러니하게도, AI-First 팀에서 테크 리드의 역할은 더 줄어드는 게 아니라—구조 설계자로서—더 핵심적이 된다. 에이전트를 믿되, 에이전트가 놀 운동장의 경계선은 당신이 그어야 한다.