《개발 너머의 일》개발자가 기획자를 이해하게 된 순간
개발자로 일하면서 가장 흔히 겪는 갈등 중 하나는 바로 기획자와의 충돌입니다. 코드 한 줄 쓰지 않는 기획자가 개발 난이도를 무시하고 무리한 요구를 할 때마다, 속으로 수없이 한숨을 쉬곤 했습니다. 하지만 저 역시 시간이 지나면서 점점 다른 시각을 가지게 되었습니다.
기획자의 논리와 개발자의 현실은 왜 충돌할까?
기획자는 ‘이상’을 바라보고, 개발자는 ‘현실’을 마주합니다. 기획자는 항상 이상적이고 완벽한 제품을 꿈꾸며 요구사항을 작성합니다. 반면 개발자는 시간, 비용, 기술적 제약을 현실적으로 고려해야만 합니다. 서로 다른 시야에서 출발하기 때문에 갈등은 필연적이었습니다.
한 프로젝트에서 기획자는 매력적인 UI와 UX를 원하며 수시로 디자인 변경을 요청했습니다. 반면 개발팀은 이미 정해진 일정과 제한된 리소스 속에서 계속된 수정 요청에 난감했습니다. 결국 빈번한 갈등과 회의를 거듭한 끝에 제품 출시가 연기되는 일도 발생했습니다.
또 다른 사례로는, 기획자가 ‘반응형 웹’을 요구했을 때였습니다. 간단히 들리는 요구사항이었지만, 개발자는 다양한 디바이스와 브라우저 호환성 문제를 미리 걱정했습니다. 이로 인해 끝없는 논의와 조율을 해야 했고, 결국 프로젝트의 전체 일정이 꼬여버렸습니다.
요구사항은 명세서가 아니다
한 번은 프로젝트 초기에 기획자로부터 받은 요구사항 명세서가 너무나도 불분명해서 화가 났습니다. “이런 명세서로는 개발할 수 없다”고 주장했지만, 기획자는 도리어 개발팀이 더 창의적으로 접근하기를 원했습니다. 결국 그 프로젝트는 끊임없는 수정과 추가 요구로 매우 힘들게 마무리되었습니다.
또 다른 경우에는 기획서에 ‘사용자가 편리하게 사용할 수 있도록 한다’는 문구만 있었습니다. 개발팀은 편리함이라는 주관적인 기준을 어떻게 구체화할지 몰라 애를 먹었습니다. 명확한 기준 없이 작업을 진행하다 보니, 기능 구현 후에도 기획자와 개발자 간의 인식 차이로 인해 여러 차례 재작업을 해야 했습니다.
이처럼 개발자는 명확하고 구체적인 지시를 원했지만, 기획자는 오히려 방향성과 목적성만을 제시하며 여지를 남겨두는 경우가 많았습니다. 개발자 입장에서는 이 여지가 부담스러웠지만, 기획자의 입장에서는 오히려 창의적이고 다양한 접근법을 유도하기 위한 전략일 수도 있었습니다.
“기획자가 되지 않더라도, 기획을 이해해야 한다”
개발자로서의 경험이 쌓일수록, 저는 기획의 중요성을 더욱 절실히 느끼게 되었습니다. 결국 훌륭한 제품은 좋은 기획에서 시작되며, 좋은 기획을 이해하는 개발자만이 제대로 된 제품을 만들 수 있다는 사실을 깨달았습니다.
한 번은 제가 직접 작은 기획을 맡아보았습니다. 예상보다 훨씬 어렵고 복잡한 작업이었습니다. 시장 조사, 사용자 조사, 경쟁사 분석 등을 하면서 기획자의 입장이 얼마나 많은 고민과 조율을 필요로 하는지 몸소 깨달았습니다. 이 경험 이후 저는 기획자들과의 소통 방식을 바꾸고, 적극적으로 그들의 고민과 방향을 이해하려 노력하게 되었습니다.
또한, 기획자들과의 워크숍을 정기적으로 열어 각자의 역할과 입장을 공유하는 시간도 가졌습니다. 이러한 소통은 갈등을 현저히 줄였고, 각자의 역할을 존중하게 만들었습니다.
이러한 과정을 거쳐 저는 개발자로서 기획자의 입장을 보다 깊이 이해하게 되었고, 프로젝트 성공을 위해서는 서로의 입장을 존중하고 이해하는 것이 필수라는 사실을 분명히 깨닫게 되었습니다.
다음 편에서는 PM이 되어 리더의 시야를 가지게 된 이야기로 찾아뵙겠습니다.