byteforce

CPN 한국어 자습서 · Claude Certified Developer — Foundations Prep

5-9 · 모듈 마무리

핵심 요약과 모듈 마무리

Key takeaways & module complete

모듈 5에서는 돌아가는 코드를 다음 팀이 다시 쓸 수 있는 자산으로 묶고, 관리자가 검증할 수 있게 기여하고, 알맞은 플랫폼에 배포하며 버전을 고정하고, 부품 사이의 이음새를 신뢰 경계로 지키는 방법을 살펴봤습니다. 이 마무리 장에서는 다섯 가지 핵심을 다시 짚고, 모듈에서 나온 용어를 정리한 뒤, 배운 내용을 스스로 점검합니다.

이 장에서 정리하는 것Module wrap-up

약 8분

빌드가 살아 있을 때 자산으로 묶는 원칙

관리자가 검증할 수 있는 기여를 준비하는 기준

별칭 대신 버전을 고정하고, 배치를 결정하는 지표를 재는 법

부품 사이 이음새를 신뢰 경계로 지키는 원칙

이 모듈의 핵심 용어 다섯 개 정리

개발자 경로에서 모듈 5의 자리와 마무리 점검

이 모듈의 다섯 가지 핵심

Key takeaways

모듈 5는 돌아가는 코드를 배포할 수 있는 자산으로 바꾸는 과정을 다뤘습니다. 아래 다섯 가지는 그 과정에서 반복해서 나온 판단들입니다. 하나씩 다시 짚어 보겠습니다.

빌드가 살아 있을 때 자산으로 묶습니다. 액셀러레이터돌아가는 솔루션을, 다음 프로젝트가 처음부터 다시 만들지 않고 설정만 바꿔 쓰도록 묶어 둔 것.는 재사용할 로직은 그대로 두고, 고객마다 달라지는 부분은 문서화된 설정값으로 빼내며, 평가(eval)와 감사 로그를 자산과 함께 묶습니다. 이렇게 묶어 두면 다음 팀이 다시 만드는 대신 설정만 바꿔 쓰는 자산이 됩니다. 어느 부분이 고객마다 달라지는지는, 그것을 알던 사람이 떠난 뒤에 다시 알아내려면 비용이 가장 많이 듭니다.
관리자는 검증할 수 있는 것만 받아들입니다. 자산을 공용 인프라로 옮기려면 먼저 자산의 형태에 맞는 창구를 고르고, 검토 기준을 통과해야 합니다 — 초점이 분명한 코드, 실행되는 예시, 동작을 증명하는 테스트, 전제 조건을 적은 설명, 그리고 기술 검토에 앞서 확인해 둔 기여 권리입니다. 검토자가 확인할 수 없는 기여는 대기열 맨 뒤로 밀립니다.
배포하는 버전을 고정합니다. 배포 플랫폼은 고객의 클라우드와 규정 준수 상황에 맞춰 고르고, 계속 움직이는 별칭(alias) 대신 특정 모델 버전을 고정(pin)하며, 이전 버전도 함께 남겨 둡니다. 별칭은 책의 "최신판"을 달라는 것과 비슷해서 편리하지만 내용이 바뀔 수 있습니다. 버전을 고정하면 정해진 판을 지정하는 셈이라, 상위 모델이 바뀌어도 되돌릴 길 없이 하루아침에 반영되는 대신, 준비된 상태에서 스스로 받아들이게 됩니다.
배치를 결정하는 지표를 잽니다. 플랫폼 선택은 지연 시간·규정 준수·비용을 실제로 측정했을 때만 근거를 갖습니다 — 지연은 고객이 있는 지역에서, 규정 준수는 고객이 이미 가진 인증 기준으로, 비용은 토큰 단가만이 아니라 호출당 총비용으로 잽니다. 규제가 있는 고객에게 규정 준수는 대개 통과 아니면 탈락입니다. 범위를 정하는 단계에서 규정 준수를 제약으로 먼저 꺼내 두면, 나중에 계약 검토에서 빌드 전체가 반려되는 상황을 줄일 수 있습니다.
모든 이음새를 경계로 표시합니다. 여러 부품으로 이뤄진 애플리케이션은 가장 권한이 큰 이음새(seam)만큼만 안전합니다. 각 부품에는 그 역할에 필요한 최소한의 접근 권한만 주고, 데이터가 건너가는 지점은 모두 신뢰 경계데이터나 지시가 한 실행 환경에서 다른 환경으로 건너가는 이음새. 받는 쪽은 건너온 내용을 지시가 아니라 데이터로 다룬다.로 다룹니다. 가져온 콘텐츠는 지시가 아니라 데이터로 취급하고요. 부품 경계에서의 신뢰는 명시적으로 세워야 하며, 데이터를 보낸 부품에서 자동으로 넘어오지 않습니다. 이음새를 안전하게 만들 수 없다면, 그대로 내보내기보다 사람 담당자에게 넘깁니다.

한눈에

다섯 가지는 순서대로 묶기 → 기여 → 배포·고정 → 근거로 방어 → 경계 지키기로 이어집니다. 코드가 돌아가는 것에서 끝나지 않고, 다른 팀과 규제 있는 고객이 믿고 쓸 수 있는 상태까지 데려가는 과정입니다.

주의 · WATCH OUT

규정 준수는 규제 있는 고객에게 대개 통과 아니면 탈락입니다. 범위를 정하는 단계에서 미리 제약으로 꺼내 두면, 계약 검토에서 빌드 전체가 반려되는 상황을 줄일 수 있습니다.
기여 권리(라이선스)는 기술 검토에 앞서 확인해 둡니다. 검토자가 확인할 수 없는 기여는 대기열 맨 뒤로 밀립니다.
별칭(alias)에 그대로 기대면 상위 모델 변경이 예고 없이 프로덕션에 들어올 수 있습니다. 버전을 고정하고 이전 버전을 남겨 두면 되돌릴 길이 생깁니다.
이음새를 안전하게 만들 수 없다면, 그대로 배포하기보다 사람 담당자에게 넘기는 편이 안전합니다.

코드가 돌아가기 시작한 뒤에

The throughline: from a working build to a deployable asset

이 다섯 가지는 따로 떨어진 항목이 아니라 하나의 흐름입니다. 돌아가는 빌드를 재사용 자산으로 묶고, 그것을 다시 기여하고, 알맞은 플랫폼에 배포하며 버전을 고정하고, 그 선택을 측정한 값으로 방어하고, 부품들을 연결하되 경계가 무너지지 않게 지키는 것 — 여기까지가 이 모듈이 다룬 '빌드에서 배포까지'의 한 줄기입니다.

개발자 경로의 앞 모듈에서 프로덕션 코드를 쓰는 법을 익혔다면, 이 모듈은 그 코드를 규제가 있는 고객도 감사할 수 있고 다른 팀이 다시 쓸 수 있는 자산으로 내보내는 법을 다뤘습니다.

핵심

코드가 돌아가기 시작하는 지점 — 많은 경우 거기서 일이 끝났다고 느끼지만, 이 모듈의 일은 바로 그 지점에서 시작합니다. 배포·감사·재사용까지가 아직 남은 몫이기 때문입니다.

이 모듈의 핵심 용어

Key terms from this module

모듈에서 자주 나온 다섯 개 용어를 한곳에 모았습니다. 앞의 핵심 정리와 아래 점검을 읽을 때 여기로 돌아와 확인하면 됩니다.

KEY TERMS · 원문 알파벳 순

액셀러레이터 (accelerator): 돌아가는 솔루션을, 다음 프로젝트가 처음부터 다시 만들지 않고 설정만 바꿔 쓰도록 묶어 둔 것. 고객마다 달라지는 부분은 문서화된 설정값으로 드러내고, 전제 조건은 적어 두며, 새 맥락에서도 여전히 동작하는지 증명할 평가(eval)를 함께 묶는다.
기여 준비 상태 (contribution readiness): 관리자(maintainer)가 기여를 검증하는 데 필요한 것들 — 초점이 분명한 코드, 실행되는 예시, 동작을 증명하는 테스트, 환경 전제를 적은 설명, 그리고 그 코드를 기여할 수 있다는 확인된 권리.
배포 플랫폼 (deployment platform): Claude 작업이 실행되는 곳. 여섯 가지가 있다 — 자사 Claude API, AWS의 Claude Platform, Amazon Bedrock의 Claude, Amazon Bedrock의 Claude(레거시), Google Vertex AI, 그리고 서드파티 플랫폼. 같은 모델이라도 플랫폼에 따라 신원(identity)·데이터 저장 위치·지연·비용이 달라질 수 있다.
모델 별칭 대 고정 ID (model alias vs. pinned ID): opus나 sonnet 같은 별칭은 시간이 지나며 갱신되고 플랫폼마다 다를 수 있는 '권장 버전'으로 연결된다. 고정된 전체 모델 ID는 바뀌지 않는 스냅숏이다. 버전을 고정하면 상위 모델 변경이 조용한 프로덕션 변경으로 흘러드는 것을 막을 수 있다.
신뢰 경계 (trust boundary): 여러 부품으로 된 앱에서 데이터나 지시가 한 실행 환경에서 다른 환경으로 건너가는 이음새. 한 부품이 가져온 콘텐츠는 다음 부품에 도달할 때 신뢰할 수 없는 것으로 보고, 받는 부품은 그것을 지시가 아니라 데이터로 취급한다.

한 줄 정리

이 모듈의 다섯 가지는 묶기 · 기여 · 배포와 고정 · 근거로 방어 · 경계 지키기로 이어지는 하나의 흐름입니다.
기여는 검토자가 검증할 수 있을 때 받아들여지고, 배포는 버전을 고정했을 때 예고 없는 변경에서 벗어납니다.
여러 부품으로 된 앱에서는 데이터가 건너가는 모든 지점을 신뢰 경계로 다루고, 신뢰는 자동으로 넘어오지 않는다는 점을 기준으로 삼습니다.

모듈을 마치며

Module complete

모듈 5, 여기까지입니다. 돌아가는 빌드를 재사용 액셀러레이터로 묶고, 관리자가 검증할 수 있는 기여로 다듬고, 목적에 맞게 배포 플랫폼을 고르고 버전을 고정하고, 다부품 앱의 이음새마다 신뢰 경계를 세우는 데까지 왔습니다.

원문 코스에서 이 모듈은 아홉 개 지점의 점검을 거치도록 구성돼 있고, 이 마무리가 그 마지막 장입니다. 아래는 개발자 경로 전체의 모듈 지도입니다 — 이 마무리가 닫는 것은 그중 모듈 5입니다.

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 — 액셀러레이터 묶기, 검증 가능한 기여 준비, 배포 플랫폼 선택, 신뢰 경계 표시. 지금 이 장이 이 모듈의 마무리입니다.

PUBLIC REFERENCES · 이 모듈이 기댄 공개 자료 (시점에 따라 바뀔 수 있음)

코드	자료 (종류)	쓰임
S1	platform.claude.com — Amazon Bedrock의 Claude, Vertex AI의 Claude (제품 문서)	배포 플랫폼, 신원·데이터 모델, 데이터 저장 위치 라우팅, 지역·전역 엔드포인트.
S2	platform.claude.com — 모델 ID·버전 관리, 모델 지원 종료 (제품 문서)	고정 모델 ID, 별칭 해석, 수명 주기와 종료, 파트너별 일정.
S3	anthropic.com · Anthropic GitHub 조직(Cookbook) (제품·저장소)	기여 창구, 초점이 분명한 예시의 보금자리로서의 Cookbook, 기여 규약.
S4	Building with the Claude API (Skilljar) (코스 출처)	평가 데이터셋과 채점기, 배포 게이트로 쓰이는 평가 파이프라인.
S5	Claude Code 101 In Action (Skilljar) (코스 출처)	Claude Code 에이전트 작업과 다부품 워크플로에서의 MCP 서버 역할.

스스로 점검 — 다섯 가지 핵심

Checkpoint · Key takeaways

이 모듈의 다섯 가지 핵심과 용어를 다섯 문항으로 점검합니다. 정답을 먼저 떠올려 본 뒤 골라 보세요. 맞히면 설명이 나옵니다.

Q1빌드를 액셀러레이터로 잘 묶었다고 할 수 있는 경우는?

Q2관리자(maintainer)가 기여를 받아들이는 기준으로 맞는 설명은?

Q3움직이는 별칭(alias) 대신 특정 모델 버전을 고정(pin)하는 이유로 가장 알맞은 것은?

Q4배포 플랫폼 선택을 근거 있게 만들려면 무엇을 측정해야 할까요?

Q5여러 부품으로 된 앱에서 신뢰 경계를 다루는 원칙으로 맞는 것은?

다음 장

이 장으로 개발자 경로 모듈 5가 마무리됩니다. 새 레슨이 준비되는 대로 학습 홈에 올라옵니다. → 학습 홈으로