회고록

Keep - 현재 만족하고 있는 부분

• 서승우 - 팀원 간 의견을 조율하는 과정이 원활했고, 결정해야 할 상황에서도 서로의 아이디어를 존중하며 합리적인 방향으로 빠르게 결론을 내릴 수 있었던 점이 인상 깊었음.
• 이찬호 - 프로젝트 구조가 파트별로 명확하게 폴더로 분리되어 있어 본인의 역할에 집중하기 쉬웠고, 코드 탐색이나 유지보수 시에도 불필요한 혼란이 없어서 효율적인 작업이 가능했음.
• 주상돈 - 기능 구현 중 막히는 부분이 생겼을 때 혼자 고민하기보다 팀원들과 적극적으로 커뮤니케이션을 통해 해결해 나가는 분위기가 잘 형성되어 있어 전체적으로 작업 흐름이 부드러웠음.
• 김재혁 - AI 시스템의 구성에서 상태 기반 FSM 구조와 블랙보드 연동이 잘 작동했으며, 서비스 노드와 태스크 노드의 역할이 명확하게 나뉘어 있어 복잡한 로직도 깔끔하게 관리할 수 있었음.
• 송정훈 - 어빌리티 시스템으로 능력 관리와 서버 로직 분리화 시킨 점. 쉽게 확장 가능한 GrabSystem 구축. 반 물리 기반 캐릭터 구현.

Problem - 불편하게 느끼는 부분

• 서승우 - 여러 번 발생한 커밋 충돌로 인해 작업 내용이 유실되거나 되돌리는 과정에서 중복 작업이 생겼고, 해당 문제를 해결하는 데 불필요한 리소스가 사용되었던 점이 아쉬웠음.
• 이찬호 - 초기 계획대로 진행되지 않았을 경우, 이를 뒷받침할 수 있는 예비 대응 방안이 부족했다는 점이 느껴졌고, 그로 인해 작업 우선순위 조정이 어렵거나 일정 지연으로 이어지는 일이 발생했음
• 주상돈 - 커밋 충돌이나 병합 과정에서 예상치 못한 충돌이 발생해 작업 흐름이 끊기는 일이 반복되었고, 그로 인해 본인이 맡은 기능 구현이 지체된 경험이 있었음.
• 김재혁 - AI 구조 설계에서 Tick 기반 처리 구조가 많다 보니 성능 저하에 대한 우려가 있었고, 특히 회전 보간 처리(RInterpTo 등)가 상황에 따라 너무 빠르거나 느려서 동작이 어색하게 보이는 경우가 있었음.
• 송정훈 - 서버 검증 로직이 부족했으며, 멀티플레이 기반 시스템 설계를 하지 않아서 급하게 수정하다 구조의 틀이 깨져 확장성이 떨어진 점. 서버와 클라이언트간 피직스 시뮬레이트 문제를 완벽하게 해결하지 못한 점.

Try - Problem에 대한 해결책, 당장 실행 가능한 것

• 서승우 - 커밋을 진행하기 전 변경된 파일 목록을 꼼꼼히 점검하고, 충돌 가능성이 있는 작업에 대해서는 미리 백업 커밋을 만들어두는 습관을 통해 작업 유실을 방지하고자 함.
• 이찬호 - Git의 에셋 잠금 기능(예: Perforce 스타일)을 활용하여 중요 리소스 충돌을 예방하고, 작업 전에 간단한 알림이나 예약 시스템을 통해 타인의 작업을 미리 공유함으로써 충돌 가능성을 낮출 계획
  4.1 파일 잠금 (File Locking)
• 주상돈 - 커밋 단위를 더 작게 쪼개 자주 커밋함으로써 충돌 발생 가능성을 줄이고, 작업 전후 간단한 Sync 미팅을 통해 서로의 작업 상황을 공유하는 루틴을 만들 계획.
• 김재혁 - Tick 사용을 줄이고 필요한 정보는 BeginPlay나 초기화 시점에 캐싱하며, 반복 처리나 딜레이가 필요한 부분은 FTimerHandle 기반으로 전환하여 자연스러운 흐름과 성능 개선을 동시에 노림.
• 송정훈 - 시스템 분리 구조를 더 명확하게 나누어 각 기능의 책임을 분리해 역할 충돌이나 중복을 방지하고, 동작에 대한 시나리오를 먼저 짜 추가 요소가 도중에 끼어들지 않도록 기존 구조는 유지하되 인터페이스나 추상 클래스를 좀 더 활용해 확장을 유도하는 설계 스타일.
• 공통 - 기능 단위 작업을 시작할 때 간단하게 작업 기준이나 구현 방향을 문서화해 두고, Notion 등을 활용해 공유함으로써 작업 간 해석 차이를 줄일 수 있도록 함
• 공통 - Discord/Slack 등 협업 툴을 통해 매일 작업 시작 전/후 간단한 공유 루틴을 만들고, 누구의 어떤 작업이 언제 들어가는지를 항상 투명하게 유지할 계획