최근 한 중견 바이오제약 기업의 품질(QA) 디렉터가 자사의 AI 기술 스택을 소개해주었습니다. 프라이빗 LLM 엔드포인트, 트레이스를 수집하는 Langfuse 인스턴스, EDMS(전자문서관리시스템)로부터 데이터를 가져오는 RAG 파이프라인, 160개의 골든 테스트 케이스(golden test cases)로 구성된 평가 스위트, 그리고 “GxP 산출물에는 인간의 검토가 필수”라고 명시된 정책 문서를 갖추고 있었습니다.

개별 구성요소들은 모두 견고했습니다. 하지만 그중 어느 것도 하나의 시스템으로 유기적으로 연결되어 있지 않았습니다.

LLM은 정책 문서에 무엇이 적혀 있는지 전혀 알지 못했습니다. 평가 스위트는 엔드투엔드가 아닌 RAG 파이프라인만을 격리된 상태에서 테스트하고 있었습니다. Langfuse 트레이스는 지연 시간(latency)은 기록했지만 ALCOA+ 컴플라이언스 속성은 캡처하지 못했습니다. 인간 검토 절차는 문서상으로만 존재할 뿐, 이를 강제하는 코드 실행 경로(code path)가 없었습니다. FDA 실사관이 “3월 4일에 에이전트가 CAPA-1234 초안을 작성할 때 정확히 어떤 데이터와 프롬프트 버전을 사용했는지 보여주십시오”라고 물었을 때, 아무도 답할 수 없었습니다.

그들에게는 개별 컴포넌트만 있었을 뿐, 아키텍처는 없었습니다.

이것이 오늘날 규제 대상 AI에서 가장 흔히 발생하는 실패 패턴(failure mode)입니다. 팀들은 하네스, 관측 가능성(Observability) 계층, 평가(Eval) 스위트 등 훌륭한 개별 요소들을 구축하지만, 모든 요청이 신원 인증부터 감사 커밋(audit commit)까지 7개 계층 전체를 통과하는 단일 통합 시스템으로 이를 결합하지 못합니다. 그 결과 발표용 슬라이드에서는 훌륭해 보이지만, 실제 규제 실사 앞에서는 힘없이 무너지는 공백이 발생합니다.

핵심 역설 (The Core Paradox)

전통적인 CSV(컴퓨터화 시스템 밸리데이션)는 결정론적(deterministic) 시스템을 전제로 합니다. 매번 동일한 입력에는 반드시 동일한 출력이 나와야 한다는 전제입니다. 이 가정은 지금까지 작성된 모든 밸리데이션 프로토콜의 법적 기반이었습니다.

AI 에이전트는 이 모든 전제를 깨뜨립니다. 에이전트는 확률론적(probabilistic)으로 추론합니다. 도구 호출을 창발적(emergent) 순서로 연쇄 실행합니다. 실행 시점마다 달라지는 컨텍스트를 검색합니다. 그리고 동일한 프롬프트에서도 서로 다른 출력을 만들어냅니다.

이에 대한 아키텍처적 해법은 LLM을 결정론적으로 만드는 것이 아닙니다. 그것은 불가능합니다. 올바른 해법은 모든 상태 전이(state transition)가 기록되고, 모든 도구 호출이 제어(gated)되며, 모든 출력이 검증되고, 모든 인간의 의사결정에 서명이 이루어지는 결정론적이고 검증된 프레임워크 내부에 비결정론적 추론을 감싸는(wrap) 것입니다. LLM은 신뢰할 수 있는 시스템(trusted system) 내부의 신뢰할 수 없는 하위 구성요소(untrusted sub-component)가 됩니다.

이것이 바로 그 시스템을 위한 참조 아키텍처입니다.

7계층 참조 아키텍처 (The 7-Layer Reference Architecture)

┌──────────────────────────────────────────────────────────────────┐ 
│  LAYER 7 — EVALS & VALIDATION                                    │ 
│  Golden datasets · Regression suites · LLM-as-judge              │ 
│  CI/CD gates · Continuous monitoring · Drift detection           │ 
├──────────────────────────────────────────────────────────────────┤ 
│  LAYER 6 — OBSERVABILITY                                         │ 
│  OpenTelemetry traces · Immutable audit trail · WORM logs        │ 
│  Prompt/response capture · Cost/latency metrics · Dashboards     │ 
├──────────────────────────────────────────────────────────────────┤ 
│  LAYER 5 — COMPLIANCE & GOVERNANCE                               │ 
│  21 CFR Part 11 e-signatures · ALCOA+ enforcement                │ 
│  Policy engine · Change control · Version registry               │ 
├──────────────────────────────────────────────────────────────────┤ 
│  LAYER 4 — AGENT ORCHESTRATION (THE HARNESS)                     │ 
│  Deterministic DAG · Supervisor → Planner → Executor             │ 
│  HITL gates · Tool registry · Guardrails · Confidence routing    │ 
├──────────────────────────────────────────────────────────────────┤ 
│  LAYER 3 — MODEL LAYER                                           │ 
│  Private LLM (VPC) · Prompt registry · RAG router                │ 
│  Model versioning · Fallback endpoints · Token budgets           │ 
├──────────────────────────────────────────────────────────────────┤ 
│  LAYER 2 — DATA & KNOWLEDGE                                      │ 
│  Controlled RAG · Vector DB with lineage · WORM storage          │ 
│  Read-only connectors · Document versioning · Hash verification  │ 
├──────────────────────────────────────────────────────────────────┤ 
│  LAYER 1 — IDENTITY & ACCESS                                     │ 
│  SSO (SAML/OIDC) · MFA · RBAC/ABAC · Session management          │ 
│  Electronic signatures · Unique user IDs · Least privilege       │ 
└──────────────────────────────────────────────────────────────────┘

각 계층은 명확한 소유자(owner), 고유한 위험 프로필(risk profile), 그리고 구체적인 통제 장치(controls)를 가집니다. 요청은 계층 1로 유입되어 모든 계층을 차례로 통과한 뒤, 계층 7에서 감사 가능하고 귀속성을 갖춘(auditable, attributable) 기록으로 완료됩니다. 어떠한 지름길도, 우회로도 허용되지 않습니다.

계층 1: 신원 인증 및 접근 통제 (Identity & Access) — 진입 관문

모든 것은 고유한 사용자 식별과 접근 통제를 규정한 21 CFR Part 11의 요구사항에서 시작됩니다. 사용자가 에이전트에 접촉하기도 전에, 신원이 검증되어 세션에 바인딩되어야 합니다.

신원 계층은 SAML 또는 OIDC를 통해 엔터프라이즈 SSO(EntraID, Okta 등)와 연동됩니다. MFA(다중 요소 인증)를 강제하고, GxP 특화 역할을 기반으로 한 RBAC(역할 기반 접근 통제)을 적용합니다. 예를 들어 QA 검토자(QA Reviewer)는 제조 작업자(Manufacturing Operator)나 인허가 담당자(Regulatory Affairs Specialist)와 서로 다른 데이터를 보고 다른 도구 권한을 갖습니다. 세션 토큰은 전체 실행 트레이스를 따라 전파됩니다.

이는 선택적 인프라가 아닙니다. ALCOA+의 제1원칙인 **귀속성(Attributable)**의 근간입니다. 모든 다운스트림 기록은 해당 요청을 누가 시작했는지에 대한 신원 정보를 반드시 포함해야 합니다.

전자 서명의 경우, 시스템은 인쇄된 성명, 일시, 서명의 의미(검토, 승인, 인가)를 포함하는 2요소 인증(비밀번호 및 보조 인증 수단)을 요구합니다. LLM은 서명을 생성하거나 적용할 수 없습니다. 오직 검증된 전자 서명 게이트웨이만이 서명을 처리할 수 있습니다.

핵심 설계 결정 사항: 에이전트가 다운스트림 시스템(QMS, LIMS, ERP)을 호출할 때 단일 특권 서비스 계정(privileged service account)을 통해 작동해서는 안 되며, 인증된 사용자 컨텍스트를 그대로 전파해야 합니다. 에이전트가 중개자 역할을 하더라도 모든 행위는 특정 개인에게 귀속될 수 있어야 합니다.

계층 2: 데이터 및 지식 (Data & Knowledge) — 통제된 컨텍스트

에이전트의 지식은 승인되고 버전이 관리되는 소스에서만 나와야 합니다. 인터넷, 통제되지 않는 위키, 오늘 아침에 개정되었는데 어제 임베딩해 둔 문서는 허용되지 않습니다.

데이터 계층은 읽기 전용의 검증된 커넥터를 통해 기준 시스템(Systems of Record) — Veeva Vault QMS/EDMS, LIMS, MES, ELN, SAP 등 — 과 연결됩니다. 검색된 모든 문서는 source_doc_id, version, effective_date, hash와 같은 메타데이터를 포함합니다. 에이전트는 자신이 언제 무엇을 확인했는지 정확하게 재구성할 수 있어야 합니다.

벡터 데이터베이스는 단일 진실 공급원(Source of Truth)이 아닙니다. 원천 데이터를 참조하는 색인(Index)일 뿐입니다. 모든 청크(chunk)는 원천 계보(lineage)를 저장합니다. EDMS에서 원본 문서가 업데이트되면 벡터 인덱스도 원자적(atomically)으로 갱신되어야 합니다. 만약 에이전트가 구버전의 SOP(표준작업지침서)를 조회한다면, 이는 ALCOA+의 원본성(Original) 및 정확성(Accurate) 원칙을 위반하는 것입니다.

GxP 기록이 되는 에이전트 산출물에는 WORM(Write Once Read Many, 단일 쓰기 다중 읽기) 스토리지가 적용됩니다. AWS S3 Object Lock, Azure Immutable Blob 또는 이에 준하는 기술이 사용됩니다. 에이전트는 한 번 기록하며, 관리자를 포함한 그 누구도 해당 기록을 수정하거나 삭제할 수 없습니다.

계층 3: 모델 계층 (Model Layer) — 추론 엔진

LLM은 자체 VPC(가상 사설 클라우드) 내부에서 실행됩니다. GxP 데이터를 처리할 때 공개 API 호출은 일절 허용되지 않습니다. 고객 관리형 키(CMK)를 적용한 Azure OpenAI나 VPC 엔드포인트를 갖춘 AWS Bedrock을 사용합니다. 모델은 교체 가능한 추론 엔진이며, 실질적인 인텔리전스는 하네스가 제공합니다.

시스템 프롬프트, RAG 템플릿, 도구 정의는 체크섬과 함께 Git에서 버전 관리됩니다. 이들은 GAMP 5 기준에 따른 설계 사양서(Design Specification, DS)의 일부입니다. 프롬프트 변경은 곧 코드 변경입니다. 배포 전에 PR(풀 리퀘스트) 검토, 자동화된 테스트, 공식 승인 절차를 반드시 거쳐야 합니다.

RAG 라우터는 승인된 소스로부터 컨텍스트를 조합합니다. 검색된 레코드는 원천 계보를 유지하므로, 에이전트 출력에 포함된 모든 주장은 특정 문서 버전으로 추적될 수 있어야 합니다. 컨텍스트는 결코 무조건 신뢰되지 않으며, 사용자에게 전달되기 전에 반드시 컴플라이언스 계층을 통과합니다.

모델 레지스트리는 의도된 사용 목적(intended use), 한계점, 밸리데이션 상태, 알려진 오류 모드 등이 포함된 모델 카드(model card)와 함께 배포된 모든 모델 버전을 추적합니다. 모델 업그레이드는 공식적인 변경 관리(Change Control)를 거칩니다. 프로덕션 환경에서의 자동 업데이트는 엄격히 금지됩니다.

계층 4: 에이전트 오케스트레이션 (Agent Orchestration) — 제어 하네스

대부분의 팀이 FDA 실사에서 탈락하는 지점이 바로 여기입니다. 하네스는 확률론적 LLM을 감싸는 결정론적 제어 플레인(control plane)입니다. 이는 단순한 프레임워크 기능이 아니라, GAMP 5 카테고리 5에 해당하는 커스텀 애플리케이션입니다.

자율적인 ReAct 루프 대신 결정론적 DAG(비순환 방향 그래프; LangGraph, Semantic Kernel, Temporal 등)를 사용해야 합니다. 오케스트레이터가 실행 흐름을 제어합니다:

수퍼바이저 노드(Supervisor Node): 의도(intent)와 GxP 중요도(criticality)를 분류합니다. 적절한 워크플로우로 라우팅하고, GAMP 위험 등급(1~3단계)을 할당합니다.

플래너 노드(Planner Node): 폐쇄형 도구 레지스트리(closed tool registry)로부터 검증된 도구 계획을 생성합니다. 동적 도구 검색(dynamic tool discovery)은 허용되지 않습니다. 에이전트는 사전 승인되고 IQ/OQ가 완료되었으며 입력, 출력, 오류 모드가 명확히 정의된 도구만 호출합니다.

정책 엔진(Policy Engine): 어떠한 도구 호출 전에도 강력한 가드레일을 적용합니다. 예: “에이전트는 절대로 일탈(Deviation)을 종료할 수 없으며 조사 요약 초안만 작성할 수 있다”, “에이전트는 투약량 권고를 제공할 수 없다”, “규제 제출을 위한 모든 산출물에는 HITL이 필수이다”.

HITL 게이트(HITL Gate): GxP상 중요한 작업의 경우 전자 서명 요구사항이 포함된 인간 검토자에게 라우팅합니다. 이 게이트는 블로킹(blocking) 상태 전이입니다. 자격을 갖춘 인간이 승인할 때까지 워크플로우는 다음 단계로 진행되지 않습니다.

신뢰도 기반 라우팅(Confidence Routing): 에이전트의 신뢰도가 임계치 아래로 떨어지거나, 질의가 새로운 유형이거나(검증된 유스케이스 범위를 벗어난 경우), 작업 위험도가 높은 경우 인간에게 에스컬레이션하거나 결정론적 경로로 폴백(fallback)합니다.

안전 우선 차단 정책(Fail-Closed Policy): 에이전트가 안전한 경로를 결정할 수 없을 때, 시스템은 불확실한 출력을 계속 진행하지 않고 안전하게 차단(fail-closed; 자동 작업 중단)합니다.

모든 상태 전이는 불변의 이벤트(immutable event)입니다. 모든 도구 호출은 입력, 출력, 지연 시간, 귀속 정보와 함께 로깅됩니다. 하네스는 곧 감사의 경계(audit boundary)입니다. 하네스를 밸리데이션할 수 없다면, 그 하네스가 생산한 어떠한 결과물도 규제 당국 앞에서 방어할 수 없습니다.

컨텍스트 방화벽(Context Firewalls): 각 하위 에이전트나 워크플로우 단계는 자신에게 꼭 필요한 컨텍스트만 전달받습니다. 증빙 검토자(Evidence Reviewer)는 CAPA 작성자(CAPA Drafter)의 원시 컨텍스트를 결코 보아서는 안 됩니다. 이는 단순한 연산 최적화가 아니라 감사 경계(audit boundary)의 설정입니다. 명확한 컨텍스트 격리는 각 단계의 출력이 제한되고 검토 가능한 입력 데이터 집합에 명확히 귀속됨을 의미합니다.

도구 권한(Tool Permissions): 역할 기반(role-based)이 아닌 역량/기능 기반(capability-based)이어야 합니다. 일탈 기록을 읽는 도구와 CAPA 기록 초안을 작성하는 도구는 “역할”(품질 검토자)이 유사하더라도 서로 분리된 자격 증명을 가집니다. 이를 통해 Part 11 접근 통제 요건을 명확하게 충족할 수 있습니다.

계층 5: 컴플라이언스 및 거버넌스 (Compliance & Governance) — 강제 계층

이는 시스템 전반을 아우르는 횡단 계층(cross-cutting layer)입니다. ALCOA+ 및 21 CFR Part 11을 실질적으로 집행하는 강제 메커니즘입니다.

ALCOA+ 데이터 무결성 엔진:

원칙 (Principle) 기술적 통제 장치 (Technical Control)
Attributable (귀속성) 모든 레코드에 user_id, agent_id, model_version, prompt_hash 기록
Legible (가독성) 구조화된 JSON 로그 및 프롬프트와 응답의 인간 가독형(human-readable) 렌더링
Contemporaneous (동시성) 검토 시점이 아닌 이벤트 생성 시점의 NTP 동기화 서버 타임스탬프
Original (원본성) 파싱 전 원시 검색 결과 및 원시 LLM 완성 텍스트 저장. 덮어쓰기 금지
Accurate (정확성) 인용 출처가 명시된 접지형(Grounded) RAG, HITL 검토, 평가(Eval) 밸리데이션
Complete (완전성) 전체 체인 보존: 의도 → 계획 → 도구 호출 → 증빙 → 최종 답변
Consistent (일관성) 결정론적 하네스, 버전이 고정된 모델, 프롬프트 및 도구
Enduring (영속성) 보존 기간(GxP 기준 10년 이상)이 정의된 WORM 스토리지
Available (가용성) 이중화 스토리지, 실사관 제출용 즉시 내보내기, 리걸 홀드(소송 보존) 지원

변경 관리(Change Control): 프롬프트, 모델 가중치, 도구 스키마, 가드레일 규칙 또는 데이터 소스에 대한 모든 변경은 배포 전 위험 평가, 테스트, 문서화 및 승인을 수반하는 공식 변경 관리를 트리거합니다.

정책 엔진(Policy Engine): 버전 관리되고 테스트를 거치는 선언적 정책(OPA, Cedar 또는 커스텀 DSL). 정책은 에이전트가 수행할 수 있는 작업과 없는 작업, 접근 가능한 데이터, 인간의 승인이 필요한 작업을 명확히 규정합니다.

계층 6: 관측 가능성 (Observability) — 증명 시스템

일반적인 APM(애플리케이션 성능 모니터링)만으로는 불충분합니다. 환각(Hallucination)이 발생해도 HTTP 200 코드가 반환되기 때문입니다. 관측 가능성은 구조적 실행 단계와 시맨틱 언어 모델 텔레메트리를 모두 수집해야 합니다.

4대 기둥 (Four Pillars):

  1. 트레이스(Traces): UI → 하네스 → LLM → 도구로 이어지는 OpenTelemetry 추적. 모든 에이전트 실행은 각 단계별 스팬(span)을 포함하는 트레이스입니다. LLM 특화 관측을 위해 Langfuse나 Arize Phoenix를 활용합니다.

  2. 로그(Logs): 불변의 프롬프트 및 완성 텍스트 로깅. 단순 템플릿이 아니라 완전히 렌더링된 프롬프트 전체를 기록합니다. PII(개인식별정보) 마스킹은 아카이브 복사본이 보존된 이후에 수행합니다.

  3. 메트릭(Metrics): 도구 선택 정확도, 환각 발생률, HITL 에스컬레이션 비율, 지연 시간, GxP 트랜잭션당 토큰 비용.

  4. 레코드(Records): 보안을 위한 별도의 SIEM 스트림 및 데이터 무결성 모니터링(Data Integrity Monitoring). 감사 저장소를 수정하려는 시도가 발생하면 즉각적인 경보가 울립니다.

모든 트레이스는 ALCOA+ 기록입니다. 여기에는 사용자 신원, 세션 ID, 모델 버전, 프롬프트 버전, 입력 해시, 출력 해시, 생성 시점 타임스탬프와 인간 승인 시점 타임스탬프의 대조값, 그리고 승인 게이트를 통과시킨 특정 인간 검토자의 신원이 반드시 포함되어야 합니다.

대시보드는 다음의 한 가지 질문에 답할 수 있어야 합니다: “3월 4일에 에이전트 2026-001이 CAPA-1234 초안을 작성할 때 사용한 정확한 데이터와 프롬프트 버전을 보여주십시오.” 만약 여러분의 관측 가능성 시스템이 이에 답할 수 없다면, 그것은 진정한 관측 가능성이 아니라 단순한 로깅에 불과합니다.

드리프트 감지(Drift Detection): 세 가지 유형의 드리프트를 모니터링합니다. 입력 드리프트(임베딩 분포 변화), 출력 드리프트(시간 경과에 따른 응답 품질 저하), 지식 드리프트(원본 문서는 업데이트되었으나 벡터 인덱스는 갱신되지 않은 현상). ‘중대(major)’ 대 ‘경미(minor)’ 분류 분포를 소리 없이 변경하는 CAPA 심각도 분류 에이전트는 오류를 뿜어내는 에이전트보다 규제 측면에서 훨씬 더 위험합니다. 오류는 인간 게이트에서 걸러지지만 드리프트는 알아채기 어렵기 때문입니다.

관심사의 분리(Separation of Concerns): 운영 텔레메트리(지연 시간, 에러, 토큰 사용량)는 엔지니어링을 위한 것입니다. 감사 등급 기록(누가, 무엇을, 언제, 왜, 어떤 소스를 기반으로 수행했는가)은 컴플라이언스를 위한 것입니다. 두 정보가 동일한 수집기를 통과하더라도 동일한 대시보드에 혼재되어서는 안 됩니다.

계층 7: 평가 및 밸리데이션 (Evals & Validation) — 지속적 증명

평가는 선택 사항인 일반 테스트가 아닙니다. 바로 OQ(운전 적격성평가)이자 PQ(성능 적격성평가)입니다. CSA(컴퓨터 소프트웨어 보증) 체계 하에서는 위험도에 기반하여 테스트를 수행합니다. 대본 없는 주관적 “느낌 점검(vibe checks)“은 실사를 통과할 수 없습니다.

3계층 체계 (Three Tiers):

티어 1 — 오프라인 평가 하네스 (배포 전): SME(해당 분야 전문가)가 엄선한 100~200개의 골든 데이터셋 테스트 케이스. 일탈 처리 에이전트(Deviation Agent)의 경우: 승인된 조사 결과가 포함된 과거 일탈 이력 데이터. 데이터는 반드시 버전 관리되어야 합니다. 다음 항목들을 테스트합니다:

  • 도구 선택 정확도(Tool Selection Accuracy): 적절한 LIMS 쿼리를 선택했는가?
  • 인용 충실도(Citation Faithfulness): 모든 주장이 검색된 GxP 문서로 추적 가능한가?
  • 지시 준수도(Instruction Following): 시스템 프롬프트를 정확히 준수했는가?
  • 스키마 적합성(Schema Conformance): 출력이 기대한 JSON 스키마와 일치하는가?
  • ALCOA+ 준수(ALCOA+ Compliance): 출처를 명확히 귀속할 수 있는가? 제조번호(Lot number)를 환각으로 꾸며내지 않는가?
  • 안전성(Safety): 탈옥(jailbreak) 저항성, ELN(전자연구노트) 입력 필드를 통한 프롬프트 인젝션 방어, 데이터 유출 시도 차단.

시맨틱 품질 평가를 위해 판사 LLM(LLM-as-Judge)을 사용할 수 있습니다. 단, 판사 모델 자체도 밸리데이션되어야 하며 해당 프롬프트는 고정(locked)되어야 합니다.

티어 2 — 온라인 모니터링 (배포 후): 검색 관련성 드리프트, 환각 비율 증가, 인간의 오버라이드(수정) 비율에 대한 드리프트 감지. 모든 HITL 수정 사항은 새로운 골든 데이터로 피드백됩니다. 실제 트래픽 샘플을 활용한 카나리(Canary) 테스트를 수행합니다.

티어 3 — 주기적 검토 (Periodic Review): EU Annex 11에서 요구하는 필수 절차입니다. 감사 추적, 평가 추세, 모델 및 프롬프트 변경 이력에 대한 분기별 검토를 수행합니다. 접근 권한 재인증, 인시던트 및 CAPA 검토를 포함합니다.

CI/CD 게이트로서의 평가: 평가 스위트를 통과하지 못한 프로덕션 배포는 있을 수 없습니다. 프롬프트, 모델, 도구 또는 데이터의 모든 변경마다 평가가 실행됩니다. 점수가 임계치 아래로 떨어지면 배포가 차단됩니다. 이것이 바로 CSA가 가능하게 하는 자동화된 OQ/PQ입니다.

골든 데이터셋 거버넌스: 평가 데이터셋은 프롬프트 버전 이력과는 독립된 자체 변경 관리 기록을 가져야 합니다. 그렇지 않으면 평가 세트가 프롬프트에 맞춰 임의로 조정(과적합)되지 않았음을 입증할 수 없게 됩니다.

컴플라이언스 매핑 (The Compliance Map)

모든 계층은 구체적인 규제 요건에 1:1로 매핑됩니다:

규제 요건 (Regulation) 아키텍처 구현 (Architectural Implementation)
21 CFR Part 11 (감사 추적 / Audit Trails) 계층 6의 불변 추가 전용(append-only) 로그. 모든 프롬프트, 완성 텍스트, 도구 호출, 시드(seed), 모델 버전 수집. 암호화 해시가 적용된 WORM 스토리지.
21 CFR Part 11 (전자 서명 / E-Signatures) 계층 4 HITL 게이트에서의 인간 승인. OAuth2/MFA를 통한 재인증. 인쇄된 성명, 일시, 서명의 의미 기록. 기록 바인딩.
21 CFR Part 11 (접근 통제 / Access Controls) 계층 1의 SSO, MFA, RBAC. 고유 사용자 ID. 세션 타임아웃. 직무 분리(Separation of duties).
ALCOA+ Attributable (귀속성) 에이전트 실행당 상관관계 ID(Correlation ID). 모든 레코드에 user_id, agent_id, tool_id 기록.
ALCOA+ Legible (가독성) 계층 6의 구조화된 JSON 로그 및 인간 가독형(human-readable) 렌더링.
ALCOA+ Contemporaneous (동시성) 이벤트 생성 시점의 NTP 동기화 타임스탬프. 소급 작성(backdating) 불가.
ALCOA+ Original (원본성) 계층 2에서 어떠한 변환도 거치지 않은 원시 검색 결과 및 원시 LLM 출력 저장.
ALCOA+ Accurate (정확성) 계층 3의 인용 출처 기반 접지형 RAG. 계층 4의 HITL. 계층 7의 평가 밸리데이션.
ALCOA+ Complete (완전성) 의도부터 최종 답변까지 전체 체인 보존. 은밀한 필터링 금지.
ALCOA+ Consistent (일관성) 계층 4의 결정론적 하네스. 버전이 고정된 모델, 프롬프트, 도구.
ALCOA+ Enduring (영속성) 계층 2의 WORM 스토리지. 10년 이상의 보존 기간. 정기적 무결성 점검.
GAMP 5 Category 5 전체 밸리데이션 라이프사이클: URS → FS → DS → RTM → IQ/OQ/PQ. 계층 5의 변경 관리.
CSA 계층 7의 위험 기반 평가 심도. 저위험 검증 자동화. 고위험 판단 영역에 테스트 집중.

무엇을 먼저 구축해야 하는가 (What to Build First)

자율적인 제조단위 출하(batch release) 에이전트가 아닙니다. 일탈 조사(deviation investigation) 에이전트도 아닙니다. 약물감시(pharmacovigilance) 시그널 탐지 에이전트도 아닙니다.

SOP 질의응답(SOP Q&A)부터 시작하십시오. 읽기 전용. 승인된 문서만 참조. 출처 인용 필수. GxP 기록 생성 없음. 완전한 감사 추적. 기본적인 평가 스위트. 인간 피드백 루프.

이것이 바로 1단계(Phase 1)입니다. 낮은 위험도에서 7개 계층 전체를 실전에 적용하고 검증합니다:

  1. 신원(Identity) — 사용자 인증, RBAC 적용
  2. 데이터(Data) — 승인된 SOP 말뭉치에서 검색, 문서 버전 검증
  3. 모델(Model) — 버전이 고정된 프롬프트를 갖춘 고정 프라이빗 LLM 사용
  4. 오케스트레이션(Orchestration) — 결정론적 검색 → 생성 → 인용 검증 파이프라인
  5. 컴플라이언스(Compliance) — ALCOA+ 속성과 함께 모든 단계 로깅
  6. 관측 가능성(Observability) — 전체 트레이스 캡처, WORM 스토리지 저장
  7. 평가(Evals) — 프롬프트 변경마다 골든 테스트 세트 실행

에이전트를 만들기 전에 컴플라이언스 사이드카(sidecar)부터 구축하십시오. 감사(audit)할 수 없다면 밸리데이션할 수도 없습니다.

2단계(Phase 2): 초안 작성 지원 — 일탈 기술서, CAPA 요약, 조사 지원. 인간의 검토 필수. 자율 제출 금지.

3단계(Phase 3): 워크플로우 지원 — 검증된 API를 통한 초안 레코드 생성. 워크플로우 단계 제안. 작성자-검토자(Maker-checker) 통제 적용.

4단계(Phase 4): 고위험 의사결정 지원 — 성숙한 통제 장치, 강력한 평가 체계, 드리프트 모니터링, 품질 감독 및 주기적 검토가 완전히 정착된 이후에만 도입.

에이전트는 플랫폼의 20%에 불과합니다 (The Agent Is Only 20% of the Platform)

이것이 가장 중요한 아키텍처적 통찰이자, 대부분의 팀이 가장 받아들이기 힘들어하는 사실입니다.

AI 에이전트 — 즉 LLM, 추론 루프, 도구 호출 — 는 가장 작은 구성요소일 뿐입니다. 에이전트를 둘러싼 모든 주변 요소들이야말로 이를 GxP 환경에서 수용 가능하게 만드는 핵심입니다:

  • 신원(Identity) (누가 요청하고 있는가)
  • 데이터(Data) (에이전트가 무엇을 알고 있는가)
  • 컴플라이언스(Compliance) (어떤 규칙이 에이전트를 제약하는가)
  • 관측 가능성(Observability) (에이전트가 무엇을 수행했는가)
  • 평가(Evals) (얼마나 정확하게 수행했는가)
  • 거버넌스(Governance) (누가 승인했으며 무엇이 변경되었는가)

에이전트 자체는 언제든 교체 가능한 추론 엔진입니다. 하네스, 관측 가능성, 그리고 평가 체계야말로 진정으로 검증된 시스템(validated system)입니다. LLM을 GPT-4에서 Claude로, 혹은 파인튜닝된 Llama로 교체하더라도 아키텍처는 바뀌지 않습니다. 컴플라이언스 통제도 바뀌지 않습니다. 감사 추적도 바뀌지 않습니다.

이러한 분리가 바로 재밸리데이션(revalidation)을 현실적으로 가능하게 만듭니다. 모델이 변경되면 평가 스위트를 다시 실행하고 모델 레지스트리를 업데이트하면 됩니다. 플랫폼 전체를 처음부터 다시 밸리데이션할 필요가 없습니다.

실사에서 치명적인 안티패턴 (Anti-Patterns That Kill Audits)

이들은 이론상의 위험이 아닙니다. FDA Form 483 지적과 경고장(Warning Letter)을 초래하는 구체적인 실제 실패 패턴들입니다:

GxP 데이터에 퍼블릭 OpenAI 사용: 프롬프트와 응답이 벤더에 의해 로깅될 수 있습니다. 데이터가 사내 네트워크 경계를 벗어납니다. 데이터 상주성(data residency)을 보장할 수 없습니다. 고객 관리형 키(CMK)를 사용하는 프라이빗 엔드포인트나 온프레미스/로컬 모델을 사용하십시오.

HITL 없이 QMS/LIMS에 에이전트가 직접 쓰기 수행: 에이전트는 초안만 생성해야 합니다. 인간이 이를 검토하고 서명해야 합니다. 레코드는 검증된 기준 시스템(system of record)을 통해서만 생성됩니다. 에이전트는 GxP 데이터베이스에 대한 직접 쓰기 권한을 결코 가져서는 안 됩니다.

통제되지 않는 프롬프트: UI 코드에 저장되어 버전 관리도, 변경 관리도, 테스트도 거치지 않은 프롬프트. 프롬프트는 설계 사양서(Design Specification) 산출물입니다. 체크섬과 함께 Git에서 관리되어야 합니다.

상관관계 ID(Correlation ID) 부재: 사용자 입력부터 모든 도구 호출, 모델 호출, 출력 검사를 거쳐 최종 감사 기록에 이르기까지 단일 요청을 완벽하게 추적할 수 없다면, 그것은 감사 추적이 아닙니다. 단순한 로그에 불과합니다.

동적 도구 검색(Dynamic tool discovery): 에이전트가 임의의 Python 코드를 호출하거나, 런타임에 도구를 임의 탐색하거나, 미승인 API에 접근하는 것. 도구 레지스트리는 반드시 폐쇄형(closed)이어야 합니다. 모든 도구는 자체 사양을 가진 GAMP 5 컴포넌트입니다.

LLM이 제어하는 라우팅: 결정론적 감독 없이 어떤 도구를 어떤 순서로 호출할지 스스로 결정하는 자율 ReAct 루프. 상태 머신(State Machine)이나 DAG를 사용하십시오. 제안은 LLM이 하되, 결정은 하네스가 내려야 합니다.

임베딩을 단일 진실 공급원으로 취급: 벡터 데이터베이스는 색인일 뿐입니다. 단일 진실 공급원은 EDMS입니다. 둘 사이에 불일치가 발생하면 언제나 EDMS가 우선합니다. 예외는 없습니다.

킬 스위치(Kill Switch) 부재: 며칠이 아니라 수 분 이내에 프로덕션 환경에서 특정 에이전트, 특정 도구 또는 특정 유스케이스를 즉시 비활성화할 수 있어야 합니다.

기술 스택 (The Technology Stack)

이는 예시일 뿐 강제 규정이 아닙니다. 본 아키텍처는 기술 중립적입니다. 다만 실제로 현장에서 검증되어 효과적으로 작동하는 컴포넌트들은 다음과 같습니다:

기능 (Capability) 권장 기술 (Recommended) 대안 (Alternatives)
오케스트레이션 (Orchestration) LangGraph Semantic Kernel, Temporal, PydanticAI
관측 가능성 (Observability) Langfuse + OpenTelemetry Arize Phoenix, 커스텀 OTel 컬렉터
벡터 DB (Vector DB) pgvector (PostgreSQL) Milvus, Qdrant, Pinecone
LLM 서빙 (LLM Serving) Azure OpenAI (CMK) 또는 Bedrock VPC vLLM, 로컬 모델용 Ollama
정책 엔진 (Policy Engine) OPA (Open Policy Agent) Cedar, 커스텀 DSL
WORM 스토리지 (WORM Storage) S3 Object Lock Azure Immutable Blob
모델 게이트웨이 (Model Gateway) LiteLLM Portkey
평가 프레임워크 (Eval Framework) DeepEval + 커스텀 OpenEvals, Ragas
CI/CD 평가 게이트가 적용된 GitHub Actions GitLab CI, Harness.io

버전 방정식 (The Version Equation)

프로덕션 에이전트의 버전은 단순한 코드 버전이 아닙니다. 전체 구성의 완전한 스냅샷입니다:

agent_version =
  code_version
  + prompt_template_version
  + model_version
  + knowledge_index_version
  + tool_schema_version
  + guardrail_policy_version
  + eval_threshold_version

모든 구성요소는 독립적으로 버전이 관리됩니다. 모든 조합은 추적 가능합니다. 감사관이 “3월 4일에 구동 중이던 시스템의 상태를 보여주십시오”라고 요청할 때 제시해야 하는 것이 바로 이 정확한 스냅샷입니다.

결론 (The Bottom Line)

FDA 실사에서 살아남는 아키텍처는 가장 뛰어난 최신 LLM이나 가장 화려한 UI를 갖춘 아키텍처가 아닙니다. 신원 확인부터 불변의 감사 커밋에 이르기까지, 어떠한 우회도, 지름길도, 기록되지 않은 상태 전이도 없이 모든 요청이 7개 계층 전체를 온전히 통과하는 아키텍처입니다.

에이전트를 만들기 전에 컴플라이언스 사이드카를 구축하십시오. 유스케이스를 개발하기 전에 스택을 잠그십시오. 읽기 전용 SOP Q&A부터 시작하십시오. 모든 변경마다 평가를 실행하십시오. 프롬프트를 코드처럼 다루십시오. 하네스를 결정론적으로 만드십시오. 감사 추적을 불변으로 유지하십시오.

에이전트는 교체 가능하지만, 아키텍처는 교체할 수 없습니다.

심층 기술 연구 노트: [[규제 대상 생명과학 분야 AI 에이전트 참조 아키텍처: 종합 연구 보고서]]

관련 기사