2부 7장. 라우팅과 병렬 처리: 요청을 분기하고 동시에 처리하기

순서만 잘 짜도 강해지지만, 흐름까지 나누면 더 강해진다

앞 장에서 우리는 프롬프트 체이닝을 살펴봤다. 복잡한 일을 한 번에 시키지 않고, 분석하고, 쓰고, 검토하고, 다듬는 식으로 나누면 훨씬 안정적이라는 이야기였다. 그런데 실전 시스템으로 가면 곧 이런 문제가 등장한다. 모든 요청이 같은 길로 가야 할까? 정말 모든 단계가 순서대로만 실행되어야 할까?

답은 대개 아니다.

어떤 요청은 단순한 FAQ 답변이면 충분하고, 어떤 요청은 정책 검색이 먼저 필요하다. 어떤 요청은 코드 분석이 핵심이고, 어떤 요청은 문서 요약과 표 생성이 동시에 가능하다. 모든 요청을 한 줄로 세워 같은 컨베이어 벨트에 태우면, 쉬운 일도 괜히 오래 걸리고 어려운 일도 제대로 처리되지 않는다.

이때 필요한 것이 라우팅과 병렬 처리다. 라우팅은 들어온 요청을 보고 어느 경로로 보낼지 결정하는 일이다. 병렬 처리는 서로 독립적인 일을 동시에 실행하는 일이다. 전자는 "어디로 보낼까?"의 문제이고, 후자는 "무엇을 동시에 할 수 있을까?"의 문제다.

둘을 잘 설계하면 속도와 정확도를 함께 잡을 수 있다. 쉬운 일은 짧은 길로 보내고, 어려운 일은 더 정교한 경로로 보낼 수 있다. 여러 분석 작업을 동시에 돌려 대기 시간을 줄일 수도 있다. 반대로 잘못 설계하면 시스템은 미로처럼 꼬인다. 길은 많아졌는데 자꾸 잘못 들어가고, 동시에 돌렸더니 결과가 서로 충돌하는 일이 벌어진다.

이번 장에서는 이 두 가지를 아주 기본부터 살펴본다. 핵심은 화려한 구조가 아니라 분기 설계의 감각이다. 언제 길을 나누고, 무엇을 동시에 돌리고, 어디서 다시 합칠지 이해하면 에이전트는 훨씬 실전적인 시스템이 된다.

라우팅은 요청을 보고 알맞은 처리 경로를 고르는 일이다

라우팅을 가장 쉽게 설명하면 접수 데스크다. 병원에 가면 모든 환자가 똑같이 진료실 1번으로 가지 않는다. 증상에 따라 내과로 갈지, 정형외과로 갈지, 응급실로 갈지 나뉜다. 에이전트 시스템도 비슷하다. 입력을 받고, 그 입력의 성격을 파악한 뒤, 가장 적절한 처리 경로로 보내야 한다.

예를 들어 고객 지원 시스템을 생각해보자. 사용자의 메시지가 배송 조회인지, 환불 문의인지, 계정 잠금 해제 요청인지에 따라 필요한 도구와 정책이 달라진다. 이때 모든 요청을 하나의 거대한 프롬프트로 처리하면 겉보기에는 단순하지만 내부에서는 늘 과한 일을 하게 된다. 배송 문의에도 환불 정책을 확인하려 들고, 단순 비밀번호 재설정 요청에도 긴 검색 절차를 붙일 수 있다.

라우팅의 목적은 단순하다. 요청마다 필요한 만큼만 처리하게 만드는 것이다. 쉽게 말하면 쉬운 일은 짧게, 어려운 일은 깊게 다루게 만드는 설계다.

입력 분류는 라우팅의 출발점이다

라우팅은 보통 입력 분류에서 시작한다. 시스템은 먼저 "이 요청이 어떤 종류인가?"를 판단해야 한다. 여기서 말하는 분류는 거창한 머신러닝 모델이 꼭 필요한 것은 아니다. 처음에는 아주 단순한 규칙으로도 시작할 수 있다.

예를 들어 이런 분류가 가능하다.

• 정보 조회 요청인지

• 작업 실행 요청인지

• 단순 대화인지

• 민감한 승인 요청인지

• 사람이 개입해야 하는 예외 상황인지

중요한 것은 분류를 위한 라벨 이름을 멋있게 짓는 것이 아니다. 분류 결과가 실제 처리 경로 차이로 이어져야 한다는 점이다. 분류는 그 자체로 가치가 있는 것이 아니라, 이후 흐름을 바꾸기 위해 존재한다.

예를 들어 "질문"이라는 라벨 하나만 만들면 라우팅에 큰 도움이 되지 않는다. 대신 "검색이 필요한 질문", "계산이 필요한 질문", "내부 시스템 조회가 필요한 질문"처럼 처리 방식이 달라지는 분류가 더 유용하다. 좋은 분류는 데이터셋이 아니라 작업 흐름을 위해 존재한다.

좋은 라우터는 똑똑한 판사가 아니라 성실한 교통경찰에 가깝다

많은 사람이 라우터를 만들 때 처음부터 모든 걸 완벽히 판단하는 작은 천재를 꿈꾼다. 하지만 실전에서 좋은 라우터는 대개 그렇게 일하지 않는다. 오히려 라우터는 교통경찰처럼 단순하고 일관된 기준으로 흐름을 정리해주는 편이 낫다.

라우터가 너무 많은 판단을 하게 되면 문제가 생긴다. 요청을 분류하는 순간부터 이미 과한 추론을 해버리고, 본 처리 단계가 해야 할 일까지 미리 결정해버린다. 그러면 오분류가 더 치명적이 된다. 라우터는 보통 "이 요청은 어느 팀에 보내야 하는가"까지만 책임지는 것이 좋다. 실제 답변의 세부 내용까지 라우터가 미리 고민할 필요는 없다.

즉, 라우터의 핵심은 깊은 해결이 아니라 적절한 전달이다. 이 단순함이 시스템을 안정적으로 만든다.

언제 라우팅이 특히 큰 효과를 내는가

모든 시스템이 라우팅을 복잡하게 가져갈 필요는 없다. 하지만 어떤 상황에서는 라우팅이 체감 성능을 크게 바꾼다.

첫째, 요청 종류가 뚜렷하게 다른 경우다. 예를 들어 어떤 요청은 문서 검색이 핵심이고, 어떤 요청은 외부 API 호출이 핵심이며, 어떤 요청은 단순 생성이면 충분하다면 하나의 경로만 쓰는 것은 비효율적이다.

둘째, 비용 차이가 큰 경우다. 모든 요청에 비싼 모델, 긴 컨텍스트, 여러 도구 호출을 붙이면 운영 비용이 빠르게 늘어난다. 라우팅을 쓰면 쉬운 요청은 가벼운 경로로 보내고, 어려운 요청만 무거운 경로로 보낼 수 있다.

셋째, 실패 방식이 다른 경우다. 환불 요청과 일정 추천 요청은 틀렸을 때의 위험이 다르다. 민감한 요청은 더 보수적인 경로, 검토 단계가 있는 경로, 혹은 사람 승인 경로로 보내야 한다.

넷째, 품질 기준이 다른 경우다. 어떤 요청은 속도가 중요하고, 어떤 요청은 정확성이 더 중요하다. 라우팅은 같은 시스템 안에서 서로 다른 목표를 동시에 다루게 해준다.

라우팅의 가장 쉬운 형태는 규칙 기반 분기다

처음부터 모델이 모든 분기를 판단할 필요는 없다. 많은 시스템은 규칙 기반 분기로도 충분히 좋은 출발을 할 수 있다. 예를 들어 파일 첨부가 있으면 문서 분석 경로로 보내고, "환불", "취소", "승인" 같은 키워드가 있으면 정책 검토 경로로 보내는 식이다.

이 방식의 장점은 이해하기 쉽고 디버깅이 쉽다는 점이다. 왜 이 요청이 저 경로로 갔는지 바로 설명할 수 있다. 초기 제품이나 내부 도구에서는 이런 단순함이 매우 강하다.

하지만 규칙만으로는 한계도 분명하다. 사용자의 표현은 늘 다양하고, 같은 단어가 다른 의미로 쓰이기도 한다. "계정을 닫고 싶다"와 "창을 닫고 싶다"는 완전히 다른 요청인데, 단어만 보면 헷갈릴 수 있다. 그래서 시스템이 성장하면 규칙만으로는 점점 버거워진다.

그렇다고 규칙 기반 라우팅이 낡은 방식이라는 뜻은 아니다. 오히려 실전에서는 규칙과 모델 기반 라우팅을 함께 쓰는 경우가 많다. 명확한 예외는 규칙으로 처리하고, 애매한 경우만 모델에게 넘기는 식이다. 이것이 비용과 안정성을 동시에 챙기기 좋은 출발점이다.

모델 기반 라우팅은 더 유연하지만 더 신중하게 써야 한다

모델 기반 라우팅은 입력 내용을 읽고 의미를 파악해 경로를 고른다. 사용자의 표현이 다양해도 비교적 유연하게 대응할 수 있다는 장점이 있다. 예를 들어 "이번 달 결제 내역 좀 확인해줘"와 "내가 카드에서 빠져나간 금액 목록을 보고 싶어"를 같은 범주로 묶을 수 있다.

하지만 유연함은 곧 불확실성이다. 모델은 언제든 애매한 판단을 할 수 있다. 그래서 모델 기반 라우팅을 설계할 때는 두 가지가 중요하다.

하나는 출력 형식을 엄격하게 제한하는 것이다. 자유로운 문장으로 "이 요청은 아마도 환불 문의 같지만 배송 이슈도 조금 섞여 있습니다"라고 말하게 하면 시스템이 다음 행동을 정하기 어렵다. 대신 route=refund, confidence=0.82처럼 구조화된 출력이 훨씬 좋다.

다른 하나는 확신이 낮을 때의 대처 경로를 만드는 것이다. 사람도 자신 없을 때는 상급자에게 묻는다. 라우터도 마찬가지다. 애매하면 안전한 기본 경로로 보내거나, 더 넓은 검토 경로로 보내거나, 사람 검토 대기열로 보내야 한다. 라우팅에서 중요한 것은 늘 맞히는 것이 아니라, 틀릴 때 크게 망하지 않는 것이다.

좋은 분기 기준은 기술 기준이 아니라 운영 기준이다

라우팅을 설계할 때 흔한 실수는 모델의 관점으로 분기를 나누는 것이다. 예를 들어 "추론형", "생성형", "분석형" 같은 분류는 그럴듯해 보이지만 운영에서는 애매하다. 실제 시스템이 알아야 하는 것은 그런 추상적 성격보다, 어떤 도구가 필요한지, 어떤 위험이 있는지, 응답 시간이 얼마나 중요한지 같은 기준이다.

좋은 분기 기준은 보통 이런 질문에서 나온다.

• 이 요청은 검색이 필요한가?

• 외부 시스템을 건드리는가?

• 잘못 처리했을 때 위험이 큰가?

• 사람이 승인해야 하는가?

• 빠른 응답이 중요한가, 깊은 검토가 중요한가?

즉, 라우팅은 철학보다 운영에 가까운 설계다. 입력을 예쁘게 분류하는 것보다 실제 처리 비용, 정확도, 책임 범위를 반영하는 분기가 훨씬 중요하다.

라우팅은 계층적으로 설계할수록 다루기 쉬워진다

분기를 한 번에 너무 많이 만들면 시스템은 금세 복잡해진다. 예를 들어 12개의 전문 경로 중 하나를 처음부터 고르라고 하면 라우터도 흔들리고 운영자도 이해하기 어렵다. 그래서 실전에서는 계층적 라우팅이 자주 쓰인다.

먼저 큰 갈래를 나누고, 그 안에서 다시 세부 경로를 고르는 방식이다. 예를 들어 첫 단계에서는 "대화형 응답", "정보 검색", "작업 실행", "민감 요청" 정도로 크게 나눈다. 그다음 작업 실행 안에서만 "이메일 발송", "일정 등록", "결제 변경" 같은 세부 경로를 고른다.

이렇게 하면 한 번의 판단이 너무 무거워지지 않는다. 동시에 실패 지점도 더 잘 보인다. 큰 갈래에서 잘못 들어갔는지, 세부 경로에서 헷갈렸는지 구분할 수 있기 때문이다. 시스템은 계단처럼 설계할수록 관리하기 쉬운 경우가 많다.

병렬 처리는 순서를 무시하는 기술이 아니라 독립성을 활용하는 기술이다

이제 병렬 처리로 넘어가 보자. 병렬 처리라고 하면 많은 사람이 "여러 개를 동시에 돌리면 빨라진다" 정도로 이해한다. 맞는 말이지만 절반만 맞다. 더 중요한 질문은 이것이다. 정말 동시에 돌려도 되는가?

병렬 처리는 순서를 없애는 기술이 아니라, 서로 기다릴 필요가 없는 작업을 찾아내는 기술이다. 어떤 단계는 앞선 결과를 알아야만 다음으로 갈 수 있다. 이런 작업은 병렬화하면 안 된다. 반대로 서로 독립적인 작업이라면 동시에 실행하는 편이 훨씬 효율적이다.

예를 들어 제품 비교 리포트를 만든다고 해보자. A사 정보 수집, B사 정보 수집, C사 정보 수집은 서로 독립적일 수 있다. 이런 일은 병렬 처리하기 좋다. 하지만 최종 비교 요약은 세 회사 정보가 모두 모인 뒤에야 제대로 할 수 있다. 이것은 합류 단계에서 해야 한다.

병렬 처리의 핵심은 "모든 걸 동시에"가 아니라 "독립적인 것만 동시에"다.

어떤 작업이 병렬 처리에 적합한가

병렬화에 잘 맞는 작업은 대개 서로의 중간 결과를 필요로 하지 않는다. 다시 말해 한 작업이 끝나기를 기다리지 않아도 다른 작업이 시작될 수 있다.

대표적인 예는 이런 경우다.

• 여러 문서를 각각 요약한 뒤 마지막에 합치는 경우

• 여러 후보 답변을 생성한 뒤 평가하거나 선택하는 경우

• 서로 다른 데이터 소스를 동시에 조회하는 경우

• 여러 기준으로 같은 대상을 분석한 뒤 종합하는 경우

예를 들어 한 개의 고객 문의를 처리하면서 동시에 정책 문서를 검색하고, 주문 상태를 조회하고, 과거 상담 기록을 불러오는 것은 좋은 병렬화 대상이 될 수 있다. 이 세 작업은 서로 독립적이기 때문이다. 세 결과가 모이면 그때 최종 응답을 만들면 된다.

이런 구조는 특히 응답 시간 단축에 효과가 크다. 세 작업을 순차적으로 하면 2초, 3초, 2초가 걸려 총 7초가 걸릴 수 있다. 병렬로 실행하면 대체로 가장 오래 걸린 작업 시간에 가까워진다. 물론 시스템 오버헤드는 있지만, 체감은 훨씬 빨라진다.

병렬 처리의 진짜 어려움은 실행이 아니라 합성이다

여러 작업을 동시에 돌리는 것 자체는 생각보다 어렵지 않다. 진짜 어려운 지점은 마지막에 결과를 어떻게 합칠 것인가다. 병렬 처리의 품질은 대개 합성 단계에서 결정된다.

예를 들어 세 개의 문서를 병렬로 요약했다고 해보자. 이제 최종 단계는 단순히 세 요약을 이어 붙이는 것으로 끝나지 않는다. 중복된 내용을 제거해야 하고, 서로 충돌하는 진술이 있으면 정리해야 하며, 사용자 질문에 맞게 우선순위를 다시 잡아야 한다.

즉, 병렬 처리 이후에는 거의 항상 재구성 작업이 필요하다. 이것을 무시하면 시스템은 빨라지기만 하고 좋아지지는 않는다. 오히려 잡다한 조각을 한데 모은 어수선한 답변이 될 수 있다.

그래서 병렬 구조에서는 마지막 합성기가 중요하다. 합성기는 단순한 붙이기 도구가 아니라, 여러 결과를 비교하고, 중복을 줄이고, 충돌을 해소하고, 하나의 일관된 응답으로 만드는 역할을 해야 한다.

결과를 합치는 방식도 설계의 일부다

결과 합성에는 몇 가지 전형적인 방식이 있다. 각각 장단점이 다르다.

첫 번째는 병합이다. 여러 경로의 결과를 모아 하나의 큰 컨텍스트로 만들고, 마지막 단계에서 종합 답변을 생성한다. 문서 요약이나 다중 소스 정보 통합에 자주 쓰인다.

두 번째는 선택이다. 여러 후보 중 가장 좋은 하나를 고른다. 예를 들어 답변 초안을 세 개 만든 뒤, 평가 기준에 따라 하나를 선택할 수 있다. 속도보다 품질을 올리고 싶을 때 유용하다.

세 번째는 투표다. 서로 독립적으로 판단한 결과가 있을 때 다수 의견을 택한다. 분류, 검토, 간단한 판단 작업에서 도움이 될 수 있다. 다만 다수가 늘 옳은 것은 아니므로 신중해야 한다.

네 번째는 역할별 종합이다. 예를 들어 하나는 정확성 검토, 하나는 정책 준수 검토, 하나는 사용자 친화성 검토를 맡기고, 마지막에 이 셋을 반영해 최종 답변을 만든다. 같은 문제를 다른 각도에서 본 뒤 다시 하나로 합치는 방식이다.

중요한 것은 병렬 처리 자체보다 합성 전략이 작업 목적과 맞아야 한다는 점이다. 여러 출력을 만들었다는 사실만으로 품질이 자동으로 올라가지는 않는다.

라우팅과 병렬 처리는 자주 함께 움직인다

실전에서는 라우팅과 병렬 처리가 따로 떨어져 있지 않다. 보통 라우팅이 먼저 어떤 흐름을 고르고, 그 흐름 안에서 병렬 처리가 일어난다.

예를 들어 사용자의 요청이 "경쟁사 세 곳의 최근 제품 발표를 비교해서 우리 팀 회의용 메모를 만들어줘"라고 해보자. 라우터는 이 요청을 단순 대화가 아니라 리서치 기반 비교 분석 경로로 보낼 수 있다. 그리고 그 경로 안에서는 세 경쟁사 정보를 각각 병렬 수집하고, 또 제품 기능, 가격, 포지셔닝 분석을 병렬 수행할 수 있다. 마지막에 이 결과들을 합쳐 회의용 메모를 만든다.

이처럼 라우팅은 어떤 작업 구조를 선택할지 결정하고, 병렬 처리는 그 구조 안에서 시간을 줄인다. 하나는 길을 고르고, 다른 하나는 그 길 위의 차선을 늘리는 셈이다.

속도와 정확도를 함께 잡으려면 분기를 잘 설계해야 한다

이번 장의 핵심 문장을 하나만 꼽자면 이것이다. 라우팅과 병렬 처리는 속도를 위한 기술처럼 보이지만, 사실은 정확도를 지키기 위한 기술이기도 하다.

라우팅이 없으면 모든 요청이 범용 경로로 들어간다. 그러면 시스템은 매번 모든 가능성을 조금씩 다 고려하려다 힘이 분산된다. 반대로 적절히 분기하면 필요한 맥락과 도구만 사용하므로 더 정확해질 수 있다.

병렬 처리도 마찬가지다. 단순히 빠르게 끝내는 것만이 목적이라면 위험하다. 하지만 서로 다른 정보원을 동시에 조회하고, 서로 다른 관점에서 분석한 뒤, 마지막에 종합하면 오히려 더 풍부하고 균형 잡힌 결과를 만들 수 있다.

다만 이 모든 것은 분기 설계가 좋아야 가능하다. 너무 많은 경로는 혼란을 만들고, 너무 세밀한 병렬화는 조각난 결과만 남긴다. 결국 중요한 것은 속도 그 자체가 아니라, 어디서 단순화하고 어디서 깊이를 더할지 결정하는 감각이다.

예시 1: 고객 지원 에이전트의 분기 설계

고객 지원 시스템은 라우팅의 가치를 보여주기 좋은 예다. 모든 문의를 같은 방식으로 처리하면 비용도 높고 실수도 많다.

예를 들어 첫 분기는 이렇게 잡을 수 있다. 배송 조회, 계정 문제, 환불 및 정책 문의, 불만 접수, 사람 상담 요청. 여기서 배송 조회는 주문 시스템 조회 도구가 핵심이고, 계정 문제는 인증 상태 확인이 중요하다. 환불 문의는 정책 문서 검토가 필수일 수 있다. 불만 접수는 감정적으로 민감하므로 정중한 응대와 사람 연결 기준이 중요하다.

이 구조에서는 단순 배송 조회는 빠른 경로로 보낼 수 있다. 반면 환불 문의는 정책 검색, 주문 상태 조회, 예외 조건 확인을 병렬로 수행한 뒤 응답을 만들 수 있다. 사람 상담 요청은 굳이 복잡한 자동화 경로를 태우지 않고 바로 전환할 수도 있다.

여기서 중요한 것은 경로마다 성공 기준이 다르다는 점이다. 배송 조회는 속도가 중요하지만, 환불 문의는 정책 정확성이 더 중요하다. 라우팅은 바로 이런 차이를 시스템에 반영하는 방식이다.

예시 2: 긴 문서 분석에서의 병렬 처리

긴 보고서나 회의록을 다룰 때 병렬 처리는 특히 강하다. 하나의 긴 문서를 한 번에 읽고 모든 것을 해결하려 하면 놓치는 것이 생기기 쉽다. 그렇다고 무조건 잘게 쪼개기만 하면 전체 맥락이 흐려진다. 그래서 부분 분석과 최종 합성의 균형이 중요하다.

예를 들어 100페이지짜리 보고서를 분석한다고 해보자. 문서를 섹션별로 나눠 병렬로 핵심 주장, 수치, 리스크, 실행 항목을 추출할 수 있다. 이 단계는 동시에 진행해도 된다. 하지만 마지막에는 전체 문서 차원에서 우선순위를 재정렬해야 한다. 어떤 리스크가 가장 큰지, 어떤 수치가 결론을 뒤집는지, 서로 충돌하는 부분은 없는지 다시 봐야 한다.

즉, 병렬 처리는 부분 이해를 빠르게 만들지만, 최종 이해는 다시 중앙에서 모아야 한다. 부분 요약만 잘했다고 전체 요약이 자동으로 좋아지지는 않는다. 병렬화 이후의 통합 사고가 반드시 필요하다.

예시 3: 코드 리뷰 보조 시스템

코드 리뷰 보조 에이전트도 라우팅과 병렬 처리의 좋은 사례다. 모든 코드 변경을 같은 깊이로 분석할 필요는 없다. 문서 파일 변경, 테스트 코드 변경, 결제 로직 변경은 위험도가 다르기 때문이다.

라우터는 먼저 변경 범위를 보고 위험도를 분류할 수 있다. UI 텍스트 수정이면 가벼운 경로로, 인증이나 결제 관련 변경이면 심층 검토 경로로 보낸다. 심층 검토 경로에 들어간 경우에는 병렬로 여러 검사를 돌릴 수 있다. 예를 들어 하나는 보안 관점, 하나는 성능 관점, 하나는 테스트 누락 관점에서 각각 살핀다.

마지막 합성 단계에서는 이 결과를 받아 "반드시 수정할 문제", "권장 개선", "참고 의견"으로 정리할 수 있다. 이렇게 하면 단순 파일 변경에는 과한 비용을 쓰지 않으면서도, 위험한 변경에는 더 많은 눈을 붙일 수 있다.

라우팅 설계에서 자주 하는 실수

라우팅은 좋아 보이기 쉬워서 과하게 설계하기도 쉽다. 특히 다음 실수가 자주 나타난다.

• 분기 수를 너무 많이 만든다.

• 각 경로의 차이가 불분명하다.

• 라우터가 애매한 경우를 처리하지 못한다.

• 잘못 분기됐을 때 되돌아오는 길이 없다.

• 분기 정확도를 측정하지 않는다.

특히 마지막이 중요하다. 시스템 설계 문서에는 멋진 경로도가 그려져 있지만, 실제로는 요청의 30퍼센트가 잘못된 길로 들어갈 수도 있다. 그러면 뒤 단계가 아무리 좋아도 전체 품질은 흔들린다. 라우팅은 앞단에서 일어나는 일이라 사소해 보이지만, 실제로는 전체 구조의 출발점이다. 앞에서 길을 잘못 들면 뒤에서 고생이 커진다.

좋은 라우팅 시스템은 오분류를 전제로 설계한다. 잘못 들어간 요청을 다시 분기할 수 있게 하거나, 확신이 낮으면 보수적인 경로로 보내거나, 사람 검토를 붙이는 식으로 피해를 줄여야 한다.

병렬 처리에서 자주 하는 실수

병렬 처리의 가장 흔한 실수는 동시에 돌릴 수 있다는 이유만으로 병렬화하는 것이다. 독립성이 없는 작업을 억지로 병렬화하면 결국 뒤에서 다시 큰 비용을 치른다. 앞 결과를 알아야 하는데 모른 채 시작해버리면, 나중에 재실행이 필요하거나 엉뚱한 결과가 나온다.

또 하나의 흔한 문제는 합성 단계를 너무 가볍게 보는 것이다. 각각의 병렬 결과는 그럴듯한데, 최종 응답은 산만하고 중복이 많고 결론이 흐릿해지는 경우가 많다. 이것은 대개 합성기가 약하기 때문이다.

세 번째 문제는 공유 컨텍스트의 불일치다. 병렬 작업들이 각자 다른 버전의 정보나 서로 다른 가정을 기준으로 일하면 마지막에 충돌이 생긴다. 예를 들어 한 경로는 최신 주문 상태를 보고, 다른 경로는 이전 캐시 상태를 보면 응답이 엇갈릴 수 있다.

병렬 처리는 빠른 대신, 합의가 필요하다. 여러 사람이 동시에 회의 자료를 만들면 속도는 빨라지지만, 마지막에 용어와 숫자를 맞추는 사람이 반드시 필요하다. 시스템도 똑같다.

라우터와 합성기의 출력은 구조화할수록 좋다

프롬프트 체이닝에서도 중간 산출물 구조화가 중요했지만, 라우팅과 병렬 처리에서는 더 중요하다. 라우터가 애매한 자연어 설명을 남기면 이후 단계가 불안정해진다. 병렬 작업의 결과도 제각각 서술되면 합성기가 힘들어진다.

예를 들어 라우터는 최소한 경로 이름, 확신 수준, 이유 요약 정도를 구조화해 내는 것이 좋다. 병렬 분석 결과도 항목별로 정리되어야 한다. 주장, 근거, 위험, 필요한 후속 조치처럼 틀을 맞추면 마지막 종합 단계가 훨씬 쉬워진다.

에이전트 시스템은 결국 정보 전달의 연속이다. 사람이 읽기 좋은 것과 기계가 다음 단계에 넘기기 좋은 것은 종종 다르다. 실전에서는 둘 모두를 고려해 구조를 잡아야 한다.

라우팅과 병렬 처리에도 실패 복구가 필요하다

분기 설계는 성공 시나리오만 그리면 안 된다. 라우터가 잘못 판단할 수도 있고, 병렬 작업 중 하나가 실패할 수도 있다. 이런 상황을 미리 생각해두지 않으면 시스템은 예상보다 쉽게 무너진다.

라우팅 실패에 대한 기본 대응은 세 가지 정도로 생각할 수 있다. 안전한 기본 경로로 보내기, 더 넓은 검토 경로로 올리기, 사람에게 넘기기다. 병렬 처리 실패에 대해서도 선택지가 필요하다. 일부 결과만으로 진행할지, 실패한 작업만 재시도할지, 전체를 중단할지 정해야 한다.

예를 들어 다섯 개의 데이터 소스를 병렬 조회하는데 하나가 일시적으로 실패했다면, 나머지 네 개 결과로 먼저 초안을 만들고 실패한 하나만 재시도할 수 있다. 반면 결제 승인처럼 정확성이 절대 중요한 작업이라면 하나라도 실패하면 전체를 멈추는 편이 맞을 수 있다.

즉, 실패 복구 정책은 작업의 위험도와 직결된다. 병렬화 구조가 늘 빠르다고 좋은 것이 아니라, 실패했을 때 어떤 품질로 어떻게 돌아설지까지 포함해 설계해야 한다.

언제 병렬화하지 말아야 하는가

병렬 처리의 유혹은 강하다. 하지만 어떤 작업은 순차적으로 가는 편이 맞다.

먼저, 이전 단계의 판단이 다음 단계의 해석을 결정하는 경우다. 예를 들어 법률 문서에서 쟁점을 추출한 뒤 그 쟁점별 판례를 찾는 작업은 순서가 중요하다. 쟁점을 모른 채 판례 검색을 병렬로 시작하면 엉뚱한 자료만 많이 모일 수 있다.

다음으로, 작업 간 충돌 가능성이 큰 경우다. 같은 상태를 수정하는 여러 행동을 동시에 실행하면 순서 문제가 발생할 수 있다. 예를 들어 한쪽은 예약을 변경하고, 다른 쪽은 취소를 시도하면 상태가 꼬인다.

마지막으로, 합성 비용이 실행 시간 절감을 갉아먹는 경우다. 작은 작업을 너무 많이 병렬화하면 실행은 빨라졌는데 마지막 정리 비용이 더 커질 수 있다. 다섯 명이 동시에 요리했는데 설거지와 상차림 때문에 더 오래 걸리는 상황과 비슷하다.

실전 설계 감각: 먼저 하나의 경로로 만들고, 그다음 갈라라

라우팅과 병렬 처리는 강력하지만, 처음부터 복잡한 분기도를 만드는 것은 권하지 않는다. 좋은 접근은 먼저 가장 단순한 단일 경로를 만들고, 어디서 병목이 생기고 어디서 과잉 처리가 생기는지 본 뒤, 그 지점에만 분기와 병렬화를 도입하는 것이다.

예를 들어 모든 요청이 하나의 체인으로 들어가는데, 특정 유형만 유독 느리거나 정확도가 낮다면 그것을 따로 빼는 것이 자연스럽다. 또는 최종 답변 전에 여러 조회가 순차적으로 일어나 지연이 크다면 그 부분만 병렬화할 수 있다.

즉, 분기는 처음부터 예술 작품처럼 설계하는 것이 아니라 실제 문제를 해결하기 위해 추가하는 것이 좋다. 시스템 구조는 멋있어 보이는 것보다 고쳐 쓰기 쉬운 것이 중요하다.

다음 장과의 연결: 분기에서 협업 구조로

이번 장에서는 요청을 어느 길로 보낼지 결정하는 라우팅과, 독립적인 일을 동시에 처리하는 병렬화의 기본 원리를 살펴봤다. 핵심은 단순하다. 모든 요청을 같은 방식으로 다루지 말고, 필요한 일만 적절한 경로에서 처리하라는 것이다.

프롬프트 체이닝이 일을 순서대로 나누는 기술이었다면, 라우팅과 병렬 처리는 흐름을 갈라 보내고 다시 모으는 기술이다. 이 감각이 생기면 시스템은 훨씬 유연해진다. 쉬운 일은 빨리 끝내고, 어려운 일은 더 많은 검토를 거치게 만들 수 있다.

다음 장에서는 이 생각을 한 단계 더 밀어붙여 본다. 단순히 경로를 나누는 수준을 넘어, 중앙 조정자가 일을 여러 작업자에게 배분하고 결과를 다시 합치는 구조를 살펴볼 것이다. 즉, 흐름의 분기와 병렬화를 보다 명시적인 협업 패턴으로 발전시킨 형태가 바로 Orchestrator-Workers 패턴이다.