AI 도입 실무 담당자가 단계마다 만들어야 하는 산출물

AI 에이전트 도입 단계를 밟는 담당자 손에 실제로 남는 문서는 아홉 개입니다. 그 개수를 정하는 것은 밟아야 할 단계의 수가 아니라, 문서 하나하나가 답해야 하는 판정 질문의 수죠. 확정하는 사람이 바뀌는 것은 그 질문이 바뀌었다는 표식이지 기준 자체는 아닙니다.

TF팀이 꾸려지고 2주 안에 비교 보고서를 내라는 지시가 떨어지면, 대개 후보 조사부터 시작합니다. 업체 자료를 모으고 기능을 나열하고 표를 그립니다. 그런데 표를 그리다 보면 열은 채워지는데 행이 비어 있습니다. 후보 정보는 넘치는데 우리 기준을 적을 칸에 쓸 것이 없죠.

모자란 것은 정보가 아니라, 그보다 앞에 놓였어야 할 문서죠.

AI 에이전트 도입 단계마다 문서를 몇 개 만들어야 하나요?

아홉 개이고, 그 수는 단계표가 아니라 문서가 답하는 판정 질문의 수에서 나옵니다. 한 질문을 여러 단계에 걸쳐 계속 묻는다면 문서는 하나로 버티고, 한 단계 안에서 물어야 할 것이 둘로 갈리면 문서도 둘이 됩니다.

실무에서 그 갈림을 먼저 알려 주는 표식은 확정하는 사람이 바뀌는 것입니다. 다만 표식은 기준이 아니어서, 이름이 바뀐 횟수만 세면 한 자리에서 문서가 하나 모자랍니다.

절차도의 화살표 개수는 문서 개수를 알려 주지 않습니다. 어느 칸에서 손을 떼도 되고 어느 칸에서 결재를 받아야 하는지가 그 그림에는 없으니까요.

문서는 절차를 기록하려고 만드는 물건이 아닙니다. 누군가에게 판정을 받으려고 만드는 물건이죠. 그래서 문서의 모양은 안에 담긴 내용이 아니라 그것을 받아 드는 사람이 정합니다. 같은 연동 요건을 우리 팀 회의록에 적을 때와 공급사에 넘길 때 문장이 달라지는 까닭도 그것입니다. 앞의 독자는 맥락을 이미 갖고 있고, 뒤의 독자는 그 문서만 갖고 있으니까요.

이 구분을 잡아 두면 두 가지 낭비가 함께 정리됩니다. 안 만들어도 될 문서를 만드는 시간, 그리고 승인자가 바뀔 때마다 같은 내용을 다시 쓰는 시간이죠.

단계와 산출물과 확정 주체를 한 표에 올리면 무엇이 보이나요?

표를 인쇄해 벽에 붙여 두고 매주 자기 줄을 짚는 팀이 있습니다. 지금 어느 줄에 서 있는지, 그 줄의 문서가 손에 있는지 두 가지만 확인하는 용도죠. 목록과 달리 표는 그것을 누가 받아 무엇을 닫는지까지 함께 보여 주거든요.

담당자가 하고 있는 일	손에 남는 문서	그 문서가 확정하는 것	확정하는 사람	비어 있을 때 먼저 되묻는 사람
업무를 세는 동안	업무 실측 기록	지금 무엇을 하루에 몇 번 하고 있는가	담당자 자신과 현업 실무자	당장은 아무도 없음
대상을 좁힌 뒤	대상 업무 정의서	이번에 손댈 업무와 이번에 빼는 업무	현업 부서장	견적을 요청받은 업체
후보를 견주는 동안	후보 비교표	어느 후보가 어느 항목에서 어떻게 읽히는가	TF팀과 결재선	보고 자리의 결재권자
후보를 좁힌 뒤	선정 근거	왜 그 항목에 그만한 무게를 두었는가	TF팀과 결재선	같은 자리의 결재권자
요건을 넘길 때	요건 정의서	무엇을 어디까지 만드는가	담당자와 공급사가 함께	개발에 들어간 공급사
착수 직전	성공 기준과 검증 계획	무엇이 되면 됐다고 하는가	결재선과 공급사 양쪽	검증 종료 회의의 참석자 전원
검증이 끝난 자리	판정 기록서	계속·중단·재설계 중 무엇인가	결재선	다음 예산 심의의 재무 담당
운영으로 넘길 때	예외 목록	못 넘긴 건을 누가 언제까지 받는가	현업 부서장	담당자가 자리를 비운 주의 동료
권한을 넘길 때	권한 대장	누가 그 계정을 끄고 되살릴 수 있는가	현업 부서장과 정보보안	인사이동을 통보받은 정보보안

아홉 줄 가운데 되묻는 쪽이 회사 밖에 있는 줄은 둘입니다. 견적을 받아 든 업체와 개발에 들어간 공급사죠.

이 둘에서는 문서가 비었을 때 되물음이 회의로 끝나지 않습니다. 사내 되물음은 자리를 한 번 만들면 메워지지만, 사외 되물음은 일정 조정이나 추가 견적으로 청구되거든요.

마지막 열이 첫 줄에서만 비어 있다는 점도 눈에 걸립니다. 되묻는 사람이 없으니 빠뜨려도 그 자리에서는 아무 일이 일어나지 않죠. 그런데 이 기록의 숫자를 요구하는 자리가 뒤에 셋 있습니다. 비교표의 기준 행, 성공 기준의 기준선, 판정 기록서가 결론과 나란히 적는 값. 셋 다 이 기록에 없는 숫자는 뒤늦게 지어낼 수 없습니다.

확정하는 것 열에서는 둘째 줄과 마지막 줄을 직접 맞대 보시면 됩니다. 둘째 줄은 대상을 고르는 어법이고 마지막 줄은 책임을 정하는 어법인데, 두 어법이 한 문서 안에 섞이면 문장이 흐려집니다. 대상을 고르던 어법으로 책임을 적으면 누가 무엇을 지는지가 남지 않고, 반대로 하면 첫 결정이 무거워져 진도가 나가지 않습니다.

아무도 승인하지 않는 첫 기록을 왜 먼저 남기나요?

뒤에 만들 문서들이 쓸 숫자가 여기서만 나오기 때문입니다. 승인받을 일이 없다는 점이 이 문서의 성격이자 함정이죠.

업무 실측 기록에 들어가는 것은 서술이 아니라 횟수입니다. 한 건을 넘기는 데 몇 분이 드는지, 하루에 같은 창을 몇 차례 오가는지, 같은 문구를 몇 번 옮겨 붙이는지.

며칠이면 모입니다. 사흘 치와 2주 치의 결론이 대체로 같은 자료라, 관찰 기간을 길게 잡아도 더 정확해지지 않거든요.

이 기록이 없으면 뒤에 만들 문서가 형용사로 채워집니다. “상당한 시간이 소요되고 있음”, “업무 부담이 큼” 같은 문장이죠. 이런 문장은 어느 결재선에서도 반박되지 않지만 어느 결재선도 통과시키지 못합니다.

숫자가 있으면 문장이 짧아집니다. 발주서 입력에 하루 2시간 40분, 그중 시스템 간 옮겨 적기가 1시간 10분. 여기서부터는 다음 문서를 쓰기가 수월해지죠.

세는 단위는 셋이면 충분합니다.

하루 몇 건인가 — 주나 월 단위로 세면 편차가 뭉개져 비교표의 기준 행에 올릴 수 없습니다.
한 건에 몇 분인가 — 시작과 끝을 어디로 잡았는지를 함께 적어야 두 사람의 값이 갈리지 않습니다.
그중 판단이 필요 없는 동작이 몇 분인가 — 옮겨 적기와 재입력처럼 사람이 고르지 않는 부분이 자동화가 가져가는 몫입니다.

셋째 단위를 빼면 뒤 문서들이 업무 전체를 대상으로 계산하게 됩니다. 그러면 검증 결과가 기대에 못 미치는 것처럼 읽히는데, 재는 대상이 처음부터 달랐다는 사정은 판정 회의에서 설명해도 잘 받아들여지지 않습니다.

기록을 남길 때 한 가지만 지키면 됩니다. 세는 사람과 그 업무를 하는 사람을 분리하는 것입니다. 자기 업무를 스스로 세면 습관이 된 동작은 세어지지 않고 불편한 동작만 크게 잡힙니다.

대상 업무 정의서는 무엇이 적혀야 부서장 손을 떠나나요?

이번에 뺄 업무가 이름으로 적혀 있어야 합니다. 무엇을 하겠다는 문장만 있는 정의서는 부서장이 승인해도 다음 자리에서 그대로 무효가 되죠.

정의서에 들어갈 항목은 넷입니다.

대상 업무의 이름 — 부서에서 부르는 이름으로 적어야 그 화면을 쓰지 않는 사람도 자기 업무로 읽습니다.
그 업무의 시작과 끝 — 앞뒤 업무와 맞닿는 지점이 흐리면 견적 범위가 함께 흐려집니다.
이번에 다루지 않을 인접 업무 — 적히지 않은 인접 업무는 공급사 쪽에서 범위 안으로 읽힙니다.
예외로 남길 유형 — 검증에서 실패로 셀 건과 셀 수 없는 건이 여기서 갈립니다.

이 가운데 셋째와 넷째가 실제로 일하는 항목이죠. 앞의 둘은 이견 없이 적히지만, 뒤의 둘은 적는 순간 누군가는 자기 업무가 이번 범위에서 빠졌다는 사실을 확인하게 되거든요. 부서장의 승인이 필요한 이유도 거기에 있습니다. 빼는 결정은 담당자 권한 밖이니까요.

아래 장면은 실재하는 회사의 기록이 아니라 여러 현장에서 되풀이해 본 모양을 하나로 묶은 것입니다. 발주서 입력을 대상으로 잡은 어느 유통사가 정의서에 “긴급 발주는 이번 범위에서 제외, 사람이 그대로 처리”라고 한 줄을 적었다고 해 봅시다. 이 한 줄이 뒤에서 세 번 일합니다. 견적 범위를 좁히고, 검증에서 실패로 셀 건을 가르고, 운영 시작 뒤 예외 목록의 첫 줄이 됩니다.

정의서가 부서장 손을 떠났다는 신호는 서명란이 아니라 그 부서 사람 누구에게 물어도 같은 답이 나오는 상태죠.

2주짜리 비교 보고서는 어디서 근거를 얻나요?

앞의 두 문서에서 얻습니다. 후보 조사에서 얻는 것은 열의 값이고, 행의 기준은 우리 문서에서만 나오죠.

비교 보고서가 2주 안에 안 끝난다면 조사량보다 기준을 먼저 보셔야 합니다. 기준이 정해지지 않으면 조사 범위가 닫히지 않기 때문입니다. 무엇을 볼지 정해져 있으면 후보 다섯 곳을 같은 양식으로 받는 데 며칠이면 되는데, 기준이 없으면 각 후보의 강점을 따라다니느라 표가 계속 넓어지죠.

제가 기업 교육 자리에서 도입 담당자들과 이 표를 같이 채워 보면, 막히는 칸이 늘 같은 자리에 몰립니다. 후보의 정보가 없어서 비는 칸이 아니라, 우리가 무엇을 요구하는지 적어 두지 않아서 비는 칸이죠. 그 칸을 앞의 두 문서에서 옮겨 오면 표는 대체로 그날 안에 닫힙니다.

행에 들어갈 기준은 실측 기록과 정의서에서 그대로 끌어옵니다. 처리 건수와 처리 시간, 연동해야 할 시스템 이름, 제외하기로 한 업무와 예외 유형. 여기에 우리 쪽 준비 조건을 하나 더합니다.

준비 조건 행은 비교표에 늦게 붙습니다. 후보가 우리에게 무엇을 언제까지 달라고 하는지를 적는 자리로, 담당자 참여 시간과 데이터 정비 몫이 들어갑니다. 이 행이 있으면 같은 기간의 제안이 서로 다른 무게로 읽히죠.

선정 근거는 표와 별개로 한 장 더 필요합니다. 표는 점수를 보여 주지만 왜 그 항목에 그만한 무게를 뒀는지는 보여 주지 못하니까요. 결재선에서 나오는 질문은 점수가 아니라 가중치를 향합니다.

표와 근거를 확정하는 사람은 같습니다. TF팀이 초안을 잡고 결재선이 닫는 자리가 두 문서 모두 같고, 비어 있을 때 되묻는 사람도 같은 결재권자죠. 그런데도 두 장으로 갈리는데, 표가 답하는 것은 어느 후보가 어느 항목에서 어떻게 읽히느냐이고, 근거가 답하는 것은 그 항목을 왜 그 무게로 두었느냐이거든요. 확정자가 한 번도 바뀌지 않았는데 문서가 하나 늘어난 자리가 여기입니다.

방식 자체가 갈리는 경우라면 표를 그리기 전에 한 단계를 더 거칩니다. 대상 업무가 규칙형인지 판단형인지를 보고 에이전트와 규칙 기반 자동화 중 어느 쪽에 맞는 일인지부터 갈라 두면 후보 목록 자체가 달라지죠.

보고서를 올린 뒤 결재선에서 자료를 더 요구받는다면 근거의 층위를 의심해 보실 만합니다. 임원 자리에서 결정을 실제로 바꾸는 데이터가 어떤 종류인지를 미리 맞춰 두면 왕복이 줄어듭니다.

사외로 넘어가는 첫 문서에서 무엇이 달라지나요?

읽는 사람이 우리 회사 맥락을 하나도 갖고 있지 않다는 전제가 붙습니다. 그래서 요건 정의서에서는 명사 나열이 조건문으로 바뀌죠.

사내 문서에는 “ERP 연동”이라고만 적어도 통합니다. 어느 ERP인지, 어느 화면인지, 누가 계정을 쥐고 있는지를 읽는 사람이 이미 알고 있으니까요. 같은 네 글자를 공급사가 받으면 견적이 몇 배로 갈립니다. 읽기 전용 조회와 쓰기 권한이 함께 필요한 작업이 같은 이름으로 묶이거든요.

요건 정의서에 들어가야 하는 것은 다섯 갈래입니다.

연동 대상 시스템과 그 안의 특정 지점 — 화면이나 인터페이스 단위까지 내려가야 공급사가 공수를 셉니다.
주고받을 데이터 항목 — 이름과 형식이 정해지면 검수 시점에 대조할 대상도 같이 정해집니다.
계정 권한의 범위 — 읽기까지인지 쓰기까지인지, 그리고 누가 발급하는지. 발급이 우리 쪽이면 일정에 우리 몫이 생깁니다.
데이터가 회사 밖으로 나가도 되는지 여부 — 나가면 안 되는 항목이 하나라도 있으면 구축 형태가 갈립니다.
처리하지 못한 건을 어떻게 되돌릴지 — 이 항목이 비면 운영을 시작한 뒤 예외 목록을 처음부터 만들게 됩니다.

마지막 갈래는 빠진 채로 넘어가기 쉽습니다. 만들 것을 적는 문서라고 생각하면 되돌리는 경로는 목록에 떠오르지 않으니까요.

이 문서가 특이한 점은 확정 주체가 우리 쪽 사람만이 아니라는 것입니다. 담당자가 쓰고 공급사가 읽어 확인하는 구조라, 한쪽이 서명한다고 닫히지 않죠. 닫혔는지는 되물음의 방향으로 압니다. 공급사가 “이건 어느 시스템 말씀이신가요”를 묻는 동안은 아직 열려 있고, “이 항목은 저희가 이렇게 이해했습니다”로 바뀌면 닫히는 중입니다.

성공 기준을 양쪽이 같은 문장으로 갖는다는 것은?

같은 판정 결과를 놓고 양쪽이 다른 결론을 낼 여지를 미리 없앤다는 뜻입니다. 요건 정의서를 아무리 촘촘히 써도 이 문서를 대신하지는 못하죠.

두 문서는 서로 다른 것을 닫습니다. 요건 정의서가 닫는 것은 만들 범위이고, 성공 기준이 닫는 것은 만들어진 것을 받아들일 선입니다. 닫는 사람도 갈립니다. 범위는 담당자와 공급사가 맞춰 닫지만, 받아들일 선은 결재선이 함께 앉아야 닫히거든요.

기준을 적을 때 걸리는 함정은 처리량으로만 적는 것입니다. 하루 몇 건을 처리한다는 문장은 도구의 성적을 재지만, 담당자가 그 결과를 몇 건이나 다시 확인하는지는 재지 못하니까요. 그래서 남는 일을 재는 항목이 함께 들어갑니다. 사람이 손대야 하는 건의 비율, 그 손질에 드는 시간, 실패한 건이 어디로 갔는지.

측정 방법도 같은 문서에 적힙니다. 무엇을 언제부터 언제까지 어느 기록으로 재는지가 없으면, 판정 회의에서 같은 숫자를 놓고 해석이 갈립니다.

값을 누가 제안하느냐는 문서에 적히지 않은 채 넘어가기 쉬운 부분입니다. 기준선은 우리 실측 기록에서 나오는 값이라 우리가 제안하고, 도달 가능한 폭은 상대가 제안하는 편이 자연스럽습니다. 반대로 되면 상대가 우리 업무를 모른 채 기준선을 잡거나, 우리가 상대 도구의 성능을 모른 채 폭을 정하게 되죠.

합의 문서라고 해서 양쪽이 반씩 쓰는 물건은 아닙니다. 초안은 담당자가 씁니다. 상대가 먼저 쓴 초안은 상대가 판정하기 쉬운 항목으로 채워지니까요.

검증 계획을 따로 떼어 놓지 않고 기준과 한 문서에 두는 편이 낫습니다. 기준만 있고 재는 방법이 없으면 판정 시점에 양쪽이 각자 유리한 기록을 들고 오게 되거든요.

검증이 끝난 자리와 운영으로 넘기는 자리에는 무엇이 남나요?

판정 기록서와 예외 목록, 그리고 권한 대장이 남습니다. 앞의 것은 결재선을 향하고 뒤의 둘은 현업을 향하는데, 향하는 사람이 다르니 세 문서의 길이와 용어 수위가 크게 갈리죠.

판정 기록서에는 결론과 그 결론을 만든 값이 함께 들어갑니다. 계속·중단·재설계 중 무엇으로 판정했는지, 어떤 값이 그렇게 읽혔는지, 그리고 판정 시점에 비어 있던 값이 무엇인지.

마지막 항목은 빠뜨리기 쉽습니다. 재보지 않은 것을 적어 두는 일이 마무리처럼 느껴지지 않으니까요. 그런데 다음 예산 심의에서 재무가 되묻는 자리가 바로 거기입니다. 조건이 적혀 있으면 추가 예산 요청의 근거가 되고, 없으면 다시 검증부터 하자는 답이 돌아옵니다.

사업성 문서를 따로 만들어야 하는 국면이라면 판정 기록서가 그 원자료가 됩니다. 결재선에 올릴 사업성 문서를 어떤 항목으로 세우는지는 이 기록의 어느 값을 끌어 쓸지를 정해 주죠.

예외 목록은 성격이 다릅니다. 읽는 사람이 결재권자가 아니라 내일 아침 그 업무를 하는 사람이니까요.

여기 들어갈 것은 세 줄입니다.

못 넘긴 건이 어느 대기함으로 밀리는지 — 대기함을 열지 못하는 사람에게는 목록이 없는 것과 같습니다.
몇 시간 안에 누가 그것을 집어 가는지 — 이름만 있으면 휴가에서 끊기고, 시간만 있으면 아무도 자기 일로 읽지 않습니다.
이상 동작이 보일 때 정지 권한이 누구에게 있고 정지 사실을 어디에 남기는지 — 정지는 권한을 가진 사람이 아니라 그 자리에 있는 사람이 하게 됩니다.

권한 대장을 갈라 두는 이유는 확인하는 사람이 다르기 때문입니다. 예외 목록은 부서장 선에서 닫히지만, 권한 대장은 정보보안 담당의 확인을 함께 받습니다. 에이전트가 쥔 계정 권한은 퇴사나 인사이동으로 정리되지 않아, 대장이 없으면 몇 달 뒤 그 소유자를 대지 못합니다.

문서가 갈리는 자리를 무엇으로 알아보나요?

판정 질문이 바뀌었는지를 봅니다. 확정하는 사람이 바뀌는 것은 그 질문이 바뀌었다는 표식이지, 그 자체가 기준은 아니죠.

표식만 세면 어떻게 되는지는 앞의 표에 그대로 나와 있죠. 확정하는 사람 칸이 바로 위 줄과 달라지는 자리는 일곱 번입니다. 이동 횟수에 처음 하나를 더하면 여덟인데, 손에 남는 문서는 아홉이죠. 한 자리에서 이름이 그대로인 채 문서가 갈라졌기 때문입니다.

눈에 보이는 신호	실제로 벌어지는 일	문서가 갈리나
확정하는 사람이 바뀌었다	정의서를 부서장이 닫고, 비교표를 결재선이 닫는다	갈린다 — 묻는 것이 함께 바뀌었다
사람은 같은데 묻는 것이 바뀌었다	후보 비교표와 선정 근거를 같은 TF팀과 결재선이 닫는다	갈린다 — 무엇을 골랐나와 왜 그 무게였나는 다른 질문이다
사람은 바뀌었는데 묻는 것이 같다	부서장이 닫은 정의서에 임원 결재란이 하나 붙는다	갈리지 않는다 — 결재란만 늘어난다
문서를 받을 상대가 사외로 나갔다	같은 내용을 공급사가 착수 입력으로 요구한다	갈린다 — 맥락 없는 독자가 생겼다

둘째 줄이 표식으로는 셀 수 없는 자리입니다. 후보 비교표와 선정 근거는 확정하는 사람이 같고 되묻는 사람까지 같은데도 두 문서로 갈리죠. 그러니 이름이 바뀐 횟수만 세면 이 자리에서 하나가 빠집니다.

셋째 줄은 반대쪽으로 어긋나는 경우입니다. 결재란이 늘어난 것을 새 문서로 착각하면 같은 내용을 두 벌 관리하게 되는데, 두 벌이 되면 어느 시점엔가 서로 어긋납니다. 넷째 줄은 두 축이 함께 움직이는 경우라 표식이 어긋나지 않습니다. 다만 여기서도 문서를 가르는 것은 상대의 직급이 아니라 그 상대가 맥락을 갖고 있지 않다는 사실이죠.

정리하면 순서는 이렇습니다. 표식을 먼저 보고 질문으로 확인하는 편이 빠르되, 세는 것은 표식이 아니라 질문입니다.

이 구분이 담당자에게 주는 실익은 문서 수를 줄이는 데 있지 않습니다. 지금 쓰고 있는 문서가 어느 질문에 답하는 물건인지 알면, 그 문서에 넣지 않아도 될 내용이 함께 걸러지거든요. 질문 하나를 겨냥한 문서는 두세 장에서 닫히고, 여러 질문을 한 문서에 담으면 스무 장이 되어도 어느 질문에도 확실히 답하지 못합니다.

결재가 늦어지는 이유를 조직 문제로 돌리기 전에 그 문서가 몇 개의 질문을 안고 있는지부터 세어 보시면 답이 나오는 자리가 있죠.

질문을 세는 일이 곧 문서를 세는 일입니다.

문서가 비면 통합 시점에 무엇이 사라지나요?

대조할 원본이 사라집니다. 기대는 회의에서 말로 오가는데, 문서가 없으면 나중에 그 기대가 어디까지였는지 확인할 자리가 남지 않죠.

가트너가 2026년 4월 7일에 내놓은 조사 결과가 그 지점을 건드립니다. 인프라·운영(I&O) 책임자 782명에게 물었고, 응답을 받은 시기는 그보다 앞선 2025년 11월에서 12월 사이였죠. AI를 운영 시스템에 붙이다가 실패한 적이 한 번이라도 있다고 답한 비율은 57%였고, 조사는 그 흔한 원인으로 과도한 기대를 지목했습니다.

여기서 눈여겨볼 것은 비율의 크기보다 원인의 성격입니다. 과도한 기대는 기술 결함이 아니라 합의의 문제이고, 합의는 문서에만 남습니다.

경로를 따라가 보면 이렇습니다. 착수 회의에서 “이 정도는 자동으로 되겠죠”가 오갑니다. 아무도 반대하지 않았으니 합의처럼 남죠. 요건 정의서에 그 문장이 조건으로 옮겨 적히지 않으면, 통합 시점에 그것은 요구사항이 아니라 인상으로만 존재합니다.

그때 벌어지는 일은 다툼이라기보다 재작업입니다. 양쪽 다 자기 기억이 맞다고 여기고, 남은 기록이 없으니 판정할 근거도 없어 결국 다시 만드는 쪽으로 갑니다.

문서가 있다고 기대 어긋남이 없어지지는 않습니다. 다만 어긋남이 드러나는 시점이 통합 이후에서 착수 전으로 당겨지죠. 그 시점 차이가 재작업 비용의 대부분을 가릅니다.

기대를 문서로 옮길 때 쓸 만한 방법이 하나 있습니다. 회의에서 나온 “이 정도는 되겠죠”를 그대로 적지 말고, 되면 어떻게 확인할지를 붙여 다시 적어 보는 것입니다. 확인 방법이 붙지 않는 기대는 요구사항이 아니라 바람입니다.

같은 문서를 고쳐 쓸 때는 무엇을 남기나요?

어느 판을 근거로 무엇이 확정됐는지를 남깁니다. 바뀐 내용만 반영하고 앞 판을 지워 버리면, 그 판을 근거로 난 결재가 근거를 잃죠.

아홉 개 문서는 한 번에 완성되지 않습니다. 대상 업무 정의서는 견적을 받아 보고 한 번, 검증 중에 예상 못 한 예외가 나와서 또 한 번 고쳐지는 식이죠.

고칠 때 붙일 것은 세 줄이면 됩니다. 고친 날짜, 고치게 만든 되물음이 공급사와 결재선과 현업 가운데 어디서 왔는지, 이번 개정을 확정한 사람.

가운데 줄이 실제로 일합니다. 몇 달 뒤 같은 논점이 회의에 다시 올라올 때, 그것이 이미 판정된 질문인지 새 질문인지를 그 한 줄이 가르거든요. 이유 없이 결과만 고쳐진 문서는 시간이 지나면 왜 그렇게 정해졌는지 아무도 대지 못하게 됩니다.

개정이 문서로 돌아오지 않는 자리는 요건 정의서에 몰립니다. 개발이 시작되면 변경이 메신저와 통화로 오가고, 그 합의가 문서로 돌아오지 않으면 검수 시점에 요건이 두 벌이 되죠. 되돌리는 일은 담당자 몫으로 남습니다. 공급사는 자기 작업 목록에 반영하면 그만이지만, 판정 근거를 쥐고 있어야 하는 쪽은 우리니까요.

형식만 남은 문서는 어떻게 가려내나요?

갱신 이력을 봅니다. 만든 날짜만 있고 고친 날짜가 없다면, 그 문서는 만들 때 한 번 읽히고 그 뒤로 열리지 않았다는 뜻이죠.

살아 있는 문서에는 흔적이 남습니다. 확인할 자리는 셋이죠. 누군가 그 문서를 근거로 무언가를 거절한 적이 있는지, 내용이 바뀔 때 실제로 고쳐졌는지, 그리고 새로 온 사람이 그 문서를 먼저 받는지.

저는 도입이 끝난 회사를 다시 방문하면 예외 목록부터 펼쳐 봅니다. 줄이 늘고 있으면 운영이 돌아가는 중이고, 처음 만든 몇 줄 그대로면 예외가 목록 밖에서 처리되고 있을 때가 많거든요. 뒤쪽이면 담당자가 바뀔 때 그 처리 방식이 함께 사라집니다.

형식만 남는 문서에는 공통점이 있습니다. 확정할 사람을 정하지 않고 만든 문서라는 점입니다. 누가 받아 무엇을 판정하는지가 없으면 문서는 보관용이 되고, 보관용 문서는 내용이 바뀌어도 고쳐지지 않죠.

반대로 확정자가 분명한 문서는 스스로 짧아집니다. 부서장이 읽을 정의서에 기술 사양을 길게 적을 이유가 없으니까요. 문서를 줄이려면 항목을 지우는 것보다 확정자를 먼저 지정하는 편이 빠릅니다. 받는 사람이 정해지면 그 사람이 판정에 쓰지 않을 내용은 자연히 빠집니다.

지금 비어 있는 칸부터 채우려면

물어볼 것은 하나면 됩니다. 지난 2주 동안 누가 우리에게 무엇을 되물었습니까.

되물은 쪽이 사내라면 앞쪽 넷 가운데 하나가 비어 있습니다. 결재권자가 “왜 이 회사인가”를 물었다면 선정 근거, 후보를 어떻게 좁혔느냐를 물었다면 비교표의 기준 행, 부서장이 자기 업무의 포함 여부를 물었다면 정의서의 제외 항목, 숫자의 출처를 물었다면 업무 실측 기록이죠. 넷 다 우리 손으로 닫을 수 있어 늦어도 며칠이면 메워집니다.

되물은 쪽이 계약 상대라면 가운데 문서 차례입니다. 업체가 견적 범위를 되물으면 대상 업무 정의서, 개발 중 확인 요청이 잦으면 요건 정의서의 다섯 갈래 가운데 빠진 갈래가 있고, 판정 회의가 해석 논쟁으로 흐르면 성공 기준의 측정 방법 항목이 비어 있습니다.

되물은 사람이 내일 그 업무를 하는 동료라면 마지막 두 문서 차례입니다. 오픈한 뒤에도 담당자 손이 더 가고 있다면 예외 목록이, 계정 권한을 누가 쥐고 있느냐는 물음이 나왔다면 권한 대장이 비어 있습니다.

지목된 문서 하나만 만들면 됩니다. 나머지를 앞당길 이유는 없습니다. 확정할 사람이 아직 등장하지 않은 문서는 미리 만들어 두어도 그 사람이 나타날 때 다시 쓰게 되니까요.

비교 보고서 제출까지 시간이 얼마 없는 상태라면 순서를 조정할 여지도 있습니다. 어느 문서를 먼저 세워야 보고서가 닫히는지 한 번 맞춰 보실 생각이라면, 지금 손에 쥔 자료와 남은 기간을 도입 문의로 보내 주십시오. 문서를 대신 써 드리는 자리가 아니라 무엇부터 채울지 정하는 자리로 씁니다.

자주 묻는 질문

아홉 개를 순서대로 만들어야 하나요, 병행해도 되나요?

앞 문서의 값이 뒤 문서의 입력이 되는 구간만 순서가 걸립니다. 업무 실측 기록에서 정의서, 거기서 비교표의 기준 행으로 이어지는 앞쪽 셋이 그 구간이라 건너뛰면 뒤에서 값이 빕니다. 반대로 성공 기준의 초안은 요건 정의서와 나란히 쓰면 만들 범위와 받아들일 선이 어긋나는 지점이 일찍 보입니다.

공급사가 문서 양식을 제공하겠다고 하면 그대로 써도 되나요?

요건 정의서와 검증 계획은 양식을 받아 쓰셔도 됩니다. 다만 대상 업무 정의서와 판정 기록서는 우리 쪽에서 만드시는 편이 낫습니다. 앞의 둘은 공동 확정 문서라 상대 양식이 오히려 소통을 줄이지만, 뒤의 둘은 우리가 상대를 판정하는 근거라 양식을 받는 순간 판정 항목까지 상대가 정하게 되니까요.

이미 절반쯤 진행된 프로젝트인데 지금 문서를 만들면 늦었나요?

지난 자리의 문서는 소급해 만들지 않으셔도 됩니다. 지금 열려 있는 판정 질문에 해당하는 문서 하나만 만들면 됩니다. 다만 앞 문서에서 나왔어야 할 숫자가 비어 있으면 그 값은 채우고 가야 하는데, 업무 실측은 지금 며칠 세어도 늦지 않습니다.

문서 승인을 이메일 회신으로 받아도 되나요?

받을 수 있습니다. 확인할 것은 형식이 아니라 회신에 무엇이 적혔는가입니다. “확인했습니다” 한 줄은 나중에 무엇을 확인했는지 알려 주지 못하니, 본문에 확정 항목을 요약해 붙이고 그 요약에 대한 회신을 받으시면 됩니다.

두 문서를 하나로 합쳐도 되는 경우가 있나요?

있습니다. 대표가 부서장과 결재권자를 겸하는 조직에서는 정의서와 선정 근거가 한 문서로 붙기도 합니다. 두 판정이 같은 사람 손에서 연달아 닫히니 갈라 둘 실익이 없죠. 합칠 때는 절을 나눠 두시길 권합니다. 공급사에 넘길 부분과 사내에만 둘 부분이 한 덩어리로 섞이면 그때 다시 갈라야 하거든요.

산출물을 다 갖추면 도입이 실패하지 않나요?

그렇게 보기는 어렵습니다. 문서는 판정을 가능하게 하는 물건이지 결과를 정하는 물건이 아니고, 대상 업무 선정이 어긋나면 문서가 아무리 정연해도 결론은 바뀌지 않습니다. 문서가 하는 일은 어긋남을 일찍 드러내고 되돌릴 지점을 남기는 것까지입니다.

참고 자료

자사 관찰 기록(2026년 시점·익명 집계) — 필자가 도입 담당자 교육 자리와 도입 완료 기업 재방문에서 본 문서 실태: 비교표에서 비는 칸이 후보 정보 부족보다 자체 기준 문서 부재에서 오며, 예외 목록의 줄 수가 늘지 않는 곳에서는 예외가 목록 밖에서 처리되는 경우가 잦다. 관찰 범위 안의 서술이며 특정 기업의 사례를 가리키지 않는다
가트너(Gartner), “Gartner Says AI Projects in I&O Stall Ahead of Meaningful ROI Returns” — 인프라·운영(I&O) 책임자 782명 대상 조사이며, 응답 수집은 2025년 11월~12월·발표는 2026년 4월 7일. 인용 범위는 실패 1회 이상 경험 비율 57%와 그 흔한 원인으로 지목된 과도한 기대 두 항목(2026-08-27 확인): https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-says-artificial-intelligence-projects-in-infrastructure-and-operations-stall-ahead-of-meaningful-roi-returns

작성자

유수호 — 하마다랩스 윈디플로 에반젤리스트이자 한양대학교 ERICA 겸임교수. 기업 교육 강사로 업종마다 다른 도입 양상과 되돌아오는 실패 지점을 다루며, 도입 현장에서 담당자가 실제로 남기는 문서와 그 문서가 결재선에서 읽히는 방식을 살핍니다. 프로필: https://www.linkedin.com/in/수호-유-852852258/