출판사 리뷰

★ 더 크게 성장하려면 기술 말고도 원칙이 필요합니다
개발자가 우대받는 시대가 되었습니다. 개발자 관두면 치킨집 차란다는 자조적인 말이 지난 몇 해째 자취를 감췄습니다. 골드러시마냥 비전공자까지 개발 전선에 뛰어들었습니다. 그럼에도 전 세계에서 소프트웨어 인력 부족과 스킬 불일치 문제가 심각합니다. 실력을 갖춘 더 많은 개발자가 필요합니다. 이미 시장에는 기술을 알려주는 많은 양질의 도서가 많습니다. 기술 말고 개발자로 살아가는 데, 시니어를 넘어 테크 리더로서 성장하는 데 도움이 될 원칙을 알려주는 선배가 필요합니다. 그래서 이 책을 준비했습니다. 이 책은 저자 9명이 각자 한 가지씩 9가지 원칙을 제시합니다.

★ 이 책의 대상 독자
_평생 개발자를 꿈꾸는 분
_소프트웨어를 개발하는 더 나은 방법이 궁금한 분
_다양한 난제를 풀 원칙이 필요한 분
_조직을 성장시키고 싶은 스타트업 CTO
_조직 생활과 이직에 고민이 많으신 분
_효율적으로 일하는 방식에 고민이 많은 분

★ 덕업일치를 넘어서
“단순한 덕업일치로 시작해 프로그래머란 직업을 탐구한 기록이
여러분의 탐구 여정에 작은 도움이 되었으면 합니다.
즐거운 여행 되십시오”

프로그래밍을 시작한 지 40년, 업으로 삼은 건 30년 정도 됐어요. 저는 프로그래밍을 하면서 세상과 나를 발견하고 소통하며 조금씩 성장했습니다. 덕분에 지금은 예전 같으면 생각도 못했던 멀고 높은 곳을 탐험하며 즐거운 삶을 살고 있어요.
개발자 그리고 개발 조직 리더로 일하면서 수많은 선택의 순간이 있었습니다. 그 과정에서 북극성처럼 삶의 기준으로 삼은 가치는 무엇이었고 무엇을 얻고 느꼈는지 담백하게 전해드리려고 합니다. 각자의 길을 찾는 데 타산지석이나 반면교사로 삼으실 수 있도록 솔직한 이야기를 나눠드릴게요.

_박성철 컬리 풀필먼트 프로덕트 본부장 겸 데이터 그룹장

★ 오류를 만날 때가 가장 성장하기 좋을 때다
“오류를 만날 때가, 가장 성장하기 좋을 때입니다.”

현재 레몬트리에서 가족 금융 서비스를 만들기 위해서 일하고 있습니다. 네이버 메일이나 카카오스토리 등 대규모 서비스를 만들어본 경험이 있고, 항상 해당 조직에서 가장 못하는 개발자 포지션을 차지하고 있습니다.
개발자가 성장하기 가장 좋은 시기가 언제라고 생각하시나요? 남의 코드가 이해될 때? 전에 못 짜던 코드를 한 번에 구현할 때? 저는 내가 운영하는 서비스에서 장애 또는 오류를 만났을 때라고 생각합니다. 오류를 만났을 때, 내가 사용하는 제품의 코드가 어떻게 동작하는지? 왜 이런 문제가 생기는지 확인할 수 있는 가장 좋은 시간이라고 생각합니다. 오류를 만났을 때 대처하는 자세를 이야기해보겠습니다.

_강대명 레몬트리 CTO

★ 소프트웨어 디자인 원칙
“소프트웨어 디자인, 딱 이것만 기억하세요”
현재 카카오에서 클라우드 플랫폼 기술 이사로 재직하고 있습니다. 《클라우드 전환 그 실제 이야기》, 《카프카, 데이터 플랫폼의 최강자》 등 저술 활동도 꾸준히 진행하고 있고요. 여러분은 ‘설계’가 뭐라고 생각하시나요? 소프트웨어 디자인에도 원칙과 방법이 있습니다. 꼭 필요한 디자인 원칙을 소개해드릴게요. 소프트웨어 디자인이 무엇인지 관점을 정리하지 못한 분들께 도움이 될 거라 확신합니다.

_공용준 카카오 Head of AI SaaS

★ 나의 메이저 버전을 업그레이드하는 마이너 원칙들
“일을 잘하는 게 무엇인지 막연하신가요? 성장하기 위한 나만의 원칙을 찾도록 도와드릴게요”
본업은 소프트웨어 교육/개발자지만 케텔 시절 비파툴, 델마당 개발자 커뮤니티부터 취미 맥 개발자 OSXDev를 거쳐 레츠스위프트 커뮤니티 운영진에 이르기까지 끊임없이 버전을 바꿔가며 살고 있습니다.
개발자에게 학습과 성장은 소프트웨어를 만드는 것과 같아요. 꾸준히 버전을 업그레이드해서 생명력을 갖도록 해야 합니다. 지속해서 업그레이드하는 소프트웨어 버전처럼 내 메이저 버전을 업그레이드하는 마이너 원칙들을 소개합니다. 정답 대신 해답을 찾아가는 방향으로 알려드릴게요.

_김정 코드스쿼드 대표

★ 이직, 분명한 이유가 필요해
“성장을 위한 새로운 환경이 필요한가요?
잘 활용한다면 이직은 좋은 방법 중 하나입니다.”
서비스/제품 만들기를 좋아하는 프로그래머로서 다양한 사람과 함께 일이 되게끔 하는 것에 관심이 많습니다. 현재 무신사에서 개발 실장으로 일하며, 지금까지 베트남 배달 플랫폼 및 커머스, 비트코인 거래소, IoT 등 다양한 서비스를 경험했습니다.
개발자는 부지런히 성장하는 직업이며, 성장에도 다양한 단계가 있습니다. 내가 속한 환경 안에서 성장을 위해 노력하지만 어느 순간 환경의 변화가 필요할 때도 있죠. 그때, 이직은 좋은 방법 중 하나입니다. 하지만 여느 도구와 마찬가지로 분명한 이유와 방향이 필요합니다. 정답은 없지만 제가 경험한 각 성장 단계에서 이직 이유와 방향을 전하고자 합니다.

_박미정 당근마켓 개발 리드

★ 목표를 달성하는 나만의 기준, GPAM
“목표를 달성하고 문제를 해결하기 위한
프레임워크가 필요하신가요? GPAM을 활용해 보세요”
한국과 미국 실리콘밸리를 오고 가며 30여 년 동안 개발자로 일하고 있습니다. 그동안 쌓은 노하우를 개발자 커뮤니티에 풀어놓고자 기술, 개발, 조직 문화를 주제로 강연과 코칭 활동을 병행하고 있어요.
왜 목표를 달성하고 문제를 해결하는 건 일이 어려울까요? 같은 고민을 하고 계시다면 GPAM을 활용해보세요. Goal, Plan, Action, Measure. 목표를 달성하고 문제를 해결하기 위한 프레임워크입니다. GPAM을 이용해 개발자들이 제일 많이 하는 고민 6가지를 분석해볼게요. 목표를 달성하고 문제를 해결하기 위한 방법을 찾고 계셨다면 놓치지 마세요.

_박종천 넥스트인텔리전스 AI 어드바이저

★프로덕트 중심주의
“10년, 20년 후에 치킨집 말고 그냥 개발자 하면 안 되나요?
개발이 좋아 오랜 시간 계속하고 싶다면 자신의 성장 계획을
프로덕트 중심으로 설계해보세요.”

10년, 20년 후에도 흔들리지 않고 개발자로 성장하는 방법은 무엇일까요? 개발자에겐 셀 수 없을 정도로 다양한 개발 기술의 습득도 중요하지만, 장기적인 관점으로 보면 어떤 목표를 갖고 성장하는지가 더욱 중요합니다. 여러 스타트업 현장에서 프로덕트를 처음부터 만드는 일을 하다 보니, 프로덕트를 만들면 그저 학습할 때보다 크게 성장한다는 사실을 알게 되었습니다. 그래서 ‘프로덕트 중심주의’라는 다소 과감한 제목으로 정리해봤습니다.

프로덕트 중심주의에서 ‘프로덕트’를 반드시 회사의 담당 업무로 개발할 필요는 없습니다. 어떤 환경에 있는 개발자이건 프로덕트 중심으로 성장 계획을 세우고 실천할 수 있습니다. 프로덕트를 중심에 놓는 순간, 오랜 기간 동안 투자한 여러분의 노력이 차곡차곡 잘 쌓이는 것을 경험하게 될 겁니다.

_이동욱(네피림) SpaceVision AI 대표

★ 제어할 수 없는 것에 의존하지 않기
“프로그래밍, 이직, 조직과 매니징에서
제어할 수 있는 것에 집중하세요.”
현재 교육/채용 플랫폼인 인프런/랠릿에서 CTO로 근무하고 있습니다. 조직과 서비스의 규모에 맞는 적정 기술과 아키텍처를 적용하고 공유합니다.
아주 사소한 것부터 결정을 내리는 데 고민이 필요하다면, 나만의 원칙들이 없어서 그럴 수 있습니다. 반면 나에게 맞는 원칙들이 세워져 있다면, 빠르게 결정하고 중요한 고민에 집중할 수 있습니다.
프로덕트 엔지니어로서, 매니저로서 지침으로 사용하는 ‘제어할 수 없는 것에 의존하지 않기 원칙’을 어떻게 세웠고, 어떻게 사용하고 있는지 소개합니다.

_이동욱(향로) 인프랩(인프런/랠릿) CTO

★ 달리는 기차의 바퀴를 갈아 끼우기
“우리 모두 밥값하는 개발자가 되자!
그러나 가슴 속에는 슈퍼 개발자를 꿈꾸자!”
슈퍼 개발자가 되고 싶은가요? 그러려면 먼저 밥값하는 개발자가 되어야 합니다. 그리고 밥값하는 개발자로 만족하면 안 됩니다.
40년 전 8비트 애플로 코딩 인생을 시작해서, 30여 년 동안 세 번의 창업과 세 번의 이직을 거쳐, 4년 전 데이원컴퍼니(a.k.a 패스트캠퍼스)에 2호 개발자로 합류해서, 60여 명의 개발자와 함께 달리는 기차의 바퀴를 갈아 끼우는 일을 하고 있습니다.
좋은 코드와 아키텍처, 효율적인 개발 프로세스를 다루는 책은 차고 넘칩니다. 책을 읽는 동안은 모든 문제를 해결할 수 있을 것 같지만, 막상 실제 업무에 도입해서 실천하면 책과는 다른 현실에 좌절하게 됩니다. 현실은 언제나 케바케고, 나의 케이스는 항상 최악이죠. 그래서 준비했습니다. 개발자라면 처해있는 현실에 무관한 뻔한 지침 세 가지. 그리고 그 지침을 뒷받침하는 원칙 한 가지. 참 쉽죠?

_장동수 수수한기술 대표
?
?
?책 속으로
★ ‘10년이 가도 변치 않을 업의 지혜, 그 후 2년’(최현우) _ 3쪽
연두색 바탕에 나열된 블록들 위로 ‘코볼의 구조’라는 고딕 폰트를 사용한 흰색 글자가 선명하게 빛나고 있었습니다. 2024년 6월 21일 금요일. 이 책의 출간 1년 7개월을 기념한 행사 〈래빗톡 : 개발자 원칙 완전체〉 현장에는 ‘AI 코파일럿이 내 프로그래머라는 직업을 삼켜버릴 것 같다’는 위기감에 휩싸인 청중 70명의 눈이 잊혀진 언어의 구조에 초점을 맞추고 있었습니다. 발표자가 다음 페이지를 넘기자 코볼 코드가 등장했습니다. “Hello Cobol World“를 출력하는 단정한 코드 뭉치. 데이터 처리 목적으로 만들어진 양산형 개발자의 언어! 단순한 문법으로 사랑받으며 사실상 기업용 애플리케이션의 표준 언어로 자리잡았던 코볼이 프로젝트의 빔으로 소환되었습니다. 이어서 화자는 화두를 던졌습니다.

“AI 시대, 어떤 개발자가 될 것인가?”

공저자이자, 존경받는 (나만의 생각으로는) ‘구도자형 개발자’인 박성철 본부장은 ‘이런 개발자가 되고 싶었던 건 아니었는데 말이죠...’를 강연하며 개발 초년부터 지금까지 이어진 ‘진짜 프로그래머’ 논쟁을 ‘어떤 개발자가 될 것인가’라는 명제에 이어붙였습니다. 끝없이 변화하고 혁신이 반복되는 업계에서 실존적 존재로서 적응하며 살아 남는 문제로 말이죠.

아홉 저자가 모두 모인 행사장에 질문이 끊임없이 이어졌습니다. 저자 사이에 의견도 갈렸습니다. 서로 마이크를 번갈으며 반론에 반론을 더했습니다. 질문은, “AI가 개발자를 대체하지 않겠는가?”, “AI 시대에 우리는 어떻게 해야 하는가?”, “AI를 업무에 어디까지 이용하나?” 같은 AI 일변도였습니다.

2022년 11월 이 책은 예약 판매에 들어갔습니다. 우연의 일치로 같은 기간 챗GPT 3.5가 공개되었습니다. AI 광풍이 개발 현장에 찾아왔습니다. 이 책의 엮은이로서 궁금해졌습니다. 그간 저자들에게는 무슨 일이 벌어졌을까? 과연 ‘10년이 가도 변치 않을 업의 지혜’를 담은 이 책의 내용이 AI 시대에도 유효한가? 그리고 개발자는 어떻게 살아가야 하는가?

행사 당일 강대명 저자는 이렇게 말했습니다.

“더 깊고 자세히, 더 많이 공부하라.”

‘프로그래머가 무엇인지’에 대한 정의는 아직 내려지지 않았지만, 그럼에도 프로그래머는 오늘을 살아가야 합니다. 길이 안 보일 때는 그저 할 수 있는 일을 할 뿐입니다. 그런 하루하루가 모이면 훗날 누군가가 길이라 부를 것입니다. 그러니 섣부른 답을 찾으려 책장을 펼치지는 말기 바랍니다. 이 책은 애초에 정답을 품지 않았습니다. 먼저 걸어간 선배의 발자취만 담았을 뿐입니다.

★ ‘덕업일치를 넘어서’(박성철) _7쪽
개발자에게 소위 덕업일치의 삶은 덜 고통스럽고 남보다 수월하거나 유리한 삶이라는 시선이 있습니다. 프로그래머라는 직업이 생소하고 정립되지 않았던 시절, 용기를 내어 어릴 때 접한 프로그래밍을 직업으로 삼고 살아보기로 결심했습니다. 그 결심에 도움이 되었던 생각을 원칙으로 삼고 미래가 불투명한 프로그래머라는 직업을 탐색했습니다.
직업인으로서 프로그래머는 단지 프로그래밍할 줄 아는 사람이라는 의미와 매우 다른 모습이었고 전문가로서 프로그래머는 더 먼 여정이 필요했습니다. 이 글은 이왕 선택한 직업이 의미 있고 인정받는 직업이었으면 하는 마음으로 길을 떠났던 여러 사람 중 한 사람의 중간 보고서입니다.

제가 경력을 시작할 때와 달리 개발자는 인기 많은 직업이 되었고 친숙해졌습니다. 하지만 아직도 전문가로서 인정받지는 못하고 있습니다. 남은 이 길을 같이 떠나 보기를 권하고 싶은 마음에 성급하게 글을 정리해보았습니다.

★ ‘출간 후 2년, 그다음 이야기’ (공용준)_146쪽
생성형 AI가 만든 코드들이 완벽하게 돌아가진 않지만 적어도 내 설계가 어떠한지 곧바로 확인할 수 있게 되어서 ‘구현부터 하지 말고, 제발 설계부터 하자!’는 원칙을 훨씬 더 강화해서 적용해도 될 환경이 마련되었습니다.
그간 제품 개발 전이나 신규 항목을 리뷰할 때 RFDC* 세션을 만들어서 진행했습니다. 처음 개발자들 반응은 “우리가 왜 이런 문서를 써? 항목은 뭐 이리 많아!”였는데, 막상 도입하고 나니 설계에 대한 개선 사항을 토론하는 문화가 생겨 제품 개선에 많은 도움이 되었다고 하더라고요. 그동안 제가 주창한 ‘소프트웨어엔 설계가 없다(그래서 문제다)’에 대한 공감도 얻을 수 있었습니다. 제품 설계와 사전 리뷰가 이렇게 유익합니다. 여러분도 적극 도입하기 바랍니다.

★ ‘달리는 기차의 바퀴를 갈아 끼우기’(장동수) _291쪽
지금까지 개발 문화의 3가지 행동 강령과 글쓰기의 중요성을 말씀드렸습니다. 행동 강령을 아무리 지켜나가려고 해도 글쓰기 능력, 코딩하는 능력이 없으면 그럴 수 없습니다. 글을 마무리하면서 《유시민의 글쓰기 특강》에 나오는 ‘글쓰기’를 ‘코딩’으로 바꿔서 읽어보겠습니다.

“코딩을 잘 하려면 많이 읽어야 합니다. 코드를 많이 읽어도 코딩을 잘 못할 수는 있습니다. 그러나 많이 코드를 많이 읽지 않고도 코딩을 잘하는 것은 불가능합니다. 코딩을 많이 할수록 더 잘하게 됩니다. 축구나 수영이나 글쓰기가 그런 것처럼 코드도 근육이 있어야 쓸 수 있습니다. 코딩 근육을 만드는 유일한 방법을 코딩을 하는 겁니다.”

여기에 예외는 없습니다.

그래서 ‘원칙’입니다.


?추천사

“이 책의 추천사를 요청받았을 때, 표지에 적힌 저자 명단을 보고 '이런 훌륭한 선수들을 책 쓰는 일로 한 번에 모을 수 있다니'라는 생각이 먼저 들었습니다. 워낙 경력이 많은 분들이라 어쩌면 종종 보던 '라떼는 말이야' 책일 수도 있겠다는 선입견과 함께 말이죠. 선입견은 처음 몇 페이지를 보고 깨졌습니다.
책을 읽고 굳이 내 맘대로 책의 장르를 분류하자면 엯촉님들의 기술적 회고서에 가깝다고 말하고 싶습니다. 모든 저자의 글에서 소프트웨어 개발자, 기술, 프로세스가 서비스에 어떻게 녹아들어가는지, 또 저자 자신을 포함하여 그 과정에 참여하는 사람들에 대한 고수의 관점을 생생하게 느낄 수 있었습니다. 고수들의 소프트웨어 개발, 개발자의 성장에 대한 태도가 하나하나 감동적입니다.
이 책은 이제 코딩 좀 하게 된 주니어 개발자에게는 꼰대스럽지 않게 생각의 방향을 잡아주고, 동시에 시니어들에게는 스스로를 정리해 한 단계 더 성장할 기회를 제공합니다. 백만 권쯤 팔리면 좋겠습니다.“

_이민석 국민대학교 소프트웨어학부 교수