💬 기능 출시 전, 우리가 챙겨야 할 것은?

배포 전, 우리는 무엇을 정리하고 챙겨야 할까?

첫 배포를 앞두고, 저는 그저 제가 처음부터 끝까지 참여한 프로젝트가 사용자에게 공개된다는 사실에 한껏 고무되어 있었어요. 하지만, 배포가 진행된 뒤 예상하지 못한 이슈가 여럿 터졌고 결국 롤백을 해야 하는 상황까지 이르렀습니다. 문의는 쏟아졌지만, 상황을 구체적으로 아는 사람이 저밖에 없어 나눠 대응을 하지 못했고 롤백 후 어떤 과정을 거쳐야 하는지에 대한 내용도 정리되지 않아 혼란 그 자체의 시간을 보낼 수밖에 없었는데요. 이때 처음으로 배포에 대한 준비를 더 체계적으로 해야겠다는 생각을 하게 되었어요. 오늘은 배포를 하기 전 우리가 함께 챙겨야 할 것들은 무엇인지, 메이커들은 어떤 준비를 하고 있는지 자세히 살펴보고자 합니다.

프로덕트 매니저 H : 기능 가이드 문서를 배포 전 꼭 작성하는 이유

저는 기능 출시를 앞두고 ‘기능 가이드 문서’를 작성하고 있어요. 한 번은 한 달 동안의 준비 과정을 거쳐 새로운 기능을 서비스에 반영, 좋은 반응을 이끌어낼 수 있었는데 운영 담당자가 기능에 대한 문의를 계속 제게 확인하는 일이 있었어요. 처음에는 익숙하지 않은 기능이라 한번 더 확인하는 과정을 거친다고 생각했는데, 이후 세일즈 담당자 역시 고객사 미팅 전 해당 기능에 대해 자세한 설명을 요청하는 것을 보며 무언가 잘못되었다는 생각이 들었죠.

세일즈, 마케팅, 운영(CX) 업무를 하는 담당자들과 이야기를 해보니, 왜 홀로 고민했을 때 답을 찾지 못했는지 그 이유를 명확하게 알 수 있었어요. 기획 문서는 보통 기획자의 언어로 작성된 내용이 많기 때문이었습니다. 왜 만들어야 하는지, 주요 정책은 무엇인지, 어떤 일정에 따라 진행해야 하는지 등 기능을 어떻게, 잘 만들어야 하는지에 초점이 맞춰져 있어 막상 이 기능이 출시된 이후 각 담당자들이 어떻게 반응하고 활용해야 하는지에 대한 관점이 부족했다는 걸 깨닫게 된 순간이었어요.

그래서 영향을 받는 팀원과 이들이 필요로 하는 내용을 중심으로 한 ‘기능 가이드’를 제작하게 되었습니다. 기능 가이드 문서는 (1) 개요 (2) 배포 계획 (3) 기능 안내 (4) FAQ (5) 담당자 (6) 참고 문서 등을 중심으로 작성했어요. 먼저, 개요는 기능에 대한 간략한 소개와 만든 이유에 대해 작성했어요. 이어서 배포 계획에서는 언제, 어떤 시간에, 어떤 방법(점진적 배포 등)으로 진행하는지 정리했습니다.

기능 안내에는 해당 기능을 어떤 화면에서, 어떤 방법으로 활용할 수 있는지 등을 정리했어요. 또 새롭게 추가되는 기능에 대한 정보를 어디에서 어떻게 알릴 것인지에 대해서도 정리했는데요. 예를 들어 상세 화면 진입 시 툴팁을 제공하거나, 자주 묻는 질문에 내용을 추가하거나, 앱스토어 스크린샷과 설명 등의 변경 사항도 포함되었어요. 기능 안내를 따로 작성한 이유는, 사용자에게 기능을 알리기 위한 소스를 쉽게 찾을 수 있도록 돕는 것과 더불어 사용자와 1:1 대화 또는 문의에 대한 답을 진행할 때 어디에서, 어떻게 발생한 문제인지 빠르게 파악하기 위해서였습니다.

FAQ를 가이드에 넣을지는 계속 고민했지만, 어차피 작성은 필요하고 기능 단위로 살펴보는 것이 이 문서의 목적이기에 함께 쓰게 되었어요. FAQ만 따로 보는 것보다 문서에 포함된 다른 내용과 함께 보면 전반적인 흐름을 더 명확하게 파악할 수 있을 거란 판단도 있었습니다. FAQ는 기능을 사용하는 데 있어 발생 가능한 문제를 미리 확인할 수 있다는 측면에서 활용도가 높은 방법이기도 해요. 담당자를 가이드 내 포함하는 것도 필요하다고 생각했는데, 문의 등에 바로 대응할 수 없는 상황이 생겼을 때 참여한 담당자를 빠르게 찾아 연락할 수 있는 용도로 활용할 수 있기 때문입니다. 또 다음 기능을 개발하는 데 있어 담당자가 변경되거나 빠졌을 경우 영향을 받는 내용을 확인하기 위한 목적으로도 중요한 역할을 할 수 있어요.

마지막으로 참고 문서는 필요에 의해 추가로 확인하면 좋은 내용을 정리하기 위해 생성했어요. 실제 화면에 적용된(최종) 디자인 시안을 볼 수 있는 링크, 기능 개발 전 작성한 스펙 문서, 자주 묻는 질문을 전체 확인할 수 있는 링크 등이 포함되며, 이후 마케팅팀에서 작성한 콘텐츠 등도 추가했습니다.

💡 메이커의 꿀팁

기능 출시 전 준비사항이 궁금할 때 읽어보면 좋은 글

‘기능 가이드’에 대한 내용은 위 글을 바탕으로 메이커가 전해준 이야기입니다. 기능 가이드의 작성 방법과 필요성에 대한 내용도 좋았지만 무엇보다 장점에 대한 내용이 가장 인상 깊었어요. “기능 가이드 문서를 제작하고, 공유하고, 활용하면서 느낀 가장 큰 장점은 우리 각자가 기능 출시를 어떻게 받아들여야 하는지 생각해볼 수 있는 기준이 생겼다는 점이에요. 기존에는 ‘개발 과정' 자체에 집중했다면, 이제는 개발 전, 후의 상황을 함께 고려할 수 있는 관점을 갖게 되었다는 점 역시 좋았습니다. 현재는 스펙 문서를 출발점으로, 가이드 문서를 마무리로 생각하며 각 단계에 포함해 활용하고 있으며 기능 단위로 계속 살펴볼 수 있는 중요한 문서 역할을 해주고 있어요. 이 문서는 업무 매뉴얼과 사용자에게 안내할 ‘업데이트 노트'를 작성하는데도 많은 도움을 주고 있어요.”

프로덕트 매니저 A : 배포 이후에 우리가 챙겨야할 것들 정리하기

제가 현재 일하고 있는 스타트업에 와서 가장 먼저 확인한 건, 업무 방식이었어요. 제가 해야 할 업무는 물론이고, 제가 하는 업무로 인해 영향을 받는 업무와 담당자를 빠르게 확인하기 위해서였죠. 기능 배포를 기준으로 처음과 끝은 무엇인지 도식화하고, 기존 업무에서 불편했던 점을 파악해 개선점으로 정리하는 것도 잊지 않았는데요. 이 과정에서 저는 ‘배포’를 중요한 기점으로 생각했어요. 보통 배포를 업무의 끝으로 따지는 경우가 많은데, 배포와 동시에 이슈가 발생하게 되고 사용자의 반응 등도 그때 하나씩 살펴볼 수 있기 때문이에요.

우리가 의도한 대로 반응이 일어나는지, 예상치 못한 이슈는 없는지, 검증 기준에 따른 데이터는 어떤지 등 배포 후 우리가 실제로 확인해야 할 내용이 많은데요. 배포 전 단계보다 체계적으로 관리되지 않는 상황에서 저는 개발에 참여한 전체 멤버들과 함께 체크리스트를 만들어보기로 했어요. 체크리스트가 잘 구성된다면, 그리고 업무 과정에 늘 포함될 수 있다면 배포 전 고민한 내용을 더 치열하게 검증하고 확인할 수 있는 기회로 활용할 수 있지 않을까?라는 생각이 들었습니다.

체크리스트는 결국, 배포 후 우리가 꼭 챙겨야 할 것과 같기에 작성 시기는 스펙 문서 그리고 기능에 대한 사용자 시나리오와 정책을 작성한 이후로 결정했는데요. 스펙 문서를 통해서는 우리가 달성해야 할 목표, 검증 기준으로 삼을 지표 등을 참고했고 데이터를 어디에서 어떤 식으로 확인할 것인지를 덧붙였어요. 사용자 시나리오와 정책을 통해서는 배포 후 기능 만족도에 대한 설문, 이슈 발생 시 대응 방법, 사용자 문의 관리 등에 대한 내용을 확인 후 정리했습니다.

백로그에서 배포 예정인 기능과 관련된 내용을 확인, 체크리스트에 포함시키는 것도 잊지 않았어요. 우선순위를 아직 정하지 않은 상태라 하더라도 연관된 기능이거나, 기능에 대한 개선 내용이라면 배포 후 함께 확인하는 시간이 필요하다고 생각했기 때문이에요. 백로그를 잘 관리하고 있다 하더라도 등록된 내용이 많을 경우 따로 시간을 내 정리하거나 논의 시 끄집어내야 하는데 배포 후 한 번씩 확인하는 과정을 거치면 관리가 더 쉬워질 거란 생각도 있었죠.

체크리스트는 팀 내 사용하는 문서 관리 툴에 맞춰 정리했고, 배포 전 다 같이 확인하는 시간을 꼭 가졌어요. 놓친 내용이 없는지 확인하는 것은 물론, 배포 후 구체적인 업무 시간과 담당자를 할당해 꾸준히 확인하고 관리하는 행동으로 이어가기 위함이었어요. 이렇게 만들고 확인한 체크리스트는 기능 단위 회고 때에도 유용하게 활용될 수 있었고, 다음 배포를 준비하면서도 이전 배포에 대한 모니터링을 조금 더 효율적으로 하는데 많은 도움을 주고 있어요.

💡 메이커의 꿀팁

배포의 중요성을 확인하고자 할 때 읽어보면 좋은 글

제목이 메이커 코멘트와 많이 닮아 더 집중해서 읽은 글이에요. 이 글에서는 ‘기능에 대한 배포를 진행했는데 생각보다 반응이 좋지 않은 경우’에 대해 다루고 있는데요. 배포 후 반응이 좋지 않아 기능에 대한 사용이 저조한 이유를 분석하고 분석에 따라 어떻게 개선하면 좋을지 정리했다고 해요. 이런 과정에서 기능에 대한 지표는 매일 확인하는 것으로 기준을 잡는 등, 메이커가 위에서 언급한 ‘체크리스트’와 함께 활용한다면 개선까지 연결되는 중요한 단계이자 방법으로 활용할 수 있지 않을까 하는 생각이 드네요!

프로덕트 오너 K : 배포 효과를 극대화하기 위한 시점 찾아보기

기능을 출시하기 전에는 백로그에 대한 대비, 배포 노트, 배포 후 살펴볼 지표 등등 준비할 게 참 많습니다. 그런데 이러한 준비는 대부분 기능 배포를 대응하기 위한 부분인데요. 큰 맥락에서의 준비도 필요합니다. 그중에서도 프로덕트 오너의 입장에서는 우리가 열심히 준비 중인 이 기능을 언제 배포해야 영향이 극대화되는지 플랜을 세우는 것도 굉장히 중요합니다.

인력 투자 관점에서도 출시 속도가 5% 정도 빠르게 개선되면 ROI(투자 대비 수익률, Return on Investment)는 무려 13% 증가한다는 논문 결과도 있는데요. 물론 제가 말하고자 하는 시점은 이런 투자 관점은 아니고, 서비스 사용자관점에서의 효과에 초점을 맞추려 합니다. 사용자 관점에서 새로운 산업군의 서비스를 배포할 때는 출시시기에 따라 성공여부가 결정되는 사례를 우리는 이미 많이 겪고 있는데요.

대표적인 사례로 코로나 시기 음성 SNS로 글로벌적인 사랑을 받은 클럽하우스가 있습니다. 클럽하우스는 환경적 시점을 고려해 코로나로 일상이 단절된 시점에 배포되며, 극적인 사랑을 받았죠. 반면 동일한 기능과 개념을 내포한 카카오에서 출시한 음은 코로나 시기에 빠르게 개발되었으나, 클럽하우스만큼의 사랑을 받지 못한 채 서비스 종료가 되었습니다. 이는 분명 환경적 출시 시점의 영향이 크다고 볼 수 있어요. 음이 발표된 시기는 코로나 규제가 완화되던 시기이고, 클럽하우스를 통한 음성형 SNS의 경험을 모두 마친 시점이라 사용자들의 큰 흥미를 끌기 어려웠던 시기죠. 이처럼 우리가 배포하는 작은 기능도 사용자들의 생애주기와 주변 트렌드, 환경 요인을 충분히 고민하고 시점을 잡아야 합니다.

그래서 저희 팀의 경우, CS를 통해 기능 개선을 하는 내용은 동일한 CS가 발생하는 주기가 돌아오는 바로 전주에 배포를 진행합니다. 예를 들어, 한 달에 한번 상품 판매자에게 정산을 진행하는데 정산에 대한 불편사항을 개선하는 기능은 정산이 이뤄지는 매달 마지막 주 금요일의 2일 전인 수요일에 배포하는 거죠. 그 뒤 목요일은 배포 노트를 판매자 알림 및 이메일을 통해 알리고 금요일에 판매자가 개선된 기능을 바로 사용할 수 있도록 제공합니다. 그리고 마지막에는 기능 만족도 조사를 슬며시 끼워 넣죠. 이렇게 하면 사용자의 만족도가 높아질 가능성이 높고, 팀이 충분히 서비스를 관리하고 있다는 인식이 생겨 충성도가 함께 올라가는 경험을 하고 있습니다. 이렇듯 우리의 업무 환경과 사용자의 충성도를 위해서라도 사소한 기능도 언제 배포하면 효과가 극대화되는지 습관적으로 고민하는 것을 추천드립니다.

💡 메이커의 꿀팁

배포 효과를 극대화한 사례를 이해하기 좋은 글

이번 메이커가 소개한 사례인 클럽하우스의 성공 사례에 대해 자세하게 분석한 ‘클럽하우스 : 인기가 많았던 이유와 차별점’ 글을 함께 읽어보시길 추천드립니다. 클럽하우스가 다른 서비스와 비교했을 때 차별점을 견고하게 설정하여 큰 성공을 이룬 사례는 참 흥미로웠어요. 그리고 그 과정에 배포 시기가 배포를 준비하는 단계에 정해져야하는 부분이란 것을 쉽게 잊을 수 있는데, 메이커님의 꿀팁을 통해 새삼 중요함을 느꼈습니다.

그리고 출시 속도가 ROI 증가에 영향을 미친다는 논문의 결과는 ‘지속 가능성에 대한 2가지 관점’ 글을 함께 읽어보시면 좋겠습니다. 이 글은 몇몇 논문을 근거로 단순 개발을 지향하는 것이 아닌 지속적으로 개선해 나갈 수 있는 개발 구조에 집중해야한다는 내용입니다. 발췌된 논문은 영문으로 글로벌 통계가 포함되어있는데, 다양한 프로젝트에 대한 통계를 함께 가볍게 살펴보시길 추천드립니다.

서비스 기획자 B : QA 담당자가 없는 작은 팀에서 배포를 위한 기능 테스트를 진행해야 하는 이유

기능 출시 전에 빠질 수 없는 과정이 테스트죠. 저는 첫 회사에서 규모가 있는 QA팀과 함께 손발을 맞춰 일을 하다가 관련 조직이 없는 작은 회사로 옮기면서 기능 테스트 과정을 직접 도입하게 됐습니다. 제가 처음 왔을 때를 생각해 보면 개발팀에서 기능을 개발한 뒤 자체적으로 테스트를 거친 뒤 배포를 했었는데요, 단순히 기능이 작동되는지 판단하는 테스트에 그치는 경우가 많았고 그마저도 문서화가 되어있지 않아 체계적인 관리가 필요하다고 판단했습니다. 지금은 기획 의도에 맞는 테스트를 수행하기 위해서 기획팀이 테스트를 주도하고 있고, 테스트는 기획팀과 디자인팀과 개발팀 중 일부 팀원들이 모여서 같이 수행하고 있습니다.

저희가 어떻게 테스트를 하고 있는지 간단하게 소개해 드릴게요. 먼저 기획팀에서 이번 업데이트에 포함되는 기능을 다시 한번 확인하고, 중점적으로 테스트해야 할 부분을 결정합니다. 그리고 테스트 일정과 테스트 케이스를 공지합니다. 이때 테스트 케이스 문서를 작성해서 공유하는데요. 해당 문서에는 화면명과 테스트 내용, 테스트 예상 결과를 적어주고 테스트 통과/실패 여부와 버그 내용에 대해 작성하는 공간이 들어갑니다. 처음에는 문서에 간단히 테스트해야 하는 내용만 적어서 공유했는데, 팀원들이 테스트 결과를 각자 다른 방식으로 공유해 불편했던 경험이 있습니다. 그래서 다음부터는 테스트 결과를 적는 공통 양식을 팀에 미리 공유하고 있습니다.

테스트 당일, 수집한 버그 내용을 정리해서 개발팀에 전달합니다. 이때 개발팀과 논의하여 버그 우선순위를 함께 설정하고, 해결 상태를 모니터링하는 문서를 만들어서 공유합니다. 빠른 시일 내에 해결되는 마이너 한 버그가 대부분이지만, 해결하는데 긴 시간이 걸리는 버그가 발생할 경우 배포일이 미뤄지는 일이 발생하기도 합니다. 그래서 테스트는 배포일 직전에 하지 않고 시간적 여유를 가지고 일정을 잡고 있습니다. 버그가 다 고쳐지고 나면 최종 테스트를 한 번 더 진행하고 배포를 진행합니다. 이런 테스트 진행 과정은 배포 후 발생 가능한 이슈를 미리 확인하고, 사용자의 입장에서 최종적으로 서비스를 사용하며 느끼는 불편 역시 함께 확인할 수 있다는 장점이 있다고 생각해요.

💡 메이커의 꿀팁

테스트 보다 효율적으로 하고 싶을 때 읽으면 좋은 글

이번 코멘트를 읽으면서 우리 팀에도 테스트 케이스 도입이 필요해! 근데 어떻게 하지?라고 외치는 메이커님, ‘아기자기한 프로덕트 팀의 Test Case 도입기’라는 글을 참고해 보세요. 실제 예시와 함께 테스트 케이스를 작성하는 방법과 주의사항이 나와 있어요. 에디터는 이 글을 읽으면서 신입 시절이 떠올랐는데요. 예외 플로우 작성을 자주 깜빡하는 바람에 QA팀에 자주 호출됐던 기억이 났어요. 테스트 시 데이터 측정을 할 수 있게 준비하는 작업과 시나리오를 확인하는 것도 좋은 팁이네요!

테스트 케이스에 대한 재미있는 글을 찾다가, 데브시스터즈 팀의 ‘테스트 케이스’로만 테스트하면 안 되나요?’를 발견했어요. 이 글에서 버그는 확률적으로 테스트 케이스 바깥에서 생겨나는 경우가 더 많다고 언급하고 있어요. 그러면서 탐색적 테스팅(Exploratory Testing)에 대해 소개하고 있는데요. 쉽게 말하자면 ‘미운 4살’처럼 기획 의도와 반대되는 행동을 하면서 버그를 찾아내는 방법이래요. 그 외에도 트롤링, 페르소나 등의 방법에 대해 소개하고 있는데요. 테스트 환경이 훨씬 복잡한 게임 QA와 일반 제품의 QA가 똑같을 순 없지만 일부 방법은 참고하기 좋은 것 같아요.

💬 이번 뉴스레터는 어땠나요?

이번 커피챗 소식은 어땠나요? 뉴스레터에 대한 의견을 더해주세요! 

의견 등록하기

기능을 배포한 뒤, 우리가 의도한 대로 사용자가 쓰고 있을까?라는 생각을 자주 하게 되는데요. 이럴 때, 사용자 만족도나 기능에 대한 사용성을 어떻게 확인할 수 있는지 다음 뉴스레터에서 자세히 살펴볼 예정입니다. 다음 뉴스레터는 10월 5일 목요일 오전 8시에 발행될 예정입니다.

팁스터 뉴스레터의 공식 오픈채팅방에 참여해보세요!

팁스터 뉴스레터에서는 프로덕트와 관련된 다양한 주제의 콘텐츠를 발행하고 있어요!

멤버십 콘텐츠 중 '캠핑'편은 무료로 체험하실 수 있어요!