게임회사 리드 개발자 1년차 후기

어쩌다보니 운과 타이밍이 잘 겹쳐 현재 재직중인 회사에서 리드 개발자로 일하고 있다. 2024년 11월부터 재직했으니 1년 반이 되어가고 있는 셈이다.

 

처음에는 이렇게나 다양한 업무를 하게 될지 몰랐고, 외부와 교류를 할 때 거창한 칭호로 스스로를 소개해야 해서 부끄럽기도 했었다. 사수가 없어지니까 성장에 대한 불안감도 있었고. 근데 자리가 사람을 만든다는 말이 진짜인 것 같다. 돌아보니 제법 성장했다.

그리고 글로 정리하지 않으면 금방 머릿속에서 사라질 것 같다는 기분이 들었다. 당장 글을 쓰도록 하자.

 

리드 개발자라고 하면 거시적인 코드 설계와 주니어 성장에만 신경쓰면 될 거라고 착각하고 있었다.

다만 내가 실제로 겪은 업무는 좀 차이가 있었다.

 

 

프로젝트 핸들링하기

우선 모든 부서와 직원들의 역량을 파악하고 있어야 했다. 이것은 개발 파트 뿐만이 아니라 기획/아트 파트의 역량도 알고 있어야 한다는 것이다. 디렉터가 현장을 지휘하는 것은 맞지만, 실제 개발 규모에 관한 키를 잡고 있는 건 나라고 느껴졌다. 디렉터가 원하는 기획을 제공하면, 나는 그 기획을 현실적으로 어디까지 실체화시킬 것인지를 논의하고 일정을 설계해야 했다.

 

초기에는 개발 파트만 속도를 내면 일정을 당길 수 있을 것이라 착각했는데, 실제로는 타 파트의 일정 배분이나 처음 겪는 파이프라인 등의 이슈가 있어 그보다 훨씬 늦어졌다. 실제 개발 일정은 예상보다 2배 늘어난다는 말이 실제로 일어날 줄이야... 많이 배운 것 같다.

 

개발-아트 파이프라인을 명시해서 협업해야 한다는 것도 이번에 깊게 깨달은 사실이다. 애니메이터 컨벤션을 설정해놓지 않고 작업했었는데, 이것이 후반부 폴리싱 작업을 어렵게 만드는 원인이 되었다. '다 프로들이니까 알아서 잘 하겠지'라고 생각하지 말았어야 했고, 프리팹 구조나 연출 가이드라인을 협의해서 깃 충돌이나 작업이 추가로 생기는 경우를 없애야 했다.

 

그리고... YAGNI 원칙은 프로젝트 설계에서는 조금 내려놓는 게 낫다고 생각했다. 예시로 입사 전부터 라이브중이던 프로젝트는 글로벌 출시를 전혀 고려하지 않았기에, 현지화 작업을 위해 대단히 고통스러운 노력을 해야만 했다. 라이브중인 게임의 기존 유저 세이브와 호환되도록 구조를 갈아엎었던 걸 다시 떠올려보면 아찔하다. 만약 미리 현지화를 고려했다면 오래 걸리지 않았을 것이다.

 

지금으로서 미리 고려해도 된다고 생각하는 항목들은 현지화, 콘솔 입출력, 크로스 플랫폼 등인 것 같다.

 

 

주니어 개발자 키우기

교육과를 졸업해서 그런지 적성에 맞는 일 중 하나인 것 같다. 면담을 해서 미래에 하고 싶은 전문 분야를 파악하고, 흥미가 있는 부분들을 고려해서 프로젝트를 배치하는 것. 그리고 성장 가능한 업무를 던져 주는 것이 뿌듯한 것 같다. 질문을 많이 받는 것도 좋았다. 설명충이라서 그런가보다. 그들이 되고 싶은 것과 잘하는 것의 괴리를 보았을 때 어떻게 가이드를 해 줘야 하는지는 여전히 잘 모르겠지만... 아무튼 재밌다.

 

현 회사는 입사 이전부터 PR 리뷰 문화가 있어서 자연스럽게 검수 업무도 하게 되었다.

처음에는 내가 얼마나 잘 해줄 수 있을까라는 막연한 두려움이 있었는데, 그 연차에 겪는 이슈들은 대부분 동일하다는 게 재미있었다. 주로 성능적으로 문제가 될 수 있는 부분이나 설계 안정성, 그리고 유지보수성에 관한 조언을 줬던 것 같다.

 

PR의 경우 컨벤션이나 코드 스타일에 관해서는 크게 피드백을 주지 않고 있다. 작은 팀은 클린 코드에 집착하는 것보다는 추상화와 생산성에 집중하는 게 더 옳은 방식이라고 생각해 유지하고 있다.

 

 

라이브러리 만들기

독립적이고 회사 자산으로 남길 수 있는 코드들을 패키지화해서 공유하는 작업이었다. 이전 리드 개발자분의 MVVM 기반 라이브러리도 존재했지만, 적은 인원 규모 입장에서는 레이어 깊이를 유지하는 비용이 더 컸다. 그래서 팀 규모와 속도를 고려하여 의존성을 단순화한 아키텍처를 짜게 되었다. 실제로 개발 속도가 이전에 비해 급격하게 상승했고, 게임 개발의 근본적인 문제에 더 집중할 수 있게 되었다.

 

다만 특정 라이브러리는 여전히 작업 중이다. 모바일 도메인을 가진 사람이었다보니 콘솔 입출력 대응을 적용하는 데에 고통을 겪고 있다. 프로젝트 초기부터 잘 적용해놓는 게 중요하다는 것을 여실히 느끼는 중... 다음 프로젝트에서는 절대 대비해야지.

 

 

CI/CD 작업하기

생산성 있는 배포를 위해 젠킨스도 자주 건드리게 되었다. 파편화되어 있던 아이템을 하나의 워크플로우로 통합하는 등의 작업을 했다. 신규 프로젝트의 빌드 아이템을 생성하는 건 이제 꽤 자연스러워졌다.

 

 

백엔드 업무하기

설계까지 하는 것은 아니므로 딥하지는 않은데, 기존 라이브중인 프로젝트를 유지보수 해야 하는 경우가 있어 업무 바운더리에 들어왔다. 비용의 미학은 최적화 빌런인 나로서는 꽤나 흥미로운 부분이지만, 어떻게 하면 비용을 낮출 수 있는지에 대한 문제제기를 하는 것부터 막히기 때문에 2026년은 백엔드를 깊게 배우기로 정했다. 고통이야!

 

 

네트워킹 하기

진짜 못하는 부분이다. 맨 처음 부분에서도 써 뒀지만 스스로를 강해보이는 직책으로 표현하는 것이 어렵다...

어느 포지션을 취해야 하는지도 잘 모르겠어서 듣는 이의 입장을 취하고 있다. 앞으로 이런 기회가 더 늘어날 것 같은데 고민이다.

 

 

정리

결국 소규모 팀의 팀원 > 1인 개발자 > 소규모 팀의 리드 개발자라는 테크트리를 타게 되었는데, 실무보다는 관리 경험의 비율이 점점 더 늘어나고 있다고 느낀다. 기업이 잘 되는 방향으로 내가 강해지는 것도 좋지만, 주니어 개발자를 키우고 책임을 위임하는 것이 더 바람직하다는 것을 많이 느끼고 있다. 넓은 시야를 가짐으로서 성장하는 것은 정말 귀중한 경험인 것 같다.

 

별개로 년차에 비해 일찍 관리직으로 전환한 것이 아닌가에 대해서는 아직도 열등감이 남아 있다. 팀원으로 더 오래 남아 있으면 사수님의 코드를 보면서 더 넓은 시야를 가질 수 있지 않았을까 하는 불안감이다. 그런 만큼 더 다양한 코드를 의도적으로 읽고 개인 프로젝트를 주기적으로 돌리면서 감각을 잃지 말아야 한다는 생각이 든다. 사실 이런 생각도 팀원으로만 있었다면 얻지 못했을 것 같다. 열등감을 버리고 강해지자.

 

아무튼, 네가 선택한 기업이니 내가 강하게 키우겠다는 마음을 잃지 말고 정진하자.