책임 경로 공학 (RPE) 구현의 현주소 2026-07

이 기사의 요점

책임 경로 공학 (Responsibility Pathway Engineering / RPE)은 AI가 관여하는 행위를 실행 전에 평가하여, allow / hold / human_gate / deny로 분류하는 외부 커널 (External Kernel)이다.

인간이 범위와 해석을 정한 Requirement Pack을 사용하여, 정지 이유, 부족 정보, 인간에게 되돌릴 대상을 기계 판독 가능한(Machine-readable) 형태로 반환한다.

현재는 Python, REST, OpenAPI, MCP, Requirement Pack Governance, Contract Compatibility까지 구현되어 있다. 다음 연구·구현 영역으로는 Lean 4를 통한 형식화, 검증 가능한 AI (Verifiable AI), AI 어슈어런스 (AI Assurance), AI 얼라이먼트 (AI Alignment), 공개 가이드라인과의 연결을 진행한다.

서론

책임 있는 AI나 AI 거버넌스에서는 투명성, 리스크 관리, 인간에 의한 감독, 설명 책임이 주요 논점이 되고 있다.

이러한 노력은 물론 중요하다.

한편, 구현하는 측면에서 보면 아직 의문이 남는다.

• AI의 행위는 실행 전 어디에서 멈추는가
• 판단에 필요한 정보가 부족할 때, 누구에게 되돌리는가
• 나중에 판단 경로를 어떻게 재구성하는가

"인간이 최종 책임을 진다"라는 원칙만으로는 이 경로가 자동으로 생겨나지 않는다.

그래서 나는 AI에게 사회적 책임을 지우는 것이 아니라, AI가 관여하는 행위 속에서 책임을 다룰 수 있는 구조를 도구로서 실현하는 시도로 나아갔다.

구현 장소는 다음 리포지토리이다.

RPE란 무엇인가

RPE는 AI에게 책임을 지우는 메커니즘이 아니다.

AI가 제안, 판단, 실행에 관여할 때, 다음 정보를 기계 판독 가능한 형태로 평가하는 책임 경로를 위한 외부 커널이다.

• 어떤 요구사항이 적용되는가
• 무엇이 부족한가
• 행위를 계속해도 되는가
• 어디에서 멈출 것인가
• 누구에게 판단을 되돌릴 것인가

RPE는 법률이나 가이드라인을 직접 해석하지 않는다.

인간이 출처를 확인하고 적용 범위와 해석을 정한 Requirement Pack을 받아, 제안된 행위를 allow / hold / human_gate / deny 중 하나로 분류한다.

Requirement Pack은 법률, 규격, 가이드라인, 조직 정책 그 자체가 아니다.

인간이 출처, 적용 범위, 해석을 정하여 실행 가능한 제어로 변환한 운용상의 산출물이다.

1. 공개 전에 인간에게 되돌리기

구체적인 예로, AI 에이전트가 공개 리포지토리로의 변경을 제안하는 상황을 생각해보자.

Requirement Pack에 "공개 변경은 인간의 승인을 필요로 한다"라고 정해져 있다면, RPE Kernel은 변경을 실행하지 않고 human_gate와 인간에게 되돌릴 대상을 반환한다.

AI가 공개 변경을 제안
↓
Requirement Pack을 평가
...

RPE가 반환하는 것은 최종 책임의 이전이 아니다.

행위를 어디서 멈추고, 왜 멈추며, 누구에게 되돌리는지를 실행 전에 명시하기 위한 판정 결과이다.

2. 판정 로직을 하나로 모으기

현재의 canonical runtime entry point는 Python 패키지의 evaluate_action()이다.

from rpe_kernel import evaluate_action
result = evaluate_action(action_request, requirement_packs)

REST나 MCP는 이 공통 커널을 호출하는 참조 어댑터 (Reference Adapter)로 배치되어 있다.

Python / REST / MCP
↓
rpe_kernel.evaluate_action()
...

연결 면마다 판정 로직을 가지게 되면, 동일한 입력이라도 Python, REST, MCP가 서로 다른 결론을 내릴 가능성이 있다.

따라서 참조 어댑터는 통신과 입출력 변환으로 한정하며, 판정의 의미를 독자적으로 재구현하지 않는 방침을 세웠다.

판정 결과는 개념적으로 다음과 같은 정보를 반환한다.

{
"decision": "human_gate",
"reason_codes": ["approval_required"],
...

이 JSON은 설명을 위한 간략한 예시이며, 정확한 field와 schema는 리포지토리 상의 contract를 정본으로 한다.

3. Python · REST · OpenAPI · MCP로 확장

현재는 다음과 같은 interface가 있다.

• import 가능한 Python package
• local REST reference adapter
• REST 자체가 반환하는 OpenAPI 3.1 contract
• MCP stdio reference adapter

REST는 평가용 endpoint를 제공하고, MCP는 하나의 bounded tool을 공개한다.

단, 이것들은 운영 환경(production)용 서비스가 아니다.

인증(Authentication), 인가(Authorization), TLS termination, rate limiting, persistence, tenancy isolation, deployment approval 등은 현재의 참조 어댑터(reference adapter)에 포함되어 있지 않다.

최소한의 동작 확인을 위해서는 다음 데모를 사용할 수 있다.

python scripts/demo.py

4. 외부 Pack Loader에 앞서, 유지보수 책임을 설정하기

외부 Pack을 로드하기 전에, 누가 유지보수하고, 언제 검토하며, 어떤 상태일 때 이용 가능한지를 정의할 필요가 있다.

따라서 Loader에 앞서 Requirement Pack Governance를 구현했다.

Lifecycle는 다음과 같이 구성했다.

draft
↓
reviewed
...

Governance record에서는 주로 세 가지 묶음을 다룬다.

• 누가 유지보수하는가: maintenance owner, reviewer, approver
• 무엇을 근거로 어디에 적용하는가: source authority, source version, jurisdiction, scope, interpretation status
• 언제까지 유효하며 무엇으로 대체되었는가: effective date, last review, next review due, ambiguity, supersession, retirement

설계상으로는 만료됨, 유지보수 책임자 불명, 미검토(unreviewed), 또는 중대한 모호함이 남아 있는 Pack을 그대로 평가로 진행해서는 안 된다.

현재는 그 적격성을 판정하는 Governance schema, synthetic example, checker, CI까지 구현되어 있다.

단, 이 Governance 판정은 아직 evaluate_action()의 실행 경로에는 연결되지 않았다. 실행 시의 강제성은 다음 단계에서 구현할 예정이다.

5. 계약(Contract)의 버전을 하나로 통합하지 않은 이유

RPE에는 여러 개의 contract가 있다.

• Action Request
• Gate Decision
• Requirement Pack
• Requirement Pack Governance
• Reason Code Policy

이것들을 프로젝트 전체의 Version만으로 다루면 어떤 interface가 변경되었는지 파악하기 어렵다.

따라서 각 contract에 독립적인 semantic-version baseline을 두었다.

• MAJOR: breaking change
• MINOR: backward-compatible additive change
• PATCH: 의미를 변경하지 않는 수정

unknown version을 추측으로 처리하지 않을 것, deprecated contract에는 migration window를 명시할 것, reason code의 의미를 다른 용도로 재사용하지 않을 것도 규정하고 있다.

단, 실행 시 payload의 모든 곳에 version field를 강제하는 단계까지는 아직 구현하지 않았다.

6. 검증 가능한 AI로 연결하기

RPE는 검증 가능한 AI (Verifiable AI)와 AI 어슈어런스 (AI Assurance)에 구현 측면에서 연결하려는 시도이기도 하다.

여기서 말하는 '검증 가능'이란 AI가 항상 옳다는 것을 증명한다는 의미가 아니다.

요구사항, 판정 규칙, 정지 조건, 이유 코드(reason code), 인간에게로의 반환 경로에 대해 무엇을 전제로 하고 어떤 성질을 확인할 수 있었는지를 재검사 가능한 형태로 나타내는 것을 의미한다.

여기서 말하는 AI 어슈어런스란 AI가 안전하다고 선언하는 것이 아니라, 요구사항, 판단 기록, 증거, 검증 결과를 쌓아 올려 어느 범위까지 신뢰할 수 있는지를 설명 가능하게 만드는 노력을 의미한다.

Lean 4를 이용한 형식화(formalization)를 통해, 선택한 모델 위에서 책임 경로(responsibility path)나 판정 규칙이 의도한 구조적 성질을 만족하는지 기계적으로 검증한다.

단, Lean 4를 통한 증명이 Python 구현 전체, 실제 법적 타당성, 운영상의 적절성, Requirement Pack 내용의 정확성까지 자동으로 보장하는 것은 아니다.

정형화(Formalization)는 증명할 수 있는 범위와 증명하지 않는 범위를 나누어, 검증 가능한 부분을 조금씩 늘려나가기 위해 사용하고 있다.

AI 정렬 (AI Alignment)과의 관계에서도, RPE가 모델 내부의 가치관이나 목적 함수 (Objective Function)를 해결한다고 주장하지는 않는다.

RPE가 다루는 것은 AI의 제안이나 행위를 외부 요구사항, 정지 조건 (Stopping Condition), 인간에게로의 반환 경로로 연결하는 운영상의 정합성이다.

7. AI 사업자 가이드라인을 참조하여 책임 경로를 구체화한다

총무성과 경제산업성의 「AI 사업자 가이드라인 (제1.2판)」 (2026년 3월 31일)은 AI의 개발·제공·이용에 관여하는 사업자가 안전하고 안심할 수 있는 AI 활용을 위해 자율적으로 노력하기 위한 지침을 제시하고 있다.

해당 가이드라인은 법적 구속력을 갖는 규제 그 자체가 아니라, 사업자의 자율적인 노력을 촉진하는 비구속적인 소프트 로 (Soft Law)로서 위치하고 있다.

본고에서는 해당 가이드라인을 일본 내 AI 거버넌스의 주요 공식 지침 중 하나로 참조한다.

RPE가 해당 가이드라인을 자동으로 해석하거나 공식적으로 구현하는 것은 아니다.

인간이 출처, 적용 범위, 해석, 유지보수 책임을 명시하고, 이를 Requirement Pack으로서 기계 판독 가능한 제어로 떨어뜨린다. 그 Pack을 RPE Kernel이 실행 전에 평가한다.

RPE는 해당 가이드라인이 다루는 AI 거버넌스, 책임성 (Accountability), 투명성 등의 논점에 대해, 판단부터 인간에 의한 승인·실행까지의 책임 경로를 구체적으로 기술·검증하기 위한 보완적인 설계 프레임워크로서 검토하고 있다.

따라서 현 시점에서 RPE가 「AI 사업자 가이드라인 준수」나 「적합」을 인정하는 것은 아니며, 리뷰가 완료된 실세계용 Requirement Pack도 아직 제공하고 있지 않다.

8. MIT License로 개방된 공통 구현을 추진한다

RPE는 MIT License로 공개되어 있다.

특정 기업의 내부 자산으로 가두는 것이 아니라, 기업, 행정, 연구 기관, 개발자가 조직을 초월하여 검증, 재사용, 개선할 수 있는 공통 구현으로서 성장시키는 것을 목표로 한다.

여기서 말하는 「표준화」는 RPE가 이미 공적인 표준 규격으로 인정받았다는 의미가 아니다.

공개 사양, 상호 운용성 (Interoperability), 독립 검증 가능성을 갖추고, 향후의 표준화 논의로 연결될 수 있는 구현 기반을 만든다는 방향성을 나타낸다.

책임의 증명을 독점하게 하지 않는다

책임의 증명이나 검증 절차의 기초 부분이 특정 기업, 일국, 또는 단일 인증 주체에 의해 배타적으로 지배되는 것에는 구조적인 리스크가 있다.

책임 경로, 정지 조건, 증거 형식, 인간에게로의 반환 절차가 독점적인 특허나 비공개 사양에 강하게 의존하면 다음과 같은 문제가 발생할 수 있다.

• 조직 간의 상호 운용성이 상실됨
• 특정 벤더나 인증 주체에 대한 의존도가 높아짐
• 도입 비용의 차이가 그대로 책임 증명 능력의 격차로 이어짐
• 제3자에 의한 독립 검증이 어려워짐
• 누가 「충분히 책임을 다했다」고 인정할 수 있는가라는 권한이 집중됨

지식 재산 제도나 특허 제도 자체를 부정하는 것은 아니다.

개별 제품, 알고리즘, 운영상의 노하우가 지식 재산으로서 보호되는 것과, 사회적인 책임 증명의 공통 기반이 배타적으로 지배되는 것은 분리해서 생각할 필요가 있다.

사회 전체에서 이용되는 책임 증명의 기초 부분에 대해서는 공개 사양, 상호 운용성, 복수 구현의 가능성, 독립 검증 가능성을 우선해야 한다고 생각한다.

책임을 증명하는 메커니즘은 책임을 독점하는 메커니즘이 되어서는 안 된다.

RPE가 주장하지 않는 것

현재의 RPE에서는 다음의 경계를 명시하고 있다.

• 기존 SDK나 프로토콜 구현 (Protocol Implementation)을 대체하는 본판 운영용 기반이 아니다
• 현실의 복잡한 제도를 자동으로 해석할 수 있다고 주장하지 않는다
• Requirement Pack에는 지속적인 유지보수 주체와 재검토 경로가 필요하다
• Lean 4 등의 정형화는 선택한 모델 (Model) 상의 구조적 성질을 확인하는 연구 측면이며, Python 런타임 (Runtime)이나 현실의 타당성 전체를 증명하는 것은 아니다
• 인증 (Certification)이나 컴플라이언스 (Compliance) 판정을 자동으로 제공하지 않는다
• 모델 내부의 AI 정렬 (AI Alignment) 문제 전체를 해결하는 것이 아니다
• RPE 자체가 공적인 표준 규격으로 인정받았다고 주장하지 않는다
• AI 사업자 가이드라인의 공식 구현, 준수 인정, 적합 판정을 제공하지 않는다

사정 거리를 한정함으로써 RPE가 무엇을 만들고 있고, 무엇을 만들고 있지 않은지를 명확히 하고 있다.

현재 위치와 미구현 범위

현재 할 수 있는 것

• 하나의 결정론적 결정 커널 (deterministic decision kernel)
• 적용 가능성 해결 (Applicability Resolution) 및 멀티 팩 평가 (Multi-Pack Evaluation)
• Python / REST / OpenAPI / MCP 레퍼런스 인터페이스 (reference interface)
• 인간 반환 경로 (Human Return Route)
• 요구사항 팩 거버넌스 (Requirement Pack Governance)
• 팩 만료 (Pack expiry) 및 유지보수 소유권 (maintenance ownership) 표현
• 계약 버전 매니페스트 (Contract Version Manifest)
• 호환성 (Compatibility) / 지원 중단 (Deprecation) / 마이그레이션 정책 (Migration Policy)
• 스키마 (Schema) / 픽스처 (Fixture) / 체커 (Checker) / CI

아직 할 수 없는 것

• 경계가 지정된 외부 요구사항 팩 로더 (bounded external Requirement Pack Loader)
• evaluate_action()
• 내부에서의 거버넌스 자격 집행 (Governance eligibility enforcement) - 실행 시 페이로드(runtime payload)에 대한 명시적 버전 필드
• 프로덕션 인증 (production authentication) / 인가 (authorization)
• 지속성 (persistence) / 테넌시 (tenancy) / 보존 (retention)
• 자동 동작 실행 (automatic action execution)
• 자동 소스 해석 (automatic source interpretation)
• 검토된 실제 법률 매핑 (reviewed real-world law mapping)
• AI 사업자 가이드라인에 대한 준수·적합의 자동 판정
• Python 런타임 (Python runtime) 전체의 형식 검증
• 공적인 표준 규격 또는 인증 제도로서의 승인

이것은 약점을 나열하기 위함이 아니라, 확인되지 않은 범위까지 구현된 것처럼 보이지 않기 위한 경계이다.

다음 구현 경계

M2 구현

다음은 거버넌스 (Governance)를 문서나 체커 (checker)의 외부에서 실제 실행 시 경계 (runtime boundary)로 연결한다.

• 런타임 요청 (runtime request)과 결과 (result)에서 버전을 명시적으로 다룸
• 거버넌스 자격 (Governance eligibility)을 런타임 경계 (runtime boundary)로 연결
• 외부 요구사항 팩 (Requirement Pack)을 경계 내에서 (bounded) 로드
• 오래된 (stale), 소유자 없는 (ownerless), 모호한 (ambiguous), 중단된 (suspended), 호환되지 않는 (incompatible) 팩을 가시적으로 정지
• 추적 (trace), 증거 (evidence), 복구 (repair), 재개 (resume) 단계로 진행

외부 팩 로더 (Pack Loader)를 먼저 만들지 않은 이유는, 로드할 수 있다는 것보다 로드해도 좋은 상태를 정의하는 것이 우선이라고 판단했기 때문이다.

병행 연구

• 선택한 책임 경로 모델에 대한 Lean 4 형식화 (formalization)
• 검증 대상과 Python 런타임 (Python runtime)과의 대응 범위 명시
• AI 어슈어런스 (AI assurance)에서 이용할 수 있는 증거 (evidence)와 추적 (trace)의 구조
• 공개 가이드라인으로부터 요구사항 팩 (Requirement Pack)을 작성하는 인간 중심의 리뷰 (review) 절차
• AI 사업자 가이드라인과의 대응 관계를 출처와 해석을 동반하여 정리하는 작업

자주 묻는 질문 (FAQ)

Q1. RPE는 AI에게 책임을 지우는 메커니즘인가

아니다. AI가 관여하는 행위를 어디서 멈추고, 왜 멈추며, 누구에게 돌려줄지를 다루는 외부 커널 (kernel)이다. 최종 책임은 인간 또는 조직에 남는다.

Q2. RPE는 법률이나 가이드라인을 자동 해석하는가

하지 않는다. 인간이 출처, 범위, 해석, 유지보수 책임을 정한 요구사항 팩 (Requirement Pack)을 평가한다.

Q3. Lean 4로 RPE 전체의 안전성을 증명할 수 있는가

RPE 전체의 안전성을 하나의 증명으로 보장할 수는 없다.

Lean 4로 증명할 수 있는 것은 명시적으로 형식화한 모델과 전제의 범위 내에서의 성질이다. 예를 들어, 책임 경로를 상태 전이 (state transition)로 정의했을 경우 다음과 같은 성질을 검증 대상으로 삼을 수 있다.

• 동일한 입력과 요구사항 팩 (Requirement Pack)으로부터 서로 다른 판정이 발생하지 않을 것
• 필수 증거가 부족한 상태에서 allow로 진행하지 않을 것
• deny나 human_gate를 필요로 하는 조건이 약한 판정에 의해 덮어쓰여지지 않을 것
• 인간의 승인이 필요한 행위에는 인간에게 반환하는 경로가 존재할 것
• 허가되지 않은 상태 전이가 발생하지 않을 것
• 정의된 불변 조건 (invariant)이 판정이나 상태 전이 전후로 유지될 것

이것들은 "형식화된 책임 경로가 형식화된 규칙을 따르고 있음"을 증명하는 것이다.

한편, Python 구현 전체, 외부 서비스, 네트워크, 의존 라이브러리, 운영 담당자의 행동, Requirement Pack에 기술된 해석의 타당성, 현실의 법률이나 사회에 대한 적절성까지는 그 증명만으로는 보장할 수 없다.

이유는 Lean 4의 증명이 Lean 4 상에 기술된 정의와 전제를 대상으로 하기 때문이다. 현실의 구현이나 운영까지 보장하려면, 형식 모델 (formal model)과 Python 런타임 (runtime)이 대응하고 있는지, 입력 데이터가 전제를 충족하는지, 외부 환경이 예상대로 작동하는지를 별도의 방법으로도 확인해야 한다.

따라서 RPE에서는 "안전함을 일괄적으로 증명하는" 것이 아니라, 증명 대상, 전제, 구현과의 대응 범위를 명시하고, 검증 가능한 성질을 단계적으로 늘려가는 방침을 취한다.

Q4. RPE는 AI 사업자 가이드라인을 준수하고 있는가

현시점에서는 준수를 주장하지 않는다. 해당 가이드라인을 주요 공식 지침 중 하나로 참조하며, 관련 책임·투명성·책무성 (accountability) 논점을 구체화하는 설계 프레임워크 (design framework)로서 검토하고 있다.

Q5. RPE는 표준 규격인가

현시점에서 공적인 표준 규격은 아니다. 기업이나 조직을 넘어 이용할 수 있으며, 향후 표준화로 연결 가능한 공개 사양 (open specification) 및 공통 구현을 목표로 하고 있다.

요약

Responsible AI나 AI 거버넌스 (AI governance)가 인간이나 조직의 책임을 중시하는 것만으로는, 실제 AI 시스템 내에서 책임이 어디를 통과하고, 어디서 멈추며, 누구에게 돌아가는지까지는 결정되지 않는다.

책임 경로 공학 (Responsibility Path Engineering)은 그 사이를 메우기 위한 시도이다.

아직 완성되지 않았다.

그럼에도 불구하고, 작은 판정 데모 (demo)부터 Python, REST, OpenAPI, MCP, Pack Governance, Contract Compatibility를 갖춘 참조 커널 (reference kernel)까지는 나아갈 수 있었다.

향후에는 Lean 4를 통한 형식화 (formalization), 검증 가능한 AI, AI 어슈어런스 (AI assurance), AI 얼라이먼트 (AI alignment), 공개 가이드라인과의 대응 정리를 과장 없이 검증 가능한 범위부터 진행할 것이다.

이 구현은 한 기업의 소유물이나 한 국가의 통제 기반으로 폐쇄되는 것이 아니라, MIT License 아래에서 기업이나 조직을 넘어 검증 및 재사용할 수 있는 공통 구현으로서 키워나갈 것이다.

이번 단계는 완성 선언이 아니라, 설명 가능한 현재 위치이다.

리포지토리:

관련 기사

참고한 AI 거버넌스 맥락

• 총무성·경제산업성 『AI 사업자 가이드라인 (제1.2판)』 2026년 3월 31일
• 해당 가이드라인 본편 PDF
• European Commission: EU AI Act의 규제 프레임워크
• NIST: AI Risk Management Framework
• OECD: OECD AI Principles
• AI agents의 신뢰성과 meaningful human control을 둘러싼 2026년 7월의 움직임

오노 아키히사 (小野 昭久)

• note : https://note.com/dantarg
• LinkedIn : https://www.linkedin.com/in/akihisaono

【주기】

나는 기업에 소속되어 있으나, 본고를 포함한 AI 연구는 직장과는 무관한 개인 활동입니다.

소속을 공표하지 않는 것은 신분을 숨기기 위함이 아닙니다. 이 노력을 특정 기업의 입장이나 소유물로 다루는 것이 아니라, 기업이나 조직을 넘어 검증 및 이용할 수 있는 프레임워크로서 키워나가는 것을 중시하기 때문입니다.

발언 내용과 직장을 혼동하는 것을 피할 목적을 포함하여, 현재의 소속은 공표하지 않고 있습니다.

Discussion