게임 개발 마일스톤 - 기능 목록을 ‘검증 질문’으로 바꾼 이유 | 쿼리도 슈팅 개발일지 #07

한 줄 요약
기능 구현 여부만으로 마일스톤을 관리하자 우선순위와 재작업의 기준이 흐려졌어요.
BGU 기획 멘토링을 계기로 ‘무엇을 만들 것인가’보다 ‘무엇을 검증할 것인가’를 먼저 정하는 방식으로 바꿨습니다.

완료한 작업을 왜 자꾸 다시 고치게 될까?

안녕하세요! <쿼리도 슈팅>에서 PO와 개발을 맡고 있는 정회륜이에요.
이번 글에서는 개발 구현보다 PO의 관점에서, BGU 기획 멘토링을 계기로 프로젝트의 마일스톤을 다시 정의한 과정을 이야기해보려고 해요.

개발을 진행하면서 이미 완료했다고 판단한 기능을 다시 수정하는 일이 반복됐어요.
UI 구성을 바꾸거나 시스템을 개선할 때마다 다른 파트의 작업까지 함께 영향을 받았고, 자연스럽게 한 가지 의문이 생겼습니다.

“이 재작업은 게임을 더 좋게 만들기 위한 정상적인 반복일까, 아니면 협업 방식의 문제일까?”

이 글에서는 BGU 기획 멘토링에서 받은 피드백을 바탕으로 반복 작업을 바라보는 기준과 마일스톤 설정 방식을 다시 정리한 과정을 다룹니다.

이 글은 다음과 같은 분들에게 도움이 될 수 있습니다.

• 게임 프로젝트의 마일스톤을 기능 목록으로 관리하고 있는 분
• 반복되는 수정과 재작업 때문에 고민하는 분
• 소규모 팀에서 개발 우선순위를 결정해야 하는 PO 또는 파트장
• 핵심 재미와 개발 태스크를 연결하기 어려운 분

---

기능은 계속 완성되는데, 핵심 재미는 확인하지 못했어요

어떤 상황이었는가

쿼리도 슈팅은 격자 전장에서 캐릭터를 이동시키고 적을 공격하는 턴제 전략 게임입니다.

당시 프로젝트에서는 이동, 공격, 스킬과 벽 건설 등의 전투 시스템을 개발하고 있었습니다.
여기에 UI/UX, 캐릭터 애니메이션과 이펙트 등을 적용하면서 플레이 가능한 빌드의 완성도를 높이는 작업도 함께 진행했어요.

프로젝트 규모가 커지면서 파트 간 작업의 연결 관계도 복잡해졌습니다.

• 기획이 바뀌면 UI 구조를 수정해야 했습니다.
• UI 흐름이 변경되면 프로그래밍 작업도 다시 필요했습니다.
• 애니메이션과 이펙트를 적용한 뒤 전투 실행 시점을 조정해야 했습니다.
• 실제 플레이 결과에 따라 기존 시스템의 규칙을 다시 검토해야 했습니다.

하나의 변경이 다른 파트의 추가 작업으로 이어지면서, 문제는 이 재작업이 필요한 반복인지, 처음부터 막을 수 있었던 낭비인지 구분할 기준이 없었다는 것이었어요.

왜 이 작업이 필요했는가

당시 마일스톤은 다음과 같이 기능 단위로 구성되어 있었습니다.

• 전투 시스템 구현
• UI/UX 개선
• 캐릭터 애니메이션 적용
• 신규 콘텐츠 추가
• 밸런싱과 최적화 진행

각 항목은 프로젝트에 필요한 작업이었습니다. 하지만 기능을 구현해 무엇을 확인하려는지는 명확하지 않았습니다.

벽 건설 시스템을 구현했다고 해서 플레이어가 벽을 전략적으로 사용한다는 보장은 없습니다. 애니메이션과 이펙트를 추가했다고 해서 전투 결과가 명확하게 전달되는 것도 아닙니다.

기능의 완료 여부만 보면 얼마나 만들었는지는 알 수 있었지만, 게임이 실제로 더 재미있어졌는지는 알 수 없었어요.

[스크린샷: 쿼리도슈팅 인게임 플레이]

---

재작업 자체가 문제가 아니라, 이유를 구분하지 못한 게 문제였어요

반복되는 수정은 모두 비효율적인가

프로젝트를 진행하면서 UI 화면과 시스템을 여러 차례 수정했습니다.
결과물을 합친 뒤 예상과 다른 플레이 경험이 나타나거나, 다른 파트의 작업과 연결하면서 추가 수정이 필요한 경우도 있었습니다.

처음에는 이러한 반복이 기획이나 협업 방식의 문제라고 생각했습니다.

처음부터 작업 범위와 결과를 정확히 정의했다면 수정 횟수를 줄일 수 있지 않았을까?

하지만 게임은 기획서만으로 최종 플레이 경험을 정확하게 예측하기 어려워요.
기획·아트·프로그램이 각각 잘 만들어졌더라도, 실제 게임 안에서 합쳐졌을 때는 예상하지 못한 문제가 생길 수 있습니다.

예를 들어 전투 정보를 명확하게 전달하기 위해 UI를 추가했지만 화면이 복잡해질 수 있습니다. 공격을 강조하기 위해 이펙트를 키웠지만 캐릭터와 타일이 가려질 수도 있습니다.

이런 문제는 실제로 구현하고 플레이해 보기 전에는 발견하기 어렵습니다.

기능 목록만으로는 우선순위를 정하기 어려웠다

두 번째 문제는 마일스톤의 성공 기준이 기능 완료 여부에만 집중되어 있었다는 점입니다.

예를 들어 다음과 같은 작업이 있다고 가정해 보겠습니다.

벽 건설 시스템을 개선한다.

이 문장만으로는 어느 상태를 완료로 판단해야 하는지 알기 어렵습니다.

• 벽을 설치할 수 있으면 완료인가?
• 벽을 설치한 뒤 적의 경로가 변경되어야 하는가?
• 플레이어가 전투 중 벽을 일정 횟수 이상 사용해야 하는가?
• 벽 사용이 실제 공격 기회로 이어져야 하는가?

완료 조건이 불명확하면 각 파트가 서로 다른 결과를 예상할 수 있습니다. 기능을 구현한 뒤에도 원래 해결하려던 문제가 남아 있을 가능성이 있습니다.

---

마일스톤을 ‘할 일’이 아니라 ‘검증할 질문’으로 바꿨어요

멘토링에서 확인한 첫 번째 기준: 반복을 구분하기

BGU 기획 멘토링에서는 게임 개발에서 수정과 반복을 완전히 피할 수 없다는 피드백을 받았습니다.

게임의 재미에는 하나의 정답이 없고, 기획자가 처음부터 완성된 해답을 가지고 있는 것도 아닙니다. 실제 게임 개발은 다음과 같은 반복에 가깝습니다.

가설 설정
→ 제작
→ 통합
→ 플레이
→ 문제 발견
→ 수정
→ 재검증

게임의 재미를 확인하기 위해 여러 번 시도하는 것은 정상적인 개발 과정입니다.

다만 모든 반복이 필요한 것은 아닙니다. 반복은 발생 원인에 따라 구분할 필요가 있었습니다.

구분	사례
생산적인 반복	실제 플레이를 통해 가설을 검증하고 새로운 문제를 발견
비생산적인 반복	결정 지연, 문서 불일치, 규격 누락과 코드 관리 문제로 재작업 발생

 

 

벽 건설의 조작 방식을 바꾸고 플레이어의 사용 빈도를 다시 확인하는 것은 핵심 재미를 찾기 위한 생산적인 반복입니다.

반면 파트마다 다른 기획서를 참고하거나, 리소스 규격을 공유하지 않아 같은 작업을 다시 제작하는 것은 줄여야 할 반복입니다.

중요한 것은 반복 횟수 자체가 아니라 다음 질문이었습니다.

이번 수정으로 이전에 알지 못했던 사실을 확인할 수 있는가?

두 번째 기준: 마일스톤을 질문으로 만들기

마일스톤을 기능 완료 목록이 아니라 ‘이번 단계에서 무엇을 검증할 것인가’를 기준으로 설정해야 한다는 점이었어요.

기존 마일스톤은 다음과 같았습니다.

벽 건설 시스템을 개선한다.

이를 검증 질문으로 바꾸면 다음과 같습니다.

플레이어가 벽 건설을 이용해 적의 이동을 방해하고, 그 결과를 공격 기회로 연결하는가?

질문이 구체화되면 필요한 작업도 명확해집니다.

• 필요 기능
  • 벽 설치 가능 위치를 명확하게 표시한다.
  • 적의 예상 이동 경로를 보여준다.
  • 벽 설치 후 변경된 경로를 즉시 반영한다.
  • 벽으로 얻은 전략적 이득을 전투 결과에서 확인한다.
• 검증 방법
  • 플레이테스트에서 벽 사용 횟수와 사용 이유를 기록한다.

반대로 해당 검증과 직접적으로 관련되지 않은 신규 콘텐츠나 추가 연출은 다음 단계로 미룰 수 있습니다.

검증 중심 마일스톤 5단계

앞으로의 마일스톤은 다음 순서로 구성하기로 했습니다.

1단계: 검증 질문 정의

한 번의 마일스톤에서 확인할 핵심 질문을 하나 정합니다.

예시: 플레이어가 적의 행동을 보고 이동 위치나 행동 순서를 변경하는가?

2단계: 최소 작업 범위 선정

질문을 확인하는 데 필요한 기능만 우선 선정합니다.

• 적 행동 예고
• 이동 가능 범위
• 행동 순서 표시
• 공격 대상과 범위
• 행동 결과 피드백

3단계: 완료 조건 정의

구현 조건과 플레이 경험 조건을 구분합니다.

• 구현 조건
  • 플레이어가 행동 순서를 변경할 수 있다.
  • 변경된 순서가 실제 실행 결과에 반영된다.
• 플레이 경험 조건
  • 플레이어가 행동 순서를 바꾼 이유를 설명할 수 있다.
  • 플레이어가 행동 순서 변경이 전투 결과에 영향을 줬다고 인지한다.

4단계: 플레이테스트 진행

같은 캐릭터, 맵과 적 구성을 사용해 변경 전후를 비교합니다.

• 어떤 기능을 사용했는가?
• 사용하지 않은 기능은 무엇인가?
• 어떤 선택에서 가장 오래 고민했는가?
• 의도한 전략과 실제 행동이 일치했는가?
• 가장 재미있거나 불편했던 순간은 어디인가?

5단계: 다음 마일스톤 결정

검증 결과에 따라 다음 작업을 결정합니다.

• 가설이 확인되면 콘텐츠와 완성도를 확장합니다.
• 일부만 확인되면 부족한 부분을 다시 실험합니다.
• 핵심 재미가 작동하지 않으면 수치보다 구조 변경을 검토합니다.
• 현재 검증과 관계없는 기능은 계속 후순위로 유지합니다.
  
  

[이미지: 차후 마일스톤]

---

아직 성과는 없지만, 판단 기준은 바뀌었어요

멘토링 직후이기 때문에 이 방식을 적용한 정량적인 성과는 아직 측정하지 못했습니다.
대신 프로젝트의 우선순위를 판단하는 기준을 다음과 같이 변경할 수 있었습니다.

Before

• 구현할 기능 목록을 먼저 작성했습니다.
• 개발 가능성과 일정으로 우선순위를 판단했습니다.
• 마일스톤의 성공 여부를 기능 완료 개수로 확인했습니다.
• 수정이 발생하면 일정이 밀린 것으로 받아들였습니다.
• 기능 구현 후 전체 플레이에서 문제를 확인했습니다.

After

• 이번 단계에서 검증할 질문을 먼저 정합니다.
• 검증에 필요한 최소 기능만 우선 선정합니다.
• 구현 조건과 플레이 경험 조건을 함께 작성합니다.
• 플레이테스트 결과를 다음 작업의 근거로 사용합니다.
• 새로운 사실을 확인했다면 수정도 유효한 결과로 기록합니다.

가장 큰 변화는 “얼마나 많이 만들었는가”보다 “이번 단계에서 무엇을 새로 알게 되었는가”를 기준으로 다음 작업을 정하게 된 것이에요.

가설이 틀렸다는 사실을 확인한 것도 의미 있는 결과입니다.
어떤 방향으로 확장하면 안 되는지 알게 되었고, 다음 마일스톤의 근거를 얻었기 때문입니다.

---

다음에는 실제 데이터로 검증해보려고 해요

이번 글에서는 멘토링을 통해 마일스톤의 기준을 바꾸는 과정까지 정리했어요.
아직 이 방식이 실제 재작업이나 의사결정 속도를 얼마나 개선하는지는 확인하지 못했습니다.

다음 플레이테스트부터는 기능 사용 횟수, 고민 시간이 길었던 선택, 기능을 사용하지 않은 이유와 예상·실제 결과의 차이를 기록해보려고 해요.

반복 자체를 실패로 생각하지 않기

게임은 직접 구현하고 플레이해야 확인할 수 있는 문제가 많습니다.
결과물을 합친 뒤 수정이 발생하는 것은 자연스러운 과정입니다.

앞으로는 수정 횟수만으로 작업의 효율을 판단하지 않으려고 합니다. 대신 새로운 사실을 확인하기 위한 반복인지, 관리 부족으로 발생한 반복인지 구분할 계획입니다.

마일스톤은 완료 목록이 아니라 질문이어야 한다

기능 이름만으로 작성된 마일스톤은 완료 조건과 우선순위가 불명확해질 수 있습니다.

다음 마일스톤부터는 먼저 다음 질문에 답하려고 합니다.

이번 단계에서 <쿼리도 슈팅>은 무엇을 증명해야 하는가?

이 질문이 정해진 이후에 필요한 기능, 담당 파트와 완료 조건을 작성해야 합니다.

다음에는 더 구체적인 데이터를 남기기

이번 글은 멘토링에서 배운 내용과 적용 방향을 정리한 단계이므로 실제 적용 결과가 부족하다는 아쉬움이 있습니다.

다음 개발일지에서는 이 데이터를 바탕으로 검증 중심 마일스톤이 실제 개발 과정에서 어떤 차이를 만들었는지 비교해보겠습니다.

• 핵심 기능별 사용 횟수
• 플레이어가 가장 오래 고민한 선택
• 기능을 사용하지 않은 이유
• 플레이어가 예상한 결과와 실제 결과의 차이
• 테스트 이후 변경한 태스크와 우선순위

이를 활용하면 검증 중심 마일스톤이 실제로 재작업과 의사결정에 어떤 영향을 주었는지 후속 글에서 비교할 수 있을 것입니다.