University

Awake

대학교 졸업작품으로 제작한 액션 게임입니다. 12명 규모의 팀에서 팀장을 맡아 기획 전반을 담당했습니다.

Summary

Project Awake
Type Graduation Project
Engine Unreal Engine
Platform PC
Role Team Lead / Planning
Team 12

Development Process

1) Team Structure (팀 구성 및 역할 분담)

본 프로젝트는 총 17명으로 구성되었으며, 직군별 역할 분담을 기반으로 개발을 진행했습니다. 프로젝트 전체 운영(PD)과 기획(Game Design)은 본인이 수행했으며, 일정 수립부터 우선순위 관리, 커뮤니케이션 정리, 범위(Scope) 관리, 기획 문서화까지 프로젝트의 핵심 의사결정과 실행을 책임졌습니다.

2) Overall Workflow (전체 진행 흐름)

프로젝트는 사전기획 → 본개발 → 마감/폴리싱의 3단계로 진행했습니다. 팀 규모가 큰 편이었기 때문에 개발 중간에 방향을 자주 바꾸기보다는, 초기에 회의에서 합의된 목표와 범위, 제작 기준을 확정하고 이후에는 해당 결정을 중심으로 실행하는 방식으로 운영했습니다. 변경이 필요한 경우에도 임의로 수정하기보다 영향 범위를 정리한 뒤 회의를 통해 합의된 내용만 반영했습니다.

3) Planning & Task Management (기획 및 업무 관리 방식)

17명 규모에서 관리 부담과 커뮤니케이션 비용이 크게 발생할 수 있어, 회의 기반의 결정 체계와 명확한 업무 정리 방식을 중심으로 운영했습니다.

4) Collaboration & Communication (협업 및 커뮤니케이션)

대규모 팀 특성상 정보가 분산되면 일정 지연과 재작업이 발생할 수 있어, Discord(디스코드)를 메인 커뮤니케이션 도구로 사용하여 정보 흐름과 결정 사항을 일원화했습니다.

5) Version Control & Build Flow (버전 관리 및 빌드 흐름)

버전 관리 및 빌드 운영은 프로그래밍 파트에서 주도하여 진행했으며, 팀 전체가 동일한 규칙을 따를 수 있도록 기본 사용 가이드를 공유받아 협업에 적용했습니다.

Post-mortem

1) Bottlenecks Are Real (병목은 현실이다)

프로젝트를 진행하며, 팀 규모가 커질수록 개인이 의도한 방향대로 빠르게 움직이기 어렵다는 점을 체감했습니다. 의사결정과 실행이 회의 및 합의 과정을 거치면서 속도가 느려졌고, 특히 핵심 의사결정, 기획 확정, 통합 작업 등 특정 지점에 업무가 집중되며 병목이 반복적으로 발생했습니다. 결과적으로 대규모 협업에서는 인원 수 자체보다 병목 지점의 처리량과 결정 구조가 프로젝트 속도와 품질을 좌우한다는 점을 학습했습니다.

2) Prioritization Under Constraints (제약 속 우선순위 판단)

개발 중간에 인력 및 업무 변동이 발생하며 예정된 작업이 중단되거나 범위에서 제외되는 경우가 많았습니다. 그때마다 제한된 시간과 자원 안에서 무엇을 살리고 무엇을 포기할지 우선순위를 재정리해야 했고, 그 과정에서 많은 고민이 필요했습니다. 이 경험은 게임에 진짜 필요한 것이 무엇인지, 즉 핵심 재미와 필수 기능이 무엇인지 깊게 고민하게 만든 계기가 되었습니다. 이후에는 기능을 단순히 추가하기보다 목표 경험에 직접 기여하는 요소부터 완성도 있게 확보하는 방향으로 판단 기준을 정리할 수 있었습니다.

3) Team Mood Is a Production Factor (팀 분위기도 생산 요소다)

프로젝트를 진행하며 팀 분위기와 관계가 단순한 감정 문제가 아니라 실제 생산성과 일정에 직접 영향을 주는 리스크라는 점을 크게 느꼈습니다. 팀 내 일부 인원 간 갈등이 발생했을 때, 당사자끼리 직접 커뮤니케이션이 어려워져 업무 전달과 의사소통이 중간자(본인)를 거치는 구조로 바뀐 적이 있었습니다. 그 결과 사소한 확인도 핑퐁이 길어졌고, 조율 비용이 증가해 진행 속도에 부담이 발생했습니다. 이후 갈등이 원만히 정리되며 프로젝트 결과는 긍정적으로 마무리되었지만, 이 경험을 통해 소수 인원의 갈등만으로도 프로젝트 전체가 흔들릴 수 있다는 점을 학습했습니다.


따라서 다음 프로젝트에서는 초기부터 커뮤니케이션 규칙을 명확히 하고, 갈등이 발생했을 때 빠르게 정리할 수 있는 조율 방식과 안전장치를 마련하는 것이 중요하다고 판단했습니다.

4) Misaligned Goals Hurt the Product (동상이몽은 결과물을 흔든다)

팀원들이 같은 프로젝트를 하고 있어도, 각자가 생각하는 목표는 서로 달랐습니다. 모든 구성원이 "재미있는 게임을 완성하자"를 최우선 목표로 두기보다는, 개인 포트폴리오를 위해 특정 기술을 넣고 싶어 하거나 자신이 맡은 파트를 돋보이게 만들고자 하는 경우도 있었습니다. 이로 인해 제품 관점에서 우선순위가 분산되었고, 게임의 핵심 재미를 빠르게 다듬기보다 각자의 요구를 맞추는 과정에 조율 비용이 크게 발생했습니다. 결과적으로 기능의 방향성이 흔들리거나 재미가 선명해지기까지 시간이 오래 걸리는 구간이 있었고, "프로젝트 목표의 정렬"이 대규모 협업에서 얼마나 중요한지 체감했습니다.


다음 프로젝트에서는 초기 단계에서 팀의 최우선 목표를 명확히 합의하고, 기능 제안이 핵심 재미와 목표 경험에 직접 기여하는지 기준을 세워 검토하는 방식이 필요하다고 판단했습니다.

5) External Collaboration Was Valuable (외부 협업/외주는 의외로 큰 자산이다)

프로젝트 진행 중 성우, 사운드 디자이너 등 일부 작업을 외부 협업 형태로 진행했습니다. 해당 협업은 비용을 지불하는 방식이 아니라, 참여자 역시 포트폴리오 목적을 가진 형태였기 때문에 일반적인 외주와는 조건이 달랐습니다. 그럼에도 외부 인원과 협업하는 과정에서 요구사항을 명확히 전달하고, 결과물을 검수하며, 일정과 품질을 맞추는 커뮤니케이션 방식을 실제로 경험할 수 있었습니다.


특히 내부 팀원과 달리 외부 협업자는 프로젝트의 전체 맥락을 공유하지 않기 때문에, 작업 지시가 모호하면 결과물의 방향이 쉽게 달라질 수 있었습니다. 이에 따라 레퍼런스, 톤/스타일 가이드, 파일 규격, 납기, 수정 범위 등 기준을 정리해 전달하는 것이 중요하다는 점을 학습했습니다. 결과적으로 외부 협업은 단순히 리소스를 보강하는 수단을 넘어, 프로덕션 환경에서 필요한 협업 역량을 강화하는 경험이 되었으며, 이후 프로젝트에서도 적극적으로 활용할 수 있는 선택지라고 판단했습니다.

Contact

채용 및 협업 문의를 환영합니다. 해외 포지션도 검토 중이며, 레벨 디자인 외주/계약(프로젝트 단위)도 가능합니다. 레벨 디자인을 주력으로 하며, 시스템 기획과 프로토타이핑까지 수행 가능합니다.

Capabilities 가능 업무

  • Level Design 레벨 디자인 (Unity/Unreal)
  • System Design 시스템 기획
  • Unity prototyping 유니티 프로토타입 제작 (Claude Code 활용)
  • Unity / Unreal Engine 운용
  • 레벨 기믹/미션 배치/콘텐츠 제작 관련 업무

Background 플레이/경험

  • 콘솔/PC/모바일 포함 100+ 타이틀 플레이 경험.
  • 플레이 경험을 설계 관점으로 분석합니다.

100+는 엔딩 클리어 또는 랭크/숙련도 등 명확한 완료 기준을 충족한 타이틀만 집계했습니다.

해당 타이틀 목록은 별도로 정리되어 있으며, 필요 시 요청하시면 공유 가능합니다.