멀티에이전트를 버리고 단일 에이전트로: 제약 분석 파이프라인 재설계 교훈

핵심 메시지

• 분석가의 업무 흐름(신호 탐지→원인→액션→전망)을 단계마다 별도 에이전트로 나눴더니, 각 에이전트는 맞는 사실을 뽑아도 전체를 책임지는 주체가 없어 결론이 어긋났다.
• 실패의 원인은 LLM이 아니라 일을 쪼갠 방식이었다. 결정론적 작업까지 에이전트에 맡기고, 에이전트 간 인계에서 맥락이 사라지고, 공통된 도메인 지식이 없었다.
• 신호 탐지 같은 결정론적 작업은 통계 파이프라인으로 분리하고, 추론과 판단은 단일 에이전트가 끝까지 책임지도록 통합했다.
• 지식 그래프를 단순 조회용이 아니라 에이전트의 탐색 경로를 제한하는 컨트롤 플레인으로 사용해, 그래프의 각 간선을 검증할 가설로 다뤘다.
• 재설계 후, 분석가가 3~4주 걸리던 분석을 20~30분 만에 비슷한 수준으로 만들어냈다.

쉽게 이해하기

발표자들은 여러 대형 제약사와 일하는 기술 기업 ZS에서 AI 엔지니어링을 이끄는 사람들이다. 제약 사업은 크게 신약을 발굴하고 임상시험을 하는 R&D와, 만들어진 약을 환자에게 전달하는 상용(commercial) 영역으로 나뉜다. 상용 영역에서는 브랜드(약)의 시장별 성과, 영업 담당자의 활동 효과, 환자의 약 채택 여정, 치료제 전환 같은 것을 끊임없이 분석한다.

이 분석 업무는 보통 네 단계로 진행된다. 첫째 신호 탐지 — 예컨대 특정 지역에서 처방이 줄어드는 변화를 포착한다. 둘째 원인 규명 — 경쟁 약 등장, 보험사의 급여 등급 하향, 영업 담당자의 활동 부족 등 왜 그런지 찾는다. 셋째 액션 결정 — 예를 들어 해당 지역에 영업 인력을 늘릴지 정한다. 넷째 전망 — 그 조치로 매출이 개선될지 내다본다.

팀은 이 네 단계를 그대로 흉내 내 단계마다 에이전트를 두었다. 신호 탐지 에이전트, 원인 규명을 위한 두 에이전트(문제가 어느 지역·보험사에 집중됐는지 찾는 소스 로컬라이제이션 에이전트와 실제 원인을 짚는 드라이버 어트리뷰션 에이전트), 그리고 액션과 전망을 정리하는 신서시스 에이전트를 두고, 이들을 오케스트레이터 에이전트가 연결했다.

시스템은 “정보 패킷”을 만들어냈다. 예: 어느 지역에서 4주 동안 처방이 18% 감소, 원인은 보험사가 이 약을 낮은 급여 등급으로 옮겨 환자 부담이 커졌기 때문, 액션은 영업 담당자를 더 보내 의사와 대화하게 하라, 전망은 매출이 오를 것. 겉보기엔 그럴듯했지만 자세히 보면 앞뒤가 맞지 않았다. 원인은 보험(급여) 문제라고 제대로 짚어 놓고, 액션은 그 보험 축을 건드리지 않고 그냥 영업 인력만 늘리라고 했고, 액션이 틀렸으니 전망도 맞지 않았다.

핵심 문제는 각 에이전트가 부분적으로는 옳은 사실을 뽑아냈지만, 처음부터 끝까지 전체 그림을 이해하고 책임지는 단일 주체가 없었다는 점이다.

주요 인사이트

• 실패의 근본 원인은 모델 성능이 아니라 일을 쪼갠 방식이었다. 분석가의 조직 구조를 그대로 에이전트 구조로 옮긴 것이 화근이었다.
• 매출 하락 같은 신호 탐지는 통계로 처리할 수 있는 결정론적 작업인데, 이를 언어 모델에 맡기니 어떤 때는 통계를 쓰고 어떤 때는 대충 보고 노이즈를 신호로 착각했다.
• 에이전트 사이의 잦은 맥락 인계에서 정보가 유실됐다. 원인을 제대로 찾은 에이전트의 판단이 다음 에이전트로 넘어가며 보험 급여 하락의 중요도가 사라졌다.
• 팀은 위상·인계 스키마를 다시 설계하는 대신, 빈 디렉터리에서 Claude Code에 bash와 데이터베이스만 주고 실제 신호를 던져 그 동작을 관찰하며 해법을 찾았다.
• 지식 그래프는 데이터 조회 수단이 아니라 통제면이다. 그래프가 에이전트가 볼 수 있는 것, 갈 수 있는 경로, 세울 수 있는 가설을 규정해 탐색 공간을 유계로 좁힌다.

자주 묻는 질문

관련 AI 소식