1인 개발로 서비스를 출시하면서, 기획자를 이해하게 되었다

서론

지난 한 달 동안 앱을 기획하고 개발해서, 구글 플레이 스토어 출시를 앞두고 있다. 이 과정에서 '기획' 업무를 경험하며 느낀 점을 정리해보려고 한다. (서비스명은 모밋(mommit)으로,  일상을 기록하고 원하는 경우 친구, 가족과 공유할 수 있고, N년전 오늘, 지금 내 위치에서의 지난 기록을 되돌아볼 수 있다.) 

---

본론

세부사항이 누락되었다

현업에서 백엔드 개발자로 일하면서, 기획안이 나오고 나면 종종 이런 생각을 했다.

• 이런 케이스는 왜 기획서에 미리 정의가 안되어있지?

위의 케이스들은 물론 기획 리뷰 또는 슬랙을 통해서 공수 산정 이전에 해결했었다. 지금 와서 생각해보면 부끄럽지만, 당시에는 기획팀의 일을 개발자가 대신 해준다는 느낌으로 생각했던 것 같다.

 

새 서비스를 기획하며

pain point 를 정의하고, 내 서비스가 어떻게 이를 해결할 수 있는지를 정했다. 그 다음으로 요구사항을 정리했다. 이 과정을 진행하면서, 특별히 집중하고 고민했던 것은 구현 상세가 아니었다.

• 무엇을 만들고, 무엇을 만들지 않을 것인가
  • 서비스 이용을 방해하는 멤버를 그룹에서 분리하는 메커니즘이 필요함.
  • 독단적 강퇴는 없음
• 핵심 정책
  • 리더가 강퇴투표를 만들 수 있음 
  • 투표를 만든 리더 제외 멤버의 과반수 동의해야 강퇴됨
  • 투표 만료 시점이 있음
• 이 기능이 서비스의 목표에 부합한가? 이게 사용자에게 가치가 있나?

구현하다 보니

요구사항을 정의하고 나서 백엔드를 구현하다보니 비로소 엣지 케이스가 보이기 시작했다.

• 강퇴 투표중인 멤버가 자발적으로 그룹을 탈퇴하면 투표의 상태는?
• 리더가 권한을 위임하지 않고 그룹을 탈퇴하면 그 이후에는 강퇴투표는 어떻게 진행하지?

깨달은 점은, 이 엣지 케이스들이 구현 단계에서야 보인 것이 잘못이 아니라는 사실이다. 추상 단계에서는 끌어낼 수 없는, 만들어 봐야 비로소 보이는 종류의 디테일이 있다. 기획서를 더 꼼꼼히 적었다고 메워질 빈칸이 아니라, 코드로 구현된 강퇴투표가 눈앞에 있어야 "그럼 투표 도중에 도망가면?"이 떠오르는 종류의 빈칸이다.

---

결론

기획자가 세부사항을 다 잡아오지 못하는 것은 게으름이 아니다. 큰 그림과 핵심 정책에 제한된 리소스를 집중한 결과다. 세부사항은 처음부터 잡을 수 있는 종류의 것이 아니라, 협업으로 채워가는 영역이다. 개발팀은 여러 엣지 케이스를 잡아내서 처리 방안을 리스트업하고, 기획팀은 큰 그림을 지키면서 각 케이스에 대해 이 문제를 풀것인가, 풀지 않을것인가, 푼다면 어떤 정책을 가질 것인가와 같은 결정을 내릴 수 있을 것이다. 실제로 팀 내에서 기획 - 개발간 논의를 업무 프로세스의 한 단계로 자리 잡는 것에 대해 이야기를 나누기도 했었다.

 

논의를 어떻게 진행하면 좋을지 방법론도 가볍게 생각해보았는데, DDD 를 중심으로 해서 아래의 것들이 있을 것 같다. 

• 데이터 모델링 해보기 : 정책의 빈칸은 자연어 기획서에서는 잘 안 보이지만, ERD나 도메인 모델 스케치에서는 시각적으로 드러난다. "리더는 1명이다"가 정책일 때, Group.leaderId의 nullable 여부를 결정해야 할 때 "리더 부재 상태가 가능한가?"라는 질문이 강제된다.
• 유비쿼터스 언어로 같은 모델 공유하기 : 강퇴투표의 엣지 케이스가 빠진 진짜 이유는, "강퇴(kick)"와 "탈퇴(leave)"가 같은 상태 변화인지 다른 사건인지, "리더"가 역할인지 책임인지, 부재가 가능한 개념인지가 도메인 언어로 합의되지 않았기 때문이다.