1. 팀 전체 회고
Keep — 계속 유지할 점
원활하고 적극적인 의사소통
팀원들이 문제와 진행 상황을 솔직하게 공유했으며, 이슈가 발생했을 때 즉시 보고하고 함께 해결했다. 요청 사항이 있을 경우 필요한 내용을 빠르게 전달했고, 요청을 받은 팀원도 신속하게 대응했다.
자신의 작업이 끝났을 때도 다른 팀원에게 도움이 필요한 부분이 있는지 먼저 확인하는 등 적극적으로 협업했다. 이러한 소통 방식은 프로젝트 진행 속도를 높이고, 문제를 장기간 방치하지 않도록 하는 데 도움이 되었다.
긍정적인 팀 분위기
팀원들이 서로의 의견을 존중하고 편안하게 의견을 제시할 수 있는 분위기가 유지되었다. 단순히 맡은 기능을 구현하는 것에 그치지 않고, 팀 전체의 완성도를 높이기 위해 함께 고민하는 태도가 돋보였다.
체계적인 기획과 문서화
기능을 바로 구현하기보다 필요한 로직을 먼저 체계적으로 정리한 후 코딩하려고 노력했다. 또한 FigJam을 활용해 기획 내용과 진행 상황을 문서화했으며, 변경 사항을 가능한 한 바로 기록했다.
이러한 문서화 방식은 팀원들이 프로젝트의 방향과 작업 내용을 공유하는 데 도움이 되었으므로 앞으로도 유지할 필요가 있다.
지속적으로 다음 목표를 설정하는 태도
정해진 목표를 달성한 뒤 작업을 바로 끝내기보다, 다음 개선 목표를 설정하고 새로운 내용을 배우려는 태도를 유지했다. 단순히 기능을 완성하는 것보다 프로젝트를 통해 더 많은 것을 학습하는 데 의미를 두었다.
Problem — 개선이 필요한 점
지나치게 촉박한 일정
일부 작업 일정이 야간 작업과 철야를 전제로 구성되었다. 그 결과 작업 후반부에 피로가 누적되었으며, 충분한 검토 없이 기능을 통합하거나 수정하는 상황이 발생했다.
앞으로는 예상치 못한 오류와 수정 시간을 고려해 일정을 더욱 보수적으로 설정할 필요가 있다.
불명확한 우선순위
필수 기능과 추가 기능의 우선순위가 명확하게 구분되지 않아, 세부 기능에 집중하는 동안 전체 구조나 핵심 기능의 안정성을 충분히 확인하지 못한 경우가 있었다.
프로젝트 초기에 다음과 같이 기능을 구분할 필요가 있다.
- 반드시 구현해야 하는 핵심 기능
- 시간이 남을 경우 구현할 추가 기능
- 이후 프로젝트에서 시도할 확장 기능
역할과 일정 분담의 세분화 부족
팀원별 담당 영역은 정해져 있었지만, 기능별 작업 범위와 완료 기준이 충분히 세분화되지 않았다. 이로 인해 기능 간 경계가 겹치거나 동일한 함수가 중복으로 작성되는 문제가 발생했다.
서로의 코드에 대한 이해 부족
각자가 자신의 담당 기능을 중심으로 작업하면서 다른 팀원의 코드 구조와 로직을 충분히 이해하지 못했다. 함수의 선언, 정의, 호출부가 서로 다르거나 매개변수가 일치하지 않는 문제가 발생했으며, Merge 이후에야 오류를 발견하는 경우도 있었다.
AI 활용 과정에서 발생한 코드 충돌
생성형 AI를 활용해 코드를 작성하면서 기존 프로젝트의 변수명, 함수 구조, 설계 방식과 맞지 않는 코드가 추가되기도 했다. 동일한 기능이 중복 구현되거나 서로 다른 코드 작성 방식이 혼재하면서 충돌 가능성이 높아졌다.
문제는 AI 사용 자체보다 생성된 코드를 프로젝트 구조에 맞게 검토하고 수정하는 과정이 부족했다는 점이다.
빌드 성공 이후의 실행 검증 부족
코드가 정상적으로 빌드되더라도 실제 실행 과정에서 기능이 누락되거나, 콘솔 출력이 밀리거나, 글자와 이미지가 사라지는 문제가 발생했다.
빌드 성공만으로 작업이 완료되었다고 판단하지 않고, 실제 게임 흐름에 따라 기능과 UI를 끝까지 테스트할 필요가 있다.
UI의 일관성 부족
초기 화면과 이후 화면 사이에 UI 디자인과 출력 방식의 통일성이 부족했다. 각 기능에서 개별적으로 출력 코드를 작성하면서 화면 구성과 간격이 서로 달라졌다.
건강 관리 부족
프로젝트 완성도를 높이기 위해 장시간 작업했지만, 철야와 과로로 인해 작업 효율이 오히려 낮아지는 문제가 있었다. 프로젝트 일정에는 작업 시간뿐만 아니라 휴식과 컨디션 관리도 포함되어야 한다.
Try — 다음 프로젝트에서 시도할 점
작업 일정을 세부적으로 작성하기
기능 단위뿐만 아니라 설계, 구현, Merge, 테스트, 수정 단계를 나누어 일정을 작성한다. 예상하지 못한 오류에 대응할 수 있도록 별도의 여유 시간도 확보한다.
기능의 우선순위를 명확하게 설정하기
프로젝트 초기에 핵심 기능과 추가 기능을 구분한다. 핵심 기능의 구현과 안정화를 완료한 이후에 추가 기능을 개발한다.
역할과 책임 범위를 구체적으로 정하기
담당 기능뿐만 아니라 다음 항목까지 사전에 결정한다.
- 기능의 입력값과 반환값
- 다른 클래스와의 연결 방식
- 함수와 변수의 명명 규칙
- 담당자가 수정할 수 있는 파일 범위
- 기능의 완료 기준
- 테스트 방법
정기적인 스크럼 진행하기
팀 분위기나 개인적인 친분에 의존하지 않고, 정해진 시간에 스크럼을 진행한다.
스크럼에서는 다음 내용을 공유한다.
- 어제 완료한 작업
- 오늘 진행할 작업
- 현재 발생한 문제
- 다른 팀원의 확인이나 도움이 필요한 사항
- Merge 예정 파일과 변경된 인터페이스
코드 의도를 명확하게 표현하기
다른 팀원이 코드를 이해할 수 있도록 함수명과 변수명을 명확하게 작성하고, 복잡한 로직에는 필요한 주석을 추가한다.
단순히 코드의 동작을 설명하는 주석보다 해당 구조를 선택한 이유와 주의해야 할 사항을 기록한다.
AI 코드를 프로젝트 규칙에 맞게 검토하기
AI 사용을 무조건 줄이기보다 생성된 코드를 다음 기준으로 검토한다.
- 기존 클래스 구조와 일치하는가?
- 동일한 기능이 이미 존재하지 않는가?
- 함수명과 변수명 규칙을 따르는가?
- 불필요한 매개변수나 include가 추가되지 않았는가?
- 다른 팀원의 코드와 충돌할 가능성이 없는가?
- 코드의 동작 원리를 직접 설명할 수 있는가?
브랜치와 Merge 절차 개선하기
기능별 브랜치를 적극적으로 활용하고, 정상적으로 작동하는 시점마다 커밋을 남겨 복구 지점을 만든다.
메인 브랜치에서 직접 문제를 해결하기보다 각 팀원이 자신의 브랜치에서 최신 메인 브랜치를 반영하고 충돌을 먼저 해결한 후, 테스트가 완료된 코드를 통합하는 방식을 사용한다.
공통 기능을 초기에 제작하기
UI 출력, 커서 이동, 아스키아트 출력 등 여러 기능에서 반복적으로 사용하는 코드는 프로젝트 초기에 공통 클래스로 제작한다.
공통 함수를 배포할 때는 함수의 역할, 매개변수, 반환값, 사용 예시를 함께 문서화한다.
실행 테스트 체크리스트 만들기
Merge 이후에는 다음 내용을 확인한다.
- 전체 프로젝트가 정상적으로 빌드되는가?
- 게임 시작부터 종료까지 진행할 수 있는가?
- 경험치와 레벨업이 정상적으로 적용되는가?
- 전투 결과와 보상이 정상적으로 반영되는가?
- 콘솔 화면이 밀리거나 잘리는 부분은 없는가?
- 한글과 특수문자가 깨지지 않는가?
- 아스키아트가 정상적인 위치에 출력되는가?
- 입력 대기와 화면 전환이 정상적으로 작동하는가?
철야를 전제로 하지 않는 일정 운영
주어진 시간 안에서 구현할 수 있는 최적의 완성도를 목표로 한다. 일정이 부족할 경우 핵심 기능을 우선 완성하고, 추가 기능의 범위를 조정한다.
Feel — 프로젝트를 마친 소감
과로한 부분은 있었지만 프로젝트 자체는 매우 즐거웠다. 팀원들과 함께 오류를 해결하고 하나의 게임을 끝까지 완성하는 과정에서 협업과 통합의 중요성을 배울 수 있었다.
특히 기능이 개별적으로 작동하는 것과 여러 기능이 결합된 하나의 완성된 게임으로 보이는 것은 다르다는 점을 체감했다. Merge와 구조 설계 과정에서 어려움이 많았지만, 직접 문제를 발견하고 해결한 경험이 이후 프로젝트를 진행할 수 있는 자신감으로 남았다.
2. 개인별 회고
주소리(본인) — UI 및 프로젝트 통합
Keep
FigJam을 활용해 기획 내용과 변경 사항을 바로 문서화한 점은 효과적이었다. 팀원 간 의사소통도 원활했으며, 문제 발생 시 즉시 공유하고 함께 해결할 수 있었다.
Problem
UI는 초기 기획 없이 구현을 시작할 경우 화면별 출력 방식이 달라지고 수정 범위가 커질 수 있다는 점을 확인했다. 또한 아스키아트와 한글 출력을 사용하면서 유니코드와 문자 인코딩 관련 문제가 발생했다.
의사소통이 원활한 팀원들과 함께했기 때문에 별도의 고정 스크럼 없이도 프로젝트를 진행할 수 있었지만, 모든 팀에서 동일한 방식이 가능하지는 않다. 따라서 개인적인 소통 능력이나 팀 분위기에 의존하지 않는 공식적인 소통 체계가 필요하다.
파일 충돌을 메인 브랜치에서 직접 해결하는 과정에서도 불필요한 수정과 재작업이 발생했다. 또한 작업 우선순위를 충분히 협의하지 않아 후반부에 작업이 집중되었고, 철야가 발생했다.
Try
다음 프로젝트에서는 전체 UI 레이아웃과 화면 전환 방식을 초기에 설계한다. 유니코드, 콘솔 문자 집합, 파일 인코딩 방식도 프로젝트 시작 단계에서 통일한다.
아스키아트 출력, 박스 그리기, 커서 이동과 같이 반복적으로 사용하는 함수는 초기에 제작한 후 사용법과 함께 팀원들에게 배포한다.
정해진 시간에 스크럼을 진행하고, 작업 시작 전에 기능의 우선순위를 팀원들과 협의한다. Merge 전에는 각 팀원이 자신의 브랜치에서 최신 메인 브랜치를 반영하고 충돌을 해결한 뒤, 정상 작동을 확인한 코드를 통합한다.
철야를 줄이고 주어진 시간 안에서 구현할 수 있는 최적의 완성도를 만드는 것을 목표로 한다.
이영빈 — 플레이어 시스템 구조
Keep
플레이어와 관련된 기능을 하나의 관리 구조로 통합하려고 고민한 점은 향후 유지보수성과 확장성을 높일 수 있는 방향이었다.
Problem
플레이어 클래스에 상태 데이터와 관련 기능이 과도하게 집중될 경우 클래스의 책임이 지나치게 커질 수 있다. 여러 기능이 플레이어 객체에 직접 접근하면서 코드가 여러 방향으로 뻗는 구조가 만들어질 가능성도 있었다.
브랜치를 충분히 활용하지 않을 경우 기능 수정 과정에서 기존 코드가 손상되거나 복구가 어려워질 수 있다.
Try
플레이어 클래스는 플레이어 객체가 직접 보유해야 하는 데이터와 기본 동작을 담당하도록 구성한다. 플레이어의 상태 출력, 경험치 처리, 장비 적용과 같은 관리 기능은 별도의 PlayerManager에서 담당하는 구조를 검토한다.
각 시스템이 서로 직접 참조하는 구조를 줄이고, 시스템 사이의 요청을 중계하는 매니저나 인터페이스를 설계한다.
기능별 브랜치를 적극적으로 활용하고, 하나의 함수에 여러 책임이 집중되는 문어발식 코드를 줄인다.
아트, 음악 등 제작 비용이 큰 비프로그래밍 리소스에는 생성형 AI를 적극적으로 활용하되, 저작권과 사용 조건을 확인하고 프로젝트의 전체 콘셉트에 맞게 수정한다.
정윤재 — 인벤토리·상점·강화·제작 시스템 및 게임 기획
Keep
인벤토리, 상점, 강화소, 제작소 등 여러 시스템을 연결하면서 기능 간 데이터 전달과 클래스 의존 관계를 직접 경험했다.
게임의 핵심 메시지를 ‘코더여, 성장하라’로 설정하고, 스토리와 시스템이 동일한 메시지를 전달하도록 구성하려고 한 점도 의미가 있었다. 이는 광고, 홍보, 게임 콘텐츠 등 여러 요소가 일관된 메시지를 전달하는 IMC 관점과도 연결할 수 있다.
Problem
함수의 매개변수가 Player* player, Inventory& inventory와 같이 여러 개로 늘어나면서 다른 클래스와 파일을 참조해야 하는 상황이 많아졌다. 이 과정에서 include 누락, 전방 선언, 타입 불일치 등 여러 오류가 발생했다.
기존 템플릿 인벤토리를 설계할 때 장착 아이템까지 충분히 고려하지 않아 이후 장비창과 전용 장비 인벤토리를 별도로 구현해야 했다. 초기 설계가 부족해 기능이 추가될수록 구조가 복잡해졌다.
현재 게임의 주요 소재가 내일배움캠프 언리얼 10기 구성원에게 맞춰져 있어, 다른 사용자가 게임을 플레이할 경우 상황과 유머에 공감하기 어렵다는 한계가 있다.
Try
함수를 작성하기 전에 반드시 필요한 매개변수인지 검토하고, 여러 객체를 반복적으로 전달해야 한다면 해당 객체를 관리하는 상위 매니저나 컨텍스트 구조를 도입하는 방안을 고려한다.
인벤토리를 설계할 때 일반 아이템, 소비 아이템, 장착 아이템, 장착 슬롯, 강화와 제작 기능까지 확장될 가능성을 먼저 검토한다. 세부 기능을 구현하기 전에 전체 클래스 구조와 데이터 흐름을 먼저 설계한다.
게임의 소비층을 특정 교육 과정 참여자뿐만 아니라 코딩을 처음 배우는 사용자 전체로 확장한다. 이를 위해 특정 기수나 내부 상황에만 의존하는 표현을 줄이고, 초보 개발자라면 공감할 수 있는 오류, 과제, 디버깅, 성장 경험을 중심으로 스토리를 개편한다.
박성빈 — 전투 시스템 및 브랜치 관리
Keep
전투 시스템에 새로운 기능을 추가할 때 GitHub Desktop에서 별도의 브랜치를 생성하고, 정상적으로 작동하는 시점마다 커밋을 남겨 복구 지점을 만든 점이 효과적이었다.
오류가 발생하더라도 이전의 정상 상태로 쉽게 돌아갈 수 있어 수정에 대한 부담을 줄일 수 있었다.
Try
앞으로도 기능별 브랜치를 사용하고, 하나의 기능이 정상적으로 작동하는 시점마다 의미 있는 커밋을 남긴다.
커밋 메시지에는 변경한 기능과 확인해야 할 사항을 구체적으로 작성하고, Merge 전에는 해당 브랜치에서 빌드와 실행 테스트를 완료한다.
장우혁 — 경험치 및 레벨업 시스템
Keep
GainExp 함수에서 외부로부터 전달받은 경험치를 현재 경험치에 누적하고, while문을 사용해 한 번에 여러 레벨이 상승하는 경우에도 레벨업이 누락되지 않도록 구현했다.
또한 클래스 간 순환 참조를 방지하기 위해 전방 선언을 활용했다.
콘솔 출력이 너무 빠르게 넘어가 확인하기 어려운 경우 입력 대기나 일시정지 기능을 사용해 출력 내용을 확인할 수 있도록 한 시도도 효과적이었다.
Problem
Merge 과정에서 경험치와 레벨업 관련 코드가 일부 누락되거나 연결이 변경되면서 프로젝트는 빌드되지만 실제 게임에서 레벨업 메시지나 기능이 나타나지 않는 문제가 발생했다.
오류를 수정한 뒤 빌드 성공 여부만 확인하고 실제 게임 흐름을 충분히 테스트하지 않아 문제를 늦게 발견했다. 이후 게임을 처음부터 반복 실행하며 경험치 획득과 레벨업 과정을 하나씩 확인해야 했다.
Try
Merge 전후에 경험치와 레벨업 관련 함수의 선언, 정의, 호출부가 모두 정상적으로 연결되어 있는지 확인한다.
오류를 수정한 뒤에는 반드시 다시 빌드하고, 게임을 직접 실행해 다음 사항을 검증한다.
- 경험치가 정상적으로 누적되는가?
- 한 번에 여러 레벨이 상승하는가?
- 레벨업 보상이 정상적으로 적용되는가?
- 레벨업 메시지가 화면에 출력되는가?
- 콘솔 출력이 밀리거나 사라지지 않는가?
- 한글과 아스키아트가 깨지지 않는가?
빌드 성공은 문법과 연결 오류가 없다는 의미일 뿐, 기능이 정상적으로 작동한다는 의미는 아니라는 점을 항상 인식한다.
Feel
이번 프로젝트를 통해 Merge 과정에서 예상보다 많은 충돌과 기능 누락이 발생할 수 있다는 점을 체감했다. 오류를 모두 수정한 것처럼 보여도 실제 실행 과정에서는 추가 문제가 나타날 수 있으므로, 빌드 이후의 플레이 테스트가 반드시 필요하다는 것을 배웠다.
이미르 — 몬스터 및 전투 시스템
Keep
몬스터 시스템을 처음부터 끝까지 구현하고 지속적으로 수정했다. 정예 몬스터가 각 챕터에서 한 번씩만 등장하도록 조건을 구성했으며, 최종 보스전을 두 명의 매니저와 보스가 대결하는 2대1 전투 구조로 구현했다.
팀원들과 적극적으로 소통하며 오류를 함께 해결했고, 발표를 통해 프로젝트와 자신이 구현한 기능에 대한 자신감을 얻었다.
Problem
Merge 과정에서 충돌과 오류가 많이 발생했다. 함수의 선언, 정의, 호출부에서 매개변수가 서로 일치하지 않는 문제가 있었으며, 동일한 함수가 중복으로 작성되어 오류가 발생하기도 했다.
시작 화면과 이후 화면의 UI가 통일되지 않았으며, 세부 기능 구현에 집중한 나머지 전체 구조를 충분히 기획하지 못했다.
Try
다음 프로젝트에서는 세부 기능을 구현하기 전에 전체 클래스 구조와 데이터 흐름을 먼저 정리한다.
함수의 매개변수를 최소화하고, 반복적으로 전달되는 데이터는 매니저나 별도의 데이터 구조를 통해 관리한다.
UI 출력 기능을 별도의 클래스로 분리하고, 모든 화면이 동일한 규칙으로 출력되도록 구성한다.
변수명과 함수명 규칙을 사전에 정하는 것에 그치지 않고, 코드 리뷰 과정에서 실제로 규칙이 지켜지고 있는지 확인한다.
전투 시스템을 확장할 경우 다음과 같은 기능도 시도한다.
- 파티 시스템
- 공격 빗나감과 명중률
- 상태 이상
- 캐릭터별 역할 구분
- 행동 순서와 우선순위
- 자원 관리가 필요한 전략적 전투
Feel
이번 프로젝트를 통해 기능이 정상적으로 작동하는 것과 게임이 완성도 있게 보이는 것은 서로 다른 문제라는 점을 느꼈다.
초보자로서 Merge와 전체 구조 설계가 어려웠지만, 실제로 오류를 경험하고 직접 해결하면서 많은 것을 배울 수 있었다. 팀원들과 소통하며 프로젝트를 끝까지 완성한 경험이 다음 프로젝트에 도전할 수 있는 자신감으로 남았다.
3. 종합 결론
이번 프로젝트의 가장 큰 강점은 적극적인 의사소통과 문제 해결 태도였다. 팀원들은 자신의 담당 기능에만 머무르지 않고, 문제가 발생하면 함께 원인을 찾고 해결했다.
반면 가장 큰 개선 과제는 초기 구조 설계, 일정 관리, 코드 통합 절차였다. 개별 기능은 정상적으로 구현되었지만, 여러 기능을 하나의 프로젝트로 통합하는 과정에서 클래스 의존성, 함수 인터페이스, UI 일관성, 실행 테스트 문제가 나타났다.
다음 프로젝트에서는 다음 원칙을 우선적으로 적용한다.
- 구현 전에 전체 구조와 데이터 흐름을 먼저 설계한다.
- 핵심 기능과 추가 기능의 우선순위를 구분한다.
- 일정에 Merge, 테스트, 수정 시간을 별도로 포함한다.
- 정기적인 스크럼을 통해 변경 사항과 문제를 공유한다.
- 공통 함수와 코딩 규칙을 초기에 확정한다.
- AI가 작성한 코드도 팀의 구조와 규칙에 맞게 직접 검토한다.
- Merge 전후에 빌드뿐만 아니라 실제 플레이 테스트를 진행한다.
- 철야를 전제로 하지 않고 지속 가능한 작업 범위를 설정한다.
이번 프로젝트는 단순히 게임 기능을 구현한 경험을 넘어, 협업 개발에서 설계와 소통, 버전 관리, 통합 테스트가 얼마나 중요한지를 학습한 프로젝트였다.
댓글 업로드 중....