에이전트/자동화 제품에서 퍼널이 흔들리는 지점은 모델 성능이 아니라 ‘사용자가 다시 쓸 수 있느냐’입니다. 그리고 다시 쓰게 만드는 핵심은 신뢰성(reliability)입니다. 한 번이라도 “얘가 엉뚱한 파일을 봤다”, “최신 정보라더니 옛날 링크를 요약했다”가 발생하면, 유저는 학습합니다. 다음부터는 결과를 의심하고, 검증 비용을 추가하고, 결국 수동 작업으로 회귀합니다. 그 순간 Retention은 떨어지고, 재시도/검수로 마진도 같이 무너집니다.
dev.to의 MCP 프로덕션 회고(‘3 MCP server failure modes…’)는 이 신뢰 붕괴가 어떻게 ‘조용히’ 시작되는지 보여줍니다. 데모에서는 깔끔하던 MCP가 고객 코드베이스·자격증명·컨테이너에 들어가면, 스펙이 침묵하는 엣지에서 사고가 터집니다. 특히 첫 번째 실패 모드인 built-in tool shadowing(내장 툴이 MCP 툴을 가리는 현상)은 사용자 입장에서 가장 위험합니다. 에이전트가 원래는 샌드박스 MCP를 통해서만 파일을 읽어야 하는데, SDK 내장 Read/Glob/Bash 같은 툴이 살아있으면 ‘더 쉬운 길’을 택해 경계를 넘어갑니다. 결과가 그럴듯하면 더 큰 문제입니다. QA에서는 “생산성 높네”로 보이고, 운영에서는 “왜 우리 앱 내부 경로(/app)를 참조하지?” 같은 신뢰 파괴로 돌아옵니다.
두 번째 실패 모드(여러 MCP 서버에서 툴 이름 충돌)도 성장 관점에선 치명적입니다. 동일한 read_file이라도 ‘로컬 워크스페이스’와 ‘GitHub 원격 리포’는 스키마도 의도도 다릅니다. 충돌이 런타임에서 랜덤하게 드러나면, 사용자는 이를 “에이전트가 멍청하다”로 인식합니다. 하지만 실제 원인은 오케스트레이션 레이어의 네이밍/라우팅 결함이죠. 이 클래스의 버그는 특히 Activation 단계에서 “첫 성공 경험”을 깨뜨려 D1을 바로 깎습니다.
여기에 ‘데이터 신선도’가 결합되면 리텐션은 더 빠르게 붕괴합니다. dev.to의 Exa 이슈 글(‘Exa Just Removed /research…’)은 전형적인 silent breakage(조용한 폐기)를 다룹니다. /research 종료는 에러로 드러나니 오히려 낫습니다. 문제는 startCrawlDate/endCrawlDate 필터가 200을 반환하면서도 무시되기 시작한 것, 그리고 응답 필드가 null로 변했다가 제거되는 과정입니다. 에이전트는 계속 “작동”합니다. 테스트도 녹색입니다. 다만 결과가 서서히 오래된 페이지로 기울고, “이번 달 동향”이 과거 자료를 요약하기 시작합니다. 즉, 제품이 망가지는 게 아니라 신뢰가 마모됩니다. 이 신뢰 마모는 D7/D30에서 ‘왜 계속 써야 하지?’로 돌아와 이탈로 연결됩니다.
시사점은 명확합니다. 신뢰성은 기능 품질이 아니라 운영 지표로 관리해야 합니다. 실행 액션을 세 가지로 정리합니다.
1) 툴 접근 기본값을 Default-Deny로 전환: MCP는 allowlist만으로 부족할 수 있습니다(내장 툴이 별도로 남아있기 때문). 내장 툴을 명시적으로 disallow하고, 시스템 프롬프트에도 “절대 사용 금지”를 중복으로 박아 ‘선택지’ 자체를 제거해야 합니다(출처: MCP 회고 글).
2) 툴 네임스페이스를 제품 규약으로 고정: mcp__
전망: 에이전트 시장이 커질수록 ‘신뢰성/신선도’는 차별화가 아니라 생존 조건이 됩니다. 모델은 상향 평준화되고, 툴/데이터 공급망은 더 복잡해집니다. 그러면 경쟁 우위는 “무엇을 할 수 있나”가 아니라 “언제나 같은 경계 안에서, 최신 근거로, 예측 가능한 실패를 하느냐”로 이동합니다. 앞으로의 그로스 레버는 여기에 있습니다. 신뢰성에 투자하면 CS·환불·재시도 비용이 줄고(마진), 첫 성공 경험이 안정화되며(Activation), 장기 코호트가 무너지지 않습니다(Retention). 결국 에이전트 신뢰성=리텐션입니다.