거버넌스·통합·생명주기 선택

범위·일정·원가·품질·자원은 이 절에서 정한 두 분관·8주·40백만 원을 실제 작업과 인수 근거에 연결한다. 먼저 헌장의 포함·제외와 변경 권한을 구별하며 읽는다.

거버넌스·통합·생명주기 선택

개발팀은 완료라고 하는데 도서관은 왜 받을 수 없을까

도서관의 새 알림 화면이 작동한다. 개발팀은 약속한 기능을 만들었다고 보고하지만 사서는 다른 분관으로 잘못 간 책을 어떻게 처리할지 모르고, 운영 담당자는 장애 연락처와 복구 권한을 받지 못했다. 사업 책임자는 처음 계획에 없던 세 번째 분관도 같은 날짜에 열겠다고 말한다.

이 상황을 일정표에 빨간색으로 표시하는 것만으로 해결할 수는 없다. 만들기로 한 범위, 완료로 인정할 증거, 자원을 바꿀 권한, 서비스를 넘겨받을 책임이 서로 연결돼야 한다. 프로젝트 관리는 여러 팀의 보고서를 모으는 일이 아니라 이 연결을 유지하면서 실제 결정을 내리는 일이다.

이 장은 가상 푸른도서관의 두 분관 간 도서 이동 요청·도착 안내 시범 프로젝트를 사용한다. 모든 기관·역할·기간·금액·결과는 자체 교육 가정이다. 실제 도서관 사업, 공공조달 절차나 운영 승인을 수행한 기록이 아니다. 이 절은 착수와 결정체계를 다룬다. 이어 범위·일정·원가·품질·자원으로 실행 가능한 계획을 세우고, 위험·조달·의사소통·이해관계자로 외부 의존을 점검한 뒤, 성과측정·변경통제·종료·교훈으로 결과와 후속 책임을 연결한다.

앞에서 배운 내용을 어디에 쓸까

소프트웨어 생명주기는 분석부터 운영·변경·종료까지 질문과 증거가 이어진다고 설명했다. 제품 개발계획은 누구의 어떤 문제를 어떤 범위로 풀고 무엇을 학습할지 정했다. 이번에는 선택한 변화에 사람·예산·일정·결정권을 묶어 착수부터 인계까지 통제한다.

1. 프로젝트는 일상 운영과 무엇이 다른가

프로젝트는 정한 목적의 고유한 결과를 만들기 위해 시작과 끝을 두고 수행하는 한시적 활동이다. 한시적이라는 말은 결과물의 수명이 짧다는 뜻이 아니다. 새 서비스의 도입 프로젝트는 끝나도 그 서비스는 계속 운영될 수 있다.¹

IT 프로젝트 관리는 정보기술을 이용한 변화의 목표와 불확실성을 범위·일정·원가·품질·자원·위험·이해관계자 및 결정 책임으로 연결하여, 실행·변경·인수·종료를 통합 관리하는 활동이다. 어느 항목 하나의 좋은 숫자로 다른 필수 실패를 지우지 않는 것이 핵심이다.

매일 도착한 책을 확인하고 이용자에게 안내하는 일은 반복 운영이다. 두 분관의 요청·안내 방식을 새 구조로 전환하고 운영자에게 넘기는 일은 프로젝트다. 프로젝트에 속한 시험 운영과 이후 상시 운영의 책임·비용을 구별하지 않으면 종료 직후 담당자가 사라지는 문제가 생긴다.

관련 프로젝트를 함께 조정해 개별 수행으로 얻기 어려운 편익을 관리하면 프로그램 관점이 필요하다. 그렇다고 분관이 두 개라는 이유만으로 자동으로 두 프로젝트와 하나의 프로그램을 만들어야 하는 것은 아니다. 필요한 결정의 범위에 맞춰 구조를 정하고 직함이나 문서 수를 늘리는 것을 목적으로 삼지 않는다.

2. 착수 전에 무엇을 승인받을 것인가

프로젝트 헌장은 프로젝트를 시작할 목적·상위 범위·주요 제약과 책임·권한을 명시하는 착수 문서다. 상세 작업을 모두 확정하는 문서와 다르다. 어떤 문제를 풀도록 누구에게 자원을 맡겼는지 먼저 분명히 해야 이후의 계획과 변경을 판단할 수 있다.

자체 착수안 PM-G1은 다음과 같다. 수치와 위임 규칙은 이 사례에서 선택한 조건이며 모든 기관의 적정 기준이 아니다.

프로젝트 납품조건과 기대 결과는 같은 것이 아니다. 교육·기능을 넘겼어도 실제 안내가 빨라졌는지는 이후 사용에서 확인한다. 반대로 사업효과 관찰을 계속해야 한다고 프로젝트 조직을 기한 없이 유지할 필요도 없다. 운영 책임자에게 관찰·개선의 책임과 재검토 시점을 명확히 넘길 수 있다.

‘중대결함 없음’은 어떤 결함을 중대로 보는지 먼저 정해야 쓸 수 있는 조건이다. 이 사례에서는 잘못된 수신자에게 이용정보가 전달되거나, 확정된 요청 기록을 잃거나, 필수 접근통제를 우회할 수 있는 결함을 중대로 정한다. 시험에서 발견되지 않았다는 사실만으로 모든 실제 환경에 결함이 전혀 없음을 증명했다고 하지 않는다.

3. 거버넌스는 결정을 늦추는 회의가 아니라 권한의 구조다

프로젝트 거버넌스는 누가 어떤 범위에서 결정하고 결과에 책임지며, 위임 한계를 넘는 문제를 어디로 올릴지 정한 체계다. APM의 공개 설명도 권한·책임과 위임 한계, 상향 보고 경로를 중심에 둔다.²

후원자 또는 스폰서는 사업 목적과 자원 투입을 지지하고 주요 결정을 책임지는 역할이다. 프로젝트 관리자(PM)는 위임받은 범위에서 계획·실행·의존성·위험·변경을 통합 조정한다. PM이 모든 기술 결정을 직접 내리거나 모든 조직의 직원에게 인사 권한을 갖는다는 뜻은 아니다.

푸른도서관의 사업 책임자는 목표·전체 자원과 사업 계속 여부를 결정한다. 사서 대표는 업무 의미와 이용자 요구를 확인하고, 개발팀은 구현·기술 근거를 제공한다. 운영 담당은 실제 인수 가능성과 장애 대응을 확인한다. 외부 공급자의 계약상 의사결정은 구매·계약 담당의 권한과 함께 처리한다.

프로젝트 지원조직(PMO)은 기준·정보·조정·지원 등의 역할을 맡을 수 있다. 그러나 PMO가 있다는 사실만으로 후원자의 사업책임이나 PM의 실행책임이 사라지는 것은 아니다. 조직마다 권한 범위가 다르므로 명칭보다 실제 위임을 확인한다.

책임표를 읽는 최소 문법

RACI는 수행 책임인 R(Responsible), 최종 책임인 A(Accountable), 사전에 협의할 C(Consulted), 결과를 알릴 I(Informed)를 구별하는 표현이다. 이 사례에서는 결정 항목마다 A를 한 역할에 지정하는 작성 규칙을 사용한다. 한 사람이 여러 역할을 겸할 수 있어도 서로 다른 책임을 숨기지는 않는다.

표의 R이 여러 개라면 실제 작업을 누가 어디까지 하는지 더 나누어야 한다. 모두를 C로 넣고 모든 회의에 참석시키면 협의 비용만 커질 수 있다. 반대로 운영의 영향을 직접 받는 사람을 I로만 두면 인수 단계에서 필수 조건을 뒤늦게 발견한다.

전체 종료 승인자는 사서·운영 담당의 필수 증거를 대신 만들어 주지 않는다. 개발팀의 자체 확인은 기술 근거이고, 인수권자의 수용 결정이나 별도 독립 검토와는 구별된다. 역할표는 계약·법정 권한의 실제 존재를 새로 만들어 내는 문서가 아니다.

4. 통합관리는 문서 합본이 아니라 영향의 연결이다

추가 기능 하나도 요구·설계·자료·시험·교육·계약·일정을 함께 바꿀 수 있다. 개발 작업만 세고 운영 준비를 빼면 비용과 기간을 과소평가한다. 반대로 모든 작은 수정에 전체 위원회를 열면 실행이 멈춘다. 영향 범위와 위임 한계를 함께 봐야 한다.

기준선은 이후 실적·변경 판단에 쓰도록 승인한 특정 버전이다. 현재 예측이 나빠졌다고 과거 기준선을 조용히 고치지 않는다. 기준선과 최신 완료 예상은 나란히 기록하며, 정당하게 승인된 변경은 별도 이력을 가진 새 버전으로 반영한다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

분류는 요청 이름이나 크기보다 실제 영향과 위임·필수 인수조건에 따른다. PM은 위임 내 작업을 조정하고 범위·예산·기간 한계를 넘으면 영향을 분석해 사업 책임자에게 올린다. 다른 이용자 정보 조회는 기존 필수 조건의 실패여서 제공 통제·수정·재시험이 필요하다. 승인 변경과 최신 예상은 과거 기준선과 나란히 기록한다. 필수 결함은 즉시 제공을 통제하며, 그 수정이 일정·예산의 위임 한계를 넘으면 변경 승인도 함께 요청한다. 하나의 발견에 여러 조치가 필요할 수 있다.

화살표는 영향과 정보의 연결이다. 한 번만 왼쪽에서 오른쪽으로 진행한다는 단계도가 아니다. 운영 담당의 발견이 범위와 시험을 바꾸고, 공급자 일정이 바뀌면 실행 순서와 비용 예상도 달라진다.

따라 판단: 세 요청은 모두 같은 변경일까

요청 G1: 사서가 안내 문구를 더 쉽게 바꾸자고 한다. 목적·제공범위·수신자·비용·기간·보호조건을 바꾸지 않는지 PM과 담당자가 확인한다. 이 사례의 위임 안이면 작업 후보에 반영하고 해당 문구와 이해 여부를 확인한다. ‘작아 보인다’는 말만으로 영향 확인을 생략하지 않는다.

요청 G2: 사업 책임자가 세 번째 분관도 8주 안에 넣자고 한다. 이는 헌장의 제외 범위를 바꾸며 교육·이용자·권한·계약·시험의 분모가 늘어난다. PM은 전체 영향을 분석해 선택지를 제시한다. 책임자의 발언만으로 새 범위가 구현·검증된 것으로 표시하지 않고, 문서화한 범위·자원·기준선 변경 결정을 거친다.

요청 G3: 시험 중 다른 이용자의 요청을 조회할 수 있는 결함을 발견한다. 이는 새 편의기능의 요구가 아니라 기존 필수 조건의 실패다. 영향받는 제공을 막고 결함·영향·수정·재시험을 관리한다. 추가 비용의 계약상 부담은 계약을 확인해야 하며, 결함이라는 이유만으로 모든 일정·원가 영향이 자동으로 없어지는 것은 아니다.

PM-G1에서는 일정 미달 예상이나 승인 작업예산 초과가 드러나면 즉시 상향한다. 필수 보호조건 실패는 다음 정기회의까지 기다리지 않는다. 그 외 위임 내 작업 조정은 PM이 처리한다. 상향 보고는 책임을 넘기는 일이 아니라 선택 가능한 대안과 필요한 결정을 분명히 하는 일이다.

5. 생명주기는 프로젝트의 불확실성에 맞게 고른다

예측형 접근은 비교적 안정된 결과·의존성을 앞에서 상세히 계획하고 변화를 통제하는 데 무게를 둔다. 적응형 접근은 불확실한 필요·해법을 짧은 피드백으로 확인하며 세부 제공범위를 조정하는 데 무게를 둔다. 순차·반복·증분의 기본 설명은 앞 생명주기 절을 사용하고, 여기서는 어떤 통제와 학습을 어디에 배치할지 판단한다.

자체 선택안 PM-G2는 상위 예산·대상·필수 품질을 통제하면서, 두 주 단위로 쓸 수 있는 작은 흐름을 확인하는 혼합 접근이다. 먼저 요청을 식별하고 상태를 확인하는 흐름, 이어 도착 안내와 오류 대응을 연결한다. 마지막에야 품질을 붙이는 대신 각 작은 흐름에서 필요한 보호·실패 처리를 함께 확인한다.

반복한다는 이유만으로 Scrum을 수행했다고 부르지는 않는다. 2020 Scrum Guide는 팀의 책임, 반복 중 검사·적응, 사용 가능한 증분과 완료의 정의를 함께 규정한다. 완료의 정의에 미달한 항목을 완료 증분으로 세지 않으며, Sprint Review는 출시를 기다리게 하는 필수 승인 관문이 아니다. PM-G2는 이런 구별을 참고한 자체 혼합 계획이지 Scrum 준수 선언이 아니다.³

착수·계획·실행·감시통제·종료 같은 관리 활동을 생명주기상의 서로 배타적인 한 번짜리 단계로만 보지 않는다. 실행 중에도 계획을 갱신하고 위험을 확인한다. 한 증분이 인수돼도 전체 프로젝트는 계속될 수 있다. ‘개발 단계가 끝났으니 요구 확인은 하지 않는다’는 식으로 책임을 끊지 않는다.

6. 실제 통합관리안은 어떤 모습인가

PM-G2의 착수 조건은 두 분관의 범위·업무 대표·운영 책임·예산과 기존 연계 가능성의 확인이다. 이 중 핵심 책임이나 연계 근거가 없으면 전체 구현부터 시작하지 않고 확인할 작업과 승인 범위를 좁힌다. 반대로 화면 문구까지 모두 확정될 때까지 시간을 쓰지 않고 확인 가능한 흐름부터 학습한다.

첫 통제점에서는 헌장과 초기 통합계획을 승인한다. 실사용 전환 통제점에서는 대상·판본과 정상·거부·복구 결과, 교육·문의·운영 준비를 대조한다. 종료 통제점에서는 인수한 범위, 잔여 작업의 인수자, 계약·재원 정리, 효과 관찰의 책임을 확인한다. 날짜가 됐거나 문서에 서명란이 있다는 이유로 자동 통과시키지 않는다.

PM은 한 요구의 식별자로 설계·작업·시험·변경의 관계를 찾을 수 있게 하고, 최신 일정·비용 예상과 기준선을 구별해 공유한다. 팀이 쓰는 실행 도구와 사업 책임자가 보는 요약표가 서로 다른 완료 정의를 쓰지 않게 한다. 상세 자료를 전부 보고하는 대신 필요한 결정, 영향, 선택지와 근거 위치를 보고한다.

운영 책임자는 프로젝트 종료 뒤 4주간 같은 정의로 안내의 적시성·오류·문의 부담을 관찰한다. 사업 책임자는 기대 결과가 부족하면 추가 개선·유지·중단을 판단한다. 인수된 산출물과 아직 검증되지 않은 편익을 분리해 남기는 것이 종료를 정직하게 만드는 방법이다.

7. 자체 10점 문제와 완성 답안

푸른도서관 PM-G1을 대상으로 프로젝트 거버넌스와 통합관리의 역할을 설명하고, 안내 문구 수정·분관 확대·접근통제 결함을 어떻게 구별해 처리할지 제시하시오.

답안 목차·풀이·교정 근거 보기

해석과 목차: 프로젝트의 경계 → 역할·위임 → 세 요청의 영향 → 결정과 기준선. 명칭의 정의만 쓰지 않고 각각 누가 어떤 근거로 행동하는지 답한다.

실제 영향과 위임·필수조건에 따른 조정·승인요청·결함통제를 관계 그림에서 함께 읽고, 아래 완성 답안에서 조건과 판단을 확인한다. 승인된 변경만 기준선에 반영하고 결정·근거·영향 문서를 갱신한다.

완성 답안

IT 프로젝트 관리는 두 분관의 이동 요청·도착 안내라는 한시적 변화의 목표를 범위·일정·원가·품질·자원·위험과 결정 책임으로 연결하는 활동이다. 사업 책임자는 상위 범위·예산·종료를 승인하고 PM은 위임된 실행을 통합 조정하며, 사서와 운영 담당은 업무·운영인수의 증거를 확인한다.

안내 문구 수정은 수신자·기능·품질·비용·기간 영향이 위임 안인지 확인한 뒤 담당자가 반영한다. 세 번째 분관 확대는 제외 범위를 바꾸므로 권한·교육·계약·시험과 자원 영향을 분석해 정식 변경 결정을 받는다. 다른 이용자의 요청 조회는 기존 필수 조건의 결함이므로 제공을 통제하고 수정·재시험하며 편의기능 후보로 미루지 않는다.

통합관리는 이 영향을 연결하고 기준선·현재 예상·실적을 구별한다. 일정·예산 초과 예상과 필수 보호 실패는 즉시 상향하며, 승인한 변경만 새 기준선에 반영하고 과거 실패를 지우지 않는다. 자체 기술 확인을 업무 인수·운영 인수나 독립 승인과 혼동하지 않는다.

8. 자체 25점 문제와 완성 설계 답안

PM-G2의 프로젝트 통합관리안을 설계하시오. 헌장·책임·위임, 생명주기 선택 근거, 실행 피드백, 전환·종료와 편익 인계를 포함하시오.

답안 목차·풀이·교정 근거 보기

해석과 목차: 목적·포함/제외 → 책임과 위임 → 안정된 조건과 학습할 조건 → 통제점·근거 → 종료 후 책임. 계획을 세운다는 지침이 아니라 사례에서 선택한 결과를 제시한다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

PM-G2는 상위 범위·예산·필수 보호를 통제하고 두 주 단위 작은 흐름에 매주 사서 피드백을 받는다. 업무·운영 인수와 프로젝트 종료 뒤에도 운영 책임자가 4주 같은 정의로 효과·오류·문의 부담을 관찰하고 사업 책임자가 재결정한다. 납품은 안내 90% 편익 달성을 뜻하지 않는다.

완성 설계 답안

PM-G2는 두 분관의 참여가 확인된 성인 이용자 요청을 범위로 정하고 요청 식별·상태·안내·오류 대응·교육·운영인수를 제공한다. 대출시스템 전체 교체와 세 번째 분관, 추천·결제는 제외한다. 착수부터 인수·종료 판단까지 8주와 승인 작업예산 40백만 원을 관리하고, 잘못된 수신자 발송·기록 유실·필수 접근통제 우회 등 미해결 중대결함이 있으면 실사용 전환을 승인하지 않는다.

사업 책임자는 목적·상위 자원·변경·종료, PM은 일별 조정·통합 예상·상향 보고를 맡는다. 사서 대표는 업무 의미·수용 조건, 개발팀은 구현·기술 증거, 운영 담당은 인수 준비와 이후 대응을 맡는다. 범위·예산을 바꾸거나 필수 실패가 발견되면 영향·선택지·필요 결정을 제시하고, 위임된 작은 조정은 PM과 담당자가 기록해 처리한다. RACI는 이 책임을 보이게 하며 명칭만으로 실제 권한을 부여하지 않는다.

상위 대상·예산·보호조건은 통제하되 인계·오류 표시의 사용성은 반복 검증한다. 기존 연계 가능성을 먼저 확인하고 두 주 단위의 사용 가능한 작은 흐름에 사서의 매주 피드백을 반영한다. 순차 승인만으로 뒤늦게 사용성을 확인하는 안과, 모든 요구·품질을 자유롭게 바꾸는 안은 기각한다. 자체 혼합 접근을 Scrum의 일부 행사만으로 준수한 것으로 표시하지 않는다.

착수에서 헌장·통합계획, 전환에서 실제 판본의 정상·거부·복구·교육·운영 준비, 종료에서 인수 범위·계약·잔여 작업의 책임을 확인한다. 요구·작업·시험·변경을 같은 식별자로 연결하고 기준선과 최신 예측을 구별한다. 운영인수 뒤 4주간 도착 후 30분 내 안내 비율과 오류·문의 부담은 운영 책임자가 관찰하고 사업 책임자가 편익 미달의 후속 결정을 한다. 프로젝트 종료를 사업효과 달성이나 위험의 소멸로 바꾸지 않는다.

9. 자기교정

조건을 바꾸어 다시 판단한다

사서 대표가 두 달간 피드백을 줄 수 없다면? 바뀐 조건으로 계산하거나 결정 근거를 먼저 적어 본다.

조건 변경 답안과 교정 근거

PM-G2의 반복 학습 가정이 깨진다. 실제 이용·업무를 대표할 참여자를 확보하거나 판단 가능한 범위를 좁히고 일정·인수 계획을 다시 협의한다. 개발팀의 추측을 사용자 검증으로 바꾸지 않는다. 선택 조건을 고친다.

안내 문구 수정이 수신자에게 보이는 개인정보 항목도 바꾼다면? 바뀐 조건으로 계산하거나 결정 근거를 먼저 적어 본다.

조건 변경 답안과 교정 근거

G1의 작은 변경 가정을 그대로 적용할 수 없다. 데이터·권한·보호·수용 조건의 영향을 검토하고 적절한 책임자에게 결정을 올린다. 통합 판단은 변경 이름보다 영향을 본다.

도입 필요 자체가 없어졌다면? 바뀐 조건으로 계산하거나 결정 근거를 먼저 적어 본다.

조건 변경 답안과 교정 근거

남은 예산을 소진하려고 프로젝트를 계속하지 않는다. 사업 책임자가 필요 변화와 종료 비용·계약·자료·운영 책임을 검토해 중단 여부를 결정한다. 종료 책임을 없애는 것이 중단은 아니다.

근거와 적용 범위

프로젝트·거버넌스·관리 역할은 공개된 전문기관의 개념 설명을 제한적으로 참고했다. PM-G1·G2의 도서관·기간·예산·책임표·변경 사례·답안은 자체 작성이다. 유료 표준 전문, 특정 자격시험의 공식 기준답안이나 국내 공공사업의 법정 절차를 재현한 원고가 아니다.

회독의 핵심

프로젝트의 끝과 서비스의 끝은 다르다. 목적·범위·인수조건과 권한을 먼저 정하고, 실행 중 드러난 영향을 일정·예산·품질·운영까지 연결한다. 불확실성에는 학습을 배치하되 필수 조건은 숨기지 않는다. 편익은 납품 수로 대신하지 않고 종료 뒤에도 지정된 책임자가 확인한다.

Footnotes

1. APM, Project management glossary, Project·Programme·Project management 등 관련 개념. https://www.apm.org.uk/resources/glossary/ . 2026-09-20 공개 설명을 대조했다. 관찰일을 해당 용어의 최초 발행일로 사용하지 않는다. ↩

2. APM, What is governance?, Definition·Empowering·Governance board. https://www.apm.org.uk/resources/what-is-project-management/what-is-governance/ . 2026-09-20 확인. 권한·책임·위임·상향 경로의 원리만 참고하며 자체 역할표는 원문 표를 복제한 것이 아니다. ↩

3. Ken Schwaber and Jeff Sutherland, The 2020 Scrum Guide, November 2020, Scrum Team·The Sprint·Sprint Review·Increment·Definition of Done의 HTML 판본. https://scrumguides.org/scrum-guide.html . 2026-09-20 대조. 독립 한국어 설명이며 원문 전체 번역·그림 복제나 Scrum 준수 인증은 하지 않았다. ↩