<플래닝카드 이벤트 응모를 위해, 최근 글로 갱신합니다.>

애자일에 대한 지극히 개인적인 회고 먼저.

  한동안. 애자일에 꽤 열광하던 때가 있었다.

  그게 언제쯤이었냐 하면. T팀에서 B팀으로 옮기고, PM과 디랙터가 없는 팀에서 열심히 해보려던 때였다. 원래 조직, 프로젝트, 스케줄 관리에는 전혀 관심을 가지지 않으려 했으나, 상황은 이러하고, 어찌 되었든 게임을 잘 만들고 싶어서 뭐든 하려고 할 때였다.

  그러나, 뭔가 시도해 보기도 전에 좌절했다. 사람들 (정확히는 관리 성향이 없는 일반 팀원들)이 애자일에 대한 좋지 않은 인식이 생겨 버린 것이다. (아이러니하게도, 김창준님께서 회사에 오셔서 세미나를 한 것이 원인이 되었다. 물론, 김창준님을 비난하려는 것이 아니다. 김창준님의 세미나는 충분히 좋았다. 단지 팀 분위기가 어둡고, 새로운 것을 받아들이는데 매우 부정적이고 까칠하던 상황에 세미나가 열려 버려서, 사람들이 모두 부정적으로 받아들이게 된 것일 뿐.) 애자일은 리더에 의한 방법론이 아니라, 모든 사람들의 마음속에 들어가는 행동 원칙이 되어야 할 텐데... 첫 단추를 끼우기 전부터 좋지 않았다. 뭐 어쨌거나, 도전은 했다. 스탠딩 회의도 해 보고, 나름 상황판도 만들었으나... 역시 결과는 좋지 못했다.

  그 뒤로, 애자일은 쳐다보지도 않았다. 대신 린을 조금 살피다가, 원론적인 전통적인 시스템도 보다가... 그냥 처음처럼 매니징에 신경을 쓰지 않기로 했다.

다음에는 책 이야기. 애자일 회고.

위와 같은 이유로 프로듀서용 책 읽지 않기로 결심 했는데.
애자일 책 읽지 않기로 결심 했는데 팀 문화에 대한 관심 하나 때문에 이 책을 주문했다.
요즘 화두중 하나가 어떻게 하면 팀을 좀 더 잘 뭉쳐서 부드럽게 굴릴 수 있을까... 이기 때문이다.

책을 펴자 마자... 서문부터 뭔가 와 닿는다.
그리고 바로 찾은 회고에 대한 김창준님의 글.

3Fs : 사실, 느낌, 교훈(Fact, Feeling, Finding)의 세가지 F를 뜻합니다. 예를 들어, "뭐뭐뭐를 해봤다. 그래서 어떤 느낌이 들었다. 그리고 거기에서 어떤 교훈을 얻었다"의 형식을 사용합니다. - 애자일 이야기

다른 분야에서는 이런 것들이 그렇게 새로운 개념이 아니지만 (칭찬일기라던가.. 그런 것 쓸 때도 같은 원칙으로 이와 거~의 유사한 3가지 관점 방법론을 쓴다.) IT분야에 적용시켰다는 점은 무척 멋지다!


감상과 기록들.

• 무척 쉽게 씌여졌으며, 아주 구체적인 방법들이 잘 나와있다. 역시 문제는 적용이겠지. 전반적인 실천은 못하더라도, 상황에 맞게 요소 요소만 따오더라도 도움이 될 수 있어 보인다.
• 이 책의 저자는 회고계의 여신 2분이다. 칭호에서도 나왔지만 여성분이다. 역시 이런 일에는 여성이 좋구나... 라는 생각을 다시 한번 하게 되었다. 고누소프트 시절, 이PM님이 생각난다.
• Facilitator : 회의의 진행자 이상의, 촉진자가 되어야 한다. 모든 사람의 참여를 유도하려면.
• Check-in : 회의에 들어가기 전에, 간단히 모든 사람에게 말을 거는 것. 누구나 대답할 수 있는 질문을 던진다. 마음을 열 수 있게 만들면 더 좋지만, 감정을 이야기 하는 것이 서툰 개발자들을 대상으로 할 때는 우회적으로 질문한다. 꼭 대답을 하는 게 중요하다. 회의 초반에 말을 하지 않으면, 끝날 때까지 말을 하지 않을 가능성이 크다.
• 감사하기 활동. 서로에게 감사하는 말을 해라. 관계의 질이 달라질 것이다.
• Make it so. 스타트랙을 한번 봐야겠다.

중요한 것은 역시 사람이다.
닫힌 마음을 열어 주는 것 만으로도 멋진 일이 생길 수 있으리라 생각한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

   2009년 처음 소개할 책인 Game Architecture and Design는 개인적으로 의미 깊은 책이다. 이 책은 나에게 아마추어를 막 벗어나려는 시기부터 몇 년간 항상 옆에 끼고 항시 참조했던 교과서 같은 책으로, 게임 디자이너로서 자리를 잡는데 큰 도움을 준 책이다. 출시된 지는 꽤 지났지만, 지금 보아도 그 가치는 떨어지지 않았으며, 초심을 돌이켜 볼 수 있는 거울과 같은 역할을 해준다.

   모든 시대의 예술가들은 선조로부터 물려받은 생각과 작품에서 영감을 얻었다. 창조적인 작업이란 완전히 새로 만드는 것이 아니고 여러 출처로부터 조금씩 빌어온 아이디어를 새롭게 조합하여 새로운 작품으로 엮어내는 것을 말하는 것이다. ~ 그러므로 완전히 새로운 발상을 얻고 싶다면 남들이 좀처럼 하지 않았던 일을 해야 한다.
   초기의 영화감독들은 새로운 영상 매체의 가능성 때문에 매우 들떠 있었다. 그들은 스크린에 담아내기 위해 다양한 분야로부터 가리지 않고 영감을 얻어냈다. 오늘날 팀 버튼에게까지 이어져 내려오는 독인 표현주의의 계보는 동화, 연극 그리고 프로이드 심리학의 요소들을 조합하고 있다. ~ 스터워즈는 뮤지컬 드라마에 텔레비젼용 연속극을 혼합한 형식을 취하고 있다.
   영화 감독들은 이렇게 다양한 곳에서 아이디어를 긁어 모아서 좋은 결과를 얻고 있지만대부분의 게임디자이너들은 그렇게까지 모험적이지 못했다.

   세계 제일의 게임 크리에이터인 미야모토 시게루는 인생 속의 여러 가지 경험, 취미 등에서 발견한 재미 요소들을 통해 게임의 아이디어를 얻는다고 한다. 어릴적 동산을 뛰어다니던 경험이 젤다를 만들었다는 것은 유명한 이야기이며, 최근 NDS로 출시해 큰 성공을 거둔 닌텐독스 역시 가족들과 강아지를 키운 경험을 토대로 만들어 졌다고 한다. (소문에 의하면, 이러한 미야모토 시게루의 개발 방식 때문에 닌텐도에서는 미야모토 시게루의 취미와 최근 관심사를 '기업적 비밀'로 다루고 있다고 한다.) 윌라이트는 집이 불타버린 후, 새 집에 가구들을 채워 넣는 과정에서 심즈의 영감을 얻었다고 한다.
   다른 분야에서도 이와 비슷한 조언은 많이 찾아볼 수 있다. 예를 들어, 건담의 아버지인 토미노 요시유키는 애니메이터를 꿈꾸는 사람들에게 애니메이션만 좋아하면 오타쿠가 될뿐, 좋은 애니메이터가 될 수 없다고 조언하고 있다. 토미노 요시유키는 다양한 인생경험을 하면서 다른 이에게 전하고 싶은 것을 찾은 뒤, 만들고 싶은 것에 그 경험을 투영하라고 이야기 한다.
   현재 존재하는 게임들을 많이, 깊게 즐기는 것도 새로운 게임을 만드는데 많은 도움을 줄 수 있을 것이다. 하지만, 이러한 경험과 지식만으로 만들어진 게임은 충분한 독창성을가지기 힘들 것이라고 판단한다.

   발상의 전환해서 생각을 해보라, 도대체 '게임'일 필요가 뭐가 있는가? ~ 가장 중요한 것은 '이것 진짜 게임이야'가 아니라 '이것 진짜 재미있어!'인 것이다.

   때로는 '게임'을 만든다는 생각 조차 게임을 만드는 창조력의 발목을 잡을 수 있다. 물론 '재미있는 것은 다 좋다.' 라는 말을 하는 것은 아니다. 재미있지만 게임이 아닌 것은 얼마든지 있기 때문이다. 하지만 재미를 느낄 수 있는 요소를 잘 이해하고 분석한다면 재미있는 게임을 위한 영감이나, 소재를 얻을 수 있을 것이다.

   민주적인 과정에 대해서 말하자면, 나는 그런 식으로 해서 잘 만들어진 유일하게 쓸모 있는 결과물은 미국 헌법 정도라고 생각한다.

   나는 게임은 프로듀서 / 디랙터의 전적인 지휘를 통해 개발되는 방식, 이른바 철인주의를 지지한다. 프로듀서나 디랙터가 아닌 어떤 개발자도 새로운 아이디어를 제시하고, 토론에 참여하고, 비판을 제기할 수 있다. 하지만 그것을 평가하고 받아들이는 것은 프로듀서 / 디랙터의 몫이다. 물론 이것은 프로듀서 / 디랙터가 모든 게임 디자인을 다하고, 다른 게임 디자이너들은 서포트만 하라는 뜻이 아니다. 게임의 전체를 생각하는 프로듀서 / 디랙터가 디자인하고 결정할 부분과 게임의 부분 부분을 책임지고 디자인할 부분은 서로 다르다는 뜻이다.

기획자 노트
   기획자 노트는 기획서를 구상하는 동안 머리에서 굴러다닌 많은 생각들에 대해서 써 내려간 문서이다. ~ 게임 기획서의 한 문장은 많은 시간 동안의 심사숙고의 결과물이다. 그러나 나중에 '무엇이다'라는 것은 기억 할 수 있어도 '왜'라는 것을 기억하지 못하게 된다.

   중요한 내용이다. 어떤 요소를 디자인 하고 게임에 반영을 한 뒤 게임을 플레이 해 보았을 때, 의도와 다르게 나오는 것은 게임을 개발하면서 마주할 수 있는 흔한 상황이다. 이러한 상황에서는 디자인 문서를 다시 검토하고 가설을 검토하고 문제를 찾아야 하는데, 이럴 때 '어떻게' 생각해서 이런 결과를 얻었는지 그 이유와 생각의 과정을 알 수 있다면 다시 디자인하는데 훨씬 수월하게 된다.

   가장 최근의 게임 개발 방식에 대한 생각은 반복적인(iterative) 방법이 가장 효율적이라는 것이다. 개발에 있어 몇몇 나선형 개발 방법을 따르면 불투명한 전망도 위험도 적당한 수준으로 맞출 수 있다.

   이 문장을 읽고, 무릎을 칠 수 밖에 없었다. 반복적 개발 방법, 나선형 개발 방법론은 "애자일" 개발론의 핵심 키워드이다. 애자일 개발 방법론이 개발자들 사이에서 회자되고, 개발 프로세스에 적용되기 시작된 것은 그리 오래되지 않았다. 물론 이 책은 오래된 책이다.

   구성요소의 비순차적 관계에서 기본형식은 수정이 거의 불가능하다. 5개의 요소로 구성되는 관계를 설정했는데 나중에 1개의 요소를 뺀다면 그 관계설정이 제대로 작동할 리 없다. ~ 반면에 개발 중에 구성요소를 추가시키는 것은 어렵지 않다. 추가되는 구성요소가 다른 요소들과 대칭구조를 이룰 필요가 없다. ~ 여기서 교훈은 명백하다. 게임 디자인의 규모를 결정할 때 되도록 하향조정하라.

   가위, 바위, 보에서 '가위'와 '바위'만 개발한 뒤, 스케줄의 문제로 '보'가 개발되 전에 게임을 출시하는 것을 생각해 보자.

허구에 대한 자발적인 믿음 (Suspension of disbelief)
   스토리는 납덩어리를 금으로 바꾸어주는 현자의 돌이기도 하다. 모양새를 꾸미는 작업은 몰입감 높은 게임 분위기를 형성하여 허구를 믿도록 만드는 것이다. 하지만 플레이어가 별로 허구를 믿고 싶어하지 않는다면, 즉 설득력 있는 스토리가 없다면 아무리 모양새가 화려해도 소용없다.

   허구에 대한 자발적인 믿음. 기억해둘 만한 키워드이다. 온라인 게임에서 말하는 현장감(be there)과 큰 연관이 있다고 생각된다.

   아직 존재하지 않는 기술이 필요한 게임은 만들지 말라. ~ 누군가 시도했다가 제대로 만들어내지 못한 기술도 마찬가지다. 연구개발이라는 것을 개발의 일부로 착각하지 말도록 하자.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

예전에, 사람들과 이야기 하며 팀장을 우산에 비유했다.

• 좋은 팀장은 투명한 비닐 우산이다. 하늘은 잘 보이되, 빗방울을 잘 막아준다.

• 보통 팀장은 불투명 우산이다. 하늘은 안보이더라도, 비는 맞지 않는다.  

• 안 좋은 팀장은 찢어진 우산이다. 하늘이 찢어진 틈새로 조금씩 보이지만 비에 젖는다.

• 물론, 하늘은 가리면서 빗방울은 아주 잘 투과시켜주는, 도저히 존재할 수도 없고, 존재한다고 해도 아무런 의미를 가지지 못하는 우산 같은 팀장도 있기는 할 것이다. 차라리 그냥 비를 맞는 게 더 좋을 것이다.

• 갑자기 여기에 하나를 추가시고 싶다. 상당히 안 좋은 팀장은 반쯤 찢어진 불투명 우산이 마구 흔들리고, 돌아가는 것이라고. 하늘이 보이기는 하나 온전한 하늘을 보기는 힘들며, 특히 특정 방향만 보이기 때문에 전체를 파악하지 못한다. 물론 비는 맞는다. 여기에 악의가 포함된 "우산 컨트롤 스킬"이 들어간다면 어떻게 될까? 하늘의 일부만 의도적으로 보여준다면? 교묘하게 우산을 돌려, 한 조각 햇살이 비치는 곳만 보이게 한다면 어떤 일이 생길까. 그리고 우산을 교묘하게 돌려, 우산 밑에 있는 여러 사람 중 일부 사람들만 비를 맞게 한다면?

• 물론 최악의 팀장은 위에서 펴진 게 아니라, 사람들 사이에 펴진 우산일 것이다. 사람들을 뿔뿔이 찢어 놓는 것은 조직의 장악력을 높이는 손쉬운 방법이다. 물론 이 것은 눈 가리고 아웅 이고, 진실은 언젠가 밝혀진다. 이쯤 되면 하늘이 보이는 것이라거나, 비에 맞는 것은 신경도 쓰지 않게 될 것은 당연할 것이다.

조금만 부연 설명을 하자면...

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

waterfall개발 방법론에 한계를 느끼고, 새로운 개발 방법론을 찾던 중 눈에 들어온 Agile.
예전에 관심을 가졌으나, 자료가 부실하여 그만 둔 적이 있었습니다. 그때는 실험적인 개발 방법론으로만 보였고 실제 사례도 거의 없었으니까요.
하지만 최근에는 다양한 문서(국내 번역 문서도!)가 존재하며, 국내에서도 개발에 적용하는 사례가 있다고 합니다. 현재 다양한 자료를 훑어보며, 현재 프로젝트에도 적용할 수 있을까를 고심해 보고 있습니다.

애자일이란 어떤 것인가? 다음 개발 선언문을 보면 그 핵심이 무엇인가 알 수 있습니다.

애자일 게임 개발 선언문
(Manifesto for Agile Game Development)

우리는 다음의 것들을 가치있게 여긴다;

공정과 프로젝트 관리 도구보다, 사람들과 의사소통을 더 중요시한다.

완전한 기획 문서보다, 제대로 작동하는 게임을 더 중요시한다.

마일스톤의 정의보다, 배급사와의 협력을 더 중요시한다.

계획을 따르는 것보다, 변화에 대응하는 것을 더 중요시한다.

다시 말해서, 왼쪽에 있는 것들이 비록 가치있긴 하지만,

우리는 오른쪽에 있는 것들에 더 큰 가치를 둔다는 것이다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.