프로덕트 Launching
론칭은 끝이 아닌 새로운 시작
제품 개발 사이클의 마지막 부분은 론칭이라고 많이 말한다. 하지만 론칭은 그동안 고심했던 제품이 드디어 세상에 나가는 것이기 때문에 어느 면에서는 새로운 시작이다. 엄마의 배속에서 10달 동안 자라서 세상에 나오는 아기처럼, 제품도 회사 내부에서 개발 공정을 거쳐서 론칭 시점에 세상에 나온다. 아기를 낳기만 하면 끝나는 것이 아닌, 그때부터 보살펴서 키워야 하는 것처럼 제품도 론칭 후 서비스나 제품을 지속적으로 키워서 안착시켜야 한다. 우리가 사용하고 있는 모든 서비스나 콘텐츠는 이런 과정을 거쳐서 론칭을 통해 사용한다고 할 수 있다.
후속 개발과 프로세스를 정비해야 한다. 제품의 특성에 따라 론칭 이후 많은 이슈들이 발생할 수도 있다. SW의 대규모 업데이트일 경우에는 롤백 시나리오나 긴급패치 및 임시패치에 대해서 염두에 두어야 한다. 자체적인 이슈가 발생하여 롤백하거나 긴급하게 수정해야 할 수도 있고, 갑자기 IDC에 문제가 생길 수도 있고, 클라우드에 문제가 발생할 수도오 있다. 혹은 내부 보안이나 서비스 지역의 방화벽과 문제가 있을 수도 있다. 사실 내부에서만 개발하다가 실서비스로 나가는 첫날이기 때문에 무슨 일이 발생할지 모르기 때문에 만발의 준비를 해야 한다.
HW를 처음 론칭하는 경우에는 포커스가 조금 다를 수 있다. 아직 실서비스에 설치가 되거나 판매가 되지 않은 경우에는 쇼룸이나 전시장, 필드테스트 등 다양한 장소에서 테스트와 홍보를 진행한다. 만약 판매가 이미 되어서 서비스 업데이트하는 경우에는 SW와 웹앱 서비스연동에 대해서 SW와 동일하게 대응한다. 제품이 론칭되면 현장과 많은 커뮤니케이션을 하고, 문제가 발생되지 않도록 대응해야 한다.
론칭 준비를 할 때 유관부서에 릴리즈노트를 발행해야 한다. PM은 커뮤니케이션을 아무리 강조해도 이상하지 않을 정도로 중요하다. CS, 설치, 영업, 마케팅 등등 조금이라도 연관이 있는 담당자들에게 전달하고, 필요에 따라 직접적인 집체교육이나 동영상을 첨부해서 공유한다.
론칭한 이후에는 피드백을 받아서 지속적으로 관리해야 한다. 기능적인 론칭으로 끝나서는 절대 안 된다. 마케팅 및 영업, CS부서를 통해서 론칭된 제품의 고객 피드백에 집중해야 한다. 우리가 의도한 방향과 고객의 방향이 맞는지 체크하고, 방향성이 잘못된 부분은 추적해서 다음 마일스톤에 개선할 부분을 정리한다. 또한 버그나 이슈가 발생한 경우에는 정도에 따라 임시패치나 긴급패치 등급을 판단하여 협의 후 업데이트 일정을 확보한다.
프로덕트를 콘셉트와 상품기획으로 요구사항을 정의하여 시작을 하고, 론칭으로 끝맺음을 한다. 하지만 론칭 이후 들어오는 이슈와 피드백으로 다시 요구사항을 정의하여 다시 시작을 하는 사이클을 반복한다. 경우에 따라 조금씩 다르긴 하지만 SW의 경우 이 주기가 몇 주에서 몇 개월일 수 있고, HW의 경우 몇 개월에서 몇 년이 될 수 있다. 서비스를 셧다운 하지 않는다면 지속적인 업데이트는 존재할 것이라 생각한다.
예전에 구독 멤버십 서비스 론칭을 한 적이 있었다. QA를 통해 검증하였을 때는 특별한 이슈가 없었다. 하지만 막상 론칭을 하고 나서 실서비스에서 문제들이 발생했다. 기존의 서비스와 충돌하면서 문제가 발생했는데, 일반적인 기능적인 문제가 아니고 유료결제에 해당하는 빌링 쪽 이슈가 생겼다. 결제를 했는데, 구독권이 활성화가 잘 안 되는 그런 이슈였고, 결제는 고객과의 신뢰이기 때문에 바로 롤백을 진행했었던 기억이 있다. 그 당시 업데이트 점검을 새벽 2~5시에 진행했는데, 새벽 4시에 롤백을 선조치하고, 아침에 후보고했던 기억이 있었다. 문제가 되는 부분을 수정하여 2주 후에 정상적으로 업데이트했고, 서비스적으로 성공한 프로젝트는 아니었지만 안정적인 론칭을 했던 프로젝트로 기억한다.
*요약
제품 론칭은 끝이 아닌, 사후 대응과 고객 피드백을 통해 요구사항을 끊임없이 고도화하는 반복적인 선순환 과정이다.