개발자가 PM·기획자와
갈등했던 실제 사례 3가지
누구의 잘못도, 누구의 승리도 아니었던 이야기들
이 글을 쓰기까지 망설였던 이유
PM과 갈등했던 이야기를 쓰려다가 몇 번을 멈췄다. 욕처럼 들릴까봐서도 아니고, 회사 얘기가 될까봐서도 아니었다. 정확히는, 내가 완전히 옳았던 갈등이 하나도 없었기 때문이다.
돌아보면 셋 다 비슷했다. 나는 기술적으로 말이 안 된다고 생각했고, 상대는 제품 관점에서 당연한 요구라고 생각했다. 그리고 둘 다 각자 기준에서는 틀리지 않았다. 그게 가장 지독한 종류의 갈등이다. 명백한 악당이 없는 갈등.
지금 PM이나 기획자와 부딪히고 있는 개발자에게, 혹은 개발자 때문에 답답한 PM에게 이 글이 조금이라도 도움이 됐으면 한다. 판단은 읽는 분이 해주셨으면 한다.
등장하는 인물들의 이름은 모두 가명이고, 세부 상황은 특정 회사를 알아볼 수 없도록 일부 변형했다. 그러나 갈등의 본질과 내가 느낀 감정은 그대로다.
사례 1 — "이거 그냥 하면 안 돼요?"
스타트업 입사 7개월 차였다. PM 재연 씨가 새로운 필터 기능을 요청했다. 상품 목록 페이지에서 카테고리, 가격대, 평점을 복합으로 필터링하는 기능이었다. 얼핏 보면 간단했다. 그런데 우리 코드베이스를 아는 나로서는 간단하지 않았다.
당시 상품 목록 페이지는 getServerSideProps 안에서 API를 세 개 동시에 부르고 있었고, URL 쿼리 파라미터 관리가 전혀 안 되어 있었다. 필터 상태를 URL에 반영하지 않으면 새로고침 시 초기화되고, 공유 링크도 안 되고, SEO에도 영향이 갔다. 제대로 만들려면 URL 파라미터 구조 자체를 다시 잡아야 했다.
그걸 설명했더니 재연 씨 반응은 이랬다.
거기서 대화가 어색하게 끊겼다. 나는 설명이 부족했고, 재연 씨는 납득을 못 했다. 결국 팀장이 중재해서 일단 state로 먼저 만들고, 다음 스프린트에 URL 반영을 추가하기로 했다.
새로고침하면 날아가는 필터. 예상대로였다. QA에서 버그로 올라왔다.
결국 페이지 구조를 건드려야 했다. 예상보다 이틀이 더 걸렸다.
"이런 경우 처음부터 얘기해줬으면 좋았겠다"고 했다. 나도 맞다고 생각했다.
"기술 부채"라는 단어는 개발자끼리 통한다. PM한테는 통하지 않는다. "이렇게 만들면 3주 뒤에 이 기능 추가할 때 2배 더 걸린다"처럼 비즈니스 언어로 바꿔 말했어야 했다. 그걸 못 한 건 내 문제였다.
사례 2 — 스프린트 마지막 날의 기획 변경
2스프린트에 걸쳐 만든 결제 플로우였다. 장바구니 → 배송지 입력 → 결제수단 선택 → 최종 확인 → 완료. Next.js의 app router로 각 단계를 별도 라우트로 구성했고, 뒤로가기 시 상태가 유지되도록 Zustand 스토어로 플로우 상태를 관리했다. 스프린트 마지막 날 배포 전 최종 QA에서 PM 지훈 씨가 화면을 보더니 말했다.
"배송지 입력이랑 결제수단 선택을 한 화면에 합칠 수 없을까요? 사용자 테스트에서 단계가 너무 많다는 피드백이 있었어요."
그 순간 솔직히 머리가 하얘졌다. 단계를 합친다는 건 라우트 구조 자체를 바꾼다는 거였다. 상태 관리도 다시 설계해야 했다. 이틀 안에 될 작업이 아니었다.
"사용자 테스트는 언제 한 거예요?" — 내가 실제로 한 말. 그 순간엔 이게 최선이었는데, 지금 생각하면 최악의 시작이었다.
지훈 씨는 지난주에 테스트를 진행했다고 했다. 기획 단계에서 미리 공유됐으면 좋았겠다고 했더니, 지훈 씨는 개발 중에 기획이 바뀔 수도 있는 거라고 했다. 분위기가 싸해졌다.
결국 이번 스프린트엔 기존 플로우로 배포하고, 다음 스프린트에 구조를 재설계하기로 합의했다. 기술적으로는 맞는 결정이었다. 하지만 배포 당일 밤까지 회의가 이어진 건 내 탓이기도 했다. 더 일찍, 더 자주 중간 공유를 했더라면 이 상황은 막을 수 있었다.
지훈 씨가 늦게 얘기한 것도 있지만, 나도 개발 2주 동안 중간에 플로우 화면을 한 번도 공유하지 않았다. "다 만들면 보여주면 되지"라고 생각했던 게 문제였다. 완성품을 처음 보면 변경 요청이 생기는 게 당연하다.
사례 3 — 디자인 시스템과 "딱 한 번만"
이건 갈등이라기보다는 서서히 쌓인 마찰이었다. 우리 팀은 디자인 시스템을 3개월에 걸쳐 구축했다. 버튼 컴포넌트, 입력 필드, 카드, 모달 — 전부 공통 컴포넌트로 만들었고, 팀 내에서 "이제 이걸 벗어난 UI는 개발하지 않는다"고 합의했었다.
그런데 기획자 소정 씨가 이벤트 페이지 작업을 가져왔다. 요구사항에 버튼 색상이 기존 컴포넌트에 없는 그라데이션이었고, 카드 컴포넌트에 hover 시 3D flip 효과가 있었다. "이번 이벤트만 특별하게 쓰는 거니까 예외로 해주면 안 될까요?"
나는 거절했다. 소정 씨는 이번 한 번만이라고 했다. 나는 그 "이번 한 번"이 쌓이면 디자인 시스템 의미가 없어진다고 했다. 소정 씨는 이벤트마다 다른 느낌을 줘야 사용자가 신선함을 느낀다고 했다. 나는 그걸 위해 시스템을 깨면 나중에 유지보수 비용이 터진다고 했다.
이 질문에서 나는 잠깐 멈췄다. 솔직히 말이 됐다. 이벤트 페이지는 임시 페이지였다. 그걸 위해 공통 컴포넌트를 억지로 확장하는 게 오히려 이상한 일일 수도 있었다.
결국 타협안을 냈다. 이벤트 전용 디렉토리를 따로 만들고, 그 안에서만 별도 스타일을 쓰되 공통 컴포넌트에는 영향을 주지 않는 구조로 만들었다. 소정 씨도 그 조건이면 괜찮다고 했다. 내가 처음부터 이 방향을 제시했으면 훨씬 빨리 끝났을 문제였다.
이 갈등은 그나마 결말이 좋았다. 소정 씨의 질문이 내 전제를 흔들었고, 나도 생각을 바꿀 수 있었다. 고집을 꺾는 게 아니라, 더 나은 해결책으로 이동하는 것. 그게 협업이었다.
세 사례를 돌아보며 공통점을 찾다
세 번의 갈등이 다 달랐지만, 지금 보면 공통 패턴이 있다. 나는 항상 기술적으로 옳았다. 그리고 그게 문제였다.
"나는 옳고, 상대는 모른다"는 전제로 대화를 시작하면 상대방은 설득이 아니라 설교처럼 느낀다. 재연 씨는 기술 부채를 몰랐던 게 아니라, 그게 지금 왜 중요한지를 내가 설명하지 못한 것이다. 지훈 씨는 늦게 요청한 게 잘못이었지만, 나도 중간 공유를 하지 않았다. 소정 씨의 요청은 실제로 합리적인 면이 있었다.
기술 용어를 비즈니스 영향으로 번역해서 전달해야 한다. "기술 부채" → "다음 기능에 n일 더 걸림"
완성품을 처음 보여주면 변경 요청이 생긴다. 초안을 빨리 보여줄수록 늦은 뒤집기가 줄어든다.
"안 돼요"보다 "이렇게 하면 돼요"가 협업이다. 거절할 때는 항상 대안을 같이 내야 한다.
PM이 마감을 왜 당기는지, 기획자가 왜 예외를 요청하는지. 맥락을 알면 해결책이 보인다.
지금 내가 갈등을 대하는 방식
지금도 PM이나 기획자와 의견이 부딪힌다. 없어지지는 않는다. 다만 대응 방식이 달라졌다.
요청이 오면 먼저 "왜 이게 필요한지"를 물어본다. 기능 뒤에 있는 목적을 알면, 내가 생각한 방법보다 더 좋은 방법이 있을 때가 많다. 그리고 거절할 때는 반드시 대안을 같이 낸다. "안 됩니다"로 끝나는 대화는 아무것도 해결하지 않는다.
무엇보다, 갈등 자체가 나쁜 게 아니라는 걸 알게 됐다. 개발자와 PM이 같은 걸 보면 서로의 전문성이 제대로 발휘되지 않는 거다. 다른 시각이 부딪히는 게 맞고, 그 충돌에서 더 나은 제품이 나온다. 지독하게 불편하지만, 그게 협업이다.
좋은 협업은 갈등이 없는 게 아니라, 갈등을 생산적으로 소화하는 것이다. 그걸 배우는 데 3번의 충돌이 필요했다.
갈등의 원인을 내 관점에서 분석하면
세 사례에서 내가 기여한 문제 비중을 솔직하게 돌아보면 이렇다.
※ 지극히 주관적인 회고 수치입니다. 상대방이 평가하면 숫자가 달라질 수 있습니다.
개발자와 PM은 같은 제품을 보면서 다른 언어로 대화한다. 개발자는 구조와 비용을 보고, PM은 사용자와 일정을 본다. 둘 다 제품을 위한 시각이다. 어느 쪽이 더 중요하냐는 질문 자체가 잘못됐다.
지금도 이 균형을 잘 맞추고 있냐고 하면, 여전히 모르겠다. 다만 적어도 "내가 기술적으로 옳으니 상대가 이해해야 한다"는 전제는 버렸다. 그것만으로도 대화가 훨씬 달라진다는 건 확실히 안다.
💬 비슷한 경험이 있으신가요?
개발자로서 PM·기획자와 부딪혔던 경험, 혹은 반대로 PM 입장에서 개발자와 소통이 어려웠던 경험이 있다면 댓글로 나눠주세요. 어느 쪽 입장이든 환영합니다. 서로의 시각을 보는 것 자체가 도움이 될 것 같습니다.
'개발자 > 실무 개발 현장' 카테고리의 다른 글
| 스프린트와 애자일, 현장에서 실제로 어떻게 돌아가나 (0) | 2026.07.06 |
|---|---|
| 혼자는 천재, 팀에는 민폐 - 혼자 개발하다 팀 협업으로 넘어올 때 가장 어려웠던 것 (0) | 2026.06.29 |
| 코드 리뷰 처음 받았을 때 멘탈 터진 경험, 그날 퇴근길에 울 뻔했다 (1) | 2026.06.22 |
| 배포 후 장애 터졌을 때, 그 긴박했던 밤 이야기 (0) | 2026.06.15 |
| 신입 개발자가 처음 맞닥뜨린 레거시 코드 — 살아남기까지의 기록 (0) | 2026.06.08 |
