4년차 유니티 클라이언트 개발자 회고

 

1. 내가 느꼈던 답답함 정리

1. 연차 대비 체감 성장 속도에 대한 불안
   • 1년차: 시키는 대로 외우면서 작업
   • 2년차: 로컬 데이터 수정, 소규모 기능 추가
   • 3년차: 회사 프레임워크, 코드베이스가 익숙해짐
   • 4년차: 이제 와서야 “내가 뭘 모르는지”가 보이기 시작
     → “이거 너무 느린 거 아닌가?”라는 불안감
2. 게임 개발 ‘A~Z 풀사이클’ 경험 부족
   • 기획 → 시스템 설계 → 구현 → 폴리싱 → 빌드/배포 → 운영
     이걸 처음부터 끝까지 자기 손으로 책임지고 해본 경험이 거의 없음.
   • 특히:
     • “전형적인 RPG/방치형 게임에 들어가는 로직을 한 번 싹 구현해봤다”는 감각이 부족
     • 회사/기존 프로젝트 구조 위에 기능만 얹는 느낌이 강했음
3. CS/이론적인 베이스에 대한 콤플렉스
   • 알고리즘, 자료구조, 네트워크, OS, 메모리 등
   • “현업 경험은 쌓였는데, 말로/이론으로 설명하라 하면 허전한 느낌”
4. 팀장/선배와의 갭에서 오는 상대적 박탈감
   • 팀장은 “장르별로 게임이 어떻게 구현돼 있는지”를 감으로 알고 있고
   • “방치형이면 보통 드랍 이렇게, RPG면 이런 구조”를 바로 말하는데
     → 나는 아직 그런 “머릿속 카탈로그”가 없다 보니,
   • “난 왜 이렇게 모르는 게 많지?”라는 감정 강화

---

2. 객관적 위치 정리

1. 업계 평균 대비 느린 속도는 아니다. 오히려 건강한 편이다.
   • 3~4년차에도 “내 코드만 겨우 아는 사람” 많고,
   • 회사 프레임워크 철학이나 구조를 말 못하는 경우도 많음.
   • 반대로 나는:
     • 회사 프레임워크를 이해하려고 했고,
     • “장르별 시스템 구조”를 궁금해하고,
     • “내가 못하는 부분이 뭔지”를 구체적으로 말하고 있음.
2. 답답함 자체가 레벨업의 증거다.
   • 주니어 때는 “와 이 기능도 구현했네!”에서 끝나지만
   • 지금 나는:
     • “아직 A~Z를 못 돌려봤다”
     • “CS 기초 구멍이 보인다”
     • “장르별 설계 패턴을 모른다”
       → 이건 자기 객관화 수준이 올라간 중급으로 가는 길목에서 나오는 감정.
3. 문제는 ‘속도’가 아니라 ‘방향’이었다.
   • 지금까지는 주어진 환경(회사/프로젝트)이 정해준 방향 안에서 성장했다면,
   • 이제는 내가 직접 성장 방향을 설계해야 하는 타이밍이라서
   • 그 과도기에 “나 너무 느린 거 아니야?”가 터진 거라고 볼 수 있음.

---

3. 이 답답함을 풀기 위한 핵심 전략 4가지

해결책:

“진짜 A~Z를 한 번 끝까지 가보면서,
그 과정에 CS 기초/설계/멘토링을 얹어서 같이 올리는 1~2년을 만들자.”

 

조금 나눠 보면:

3-1. A~Z 사이드 프로젝트 1개 완주

• 장르: 전형적인 RPG or 방치형 (네가 말하던 바로 그 영역)
• 목표:
  기획 → 시스템 설계 → 구현 → 폴리싱 → 빌드/배포를 처음부터 끝까지 “내 머리로” 진행해보는 것.

경험할 루프:

1. 기획
   • A4 1장으로 게임 콘셉트/코어 루프 정리
2. 시스템 설계
   • 전투, 성장, 드랍, 퀘스트 중 핵심 시스템 골라 설계
   • 클래스 다이어그램/상태 흐름 대략이라도 그려보기
3. 구현
   • Unity에서 실제 클래스/매니저/데이터 구조로 녹이기
4. 폴리싱
   • 이펙트, UI, 튜토리얼, 난이도 곡선 손보기
5. 빌드/배포
   • itch.io / WebGL / 내부 테스트 정도로 내보내고 피드백 받아보기

이렇게 한 번 완주해야 “아 게임 하나가 이렇게 돌아가는구나”가 몸에 새겨진다.

---

3-2. CS 기초를 “게임 관점”에서 퍼즐 맞추듯 메꾸기

포인트는 “면접용 암기”가 아니라 실제 Unity/게임과 연결해서 이해하는 것.

다루기로 한 영역은:

• OS / 메모리
  • 값 타입 vs 참조 타입, 스택/힙, GC
  • 왜 new 남발하면 프레임 드랍 나는지
• 자료구조 / 알고리즘
  • List / Dictionary / Queue / Stack
  • 빅오 개념을 몬스터 수, 드랍 수, 인벤토리 수랑 연결해서 생각
• 네트워크
  • TCP/UDP, 딜레이/패킷 유실
  • 왜 보간/보정이 필요한지, 왜 위치 순간이동처럼 보이는지

 결국 목표는:

“이 코드가 느린/불안한 이유를 말로 설명할 수 있는 수준”

---

3-3. 기능/시스템마다 “A4 1장 설계 문서” 쓰는 습관

답답함의 큰 원인 중 하나가 머릿속에는 감각이 있는데, 문서로/언어로 정리된 적이 적다는 것도 있었음.

 

그래서:

• 새 기능 만들 때마다 최소 A4 1장 설계 요약:
  1. 기능/시스템 이름
  2. 목표 (유저 입장에서 한 줄)
  3. 유저 플로우 (화면/행동 순서)
  4. 시스템 플로우 (Manager/Controller 간 로직 흐름)
  5. 데이터 구조 (클래스 구조)
  6. 예상 이슈/엣지케이스

그리고 이걸:

• 팀장/동료/멘티에게 보여주고 피드백 받으면서
  → “아, 이런 설계 의도가 있었구나”를 남도 이해하게 만드는 연습.

이게 쌓이면:

“코드는 혼자 잘 짜는 사람”에서
“사람들과 공유 가능한 설계를 하는 사람”으로 넘어감
= 연구개발/리드 포지션으로 가는 핵심 역량.

---

3-4. 멘토링을 “내 머릿속 정리도 되는 구조”로 쓰기

• 학생들에게 설명할 때:
  • “코루틴은요…”가 아니라
  • “왜 여기서 코루틴을 쓰는 게 좋은 선택인지/나쁜 선택인지”까지 이야기해 보기
• 새로 이해한 CS 개념/설계 패턴을
  • 학생 기준으로 ‘쉽게’ 풀어보면서
  • 내 머릿속 개념도 더 단단하게 만드는 구조

남 가르치는 과정이 내 개념을 가장 깊게 이해하는 루트

---

4. 이 모든 걸 합친 “큰 그림”

요약하면 지금 상황은:

“나는 4년 동안 뭔가 해온 것 같은데,
막상 돌아보니 A~Z 게임 한 판도 못 끝낸 느낌이고,
이론/기초/장르별 패턴도 구멍이 있는 것 같아서 답답하다.”

앞으로 세운 방향은:

그래서 앞으로 1~2년은

1. RPG or 방치형 하나를 처음부터 끝까지 직접 만들고
2. 그 과정에 CS 기초, 설계 문서, 멘토링 정리를 끼워 넣어서
3. “실무형 중급 개발자”에서 “설계·연구개발 할 줄 아는 개발자”로 올라간다.

 

 

 

막연한 답답함보단 수치로 나타내고 정리하고 보완해나가자

결국 이 답답함은 해결해야 괜찮아지더라~~~~