북팔 새 옷 입다
북팔 시즌4 오픈 기록
웹소설 회사에 입사한 지 꼭 2년이 되었다. 처음 6개월은 이것저것 레거시 시스템만 손대다가, 본격적으로 북팔의 메인 서비스인 웹소설 서비스 개발에 투입된 것은 입사 7개월 차, 지금으로부터 1년 반 정도 된다. 그 1년 반 동안 2차례의 대규모 업데이트(라고 쓰고 재개발이라고 읽는다), 크고 작은 기능 추가 등을 진행했다. 이 글에서는 얼마 전 진행했던 3번째 대규모 업데이트(라고 쓰고 재개발이라고 읽는다)에 대한 기록을 남겨 두려고 한다.
이 글은 북팔 개발팀의 개발자가 개발자 입장에서 작성한 글이지만, 가급적 기술적인 내용은 배제하고, 북팔 웹소설 서비스의 짧은 역사를 정리해 보려고 한다. 따라서 이 글의 대상은 북팔 직원일 수도 있고, 북팔을 이용하는 작가님, 독자님이 될 수도 있겠다. 제한적으로나마 북팔 웹소설 서비스를 사랑하시는 분들에게 공감이 되었으면 한다.
현재 북팔 웹소설 서비스의 트래픽은 평소에는 월간 UV 30만 정도이고, 마케팅이 걸리면 약 30~40% 정도 증가한다. 특이하게도, UV 대비 PV가 높고, 세션당 평균시간이 30분에 육박한다. 하드코어 유져가 많다는 이야기이다. 이러한 유저의 이용 형태는 특정시간대에 트래픽이 집중되고, 그만큼 서버에 부하가 순간적으로 몰리는 경우가 많다.
북팔 웹소설 앱은 수익모델이 검증되기도 전에, 소수의 기획자/개발자들이 다양한 실험을 하면서 성장해온 서비스여서, 기술적인 완결성보다는, "일단 만들고 보자" 분위기가 강했고, 그 때문에 소스의 복잡도가 높고 비효율적인 코드가 많다.
초기 북팔 서비스는 게시판에 편당 과금을 붙여놓은 형태인 탓에 일반 공개형 CMS가 가지고 있는 문제점을 고스란히 가지고 있었다. 로직과 뷰가 뒤섞여 있다던지, 화면에 필요 없는 데이터를 불러오거나, 테이블 간에 관계가 설정되어 있지 않아 데이터들의 정합성도 맞지 않았고, 툭하면 서버에 행이 걸려 멈추곤 했다.
_북팔 시즌2
북팔의 첫 번째 대규모 업데이트의 개발은 2015년 8월부터 10월까지 3개월간 진행했는데, DB 구조는 그대로 두면서 기존의 소스를 모두 걷어내고 새로 개발했다. "북팔 시즌2"로 명명된 이 프로젝트를 위해, 사내의 개발자들을 모두 긁어모아 개발자 4명 퍼블리셔 1명의 팀을 만들었는데, 이 팀이 지금의 북팔 개발팀이다. 새로 만들어진 개발팀에 떨어진 "북팔 시즌2"의 임무는 "UX 개선과 디자인 개편"이 주된 내용이었는데, 우리 개발자들은 뷰와 로직이 뒤섞여 있는 소스를 망연히 바라보다 "그냥 다시 만들자"라는 결론을 내고 "개편"이 아닌 "재개발"로 결국 3개월 만에 오픈을 하게 되었다.
서비스의 구조를 홈페이지 개념의 웹페이지 단위에서, 앱 개념의 모듈단위로 재개발하고 필요한 라이브러리만 선택적으로 로드하는 식으로 공통 라이브러리를 다시 만들었다. 트래픽이 집중되는 페이지는 데이터만 캐싱해서 데이터베이스를 경유하는 횟수를 줄이고, 라우팅/fb graph 개념도 도입해서 나름대로 SEO도 신경 써서 설계했다. 이 업데이트에서 아이폰 앱을 신규로 론칭했다.
다 만들고 오픈을 하고 나서야 우리는 문제점 하나를 깨닫게 되었는데, 그것은 바로 "3개월"이라는 기간에 문제가 있었다. 급조된 개발팀이 업무 분석할 시간도 없이 3개월 동안 할 수 있는 것은 고작 "UX와 디자인이 개선되어 보기 좋은, 그러나 로직과 뷰는 여전히 뒤섞인" 앱을 만드는 것일 뿐이었다.
_북팔 시즌2.5(판타지), 북팔 시즌3(BL, 북팔 팩토리)
개발팀의 2번째 임무는 "로맨스는 북팔"이라는 슬로건을 "판타지도 북팔"로 바꾸는 것이었다. 2015년 11월부터 2016년 1월까지 3개월간 진행되었는데, "북팔의 큰 업데이트는 3개월 만에 해치우는 것"이라는 징크스가 이때부터 생겨나지 않았나 싶다. 그래도 "시즌2"에서 어느 정도 확장성을 고려해서 설계를 잡아 놓은 덕에, 비교적 수월하게 적용이 가능했다. 이제 개발팀이 관리해야 하는 앱이 2개에서 5개(응?)로 늘어났다.
북팔 판타지앱의 핵심 서비스 - 골드카드관판타지 앱의 성공적인 론칭 후에 작가님들께서 편하게 작품을 등록하기 위한 전용 서비스인 "북팔 팩토리" 개발을 시작했다. 이쯤 되면 눈치챘겠지만, 이번에도 개발기간은 3개월이었다.
"북팔 팩토리"의 모토는 "작가님들께서 누워서도 글을 쓰실 수 있도록 만들자"이다. 이 프로젝트는 "시즌3"으로 명명되었고, 모든 기능과 화면은 반응형 웹으로 구현했다. 이 프로젝트로 인해 북팔 작가님들은 작품 관리, 수익 내역 확인, 이벤트 신청, 타 플랫폼 전자책 출간 등을 하나의 시스템에서 관리하실 수 있게 되었고, 북팔에서 CP의 콘텐츠를 볼 수 있게 되었다. 다만, 아쉽게도 아직 작가님들이 누워서도 글을 쓰실 수 있는 수준은 아니다. ㅠ.ㅠ
작가님 전용서비스 "북팔 팩토리"북팔 웹소설 서비스는 위에 언급한 시스템/서비스들 이외에도 BL(Boys Love) 전용 앱, 정산시스템, 서비스 관리시스템, 출간 예약시스템 등 하나의 서비스를 운용하기 위한 무수한 레거시 시스템이 존재한다. 현재 북팔 개발팀에는 SE 1명, 안드로이드 앱 개발자 1명, 아이폰 앱 개발자 1명, 웹 프런트/서버 개발자 6명, 퍼블리셔 2명이 이 모든 서비스를 끌어가고 있다.
여담이지만, 북팔은 기획/운영에 강한 회사로 봐도 무방할 것 같다. 작가님들께서 직접 작품을 올리고, 독자님들께서 작품을 선택하는 오픈마켓과 비슷한 BM덕에 지속적으로 서비스를 관리하지 않으면, 서비스가 정체된 것처럼 보이기 쉽다. 또한, 대부분의 작가님/독자님들께서 여성이기 때문에 예쁜 디자인에 대한 니즈가 강하다. 때문에, 기획팀/운영팀/디자인팀이 별도로 운영되고 있으며, 위에서 언급한 서비스들은 "기획-> 디자인 -> 개발 -> 운영"의 순서대로 각자의 명확한 책임하에 긴밀한 협업으로 만들어진다.
이런 명확한 분업 시스템은 개발자 입장으로서는 당황스러울 때가 많다. 일단 협업을 어려워하는 개발자 특성을 제쳐두고서라도, 어느 부분에서 의견을 내야 할지, 어느 단계에서 문제제기를 해야 할지 타이밍 잡기가 어렵기 때문이다. 하지만 일단 북팔의 협업 시스템에 적응하게 되면, 개발자는 로직 개발에만 집중할 수 있게 만드는 장점이 있어 필자의 경험상 개발자에게는 훌륭한 작업 환경인 것은 틀림없다.
_북팔 시즌4
아는 분들은 아시겠지만, "북팔 웹소설 앱"은 "하이브리드 앱"이다. 서비스가 앱으로 제공되지만 앱 안에는 브라우저가 내장되어 있고, 그 브라우저에 "모바일 웹"이 보이는 형태이다. "하이브리드 앱"은 장단점이 명확해서 "네이티브 앱"보다 좋다/나쁘다를 판단하기는 쉽지 않다. 앱을 재 배포하지 않고도 화면이나 내부 로직을 수정해서 발 빠르게 고객의 요구를 반영할 수 있는 것은 앱을 서비스하는 기업 입장에서는 "하이브리드 앱"의 최대 장점이다. 하지만 이용자의 입장에서는 네이티브 앱보다 상대적으로 느린 속도, 많은 데이터 사용량, 불편한 사용자 경험 등에서 이용에 장애가 될 수 있다.
"북팔 시즌4"로 명명된 3번째 대규모 업데이트에서는 "속도, 사용자 경험"을 목표로 잡았다. "하이브리드 앱"은 브라우저에서 HTML과 JavaScript로 UX를 구현해야 하기 때문에, "네이티브 앱"의 동작성을 흉내 낼 수는 있어도, 그 부드러운 반응성은 따라 하기 힘들다. "하이브리드 앱"을 "네이티브 앱"으로 전환하는 데에는 커다란 산이 존재하는데, 바로 "API"다. 앱과 데이터베이스를 연결해 주는 것이 API인데, 결국 기존 개발 코드는 참고만 하고, 코드 자체를 새로 작성해야 한다. 또한, 콘텐츠 서비스 특성상 API 보안체계도 구현해야 한다.
"이쯤 되면 막가자는 거다. 막가자! 이번에도 3개월이죠?"
https://www.youtube.com/watch?v=CIrGcPFgGIkAPI를 새로 만들고, 앱도 새로 만들고, API 만든 김에 API를 활용해서 웹도 다시 만들기로 했다. 다행히 이번에는 5개월을 확보했다. 대신, 멋진 UX를 위해서 디자인 2개월. 그럼 개발은 3개월. 이상한 일정이긴 했지만, 해보는 거다.
파란 영역이 재 개발 영역. "재"라는 접두어가 무색하다.API에 서비스에 필요한 대부분의 코드를 재작성해서 넣었다. 결제, 과금, 콘텐츠, 개인화, 각종 이벤트, MD 큐레이션 등을 구현했고, 소셜 로그인, 선물함, 랭킹, 캐릭터관 등 새로운 기능들을 구현했다. 웹서비스도 재개발했는데, 로직과 뷰가 섞여있던 코드들을 API로부터 데이터를 받아와서 화면에 뿌려주는 비동기식으로 모두 재 작성했다.
이렇게 개발된 API를 기반으로 앱 개발이 진행되었는데, 디자인팀에서 만든 디자인 가이드라인과 Mock-Up을 바탕으로 앱 개발자들이 UX를 구현했다. (구현이라고 쓰고 "갈아 넣었다."라고 읽는다)
새로운 디자인을 처음 마주하고 든 느낌은, "디자인이 예쁘면 무조건 좋아 보인다."였다.
북팔 시즌4 디자인 확정 안 (300여장 중 일부)
디자인팀에서 만든 목업코드를 모두 재작성했다는 것은, 테스트 또한 처음부터 모두 다시 해야 한다는 이야기다. 운영팀에서는 회원가입, 로그인 같은 서비스의 기본적인 부분에서부터 작품 회차 목록, 뷰어, 결제 등 복잡한 부분까지 알파테스트, 베타 테스트 등 2중으로 QA를 진행했다.
D-Day.
일주일 전에 공지 한 대로 새벽 3시부터 6시까지 작업을 할 예정이어서, 전날 업무를 일찍 마무리하고, 새벽 2시까지 모이기로 했지만 다들 자다가 못 일어난다면서 각자 이것저것 최종 점검을 했다.
오픈하는날 점검 하는적 하면서, 기능 추가 하고 있는 개발팀같은 시각, 개발팀과 마찬가지로 오픈을 준비하고 있는 각 팀들도 분주히 준비하고 있었다. 운영팀은 서버가 멈춘 뒤와, 오픈 직후 서비스 상태를 모니터링하기 위한 준비를 마쳤고, 마케팅팀은 오픈 직후 론칭 마케팅을 하기 위해 준비를 했다.
오전 3시.
개발팀 내 오픈 조 4명이 모여, 간단하게 오픈 절차를 다시 한번 확인하고 웹서버의 Document Root를 점검 중 페이지로 전환했다. 점검 중 공지를 일주일 전부터 했음에도 불구하고, 새벽 3시에 서비스에 접속해 있는 이용자는 3,000명이 넘었다. GA를 통해서 이용자가 모두 접속이 해제된 것을 확인하고, DB 마이그레이션 시작.
오전 3시 40분.
약 2시간이 걸릴 것 같았던 DB 마이그레이션이 40분 만에 끝났다. 오픈 후 테스트 시간을 벌 수 있겠다 싶어서, 기존 앱의 강제 업데이트 플래그를 켜고, 대기하고 있던 앱 개발자에게 앱 배포를 부탁했다. 이미 Apple App Store, Google Play Store에 대기 상태로 있던 앱 발행. 5분 만에 배포 완료되었다는 소식을 듣고, API 서버와 웹서버를 올리고 운영팀에게 테스트 요청을 했다. 마케팅 팀에서는 여러 마케팅 채널에 배포되어 있는 링크들이 Dead-Link가 되지 않았는지 확인을 시작했다.
오전 4시 30분.
드디어, 이용자들이 앱을 업데이트하고 속속 접속하기 시작했다. 재 개발 한 부분에서 DB에 부하를 주는 곳이 없는지 DB 모니터링 툴을 수시로 확인했더니, 역시 슬로 쿼리가 몇 개 눈에 띈다. 전담 DBA가 없는 개발팀에서는 각자 나름대로 최적화해서 쿼리를 짜지만, 개발서버에서는 멀쩡히 작동하던 쿼리가, 이용자가 몰리는 실서버에서는 슬로 쿼리로 돌변하곤 한다.
오전 5시 20분.
사내 메신저에 "오픈 완료"를 알리고, 운영팀과 함께 "1:1문의"요청을 모니터링하고 있는데, 심상치 않은 문의 사항들이 올라오기 시작한다. 문의 내용의 대부분이 "이용내역 유실"과 "로그인 장애" 들이었다. 긴급하게 원인 분석을 시작했는데, 비로그인 상태의 내역과 로그인 상태의 내역을 동기화하는 부분에 문제가 발견되었다. 급히 동기화 기능을 보완하고 API를 재배포하였으나 이미 1시간 만에 앱은 몇천 건 이상 배포된 후였다.
오전 6시.
개발팀, 운영팀, 전략팀이 모여 대책을 논의하고, 급하게 대응팀을 꾸렸다. 1:1 문의로 접수된 모든 신고사항을 추리고, 문의 건별로 담당자를 지정하고 수동으로 이용내역을 동기화시키면서 문의에 대한 답변을 드렸다. 이후 직원들이 속속 출근하면서 거의 모든 직원들이 고객 대응에 나섰다. 기대를 갖고 새벽시간에 업데이트를 하셨던 고객님들에게 불편을 드려서 송구하다는 말씀을 이 글을 통해서라도 드리고 싶다.
이로서. 북팔은 새 옷을 갈아입었다.
