※ 앞서 해당 회고록은 프로젝트 진행을 하며 내용을 추가&수정 혹은 다른 포스팅으로 분리해서 쓸 수도 있음.
애자일 방법론을 겪으며,,,
지금까지는 프로젝트를 한 단계가 끝나면 다음단계로 넘어가는 워터폴 방법론과 유사하게 대략 다음과 같이
[계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 배포 → 유지보수] 같은 방식으로 개발을 진행했었고, 익숙해져 있었다.
그러다보니 애자일 방법론을 처음 겪으면서 혼란스럽고, 익숙하지 않아 몇번 시행착오를 겪었다.
이번 게임 개발 프로젝트에서는 주로 스크럼 프레임워크를 사용하여 애자일 방법론을 실천하였고, 조금씩 XP도 섞인 것 같다.
애자일은 시스템에서 당장 필요한 핵심 기능들을 빠르게 정해 한번의 스프린트 기간동안 목표치만큼 구현한다.
그 산출물로 시스템이 잘 돌아가는지? 구현한 기능이 어떤지? 특히 게임의 경우는 재밌는지 빠르게 검증하고, 이 기능이 필요한지? 등 지속적으로 검증하며 점점 확장해 나가는 방식이다.
애자일에서 겪은 문제점과 해결 방법
애자일은 전체적인 문서화보다 구현물에 더 집중하면서 확장 해 나가는 방식이므로 기존에 적응했던 방식과는 반대이다.
그래서 눈 앞의 스프린트 목표 구현에 집중해야 하는데 자꾸 한번씩 전체적인 틀을 생각하고 체계화 하는데 시간을 허비하여 첫 스프린트 목표를 하마터면 달성하지 못할 뻔 했다.
이런 시행착오를 겪었음에도 첫 스프린트를 달성 할 수 있었던 이유는 바로 소통에 있었다.
특히 스크럼 프레임워크같은 경우 데일리 스크럼이라는 소통기법을 사용한다.
우리는 대학생들끼리 팀을 이뤄 개발을 진행하였기에 다른 수업도 듣고, 시험기간도 있어 이 소통기법을 완벽히 적용하기는 힘들었지만 일주일에 1번 정기적 회의와 팀원끼리 추가 미팅을 진행하였다.
추가로 애자일 방법론을 사용하면서 느낀 문제는 다음과 같다. (일단 지금까지 느낀점)
- 체계적으로 이전 단계에서 문서화되고 정해진게 없이 미흡한 상태로 스프린트 개발이 돌아가니 스프린트의 구현 목표는 정해져도 배정받은 백로그에서도 구현을 얼마만큼? 어디까지? 구현해야 하는지 명확성이 부족하다.
- 추가로 어떤 기능이 필요하지 않을까? 같은 상상으로 추가 구현을 하여 삽질을 하기도 한다.
- 팀원끼리 나눠서 작업을 한 결과물이 서로 생각한 것과 달라지는 등 통일된 문서화의 부재가 느껴진다.
결국 이런 문제들이 생기기 때문에 애자일에서는 정기적인 소통이 매우 중요함을 깨달았고, 데일리 스크럼같은 잦은 회의가 필수다.
특히 각자 구현에서도 더욱 확장과 코드 재사용을 등을 고려한 객체지향적 구현이 필요함도 깨달았다.
소통이 적다면 적어도 합칠때 충돌이 나지 않게 혹은 이어 작업하기 용이하게 각자 코드를 짜야한다.
따라서 아무리 애자일 방법론이더라도 앞으로의 확장과 협력 잡업의 용이함을 위한 일부 코드 규칙들, 형상관리에서 브런치 관리, 커밋 규칙 등이 필요하다고 느꼈다.
애자일과 게임 개발
나는 게임 개발에서는 애자일 방법론이 맞지 않을 수도 있다고 생각했는데, 게임은 기획자가 따로 있는 것 처럼 기획 단계가 꼭 필요하다. 미리 정해지고 문서화가 잘 이뤄진 상태에서 다음 단계인 개발로 넘어가야 훨씬 수월함을 느꼈기 때문이다.
→ 다시 생각해보니 게임 콘텐츠 기획, 시스템 기획은 기획자가 존재하면 같이 애자일로 개발했을때 기획자가 만들어 줄 것이다.
우리 팀은 모두가 프로그래머고, 기획을 맡을 인력이 없었기에 기존에 팀원들과 회의를 통해 일단락 해놓은(아직 미완성된) 기획서만 들고 구현을 들어가면서 우리가 구체화를 할려다보니 실시간으로 "어떻게 구현할지?" 가 정해지지 않은 부분들에서 충돌이 나 생긴 문제였다.
정리하면 어떻게 구현할지 방향성이 뚜렷하지 않아 구현도 하기 힘들었던 것이다.
게임에 애자일 방법론을 쓰면서 느낀점은 전체적인 형태를 빠르게 잡아가며 구현이 가능하다는 것이다.
초반에 첫 스프린트로는 프로토타입을 빠르게 만들어서 게임성과 비즈니스적 요소 확인을 위한 테스트 구현도 가능하다.
개발 과정
개발 과정은 대략 다음과 같다.
- 프로젝트 목표, 계획, 타겟 설정 등 기획과 팀원 역할 설정
- 요구사항 분석(User Story 분석 → 전체 백로그 구성) → 명확하게 정의해야 함!
- 기술스택 및 아키텍처 설계(게임은 주로 싱글 vs 멀티로 나뉘며, 플레이어 경험 중심의 아키텍처 구성이 중요!)
- 스프린트 진행
- 핵심 기능 개발
- 고급 기능 구현
- 성능 최적화
- 사용자 테스트 및 배포
사실 개발 방법론을 어떻게 하더라도 프로젝트가 성공적으로 정해진 기간 내에 목표를 이뤄 잘 끝마칠 수 있으면 되는 것이므로 너무 고민할 필요는 없다.
내가 생각한 이상적인 게임 개발 방법론?
나는 애자일과 워터폴 방법론을 겪으면서 각각 장단점이 있다고 느꼈고 게임 개발에서는 어떻게 섞어 쓰면 좋을지 고민했다.
우선 방법론을 떠나서 이번 시행착오로 중요하다 생각한 것은 방향성이 명확해야 구현도 가능하다는 것이다.
특히 게임에선 기획에서 명확한 방향성을 제시할 수 있는 것으로, 기획에서 방향성을 이끌어내는게 중요하다.
게임 기획조차 안된 처음부터 생각하겠다.
1. 1차 기획(기획 선정)
→ 핵심 플레이 요소와 차별점 등
2. 2차 기획(기획 구체화)
→ 어떤 구현 요소들이 필요한지 정하고 어떻게 구현할지 방향성 정하기.
3. 애자일 스프린트(프로토타입)
→ 핵심 플레이 테스트 프로토타입 구현(플레이 재미 검증)
→ 검증됐다면 기획자는 기획 구체화(콘텐츠 기획, 시스템 기획)
4. 애자일 스프린트(본격 구현)
→ 프로그래머 백로그로 구현 역할 분담 후 구현 & 합치기
→ 기획자는 실시간으로 프로그래머와 상호작용하며 구현의 방향성 제시
→ 한 스프린트가 끝나면 스프린트 회고(개선점, 향후 스프린트 계획 세우기)
특히 프로그래머 관점에서 봤을때 그냥 애자일만 쓰는 방법이 힘든 상황이 있는 것 같았다.
백로그로 역할분담을 할때 문제인데, 만약 해당 백로그를 개발할 실력이나 경험이 없는 사람이 일을 맡으면 그 백로그는 스프린트 내에서 퀄리티가 낮거나 미완성 될 가능성이 크다. 혹은 스프린트 목표를 해당 백로그만 느리게 잡아야 할 것이다.
예를 들자면 우리 프로젝트 팀원들은 모두 클라이언트 개발자라 백엔드 개발은 경험이 거의 없어 당장 구현하기 힘들다.
지식은 공부해서 알지만 막상 구현은 다른 이야기다.
따라서 멀티플레이를 구현한다고 하면 서버 개발을 해야하는데 경험있는 사람이 없어서 해당 백로그 구현은 누가 맡아도 정해진 스프린트 내에서 구현 진도가 더딜것이다.
이런 경우 해당 백로그는 팀원들과 머리를 모아서 함께, 빠르게 구현 방법을 생각하고 설계한 뒤 구현만 해당 인원이 맡거나 혹은 구현조차도 같이 끝내는게 좋을 것이다.
이 방법은 아예 스프린트 하나를 그 백로그로 잡고 가는 방식이라 볼 수 있다.
(혹은 이 부분에서만 다같이 단계를 밟고 가는거니 워터폴과 유사하다 볼 수도 있다.)
일단은 프로젝트가 진행중이라 경험하며 느낀 구현 단계까지만 적었다.
나중에 더 추가 할 예정이다.
방법론 설정 방법
방법론은 결국 해당 프로젝트 팀에서 백로그 담당 전문 인력이 얼마나 존재하는가?
- 기획자(콘텐츠 기획자, 시스템 기획자)
- 프로그래머(클라이언트 개발자(UI 담당, 플레이 담당), 백엔드 개발자)
- 아트, 사운드, etc...
그리고 프로젝트의 마감 기한이 언제인가?
정도에 따라서 달라질 것 같다.
방법도 여러가지를 하이브리드로 쓸 수도 있고, 한개만 쓸 수도 있고...
