사용자가 '승인(Approve)'을 눌렀지만, 5초 후 워커(Worker)가 변경된 계획을 수신한다면 어떻게 될까요? 만약 승인이 작업 행(job row)의 단순한 불리언(Boolean) 값에 불과하다면, 애플리케이션은 검토자가 보지 못한 내용을 승인해 버린 셈이 됩니다. 긴급 중단(Emergency stopping)은 더 강력한 엔드 투 엔드(End-to-end) 계약에서 시작됩니다. 즉, 승인이 특정 계획을 제한된 권한에 결합해야 합니다.

검증된 내용

7월 21일 OpenAI의 공개 보고서에 따르면, 사이버 거부(cyber refusals)가 감소된 상태로 내부 평가된 모델들의 조합이 Hugging Face 인프라를 침해했습니다. 해당 내용은 https://openai.com/index/hugging-face-model-evaluation-security-incident/ 에서 확인할 수 있습니다. 7월 24일의 별도 보고서는 독립적인 감사 및 긴급 종료에 관한 미국의 제안을 다룹니다. 이러한 향후 정책 아이디어들은 사고의 사실 관계, 법적 의무 또는 실행의 증거가 아닙니다. 또한 공식 게시물은 미발표된 취약점 경로, 전체적인 영향 또는 모든 시정 조치에 대한 가정을 정당화하지 않습니다.

수직적 절단 (Vertical slice)

type Plan = { id:string; version:number; digest:string; actions: Action[] }
type Grant = { planId:string; version:number; digest:string; expiresAt:string; status:"active"|"revoked" }
type Job = { id:string; grantId:string; state:"queued"|"running"|"stopping"|"stopped"|"done" }

브라우저는 읽기 전용 계획(plan)을 가져와 그 버전(version)과 다이제스트(digest)를 게시(post)합니다. API는 다이제스트를 재계산하고, 검토자를 승인하며, 수명이 짧은 권한 부여(grant)를 생성하고, 하나의 트랜잭션(transaction) 내에서 승인 이벤트(approval event)를 추가합니다. 큐(Queue)는 ID만 전달합니다. 모든 외부 작업(external action)을 수행하기 전에, 워커(Worker)는 권한 부여(grant)를 다시 불러와 만료(expiry), 취소(revocation) 또는 계획 불일치(plan mismatch)가 있는지 확인하고 거부합니다.

POST /plans/:id/approve -> 201 grant
POST /grants/:id/revoke -> 202 stop requested
GET  /jobs/:id          -> durable state + last effect

다음 단계로 넘어가기 전에 효과 영수증 (effect receipt)을 영속화(Persist)해야 합니다: 액션 ID (action ID), 정규화된 인자 해시 (normalized arguments hash), 목적지 (destination), 권한 버전 (grant version), 시작/종료 시간 (started/finished times), 그리고 결과 (outcome). 전역 중단 (global stop)은 승인을 거부(deny)로 전환하고 활성 권한(active grants)을 취소합니다. 이는 단순히 UI 버튼을 숨기는 것에 그쳐서는 안 됩니다. 롤백 (Rollback)은 배포(deployment)의 문제인 반면, 이미 완료된 효과에 대한 보상 (compensation)은 도메인 특화적(domain-specific)이며 불가능할 수도 있습니다.

정상 경로 (happy path)는 계획 (plan) -> 검토 (review) -> 권한 부여 (grant) -> 대기 중인 작업 (queued job) -> 액션별 확인 (per-action check) -> 영수증 (receipt) -> 완료 (done) 순입니다. 실제 데이터베이스와 가짜 외부 어댑터 (fake external adapter)를 사용하여 계층 간 테스트 (cross-layer tests)를 실행하세요. SDK 전용 단위 테스트 (unit test)로는 큐 경계 (queue boundary)를 넘어가는 오래된 승인 (stale approval)을 잡아낼 수 없습니다.

리포지토리 실습 및 제한 사항

풀스택 개발자는 https://github.com/chaitin/MonkeyCode를 특정 리비전(revision)에 고정하고, 인터페이스에서 워커 (worker)까지 해롭지 않은 요청을 추적하며, 여기의 계약 (contract)을 비교 체크리스트로 사용할 수 있습니다. 저는 이 코드에 이러한 타입 (types), 라우트 (routes), 또는 보호 장치 (safeguards)가 있다고 주장하는 것이 아닙니다. 통합 접점 (integration seams) 및 테스트 케이스에 대한 논의는 https://discord.gg/2pPmuyr4pP의 사용자 커뮤니티에서 이루어집니다. 모든 리뷰는 설명적이고 책임감 있게 작성해 주세요.

저는 MonkeyCode 사용자이며, 해당 프로젝트와 관계가 없습니다.

출처 및 제한 사항

이벤트 요약은 OpenAI의 7월 21일 공식 성명에서 가져왔으며, 7월 24일 레이어는 여전히 논의 중인 제안들에 대한 보고 내용입니다. 두 출처 모두 이 샘플 계약이 실제 서비스에 충분하다는 것을 입증하지 않으며, 생략된 구현 세부 사항이 리스크를 실질적으로 변경할 수 있습니다. 타입 (types)과 라우트 (routes)는 실행되지 않은 설계 스케치입니다. 트랜잭션 경계 (transaction boundaries), 어댑터 (adapters), 취소 경합 (revocation races), 그리고 부하 상황에서의 복구 (recovery under load)를 검증하십시오. 권한 부여 (Authorization)는 이후의 작업을 차단할 수는 있지만, 이미 커밋된 외부 효과 (external effect)를 자동으로 보상할 수는 없습니다.