DevLog - 게임을 출시하고 나서

요약

4월 17일, 여러 우여곡절이 있었지만.
장장 1년 2개월간의 여정이 끝을 맺었고, 글로벌과 한국에 모두 성공적으로 출시했다.
출시하기까지 있었던 일들과, 출시 전후로 배웠던 것들을 간략하게 적어놓고자 한다. 

21년 7월부터 (정확한 날짜는 입사하기 전이라 확신하기 어렵지만, 대략 해당 월 전후라고 한다) 시작된 이 프로젝트는.  약 2년의 시간을 지나 4월 17일 성공적으로 글로벌 런칭을 진행했고, 당초 목표로 잡았던 일매출의 약 N배 정도를 기록하고 있다. (즉 기대 이상의 성공(??) 중이다) 그리고 나는 이 프로젝트를 통해 다음과 같은 것들을 배웠다. 

1. 핫픽스를 하며 배우고 느낀 것들
정식런칭 이후 한숨 돌리려는 찰나, 소프트런칭때는 발견되지 않았던(!!) 버그들이 마구마구 터져서, 약 4회정도 급하게 핫픽스를 진행했었다. 아래는 핫픽스를 진행하면서 배웠거나 느낀 것들이다.

1-1. 통신은 실패를 염두해 두어야 한다. 
런칭 2일차, 계정 데이터에 대한 중대한 이슈가 발견되었다. 덕분에 10시에 집으로 가던 도중 급하게 회사로 돌아와야 했고 새벽 2시까지 작업했다. 원인은 의외로 간단했는데, 로그인 시도 중 특정 단계에서 로그인에 실패하는 경우 실패한 상태에서 게임을 재실행하면 (실행되었어야 하는) 몇가지 함수를 실행하지 않고 즉시 계정 데이터를 불러오는 부분이 원인이었다.
해당 이슈를 팀에 전파하고 간단하게 수정된 빌드를 공유한 뒤, 검토를 기다리면서 로그인에 관련된 함수를 검토한 결과. 로그인 실패 시 or 부적절한 로그인 진입 시 전환되는 루틴이 아예 존재하지 않는다는 것을 알게되었다. 이를 검증하기 위하여 팀원들과 버그 재현을 위해 분투하면서, (의도적으로 에러를 던지지 않는 이상) 통신실패를 재현한다는 것은 너무나도 힘들고 어려운 일이라는 것을 고통스럽게 배웠고. 
만약에 언젠가 내가 로그인 등을 구현해야 하는 상황이 온다면 설계에서부터 각 단계별로 실패하는 상황을 염두해두고, 각 상황을 안전하게 핸들링할 수 있도록 설계해야겠다고 생각했다.  

1-2. 남의 코드도 내것처럼!!
현재 소속된 팀은 강한 코드 소유권 규칙을 적용하고 있기 때문에, 현재는 최대한 그 규칙을 준수하고 있지만. 개인적으로 약한 코드 소유권, 나아가 코드 공동 소유를 지향하고 있기 때문에. 언제든지 지향하는 방향으로 스위칭할 수 있도록 항상 다른 사람의 코드도 추적하면서 그 흐름을 숙지해두고 있었다. (버스 팩터를 높여서 만일의 상황에 대한 리스크를 최소화하고 싶었기 때문인 것도 있었다)
그 덕분에, 런칭초 이슈가 발생했을 때 비교적 빠르게 이슈들을 해결할 수 있었고, 역시 숙지해두길 잘했다고 생각했다. 시스템을 통해 최소화할 수 있지만, 사람은 반드시 실수를 하게 되어있기 때문에. 이것에서 기인하는 문제를 효율적으로 해결하기 위해서는, 강한 코드 소유권을 통해 영역을 나눠 책임을 지우고 잘잘못을 가리는게 아니라. 약한 소유권을 통해 문제 해결을 위해 팀이 힘을 합할 수 있도록 하는 것이 더 나은 방식이라고 생각한다.

1-3. "지금 그러고 있음"은 "그럴리가 없음"보다 앞에 있다.  
"그럴리가 없는데..?"라는 말을 들어도, 제보받은 이슈를 한번 더 살펴봐야 한다. 조작 미숙 / 잘못된 치트 사용 / 기분탓 등 문제는 문제가 발생하는 원인은 앱 바깥에도 수만가지가 존재할 수 있지만. 그 쪽으로 생각을 진행시키기 전에, 제보받은 이슈의 디테일을 한번 더 꼼꼼히 검토해보아야 한다. "특수한 상황에서 유저가 조작을 실수했거나 or 그냥 착각한 것 같은" 것 같아보이더라도 어딘가 오버플로우가 일어나고 있는 것에 대한 중요한 단서일수도 있다. 
특히, 앱 바깥에서 생기는 원인은 개발자 외의 사람들이 같이 고민하면서 떠올려주기 때문에, 적어도 클라이언트개발자 만큼은 (모두 제보자가 착각한 것이라고 이야기하고 있더라도) 앱 내에서 생기는 문제가 정말로 아닌지 한번 더 확실하게 검증하는게 좋다.  

1-4. 유저는 반드시 알아챈다
"잘 모를 것 같으니 넘어가죠"라고 하면서 넘어갔던 디테일들은 반드시 누군가 알아채고 제보한다. 

1-5. 운영에 의존해선 안된다.
문제가 생길 수 있는 지점에다 "특수한 상황에서만 가끔 생기는 일이니까, CS처리하면 돼"라고 하는 사람이 있다고 해서 그냥 넘기면 안된다. 그 문제는 자주 생길것이며, CS처리는 안 될 것이다.
농담처럼 이야기했지만 정말로 그렇다. 운영분들은 CS를 처리할 때 해당 제보가 참인지 거짓인지를 판단해야하며. 해당 참 / 거짓을 판단하기 위한 근거가 (거의)반드시 필요하다. 만일 (가끔 생긴다던 그 문제가) 발생한다면 CS분들은 제보받은 문제의 진위를 판단하기 위해 고군분투하다가 어떠한 처리도 되어있지 않다는 것을 깨닫고, 해당 제보 검토를 요청할 것이고. 재현스탭, 발생원인, 해결방법 따위를 고민하다가 결국 그 지점의 수정이 필요하다는 것과 그때는 릴리즈 전이라 수정 이후 충분한 테스트를 가질 여유가 있었지만, 지금은 그렇지 않다는 것을 깨닫게 된다.
다시말해 잠재적인 이슈가 생겨날 수 있는 지점은, 그냥 발견된 즉시 수정하는게 낫고 설사 수정할 수 없다고 하더라도. 최소한 운영분들이 로그나 데이터를 보고 판단할 수 있도록 최소한의 안전장치를 구비해두는 것이 좋다.   

 

2. 좀 더 공부해봐야겠다 생각한 것들
그리고 아래는 1년 간 작업을 진행하면서, 아직 명확하게 답을 구하지 못했지만 언젠가는 답을 찾아내어 정리해둬야겠다 싶었던 것들이다.

1. 임시 기능들을 명명하고 관리하는 방법
검증을 위해 or 정보가 필요해서 임시로 만들어졌던 기능들은 언젠가 반드시 제거되거나 혹은 정식으로 편입되어야 하는 시기를 거쳐야만 한다. 하지만 때로 몇몇 기능들은 "제거하기는 애매하지만, 정식으로 넣기는 애매한" 상태를 줄곧 유지해오다가 런칭 직전에 상기한 루틴이 강제된다.
모든 기능들이 캡슐화 되어있어서, 각 모듈들이 제거 / 편입되더라도 영향이 없는 상태가 가장 행복하겠지만.. 그렇지 않은 프로젝트에서는 판단 기준이 필요하다. 
내가 궁금한 부분은 담당자가 제거 / 편입을 판단해야 할 때 무엇을 기준으로 판단하면 되는가?? 에 대한 부분이다. 팀에 전파가 끝났고 일단 유지해보기로 하는 순간 편입을 상정해야 하는가? 여전히 제거될 수 있다고 생각해야 하는가? 임시 기능이 코어와 밀접하게 연관되어있기 때문에 상태를 변경하는데 코스트가 아주 많이 든다면?
몇 주 뒤에나 결론이 날 것 같아서 지금 당장 결정할 수 있는게 없을 때에는 어떻게 기록해 두어야 할까?
제거를 염두해두고 언제든 분리할 수 있도록 하기 위해 설계한 구조가 일관성을 해칠 때, 언제까지 두는게 좋을까?
등..

2. 실수가 반복되지 않게 관리하는 방법
개인적인 실수는 오답노트, 작업일지 등을 통해 관리할 수 있다. (버전관리 툴 사용 등의 과정에서) 팀 단위의 실수가 생길 수 있는데, 이 경우에는 어떻게  

 

 
수정내역 
- 2023.04.30 : 최초작성
- 2023.05.03 : 더 알아봐야겠다 생각한 것들 리스트업 및 작성 중