좋은 PM은 무엇이 다른가 – AI 프로젝트 관리의 핵심

PM이 조용하면 프로젝트가 시끄러워진다

현장에서 오래 일하다 보면 PM의 스타일이 프로젝트의 분위기를 결정한다는 걸 느끼게 됩니다.
PM이 문제를 먼저 꺼내는 팀은 회의가 조용합니다.
이미 대화가 됐고, 방향이 정해졌기 때문입니다.
반대로 PM이 문제를 늦게 꺼내는 팀은 회의가 시끄럽습니다.
갑자기 커진 이슈 앞에서 모두가 놀라고, 서로 원인을 찾고, 책임 소재를 따집니다.
좋은 PM과 그렇지 않은 PM의 차이는 결국 하나로 귀결됩니다.

타이밍입니다. 문제가 커지기 전에 움직이는 사람이냐, 커진 후에 반응하는 사람이냐.

저는 좋은 PM의 핵심 역량은 이슈와 위험을 관리하는 능력이라고 생각합니다.
이 글은 그 이야기입니다.

AI 프로젝트 관리에서 리스크가 더 까다로운 이유

일반적인 IT 프로젝트도 이슈 관리와 리스크 관리가 중요하지만, AI 프로젝트는 그 난이도가 한 단계
높습니다.
세 가지 이유가 있습니다.

첫째, 모델 성능은 현장에서 달라집니다.
개발 환경에서 검증한 성능이 실제 고객 현장에 나가면 달라지는 경우가 빈번합니다.
카메라 위치, 조명 환경, 현장 특성, 계절 변화 – 이 모든 변수가 모델에 영향을 줍니다.
“테스트에서 됐으니 현장에서도 된다”는 가정은 AI 프로젝트에서 통하지 않습니다.

둘째, 요구사항이 중간에 바뀝니다.
고객이 처음 원했던 것과 실제 현장을 보고 나서 원하는 것이 달라지는 일이 자주 생깁니다.
AI에 대한 기대치가 과도하거나 반대로 너무 낮은 경우 모두 요구사항 변경으로 이어집니다.
이것을 예측하지 못하면 개발 막바지에 범위가 폭발합니다.

셋째, 기술적 불확실성이 높습니다.
일반 SI 프로젝트는 구현 방법이 대체로 정해져 있습니다.
하지만 AI 프로젝트는 “할 수 있을 것 같다”와 “실제로 할 수 있다” 사이의 간격이 큽니다.
그 불확실성을 일정과 범위 안에서 관리하는 것이 PM의 역할입니다.

리스크를 보는 눈, 어떻게 만들어지나

리스크 관리는 거창한 문서 작업이 아닙니다.
핵심은 두 가지 질문을 습관적으로 던지는 것입니다.

“지금 보이지 않는 문제가 있다면 무엇인가?”
“이것이 지금은 작아 보이지만 나중에 커질 수 있는가?”

실무에서는 리스크 매트릭스를 간단하게라도 운영하는 것이 도움이 됩니다.
발생 가능성과 영향도를 두 축으로 놓고, 각 리스크를 위치시켜 보는 것입니다.
말로만 “위험할 수 있다”고 할 때와 눈에 보이는 형태로 정리했을 때, 팀의 반응이 달라집니다.
AI 프로젝트에서 자주 등장하는 리스크들을 예로 들면 이렇습니다.
모델 성능 저하, 현장 환경 변수, 요구사항 범위 변경, 일정 지연, 고객 기대치 미스매치.
이것들을 프로젝트 초반에 명시적으로 올려놓고 팀과 공유하는 것만으로도 프로젝트의 긴장감과 준비도가 달라집니다.

이슈는 생애주기로 관리한다

리스크가 사전에 보는 것이라면, 이슈는 이미 발생한 문제입니다.
그리고 이슈도 생애주기가 있습니다.

감지 → 분석 → 대응 → 모니터 → 종결

좋은 PM은 이 흐름을 의식적으로 관리합니다. 특히 중요한 단계는 ‘감지’와 ‘종결’입니다.
감지가 늦으면 이후 모든 단계가 힘들어집니다.
이슈를 빨리 발견하려면 PM이 팀원들이 불편한 것을 쉽게 말할 수 있는 분위기를 만들어야 합니다. 이슈를 숨기고 싶어지는 문화에서는 감지가 항상 늦습니다.
종결도 제대로 해야 합니다.
문제가 일단 해결됐다고 넘어가면 같은 이슈가 반복됩니다.
이슈가 종결될 때 ‘왜 발생했고, 어떻게 해결했고, 다음에 어떻게 예방할 것인가’를 짧게라도 기록으로 남기는 PM과 그렇지 않은 PM의 차이는 프로젝트가 반복될수록 확연하게 벌어집니다.

PM은 ‘번역가’이기도 하다

이슈와 리스크 관리를 잘한다는 건, 단순히 문제를 빨리 발견한다는 것만이 아닙니다.
발견한 것을 제대로 전달하는 능력도 포함됩니다.
개발팀에게는 기술적 맥락으로, 사업팀에게는 비즈니스 영향으로, 경영진에게는 의사결정이 필요한 사항으로 – 같은 이슈를 각 이해관계자의 언어로 번역해서 전달하는 것이 PM의 역할입니다.

AI 프로젝트 관리에서는 이 번역 능력이 더욱 중요합니다.
개발팀이 말하는 “모델 정확도가 3% 떨어졌다”를 고객이 이해할 수 있는 언어로 어떻게 설명할 것인가. 고객이 요구하는 “실시간 감지”가 기술적으로 무엇을 의미하는지 개발팀에게 어떻게 전달할 것인가.
이 사이에 PM이 있습니다.

결국, 좋은 PM은 불편함을 먼저 꺼내는 사람이다

경험상 좋은 PM의 공통점은 하나였습니다.
불편한 것을 먼저, 그리고 명확하게 꺼내는 사람들이었습니다.
일정이 빠듯하다는 걸 모두가 알지만 아무도 말하지 않을 때, 먼저 테이블에 올리는 사람.
고객의 기대치가 현실과 다르다는 걸 느끼면서도 눈치를 보고 있을 때, 먼저 대화를 시작하는 사람.
팀 안에서 무언가 삐걱거린다는 신호가 올 때, 무시하지 않고 직접 확인하는 사람.
이 부분은 고객과의 대화에서도 필요합니다.
고객에게도 명확하게 문제점과 한계를 설명해서 이해시키는 과정이 AI 프로젝트에서는 많이 요구됩니다.
이유는 AI 프로젝트는 고객도 어려워 하고, 힘들어하는 기술적인 내용이 많이 포함되기 때문입니다.

이것이 이슈와 위험을 관리하는 PM의 실제 모습입니다.
도구나 방법론보다 이 태도가 먼저입니다.
프로젝트는 결국 사람이 합니다.
그리고 그 사람들 사이에서 가장 먼저 문제를 보고, 가장 먼저 목소리를 내는 사람이 프로젝트를
살립니다.

2026.05. 06
Rhapsody