[컴퓨터/IT] 박종천, 『개발자로 살아남기』

개발자에겐 두가지 길이 있다. 죽을때까지 코딩만 하거나, 관리자가 되거나. 

이 책은 관리자의 길을 원하는 개발자들을 위한 책이다.

 

저자는 성장하는 10년, 리드하는 10년, 서포트하는 10년으로 이루어진 30년 개발자 커리어패스를 제시한다.

개발자로서의 역량을 키우고, 남들을 이끌며, 인사이트를 키워서 꼭대기에 있는 관리자까지 도달하는 방법에 대해 말해준다.

 

신입 개발자로 입사를 앞둔 시점에서 이 책을 만나서 참 다행이다라는 생각이 든다.

이 책을 읽고 개발자로서 목표를 정했기 때문이다. (일단 단기적인 목표)

 

책에서는 성장하는 단계를 10년정도라고 정해두었는데, 이 시간을 단축시킬 수 있는 방법이 있다.

바로 지식과 숙련도와 경험을 쌓아서 역량을 키우는 것이다. 

지식은 공부를 통해, 숙련도는 반복을 통해, 경험은 직접 경험해보거나 다른 사람들의 간접 경험을 흡수하여 키울 수 있다. 

 

나는 매일 공부하고, 부족한 부분은 연습하고, 다양한 문제를 해결하고, 다른 사람들의 간접 경험을 흡수하여 빠르게 성장해나기로 다짐했다.

그래서 1년만에 나의 첫 직장에서 일어나는 모든 일을 해결할 수 있고, 일을 알아서 할 수 있는 '슈퍼' 주니어 개발자가 될 것이다. 

일단 목표는 그렇게 정했다 🫵

---

책 내용 요약

프롤로그

개발자 30년을 넘어서

• 1993년 한글과컴퓨터에서 ‘아래아한글’을 만들며 개발자 생활을 시작했습니다. 이후 미국에서 스타트업 두 곳을 거쳐 블리자드에서 일했습니다. 블리자드 최초의 모바일 게임인 <하스스톤>을 만들고 나서 귀국 후 넥슨에서 모바일 플랫폼과 PC 플랫폼 등을 개발했고, 삼성전자 무선사업부에서 인공지능을 이용한 광고 플랫폼을 만들었습니다. 지금은 실리콘밸리에 본사를 둔 몰로코라는 유니콘에서 헤드 오브 솔루션 아키텍처로 활동합니다.
• 개발자가 성장하는 시간을 세단계로 구분하고 각 단계마다 필요한 역량을 세가지씩 추렸습니다.
• 저처럼 30년을 혹은 그 이상을 개발자로 살고 싶은 분께 조금이나마 도움이 되었으면 하는 마음으로 제 경험을 풀어놓을 겁니다.

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

• 저는 코딩에만 집중하는 ‘100세 코딩’보다는 성장하는 ‘30년 커리어 패스’를 개발자께 제안드립니다. 처음 10년은 실력을 쌓으며 성장하는 시기, 다음 10년은 다른 개발자를 리딩하는 시기, 마지막 10년은 한 발 물러서서 다른 사람들을 돕고 서포트하는 시기입니다.
• 마지막 10년에는 선택의 폭이 넓습니다. 예를 들어 기술리더십을 사업리더십까지 확장해서 디렉터, VP, CTO 같은 임원이 될 수도 있겠지요.

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

• 실리콘밸리 대부분 회사는 개발자를 어시스턴트 개발자, 어소시에트 개발자, 미드레벨 개발자, 시니어 개발자, 리드 개발자, 프린시펄 개발자, 디렉터, VP, CTO로 구분합니다.
  • 어시스턴트 개발자를 흔히 주니어라고 부릅니다. 농담 반 진담 반으로 ‘대학 졸업 후 막 입사한 어시스턴트 개발자는 회사에서 숨만 쉬어도 된다’라고 말하곤 했습니다. 그때는 정말로 배워야 하는 시기니까요.
  • 어시스턴트 개발자로 1~2년을 지내면 어소시에트 개발자가 됩니다. 어소시에트 개발자는 시키는 일을 잘 하는게 중요합니다.
  • 다시 3~4년이 지나면 미드레벨 개발자, 그야말로 그냥 ‘개발자’가 됩니다. 이때부터는 본인이 알아서 일을 잘해내야 합니다. 일을 찾아서 하는 시기입니다.
  • 경력 10년차 쯤 되면 시니어 개발자입니다. 이때는 혼자서만 잘한다고 끝이 아닙니다. 일을 크게 만들 줄을 알아야 하고요, 다른 사람을 이끌며 일할 줄 알아야 합니다. 프로젝트를 리드하고 기술을 결정하며 점점 더 큰 일을 더 많이 하게 되는 거죠.
  • 리드 개발자가 되려면 미지의 영역을 해결할 수 있는 능력이 필요합니다. 모르는 일도 분석해서 끝까지 처리하는 능력, 그래서 새로운 프로젝트를 맡을 수 있는 능력이 있어야 리드 개발자로 승진합니다.
  • 프린시펄 소프트웨어 개발자는 진정한 구루여야 합니다. 프로젝트의 개발을 리딩한다기 보다는 정말 깊게 기술을 연구해서 회사에서 인정받는 기술 전문가이어야 합니다.
  • 그다음은 디렉터입니다. 경력 20년이 넘어가는 위치입니다. 모든 일을 할 수는 있지만 아무 일도 하지 않고 대신 모든 일에 책임지는 사람. 모든 것을 파악하고 옳은 결정을 빠르게 내릴 수 있어야 합니다.
  • 디렉터 위로는 VP of 엔지니어링이나 CTO가 있습니다. 이 둘은 사실상 경영과 사업 영역에 속합니다. 좋은 개발자들의 채용과 교육 그리고 개발 문화까지도 챙겨야 하며, 개발 프로세스도 잘 정립해야 합니다.
• 다음 단계로 성장하려면 10년을 꼬박 채워야 할까요? 그렇지 않습니다. 10년보다 중요한건 성장입니다. 그런데 성장은 무엇일까요? ‘성장’은 역량이 늘어난다는 뜻입니다.
  사람의 역량이란 무엇일까요? 첫번째는 지식, 두번째는 숙련도, 마지막은 경험입니다.
  • 첫번째 지식은 공부를 해야 쌓입니다. 지식을 쌓는 것은 혼자서 하는 영역입니다.
  • 두번째 숙련도는 같은 일을 여러번 오래 반복해야 쌓을 수 있습니다. 얼마나 열심히 하냐에 따라 공부와 숙련에 드는 시간이 짧아질 수 있습니다.
  • 반면 경험을 쌓는 데 드는 시간은 단축하기 어렵습니다. 경험은 성공과 실패를 해봐야 하고, 이런 사람 저런 사람도 만나봐야 합니다. 다행인 것은 강연이나 책으로 다른 사람의 경험을 간접적으로 습득하면 시간을 줄일 수 있습니다.
  • 항상 지식과 숙련도를 고민하고, 특히 간접경험을 적극적으로 받아들여 경험을 쌓으면 앞서 언급한 커리어패스를 더 빠르게 밟아 나아갈 수 있습니다.
  • 기억하세요. 지식, 숙련도, 경험.

30년간 개발자가 갖춰야 할 9가지 기술

• 각 10년, 도합 30년동안 개발자가 갖춰야 할 9가지 기술을 알아봅시다. 크게 세 분야로 나눌 수 있습니다. 엔지니어링 역량, 매니지먼트 역량, 비즈니스 역량입니다.
  • 엔지니어링 역량에는 개발에 대한 기본 지식, 제품에 대한 이해, 개발주기 지식이 필요합니다.
  • 매니지먼트 역량에는 프로젝트, 팀, 프로세스 관리 기술이 필요합니다.
  • 비즈니스 역량에는 인사시스템, 사업 관리, 비전과 조직 문화에 대한 이해와 관리 기술이 필요합니다.

---

PART1 엔지니어링 역량

개발에 대한 기본 지식

• 엔지니어링 역량에서 기본 개발 지식이 1순위입니다.
• 차에 엔진이 있다는 사실과 핸들로 바퀴를 조정하는 방법 정도는 알아야 운전을 잘할 수 있듯이 개발도 마찬가지입니다. 하드웨어, 운영체제, 자료구조와 알고리즘, 데이터베이스와 네트워킹, 그리고 개발 도구를 어느정도는 알아야 적절한 프로그래밍 언어로 개발할 수 있습니다.
• 기본 개발 지식을 익히는 제일 좋은 방법은 책입니다. 위에서 언급한 주제별로 최소 한권씩을 읽어보시기 바랍니다. 그러고 나서 직접 해보세요. 컴퓨터를 분해하거나, 운영체제 구석구석 설정을 살펴보거나, 자료구조와 알고리즘을 직접 만들어보세요.
• 책을 읽고 공부를 했으면 꼭 직접 해봐야 내 것이 됩니다. 무엇보다도 해봐야 벽에 부딪치고 질문이 생깁니다. 좋은 답변은 좋은 질문에서 나옵니다. 전문가를 만나서 책에서 배운 내용과 직접 해보며 겪은 어려움을 이야기하면 나의 역량도 올라갑니다.

제품에 대한 이해

• 현업에서 개발할 때는 구현 대상인 제품을 제대로 파악해야 합니다.
• 정해진 스펙대로만 개발만 하는게 아니라 사용자 입장에서 제품을 생각하고 아이디어를 보태야 합니다.
• 자신이 만든 제품을 직접 써보면서 더 좋은 제품을 만들고자 하는 욕구가 있어야 더 좋은 개발자로 발전합니다.

개발 주기 지식

• 사람에게 수명 주기가 있듯이 제품 개발에도 개발 주기가 있습니다.
• 개발 주기는 5단계입니다. (1) 요구사항 분석하기, (2) 시스템 구조 설계하기, (3) 구현하기, (4) 테스트하고 출시하기, (5) 피드백을 모아서 업데이트하기 입니다.

---

01 개발자의 소양

소프트웨어 개발자가 뭐지?

• 우리나라 미래는 기술과 창조, 이 두가지 힘에 달렸습니다. 모든 서비스와 콘텐츠 뒤에는 기술이 있고, 기술과 콘텐츠가 합쳐져 세계적인 성과를 만듭니다.
• 소프트웨어는 컴퓨터 안에서 돌아가는 단순한 로직의 집합체가 아닙니다. 소프트웨어는 과학, 기술, 엔제니어링, 수학이 잘 융합된 STEM의 결정체입니다. 개발자는 STEM의 결정체인 소프트웨어를 만드는 사람이며, 기획자나 프로젝트 매니저, QA 등 다른 직군의 사람들과 창의적으로 협업하여 사용자에게 가치를 제공하는 사람입니다.

폴리글랏 시대의 개발자 직군 엿보기

• 세상이 빠르게 변하므로 개발자는 유행보다는 기본 지식을 쌓는 데 투자해야 합니다.
• IT 인생 30년 내내 줄곧 쓰는 언어는 없습니다. 프로그래밍 언어는 유행을 따르는 도구일 뿐입니다. 그래서 빠르게 새로운 걸 터득하는 능력과 기반 지식이 중요합니다.

개발에 대한 기본 지식이 뭐지?

• 개발자의 기본은 영어입니다. 그 다음은 수학과 물리입니다.
• ‘나는 웹 개발자니까 하드웨어는 몰라도 돼’, ‘나는 운영체제는 몰라도 돼’ 이런 자세는 안됩니다. 만든 프로그램을 쌩쌩 돌게 하려면 하드웨어를 알아야 합니다.
• 기본 지식을 안다고 제로 베이스부터 모든 걸 직접 만들어 쓰는 게 아닙니다. 하지만 모든 소프트웨어는 기본 위에서 작동합니다. 기본을 알면 아키텍쳐가 달라집니다.
• 정렬, 스택, 힙, 스레드, 네이티브 코드, MVC 모델 등 표에 언급된 내용을 공부해보세요. 이 정도는 알아야 소프트웨어 기본 지식을 갖췄다고 할 수 있습니다.

크리티컬 싱킹하라

• 크리티컬 싱킹은 주어진 일의 앞뒤를 생각하는 습관입니다. ’왜 이 일을 해야 될까?’, ‘이 일을 하다가 말면 어떻게 될까?’, ‘어떤 방식으로 일하는 게 최선일까?’ 문제의 상하좌우까지 고민하는 사고 방식을 습관으로 들이면 모든 일을 더 깊이 들여다볼 수 있습니다. 크리티컬 싱킹 습관이 들어 있으면 그 사람이 감당하는 업무 스케일이 계속 커지게 됩니다.
• 소프트웨어를 개발하면서 왜, 어떻게, 무엇을, 누가, 언제까지 출시해야 하는지를 종합적으로 고려해야 합니다. 크리티컬 싱킹은 종합적인 관점에서 해법을 구하는 습관입니다.
• 회사의 주인의식을 가질 필요는 없습니다. 대신 나의 주인의식을 가져보세요. ’그냥 시킨 것만 했어요’라고 대답하지 않으려면 나에 대한 주인의식, 즉 크리티컬 싱킹이 필요합니다.

도구를 사랑하지 마라

• 특정 언어나 도구와 사랑에 빠지면 안됩니다. 사랑에 빠지면 최적의 언어와 도구를 선택하지 못합니다. 개발자의 도구는 역할과 프로젝트마다 달라져야 합니다.
• 현업에 바쁘더라도 6개월 주기로 새로운 기술과 도구를 확인하고 공부하는 기간을 갖길 바랍니다.
• 그저 시키는 대로 사장될 기술을 사용한다면 모두에게 불행을 가져다 줄 것입니다. 그렇다고 모든 개발에 신규 기술만 고집할 필요는 없습니다. 향후 5년 이상 유지할 서비스라면 최대한 미래를 고려해 선택하고, 1년 미만 혹은 유지보수 정도 목적에는 기존 기술을 쓰면 됩니다.

π자형 인재되기

• 한 가지를 깊게 파서 잘하는 I자형 인재가 각광받던 시절이 있었습니다. 변화가 빠른 지금은 적어도 하나는 깊게, 나머지는 골고루 아는 T자형 인재가 각광받고 있습니다. T자를 넘어 요즘에는 π자형 인재라는 말도 나왔습니다. 하나가 아니라 두가지에서 전문성이 있어야 한다는 이야깁니다.
• 시작은 I자형 인재입니다. T자형을 거쳐 π자형 인재로 차근차근 나아가면 됩니다. π자형 인재가 되려면 눈물나게 노력해야 합니다.

마무리

• 끊임없이 공부하고 성장을 추구하고, 계속 넓은 세상을 보려고 노력했습니다. 또 제가 하는 일만 아니라 다른 세상이 어떻게 돌아가는지도 봐왔습니다. 많은 사람을 만나고, 많은 책을 읽었습니다. 이 책을 쓰는 이유도 제가 공부하고 성장하기 위해서입니다.
• 여러분도 항상 이 말을 기억했으면 좋겠습니다. ”세상은 배우는 자와 배우지 않는 자로 나뉜다.” 많은 것을 보고 공부하고, 좋은 책을 보고, 좋은 사람을 만나서 끊임없이 성장하는 것만이 개발 업계에서 살아남을 수 있는 비결입니다. 동시에 굉장히 재미있게 생활하는 길입니다.

---

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

• 좋은 제품을 디자인하려면 누가 사용하나, 사용자가 원하는 일은 무엇인가, 만드는 제품이 사용자가 원하는 바를 제공해주는가, 경쟁 제품은 어떤 접근을 하는가 등을 고려해야 합니다.
• 사용자 경험(UX)이 특정 제품 안에 국한되는 경험이라면 고객 경험(CX)은 탐색, 구매, 사용, 사용 후 평가까지 모든 접점에서의 경험입니다.
• 프로그램에서 오류가 나타났을 때 사용자 경험을 제공하는 방법은 총 3가지입니다. 첫번째는 사용자에게 알리지 않고 알아서 문제를 해결하는 경우입니다. 두번째는 사용자에게 해결책을 알려주어 사용자가 실행하는 경우입니다. 세번째는 아무것도 할 수 없는 경우입니다.

경쟁 제품 분석

• 참고로 마이크로소프트의 초기 전략은 ‘Embrace and Extend’, 즉 ‘흡수하고 확대하라’였습니다. 천하의 마이크로 소프트도 경쟁 제품을 참고해 성장한 겁니다.

고객 여정

• 제품을 만들 때 고객과 우리 제품 사이의 모든 여정이 설계되어 있어야 합니다. 고객 여정으로는 인식, 고려, 결정, 유지 단계가 기본입니다. 설계대로 여정이 진행되는지를 데이터를 기반으로 모니터링하고, 그 결과를 기반으로 개선해야 합니다.
• 제품 기획과 개발 단계에서 고객 여정을 설정하고 미리 시뮬레이션해야 하며, 각 과정은 숫자로 정의되어야 합니다.

A/B 테스트

• A/B 테스트란 새로운 기능을 추가하거나 바꾸고 싶을 때 전체 사용자 중 일부에게는 기존 기능을, 나머지에게는 새로운 기능을 제공하여 그 결과를 비교하는 방법입니다.
• 이 방법은 최소기능제품(MVP, Minimum Viable Product)의 시대에도 딱 들어맞습니다. 최소한의 기능을 좋은 품질로 만들어서 빠르게 시장을 내고 계속 시장 반응을 보면서 업데이트 하는 개발 방법입니다. 사용자에게 선택권을 주어 사용자가 좋아하고 성공하는 방향으로 기능을 추가하는 거죠.
• 제품 기획자가 한 달을 끙끙대며 최대한 사용자의 생각을 예측하는 것보다 그 시간에 기능을 개발해서일부 사용자들에게 배포하고 반응을 살피는 것이 더 확실한 방법입니다.

데이터 주도 개발

• 데이터 주도 개발이란 제품 추시 이후에도 지속해서 데이터를 모아 모든 과정에 데이터를 사용하는 겁니다.
• 개발을 위해 수집하는 데이터를 로그데이터라고도 부릅니다. 로그데이터를 너무 과도하게 수집하면 성능이 느려지거나 프로그램이 이상 종료하거나 서버에 접속하지 못하는 문제가 발생할 수도 있습니다. 따라서 성능과 충분한 데이터 사이에 균형을 맞추어야 합니다.
• 데이터 수집 시스템 설계는 총 3단계로 나눌 수 있습니다.
  • 첫번째는 데이터 설계 단계입니다. 어떤 데이터를 어디에서 수집하는지, 왜 수집하는지, 그 데이터를 어떻게 사용할지를 계획해야 합니다.
  • 두번째는 데이터를 수집하는 시스템 설계 단계입니다. 어디서 데이터를 수집할지 정해야 합니다.
  • 세번째는 모은 데이터를 정리하고 활용하는 단계입니다. 여러 솔루션을 이용해 자동으로 정리하고, 정리된 결과를 보여줄 대시보드를 만들어서 개발자나 운영자가 활용하게 해야합니다.
• 피터 드러커는 “측정할 수 없으면 관리할 수 없고, 관리할 수 없으면 개선할 수도 없다”고 말했습니다.
• 우리가 제품에 주는 모든 편화는 꼭 측정이 가능해야 하며, 지속적인 변화만이 최고의 제품을 만들 수 있습니다.

개발자 자세, 30년동안 도그푸딩 실천하기

• 도그푸딩이란 ‘내가 만든 개밥을 스스로 먹어라’라는 말에서 유례했습니다.
• 식당에는 세가지 종류가 있습니다.
  • 첫번째는 돈을 벌려고 하는 식당입니다. 두번째는 손님들에게 맛있는 음식을 대접하는 행위를 좋아해서 하는 식당입니다. 세번째는 요리하는 행위 자체를 좋아해서 하는 식당입니다.
  • 돈만 목표로 해서는 적당한 성공을 얻을 수 있으나 큰 성공을 얻기는 어렵습니다.
• 내가 먼저 제품을 써보고 좋아해야 사용자도 좋아하게 되는겁니다.

마무리

• 개발은 좋은 제품 만들기가 목적입니다. 멋진 코드와 확장성 있는 아키텍쳐도 좋지만 기술은 좋은 제품을 만들어내야 의미가 있습니다. 그래서 개발자도 제품에 대한 이해력을 키워야 합니다.

---

03 30년간 실천할 개발주기

• 개발은 복잡하고 어려운 과정을 극복하는 과정입니다. 충분한 시간을 들여 사전 검토 후 단계별로 결과를 점검하며 진행해야 합니다.
• 개발 프로세스는 일반적으로 분석, 기획, 개발, 테스트, 출시, 피드백, 마지막으로 피드백 반영까지를 순환합니다.
• 하지만 개발 전에 요구사항을 제대로 분석했는지, 기획은 제대로 되었는지, 아키텍쳐는 잘 잡았는지 확인해야 합니다.
• 개발 과정에서 테스트를 충분히 진행해 품질을 끌어올리고, 출시 후 모든 지표를 살펴볼 수 있도록 측정 도구를 준비해야 합니다.

30년간 실천할 개발 주기 알아보기

• 애자일은 무계획/무관리 개발과 지나친 계획/관리 개발 사이에서의 타협점입니다. 품질을 놓치지 않으면서도 기민한 개발을 지향합니다.
• 애자일은 굉장히 작은 기능, 즉 최소한의 기능으로 최대한 빠르게 개발하는 방법입니다.

개발 문화를 변화시킨 애자일

• 애자일을 실천하는 데 유용한 프로젝트 관리 방법으로 스크럼이나 칸반이 있죠.
• 스크럼은 소규모 팀으로 제품을 기민하게 개발하는 방법으로 스프린트라는 업무 주기를 반복합니다.
• 스크럼이 시간을 제한하는 방법론인 반면 칸반은 수를 제한하는 방법입니다. 쉽게 말해 칸반은 칠판에 ‘할 일’, ‘진행 중인 일’, ‘완료된 일’ 열을 만들고, 그 밑에 중요도에 따라 색이 다른 업무를 포스트잇으로 붙여서 관리하는 개발 방식입니다.
• 프로젝트 관리 도구로는 지라를 주로 씁니다. 협업 문서 관리 도구는 컨플루언스에서 노션으로 옮겨지는 추세입니다.
• 애자일의 꽃은 회고입니다. 매달 또는 분기에 한 번 정도 정기적으로 현재 조직, 기술, 제품, 프로세스에 대해서 논의해보고, 문제점이 발견되었을 때 개선 방안을 깊게 살펴보는 과정이 회고입니다. 지속적으로 조직, 기술, 제품, 프로세스 등 모든 것이 개선되도록 노력하는 최고의 도구가 회고인거죠.

---

PART2 매니지먼트 역량

• 30년 커리어패스의 두번째 10년에 필요한 매니지먼트 역량은 총 3가지입니다. 프로젝트 관리, 팀 관리, 프로세스 관리.

매니지먼트 역할

• 첫번째 프로젝트 관리는 출시 시기와 중점을 둬야하는 일을 관리하는 기술입니다. 두번째는 팀 관리, 즉 사람관리 입니다. 세번째로 프로세스 관리입니다.
• 주니어 개발자로 입사하면 처음에는 주어진 일을 하며, 개발 바업과 개발 주기를 배웁니다. 연차가 높아질수록 프로젝트를 관리하는 방법, 직원을 관리하는 방법, 좋은 프로세스를 설정하는 방법을 고민하며 성장합니다. 이 단계를 거쳐야 좋은 시니어 개발자가 되거나 좋은 개발 팀장이 될 수 있습니다.

프로젝트 관리

• 프로젝트 관리는 기본적으로 비용(리소스/인력), 시간(출시일), 제품 범위(기능) 세가지를 관리하는 겁니다.

팀관리

• 팀을 포밍하면 스토밍, 즉 폭풍처럼 마구 싸웁니다. 그러고 나면 잔잔해지고 사람들이 친해집니다. 마지막은 퍼포밍, 즉 질을 잘하게 되는 단계로 진입힙니다.
• 팀의 존재 이유는 서로의 장점을 공유해서 극대화하고 약점을 보완해주는 것이므로, 서로가 강점과 약점을 알아야 합니다. 특히, 약점을 공격하는데 사용하면 안됩니다. 약점은 당사자를 보호하고 팀워크를 유지하는 데 사용해야 합니다 .

프로세스 관리

• 프로세스란 결국 일을 하는 과정을 정리하는 겁니다. 한번 했던 일을 다시 잘 할 때 잘하기 위한 장치가 프로세스입니다. 프로세스를 만들면 규격화해 측정할 수 있게 됩니다. 두세 번 반복하면 최적화 할 수 있습니다.
• 프로세스 관리는 실패를 막고, 우연을 막고, 철저하게 품질을 관리하고, 최적화하는 과정을 만드는 겁니다. 개발 주기, 코드 리뷰 등 개발과 관련된 모든 것이 프로세스에 해당합니다. 프로세스가 정립되어야지만 회사의 현 상태를 측정하고, 고도로 최적화할 수 있습니다.

매니지먼트 5가지 기본 소프트 스킬

• 훌륭한 개발자는 절대 엔지니어링 역량만 가지고는 될 수 없습니다. 매니지먼트 역량이 꼭 필요하고 이 매니지먼트 역량의 바탕은 바로 소프트 스킬입니다.
• 소프트 스킬 중에서도 제일 기본인 다섯 가지 기술을 알아보겠습니다.
  • 첫째 소통입니다. 둘째 협업입니다. 셋째 긍정적인 자세입니다. 넷째 프로의식입니다. 마지막은 리더십입니다.

소통과 리더십

• 소통에는 투명성과 개방성, 리더십에는 인사이트가 중요합니다.
• 투명서은 사람들이 알아야 할 정보를 충분히 공급해주는 걸 말합니다. 투명성이 보장되려면 업무에 필요한 중요 정보에 모두가 쉽게 접근할 수 있어야 합니다. 서로가 항상 사실을 말해야 합니다. 이렇게 투명성과 예측가능성이 확보되면 직원에게 자율성이 생깁니다.
• 아울러 리더라면 개방성을 가지고 남의 말을 경청하는 사람이 되어야 합니다. 즉, 투명하게 모든 정보를 공유하고, 개방적인 자세로 다른 사람의 말을 잘 듣는 것. 이 두가지를 잘하는 것이 소통의 핵심입니다. 투명성과 예측 가능성을 기반으로 한 자율성에 개방성을 더해봅시다.
• 협업은 논쟁 테이블 위에서 벌어지는 관철과 양보의 줄다리기입니다. 좋은 리더라면 작은 것을 버리고 큰 것을 얻어야 합니다. 중요하지 않은 일은 원하는 대로 하게 둡시다. 대신 중요한 일이라면 물러서서는 안됩니다. 중요한 일 까지 물러서면 호구입니다.
• 양보했다고 해서 나몰라라 하면 안됩니다. 무관심을 주는게 아니라 자율 선택권을 주는 양보와 타협이라면 지지하고 지원해줘야 합니다.
• 리더십은 무엇일까요? 리더십이라는 역량은 많은 것을 포괄합니다만 그중에서 하나만 꼽으라면 인사이트입니다. 현재 시장을 파악하고 향후 변화의 큰 물줄기를 분간하는 능력이죠. 인사이트가 있어야 기술 변화를 내다보고, 개발 방식과 방향을 결정할 수 있습니다.
• 그럼 인사이트를 어떻게 계발할 수 있을까요? 저는 책과 사람 그리고 크리티컬 싱킹을 제안해봅니다. 좋은 책을 계속 읽고, 좋은 사람을 계속 만나야 합니다. 이렇게 해서 얻어진 것들을 실제 업무에 적용해보고, 크리티컬 싱킹을 해서 계속 확장해야 합니다. 투명하게 지속적으로 본인의 인사이트를 전파하고 개방성을 발휘해 다시 좋은 피드백을 듣고 반영해야 합니다.
• 업무 위주의 책만 보는 것이 아니라 인문이나 리더십 서적 등 다양한 주제의 책을 읽어야 하며, 사내와 외부 사람들 모두 많이 만나보아야 합니다. 일하면서 그리고 책을 읽고 느낀 점을 사람들과 대화를 나누면서 발전시켜야 합니다.

프로젝트 리딩, 테크니컬 리딩, 피플 매니징

• 관리자는 최상위 관리자와 중간 관리자로 나뉩니다. 최상위 관리자는 회사의 미래, 파트너십, 투자를 책임지고, 중간 관리자는 실무선에서 제품을 개발하고 조직을 관리합니다.
• 10년차 20년차가 되어도 관리자 역하을 하지 않고, 본인의 역량과 능력을 활용해서 회사에 기여하는 일반 직원을 개인 기여자라고 부릅니다. 개인 개발자로 남을지 관리자가 될지는 본인의 선택입니다. 하지만 관리자가 무슨 일을 하는지 알아야 본인이 관리자로서 재능이 있는지 알 수 있고, 커리어도 결정할 수도 있습니다.
• 중간 관리자(개발팀장)는 세가지 일을 합니다.
  • 첫번째는 프로젝트 리딩입니다. 제품의 방향을 결정하고 잘 춣시하도록 프로젝트를 진행하는 일입니다.
  • 두번째는 테크니컬 리딩, 기술에 집중합니다. 사용하는 기술이 올바른 기술인지, 해당 기술을 잘 쓰고 있는지, 현 상태로 개발하면 나중에 문제가 생기지는 않을지, 시스템은 확장가능한지 등 기술과 관련된 문제에 집중합니다.
  • 마지막은 피플 매니징입니다. 직원의 행복과 성장에 집중하는 겁니다.

---

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

• PM에는 두가지 뜻이 있습니다. 프로젝트 매니저와 프로덕트 매니저입니다. 혼란을 막고자 제품의 총 책임자를 PO, 프로젝트 책임자를 PM으로 부르며 설명하겠습니다.
• 단적으로 이야기하면 PO는 제품만 신경쓰고, PM은 개발해서 출시하는 전체 일정과 리소스를 관리합니다. 참고로 우리나라 기업은 대개 프로젝트 매니저와 프로덕트 매니저를 한 사람이 맡아서 진행합니다.
• ‘Debugging the Development Process’라는 책이 있습니다. 제목에서 유추할 수 있듯이 개발 과정 자체를 계속 살펴보면서 개선해야 좋은 제품을 만들 수 있다는 메시지를 던져주는 책입니다.

개발 계획 세우기

• 개발 주기는 요구사항을 분석하고, 시스템 구조를 설계하고 개발하고, 테스트와 출시하고, 피드백을 받아서 업데이트하는 전체 과정입니다. 계획을 세우는 이유는 완벽하게 준수하기 위해서가 아닙니다. 성공을 위해 세우는 겁니다. 그러므로 계획을 세워두고 상황에 맞게 수정하고 대비해야 합니다.

역할 나누기

• 역할을 나눈 다는 것은 할 일을 정해주는 게 아닙니다. 야구에서 1루수, 2루수, 3루수같이 포지션을 정해야 합니다. 서로의 포지션을 약간씩 겹치면서 충돌하면서 일해야 합니다.

시간 아끼기

• 시간을 아끼는 최고의 방법은 낭비를 없애는 겁니다. 시간을 잡아먹는 요인으로는 필요없는 코드, 개발 과정에서의 기다림, 불명확한 요구사항, 내부 정치, 느린 내부 소통 이렇게 다섯가지가 있습니다.
• 생산성을 올리는 방법은 모두를 바쁘게 하는 것이 아니고 낭비를 없애는 겁니다. 모두가 바끄고 진척이 안된다면 사실상 낭비하고 있을 가능성이 높습니다.

문제 해결 6단계

• 문제는 항상 발생합니다. 일이란 문제를 잘 정리하고 계산하고 해결하는 행위입니다. 문제가 재발되지 않게 해결하는 게 중요합니다. 고로 문제 자체를 싫어하면 안됩니다.
• 문제는 필연적으로 계속 발생하므로 문제 해결 시스템을 갖추면 시간 낭비를 줄일 수 있습니다.
• 실제로 실행해야만 뭐든 결과가 나옵니다. 모든 결과를 측정/분석해서 더 좋으 목표로 수정하거나 아니면 계획을 더 좋게 바꾸어 다시 실행해 원하는 결과가 나올 때까지 이 과정을 반복해야 합니다.

선별해 문제 풀기

• 제한된 시간을 효과적으로 사용하려면 산적한 문제를 효과적으로 분류하고 대응해야 합니다.
• 중요하고 풀 수 있는 문제는 풉시다. 중요한데 풀 수 없다면 미래로 미뤄둬야 합니다. 풀 수 있지만 중요하지 않다면 위임합니다. 중요하지도 않고 해결하지 못하는 일은 무시합니다.
• 이처럼 중요도가 낮거나 해결할 수도 없는 일이라면 머릿속에서 지워버리는 것도 방법입니다. 그렇지 않으면 낭비로 연결되기 때문입니다. 할 수 있는 일, 중요한 일, 해결할 수 있는 문제에 집중합니다. 재발하지 않도록 해결책을 만듭시다.

우선순위 정하기

• 핵심은 ‘우선순위 정하기’입니다. 우선순위의 기본은 ‘급한가 급하지 않은가?’, ‘중요한가 중요하지 않은가?’에 있습니다.
• 할 일을 고를 때 급한가 급하지 않은가를 따지지 말고, 한 발 물러서서 ‘중요한가 중요하지 않은가를 먼저 생각해야 합니다. 그래야 자신이 삶을 주도하고 시간을 주도하면서 프로액티브하게 살아갈 수 있습니다. 외부에서 오는 것에 반응하는 것은 리액티브한 삶입니다.

---

 

 

읽고 싶은 책이 많아서 일단 여기까지..^^~