#서비스기획 - 기획자가 개발자와 잘 소통하는 법
"이건 데이터를 저장하고 있지 않아요"라는 말 뒤에 숨은 신호 읽기
서비스기획자로 일하면서 개발자와 매일 협업한다.
하지만 언제나 부딪히는 포인트가 있다.
개발자의 피드백이 때론 벽처럼 느껴지는 그 순간들.
"기획 내부에서 먼저 확인해보세요"
"이건 데이터를 저장하고 있지 않아요"
"그건 케이스 정리가 필요해요"
"지금 구조에선 무리가 있어요"
이 말들은 단순한 '거절'로 받아들이기보다,
'기획자가 더 성장할 수 있는 시그널'로 해석하면 완전히 다른 결과가 나온다.
🤔 기획 내부에서 확인해보세요
기획자는 정보의 허브가 되어야 한다.
개발자는 '왜 이 기능이 지금 나오고 있는지'를 과거 버전까지 거슬러가며 파악하기 어렵다.
그래서 기획자가 과거 이력과 현재 변경점을 명확하게 가져가는게 좋다.
✅ 실무 대응법
- 기능 히스토리 노션/피그마에 정리
- "이 기능은 3월 배포 때 v2가 되었고, 이번은 v3 변경입니다"
- 기획자는 '내가 만든 것'만이 아니라, 서비스 전체 흐름을 맥을 잡고 있어야 한다.
🤔 이건 데이터를 저장하고 있지 않아요
당연히 저장되고 있을 거라는 착각을 주의해야 한다.
개발자는 기획자가 어떤 데이터를 분석할 건지 명확히 요청하지 않으면, 절대 알아서 저장하지 않는다.
특히 '전환율', '클릭 로그', '이탈 타이밍' 같은 행동 기반 데이터는 설계 요청이 선행돼야 저장이 가능하다.
✅ 실무 대응법
- 어떤 데이터를 저장해야 하는지 명확히 정의
- ex. "배너 클릭수 vs 상세 페이지 진입 수 vs 최종 구매 전환율까지 트래킹 필요"
- 데이터 목적까지 설명
- "다음 기획 개선 시 전환율 기반으로 A/B 테스트 할 예정"
🤔 이런 케이스는 어떻게 처리해요?
예외 상황을 다루는게 진짜 기획자의 일이다.
개발자는 항상 예외를 먼저 본다.
기획자는 '정상 시나리오'를 만들지만, 개발자는 '비정상 상황'에 대한 대비부터 물어본다.
✅ 실무 대응법
- '정상 흐름' + '예외 케이스'를 함께 문서화
- 모든 조건에 '예외 상황 발생 시 처리 방안' 포함 (ex. 쿠폰 만료, 중복 요청, 네트워크 실패 등)
- "A -> B -> C" 흐름이 안 될 경우, C 대신 어떤 화면/메시지를 띄울 것인가? 항상 준비
🤔 지금 구조에선 무리가 있어요
구조 변경은 시간과 비용의 문제, 협업의 여지로 보자
기획자는 기능 중심, 개발자는 구조 중심.
기획이 단순해 보여도, 구조적으로 손대야 하는 범위가 크면 '개선'보다 '리팩터링(*)'이 먼저라는 판단이 나올 수 있다.
✅ 실무 대응법
- 무리라고 들었을 때 '왜 무리한가'를 기술적 관점에서 이해하려는 태도가 중요
- 가능한 대안 논의 : "이 구조를 유지하면서도 가능한 다른 방식이 있을까요?"
- '필요 기능'과 '개발 난이도'를 함께 저울질해야 진짜 우선순위 판단이 가능
📌기획자의 마인드셋
"정답을 요구하기보다, 함께 답을 만들어가는 사람"
개발자와 소통은 언제나 '지시'가 아닌 '협의'의 형태가 되어야 한다.
- 내가 먼저 전체 구조를 이해하려는 태도
- 예외 상황을 나부터 정의하려는 책임
- 데이터 목적을 미리 말할 줄 아는 명확함
- 그리고, 내가 만든 기획서의 부족함을 나부터 인정하는 유연함
또한, 데이터 기반 사고방식을 갖되 유연한 업무처리 능력을 겸비해야한다.
작은 것도 정량화 할 줄 알아야 한다. VOC, 경쟁사 벤치마킹 등을 통해서.
빠르고 정확하게 해야하는 일이 많기 때문에 적극적이면서도 능동적으로 일을 할 줄 알아야 한다.
무엇보다 서비스기획자는 사용자 대변인으로서 내부 이해관계자(운영, 마케팅, 디자이너, 개발자 등)을 설득해야한다.
그렇기 때문에 사람에 대한 이해와 호기심도 있어야 한다.
* 리팩터링(refactoring)
기능은 그대로 두고, 내부 구조(코드)를 더 깔끔하고 효율적으로 바꾸는 작업
- 사용자 입장에서는 '변화 없음'
- 개발자 입장에서는 '더 유지보수하기 쉬운 코드로 개선'
기획자 입장에서는 이전 동작으로 수정하면 된다고 생각할 수 있지만,
개발자 입장에서는 코드가 얽혀 있어 수정하려면 다른 기능에 영향을 미칠 수 있다고 판단.
이때 하는 작업이 리팩터링.
개발자의 리팩터링 신호
- "지금 구조에선 무리가 있어요" -> 구조가 비효율적임
- "이거 수정하려면 다른 기능도 영향을 받아요" -> 코드가 얽혀 있음
- "옛날 코드라 건드리기 무서워요" -> 기술 부채 상태
- "이참에 좀 구조 정리할게요" -> 리팩터링 작업 예정
때때로 커뮤니케이션 오류와 인내심 한계로 인해 폭발할 때가 있다.
우리는 성인이기 때문에 참을 줄 알아야 한다. 화를 낸다고 해서 상황이 해결되지 않는다.
이성적인 판단으로 효율적인 의사결정 방식을 가져갈 수 있도록 정리할 줄 알아야 한다.
대체로 책임지지 않는다. 결과는 기획자가 대체로 책임진다.
책임진다는 표현이 다소 과격(?)하게 표현되었지만. 결과물은 기획자의 탓이되곤 한다.
기획하고 배포하는 모든 과정 중에 쉬운 것은 없다. 가장 힘든 부분은 중요도와 일정인 듯 하다.
내가 추진한 것으로 인해 회사의 리소스가 투입된다. 나로 인해 일이 만들어지고 다른 이가 일을 하게 된다.
기획서를 작성하는 것도 중요하지만, 일을 진행하면서 커뮤니케이션이 훨씬 더 중요해진다.
다 같이 먹고 살자고 하는 일인데, 서로 조금씩 배려하면서 살자.