같은 회사, 두 종류의 일.
수진 씨는 매일 아침 출근하면 어제 밤 배치가 잘 돌았는지 확인하고, 장애 티켓을 처리하고, 백업이 정상인지 점검합니다. 이 일은 끝나지 않습니다. 오늘 잘 끝내도 내일 또 같은 하루가 옵니다. 잘하는 기준은 "서비스가 계속 정상이었는가"입니다.
민호 씨는 6개월짜리 신규 결제 시스템 구축을 맡았습니다. 시작일과 오픈일이 박혀 있고, 만들 기능 목록과 예산, 투입 인력이 정해져 있습니다. 이 일은 오픈하면 끝납니다. 잘하는 기준은 "약속한 범위를, 정해진 일정과 비용 안에서, 쓸 만한 품질로 넘겼는가"입니다.
수진 씨가 하는 건 운영(Operation), 민호 씨가 하는 건 **프로젝트(Project)**입니다. 그리고 민호 씨처럼 "끝이 있는 한시적 노력"을 약속한 제약 안에서 완수시키는 사람이 **PM(프로젝트 관리자)**입니다.
여기서 흔한 오해 하나. 발주사 임원이 민호 씨에게 묻습니다. "PM이면 결제 연동 코드도 직접 짤 수 있어야 하는 것 아닙니까?" 민호 씨가 코딩을 한 줄도 안 해도 프로젝트는 성공할 수 있고, 코딩을 아무리 잘해도 일정·범위 관리를 못 하면 실패합니다. 이 모듈은 그 차이 — 프로젝트란 무엇이고, PM은 정확히 무엇을 관리하는가 — 를 다룹니다.
- 1"프로젝트(유한·고유 결과물)"와 "운영(반복·정상상태 유지)"의 차이를 자기 말로 구분할 수 있다
- 2프로젝트의 3대 제약(범위·일정·비용)과 품질의 관계를 "제약 삼각형"으로 설명할 수 있다
- 3하나의 제약을 바꾸면 다른 제약이 영향받는 트레이드오프를 구체적 예로 들 수 있다
- 4PM이 직접 기술을 구현하기보다 "무엇을·누가·언제·막힌 것·보고·결정"을 관리하는 역할임을 설명할 수 있다
- 5SI 프로젝트에서 PM과 PMO의 관계, 협력사와의 책임 구조를 그릴 수 있다
프로젝트 vs 운영 — 끝이 있는가, 반복되는가
프로젝트는 '유한하고 고유한' 한시적 노력이다
같은 IT 부서 안에서도 일은 크게 두 종류로 갈립니다. 이 구분을 못 하면, 끝이 있어야 할 일을 끝없이 끌거나(프로젝트를 운영처럼), 계속 돌봐야 할 일을 한 번에 끝내려 합니다(운영을 프로젝트처럼).
**프로젝트(Project)**는 "정해진 시작과 끝 사이에, 고유한 결과물(제품·서비스·결과)을 만들어 내는 한시적 노력"입니다. 두 가지가 핵심입니다.
- 유한하다(temporary): 끝이 있습니다. 오픈하거나 인수인계하면 그 프로젝트는 종료됩니다.
- 고유하다(unique): 매번 똑같은 걸 찍어내는 게 아니라, 이번에만 만드는 결과물입니다.
반대로 **운영(Operation)**은 "이미 만들어진 서비스를 정상 상태로 유지하며 반복적으로 수행하는 일"입니다. 끝이 없고(ongoing), 매일 비슷한 일이 반복됩니다(repetitive).
| 구분 기준 | 프로젝트(Project) | 운영(Operation) |
|---|---|---|
| 시간 | 시작·끝이 정해진 한시적 노력 | 끝없이 계속됨(상시) |
| 결과물 | 이번에만 만드는 고유한 결과물 | 반복되는 동일한 산출·서비스 유지 |
| 목표 | 약속한 범위를 일정·비용 안에 완수 | 서비스를 정상 상태(SLA)로 유지 |
| 잘함의 기준 | 범위·일정·비용·품질 달성 | 가용성·안정성·반복 품질 |
| 예시 | 신규 결제 시스템 구축, 차세대 ERP 오픈 | 장애 대응, 배치 모니터링, 정기 백업 |
| 끝나면 | 결과물이 '운영'으로 인계됨 | 계속 돈다(끝 자체가 없음) |
둘은 적이 아니라 이어지는 관계입니다. 프로젝트가 만든 결과물(예: 새 결제 시스템)은 오픈 후 운영으로 넘어가 계속 돌아갑니다. 그래서 프로젝트의 마지막 단계에는 늘 "운영 인계(handover)"가 있습니다. 앞 모듈들에서 다룬 ITSM(인시던트·문제·변경 관리)이 바로 그 '운영'의 언어였고, 이번 모듈부터는 그 앞단인 '프로젝트'의 언어를 봅니다.
제약 삼각형 — 범위·일정·비용, 그리고 품질
하나를 당기면 다른 하나가 딸려 온다
프로젝트가 운영과 결정적으로 다른 점은 세 개의 제약에 동시에 묶여 있다는 것입니다. 이 셋을 흔히 **제약 삼각형(triple constraint)**이라 부릅니다.
- 범위(Scope): 무엇을 만들 것인가. 기능 목록, 요구사항의 범위.
- 일정(Schedule/Time): 언제까지 끝낼 것인가. 마감일, 단계별 일정.
- 비용(Cost): 얼마로 할 것인가. 예산, 투입 인력(공수).
그리고 이 삼각형 가운데에 **품질(Quality)**이 있습니다. 품질은 별개의 네 번째 꼭짓점이 아니라, 세 제약을 어떻게 조였느냐에 따라 결과로 나타나는 값입니다. 범위를 무리하게 늘리고 일정·비용을 그대로 두면, 가장 먼저 깎이는 게 품질입니다.
핵심은 세 제약이 서로 묶여 있다는 점입니다. 하나를 바꾸면 보통 다른 하나 이상이 함께 움직입니다. 이걸 모르면 "기능은 그대로, 일정은 절반, 예산도 그대로"라는 불가능한 요구를 받아들이게 됩니다.
| 고객 요구 | 그대로 받으면 생기는 일 | PM이 꺼낼 카드(트레이드오프) |
|---|---|---|
| "일정을 한 달 당겨주세요" (범위·비용 고정) | 같은 일을 적은 시간에 → 야근·품질 저하·결함 증가 | 범위를 줄이거나(필수 기능만 오픈), 인력·비용을 추가 투입 |
| "기능을 더 넣어주세요" (일정·비용 고정) | 추가 기능을 같은 기간·예산에 → 다른 기능이 부실해짐 | 일정을 미루거나, 비용을 늘리거나, 우선순위 낮은 기능을 뺀다 |
| "예산을 깎아야 합니다" (범위·일정 고정) | 적은 인력으로 같은 범위·기간 → 무리·번아웃·품질 저하 | 범위를 줄이거나, 일정을 늘려 적은 인력으로 소화 |
| "다 그대로, 품질만 높여주세요" | 품질은 공짜가 아님 → 테스트·리뷰 시간 필요 | 일정·비용을 더 쓰거나, 범위를 줄여 핵심에 품질을 집중 |
표의 모든 행에 공통점이 보입니다. "공짜 점심은 없다." 한 꼭짓점을 좋게 만들면 다른 꼭짓점에서 대가를 치릅니다. PM의 일 중 절반은 이 트레이드오프를 고객·이해관계자에게 솔직하게 보여주고, 함께 결정하게 만드는 것입니다. "네, 다 해드리겠습니다"가 아니라 "일정을 당기시려면 이 세 기능 중 하나를 다음 단계로 미루는 걸 권합니다 — 어느 쪽을 택하시겠습니까?"가 PM의 언어입니다.
그림: 한 꼭짓점을 당기면 다른 꼭짓점이 대가를 치르는 제약 삼각형 — PM은 이 트레이드오프를 표로 펼쳐 고객이 함께 결정하게 만든다.
직접 해보기 — 트레이드오프를 표로 만들어 보고하기
아래 상황을 PM의 시각으로 정리해 보세요. 코드도, 명령어도 필요 없습니다 — 표 한 장이 PM의 산출물입니다.
상황: SI 결제 시스템 구축 프로젝트(범위 12개 기능, 6개월, 예산 6억).
오픈 D-30, 고객이 "쿠폰·포인트 기능 2개를 추가로 넣어 오픈하자"고 요청.
일정(오픈일)과 예산은 더 못 늘린다고 함.
해야 할 일:
- 이 요청이 건드리는 제약이 무엇인지 적는다(범위? 일정? 비용? 품질?).
- "그대로 수용하면" 어떤 제약이 깨지는지 한 줄로 쓴다.
- PM이 고객에게 제시할 선택지 2~3개를 트레이드오프 표로 만든다.
- 표 맨 아래에 "PM 권고안"과 "고객 결정 필요 사항"을 한 줄씩 단다.
작성한 표가 ObserveBlock의 예시와 같은 구조인지 비교해 보세요. 핵심은 "안 됩니다"가 아니라 **"이렇게 하면 됩니다, 단 대가는 이것입니다"**로 말이 끝나는가입니다.
범위 / 일정 / 비용 / 품질 영향 정리- 건드리는 제약: 범위(+기능 2개). 일정·비용은 고객이 고정 선언 → 품질이 희생될 위험이 가장 큼
- 그대로 수용하면: 같은 일정·예산에 기능만 2개 추가 → 테스트 시간 부족 → 결제 시스템에 결함 위험(가장 위험한 시나리오)
- 선택지 A: 두 기능을 2차 릴리스(오픈 +1개월 후)로 분리 → 1차 오픈 일정·품질 사수 (PM 권고안)
- 선택지 B: 인력 2명 추가 투입(비용↑ 약 4천만) → 일정 내 추가 기능 소화, 단 예산 증액 결재 필요
- 선택지 C: 기존 12개 중 우선순위 낮은 기능 2개를 빼고 신규 2개로 교체 → 범위 총량 유지, 단 고객 합의 필요
- 표 맨 아래: "PM 권고 = A(단계적 오픈). 고객 결정 필요 = 예산 증액(B) 가능 여부 / 기능 교체(C) 동의 여부"
- 핵심 감각: PM의 산출물은 코드가 아니라 "결정 가능한 선택지" — 트레이드오프를 숨기지 않고 표로 펼쳐 고객이 고르게 만든다
현장에서 자주 보는 함정
증상: 프로젝트 초·중반에는 별문제가 없어 보입니다. 고객이 기능을 추가해도, 일정을 당겨달라 해도 PM이 "네, 맞춰보겠습니다"로 받습니다. 그런데 오픈 D-30쯤부터 갑자기 모든 게 한꺼번에 터집니다 — 기능은 미완성, 테스트할 시간은 없고, 팀은 번아웃, 품질 사고가 연달아 납니다.
원인: 제약이 묶여 있다는 사실을 고객에게 보여주지 않았기 때문입니다. 범위를 늘릴 때마다 누군가는 일정·비용·품질에서 대가를 치러야 하는데, PM이 그 대가를 그때그때 '눈에 안 보이게' 삼켜버렸습니다(야근으로, 테스트 생략으로). 보이지 않는 부채는 사라지지 않고 막판에 한꺼번에 청구됩니다.
해결 방향:
- 요구가 들어올 때마다 제약 영향을 즉시 표로 가시화한다 — "이 기능을 넣으면 범위 +X, 그래서 일정 +Y 또는 비용 +Z가 필요합니다."
- "안 됩니다"가 아니라 **"이렇게 하면 됩니다, 대가는 이것입니다"**로 선택지를 준다. 결정은 고객 몫으로 넘긴다.
- 변경된 합의는 반드시 문서로 남긴다(범위 변경 요청서). 말로 받은 추가 기능은 나중에 "그건 원래 범위였잖아요" 분쟁이 된다.
- 품질(테스트·리뷰)을 일정의 일부로 박아둔다. "시간 남으면 하는 것"이 아니라 처음부터 일정에 포함.
PM의 핵심 역량은 코딩 실력이 아니라, 트레이드오프를 숨기지 않고 제때 드러내 고객과 함께 결정하는 정직함입니다.
한국의 IT 현장에서 이 모듈이 향하는 가장 흔한 자리는 SI(System Integration) 프로젝트의 PM입니다. 발주사(고객)가 "차세대 시스템을 만들어 달라"며 발주하면, 수행사(SI 업체)가 PM을 세우고, 그 아래 분석·설계·개발·테스트 인력과 협력사(하도급) 엔지니어가 붙어 실제 구현을 합니다.
이 구조에서 PM인 당신은 보통 직접 코딩하지 않습니다. 대신 "무엇을 만들지(범위)·누가 맡을지(자원)·언제까지(일정)·지금 무엇이 막혔는지(이슈·리스크)·고객에게 무엇을 보고하고 무엇을 결정받을지"를 관리합니다. 주간 보고, 진척률(EVM), 위험 관리, 변경 요청 처리, 검수·인수인계가 당신의 일상입니다. 협력사 엔지니어가 코드를 짜더라도, 범위·일정·비용·품질에 대한 책임은 PM에게 있습니다. 그래서 기술을 아는 PM은 협력사와 대등하게 대화하고, "이건 원래 두 배 걸리는 일입니다" 같은 말에 휘둘리지 않습니다.
여기에 **PMO(Project Management Office)**가 한 겹 더 있습니다. PMO는 여러 프로젝트를 가로질러 공통의 관리 기준 — 산출물 양식, 진척 보고 주기, 리스크 관리 방식, 품질 기준 — 을 제공하고, 각 PM이 그 표준을 지키는지 점검·지원합니다. PMO는 일일 작업을 지시하는 곳이 아니라 '관리의 틀과 전사적 가시성'을 제공하는 조직입니다. 큰 SI 사업일수록 "PM은 한 프로젝트를 끌고, PMO는 여러 프로젝트를 같은 기준으로 보이게 한다"는 분업이 또렷합니다. 면접에서 "PM과 PMO의 차이"를 묻는 것도 이 분업을 이해하는지 보려는 것입니다.
관련 모듈로 더 깊이:
- PMBOK 7 — PM의 일을 글로벌 표준의 원칙·성과 영역으로 체계화한 틀
- 범위와 요구사항 — 3대 제약의 출발점인 '범위'를 정의하고 통제하는 법
- 프로젝트 역할 — PM·PMO·발주사·협력사가 SI 구조에서 맡는 역할 구분
다음 모듈에서는 이 PM의 일을 글로벌 표준으로 체계화한 PMBOK 7판의 12가지 원칙과 8개 성과영역을 한 장의 지도로 정리해, "프로젝트를 끌고 가는 사고의 뼈대"를 세웁니다.