핵심 요약 (Key Takeaways)

데이터 소스를 추상화(Abstracting)하는 것이 멀티 에이전트 시스템을 확장 가능하게 만듭니다. Madrigal은 모든 데이터 소스를 일관된 도구 인터페이스(tool interface)로 정규화했습니다. 에이전트(Agents)는 데이터가 어디에서 왔는지 신경 쓰지 않고 그저 사용할 뿐입니다. 이러한 추상화 덕분에 오케스트레이션 로직(orchestration logic)을 다시 작성하지 않고도 새로운 도메인을 추가할 수 있습니다.

모듈형 기술(Modular skills)은 단일 사용 사례를 플랫폼으로 변화시킵니다. Madrigal은 워크플로(workflows)를 하드코딩하는 대신, 각 기능을 교체 가능한 기술(skill)로 구축했습니다. 새로운 요구사항이 발생했을 때, 그들은 새로운 시스템이 아닌 새로운 기술을 정의했습니다. 이를 통해 새로운 사용 사례의 개발 기간은 몇 주에서 몇 시간으로 단축되었으며, 범위가 확장되어도 배포 복잡성은 증가하지 않았습니다.

관측성(Observability)은 프로토타입과 프로덕션 사이의 루프를 완성합니다. LangSmith 트레이싱(tracing)은 Madrigal에 모든 도구 호출(tool call), 검색된 청크(retrieved chunk), 그리고 에이전트의 결정에 대한 가시성을 제공했습니다. 더 중요한 것은, 프로덕션에서의 실패 사례가 평가 스위트(eval suite)로 자동 피드백되어 시스템이 합성 테스트 케이스(synthetic test cases)가 아닌 실제 오류로부터 학습할 수 있게 했다는 점입니다.

이 글은 Madrigal Pharmaceuticals의 AI 및 데이터 과학 글로벌 책임자인 Parth Patel과 Madrigal Pharmaceuticals의 CIO인 Ron Filippo가 작성한 게스트 포스트입니다.

At Madrigal Pharmaceuticals, Inc.에서 우리는 기업용 멀티 에이전트(multi-agentic) 플랫폼을 구축하려는 목적으로 시작하지 않았습니다. 대부분의 기업용 시스템은 플랫폼으로 시작하지 않습니다. 질문에서 시작합니다.

우리의 시작은 제약 회사로서의 핵심 질문이었습니다: 어떻게 하면 다양한 데이터 세트로부터 정보를 대규모로 통합, 검색 및 합성할 수 있을까.

이를 위해서는 여러 소스에서 정보를 가져오고, 구조화된 사고(structured thinking)를 적용하며, 신뢰할 수 있는 답변을 생성하는 워크플로를 구축해야 했습니다.

처음에는 단일 사용 사례처럼 보였습니다. 하지만 우리는 많은 문제를 동일한 방식으로 해결할 수 있는 더 일반적인 에이전트 솔루션(agentic solution)을 구축하고 있다는 사실을 빠르게 깨달았습니다. 즉, 다음과 같은 작업을 수행할 수 있는 시스템입니다:

• 소스 전반에 걸친 검색 (search across sources)
• 구조화된 기준에 따른 추론 (reason over structured criteria)
• 대규모 출력 합성 (synthesize outputs at scale)
• 자율적 운영 (operate autonomously)

그 아이디어가 우리 기업용 멀티 에이전트(multi-agentic) 플랫폼의 기반이 되었습니다.

우리는 Madrigal의 직원들이 적절한 접근 제어 (access controls) 내에서 기업 전반에 흩어져 있는 관련 데이터를 쉽게 검색, 분석 및 합성할 수 있도록 하면서, 모든 응답에 명확한 인용 (citation)이 포함되도록 하고 싶었습니다. 이 플랫폼은 역할 기반 권한 (role-based permissions) 및 데이터 거버넌스 가드레일 (data governance guardrails)을 갖추도록 설계되어 사용자가 권한을 부여받은 정보에만 접근할 수 있습니다. 우리의 멀티 에이전트 (multi-agentic) 플랫폼에 대한 신뢰를 구축함으로써, Madrigal의 사용자들은 우리의 북극성 핵심 가치(north star core value)인 '우리가 하는 모든 일의 중심에 MASH 환자를 두는 것'에 집중할 수 있습니다.

데이터 사일로 (Data Silos) 해소

제약 등급 (pharmaceutical-grade)의 멀티 에이전트 플랫폼을 구축하는 데에는 오류의 여지가 있어서는 안 됩니다. 우리는 적절한 에이전트 (agent)가 올바른 데이터를 정확하게 분석하도록 보장해야 합니다. 하지만 여타 기업과 마찬가지로, 정보는 구조화된 시스템 (structured systems), 비구조화된 문서 (unstructured documents), 외부 소스, 실시간 API 등 모든 곳에 흩어져 있습니다. 각각은 유용하지만 서로 단절되어 있습니다.

우리는 멀티 에이전트 플랫폼에서 사용할 수 있는 병렬화 가능한 도구 호출 (parallelizable tool calls) 제품군을 통해 단절된 데이터 소스들을 하나로 엮었습니다. 이 과정에서 기업용 시스템의 가장 큰 제약 중 하나는 모든 데이터 소스가 서로 다른 형식, 다른 접근 패턴, 다른 기대치를 가지는 등 각기 다르게 동작한다는 점입니다. 우리는 이러한 차이점을 에이전트들에게 보이지 않게 만듦으로써 이 문제를 해결했습니다. 데이터가 어디에서 오든 상관없이, 데이터는 정규화 (normalized)되어 동일한 보안 데이터 웨어하우스 (data warehouse)에 저장되며, 일관된 도구 인터페이스 (tool interface)를 통해 접근할 수 있게 됩니다. 에이전트의 관점에서는 그저 사용할 수 있는 정보일 뿐입니다. 이러한 추상화 (abstraction) 덕분에 시스템은 매번 로직을 다시 작성하지 않고도 여러 도메인에 걸쳐 작동할 수 있습니다.

LangChain과 LangGraph는 구축을 위한 최적의 장소였습니다

LangChain 프레임워크와 LangSmith 플랫폼의 결합은 우리 팀에게 단순한 도구 세트 그 이상입니다. 이는 우리의 프로세스를 자동화하는 플랫폼 철학을 나타냅니다.

전체 파이프라인의 가시성(visibility), 반복적인 개발 주기(iterative development cycle), 그리고 모니터링(monitoring)을 통해 우리는 엔터프라이즈급 프로덕션 시스템(production systems)이 요구하는 사항을 타협하지 않으면서도, 오픈 소스의 커뮤니티 주도형 혁신을 누릴 수 있었습니다.

LangChain 프레임워크의 **개발자 경험(developer experience)**은 일반적인 에이전트 패턴 및 기능(심층 에이전트(deep agents), 미들웨어(middleware), 기술(skills) 등)과 통합되어 있습니다. 이는 우리가 에이전트 프레임워크를 직접 만드는 것이 아니라, 그 위에 제약(Pharma) 인텔리전스를 구축하고 있음을 의미합니다.

이 모든 것은 배포(deployment) 및 확장(scale)과 네이티브하게 통합되어 있습니다. LangSmith 배포를 통해 이러한 에이전트들은 회사 전역에서 즉시 사용 가능해지며, 이는 소규모 팀이 흔히 겪는 병목 현상을 해결해 줍니다.

우리가 *플랫폼 철학(platform philosophy)*이라고 말할 때, 이는 도메인 특화 추론(domain-specific reasoning)에 대한 집중부터 즉각적인 배포, 모니터링, 그리고 트레이싱(tracing)에 이르기까지 우리가 필요로 했던 요소들이 어떻게 하나로 결합되는지를 의미합니다. 특히 다음과 같습니다:

• 우리는 **대규모 멀티 에이전트 조정(multi-agent coordination at scale)**을 처리할 수 있는 프레임워크가 필요했습니다.
• LangSmith는 모든 행동, 결정, 단계 뒤에서 **전체적으로 추적 가능한 파이프라인 가시성(full traceable pipeline visibility)**을 제공했습니다.
• LangChain 프레임워크는 확신을 가지고 **반복적인 개발(iterative development)**을 가능하게 했습니다. 작은 변화만으로도 가시적인 결과를 얻을 수 있었습니다.
• LangSmith는 **배포 및 CI/CD 워크플로(workflows)**를 통해 일반적인 엔터프라이즈 문제의 한 카테고리를 완전히 제거함으로써, 프로토타입에서 일상적인 기업용 사용으로 넘어가는 간극을 몇 달이 아닌 몇 주 만에 메울 수 있도록 도왔습니다.
• LangSmith의 예상치 못한 이점은 잘 정의된 API 엔드포인트를 통한 **즉시 배포 가능한 UI 통합(ready-to-deploy UI integrations)**이었습니다.
• LangSmith 관측성(Observability)은 **실제 사용 모니터링(real-world usage monitoring)**을 가능하게 하여 공통적인 사용 사례와 마찰 지점(friction points)을 식별할 수 있게 해주었습니다.

LangChain 팀은 프로세스 전반에 걸쳐 고품질의 개발자 경험을 보장하는 진정한 사고 파트너(thought partner) 역할을 수행했습니다.

하나의 시스템에서 여러 에이전트로

다양한 데이터를 분석하고 모든 것을 종합할 수 있는 단일 시스템을 구축하는 것은 복잡성이 증가함에 따라 빠르게 한계에 부딪힙니다. 대신, 우리는 다른 모델에 집중했습니다. 바로 하나의 거대한 목표를 향해 각자 한 가지 일을 잘 수행하는 여러 에이전트(Agents)가 조화롭게 협력하는 모델입니다. 어떤 에이전트는 검색을 수행하고, 다른 에이전트는 분석을 하며, 또 다른 에이전트는 종합을 수행합니다. 그리고 이들 위에는 다양한 데이터셋을 정확하게 분석하고 종합하는 작업이 어떻게 수행될지 결정하는 오케스트레이터(Orchestrator)가 자리 잡고 있습니다.

LangChain의 DeepAgents 에이전트 하네스(agentic harness)를 통해 우리는 오케스트레이션(orchestration)과 병렬 실행(parallel execution)을 쉽게 구현할 수 있었습니다. 이 하네스에는 가상 파일 시스템(virtual filesystem), 컨텍스트 관리(context management), 모듈형 기술 역량(modular skill capabilities), 체크포인팅(checkpointing)과 같은 기능들이 기본적으로 포함되어 있습니다. 덕분에 우리는 에이전트 조정의 메커니즘이 아니라, 제약 산업을 염두에 둔 맞춤형 에이전트를 구축하는 데 집중할 수 있었습니다.

이 하네스를 통해 시스템은 분할 정복(divide and conquer)을 수행할 수 있습니다. 지능을 한 곳에 강제로 몰아넣는 대신, 지능을 분산시킨 후 이를 조정하는 방식입니다. 이는 인간의 뇌가 작동하는 방식과 유사합니다.

오케스트레이터의 역할

오케스트레이터는 의도(intent)가 실행(execution)과 만나는 지점입니다. 오케스트레이터는 작업을 수신하고 다음에 무엇이 일어나야 하는지를 결정합니다.

• 어떤 역량(capabilities)이 필요한지
• 어떤 에이전트가 실행되어야 하는지
• 무엇이 병렬로 수행되어야 하며, 언제 모든 것을 다시 하나로 모아야 하는지

오케스트레이터가 모든 도메인의 세부 사항을 알 필요는 없습니다. 단지 문제를 해결하기 위해 솔루션을 어떻게 라우팅(route)할지만 알면 됩니다. 이러한 분리가 시스템의 유연성을 유지해 줍니다.

연구 방법과 요구 사항은 기업 전반에 걸쳐 다양하기 때문에, 오케스트레이터는 이러한 차이를 반영하는 모듈형 워크플로우(workflows) 세트를 중심으로 구축되었습니다. 새로운 유스케이스(use cases)가 등장하면, 시스템은 오케스트레이터 자체의 복잡성을 높이는 대신 *기술(skill)*의 형태로 새로운 워크플로우를 추가함으로써 확장됩니다.

기술(Skills): 재사용성의 핵심

시스템이 하나의 워크플로우에서 작동하게 되자, 다음 질문이 빠르게 뒤따랐습니다. '다른 것도 할 수 있을까?'

로직을 하드코딩(hardcoding)하는 대신, Anthropic의 스킬 (skills) 접근 방식에 기반한 모듈형 기능(modular capabilities)을 도입했습니다. 각 스킬은 특정 유형의 문제에 어떻게 접근할지를 정의합니다. 즉, 무엇을 찾아야 하는지, 어떻게 추론해야 하는지, 그리고 바람직한 출력(output)은 어떤 모습인지 등을 정의합니다. 오케스트레이터(orchestrator)는 단순히 적절한 시점에 적절한 스킬을 로드하기만 하면 됩니다. 이는 새로운 유스케이스(use case)를 추가할 때 시스템을 재구축할 필요가 없음을 의미하며, 단지 새로운 사고 방식(way of thinking)을 정의하기만 하면 된다는 뜻입니다.

병렬성(parallelism)이 게임의 판도를 바꾸는 이유

우리가 가장 먼저 깨달은 것 중 하나는 대부분의 복잡한 작업이 순차적으로(sequentially) 이루어질 필요가 없다는 점입니다. 만약 어떤 작업이 여러 각도를 탐색하거나, 여러 소스를 쿼리(query)하거나, 서로 다른 차원을 분석하는 것을 포함한다면, 이를 한 번에 한 단계씩 수행할 이유가 없습니다.

여러 에이전트(agent)가 병렬로 실행되며, 각 에이전트는 문제의 서로 다른 부분에 집중합니다. 시스템이 다시 하나로 합쳐질 때쯤에는 이미 완성된 형태의 작업 조각들이 결합됩니다. 오케스트레이션 에이전트(orchestration agent)는 연구 질문을 세 부분으로 나누어 세 명의 서브 에이전트(sub-agent)에게 전달할 수 있으며, 이들은 각자의 작업 내에서 개별 데이터셋(dataset)에 대한 분석을 병렬화할 수 있습니다. 이는 지연 시간(latency)을 줄이면서 정확도와 범위를 높여줍니다.

협업 메모리를 위한 공유 워크스페이스(shared workspace)

병렬 시스템은 각 조각들이 깔끔하게 다시 합쳐질 수 있을 때만 작동합니다. 이를 가능하게 하기 위해, 우리는 딥 에이전트(deep agents)에 내장된 파일 시스템(filesystem)에 크게 의존했습니다. 이는 모든 에이전트가 자신이 발견한 것을 기록하고, 다른 에이전트가 이미 수행한 내용을 읽을 수 있는 공간입니다.

이 공간은 시스템의 메모리(memory)가 됩니다. 모든 결과가 저장되고, 모든 소스(source)가 추적되며, 모든 중간 단계(intermediate step)를 재사용할 수 있습니다. 에이전트 간에 정보를 직접 전달하는 대신, 모든 것이 이 공유 레이어(shared layer)를 통해 흐르게 함으로써 시스템이 확장되더라도 조정(coordination) 과정을 단순하게 유지합니다. 예를 들어, 사용자가 에이전트에게 모든 소스를 확인하라고 요청할 경우, 여러 데이터셋에 걸쳐 수백 개의 소스가 분석되고 합성되었더라도 시스템은 응답에 포함된 모든 데이터 포인트를 정확히 어디에서 찾을 수 있는지 알고 있습니다. ** **

LangSmith를 통한 관측성(Observability) 및 평가(evals)

여러 데이터 소스에 걸쳐 구축할 때 가장 어려운 부분은 검색 (Retrieval) 자체가 아니라, 검색이 제대로 작동하고 있는지 아는 것입니다. 응답이 틀렸을 때, 그것이 인덱스 (Index)에 데이터가 없기 때문인가요? 쿼리 (Query)가 데이터를 찾아내지 못한 것인가요? 아니면 에이전트 (Agent)가 신뢰해서는 안 될 소스를 신뢰했기 때문인가요?** **

*트레이싱 (Tracing)*은 에이전트적 행동 (Agentic behavior)에 대한 실질적인 분석을 가능하게 했습니다. LangSmith에서 우리 시스템의 트레이스 (Traces)를 처음 확인했을 때, 이전의 가시성 (Visibility)이 얼마나 제한적이었는지 깨달았습니다. 우리는 자극-반응 (Stimulus-response) 행동만을 관찰할 수 있었을 뿐, 실제 인지 (Cognition) 과정은 볼 수 없었습니다. LangSmith에서의 트레이싱은 우리 에이전트 AI 시스템을 대상으로 기초 심리학에서 신경 영상 (Neuroimaging) 단계로 넘어가는 것과 같은 느낌을 줍니다. 우리는 시스템의 뇌 내부에서 실제로 어떤 일이 일어나고 있는지 볼 수 있었습니다.

우리는 LangSmith의 에이전트 평가 프레임워크 (Agent evaluation framework)를 사용하여 전체 에이전트 실행에 대한 트레이스 수준의 평가 (Trace-level evals)부터 시작했습니다. 이때 정확한 경로보다는 결과를 점수화하도록 설계된, 실제 최종 사용자의 비즈니스 피드백 양식을 모방한 LLM-as-judge 채점기를 사용했습니다. 모든 도구 호출 (Tool call), 모든 검색된 청크 (Retrieved chunk), 모든 에이전트 결정은 세션 ID (Session ID)별로 태그가 지정되어 가시적으로 나타납니다. 만약 트레이싱이 에이전트 시스템을 위한 신경 영상이라면, LangSmith는 어떤 영역이 어떤 순서로 활성화되었는지, 그리고 그 결과가 타당한지를 보여주는 fMRI (기능적 자기공명영상)와 같습니다.

지속적으로 가장 큰 차이를 만들어낸 부분은 다음과 같습니다. 프로덕션 (Production)에서의 실패 사례가 LangSmith 데이터셋으로 자동 피드백됩니다. 모든 의미 있는 오류는 새로운 테스트 케이스가 됩니다. 평가 스위트 (Eval suite)는 합성 시나리오 (Synthetic scenarios)가 아닌 실제 실패 사례를 통해 성장합니다.

LangSmith를 통한 배포 (Deploying with LangSmith)

엔터프라이즈용 제품을 구축하는 소규모 팀은 실제적인 긴장 상태에 놓여 있습니다. 신뢰성과 확장성 (Scalability)이 필요하지만, 인프라를 운영할 대규모 엔지니어링 팀은 없기 때문입니다.

LangSmith Deploy가 그 해결책을 제시했습니다. 우리는 핵심 로직을 다시 작성하지 않고도 상태 지속성 (State Persistence), 동시 세션 (Concurrent Sessions), 그리고 UI로의 실시간 스트리밍 (Real-time Streaming) 기능을 갖춘 관리형 서비스 (Managed Service)로 우리의 그래프를 배포했습니다. GitHub의 CI/CD 파이프라인이 자동 재배포를 트리거하므로, 수동 단계 없이도 기술 업데이트를 배포할 수 있습니다. 이러한 가속화는 반가운 놀라움이었습니다. 프로토타입에서 엔터프라이즈급 사용으로 넘어가는 데 우리가 예산으로 잡았던 몇 달이 아니라 단 몇 주밖에 걸리지 않았습니다.

도메인 전문가 전반으로의 확장

에이전트 기술 (Agentic skills) 덕분에 Madrigal의 도메인 전문가들에게 개발을 개방할 수 있게 되었습니다. 제약 전문가들은 어떤 증거 계층 (Evidence hierarchies)이 중요한지, 어떤 데이터베이스를 신뢰해야 하는지, 그리고 무엇이 좋은 결과물인지 알고 있습니다. 이러한 피드백 루프는 우리가 이전에 구축했던 그 어떤 것보다 빠릅니다. 사용자가 시스템의 로직에서 무언가를 발견하면, 딥 에이전트 하네스 (Deep agents’ harness)의 모듈성 (Modularity) 덕분에 우리는 어떠한 결점도 쉽게 해결할 수 있습니다.

우리는 현재 Madrigal의 검색, 분석 및 연구 요구 사항을 가능한 한 많이 충족할 수 있도록 플랫폼을 빠르게 확장하는 작업을 진행 중입니다. LangChain과 LangGraph를 구축한 방식 덕분에, 진정한 가치는 복리 효과 (Compounding effect)에서 나타납니다. 다음과 같은 상황에서 그 효과를 확인할 수 있습니다.

• 일반적으로 몇 주가 소요될 새로운 유스케이스 (Use case) 개발이 몇 시간으로 단축될 때
• 수동 작업이 필요했던 시스템이 자가 유지 (Self-sustaining) 가능해질 때
• 새로운 유스케이스에 새로운 인프라가 필요하지 않을 때
• (그리고 가장 중요한 것은) 후속 배포가 점진적으로 더 빠르게 이루어질 때