들어가며
안녕하세요. 스튜디오 킹덤 클라이언트 개발자 이한나입니다. 이 글은 제가 신입으로 입사하여 3년 차인 지금까지 일하며 경험한 것들을 돌아보고 되새겨 보는 글입니다. 이 글이 저와 같은 신입 또는 주니어 클라이언트 개발자분들께 작게나마 도움이 되기를 바라며 저의 경험을 나누고자 합니다.
제발 담당자한테 물어보고 작업하자
일하다 보면 종종 내가 이해한 것과 기획자가 의도하는 방향이 다른 경우가 생깁니다. 확신이 가지 않는 부분은 당연히 물어봐야 합니다. 설계를 하고 있을 때, 작업을 진행하고 있을 때, 작업을 완료 했을 때까지, 늦었다고 생각할 때가 가장 빠른 질문 타이밍입니다.
"10번 뽑기 기능"을 만드는 상황을 예시로 들어보겠습니다.
여기서 질문을 하지 않는 개발자가 1번 뽑기를 10번 반복하는 것으로 이해하고 (음! 전부 이해했어!) 작업을 진행합니다.
그리고 마감날이 되어 테스트를 돌려본 기획자가 물어봅니다.
기획자 : 이거 뽑기 10번을 전부 보여주고 있네요? 뽑기는 1번만 보여주고 보상을 10개를 줘야 하는데 다르게 나오는 것 같아요. 확인 부탁드립니다.
클라이언트 개발자: !!!
그동안의 시간과 노력을 지우고 다시 작업을 하는 상황이 되어버렸습니다. 눈물을 머금고 다시 작업을 하고 싶지 않다면 자신이 이해한 것 그리고 작업 방향이 기획자가 의도하는 방향과 맞는지 물어보고, 기록하고, 작업을 진행하도록 합시다.
추가로 작업하면서 중간중간 결과물을 영상으로 찍거나 스크린샷으로 캡쳐해 공유합시다. 구현 방향을 공유하는 의미도 있고, 나중에 리팩터링하거나 기능이 추가될 때 원본 기능이 어땠는지 참고하기 좋아서 기록 차원에서라도 남겨두는 게 좋습니다. 그리고 귀여운 작업물을 만들었다면 자랑할 수 있다는 장점도 있습니다.
다른 프로그래머의 코드를 수정할 때도 비슷합니다. 코드에는 의도와 맥락이 있습니다. 왜 이런 코드가 있는지 물어보고 의도에 맞는 방향으로 작업해 야 합니다. 그리고 수정 방향에 대해 얘기하다 보면 생각지 못한 더 좋은 코드가 떠오르거나 어딘가에 있는 동일한 코드를 가져다 쓸 수 있음을 알게 될 수 있어서, 어떤 코드에 대해 수정이 고민이 된다면 담당 프로그래머와 얘기해 보는 것이 좋습니다.
데이터 수정은 기획자에게 요청하자
"쿠키런: 킹덤"에서는 기획자가 퀘스트 내용이나 쿠키의 능력치 같은 게임 데이터를 작업합니다. 적은 양의 데이터 수정일지라도 어떤 데이터는 서로 연결되어 있어 규칙에 맞게 입력해야 하고, 또 그 데이터를 수정하고 번역 요청을 하는 등 관리가 필요합니다. 따라서 데이터 수정은 담당 기획자에게 요청하는 것이 가장 안전합니다. (담당자한테 물어보자는 위 문단의 내용과도 유사합니다.)
네트워크 환경이 항상 최선의 상태가 아닐 수 있음을 고려하자
예를 들어서, 클라이언트는 서버와 통신을 할 때, 클라이언트가 서버에 보내는 모든 요청이 실패할 수 있음을 고려해야 합니다. 유저의 네트워크 환경이 다양하기 때문입니다. 요청이 실패하면 경우에 따라 유저가 말을 걸어도 NPC 가 반응을 하지 않는 등 의도하지 않게 게임에 갇힐 수 있습니다. 그래서, 요청이 실패했을 때 화면이 어떻게 나와야 하는지, 다음 요청을 보내도 되는지, 요청이 실패하면 자동으로 다시 요청을 보내야 하는지 등 상황에 따라서 처리해야 합니다.
예를 들어, 유저가 버튼을 눌러 A 퀘스트를 클리어했다는 요청을 보냈는데 실패했다고 합시다. A 퀘스트는 클리어 통신 후 바로 다음 B 퀘스트를 시작하는 통신 요청을 (A 퀘스트 클리어 통신 성공 여부와 상관없이) 클라이언트에서 하게 되어 있습니다. 설상가상으로 B 퀘스트의 클리어 조 건으로 걸려있는 게 A 퀘스트의 완료입니다. 이렇게 되면 유저는 B 퀘스트가 시작되어 있지만 영원히 클리어하지 못하게 될 수 있습니다.
이를 방지하기 위해 클라이언트는,
- 요청 실패 시, 성공할 때까지 재요청하기
- 요청 실패 시, 이후 처리를 하지 않도록 리턴하기(그래서 유저가 다시 버튼을 누르게 하기)
- 퀘스트를 완료해야 다음 퀘스트를 받을 수 있게 조건 걸기
등 팀의 개발 기조에 따라 예외 처리를 둘 수 있습니다.
이번에는 예방 방법이 아닌, 이미 유저가 통신 실패로 게임에 갇힌 상황에서 클라이언트 코드를 수정하는 방법에 대해 이야기해 보겠습니다.
예를 들어, 특정 조건을 달성하면 자동으로 요청을 보내는 기능이 있고, 요청이 실패했으나 유저가 따로 액션을 취할 방법이 없는 상황이 되었다고 해봅시다. 이렇게 되면, 분명 기능이 있는데 상호작용을 하지 못해서 좋지 못한 플레이 경험을 얻게 될 수 있습니다. 얼른 문제를 예방하기 위한 방어 코드를 추가하고 구출용 방안을 모색해야 합니다.
이때 클라이언트가 시도해 볼 수 있는 방안으로는,
- 유저가 버튼을 누르면 요청을 보내는 비상 탈출 기능 넣기
- 재진입 시 조건을 만족한 상태라면 요청을 자동 다시 보내기
등 상황에 맞게 수정을 해볼 수 있습니다.
이처럼 네트워크는 항상 실패할 수 있다는 전제를 두고 개발해야 합니다.
라이브 서비스 중인 리소스는 조심히 다루자
이 주제를 얘기하려면 우선 빌드와 에셋번들에 대한 설명이 간단하게 필요합니다.
- 빌드는 코드, 프리팹, 텍스처 이미지 등의 리소스를 실행 가능한 파일로 묶은 것으로, 수정 시 전체 빌드를 새로 하고 스토어에 배포하는 과정을 거칩니다.
- 에셋번들은 리소스를 빌드와 분리된 외부 파일로, 빌드에 포함되지 않고 게임 내에서 패치 형식으로 다운로드하여 적용할 수 있게 해줍니다.
코드 수정이 필요하다면 빌드 수정이 필요하고, 에셋번들에 들어있는 리소스(프리팹 혹은 이미지 등) 수정이 필요하다면 에셋번들 수정으로 반영이 됩니다. 이 차이를 이해하고 있어야 다음 상황을 예방할 수 있습니다:
라이브 중인 기능을 수정하면서 어떤 변수가 더 이상 필요 없어 보여 코드상에서 제거했다고 합시다. 이 변수는 에셋번들로 관리되는 프리팹 A에서 사용하고 있습니다. 개발 환경의 코드에서는 더 이상 필요하지 않은 변수이지만, 라이브에 나가 있는 코드와 프리팹 A에서는 새 빌드를 스토어에 올리지 않는 한 이 변수를 사용하고 있을 것입니다. 개발 환경에서 변수가 제거된 프리팹 A'가 다른 라이브 수정이 필요해서 라이브에 나가게 되는 경우, 새 에셋번들의 프리팹 A’에서는 해당 변수가 사라지게 됩니다. 라이브의 코드는 제거된 변수를 참조하려 하므로 의도하지 않은 동작을 하게 됩니다.
이를 방지하기 위해 변수를 에셋번들의 프리팹에서 쓰고 있지는 않은지 먼저 확인하고 제거해도 될지, 남겨두어야 할지 고려하여 작업을 하는 게 필요합니다.
마무리하며
시행착오는 누구나 겪을 수 있는 일입니다. 중요한 것은 그러한 경험을 혼자 감추지 않고 팀과 공유하며, 재발하지 않도록 개선해나가는 자세입니다.
이 글을 읽는 여러분도 한 번의 경험에 좌절하지 않고, 그 순간을 기회로 삼아 한 걸음 더 성장해 나가시길 진심으로 바랍니다. 우리 모두의 개발 여정을 응원합니다. 감사합니다.
