MFC-B01 | MFC-Crazy-Arcade — 타일 배치를 맡으며 처음 경험한 팀 프로젝트 역할 분담

이 글에서 확인할 내용

MFC-Crazy-Arcade는 제가 처음으로 팀 안에서 역할을 나눠 진행한 프로젝트입니다.

제가 맡았던 중심 역할은 타일 배치와 맵 구성 흐름이었습니다.

처음에는 "내가 맡은 기능만 잘 만들면 된다"고 생각하기 쉬웠습니다. 하지만 실제로는 Tool에서 고른 타일 값이 Terrain 데이터에 반영되고, 다른 화면과 Client 결과까지 이어져야 했기 때문에 제 작업만 따로 떼어 볼 수 없었습니다.

이 글에서는 세부 Class 설명보다, 첫 팀 프로젝트에서 제가 어떤 역할을 맡았고, 그 역할이 팀 전체 결과물 안에서 어떻게 연결되었는지를 중심으로 정리합니다.

혼자 만들 때와 달랐던 점

이전 WinAPI-Isaac은 개인 프로젝트였습니다.

어떤 기능을 먼저 만들지, 어디를 수정할지, 문제가 생기면 어디부터 볼지 대부분 혼자 결정할 수 있었습니다.

팀 프로젝트는 달랐습니다.

제가 맡은 기능이 동작하더라도 팀 전체 결과물 안에서 연결되지 않으면 끝난 것이 아니었습니다.

예를 들어 타일 배치만 봐도 다음 흐름이 맞아야 했습니다.

Tool에서 타일 선택
↓
입력으로 배치
↓
Terrain 데이터 변경
↓
화면에서 결과 확인

여기서 Tool은 맵을 편집하는 화면이고, Terrain 데이터는 어떤 타일이 어느 위치에 놓여 있는지를 실제로 들고 있는 값이라고 보면 됩니다.

겉으로는 작은 기능처럼 보여도, 중간에 사용하는 값과 데이터가 서로 맞아야 했습니다.

이때 처음으로 "기능 하나를 만든다"는 말이 팀 프로젝트에서는 생각보다 넓은 의미라는 걸 느꼈습니다.

프로젝트 안에서 내가 맡은 역할

이 프로젝트에서 전체 MFC Tool이나 Client를 혼자 만든 것은 아닙니다.

팀원들과 역할을 나눴고, 제가 맡은 중심 범위는 타일 배치와 맵 구성 흐름이었습니다.

제가 경험한 흐름을 단순하게 정리하면 다음과 같습니다.

현재 사용할 타일 선택
↓
맵 위에 배치
↓
배치 결과가 Terrain 데이터에 반영
↓
main view / minimap에서 결과 확인

main view는 실제 맵을 편집하는 화면이고, minimap은 같은 맵을 축소해서 확인하는 화면입니다.

당시에는 그냥 "타일을 찍는다"고 생각했습니다.

지금 다시 보면 사용자가 선택한 값이 입력을 거쳐 데이터에 반영되고, 같은 데이터를 여러 화면에서 확인하는 흐름이었습니다.

중요했던 것은 Class 이름을 많이 아는 것이 아니라, 내가 맡은 작업이 어디에서 시작해서 어디까지 영향을 주는지 확인하는 것이었습니다.

역할 범위를 구분해서 보는 이유

지금 포트폴리오를 정리하면서는 당시 작업을 더 크게 보이게 만들기보다, 제가 맡은 범위와 팀 전체 구조를 구분해서 설명하려고 합니다.

제가 맡은 것은 타일 배치와 맵 구성 흐름이었고, 프로젝트 전체 Tool 구조와 Client의 모든 기능을 혼자 구현한 것은 아닙니다.

이 구분은 단순히 표현을 조심하기 위한 것이 아닙니다.

팀 프로젝트에서는 내가 만든 코드와 다른 사람이 만든 코드가 연결되어 하나의 결과가 나오기 때문에, 나중에 프로젝트를 설명할 때도 다음 두 가지를 나누어 보는 것이 중요하다고 생각합니다.

내가 직접 맡은 범위
 
vs.
 
팀 전체가 함께 만든 결과

MFC-Crazy-Arcade는 제가 이 차이를 처음 경험한 프로젝트였습니다.

역할 분담에서 처음 배운 것

개인 프로젝트에서는 내가 바꾼 코드가 곧 내 결과물입니다.

하지만 팀 프로젝트에서는 같은 파일이나 같은 데이터를 다른 기능도 사용할 수 있습니다.

그래서 단순히 "내 부분은 끝났다"고 보기 어려웠습니다.

작업하면서 계속 확인해야 했던 것은 이런 부분이었습니다.

내가 맡은 범위가 어디까지인가?
 
어떤 값이 다른 기능과 연결되는가?
 
내 작업 결과를 다른 팀원이 어디에서 사용하는가?
 
하나로 합쳤을 때 화면 결과가 정상인가?

당시에는 이런 질문을 지금처럼 정리해서 생각하지는 못했습니다.

그래도 첫 협업을 하면서 역할을 나누는 것과 결과물을 하나로 합치는 것은 서로 다른 문제라는 점을 직접 경험했습니다.

역할 분담은 각자 할 일을 정하는 시작점이었고, 실제 프로젝트에서는 그 작업들이 다시 연결되어야 했습니다.

내가 맡은 기능도 혼자 끝나지 않았습니다

타일 배치 흐름도 혼자 독립적으로 끝나는 기능이 아니었습니다.

Tool에서 선택한 값이 실제 데이터에 들어가고, 그 결과가 화면에 반영되어야 했습니다.

또 프로젝트 전체 흐름에서는 저장된 맵 데이터와 Client 결과까지 이어졌습니다.

지금 기준으로 단순화하면 다음과 같습니다.

Tool
→ Tile Data
→ Map Data
→ Client Terrain

이 구조를 경험하면서 "내가 맡은 화면에서 잘 보인다"는 것과 "팀 전체 결과물에서 정상적으로 사용된다"는 것은 다를 수 있다는 점을 알게 됐습니다.

그래서 기능을 확인할 때도 내 작업 화면만 보는 것이 아니라, 다음 단계에서 그 값을 누가 사용하고 최종적으로 어떤 결과가 나오는지를 같이 보게 됐습니다.

기능 통합에서 중요했던 부분

이 프로젝트를 다시 보면서 가장 분명하게 느낀 점은, 기능 통합이 마지막에 코드를 한 번 합치는 작업만은 아니라는 것입니다.

처음부터 어떤 값이 기준인지, 그 값이 어디에서 바뀌고 어디에서 다시 사용되는지를 알아야 문제를 찾기 쉬웠습니다.

타일 배치 흐름을 기준으로 보면 다음이 연결되어야 했습니다.

선택한 타일
↓
Terrain의 TILE 데이터
↓
저장된 Map Data
↓
Client에서 사용하는 Terrain

이 중간 흐름이 어긋나면 마지막 화면에서는 기대한 결과가 나오지 않을 수 있습니다.

이 경험은 이후 DirectX 프로젝트를 할 때도 영향을 줬습니다.

기능을 볼 때 "어떤 Class가 있는가"보다 어떤 데이터가 어디에서 바뀌고 다음에 누가 읽는가를 더 의식하게 됐습니다.

첫 협업에서 남은 경험

MFC-Crazy-Arcade에서 가장 크게 남은 것은 화려한 기능이 아니라 첫 협업 경험이었습니다.

팀 안에서 역할을 맡고, 제가 만든 결과를 다른 작업과 맞추고, 최종 화면에서 제대로 이어지는지 확인하는 과정을 처음 겪었습니다.

특히 혼자 만들 때와 달리 다음 부분이 중요했습니다.

• 내가 맡은 범위를 명확히 아는 것
• 진행 상황을 다른 팀원과 공유하는 것
• 같은 데이터와 결과를 기준으로 확인하는 것
• 문제가 생기면 내 코드만 보지 않고 연결 지점을 같이 보는 것

지금 보면 기본적인 내용이지만, 처음 팀 프로젝트를 경험할 때는 이 차이가 크게 느껴졌습니다.

또 이때부터 "내가 무엇을 만들었는가"만큼이나 내 작업이 전체 프로젝트 안에서 어디에 위치하는가를 설명할 수 있어야 한다는 감각도 조금씩 생겼습니다.

Runtime

당시 팀 프로젝트의 결과는 아래 영상에서 확인할 수 있습니다.

MFC C++ Crazy Arcade

이 영상은 현재 대표 프로젝트의 기술 깊이를 증명하기 위한 자료라기보다, 처음 역할을 나눠 하나의 게임 결과물을 만들었던 당시 경험을 확인할 수 있는 기록입니다.

영상에서는 MFC-Crazy-Arcade가 실제 게임 결과물로 동작했던 당시 모습을 확인할 수 있습니다.

다음 프로젝트에서 달라진 점

이 경험 이후 진행한 DX9-Cat-Quest에서는 팀 프로젝트 안에서 캐릭터, 몬스터, 스킬, 상호작용처럼 Runtime Gameplay 영역을 더 많이 맡게 됐습니다.

MFC-Crazy-Arcade에서 처음 겪었던 역할 분담과 기능 연결 경험 덕분에, 다음 프로젝트에서는 단순히 "내 기능이 동작하는가"만 보지 않고 다른 시스템과 어디에서 만나는가도 같이 보려고 했습니다.

이후 DX11과 Unreal 프로젝트를 정리할 때도 같은 기준이 이어졌습니다.

내가 맡은 범위
↓
사용하는 데이터
↓
다른 기능과 만나는 지점
↓
Runtime 결과

첫 팀 프로젝트였기 때문에 당시 구조가 완벽했던 것은 아닙니다.

하지만 혼자 만드는 방식에서 벗어나, 팀 안에서 역할을 맡고 기능을 맞춰가는 개발 방식을 처음 경험했다는 점에서 다음 단계로 넘어가는 데 중요한 프로젝트였습니다.

정리

MFC-Crazy-Arcade에서 저는 타일 배치와 맵 구성 흐름을 맡았습니다.

처음에는 역할을 나눠 각자 기능을 만들면 된다고 생각했지만, 실제로는 제가 만든 부분이 다른 데이터와 화면 결과까지 이어져야 하나의 기능으로 완성된다는 점을 경험했습니다.

이 프로젝트를 통해 역할 분담, 진행 공유, 기능 통합을 처음 겪었고, 이후 프로젝트에서는 내가 맡은 코드만 보는 것이 아니라 그 기능이 전체 Runtime 흐름에서 어디에 연결되는지를 함께 확인하게 됐습니다.

또 포트폴리오를 정리할 때도 팀 전체 결과와 개인 기여를 구분해서 설명하는 것이 중요하다는 기준을 갖게 됐습니다.

MFC-Crazy-Arcade는 제 포트폴리오에서 처음 팀 안에서 역할을 맡고, 그 역할이 전체 결과물과 연결되는 과정을 경험한 프로젝트로 정리하고 있습니다.