NDC Replay

Software Development Manager
박종천
넥슨
한글과컴퓨터 개발팀장 6년 미국 보스턴의 다수 벤처에서 개발실장 (Technical Director) 5년 Blizzard 미국 얼바인 본사에서 수석개발자/개발팀장 (Lead Software Engineer) 11년 현재 넥슨 플랫폼본부 부본부장 (Vice President of Platform Technology) 총 개발경력 22년
게임 소프트웨어 개발자가 무엇인가 알아보고 게임 소프트웨어 개발자가 되기 위해서 준비해야 할 것들 살펴보기 세계의 미래는 소프트웨어 개발에 있습니다. 한국도 이 소프트웨어 개발을 정말 열심히 하고 있고, 엔터테인먼트의 강국답게 저희가 제일 잘하는 소프트웨어 분야는 게임입니다. 게임 개발의 여러 Art, Design, Engineering, Production 등 직군들을 살펴보고, 그중에서 소프트웨어 개발자를 Client, Server, Tools, Platform 등 파트별로 자세히 살펴봅니다. 그리고, 그런 소프트웨어 개발자가 되고 또 발전하기 위해서는 무엇을 준비하고 공부해야 하는지를 살펴봅니다. 게임 회사에 소프트웨어 개발자로 시작하고 싶거나 막 시작하신 분들을 위해서 좋은 정보가 될 것입니다.
[새 창에서 슬라이드 보기]
네 안녕하세요. 박종천입니다. 늦은 시간까지 이렇게 기다리셔서 좋은 세션 들어오신 거 축하드리고요. 좀 어렵고 재미없는 주제일 수도 있는데 한 번 이렇게 쭉 다뤄보시면은 좀 딱딱하고 힘든 내용이지만 여기 혹시 학생분들 계시면은 학생분들한테는 굉장히 좀 어려운 주제일 거예요. 왜냐하면 “개발자로써 어떻게 성장하느냐?”라는 세션을 가지고 작년에 NDC에서 했었는데 “개발자의 9가지 기술” 뭐 그런 걸로 했었고 이거는 거기에서 좀 더 심화된 학습 버전이거든요. 그래서 개발자를 한 10년 정도 했을 때 개발 팀장이 되려면 어떻게 해야 되느냐? 그런 내용이라서 조금 어려운 주젠데 와주신 여러분들께 감사드립니다.

잠깐 제 소개를 하면 저는 한글&컴퓨터에서 개발자 생활을 시작해가지고 미국에 건너가서 거기서 벤처기업 몇 개 하다가 Blizzard에 들어가서 11년 정도 일을 했었고요. 그리고 올해 1월에 넥슨으로 옮겼어요. 그래서 작년에는 Blizzard의 개발자로써 와가지고 NDC 강연을 했었고 올해는 넥슨의 직원으로써 강연을 하게 됐습니다. 어쨌든 오랜 기간 개발을 했었고요. 그래서 22년 동안 개발을 하고 아직도 안 잘리고 이렇게 회사 생활 잘 하고 있습니다. 여기 그래서 Engineer 분들 계시면 노력하시면 한 20년 넘게 일을 할 수 있습니다. 안 잘리고. 그래서 이렇게 개발자 생활 재밌게 하고 있고요. 지금은 넥슨에서 Global Platform, 그래서 넥슨의 게임 그리고 한국의 모든 게임들이 전 세계에 나갈 수 있는 그런 교두보를 만들어보자. 뭐 그런 꿈을 가지고 한국에 왔습니다. 제가 Blizzard에 있었을 때 마지막으로 했던 일은 Hearthstone 일이었는데 Hearthstone에 유니티하고 연결하고 그런저런 툴 Platform Contents Creation 툴 그런 일도 했었고요. 여러 가지 개발을 많이 했었어요. 지금 시간이 늦어서 제가 원래도 말을 빨리하는데 지금 조금 더 빨리할 것 같아요. 그래서 제가 너무 말을 빨리하니까 이렇게 들으시면서 너무 집중하시면 숨이 멎을지도 몰라요. 그러니까 중간중간 숨을 쉬어가면서 들어주시기 바랍니다.

그래서 팀장이다. 그러니까 Manager다. 그러면 보통 3개로 나눌 수 있는데요. 아니 그러니까 사람들 일하는 걸 세 개로 나눌 수 있는데 Top-level Manager 그러면은 보통 사장직이라고 볼 수 있겠죠? 사장님들이 일을 하는 스타일이 있고 Mid-level Manager 중간 관리자들. 일을 할 때 보면 저희가 대부분의 직원들은 중간 관리자하고 일을 해요. 그러니깐 팀장들하고. 사실 사장님하고 직접 일을 하거나 본부장님하고 직접 일을 하거나 그런 일은 없잖아요. 그만큼 이렇게 중간 관리자들이 중요한 일을 하기 때문에 이 중간 관리자들이 어떻게 하면 성장할 것인가? 그런 사람, 그런 거에 대한 이야기를 오늘 이 주제로 다루고자 합니다. 그리고 이제 마지막에 주로 일하는 사람들이죠. 그래서 이렇게 조직을 나눌 때 이거보다 더 복잡하게 나눌 수 있겠지만 크게 보면은 결국 이렇게 큰 Top-level Manager, 그다음 중간 Mid-level Manager, 그리고 마지막에 진짜 일하는 사람들 이렇게 3개로 나눠볼 수 있는 거죠.

그래서 Mid-level Manager들은 과연 어떤 일을 하느냐? 그래서 오늘 다룰 주제가 Mid-level Manager죠. 여기서 팀장이다 그러면 오늘 개발 팀장을 이야기하는 거거든요. 그러니까 개발 팀장은 실제로 개발도 하고 S/W Engineer로써 개발도 하고 팀도 다루는 그런 내용인데 Project Lead를 이렇게 관리하는 사람. 그래서 Project Lead 실제로 일을 진행하는 그 Project로서의 일도 하고 그러면서도 Technical Lead, 실제로 개발하고 있는 코딩이 잘 되고 있는지 이 기술이 좋은 기술인지 그런 것도 살펴보고 마지막으로 팀원들도 관리해야죠. 사람들도 관리해서 그 사람들이 행복하고 일을 잘 할 수 있도록 이 세 가지를 다 하는 사람들을 일반적으로 이제 Mid-level Manager라고 부르죠. 팀장. 그래서 팀장이라는 게 사실 그래서 어려운 거예요. 앞에 사장도 참 어려운 일이지만 팀장도 꽤 어려운 일이에요. 왜냐하면 이 세 가지가 다 다른 거거든요. Project를 진행하는 Skiil Set도 다르고 Technically 진행하는 Skiil Set도 다르고 마지막으로 사람들 이렇게 다루는 마음도 달라요. 어쨌든 한 사람이 현재 한국에 게임 업계나 IT 업계의 특성상 다 해야 되는 상황이라서 이 세 가지를 어떻게 하면 다 잘할 수 있을까? 그런 거를 고민해보겠습니다.

그래서 다시 말하지만 Team Lead는 Project Lead, Technical Lead, People Manager 이 세 가지가 다 섞여 있는 거고요. People Manager 할 때 제일 중요한 거는 사람들하고 1:1면담을 하면서 어떻게 진행할 것인가? 제가 Lead라는 말을 좋아해요. Manager란 말을 안 좋아하고 왜냐하면 이 페이스북에서 주워온 그림인데 유명한 거죠? Boss는 앞에서 가자!! 그러는 사람이고 Leader는 앞에서 끄는 사람이죠. 그래서 Manager라는 거는 왠지 성격상 좀 사람들을 뒤에서 이렇게 해라 해라 그러는 것 같고 Lead는 앞에서 끌고 가는 것 같은 그런 느낌이라 저는 개인적으로 Lead라는 말을 더 좋아하고요. 그리고 Project Lead, Technical Lead, People Manager 다 살펴보고 나서 Process, 이런 일을 하는 그 중간 과정 그 어떤 식으로 진행할 것인가? 그런 거를 다 Process라 볼 수 있는데 이 Process가 어떻게 될 것인가에 대해서 한 번 더 살펴보는 시간을 갖도록 하겠습니다.

그래서 Project Lead, Project Lead, Technical Lead, People Manager 세 가지 주제에 대해서 볼 건데요. Project Lead는 결국 일을 진행하는 Product와 Project 이 단어를 보통 구분하고 그래요. 가끔 사람들이. Product는 그 제품 자체를 말하는 거예요. 그러니까 예를 들면 김치볶음밥이 먹고 싶어. 김치볶음밥을 만들자. 그러면 그 김치볶음밥이라는 거 자체를 Product라고 볼 수 있고 Product Lead라는 거는 ‘그 김치볶음밥은 어떤 김치볶음밥이어야 된다’라는 거를 생각해내는 사람이죠. 조금 달라요. Project Lead는 김치볶음밥을 요리하는 과정을 고민하는 거예요. 쟁반을 뭐를 써야 되고 요리를 어디서 가져와야 되고 요리 시간은 며칠 걸리고 그걸 어떻게 내놔야 되고 그 일을 진행하는 과정 자체를 지켜보는 거죠. 그래서 제가 굉장히 좋아하고 추천하는 책 중에 하난데 Debugging The Development Process라고 한국에 번역돼 나와서 지금은 절판됐어요. 그런데 이거 아마 구해서 읽어보면 굉장히 도움 될 거예요. 그래서 개발하는 과정 자체를 디버깅하는 거예요. 저희가 흔히 S/W를 개발한다 그러면은 그냥 제품을 디버깅한다고 생각하잖아요. 그런데 사실 그 제품에 문제가 있어서 망하는 경우보다는 그 제품을 만드는 과정에 문제가 있어서 망하는 경우가 더 많아요. 그래서 그 개발 과정 자체를 디버깅해야 된다는 의미로써 이 책을 냈는데 굉장히 좋은 책이고 거기에 이런 Project 관리에 대한 개념들이 많이 나오죠. 그래서 Project Lead는 어쨌든 “What to do? 무엇을 할 것인가?”를 결정하고 거기에서 실제로 개발이 Direction은 어떻게 돼있고 Product Owner, 실제로 뭐를 먹고 싶다. 아까 음식 이야기했었죠? 뭐를 먹고 싶다고 말하는 사람, 그 일을 한 정의한 사람한테서 정보를 가져와서 어떤 식으로 개발해야 될 것인가? 그런 방향을 정해주는 거죠. 실제로 이 안에 들어가 보면은 스케줄은 어떻게 잡을 거고 개발 계획은 어떻게 되어 있고 그리고 실제로 우리가 시간을 얼마나 쓰고 있고 실제로 문제가 중간에 있고 또 생산성은 얼마나 되는지 여러 가지 고민을 많이 해야 되는데

결국은 그 안에 개발 계획이잖아요? 그래서 개발한다는 거 자체가 Development Cycle, 개발 Cycle에서 돌아가는데 첫 번째는 요구 사항을 받아오고 분석을 하고 그다음에 Design Modeling을 하고 구현을 하고 출시를 하죠. 그리고 나서 피드백을 업데이트하고 이 다섯 단계에 따라서 이제 개발을 하기 때문에 이거에 맞춰서 이 개발 계획 자체를 쭉 잘 세워야 돼요. 그러니까 결국 Project를 관리한다는 거는 뭐를 만들겠다. 언제까지 하겠다. 이건 테스트를 어떻게 하겠다. 이 전체적인 개발 Cycle을 이해하고 그다음에 계획을 쭉 세워가는 거죠. 이 개발 다섯 단계 Cycle을 이해하고 그 안에 계획을 세운다는 것 자체가 또 Product Owner, 이 제품을 만들고자 하는 사람, 그 Owner와 실제로 내가 Leader로써 진행을 하고 Engineer들이 개발하는데 그 사이에 모든 사람들에 소통을 책임져야 되는 거고요. 거기에서 Product Owner는 당장 지금이 아니라 앞으로 몇 년 동안 이제 어떻게 해야 된다라는 비전을 보여준다면 Project Leader는 앞으로 몇 개월 동안 이 일을 한다는 걸 생각하고 Engineer들은 매일매일 일을 생각하는 서로 밸런스를 맞춰가면서 일을 하는 거죠.

그래서 이 계획, 계획을 가지고 개발을 시작했을 때 실제로 개발에 들어가면은 보통 잘 안 돼요. 방금 말했던 것들이 다 좋은 말 같잖아요. 이렇게 제품을 만들어야 된다. 개발을 해야 된다. 그 계획을 세웠다. 그대로 계속 진행하면 좋겠지만 제가 15분 늦게 시작했더니 마음이 굉장히 급한가 봐요. 왜냐하면 15분 늦게 시작해서 이거를 제시간 내에 끝나면 너무 늦게 끝나는 것 같아서 조금 빨리하려는 마음에 마음이 급해지는 것 같은데 제가 마음이 급해질 때마다 이제 물을 마셔서 좀 속도를 조절하겠습니다. 그래서 실제로 이제 개발 계획이 들어가면은 Triple Constraints라고 개발을 할 때 그 안에 세 가지 제약 조건이 있어요. 그래서 실제로 리소스는 충분한가? 예를 들면 개발 인력은 충분한가? 그리고 시간, 그 개발할 수 있는 시간은 충분하냐? 그리고 거기에서 일할 양, Scope 무슨 무슨 걸 개발해야 되냐? 거기서 부족한 게 빠질 수도 있죠. 결국은 시간도 충분하고 인력도 충분하면은 뭐든지 다 개발할 수 있죠. 그래서 좋은 제품이 나올 수가 있어요. 근데 그런 식으로 많이 할 수 있는 회사는 드물죠. 결국은 시간도 부족하고 인력도 부족해요. 그러다 보니까 결국은 Scope에서 원하는 걸 빼낼 수밖에 없어요. 개발하는 양을 줄일 수밖에 없어요. 그런 식으로 해서 쳐내는 게 위험한 Quality가 될 수 있는 거죠. 개발을 다 못하고 덜 하고 낸 제품 망할 수도 있죠. 게임도 마찬가지죠. 인력도 부족하고 시간도 부족하니까 반쯤 만든 거 출시하면 망하는 거죠. 결국 이 안에서 고민해야 될 거는 어떻게 하면 이 시간을 잘 쓸 것인가? 그리고 어떻게 하면은 인력을 더 늘릴 것인가? 이건 쉽지 않잖아요. 결국 돈이 들어가는 거니까 결국은 시간을 잘 쓰는 개념과 그리고 이렇게 일을 자르긴 잘라야 되는데 어떻게 하면 일을 잘 자를 것인가? 결국은 두 가지에 질문이 되는 거예요. 시간을 어떻게 잘 관리하고 Spec을 다 잘 관리할 것인가?

시간을 잘 관리한다는 거는 결국 Waste를 줄이는 거예요. 저희가 일을 하는 방식을 쭉 한 번 살펴봐야 되는데 그 일을 할 때 저희가 보이지는 않지만 상당히 낭비되는 게 많아요. 그래서 도요타에서 시작한 유명한 게 있죠? Remanufacturing이라고 Agile 같은 거 나오고 결국은 그런 산업에서 어떻게 하면은 낭비가 심한가? 그런 걸 분석해 놨고 그런 거를 S/W 개발 쪽에서 가져와가지고 실제로 우리는 어디에서 낭비가 심한가를 분석을 해 놓은 거예요. 그래서 위키피디아 같은데 보면 이런 내용들이 나오는데 필요 없는 코드를 만든다든가 아니면 개발하는 과정에서 딜레이가 생겨서 서로 기다리게 된다든가 아니면은 확실하지 않은 요구 조건을 말한다든가 안에서 정치가 심해서 자기네들끼리 일을 계속 이야기한다든가 뭐 제일 중요한 거는 또 Communication 안에 의사소통을 하는데 굉장히 느리기 때문에 낭비가 심해지는 거죠. 이 다섯 가지가 다 없는 회사는 굉장히 드물어요. 그런데 이 다섯 가지 중에 다섯 가지가 다 있다 그러면 그것도 힘든 거죠. 그래서 이거는 우리 팀은 이 중에서 어디까지 있어야 되는가? 그리고 어떤 거를 빼야 되는가? 그런 거를 좀 고민해봐야 되는 거죠. 제가 마지막으로 일했던 팀의 내용에는 이런 것에 대해서 고민을 많이 했기 때문에 예를 들면 일주일에 미팅을 한 두 번 밖에 안 했어요. Hearthstone 팀의 이야긴데 Hearthstone 같은 경우에는 일주일에 두 번만 미팅을 해서 전 팀원들이 한 번만 미팅, 아니 두 번만 미팅하는 화요일 목요일마다 미팅을 하고 회의 같은 것도 안 잡고 이메일 같은 것도 최대한 안 쓰고 사람들끼리 이야기할게 있으면 바로바로 만나서 하고 그래서 뭔가 계획을 세우고 바로 개발을 하고 테스트를 하고 출시할 때까지 시간이 굉장히 짧았어요. 극도의 빠른 속도로 Agile로 돌려서 대부분의 Blizzard 게임들이 아주 오랜 기간 걸려서 출시가 됐다면은 Hearthstone 같은 경우에는 빠른 시간에 출시가 될 수 있었죠. 그런 게 예를 들면 이런 거를 많이 적용을 했기 때문인 것 같아요. 그래서 이런 waste를 한 번 고민해보시고 지금 일을 하고 있는 도중에서 우리는 어디까지 하고 있나? 어디에서 낭비가 되고 있나? 한 번씩 생각을 해보셔서 이걸 해결할 수 있는 방법은 많아요. Requirement가 좀 정해지지 않았다. 그러면 계획을 좀 앞서서 세운다든가 소통이 잘 안 된다. 그러면 사람들을 자주 모여서 의논을 해본다든가 아니면 전체 개발 과정이 좀 느린 것 같다. 그러면 그거를 쭉 시간을 다시 한 번 정리해 놓고 어디에서 사람들이 시간을 많이 소모하나? 그런 거를 한 번 살펴볼 수 있는 거고요. 어쨌든 이 낭비라는 개념을 생각하셔야 돼요. 저희가 실제로 일을 할 때 생각보다 낭비가 많아요. 아침에 출근해서 저녁에 퇴근할 때까지 실제로 내가 일한 시간에 얼마가 마지막 출시된 제품에 들어갔나? 한 번 분석을 해보시면 생각보다 굉장히 낮을 거예요. 그게 깜짝 놀랄 정도로 낮아요. 그래서 하루에 내가 회의를 하고 뭔가 개발을 하고 이메일을 쓰고 해도 실제로 그 모든 시간이 출시된 제품에 기여가 됐나? 안 됐나? 내가 열심히 만든 거를 석 달 동안 했는데 예를 들면 다 뒤집어엎어서 버린다 그러면 사실 아무 의미가 없는 거잖아요. 그래서 과연 내가 회사에서 일하는 시간, 우리 팀이 일하는 시간, 우리 실이 일하는 시간이 얼마만큼 이 제품에 투자가 됐나? 그런 거 한 번 이 waste 측면에서 살펴볼 필요가 있고요. 그렇게 시간을 절약할 수 있는 거죠.

그리고 두 번째로 시간을 절약할 수 있는 거는 문제를 해결하는 방식 자체를 좀 고민해야 돼요. 그래서 제가 이 도표는 여기저기서 많이 보여드렸는데 굉장히 개인적으로 좋아하는 도표고 여기저기 적용할 수 있는 그런 내용입니다. 결국은 문제들이 자기가 해야 될 일들, 해야 될 문제들이 많은데 그거를 뭐든지 다 해야 된다. 그러니까 내 앞에 있는 모든 일을 다 해야 된다고 생각하면 너무 어려운 거예요. 예를 들면 대통령이 정치도 잘 해야 되고 날씨도 좋아야 되고 우리 집에 돈도 많아야 되고 애들도 건강해야 되고 그런 모든 것까지 다 하려고 하는 순간 멘붕이 오면서 망하는 거예요. 결국 ‘제가 할 수 있는 몇 가지에만 집중을 한다’라는 그런 개념으로써 사람들이 문제 해결 방법에 대해서 고민해서 정의해 놓은 내용이고요. 그리고 오른쪽에 표를 보면은 내가 할 수 있는 일이냐? 할 수 없는 일이냐? Feasibility가 있고 또 중요한 일이냐 안 중요한 일이냐? 그래서 내가 할 수 있고 중요한 일이면 하면 돼요. 그냥 Do it. 하면 되죠. 그런데 내가 할 수 없고 중요하지도 않아요. 그런 일은 Ignore하는 거죠. 생각해보시면 세상에 많은 일이 내가 할 수 없고 중요하지도 않은 일이 굉장히 많아요. 그래서 그런 일들을 과감히 무시해줬을 때 저희의 시간이 늘어날 수 있는 거죠. 옆에 문제 해결 방법에 대해 조금 더 자세히 보면 문제들이 여러 개 있어도 그런 모든 문제를 다 해결할 필요는 없어요. 우리 팀이 개발이 잘 안 된다. Source Code Repository가 좀 이상하다. 기계가 느리다. 뭔가 이유가 많겠지만 그 이유들 중에서 뭐부터 할지를 정확히 결정을 해야 돼요. 이거 이거 이거 세 개는 중요하니까 하고 나머지 일곱 개는 과감히 무시한다. 이렇게 했을 때 시간관리가 제대로 될 수 있는 거죠. 그리고 그 문제에 대해서 그냥 단순히 예를 들면 지금 약간 덥잖아요. 이 방이. 이렇게 덥다. 더운 걸 놓고 치자. 그런데 그 “덥다”라는 것 자체도 정의를 해야 돼요. 뭐 몇 도가 더운 거냐? 지금 온도가 30도가 더운 거냐? 20도가 더운 거냐? 그런 거에 대해서 사실 Define을 해야 되는 거고요. 그리고 실제로 그 문제에 대해서 분석을 하는 거죠. 이걸 에어컨을 설치하면 되느냐? 아니면 사람들이 옷을 좀 덜 입으면 되느냐? 이런 식으로 분석해서 정하고 마지막 이 네 번째 마지막은 아니죠. 4번, 네 번째가 중요한 건데 실제로 그거에 대해서 솔루션을 여러 개 낼 수 있어야 돼요. 에어컨을 설치할 수도 있고 선풍기를 설치할 수도 있고 창문을 넣을 수도 있고 여러 가지 솔루션을 생각해놓고 그중에 하나를, 그중에 최고의 솔루션을 고르는 거예요. 그리고 5번에 가서 실제로 Decision Making을 하는 사람들한테 그걸 보여주고 설득을 한 다음에 결정이 내려지면 마지막으로 여섯 번째 실제로 문제를 풀고 그 문제가 해결된 상태로 남아있도록 계속 관찰하는 거죠. 다시 4번으로 돌아가서 왜 문제에 대해 솔루션이 여러 개가 있어야 되느냐? 만일 문제에 대해서 솔루션이 하나만 있다 그러면은 딱 그 하나를 했는데 그게 안 돼요. 그러면은 사실 망하는 거예요. 다시 앞으로 돌아갈 수도 없잖아요. 괜히 시간을 들여서 뭔가를 했는데 그거에 대한 변화가 없으니까 안 한 것만 못하는 시간만 낭비한 상황이 되는 거죠. 그래서 항상 저는 문제 하나에 대해서 두 개 이상의 솔루션이 있어야지만 그중에 하나를 적용하려 그래요. 딱 문제 하나에 솔루션 하나가 있다는 거는 말하자면 제가 예를 들면 총각인데 전 세계 여자가 딱 한 명밖에 없으니까 결혼을 해야 되는 거예요. 그러면은 너무 복잡해지잖아요. 그러니까 항상 여러 가지 솔루션이 있다고 생각을 하고 그중에서 하나를 찾아가지고 하는 그런 방향으로 가야 됩니다. 이렇게 앞에 waste 이야기했고 지금 problem solving 이야기를 했었는데 어떻게 하면 낭비를 덜 할 것인가? 그리고 어떻게 하면 문제 해결을 잘할 것인가? 이런 거를 하면서 시간이 많이 절약이 되는 거고요.

그다음에 이제 Scope 관리, 아까 Scope 관리를 했었죠? 뭔 일을 할 것인가? 그 일을 할 때는 유명한 사사 분변이죠? 이 표는. 그래서 중요한 일, 안 중요한 일, 그리고 급한 일, 안 급한 일하는데 사람들이 대부분 다 하는 일은 중요하고 급한 일부터 하죠. 그렇기 때문에 중요하고 안 급한 일을 못하고 계속 밀리게 되면서 일이 점점 꼬이게 되는 거죠. 그리고 제일 안 좋은 거는 중요하지 않은데 급한 일도 많이 하게 돼요. 그래서 이 “중요하다”와 “안 중요하다” 그리고 “급하다”와 “안 급하다”에 대한 이렇게 판단을 잘 해야 되는데 혼자서 그걸 하기는 굉장히 힘들어요. 그래서 옆에서 같이 일하는 사람들한테 많이 도움을 받아야 되고 그리고 사람들이 본능적으로 이렇게 급한 일과 안 급한 일을 판단할 수가 있어요. 쉽거든요. 급한 건 사람들이 날을 치니까. 그런데 중요하고 안 중요한지를 평가하기가 굉장히 어려워요. 그러니까 혼자서 판단하려고 하지 말고 주변 사람들의 판단을 받아야 되고 또 중요하고 급한 일이라고 그래도 그걸 어떻게든지 모드를 바꿀 수가 있어요. 사람들이 계속 중요하고 급한 일을 던져주면은 거기에 끌려가다 보면은 이걸 reactive라고 그러는데 끌려가면서 일을 하다 보면은 일이 저를 끌고 가는 거예요. 시간이 저를 지배하게 되는 거예요. 근데 그걸 한 번 체인을 끊어주면 저희가 중요하지만 안 급한 일로 만들어서 관리를 할 수 있게 되는 거죠. 그래서 얘를 들면 전화가 왔어요. 그래서 “이거 이거 이거 언제까지 해주세요.”라고 이렇게 이야기하는데 그런 상황에서도 “아 지금 바쁘니깐 그거는 30분 후에 다시 전화 연락드리겠습니다”라고 해서 끊고 하던 일 멈추고 그 일을 할 수 있게 되는 거죠. 그런데 그렇게 하지 않고 지금 하고 있는 일 도중에 누가 무슨 급한 일이라고 줬다고 그걸 받아서 하면 그거 하는 도중에 또 급한 일이 오고 점점 커지죠? 그러다 보면 결국 일에 일이 쌓아가지고 나중에는 폭주하는 상태가 되는 거예요. 결국 아무리 일이 바쁘고 급해도 그거를 관리할 수 있는 스킬을 길러야 되는 거죠. 그래서 이 우선 순위를 잘 정했을 때 아까 Scope 무슨 일을 할 것인가? 결국은 Waste를 덜 해서 시간을 절약하고 문제를 잘 골라서 하면 시간을 절약하고 그리고 일을 할 때에도 어떤 일을 할 것인가 우선순위를 정하는 데서 저희가 부족한 시간들과 부족한 리소스를 해결했을 때 좋은 제품을 만들어낼 수 있는 거죠.

이렇게 쭉 본 게 Project 관리의 개념이고요. 사실 Project 관리는 이렇게 쉽게 설명할 수 있진 않아요. 이거보다 복잡한 게 많은데 사실 근본으로 가면 결국 지금 말씀드렸던 우리가 얼마나 시간을 잘 쓰느냐? 그리고 얼마나 있는 리소스를 잘 쓰느냐? 그리고 방향은 잘 정해져 있느냐? 그리고 그 안에서 사람들이 적절한 중요한 일부터 하고 있느냐? 그런 것들을 쭉 보는 일이죠. 결국 개발 과정 자체를 쭉 보는 거예요. 그런 일을 하는 게 팀장인 거고 이제 두 번째로 왔을 때 Technical Lead로 올 수 있는데 이제 Technical Lead는 좀 쉬워요. 왜냐하면 기술적인 거니까 사실 Engineer, S/W Engineer 개발자가 팀장이 됐다. 그러면은 Technical Lead가 이미 될 수 있는 자격이 이미 좀 있는 거죠. 그래서 Good Technical Direction, 좋은 개발 방향을 정하고 또 개발 과정에 개발 환경이 잘 되어 있는지 확인을 하고 그리고 제가 개인적으로 추천하는 이 Joel Test 안 해보신 회사나 팀이 있다면은 한 번 해보시길 바라요. 찾아보시면 Google 가서 Joel Test 이렇게 해보시면 나오거든요? 그러면 지금 여러분의 개발 환경에 대해서 이런 걸 쓰고 있습니까? 예를 들면 소스 코드를 쓰고 있습니까? Daily Build는 하고 있습니까? 이런 질문이 한 열 개 정도 나오는데 거기 나온 질문에 한 아홉 개 정도는 다 사실 하셔야 좋은 개발 환경 있는 거죠. 어쨌든 기술적인 거를 보고 거기에 이제 개발해야 될 백로그, 일해야 될 목록들이 나오고 거기에 Technical된 기술 부채 같은 거? 이런 것들을 다 기술적인 것만 보는 거예요. 그러니까 사실 조금 더 쉽죠? 아까 Project적인 거는 사실 생각해야 될 대목이 많은데 이 기술적인 거는 저희가 Engineer로써 아는 쪽이에요. 결국 How to do. 어떻게 하는지 그쪽에 대한 이야기인 거죠. 그런데 이 Technical Lead 했을 때 제 주변에 이제 개발자들이 자기가 팀장이 됐을 때 이렇게 Technical Lead로 이렇게 이런 식으로 이런 식으로 개발하면 된다. 그건 쉬운데 나머지는 좀 어렵다. 그러면 제가 농담 삼아서 그런 이야기를 해요. 당연하다. 우리는 S/W 개발자가 된 이유가 사람보다 기계가 좋아서 된 거다. 우리는 당연히 기계를 다루는 게 더 쉽고 이렇게 사람을 다루는 거는 어렵다. 그러니까 그걸 인정을 하고 우리가 사람 다루는 걸 잘 못하는 거를 인정을 하고 거기에서 좀 노력을 해서 더 발전해야 된다. 그런 식으로 이야기하면 다들 용기를 가지고 하더라고요. 그래서 다 잘하는 사람은 힘들어요. 그래서 Project Lead도 잘하고 Technical Lead도 잘하고 세 번째 다루게 될 People Manager까지 잘하는 사람은 굉장히 드물죠. 그래서 이 세 개를 혼자서 다 하겠다고 생각하면 안 되고 좀 나눠가질 필요도 있어요. 그래서 제가 Project Lead를 잘한다 그러면 Technical Lead하고 People Manager는 사람들한테 나눠준다든가 아니면 팀 안에 개발을 잘하는 친구가 있다? 그러면 그 친구한테 Technical Lead를 좀 맡겨주고 나는 이제 Project Lead하고 People Manager를 한다든가 일을 좀 나눠볼 필요가 있습니다.

그래서 여기에서는 아까 그 Priority, 우선순위하고 좀 다른 방향에서 좀 고민을 하게 되는데요. 결국 실제로 기술적으로 일을 진행해나갈 때 뭐를 가지고 고민을 하고 나면은 이 일을 하는데 중요한 일이냐? 안 중요한 일이냐? 급한 일이냐? 안 급한 일이냐? 이걸 갖고 고민하는 게 아니라 다른 방향에서 고민을 하게 돼요. 이 일은 지금 우리가 원해서 하는 거냐? 아니면 우리가 필요해서 하는 거냐? 이런 걸 갖고 고민을 하고 또 이 일은 우리가 아는 일이냐? 모르는 일이냐? 갖고 고민을 해요. 이 모르는 일이라는 대목이 참 재밌어요. 제가 S/W 개발자들을 이렇게 레벨을 나눌 대 초급 개발자, 중급 개발자, 고급 개발자 이런 식으로 나누거든요. 초급 개발자는 시킨 일 잘 하는 사람, 중국 개발자는 안 시켜도 일 잘하는 사람, 고급 개발자는 다른 사람들을 시킬 수 있는 사람. 그런데 그 위에 고급 개발자 위에 이제 고수 개발자가 있어요. 고수. 대가. 더 쎈 개발자가 있는데 이 사람들은 무엇이냐? 저는 이제 Unknown의 영역, 모르는 영역, 해 본 일을 하는 거는 누구나 다 할 수 있죠. 그런데 이 사람들은 안 해본 일, 한 번도 안 해본 영역, “우리가 이쪽 안드로이드 개발을 해봤는데 이제 iOS 개발을 해봐야 될 것 같아. 이것 좀 공부해서 해볼 수 있을 것 같아?” 그러면은 “그 정도 한 두 달이면 할 수 있을 것 같은데요?”하면서 조절할 수 있는 거죠. 결국 왜 이게 중요하냐면 이 개발을 하다 보면 항상 저희가 아는 쪽에서만 할 수가 없어요. 모르는 쪽에 뛰어들어가 살아야 되거든요. 그래서 결국 모르는 영역을 얼마나 잘 할 건가? 그래서 모르는 영역에 대해서 판단을 잘 할 수 있어야 Technical Management가 될 수 있는 거죠. 그래서 좋은 개발자일수록 자기가 모르는 분야에서 처음 들어가는 분야에서도 일을 할 수 있어야 된다고 믿습니다.

그리고 결국 이 제품의 품질은, 제품의 품질은 이런 Technical 쪽에서 나오는 거거든요. 그래서 좋은 품질을 만들어 내도록 하는 건 사실은 좋은 코드가 있어야 되는 거고 좋은 QA가 있어야 되고 결국은 다 기술의 영역인 거죠. 그런데 이거를 빨리 내려고 집중만 하다 보면 Efficiency, 예를 들면 사람들이 빨리빨리 일을 하고 모든 사람들이 열심히 일을 하자. 그런 것만 하다 보면 사실 이 품질이 떨어지는 거예요. 그래서 효율성이 품질의 적인 거죠. 너무 효율만 생각해서 팀의 예를 들면 사람이 열 명이다. 열 명이 다 바쁘게만 일하게만 한다고 좋은 제품이 나오는 건 아니에요. 막말로 열 명 중에 세 명이 막 열심히 일해서 막 만들어내고 나머지 일곱 명은 딩가딩가 해도 이 세 명이 잘 만들면 성공하는 거거든요. 억지로 일곱 명이 노는 거 보기 싫다고 막 일을 시키면 그 사람들이 이상한 코드 넣고 서로 호흡이 안 맞고 해서 망가질 수도 있거든요. 결국은 그래서 이 품질과 효율성 사이에서 계속 고민을 해야 되고요. 그리고 항상 일을 할 때는 이렇게 Speed, 빨리 일을 하는 게 중요한 게 아니라 Direction, 올바른 방향으로 가는 게 더 중요하거든요. 특히 기술적인 분야에선 그래요. 그러니까 제품적인 방향으로는 이쪽 방향으로 만들자 그래서 가다가 이거 아닌 것 같아. 그러면 뒤집어엎을 수 있거든요. 그런데 기술적인 방향으로 시작할 때 우리는 C# 쓰자. 그래서 반쯤 만들었는데 아 이 상황이 아닌가 봐. Java로 바꾸지. 그러면은 망한 거죠. 사실 그렇게 할 수가 없잖아요. 그러니까 차라리 제품은 뒤집어엎을 수 있는데 기술은 뒤집어엎을 수 없어요. 그렇기 때문에 기술의 방향을 정하고 그쪽으로 계속 개발하는 도중에는 계속 살펴봐야 되는 거죠. 그래서 결국 제가 되게 좋아하는 말인데 개발할 때 이렇게 단계를 거치면서 가야 돼요. 왜냐하면 중간에 바꿀 수가 없잖아요. 기술적인 방향은. 기술적인 방향은 바꿀 수가 없기 때문에 매번 확인하면서 프로토타입 같은 거 만들면서 가 봐야 되는데 제일 처음 만들 때는 Make it working. 동작하게 만들고 그다음에 Make it right. 올바르게 만들고 그다음에 Make it fast. 이렇게 빠르게 만들어라. Optimize해라. 그런 뜻인데요. 어쨌든 간단하게 프로토타입 만들어서 돌아가는 거 확인하고 그다음에 괜찮은 솔루션을 도입을 해서 좀 제대로 만들고 마지막에 그거를 최적화를 해서 빠르게 만들어라. 계속 방향을 이렇게 검사하면서 개발을 천천히 잘하자. 그러니까 막 하루빨리 막 일을 해서 빨리빨리 되는 게 중요한 게 아니라 제대로 하는 게 중요하다. 그러니까 예를 들면 Project Lead는 제품을 출시하는 게 중요하다. Technical Lead는 제대로 하는 게 중요한 거죠. 그래서 저희가 저희 아버님이 저한테 주신 인생의 교훈이 몇 가지가 있는데 이거 굉장히 중요한 교훈인데 특별히 여러분들한테만 오늘 공유해 드리겠습니다. 첫 번째 교훈인데 제가 고등학교 때 이렇게 공부를 열심히 해보고 싶었어요. 반에서 1등을 한 번도 못 해봤는데요. 공부를 그렇게 잘 하진 않아서. 반에서 1등을 한 번도 못해봤는데 한 번 1등을 해보고 싶어서 밤에 막 열심히 공부하고 있으면 12시가 되면 아버님이 와서 불을 꺼요. 그래서 저는 화를 내죠. 아니 나 밤새 공부해서 1등 한 번 해보고 싶은데 아버님이 계속 불을 끄면서 자라. 자라. 그래서 아니 내가 밤새서 공부해서 1등 안 될 것 같아서 그러냐? 전기세가 아까워서 그러냐? 그랬더니 그건 아니고 한 번 밤새서 1등 하면 계속 밤샐래? 그러니까 뭐든지 쭉 할 수 있는걸 해야지. 한 번 오버해가지고 뭔가를 한다 해가지고 의미가 없다는 거죠. 그러니까 이 개발도 마찬가지예요. 뭔가 한 번 해 갖고 억지로 뭔 결과를 만들어 내는 건 계속할 수 없는 거예요. 꾸준히 만들어 낼 수 있는 시스템을 만들고 Process를 만들고 기술을 하나하나씩 신경을 써야 되는 거지 중간에 살짝 이렇게 해킹하고 뭔가를 만들어 내도 금방 그거는 빵꾸가 난다는 거죠. 그래서 Technical Lead로써는 이 기술이 좋고 얼마나 오래갈 수 있는가에 대해서는 계속 생각을 해야 되는 거죠. 그래서 잠깐 뭔가 빨리 만든다. 이런 거에 신경 쓰는 건 좀 위험한 일이라고 봅니다.

세 번째로 갔을 때는 이제 People Manager, 사람 관리죠. 이게 제일 힘들어요. 그래서 제품 관리도 잘 돼서 팀이 좋은 제품을 만들어내고 Technical 관리도 잘 돼서 팀이 좋은 기술도 만들고 Engineer들이 성장도 하고 그러는데 그 안에서 과연 이 사람들이 행복하게 일을 하고 있고 또 성장도 하고 있고 좋은 제품을 내고 있지만 그 안에서 더 많은 일을 할 수 있느냐? 이런 걸 계속 봐야 되기 때문에 사실 제일 힘든 대목이에요. 사람을 다루는 일이라서. 그래서 그 사람을 다루는 것에 대해서 한 번 살펴보겠습니다. 그래서 채용을 하는 거, Hiring이죠. On-Boarding은 이렇게 팀에 데리고 오는 것 결국 사람을 관리한다는 거는 사실 Hiring부터 출발해야 돼요. 사람을 뽑아와서 “어떻게 뽑느냐?”부터 고민하는 게 사실 팀장으로서 중대한 거지 온 사람들만 관리하면 안 돼요. 어떻게 뽑는지? 좋은 사람부터 뽑아와야죠. 왜냐하면 제일 좋은 팀을 만드는 방법은 좋은 사람들로만 뽑는 거예요. 좋은 사람들만 뽑아오면 팀이 저절로 돌아가는 거죠. 채용부터 신경을 써야 되고 그렇게 뽑아온 사람들이 이 팀에 잘 적응할 수 있도록 On-Boarding도 잘 해줘야 되고요. 그리고 팀에서 실제로 일을 하게 되면 One-on-One 이렇게 일대일 면담을 하면서 계속 그 사람들을 챙겨줘야 되는 거고요. 그런 식으로 했을 때 개발자들의 스타일이 달라요. 사람들마다. 그래서 그 사람들을 이해하는 게 굉장히 중요한데 그래서 유명한 책 중에 어떤 책이 이렇게 사람들을 네 가지로 구분해놨어요. Why 타입, What 타입, How 타입, What If 타입 이런 식으로 네 가지로 구분해놨는데 예를 들면은 “다리를 지어라. 다리를 지어라.”라고 이렇게 말을 하면은 Why 타입은 왜 지어야 되나요? 다리가 왜 필요하나요? 이런 식으로 물어본데요. 어떤 사람들은 그렇게 물어보겠죠. 그리고 많은 한국 사람들은 What 타입이에요? “아 무슨 다리를 지어야 됩니까? 현수교를 지어야 됩니까? 사장교를 지어야 됩니까?” 바로 그 이유는 궁금하지 않고 할 일에만 집중을 하는 거죠. 저희가 이렇게 한국에서 교육받은 거라든지 일하는 스타일이 이쪽에 많이 적응이 돼있죠. 바로 할 일에 뛰어드는 그런. 그리고 How는 약간 기술 지향 주의자죠. 그래서 기술적으로 굉장히 센 엔지니어라든지 이쪽으로 가는 거죠. “그건 콘크리트를 많이 쓸까요? 쇠를 많이 쓸까요?” 바로 그 다리에 스타일보다는 다리에 들어가는 기술에 관심이 있는 거죠. 대부분의 사람들이 이 셋 중에 하나고 미국에 많은 회사들은 예를 들면 이게 한 30%, 30%, 30% 섞여 있다 그러고 한국 회사들은 제가 볼 때는 Why하고 How가 좀 적고 What이 더 많은 것 같아요. 그런데 그게 장단점이 있어요. 더욱더 빨리 갈 수 있는 걸 수도 있고 진행 속도도 빠르고 사람들이 What에만 집중을 하니까. 그런데 여하튼 미국이건 한국이건 What If 좀 이렇게 엉뚱한 생각을 하는 사람들이 있어요. 예를 들어서 다리를 지어라 그러면은 “배 타고 건너가면 안 되나요? 강 건너는데 왜 꼭 다리를 지어야 되나요?” 이렇게 엉뚱한 소리 하는 사람들이 있는데 이 사람들이 어떻게 생각하면 되게 짜증 나요. 일을 해야 되는데 계속 헛소리하니깐. 이런 사람들을 잘 보관해 놓으면은 이 사람들이 예를 들면 애플 안에서 아이폰을 만들고 뭐 이렇게 새로운 걸 만드는 사람들이에요. 항상 Out of Box로 새로운 걸 만드는 사람들이 What If인 사람들이죠. 그래서 이 사람들을 그래서 잘 보관해 놔야지 팀에 피해가 안 되면 이 사람들을 밖에다 내놓으면 또 다른데 가서 사고 칠 수 있어요. 사실 회사 안에 여유가 있다면 보호를 좀 해주는 게 좋아요. 예를 들면 이거 하고 비슷한 건데 저는 팀 관리를 할 때도 예를 들면 일을 잘 하는 사람들이 있고 일을 못 하는 사람도 있을 거잖아요. 그런데 재밌는 거는 일 못하는 사람들이 없어진다고 일을 다 잘하는 건 아니잖아요. 항상 이 Percentage가 있잖아요. 뭐라 그러더라? 진상 불변의 법칙인가? 그런 것도 있더라고요. 그러니까 “모든 조직에 진상은 몇 명이 있고 아무리 둘러봐도 그중에 진상이 없다 그러면은 네가 진상이다.” 그런 조크가 있더라고요. 그러니까 결국 팀의 이 팀을 이뤄서 같이 일한다는 것 자체가 여러 사람들이 섞여서 일을 하는 거예요. 그래서 저 사람은 다른 생각하고 이 사람은 다른 생각하고 저 사람은 다른 생각하는 사람들이 섞여서 일을 해야 되기 때문에 이 People Manager로써 제일 중요한 거는 그런 모든 거를 받아들일 수 있는 마음의 여유가 돼야 해요. 그러니까 나하고 똑같은 사람 열 명 대리고 일한다고 생각하는 순간 망하는 거예요. “나랑 다른 사람 열 명을 일을 잘 하게 만들겠다”라고 해야 사실 되는 거죠. 그래서 저는 People Manager 뽑을 때 제일 중요한 게 Heart for People하고 마음속에 사람에 대한 사랑이 있어야 돼요. 근본적으로 다른 사람에 대한 뭔가 마음속에 애정? Love 이런 건 아니지만 하여튼 사람을 사랑해야 돼요. 사람을. 그래서 앞으로 다시 가면 Project Lead는 제품에 대한 사랑이 있어야 돼요. 제품. “나는 제품을 꼭 내고 싶다. 이 제품을 꼭 출시하고 싶다”라는 그런 강한 의지가 있어야지 Project Leader를 할 수가 있고요. Technical Lead는 당연히 기술에 있어야 되죠. “나는 기술을 정말 좋은 기술로써 이 제품을 만들고 싶다. 사람들은 모르겠지만 이 안에 백엔드나 이 안에 소스 코드는 정말 예술로 만들고 싶다.” 그런 게 있어야 Technical Lead가 될 수 있는 거고 People Manager는 정말 사람을 좋아해야 돼요. “나는 저 사람이 잘 됐으면 좋겠습니다. 나는 저 사람이 일을 잘 했으면 좋겠다.” 그런 마음이 진짜 가슴속 깊이 있어야 훌륭한 People Manager가 될 수 있는 거죠. 그래서 사람들 일하다가 팀장으로 승진시킬 때쯤 돼서 인터뷰를 제가 하면서 봐요. 그러면 이 셋 중에서 어느 성향인가? 그러면 Project Lead가 강한 사람이 있고 Technical Lead가 강한 사람이 있고 이렇게 People Manager가 강한 사람이 있죠. 다 장단점이 있어요. 세 개 다 잘 하는 사람은 드물 테니까요. 그리고 저 같은 경우에도 하나만 계속하거나 이 세 개를 한꺼번에 하면 되게 힘들었어요. 그래서 좀 이렇게 돌아가면서 했어요. 어쩔 때는 한 1년 정도는 People Manager로 그냥 사람들만 1:1 면담하면서 관리 좀 하고 그다음 1년은 그냥 Technical Lead로 개발만 계속 신경 쓰고 그다음 1년은 Project Lead로 팀 관리만 하고 그런 식으로 좀 왔다 갔다 했던 게 있어요. 왜냐하면 한꺼번에 세 개를 하면 힘들긴 힘들더라고요. 그런데 이 세 가지 경험을 다 해보는 건 굉장히 중요한 것 같아요. 알아야 되거든요. 내가 뭘 잘하고 뭘 못하는지 그래야 다른 사람들한테 그걸 도와달라고 할 수 있거든요.

그래서 One-on-One은 크게 보면 세 가지 컨셉을 보는 거예요. 1:1 면담할 때 무슨 이야기하냐? 예를 들면 저는 2주에 한 번 정도 1:1 면담하는 걸 좋다고 생각하는데 팀장이 팀원들이랑 실장이 팀장님들이랑 이렇게 2주에 한 번 정도를 만나서 얘기하긴 해야 돼요. 한 시간이나 30분 정도는 그러면서 다뤄야 될 주제가 Performance, 일은 잘 하고 있는가? 그다음에 Growth, 성장은 하고 있는가? 마지막에 Happiness, 이제 행복한가? 왜냐하면 Performance, 지금 일을 못하면 위험하잖아요. 회사에 잘릴 수가 있는 거잖아요. 안 되지. 일을 잘하도록 계속 유지를 시켜줘야 돼요. 그런데 Growth 이 사람이 지금 일을 잘하는데 몇 년 있다가는 일을 못할 수도 있잖아요. 성장을 안 하면은. 세상은 계속 변하는데. 저희가 지금 쓰고 있는 기술이 몇 년 후에도 계속 쓰인다는 보장이 없잖아요. 계속 공부를 해야 되는데 그 성장을 할 수 있도록 옆에서 계속 신경을 써줘야 되는 거지 그냥 “일만 해라”라고 놔둬서 그 사람이 일을 하면서 저절로 성장하기를 바라는 거는 너무 큰 무리죠. 특히 저희가 일을 하면서 성장하는 것과 또 공부해서 성장하는 건 다른 거거든요. 이런 거를 계속 신경을 써줘서 “나는 너의 Manager다. 나는 너를 도와서 일을 잘하게 하고 싶다.” 이런 거에 대해서 결국 내가 뭐를 이렇게 시키는 사람으로서 앞에 Project Lead나 Team Lead, Technical Lead로써 뭔가를 시키는 사람이 아니라 People Manager의 마인드로 봤을 때는 “내가 너를 위해서 뭘 해줄까? 네가 지금 부족한 게 뭐냐? 이렇게 일이 잘 안 되냐? 아니면 성장을 하고 싶은데 성장이 안 되냐? 아니며 안 행복하냐?” 이런 걸 다 보고 그 안에서 해줄 수 있는 일을 찾아야 되는 거죠. Manager로써. 그래서 마음을 열고 시작이 중요해요. 시작이. 저 같은 경우는 팀을 새로 Set up을 하면 제일 처음에 일대일 면담을 하면서 딱 이야기를 하죠. “아 내가 너의 인생을 위해서 네가 하고 싶은 일이 많겠지만 그걸 다 도와줄 수가 있겠냐. 네가 좋은 여자친구를 찾고 싶다. 내가 그걸 도와줄 수도 없는 일이고 키가 갑자기 커지고 싶다. 그걸 도와줄 수 없는 거고 내가 유일하게 도와줄 수 있는 거는 네가 회사에서 일을 잘하게 도와줄 수 있다. 그리고 네가 원하는 Career Path, 성장하고 싶은 쪽으로 공부할 수 있도록 도와줄 수 있고 또 회사에서 일을 할 때 행복하게 일을 할 수 있겠다. 결국 네가 회사에서 해야 되는 일을 내가 최대한 많이 도와줘서 이렇게 성장을 하고 행복하고 또 일도 잘하게 하는 그게 내 일인 거고 너는 나를 최대한 이용해가지고 네가 그걸 잘 하는데 도움을 받아라. 그래서 일도 잘해서 그 일 잘한 걸로 돈 많이 벌어서 집을 좋은 걸 산다든가 이런 식으로 하는 거지 다른 쪽에서 나는 못 도와준다.”라고 처음부터 이렇게 명확하게 “나는 너를 도와주는 사람이고 너는 나를 그걸 이용해서 최대한 네가 하고 싶은 일을 많이 해라.”라는 식으로 이렇게 Manager를 Set up하면 많은 사람들이 마음을 열고 도움을 많이 받더라고요.

그래서 Performance 쪽으로 봐서 얼마나 일을 잘 하는지 평가를 한다면은 “너는 얼마나 일을 잘 하고 있느냐? 그리고 팀은 얼마나 일을 더 잘하고 있느냐?” 그리고 제가 One-on-One할 때 많이 물어보는 질문이죠? “지난 2주 동안 했던 거 중에 뭐가 제일 잘한 일인 것 같냐? 그리고 지난 2주 동안 했던 거 중에 뭐가 좀 아쉬웠냐?” 항상 잘한 거하고 아쉬운 걸 물어봐서 잘한 걸 계속할 수 있도록 해주고 아쉬운 거는 개선할 수 있는 방법을 같이 고민하는 거죠. 그런 식으로 계속 일을 하는 거를 지켜보는 거고요. 이건 뭐 방식이 워낙 많기 때문에 워낙 이런 책들도 많고 그런 걸 읽어보시면 될 것 같고요. 항상 뭐를 잘했고 뭐를 더 잘할 수 있었는지에 대해서 계속 고민하고 이게 “잘했다. 더 잘할 수 있었다”에 대한 기준은 고객을 기준으로 생각해야죠. 그래서 우리가 만든 제품, 우리가 하고 있는 일에 최종 평가자, 고객은 누구인가에 대해서 계속 생각을 해봐야 되는 거고요. 그래서 Performance에 대해서 생각을 해보고 

또 Performance는 Performance Review라고 단순히 그냥 “일 잘한다, 못 한다”가 아니라 회사의 평가 기준이 있어야 되잖아요. 물론 그냥 A, B, C, D, E, F 이런 식으로 쭉 나눠버릴 수도 있지만 조금 더 체계적으로 나눠서 예를 들며 제가 개인적으로 만들어 쓰고 있는 다섯 가지 카테고린데 소통은 잘 하느냐? 아니면 기술적으로 많이 알고 개발을 잘 하느냐? 그다음에 계획은 잘 세우느냐? 그리고 이렇게 일을 할 때 집중해서 그 일을 잘 하고 주변 사람들하고 잘 연동이 되느냐? 그리고 제품을 만들어서 과연 출시를 할 수 있느냐? 이런 식으로 한 다섯 가지 정도 카테고리를 만들어서 어떤 사람을 일을 잘 하고 있는지 못하고 있는지 평가할 때 그냥 A입니다. B입니다. C입니다. 그러고 끝나는 게 아니라 이런 카테고리는 잘하고 있고 이런 카테고리는 못하고 있으니까 이쪽 카테고리를 좀 잘해보면 어떻겠습니까? 저희가 시험을 보고 평가를 하는 거는 거기에서 어떤 걸 잘하고 어떤 걸 못하는지를 알아내서 거기에 계획을 세워서 더 잘할 수 있도록 하는 거거든요. 그러니까 항상 평가, Assessment가 있는 건 그 뒤에 Action이 있는 거기 때문에 이런 Performance Review도 그냥 1년에 한 번 하고 끝나면 아무 의미가 없어요. 그러니까 이런 거를 1년에 한 번 하는 게 아니라 두 달에 한 번씩 계속해가면서 그 사람이 더 발전할 수 있는 방법을 찾아야죠.

그리고 이런 Performance Review도 단순히 이 정도로만 끝나는 게 아니라 아까 Technology Section 있었잖아요 다섯 개 중에 하나. 그거에 대해서 Technology 세부 항목들은 뭐가 있고 C++는 잘 하느냐? SQL은 잘 하느냐? 그래서 점수를 매긴 다음 1점에서 5점까지 예를 들어서 점수를 준다 그러면 예를 들어 Associate Level 초보 개발자냐? Mid Level 중급 개발자냐? Senior, 고급 개발자냐? 이런 거에 따라서 초급 개발자는 C++를 뭐 한 2점 정도는 해야 되는데 데이터 베이스는 1점이면 충분하다. 그런데 Senior로 가면은 C++가 4점 정도는 해야 되고 SQL은 2점 정도 해야 된다. 요구 조건도 볼 수 있는 거죠. 그러니까 굉장히 복합적으로 Performance Review를 가지고 사람들의 상태를 평가할 수 있는 거죠. 어느 정도까지 가야 된다. Requirements Matrix 같은 것도 한 번 만들어 볼 수 있고요. 이렇게 했을 때 사람들이 지금 나는 초급 개발자인가? 중급 개발자인가? 고급 개발자인가? 어떻게 하면 더 성장할 수 있는가? 이런 거를 더 가이드를 줄 수 있겠죠.

결국은 그렇게 Performance Review한 거를 가지고 사람들이 이렇게 성장할 수 있도록 도와줘야 되는데 그 안에서 제가 주로 쓰는 방법은 다섯 가지 아까 항목이었다. 그러면 그중에서 잘 하고 있는 것. 본인이 나는 진짜 이걸 잘하고 있다고 믿는 하나를 고르게 해요. 나는 예를 들어 “Communication 잘한다.” “그러면 그걸 계속해라.” 그런데 내가 못하는 뭔가? “나는 Technology가 좀 약하다. 기술적인 공부가 좀 부족하다.” 그래서 잘하는 거는 계속 잘하고 있는지 1:1 면담을 할 때마다 확인을 해요. 계속 이번 주는 Communication 잘했고 다른 사람 문제는 없고 그런 걸 계속 확인하면서 못하고 있는 거, Technology 뭔가 목표를 정하게 해야죠. “그 Technology를 어느 정도까지 끌어올리겠다. 뭐 책을 읽어서 공부를 해서 자바를 잘 해야겠다.” 그런 식으로 하나의 카테고리를 고른 다음에 그쪽을 꼭 진행할 수 있도록 해 줘야 되는 거죠. 그래서 그거를 다른 말로 Goal, Plan, Action이라 그러는데 항상 목표를 세우게 해야 돼요. “나는 Technology 쪽에서 Java를 앞으로 공부하고 싶다.” 그럼 Goal이 없으면 할 수가 없잖아요. 그래서 Goal을 정해야 되는 거고 거기에 Plan 실제적으로 “매주 Java 책을 한 권씩 읽겠다.” 그런 Plan이 있어야 되는 거죠. Action은 실제로 해야 되는 거죠. 그래서 그게 이 Action을 하고 있는지를 Manager가 이 주에 한 번씩 확인해야 되는 거죠. “이번 해 동안 Java 책 열 권 읽고 어느 정도 실력을 쌓겠다고 했는데 계속 잘 하고 있느냐?” 그걸 계속 물어봐서 확인하면서 성장하고 있는지 그래서 잘 하고 있는 건 잘하고 있고 못하고 있는 거는 좀 더 잘할 수 있도록 성장하고 있는지를 확인하는 거죠. 그런데 이 여기에서 뭔가 자기가 못하고 있는 문제를 찾고 그거를 잘 할 수 있도록 계획을 세우고 실천하는 거를 본인이 하지만 그거를 확인하는 거는 Manager의 의미인 거죠. 그리고 사람들이 내가 뭘 잘하고 뭘 못하는지에 대해서 평가하기가 좀 어려워요. 그리고 자기 자신에 대해서 객관적으로 평가할 수 있는 사람도 굉장히 드물고 어려워요. 그래서 주변 사람들하고 비교하는 방식을 쓰면 좋긴 좋아요. 예를 들면은 Technology다 그러면 “우리 팀 내에 누가 제일 Technology가 센 거 같냐?” Communication이다. 그러면 “우리 팀 내에 누가 Communication을 잘 하는 것 같냐?” 특별히 그쪽 분야의 잘하는 사람을 찾게 만든 다음에 너의 현재 상태와 그 사람의 상태를 비교해서 “그 사람은 왜 그걸 잘 하는 것 같냐? 너는 왜 이거를 못 하는 것 같냐? 어떻게 하면 잘 할 것 같냐?” 좀 비교를 하면서 액션 아이템을 만들라고 하면 좀 쉬워요. 그래서 “내가 어떻게 해야 성장할지를 잘 모르겠지만 저 사람이 내가 볼 때는 우리 팀에서 제일 Delivery를 잘한다. 저 사람한테 일만 맡기면 항상 제시간 안에 끝낸다.” 그러면 옆에서 관찰하라 그러는 거죠. 그 사람을 지켜보면서 “그 사람은 왜 제때 끝내는 것 같으냐?” 그래서 방법을 찾아내고 그 방법을 배워서 적용하라는 거죠. 그래서 다시 앞으로 가서 팀에 많은 사람들이 조금씩 다른 사람들이 있으면 좋아요. 자기가 다 똑같은 사람만 있으면 안 되죠. 다 Communication만 잘 하는 사람만 있으면 안 되죠. Communication 잘 하는 사람 하나, Technology 잘 하는 사람 하나, Delivery 잘 하는 사람 하나 있어야 서로 이렇게 조합이 되면서 일도 잘 되고 서로 도와줄 수도 있고 보고 배울 수 있는 거고요. 

그래서 Performance, “일을 더 잘 하고 있냐?”도 봤지만 그다음에 성장을 해야 되는 거죠. 사람들이 지금 일만 잘해서 되는 건 아니고 그리고 평가를 잘 받아오는 것만 중요한 게 아니고 Performance Review는 거기서 나오는 거죠. 인사 평가에서 나오는. 성장을 계속해야 되는데 이 성장은 Individual Development Plan이라고 자기의 어떤 계획을 세워야 돼요. 지금 일하고 있는 걸 잘하는 건 두 번째 치고 내가 앞으로 1년 후, 3년 후, 5년 후에는 어떤 쪽에 능력을 더 갖추고 싶다는 계획은 세우게 만드는 거죠. 그래서 아까 어떤 사람은 1년 후에 자바 개발자가 되고 싶다. 그럼 3년 후엔 뭐하고 싶냐? 5년 후엔 뭐하고 싶냐? 그런 걸 실제로 본인이 꿈을 가지게 하고 거기에서 목표를 세워서 그쪽 개발을 하게 만들어야 되는 거죠. 그래서 그걸 위해서 필요한 리소스를 이제 공부하고 잘하고 있는지 체크하는 게 Manager가 하는 거고요. 그래서 제가 팀 사람들한테 자주 던지는 질문 중에 하나가 10년 후에 대한 질문을 던지는데 10년 후가 너무 멀다 그러면 5년 후에 던지고 지금 넥슨에 와서도 사람들하고 이야기하고 이런 질문을 많이 던지는데 “5년 후까지 넥슨이 있을 것 같냐?” “당연히 있을 것 같다.” “그러면 왜 그럴 것 같냐?” 사람들이 과연 이 회사가 잘 나갈 것인가? 고민을 한 번 하게 만들고 그다음에 “5년 후에는 당신이 계속 넥슨을 다니고 있을 것 같냐? 왜 다니고 있을 것 같냐?” 과연 여기에 내가 계속 있을 가치가 있느냐? 나는 이 회사가 앞으로 5년, 10년 후까지 갈 거라고 믿고 또 나는 그 안에서 5년 10년 후까지 계속 일하고 싶은 마음이 있는지를 확인한 다음에 마지막에 “그럼 5년 후에는 네가 무슨 일을 하고 있을 것 같냐? 지금 하고 있는 일을 계속하고 있을 것 같냐? 아니면 전혀 다른 일을 할 것 같냐?” 결국 미래를 생각하게 만드는 거예요. 그게 성장의 동력이 되는 거죠. 지금 회사에서 5년 후 회사는 어떤 걸로 변하고 지금 내가 5년 후에 가서 일을 하고 거기서 어떤 기술이 필요할지를 고민해야 지금부터 공부하면서 미래를 준비할 수 있는 거죠. 그렇게 했을 때 계속 성정이 되는 거고 사실 5년, 10년 후까지 갈 수 있는 회사가 되는 거죠. 이게 계속 회사가 변하고 기술이 변하고 사람들이 변하지만 그거를 필요할 때마다 사람들을 이렇게 뽑아서 할 수 있는 거는 한계가 있는 거거든요. 계속 사람들을 있는 사람들을 교육해가면서 같이 가는 게 최고인 거죠. 좋아하는 조크 중에 하나가 이런 게 있어요. 회사에 CEO한테 CFO가 와가지고 구박을 해요. “왜 직원들 교육에 돈을 이렇게 많이 쓰냐? 직원들 교육에 이렇게 돈 많이 쓰면 너무 부담된다. 이렇게 열심히 공부시켜 놨는데 나가면 어떡하냐? 사람들이.” 그랬더니 CEO가 반대로 물어봤어요. “공부 하나도 안 시켜서 사람들이 점점 바보가 돼가는데 안 나가면 어떡하냐?” 그러니까 이걸 반대로 생각하면 굉장히 위험한 거예요. 그러니까 공부시켜서 나가는 게 낫지. 공부 안 시켰는데 계속 있으면 아주 위험한 거거든요. 그러니까 회사도 교육에 대한 투자가 “이 사람들을 열심히 공부시켜서 우리 회사에 놔둬야지”가 아니에요. 만약에 모든 회사들이 다 그렇게 생각하면 다 위험한 거죠. 이 NDC 같은 것도 참 좋은 것 같아요. 이렇게 오픈하고 업계 사람들이 다 같이 공부하고 여기 있던 사람들이 예를 들어 넥슨도 오고 넥슨에 있던 사람들이 밖에서도 나가고 서로 성장하고 배우고 그러는 거죠. 적어도 그런 의미에서 Blizzard를 11년 다녔으니까 아 좀 다른데 가서도 저도 성장하고 싶은 거죠. 거기서 11년 동안 일했으니까 같은 일도 좀 오래 한 것 같고 좀 다른 일도 해보고 싶고 또 미국 회사 오래 다녔으니까 한국 회사도 다니고 싶고 여러 가지를 복합적으로 해서 저도 스스로 22년을 일을 했지만 더 성장하고 싶은 마음이 있으니까 한국에 와서 이렇게 넥슨에서 일하면서 정말 많은 걸 배우고 여기 있는 사람들이랑 일하면서 새로운 것도 생각하게 되고 좋은 것 같아요. 그래서 이렇게 성장하는 데는 끝이 없는 거죠. 

그래서 이 성장할 때에 대해서 생각해 볼 수 있는 게 이게 Potential, 어떤 사람의 어느까지 성장할 수 있냐 그 끝과 Capacity 지금 현재 상태, 이 사람이 할 수 있는 어떤 한계라고 할까요? Potential은 그 사람이 할 수 있는 끝 그 두 개라고 볼 수 있는데 이 중요한 거는 사람들이 일을 할 때에는 Capacity의 한참 밑에서 일을 해요. 그러니까 안전하게 일을 하는 거예요. 내가 100m를 20초에 달릴 수 있어도 실제로 달리라고 시키면 한 30초에 달려요. 안전하게. 왜냐하면 20초에 달리면은 위험하거든요. 내 제한 속도기 때문에 가다가 넘어질 수도 있고 다칠 수도 있잖아요. 그래서 사람들이 대부분 안전하게 일을 하고 싶어요. 그런데 문제는 아시다시피 운동을 할 때 아령 같은 걸 들 때 내 몸에 한계에 달하지 않는 아주 가벼운 운동은 아무리 해도 도움이 안 돼요 몸에. 결국 아주 힘든 운동을 해서 근육이 파열되고 그 근육이 파열돼야 근력이 생기는 거거든요. 그러니까 힘든 일을 해야 돼요. 그래서 자기의 Capacity, 내 한계치에 달할 정도의 일을 해서 사실 두 번에 한 번 정도는 실패해 줘야 돼요. 그래야 내 한계치에 있는 거고 그 한계치에서 일을 할 때 이 사람이 성장할 수 있는 거예요. 그래야 계속 Capacity를 넘어서 Potential까지 가는 거죠. 그래서 저는 좀 사람들한테도 어려운 일을 많이 주고 실패하는 걸 권장해요. 근데 그렇게 실패를 했을 때 성장을 하는 거죠. 사람들은 성공해서 배우질 않아요. 항상 실패에서 배우는 거지. 다만 회사의 모든 사람 팀의 모든 사람에 대해서 다 실패하면 Project 망하고 위험하잖아요. 그러니깐 Process에서 관리를 해줘야죠. 그래서 사람들이 빨리 실패할 수 있도록 도와주고 잦은 조그맣게, 작게 자주 실패하게 도와줘야 돼요. 그러면서 사람들이 계속 성장하게 만들고 그 실패들이 있어도 Process들은 잘 갈 수 있도록 만들어줘야죠. 그런 의미에서 사람들이 일을 할 때 Ownership, “이거 내 거다.”라고 가지게 되는 순간 굉장히 위험해져요. Expert, 전문가가 돼야죠. 너는 그걸 정말 잘 하는 사람이 돼야지. “그건 내 거다”라고 하는 순간 위험해지는 거죠. 저희 아버님이 주신 교훈 두 개. 저희 아버님이 주신 교훈이 사실 세 개에요 제가 하나는 세이브해야 내년 NDC에 다시 또 할 거니까 오늘은 두 개까지만 이야기할 겁니다. 그래서 아버님이 주신 두 번째 교훈인데 제가 대학교 졸업할 때쯤 이제 회사 입사 제안을 받았는데 하나는 토목 회사 그렇게 토목 회사에서 건축하는데 거기서 포트란으로 이렇게 땅을 파고 이렇게 철빔을 심는 그런 프로그램을 짜줬어요. 아르바이트로 가서. 무려 포트란으로. 저는 포트란으로 돈을 벌어본 사람입니다. 그래서 굉장히 드문 사람이죠. 그래서 그 포트란으로 몇 만 줄짜리 프로그램을 짜서 계산해서 땅 파는 거 하는데 그 빔 하나가 천만 원 이천만 원 그러거든요. 그러니까 그 빔 하나만 덜 박아도 회사는 돈이 엄청나게 절약이 돼요. 그걸 계산하는 프로그램을 짜달라고 요구를 받아서 짜줬는데 잘 도니까 너무 좋아 갖고 그 사람들이 그걸 다른 회사들한테 팔더라고요. 도리어. 그래가지고 많이 버니깐 “졸업하고 자기 회사 와라. 그럼 아무것도 없는데 전산실 만들어주겠다 심지어. 네가 전산실장해라. 연봉도 엄청나게 많이 주겠다. 그때 뭐 대기업 연봉보다도 더.” 이런 좋은 조건이고 제가 그때 한글과 컴퓨터에서도 아르바이트하고 있었는데 한글과 컴퓨터에서는 막 쟁쟁한 개발자들이 있어요. 지금 NC의 부사장으로 계시는 우원식 부사장님 이런 분들이 코딩하던 시절 옆에서 물 떠다 나르고 “여기 세미콜론 빠졌어요.” 이런 이야기하고 어쨌든 그런 식으로 시다바리로 거의 개발을 하고 있는데 여기서 이러는 거예요. 그런데 한컴에서도 “어? 졸업할 때 됐으니까 우리 회사 와라. 연봉은 이만큼 줄게.” 그러는데 저쪽 토목 회사에서 제시한 연봉은 세 배인 거예요. 저쪽 토목 회사 가면 연봉을 세 배를 주고 아파트 전세 빌릴 수 있도록 회사에서 돈도 빌려준다 그러고 온갖 조건이 다 좋은 거예요. 그래서 이제 고민을 하는데 저희 엉뚱한 아버님이 밤에 자지 말고, 공부하지 말고 자라고 했던 아버님이 오시더니 이렇게 세상에 쉬운 일과 어려운 일 두 개가 있을 때 쉬운 일만 선택하면 계속 쉬운 일만 선택하게 된다는 거예요. 그러면 나중에 선택이 없어진다는 거예요. 어렸을 때는 그게 무슨 말인지 잘 이해가 안 됐었어요. 근데 어쨌든 그때 아버님 말 듣고 생각해보니까 이쪽 토목 회사 가면은 사실 일이 좀 쉬울 것 같기도 하고 내가 전산실장이니깐 대충 하면 될 것 같기도 하고 하여튼 뭔가 좀 도전이 안 되더라고요. 도전. 이 포트란이 절대 마음에 안 들어서 그런 건 아니고 뭔가 도전이 안 돼서 “여기보다는 저기 한컴 가서 그냥 막내로 사람들한테 구박받으면서 좀 성장을 하자. 내가 지금 열심히 뭐 돈 벌 때가 아니고 여기 가서 성장하는 게 낫지 않겠냐? 좀 어려운 길을 선택하자”라고 결정을 했는데 그 이후로 평생을 살아보니까 그렇게 살았던 것 같아요. 저희 아버님의 주신 지론에 따라서 한컴 가서 직장에서 고생하고 좀 회사 먹고 살만 해지니까 미국 가서 일해봐야지 그러고 미국 가서 벤처에 가 가지고 계속 고생하고 그러다가 아 좀 게임 회사를 한 번 가볼까? 그래 갖고 Blizzard 가서 또 열심히 일하다가 한 10년 정도 일해가지고 어느 정도 안정되고 다 좋으니까 아 배부르고 등 따시네? 배부르고 등 따시면 위험하다 좀 더 힘든 대로 가야 되겠다. 쭉 봤더니 넥슨이 좀 제일 도전이 되더라고요. 그래서 여기 와서 좀 재밌는 일을 해봐야 되겠다. 그러고 넥슨을 오게 된 거죠. 사실 저는 이렇게 도리어 쉬운 일, 좋은 길을 찾아다닌 게 아니라 어렵고 힘든 일만 계속 쫓아다녔어요. 그렇게 했으니까 22년을 개발자 생활을 한 거 같아요. 아마 쉬운 일만 했으면 지금쯤 치킨집을 차렸겠죠. 쉽게. 그런데 어려운 일만 하다 보니까 개발자로써도 성장하고 계속 발전할 수 있었던 것 같고 저희 아버님한테 굉장히 이 자리를 빌려서 감사를 드리겠습니다. 여러분들도 이렇게 선택이 있을 때 한 번 어려운 걸 선택해 보세요. 어려운 걸 선택해야 도전이 되는 거고 그러면서 발전이 되는 거죠. 어쨌든 이렇게 성장을 한다는 것 자체가 내 한계치를 깬다는 거라서 내가 할 수 있는 일의 한계를 옆에서 누가 보고 계속 도전을 해줘야 되는 거죠.

그리고 이렇게 일을 잘해도 행복하지 않으면 안 되는 거죠. 그래서 그 사람이 계속 행복하게 일을 잘하는지를 계속 체크해줘야 돼요. 아니나 다를까 시간이 얼마 안 남았는데 이거 큰일 났네요. 이거 다 끝내려면. 그런데 행복을 해야 되는데 행복하기 위해서는 직장을 다니는 이유에 대해서 같이 고민해볼 필요가 있어요. 왜냐하면은 왜 직장을 다니는가? 내가 왜 일을 하는가? 그런 것에 대해서 같이 고민을 해줘야 되거든요. 그거를 팀장이 같이 고민을 해 줘야 되는 거죠. 그래서 저는 보통 회사를 고를 때 일을 할 때 세 가지 질문을 하는데 이 일이 재밌냐? 네가 지금 이 회사에서 일을 하는 게 재밌냐? 그거를 꼭 본인이 확인해야 되고 아침에 출근했는데 아침에 눈 떴는데 회사가 싫으면 민감한 상황이에요. 눈 떠서 회사, 아 빨리 회사 가고 싶어라. 어제 하던 일을 마저 하고 싶어라. 이거 빨리 만들어서 출시하고 싶어라. 이런 마음이 있어야 돼요. 그게 계속 있을 수 있느냐? 저는 있다고 믿어요. 본인이 노력하면은 그 일을 좋아하고 재밌게 즐길 수 있는 거죠. 그러면서 배우고 성장을 해야 돼요. 배우고 성장하지 않으면 그 일을 하는 것 자체가 의미가 없는 거죠. 그리고 마지막에 내가 인생에 이루고 싶은 꿈이 있어요. 목표가 있어요. 그 일을 위해서 이 일이 도움이 되냐? 저 같은 경우에는 그냥 개발만 하면 되는데 왜 이렇게 와서 강연을 하느냐? 물어보는데 사람들이. 저는 지금 22년 일했다 그랬잖아요? 거기서 8년을 더 넥슨에서 일하고 8년 동안 안 잘린다면, 8년 열심히 일해서 잘 버티고 그다음에 30년 딱 채우고 은퇴하고 북한 가서 컴퓨터 학원을 차리는 게 저의 꿈이에요. 그래가지고 북한에 김일성 종합 대학 나온 사람들이 이제 먹고살게 없잖아요. 그 사람들이 열심히 공부할 수 있도록 도와주면서 그리고 전 세계로 보면은 IT가 대한민국이 강하잖아요. 그러니까 대한민국이 잘할 수 있는 거는 IT, 게임, Contents Creation 뭐 이런 거거든요. 어쨌든 북한 가서 컴퓨터 학원 차리는 게 저의 인생의 목표라 와서 이렇게 강연하고 사람들하고 이야기하고 이런 강연을 통해서 제 이름도 알리고 나중에 좀 유명해지면 북한 가서 컴퓨터 학원 차린다 그러면 누가 좀 도와주는 사람이 있을 수도 있고 어찌 됐든 저의 인생의 목표에 대해서 넥슨을 오면 재밌을 것 같고 여기서 또 성장할 수 있을 것 같고 내가 북한 가서 컴퓨터 학원 차리는데 도움이 될 것 같으니까 Blizzard를 그만두고 일로 와야지. 그리고 와서 이렇게 공부하고 일을 하고 강연하고 그러는 거죠. 결국 행복해야 돼요. 제가 행복하니까 이 일을 하는 거죠.

그리고 이런 모든 거를 다 총칭하는 게 사실 Process죠. 어떤 일을 하는 방식이죠. 방금 말했던 Product 관리, People 관리, Technology 관리 이 모든 게 다 Process인 거죠. 그래서 우리 팀 제가 지금 팀장이다. 그럼 우리 팀에 대해서 한 번 생각을 해봐야 돼요. 우리 팀에서 좋은 제품을 만들고 있느냐? 우리 팀에서 좋은 기술을 쓰고 있느냐? 그리고 우리 팀의 사람들이 행복해하고 일을 잘하고 정말 좋아하느냐? 그리고 이걸 관리하는 1:1 면담은 얼마만큼 하냐? 우리가 기술 관리, 코드 Review 같은 걸 하고 있느냐? 제품이 나간다고 제품의 피드백을 제대로 받고 있느냐? 이런 모든 걸 하는 Process가 제대로 돼 있나? 이 네 가지를 다 잘하는지를 평가하는 거죠. 그래서 저는 점수를 매기라 그래요. 1점에서 0점까지 나눠가지고 이 네 개의 다 해서 4점 만점 그러면은 정말 훌륭한 회사지만 그런 회사는 드물죠. 그래서 한 2점 정도만 돼도 훌륭해요 사실. 그런데 1점이다 그러면 좀 심각한 상태죠. 이 넷 중에 한 두 개 정도만 잘해도 괜찮은 회사라고 봅니다. 그래서 Project Lead로써 이렇게 제품을 보고 Technical Lead로써 기술을 보고 그다음에 People Manager로써 사람을 보고 이걸 다 연결시키는 Process를 보고. 이걸 다 하는 게 팀장인 거죠. 물론 이 팀장이 이걸 다 하긴 힘들어요. 그런데 알아야 돼요. 이런 게 있다는 걸 알고 내가 못 하는 걸 남한테 맡겨야 되는 거지 원래 그런 게 있잖아요. 내가 뭘 모르는지 모르는 게 위험하다고. 내가 뭘 모르는지 알아야 남한테 줄 수가 있는데 내가 뭘 모르는지 모르면 아무도 안 해요. 그러면 위험한 거죠. 

그래서 팀 Performance 이걸로 어떤 식으로 팀이 운영되느냐? 우리 팀은 얼마나 일을 잘 하느냐? 그런 거를 다루는 내용이 있는데 결국 그 아까 다섯 가지 이야기했었잖아요. Communication, Technology 그런 이야기했던 것처럼 팀의 Performance 팀이 얼마나 일을 잘하고 있느냐를 평가하는 기준은 저는 한 세 가지 정도로 보는데 소통은 잘 되느냐? 그리고 그 팀이 뭔가 집중해서 시간 관리를 잘 해서 일을 하느냐? 그다음에 실제로 생산성이 있어서 제품을 내느냐? 그래서 얼마나 밖에 제품을 내고 있고 그 안에 시간 효율성이 좋고 의사소통을 잘 하느냐? 이 세 가지로 평가를 하고요.

그리고 Team Dynamics는 이게 팀이 생겼을 때 그 팀이 어떤 식으로 이렇게 흘러가느냐에 대한 이야긴데 처음에는 팀이 많아서 싸우다가 점점 사이가 좋아져서 정말 많은 일을 한다. 뭐 그런 쪽입니다. 아우 이게 앞에 시간하고 엉켜가지고 제가 시간 관리에 실패해가지고 지금 앞에 시간이 끝나버렸네요? 어쨌든 팀 관리에 대한 내용은 사실 찾아보시면 이런 내용 공부하실 수 있으니깐 넘어가도록 할 거고요. 여기서 중요한 거는 내 이야기했듯이 다른 사람들이 모여서 팀을 하는 거거든요. 그렇게 다른 사람들끼리 모여서 팀을 하기 때문에 남이 못하는 거를 내가 도와준다는 개념으로 팀을 운영할 수 있도록 팀장이 신경을 써줘야 되는 거죠.

결국 Team Lead는 제품을 출시하고 좋은 기술을 가지고 사람들을 행복하게 만들고 그런 모든 Process를 다 연결하는 이런 걸 다 해야 되는 사람인 거고요.

그래서 샘플 Q&A까지 만들어 왔었는데 한 번 그냥 쭉 읽어볼까요? 시간 내서 왔는데 질문이 없을까 봐 그래서 질문을 만들어 왔는데 고객이 너무 많아서 질문이 많아요. 그러면 사실 이런 거는 백 로그를 정확하게 정리를 해야죠. “우리가 이런 일을 하겠습니다.”라고 결정을 해야 밖에서 요구 조건이 많아져도 버틸 수 있는 거고요. 그리고 개발자들끼리 맨날 싸워요. 그러면은 뭘 갖고 싸우는지를 봐야 돼요. 이 사람들이 “뭐가 옳으냐? 뭐가 옳으냐? What is right? 뭐가 옳으냐?”가지고 싸우는 거면 괜찮아요. 싸우라고 내버려 둬야 돼요. 근데 만일 그 사람들이 “누가 옳으냐? Who is right?” 이거 가지고 싸우면 안 돼요. 그러니까 “누가 옳으냐?”가지고 싸우면은 당장 싸움을 말려야 되는 거고요 “뭐가 옳으냐?”가지고 싸우면 내버려 두세요. 그거 갖고 싸워서 둘 중에 하나 개발하면 되는 거죠. 그리고 기술 빚이 너무 많습니다. 소스 코드라든지 여러 가지 시스템이 열악합니다 이런 거는 사실 우선순위를 잘 정의해야죠. 그래가지고 기술 부채 같은 거 신경을 많이 써서 개발을 잘하도록 해야 되고요. 그다음에 사람들이 현재 Job이 재미없다고 생각합니다. 그러면은 성장할 수 있도록 도와줘야 되죠. 그리고 지금 하는 일 중에 어려운 일을 찾을 수 있도록 계속 신경을 써줘야 되고요. 그리고 “우리 팀에 코어 엔지니어, 그러니까 핵심 개발자가 있는데 핵심 개발자가 너무 모든 걸 다합니다.”라는 질문이 있으면 사실 이거는 전문가와 Owner 두 개를 구별을 해야죠. 그 일을 가지는 게 아니라 그 일의 전문가가 되도록 해서 다른 사람들에게 나눠 줄 수 있도록 신경을 많이 써야 되겠죠. 일이 너무 많습니다. 일이 너무 많다 그러면은 사실 Direction하고 Speed의 개념인데 방향이 잘 정해져 있고 속도가 난다면은 “지금 이 일을 꼭 그때까지 해야 되냐? 그때까지 안 하면 회사가 망하냐?”라고 물어보면 아닐 수도 있거든요. 그래서 사실 그 이 속도로 저 방향으로 가면은 거기를 도착한다는 보장만 해준다면 사실 경영진은 조금 더 시간을 줄 수도 있어요. 결국 정확한 개발 계획을 보여주면서 시간을 더 많이 받아내 가지고 안정적인 속도로 일정한 속도로 갈 수 있도록 해줘야 되는 거죠. 생산성이 떨어집니다. 그런 거는 사실 안에 낭비가 많거나 사람들의 마인드가 좀 떨어진 걸 수도 있으니까 뭔가 작은 성공, Small Success, 조그마한 Success를 계속하게 해서 사람들의 분위기를 이렇게 끌어올리고 낭비를 없애는 방법이 있고요. 그리고 개발 방법론, Development Process 같은 게 아무것도 없어요. 그러면 처음부터 다시 고민을 해 봐야죠. 지금 쭈욱 늘어놨던 왜 개발하느냐? 무엇을 개발하냐? 어떻게 개발하느냐? Project Leader는 누구냐? Technical Leader는 누구냐? 이런 걸 다 고민해 봐야 되는 겁니다.

그래서 마지막에 이게 Ultimate Question인데요. 제가 좋아하는 책 세 권하고 섞어서 모든 게 다 망가져있다. 방금 그 질문의 끝판왕인 거예요. “이 제품도 망한 제품이고 기술도 엉망진창이고 사람들은 불행하고 그리고 Process도 아예 없다. 도대체 이런 걸 어떻게 살리냐?”라고 물어보면은 사실 그 경우에도 새로 시작하는 거하고 마찬가지니까 할 순 있어요. 그런데 사람마다 방법이 달라요. 얘를 들면은 Stebe Jobs 같은 경우에는 이 네 가지 축이 완전 없는 상태에서 시작한다 그러면은 이 아저씨는 뭐라 그럴까 강한 자기의 비전인 거죠. 그러니까 제품을 하나 보는 거예요 제품. “우리는 세상에서 제일 좋은 제품을 낼 수 있어.” 그리고 Product 하나만 가지고 사람들을 거의 이렇게 정신을 홀리다시피까지 해가지고 그렇게 해서 그쪽으로 딱 끌어오는 거죠. 좋은 제품 만들어야 되니깐 사람들이 막 불타오르고 기술도 어떻게든지 만들어내고 Process가 없어도 막 일하면서 만들어내는. 실제로 제가 일했던 저의 보스 같은 경우에는 원래 게임 회사를 만들고 열심히 PC 게임을 만들고 있었는데 Stebe Jobs가 어느 날 게임회사 사람들을 다 모았데요. 주변 사람들을. 그래가지고 “자기가 매킨토시라는 걸 만들었는데 게임을 더 이상 PC만 만들지 말고 매킨토시도 좀 만들어달라.”라고 하려고 불렀데요. 그래서 아무 생각 없이 룰루랄라 가서 들었는데 Stebe Jobs가 한 세 시간 이렇게 한 30명 모아놓고 막 열변을 토했는데 너무 말을 잘 해가지고 그때 혼이 나가가지고 돌아와서 맥 게임 회사로 바꿔가지고 거의 망할 뻔했죠. 근데 어쨌든 다행히 그렇게 계속 개발을 하면서 맥만 갖고 근근이 먹고살다가 Blizzard가 이제 우리도 맥 용 내고 싶어 그래서 이렇게 포팅을 줬다가 너네 일 잘하네? 그러고 반대로 Blizzard와 합병돼서 마지막 결과는 좋게 끝났는데 어쨌든 Stebe Jobs랑 직접 1:1로 대화하면 안 넘어갈 수가 없데요. 그런데 그 정도의 카리스마가 있으면 이게 다 망가진 상황에서 끌어갈 수가 있죠. Jack Welch 같은 경우에는 유명한 사람이죠. GE, GE의 회장이었는데 여기서 이 사람은 Process만 집중해요. Process. Product건 Technology건 People이건 만들어낼 수 있는 Process를 만들고 Process를 어떻게든지 적용하면서 끌어가는 거예요. 그러면서 할 수 있는 거고 직장 학교는 최근에 봤던 책인데 이렇게 많은 게 무너진 상황에서 어떻게든 공부해서 성장할 수 있느냐? 그런 주젠데 뭐 하여튼 이런 모든 게 망가져 있어도 방법은 있어요. 그러니깐 이 중에서 하나씩 집중하는 거죠. 내가 Process를 잘 하면 Process에 집중하고 내가 People을 잘하면 People에 집중하고 넷 중에 하나를 집중해서 1점을 만드는 걸로 시작하는 거예요. 그리고 나머지 다른 하나의 1점을 만들고 그래서 네 개 중에 한 두 개정도 1점이 되면 그때부터 좀 돌아가기 시작하는 거죠. 그래서 아무것도 없다라고 생각하지 말고 이 넷 중에 나는 어디에 강점이 있나? 그리고 나랑 같이 일하는 사람들은 어디에 강점이 있나? 같이 협력을 해가지고 두세 개씩 살려 나가면은 어떤 힘든 팀이나 Project도 다 살려낼 수 있다고 믿습니다.

그래서 제가 팀을 운영할 때 쓰는 팀훈? 같은 건데요. 항상 저는 저희 팀 사람들한테 1:1 면담하거나 팀에 새로운 사람 뽑을 때 이 세 가지를 강조해요. “행복해라. 그리고 뭔가 회사에 와서 매일 뭔가를 배워라. 그리고 목표를 가지고 살아라.” 그래서 항상 행복한 상태로 뭔가를 배우면서 목표를 가지고 일하다 보면은 그 팀은 당연히 좋은 팀이 될 거고 좋은 제품을 내고 내가 그 팀에서 나와서 다른데 가더라도 또 성장할 수 있고 그렇게 되는 것 같습니다. 여기 오신 분들이 이렇게 늦은 시간까지 오시고 또 제가 시간 조절을 좀 잘못해가지고 마지막에 좀 빨리하기도 하고 또 이런 내용을 좀 너무 두루뭉술한 그런 내용이긴 한데 이런 거를 좀 고민해 보셨을 때 사실 좋은 팀장이 될 수 있고 좋은 관리자가 될 수 있거든요. 그래서 단순히 개발만 하는 게 아니라 이렇게 관리자가 좋은 사람이 돼서 이렇게 사람들을 관리해 주실 수 있는 그래서 한국 IT 업계가 더 좋은 관리자가 많아서 신규 개발자가 많이 생기는 그런 분들이 되시기를 바라겠습니다. 감사합니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
