에이전트는 기회가 생기면 반드시 탈선한다
"에이전트가 말을 안 들어요." 팀원한테서 이 말을 들을 때마다 저는 속으로 생각합니다. 당연하지. AI 코딩 에이전트는 기본적으로 신뢰할 수 없는 동료입니다. 뛰어나고, 빠르고, 지치지 않지만—감시를 풀면 반드시 탈선합니다. 이건 모델 성능의 문제가 아니라 구조의 문제입니다. 그리고 지금 현장의 개발자들은 그 구조를 맨몸으로 설계하고 있습니다.
최근 세 편의 글이 각기 다른 각도에서 이 문제를 정확하게 포착했습니다. 하나는 AI 코딩 세션을 Git 커밋에 추적하는 도구(git-memento), 하나는 에이전트를 믿지 않아서 7겹 가드레일을 직접 만든 개발자의 고백(dev.to), 그리고 하나는 AI 에이전트가 자기 비용을 스스로 추적하게 만든 MCP 서버 구현기(dev.to). 주제는 달라 보이지만 핵심은 하나입니다. 에이전트에게 신뢰를 주는 게 아니라, 신뢰를 설계해야 한다는 것.
신뢰 문제 1: 컨텍스트는 사라지고, 의도는 증발한다
dev.to에 올라온 글 「I stopped trusting my coding agents, so I built a system to not trust them」은 제목부터 직설적입니다. 저자는 Cursor와 Claude로 대규모 프로젝트를 1년간 운영하면서 MCP 메모리, 병렬 에이전트 20개, 장시간 세션을 시도했지만 결론은 하나였습니다. 에이전트는 컨텍스트를 잃고, 당신도 컨텍스트를 잃는다.
그가 만든 projects_control 시스템은 이 문제를 구조로 해결합니다. 핵심 아이디어는 프롬프트 파일이 곧 메모리이자 커뮤니케이션 채널이라는 것. 에이전트는 마크다운 파일을 읽고, 결과를 다시 그 파일에 씁니다. 다음 세션은 그 파일을 이어받아 시작합니다. 공유 메모리도, 트랜스크립트 파싱도 없습니다. 문서가 상태(state)가 됩니다.
이게 Claude한테 물어봤을 때도 자주 나오는 패턴인데요—에이전트의 컨텍스트 지속성 문제는 더 좋은 모델로 해결되는 게 아닙니다. 세션과 세션 사이를 잇는 구조를 직접 설계해야 합니다.
신뢰 문제 2: 에이전트는 '계획만 해'를 무시한다
같은 글에서 가장 인상적인 부분은 이것입니다. 저자는 리서치 에이전트와 플랜 에이전트가 코드를 직접 구현하지 못하도록 7겹의 가드레일을 쌓았습니다.
- CLI 플래그(
--mode plan) - 워크트리 격리(임시 git 브랜치에서만 작업)
- 액터 프롬프트 내 명시적 금지 지시
- 비평가 프롬프트의 프레이밍 통제
- 피드백 주입 시 리마인더
- 프롬프트 게이트(실행 전 검증)
- 비평가 게이트(결과 후 검증)
7겹. 하나도 아니고. 이 숫자가 상징하는 게 뭔지 팀원들한테 꼭 보여주고 싶습니다. 에이전트는 "하지 마"라는 말을 액면 그대로 받아들이지 않습니다. 그 말이 구조적으로 강제되어야 합니다.
Lead Software Engineer인 또 다른 저자(dev.to 「Agentic Development」)는 다른 각도에서 같은 교훈을 공유합니다. AI가 네트워크 요청 실패 시 자동으로 레거시 플로우로 폴백하는 로직을 스스로 삽입했습니다. 요청하지도, 명세하지도 않았지만—그게 일반적인 패턴이니까 추론해서 넣은 겁니다. 이런 그럴듯한 환각(plausible hallucination)이 리뷰 없이 프로덕션에 들어갔다면 어떻게 됐을까요. 에이전트를 믿는 게 아니라, 에이전트의 가정을 검증하는 게 개발자의 핵심 역할이 된 겁니다.
신뢰 문제 3: 비용은 조용히, 그리고 빠르게 불어난다
dev.to의 「I Built an MCP Server So My AI Agent Can Track Its Own Spending」은 또 다른 차원의 신뢰 문제를 건드립니다. 대부분의 에이전트 프레임워크는 비용 인식이 없습니다. 에이전트는 claude-sonnet을 호출하고, 결과를 받고, 다음 단계로 넘어갑니다. 방금 $0.04를 썼다는 사실을 모릅니다. 하루 200번 호출하면 점심 전에 $8이 사라집니다.
저자가 만든 agent-budget-guard는 세 겹입니다. BudgetGuard(호출 후 추적), AgentWatchdog(런타임 서킷 브레이커), MCP Server(에이전트가 직접 자기 지출을 조회). 실제 수치가 인상적입니다. 30분마다 하트비트를 치는 것만으로 하루 $4.20. 측정하지 않으면 절대 알 수 없는 숫자입니다.
이거 자동화하면 팀이 더 중요한 일에 집중할 수 있다고 항상 말하는데—자동화 전에 측정 레이어가 먼저입니다. 비용이 어디서 새는지 모르면 최적화도 없습니다.
신뢰 문제 4: AI가 쓴 코드, 왜 그렇게 썼는지 아무도 모른다
git-memento(geeknews 소개)는 이 문제를 감사(audit) 관점에서 접근합니다. AI가 생성한 코드는 커밋에 남지만, 그 코드가 어떤 프롬프트와 대화에서 나왔는지는 사라집니다. git-memento는 커밋 시점에 AI 세션 대화를 git notes로 함께 저장합니다. 요약본은 refs/notes/commits, 전체 로그는 refs/notes/memento-full-audit으로 분리해 추적성과 프라이버시를 동시에 확보합니다.
Hacker News 댓글 중 가장 핵심을 찌른 문장이 있습니다. "요즘 엔지니어들이 너무 빠르게 작업해서, 일주일만 지나도 왜 그렇게 했는지 기억 못한다." AI가 코드를 쓰면 이 문제는 더 심각해집니다. 코드를 쓴 건 AI고, 의도는 프롬프트에만 있고, 프롬프트는 세션이 닫히면 사라집니다.
물론 "세션 로그가 다 잡음"이라는 반론도 타당합니다. 잘못된 시도, 롤백, 사소한 수정까지 다 남기는 건 브라우저 히스토리를 커밋에 포함하는 것과 같다는 비유도 납득이 갑니다. 그래서 git-memento의 접근—요약본과 전체 감사 로그를 분리 저장하는 것—이 현실적인 절충점이 됩니다. 모든 걸 다 보존하되, 일상적으로는 요약만 노출하는 방식입니다.
시사점: 에이전트 신뢰 체계는 '설계'의 영역이다
세 편의 글을 관통하는 공통점이 있습니다. 에이전트를 믿는 게 아니라 믿을 수 있는 구조를 만드는 것이 개발자의 역할이 됐다는 겁니다. 구체적으로는 네 가지 레이어가 필요합니다.
- 컨텍스트 지속성: 프롬프트 파일이 세션 간 메모리 역할을 하도록 설계. 에이전트가 컨텍스트를 잃어도 문서에서 복구 가능해야 함
- 실행 격리: 리서치·플랜·구현 에이전트를 분리하고, 각 역할이 경계를 넘지 못하도록 다층 가드레일 구축
- 비용 가시성: 에이전트 호출마다 비용을 추적하고, 예산 초과 시 자동 차단하는 서킷 브레이커 운영
- 감사 추적: AI가 쓴 코드의 의도와 맥락을 커밋 단위로 기록해 나중에 "왜 이렇게 했나"를 재구성 가능하게
이게 AI-First 워크플로우의 진짜 설계입니다. AI 도구를 쓰는 게 아니라, AI가 탈선하지 않는 시스템을 만드는 것.
전망: 에이전트가 많아질수록 감독 구조가 핵심 경쟁력이 된다
에이전트 하나를 쓸 때는 직관으로 통제할 수 있습니다. 에이전트가 4개, 8개, 팀 전체가 수십 개를 돌릴 때는 직관이 아니라 시스템이 필요합니다. 그리고 그 시스템을 먼저 잘 설계한 팀이 에이전트 확장의 실질적 이점을 가져갑니다.
저는 팀원들한테 항상 이렇게 말합니다. AI는 동료지만, 신입 동료가 아닙니다. 열심히 하지만 경계가 없으면 엉뚱한 곳으로 달려가는 동료입니다. 온보딩할 때 가이드라인 주고, 작업 범위 정해주고, 결과물 리뷰하는 것—에이전트도 정확히 같은 구조가 필요합니다.
신뢰는 주는 게 아니라 설계하는 겁니다.