AI가 확신 못 하는 일은 왜 '검토함'으로 보내야 할까?

AI에게 문서를 정리하게 하면 가장 곤란한 순간은 틀린 답을 내놓을 때만이 아닙니다. 애매한데도 너무 매끄럽게 다음 행동까지 정해 버릴 때가 더 난감할 수 있습니다. 새 페이지를 만들어야 할지, 자료를 더 찾아야 할지, 그냥 지나가도 될지 모르는 상황에서 말이죠. 그때 모델이 “제가 알아서 처리했습니다”라고 하면 (친절한 척하지만), 우리는 무엇을 확인해야 하는지도 잃어버립니다.

llm_wiki의 README는 이런 판단을 Async Review System, 즉 비동기 검토함으로 따로 보냅니다. ingest 과정에서 LLM이 사람의 판단이 필요하다고 본 항목을 표시하고, 사용자는 나중에 자신의 속도로 검토합니다. 핵심은 AI가 모르는 일을 숨기지 않는 데 있습니다. 모른다는 신호를 작업 중단 버튼으로 만들지 않고, 검토 가능한 대기열로 바꾸는 것입니다.

확신이 없다는 말은 왜 결과물에 남아야 할까?

AI가 다루는 문서에는 정답이 하나로 고정되지 않은 판단이 많습니다. 어떤 개념을 새 페이지로 독립시킬지, 기존 지식과 연결할지, 더 넓은 자료 조사가 필요한지 같은 일입니다. README는 이런 항목을 사람의 판단이 필요한 대상으로 분류합니다.

그렇다고 매번 멈춰 서서 사람에게 물으면 ingest 자체가 답답해집니다. 책을 정리할 때마다 “이 문단도 중요한가요?”라는 질문이 즉시 뜬다고 생각해 보세요. 분류 작업을 하다가 계산대 앞에서 손님 한 명씩 붙잡는 편의점처럼, 흐름이 금방 막힙니다. 비동기라는 말은 이 문제를 피하는 방식입니다. 문서는 계속 처리하고, 불확실한 판단은 나중에 모아 봅니다.

README는 검토 시스템을 사람이 판단해야 하는 항목을 표시하는 비동기 대기열로 설명합니다. 사용자가 검토를 편한 때 처리하므로 ingest를 막지 않는다는 점도 함께 적고 있습니다. 여기서 비동기는 “사람이 필요 없다”는 뜻이 아닙니다. 반대로 사람의 판단을 지연 가능하지만 생략 불가능한 단계로 보존한다는 뜻에 가깝습니다.

아무 행동이나 제안하게 두지 않는 이유

이 검토함에는 세 가지 미리 정해진 행동 유형이 있습니다.

• Create Page: 새 페이지를 만들지 검토합니다.
• Deep Research: 추가 조사가 필요한지 검토합니다.
• Skip: 지금은 처리하지 않을지 검토합니다.

선택지가 적어 보이죠. 하지만 바로 그 제한이 중요합니다. README는 이 행동 유형이 임의의 다른 행동을 환각하는 일을 막기 위해 제약되어 있다고 설명합니다. 모델에게 “불확실하면 다음 조치를 마음껏 설계해”라고 열어 두면, 문서 정리와 무관한 처리까지 그럴듯하게 제안할 여지가 생깁니다. 반면 선택지를 세 개로 닫아 두면, 사람이 확인할 질문도 선명해집니다.

문서 ingest
  -> LLM이 사람 판단이 필요한 항목을 표시
  -> Async Review 대기열에 저장
  -> Create Page | Deep Research | Skip 중 하나를 검토
  -> 사람이 적절한 때 결정

이 흐름은 AI에게 “완벽한 다음 행동”을 기대하는 방식이 아닙니다. AI에게는 판단이 필요한 지점을 찾는 역할, 사람에게는 허용된 선택지 안에서 결정하는 역할을 나눠 줍니다. 자동화가 커질수록 이 역할 분리가 더 소중해집니다. AI는 못 본 척하지 말고 표시하고, 사람은 매번 즉시 응답하지 않아도 됩니다.

Deep Research는 왜 미리 질의를 만들까?

Deep Research 항목에는 검색에 쓸 질의를 ingest 시점에 미리 생성하는 방식도 들어 있습니다. README는 이 질의가 LLM에 의해 검색용으로 최적화되어 생성된다고 설명합니다. 따라서 나중에 검토자가 “추가 조사가 필요하다”는 판단을 했을 때, 무엇을 찾아볼지 처음부터 다시 문장으로 조립하는 부담을 줄일 수 있습니다.

여기서도 순서를 잘 봐야 합니다. 검색 질의를 미리 만든다고 해서 검색 결과를 자동으로 믿는 것은 아닙니다. 그 질의는 조사 시작점일 뿐입니다. 검색어 자체가 문서의 맥락을 과도하게 좁히거나, 반대로 너무 넓게 만들 수 있기 때문입니다. 그래서 사람은 검토함에서 “조사가 필요한가”만 고르는 것이 아니라, 실제로 어떤 근거를 받아들일지도 계속 살펴야 합니다. 검색창도 가끔 “이걸 찾으시려던 건가요?”라며 자신만만하게 엉뚱한 데로 데려가니까요.

이것은 오류 처리와 조금 다릅니다

검토함을 오류 목록이라고 생각하면 미묘하게 어긋납니다. 오류는 보통 프로그램이 약속한 동작을 못 했다는 신호입니다. 반면 여기의 검토 항목은 프로그램이 멈췄다는 뜻보다, 판단의 주체를 사람에게 넘겨야 하는 순간을 표시합니다. 문서는 처리됐을 수 있고, 위키 페이지도 생성됐을 수 있습니다. 다만 “새 항목을 추가해도 되는가?” 또는 “더 조사해야 하는가?” 같은 결론은 확정하지 않고 남겨 둡니다.

이 차이를 알면 자동화를 설계할 때 질문도 달라집니다. 실패했을 때만 알림을 만들 것이 아니라, 성공처럼 보이지만 승인·해석·정책 선택이 필요한 지점을 어디에 쌓을지 생각하게 됩니다. 예를 들어 고객 요청을 분류하는 시스템이라면, 금지 표현을 발견했을 때만 멈추는 것이 아니라 의도가 불명확한 요청을 “확인 필요”로 보내는 편이 안전할 수 있습니다. 어떤 기준으로 보낼지는 서비스마다 다르지만, 모호함을 별도 상태로 다루는 발상은 그대로 가져갈 수 있습니다.

내 자동화에 적용하는 작은 규칙

AI가 참여하는 흐름을 만들고 있다면, 거대한 검토 시스템부터 만들 필요는 없습니다. 다음처럼 작게 시작해도 됩니다.

• 확신이 부족한 결과에 붙일 상태를 하나 정합니다.
• 그 상태에서 가능한 다음 행동을 몇 개로 제한합니다.
• 발견 시점에 사람이 검토할 재료를 함께 남깁니다.
• 처리 흐름은 계속 가게 두되, 확정은 검토 뒤에만 일어나게 합니다.

가령 “새 문서를 분류한다”는 자동화라면 새 분류 만들기, 추가 자료 찾기, 보류 정도가 될 수 있습니다. 중요한 것은 멋진 버튼 개수가 아닙니다. 누가 어떤 결정을 하며, 그 결정을 나중에 다시 볼 수 있는지가 핵심입니다. 검토함은 AI를 믿지 말자는 선언이 아니라, 믿을 수 있는 범위를 설계하자는 제안입니다 (둘은 꽤 다릅니다).

정리: AI의 망설임을 숨기지 말고 보관하세요

Async Review System은 불확실한 판단을 버리지 않고, ingest를 멈추지도 않게 합니다. 사람 판단이 필요한 항목을 대기열에 남기고, Create Page, Deep Research, Skip처럼 제한된 행동 중에서 검토하게 합니다. 필요한 조사 질의까지 미리 준비해 두므로, 검토는 빈 화면에서 다시 시작하지 않아도 됩니다.

AI가 확신하지 못하는 순간은 자동화의 실패가 아닐 수 있습니다. 그 순간을 알아보고 사람에게 넘기는 경계가 잘 보이면, 오히려 시스템은 더 정직해집니다. 다음 설계에서 “모르겠으면 어떻게 하지?”가 나오면, 답을 억지로 만들게 하지 말고 검토함 하나를 마련해 보세요. 그 작은 칸이 나중의 큰 되돌리기를 줄여 줄지도 모릅니다.