일과 기술 목록으로
PMP 로드맵 12부 표지. PMP 따고 실무에서 달라진 점이라는 제목과 AT WORK 문구, 빨간 PMP 도장
일과 기술

PMP 따고 실무에서 달라진 점: 자격증보다 '말하는 방식'이 바뀌었다

PMP 합격 후 석 달 가까이, 글로벌 테크 PM으로 일하며 달라진 습관을 정리했다. 범위·변경 요청·리스크 같은 공통 언어, 행동 전 평가, 가치 중심 사고, 하이브리드 테일러링까지.

유지보수v1.0버전작성 2026년 9월 28일→ 갱신 2026년 9월 28일
시리즈: PMP 합격 로드맵

파트 12 / 15

100% complete15 / 15 articles

지난 편에서는 PMP를 3년 동안 유지하기 위한 60 PDU 계획을 세웠습니다. 그럼 이 자격증, 유지할 만한 가치가 있을까요? 오늘은 그 질문의 절반인 실무 이야기를 해 보겠습니다.

3줄 요약 — PMP가 바꾼 건 지식의 양보다 일하는 순서였습니다. 같은 단어를 같은 뜻으로 쓰고, 이슈 앞에서 평가부터 하고, 변경은 기록으로 받고, 결과물보다 가치를 묻게 됐습니다. 다만 합격한 지 석 달이 채 안 됐고, 자격증이 일을 대신해 주지는 않습니다.

제가 일하는 환경부터

지금 저는 Concentrix에서 Global Tech PM으로 일합니다. 엔터프라이즈 고객사의 ShopifyShopify디지털 및 실물 매장을 호스팅하고 다국어 번역, 글로벌 결제 및 맞춤형 앱 생태계를 제공하는 세계적인 커머스 플랫폼입니다.Read More →·Magento 커머스 구축과 고도화를 맡고 있고, 우선순위 정리부터 리스크 관리, UAT(사용자 인수 테스트), 릴리스, 오픈 직후 안정화까지 챙깁니다.

일하면서 만나는 사람은 고객사 본사 팀, 나라별 현지 법인, 글로벌 벤더, 해외 기술팀입니다. 규모를 하나만 예로 들면, 글로벌 뷰티 그룹의 PDP(상품 상세 페이지) 생성 SaaS를 고도화해 5개 브랜드, 27개 이커머스 사이트로 넓히는 일을 맡았습니다. 결정 하나가 여러 브랜드와 여러 나라로 한꺼번에 퍼지는 구조입니다.

그 전에는 Hyperhire에서 Software Development PM으로 웹, 앱, SaaS, 블록체인 프로젝트를 맡았습니다. 함께 일한 개발자들은 인도, 파키스탄, 인도네시아, 나이지리아, 에티오피아에 있었습니다. 나라도 다섯, 시간대도 제각각이었죠.

이런 환경에서 일이 엇나가는 건 대개 기술보다 말에서 시작된다고 생각합니다. 그래서 PMP 이후 달라진 것도 대부분 “말”과 “순서”였습니다.

참고로 이 일들은 모두 PMP를 따기 전부터 해 오던 일입니다. 자격증이 생겼다고 하는 일이 바뀐 게 아니라, 같은 일을 하는 방식이 조금씩 바뀌었습니다.

가장 먼저 바뀐 건 단어였다

PM으로 일하면서 scope, change request, risk 같은 단어는 PMP 전에도 늘 썼습니다. 그런데 PMP를 공부하면서 이 단어들의 경계가 훨씬 또렷해졌습니다. 요즘 글로벌 회의나 메일에서 일부러 구분해서 쓰는 단어는 이 다섯 개입니다.

용어제가 쓰는 뜻구분해서 쓰는 이유
Scope (범위)이번에 하기로 합의한 것, 그리고 하지 않기로 한 것“안 하기로 한 것”까지 적어 둬야 나중에 말이 엇갈리지 않는다
Change Request (변경 요청)합의한 범위·일정·비용을 바꾸자는 공식 요청작아 보여도 영향이 있으면 결정권자가 판단해야 한다
Risk (리스크)아직 일어나지 않았지만 일어날 수 있는 불확실한 일미리 대응 계획을 세울 수 있다
Issue (이슈)이미 일어나 지금 영향을 주고 있는 일계획이 아니라 해결과 보고가 필요하다
Acceptance Criteria (인수 기준)결과물을 “완료”로 받아들이는 조건UAT에서 “된 것 같다”와 “됐다”를 가른다

이 중에서 제게 특히 쓸모 있었던 건 리스크와 이슈의 구분입니다. “This is a risk”와 “This is an issue”는 듣는 사람에게 전혀 다른 신호입니다. 앞의 말은 “대비하자”이고, 뒤의 말은 “지금 손을 쓰자”입니다. 둘을 섞어 쓰면 상대는 얼마나 긴장해야 할지 모릅니다.

모국어가 서로 다른 사람들이 영어로 일할 때는 정확한 단어 하나가 문단 하나를 대신합니다. 그리고 PMP는 전 세계가 같은 기준으로 치르는 시험이라, 이 단어들은 나라와 회사가 달라도 같은 뜻으로 통하는 몇 안 되는 공용어에 가깝습니다.

이슈와 변경 앞에서: 평가 먼저, 기록 먼저

솔직히 제 실무 본능은 “일단 고치자”입니다. 시험 공부를 할 때 오답노트에 반복해서 적힌 실수도 그쪽이었습니다. 원인을 찾기 전에 해결책을 고르고, 영향을 분석하기 전에 실행하는 실수요.

공부하면서 NotebookLM으로 만든 한국어 오디오 목록을 봐도 그렇습니다. 제목에 “실무 본능”이 두 번, “PM도 틀리는”이 두 번 들어가 있습니다. 출퇴근길에 듣던 이 오디오들의 주제가 결국 실무 본능과 PMP 정답 사이의 간극이었던 셈입니다. 오디오를 어떻게 만들고 들었는지는 7부에 정리했습니다.

NotebookLM 스튜디오 패널의 한국어 딥 다이브 오디오 목록. 실무 본능이 PMP 사람 영역에서 오답인 이유, 현업 PM도 틀리는 PMP 변경관리 함정 등 약 12~24분 길이의 오디오가 보인다

2026년 6월, PMP를 공부하며 NotebookLM으로 만든 한국어 오디오 요약 목록. 제목에 “실무 본능”과 “PM도 틀리는”이 두 번씩 들어가 있다.

이슈가 터졌을 때

이커머스에서 이슈는 예고 없이 옵니다. 릴리스 직후 결제 단계에서 오류 문의가 들어오기 시작했다고 가정해 볼게요. 제 본능은 개발팀에 “확인 부탁드립니다”부터 보내는 쪽입니다.

요즘은 그 메시지를 보내기 전에 세 가지를 먼저 적습니다.

  1. 영향: 누가, 어디서, 얼마나 영향을 받고 있나. 모든 국가인가, 특정 결제 수단인가.
  2. 성격: 이미 벌어진 이슈인가, 아직 가능성인 리스크인가.
  3. 알릴 사람과 결정할 사람: 누가 알아야 하고, 누가 판단해야 하나.

적는 데는 몇 분이면 충분합니다. 그 몇 분은 개발팀이 엉뚱한 곳을 뒤지지 않게 하고, 고객사와 제가 같은 그림을 보게 만드는 시간입니다.

물론 예외도 있습니다. 결제 전체가 멈췄다면 평가보다 복구가 먼저입니다. 1부에서 썼듯 PMP Mindset에도 긴급한 위험처럼 즉시 조치가 필요한 예외가 있습니다. 다만 급할수록 “어디까지, 왜”를 확인하는 순서만큼은 놓지 않으려 합니다.

변경 요청이 들어왔을 때

커머스 고도화 일에는 작은 요청이 자주 들어옵니다. 버튼 문구 하나, 필터 하나, 국가 하나 추가. 하나하나는 작아 보여도 QA, 번역, 나라별 UAT까지 건드리는 경우가 적지 않습니다.

변경 관리는 제가 시험 공부를 하면서 반복해서 틀린 영역이기도 합니다. 위 목록에도 “현업 PM도 틀리는 PMP 변경관리 함정”(23분 34초)이 있습니다. 제목 그대로, 현업 감각대로 풀면 틀리기 쉬운 영역입니다.

그래서 지금은 작은 요청일수록 말로만 오케이하지 않으려 합니다. 최소한 아래 다섯 줄은 남깁니다.

[변경 요청] 예: 상품 상세 페이지에 배송 안내 배너 추가
1. 요청: 누가, 왜 요청했나
2. 영향: 일정 / 비용 / 범위 / 품질(QA·UAT 재수행) / 리스크
3. 선택지: 이번 릴리스에 포함 / 다음 릴리스로 / 하지 않음
4. 결정권자: 누가 승인하나
5. 결정: 무엇을, 언제 결정했나

PMP 시험이 정답으로 요구하는 순서도 같습니다. 영향을 분석하고, 공식 절차로 승인을 받고, 승인되면 계획을 고치고 공유합니다. 처음엔 깐깐해 보일까 신경 쓰이기도 합니다. 그래도 기록이 남으면 고객사 담당자도 자기 조직에 변경을 설명하기가 훨씬 쉬워집니다. 변경 요청서는 PM을 지키는 문서이면서, 고객사 담당자를 지키는 문서이기도 합니다.

납품물보다 가치를 묻는다

제 오디오 목록에는 “버그 없는 프로젝트가 인수를 거절당한 이유”라는 제목도 있습니다. 제목 자체가 질문입니다. 버그가 없는데 왜 거절당했을까요? 제가 이 제목에서 읽는 답은 이렇습니다. 만들기로 한 것은 만들었지만, 고객이 원래 얻고 싶던 것은 주지 못했다.

PM 일을 하다 보면 산출물(output)과 결과(outcome)를 섞어 쓰기 쉽습니다. “릴리스를 했다”, “기능을 오픈했다”는 산출물입니다. 고객사가 돈을 낸 이유는 그다음에 있습니다. 운영이 쉬워지는 것, 고객이 더 쉽게 사는 것, 여러 나라 사이트가 같은 기준으로 움직이는 것.

그래서 요즘은 요구사항을 받을 때 질문을 하나 더 붙입니다.

이게 오픈되면, 누가 무엇을 더 잘하게 되나요? 그건 어떻게 확인하나요?

그리고 그 답이 UAT 인수 기준에 들어가 있는지 봅니다. 기능이 동작하는지만 확인하는 UAT와, 원래 얻고 싶던 결과까지 확인하는 UAT는 다릅니다.

PMI도 같은 방향으로 움직였습니다. 2026년 개편된 PMP 시험의 출제 기준(ECO)은 PMBOKPMBOK프로젝트 관리 지식 체계: 프로젝트 관리 협회(PMI)에서 발행하는 표준 가이드로, 프로젝트 성공을 위한 핵심 프로세스, 베스트 프랙티스 및 표준 용어집입니다.Read More → 8판의 프로젝트 정의, 즉 “고유한 맥락에서 가치를 만들기 위해 수행하는 일시적인 시도”를 그대로 씁니다. Process 영역에는 “가치 기반 전달을 돕는다(Help ensure value-based delivery)”는 과제가 새로 생겼고, Business Environment 비중은 8%에서 26%로 커졌습니다. 자세한 변화는 5부에 정리했습니다.

벤더와 오프쇼어 팀: 통제보다 지원

고백하자면 제 시험 결과에서 People 영역은 Below Target이었습니다. 세 영역 중 가장 낮은 등급을 받은 사람이 “사람을 대하는 방식이 바뀌었다”고 쓰려니 조금 민망합니다.

그래도 People 문제에서 제가 반복해서 틀린 패턴은 분명했습니다. 팀과 이야기하기 전에 바로 윗선으로 올리거나, 원인을 보기 전에 사람을 바꾸려는 선택이었습니다. PMI가 원하는 답은 정반대였습니다. PM은 팀을 통제하는 사람이 아니라, 팀을 지원하고 장애물을 치우는 사람이라는 것.

이 관점은 소속도, 시간대도 다른 팀과 일할 때 더 쓸모가 있습니다. 지금 함께 일하는 글로벌 벤더는 제 직속 팀원이 아닙니다. 다른 회사, 다른 계약 아래에서 일합니다. Hyperhire 시절에는 다섯 나라의 개발자들과 서로 다른 시간대에서 일했습니다. 이런 팀에게 “왜 늦었나요?”를 묻기 전에 “무엇이 막고 있나요?”를 먼저 묻는 것, 저는 그게 서번트 리더십(servant leadership)의 출발점이라고 생각합니다.

PM이 치울 수 있는 장애물은 생각보다 구체적입니다.

  • 애매한 요구사항: 질문이 하루를 넘기기 전에 답하거나, 답할 사람을 바로 연결한다.
  • 미뤄진 결정: 고객사 승인이 필요한 건 상대 팀의 업무 시간이 시작되기 전에 정리해 둔다.
  • 권한과 환경: 접근 권한, 테스트 데이터, 스테이징 환경처럼 개발자가 혼자 풀 수 없는 것을 챙긴다.
  • 흔들리는 우선순위: 무엇이 먼저인지 한 줄로 정리해서 공유한다.

지원한다는 게 기준을 낮춘다는 뜻은 아닙니다. 오히려 인수 기준을 처음부터 분명하게 주는 것이 벤더에게는 가장 큰 지원입니다. 무엇을 만들어야 “완료”인지 모르는 채 일하는 것만큼 힘 빠지는 일도 없으니까요.

예측형과 애자일 사이에서 고르는 감각

제가 해 온 엔터프라이즈 커머스 프로젝트는 성격상 하이브리드에 가깝습니다. 오픈 날짜와 예산은 미리 승인받아 고정되는 경우가 많고, UAT와 릴리스는 정해진 관문을 통과해야 합니다. 그런데 오픈 뒤의 개선 요청과 운영 백로그는 우선순위가 계속 바뀝니다.

PMP를 공부하면서 생긴 감각은 하이브리드를 “둘 다 조금씩”이 아니라 “어디에 무엇을 쓸지 고른 결과”로 보는 것입니다. 예를 들어 커머스 프로젝트라면 이렇게 나눠 볼 만합니다.

예측형으로 관리할 것애자일로 운영할 것
오픈 일정, 예산, 계약 범위개선 요청 백로그와 우선순위
UAT 일정과 인수 기준, 릴리스 승인스프린트 단위 개발과 데모
나라별 롤아웃 순서오픈 뒤 안정화 이슈 처리

2026년 개편된 PMP 시험도 약 40%가 예측형, 60%가 애자일 또는 하이브리드 접근을 다룹니다. PMBOKPMBOK프로젝트 관리 지식 체계: 프로젝트 관리 협회(PMI)에서 발행하는 표준 가이드로, 프로젝트 성공을 위한 핵심 프로세스, 베스트 프랙티스 및 표준 용어집입니다.Read More → 8판에서 테일러링(tailoring)은 더 이상 원칙 목록에 없지만, 테일러링 지침은 그대로 남아 있습니다. 저는 이걸 “테일러링은 구호가 아니라 매일 내리는 판단”이라는 뜻으로 읽었습니다.

이력서 한 줄은 바뀌었지만

PMP를 받고 나서 이력서 맨 윗줄을 “PMP® | Global Project Manager”로 바꿨습니다.

PMI가 보낸 PMP 취득 축하 메일. You earned your Project Management Professional (PMP) Professional Certification 문구와 Credly 디지털 배지 안내가 보인다

2026년 7월 4일 새벽에 받은 PMP 취득 메일. Credly 디지털 배지는 1~2주 안에 따로 메일로 온다고 안내한다.

글로벌 협업에서 이 세 글자는 짧은 자기소개 역할을 한다고 생각합니다. 처음 만나는 본사 담당자나 해외 벤더에게 PMP는 대략 이런 뜻으로 읽힌다고 봅니다.

  • 일정 기간 이상 프로젝트를 이끈 경험이 있다 (학사 기준 36개월, PMI는 무작위로 Audit도 한다)
  • PMI가 정한 같은 용어와 판단 틀을 공부했다
  • 3년마다 60 PDU를 채워야 자격이 유지되니, 계속 공부하는 사람이다

다만 솔직히 말하면, 아직 이릅니다. 7월에 합격했으니 이 글을 쓰는 지금 석 달이 채 안 됐습니다. 그래서 이 글에는 “자격증 덕분에 생긴 일”을 하나도 적지 않았습니다. 석 달은 그런 이야기를 하기엔 너무 짧습니다.

그리고 자격증은 일을 대신해 주지 않습니다. 제 이력서에 적힌 숫자들, 예를 들어 글로벌 가전 고객사의 운영 백로그가 104건에서 48건으로 줄고 이슈 해결 리드타임이 27% 짧아진 것은 PMP라는 글자가 만든 결과가 아닙니다. 현업에서 만든 숫자입니다. PMP는 그런 일을 설명하는 언어를 조금 더 정확하게 만들어 줬을 뿐입니다.

자격증은 대화를 시작하게 해 줍니다. 대화를 이어 가게 하는 건 결국 일입니다.

다음 편에서는 한 발 더 나간 주장을 해 보려 합니다. 이 사고방식이 오히려 PM이 아닌 사람, 그러니까 개발자나 디자이너, 마케터에게 더 강력하다는 이야기입니다. 연봉과 채용이 궁금하다면 14부에서 숫자와 국내 공고로 정리했습니다.

다음 편: PMP는 오히려 PM이 아닌 사람에게 더 강력하다

자주 묻는 질문

PMP를 따면 실무가 바로 달라지나요?

자격증을 받는 순간 달라지는 건 없습니다. 제 경우 달라진 건 시험 공부로 익힌 판단 순서가 업무 습관으로 옮겨 온 부분입니다. 이슈 앞에서 영향부터 평가하고, 변경 요청을 기록으로 받고, 결과물보다 가치를 묻게 됐습니다. 다만 합격한 지 석 달이 채 안 된 시점의 이야기입니다.

PMP 정답과 실무 감각이 다르다는 말이 사실인가요?

어느 정도는 맞습니다. 실무 본능은 빨리 고치고 빨리 결정하는 쪽인데, PMP 문제는 상황 파악과 영향 분석을 먼저 요구하는 경우가 많습니다. 그런데 이 순서는 실무에서도 쓸모가 있었습니다. 결제 전체가 멈춘 상황처럼 즉시 조치가 필요한 예외도 있으니, 공식처럼 외우기보다 이유를 이해하는 편이 낫습니다.

애자일 팀에서 일해도 PMP가 도움이 되나요?

2026년 개편된 PMP 시험은 약 40%가 예측형, 60%가 애자일 또는 하이브리드 접근을 다룹니다. 고정된 오픈 일정과 백로그 기반 개선 작업이 섞인 하이브리드 프로젝트라면, 어느 부분을 예측형으로 두고 어느 부분을 애자일로 운영할지 고르는 기준을 세우는 데 도움이 됩니다.

이력서에는 PMP를 어떻게 적나요?

저는 이력서 맨 윗줄을 PMP® | Global Project Manager로 바꿨습니다. 다만 자격증 이름보다 그 아래 적힌 프로젝트 경험이 더 중요하다고 생각합니다. 자격증은 대화를 시작하게 해 주고, 대화를 이어 가게 하는 건 경험입니다.

참고 자료

시리즈 이어보기 → PMP 합격 로드맵

PMP는 오히려 PM이 아닌 사람에게 더 강력하다: 개발자·디자이너가 PM의 눈으로 일할 때

파트 13 / 15

수정 이력

v1.0

PMP 합격 후 실무에서 달라진 습관을 정리한 첫 버전

  • •공통 용어, 행동 전 평가, 변경 통제, 가치, 서번트 리더십, 테일러링 여섯 가지 변화 정리
  • •이력서 한 줄의 의미와 자격증의 한계 정리

DailySay에 묻기

Related Posts

이어서 읽기

PMP는 오히려 PM이 아닌 사람에게 더 강력하다: 개발자·디자이너가 PM의 눈으로 일할 때
일과 기술22 min

PMP는 오히려 PM이 아닌 사람에게 더 강력하다: 개발자·디자이너가 PM의 눈으로 일할 때

범위, 이해관계자, 리스크, 변경 관리, 가치. PMP가 정리한 사고방식은 개발자·디자이너·마케터·운영 담당자에게 더 큰 차이를 만든다. 역할별 예시와 CAPM까지, 현실적인 경로를 정리했다.

글 읽기

Jayden의 발자취가 궁금하신가요?

일과 제품, 여행, 그리고 지금 만들고 있는 이야기들을 가끔 보내드릴게요.

스팸 없이, 가끔만요. 개인정보 처리방침.