모두가 AI 챗봇을 만들고 있습니다.

하지만 프로덕션 환경에 적합한 (production-ready) AI 에이전트를 구축하는 팀은 매우 적습니다.

헬스케어는 에이전트형 AI (agentic AI)를 구현하기에 가장 도전적인 분야 중 하나입니다. 왜냐하면 LLM (Large Language Model)만으로는 충분하지 않기 때문입니다. 프로덕션 환경의 헬스케어 에이전트에는 보안이 확보된 데이터 접근, 결정론적 워크플로 (deterministic workflows), 엔터프라이즈 통합, 관측성 (observability), 메모리 관리 (memory management), 그리고 규제 준수 (regulatory compliance)가 필요합니다.

이 글에서는 현대적인 헬스케어 AI 에이전트 뒤에 숨겨진 엔지니어링 아키텍처와 이들을 프로덕션 환경에 적합하게 만드는 기술들을 살펴봅니다.

왜 LLM은 AI 에이전트가 아닌가

많은 개발자가 LLM과 AI 에이전트를 혼동합니다.

LLM은 다음 토큰 (token)을 예측합니다.

반면, AI 에이전트는 다음과 같은 일을 할 수 있습니다:

• 문제에 대해 추론 (reason)
• 외부 지식 검색 (retrieve)
• API 호출
• 도구 실행 (execute tools)
• 메모리 유지 (maintain memory)
• 워크플로 오케스트레이션 (orchestrate workflows)
• 출력 검증 (verify outputs)
• 완료될 때까지 반복 (iterate)

단일 프롬프트-응답 (prompt-response) 사이클 대신, 에이전트는 다음에 어떤 행동이 일어나야 하는지를 지속적으로 평가합니다.

사용자 (User)
│
▼
플래너 (Planner)
│
▼
추론 엔진 (Reasoning Engine, LLM)
│
├──────────────┐
▼ ▼
도구 호출 (Tool Calling) | RAG
│ │
▼ ▼
FHIR APIs | 벡터 데이터베이스 (Vector Database)
│ │
└──────┬───────┘
▼
응답 검증 (Response Validation)
│
▼
사용자 (User)

헬스케어는 단순히 텍스트를 생성하는 것을 넘어 모든 응답이 여러 시스템과 연관될 수 있기 때문에 이러한 아키텍처가 필요합니다.

핵심 아키텍처

전형적인 헬스케어 AI 에이전트는 여러 개의 독립적인 서비스로 구성됩니다.

클라이언트 (Client)

↓

API 게이트웨이 (API Gateway)

↓

인증 (Authentication)

↓

에이전트 오케스트레이터 (Agent Orchestrator)

↓

LLM

↓

도구 라우터 (Tool Router)

↓

FHIR APIs
스케줄링 (Scheduling)
청구 (Billing)
환자 포털 (Patient Portal)
검사 시스템 (Lab Systems)

↓

벡터 데이터베이스 (Vector Database)

↓

모니터링 (Monitoring)

이러한 서비스들을 분리하면 각 구성 요소를 독립적으로 발전시킬 수 있으면서도 확장성 (scalability)을 향상시킬 수 있습니다.

검색 증강 생성 (RAG)은 필수 사항입니다

헬스케어 모델은 절대로 사전 학습된 지식 (pretrained knowledge)에만 전적으로 의존해서는 안 됩니다.

임상 가이드라인은 변합니다.

약물 정보도 변합니다.

병원 프로토콜도 변합니다.

모델에게 모든 것을 "기억"하라고 요구하는 대신, 현대적인 시스템은 생성하기 전에 신뢰할 수 있는 문서를 검색합니다.

전형적인 RAG (Retrieval-Augmented Generation) 파이프라인:

사용자 질문 (User Question)

↓

임베딩 모델 (Embedding Model)

↓

벡터 검색 (Vector Search)

↓

Top-K 문서 (Top-K Documents)

↓

컨텍스트 주입 (Context Injection)

↓

LLM (Large Language Model)

↓

근거 있는 응답 (Grounded Response)

대중적인 임베딩 모델은 다음과 같습니다:

• OpenAI text-embedding-3-large
• BAAI BGE
• Nomic Embed
• Cohere Embed

대중적인 벡터 데이터베이스:

• Pinecone
• Qdrant
• Weaviate
• Milvus
• pgvector

검색 품질은 단순히 더 큰 LLM으로 업그레이드하는 것보다 의료 분야의 정확도에 일반적으로 더 큰 영향을 미칩니다.

FHIR가 주요 통합 계층이 되어야 하는 이유

헬스케어 소프트웨어는 독점적인 EHR (Electronic Health Record) 데이터베이스를 직접 조작해서는 안 됩니다.

FHIR (Fast Healthcare Interoperability Resources)는 의료 데이터를 교환하기 위한 표준화된 인터페이스를 제공합니다.

예시:

GET /Patient/12345

GET /Observation

GET /MedicationRequest

GET /Appointment

FHIR 리소스는 AI 에이전트를 특정 벤더에 밀접하게 결합(tightly coupling)시키는 대신, 의료 기관 전반에 걸쳐 이식 가능하게(portable) 만듭니다.

SMART on FHIR 인증과 결합하면, 에이전트는 권한 범위(authorization scopes)를 준수하면서 환자 정보에 안전하게 접근할 수 있습니다.

MCP는 에이전트 개발을 더 깔끔하게 만듭니다

MCP (Model Context Protocol)는 AI 모델이 외부 도구 및 데이터 소스와 상호작용하는 표준적인 방식이 되어가고 있습니다.

수십 개의 맞춤형 통합 기능을 구축하는 대신, MCP 서버는 기능을 구조화된 방식으로 노출합니다.

예시:

AI 에이전트 (AI Agent)

↓

MCP 클라이언트 (MCP Client)

↓

MCP 서버 (MCP Server)

↓

FHIR
데이터베이스 (Database)
캘린더 (Calendar)
청구 (Billing)
내부 API (Internal APIs)

이점은 다음과 같습니다:

재사용 가능한 도구 (reusable tools)
표준화된 통합 (standardized integrations)
더 쉬운 유지보수 (easier maintenance)
프롬프트 복잡도 감소 (reduced prompt complexity)
벤더 유연성 (vendor flexibility)

생태계가 성숙해짐에 따라, MCP는 엔터프라이즈 AI 시스템을 위한 중요한 계층이 될 가능성이 높습니다.

함수 호출 (Function Calling) vs 도구 호출 (Tool Calling)

많은 개발자가 이 용어들을 혼용하여 사용하지만, 중요한 차이점이 있습니다.

함수 호출 (Function Calling)

• 미리 정의된 함수를 실행함
• 결정론적 (deterministic)
• 구조화된 입력 (structured inputs)
• 예측 가능한 출력 (predictable outputs)

도구 호출 (Tool Calling)

• 더 넓은 추상화 (broader abstraction)
• API (APIs)
• 데이터베이스 (databases)
• 검색 (search)
• 외부 서비스 (external services)
• 커스텀 워크플로우 (custom workflows)

헬스케어 AI 에이전트는 종종 두 가지 접근 방식을 모두 결합합니다.

예시 워크플로우:

증상 확인 (Check Symptoms)

↓

의학 지식 검색 (Search Medical Knowledge)

↓

환자 기록 조회 (Retrieve Patient History)

↓

예약 일정 잡기 (Schedule Appointment)

↓

의료진에게 알림 (Notify Provider)

↓

요약 생성 (Generate Summary)

메모리 아키텍처의 중요성 (Memory Architecture Matters)

헬스케어 대화는 단일 세션에서 끝나는 경우가 드뭅니다.

환자는 다시 방문합니다.

의사는 후속 조치를 취합니다.

사례는 진화합니다.

현대적인 AI 에이전트는 일반적으로 세 가지 메모리 계층을 구현합니다.

단기 메모리 (Short-Term Memory)

현재 대화의 문맥 (context)을 저장합니다.

주로 다음과 같이 구현됩니다:

• Redis
• 대화 버퍼 (Conversation buffers)
• 윈도우 메모리 (Window memory)

장기 메모리 (Long-Term Memory)

지속적인 지식을 저장합니다.

예시:

• 환자 선호도 (patient preferences)
• 과거 요약 (historical summaries)
• 이전 상호작용 (previous interactions)

시맨틱 메모리 (Semantic Memory)

임베딩 (embeddings)을 사용하여 유사한 대화를 검색합니다.

대화 (Conversation)

↓

임베딩 (Embedding)

↓

벡터 스토어 (Vector Store)

↓

유사도 검색 (Similarity Search)

↓

관련 문맥 (Relevant Context)

이는 프롬프트 (prompt)를 간결하게 유지하면서도 개인화 수준을 획기적으로 향상시킵니다.

멀티 에이전트 시스템 (Multi-Agent Systems)

대규모 헬스케어 워크플로우는 책임을 전문화된 에이전트들에게 분산할 때 관리하기가 더 쉽습니다.

예시:

환자 에이전트 (Patient Agent)

↓

트리아지 에이전트 (Triage Agent)

↓

일정 관리 에이전트 (Scheduling Agent)

↓

문서화 에이전트 (Documentation Agent)

↓

청구 에이전트 (Billing Agent)

하나의 거대한 프롬프트를 만드는 대신, 각 에이전트는 단일 책임에 특화됩니다.

흔히 사용되는 프레임워크는 다음과 같습니다:

• LangGraph
• CrewAI
• AutoGen
• OpenAI Agents SDK

이러한 모듈형 아키텍처 (modular architecture)는 테스트, 확장성 (scalability), 그리고 유지보수성 (maintainability)을 향상시킵니다.

가드레일은 선택 사항이 아닙니다 (Guardrails Are Not Optional)

헬스케어 AI는 환각 (hallucinations)을 최소화해야 합니다.

일반적인 프로덕션 가드레일은 다음과 같습니다:

• 스키마 검증 (schema validation)
• JSON 모드 (JSON mode)
• 신뢰도 점수 산정 (confidence scoring)
• 출처 표기 (source attribution)
• 결정론적 비즈니스 규칙 (deterministic business rules)
• 인간 승인 워크플로우 (human approval workflows)
• 독성 필터 (toxicity filters)
• 프롬프트 인젝션 탐지 (prompt injection detection)

환자 케어에 영향을 미치는 응답은 모델의 메모리에만 의존하기보다, 항상 검색된 의학적 근거에 기반해야 합니다.

관측 가능성 (Observability)는 빠져 있는 핵심 요소입니다

전통적인 모니터링은 API만을 추적합니다.

에이전트 모니터링은 추론 품질 (reasoning quality) 또한 추적해야 합니다.

유용한 지표는 다음과 같습니다:

• 토큰 소비량 (token consumption)
• 지연 시간 (latency)
• 검색 정밀도 (retrieval precision)
• 환각률 (hallucination rate)
• 도구 실패 (tool failures)
• 프롬프트 성공률 (prompt success rate)
• 컨텍스트 활용도 (context utilization)
• 사용자 피드백 (user feedback)
• 요청당 비용 (cost per request)

Langfuse, OpenTelemetry, LangSmith, Helicone과 같은 플랫폼은 프로덕션 AI 시스템에 대한 가시성을 제공합니다.

관측 가능성 (observability) 없이는 AI 에이전트의 디버깅이 추측에 의존하게 됩니다.

프로덕션을 위한 인프라

전형적인 배포 스택에는 다음과 같은 것들이 포함될 수 있습니다:

• FastAPI
• Docker
• Kubernetes
• Redis
• PostgreSQL
• Kafka
• Qdrant
• NGINX
• Prometheus
• Grafana
• GitHub Actions
• Terraform

대규모 조직은 확장성을 개선하고 운영 비용을 절감하기 위해 종종 추론 서비스 (inference services)를 오케스트레이션 서비스 (orchestration services)와 분리합니다.

실제로 마주하게 될 엔지니어링 과제들

가장 어려운 문제는 대개 모델과 관련된 것이 아닙니다.

엔지니어링과 관련된 문제입니다.

예시는 다음과 같습니다:

• 컨텍스트 윈도우 관리 (context window management)
• 프롬프트 버전 관리 (prompt versioning)
• API 속도 제한 (API rate limiting)
• 안전한 PHI (개인 건강 정보) 처리
• 도구 지연 시간 (tool latency)
• 모델 라우팅 (model routing)
• 캐시 무효화 (cache invalidation)
• 검색 최적화 (retrieval optimization)
• 토큰 비용 관리 (token cost management)
• 결정론적 워크플로 (deterministic workflows)

이러한 과제들을 해결하는 것이 프로토타입과 프로덕션 시스템을 구분 짓는 차이점입니다.

헬스케어 AI 구현, 아키텍처 결정, 컴플라이언스 고려 사항 및 배포 전략에 대한 더 광범위한 분석을 찾는 개발자와 엔지니어링 팀을 위해, 헬스케어 AI 에이전트 구축에 관한 이 가이드는 이러한 개념 중 많은 부분을 확장하여 설명합니다: [https://citrusbits.com/how-to-build-healthcare-ai-agents/]

마치며

헬스케어 AI는 단순한 대화형 어시스턴트에서 실제 임상 워크플로를 오케스트레이션할 수 있는 자율적이고 도구 인지적인 (tool-aware) 소프트웨어 시스템으로 진화하고 있습니다.

미래는 가장 큰 언어 모델을 선택하는 것에 관한 것이 아닙니다.

그것은 LLM (Large Language Models)을 검색 증강 생성 (RAG), FHIR 상호운용성 (interoperability), 모델 컨텍스트 프로토콜 (MCP), 관측 가능성 (observability), 보안 인프라 (secure infrastructure), 그리고 결정론적 실행 (deterministic execution)과 결합하여 탄력적인 아키텍처를 설계하는 것에 관한 것입니다.

오늘 이러한 아키텍처 원칙을 수용하는 엔지니어링 팀이 내일 확장 가능하고 신뢰할 수 있는 헬스케어 AI 플랫폼을 구축하게 될 것입니다.

AI 아키텍처, 헬스케어 소프트웨어, 그리고 엔터프라이즈 애플리케이션 개발에 관한 더 많은 엔지니어링 인사이트에 관심이 있다면, 다음에서 더 많은 기술 리소스를 탐색해 보세요: [https://citrusbits.com/]