커리어리 스킬업과 파이썬 강의를 찍었습니다!

안녕하세요. 소난입니다.

최근 근황

이전에 2021년 배우면 좋은 프로그래밍 언어에서 올해에 언어로 파이썬을 이야기했던 적이 있는데요. 이를 실천하고, 전파하기 위해 이번에 커리어리 스킬업이라는 직장인을 위한 온라인 강의 플랫폼과 함께 파이썬 강의를 찍었습니다 🙂

이 강의를 찍으면서 정말 다른 강사분들을 저절로 존경하게 되더라구요. 정말 ‘지식을 누군가에게 전달한다는 것은 아무나 하는 것이 아니구나’ 라는 생각이 많이 들었습니다.

오늘은, 이 강의를 찍으면서 제가 경험했던 내용들이나 강의에 담고 싶었던 내용들을 여러분들에게 공유하고 싶어 이렇게 포스트를 써보려고 합니다 😍

(마지막에 제가 찍은 강의에 대한 소개와 선물도 있습니다 😎)


강의 기획 단계

이 강의를 찍을 때, 강의의 방향성에 대해서 많은 고민을 했었습니다. 고민의 시작점은 프로그래밍 언어 강의 하나 들어서 정말 프로그래밍을 할 수 있나요? 였어요.

요즘 파이썬 강의라던가, 다른 프로그래밍 강의가 너무 많기도 하고, 많은 강의들이 따라하기만 하면 마스터가 된다거나, 코딩으로 무엇이든 할 수 있을 것처럼 이야기하곤 있지만, 제가 들은 대부분의 강의는 그렇지 않았던게 고민의 시작점이였던 것 같습니다.

(제가 2020년 연말에 제가 강의를 3개를 샀는데ㅠㅠ 그 강의들이 도움이 1도 되지 않았던 것도 저의 고민을 더욱 증폭 시키는 촉매제였지요…)

그래서, 어떻게든 도움을 주는 강의를 만들고 싶었습니다. 프로그래밍 강의지만, 쉽게 얻을 수 없는 정보를 줄 수 있는 강의를 지향하면서, 마음먹고 프로그래밍을 시작하려는 사람들에게 프로그래밍의 개론적 개념을 충분히 전달 할 수 있는 강의를 원했습니다.

이런 제 마음속 희망 사항은 주변에 제가 멘토링했던 후배들이나 비전공분야 직군으로 협업하고 있는 분들의 영향이 컸던 것 같습니다. 그런 분들에게 도움이 되길 바랐습니다.

그래서 생각보다 커리어리 스킬업쪽과 예정되었던 것보다 많은 미팅을 진행했었고, 여러번 커리큘럼을 바꿔야 했습니다. (도움주셨던 PD님, 감사합니다)

하나의 강의에 담을 수 있는 주제는 한정적이고, 그렇다고 정말 많은 걸 담아서 강의를 장기 프로젝트로 끌고 나가는 건 또 원하는 방향이 아니 였기 때문이죠.

(사실 전 강의가 길어지면 길어질수록… 더 포기하시는 분이 많다고 생각했거든요. 80시간 짜리 강의… 들으라고 하면 전 포기할 것 같아요..)

그 관점에서 실행 가능한 안으로 여러 번의 조율을 거친 덕에 촬영까지 제가 원하던 강의로 잘 마친 것 같습니다.


리허설과 촬영

많은 분들의 도움 덕분에 커리큘럼은 잘 나왔는데……..문제는 촬영이 였죠. 특히 제가 경험이 없었기 때문에 겁이 나는 부분도 있었습니다.

촬영… 명확한 타게팅을 했음에도, 그 타게팅과 직접적으로 면대면이 아닌, 비대면으로 지식을 전달하던 그 시가 올해 제가 제일 많은 걸 배운 시기가 아니였나 싶습니다. 리허설을 하면서, 제 생각보다 제가 말을 할 때 작은 습관들이 있다는 것도 깨닫게 되고, ‘자세히 설명한다고 설명했지만 놓치는 건 있다.’ 라는 제 3자의 눈의 중요성을 깨닫게 된 시기가 아닌가 싶습니다. 정말 오랜만에 많은 피드백도 받았구요. 신기하게 피드백 받으면서 뭔가 신선한(?) 에너지가 생기는 경험도 했습니다. ㅋㅋㅋ


후기를 마무리하며,

정말 신기하게도, 강의를 진행하는 내내 꽤 재밌었고 에너지를 얻었습니다. 이상하게 제가 신입 때 낯선 환경, 낯선 업무를 하던 생각이 나기도 하고… 열정(?)이랄까요? 뭔가 열정이라는 게 전이되는구나 싶기도 했습니다. (커리어리 스킬업에서 도움주시는 분들이 정말 엄청나게 열정적이셨거든요)

그리고 정말 완전 다른 분야에 있는 분들(커리어리 스킬업 PD님들)에게 피드백 받으니까, 평소에 제가 생각했던 부분을 다시 한번 생각해볼 수 있는 기회가 됐었던 것 같습니다. 이래서 세상을 넓게 보라고 하는건가 봅니다. 많은 경험도 중요하다고 하는 것도, 다 이유가 있구나.. 를 깨닫는 기회였던 것 같습니다.

이제 제가 촬영한 강의를 소개해드리며 이 글을 마무리 하겠습니다!


강의 소개

강의 바로 가기

비전공자 개발자 만들기 프로젝트 : 파이썬으로 시작하는 프로그래밍 입문 강의 입니다.

개발자 커리어를 시작하려는 분들, 개발자가 적성에 맞는지 확인해보고 싶으신 분들을 위한 강의구요. 강의를 통해 개발자가 되기 위한 코딩에 대해서 배워가실 수 있게 만들었습니다.

주로, 파이썬과, 개발자에 대한 이야기를 많이 담았고, 수강 해서 후회 없으실 만한 핵심 정보로 담았습니다.

강의에 담으려고 노력한 것들!

  • 비전공자분들을 위한 최근 개발자 채용 트렌드!를 분석해서 담았습니다.
  • 파이썬이라는 언어가 왜 좋은 지를 담았습니다.
  • 개발자가 되기 위한 코딩을 이야기하고 싶었습니다.
  • 개발자에 도전하는 분들에게 진짜 도움이 되는 내용을 담았습니다.
  • 각 프로그래밍 문법(반복문, 조건문, 함수등)의 개념이 왜 필요한지를 담았습니다.
    • 외우는 개념이 아닌, 스스로 생각하는 개념을 지향했어요.
    • 개념만 알면, 코딩테스트도 풀 수 있다는 걸 보여드리고 싶었습니다.
  • 지하철에서도 편하게 보실 수 있게 녹화했습니다.
    • 강의 하나하나를 독립적인 주제로 촬영했습니다.
    • 하나의 강의 시간은 15분을 넘기지 않으려고 노력했습니다!

마지막으로, 제가 여러분에게 드리는 작은 선물입니다. 이 쿠폰을 이용하시면, 엄청난 할인이!!

📧 코치의 깜짝선물 : 성장 응원 쿠폰 📧

  • 쿠폰 링크 : 코치의 응원 쿠폰
  • 쿠폰 금액 : 1만원 할인 쿠폰
  • 사용기간 : ~ 7/16 23:59
  • 사용 방법 : 링크 클릭 → 쿠폰 발급 / 강의 구매하기를 누르면 자동으로 쿠폰이 적용됩니다.

감사합니다 🙊

제품 프레임워크 : Proven, Better, New

이 글은 Product Management : Science And Emotion 에서 Proven, Better, New에 해당하는 부분을 번역, 요약한 글입니다.

The Framework

프로덕트의 성공에는 과학적 접근과, 감정의 컨트롤이 필요합니다. 제품을 만드는 초기 단계는 가장 흥미롭고 중요한 시기이고, 다양한 접근법이 있습니다. 오늘 소개시켜드릴 주제는 해당 접근 법 중 하나인 “Proven, Better, New”라는 프레임워크 입니다. 사실 Proven, Better, New 는 1960년 제약 업종에서부터 시작했습니다.

각 키워드의 정의는 아래와 같습니다.

  • 이미 있는 기능은 Proven, 다른 프로덕트에도 있는 것을 의미합니다.
  • 차별 되는 기능은 Better, 이는 다른 프로덕트에 있지만 개선한 것입니다.
  • 마지막으로 new이며 다른 프로덕트에 없는 것을 의미합니다. new는 새로운 기능이나, 기능에 대한 새로운 조합이 될 수 있습니다.

예를 들어, iPhone은 2007년 런칭됐는데, 이를 다음 프레임워크에 비유해볼 수 있습니다.

  • Proven은 전화를 걸 수 있는 폰과 iPod 및 인터넷은 이미 존재하는 프로덕트 였습니다.
  • Better는 기존 스마트폰들의 UI/UX 디자인을 대폭 개선했고, 키보드를 없애고 스크린으로 채운 것과 터치로 하는 인터넷 익스플로러의 탄생이였습니다.
  • new는 이 모든 피쳐가 하나의 장치에 있었다는 것이죠.

이 프레임 워크는 특정 제품을 개선하는데도 쓰일 수 있습니다. ProvenBetter는 유저들이 이미 선택한 것들을 반영하기 때문에 실패에 대한 리스크를 줄이는데 큰 도움이 되며, 반대로 new는 종종 신제품 성공의 원동력이지만 높은 수준의 위험을 수반합니다. 돌이켜보면, iPhone의 주요 위험은 이걸 하나로 합친 장비를 사람들이 기꺼이 프리미엄 가격을 주고 채택하느냐였습니다. 돌이켜보면 이는 리스크가 아니였고, 역사를 만들었습니다.

해당 프레임워크를 가장 잘 활용한걸로 알려진 징가의 CEO Mark에 따르면, 프로덕트를 proven,better,new로 분해하는 능력은 PM이 여러 제품을 선별하거나, 기능에 집중할 때, 기회와 위험을 평가할 수 있게 만듭니다.

새로운 아이디어를 만들 때도 사용할 수 있을까요?

이 프레임워크의 흥미로운 점은 예측 목적으로 확장될 수 있다는 것입니다. 예를 들어, 징가의 팜빌(Farmville) 이 대박 났습니다. 그리고 슈퍼셀에서 런칭한 헤이데이는 Proven된 게임성에 모바일에 완벽히 적응한 new로 성공을 했습니다.

팜빌과 헤이데이처럼, 이미 증명된 컨셉으로 새로운 플랫폼이나 시장에 도입되는 많은 예가 있습니다. 새로운 시장은 혁신과 성공에 많은 기회가 있습니다. 이는 검증된 걸 새로운 플랫폼에 적응시키기만 하면 되기 때문입니다.

이 프레임워크가 있는데 우린 왜 실패할까요?

많은 사람들이 이 프레임워크가 성공을 보장해주지 않는다며, 프레임워크들을 낮게 평가합니다. 이 프레임워크와 이론들은 확실히 성공을 보장하지 않지만, 여러분의 프로덕트의 성공 확률을 극대화 하는 데 도움을 줍니다. 많은 사람들은 일반적으로 객관성을 잃습니다. 그들은 제품을 만드는데 시간을 소비하고 자신을 분리하는 것을 어려워 합니다. 사람들은 자신이 원하는 것을 회사 내에서 증명하려는 경향이 있습니다. 허나 우리는 솔직해야 합니다. 고객의 피드백을 듣는 게 중요합니다.

올바른 아이디어는 사용자가 말하는 것이 아니라, 사용자가 제품으로 무엇을 하는 지에 대해 관찰하는 것입니다.

감사합니다.

더 볼만한 자료

[GDC2017] 게임 스튜디오 리더쉽을 보고,

Schell Games의 Founder인 Jesse Schell이 2017 GDC에서 한 내용으로, 2020년에 유튜브에 공개되었다. 최근 유튜브의 알고리즘이 이곳으로 인도하여 보게되었는데, 평소에 관심있던 조직빌딩쪽이라 매우 재밌게 보게됐다. 전반적으로는 게임 스튜디오를 키우고 만드는 방법에 대해서 설명하고, 2017년 자료이지만 개인적으로 매우 와닿았던 부분만 정리한다.

개발자의 가치(Developer Value)

  • 기술
  • 열정
  • 존중하는 태도

기술 * 열정 * 존중하는 태도 = 개발자의 가치

유능한 개발자는 능력주의에 기반한 능력만 고려하지 않는다. 물론, 능력이 좋다면 일반적으로 가치는 높다. 허나, 실제로 업계에서 존경받는 개발자는 실력과 더불어 오는 중요한 포인트들이 있다. 이 발표에선 그걸 열정존중하는 태도라고 이야기했는데, 1000% 동의한다.

열정 이란 단어는 국내에는 열정페이와 같은 안좋은 인식으로 인해 조금 오해의 소지가 있지만, 내가 생각하는 열정은 당신이 만드는 제품을 사랑하는 마음이다.

좋은 피드백(Good Feedback)

  • 다면 피드백은 필수
  • 누가 평가에서 A,B,C인지 분명히 해야하고, 사람들은 자신의 위치를 알 필요가 있다.
  • C는 개선되어야 하고, 그렇지 않다면 방출을 고려해야 한다.

도움이 되는 코칭(Helpful Coaching)

  • 1:1 미팅을 위한 시간을 확보해야한다.
  • 1:1 미팅는 최우선 순위를 갖는다.
  • 핵심가치와 원칙을 지속적으로 상기시켜야한다.
  • 서로가 코치가 될 수 있도록 도와야한다.

조직적인 레벨에서 피드백과 코칭에 대한 이야기이다. 사실 게임업계에 있으면서 나는 피드백이나 코칭에 대해서 매우 보수적이라고 생각한다. 이는 국내 정서상이나 노동법상의 차이에서 오는걸 수도 있다고 생각하는데, 최근에는 다른 IT기업에서의 유입이나 문화들이 섞이면서 회사에서도 적극적으로 피드백이나 코칭을 권장하고, 조직적 문화 관점에서 건전한 피드백을 주면서 동시에 성장할 수 있는 분위기를 만들기를 원한다. 특히, 여기서도 강조한 1:1미팅은 어떤 규모의 조직이건 매우 중요한 포인트인 것 같다.

투명한 정보

  • 누구도 당신의 마음을 읽지 못한다.
    중요한건 반드시 오버 커뮤니케이션 해라.
  • 중요한 걸 되풀이 하는 것은 매우 도움이 된다.
  • 그래서 반복은 중요하다.
  • 다양한 방법으로 중요한걸 지속적으로 이야기해라.
  • 중요한 내용을 자주 듣는 것이 충분히 듣지 못하는 것보다 낫다.
  • 중요한 것 : 반복해라.

중요한 내용에 대해선 팀 모두가 알고, 공유해야한다. 실제로 중요한 것은 무한히 반복해서 세뇌될 정도로 반복하고, 이 게임이 바라는 재미는 무엇인지, 우리는 어떤 미션(Mission)을 갖고 게임을 만들고 있는지 등을 계속 제시 해야 한다. 팀이 같은 중요한 것을 바라보고 있을때 시너지는 그 어떤 능력(skill)보다 뛰어날 수도 있다.

서로를 존중

  • 서로를 존중하는 태도를 가져라.
  • 다른 사람이 존중 받는다고 느낄 수 있는 능력을 가져라.

팀원을 좋아해라

  • 호감(likability) 은 유능함(competent)보다 중요하다.

팀원을 존중하고, 좋아 해야 한다는 점은 얼핏 들으면 뻔한말이지만 생각보다 힘들다. 이기적인 팀원이 있을수도 있고, 내가 존중해주는 만큼 존중받지 못한다거나, 때론 정치적으로 이용당할 수도 있다. 이에 대한 해결법은 다양하지만, 개인적으로는 나 자신을 돌아봐야한다고 생각한다. 대부분의 사람이 ‘나는 그렇지 않아’, 라고 생각하지만 실제로는 본인이 이기적인 팀원일 수 있다. 그래서 내가 받는 존중도 중요하지만, 내가 주는 존중도 중요하다. 내가 혹시 상대방의 말을 끊고 있진 않은지? 토론이 아니라 일방적 설득을 하고있진 않은지를 수시로 고민해야하고, 성찰해야한다. 그래야 성장하고, 그래고 존중도 받을 수 있다.

스튜디오의 성장 규칙

  • 5명 이상 : 프로듀서가 필요하다, 앞으로 매 개발자 10명당 한명씩 필요하다.
  • 10명 이상 : 의사소통을 위해 하위 팀 미팅이 필요하다.
  • 20명 이상 : 코칭 책임을 선임할 필요가 있다.
  • 30명 이상 : 풀타임 IT 전문가가 필요하다, 매 50명마다 한명씩 필요하다.
  • 40명 이상 : 부서들이 필요하며, 각각 리더가 있어야한다.
  • 50명 이상 : 풀타임 HR이 필요하고, 재정 및 회계도 있어야한다.
  • 60명 이상 : 부서 내부의 코칭을 위해 두개의 관리 계층이 필요하다.
  • 150명 이상 : Dunbar’s number에 도달했다. 조직을 쪼개야한다.

간혹, 어떤 게임이 200명이상 사람이 만들었다는 이야기를 듣거나, 어쎄신 크리드는 1500명이서 개발한다라는 이야기를 들으면 그 방대한 스케일과 조직 규모가 상상이 잘 안됐다. 물론 지금도 잘 안되지만, 사람이 20명만 모여도 정보가 혼탁해지거나 관리비용이 부족한 경우를 많이 봤는데 생각보다 그 부분이 조직이 멋진 게임을 만드는데 큰 걸림돌이 되기도 한다. 그 관점에서 이 가이드는 팀 확장을 고려하는 사람들이나, 관리비용에 대해 구체적인 대안을 얻고 싶은 사람들에게 매우 유용하다고 생각한다. 특히 내가 생각하는 중요한 부분은 이거다.

  • 매 개발자 10명당, 1명의 프로듀서(아마도, 국내에선 PM인듯하다)가 필요하다.
  • 부서들이 생기면, 각각 리더가 있어야한다.
  • 코칭 책임과, 내부의 코칭에 대한 관리 계층도 있어야 한다.

당신의 팀에 리더프로듀서는 충분한가?, 팀이 만들고 있는 중요한 필라에 대해서 지속적으로 세뇌(?)당하고 있는가? 그 정보에 대해서 당신은 얼마나 솔직하게 피드백하고, 이야기하는가? 좋은 게임을 만들기 원한다면 조직을 준비하는 이 발표를 이용해, 우리 조직을 평가해보는 것도 좋지 않을까 라는 생각이 든다.

《인스파이어드》를 읽고,

출처 : yes24

만들만한 가치가 있는 프로덕트가 아니라면, 엔지니어팀이 얼마나 휼륭한지는 아무 의미가 없다.

인스파이어드, P3

이 책을 읽게 된 가장 큰 이유

세상에는 수없이 많은 게임 스튜디오와 개발사가 있다. 그들은 자신만의 게임을 개발하지만, 그 중에 정말 많은 수의 게임이 출시도 못하고 사라진다. 왜 이렇게 게임 만드는 것은 어려운가라는 질문으로 시작해서, 찾게 된 책이 이 책이다.

IT 프로덕트에 대한 프로세스를 이해하면 게임쪽에 대한 좋은 힌트를 얻을 수 있지 않을까?

프로덕트 개발에 대한 모든 것

프로덕트를 잘 만들 기 위해서는 좋은 프로덕트를 발견하는 것에서 시작되어야 한다. 이 책을 관통하는 가장 주요한 이야기 중 하나다. 이 책은 기술 프로덕트를 만들 때 필요한 모든 과정을 기술하고 있는 책이다. 팀을 어떻게 구성해야하는지, 어떻게 프로덕트를 발견해야하는지, 어떻게 테스팅하고, 점검하는지까지 말이다.

책에선 엄청나게 많은 프로덕트를 발견 기법을 소개하고 있다. 동시에 많은 프로토타입 기법도 소개한다. 그런 기법들을 관통하는 철학은 하나다. 프로덕트의 강력한 가치를 구축하는 것, 이를 위해 유저에게 많이 물어야하고, 정말 많은 프로토타입을 만들었다가 버려야 한다고 이야기한다.

우린 애자일로 개발하는게 아니다.

책은 시작부터 커다란 충격을 준다. 우선 프로덕트의 보편적인 개발 진행을 이야기한다.

아이디어 -> 비지니스 케이스 -> 로드맵 
-> 요구사항 -> 디자인 -> 구현 -> 테스트 -> 배포

그리고, 많은 회사에서 디자인 -> 구현 에서 애자일 방식을 이용해 개발한다고 한다. 그렇다. 정말 많은 회사에서 이렇게 개발을 한다. 어디서 나오는지 출처를 모르는 태초의 아이디어가 있고, 그 아이디어 안에서 틀을 두고 디자인하고 구현한다. 허나 책은 바로 그 다음, 아래와 같은 이야기를 한다.

요즘 거의 모든 사람들이 하고자 하는 ‘애자일’을 잠깐 언급했었다. 하지만, 내가 방금 설명했던 상황은 완전히 폭포수 프로세스에 대한 것이었다.

인스파이어드, P18

책에 이 내용을 보자마자 난 이 책을 꼭 다 읽어야겠다고 결심했다. 내가 너무나 하고 싶었던 말이였다. 실제로 게임 개발 업계에 있으면서 정말 많은 사람들로부터 우리팀은 애자일한다라고 이야기를 들었다. 아침에 스탠드업하고, 스프린트로 개발 하는데 그게 애자일 아니냐고 말이다. 확실한건 그건 애자일이 아니다.

그렇다고 해서 진짜 애자일을 하면 프로젝트가 무조건 성공한다고 생각하진 않는다. 오히려 책에서 이야기하는 2가지의 불편한 진실이 정말 중요하다고 생각한다. 이 진실을 마주하고, 개발 할 수 있다면 방법론은 상관이 없다.

첫 번째 진실은, 당신의 아이디어 중 최소 절반 이상은 유효하지 않을 것이라는 사실이다.

인스파이어드, P20

즉, 게임을 만들건 프로덕트를 만들건 우리가 만드려는 아이디어에 대해 그 누구도 관심을 가지지 않을 수 있다는 것이다. 이 아이디어가 정말 프로덕트로 이어질 수 있게 우린 수없이 많은 프로토타이핑을 해야하고, 노력해야한다.

두 번째 진실은, 아이디어가 충분히 잠재적인 가치가 있는 것으로 파악되었더라도 필요한 비지니스 가치를 만들어 내는 수준에 도달하려면 최소 몇 번의 이터레이션을 반복해야 한다는 것이다. 우리는 이것을 돈을 버는데 필요한 시간(Time to money)이라고 한다.

인스파이어드, P20

간혹 우리는 이런 이야기를 하곤 한다. 아, 그거 내가 생각했던 아이디어였는데, 아, 그거 내가 먼저 만들었었는데하며 기회에 대해 아쉬워하곤 한다. 난 이에 대한 대답이라고 생각한다. 그 어떤 아이디어가 있었어도, 충분히 만들거나 이터레이션을 돌지 않았다면, 그건 그냥 아무것도 아니다.

중요한 건 팀이다.

출처 : Supercell 사이트

책에서 다양한 직군의 사람으로 구성된 팀을 꾸려야하고, 미션팀으로 프로덕트를 다 같이 만드는 팀으로 구성되어야 한다고 강조한다. 아래는 책에서 이야기하는 강한 팀의 원칙이다.

강한 제품팀의 원칙

  • 방법을 선택할 권한책임을 갖는다.
  • 적절한 팀 사이즈보다 고른 역량을 갖는 것이 중요하다.
  • 팀 내부는 수평적인 구조를 가지며 보고는 각자 직무 관리자에게 한다.
  • 함께 의논하고, 솔루션을 만드는 협업 관계를 갖는다.
  • 최대한 가까이 앉아서 같이 일한다.
  • 한 팀(미션팀)은 최대한 오래 지속되어야 전문성을 가질 수 있다.
  • 제품 팀에는 높은 수준의 자율성이 필요하다.

인스파이어드에 나오는 인력 구성과 프로덕트의 발견 방식을 보면서 슈퍼셀(Supercell)이 많이 떠올랐다. 물론 직접 경험한 적은 없지만, 들은바로는 팀을 중시하며, 셀이라 불리는 팀의 가치를 우선하고 어떤 프로세스건 모두가 참여해서 성공적인 게임을 만드는 곳이다. 슈퍼셀이 GDC나 NDC등에서 발표한 내용을 보면 비전(Vision)으로부터 시작하고 항상 권한을 가진 소규모의 팀(Small Team)을 이야기한다. 동시에 어떤 프로덕트건 모든걸 팀안에서 결정한다. 브롤스타즈 케이스를 보면 프로젝트의 취소 조차도 팀이 결정할 수 있다고 한다.

슈퍼셀에 대한 자세한 내용은 아래 링크를 확인하면 좋을 것 같다.

하지만, 현실세계에 많은 게임 개발사들이 팀을 중시하지 않는다. 프로젝트가 접히면 팀은 자연스럽게 해산되고 다른 프로젝트에 편입되거나 이직을 한다. 그러면 접힌 프로젝트의 노하우나 히스토리는 사라진다. 즉, 아무것도 쌓이지 않는다. 성공적인 게임을 보면, 항상 팀이 있다. 그리고 그 팀은 또 다른 성공적인 게임을 만든다.

최고의 팀은 최고의 게임을 만든다.

The Best Teams make The Best Games

Supercell HOMEPAGE

이 외에도 언급할게 정말 무궁무진한 책이다. 프로덕트 개발에 방법론과 프로토타이핑 기법등이 다수 있고, 이를 테스팅하는 방법까지 나와있으니 프로덕트의 개발 과정에 관심이 있고, 내가 지금 참여하고 있는 프로덕트에 좋은 영향을 주고 싶다면 꼭 한번 읽어보길 바란다.

2021년 배우면 좋은 프로그래밍 언어

🧡 이 글은 게임 개발자 관점에서 작성된 글입니다.

어떤 언어를 배우는게 좋을까?

2021년을 시작하면서 새로운 언어를 배우려고 조사하는 김에 작성하기 시작했다. 아마도, 게임 프로그래머라면 주로 다루던 언어는 C++/C# 등과 같은 C계열의 언어였을텐데, 조금 새로운 바람이 필요한 분들에게 도움이 되길 기대한다.

Python

TIOBE Index For Python

대부분의 프로그래밍 언어 랭킹 사이트에서 파이썬은 압도적으로 높은 순위를 자랑한다. 2021년 1월 현재 PYPL 1위, TOIBE 3위로 랭크되어 있으며, 이제 프로그래머라면 반드시 알아야하는 언어가 되었다. 파이썬은 매우 풍부한 라이브러리를 갖고 있을 뿐만 아니라, AI, ML등에서 적극적으로 사용한다. 또한 웹 서버 개발(Django, Flask)로도 많이 사용된다.

파이썬 하이라이트

  • 오픈소스, 객체지향 언어
  • 크로스플랫폼을 지원
  • 비동기 코딩이 가능하도록 디자인
  • 강력한 라이브러리가 존재
  • 잘 되어 있는 문서화

게임 쪽에서도 파이썬은 잘 활용되고 있다. 대표적인 아트 툴인 Maya/3Ds Max/Blender는 이미 플러그인 API 스크립트로 파이썬을 사용하고, 이펙트/절차적 생성으로 유명한 Houdini 또한 파이썬을 지원하고 있다. 언리얼 엔진은 4.20 버전부터 에디터 스크립팅으로 파이썬을 지원하는 실험 기능이 추가 되었다.

게임에서는 일부 프로젝트에서 파이썬을 적극적으로 사용하는 케이스도 있었다.

게임에서의 실전 사용 케이스

어떻게 시작할까?

  • 슬랙 API를 이용해 봇을 만들어보는 것도 괜찮다.
  • 비공식이지만, Notion API를 이용해 무언가 자동화해보는것도 괜찮다.
  • 괜찮다면 DCC 생산성을 돕는 툴을 만들어 보는것도 좋을 것 같다.

Rust

TIOBE Index for Rust

두번째는 Rust다. 러스트는 현재 많이 사용되고 있지 않지만 꾸준히 사랑받고 있는 언어다. 실제로 스택오버플로우에서 2020년에 제일 사랑받는 언어 1위로 채택되기도 했다. 러스트는 효율성안정성을 중시하는 언어로 시스템 프로그래밍과 관련된 프로젝트들 여러개가 러스트를 기반으로 만들어지고 있다.

러스트 하이라이트

  • 급성장 하는 언어
  • 쉽고 빠른 개발 환경 구축
  • 안전한 문법 제공

러스트는 특히 C++의 대체제로 많이 대두되었는데 이에 대해선 다양한 의견들이 있으나 아마도 가장 크게 이슈가 되었던건 이 기사였을 것이다.

이에 대해서 반박하는 글도 있긴하다. 이 때문인지 Rust를 찾다보면 C++/C에 대한 이야기가 많이 나온다. 안전하고 효율적인 프로그래밍을 배워보고 싶다면 러스트를 배워보는 것이 매력적인 제안이 되지 않을까 싶다.

러스트에서 매우 흥미로운 것이 있는데 바로, Are we xxx Yet? 밈이다. 이는 러스트 프로젝트들을 모은 awesome list라고 생각하면 되는데, 재미있으니 한번 찾아보자. 또한 게임쪽에서 Rust하면 스웨덴에 게임회사 엠바크 스튜디오를 빼놓을 수 없다. AAA급 게임 스튜디오인 엠바크 스튜디오는 EA DICE 출신 게임 개발자들이 창업한 곳이다. 얼마전 넥슨에서 인수했는데 이 곳의 행보는 독특하다. 바로 개발의 메인 언어(Primary Language)로 Rust를 사용한다는 것. 즉, 거의 개발의 대부분을 Rust를 쓴다는 것이다. 이 스튜디오의 게임이 어떻게 출시되느냐의 따라 게임 개발 쪽에서 러스트의 입지나 윤곽이 드러나지 않을까 예상해본다.

게임 개발자를 위한 러스트 유용한 링크

어떻게 시작할까?


Kotlin

TIOBE Index for Kotlin

세번째는 코틀린이다. 앞에 Rust가 C++을 대체하는 후보라면, Kotlin은 Java를 계승한다. 코틀린도 위의 Rust와 같이 모던하면서 간결하고 안전한 프로그래밍을 지향한다. 자바의 JVM을 공유하기 때문에 자바 개발자분들이 특히 환영하는 언어라고 한다. 근데 왠 게임 개발자에게 자바? 라고 생각이 들 수 있는데, 사실 게임 개발자의 대부분이 C++/C#을 다루다보니 자바와 같은 언어와는 대척점에 있고 완전히 다른 세계라고 생각하고 기피하곤 한다. 허나 코틀린은 다르다. C#과 유사한 문법을 가질 뿐만 아니라, 다양한 언어에서 본 문법들을 공유한다. 즉, C++/C#과 Java의 간극을 좁혀주는 중간 다리 역할을 할수도 있다는 것이다.

코틀린 하이라이트

  • 표현력이 높고, 간결
  • Java와 100% 호환
  • 코루틴이 가능
  • 안전한 문법 제공

코틀린의 인기는 이제 급상승 하기 시작했는데, 가장 큰 이유는 역시 안드로이드 진형 때문이다. 구글 안드로이드에서 2017년 공식으로 Java외의 언어로 지원하기 시작했다.

그리고, 2019년 구글 I/O에서 Kotlin이, 모든 안드로이드 API에 First 언어가 될 것이라고 선언했다.

이로 인해, 코틀린은 날개를 달았고, 안드로이드 앱개발자들은 반드시 알아야하는 언어가 되었다. 나는 처음에 코틀린이 뭔가 코볼 같은 느낌이 나서 엄청 오래된 언어인줄 알았다. 허나 안드로이드 앱을 하나 만들어보고, 내 생각이 완전히 달랐음을 느꼈다. 이건 마치 C#과 비슷하며, 동시에 모던하다.

어떻게 시작할까?


왜 새로운 언어를 배워야 할까?

어쩌면, 내가 제시한 3가지 언어는 너무 뻔한 내용이라고 생각할 수 있다. 어쩌면, 아, 이거 다들 배우라는 언어인데 손이 안가 라고 생각 할 수도 있다. 나도 그렇다. 지금도 새로운 언어를 배우라고 하면, 실컷 찾아보고 결국 C#, C++ 을 다시 한다. 허나 여기서 하고 싶은 이야기는 새로운 시각에 대한 것이였다.

새로운 시각

위의 자료들을 조사하고, 직접 배워보면서 얻은 인사이트를 몇가지 공유하고자 한다.

  1. 프로그래밍 언어에 대한 습득 방식의 변화
    처음에 내가 개발언어를 배울때만 해도, 책 or 문서뿐이였다. 하지만 지금은 아니다. 유튜브, 인터렉티브한 문서, 인터렉티브 앱 완성 강의등이 차고 넘친다. 실제로 코틀린으로 간단한 앱 하나를 배우면서 만드는데 3시간이 안걸렸다.
  2. 패러다임의 변화
    언어의 패러다임이 계속 변화한다. 아마도 C++17/20도 이런 패러다임을 따라가기 위한 장치로 보이고, C#의 버전업도 비슷하다. 최근 언어들의 핵심 키워드는 안전성, 동시성, 간결성이다. 안전성은 NullPointerException을 제거하는 것을 의미하고, 동시성은 여러가지 태스크가 동시에 처리 될 수 있는 것, 간결성은 읽기 좋으면서도 짧은 코드화를 의미한다. (이에 대한 자세한 내용은 추후에 다뤄보겠다.)
  3. 생각의 확장
    안드로이드 스튜디오의 앱 개발 방식에서 게임 UI에 대한 영감이 떠오를수도 있고, 풀리지 않았던 문제를 다른 프로그래밍 언어에선 너무나 쉽게 푸는 경우가 있다. 몇년전 Unity에 갑자기 등장했던 UniRx도 Rx 패러다임에서 온 것인데, 이걸 이용하면 게임 개발에서 정말 많은 문제들이 쉽게 풀린다. 예를들면, 콤보 누적할때, 액션이 히트되면 누적되고 n초간 아무도 히트 되지 않으면 초기화 와 같은 문제는 Rx에서 한줄로 해결된다.

그렇다. 패러다임은 더욱 빠르게 변화하고, 배우는 방법은 엄청나게 방대해졌다. 이제 남은건 실행뿐이다. 2021년 1월 각오가 되었을 때 한번 시작해보자.

《빌 캠벨, 실리콘밸리의 위대한 코치》를 읽고,

출처 : yes24

실리콘 밸리 전설의 멘토

팀 캠벨은 실리콘 밸리에서 애플, 구글, 페이스북, 트위터, 이베이등의 숨겨진 스승이였다. 그는 독재자형 리더를 인간적인 리더로 바꾸었으며, 개성이 강한 직원들을 헌신적인 팀플레이어로 만들었다. 경쟁이 아닌 협력으로, 명령이 아닌 신뢰로 가장 혁신적이고 협력적인 조직을 만들게 해준 최고의 코치, 그가 빌 캠벨이다.

이 책은 지금은 고인이 된 빌 캠벨의 코칭에 대한 기억을 하나씩 더듬어가는 책이다. 이 책의 저자이자 전 구글 CEO인 에릭 슈미트는 ‘코치’의 가르침을 미래 세대에 전수하기 위한 목적으로 이 책을 썼다고 한다. 이 책을 읽으면서 정말 많은 내용들이 주옥같았을 뿐만 아니라 경험에서 오는 리더쉽에 대한 인사이트도 많았다. 아래에 내용들은 이 책을 읽으면서 제일 인상깊었던 내용 몇개만 추려서 써내려가려고 한다.

구글이 놓친 한 가지

책의 저자이자 전 구글 CEO인 에릭 슈미트는 《구글은 어떻게 일하는가》에서 전문성과 창의력을 겸비한 새로운 유형의 직원들이 속도전으로 혁신을 달성하는 핵심이라고 주장었다. 실제로 이런 사람들이 있으면 팀의 성과는 올라가고, 혁신이 일어날 수 있고, 구글은 이를 증명한 듯 했다. 하지만 여기에서 크게 놓친 중요한 요소가 있는데 그것은 공동체, 즉 이다.

특히 공동체로서의 팀, 즉 팀원들의 관심사를 한데 묶고 차이점을 제쳐두는 팀, 혹은 개인적으로나 집단적으로나 회사의 이익에 몰입할 수 있는 팀이다.

성과가 높은 팀에서 일한 경험이 있는 사람이라면 모두 알듯이, 직장에서의 팀은 항상 이런식으로 움직이지 않는다. 그런 팀은 똑똑하고 공격적이면서, 동시에 야심만만하고 의지가 강하며 자기 주장이 뚜렷한 사람들로 채워져 있다. ..중략… 이런 환경에서 이기적인 직원들은 이타적인 직원들보다 더 인정받을 수 있다.

빌 캠벨, 실리콘밸리의 위대한 코치, P42-43

허나 공동체로서의 팀은 충분히 이상주의적일 수 있다. 책에서도 이야기했듯이, 회사에서 공동체적인 팀을 구축하기란 매우매우 어렵다. 오히려 이를 악용해서 가족같은 회사가 될 수도 있다. 이를 위해서 책은 중요한 설계 원칙으로 의사결정과 분쟁을 해결하는 강력한 메커니즘을 개발하는 것이라고 이야기한다. 나는 이 말에 매우 동의한다. 즉 공동체로서의 팀이 되기 위한 사전 조건과 같다고도 할 수 있다.

‘이런 라이벌로 구성된 팀’을 하나의 공동체로 묶어 공동의 목표를 주고 함께 일할 수 있도록 재정비하는 것이다. 2013년에 나온 한 논문에서 이를 위한 설계 원리(design priciples)를 제시했다. 이중 하나는 의사결정을 내리고 분쟁을 해결하는 강력한 메커니즘을 개발하는 것이다.

빌 캠벨, 실리콘밸리의 위대한 코치, P42-43

개인적인 경험에 의하면, 의사결정과 분쟁을 해결하는 메커니즘이 없는 곳이 꽤 많다. 오히려 이를 회피하고 서로 탓을 돌리거나, 다른 사람 작업이 우선되야 내 작업을 할 수 있다며 떠넘기기도 한다.

리더는 필요하다.

초기에 구글에서는 관리자 없이 모든 엔지니어가 최고 임원에게 직접 보고하는 디스오그 실험(disorg)이 실행된적이 있다. 중간 관리자를 없애는 이와 비슷한 실험들은 간혹 큰 조직에서 자주 일어나곤 하는데, 구글의 실험도 이와 같은 일환이였고, 임원진들이 모두 동의한 아이디어였다. 이에 대해 빌은 관리자를 두는 것이 좋겠다고 이야기하며, 지나가는 엔지니어에게 바로 물어보는 장면이 나온다.

빌은 그들에게 관리자가 필요하냐고 물었다.

“네 필요합니다.”
“왜?”
“보고 배울 수 있는 사람이나 어색한 사이를 좁혀줄 수 있는 사람이 필요해요.”

빌 캠벨, 실리콘밸리의 위대한 코치, P55

이 일을 계기로 했는지 구글의 디스오그 실험은 2002년 말에 종료되었다고 한다. 관리자는 꼭 필요할까? 실제로 중간관리자의 존재에 대한 논문은 꽤 다양하게 주장이 이어지고 있는데, 1991년에 발표된 논문에 의하면 혁신 기업의 경우, 자원을 조정하고 갈등을 해결할 관리자들이 필요하다고 주장했고, 2012년에 한 연구에 따르면, 비디오게임 산업에서 강력한 중간관리는 전체 매출 변동폭의 22퍼센트를 차지했다고 이야기했다. 조금은 다르지만, 창의성을 위해서라면 관리자가 없어야 한다는 논문도 있었다. 2005년에 출간된 논문에 의하면 창의성은 위계적인 조직보다는 수평적인 환경에서 꽃을 피운다고 이야기했다. 빌은 관리자가 꼭 필요하다고 생각하는 코치였다.

그렇다면 관리자 중에서도 뛰어난 리더는 어떤 사람일까? 책에서 가장 와닿았던 말은 잘못된 의사소통으로 생기는 사람들 사이의 틈을 메우는 일이였다. 리더에겐 다양한 능력이 요구되지만 그 중에서도 일이 돌아가게 하는 능력, 즉 의사소통에 중요한 역할을 한다는 걸 명심해야 한다.

실제로 업계에 있으면서 중간관리가 있는 곳도 있어봤고, 없는 곳도 있어 본 바로는 국내에선 중간 관리의 역할이 매우 중요하나 과소평가 되는 경향이 있다. 예를 들면, 10년차 이상의 프로그래머를 생각해보자. 대부분의 프로그래머가 관리자로 갈거냐, 전문가로 갈거냐를 고민한다. 특히 관리자보단, 전문가에 가고 싶어한다. 왜일까?, 조금은 다른 이야기이지만 국내에는 아직 중간 관리자가 업무적인 역량에 의한 존재가 아닌 정치적인 존재로 많이 읽혀진다. 개인적인 역량의 발전은 없고 회사를 위해 헌신하기만 하는 그런 존재말이다. 허나 내 생각은 조금 다르다. 관리자에도 비전이 있다. 뛰어난 전문가 10명보다, 뛰어난 중간관리자 1명이 프로덕트를 성공으로 이끈다.

팀이 우선이다.

빌은 지독한 팀 퍼스트 주의자였다. 언제나 팀을 구성하려고 했다. 팀원들도 팀으로 헌신하길 바랬다고 한다. 어떤 어려운 문제가 닥쳐도 그는 팀을 만드려고 했다. 그의 첫번째 원칙은 문제를 해결하기 전에 팀을 만드는 것이었다. 이는 팀이 직면한 특정한 문제를 해결하는 것에 도움을 주는 것이 아니라 팀 자체에 집중했으며, 이로 인해 실제로 일을 수행할 능력이 있는 사람들이 일을 할 수 있게 한다는 뜻이 담겨있었다.

셰릴 샌드버그는 이렇게 말했다. “그는 언제나 팀을 만들고 있다는 인상을 줬어요. 빌의 코칭은 경영진 코칭도 아니였고 커리어 코칭도 아니었어요. 나만을 위한 코칭도 아니었죠. 언제나 팀을 위한 코칭이었어요.”

빌 캠벨, 실리콘밸리의 위대한 코치, P152

IT뿐만아니라 게임개발에서도 팀은 매우 중요하다. 개인적으로 제일 좋아하는 말 중에 최고의 팀이 최고의 게임을 만든다라는 말이 있다. 슈퍼셀에 신념으로 나오는 말인데, 나도 이에 매우 매우 동의한다. 개인이 모든걸 하기엔 게임의 파이가 너무 커졌을 뿐더러, 경쟁은 치열해지고 있다. 혼자만의 능력으로 이 거대한 시장에 진입하긴 매우 어려우며, 잘 할 능력이 있는 사람이 잘 할 수 있도록 팀을 꾸리고 운영하는 게 더 좋은 게임을 만들 수 있다.

마무리 하며

이 책은 내가 마음속에 품고 있던 가치관의 깊이를 메워주는 책이였다. 책을 읽는 것만으로 코칭을 받은 느낌이였고, 좋은 리더가 될 수 있을 것 같은 생각도 많이 들었다. 위에 언급한 내용외에도 리더 혹은 관리자로써 코칭이 될만한 많은 문구들이 있다. 초보 관리자나 리더인 경우 꼭 한번 읽어보길 권장한다.

《생각이 돈이 되는 순간》를 읽고,

출처:yes24

천재적인 아이디어의 진실

천재적인 아이디어는 어디서 나오는 걸까?,
아이폰 같은 프로덕트에 대한 생각은 선택받은 자에게만 허용 되는걸까?
순간적인 신내림 같은 영감이 나에게도 올까?

누구든지 이런 고민을 해본적 있을 거다. 연구원이라면, 새로운 논문이나 연구 주제에 대한 아이디어가 하늘에서 떨어졌으면 좋겠다라는 생각, 게임 개발자라면 세상에 없는 재밌는 게임에 대한 아이디어가 뚝 떨어졌으면 좋겠다라는 생각을 한번쯤은 해보지 않았을까 싶다.

생각이 돈이 되는 순간(원제 : The Creative Curve)은 영감과 창의력이라고 부르는 것들에 대해 그 뒤에 숨어있는 진짜 노력을 이야기해주는 책이다.

책은 시작부터, 비틀즈의 예스터데이가 첫 영감부터 술술 쓰이던 곡이 아닌, 첫 아이디어부터 완성까지 20개월이 걸린 엄청난 노력이 들어간 곡이였고, 우리가 아는 모차르트는 한번의 수정 없이 곡을 술술쓰는 천재 작곡가가 아닌, 수많은 악보 수정을 하는 진정한 노력파였다라고 말한다.

천재는 만들어진다.

생각이 돈이 되는 순간에선 창의성과 천재는 ‘사회적 현상’으로 만들어지는 것이라고 칙센트미하이의 창의성에 대한 주장을 설명한다. 사회적으로 표준화되거나 규범화된 기술적 범위내에 있는 소재를 사용해야하며, 창의적이고 가치있는 것과 그렇지 않은 것을 판단하는 문지기의 관심을 끌어야하고, 사회적 체제안에서 인정받은 개인이 되어야한다는 것이다.

예술가는 대중의 인정을 받아야한다. 그래서 ‘타이밍’이 중요하다. 자원이 있고 문지기가 관심을 가질 때 작품을 생산하고 창작해야 하는 것이다.

생각이 돈이 되는 순간, P112

결국 끊임없이 변화하는 대중이 천재를 결정하는 것이지, 타고난 재능만으로 되진 않는다는 것을 이야기한다. 아무리 멋진 서비스를 제작한다고 해도 유저가 없으면 아무것도 아니다. 아무리 멋진 소설을 써도 독자가 없다면 아무것도 아니고, 아무리 천재적인 프로그래밍을 한다고해도 프로덕트가 런칭하지 못한다면 아무런 소용이 없다는 뜻이다.

크리에이티브 커브

우리는 간혹, 너무 앞선 서비스나 시대를 앞선 이야기 등을 회상하곤 한다. 페이스북 이전의 싸이월드가 그랬다. 그리고 간혹 대세감이라고 부르는 순간적으로 스위트 스폿을 넘어버리는 현상을 보곤한다. 아마도, 2020년에 가수 비의 ‘깡’이 그랬을 거다.

‘너무’ 색다른 것들은 사람들이 다가오지 못하게 만드는 게 문제이지만, ‘너무’ 친숙한 것들은 애초에 아무런 흥미도 자아내지 못한다.

생각이 돈이 되는 순간, P139

책에서 이야기하는 크리에이티브 커브는 쉽게 말하면, 천재적인 아이디어가 우리 모두에게 보급되기까지의 과정을 다룬다. 모든 성공한 아이디어들이 이 과정을 거치고 있으며, 이 곡선을 피하는 유일한 방법은 중독자로 만드는 것 뿐이다. ex) 커피, 비디오 게임, 애플빠, 삼성빠

크리에이티브 커브의 법칙

그렇다면, 나도 크리에이티브 법칙을 적용할 수 있지 않을까?

책에선, 이 부분을 크리에이티브 커브의 네가지 법칙으로 소개한다.

  1. 소비
  2. 모방
  3. 공동체
  4. 반복

소비는 경험 축적시켜 내 지식과 결합되어 순간적으로 새로운 아이디어를 ‘저절로’ 떠오르게 한다. 때문에 20% 법칙을 통해 소비에 대한 경험을 축적하고, 번쩍하는 순간을 만드는 최초의 불꽃을 제공하라고 이야기한다.

모방은 각 분야의 성공 공식을 체득하는 방식이 비범한 작품으로 이어진다는 이야기를 한다. 즉, 모방은 친숙함을 자신의 색다름과 결합하기 위한 필수 요소로, 색다름도 중요하지만 이미 그 분야에서 따르고 있는 패턴도 중요하다고 이야기한다.

공동체는 ‘천재 크리에이터’하면 떠오르는 초인적인 한 사람의 이미지를 완전히 부순다. 유명한 스트리머에게도, 자신의 크루가 있고 창의성으로 유명한 스티브 잡스마저도 팀을 이뤄 프로젝트를 진행했다. 즉, 창의적인 사람들에게는 강력한 에너지를 주는 사람들(동료)이 존재한다는 이야기다.

반복은 크리에이티브함을 만들기 위한 배합과정을 의미한다. 개념화를 통해 많은 아이디어를 내고, 압축을 통해 양질의 아이디어만 솎아내고, 최상의 아이디어를 큐레이팅한다. 그리고 피드백을 받고, 이를 반복하는 과정. 즉, 친숙성과 색다름의 이상적인 배율을 위해 끊임없이 반복해서 만들고, 피드백을 받아야한다는 이야기다.

마무리하며,

나는 이 책을 통해, 기존에 갖고 있던 많은 고정 관념과 더불어 팀에서도 실험을 해보고 싶어졌다. 그리고 이전에 들었던 두가지 세션이 떠올랐는데, 하나는 Mobile Game Development in Supercell (Hay Day)이고, 하나는 〈어쌔신 크리드〉에서 〈심시티 빌드잇〉까지 였다. 이게 무슨 뚱딴지 같은 소리라고 생각할수도 있을 것 같은데, 사실 기존의 게임 프로덕션은 고착화 된 워터폴 방식과 비슷한 형태로 진행이 된다. 즉, 태초의 아이디어가 있고, 그 아이디어에 따라 개발한다.

<어쌔신 크리드>에서 <심시티 빌드잇>까지
Mobile Game Development in Supercell (Hay Day)

허나, 이들은 그렇지 않았다. 두 세션 모두 특징이 크리에이티브 커브에서 이야기한 것들을 너무나 자연스럽게 따르고 있었다. 친숙함과, 색다름을 적당히 조합하면서 팀(공동체)을 중시한다. 하나의 영감이 만능이 아니라, 누구든 아이디어를 낼 수 있고 이를 정제하고 가공하는 과정을 중시한다. 즉, 프로덕션부터 지독하게 창의성을 위한 노력을 한다. 아마도, 앞으로의 게임 업계도 이런식으로 변화해야하지 않을까라는 생각이 든다.

《나는 아마존에서 미래를 다녔다》를 읽고,

출처 : yes24

세계에서 제일 혁신적인 기업

세계에서 가장 혁신적인 회사라고 하면 떠오르는 기업에 아마존이 있다. 세상에서 가장 고객 중심적인 회사라는 미션 스테이트먼트를 가진 아마존에 대한 나의 첫기억은 인터넷으로 전공책을 사던 서점이였다. 그리고선 꽤 오랜시간이 흘렀고, 아마존은 어느샌가 모든것을 파고, 어디로든(그게, 미국 -> 한국이던) 배달해주는 온라인 마켓이 되어 있었다. 또한, AWS(Amazon Web Service)라는 IT인이라면 반드시 알아야 하는 세계적인 클라우드 플랫폼 회사가 되어 있었다.

to be Earth’s most customer centric company.

Amazon UK : Our Mission (아마존 미션 스테이트먼트)

이 책은 아마존의 거의 모든 성장을 직접 보고 배운 한국인 아마조니언(아마존 직원)의 기록이다. 저자는 이 책에서 아마존(회사)을 다니면서 보고, 듣고, 직접 일했던 경험을 이야기 해준다. 책에서 저자는 꽤나 날 것(raw)의 이야기를 많이 해주는 데 이전 글인 《이기적인 직원들이 만드는 최고의 회사》를 읽고, 와 달리 같은 IT인으로써 많은 부분 공감이 되었다.

그중 몇가지만 고르자면, 아마존이 소프트웨어 회사라는 이야기를 하면서 이에 대해서 월마트와 비교하는 부분이였다.

당시 월마트에 비하면 구멍가게 수준인 아마존이 왜 앞으로 월마트를 앞지를 수밖에 없는지를 명쾌하게 한마디로 농증한 것인데, 이유인즉 땅값은 시간이 지나면 오르는데 컴퓨터는 갈 수록 싸지기 때문이라는 것이다.

나는 아마존에서 미래를 다녔다, P26

이 부분은 저자도 처음 입사때 들은 이야기지만 아직까지 기억에 남을 정도로 강렬한 이야기였다고 한다. 나 또한 공학인으로써 내용을 곱씹어보게 되는 부분이였다. 역설적이게도, 책을 더 읽다보면, 아마존은 새로운 사옥을 지을 때 땅값이 매우 비싼곳에 짓는다.(p46. 아마존이 비싼 도심으로 간 이유)

개밥먹기(Dogfooding)

개밥먹기(Dogfooding), 소프트웨어 개발에서 자사에서 만든 서비스를 직접 사용해보는 것을 말한다.

또한 인상깊었던 곳은 개밥먹기였다. 개밥 먹기는 자사의 제품이나 서비스를 실제로 직접 사용하는 것을 의미하는데, 게임 업계에서도 자기가 개발한 게임을 직접 플레이하는 걸 개밥먹기라고 부르곤 했는데 아마도 여기서 유래된 것 같다.

‘네가 만든 개밥을 먹어봐(Eat your own dog food)’ 또는 도그 푸딩(dogfooding)이라고도 부르는 재미있는 미국 숙어는 (…중략…), 주로 기업들이 자사의 제품이나 서비스를 회사 내에서 사용하거나 사용하지 않는 경우를 빗대어 쓰는 말이다.

나는 아마존에서 미래를 다녔다, p204

아마존에서 예를 든 개밥 먹기는 AWS에 대한 부분이였다. AWS서버가 다운되도 아마존 사이트가 다운되지 않아, 사람들이 항의를 하자 피하지않고, 아마존 사이트를 마이크로서비스 아키텍쳐로 변화시켰고 완전히 AWS 서비스로 이주하게 되었다는 이야기가 있었다.

개밥먹기에 대한 개인적인 일화를 소개하면, 게임에선 직접 개발하는 게임의 기능이나 전체 플레이해보는 걸 의미하게 되는데, 생각보다 많은 게임 회사에서 개밥 먹기를 하지 않는다. (충격적일 수 있지만 실화다)

내가 이전 회사에 있을 때, 대규모 패치를 앞두고 있었던 적이 있다. 이 회사에선 충격적이게도 아무도 테스트를 하지 않고 개발한 내용을 일단 올리고, QA에서만 개밥먹기를 하는 완전한 분업화(?)를 이뤘었다. 그래서 내부적으로도 직군팀끼리 기획은 요청한 기능 테스트도 안해 라던가, 엔지니어팀은 만든 기능 테스트 한번 안해보나? 라는 식으로 헐뜯기 시작했고, 두 팀간의 거리는 점점 더 멀어졌던 기억이 있다. 즉 팀 간의 의사소통이 점점 더 경직되는 경험을 했었다.

추후에 퇴사 후 개인적으로 서로 친해지면서 알게된 충격적인 사실은 실제로 기획팀과 클라팀에선 개밥먹기를 했었다는 것이고, 이게 서로의 관점에서 이뤄진 개밥먹기여서 다른팀 관점에서 보기엔 전혀 테스트를 안하는 것처럼 보였다는 것이다. 예를 들면, 기획팀은 퀘스트 진행 경로라던가, 밸런스에 집중을 했다면, 엔지니어팀은 기능적으로 발생하는 버그나 문제점에 집중을 했었다. 지금 생각해보면 내 작업에만 관심을 가졌던 게 문제 였던 것 같기도 하고, 해당 기능에 대한 설명이나 바라보는 관점이 다른데서 나온 문제가 아니였나 싶다. 뭐, 결국엔 의사소통의 문제였던 것 같다.

이 책을 마무리하면서 든 여러가지 생각중 하나는 비전(Vision)이라는 신념이 어떤 일을 하건, 많은 영향을 줄 수 있다는 점이였다. 물론, 비전 없는 회사는 없다곤 하지만 지킬 수 있는 비전이나, 꿈꿀수 있는 비전을 가진 회사가 과연 얼마나 될지 다시 한번 고민하게 되는 책이였다.

《이기적 직원들이 만드는 최고의 회사》를 읽고,

이기적 직원들이 만드는 최고의 회사
출처 : yes24

실리콘 밸리는 어떻게 혁신을 이루는가?

실리콘 밸리의 혁신은 어디서 오는가?

엔지니어라면 누구나 실리콘밸리를 꿈꾼다. 실리콘밸리에서 일하는 삶은 어떤 삶일까?

얼마 전에 읽었던 “이기적 직원들이 만드는 최고의 회사“에서 이에 대한 해답을 얻을 수 있었다. 이 책에선 막연히 알고 있던 실리콘밸리에서의 삶이나, 기존에 알던 실리콘밸리에 대한 선입견을 완전히 부수고, 새로운 관점에서 역할 조직혁신에 대한 저자의 경험을 그대로 전달해준다.

먼저, 실리콘밸리를 하면 누구든지 먼저 떠올리는게 수평적 조직 구조애자일 방법론 일 것이다. 정말 운이 좋게도(?) 나는 최근 5년간 일하면서 진짜 수평적 조직 구조와 진짜 애자일 방법론을 게임 개발에서 경험한 적이 있다(진짜다. 이에 대해선 언제 한번 포스팅을 해볼 예정이다). 그 때의 경험으로는 실리콘밸리의 혁신은 이 두개(수평적 조직구조와 애자일)에서 오는게 절대 아니라는 것을 마음속에 품고 있었는데, 이 책을 통해 확실하게 깨닫게 되었다.

역할 조직은 수평적 조직구조의 마스터 피스

이 책에서 이야기하는 “역할 조직”은 내가 겪었던 수평적 조직 구조가 놓친 마스터피스를 채워주는 느낌이였다.

구글, 페이스북, 트위터, 에어비앤비등 최근에 생긴 실리콘밸리 기업들이 선택한 방법은 ‘역할 조직(role-driven organization)’이라고 할 수 있다. 위 아래가 아닌 각자의 역할에 따라 책임을 지고 의사결정을 하며 업무를 수행하는 것이다.

이기적 직원들이 만드는 최고의 회사, p31

이 부분만 보면, ‘결국 수평적 조직 구조를 이야기하는 것 아닌가?‘ 라는 생각이 들 수 있는데 내 사견으로는 역할책임이 바로 그 마스터피스다. 실제로 수평적 구조를 경험해보면, 역할과 책임은 결이 안맞는다. 오히려 위계조직에서 더 어울리는 말일 수 있다. 나에게 부여된 일에 대한 역할을 다하고, 나에게 부여된 일까지만 책임을 다하는 것. 이것이 지금까지 우리가 해온 역할과 책임에 가깝지 않은가?

수평적인 구조에서 역할과 책임을 다한다는 건 직접 경험해보면 정말 어려운 일이다. 수평적일수록 의사 결정에서 분쟁은 쉽게 발생하며, 정답이 없는 방향에 대해 결정을 내리고 책임을 져야하는 상황이 오기도 한다. 국내에서 이런 상황에서 사실 대책이 없다. 기업의 구조에 따라 다르긴 하겠지만, 내가 있던 기업에선 한계가 확실했다. 이 책에선 실리콘밸리는 이런 단점을 해결하기 위해서 기업의 미션뛰어난 인재라는 국내 기업에서 쉽게 가질 수 없는 특수한 실리콘밸리의 문화를 소개한다.

역할조직의 또 다른 단점은 직원 개개인에게 결정권이 주어지기 때문에 잘못된 결정을 내릴 경우에 회사가 쉽게 무너질 수도 있다는 것이다. 그래서 모든 구성원의 능력이 뛰어나야한다.

이기적 직원들이 만드는 최고의 회사, P33

사실 채용과 인재 관리 관점에서 실리콘밸리에 매우 특화되어있는 부분이긴하지만, 정말 많이 동의한 부분이다. 확실히 조직을 수평적으로 운영하려면 모든 조직원이 모든 관점에서 뛰어나야 한다.

혁신은 미션에서 부터 시작한다.

실리콘밸리 기업은 대중이 의식적/무의식적으로 가지고 있는 문제인식을 해결하기 위한 ‘미션mission’으로 부터 출발하며, 그 미션에 따라 혁신적인 제품을 만들어 대중에게 제공한다. 회사의 미션이 무엇인지를 명확하게 함으로써, 의사결정에 갈등이 생겼을 때 우리회사가 무엇을 하는 회사인지를 상기시킨다.

이기적 지원들이 만드는 최고의 회사, P74-75

또한 실리콘밸리하면, 빠질 수 없는게 애자일 개발 방법론이다. 애자일 방법론은 우리에게 실리콘밸리의 혁신 수단으로 알려져 있다. 그래서 최근 채용 공고를 보면 정말 쉽게 우린 애자일 방법론을 이용해 개발합니다 라는 문장을 볼 수 있다. 허나 애자일은 수단일 뿐이지 모든 혁신은 미션(Mission)에서부터 시작한다. 이 책은 이 부분을 정확히 찝어준 책이다.

구글 : 세상의 정보를 조작하여, 모든 사람이 접근 가능하고 활용할 수 있도록 하자.

페이스북: 세상을 더 가깝게 만들자.

에어비앤비 : 세계 어디를 가든 내 집처럼 느끼게 하자.

중략..

애자일 방식에서는 ‘자동차를 만들자’가 아니라 ‘인류의 이동을 편하게 하자’라는 미션을 걸고 프로젝트를 시작한다.

이기적 지원들이 만드는 최고의 회사, P158

미션은 사이먼 시넥의 골든서클과도 연결 되는 부분으로 혁신에서 정말 중요한 부분이다. 우리는 단순한 목적이 아닌 궁극적 미션이나 비전을 따라 혁신을 만든다. 즉, 어떤 일을 하는데 있어 “왜why” 이 일을 하는가를 묻는 것인데, 골든 서클에 대한 자세한 건 TED – 위대한 리더들이 행동을 이끌어 내는 법(사이먼 시넥)에서 찾아볼 수 있다.

조선위클리비즈(사이먼 사이넥,크르즈나릭)
사이먼 시넥, 골든서클

다시 돌아와서, 많은 직장인들이 금기어처럼 마음속으로 갖고 있는 질문있다. 너무나 간단하게는 돈 때문이지라고 생각하지만 좀 더 깊은 내면과 철학적으로 고민해 볼만한 질문이다.

나는 왜 이 프로젝트를 하지?

그리고 이 역질문 또한 꽤 가치가 있다고 생각한다.

당신이 다니는 회사에 미션(Mission)은 무엇인지 알고 있나요?

물론 회사에 미션이 실리콘밸리와 같은 혁신을 일으키는 미션과 거리가 멀 수도 있다. 허나, 내가 다니는 회사에 미션을 직접 찾아보고 알게 되는 건 꽤 가치가 있다. 나는 지금 판교에 N사에 다니는데 최근에 회사 소개를 보면서 꽤 놀랐다. 미션이라고 명시되어 있지는 않았지만, 회사 소개에 적혀 있는 이 슬로건은 현재 회사를 초기에 설립할 때 어떠한 비전을 갖고 설립했는지는 충분히 느낄 수 있었다.

게임을 사랑하는 사람들이 모여 즐겁게 게임을 만드는 곳, 이 곳에서 전세계 게이머들에게 최고의 재미와 경험을 선사하기 위한 도전은 계속됩니다.

이에 대해 더 깊은 이야기는 안하겠지만, 개인적으로는 회사가 진행하는 행사나 활동 그리고 구성원들이 한순간에 이해가 되는 순간이였다. (참고로 N사는 내가 경험한 그 어떤 게임 회사보다 구성원 모두가 게임을 사랑한다.)

역할 조직과 미션에 대한 이야기는 내가 언급한 내용 이외에도 모든 챕터를 읽어봄직하다. 구성원을 어떻게 뽑는지, 어떻게 평가하는지, 어떻게 떠나는지와 같은 혁신에 머물러간 사람들에 대한 이야기뿐만 아니라, 실리콘밸리에서 미션은 어떻게 만들어지고 있는지, 그 미션이 이뤄낸 혁신은 무엇인지에 대한 이야기도 함께 볼 수 있다.