• 채널: aiDotEngineer
• 제목: Why We Killed Our Multi-Agent Pipeline — Subbiah Sethuraman and Abhilash Asokan, ZS Associates
• URL: https://www.youtube.com/watch?v=u6jJcIFDLE4
• video_id: u6jJcIFDLE4
• 발표자: Subbiah Sethuraman (ZS, Head of AI Engineering), Abhilash Asokan (ZS, Director of AI Engineering)
• 처리일: 2026-07-23

1계층: 한 줄 핵심 명제

다중 에이전트 파이프라인이 아니라, 데이터·통계·지식 그래프로 경계를 설정하고 단일 에이전트가 end-to-end 추론을 소유하는 구조가 제약산업 상업 분석에서 한 달 걸리던 분석을 20~30분 만에 만들어낼 수 있었다.

2계층: 핵심 주장·근거·수치·사례

• V1은 분석가의 업무 단계를 그대로 모방해 에이전트를 나눴다: 신호 탐지 → 소스 로컬라이제이션 → 드라이버 어트리뷰션 → 종합·액션·아웃룩, 이 모두를 오케스트레이터가 연결.
• V1 출력은 겉보기에 설득력 있었지만 내부적으로 비일관적이었다: "처방이 4주간 특정 지역에서 18% 감소했다"는 신호는 맞았고, 원인도 "보험사(payer)가 약물을 더 낮은 티어로 이동시켜 환자 부담이 커졌다"로 잡았지만, 액션은 "영업 담당자(sales rep)를 더 보내라"로 나왔다. 원인은 보험인데 대응은 영업인 셈.
• 실패 원인은 LLM 성능이 아니라 업무 분할 방식: (1) 신호 탐지라는 결정론적 작업을 LLM에 맡겼고, (2) 에이전트 간 문맥 전달에서 핵심 정보(보험 커버리지 하락의 무게)가 손실되었고, (3) KPI·메트릭·도메인 지식을 공유하지 않아 각 에이전트가 제각각 판단했다.
• 재설계는 "빈 디렉터리 + Claude Code + bash + DB"에서 시작했다: 토폴로지를 먼저 다시 그리지 않고, Claude Code가 실제로 무엇을 하는지 관찰한 뒤 그 행동을 설계에 반영.
• 결정론적 부분을 에이전트 밖으로 분리했다: 통계 기법, 임계값, 우선순위, 가드레일을 갖춘 자동 파이프라인이 데이터를 스캔하고 신호를 큐에 넣으면, 에이전트는 "발견"이 아닌 "조사"에만 집중.
• 추론은 단일 에이전트가 소유하고, 조사만 하위 에이전트에 위임: 병렬성은 유지하되 판단과 추론을 분산시키지 않음. 특정 지역의 rep 활동 같은 한정된 조회만 동적 서브 에이전트로.
• 지식 그래프는 조회표(lookup table)가 아니라 제어 평면(control plane): 엔티티(지역·보험사·계정·브랜드·KPI)와 엣지(관계·드라이버)를 사전에 정의. 각 엣지는 에이전트가 검증하는 가설이며, 이를 통해 탐색 공간을 제한.
• 결과: 50턴 이상의 추론 끝에 분석가가 3~4주 걸리던 결과를 20~30분에 도출.
• 핵심 교훈: 인간의 조직 구조를 그대로 복제하지 말고, 결정론적·에이전트적 영역을 분리하고, end-to-end 추론을 단일 주체가 소유하며, 지식 그래프를 탐색과 판단의 경계로 사용하라.

3계층: 섹션별 상세 전개

0:00~2:32 — 제약 상업 분석과 분석가의 4단계

Subbiah Sethuraman(Suba)가 자신을 ZS의 AI 엔지니어링 책임자로, Abhilash Asokan을 동료 AI 엔지니어링 디렉터로 소개한다. ZS는 글로벌 제약사를 포함한 Top 기업과 일하는 테크 컨설팅 기업이다.

제약 산업에는 두 가지 큰 기능이 있다.

• R&D: 신약 발견과 임상시험.
• Commercial: 만들어진 약을 환자에게 도달시키는 일. 이 안에는 브랜드 실적, 시장별 성과, 영업 담당자(field force/reps) 효율, 환자 여정(patient journey), 치료 전환(therapy switch) 등 수많은 분석이 존재.

분석가가 하는 일을 4단계로 정리했다.

1. Signal detection: 처방 추이, 매출 변화 같은 신호를 포착. 예: "처방이 떨어졌다".
2. Root cause / localization: 신호의 원인과 발생 위치를 특정. 예: 경쟁약 등장, 보험 커버리지 축소, 영업 담당자 활동 부족.
3. Action: 원인에 맞는 행동 결정. 예: 특정 지역 영업 인력 증원.
4. Outlook / synthesis: 행동이 미칠 영향과 향후 실적 전망.

2:33~4:31 — V1: 단계별 에이전트 설계와 그 출력

ZS 팀은 이 4단계를 에이전트로 모방했다.

• Signal detection agent: 신호를 식별.
• Source localization agent: 국가 수준 하락이 지역/보험사/계정 중 어디서 집중되는지 파악.
• Driver attribution agent: 실제 원인이 무엇인지 판단.
• Synthesis agent: 원인에 따른 액션과 아웃룩을 종합.
• Orchestrator agent: 이들을 연결.

V1은 다음처럼 보이는 "정보 패킷"을 출력했다.

• Signal: "브랜드 처방이 특정 지역에서 4주간 18% 감소."
• Reason: "보험사(payer)가 이 약을 더 낮은 티어로 이동시켜 환자에게 비싸졌다."
• Action: "의사들에게 영업 담당자를 더 보내 처방 수를 늘려라."
• Outlook: "이 조치를 취하면 매출이 오를 것."

겉으로는 설득력 있지만, 세부적으로 보면 원인은 보험인데 액션은 영업이라 비일관적이다. 각 에이전트는 사실 하나씩은 맞게 뽑았지만, 전체 그림을 아는 주체가 없었다.

4:32~5:56 — 왜 실패했나: 신호, 핸드오프, 도메인 부재

실패의 책임은 LLM이 아니라 업무 분할 방식에 있었다.

1. 신호 탐지를 LLM에 맡김: 매출 하락처럼 통계로 충분히 뽑을 수 있는 단순 정보를 굳이 언어모델이 찾게 했다. 때로는 통계를 쓰고, 때로는 데이터를 얕게 보고 노이즈까지 신호로 내놓았다.
2. 에이전트 간 문맥 손실: 드라이버 어트리뷰션 에이전트는 원인을 맞게 찾았지만, 종합 에이전트는 "보험 커버리지 하락의 무게"를 제대로 이해하지 못했다. 핸드오프마다 핵심 맥락이 희석.
3. 공유된 도메인 지식 부재: 각 에이전트가 TRX(처방 건수) 같은 메트릭이 무엇인지, KPI 간 관계가 어떻게 되는지 몰랐다. 비즈니스 도메인에 대한 공통 이해가 없어 일관된 판단이 불가능.

5:57~8:04 — 재설계: 빈 디렉터리에서 Claude Code 관찰하기

Abhilash가 등장해 세 가지 문제를 해결한다. 첫 직관은 "다시 설계하자"(토폴로지·스킬·도구·핸드오프 스키마)였지만, 팀은 한발 물러섰다.

대신 빈 디렉터리를 열고 Claude Code에 bash와 데이터베이스만 주어 실제 신호를 던진 뒤, Claude Code가 무엇을 하는지 관찰했다.

관찰에서 나온 핵심 행동:

• Claude Code는 데이터를 보며 스스로 함수를 작성하고 DB를 질의하는 반복을 한다.
• 필요할 때만 짧고 명확한 하위 작업을 동적으로 떼어낸다.
• 복잡한 추론은 자신이 유지한다.

이 경험을 설계에 반영해 더 가벼운 아키텍처를 만들었다.

8:05~9:21 — 신호 탐지를 에이전트 이전으로 분리

신호 탐지는 에이전트가 아니라 결정론적 파이프라인으로 옮겼다.

• 다양한 통계 기법과 임계값, 우선순위, 가드레일을 적용.
• 각 KPI별로 데이터를 스캔해 이상치·추세·변화를 자동 감지.
• 신호가 큐에 들어오는 순간 에이전트가 깨어난다.

즉, 에이전트의 역할은 **"무엇이 일어났는지 찾아내는 것"이 아니라 "왜 일어났는지 조사하는 것"**으로 축소. 이는 신호 탐지의 재현성과 신뢰성을 높이고, 에이전트의 인지 부하를 줄였다.

9:22~11:03 — 단일 에이전트로 추론 통합

이전에는 추론이 여러 에이전트에 흩어져 있었다. 재설계에서는 단일 에이전트가 전체 추론을 소유하도록 했다.

• 병렬성은 그대로 유지. 하지만 판단(judgment)은 분산시키지 않음.
• 특정 지역의 rep 활동이나 특정 테이블 조회 같은 한정된 조사만 하위 에이전트로 동적 위임.
• 하위 에이전트는 결과만 돌려주고, 종합과 판단은 메인 에이전트가 유지.

이 방식은 Claude Code의 실제 동작—"함수를 쓰고 DB를 조회하며 필요할 때만 하위 작업을 떼어냄"—을 그대로 구조화한 것이다.

11:04~마지막 — 지식 그래프를 제어 평면으로

비즈니스 맥락 문제를 해결하기 위해 ZS는 제약 상업 분야 지식 그래프를 구축했다.

• 엔티티: 지리적 단체, 보험사(payer), 계정, 브랜드, KPI, 2차·3차 KPI 등.
• 관계: 지역-보험사, 브랜드-KPI, KPI-KPI 드라이버 관계 등을 사전에 정의.

지식 그래프는 단순한 조회표가 아니라 제어 평면이다.

• 에이전트가 탐색할 수 있는 경로, 검증해야 할 가설, 고려할 차원을 제한.
• 예: "TRX가 전국적으로 감소" → 소스 로컬라이제이션을 통해 지역·보험사·계정 조합 중 어디에 집중되는지 파악 → 원인 파악을 위해 KPI 간 드라이버 관계를 따라 탐색.
• 그래프의 모든 엣지는 하나의 가설. 에이전트는 데이터로 해당 가설을 검증하며 루프를 돈다.
• 가설이 뒷받침되면 그래프를 따라 다음 탐색으로; 반박되면 해당 가지를 버린다.

이 구조로 50턴 이상의 추론 끝에 분석가가 3~4주 걸리던 분석을 20~30분에 도출.

마무리 핵심 takeaway

1. 인간 조직이나 기존 프로세스의 제약을 아키텍처에 그대로 옮기지 말고, 실제 동작에서 구조를 도출하라.
2. 복잡한 워크플로우에는 결정론적 부분과 에이전트적 부분이 있다. 결정론적 부분은 에이전트에게 맡기지 말라.
3. end-to-end 추론은 하나의 에이전트가 소유해야 하며, 필요할 때만 하위 에이전트/도구/스킬을 동적으로 호출하라.
4. 지식 그래프는 단순 조회표가 아니라 에이전트의 탐색과 의사결정을 제어하는 평면으로 설계하라.

4계층: 시사점 및 실행 포인트

• 에이전트 설계는 "역할 분할"이 아니라 "추론 소유"부터 시작해야 한다. 많은 팀이 인간 팀 구조를 모방해 에이전트를 쪼개지만, 그것이 곧 문맥 손실과 비일관성을 낳는다.
• 결정론적 파이프라인과 에이전트 파이프라인의 경계를 명확히 하라. 데이터 스캔·신호 탐지·임계값 비교는 통계/규칙으로, 의미 해석·가설 검증·액션 종합은 에이전트로.
• Claude Code 같은 도구를 "구현 도구"로만 보지 말고 "아키텍처 관찰 도구"로 활용할 수 있다. 빈 디렉터리에서 실제 문제를 던지고 모델이 스스로 푸는 방식을 보면, 필요한 도구·병렬 구조·에이전트 위임 지점이 드러난다.
• 지식 그래프는 도메인 전문가의 암묵지를 구조화한 제어 장치다. 제약처럼 도메인 지식이 복잡하고 관계가 중요한 영역에서, 그래프의 엣지를 가설로 삼으면 에이전트의 탐색 공간과 환각 가능성을 동시에 줄일 수 있다.
• "작은 에이전트 많이"보다 "하나의 추론 주체 + 필요한 조사 위임"이 더 강하다. 병렬 처리는 유지하면서도 판단은 중앙집중식으로.
• 메트릭 정의, KPI 계층, 엔티티 관계를 먼저 문서화/그래프화하라. 에이전트가 데이터에서 관계를 매번 추론하게 하면 비용도 크고 오류도 많다.
• 액션-원인 일관성을 검증하는 평가 파이프라인을 별도로 두라. V1처럼 원인과 액션이 어긋나는 출력이 나오지 않도록, 최종 출력 전에 "원인→액션→아웃룩" 간 논리적 일관성을 자동 검증.
• 장기적으로는 지식 그래프를 지속적으로 업데이트하는 피드백 루프를 만들어라. 새로운 KPI·브랜드·보험 정책 변화가 생길 때 그래프와 통계 파이프라인이 함께 버전업되어야 에이전트의 추론 신뢰도가 유지된다.