21 서비스 오픈과 안정화
오픈 이후가 더 중요한 이유
18 QA(Quality Assurance) 회차 이후의 연장 선상에서 작성된 글로 봐주시면 좋겠습니다.
QA까지 잘 마무리되면 드디어 서비스 오픈을 하게 됩니다. 이 오픈도 신규, 리뉴얼, 부분 기능 신규 도입 여부에 따라 프로세스가 좀 달라지는데 신규라는 가정하에 작성해 봅니다.
신규인 경우, 그간 언급한 일련의 기획/디자인/개발/개인정보 영향평가/취약점 보안 진단/QA 과정과 별개로 두어 달 전부터 인프라 장비를 준비해야 합니다. 이는 주로 DB개발팀, 인프라개발팀, 시스템개발팀으로 불려지는 곳에서 DBA나 SE(System Engineer)가 담당하는데 주로 Web/Was 서버, DB storage 서버, DB 종류는 무엇으로 할지(Oracle, MySQL, Clould 등)에 대한 장비 세팅을 견적 받아 구입 및 IDC에 구축해야 하기 때문에 시일이 소요됩니다. 기획자가 직접 하는 부분은 아니지만 비용 지출이 큰 만큼 기획자에게 어느 정도의 볼륨으로 장비를 세팅해야 할지 문의할 때가 있습니다. 기획자는 Best, normal, Worst 세 가지 측면에서 트래픽을 예측해야 하는데 이는 기존에 서비스되고 있는 타 서비스의 트래픽(사용량) 즉, 통계에 근거하여 시뮬레이션 작성 후 공유해 주면 됩니다. 오픈 이후 초 대박이 난 경우 바로 PC 업그레이드하듯, 장비 증설 작업을 하면 되므로 너무 걱정 고민하실 필요는 없습니다. 장비 증설되기 전까지 자주 서비스가 다운되고, 그래서 실검 1위까지 오른 걸 캡처하여 보여준 개발자분이 갑자기 생각나네요. 저는 속이 타들어갔지만 그분은 본인이 개발한 서비스가 실검 1위에 올랐다는 그 사실 자체가 그저 신기하고, 꽤 자랑스러웠던 것 같습니다.
다시 오픈 시점으로 돌아와, 예전엔 서비스 오픈을 밤샘 작업으로 많이 진행했습니다. 미리 티저 홍보를 통해 오픈일을 공지해 두었기 때문이기도 하지만 더 큰 이유는 이 서비스가 타 서비스에도 영향을 끼치다 보니 유저들이 가장 적은 밤 시간대에 전체 서비스를 셧 다운한 상태에서(특히 포털 전면 개편의 경우) 진행하는 경우가 많았습니다. 초대형 프로젝트인 경우 오픈 작업이 원활하지 않고 오픈 예정 시간까지 넘어가면 원복 하는 경우도 발생하게 됩니다. 그 당시 회사에는 '원복'이와 '미정'이 이름을 가진 직원이 가장 많다는 우스갯소리도 있을 정도였지요. 원복이는 원상 복귀, 미정이는 일정 미정을 의미합니다.(정말 옛날 얘기네요)
요즘 App. 의 경우 충분한 테스트를 거쳐 앱스토어 또는 플레이 스토어에서 심사 과정을 거쳐 출시되기 때문에 위와 같은 일은 드물지만 가끔씩은 지금도 주로 금융권 서비스에서 주말 동안 이용 불가(업그레이드 작업으로) 공지를 받게 되곤 합니다.
오픈 시 사전에 '오픈 시나리오'를 작성합니다. 몇 시 몇 분부터 서비스 셧다운 하고, 몇 시 몇 분부터 개발기에서 운영으로 소스 반영하고, 몇 시 몇 분부터 테스트하고, 몇 시 몇 분에 오픈한다 등등의 세부 사항은 주로 개발팀에서 작성하여 진행하게 되며, 이슈 발생 시 기획자(PM)는 이에 대한 의사 결정을 해야 합니다. 무시하고 진행할지, 오픈을 미룰지, 우회적인 방안을 마련하여 제시할지(원활한 진행이 되지 않는 경우엔 집에 있는 상사에게 보고하여 컨펌도 필요했습니다. 상사가 휴가로 일본에 갔을 때 새벽에 연락했던 기억도 나네요 ) 졸리고 피곤한 순간들이지만 참 당연시 여기며 일했습니다. 이후 후폭풍처럼 쏟아지는 반응들과 매출로 보람과 뿌듯함이 더 컸기 때문이었던 것 같습니다.
그리고 지금부터가 가장 중요한 부분입니다. 그렇게 테스트를 많이 하고, 수많은 준비 작업을 거쳐 오픈을 하게 되었음에도 불구하고 꼭 유저들로 인해 여러 버그들을 발견하게 됩니다. 모든 환경(OS, 디바이스, 브라우저, 해상도 등)에서 완벽한 테스트를 하기엔 한계가 있기 때문입니다. 위에서도 언급했듯 생각보다 유저들이 많아 장애가 발생하기도 하고요. 이 서비스가 마음에 드는 유저들은 곧바로 본인의 입맛에 맞는 기능 개선 사항을(물론 성공적으로 론칭한 서비스에 해당하지만) 제시하기도 합니다. 또한 이용 방법에 대한 질문들도 쏟아 냅니다.(그래서 왜 FAQ가 필요한 지는 19 개인정보보호 회차에서 확인하실 수 있습니다) 더불어 상사 또는 임원분들은 신규 서비스 론칭에 대한 반응들(통계, 피드백, 이슈 사항 등)을 매우 궁금해하십니다. 투자를 했으니 당연한 절차이지요. 좀 쉬거나 숨 돌릴 틈도 없이 이에 대한 대응을 해야 하는데 프로젝트를 단독으로 진행한 게 아니라면 분산하여 진행하시면 됩니다. 이 과정에서 제가 제일 중요시 여기는 부분은 유저들의 반응과 개선 요청 사항들로 중복적인 부분일수록 더욱 리스트업 해야 됩니다. 핵심적인 니즈이자, 이 서비스가 더욱 성장하기 위한 발판이기 때문이지요.
그러나 우선은 서비스 안정화입니다. 버그 없이 원활히 서비스를 제공하기 위한 작업이 최우선 순위이며, 그다음 리스트업해 둔 니즈 사항들을(가장 많이 원했던 기능 순서대로) 반영해 가다 보면 서비스는 점점 자리를 잡아, 성공적인 성과를 내는 궤도에 오를 것입니다.
성공적인 기 서비스가 있는 회사에서 신규 서비스 오픈했을 때의 경험담을 바탕으로 작성된 것 같습니다. 서비스를 처음 론칭하는 스타트업 회사의 경험은 없기 때문입니다. 위 일련의 과정들이 얼마만큼 적용되고, 맞아떨어질지는 장담하기 어렵습니다. 다만, 기본이 되는 원칙들은 변함이 없어 보입니다. 바로 '고객의 소리'입니다. 대응할 사람이 없다고 외면하거나, 소홀히 하거나, 늦장 대응을 하면 유저들은 다 떨어져 나간다고 보시면 됩니다. 그간 투자하여 힘들게 애써 만든 서비스인데 말이지요.
유저의, 유저에 의한, 유저들을 위한 서비스를 만드십시오. 유저들이 열광하면 매출은 따라옵니다.
그렇기에 CS가 가장 중요하고, 또 중요합니다.
그래야 경쟁력을 가지고 살아 남아 제2의 네이버, 구글, 페이스북 서비스가 될 수 있다고 생각합니다.
