어려웠던 점
관련 업무를 모르다보니 처음에는 내 문서함과 관련이 있는 서비스 A, 전반적으로 사용되는 공통 서비스 B 정도만 수정하면 된다고 생각했습니다. 하지만 업무를 알아가는 과정에서 웹뷰(WebView) 프론트엔드 서비스 C 도 작업을 해야 한다는 사실을 깨닫게 되었습니다. 해당 웹뷰 서비스는 Backbone 으로 구현되어 있어 이를 또 학습하고 알아가는 과정이 매우 챌린징했습니다.
도전해보고자 했던 점
당시 PM(Project Manager)이 없는 상황이었기 때문에, 주도적으로 일정 및 프로젝트 리딩을 관리해보고자 했습니다.
초기에 총 7개의 수신 상품에 해당 기능을 적용하는 업무가 기획되었지만, 이는 다소 리스크가 있다고 판단했습니다. 배포 시 7개의 수신 상품 중 일부가 가입이 안될 수 있는 치명적인 버그가 포함될 수 있고, 제가 아직 해당 도메인의 업무 히스토리를 잘 모르는 상태에서 7개 전체를 한 번에 안전하게 작업할 수 있을지 예측하기 어려웠기 때문입니다.
그래서 7개 중 구현하기 가장 어렵고 까다로운 1개를 우선적으로 선정하여 진행해보고자 의사결정을 제안했고, 동료들과 협의하여 그렇게 진행되었습니다. 돌이켜보면 이 부분이 프로젝트를 안정적이고 성공적으로 이끄는 데 가장 중요한 결정 중 하나가 아니었나 생각합니다.
효과적인 커뮤니케이션
기획 요구사항을 구현하기 위해서는 Backbone 으로 웹뷰 화면을 구성했어야 했습니다. 하지만 팀 내 다양한 방법에 대해 논의하고 고민해 보아도, 이를 Backbone 상에서 현실적으로 구현하기가 매우 까다로울 것 같았습니다.
그래서 관련된 클라이언트 개발자분들과 적극적으로 커뮤니케이션하여 Backbone 웹뷰 화면 대신 Native 로 구현하는 방향으로 새롭게 합의를 이루어 냈습니다. 그 결과 사용자 경험 측면에서도 훨씬 자연스러운 흐름이 만들어졌고 개발도 성공적으로 마무리되었습니다.
해당 서비스 개발 후 효과
이러한 개발 과정을 거쳐 프로젝트가 성공적으로 배포되었고, 내 문서함 서비스 가입자가 무려 하루 평균 100배 증가하는 눈부신 성과를 이루어냈습니다.
- 마케팅과 홍보 이벤트를 제외하면 하루 평균 100~200명 수준이었으나,
- 별도의 마케팅과 홍보 없이도 10,000명 평균 달성이라는 놀라운 지표를 보여주었습니다.