• 테크
  • 워크

넷마블 게임을 만드는 CTO, 어떻게 일할까?

이 스토리는 <게임 회사가 일하는 방법>1화입니다

3줄 요약

  • 넷마블 잼팟의 조광래 CTO는 게임회사가 겪는 단계를 총 4단계로 분류합니다. 초창기-성장기-활황기-성숙기에 따라 CTO와 팀이 일하는 방식이 달라진다고 하죠.
  • 아이디어를 맨바닥에서 실제 게임으로 구현하는 과정에서 중요한 건 동료와의 협업과 기술 문화입니다. 조 CTO는 이 순환을 윤택하게 만드는 게 그의 역할이라고 설명하죠.
  • 개발자가 좋은 도구 외에 꼭 가져야 할 자질은 뭘까요? 조 CTO는 '호기심'이라고 설명합니다. 호기심이 있는 개발자는 빠르게 성장한다는 게 그의 생각입니다.



게임은 그동안 '재미있는 것'으로만 여겨지는 취향의 영역이었습니다. 하지만 세상이 변하면서 게임 업계가 일하는 방식을 전 산업이 연구하며 접목하고 있습니다. 

게임회사들은 실제로 어떻게 일하고, 성과를 내고 있을까요? 이들이 직접 소개한 자기들의 일하는 방식, 업계의 트렌드를 스토리북 <게임 회사가 일하는 방법>에 담아봤습니다. 

* 이 콘텐츠는 네이버클라우드가 개최한 <게임×컨퍼런스>에서 진행된 강연을 폴인이 텍스트 리포트로 만든 것입니다.

2021년 10월15일에 온라인으로 열린 네이버클라우드 <게임×컨퍼런스>에서 강연을 하는 조광래 넷마블 잼팟 CTO. (출처 : <게임×컨퍼런스> 영상 캡처

저는 넷마블 잼팟(Netmarble Zempot)의 CTO(Chief Technology Officer) 조광래입니다. 사회 입문 때부터 소프트웨어 엔지니어로 일한 저는, NHN 한게임과 NHN 엔터테인먼트를 거쳐 넷마블에서 일하고 있습니다.

여기서 저는 게임회사의 CTO로 생활하면서 배운 것을 나누려 합니다. 각 회사가 겪는 단계별로 어떤 경험이 있고, 어떤 걸 준비하고, 어떤 걸 챙겨야 하는지 정리하고자 해요. 순서는 초창기-성장기-활황기-성숙기-그리고 Always(언제나 챙겨야 할 것), 5단계입니다.

초창기: 맨바닥에서 게임 아이디어 구현하려면?

먼저 창업 초창기입니다. 처음에는 맨바닥에서 모든 걸 다 할 때죠. 물론 아무것도 없이 뭔가를 할 수는 없습니다. 보통 게임 회사는 어떤 게임을 만들어보자는 기본적인 아이디어는 갖고 있습니다. 다만 상업적으로 시장에 내놓기 전 여러 검토를 진행하죠.

'POC(Proof-of-Concept)'라든지, 'Prototype(프로토타입)', 그리고 'MVP(Minimum Viable Product)' 등을 통해 사전 검증을 합니다. 특히 프로토타입 단계에서는 디자인과 사용성, 기능 등을 통합해서 시험하는 작업이 필요해요. 그다음 게임에서도 정말 재미있는지 '핵심 재미'를 검증해야 합니다.

이 단계가 게임에선 굉장히 중요합니다. 왜냐하면 일반 기능성 앱과는 달리 게임에선 '재미'라는 요소가 제일 중요하기 때문입니다. 초창기에 핵심 재미를 잡지 못하고 바로 상용화에 도전하면 실패할 확률이 높습니다.

그다음 사람이 있어야 뭔가를 만들겠죠. 동료를 구해야 합니다. 좋은 팀을 구성하는 게 첫 목표가 됩니다. 당연히 누구나 좋은 멤버들을 영입하고 싶을 겁니다. 하지만 이게 쉽지 않아요. 그렇기에 평소 업계나 지인을 통한 인맥 네트워크를 잘 유지하는 게 중요합니다.

이 단계에서 많이 질문을 받는 게 있습니다. '팀은 소수 정예가 좋을까요? 아니면 사람 수가 많은 게 좋을까요?'라는 질문이죠. 초기 단계를 기준으로는 기민하게 움직여야 하기에 소수 정예로 작은 조직을 만들어 민첩하게 움직이는 게 좋습니다.

그리고 또 이런 질문도 받습니다. '능력과 태도 중에 무엇을 먼저 봐야 하느냐'라는 질문이죠. 우선 흑백 논리로 능력과 태도를 일렬로 보지 않았으면 합니다. 그 둘의 균형을 잘 보되, 무게중심을 조금 더 둬야 한다면 태도에 두길 권해요.

능력이 조금 부족한 건 리더가 얼마든지 메꿀 수 있지만, 태도는 그럴 수 없기 때문입니다.

문제는 좋은 팀을 구성한 다음입니다. 생각보다 리더들이 팀을 유지하는 데 신경을 쓰지 않는 경우가 많아요. 이게 더 중요한데도 말이죠. 좋은 팀을 계속 강화하고 유지하는 게 정말 중요합니다.

간혹 이런 경우를 볼 때가 있습니다. 상황이 너무 급해서 능력도 조금 떨어지는데, 인성까지 좋은 평가를 받지 못한 인력을 급하게 좋은 팀에 넣는 거죠. 그런 인력이 합류하는 순간 그 좋았던 팀은 간단하게 깨져버립니다. 이런 실수를 범하지 않도록 조심해야 합니다.

그리고 협업 시스템은 초창기에 도입해야 합니다. 필수적으로 도입해야 할 것들로는 'Knowledge Base(지식 베이스)', 그다음 'Issue Tracker(이슈 트래커)', 그리고 'Communication Tool(소통 도구)', 'Code Repository(코드 저장소)'가 있습니다.


ⓒ조광래, 네이버클라우드

보통 지식 베이스는 'Wiki(위키)'라 불리는 시스템을 많이 도입합니다. 이슈 트래커 역시 버그와 문제 발생을 추적하는 여러 시스템이 있죠. 소통 도구는 'DM(Direct Message)'이나 그룹 메시지를 통해 빠르게 대화할 채팅형 프로그램이 있고요. 코드 저장소는 개발자 협업을 위해서 반드시 존재해야 하는 시스템입니다.

여기서 가장 중요한 게 있습니다. 협업 시스템은 반드시 유기적으로 연결돼 있어야 한다는 점이에요. 만약 서로 분절돼 따로 놀게 되면, 없는 게 차라리 나아요. 복잡한 시스템만 늘어나게 되거든요. 그래서 이 시스템을 유기적으로 엮어서 통합하는 게 핵심입니다.

게임회사가 초창기에 또 할 일이 있습니다. 각종 'Tech Stack(기술 요소)'을 선택하는 겁니다. 우리는 게임을 어떻게, 어떤 기술 요소를 이용해 만들 것인지를 결정하는 건데요. 렌더링 엔진과 물리 엔진, 네트워크 엔진을 선택합니다.

이때 중요한 건 선택의 기준이에요. '우리 게임을 품을 성능이 계속 나오는가, 또 확장성이 있는가'에 대한 것들이죠. 시장에 얼마나 많은 레퍼런스가 있는지도 고려해야 하고요.

이런 선택을 할 때 너무 현재에만 집중하면 나중에 발생할 피드백과 요청을 탄력적으로 대응할 수 없습니다. 반대로 너무 먼 미래를 생각해서 이런 걸 다 수용해 개발하면 제품을 출시하는 시기가 연기될 수 있습니다. 무작정 빠르게 갈 수 없기에 현재와 미래 사이의 'Threshold(문턱)'를 잘 판단해 결정하는 게 중요합니다.

한 가지 더, 초창기에는 관리보다 개발이 중요합니다. 그렇기에 개발에 '초집중'을 해야 해요. CTO도 마찬가지로 '크레이지 코딩 머신(Crazy Coding Machine)'으로 빙의해 불꽃 개발을 해야 합니다. 업계에선 '손가락에 땀 나도록 코딩한다'는 이야기를 하죠.

이렇게 하려면 동료들이 개발에 집중할 시간을 잘 확보해줘야 합니다. 개발자들은 코딩하며 집중하는 데까지 30분 정도가 필요합니다. 그런데 누군가 와서 이 집중을 깨면 다시 몰입하는 데 또 그 시간을 들여야 하죠. 그래서 방해받지 않는 환경을 잘 조성하는 게 필요합니다. 코딩 시에 생산성을 높이는 방법이죠.

성장기: 준비한 아이템과 동료와 잘 달리려면

이상의 내용이 게임회사가 초창기에 갖춰야 할 준비였습니다. 이제 성장기인데요. 저는 이를 '위대한 항로로 떠난다'고 표현합니다. 즉, 앞에서 준비한 아이템과 동료를 바탕으로 성장하기 위한 도전을 하는 단계죠.

ⓒunsplash

이때 CTO는 가장 많은 항목을 준비하고 챙겨야 합니다. 'Dev Culture(데브 컬처, 개발 문화)'를 1순위로 꼽는데요. 좋은 기업문화가 있어도 경영자의 노력 없이는 분위기가 촉진되지 않는 것처럼, 기술 조직도 CTO의 노력 없이 좋은 기술 문화를 만들 수 없습니다.

긍정적인 문화를 유도하는 게 굉장히 중요합니다. 활발한 소통이 필요하죠. 그러려면 동료들에게 많은 정보를 능동적으로 공유해야 해요. 그래야 참여할 의지가 높아지고, 동료들이 더 많은 능동성을 발휘합니다. 다양한 시도 역시 존중해야 해요. 이 과정이 반복되면 좋은 문화가 형성됩니다.

성장기 단계에서 실질적으로는 게임의 'Architecture(아키텍처, 구조)'를 잘 잡아야 돼요. 일정이 급해서 아키텍처를 잡지 않고 코딩부터 한다는 분들도 있는데요. 그렇게 시작하면 정리되지 않는 코드와 아키텍처로 인해 중·후반부로 갈수록 작업 속도가 떨어집니다. 안정성도 떨어지면서 '진짜' 고통받게 되죠. 그래서 초반에 아키텍처를 설계하는 것이 필요하고, 이 일이 CTO가 가장 집중해야 하는 실무입니다.

물론 정답은 없습니다. 상황에 따라 모두 다르기에 성능과 확장성, 생산성 등을 고려해 Trade-off(트레이드 오프, 상충관계)를 잘 판단해야 하고요. 저는 아키텍처를 설계할 때 'One-system, One-role(원 시스템, 원 롤)'의 원칙으로 최대한 명확하게 일하는 걸 선호합니다. 그렇기에 시스템 개수가 많아지면 논리적으로는 분리하고, 물리적으로는 병합하는 작업을 하는 게 좋습니다.

또 하나, 'DevOps(데브옵스)'*는 개발의 핵심인 코드에 집중하기 위한 필수 요소입니다. 좁게 보면 그동안 데브옵스는 'Build(빌드)' 배포의 자동화를 의미하는 경우가 많았습니다.

*DevOps : 소프트웨어 개발 방법론의 하나로, 개발(development)과 운영(operation)을 결합한 혼성어다. 개발 담당자와 운영 담당자가 연계해 협력하는 개발 방법론을 말한다. (출처 : 두산백과)

광의로 보면 데브옵스는 다음의 큰 순환을 모두 포함합니다. 빌드 및 배포 후 운영된 뒤 사용자의 피드백을 받고, 또 그 피드백을 통해 사업·기획에서 정제된 요구사항을 내놓고, 이걸 다시 디자인과 개발에 녹여 만들고 배포하는 작업까지요.

이 작업을 가급적이면 신속하고 빠르게 자동화해 이 단계가 반복되는데 부하가 걸리지 않도록 하는 게 중요합니다. 결국 핵심은 누구든지 와서 클릭하면 빌드가 되고 배포가 되게끔 간단히 구성하는 것입니다.

이 맥락에서 '인프라'인 클라우드의 변화도 주목할 만합니다. 예전에 인프라는 소프트웨어 개발자의 영역이 아니었어요. 하지만 클라우드가 등장하면서 소프트웨어 개발자가 서버 영역에서 클라우드의 구성을 이해하지 못하고 작업하면 어려움을 겪는 일이 많아졌습니다. 그래서 필수 지식 요소가 되고 있고요.

일도 늘어나고 영역도 확장되니, 이 단계에선 더는 소수로 일을 끌어갈 수 없습니다. 동료들도 복수의 팀에 속하며 조직적으로 움직여야 하죠. 동시에 다수의 인재를 계속 영입해야 합니다.

CTO는 채용에 적극 관여하고 노력해야 해요. 채용된 분들이 경력을 개발하며 성장할 수 있도록 케어도 해야 합니다.

동료의 성장이 회사의 전략과 'align(얼라인)' 돼서 함께 성장하는 선순환 구조를 만들도록, CTO가 중간에서 노력해야 합니다.

그리고 인력 관리도 계속 필요합니다. 이때는 권한을 적극적으로 위임을 하되, 사람들을 적극 돌봐야 하죠. 왜냐하면 IT 분야는 공장의 컨베이어 벨트 위에서 제품을 만드는 게 아니라 사람이 컴퓨터로 제품을 만들어가는 것이기 때문이죠.

개인별로 역량이 어떤지 파악해서 그에 맞는 업무를 잘 배분해야 합니다. 자칫하면 잘하는 사람에게만 업무를 주다 보면 중장기적으로 업무 밀도가 높아져서 작업의 질도 떨어지고, 나머지 분들의 기회도 박탈하는 결과가 될 수 있어요. 그렇기에 경험이 많지 않은 개발자도 도전할 기회를 계속 부여해야 해요. 조금 부족한 면이 있다면 리더가 적극적으로 개입해 그걸 해소하도록 노력해야 합니다.

모든 업계에서도 마찬가지겠지만, 도전해서 성과를 냈을 때 거기서 얻는 동기부여가 가장 큰 원동력입니다. 이 부분을 계속 도전할 수 있도록 적극 케어해야 합니다.

또 '기술 부채'를 관리하는 게 있습니다. 보통 기술 부채는 불가항력적이거나, 판단에 따라 너무 무리하게 진행할 때 생깁니다. 업계에선 속된 말로 '땜빵형 코드', 단기 처방용 코드에 해당하는데요. 그렇다 보면 코드가 전부 꼬이는 '스파게티화'하고 시스템도 엉망진창이 됩니다.

결국 유지보수 압력은 늘어나고 구성원은 그 압력을 견디지 못하고 다 이탈하는 거죠. 자연스럽게 업무의 속도도, 안정성도 저하되고요. 그렇기에 CTO는 어떻게든 기술 부채를 개발자들이 잘 풀 수 있도록 신경을 써야 합니다.

이를 푸는 방법 중 아웃소싱이 있는데요. 이 역시 전부 다 맡기는 '턴키' 방식을 택할지, 협업 방식을 택할지 등을 고려해 전략적인 판단을 해야 합니다. 즉, 업무를 통합해 중앙 관제를 하고, 자동화할 것은 잘 맡겨서 위험 요소를 빠르게 관리하는 것이 필요합니다.

활황기: '고인물'의 등장을 막으려면

성장기를 거치면 이제 '활황기'를 맞습니다. 저는 이를 '기술의 대항해 시대'라고 표현하고 싶습니다.

이때 필요한 건 '기술 비전'입니다. 동료의 수가 많아졌고, 비대해진 조직이라면 '고인물 같은 전형적인 생각을 하는 경우가 나타납니다. 이를 타개하려면 회사와 사업의 비전, 그리고 기술의 비전을 얼라인해서 지속적인 소통을 하는 게 필요합니다. 그렇게 생각의 차이를 줄여야 하죠.

조직이 같은 'Aim(목표)'을 바라보면 강력해집니다. 앞서 성장을 위해 단기적으로 뛰었다면 일관된 방향을 유지하기 위한 장기 로드맵이 그 역할을 할 때죠. 예를 들어 CTO가 직속 조직을 만들어 직접 드라이브를 거는 것도 방법입니다.

이때부터 CTO는 '기술 대변인'이 아닌, 회사 전체를 통합적인 시각에서 바라보고 여러 직군을 문제없이 잘 연결해 시너지가 나게끔 하는 역할을 맡죠.

내부에선 다양한 시도를 하는 여러 업무를 보면, 적극적으로 지원해야 합니다.

실패해도 그 과정이 훌륭했다면, 칭찬과 박수를 보내야 합니다. 그렇게 혁신적인 결과물이 나오도록 촉진해야 하죠.

외부로는 회사의 가치를 전파하는 'Evangelist(에반젤리스트)'의 역할로 기술 브랜딩을 위해 블로그를 운영하거나, 글을 기고하는 일도 맡죠.

개발자에게 가장 중요한 자질은 뭘까?

회사의 '성숙기'는 수천 명의 동료가 생기는 시기입니다. 개인적으로 저는 CTO로서 이 단계를 경험하진 못했습니다. 대신 'Always(항상)', 늘 염두에 둬야 할 항목을 넣었어요.

즉, 어떤 단계로서가 아닌 늘 나누는 이야기들입니다. 이런 질문을 자주 받습니다. '개발자는 어떤 자질이 필요합니까?'라고요. 그럼 저는 이렇게 답합니다. 호기심과 몰입, 자긍심과 능동성, 즐거움 등이 필요하다고요. 그리고 좋은 PC와 큰 모니터, 훌륭한 키보드와 마우스가 필요하다고 하죠.

여기서 제일 중요한 건 '호기심'입니다.

호기심이 왕성한 개발자는 빠르게 성장해요. 다양한 업무도 잘 받아들이죠. 궁금해서 못 참고 항상 학습하기에 조직 내에서도 빠르게 성장합니다. 결국 조직 안에서 많은 일을 참여하고 다루게 되죠.

ⓒ조광래, 네이버클라우드

이런 질문도 받습니다. 'CTO는 코딩해야 합니까'라는 질문요. 회사 초창기에는 CEO도 총무와 회계, 재무 업무까지 맡습니다. 청소도 하죠. 그러니 당연히 CTO는 손가락에 땀이 나도록 코딩을 해야 합니다. 특히 회사의 초창기와 성장기 때는요.

그 이후가 되면 비개발 업무가 늘어나죠. 이때는 직접 코딩을 하기보다 의사 결정을 잘못했을 때 생기는 폐해를 막는 일을 해야 합니다. 경영진과 구조를 짜는 사람으로의 역할을 성실히 수행해야 해요. 회사가 활황기에 접어들면, 올바른 전략과 의사 결정에 집중하세요.

저는 리더라는 걸 이렇게 생각합니다. 리더는 일을 시키는 사람이라고요.

일을 시키지 않으면 리더가 아닌 거죠. 그렇다면 어떻게 시켜야 하냐. 노는 게 아니고 일을 잘 시키기 위해 준비하고 배분해서, 일이 잘되도록 하는 거죠.

그리고 리더는 결과를 책임지는 사람입니다. 판단하고 진행했다면, 그 결과에 책임을 져야 합니다. 리더가 누릴 것만 누리고 책임을 지지 않으면 리더십이 발휘되지 않습니다.

저는 업무의 결과는 리더의 판단과 진행의 결과이며, 이를 '100% 내 책임'이라고 보는 소명 의식을 갖고 일합니다.

마지막으로 나누고 싶은 이야기는 '조직문화'입니다. 고대부터 협업은 인류가 살아남기 위한 최고의 수단이었습니다. 협업에 집중하세요. 그리고 다른 직군을 이해하기 위해 노력하세요. 그게 자기를 성장시킵니다.

개발자로서 필요한 건 방향과 결과, 그리고 말. 삼박자를 갖추면 제일 좋습니다.

성장 과정에서 코딩의 문법부터 구조까지 본인이 생각하는 폭을 단계적으로 넓혀야 합니다. 단계별로 필요한 걸 빠르게 적용하고, 결과도 빨리 보는 게 좋아요. 그래야 실패하더라도 그걸 교훈 삼아 빠르게 새로운 걸 시도합니다.

마지막으로 제일 중요한 건 이를 진행하는 커뮤니케이션입니다. 상하좌우를 가리지 않고 편한 소통이 일할 때 중요합니다. 이걸 가능케 하려면 권한과 책임을 가진 분들이 더 노력하는 게 필요합니다.





지금 폴인멤버십 가입하면
1,400여 개 스토리를 무제한으로!

폴인멤버십 회원 이OO님 폴인은 저에게 더 나은 내일을 만들 수 있다는
자신감을 주는 무기예요

  • 멤버십 혜택 첫번째

    디지털 콘텐츠
    무제한 열람

  • 멤버십 혜택 두번째

    온라인 세미나
    월 2회 무료

  • 멤버십 혜택 세번째

    각종 온/오프라인 행사
    상시 할인

Top