CPN 한국어 자습서 · Claude Certified Developer — Foundations Prep
4-8 · 모듈 4 마무리
Key Takeaways & Module Complete
모듈 4에서는 평가, 테스트와 추적, 실패 처리, 비용과 오케스트레이션, 보안까지 — 프로덕션에서 시스템이 버티게 하는 다섯 층을 다뤘습니다. 이 마무리에서는 그 다섯 가지를 한 번에 다시 짚고, 모듈에서 나온 용어 아홉 개를 정리한 뒤, 짧은 복습 문제로 스스로 점검합니다.
이 마무리에서 다시 짚는 것What this recap covers
핵심 5가지핵심 다섯 가지 — 평가 · 테스트와 추적 · 실패 처리 · 비용 · 보안
채점 방식을 출력 종류에 맞춰 고르는 원칙
겉으로 드러나지 않는 실패가 통합 지점에 숨는 이유
재시도 가능 오류와 종료 오류를 나누는 기준
가져온 콘텐츠를 데이터로 다루는 보안 경계
이 모듈의 용어 아홉 개와 짧은 복습 문제
이 모듈은 다섯 개의 층을 다뤘습니다. 각 층은 개발 단계에서는 잘 보이지 않던 문제 하나를, 프로덕션에서 터지기 전에 미리 막아 줍니다. 다섯 가지를 한 번에 다시 짚어 보겠습니다.
만들기 전에 기준부터 정합니다
평가(eval)는 '다 됐다'는 느낌을, 정해 둔 사례들에 대한 점수로 바꿔 줍니다. 채점 방식은 출력의 종류에 맞춰 고릅니다. 정답이 하나로 정해진 경우에는 정확히 일치하는지 보고, 구조화된 출력은 코드로 검사하고, 정답을 딱 정하기 어려운 열린 품질은 심판 모델(LLM-as-judge)에게 맡깁니다. 다만 심판 모델은 사람이 직접 라벨을 붙인 사례와 얼마나 맞는지 먼저 맞춰 본 뒤에 믿습니다.
평가를 먼저 쓰는 이유는, 기대 동작을 적어 보는 과정에서 '성공이 무엇인지'를 설계를 아직 바꿀 수 있을 때 확정하게 되기 때문입니다.
실패의 종류에 맞는 테스트를 고르고, 추적으로 위치를 찾습니다
단위·기능·통합·엔드투엔드 테스트는 저마다 다른 종류의 고장을 잡아냅니다. 그리고 겉으로 드러나지 않는 실패는 대부분, 각자는 멀쩡히 통과하는 두 컴포넌트가 값을 주고받는 통합 지점에 숨어 있습니다. 추적(trace)을 남겨 두면 어느 단계에서 잘못된 결과가 나왔는지 바로 보이기 때문에, 하루가 걸리던 원인 찾기가 짧은 수정으로 줄어듭니다.
가져오기(retrieval) 방식을 고를 때도 같은 판단을 씁니다. 사실 하나를 찾는 조회라면 한 번만 가져오고, 정말 여러 단계를 거쳐야 하는 질문이라면 여러 번 검색을 반복하는 에이전트 검색을 씁니다.
실패를 종류별로 나눈 다음, 하나씩 처리합니다
어떤 실패든 가장 먼저 물어볼 것은, 조금 기다렸다가 다시 시도하면 풀릴 문제인가입니다. 다시 시도해 볼 만한 실패에는 지수 백오프를 씁니다. 간격을 점점 늘려 가되 상한과 재시도 횟수를 정해 두고, 곧바로 다시 부르는 반복은 피합니다. 그런 즉시 반복은 문제를 더 키우기만 하기 때문입니다.
도구 호출이 실패했을 때는 오류 표시를 붙여 모델에게 그대로 돌려줍니다. 빈 결과로 감추면 모델이 그걸 데이터로 오해하기 때문입니다. 그리고 재시도로도 고쳐지지 않는 실패에는, 미리 정해 둔 대체 동작(fallback)이 하나씩 필요합니다. 이게 없으면 처리되지 않은 예외가 그대로 기본 동작이 되고, 잘못된 응답 하나가 전체 흐름을 멈추게 만드는 상황으로 이어집니다.
호출마다 비용과 지연을 재고, 작업이 정말 갈라질 때만 나눕니다
재 보지 않은 것은 예산으로 잡을 수 없습니다. 그래서 호출 하나하나에 토큰 비용·지연 시간·오류율을 재는 장치를 걸어 둡니다. 그런 다음 청구서만 보고 짐작하는 대신, 고칠 지점 하나를 정해 그 값을 조정합니다.
오케스트레이터-워커 패턴은 토큰 비용을 서브에이전트 수만큼 늘립니다. Anthropic이 공개한 사례에서는 약 15배였습니다. 이 비용이 아깝지 않으려면, 작업이 서로 독립적으로 병렬 처리되는 부분들로 진짜 갈라져야 합니다. 단계가 촘촘히 얽혀 있어 에이전트 하나가 훨씬 적은 비용으로 처리할 수 있는 작업에는 맞지 않습니다.
가져온 콘텐츠는 데이터로 다루고, 경계는 훅으로 강제합니다
모델은 컨텍스트에 들어온 모든 것을 한 덩어리로 읽습니다. 신뢰할 수 있는 지시와 믿을 수 없는 데이터 사이에 원래부터 그어진 선은 없습니다. 그래서 가져온 콘텐츠 안에 지시가 숨어 있으면, 그것이 에이전트의 동작에 영향을 줄 수 있습니다. 내 서비스 사용자만 믿는다고 해서 막아지지는 않습니다. 주입은 사용자가 아니라 에이전트가 읽어 들이는 콘텐츠를 타고 들어오기 때문입니다.
대응은 이렇게 정리됩니다. 믿을 수 없는 입력은 데이터로만 취급하고, 에이전트의 권한은 꼭 필요한 만큼(최소 권한)으로 좁히고, 비밀 키는 소스에 함께 올라가는 설정에 두지 않고, 도구가 실행되기 전에 차단하고 기록하는 훅으로 행동의 경계를 강제합니다. 이렇게 만든 경계라야 규제 심사에서 통제하고 들여다볼 수 있습니다.
다섯 가지는 결국 한 방향을 가리킵니다. 개발 환경에서 '잘 되는 것처럼' 보이던 기능이, 프로덕션의 진짜 입력과 트래픽 앞에서 어디서 어떻게 어긋나는지 미리 찾아 두는 일입니다.
모듈에서 나온 핵심 용어 아홉 개입니다. 각 용어를 눌러 정의를 펼쳐 보세요. 원문의 알파벳 순서를 그대로 따랐습니다.
고정된 컨텍스트를 한 번에 가져오는 대신, 모델이 스스로 질의를 던지고 결과를 읽어 가며 여러 차례에 걸쳐 검색을 다듬어 가는 방식입니다. 여러 단계를 거쳐야 하는 질문이나 자주 바뀌는 자료를 다룰 수 있는 대신, 토큰과 지연 비용이 더 듭니다. 그 대신 따로 관리하는 색인이 없으니, 색인이 오래돼 낡거나 색인 인프라를 유지하는 부담은 피할 수 있습니다.
입력 사례, 기대 동작, 채점 기준을 묶어 — 어떤 기능이 배포 전에 반드시 해내야 할 일을 정의한 것입니다. 평가를 돌리면 따로 떼어 둔 사례 묶음(holdout set)에 대한 점수가 나오고, 그러면 '다 됐다'가 판단하는 사람의 감이 아니라, 프롬프트·도구·모델을 바꿔 가며 추적할 수 있는 숫자가 됩니다.
다시 시도할 때마다 기다리는 간격을 점점 늘리는 재시도 방식입니다. 상한과 정해진 시도 횟수를 두고, 대개 무작위 흔들림(jitter)을 섞습니다. 즉시 다시 시도해서 속도 제한을 더 깊게 만드는 상황을 막아 주고, 응답이 다시 시도까지 기다릴 시간(retry-after)을 알려 주면 그 값을 존중합니다.
Claude Code 에이전트가 동작하는 흐름의 정해진 지점에서 — 예를 들어 도구를 부르기 직전(PreToolUse) — 실행되는 검사입니다. 어떤 동작을 막고 그 사실을 기록할 수 있습니다. 프롬프트에 적어 둔 지시와 달리, 훅은 보호하려는 동작보다 먼저 실행되는 강제된 통제입니다. 규제 심사가 눈여겨보는 것이 바로 이 차이입니다.
두 컴포넌트가 값을 주고받는 지점을 — 예를 들어 가져오기 결과가 모델 호출로 넘어가는 자리를 — 실제로 실행해 보는 테스트입니다. 단위 테스트나 기능 테스트가 놓치는, 겉으로 드러나지 않는 실패를 잡아냅니다. 각 컴포넌트는 혼자서는 통과하는데, 둘 사이의 연결이 잘못돼 있을 수 있기 때문입니다.
코드 규칙으로는 검사할 수 없는 열린 형식의 출력을, 채점 기준(rubric)을 담은 두 번째 모델 호출로 점수 매기는 방식입니다. 점수와 그 근거를 함께 돌려줍니다. 다만 사람이 라벨을 붙인 사례와 얼마나 일치하는지 맞춰 보고 일치도를 확인한 뒤에야 믿을 수 있습니다.
이끄는 에이전트 하나가 작업을 계획하고, 각자 자기 컨텍스트를 가진 서브에이전트들을 병렬로 띄운 뒤, 그 결과를 모아 정리하는 다중 에이전트 구조입니다. 독립적인 부분들로 갈라지는 넓은 작업에 도움이 되지만, Anthropic이 공개한 사례에서는 한 번의 대화보다 토큰 비용이 약 15배였습니다.
에이전트가 가져오는 콘텐츠 안에 숨겨 둔 지시가 명령처럼 실행되는 공격입니다. 모델은 컨텍스트 전체를 하나의 흐름으로 읽고, 신뢰할 수 있는 지시와 믿을 수 없는 데이터 사이에 원래부터 그어진 경계가 없기 때문에 이런 일이 생깁니다. 대응은 가져온 콘텐츠를 데이터로 취급하고, 행동의 경계를 프롬프트 바깥에서 강제하는 것입니다.
프로덕션 실패를 만났을 때 가장 먼저 나누는 기준입니다. 재시도 가능 오류는 — 속도 제한이나 과부하처럼 — 나중에 다시 하면 성공할 가능성이 있어 백오프를 겁니다. 종료 오류는 — 잘못된 요청처럼 — 다시 해도 똑같이 실패하므로, 재시도 예산을 낭비하지 말고 빨리 실패시키는 편이 낫습니다.
핵심 다섯 가지를 문제로 다시 짚어 봅니다. 정답을 먼저 떠올려 본 뒤 골라 보세요. 맞히면 설명이 나옵니다.
정해진 점수는 없습니다. 다섯 문제를 풀며 헷갈리는 곳이 있으면, 위 정리와 용어 사전에서 그 부분을 다시 보고 오면 됩니다.
Q1이 모듈에서는 평가(eval)를 언제 작성하라고 했나요?
평가를 먼저 쓰는 이유가 여기 있습니다. 기대 동작을 적어 보는 과정에서 '성공이 무엇인지'를, 설계를 아직 바꿀 수 있을 때 확정하게 됩니다. 기능을 다 만든 뒤에 쓰면 이미 굳어진 구현에 기준을 맞추기 쉽습니다.
Q2겉으로 드러나지 않는 실패가 가장 자주 숨는 곳은 어디였나요?
각자는 멀쩡히 통과하는 두 컴포넌트가 값을 주고받는 통합 지점 — 여기에 겉으로 드러나지 않는 실패가 대부분 숨어 있습니다. 그래서 그 연결부를 실제로 실행해 보는 통합 테스트가 필요하고, 추적을 남겨 두면 어느 단계에서 깨졌는지 바로 찾을 수 있습니다.
Q3재시도로도 고칠 수 없는 실패에는 무엇이 필요하다고 했나요?
재시도로 고쳐지지 않는 실패에는 미리 정해 둔 대체 동작이 하나씩 필요합니다. 이게 없으면 처리되지 않은 예외가 기본 동작이 되고, 잘못된 응답 하나가 전체 흐름을 멈추게 만들 수 있습니다. 즉시 반복은 문제를 더 키우고, 빈 결과로 감추면 모델이 그걸 데이터로 오해합니다.
Q4오케스트레이터-워커 패턴을 쓸 만한 작업은 어떤 경우였나요?
이 패턴은 서브에이전트 수만큼 토큰 비용이 불어납니다. Anthropic이 공개한 사례에서는 한 번의 대화 대비 약 15배였습니다. 그 비용이 아깝지 않은 경우는, 작업이 독립적으로 병렬 처리되는 부분들로 진짜 갈라질 때입니다. 단계가 촘촘히 얽힌 작업은 에이전트 하나가 훨씬 적은 비용으로 처리합니다.
Q5가져온(fetched) 콘텐츠에 숨은 지시를 막는 접근으로 이 모듈이 제시한 것은?
모델은 컨텍스트 전체를 한 흐름으로 읽고, 신뢰할 지시와 믿을 수 없는 데이터 사이에 원래부터 그어진 선이 없습니다. 그래서 가져온 콘텐츠는 데이터로 취급하고, 도구가 실행되기 전에 차단·기록하는 훅으로 경계를 강제합니다. 내 사용자만 믿는다고 막아지지 않는 이유는, 주입이 에이전트가 읽는 콘텐츠를 타고 들어오기 때문입니다.
여기까지 왔다면, Claude로 만든 기능이 프로덕션 트래픽에서도 버티는지 스스로 증명할 수 있는 다섯 층을 갖춘 셈입니다.
이 다섯 층은 개발할 때는 잘 드러나지 않다가 프로덕션에서야 나타나는 문제를, 각각 한 종류씩 미리 걸러 냅니다.
DEVELOPER PATH — 코스 다섯 모듈
| 모듈 | 다루는 내용 |
|---|---|
| M1 | MSO Foundations — 토큰, 컨텍스트 윈도우, 샘플링, 모델 등급, 프롬프팅 방식, 그리고 API 전송 구조. |
| M2 | Production-Grade Prompting, Agents & Tool-use — 프로덕션에 낼 수 있는 프롬프트, 도구 사용 루프, 스트리밍, 컨텍스트·메모리 관리, 체크포인트를 둔 에이전트 루프. |
| M3 | Claude Code, MCP & Integration — 권한 모드, 오래 유지되는 프로젝트 컨텍스트, 플러그인 패키징, 자격 증명을 흘리지 않는 MCP 연동. |
| M4 | Production Engineering, Evals, and Security — 프로덕션 트래픽에서 시스템이 버티고 보안 심사를 통과하는지 확인합니다. ← 이번 모듈 |
| M5 | Accelerators and IP Contribution — 가속기 패키징, 검증 가능한 기여 준비, 배포 플랫폼 선택, 신뢰 경계 표시. 다음 모듈 |
다음 모듈은 지금까지 만들 수 있게 된 프로덕션급 시스템을, 다시 쓸 수 있는 가속기와 외부에 기여하는 자산으로 바꾸는 법을 다룹니다. 완성된 결과물을 매개변수를 받는 템플릿, MCP 서버, 또는 다른 환경으로 옮겨 쓸 수 있는 평가 묶음으로 패키징하고, 유지보수자가 받아 주는 경로로 그것을 되돌려 기여하는 방법을 배웁니다. 그런 다음 그 결과물이 어디에서 실행될지를 정합니다 — 자체 API, Amazon Bedrock, Google Vertex AI 가운데 고르고, 버전을 고정하고, 모델이 바뀌거나 데이터 위치(residency) 심사가 들어와도 프로덕션이 깨지지 않도록 지킵니다.
모듈 5는 지금까지 만든 시스템을 다시 쓸 수 있는 가속기와 기여 자산으로 바꾸고, 어느 배포 플랫폼에서 실행할지 정하는 법으로 이어집니다. → 모듈 5 · 첫 레슨으로
전 코스는 계속 무료입니다. 등록하면 이 코스의 남은 38개 레슨을 끝까지 읽을 수 있습니다.
이미 등록하셨다면 그때 쓰신 이메일을 넣어 주세요.