기획자와 개발자가 서로를 탓하지 않고 프로그램개발을 성공시키는 법

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

개발 조직을 리딩하다 보면 사무실 구석에서, 혹은 슬랙 채널 한구석에서 묘한 긴장감이 흐르는 순간을 자주 목격합니다. 바로 기획자와 개발자가 충돌하는 지점입니다. "기획서에 없는 내용인데요?"라는 개발자의 방어와, "이건 당연히 되어야 하는 거 아닌가요?"라는 기획자의 공격이 오가는 순간이죠. 솔직히 말씀드리면, 저 역시 주니어 시절에는 기획자를 '요구사항을 끊임없이 바꾸는 사람' 정도로 치부했던 적이 있습니다. 하지만 수많은 프로젝트를 거치며 깨달은 건, 성공적인 프로그램개발은 코드 퀄리티 이전에 '오해를 줄이는 대화'에서 시작된다는 사실이었습니다.

가장 뼈아팠던 기억 하나를 꺼내보겠습니다. 과거 핀테크 관련 프로젝트를 진행할 때였습니다. 기획팀에서 내려온 요구사항은 '안전하고 빠른 결제 시스템 구축'이었습니다. 저희 개발팀은 '안전'이라는 키워드에 꽂혀 모든 트랜잭션마다 이중, 삼중 검증 로직을 넣고 복잡한 암호화 과정을 거치도록 설계했습니다. 기술적으로는 완벽에 가까운 보안성을 자랑했죠.

하지만 결과는 참담했습니다. 정작 사용자는 결제 버튼을 누르고 로딩이 3초 이상 걸리자 이탈해 버렸습니다. 기획자가 의도했던 '빠른'은 UX 관점에서의 속도감이었는데, 개발자는 이를 '서버 처리량'이나 '기술적 안정성'으로만 해석했던 겁니다. 결국 코드를 절반 이상 걷어내야 했고, 일정은 지연되었습니다. 이 실패는 기술력이 부족해서가 아니었습니다. 서로 바라보는 '성공의 그림'이 달랐기 때문입니다.

많은 개발자가 기획서를 '설계도'로 받아들입니다. 설계도대로 벽돌을 쌓는 것이 본인의 역할이라 생각하죠. 하지만 소프트웨어 기획서는 건축 도면처럼 완벽할 수 없습니다. 비즈니스 환경은 살아있는 생물처럼 변하고, 모든 예외 케이스를 문서에 담는 건 불가능하기 때문입니다. 여기서 개발자의 역할은 기획서의 빈칸을 코드로 채우는 것이 아니라, 기획자와 함께 빈칸에 무엇이 들어가야 할지 '질문'하는 것입니다.

그렇다면 어떻게 해야 서로 얼굴 붉히지 않고 효율적으로 협업할 수 있을까요? 풀링포레스트 팀에서 실천하고 있는 몇 가지 원칙을 공유합니다.

첫째, '무엇(What)'이 아니라 '왜(Why)'를 먼저 물어야 합니다. 기획자가 "회원가입 버튼을 빨간색으로 바꿔주세요"라고 했을 때, 단순히 CSS만 수정하는 건 하수입니다. "왜 빨간색이어야 하나요?"라고 물어보세요. "사용자가 가입 버튼을 못 찾아서 이탈률이 높아요"라는 대답이 돌아온다면, 색상 변경이 아니라 버튼 위치를 옮기거나 플로우를 단순화하는 더 나은 기술적 제안을 할 수 있습니다. 이것이 진짜 프로그램개발의 가치를 높이는 길입니다.

둘째, 용어의 정의를 일치시켜야 합니다. 개발자가 말하는 '배포'와 기획자가 생각하는 '배포'가 다를 때가 많습니다. 개발자는 '스테이징 서버 업로드'를 배포라 생각하고, 기획자는 '앱스토어 출시'를 배포라 생각한다면 대참사가 일어납니다. 도메인 주도 설계(DDD)에서 말하는 '유비쿼터스 언어(Ubiquitous Language)'까지는 아니더라도, 프로젝트 초기에 핵심 용어집을 만들어 서로의 언어를 동기화하는 과정이 반드시 필요합니다.

셋째, '시각적인 합의'를 빠르게 도출하세요. 텍스트로 된 기획서 백 장보다 프로토타입 하나가 훨씬 강력합니다. 저희는 기획 단계에서부터 개발자가 참여하여 피그마(Figma) 같은 도구로 화면 흐름을 보거나, 화이트보드에 대략적인 아키텍처와 유저 플로우를 그려보며 논의합니다. 이 과정에서 개발 난이도가 너무 높은 기능은 덜어내고, 더 효율적인 대안을 제시하며 스펙을 확정합니다. 코드를 다 짜고 나서 수정하는 비용보다, 기획 단계에서 말 한마디로 수정하는 비용이 압도적으로 저렴하기 때문입니다.

마지막으로, 기획자를 '고객을 대변하는 사람'으로 인정하는 태도가 필요합니다. 개발자인 우리가 보기에 비논리적이거나 비효율적인 요구사항이라도, 그것이 비즈니스의 핵심 가치를 위한 것이라면 기술적 난제를 해결해 주는 것이 우리의 전문성입니다. 반대로 기획자 역시 개발자의 기술적 제약을 이해하고 존중할 때 건강한 제품이 나옵니다.

결국 프로그램개발은 컴퓨터와 대화하는 작업인 동시에, 사람과 소통하여 가치를 만들어내는 과정입니다. 지금 혹시 모호한 기획서 때문에 답답해하고 계신가요? 모니터 뒤에서 한숨만 쉬기보다는, 지금 당장 기획자 자리로 가서 커피 한 잔을 권하며 물어보세요. "우리가 이 기능을 왜 만드는지, 제가 제대로 이해했는지 확인하고 싶습니다"라고 말이죠. 그 작은 대화가 프로젝트의 운명을 바꿀 수도 있습니다.