큰 일을 '한 번의 프롬프트'로 끝내려 하면, 프롬프트가 길어지고 요구사항이 서로 충돌하기 시작합니다. 모델은 그 안에서 우선순위를 추측해야 하고, 사용자는 결과를 보고 다시 "아니, 그게 아니라…"를 반복하게 됩니다. 이때 가장 빠른 길은 역설적으로 "한 방"이 아니라 2~4턴으로 설계된 대화형 워크플로입니다.
이 장의 목표는 하나입니다. 큰 과제를 하위 과제로 분해(Chunking/Decomposition)하고, 멀티턴으로 누적 개선하는 진행법을 손에 익히는 것. 그리고 그 핵심은 "대화는 길게"가 아니라 "대화는 짧게, 단계를 분명하게"입니다.
왜 '한 방 프롬프트'가 느리고, 2~4턴이 빠른가
큰 과제는 시작 자체가 어렵습니다. 막연한 두려움과 과부하가 생기면 뇌가 멈추는 듯한 'freeze'가 나타나고, 미루기가 쉬워집니다. 이때 과제를 아주 작은 행동 단위(마이크로 스텝)로 나누면 시작 저항이 급격히 줄고, 작은 완료가 다음 행동을 부르는 추진력을 만듭니다.1
프롬프트에서도 똑같은 일이 벌어집니다.
한 번에 "좋은 기획서"를 요청하면, 모델은 목표/대상/톤/분량/근거/형식을 한꺼번에 만족해야 합니다. 요구사항이 많을수록 누락과 왜곡이 늘어납니다.
반대로 "요구사항을 확정 → 뼈대(아웃라인) → 초안 → 점검/수정"처럼 단계를 분리하면, 각 턴의 난도가 낮아지고 검토 지점이 생깁니다. 잘못된 방향을 초기에 바로잡을 수 있어 전체 시간이 줄어듭니다.
심리학 관점에서 말하면, 분해(Decomposition)는 압도감을 줄이고, 더 자주 '완료 체크'를 만들며, 중간에 막히면 쉬운 가지부터 시작할 여유를 줍니다.2 작업 관점에서는 "큰 실패 1번" 대신 "작은 검증 3번"으로 리스크를 낮춥니다.
대화형 워크플로의 기본 원리: '상태'를 나눠 관리한다
멀티턴 프롬프트의 강점은 상태(state)를 누적한다는 점입니다. 중요한 건 상태를 아무렇게나 쌓는 게 아니라, 다음 두 층으로 나눠 관리하는 것입니다.
첫째, 고정 지침(변하지 않는 것)입니다. 역할, 금지사항, 출력 형식처럼 대화 내내 유지되어야 하는 규칙을 말합니다.
둘째, 가변 맥락(매 턴 바뀌는 것)입니다. 방금 나온 초안, 추가 자료, 사용자의 피드백, 새로 확정된 요구사항이 여기에 들어갑니다.
멀티턴 시스템은 매번 "대화 히스토리 + 새 지시"를 함께 넣어 답을 만드는데, 이때 각 턴이 맡은 일이 명확할수록 더 안정적으로 누적됩니다.18
2~4턴 설계: 가장 많이 쓰는 4가지 패턴
여기서 말하는 '턴'은 대화 횟수이지만, 실제로는 단계(phase)에 가깝습니다. 아래 패턴은 가장 자주 쓰이고, 실패율이 낮습니다.
패턴 A: 2턴(요구사항 확정 → 결과물)
간단하지만 강력합니다. 첫 턴을 "질문/정의"에 쓰고, 둘째 턴을 "생성"에 씁니다.
Turn 1 (요구사항 확정)
당신은 [역할]입니다.
내 목표는 [목표]입니다.
먼저 결과물을 만들지 말고, 아래를 위해 확인 질문 5개만 해주세요.
- 대상/상황
- 성공 기준
- 포함해야 할 핵심
- 제외해야 할 것
- 원하는 출력 형식
질문은 번호로만.Turn 2 (생성)
좋아요. 지금 답한 내용으로
- 형식: [예: 마크다운]
- 길이: [예: 800~1200자]
- 톤: [예: 담백하고 단정]
을 지켜서 최종 결과물을 작성해주세요.이 패턴은 "애매함 제거(4장)"를 대화로 수행하는 방식이라고 이해하면 쉽습니다.
패턴 B: 3턴(분해 → 뼈대 → 초안)
큰 과제에서 가장 추천하는 기본형입니다.
1턴에서 분해하고, 2턴에서 뼈대를 승인받고, 3턴에서 초안을 씁니다. 이때 2턴의 승인 과정이 전체 품질을 크게 올립니다.
Turn 1: 작업 분해(Chunking)
[최종 산출물]을 만들고 싶습니다.
먼저 이 일을 10~15개의 하위 과제로 분해해 주세요.
조건:
- 각 과제는 '완료 기준(Definition of Done)'을 한 줄로 포함
- 의존관계가 있으면 표시
- 우선순위 추천(상/중/하)작업 분해가 효과적인 이유는 큰 과제가 위협처럼 느껴질 때 생기는 멈춤을 줄이고, '작게 시작'할 수 있게 해주기 때문입니다.1
Turn 2: 뼈대(Outline) 승인
좋습니다. 위 하위 과제를 바탕으로 최종 문서의 목차(대제목/소제목)를 제안해 주세요.
- 독자는 [대상]
- 문서 목적은 [목적]
- 분량은 [분량]
목차만 제시하고, 아직 본문은 쓰지 마세요.Turn 3: 초안 작성
이 목차로 초안을 작성해 주세요.
추가 제약:
- [문체/형식]
- [금지사항]
- [필수 포함]패턴 C: 4턴(분해 → 초안 → 점검 → 리비전)
3턴에서 끝내지 말고, 검수 전용 턴을 하나 더 둡니다. 실무에서는 이 4턴이 "재작업 시간을 줄이는 지름길"이 되는 경우가 많습니다.
Turn 1: 분해(체크리스트)
Turn 2: 초안 생성
Turn 3: 점검(사실/요건/형식)
Turn 4: 반영 리비전
특히 Turn 3은 단순한 "더 잘 써줘"가 아니라, 검수 기준을 고정하면 강해집니다. 멀티턴 설계에서 흔히 쓰는 점검 축은 다음처럼 3가지로 잡을 수 있습니다.18
사실/근거 점검: 근거 없는 단정, 출처 불명 주장, 숫자 오류
요구사항/누락 점검: 반드시 포함해야 할 항목 누락, 범위 이탈
형식/톤 점검: 스키마, 길이, 문체, 금지어
패턴 D: '간단 버전 먼저'(MVP → 확장)
분해(Decomposition)의 중요한 요령 중 하나는 가장 단순한 버전으로 먼저 테스트하는 것입니다.2 프롬프트도 마찬가지입니다.
먼저 "가장 짧은 형태의 결과물(핵심만)"을 만든 뒤
그 결과를 바탕으로 확장(근거 추가, 예시 추가, 표/스키마화, 톤 변경)
이 방식은 처음부터 완벽을 요구하지 않기 때문에 방향 오류를 빨리 발견합니다.
Chunking을 프롬프트로 구현하는 6가지 기술
'대화형'이라고 해서 반드시 긴 대화를 뜻하지 않습니다. 핵심은 쪼개는 기준입니다.
1) "무엇(What)"을 먼저 고정하고, "어떻게(How)"는 나중에
분해를 잘하려면 먼저 "무엇을 만들지"가 선명해야 합니다.2 프롬프트 첫 턴에서는 해결책을 강요하기보다, 산출물의 정의부터 고정하세요.
나쁜 예: "이 주제로 보고서 잘 써줘. 논리적으로."
좋은 예: "목표는 A, 독자는 B, 결론은 C로 설득하는 2페이지 보고서."
2) 트리 구조로 쪼개기(큰 가지 → 작은 가지)
프로젝트를 '나무'로 상상하면 분해가 쉬워집니다.2 대제목(큰 가지)부터 잡고, 그 아래에 소제목과 작업을 붙이세요. 모델에게도 "트리로 제시"를 요청하면 구조가 깨질 확률이 줄어듭니다.
3) 전처리(Preprocessing)로 바닥을 쓸고 시작하기
분해가 잘 안 되는 이유는 "장애물"이 섞여 있기 때문입니다. 어떤 일을 하기 전에 먼저 방해 요소를 치우는 전처리가 도움이 됩니다.2 예를 들어 글쓰기라면, 자료를 한곳에 모으고 용어를 정의하는 단계가 전처리입니다.
4) 의존관계(Dependency)를 표시하게 하기
실무 과제는 선후관계가 있습니다. 의존관계를 무시하면 병목과 재작업이 늘어납니다.3 분해를 시킬 때 "선행 조건/후행 작업"을 표시하게 하세요.
5) '부끄러울 만큼 작은' 첫 행동을 만들기
Chunking의 목적은 "멋진 계획"이 아니라 "즉시 착수"입니다. 첫 단계는 작을수록 좋습니다.1
예를 들어 "시장 조사"가 아니라 "검색 키워드 5개 만들기"처럼 시작점을 줄입니다.
6) 시간 상자(Timebox)를 붙여서 과제를 작게 유지하기
하위 과제는 10~30분 같은 시간 단위로 끊을수록 실행 가능성이 높아집니다.7 프롬프트에도 "각 하위 과제는 15분 내 완료 가능해야 함" 같은 조건을 붙이면 과도한 덩어리가 줄어듭니다.
실전: '2~4턴 설계' 템플릿 모음
아래 템플릿은 그대로 복사해 써도 되도록 구성했습니다. (대괄호만 채우세요.)
템플릿 1) 문서 작성(기획서/보고서/제안서)
Turn 1: 요구사항 질문
당신은 문서 기획 전문가입니다.
내가 만들 문서는 [문서 종류]이고, 목표는 [목표]이며, 독자는 [독자]입니다.
먼저 본문을 쓰지 말고 확인 질문 7개만 해주세요.
질문은 (1)~(7)로, 한 줄 질문만.Turn 2: 목차 승인
좋아요. 내 답변을 반영해 목차를 제안해 주세요.
- 목차는 H2/H3 수준까지
- 각 항목 옆에 '포함할 핵심 1줄'
목차만.Turn 3: 초안
확정한 목차로 초안을 작성해 주세요.
제약:
- 톤: [예: 간결, 단정]
- 분량: [예: A4 2p]
- 형식: [예: 마크다운]Turn 4: 점검 및 리비전
초안을 아래 체크리스트로 점검하고, 수정안을 내주세요.
체크리스트:
1) 독자에게 필요한 전제/용어가 빠지지 않았나
2) 주장-근거-예시 연결이 끊긴 곳은 없는가
3) 요청한 분량/형식을 준수했는가
출력은 '문제점 목록' 후 '수정본' 순서.템플릿 2) 코드/자동화(작은 도구, 스크립트)
코딩은 특히 "한 파일에 다 넣기"보다 모듈로 나누는 흐름이 유지보수에 유리합니다. 실제 개발에서도 기능 의존 트리를 따라 바닥부터 쌓아 올리는 방식이 가독성/테스트/재사용을 높인다고 설명됩니다.11
Turn 1: 기능 분해 + 인터페이스
[문제/기능]을 구현하고 싶습니다.
먼저 함수를 5~8개로 분해해 주세요.
- 각 함수: 이름, 입력, 출력, 책임(1문장)
- 의존관계(어느 함수가 어느 함수를 호출)
- 가장 작은 테스트 케이스 3개
코드는 아직 작성하지 마세요.Turn 2: 핵심 함수부터 구현
가장 하위(leaf) 함수부터 구현해 주세요.
조건:
- 테스트 가능한 순수 함수 우선
- 주석으로 간단한 테스트 예시 포함Turn 3: 조립(상위 함수 구현)
이제 상위 함수를 구현해서 전체 흐름을 연결해 주세요.
- 이미 만든 함수를 재사용
- 중복 로직 금지
- 에러 처리 정책: [정책]Turn 4: 리뷰(버그/엣지/리팩터링)
아래 관점으로 코드 리뷰 후 개선안을 반영해 주세요.
1) 엣지 케이스 누락
2) 함수 책임 과대/중복
3) 테스트 추가
출력: 리뷰 요약 → 수정된 전체 코드.템플릿 3) 회의/워크숍 설계(팀 작업)
교육 현장에서는 큰 과제를 던진 뒤, 이해를 맞추고, 타임라인을 만들고, 역할을 정하는 절차가 중요하다고 말합니다.4 팀 회의도 동일합니다.
Turn 1: 목표/제약 수집 질문
[회의/워크숍]을 설계하려고 합니다.
목표는 [목표]이고 참석자는 [구성]이며 시간은 [총 시간]입니다.
진행안을 만들기 전에 확인 질문 6개만 해주세요.
(예: 결정해야 할 것, 사전자료, 금지 주제, 산출물 형태)Turn 2: 아젠다 초안
좋아요. 아젠다를 시간표 형태로 제안해 주세요.
- 각 세션: 목적, 진행 방식, 산출물
- 마지막 10분은 회고/다음 액션Turn 3: 리스크/대응 플랜
이 진행안에서 흔한 실패(시간 초과, 말 많은 사람 편중 등)를 5개 예측하고,
각 실패에 대한 진행자 멘트/대응을 써 주세요.멀티턴을 '워크플로'로 굳히는 체크포인트 설계
대화가 길어질수록 흔히 발생하는 문제는 "방향이 흐려짐"입니다. 이를 막는 가장 쉬운 방법은 중간 산출물(artifact)을 만들고, 매 턴마다 그 산출물을 기준으로 다음 턴을 여는 것입니다.
체크포인트 1: 결정 사항 로그(Decision Log)
Turn 1이 끝나면, 모델에게 "결정 사항을 5줄로 요약"하게 하세요.
방금 대화에서 확정된 요구사항을 '결정 사항 로그'로 5줄 요약해 주세요.
형식:
- 목표:
- 독자:
- 포함:
- 제외:
- 형식/길이:이 로그는 다음 턴에서 "이 로그를 기준으로…"라고 재사용하면 흔들림이 크게 줄어듭니다.18
체크포인트 2: 완료 기준(Definition of Done)
분해된 하위 과제마다 "무엇이 되면 끝인가"를 한 줄로 붙이면 실행과 검수가 쉬워집니다.3
예:
"서론 작성"이 아니라 "서론에 문제정의 2문장 + 독자 이득 1문장 포함"
체크포인트 3: 검수 턴을 '별도 역할'로 분리
초안을 만든 모델에게 "검수자 역할로 바꿔서" 평가하게 하면, 생성 편향이 줄어듭니다. (9장에서 더 깊게 다룹니다.)
예시: '한 방 프롬프트' vs '3턴' 비교
주제: 사내 공지 메일(정책 변경 안내)
한 방 프롬프트(실패하기 쉬움)
재택근무 정책이 바뀌었는데 직원들에게 공지 메일을 잘 써줘.
친절하고 설득력 있게.대개 이런 요청은 정보가 비어 있어서, 모델이 정책 내용을 상상하거나(위험), 너무 일반적인 문장을 늘어놓습니다.
3턴 워크플로(짧고 빠름)
Turn 1 (정보 수집 질문)
공지 메일을 쓰기 전에 확인 질문 6개만 해줘.
(변경 전/후 핵심, 시행일, 예외, 문의 채널, 톤, 분량)Turn 2 (구조 승인)
좋아. 위 답변을 바탕으로 메일 구조(제목 후보 3개 + 본문 섹션 4개)를 제안해줘.
아직 본문은 쓰지 마.Turn 3 (최종 작성 + 체크)
이 구조로 최종 메일을 작성해줘.
마지막에 '오해 소지 점검' 3개를 스스로 체크하고 문장도 함께 고쳐줘.3턴은 길어 보이지만, 실제로는 되돌림(재작성) 비용을 줄여 총 시간을 단축합니다. 반복 프로세스가 위험을 낮추고 피드백 기반으로 개선한다는 설명과 같은 맥락입니다.13
자주 터지는 문제 5가지와 해결법
1) 분해가 "과하게" 상세해서 더 막막해진다
하위 과제가 너무 많으면 또 다른 '벽'이 됩니다. 이런 경우에는 "다음 3개만 보여줘"로 해결합니다.
좋아. 전체 계획은 유지하되,
지금 당장 실행할 '다음 3개 하위 과제'만 보여줘.
각 과제는 15분 내로 끝나야 해.2) 모델이 중간에 목표를 바꾼다(범위가 미끄러짐)
Turn 2(목차 승인)에서 목표/독자/금지를 다시 고정하세요.
결정 사항 로그를 다시 붙일게.
[로그 붙여넣기]
이 범위를 벗어나는 제안은 하지 말고, 모호하면 질문 2개만 해.반복 프로세스에서 범위 변동(scope creep)이 대표적 위험으로 언급되는 것처럼,15 멀티턴에서도 범위는 매 턴 관리해야 합니다.
3) 초안이 그럴듯하지만 근거가 약하다
검수 턴을 두고 "근거 없는 문장 표시"를 시키세요.
초안에서 근거 없이 단정한 문장을 모두 표시하고,
- 필요한 근거 유형(통계/사례/정의/규정)을 제안한 뒤
- 근거를 넣을 자리를 [근거 필요]로 표기해 다시 써줘.4) 모델이 질문을 너무 많이 한다
질문 수를 제한하고, 모르면 가정하되 가정을 표시하게 합니다.
확인 질문은 최대 3개만.
나머지는 합리적 가정을 하되, 문장 끝에 (가정)이라고 표시해.5) 대화가 길어져 컨텍스트가 지저분해진다
요약 턴을 한 번 넣어 컨텍스트를 압축하세요.
지금까지의 대화를
1) 확정 요구사항
2) 미확정/리스크
3) 다음 행동 3개
로 10줄 이내 요약해줘.
이 요약을 기준 컨텍스트로 삼아 다음을 진행하자.오늘부터 쓰는 '2~4턴 설계' 미니 연습
연습 1: 당신의 업무를 10분짜리 조각으로 쪼개기
아무 과제나 하나를 고르고, 모델에게 이렇게 요청해 보세요.
내 과제는: [과제]
이걸 10분짜리 하위 과제로 12개로 쪼개줘.
각 항목에 '완료 기준' 1줄을 붙여줘.작게 쪼개면 시작 저항이 낮아지고, 작은 성공이 다음 행동의 동력이 됩니다.1
연습 2: 3턴으로 결과를 '승인'하며 만들기
1턴은 질문, 2턴은 목차, 3턴은 초안. 이 리듬만 익혀도 '한 방 프롬프트'의 재작업이 크게 줄어듭니다.
정리: 빠른 사람은 '대화 길이'가 아니라 '단계'를 설계한다
대화형 워크플로는 말을 많이 하는 기술이 아니라, 일을 작게 만들고(Chunking), 짧은 사이클로 점검하며(Iterative), 중간 산출물을 기준으로 누적하는 기술입니다.11318
한 번에 완벽한 프롬프트를 쓰려 애쓰지 말고, 다음 중 하나만 선택해도 충분합니다.
2턴: 질문으로 요구사항을 확정하고 바로 생성
3턴: 분해 → 목차 승인 → 초안
4턴: 초안 뒤에 검수 턴을 넣어 리비전까지
다음 장에서는 이 흐름의 마지막 고리, 즉 피드백과 리비전을 '동료처럼' 시키는 구체적 대화법을 다룹니다.
참고
1Why Your Brain Freezes on Big Tasks (And the Simple Method That Fixes It)
2Your Guide to Breaking Projects Into Manageable Chunks
3How to break down tasks into manageable pieces
4Teaching Students to Use Chunking to Tackle Complex Problems
7The Chunking Method: When a Task Feels Too Big to Start
11CodeFlowBench: A Multi-turn, Iterative Benchmark for Complex Code Generation
15The iterative process: A complete guide with examples 2026
18Multi turn prompts explained: enhancing AI conversations and workflows
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.