.gif)
안영훈 포트폴리오 (상위 링크로 되돌아가기)
| 제목 | 평생 영업해주세요 |
|---|---|
| 개발 기간 | 2025.05.04 ~ 2026.02.25 (약 9개월) |
| 인원 | 5인 (기획 1명, 개발 3명, 아트 1명) |
| 깃허브 | ‣ |
| 장르 | 3D 시뮬레이션 |
| 개발 환경 | Unity 3D, C#, Github (Source Tree) |
| • 핵심 로직 | |
|---|---|
| 음식 주문 프로세스 아키텍처 설계 | ‘손님 - 주문 정보 - 음식 DB - 주문 확인 UI - 셰프 - 서빙’으로 이어지는 프로세스 파이프라인을 설계하고 그 중 손님부터 주문 확인까지 구현했습니다. |
| 손님 입장/퇴장 프로세스 구현 | 손님이 앉을 수 있는 테이블을 탐색하는 프로세스와 손님을 그룹으로 묶어 제어하는 프로세스 구현했습니다. |
| • 게임 플레이 및 콘텐츠 | |
| 테이블 관리 시스템 설계 | 맵 정보에 테이블과 좌석 위치를 매핑, 테이블 접근자 역할인 TableManager 구현, 테이블에 앉은 손님 그룹 정보를 관리했습니다. |
| 손님 객체 오브젝트 풀링 및 스포너 구현 | 손님 객체를 오브젝트 풀링하여 리소스를 줄이고 스포너로 감싸서 안전하게 제어했습니다 |
| • 버전 관리 / 협업 환경 세팅 주도 | |
| GitHub 기반 협업 환경 구축 | 프로젝트 초기 Unity, GitHub 환경 세팅을 주도하고 익숙하지 않은 팀원의 온보딩을 진행하여 원활한 협업 기반을 마련했습니다. |
| 패키지 매니저 병합 충돌 해결 | 협업 중 발생한 maifest.json 및 package-lock.json의 병합 충돌을 주도적으로 해결했습니다. 유니티 내부 패키지 트리에 대한 이해와 .gitattributes (merge=union) 드라이버 설정을 통해 팀원 간의 로컬 환경 종속성을 안전하게 동기화 했습니다 |
| 주기적인 아키텍처 온보딩 및 협업 리드 | 머지할 떄 발생할 수 있는 리스크를 줄이기 위해, 주기적인 코드 리뷰 회의를 주도 했습니다 |
| 게임 개발이 처음인 팀원이 제가 설계한 시스템 아키텍처 위에서 안전하게 작업할 수 있도록 오프라인 미팅을 통해 코드의 의도와 구조를 직접 설명하는 온보딩을 진행했습니다. 이를 통해 팀원의 기술적 이해도를 높이고 메인 브랜치에 작업물을 머지하고 프로세스를 연결하는 과정을 유연하게 만들었습니다. |
설계 상 일부 객체의 과도한 책임
| 문제 상황 | • 객체가 단일 책임 원칙을 따르고 있지 않습니다. 해당 설계를 예로 들면, visitorOrder가 foodDB에서 정보를 가져와 취합하고, 정보를 셰프에게 전달하는 두 가지 역할을 하고 있습니다. | | --- | --- | | 발생한 한계 | • 기능 간 높은 결합도로 유지 보수에 불리합니다. 예를 들어, foodDB의 데이터 구조를 수정했을 때, foodDB에 접근하는 기능 뿐만 아니라 데이터를 전달하는 기능도 수정해야만 하게 됩니다.
• 권한 범위의 의도치 않은 확장이 생길 수 있습니다.
예를 들어, 현재 구조에서 외부 객체가 주문 정보만을 참조하기 위해 visitorOrder를 호출할 경우 의도치 않게 visitorOrder가 가지고 있는 foodDB 접근 권한까지 가질 수 있습니다 | | 깨달음 및 개선 | 한 객체는 유지 보수 편의성과 코드 재사용성, 접근 권한 관리 등을 위해 되도록 한 가지 역할만 수행해야 합니다. 따라서 지금이라면 foodDB의 접근자 클래스를 따로 만들어 visitorOrder의 과중한 책임을 분산시킬 것입니다.
다만, 현실적인 개발 일정과 과도한 객체 생성으로 인한 불필요한 기능 분산에 주의해야 합니다. |
손님 객체의 상태 관리 미흡 - FSM 도입
PlzRestaurant/Plz Restaurant/Assets/Scripts/Visitor/Visitor.cs at main · YoungSi4/PlzRestaurant
| 문제 상황 | • 손님이 어떻게 제어되고 있는지 알기 어렵습니다 각 기능 자체는 독립적인 함수로 구현되어 있지만, 제어의 주체가 불명확하고 분산되어 있습니다. 해당 구조는 어느 기능이 어디서 호출되는지 일목요연 하게 알기 어렵고, 손님의 상태에 대해 확장하기 어렵습니다. | | --- | --- | | 발생한 한계 | • 유지 보수 및 확장성에 안 좋은 영향을 줍니다. • 손님의 현재 상태를 알기 어렵습니다. | | 깨달음 및 개선 | • FSM 도입 손님 객체에 state 변수를 추가하고, 손님의 FSM state를 정의한 구조체를 작성합니다. flag와 queue를 통해 손님의 다음 state를 결정합니다. (부연 설명: 외부의 다양한 객체와 이벤트에 의해 손님의 상태가 변화하고, 동시에 접근할 경우 온전히 행동하지 못하고 다음 상태로 전이하거나, 전이할 상태의 목록을 온전히 기록하지 못할 수 있으므로 queue를 활용하여 전이할 상태 목록을 대기 시켜둡니다. queue가 비어 있다면 idle 상태로 진입합니다.) 델리게이트를 통해 FSM state의 enter, update, exit 따라 수행할 action을 지정합니다. |