대부분의 프롬프트 파이프라인은 모든 것을 하나의 긴 순차적(serial) 패스로 처리하거나, 전체 작업을 하나의 부풀어 오른(bloated) 프롬프트에 쑤셔 넣습니다. 둘 다 무언가를 낭비합니다. 병렬화는 같은 입력을 여러 개의 프롬프트로 분산하여 동시에 실행하고, 그 결과를 집계기(aggregator)를 통해 결합함으로써 이 두 가지 문제를 해결합니다. 이는 프롬프트를 위한 map/reduce이며, 이렇게 보면 실제로는 단지 Promise.all과 reduce에 불과합니다. 저는 호출을 실행하고 벽시계 시간(wall-clock) 및 신뢰성 측면의 이점을 실시간으로 보여주는 인터랙티브 데모를 만들었습니다. 모양은 다음과 같습니다.

대체할 느린 순차 버전 (The slow serial version you're replacing)

거의 작동하는 방식: 루프에서 await을 사용하여 각 조각을 하나씩 실행하는 것입니다. 이는 정확하지만, 아무것도 서로 의존하지 않음에도 불구하고 모든 호출이 다음 것을 차단(blocks)하기 때문에 벽시계 시간은 모든 호출의 **합계(sum)**가 됩니다.

// ❌ 각 독립적인 호출이 다음을 차단함 -> 벽시계 = 합계 (SUM)
async function serial(subtasks, input) {
  const parts = [];
...

맛 하나 — 섹션 분할 (latency win)

작업을 서로의 출력이 필요하지 않은 조각들로 나누고, 각각에 작고 집중된 프롬프트를 부여합니다. 출시 개요(launch brief)는 다음과 같이 변합니다: 헤드라인, 기능, FAQ, 트윗 — 모든 부분을 다루느라 얇고 서두르는 하나의 프롬프트 대신 네 개의 좁은 프롬프트로 나뉩니다. 이들은 독립적이므로 한 번에 실행되며, 벽시계 시간은 _합계(sum)_에서 _가장 느린 단일 호출(slowest single call)_로 떨어집니다. 이것이 전체 요령입니다 — 모두를 기다리지 않고 시작한 다음, 한 번에 await Promise.all을 합니다.

// ✅ 병렬 분산: 모두 시작하고, 한 번만 await합니다. 시계 = 합계(SUM)가 아닌 최대값(MAX).
async function fanOut(subtasks, input) {
  const calls = subtasks.map(t => llm(t.prompt + input)); // 모두 지금 시작
...

맛 둘 — 투표 (a reliability win)

맛 둘 — 투표 (a reliability win)

동일한 팬-아웃 방식이지만, 모든 호출이 동일한 프롬프트이며 따뜻하게 실행되어 샘플들이 다양하게 나옵니다. 단일 샘플은 동전 던지기일 수 있지만, 이를 N번 실행하고 다수결을 취하면 무작위 노이즈가 상쇄되고 — 불안정한 일회성 결과가 자신감 있고 자체적으로 일관된 답변으로 바뀝니다. 가장 좋은 점은: 승리한 투표 비율 자체가 무료로 얻는 신뢰도 점수라는 것입니다. 데모의 야구공 질문에서 5개 샘플 중 2개가 고전적인 $0.10 함정에 빠지지만, 다수결은 여전히 올바른 $0.05에 도달합니다.

async function vote(prompt, n = 5) {
  const runs = Array.from({ length: n }, () => llm(prompt)); // identical prompt
  const votes = await Promise.all(runs);                     // all at once
...

집계기는 리듀스 (The aggregator is the reduce)

팬-아웃은 절반에 불과하며, 결과들은 함께 모여야 합니다. 섹셔닝(sectioning)의 경우 병합(merge) — 섹션들을 하나의 문서로 꿰매고, 때로는 최종 합성 단계를 거칩니다. 투표(voting)의 경우 집계(tally) — 답변을 세어 다수결을 취하고, 승리한 비율에서 신뢰도를 읽습니다.

const merge = (parts) => parts.join("
\n");        // sectioning: stitch pieces

function majority(votes) {                          // voting: tally + confidence
...

두 가지 방식, 하나의 형태 — 그리고 한계점

섹셔닝과 투표는 같은 두 가지 동작입니다: fanOut → aggregate. 데모에서는 이 둘 사이를 전환하고 순차적(sequential) 대 병렬적(parallel)을 토글할 수 있으며, 작은 간트 차트는 그 점을 생생하게 보여줍니다 — 병렬 행은 가장 느린 호출의 길이와 하나의 집계 단계만 추가되는 반면, 순차 행은 끝과 끝이 쌓입니다.

async function parallelize(input, mode) {
  if (mode === "section") return merge(await fanOut(SUBTASKS, input)); // latency
  if (mode === "vote")    return vote(input, 5);                       // reliability
...

이러한 트레이드오프는 평평하며 명확하게 언급할 가치가 있습니다: N번의 호출은 대략 N배의 토큰을 의미합니다. 따라서 조각들이 진정으로 독립적일 때(분할/sectioning) 또는 정확한 답변을 얻기 위해 여러 번 시도하는 것이 가치 있을 때(투표/voting) 병렬화를 사용해야 하며, 순서대로 서로에게 피드되어야 하는 단계를 빠르게 하기 위함은 아닙니다. 그것이 바로 체이닝(chaining)이며, 완전히 다른 패턴입니다. 또한 제공업체의 호출 제한(rate limits)은 큰 분산(fan-out)을 속도 제한할 것이므로 동시성(concurrency)에 상한선을 두어야 합니다. 이것은 핵심 에이전트 빌딩 블록이며, 다음 단계는 서브태스크를 동적으로 결정하여 워커 모델에 전달하는 오케스트레이터입니다. 여기서는 분할이 고정되어 있습니다.

어떤 방식을 선택하고 호출이 실행되는 것을 지켜보세요. 벽시계 시간과 토큰 비용을 나란히 비교해 볼 수 있습니다:
[https://dev48v.infy.uk/prompt/day37-parallelization.html]