데모는 통과했는데 프로덕션에서 조용히 깨진다
에이전트 데모는 쉽다. 모델이 툴을 부르고, 툴이 그럴듯한 값을 돌려주면 회의실에서 고개가 끄덕인다. 문제는 그 다음이다. 실제 사용자, 실제 데이터, 실제 돈이 붙는 순간—에이전트는 조용히, 4%의 확률로 틀린 일을 한다. 아무도 모른다. 고객이 먼저 알아채기 전까지는.
Dev.to에 올라온 'The Reliability Gap' 아티클이 이 현상을 정확하게 짚는다. 이 4%의 간극이 '그럴듯한 데모'와 '실제로 믿을 수 있는 시스템' 사이의 전부다. 그리고 일반적인 LLM 튜토리얼은 이 간극을 닫는 방법을 거의 가르쳐주지 않는다.
에이전트가 어렵게 만드는 세 가지 구조적 특성
첫째, 비결정성(non-determinism)이다. 같은 입력이 내일은 다른 툴 호출을 만들 수 있다. '내가 그 코드 건드리지 않았으니까 여전히 잘 작동하겠지'라는 회귀 직관이 에이전트 앞에서는 통하지 않는다. 세 단계 상류의 프롬프트 수정이 세 단계 하류의 의사결정을 바꾼다.
둘째, 무음 실패(silent failure)다. 전통적인 서비스는 예외를 던진다. 에이전트는 틀린 답을 올바른 답과 똑같은 모양으로 자신 있게 돌려준다. '모델이 인보이스 합계를 잘못 읽었습니다'에 대한 스택 트레이스는 존재하지 않는다.
셋째, 런타임 정답 부재다. 에이전트가 결정을 내리는 순간, 그 결정이 맞는지를 실시간으로 검증할 오라클이 없다. 나중에, 집계 수준에서, 측정했을 때만 알 수 있다.
이 세 가지를 내면화하면 하나의 관점 전환이 따라온다. 에이전트는 디버그하는 함수가 아니라 측정해야 하는 모집단이다.
첫 번째 방어선: Eval 세트를 CI에 연결하라
팀이 만들 수 있는 가장 레버리지가 높은 것은 Eval 세트다. '그럴듯하게 들리는가'가 아니라 '올바른 툴을 선택했는가, 정확한 필드를 추출했는가, 범위 밖 요청을 거부했는가'를 묻는 테스트다.
유용한 Eval 세트는 세 가지 조건을 갖춘다. 상상이 아닌 실제 트래픽에서 가져와야 한다. 프로덕션 인터랙션을 로깅하고, 이상한 케이스를 샘플링하고, 실패를 영구 테스트 케이스로 만들어야 한다. '환불 툴을 골랐는데 정책은 거부였다'처럼 검증 가능한 행동을 채점해야 한다. 그리고 반드시 CI에서 실행해야 한다. 프롬프트 수정이 한 지표를 올리면서 조용히 다른 지표를 떨어뜨리면, 유닛 테스트처럼 빌드를 실패시켜야 한다.
이 단계를 건너뛰는 팀이 대부분이다. 그리고 그게 '반복 개선이 가능한 에이전트'와 '건드리기 무서운 에이전트'의 차이를 만든다.
두 번째 방어선: 가드레일은 프롬프트가 아니라 코드로 구현하라
신뢰성을 프롬프팅 문제로 접근하는 팀이 많다. '절대로 ~하지 마세요' 단락을 하나 더 추가하고 기대를 건다. 그러나 프롬프트는 설득이지 강제가 아니다.
진짜 가드레일은 모델 바깥, 코드 레이어에 있어야 한다. '읽기 전용 지원' 상태의 에이전트는 delete_account 툴 자체를 스코프에서 제거해야 한다. 친절하게 부탁하는 게 아니라, 애초에 총을 쥐어주지 않는 것이다. 모든 툴 호출은 실행 전에 스키마와 비즈니스 룰로 검증해야 한다. 모델은 제안하고, 결정론적 코드가 실행 여부를 결정한다. 루프에는 반드시 상한선을 둬야 한다—최대 스텝, 최대 비용, 최대 재시도. 신용카드를 쥔 무한 루프 에이전트는 날짜를 기다리는 인시던트다.
멘탈 모델을 바꿔야 한다. LLM은 플래너고, 런타임이 방 안의 어른이다.
세 번째 방어선: AI 생성 코드의 보안 공백을 닫아라
에이전트가 코드를 직접 생성하는 팀이라면 또 다른 조용한 실패 지점이 있다. Dev.to에 공개된 GitGuardian MCP 사례가 이 문제를 정면으로 다룬다.
AI 코딩 에이전트가 빠르게 PR을 쏟아낼수록, 기존 DevSecOps의 'PR 체크 → 인간 리뷰' 흐름이 병목이 된다. 문제는 에이전트의 훈련 데이터 자체에 있다. 인간이 취약한 코드를 많이 작성했기 때문에, LLM도 취약한 패턴을 학습했다. 모든 에이전트 생성 코드 한 줄에는 알려진 나쁜 패턴을 포함할 확률이 0이 아니다.
GitGuardian은 MCP를 통해 GitHub Copilot 에이전트의 제어 플레인에 직접 보안 스캔 툴을 주입하는 방식으로 이 문제에 접근한다. 에이전트가 코드를 생성하는 순간, 커밋 전에, 하드코딩된 시크릿이나 취약 패턴을 감지하고 자동으로 수정할 수 있다. IDE 플러그인이 클라우드 에이전트 환경과 호환되지 않는다는 구조적 한계를 MCP 레이어로 우회한 셈이다.
이 접근의 핵심은 보안 검증을 에이전트의 워크플로우 안으로 당기는 것이다. 보안을 파이프라인 끝의 게이트가 아니라 생성 시점의 조건으로 설계한다.
실패 경험이 가르쳐준 것: 주도권을 넘기지 마라
긱뉴스에서 화제가 된 한 개발자의 글은 이 모든 논의를 개인 실패담으로 압축한다. Claude Code로 자동매매 시스템을 구축했다가 0승 8패, 자산 3% 손실. 블로그 자동발행 시스템은 검수 없이 내보낸 부정확한 글로 독자 피드백을 받았다.
두 실패의 공통 원인은 단순하다. AI에게 주도권을 넘겼다. 도메인 지식이 부족하면 AI가 짠 코드를 검증할 수 없다. 검증할 수 없으면 에이전트를 못 믿는다. 그런데도 그냥 켜두면—조용히 실패한다.
이 사례가 무거운 이유는 자동매매나 블로그에만 해당하는 이야기가 아니기 때문이다. 법적 근거, 의료 수치, 계약 금액을 다루는 에이전트에서 같은 실패가 벌어지면 손실의 규모가 달라진다.
팀 단위로 설계해야 할 방어 체크리스트
세 소스가 가리키는 방향을 팀 실행 관점으로 압축하면 이렇다.
즉시 적용 가능한 것: - Eval 세트를 CI에 연결한다. 첫 케이스 10개가 없는 것보다 낫다 - 툴 스코프를 상태 단위로 제한한다. 에이전트가 필요하지 않은 툴은 보이지 않게 한다 - 루프에 상한을 박는다. 스텝·비용·재시도 모두 - AI 생성 코드에 자동 시크릿 스캔을 붙인다. MCP 레이어가 가장 빠른 경로다
아키텍처 결정이 필요한 것: - Human-in-the-loop를 어디에 놓을지 설계한다. '완전 자율'이 목표가 되는 순간 설계가 틀렸다 - 법·금융·의료 도메인은 에이전트가 적합한 툴인지 먼저 묻는다 - 되돌릴 수 없는 액션은 사람이 서명하도록 강제한다
전망: 에이전트 신뢰성은 모델 성능이 아니라 팀 설계 역량으로 결정된다
모델은 점점 나아진다. 그러나 비결정성은 구조적 특성이지 버그가 아니다. 무음 실패는 에이전트의 본질이지 특정 버전의 문제가 아니다. 이 두 가지는 모델이 GPT-5가 되어도 사라지지 않는다.
결국 프로덕션 에이전트의 신뢰성은 모델 성능 경쟁이 아니라 팀이 얼마나 좋은 Eval 세트를 갖고 있는지, 가드레일을 코드로 강제하는지, AI 생성 결과물을 검증하는 루프를 설계했는지로 결정된다.
'boring infrastructure'라는 표현이 딱 맞다. Eval CI, 코드 기반 가드레일, 바운딩된 루프, 인간 체크포인트—어느 것도 화려하지 않다. 그런데 그게 전부다. 데모와 시스템의 차이는 거기서 만들어진다.
팀 리드로서 지금 당장 물어볼 질문은 하나다. 우리 에이전트가 틀렸을 때, 우리가 먼저 알 수 있는 구조로 되어 있는가?