AI의 불확실성을 오류창 대신 작업열로 보내기

문서 백 개를 처리하는 AI 자동화를 떠올려 봅시다. 세 번째 문서에서 질문이 떴습니다.

“새 페이지로 만들까요?”

사람이 답하면 네 번째 문서에서도 묻고, 다섯 번째에서도 묻습니다.

정확하긴 한데 자동화가 아닙니다. 사람을 호출 스택에 넣은 프로그램입니다. (게다가 사람은 재귀에 약합니다.)

반대로 AI가 애매한 항목을 알아서 확정하게 두면 흐름은 빠르지만, 나중에 무엇을 왜 결정했는지 찾기 어렵습니다.

둘 중 하나를 고를 필요는 없습니다. 처리는 계속하되 확정할 수 없는 판단을 별도의 작업열에 남기면 됩니다. 불확실성을 즉시 오류로 만들지도, 조용한 추측으로 덮지도 않는 방식입니다.

오류와 검토 필요는 다른 상태입니다

오류는 보통 약속한 처리를 완료하지 못했다는 뜻입니다. 파일을 읽지 못했거나, 형식이 깨졌거나, 저장에 실패한 경우입니다.

검토 필요는 다릅니다. 자료는 읽었고 초안 분류도 만들었지만, 새 개념을 독립시킬지 기존 문서에 연결할지는 사람의 정책 판단이 필요할 수 있습니다.

둘을 같은 실패 큐에 넣으면 운영자가 기술 오류와 편집 판단을 한꺼번에 보게 됩니다. 반대로 둘 다 성공으로 표시하면 중요한 결정을 잃습니다.

상태를 나눠 보세요.

processed  — 자동 처리가 끝났고 추가 판단이 필요 없음
failed     — 약속한 처리를 완료하지 못함
review     — 처리는 진행됐지만 사람이 확정할 판단이 남음

이 세 번째 상태가 자동화의 속도와 사람의 권한을 함께 지켜 줍니다.

작업열에는 질문이 아니라 증거를 넣습니다

“확인해 주세요”만 적힌 검토 항목은 일을 미래로 미룬 메모에 가깝습니다. 검토자가 원문부터 다시 찾아야 하기 때문입니다.

쓸모 있는 항목에는 최소한 다음이 필요합니다.

• 어떤 입력에서 생겼는지
• AI가 무엇을 제안했는지
• 왜 확신하지 못했는지
• 판단에 필요한 근거가 무엇인지
• 선택 가능한 다음 행동은 무엇인지

예를 들어 위키 인제스트라면 새 페이지 만들기, 추가 조사하기, 건너뛰기처럼 행동을 제한할 수 있습니다. 자유 입력 칸 하나보다 결정 결과가 일관되고, 다음 처리도 자동화하기 쉽습니다.

추가 조사가 필요하다면 검색 질의 후보까지 남겨 둘 수 있습니다. 검토는 빈 화면에서 시작하지 않고, AI가 멈춘 지점에서 이어집니다.

모든 애매함을 보내면 작업열이 쓰레기통이 됩니다

불확실성 큐를 만들었다고 끝은 아닙니다. 모델이 조금이라도 망설일 때마다 항목을 만들면 사람은 곧 큐를 무시합니다.

검토 조건은 결과에 영향을 주는 판단으로 좁혀야 합니다.

• 외부에 공개될 내용인가?
• 새 영구 데이터를 만드는가?
• 기존 분류를 크게 바꾸는가?
• 사실 확인 없이 확정하면 되돌리기 비싼가?
• 사람마다 다른 정책 선택이 가능한가?

문장 부호 하나처럼 쉽게 되돌릴 수 있고 영향이 작은 선택은 기본 규칙으로 처리할 수 있습니다. 새 문서 생성이나 공개 범위 결정처럼 구조와 권한을 바꾸는 선택은 검토함으로 보냅니다.

작업열의 크기는 모델의 자신감보다 잘못된 확정의 비용으로 조절하는 편이 낫습니다.

검토 뒤의 상태 전이까지 설계합니다

큐에 넣는 기능만 만들면 미처리 항목이 박물관처럼 쌓입니다. 각 행동이 어떤 상태를 만드는지까지 정해야 합니다. 다음은 원본 llm_wiki README의 현재 동작을 옮긴 표가 아니라, 이 글이 제안하는 상태 전이 예시입니다.

Create Page   → 페이지 생성 결과를 확인한 뒤 항목 종료
Deep Research → 조사 작업을 생성하고 항목 상태를 명시적으로 갱신
Skip          → 선택 기록을 남기고 항목 종료

제품이 지원한다면 누가 언제 무엇을 선택했는지도 남겨 같은 판단을 반복하지 않게 할 수 있습니다. “Skip”도 삭제가 아니라 결정입니다. 나중에 조건이 바뀌었을 때 다시 볼 수 있는지는 제품의 보존 정책으로 명시해야 합니다.

저는 불확실성을 없애려는 자동화보다, 불확실성이 어디로 가는지 보이는 자동화를 더 믿습니다. AI가 매번 사람을 붙잡지 않으면서도 사람의 판단을 빼앗지 않기 때문입니다.

다음 자동화에서 애매한 결과가 나오면 success와 error 사이에 상태 하나를 추가해 보세요. 그리고 그 칸에 원문, 제안, 망설인 이유, 가능한 행동을 함께 넣으세요. 오류창을 하나 덜 띄우는 일이 아니라, 미래의 판단을 실제 작업으로 바꾸는 설계가 됩니다.