프로그래머, 열정을 말하다(The Passionate Programmer)

저자 : 채드 파울러(Chad Fowler), 옮긴이 : 송우일

 

들어가며

---

프로그래머, 열정을 말하다

실력있는 개발자로 성장하고 직업적 성공을 위해 무슨 마음가짐을 가지고 어떤 노력을 해야 하는지에 대하여 소개한 책이다. 육아휴직 후 개발이란 일에서 멀어지며 좋은 개발자가 되기 위한 노력하는게 권태로워졌다. 휴직 5개월차 개발자 아빠에게 다시 시작할 동기부여가 되는 나름 괜찮은 자기계발서이다. 

추천 독자는 매너리즘을 겪고 있는 잠시 정체 또는 슬럼프를 겪고있는 개발자이다. 슬럼프는 올수도 있고 안올수도 있지만, 일단 왔다는 것은 성장 욕구가 있다는 것이다. 안오는 사람들은 2가지 부류인데, 성장 욕구가 있으면서 멘탈이 정말 강한 영웅형?(사실 영웅은 고난을 통해 태어난다고 생각하지만..) 인간이거나 성장 욕구가 없는 개발과 관련된 시간을 주 40 업무시간에 한정하고, 일년에 책 한권 안읽는 인간이다. 가끔은 후자에 해당하는 사람들이 부럽기도 하다 ㅎㅎ

 

총 5부로 구성되어 있으며, 주요 내용은 아래와 같다.

1부 - 당신의 시장을 선택하라 : 개발자로서 어떤 기술을 읽혀야 좋을지 어디서 커리어를 쌓아나갈 것인지 현재만 보지말고 미래까지 고려하여 결정하라고 조언한다.

2부 - 자신에게 투자하라 : 일반적으로 개발자로서의 실력을 어떤 방식으로 늘릴 것인지를 소개한다.

3부 - 실행 : 2부와 비슷한 내용이다.

4부 - 마케팅은 높으신 분들만 하는 게 아니다 : 유능한 개발자로 조직에서 주변 사람들에게 각인시켜 합당한 가치를 인정받기 위한 팁을 알려준다.

5부 - 자신의 강점을 유지보수하라 : 개발자로 살아남기 위해 해야할 일이 무엇인지 일깨워준다.

 

인상 깊었던 내용 발췌

---

1부 - 당신의 시장을 선택하라

01 그냥 앞서갈 것인가, 위험까지 무릎쓸 것인가p20

 큰 투자를 하려고 한다. 큰돈을 투자하는 게 아니라 자신의 시간, 바로 자신의 삶을 투자하는 것이다. 경력이라는 흐름에 그저 떠다니기만 하면서 그 흐룸이 가는 대로 자신을 내맡겨 버리는 사람이 많다. 자바나 비주얼 베이직을 우연히 알게 되자, 고용주는 이것이 업계 최신 유행이라고 직원들의 교육에 돈을 쓴다. 그래서 우리는 한동안 무언가가 손에 들어올 때까지 그 흐름을 쫓아다닌다. 프로그래머들의 경력은 방향 없는 우연의 연속이다.

 회사를 창업하고 회사의 존망이 걸린 가장 중요한 제품을 개발하고 있다고 상상해 보자. 이 제품이 성공하지 못하면 회사는 파산할 것이다. 대상 고객에게 얼마나 주의를 기울이는가? 실제로 제품을 만들기 전에 제품이 어떠해야 하는지 얼마나 생각하는가? 아무도 우리를 위해 이런 결정을 해주지 않는다. 우리는 결정을 할 때 각 세부 사항까지 철저히 주의를 기울여야 한다.

 그렇다면 왜 개발자들은 대부분 경력 선택에 이와 같은 주의를 기울이지 않을까? 경력을 사업이라고 생각한다면(사실은 그렇다), 자신이라는 '상품'은 자신이 제공해야만 하는 서비스로 구성된다.

 그러한 서비스는 무엇인가? 서비스를 누구에게 팔려고 하는가? 서비스에 대한 수요가 향후 몇 년간 늘어날 것인가, 줄어들 것인가? 이러한 서택에 얼마나 큰 모험을 기꺼이 할 것인가?

나는 자바 개발자이다. 자바라는 언어를 선택한 계기는 우연이었다. 멀티미디어 공학과 광고홍보학을 복수 전공하여 IT와 광고쪽 나름 이름있는 기업을 대상으로 취업준비를 하였는데, 11번가 인턴에 운좋게 합격하여 개발자로 경력을 시작하게 되었고 자바와 스프링을 접하게 된 것이다. 운이 좋았고 만약 C#이나 PHP 등 다른 언어로 서비스하는 회사에서 날 불러주었다면 지금과는 크게 달라졌을 것이다. 그땐 정말 내 삶에 깊은 고민을 하지 않았던 것 같다.

 

02 수요와 공급 - p23

 위험과 보상을 절충하는 것은 어느 기술과 영역에 투자할지 신중하게 고르는 데 중요한 부분이다. 15년 전만 해도 위험이 크지 않고 안전한 선택은 코볼 프로그래밍을 배우는 것이었다. 물론 평균 임금을 놓고 경쟁했던 코볼 프로그래머가 많았지만 그다지 대단하지 않았다. 일자리를 쉽게 찾을 수 있었지만 돈을 특별히 많이 벌지는 못했다. 위험이 작은 만큼 보상도 작았던 것이다.

 반면에 같은 시기에 썬 마이크로 시스템즈(Sun Microsystems)에서 새로 출시한 자바 언어를 연구하기로 했다면 자바로 실제 개발을 하는 회사의 일자리를 찾기가 한동안 어려웠을 것이다. 결국 자바로 개발하게 될 줄 누가 알았겠는가?

 그러나 당시 업계 상황을 보고 있었다면 썬이 그랬던 것처럼 자바에 특별한 뭔가가 있음을 알았을 것이다. 자바가 크겠다는 강한 느낌이 들었을 것이다. 초기에 자바에 투자하면 다가오는 거대한 기술 추세에서 리더가 됐을 것이다. 물론 그렇게 했다면 여러분은 옳은 결정을 한 것이다. 또 개인적으로 자바에 투자하기로 패를 던졌다면, 자바에 대한 개인적인 투자는 매우 수지가 맞았을 것이다. 위험이 큰 만큼 보상도 큰 것이다.

예시로 든 자바가 나에게는 스위프트였다. 2013년 겨울방학 코더스하이라는 iOS 앱 제작 교육 업체에서 산학연계 인턴을 했었는데, 대표님은 그야말로 애플 성덕이고 나는 애플뽕을 강하게 맞고 새 학기를 시작하였다. 2014년 졸업학기에 애플에서 스위프트를 출시하자 나는 이를 시장 선점의 기회로 보고 졸업 작품을 스위프트로 개발하였다. 취업에 많은 어필이 될줄 알았는데, 면접에서의 반응은 그닥이었던 것으로 기억한다. 당시 iOS 앱 개발 주류였던 Objective-C로 했다면 대화가 조금 더 되지 않았을까? 

 

03 코딩만으로는 이제 충분하지 않다 - p31

 어떤 기술에 투자할지 생각하는 것만으로는 충분하지 않다. 이제 기술은 필수품이 됐다. 결국 프래그래머들은 사업 담당자들이 사업을 책임지는 동안 편하게 앉아서 단순히 프로그래밍 언어를 익히거나 운영 체제를 공부하는 일만 할 수 없게 되었다. 사업 관리자들이 원하는 것이 단지 코드 짜는 로봇이라면 그런 일을 할 사람은 다른 나라에서 뽑는 편이 훨씬 쉽기 때문이다. 회사에서 계속 쓸모 있는 사람으로 남고 싶다면 자신이 속한 사업 분야에 뛰어들어야 한다.

 여러분은 '그냥 프로그래머'일지도 모른다. 그러나 해당 사업 분야의 언어로 기업 고객과 이야기할 수 있다는 것은 결정적인 기술이다. 같이 일하는 모든 사람이 소프트웨어가 어떻게 개발되는지 제대로 이해한다면 삶이 얼마나 편해질까. 웹 애플리케이션의 페이지 하나에 레코드 3만 개를 돌리는 게 왜 나쁜 생각인지 또는 개발 서버 링크를 건네주면 왜 안 되는지 고객에게 설명할 필요가 없을 것이다. 기업 고객도 프로그래머에 대해 같은 생각을 한다. "하나 하나 시시콜콜 설명하지 않아도 프로그래머들이 요구 사항을 이해한다면 같이 일하기 얼마나 편할까?"라고 말이다. 무슨 뜻일까? 여러분의 봉급이 나오는 곳은 바로 기업이다.

 유행하는 기술처럼 사업 분야도 같은 방법으로 선택할 수 있다. 소프트웨어 개발에서 자바와 닷넷은 현재 잘나가는 기술이다. 자바와 닷넷을 배우면 이 기술을 채택한 회사에서 일자리를 얻을 수 있다. 사업 분야도 마찬가지다. 습득할 기술을 고를 때처럼 종사할 산업을 고를 때도 같은 관심을 기울여야 한다.

이제 자신의 시간을 투자할

사업 분야에 대해 생각할 시간이다.

사업 분야를 잘 선택해야 하는 중요성에 비춰보면 포트폴리오를 완성할 때 여러분이 선택한 회사나 업계는 자신에게 중요한 투자처다. 자신이 투자해야 할 사업 분야에 대해 아직 정말 진지하게 생각해 보지 않았다면 지금이 바로 생각해야 할 때다. 하루가 지나갈 때마다 기회를 잃어버리는 것이다. 정체된 사업 분야에서 개발 일을 계속하는 것은 고이자율 예금 상품이 나왔는데 이자율이 낮은 계좌에 예금을 계속 내버려두는 것과 같은 좋지 않은 투자 선택이다.

실천하기

회사 업무와 관련된 업계 잡지를 고른다. 아마 한 권도 사보지 않았을 것이다. 회사에는 대부분 업계 잡지 과월호 모음이 있다. 잡지를 하나하나 읽기 시작하라. 모든 내용을 이해할 수는 없겠지만 꾸준히 읽도록 한다. 경영진이나 비즈니스 고객에게 물어볼 질문 목록을 만들라. 질문이 멍청해 보여도 고객은 여러분이 배우려고 한다는 사실을 고맙게 여길 것이다.

 업계 웹 사이트를 찾아 정기적으로 검토할 수도 있다. 웹 사이트와 잡지에서 뉴스와 특집 기사가 무엇을 다루는지 특별히 주의해 보라. 업계에서 무엇을 하려고 애쓰는가? 현재 새롭게 뜨는 주제는 무엇인가? 그게 뭐든 간에, 고객과 그에 대해 이야기하고 설명을 부탁하고 의견을 구하라. 현재 추세가 여러분이 일하는 회사, 부서, 팀, 결국에는 여러분의 일에 어떻게 영향을 미칠지 생각해보라.

맞는 말이다. 아무리 현재 대세인 자바로 개발을 한들 사업이나 업계 자체가 죽어간다면 무용지물이다. 호텔 관련책 2권 정도 읽어야 겠다.

 

04 가장 목하는 사람이 되라 - p37

사람이 집단을 이뤄 오래 일하면 업무 수행 능력에 지속적으로 영향 받을 수 있다.

주변 사람이 자신의 능력에 영향을 준다.

주변 사람을 신중하게 선택하라.

 가장 못하는 사람이 되려고 하면 실제로는 자신을 과소평가하지 않게 된다. 사람들은 A급 밴드에 속할 수도 있지만 항상 B급 밴드에 들어간다. 두렵기 때문이다. 자신이 최고가 아님을 솔직히 인정하면 자신이 최고가 아니라는 사실이 알려지는 데 대한 두려움을 씻어낼 수 있다. 사실은 가장 못하는 사람이 되려고 할 때 실제로는 가장 못하는 사람이 되지 않을 것이다.

개발자에게는 완전 공감되는 말이다. 이래서 좋은 개발자들이 있는 곳에 개발자 공급이 계속 이루어지는 것이다. 전 직장에 있을 때는 업무 시간외에 공부하는 동료 개발자가 많지 않았다. 그나마 몇명있어서 다행이지 안그랬으면 흘러가는대로 그저 대기업 회사원으로 지금 과장 진급에 목매고 있었을 것이다. 현 직장인 야놀자에서 나는 말그대로 가장 못하는 사람이지만 말이다 ㅎㅎㅎ

 

06 부모님 말씀을 듣지 말라 - p45

 직업 세계에 관해 부모님의 관점에 있을 것 같지 않은 또 다른 경력 결정 요소는 직업을 바꿔도 괜찮다(그리고 더 나을 때도 있다)는 점이다. 다재다능한 소프트웨어 전문가는 산업의 다양한 측면, 즉 제품 개발, IT 지원, 내부 비즈니스 시스템 개발, 정부 일을 경험했다. 더 다양한 분야를 알고 더 많은 기술적 아키텍처를 꾸준히 다뤄볼수록 좀 더 어려운 프로젝트에서 옳은 결정을 내릴 준비가 더 된다. 한 회사에 머물며 출세하는 것은 개발자로서 성장하는 데 제한된 환경이다. 전체 경력을 위해 큰 회사에 들어가 자리 잡고 '평생을 바치는 사람'의 시대는 갔다. 이러한 행동이 한때는 헌신의 증표였다. 이제는 골칫거리다. 여러분이 한 회사에서만 일했고 한 시스템만 안다면 많은 (똑똑한) 매니저가 그것을 고용 결정을 하는 데 감점 요소로 볼 것이다. 나라면 일을 하는 한 가지 방법만 아는 사람보다는 서로 다른 환경에서 다양한 성공과 실패를 겪은 사람을 고용할 것이다.

고인 물이 되지말자.

 

07 다재다능한 사람이 되라 - p52

'만물박사치고 제대로 하는 일이 없다'라는 딱지는 보통 경멸적인 표현이다. 그런 딱지가 붙든다는 것은 한 가지 주제에 제대로 뛰어들어 그것을 습득하는 집중력이 부족함을 의미한다. 그러나 온라인 쇼핑 애플리케이션이 고장나서 한 시간마다 수백 명의 주문을 놓치고 있을 때 해결사 노릇을 하는 이는 바로 이런 만물박사다. 만물박사는 애플리케이션 코드가 어떻게 동작하는지 알 뿐 아니라 웹 서버 프로세스의 하위 수준 유닉스 디버깅도 할 줄 안다. 그 외에도 RDBMS 설정을 분석해 잠재적인 성능 병목을 찾아내고 네트워크 라우터 설정을 확인해 발견하기 어려운 문제도 찾아낸다. 그리고 더욱 중요한 것은 문제를 찾아낸 후 만물박사는 아키텍처와 설계에 대한 결정을 빨리 내려 코드를 고치고 새롭게 수정된 시스템을 현장에 배치한다. 이런 시나리오에서 제조업 방식 해결책은 기껏해야 구닥다리일 뿐이고 최악의 경우에는 치명적인 결함만 만들어낸다.

 소프트웨어 공장에서 작업을 나누는 방식은 한 방향으로 일정한 흐름이 유지되는 조립 라인과 달라서 소프트웨어 프로젝트는 대개 순환적이다. 다시 말하면 프로젝트의 실제 흐름이 순환적일 뿐 아니라 프로젝트 내부의 일도 순환적이다. 요구 사항이 정해지고 아키텍처가 만들어지고 설계되는 동안 코더는 의자에 앉아 있거나 많은 프로젝트를 오가며 동시에 여러 가지 일을 한다. 여러 가지 일을 하는 코더의 문제는 소프트웨어 현장의 본래 의도에도 불구하고 실제로 일할 때 이전의 경험과 상황에 매우 의존한다는 것이다. 요구 사항, 아키텍처, 설계 문서가 좋은 출발점일 수 있지만 결국 프로그래머가 시스템이 무엇을 해야 하는지 이해하지 못하면 시스템을 제대로 구현할 수 없다.

 다재다능한 사람이 되려면 특벙한 역할이나 기술에 매여서는 안 된다. 경력으로 해야 할 역할을 정하는 방법은 경력에 따라 다양할 것이다. 다재다능한 사람이 무엇을 의미하는지 구체적으로 알아보기 위해 IT 경력 지형을 다양하고 독립적인 형태로 나눠 보자. 나는 다섯 가지를 생각해냈지만 그 수가 무한할 것이다(개인적으로 주제를 어떻게 나누느냐에 전적으로 달려있다).

• 경력 사다리의 각 단계
• 플랫폼/운영 체제
• 코드 대 데이터
• 시스템 대 애플리케이션
• 사업 대 IT

이것은 다재다능한 사람이 되기 위해 접근할 수 있는 서로 다른 통로다. 이것은 자기 경력의 전체 그림에 비추어 생각하는 방식이다. 그리고 스스로 더 나은 목록을 만들 수도 있을 것이다. 이제 이에 대해 토론해 보자.

 또 다른 인위적(이고 받아들이기 어려운) 경계는 플랫폼 또는 운영 체제다. 윈도를 거부하고 유닉스만 고집하면 점점 쓸모없는 사람이 된다. 닷넷 대 J2EE나 다른 플랫폼도 마찬가지다. 장기근속을 바란다면 직장에서 플랫폼에 대해 중립적이어야 한다. 모두 자기 취향이 있지만 자신의 이상은 잠시 보류해야만 할 것이다. 하나를 습득하고 다른 하나에 능숙해지라. 자신의 기술이 기술 플랫폼을 넘나들어야 한다. 기술은 단지 도구일 뿐이다. 윈도 인력이 필요하면 필리핀에서 채용할 것이다. 하지만 윈도와 유닉스 개발을 제대로 이해하고 두 플랫폼을 통합할 사람이 필요하다면 아마도 선진국 내에서 찾아볼 것이다. 이런 기회를 특정 플랫폼을 좋아하는 마음 때문에 놓치지 말라.

실천하기

종이나 화이트보드에 자신의 지식과 능력 중에 다재다능한 부분과 그렇지 않은 요소를 나열하라. 각 요소에 자신의 특기를 적는다. 예를 들어 플랫폼과 운영 체제가 여러 요소 중 하나라면 그 옆에 윈도/닷넷을 쓰면 된다. 이제 적어 놓은 특기 오른쪽에 '배울 것(To-Learn)' 목록에 넣을 주제를 하나 또는 그 이상 쓰라. 앞에서 든 예를 다시 들면 리눅스와 자바(또는 루비나 펄)을  쓰면 될 것이다.

 되도록 빨리(늦어도 이번 주 중에) 30분을 할애해 목록에 있는 배울 것 항목 중 최소한 하나를 다루기 시작해 본다. 눈으로 보지만 말고 다능하다면 실제로 다뤄 보라. 웹 기술이라면 웹 서버 패키지를 받아 스스로 셋업해 보라. 사업 관련 주제라면 회사 고객을 만나 점심을 같이 먹으면서 대화를 나누라.

이런 유형의 만물 박사가 전직장인 이랜드에서의 내 상사였다. 네트워크, 우주항공, 쇼핑몰 등 다양한 경력을 가지신 분이었고, 쌓은 경험을 바탕으로 남들이 보지 못하는 방식으로 문제를 해결하시곤 했다. 예를 들어 클라우드는 이랜드에서 처음이었지만, AWS 컨설턴트와 사내 클라우드 부서의 의견을 앞질렀던 일화가 많다.

 

08 진정한 전문가가 되라 - p59

 너무 많은 사람이 어떤 분야에 전문가라는 의미가 다른 분야에 대해서는 잘 몰라도 되는 것으로 오해하고 있는 것 같다. 극단적인 예지만, 그렇다면 우리 어머니는 윈도 전문가다. 어머니는 리눅스나 맥 OS X를 쓰지 않기 때문이다. 또 아칸소 주의 시골에 사는 내 친척은 컨트리 음악 전문가라고 할 수 있다. 그 사람들은 다른 음악을 전혀 들어보지 못했기 때문이다.

 그렇다면 소프트웨어 분야에서 전문가는 어떤 사람이어야 할까? 나는 채용 여행에서 구석구석을 뒤지며 자바 프로그래밍과 배치 환경을 깊이 있게 이해하는 사람을 찾고 있었다. 어떤 상황이 닥치더라도 80% 정도는 "그거요, 해봤습니다."라고 말할 수 있고 나머지 20%의 상황에서는 기존 지식의 깊이를 사용해 문제를 처리할 수 있는 사람을 원했다. 상위 수준 추상화를 다루면서 그러한 추상화 구현의 세세한 부분을 이해하는 사람을 원했다. 앞으로 부딪힐 수 있는 배치 묹를 풀 수 있다거나 풀지 못한다면 최소한 도움을 요청할 만한 사람을 아는 사람이 필요했다.

 변화하는 컴퓨터 산업에서 살아남을 전문가는 이런 종류의 사람이다. 닷넷 전문가라는 게 닷넷 이외에 아무것도 몰라도 된다는 이유가 되지 않는다. 닷넷 전문가라는 것은 닷넷과 관계가 있는 일에 권위가 있다는 의미다. IIS(Internet Information Server)가 죽어서 재시동해야 하는지 질문하면 "문제없어요."라고, 비주얼 스튜디오 닷넷(Visual Studio.NET)과 소스 제어 통합에 대해 물으면 "어떻게 하는지 보여줄게요."라고, 모호한 성능 문제 떄문에 플러그를 뽑아버리겠다고 고객이 위협하면 "30분만 주세요."라고 대답할 수 있어야 한다. 위와 같은 의미의 전문가로 자신을 규정짓지 못하면, 자신을 전문가라고 주장하지 않기 바란다.

 

실천하기

컴파일 방식이면서 가상 기계 위에서 동작하는 프로그래밍 언어를 사용하는가? 그렇다면 시간을 들여 가상 기계가 어떻게 동작하는지 내부 구조를 공부해보라. 자바, 닷넷, 스몰토크에 대해 많은 책과 웹 사이트에서 다루고 있다. 생각보다 배우기 쉬울 것이다.

 자신이 사용하는 언어가 가상 기계에 의존하든 그렇지 않든 소스 파일을 컴파일할 때 무슨 일이 일어나는지 시간을 내 공부해 보라. 입력한 코드가 사람이 읽을 수 있는 텍스트에서 컴퓨터가 실행할 수 있는 명령으로 어떻게 바뀌는가? 자신만의 컴파일러를 만드는 것은 무엇을 의미할까?

 외부 라이브러리를 가져오거나 사용할 때 그 라이브러리는 어디에서 오는가? 외부 라이브러리를 가져온다는 것은 실제로 무엇을 의미하는가? 컴파일러, 운영 체제, 가상 기계는 어떻게 여러 조각의 코드를 링크해 일관된 시스템을 만들까? 이 내용을 배우면 기술 선택에서 전문가가 되는 데 몇 걸음 다가설 것이다.

그래 자바 개발자라면, JVM 구조와 그것이 어떻게 동작하는지 잘 이해하는 사람과 그렇지 않은 사람은 천지차이다. JVM 쪽 공부해보자.

 

2부 - 자신에게 투자하라

11 물고기 낚는 법을 배우라 - p 77

여러분을 위해 일할 사람을 뽑으려고 하는데 전문가의 말에 끌려 다니는 사람이 필요할까? 나한테는 필요 없다. 나는 스스로 알아서 할 수 있는(self-sufficient) 사람을 원한다. 

위에서 말했듯이 내 전직장 상사는 전문가의 말에 끌려 다니지 않고 주도하셨다. 이런 사람들이 팀의 확실한 성과를 만들어낸다.

 

3부 - 실행

26 물 양동이 속 자갈

자신만의 성공 때문에

눈이 머는 것을 경계하라.

그 점이 그가 말하려던 것이다. 겸양의 태도를 기르는 것이 단지 정신적으로 좀 더 성숙해지기 위해서만은 아니다. 겸손해지면 자기 행동을 좀 더 명확하게 볼 수 있다. 그 CIO가 가르쳤던 것은 '성공하면 할수록' 치명적인 실수를 저지를 수 있다는 것이다. 모든 게 잘 되면 자기 결정에 의문을 품지 않게 된다. 늘 해오던 방식대로 다 잘 되면 자기 결정에 의문을 품지 않게 된다. 늘 해오던 방식대로 다 잘 되면 더 잘할 수 있는 새로운 방법을 찾지 않을 수 있다. 거만해질 것이고 건방을 떨다 보면 맹점이 생긴다. 아무도 자신을 대신할 수 없다고 생각할수록 누구나 자신을 대신할 수 있게 된다(그럴수록 자신은 점점 더 매력 없는 사람이 될 것이다).

 자신을 대신할 수 없다고 자만하는 것은 나쁜 징조다. 특히 소프트웨어 개발자에게는 더욱 그렇다. 여러분을 대신할 수 없다면 그것은 여러분이 다른 사람이 할 수 없는 방식으로 일을 한다는 것을 의미한다. 우리는 모두 자신을 '특별한 천재'라고 주장하지만 아무리 탁월해도 그를 대신할 수 없는 개발자는 거의 없다.

실천하기

만들었거나 유지보수하는 코드와 수행하는 모든 태스크를 목록으로 만들라. 팀에서 전적으로 자신에게 의존하는 것을 기록한다. 자신이 애플리케이션 배치 프로세스를 완전히 이해하는 유일한 사람일지도 모른다. 또는 자신이 짠 코드 중 일부가 특히 어려워서 나머지 팀원들이 이해하기 힘들 수도 있다.

 이 각각의 항목을 할 일 목록에 적는다. 각각의 코드나 일을 문서로 만들고, 자동화하거나 리팩터링해 팀원 누구나 쉽게 이해할 수 있게 하라. 이 목록이 다 없어질 때까지 이 일을 하라. 팀의 리더, 팀원들과 문서를 적극적으로 공유하라. 문서는 어딘가에 반드시 저장해 팀원들이 쉽게 볼 수 있게 해야 한다. 이 연습을 정기적으로 되풀이하라.

전 직장에서 내가 이랬던 것 같다. 실력있는 상사분도 나가고, 입사 동기와 같이 팀의 기술쪽 업무를 이끌었는데 처음의 부담감이 점점 거만함으로 바뀌었던 것 같다. 그런면에서 이번 야놀자에 도입되었다는 코드 배포 시 개발 내용 및 코드리뷰 자료를 필수로 문서화해놓는 프로세스는 긍정적인 것 같다. 물론 실무자 입장에서 굉장히 귀찮고 속도내기 힘들긴 하지만 말이다... 구글러들이 요직으로 오면서 이런 문화를 도입하는 것 같다.

 

4부 - 마케팅은 높으신 분들만 하는 게 아니다

p182

여러분은 가장 재능 있는 소프트웨어 개발자다. 여러분의 창의력은 마르지 않는 강과 같아 우아한 디자인이 끊임없이 흘러나온다. 아키텍처적 통찰력도 직장에서 최고다. 회사에서 지금까지 고용한 어떤 직원보다 코드를 빠르고 정확하게 짤 수 있다.

 그래서 그게 어떻다는 건가?

 많은 소프트웨어 개발자들, 특히 자만심이 강한 사람들은 실력이란 것이 뭘 좀 아는 관리자나 경영진에게는 그냥 드러나게 마련이라고 오해하며 사는 것 같다. 그런 사람들은 겸손한 척하는 것이 도덕적이라고 생각한다. 너무 '겸손해서' 자기 능력을 팔지 못한다. 능력을 굳이 알리려는 것은 잘 보이려고 '아부'하는 것이라고 생각한다. '그분'에게 잘 보이려고 하는 프로그래머들은 자신의 자긍심을 버린 사람들이라고 생각한다.

 전부 핑계일 뿐이다. 사실 그 사람들은 두려워하는 것이다.

 누군가가 정말 대단한 일을 했는데 아무도 모른다면, 그가 보기에는 아무것도 일어나지 않은 것이다. 잔인하게 들리겠지만 회사의 관점에서는 일리가 있다. 실무적으로 말하자면 관리자에게는 직원들이 각자 매일 뭘 하는지 자세히 확인할 시간이 없다. 그리고 회사나 직원들도 관리자가 자신의 시간을 이런 시시콜콜한 일에 쓰기를 바라지 않을 것이다. 회사는 관리자가 팀원의 일상 업무나 추적하며 시간을 보내기보다는 큰 그림에 초점을 맞추기를 바란다. 그리고 직원(특히 프로그래머) 역시 세세한 점까지 관리 당하는 걸 싫어한다.

 간단히 말하면 역사상 가장 좋은 제품을 갖고 있어도 관고를 하지 않으면 아무도 그것을 사지 않을 것이다. 특히 소프트웨어 세계에서는 최고의 제품이 항상 이기는 것이 아님을 우리는 알고 있다. 뛰어난 제품을 갖고 있지 않아도 시장에서 성공하는 방법은 많다. 인력 시장에서도 이 사실을 잊지 말자.

 자신이라는 상품을 파는 건 겉보기에는 간단하다. 두 가지 목표뿐이다. 자신의 존재를 사람들에게 각인시키는 것, 즉 사람들이 밤을 새고도 풀지 못한 어려운 문제를 풀 수 있는 사람이 바로 자신임을 알려주는 것이다. 이것은 인력 시장에 일반적으로 적용될 뿐 아니라 현재 일하는 회사에서도 적용된다. 회사에 고용됐기 때문에 경영진이 자신을 알 거라고 추측하지 말라. 리더가 여러분의 이름을 알기 때문에 여러분의 능력을 어렴풋하게라도 알리라고 추측하는 것은 더욱 안 된다.

가장 어렵고 손이 많은 작업이 아닐까한다. 나도 한편으로는 겸손한 개발자였고 겸손해서 진짜 겸손한게 아니라 인사 고과철마다 내가 한일을 포장해야 하는 일이 귀찮았다. 다른 할일이 계속 쌓여있었으니까 말이다. 하지만 결국 나라는 상품은 내가 팔아야 하는 것이고, 그때 반짝 잘 정리해놓으면 여러모로 도움이 많이 되긴한다.

 

33 인식이 대수롭지 않다고? - p184

 여러분이 일을 아주 잘하는데 아무도 보지 않으면 정말 일을 잘한 것일까? 누가 신경이나 쓸까? 아무도 안 쓴다.

실천하기

인식은 대상이 누구냐에 따라 여러 요소에 좌우된다. 어머니는 여러분이 객체지향 시스템을 얼마나 잘 설계할 수 있는지 별로 신경 쓰지 않지만 팀 동료는 신경 쓸 것이다.

 각각의 관계에서 무엇이 중욯ㄴ지 이해하는 것은 서로 영향을 주고받는 사이에서 신뢰할 수 있는 인식을 쌓는 데 중요한 부분이다. 사무실에서 사람들과 맺는 서로 다른 유형의 관계에 대해 생각해 보라. 이를테면 같은 일을 하는 동료가 있을 것이다. 직속 관리자가 있고 한 명 이상의 고객과 프로젝트 관리자도 있을 것이다.

 이 서로 다른 집단들을(또는 직장 구조에 실제 적용할 수 있는 아무것이나) 목록으로 만들라. 각 집단 목록 옆에 그 집단에서 여러분의 어떠한 모습을 보고 인식할지 한번 적어보라. 예를 들면 다음과 같다.

집단	인식에 영향을 미치는 요소
동료	기술적 숙련도, 사회 적응도, 팀워크
관리자	지도 능력, 고객 중심, 의사소통 기술, 임무 완수, 팀워크
고객	고객 중심, 의사소통 기술, 임무 완수
프로젝트 관리자	의사소통 기술, 임무 완수, 생산성, 기술적 숙련도

자신의 목록을 보며 잠시 생각해 보라. 이 목록의 결과로 자기 행동을 어떻게 바꾸겠는가? 각 집단과 일할 때, 자신이 집중해야 할 점을 어떤 방식으로 조정했는가? 어떤 방식을 썼을 때 자신의 행동을 적절하게 조정했는가(하지 못했는가)?

직책에 따라 관심사가 다르니 그에 맞게 어필하는 것이 맞다. 직급 높은 관리자라면 안정성이 될 수 있고, 내 동료나 바로 위 팀장이라면 객체지향적 코드 설계와 의사소통이 우선순위일 수 있다. 타게팅해야한다.

 

34 모험 여향 안내자 - p191

고객은 자기가 하는 프로젝트에 대해 편하게 말해줄 사람을 찾으려 한다.

고객은 개발자를 두려워한다.

우리가 이야기하는 이 관리자와 고객들에게는 사소하지만 불편한 비밀이 있다. 고객은 개발자를 두려워한다. 당연하다. 개발자가 똑똑하기 때문이다. 고객 입장에서 개발자는 자신이 이해하지 못하는 신비한 말을 한다. 개발자는 떄떄로 비꼬듯 말해 고객이 스스로가 바보 같다고 느끼게 하기도 한다(비꼬려는 의도가 없었을지도 모른다). 가장 불편한 것은 개발자가 프로젝트 구상과 탄생 사이에서 마지막까지 가장 중요한 위치에 있다는 것이다.

 개발자는 IT 세계라는 까다로운 세계를 여행하는 고객의 안내자다. 개발자는 고객이 낯선 곳을 여행하는 동안 편안하게 안내해야 한다. 개발자는 고객에게 전망을 보여주고 고객이 가고 싶어 하는 곳으로 데리고 다녀야 하지만 자신이 전에 만났던 불편한 곳은 피해야 한다.

 고객은 프로그래머가 아니지만 평균적으로 프로그래머만틈 지적이다(대부분은 그다지 지적이지 않지만 정말 지적인 사람도 있다). 고객이 개발자만틈 똑똑할 가능성이 높다고 하더라도 어떻게 프로그래밍하는지는 알지 못할 것이다. 좋다. 반대로 개발자는 고객이 어떻게 하루 일을 하는지 잘 모를 것이다. 이 떄문에 고객과 개발자가 있는 것이고 같이 일하라고 보수를 받는 것이다.

 소프트웨어 관련 문제를 토론할 때는 고객에게 약간 쉽게 이야기할 필요가 있다. 너무 기술적이지도 너무 우둔하지도 않게, 섬세하게 균형을 잡아야 한다.

 "왜, 고객을 어떻게 배려할지에 대해서만 이야기하는 건가요? 자기를 마케팅하는 방법을 이야기한다고 알고 있었는데요."라고 물을지도 모른다. 전형적인 IT 기업에서 일한다면, 현재의 고용 상태를 계속 유급으로 유지하게 하는 예산의 대부분은 비즈니스로부터 나온다. 즉, 지금의 고객은 그 비즈니스를 하고 있고 그것을 결정하는 데 영향을 끼친다는 말이다. 승진과 인사 결정이 내려질 때 개발자에게 필요한 최고의 후원자는 바로 지금의 고객이다. 이들이 개발자가 생색만 낸다고 생각한다면 어떤 영향이 미칠지 상상해보라. 고객은 비즈니스의 요구를 표현하고 개발자는 그 필요를 충족시키기 위해 돈을 받는다. 이 사실을 잊지 말라.

나는 이런 비개발자와의 소통에 있어서는 나름 강점을 갖는다. 경력을 시작할 때부터 줄곧 타 비개발부서와 소통할 때 최대한 그들이 이해할 수 있는 비즈니스 언어로 소통하려고 노력하였다. 그래서 그런지 그들이 나에게는 보다 긍정적인 태도로 대했다. 언어는 인간의 사고를 지배하고 행동에 영향을 미친다.

 

35 나를 글이 잘 정말 써... - p193

말수가 적은 프로그래머의 시대는 갔다. 회사가 프로그래머들과 의사소통을 하는 데 불편을 겪기를 바란다면 차라리 그들을 다른 대륙, 다른 시간대로 옮겨 놓고 전화와 이메일로만 소통하려 할 것이다. 그건 독자들과 내가 피하고 싶은 것이다.

 따라서 의사소통 문제가 중요하다.

 글을 많이 쓰게 될 것이다. 일 중 많은 것이 글쓰기와 관련 있다면, 당연한 얘기지만 글을 잘 쓰는 것이 못 쓰는 것보다 낫다. 그 어느 때보다 자신에 대한 인식이 글쓰기 능력에 바탕을 두고 형성될 것이다. 뛰어난 코더지만 글로 자신을 잘 표현할 수 없다면 지리적으로 멀리 떨어진 팀에서 유능한 사람으로 인식될 수 없을 것이다.

 글쓰기 능력이 있으면 자신을 잘 인식할 수 있을 뿐 아니라 내적으로는 자신이 어떤 길로 가고 있는지에 대해 진정한 통찰도 생긴다. 다른 사람이 분명하게 이해할 수 있도록 자신의 모국어로 자기 생각을 구성할 수 없는데, 프로그래밍 언어로 그렇게 할 수 있다고 어떻게 기대하겠는가? 논리적 사고 과정을 통해 자신의 구상을 다듬고 독자를 합리적인 결론으로 이끄는 능력은 후임 유지보수자들이 이해할 수 있는 깔끔한 디자인과 시스템 구현을 만드는 능력과 별로 다르지 않다.

 이는 평가에 대한 것만은 아니다. 다른 시간대와 먼 장소에 팀원이 있다면 뭘 했는지, 뭘 어떻게 디자인했는지, 팀원이 뭘 할 필요가 있는지 설명해야만하는 유일한 방법이 바로 글쓰기일지도 모른다.

설명할 수 없으면

아무것도 아니다.

 의사소통, 특히 글쓰기를 통한 의사소통은 모든 훌륭한 아이디어가 반드시 통과해야 하는 병목이다. 설명할 수 없으면 아무것도 아니다.

실천하기

개발 일기를 쓰기 시작하라. 매일 조금씩 쓰면서 뭘 했는지 기록하고, 설계 결정에 대해 타당성을 증명하고 어려운 기술적 또는 전문적 결정을 자세히 조사하라. 자기 자신만 보는 것이라 하더라도 자신의 입장을 분명하게 표현할 수 있도록 작문 품질과 능력 향상에 주의를 기울이라. 이따금 옛 글을 다시 읽고 비평해보라. 옛 글에서 좋았던 것과 나빴던 것을 바탕으로 새 글을 수정하라. 이 일기를 쓰면서 글쓰기가 개선될 뿐 아니라 자신이 내린 결정을 좀 더 잘 이해하는 데 이용할 수 있다. 또 과거에 어떤 일을 왜, 어떻게 했는지 다시 봐야할 필요가 있을 떄 참고할 수도 있다.

맞는 말이다. 글을 잘쓴다는 것은 자신의 머릿속에 있는 무형의 창작물을 글이라는 매개체를 통해 다른 사람이 알아듣기 쉽게 정리한다는 것이다. 글을 중언부언 쓰는 사람은 정리안된 코드를 작성할 가능성이 크다.

 

38 세상을 바꾸라 - p204

직장 사람들이 여러분이 없는 자리에서 여러분에 대해 물을 수 있는 최악의 질문은 "그 사람은 뭘 하나요?"다. 이런 질문을 하는 것은 직장 사람들이 여러분이 뭘 하고 있는지 모른다는 뜻이다.

 고임금 국가에서 소프트웨어 개발자가 되고 싶다면 사명감을 가지고 일해야 한다. 여러분이 변화를 가져와야 한다. 자신의 변화나 일의 변화가 아니다(그것은 주어지는 것이다). 팀이나 조직, 회사에 눈에 보이는 변화를 가져와야한다.

 변화가 작을지도 모른다. 여러분이 단위 테스트 운동을 일으켜 회사 내 프로그래머들의 중심에 단위 테스트 관례를 가져올 수도 있다. 더 나아가 더 큰 변화일지도 모른다. 예를 들어 급진적인 새 기술을 도입해 더 싸고 나은 시스템을 더 빨리 만드는 것이다.

 이런 일들을 하는 것은 자신의 내면에서 무언가가 강하게 이끌기 때문이다. 여러분은 사람들이 일을 잘못하는 것을 두고 볼 수 없다. 일을 더 낫게 하는 걸 알기에 바꿔야만 한다.

신입사원일 때 전직장에서 부서장이 내가 뭘하는지 물었다는 걸 피드백을 받은 적이 있다. 매일 야근하고 많은 일을 하고 있었음에도 불구하고 말이다. 어쩔수 없다 더 나대면서 일하는 것도 나쁘진 않은 선택이다. 다만 나댄 뒤에는 결과가 확실히 있어야 한다.

 

42 주목받는 남다른 능력 - p220

 마케팅 대가 세스 고딘(Seth Godin)은 그의 책 Purple Cow(보랏빛 소가 온다 - 남수영 옮김)에서 소비자들이 제품에 주목하게 하는 가장 좋은 방법은 제품을 남다르게 만드는 것이라고 주장한다. 고딘은 전통적인 4P는 쓸모없어지고 소비자들은 뿌리고 기도하기(spray-and-pray) 식의 낡은 대량 마케팅 전략에 무감각해졌다고 말하기까지 한다. 그래서 고딘은 군중 속에서 두드러지는 유일한 방법은 정말로 남다르게 걸출해지는 것이라고 말한다.

 자, 여기에서 냉소적인 독자들은 박수 갈채를 보내기 시작한다. 알아들을 수 없는 마케팅 용어는 남다른 능력에 비하면 아무것도 아니라고 말이다. 그런데 "내가 그렇게 말했잖아요"라고 하기 전에 '남다른(remarkable)'이란 말의 정의를 이야기해야만 한다.

 남다르다는 것이 절대적으로 좋다는 의미는 아니다. 보통 남다른 제품은 좋다. 그렇다고 좋은 제품이 모두 남다르지는 않다. 남다르다는 것은 주목할 만한 가치가 있음을 의미한다. 다른 소프트웨어 개발자보다 단순히 더 나은 것만으로는 비범한 소프트웨어 개발자가 될 수 없을 것이다. 다른 사람보다 조금씩 더 나아지는 것은 자신의 이름을 퍼뜨릴 만큼 인상적이지 않다. 누군가 여러분에 대해 물어본다는 것은 여러분이 빛나는 성적표를 갖고 있다는 것일 수 있다. 그러나 '남다르다는 것'은 누가 물어보기 전에 사람들이 먼저 여러분에 대해 이야기하는 것을 의미한다.

 남달라지려면 주변 것들과는 크게 달라야 한다. 이 장에서 논의한 여러 가지 자가 마케팅 전략은 남달라지기 위한 것이다. 성공적인 오픈 소스 소프트웨어 발표, 책과 기사 쓰기, 컨퍼런스에서 발표하기를 통해 더욱 남달라질 수 있을 것이다.

보여주느냐 아니면 죽느냐,

그것이 문제로다...

 바로 전 문장을 보면 총망라한 목록은 아니지만 잠재적으로 남달라질 수 있게 할 만한 항목에 중요한 뭔가가 포함되어 있음을 알아챘을 것이다. 가장 똑똑하거나 빠른 사람이 되는 것으로는 충분치 않다. 실행해내야 한다.

 고딘은 '보랏빛 소'라는 문구를 이용해 남달라지려면 무엇을 해야 하는지 일깨운다. '가장 좋은 소'나 '우유를 가장 많이 짜내는 소'나 '가장 예쁜 소'가 아니다. '보랏빛 소'는 그런 무리중에서 두드러진다. 그 무리를 봤을 때 얘깃거리가 될 만한 것은 보랏빛 소다.

 자신과 자신의 성과를 보랏빛 소처럼 만들기 위해 무엇을 할 수 있을까? 주제를 습득하는 데서 그치지 말고 그것에 관한 책을 쓰라. 1주일짜리 프로세스였던 것을 5분짜리 프로세스로 줄이는 코드 생성기를 짜라. 동료 사이에서 존경받으려 하기보다는 자신이 집중하는 기술에 대한 세미나와 연수를 통해 도시에서 가장 알려진 권위 있는 개발자가 되라. 다음 프로젝트에서 전에는 생각지도 못했던 것을 하라.

 그저 무리 속의 최고가 되란 말이 아니다. 사람들이 여러분의 '남다름'에 대해 말할 수 밖에 없도록 하라.

실천하기

현재 프로젝트나 업무에서 작지만 남다른 무언가를 시도해 보라. 실험해 보는 한 방법은 남다른 생산성을 목표로 하는 것이다. 프로젝트 일정에는 여분이 많을 때가 있다. 모두 1주일 걸린다고 생각하는 일을 찾아 하루에 해내라. 필요하면 초과 근무를 해도 된다. 초과 근무하는 버릇을 들일 필요는 없지만 이것은 실험이다. 눈에 띄게 짧은 시간에 일을 해내라. 사람들이 '남다르다고' 느끼는지 보라. 그렇지 않다면 왜일까? 그렇다면 어떤 식으로 그렇게 됐나? 변수를 미세하게 조정해 다시 시도해 보라.

현직장 부서장의 가치관과 비슷한 것 같다. 정말 두드러지는 성과를 내는 것이 조직내에서 성공하는 가장 확실한 방법인 것 같다. 조직 내부 뿐만아니라 이직이 보편화된 요즘 같은 세상에서는 외부의 좋은 자리로까지 가기 마련이다.

 

5부 - 자신의 강점을 유지보수하라

44 이미 구식 - p234

우리는 모두 컴퓨팅 능력이 18개월마다 두 배가 된다는 무어의 법칙(Moore's law)을 알고 있다. 수치가 정확히 맞든 안 맞든, 1965년 인텔의 고든 무어(Gordon Moore)가 이 주장을 했을 때와 비슷한 비율로 기술이 여전히 진보한다는 것을 쉽게 알 수 있다. 그리고 하드웨어 성능이 이렇게 진보하면서 소프트웨어로 할 수 있는 일들도 발전하고 있다.

 컴퓨팅 능력이 두 배가 된다. 기술이 매우 빠르게 발전하면서 사람이 쫓아 갈 수 없을 정도로 너무 많은 일이 생긴다. 자기 기술이 현재 유행 중인 것이라 해도 차세대 대박 기술을 배우는 과정을 제대로 쫓아가지 못하면 너무 늦다. 지금은 앞서 나가고 있더라도 다음에는 뒤쳐질 수 있다. 이와 같은 환경에서는 타이밍이 중요하다.

 오늘날의 흐름에서는 첨단에 있더라도 다음에는 뒤에 있을지도 모른다는 사실을 깨닫는 것으로 시작해야 한다. 타이밍을 잡는 것이 중요하다. 배움에 있어 앞을 내다보고 생각하라. 지금은 불가능하지만 2년 안에 무엇이 가능할껏인가? 하드 드라이버가 너무 싸 사실상 공짜나 다름없다면 어떨까? 프로세서가 두 배나 빠르다면 어떨까? 최적화에 대해 걱정할 필요가 없다면 어떨까? 이러한 선도적인 발전이 앞으로 대성공을 거둘까?

 그렇다. 어느 정도는 도박이다. 그렇다고 하지 않으면 확실히 지는 게임이다. 최악의 경우 가치가 높은 뭔가를 배웠는데도 2년 동안 자신의 일에 직접 적용하지 못할 수 있다. 그래도 장래를 보고 이 도박 같은 모험을 하는 편이 낫다. 가장 좋은 경우는 첨단 기술 분야에서 전문가로 계속 앞서나가는 것이다.

 앞을 내다보고 실력 계발을 확실히 하는 것으로 이상을 꿈꾸는 사람과 맹목적인 사람의 차이가 무엇인지 알 수 있다.

아쉽게도 아무것도 안하는 개발자들이 많다. 빅테크 기업에서는 개발 문화가 어느정도 있으니 뭐라도 해야할 것 같은 분위기라 마지 못해서라도 하는 경우가 있지만, 그 외 기업에서는 그냥 흘러가는 대로 업무만 하기 바쁘다. 뭐라도 배우려고 하는 개발자는 다르다. 당장은 쓸데없는 기술을 배우고 있다던가 삽질만 해대는 사이드 프로젝트를 하더라도 거기서 습득된 인사이트가 업무에 녹아져 있고 더 잘한다는 소리를 듣는다.

 

46 목적 없는 길 - p240

코드를 전달할 때 미듭짓기는 쉽다. 고객은 웹 애플리케이션을 필요로 하고, 여러분은 그 애플리케이션을 끝내는 데 집중하기만 하면 된다. 그러나 애플리케이션이 계속 동작하는 한 결코 '끝나지' 않는다. 하나를 발표하면 그 다음에 해야 할 일이 계속 생긴다. 최종 제품에만 너무 집중하면 정말 전달해야 할 것, 즉 새로운 것을 지속적으로 개발해야 하는 것에서 멀어진다.

결과가 아닌 과정에 집중하라.

결과에 집중하다 보면 과정을 개선하는 데 게을러질 수 있다. 사실 과정이 나쁘면 나쁜 제품을 만들어낸다. 제품이 최소 요구 사항을 충족했는지 모르지만 그 속은 추할 것이다. 단기 목표만 최적화했지, 필연적으로 계속될 제품 개발의 미래는 최적화하지 않은 것이다.

 나쁜 과정이 나쁜 제품을 만들 뿐 아니라 나쁜 제품이 나쁜 과정을 만든다. 제품 중 하나가 속이 엉망이더라도 과정은 그에 맞춰진다. 제품의 '깨진 창문'이 과정에서도 깨진 창문을 만들어 낸다. 악순환이다.

 따라서 "아직 안 됐나요? 아직 안 됐어요?"라고 계속해서 물을 때, "아직, 안 됐습니다."라고 대답하는 것만이 올바른 태도임을 깨달으라. 중요한 것은 길을 가는 과정이지, 목적지가 아니다.

당장 돌아가게 하려고 구멍 난 옷에 패치 붙이듯이 대충 때우면 결국 나중에 일이 많이 생기기 마련이다. 코딩하는 것은 정말 과정 그 자체라고 할 수 있다. 남에게 보이진 않지만 조금이라도 나은 코드나 아키텍처를 만들기 위한 고민은 결국 빛을 발한다.