에이전트는 클래식 소프트웨어처럼 죽지 않는다. 스택 트레이스도, 빨간 대시보드도 없다. 그냥 계속 돌아간다. 틀린 숫자를 자신 있게 반환하면서, 실패한 접근을 반복하면서, 아무도 눈치채지 못하는 사이에. 이게 에이전트 신뢰성 문제의 본질이다. 그리고 이 문제를 팀 레벨에서 사전에 차단하지 않으면, 프로덕션 배포는 결국 조용한 사고를 향한 카운트다운이 된다.
최근 세 가지 실전 사례가 같은 질문으로 수렴된다. '에이전트를 프로덕션에 내보내기 전, 무엇을 강제해야 하는가?' AgentGuard의 거버넌스 레이어 설계, AI 에이전트 자체 검증의 구조적 한계를 다룬 분석, 그리고 Claude Agent SDK 배포 과정에서 마주친 실제 함정들. 각각의 맥락은 다르지만, 가리키는 방향은 하나다.
첫 번째: 거버넌스는 문서가 아니라 강제 실행 레이어다
AgentGuard를 소개한 dev.to 포스트가 던지는 핵심 메시지는 단순하다. "프롬프트는 기초가 아니다. 기둥이다. 그것도 늪 위에 세운." CLAUDE.md에 '루프에 빠지지 마라', '중요한 결정 전에 확인해라'라고 적어두는 건 의도의 표현이지, 강제 실행이 아니다. 에이전트는 그 텍스트를 읽고 해석할 뿐, 위반 시 차단되지 않는다.
AgentGuard가 제안하는 구조는 다르다. 에이전트가 시작하기 전에 네 가지를 강제로 확인한다. 에이전트 오너가 정의되어 있는가, 허용된 스코프가 명시되어 있는가, 에스컬레이션 경로가 설정되어 있는가, 킬스위치가 존재하는가. 하나라도 빠지면 실행이 차단된다. 그리고 Claude Code의 훅 메커니즘을 통해 모든 툴 호출을 사전 심사한다. LLM 판단이 아닌 패턴 매칭 기반의 결정론적 검사다. 느리지 않고, 틀리지 않는다.
테크 리드 입장에서 이 접근이 흥미로운 이유는 하나다. 거버넌스를 '나중에 할 일'이 아니라 '실행의 전제 조건'으로 구조화했다는 것. 아직 88%의 에이전트 프로젝트가 프로덕션에 도달하지 못한다는 수치가 인용되는데, 모델 문제가 아니라 이 기초 설계의 부재라는 진단은 충분히 설득력 있다.
두 번째: '검증됨' 배지를 에이전트 스스로 달게 하지 마라
두 번째 사례는 더 근본적인 문제를 건드린다. 에이전트가 자신의 로그를 쓰고, 그 로그를 읽어 자신이 제대로 작동했는지 확인하는 구조. dev.to의 한 분석 포스트는 이걸 '자기 기술에 단계를 하나 추가한 것'이라고 부른다. 그 단계가 오히려 위험한 이유는, 초록색 체크마크에 신뢰를 세탁하기 때문이다.
논리는 간단하다. 에이전트가 'X를 실행했다'고 로그에 썼다면, 외부에서는 실제로 X가 실행된 것과 기록만 쓴 것을 구분할 방법이 없다. 해시값도 마찬가지다. 값을 보유했음은 증명하지만, 실제로 실행됐음은 증명하지 못한다. 실행은 세계에 대한 사실이고, 자기 저술 로그는 세계의 증인이 아니다.
해결 방향은 '정직함을 증명하려는 시도'를 포기하고, '부정직함이 흔적을 남기는 구조'를 만드는 것이다. 저자가 통제할 수 없는 외부 표면에 검증 포인트를 두어야 한다. 검사가 제3자에 의해 재실행 가능한가, 결과가 저자가 사후에 수정할 수 없는 곳에 기록되는가, 실패해야 할 벡터가 실제로 실패를 트리거하는가. 이 세 질문이 통과되지 않는 '검증됨' 표시는 장식이다.
팀 워크플로우에 이걸 적용하면 실천 방향이 명확해진다. AI 코드 리뷰 자동화나 테스트 자동화를 도입할 때, 생성과 검증을 같은 에이전트에게 맡기지 말 것. 검증 단계는 반드시 다른 레이어, 가능하다면 외부 표면에 기록이 남는 구조로 설계해야 한다.
세 번째: 도구가 연결되기 전에 에이전트가 말하게 두지 마라
세 번째는 가장 실전적인 함정이다. Claude Agent SDK를 Railway에 배포하면서 마주친 세 가지 문제 중 두 번째가 핵심이다. stdio MCP 서버가 연결 완료를 기다리지 않고 에이전트가 첫 번째 턴을 시작한다. 도구 목록이 비어 있는 상태에서 에이전트는 무엇을 하는가? 도구 호출을 텍스트로 '연기'하고, 그럴듯한 숫자를 스스로 만들어낸다.
이게 무서운 이유는 로그가 정상처럼 보인다는 것이다. 에이전트는 자신 있게 응답했고, 에러는 없었다. 문제는 숫자가 완전히 조작됐다는 것뿐. CPU가 여유로운 로컬 환경에서는 재현이 안 되고, 컨테이너 환경에서만 나타나는 레이스 컨디션이다. 수치를 다루는 에이전트에게 이건 치명적이다.
수정은 alwaysLoad: true 한 줄이지만, 원칙은 그보다 넓다. 에이전트가 발화하기 전에 의존하는 모든 도구가 실제로 연결된 상태인지 확인하는 것을 배포 체크리스트에 강제해야 한다. 첫 번째 함정으로 언급된 bypassPermissions 문제도 같은 맥락이다. 루트 컨테이너에서 실행되면 에이전트는 코드 1로 조용히 죽고, stderr를 별도로 캡처하지 않으면 이유조차 알 수 없다. '로그가 거짓말을 한다'는 교훈이 세 함정을 관통한다.
테크 리드가 지금 당장 팀에 심어야 할 것
세 사례를 종합하면 에이전트 배포 전 강제해야 할 체크포인트가 명확해진다.
1. 거버넌스를 코드로 강제하라. 오너, 스코프, 에스컬레이션 경로, 킬스위치. 문서가 아니라 실행 차단 조건으로. AgentGuard가 보여주는 Pre-Flight Check 구조는 팀 자체 구현의 참고 기준이 될 수 있다.
2. 검증 레이어를 에이전트 외부에 두어라. 에이전트가 생성한 것을 에이전트가 검증하는 구조는 장식이다. 제3자가 재실행 가능하고, 저자가 통제할 수 없는 표면에 기록이 남아야 한다.
3. 도구 연결 상태를 확인한 후 에이전트를 시작하라. 특히 MCP나 외부 서비스에 의존하는 에이전트라면, 첫 번째 턴 이전에 모든 도구가 connected 상태인지 검사하는 로직을 배포 파이프라인에 포함시켜야 한다.
맥킨지가 AI 에이전트 시대의 생존 전략으로 거버넌스와 신뢰성을 반복해서 강조하는 이유가 여기 있다. 에이전트의 속도는 이미 충분히 빠르다. 이제 병목은 '얼마나 빨리 배포하는가'가 아니라 '배포한 것을 얼마나 신뢰할 수 있는가'다. 그리고 그 신뢰는 에이전트가 스스로 만들 수 없다. 팀이 구조로 강제해야 한다.
결국 에이전트 신뢰성은 모델 선택의 문제가 아니다. 거버넌스 레이어를 얼마나 일찍, 얼마나 강제적으로 설계에 포함시켰는가의 문제다. 프롬프트 한 줄로 해결하려는 팀과, 실행 전 차단 조건을 코드로 심는 팀의 차이는 첫 번째 조용한 실패가 발생하는 순간 드러난다.