성공적인 프로그램개발을 위한 개발자와 기획자의 동상이몽 깨기

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

"이게 왜 지금 안 된다는 거죠?"
"기획서에는 이 내용이 없었잖아요."

개발 조직에서 흔히 들을 수 있는 대화입니다. 아니, 대화라기보다는 서로를 향한 날카로운 비명에 가깝겠네요. 기획자와 개발자 사이의 보이지 않는 벽, 여러분의 조직에도 존재하나요? 저 역시 수많은 프로젝트를 이끌며 이 미묘한 긴장감 속에 놓인 적이 한두 번이 아닙니다. 오늘은 기술적 난제보다 해결하기 어렵다는 '소통'에 대해, 특히 성공적인 프로그램개발을 위해 개발자와 기획자가 어떻게 합을 맞춰야 하는지 이야기해 보려 합니다.

솔직히 고백하자면, 저도 주니어 시절에는 기획자를 '요구사항 자판기' 정도로 생각했던 적이 있습니다. 기획서가 내려오면 그대로 코드를 짜는 것이 제 역할이라 믿었죠. 하지만 어느 날, 야심 차게 준비한 기능이 배포 직전에 엎어지는 경험을 했습니다. 기술적으로는 완벽했지만, 비즈니스 목표와는 완전히 엇나간 결과물이었기 때문입니다.

그때 깨달았습니다. 우리가 겪는 갈등의 대부분은 '언어의 차이'가 아니라 '맥락의 부재'에서 온다는 사실을요. 기획자는 '사용자가 무엇을 원하는가'라는 비즈니스 언어를 쓰고, 개발자는 '이것을 어떻게 구현할 것인가'라는 기술 언어를 씁니다. 이 두 언어가 통역 없이 부딪히면 프로젝트는 산으로 갑니다. 단순히 기능 명세서를 주고받는 행위는 협업이 아닙니다. 그것은 그저 '전달'일 뿐이죠.

가장 흔한 실패 패턴은 기획 단계에서 기술적 제약을 고려하지 않고 스펙을 확정한 뒤, 개발 단계에서 "불가능하다"는 통보를 받는 경우입니다. 반대의 경우도 있습니다. 개발자가 기술적 우월성에 취해 비즈니스 임팩트를 무시하고 과도한 엔지니어링(Over-engineering)을 감행하는 상황이죠.

제가 겪은 한 에피소드가 있습니다. 고객사에 납품할 중요한 프로그램개발 프로젝트였는데, 기획팀에서는 '실시간 데이터 연동'을 핵심 기능으로 꼽았습니다. 하지만 당시 우리 인프라 구조상 완전한 실시간 처리는 막대한 비용과 리팩토링이 필요한 상황이었습니다. 개발팀은 즉각 "구조상 불가능합니다"라고 방어막을 쳤고, 기획팀은 "이게 없으면 안 팔린다"며 맞섰습니다. 회의실 공기가 차갑게 얼어붙었죠.

문제를 해결한 건 '질문의 변화'였습니다. 제가 기획팀에 물었습니다. "고객이 원하는 '실시간'이 0.1초 단위의 즉각적인 반응인가요, 아니면 1분 정도의 딜레이는 허용되나요?" 놀랍게도 답은 "5분 정도 늦어도 상관없지만, 버튼을 눌렀을 때 최신 데이터라는 확신만 주면 된다"였습니다.

결국 우리는 복잡한 소켓 통신이나 스트리밍 아키텍처를 도입하는 대신, 사용자가 조회 버튼을 누를 때만 데이터를 갱신하는 심플한 방식으로 요구사항을 해결했습니다. 개발 리소스는 1/10로 줄었고, 고객 만족도는 그대로였습니다. 이것이 바로 '맥락 공유'의 힘입니다.

그렇다면 풀링포레스트에서는 이 문제를 어떻게 해결하고 있을까요? 우리는 '기획 리뷰'가 아닌 '솔루션 워크숍'을 지향합니다. 기획자가 "A를 만들어주세요"라고 요구하는 자리가 아니라, "지금 우리가 해결해야 할 문제는 A입니다"라고 문제를 정의하는 자리입니다.

이때 개발자는 "안 됩니다"가 아니라 "그 문제를 해결하려면 A보다는 B 방식이 기술적으로 더 효율적이고 빠릅니다"라고 제안해야 합니다. 기획자는 개발자의 기술적 제안을 통해 상상하지 못했던 더 좋은 UX를 발견할 수 있고, 개발자는 비즈니스 목표를 이해함으로써 불필요한 코딩을 줄일 수 있습니다.

성공적인 협업을 위해 제가 제안하는 실전 체크리스트는 다음과 같습니다.

첫째, 용어 사전을 만드세요. 기획자가 말하는 '배포'와 개발자가 말하는 '배포'의 의미가 다를 수 있습니다. 같은 단어를 쓰고 있는지 확인하는 것만으로도 오해의 절반은 줄어듭니다.

둘째, 시각화 도구를 적극 활용하세요. 텍스트로 된 기획서는 필연적으로 해석의 여지를 남깁니다. 피그마(Figma)나 간단한 와이어프레임, 하다못해 화이트보드 그림이라도 좋습니다. 눈으로 보이는 합의점이 있어야 딴소리가 나오지 않습니다.

셋째, '왜(Why)'를 묻는 것을 두려워하지 마세요. 개발자가 기획 의도를 묻는 것은 월권이 아니라 의무입니다. "이 기능이 왜 필요한가요?"라는 질문이 날카로운 공격이 아니라, 더 좋은 제품을 만들기 위한 순수한 호기심으로 받아들여지는 문화를 만들어야 합니다.

프로그램개발은 혼자만의 예술 활동이 아닙니다. 그것은 문제를 정의하는 사람과 해결책을 구현하는 사람이 함께 추는 춤과 같습니다. 서로의 발을 밟지 않으려면 끊임없이 눈을 맞추고 호흡을 확인해야 합니다.

기술은 결국 사람을 향합니다. 우리가 작성하는 수만 줄의 코드도 결국 누군가의 문제를 해결하기 위함이라는 본질을 잊지 않는다면, 기획자와의 소통은 더 이상 스트레스가 아닌 즐거운 창조의 과정이 될 것입니다. 오늘 동료 기획자에게 커피 한 잔을 권하며 이렇게 물어보세요. "우리가 지금 풀고 있는 진짜 문제가 뭘까요?" 그 대화 속에 혁신의 실마리가 숨어 있을지도 모릅니다.