[인벤게임컨퍼런스(IGC) 발표자 소개] 유석문 기술 이사는 NHN 지도지역서비스개발랩 팀장과 NHN NTS 부장, NHN 테크놀로지 서비스 이사직을 역임하였으며, 현재는 라이엇게임즈 코리아의 기술 이사로 활약하고 있다. 또한, 그는 프로그래머의 삶과 철학을 조명한 저서를 집필하였으며, 업무 효율 개선을 위한 노하우를 공유하고자 꾸준히 활동해왔다.

우리의 프로젝트는 왜 실패하는 걸까? 우리 조직 구조에 문제가 있는 것은 아닐까?

라이엇게임즈 코리아의 유석문 기술이사는 "오늘 강연에서는 우리 회사가 이렇게 잘하고 있으니 따라하면 됩니다, 라는 이야기를 하러 온게 아니다"라며 강연을 시작했다. 여러 시행착오를 거쳐왔고, 현재도 진행중이며, 그과정에서 배운것을 공유하고자 오늘 강연에 임하게 되었다고 전했다.

IGC 2017의 두번째날에는 라이엇게임즈의 유석문이사가 나와 '애자일 개발 프로세스'를 통한 개발 구조와 효과적인 조직문화에 대하여 강연했다. 라이엇게임즈에서는 어떤 시행착오를 통해 배워나가고 있는지, 어떤식으로 개발 프로세스를 구축해야하는지에 대하여 '애자일 프로세스'를 통해 설명했다.



▲처음엔 분위기가 좋다가 나중에는 분위기가 반전되기 마련

유석문 이사는 먼저 ‘버드와이저’ 광고를 보여주면서, 영상의 모습이 소프트웨어 개발의 초창기 모습과 비슷하다고 이야기했다. 처음 새로운 것을 만들 때는 분위기가 좋다. 유저가 좋아하는 게임을 만들자, 새로운 걸 만들어보자, 하는 마음으로 뭉치지만 어느 순간 분위기가 급변하는 순간이 있다.

개발이 시작된 후 동작하는 결과물이 나오기 시작할 때다. 만들어진 결과물을 보면 기획자들이, 유저들이 원했던 모습과 너무 다른 모습이 나오기 때문이다.

‘애자일’은 사실 생긴 지 오래된 개념이다. 1950년대에 소비자들이 원하는 가치를 전달하기 위해 만들어졌지만, 당시에는 주목받지 못했다. 1990년대에 들어와 대규모 정부 프로젝트의 실패로 인해 무엇을 개선해야하는가에 대한 고민이 시작됐다. 그 논의 끝에 다시 조명된 것이 ‘애자일’이다.

▲각자 생각하는 것이 다르다.

사용자가 원하는 것에 대해서 설명을 할 때, 사용자는 상상에 근거해 설명한다. 개발자들도 프로젝트 초기에는 사용자들이 이런 것을 원한다고 생각하고 개발을 시작하지만, 결과물은 유저들이 원하는 모습과 전혀 다를 때가 많다. 프로젝트 자체도 첫 구상을 따라가지 않을 때도 많고, 그대로 만들었다고 하더라도 유저가 정말 원하는 모습과는 다른 기획으로 구상되었을 확률이 높다.

“저희의 예시를 들자면, ‘다인큐’같은 거죠.”

소프트웨어 개발은 개발자들만이 하는 것이 아니다. 모두의 프로젝트다. 여러 사람이 모여있는 만큼 서로 쓰는 언어도 다르다. 외국인과의 대화가 어려운 만큼, 기획자와 개발자는 서로 원하는 것이 다르고 이해가 다를 수 있다. 모두가 똑같이 유저를 위한다고 하더라도 단계를 거치면 거칠수록 오해는 커진다. 이를 해결하는 것이 ‘애자일’이다.

애자일이 재조명받기 시작하면서 수많은 컨퍼런스들이 생겨났고, 애자일을 도입하는 사례도 생겼다. 최고 의사결정권자는 컨퍼런스를 다녀와서 ‘아, 이래서 우리가 실패했구나’, 하고 생각하게 된다. 애자일 컨퍼런스에서는 대부분 오류가 없이 빠르게 소프트웨어를 배포할수 있으며, 똑같은 인원으로 더 빠르게 업무가 가능하다고 이야기한다. 그만큼 영감을 받은 의사결정권자는 적극적으로 애자일 프로세스를 시도하고자 한다.

실무자의 경우는 변화를 좋아할 것 같지만, 사실 새로운 것을 도입할 때마다 새롭게 배워야 하므로 좋아하지 않는다. 따라서 적극적인 의사결정권자에 비해 회의적인 태도를 보인다. “이름은 거창한데, 이게 됩니까?” 하기 마련이다.

그래서 애자일 프로세스를 도입한 프로젝트들이 성공했는가. 사실 많은 프로젝트들이 전과 다를 것 없이 실패했다. 그만큼 최근에는 애자일 프로세스가 의미가 없다는 의견이 많아지고 있다.

그럼 애자일이 문제인가, 아니면 프로세스를 제대로 이해하지 못했기 때문에 성공하지 못한 것일까.

유석문 이사는 "경험한 것을 토대로 이야기하자면, 어떤 프로세스를 사용해도 프로젝트가 실패할 확률은 높다"고 말했다. 먼저 우리가 프로세스로 이용하는 것들은 체계화된 학문의 수준으로 완성된 것들이 아니다. 그만큼 운이 좋아서 팀원들이 잘 해내면 성공하는 거고, 분쟁이 생기면 실패하게 되는 것이다. 프로젝트에 따라 확실한 모델을 가지고 차례대로 잘되면 성공하는 거고, 외부적인 상황이 달라지면 실패한다. 중요한 것은 우리가 모든 것을 알고 있고, 상황을 통제할 수 있다는 생각을 버려야 한다. 대부분이 우리가 통제할 수 있다고 생각하기 때문에 실패하게 된다.



■ 개발 단계의 낭비 요소를 줄여라 -

그래서 라이엇은 애자일 프로세스를 어떻게 사용하고 있을까?


유석문 이사는 라이엇이 추구하는 가치가 ‘어떤 의사 결정할 때 기준은 첫째, 플레이어, 둘째, 회사, 셋째, 팀, 그리고 마지막이 개인의 이득’이라고 명시했다.이런 가치는 겉으로 보기에 멋진 회사가 되기 위해서가 아니라, 현실적으로 플레이어가 좋아하는 게임을 개발하고, 그들이 즐겁게 플레이하고, 이에 맞는 플랫폼을 만들어야 성공확률이 높으므로 중요하다.

라이엇게임즈는 신규 기능이나 게임 내 조정을 2주 단위로 배포하고 있다. 유석문 이사는 “배포하고 욕먹고, 고치고, 가끔 칭찬 듣고, 그런 방식이죠”라며, 애자일이 가지는 가장 중요한 가치는 ‘피드백을 빠르게 받는 것’이라서 설명했다.


그럼 피드백을 빠르게 받기 위해서 필요한 것은 무엇일까? 빠르게 피드백을 받기 위해서는 빠르게 플레이어에게 전달해야 한다. ‘사이클타임’을 줄이는 것이 중요하다. 어떤 시스템이 좋은지, 어떤 프로그램이 좋은지 개발자는 모른다. 따라서 어떤 결과물이든 내놓고 많은 이야기를 듣는 것이 중요하다.


사이클타임을 줄리기 위해서는 개발 단계에서 생기는 낭비 요소를 줄여야 한다. 낭비요소에는 먼저 디펙트(Defects), 버그다. 버그란 사용자가 원하지 않는 것들을 의미한다. 기능상 정상이어도 유저가 원하지 않는 요소라면 디펙트다.

Extra Features에 대해서도 고려해야 한다. 예를 들어 워드프로세서를 보면, 워드 프로세서의 핵심 기능은 글을 쓰고, 저장하고, 다시 열어보는 것이다. 그 외에 글을 예쁘게 꾸미거나 하는 기능은 부가적인 요소다. 개발에 있어서 기본적인 기능을 먼저 개발해 출시하고, 나머지 기능을 더해가면서 피드백을 받는 게 중요하다. 부가적인 기능에 많은 시간을 들이느라 출시가 늦어지면 낭비다.

기획자가 열 가지 기능을 가져오면, 그중 두세 가지는 핵심기능이고 나머지는 부가적인 기능이다. 기획자도 말해준다. “이 두 가지는 중요하고, 나머지는 가능할 때 합시다.” 개발자도 안다. 하지만 핵심 기능을 개발하다 보면 계속 부가적인 기능에 눈이 간다. “나중에 이 기능을 넣으려면 미리 이런 작업을 해놔야 하는데.” 그렇게 개발 시간이 늘어난다. 유저가 좋아할 것이라고 생각해서 넣는 기능이지만, 개발 시간을 늘리는 결과를 낳게 된다.

개발 시간을 늘리는 낭비 요소에는 핸즈오프(Hands Off)도 있다. 기획을 완료하고 개발단계로 넘어갈 때, 다음 단계에 있는 사람들은 전 단계에 무슨 일이 있었는지 모른다. 보고서로 정리되어있는 것을 보고 어떤 논의가 있었는지, 모호한 부분에서는 어떻게 결정이 되어있는지 다시 그 단계를 알아가야 한다. 따라서 이런 낭비를 줄이기 위해서는 기획단계에도 개발자가 참여해 각자의 의견을 내야 한다. 기획, 개발이 따로 진행되는 것이 아니라, 그 단계에 참여하는 것이 중요하다.

끝내지 않고 남긴 작업을 그대로 두는 것도 개발시간을 낭비하는 요소 중의 하나이다. 개발자는 코드를 지우는 것을 싫어한다. 이용하지 않은 코드라면 지우는 게 맞지만 언젠가 쓰겠지라는 마음에 지우지 못한다. 그렇게 시간이 흐르고 그 코드의 담당자가 팀에서 사라지고 새로운 담당자가 들어오면 그 담당자는 그 코드를 보면서 이걸 지워도 되는지 고민하게 된다. 그 사라진 담당자는 괴로운 퀴즈를 내놓은 거다. “네가 과연 이걸 지울 수 있을까? 못할걸?”

그외에도 여러가지 낭비 요소를 줄여야한다. 우선적으로는 디펙트를 줄이는 것이 제일 중요하다. 가장 효과적인 방법은 유닛 테스트를 진행하는 것이다. 코드 작성이 개발자 의도대로 되었는지 확인하고 빠르게 오류를 수정해야한다. 2010 구글 자료에 따르면 TDD단계에서 개발자가 바로 확인해서 수정하면 5달러의 비용이 발생한다. 하지만 빌드로 발전해 여러명이 모인 단계에서 테스트를 진행하면 50달러의 비용이 발생한다. 단계가 진행될수록 지출은 커져간다.


따라서 사이클타임을 빠르게 하기위해서는 낭비요소를 줄이는 것이 중요하고, 가장 우선적으로 디펙트를 줄여야한다. 그리고 그 디펙트를 줄이기 위해서는 최대한 빠르게, 단계가 진행되기전에 확인하고 수정해야한다. 자동화 빌드 테스트를 진행하는 이유가 여기에 있다.

코드 퀄리티는 중요하다. 코드 퀄리티가 좋을수록 자주 피드백을 받을 수 있고 플레이어들이 원하는 기능을 만들 확률이 높아진다. 물론 코드의 퀄리티가 높다고 반드시 성공한다는 것은 아니다. 다만 코드퀄리티가 높으면 피드백에서 나온 요구를 적용하기 빠르다는 장점이 있다. 그만큼 사이클타임을 줄일 수 있다는 뜻이다.

그만큼 자동화가 중요하다. 물론 자주 하지 않는 업무라면 수동으로 처리해도 된다. 하지만 반복적으로 매일, 매주 하는 작업이라면 자동화하여 빠르게 처리하는 것이 중요하다. 반복적인 작업을 잘하는 게 컴퓨터니까. 그렇게 시간을 아껴 인력은 더 중요한 곳에 사용해야 한다. 자동화의 목적은 ‘내 시간을 절약해서 좀 더 중요한 곳에 쓰겠다’는 데에 있다.



■ MVP, 매 단계 피드백을 받을 수 있는 방법

유석문 이사는 이어 MVP(Minimum Viable Product)에 대해서 이야기했다. 일반적으로 개발을 시작하면, 각각의 부분을 만들어 조합한다. '탈것'을 만든다고 가정하면, 핸들, 바퀴, 몸체를 제작한 후 조합하는 것이다. 애자일 프로세스에서는 모든 단계에서 구동이 가능한 것을 만든다는 점에서 다르다. 첫 단계에서부터 스케이트보드처럼 간단한 것을 만들더라도 움직이는 것을 만들어내야 한다. 그다음 단계를 넘어갈 때마다 조금씩 더해져 자전거, 자동차까지 나아가는 것이다.


라이엇게임즈에서도 같은 방식으로 진행하고 있다. 물론 완성된 새로운 기능을 선보이듯 내보내기도 하지만, 대부분 간단한 단계에서부터 내보낸 후 플레이어들의 피드백을 통해 개선해나가는 것이다.

애자일과 관련해 스크럼 개발 방법론도 많이 언급되는 부분이다. 여기서 중요한 점은 정보를 공유하는 시간을 갖는 것이다. 하지만 매일 만나서 이야기한다는 점이 중요한 것이 아니다. 정보가 공유되고 있다면, 출시는 2주 단위다, 라는 룰만 지켜지고 있다면 상황에 따라 유동적으로 이루어지는 것이 좋다.

"애자일 개발 프로세스를 잘못된 방법으로 적용한 조직을 볼 때 안타까울 때가 많다."고 유석문 이사는 그 방법 자체보다 그 핵심을 짚는 것이 중요하다고 강조했다. 애자일 프로세스를 잘 지키고 있다고 착각하는 경우가 있다. 애자일 프로세스를 적용한다는 것은 매일 회의를 하고 있다거나, 아침마다 미팅한다는 점이 중요한 게 아니다. 자동화와 피드백이 잘 이루어져야 한다는 점이 중요하다.


위 XP Practices 구조를 보면 가장 중요한 것은 가운데 코어 부분이다. 코어부분이 제대로 이루어지고 있지 않다면 바깥 고리는 의미가 없다.

테스트 기반 개발은 앞서 말했든 유닛 테스트가 중요하다. 내가 원하는 기능이 개발되고 있는지 확인을 해야 한다는 것이다. 다름은 Refactoring, 외부에 드러나는 것은 그대로 두고 내부를 고쳐나가는 것이다. 물론 이 단계는 유닛 테스트가 기반으로 이루어져야 한다. 확인하지 않는다는 것은 마치 고쳐놓고 운이 좋게 문제가 없기를 바라는 것과 같다.

Pair Programming은 코드를 작성하면서 실시간으로 이루어져야 하는 부분이다. 신규 멤버가 들어오거나 문제가 까다로울 때 모여서 코드 리뷰를 하는 것이 좋다. 코드를 작성한 사람도 시간이 지나면 잊어버리기 마련이다. 그만큼 진행에 차질이 생기게 되므로, 사람이 읽었을 때도 읽을수 있는 수준인지 확인해보는 것이 좋다. 라이엇게임즈에서도 이 단계를 거치지 못하면 아예 코드를 활용할 수 없도록 정해져 있다.

이때 소프트웨어 장인정신을 지키는 것이 중요하다. 먼저, 피드백에 단순히 빠르게 대응하는 것이 아니라, 그때마다 반드시 가치를 더해나가고 있는지 확인해야 한다. 특히, 플레이어 가치에 맞도록 하는 데에 집중해야 한다.



■ 라이엇, 사내 문화를 만들어 나가다

이어 유석문 이사는 라이엇만의 독특하고 효과적인 사내 문화, RFC(Request for Comment)에 대해서 설명했다. 새로운 기술을 만들 때 대부분 기획서를 만들고 관련자를 찾아가 설명하게 된다. 그게 아니라, 라이엇에서는 현재 관련 문서를 작성하면 누구나 볼 수 있도록 공개한다. 그걸 보고 사람들이 피드백을 주고 더 좋은 아이디어를 제시하기도 하며, 아이디어를 덧붙이기도 한다. 더 나아가 그 기술을 원하는 다른 팀에서 함께 개발해서 적용할 수 있도록 기술의 적용범위를 새로 정하기도 한다. 라이엇 전체에 적용할 것인지, 라이엇 코리아에만 적용할 것인지, 기술이 필요하다면 함께 협력하고 기술을 사용한다.

조직이 커지면서 어떤 조직에서 이미 만든 기술인데 다른 곳에서는 모른 채 개발하는 때도 있다. 그런 일이 없도록 서로 정보를 공유하고 이미 있는 기술이라면 알려줄 수 있는 환경을 만드는 것이다.

또한, 라이엇은 다양한 테크 서밋과 AMA(Ask Me Anything)을 진행하고 있다.


썬더돔 : 2박 3일동안 하고 싶은 개발하고 싶은 것을 개발할 수 있는 시간을 가진다.
테크서밋: 개발자들이 모여서 그동안 해온 작업에 대한 정보를 공유한다. 1년에 한 번 진행하고 있다.
AMA(Ask Me Anything) : 기술이나 조직문화 등 관련자에게 무엇이든 질문하고 답변을 듣는 행사다. 중요한 질문도 나오지만 캐주얼하게 탁구대를 만들어달라는 요청을 하기도 한다. 궁금한 것이 있을 때 물어볼 수 있도록 질문할 수 있는 장을 오픈하는 취지에서 이루어지고 있다.

이어서 유석문 이사는 효과적인 개발 조직 문화에 관하여 이야기했다. 라이엇에서 원하는 인재상은 스스로 동기부여를 하는 사람이다. 동기부여는 외부에서 하기 힘든 부분이고, 자금으로 해결되는 문제도 아니다. 그만큼 게임을 좋아하고 좋은 게임을 만들고자 하는 동기부여가 확실한 사람을 필요로 하고 있다고 말했다.

그리고 회사에서는 그런 사람들에게 좋은 환경, 성장할 수 있는 환경을 만들어줘야 한다. 계속해서 스스로 그 열정을 잃지 않도록 환경을 제공해야 한다.

그러기 위해서 중요한 것은 협업이다. 단계별로 집중하는 사람이 다르다면 협업이 어렵다. 기획에서 개발까지 모든 인원이 참여하고, 협업하는 구조로 가야한다. 더 나아가 유석문 이사는 데드라인을 정할 때는 개발자들이 가능한 날짜를 만들어야 한다고 강조했다. 물론 마케팅적으로 맞춰야 하는 기한이 있다면 그만큼 개발해야 할 규모를 조정해야 한다.

▲데드라인은 개발팀을 위주로

또 한 가지 중요한 것은 성장할 수 있는 환경을 만들어줘야 한다는 것이다. 공부할 수 있도록 지원을 해주고, 팀 안에서 배울 수 있도록 분위기를 조성하고, 일하면서 배울 수 있도록 해야한다. 예를 들어 애자일을 제대로 지키지 않는 사람이 있다면, 대중 앞에서 강연을 하도록 유도해야 한다. 자신의 목소리로 강연하면 그만큼 자신이 말한 것을 지키려고 하는 경향이 있다.


수평조직도 효과적인 개발환경을 조성하는 데 중요하다. 수직적인 조직에서는 실무자가 아이디어가 생겼을 때 의사결정을 위해 여러 단계를 거쳐야 하는 것이 일반적이다. 그만큼 딜레이가 발생한다. 게다가 가장 똑똑한 사람이 매니저가 되기 마련이지만 그렇다고 그 사람이 매니지먼트를 잘해내는 것도 아니다.

"라이엇에는 직급이 없으며, 서로 이름으로 부릅니다. 근데 저는 기술 이사를 직급으로 명시하고 있지요? 직급은 대외적으로는 필요할 때가 있어요. 그래서 자기가 원하는 직급을 아무거나 골라 붙일 수 있도록 하고 있어요. 팀장이 좋다면 팀장, 이사가 좋다면 이사."

하지만 물론 책임감은 모두 가지고 있다. 자신의 역할에 충실하고 그에 맞춰 책임은 져야한다. 유석문 이사는 그렇다고 권력을 부여받고 의사결정에 힘이 생기는 것은 아니라고 설명했다.

마지막으로 유석문 이사는 여러 시행착오 끝에 배운 것에 대해서 이야기했다. 먼저, 조직을 키우는데 시간이 오래 걸린다는 것이다. 유석문 이사는 3년 전 자신이 라이엇에 입사할 당시 팀은 20여 명으로 구성되어있었다고 말했다. 3개월 정도면 팀이 크게 성장할 것이라 생각했지만 3개월 동안 늘어난 팀원은 단 한 명이었다. 현재는 38명으로, 좋은 조직은 빠르게 규모가 키우는 것이 아니라, 시간을 들여야 하는 작업이라고 이야기했다.

"조급해하지 마세요. 빠르게 교육해보자고 시도해봤지만 하고 싶지 않은 것을 요구할수록 성과는 안나옵니다. 끈기 있게 기다려주고, 단기간 적으로 생각하면 안 됩니다."

▲조직은 정원과 같다

조직은 예쁜 정원과 같다. 한번 가꾸면 끝인 것 같지만, 잡초는 계속 자라나고 그만큼 관심을 계속해서 가져줘야 한다. 조직은 망가지기 일쑤다. 유석문 이사는 "한 명이 아니라 모든 조직원이 함께 가꿔나가도록 노력해야 한다"며, 강연을 마무리했다.