[DAY49] Team Project Guide

성공적인 팀 프로젝트는 코드를 작성하기 전, 명확한 규칙을 정하는 단계에서부터 시작된다. 프로젝트의 목표와 방향성을 통일하고, 체계적인 개발 및 소통 규칙을 수립해야 추후 발생할 수 있는 수많은 비효율과 갈등을 예방할 수 있다. 이는 단순히 좋은 결과물을 넘어, 팀원 모두가 만족하는 협업 경험을 만드는 가장 확실한 방법이다. 🚀

---

📖 단계별 규칙

1. 프로젝트 방향성 정렬

• 목표 설정: '완성형 게임'을 지향할지, '핵심 기능 중심의 프로토타입'을 목표로 할지 명확히 합의해야 한다. 프로젝트의 범위와 깊이를 결정하는 가장 중요한 단계이다.
• 경험 중심 기획: "어떤 기능을 구현할까?"보다 "플레이어에게 어떤 경험을 줄 것인가?"를 먼저 고민해야 한다. 이 접근법은 개발 우선순위를 자연스럽게 정립하고 기획 리스크를 줄여준다.
• 유사 게임 분석: 벤치마킹할 게임을 정해 팀원들과 함께 플레이해보고, 장단점과 차별화 포인트를 정리하여 프로젝트의 방향성을 구체화한다.

2. 개발 환경 및 규칙 정의

• 아키텍처 설계: 본격적인 개발에 앞서 기능의 전체적인 흐름을 담은 소프트웨어 아키텍처 다이어그램을 작성한다. 이는 복잡한 기능 구현 시 발생할 수 있는 스파게티 코드를 방지하는 설계도 역할을 한다.
• 네이밍 컨벤션: 모든 에셋과 파일에 일관된 명명 규칙을 적용한다. 언리얼 엔진 공식 문서를 기반으로 하되, 팀의 특성에 맞는 접두사 규칙을 추가하여 가독성을 높인다.
  • 예시: BP_Character_Player, W_Lobby_Main
• Git 사용 원칙:
  • 1일 1커밋/푸시: 코드 유실 방지와 지속적인 동기화를 위해 최소 하루에 한 번 이상 커밋하고 푸시하는 것을 원칙으로 한다.
  • PR(Pull Request) 기반 작업: main 브랜치에 직접 푸시하는 것을 금지한다. 모든 코드 변경은 PR을 통해 코드 리뷰를 거친 후 병합(Merge)하여 코드 품질을 높이고 치명적인 충돌을 예방한다.
  • 커밋/PR 메시지 템플릿 통일: 정해진 양식에 맞춰 메시지를 작성하면 변경 이력을 추적하기 용이하다.
• 기술 부채 기록: 임시로 처리한 코드, 하드코딩된 값, 미해결 버그 등 '나중에 해결해야 할 문제들'을 Notion 같은 공간에 반드시 기록하고 공유해야 한다.

3. 협업 및 소통 전략

• 스크럼 진행: 최소 주 2회 전체 스크럼 미팅을 진행하고, 매일 짧게 각자의 진행 상황과 문제점을 공유하는 데일리 스탠딩 미팅을 통해 팀의 진행 속도를 조율한다.
• Issue Tracking: Notion의 칸반 보드나 Trello를 사용해 할 일, 진행 중, 완료 상태를 시각적으로 관리한다. 이를 통해 누가 어떤 작업을 하고 있는지, 병목이 발생하는 부분은 없는지 쉽게 파악할 수 있다.
• 모든 것을 기록하기: 회의록, 기획서, 스크럼 내용, 기술 부채 등 모든 논의와 결정 사항은 공유된 문서(Notion 등)에 기록하여 투명성을 확보한다.
• 도움 요청 문화: 막히는 문제를 혼자 오래 붙잡고 있는 것은 팀 전체에 손해다. 일정 시간 이상 해결되지 않는 문제는 즉시 팀에 공유하여 도움을 요청하는 문화를 조성해야 한다.

---

⚠️ 흔히 저지르는 실수

• 규칙 없는 시작: "알아서 잘하겠지"라는 생각으로 프로젝트 초기에 명확한 규칙을 정하지 않으면, 나중에 뒤섞인 네이밍 컨벤션과 잦은 코드 충돌을 수습하는 데 더 큰 비용이 든다.
• 추상적인 공유: "거의 다 됐어요"와 같은 모호한 보고는 팀의 오해를 낳는다. 실제 플레이 영상, 스크린샷, 문서 기록 등 시각적인 결과물로 진행 상황을 공유하는 것이 훨씬 효과적이다.
• PR 없는 직접 Push: 동료의 리뷰 없이 코드를 main 브랜치에 직접 병합하는 것은 다른 사람의 작업을 덮어쓰거나 심각한 버그를 유발하여 팀 전체의 작업을 중단시킬 수 있는 매우 위험한 행동이다.

---

✅ 핵심 요약

개념	설명	비고
WBS 및 마일스톤	주차 단위로 상세한 목표(v0.1-alpha 등)를 설정하고 관리하는 방식.	Notion 캘린더 등으로 시각화하면 효율적.
네이밍 컨벤션	에셋, 파일, 변수 등의 이름을 정하는 규칙.	팀의 코드 가독성을 높이는 기본 약속.
PR (Pull Request)	코드 변경사항을 main 브랜치에 병합하기 전 팀원에게 리뷰를 요청하는 과정.	코드 품질 향상 및 충돌 사전 방지.
기술 부채	임시방편으로 작성한 코드나 잠재적인 버그 등 미래에 해결해야 할 문제들.	반드시 별도 공간에 기록하고 추적해야 함.
스크럼	주기적인 미팅을 통해 진행 상황, 계획, 문제점을 공유하는 협업 방식.	팀의 병목 현상을 조기에 발견하는 데 유용함.