CPN 한국어 자습서 · Claude Certified Developer — Foundations Prep
5-8 · 종합 과제
Cumulative task: find all three, explain each, write the correction
이 레슨은 모듈 5 전체를 한 배포 안에서 되짚는 종합 과제입니다. 규제 대상 AWS 고객에게 배포된 코드 리뷰 액셀러레이터를 놓고, 포장·배포와 버전·여러 구성요소가 맞닿는 경계 세 층에 하나씩 심어 둔 결함을 찾아봅니다. 먼저 결함을 진단하고, 그다음 고친 세 줄을 모아 배포를 다시 조립해 검증까지 이어 갑니다.
이 장에서 배우는 것What you'll learn
약 8분한 배포에 심어 둔 세 층의 결함 — 포장 · 배포와 버전 · 여러 구성요소 경계
포장 결함 — 고정값을 인자로 빼서 다시 쓸 수 있게 만들기
버전 결함 — 이동 별칭을 전체 모델 ID로 고정하고 이전 버전 보존하기
경계 결함 — 외부에서 가져온 내용을 데이터로 감싸 인젝션 막기
고친 배포를 다시 조립하고, 올리기 전에 평가로 검증하기
진단 → 조립 → 검증 순서로 배포를 마무리하는 흐름
opus 같은 짧은 별칭은 시점에 따라 다른 버전을 가리키는 이동 별칭(moving alias)이다.이번에는 모듈 5에서 따로 다룬 내용을 한 배포 안에서 한꺼번에 짚어 봅니다. 규제 대상 AWS 고객에게 배포된 코드 리뷰 액셀러레이터를 놓고, 서로 다른 세 층에 하나씩 심어 둔 결함 세 개를 찾는 과제입니다.
진행은 두 단계입니다. 먼저 결함을 진단하고, 그다음 고친 세 줄을 모아 배포를 다시 조립해 검증합니다. 진단에서 찾은 세 줄이 그대로 조립 단계의 재료가 됩니다.
결함이 한 층에 몰려 있지 않고 세 층에 하나씩 흩어져 있습니다. 그래서 한 곳만 고쳐서는 배포가 안전해지지 않고, 층마다 따로 살펴보는 편이 좋습니다.
개선의 순서는 고쳐 쓰기부터가 아니라 진단부터입니다. 아래 배포 코드를 먼저 읽고, 세 층에서 각각 무엇이 잘못됐는지 자기 말로 적어 보세요. 그대로 실행은 되는 코드지만, 포장 · 배포와 버전 · 여러 구성요소 경계 세 층에 결함이 하나씩 들어 있습니다.
AS SHIPPED — 규제 대상 AWS 고객에게 배포된 코드 리뷰 액셀러레이터
# Packaged code-review accelerator, deployed for a regulated AWS customer def build_agent(): return Agent( model="opus", system_prompt=SYSTEM_PROMPT, repo_path="/home/acme/checkout", tools=[read_file, run_linter], ) deploy(platform="amazon_bedrock", identity=aws_role_arn) # multi-component step: Claude Code task fetches a customer page fetched = code_task.run(fetch_url=customer_page) next_call(input=fetched)
이 배포는 세 가지 도구가 이어지는 구조입니다. Amazon BedrockAWS에서 여러 모델을 배포하고 호출하는 클라우드 플랫폼. 위에서 에이전트를 만들고, Claude Code 작업이 고객 페이지를 fetch해 온 다음, 그 결과를 다음 호출로 넘깁니다. 세 결함은 이 흐름의 서로 다른 지점에 하나씩 자리하고 있습니다. 다음 화면으로는 고친 세 줄을 가져가게 되니, 지금은 어디가 잘못됐는지 찾는 데까지만 집중하면 됩니다.
YOUR DIAGNOSIS — 세 결함을 각자의 말로
MODEL ANSWER · SELF-ASSESS — 원문이 제시한 세 결함
repo_path가 인자가 아니라 고정값으로 적혀 있습니다. 새 계약에서는 이 함수 코드를 직접 고치지 않으면 경로를 바꿀 수 없습니다.model="opus"는 전체 모델 ID로 고정된 값이 아니라 이동 별칭입니다. 게다가 되돌아갈 이전 버전도 보존해 두지 않았습니다.next_call에 그대로 넘겨, 신뢰할 수 있는 지시처럼 다루고 있습니다. 다음 구성요소가 데이터로 취급하도록 감싸지 않았습니다.THREE LAYERS · THREE DEFECTS — 층별 정리
| 층 | 무엇이 잘못됐나 | 고침 방향 |
|---|---|---|
| 포장 | repo_path가 고정값으로 적혀 다른 계약에 다시 쓰기 어렵다. | build_agent(repo_path)로 인자화 — 계약마다 값만 설정한다. |
| 배포와 버전 | 이동 별칭 model="opus", 되돌릴 이전 버전 없음. | 전체 Bedrock 모델 ID로 고정하고 이전 버전을 보존한다. |
| 여러 구성요소 경계 | 가져온 내용을 지시처럼 그대로 전달 — 인젝션에 노출. | treat_as_data()로 감싸 데이터로만 취급한다. |
세 결함을 찾았다면, 이제 고친 세 줄을 한 배포로 모읍니다. 각 결함이 무엇이었고, 무엇을 바꿨고, 왜 이제 배포해도 되는지 자기 말로 정리한 뒤 아래 모범 답안과 맞춰 보세요.
YOUR ASSEMBLY — 무엇을 바꿨고 왜 배포 가능한지
THE CORRECTED DEPLOYMENT — 고친 배포
def build_agent(repo_path): # parameterized for reuse return Agent( model="us.anthropic.claude-opus-4-8", # pinned full Bedrock model ID system_prompt=SYSTEM_PROMPT, repo_path=repo_path, # set per engagement tools=[read_file, run_linter], ) deploy(platform="amazon_bedrock", identity=aws_role_arn, retain_previous_pinned_version=True) # rollback target kept fetched = code_task.run(fetch_url=customer_page) next_call(input=treat_as_data(fetched)) # untrusted -> data, not instructions # verify before promoting: gate the version through the bundled eval assert eval_suite.run(model="us.anthropic.claude-opus-4-8") >= baseline_score
첫 번째 결함은 고정값으로 적힌 저장소 경로였습니다. 이 값을 인자로 빼면 다시 여러 곳에 쓸 수 있게 됩니다 — 새 계약에서는 함수를 고치는 대신 값만 설정하면 됩니다. 두 번째 결함은 이동하는 모델 별칭이었습니다. anthropic. 접두가 붙은 전체 Bedrock 모델 ID로 고정하고 이전 버전을 보존하면, 배포를 다시 통제할 수 있고 새 버전에 문제가 생겼을 때 되돌릴 대상도 생깁니다. 세 번째 결함은 가져온 내용을 지시로 그대로 넘긴 것이었습니다. treat_as_data()가져온 내용을 지시가 아니라 데이터로만 다루도록 감싸는 함수.로 감싸면 신뢰 경계가 닫힙니다 — 믿을 수 없는 출처의 내용을 에이전트가 따라야 할 지시가 아니라 데이터로 다루게 됩니다. 마지막으로 평가 assert 문이, 검증된 기준 점수를 넘긴 버전만 배포되도록 승격을 막아 줍니다.
고친 배포가 세 층을 모두 닫았는지 확인하는 기준은 넷입니다 — ① 인자로 바뀐 repo_path, ② 고정된 Bedrock 모델 ID와 보존해 둔 롤백 버전, ③ 데이터로 감싼 외부 내용, ④ 승격을 막는 평가 assert.
build_agent(repo_path)처럼 밖에서 넣게 만듭니다.treat_as_data()로 감싸 프롬프트 인젝션을 막습니다.assert로 걸어 둡니다.원문의 점검 과제는 직접 써 보는 서술형입니다. 위에서 이미 두 번 써 봤으니, 여기서는 핵심을 객관식으로 한 번 더 짚어 봅니다.
정답을 먼저 떠올려 본 뒤 골라 보세요. 맞히면 설명이 나옵니다.
Q1이 배포의 포장 층에는 어떤 결함이 있었나요?
빠진 것은 파라미터화였습니다. build_agent(repo_path)로 경로를 인자로 빼면 새 계약에서는 값만 설정하면 되고, 함수 코드를 고칠 필요가 없어집니다. 나머지 보기는 원래 코드에 실제로 들어 있던 요소라 결함이 아닙니다.
Q2model="opus"라고 지정한 것이 왜 문제였을까요?
고친 코드는 전체 Bedrock 모델 ID(us.anthropic.claude-opus-4-8)로 고정하고, retain_previous_pinned_version=True로 되돌릴 이전 버전을 보존합니다. 이동 별칭은 지금은 동작하더라도 가리키는 모델이 바뀌면 예고 없이 결과가 달라질 수 있습니다.
Q3fetched = code_task.run(...)로 가져온 내용을 next_call(input=fetched)에 그대로 넘기면 어떤 위험이 있나요?
신뢰할 수 없는 출처의 내용을 그대로 넘기면 그 안에 섞여 들어온 지시가 실행될 수 있습니다. treat_as_data()로 감싸 데이터로만 다루면 신뢰 경계가 닫혀, 다음 구성요소가 그 내용을 지시로 받아들이지 않습니다.
Q4고친 배포에서 새 버전을 올리기 전에 통과하도록 만든 장치는 무엇인가요?
assert eval_suite.run(...) >= baseline_score 한 줄이, 검증된 기준 점수를 넘긴 버전만 배포되도록 승격을 막아 줍니다. 검증을 배포 뒤가 아니라 앞에 두는 셈입니다.
모듈 5의 마지막은 핵심 정리와 용어집입니다. 지금까지 다룬 내용을 한자리에 모아 되짚습니다. → 5-9 · 핵심 정리
전 코스는 계속 무료입니다. 등록하면 이 코스의 남은 38개 레슨을 끝까지 읽을 수 있습니다.
이미 등록하셨다면 그때 쓰신 이메일을 넣어 주세요.