CONTEXT
AI가 운영 요청을 구조화할 수 있어도 곧바로 외부 작업을 실행하면 근거 누락, 잘못된 수정본 승인과 중복 실행을 통제하기 어렵습니다. AI Control Room은 합성 요청을 사람이 검토하고 승인한 뒤에만 Mock 작업으로 넘기는 공개 데모입니다.
핵심은 자동화의 속도가 아니라 누가 어떤 근거와 수정본을 승인했는지 추적하고, 실행 결과를 확신할 수 없을 때 안전하게 멈추는 것입니다. 실제 ERP·이메일·캘린더·고객 데이터에는 연결하지 않았습니다.
CONTRIBUTION
- 합성 이메일과 PDF 근거, 신뢰도와 누락 정보를 한 화면에서 비교하는 검토 인박스를 구현했습니다.
- 수정본 revision에 결속되는 승인과 고위험 요청의 서로 다른 2인 승인 규칙을 상태 전이로 구성했습니다.
- idempotency key, append-only 이력과 outcome_unknown 조정·제한 재시도 흐름을 구현했습니다.
- 공개 환경을 Fixture/Mock-only로 고정하고 실제 외부 시스템 호출이 발생하지 않는 경계를 문서화했습니다.
DECISIONS
판단 근거를 승인 버튼보다 먼저 배치
- 이유
- 요약된 제안만 보면 AI가 어떤 문장과 첨부를 근거로 삼았는지, 무엇을 찾지 못했는지 확인하기 어려웠습니다.
- 구현
- 원문과 PDF 인용, 필드별 신뢰도, 누락 정보와 제안 액션을 같은 검토 화면에서 교차 확인하도록 구성했습니다.
- 영향
- 승인자는 실행 여부를 결정하기 전에 근거의 위치와 빈칸을 직접 확인할 수 있습니다.
승인을 사람뿐 아니라 수정본에 결속
- 이유
- 승인 뒤 카드나 액션이 바뀌어도 기존 승인이 남으면 검토하지 않은 내용이 실행될 수 있었습니다.
- 구현
- 승인에 caseVersion과 revision hash를 기록하고, 수정 시 기존 승인을 분리했습니다. 고위험 요청은 동일인이 중복 승인할 수 없는 2인 규칙을 적용했습니다.
- 영향
- 데모 상태 모델 안에서 검토한 revision과 실행 대상을 일치시키고, 변경된 요청은 다시 사람의 판단을 거치게 했습니다.
결과를 모르면 재실행하지 않고 조정
- 이유
- 타임아웃이 실패를 의미하지 않을 수 있어 즉시 재시도하면 같은 메일이나 작업이 중복 실행될 위험이 있었습니다.
- 구현
- outcome_unknown을 독립 상태로 두고 먼저 reconcile했습니다. not_executed가 확인된 경우에만 같은 idempotency key로 제한 재시도하도록 했습니다.
- 영향
- Fixture/Mock 흐름에서 결과가 불확실하면 즉시 재실행하지 않고 reconcile 단계로 보내도록 했습니다.
RESULT / EVIDENCE
핵심 검토·승인·복구 흐름을 공개 데모로 구현했습니다. 실제 ERP·외부 시스템·고객 데이터는 연결하지 않았습니다.
- 근거 검토, 수정 후 재승인, 고위험 2인 승인과 실행 결과 조정 흐름을 하나의 데모 시나리오로 연결했습니다.
- Playwright 시나리오로 대표 상태 전이와 승인·복구 경계를 확인했습니다.
- 모든 공개 요청과 실행 결과는 고정 Fixture와 Mock adapter를 사용합니다.
CURRENT LIMITATIONS
- PostgreSQL/Docker 통합 경로는 현재 환경에서 완전히 검증되지 않았습니다.
- 실제 ERP·이메일·캘린더·LLM 또는 고객 데이터와의 통합 성과를 주장하지 않습니다.
- 공개 데모에서는 Fixture/Mock-only 경계를 유지하며 실제 외부 작업을 실행할 수 없습니다.