제약, 의료기기, 항공우주, 금융과 같은 규제 산업에서 표준작업지침서(SOP, Standard Operating Procedure)는 단순한 문서가 아닙니다. 이는 엄격하게 통제되고 밸리데이션되었으며 법적 구속력을 갖는 산출물(artifact)입니다. 모든 문장은 이미 철저한 검토, 승인, 감사를 거쳤습니다. 타당한 근거(justification) 없이 단 한 단어를 변경하는 것만으로도 CAPA(시정 및 예방 조치)가 발행되거나, FDA 실사(inspection)에서 지적을 받거나, 적격성 평가 프로토콜(qualification protocol)이 무효화될 수 있습니다.

이제 이 문서를 LLM에 전달하며 “새로운 캘리브레이션 요구사항을 반영해 섹션 4.2를 업데이트해 달라”고 요청하는 상황을 상상해 보십시오. 어떤 일이 일어날까요? LLM은 섹션 전체를 다른 단어로 다시 작성해 버립니다. “shall”을 “must”로 바꾸고, “명확성”을 높인다며 문장 순서를 뒤섞으며, 이전에는 없던 마무리 문장을 덧붙입니다. 의미 자체는 유지되었을지 몰라도 문서는 원본과 40%나 달라졌으며, 이러한 모든 변경 사항은 QA(품질 보증) 부서에서 일일이 재검토하고, 재밸리데이션하며, 다시 승인을 받아야만 합니다.

이것은 가상의 시나리오가 아닙니다. 모든 대형 언어 모델의 기본 동작 방식입니다. 그리고 GxP 환경에서 이는 컴플라이언스(규정 준수)의 악몽과도 같습니다.

그렇다면 질문은 이것입니다. “나머지 내용을 다시 작성하지 않고, LLM이 규제 대상 SOP에 대해 섹션별로 외과수술처럼 정밀하고 최소한의 편집만 수행하도록 강제하려면 어떻게 해야 하는가?” 그 해답은 모든 규제 문서 에이전트의 아키텍처를 뒤바꾸는 근본적인 통찰로 귀결됩니다.

모두가 동의한 단 하나의 원칙

LLM은 수정 가능한 전체 문서를 보관하거나 출력해서는 결코 안 된다.

그 어떤 신뢰할 만한 분석에서도 LLM이 전체 SOP를 확인하고 수정된 버전을 통째로 반환하도록 허용해서는 안 된다고 조언합니다. 아키텍처는 ’작성자(author)로서의 LLM’에서 근본적으로 다른 패러다임으로 전환되어야 합니다:

LLM은 제안하고, 시스템은 적용하며, 인간은 승인한다.

LLM의 역할은 구조화된 패치(patch)—타당한 근거(rationale)가 포함된 정밀 타깃 편집 목록—를 출력하는 것입니다. 결정론적(deterministic) 스크립트가 해당 편집 사항을 마스터 문서에 적용합니다. 그리고 통제된 원본 사본(controlled copy)에 반영되기 전에 반드시 인간이 이를 검토하고 승인합니다. 전체 문서를 두고 LLM이 직접 펜을 쥐는 순간은 결코 존재하지 않습니다.

LLM의 기본 동작 방식이 위험한 이유

LLM은 유용하고 매끄러운 글을 작성하도록 훈련되었습니다. 20페이지 분량의 SOP를 컨텍스트 창에 넣고 업데이트를 요청하면, 모델은 이를 열린 캔버스처럼 취급합니다. 모델의 다음 토큰 예측(next-token prediction) 메커니즘은 자연스럽게 일관되고 “개선된” 문장을 선호합니다. 모델은 다음과 같은 동작을 수행합니다:

  • 수정할 필요가 없던 문장을 다른 말로 바꾸어 표현
  • 동의어 교체 (“technician” → “operator”, “shall” → “must”)
  • “논리적 흐름”을 개선한다며 절차의 순서를 변경
  • 원본에 없던 전환 어구나 접속 문장 추가
  • 서식, 대소문자 표기 또는 번호 매기기를 임의로 변경

이러한 변경 사항 중 악의적인 것은 전혀 없습니다. 자연스러운 텍스트 생성을 위해 최적화된 모델의 지극히 당연한 동작일 뿐입니다. 하지만 밸리데이션된 SOP에서 이러한 모든 변경은 무단 수정(unauthorized modification)에 해당하며, 재검토, 재밸리데이션, 감사 문서화를 유발합니다.

해결책은 단순히 더 나은 프롬프트 엔지니어링에만 있지 않습니다. 문서 전체의 재작성을 물리적으로 불가능하게 만드는 아키텍처적 제약이어야 합니다.

합의된 표준 아키텍처

여러 분석 결과는 다음과 같은 8단계 파이프라인으로 수렴합니다:

┌──────────────────────────────────────────────────┐
│              CHANGE REQUEST (CR)                 │
│  "Update calibration logging from 48h to 24h"    │
└──────────────────────┬───────────────────────────┘
                       │
       ┌───────────────▼───────────────┐
       │  STEP 1: STRUCTURED PARSE     │  ← 영구 ID가 부여된 JSON 트리로
       │  (sections with IDs + hashes) │     SOP 구조화 저장
       └───────────────┬───────────────┘
                       │
       ┌───────────────▼───────────────┐
       │  STEP 2: PLANNER              │  ← 영향받는 섹션 식별
       │  "Only SEC-4.2 is impacted"   │     (저비용 LLM 호출 또는 규칙 기반)
       └───────────────┬───────────────┘
                       │
       ┌───────────────▼───────────────┐
       │  STEP 3: SECTION ISOLATION    │  ← SEC-4.2만 컨텍스트에 진입
       │  Lock all other sections      │     불변(Immutable) 섹션은 제외
       └───────────────┬───────────────┘
                       │
       ┌───────────────▼───────────────┐
       │  STEP 4: EDITOR AGENT         │  ← 구조화된 델타(Delta) 출력
       │  (temp=0, strict prompt)      │     (REPLACE/INSERT/DELETE)
       └───────────────┬───────────────┘
                       │
       ┌───────────────▼───────────────┐
       │  STEP 5: VERIFICATION LAYER   │  ← 해시 검증 + Diff 비율 +
       │  (automated, deterministic)   │     시맨틱 드리프트 감지
       └───────────┬───────────┬───────┘
                   │           │
                통과(Pass)   실패(Fail) → 반려 후 재시도
                   │
       ┌───────────▼───────────────┐
       │  STEP 6: HUMAN REVIEW     │  ← SME가 레드라인 및 근거 검토
       │  (GxP checkpoint)         │
       └───────────┬───────────────┘
                   │
       ┌───────────▼───────────────┐
       │  STEP 7: DETERMINISTIC    │  ← Python 스크립트가 마스터 JSON
       │  ASSEMBLY                 │     트리에 패치 적용
       └───────────┬───────────────┘
                   │
       ┌───────────▼───────────────┐
       │  STEP 8: AUDIT LOG        │  ← CR ID, 정확한 델타, 변경 사유,
       │  + CHANGE HISTORY UPDATE  │     승인 기록, 타임스탬프
       └───────────────────────────┘

각 단계를 자세히 살펴보겠습니다.

1단계: 구조화된 문서 표현 (Structured document representation)

규제 대상 SOP를 단순한 평문 문자열(flat string)로 저장해서는 안 됩니다. 모든 콘텐츠 단위가 영구적인 식별자(persistent identity)를 갖도록 구조화된 트리 형태로 파싱해야 합니다:

{
  "sop_id": "SOP-4012",
  "version": "3.1",
  "sections": [
    {
      "section_id": "SEC-4.2-A",
      "heading": "4.2 Equipment Calibration",
      "version_hash": "a3f8c1",
      "status": "approved",
      "content": "Upon completion of calibration, the technician shall log the results in the QMS system within 48 hours."
    },
    {
      "section_id": "SEC-4.2-B",
      "heading": null,
      "version_hash": "b7d2e9",
      "status": "approved",
      "content": "The equipment must be tagged with a 'Calibrated' status."
    }
  ]
}

모든 섹션, 서브섹션 및 단락에는 다음 요소가 부여됩니다:

  • 버전이 바뀌어도 유지되는 영구 ID(persistent ID) (예: SEC-4.2-A)
  • 위변조 감지를 위한 콘텐츠 해시(content hash) (SHA-256)
  • 상태 플래그(status flag) (승인됨, 잠김, 편집 가능)
  • 메타데이터(metadata) (문서 책임자, 승인 날짜, 연계된 CR 번호)

이 구조는 이후의 모든 작업을 위한 기반이 됩니다. 이 구조 없이는 특정 위치만을 타깃으로 편집하거나, 변경되지 않은 섹션을 검증하거나, 감사 추적(audit trail)을 생성할 수 없습니다.

2단계: 변경 범위 분석 (플래너, Planner)

편집 담당 LLM이 문서를 보기 전에, 경량화된 플래너(Planner)가 변경 요청서(CR)의 영향을 받는 섹션이 무엇인지 식별합니다. 이는 다음과 같은 방식으로 구현할 수 있습니다:

  • SOP의 목차와 변경 요청서를 입력받는 저비용 LLM 호출(GPT-4o-mini, Claude Haiku 등)
  • CR이 정형화되어 있는 경우 규칙 기반 시스템(rule-based system)
  • 섹션 임베딩에 대한 벡터 유사도 검색(vector similarity search)

플래너는 영향받는 섹션 ID 목록만을 출력하고, 그 외의 다른 내용은 출력하지 않습니다:

{
  "affected_sections": ["SEC-4.2-A"],
  "rationale": "CR-2026-089 changes calibration logging window from 48h to 24h. Only the timing requirement in SEC-4.2-A is directly impacted.",
  "unaffected_sections": ["SEC-4.2-B", "SEC-4.1", "SEC-5.0"]
}

이 단계는 작업 범위가 무단으로 확장되는 스코프 크립(scope creep)을 방지합니다. 편집 LLM이 나중에 이 목록에 없는 섹션을 수정하려고 시도하면 검증 계층(verification layer)이 이를 즉각 잡아냅니다.

3단계: 섹션 격리 (핵심적인 제약 조건)

이 단계는 전체 문서 재작성을 물리적으로 불가능하게 만드는 핵심입니다. 영향받는 섹션과 문맥의 자연스러움을 위한 최소한의 인접 컨텍스트만을 편집 LLM에 전송합니다:

You are editing section "SEC-4.2-A" of SOP-4012 v3.1.

[Content of SEC-4.2-A]

Adjacent context (READ ONLY — do not modify):
  SEC-4.1 ending: "..."
  SEC-4.2-B beginning: "..."

Change request: "Update calibration logging window from 48h to 24h per CR-2026-089."

Output ONLY the revised content for SEC-4.2-A.
Preserve all existing language, structure, and formatting
unless directly contradicted by the change request.

LLM은 섹션 3, 섹션 5, 또는 승인 서명 블록을 전혀 볼 수 없습니다. 볼 수 없는 내용은 다시 작성할 수도 없습니다. 이는 단순한 프롬프트 수준의 제약이 아니라, 아키텍처 차원의 제약입니다.

4단계: 구조화된 델타 (The structured delta)

편집 LLM은 수정된 문단을 그대로 반환하지 않습니다. 대신 구조화된 패치(patch)를 반환합니다:

[
  {
    "operation": "REPLACE",
    "target_id": "SEC-4.2-A",
    "original_text": "...within 48 hours.",
    "new_text": "...within 24 hours.",
    "rationale": "Updated per CR-2026-089 to reflect new FDA guidance on data integrity timelines."
  }
]

모든 변경 사항은 다음과 같은 특성을 갖습니다:

  • 특정 섹션 ID에 명확히 한정됨(Targeted)
  • CR과 연계된 추적 가능한 타당한 근거로 정당화됨(Justified)
  • 최소화됨(Minimal) — 실제로 변경이 필요한 특정 텍스트만 포함
  • 기계 판독 가능(Machine-readable) — 결정론적 스크립트가 직접 적용 가능

이는 전체 아키텍처에서 가장 강력한 영향을 미치는 설계 결정입니다. LLM은 줄글(prose)이 아니라 구조화된 명령어를 출력하기 때문에 주변 텍스트를 임의로 다시 작성할 수 없습니다.

일부 조직은 여기서 한 걸음 더 나아가, 함수 호출(function calling)을 통해 호출 가능한 도구 형태로 외과수술식 편집 연산만을 노출합니다:

tools = [
    edit_section(section_id, new_content, change_rationale),
    insert_section(after_section_id, new_content, change_rationale),
    remove_section(section_id, change_rationale),
    edit_paragraph(section_id, paragraph_index, new_content, rationale),
    edit_sentence(section_id, para_idx, sent_idx, new_text, rationale),
]

LLM은 말 그대로 “전체 재작성” 명령을 내릴 수 없습니다. 애초에 그러한 도구가 존재하지 않기 때문입니다.

5단계: 자동화된 검증 (안전망, Safety net)

엄격한 프롬프트와 격리된 컨텍스트를 적용하더라도 LLM은 미묘한 변경을 슬그머니 끼워 넣을 수 있습니다. 검증 계층(verification layer)은 이러한 변경이 인간 검토자에게 도달하기 전에 사전에 차단합니다.

해시 비교(Hash comparison). LLM에 전송하기 전에 모든 섹션의 SHA-256 해시를 계산합니다. 응답을 받은 후, 편집을 요청하지 않은 모든 섹션의 해시를 다시 계산합니다. 만약 해시가 하나라도 변경되었다면 응답을 즉시 거부(reject)합니다.

for section in locked_sections:
    before_hash = sha256(section.content)
    after_hash = sha256(response.get_section(section.id).content)
    if before_hash != after_hash:
        raise UnintendedChangeError(f"Section {section.id} was modified without authorization")

Diff 비율 점검(Diff ratio check). difflib이나 레벤슈타인 거리(Levenshtein distance)를 사용하여 원본 섹션과 제안된 편집 내용을 비교합니다. 유사도가 90~95% 미만으로 떨어지면 LLM이 너무 많은 내용을 수정한 것으로 판단합니다.

시맨틱 드리프트 감지(Semantic drift detection). 변경되지 않아야 하는 섹션의 경우 임베딩 코사인 유사도를 계산합니다. 유사도가 0.99 아래로 떨어지면 인간 검토를 받도록 플래그를 지정합니다. 이는 의미는 같지만 문구를 바꾸어버리는 미묘한 표현 변경을 감지하며, 이는 밸리데이션 환경에서 매우 중대한 문제입니다.

핵심 키워드 보존(Keyword preservation). 동결된(frozen) 섹션 내의 필수 규제 용어(“shall”, “must”, “ALCOA+”, 특정 약어 등)가 정확히 그대로 보존되었는지 검증합니다.

검사 항목 중 하나라도 실패하면 시스템은 출력을 거부하고 더 엄격한 프롬프트로 재시도합니다: “이전 출력이 원본 텍스트를 너무 많이 변경했습니다. 변경 요청서에 명시된 특정 요구사항만 변경하여 다시 시도하십시오.”

6단계: 인간 검토 (GxP 체크포인트)

제안된 델타는 자격을 갖춘 검토자에게 레드라인(redline, 교정본) 형태로 제시됩니다. 이는 Microsoft Word의 변경 내용 추적 기능과 유사하지만, LLM이 아닌 diff 알고리즘에 의해 프로그래밍 방식으로 생성됩니다:

Section 4.2 Equipment Calibration
──────────────────────────────────
 Upon completion of calibration, the technician shall log
-the results in the QMS system within 48 hours.
+the results in the QMS system within 24 hours.
 The equipment must be tagged with a "Calibrated" status.

Change Rationale: Updated per CR-2026-089 to reflect new
FDA guidance on data integrity timelines.
──────────────────────────────────
[Approve] [Reject] [Request Revision]

검토자는 무엇이 변경되었는지, 왜 변경되었는지만을 정확하게 확인할 수 있으며 그 외의 불필요한 내용은 볼 필요가 없습니다. SOP 전체를 다시 읽을 필요가 전혀 없는 것입니다. 이는 규제 문서 워크플로의 가장 큰 두 가지 병목 현상인 검토 시간과 검토 피로도(review fatigue)를 획기적으로 줄여줍니다.

인간의 명시적인 승인 없이는 마스터 문서에 그 어떤 변경도 적용되지 않습니다. 이는 GxP 환경에서 결코 타협할 수 없는 원칙입니다.

7단계: 결정론적 조립 (Deterministic assembly)

최종 SOP는 LLM에 의해 “생성”되는 것이 아닙니다. 다음과 같은 작업을 수행하는 Python 스크립트에 의해 조립됩니다:

  1. 마스터 JSON 문서를 가져옴
  2. 승인된 패치를 적용 (대상 섹션 ID에서 정확한 문자열 치환 수행)
  3. 버전 번호를 증가시킴
  4. 결정론적 렌더러를 사용하여 PDF/Word 문서로 내보냄
def apply_patch(master_doc: dict, approved_patch: list[dict]) -> dict:
    for edit in approved_patch:
        section = master_doc.get_section(edit["target_id"])
        section.content = section.content.replace(
            edit["original_text"], edit["new_text"]
        )
        section.version_hash = sha256(section.content)
        section.metadata.last_modified = datetime.utcnow()
        section.metadata.change_request_id = edit["cr_id"]
    master_doc.version = increment_version(master_doc.version)
    return master_doc

이를 통해 최종 산출물이 승인된 내용과 정확하게 일치함을 보장합니다. 드리프트도, 환각도, 최종 단계에서의 손상(last-mile corruption)도 발생하지 않습니다. 조립 단계에는 LLM이 전혀 관여하지 않습니다.

8단계: 감사 추적 (Audit trail)

모든 변경 사항은 완벽한 추적성(traceability)을 갖추어 기록됩니다:

  • 타임스탬프 및 사용자/에이전트 ID (누가 업데이트를 트리거했는가)
  • CR ID (해당 편집을 승인한 공식 변경 요청서 번호)
  • 정확한 텍스트 델타 (정밀한 문자열 치환 내역)
  • 변경 사유(Change rationale) (LLM이 제시한 타당성 근거)
  • 승인 기록 (누가 검토하고 최종 승인했는가)
  • 변경 전/후 해시 값 (무엇이 변경되었는지에 대한 암호학적 증명)

SOP의 공식 개정 이력(Change History) 섹션에는 다음과 같은 새 항목이 자동으로 업데이트됩니다:

Version Date CR ID Description Approved By
3.1 → 3.2 2026-07-04 CR-2026-089 Updated calibration logging from 48h to 24h per FDA guidance J. Smith, QA

이러한 감사 추적은 WORM(Write Once Read Many) 스토리지나 해시 체인 로그(hash-chained logs)와 같이 위변조 방지 스토리지에 보관되며, FDA 실사관이 방문했을 때 가장 먼저 열람을 요청하는 항목입니다.

이를 실현하는 프롬프트 엔지니어링

편집 에이전트의 시스템 프롬프트는 텍스트를 “개선”하려는 LLM의 타고난 본능에 적극적으로 대응해야 합니다. 주요 지침은 다음과 같습니다:

CORE EDIT PRINCIPLES:
1. You are a conservative editor, not an author.
   Your job is to make the MINIMUM change necessary.
2. Preserve existing approved language. Do not rephrase
   sentences that are not directly affected by the change request.
3. Do not reorganize, reorder, or restructure content
   unless explicitly requested.
4. If the change request is ambiguous, ask for clarification
   rather than guessing and over-editing.
5. Every change must have a traceable rationale tied to
   a specific requirement (regulation, CR, CAPA).
6. If a change can be made by modifying a single word
   rather than rewriting a paragraph, choose the smaller change.
7. Never alter: document metadata, section numbering,
   approval blocks, or signature lines unless specifically directed.

퓨샷 예제(Few-shot examples)는 대단히 효과적입니다. 모델에게 문단 전체의 어조를 바꾸어버린 ‘나쁜 편집(bad edit)’ 예시와 단 하나의 구체적인 값만 수정한 ‘좋은 편집(good edit)’ 예시를 함께 보여주십시오. 이는 추상적인 지침을 나열하는 것보다 모델의 동작을 훨씬 더 신뢰성 있게 보정해 줍니다.

온도(temperature)는 반드시 0.0으로 설정하십시오. 규제 대상 문서 편집에서는 타협할 수 없는 기본 조건입니다. 가장 결정론적이고 예측 가능한 토큰 경로를 확보해야 하기 때문입니다. 일부 엔지니어링 팀은 완전한 재현성(reproducibility)을 위해 seed 파라미터까지 고정하여 사용합니다.

멀티 에이전트 패턴 (The multi-agent pattern)

분석 결과에 따르면 작업을 전문화된 에이전트들로 분할하는 패턴이 권장됩니다:

에이전트 (Agent) 역할 (Role) 방지하는 리스크 (Prevents)
플래너 (Planner) CR 분석, 영향받는 섹션 식별 스코프 크립 (무단 범위 확장)
에디터 (Editor) 격리된 섹션 수신, 최소 델타 출력 환각성 재작성
리뷰어 (Reviewer) 이전 vs 신규 비교, 무단 변경 점검 과도한 편집 (Over-editing)

플래너와 리뷰어는 저비용 모델(또는 규칙 기반 시스템)로 구성해도 충분합니다. 강력한 언어 이해 능력이 필요한 것은 에디터뿐입니다. 이러한 관심사의 분리(separation of concerns)를 통해 각 에이전트는 좁고 검증 가능한 역할을 수행하게 되며, 시스템 전체는 단일 에이전트보다 훨씬 더 높은 신뢰성을 확보하게 됩니다.

불변 섹션 패턴 (The immutable sections pattern)

규제 대상 SOP에는 LLM이 절대 손대서는 안 되는 필수 상용구(boilerplate)가 포함되어 있습니다:

  • 규제 참조 헤더 (예: “Per 21 CFR 211.22”)
  • 승인 블록 및 서명란
  • 문서 제어 메타데이터
  • 표준 정의 및 용어집 항목

문서 모델에서 이러한 항목들을 **불변(immutable)**으로 표시하십시오. LLM은 편집 가능한 컨텍스트 내에서 이 내용들을 아예 전달받지 못합니다. 이들은 기준 저장소(canonical store)로부터 온전히 보존된 채 최종 문서에 다시 조립됩니다.

{
  "section_id": "SEC-HEADER",
  "content": "SOP-4012: Equipment Calibration Procedure",
  "immutable": true,
  "lock_reason": "Regulatory header required per 21 CFR 211.22"
}

피드백 루프 (The feedback loop)

위의 아키텍처는 편집 파이프라인을 체계적으로 처리합니다. 그렇다면 시간이 지남에 따라 이 시스템을 어떻게 지속적으로 개선할 수 있을까요?

모든 거부(반려) 기록 로깅. 검증 계층이 LLM의 출력을 거부할 때(과도한 드리프트, 무단 변경 등), 원본 입력과 거부된 출력, 그리고 구체적인 사유를 모두 기록합니다. 이 데이터는 파인튜닝(fine-tuning)을 위한 귀중한 자산이 됩니다.

주간 정기 검토. 사람이 거부 로그를 정기적으로 검토합니다. 어떤 거부는 정당한 차단(LLM이 임의로 문장을 바꾸려 한 경우)일 것이고, 어떤 것은 오탐(false positive, 정당한 편집이었으나 유사도 임계값에 의해 잘못 플래그 지정된 경우)일 것입니다. 이러한 오탐 사례들을 평가 데이터셋(evaluation dataset)에 지속적으로 반영합니다.

프롬프트 반복 개선. 에디터의 프롬프트를 수정할 때는 배포 전에 이미 검증된 30~200건의 SOP 편집 케이스로 구성된 고정 평가 데이터셋에 대해 테스트를 수행하십시오. 그리고 다음을 측정합니다: LLM이 의도한 섹션만 변경했는가? 손대지 않은 콘텐츠의 정확한 문구를 그대로 보존했는가? 타당한 근거(rationale)를 포함했는가?

이를 통해 가드레일 시스템은 정적인 벽에 머무르지 않고, 편집 주기를 거듭할 때마다 정확도가 향상되는 학습형 시스템으로 진화합니다.

결코 건너뛰어서는 안 될 핵심 요소

오늘날 이러한 시스템을 구축하고 있다면, 규제 환경에서 결코 타협할 수 없는 최소 요구사항은 다음과 같습니다:

  1. 영구 섹션 ID를 갖춘 구조화된 문서 표현(Structured document representation)
  2. 섹션 격리(Section isolation) — 영향받는 섹션만 LLM에 전달
  3. Diff 전용 출력(Diff-only output) — 전체 문서가 아닌 구조화된 패치 출력
  4. 부정적 제약 조건(negative constraints)과 퓨샷 예제를 포함한 엄격한 프롬프트 엔지니어링
  5. 자동화된 검증(Automated verification) — 수정되지 않은 섹션에 대한 해시 검증
  6. 인간 검토(Human review) — 승인/반려 기능이 포함된 레드라인 뷰
  7. 감사 추적(Audit trail) — 모든 변경 사항이 완벽한 추적성을 갖추고 CR에 연계

그 외의 모든 요소—멀티 에이전트 아키텍처, 함수 호출, 불변 섹션, 문장 단위 추적, LLM 판사(LLM-as-judge) 검증 등—는 최적화 영역입니다. 위의 일곱 가지가 기본 토대입니다. 이 일곱 가지가 없다면 여러분이 만든 것은 규제 대상 문서 에이전트가 아닙니다. 단지 회사의 법적 책임(liability)이자 리스크를 양산하는 기계일 뿐입니다.

각 기법별 일치도 점수를 포함한 전체 분석 내용은 [[Surgical SOP Editing with LLMs - Multi-LLM Consensus|연구 노트]]에서 확인하실 수 있습니다.

관련 기사