[MRM 스레드] 에피소드 3 — 감사의 감사자들: Chain of Custody와 컨센서스 중재

“MRM 스레드” 3편. Ep 2 가 승격 결정의 기록을 다뤘다면, 이번 편은 그 기록이 무엇을 담는지(7개 감사 테이블 · HMAC 체인), 그 기록을 누가 검증하는지(Ops · Audit 에이전트), 그리고 그 검증자들이 어떻게 서로를 견제하는지(3인 병렬 투표 · 2-Round 심의)까지 한 층씩 내려가 본다.

2027년 6월의 질문

시나리오 하나. 2026년 4월의 어느 고객이 2027년 6월 어느 분쟁 심사 창구에 이의제기를 넣는다. “15개월 전 이 상품을 추천받았는데, 나는 이 추천이 내 소득 계층을 기준으로 차별적으로 작동했다고 본다. 어떤 근거로 이 상품이 나에게 추천됐는가?” 금융소비자보호법 §17 적합성 원칙에 따라 금융기관은 답해야 한다.

종래 모델이라면 여기서 몇 가지 답변 형태가 있다 — “그 시점의 특징 점수를 재현할 수는 없지만 모델은 일반적으로 …” 같은 정성적 설명, 혹은 “해당 고객은 A 상품군 선호 세그먼트에 속해 있었다” 같은 SHAP 근사 설명. 규제 대응 측면에서는 충분치 않다. 시점 특정성이 부족하고 재구성 가능성이 결여되어 있다.

우리 파이프라인의 답은 다른 형태를 가진다. 15개월 전 그 고객에게 추천이 나간 순간, 무엇이 감사 로그 어느 위치에 쓰였는가 를 정확히 특정할 수 있다. 그리고 그 로그가 위변조되지 않았음 을 독립적으로 보증한다. 이 두 단계의 특정성을 어떻게 쌓아 올렸는지가 이번 편의 주제다.

7개 감사 테이블의 분담

감사 로거 모듈에 7개의 log_* 메서드가 있고, 각각 별도의 감사 테이블에 쓰인다.

log_operation — 시스템 상태 전이 (재학습 시작·종료, 승격, 서빙 매니페스트 교체)
log_model_inference — 예측 하나하나의 발생 시점·대상·모델 버전
log_data_access — 누가 어느 데이터에 접근했는가
log_dimension_change — 피처 스키마 변화 (349D → 403D 같은)
log_attribution — 각 예측에서 어느 피처가 얼마나 기여했는가
log_guardrail — Safety Gate 가 어떤 출력을 차단 또는 수정했는가
log_model_promotion — Ep 2 에서 다룬 승격 결정

테이블이 7개로 분할된 건 관심사 분리 원칙의 결과다. 한 테이블에 모든 이벤트를 섞으면 검색·감사·보존 정책이 꼬인다. 예를 들어 log_data_access 는 PIPA 와 신용정보법 감사 대상이라 보존 주기가 다르고, log_model_promotion 은 SR 11-7 Pillar 2 대상이라 접근 권한이 다르다. 한 테이블로 묶으면 가장 엄격한 정책이 나머지를 지배하게 되어 저장 비용이 폭등한다.

한 요청이 테이블을 어떻게 거치는가

파트너 기관과의 실 트래픽 수집은 2026년 4월 30일에야 시작되었으므로, 위 재구성 속성이 아직 대규모 운영 환경에서 검증된 것은 아니다. 현재 존재하는 것은 설계뿐이다. 이 설계가 어떻게 작동하는지 이해하기 위해, 만기된 정기예금을 재예치하러 내점한 고객에게 추천 시스템이 ‘적금 + 예금 조합’을 제안하는 상황을 따라가 보자.

이 추론 과정에서는 4개의 테이블에 순차적으로 로그가 기록된다.

log_data_access가 가장 먼저 기록된다. 영업점 직원이 인증을 마치고 고객을 대신해 추천을 요청할 때 발생한다. 작업자 ID, 고객 ID, 접근 사유(“영업점 발단 추천”)가 남으며, PIPA 제37조의2를 충족하기 위한 감사 연결점이 된다.
log_model_inference는 경량화된 LightGBM 모델이 13개 태스크를 실행해 점수를 산출할 때 기록된다. 모델 버전 포인터와 피처 텐서 해시값이 남아, 나중에 “어떤 모델이 어떤 입력값을 보고 판단했는가”를 정확히 추적할 수 있다.
log_attribution은 직후에 기록되며, 상위 K개 피처의 기여도와 전문가 게이트 가중치를 담는다. EU AI 법안 제13조와 금융소비자보호법 제17조에서 요구하는 “왜 이 고객에게 이런 추천을 했는가”에 답하기 위한 근거 자료다.
log_guardrail은 Safety Gate 에이전트가 규제 준수·적합성·환각 여부·어조·사실성 5가지 기준으로 추천 설명을 검토할 때 기록된다. 최종 판정(pass/modify/block)과 기준별 점수가 결과와 무관하게 모두 남는다.

전체 추론 과정은 1초도 걸리지 않는다. 4개의 감사 로그를 남기지만 오버헤드는 미미한 수준이다. 각각 작고 표준화된 JSON 페이로드를 덧붙이는 방식이기 때문이다.

나머지 3개 테이블은 개별 요청마다 기록되지 않는다. log_operation은 시스템 상태가 변할 때(야간 재학습 시작·종료, 서빙 매니페스트 교체 등), log_dimension_change는 피처 스키마가 변경될 때(예: Phase 0 개정 후 349D에서 403D로 변경), log_model_promotion은 챔피언-챌린저 판정(Ep 2 참고)이 일어날 때 각각 기록된다.

HMAC 해시 체인 — 왜 “그냥 로그”가 아닌가

각 엔트리는 단순히 쓰여지는 게 아니다. log_operation() 이 호출되는 순간 세 가지가 동시에 일어난다.

엔트리 직렬화 — 타임스탬프, 이벤트 타입, payload 를 canonical JSON 으로 정규화
HMAC 서명 — 직전 엔트리의 해시 + 현재 엔트리 내용을 감사 전용 서명 키로 서명
체인 연결 — 현재 엔트리의 prev_hash 필드에 직전 엔트리 해시를 박아넣음

이 구조가 얻는 결과 한 가지 — 엔트리 n 을 수정하려면 n+1, n+2, …, 최신 엔트리까지 전부 재서명해야 한다. 공격자가 HMAC 키를 얻지 않는 한 불가능하다. 즉 위변조 증거성이 “신뢰” 가 아니라 “구조” 로 보장된다.

참고로 AWS 키 관리 관점에서, 감사 서명 키는 SSM Parameter Store(SecureString)에 저장되고 Lambda 런타임에 IAM 역할로만 접근 가능하다. 키 노출이 곧 감사 무결성 전체 붕괴라서, 이 부분은 MRM 감독의 개별 검증 포인트 다 — “감사 로그가 있습니다” 가 아니라 “감사 서명 키가 별도 로테이션 정책 하에 있습니다” 까지 가야 의미.

여기까지가 Ep 3의 전반부다. 기록이 있고, 그 기록이 위변조되지 않음이 구조적으로 보장된다. 그런데 여기엔 한 가지 질문이 남는다.

누가 로그를 검증하는가 — 단일 LLM 감사자의 함정

감사 로그가 있다고 해서 “로그가 맞다” 는 보장은 아니다. 누가 매일 hash chain 이 깨지지 않았는지 확인하는가? 누가 이상 신호를 찾아내는가? 규제 키워드 위반을 누가 읽어내는가?

여기서 단순한 답은 “LLM 에이전트 하나를 돌려서 매일 밤 검증하게 한다”이다. 실제로 초기 프로토타입은 그렇게 만들어졌다. Sonnet 한 세션이 직전 24시간의 감사 로그를 읽고 “이상 없음” 또는 “다음 항목 주의”를 내놓는 구조였다.

이 방식의 문제는 운영 몇 주 만에 드러났다. 같은 입력에 같은 프롬프트를 넣어도 출력이 미묘하게 흔들렸다. 어떤 날은 특정 이상 신호를 잡아내고, 다른 날은 같은 패턴을 그냥 지나쳤다. Temperature 를 낮추고 system prompt 를 다듬어도 환각의 방향이 예측 불가능했다. 그리고 더 불안한 관찰이 하나 있었다 — LLM 감사자가 확신에 차서 잘못된 판정을 내렸을 때, 그 틀린 판정이 자연스러운 언어로 포장되어 오히려 더 설득력 있어 보인다.

규제 감사에서 가장 위험한 시나리오는 “감사자가 있었지만 특정 이상을 놓쳤다”가 아니다. “감사자가 있었고, 그 감사자가 틀린 판정을 확신에 차서 내렸으며, 그 판정이 기록으로 남아 이후 의사결정의 근거가 되었다”이다. 단일 LLM 감사자는 구조적으로 이 시나리오에 취약하다.

Ops 에이전트와 Audit 에이전트 — 관점의 분리

이 문제를 풀기 위해 먼저 감사자의 관점 자체를 둘로 쪼갰다.

Ops 에이전트 — “파이프라인이 잘 돌아가고 있는가” 관점. 성능 지표, 안정성, 비용, 드리프트, 콜드스타트 지연 같은 운영 건강도를 본다. 매일 야간에 돌며 GREEN · YELLOW · RED 상태를 판정하고 attention_required 리스트를 내놓는다.
Audit 에이전트 — “규정을 준수하고 있는가” 관점. HMAC 체인 무결성, 공정성 지표 위반 여부, 추천사유 품질, 규제 키워드 출현을 본다. 주 단위로 돌며 LOW · MEDIUM · HIGH 리스크 레벨과 focus_areas를 산출한다.

두 에이전트는 같은 감사 로그를 보지만 다른 질문을 던진다. Ops 는 “어제 p99 레이턴시가 300ms 를 넘긴 순간이 있었는가”를 묻고, Audit 는 “어제 발생한 log_guardrail 중 block 비율이 특정 보호군에 편중되었는가”를 묻는다. 한 에이전트가 놓칠 질문을 다른 에이전트가 집어드는 구조다.

둘은 동일한 3단계 루프를 공유한다.

Collect  (체크포인트별 측정값 수집)
  → Diagnose  (임계값 · 추세 · 상관관계 기반 진단)
    → Report  (담당자에게 "어디를 봐야 하는지" 전달)

차이는 어떤 체크포인트를 보는가, 어떤 기준으로 진단하는가다. Ops 리포트는 finding + likely_cause + suggested_action 세 필드의 리스트 형식을 갖는다. Audit 리포트는 focus_areas + regulatory_summary + reason_quality_dashboard 의 구조화된 증거 묶음이 된다.

컨센서스 중재 — 단일 세션을 신뢰하지 않는다

관점을 둘로 쪼갠 것만으로는 단일 LLM 판정의 흔들림은 해결되지 않는다. Ops 에이전트 한 세션, Audit 에이전트 한 세션이 여전히 각자의 판정을 독단적으로 내리기 때문이다.

여기서 두 번째 장치가 붙는다. 각 에이전트의 Diagnose 단계는 혼자 돌지 않고, 여러 개의 독립 세션이 병렬로 같은 진단을 수행한다. 세션마다 주어지는 system prompt 가 다르다 — 서로 다른 관점을 부여한 것이다.

α (Alpha) — 보수적 관점. “위험 신호를 놓치지 않는 것이 중요합니다. 의심스러우면 WARN 으로 판단하세요.”
β (Beta) — 통계적 관점. “모수(sample size)가 충분한지, 변동이 통계적으로 유의한지 확인하세요.”
γ (Gamma) — 비즈니스 관점. “실제 고객 경험과 비즈니스 KPI 에 미치는 영향을 기준으로 판단하세요.”

각 세션은 PASS · WARN · FAIL 중 하나의 판정과 0.0–1.0 범위의 confidence, 그리고 500–800 토큰 분량의 reasoning 을 내놓는다. 이 의견들이 모이는 지점이 ConsensusArbiter 다. 중재 결과는 다음 세 가지 중 하나로 분류된다.

Consensus — 모든 세션이 같은 판정. 확인 완료 로 간주되고 바로 리포트에 반영.
Majority (다수결) — 다수 세션이 일치하고 일부가 반대. 다수 판정이 채택되지만 우선 검토(priority review) 플래그가 붙는다.
Minority Report (소수 의견) — 판정이 갈림. 다수결로 결정하되, 소수 의견도 별도 트랙으로 영구 보존.

이 구조가 얻는 핵심은 하나다. 어느 한 세션이 환각으로 틀린 판정을 내려도, 나머지 세션들이 다른 관점에서 접근하고 있었다면 최종 결과에 소수 의견 플래그가 자동으로 붙는다. 단일 LLM 감사자가 확신에 찬 오류를 낼 수 있는 바로 그 상황에서, 다른 관점의 세션이 두 번째 의견을 구조적으로 제공하는 셈이다.

AWS와 온프렘에서 합의 방식이 다른 이유

같은 “다중 에이전트 합의”라는 목표 아래에서도, AWS 환경과 온프렘 환경은 합의 방식 자체가 다르게 설계됐다. 그 차이는 모델 역량, 비용 구조, 지연 예산, 세 조건에서 자연스럽게 갈린다.

AWS — 독립 병렬 투표 (배심원 방식)

AWS 환경에서는 Sonnet 3개 세션을 병렬로 실행한다. 세션들은 서로의 출력을 보지 않는다. α·β·γ 관점이 각자 독립적으로 판정을 내리고, 그 셋을 ConsensusArbiter 가 집계한다. 전체 소요 시간은 약 5초. 비용은 단일 세션 대비 3배다.

이 방식이 AWS에서 적절한 이유는 세 가지다. (1) Sonnet 이 충분히 강력해서 단일 세션의 판정 품질 자체가 이미 쓸 만하다 — 세션 수를 늘리는 건 흔들림의 방향을 교차 검증하기 위함이지 판정 품질 자체를 끌어올리기 위함이 아니다. (2) 병렬 실행 비용이 직선적이고 지연이 미미해서, “5초만에 3인 배심원” 이 실무적으로 성립한다. (3) 세션이 서로를 보지 않기 때문에 동조 편향(conformity bias) 이 원천 차단된다 — 소수 의견이 다수에 끌려가 사라지는 현상이 없다.

온프렘 — 2-Round 하이브리드 (독립 투표 → 순차 심의)

온프렘에서는 RTX 4070 한 장 위에서 14B Q4 양자화 모델을 쓴다. 모델 역량이 Sonnet 보다 약하다. 이 조건에서 단순히 “3개 독립 세션”을 그대로 적용하면 문제가 생긴다 — 약한 모델 3개가 각자 흔들려서 합의 자체가 불안정해진다. 반대로 “델파이(Delphi) 방식의 순차 심의” 만 쓰면 뒤 세션이 앞 세션 의견에 끌려가는 수렴 편향이 생겨 소수 의견이 사라진다.

운영·감사 맥락에서는 “놓치는 것”이 “오탐”보다 훨씬 위험하다. 오탐은 담당자가 확인하면 넘어갈 수 있지만, 놓친 이상은 규제 사고로 이어진다. 그래서 온프렘은 두 약점을 번갈아 상쇄하는 2-Round 구조를 택했다.

[Round 1: 독립 투표 — 마이너리티 보존]
  ① → "필터 문제"      (독립, 서로 안 봄)
  ② → "모수 문제"      (독립)
  ③ → "PASS"          (독립)
  ④ → "필터 문제"      (독립)
  ⑤ → "계절 패턴"      (독립)

  집계: 필터 2, 모수 1, PASS 1, 계절 1
  마이너리티 확정: ③(PASS), ⑤(계절 패턴) — 이후 삭제 불가

[Round 2: 순차 심의 — 논거 보강 (마이너리티 삭제 불가)]
  ⑥ → Round 1 전체를 보고 다수 논거 정리 + 소수 타당성 평가
  ⑦ → ⑥을 보고 종합 판정 + 각 의견 근거 보강/반박 정리

Round 1 은 독립 투표로 소수 의견을 잠가둔다. Round 2 는 순차 심의로 논거 품질을 끌어올린다. 핵심 원칙은 단 하나 — Round 1 에서 확정된 마이너리티는 Round 2 에서 삭제되지 않는다. Round 2 의 ⑥이 “⑤의 계절 패턴 가설은 타당성이 낮다”고 평가해도, 기록은 “⑥이 타당성 낮다고 평가 — 근거: … / 원 의견(⑤) 보존”의 형태로 남는다. 최종 판단은 사람이 한다.

온프렘 기본은 5개 세션(R1=5, R2=2), 고위험 판정은 7개 세션(R1=7, R2=2)까지 늘린다. 14B Q4 모델에서 건당 약 30–40초. WARN/FAIL 만 합의 실행 대상이므로 일일 5–10개 정도, 전체 약 45분이면 끝난다. 점검 직후 바로 실행 가능한 시간이다.

환경	모델	R1	R2	총 세션	항목당 소요
AWS	Sonnet	3 (병렬)	—	3	약 5초
온프렘 기본	14B Q4	5 (독립)	2 (심의)	7	약 2분
온프렘 고위험	14B Q4	7 (독립)	2 (심의)	9	약 2.5분

두 환경이 만나는 지점은 최종 분류 스키마다. AWS 3/3, 온프렘 5/5 모두 Consensus 로 묶이고, AWS 2/3·온프렘 3/5 이상이 Majority (최우선 리뷰)로, AWS 1/3·온프렘 1–2/5 이상이 Minority Report (2순위 리뷰)로 분류된다. 감사 로그에서는 환경에 무관하게 같은 필드 이름으로 저장되어, MRM 위원회는 하나의 검토 흐름으로 두 환경을 모두 감독할 수 있다.

소수 의견은 지우지 않는다 — SR 11-7 Effective Challenge 와 맞닿는 지점

두 환경의 구현은 다르지만 공유하는 원칙은 동일하다. 소수 의견(Minority Report)은 식별된 이후 절대 삭제되지 않는다.

채택되지 않은 소수 판정도 log_operation 의 별도 엔트리로 영구 저장된다. 분기마다 MRM 위원회가 검토할 때, “이번 분기에 소수 의견이 붙은 판정은 몇 건인가”, “그중 사후에 소수 의견 쪽이 맞았던 것으로 드러난 케이스가 있는가”, “소수 의견의 reasoning 을 다시 읽어봤을 때 놓친 관점이 보이는가” 가 심사 대상이 된다.

이 설계가 규제적으로 의미 있는 이유는 SR 11-7의 Effective Challenge 요건과 정확히 맞닿기 때문이다. SR 11-7 Pillar 2 는 모델 리스크 관리에 효과적인 도전(effective challenge) 이 조직 안에 존재할 것을 요구한다. 전통적으로 이 요건은 제2선(2nd Line of Defense) 담당자의 독립적인 검토로 충족되어 왔다. AI 기반 감사 시스템으로 이행하면 이 요건이 자칫 “LLM 이 알아서 검증하니까 인간 검증은 줄여도 된다” 는 방향으로 해석될 위험이 있다.

우리 설계는 반대 방향을 택한다. LLM 한 개의 판정을 신뢰하지 않는다. 여러 개의 독립 세션이 서로 다른 관점으로 구조적으로 서로를 challenge 하게 만들고, 그 challenge 의 결과물(소수 의견)을 지우지 않는다. 사람이 할 검증의 일부가 자동화되는 대신, 기계들 사이의 challenge 가 사람이 사후 검토할 기록으로 남는다.

그럼 그 소수 의견은 어디에 저장되고, 나중에 어떻게 찾아오는가. 각 세션이 제출한 reasoning 전문(500–800 토큰)은 임베딩으로 변환되어 LanceDB 케이스 스토어 에 영구 적재된다. 메타데이터로 consensus_type, final_verdict, timestamp, 연관 log_operation 엔트리 포인터가 같이 따라붙는다. 새 WARN/FAIL 판정이 들어오면, 케이스 스토어는 벡터 유사도 기준으로 과거 유사 사례를 끌어올려 현재 판정 컨텍스트에 주입한다 — “이 유형의 이상 신호에 대해 지난 6개월간 α·β·γ 가 어떻게 투표했고, 그중 소수 의견이 사후에 맞았던 비율은 얼마였는가”. 이렇게 해서 현재 판정 이 과거 판정 전체의 누적 을 참고할 수 있게 된다. ConsensusArbiter 가 현재 시점의 3–7개 세션 사이의 견제라면, 케이스 스토어는 그 견제를 시간 축으로 확장 하는 계층이다. MRM 위원회의 분기 검토 자료도 이 케이스 스토어에서 집계된다 — “이번 분기에 minority 로 분류된 판정 중 과거 유사 패턴이 있었는가”, “반복되는 소수 의견 유형이 아키텍처 수준의 재설계 신호인가”.

온프렘 룰 엔진 — LLM 없이도 작동해야 한다

한 가지 더. 이 모든 Ops · Audit · Consensus 구조가 Sonnet 호출이 실패했을 때, 혹은 14B 로컬 모델 가중치가 손상됐을 때 어떻게 되는가 는 규제 관점에서 피할 수 없는 질문이다.

우리의 답은 이원화다. 에이전트의 본질적 판정 기능은 결정론적 Python 룰 엔진만으로 완결되도록 설계했다. 임계값 기반 체크리스트 48개가 룰 엔진 안에 박혀 있고, 이것만으로도 Ops 는 GREEN/YELLOW/RED 를, Audit 는 LOW/MEDIUM/HIGH 를 판정할 수 있다. 재현성 100%, 비용 0, 외부 네트워크 의존성 0.

LLM 합의 계층은 그 위에 편의 계층으로 얹힌다.

Interpret & Discuss (Sonnet) — 룰 엔진이 뱉은 판정을 자연어로 해석하고, 담당자가 “왜 이 판정이냐” 를 물으면 대화로 답한다.
Impact Review (Sonnet) — 설정 변경이 감사 지표에 미칠 영향을 사전 추론.
Deep Audit (Opus, 분기 1회) — 여러 규제 간의 트레이드오프를 길게 따져야 하는 분기 심층 감사.

AWS의 3인 병렬 투표와 온프렘의 2-Round 심의도 이 편의 계층 안에서 돈다. Bedrock 전체가 끊겨도, 로컬 모델이 죽어도, 룰 엔진 판정은 그대로 유지되고 감사 시스템은 완전히 멈추지 않는다. AI 감사자가 보조하되, AI 감사자가 없어도 시스템이 규제 요건을 충족하는 구조다.

규제를 코드 경로로 바꾼다는 것

EU AI Act Article 13(투명성 및 정보 제공)이 요구하는 것 — “고위험 AI 시스템은 이용자가 출력을 해석할 수 있도록 설계되어야 한다.” 종래 대응은 “투명성 문서를 제공합니다” 였다. 우리 구조에서는 log_attribution 엔트리 → 해당 예측에 기여한 피처 랭킹 즉시 조회, log_guardrail 엔트리 → 설명이 Safety Gate 를 어떤 기준으로 통과했는지. Article 13 요구사항의 답은 쿼리 한 번 이다.

Article 14(인간 감독) — 우리 구조에서는 HumanReviewQueue API 엔드포인트, kill switch API, log_operation 의 kill switch 발동 기록이 답이다. 자세한 구조는 Ep 5 에서 다룬다.

Article 15(정확성·견고성·사이버보안) — log_model_inference + log_dimension_change 를 조인하면 “모델 v143 이 언제 어떤 스키마에서 몇 % 정확도를 보였는가” 를 즉석에서 조회 가능. 종래의 “분기 리포트” 를 SQL 한 줄로 대체.

KFCPA §17(금융소비자 분쟁 대응) — 시나리오 첫 문단의 질문이다. log_model_inference + log_attribution + log_data_access 세 테이블의 조인. “2026-04-15 14:37 에 이 고객 ID 에 대해 v143 모델이 어느 피처 조합으로 어떤 상품을 추천했는가” — 15개월 지난 시점에서도 그대로 재구성된다. AuditAgent 의 일일 hash chain 검증이 매일 돌았기 때문에, 그 재구성이 위변조되지 않았음 도 함께 보증된다.

여전히 MRM 위원회의 일

Ep 2 에서 본 패턴이 여기서도 반복된다. 아키텍처가 해결하는 영역이 있고, 여전히 사람의 판단으로 남는 영역이 있다.

아키텍처가 해결하는 영역:

특정 시점의 예측, 결정, 설정 변경 내역의 재구성 가능성
15개월 뒤 감독 당국의 질의에도 답할 수 있는 구조적 보증
단일 LLM 판정의 흔들림을 줄이는 다중 세션 컨센서스 구조
hash chain 위변조 탐지의 지연 상한선(최대 24시간)
Bedrock 또는 로컬 LLM 장애 시에도 작동하는 룰 엔진 폴백

여전히 사람의 몫인 영역:

HMAC 키 교체 주기와 정책은 적절한가?
Ops 와 Audit 의 체크포인트 구성이 현재 규제 환경에 여전히 유효한가? (새 규제 도입 시 체크리스트 확장이 필요할 수 있다)
α·β·γ 페르소나의 prompt 가 특정 편향을 만들지는 않는가? 페르소나 구성 자체가 정기 심사 대상이다.
반복해서 올라오는 소수 의견 패턴이 아키텍처 수준의 재설계 신호는 아닌가?
Bedrock 의존성이 SR 11-7 Pillar 4(거버넌스) 관점에서 제3자 리스크로 적절히 관리되는가?

“컨센서스가 자동으로 돌아가니 위원회 회의는 필요 없다” 는 오해는 여기서도 유효하지 않다. 자동화가 대체한 것은 매일의 반복 검증이며, 검증 구조의 설계와 파라미터 심사는 여전히 위험관리 전문가의 영역으로 남는다. 오히려 소수 의견(Minority Report)이라는 새로운 심사 거리가 하나 더 늘어난 셈이다.

다음 편

Ep 4 는 한국 AI 기본법 §35 의 FRIA(Fundamental Rights Impact Assessment) 가 코드에 어떻게 살아있는지 다룬다. 7-차원 영향평가, 5년 보존 의무, 그리고 왜 EU AI Act Article 9 의 FRIAEvaluator 와 별도 클래스 로 관리되는지 — 법적 기반이 다른 두 체계를 한 코드로 합치는 유혹과 그 위험.

원문 자료: Paper 2 (Zenodo) §6 “규제 매핑”, 구현은 오픈소스 레포.