개발자-기획자 갈등 (언어차이, 구조문제, 협업전환)

개발자-기획자 갈등

솔직히 저는 오랫동안 이 갈등이 '사람 문제'라고 생각했습니다. 기획자가 개발을 모르거나, 개발자가 소통을 못하거나. 그런데 20년을 일하고 나서 깨달은 건, 그게 절반도 맞지 않는 진단이라는 것입니다. 개발자와 기획자 사이의 충돌은 생각보다 훨씬 구조적이고, 그래서 훨씬 더 다루기 까다롭습니다.

서로 다른 언어를 쓰는 두 직군이 한 테이블에 앉을 때

개발자는 구현 가능성(feasibility)의 언어로 말합니다. 여기서 feasibility란, 주어진 기술 스택과 일정 안에서 특정 기능이 실제로 만들어질 수 있는지를 판단하는 기준입니다. 반면 기획자는 사용자 경험(UX, User Experience)의 언어로 말합니다. UX란 사용자가 제품이나 서비스를 사용하는 과정에서 느끼는 전반적인 경험을 뜻하는데, 이 두 관점은 같은 기능을 두고도 전혀 다른 우선순위를 만들어냅니다.

제가 직접 겪어보니, 초반 5년 동안 기획서를 받을 때마다 '왜 이렇게 허술하냐'는 생각이 먼저 들었습니다. 리뷰 미팅에서 기술적 제약을 설명하다 지쳐서 "안 됩니다"로 끊어버린 적도 많았습니다. 당시엔 그게 합리적인 판단이라고 여겼는데, 지금 돌아보면 그건 소통의 실패가 아니라 언어의 불일치였습니다. 통역사 없이 두 나라 사람이 협상 테이블에 앉아 있던 셈이었습니다.

이 언어 차이가 현장에서 가장 자주 터지는 순간은 일정 협의입니다. "이거 금방 되는 거 아니에요?"라는 한 문장 안에는 얼마나 많은 오해가 압축되어 있는지, 당시엔 설명할 말조차 찾기 어려웠습니다. 실제로 개발 일정을 기획자가 임의로 산정하는 조직에서는 기술 부채(technical debt)가 빠르게 쌓입니다. 기술 부채란, 빠른 출시를 위해 코드 품질이나 설계 완성도를 희생했을 때 나중에 더 큰 비용으로 돌아오는 문제를 말합니다. 당장의 기능 출시 속도를 높이려다 나중에 수십 배의 재작업 비용을 치르는 패턴이 반복되는 이유가 여기 있습니다.

개발자와 기획자의 언어 차이가 유발하는 주요 충돌 지점을 정리하면 다음과 같습니다.

• 일정 산정: 기획자는 기능 단위로 생각하고, 개발자는 의존성과 예외 처리까지 포함한 공수를 산정합니다.
• 요구사항 변경: 기획자에게 "작은 수정"이 개발자에게는 DB 스키마 변경이나 API 재설계를 의미할 수 있습니다.
• 완성의 기준: 기획자는 화면이 나오면 완성이라고 보지만, 개발자는 예외 케이스 처리와 성능 최적화까지 포함합니다.

갈등의 진짜 원인은 개인이 아니라 구조였습니다

전환점은 10년차 즈음이었습니다. 당시 시니어 기획자가 기획서를 전달하기 전에 저를 불러 30분 동안 구두로 설명해주는 습관이 있었습니다. 처음엔 귀찮다고 생각했는데, 어느 순간 그 30분이 이후에 발생할 수십 시간의 재작업을 막고 있다는 걸 깨달았습니다. 기획 의도를 먼저 알면 '왜 이 기능이 필요한가'를 이해한 상태로 개발에 들어가게 됩니다. 그러면 제가 먼저 더 나은 구현 방식을 제안하게 되고, 갈등이 협업으로 바뀌는 순간이 만들어집니다.

그런데 여기서 중요한 질문이 있습니다. 이런 변화가 왜 모든 팀에서 일어나지 않는가. 제 경험상 이건 개인의 의지 문제가 아닌 경우가 더 많았습니다. 기획자는 기능의 수와 출시 속도로 성과를 평가받고, 개발자는 버그 없는 안정성으로 평가받는 조직 구조에서, 두 직군은 구조적으로 다른 방향을 보고 있습니다. 이걸 개인의 태도 문제로만 접근하는 건 처방이 틀린 겁니다.

애자일(Agile) 방법론에서 도입된 스크럼(Scrum)이 이 문제를 부분적으로 해소하려는 시도입니다. 스크럼이란 2주 내외의 짧은 스프린트 단위로 개발과 기획을 함께 검토하는 협업 프레임워크를 말합니다. Jira 같은 협업 도구도 이 맥락에서 도입된 것인데, 도구보다 더 중요한 것은 '같은 목표를 보는가'입니다. 도구는 투명성을 만들지만, 공동의 성공 기준은 조직이 설계해야 합니다.

국내 IT 기업의 협업 방식에 대한 실태 조사에서도 직군 간 업무 이해 부족이 갈등의 주요 원인으로 꼽힙니다(출처: 정보통신정책연구원). 개인이 아무리 노력해도 이해관계의 충돌이 반복되는 이유는, 조직이 의도적으로 교차 학습의 시간과 구조를 만들지 않기 때문입니다.

20년이 걸려 배운 협업 전환의 실제 조건

15년차 이후부터 저는 기획 단계에 먼저 들어가기를 자청했습니다. 기능 명세가 완성된 뒤에 개발자에게 던져주는 워터폴(Waterfall) 방식이 아니라, 초안 단계부터 기술적 제약과 대안을 함께 논의하는 방식입니다. 워터폴이란 기획-설계-개발-테스트가 순차적으로 진행되는 전통적인 개발 방법론인데, 이 방식에서는 기획이 완료된 뒤에야 개발자가 제약 사항을 발견하게 되어 뒤늦은 수정 비용이 커집니다.

가장 결정적으로 배운 것은 '아니오'를 말하는 방식이었습니다. 예전엔 "안 됩니다"로 끝냈다면, 이제는 "지금 방식으론 3주가 걸리는데, 이렇게 바꾸면 1주에 됩니다"라고 말합니다. 거절이 아니라 대안 제시입니다. 이 차이 하나가 관계의 온도를 완전히 바꿉니다. 제 경험상 이 한 문장의 변화가 팀 전체의 분위기를 바꾸는 데 몇 달이 채 걸리지 않았습니다.

서비스 기획자가 개발 구조를 이해하기 시작했을 때 일정 갈등이 실질적으로 해소되는 사례는 현장에서 반복적으로 관찰됩니다. 실제로 소프트웨어 프로젝트의 일정 초과 원인 중 요구사항 불명확이 가장 큰 비중을 차지한다는 연구 결과도 있습니다(출처: Standish Group CHAOS Report). 기획자가 API(Application Programming Interface, 서로 다른 소프트웨어 시스템이 데이터를 주고받는 연결 방식)의 개념이나 DB(데이터베이스) 구조의 기초를 이해하면, 무리한 요구사항 자체가 줄어듭니다.

협업 전환을 위해 조직 차원에서 실질적으로 해볼 수 있는 것들은 다음과 같습니다.

1. 기획 초안 단계부터 개발자를 리뷰어로 포함시킨다.
2. 일정 산정 권한을 개발자에게 주고, 기획자는 그 근거를 함께 학습한다.
3. 직군 간 성과 지표(KPI)를 완전히 분리하지 않고, 프로젝트 단위의 공동 목표를 설정한다.
4. 스크럼 데일리 스탠드업 등 짧은 주기의 정기 싱크를 습관화한다.

20년이 지난 지금, 가장 좋은 기획자-개발자 관계는 서로의 무지를 인정하고 배우려는 사람들 사이에서 만들어진다는 걸 압니다. 하지만 그 조건을 만들어주는 것은 결국 조직의 구조입니다. 개인에게 "서로 이해하라"고만 주문하는 조직은, 매번 같은 갈등을 새로운 사람들이 반복하게 만듭니다. 지금 팀에서 비슷한 충돌이 반복된다면, 사람을 탓하기 전에 어떤 구조가 그 충돌을 만들고 있는지를 먼저 들여다보시길 권합니다.

---

참고: 기획자 데이먼, "개발자와 효과적으로 커뮤니케이션하는 법", Brunch — https://brunch.co.kr/@cysstory/37
@tsp, "개발자, 디자이너, 기획자의 온도차", Brunch — https://brunch.co.kr/@tsp/8
Slowalk, "기획자와 개발자, 어서 친해지길 바라" — https://slowalk.com/2466
Billionnapkin, "서비스 기획자, 개발을 알면 벌어지는 일들" (2024) — https://billionnapkin.com
@okko8522, "오늘도 개발자가 안 된다고 말했다", Velog (2022) — https://velog.io/@okko8522