이 모듈을 마치면 할 수 있는 것

앞의 두 모듈에서는 도구 사용 루프를 연결하고, 계획과 기억을 갖춘 에이전트를 만들고, 훅과 MCP 서버로 Claude Code 워크플로를 감쌌습니다. 이렇게 만든 에이전트는 실제로 잘 돌아갑니다. 그런데 프로덕션은 조금 다른 질문을 던집니다.

시험해 본 적 없는 예외 입력이 들어올 때, 트래픽이 몰려 요청 한도에 걸릴 때, 가져온 웹페이지 안에 에이전트를 겨냥한 지시가 숨어 있을 때 — 시스템은 그대로 버틸까요, 아니면 아무 표시 없이 조용히 실패할까요? 이 모듈은 "내 컴퓨터에서는 잘 되던데"라는 상태를, 리뷰 자리에서 근거를 들어 방어할 수 있는 시스템으로 바꾸는 과정을 다룹니다.

이 모듈은 이미 돌아가는 무언가를 만들어 봤고, 이제 더 많은 사람이 그것에 의존하기 시작한 개발자를 위한 것입니다. 앞 두 모듈에서 만든 도구 사용 루프·에이전트·Claude Code 워크플로가 이미 동작한다고 전제하고, 그 부분은 다시 다루지 않습니다. 여기서 살펴보는 것은, 개발 환경에서 돌아가던 기능이 프로덕션 트래픽 아래에서도 버티는지를 가르는 엔지니어링 결정들입니다.

이 모듈을 다 마치면 아래 다섯 가지를 직접 할 수 있게 됩니다. 뒤에 이어지는 각 장이 하나씩 맡아 자세히 다룹니다.

• 1이밸(eval) 세트 작성. 배포하기 전에 그 Claude 기능에서 '완료'가 무엇인지 정의하고, 과제에 맞는 채점 방식을 고르고, LLM이 대신 매기는 점수(LLM-as-judge)를 사람이 라벨링한 사례에 맞춰 보정해 결과를 근거로 방어할 수 있게 합니다.
• 2테스트·트레이싱 계층 구축. 단위·기능·통합·엔드투엔드 네 수준에서 리그레션(이전엔 되던 것이 다시 안 되는 것)을 잡아내는 층을 만듭니다.
• 3실패에 견디는 애플리케이션. 다시 시도하면 되는 오류와 그럴 수 없는 오류를 구분해, 프로덕션에서 생기는 실패에 견디도록 만듭니다.
• 4예산 안에서 시스템 유지. 여러 에이전트가 함께 움직이는 경우까지 포함해 시스템을 비용·지연·신뢰성 예산 안에 둡니다. 호출마다 비용과 지연을 측정하고, 정말 필요할 때만 병렬 에이전트를 씁니다.
• 5보안 리뷰를 통과하는 방어. 프롬프트 인젝션, 탈옥(jailbreak), 신뢰할 수 없는 입력, 권한을 좁힌 신원, 노출된 비밀값, 데이터 경계 문제로부터 통합을 방어해, 배포가 보안·규정 준수(컴플라이언스) 리뷰를 통과하도록 만듭니다.

이 다섯 가지는 서로 다른 주제처럼 보이지만, 사실 하나의 문제를 각각 다른 각도에서 다룹니다. 그 문제는 이렇습니다 — 개발 환경은 프로덕션이 드러내는 실패를 가려 줍니다.

같은 시스템인데도, 개발에서 겪는 조건과 프로덕션에서 만나는 조건은 다릅니다.

DEV → PROD — 같은 시스템, 다른 조건

여기서 실패는 대개 실행된 코드의 버그가 아닙니다. 아직 내리지 않은 결정인 경우가 많습니다. '완료'를 채점 가능한 기준으로 적어 두지 않았고, 다시 시도하면 되는 경우에 별도 경로를 마련하지 않았고, 예산을 측정하지 않았고, 어떤 동작까지 허용할지 경계를 정하지 않았습니다.

이 모듈이 하는 일은, 그 결정들을 실패가 실제로 나타나기 전에 미리 종이 위에서 내려 두고, 나머지 작업이 참고할 설계 문서에 정리해 두는 것입니다. 뒤에 이어지는 각 장 — 이밸, 테스트·트레이싱, 실패 경로, 비용 예산, 보안 경계 — 은 개발과 프로덕션 사이의 이 간극이 조용한 실패로 이어지는 통로를 하나씩 막습니다.