문제의 출발점
AI가 계획을 만들고, 코드를 고치고, 스스로 검토한 뒤 완료를 선언하게 할 수는 있어요. 하지만 같은 흐름에 서로 다른 판단이 들어 있어요. 요청을 어떻게 풀지 제안하는 일, 그 행동을 할 권한이 있는지 확인하는 일, 결과가 목표를 만족하는지 판정하는 일은 같은 결정이 아니에요.
VibeMarshal은 이 역할을 사람과 AI, 규칙을 적용하는 Core에 나누어 두어요. AI의 활용 범위를 넓히면서도 승인과 상태 변경의 기준을 따로 관리하려는 설계예요.
사람의 승인과 Core의 선택을 구분하기
| 주체 | 맡는 판단 |
|---|---|
| 사람 | 목표와 완료 조건, 허용 효과 및 운영 정책을 확인하고 실행 승인 |
| AI 역할 | 목표 구조화, 계획 생성·검토, Task 실행과 의미 검사 |
| Core | 후보 admission과 선택, 승인 범위 대조, 상태 기록과 완료 전이 |
현재 Engine에서 사람이 매 후보를 수동으로 고르는 것은 아니에요. 앞 편의 규칙으로 Core가 Plan을 선택하고, EngineApplication.authorize가 사용자 승인 경계를 기록하면서 선택된 Plan을 활성화해요. 사람이 승인하는 대상에는 Goal과 project root, 허용 효과와 정책뿐 아니라 현재 선택한 Plan의 identity·revision·digest도 연결돼요. 승인과 활성화
계산 사례에서는 두 구현 파일 수정과 로컬 검사만 허용했어요. AI가 더 나은 해결 방법이라며 테스트 기대값을 바꾸거나 배포를 추가해도 그 승인으로 실행할 수는 없어요. 목표나 효과를 확대하려면 바뀐 대상에 맞는 승인이 필요해요.
승인 문장을 권한으로 취급하지 않기
설치 CLI의 TrustedConsoleHost는 승인 대상 전체의 target_digest를 표시해요. 대화형 사용자가 같은 값을 입력하면 ApplicationAuthority가 일회성 capability를 발급해요. 대상이 다르거나 비대화형 입력이면 승인 기록 없이 멈추고, Core는 쓰기 직전에도 대상이 같은지 다시 확인해요. 감사용 --source 문자열이나 모델 응답의 승인 문장은 이 경로를 대신하지 않아요. console 승인
Worker에는 승인 capability와 host, Core service나 DB handle을 전달하지 않아요. 역할 실행 중 host로 다시 들어가는 경로도 제한해요. 다만 이 경계는 application 수준이에요. 같은 OS 사용자의 SQLite 직접 쓰기나 적대적인 같은-process 코드까지 막는 sandbox 보장은 아니에요.
승인한 입력이 실행 전에 바뀌는 문제도 있어요. 다른 사람이 파일을 고치거나 지침이 달라질 수 있어요. Engine은 실행 준비와 실제 효과 전에 대상, Context, prompt, model과 정책의 연결을 확인하고, 오래된 입력이면 STALE_EXECUTION_INPUT으로 멈춰요. digest는 어느 입력을 확인했는지 연결하는 값이지 그 내용이 옳다는 증명은 아니에요. 실행 입력 검사, 승인 freshness 검사
실행한 역할과 결과를 받아들이는 역할 나누기
Worker는 활성 Plan의 Task 하나를 수행하고 실제 변경과 실행 결과, evidence 위치를 제출해요. 다음 Task를 선택하거나 Core 원장을 직접 완료로 바꾸지는 않아요. assemble_worker_prompt에도 이 책임이 드러나요. Worker 입력 조립
의미 검사를 맡은 Validator는 별도 실행의 model-review evidence를 제출해요. Core는 해당 Attempt와 RuntimeJob, thread·turn, terminal receipt가 같은 validation과 Task에 연결됐는지 확인해요. 모델 이름을 다르게 썼다는 표기만으로 독립 검사를 인정하지 않아요. 의미 검사 출처 확인
이 출처 검사는 누가 어떤 입력을 검토했는지 추적해요. Validator가 중요한 결함을 모두 발견한다는 보장은 아니에요. 실행과 검사 역할을 분리해도 원자료가 부족하거나 검사 조건이 빠지면 잘못된 판단이 나올 수 있어요.
끝났다는 말 대신 상태 전이 조건 확인하기
provider가 terminal 상태에 도달했다는 사실과 Task 완료도 달라요. Core는 Task가 validating인지, 미확정 실행이나 효과가 없는지, 요구한 모든 validation의 최신 결과가 통과했는지를 확인한 뒤 완료로 바꿔요.
# complete_task의 실제 필수 검사 대조 조건
if set(latest) != expected or any(latest[item] != "pass" for item in expected):
raise EngineServiceError("모든 Task validation의 최신 결과가 PASS여야 합니다.")expected는 계약이 요구한 검사 ID 집합이고 latest는 ID별 최신 상태예요. 과거에 한 번 통과한 결과로 이후 실패나 빠진 검사를 덮을 수 없어요. 그다음 전체 Goal의 수용 조건을 별도로 확인해요. 최신 Task 검사 대조
현재 완료 경로에는 agent-governance-suite 연동도 필요해요. 플러그인 적합성과 실행 관측은 추가 조건이며 Task 검사와 Goal 판정을 대신하지 않아요. 해당 커밋에서는 표준 Codex provider의 model/list 출처가 필수 governance 경로에서 지원되지 않아 GOVERNANCE_PROVIDER_UNSUPPORTED로 막히는 제약이 있어요. 다른 provider로 자동 전환하지도 않아요. 구현 구조를 설명하는 것과 실제 제품에서 끝까지 실행됐음을 입증하는 것을 구분해야 해요. governance 지원 경계, 연동 현황
이 역할 분담에서 AI는 더 많은 일을 제안하고 수행할 수 있어요. 대신 권한과 상태를 바꾸는 조건은 별도로 확인해요. 실행 결과가 실패하거나 응답이 끊겼을 때도 같은 구분이 필요해요. 마지막 편에서는 무엇을 다시 실행하고, 무엇을 먼저 관측하며, 어떤 이전 근거를 사용할지 살펴봐요.