본문으로 건너뛰기
Koding
Claude Certified Architect – Foundations (CCA-F) 자격시험 교재
무료

Claude Certified Architect – Foundations (CCA-F) 자격시험 교재

한국 SI·컨설팅 실무자와 AI 엔지니어를 위한 CCA-F 합격 교재예요. 원문 61회 연재 원고를 내용 손실 없이 32개 장으로 재구성했어요. 각 세션의 이론·연습문제·해설은 한 장에 묶어 학습 흐름이 끊기지 않게 했고, 프로젝트와 모의고사는 문제편과 해설편을 분리해 실전처럼 풀 수 있게 했어요.

클로드claudeanthropicCCACCAF

4.제3장. 세션 1: Claude 기초와 모델 패밀리 (이론·연습문제·해설)

출제 도메인: 전 도메인 공통 기초 · 작성자: 김재우 (jaewoo@claudcode.to)


① 세션1: Claude 기초와 모델 패밀리(컨텍스트 윈도우·모델 ID·비용 최적화)

목차

이전 챕터 되돌아보기

이전 챕터에서는 Anthropic Console・API・Claude Code CLI・MCP SDK 네 가지 학습 환경을 갖췄습니다. 이번 챕터에서는 CCA-F 시험의 전제 지식이 되는 Claude라는 제품의 전체 그림과, Opus / Sonnet / Haiku 세 가지 모델 패밀리의 특성을 배웁니다.

주제 개요

Claude는 Anthropic 사가 개발하는 대규모 언어 모델(LLM)입니다. '정직하고・무해하며・도움이 되는(Honest, Harmless, Helpful)'이라는 3원칙 아래 설계되어 있으며, 특히 Constitutional AI라는 독자적 기법으로 안전성을 높이고 있습니다.

Claude를 이해할 때 가장 중요한 관점이 '모델 패밀리를 골라 쓰는 것'입니다. 같은 요리를 만들더라도 매일 부치는 계란말이에 셰프 나이프까지 꺼낼 필요는 없고 과일을 자를 때는 페티 나이프가 어울리듯, 태스크의 규모・복잡성・속도・비용에 맞춰 최적의 모델을 고르는 판단이 CCA-F에서 자주 출제됩니다.

습득 포인트

  • Anthropic 사의 미션과 Claude의 설계 사상(Constitutional AI, 3H)을 설명할 수 있다
  • Claude 모델 패밀리(Opus / Sonnet / Haiku)의 특성・비용・레이턴시를 암기하고 있다
  • 사용 사례에 따른 적절한 모델의 선정 기준을 서술할 수 있다
  • 모델 ID의 명명 규칙과 버저닝을 이해하고 있다
  • Claude의 컨텍스트 윈도우 크기와 활용 감각을 파악하고 있다
  • Claude의 멀티모달 기능(이미지 입력)의 개요를 이해하고 있다

1. Anthropic 사와 Claude의 설계 사상

1.1 Anthropic의 미션

Anthropic은 AI 안전성 연구를 핵심에 둔 기업으로, 미션은 '인류에게 장기적으로 유익한 AI를 만드는' 것입니다.

사용법과 유의점

Anthropic의 미션, Constitutional AI, Responsible Scaling Policy(RSP)와 같은 이념・내부 기법은 CCA-F의 출제 범위 밖입니다(공식 가이드의 Out-of-Scope에 해당). 시험 대책으로 암기할 필요는 없으며, Claude의 설계 사상을 이해하기 위한 배경 지식으로 간결하게 짚어두면 충분합니다.

1.2 Constitutional AI(CAI)

Claude는 Constitutional AI라는 기법으로 훈련됩니다. 이는 '사전에 정의한 원칙(헌법)'에 비추어, AI 자신이 자기 출력을 비평・수정하는 구조입니다.

비유하자면 경찰에게 단속당한 뒤에야 운전 습관을 고치는 게 아니라, 교통 규칙을 스스로 익혀서 알아서 안전 운전하는 자율적인 운전자에 가깝습니다.

1.3 3H 원칙(Honest, Harmless, Helpful)

원칙의미설계 반영 예시
Honest거짓말을 하지 않는다・모르는 것은 모른다고 말한다할루시네이션 억제・출처 명시
Harmless유해한 정보・차별적인 출력을 피한다위험물 제조 절차・폭력적 내용의 생성을 거부
Helpful도움이 된다단순히 '답변할 수 없습니다'로 끝내지 않고 대안을 제시

사용법과 유의점

  • 'Harmless'와 'Helpful'은 때로 트레이드오프가 됩니다. 예: 의료 조언을 '위험하니까 거부한다'는 것은 Harmless지만 Helpful은 아닙니다
  • Claude는 '합리적인 범위에서 Helpful'을 선택하도록 훈련되어 있습니다

2. Claude 모델 패밀리

Claude에는 Opus / Sonnet / Haiku 세 계통이 있습니다. 이는 음악 용어에서 유래했으며, 각각 규모감을 나타냅니다(서사시 / 14행시 / 17음의 짧은 시).

2.1 모델 패밀리의 전체 그림

모델위치속도비용강점 영역
Opus최고 성능・플래그십느림높음복잡한 추론・코딩・에이전트
Sonnet성능과 비용의 균형형중간중간일반적인 애플리케이션・대량 처리
Haiku경량・고속・저비용빠름저렴분류・추출・챗・대량 배치

쉽게 말하면 Opus는 베테랑 변호사(고단하지만 난제를 해결), Sonnet은 중견 컨설턴트(균형형), Haiku는 신입 어시스턴트(신속하게 대량 태스크를 처리)에 해당합니다.

2.2 모델 ID의 명명 규칙

API에서 모델을 지정할 때는 아래와 같은 ID를 사용합니다.

"claude-opus-4-8"             # Opus 4.8
"claude-sonnet-5"           # Sonnet 5
"claude-haiku-4-5-20251001"   # Haiku 4.5 의 특정 리비전

구조: claude-{family}-{major}-{minor}[-{revision}]

  • family: 모델 패밀리(opus / sonnet / haiku)
  • major.minor: 버전 번호(숫자가 클수록 최신)
  • revision: 날짜 기반 리비전(특정 버전을 고정하고 싶을 때 지정)

프로덕션 환경에서는 리비전이 붙은 ID를 사용하는 것이 권장됩니다. 에일리어스(claude-opus-4-8)는 향후 같은 패밀리의 신규 버전으로 다시 향할 가능성이 있어, 재현성에 영향을 줍니다.

2.3 모델 선정의 판단 기준

CCA-F 시험에서는 '이 시나리오에서는 어떤 모델을 선택해야 하는가'라는 문제가 자주 나옵니다. 판단 기준은 아래와 같습니다.

Bad(비용 최적화 문제): 모든 리퀘스트에 Opus를 사용한다

# bad.py
# 전체 리퀘스트에 Opus를 사용하면 비용이 막대함
model = "claude-opus-4-8"

for log in millions_of_logs:
    classify(log, model=model)  # 단순한 분류인데도 Opus

Good(비용 최적화): 태스크에 따라 모델을 구분해서 사용한다

# good.py
# 단순 분류는 Haiku, 복잡한 추론만 Opus
SIMPLE_MODEL = "claude-haiku-4-5-20251001"
COMPLEX_MODEL = "claude-opus-4-8"

for log in millions_of_logs:
    classify(log, model=SIMPLE_MODEL)

for incident in critical_incidents:
    root_cause_analysis(incident, model=COMPLEX_MODEL)

왜 Good인가: 단순한 태스크에 비싼 모델을 쓰면 비용이 선형으로 증대합니다. '요건을 충족하는 가장 저렴한 모델'을 선택하는 것이 에이전트 설계의 원칙입니다.

3. 컨텍스트 윈도우

Claude의 모델은 대규모 컨텍스트 윈도우를 가지고 있습니다. 컨텍스트 윈도우는 Claude가 '한 번에 시야에 넣을 수 있는 정보량'을 말하며, 토큰 수로 표시됩니다.

모델컨텍스트 윈도우(개략)체감 규모
Opus 4.x최대 1M 토큰중편 소설 5〜10권 분량
Sonnet 4.x최대 200K〜1M 토큰중편 소설 1〜5권 분량
Haiku 4.x최대 200K 토큰중편 소설 1권 분량

컨텍스트 윈도우는 '책상의 넓이'에 빗댈 수 있습니다. 책상이 넓을수록 많은 자료를 동시에 펼쳐놓고 작업할 수 있지만, 아무리 넓은 책상이라도 '어디에 무엇이 있는지'를 파악하는 능력(컨텍스트 관리)은 그것대로 따로 필요합니다.

컨텍스트 윈도우 ≠ 성능입니다. 클수록 많은 정보를 다룰 수 있지만, 무턱대고 채워 넣으면 컨텍스트 열화(context degradation)가 일어납니다. 상세는 세션11에서 다룹니다.

4. 멀티모달 기능

Claude는 텍스트에 더해 이미지 입력에 대응하고 있습니다(모델에 따라 다름).

# multimodal_example.py
import anthropic
import base64

client = anthropic.Anthropic()

with open("chart.png", "rb") as f:
    image_data = base64.standard_b64encode(f.read()).decode("utf-8")

message = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "image",
                    "source": {
                        "type": "base64",
                        "media_type": "image/png",
                        "data": image_data,
                    },
                },
                {"type": "text", "text": "이 그래프에서 읽어낼 수 있는 경향을 3가지 알려주세요."},
            ],
        }
    ],
)

print(message.content[0].text)

사용법과 유의점

  • 입력 가능한 이미지 포맷: PNG / JPEG / GIF / WebP
  • 이미지 1장당 크기・해상도에는 상한이 있음(공식 문서 참조)
  • 동영상・음성에는 직접 대응하지 않음(프레임을 추출해 이미지로 입력할 필요 있음)

5. Responsible Scaling Policy(RSP)

Anthropic은 Responsible Scaling Policy(RSP)라는, 모델의 능력 상승에 따라 보안 대책을 강화하는 정책을 공개하고 있습니다.

AI Safety Level(ASL)개요
ASL-1기존 기술과 동등한 리스크
ASL-2(현재의 Claude)한정적인 리스크. 기본적인 보안 대책
ASL-3중대한 리스크. 견고한 보안・배포 제어
ASL-4 이상파멸적 리스크. 극히 엄격한 제어

Anthropic은 2025년 5월 Claude Opus 4 배포부터 주력 모델에 ASL-3 기준을 적용하고 있으며, 이후의 Opus 4.5/4.6/4.8, Sonnet 5 등 주력 모델은 모두 ASL-3 기준으로 배포되고 있습니다(근거: Anthropic 공식 트랜스퍼런시 허브·RSP 발표). 다만 소형 모델인 Haiku 4.5는 ASL-2 기준으로 배포되었습니다. 즉 '현재의 Claude 주력 모델 = ASL-3」이 정확한 서술입니다.

사용법과 유의점

  • CCA-F에서는 「설계 판단의 안전성」을 묻는 문제에서 RSP가 등장할 수 있습니다
  • '운용상의 보안 책임은 이용자 측에도 있다'는 점을 이해해 둡시다

자주 하는 오해와 개념 정리

❌ 자주 하는 오해: ''최신 모델 = 반드시 Opus'

  • 오해: 최신이자 최고 성능이니까 항상 Opus를 써야 한다고 생각하기 쉽다
  • 실제: 최신 세대의 Haiku는 이전 세대의 Sonnet보다 똑똑한 경우조차 있다. 세대와 패밀리의 축을 혼동하지 말 것
  • 확인 방법: 공식 벤치마크 페이지에서 패밀리 × 세대의 성능을 비교

❌ 자주 하는 오해: '컨텍스트 윈도우가 크다 = 무엇이든 채워 넣을 수 있다'

  • 오해: 1M 토큰이 있으니까 전사의 문서를 통째로 넣어서 검색할 수 있다
  • 실제: 너무 많이 채워 넣으면 'Lost in the Middle' 현상(중간의 정보를 놓치는 것)이나 컨텍스트 열화가 일어난다
  • 확인 방법: RAG・요약・하이브리드 검색을 활용하는 것이 정석

❌ 자주 하는 오해: 'Constitutional AI = 전부 거부된다'

  • 오해: CAI로 훈련되어 있으니까 안전한 질문이라도 거부된다
  • 실제: Helpful도 같은 비중의 원칙. 과도한 거부(over-refusal)도 훈련상으로는 실점
  • 확인 방법: 통상적인 업무 질문은 문제없이 답변한다

자주 발생하는 에러와 대처법

에러 예: model: claude-xxx is not available for your account

  • 원인: 계약 플랜상 해당 모델에 대한 접근 권한이 없음
  • 대처법: Console의 Models 페이지에서 사용 가능한 모델을 확인. Tier 업이 필요한 경우 있음

에러 예: maximum context length exceeded

  • 원인: 입력+출력이 컨텍스트 윈도우를 초과
  • 대처법: 입력을 요약 / 분할한다, 또는 max_tokens를 낮춘다, 혹은 큰 윈도우의 모델로 전환

정리와 다음 한 걸음

  • Anthropic은 AI 안전성 연구를 핵심에 둔 기업으로, Claude는 Constitutional AI와 3H 원칙에 기반해 설계되어 있다
  • 모델 패밀리는 Opus(고성능・고비용)/ Sonnet(균형)/ Haiku(경량・저비용) 세 계통
  • 모델 ID는 claude-{family}-{major}-{minor} 형식. 프로덕션에서는 리비전 고정을 권장
  • 컨텍스트 윈도우는 클수록 좋은 것이 아니라, 컨텍스트 관리와 세트로 생각한다
  • 멀티모달(이미지 입력)에 대응하고 있다
  • Responsible Scaling Policy(RSP)로 AI Safety Level(ASL)이 정의되어 있다

이 장의 연습문제와 해설을 마친 뒤, 다음 장(제4장)에서는 이러한 모델을 API에서 호출하기 위한 기본 파라미터와 조작을 배웁니다.


② CCA-F 자격시험 대비 연습문제 7선: Claude 모델과 설계 철학 핵심 정리 (세션 1)

목차

  • 연습 진행 방법
  • 습득 포인트와 문제 매칭
  • 문제 1 ~ 문제 7

연습 진행 방법

이 장의 문제는 CCA-F 시험을 염두에 둔 시나리오 기반 객관식 문항을 중심으로 구성했어요. 고급 문제와 실전 문제는 입문자라면 건너뛰고 진행하셔도 괜찮아요.

습득 포인트와 문제 매칭

습득 포인트해당 문제
Anthropic의 설계 철학(CAI·3H)을 설명할 수 있다문제 1
모델 패밀리의 특성을 암기하고 있다문제 2, 문제 3
유스케이스에 맞는 모델 선정을 할 수 있다문제 4, 문제 5
모델 ID 명명 규칙을 이해하고 있다문제 3
컨텍스트 윈도우 활용 개념을 파악하고 있다문제 6

문제 1: 설계 철학 이해

  • 카테고리: 기초
  • 목적: Anthropic의 설계 철학(Constitutional AI와 3H 원칙)을 이해하고 있는지 확인
  • 난이도: ★☆☆☆☆
  • 예상 소요 시간: 5분

문제 내용: 다음 중 Constitutional AI(CAI)를 가장 잘 설명한 것을 하나 고르세요.

입출력 사양

  • 입력: 없음
  • 출력: 선택한 번호

제약 조건: 하나만 선택

힌트·예상되는 함정: '외부 감시자'와 '자율적인 자기 성찰'을 혼동하지 말 것

  • (A) 사전에 정의한 원칙에 비추어 AI 스스로 출력을 비평하고 수정하는 구조
  • (B) 외부 감시자가 출력을 순차적으로 확인해 부적절한 응답을 삭제하는 구조
  • (C) 사용자 쪽에서 금지어 목록을 설정하고, 해당 단어가 포함되면 출력을 차단하는 구조
  • (D) Anthropic 직원이 매번 모델 출력을 검토하는 구조

문제 2: 모델 패밀리의 특성

  • 카테고리: 기초
  • 목적: Opus / Sonnet / Haiku의 특성 차이를 암기 수준으로 이해하고 있는지 확인
  • 난이도: ★☆☆☆☆
  • 예상 소요 시간: 5분

문제 내용: 다음 모델 패밀리의 포지셔닝 중 틀린 것을 하나 고르세요.

입출력 사양

  • 입력: 없음
  • 출력: 선택한 번호

제약 조건: 하나만 선택

힌트·예상되는 함정: '속도'와 '정확도'를 헷갈리지 말 것

  • (A) Opus는 최고 성능의 플래그십으로, 복잡한 추론이나 에이전트에 적합하다
  • (B) Haiku는 Opus보다 느리지만, 더 복잡한 추론을 할 수 있다
  • (C) Haiku는 최고 속도의 모델로, 분류나 추출 같은 대량 배치 처리에 적합하다
  • (D) Sonnet은 성능과 비용의 균형을 맞춘 모델로, 일반적인 애플리케이션에 적합하다

문제 3: 모델 ID 명명 규칙

  • 카테고리: 기초
  • 목적: 모델 ID 구조를 이해하고, 프로덕션 운영 시 적절하게 지정할 수 있는지 확인
  • 난이도: ★☆☆☆☆
  • 예상 소요 시간: 5분

문제 내용: 프로덕션 환경에서 재현성을 최대화하기 위해 가장 적절한 model 파라미터 지정은 무엇인가요?

입출력 사양

  • 입력: 없음
  • 출력: 선택한 번호

제약 조건: 하나만 선택

힌트·예상되는 함정: 에일리어스(alias)는 향후 다른 버전으로 다시 지정될 수 있다

  • (A) "claude"
  • (B) "claude-opus"
  • (C) "claude-opus-4-7"
  • (D) "claude-opus-4-7-20251215"

이 문항이 가르치는 원칙(날짜가 박힌 전체 ID로 지정해야 재현성이 가장 높고, 에일리어스는 나중에 다른 버전으로 다시 지정될 수 있음)은 그대로 유효합니다. 다만 실제 명명 규칙은 세대에 따라 조금 다릅니다. Claude 4.6 세대부터는 모델 ID가 날짜 없는 형식(예: claude-opus-4-8) 자체로 고정 스냅샷이 되어, 별도 날짜 접미사 없이도 특정 릴리스에 고정됩니다. 4.6 이전 세대에서는 예제 (D)처럼 날짜가 붙은 전체 ID가 고정 스냅샷이고, 날짜 없는 쪽이 에일리어스였습니다. 문항의 정답 논리(가장 구체적으로 지정한 것을 고른다)는 어느 세대에서든 통합니다.

문제 4: 모델 선정 (시나리오 문제)

  • 카테고리: 응용
  • 목적: 업무 시나리오에서 적절한 모델 선정 판단을 내릴 수 있는지 확인
  • 난이도: ★★☆☆☆
  • 예상 소요 시간: 10분

문제 내용: 다음 시나리오에서 가장 적절한 모델을 고르세요.

시나리오: 이커머스 사이트에서 사용자 리뷰(하루 100만 건)를 '긍정 / 부정 / 중립' 3개 클래스로 분류하는 배치 처리를 구현하려고 합니다. 리뷰 한 건당 텍스트는 200자 정도이고 내용도 단순합니다. 비용 최적화를 최우선으로 합니다.

입출력 사양

  • 입력: 없음
  • 출력: 선택한 번호와 이유(1~2문장)

제약 조건: 이유도 반드시 작성

  • (A) Opus
  • (B) Sonnet
  • (C) Haiku
  • (D) 무엇을 써도 똑같다

문제 5: 모델 선정 (복잡 시나리오)

  • 카테고리: 응용
  • 목적: 복잡한 시나리오에서 단계적으로 모델을 나눠 쓰는 판단을 할 수 있는지 확인
  • 난이도: ★★☆☆☆
  • 예상 소요 시간: 10분

문제 내용: 여러분은 고객 지원용 에이전트를 설계하고 있습니다.

요건:

  • 하루 10만 건의 문의를 처리한다
  • 대부분(80%)은 FAQ로 답변할 수 있는 단순한 문의다
  • 나머지 20%는 복잡한 조사·추론이 필요하다
  • SLA: 문의의 99%를 3초 이내에 응답한다

가장 합리적인 설계는 무엇인가요?

  • (A) 전부 Opus로 처리한다
  • (B) 전부 Haiku로 처리한다
  • (C) 먼저 Haiku로 'FAQ로 답변 가능한가'를 판단하고, 가능하면 Haiku로 답변하며, 불가능한 경우에만 Opus로 에스컬레이션한다
  • (D) 무작위로 모델을 전환한다

문제 6: 컨텍스트 윈도우 이해

  • 카테고리: 기초
  • 목적: 컨텍스트 윈도우의 개념과 함정을 이해하고 있는지 확인
  • 난이도: ★★☆☆☆
  • 예상 소요 시간: 5분

문제 내용: '컨텍스트 윈도우가 1M 토큰'인 모델에 500K 토큰 분량의 사내 문서를 전부 넣고 특정 정보를 질문했습니다. 기대한 답을 얻지 못하는 원인으로 가장 가능성이 높은 것은 무엇인가요?

  • (A) Lost in the Middle 현상이나 Context Degradation으로 인해 중간에 있는 정보가 누락됐다
  • (B) 컨텍스트 윈도우를 초과했다
  • (C) Claude가 한국어를 이해하지 못한다
  • (D) API 키가 올바르게 설정되지 않았다

문제 7 (고급): RSP와 운영 판단

  • 카테고리: 고급
  • 목적: Responsible Scaling Policy(RSP)의 개념과 운영상의 책임을 이해하고 있는지 확인
  • 난이도: ★★★★☆
  • 예상 소요 시간: 15분

문제 내용: 자사 서비스에서 Claude를 사용할 때, Responsible Scaling Policy(RSP)와 관련한 운영상의 책임으로 가장 적절한 설명은 무엇인가요?

  • (A) RSP는 Anthropic이 단독으로 관리하므로, 이용자 쪽에서는 아무것도 신경 쓸 필요가 없다
  • (B) RSP에는 ASL-1~4 레벨이 정의되어 있으며, 이용자는 모델의 능력 레벨에 상응하는 운영상의 보안 대책을 고려할 책임이 있다
  • (C) RSP를 위반하면 즉시 계정이 정지되므로, 관련 서류를 사내에 배포해야 한다
  • (D) RSP는 연구 논문상의 논의일 뿐, 실제 운영과는 무관하다

정답은 이 장 후반의 정답·해설편에서 확인하세요.


③ CCA-F 연습문제 정답·해설 완전정복 (세션 1): Claude 모델 선정부터 RSP까지

목차

  • 정답 일람
  • 문제별 해설 (문제 1 ~ 문제 7)
  • 이 세션 돌아보기

정답 일람

문제정답
문제 1(A)
문제 2(B)
문제 3(D)
문제 4(C)
문제 5(C)
문제 6(A)
문제 7(B)

문제 1: 설계 철학 이해 — 정답 (A)

해설

Constitutional AI(CAI)는 사전에 정의한 원칙(헌법)에 비추어 AI가 스스로 자기 출력을 비평하고 수정하는 구조예요. 자율적인 자기 성찰 구조라서, 외부 감시자나 금지어 목록과는 성격이 다르죠.

오답 선택지

  • (B): 외부 감시자 방식은 CAI가 아니라 별개의 안전성 접근법이에요.
  • (C): 금지어 필터는 애플리케이션 층의 대책이라, CAI 설명이 아니에요.
  • (D): 사람 검토는 RLHF(사람 피드백 기반 강화학습)의 일부일 뿐, CAI 자체는 아니에요.

◆ 설계와 운용 포인트

  • 설계 사상: CAI는 '규모를 키우기 어려운 사람 검토'를 대신해 AI가 스스로 성찰하게 만드는 구조예요. Claude가 '설명 가능한 거절 이유'를 대기 쉬운 배경이기도 해요.
  • 운용 시 주의점: CAI로 훈련됐다고 해서 모든 안전성 책임이 AI 쪽에 있는 건 아니에요. 애플리케이션 층에서도 점검 계층을 하나 더 두는 걸 권장해요.

문제 2: 모델 패밀리의 특성 — 정답 (B)

해설

'Haiku는 Opus보다 느리지만 더 복잡한 추론을 할 수 있다'가 틀렸어요. 순서가 반대죠. Haiku는 Opus보다 빠르지만, 복잡한 추론은 Opus가 잘해요.

올바른 관계

최강중간최속 / 최저가
추론 능력OpusSonnetHaiku
속도HaikuSonnetOpus
비용 효율HaikuSonnetOpus

◆ 설계와 운용 포인트

  • 외우는 법: 음악 용어의 길이에 대응해요. Opus(서사시) = 규모 큼, Haiku(하이쿠) = 규모 작음, Sonnet(14행시) = 중간.

  • 운용 시 주의점: 모델 선정 시험 문제에서는 '속도'와 '정확도'를 바꿔치기한 선택지가 자주 나와요. 차분히 읽으면 걸러낼 수 있어요.

문제 3: 모델 ID 명명 규칙 — 정답 (D)

해설

리비전이 붙은 ID(claude-opus-4-7-20251215처럼 날짜 접미사가 붙은 형태)를 지정하면 특정 학습 리비전을 고정할 수 있어요. 에일리어스(claude-opus-4-7)는 나중에 같은 패밀리의 새 버전으로 다시 지정될 수 있어서 재현성에 영향을 줘요.

오답 선택지

  • (A), (B): 패밀리나 버전이 특정되지 않아 무효예요.
  • (C): 에일리어스로도 동작은 하지만, 프로덕션에서 재현성을 확보하려면 리비전이 붙은 ID를 권장해요.

[최신 정보] 이 해설의 원칙(날짜 접미사로 리비전을 고정하면 재현성이 높고, 에일리어스는 새 버전으로 재지정될 수 있음)은 그대로 맞습니다. 다만 실제 규칙은 세대에 따라 달라요. Claude 4.6 세대부터는 날짜 없는 형식(예: claude-opus-4-8) 자체가 고정 스냅샷이라, 별도 날짜 없이도 특정 릴리스에 고정됩니다. 즉 최신 세대에서는 claude-opus-4-7 같은 형태가 에일리어스가 아니라 고정 스냅샷이에요. 해설이 든 예시(날짜가 붙은 전체 ID)는 4.6 이전 규칙을 반영한 것이고, '가장 구체적으로 지정한다'는 결론은 어느 세대에서든 통합니다.

◆ 설계와 운용 포인트

  • 설계 사상: 모델 업데이트는 사용자가 예상하지 못한 동작 변화를 일으킬 수 있어요. 그래서 프로덕션에서는 '고정', 검증 환경에서는 '최신 추종'으로 나눠 쓰는 게 일반적이에요.
  • 운용 시 주의점: 다만 고정해 두면 보안 수정이나 버그 픽스도 따라가지 못한다는 점을 조심하세요. 정기적인 평가와 업데이트 주기를 함께 설계해야 해요.

문제 4: 모델 선정 (시나리오 문제) — 정답 (C)

해설과 이유 예시

단순한 3개 클래스 분류이고 비용 최적화가 최우선이라 Haiku가 최적이에요. Opus는 추론 능력에서는 유리하지만, 단순 분류에 쓰기엔 과잉 스펙이라 비용이 불어나요.

◆ 설계와 운용 포인트

  • 비용 계산: 100만 건 × 200자 × Haiku 단가 vs 100만 건 × Opus 단가. Opus는 수십 배 비용이 되기 십상이에요.
  • 품질 확인: '단순'하다고 판단한 작업이라도, Haiku로 타당성 검증(수백 건으로 정확도 측정)을 거친 뒤 프로덕션에 투입하는 게 철칙이에요.
  • 다른 답: Sonnet도 아예 없는 선택지는 아니지만, 이 문제의 '비용 최우선' 제약을 보면 결국 Haiku가 최적이죠.

문제 5: 모델 선정 (복잡 시나리오) — 정답 (C)

해설

'FAQ로 답변할 수 있는가'를 Haiku로 먼저 분류하고, 가능하면 그대로 Haiku로 대응하며, 복잡한 조사가 필요하면 Opus로 에스컬레이션하는 단계적 처리가 가장 합리적이에요. 이 패턴은 '라우팅형 에이전트'라고 부르고, 도메인 1(에이전트 아키텍처)에서 다시 자세히 다뤄요.

오답 선택지

  • (A): 전건 Opus는 비용이 막대하고 SLA도 나빠져요.
  • (B): 전건 Haiku는 복잡한 20%에서 품질이 부족해요.
  • (D): 무작위는 합리성이 없어요.

◆ 설계와 운용 포인트

  • 단계적 처리의 장점: '요건을 충족하는 가장 저렴한 모델'을 고른다는 원칙을 구현으로 옮긴 패턴이에요.
  • 운용 시 주의점: 라우터(Haiku)가 'FAQ로 충분하다'고 잘못 판단하면 고객 경험이 나빠져요. 그래서 임곗값(confidence threshold)이나 폴백(fallback) 설계가 중요해요.
  • 계산량과 리소스 사용: 전체 요청 중 80%는 Haiku만, 20%는 Haiku + Opus의 2단계 호출이에요. 총비용은 '전부 Opus'보다 크게 줄어들어요.

문제 6: 컨텍스트 윈도우 이해 — 정답 (A)

해설

500K 토큰은 1M 컨텍스트 윈도우 안에 들어오니 초과가 아니에요. 하지만 Lost in the Middle 현상이나 Context Degradation 때문에, 윈도우 중반에 놓인 정보의 참조 정확도가 떨어진다고 알려져 있죠.

대책

  • RAG(Retrieval-Augmented Generation): 관련 정보만 뽑아서 입력.
  • 요약 압축: 긴 글을 미리 요약해 토큰 수를 줄이기.
  • 청크 + 랭킹: 여러 청크로 나눠 관련도가 높은 것만 입력.

자세한 내용은 세션 10·11에서 다뤄요.

◆ 설계와 운용 포인트

  • 설계 사상: '컨텍스트 윈도우는 책상 넓이'라고 외워 두세요. 넓긴 하지만, 정리해서 써야 해요.
  • 운용 시 주의점: 벤치마크에서 '윈도우 전체를 활용할 수 있는가'를 재는 Needle in a Haystack 테스트가 업계 표준이에요.

문제 7 (고급): RSP와 운영 판단 — 정답 (B)

해설

Responsible Scaling Policy(RSP)는 모델의 능력(ASL 레벨)에 맞춰 보안 대책을 강화하는 정책이죠. 이용자 쪽에도 이런 책임이 있어요.

  • API 키 관리(유출 방지)
  • 출력의 최종 확인(특히 외부에 공개되는 콘텐츠)
  • ASL 레벨에 걸맞은 권한 관리

오답 선택지

  • (A): 이용자 쪽에도 책임이 있으니 틀려요.
  • (C): RSP를 위반한다고 곧바로 계정이 정지되는 건 아니에요(과도한 서술).
  • (D): RSP는 실제 운영에도 관여하는 공개 정책이에요.

◆ 설계와 운용 포인트

  • 설계 사상: AI 안전성은 Anthropic과 이용자의 공동 책임이에요. 공유 책임 모델(shared responsibility model, 클라우드 서비스의 책임 공유 모델과 비슷)이죠.
  • 운용 시 주의점: 엔터프라이즈 도입 때는 사용 부서를 위해 'Claude를 쓸 때의 사내 규칙'을 정비해 두는 게 좋아요.

이 세션 돌아보기

  • Anthropic의 설계 철학(CAI·3H·RSP)을 이해했어요.
  • Opus / Sonnet / Haiku의 특성과 선정 기준을 익혔어요.
  • 모델 ID 명명 규칙과 프로덕션 운영에서의 주의점을 짚었어요.
  • 컨텍스트 윈도우의 크기와 함정까지 파악했고요.

다음 세션(제4장)에서는 이 모델들을 API에서 호출하기 위한 기본 파라미터와 사용법을 배워요.


©2024-2026 ClaudeCode.to, Hand-crafted & made with Jaewoo Kim.

  • 이메일문의: jaewoo@claudecode.to
  • AI 에이전트 만드는 사람
  • 기업 AI 강의 · 에이전트 개발 · 기술자문
  • "AI한테 일 시키는 법, 제대로 알려드립니다"