목록에는 일이 보이고, 상태차트에는 현재가 보인다
“AI가 초안을 쓴다 → 편집자가 검토한다 → 게시한다”는 목록은 일이 진행되는 순서를 알려 줍니다. 그러나 편집자가 출처 오류를 찾았을 때 원고가 어디로 돌아가는지, 수정한 뒤 자동으로 게시되는지 다시 승인을 받아야 하는지는 보이지 않습니다. 상태차트에서는 원고가 일정 시간 머무를 수 있는 상태를 상자로, 상태를 바꾸는 사건을 화살표에 적습니다. ‘검토 대기’인 원고는 검토가 시작될 때까지 그대로 존재하고, ‘수정 중’인 원고는 수정 완료 사건이 생길 때까지 그 상태에 머뭅니다.[1]
오류 발견 뒤의 경로와 현재 위치를 알기 어렵습니다.
상태, 사건, 조건, 행동을 한 줄에 섞지 않는다
기본 표기는 네 가지면 충분합니다. 둥근 상자는 상태, 화살표는 전환, 화살표 위의 말은 전환을 일으키는 사건입니다. 조건은 대괄호로 적어 사건이 일어나도 이동해도 되는지 가립니다. 필요하면 빗금 뒤에 전환과 함께 수행할 행동을 적습니다. 예를 들어 “검토 완료 [출처 확인됨] / 승인 기록 저장”은 검토 완료라는 사건이 왔고 출처 확인 조건이 참일 때 게시 가능으로 이동하면서 승인 기록을 남긴다는 뜻입니다. W3C SCXML도 활성 상태에서 사건이 오면 정의된 전환과 조건을 검사하는 구조로 설명합니다.[1]
[출처 확인됨]
/ 승인 기록 저장→게시 가능다음 상태
동사는 곧바로 상태가 되지 않는다
원문이 “AI가 초안을 만들면 편집자가 사실을 확인한다. 오류가 있으면 수정 요청하고, 오류가 없으면 책임자가 승인한다. 승인된 원고만 게시한다”라고 합시다. 먼저 오래 머무를 수 있는 말을 찾으면 ‘작성 중·검토 대기·수정 중·승인 대기·게시 가능’이 나옵니다. ‘확인한다·요청한다·승인한다’는 대개 사건이나 행동입니다. 그리고 “승인된 원고만”은 게시 가능으로 가는 문을 잠그는 조건입니다. 모든 동사를 상자로 만들면 순간적인 사건과 지속되는 상태가 뒤섞입니다.
| 원문 표현 | 역할 | 도표 표기 |
|---|---|---|
| AI가 초안을 만든다 | 행동과 완료 사건 | 초안 생성 완료 |
| 편집자가 사실을 확인한다 | 진행 상태 | 검토 중 |
| 오류가 있으면 | 전환 조건 | [오류 있음] |
| 승인된 원고만 게시 | 필수 조건 | [책임자 승인됨] |
편집 원고의 정상 경로와 되돌림을 함께 그린다
정상 경로만 그리면 상태차트가 장식이 됩니다. 검토에서 오류가 발견되면 수정 중으로 가고, 수정 완료 후에는 승인 대기가 아니라 다시 검토 대기로 보내야 합니다. 수정이 출처 오류를 실제로 해결했는지 재확인해야 하기 때문입니다. 또 게시 가능에서 원문이 바뀌면 승인 효력이 사라지므로 검토 대기로 돌아가게 할 수 있습니다. 이 경로가 없으면 예전에 승인된 원고를 고친 뒤 확인 없이 게시하는 빈틈이 생깁니다.
| 작성 중 | 초안 생성 완료 | 검토 대기 |
| 검토 대기 | 오류 발견 | 수정 중 |
| 수정 중 | 수정 완료 | 검토 대기 |
| 검토 대기 | 승인 [출처·권리 확인] | 게시 가능 |
검색 도구와 사람 승인은 서로 다른 상태를 만든다
LLM이 검색 도구를 쓰는 시스템에서는 ‘검색 요청됨·결과 수신·근거 연결됨·답변 준비됨’처럼 시스템의 상태를 그릴 수 있습니다. 검색 실패는 곧바로 답변 완료가 아니라 재시도 대기나 사람 확인으로 보내야 합니다. 사람 승인을 기다리는 작업이라면 ‘승인 대기’가 별도 상태가 됩니다. 요청을 보냈다는 사실과 승인을 받았다는 사실은 다르며, 승인 대기 상태에서는 게시 동작이 일어나지 않아야 합니다. 같은 상태차트 문법을 쓰더라도 대상이 원고인지, 검색 실행인지, 승인 요청인지 먼저 제목에 밝혀야 합니다.
원문과 금지할 추정을 함께 준다
LLM에 “상태도를 그려 줘”라고만 요청하면 원문에 없는 자동 승인, 시간 제한, 담당자 규칙이 생기기 쉽습니다. 대상, 상태 후보, 사건, 조건, 빠뜨리지 말아야 할 예외, 출력 형식을 구체적으로 줍니다. 그리고 확실하지 않은 정보는 새 상태를 만들지 말고 ‘확인 필요’ 목록에 남기라고 요구합니다. 아래 요청문은 특정 서비스의 실행 결과가 아니라 독자가 그대로 고쳐 쓸 수 있도록 만든 예시입니다.
다음 원문을 ‘원고 한 건’의 상태차트로 바꿔 주세요. 목적: 승인 전 게시를 막고, 수정 뒤 재검토 경로를 확인한다. 원문: AI가 초안을 만들면 편집자가 출처와 수치를 검토한다. 오류가 있으면 수정하고 다시 검토한다. 책임자가 승인한 원고만 게시할 수 있다. 승인 뒤 원문이 바뀌면 다시 검토한다. 표시: 상태는 명사형 상자, 전환은 ‘사건 [조건] / 행동’ 형식. 반드시 포함: 시작·종료, 오류 발견, 수정 완료, 승인, 승인 뒤 변경. 금지: 원문에 없는 자동 승인·기한·담당자를 추정하지 말 것. 출력: ① 상태 목록 ② 전환표 ③ Mermaid 초안 ④ 확인이 필요한 모호한 점.
상태 이름보다 들어오고 나가는 길을 검사한다
좋은 상태 이름도 연결이 틀리면 쓸 수 없습니다. 먼저 시작점에서 모든 정상 상태에 도달할 수 있는지 살핍니다. 다음으로 종료 상태까지 갈 수 없는 막힌 상태가 있는지, 승인 조건을 건너뛰는 화살표가 있는지 봅니다. 특히 ‘수정 완료 → 게시 가능’은 자연스럽게 보이지만 재검토를 빠뜨린 오류입니다. 또 ‘검토 실패’처럼 사건과 결과가 섞인 말보다 ‘오류 발견 [중대]’처럼 관찰된 사건과 조건을 나누어 적는 편이 검증하기 쉽습니다.
전환표를 한 줄씩 실행해 본다
상태차트를 실제 운영 규칙으로 쓰려면 그림과 별도로 전환표를 만듭니다. 각 줄의 현재 상태에서 사건이 왔을 때 조건이 참이면 다음 상태로 갈 수 있어야 합니다. 조건이 거짓일 때의 처리도 정합니다. “승인 버튼을 눌렀지만 출처 확인이 끝나지 않았다”면 상태를 유지하고 무엇이 부족한지 알려야 합니다. 존재하지 않는 상태에서 온 사건은 무시할지 오류로 기록할지도 필요합니다. 이 표는 개발자에게는 구현 규칙, 편집자에게는 검수표가 됩니다.
사건과 조건을 바꾸며 다음 상태를 예측해 보자
현재 상태와 사건을 고른 뒤 조건을 바꾸어 보세요. 브라우저 안의 미리 정한 전환표가 다음 상태를 계산합니다. 실제 LLM이나 편집 시스템에 연결된 실험이 아닙니다. 핵심은 같은 ‘승인’ 사건이라도 현재 상태와 조건이 다르면 결과가 달라진다는 점입니다. 결과를 보기 전에 먼저 종이에 다음 상태를 적고 비교하면 화살표를 읽는 힘을 확인할 수 있습니다.