- Authors
- Name
- Youngju Kim
- @fjvbn20031
들어가며
어떤 조직에서든 일은 결국 누군가가 되게 만들어야 합니다. 좋은 아이디어, 충분한 예산, 유능한 사람이 모두 있어도 그것을 묶어 결과물로 만드는 힘이 없으면 일은 표류합니다. 프로젝트 매니징은 바로 그 힘, 즉 흩어진 자원과 사람과 시간을 하나의 목표로 수렴시키는 기술입니다.
이 글은 처음 프로젝트 매니징을 맡게 된 분, 혹은 어깨너머로 PM 역할을 해 오다가 한 번쯤 기초를 제대로 정리하고 싶은 분을 위해 썼습니다. 화려한 방법론이나 자격증 이론보다는, 실제로 일을 굴릴 때 머릿속에 있어야 하는 골격을 다룹니다. 용어는 PMI의 PMBOK 가이드와 애자일 진영의 표준을 따르되, 현장에서 통하는 언어로 풀어 보겠습니다.
먼저 가장 근본적인 질문부터 시작합니다. 프로젝트란 대체 무엇일까요.
프로젝트란 무엇인가
운영 업무와 프로젝트는 다릅니다. 매달 급여를 정산하고, 매일 고객 문의에 답하는 일은 끝이 정해져 있지 않은 반복적인 운영입니다. 반면 프로젝트는 고유한 결과물을 만들기 위해 한시적으로 수행하는 노력입니다. 시작과 끝이 분명하고, 만들어 내는 산출물이 이전과는 다른 무언가라는 점이 핵심입니다.
PMBOK은 프로젝트를 다음 두 가지 특성으로 정의합니다.
- 한시성(temporary): 명확한 시작과 끝이 있습니다. 목표를 달성했거나, 달성할 수 없다고 판단되거나, 더 이상 필요가 없어지면 종료됩니다.
- 고유성(unique): 산출물, 서비스, 결과가 어떤 식으로든 이전과 다릅니다. 비슷한 건물을 또 짓더라도 위치, 설계, 팀이 다르면 그것은 새로운 프로젝트입니다.
신제품 출시, 시스템 마이그레이션, 사옥 이전, 행사 기획은 모두 프로젝트입니다. 반대로 그 제품을 매일 판매하고 지원하는 일은 운영입니다.
삼중 제약: 범위, 일정, 예산의 삼각형
프로젝트 매니징을 한 장의 그림으로 압축하면 삼각형이 됩니다. 흔히 삼중 제약(triple constraint) 또는 프로젝트 관리의 삼각형이라고 부릅니다. 세 변은 서로 묶여 있어서, 하나를 건드리면 나머지가 반드시 영향을 받습니다.
품질(Quality)
▲
╱ ╲
╱ ╲
╱ ╲
범위 ╱ ╲ 일정
(Scope) ╱ 품질이 ╲ (Schedule)
╱ 가운데에 ╲
╱ 균형을 ╲
╱ 잡는다 ╲
╱_________________╲
예산(Cost)
범위를 늘리면 ──▶ 일정이 늘거나 예산이 는다
일정을 줄이면 ──▶ 범위를 줄이거나 예산이 는다
예산을 줄이면 ──▶ 범위를 줄이거나 일정이 는다
이 삼각형이 주는 교훈은 단순하지만 강력합니다. 더 많이(범위), 더 빨리(일정), 더 싸게(예산)를 동시에 전부 만족시킬 수는 없습니다. 이해관계자가 세 가지를 모두 요구할 때, PM의 일은 그중 무엇이 고정값이고 무엇이 협상 가능한지를 분명히 하는 것입니다.
예를 들어 출시일이 마케팅 행사에 묶여 절대 못 미루는 상황이라면, 일정은 고정입니다. 그러면 범위(기능 일부 축소)나 예산(추가 인력 투입) 중 하나를 조정해야 합니다. 이 트레이드오프를 말로 분명히 합의해 두지 않으면, 나중에 "약속한 게 다 안 됐다"는 갈등으로 돌아옵니다.
PM의 역할
프로젝트 매니저는 모든 것을 직접 하는 사람이 아닙니다. 모든 것이 되게 만드는 사람입니다. 코드를 직접 짜지 않아도, 디자인을 직접 그리지 않아도, 그 모든 조각이 제때 맞물려 돌아가도록 조율하는 것이 PM의 본업입니다.
핵심 책임을 정리하면 다음과 같습니다.
- 계획 수립: 목표를 작업으로 쪼개고, 순서와 일정과 자원을 배치합니다.
- 조율과 소통: 팀, 이해관계자, 외부 협력사 사이의 정보 흐름을 책임집니다. PM은 정보의 허브입니다.
- 리스크 관리: 무엇이 잘못될 수 있는지 미리 식별하고 대비책을 준비합니다.
- 의사결정 촉진: 막힌 결정을 빠르게 풀리도록 적절한 사람을 모으고 정보를 갖춥니다.
- 진척 추적과 보고: 계획 대비 현재 어디에 있는지 측정하고, 솔직하게 보고합니다.
PM이 가진 권한은 조직마다 다릅니다. 인사권과 예산권을 모두 쥔 강한 PM도 있고, 직접 권한 없이 영향력만으로 사람을 움직여야 하는 약한 PM도 있습니다. 후자가 훨씬 흔하며, 그래서 PM에게는 공식 권한보다 신뢰와 설득력이 더 중요한 무기인 경우가 많습니다.
프로젝트 생애주기
프로젝트는 일정한 흐름을 따라 움직입니다. PMBOK은 이를 다섯 개의 프로세스 그룹으로 정리합니다. 착수, 계획, 실행, 감시 및 통제, 종료입니다. 이 다섯 단계는 한 번 지나가는 직선이 아니라, 특히 감시와 통제가 실행과 계획 사이를 끊임없이 오가는 순환 구조입니다.
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ 착수 │──▶ │ 계획 │──▶ │ 실행 │──▶ │ 종료 │
│Initiating │ │ Planning │ │ Executing │ │ Closing │
└───────────┘ └─────▲─────┘ └─────┬─────┘ └───────────┘
│ │
│ ┌────────────▼────────────┐
└───│ 감시 및 통제 │
│ Monitoring & Controlling│
│ (전 기간에 걸쳐 작동) │
└─────────────────────────┘
각 단계가 실제로 무엇을 하는지 봅시다.
- 착수(Initiating): 프로젝트가 존재해야 할 이유를 정의합니다. 비즈니스 케이스, 목표, 핵심 이해관계자, 대략적 범위를 담은 프로젝트 헌장(project charter)을 만들고 공식적으로 출발 승인을 받습니다.
- 계획(Planning): 어떻게 할지를 구체화합니다. 범위를 작업으로 분해하고(WBS), 일정과 예산을 세우고, 리스크를 식별하고, 소통 계획을 짭니다. 대부분의 프로젝트는 여기서 충분히 시간을 쓰지 않아 나중에 대가를 치릅니다.
- 실행(Executing): 계획을 실제 작업으로 옮깁니다. 사람이 일을 하고 산출물이 나옵니다. PM의 시간 대부분이 조율과 장애물 제거에 쓰입니다.
- 감시 및 통제(Monitoring & Controlling): 계획 대비 실제를 비교하고, 차이가 생기면 바로잡습니다. 범위 변경 요청을 통제하고, 일정과 예산을 추적하며, 리스크를 모니터링합니다. 전 기간 내내 병행됩니다.
- 종료(Closing): 산출물을 공식적으로 인수인계하고, 계약을 정리하고, 교훈(lessons learned)을 기록합니다. 흐지부지 끝내지 않고 매듭을 짓는 것이 다음 프로젝트의 자산이 됩니다.
범위 관리와 WBS
프로젝트가 무너지는 가장 흔한 지점 중 하나가 범위입니다. 무엇을 만들고 무엇을 만들지 않을지가 흐릿하면, 일은 끝없이 늘어납니다. 그래서 범위를 명확히 정의하고, 그것을 관리 가능한 단위로 쪼개는 일이 중요합니다.
작업 분해 구조(WBS)
작업 분해 구조(Work Breakdown Structure, WBS)는 프로젝트의 전체 산출물을 점점 더 작은 단위로 계층적으로 쪼갠 그림입니다. 핵심 원칙은 산출물 중심으로 쪼갠다는 것입니다. 즉 "무엇을 할 것인가(동사)"가 아니라 "무엇이 나올 것인가(명사, 산출물)"를 기준으로 나눕니다.
가상의 사내 모바일 앱 프로젝트를 WBS로 그려 보겠습니다.
1. 사내 모바일 앱
│
├── 1.1 기획 및 설계
│ ├── 1.1.1 요구사항 정의서
│ ├── 1.1.2 화면 설계서(와이어프레임)
│ └── 1.1.3 UI 디자인 시안
│
├── 1.2 개발
│ ├── 1.2.1 백엔드 API
│ │ ├── 1.2.1.1 인증 모듈
│ │ └── 1.2.1.2 데이터 모듈
│ ├── 1.2.2 모바일 클라이언트
│ │ ├── 1.2.2.1 로그인 화면
│ │ └── 1.2.2.2 대시보드 화면
│ └── 1.2.3 인프라 구성
│
├── 1.3 테스트
│ ├── 1.3.1 통합 테스트 결과서
│ └── 1.3.2 사용성 테스트 보고서
│
└── 1.4 출시 및 인수
├── 1.4.1 배포 패키지
└── 1.4.2 사용자 매뉴얼
WBS의 가장 아래 단위를 작업 패키지(work package)라고 부릅니다. 작업 패키지는 한 사람 또는 한 팀에 맡길 수 있을 만큼 작고, 일정과 비용을 산정할 수 있을 만큼 구체적이어야 합니다. 너무 크면 추정이 부정확해지고, 너무 잘게 쪼개면 관리 비용이 늘어납니다. 경험적으로는 한 작업 패키지가 며칠에서 2주 정도 분량이 되도록 잡는 경우가 많습니다.
WBS를 제대로 그리면 두 가지 큰 이득이 있습니다. 첫째, 빠진 작업이 눈에 보입니다. 둘째, 이 분해 단위가 그대로 일정과 예산 산정의 기반이 됩니다.
100퍼센트 규칙
WBS에는 100퍼센트 규칙이라는 원칙이 있습니다. 어떤 단계의 하위 항목을 모두 합치면 그 상위 항목의 100퍼센트가 되어야 하며, 그 이상도 이하도 아니어야 한다는 뜻입니다. 즉 빠진 작업도 없고, 범위 밖의 군더더기 작업도 없어야 합니다. 이 규칙은 범위 누락과 범위 초과를 동시에 막아 줍니다.
일정 관리
범위를 쪼갰다면 이제 순서와 시간을 입혀야 합니다. 일정 관리의 핵심 도구는 간트 차트와 임계경로입니다.
간트 차트
간트 차트(Gantt chart)는 작업을 가로 막대로, 시간을 가로축으로 표현한 그림입니다. 어떤 작업이 언제 시작하고 끝나는지, 어떤 작업이 겹치는지를 한눈에 보여 줍니다. 막대 사이의 화살표는 선후 관계(의존성)를 나타냅니다.
작업 1주 2주 3주 4주 5주 6주
─────────────────┼────┼────┼────┼────┼────┼────┤
요구사항 정의 ████
화면 설계 ████
백엔드 개발 ██████████
프론트 개발 ██████████
통합 테스트 ████
출시 준비 ████
─────────────────┼────┼────┼────┼────┼────┼────┤
◆ 착수 ◆ 중간점검 ◆ 출시
(마일스톤) (마일스톤) (마일스톤)
다이아몬드 기호로 표시한 마일스톤(milestone)은 기간이 없는 중요한 시점입니다. 착수 승인, 베타 공개, 정식 출시처럼 "여기까지 왔다"를 확인하는 지점이죠. 마일스톤은 진척을 객관적으로 점검하고 이해관계자에게 보고하기 좋은 기준점이 됩니다.
의존성의 네 가지 유형
작업 사이의 선후 관계에는 네 가지 유형이 있습니다.
- 종료-시작(FS): 앞 작업이 끝나야 다음이 시작됩니다. 가장 흔합니다.
- 시작-시작(SS): 앞 작업이 시작되면 다음도 시작할 수 있습니다.
- 종료-종료(FF): 앞 작업이 끝나야 다음도 끝낼 수 있습니다.
- 시작-종료(SF): 드물게 쓰이며, 앞 작업이 시작되어야 다음을 끝낼 수 있습니다.
임계경로
임계경로(critical path)는 프로젝트를 끝내는 데 걸리는 가장 긴 작업의 연쇄입니다. 다르게 말하면, 이 경로 위의 작업 중 하나라도 늦어지면 프로젝트 전체가 늦어집니다. 반대로 임계경로 밖에 있는 작업은 약간의 여유(float, slack)가 있어서 조금 늦어도 전체 일정에 영향을 주지 않습니다.
아래 그림에서 각 노드는 작업이고, 괄호 안 숫자는 소요 일수입니다.
┌──[B: 설계 5일]──┐
│ │
[A: 착수]──┤ ├──[D: 통합 3일]──[E: 출시 2일]
2일 │ │
└──[C: 조사 3일]──┘
경로 1: A ─ B ─ D ─ E = 2 + 5 + 3 + 2 = 12일 ◀ 임계경로
경로 2: A ─ C ─ D ─ E = 2 + 3 + 3 + 2 = 10일
▶ 작업 C는 2일의 여유(float)가 있다.
C가 2일 늦어도 전체 일정 12일은 그대로다.
▶ 작업 B는 여유가 0이다.
B가 하루 늦으면 프로젝트도 하루 늦는다.
임계경로를 아는 것이 왜 중요할까요. 일정을 단축하거나 지키고 싶다면, 노력과 자원을 임계경로 위의 작업에 집중해야 하기 때문입니다. 여유가 있는 작업에 인력을 더 넣는 것은 전체 일정에 도움이 되지 않습니다. 한정된 자원을 어디에 쓸지 결정할 때 임계경로는 명확한 우선순위를 알려 줍니다.
이해관계자 관리
프로젝트는 진공 속에서 진행되지 않습니다. 그 결과에 영향을 주거나 받는 모든 사람과 조직을 이해관계자(stakeholder)라고 부릅니다. 스폰서, 고객, 사용자, 팀원, 협력사, 심지어 규제 기관까지 포함될 수 있습니다.
이해관계자를 관리하는 첫걸음은 식별과 분류입니다. 흔히 권력과 관심도의 두 축으로 나눈 격자(power-interest grid)를 씁니다.
관심도 높음 관심도 낮음
┌────────────────────┬────────────────────┐
권력 │ 긴밀히 관리 │ 만족 유지 │
높음 │ (Manage Closely) │ (Keep Satisfied) │
│ 스폰서, 핵심 고객 │ 상위 임원, 재무팀 │
├────────────────────┼────────────────────┤
권력 │ 정보 제공 │ 모니터링 │
낮음 │ (Keep Informed) │ (Monitor) │
│ 실사용자, 현업팀 │ 주변 부서 │
└────────────────────┴────────────────────┘
분류에 따라 대응 전략이 달라집니다. 권력과 관심이 모두 높은 사람은 의사결정에 깊이 관여시키고 수시로 소통합니다. 권력은 높지만 관심이 낮은 사람은 불만이 생기지 않을 만큼만 적절히 만족시킵니다. 관심은 높지만 권력이 낮은 사람에게는 충실히 정보를 제공합니다. 둘 다 낮은 사람은 가볍게 모니터링하면 됩니다.
여기서 핵심은 소통의 양이 아니라 적절함입니다. 모두에게 모든 것을 똑같이 쏟아붓는 것은 비효율적일뿐더러 정작 중요한 신호를 묻어 버립니다. 이해관계자별로 무엇을, 얼마나 자주, 어떤 형식으로 전달할지를 소통 계획으로 정해 두면 훨씬 매끄럽게 굴러갑니다.
폭포수와 애자일
프로젝트를 끌고 가는 방식에는 크게 두 갈래가 있습니다. 단계를 차례로 밟아 나가는 폭포수(waterfall)와, 짧은 주기로 만들고 점검하며 나아가는 애자일(agile)입니다.
폭포수
폭포수는 요구사항, 설계, 개발, 테스트, 배포를 순서대로 한 번씩 거치는 방식입니다. 마치 물이 위에서 아래로 떨어지듯 앞 단계가 끝나야 다음 단계로 넘어갑니다.
요구사항 ──▶ 설계 ──▶ 개발 ──▶ 테스트 ──▶ 배포
(한 단계가 끝나야 다음으로. 되돌아가기 어렵다.)
폭포수는 요구사항이 명확하고 변동이 적은 프로젝트에 강합니다. 건설, 제조, 규제가 엄격한 분야에서 흔히 쓰입니다. 다만 후반에 가서 큰 변경이 필요해지면 비용이 크게 듭니다.
애자일
애자일은 전체를 한 번에 만들지 않고, 짧은 반복 주기(이터레이션, 스크럼에서는 스프린트)마다 작동하는 결과물을 조금씩 만들어 점검하고 방향을 조정합니다.
┌─ 스프린트 1 ─┐ ┌─ 스프린트 2 ─┐ ┌─ 스프린트 3 ─┐
│ 계획 │ │ 계획 │ │ 계획 │
│ ▼ │ │ ▼ │ │ ▼ │
│ 개발 ▶ 검토 │ │ 개발 ▶ 검토 │ │ 개발 ▶ 검토 │
│ ▼ │ │ ▼ │ │ ▼ │
│ 회고 ────────┼▶│ 회고 ────────┼▶│ 회고 │
└──────────────┘ └──────────────┘ └──────────────┘
결과물 v0.1 결과물 v0.2 결과물 v0.3
(매 주기마다 작동하는 산출물이 나온다)
애자일은 요구사항이 불확실하거나 자주 바뀌는 프로젝트, 빠른 피드백이 중요한 소프트웨어 개발에서 강점을 보입니다. 대표적인 프레임워크로 스크럼과 칸반이 있습니다.
비교표
| 구분 | 폭포수(Waterfall) | 애자일(Agile) |
|---|---|---|
| 진행 방식 | 단계 순차 진행 | 짧은 반복 주기 |
| 요구사항 | 초기에 확정 | 진행하며 발전 |
| 변경 수용 | 어렵고 비용 큼 | 유연하게 수용 |
| 산출물 시점 | 후반에 한 번 | 매 주기마다 |
| 고객 참여 | 시작과 끝 위주 | 전 과정 지속 |
| 적합한 경우 | 명확하고 안정적인 범위 | 불확실하고 변동 큰 범위 |
| 위험 노출 | 후반에 몰림 | 매 주기 분산 |
현실에서는 둘을 섞은 하이브리드도 많습니다. 큰 일정과 예산은 폭포수처럼 단계로 관리하되, 개발 내부는 애자일로 굴리는 식입니다. 중요한 것은 방법론을 신봉하는 것이 아니라, 프로젝트의 성격에 맞는 방식을 고르는 판단입니다.
흔한 실패와 그 처방
프로젝트가 어그러지는 양상은 의외로 비슷합니다. 자주 마주치는 함정과 대처법을 정리합니다.
범위 크리프
범위 크리프(scope creep)는 통제되지 않은 채 범위가 슬금슬금 늘어나는 현상입니다. "이것도 추가로 해 주세요"가 공식 절차 없이 하나둘 쌓이다 보면, 일정과 예산은 그대로인데 할 일만 불어납니다.
처방은 변경 통제 프로세스입니다. 모든 범위 변경 요청을 문서로 받고, 그것이 일정과 예산에 미치는 영향을 평가한 뒤, 승인권자가 명시적으로 결정하게 합니다. "안 됩니다"가 아니라 "그것을 하면 출시가 2주 늦어지는데, 그래도 진행할까요"라고 트레이드오프를 보여 주는 것이 핵심입니다.
일정 지연
일정 지연은 거의 모든 프로젝트가 마주합니다. 원인은 낙관적 추정, 숨은 의존성, 예상치 못한 리스크 등 다양합니다. 특히 임계경로상의 작업이 늦어지면 곧장 전체 지연으로 이어집니다.
처방은 솔직하고 빠른 인지입니다. 지연을 숨기다가 마지막에 폭로하는 것이 최악입니다. 마일스톤마다 실제 진척을 측정하고, 임계경로를 주시하며, 버퍼(여유 시간)를 의도적으로 확보해 두는 것이 좋습니다.
추정 오류
작업이 얼마나 걸릴지 사람은 본능적으로 과소평가합니다. 이를 계획 오류(planning fallacy)라고 합니다.
처방은 과거 데이터에 기반한 추정과 여러 사람의 교차 검증입니다. 비슷한 작업이 실제로 얼마나 걸렸는지 기록을 참고하고, 최선과 최악을 함께 추정해 범위로 다루는 것이 단일 숫자보다 정직합니다.
소통 단절
이해관계자가 프로젝트 상황을 모르거나, 팀 안에서 정보가 막히면 곳곳에서 잘못된 가정이 자랍니다. 늦게 발견된 오해는 큰 재작업으로 돌아옵니다.
처방은 정기적이고 예측 가능한 소통 리듬입니다. 짧은 일일 점검, 주간 상태 보고, 마일스톤 리뷰처럼 정해진 주기를 만들어 두면 정보가 고이지 않습니다.
모호한 책임
누가 무엇을 책임지는지 불분명하면, 모두의 일은 누구의 일도 아니게 됩니다.
처방은 책임의 명문화입니다. RACI(실무 담당, 최종 책임, 자문, 정보 공유) 같은 도구로 작업별 역할을 분명히 해 두면 공백과 중복이 줄어듭니다.
실무 운영 팁
이론을 알았다면 이제 실제로 굴릴 차례입니다. 현장에서 통하는 몇 가지 운영 원칙을 덧붙입니다.
- 킥오프를 제대로 하라: 목표, 범위, 역할, 일정, 소통 방식을 첫 회의에서 한 번에 정렬해 두면 이후의 혼선이 크게 줄어듭니다.
- 단 하나의 진실의 원천을 두라: 일정과 작업 현황은 한 곳에서만 관리합니다. 여러 문서가 따로 돌면 반드시 어긋납니다.
- 나쁜 소식을 빨리 올려라: 문제는 시간이 지날수록 비싸집니다. 작을 때 드러내는 문화를 PM이 먼저 만들어야 합니다.
- 회의는 결정과 행동으로 끝내라: 모든 회의는 누가, 무엇을, 언제까지 한다는 액션 아이템으로 마무리합니다.
- 회고를 거르지 마라: 끝난 뒤 무엇이 잘됐고 무엇을 바꿀지 기록하면, 그것이 다음 프로젝트의 출발점이 됩니다.
시작 전 체크리스트
프로젝트를 시작하기 전, 다음 질문에 답할 수 있어야 합니다.
- 이 프로젝트가 왜 필요한지(비즈니스 케이스) 한 문장으로 말할 수 있는가
- 성공의 기준이 측정 가능한 형태로 정의되어 있는가
- 범위에 포함되는 것과 포함되지 않는 것이 문서로 명시되어 있는가
- 삼중 제약 중 무엇이 고정이고 무엇이 협상 가능한지 합의되어 있는가
- 핵심 이해관계자가 식별되고 분류되어 있는가
- 작업이 WBS로 분해되어 작업 패키지 수준까지 내려와 있는가
- 임계경로와 주요 마일스톤이 파악되어 있는가
- 주요 리스크가 식별되고 대응책이 마련되어 있는가
- 소통 계획(무엇을 누구에게 얼마나 자주)이 정해져 있는가
- 변경 통제 절차가 합의되어 있는가
- 폭포수, 애자일, 하이브리드 중 어떤 방식으로 진행할지 정해져 있는가
이 목록을 모두 채우지 못한 채 출발하는 프로젝트가 사실 대부분입니다. 그러나 빈칸이 어디인지 아는 것만으로도 위험을 크게 줄일 수 있습니다.
마치며
프로젝트 매니징의 기초는 화려하지 않습니다. 범위를 분명히 하고, 작업으로 쪼개고, 순서와 시간을 입히고, 사람을 정렬하고, 진척을 정직하게 추적하는 것. 이 단순한 골격을 꾸준히 지키는 팀이 결국 일을 되게 만듭니다.
좋은 PM은 모든 답을 가진 사람이 아니라, 올바른 질문을 제때 던지는 사람입니다. 무엇이 고정이고 무엇이 협상 가능한가. 지금 가장 위험한 작업은 무엇인가. 누가 이 결정을 내려야 하는가. 이 질문들을 습관처럼 던지다 보면, 방법론은 도구가 되고 판단은 당신의 것이 됩니다.
처음 PM 역할을 맡았다면, 완벽한 계획을 세우려 애쓰기보다 이 글의 골격을 한 바퀴 돌려 보는 것에서 시작하세요. 일은 계획대로 흘러가지 않지만, 골격이 있는 사람은 흔들려도 다시 중심을 잡을 수 있습니다.
참고 자료
- Project Management Institute (PMI) — PMBOK 가이드와 프로젝트 관리 표준의 본산
- Atlassian Agile Coach — 애자일, 스크럼, 칸반에 대한 실무 가이드
- Scrum.org — What is Scrum? — 스크럼 프레임워크 공식 설명
- Scrum Guide — 스크럼의 정의를 담은 공식 가이드
- Manifesto for Agile Software Development — 애자일 선언문 원문