PM

프로젝트와 PM의 정의

프로젝트란 한정된 기간과 비용을 투자해 정해진 미션을 달성하는 활동이다. 시간과 비용이라는 두 제약이 프로젝트의 본질이며, 특히 IT 프로젝트는 여기에 데이터와 인프라·인력·SaaS 등 통합된 정보 자원이 더해져 관리의 복잡도가 한층 높다.

PM(Project Manager)은 이 제약 안에서 범위(Scope)·일정(Time)·비용(Cost)을 동시에 충족시키는 책임자다. 세 가지를 모두 만족해야 비로소 ‘성공’으로 인정되며, 통계적으로 이 엄밀한 성공에 도달하는 비율은 30%대에 머문다.

PM의 역할이 본질적으로 까다로운 이유가 여기에 있다.

역량의 차이를 만드는 것

엔지니어의 성장은 경력의 길이가 아니라 일을 대하는 방식에서 갈린다. 핵심은 전체 흐름을 이해하고 일하는가, 아니면 맥락 없이 주어진 작업만 수행하는가의 차이다.

시니어는 프로젝트의 전 생명주기를 조망하고 각 작업 주체의 역할을 이해한 상태에서 일을 배치한다. 그리고 이 모든 협업의 토대는 결국 ‘용어’다.

같은 단어를 서로 다른 의미로 사용하면 요구사항 정의부터 최종 검수까지 모든 단계에서 인식의 균열이 생긴다.

권한이 아니라 조정력

PM의 권한과 책임은 모든 일을 직접 떠안는 데 있지 않다. 핵심은 경영진과 현업의 영향력을 적절히 활용해 일이 진행되도록 조정하는 것이다.

특히 한국형 고정계약 구조에서는 예산을 유연하게 조정하기 어렵기 때문에, PM은 통제자보다 이해관계자 사이를 잇는 조정자이자 오케스트레이터에 가깝다. 제품의 방향을 쥔 PO(Product Owner)를 효과적으로 활용하는 PM이 좋은 PM이며, 경험이 부족한 영역은 PMO나 전문가를 투입해 보완하는 판단 역시 PM의 역량에 포함된다.

실무에서 챙겨야 할 빈틈

실제 프로젝트에서 가장 자주 문제가 되는 것은 역할 분담의 사각지대다. 데이터 마이그레이션은 수행사가 기존(AS-IS) 업무를 알지 못해 발주사의 지원이 필요한 대표적 영역이며, 외부 인터페이스 연계나 회계 모듈(SAP 등)도 담당을 사전에 확정하지 않으면 후반에 분쟁이 생긴다.

갑과 을의 접점은 대개 이 마이그레이션 구간이다. 또한 프로젝트의 핵심 인력은 결국 아키텍트다.

노력만으로 채워지는 자리가 아니라 역량을 갖춘 사람을 확보해야 하는 자리이며, PM은 이 핵심 인력의 배치에 가장 신경을 써야 한다.

무엇으로 평가되는가

PM의 실력은 수행계획서와 완료보고서에서 드러난다. 합의 요건의 증감이 통제 범위 안에 있었는가, WBS 계획대로 진행됐는가, 투입 공수(맨먼스)와 업무 분담에 무리가 없었는가가 핵심 지표다.

결국 PM의 일은 실현 가능한 계획을 세우고 끊임없는 변화 속에서 그 계획을 지켜내는 것이며, 이 역량은 한두 번의 경험이 아니라 여러 프로젝트를 직접 결산(wrap-up)하며 누적된다.

전문성과 외부 시선의 활용

경험하지 못한 영역을 맡았을 때 현명한 선택은 PMO나 전문가를 투입하는 것이다. 모든 것을 직접 통제하려다 핵심을 놓치기보다, 외부 전문성을 빌려 빈틈을 메우는 편이 전체 위험을 줄인다.

정보화전략계획(ISP)이나 전사 아키텍처(EA)를 외부 컨설팅에 맡기는 이유도 같다. 내부의 시선에서 벗어나 객관적 관점을 확보하기 위해서다.

최근 화두인 AI 전환(AX) 역시 무엇을 전환할지 발주 전에 내부 기준으로 정리하고 시제품으로 방향을 명확히 한 뒤 외부에 맡겨야 한다. 수행사는 전환 기법을 보유한 곳이지 요구를 정의하는 곳이 아니기 때문이다.

결국 PM의 역량은 직접 수행하는 폭이 아니라, 적절한 전문성을 제때 끌어들이는 판단에서 드러난다.