프롬프트가 길어질수록 모델이 말을 잘 안 듣는다고요? — 공식 가이드: 하나의 큰 프롬프트에 매달리지 말고, 두 단계로 나누세요.

공식 출처: Anthropic Academy 《Building with the Claude API》 제 47과. 과 페이지에는 발행 날짜가 표기되어 있지 않아 생략합니다. 원문 제목 직역: 《연쇄 작업 흐름(Chaining Workflows)》。먼저 상식에 반하는 결론을 말씀드리겠습니다. 프롬프트를 길게 작성하고 요구사항을 많이 나열할수록 모델은 오히려 말을 잘 듣지 않게 됩니다. 많은 사람들의 첫 반응은 '그럼 요구사항을 더 명확하게 적으면 되지 않을까'입니다. — 오산입니다. 공식 가이드에 따르면, 아무리 요구사항을 명확하게 적어도 소용이 없습니다. Claude에게 기술 기사를 작성하라고 요청하면서 네 가지 요구사항(AI가 쓴 것이 아니라는 점, 이모티콘 사용 금지, 진부한 표현 금지, 전문적인 어조 유지)을 한 번에 제시했음에도 불구하고, 결과물에는 여전히 이모티콘이 포함되거나, AI 작성자임을 언급하거나, 어조가 비전문적일 수 있습니다. 올바른 방법은 두 단계로 나누는 것입니다. 첫 번째 단계에서는 일단 작성하게 하고, 그 불완전함을 받아들입니다. 두 번째 단계에서 전문적으로 수정하도록 요청하여 문제를 하나하나 깨끗하게 다듬습니다.

용어 설명:

• 연쇄 작업 흐름(chaining workflows): 크고 복잡한 작업을 더 작고 순차적인 하위 작업으로 분해하는 워크플로우 패턴 — 한 단계씩, 각 단계는 오직 하나의 일에만 집중합니다.
• 소셜 미디어 마케팅 도구(social media marketing tool): 강의에서 예시로 사용된 애플리케이션 — 비디오를 자동으로 생성하고 게시합니다.
• 장문 프롬프트 문제(the long prompt problem): 강의에서 지적한 결함 — 너무 많은 요구사항을 한 번에 제시하면, Claude가 그중 몇 가지를 위반하는 경향이 있습니다.
• 2단계 연쇄 접근법(two-step chaining approach): 강의에서 제시한 해결책 — 첫 번째 단계에서는 일단 작성하게 하고, 두 번째 단계에서 전문적으로 수정합니다.
• 수정(revision): 연쇄 작업의 두 번째 단계 — 방금 작성된 글을 다시 제출하고, 구체적인 수정 지침을 주어 하나하나 깨끗하게 다듬습니다.
• 진부한 표현(clichéd language): 강의에서 제시한 네 가지 요구사항 중 하나 — 진부하거나 너무 가벼운 언어를 사용하지 않도록 합니다.
• 기술 작가(technical writer): 강의에서 수정 지침의 표준 — 어색한 표현을 기술 작가가 쓸 만한 문장으로 바꿉니다.

실제 예시: 강의에서는 소셜 미디어 마케팅 도구를 예시로 들었습니다. 비디오를 자동으로 생성하고 게시하려면, 하나의 큰 프롬프트에 모든 것을 담아 Claude에게 주제 찾기, 주제 선정, 연구, 스크립트 작성, 비디오 제작, 게시까지 처음부터 끝까지 요청할 수 있습니다. 하지만 공식 가이드는 이렇게 하는 것은 안 된다고 말합니다. 한 번에 오직 하나의 구체적인 임무만 주어야 Claude가 그 일에 집중할 수 있기 때문입니다. 올바른 방법은 여섯 단계로 순차적으로 나누는 것입니다: 먼저 트위터 관련 인기 주제를 찾고, 가장 흥미로운 것을 선정하고, 해당 주제를 연구한 다음, 짧은 비디오 스크립트를 작성하고, AI 가상인과 음성 합성으로 비디오를 만들고, 마지막으로 소셜 미디어에 게시합니다. 더 심각한 예시는 기술 기사 작성입니다. 네 가지 요구사항(AI가 쓴 것이 아니라는 점, 이모티콘 사용 금지, 진부하거나 너무 가벼운 언어 금지, 전문적인 기술 어조 사용)을 한 번에 요청했음에도 불구하고, Claude가 작성한 글은 여전히 몇 가지를 위반할 수 있습니다. 즉, 이모티콘이 포함되거나, AI 작가를 언급하거나, 어조가 비전문적일 수 있습니다. 이때 프롬프트에 매달리지 말고 두 단계로 나누세요: 첫 번째 단계에서는 초기 프롬프트를 보내고, 결과물이 완벽하지 않을 수 있음을 받아들입니다. 두 번째 단계에서 후속 요청을 보내 전문적으로 수정합니다 — 방금 작성된 글을 다시 제출하고 구체적인 수정 지침을 줍니다: '작성자임을 언급하는 부분을 찾아 삭제하라', '모든 이모티콘을 찾아 삭제하라', '어색한 표현을 기술 작가가 쓸 만한 문장으로 바꿔라'. 익숙한 발전 과정 역시 바로 이 경로를 따릅니다. 제1과에서의 단일 요청부터, 제2과에서의 히스토리(history)가 포함된 다중 대화, 제3과에서의 역할 지정 시스템 프롬프트, 제4과에서의 온도 조절, 제5과에서의 스트리밍 출력, 제6과에서의 구조화 데이터, 제7과에서의 프롬프트 평가, 제8과에서의 코드 점수, 제9과에서의 XML 태그, 제10과에서의 예시 제공, 제11과에서의 명확하고 직접적인 방식, 제12과에서의 구체적이고 명확한 방식, 제13과에서의 도구 사용 입문, 제14과에서의 프로젝트 개요, 제15과에서의 도구 함수(tool function), 제16과에서의 도구 패턴(tool pattern), 제17과에서의 메시지 블록 처리, 제18과에서의 도구 결과 반환, 제19과에서의 다중 라운드 도구 대화, 제20과에서의 구현된 다중 라운드, 제21과에서의 여러 도구 사용, 제22과에서의 정교한 도구 호출(fine-grained tool calling), 제23과에서의 텍스트 편집 도구, 제24과에서의 네트워크 검색 도구, 제25과에서의 검색 증강 생성(RAG) 소개, 제26과에서의 텍스트 청크 전략, 제27과에서의 텍스트 임베딩, 제28과에서의 완전한 RAG 프로세스, 제29과에서의 구현된 RAG 프로세스, 제30과에서의 BM25 어휘 검색, 제31과에서의 두 가지 검색 결과를 하나의 통일된 하이브리드 검색으로 병합, 제32과에서의 작성 도구의 작업을 넘겨주기, 제33과에서의 클라이언트가 서버 통신의 복잡성을 어떻게 추상화하는지 살펴보기, 제34과에서의 프로젝트를 먼저 구축하고 두 가지 질문으로 기준선(baseline)을 확인한 후 작업하기, 제35과에서의 데코레이터로 두 개의 도구를 정의하여 SDK가 설명서를 자동으로 생성하게 하기, 제36과에서의 도구 작성 후 검사기(checker)로 하나하나 실행해보고 애플리케이션에 연결하기, 제37과에서의 클라이언트가 또 다른 반쪽의 공학이 되다, 제38과에서의 읽기 전용 데이터는 리소스(resource)를 사용하고 도구를 사용하지 않기, 제39과에서의 리소스를 MIME 유형으로 읽기, 제40과에서의 프롬프트 템플릿은 매번 다시 입력할 필요가 없다, 제41과에서의 클라이언트가 슬래시(/)로 프롬프트를 호출하기, 제42과에서의 도구 서비스 모델, 리소스 서비스 애플리케이션, 프롬프트 서비스 사용자, 제43과에서의 Claude Code

팀원처럼 대하세요: 컨텍스트를 먼저 제공하고, 계획을 세우게 한 다음, 마지막에 코드를 작성하게 하세요. 44강의 Claude Code와 MCP 서버 연결하기: 내장 클라이언트, 3가지 원리 분업, 6가지 기본 통합 기능을 통해 Sentry + Jira + Slack이 하나의 워크플로우를 구성합니다. 45강의 워크플로우와 에이전트(Agent): 프로세스가 다이어그램으로 그려지면 워크플로우로 실행하고, 그릴 수 없다면 에이전트에게 맡기세요. 이미지에서 CAD까지는 평가자-최적화자의 4단계 과정입니다. 46강의 병렬 워크플로우: 하나의 요청을 여러 경로로 분산하여 동시에 평가한 후, 최종적으로 취합하여 결정합니다. 47강의 체인형(Chain) 워크플로우: 큰 작업을 작은 순차적 단계로 나누어 처리합니다. 먼저 작성하고, 깨끗하게 수정하세요. 앞부분은 호출 연결을 확립하고, 출력을 정렬하며, 평가 기능을 구축하고, 프롬프트에 경계를 설정하고, 좋은 형태를 갖추고, 첫 문장을 명확히 하며, 요구사항을 구체화하고, 모델이 데이터를 가져갈 수 있는 문을 열어주고, 프로젝트의 세 가지 약점을 나열하고, 첫 번째 함수를 작성하며, 함수 설명서를 작성하고, 모델이 반환한 패키지는 그대로 보존하고, 도구가 실행한 결과를 모델에게 다시 전달하고, 한 라운드를 다중 라운드로 변경하고, 루프(Loop)를 실제로 구현하고, 4단계에 따라 새로운 도구를 연결하고, 도구 호출을 더 세분화하며, 모델이 파일을 수정할 수 있는 내장 도구를 제공하고, 모델에게 인터넷 접속의 문을 열어주고, 대용량 파일을 청크(Chunk)로 분할하여 가장 관련성 높은 부분만 제공하고, 분할 방식을 명확히 설명하고, '의미'를 숫자로 변환하고, 그 숫자를 비교하는 데 사용하며, 전체 프로세스를 실제로 구현하고, 검색에 원본 단어를 찾는 경로를 추가하고, 두 경로의 결과를 하나의 통일된 혼합 검색으로 병합하며, 도구를 작성하는 작업을 위임하고, 클라이언트가 서버 통신의 복잡성을 어떻게 추상화하는지 확인하고, 먼저 프로젝트 구조를 세우고 두 가지 질문을 통해 기준선(Baseline)을 검증한 후 작업합니다. 데코레이터(Decorator)를 사용하여 두 개의 도구를 정의하면 SDK가 자동으로 설명서를 생성하게 합니다. 도구 작성이 완료되면 검사기(Checker)로 하나씩 실행해 본 다음 애플리케이션에 연결합니다. 클라이언트야말로 또 다른 반쪽의 엔지니어링입니다. 읽기 전용 데이터는 리소스(Resource)를 사용하고 도구를 사용하지 않습니다. 리소스는 MIME 유형별로 읽습니다. 프롬프트 템플릿은 매번 다시 작성할 필요가 없습니다. 클라이언트는 슬래시(/)를 사용하여 프롬프트를 호출합니다. 도구 서비스, 모델 리소스 서비스, 애플리케이션, 프롬프트 서비스, 사용자 순서입니다. Claude Code를 타이피스트가 아닌 팀원처럼 대하고, Claude Code에 MCP 서버를 연결하며, 워크플로우와 에이전트: 프로세스가 다이어그램으로 그려지면 워크플로우로 실행하고, 그릴 수 없다면 에이전트에게 맡기세요. 병렬 워크플로우: 하나의 요청을 여러 경로로 분산하여 동시에 평가한 후, 최종적으로 취합하여 결정합니다. 이 강좌는 체인형 워크플로우입니다: 큰 작업을 작은 순차적 단계로 나누어 처리하며, 먼저 작성하고 깨끗하게 수정하세요.**

반대 적용 조건 목록 — 다음 상황에서는 반드시 체인형 워크플로우로 분할하기 전에 명확히 설명해야 합니다. 이 내용을 읽고 본 강좌를 교리로 오해하는 것을 방지합니다:

• 작업이 단일 요청으로 완료되는 경우: 요구사항이 적고 단계가 적어, 단일 호출만으로 답을 얻을 수 있다면 분할은 불필요합니다.
• 단계 간 선후 관계가 없는 경우: 각 단계가 서로 의존하지 않고 이전 단계의 결과를 기다릴 필요가 없다면, 강제로 순서화하는 것은 오히려 느립니다. 병렬 처리를 사용해야 합니다.
• 첫 번째 결과가 이미 충분히 좋은 경우: 네 가지 요구사항을 한 번에 모두 충족했다면, 더 수정할 필요가 없습니다. 수정을 해도 변화는 없습니다.
• 수정 지시를 작성하기 어려운 경우: AI 작가가 어디인지, 이모지(Emoji)가 어디 있는지, 문장이 어색한 부분이 어디인지 등, 단 하나도 짚어낼 곳이 없다면, 두 번째 단계에서 시작할 수 없습니다. 무엇을 수정해야 하는지 먼저 명확히 적은 후에 체인형 구조를 논의하세요.
• 그 외에, 작업이 복잡하고 요구사항이 많으며 Claude가 항상 몇 가지를 빠뜨리는 경우 — 다음 세 가지 질문을 먼저 하세요: 분리 가능한가? 각 단계가 전문적인가? 수정할 수 있는가? 명확히 묻지 않고 시작하면, 분해한 것이 아무것도 아닌 것과 같습니다.

핵심 요약 문장: 큰 프롬프트로 해결하지 못하는 것은 작은 순차적 단계로 나누어 처리합니다. 처음 작성했을 때 잘 안 되어도 부끄러워할 필요 없습니다. 두 번째 수정본을 만들지 않는 것이 부끄러운 일입니다.

Ⅰ. 실패 사례 목록 (Failure Checklist)

• 하나의 큰 프롬프트로 끝까지 진행하기: 주제 찾기, 주제 선택, 조사, 스크립트 작성, 영상 제작, 배포 등 모든 것을 한 번에 넣으면, 모델은 여섯 가지 일을 동시에 처리하려 하다가 어느 것 하나 제대로 못 합니다.
• 요구사항을 많이 나열할수록 더 안정적이라고 착각하기: 아무리 명확하게 네 가지 요구사항을 적어도, 글에는 여전히 이모지가 있거나 AI 작가 언급이 남아있습니다.
• 처음 불완전하면 프롬프트를 다시 작성하기만 하기: 글을 수정하지 않고 프롬프트만 바꾸어 처음부터 다시 쓰면, 결과는 여전히 같은 문제점을 가집니다.
• 수정 지시를 모호하게 작성하기: '좀 더 전문적으로 써줘'라고 돌려주면, 모델은 어디를 고쳐야 할지 알지 못해 수정한 것이 없는 것과 같습니다.
• 단계 간에 강제로 순서를 정하기: 각 단계가 서로 의존하지 않는데도 순서로 연결하면, 이전 단계를 기다리느라 시간만 낭비합니다.
• 단계별 검증을 하지 않기: 이전 단계의 결과를 확인하지 않고 다음으로 넘어가면, 잘못된 정보가 끝까지 전달됩니다.
• 패턴을 인식했다고 해서 능숙하다고 착각하기: 분할(Chunking)이나 수정(Revision)이라는 단어를 외우는 것과 실제 프로세스 표를 작성하는 것은 다릅니다. 레시피는 여전히 종이에 있습니다.

Ⅱ. 대안 및 이유 (Alternative Solutions + Reasons)

강좌에서 제시한 비교는 '하나의 큰 프롬프트'와 '체인형 워크플로우'입니다. 첫째, 하나의 큰 프롬프트: 기술 기사 작성 시 네 가지 요구사항(AI가 작성했다는 언급 금지, 이모지 사용 금지, 진부한 표현 금지, 전문적인 어조 유지)을 한 번에 제시합니다. 아무리 명확하게 요구사항을 적어도, Claude는 여전히 그중 몇 가지를 위반할 수 있으며, 결과물은 여전히 이모지를 포함하거나 AI 작가 언급이 남아있고, 어조도 비전문적일 수 있습니다. 둘째, 체인형 워크플로우: 첫 단계에서 초기 프롬프트를 보내고, 첫 번째 결과가 완벽하지 않을 수 있음을 받아들입니다. 두 번째 단계에서 후속 요청을 보내서 전문적으로 수정합니다. 방금 작성한 글을 돌려주면서, 구체적인 수정 지시를 통해 하나하나 깨끗하게 고칩니다. 이유는 세 가지입니다: 첫째, 집중성(Focus): 한 번에 Claude에게 하나의 구체적인 임무만 주면, 그 일에만 집중하여 처리할 수 있으며, 여러 요구사항을 동시에 처리하려 애쓰지 않아도 됩니다. 둘째, 단계 간 개입 가능(Intervention): 각 단계 사이에서 LLM이 아닌 처리를 선택적으로 수행하거나, 먼저 검증한 후에 다음으로 전달할 수 있습니다. 셋째, 수정 비용 효율성(Cost-effectiveness of Revision): 첫 번째 글은 전반적으로 맞습니다. 위반된 몇 가지 항목만 수정하면 되므로, 전체를 다시 쓸 필요가 없습니다. '분리 가능한가? 각 단계가 전문적인가? 수정할 수 있는가?' 이 세 가지 질문을 확실히 다루는 것이 중요하며, 이후 모든 '프롬프트가 길어지면 모델이 말을 안 듣는다'는 문제는 먼저 분해(Chunking)를 제대로 했는지부터 물어야 합니다.

Ⅲ. 목표 형태

작업이 주어지면 먼저 분할 가능한지 물어봐야 합니다. 분할 가능하다면 작은 순서적 단계로 나누어 수행하고, 각 단계에서는 오직 한 가지 일에만 집중해야 하며, 단계와 단계 사이에는 반드시 검증(Verification)을 거쳐 다음 단계로 넘겨야 합니다. 처음 작성된 결과물이 완벽하지 않더라도 두 번째 수정 과정을 거치고, 수정 지침은 항목별로 명확하게 정의해야 합니다. 신입 사원이 이 내용을 보면 다음과 같은 질문을 할 것입니다: 분할 가능한가? 각 단계가 독립적인가? 그리고 수정이 가능한가? 절대로 단계를 건너뛰어서는 안 됩니다.

4. 전이(遷移) 단계

1. 먼저 작업을 문서화하세요: 한 번의 요청에 몇 가지 일을 담았는지, 어느 부분에서 막혔는지 기록합니다.
2. 첫 질문을 하세요: 분할 가능한가? 순차적인 하위 작업으로 나눌 수 있다면 나누고, 그렇지 않다면 의존성(Dependency)을 명확하게 설명해야 합니다.
3. 각 단계별로 한 가지 일만 수행하도록 명시하세요: 주제 찾기는 오직 주제 찾기만 하고, 스크립트 작성은 오직 스크립트 작성만 해야 하며, 모든 것을 한 번에 하려고 해서는 안 됩니다.
4. 첫 단계를 먼저 실행시키세요: 초기 프롬프트(Prompt)를 발행하고, 처음의 결과물이 완벽하지 않을 수 있음을 받아들여야 합니다.
5. 두 번째 단계에서 전문적으로 수정하세요: 첫 번째 결과를 다시 전달하여 구체적인 수정 지침을 제공하며, 항목별로 하나씩 수정해야 합니다.
6. 단계와 단계 사이에는 반드시 검증을 거치세요: 이전 단계의 결과물을 확인하지 않고 다음 단계로 넘겨서는 안 됩니다.
7. 새로운 단계를 추가할 때는 한 단계를 더 추가하세요: 기존 단계는 수정하거나 다시 작성할 필요가 없습니다.
8. 패턴을 인식하는 것을 넘어 직접 구현해야 합니다: 레시피(Recipe)를 알면 코드는 스스로 작성해야 하며, 패턴을 아는 것이 코드를 작성할 줄 안다는 의미와 같지 않습니다.

5. 팀 공동 구축 분업화

• 한 명은 분할 담당: 분할 가능한가? 각 단계가 독립적인가? 분할 불가능한 것은 막아냅니다.
• 한 명은 각 단계별 작업 관리: 주제 찾기, 주제 선정, 연구 등 모든 단계의 작업을 기록했는지 확인합니다.
• 한 명은 수정 담당: 수정 지침이 항목별로 명확하게 정의되었는지, 첫 번째 결과물의 결함이 깨끗하게 수정되었는지 확인합니다.
• 한 명은 검증 담당: 단계와 단계 사이의 검증을 거쳤는지, 잘못된 것이 다음 단계로 넘어가지 않았는지 확인합니다.

6. 공식 도구 키트

• 체인형 워크플로우 구조(Chained Workflow Structure): 큰 작업을 작은 순차적 단계로 나누어 수행하고, 각 단계에서는 오직 한 가지 일에만 집중합니다. 단계 사이에는 선택적으로 LLM이 아닌 처리를 할 수 있습니다.
• 소셜 미디어 마케팅 도구 예시: 6단계—트위터의 인기 주제 찾기, 가장 흥미로운 주제 선정, 주제 연구, 짧은 영상 스크립트 작성, AI 버추얼 휴먼과 음성 합성으로 영상 제작, 소셜 미디어에 게시하기.
• 긴 프롬프트 문제점: 네 가지 요구사항—AI가 작성했다는 언급 금지, 이모티콘 사용 금지, 진부한 표현(陳腔濫調) 사용 금지, 전문적인 기술 용어 톤 유지.
• 2단계 체인 방식: 첫 번째 단계에서 먼저 작성하고, 두 번째 단계에서 전문적으로 수정합니다—AI 저자 언급 삭제, 이모티콘 삭제, 어색한 문체를 기술적 작가의 글로 변경.
• 가져가야 할 원칙: 작은 순차적 단계로 나누어 수행하고, 처음이 완벽하지 않으면 두 번째 수정 과정을 거칩니다. 작업이 복잡하여 분할할 가치가 있다는 것을 인식하는 것이 핵심입니다.

마무리 요약: 원칙이 구조보다 중요합니다—여기서 묻는 것은 '분할', '수정'이라는 단어를 외우는지 여부가 아니라, '하나의 큰 프롬프트로 처음부터 끝까지 진행하는 것'이 잘못되었다는 것을 인정할 용기가 있는지입니다. 반복 가능한 동작 규칙은 오직 하나뿐합니다. 복잡한 작업을 접하기 전에 항상 세 가지 질문을 던지세요—분할 가능한가? 각 단계가 독립적인가? 수정 가능한가? 이 문장을 습관으로, 템플릿으로 만드십시오. '프롬프트가 길어질수록 모델이 말을 안 듣는다'는 것은 숙명이 아니라 선택의 문제입니다.

S1님의 관점: 더 이상 '요구사항을 모두 프롬프트에 담았으니 끝났다'고 생각하며 시작하지 마세요—아무리 명확하게 네 가지 요구사항을 작성했더라도, 글에 이모티콘이 있거나 AI 저자 언급이 있다면 모델 탓만 할 수 없습니다. 처음부터 잘 안 되었다고 해서 프롬프트를 수정하여 다시 쓰는 결과물도 여전히 같은 결함이 있다면 체인 방식이 쓸모없다고 할 수 없습니다. 일꾼 여섯 명을 불러놓고, 각자 맡은 일이 없게 하고 그저 어둠 속에서 감에 의존하게 한 뒤, 마지막에 아무도 관리하지 않았다고 비난하는 것이 말이 됩니까? 더 중요한 질문은 이것입니다: 현재 당신의 작업은 분할 가능한가? 각 단계가 독립적인가? 수정 가능한가? 답할 수 없다면 체인형 워크플로우를 다룰 줄 안다고 자랑하기 전에, 이 세 가지 질문을 명확히 하고 두 단계를 거친 후 시작해도 늦지 않습니다. 당신이 가진 작업은 분할 가능한가? 댓글로 이야기해 보세요.

수집용 체크리스트 (따라 하기):

1. 먼저 세 가지 질문을 하세요: 분할 가능한가, 각 단계가 독립적인가, 수정 가능한가?
2. 각 단계는 한 가지 일만 수행하세요: 주제 찾기는 오직 주제 찾기만 하고, 스크립트 작성은 오직 스크립트 작성만 합니다.
3. 첫 단계를 먼저 실행시키세요: 처음의 결과물이 완벽하지 않을 수 있음을 받아들입니다.
4. 두 번째 단계에서 전문적으로 수정하세요: 수정 지침을 항목별로 명확하게 정의한 후 다시 전달합니다.

아직도 하나의 큰 프롬프트 안에서 처음부터 끝까지 진행하는 친구에게 이 글은 오늘 바로 사용할 수 있는 내용이 될 것입니다.