확정짓고싶은 개발자, 감히 최종이라 말못하는 기획자

설계가 중요한 개발자와 결과물이 중요한 기획자의 차이

프로젝트를 시작할 때 개발자들은 흔히 “최종 기획안”을 요청한다. 하지만 이 ‘최종’이라는 단어는 기획자들에게 현실적으로 받아들이기 어려운 부담으로 다가온다. 현재 시점의 기획안이 확정이라고 말하기 어려울 뿐만 아니라, 시장에서 성공한 대부분의 서비스들도 최초 기획과는 전혀 다른 모습으로 진화해왔기 때문이다. 이처럼 상반된 두 직군의 입장 차이는 각자의 전문성과 업무 특성에서 비롯된다.

기획자는 프로젝트의 유동성을 무엇보다 중요하게 생각한다. 여기에는 세 가지 핵심적인 이유가 있다. 첫째, 기획서 초안 단계에서 모든 것을 확정하는 것은 현실적으로 불가능하다. 초안이란 말 그대로 여러 가능성의 시작점일 뿐이다. 이후 다양한 이해관계자의 의견이 추가될 것이고, 최종 의사결정권자의 검토를 거치기까지 수많은 변경이 예상된다. 지금 최선이라 생각한 기획안도 여러 단계의 피드백을 거치며 전혀 다른 모습으로 변모할 수 있다.

둘째, 시장 변화에 유연하게 대응할 수 있어야 한다. 현재 가장 영향력 있는 SNS 중 하나인 Instagram의 사례가 이를 잘 보여준다. Instagram은 처음에는 Burbn이라는 이름의 위치 기반 체크인 서비스였다. 하지만 시장의 반응을 민첩하게 파악해 사진과 동영상 공유 플랫폼으로 방향을 전환했고, 독특한 필터 기능을 강화하며 폭발적인 성장을 이뤄냈다

마지막으로, 실제 사용자의 피드백은 서비스의 방향을 크게 바꿀 수 있다. 아무리 완벽한 기획이라도 실제 사용자들의 반응은 예상과 다를 수 있다. 수많은 사용성 테스트와 데이터 분석을 통해 사용자가 원하는 방향으로 서비스는 진화해야 하며, 이것이 바로 초기 기획이 ‘최종’이 될 수 없는 근본적인 이유다.

반면 개발자는 견고한 구조를 만드는 것을 최우선으로 생각한다. 이는 마치 건축물의 골조와 같다. 건물의 외관이나 내부 인테리어는 얼마든지 변경할 수 있지만, 한번 굳어버린 철근 콘크리트 구조는 수정이 거의 불가능하다. 프로그램 개발도 이와 같다. 서비스가 성장하면서 여러 변경사항이 발생하더라도, 핵심이 되는 시스템 구조는 쉽게 바꿀 수 없다. 그래서 개발자들은 초기 설계 단계에서 최대한 많은 변수를 고려하여 확장 가능한 구조를 만들고자 한다. 이는 단순한 고집이 아닌, 기술적 현실에서 비롯된 신중함이다.

비체계적으로 수정된 코드는 여러 면에서 견고한 구조를 가진 코드보다 취약하다. 코드는 한눈에 어떤 기능을 하는지 파악이 되어야 하는데, 처음의 깔끔한 구조에서 설명이 필요한 여러 임시방편적 수정이 발생하면 이해하는 데 그만큼 시간이 더 소요된다. 가독성이 떨어지는 코드는 처음 작성한 개발자는 그 의도를 기억하지만, 담당자가 두 번만 바뀌어도 그 의도를 파악하기 어려워진다.

잦은 변경 요청은 단순한 수정일지라도 개발자에게는 상당한 업무 부담이 된다. 한 줄의 코드 수정이라도 회사마다 정해진 배포 프로세스를 거쳐야 한다. 여기에는 코드 리뷰, 승인 절차, 품질 검증 등 여러 단계가 포함된다. 특히 프로젝트 초기에는 화면 구성이 빈번히 변경되는데, 때로는 여러 차례 수정 끝에 다시 원래 안으로 돌아가는 경우도 있어 개발 리소스의 비효율적 소모가 발생한다.

확장성 있게 구조를 잘 설계한 좋은 사례를 살펴보자. 카카오톡의 선물하기 서비스를 예로 들 수 있다. 초기에는 단순히 모바일 상품권을 주고받는 서비스로 시작했지만, 시장의 반응에 따라 실물 상품 배송, 케이크 예약, 꽃 배달 등으로 확장했다. 이런 확장이 가능했던 것은 초기 설계 단계에서 ‘디지털 상품’이라는 한정된 범위를 넘어 ‘선물’이라는 큰 그림의 서비스 구조를 만들었기 때문이다. 개발팀은 상품의 종류와 배송 방식이 확장될 것을 예상하고, 유연하면서도 견고한 구조를 설계했다.

반면 한 소셜커머스는 초기 설계 시 ‘당일배송’ 서비스만을 고려해 시스템을 구축했다. 그러다 시장 변화로 ‘새벽배송’을 도입해야 했을 때 큰 어려움을 겪었다. 배송 시간대별로 재고 관리 시스템을 완전히 새로 구축해야 했고, 이는 막대한 개발 비용과 시간 낭비로 이어졌다. 초기 설계가 특정 비즈니스 모델에 너무 종속되어 있었던 것이다.

그렇다면 기획 변경이 불가피한 상황에서 우리는 어떻게 대처해야 할까? 먼저, 변경의 크기와 영향도를 정확히 파악해야 한다. 예를 들어 ‘결제 수단 추가’와 ‘결제 프로세스 전체 변경’은 완전히 다른 수준의 변경이다. 전자는 기존 구조 내에서 처리할 수 있지만, 후자는 시스템 전반에 영향을 미친다. 개발팀과 초기 논의 시 예상되는 변경 사항들의 수준을 명확히 구분하여 커뮤니케이션하는 것이 중요하다.

초기 설계 단계에서 기획자가 고려해야 할 기술적 요소들도 있다. 첫째, 데이터 구조의 확장성이다. 예를 들어 사용자 정보를 설계할 때, 현재 필요한 정보만 고려하면 안 된다. 향후 추가될 수 있는 정보들(소셜 로그인, 멤버십 등)을 고려한 구조가 필요하다. 둘째, 서비스의 확장 방향성이다. 현재는 국내 서비스만 하더라도, 향후 해외 진출 가능성이 있다면 다국어 처리나 결제 시스템 등을 미리 고려해야 한다.

성공적인 소통 사례를 보자. 한 이커머스 기업은 새로운 기능 도입 시 ‘단계적 확장 전략’을 활용했다. 먼저 핵심 기능만으로 구성된 MVP(Minimum Viable Product)를 출시하고, 사용자 반응을 보며 점진적으로 기능을 확장했다. 이 과정에서 기획팀은 개발팀과 주간 회의를 통해 기술적 제약사항과 개선 가능성을 지속적으로 논의했다. 결과적으로 큰 구조 변경 없이도 서비스를 성공적으로 발전시킬 수 있었다.

이처럼 기획자와 개발자의 입장 차이는 피할 수 없는 현실이다. 하지만 기획자들은 이를 극복하기 위해 두 가지를 기억해야 한다. 첫째, ‘변경 가능성이 낮은 핵심 요소’와 ‘변경 가능성이 높은 세부 사항’을 구분하여 제시하라. 예를 들어 ‘결제 시스템을 도입한다’는 핵심 요소는 확정하되, 구체적인 결제 수단은 변경 가능성을 열어둘 수 있다. 둘째, 개발팀과 초기에 충분한 대화를 통해 서비스의 확장 가능성과 한계를 명확히 인지하라. 이를 통해 우리는 유연성과 견고성이라는 두 가치를 모두 지킬 수 있을 것이다.