할루시네이션은 빙산의 일각이다
에이전트가 거짓말을 한다는 건 이미 다 안다. 문제는 그 다음이다. "모델이 틀릴 수 있다"는 사실은 실제 운영에서 아무 행동 지침도 주지 않는다. 모든 출력을 두 번 확인하면 에이전트를 쓰는 이유가 사라지고, 그냥 믿으면 언제 터질지 모른다. dev.to에 올라온 Maxim Saplin의 분석은 바로 이 지점을 파고든다—할루시네이션 너머, 실제 에이전트 엔지니어링에서 반복적으로 나타나는 실패 패턴 21가지를 정리했다.
에이전트는 어디서 무너지는가
패턴을 읽어보면 크게 세 층위로 나뉜다.
첫 번째는 컨텍스트 붕괴다. "One-shotting"—전체 앱을 한 번에 삼키려다 컨텍스트를 소진하고 반쪽짜리 코드를 남기는 것—은 누구나 겪어봤을 거다. 여기에 "Cold-start amnesia"가 붙는다. 새 세션마다 이전 작업 맥락이 없어지고, 에이전트는 매번 실행 환경부터 다시 파악한다. "Working-memory rot"는 더 교묘하다. 컨텍스트 윈도우가 길어질수록 초반에 넣은 중요한 정보에 모델이 제대로 집중하지 못한다. 파일은 있는데 읽히지 않는 것이다.
두 번째는 품질 착각이다. "Progress-as-completion"—저장소에 커밋이 쌓이면 작업이 끝났다고 판단하는 패턴—은 특히 위험하다. "False E2E completion"도 같은 계열이다. 유닛 테스트는 통과하고 curl 응답도 나오지만 실제 사용자 플로우는 깨져 있다. "Self-review softness"까지 더해지면 에이전트가 스스로 자기 결과물을 칭찬하면서 검토를 마무리한다. 이 세 가지가 겹치면 팀은 완성된 줄 알고 배포 버튼을 누른다.
세 번째는 복잡성 폭발이다. "Overengineering by default"—에이전트가 인터넷에서 학습한 복잡한 패턴을 기본으로 적용하는 현상—은 코드베이스를 빠르게 무겁게 만든다. "Local patching"은 개별 변경은 합리적으로 보이지만 전체 시스템의 일관성이 점점 무너지는 문제다. "Overdecomposition"은 플래너-구현자-리뷰어 구조가 기술적으로는 작동하지만 레이턴시와 관성이 쌓여 결국 팀이 그 구조를 싫어하게 된다는 것을 말한다.
왜 이게 팀 피로로 이어지는가
Saplin이 테이블 밖에서 따로 지적한 두 가지가 핵심이다. 생성 속도가 리뷰 속도를 추월하면 병목이 타이핑에서 판단으로 이동한다. 코드, 테스트, 이슈, PR이 사람이 읽을 수 있는 속도보다 빠르게 쌓이면 아무도 그 코드를 실제로 이해하지 못한 채 배포가 일어난다. 장애가 나도 "왜 이 코드가 여기 있는지" 아는 사람이 없다. 이게 AI-First 팀이 실제로 마주치는 가장 큰 운영 리스크다.
MCP가 이 문제에 답하는 방식
이 맥락에서 MCP 도입 결정을 다시 보면 우선순위가 달라진다. 단순 편의 기능이 아니라, 에이전트 실패 모드를 구조적으로 줄이는 설계 선택이 된다.
Graham Dues가 정리한 일상 MCP 스택 세 가지는 단순해 보이지만 실패 모드 관점에서 읽으면 의미가 다르다. Filesystem MCP는 Cold-start amnesia를 부분적으로 완화한다. 에이전트가 세션마다 파일을 직접 읽을 수 있으면 "이전에 뭐가 있었지?"를 추측하는 시간을 줄인다. GitHub MCP는 Progress-as-completion 리스크를 낮춘다. 실제 PR과 이슈 상태를 직접 확인할 수 있으면 에이전트가 커밋 수만 보고 완료를 선언할 가능성이 줄어든다. PostgreSQL MCP는 False E2E completion에 대응한다. 실제 데이터를 직접 조회해서 사용자 플로우를 검증할 수 있는 경로가 생긴다. 설정은 각각 2분이다. 학습 곡선은 거의 없다.
에이전트 간 공유 메모리: 다음 층위의 실험
Chen Yuan이 만든 MCP 서버는 한 단계 더 나아간다. 에이전트들이 서로 실패 경험을 공유하는 구조다. check_failures 툴은 kubectl delete나 terraform apply 같은 위험 명령을 실행하기 전에 과거 유사 실패 이력과 위험 점수를 돌려준다. resolve_reasoning은 알려진 문제에 대한 캐시 솔루션을 먼저 확인해서 동일한 디버깅을 반복하는 토큰 낭비를 막는다.
이건 Blind N-step execution 문제를 직접 공략한다. 에이전트가 막힌 상황에서 같은 접근을 반복하다 결국 컨텍스트를 소진하는 패턴에, "이 방향은 이미 30%가 실패했다"는 사전 경고가 개입하는 구조다. 155줄짜리 bash 래퍼 s는 로컬 텔레메트리를 기록하고 실패율이 20%를 넘으면 실행 전에 확인을 요청한다. 서버 의존성 없이 로컬에서 바로 쓸 수 있다는 점이 실용적이다.
팀에 적용할 때 실제 판단 기준
세 소스를 종합하면 팀 도입 순서가 보인다.
먼저 Filesystem + GitHub MCP부터 시작하라. 설정 비용이 거의 없고 Cold-start amnesia와 Progress-as-completion이라는 가장 빈번한 실패 모드를 즉시 완화한다. 팀 전체가 이틀 안에 적용할 수 있다.
그 다음 리뷰 루프에 인간 게이트를 명시적으로 설계하라. 에이전트가 생성한 결과물의 검증 비용이 낮은 영역—테스트, 쿼리, 문서—과 높은 영역—아키텍처 변경, 보안 관련 코드—을 나눠서 전자만 자동화 루프에 넣어라. Saplin의 "slow down" 원칙은 에이전트를 덜 쓰라는 게 아니라 검증 가능한 범위 안에서만 쓰라는 말이다.
공유 실패 메모리 MCP는 DevOps 자동화가 먼저 안정된 팀에 도입하라. 에이전트 간 공유 메모리는 강력하지만, 기반 워크플로우가 불안정하면 잘못된 실패 패턴이 캐시에 쌓여서 오히려 에이전트를 잘못된 방향으로 유도할 수 있다.
결국 MCP는 에이전트 실패를 설계로 흡수하는 구조다
MCP 도입을 "Claude에 기능 추가"로 보면 우선순위를 잘못 잡는다. 21가지 실패 모드를 보고 나면 MCP는 에이전트의 구조적 취약점—컨텍스트 단절, 검증 부재, 반복 실패—을 툴 레이어에서 흡수하는 설계 결정이다. 어떤 MCP를 먼저 붙이느냐는 팀이 어떤 실패 모드에 가장 자주 물리느냐에서 역산해야 한다. 에이전트가 어디서 무너지는지 모르면 MCP를 붙여도 같은 자리에서 다시 무너진다.