Orbit · 가이드 · Chapter 13
Acceptance Run
운영에 들어가기 전, 궤도가 검증되어야 합니다
데모 화면이 잘 보인다고 운영에 들어가지 않습니다. Field, Dictionary, Authority, Protocol, Trace가 함께 작동하는지 검증한 뒤에야 첫 운영 궤도에 올라갑니다.
읽기 8분 · 마지막 업데이트 2026-04-28
Section 01
한 장면 — 구매팀의 송장 처리가 멈추던 날
개념을 먼저 풀기 전에 한 장면부터 봅니다. 중견 제조사의 구매팀이 Orbit을 도입하고, 다음 주 월요일부터 실제 송장 처리에 쓰기로 했습니다.
설정 완료. Field 정의에 "3자 대사"가 포함되어 있다. 현우는 실제로는 2자 대사만 쓴다.
Dictionary에 "단가 차이"가 등록되지 않았다. Agent가 단가 불일치 건을 설명하지 못한다.
Authority에 팀장 승인 lane이 빠져 있다. 500만 원 이상 건이 자동으로 넘어간다.
Protocol 경계가 "조회만 허용"인데 Agent가 ERP에 write-back을 시도한다.
팀장이 묻는다. "이거 다음 주에 바로 쓸 수 있는 거 맞아?"
11:15의 질문이 핵심입니다. Acceptance Run 없이 운영에 들어간 회사라면 이 다섯 가지 문제가 월요일 아침, 실제 송장 위에서 터집니다. 담당자는 시스템을 의심하고 다시 엑셀로 돌아갑니다.
Acceptance Run을 거친 회사라면 금요일 오후에 이미 알고 있습니다:
Acceptance Run이 잡은 것은 코드 버그가 아닙니다. Field 정의와 실제 업무 사이의 불일치입니다. 소프트웨어 테스트가 코드가 올바른지 묻는다면, Acceptance Run은 궤도가 현실에 맞는지 묻습니다.
Section 02
Acceptance Run이 무엇인가
Acceptance Run은 Orbit이 실제 운영에 들어가기 전 통과해야 하는 구조화된 검증 프로세스입니다. Field, Dictionary, Authority, Protocol, Trace 다섯 개 층이 실제 데이터 위에서 올바르게 작동하는지를 확인합니다.
핵심 구분: Acceptance Run은 데모가 아닙니다. 데모는 "이렇게 될 수 있다"를 보여주고, Acceptance Run은 "이렇게 되고 있다"를 증명합니다. 데모는 선택된 시나리오를 보여주지만, Acceptance Run은 실제 데이터를 흘려서 어디가 깨지는지 찾습니다.
| 구분 | 데모 | Acceptance Run |
|---|---|---|
| 데이터 | 준비된 샘플 | 실제 운영 데이터 (read-only) |
| 목적 | 가능성 확인 | 운영 준비 상태 검증 |
| 결과 | "잘 되네요" | 통과/미통과 + 근거 |
| 시점 | 도입 초기 | 운영 직전 · 정의 변경 시 |
| 판단자 | 영업팀 | 운영 담당자 + 시스템 |
비행기 비유. 항공기는 조립이 끝나면 바로 승객을 태우지 않습니다. 지상 시험 → 무인 택싱 → 시험 비행 → 인증을 거칩니다. Acceptance Run은 Orbit의 시험 비행입니다. 궤도가 실제로 돌아가는지, 어디서 흔들리는지를 운영 전에 알아냅니다.
Acceptance Run이 필요한 시점은 세 가지입니다:
최초 도입
Orbit을 처음 도입할 때. Field 정의, Dictionary, Authority가 처음 설정된 상태에서 실제 업무 데이터를 흘려봅니다.
정의 변경 후
Field 정의가 v2에서 v3으로 바뀌거나 Authority에 새 승인 lane이 추가되었을 때. 변경이 기존 흐름을 깨지 않는지 확인합니다.
주기적 재검증
업무 환경은 바뀝니다. 새 거래처, 새 규정, 새 팀원. 분기마다 한 번, 현재 정의가 현실과 여전히 맞는지 확인합니다.
Section 03
다섯 개 층의 검증 대상
Acceptance Run은 Orbit의 다섯 개 핵심 층을 각각 검증합니다. 한 층이라도 통과하지 못하면 전체 Run은 미통과입니다. 부분 통과란 없습니다.
| 검증 층 | 묻는 질문 | 미통과 시 증상 |
|---|---|---|
| Field | 정의된 그래프가 실제 업무 흐름을 반영하는가? | 단계가 실제와 맞지 않아 상태가 멈춤 |
| Dictionary | 업무에서 쓰는 모든 용어가 정의되어 있는가? | Agent가 용어를 이해하지 못함 |
| Authority | 승인 lane이 빠짐없이 설정되어 있는가? | 승인 없이 결정이 넘어감 |
| Protocol | AI의 실행 경계가 적절히 설정되어 있는가? | Agent가 허용 범위를 넘어 행동 |
| Trace | 모든 결정이 근거와 함께 재현 가능한가? | "왜 이렇게 됐지?"에 답할 수 없음 |
Field 정확도 — 그래프가 현실과 맞는가
가장 큰 비중을 차지하는 검증입니다. Field 정의에 "3자 대사" 단계가 있는데 실제로는 "2자 대사"만 쓴다면, 그 단계는 영원히 완료되지 않습니다. 반대로 실제로 존재하는 "세무 검토" 단계가 정의에 빠져 있으면, 해당 업무가 Trace에 남지 않습니다.
실제 송장 48건을 Field에 흘린다. 42건이 정의된 경로를 따라간다.
6건이 "3자 대사" 단계에서 막힌다. 실제로는 2자 대사를 쓰는 건이다.
3건에서 "긴급 승인" 경로가 발생하지만 Field에 정의되지 않았다.
Field 적합도 87.5% (42/48). 미통과. 2자 대사 경로 추가, 긴급 승인 lane 정의 필요.
Dictionary 커버리지 — 빠진 용어가 없는가
Agent가 업무를 지원하려면 해당 업무에서 쓰는 용어를 알아야 합니다. "단가 차이", "대사 불일치", "미수금 상계" 같은 용어가 Dictionary에 없으면, Agent는 해당 개념을 다룰 때 엉뚱한 답을 내놓거나 침묵합니다.
Authority · Protocol · Trace
나머지 세 층은 Trust Loop의 완성도를 검증합니다. Authority에 빠진 승인 lane이 있으면 결정이 무허가로 넘어갑니다. Protocol 경계가 느슨하면 Agent가 허용 범위 밖의 행동을 합니다. Trace가 불완전하면 사후에 "왜 이렇게 결정되었는가"를 재현할 수 없습니다.
다섯 층은 독립이 아닙니다. Field가 틀리면 Authority 검증도 의미가 없습니다 — 잘못된 단계에서의 승인 lane은 올바를 수 없으니까요. 그래서 Acceptance Run은 Field부터 검증하고, Field가 통과해야 나머지 층으로 넘어갑니다.
Section 04
합격 기준 — 무엇으로 판단하는가
"느낌적으로 괜찮다"는 합격이 아닙니다. Acceptance Run은 네 가지 축으로 합격 여부를 측정합니다. 각 축은 수치화 가능한 기준이며, 하나라도 기준 이하이면 Run은 미통과입니다.
| 축 | 정의 | 합격 조건 |
|---|---|---|
| Precision | 관련 없는 이벤트가 Field에 잘못 붙지 않는가 | 오탐 비율 < 임계값 |
| Recall | 실제로 발생한 이벤트가 빠짐없이 잡히는가 | 미탐 비율 < 임계값 |
| Traceability | 모든 결정에 근거가 연결되어 있는가 | 근거 없는 결정 = 0 |
| Latency | Field 상태가 SLA 안에 갱신되는가 | 갱신 지연 < 허용 SLA |
Precision — 맞지 않는 것이 섞이지 않는가
계약 검토 Field에 HR 관련 문서가 붙는다면, 담당자는 매번 "이건 왜 여기 있지?"라고 쳐내야 합니다. Precision이 낮으면 Field는 정보 정리 도구가 아니라 또 다른 잡음 소스가 됩니다.
Recall — 실제로 일어난 것을 놓치지 않는가
송장 100건 중 95건만 Field에 잡힌다면, 빠진 5건은 어디로 갔는가. 담당자는 Field를 믿지 못하고 ERP를 다시 열게 됩니다. Recall이 낮으면 Field는 보조 참고 자료로 전락합니다.
Traceability — 근거 없는 결정은 허용하지 않는다
Agent가 "이 송장은 승인 대상"이라고 판단했다면, 그 판단의 근거가 Trace에 있어야 합니다. 근거 없는 결정이 하나라도 있으면 Traceability는 미통과입니다. 이 축은 부분 통과가 없습니다 — 100%이거나 아닙니다.
Latency — 상태가 제때 반영되는가
ERP에서 송장이 승인되었는데 Field 상태가 30분 뒤에야 바뀐다면, 담당자는 이미 직접 확인하고 넘어간 뒤입니다. 상태 갱신이 SLA 안에 이루어지지 않으면 Field는 실시간 도구가 아니라 일일 보고서 수준이 됩니다.
네 축 중 하나만 낮아도 미통과. Precision이 높아도 Recall이 낮으면, "깔끔하지만 절반만 보여주는" Field가 됩니다. 네 축의 균형이 운영 신뢰의 최소 조건입니다.
Section 05
Run의 구조 — Connect에서 Accept까지
Acceptance Run은 다섯 단계로 구성됩니다. 각 단계는 이전 단계의 결과에 의존합니다. 중간 단계에서 실패하면 그 이후 단계는 실행되지 않습니다.
Connect — 읽기 전용 데이터 연결
실제 시스템(ERP, 문서함, 승인 시스템)에 읽기 전용으로 연결합니다. 쓰기는 절대 하지 않습니다. 이 단계에서 데이터 접근 가능 여부, 포맷 호환성, 연결 지연을 확인합니다.
Scene — 하나의 업무 흐름 선택
전체 업무를 한꺼번에 검증하지 않습니다. 하나의 구체적 업무 흐름을 고릅니다. "국내 원재료 구매 → 송장 접수 → 3자 대사 → 팀장 승인" 같은 실제 시나리오 하나. Scene이 좁을수록 검증이 명확합니다.
Execute — 전체 사이클 실행
선택한 Scene을 실제 데이터로 처음부터 끝까지 돌립니다. Field에 이벤트가 들어오고, Dictionary가 해석하고, Agent가 판단하고, Authority가 승인을 거치고, 결과가 Trace에 남습니다.
Evaluate — 기준 대비 측정
실행 결과를 네 축(Precision, Recall, Traceability, Latency)으로 측정합니다. 각 축의 수치와 구체적 미달 항목이 리포트에 남습니다.
Accept / Retry — 판정
네 축 모두 기준을 충족하면 Accept. 하나라도 미달이면 미달 원인을 수정하고 Retry. Retry는 Connect부터 다시 시작하지 않습니다 — 수정된 층만 재검증합니다.
Field 정확도 미달 (87.5%). 2자 대사 경로 누락, 긴급 승인 lane 부재.
Field 정의 v3으로 업데이트. 2자 대사 분기 추가. Authority에 긴급 승인 lane 추가.
Field 통과. Dictionary 미달 — "단가 차이" 미등록.
Dictionary에 단가 차이, 대사 불일치, 미수금 상계 용어 등록.
전 축 통과. Accept. 운영 시작 승인.
Retry는 실패가 아닙니다. Retry는 정의를 현실에 맞추는 과정입니다. Run #1에서 모든 것이 통과하는 경우는 거의 없습니다. 보통 2~4회의 Retry를 거치며, 이 과정 자체가 조직이 자기 업무를 정확히 이해하게 만드는 학습입니다.
Section 06
Acceptance Run이 연결하는 것들
Acceptance Run은 독립적인 기능이 아닙니다. Orbit의 다른 구성 요소들을 "운영 준비 완료"라는 하나의 기준선 위에 정렬시키는 역할을 합니다.
| 연결 대상 | 관계 | 없으면 |
|---|---|---|
| Field | 검증의 최우선 대상. Field가 틀리면 나머지도 의미 없음 | 정의와 현실이 어긋난 채 운영 시작 |
| Dictionary | Agent가 업무 용어를 이해하는지 확인 | 용어 누락으로 Agent 오답 발생 |
| Authority | 승인 lane 완비 여부 확인 | 무허가 결정이 운영에 노출 |
| Protocol | AI 실행 경계의 적절성 확인 | Agent가 허용 범위를 넘어 행동 |
| Trace | 결정 재현 가능성 확인 | 사후 감사 불가 |
| 6주 Pilot | Pilot 종료 시 Acceptance Run이 최종 gate | Pilot 결과를 객관적으로 판단 불가 |
Pilot과의 관계
6주 Pilot은 Acceptance Run으로 시작하고 Acceptance Run으로 끝납니다. 시작 시점의 Run은 초기 설정의 검증이고, 종료 시점의 Run은 6주간의 조정이 충분했는지의 최종 판정입니다.
Pilot 종료 후 남는 Acceptance Summary는 영업 문서가 아닙니다. 운영 시작 여부를 판단하는 근거입니다. 어떤 축이 통과했고, 어떤 부분을 Production 전에 보완해야 하는지가 수치와 함께 남습니다.
왜 상세 체크리스트를 공개하지 않는가. Acceptance Run의 원리와 구조는 공개합니다. 하지만 내부 검증 항목의 전체 목록과 순서는 도입 playbook에 해당하므로 비공개입니다. 이 페이지에서 설명하는 것은 "왜 검증이 필요한가"와 "무엇을 기준으로 판단하는가"입니다.