LLM 데모에서 의료용 AI 에이전트로 전환하는 방법: 개발자가 모델 주변에 구축해야 할 것들

LLM 데모에서 의료용 AI 에이전트로: 개발자가 모델 주변에 구축해야 할 것들

AI 에이전트 데모를 만드는 것은 쉽습니다.

하지만 실제 운영 환경(production)에서 살아남을 수 있는 의료용 AI 에이전트를 구축하는 것은 전혀 다른 문제입니다.

단순한 프로토타입에는 다음과 같은 것들만 필요할 수 있습니다:

• 채팅 UI
• LLM API
• 프롬프트 (prompt)
• 응답 스트림 (response stream)
• 아마도 기본적인 데이터베이스

이 정도면 개념을 보여주기에는 충분합니다.

하지만 시스템이 의료 워크플로우 (healthcare workflows), 환자 정보, 임상 문서화 (clinical documentation), 일정 예약, 청구, 접수, 보험 또는 EHR (전자 건강 기록) 데이터와 접촉하게 된다면, 아키텍처 (architecture)는 완전히 바뀝니다.

그 시점에서 모델은 더 이상 제품이 아닙니다. 모델 주변의 시스템이 제품이 됩니다.

이 포스트는 LLM 프로토타입을 의료용 AI 에이전트로 전환하기 전에 개발자가 고려해야 할 계층들을 분석합니다.

면책 조항: 이것은 기술적 아키텍처 개요이며, 법적 조언이 아닙니다. PHI (개인 건강 정보)를 처리하는 의료 제품은 적절한 컴플라이언스 (compliance), 보안 및 법적 검토를 거쳐야 합니다.

1. 모델이 아니라 데이터 흐름부터 시작하세요

대부분의 팀은 다음과 같은 질문으로 시작합니다:

어떤 모델을 사용해야 할까요?

의료용 AI의 경우, 더 나은 첫 번째 질문은 다음과 같습니다:

어떤 민감한 데이터가 시스템에 입력되고, 어디로 이동하며, 누가 접근할 수 있는가?

운영 코드를 작성하기 전에 전체 데이터 흐름 (data flow)을 매핑하세요:

사용자 입력 (User input)
  -> API 게이트웨이 (API gateway)
  -> 인증 / 인가 (authentication / authorization)
...

만약 보호된 건강 정보 (PHI)가 워크플로우에 들어온다면, 예상보다 더 많은 곳에 나타날 수 있습니다:

• 요청 페이로드 (Request payloads)
• 프롬프트 (Prompts)
• 모델 응답 (Model responses)
• 로그 (Logs)
• 트레이스 (Traces)
• 임베딩 (Embeddings)
• 벡터 데이터베이스 (Vector databases)
• 모니터링 도구 (Monitoring tools)
• 지원 티켓 (Support tickets)
• 분석 대시보드 (Analytics dashboards)
• 알림 시스템 (Notification systems)
• EHR 통합 페이로드 (EHR integration payloads)

PHI가 로그나 제3자 모니터링 도구로 유출된다면 보안 데이터베이스도 큰 도움이 되지 않습니다.

2. PHI를 경계 문제로 취급하세요

의료용 AI 아키텍처를 생각하는 유용한 방법은 PHI 경계를 그리는 것입니다.

다음과 같이 질문해 보세요:

PHI가 어디로 유입될 수 있는가?
PHI가 어디에 저장될 수 있는가?
PHI가 어디에서 변환될 수 있는가?
...

그 경계(boundaries)를 중심으로 제어 장치(controls)를 설계하세요.

예를 들어:

환자 메시지에 PHI 포함
  -> 입력값 분류 (Classify input)
  -> 비필수 로그에서 PHI 제거
...

이것이 추가적인 작업처럼 들릴 수 있지만, 나중에 발생할 막대한 재작업 비용을 방지해 줍니다. 로그에 PHI가 포함되어 있다는 사실을 발견하기에 가장 최악의 시점은 시스템이 라이브(live) 상태가 된 이후입니다.

3. 생성 후가 아니라 검색(retrieval) 전에 권한 부여(authorization)를 추가하세요

RAG 기반 의료 시스템에서 흔히 발생하는 실수는 먼저 검색을 수행한 뒤 나중에 필터링하는 것입니다.

이는 의도치 않은 정보 노출을 초래할 수 있습니다.

나쁜 패턴:

사용자가 질문함
  -> 모든 관련 문서 검색 (Retrieve all relevant documents)
  -> 검색된 컨텍스트를 모델로 전송
...

더 나은 패턴:

사용자가 질문함
  -> 사용자의 역할(role) 및 권한(permissions) 식별
  -> 허용된 문서만 검색
...

의료 분야에서의 RAG는 단순히 검색 품질에 관한 것이 아닙니다. 그것은 권한이 부여된 검색(permissioned retrieval)에 관한 것입니다. 환자, 의사, 수납 직원, 접수처 사용자, 그리고 관리자는 동일한 지식 베이스(knowledge base)에서 자동으로 정보를 검색해서는 안 됩니다.

별도의 인덱스(indexes), 메타데이터 필터(metadata filters), 테넌트 경계(tenant boundaries), 문서 수준 권한(document-level permissions), 또는 검색 전 액세스 제어(access-control) 확인이 필요할 수 있습니다.

검색 필터 예시:

{
  "tenant_id": "clinic_123",
  "user_role": "billing_staff",
...

정확한 구현 방식은 사용 중인 스택(stack)에 따라 다르지만, 원칙은 동일합니다:
사용자가 가져서는 안 될 컨텍스트를 모델에게 제공하지 마세요.

4. 진지한 워크플로우(workflows)에서 감사 로그(audit logs)는 선택 사항이 아닙니다

일반적인 챗봇에서 로그는 주로 디버깅(debugging)을 위한 것입니다.
의료 AI에서 로그는 책임 소재(accountability)의 일부입니다.

다음과 같은 질문에 답해야 할 수도 있습니다:

• 누가 AI 에이전트를 사용했는가?
• 무엇을 질문했는가?
• 어떤 데이터 소스가 검색되었는가?
• 모델이 무엇을 반환했는가?
• 출력이 수정되었는가?
• 누가 승인했는가?
• 다른 시스템으로 전송된 것이 있는가?
• 모델이 실패했을 때 어떤 일이 발생했는가?

기본적인 감사 이벤트(audit event)는 다음과 같은 형태일 수 있습니다:

{
  "event_type": "ai_agent_response_generated",
  "timestamp": "2026-07-02T14:25:00Z",
...

목표는 불필요한 민감 데이터를 저장하지 않는 것입니다. 또한 나중에 무슨 일이 일어났는지 이해할 수 있을 만큼 충분한 추적성 (traceability)을 확보하는 것이 목표입니다.

감사 로그 (Audit logs)는 의도적으로 설계되어야 합니다. PHI (개인 건강 정보) 노출에 대해 깊이 고민하지 않은 채, 전체 프롬프트 (prompts)와 응답 (responses)을 애플리케이션 로그에 무작정 쏟아붓지 마십시오.

5. 인간의 검토 (Human review)가 워크플로우의 일부가 되어야 합니다

개발자들은 종종 인간의 검토를 하나의 제품 기능 (product feature)으로 생각하곤 합니다.

의료 AI 분야에서 이는 리스크 제어 계층 (risk-control layer)이기도 합니다. 저위험 행정 업무의 경우 AI가 제안하거나 초안을 작성하도록 허용할 수 있습니다. 하지만 고위험 워크플로우의 경우, 무언가가 전송, 저장 또는 실행되기 전에 승인이 필요할 수 있습니다.

간단한 워크플로우 패턴:

AI가 초안 생성
  -> 신뢰도 / 리스크 체크
  -> 인간의 검토가 필요한가?
...

인간의 검토가 필요할 수 있는 예시:

• 임상 요약 (Clinical summaries)
• 의료 문서화 (Medical documentation)
• 사전 승인 지원 (Prior authorization support)
• 환자 대상 의료 가이드라인 (Patient-facing medical guidance)
• 청구 또는 코딩 권장 사항 (Billing or coding recommendations)
• EHR (전자 건강 기록)에 다시 기록되는 모든 것

AI의 출력이 유용할 때조차도, 시스템은 여전히 인간이 책임을 진다는 점을 명확히 해야 합니다.

6. EHR/FHIR 통합은 난이도를 변화시킵니다

독립형 AI 어시스턴트는 하나의 프로젝트입니다. EHR 데이터와 연결된 AI 에이전트는 또 다른 프로젝트입니다.

임상 또는 행정 시스템과 통합되면 다음과 같은 사항들을 고려해야 합니다:

• 인증 (Authentication)
• 환자 매칭 (Patient matching)
• 필드 수준 권한 (Field-level permissions)
• 읽기 vs 쓰기 권한 (Read vs write access)
• FHIR 리소스 매핑 (FHIR resource mapping)
• 속도 제한 (Rate limits)
• 장애 처리 (Failure handling)
• 데이터 동기화 타이밍 (Data sync timing)
• 중복 기록 (Duplicate records)
• 감사 가능성 (Auditability)
• 롤백 또는 수정 워크플로우 (Rollback or correction workflows)

기본적인 아키텍처는 다음과 같을 수 있습니다:

AI 에이전트
  -> 백엔드 서비스 (Backend service)
  -> 통합 서비스 (Integration service)
...

통합 서비스는 사후에 고려되는 요소가 되어서는 안 됩니다. 통합 서비스는 권한을 강제하고, 이벤트를 기록하며, 페이로드 (payloads)를 검증하고, 외부 시스템의 복잡성을 AI 계층으로부터 격리해야 합니다.

7. 모니터링은 가동 시간 (uptime) 그 이상을 다뤄야 합니다

프로덕션 AI 모니터링은 단순히 서버를 모니터링하는 것이 아닙니다.

의료용 AI 에이전트의 경우, 다음과 같은 항목들을 모니터링해야 할 수도 있습니다:

• 지연 시간 (Latency)
• 토큰 사용량 (Token usage)
• 모델 호출 실패 (Failed model calls)
• 검색 품질 (Retrieval quality)
• 환각 보고 (Hallucination reports)
• 안전하지 않은 출력 (Unsafe outputs)
• PHI(개인 건강 정보) 유출 위험 (PHI leakage risk)
• 사용자 재정의 (User overrides)
• 검토자 거부율 (Reviewer rejection rate)
• 출처 인용 품질 (Source citation quality)
• 시간에 따른 응답 드리프트 (Drift in responses over time)

예를 들어, 검토자들이 AI가 생성한 요약본을 빈번하게 수정하거나 거부한다면, 이는 중요한 신호입니다.

이는 다음과 같은 의미일 수 있습니다:

• 프롬프트 (Prompts) 개선 필요
• 소스 문서 (Source documents)의 품질 저하
• 검색 (Retrieval) 성능 약화
• 사용자의 기대치가 불분명함
• 워크플로 (Workflow)가 자동화하기에 너무 위험함

AI 모니터링은 기술적 지표 (Technical metrics)를 워크플로 결과 (Workflow outcomes)와 연결해야 합니다.

8. 모델 계층만 보고 비용을 추정하지 마세요

초기에 흔히 하는 추정 방식은 다음과 같습니다:

프론트엔드 (Frontend): 작음
백엔드 (Backend): 작음
LLM API: 관리 가능
...

그러다 프로덕션 요구사항이 나타나기 시작합니다:

RBAC (역할 기반 액세스 제어)
MFA (다요소 인증)
감사 로그 (Audit logs)
...

바로 이 지점에서 실제 비용이 발생하기 시작합니다.

모델은 눈에 보이는 부분일 수 있지만, 제어 계층 (Control layers)이 일반적으로 해당 제품을 의료 환경에서 출시할 수 있는지 여부를 결정합니다.

9. 실무 개발자를 위한 체크리스트

의료용 AI 에이전트를 구축하기 전에 다음 질문들에 답해 보세요:

데이터 (Data)

• 어떤 데이터가 시스템에 입력됩니까?
• PHI(개인 건강 정보)를 포함하고 있습니까?
• 데이터가 어디에 저장됩니까?
• 암호화되어 있습니까?
• 얼마나 오래 보관됩니까?

모델 (Model)

• 어떤 데이터가 모델로 전송됩니까?
• 프롬프트 (Prompts)가 로그에 기록됩니까?
• 응답이 로그에 기록됩니까?
• 벤더 (Vendor)가 데이터를 처리하는 것이 허용됩니까?
• BAA (비즈니스 파트너 계약)가 필요합니까?

검색 (Retrieval)

• AI가 어떤 소스에서 정보를 검색할 수 있습니까?
• 검색 결과가 역할에 따라 필터링됩니까?
• 출처 인용 (Source citations)이 유지됩니까?
• 사용자가 접근해서는 안 되는 데이터에 접근할 수 있습니까?

액세스 제어 (Access control)

• 누가 에이전트를 사용할 수 있습니까?
• 어떤 역할 (Roles)이 존재합니까?
• 각 역할은 무엇을 보고 무엇을 할 수 있습니까?
• 액세스 권한이 정기적으로 검토됩니까?

감사 가능성 (Auditability)

• 발생한 일을 재구성할 수 있습니까?
• 작업이 사용자와 연결되어 있습니까?
• AI가 생성한 출력을 추적할 수 있습니까?
• 인간의 수정 사항이 기록됩니까?

인간의 검토 (Human review)

• 어떤 출력이 승인을 필요로 합니까?
• 누가 승인합니까?
• 출력이 거부되면 어떤 일이 발생합니까?
• 최종 결정이 기록됩니까?

통합 (Integration)

• 에이전트는 어떤 시스템과 연결됩니까?
• 읽기 전용입니까, 아니면 다시 쓰기(write back)도 가능합니까?
• 실패는 어떻게 처리됩니까?
• 통합 이벤트가 기록됩니까?

모니터링 (Monitoring)

• 어떤 모델 동작이 모니터링됩니까?
• 안전하지 않은 출력은 어떻게 보고됩니까?
• 드리프트 (Drift)는 어떻게 감지됩니까?
• 지속적인 검토의 책임자는 누구입니까?

마지막 생각

의료용 AI 에이전트는 단순히 의료용 프롬프트가 적용된 LLM이 아닙니다. 그것은 모델 주변에 구축된 보안 워크플로우 시스템입니다.

실제 엔지니어링 작업은 종종 사용자가 볼 수 없는 부분에서 이루어집니다:

• 액세스 제어 (Access control)
• 감사 가능성 (Auditability)
• 데이터 경계 (Data boundaries)
• 검색 권한 (Retrieval permissions)
• 모니터링 (Monitoring)
• 인간의 검토 (Human review)
• 통합 신뢰성 (Integration reliability)
• 규정 준수 준비가 된 아키텍처 (Compliance-ready architecture)

이것이 의료용 AI 개발 비용이 단순히 모델 통합 비용에 그치지 않는 이유입니다. 그것은 규제 환경에서 모델을 사용할 수 있게 만드는 시스템을 구축하는 비용입니다.

저는 HIPAA 준수 AI 에이전트, RAG 아키텍처, EHR/FHIR 통합, 인프라, 규정 준수 제어, 숨겨진 비용, 그리고 구축 대 구매 (build-vs-buy) 계획을 다루는 더 심도 있는 비용 분석을 여기에 작성했습니다.