에이전트를 붙이는 건 쉬워졌다. Claude Code든 Cursor든 GitHub Copilot Workspace든, 리포지터리 하나에 연결하고 프롬프트 몇 줄 넣으면 코드가 나온다. 문제는 그 다음부터다. 에이전트가 며칠째 혼자 빌드하고, 수백 줄짜리 PR을 쏟아내고, 팀 전체 코드베이스 위에서 멀티 세션을 돌리는 순간—'붙이는 것'과 '운영하는 것' 사이의 거리가 본격적으로 벌어진다.
최근 세 편의 기술 글이 거의 동시에 같은 문제를 다른 각도에서 짚었다. 에이전트를 신뢰할 수 있게 운영하기 위한 하네스 설계, 대형 코드베이스에서 에이전트가 환각을 일으키는 구조적 원인, 그리고 에이전트 도입 이후 PR 리뷰 프로세스가 무너지는 이유. 세 편 모두 결국 같은 메시지를 전달한다—에이전트는 도구가 아니라 운영 대상이다.
하네스: 프롬프트로는 에이전트를 붙잡을 수 없다
dev.to에 올라온 'The Six-Component Harness' 시리즈는 내가 요즘 팀에게 가장 자주 공유하는 글 중 하나다. 저자는 Claude Code로 실제 프로젝트를 여러 주에 걸쳐 자율 빌드한 경험을 바탕으로, 4개 컴포넌트 하네스(시스템 프롬프트·태스크 리스트·진행 파일·테스트)로는 '이론상 작동'만 가능하고, 실제 진화하는 코드베이스에서는 버텨내지 못한다고 단언한다.
핵심은 두 가지 추가 컴포넌트다. 첫째는 feature_list.json으로 관리되는 ground truth 파일—각 피처의 passes 필드는 에이전트가 '완료했다고 믿을 때'가 아니라 Playwright 기반 E2E 테스트가 실제로 통과했을 때만 true로 바뀐다. 여기서 touches와 depends_on 필드가 핵심 역할을 한다. touches는 해당 피처가 건드리는 공유 코드 표면을 명시해 리그레션 게이트를 작동시키고, depends_on은 선행 피처가 통과하지 않으면 현재 피처를 아예 시도조차 못 하게 막는다.
둘째는 세션 메모리 파일(claude-progress.txt)과 스타트업 리추얼(init.sh)의 조합이다. 에이전트는 새 세션을 시작할 때 이전 세션의 기억이 전혀 없다. 메모리 파일이 없거나 부정확하면 에이전트는 코드에서 프로젝트 상태를 추론하는데—이게 충분히 자주 틀린다. 스타트업 리추얼은 환경 가정을 '희망'이 아닌 '검증된 사실'로 만들고, 이전 세션에서 커밋되지 않은 변경이 있으면 즉시 경고를 띄운다.
이 프레임워크가 말하는 것은 명확하다. 에이전트를 신뢰하려면 에이전트가 스스로를 검증할 수 있는 구조를 먼저 깔아야 한다. 프롬프트를 정교하게 쓰는 것, 시스템 프롬프트에 규칙을 잔뜩 넣는 것—그것들은 '기대'지 '제어'가 아니다.
환각: 문제는 컨텍스트 크기가 아니라 관계 구조다
두 번째 글은 MCP 에이전트가 대형 코드베이스에서 환각을 일으키는 원인을 다룬다. 예시가 인상적이다. 에이전트는 deleteUser() 함수를 찾고, AuditService를 찾고, 변경을 가했다. 로컬 테스트도 통과했다. 그런데 틀렸다. 실제 사용자 삭제는 saga를 통해 이루어지고, 감사 이벤트는 워커에서 발행되며, 에이전트가 편집한 함수는 테스트 코드에서만 쓰이는 것이었다.
저자의 진단은 정확하다—에이전트는 파일을 검색하지, 관계를 탐색하지 않는다. 컨텍스트 창 크기의 문제로 보는 시각이 많은데, 그건 절반짜리 분석이다. 진짜 난제는 이 서비스가 실제로 이 동작을 소유하는지, 이 코드 경로가 프로덕션 경로인지 아니면 데드 코드인지, 무엇이 무엇을 호출하는지를 에이전트가 파악하는 것이다. 벡터 검색은 '유사한 텍스트'를 찾을 수 있지만 '이 메서드는 deprecated API의 래퍼이고 실제 사이드이펙트는 세 단계 하위 큐 컨슈머에서 발생한다'는 사실을 알려주지 않는다.
제안된 해법은 지식 그래프다. 파일·함수·서비스·API·MCP 도구·권한 정책을 노드로, calls·imports·emits·deprecated_in_favor_of 같은 관계를 엣지로 구성한다. 에이전트가 '사용자 삭제를 언급하는 파일이 무엇인가'가 아니라 '사용자 삭제의 프로덕션 실행 경로가 무엇이고, 어떤 정책과 감사 컴포넌트가 붙어 있는가'를 물을 수 있게 된다.
실용적인 조언도 따라온다. 거대한 'AI 그래프 플랫폼' 프로젝트를 런칭할 필요는 없다. 파일·함수·서비스·MCP 도구에 대한 노드를 만들고, import·call·ownership·auth 요구사항에 대한 엣지를 추가하고, deprecated 경로를 명시적으로 마킹하는 것부터 시작하면 된다. 핵심 기준은 하나다—에이전트가 '이것을 언급하는 것이 무엇인가'는 답할 수 있지만 '이것에 실제로 의존하는 것이 무엇인가'는 답할 수 없다면, 프로덕션 수준 코드베이스에서 반드시 환각이 생긴다.
PR 병목: 리뷰 프로세스가 죽는 것이지, PR이 죽는 게 아니다
세 번째 글은 'PR이 죽는다'는 AI 업계의 내러티브를 정면으로 반박한다. Faros AI가 1,255개 엔지니어링 팀을 분석한 데이터가 출발점이다—AI 코딩 도구를 쓰는 팀은 PR 병합이 98% 증가했지만, 코드 리뷰 시간은 91% 늘었고, PR 크기는 154% 커졌으며, 버그율은 9% 올랐다. 숫자는 사실이다. 그런데 여기서 'PR이 죽는다'는 결론으로 점프하는 것은 논리의 비약이다.
저자의 진단은 이렇다—문제는 PR이라는 포맷이 아니라, 팀이 리뷰 프로세스를 가변 처리량을 감당하도록 설계한 적이 없다는 것이다. AI 도입 전에는 하루 2~3개 PR, 몇 백 줄짜리가 자연스러운 페이스였다. 누가 설계한 게 아니라 그냥 그 속도에 맞게 정착된 것이다. 에이전트가 하루 5~8개, 500줄짜리 PR을 쏟아내기 시작하면 리뷰어는 당연히 익사한다. 이건 포맷 문제가 아니라 프로세스 설계 문제다.
'PR 폐기론'이 틀린 이유도 세 가지로 정리된다. 첫째, 대부분의 팀은 아직 에이전트 주도 개발의 프론티어에 있지 않다—자동완성과 채팅을 쓰는 팀에게 PR 병목은 아직 이론적 문제다. 둘째, fintech·healthcare·defense 등 SOC 2·HIPAA 규정 환경에서 인간 코드 리뷰는 옵션이 아니라 규제 체크박스다. AI 에이전트가 다른 AI 에이전트의 코드를 승인하는 것은 감사관을 만족시키지 못한다. 셋째, 대안의 비용이 과소평가된다—Devin은 시트당 월 $500이고, 에이전트 오케스트레이션 인프라를 이해하는 팀이 필요한 솔루션은 5인 스타트업에게 현실적인 답이 아니다.
실제 작동하는 패턴은 더 단순하다. PR을 작게 만드는 것—정책이 아니라 에이전트 태스크 분해를 잘 해서. 아키텍처 규칙을 린터와 CI 체크에 박아서 인간이 보기 전에 구조 문제를 잡는 것. 그리고 인간 리뷰는 코드 문법이 아니라 인텐트에 집중하는 것—스펙과 수락 기준을 리뷰하고, 코드 검증은 기계에게 넘기는 것.
테크 리드로서의 해석: 세 글이 합쳐서 말하는 것
이 세 편을 같이 읽으면 하나의 그림이 나온다. 에이전트를 프로덕션 수준으로 운영하는 것은 세 개의 레이어 문제다.
레이어 1—에이전트 실행 제어: 하네스가 없으면 에이전트는 자신이 완료했다고 '믿는' 순간 멈춘다. Ground truth 파일, 세션 메모리, 스타트업 리추얼, E2E 검증 레이어가 없으면 자율 세션이 길어질수록 드리프트가 쌓인다.
레이어 2—컨텍스트 구조화: 에이전트에게 파일을 더 많이 주는 것은 답이 아니다. 코드베이스가 이미 그래프 구조를 갖고 있는데 에이전트에게 플랫 뷰만 주면 관계를 추론하고—그 추론이 틀린다. 벡터 검색과 지식 그래프를 함께 써서 후보 파일을 찾고 실행 경로를 검증하는 구조가 필요하다.
레이어 3—팀 프로세스 재설계: 에이전트가 PR 처리량을 두 배로 늘렸는데 리뷰 프로세스가 그대로라면 병목이 아니라 붕괴다. 기계 검사를 CI에 올리고, 리뷰어의 인지 에너지를 인텐트 검증에 집중시키고, PR 크기를 태스크 분해 단계에서 통제하는 것이 정답이다.
팀에 에이전트를 도입하려는 테크 리드에게 솔직하게 말하면—에이전트를 프로덕션 워크플로우에 붙이는 데 하루가 걸린다면, 그것을 신뢰할 수 있게 운영하는 데는 몇 주가 걸린다. 하네스를 설계하고, 코드베이스의 관계 구조를 에이전트가 탐색할 수 있게 만들고, 팀의 리뷰 프로세스를 가변 처리량에 맞게 재설계하는 것—이 세 가지는 AI 도구 도입 비용에 반드시 포함해야 한다. 이 비용을 계산하지 않고 '에이전트 도입했으니 생산성 두 배'를 기대하면, Faros AI의 데이터가 보여주는 대로 버그율과 리뷰 시간이 함께 올라가는 현실을 마주하게 된다.
에이전트 시대의 테크 리드 역할은 결국 여기 수렴한다—에이전트가 자율적으로 움직일 수 있는 구조를 설계하는 것. 에이전트 자체의 능력보다 에이전트를 감싸는 하네스, 컨텍스트 구조, 팀 프로세스가 운영의 품질을 결정한다. 도구를 고르는 시간보다 이 구조를 설계하는 시간이 훨씬 더 많이 들어야 한다.