그래서, 이 Runtime. 내부에서는 무엇을 하고 있는가

전편에서는 Responsibility Pathway Runtime (RPR)을 만들고, 처음으로 PyPI에 공개한 이야기를 썼습니다.

이번에는 그 내용입니다.

"AI 거버넌스를 Runtime으로 만들었다"라고 해도, 무엇이 움직이고 있는지 알기 어렵지요.

그래서 Human Gate, 결과 불명, 대조, 복구, 재개라는 흐름에 따라 RPR이 무엇을 하고 있는지 살펴보겠습니다.

먼저 테스트만 해보려면, 이것으로 설치합니다.

python -m pip install responsibility-pathway-runtime
rpr --help

특정 버전을 지정하려면, 이것입니다.

python -m pip install responsibility-pathway-runtime==0.1.0a2

첫 PyPI입니다. 제대로 설치됩니다 (웃음)

어떤 때에 필요해지는가

AI에게 문장을 쓰게 하는 것뿐이라면, 실패해도 다시 쓸 수 있습니다.

하지만 파일을 수정하거나, API로 POST를 하거나, 메시지를 보내거나, 리포지토리나 업무 시스템을 업데이트하게 되면 이야기가 달라집니다.

인간의 확인 전에 실행해서는 안 된다.

통신이 끊겼다고 해서 바로 재전송해서는 안 된다.

함수가 반환되었다는 것만으로 완료 처리해서는 안 된다.

일부만 진행된 처리는 통상적인 실행과는 별도로 복구해야 한다.

RPR은 이러한 외부 조작의 전후로 책임이 끊기지 않도록 상태, 권한, 증거, 재개 경로를 연결합니다.

RPR의 담당 범위

RPR은 AI의 답변 내용이 옳은지, 업무 판단이 타당한지, 법령에 적합한지를 판정하는 제품이 아닙니다.

그 부분은 RPE나 도입 측의 규칙, 인간이나 조직의 판단 영역입니다.

RPR이 다루는 것은,

그 판단을 어떤 상태, 권한, 증거, 재개 경로로 실행할 것인가

입니다.

AI / planner / agent framework
↓
실행 후보 조작
...

Human Gate는 "확인 버튼"이 아니다

프롬프트에 "중요한 변경은 인간에게 확인해 주세요"라고 쓰는 것만으로는 실행 경로의 통제가 되지 않습니다.

확인하지 않아도 툴을 호출할 수 있다면, AI는 외부 조작을 시작할 수 있습니다.

RPR에서는 Human Gate가 필요한 경우, 외부 조작 자체를 시작하지 않습니다.

실행 후보
↓
요건 평가
...

Human Gate는 화면에 버튼을 두는 이야기가 아닙니다.

"외부 조작을 시작할 수 없는 상태"와 "그 상태를 해제할 수 있는 권한"을 갖는 것입니다.

승인 후에 전제가 바뀌면, 동일한 승인을 그대로 사용하지 않고 재평가합니다.

callback이 반환되었다. 그러므로 성공……이 아니다

함수가 정상 종료된 것과 외부의 상태가 기대대로 변한 것은 별개입니다.

API가 200을 반환해도, 대상 데이터가 저장되지 않았을 수도 있습니다.

파일을 다 썼어도, 기대한 내용을 다시 읽어올 수 없을지도 모릅니다.

A callback is not proof of an external effect.

RPR은 완료의 근거로서 외부 상태의 readback을 다룹니다.

"처리는 반환되었다. 좋아!" 하고 끝내지 않는 것입니다 (웃음)

성공했는지 모를 때, 바로 재전송하지 않는다

외부 시스템으로 쓰기 요청을 보낸 직후에 통신이 끊겼다.

클라이언트 측에서는 실패로 보입니다.

하지만 외부 측에서는 이미 처리가 완료되었을지도 모릅니다.

여기서 자동 재시도를 하면 이중 등록, 이중 전송, 이중 결제, 이중 업데이트로 이어집니다.

RPR은 이 상태를 결과 불명 (write_status_unknown) 으로 저장합니다.

running
↓
write_status_unknown
...

모른다면, 모르는 상태로 멈춘다.

사소해 보이지만, 이 부분이 상당히 중요합니다.

복구와 재개는 '재실행 버튼'이 아니다

이상(Anomaly)이 발생한 후, 원래의 조작을 다시 실행한다고 해서 반드시 해결되는 것은 아닙니다.

일부만 성공했다면, 동일한 조작을 반복하는 것은 위험합니다.

전제 조건이나 권한이 바뀌었을 수도 있습니다.

RPR에서는 통상적인 실행(Normal Execution)과 복구(Repair)를 분리합니다.

프로세스를 재시작할 수 있는 것과, 안전하게 재개할 수 있는 것은 별개의 문제입니다.

권한, 전제 조건, 증거, 남은 영향을 재평가하고, 책임 경로(Responsibility Pathway)를 다시 연결할 수 있을 때 재개합니다.

되돌릴 수 없는 영향은 누군가가 책임진다

되돌릴 수 없는 조작이나 부분 완료 상태에서는, 단순히 '되돌리기(Rollback)'만으로 끝나지 않습니다.

영향이 남는다면, 누가 이를 감시하고, 설명하며, 다음 판단을 맡을지를 남겨두어야 합니다.

RPR은 복구 담당자, 인간으로의 귀환점(Return Point), 잔여 담당자가 불명확한 상태로 자율적으로 지속하지 않습니다.

이는 법적 책임을 자동으로 결정하는 메커니즘이 아닙니다.

운용상 판단과 감시를 돌려줄 대상을 잃지 않기 위한 런타임(Runtime) 구조입니다.

Lean 4에서는 무엇을 검사하는가

RPR에는 Python Runtime, JSON 상태 머신(State Machine), Lean 4 형식 모델(Formal Model)이 포함되어 있습니다.

Lean 4로 검사하는 것은 공개된 상태 전이(State Transition)와, 그로부터 선택한 불변 조건(Invariant)입니다.

Lean 4를 사용한다고 해서 현실 세계의 안전성까지 모두 증명되었다는 뜻은 아닙니다.

어디까지 형식화(Formalization)할 것인지, 어디서부터는 도입 환경이나 인간의 판단 영역인지, 그 경계를 공개하고 있습니다.

브라우저 데모에서는 무엇이 작동하는가

공개 데모는 단순히 상태 전이만을 보여주는 모크(Mock)가 아닙니다.

GitHub Actions가 생성한 RPR의 wheel 파일을 브라우저 내의 Python 환경(Pyodide)으로 로드합니다.

브라우저 내부에서는 실제 ResponsibilityPathwayRuntime이 작동하며, SQLite 저장, 실행 이력, 결과 불명 처리, 재시작 후 읽기, 외부 상태와의 대조, 증거 체인(Evidence Chain)이 실행됩니다.

Human Gate
↓
외부 서비스로 1회만 실행
...

모의(Simulate)하고 있는 것은 외부 서비스뿐이며, RPR 본체는 실제 구현체입니다.

어디까지 검증되었는가

RPR은 MIT License 기반의 Public Alpha 버전입니다.

특정 용도에 대한 적합성, 본방 운용의 안전성, 법령 준수, 외부 서비스의 정확성을 보장하지 않습니다.

도입 측에서는 대상 조작, 권한 경계, 증거, 외부 상태 확인 방법, 복구, 재개, 남은 영향을 자신의 환경에 맞춰 정의해야 합니다.

우선 직접 사용해 보세요

로컬에 설치하려면 PyPI를 이용하세요.

python -m pip install responsibility-pathway-runtime
rpr --help

설치 없이 분위기를 보고 싶다면 브라우저 데모를 이용하세요.

처음 만든 Runtime을 처음으로 PyPI에 출시했습니다.

아직 Public Alpha 단계이지만, 문서로만 생각하던 책임 경로가 실제로 멈추고, 저장하고, 확인하고, 복구하고, 재개하는 단계까지 도달했습니다.

직접 만져보시고, "이 부분은 이해하기 어렵다", "이 상황에서도 사용할 수 있지 않을까", "이 설계는 위험하지 않을까"와 같은 피드백을 주신다면 기쁘겠습니다.

만든 사람은 무척 기뻐할 것입니다 (웃음)

Discussion