AI가 “이미 완료했다”고 말할 때, 정말로 했는지 어떻게 확인할까?

AI가 생성한 개념 삽화이며, 내용은 가상의 예시입니다.

AI에게 보고서를 팀 문서에 저장한 뒤 담당자에게 알리라고 요청했다고 가정해 보겠습니다. 몇 분 후, AI가 “이미 완료했습니다”라고 답합니다.

문서를 열어 보니 제목과 도입부 한 단락만 있습니다. 알림을 확인해 보니 지정된 채널에는 메시지가 없습니다. 어시스턴트가 거짓말을 한 것은 아닙니다. 호출한 각 단계마다 응답을 받았을 뿐이고, “이미 완료했습니다”는 호출 과정을 설명한 것이지 원하는 결과를 설명한 것이 아닙니다.

작업이 여러 시스템에 의존할수록 이 문장이 어긋나기 쉬워집니다. 정말로 답해야 할 질문은 하나입니다. 작업이 요구한 결과가 지금 정말로 있어야 할 곳에 존재하는가?

“완료”를 확인 가능한 결과로 작성하기

“보고서를 정리하고 팀에 알린다”는 작업 개요로는 적합하지만 검수 기준으로는 쓸 수 없습니다. 이를 대상 시스템에서 대조할 수 있는 조건들의 묶음으로 펼쳐야 합니다.

주간 경쟁사 보고서를 예로 들어 보겠습니다.

작업 요구	완료 조건(어디에서 확인할 수 있는가)
보고서 정리	지정된 기간을 포함하고, 출처 링크를 유지하며, 누락된 자료를 표시
문서 저장	지정된 워크스페이스와 상위 페이지에 위치하고, 본문이 최종본과 일치
팀에 알림	지정된 채널에 나타나고, 메시지의 링크가 위 문서를 가리킴
결과 전달	문서 위치, 알림 기록, 그리고 미완료 또는 미검증 항목을 반환

완료 조건을 작성할 때는 가능한 한 “누가 어디에서 그것을 볼 수 있는가”로 귀결시키세요. 초안 저장만 요구했다면 팀에 알릴 필요가 없습니다. 동료가 읽을 수 있어야 한다면 대상 구성원의 접근 권한도 확인해야 합니다. 어시스턴트 자신의 계정으로 문서를 열 수 있다고 해서 모든 수신자가 열 수 있는 것은 아닙니다.

“이미 보냈다”와 “상대방이 이미 읽었다”도 구분해야 합니다. 채널에 메시지가 나타난 것은 “게시됨” 판단을 뒷받침할 수 있습니다. 읽음 또는 확인 기록이 없으면 상대방이 이미 보고 후속 조치했다고 추론할 수 없습니다.

세 가지 증거는 서로 다른 질문에 답한다

검증할 때는 세 가지 자료가 있고, 각각은 질문의 일부만 답할 수 있습니다.

도구 반환        이번 호출이 어떤 응답을 받았는가?
                     상태, 오류, 반환된 객체 식별자
                          │
대상 기록        결과가 어디에 떨어졌는가? 다시 읽을 수 있는가?
                     대상 애플리케이션의 문서, 메시지, 기록
                          │
내용 검사        산출물이 요구 사항을 충족하는가?
                     완료 조건에 대조하여 본문, 출처, 누락 항목을 검사

도구 반환은 이번 호출에서 무슨 일이 있었는지 설명합니다. 응답의 상태 필드, 오류 메시지, 반환 객체는 호출된 서비스가 결정하며, 구체적인 의미는 해당 도구와 대상 API의 약속에 따라 달라집니다. 문서 식별자가 반환되었다면 그것으로 이 문서를 찾아갈 수 있습니다. 식별자만으로는 본문이 완전한지 판단할 수 없습니다.

대상 기록은 결과가 정말로 시스템에 떨어졌는지 설명합니다. 반환된 식별자로 문서를 다시 읽거나, 대상 애플리케이션에서 해당 기록을 열어 계정, 워크스페이스, 상위 페이지, 내용을 대조하세요. 알림을 확인할 때도 채널과 메시지 자체를 봐야 하며, 비슷한 제목으로 검색한 뒤 이번 결과를 찾았다고 단정해서는 안 됩니다.

내용 검사는 산출물을 납품할 수 있는지 설명합니다. 문서가 존재해도 한 섹션이 빠져 있을 수 있습니다. 보고서에 출처 링크가 있어도 잘못된 기간의 데이터를 인용했을 수 있습니다. 이 단계는 반드시 최초의 완료 조건으로 돌아가 항목별로 대조해야 하며, “생성에 성공했는가”만 보아서는 안 됩니다.

세 가지 증거는 짧은 영수증 하나로 합칠 수 있습니다. 무엇을 했고, 결과가 어디에 있으며, 무엇을 확인했고, 무엇이 아직 불확실한지. 사용자에게 전체 실행 로그를 붙여 넣을 필요는 없습니다.

부분 성공은 별도로 보고해야 한다

다단계 작업은 일부만 완료될 수 있습니다. 앞 단계는 이미 반영되었지만, 뒤 단계는 아직 결론이 나지 않은 경우입니다.

다음은 처리 방식을 설명하기 위한 가상 기록이며, 실제 호출 로그가 아닙니다.

단계	관찰된 결과	현재 판단
문서 저장	문서 식별자가 반환되었고, 다시 읽어 보니 본문이 완전하고 위치가 올바름	저장 및 검증됨
알림 전송	요청 타임아웃, 메시지 식별자를 얻지 못함	결과 미확인
대상 채널 조회	현재 계정에 메시지를 읽을 권한이 없음	이 계정으로는 확인 불가

이때 어시스턴트는 “문서는 저장되었고, 알림 결과는 확인되지 않았습니다”라고 보고하고, 문서 링크와 차단 원인을 함께 제시해야 합니다.

타임아웃은 호출자가 예상 시간 안에 응답을 받지 못했다는 것만 의미합니다. 알림이 발송되지 않았을 수도 있고, 대상 시스템에 이미 기록되었지만 응답이 유실되었을 수도 있습니다. 따라서 전체 작업을 곧바로 다시 실행하면 두 번째 문서가 생기거나 알림이 중복될 수 있습니다.

후속 처리는 결과가 미확인인 단계부터 시작해야 합니다. 계정에 읽기 권한이 있다면 대상 채널, 전송 시각, 보고서 링크를 기준으로 메시지를 확인하세요. 이번 작업에 대응하는 기록이 있다면 내용을 대조한 뒤 영수증을 보완하세요. 조회 결과가 없을 때는 조회 범위, 권한, 데이터 가시성 지연도 고려해야 하며, “찾지 못했다”를 곧바로 “발송되지 않았다”로 단정해서는 안 됩니다.

정말로 증거를 얻을 수 없다면, 권한이 있는 사람에게 대상 채널을 확인하도록 요청하고 재발송은 보류하세요. 재발송이 필요하다고 확인된 뒤에야 알림 단계를 계속하고, 이미 검증된 문서를 재사용하세요.

영수증에는 “미확인”을 남겨야 한다

사용 가능한 영수증은 이렇게 작성할 수 있습니다. 대괄호 안의 내용은 실제 결과로 채우고, 얻을 수 없을 때는 명확히 설명하며 그럴듯해 보이는 링크를 만들어 내지 마세요.

작업: 이번 주 경쟁사 보고서를 저장하고 지정된 채널에 알림

문서: 저장 및 검증됨
위치: [실제 문서 링크 또는 기록 식별자]
확인한 항목: 대상 워크스페이스, 상위 페이지, 본문, 출처 링크

알림: 결과 미확인
원인: 전송 요청 타임아웃, 현재 계정이 대상 채널 메시지를 읽을 수 없음
처리: 중복 알림을 피하기 위해 재발송 보류

확인 필요: 대상 채널에 위 문서 링크를 포함한 메시지가 나타났는지

“실패”, “미실행”, “결과 미확인”을 같은 상태로 뭉뚱그리지 마세요. 각각은 서로 다른 처리 방식을 요구합니다. 도구가 접근 거부를 명확히 보고했다면 보통 계정과 권한을 확인해야 합니다. 작업이 해당 단계까지 전혀 실행되지 않았다면 계속할지 결정해야 합니다. 전송 결과가 미확인이라면 먼저 기록을 조회해야 합니다. 오류 원인이 바뀌지 않았다면 같은 요청을 반복 제출해도 보통 결과는 달라지지 않습니다.

장기간 자동으로 실행되는 흐름에서는 각 단계의 결과 식별자와 검증 상태도 저장해야 합니다. 작업에 번호를 붙이면 기록을 연결하기 편리하지만, 번호 자체가 중복 쓰기를 막아 주지는 않습니다. 안전하게 재시도할 수 있는지는 대상 API가 멱등성을 지원하는지, 그리고 흐름이 실제로 중복 검사를 수행했는지에 달려 있습니다.

OOMOL에서 실행 기록은 어디까지 커버하는가

연결 계층은 호출 능력과 호출 기록을 제공할 수 있지만, 검수 판단은 여전히 작업 자체가 내려야 합니다.

OOMOL의 권한 제어는 connection별로 호출 가능한 작업을 설정합니다. 작업을 설계할 때 두 가지를 유의할 만합니다. 첫째, 검증에 필요한 읽기 능력도 함께 고려해야 합니다. 문서 생성을 허용했다고 해서 어시스턴트가 관련 기록을 다시 읽을 수 있다는 뜻은 아닙니다. 둘째, 권한이 특정 작업 호출을 허용하더라도 메시지 전송, 외부 데이터 수정, 공유 범위 확대, 콘텐츠 삭제 전에는 대상 connection, 작업, 최종 파라미터를 확인해야 합니다.

OpenConnector를 자체 배포할 때, 최근 실행 기록에는 마스킹된 입력 요약과 provider 오류가 포함되며, OOMOL_CONNECT_ALLOWED_ACTIONS와 OOMOL_CONNECT_BLOCKED_ACTIONS로 실행 가능한 작업을 제한할 수 있습니다. 어시스턴트는 schema, scope, 실행 상태, 안전한 계정 라벨만 볼 수 있습니다. 이 기록들은 호출 실패를 조사하는 데 적합하지만, 호출을 설명할 뿐 비즈니스 목표가 달성되었는지는 설명하지 않습니다. 자체 배포 가이드

작업이 사람의 승인을 기다려야 한다면, Open Flow의 Approval 및 Wait 노드가 대기 상태를 영속화하므로, 확인 후 같은 실행을 계속할 수 있고 이미 완료된 단계를 다시 실행할 필요가 없습니다. 실행 이력은 해당 흐름 버전과 연결되므로, 어떤 결과가 어느 버전의 로직에서 생성되었는지 파악하기 쉽습니다. 호스팅 버전 · 소스 코드 및 자체 배포

완료 조건, 단계 상태, 재시도 결정, 최종 영수증은 어시스턴트 지시, 비즈니스 코드, 또는 워크플로가 구현해야 합니다. 연결 계층은 호출 경로와 기록을 제공할 뿐, 전체 작업이 검수를 통과했는지 대신 판단하지 않습니다.

검수 가능한 작업 하나에서 시작하기

먼저 쓰기 단계 하나를 선택하고, 처음부터 전체 체인을 연결하지 마세요. OOMOL Connections에서 작업에 필요한 연결을 구성하고, 사용 가능한 작업을 확인한 뒤, 다음 요구 사항을 어시스턴트에게 전달하세요.

이 확인된 보고서를 내가 지정한 테스트 문서 위치에 저장해 주세요. 저장 후 다시 읽어 본문이 원고와 일치하는지 확인하고, 실제 문서 링크를 반환하세요. 다른 사람에게는 아직 알리지 마세요. 읽거나 검증할 수 없다면, 실행한 단계, 반환된 기록 식별자, 부족한 조건을 설명하고 작업을 전부 완료로 표시하지 마세요.

저장과 검증이 안정적으로 완료된 뒤에 알림을 추가하고, 해당 메시지 기록을 반환하도록 요구하세요. 쓰기 단계를 하나 추가할 때마다 대상 시스템에서 확인할 수 있는 완료 조건을 하나씩 보완하세요.

검수의 핵심은 어시스턴트가 마지막에 무엇을 말했는지가 아니라, 그것이 제시한 위치를 따라가서 대상 시스템에서 그 결과를 찾을 수 있는지에 있습니다. 모든 쓰기 단계가 확인 가능한 조건 하나에 대응할 때, 그 “이미 완료했습니다”에 근거가 생깁니다.