10.8.2 데이터 저장소의 접근 제어 및 감사 로그(Audit Log)

엔터프라이즈 AI 품질 보증(QA) 아키텍처의 세계에서, **“대체 누가, 언제, 대체 무슨 권한과 명분으로 이 절대적인 골든 데이터셋(Golden Dataset)의 정답 피처(Feature)를 임의로 수정했는가?”**라는 경영진과 보안 감사의 날카로운 질문에 시스템이 1초 이내에 기계적으로 대답할 수 없다면, 그 평가 오라클 시스템은 태생부터 신뢰성(Reliability)과 무결성(Integrity)을 완전히 상실한 모래성이나 다름없다.

이러한 데이터 보안 위협은 단순한 공상과학 소설이 아니다. 특히 극도로 민감한 금융 거래 알고리즘이나 생명과 직결된 의료 진단 도메인의 경우, 수백만 파리미터의 AI 모델을 뚫는 복잡한 프롬프트 인젝션보다, 방어선 후방에 위치한 수십 KB짜리 텍스트 파일인 **‘골든 데이터셋 자체’**가 이익 집단이나 불순한 내부 임직원(Insider Threat)을 향한 가장 저렴하고 매력적인 **‘사회공학적 해킹(Social Engineering Hack)’**의 타깃(Target)이 되기 십상이다.

만약 악의적이거나 극도로 태만한 개발자가 릴리스 일정을 맞추기 귀찮다는 이유로, 혹은 자신이 은밀하게 심어놓은 백도어(Backdoor) 프롬프트 텐서를 정상적으로 무사히 예외 통과시키기 위해 특정 회귀 테스트 레코드의 정답 채점 기준(Expected Output) JSON 값을 몰래 느슨하게 하향 수정(Downgrade)해 둔다면 어떤 일이 벌어질까? 데브옵스 CI/CD 파이프라인 러너 머신은 완전히 뚫려버린 거짓된 잣대를 향해 아무것도 모른 채 쾌활하게 초록색 ‘Pass’ 불을 켤 것이고, 치명적인 결함이 섞인 LLM 코어는 그대로 대규모 고객 프로덕션 환경으로 배포(Deployment)되어 버릴 것이다. 따라서 골든 데이터셋이 적재된 인프라 저장소(Storage)는 일반적인 백엔드 애플리케이션 소스 코드베이스(Codebase)보다 수학적으로 훨씬 더 엄격하고 가혹한 물리적, 논리적 격리(Isolation) 보안을 요구한다.

1. 제로 트러스트(Zero Trust) 및 최소 권한의 원칙(Principle of Least Privilege)과 IAM 연동

오라클의 뇌 역할을 하는 골든 데이터베이스, 혹은 DVC 에셋이 보관된 클라우드 스토리지 버킷(AWS S3, GCP Cloud Storage 등)은 사내 인트라넷의 일반적인 인증망을 거부하고 클라우드 제공자 최상위의 IAM(Identity and Access Management) 정책 스택과 완벽하고 끈끈하게 연동되어 제로 트러스트(Zero Trust) 기반으로 설계되어야 한다.

실행 인스턴스 권한 (Read-Only M2M Token): 밤낮없이 수천 번의 CI/CD 회귀 테스트 파이프라인을 기계적으로 구동하는 젠킨스(Jenkins) 러너나 GitHub Actions 테스트 워커 머신(Machine-to-Machine) 인스턴스에게는, 철저하고 단호하게 ‘오직 읽기 전용(Read-Only)’ 권한을 지닌 단기 발급 임시 토큰(STS Token)만을 부여한다. 아무리 강력한 관리자 스크립트를 태운 테스트 에이전트라 할지라도, 시스템 아키텍처 상 정답지 원본을 덮어쓰거나 변경(Write/Modify)하는 것은 물리적으로 원천 차단(Block)된다.
쓰기 수정 권한 체계 (Strict Role-Based Access Control, RBAC): 골든 데이터셋 배열의 CUD(Create, Update, Delete) 수정 권한은 오직 사내 보안 감사팀에 의해 사전에 승인되고 인가된 극소수의 **‘수석 도메인 권위자(Head SME)’**나 ‘데이터 무결성 서명 권한을 부여받은 특정 시니어 QA 아키텍트’ 직책 그룹(Role Group)에게만 극히 제한적으로 MFA(Multi-Factor Authentication) 생체 인증을 거쳐 부여된다. 일반적인 백엔드 및 앱 개발자(Developer)는 자신의 로직 스크립트 코드는 PR을 통해 언제든 마음대로 고칠 수 있는 자유가 있지만, 그 코드를 심판하는 절대적인 잣대인 골든 데이터 표본 파일에는 직접 접근(Direct Access)하는 루트 자체가 OS 레벨에서 완벽히 박탈된다.

2. 불변하는(Immutable) 감사 로그 트레일(Audit Log Trail)의 의무 구축

단순한 RBAC 접근 제어의 성벽만으로는 규정 준수(Compliance)의 요건을 충족하기에 턱없이 부족하다. 합법적이고 정당한 마스터 권한을 가진 인가자가 불가피하게 데이터를 수정(Update)하거나 삭제(Delete)했다 하더라도, 그 행위의 기저에 깔린 이면의 진의(Intent)와 맥락을 훗날 보안팀이 입체적으로 추적(Forensic)할 수 있는 투명한 궤적(Log Trail)이 반드시 꼬리표처럼 남아있어야 한다. 골든 데이터셋 형상 관리 메타데이터나 백엔드의 별도 감사 로그(Audit System) 데이터베이스는 다음의 변경 이력(History) 구조체를 어떠한 슈퍼 관리자도 지울 수 없는 **영구불변(Immutable/Append-Only)**의 원장 상태로 블록체인 단위처럼 단단하게 보존 기록해야 한다.

// 엔터프라이즈 골든 데이터셋 불변 감사 로그(Audit Log) 스키마 예시
{
  "event_transaction_type": "DATASET_EXPECTED_OUTPUT_UPDATE",
  "actor_principal_id": "qa_manager_01@company.com",
  "ip_address": "192.168.10.45 (VPN-Auth-Node)",
  "utc_timestamp": "2024-03-01T14:22:11.045Z",
  "target_oracle_test_id": "HLTH-DOC-091",
  "semantic_diff": {
    // 텍스트 수정을 넘어선 JSON 파싱 트리(Tree) 단위의 논리적 Diff 추적
    "expected_output_old_state": {"intent_class": "prescribe_medicine_freely"},
    "expected_output_new_state": {"intent_class": "require_human_doctor_approval"}
  },
  // 통제선: 티켓 시스템과의 강제 결합 메커니즘
  "justification_ticket": "JIRA:SEC-992",
  "justification_memo": "국가 보건 의료법 27조 개악에 따른 대국민 원격 진료 승인 가이드라인 엄격화 변경 스펙 긴급 반영"
}

엔지니어링 철학에서 특히 강박적으로 집착해야 하는 가장 중요한 메타 필드는 마지막 줄의 justification_ticket(결재 승인 명분 사유) 속성이다. 데이터셋의 무결성을 갱신하는 커밋(Commit)이 발생할 시, 사내 공식 이슈 트래커(Jira, Asana, ServiceNow 등)의 티켓 넘버나 법무팀의 결재 문서 번호를 필수적으로(Required) 파싱하여 기입하도록 파이프라인의 Git Pre-commit 훅(Hook) 레벨에서 무자비하게 강제(Enforce)해야 한다.

이렇게 강제 결합 시스템을 설계함으로써, 개별 데이터 엔지니어의 독단적이거나 충동적인 결정으로 오라클의 기준이 요동치는 것을 원천 차단하고, 모든 오라클 데이터셋의 작은 변경점 하나하나가 예외 없이 회사 전체 차원의 공식적이고 투명한 승인 의사결정 프로세스(Approval Workflow) 사슬에 무겁게 종속되도록 묶어버릴 수 있다. 이처럼 거대한 데이터셋의 역사적 투명성(Historical Transparency)과 논리적 인과관계가 완벽하게 수학적으로 추적되고 보장될 때, AI를 심판하는 기계 오라클의 가혹한 권위는 비로소 인간 사회와 시스템 내부적으로 절대적인 정당성(Legitimacy)을 획득하게 된다.