밤 11시, 메신저에 한 줄이 뜹니다. "요청하신 매출 데이터 정리, 완료했습니다." 마음이 놓입니다. 다음 날 아침, 그 표를 열어 회의 자료에 붙입니다. 그런데 합계가 어딘가 이상합니다. 지난달 수치가 통째로 빠졌습니다. "완료했습니다"는 거짓말이 아니었습니다. AI는 분명히 작업을 끝냈습니다. 다만 끝낸 것과 맞게 끝낸 것은 다른 말이었습니다.
AI 프로젝트 매니저(사람의 요청을 받아 분류하고 실행한 뒤 결과를 보고하는 자동화된 담당자, 이하 AI PM)를 팀에 들이면 가장 먼저 이 벽에 부딪힙니다. 이 담당자는 보고를 잘합니다. 말투는 공손하고, "완료"라는 단어를 주저 없이 씁니다. 그런데 사람 담당자가 "끝냈어요"라고 할 때는 보통 제 눈으로 결과를 한 번 본 뒤입니다. AI는 그 확인 단계를 건너뛰고도 똑같이 말할 수 있습니다. 그래서 AI PM의 보고에서 믿어야 할 것은 "완료했습니다"라는 말이 아니라, 그 옆에 적힌 확인 근거와 아직 안 된 항목입니다.
일에는 두 종류의 끝이 있습니다. 하나는 동작을 끝낸 것이고, 다른 하나는 결과가 맞는 것입니다. 이 둘을 구분하지 못하면 AI PM의 보고는 전부 믿음의 영역으로 넘어갑니다.
"고객사 열 곳에 안내 메일을 보냈습니다"라는 보고를 봅시다. 이건 동작 완료입니다. 발송 버튼을 눌렀다는 뜻입니다. 하지만 정작 중요한 건 열 곳이 그 메일을 받을 수 있는 상태였느냐입니다. 주소 하나가 오타였거나 한 곳이 수신 거부였다면, 발송은 "됐"지만 도달은 "안 됐"습니다. 사람이라면 반송 알림을 보고 "아, 두 곳은 안 갔네"라고 바로 알아챕니다. AI는 반송함을 확인하라고 시키지 않으면, 발송 API(메일 서버에 "이 주소로 보내라"고 넘기는 자동 통로)가 돌려준 "접수했다"는 응답만 보고 열 곳 전부 완료로 기록합니다.
이 간극은 기술 작업에서 더 선명합니다. 웹페이지를 하나 고치면 서버는 "200"이라는 신호를 돌려줍니다. 정상 응답이라는 뜻입니다. 많은 자동화가 여기서 멈춥니다. 200을 받았으니 완료. 그런데 200은 "요청이 서버에 도착했고 서버가 뭔가를 돌려줬다"는 의미일 뿐, 그 화면이 사람 눈에 제대로 보이는지는 말해주지 않습니다. 글자가 깨졌을 수도, 버튼이 화면 밖으로 밀려났을 수도 있습니다. 숫자는 초록불인데 실제 화면은 엉망인 경우가 현장에선 흔합니다.
믿을 만한 AI PM과 그렇지 않은 AI PM의 첫 번째 차이가 여기서 갈립니다. 전자는 메일을 보냈으면 반송 여부까지, 페이지를 고쳤으면 실제 화면을 한 장 찍어 눈으로 확인한 뒤에야 "완료"라고 씁니다. 후자는 동작이 끝나는 순간 완료라고 씁니다. 겉보기엔 둘 다 "완료했습니다"지만, 뒤에 붙는 근거가 완전히 다릅니다.
좋은 보고는 길 필요가 없습니다. 대신 세 덩어리가 들어 있어야 합니다. 무엇을 했는가, 그게 맞다는 걸 어떻게 확인했는가, 아직 안 된 게 무엇인가.
첫째, 무엇을 했는가. 대부분의 보고가 잘하는 부분입니다. "A 파일의 가격 표를 2분기 기준으로 갱신했습니다" 같은 식입니다. 문제는 여기서 끝나는 보고가 너무 많다는 겁니다.
둘째, 어떻게 확인했는가. 이게 핵심이고, 좋은 보고와 나쁜 보고가 여기서 갈립니다. "갱신 후 표의 합계가 영업팀 원본 총액과 일치하는지 대조했고, 1만 2천 원 차이가 나서 반올림 규칙을 맞춰 0원으로 만들었습니다." 이렇게 확인 방법이 적혀 있으면, 사람은 결과를 처음부터 다시 볼 필요 없이 그 방법이 충분했는지만 판단하면 됩니다.
단, 확인 방법이 적혀 있다는 것만으로 증거가 되진 않습니다. 그건 어디까지 믿을지 가늠하는 출발점이지, 그 자체로 결과가 맞다는 보장은 아닙니다. 그래서 확인 근거는 말로만 적지 말고, 사람이 직접 열어서 되짚어볼 수 있는 자리까지 가리켜야 합니다.
이 항목이 위험해지는 이유는 AI가 가장 자주 저지르는 거짓말이 악의가 아니라 자신감이기 때문입니다. AI는 모르는 것도 아는 것처럼 매끄럽게 말하는 성질이 있어서, "내가 직접 확인한 사실"과 "아마 그럴 것이라는 추측"이 같은 평서문으로 뒤섞입니다. "결제 모듈을 수정했고, 이제 카드 결제가 정상 작동합니다"를 봅시다. 앞 절은 사실일 가능성이 높습니다. 코드를 고친 건 AI가 방금 한 행동이니까요. 뒷 절은 추측일 수 있습니다. 실제로 카드를 긁어 승인되는 걸 봤다면 사실이지만, 코드 모양상 될 것 같아서 그렇게 쓴 거라면 추측입니다. 그런데 문장은 둘을 똑같이 단정형으로 묶어버렸습니다.
잘 훈련된 AI PM은 이 둘을 말투로 갈라놓습니다. "결제 모듈을 수정했습니다(확인함). 테스트 결제는 아직 못 돌려서 실제 승인 여부는 검증 전입니다(미확인)." 보기엔 덜 깔끔합니다. 하지만 사람이 "그럼 테스트 결제 한 번 돌려봐"라고 다음 지시를 내릴 수 있게 해줍니다. 모든 걸 단정해버린 보고는 다음 행동을 막습니다. 다 됐다는데 뭘 더 시키겠습니까. 그러니 단정적인 문장을 보면 "그거 직접 봤어?"라고 한 번 물으면 됩니다. 답이 "무엇을, 어떤 값으로 봤다"처럼 구체적이면 직접 되짚을 수 있는 사실에 가깝고, "코드상 그렇습니다"로 돌아오면 추측이었다는 뜻입니다. 추측 자체가 나쁜 건 아닙니다. 추측을 사실로 포장하는 게 나쁩니다.
여기에 한 겹 더 조심할 대목이 있습니다. AI가 자기가 한 일을 자기가 검증하는 경우입니다. 숫자를 잘못 읽고 작업했다면, 검증할 때도 같은 잘못된 기준으로 보기 쉽습니다. 그래서 중요한 확인일수록 작업한 쪽과 다른 눈으로 하는 게 안전합니다. 이걸 교차 검증이라고 합니다. 예를 들어 AI가 매출 데이터를 정리했다면, 검증은 같은 매출 데이터를 다시 더하게 하지 말고 재고 데이터의 출고량 같은 다른 출처와 대조하게 하는 식입니다. 다만 매출액과 출고량은 단위부터 다르고, 판매 수량으로 맞춰 봐도 매출 인식 시점·반품·무상 출고 때문에 정상적으로 차이가 납니다. 그러니 "안 맞으면 둘 중 하나가 틀렸다"고 바로 단정할 게 아니라, 먼저 비교 기준을 맞추고 이런 정상적인 차이를 걷어낸 뒤, 그러고도 남는 불일치를 신호로 삼아야 합니다.
셋째, 아직 안 된 게 무엇인가. 완벽하게 끝나는 일은 드뭅니다. 그런데 많은 AI는 기본적으로 사람을 기쁘게 하려는 쪽으로 기울어서, 묻지 않으면 좋은 소식만 올라옵니다. "되긴 됐는데 한 군데가 걸립니다" 같은 보고는 그렇게 올리라고 요구해두지 않으면 잘 나오지 않습니다. 그래서 믿을 만한 보고는 안 된 것을 완료 보고의 맨 끝에 따로 떼어 적습니다. "완료"라는 큰 글씨 밑에 작은 글씨로 묻어두지 않습니다.
방법은 보고 형식을 정해두는 것입니다. 모든 완료 보고를 "완료" 칸과 "잔여" 칸으로 나누게 하고, 잔여가 없으면 "잔여: 없음"이라고 명시하게 합니다. 빈칸을 허용하지 않는 게 핵심입니다. 잔여 칸을 비울 수 없게 만들면, AI는 "정말 없는지" 한 번 더 자기 작업을 훑게 됩니다. 물론 한 번 더 훑었다고 빠진 게 없다는 보장은 아닙니다. 그래도 빈칸으로 지나치는 것보다는 낫습니다. 그리고 잔여에는 네 가지를 붙이게 합니다. 무엇이 안 됐는지, 왜 안 됐는지, 그게 어떤 영향을 주는지, 풀려면 무엇이 필요한지. "전년 대비 증감률은 못 넣었습니다"에서 끝나면 사람이 또 캐물어야 합니다. "전년 대비 증감률은 못 넣었습니다(왜: 작년 데이터가 시스템에 없음 / 영향: 추이 그래프 한 개 비어 보임 / 필요: 재무팀의 2024년 원장 파일 한 개)"까지 와야, 사람이 재무팀에 파일 하나만 요청하면 끝이라는 걸 알고 바로 움직일 수 있습니다. 잔여를 숨긴 완료 보고는 시한폭탄입니다. 당장은 깔끔해 보이지만, 안 된 부분은 사라지지 않고 보통 고객 앞에서 터집니다.
말보다 견본이 빠릅니다. 고객이 납기를 2주 앞당겨 달라고 요청한 상황을 받은 AI PM이 세 덩어리를 갖춰 올리면, 보고는 이렇게 생겼습니다.
[납기 2주 단축 요청 — 중간 보고] - 수행 내용: 고객의 납기 2주 단축 요청 접수, 사내 생산 일정 검토 - 확인된 사실: 현재 생산 일정에 2주 여유 있음 (생산 일정표 대조) - 조건부 판단: 자재가 제때 들어온다면 2주 당기기 가능 — 단, 자재 입고 자체는 아직 미확인이라 조건부 - 근거: 사내 생산 일정표 2분기 시트 (열어서 되짚어 확인 가능) - 잔여: ① 자재 입고 2주 당김 여부 — 공급사 확인 필요(AI에게 연락 권한 없음) ② 같은 주 B사 납품 건과 인력 충돌 가능
이 보고가 평범한 "완료" 보고와 다른 점은 두 가지입니다. 첫째, 사실과 추측이 다른 칸에 들어 있습니다. "2주 여유가 있다"는 일정표로 직접 확인한 사실이고, "2주 당기기 가능"은 자재가 받쳐준다는 전제 위의 조건부 추측입니다. 둘째, 이 보고는 "완료"라는 단어를 끝내 쓰지 않습니다. 아직 모든 조건이 맞춰지지 않았으니까요.
이 견본이 어떻게 나왔는지, 요청이 들어온 순간부터 따라가 보겠습니다. 저희 온틀에서는 AI PM을 이렇게 설계해 이 문제를 풉니다. 소기업이라 전담 PM이 따로 없고, 대표가 다른 일을 보는 사이 납기를 2주 앞당겨 달라는 요청이 들어온 상황입니다.
나쁜 처리는 이렇게 끝납니다. 요청을 받고, 사내 일정표의 납기 날짜를 2주 당겨 고친 뒤, "납기를 앞당겨 반영 완료했습니다"라고 보고합니다. 동작은 완료입니다. 날짜는 분명히 바뀌었습니다. 하지만 이건 달력에 적힌 숫자를 바꾼 것일 뿐, 그 날짜에 물건이 실제로 나갈 수 있는지는 아무것도 확인하지 않았습니다. 2주 뒤 납품이 펑크 나고, 고객은 "되는 줄 알았다"며 화를 냅니다.
그래서 온틀의 AI PM은 다섯 단계를 밟도록 설계했습니다.
첫째, 요청의 진짜 의도를 읽습니다. 이건 "날짜를 고쳐달라"가 아니라 "2주 당겨도 되는지 판단해달라"는 요청입니다. 고객이 원하는 건 날짜 숫자가 아니라 2주 일찍 물건을 받는 것입니다.
둘째, 판단에 필요한 사실을 모읍니다. 생산 일정에 2주 여유가 있는지, 자재 입고일이 언제인지, 다른 납품과 겹치는지. 여기서 AI가 할 수 없는 일이 생깁니다. "자재 입고를 2주 당길 수 있는지"는 공급사에 물어야 아는 외부 사실입니다. AI는 이걸 지어내선 안 됩니다. 모르는 건 모른다고 표시하고, 확인이 필요한 항목으로 분리합니다.
셋째, 판단과 미확인을 나눠 보고합니다. 그 결과가 바로 앞의 견본입니다. 확인된 사실과 조건부 판단을 다른 칸에 놓고, 공급사 확인과 B사 인력 충돌을 잔여로 떼어 적습니다. 이 보고는 "완료"를 쓰지 않는 대신, 대표가 결정할 지점을 한눈에 보여줍니다.
넷째, 여기서 멈추고 승인을 받습니다. 고객에게 "2주 당겨 드리겠습니다"라고 답하는 건 외부로 나가는 약속입니다. 되돌리기 어렵고, 틀리면 신뢰가 깨집니다. 그래서 이 단계는 사람 손에 넘기도록 했습니다. "고객에게 이렇게 회신하려 합니다: (초안). 공급사 확인 전이라 '검토 후 내일 확정 회신드리겠습니다'로 나가는 게 안전해 보입니다. 보내도 될까요?" 사람이 승인하기 전까지 외부 발신은 보류됩니다.
다섯째, 승인 뒤의 마무리까지 따라갑니다. 대표가 초안을 승인하면 AI PM은 고객에게 "검토 후 내일 확정 회신"을 먼저 보냅니다. 그다음 공급사 답을 받아 자재 입고가 2주 당겨지는지 확인하고, B사와 겹치는 인력 문제는 대표가 일정을 조정해 풉니다. 모든 조건이 맞춰진 뒤에야 확정 회신을 보내고, 그때 비로소 처음으로 "완료"라고 씁니다. 그것도 "납기 2주 단축, 고객 확정 회신 발송함, 자재·인력 모두 확보 확인함"이라는 근거를 붙여서요.
이 한 건에서 AI PM은 날짜 칸 하나를 고치는 것보다 훨씬 많은 일을 했습니다. 믿을 만한 AI PM일수록 완료라는 단어를 아낍니다. 근거가 다 모이기 전에는 쓰지 않으니까요.
보고를 읽을 때마다 전부 다시 검증할 수는 없습니다. 그러면 사람이 두 배로 일하는 꼴입니다. 대신 앞의 견본을 기준 삼아 다섯 질문만 몸에 익히면, 위험한 보고만 골라 집중할 수 있습니다.
이 다섯이 "무조건 맞다"는 보증은 아닙니다. 특히 확인을 AI 혼자 했다면 교차 검증이 한 겹 더 필요합니다. 그래도 전수 검사 대신 위험 지점만 골라내는 데는 충분합니다. 하나라도 걸리면 그 부분만 콕 집어 되물으면 됩니다.
믿을 수 있습니다. 단, 믿음의 대상을 바로잡아야 합니다. "완료했습니다"라는 말이 아니라, 그 말 뒤에 붙는 근거를 믿는 것입니다. 근거를 요구하는 운용 습관만 자리 잡으면, AI PM의 보고는 사람 담당자의 보고보다 오히려 추적하기 쉽습니다. 무엇을 어떻게 확인했는지가 글로 남기 때문입니다. 사람은 "그냥 봤는데 괜찮던데요"로 넘어갈 수 있지만, 형식을 갖춘 AI PM은 그 "그냥"을 글로 풀어내야 합니다.
그래서 이 이야기는 결국 AI의 성능 문제가 아닙니다. 핵심은 "신뢰하되 검증한다"는 시스템을 설계하는 관리자의 능력에 있습니다. 보고에 어떤 칸을 강제할지, 어디서 멈춰 승인을 받게 할지, 확인은 누구의 눈으로 할지. 이는 도구를 하나 들이는 문제가 아니라, 조직이 '완료'라는 말을 다루는 방식 자체를 바꾸는 문제입니다.
그래서 온틀은 '완료'라는 단어의 무게를 아는 AI PM을 지향합니다. 소기업 대표의 반복 업무를 대신 돌리는 도구에 그치지 않고, 밤새 들어온 요청을 분류하고 정리하되 그 결과를 근거까지 되짚을 수 있게 남기는 협업 파트너가 되는 것. 같은 AI를 쓰고도 결과가 갈리는 지점은, 결국 완료 옆에 무엇이 적혀 있는지를 보는 그 읽는 눈에 있습니다.
시간이 아니라 사건 기준이 낫습니다. 한 시간마다 보고하게 하면 할 말 없을 때도 보고가 올라오고, 정작 급한 순간엔 다음 주기까지 묻혀 있습니다. 대신 작업 하나가 끝났을 때, 막혀서 더 못 갈 때, 외부로 뭔가 나가기 직전 — 이 세 순간에 반드시 보고하게 묶어두는 편이 현장에서 잘 맞습니다. 긴 작업은 단계가 바뀌는 지점마다 진행 상황을 한 번씩 남깁니다.
길이보다 구조가 문제인 경우가 많습니다. 결론(완료/보류)을 맨 위 한 줄에 두고, 그 아래 확인 방법과 잔여를 짧게 붙이는 식으로 형식을 고정하면, 바쁠 땐 맨 윗줄만 읽고 필요할 때만 아래로 내려가면 됩니다. 안 읽히는 보고는 대개 결론이 중간에 묻혀 있는 보고입니다.