MFC-B03 | MFC-Crazy-Arcade — 첫 팀 프로젝트에서 배운 커뮤니케이션과 기능 통합

이 글에서 확인할 내용

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

이전까지는 혼자 기능을 만들고 혼자 확인하는 방식이 익숙했습니다. 하지만 팀 프로젝트에서는 제가 맡은 기능이 동작하는 것만으로는 충분하지 않았습니다.

제가 맡은 타일 배치와 맵 구성 흐름도 다른 작업과 연결되어야 했고, 같은 데이터와 결과를 기준으로 맞춰야 했습니다.

이 글에서는 MFC 자체의 기능보다, 처음 팀으로 개발하면서 역할 분담 이후에 어떤 내용을 공유해야 했고, 기능을 하나의 결과물로 맞추는 과정에서 무엇을 배웠는지를 중심으로 정리합니다.

특정 갈등이나 회의 에피소드를 과장해서 설명하기보다, 당시 실제로 경험했던 진행 공유, 연결 지점 확인, 기능 통합의 의미를 정리한 글입니다.

혼자 만드는 것과 팀으로 만드는 것의 차이

개인 프로젝트에서는 대부분의 판단을 혼자 내릴 수 있습니다.

어떤 기능을 먼저 만들지, 어떤 방식으로 수정할지, 문제가 생기면 어디부터 확인할지 모두 제 흐름 안에서 정하면 됐습니다.

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

내가 맡은 기능도 결국 다른 사람의 작업과 연결되어 하나의 결과물로 보여야 했습니다.

예를 들어 제가 맡았던 타일 배치 흐름만 봐도 다음과 같은 연결이 있었습니다.

Tool에서 타일 선택
↓
맵에 배치
↓
Terrain 데이터 변경
↓
저장된 Map Data
↓
Client 화면에서 결과 확인

이 흐름 중 하나라도 맞지 않으면 제 작업이 끝났다고 보기 어려웠습니다.

이때 처음으로 다음 두 가지가 다르다는 걸 느꼈습니다.

내 기능이 동작한다
 
!=
 
팀 프로젝트 안에서 정상적으로 통합된다

혼자 만들 때는 화면에 원하는 결과가 나오면 기능이 끝났다고 생각하기 쉬웠습니다.

팀 프로젝트에서는 그 결과가 다른 기능과 연결된 뒤에도 같은 기준으로 동작해야 했습니다.

역할을 나눈 뒤에도 계속 맞춰야 했던 이유

처음 팀 프로젝트를 할 때는 역할을 나누면 각자 맡은 부분을 만들고 마지막에 합치면 된다고 생각하기 쉬웠습니다.

하지만 실제로는 중간에 계속 확인해야 할 것이 있었습니다.

누가 어떤 기능을 맡고 있는가?
 
어떤 데이터가 공통 기준인가?
 
내가 만든 결과를 다른 작업에서 어디서 사용하는가?
 
기능을 합쳤을 때 화면 결과가 같은가?
 
문제가 생기면 어느 연결 지점부터 확인해야 하는가?

특히 타일 배치처럼 Tool, 데이터, 저장 결과, Client 화면이 이어지는 기능은 내 코드만 보고 전체 결과를 판단하기 어려웠습니다.

그래서 자연스럽게 다른 작업과 만나는 지점을 확인하고, 필요한 내용을 공유하면서 맞춰가는 과정이 필요했습니다.

역할 분담은 시작점이었고, 실제 협업에서는 각자 만든 결과가 다시 하나의 흐름으로 연결되는 과정이 더 중요했습니다.

진행 공유가 필요했던 부분

처음 팀 프로젝트를 하면서 가장 크게 달라진 점 중 하나는 작업 진행 상태를 설명해야 한다는 것이었습니다.

혼자 작업할 때는 제가 어디까지 했는지 제가 알고 있으면 됐습니다.

하지만 팀에서는 다음 작업을 이어갈 사람이 있거나, 같은 결과를 확인해야 하는 사람이 있기 때문에 현재 상태를 공유해야 했습니다.

예를 들어 타일 배치 흐름에서도 이런 정보가 중요했습니다.

현재 어디까지 동작하는가
 
어떤 값이 변경되는가
 
어떤 데이터에 결과가 들어가는가
 
화면에서는 어디에서 확인할 수 있는가
 
다른 기능과 연결되는 부분은 어디인가

당시에는 지금처럼 문서화 기준을 세워두고 작업한 것은 아니었습니다.

그래도 이 경험을 통해 기능을 설명할 때 단순히 “완료했습니다”라고 말하는 것보다, 어디까지 동작하고 어떤 결과로 확인할 수 있는지 말하는 것이 더 중요하다는 점을 배웠습니다.

지금 프로젝트를 정리할 때 Input → Data → Runtime Result처럼 흐름을 나눠 보는 습관도 이런 초기 경험과 연결되어 있습니다.

같은 말을 하고 있어도 기준이 다르면 결과가 달라집니다

팀 프로젝트에서는 “맵”, “타일”, “저장 결과”처럼 같은 표현을 쓰더라도 실제로 어떤 데이터를 기준으로 말하는지 맞아야 했습니다.

예를 들어 Tool 화면에서 선택한 타일과 Client 화면에서 실제로 그려지는 타일이 이어지려면 중간 데이터가 같은 기준을 가져야 했습니다.

Tool에서 선택한 Tile ID
↓
Terrain의 TILE 데이터
↓
저장된 Map Data
↓
Client에서 다시 읽는 데이터
↓
화면에 표시되는 결과

중간 값 하나가 다르면 마지막 화면에서는 기대한 결과와 다른 모습이 나올 수 있습니다.

그래서 커뮤니케이션도 단순히 “기능 됐습니다”라고 말하는 것보다, 어떤 데이터와 어떤 결과를 기준으로 이야기하는가가 중요했습니다.

이 경험을 통해 협업에서 같은 용어를 쓰는 것만으로는 충분하지 않고, 실제로 같은 상태와 같은 결과를 보고 있는지 확인해야 한다는 감각을 처음 얻었습니다.

기능 통합에서 배운 것

기능 통합은 단순히 마지막에 코드를 합치는 과정이 아니었습니다.

각자 만든 기능이 같은 값을 기준으로 보고 있는지, 연결되는 데이터가 맞는지, 실제 화면 결과까지 정상인지 확인해야 했습니다.

타일 배치 흐름을 기준으로 보면 다음이 맞아야 했습니다.

선택한 Tile ID
↓
Terrain의 TILE 데이터
↓
저장되는 Map Data
↓
Client가 읽는 Map Data
↓
화면에 표시되는 결과

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

이 프로젝트를 진행하면서 처음으로 기능이 끝나는 지점보다 다른 기능과 만나는 경계를 같이 봐야 한다는 감각을 얻었습니다.

지금 기준으로 보면 기능 통합은 다음에 더 가깝습니다.

각 기능을 만든다
 
+
 
연결되는 Data / State를 맞춘다
 
+
 
최종 Runtime 결과를 확인한다

이후 프로젝트에서 Runtime Flow나 State의 Owner를 계속 확인하려고 하는 습관도 이런 초기 경험과 연결되어 있습니다.

문제가 생겼을 때 내 코드만 볼 수 없었습니다

개인 프로젝트에서는 문제가 생기면 대부분 내가 수정한 코드 안에서 원인을 찾으면 됐습니다.

팀 프로젝트에서는 그렇지 않았습니다.

내 기능 자체는 정상이어도, 다른 기능과 연결되는 값이나 저장된 데이터가 예상과 다르면 최종 결과는 틀릴 수 있었습니다.

타일 배치 흐름을 예로 들면 다음 중 어디에서 문제가 생겼는지 나눠 봐야 했습니다.

타일 선택이 잘못됐는가?
 
입력 결과가 Terrain에 들어갔는가?
 
저장된 Map Data가 맞는가?
 
Client가 같은 데이터를 읽고 있는가?
 
최종 화면에서 정상적으로 보이는가?

당시에는 이런 방식으로 디버깅 절차를 체계화한 것은 아니었습니다.

하지만 첫 팀 프로젝트를 경험하면서, 문제가 생겼을 때 내 코드만 보는 것이 아니라 연결된 데이터와 다음 단계까지 함께 확인해야 한다는 점을 처음 체감했습니다.

이 경험은 이후 더 큰 프로젝트에서 문제가 생겼을 때 “어디까지 정상이고, 어디서부터 달라지는가”를 확인하려는 습관으로 이어졌습니다.

첫 협업에서 어려웠던 점

첫 팀 프로젝트였기 때문에 처음부터 협업을 잘했다고 생각하지는 않습니다.

오히려 해보면서 어려운 점을 많이 느꼈습니다.

혼자 만들 때는 내 코드만 이해하면 됐지만, 팀 프로젝트에서는 다른 사람이 만든 구조를 읽고 내 작업과 연결해야 했습니다.

또 문제가 생겼을 때도 내 코드만 보는 것이 아니라, 연결된 데이터와 다른 기능까지 확인해야 했습니다.

당시에는 이런 과정을 체계적으로 설명하지 못했습니다.

그래도 프로젝트를 끝내고 나니 다음 기준이 남았습니다.

내 역할을 명확히 한다.
 
진행 상태를 공유한다.
 
다른 기능과 만나는 지점을 확인한다.
 
같은 Data / State를 기준으로 이야기한다.
 
최종 결과는 Runtime에서 함께 확인한다.

지금 보면 기본적인 협업 원칙이지만, 저에게는 첫 팀 프로젝트를 통해 직접 체감한 내용이었습니다.

팀 결과와 개인 기여를 구분하게 된 이유

이 프로젝트를 지금 다시 정리하면서 중요하게 보는 부분이 하나 더 있습니다.

팀 프로젝트의 최종 결과는 여러 사람이 함께 만든 것이기 때문에, 프로젝트 전체가 동작했다는 사실과 제가 직접 맡은 부분은 구분해서 설명해야 합니다.

MFC-Crazy-Arcade에서 제가 맡은 중심 영역은 타일 배치와 맵 구성 흐름입니다.

반면 Tool 전체 구조, 저장 흐름, Client 전체 기능은 팀 프로젝트의 더 넓은 영역에 해당합니다.

그래서 포트폴리오에서도 다음 두 가지를 분리해서 보고 있습니다.

개인 기여
→ 타일 배치 / 맵 구성 흐름
 
팀 결과
→ Tool과 Client가 연결된 전체 게임 결과물

첫 팀 프로젝트를 경험한 뒤부터는 “프로젝트에서 무엇이 구현됐는가”와 “그중 내가 맡은 것은 무엇인가”를 따로 설명하는 것이 중요하다고 생각하게 됐습니다.

Runtime

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

MFC C++ Crazy Arcade

이 영상은 현재의 대표 프로젝트처럼 기술 깊이를 보여주기 위한 자료라기보다, 처음 역할을 나누고 하나의 게임 결과물을 완성했던 당시 작업을 확인할 수 있는 기록입니다.

영상에서는 팀 프로젝트의 결과물이 실제 게임 화면으로 동작했던 당시 모습을 확인할 수 있습니다.

이후 프로젝트에서 달라진 점

MFC-Crazy-Arcade 이후에는 DX9-Cat-Quest에서 더 많은 Runtime 기능을 맡게 됐습니다.

캐릭터, 몬스터, 스킬, 상호작용처럼 서로 연결되는 기능이 많아지면서, MFC에서 처음 경험했던 역할 분담과 기능 통합의 중요성을 더 크게 느끼게 됐습니다.

이후 DX11과 Unreal 프로젝트를 진행하면서도 기능 하나를 볼 때 다음 순서를 계속 의식하게 됐습니다.

내가 맡은 범위
↓
사용하는 Data / State
↓
다른 기능과 연결되는 지점
↓
실제 Runtime 결과

또 기능을 설명할 때도 단순히 “구현했다”에서 끝내기보다,

어디에서 시작하는가
 
무슨 데이터를 바꾸는가
 
다음에 누가 사용하는가
 
최종 결과는 어디에서 확인하는가

를 함께 설명하려고 하게 됐습니다.

MFC-Crazy-Arcade는 이 기준을 완성한 프로젝트는 아닙니다.

대신 혼자 만드는 방식에서 벗어나, 팀 안에서 기능을 설명하고 다른 작업과 맞춰가야 한다는 사실을 처음 배운 프로젝트였습니다.

정리

MFC-Crazy-Arcade는 제가 처음으로 팀 단위 개발을 경험한 프로젝트입니다.

타일 배치와 맵 구성 흐름을 맡으면서 기능을 만드는 것과 팀 전체 결과물에 통합하는 것은 다른 문제라는 점을 처음 느꼈습니다.

역할을 나눈 뒤에도 진행 상태를 공유하고, 같은 데이터와 결과를 기준으로 맞추고, 다른 기능과 만나는 지점을 확인해야 했습니다.

문제가 생겼을 때도 내 코드만 보는 것이 아니라, 연결된 데이터와 다음 단계까지 함께 확인해야 했습니다.

이 경험 이후에는 프로젝트를 볼 때 제 코드만 보는 것이 아니라 어디에서 다른 기능과 연결되고, 최종 Runtime 결과까지 어떻게 이어지는지를 더 의식하게 됐습니다.

또 팀 전체 결과와 개인 기여를 구분해서 설명하는 기준도 갖게 됐습니다.

MFC-Crazy-Arcade는 제 성장 과정에서 첫 협업, 진행 공유, 기능 통합의 감각을 처음 배운 프로젝트로 남아 있습니다.