프로젝트가 마무리에 가까워질수록, 우리는 종종 ‘생산해야 할 결과물은 이미 모두 만들었다’고 생각하기 쉽다. 범위 정의에 따른 핵심 산출물, 일정 관리를 통한 중간 마일스톤에 도달하며 만든 산출물, 비용 관리와 품질 관리의 체계를 갖추어가며 발생하는 산출물 등 수많은 문서와 업무 산출물을 모았다면, 그 프로젝트는 이미 완성에 가까워 보인다. 그러나 실무 현장에서 실제로 프로젝트를 종료하려 할 때 ‘예상치 못한 문서나 산출물이 필요한 상황’이 의외로 자주 생긴다. 바로 PMBOK에서 말하는 “기타 결과물(4.6.9)”이 대표적이다.
이 글에서는 기타 결과물이란 무엇이며, 왜 이렇게 예기치 못하게 필요해지는지, 그리고 그 중요성을 프로젝트 관리자 혹은 실무자 관점에서 깊이 있게 살펴본다. PMBOK의 여타 지식 영역에서 직접적으로 명명된 산출물(예: 범위명세서, 일정표, 원가추정서 등)과 달리, 기타 결과물은 다양한 상황과 맥락에서 생길 수 있다. 예를 들어 특정 이해관계자와의 별도 협의가 필요해 만든 문서, 기존 운영 환경에 추가 통합해야 해서 만든 기술 가이드, 혹은 규제 준수를 위한 문서 등이 여기에 해당한다. 각각의 맥락을 이해하고 적절히 준비해둬야, 프로젝트가 ‘정말로’ 마무리되는 시점까지 이슈 없이 흘러갈 수 있다.
기타 결과물의 핵심 개념
명시되지 않은 산출물이 생기는 이유
대부분의 프로젝트에서 핵심 산출물은 ‘계획 단계’에서 이미 도출된다. 예를 들어 요구사항 수집과 범위 정의 과정에서 최종 제품(시스템, 서비스, 문서 등)의 모습이 제시되고, 일정관리에서 마일스톤에 맞춰 만들어야 할 중간 산출물이 구체화된다. 원가관리, 품질관리, 리스크관리 등에서도 핵심 문서들이 정의된다. 그렇다면 기타 결과물은 어떤 이유로 생길까?
한 가지 큰 원인은 ‘프로젝트 진행 중 발생하는 불확실성’이다. 범위가 아주 명확하다 해도, 예기치 못한 이슈나 변경 요청, 혹은 이해관계자의 새 요구사항이 나타날 때 프로젝트 팀은 그에 맞춰 문서를 만들거나 프로세스를 재설계하기도 한다. 이 과정에서 새롭게 필요한 내부 지침이나, 별도 승인 서류, 테스트 보고서 등이 생성된다. 또 다른 이유는 “기업의 내부 정책이나 규정” 혹은 “법률·규제 요구” 때문이기도 하다. 예를 들어 ISO 27001 같은 보안 규정을 준수하기 위한 별도 증빙 자료, 혹은 감사(Audit)용으로만 사용하는 내부 문서 등이 좋은 예시다.
특히 조직이 대규모화되고 프로젝트가 복잡해질수록, 애초에 프로젝트 관리 계획서(혹은 PMO 지침)에 포함되지 않았던 여러 결과물이 자연스럽게 요구되는 경우가 늘어난다. PMBOK에서는 이를 일괄적으로 ‘기타 결과물’로 묶어 정의하고, 이들의 필요성과 활용 방안을 인식해두라고 조언한다.
PMBOK 지식 영역과 기타 결과물의 연관성
기타 결과물은 특정 한 지식 영역에 국한되지 않는다. 사실상 통합관리(Integration Management), 스코프관리(Scope Management), 품질관리(Quality Management), 이해관계자관리(Stakeholder Management), 리스크관리(Risk Management) 등 프로젝트 관리 전반에 걸쳐 언제든 등장할 수 있다.
예컨대 이해관계자관리 측면에서는 내부 임직원이나 외부 기관(정부, 협력 업체 등)이 요구하는 별도 문서를 작성해야 할 수 있고, 품질관리 측면에서는 제품 결함 발생 기록이나 품질 관리 강화 조치 보고서 등 기존에 정의되지 않았던 신규 산출물이 생길 수 있다. 또한 통합관리 측면에서 프로젝트 전반의 변경이나 이슈가 발생했을 때, 이를 추적하고 해결하기 위한 추가 문서, 예를 들어 ‘변경관리 로그(변경 요청, 승인 내역, 영향분석 등)’ 같은 결과물도 발생 가능하다.
실무에서는 이런 ‘기타 결과물’이 의외로 프로젝트의 완성도와 만족도를 크게 높이기도 한다. 예를 들어 “프로젝트 후속 운영에 필요한 내부 매뉴얼”을 애초에 만들 계획이 없었는데, 테스트 과정에서 운영 담당자가 “이 매뉴얼이 없으면 운영이 힘들다”고 피드백해 추가로 제작할 수 있다. 해당 매뉴얼은 PMBOK에서 범위명세서나 일정표에 뚜렷이 명시된 결과물은 아니지만, 프로젝트가 실제로 운용되고 유지되는 데 매우 큰 도움을 준다.
프로젝트 프로세스에서 기타 결과물이 생기는 절차
요구사항 수집, 범위 확인
기타 결과물과 관련한 첫 번째 단계는 ‘요구사항 수집 및 범위 정의’ 시점에서 잠재적으로 필요한 문서를 최대한 인지하는 것이다. PMBOK 스코프관리 지식 영역에서 “이해관계자의 요구사항을 수집한다”고 하지만, 대개는 프로젝트 산출물을 기능적인 측면(예: 소프트웨어 기능, 하드웨어 구조)에 집중하여 나열한다. 이 과정에서 상대적으로 문서화나 내부 절차, 유지보수 시 필요한 자료 등은 간과되기 쉽다.
이를 피하려면 초기 범위 정의 단계에서 다음 질문을 던져볼 필요가 있다. “이 프로젝트 산출물을 실제로 운영·유지·검수·감사·보고하기 위해 추가로 필요한 문서, 절차, 파일 형식, 승인서 등이 있는가?” 예를 들어 고객이 정부 기관이라면, 납품 후 부처 승인에 필요한 별도 양식이 있을 수 있고, 내부 감사 프로세스가 엄격한 회사라면, 재무 감사용 증적 자료나 결제 프로세스 문서가 별도로 요구될 수 있다.
범위 확인 단계에서는 이렇게 식별된 산출물이 프로젝트 범위에 정식으로 포함되는지, 아니면 선택 사항인지 결정해야 한다. 만약 선택 사항이라면 예산과 일정에 영향을 줄 수 있기 때문에, 정확히 합의하는 과정이 필수적이다. 이 단계를 소홀히 하면, 프로젝트가 거의 끝나갈 무렵 “이런 문서도 필요했는데, 왜 없느냐”라는 불만이 터져나오고, 예산과 일정이 다시 엉키는 사태를 맞게 된다.
실행과 모니터링 중 발생하는 추가 요구
프로젝트가 실행(Executing Process Group) 단계에 들어가면, 실제 업무와 산출물이 생산되기 시작한다. 이때 실무자들은 “현재 작업을 진행하다 보니, 특정 과정에서 예기치 못한 산출물이 필요해졌다”라고 느낄 수 있다. 예컨대, 개발 프로젝트에서 테스트를 진행하다 보니 로그분석 보고서가 필요하거나, 새로운 에러 모듈에 대한 대응 가이드 문서가 필요하다는 사실을 알게 되는 식이다.
이러한 추가 요구는 보통 모니터링 및 통제(Monitoring and Controlling Process Group)에서 다룬다. 프로젝트 변경관리(Change Control) 프로세스를 통해, 새로 필요한 기타 결과물을 공식적으로 등록하고, 범위와 일정, 원가에 어떤 영향을 주는지 분석한다. 그리고 승인 절차를 거쳐 최종 범위에 반영한다. 이 과정을 거치지 않고 팀원이 그냥 임의로 문서를 만들면, “왜 예산에 없던 작업을 하느냐”는 식의 갈등이 생길 수 있으니 주의가 필요하다.
실무에서 자주 벌어지는 문제는, 기타 결과물이 필요하다는 사실을 인지했음에도 이를 공식적으로 문서화하거나 승인받지 않고 그냥 ‘해결책을 단발적으로 마련’해서 넘기는 경우다. 예를 들어 “이번 주에 갑자기 VIP 고객사에 보고해야 할 간단한 자료가 생겼다”며 빨리 만들어버리고는, 정작 프로젝트 산출물 목록에는 넣지 않는 식이다. 그러다 나중에 비슷한 요구가 재발했을 때, 다시 처음부터 모든 작업을 반복하는 비효율이 발생한다. PMBOK에서는 이런 상황을 방지하기 위해 사소한 변경도 정식 절차로 기록하고, 프로젝트 지식 자산으로 반영할 것을 권고한다.
종료(Closing) 단계에서의 결산 자료
프로젝트가 거의 마무리에 다다르면, 우리는 프로젝트 종료 보고서나 최종 인수인계 자료를 준비한다. 이때도 의외로 “그동안 한 작업들을 되짚어보니, 여기저기서 수집해야 할 문서가 아직 정리되지 않았네?”라는 사실이 발견되곤 한다. 예컨대 최종적으로 고객이 서명해야 할 승인서, 학습된 교훈(Lessons Learned) 문서, 사용자 교육용 매뉴얼, 시스템 관리자 모드 메뉴얼, 감사 보고서 등의 문서가 바로 이런 ‘기타 결과물’이 될 수 있다.
종료 단계에서 이런 문서가 미리 준비되지 않았다면, 프로젝트 팀은 상당한 시간과 노력을 추가로 투입해 마무리 자료를 정리해야 한다. 이 때문에 PMBOK 통합관리(Integration Management) 지식 영역에서는 프로젝트 마무리를 체계적으로 관리하라고 강조한다. 중간에 필요했던 문서를 놓치지 않고 수집해두면, 종료 시점에 별도의 추가 작업 없이도 간편하게 자료를 완성할 수 있다.
프로젝트 실무에서 자주 발생하는 이슈와 해결 사례
중요한 문서를 깜박 잊고, 일정이 지연되는 경우
프로젝트 팀이 내부 리뷰나 외부 심사를 거치다가 “아, 이 문서가 빠져 있었구나!”라는 사실을 뒤늦게 깨닫는 상황이 종종 발생한다. 예를 들어 공공 기관 납품 프로젝트에서 ‘정기 감사 보고서’에 해당하는 문서를 사전에 준비하지 않아, 나중에 고객이 “계약서상 의무는 아니지만 내부 절차상 이 보고서가 필수”라고 요구하면 어쩔 도리가 없다. 이미 프로젝트 막바지라 시간이 부족한 상태에서 허둥지둥 문서를 만들어야 하고, 추가 자원과 시간이 들어 일정까지 지연된다.
이를 해결하기 위해서는, 프로젝트 초기부터 ‘전사 품질 체계’나 ‘법적/규제 요구사항’을 꼼꼼히 체크해 필요 문서 목록을 빠짐없이 작성해야 한다. 여기에 더해, 이해관계자관리(Stakeholder Management)에서 누구와 협의해 어떤 문서를 마련해야 하는지를 미리 파악하는 것이 중요하다. 대규모 조직일수록, 협력 부서나 외부 기관(회계 법인, 규제 기관 등)이 관여할 수 있으므로, 조금이라도 의심되는 부분은 초반에 연락해 필요한 문서가 있는지 확인해야 한다.
중복 작업으로 인한 비효율
또 다른 문제는 여러 부서나 팀에서 비슷한 문서를 따로따로 만들거나, 이미 있는 자료를 재활용하지 못해 중복 작업이 발생하는 경우다. 예컨대 개발팀이 만든 테스트 결과 보고서가 품질관리팀에서 만든 결함 분석 보고서와 사실상 동일한 내용을 담고 있는데, 양쪽이 서로 인지하지 못해 중복 업무를 하는 식이다. 이는 프로젝트의 생산성을 떨어뜨리고, 인력 낭비와 일정 지연을 유발한다.
이런 중복을 줄이려면, PMBOK 통합관리(Integration Management)와 커뮤니케이션관리(Communications Management)를 적극 활용해 문서 자산을 공유·관리해야 한다. 디지털 요구사항 추적 시스템이나 협업 툴(예: 지라, 애저 DevOps, 구글 드라이브, Confluence 등)을 도입하면, 각 팀에서 작성하는 문서를 중앙 저장소에 업로드하고 태그나 카테고리를 붙여 쉽게 검색·재활용할 수 있다. 이런 방식으로 문서가 일원화되면, 중복 문서를 만들기 전 “이미 유사 자료가 있는지”를 간단히 확인할 수 있다.
품질·감사·규제 이슈로 인한 예기치 못한 산출물
품질 요구 사항이 까다로운 프로젝트에서는, 예기치 못한 시점에 인증 보고서나 시험 성적서를 추가로 요구받을 수 있다. 예를 들어 의료기기 소프트웨어를 개발하는 프로젝트에서, 각 국가별 의료기기 인증 규정에 맞춘 별도 제출 문서가 필요할 수 있다. 이건 원래 범위에 들어 있지 않았다고 해도, 현지 규정이 요구한다면 반드시 만들어야 한다. 이는 리스크관리(Risk Management)와 직결된 문제다.
미리 리스크 식별 단계에서 “해외 인증 규정, 산업별 규제 요건이 달라 추가 문서를 작성할 가능성”을 고려해두고, 이를 범위와 일정, 예산 계획에 반영해두면 훨씬 대응이 쉬워진다. 반면, 이 부분을 간과하면 프로젝트 후반부에 큰 비용과 시간을 들여 문서를 만들어야 하고, 일정이 지연되면서 고객과의 마찰이 커질 수 있다.
기타 결과물을 위한 실무 전략과 예시
간단한 표로 정리하는 방법
기타 결과물이 여러 개 존재하거나, 어떤 상황에 따라 새롭게 추가될 수 있다는 사실을 빠르게 파악하기 위해선, 다음과 같은 표 형식으로 정리해두는 방법을 추천한다.
| 결과물 명칭 | 필요 시점(프로세스) | 요청/필요 주체 | 담당 부서(담당자) | 비고 또는 특이사항 |
|---|---|---|---|---|
| 감사 요구사항 체크리스트 | 초기(범위 정의 단계) | 내부 감사팀, 법무 | PMO(문서 담당자) | 공공기관 납품 시 필수 적용, 매년 갱신 필요 |
| 운영 매뉴얼(사용자 용) | 실행, 마무리 | 운영 부서 | 개발 팀(인수인계 담당) | UI 변경 시마다 업데이트 필요 |
| 보안 점검 보고서 | 주간/월간 점검 | 보안 팀 | 보안팀, 외부 감사사 | ISO 27001 기준 준수사항 포함 |
| 장애 대응 가이드 | 개발/실행 중 | 운영부서, 고객사 | 개발팀(기술 리더) | 고가용성(HA) 요구사항 반영 |
| 설계 변경 후 검수 확인서 | 변경관리 단계 | 품질팀, 고객사 | 품질관리팀(검수자) | 범위 밖 변경 시 추가 비용 발생 가능 |
위 표는 단순 예시지만, 프로젝트에서 발생할 수 있는 대표적인 기타 결과물들을 목록화해둔 것이다. 이런 목록을 프로젝트 관리계획서(혹은 별도 산출물 관리 리스트)에 포함해 두면, “어떤 시점에 어떤 문서가 필요한가”를 체계적으로 추적할 수 있다. 이를 통해 불필요한 이슈를 줄이고, 문서 작성을 누락하거나 중복 작업을 하는 일을 예방한다.
애자일 접근법과 디지털 요구사항 추적 시스템의 활용
최근에는 애자일(Agile) 방법론을 채택해 스프린트 단위로 기능을 개발·출시하는 프로젝트가 늘고 있다. 이때 ‘기타 결과물’이 예측하기 어려운 시점에 발생할 가능성이 더 커지는데, 애자일은 짧은 반복 주기로 제품을 내놓으면서 고객 및 이해관계자와 소통을 강화하기 때문이다. 새로운 요구사항이 발견되면 backlog에 추가하고, 해당 작업을 다음 스프린트 혹은 우선순위 높은 순서로 처리한다. 이때 문서 산출물 역시 backlog 항목으로 관리할 수 있다. “사용자 메뉴얼 추가 작성”이나 “정부 규정 준수 문서 작성” 같은 항목이 backlog로 들어오면, 정해진 스프린트 안에서 구현(=작성) 시점을 결정하고 작업을 추적하면 된다.
디지털 요구사항 추적 시스템(예: 지라, 애저 DevOps, 레드마인 등)은 이런 문서 요청과 작업 현황을 실시간으로 공유하고, 태스크가 완료되면 자동으로 버전 관리를 해주는 기능을 제공한다. 예컨대 새로운 문서가 필요하다고 인지되면, 해당 작업 항목을 생성해 담당자와 기한을 할당하고, 완료 시 해당 문서 파일을 첨부할 수도 있다. 그 결과 팀원들은 “이 문서가 왜 생겼는지, 언제까지 만들어야 하는지, 누가 승인해야 하는지”를 잊지 않고 투명하게 관리할 수 있다.
마무리: 기타 결과물의 중요성과 적용 시 주의점
프로젝트 완성도를 높이는 숨은 열쇠
기타 결과물은 이름만 보면 ‘부차적인’ 산출물처럼 보이지만, 실제로는 프로젝트의 완성도를 결정짓는 숨은 열쇠에 가깝다. 예기치 못한 문서나 절차가 빠져 있으면, 아무리 훌륭한 핵심 산출물을 만들어냈더라도 고객(혹은 조직 내부) 입장에서는 “왜 이런 필수적인 자료가 안 보이느냐”라며 프로젝트 품질을 낮게 평가하기도 한다. 특히 운영·유지보수·감사·교육 등 프로젝트의 사후 단계까지 고려해야 할 때, 기타 결과물의 유무가 현장에서 큰 차이를 만들어낸다.
이를테면 대규모 ERP 프로젝트를 마치고 시스템을 오픈했는데, 정작 사용자 교육 매뉴얼이 미비하거나, 내부 통제 프로세스 문서가 누락되어 운영팀이 혼선을 겪는다면, 사용자들이 “이 프로젝트는 실패”라고 판단할 수도 있다. 반대로 핵심 기능 외에도 세세한 문서와 자료까지 잘 마련되어 있다면, 운영팀과 사용자들이 안정적으로 시스템을 활용해 회사 전체의 효율성이 높아진다. 결국 작은 문서 하나가 프로젝트의 전체 평판을 바꿀 수 있음을 기억해야 한다.
적용 시 주의사항
첫째, 초기 범위 정의 시점에 최대한 꼼꼼히 ‘추가 결과물’을 식별하려 노력하되, 100% 예측하는 것은 불가능하다는 점도 인식해야 한다. 둘째, 프로젝트 실행 과정에서 모니터링 및 통제 프로세스를 활용해, 새로 식별된 기타 결과물을 정식으로 승인·기록하고, 예산과 일정 영향을 검토해 반영해야 한다. 셋째, 정보 공유와 문서 중앙 관리 체계가 없다면 중복 작업이나 누락이 발생하기 쉽다. 디지털 요구사항 추적 시스템, 협업 툴 등을 활용해 문서 버전 및 배포 이력을 일원화하길 권장한다. 넷째, 프로젝트 종료 단계에서 남은 문서는 없는지, 꼭 필요한 승인이나 확인서, 매뉴얼이 누락되지 않았는지 최종 점검하는 절차를 놓치면 안 된다.
기타 결과물을 잘 챙기는 프로젝트 팀은 최종 인수·검수 시점에 흔들리지 않고, 고객과 내부 이해관계자로부터 신뢰를 얻는다. 그 결과, 프로젝트의 평가는 물론이고, 후속 비즈니스 기회까지 확대될 가능성이 높아진다. 이러한 가치가 바로 PMBOK에서 4.6.9 “기타 결과물” 항목을 별도로 강조하는 이유가 아닐까.