핵심노트 · 주제 06-01

프로젝트 관리

이게 뭔가요?

하겠다고 한 일을 실제로 끝낼 수 있게 계획하고, 진행 상황을 확인하며 조정하는 방법을 배웁니다. 새 지점 개점까지 한 달 남은 식당이 예약 앱을 도입한다면 어디까지 만들지, 누가 무엇을 맡을지, 시간과 비용은 얼마나 필요한지, 직원 교육과 기존 예약 이전까지 무엇을 확인해야 완료인지 정하는 일입니다.

왜 배우나요?

열심히 일해도 중간에 기능이 계속 늘거나 앞선 작업이 늦어지면 약속한 날짜를 지키기 어렵습니다. 결제 기능을 추가해 달라는 요청이 들어오면 일정·비용·품질에 미칠 영향을 함께 따져야 합니다. 제한된 자원 안에서 우선순위를 정하고, 변화에 대응하며 합의한 결과를 완성하기 위해 배웁니다.

무엇을 언제까지 만들지 합의하고 작업 순서와 담당자를 정합니다. 아직 확인하지 못한 조건과 다른 팀을 기다리는 일을 점검하며, 완성한 결과를 운영 담당자가 사용할 수 있도록 넘깁니다.

교재 개념의 뜻을 설명하고, 가상 업무에서 언제 왜 쓰는지 풀어 쓴 자체 해설입니다. 먼저 설명과 예시를 읽고, 확인 질문에 자신의 말로 답해 보세요. 각 항목의 관련 교재 내용에서 단원과 교재 페이지를 확인할 수 있습니다. 20개 노트는 교재 전체 요약이나 시험 중요도 순위가 아니며, 주제 끝의 추가 학습 내용도 함께 확인하세요.

1. 성공 기준 — 납품 완료와 업무 개선을 각각 확인한다

산출물은 프로젝트에서 만들어 전달하는 프로그램·문서 같은 결과물입니다. 이 결과물이 약속한 기능을 갖춘 것과 도입 목적을 이룬 것은 각각 확인해야 합니다.

신청 시스템을 납품할 때는 신청·승인·반려가 합의대로 동작하는지 확인합니다. 운영 후에는 실제 처리 시간이 줄었는지 살펴봅니다. 무엇을 누가 언제 확인해야 완료 또는 성공이라고 할지 시작할 때 합의해야 마지막에 서로 다른 기대를 발견하는 일을 줄일 수 있습니다.

가상 업무 예시

신청 시스템을 만들 때 발주 담당자는 납품 전에 신청·승인·반려·재신청이 약속대로 동작하는지 확인합니다. 운영 담당자는 도입 후 일정 기간의 처리 시간을 이전과 비교합니다. 기능을 제대로 만들었는지와 실제 업무가 빨라졌는지를 서로 다른 시점에 확인하는 것입니다.

생각해 볼 질문
어떤 기능과 시험 결과를 누가 확인하면 프로젝트가 완료되나요? 운영 후 처리 시간이 줄었는지는 언제 누가 확인하나요?

2. 범위와 우선순위 — 이번에 할 것과 미룰 것을 정한다

제품 범위는 만들 결과물의 기능과 특징이고, 프로젝트 범위는 그 결과물을 만드는 데 필요한 일입니다. 신청 버튼은 제품의 기능이며, 설계·개발·시험·교육은 그것을 사용하게 만들 작업입니다.

이번에 신청과 승인만 만들고 통계는 다음으로 미룬다면 포함할 기능과 제외할 기능을 명시합니다. 하지만 실제 사용에 필요한 계정 발급과 교육은 기능 목록에 없다고 빠뜨려서는 안 됩니다. 새 요청이 들어오면 필요한 작업과 일정이 얼마나 늘어나는지 확인해 범위를 조정합니다.

가상 업무 예시

다음 달부터 쓸 출장비 시스템을 4주 안에 만들어야 합니다. 책임자는 신청·승인·정산에 집중하고 통계 화면은 다음 단계로 미룹니다. 다만 계정 발급과 회계 담당자 교육을 빼면 첫날 사용할 수 없으므로 이번 범위에 포함합니다. 화면 수를 줄이는 것과 실제 업무를 시작하는 데 필요한 일을 빼는 것은 다릅니다.

생각해 볼 질문
이번에 만들 기능과 다음으로 미룰 기능을 모두 같은 뜻으로 이해하나요? 사용에 필요한 계정 발급·교육·데이터 이전도 포함했나요?

3. 역할과 결정권 — 담당자를 적는 것에서 끝내지 않는다

작업을 하는 사람과 업무 규칙을 결정하는 사람, 결과를 승인하는 사람은 다를 수 있습니다. ‘담당자’라는 말 하나로 묶으면 결정이 필요할 때 서로 기다리게 됩니다.

개발자는 반려 기능을 만들 수 있지만 어떤 신청을 다시 제출하게 할지는 업무 책임자가 정해야 합니다. 프로젝트 관리자는 결정할 사람과 기한을 확인하고 개발 일정에 연결합니다. 그 사람이 없을 때 누가 대신 결정할지도 정해 둡니다.

가상 업무 예시

출장비 시스템 개발자가 ‘영수증이 없으면 반려한다’고 구현하려는데 회계팀은 분실 증빙을 허용할 때도 있다고 말합니다. 개발자가 임의로 예외를 정하면 회계 책임까지 떠안게 됩니다. 프로젝트 관리자는 회계 책임자를 정책 결정자로 지정하고 금요일까지 허용 조건을 확정하도록 합의합니다. 개발 담당과 업무 결정 담당을 나눈 것입니다.

생각해 볼 질문
지금 막힌 일을 풀기 위해 누가 무엇을 언제까지 결정해야 합니까?

4. WBS와 활동 의존성 — 범위를 나누고 순서를 정한다

WBS는 작업분류체계로, 프로젝트 전체 결과와 범위를 관리할 수 있는 작은 단위로 나눈 것입니다. 큰 제목만 적었을 때 빠뜨리기 쉬운 작업과 담당자를 찾는 데 도움이 됩니다.

외부 서비스와 연결하는 기능에는 코딩 외에도 규격 확인·접근 승인·시험 계정 발급·연결 시험이 필요합니다. 일을 나눈 다음에는 먼저 끝나야 할 일과 기다려야 할 시간을 확인합니다. WBS를 만들었다고 작업 순서와 일정까지 자동으로 정해지는 것은 아닙니다.

가상 업무 예시

택배 연동을 ‘개발 3일’ 한 줄로 계획했지만 시험 계정 승인에 5일이 필요했습니다. 관리자는 규격 확인, 계정 신청, 코드 작성, 시험 배송, 결과 확인으로 일을 나눕니다. 계정 신청은 먼저 하고 코드는 예제 응답으로 일부 진행하되, 실제 시험 배송은 계정 승인 뒤에 배치합니다. 할 일과 선행 조건을 나누자 코딩 시간만으로 잡은 일정의 누락이 보입니다.

생각해 볼 질문
이 작업을 시작하려면 다른 팀의 승인·규격·시험 계정 중 무엇이 먼저 필요한가요? 준비될 날짜를 확인했나요?

5. 추정과 불확실성 — 예상 기간의 가정과 미확인 조건을 적는다

기간 추정은 필요한 작업량과 투입할 사람·장비, 현재 아는 조건을 바탕으로 걸릴 시간을 예상하는 것입니다. 조건이 바뀌거나 새로운 사실을 알게 되면 예상도 달라질 수 있습니다.

처음 연결하는 외부 시스템을 하루면 끝난다고 단정하기보다 작은 연결 시험으로 응답 형식과 제한을 먼저 확인할 수 있습니다. 가까운 작업은 자세히 계획하고 정보가 부족한 뒤쪽 작업은 확인 시점을 정해 점차 구체화합니다. 일정의 가정과 미확인 조건을 드러내야 변경 이유도 설명할 수 있습니다.

가상 업무 예시

처음 연결하는 택배 API를 보고 팀은 주소와 주문 번호만 보내면 되니 이틀이면 된다고 추정했습니다. 시험 요청을 해 보니 일부 주소는 별도 코드 변환이 필요했습니다. 팀은 먼저 작은 연결 시험에 하루를 배정하고 그 결과로 개발·검증 시간을 다시 잡습니다. 아직 확인하지 못한 대량 요청 제한은 확정 일정의 근거와 구분해 적습니다.

생각해 볼 질문
예상 기간을 계산할 때 어떤 작업량과 인원, 외부 승인 날짜를 가정했나요? 아직 확인하지 못한 조건은 언제 확인하나요?

6. 위험과 이슈 — 가능성과 발생한 문제를 구분한다

프로젝트 위험은 아직 확실하지 않은 사건이나 조건이 목표에 영향을 줄 가능성을 말합니다. 부정적 영향인 위협뿐 아니라 긍정적 영향인 기회도 포함합니다. 이슈는 이미 발생해 해결해야 하는 문제입니다.

외부 승인이 늦어질 수 있다는 것은 위험입니다. 승인 기한을 넘겨 시험이 멈췄다면 이미 이슈입니다. 위험에는 예방·대응 방법과 알아챌 신호를 정하고, 이슈에는 해결 담당자와 기한을 정합니다. 목록에 같은 문장을 반복하기보다 상태에 맞게 행동을 바꿔야 합니다.

가상 업무 예시

월요일 회의에서는 ‘금요일까지 시험 계정을 못 받으면 다음 주 연동 시험이 늦어진다’는 위험을 기록하고 수요일에 승인 상태를 확인하기로 했습니다. 금요일에도 계정이 나오지 않자 이는 발생한 이슈가 됐습니다. 관리자는 승인 담당자에게 조치를 요청하고 먼저 할 수 있는 내부 시험을 진행하며 공개일 영향을 보고합니다. 가능성을 적는 것과 이미 멈춘 일을 처리하는 행동은 다릅니다.

생각해 볼 질문
외부 승인이 늦어질 가능성을 걱정하는 단계인가요, 기한을 넘겨 시험이 멈춘 상태인가요? 현재 상태에 맞는 대응과 담당자를 정했나요?

7. 짧은 검증 주기 — 마지막 날에 처음 보여 주지 않는다

애자일은 짧은 주기로 결과를 만들고 확인하면서 변화에 대응하는 접근입니다. 마지막 날 전체를 처음 보여 주는 대신 실제로 동작하는 작은 부분을 사용자와 자주 검토합니다.

신청 화면의 모양만 보여 주면 업무 순서가 맞는지 알기 어렵습니다. 신청·반려·수정·재승인을 한 번 이어서 해 보면 사용자의 기대와 다른 순서를 일찍 발견할 수 있습니다. 반복 개발도 목표나 확인 기준 없이 계속 바꾸라는 뜻은 아닙니다.

가상 업무 예시

개발팀은 반려된 출장비 신청을 처음부터 다시 쓰게 만들었습니다. 첫 주에 신청·반려·수정·재제출을 시연하자 회계 담당자는 영수증 한 장만 고치면 될 때 전체를 다시 쓰는 부담을 지적했습니다. 팀은 다른 화면을 모두 만들기 전에 수정 후 재제출 흐름으로 바꿨습니다. 화면 시안만 확인했다면 놓쳤을 작업 방식의 차이입니다.

생각해 볼 질문
사용자와 승인 담당자가 최근 직접 써 본 기능은 무엇인가요? 정상 처리뿐 아니라 반려·취소 같은 예외도 확인했나요?

8. 변경 관리 — 추가 작업과 비용·일정을 함께 결정한다

변경 관리는 추가·수정 요청이 기능·일정·비용·시험에 미치는 영향을 보고 받아들일지 결정하는 일입니다. 기준선은 변경 전후를 비교할 승인된 계획이며, CCB는 정해진 절차로 변경을 판단하는 변경통제위원회입니다.

공개 직전에 승인 단계 하나를 추가하면 화면만 바뀌는 것이 아닙니다. 권한과 알림, 시험할 경우도 늘어납니다. 필요한 이유와 추가 작업을 확인한 뒤 공개일을 바꿀지 다른 기능을 미룰지 결정하고 새 계획을 기록합니다.

가상 업무 예시

공개 사흘 전에 100만 원 이상 신청에는 부서장 승인을 추가해 달라는 요청이 왔습니다. 팀은 승인자 권한, 대기 알림, 부재 처리와 금액 경계 시험이 추가된다고 설명합니다. 책임자는 필요한 변경으로 승인하되 통계 기능을 미루고 승인 흐름 검증 시간을 확보합니다. 요청을 받았다는 이유만으로 원래 범위와 날짜를 동시에 유지한다고 약속하지 않습니다.

생각해 볼 질문
새 기능을 추가하면 어떤 개발·시험 작업이 늘어나나요? 늘어나는 비용과 일정, 미룰 기능을 승인 담당자와 합의했나요?

9. 품질과 인수 — 사용자가 합의한 완료 조건으로 확인한다

인수는 완료한 결과가 합의한 요구에 맞는지 확인하고 고객이나 권한 있는 담당자가 공식적으로 받아들이는 것입니다. 개발자가 ‘완료’라고 보고한 것만으로 끝나지 않습니다.

실제 사용자가 대리 승인이나 반려 후 재신청을 해 보고 약속한 동작인지 확인합니다. 남은 오류가 있다면 어떤 업무에 영향을 주고 언제 고칠지 알려야 합니다. 그 근거를 보고 인수할 권한이 있는 사람이 받아들일지 판단합니다.

가상 업무 예시

출장비 신청은 정상 승인되지만 승인자가 휴가 중일 때 대리자에게 전달되지 않습니다. 발주 담당자는 합의한 ‘부재 시 대리 승인’ 기준을 충족하지 못했다고 기록합니다. 임시 수동 처리가 가능한지와 예상 건수·담당자·수정일을 검토해 인수 여부를 결정합니다. 개발자의 완료 보고와 사용자가 합의 조건으로 받아들이는 판단은 별개입니다.

생각해 볼 질문
사용자가 실제 업무 순서대로 시험했나요? 남은 오류가 있어도 사용할 수 있는지는 권한 있는 담당자가 판단했나요?

10. 인수인계와 회고 — 운영할 사람이 이어 갈 수 있게 한다

인수인계는 다음 담당자가 결과물을 실제로 사용하고 관리할 수 있도록 필요한 정보와 일을 넘기는 과정입니다. 프로그램뿐 아니라 계정·설정·장애 대응·문의 경로·남은 문제도 포함합니다.

운영 담당자가 시험 환경에서 재시작과 복구를 직접 해 보면 문서만 읽을 때 놓친 준비물을 찾을 수 있습니다. 프로젝트 회고에서는 누가 잘못했는지만 따지기보다 어떤 조건에서 문제가 생겼고 다음에는 어떤 절차를 바꿀지 정합니다.

가상 업무 예시

문서 전달만으로 인계를 끝내지 않고 운영 담당자가 시험 환경에서 재시작과 복구를 직접 해 봅니다. 부족한 설명을 보완하고, 남은 오류의 담당자와 처리 계획을 합의합니다.

생각해 볼 질문
운영 담당자가 개발자 도움 없이 재시작과 복구를 할 수 있나요? 이번에 겪은 문제를 줄이기 위해 다음 프로젝트에서 무엇을 바꾸나요?

11. 이해관계자 참여 — 필요한 사람을 늦게 부르지 않는다

이해관계자는 프로젝트에 영향을 주거나 결과의 영향을 받는 사람입니다. 요구하는 사람, 실제 사용자, 승인자, 운영자, 보안 담당자 등이 서로 다른 조건을 알고 있을 수 있습니다.

보안 담당자를 공개 직전에 처음 부르면 이미 만든 인증 구조를 크게 바꿔야 할 수 있습니다. 어떤 결정을 하기 전에 누구의 검토가 필요한지 찾아 일정에 넣습니다. 모든 회의에 모두를 부르기보다 해당 결정에 필요한 사람이 참여하게 하는 것이 목적입니다.

가상 업무 예시

외주 개발자는 운영 자료를 바로 내려받아 시험하려 했지만 회사 보안 기준상 실제 고객 자료의 외부 반출이 허용되지 않았습니다. 이를 마지막에 알면 시험 자료와 절차를 다시 만들어야 합니다. 관리자는 설계 단계에 보안·운영 담당자를 참여시켜 가상 시험 자료, 계정 권한, 검토 시점을 합의합니다. 필요한 조건을 가진 사람을 일찍 찾아야 재작업을 줄일 수 있습니다.

생각해 볼 질문
결과물을 사용할 사람, 승인할 사람, 운영할 사람이 요구사항과 완료 기준을 정할 때 참여했나요?

12. 자원 제약과 버퍼 — 담당자의 작업 시간과 일정 여유를 확보한다

일정은 작업 순서뿐 아니라 실제로 일할 사람과 장비의 한계도 고려해야 합니다. 한 사람이 해야 할 세 작업을 달력의 같은 시간에 적었다고 동시에 진행되지는 않습니다.

주공정연쇄기법은 이런 자원 제약과 작업 기간의 불확실성을 고려하고 버퍼, 즉 시간 여유를 두는 일정 계획 방법입니다. 담당자의 실제 작업 가능 시간과 우선순위를 확인하고, 지연이 전체 완료일에 번지지 않도록 확보한 여유가 얼마나 남았는지 관리합니다.

가상 업무 예시

DB 담당자 한 명이 각각 이틀 걸리는 세 팀의 자료 이전을 맡았습니다. 세 팀 모두 월·화요일 완료로 적었지만 같은 사람이 동시에 처리할 수는 없습니다. 관리자는 우선순위에 따라 여섯 작업일을 배정하고 마지막 검증 전에 복구 시험용 여유를 둡니다. 인력을 추가하면 검토·인수인계 시간이 드는지도 확인합니다.

생각해 볼 질문
같은 담당자에게 같은 시간대의 작업을 여러 개 배정하지 않았나요? 실제 일할 수 있는 시간으로 일정을 계산했나요?

13. 비용의 전체 범위 — 개발비 밖의 지출도 포함한다

프로젝트 원가는 일을 끝내기 위해 사용하는 사람·장비·서비스 등의 비용입니다. 원가관리는 필요한 돈을 예상하고 예산을 정한 뒤 실제 지출과 비교하며 조정하는 활동입니다.

소프트웨어 구매비만 잡고 자료 이전과 교육 비용을 빠뜨리면 사용 직전에 예산이 모자랄 수 있습니다. 사용자가 실제로 일을 시작할 때까지 필요한 작업을 기준으로 비용을 계산해야 합니다. 범위나 일정이 바뀌면 비용도 다시 확인합니다.

가상 업무 예시

회사가 업무 도구 이용료 1천만 원만 확보했는데, 기존 자료 정리·이전 300만 원과 사용자 교육 100만 원이 추가로 필요했습니다. 이용권은 샀지만 자료가 없어 새 도구로 일을 시작할 수 없었습니다. 관리자는 구매가 아니라 사용 시작까지 필요한 작업을 기준으로 예산을 다시 잡고, 연간 운영비는 별도 기간으로 비교합니다. 수치는 가상 산정입니다.

생각해 볼 질문
결과물을 실제로 사용할 때까지 드는 비용을 모두 검토했습니까?

14. 의존 작업의 합의 — 다른 팀의 일정도 관리한다

활동 의존관계는 한 작업의 시작이나 완료가 다른 작업의 시작·완료에 어떤 조건을 갖는지 나타냅니다. FS는 앞 작업이 끝나야 다음 작업을 시작할 수 있다는 관계입니다. 예를 들어 화면 설계를 끝낸 뒤 그 설계대로 구현을 시작합니다.

SS는 앞 작업이 시작돼야 다음 작업도 시작할 수 있고, FF는 앞 작업이 끝나야 다음 작업도 끝낼 수 있다는 관계입니다. 반드시 같은 시각에 시작하거나 끝난다는 뜻은 아닙니다. SF는 앞 작업이 시작돼야 다른 작업을 끝낼 수 있는 관계로, 다음 근무자가 일을 시작해야 이전 근무자가 교대를 마치는 상황을 떠올릴 수 있습니다.

다른 팀의 API, 즉 프로그램끼리 요청과 결과를 주고받는 규칙이 필요하다면 주소·입력·응답 예시를 언제 받을지 합의합니다. 자료 도착과 실제 연결 성공도 구분해서 확인합니다.

가상 업무 예시

다른 팀의 API와 연결해야 한다면 개발팀은 호출 주소, 입력 항목, 정상 응답과 오류 응답 예시를 언제 받을지 합의합니다. 자료를 받은 뒤에는 시험 요청을 보내 문서대로 응답하는지 확인하고, 서로 다르게 이해한 항목을 고칩니다.

생각해 볼 질문
외부 팀이 언제 어떤 규격과 예제를 보내야 하는지 합의했나요? 받은 자료로 시험할 수 있는 조건도 정했나요?

15. 획득가치 EV — 완료한 작업의 예산 가치로 진척을 판단한다

획득가치 EV는 실제로 끝낸 작업을 그 작업에 배정했던 예산으로 나타낸 값입니다. 실제로 얼마를 썼는지는 실제비용 AC이고, 그 시점까지 끝내기로 했던 작업의 예산은 계획가치 PV입니다. 세 값은 모두 돈의 단위로 비교합니다.

PV 100만 원, EV 80만 원, AC 90만 원이라면 계획했던 가치보다 적은 일을 완료했고, 끝낸 일에 배정된 예산보다 10만 원을 더 썼습니다. 일정성과지수 SPI는 EV ÷ PV = 0.8, 비용성과지수 CPI는 EV ÷ AC ≈ 0.89입니다. 이 지수는 성과를 비교하는 값이며 완료일이 정확히 며칠 늦는지를 바로 알려 주는 값은 아닙니다.

돈이나 시간을 많이 썼다고 일을 많이 끝낸 것은 아닙니다. 완료를 확인한 결과물을 기준으로 EV를 계산해야 합니다.

가상 업무 예시

같은 시점에 계획 작업의 예산은 100만 원, 검증을 통과한 완료 작업의 예산 가치는 80만 원, 실제 지출은 90만 원이었습니다. 팀은 일정성과지수 0.8과 비용성과지수 약 0.89를 나눠 보고하고, 남은 연동 시험의 지연 원인을 확인했습니다.

생각해 볼 질문
완료한 작업의 예산 가치인 EV를 실제 산출물로 확인했나요? 계획가치 PV와 실제비용 AC를 각각 비교하면 어떤 차이가 있나요?

16. 범위 변경의 누적 — 작은 요청도 합산한다

작은 변경도 여러 번 쌓이면 필요한 작업이 커집니다. 범위 통제에서는 이번 요청 하나의 영향과 지금까지 받아들인 변경의 합계를 함께 확인해야 합니다.

알림 문구만 바꾸는 일은 작아 보여도 대상·시간·조건을 계속 추가하면 확인할 조합이 늘어납니다. 승인한 변경을 모아 구현과 시험에 필요한 시간을 다시 계산하고 공개일이나 다른 기능의 범위를 조정해야 합니다. 승인 없이 조금씩 늘어난 일을 원래 계획 안에 숨기지 않습니다.

가상 업무 예시

팀이 알림에 이메일 외 문자도 넣고, 수신자를 신청자 외 대리자까지 늘리고, 즉시 발송 외 하루 한 번 모아 보내기도 추가했습니다. 요청은 각각 작아 보이지만 채널·수신자·시점 조합의 구현과 시험이 늘었습니다. 관리자는 승인한 변경을 합쳐 남은 작업량을 다시 계산하고 이번 공개에 넣을 조합을 정합니다.

생각해 볼 질문
지금까지 추가된 요청을 모두 합치면 개발과 시험에 며칠이 더 필요한가요? 기존 완료일을 지킬 수 있는지 다시 계산했나요?

17. 갈등 조정 — 사람 대신 판단 기준을 논의한다

갈등 조정은 서로 다른 요구를 공통 목표와 판단 기준으로 비교해 결정하는 일입니다. 목소리가 큰 사람의 요구를 따르는 대신 각 선택이 무엇을 얻고 무엇을 위험하게 하는지 설명합니다.

영업팀은 빠른 공개를, 운영팀은 장애를 줄일 시간을 원할 수 있습니다. 예상되는 오류의 영향과 일정 지연의 영향을 비교하고 일부 기능만 먼저 공개하는 대안도 검토합니다. 팀끼리 합의하기 어려우면 결정권자에게 선택지와 결과를 전달합니다.

가상 업무 예시

영업팀은 월요일 행사에 맞춰 새 결제를 열고 싶지만 운영팀은 중복 결제 시험 실패를 이유로 반대합니다. 회의에서는 ‘빨리’와 ‘안전하게’를 반복하는 대신 중복 청구 피해, 행사 지연 비용, 기존 결제 사용 가능성을 비교합니다. 책임자는 기존 결제로 행사를 시작하고 새 결제는 수정·재시험 뒤 열기로 결정합니다. 기술 위험을 무시한 타협 대신 업무를 이어 갈 대안을 고른 것입니다.

생각해 볼 질문
빨리 공개할 때의 이익과 오류가 남을 때의 피해를 비교했나요? 양쪽 부서가 받아들일 공개 범위와 시점을 정했나요?

18. 의사결정 기한 — 결정 지연이 미룰 작업을 확인한다

정책이나 설계에 대한 결정도 다음 작업을 시작하기 위한 조건입니다. 필요한 결론이 나오지 않으면 개발자가 기다리거나 임의의 가정으로 만들었다가 다시 고쳐야 합니다.

환불 규칙이 정해져야 승인 화면과 시험 사례를 만들 수 있다면 누가 언제까지 규칙을 결정할지 정합니다. 늦어질 때 멈추는 작업을 알리고, 결정 전 진행할 수 있는 일과 나중에 고칠 수 있는 가정도 구분해 기록합니다.

가상 업무 예시

부분 반품 때 배송비를 누가 부담할지 정해지지 않아 개발자가 환불 금액과 안내 문구를 만들 수 없습니다. 관리자는 목요일까지 업무 책임자가 규칙을 확정해야 금요일에 계산·검증을 시작할 수 있다고 알립니다. 결정 전에는 확정된 전체 취소 기능을 만들고, 부분 반품은 추정으로 완성했다고 보고하지 않습니다.

생각해 볼 질문
환불 정책 결정이 늦어지면 어떤 개발·시험이 멈추나요? 결정권자에게 필요한 결정 날짜와 지연 영향을 알렸나요?

19. 지속적 사업 타당성 — 계속할 이유를 재검토한다

지속적 사업 타당성은 프로젝트를 계속할 이유가 아직 있는지 확인하는 원칙입니다. 교재는 PRINCE2의 원칙 중 하나로 설명합니다. 처음에 가치 있던 계획도 요구나 환경이 바뀌면 다시 판단해야 합니다.

이미 비용을 많이 썼다는 사실만으로 계속하는 것이 유리한 것은 아닙니다. 앞으로 더 들 비용, 얻을 효과, 남은 위험을 비교해 유지·축소·방향 변경·중단을 검토합니다. 중단하더라도 자료와 필요한 업무를 어떻게 정리할지 계획해야 합니다.

가상 업무 예시

회사가 종이 영수증을 읽는 전용 장비를 개발하던 중 주요 거래처가 전자 영수증 전송으로 바꿨습니다. 이미 개발비를 많이 썼지만 전용 장비를 끝내도 처리할 물량이 크게 줄어듭니다. 책임자는 남은 개발·유지 비용과 예상 절감액, 전자 영수증 연동안을 비교해 장비 개발을 중단합니다. 이미 쓴 돈보다 앞으로의 비용과 효과가 결정 기준입니다.

생각해 볼 질문
남은 비용을 더 투입해도 원래 기대한 효과를 얻을 수 있나요? 계속 진행·방향 변경·중단 중 어떤 선택이 타당한가요?

20. 학습의 재사용 — 회고에서 정한 개선을 다음 작업에 적용한다

회고는 프로젝트에서 있었던 일을 다음 작업의 개선으로 연결하는 활동입니다. ‘소통을 잘하자’ 같은 결론만 남기면 다음 팀은 무엇을 바꿔야 할지 알기 어렵습니다.

시험 계정 승인이 늦어 개발이 멈췄다면 언제 요청했고 어떤 조건을 놓쳤는지 정리합니다. 다음 프로젝트에서는 외부 계정 신청을 초기 작업에 넣고 담당자와 예상 대기 시간을 확인하도록 절차를 바꿀 수 있습니다. 문제의 상황·원인·대응 결과를 함께 남겨야 다른 팀도 적용 조건을 판단할 수 있습니다.

가상 업무 예시

여러 번 시험 계정 발급이 늦었다면 다음 착수 점검에 신청 기한과 담당자를 넣습니다. 실제로 지연이 줄었는지 다음 회고에서 확인합니다.

생각해 볼 질문
지난 프로젝트에서 반복된 지연을 줄이기 위해 이번에는 무엇을 바꿨나요? 바뀐 절차가 실제로 효과가 있었나요?

교재에서 함께 확인할 내용

위 20개 노트는 교재 개념을 업무에 적용하는 길잡이입니다. 다음 이론과 기법은 별도로 읽고 직접 설명하거나 계산해 보세요. 이 목록도 교재 전체를 대신하지는 않습니다.

1. WBS와 작업 패키지

WBS는 프로젝트가 제공할 결과를 관리 가능한 작업 묶음으로 나눈 구조입니다. ‘서비스 개발’ 하나로 적는 대신 주문 조회·취소 등으로 나누고 각각의 완료 조건을 정하면 담당과 비용을 추정하기 쉽습니다. 작업을 나눈 구조이므로 시작일과 종료일을 표시한 일정표와는 구분합니다.

확인해 보기: 작업표에 “서비스 개발”이라고만 적으면 담당자와 완료 여부를 정하기 어려운 이유는 무엇인가요? 주문 조회 기능을 별도 작업으로 나누고 확인할 동작을 적으면 무엇이 달라지나요?

프로젝트관리 및 테크니컬커뮤니케이션 · 86쪽 →

2. 3점 추정

3점 추정은 잘 풀릴 때의 기간 O, 가장 가능성이 높은 기간 M, 잘 풀리지 않을 때의 기간 P를 함께 사용합니다. 교재의 PERT 계산은 (O+4M+P)/6입니다. O=4일, M=6일, P=10일이면 38/6, 약 6.3일입니다. 불확실성을 고려한 예상이므로 그날 반드시 끝난다는 약속은 아닙니다.

확인해 보기: O=4일, M=6일, P=10일이면 기대 기간은 약 며칠인가요?

프로젝트관리 및 테크니컬커뮤니케이션 · 94쪽 →

3. 주공정법과 여유 시간

주공정법은 먼저 끝나야 하는 작업의 관계와 기간을 이어 전체 완료 시간을 계산하는 방법입니다. 동시에 시작해 모두 끝나야 하는 두 경로가 12일과 16일이면 16일 경로가 전체 완료를 결정합니다. 이런 가장 긴 경로가 주공정입니다. 같은 사람이 여러 작업을 맡는 등의 자원 제약은 추가로 확인해야 합니다.

확인해 보기: 두 병렬 경로가 12일과 16일이면 완료 기간을 결정하는 경로는 어느 쪽인가요?

프로젝트관리 및 테크니컬커뮤니케이션 · 98쪽 →

4. 획득가치 분석

획득가치 분석은 계획한 일, 실제 끝낸 일, 쓴 비용을 같은 금액 기준으로 비교합니다. PV는 계획 작업의 예산, EV는 완료 작업에 배정된 예산, AC는 실제 비용입니다. PV=100만 원·EV=80만 원·AC=90만 원이면 SPI=80/100=0.8, CPI=80/90≈0.89입니다. 계획보다 완료한 일이 적고 그 완료분의 예산보다 돈을 더 쓴 상태입니다. 금액 차이를 지연 일수로 읽지는 않습니다.

확인해 보기: PV=100만 원, EV=80만 원, AC=90만 원일 때 SPI와 CPI는 각각 1보다 큰가요, 작은가요?

프로젝트관리 및 테크니컬커뮤니케이션 · 110쪽 →

5. 품질보증과 품질통제

품질보증은 좋은 결과가 나오도록 검토와 시험 절차를 제대로 운영하는지 살피는 활동입니다. 품질통제는 만들어진 결과를 실제로 검사하는 활동입니다. 코드 검토 절차를 점검하는 일과 납품 기능을 시험해 결함을 찾는 일을 비교하면 초점의 차이를 이해하기 쉽습니다.

확인해 보기: 코드 검토 절차를 점검하는 활동과 인수 테스트 결과를 확인하는 활동은 초점이 어떻게 다른가요?

프로젝트관리 및 테크니컬커뮤니케이션 · 116쪽 →