많은 자극이 되는 글이네용 ㅎㅎ 대단하신분
출처: http://log.op.gg/
2014년 1월 7일, OP.GG가 1주년을 맞았습니다. 저희에게 이번 1년은 매우 짧게 지나간 것 같습니다.
OP.GG는 2012년 12월 23일 개발에 착수했습니다. 당시 유명했던 다른 전적 검색 사이트가 제대로 동작을 하지 않았던 시기였습니다. 기존에 쓰던 개인용 70만원짜리 일반 데스크탑용 서버에서 Apache + PHP + MongoDB + APC 환경으로 개발을 진행했고, Closed Beta 로 사이트를 잠깐 잠깐 12월 말에 공개하다가 어느정도 완성된 기본적인 소환사 검색 기능이 완성된 1월 7일, 정식 Beta 사이트를 오픈했습니다.
롤 커뮤니티에 사이트를 공개를 했고 그 반응은 엄청났습니다. 오픈을 하자마자 부하에 시달렸고, 계속해서 쌓이는 데이터에 대해 MongoDB는 엄청나게 많은 용량을 차지했습니다. 초당 Insert 가 수백에 달했습니다. 부하 역시 그에 따라 많이 증가했습니다. MongoDB를 버리기로 결정하고, Mysql 로 전향할 준비를 했습니다. 우선 서버 이전을 준비하며 MongoDB를 사용한 부분은 그대로 유지하며, Mysql 로 추가적인 기능 개발에 촛점을 맞췄습니다. 기획자는 Facebook 으로 사용자의 피드백과 마케팅을 쉴새 없이 했습니다.
OP.GG 공식 페이스북은 1주일만에 2천개의 좋아요를 받고, 사이트 방문자수는 하루 3만을 찍었습니다. 점점 서버가 더이상 버티지 못하는 단계로 들어섰습니다. 계속해서 증가하는 사람을 버티기 위해 아직 할부금이 남은 새차를 팔아, 약 700만원 정도의 새로운 서버를 장만 했습니다. 주말과 재고 부족의 장애물을 넘어 5일이나 걸리고서야 결국 서버를 구매하고 세팅 직후 쾌적한 환경을 보여주게 됐습니다.
비용을 최대한 아끼기 위해 조립서버를 직접 주문하였는데 조립하는데 반나절을 쏟아부었습니다. 그냥 일반 컴퓨터 조립하는거랑 별 다른거 없는 줄 알았는데, 다 조립하고 나서 모니터가 안나온다든지, 인터넷이 안된다든지 하는 오류도 많아서 OS 설치도 여러번 했고요.. 그래서 실제 서버를 구매하고도 실제 서비스까지 2-3일은 걸린 듯 합니다.
그러던 중 간단한 문제에 부딛혔습니다. 당시엔 LOL 서버가 많이 불안정한 상황이어서 LOL 서버가 죽음/살음에 따라 OP.GG 사이트도 속도가 느려지거나 다운되는 경우가 빈번했습니다. 소환사를 검색하면 바로 LOL 서버에 요청해서 새로운 전적을 받아오는 방식 때문이었죠. 우선 LOL 서버 상태를 캐시하여 서버 상태를 체크하도록 해서 급한 불을 껐습니다. 나중에는 갱신 버튼을 따로 누르게 하는 방식으로 원천적으로 해결이 되었죠.
그렇게 좋아진 서버와 안정성을 가지고 오픈 2주만에 하루 평균 30만명의 순방문자(UV)를 확보했습니다. 일주일 전과 비교해 10배나 증가한 수치였습니다.
서버 이전 후 쾌적한 환경에서 함께 MongoDB의 데이터를 Mysql 로 전향하는 작업을 진행했습니다. 기능추가와 마이그레이션 작업이 같이 진행되어, 끝나는데는 약 10일 정도가 걸렸습니다. 드디어 그때부터 본격적인 기능추가와 최적화/튜닝 작업이 시작됐습니다.
LOL 관련 국내 대형 커뮤니티 3개 사이트의 모니터링도 수시로 빠지지 않고 했습니다. 유저 말 한마디 한마디가 (정말로 한마디가) 중요했고, 대부분의 커뮤니티에 적힌 피드백이 인기의 증거이자 성장의 방향이었습니다. 서비스가 크고 있는지 아닌지 확인을 하려면 우리 서비스 내부에서 확인을 할 수 없습니다. 철저히 외부를 분석해야 합니다.
특히 경쟁 서비스가 있는 경우 이런걸 통해 실시간으로 유저의 반응을 지켜보는 것도 중요합니다. 갑자기 떨어지면 우리 서비스에 어떤 문제가 생겼나 체크를 해보는 것도 정말 중요합니다. 관련 커뮤니티에 검색을 해보면 됩니다. 물론, OP.GG 의 경우 LOL이라는 한 주제만 다루는 사이트이고, 이에 대한 커뮤니티도 존재하기 때문에 가능한 사실이었긴 했습니다. 이외에도 트위터, 네이버 카페/블로그 모니터링 등이 있을수 있습니다.
모니터링을 하면서 서비스 속도에 대해서는 항상 평이 안좋았습니다. 지금도 아직 해결되지 못한 문제이기도 합니다. 개발자 아이피에서는 실 서비스에서도 Executed Time 과 디버깅 로그를 항상 찍도록 하면서 항상 사이트 이용을 디버깅 환경으로 구성해뒀습니다. 서버 증축과 IDC 입주도 준비했습니다.
그래서 우리는 항상 UI에 촛점을 뒀습니다. 아무리 좋은 기능이라도 유저에게 편의성을 지원하지 않으면 안되고, 사용법이 어려우면 눈을 어지럽힐 수 있으니 없느니만 못하다는 문제였죠. 사실 추후에 추가된 “전적 갱신” 기능도 마찬가지로 이런 편의성 측면에서 문제가 컸습니다. 그냥 검색만 하면 자동으로 나오는게 사용자들의 요구이지만, 서버 부하나 데이터 갱신률을 위해서는 정말로 어쩔 수 없이 물러날 수 밖에 없었던 기능이기도 합니다. 이후에도 비슷한 여러 사례가 존재했죠.
좋아요 수를 높힌 페이스북을 통해 빠짐없이 제대로된 피드백과 의견도 받았습니다. 기획을 1명이서 하고 있기 때문에 더 다양한 아이디어와 관점이 필요 할 때가 많습니다. 그래서 이렇게 많은 사람들의 의견을 받다보면 생각치못한 금덩어리 같은 아이디어가 나오기 마련이거든요. 처음엔 사이트 홍보를 위해, 커진 척을 위해 받기 시작했던 페이스북의 좋아요가 지금에서는 무엇과도 바꿀 수 없는 중요한 피드백 도구가 됐습니다. 정말로 찾기 힘든 문제(브라우저 호환성 등)가 있을 경우엔 페이스북으로 모집하면 금방 사례를 찾을 수 있었습니다. 재빠른 디버깅이 가능했죠.
지금은 없지만 이런 기능도 있었습니다. 여러가지 진행했던 게임들에 대한 요약 스탯을 보는 기능이었습니다. 이 기능은 누군가에겐 좋은 정보가 될 수 있지만 가독성 문제가 존재했습니다. 실제 이용하는 사람도 많지 않았고, 상세한 수치들이 화면에 자리잡고 있어 가독성도 좋지 않았고 미관상으로도 문제가 있었습니다. 유용한 정보가 될 순 있지만 유저 피드백으로 과감하게 버린 사례입니다.
위 화면들은 “최근게임 목록” 의 UI 변화들입니다. OP.GG 에서 제일 많은 변화를 겪은 부분이기도 합니다. 사실 지금도 또 다른 변화를 계획하고 있습니다. 최근게임 목록은 많은 사람들이 필수적으로 이용하는 부분입니다. 한눈에 파악이 쉽게 가능해야 하고, 쉽게 익숙해질 수 있어야 합니다. 그래서 계속해서 좋은 방향을 찾아갔고, 최대한 타협을 통해 제거 할 수 있는 데이터는 제거를 했습니다. LOL 에서는 정말로 많은 데이터를 주지만 가독성을 위해 많은 것을 버렸습니다. 심지어 유저의 선택권마저도 미리 버려줬습니다.
이 간단해 보이는 랭킹 화면도 사실은 디자인이 괜찮은 게임 홈페이지들을 몇 곳이나 뒤져가며 만들어진 화면입니다. 블레이드앤소울, 아키에이지, 마비노기, 또.. 기억이 안나네요. UI는 유행을 타기도 하기 때문에 이런 조사도 꼭 필요 했던 것 같습니다.
개발 인력도 1명뿐이므로, 모바일도 최대한 PC버전의 코딩을 유지하면서 반응형 웹으로 개발을 했습니다. 속도는 조금 느릴 수 밖에 없었습니다. 어플 역시 간단한 웹뷰로 땜빵 처리 했습니다. 개발 인력이 없으므로 최선의 방법이었죠. 안드로이드 앱 역시 마찬가지였습니다.
모바일을 오픈 하고 나서야 비로소 뼈저리게 인식했던 사실이 있습니다. 유저들은 생각을 하기 귀찮아한다는 사실. 다양한 연령대의 유저를 끌어들이려면, 극한의 편의성까지 생각을 해야한다는 사실을 알았습니다.
계속되는 기능 추가 탓에 서버 부하는 날로 늘어갔습니다. 시즌3 시작의 여파로 인해 사람 수는 매우 줄었음에도 불구하고요. 그러다가 기존에 쓰던 APC를 버리고 5월에 Memcached 로 캐시 엔진을 변경했습니다. 하지만 여기저기 찾아본 결과, 추후 범용성을 위해서는 Redis 가 더 좋은 답이라고 생각하여 열흘만에 Redis로 갈아탔습니다.
1월에 오픈 2주만에 30만명을 찍었지만, 시즌 3가 시작되고 전적 갱신이 막히는 바람에 방문자 수가 절반 훨씬 이하로 급감을 했습니다. 사이트의 수익이 상당히 부족했습니다. 그래서, 번역가를 모집할 돈 역시 부족해 유저님들의 힘을 빌렸습니다.
드디어 세번째 디자인 개편이 진행됐습니다. 사이트의 디자인 역시 개발자가 했습니다.
Mysql 을 최대한 배제하고 다른 DBMS로 변경하려는 생각으로, 룬/마스터리 기능은 다른 데이터와 Join 을 필요로 하는 데이터가 아니기 때문에 Cassandra 를 도입했습니다. 아직 한국에서 사용 사례가 별로 없어서 관련 자료가 너무 없었습니다. Couchbase 등 여러가지 고민해보면서 도입해본 DB인데요. 상당히 많은 수의 Insert 가 됨에도 불구하고 반년동안 전혀 읽기/쓰기 이슈가 생기지 않았습니다. 정말로요..
이런 일도 가끔 일어났습니다. 이런 일을 겪으면서 직원수가 좀 되는 중소기업에서 이런일이 일어났으면 어떻게 됐을까? 생각을 많이 했습니다. 꼰대 상사가 있었다면 담당자가 욕을 먹겠죠? 9시간의 사이트 마비는 중대한 이슈지만.. 혼내는 것 보다 이 이슈가 얼마나 중대한 이슈인지를 일컫게 해주고 혼자서 자책하도록 유도하는게 훨씬 더 좋은 방법이지 않을까 되뇌었습니다. (어쩌면 더 잔인할수도 있겠습니다만..)
8월에는 기존에 사용하던 PHP Template 엔진인 Smarty 를 Raintpl3 로 바꾸는 작업을 했습니다. 아직 출시되지 않은 템플릿 엔진이지만 기능이 적기 때문에 속도가 빨랐습니다. 서버 언어가 아직도 PHP이기 때문에 서버 성능에 너무 이슈가 많았습니다. 기본적인 Connection Pooling 도 지원이 되지 않아, Mysql 과 Redis 와의 이슈도 늘 존재해왔죠.
이렇게 1명의 메인개발자가 하루 수면시간 4시간을 유지하면서 죽도록 개발만 했습니다. 피부의 상태가 눈으로 확연히 비교할 수 있을만큼 안좋아지는게 보였죠. 그러면서 보조 개발을 하는 인원이 두명 늘어났습니다. 하지만 한명은 자신의 길을 바꿔야겠다며 다음달에 급하게 재수 준비를 하러 갔습니다.
그래서 이 보조 개발자를 통해 다시보기 기능도 개발되고요. 외부 인력을 통한 새 기능 개발의 첫 발을 디뎠었습니다.
기능은 계속해서 추가됐습니다. 1년동안 모든 UI들에 대해 세심한 관심을 기울이며 기획/개발을 진행했습니다. 어느 하나 “아 이거 또 대충줬네 그냥 대충 해야지” 하고 개발자가 대충 때운 것이 없었습니다. 이런 경우가 꽤나 많아서 기획자와 개발자가 싸운적도 많고요.
최근에는 Redis 가 APC로 다시 교체되었습니다. Socket Connect/Close 부하가 너무 커서 어쩔 수 없는 선택이었죠. 간단한 캐싱은 모두 APC로 처리를 하고 있습니다.
제일 최근에 한 작업은 소셜 번역 작업입니다. 번역에 많은 시간이나 금액을 투자하기 힘들기 때문에, 수많은 방문자들을 통해 번역 작업을 진행하고 있습니다. 퀄리티를 보장 할 수 없는게 단점이긴 하지만, 도움 주실 수 있는 분들이 있고, 그로 인해 본인들이 기쁨까지 얻을 수 있는데 가성비 짱 아니겠습니까. 현재 도움을 주시는 분들은 한국인 300명, 외국인 400명 정도가 됩니다.
소셜 번역이기 때문에 문구가 자유롭게 변형이 됩니다. 투표 시스템을 통해 높은 득표의 언어가 표시권을 얻게 되죠. 그렇기 때문에 DB를 이용해야 했고, 이를 구현하는데는 Mysql이 사용됐습니다. 뭐, 메인 DB 시스템이 전부다 Mysql 이니 이상할 것은 없네요. 하지만 매번 쿼리를 할 수는 없으니 APC를 통해 유저캐시를 했습니다.
앞으로 LOL이 살아 있는 한 계속해서 유지하고 싶고, 더 키우고 싶습니다. 또 지금은 한국서버만을 지원하고 있지만 전세계 모든 서버를 대상으로 하고도 싶구요. 1년간 제휴나 광고, 제안 요청이 수십업체에서 들어왔습니다. 하지만 인력도 적은데다 기능 추가에 촛점을 맞추고 있기 때문에 대부분 제대로 응대를 해드리지 못했음을 진심으로 사과드리고 싶습니다. 인력이 늘어나고 개발 속도가 안정적인 권에 들어 갈 때 본격적인 시작을 해볼 것이고 그때까지는 아직 지금까지 한 것과 비슷한 시간이 흘러야 하지 않나 싶네요.
페이스북에 댓글을 달아주시는 분들과, 무료로 도움을 주시려는 분들을 보면 정말 하루에 3~5시간의 수면 시간을 유지하며 사이트를 만든 보람이 있다고 느껴집니다. OP.GG를 이용해주시는 모든 분들에게 감사의 말씀을 드립니다.
