ISO 21500의 39개 프로세스는 AI가 외울 표가 아니라 입력을 확인하는 점검표입니다

공공기관의 정보시스템 구축 사업을 수주한 뒤 프로젝트 관리를 AI에게 맡기기 시작하면 첫 주는 산출물의 속도에 놀랍니다. 계약 뒤 첫 공식 보고를 앞두고 “이 사업 리스크 분석해 줘”라고 하면 1분 만에 리스크 열두 개가 등급과 대응 방안까지 붙어 나옵니다. 그런데 그 보고 자리에서 발주처(사업을 맡긴 기관) 담당자가 “이 리스크는 어디서 나온 거죠”라고 물으면 대답이 막힙니다. 발주처가 낸 요구 문서와 우리가 낸 제안서, 계약서는 있었지만, 그것들을 맞춰 무엇을 어디까지 만들지 우리가 확정해 적은 범위기술서는 아직 없었습니다. AI는 공공 SW 사업이 흔히 겪는 리스크를 그럴듯하게 써 준 것이었습니다.

이 장면은 설명을 위해 만든 가상의 수주사(사업을 따낸 회사) 이야기입니다. 특정 회사나 사업의 기록이 아닙니다. 공공 사업이 아니어도 같습니다. 고객이 준 요구, 우리가 한 약속, 고객이 정해 준 범위라는 세 문서는 있는데, 그 셋을 맞춰 우리가 확정해 적은 범위기술서는 없는 일이면 어디든 같은 자리가 있습니다. 혼자 일하는 프리랜서라면 고객의 의뢰 메일이 요구이고, 견적서가 약속이고, 발주를 확정한 메일이 고객이 정해 준 범위입니다. 그 셋을 맞춰 내가 적는 작업 명세가 범위기술서이고, 메일로 받은 것도 저장해 두면 파일입니다.

이 글의 결론은 하나입니다. AI에게 프로젝트 관리를 맡기려면 프로세스 이름만 주고 “리스크 분석해 줘”라고 시킬 것이 아니라, 프로세스마다 들어가야 할 입력 문서가 실제로 있는지 확인하는 점검표로 표준의 목록을 써야 합니다. 입력이 있는 프로세스는 AI에게 초안을 맡기고, 입력이 없는 프로세스는 산출물이 아니라 입력부터 만들고, 승인이 들어가는 프로세스는 사람이 쥡니다.

프로젝트 관리의 국제 표준인 ISO 21500은 2012년 판에서 프로젝트 관리를 두 축으로 나눕니다. 가로는 5개 프로세스 그룹(process group)으로 착수, 기획, 실행, 통제, 종료이고, 세로는 10개 주제 그룹(subject group)입니다. 두 축이 만나는 격자에 39개 프로세스가 놓입니다. 이 글은 이 격자로 설명하고, 흔히 듣는 다른 숫자와 그 뒤 판본 이야기는 두 번째 파트에서 한 번에 짚습니다. 프로세스 이름은 제가 짧게 옮긴 것이라 공식 한국어 명칭과 다를 수 있습니다.

리스크 열두 개가 어디에나 있는 리스크인 이유는 입력이 없어서입니다

직원 서른 명 규모의 SW 회사가 공공기관의 정보시스템 구축 사업을 수주했다고 해 봅시다. 프로젝트 관리자(PM) 한 사람이 AI 하나를 옆에 두고 일합니다. 계약 다음 날 PM이 AI에게 리스크 분석을 시켰고, 열두 개가 나왔습니다. ‘발주처 요구 변경 빈발’, ‘핵심 인력 이탈’, ‘연계 기관 데이터 지연’ 같은 항목입니다. 틀린 말은 하나도 없습니다. 어느 공공 SW 사업에나 있는 리스크이기 때문입니다.

표준은 리스크 찾기 프로세스를 기획 그룹에 둡니다. 같은 기획 그룹에 범위 정하기와 작업분류체계(WBS, Work Breakdown Structure, 일을 관리 가능한 단위로 쪼갠 표) 만들기가 있습니다. 리스크 찾기는 이 둘의 산출물을 입력으로 받습니다. 뒤 프로세스는 앞 프로세스의 산출물을 읽어야 제대로 돌아갑니다. 수주사의 손에는 네 문서가 있습니다. 발주처가 낸 제안요청서(RFP)는 요구이고, 우리가 낸 제안서는 하겠다고 쓴 약속입니다. 계약서는 이 사업을 시작한다는 공식 합의이고, 계약 뒤 받은 과업지시서(수주사가 해야 할 일을 발주처가 적어 준 문서)는 발주처가 정해 준 범위입니다. 요구와 약속과 정해 준 범위는 서로 조금씩 다르고, 그 차이를 맞춰 ‘무엇을 어디까지 만들기로 확정했나’를 우리가 적은 문서가 범위기술서(scope statement)입니다. 범위기술서가 있으면 ‘이 사업에만 있는 리스크’가 나옵니다. 없으면 ‘세상 모든 사업의 리스크’가 나옵니다. 그 열두 개는 입력이 없어서 나온 결과입니다.

사람이 할 때는 비어 있어도 티가 나지 않았습니다

같은 자리에 사람이 있었다면 어땠을까요. 경험 있는 PM은 리스크를 적기 전에 “과업 범위를 발주처와 아직 못 맞췄는데요”라고 되묻거나, 보고 자료를 만들며 머릿속으로 좁힌 범위를 가지고 리스크를 적습니다. 문서가 없어도 머리에 있었고, 모호하면 물었습니다. 그래서 여러 프로세스가 입력 문서 없이 비어 있어도 프로젝트는 돌아갔고, 표준을 ‘문서 많이 만드는 절차’ 정도로 가볍게 보는 사람도 많았습니다.

AI는 두 가지가 동시에 없습니다. 머릿속 범위가 없고, 따로 시키지 않으면 되묻지 않습니다. 되묻게 시킬 수는 있습니다. 그런데 무엇이 비었는지 모르는 AI는 되묻는 질문도 일반론으로 만듭니다. 비었다는 사실을 아는 쪽은 입력을 확인한 사람입니다. 입력이 비어 있으면 AI는 그 자리를 가장 그럴듯한 일반론으로 채우고 결과를 돌려줍니다. 결과의 모양은 완성품과 똑같아서, 받는 사람이 입력을 확인해 보지 않으면 발명된 것인지 도출된 것인지 구별할 수 없습니다. 표준이 틀린 것이 아닙니다. 표준은 사람을 전제로 쓰였고, 그 전제에서 느슨해도 괜찮았던 자리가 수행자가 바뀌자 그대로 비용이 된 것입니다.

격자는 순서표가 아니라 분류표입니다

가로축인 다섯 프로세스 그룹은 한 번 지나가는 달력이 아닙니다. 실행과 통제는 프로젝트가 끝날 때까지 오가고, 통제가 어긋남을 찾으면 기획으로 되돌아갑니다. 순서는 칸의 위치가 아니라 입력과 산출물의 연결에서 나옵니다. 세로축인 열 개 주제 그룹은 통합, 이해관계자, 범위, 자원, 시간, 원가, 리스크, 품질, 조달, 의사소통입니다. 자기 일을 격자에 놓는 방법은 두 질문입니다. 지금 사업의 어느 시점인가, 그리고 지금 무엇을 다루고 있나. 두 답이 만나는 칸에 지금 하는 프로세스가 있습니다.

한 칸에 프로세스가 여럿 있을 수 있으므로, 입력을 확인하는 일은 칸이 아니라 프로세스 하나마다 합니다. 이 글에서 우리 사업에서 실제로 쓰는 프로세스를 켜진 칸이라고 부르겠습니다. 어느 칸이 켜지는지는 사업의 크기와 계약 형태가 정합니다. 외부 업체가 없으면 조달 줄이 통째로 꺼지고, 팀이 한 사람이면 자원 줄 대부분이 꺼집니다. 그것은 결함이 아니라 정상입니다.

격자에서 읽을 것은 세 가지입니다. 기획이 16개로 가장 두껍습니다. 모든 시점에 걸치는 주제는 통합 하나뿐이고, 나머지 아홉을 한 프로젝트로 묶는 일이 통합입니다. 착수에는 헌장(project charter, 프로젝트를 시작하도록 승인하고 PM에게 권한을 주는 문서) 만들기 말고도 이해관계자 찾기와 팀 꾸리기가 있습니다. 표준은 무엇을 할지만큼 누구와 할지를 먼저 정하라고 봅니다.

그러면 각 프로세스의 입력은 어디서 찾을까요. 입력은 그 프로세스가 읽어야 할 문서이고, 대개 같은 주제 그룹에서 바로 앞 칸의 산출물이거나 범위 그룹이 만든 범위기술서와 WBS입니다. 표준은 프로세스마다 주요 입력과 산출물을 표로 적어 두었습니다. 원문은 ISO와 한국표준협회에서 판매하는데, 원문이 없어도 같은 주제 줄에서 바로 앞 칸의 산출물을 입력으로 잡으면 대부분 맞습니다. 자주 쓰는 프로세스 일곱 개를 그 방식으로 정리하면 아래와 같습니다. 수주사라면 헌장 자리에 계약서가 옵니다.

판본과 다른 숫자 이야기를 여기서 한 번만 하겠습니다. 흔히 듣는 ‘5개 단계, 10개 지식 영역, 49개 프로세스’는 미국 PMI(프로젝트 관리 협회)가 펴내는 PMBOK 가이드 6판의 숫자입니다. 그 뒤 7판과 8판은 구조를 바꿨으므로 이 비교는 6판까지만 말합니다. ISO 쪽은 39개이고, 지식 영역 대신 주제 그룹이라는 이름을 씁니다. 그리고 2012년 판은 지금 현행이 아닙니다. 2021년 판은 프로세스 표 대신 개념과 맥락만 다루고, 실무 지침은 ISO 21502:2020으로 옮겨 갔습니다. 21502는 격자 대신 실무 지침으로 짜여 있고, 조직이 규모에 맞게 실무를 골라 쓰는 테일러링(tailoring, 표준을 프로젝트 상황에 맞게 덜어 내는 일)을 전제로 합니다. 그래도 이 글이 39개 격자를 쓰는 이유는 켜진 칸이 어디인가를 한 장에서 보기에 이 격자가 가장 알기 쉽기 때문입니다.

AI에게 넘기면 다섯 그룹이 세 종류로 갈립니다

같은 격자를 ‘AI에게 맡기면 어떻게 되나’라는 눈으로 다시 보면 프로세스가 세 종류로 나뉩니다. 기준은 그 프로세스의 결과가 문서인가, 결정인가, 사람의 행동인가입니다. 문서 프로세스도 초안이 문서가 되려면 마지막에 사람의 승인을 거칩니다. 도입에서 말한 ‘승인이 들어가는 프로세스’는 그 마지막 승인과 변경 승인 둘 다를 말합니다. 그룹 단위로 말하면 대략 다음과 같고, 정확히는 프로세스마다 결과물로 판단합니다.

기획 16개는 결과가 문서인 프로세스입니다. 범위기술서, WBS, 일정, 예산, 리스크 등록부, 품질 계획, 의사소통 계획이 여기서 나옵니다. 문서 초안을 만드는 일은 AI가 가장 쓸모 있는 일이고, 조건은 하나입니다. 그 프로세스의 입력이 파일로 있어야 한다는 것입니다. 착수의 헌장과 이해관계자 목록도 문서이지만, 그것을 승인하고 관계를 맺는 일이 핵심이라 세 번째 종류인 행동에 둡니다.

통제 11개는 결정으로 끝나는 프로세스입니다. 기준선과 실적을 대조해 편차를 세고 변경 요청을 만드는 일까지는 AI가 잘합니다. 그러나 편차를 보고 ‘범위를 바꿀 것인가, 일정을 늦출 것인가, 그대로 갈 것인가’를 정하는 변경 통제(change control)는 승인입니다. 표준은 변경 통제를 통제 그룹의 프로세스로 두고, 변경 요청이 승인을 거쳐 반영되도록 합니다. AI가 편차표를 만들고 사람이 승인을 하는 구조여야 기준선이 기준선으로 남습니다.

착수 3개, 실행 7개, 종료 2개는 결과가 사람의 행동인 프로세스입니다. 헌장을 승인하고 PM에게 권한을 주는 일, 이해관계자를 찾아 관계를 맺는 일, 팀을 꾸리고 키우는 일, 작업을 지휘하고 공급자를 고르는 일은 조직 안의 사람 사이에서 일어납니다. AI는 헌장 초안을 쓰고 회의 자료를 준비할 수는 있지만, 승인하거나 사람을 움직일 수는 없습니다. 그룹 단위로 묶었으니 예외가 있고, 여기에 모아 둡니다. 실행의 리스크 대응과 품질 보증, 정보 나누기와 종료의 교훈 모으기는 결과가 문서에 가까워 AI가 자료를 만들 수 있고, 통제의 팀 관리는 결정보다 사람의 행동에 가깝습니다. 예외가 있어도 기준은 같습니다. 결과가 문서면 입력을 확인하고 AI에게 맡기고, 결정이면 사람이 하고, 행동이면 AI는 자료만 돕습니다. 교훈 모으기의 조건은 앞과 같습니다. 통제에서 편차와 결정이 파일로 남아 있었다면 AI가 교훈을 모을 수 있고, 머릿속과 회의에만 있었다면 모을 것이 없습니다.

도입에서 말한 세 갈래와 이 세 종류는 이렇게 맞물립니다. 문서 프로세스가 ‘입력 있음’과 ‘입력 없음’으로 갈리고, 결정 프로세스가 ‘승인’입니다. 행동 프로세스는 처음부터 AI에게 맡길 일이 아니라서 도입의 세 갈래에 넣지 않았습니다.

점검표의 원리는 한 문장이고, 장면에서는 순서가 바뀝니다

위 수주사로 돌아가 보겠습니다. PM은 AI에게 리스크를 다시 시키는 대신 격자를 다른 눈으로 봤습니다. 외워야 할 39개 프로세스가 아니라, 프로세스마다 “이 프로세스의 입력 문서가 파일로 있나”를 묻는 점검표로 본 것입니다. 한 문장으로 쓰면 이렇습니다. 입력이 있는 프로세스만 AI에게 시키고, 없으면 입력부터 만들고, 승인은 사람이 한다.

이 눈으로 보면 리스크 열두 개의 문제가 분명해집니다. 리스크 찾기의 입력인 범위기술서와 WBS가 없는 상태에서 산출물을 먼저 시킨 것입니다. 순서를 바꾸면 됩니다. 범위 정하기의 입력인 계약서와 제안요청서, 과업지시서를 주고, 제안서는 우리가 한 약속을 맞춰 보는 참고로 붙여, 범위기술서 초안을 먼저 쓰게 합니다. PM이 그 초안의 내용을 발주처 담당자와 맞춘 뒤 PM이 승인하고, 그 범위기술서로 WBS 초안을 만들게 하고, 그다음에 리스크를 시킵니다. 그때 나오는 리스크는 ‘이 사업의 리스크’입니다.

언제부터 점검표가 필요한가의 기준은 하나입니다. 한 프로세스의 산출물이 다른 프로세스의 입력으로 넘어가는가입니다. 하루짜리 단발 작업처럼 입력이 하나뿐이고 결과를 바로 사람이 쓰면 머릿속 점검으로 충분합니다. 혼자 하는 프로젝트라도 범위기술서가 WBS와 리스크 등록부로 흘러 들어가는 순간부터는 점검표가 필요합니다.

마치며: ‘프로세스를 외운 AI’가 아니라 ‘입력이 있는 프로세스’

AI에게 프로젝트 관리를 맡기는 방법은 AI에게 프로세스 이름을 주고 시키는 것이 아니라, 그 격자를 프로세스마다 입력이 있는지 확인하는 점검표로 바꾸고, 승인이 들어가는 프로세스를 사람이 쥐는 것입니다. 표준은 사람끼리 일할 때 느슨해도 괜찮았던 입력을 적어 두었고, AI는 그 느슨함을 비용으로 바꿔 돌려줍니다.

오늘 해 볼 일은 하나입니다. 지금 AI에게 맡기려는 프로젝트 관리 일 하나를 골라 위 격자의 어느 칸인지 두 질문으로 놓아 봅니다. 그다음 일곱 줄 표의 방식대로 그 프로세스의 앞 산출물이 무엇인지 적고, 그 입력 문서의 파일 이름을 한 줄 적어 보시길 권합니다. 파일 이름이 떠오르지 않으면 그 프로세스는 오늘 AI에게 시킬 자리가 아니라 사람이 먼저 채울 자리입니다. 혼자 하는 프로젝트라면 켜진 칸이 범위 정하기, 일정 만들기, 리스크 찾기 셋뿐일 수 있는데, 질문은 같습니다.

이 글은 AI의 도움을 받아 작성했습니다.

참고 자료

1. ISO 21500:2012 Guidance on project management: https://www.iso.org/standard/50003.html
2. ISO 21500:2021 Project, programme and portfolio management, Context and concepts: https://www.iso.org/standard/75704.html
3. ISO 21502:2020 Project, programme and portfolio management, Guidance on project management: https://www.iso.org/standard/74947.html
4. PMBOK Guide 6th edition, Project Management Institute: https://www.pmi.org/standards/pmbok