■ decomposition 단위 정하기

한 프롬프트 vs 과제별 호출1.5 본편

표시가 없는 문장은 공식 문서에서 확인한 내용이에요. 다른 표시는 읽는 법

왜 배우나 — 시험이 요구하는 것

시험 목표 1.5 복잡한 문제 쪼개기 · D1 설계 17%
Apply decomposition techniques for complex problem solving

이 개념으로 푸는 판단 (할 수 있어야 하는 것)

1.5② 한 프롬프트에 다 시킬까, 나눠 시킬까? — 분해 단위 정하기 (단일 프롬프트 vs 과제별 호출)
2.3② 여러 단계 추론이 필요하다 — "step by step" 문구? thinking? 체이닝? — CoT(한 요청 안에서 사고) vs 프롬프트 체이닝(여러 호출로 쪼개기)

한눈에

복잡한 일을 "과제" 로 쪼갠다. 과제는 설계·평가의 기본 단위라 먼저 쪼갠다. 호출까지 나눌지는 따로 정한다

공식 고객지원 예 : 대화를 과제 4개로 쪼개 과제마다 프롬프트 부분을 쓴다. 그 부분들을 하나의 문자열로 합쳐 한 프롬프트로 쓴다. 견적은 도구 하나로 계산한다

비유 헬스체크와 같다. 하나로 뭉치면 어디가 깨졌는지 안 보인다. 그래서 구성요소별로 나눠 본다. 그렇다고 구성요소마다 서버를 따로 띄우지는 않는다

대화를 인사·상품 정보·주제 유지·견적 과제로 쪼개 과제마다 평가하되, 프롬프트 부분들은 문자열 하나로 합쳐 한 프롬프트로 쓰고 견적은 도구로 계산한다는 그림. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

ELI5

숙제 공책 한 권에 과목별로 칸을 나눠 쓰는 것과, 과목마다 공책을 따로 사는 것의 차이예요.

먼저 과목(할 일)을 다 적어 봐야 빠진 과목이 안 생겨요.
대부분은 공책 한 권에 칸만 나눠도 충분해요.
한 과목만 자꾸 틀리면, 그 과목 칸을 먼저 고쳐 봐요.
칸으로 안 될 때만 공책을 따로 사요. 공책이 늘면 들고 다니기 무거워요.

개념 설명

영상 — 제약을 자꾸 어기면 호출을 어떻게 할까? (약 43초 · 소리 없음 · 자막). 6번 보낸 결과(어김 2/6 · 고친 뒤 0/6)와 기다림 칸 길이(호출 1번 = 1칸)는 그림용 가정 작은 화면에서는 전체화면(⛶)으로 보세요.

원리

과제 쪼개기는 설계·평가 단위다

고객지원 대화 한 번 안에는 질문 답변 · 정보 찾기 · 요청 처리 같은 서로 다른 과제가 묶여 있다.
만들기 전에 이상적인 대화를 과제로 다 쪼갠다. 그러면 과제마다 프롬프트를 쓰고 평가할 수 있다. 테스트 케이스 범위도 보인다.
공식 예는 쪼갠 과제마다 프롬프트 부분을 따로 쓴 뒤, 하나의 문자열로 합쳐 한 프롬프트로 쓴다. 견적 계산은 도구 하나에 맡긴다. 즉 과제 decomposition(분해)과 호출 decomposition 은 다르다.

호출 쪼개기는 조건이 있을 때만 한다

고려할 점이 여럿이면 관점마다 따로 호출해 각 측면에 집중하게 한다 (나눠 돌리기).
가드레일 : 답하는 인스턴스와 검사하는 인스턴스를 나누면, 한 호출이 둘 다 할 때보다 낫다.
긴 프롬프트에서 일부 제약을 계속 무시하면 "생성한 뒤 고치기" 2단계로 나눈다 (Skilljar).
중간 출력을 검사하거나 파이프라인 구조를 강제해야 하면 명시적 체이닝을 쓴다.
그 밖의 다단계 추론(reasoning)은 최신 모델이 adaptive thinking·서브에이전트로 한 요청 안에서 대부분 처리한다.

나누는 대가

체이닝은 지연(latency)을 감수하고 정확도를 얻는 trade-off(절충)다. 의도 분류기는 Claude 호출이 1번 더 든다. 그래서 지연이 늘어난다.
여러 프롬프트로 나눈 대화 흐름이면 지연 최적화 쪽 모델도 검토하라는 공식 문장이 있다.

층을 더하는 순서

아래 순서로 간다.
- 프롬프트 엔지니어링
- 도구 추가(프롬프트 체인까지)
- 과제가 아주 다양할 때만 의도 분류기 + 전문 대화

핵심 질문 두 개

지금 틀리는 게 어느 과제인지 보이나? (안 보이면 먼저 과제로 쪼개 평가한다)
그 과제가 틀리는 이유가 "한 호출이 여러 걸 저울질해서" 인가? (그렇다면 호출을 나눈다)

규칙과 판단

고려할 점이 여럿이면 점마다 따로, 답과 검사를 한 호출이 하면 분리, 제약을 계속 무시하면 생성→고치기, 중간 검사·구조 강제면 명시적 체이닝, 해당 없으면 한 프롬프트. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

갈림길

①② 먼저 과제로 [1.5②]

과제 목록이 있나?인사·상품 정보·주제 유지·견적

없다

과제로 쪼갠다

과제마다 프롬프트를 쓰고 평가한다. 테스트 케이스 범위를 잡는다

있다

↓ 아래 「호출을 나눌까」 갈림길로 이어짐

다음 물음 — 무엇이 보이나?

③④ 호출을 나눌까 [1.5②] [2.3②]

무엇이 보이나?

고려할 점이 여럿이다

관점마다 따로 호출

관점마다 따로 호출해 각 측면에 집중한다 (나눠 돌리기)

답과 검사를 한 호출이 다 한다

답·검사 분리

한 인스턴스는 답하고, 다른 인스턴스는 검사한다

일부 제약을 계속 무시

생성한 뒤 고치기

2단계 체이닝을 쓴다 (Skilljar)

중간 출력 검사 · 구조 강제

명시적 체이닝

지연(latency)을 감수하고 정확도를 얻는다

해당하는 것이 없다

한 프롬프트

그 밖의 다단계 추론(reasoning)은 최신 모델이 한 요청 안에서 대부분 처리한다

⑤ 층을 더할까 [1.5②]

프롬프트·도구로 해 봤나?

아니오

프롬프트 먼저

프롬프트 엔지니어링을 먼저 한다

프롬프트만 해 봤다

도구 추가

도구를 추가한다(프롬프트 체인까지)

예, 과제가 아주 다양하다

의도 분류기

갈래마다 자기 도구·시스템 프롬프트를 둔다. Claude 호출이 1번 더 들어 지연이 늘어난다

예, 과제는 몇 가지다

↑ 위 「호출을 나눌까」 갈림길로 이어짐

다음 물음 — 무엇이 보이나?

흐름

그림 속 이름·금액·시간·토큰 수는 예시예요. 공식 한도·동작은 카드 본문 값이 기준.

장면 글로 보기

칸 : 과제 → 프롬프트 → Claude → 출력

질문 : 제약을 자꾸 어기면 호출을 어떻게 할까?

① 과제별 부분을 한 프롬프트로 ✓

시작 : 과제 — 쪽지 : 인사 · 상품 정보 / 주제 유지 · 견적
쪼개기 : 과제 → 프롬프트 : 과제마다 부분을 쓴다 — 쪽지 : ## 인사 / ## 상품 정보 / ## 주제 유지 / ## 견적
합치기 : 프롬프트 → Claude : 하나의 문자열로 합친다 — 쪽지 : system = 부분 4개를 / 이어 붙인 문자열 1개
답 : Claude → 출력 — 말 : “안녕하세요, 자동차 보험 견적을 도와드릴게요.”
평가 : 출력 : 과제마다 평가한다 — 쪽지 : 과제별 채점 / 인사 ✓ · 상품 ✓ / 주제 ✓ · 견적 ✗ → 견적 부분만
끝 : 부분만 고치면 되니 디버깅이 쉽다

② 더 길고 강하게 한 호출 ≠

시작 : 과제 — 쪽지 : 규칙 30줄 / "환불·보상 약속 금지" 포함
몰아넣기 : 프롬프트 → Claude : 지시를 더 길고 강하게 쓴다 — 쪽지 : "절대로 환불을 / 약속하지 마라!!" / 같은 말 3번 반복
출력 : Claude → 출력 : 분명히 적어도 일부를 어긴다 — 말 : “걱정 마세요, 전액 환불해 드릴게요.”
끝 : 긴 프롬프트에서는 일부 제약을 계속 무시한다. 한 호출에 더 몰아도 그대로다

③ 생성한 뒤 고치기 ✓

시작 : 과제 — 쪽지 : 규칙 30줄 / "환불·보상 약속 금지" 포함
1단계 : 프롬프트 → Claude : 생성한다 — 쪽지 : 호출 1 / 답장 초안을 써 줘
초안 : Claude → 출력 — 말 : “걱정 마세요, 전액 환불해 드릴게요.”
2단계 : 출력 → Claude : 고치기 단계를 따로 둔다 — 쪽지 : 호출 2 / 이 초안을 제약 목록에 / 맞춰 고쳐 줘
고침 : Claude → 출력 — 말 : “보상 여부를 확인한 뒤 바로 안내드릴게요.”
끝 : 단계마다 따로 호출한다. 그래서 어느 지점에서든 기록·평가·분기할 수 있다

규칙 원문 ①②③④⑤ (갈림길로 그린 규칙)

①
먼저 이상적인 대화를 Claude 가 할 과제로 모두 쪼갠다. 그리고 과제마다 프롬프트를 쓰고 평가하고, 테스트 케이스 범위를 잡는다. 공식 예의 과제는 넷이다 [1.5②]
- 인사·일반 안내
- 상품 정보
- 대화 관리(주제 유지)
- 견적 생성
쪼갠 과제는 프롬프트 부분(하위 섹션)으로 한 번에 하나씩 쓴다. 그러면 부분만 고치면 되니 디버깅이 쉽다. 다 쓰면 하나의 문자열로 합쳐 한 프롬프트로 쓴다 [1.5②]

호출을 나누는 때 [1.5②] [2.3②]

보이는 것	나누는 법
고려할 점이 여럿인 복잡한 일	관점마다 따로 호출한다. 각 측면에 집중한다 (나눠 돌리기)
답과 검사를 한 호출이 다 한다 (가드레일)	한 인스턴스는 답하고, 다른 인스턴스는 검사한다. 한 호출이 둘 다 할 때보다 낫다
긴 프롬프트에서 일부 제약을 계속 무시한다	생성한 뒤 고치는 2단계 체이닝 (Skilljar)
중간 출력을 검사해야 한다 · 파이프라인 구조를 강제해야 한다	명시적 체이닝

그 밖의 다단계 추론은 최신 모델이 adaptive thinking·서브에이전트로 한 요청 안에서 대부분 처리한다

가장 흔한 체이닝은 자기 교정이다. 초안을 쓰고, 기준으로 검토하고, 고친다. 단계마다 따로 호출이라 어느 지점에서든 기록·평가·분기할 수 있다

여러 갈래가 같은 중간 산출물(장면 경계·항목 목록)을 똑같이 써야 하면, 그것을 먼저 한 단계로 만든다. 그 결과를 나눠 돌리기 갈래마다 같게 넘긴다. "도착하자마자 전부 병렬" 이면 갈래마다 경계가 달라진다. 이 조합은 이 카드의 해석이다. 공식은 패턴을 섞어 쓴다는 것이다

④
나누면 대가를 낸다 [1.5②]
- 체이닝은 지연을 감수하고 정확도를 얻는다
- 의도 분류기는 Claude 호출이 1번 더 든다. 그래서 지연이 늘어난다
- 여러 프롬프트로 나눈 대화 흐름은 지연 최적화 쪽 모델(공식 예 Haiku 4.5)도 검토한다
⑤
층을 더하기 전에 : 아래 순서로 간다 [1.5②]
- 프롬프트 엔지니어링을 먼저 한다
- 도구를 추가한다(프롬프트 체인까지)
- 그래도 과제가 아주 다양하면 의도 분류기로 라우팅한다(갈래마다 자기 도구·시스템 프롬프트)
반대쪽 끝(과제마다 에이전트 하나)은 ◆ 단일 vs 멀티 에이전트 에서 다룬다. 나누는 법은 일의 종류가 아니라 컨텍스트 경계다

더 깊이 : 판단 규칙 · 상황 변수 (설명)

판단 규칙

조건	답	근거
새로 만드는 고객지원 Agent 다	이상적인 대화를 과제로 다 쪼갠다. 과제마다 프롬프트를 쓰고 평가한다	customer-support-chat · "break down your ideal customer interaction into every task"
과제별 프롬프트 부분을 다 썼다	하나의 문자열로 합쳐 한 프롬프트로 쓴다	"combine all these sections into a single string"
복잡한 일에 고려할 점이 여럿이다	관점마다 따로 호출한다	building-effective-agents
답과 안전 검사를 같은 호출이 한다	답·검사 인스턴스를 나눈다
긴 프롬프트에서 일부 제약을 계속 무시한다	생성한 뒤 고치는 체이닝을 쓴다	Skilljar 287800
중간 출력 검사 · 파이프라인 구조 강제가 필요하다	명시적 체이닝을 쓴다	prompting-best-practices
위 어느 것도 아니다	한 프롬프트로 둔다 (모델이 내부에서 처리한다)	"Claude handles most multistep reasoning internally"
프롬프트·도구로 다 해 봤고 과제가 아주 다양하다	의도 분류기로 전문 대화에 보낸다 (지연이 늘어난다)

상황 변수

변수	값	답 쪽	근거
어디가 틀리는지	안 보인다	먼저 과제별로 평가한다	판단 규칙 1
틀리는 과제의 성격	계산·조회 (견적 등)	도구로 옮긴다	"견적을 계산하기 위한 하나의 도구로 시작"
틀리는 과제의 성격	여러 기준을 동시에 저울질한다	기준마다 호출한다
제약 준수	일부를 계속 어긴다	고치기 단계를 더한다	Skilljar 287800
사람이 중간 결과를 확인해야 한다	예	명시적 체이닝
지연 예산	빡빡하다	호출 수를 늘리지 않는 쪽이다. 나눴다면 빠른 모델을 검토한다
과제 다양성	아주 다양하다 (서로 다른 도구·시스템 프롬프트가 필요하다)	의도 분류기
과제마다 에이전트를 둘까	순차 단계·공유 맥락	같이 둔다	◆ 단일 vs 멀티 에이전트

연습 문제

자동차 보험 고객지원 Agent 의 한 프롬프트에 규칙이 30줄 있다. 답장이 "환불·보상을 약속하지 마라" 같은 몇몇 제약을 계속 어긴다일부 제약 무시. 팀장은 "그 규칙을 더 길고 강하게 다시 써서 한 호출로 해결하자"고 한다. 무엇을 해야 하나?

시험 대비

함정

"한 프롬프트에 몰아넣었더니 견적이 틀리니 과제별 호출로 나눈다" 는 함정이다. 바로 호출을 나누지 않는다. 과제별로 평가해 어디가 틀리는지 본다. 공식 예는 한 프롬프트를 쓰고, 견적은 도구 하나로 계산한다
"지시를 더 길고 강하게 써서 한 호출로 해결한다" 는 함정이다. 제약을 분명히 적어도 일부를 어긴다. 그래서 고치기 단계를 따로 둔다 (Skilljar)
"과제마다 에이전트를 하나씩 둔다" 는 함정이다. 역할별 decomposition(분해)은 전달 손실(거쳐 갈수록 내용이 빠진다)이 생긴다. 자세한 것은 ◆ 단일 vs 멀티 에이전트 에 있다
"체이닝으로 나누면 더 빠르고 싸다" 는 함정이다. 체이닝은 지연을 감수하고 정확도를 얻는다
"단계가 여러 개면 무조건 체이닝한다" 는 함정이다. 최신 모델은 대부분 한 요청 안에서 처리한다. 명시적 체이닝은 중간 검사·구조 강제일 때 쓴다
"처음부터 의도 분류기와 전문 대화를 둔다" 는 함정이다. 층을 더하기 전에 프롬프트·도구부터 해 본다. 분류기는 과제가 아주 다양할 때 쓰고, 지연이 늘어난다

신호

"For complex tasks with multiple considerations, LLMs generally perform better when each consideration is handled by a separate LLM call, allowing focused attention on each specific aspect."

"Explicit prompt chaining (breaking a task into sequential API calls) is still useful when you need to inspect intermediate outputs or enforce a specific pipeline structure."

"break down your ideal customer interaction into every task you want Claude to be able to perform. This ensures you can prompt and evaluate Claude for every task"

"Now combine all these sections into a single string to use as your prompt."

"Note, this method requires an additional call to Claude that can increase latency."

"Claude consistently ignores some constraints in long prompts" (Skilljar)

보통은 과제로 쪼개 한 프롬프트로 쓰지만, 중간 결과를 사람이 확인하면 체이닝, 과제마다 도구·규칙이 충돌하면 의도 분류기, 견적만 틀리면 그대로 두고 계산만 도구로 옮긴다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게) — 자세한 조건은 아래 '더 깊이'에 있어요

더 깊이 : 뒤집히는 때 · 오답 재료 (설명)

뒤집히는 때

1. 견적이 틀리는데 "호출 분리"가 답이 아닌 때

조건 : 한 프롬프트 고객지원 Agent 에서 견적 금액만 자주 틀린다.
판단 : 공식 예는 견적을 LLM 이 계산하지 않는다. get_quote 도구 하나가 계산한다. 금액이 틀리면 먼저 계산을 도구로 옮긴다. 그리고 과제별 평가(견적 정확도 목표 100%)로 확인한다. 호출을 과제별로 쪼개는 것은 그다음이다.
근거 : customer-support-chat

2. 나눠 놨더니 지연이 문제가 되는 때

조건 : 인사, 분류, 답변, 검사를 호출 4개로 나눴다. 사용자는 채팅 창에서 기다린다.
판단 : 호출마다 지연이 붙는다. 공식 문서는 여러 프롬프트로 된 대화 흐름이면 지연 최적화 쪽 모델(Haiku 4.5)을 검토하라고 한다. 검사처럼 독립인 단계는 병렬로 돌리고, 나머지는 한 프롬프트로 되돌리는 것도 선택지다.
등급 : (방향) · 업계 일반 (어느 단계를 되돌릴지)
근거 : building-effective-agents

3. 한 프롬프트로 두다가 체이닝이 필요해지는 때

조건 : 환불 요청 처리에서 "환불 가능 판정" 결과를 사람이 확인한 뒤에 답장을 보내야 한다는 규정이 생겼다.
판단 : 중간 출력 검사가 요구된다. 그래서 명시적 체이닝을 쓴다(판정 호출, 사람 확인, 답장 호출). 모델이 내부에서 잘 처리하더라도 검사 지점을 만들려면 호출을 나눈다.
근거 : prompting-best-practices

4. 과제가 늘어 의도 분류기가 쓸 만한 때

조건 : 보험 상담에 청구 접수 · 계약 변경 · 해지 방어가 추가됐다. 과제마다 도구 묶음과 규칙이 서로 충돌한다.
판단 : 프롬프트·도구 추가로 버티다가 과제가 "아주 다양" 해지면, 의도 분류기로 전문 대화(각자 도구·시스템 프롬프트)에 보낸다. 호출 1번 더, 즉 지연 증가를 감수할 만큼 충돌이 클 때 쓴다.
등급 : (조건·대가) · 업계 일반 ("충돌"을 기준으로 삼는 부분)

오답 재료

오답	왜 끌리나	왜 틀리나	근거
"지시를 더 길고 강하게 써서 한 호출로"	고치기가 가장 쉬워 보인다	제약을 분명히 적어도 일부를 어긴다. 그래서 고치기 단계를 따로 둔다	Skilljar 287800
"과제마다 에이전트를 하나씩"	과제가 곧 담당자처럼 보인다	역할별 decomposition 은 전달 손실(거쳐 갈수록 내용이 빠진다)이 생긴다. 조율 토큰이 실제 작업보다 많다	◆ 단일 vs 멀티 에이전트
"과제로 쪼갰으니 호출도 과제마다"	쪼갠 단위를 그대로 쓰고 싶다	공식 예는 과제별 부분을 한 프롬프트로 합친다
"체이닝으로 나누면 더 빠르고 싸다"	작은 호출은 빨라 보인다	지연을 감수하고 정확도를 얻는 trade-off 다	building-effective-agents
"단계가 있으면 무조건 체이닝"	단계가 곧 호출처럼 보인다	최신 모델은 대부분 내부에서 처리한다. 체이닝은 중간 검사·구조 강제일 때 쓴다	prompting-best-practices
"처음부터 의도 분류기 + 전문 대화"	깔끔한 아키텍처로 보인다	층을 더하기 전에 프롬프트·도구부터 해 본다. 분류기는 지연이 늘어난다
"견적이 틀리니 견적 전용 LLM 호출을 분리"	틀린 과제를 떼어내면 될 것 같다	계산은 도구가 맡는다. 떼어내도 LLM 이 계산하면 그대로 틀린다

참고

함께 보기

더 깊이 : 출처 · 상태 · 미해결 (참고)

출처

상태

모든 줄을 공식 문서에서 확인

미해결

목록 1.5② 의 "문제 상황"(한 프롬프트에 몰아넣었더니 견적이 틀림)은 정답이 "과제별 호출" 로 읽히게 쓰였다. 하지만 공식 예는 한 프롬프트 + 견적 도구다. 그래서 카드는 공식대로 "과제별 평가 먼저, 계산은 도구" 로 고쳤다.
목록의 운영 비유 "헬스체크 하나 vs 구성요소별 체크" 는 업계 일반 비유다. 카드 비유 줄에만 쓴다.
prompting-best-practices 는 영어판만 받아 두었다(한국어판 파일이 없다). 404줄 내용의 한국어판 대조는 안 했다.
목록 1.5② 의 영어 신호 두 문장은 원문(building-effective-agents · prompting-best-practices)에서 찾았다. 못 찾은 인용은 없다.