Hosted Agents: Novo Nordisk 임상 데이터 분석 에이전트가 자체 인프라를 내려놓은 방법

Novo Nordisk는 임상시험 데이터 분석 에이전트의 런타임을 직접 운영하던 방식에서 Microsoft Foundry hosted agent로 옮겼습니다. 에이전트 로직은 그대로 두고 세션 격리, scaling, 신원, 추적은 플랫폼에 넘긴 것입니다. 따라 하려면 세 가지를 먼저 정해야 합니다. 네트워크 주소 계획, 민감 데이터로 다룰 추적 기록, 그리고 이전 전후에 똑같이 돌릴 전문가 정답 평가 세트입니다.

요약

임상시험 데이터는 보통 시험 프로토콜(시험 전에 정해 둔 분석 계획)이 묻는 질문에 답하도록 분석됩니다. 의료 전문가는 그 밖의 질문도 하고 싶어 합니다. 가설을 시험하고, 환자 집단을 비교하고, 추세를 그려 보고, 다음 연구 방향을 찾는 2차 분석입니다. Novo Nordisk와 Microsoft Frontier Company의 AI Acceleration Studio는 forward-deployed engineering(FDE, 엔지니어가 고객 현장에 들어가 함께 만드는 방식)으로 이 일을 돕는 에이전트를 만들었습니다. 에이전트는 요청을 해석하고, 쓸 수 있는 데이터를 살피고, 분석 코드를 써서 실행하고, 결과를 보고 접근을 고친 뒤 요약과 시각화를 돌려줍니다. 2026년 11월 11일 Microsoft 엔지니어 블로그 Command Line에 실린 이 글은 Microsoft의 Casimir Wierzynski(Engineering GM)와 Jon Malsan(Principal Software Engineer)이 그 에이전트를 다시 구현한 과정을 다룹니다. Novo 쪽에서는 FounData의 Sid Prabhu와 Rasmus S Andersen이 의견을 보탰습니다.

첫 운영 버전은 Azure Container Apps에서 돌았습니다. 대화는 PostgreSQL에 저장하고, 모델이 만든 코드는 Azure Container Apps dynamic sessions(격리된 코드 실행 환경)에서 실행했습니다. 구성 요소를 하나하나 직접 쥐고 있었기에 쓸모를 증명할 수 있었습니다. 그 대신 컨테이너 scaling, 세션 수명 주기, 대화 저장, 실행 격리, 네트워크, 텔레메트리와 그 사이의 연결을 모두 팀이 떠안았습니다. 팀은 이 에이전트를 Foundry hosted agent로 다시 구현했습니다. 운영 모델이 단순해졌고, 세션 격리가 강해졌으며, Foundry의 추적·평가·실험·최적화·거버넌스 도구로 이어지는 길이 생겼습니다. Prabhu는 이 덕분에 인프라를 직접 짓고 돌리지 않고도 연구자 수천 명에게 더 빨리 에이전트를 내놓을 수 있었다고 밝혔습니다. 정확도, 비용, 시간 절감 수치는 원문에서 밝히지 않았습니다. 아래에서는 이 이전을 여섯 가지 메커니즘으로 나누고, 같은 이전을 할 때 필요한 기술·현업 디테일을 덧붙입니다.

핵심 메커니즘

Open-ended Analysis Agent: 정해진 워크플로가 없는 질문을 맡는 에이전트

2차 분석은 질문마다 실행 경로가 달라서 에이전트에 맞는 일입니다. 같은 “두 집단을 비교해 달라”는 요청도 어떤 변수가 있느냐, 첫 결과가 어떻게 나오느냐에 따라 다음 단계가 바뀝니다. 그래서 고정된 파이프라인 대신 네 가지를 묶습니다. 다음 할 일을 정하는 reasoning loop(추론 반복), 임상 분석에 맞춘 domain-specific skills, 데이터를 다루는 data tools, 그리고 가운데 도구인 code execution(코드 실행)입니다. 모델이 쓴 분석 코드와 시각화 코드는 통제된 환경에서만 돕니다. 대화를 관리하고 결과를 보여 주는 일은 바깥 애플리케이션이 맡습니다. 원문은 스킬과 데이터 도구의 세부 목록을 밝히지 않았습니다. 질문 유형이 몇 가지로 정해져 있다면 고정 보고서나 BI 대시보드가 더 쌉니다. 가상 예시를 들면, 연구자가 “체질량지수 구간별로 1차 지표 변화를 나눠 보고 싶다”고 하면 에이전트가 구간을 나누는 코드를 쓰고, 표본이 너무 작은 구간이 나오면 구간을 합쳐 다시 돌리는 식입니다.

Hosted Agent: 에이전트 로직은 팀이, 런타임은 플랫폼이

hosted agent는 팀이 짠 코드를 컨테이너로 묶어 Foundry Agent Service 인프라 위에서 돌리는 방식입니다. 오케스트레이션, 모델, 도구, 런타임 동작은 계속 팀이 정합니다. endpoint, agent identity(에이전트 자체의 신원), 세션별 compute, 상태 저장, scaling, lifecycle(배포와 버전 수명 관리)은 Foundry가 운영합니다. 경계를 옮겼다고 책임이 사라지지는 않습니다. 팀은 여전히 접근 통제를 정하고, 텔레메트리를 줄이고 보호하며, 자기 용도에 맞는 시험을 하고, 에이전트가 부를 수 있는 시스템을 하나하나 검토합니다. Microsoft Agent 365와 붙이면 에이전트 목록, 신원, 접근 통제, lifecycle 거버넌스도 한곳에서 봅니다. 원문은 이 선택을 “에이전트를 다르게 만드는 부분만 직접 짓는다”는 원칙으로 요약합니다.

Session-isolated Sandbox: 세션마다 VM 하나

hosted agent에서는 세션마다 VM 수준으로 격리된 sandbox가 하나씩 붙습니다. compute는 필요할 때 할당되고, 쓰는 동안 유지되며, 설정한 유휴 시간이 지나면 해제됩니다. 세션 파일은 남겨 두었다가 세션을 다시 열 때 복원할 수 있습니다. 규모는 미리 예측한 replica(복제본) 수가 아니라 실제 활성 세션 수를 따라갑니다. 1차 구조에서는 애플리케이션이 세션을 만들 때 따로 scaling되는 실행 환경 풀과 맞물려야 했는데, 이 연결이 필요 없어졌습니다. 격리를 기본 단위로 두는 것이 이 사례에서 특히 중요한 이유는 모델이 생성한 코드가 민감한 임상 데이터를 만지기 때문입니다. 한 연구자의 세션에서 돈 코드가 다른 연구자의 데이터나 파일에 닿을 길을 처음부터 막습니다. Andersen은 세션 격리와 사설 네트워크를 데이터 보호의 핵심 통제로 꼽았습니다.

Network as Product Decision: 서브넷 크기는 처음에 정한다

원문의 첫 교훈은 인프라 선택을 제품 결정으로 다루라는 것입니다. 사설 네트워크, VNet integration, 의존하는 Azure 자원으로의 사설 접근을 쓸지는 초기에 정해야 합니다. hosted agent는 세션 수에 따라 IP 주소를 씁니다. 계정, 프로젝트, 에이전트, 동시 세션, 에이전트 revision이 모두 주소를 차지합니다. 서브넷은 계정 수준에서 한 번 정하면 바꿀 수 없는 참조라서, 범위를 작게 잡으면 나중에 이전 작업을 다시 해야 할 수 있습니다. 원문은 계정 전체의 최대 동시 세션을 추정하고 여유를 더한 뒤, Foundry 자원을 만들기 전에 네트워크 팀을 부르라고 권합니다. 현재 가이드는 운영 환경에 /24 서브넷을 권하고, 작은 배포의 최소 지원 크기로 /27을 둡니다. 인프라 코드는 Azure Verified Modules(검증된 Azure 인프라 모듈)로 반복 가능한 바탕을 깔았지만, 생성된 의존 자원은 따로 확인했습니다. Cosmos DB 같은 자원의 처리량도 예상 동시성과 데이터 접근 패턴에 맞추고, 운영 중 조정은 배포 절차나 runbook(운영 절차서)에 넣습니다.

Navigable Traces: 찾을 수 있고, 보호되는 추적 기록

Foundry 추적은 OpenTelemetry(분산 추적 표준)로 모아 Azure Monitor Application Insights에 저장합니다. 사용자 입력과 출력, 모델 호출, 도구 활동, 토큰 사용량, 지연 시간이 남습니다. 이전하는 동안에는 추적을 Application Insights와 Langfuse(LLM 앱용 관측 도구) 양쪽에 보내 기록이 끊기지 않게 했습니다. 기록을 찾을 수 있게 하는 열쇠는 안정적인 식별자입니다. user, session, conversation, agent version, trace ID를 일관되게 달아야 구성 요소를 넘나들며 한 번의 실행을 따라갈 수 있습니다. 반대로 추적 기록은 그 자체로 민감 데이터입니다. 프롬프트, 출력, 도구 인자와 도구 결과가 담기기 때문입니다. 원문은 접근 통제, 최소 수집, 가림(redaction), 보존 기한을 함께 두라고 말합니다.

Continuous Learning Loop: 이전 중에도 평가를 끊지 않는다

원문이 꼽는 지속 학습 루프는 네 단계입니다. Trace는 실행 한 번에서 무슨 일이 있었는지 설명합니다. Evaluate는 결과를 잽니다. Experiment는 대안끼리 비교합니다. Optimize는 그 근거를 개선 후보로 바꿉니다. 목표는 운영에서 본 문제가 시험을 거친 변경이 되기까지의 거리를 줄이는 것입니다. 이전 중에도 이 루프를 지킨 방법이 단순합니다. 백엔드 계약(입출력 인터페이스)을 바꾸지 않았기에, 평가 프레임워크는 Foundry로 옮긴 에이전트를 예전과 같은 인터페이스로 불렀습니다. 같은 평가 세트를 돌리고 같은 grader(채점기)를 적용했으며, 여기에는 subject matter expert(SME, 해당 분야 전문가)가 만든 golden answer(모범 정답)와의 비교가 들어갑니다. 점수는 세 가지로 쓰였습니다. 이전 기준선, 회귀를 막는 장치, 그리고 지시문·도구·오케스트레이션 변경이 도움이 됐는지 보는 지표입니다. Andersen의 표현으로는 “agent quality is paramount and must be measurable”입니다.

통념과 다른 주장

저자가 든 사례

1차 운영: Azure Container Apps 위의 분석 에이전트

• 상황: Novo Nordisk의 의료 전문가들이 임상시험 데이터를 프로토콜이 정한 질문 밖으로 분석하고 싶어 했습니다.
• 한 일: 에이전트를 Azure Container Apps에 올리고, 대화는 PostgreSQL에 저장하고, 코드 실행은 dynamic sessions sandbox에 맡겼습니다. 이 과정은 앞서 Microsoft 고객 사례로도 소개됐습니다.
• 결과: 구성 요소를 직접 쥔 덕에 쓸모를 증명했습니다. 대신 scaling, 세션 수명, 대화 저장, 격리, 네트워크, 텔레메트리와 그 연결을 팀이 모두 운영해야 했습니다.
• 연결: Open-ended Analysis Agent, Hosted Agent.

재구현: Foundry hosted agent로 연구자 수천 명에게

• 상황: 운영 부담을 줄이면서 모델 생성 코드가 임상 데이터를 만지는 환경의 격리를 더 강하게 해야 했습니다.
• 한 일: 같은 에이전트를 Foundry hosted agent로 다시 구현했습니다. 사설 네트워크를 붙이고, 추적을 Application Insights와 Langfuse에 함께 보내며, 같은 평가 세트로 이전 전후를 비교했습니다.
• 결과: 세션별 격리 compute, 관리형 scaling과 신원, 사설 네트워크, 지속 상태, 추적에서 최적화까지 이어지는 경로를 얻었습니다. Novo는 연구자 수천 명에게 에이전트를 제공한다고 밝혔습니다. 정확도, 비용, 지연 수치는 원문에서 밝히지 않았습니다.
• 연결: Session-isolated Sandbox, Network as Product Decision, Navigable Traces, Continuous Learning Loop.

기술 디테일: 같은 이전을 직접 해 보려면

아래 스키마, 설정값, 계산, 기준은 원문에 없는 내용입니다. 비슷한 분석 에이전트를 관리형 런타임으로 옮길 때 필요한 것을 새로 정리했습니다.

서브넷을 산정하려면 (Network as Product Decision과 연결) 먼저 숫자 세 개를 뽑습니다. 동시에 분석을 돌릴 최대 연구자 수, 연구자 한 명이 동시에 여는 세션 수, 같은 계정에 함께 올릴 에이전트와 revision 수입니다. 세션 하나가 IP를 몇 개 쓰는지는 Foundry 문서의 최신 기준으로 확인해 곱하고, 피크의 2배를 여유로 잡습니다. Azure는 서브넷마다 주소 5개를 예약하므로 /24는 실제로 251개, /27은 27개를 쓸 수 있습니다. 계산 결과가 /27 근처라도 운영 계정이면 /24에서 시작하는 편이 안전합니다. 서브넷을 나중에 바꿀 수 없기 때문입니다.

추적에 안정 식별자를 달려면 (Navigable Traces와 연결) 모든 span(추적의 한 구간)에 같은 속성을 붙입니다. 사용자 ID는 원본 대신 해시값을 씁니다.

{
  "app.user_hash": "u_7f3a91c2",
  "app.session_id": "sess-2026-11-14-0042",
  "app.conversation_id": "conv-118",
  "app.agent_version": "clin-analyst@3.2.0",
  "app.trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "app.dataset_id": "trial-XYZ-adsl-v5",
  "tool.name": "execute_python",
  "tool.exit_code": 0,
  "tool.args_redacted": true,
  "gen_ai.usage.input_tokens": 5120,
  "gen_ai.usage.output_tokens": 840
}

도구 인자와 결과는 기본으로 가리고, 디버깅에 필요하면 짧은 보존 기한(예: 7일)을 둔 별도 저장소에 권한자만 보게 둡니다. 환자 단위 행이 출력에 그대로 찍히지 않도록 code execution 결과는 집계 표와 그림만 돌려주고, 행 수가 작은 셀(예: 10명 미만)은 가리는 규칙을 실행 환경 쪽에 둡니다.

이전 전후를 같은 평가로 비교하려면 (Continuous Learning Loop와 연결) 평가 항목 하나를 아래처럼 저장합니다. 분석 에이전트는 같은 질문에도 매번 다른 코드를 쓰므로 질문마다 3회씩 돌려 편차를 봅니다. 수치 답은 허용 오차(예: 상대 오차 1%) 안이면 정답으로 치고, 서술과 그림은 LLM 채점기가 SME 정답과 비교하되 매주 10~20%를 SME가 다시 봅니다.

{
  "case_id": "secondary-034",
  "question": "치료군과 대조군의 52주 체중 변화율을 연령 3구간으로 나눠 비교",
  "dataset_id": "trial-XYZ-adsl-v5",
  "golden": {"values": {"18-39": -12.1, "40-59": -10.4, "60+": -8.9}, "tolerance_rel": 0.01},
  "expects_chart": true,
  "runtime": "foundry-hosted",
  "runs": 3,
  "verdicts": ["pass", "pass", "partial"],
  "grader": "numeric+llm",
  "agent_version": "clin-analyst@3.2.0"
}

예시의 질문과 수치는 가상입니다. 판정은 질문별 pass 비율이 이전 런타임의 기준선보다 낮아지지 않는지, 3회 결과가 서로 엇갈리는 질문이 늘지 않는지로 합니다.

세션 수명을 정하려면 (Session-isolated Sandbox와 연결) 유휴 해제 시간은 연구자의 실제 작업 패턴에서 고릅니다. 결과를 받아 들고 몇십 분 생각한 뒤 다시 묻는 일이 잦다면 너무 짧게 잡을 때 세션 파일 복원이 자주 일어납니다. 반대로 길게 잡으면 compute와 IP를 오래 붙잡습니다. 처음 2주는 trace의 세션 간 질문 간격 분포를 보고 정합니다.

실패 상황	대응
동시 세션이 몰려 IP 부족	신규 세션 대기열, 서브넷 용량 경보를 80%에 설정
생성 코드가 환자 단위 행을 출력	실행 환경에서 소표본 셀 가림, 해당 trace 표시
이전 뒤 평가 점수 하락	백엔드 계약 차이부터 비교, 이전 런타임으로 되돌림
추적에 민감 인자 노출	기본 가림, 원본은 단기 보존 저장소로 분리
같은 질문의 결과가 매번 다름	3회 반복 편차가 큰 질문을 따로 모아 지시문·도구 점검

현업 실행 디테일: 누가, 언제, 무엇을

아래 역할과 일정은 원문에 없는 내용입니다. 사내에서 직접 운영하던 분석 에이전트를 관리형 런타임으로 옮기려는 조직을 가정해 가상 예시로 정리했습니다.

역할	하는 일	산출물
데이터 조직 리더(스폰서)	이전 범위와 판정 기준 결정	이전 결정서
SME(임상·의학 전문가)	질문 세트와 golden answer 작성, 채점 검토	평가 세트 50~100문항
에이전트 엔지니어	컨테이너화, 백엔드 계약 유지, 추적 속성	동작하는 hosted agent
네트워크 팀	동시 세션 추정, 서브넷·사설 접근 설계	주소 계획서
보안·개인정보 담당	텔레메트리 가림·보존 규칙, 호출 가능 시스템 검토	통제 점검표
플랫폼 운영	처리량 조정, runbook	운영 절차서

시작 전 준비물: 지금 런타임의 입출력 계약 문서, 최근 3개월의 세션 수와 피크 동시 사용자, 에이전트가 부르는 시스템 목록, 지금 쓰는 평가 세트와 최근 점수, 추적에 남는 필드 목록을 모읍니다. 평가 세트가 없다면 이전보다 평가 세트 만들기가 먼저입니다.

인터뷰·확인 질문

• 연구자가 가장 자주 묻는 프로토콜 밖 질문 다섯 개는 무엇입니까? 그 정답을 누가 확인해 줄 수 있습니까?
• 한 번에 분석을 돌리는 사람이 가장 많은 날은 언제이고, 몇 명입니까?
• 에이전트가 만든 결과 가운데 밖으로 나가면 안 되는 것은 무엇입니까?
• 추적 기록을 볼 수 있어야 하는 사람과 보면 안 되는 사람은 누구입니까?
• 이전 뒤 점수가 얼마나 내려가면 되돌리겠습니까?

진행 판정 기준(가상 예시): 병행 운영 2주 동안 평가 세트의 pass 비율이 기준선과 같거나 높고, 3회 반복 편차가 큰 질문 수가 늘지 않으며, 추적에서 가리지 않은 민감 인자가 0건이고, 피크 시간 서브넷 사용률이 60% 아래면 전환합니다. 하나라도 어긋나면 전환을 미루고 원인을 고칩니다.

적용 제언. 사내 데이터 분석 에이전트를 PoC에서 전사 서비스로 넓히려는 제약·바이오 R&D, 제조 품질 분석, 금융 리스크 분석 조직이 첫 후보입니다. 이들은 모델이 쓴 코드가 민감 데이터를 만지는 공통점이 있습니다. 순서는 평가 세트와 기준선 확보, 백엔드 계약 고정, 네트워크 주소 계획, 추적 보호 규칙, 병행 운영과 전환입니다. 경영진에게는 런타임 운영을 플랫폼에 넘기는 결정이 비용 절감보다 확장 속도와 통제 강화의 문제라는 점을 설명하는 편이 좋습니다. Novo가 강조한 결과도 연구자 수천 명에게 더 빨리, 더 안전하게 내놓은 것이었습니다. 직접 지을 부분은 임상 분석 스킬과 평가처럼 그 조직만의 것으로 좁히는 것이 원문의 원칙과 맞습니다.

원문 사례

항목	내용
원문	Microsoft Command Line, 2026년 11월 11일
저자	AI Acceleration Studio(Microsoft Frontier Company), Casimir Wierzynski(Engineering GM), Jon Malsan(Principal Software Engineer)
고객 측	Sid Prabhu(FounData AI Application 책임), Rasmus S Andersen(FounData Products and AI)
과제	의료 전문가의 임상시험 데이터 2차 분석(프로토콜 밖 질문)
에이전트	reasoning loop, domain-specific skills, data tools, code execution
1차 구조	Azure Container Apps, PostgreSQL(대화), dynamic sessions(코드 실행)
새 구조	Foundry hosted agent, 세션별 VM 격리 sandbox, 사설 네트워크·VNet, Agent 365 거버넌스
네트워크	운영 /24 권장, 최소 지원 /27, 서브넷은 계정 수준에서 변경 불가
관측	OpenTelemetry, Application Insights, 이전 중 Langfuse 병행
평가	같은 평가 세트와 grader, SME golden answer 비교, 기준선·회귀 방지
규모	연구자 수천 명(Novo 측 발언)
공개하지 않은 것	모델 이름, 정확도·비용·지연 수치, 스킬·데이터 도구 세부

핵심 개념

Secondary analysis

임상시험 프로토콜이 처음 정한 질문 밖에서 같은 데이터로 하는 추가 분석입니다.

Azure Container Apps dynamic sessions

Azure Container Apps에서 코드를 격리된 세션으로 실행해 주는 기능입니다. 1차 구조의 코드 실행을 맡았습니다.

Foundry Agent Service

Microsoft Foundry에서 에이전트의 endpoint, 신원, 세션, scaling을 운영하는 서비스입니다. hosted agent가 이 위에서 돕니다.

Agent revision

배포된 에이전트의 버전 하나입니다. revision도 IP 주소를 차지합니다.

VNet integration

서비스를 기업의 가상 네트워크 안에 붙여 들어오고 나가는 트래픽을 통제하는 방식입니다.

Azure Verified Modules

Microsoft가 검증해 공개한 인프라 코드 모듈입니다. 반복 가능한 배포 바탕으로 썼습니다.

Microsoft Agent 365

에이전트 목록, 신원, 접근 통제, lifecycle을 관리하는 거버넌스 도구입니다.

Langfuse

LLM 애플리케이션의 추적과 평가를 보는 관측 도구입니다. 이전 기간에 Application Insights와 함께 썼습니다.

Golden answer

전문가가 미리 확인한 모범 정답입니다. 채점기가 에이전트의 답을 이것과 비교합니다.

내 메모

TODO: 내 생각 추가

원문은 Microsoft Command Line 「From custom infrastructure to hosted agents」(AI Acceleration Studio, Casimir Wierzynski, Jon Malsan, 2026.11.11)입니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 원문이 언급한 내용을 AX Partners가 다시 정리했습니다. 핵심 메커니즘의 체질량지수 예시, 기술 디테일의 서브넷 계산·추적 속성·평가 스키마·설정값·실패 대응표, 현업 실행 디테일의 역할·일정·질문·판정 기준, 적용 제언, 모든 인포그래픽은 새로 작성한 것이며 가상 예시는 그렇게 표시했습니다. 서브넷 주소 수는 CIDR 크기와 Azure의 서브넷 예약 주소 규칙으로 계산했습니다. 전체 내용은 원문에서 볼 수 있습니다.