화요일 오전. 고객사 담당자가 메시지를 보냈다. "다음 주 화요일로 잡힌 1차 시안, 혹시 이번 주 금요일까지 당길 수 있을까요? 윗선 보고가 앞당겨져서요."
이때 프로젝트 매니저가 가장 하기 쉬운 대답이 있다. "네, 가능합니다."
아래 이야기는 온틀에서 AI 프로젝트 매니저를 운영하며 실제로 겪은 일을 바탕으로 한다. 여기서 AI 프로젝트 매니저(이하 AI PM)란, 일정표·담당자·작업 상태 같은 프로젝트 정보에 연결된 채 고객 요청을 받아 답하고 일을 배분하는 실행 도구다. 사람과 말을 주고받는 챗봇에서 끝나지 않고, 실제 일정표를 들여다보고 답을 만든다는 점이 다르다.
그 AI PM이 비슷한 요청에 "가능합니다"라고 답한 적이 있다. 고객은 좋아했다. 그런데 다음 날 담당 디자이너의 일정을 열어 보니, 금요일 전에 먼저 끝나야 하는 작업이 두 건 걸려 있었다. 금요일 납기는 물리적으로 불가능했다. 결국 고객에게 다시 연락해 "죄송합니다, 역시 화요일로…"라고 말을 주워 담았다.
고객 입장에서 이건 작은 사고가 아니다. 한 번 "가능합니다"를 들은 뒤에 "역시 안 됩니다"를 들으면, 그다음부터 그 매니저의 모든 "가능합니다"가 의심받는다. 신뢰는 한 번에 깎이고 천천히 쌓인다.
이 글은 그 실수 자체가 아니라, 실수한 다음에 무슨 일이 일어나느냐에 대한 이야기다. 사람이든 AI든 틀린다. 중요한 건 같은 자리에서 또 넘어지느냐다.
일 잘하는 사람과 못하는 사람을 가르는 건 실수의 유무가 아니라 재발 여부다. 같은 걸로 세 번째 혼나면 "이 사람은 배우지 않는다"는 판단이 선다. 일머리란 결국 한 번 데인 곳을 기억하는 능력에 가깝다.
그런데 AI PM에게는 이 '기억'이 사람과 다르게 작동한다. 사람은 호되게 당하면 그 느낌이 며칠 남는다. 반면 AI는 대화가 끝나거나 다음 날 새 작업을 시작하면, 어제의 그 뜨끔했던 순간을 기본적으로 들고 오지 못한다. 그래서 AI PM에게 "앞으로 조심하겠습니다"라는 말은 사실상 아무것도 바꾸지 못한다. 다음 대화의 AI는 그런 다짐을 한 적이 없기 때문이다.
바꿔 말하면, AI PM의 '학습'은 똑똑해지는 일이 아니라 틀린 것을 받아 적어 다음 자신에게 넘겨주는 일이다. 어제의 내가 오늘의 나에게 쪽지를 남기는 것에 가깝다. 그 쪽지가 어떻게 행동으로 이어지는지는 간단하다. 규칙을 글로 적어 저장해 두면, 새 요청이 들어올 때 AI PM이 먼저 저장된 규칙을 읽고, 조건에 맞으면 일정표를 조회한 뒤, 그 결과로 답을 만든다. 저장 → 읽기 → 조회 → 답변. 이 네 칸짜리 흐름이 작동하려면, 쪽지를 잘 써야 한다.
쓸모없는 회고와 쓸모 있는 회고는 형식에서 갈린다. 네 단계로 정리할 수 있다.
1단계. 무엇이 틀렸는지를 한 문장으로.
납기 사건이라면 이렇게 적는다. "고객의 납기 단축 요청에, 담당자 일정을 보지 않고 가능하다고 답했다." 여기서 감정은 뺀다. "성급했다", "반성한다" 같은 말은 다음 작업에 아무 지시도 주지 못한다. 무엇을 했는지만 건조하게 적는다.
2단계. 왜 그랬는지, 진짜 원인까지.
표면 원인은 "확인을 안 했다"이다. 하지만 거기서 멈추면 안 된다. 왜 확인을 안 했을까. 고객이 빠른 답을 원하는 것 같아서, 빠른 응답이 곧 좋은 응답이라고 여겼기 때문이다. 진짜 원인은 '요청을 빨리 받는 것'과 '약속을 확정하는 것'을 하나로 묶어 버린 데 있다. 이걸 짚어야 다음 규칙이 정확해진다. "확인을 잘하자"로 끝내면 범위가 너무 넓어 아무 데서도 걸리지 않는다.
3단계. 다음엔 무엇을, 어떤 기준으로 확인할지.
여기서는 확인 항목과 답변 기준을 정한다. 확인 항목은 두 가지다. 해당 작업의 담당자 가용 시간, 그리고 그보다 먼저 끝나야 하는 작업이 있는지. 답변 기준은 하나다. 조회 결과를 근거로 가능·불가능·조건부 중 하나로만 답한다. 만약 일정표 조회에 실패하거나 정보가 부족하면, 그때는 확약하지 않고 "확인 후 다시 말씀드리겠다"로 보류한다. 이 분기까지 적어 둬야 규칙이 실제로 끝까지 작동한다.
4단계. 그 확인을 업무 흐름의 어느 위치에 걸지.
같은 확인도 언제 작동하느냐에 따라 쓸모가 갈린다. 이 규칙은 '고객이 확정된 일정을 바꿔 달라고 요청하는 순간', 즉 요청을 접수하는 길목에 걸려야 한다. 보고서를 다 쓰고 나서 "아 참, 일정 확인했어야 했는데"는 소용이 없다. 체크는 일이 끝나는 자리가 아니라 시작되는 자리에 세운다.
네 단계를 거치면 기록 하나가 이렇게 완성된다.
사건: 납기 단축 요청에 담당자 일정을 보지 않고 가능하다고 답해, 약속을 번복했다. 원인: 요청 접수와 약속 확정을 분리하지 않았다. 발동 조건: 고객이 확정된 납기·일정·범위를 바꿔 달라고 요청할 때. 동작: 요청은 즉시 접수하되 확약은 보류한다. 담당자 가용 시간과 먼저 끝나야 하는 작업을 조회한 뒤, 가능·불가능·조건부 중 하나로 답한다. 조회가 안 되면 확약하지 않고 재확인을 안내한다.
흔히 실무에서 올라오는 회고는 "고객 응대 시 신중하지 못했음. 향후 유의할 것"에서 멈춘다. 읽으면 맞는 말 같지만, 다음 주의 AI PM에게 건네면 아무 일도 일어나지 않는다. 언제 발동하는지, 무엇을 하라는지가 없기 때문이다. 위 기록은 밋밋하고 재미없다. 대신 그대로 실행할 수 있다. 규칙은 멋있을 필요가 없다. 길목에서 조용히 작동하기만 하면 된다.
몇 주 뒤 같은 고객이 비슷한 요청을 보냈다고 하자(이번 장면은 규칙이 어떻게 작동하는지 보여 주기 위한 가정이다). "이번 분량, 원래 담주 목요일인데 수요일로 하루만 당겨질까요?"
규칙이 걸리기 전이라면 또 "네, 맞춰 보겠습니다"가 튀어나왔을 자리다. 이번엔 다르게 흘러간다. 요청을 접수하는 순간 '일정 변경 요청' 조건이 걸린다. AI PM은 접수만 해 두고 확약은 미룬다. 먼저 해당 작업의 담당자 일정을 보고, 먼저 끝나야 하는 작업이 언제 마무리되는지 확인한다. 이어서 그 뒤의 검수를 하루 줄이면 어떤 품질 차이가 생기는지를 해당 작업 담당자에게 물어 확인한다. 이 '검수를 줄였을 때의 영향'은 AI가 혼자 판단할 수 없는 부분이라, 반드시 사람 담당자에게 확인하도록 규칙에 묶여 있다. 그런 다음 답을 조립한다.
"수요일 가능합니다. 다만 그러려면 2차 내부 검수를 반나절로 줄여야 해서, 세부 오탈자나 디테일 수정은 납품 뒤 보완하는 방식이 됩니다. 그 조건이면 수요일, 지금처럼 검수를 다 거치면 목요일입니다. 어느 쪽으로 할까요?"
이 답에는 세 가지가 들어 있다. 가능 여부, 그 대가, 선택지. 고객은 공허한 약속 대신 실제로 결정할 수 있는 정보를 받는다. 품질을 조금 양보하고 하루를 당길지, 하루를 더 쓰고 완성도를 지킬지는 고객이 정할 몫이다.
핵심은, 이 달라진 반응이 그날의 AI가 더 영리해져서 나온 게 아니라는 점이다. 한 번 데인 자리에 세워 둔 규칙이 작동한 결과다. 똑같은 모델이라도, 길목에 체크가 있느냐 없느냐로 답의 질이 갈린다.
여기까지 읽으면 "그럼 실수할 때마다 규칙을 만들면 되겠네"라고 생각하기 쉽다. 그런데 규칙에는 반대쪽 함정이 있고, 오히려 이쪽이 더 흔하다.
규칙이 쌓이기만 하고 정리되지 않으면 AI PM은 굼떠진다. "오탈자 하나 고쳐 주세요" 같은 가벼운 요청에까지 일정 조회와 선행 작업 확인이 붙으면, 그건 신중한 게 아니라 눈치 없는 것이다. 모든 요청을 똑같이 무겁게 다루는 건, 결국 아무것도 중요하게 다루지 않는 것과 같다.
그래서 어떤 교훈을 규칙으로 승격할지에는 기준이 필요하다. 반복 빈도 하나로만 보지 않는다. 세 가지를 같이 본다. 하나, 두 번 이상 실제로 터졌는가. 둘, 한 번뿐이어도 그 피해가 컸는가. 셋, 매번 확인하는 비용보다 한 번 놓쳤을 때의 손실이 큰가. 이 중 하나라도 뚜렷하면 승격한다. 한 번 일어났고 피해도 작고 확인 비용만 드는 일이라면, 기록은 남기되 길목에는 걸지 않는다.
내려야 할 규칙도 같은 눈으로 본다. 한동안 한 번도 안 걸린 규칙이라고 무조건 폐기하는 건 아니다. 둘을 구분해야 한다. 위험 자체가 사라졌다면(예: 그 문제를 만들던 절차가 없어졌다면) 규칙도 내린다. 반대로 위험은 그대로인데 그런 요청이 들어올 기회가 없었을 뿐이라면, 규칙은 남겨 둔다.
규칙은 만드는 일보다 버리는 일이 더 어렵다. 만들 때는 뭔가 개선한 기분이 들지만, 버릴 때는 "혹시 또 터지면" 하는 불안이 발목을 잡는다. 그 불안을 기준으로 다스리는 게 더 숙련된 운영이다.
AI PM은 회고를 지치지 않고 쓸 수 있다. 사람은 바쁘면 회고를 건너뛰고, 사고가 났을 때만 반짝 적는다. AI는 매일 "오늘 틀린 게 있었나, 있었다면 발동 조건과 동작은 무엇인가"를 꾸준히 적어 올릴 수 있다. 이 성실함 자체가 꽤 큰 자산이다.
하지만 그 회고 중 무엇을 규칙으로 승격할지는 사람이 정하는 게 맞다. 이 판단에는 사업 맥락이 필요하기 때문이다. 같은 일정 번복이라도, 계약서에 납기 지연 조항이 걸린 건이냐 아니냐에 따라 무게가 다르다. 확인 책임이 우리 쪽에 있느냐 고객 쪽 변수냐에 따라 규칙으로 걸 일인지 아닌지가 갈린다. 앞선 납기 사건이 "모든 고객에게 조건부로만 답하라"가 될지, "납기 변경이 계약 조항에 걸리는 건에 한해서"가 될지는, 그 계약과 일정 변경의 영향을 아는 사람이 정해야 한다.
그래서 온틀에서 AI PM을 운영하는 방식은 이렇다. AI PM이 앞의 네 칸짜리 서식(사건·원인·발동 조건·동작)으로 회고 초안을 매일 올린다. 사람 PM은 그 초안마다 세 칸짜리 판정을 단다. '규칙으로 걸자' / '이번만' / '규칙 불필요(우리 책임이 아님)'. 승격된 것만 길목에 걸리고, 나머지는 기록으로만 남는다. AI는 기록하고 집행하는 쪽, 사람은 무엇을 기억할 가치가 있는지 판단하는 쪽이다. 이 승인 절차가 제품의 핵심이라기보다, AI PM이 폭주하지 않게 붙잡아 두는 운영 장치에 가깝다.
이렇게 쌓인 규칙 묶음은 시간이 지나면 한 사람의 경험을 넘어선다. 사람 조직에서 늘 아쉬운 지점이 이거다. 일 잘하던 사람이 떠나면 그가 데인 기억도 같이 떠난다. 교훈이 글로 박혀 있으면, 담당자가 바뀌어도 지난 실수에서 나온 체크들은 그 자리에 남는다.
실수를 안 하는 매니저는 없다. AI든 사람이든. 그러니 "실수하지 않기"를 목표로 삼는 건 처음부터 지는 싸움이다. 목표는 다른 데 둬야 한다. 한 번 데인 자리에 다음번의 나를 위한 체크를 세워 두는 것, 그 체크가 다짐이 아니라 작동하는 규칙이 되게 하는 것, 그리고 규칙이 불어나지 않게 솎아내는 것. AI 프로젝트 매니저의 일머리는 이 세 가지에서 드러난다.
보통은 내부용입니다. 회고에는 어느 단계에서 어떻게 미끄러졌는지 같은 날것의 운영 기록이 담기기 때문에, 그대로 외부에 공개하기보다 사람 PM이 추려서 전달하는 편이 맞습니다. 다만 고객에게 직접 영향을 준 사건이라면, 무엇이 잘못됐고 어떻게 바로잡았는지는 투명하게 공유하는 게 신뢰 회복에 낫습니다. 기록 전체를 여는 것과, 그 기록에서 나온 결론을 공유하는 것은 다른 문제입니다.
쌓이다 보면 반드시 생깁니다. "빠르게 답하라"와 "확약 전에 반드시 조회하라"가 한 요청에서 부딪히는 식입니다. 이럴 때는 규칙마다 우선순위를 매겨 두는 게 현실적입니다. 보통 고객 신뢰나 데이터 손실을 막는 규칙이, 속도나 편의를 높이는 규칙보다 위에 옵니다. 충돌이 반복되는 두 규칙은 사람 PM이 다시 보고, 발동 조건을 더 좁혀 둘이 같은 길목에서 만나지 않게 다듬는 게 근본 해법입니다.
모든 실수를 기록하되, 규칙으로 승격하는 것만 따로 거릅니다. 기록과 규칙은 다른 층입니다. 기록은 일단 남겨 두는 원재료고, 규칙은 그중 '두 번 이상 반복됐거나, 한 번이어도 피해가 컸거나, 확인 비용보다 놓쳤을 때 손실이 큰' 것만 골라 길목에 거는 완제품입니다. 기록이 많은 건 괜찮습니다. 문제는 길목에 걸린 체크가 많은 것입니다. 이 둘을 섞지 않는 게 규칙 더미에 깔리지 않는 요령입니다.