★ 더 크게 성장하려면 기술 말고도 원칙이 필요합니다 개발자가 우대받는 시대가 되었습니다. 개발자 관두면 치킨집 차란다는 자조적인 말이 지난 몇 해째 자취를 감췄습니다. 골드러시마냥 비전공자까지 개발 전선에 뛰어들었습니다. 그럼에도 전 세계에서 소프트웨어 인력 부족과 스킬 불일치 문제가 심각합니다. 실력을 갖춘 더 많은 개발자가 필요합니다. 이미 시장에는 기술을 알려주는 많은 양질의 도서가 많습니다. 기술 말고 개발자로 살아가는 데, 시니어를 넘어 테크 리더로서 성장하는 데 도움이 될 원칙을 알려주는 선배가 필요합니다. 그래서 이 책을 준비했습니다. 이 책은 저자 9명이 각자 한 가지씩 9가지 원칙을 제시합니다. ★ 이 책의 대상 독자 _평생 개발자를 꿈꾸는 분 _소프트웨어를 개발하는 더 나은 방법이 궁금한 분 _다양한 난제를 풀 원칙이 필요한 분 _조직을 성장시키고 싶은 스타트업 CTO _조직 생활과 이직에 고민이 많으신 분 _효율적으로 일하는 방식에 고민이 많은 분 ★ 덕업일치를 넘어서 “단순한 덕업일치로 시작해 프로그래머란 직업을 탐구한 기록이 여러분의 탐구 여정에 작은 도움이 되었으면 합니다. 즐거운 여행 되십시오” 프로그래밍을 시작한 지 40년, 업으로 삼은 건 30년 정도 됐어요. 저는 프로그래밍을 하면서 세상과 나를 발견하고 소통하며 조금씩 성장했습니다. 덕분에 지금은 예전 같으면 생각도 못했던 멀고 높은 곳을 탐험하며 즐거운 삶을 살고 있어요. 개발자 그리고 개발 조직 리더로 일하면서 수많은 선택의 순간이 있었습니다. 그 과정에서 북극성처럼 삶의 기준으로 삼은 가치는 무엇이었고 무엇을 얻고 느꼈는지 담백하게 전해드리려고 합니다. 각자의 길을 찾는 데 타산지석이나 반면교사로 삼으실 수 있도록 솔직한 이야기를 나눠드릴게요. (박성철_ 컬리 풀필먼트 & 딜리버리 프로덕트 본부장) ★ 오류를 만날 때가 가장 성장하기 좋을 때다 “오류를 만날 때가, 가장 성장하기 좋을 때입니다.” 현재 레몬트리에서 가족 금융 서비스를 만들기 위해서 일하고 있습니다. 네이버 메일이나 카카오스토리 등 대규모 서비스를 만들어본 경험이 있고, 항상 해당 조직에서 가장 못하는 개발자 포지션을 차지하고 있습니다. 개발자가 성장하기 가장 좋은 시기가 언제라고 생각하시나요? 남의 코드가 이해될 때? 전에 못 짜던 코드를 한 번에 구현할 때? 저는 내가 운영하는 서비스에서 장애 또는 오류를 만났을 때라고 생각합니다. 오류를 만났을 때, 내가 사용하는 제품의 코드가 어떻게 동작하는지? 왜 이런 문제가 생기는지 확인할 수 있는 가장 좋은 시간이라고 생각합니다. 오류를 만났을 때 대처하는 자세를 이야기해보겠습니다. (강대명_ 레몬트리 CTO) ★ 소프트웨어 디자인 원칙 “소프트웨어 디자인, 딱 이것만 기억하세요” 현재 카카오에서 클라우드 플랫폼 기술 이사로 재직하고 있습니다. 《클라우드 전환 그 실제 이야기》, 《카프카, 데이터 플랫폼의 최강자》 등 저술 활동도 꾸준히 진행하고 있고요. 여러분은 ‘설계’가 뭐라고 생각하시나요? 소프트웨어 디자인에도 원칙과 방법이 있습니다. 꼭 필요한 디자인 원칙을 소개해드릴게요. 소프트웨어 디자인이 무엇인지 관점을 정리하지 못한 분들께 도움이 될 거라 확신합니다. (공용준_ 카카오 클라우드 테크니컬 디렉터) ★ 나의 메이저 버전을 업그레이드하는 마이너 원칙들 “일을 잘하는 게 무엇인지 막연하신가요? 성장하기 위한 나만의 원칙을 찾도록 도와드릴게요” 본업은 소프트웨어 교육/개발자지만 케텔 시절 비파툴, 델마당 개발자 커뮤니티부터 취미 맥 개발자 OSXDev를 거쳐 레츠스위프트 커뮤니티 운영진에 이르기까지 끊임없이 버전을 바꿔가며 살고 있습니다. 개발자에게 학습과 성장은 소프트웨어를 만드는 것과 같아요. 꾸준히 버전을 업그레이드해서 생명력을 갖도록 해야 합니다. 지속해서 업그레이드하는 소프트웨어 버전처럼 내 메이저 버전을 업그레이드하는 마이너 원칙들을 소개합니다. 정답 대신 해답을 찾아가는 방향으로 알려드릴게요. (김정_ 코드스쿼드 대표) ★ 이직, 분명한 이유가 필요해 “성장을 위한 새로운 환경이 필요한가요? 잘 활용한다면 이직은 좋은 방법 중 하나입니다.” 서비스/제품 만들기를 좋아하는 프로그래머로서 다양한 사람과 함께 일이 되게끔 하는 것에 관심이 많습니다. 현재 무신사에서 개발 실장으로 일하며, 지금까지 베트남 배달 플랫폼 및 커머스, 비트코인 거래소, IoT 등 다양한 서비스를 경험했습니다. 개발자는 부지런히 성장하는 직업이며, 성장에도 다양한 단계가 있습니다. 내가 속한 환경 안에서 성장을 위해 노력하지만 어느 순간 환경의 변화가 필요할 때도 있죠. 그때, 이직은 좋은 방법 중 하나입니다. 하지만 여느 도구와 마찬가지로 분명한 이유와 방향이 필요합니다. 정답은 없지만 제가 경험한 각 성장 단계에서 이직 이유와 방향을 전하고자 합니다. (박미정_ 무신사 개발 실장) ★ 목표를 달성하는 나만의 기준, GPAM “목표를 달성하고 문제를 해결하기 위한 프레임워크가 필요하신가요? GPAM을 활용해 보세요” 한국과 미국 실리콘밸리를 오고 가며 30여 년 동안 개발자로 일하고 있습니다. 그동안 쌓은 노하우를 개발자 커뮤니티에 풀어놓고자 기술, 개발, 조직 문화를 주제로 강연과 코칭 활동을 병행하고 있어요. 왜 목표를 달성하고 문제를 해결하는 건 일이 어려울까요? 같은 고민을 하고 계시다면 GPAM을 활용해보세요. Goal, Plan, Action, Measure. 목표를 달성하고 문제를 해결하기 위한 프레임워크입니다. GPAM을 이용해 개발자들이 제일 많이 하는 고민 6가지를 분석해볼게요. 목표를 달성하고 문제를 해결하기 위한 방법을 찾고 계셨다면 놓치지 마세요. (박종천_ 몰로코 헤드 오브 솔루션즈 아키텍처) ★프로덕트 중심주의 10년, 20년 후에 치킨집 말고 그냥 개발자 하면 안 되나요? 개발이 좋아 오랜 시간 계속하고 싶다면 자신의 성장 계획을 프로덕트 중심으로 설계해보세요.” 10년, 20년 후에도 흔들리지 않고 개발자로 성장하는 방법은 무엇일까요? 개발자에겐 셀 수 없을 정도로 다양한 개발 기술의 습득도 중요하지만, 장기적인 관점으로 보면 어떤 목표를 갖고 성장하는지가 더욱 중요합니다. 여러 스타트업 현장에서 프로덕트를 처음부터 만드는 일을 하다 보니, 프로덕트를 만들면 그저 학습할 때보다 크게 성장한다는 사실을 알게 되었습니다. 그래서 ‘프로덕트 중심주의’라는 다소 과감한 제목으로 정리해봤습니다. 프로덕트 중심주의에서 ‘프로덕트’를 반드시 회사의 담당 업무로 개발할 필요는 없습니다. 어떤 환경에 있는 개발자이건 프로덕트 중심으로 성장 계획을 세우고 실천할 수 있습니다. 프로덕트를 중심에 놓는 순간, 오랜 기간 동안 투자한 여러분의 노력이 차곡차곡 잘 쌓이는 것을 경험하게 될 겁니다. (이동욱/네피림_ 데이블 스페이스비전그룹 테크니컬 디렉터) ★ 제어할 수 없는 것에 의존하지 않기 “프로그래밍, 이직, 조직과 매니징에서 제어할 수 있는 것에 집중하세요.” 현재 교육/채용 플랫폼인 인프런/랠릿에서 CTO로 근무하고 있습니다. 조직과 서비스의 규모에 맞는 적정 기술과 아키텍처를 적용하고 공유합니다. 아주 사소한 것부터 결정을 내리는 데 고민이 필요하다면, 나만의 원칙들이 없어서 그럴 수 있습니다. 반면 나에게 맞는 원칙들이 세워져 있다면, 빠르게 결정하고 중요한 고민에 집중할 수 있습니다. 프로덕트 엔지니어로서, 매니저로서 지침으로 사용하는 ‘제어할 수 없는 것에 의존하지 않기 원칙’을 어떻게 세웠고, 어떻게 사용하고 있는지 소개합니다. (이동욱/향로_ 인프런/인프랩 CTO) ★ 달리는 기차의 바퀴를 갈아 끼우기 “우리 모두 밥값하는 개발자가 되자! 그러나 가슴 속에는 슈퍼 개발자를 꿈꾸자!” 슈퍼 개발자가 되고 싶은가요? 그러려면 먼저 밥값하는 개발자가 되어야 합니다. 그리고 밥값하는 개발자로 만족하면 안 됩니다. 40년 전 8비트 애플로 코딩 인생을 시작해서, 30여 년 동안 세 번의 창업과 세 번의 이직을 거쳐, 4년 전 데이원컴퍼니(a.k.a 패스트캠퍼스)에 2호 개발자로 합류해서, 60여 명의 개발자와 함께 달리는 기차의 바퀴를 갈아 끼우는 일을 하고 있습니다. 좋은 코드와 아키텍처, 효율적인 개발 프로세스를 다루는 책은 차고 넘칩니다. 책을 읽는 동안은 모든 문제를 해결할 수 있을 것 같지만, 막상 실제 업무에 도입해서 실천하면 책과는 다른 현실에 좌절하게 됩니다. 현실은 언제나 케바케고, 나의 케이스는 항상 최악이죠. 그래서 준비했습니다. 개발자라면 처해있는 현실에 무관한 뻔한 지침 세 가지. 그리고 그 지침을 뒷받침하는 원칙 한 가지. 참 쉽죠? (장동수_ 데이원컴퍼니/패스트캠퍼스 CTO)

01 덕업일치를 넘어서 __ 뒤늦은 진로 선택 __ 덕업 일치의 시작 __ 테라포밍 __ 테크 리드의 길 __ 아직도 가야 할 길 02 오류를 만날 때가 가장 성장하기 좋을 때다 __ 오래된 오류와의 만남 __ 정말인지 소스 코드로 확인하기 __ 결과물 내 것으로 만들기 03 소프트웨어 디자인 원칙 __ 디자인이란 무엇인가? __ 설계와 요구사항 __ 소프트웨어 설계 원칙 : 통합적으로 설계하라 __ 명시적 소프트웨어 설계 __ 암묵적 소프트웨어 설계 __ 통합 설계의 미래 04 나의 메이저 버전을 업그레이드하는 마이너 원칙들 __ v 0.1.0 두리번거리면서 속력과 방향을 자주 확인하기 __ v 0.2.0 낯선 방식으로 해결하기 __ v 0.3.0 개구리를 해부하지 말고, 직접 만들기 __ v 0.4.0 남을 향한 자존심을 버리고, 나를 향한 자존감 채우기 __ v 0.5.0 결과를 향하면서 과정을 기록하기 __ v 0.6.1 의도한 실수를 반복하면서 작은 부분을 개선하기 __ v 0.7.0 기준을 정하기 전에 여러 답을 찾아서 공유하기 __ v 1.0.0 배포하기 그리고 다음 버전 준비하기 05 이직, 분명한 이유가 필요해 __ 어떻게 기술을 교류할 수 있을까? __ 제품에 대한 주인의식을 가질 수 있을까? __ 체계적인 개발/조직 문화 경험하기 __ 경험을 넘어 개발/조직 문화에 기여하기 __ 완전히 새로운 서비스/도메인 경험하기 __ 조직을 만들고, 관리자 역량 향상시키기 06 목표를 달성하는 나만의 기준, GPAM __ 목표 달성 가능성을 높여주는 GPAM을 소개합니다 __ S.M.A.R.T. 하게 목표 세우기 __ 개발 사이클과 GPAM 원칙을 비교해보기 __ GPAM 실천 사례를 공유합니다 __ 개발자의 7가지 고민, GPAM으로 타파하기 07 프로덕트 중심주의 __ 프로덕트 만들기를 목표 삼기 __ 반복적으로 완성하기 __ 디테일까지 도달하기 __ 항상 협업 모드로 작업하기 __ 망설일 바에는 실패하자 __ 조직과 팀의 선택 08 제어할 수 없는 것에 의존하지 않기 __ 코드 설계에 적용하기 __ 이직에 적용하기 __ 조직과 매니징에 적용하기 09 달리는 기차의 바퀴를 갈아 끼우기 __ 밥값에 대하여 __ 기술 부채에 대하여 __ 삽질에 대하여 __ 은탄환은 없다. 많이 읽고, 많이 쓰고, 많이 생각하자