[아티클 분석]개발자의 시선에서 바라본 PM

PM은 어떻게 해야하는가에 대해, 개발자의 시선으로 들은 섹션에 대한 이야기를 포스팅해보려고 한다. 

주된 이야기는 개발자 분께서 PM과 협업하며 느꼈던 좋은 점 나쁜 점들이 섹션의 중점이었다. 

 

개발자가 업무하면서, pm에게 어떤 업무를 기대하겠는가?

-일반적인 기대	-현실의 업무
-IT업계에서 PM, 디자이너, 개발자는 "함께 창조하는 사람들 이라는 이미지가 강하다.  -아이디어 기획-> 디자인 구체화 -> 기술 구현으로 이어지는 창조의 흐름이 자연스럽게 연상된다.	-실무는 다르다. 제가 가장 많이 했던 일은 처음부터 만드는 것보다 기존 서비스를 유지하고 개선하는 일이었다. -운영중인 코드의 버그수정 -외부 정책 / API 변경에 따른 기능 수정 유저 피드백 기반 UXUI 개선

 

보통은 창조적인 걸 기대하겠지만, 보통의 실무에서는 백지에서 시작해서 제품 론칭하는 게 아니라 사실 이미 다 만들어져있는거 버그 수정 하고 개선하는 게 대부분이다. 때문에 이런 기대를 가지고 실무애 취업해 들어가게 되면 실무에서 일하기에 반밖에 준비 안된 사람이다.

 

실전 협업 케이스

1. 신규 기능 개발.

신규 프로젝트를 함께 만들어가는 건 가장 전형적인 협업 구조다. 이 과정에서 PM은 기획부터 릴리즈까지 팀 전체의 중심축이 되어야 한다.
프로세스는 대개 다음과 같이 흐른다.

신규 기능 개발에서 PM의 역할
(기획 → 킥오프 → 디자인 → 개발 → QA → 릴리즈)

📅 일정 계획 수립
디자인, 개발, QA 등 각 리소스를 고려한 스케줄링을 담당합니다. 전체 프로젝트의 타임라인을 설정하고 각 단계별 마일스톤을 정의합니다.
📝 MVP 우선순위 결정
무엇부터 구현할지를 명확히 구분합니다. 핵심 기능과 부가 기능을 분류하고, 단계적 구현 전략을 수립합니다.
📊 비즈니스 맥락 전달
이 기능이 왜 필요한지, 어떤 KPI(핵심 성과 지표)와 연결되는지 명확히 설명합니다. 개발팀이 목적을 이해하고 작업할 수 있도록 합니다.
🗂 킥오프 리딩
팀이 같은 방향을 보고 갈 수 있도록 초기 정리를 담당합니다. 기획 배경, 사용자 흐름, 기능 목적, 예상 질문 리스트까지 정리된 문서를 미리 공유합니다.

 

신규 협업 케이스에서 개발자가 PM에게 원하는 역할

개발자 입장에서 봤을 때, 좋은 PM은 단순히 기획서를 잘 쓰는 사람이라기보다는, **‘기획의 방향성과 맥락을 전사적으로 공유해줄 수 있는 사람’**이다. 대부분의 개발자는 회사의 비즈니스 목표나 매출 증가와 같은 상위 레벨의 지표에 큰 관심이 없다. 그보다는 지금 내가 작성하는 코드가 얼마나 깔끔한지, 향후 유지보수가 잘 되는지 같은 업무 자체의 완성도에 더 관심이 많은 경우가 많다. 그렇기 때문에 PM이 그 기능이 왜 필요한지, 어떤 문제를 해결하는 건지, 비즈니스적으로 어떤 의미가 있는지를 명확하게 설명해주는 역할이 정말 중요하다.

 

실제로 협업할 때 보면, 기획 배경과 사용자 흐름, 기능 목적, 참고할 만한 레퍼런스까지 킥오프 미팅 이전에 미리 정리해서 공유해주는 PM들이 있었다. 이렇게 되면 디자이너나 개발자 입장에서도 머릿속에 기능에 대한 그림이 먼저 잡히고, 회의 자리에서는 기능 자체에 대한 토론이 아니라 “이걸 이렇게 바꾸면 더 낫지 않을까요?” 같은 생산적인 피드백을 주고받을 수 있게 된다. 그런 미팅은 단순한 기능 검토가 아니라 실제로 다 같이 프로덕트를 설계해나가는 느낌이 강하다.

 

결국 중요한 건 기획서를 잘 쓰는 PM이 아니라, 기획의 흐름과 맥락을 팀 전체에 자연스럽게 스며들게 하는 PM이다. 개발자도, 디자이너도 각자 다른 관점에서 일을 하지만, 우리가 지금 ‘왜 이걸 하는지’가 명확하게 공유된 상태에서는 훨씬 더 깊이 있는 협업이 가능하다. 그리고 그 시작은 언제나 “왜 이걸 해야 하죠?”라는 질문에 명확히 답할 수 있는 PM으로부터 시작된다고 생각한다.

 

2. 버그 픽스 – 빠른 대응이 핵심이다

📌 문제 정의
단순히 "버그 있어요"가 아니라, 문제의 조건·맥락·기대 동작을 명확하게 정의하는 것이 중요합니다.예: “iOS Safari에서 로그인 후 프로필 편집 기능이 작동하지 않습니다.”

📌 재현 방법 제공
버그 발생 조건을 명확히 하고, 실제 발생 상황을 짧게 캡처한 영상을 첨부하여 개발자가 문제를 쉽게 파악할 수 있도록 합니다.예: “iOS Safari 15.4, iPhone 13에서 프로필 편집 버튼 클릭 시 반응 없음 (영상 첨부)”

📌 영향도 평가
얼마나 많은 유저가 영향을 받는지, 즉시 대응이 필요한지, 다음 릴리즈에 포함해도 되는지 등 우선순위를 설정합니다.예: “iOS 유저 30%가 영향 받으며, 핵심 기능이므로 긴급 패치 필요”

📌 기대 동작 명확화
정상적으로 작동했을 때 어떤 상태여야 하는지 기대 동작을 명확히 설명합니다.예: “프로필 편집 버튼 클릭 시 편집 모드로 전환되어 사용자 정보 수정 가능해야 함”

📌 대응 긴급도 설정
이슈의 심각성과 비즈니스 영향을 고려하여 대응 우선순위를 명확히 합니다.예: “회원가입 흐름에 영향을 주는 중대 버그로, 48시간 내 핫픽스 배포 권장”

 

버그 픽스는 실무에서 가장 자주 마주치는 PM의 역할 중 하나다. 특히 사용자가 직접적으로 불편함을 느끼는 기능 버그는 서비스 신뢰도와 사용자 경험에 치명적인 영향을 줄 수 있고, 회사 비즈니스에도 부정적인 영향을 끼친다. 그렇기 때문에 ‘빠른 대응’이 핵심이 된다.

 

예를 들어, iOS Safari에서 특정 기능이 작동하지 않는 상황이 발생했다고 가정해보자. 이때 PM은 단순히 "버그 있어요"라고 말해서는 안 된다. 우선 이 버그가 어떤 환경에서, 어떤 이유로 발생했는지를 먼저 정리해야 한다. 예를 들어 iOS Safari 15.4, iPhone 13에서 발생한 문제라면 그 조건을 정확히 명시하고, 가능하다면 버그 화면을 캡처하거나 영상으로 첨부해서 함께 전달하는 것이 좋다.

 

그 다음으로 중요한 건 기대 동작까지 함께 전달하는 것이다. 어떤 동작이 원래 의도된 것이고, 현재 어떻게 비정상적으로 작동하고 있는지를 구체적으로 비교해서 알려줘야 한다. 예를 들어, “프로필 편집 버튼을 클릭하면 편집 모드로 전환되어야 하지만 아무 반응이 없음”처럼 현재 상황과 기대 동작을 분명히 해야 개발자도 빠르게 원인을 파악할 수 있다.

 

실제로 한 서비스 안에서도 동시에 여러 개의 버그가 발생할 수 있다. 이런 경우, PM은 버그별로 얼마나 많은 유저가 영향을 받고 있는지를 파악한 후, 이슈의 심각도에 따라 대응 순서를 정해야 한다. 영향도가 낮다면 다음 릴리즈에 포함시킬 수 있지만, 만약 핵심 기능에 영향이 있다면 즉시 핫픽스가 필요할 수도 있다.

 

이렇게 버그의 상황과 조건, 기대 동작, 영향도, 대응 우선순위까지 명확하게 PM이 정리해서 공유해주면 개발자와의 커뮤니케이션 과정에서 불필요한 리소스를 줄일 수 있다. 커뮤니케이션 자체도 리소스이기 때문에, PM이 선제적으로 상황을 잘 정리하고 전달하는 것만으로도 팀의 대응 속도와 효율이 훨씬 높아진다.

 

---

기능 개선 / 리뉴얼 시 PM의 역할

구분	설명
AS-IS	현재 결제 방식과 구조, 한계점
TO-BE	새 정책에 맞게 바뀐 결제 방식
영향도	주문, 환불 등 관련 기능 목록
협업 요청	개발자의 의견이 필요한 부분

기존 기능을 개선하거나 새로 만들 때는 현재(AS-IS)와 개선 후(TO-BE) 상태를 명확히 구분해야 합니다. 왜 바꾸는지 이유를 함께 설명하면 개발자는 변경 목적을 이해하고 더 좋은 기술 방법을 제안할 수 있습니다.
제품의 퀄리티는 맥락의 이해에서 시작됩니다. 그리고 맥락의 이해는 개발자와 PM의 역할에서 시작하고요.
때로는 AS-IS 정보가 불명확하거나 조직 내 아무도 정확히 알지 못하는 경우도 있습니다. 이런 상황에서는 PM이 직접 현재 기능의 명세를 체계적으로 정리하고 문서화하는 작업이 필요합니다. 이는 개발자들이 기존 시스템을 이해하는 데 큰 도움이 되며, 이후 TO-BE 설계의 토대가 됩니다.

 

제품이 시간이 지나며 **래거시(legacy)**가 되면, 기술적으로 더 나은 방법이 등장하거나, 비용을 줄일 수 있는 새로운 기능이 출시되면서 기능 재설계나 리뉴얼이 필요한 상황이 생긴다. 이때 단순히 UI만 고치는 수준이 아니라, 전체 기능 구조를 다시 설계하거나 백엔드 구조까지 손을 대야 하는 경우도 많다. 당연히 복잡한 작업이 수반되고, 이 과정에서 PM에게 요구되는 역할도 중요해진다.

 

가장 중요한 것은 현재 상태(AS-IS)와 변경 이후 상태(TO-BE)를 명확하게 제공하는 것이다. PM은 현재 제품이 어떤 구조로 작동하고 있으며, 왜 개선이 필요한지, 개선 이후에는 어떤 모습으로 바뀌어야 하는지를 개발자와 디자이너가 명확하게 이해할 수 있도록 문서화하고 설명해야 한다. 그래야 팀원들이 변경 목적을 정확히 이해하고, 더 나은 기술적 대안을 제시하거나 우선순위를 함께 정할 수 있게 된다.

 

특히 실제 업무에서 마주하는 문제 중 하나는, AS-IS 정보를 아는 사람이 조직 내에 아무도 없는 경우다. 시스템이 오래되어 문서도 없고, 담당자도 이직했거나 퇴사한 경우가 흔하다. 이런 상황에서는 PM이 직접 현재 기능의 명세를 조사하고, 마치 백과사전처럼 정리해두는 것이 중요하다. 일종의 ‘제품 위키’를 만들어두는 작업이다.

 

이렇게 쌓아놓은 문서는 향후 TO-BE 설계를 할 때 큰 도움이 된다. 개발자 입장에서도 기존 시스템의 이해도가 높아지기 때문에 리팩토링이나 개선 작업이 더 수월해지고, PM 역시 변경 의도를 정확히 설명할 수 있어 팀 전체의 효율이 높아진다.

 

결국 기능 개선 작업은 단순한 기획 변경이 아니라, 과거를 명확히 정리하고 미래를 구체화하는 작업이다. 그 중심에는 언제나 PM의 맥락 이해력과 커뮤니케이션 역량이 있다.

 

기억에 남는 pm의 공통된 특징

-나는 당신의 말을 들을 준비가 되어있어요가 태도에 나타나는 분.
-단순한 예의나 격식보다는 태도!
-정보를 구조화해서 상대가 이해할 수 있도록 설명하는 능력.

 

이 자료들을 통해 알 수 있는 핵심은, 기억에 남는 좋은 PM이란 단순히 기획서를 잘 쓰는 사람이 아니라 ‘함께 일하고 싶은 분위기’를 만드는 사람이라는 점이다. 개발자와 협업을 잘하는 PM은 공통적으로 세 가지 태도를 지니고 있다. 첫째, 개발자가 편하게 다가갈 수 있는 협업 파트너십을 조성하고, 둘째, 상대방의 의견을 먼저 듣고 수용할 수 있는 열린 커뮤니케이션 태도를 가지며, 셋째, 복잡한 정보를 명확하고 구조적으로 설명해서 개발자가 이해하기 쉽게 만든다.

 

특히 실무에서는 “나는 당신의 의견을 들을 준비가 되어 있다”는 메시지를 말과 태도 속에 자연스럽게 녹이는 것이 중요하다. 겉으로 공손해도 의견을 무시한다는 인상을 주면 오히려 협업은 어려워진다. 반대로 진정성 있게 경청하고 문제를 함께 풀어가려는 태도를 보이면, 개발자는 더 솔직하게 의견을 나누고 주도적으로 참여하게 된다.

 

또한 PM은 설명할 때도 직관적으로 이해 가능한 방식을 지녀야 한다. 이를 위해선 기능의 도입 목적과 사용자 가치, 구현 방식, 요구 사항, 그리고 **참고자료(레퍼런스)**를 명확하게 전달할 수 있어야 한다. 예를 들어, “이 기능을 추가하면 결제 전환율이 30% 증가합니다”처럼 데이터와 함께 목적을 설명하면, 개발자에게도 분명한 맥락이 생기고 더 빠르고 효과적인 협업이 가능해진다.

 

요약하자면, 좋은 PM은 문제 해결 능력보다도 먼저 사람과 협업하는 능력, 상대를 존중하는 태도, 이해하기 쉬운 커뮤니케이션 스킬을 통해 팀 전체가 같은 방향을 보게 만드는 사람이다.

실무에서 만난 PM 중, "이 분과는 또 함께 일하고 싶다"고 느꼈던 분들에게는 몇 가지 공통적인 특징이 있었다.
그 공통점은 단순히 ‘일을 잘한다’에서 끝나는 것이 아니라, 개발자가 기꺼이 협업하고 싶은 분위기를 만들어주는 태도에서 나왔다.

1. 협업 파트너십
개발자가 기꺼이 협업하고 싶어지게 만드는 분위기를 조성한다.
2. 열린 커뮤니케이션
의견을 경청하고, 다른 사람의 의견도 수용할 수 있는 태도를 가진다.
3. 명확한 설명
정보를 구조화하여 이해하기 쉽게 전달한다.

'열려 있다'는 인상을 주는 커뮤니케이션
개발자와 PM 사이에 오가는 대화에서 정중한 말투보다 더 중요한 것은 “나는 당신의 의견을 들을 준비가 되어 있다”는 메시지가 태도와 말 속에 자연스럽게 담겨있는 것이다.

개발자의 상황“이 부분은 구조상 구현이 꽤 까다로울 수 있어요.”

닫힌 태도의 커뮤니케이션“그래도 어떻게든 해결 방법이 있지 않을까요? 이미 기획에서 정해진 거예요.”겉으로는 공손한 말투를 쓰더라도, 실제로는 상대방의 의견을 듣고 있지 않다는 메시지가 전달되면 개발자는 “내 의사는 존중받지 못하고 그냥 시키는 대로 하라는 건가?”라고 느끼게 된다.

열린 태도의 커뮤니케이션 “음, 그렇군요. 그 부분이 UX상 중요한 포인트라고 생각했는데, 구현이 어렵다면 혹시 다른 방식으로 풀 수 있을까요?”이 대화에서 중요한 것은 말투가 아니라 “나는 당신의 전문성을 존중하고 의견을 진지하게 듣고 있다”는 메시지가 전달되는 것이다.

실무에서 가장 효과적인 PM-개발자 협업은 단순한 예의나 겉치레보다, 진정성 있는 경청과 상대방의 의견을 들을 준비가 되어 있다는 태도에서 시작한다. 이러한 태도가 있을 때 개발자는 더 솔직하게 의견을 나누고 함께 해결책을 고민하고자 한다.

직관적으로 이해 가능한 설명
PM이 개발자와 협업할 때 가장 중요한 역할 중 하나는 설명을 '직관적으로 이해 가능하게' 전달하는 것이다. 여기엔 네 가지 핵심 포인트가 있다.

1. 목적과 가치제품 변경의 근본적인 이유와 사용자 가치가 무엇인지 명확히 전달해야 한다. 예를 들어 “이 기능을 추가하면 사용자의 결제 시간이 30% 단축되어 전환율이 높아집니다”처럼, 실제 데이터와 함께 설명할 경우 개발자의 동기부여도 훨씬 명확해진다.

2. 접근 방식구현 방식과 프로세스를 구체적으로 설명해야 한다. 기술적 접근법, 단계별 구현 계획 등을 포함해 개발자가 이해할 수 있는 수준으로 기술적 맥락을 제공하면 혼선을 방지할 수 있다.
(단, 모든 개발자가 기술적 설명을 원하지는 않으므로 상황에 따라 조절 필요)

3. 요구 사항구체적인 요구사항과 기대 결과물을 명확히 정리해 전달해야 한다. 예를 들어 “로그인 화면에 소셜 로그인 옵션 3개를 추가하고, 각 버튼은 브랜드 색상을 유지한 상태로 디자인 시스템에 맞게 조정됩니다”와 같이 세부사항까지 포함해 설명하면 좋다.

4. 레퍼런스참고 자료와 리소스 위치를 구체적으로 안내해야 한다. “디자인 시안은 피그마 프로젝트 'Auth-2023'에 있으며, API 문서는 노션 'Backend/API/Social Login' 페이지에서 확인할 수 있습니다”처럼, 실제 액세스 가능한 정보를 제공하는 것이 중요하다.

🛒 쇼핑카트 개선 예시
“이번 변경은 사용자 피드백 중 '장바구니에 담기 기능의 혼란스러움'을 개선하려는 목적이에요.
기존에는 3단계였던 플로우를 2단계로 줄였고요, 설계는 기획서 5페이지에 정리되어 있습니다.
변경된 내용은 미리보기 삭제, 곧바로 결제하기 추가입니다. 사용자 테스트 결과는 노션 문서에 정리해두었어요.”

 

 

마찰이 생기는 순간들

1. 기술 제약에서의 충돌

기술 제약에서의 충돌은 PM과 개발자 사이에서 가장 흔하게 발생하는 마찰 중 하나이다.

 

ㅣ pm : 이 기능 필요해! 빨리 개발해서 배포해야해! 소비자가 원해!

ㅣ 개발자 : 이거 바꾸면 성능 떨어져! 구현도 오래걸려!

 

PM은 “이 기능은 꼭 필요하다. 소비자가 원하고, 빠르게 배포해야 한다”라고 주장하는 반면, 개발자는 “이걸 지금 바꾸면 성능이 떨어지고, 구현에도 시간이 오래 걸린다”라며 기술적 한계를 강조한다.

이런 상황에서 중요한 것은 커뮤니케이션이다. 단순히 각자의 입장만 고수하기보다는 “단계적으로 구현할 수 있는 방법은 없을까?”, “비슷한 효과를 낼 수 있는 대안은 없을까?”와 같은 접근을 통해 중간 지점을 찾는 노력이 필요하다.

실제로 마찰 포인트가 열 가지 있다면, 그중 아홉 가지는 대화를 통해 중간 지점을 도출하는 경우가 대부분이다. 갈등의 핵심은 의견의 차이 그 자체라기보다, 그 차이를 좁히기 위한 대화의 부재인 경우가 많다.

PM과 개발자 간의 마찰이 가장 흔하게 발생하는 순간은 바로 기술적인 제약이 명확하게 존재할 때입니다. PM은 비즈니스적인 필요성을 강조하는 반면, 개발자는 기술적인 한계를 설명하게 되면서 양측의 입장이 충돌하게 됩니다. 이는 기능을 실제로 구현하는 데 어려움이 있는 상황에서 특히 빈번하게 발생합니다.

또 다른 마찰 포인트는 **기한(데드라인)**과 완성도(퀄리티) 사이의 줄다리기입니다. 스프린트가 종료될 시점에 기능이 아직 완전히 구현되지 않았다면, 해당 기능을 출시할 것인지 미룰 것인지에 대한 의견이 갈릴 수 있습니다.

마지막으로, 우선순위의 차이 역시 마찰을 유발합니다. PM은 비즈니스 임팩트를 우선적으로 고려하지만, 개발자는 기술적인 안정성을 더 중시하는 경향이 있기 때문에, 서로 다른 우선순위에서 의견 충돌이 발생할 수 있습니다. 이런 상황에서는 양측의 관점을 잘 조율하는 것이 중요합니다.

 

데드라인 vs 퀄리티 충돌(가장 많이 일어나는 문제)

실무에서 기능을 개발할 때, PM과 개발자 사이에 가장 자주 발생하는 충돌 중 하나는 ‘완벽한 품질 보장 vs 빠른 일정 준수’ 사이에서의 우선순위 갈등이다. 개발자 입장에서는 기능의 완성도를 더 높이고 싶기 때문에 데드라인을 조금 늦추더라도 퀄리티를 보장하고 싶어하는 경향이 있다. 반면 PM 입장에서는 유저 피드백을 빠르게 받고, 내부 일정이나 마케팅과 맞물려 있는 타이밍을 놓치지 않기 위해 가능한 한 빨리 배포하고 싶어한다.

 

이런 충돌은 실무에서 매우 흔하며, 결국 기능의 ‘핵심도’에 따라 우선순위를 조정하여 해결하는 경우가 많다. 예를 들어, 결제·인증·로그인·보안 등 서비스의 신뢰성과 직결되는 핵심 기능은 안정성이 최우선이기 때문에 퀄리티 확보를 위해 일정이 다소 늦춰지더라도 충분한 테스트와 안정성 확보가 필요하다. 반면 알림 기능, UI 개선, 문구 수정과 같은 부가 기능은 일단 빠르게 배포한 후 피드백을 반영해 점진적으로 개선하는 접근이 일반적이다.

 

이처럼 PM은 상황에 따라 기능 우선순위를 판단하고, 유저에게 전달할 시점과 이후 업데이트 시점을 조율하는 역할을 맡는다.
그렇다면 기획자 의견에 따라 데드라인을 맞춰 기능을 먼저 유저에게 노출했을 경우, 개발자가 원하는 퀄리티 향상은 이후 반영될 수 있을까?

 

실제 실무에서는 대부분 그렇다. 배포 이후에도 실시간으로 업데이트가 이루어지고, 개발자 의견을 반영해 주기적으로 기능을 다듬는 형태로 운영된다.

즉, ‘완벽한 제품’이 아닌, ‘빠르게 검증하고 점진적으로 개선하는 프로세스’가 더 많이 활용되는 것이다. 그렇기에 우선순위 조정 능력과 지속적인 협업 태도가 PM에게 있어 핵심 역량 중 하나가 된다.

데드라인 vs 퀄리티 – 우선순위 충돌
프로젝트에서 가장 자주 발생하는 마찰 중 하나는 마감 기한과 품질 간의 충돌이다. 예를 들어, 스프린트 마감이 다가왔지만 기능 구현이 80%만 완료된 상황에서 QA까지 포함하면 일정을 맞추기 빠듯한 경우가 있다.

이럴 때 개발자는 “지금 출시하면 안정성에 문제가 생길 수 있어요. 다음 배포에 넣는 게 어떨까요?”라며 퀄리티를 우선으로 생각하는 경향이 있다. 반면에 PM은 “이번에 꼭 출시해야 해요. 유저 요청도 많고, 마케팅 일정도 이미 잡혀 있어요.”라며 일정과 비즈니스 임팩트를 우선으로 고려한다.

이런 충돌을 줄이기 위해서는 기능의 우선순위에 따라 고려 요소를 달리해야 한다.

핵심 기능(예: 결제, 인증, 로그인, 보안)은 퀄리티 우선으로 접근해야 한다. 안정성이 담보되지 않으면 전체 서비스 신뢰도에 타격이 있기 때문이다.반면에 부가 기능(예: 알림 기능, UI 개선, 문구 수정 등)은 속도 우선으로 진행할 수 있다. 다소 불완전하더라도 빠르게 출시하고 후속 개선을 하는 것이 전략적으로 더 나은 선택이 될 수 있다.

PM은 이러한 기능 구분과 우선 고려 요소를 기준으로 개발자와 적절한 의사결정 조율을 해야 한다.

 

 

pm은 무엇을 만들고 왜 만들어야하는가?(비지니스 목표, 데이터 기반)

PM은 *“무엇을 만들 것인가, 왜 만들어야 하는가”*를 고민하는 역할이다. 이는 비즈니스 목표, 유저 니즈, 그리고 데이터 기반의 방향성 설정을 통해 제품이 해결해야 할 문제와 가치를 정의하는 과정이다.

 

반면 개발자는 *“이걸 어떻게 만들 수 있을까, 더 나은 방법은 없을까”*를 고민하는 입장이다. 주로 기술적 안정성, 구조, 유지보수 가능성 등을 고려하여 실제 구현 방식에 집중한다.

 

이처럼 출발점은 다르지만, 두 역할이 바라보는 방향은 ‘제품과 프로젝트의 성공’이라는 동일한 목표를 향해 있다. 그러나 관점의 차이에서 비롯된 오해나 충돌로 인해, 의사소통 과정에서 불필요한 리소스 낭비가 발생하는 경우도 많다.그래서 중요한 것은 서로의 관점을 인정하고 이해하며 조율하려는 태도이다. 이러한 과정을 통해서야 비로소 진짜로 의미 있는 피드백이 오가고, 더 나은 제품이 탄생할 수 있다. 관점의 차이를 이해하고 받아들이는 것 자체가 협업의 시작점이며, 성과를 만들어내는 기반이 되는 셈이다.

 

PM과 개발자는 관점은 다르지만, 결국 바라보는 목표는 같다. 더 나은 제품, 더 나은 사용자 경험, 더 나은 결과를 만들고자 하는 것이 궁극적인 목적이며, 이는 곧 프로젝트와 제품의 성공으로 이어진다.

하지만 두 역할은 서로 다른 기준에서 출발한다.PM은 "무엇을 만들 것인가", "왜 만들어야 하는가"를 고민한다. 이때 비즈니스 목표, 유저 니즈, 데이터 등을 바탕으로 제품의 방향성을 설정한다.반면, 개발자는 "그걸 어떻게 만들 수 있을까", "더 나은 방식은 없을까"를 고민한다. 기술 구조, 안정성, 유지보수 가능성 등을 고려하여 구체적인 구현 방식을 찾는다.

이러한 관점 차이는 종종 충돌로 이어지기도 하지만, 협업의 핵심은 서로의 관점을 인정하고 소통하는 데 있다.협업의 질을 결정짓는 건 태도이며, 서로의 관점을 이해하고 조율할 줄 아는 ‘협업 파트너’가 되는 것이 진정한 협력의 시작점이다.

즉, 방향은 다를 수 있지만 나아가는 길은 하나이며, 좋은 결과를 만들기 위한 서로 다른 접근일 뿐이다.

 

 

 

-실무에서 인정받는 PM은 어떤 사람일까?

실제로 협업을 해보면, 어떤 PM은 "이 사람이랑은 또 같이 일하고 싶다"는 생각이 들고, 어떤 PM은 "이건 너무 힘들다…"는 피드백이 나온다. 이 차이를 만드는 건 단순한 스킬이 아니라 태도와 준비도, 그리고 전반적인 일 처리 방식이다.

 

-최악의 PM은 어떤가요?
기획을 할 때 자신만의 머릿속 구상만으로 작업을 밀어붙이는 경우가 많다. 기본적인 리서치 없이, 기술적 검토나 디자인적 타당성도 체크하지 않은 채 “이거 할 거야, 개발 가능한지 너네가 봐봐”라고 하면, 협업자는 곤란해진다. 실제로는 구현 불가능하거나 리소스가 과하게 들어가는 요구가 많고, 결국 일정이 밀리거나 팀 전체가 혼란스러워지기 쉽다.

 

-좋은 PM은 어떻게 다른가요?
실제로 인정받는 PM은 본인이 작성한 기획안을 기반으로 사전 검토를 철저히 한다. 예를 들어, 킥오프 전에 개발자나 디자이너를 직접 찾아가 “이 기능, 기술적으로 가능한가요?”, “이런 디자인 구성 괜찮을까요?” 하고 물어본다. 한 아르헨티나 출신의 PM 사례처럼, 사전에 1:1로 검토를 여러 번 받고 킥오프에서 이미 대부분의 실현 가능성이 정리되어 있는 경우가 이상적이다.

 

-실무 개발자가 함께 일하고 싶은 PM의 하드 스킬은?
딱히 정해진 커리큘럼이 있는 직무는 아니다 보니, '이 도구를 꼭 써야 한다'보다는 얼마나 다양한 실무를 경험해봤는가, 그리고 도메인에 대해 얼마나 이해하고 있는가를 중요하게 본다. 특히 중소기업이나 스타트업에서는 한 명의 PM이 기획뿐만 아니라 디자인, QA, 마케팅까지 담당하는 경우가 많다.
따라서 넓게 경험해보고, 여러 역할을 한 번씩 해본 경험이 훨씬 큰 자산이 된다.

 

-AI 시대에 더 선호되는 PM은?
요즘은 AI 도구가 실무에 적극적으로 도입되면서, 회사 입장에선 기존 인력보다 더 많은 역할을 하나로 합쳐서 할 수 있는 사람을 기대하게 된다. 다시 말해, 디자인도 어느 정도 이해하고, 개발자와도 기술적 대화를 나눌 수 있고, 간단한 데이터도 직접 보고 해석할 수 있는 사람을 찾는다는 의미다.

 

이제는 “기획만 잘하면 된다”는 시대는 끝났다. 다양한 도메인을 이해하고, 전반적인 흐름을 그릴 수 있으며, 팀원과의 커뮤니케이션을 매끄럽게 이끌 수 있는 사람이 진짜 좋은 PM이다. 실무에서 부딪히며 배우는 것도 좋고, 모르면 ChatGPT나 주변 동료에게 물어보면서 빠르게 성장하려는 태도도 필수다. 잘 몰라도 좋다. 다만, 책임지고 끝까지 가려는 태도가 중요하다.