레이드.
마비노기라는 게임에 레이드라는 단어가 이제 어울릴지 모르겠습니다.유저 하나하나가 너무 강해지는 바람에 체력이 못따라가는 상황인 것 같더군요..
그럼에도 불구하고 싴갤러스에서는 유저분들의 제보를 이용해 보다 더 나은 레이드 환경을 만들려고 항상 노력하고 있습니다 (진짜)
오늘 이 글에서 다룰 이야기는 바로 그 레이드 개선에 관한 이야기입니다
구조적 문제를 안고 시작하다
처음 싴갤러스의 레이드를 다룰때는 네이드, 거대사자, 거대악어, 평원 드래곤 그리고 이프리트 5종만 다루었습니다.
아마 위 레이아웃은 본적도 없으신분들이 많을 것 같은데요.
이때는 웹, 즉 PHP를 막 배우고 있을때 만든 홈페이지라 레이드 별로 페이지를 전부 하나씩 생성했습니다.
그리고 DB에서 보스별로 불러와 처리했죠. 그러니까 즉, SQL 쿼리만 살짝 다른 페이지가 5종, 전체를 볼 수 있는 페이지까지 해서 6종이죠.
그리고 자바스크립트도 잘 할 줄 몰라서 하나의 페이지를 가지고 인자를 전달해 다른 결과를 보여준다는건 생각도 못했고, 무조건 페이지 이동이 필요했습니다
js를 좀 배우고 나서도 문제가 해결되진 않았습니다.
이미 나눠진 페이지를 굳이 합칠 필요가 없었기 때문입니다. 그리고 이땐 또 ajax와 REST개념을 잘못 이해하고 있어서 ajax로 데이터를 불러오는게 아니라 페이지 자체를 그대로 불러와 대상 dom 에 씌우는 식이었습니다. 그러니까, 불러오는 페이지에서 표까지 완전히 작성하는 구조였죠.
그렇게 많은 페이지들이 만들어진 상태에서 레이드가 계속 늘어났습니다. 레드 드래곤부터 시작해서, 시간이 고정이었던 사막 드래곤, 신규 레이드인 블랙, 화이트 드래곤부터 지금의 실반 드래곤, 모쿠르칼피까지. 첫 단추를 잘못꿴 상태였기때문에 똑같은 페이지를 계속 만들어낼 수 밖에 없었습니다. 잘못된건 아는데, 빠르게 결과물을 내야했기때문에 -당시에 레이드는 경쟁구도의 사이트가 있었습니다- 속도를 올릴 수 밖에 없었고, 나중을 기약하며 조악한 페이지들을 계속 늘려만 갔죠. 그 결과는...
(여기서 strings는 작업하려고 추가해놓은거고 실제론 없었음)
raid3.php 이라는 뷰 페이지에서 page를 include 해서 보여주는 식이었고, 각 페이지에서는 각 프로세스를 처리할 (레이드 마다 시간이 다르기때문에) 페이지에 1:1로 매칭이 됩니다. 초록색은 작업하려고 만든거라 상관없고... 그러니까, 거의 20여개에 달하는 페이지로 구성되어 있던거죠... 그리고 스크립트도 PHP 변수를 사용해 처리하기때문에 인라인 스크립트로 작성되어 있고, css도 인라인 css로 작성되어 있기때문에...
단 하나의 수정이 발생하면 최소 8개 페이지(레이드가 다르더라도 인터페이스는 공통된 경험을 줘야하니까)가 수정되어야했고, 좀 심하면 처리 페이지까지 수정해야했으니 1글자를 고치기 위해 20페이지가 수정되어야 하는 기염을 토하기도 했습니다.
구조적인 문제가 분명히 있었으나, 다들 잘 쓰고 있으니까요. 굳이 수정이 안되어도 문제가 없었습니다. 어차피 레이드는 완성형이라고 생각했고, 뭐 하나 추가되면 페이지 늘려야지, 이젠 도가 텄으니 빨리빨리 수정할 수 있다 이런식으로 애써 신경안쓰려고 하고 살았습니다..
곪은건 터지게 된다
신규 기능 요청이 들어왔습니다. 별건아니고, 전광판을 여러개 띄울 수 있게 해주세요.... 인데
모든 보스몬스터가 별도로 구분되어 있기때문에 현재의 구조로는 제공할 수가 없었습니다. 정확히는 가능은 하지만 불필요한 함수를 작성해야할 수도 있고, 뭣보다 중간에 수정이 일어나게 되면 모든 페이지에 같은 내용으로 또 작성... 아... 더 이상은 얘기하기 싫네요.
그래서 이왕 이렇게 된거 레이드 자체를 다시짜자고 결심하게 되었습니다.
단 한번의 수정으로 많은 경험을 선사해주자는거죠. 결론부터 작성해보자면 다음과 같이 변했습니다.
여기에 raid.js 라는 별도로 분리된 js 파일이 하나 더 있습니다. 뷰를 담당하는 파일이 하나 더 있고요.
먼저 페이지를 통일하는게 중요했습니다.
어차피 설명만 좀 다르고 마크업은 똑같기 때문에 (아주 약간만 다르던지) assets에 strings 를 추가해 파라미터별로 설명을 다르게 표시해주는것부터 시작했습니다. 같은 이름의 변수를 case마다 계속 작성해나가는게 유쾌한 경험은 아니었지만 필요한 작업이니까, 좋게 말하면 string을 분리한거고, 나쁘게 말하면 우겨넣은거죠. 그래도 다음과 같아졌습니다.
이제 이 수많은 print_보스들... 왜 이럴까 소스를보니 초반부는 다른데 후반부는 완전 같습니다.
이상하네 하고 보니까(내가 짠건데 이상하네라고...) 그냥 시간을 체크해서 레이드 시간인지 아니만 판단하는 부분만 다를뿐 모두 같더군요.
그리고 이상하게 뿔피리데이터를 이쪽에서 만들고 있었는데 검색 키워드만 조금씩 다르고 쿼리도 같고요. 자갈치 시장도 아니고 한번에 처리하려고 발악을 한 느낌이었습니다. (print_smd_data , print_smd_horn 이렇게 안하려고...?)
해야할건 명확했습니다. 각 보스별로 시간 체크 및 시간, 제보 정보를 합치고, 뿔피리 데이터를 분리해 처리하는 두개파일로 나누는거죠.
그리고 전광판을 여러개 띄웠을때도 같은 페이지로 온전히 동작해야하니까 범용성을 살짝 넣고.
그렇게 서버에서 주는 값들을 대강 명세하고, js 를 수정했습니다.
기존엔 js안에 서버 변수를 넣어서 그대로 작성한 케이스가 많았는데 이번엔 어떤 서버변수도 사용하면 안되었기때문에, url 을 이용해 구분했습니다. 그리고 대부분의 DOM을 dynamic 하게 만들어야했기때문에 js안에 html div를 많이 작성했습니다. 이게 맞는 방법인진 모르겠는데.. 맞겠죠?;
js를 작성하면서 느낀건데 multi line을 작성할때 쓰는 ` (back qoute)와 new URL, filter arrow 등은 IE에서 사용할 수가 없었어서 다 만들었다 생각했는데 대체하기 위해 다시 작업을 하고.... 뭐 그랬던거 같네요. 그리고 신규 관리자분이 들어왔는데... 시련이 시작되었습니다. css 지옥이었는데.. 봐주는 관리자 한명이 잠을 안자...
화면을 같이 보고 있는게 아니라서 캡쳐 후 보여주기를 계속 반복해야했고 결국 대화방 앨범이 이거 관련 내용으로 한페이지를 넘게 차지하게 되더군요. 개인적으로 디자인 작업은 안좋아하기때문에 아주 많이 힘든 시간이었습니다.... ㅠㅠ
신규 기능 추가를 마치고, 테스트 서버에서 기능이 실제 데이터 기반으로 잘 돌아가는걸 확인하고 기능을 릴리즈 했지만 IE 호환문제, 창이 자동으로 안뜬다던지, 채팅 제보 정규식에 문제가 있다던지 하는 소소하면서도 안되면 불편한 문제들이 계속 발견되면서, 한번에 완벽하긴 정말 어렵구나 하는 생각을 했습니다
돌아보며
금번 작업은 보기엔 별거 없습니다. 기능한개가 추가 되었고, 사이트 외형적으로도 거의 변한게 없습니다.
그러나,
5,000여 라인의 코드 삭제가 있었고, 2,200 여 라인의 코드 작성이 있었습니다.. 이 작업은 단 이틀만에 수행되었고요..
훨씬 많을줄 알았는데 이거밖에 안돼 같은 생각이 들지만, 범용성을 위한 코드 리팩토링은 싴갤러스를 운영하면서 처음인거같습니다.
코드자체가 대단한것도 아니고 난이도가 있는 코드도 아니지만, 짧은 시간내에 끝내려고 일정을 빡빡하게 잡았고, 오히려 시간이 타이트했기때문에 한줄한줄 쓸모없이 작성하지 말자 이렇게 임했던 느낌입니다. 유저 수요도 고려하고, 중간에 기획을 바꾸기도 하면서..
개인적인 성취를 이룬 느낌이 더 강한 업데이트였습니다. 구조 통일도 했으니 앞으로 레이드쪽에 더 많은 기능 추가가 있을....수도 있겠죠?
다음엔 더 재밌는 글로 찾아뵙겠습니다~