Intro
GDC2020의 발표 중 하나인 Stress-Free Game Development: Powering Up Your Studio With DevOps의 내용을 정리, 요약한 글이다.
https://www.youtube.com/watch?v=t9HRzE7_2Xc&t=681s
베타 테스트를 했더니 버그가 2200개가 나오고, 그 버그를 고치기 위한 크런치.. 출시 이후에도 버그가 쏟아져 하게 되는 크런치. 그러다보니 1년에 패치를 두 번 밖에 할 수 없었고, 이에 대한 대응으로 모두들 하는 선택을 했다. 사람을 더 고용한 것이다. 그러면서 개발팀 내에 프로세스라고 부를만한게 없다는 것을 깨닳았다. 아트 팀은 늘어서 더 많은 리소스가 나오는데 여전히 프로그래머는 부족했다.
결국 감당이 안 되어 인원을 다시 4명으로 줄였고, 이 과정이 너무 힘들어 데브옵스(DevOps)라는 것을 생각하기 시작했다. 그 이후 스팀에서 97%의 긍정적인 피드백, 한달에 2~3개의 컨텐츠 패치, 내부 QA에 하루 4번 패치 전달, 11개 언어 제공, 플랫폼 다양화, 6명의 팀원, 그리고 크런치 없는 결과를 얻을 수 있었다.
데브옵스란 무엇인가?
빠른 배포주기, 신뢰성 높은 제품, 팀간의 커뮤니케이션 강화에 집중하는 운영 원칙이다. 그리고 개발팀과 운영팀(배포, 관리)간의 관계를 의미한다. 이를 위해선 다음 세 가지 방법이 중요하다.
- 일의 흐름 제어
- 피드백 강화
- 지속적인 학습
낭비 제거
좋은 프로세스를 위해선 낭비를 제거해야 한다. 낭비는 고객에게 가치를 전달하지 못하는 모든 것을 의미하며, 자가증식을 하기 때문에 눈에 보이는 것보다 더 나쁘다. 낭비에는 다음과 같은 것들이 있다.
- 행동 낭비
- 물질이나 정보의 이동에 의해 생기는 낭비. 뭔가를 요청하기 위해 메일을 보내고, 계속 메일을 주고 받다 결국 다음 주에 미팅을 잡곤 한다. 그리고 이로 인해 다른 종류의 낭비가 생기기도 한다. 따라서 문서화 등을 통해서 최대한 혼자 찾아서 할 수 있는 시스템을 만들어야 한다.
- 작업 전환
미팅 -> 개발 -> 출시 -> 미팅등 서로 다른 작업을 하면서 발생하는 전환 비용이다. 일을 종류에 따라 배분하거나, 미팅을 하루에 몰아서 하는 등의 방법을 사용해 줄여볼 수 있다.
- 결함
- 다음 작업자에게 유용하지 않은 모든 것을 의미한다. 이미지 크기나 사운드 포맷이 다르거나 오타가 많은 등의 문제로 결함이 생기면 다시 이전 작업자에게 올려보내야 한다. 애초에 시작부터 이런 문제가 생기지 않을 수 있는 시스템을 만들어야 한다.
- 대기
- 무언가 발생하거나 완료되기를 기다리는 시간. 이로 인해 다른 낭비도 생기기 때문에 결국 프로젝트 완성도도 떨어진다. 일을 작은 단위로 끊이지 않고 진행될 수 있도록 하는 것이 중요하다.
- 미완성 작업
- 어떤 작업을 하는데 크기가 너무 커서 다른 작업들이 밀리기 시작해 잠시 미루고 다른 작업들을 하기 시작한다. 몇달 후 다시 이 작업을 꺼내려니 버그도 많고 사이드 이펙트도 생긴다는 사실을 깨닳게 된다. 결국 이전 작업을 포기하거나 다시 처음부터 하게 된다. 잠시라도 일이 미완성 상태로 남게 되면 주변 환경이 변하므로 다시 꺼냈을 때 문제가 발생한다. 따라서 프로젝트를 전달 가능한 가장 작은 단위로 쪼개야 한다.
- 수동 작업
- 손으로 직접 하는 일은 결함이 발생하기 쉽고 작업 단위를 확장하기도 어렵다. 가능한 자동화 하고 그 시간을 플레이어를 위해 사용하는 것이 낫다.
- 부가 과정
- 꼭 할 필요가 없는 일을 하는 것이다. 이게 꼭 필요한가? 라는 질문을 자주 던지고 불필요한 일은 하지 말자.
- 부가 기능
- 게임에 있을 필요가 없는 것들을 의미한다. 모든 기능은 게임에 복잡성을 더하기 때문에 이게 꼭 필요한지 계속 생각할 필요가 있다. 이미 있는 기능이라면 제거할 수 있는지 생각해보자.
- 영웅심
- 요구사항을 만족하기 위해 비정상적인 행동을 하는 것이다. 대표적으로 크런칭이 있다. 크런칭을 하게 되면 다른 모든 요소들에도 영향을 주기 때문에 가장 나쁜 낭비의 종류이다. 이러한 영웅심은 게임업계의 상징과 같이 되었다. 기사에서 매일 게임 업계의 크런칭에 대해 이야기 한다. 게임 업계가 이렇다는 것은 이 업계가 전반적으로 일을 매우 비효울적인 방법으로 하고 있다는 것이다.
생산을 그만두는 것이 이 악순환을 깨기 위한 유일한 방법이다.
일이 눈에 보이게 만들기
일주일에 두 번 제품 미팅(Production Meeting)을 통해 높은 단계의 목표를 설정하고 다음 미팅 전까지 약 16시간 동안 할 정도의 일을 배분한다. 스프린트가 짧기 때문에 미팅도 짧다. 일을 정리하기 위해서 트렐로를 사용한다.
Inbox -> To-Do -> Doing -> Testing -> Done
1. 새로운 작업은 무조건 Inbox에 들어가고 미팅에서 우선순위에 따라 정렬한다. 이렇게 계획에 없던 일에 방해받는 것을 최대한 피한다.
2. 시간은 제한적이다. 만약 16시간 이상의 일을 준다면 야근을 하라는 것이니 피해야 한다.
3. 모든 작업은 Testing을 포함해 항상 모든 단계를 거쳐야 한다. 다음 사람에게 작업을 전달하기 전에 결함은 없는지 잘 살펴야 한다.
아트 에셋 파이프라인
기존에는 프로그래머가 아트 작업을 확인하고 에러가 있으면 다시 돌려보냈다. 프로그래머에게 넘기기 전에 생산자(아티스트)가 테스트를 진행하고 에러가 있으면 바로 고쳐야 한다.
보틀넥(Bottleneck) 시각화
아트가 생산할 수 있는 에셋이 시간당 3개라고 해도 프로그래머가 적용할 수 있는게 시간당 1개라면, 최종 게임에 적용할 수 있는건 시간당 1개가 된다. 테스트를 아티스트가 진행함으로써 아티스트의 생산량이 시간당 2개로 줄더라도, 프로그래머의 일을 가져가주므로 프로그래머가 시간당 2개를 처리하며 결과량은 향상된다. 팀의 결과물을 늘리는 방법은 이렇게 보틀넥을 향상시키는 것이다.
배포!
기존 배포 프로세스는 아주 별로였다. 하지만 데브옵스를 할 때에는 어떤 프로세스가 별로면 더 자주 해야한다. 그러면 불편해서 고치게 된다.
목표: 지속적인 배포
작은 변화도 지속적으로 배포하면 문제를 바로 찾아서 해결할 수 있고 큰 문제가 생기는 빈도도 줄어든다. 문제가 생기면 어디서 찾아야 하는지 알아보기 쉽고 배포 프로세스에 생긴 문제도 고치기 쉬워진다.
기존의 배포 & QA 테스트 파이프라인
- 매주 목요일 패치노트를 작성: 30분
- 빌드를 만들고 동작하는지 확인: 30 ~ 60분
- 만약 빌드가 잘 안나오면 위 프로세스 반복
- DropBox로 QA에게 전달
- QA 체크리스트 생성
- 테스트 시작
- 찾아낸 버그를 이슈로 생성
- 이슈 검토
- 트렐로 카드 생성
- 반복 (주단위)
윈도우만 겨우 하고 다른 플랫폼은 테스트도 하지 못했다.
게임 파이프의 탄생
바로 적용할 수 있는 간단한 것부터 시작한다. Git에 푸시를 하면 hook을 사용해서 자동을 빌드를 생성하고 완료되면 DropBox에 올리는 것만으로도 많은 문제가 해결된다. 게임 프로그래머의 시간이 더이상 빌드 컴파일 하는데 빼았기지 않고, 빌드를 QA에게 수동으로 전달하지 않아 시간도 절약된다. 또한 모든 플랫폼의 빌드가 같은 버전이기 때문에 환경 설정 문제도 생기지 않는다. 이렇게 주간 빌드에서 일간 빌드로 변경할 수 있었다. 하지만 하루 한 번이 지속적인 빌드는 아니다.
자동 패치노트
깃에 커밋을 할 때 무엇을 수정헀는지 항상 작성하는데, 패치노트에도 비슷한 내용이 들어간다. 결국 같은 일을 두 번 하게된다. 따라서 깃 커밋을 자동으로 패치노트로 만들어주는 프로그램을 만들었다. 이렇게 언제든 배포를 할 수 있게 되었고, 패치노트에 내용을 빠뜨리는 실수도 사라졌다. 또한 깃 커밋 내용이 공개되다 보니 커밋 메시지를 더 명확하고 확실하게 작성하게 되었다. 결국 변경 내용을 추적하는 것도 쉬워졌다.
추가적으로 DropBox에 배포하는 대신 스팀의 내부 스테이징 브랜치에 올려 QA 팀이 항상 최신 버전으로 테스트할 수 있게 했다. 다른 플랫폼에도 자동으로 올릴 수 있게 했고 Localization도 자동화 했다.
게임 파이프: 결론
완전 수동이던 1시간 짜리 배포 과정이 5초로 바뀌었다. 주단위 테스트에서 지속적인 테스트로 변경했고 더 안정적인 빌드를 얻게 되었다. 배포가 쉽고 고통이 없는 환경을 위해 할 수 있는 것부터 하고 계속 발전시켜야 한다.
다음 보틀넥: 새로운 직원
비지니스를 담당할 직원이 필요했고 그 직원의 교육을 위해 개발 프로세스와 비슷한 시스템을 만들었다. 책 읽기 같은 혼자 하는 작업부터 다른 직업과의 인터뷰까지 교육용 작업을 생성했다. 각 작업의 목적은 스튜디오의 동작 방식과 자신의 역할을 이해하는 것이다. 일주일에 두 번 스프린트 미팅을 진행해 정확히 무엇을 해야하는지 알 수 있게 했다. 나중에 같은 방법을 풀타임 QA를 고용헀을 때에도 사용했다. 이러한 방법으로 새로운 보틀넥을 해결할 수 있었다.
데브옵스의 방법 정리
첫 번째 방법: 일의 흐름 제어
작업은 항상 단방향으로 진행된다. 낭비를 제거하고 일을 명확하게 하기 위해 제품 미팅을 진행하고, 트렐로 등을 사용해 프로세스를 변경했다. 작은 단위로 작업을 전달하기 위해 게임 파이프를 생성하고 지속적인 배포/통합을 이용했다. 생산자가 직접 테스트를 함으로써 작업이 흐름을 거슬러 가는 것을 방지할 수 있었다. 이 모든 것은 높은 품질의 게임을 고객에게 전달하는 목표를 위해서이다.
두 번째 방법: 피드백 강화
피드백은 작업 흐름의 반대 방향으로 가야 한다. 피드백을 통해 문제를 발견하고 프로세스를 개선하며 빌드 품질을 향상시킬 수 있다. 피드백을 향상시키기 위해 툴과 시스템을 개발해야 한다. QA 팀에서 많은 버그를 발견해도 수동으로 트렐로 카드를 생성하기 때문에 감당이 안 될 수도 있다. 트렐로 API를 사용해서 이슈를 보는 사람이 버튼 하나로 자동으로 트렐로 이슈로 전환할 수 있도록 기능을 만들어 문제를 해결했다.
패치노트를 보고 QA 체크리스트를 만드는 것도 큰 비용이고 실수의 여지도 있다. 패치노트를 QA 체크리스트로 바꾸는 기능을 개발해 QA가 사용할 수 있게 했고 개발자가 로그인 했을 땐 몇 명의 QA가 이 요소를 확인했는지 알 수 있게 했다.
물론 피드백을 강화하기 전에 그 피드백을 소화할 수 있는 환경이 선행되어야 할 것이다.
세 번째 방법: 지속적인 학습
팀의 모든 사람이 더 빠르고 나은 프로세스를 위해 참여할 수 있어야 한다. 도전 정신이 중요한 부분이다. 이를 위해 정신적으로 안정된 문화가 형성되어 모두가 목소리를 낼 수 있어야 한다. 이런 문화는 허공에서 생겨나지 않는다. 사람들이 개발하는 주변 환경에 대해 이야기 하는 것들이 모여서 만들어진다. 이러한 문화는 일하는 방법의 구조와 과정에서 생겨난다.
지속적으로 평가하는 구조가 중요하다. 공식적으로 분기마다 리뷰를 진행해 팀원들이 질문지를 작성하게 하고, 응답을 참고해 문제 분석가가 프로세스 개선 여부를 살핀다. 이런 과정을 통해 정말 많은 개선이 있었다.
결론
6개 플랫폼에 11개 언어로 서비스 하지만 6명의 팀원으로 야근 없이 대응하고 있다. 스위치 런칭을 준비하고 있엇지만 비슷한 컨셉의 마리오 메이커가 출시하는 바람에 갑자기 스팀으로, 그것도 2개월이나 빠르게 런칭하게 되었다. 그럼에도 불구하고 평소 스팀으로 빌드를 하고 있었고 지속적으로 QA를 진행했기 때문에 그대로 출시를 준비해도 야근 없이 마무리 할 수 있었다. 게임 개발의 스트레스는 잘못된 관행으로 인한 것이다. 이런 변화가 쉽지는 않지만 완벽보단 조금이라도 발전해나갈 수 있게 해야한다. 작은 부분만 바뀌어도 이득을 볼 수 있다.
소감
더 나은 개발 프로세스를 위해 많은 고민이 필요하다는 것을 느꼈다. 그리고 그 개발 프로세스가 얼마나 중요한지도. 프로세스를 발전시키려는 고민 없이 지금에 안주하고 "문제 생기면 야근하면 되지" 라는 생각으로 일하고 있지 않나 하는 반성도 되었다. 좋은 예시와 함께 재미있게 설명해주는 좋은 영상이었다.
