주니어 클라이언트 개발자의 성장 노트

작업을 시작할 때는 담당자와 먼저 확인하고, 이해한 내용과 구현 방향이 맞는지 계속 점검해야 한다. 특히 기획 의도와 다르게 해석하면 처음부터 다시 작업해야 할 수 있으니, 설계 단계부터 완료 후 검증까지 의문점은 바로 물어보고 기록하는 습관이 중요하다.

중간 결과물은 영상이나 스크린샷으로 남겨 두는 편이 좋다. 구현 방향을 공유하는 자료가 될 뿐 아니라, 나중에 리팩터링하거나 기능을 확장할 때 원본 동작을 다시 확인하는 기준이 된다. 다른 개발자의 코드를 수정할 때도 마찬가지로, 코드가 왜 존재하는지와 어떤 맥락에서 만들어졌는지를 먼저 이해해야 한다.

데이터 수정은 가능한 한 기획자에게 요청하는 것이 안전하다. 퀘스트 내용이나 능력치 같은 게임 데이터는 서로 연결된 경우가 많아, 단순한 값 하나를 바꾸는 일도 규칙과 번역, 관리 절차를 함께 고려해야 하기 때문이다.

클라이언트는 네트워크 실패 가능성을 항상 전제로 설계해야 한다. 요청 실패 시 재시도할지, 이후 처리를 멈출지, 자동 재진입이 필요한지 등 상황에 맞는 방어 로직이 필요하며, 실패 때문에 유저가 게임 진행에 갇히는 상황이 생기면 비상 탈출 버튼이나 재접속 시 자동 재요청 같은 구제책도 마련해야 한다.

라이브 서비스에서는 빌드와 AssetBundle의 차이를 이해하고 리소스를 다뤄야 한다. 코드에서 변수를 제거해도 라이브 빌드나 에셋번들 프리팹이 아직 그 변수를 참조하고 있을 수 있으므로, 실제 배포 범위를 확인하지 않으면 의도치 않은 동작이 발생할 수 있다. 결국 시행착오는 숨기기보다 팀과 공유하고, 재발하지 않도록 개선하는 태도가 가장 중요하다.