brunch

같은 것을 다르게 말하는 이유

기획자와 개발자의 대화

by 닥터브룩스

관점과 언어의 차이는 곧 협업의 난관이 된다. 상품 개발 과정에서 기획자와 개발자의 협업은 필수적이다. 그러나 두 역할은 같은 대상을 두고도 서로 다르게 이야기하는 경우가 많아, 협업 과정에서 어려움을 자주 겪는다. 이러한 차이는 크게 언어(용어)의 차이, 전달 방식의 차이, 실행 과정의 차이로 나눌 수 있다. 이 글에서는 각각의 차이가 협업에 미치는 영향과, 이를 극복하기 위한 (나름의) 실질적 방안을 살펴보고자 한다.




용어와 언어의 차이로 인해서 같은 말을 다르게 해석하는 문제다. 기획자와 개발자는 동일한 개념을 서로 다른 용어로 표현하며, 이로 인해 오해가 발생한다. 예를 들어 기획자가 “사용자 친화적인 UI”를 요청할 때, 이는 직관적이고 시각적으로 깔끔한 인터페이스를 의미할 수 있다. 반면, 개발자는 버튼 배치, 반응 속도, 코드 최적화 등 기술적 요소에 초점을 맞춘다. 또한 “실시간 업데이트”라는 표현 역시, 기획자는 단순한 화면 갱신을 의미할 수 있지만, 개발자는 웹소켓 기반의 데이터 스트리밍을 떠올릴 수 있다.

이러한 용어 불일치는 서로의 배경 지식과 전문 용어 이해도 차이에서 비롯된다. 실제로 IT 프로젝트 실패의 약 30%가 의사소통 문제에서 기인하며, 그중 용어 불일치가 주요 원인 중 하나로 꼽힌다(출처: PMI Report, Pulse of the Profession 2023)


전달 방식에 있어서도 차이가 있다. 이는 문제 접근과 소통 스타일의 간극을 치부된다. 기획자는 비즈니스 목표와 사용자 경험에 초점을 맞추고, 추상적이고 포괄적인 언어로 큰 그림을 제시한다. 예컨대 “고객 참여도를 높이는 기능”을 제안할 때 구체적 구현보다는 결과를 강조한 반면, 개발자는 기술적 제약과 구현 가능성에 집중하며, 구체적이고 세부적인 논의를 선호한다. 이로 인해 기획자의 제안이 개발자에게는 모호하게 들릴 수 있고, 개발자의 설명은 기획자에게 지나치게 복잡하게 느껴질 수 있다. 이러한 차이는 문서화 방식이나 회의 진행에서도 드러난다. 기획자는 와이어프레임(뼈대 역할)이나 사용자 스토리(시나리오)로 요구사항을 전달하지만, 개발자는 이를 데이터 흐름도, API 명세 등 기술적 문서로 변환해야 한다. 예를 들어보자면, “결제 시스템을 간편하게”라는 요청은 개발자에게 결제 API, 보안, 트랜잭션 처리 등 다양한 기술적 요구로 이어진다. 기대치가 어긋나면 프로젝트 지연으로 이어질 수 있다.


또한, 실행 과정의 차이는 반복과 안정성에 대한 상반된 기대를 낳을 수 있다. 실행 단계에서도 차이는 두드러진다. 기획자는 시장 반응이나 사용자 피드백을 바탕으로 빠른 수정과 반복(애자일 방식)을 선호한다. 예를 들어 베타 테스트 후 기능을 신속하게 추가나 변경을 하려 할 수 있다. 하지만, 개발자는 시스템 안정성과 유지보수를 중시해 초기 설계에 충실하려 하거나, 잦은 변경에 따른 코드 리팩토링 부담을 우려한다. 그렇기 때문에 스타트업에서는 “빠른 기능 추가” 요청이 코드 구조 재설계와 충돌하는 일이 발생할 수 있다. 이처럼 반복과 안정성에 대한 기대 차이가 시행착오 빈도와 속도에 영향을 미친다.


pexels-kevin-ku-92347-577585.jpg

출처: Pexels.comⓒ2017 Kevin Ku


이러한 차이를 줄이기 위해서는 다음과 같은 구체적 노력이 필요하다.

첫째, 공통 용어집(Glossary)을 공유하는 것이다. ‘실시간’, ‘사용자 친화적’ 등 주요 용어의 정의를 양측이 합의해 문서화하면 오해를 줄일 수 있다. 서로의 분야에서 쓰이는 도메인 지식을 공유하는 과정도 중요하다.

둘째, 정기적 교류회를 실시하는 것이다. 기획자와 개발자가 서로의 관점을 이해할 수 있도록 정기적으로 워크숍을 진행한다. 기획자는 기술적 제약을, 개발자는 비즈니스 목표를 이해하는 세션을 마련하면 효과적이라고 생각한다.

마지막으로, 프로토타입 및 피드백 루프 강화하는 것이다. 초기 단계에서 최소기능제품(MVP)을 공동 정의하고, Figma와 같은 협업 툴을 활용해 실시간으로 기획과 개발을 조율한다. 이를 통해 시행착오를 줄이고 기대치를 일치시킬 수 있다.

세 가지 실천항목은 실제로 현업에서 실행하기가 매우 어려운 것이 현실이다. 스타트업은 소규모이기 때문에 비교적 원활한 소통으로 서로 간의 빠른 피드백이 가능하지만, 규모가 커질수록 이런 활발한 활동을 기대하는 것은 욕심일 수 있다. 하지만, 나아가기 위해서, 더 전진하기 위해서는 기획자와 개발자 간의 진실한 소통이 필수적임을 강조하지 않을 수 없다.


어떤 일을 하기 위해서는 소통이 가장 중요하다. 특히 기획자와 개발자 간의 언어, 전달, 실행 방식의 차이는 협업의 주요 장애물이다. 왜냐하면 그것이 소통을 방해하는 장애물이기도 하기 때문이다. 그러나 공통 용어집 작성, 정기 워크숍, 프로토타입 기반 협업 등 실질적 노력을 통해 서로의 관점을 조율하며 소통에 적극적으로 임하게 되면 방해물은 자연스럽게 사라질 것이다.

궁극적으로, 서로의 언어와 관점을 이해하고 존중할 때 더 나은 상품 개발과 혁신이 가능해질 것이다.




keyword
작가의 이전글지리적 결정론