서브 퀘스트: 워터폴? 애자일?
사업 PM의 관리 업무 #2
앞서 PM의 기본 공격 기술인 '관리'를 터득했으니 동료를 찾을 차례다. 호기롭게 파티 모집을 하려고 보니, 파티 생성 전 플레이 타입을 지정해야 한단다. 결투, 사냥, 친목 같은 걸 고르라는 건가 싶어 자세히 살펴보니 워터폴, 애자일, 혼합 셋 중 하나를 선택하게 되어있다. 이게 무슨 소리람?
내가 게임 회사에서 난생처음 들어본 단어 중 하나가 바로 애자일이었다. 애자일은 프로젝트를 어떻게 계획하고 운영할 것인지에 대한 방법론이었는데 이제는 단순한 절차를 넘어 일종의 사고방식 내지 문화에 가까워졌다.
흐르는 강물처럼, 워터폴
워터폴 방식은 전통적인 프로젝트 관리 기법이다.
워터폴은 문자 그대로 폭포와 같이 한 번 정해진 계획이 위에서 아래로 흐르듯 진행된다. 초기 단계에서 모든 요구사항이 확정되고 기획이 끝난 이후 개발, 테스트, 출시까지 순차적으로 진행하는 방식이라고 할 수 있다. 예를 들어 퍼즐 게임을 개발한다고 하면 기본적인 게임 규칙, 랭킹, 상점 등 모든 요소를 처음부터 기획하고 개발한 뒤 한 번에 출시하는 것이다.
이렇게 하면 계획이 명확하고 체계적인 진행이 가능하지만, 개발 도중 변경이 어려운 데다 출시 이후 문제가 생기면 수정이 늦어질 수 있다.
변화에 적응하는 힘, 애자일
애자일은 빠르게 변화하는 환경에 적응하기 위한 방법론으로 짧은 개발 주기 안에서 반복적으로 제품을 개선해 나가는 것이 특징이다.
애자일 방식에서는 처음부터 모든 기능을 확정하지 않고 핵심적인 기능만 먼저 개발한 후 유저 피드백과 데이터를 반영하여 지속적으로 업데이트한다. 예를 들어 퍼즐 게임을 개발할 때 기본적인 퍼즐만 만들어 출시하고 유저 반응에 따라 새로운 모드나 경쟁 요소를 추가하는 방식이다. 이렇게 하면 유저의 요구에 신속하게 대응할 수 있지만, 방향이 자주 바뀔 가능성이 있어 개발팀이 혼란을 겪을 수 있다.
애자일 방식의 핵심 원칙은 2001년 발표된 애자일 선언문(Agile Manifesto)에서 비롯되었다. 이 선언문은 문서나 절차보다 사람 간의 협업을 중요하게 여기고 계획보다는 변화에 유연하게 대응하는 것을 강조한다.
애자일을 실천하는 방법, 스크럼
애자일은 다양한 프레임워크를 통해 실천할 수 있으며 그중에서도 가장 널리 사용되는 방식이 스크럼(Scrum)이다. 스크럼은 일정한 주기인 스프린트(Sprint) 별로 목표를 정하고 팀원들이 협업하여 제품을 점진적, 반복적으로 개선해 나가는 개발 방식이다.
스프린트의 점진성, 반복성을 나타내는 두 개의 화살표. ⓒ 아틀라시안스크럼에서는 모든 구성원이 같은 목표를 향해 나아가나, 동시에 구성원마다 관심사와 책임 범위가 달라 서로가 서로를 보완할 수 있다.
먼저 스크럼 마스터(Scrum Master)는 팀이 스크럼 방식에 따라 원활하고 건강하게 일할 수 있도록 돕는다. 스스로 의사결정을 내리지는 않지만, 팀이 자율적으로 일할 수 있는 환경을 만드는 것이 핵심이다. 스크럼 마스터는 마치 스포츠 팀의 코치처럼 협업 프로세스를 조율하고 장애물을 제거하며 팀이 흔들리지 않도록 중심을 잡으며 제품 책임자, 개발팀, 외부 이해관계자 사이에서 중재자 역할을 하기도 한다.
제품 책임자로도 불리는 프로덕트 오너(Product Owner, PO)는 무엇을 만들지, 그리고 어떤 기능이 가장 큰 가치를 줄지를 결정하는 사람이다. 유저 피드백과 시장 흐름을 분석해 제품 백로그의 우선순위를 조정하고 제품 방향성과 목표를 설정하는 핵심 의사결정자라고 할 수 있다.
개발팀(Developers)은 실제로 기능을 구현하는 사람들이다. 스크럼에서는 직무보다 역할에 집중하기 때문에 개발자뿐 아니라 기획자, 아티스트 등 다양한 직군이 포함될 수 있다.
통상적인 스프린트는 아래와 같은 이벤트로 이루어져 있다.
스프린트 계획 회의(Sprint Planning): 한 스프린트는 일반적으로 1~4주 단위로 진행된다. 스프린트 계획 회의 단계에서는 이번 스프린트 동안 무엇을 개발할지 결정한다. 기간 내 완성할 수 있는 구체적인 목표를 설정하는 것이 핵심이다.
데일리 스크럼(Daily Scrum): 데일리 스크럼은 매일 진행되는 짧은 회의다. 데일리 스크럼에서는 팀원 각자가 현재 작업 상황과 장애 요소를 공유함으로써 팀워크를 다지고 불필요한 혼선을 줄일 수 있다.
스프린트 리뷰(Sprint Review): 스프린트 리뷰는 스프린트가 끝난 뒤 개발된 기능을 팀과 이해관계자 앞에서 시연하고 피드백을 받는 시간으로 제품의 방향성을 점검하고 다음 스프린트를 준비하는 데 도움이 된다.
스프린트 회고(Sprint Retrospective): 스프린트 회고는 개발 과정 자체를 되돌아보며 무엇을 잘했는지, 무엇을 개선할 수 있을지 함께 논의하는 자리다. 스프린트 회고는 지난 스프린트가 단순히 제품을 만드는 데에 그치는 대신, 팀의 업무 방식까지 발전시킬 수 있게 돕는다.
스프린트의 흐름. 제품 백로그는 제품 전체 관점에서 무엇을 만들지 정리한 목록을 뜻하고 스프린트 백로그는 스프린트 동안 개발팀이 실제로 수행할 작업 목록을 가리킨다. ⓒ 아틀라시안중요한 것은 팀이 하나의 목표를 바라보며 더 나은 결과를 위한 작은 개선을 계속 이어간다는 점이다. 이러한 측면에서 스크럼은 단순한 프레임워크를 넘어 팀워크와 책임감을 기반으로 일하는 방식이라고도 말할 수 있다.
게임 제작 및 서비스, 워터폴과 애자일이 함께하다
게임 제작 및 서비스에서는 워터폴과 애자일 방식을 혼합하여 활용하는 경우가 많다.
게임 출시 이전에는 게임의 핵심 구조와 주요 콘텐츠를 확정하고 이를 기반으로 개발을 진행한다. 퍼즐 게임이라면 기본적인 게임 플레이와 UI/UX, 핵심 기능들을 미리 정해두는 것이다. 이 과정은 워터폴 방식처럼 진행된다.
하지만 게임이 출시된 이후에는 유저 피드백을 반영하며 고도화에 임해야 한다. 유저의 반응을 분석해 새로운 기능을 추가하거나 밸런스를 조정하는 등 유연한 대응이 필요하기 때문이다. 이 단계에서는 애자일 방식이 적용된다. 예를 들어 유저가 친구들과 경쟁할 수 있는 기능을 원하면 이를 빠르게 개발하여 업데이트하는 식이다.
판교 사투리: IT 업계의 독특한 언어문화
한편 게임 등 IT 업계에서 일하다 보면 마치 새로운 언어를 배우는 듯한 경험을 하게 된다.
앞서 애자일에 대해서 살펴봤는데 "애자일하게 일하자"라고 하면 그 방법론을 사용하자는 의미하는 것이 아니라, '유연하게 대응하며 일하자'는 뜻이 된다. 이런 독특한 표현들이 모여 '판교 사투리'라는 신조어가 생겼다.
많은 개발 용어가 영어에 뿌리를 두고 있어 생긴 것으로 보이는 이 독특한 말투에는 과도하게 멋을 부린 듯 조금 웃겨 보이기도 하지만, 새로운 업계로 들어온 사람들은 자연스럽게 이러한 용어를 배우고 이 '사투리'를 익히는 것이 빠른 적응의 첫걸음이 될지도 모른다.
아래는 대표적인 판교 사투리다.
이 정도는 아닙니다 아마도……. ⓒ 숏박스AS-IS, TO-BE: 순서대로 현재 상태, 이상적인 미래 상태.
MECE: Mutually exclusive collectively exhaustive. 각 부분 집합이 겹치지 않고(상호 배타적) 천체를 다 포함하도록(전체 포괄적) 설계하는 원칙. 복잡한 문제를 체계적으로 분해하고 분석하는 데 유용하며 누락, 중복을 방지하는 효과도 있다.
MVP: Minimum viable product. 제품이나 서비스를 핵심 기능만 포함해 최소한의 비용과 노력으로 제작한 뒤, 시장의 반응을 빠르게 확인하고 사용자의 피드백을 통해 개선해 나가는 전략.
가라: から. 가짜, 임의. "급하니까 우선 가라 이미지 사용하고 나중에 교체하시죠."
노티: Notification. 정보 따위를 알려주는 것. "담당자에게 회의 일정 노티 부탁드려요."
랩업: Wrap Up. 회의나 업무와 관련된 내용을 요약, 정리하여 마무리하는 것.
러프한: Rough. 세부적인 내용 없이 대략적인. "구체적일 필요 없으니까 러프하게 주세요."
레슨런: Lessons Learned. 게임 개발, 서비스 과정에서 얻은 경험과 교훈.
레퍼 체크: Reference check. 평판 조회. 채용 과정에서 지원자의 이전 직장 상사, 동료, 후배 등에게 지원자의 능력, 성격, 태도 등을 확인하는 것.
레퍼런스: Reference. 게임을 제작, 운영하는 데 참고로 하거나 영향을 받은 창작물.
리소스: Resource. 업무에 필요한 자원 총체. "저희 팀 세 명 밖에 없는 거 아시잖아요. 리소스(=일손)가 부족해요.", "프로모션 페이지 디자인을 시작해야 하는데 비주얼 리소스(=스크린숏)가 없어요."
리젝: Reject. 반려, 거절.
린한: Lean. 효율적이고 신속한.
마일스톤: Milestone. 게임 개발, 서비스 과정에 특정한 목표가 되는 중요한 단계나 지점. "이번 분기 마일스톤은 신규 직업 출시, 기존 직업 개편, 편의성 개선입니다."
맨먼스: Man Month, MM. 한 사람이 한 달 동안 수행할 수 있는 작업량
배리에이션: Variation. 원형을 다양한 형태로 변경하는 것. "먼저 배너 하나를 만든 다음, 문구나 이미지만 배리해서 쓰시죠."
사인오프: Sign off. 게임 전체 또는 하위 프로젝트의 최종 승인. 더 이상 수정하거나 변경할 부분 없이 다음 단계로 나아가거나 곧장 출시할 수 있는 시점임을 가리킨다. "체크리스트에 있는 항목 중 절반 이상이 개발되지 않은 상태라, 사인오프 리젝됐어요."
스탠스: Stance. 이슈에 대한 입창이나 태도. "밸런스 기획자님은 성수기 이벤트로 성장 재료가 풀리는 데 대해 상당히 보수적인 스탠스세요."
스펙아웃: Spec out. 게임 출시나 업데이트를 앞두고 예정된 기한 내에 목표한 사양을 모두 반영하기 어려울 때, 일부 사양을 의도적으로 제외하거나 연기하는 것. "주요 장면 다시 보기 기능 스펙아웃 됐대요."
싱크: Synchronize. 업무에 대한 이해도, 개인이나 조직이 처한 상황 등을 서로 비슷한 수준으로 동기화하는 것.
아삽: As soon as possible, ASAP. 가능한 빠르게. 긴급한 확인, 대응 요청 등에 사용한다.
아이데이션: Ideation. 새로운 아이디어를 창출하고 발전시키는 것. "서비스 1주년 기념 인포그래픽에 넣을 만한 내용을 아이데이션 해봅시다."
알앤알: Role and Responsibility. 업무와 책임의 수준. 지난 포스팅에서 살펴본 '범위 관리'와 연결하여 생각할 수 있다.
애자일한: Agile. 유연하고 민첩한.
어레인지: Arrange. 일정, 방향성 등을 조율하는 것.
어싸인: Assign. 일감을 담당자에게 할당하는 것.
얼라인: Align. 업무에 대한 이해도, 개인이나 조직이 처한 상황 등을 이해시킴으로써 방향성을 일치시키는 것.
와꾸: わく. 좁은 의미로 외관, 넓은 의미로 외관을 포함한 대략적인 설계. "설명만 들어선 잘 모르겠네. 와꾸 짜서 보여주세요."
원온원: One on one. 두 명의 참가자가 특정한 주제나 목적을 가지고 1:1로 만나 진행하는 미팅.
이슈: Issue. 현재 발생하고 있는 문제, 이야기하고자 하는 주제 등을 포괄적으로 이르는 말. "현재 퀘스트 메뉴의 [보상받기] 버튼이 클릭되지 않는 이슈가 있어요.", "오랜만에 메신저 주셨네요. 무슨 이슈 있나요?"
이슈라이징: Issue Rising. 이슈를 관계자가 지금보다 중요하게 취급하도록 강조하는 것.
이슈업: Issue up. 이슈를 관계자가 알 수 있도록 회의, 메일, 메신저 등으로 공론화하는 것.
캐파: Capacity. 감당할 수 있는 업무의 양, 수준. "수습 기간 동안 캐파 키우기를 목표로 할게요."
커피챗: Coffee chat. 비공식적인 자리에서 가볍게 커피를 마시며 궁금한 점을 문고 답하는 것.
컴: Communication. 주제에 대해 이야기를 나누는 것,
킥오프: Kick off. 축구에서 전반전, 후반전 시작 또는 특점 후 경기를 재개할 때 중앙 원에서 공을 차는 행위. 게임 개발에서는 유관 부서들이 처음으로 모여 프로젝트의 목적, 목표, 세부 사항 등을 논의하는 자리를 가리킨다.
타깃데이: Target Date. 목표한 적용 일정. "이 피처 타깃데이가 언제예요?"
팔로우업: Follow up. 게임 제작 또는 서비스 과정에서 발생한 문제를 지속적으로 확인 및 관리하여 해결하거나 개선하는 것.
퍼포먼스: Performance. 업무와 관련된 성과, 실적. "지난 하반기 퍼포먼스 좋던데요."
피보팅: Pivoting. 게임의 방향성을 빠르고 과감하게 전환하는 것. 문제를 발견했거나 기회를 포착했을 때 더 나은 결과를 위해 시도하는 전략적 결정.
피처: Feature. 게임이 유저에게 의도한 경험을 선사하기 위해 마련한 요소. 게임의 주요 메커니즘부터 특정 콘텐츠까지 폭넓게 지칭할 수 있다. "이거 이번 정기 점검 때 업데이트할 피처예요?"
경험상 한국어로 충분히 전달할 수 있는 표현이라면 굳이 영어를 쓸 필요는 없다고 생각한다. 심지어 한국어가 더 짧고 명료한 경우도 많다. 무엇보다 외부 미팅에 참석하거나 새로운 팀원을 맞이했을 때, 상대가 이 용어에 익숙하지 않다면 대화는 겉돌기 쉽다.
물론 예외는 있다. 슬랙이나 지라처럼 고유명사이거나, 한국어로 바꾸면 뉘앙스가 달라지는 단어들은 그대로 쓰는 것이 낫다. 예를 들어 '팔로우업'은 지켜본다는 의미를 넘어 필요시 개입하겠다는 태도까지 담고 있다. 이런 단어까지 억지로 바꾸려 하면 오히려 소통이 더 어려워진다. 하지만 그런 경우가 아니라면 나는 되도록 쉽고 효율적인 언어를 선택하는 것이 좋다고 본다. 용어는 나를 드러내기 위한 장식이 아니라, 함께 일하는 사람들과 빠르게 통하기 위한 도구이기 때문이다.
워터폴, 애자일부터 판교 사투리까지. 어쩌다 보니 이야기가 조금 옆으로 새기도 했지만, 이번 포스팅에서 다루고자 한 주제는 프로젝트를 어떻게 잘 이끌어갈 수 있을까에 대한 고민이었다.
기획자, 개발자, 아티스트처럼 일하는 방식과 사용하는 용어가 각기 다른 사람들과 온종일 부딪히다 보면 예상하지 못했던 상황이 생기고 계획이 틀어지는 일이 부지기수다. 이러한 어려움을 하나씩 해치우며 끝내 하나의 결과물을 완성하고 나면 어제까지 저마다 상이한 관점과 언어를 내세우던 사람들이 어느새 같은 방향을 바라보며 대화하고 있는 것을 자각하게 된다. 다양한 사람들을 이해하고 서로 말이 통하게 만드는 일은 때때로 고단하지만, 동시에 미지의 문화에 숙달되어 가는 재미를 맛볼 수 있다.
어쩌면 이 또한 프로젝트 매니징의 묘미가 아닐까 생각해 본다.
