기능별 팁 & 마이그레이션

🧭

이 페이지는 개발자나 고급 사용자를 위한 확장 내용입니다. 공식문서의 best practices에 포함되어 있어 문서에는 그대로 남깁니다. 초보자라면 이 페이지에서 딱 하나만 가져가세요: 결과물이 심심하거나 아쉬우면 AI 실력 탓부터 하지 말고, 요청 뒤에 “더 상세하게”, “시각적으로 풍부하게” 같은 한 마디 수정자를 붙여 기본값을 먼저 끌어올리세요.

지난 시간 복습

에이전트 = 사고 + 행동 루프

자율적으로 일하되, 안전 가드레일이 필수

들어가며 — 큰 그림에서 디테일로

지난 13강까지는 에이전트 시스템의 “큰 그림”을 다뤘습니다. 14강부터는 요청 하나하나에 숨어 있는 작은 장치들을 살펴봅니다. 오늘의 주인공은 수정자 프레이밍(Modifier Framing) 입니다.

오늘의 여정

1. “대시보드 만들어줘” — 문제 열기

2. 수정자 프레이밍 단어 해부

3. AI의 기본값이라는 숨은 개념

4. 공식 마이그레이션 표 — Before/After

5. 실무 세 가지 사례 (보고서·회의록·이메일)

6. 비전 팁 + AI 슬롭 방지

장면 하나 상상해 보세요

”대시보드 하나 만들어줘”

기능은 돌아갑니다 — 그런데 아주 심심한 결과

이런 경험 있으시죠?

”이걸로 보고하긴 좀…”

결국 내가 다시 손봐야 하는 결과물

또 다른 장면

이미지의 숫자를 틀리게 읽어요

”어? AI가 이런 것도 못 하나?”

한 가지 질문

”이게 AI의 한계일까요?”

AI가 원래 이 정도밖에 못 하는 걸까요?

사실은 아닐 수 있어요

요청하는 방식을 조금만 바꾸면

한 마디. 한 줄. — 결과물의 수준이 바뀝니다

💼

직장인 학습 가이드: 이 챕터는 Claude API 마이그레이션과 개발자 설정을 다룹니다. Claude.ai를 사용하는 직장인은 “수정자 프레이밍” 기법과 “AI 슬롭 방지” 두 가지에 집중하세요. 이 두 가지만 제대로 익혀도 내일 업무에 바로 써먹을 수 있습니다. 코드 블록은 “개발자들은 이런 것도 조절하는구나” 정도로 가볍게 읽어도 충분합니다.

오늘의 핵심 단어

수정자 프레이밍 (Modifier Framing)

이 단어 하나만 제대로 뜯으면 오늘의 절반

단어 해부 — Modifier Framing

Modifier Framing은 오늘 강의를 관통하는 핵심 개념입니다. 두 단어로 쪼개어 의미를 살펴봅니다.

Modifier — 수정하는 것

영어 문법의 수식어 — “빨간 자동차”의 “빨간”

명사의 성격을 바꿔주는 역할

Framing — 틀을 잡는 것

Frame = 틀(액자). Framing = 틀을 잡는 행위

사진 프레이밍처럼 — 어떤 틀 안에서 요청할지 결정

두 단어를 합치면

Modifier Framing = 요청의 틀을 살짝 수정하는 기법

원래 요청은 그대로 — 틀의 모양만 조절

방법: 한 마디를 추가해서

후배 비유 — Before

”자료 좀 만들어줘”

A4 반 장. 틀린 건 없지만 — 뭔가 부족

후배 비유 — After

”상세하게, 차트도 넣어서 자료 만들어줘”

A4 세 장. 차트. 구조. 근거 — 완전히 다른 물건

오늘의 첫 핵심

한 마디가 결과물의 수준을 바꾼다

사람에게도 — AI에게도 — 똑같이 적용됩니다

그런데 왜 그럴까요?

AI에게는 “기본값”이 있다

default — 아무 지시 없을 때 자동으로 나오는 수준

AI의 기본값(default) 개념

수정자 프레이밍이 왜 작동하는지 이해하려면 “기본값”이라는 숨은 개념을 먼저 짚어야 합니다. AI는 학습 데이터에서 가장 많이 본 수준으로 기본 출력을 맞춥니다.

기본값의 성격

평균 — 가장 많이 본 수준

안전 — 튀지 않게

무난 — 욕 안 먹을 만큼

기본값 그대로 두면

심심한 대시보드가 나온다

AI의 잘못이 아니에요 — 기본값 수준의 요청을 한 것

→

그럼 어떻게 해결하죠?

기본값을 끌어올리는 장치가 필요합니다

”그냥 만들어줘” 말고 — “이 정도 수준으로 만들어줘”

그 장치의 이름이

수정자 프레이밍 = 기본값 상승 스위치

한 마디 추가 = 스위치 한 번 누르기

공식 마이그레이션 고려사항 표

Claude 4.6 모델로 마이그레이션할 때 점검해야 할 항목들입니다.

항목	가이드
원하는 동작	출력에서 정확히 무엇을 보고 싶은지 구체적으로 설명
수정자 프레이밍	”대시보드 만들어줘” → “대시보드를 만들어줘. 가능한 한 많은 기능과 인터랙션을 포함해줘.”
특정 기능 요청	애니메이션, 인터랙티브 요소는 명시적으로 요청
사고 구성	`thinking: {type: "adaptive"}` + `effort` 매개변수 사용
사전 채움	더 이상 지원되지 않음 → 대안 참고
과잉 방지 프롬프팅	Claude 4.6은 훨씬 적극적 → 공격적 표현 완화

표 6행 훑기

1. 원하는 동작 구체화

2. 수정자 프레이밍 — 오늘의 주인공

3. 특정 기능 명시적 요청 — 오늘 두 번째 주인공

4. 사고 구성 업데이트 — 15강

5. 사전 채움 마이그레이션 — 15강

6. 과잉 방지 프롬프팅 — 15강

🎯

표의 두 번째 줄

”출력 품질과 세부 사항을 높이도록 장려하는 수정자를 추가하세요.”

강제가 아니라 장려 — 그 역할이 “한 마디”

공식 예시 — Before

”대시보드를 만들어줘.”

한 줄. 끝. — 기본값 수준 요청의 전형

공식 예시 — After

”대시보드를 만들어줘.

가능한 한 많은 관련 기능과 인터랙션을 포함해줘.

기본을 넘어서 완전한 기능을 갖춘 구현을 만들어줘.”

가추법 한번 해볼까요

왜 이 예시를 굳이 공식문서에 넣었을까?

추론: 너무 쉬워서 사람들이 안 써요

Before 결과 스케치

박스 세 개에 숫자만

기본 바 차트 하나

무난한 파란색 — 인터랙션 없음

After 결과 스케치

메트릭 카드 여섯 개

차트 세 종류 (막대·도넛·라인)

필터 토글 + 기간 셀렉터 + 툴팁 + 상세 뷰

기본 요청 vs 수정자 추가

왼쪽: “대시보드 만들어줘” — 밋밋

오른쪽: “대시보드 만들어줘. 가능한 한 많은 기능과 인터랙션을 포함해줘.” — 풍성

앞부분은 같다 — 뒤에 붙은 한 마디가 전부를 바꿨다

변화의 크기를 체감해 보세요

30자가 수준을 한 단계 올렸다

보고받을 물건 vs 내가 다시 손봐야 할 물건 — 그 차이

오늘 첫 번째 포인트

한 줄의 힘

프롬프트 전체를 갈아엎을 필요가 없어요 — 한 줄만 붙이면 됩니다

대시보드에만 통하는 얘기가 아니에요

보고서 · 회의록 · 이메일

아이디어 회의 · 코드 리뷰 · 디자인 시안

이제 실무 사례 세 가지를 볼게요

실무 사례 1 — 보고서 Before

”보고서 작성해줘.”

일반론 두세 단락. 숫자 없음. 사례 없음.

보고서 — After

”보고서 작성해줘. 가능한 한 구체적인 수치와 사례를 포함해서.”

주요 지표에 실제 수치 · 각 단락에 사례 · 개선 방안에 근거

실무 사례 2 — 회의록 Before

”회의록 정리해줘.”

한 덩어리로 쫙 — 누가 뭘 하기로 했는지가 안 보인다

회의록 — After

”회의록 정리해줘. 각 안건별로 결정사항과 액션 아이템을 분리해서.”

안건 1 → 결정사항 / 액션 아이템

안건 2 → 결정사항 / 액션 아이템

실무 사례 3 — 이메일 Before

”이메일 초안 써줘.”

문장은 예쁜데 — 상대방이 한 번에 이해하기 어려운 구조

이메일 — After

”이메일 초안 써줘. 상대방이 한 번에 이해할 수 있도록 구조를 잡아서.”

용건이 첫 줄 · 핵심 내용 불릿 · 마지막에 요청사항

공통 패턴이 보이시죠?

원래 요청 + “~하게/~해서” 한 줄

”보고서 작성해줘” + “구체적인 수치와 사례를 포함해서"

"회의록 정리해줘” + “안건별로 결정사항과 액션 아이템을 분리해서"

"이메일 초안 써줘” + “구조를 잡아서”

수정자 프레이밍 실무 예시 정리

보고서: “보고서 작성해줘” → “보고서 작성해줘. 가능한 한 구체적인 수치와 사례를 포함해서.”
회의록: “회의록 정리해줘” → “회의록 정리해줘. 각 안건별로 결정사항과 액션 아이템을 분리해서.”
이메일: “이메일 초안 써줘” → “이메일 초안 써줘. 상대방이 한 번에 이해할 수 있도록 구조를 잡아서.”

앞부분은 그대로, 뒤에 “~하게/~해서” 한 줄 — 이 공식 하나만 외우시면 내일 업무가 바뀝니다.

따라 말해 보세요

”원래 요청 · 플러스 · ~하게 한 줄”

손가락이 먼저 기억합니다 — 내일 자판이 저절로 움직여요

바로 쓰는 템플릿

[원래 요청].

[~하게/~해서] [구체적인 기준].

예: [프레젠테이션 초안]. [임원이 3분 안에 이해하도록] [핵심 3가지로].

🎯

표의 세 번째 줄 — 특정 기능 명시적 요청

”애니메이션, 인터랙티브 요소는 원할 때 명시적으로 요청해야 합니다.”

AI는 안 시키면 안 해요

AI는 기대를 읽지 않아요 — 말을 읽어요

말하지 않은 것은 안 합니다

”당연히 해주겠지”의 함정

당연히는 — 통하지 않는다

후배에게도 AI에게도 똑같이

03강 콜백

”명확하고 직접적으로”

기억 상실 천재 신입사원 — 원하는 게 있으면 직접 말하세요

명시적으로 요청하는 법

표를 원하면 — “표로 정리해줘”

차트를 원하면 — “차트를 포함해줘”

비교가 필요하면 — “장단점을 비교해줘”

막연히 “잘 정리해줘” 대신 — 형태를 지정하세요

습관으로 만들 자문

”내가 기본값 수준의 요청을 한 건 아닐까?”

AI를 바꾸는 게 아니라 — 내 요청을 바꾸는 것

향상된 비전 기능

Claude Opus 4.5와 4.6은 이전 모델에 비해 향상된 비전 기능을 가지고 있습니다. 특히 컨텍스트에 여러 이미지가 있을 때 이미지 처리 및 데이터 추출 작업에서 더 나은 성능을 보여줍니다.

🔍

“Claude Opus 4.5와 4.6은 이전 모델에 비해 향상된 비전 기능을 가지고 있습니다. 특히 컨텍스트에 여러 이미지가 있을 때 이미지 처리 및 데이터 추출 작업에서 더 나은 성능을 보여줍니다.”

✂️

강력한 팁 — Claude에게 자르기(crop) 도구나 스킬을 제공하면 성능이 더 높아집니다. Claude가 이미지의 관련 영역을 “확대”할 수 있을 때 이미지 평가에서 일관된 성능 향상이 나타났습니다.

A4 멀리서 vs 확대해서

멀리서: 전체 구조는 보여도 숫자는 안 보여요

확대해서: 소수점 둘째 자리까지 보입니다

AI도 같아요 — 세밀한 숫자는 잘라서 주세요

비전 기능 실무 3가지

1. 영수증 — 금액 영역을 잘라서

2. 계약서 — 해당 조항만 잘라서, 확대해서

3. 디자인 시안 — 타이포만 · 팔레트만 부분별로

💡

비전 팁의 원리

확대 = 노이즈 줄이기

AI가 “무엇이 중요한가”를 고민하는 시간을 미리 줄여주는 것

결국 AI의 기본값을 제어하는 같은 원리

프론트엔드 디자인

Claude Opus 4.5와 4.6은 복잡한 실제 웹 애플리케이션을 구축하는 데 뛰어납니다. 그러나 가이드 없이는 “AI 슬롭” 미학이라고 불리는 일반적인 패턴으로 기본 설정될 수 있습니다.

AI 슬롭 (AI Slop)

Slop = 찌꺼기 · 대충 만든 음식 · 엉성한 것

AI가 만들어내는 찌꺼기 같은 미학

AI 슬롭의 3대 징후

1. 흰 배경

2. 보라색 그라데이션

3. Inter 폰트

이 셋이 붙으면 — “아, AI가 만들었네”

📊

“AI는 분포상의 출력으로 수렴하는 경향이 있습니다.” — 학습 데이터에서 가장 많이 본 패턴(평균값)으로 기울어진다는 뜻. 결국 다시 기본값 이야기입니다.


<frontend_aesthetics>
당신은 일반적이고 "분포상의" 출력으로 수렴하는 경향이
있습니다. 프론트엔드 디자인에서 이것은 사용자들이 "AI 슬롭"
미학이라고 부르는 것을 만듭니다. 이를 피하세요: 놀랍고
만족스러운 창의적이고 독특한 프론트엔드를 만드세요.
 
집중할 점:
- 타이포그래피: 아름답고, 독특하며, 흥미로운 폰트를
  선택하세요. Arial과 Inter 같은 일반적인 폰트는 피하세요.
- 색상 & 테마: 일관된 미학에 전념하세요. CSS 변수를
  사용하세요. 날카로운 악센트와 함께하는 주요 색상이 소심하고
  균등하게 분배된 팔레트보다 효과적입니다.
- 모션: 효과와 마이크로 인터랙션에 애니메이션을 사용하세요.
  고영향 순간에 집중하세요.
- 배경: 단색 기본값 대신 분위기와 깊이를 만드세요.
 
피해야 할 것:
- 과다 사용 폰트 패밀리 (Inter, Roboto, Arial, 시스템 폰트)
- 진부한 색상 체계 (흰색 배경에 보라색 그라데이션)
- 예측 가능한 레이아웃과 컴포넌트 패턴
</frontend_aesthetics>

frontend_aesthetics — 4가지 지시 축

1. 타이포그래피 — 일반 폰트 금지

2. 색상 — 날카로운 악센트와 주요 색상

3. 모션 — 고영향 순간 집중

4. 배경 — 단색 대신 그라데이션/패턴

여기서 오늘이 하나로 꿰입니다

AI 슬롭 방지 = 수정자 프레이밍의 다른 이름

”그냥 디자인해줘” → “이런 폰트로, 이런 색상으로, 이런 모션으로”

기본값을 “평균”에서 “의도적으로 선택한 미학”으로 옮기기

14강 정리 3줄

1. 수정자 프레이밍 = 한 줄의 힘

2. AI에게는 기본값이 있다 — 아무 지시 없으면 평균으로 수렴

3. 원하는 건 직접 말해야 한다 — 표·차트·애니메이션 모두 명시적으로

오늘의 통찰

요청의 구체성이 결과물을 결정한다

모델이 바뀌어도 — 이 원칙은 변하지 않아요

AI만의 이야기일까요?

후배에게도 · 외주에게도 · 나 자신에게도

요청이 구체적일수록 — 결과가 풍부해진다

AI와 잘 일하는 법이 — 결국 사람과 잘 일하는 법

오늘의 액션

기본 요청 뒤에 수정자 한 줄

”~를 포함해서” · “~하게 정리해서” · “~가 보이도록”

내일 첫 번째 요청부터 바로 해보세요

다음 강의 예고

마이그레이션 가이드 — 마지막 강의

원칙은 변하지 않아요 — 다만 “조절 포인트”가 있습니다

마이그레이션 가이드

지난 시간 복습

수정자 프레이밍 = 기본값 상승 스위치

”대시보드 만들어줘” 뒤에 붙는 한 줄이 결과물의 수준을 바꾼다

들어가며 — 14강에서 15강으로

14강에서는 수정자 프레이밍을 배웠습니다. 한 줄의 수정자가 AI의 기본값을 끌어올리는 장치였죠. 15강은 그 연장선에서 출발합니다. “모델이 바뀌면 — 내 프롬프트도 바뀌어야 하는가?”라는 질문에 답하는 시간입니다.

오늘의 여정

1. 마이그레이션 단어 해부 — 철새 비유

2. 과잉 방지 프롬프팅 — 하강 스위치

3. Sonnet 4.5 → 4.6 구체 설정

4. 적응형 사고(Adaptive Thinking)

5. 점검 3단계 체크리스트

6. 16강 여정 회고 · OT 약속 회수

장면 하나 상상해 보세요

”Claude 4.5가 갑자기 4.6이 됐어요”

정성껏 다듬어 놓은 프롬프트 — 다시 써야 하나?

한 가지 질문

”모델이 바뀌면 — 프롬프트도 바뀌어야 할까요?”

지금까지 배운 14강의 원칙들은 새 모델에서도 유효할까요?

결론부터 — 원칙은 변하지 않아요

명확·맥락·예시·구조 — 전부 통한다

Claude 1이든 4든 GPT-5든 — 원칙은 살아 있습니다

그런데 — 조절 포인트가 있어요

모델의 기본값이 바뀝니다

원칙은 그대로, 기본값만 적응시키는 법 — 오늘의 초점

오늘의 핵심 단어

Migration · 이주 · 이동 · 마이그레이션

개발자에게 익숙한 이 단어 — 원래 어디서 왔을까요?

Migration의 원뜻 — 철새의 이동

‘Migration’은 원래 철새의 계절 이동을 뜻합니다. 철새가 겨울엔 따뜻한 곳으로, 여름엔 시원한 곳으로 환경에 맞춰 이동하는 행위가 Migration이죠. 핵심은 “환경 변화에 대응한 적응”입니다.

어원

Migration = 철새의 계절 이동

겨울에는 따뜻한 곳으로, 여름에는 시원한 곳으로

”환경 변화에 대응한 이동” — 적응이 핵심

철새 비유 ①

환경이 바뀌어도 — 새는 같다

날개 구조, 비행 원리, 본능 — 본질은 불변

철새 비유 ②

조절하는 건 — 먹이·기온·바람

사냥 방식, 체온 조절, 비행 고도 — 디테일만 적응

오늘의 핵심 공식

원칙 불변 · 기본값 적응

원칙(명확·맥락·예시·구조)은 안 바꾼다
기본값(적극성·길이·사고 깊이)은 조절한다

핵심 공식 — 원칙 불변, 기본값 적응

마이그레이션이란 새 모델의 기본값에 맞춰 내 프롬프트를 조절하는 일입니다. 본질을 갈아엎는 게 아닙니다. 철새가 환경에 따라 비행 고도를 바꾸듯, 새 모델의 기본값 위치를 파악하고 수정자의 방향을 맞추는 겁니다.

💼

직장인 학습 가이드 (2/2): 오늘은 어제보다 개발자 얘기가 조금 더 많습니다. effort 매개변수, thinking 설정 같은 API 세팅이 등장해요. Claude.ai를 쓰시는 직장인 분들은 **“과잉 방지 프롬프팅”**과 “점검 3단계”, 그리고 마지막 “여정 회고” 세 가지에만 집중하세요. 이 세 가지만 제대로 챙기면 오늘 강의의 90%를 얻으신 겁니다. 코드 블록은 “개발자들은 이런 설정을 조절하는구나” 정도로 가볍게 넘겨도 충분합니다.

마이그레이션 고려사항 표 — 이번엔 4·5·6행

14강에서는 2·3행: 수정자 프레이밍, 특정 기능 요청

오늘은 4·5·6행:

④ 사고 구성 (adaptive thinking)

⑤ 사전 채움 (prefill)

⑥ 과잉 방지 프롬프팅

⑥

과잉 방지 프롬프팅

공식문서: “Claude 4.6은 훨씬 적극적입니다”

권장: “공격적 표현을 완화하세요”

과잉 방지 프롬프팅 — 공식문서 원문

마이그레이션 고려사항 표의 여섯 번째 행입니다. “Claude 4.6은 훨씬 적극적입니다. 공격적 표현을 완화하세요.” 이전 모델 시대에 습관적으로 쓰던 “적극적으로 해줘”, “더 열심히 해줘”, “철저하게 분석해줘” 같은 수정자가 이제는 오히려 과잉을 만들 수 있다는 뜻입니다.

왜 예전엔 공격적 표현이 필요했나

예전 AI 기본값 = 소극적

요약 짧게 · 분석 겉핥기 · 리뷰 “괜찮아 보입니다” 한 줄

그래서 “더 열심히”라는 밀어붙이는 수정자가 필요했던 것

지금은 기본값이 이미 적극적

Claude 4.6 = 아무 말 안 해도 적극적

예전 수정자를 그대로 쓰면 — 과하게 작동합니다

”너무 열심히 한” 결과물의 증상

❌ 불필요하게 길어진다

❌ 이것저것 다 설명하려 한다

❌ 결론이 산만해진다

❌ 한 줄이면 될 걸 세 단락으로 말한다

수정자 = 양방향 스위치

↑ 상승 (14강) · ↓ 하강 (15강)

위로: “상세하게”, “풍부하게”, “철저하게”
아래로: “간결하게”, “핵심만”, “담백하게”

14강의 상승 스위치 + 15강의 하강 스위치

14강에서 배운 수정자 프레이밍이 “기본값을 끌어올리는 스위치”였다면, 15강의 과잉 방지 프롬프팅은 “기본값을 끌어내리는 스위치”입니다. 두 방향을 합치면 양방향 조절이 완성됩니다. 적절한 높이를 맞추는 기술이죠.

실무 완화 ① — 보고서

임원 보고용 한 장 요약이 필요할 때

”보고서 요약해줘. 3문장 이내로, 핵심만 담아서.”

기본값이 “상세” → “간결”로 내려주기

실무 완화 ② — 코드 리뷰

치명적 버그만 보고 싶을 때

”이 코드 리뷰해줘. 치명적인 버그 리스크 3개만 집어서.”

풍부하게가 아니라 — 집중해서 적게

상위 원리

수정자 프레이밍 = 양방향 기본값 제어

기본값 낮으면 ↑, 높으면 ↓ — 내가 원하는 수준으로 맞추는 기술
모델이 바뀌어도 이 원리는 변하지 않습니다

섹션 전환 — 파트 2

Claude Sonnet 4.5 → 4.6 구체 마이그레이션

여기서부터 API 설정 얘기가 나옵니다

직장인 분들은 “개발자는 이런 설정을 조절하는구나” 정도로 가볍게

Claude Sonnet 4.5 → Sonnet 4.6 마이그레이션

Claude Sonnet 4.6은 기본 노력 수준이 high입니다 (Sonnet 4.5는 effort 매개변수 없음).

공식문서 인용

”기본 effort = high”

Sonnet 4.5엔 없던 매개변수가 4.6에 새로 생겼다
그 이름이 effort — “가장 열심히 하는 설정”이 기본

단어

effort = 노력 · 수고 · 공들임

AI가 답변하는 데 얼마나 공을 들이는지 조절

Low: 빨리, 가볍게 · Medium: 적당히 · High: 깊이 있게

공식문서 권장 노력 설정

Medium — 대부분의 애플리케이션

Low — 대량 또는 지연 시간 민감 워크로드

Medium/High에서 64k 토큰 최대 출력 예산 권장

권장 노력 설정

Medium: 대부분의 애플리케이션
Low: 대량 또는 지연 시간에 민감한 워크로드
Medium/High에서 64k 토큰 최대 출력 예산 권장

왜 Low가 필요한가

① 대량 처리 — 수천·수만 건 배치, 비용 감당

② 지연 시간 민감 — 실시간 응답 서비스

깊이 양보 · 속도/비용 확보

왜 Medium이 대부분인가

품질과 속도의 균형점

High만큼 공들이진 않지만, Low처럼 대충 하지도 않음

”굳이 High로 시작하지 마세요. Medium부터” — 이것도 과잉 방지

확장 사고를 사용하지 않는 경우


client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8192,
    thinking={"type": "disabled"},
    output_config={"effort": "low"},
    messages=[{"role": "user", "content": "..."}],
)

thinking disabled · effort low

”깊이 생각하지 마 · 공 들이지 마”

속도를 최대로 뽑는 설정

확장 사고를 사용하는 경우

코딩 사용 사례


client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=16384,
    thinking={"type": "enabled", "budget_tokens": 16384},
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "..."}],
)

코딩 워크로드

thinking enabled · budget 16384

effort medium · 논리 따져야 하니 사고 켜고, 실무 수준으로

두 탭의 메시지

”같은 모델이라도 — 용도별로 기본값을 조절하라”

사고를 켜고 끄는 게 아니라 — 사고의 높이를 용도에 맞춰 조정
14강 수정자 프레이밍의 연장선

같음

개발자 vs 직장인 — 도구는 달라도 목표는 같다

개발자: API 매개변수 (effort/thinking/budget_tokens)

직장인: 프롬프트 한 줄 (“간결하게”, “상세하게”)

공통: 새 모델 기본값에 맞춰 원하는 수준 지정

섹션 전환 — 파트 3

적응형 사고 (Adaptive Thinking)

thinking: adaptive — disabled도 enabled도 아닌 제3의 값

단어

Adaptive = 적응하는 · 상황에 따라 변하는

어원: ad(향하여) + apt(맞는) — “상황에 맞게 조절”

오늘의 단어 Migration과 같은 어감 — 환경에 맞춰 바꾸는 것

기존 방식 vs 적응형

❌ 기존: 개발자가 고정된 값을 미리 지정

✅ 적응형: AI가 요청 난이도를 보고 스스로 조절

쉬운 건 빨리, 어려운 건 깊이

적응형 사고를 시도해야 할 때

워크로드	설명	권장 노력
자율 다단계 에이전트	코딩 에이전트, 데이터 분석, 버그 찾기	high
컴퓨터 사용 에이전트	최고 수준의 정확도 달성	high
이모드 워크로드	쉬운 + 어려운 작업 혼합	medium~high

적응형 사고 권장 워크로드 3

① 자율 다단계 에이전트 — high

② 컴퓨터 사용 에이전트 — high

③ 이모드(이질) 워크로드 — medium~high

공통점: 요청마다 난이도 편차가 큰 작업

① 자율 다단계 에이전트

13강의 그 에이전트

한 세션에 쉬운 코드 수정과 복잡한 아키텍처 결정이 섞임

매번 난이도가 들쭉날쭉 → adaptive 필요

② 컴퓨터 사용 에이전트

마우스·키보드·브라우저 직접 조작

한 번 잘못 클릭하면 복구 어려움 → 최고 수준의 정확도

쉬운 단계엔 빠르게, 중요 결정 단계엔 깊이

③ 이모드(heterogeneous) 워크로드

쉬운 작업 + 어려운 작업이 섞여 오는 시스템

고객 문의 봇 예: “영업시간?” vs “해지·환불 절차?”

같은 시스템이 — 각 문의에 맞는 사고량을 씀


client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

핵심 한 줄

thinking: adaptive

max_tokens 64000 — 복잡한 순간엔 깊이, 쉬운 순간엔 짧게

섹션 전환 — 파트 4

실전 체크리스트: 점검 3단계

① 테스트 → ② 과잉/부족 체크 → ③ 원칙 재확인

기존 프롬프트 그대로 테스트

새 모델이 나오면 — 아무것도 바꾸지 말고 그대로 넣어보기

결과가 어떻게 달라졌는지 확인 → 이상한 지점 찾기

과잉/부족 체크

과하면 → “간결하게”, “핵심만” (완화 수정자)

부족하면 → “상세하게”, “구체적인 수치로” (강화 수정자)

14강 수정자 프레이밍을 양방향으로 쓰는 순간

핵심 원칙 재확인

명확하게(3강) · 맥락(4강) · 예시(5강) · 구조 XML(6강) · 역할(7강)

수정자로 안 풀리면 — 원칙 자체로 돌아가세요

3단계는 순환 습관

테스트 → 조절 → 원칙 재확인 → 다시 테스트

습관이 되면 — 어떤 새 모델도 하루 안에 적응시킵니다
마이그레이션에 대한 두려움이 사라집니다

14·15강 한 줄 요약

”기본값을 제어하는 법”

기본값 낮으면 ↑ (14강) · 높으면 ↓ (15강) · 달라지면 적응 (15강 마이그레이션)

세 가지 다 — 같은 원리의 다른 얼굴

절반

AI 기본값 이해 = 프롬프트 엔지니어링의 절반

모델마다 · 버전마다 · 용도마다 기본값이 다름

”내가 원하는 수준 vs 모델 기본값의 차이를 파악하는 것”이 출발점

모델이 바뀌어도 — 질문 하나

”이 모델의 기본값은 어디쯤인가?”

Claude 4.7이든 5.0이든 GPT-6이든 — 이 질문 하나면 됩니다
답을 찾으면 수정자 방향이 자동으로 정해집니다

섹션 전환 — 마지막 파트

16강 여정 회고

OT부터 15강까지 — 한 줄씩 함께 돌아봅니다

0강 OT

”공식문서를 스스로 읽는 힘”

특정 모델 사용법이 아니라 — 관점을 기르는 강의
매 강의마다 공식문서 원문 · 단어 해부 · 의도 추론 (가추법)

1-2강 — 개요와 첫 프롬프트

1강: 프롬프트 엔지니어링의 큰 그림

2강: 첫 초안 프롬프트 쓰기

”일단 첫 초안부터 써라” — Ch.1로 가는 다리

3-9강 Ch.1 일반 원칙 — 7개 키워드

3강 명확·직접 — 기억상실 천재 신입사원

4강 맥락 — 배경·목적·제약

5강 예시 — Few-shot / Zero-shot

6강 XML 태그 — 구조화된 지시

7강 역할 부여 — 관점 고정

8강 긴 컨텍스트 — 문서 넘기기

9강 자기 인식 — 모델이 한계를 말하게

10강 Ch.2 — 출력과 형식

”뭘 해줘” → “어떤 형태로 해줘”

JSON · 마크다운 · 표 — 원하는 형태를 직접 지정

11강 Ch.3 — 도구 사용 (Tool Use)

AI가 스스로 손을 뻗게 만들기

검색 · 계산기 · API 호출 — 외부 도구 직접 호출

12강 Ch.4 — 사고와 추론

Extended Thinking — 답 내기 전에 스스로 생각

오늘 15강의 thinking: adaptive가 이 챕터의 확장판

13강 Ch.5 — 에이전트 시스템

생각 · 행동 · 점검 루프 + 가드레일

14강 시작 때 언급한 “큰 그림”이 바로 이 챕터

14-15강 Ch.6 — 기능별 팁 & 마이그레이션

14강: 수정자 프레이밍 · AI 슬롭 방지 · 비전 팁

15강: 과잉 방지 · Sonnet 4.6 · 적응형 사고 · 점검 3단계

결과물의 품질을 조절하는 법 + 모델 변화 대응

16강 관통 원칙

명확하게 · 구체적으로 · 구조적으로 — 전달하라

모호하지 않게 · 두루뭉술하지 않게 · 뒤죽박죽이지 않게
이 세 단어만 기억하셔도 — 강의를 가져가신 것

OT 약속 회수

”공식문서를 스스로 읽는 힘 — 드리겠습니다”

단어 해부 · 의도 추론 · 수정자 프레이밍 · 기본값 제어

지금 전부 되시잖아요 — 약속 지켰어요

OT에서의 약속 — 회수

OT에서 드린 약속이 하나 있었습니다. “이 강의는 특정 모델의 사용법을 가르치는 강의가 아닙니다. 공식문서를 스스로 읽는 힘을 기르는 강의입니다.” 15강을 마치는 지금, 여러분은 앤트로픽 공식문서를 펴서 단어를 해부하고, 의도를 추론하고, 수정자 프레이밍과 기본값 제어를 스스로 적용할 수 있습니다. 약속을 지켰습니다.

앞으로 나올 모든 모델에도 — 같은 눈

Claude 4.7 · 5.0 · GPT-6 · Gemini 3 — 어떤 모델이 나와도

”기본값은 어디?” “의도는?” “왜 이 예시?”

이 질문을 스스로 던질 수 있는 눈이 생긴 것

메타

특정 사용법이 아니라 — 관점

모델은 6개월에 한 번씩 바뀜 · 사용법은 계속 갱신

하지만 관점은 남는다 — 오늘부터 여러분 것

15강 전체 통찰

”변화 속의 불변을 보는 법”

모델은 변합니다 · 기본값도 변합니다

그러나 원칙은 변하지 않습니다 — 명확·구체·구조

마지막 액션

docs.anthropic.com 직접 열어보기

이 강의에서 다룬 내용이 거기 다 있습니다
처음엔 20분 → 한 달 반복이면 5분

감사합니다

진짜 주인공은 — 끝까지 함께 해주신 여러분

16강을 완주하신다는 것 — 쉬운 일이 아닙니다

그 시간을 내어주신 것 — 감사합니다

이제 — 여러분 차례입니다

내일 업무에서 바로 — 수정자 한 줄부터

결과가 달라지는 걸 직접 체감해 보세요

동료에게 하나 공유하는 순간 — 그게 진짜 여러분 것이 됩니다

16강, 여기까지입니다

감사합니다

다시 만나 뵐 그날까지 — 좋은 프롬프트 많이 쓰세요

🎓

15강에 걸쳐 배운 원칙 — 명확하게 지시하는 법, 맥락과 예시를 주는 법, 구조화하는 법, 출력을 제어하는 법, 모델 변화에 대응하는 법 — 은 어떤 모델이 나와도 변하지 않습니다. 이제 어떤 AI의 공식문서든 펼쳐서 “왜 이렇게 바뀌었을까?”를 스스로 추론할 수 있는 눈이 생겼습니다. docs.anthropic.com, 오늘 당장 한 페이지만이라도 직접 열어보세요. 그것이 이 강의의 마지막 과제입니다.