체이닝 워크플로

Stephen Grider · Anthropic 기술 스태프

이번에 살펴볼 워크플로는 조금 뻔하고 단순해 보일 수 있습니다. 하지만 믿어 주세요 — 이건 실제로 가장 유용한 워크플로 중 하나이고, 특히 여러분이 아주 자주 마주칠 한 가지 상황에서 진가를 발휘합니다.

예시 애플리케이션을 다시 한번 바꿔 봅시다. 이번엔 소셜 미디어 마케팅 도구를 만든다고 상상합니다. 사용자는 자기 SNS 계정의 주제(계정이 무엇에 초점을 두는지)를 입력합니다. 우리 앱의 목표는 그 계정에 올릴 영상을 생성하고 게시하는 것입니다.

이걸 구현하는 데 거창한 도구를 잔뜩 갖춘 화려한 에이전트는 필요 없습니다. 미리 정해진 단계를 하나씩 차례로 밟는 워크플로면 충분합니다. ① 사용자가 입력한 주제로 트위터에서 트렌드 주제를 검색합니다. ② 그 주제 목록을 모두 Claude에 넣어 가장 흥미로운 주제를 고르게 합니다. ③ 후속 요청으로 Claude에 그 주제를 웹 리서치하게 합니다. ④ 리서치가 끝나면 숏폼 영상 스크립트를 쓰게 합니다. ⑤ 스크립트가 나오면 AI 아바타와 음성 합성(TTS) 프로그램으로 실제 영상을 만듭니다. ⑥ 마지막으로 그 영상을 SNS에 게시합니다.

이것이 체이닝 워크플로의 예입니다. 체이닝 워크플로에서는 하나의 큰 작업(원래는 '영상을 생성해 SNS에 게시')을 가져와 별개의 여러 단계로 쪼갭니다. 여기서 하위 작업들은 Claude에 보낸 개별 호출들이었습니다. 이 모든 걸 Claude 호출 한 번에 처리할 수도 있었습니다 — 주제 목록을 주고, 가장 흥미로운 걸 고르고, 리서치하고, 스크립트까지 한 프롬프트 안에서 다 시키는 식으로요. 하지만 이걸 별개의 호출들로 쪼개면, Claude가 한 번에 하나의 작업에만 집중하게 됩니다.

말했듯이 이건 단순하고 뻔한 워크플로처럼 보일 수 있고, 이미 과거에 구현해 봤을 수도 있어 굳이 논할 가치가 없어 보일지도 모릅니다. 하지만 제가 이 워크플로를 특별히 짚는 데는 아주 분명한 이유가 있습니다. 이것이 제법 큰 프롬프트를 쓸 때 Claude에서 일관되게 좋은 출력을 얻기 위해 이해해야 할 가장 중요한 워크플로이기 때문입니다.

한 가지 시나리오를 짚어 보겠습니다. 아직 겪어 보지 못했을 수도 있지만, 언젠가는 거의 반드시 마주치게 될 상황입니다. Claude로 어떤 주제에 대한 글을 쓴다고 합시다. 처음엔 아주 단순한 프롬프트를 보내 글을 써 달라고 합니다. 결과가 돌아오는데, 괜찮긴 해도 마음에 안 드는 부분이 있습니다. Claude가 '나는 이 글을 쓰는 AI입니다'라고 밝히거나(원치 않겠죠), 이모지를 과하게 쓰거나, 곳곳에 진부한 표현을 늘어놓습니다.

그래서 프롬프트를 다듬어 가며 '이건 하지 마, 저건 하지 마' 하는 긴 목록을 만들게 됩니다. 그런데 아무리 같은 항목을 반복해도 Claude는 어떻게든 이모지를 쓰고, 자신이 AI라고 밝히고, 전반적으로 어딘가 낯간지럽고 비전문적인 톤의 글을 돌려줍니다. 제약을 몇 번을 되풀이해도 이런 글을 고집하는 거죠.

이 문제를 해결하려면 아주 단순한 프롬프트 체이닝 워크플로를 쓰면 됩니다. 방법은 이렇습니다. 먼저 그 긴 제약 목록이 담긴 초기 프롬프트를 보내고, 원하는 바에 못 미치는 초안이 돌아올 거라는 걸 그냥 받아들입니다. Claude는 결국 일부 제약을 어기게 됩니다.

이 문제들을 고치려면, 방금 Claude가 쓴 글을 그대로 다시 넣은 후속 요청을 보냅니다. 그 글 아래에 특정한 방식으로 다시 써 달라고 요청합니다 — 예를 들어 '저자가 자신을 AI라고 밝힌 곳을 모두 찾아 지우고, 이모지를 전부 제거하고, 전문 기술 작가가 쓰듯 다시 써 줘.' 작업을 여러 단계로 쪼개면 Claude가 눈앞의 각 작업에 훨씬 더 집중하게 됩니다.

그래서 원래의 긴 프롬프트의 모든 요구를 다 못 채웠더라도, 후속 프롬프트에서는 여러분이 정말 신경 쓰는 제약에만 Claude가 집중하게 되고, 바라던 스타일로 글을 다시 써 줍니다. 다시 말하지만, 프롬프트 체이닝은 뻔하고 단순해 보여도, 제약이 많은 작업을 Claude가 기대만큼 잘 따르지 않을 때 아주 자주 쓰게 되는 워크플로입니다.