#acl +All:read

박종천, 개발자로 살아남기

흠... 딱히 뾰족한 내용은 없었던듯.


= 프롤로그: 개발자 30년을 넘어서 =

== 성장하는 개발자 30년을 생각하다 ==

1993년 한컴 -> 블리자드 -> 넥슨 -> 삼성전자 무선사업부 -> 몰로코

저는 코딩에만 집중하는 '100세 코딩'보다는 성장하는 '30년 커리어패스'를 개발자님께 제안드립니다.

 * 처음 10년은 실력을 쌓으며 성장하는 시기
 * 다음 10년은 다른 개발자를 리딩하며 일하는 시기
 * 마지막 10년은 한발 물러서서 사람들을 돕고 서포트하는 시기입니다.

마지막 10년에는 선택의 폭이 넓습니다. 예를 들어 기술 리더십을 사업 리더십까지 확장해서 디렉터, VP, CTO 같은 임원이 될 수도 있겠지요.

== 실리콘밸리의 커리어패스로 알아보는 개발 30년 ==

실리콘밸리 대부분의 회사는 개발자를 아래와 같이 구분합니다.

 * 성장하는 10년
   * 어시스턴트 개발자
   * 어소시에이트 개발자
   * 미드 레벨 개발자
 * 리딩하면서 일하는 10년
   * 시니어 개발자
   * 리드 개발자
   * 프린시펄 개발자
 * 서포트하는 10년 (경영과 사업의 10년)
   * 디렉터
   * VP of Engineering
   * CTO

블리자드에서는 시니어 이후 레벨의 개발자를 리드 개발자, 프린시펄 개발자라고 불렀습니다.

리드 개발자가 되려면 미지의 영역을 해결하는 능력이 필요합니다. 블리자드에서는 아는 일을 잘하는 능력보다 모르는 일도 분석해서 끝까지 처리하는 능력, 그래서 새로운 프로젝트를 맡을 수 있는 능력이 있어야 리드 개발자로 승진합니다. 리드 개발자 승진 평가에는 심지어 다른 팀의 디렉터들까지 참여합니다. 회사 전체에 영향력이 퍼져 있을 정도로 많은 일을 하고 있어야지만 리드 개발자가 되는 것이죠.

반면에 프린시펄 소프트웨어 개발자는 진정한 구루여야 합니다. 프로젝트의 개발을 리딩한다기보다는 정말 깊게 기술을 연구해서 회사에서 인정받는 기술 전문가여야 합니다.

그 다음은 디렉터입니다. 경력 20년이 넘어가는 위치입니다. 이제부터는 책임의 영역입니다. 저는 농담으로 디렉터를 정의하며 이런 표현을 씁니다. "모든 일을 할 수는 있지만 아무 일도 하지 않고 대신 모든 일에 책임지는 사람"이라고요. 단순히 일을 하는 사람이 아닙니다. 책임질 줄 알아야 하는 사람입니다. 그러려면 모든 것을 파악하고 옳은 결정을 빠르게 내릴 수 있어야 합니다.

디렉터 위로는 VP of Engineering이나 CTO가 있습니다. 이 둘은 사실상 경영과 사업 영역에 속합니다. 개발과 기술을 기반으로 사업에 기여하는 모든 일을 책임집니다. 당연히 개발은 개발자들이 하는 것이므로 좋은 개발자들의 채용과 교육 그리고 개발 문화까지도 챙겨야 하며, 개발 프로세스도 잘 정립해야 합니다.

30년 커리어패스 9가지 기술

 * 엔지니어링 역량
   * 개발에 대한 기본 지식
   * 제품에 대한 이해
   * 개발 주기 지식
 * 매니지먼트 역량
   * 프로젝트 관리
   * 팀 관리
   * 프로세스 관리
 * 비즈니스 역량
   * 인사 시스템
   * 사업 관리
   * 비전과 조직 문화

= Part 1. 엔지니어링 역량 =

== 01. 개발자의 소양 ==

== 02. 고객이 원하는 제품 디자인 ==

== 03. 30년간 실천할 개발 주기 ==


= Part 2. 매니지먼트 역랑 =

== 04. 성공을 이끄는 프로젝트 리드 ==

== 05. 기술 주도 테크니컬 리드 ==

== 06. 행복을 만드는 피플 매니저 ==

== 07. 프로세스 바로 세우기 ==


= Part 3. 비즈니스 역량 =

== 08. 잘 뽑고 잘 들어가기 ==

한 연구 결과에 따르면 잘못된 사람을 채용하면 그 사람 연봉의 2.5배에 해당하는 금액만큼 손해가 발생한다고 합니다. 그래서 오늘날 채용 제도는 좋은 사람을 뽑는데 집중하기보다는 잘못된 사람을 뽑지 않는데 더 집중합니다. ... 채용의 제 1원칙으로 '잘못된 사람을 뽑지 않는다'를 제안합니다.

1원칙을 만족하는 인재를 뽑을 때 세 가지 기준을 고려하면 됩니다. 첫번째는 우리의 '목표', 두번째는 목표를 달성하는 우리의 '원칙', 세번째는 사람을 채용하는 '프로세스'입니다.

목표는 피고용자의 능력과 인성 검증에 초점이 맞추어 있습니다. 원칙은 채용 기준을 정해줍니다. 프로세스는 채용의 품질을 보장한느 보호 도구입니다. 채용은 양방향 평가의 결과물입니다. ... 채용을 할 때 목표와 원칙 뿐 아니라 채용 프로세스도 무시할 수 없습니다.

=== 채용 목표 바로 세우기 ===

회사의 채용 목표를 단순하게 '좋은 사람 채용'으로만 정의할 수는 없습니다. 더 디테일하게 우리가 원하는 인재상을 정의하고 채용을 진행해야 합니다. 채용 목표는 '현재 조직 문화와 잘 맞는가', '업무를 진행할 전반적인 능력이 있는가'로 시작해야 합니다. 이 둘은 필수 요구사항입니다.

다양한 채용 목표가 있겠지만 그중에서도 가장 중점을 둘 사안이 무엇인지를 정해둬야 합니다. ... 이렇게 정확한 채용 목표를 세우면 원하는 것과 놓칠 수 있는 것을 미리 정의해둘 수 있습니다. 물론 채용과 관련된 사람 모두가 채용 목표에 동의해야 합니다.

=== 채용 목표를 만족하는 원칙 세우기 ===

=== 생물 같은 채용 프로세스 운용하기 ===

요즘은 웹사이트에서 코딩 테스트를 진행합니다만, 제가 블리자드에 있을 때만 해도 이메일로 과제를 줬습니다. 집에서 혼자 하는 과제를 내주고 프로그래밍해서 보내게 했습니다. 오픈북 시험과 비슷합니다. 이런 메일 인 테스트(mail-in test)는 유효합니다.

블리자드에서는 조금 아날로그 스타일로, 코드에 집중해 옛날 방식으로 코딩 테스트를 진행했습니다. '텍스트로 게임을 만들어라', '코드 500줄짜리 간단한 게임을 만들라' 같은 과제를 주었습니다. ... 그러면 면접관은 제품의 안정성, 코드가 읽기 편하게 잘 짜여 있는지, 버그 없이 잘 작동하는지, 해당 프로그래밍 언어를 잘 활용했는지, 구조를 잘 짰는지, 미래에 다른 기능을 추가할 수 있는지 등을 고려하며 소스 코드를 살펴봅니다. 소스 코드 리뷰도 팀장 세명 정도가 진행합니다.


데이 제로(day zero) 인터뷰라고도 부릅니다. 인 퍼슨 테스트(in-person test)는 블리자드에서 진행한 굉장히 독특한 문화입니다. 입사를 했다고 가정하고 지원자 3명을 불러서 게임을 만들게 하는겁니다. 그리고 게임을 개발하는 과정을 지켜봅니다.

보통은 지원자 3명을 모아 테스트를 하는데, 지원자가 부족할 때는 직원 중 한 명이나 두 명을 넣어서 진행합니다. 직원도 테스트에 참여하면 지원자처럼 행동합니다.

-

지금까지 면접관과 지원자 입장에서의 채용을 알아보았습니다. 그런데 우리는 왜 일을 하는걸까요? 한글과컴퓨터에서 일하던 사회 초년 시절에는 돈을 벌기 위해서 일을 하거나, 옳은 일이라서 하거나, 좋아하는 사람들과의 관계 때문에 일을 했습니다. 그런데 30년 커리어패스를 밟고 보니 다른 이유가 더 좋겠습니다. 1) 일이 재밌어서 2) 일에서 성장을 할 수 있어서 3) 인생의 목표와 현재의 일이 연결되어서.


== 09. 돈 되는 사업 만들기 ==

일반적인 스타트업들의 흐름을 한 번 살펴보겠습니다. 좋은 아이디어를 기반으로 소수가 의기투합해서 시작합니다. 초기 투자를 받고 최대한 빠른 시일 내에 최소기능제품을 만듭니다. 이제 본격적으로 투자를 받고 사람을 모집합니다. 이때 정말 좋은 사람을 채용해야 합니다. 직원 100명일 때도 직원이 10,000명일 때를 생각하며 최고의 인재만을 채용하세요. 그 사람들이 결국 조직을 키워서 10,000명의 미래 조직으로 성장할 수 있습니다. 특히나 스타트업은 사람이 적기 때문에 한 사람 한 사람이 더욱 중요합니다.



== 10. 비전을 공유하는 조직 문화 만들기 ==

= Part 4. 개발자로 살아남기 30년 =

== 11. 시간 관리 비법 ==

== 12. 30년 커리어패스에서 배운 것 ==



----
CategoryBook