코딩을 배워 개발자로 취업하는 방법 2023년

Original article: How to Learn to Code and Get a Developer Job [Full Book]

번역/감수

Minhyae Kim
Soomin Kim
Seunghyun Kim
Yeonhee Kim
Chaeyoon Kim
Hyojin Kim
Jiyoon Park
Younghyun Bae
Soojung Yoon
Yeon Yoon
Hanseul Lee
JungHoon Lee
Jihyo Jeon

코딩을 배워 개발자로 취업하고 싶다면 제대로 찾아오셨습니다. 이 책이 그 방법을 알려줄 것입니다.

이 웹페이지에서 무료로 책 전체를 볼 수 있습니다.

몇 년 전, 뉴욕의 5대 출판사 중 한 곳에서 책 계약에 대해 연락이 왔습니다. 그들과 만났지만 책을 쓸 시간이 없었죠.

다행히 드디어 시간이 생겼습니다. 그리고 이 책을 바로 여기, freeCodeCamp에서 무료로 출판하기로 했습니다.

정보는 무료여야 하잖아요, 그렇죠? 🙂

이 모든 내용을 읽는 데 몇 시간이 걸릴 수도 있습니다. 그러나 이것이 전부입니다. 코딩을 배우고 개발자로 취직하기 위한 저의 모든 통찰력 말이죠.

저는 이 모든 것을

• 30대에 코딩을 배우고
• 소프트웨어 엔지니어로 일하고
• 지난 8년 동안 freeCodeCamp.org를 운영하면서 배웠습니다.
  오늘날에는 매일 수백만 명의 사람들이 수학, 프로그래밍, 컴퓨터 과학에 대해 배우기 위해 이 웹사이트를 방문합니다.

저는 프로그래밍을 해본 적이 없는 영어 선생님이었습니다. 그리고 1년 만에 첫 소프트웨어 개발자로 직업을 얻기에 충분한 코딩 실력을 갖출 수 있었습니다.

책이나 강좌에 돈을 들이지 않고도 말이죠.

(물론 인근 도시를 여행하고 기술 이벤트에 참가하는 데 돈을 썼지만요. 이 책의 뒷부분에서 볼 수 있듯이 이것은 잘 쓴 돈이었습니다.)

몇 년 동안 소프트웨어 엔지니어로 일한 후, 저는 준비가 되었다고 느꼈습니다. 저는 다른 사람들에게도 이러한 직업 전환 방법을 가르치고 싶었습니다.

아무도 관심을 두지 않는 기술 교육 도구를 몇 개 만들었습니다. 그러던 어느 주말, 저는 freeCodeCamp.org를 만들었습니다. 활기찬 커뮤니티가 빠르게 만들어졌습니다.
그 과정에서 우리는 모두 서로를 도왔습니다. 그리고 오늘날 전 세계 사람들이 기술 분야에서 첫 직업을 준비하는 데 freeCodeCamp를 사용하고 있습니다.

이 책을 다 읽을 시간이 있을지 모르겠다고 생각할 수도 있습니다.

걱정하지 마세요. 북마크에 추가하면 됩니다. 필요한 만큼 몇 번이고 다시 돌아와서 읽을 수 있습니다.

그리고 소셜 미디어에 공유할 수도 있습니다. 공유하세요. "내가 읽고 있는 이 책을 확인해 보세요"라고 말하며 첨부하는 것은 책을 다 읽도록 스스로를 설득하는 놀랍도록 효과적인 방법입니다.

제가 이 말을 하는 이유는 이 책을 팔려고 하는 것이 아니기 때문입니다. 이 웹페이지를 열었을 때 이미 이 책을 '구매'하셨으니까요. 이제 제 목표는 이 책이 여러분의 부족한 시간을 투자할 만한 가치가 있다는 확신을 드리는 것입니다. 😉

여러분의 시간을 존중할 것을 약속드립니다. 여기에는 과대광고나 장황한 설명이 없으며 직설적이고 실행 가능한 팁만 있습니다.

이 책의 모든 장에 최대한 많은 인사이트를 담으려고 노력했습니다.

그러고 보니 목차는 어디에 있나요?

아. 여기 있습니다.

목차

1. 서문: 이 책은 누구를 위한 책인가요?
2. 500단어 요약
3. 1장: 실력을 쌓는 방법
4. 2장: 인맥을 쌓는 방법
5. 3장: 평판을 쌓는 방법
6. 4장: 코딩으로 돈 버는 방법 - 프리랜서로서 고객 유치와 구직 활동
7. 5장: 개발자로서 첫 직장에서 성공하는 방법
8. 에필로그: 할 수 있습니다

서문: 이 책은 누구를 위한 책인가요?

이 책은 소프트웨어 개발 분야에서 경력을 쌓고자 하는 모든 사람을 위한 책입니다.

유연하고 보수가 높으며 창의적인 문제 해결을 많이 하는 직업을 찾고 있다면 소프트웨어 개발이 적합할 수 있습니다.

물론 우리는 각자의 '시간', '비용', '기회' 라는 자원을 가지고 코딩 여정을 시작합니다.

여러분은 아마 나이가 많거나 돌봐야 할 자녀나 연로한 친척이 있을 수도 있습니다. 따라서 '시간' 이 부족할 수 있습니다.

어쩌면 나이가 어려 저축하거나 수입을 늘리는 능력을 습득할 시간이 적었을 수도 있습니다. 따라서 '돈' 이 부족할 수 있습니다.

샌프란시스코, 베를린, 도쿄, 벵갈루루와 같은 주요 기술 도시에서 멀리 떨어진 곳에 살고 있을 수도 있습니다.

신체적 또는 정신적 장애를 안고 살아갈 수도 있습니다. 나이 차별, 인종 차별, 성차별은 현실입니다. 이민 신분이 구직 활동을 복잡하게 만들 수 있습니다. 범죄 기록도 마찬가지입니다.

따라서 '기회' 가 줄어들 수 있습니다.

코딩을 배우고 개발자가 되는 것이 어떤 사람에게는 남들보다 더 어려울 수 있습니다. 모든 사람은 각자의 출발점에서 자신이 가진 자원을 가지고 이 도전을 시작합니다.

하지만 시간, 비용, 기회 등을 어떤 출발점에서 갖고 시작하든 실행 가능한 조언을 드리기 위해 최선을 다하겠습니다.

다시 말해, 여러분은 제대로 찾아오셨습니다.

용어에 대한 간단한 참고 사항

새로운 용어를 사용할 때마다 그 의미를 정의하기 위해 최선을 다하겠습니다.

하지만 제가 항상 사용하게 될 몇 가지 용어가 있습니다.

'프로그래밍'과 '코딩'이라는 단어를 같은 의미로 사용하겠습니다.

'앱'이라는 단어는 휴대폰, 노트북, 게임 콘솔 또는 냉장고에서 실행되는 모든 종류의 애플리케이션을 통칭하는 약어로 사용하겠습니다. (죄송합니다, 스티브 잡스. iPhone은 앱이라는 단어를 독점하고 있지 않습니다.)

또한 '소프트웨어 엔지니어'와 '소프트웨어 개발자'라는 단어를 같은 의미로 사용하겠습니다.

이에 대해 문제를 제기하는 기술 업계 분들을 만날 수도 있습니다. 마치 소프트웨어 엔지니어링이 기계 공학이나 토목 공학처럼 몇 세기에 걸쳐 유산을 이어온 멋진 분야인 것처럼 말입니다. 아마 여러분의 손자 손녀들에게는 사실이 될지도 모릅니다. 하지만 우리는 아직 소프트웨어 개발의 초기 단계에 있습니다.

여기 인용문 하나만 소개해 드리겠습니다.

"건축업자가 프로그래머가 프로그램을 작성하는 방식으로 건물을 짓는다면, 최초의 딱따구리는 문명을 파괴할 것입니다."
- 제럴드 와인버그(Gerald Weinberg), 프로그래머, 작가, 대학교수

누구나 코딩을 배울 수 있나요?

물론이죠. 충분한 동기를 가진 사람이라면 누구나 코딩을 배울 수 있다고 생각합니다. 결국 코딩을 배우는 것은 동기 부여의 문제이지 적성의 문제가 아닙니다.

초기 인류가 유럽, 아시아, 아메리카로 퍼져나가기 전 수천 년 동안 살았던 아프리카의 사바나에도 컴퓨터가 있었을까요?

수천 년 동안 프로그래밍 기술은 결코 선택의 대상이 아니었습니다. 우리가 알고 있는 컴퓨터(데스크톱, 노트북, 스마트폰)는 80년대, 90년대, 00년대에 등장했습니다.

물론 적성과 흥미가 중요한 역할을 한다고 생각합니다. 하지만 결국 전문적인 개발자가 되고자 하는 사람은 누구나 키보드 앞에서 시간을 투자해야 합니다.

코딩을 배우려고 시도하는 대다수는 좌절하고 포기할 것입니다.

저도 그랬습니다. 여러 번 좌절하고 포기했죠.

하지만 결국 성공한 다른 사람들처럼 저도 며칠 후 다시 돌아와 계속해서 시도했습니다.

제가 이 모든 이야기를 하는 이유는 코딩을 배우고 개발자로 취업이 어렵다는 것을 인정하고 싶기 때문입니다. 그리고 어떤 사람들에게는 상황 때문에 남들보다 훨씬 더 어렵게 느껴질 수도 있습니다.

저는 코딩을 배우면서 진정한 역경에 직면한 척하지 않겠습니다. 저는 30대였고, 프로그래밍이나 컴퓨터 과학에 대한 배경지식이 없었습니다. 하지만 이 점을 생각해 보세요.

저는 미국에서 중산층으로 자랐고, 영어를 사용하는 가정에서 미국인 4세대로 자랐습니다. 저는 대학에 다녔습니다. 저의 아버지도 대학을 다녔습니다. 그리고 아버지의 아버지도 대학을 다녔습니다. (그의 부모님은 스웨덴에서 농사를 짓는 농부였습니다.)

저는 일종의 세대 간 특권의 혜택을 누렸습니다. 전쟁이나 기근, 노예제 등으로 가족들이 찢겨나가지 않았을 때 시간이 지나면서 회복할 수 있는 추진력이죠.

이것은 제가 여러분에게 드리는 경고입니다. 저는 여러분에게 역경을 극복할 수 있도록 동기 부여하는 인물이 아닙니다.

개발자 커뮤니티에는 실제 역경을 극복한 수많은 사람이 있습니다. 여러분이 그들의 가르침을 찾고 싶다면 책 뒷부분에서 그런 사람들을 언급할 것입니다.

저는 소프트웨어 개발 분야를 찬양하려는 것이 아닙니다. 코딩을 배우면 일어날 수 있는 공상 과학 소설 속 유토피아를 그리려고 하는 것도 아닙니다.

대신 이러한 기술을 습득하는 방법에 대한 실용적인 팁을 알려드리겠습니다. 그리고 어떻게 하면 좋은 직장에 취직하고 가족을 부양할 수 있는지 알려드리겠습니다.

안정된 좋은 직업을 원하기 때문에 코딩을 배우는 것이 잘못된 것은 아닙니다.

창업을 위해 코딩을 배우는 것은 잘못된 것이 아닙니다.

어쩌면 코딩에 대한 열정이 너무 커서 코딩에 대한 꿈을 꿔야 한다고 말하는 사람들을 만나게 될 수도 있습니다. 퇴근한 후 주말 내내 오픈소스 프로젝트에 기여하며 시간을 보내는 사람들이요.

저도 코딩에 '그 정도'의 열정을 가진 사람들을 알고 있습니다. 하지만 힘든 한 주간의 업무를 마친 후 자연 속에서 시간을 보내거나 친구들과 보드게임을 하고 싶어 하는 사람들도 많이 알고 있습니다.

사람들은 일반적으로 자신이 잘하는 일을 하는 것을 좋아합니다. 그리고 코딩을 더 잘하는 것만으로도 코딩에 대한 적당한 수준의 열정을 키울 수 있습니다.

즉, 이 책은 누구를 위한 책인지 궁금하신가요? 코딩을 더 잘하고 싶고 개발자로 일하고 싶은 사람 모두에게 추천합니다. 바로 그거예요.

자칭 '괴짜', 내향적인 사람, 이념에 사로잡힌 활동가일 필요는 없습니다. 그런 고정관념도 필요 없습니다.

그런 분도 괜찮습니다. 하지만 꼭 그럴 필요는 없습니다.

여러분이 코딩을 잘해서 돈을 벌고 싶을 만큼 잘 배우고 싶다면 이 책이 적합합니다.

먼저 이 책의 간략한 요약부터 읽어보세요. 그런 다음 나머지 부분을 읽어보세요.

500 단어 요약

코딩을 배우는 것은 어렵습니다. 소프트웨어 개발자로서 일을 구하는 것은 그보다 더 어렵습니다. 하지만 많은 사람에게 그것은 분명 노력할 가치가 있는 일입니다.

코딩은 고임금, 지적인 도전, 창의적인 보람이 주어지는 분야입니다. 시니어 개발자, 테크 리드, 엔지니어링 매니저, CTO 그리고 어쩌면 CEO까지 확실한 커리어가 여러분을 기다리고 있습니다.

거의 모든 분야에서 일자리를 찾을 수 있습니다. 개발자 일자리의 3분의 2가 농업, 제조, 정부, 은행이나 헬스케어 같은 서비스 산업처럼 우리가 전통적으로 '기술'이라고 부르는 분야 밖에 존재합니다.

만약 당신의 직업이 은퇴 전에 자동화될까 봐 두렵다면, 코딩이 사물을 자동화하는 행위라는걸 생각해보세요. 코딩은 완전히 자동화되는 마지막 직업이라고 할 수 있습니다.

제가 코딩이 좋은 직업이라고 여러분을 잘 설득했나요? 그렇다면 여기 업계에 뛰어들기 위해 필요한 것들이 있습니다.

실력을 쌓으세요

여러분이 배워야 할 것 :

• 프론트엔드 : HTML, CSS, JavaScript
• 백엔드 : SQL, Git, Linux, 웹 서버
• 컴퓨터 공학 : Python과 다양한 라이브러리들

이들 모두 20년 이상 된 성숙한 기술들입니다. 여러분이 어느 회사에서 근무하든 대부분 위 기술들을 사용하게 될 것입니다.

이런 기술을 배우는 가장 좋은 방법은 직접 프로젝트를 만들어 보는 것입니다. 매일 최소한 몇 줄이라도 코딩해보세요. freeCodeCamp 커리큘럼을 처음부터 끝까지 따라가다 보면 기술에 대해 배울 수 있는 건 물론이고 수십 개의 프로젝트를 만들 수 있게 될 것입니다.

freeCodeCamp 핵심 커리큘럼 내 일부 과정들

인맥을 쌓으세요

취업에 있어 중요한 것은 당신이 누구를 알고 있느냐입니다.

내성적이라도 괜찮아요. 하지만 여러분의 경계를 넓힐 필요가 있습니다.

GitHub, Twitter, LinkedIn 그리고 Discord 계정을 만드세요.

개발자 모임과 컨퍼런스에 참여해보세요. 필요하다면 여행도 가보세요. ('코딩 배우기'에 들어가는 예산의 대부분은 책이나 강의 수강이 아닌 여행이나 행사 티켓에 쓰여야 합니다.)

홀로 서 있는 사람들에게 말을 걸어보세요. 대화는 다른 사람들이 하도록 두고 이야기를 경청해보세요. 사람들의 이름을 기억하세요.

LinkedIn에서 사람들을 추가하고 그들의 트위터 계정을 팔로우하세요. 그리고 뒤풀이에 나가는거에요.

평판을 쌓으세요

여러분이 만들고 있는 프로젝트의 짧은 데모 영상을 공유하세요.

점점 더 큰 규모의 컨퍼런스에 연사로 지원해보세요.

해커스페이스(*Hackerspace : 비슷한 관심사를 가진 사람들이 모여 프로젝트를 함께하거나 지식이나 아이디어를 나누는 공간 또는 시설을 뜻합니다. --옮긴이)에서 어울리면서 코딩을 처음 시작한 사람들을 도와주세요.

오픈소스에 기여해보세요. 오픈소스에 기여하는 일은 현업 개발자가 하는 일과 매우 비슷합니다.

앞서 말한 세 가지를 동시에 해보세요. 가장 두려운 일을 미루지 마세요.

직접적으로 구직을 하는 대신 네트워크를 활용해 면접 기회를 잡으세요. 채용담당자도 도움을 줄 수 있을 거에요.

취업 제안을 받을 때까지 계속 면접에 응하세요. 꼭 첫 번째 합격한 회사에 갈 필요는 없습니다. 인내심을 가지세요.

여러분이 개발자로서 다니는 첫 번째 직장이 가장 힘들 겁니다. 최소한 2년은 그곳에서 버티세요. 그리고 돈을 받으면서 배우는거에요.

진정한 배움은 여러분이 팀과 함께 대규모 레거시 코드를 다루면서 시작됩니다.

가장 중요한 것은 수면과 운동입니다.

동기가 충분한 사람이라면 누구나 개발자로 일할만큼 코딩을 배울 수 있습니다. 그저 얼마나 간절히 원하고, 얼마나 끈질기게 구직 활동을 할 수 있는가에 대한 문제일 뿐입니다.

기억하세요, 여러분은 할 수 있습니다.

이 책은 전 세계의 freeCodeCamp 커뮤니티를 위한 책입니다.

지난 8년 동안 우리 자선단체와 사명을 지지해주신 모든 분들께 감사드립니다.

여러분의 봉사와 박애 정신 덕분에 수많은 사람이 코딩을 배우고 개발자로서 첫 취업 하는 데 도움을 줄 수 있었습니다.

커뮤니티는 제가 2014년에 처음 배포한 작은 오픈소스 프로젝트에서 많은 성장을 이루었습니다. 저는 이제 이 글로벌 커뮤니티의 작은 부분에 지나지 않습니다.

여러분들과 함께 일할 수 있어 영광입니다. 우리는 정보와 교육에 대한 접근성, 그리고 미래를 만들어가는 도구에 대한 접근성과 같은 이 시대의 근본적인 문제점을 직면하고 있습니다.

아직은 초기 단계에 불과합니다. 제 생애 모든 사람이 코딩하는 법을 알게 될 것이라는 환상을 가지고 있는 것은 아닙니다. 하지만 우리는 1455년 구텐베르크 성경이 문맹 퇴치를 가속했듯, 무료 공개 학습자료들을 통해 기술 문맹 퇴치를 가속할 수 있습니다.

다시 한번 여러분께 감사드립니다.

그리고 편집 피드백을 제공해주신 Abbey Rennemeyer와 책 표지 디자인해 주신 Estefania Cassingena Navone에게 특별히 감사드립니다.

그리고 이제, 책입니다.

1장: 실력을 쌓는 방법

"모든 예술가는 처음에는 아마추어였다." - Ralph Waldo Emerson

코딩을 배우기 위한 길은 멀고도 험난합니다.

저에게는 애매모호한 길이었지만, 여러분한테까지 그럴 필요는 없습니다.

이 장에서는 코딩을 최대한 원활하게 배울 수 있는 몇 가지 전략을 공유하려고 합니다.

2011년에 어떻게 코딩을 배웠는지 알려드린 다음, 이 과정에서 제가 배운 것을 공유하겠습니다.

제가 했던 것보다 훨씬 더 효율적으로 배울 수 있는 방법을 보여드릴 거예요.

Story Time: 30대 교사는 어떻게 스스로 코딩을 배웠을까요?

저는 영어 학원을 운영하는 교사였습니다. 전 세계에서 캘리포니아로 온 100여 명의 성인 학생들은 대학원에 진학하기 위해 고급 영어를 배우고 있었습니다.

선생님들이 싫어하는 것은 출석 보고서, 성적표, 이민 서류와 같은 서류 작업이었습니다. 그리고 저는 선생님들이 학생들과 더 많은 시간을 보낼 수 있기를 바랐습니다. 그리고 서류 작업으로 책상에 묶여 있는 시간을 줄이고 싶었습니다.

하지만 제가 컴퓨터에 대해 아는 것은 극히 적었습니다.

프로그래밍은요? 똑똑해야만 할 수 있는 것 아닌가요? 와이파이 라우터 설정도 겨우 했고, 수학에도 젬병이었죠.

그러던 어느 날 모든 것을 제쳐두고 생각했어요. "자, 일단 해보자고. 잃을 게 뭐가 있겠어?"

'웹 사이트를 자동으로 클릭하는 방법', '웹 사이트에서 엑셀로 데이터를 가져오는 방법'과 같은 질문을 검색하기 시작했습니다.

당시에는 뭐가 뭔지 몰랐지만 워크플로우를 자동화하는 방법을 배우고 있기도 했네요.

학습이 시작된 것이죠. 엑셀 매크로를 사용하고, 마우스를 화면상의 특정 좌표로 이동시키고, 클릭한 후, 텍스트를 복사하여 다른 좌표로 이동시킨 것을 붙여넣도록 프로그래밍할 수 있는 AutoHotKey라는 도구를 사용했습니다.

어둠 속에서 헤맨 몇 주 동안 몇 가지 작업을 자동화하는 방법을 알아냈습니다. 엑셀 스프레드시트와 웹 사이트를 열어 스크립트를 실행합니다. 10분 후에 다시 돌아오면 스프레드시트가 완전히 채워져 있는 것이죠.

아마추어의 작업이고, 개발자들은 '더티 핵'이라고 부를 수도 있겠습니다만, 어찌 됐든 작업을 완료했습니다.

새로 배운 자동화 기술을 사용하여 학원를 계속 간소화시켰더니 교사들은 컴퓨터를 거의 만질 필요가 없어졌습니다. 저는 초보적인 기술만으로 여러 교사의 업무를 처리하고 있던 것이죠.

이는 학원에 눈에 띄는 영향을 미쳤습니다. 그동안 많은 시간을 컴퓨터의 암기식 작업에 묶여 있었거든요. 이제 우리는 자유로워졌습니다.

선생님들이 더 행복해졌고, 학생들과 더 많은 시간을 보냈죠.

학생들도 더 행복해졌고, 고국에 있는 모든 친구들에게 "이 학교를 꼭 가봐야 한다"고 말했죠.

곧 우리는 전체 학원 시스템에서 가장 성공적인 학원 중 하나가 되었습니다.

더욱 용기를 얻었습니다. 혼자서 생각했던 기억이 납니다. "아마 나도 코딩을 배울 수 있겠구나"라고요.

저는 보드게임 모임을 통해 몇몇 소프트웨어 엔지니어를 알게 되었습니다.
그들은 캘리포니아 공과대학교, 하비 머드, 그리고 다른 유명한 컴퓨터 공학 학위를 소유한 전형적인 개발자의 배경을 가지고 있습니다.

그 당시에는 30대가 코딩을 배우는 것이 지금보다 훨씬 흔하지 않았습니다.
저는 이 친구들과 같은 꿈을 꾸기 위해 용기를 내었습니다.

저는 제대로 프로그래밍하는 방법을 배우고 싶었습니다. 저는 그들처럼 개발자로서 코드를 작성하여 돈을 벌 수 있기를 바랐습니다.
그리고 어쩌면 학교에 도움이 되는 소프트웨어를 만들 수도 있습니다.

저는 이 꿈들을 제 개발자 친구들에게 이야기했습니다. "저도 개발하고 싶어요."

하지만 그들은 어깨를 으쓱했습니다. 그러면서 다음과 같이 말했어요.
"그래요, 시도해볼 수 있죠. 그러나 지식의 바다 전체를 마셔야 할 거에요."
"이 분야는 경쟁이 매우 심해요. 어렸을 때부터 코딩하며 자란 사람들과 어떻게 함께 할 거예요?"
"이미 교사로서 잘하고 계시잖아요. 잘하는 것을 계속해보시는 건 어떨까요?"

이 대화는 몇 주 동안 저를 괴롭혔습니다. 저는 밤에 저의 영혼을 찾는 긴 산책을 하곤 했습니다.
저는 별빛 아래에서 저의 미래에 대해 고민하였습니다. 이 사람들 말이 맞았을까요? 제 말은 - 그들은 알겠죠? 그렇죠?

그러나 매일 아침 저는 다시 책상으로 돌아갔습니다. 제가 짠 스크립트가 돌아가는 것을 보았죠. 제 보고서가 초인적인 속도로 컴파일되는 것을 지켜보았습니다.
제 컴퓨터가 제 명령을 수행하는 것을 지켜보았어요.

문득 떠올랐습니다: 아마 이 친구들은 저를 상심에서 구해주려고 한 것일 수도 있습니다. 아마도 그들 주변엔 30대에 코딩을 배운 사람이 없을 수도 있습니다.
그래서 그들은 가능하다고 생각하지 못한 거죠.

마치…. 몇 년 동안 의사들은 4분 안에 1마일을 달리는 것은 불가능하리라 생각했습니다.그렇게 빨리 달린다면 심장이 폭발해버릴 거로 생각했죠.

그러나 누군가가 이를 해냈습니다. 그리고 그의 심장은 폭발하지 않았죠.

25세의 옥스퍼드 학생인 Roger Bannister가 그 심리적 장벽을 허물자 수많은 다른 사람들도 이를 해냈습니다.
지금까지 1,000명이 넘는 사람들이 4분 미만의 시간 동안 1마일을 달렸습니다.

저는 4분 안에 1마일을 달리는 것처럼 대담하고 전례 없는 일을 하고 있던 것도 아닙니다.

많은 유명한 개발자들이 수년에 걸쳐 코딩을 독학했습니다.

Ada Lovelace는 1840년대에 프로그래밍을 독학했습니다. 그녀는 작동하는 컴퓨터도 없었죠.
Ada Lovelace는 그녀의 친구 Charles Babbage의 컴퓨터가 이론적으로 어떻게 동작하는지에 대한 이해만 있었습니다.

그녀는 최초의 컴퓨터 알고리즘 중 몇 가지를 구현했습니다. 그리고 그녀는 세계 최초의 컴퓨터 프로그래머로 널리 알려져 있죠.
아무도 그녀에게 알려주지 않았습니다. 왜냐하면 그녀에게는 컴퓨터를 가르쳐 줄 사람이 아무도 없었기 때문입니다.
그녀가 스스로에 대해 어떤 의심을 하고 있었든 간에, 이를 분명하게 극복했습니다.

저는 Ada Lovelace가 아니었습니다. 저는 이미 작동하는 컴퓨터, 잘 동작하는 인터넷, 그리고 Google로 수십억 개의 웹페이지를 검색할 수 있는 능력을 갖춘 교사일 뿐이었습니다.

저는 손마디를 꺾으며 시선을 한곳에 모았습니다. 저는 이걸 하려고 했습니다.

튜토리얼 지옥(Tutorial Hell)에 갇히기

"당신이 10년 동안 일했다면, 10년의 경력을 얻게 될까요, 혹은 10번의 1년 경력을 얻게 될까요? 진정한 경험을 얻기 위해서는 당신의 활동들을 반성해 봐야 합니다. 당신이 배움에 지속적인 헌신을 했다면, 경력을 얻을 것입니다. 배우는 것에 지속적으로 전념하지 않았다면 몇 년을 했더라도 진정한 경력을 얻지 못할 것입니다." – 스티브 맥코넬, 소프트웨어 엔지니어

저는 구글링하다가 두서 없이 마주한 튜토리얼들을 하면서 지난 몇 주를 보냈습니다.

오, 이건, 루비(Ruby) 튜토리얼이네.

흠, 점점 어려워지는데. 튜토리얼에는 없는 에러 메세지잖아. 흠... 도대체 뭐야...

오, 파이썬 튜토리얼이네.

인간의 심리는 흥미롭습니다. 무언가 어려워지기 시작한 순간에 우리는 묻죠: 내가 제대로 하고 있는건가?

아마도 이 튜토리얼은 뒤떨어진 것일 거야. 저자는 자기들이 무엇에 대해 말하는지 모를지도 몰라. 누가 이 언어를 아직도 써?

당신이 코딩하는 동안 모호한 에러 메시지를 몇 시간 동안 마주할 때, 남의 떡이 더 커 보이기 시작합니다.(다른 언어 튜토리얼이 더 매력적으로 보이기 시작합니다.)

진전이 있는 척 하는 건 쉽죠. 점심을 먹으러 갑니다.

카페에서 친구를 만나면, “코딩은 어떻게 돼가?” 하고 물을 것입니다.

"잘 되고 있어. 오늘 벌써 4시간이나 코딩했어."

"멋진데. 언제 한 번 네가 뭐 만들고 있는지 보고 싶어."

어떤 것도 제대로 만들고 있지 않다는 걸 알면서, "당연하지," "곧."이라고 말할 것입니다.

서점에서 새 자바스크립트(JavaScript) 책을 하나 사야겠어.

책을 살 때의 기분은 이 세상에서 최고의 기분입니다. 그 책들을 읽을 시간을 사는 것처럼 느껴지니까요.

그리고 나서 코드를 배우는데 몇 주는 쏟는다는 것을 스스로 깨닫게 됐습니다.

몇 권의 프로그래밍 책은 앞쪽 100장만 읽고, 한 권도 끝내지 못했습니다.

몇 개의 프로그래밍 튜토리얼에서는 처음 100줄의 코드를 썼지만, 역시 어떤 것도 완료하지 못했습니다.

잘은 모르겠지만, 개발자들이 애정을 담아 "튜토리얼(배움) 지옥"이라고 부르는 곳에 빠진 것 같았어요.

튜토리얼 지옥은 한 강의에서 다른 강의로 옮겨가면서, 동일한 기본적인 것들을 배우고 또 배우는 것입니다. 그러나 기초를 절대 벗어나지 않습니다.

기초를 벗어나기 위해서는 – 진짜 일을 필요로 하기 때문입니다.

코더(Coder) 한 명을 키우려면 온 마을이 필요하다

코딩을 배우느라 쉬는 시간을 전부 썼습니다. 그러나 많은 진전을 만들어내지는 못했어요. 이제 키보드를 보지 않고 { 나 * 문자는 입력할 수 있습니다. 하지만 그게 다죠.

뭔가 도움이 필요하다는 것을 알았습니다. 방법을 가르쳐 줄 수 있는 요다 같은 멘토가. 그런 사람이 존재했다면, 분명히 모든 것이 달랐을 것입니다.

저는 근처에 "해커스페이스"라는 곳을 알게 됐습니다. 처음에 그 이름을 들었을 때, 좀 두려웠어요. 해커들이 불법적인 일을 하는 거 아냐? 저는 보드 게임을 좋아하는 영어 선생님이고, 문제를 일으키고 싶지는 않았어요.

스티브라는 사람한테 전화해서 이야기해봤어요. 긴장하면서 물었죠: "해커스페이스 사람들이 불법적인 일을 하는 건 아니죠, 그래요?" 스티브는 웃음을 터뜨렸습니다.

"핵(Hack)"이라는 단어는 과부하 용어를 말하는 것이었습니다. 물론 – "해킹하다"는 악의적으로 소프트웨어 시스템을 파괴하는 것을 의미합니다. 그러나 "해킹하다"는 컴퓨터에서 코드를 치는 좀 더 일상적인 것을 의미할 수도 있습니다.

"해키"는 우아한 솔루션이 아닌 어떤 것을 의미할 수 있습니다. 그러나 당신은 "영리한 핵"을 가질 수도 있습니다. – 당신의 코드를 훨씬 효율적으로 만들 기발한 트릭

요약: "핵"이라는 용어를 두려워하지 마세요.

페이스북 기업 캠퍼스 내 콘크리트 위에 새겨진 거대한 "HACK" 글자.

저는 예를 들어 그 용어를 사용하는 게 너무 헷갈려서 두려울 때가 있습니다. 그리고 요즘 굉장히 많은 해커스페이스들이 그 모호함을 가져온다고 생각합니다. 그 중 많은 것들은 요즘 스스로를 "메이커스페이스"라고 대신 호칭합니다.

왜냐하면 해커스페이스 자체가 무언가를 만드는 것이기 때문입니다.

토요일 오후 스티브가 저를 해커스페이스에 초대하였습니다. 그는 해당 지역 출신의 몇몇 개발자들이 거기에 있을 거라고 말했습니다.

처음 산타 바바라 해커스페이스에 들어섰을 때 깜짝 놀랐습니다.

그곳은 마치 전깃불 같은 냄새가 났습니다. 작업 테이블들 위로 땜납들과 LED 전구 선, 애호가들의 아두이노 회로 기판, 룸바 진공 로봇 더미들이 늘어져 있었습니다.

저랑 전화 통화를 했던 스티브가 그곳에 있었고 저를 반겨주었습니다. 그는 안경을 쓰고 있었고 뒤로 빗어 넘긴 머리에 염소 수염을 가지고 있었습니다. 그는 항상 웃고 있었습니다. 질문을 던졌을 때 그는 빠르게 대답하는 대신, 먼저 고개를 끄덕이고 몇 초 동안 생각하는 모습을 보였습니다.

스티브는 캘리포니아 대학교 산타 바바라 캠퍼스에서 수학과 철학을 공부한 열정적인 프로그래머였습니다. 그는 여전히 그 과목들에 대해 열정적이었습니다. 하지만 그의 진정한 열정은 파이썬에 있었습니다.

스티브는 프로젝터를 켜고 편안하게 "가벼운 토크"를 했습니다 그는 자신이 만든 앱을 시연했는데 그것은 동영상에서 QR 코드를 인식하고 이미지로 대체할 수 있는 것이었습니다.

방청석에 있던 누군가가 노트북에 있는 어떤 QR 코드를 꺼내 카메라 앞에서 들고 있었습니다. 그러면 스티브의 앱은 그 QR 코드를 피자 사진으로 바꾸었습니다.

청중 중 누군가가 소리쳤습니다. "그 피자를 회전하게 할 수 있나요?"

스티브는 Emacs라고 불리는 코드 에디터에서 그의 코드를 열었고, 실시간으로 그것을 변경하기 시작했습니다. 그는 자신의 코드 에디터 및 커맨드 라인, 앱이 실행 중인 브라우저 사이를 너무나도 쉽게 왔다 갔다 하며 코드에 업데이트를 "실시간 로딩"했습니다.

저에게 이것은 주술이었습니다. 저는 스티브가 고작 몇 시간 과정으로 앱을 막 출시했다는 것을 믿을 수 없었습니다. 그리고 이제 그는 청중의 요청에 따라 즉석에서 새로운 기능을 추가하고 있었습니다.

저는 생각했습니다: "이 사람 천재다."

그날 저녁 행사가 끝난 후 우리는 좀 더 남아있었고 저는 그에게 그렇게 말했습니다.

우리는 함께 샌드위치를 먹었습니다. 그리고 저는 그에게 말했습니다: "제가 커리어 기간 내내 코딩할 수는 있지만 당신만큼 잘하지는 못할 것 같아요. 10년 후에 제가 당신이 하는 절반만큼이라도 코딩을 잘할 수 있다면 너무 기쁠 것 같은데요."

하지만 스티브는 겸손하게 부인했습니다. 그는 "저는 아무것도 특별하지 않아요. 스스로에게 한계를 두지 마세요. 코딩에 집중한다면 저를 쉽게 뛰어넘을 수 있을 거예요"라고 말했습니다.

저는 그가 한 말을 조금도 믿지 않았습니다. 하지만 그가 그런 말을 했다는 사실 그 자체가 저를 설레게 했습니다.

여기서 그는 저를 믿어준 개발자였습니다. 그는 아무개 선생님이면서 "아마추어 해커" 그 자체인 저를 보고도 제가 해낼 수 있을 거라고 생각했습니다.

스티브와 저는 밤늦게까지 이야기를 나눴습니다. 그는 저에게 200달러짜리, 심지어 2011년도 표준에도 심각하게 저전력인 넷북 컴퓨터를 보여주었습니다.

"소프트웨어를 만들기 위해 대단한 컴퓨터가 필요하지 않아요."라고 스티브가 제게 말했습니다. "오늘날의 하드웨어는 놀라울 정도로 뛰어나요. 그런 컴퓨터가 느려지는 것은 불필요하게 설치된 대용량 소프트웨어 때문입니다. 기성 노트북 한 대를 구입해서 하드 드라이브를 지우고 Linux를 설치한 후 코딩을 시작해 봐요."

저는 그가 가지고 있는 노트북 모델을 메모했고 그날 밤 집에 도착해서 정확히 똑같은 것을 주문했습니다.

며칠 동안 새 컴퓨터를 스택 오버플로(Stack Overflow)와 함께 디버깅한 끝에, 저는 성공적으로 우분투(Ubuntu)를 설치했습니다. 또한 Emacs 코드 에디터 사용법도 배우기 시작했습니다. 그 다음 토요일까지, 저는 몇 가지 명령어를 알게 되었고 이제껏 제가 학습한 내용들을 빠르게 선보였습니다.

스티브는 고개를 끄덕이며 승인했습니다. 그는 "대단하네요. 그런데 무엇을 만들고 있나요?"라고 말했습니다.

저는 무슨 뜻인지 이해하지 못했습니다. "저는 Emacs 사용법을 배우고 있는데요. 확인해 봐요. 저는 이런 걸 외웠어요..."

하지만 스티브는 진지해 보였습니다. "다 잘했어요. 하지만 당신은 어떤 프로젝트가 필요해요. 항상 프로젝트를 가져야 해요. 그래서 해당 프로젝트를 완료하는 과정에서 무엇이 필요한지를 배워야 해요."

저는 학교에서 선생님들을 돕기 위해 썼던 몇몇 스크립트를 제외하고는, 아무것도 끝낸 것이 없었습니다. 하지만 저는 그가 말하는 것을 보기 시작했습니다.

그리고 무언가 떠오르기 시작했습니다. 그동안 저는 튜토리얼 지옥에 갇혀 빙빙 돌면서 아무것도 끝내지 못했습니다.

스티브는 "HTML5를 사용하여 어떤 프로젝트를 만들면 좋겠어요. 그리고 다음 주 토요일 해커스페이스에서 그걸 발표하면 좋겠어요"라고 말했습니다

저는 그의 말에 당황했습니다. 하지만 똑바로 서서 말했습니다. "할 만하겠는데요. 해볼게요."

오직 당신만이 당신 스스로를 개발자로 만들 수 있습니다

"네 마음을 풀어주려는 거다, 네오(Neo). 난 문까지만 안내할 뿐이야. 나가는 건 네가 직접 해야 해." – 매트릭스(1999)의 모피어스(Morpheus)

다음 날 아침, 저는 평소보다 다소 일찍 일어났고 일을 시작하기 전 구글에 "HTML5 튜토리얼"에 대해 검색했습니다. 튜토리얼 지옥에서 겪은 이전의 경험으로 인해 이미 많은 걸 알고 있었지만요. 그냥 넘겨버리는 대신 모든 명령을 천천히 읽고 하나씩 타이핑하며 정확하게 따라해보려고 노력했습니다.

저는 보통 튜토리얼 하나를 끝내고 나면 곧장 또 다른 튜토리얼을 찾아 떠나기 일쑤였습니다. 하지만 이번에는 튜토리얼에 나와있는 코드를 가지고 좀 더 실습을 해보기로 했어요. 간단한 프로젝트 아이디어가 떠올랐고 HTML5만으로 순수하게 코딩을 해서 문서 페이지를 만들어보려 했습니다.

그 전에 잠시 HTML5를 정말 간단하게 설명해보겠습니다. HTML5는 최초의 웹사이트가 탄생한 시기인 1990년대부터 존재해왔던 HTML의 새로운 버전입니다.

웹사이트가 몸통이라면 HTML은 뼈대라고 할 수 있습니다. 그 밖의 모든 요소가 이 뼈대 위에 얹혀지며 참고로 JavaScript는 근육에, CSS는 피부에 비유할 수 있습니다. 일단 다시 본론으로 돌아가봅시다.

저는 HTML에서 ID 속성을 사용하면 동일한 페이지 내의 다른 부분과 연결지을 수 있다는 점을 알고 있었고, 이를 활용할 여러 아이디어를 떠올릴 수 있었습니다. 좌측에 목차를 넣어보면 어떻게 될까? 좌측에서 각 항목을 클릭하면 우측에 해당하는 내용이 보여지도록 스크롤이 내려가게끔 만들어보자.

30분 내로 저는 대강의 프로토타입을 코딩했습니다.

하지만 학교에서 작업을 발표해야 할 시간이 다가오고 있었습니다. 하루 종일 프로젝트에 대해 생각했고, 어떻게 최선의 방법으로 완성할 수 있을지 계속 고민했습니다.

수업이 끝나자마자 집으로 달려가서 노트북을 열었고 저녁 내내 코딩을 하며 시간을 보냈습니다.

(저작물 사용이 허가된) 공식 HTML 문서를 제 웹페이지 안에 그대로 "하드코딩"된 채 붙여넣었습니다.

그리고 나서 1시간 가량 CSS에 시간을 쓰며 컨텐츠는 모두 우측에 노출되도록 하고, 사이드바는 절대 위치(absolute positioning)를 적용해서 원하는 자리에 고정시켰습니다.

HTML5에서 새롭게 도입된 "의미있는(semantic)" 태그도 가능한 다양하게 사용해보려고 애를 썼습니다.

그리고 드디어! 프로젝트를 완성했습니다.

성취감이 물결처럼 밀려왔습니다. 축구장 근처에서 조깅을 하며 자축했습니다. 내가 해냈어, 프로젝트를 완수했다고.

그리고 저는 그 순간 바로 그 자리에서 굳게 결심했습니다. 이제부터 내가 하는 모든 것이 프로젝트가 될 거야. 앞으로 난 어떤 결과물을 완성해내는 것에 집중할 거야.

다음 날 저녁 단상 위에 올라 노트북 플러그를 꽂고 저의 HTML5 웹페이지를 발표했습니다. HTML5에 대한 개발자들의 질문에도 답변했습니다.

때때로 저는 잘못 알고 있었고, 청중들 일부는 이렇게 말하기도 했습니다. "그건 틀린 것 같습니다. 문서를 확인해보죠."

사람들은 제가 잘못 알고 있는 지식을 정정해주는 것에 거리낌이 없었습니다. 하지만 그들은 정중한 태도로 아낌없이 도움을 주었고, 잘못을 지적하는 것처럼 느껴지지 않았습니다. 혹시라도 누군가 잘못된 정보를 얻고 가지 않도록 정확한 정보를 공유하고자 하는 느낌이 더 강했습니다.

현직 교사의 입장에서 발표하면서 느낄 법한 그 어떤 불안도 느끼지 않았고, 저 스스로가 거의 청중의 일부인 것 같았습니다.
마치 그들과 함께 배우고 있는 사람인 것처럼 말이죠.

어쨌든 간에 새롭게 등장한 기술이었고, 우리는 그 모든 기술을 어떻게 사용할지 함께 익혀가는 중이었습니다.

발표를 마치자, 스티브가 다가와 이렇게 말했습니다. "나쁘지 않네요."

저는 행복감에 젖어 긴 시간 동안 말없이 어색하게, 그렇지만 꽤 만족스러운 미소를 지었습니다.

그러자 스티브는 눈을 가늘게 뜨고 입술을 오므렸습니다. 그가 말했습니다. "오늘 밤에 다음 프로젝트를 시작해보세요."

코딩과 함께하는 여정에 담긴 여러 교훈

우리는 이어지는 각각의 챕터에서 어린 퀸시의 코딩 여정을 계속해서 살펴볼 것입니다. 하지만 이쯤에서 잠깐 끊어가도록 하겠습니다. 여러분의 머릿속에 떠올랐을 의문들에 먼저 답해보도록 하죠.

코딩을 배우는 것이 왜 이렇게 어려울까요?

새로운 기술을 배우는 것은 어느 것이든 어렵습니다. 축구공으로 드리블하는 것이든, 자동차의 오일을 교체하는 것이든, 새로운 언어로 말해보는 것이든 말이죠.

코딩을 배우는 것은 몇몇의 특정한 이유로 인해 어렵습니다. 그 중 일부는 코딩의 특수한 성격과도 관련이 있습니다.

첫 번째 이유로, 대다수의 사람들은 코딩이 무엇인지 정확히 이해하지 못합니다. 자, 이 부분에 대해 먼저 말해볼게요.

코딩이란 무엇인가요?

컴퓨터가 해야 할 일을 컴퓨터가 이해할 수 있는 방식으로 알려주는 게 바로 코딩입니다. 이게 코딩의 전부에요.

오해는 마세요. 컴퓨터와 의사소통하는 건 당연히 어려운 일입니다. 인간의 기준으로 보면 컴퓨터는 "멍청"하니까요. 컴퓨터는 당신이 시키는 대로 작동하겠지만 당신이 의도한 대로 움직이리라는 보장은 없습니다. 당신이 능숙하게 코드를 작성하지 못한다면 말이죠.

게다가 서버, 데이터베이스, 네트워크... 이런 용어들은 대체 무엇을 뜻하는 걸까요?

결론부터 말하자면 이 모든 건 겹겹이 쌓인 소프트웨어에 의해 동작합니다. 즉 처음부터 끝까지 코드로 이뤄진 존재인 셈이죠. 여기서 조금 더 파고들면 물리적 차원의 회로판과 그 위에 흐르는 전기 신호의 세계에 다다르게 됩니다.

컴퓨터 사용 초창기 시절에 개발자들은 코드를 "하드웨어적으로" 작성해야 했습니다. 말 그대로 하드웨어에 직접적으로 0에서 1로, 1에서 0으로 비트를 바꿔가며 명령을 입력하는 방식으로요.

그렇지만 오늘날의 소프트웨어 개발은 "겹겹의 추상화"로 이뤄져 있다고 표현할 수 있습니다. 어떤 프로그램이 있고, 그 위에서 또 다른 프로그램이 동작하고, 이러한 과정이 계속해서 반복됩니다. 고작 몇 줄의 자바스크립트 코드만 있다면 이를 충분히 구현할 수 있습니다.

1960년도의 "버그"란 종종 커다란 컴퓨터 안에서 기어 다니다가 뜨거운 회로에 닿아 익어버린 실제 벌레를 뜻하기도 했습니다.

1945년에 발견된 최초의 버그. 하버드의 방 크기만 한 계산용 컴퓨터 속 패널 사이에 갇힌 나방(출처: Public Domain)

오늘날 우리는 물리적인 하드웨어 위에 추상화된 개념을 여러 겹 쌓아 올리는 방식으로 코드를 작성하고 프로그램을 만듭니다. 과거에 비하면 훨씬 간단해진 방식이고 지금도 계속해서 간편해지고 있습니다.

몇십 년 후면 너무 쉬운 일이 되어 젊은 세대 대부분이 코딩을 할 수 있게 될 거라 해도 과언이 아닐 겁니다.

왜 2023년인 지금도 코딩을 배우는 게 어려울까?

2023년이 된 지금도 코딩을 배우는 게 쉽지 않은 이유는 크게 세 가지입니다.

1. 도구가 너무 원시적이라서
2. 대다수의 사람이 모호한 것을 다루는 것에 능숙하지 않아서: 코딩을 배우는 일 자체가 모호한 까닭에 자꾸만 길을 잃은 것처럼 느껴져서
3. 대다수의 사람이 부정적인 피드백을 주고받는 것을 좋아하지 않아서: 코딩을 배운다는 건 짜증스럽게도 새로운 에러 메시지를 계속 마주해야 한다는 뜻이기에

앞서 나열한 각각의 어려움을 좀 더 자세히 살펴보며 이를 극복할 수 있는 실용적인 방안을 함께 제시해보겠습니다.

도구는 여전히 원시적입니다

스타트렉:넥스트 제너레이션에서 바클리가 홀로덱에서 프로그래밍하는 방법입니다.

컴퓨터, 새 프로그램을 시작한다. 지금부터 나열하는 걸 모두 만들어. 작업용 의자, 왼손용 표준 영숫자 콘솔, 오른손용 아이콘 디스플레이 콘솔. 그리고 두 콘솔을 신경 스캔 인터페이스를 통해 엔터프라이즈 본체에 연결해.
- 바클리, 스타트렉:넥스트 제너레이션 시즌 4 19화:N도

제가 가장 좋아하는 공상과학물 스타트렉:넥스트 제너레이션의 한 장면입니다. 미래에는 정말 이런 식으로 프로그래밍하게 될지도 모릅니다.

의사, 보안 요원, 비행사 등 스타트렉에 등장하는 모든 등장인물은 코딩을 할 줄 압니다. 심지어 아역 배우 Wil Wheaton이 연기했던 웨슬리 크러셔 역시 자신이 원하는 대로 컴퓨터를 조작할 줄 압니다.

물론 이 드라마가 그 어떤 물질적 결핍도 존재하지 않는 24세기 사회를 배경으로 하므로, 또 모두가 높은 수준의 무상교육을 받을 수 있다는 점 때문에 가능한 장면일 수도 있습니다. 그렇지만 미래에는 코딩이 훨씬 하기 쉬운 일이 되어있을 것이란 점 역시 이 드라마의 커다란 전제입니다. 해야 할 일을 컴퓨터에 자세히 설명할 수만 있다면 컴퓨터는 당신이 시키는대로 할 거예요.

그냥 평범한 지시문을 말로 하는 것처럼 프로그래밍이 쉬운 일이 된다면 어떻게 될까요?

사실 이 목표를 우리는 이미 상당 부분 이뤄냈습니다. 펀치카드를 잔뜩 쌓아두고 방 크기만 한 중앙컴퓨터를 작동시켜야 했던 우리 할머니들을 떠올려보세요.

펀치카드로 동작하는 컴퓨터로 일을 하는 모습(출처: NASA)

아주 간단한 프로그램을 작동시킬 때조차 아주 자세한 명령이 필요했습니다.

컴퓨터 공학과의 고전 과제 중 하나인 카이사르 암호(Cesar Cypher 또는 Caesar Cipher)를 프로그래밍한 예시를 살펴봅시다.

ROT-13라고 불리기도 하는 이 암호화 알고리즘은 각 알파벳을 13자리씩 회전시키는 방식으로 평문을 암호로 바꿉니다. 예를 들면 A는 13자리 뒤의 알파벳인 N이 되고, 마찬가지 방법으로 B는 O로 대치됩니다.

다음은 ROT-13을 코드로 표현한 것입니다. 두 예시 모두 오픈소스 프로그래밍 예제 모음인 Rosetta Code Project에서 발췌한 내용입니다.

먼저 x86 어셈블리 언어로 작성한 프로그램입니다.

format 	ELF 	executable 3
entry 	start

segment	readable writeable
buf	rb	1

segment	readable executable
start:	mov	eax, 3		; syscall "read"
	mov	ebx, 0		; stdin
	mov	ecx, buf	; buffer for read byte
	mov	edx, 1		; len (read one byte)
	int	80h

	cmp	eax, 0		; EOF?
	jz	exit

	xor 	eax, eax	; load read char to eax
	mov	al, [buf]
	cmp	eax, "A"	; see if it is in ascii a-z or A-Z
	jl	print
	cmp	eax, "z"
	jg	print
	cmp	eax, "Z"
	jle	rotup
	cmp	eax, "a"
	jge	rotlow
	jmp	print

rotup:	sub	eax, "A"-13	; do rot 13 for A-Z
	cdq
	mov	ebx, 26
	div	ebx
	add	edx, "A"
	jmp	rotend

rotlow:	sub	eax, "a"-13	; do rot 13 for a-z
	cdq
	mov	ebx, 26
	div	ebx
	add	edx, "a"

rotend:	mov	[buf], dl

print: 	mov	eax, 4		; syscall write
	mov	ebx, 1		; stdout
	mov	ecx, buf	; *char
	mov	edx, 1		; string length
	int	80h

	jmp	start

exit: 	mov     eax,1		; syscall exit
	xor     ebx,ebx		; exit code
	int     80h

이번에는 동일한 내용을 파이썬으로 작성한 내용입니다.

import string

TRANSLATION_TABLE = str.maketrans(
    string.ascii_uppercase + string.ascii_lowercase,
    string.ascii_uppercase[13:] + string.ascii_uppercase[:13] +
    string.ascii_lowercase[13:] + string.ascii_lowercase[:13]
)

def rot13(s):
    """Return the rot-13 encoding of s."""
    return s.translate(TRANSLATION_TABLE)

if __name__ == "__main__":
    """rot-13 encode the input files, or stdin if no files are provided."""
    import fileinput
    for line in fileinput.input():
        print(rot13(line), end="")

훨씬 간단하고 읽기 쉽지 않나요?

미래에는 이보다 더 쉬워질 겁니다. 당신의 우주선에 대고 그냥 이렇게 말하면 돼요.

"컴퓨터, 새로운 프로그램을 시작해. 내가 말하는 단어를 알파벳 단위로 쪼개고 각 알파벳을 뒤로 13자리씩 움직여줘. 그리고 그 결과를 나한테 말해줘. 자, 바나나(Banana)."

컴퓨터는 "오나난(Onanan)"이라는 답을 알려줄 겁니다.

방금 우리가 한 게 바로 "선언적 프로그래밍"입니다. 우리가 컴퓨터에 어떤 것을 해야한다는 명령을 선언했고, 똑똑한 컴퓨터, 즉 잘 짜인 프로그램은 우리의 명령을 잘 알아듣고 이를 실행했습니다.

하지만 2023년 현재 우리는 대부분 "명령형 프로그래밍" 방식으로 코드를 짜고 있습니다. 순서대로 하나씩 컴퓨터에 어떤 것을 해야 할지 알려주는 방식으로요.

아직 이 분야가 충분히 발전하지 않았기에 컴퓨터는 여전히 멍청하며, 제대로 걸음을 걷게끔 하려면 인간인 우리가 한 발씩 앞으로 나아갈 수 있게 거들어줘야 합니다.

선사 시대의 인간이 사용하던 도구는 돌에서 청동, 철로 발전을 거듭했습니다. 소프트웨어 도구도 마찬가지로 이런 발전의 과정을 거치는 중입니다. 다만 훨씬 빠른 속도로요.

지금 우리가 살고 있는 시대를 선사 시대에 비유하자면 대략 청동 시대쯤 될 겁니다. 그렇지만 아마 우리가 살아있는 동안 인류는 철의 시대를 맞이하게 될 거예요.

코딩을 배우는 것은 애매모호한 과정입니다

코딩을 배울 때는 이런 질문들이 계속 떠오르기 마련입니다. "내가 시간을 현명하게 쓰고 있는 걸까? 맞는 툴을 배우고 있는 걸까? 책의 저자나 강좌의 강사는 자기들이 무슨 말을 하고 있는지 알기나 하는 걸까?"

애매모호함이 모든 스터디 세션을 혼란에 빠뜨리지요. "테스트 케이스가 실패한 게 튜토리얼이 오래된 데다 내가 쓰는 프레임워크에 변경 사항이 있어서 그런 걸까? 아니면 단지 내가 잘못하고 있는 것뿐일까?"

전에 튜토리얼 지옥에 대해 언급했던 것처럼 당신은 "남의 떡이 더 커 보이는" 병도 이겨내야 합니다.

이는 질문에 "RTFM", 즉 "매뉴얼이나 잘 읽어봐(Read the Freaking Manual)"라고 답하는 걸 영리하다고 생각하는 몇몇 개발자 때문에 악화되곤 합니다. 썩 도움이 된다고 할 수 없지요. 대체 어느 매뉴얼 말입니까? 어느 섹션이요?

또 다른 문제는 이겁니다. 자기가 뭘 모르는지 모르는 거지요. 물어보려던 질문을 명확하게 표현하지 못할 때도 종종 있습니다.

그리고 정확한 질문조차 하지 못하면 헛수고만 하게 될 겁니다.

이는 코딩을 할 때 특히나 어려워집니다. 누구도 본인이 만들고 있는 것과 똑같은 앱을 만들려고 한 적이 없을 수도 있으니까요.

당신이 맞닥뜨리는 몇 가지 문제는 그런 이유로 사상 초유의 문제일 수도 있습니다. 의지할 사람이 아무도 없을 수도 있고요.

사람들이 매일 구글에 입력하는 질문의 15퍼센트는 지금까지 단 한 번도 검색된 적 없는 질문이라고 합니다. 당신이 그런 질문을 검색창에 입력하는 중이라면 안타까운 소식이 되겠습니다.

제 가설은 이렇습니다. 대부분의 개발자는 문제 해결법을 찾아내고는 어딘가에 문서로 남겨두지 않은 채 그대로 진행하겠지요. 정확히 똑같은 문제에 대해 자신만의 해결책을 만들어내야 했던 수많은 개발자 중 하나가 당신일 수도 있겠군요.

그리고 오래된 게시글과 스택 오버플로 페이지도 물론 빼놓을 수 없지요.

삽화: XKCD(미국의 웹툰 https://xkcd.com - 옮긴이)

코딩을 배울 때 길을 잃지 않으려면

좋은 소식은, 능숙함과 자신감 둘 다 연습으로 얻을 수 있다는 것입니다.

곧 당신은 정확히 무엇을 검색해야 할지 알게 될 것입니다. 문서 작업은 보통 어떻게 이루어지는지, 어디서 무엇을 찾아야 할지 볼 수 있는 눈도 생길 것입니다. 어떤 질문을 어디에 물어봐야 하는지도 알게 될 거고요.

애매모호한 것을 해결할 더 단순한 방법이 있으면 좋겠습니다만, 사실 그저 받아들이는 수밖에 없습니다. 코딩을 배우는 것은 애매모호한 과정입니다. 아무리 숙련된 개발자여도 애매모호함과 씨름하곤 합니다.

결국 코딩이란 당신이 전에 맞닥뜨렸던 문제에 대한 해결책을 무한정 다시 쓸 수 있는 희귀한 직업입니다.

당신은 개발자이기에 언제나 한 번도 해본 적 없는 일을 하고 있습니다.

사람들은 소프트웨어 개발이 컴퓨터에 코드를 입력하는 일이라고들 생각하지요. 하지만 사실 배우는 것이야말로 개발자가 하는 일입니다.

골똘히 궁리하거나, 시스템이 어떻게 작동하는지 알기 위해 프롬프트에 명령어를 마구잡이로 입력하는 일이 당신 커리어의 상당 부분을 차지하게 될 것입니다.

또한 당신은 매니저와 고객, 동료 개발자 같은 사람들과 회의하고, 해결이 필요한 문제를 배우는 데 많은 시간을 들이면서 해결책을 만들 수 있게 될 것입니다.

애매모호함에 익숙해지세요. 그럼 더 멀리 나아갈 수 있을 것입니다.

코딩을 배우는 것은 에러 메시지의 반복입니다

많은 사람이 코딩을 배우면서 벽에 부닥치는 느낌이 들곤 합니다. 기대한 만큼 빨리 진전되지를 않지요.

여기에는 큰 이유가 하나 있습니다. 프로그래밍의 피드백 루프는 어떤 분야보다도 빡빡하다는 겁니다.

대부분의 학교에서는 선생님께서 과제를 내 주신 다음 채점하고 돌려주시지요. 한 학기 수업을 들으면서 피드백을 받는 경우는 고작 열두 번 남짓일 것입니다.

"아 이런, 이번 시험 완전히 망했어. 중간고사 때는 더 열심히 해야겠다." 하고 스스로 다짐하기도 하지요.

당신이 제출한 과제에 선생님께서 붉은 펜으로 도움이 될 만한 내용을 메모해 주실 수도 있습니다.

시험이나 과제 점수가 나쁘면 하루 종일 기분이 나쁘기도 합니다.

바로 이런 것이 우리가 인간으로서 피드백에 대해 일반적으로 갖는 생각입니다.

코딩에 많은 시간을 투자해 봤다면 컴퓨터가 무척 빠르다는 사실을 아시겠지요. 컴퓨터는 수 밀리초 이내에 당신의 코딩을 처리합니다.

대부분의 경우에는 코드가 충돌합니다.

운이 좋다면 에러 메시지를 받게 될 것입니다.

만약 운이 굉장히 좋다면 "스택 트레이스"를 받게 됩니다. 에러가 났을 때 컴퓨터가 시도한 모든 일과 어떤 라인이 프로그램 충돌을 일으켰는지 보여주는 겁니다.

이것이 바로 컴퓨터가 대놓고 준 부정적인 피드백입니다. 이걸 하루 종일 보고 또 보고 하는 걸 버틸 사람은 아무도 없습니다.

선생님께 학기 말 과제를 제출할 때마다 붉고 거대한 글씨로 "F"를 써서 돌려주셨다고 상상해 보십시오. 그것도 눈 한 번 깜빡이기도 전에 말입니다. 계속 반복해서요.

가끔 그런 느낌이 드는 것이 코딩입니다. 컴퓨터를 붙들고는 소리를 질러대고 싶어지지요. "내가 하려는 일을 그냥 좀 이해해 주면 안 되겠니?"

좌절하지 않으려면

이번에도 비결은 연습입니다.

시간이 지나면 애매한 에러 메시지와 화면 가득한 스택 트레이스에 내성이 생길 것입니다.

코딩은 처음 막 시작했을 때가 가장 힘듭니다.

본인이 뭘 하고 있는지도 모를 뿐 아니라 이런 인간미 없이 속사포로 쏘아대는 부정적인 피드백을 받는 데 익숙하지 않기도 하겠지요.

여기서 몇 가지 팁을 드리겠습니다.

첫 번째 팁: 당신만 유난히 못 하는 게 아니란 걸 알아 두십시오

코딩을 배우는 사람이라면 누구나 컴퓨터와 "벌컨 족의 마인드 멜드"를 시도하여 컴퓨터에게 자신을 이해시키려다 지쳐 나가떨어지지요. (스타트렉을 또 인용해 봤습니다. *마인드 멜드: 스타트렉 시리즈에 나오는 외계인 벌컨 족이 쓸 수 있는 일종의 최면술. 타인의 정신과 본인의 정신을 융합할 수 있다고 한다. - 옮긴이)

물론 어릴 때부터 프로그래밍을 시작한 사람들도 있습니다. 그들은 마치 언제나 프로그래밍을 잘 해왔던 것처럼 굴지도 모릅니다. 하지만 그들도 우리 성인처럼 똑같이 고생하고는 시간이 흐르면서 그 좌절했던 기억을 잊어버렸을 가능성이 높습니다.

컴퓨터를 적이 아닌 친구라 생각해 보세요. 그는 그저 당신에게 설명을 좀 더 명확하게 해 달라는 것뿐입니다.

두 번째 팁: 숨 쉬세요

에러 메시지를 받은 사람 상당수의 자연스러운 반응은 이를 가는 겁니다. 그러고는 코드 에디터로 돌아가 어떻게든 운 좋게 해결되기를 바라면서 무턱대고 코딩을 수정합니다.

잘 될 리가 없습니다. 이유를 알려 드리지요.

우주는 복잡합니다. 소프트웨어도 복잡합니다. 포레스트 검프처럼 무조건 열심히 한다고 행운이 찾아오지는 않습니다.

포레스트 검프가 늘 하던 대로 무작정 열심히 하다가 말도 안 되게 엄청난 행운으로 새우를 잡는 장면

"무한 원숭이 정리"에 대해 들어보셨을 겁니다. 이는 침팬지들이 타자기로 타이핑하는 걸 상상하는 사고 실험입니다.

만약 이렇게 타이핑하는 침팬지들로 뉴스룸 하나가 가득 차 있다면, 그 중 한 마리가 우연히 "죽느냐 사느냐"를 치기까지 얼마나 걸릴까요?

모든 침팬지가 무작위로 1초에 한 글자를 친다고 해봅시다. 그러면 침팬지 중 한 마리가 "죽느냐 사느냐"를 치기까지 100경 년이 걸릴 것입니다. 100경은 10의 18제곱입니다. 10억의 10억 배죠.

거기에 모든 침팬지가 건강하고 타자기도 정기적으로 점검을 받는다고 가정해도, 침팬지 한 마리가 간신히 "죽느냐 사느냐"를 칠 때쯤이면 은하계는 차갑고, 어둡고, 텅 빈 곳이 되어 있을 것입니다.

이런 얘기를 왜 하냐고요? 왜냐하면 당신이 그 침팬지 중 하나가 되어서는 안 되기 때문입니다.

그 정도 시간이면 틀림없이 침팬지에게 영어 단어 타이핑하는 걸 가르칠 방법을 알아낼 것도 같습니다. 침팬지들은 그 명대사뿐 아니라 "햄릿"을 통째로 치게 될 수도 있을 겁니다.

그렇게 해서 운 좋게 버그를 해결해봤자 무엇을 배우겠습니까?

그러니까 마구 헛발길질하는 대신 시간을 들여 보는 건 어떨까요. 코드를 이해하려고 해 보고, 무슨 일이 일어나고 있는지 이해하려고 해 보십시오. 그런 다음 에러를 수정하세요.

실패한 코드를 이해하는 데 언제나 시간을 들이도록 하세요. 퀸틸리어나리언(quintillionarian *실제로 존재하지 않는 단어임 - 옮긴이) 침팬지가 되지는 마십시오. (100경(quintillion) 살짜리라는 뜻이 아닐까 싶습니다. 구글에서 검색해 보니 아무도 이런 단어를 쓴 적 없는 것 같긴 하지만요.)

아무거나 무턱대고 시도해 보는 대신 에러 메시지를 해결하기를 바라면서 속도를 늦추세요.

심호흡하세요. 기지개도 켜고요. 자리에서 일어나 뜨거운 음료수도 한 잔 마셔요.

미래의 당신은 자신이 이를 교훈적인 순간으로 받아들였다는 사실에 감사할 것입니다.

세 번째 팁: 고무 오리 디버깅을 해보세요

고무로 된 장난감 오리를 하나 가져다 컴퓨터 옆에 두십시오. 에러 메시지에 부딪힐 때마다 무슨 일이 일어나고 있는 것 같은지 고무 오리에게 본인의 생각을 설명하려고 해보세요.

물론 우스꽝스럽게 들릴 겁니다. 이게 어떻게 도움이 된다는 거죠?

그런데 도움이 된답니다.

고무 오리 디버깅은 속도를 늦추고 당장의 문제에 대해 차분히 설명할 수 있게 해주는 훌륭한 수단입니다.

꼭 고무 오리일 필요는 없습니다. 애완 선인장에게 파이썬 앱을 설명해도 되지요. 자꾸만 키보드에 뛰어오르는 고양이에게 SQL 쿼리를 설명할 수도 있고요.

자기 생각을 소리 내어 설명하는 행위 자체가 상황을 잘 해결하는 데 도움이 된다고 볼 수 있지요.

다들 어떻게 코딩을 배우는 걸까?

이제 처음 개발자로 취업하기 위한 보편적인 경로에 관해 얘기해봅시다.

다른 모든 사람이 무엇을 하는지 왜 신경을 써야 할까요? 스포일러 주의: 꼭 그럴 필요는 없습니다.

그저 하던 대로 하시면 됩니다.

어쩌면 스스로에 대해서나 배우기로 한 결정에 대해서도 확신이 없을 수 있겠지요. 해본 적 없는 다른 진로를 갈망할 수도 있고요.

이 섹션에서 제가 목표로 하는 것은 당신이 갖고 있을지 모를 모든 불안을 잠재우는 것입니다.

컴퓨터 과학 학위의 중요성

대학교의 학위는 여전히 소프트웨어 개발 분야에서 커리어를 준비할 때 기준이 됩니다. 특히 컴퓨터 과학의 학사 학위가 그렇습니다.

"그렇지만 저는 컴퓨터 과학 학위가 없는걸요"라고 말씀하시기 전에, 걱정하지 마십시오. 개발자가 되는 데 꼭 컴퓨터 과학 학위가 필요한 것은 아닙니다.

그러나 학위의 유용성은 반박의 여지가 없습니다. 왜 그런지 알려 드리겠습니다.

첫째로, 어째서 개발자는 컴퓨터 과학을 공부해야 하는지 의문이 들 수도 있겠지요. 심지어 역사상 가장 뛰어난 개발자 중 한 분은 이 분야에 대해 다음과 같은 말씀을 남겼습니다.

"붓과 물감을 공부한다고 누구나 전문 화가가 될 수는 없듯이, 컴퓨터 과학 교육을 받는다고 누구나 전문 프로그래머가 될 수는 없습니다." - 에릭 레이먼드. 개발자이자 컴퓨터 과학자 및 작가

컴퓨터 과학과는 전통적으로 수학과의 일부였습니다. 1960년대와 1970년대의 대학에서는 이 컴퓨터 분야 전체를 어디에 넣어야 할지 확신하지 못했지요.

컴퓨터 과학을 전기 공학의 연장선으로 보는 대학도 있었습니다. 그리고 세계에서 가장 훌륭한 공립 대학 중 하나인 캘리포니아주 버클리 대학마저도 최근까지 컴퓨터 과학 학위를 전기 공학과의 이중 전공으로만 제공했습니다.

하지만 지금은 대부분의 대학에서 연구 분야로서 컴퓨터 과학의 중요성을 이해하게 되었습니다.

이 글을 쓰는 시점에서 컴퓨터 과학은 졸업 후에 연봉을 가장 높게 받을 수 있는 전공입니다. 심지어 금융학이나 경제학처럼 돈에 치중한 전공보다도 더 높은 수준입니다.

글래스도어(Glassdoor, 해당 회사 직원의 익명 리뷰에 기반한 직장 및 상사 평가 사이트 - 위키피디아)에 따르면, 미국 내 컴퓨터 과학 전공자의 평균 초봉은 미화 7만 달러로 다른 전공자보다 높다고 합니다. 갓 대학을 졸업한 사회 초년생에게는 제법 큰 돈이지요.

간호학과(5만 9천 달러), 금융학과 (5만 5천 달러), 그리고 건축학과(5만 달러)보다도 높습니다.

좋습니다. 컴퓨터 과학 학위가 있으면 첫 직장으로 고액 연봉을 주는 회사에 취직하는 데 도움이 됩니다. 딱히 새로운 소식은 아니지요. 하지만 왜 그럴까요?

학사 학위에 대한 고용주의 생각은

기술 분야의 굵직한 회사에서 이렇게들 말하는 걸 들어보신 적이 있겠지요. "우리는 더 이상 입사 지원자에게 학사 학위를 요구하지 않습니다."

구글이 그렇답니다. 애플도 그렇답니다.

저도 믿습니다. 그들이 더 이상 학사 학위를 요구하지 않는다는 사실을 말이지요.

프리코드캠프 동문 중에서는 그런 회사에 취직하신 분이 많이 계십니다. 그중에는 학사 학위가 없는 분들도 계시지요.

하지만 이렇게 취업에 성공한 프리코드캠프 동문들은 학사 학위가 없다는 사실을 극복할 만큼 강력한 채용 후보가 되어야 했을 것입니다.

이런 채용 공고를 보면 다음과 같이 다양한 채용 기준이 있는 것을 알 수 있습니다.

1. 업무 경험
2. 학력
3. 포트폴리오 및 참여한 프로젝트
4. 회사에서 근무 중인 누군가의 추천장이 있는가? (인맥을 쌓는 법에 대해서는 2장에서 자세히 다룰 예정입니다.)
5. 고려할 만한 기타 평판 (평판을 얻는 법에 대해서는 3장에서 다룰 예정입니다.)

지원자에게 학사 학위를 요구하지 않는 고용주에게 학력은 그저 여러 가지 고려 사항 중 하나일 뿐입니다. 다른 분야에서 뛰어나다면 면접 기회가 주어질 수도 있습니다. 대학교 강의실에 한 번이라도 발을 들였건 아니건 간에요.

학사 학위 소지자에게 면접 기회가 좀 더 많이 주어진다는 점을 알아두십시오. 학위는 선택에 불과하다는 고용주로부터도 말이지요.

왜 개발 직군을 채용할 때 컴퓨터과학 전공 학위를 요구할까요?

저는 종종 말하곤 합니다. 학사 학위는 학사 학위일 뿐이라고요. 단지 어떤 특정 목표를 이루기 위해 필요한 하나의 수단일 뿐입니다.

일반 사병보다 장교로 미군에 입대하고 싶나요? 학사 학위가 필요하긴 하지만, 어떤 전공인지는 별 영향이 없을 겁니다.

해외 취업을 위해 취업 비자를 신청하고 싶다면요? 학사 학위가 필요할 수도 있지만, 마찬가지로 전공이 무엇인지는 크게 관계가 없을 거예요.

많은 구인 광고에서 "학사 학위 소지자"를 찾습니다만, 이 경우에도 실상 전공 자체는 큰 영향이 없습니다.

왜 그럴까요? 대학에서 전공한 과목은 전혀 중요하지 않은 걸까요?

글쎄요, 저는 대학에서 무엇을 배웠는지보다 궁극적으로 대학을 졸업했는지가 훨씬 더 중요하다고 생각합니다.

고용주들은 대학 졸업과 같은 특정 통과 의례를 무사히 완수할 수 있는 사람들을 뽑고 싶어 합니다.

물론 학위 취득 과정에서 하위권 성적을 받거나 재수강을 할 수도 있고, 어쩌면 유급을 하게 될지도 모르죠. 그렇지만 어쨌거나 이 과정을 거치고 나면 학위를 받게 됩니다.

의과 대학에서 최종적으로 모든 과정을 완수한 학생들을 "의사(박사)"라고 부르듯이 말이죠.

대다수의 고용주들도 마찬가지로 이러한 학위 취득 과정을 겪었을 겁니다.

많은 경우 HR 직원들은 소프트웨어와 관련한 키워드가 있는지를 기준으로 이력서를 추려냅니다. 학위가 없는 지원자를 걸러내기도 하고요. 그 경우 학위가 없는 지원자의 이력서는 아예 읽어보지 않을 수도 있죠.

다시 말씀드립니다만, 모든 고용주들이 다 이런 건 아니에요. 하지만 상당수의 고용주가 이러한 경향이 있습니다. 저는 미국을 예로 들었습니다만, 다른 나라들은 아마 더 심할지도 모릅니다.

거지같은 일이죠. 그렇지만 현재 노동 시장의 현실이 그렇습니다. 어쩌면 수십 년 후에는 달라질지도 모르죠. 수십 년 후에도 여전할지도 모르고요.

그래서 전 항상 개발자를 지망하는 10대, 20대에게는 학사 학위를 취득하는 것을 적극적으로 검토해보라고 추천하는 편입니다.

단지 대학에서 흔히 내세우는 아래의 이점 때문에 추천하는 것은 아닙니다.

• 품질 높은 교육? 비싼 수업료를 내지 않더라도 품질 높은 대학 수업을 온라인으로 수강할 수 있습니다.
• 기숙사에서 생활하고 친구들을 사귀면서 자아를 발견하는 경험? 대부분의 미국 대학생들은 캠퍼스에서 살지 않기 이를 경험할 기회가 거의 없습니다.
• "다재다능한 인재"를 키워내는 여러 교양 과목? "신입생 15(Freshman 15)"라는 말을 들어보셨나요? 농담처럼 쓰이는 말이긴 하지만 실제로 많은 신입생이 필수 교양 과목 이수 과정에서 받는 스트레스로 체중 증가를 경험합니다.

거듭 말씀드리지만 미국인이 대학에 4년 동안 10만 달러 이상을 지불하며 학사 학위를 취득하는 이유는 위의 이유 때문이 아닙니다. 많은 고용주가 취업 과정에서 학위를 요구하기 때문이죠.

물론 학사 학위의 이점이 이뿐만은 아닙니다. 앞서 언급했듯이 학사 학위가 있으면 군 입대 시 선택지가 넓어질 수 있고 취업 비자도 훨씬 더 쉽게 받을 수 있습니다.

또한 만일 의사, 치과 의사, 변호사, 교수가 되고 싶다면 반드시 학사 학위가 필요합니다. 학사 학위가 있어야 대학원을 갈 수 있기 때문입니다.

좋습니다. 지금까지 학사 학위와 관련하여 다각도의 측면에서 이야기했습니다. 이제 보다 구체적으로 질문에 답해보도록 하죠.

소프트웨어 개발자로 일하려면 대학 학위가 필요한가요?

아닙니다. 학사 학위가 없어도 당신을 고용할 고용주는 많이 있습니다.

학사 학위가 있으면 많은 고용주로부터 면접 기회를 얻기가 조금 더 쉬워지는 겁니다. 높은 연봉을 받는 데 도움이 될 수도 있습니다.

준학사 학위는 어떤가요? 취득할 가치가 있을까요?

이론적으로는 그렇습니다. 준학사 학위를 요구하는 기술 분야도 있습니다. 학위는 면접 기회를 늘리는 데 언제나 도움이 된다는 것이 제 생각입니다.

그렇다고 준학사 학위 취득이라는 특정한 목표를 갖고 대학에 가는 것을 추천하지는 않겠습니다. 저는 훨씬 더 유용한 학사 학위를 딸 때까지 학교에 남아있는 것을 백 퍼센트 권장합니다.

미국 교육부에 따르면, 학사 학위를 소지하고 있으면 준학사 학위 하나만 있을 때보다 직장 생활을 하는 동안 31퍼센트 더 많은 소득을 얻을 수 있다고 합니다.

또 컴퓨터 과학 학사 학위의 경우 그 차이가 훨씬 크다고 확신합니다.

아직 학사 학위가 없다면 나중에라도 학사 학위를 따기 위해 대학에 갈 가치가 있을까요?

당신이 30대라고 가정해 봅시다. 컬리지나 종합대학에 다니셨을 수도 있겠군요. 첫 2년의 과정을 마치고 준학사 학위를 받게 되었을 수도 있고요.

이때 정식으로 "학교로 돌아가는" 게 맞는 일일까요?

네, 그럴 수 있습니다.

하지만 그렇다고 해서 풀타임 학생이 되기 위해 하던 일을 그만두고 학교에 가는 것은 온당치 않다고 봅니다.

풀타임 학생의 생활 방식은 정말 "일반적인" 학생을 염두에 두고 고안된 것입니다. 다시 말해, 아직 고교생 수준의 일자리나 여름 파트타임 이상의 직장 경력이 없는 18세에서 22세 사이(군 복무를 한 경우에는 그보다 조금 더 높은 연령대)의 사람들이 대상이었다는 얘기입니다.

일반 대학은 학비가 많이 들지요. 이는 학생들이 장학금과 가족들의 지원 및 학자금 대출을 조합하여 학비를 조달하리라는 가정이 밑바탕에 깔린 것입니다.

직장에 다니는 성인이 이런 재정 지원을 받기는 어려울 것입니다. 게다가 갓 고등학교를 졸업한 사람에 비해 쓸 수 있는 시간이 부족하다는 사실도 중요하지요.

하지만 그렇다고 해서 학사 학위 취득의 꿈을 포기해야 한다는 뜻은 아닙니다.

30세 이상인 분들께는 전통적인 대학보다는 온라인 비영리 대학 수업을 듣는 것을 추천합니다. 평판이 좋으면서 학비가 제법 저렴한 두 군데 대학은 웨스턴 가버너스 유니버시티(Western Governor's University)와 유니버시티 오브 더 피플(University of the People)입니다.

이 밖에도 학위를 제공하는 커뮤니티 컬리지(community college, 지역 전문대학), 혹은 일반 대학교의 공개강좌를 찾을 수 있습니다. 이런 프로그램은 온라인으로 제공되는 경우가 많습니다. 또한 그중에는 자기 진도에 맞춰 자율적으로 학습할 수 있는 프로그램도 있어서 일하면서 틈틈이 수업을 들으며 과정을 수료할 수도 있습니다.

한번 알아보시길 바랍니다. 유망해 보이는 학교를 발견하면 링크드인에서 그 학교 졸업생 중 한 명을 찾아 연락해 보는 것도 좋겠습니다. 어떤 경험을 했는지, 혹은 다닐 만한 가치가 있다고 생각하는지도 물어보십시오.

학위를 따겠다고 대출을 받아 학비를 조달하는 것은 추천하고 싶지 않습니다. 학비가 더 저렴한 학교에 다니는 편이 훨씬 낫습니다. 학위는 학위에 불과합니다. 공인된 교육 기관이기만 하면 대체로 의도와 목적에 잘 부합할 것입니다.

이미 학사 학위가 있는데 다시 학교로 돌아가 컴퓨터 과학에서 두 번째 학사 학위를 따는 것이 맞는 걸까요?

아닙니다. 두 번째 학사 학위는 딱히 시간과 돈을 투자할 가치가 없습니다.

학사 학위가 있다면 STEM 계열 전공(STEM: Science, Technology, Engineering, and Mathematics)이 아닐지라도 이미 대학에서 얻을 수 있는 가치를 거의 다 얻어냈다고 할 수 있습니다.

컴퓨터 과학 석사 학위가 필요한가요?

물론 커리어를 쌓는 과정에는 도움이 될 수 있습니다. 그렇지만 개발자로 일을 시작한 뒤에 도전해도 충분합니다. 직원이 학업을 계속하는 것을 기꺼이 지원해 주는 고용주도 꽤 많습니다.

조지아 공과대학교의 컴퓨터 과학 석사 학위 프로그램을 수료한 친구가 주변에 여럿 있습니다. 이 학과는 미국 내에서 손에 꼽는 훌륭한 곳으로 모든 프로그램이 온라인으로 진행될 뿐만 아니라 학비도 합리적입니다.

그럼에도 불구하고 당장 학위를 따는 걸 추천하지는 않습니다. 일단 개발자로서 실무를 시작하는 것에 집중해야 합니다(관련한 내용을 뒷부분에서 좀 더 자세히 다루겠습니다).

학위 보유 여부가 미래에도 영향력을 가질까요?

저는 아마 그럴 거로 생각합니다. 다가올 몇십 년, 아마 몇백 년 후에도요. 대학 학위라는 건 1,000년 전에도 존재했습니다. 미국의 상위 대학 대다수는 사실 미국이라는 나라보다도 역사가 깊습니다. 하버드는 무려 400여 년 전통을 자랑합니다.

대학 학위가 점점 힘을 잃을 거라는 관점은 과장된 면이 생각보다 더 많습니다. 이는 대학 제도를 비난하는 사람들 사이에서 꽤 인기 있는 주장이며, 그들은 이제 학위가 아무런 의미도 갖지 않는다고 주장합니다.

그렇지만 통계 자료를 살펴보면 실제로는 그렇지 않다는 걸 확인할 수 있습니다. 여전히 학위는 일생에 걸친 소득 수준에 영향을 미칩니다. 소득 수준뿐만이 아닙니다. 좀 더 안전하고, 안정적이며 높은 성취감을 느낄 수 있는 직업을 향한 기회의 문이 열릴 확률이 더 높다는 점 역시 학위가 주는 커다란 힘 중 하나입니다.

당신이 석유 시추선에서 선원으로 일을 한다고 가정해봅시다. 물론 많은 돈을 벌 수 있을 겁니다. 그렇지만 날씨를 걱정하는 대신 쾌적한 사무실 안에서 서버를 관리하고 코드를 수정하는 개발자로 일을 해도 비슷한 수준의 소득을 올릴 수 있다는 점이 중요합니다. 전자는 위험하고 육체적으로 아주 힘든 일입니다. 후자는 훨씬 편안하게, 40년 넘게 지속할 수 있는 일이고요.

대학 제도를 맹렬히 비난하는 소위 "선구자들" 대다수 역시 알고 보면 대학 교육을 통해 큰 삶의 혜택을 얻은 경우가 많습니다. 개인적으로 많은 사람이 학위 취득에 따른 사회적 지위 상승과 대학 교육 자체를 분리하지 못하기 때문에 대학 학위가 쓸모없다는 의견이 설득력을 얻는다고 생각합니다.

대학이라는 곳이 상위 계급에 속하기 위한 통과 의례일 뿐일까요? 단지 부와 권력을 쟁취하고, 그렇게 얻은 것을 자식에게 대물림하기 위해 거쳐 가는 곳인가요? 이러니저러니 해도 결국 하버드에서 부자가 아닌 사람을 만날 확률은 부자를 만날 확률의 20분의 1도 되지 않으니까요.

인생이 공평하지 않다는 건 어쩔 수 없이 받아들여야 하는 사실입니다. 그렇지만 학위가 노동 시장에서 절대적인 영향력을 갖는 건 아닙니다. 쉬운 길을 택하면, 즉 학위를 취득한다면 당신의 눈앞에 비교적 더 다양한 선택지가 눈앞에 펼쳐질 겁니다. 반대로 어려운 길을 택한다면, 단기적으로는 시간과 돈을 아낄 수 있지만 당신이 선택할 수 있는 직장의 수가 비교적 적을 수밖에 없습니다.

물론 각각의 접근법을 성공적으로 활용한 친구들을 여럿 알고 있긴 하지만요.

컴퓨터 과학 학사 학위로 무엇을 할 수 있는가

대학 학위의 대안으로는 무엇이 있을까요?

20년 가까이 성인 교육 분야에서 일하면서 대학교의 학위를 대신할 설득력 있는 대안은 아직 보지 못했습니다.

물론 수료 과정과 부트캠프가 있기는 합니다.

그러나 고용주는 이런 프로그램을 그다지 높게 쳐주지 않습니다. 이 프로그램들이 그렇게 철저하지 않기도 하고요.

참고: 여기서 "수료 과정"은 코스를 들으면 마지막에 수료증을 취득하게 되는 프로그램을 말합니다. 이들의 가치는 한정되어 있지요. 하지만 아마존이나 마이크로소프트 같은 회사에서 제공하는 수료증은 시험을 치러야 취득할 수 있는 것으로 상당히 가치가 있습니다. 이에 대해서는 나중에 자세히 다룰 예정입니다.

제가 사람들에게 얘기하는 것은 이겁니다. "학위냐 아니냐, 그것이 문제로다."

저는 학사 학위가 없는 자동차 정비사와 전기 기사, 혹은 다른 기술직 노동자를 많이 뵙곤 합니다. 확실히 기술을 배워 응용할 줄 알며 일을 계속할 수 있는 분들입니다.

학사 학위가 없는 회계사와 법무사, 또 다른 "지식 노동자"도 많이 뵙습니다. 확실히 기술을 배우고 응용할 줄 알며 일을 계속할 수 있는 분들이지요.

대체로 이런 분들은 무료 강좌를 듣고 뜻이 맞는 사람들과 어울리며 스스로 코딩을 배우는 것이 가능합니다.

이 가운데에는 학교로 돌아가 학사 학위를 마치겠다는 개인적인 목표를 늘 품고 있는 분들도 계십니다. 학교로 돌아가는 데 충분한 이유가 되지요.

하지만 모두에게 그런 것은 아닙니다.

정규 교육을 받고 싶다면 학사 학위를 목표로 하십시오. 정규 교육을 받고 싶은 게 아니라면 어떤 프로그램에도 등록하지 말고 그냥 독학하십시오.

부트캠프 및 기타 수료 과정에서는 주로 구조를 배우고 또래 집단 스트레스에 대해 맛볼 수 있을 겁니다. 나쁘지 않지요. 그런데 그게 과연 수천 달러의 가치가 있을까요?

코딩을 스스로 익히는 법

개발자는 대부분 독학으로 코딩을 배웁니다. 스택 오버플로의 연례 설문 조사 같은 업계의 설문 조사 결과를 보면 컴퓨터 과학 학사 학위를 소지한 개발자들조차 여전히 "독학했다"고 대답하는 일이 종종 있습니다.

현직 개발자 대부분은 "독학으로 배웠다"고 합니다. (표: 2016년 스택 오버플로 설문 조사 결과)

코딩 공부는 평생 끝이 없는 과정이기 때문입니다. 끊임없이 새로운 툴을 공부해야 하고, 새로운 레거시 코드베이스를 손봐야 하고, 새로운 문제를 해결해야 합니다.

그러니까 정규 교육을 추구하든 아니든 독학을 잘하셔야 한다는 점, 알아두시기를 바랍니다.

"독학으로 배운" 개발자가 된다는 것은 무엇을 뜻합니까?

꼬치꼬치 따지려는 것이 아니라, 제가 말하는 독학은 정규 교육 이외의 자기 주도 학습을 뜻합니다.

극히 소수의 사람만이 진정한 "독학"을 했다고 볼 수 있습니다. 예를 들어 아이작 뉴턴은 미적분을 독학했습니다. 그때는 미적분 책이란 게 없었기 때문입니다. 그가 연구를 진행하면서 알아내고 발명해야 했던 것이 미적분입니다.

마찬가지로 에이다 러브레이스(영국 시인 바이런의 딸로 최초의 컴퓨터 프로그래머로 알려져 있음 - 인물세계사)는 프로그래밍을 독학했습니다. 그전에는 프로그래밍이란 게 없었기 때문입니다. 그녀가 발명한 것입니다.

"당신은 책이나 온라인 강의에서 배운 거니까 정말로 독학했다고 할 수 없어요. 말하자면 선생님이 있었던 거죠." 맞습니다. 단, 아주 좁은 의미에서만 말이지요.

당신이 독학했다고 말하는 것을 누군가 트집 잡는다면 이렇게 말씀하십시오. "그 기준에 따르면 늑대가 키운 사람 말고는 아무도 독학했다고 할 수 없겠군요." (로마 제국을 세운 로물루스와 레무스 쌍둥이는 늑대가 키웠다고 알려져 있다. - 옮긴이)

그런 사람에게 이 책의 바로 이 대목을 보여주면서 말씀하십시오. "당신이 그렇게 잘난 척할 것을 퀸시가 벌써 내다봤답니다." 그러고서 갈 길을 가시면 됩니다.

그런 걸 신경 쓰기에 인생은 너무 짧습니다. 그렇죠?

인생은 독학이죠.

자기 주도 학습(Self-Directed Learning)이란 무엇인가요?

자기 주도 학습자로서, 당신은 자신만의 학습 리소스를 선택하고 관리하게 됩니다. 어디에서 무엇을 배울지 선택할 것입니다. 이것이 "자기 주도 학습"의 본질입니다.

하지만, 어떻게 자신이 올바른 기술을 배우고 올바른 자원을 활용하고 있는지 알 수 있을까요?

그래서 우리는 커뮤니티가 필요합니다.

전 세계에는 많은 학습자 커뮤니티가 있으며 서로의 기술을 향상시키는 데 도움을 주고 있습니다.

커뮤니티는 정의하기 어려운 단어입니다. Tech Twitter는 커뮤니티일까요? freeCodeCamp 포럼은 어떨까요? 또는 특정 코딩 기술을 위한 다양한 디스코드 그룹과 서브레딧은 커뮤니티에 해당할까요?

저는 이 모든 것을 커뮤니티로 간주합니다. 만약 자주 함께 어울리고 또 서로 도와주는 사람들이 있다면, 그곳은 커뮤니티라고 생각합니다.

현장에서 열리는 행사들은 어떤가요? 오크랜드(캘리포니아에 있는 도시-옮긴이)의 루비 개발자들이 매월 만나는 밋업, 뉴욕 시 스타트업 커뮤니티 밋업, 텍사스의 리눅스 사용자 그룹 등은 어떨까요?

이러한 커뮤니티들은 온라인, 현장, 또는 둘 다의 조합일 수 있습니다.

"인맥 쌓기" 챕터에서는 커뮤니티에 대해 더 자세히 이야기하겠습니다. 하지만 중요한 점은, 이러한 커뮤니티에서 새로운 친구들을 만나면 무엇을 배울지와 어떤 리소스를 활용할지 선택지를 좁히는 데 도움을 받을 수 있다는 것입니다.

어떤 프로그래밍 언어를 먼저 배워야 할까요?

간단히 말하자면, 어떤 언어를 먼저 배워야할지는 별로 중요하지 않습니다. 하나의 프로그래밍 언어를 잘 배우면, 두 번째 언어를 배우는 것이 훨씬 쉬워집니다.

프로그래밍 언어에는 여러 종류가 있지만, 오늘날 대부분의 개발은 자바스크립트나 파이썬과 같은 '고수준 스크립트 언어'를 사용하여 수행됩니다. 이러한 언어들은 C와 같은 '저수준 프로그래밍 언어'에서 얻을 수 있는 초기 효율성을 포기합니다. 하지만 그럼으로써 받는 이득은 훨씬 쉽게 사용할 수 있다는 것입니다.

오늘날 컴퓨터는 C 같은 언어로 대부분의 프로그램을 작성했던 1970년대와 1980년대보다 수억 배 더 빠릅니다. 이러한 성능은 스크립트 언어의 상대적인 비효율성을 충분히 상쇄시킵니다.

주목할 만한 점은, 자바스크립트와 파이썬 자체가 C로 작성되었고, 이 언어들의 오픈 소스 코드 기여자들의 대규모 커뮤니티 덕분에 매년 더 빨라지고 있다는 것입니다.

파이썬은 데이터 과학과 머신 러닝같은 과학적 계산을 위한 강력한 언어입니다.

그리고 자바스크립트... 자바스크립트는 모든 것을 할 수 있습니다. 자바스크립트는 궁극적인 스위스 아미 나이프 프로그래밍 언어입니다. 자바스크립트는 전 세계 인터넷 함께 묶어주는 박스 테이프입니다.

"자바스크립트로 만들 수 있는 애플리케이션이라면 결국 자바스크립트로 만들어질 것이다."

• Atwood의 법칙 (스택 오버플로와 Discourse의 창시자 Jeff Atwood)

당신의 모든 경력 자체를 자바스크립트만으로 쌓을 수 있고, 두 번째 언어를 배울 필요가 없을 수도 있습니다. (그렇다고 하더라도, 나중에 파이썬과 다른 몇 가지 언어를 배우는 것이 좋습니다.)

그러므로 저는 자바스크립트부터 시작하는 것을 추천합니다. 자바나 C++과 같은 언어보다 사용하기 쉬울 뿐 아니라, 배우기도 훨씬 쉽습니다. 그리고 자바스크립트를 아는 사람에게 취업 기회가 훨씬 더 많이 있습니다.

미국 취업 검색 엔진 Indeed에서 "자바스크립트"로 검색한 결과, 68,838개의 채용 공고가 나온 모습

다음으로 주목해야 할 기술로는 HTML과 CSS가 있습니다. 웹 페이지가 몸이라면 HTML은 뼈대, CSS는 피부라 할 수 있지요. (자바스크립트는 웹 사이트가 움직이고 상호작용하게끔 한다는 점에서 근육이라 할 수 있습니다.)

HTML과 CSS는 반나절이면 배울 수 있습니다. 여기에서 언급한 대부분의 툴과 마찬가지로, 이들은 배우기는 쉽지만 숙달하기는 어렵습니다.

리눅스도 배워두는 것이 좋습니다. 리눅스는 전 세계 대부분의 서버를 지원하며, 당신은 리눅스 커맨드 라인에서 명령을 실행하는 데 커리어의 상당 시간을 할애하게 될 것입니다.

맥을 쓰는 경우, 맥 OS(MacOS)에는 리눅스에서 쓰는 것과 거의 동일한 명령어를 사용하는 터미널이 있습니다. (맥 OS와 리눅스는 유닉스라는 같은 조상에서 파생되었습니다.)

윈도우 PC를 쓰고 계신다면 WSL(Windows Subsystem for Linux, 리눅스용 윈도우 하위 시스템)을 설치하십시오. 그러면 PC에서 리눅스 명령어를 실행할 수 있습니다. 특별히 모험심이 강한 분이라면 동일한 컴퓨터에서 윈도우와 리눅스 운영 체제를 듀얼 부팅으로 모두 사용하실 수 있습니다.

컴퓨터에 리눅스를 설치하신다면 우분투부터 시작하는 것을 추천해 드립니다. 가장 널리 사용되는 (그리고 널리 문서화된) 리눅스 배포판이지요. 그런 만큼 가장 관대할 것입니다.

분명히 말해두지만, 리눅스는 윈도우나 맥 OS보다 사용이 상당히 까다롭습니다. 하지만 노력의 대가로 매우 빠르고 안정적이며 고도의 커스터마이징이 가능한 운영 체제를 얻을 수 있습니다.

게다가 운영체제 라이선스 비용을 또 결제하지 않아도 됩니다. 그러고 싶지 않다면요. 레드햇(Red Hat)은 소프트웨어가 오픈 소스임에도 불구하고 수십억 달러를 벌어들이는 회사입니다. 기업에서 리눅스 서버의 도움말 서비스 및 지원에 지불하는 비용 덕분이지요.

Git도 배우는 것이 좋습니다. 이 버전 관리 시스템(Version Control System)은 개발자 팀에서 코드베이스의 변경점을 관리할 때 사용합니다.

깃허브(GitHub)에 대해 들어보셨겠지요. 개발자들이 오픈 소스에서 더 쉽게 협업할 수 있게 해주는 웹 사이트입니다. 그뿐만 아니라 깃(Git)의 일부 기능을 더욱 확장하기도 합니다. 깃허브에 대해서는 "평판을 쌓는 법" 챕터에서 자세히 알아보겠습니다.

SQL과 관계형 데이터베이스가 어떻게 작동하는지도 배워야 할 것입니다. 이들은 정보 경제학의 주요한 장비입니다.

NoSQL 데이터베이스(그래프 데이터베이스(graph databases), 문서 데이터베이스(document databases)와 키-밸류 스토어(key-value stores)과 같은 비관계형 데이터베이스(Non-relational databases))에 대해서도 많이 듣게 될 것입니다. 이에 대해서는 나중에 더 배울 수 있습니다. 우선은 SQL부터 집중하도록 하세요.

마지막으로, 웹 서버가 어떻게 작동하는지 배워야 합니다. Node.js와 Express.js부터 시작하는 게 좋겠죠.

"풀스택 개발"이라는 용어는 프론트엔드(HTML, CSS, 자바스크립트)와 백엔드(리눅스, SQL 데이터베이스, 그리고 Node + Express)를 합친 것을 뜻합니다.

이 밖에도 리액트(React), NGINX, 도커(Docker), 테스팅 라이브러리(testing libraries)처럼 배우면 좋은 툴이 많지요. 앞으로 하나씩 배우시면 됩니다.

하지만 취업 전 학습 시간의 90퍼센트를 투자해야 하는 핵심 기술은 다음과 같습니다.

1. HTML
2. CSS
3. JavaScript
4. Linux
5. Git
6. SQL
7. Node.js
8. Express.js

이러한 툴을 배우면 대부분의 메이저 웹 사이트와 모바일 앱을 만들 수 있습니다. 또한 신입 개발자로서 일을 할 수 있는 자격을 거의 갖추게 되지요. (물론 많은 직무 내용에는 다른 툴도 포함되어 있습니다. 하지만 이에 대해서는 책의 뒷부분에서 다시 논의하겠습니다.)

이제 이런 생각이 들겠지요. "이걸 다 어떻게 배우죠?"

코딩을 어디서 배워야 하나요?

재미있는 질문이군요. 숙련된 소프트웨어 엔지니어와 선생님들이 설계한, 하나로 완성된 커리큘럼이 있답니다. 바쁜 성인을 염두에 두고 만들어졌지요. 또, 완전히 무료인 데다 자기 진도에 맞춰 자율적으로 학습할 수 있답니다.

맞습니다. 바로 프리코드캠프 코어 커리큘럼입니다. 다음 분야를 공부할 때 도움이 될 것입니다.

• 프론트엔드 개발
• 백엔드 개발
• 공학수학
• 과학 컴퓨팅(Scientific Computing)(데이터 과학 및 머신러닝을 위한 파이썬 사용)

지금까지 수천 명의 사람들이 이 코어 커리큘럼을 거쳐 개발자로 취업했습니다. 낮에 하던 일을 그만둔다든지, 대출을 받는다든지 할 필요도 없고, 밤과 주말 시간을 조금 포기하는 것 외에 짊어져야 할 위험 부담은 아무것도 없었지요.

실제로 프리코드캠프는 혼자 코딩을 공부하는 사람들 대부분이 기본으로 거쳐 가는 경로가 되었습니다.

일단 프리코드캠프 코어 커리큘럼을 시작점으로 두고 거기서부터 다른 분야로 확장해 갈 수도 있습니다. 대부분의 업무에서 요구하는 핵심 기술을 배우고 관심 있는 기술에 도전할 수도 있지요.

거기에는 수십 년 동안 배울 수 있는 책과 코스들이 있습니다. 몇몇은 공공 도서관이나 월간 구독 서비스를 통해 찾을 수 있지요. (물론 도서관에서도 이런 구독 서비스 일부를 무료로 이용할 수 있습니다.)

또한 프리코드캠프에서는 현재 AWS 인증 준비부터 모바일 앱 개발, 칼리 리눅스(Kali Linux)에 이르기까지 모든 분야에 대한 무료 정규 코스가 1,000개 가까이 제공되고 있습니다.

프로그래밍 독학이 이보다 쉬웠던 적은 없었습니다.

기술의 향상은 끝없는 노력이 답입니다

지금까지 왜 독학이 가장 좋은 방법이 될 수 있는지와 그 방법에 관해서 이야기했습니다.

컴퓨터 과학 학사, 혹은 석사 학위 취득과 같은 독학의 대안에 관해서도 이야기했고요.

가장 먼저 중점적으로 공부해야 할 특정한 툴에 관해서도 이야기했습니다.

이제 기어를 바꾸고, 의자의 두 번째 다리라고 할 수 있는 "인맥"을 쌓는 법으로 넘어가 봅시다.

2장: 인맥을 쌓는 방법

"빨리 가고 싶으면 혼자서 가고, 멀리 가고 싶으면 누군가와 함께 가라." - 아프리카 속담

"인맥 쌓기." 이 단어를 들으면 움찔하실 수도 있겠습니다.

인맥을 쌓는다고 하면, 답답한 정장을 빼입고서 받아줄 법한 사람에게 필사적으로 이력서를 들이미는 어색한 취업 박람회가 떠오를 수도 있습니다.

또는 술에 흠뻑 취한 채 함께 경기를 시청하는 친목 모임이 떠오를 수도 있지요. 관심도 없는 스포츠에 흥미가 있는 척 끼는 모임 말입니다.

또, 링크드인에서 잘 알지도 못하는 사람의 생일을 축하해 준다거나 상태 업데이트에 "좋아요"를 눌러 주며 당신을 알아봐 주기를 바라는 것을 떠올리게 할 수도 있습니다.

그러나 인맥 쌓기는 그렇게 하지 않아도 됩니다.

이 장에서는 사람을 만나는 일에 대해 제가 배운 모든 것을 알려 드리려고 합니다. 신뢰를 얻는 법과, 도움이 필요할 때 가장 먼저 떠오르는 사람이 될 방법을 가르쳐 드리겠습니다.

왜냐하면 결국 그게 가장 중요하기 때문입니다. 문제를 해결하는 데 도움을 주는 것, 쓸모 있는 사람이 되는 것 말이죠.

앞으로 수십 년 동안 당신을 뒷받침 해줄 강력한 인맥을 쌓는 법을 보여드리겠습니다.

스토리 타임: 30대 교사는 어떻게 기술 분야에서 네트워크를 구축했을까?

지난 이야기: 퀸시는 책을 읽고 무료 온라인 강좌를 듣고 지역 해커스페이스의 개발자들과 어울리며 코딩을 좀 배웠습니다. 그는 막 첫 프로젝트를 완성했고, 처음으로 기술에 대한 강연도 했습니다...

좋습니다. 이제 가장 초보적인 코딩 기술을 조금 익혔습니다. 간신히 코딩으로 뭔가를 시도해 볼 수도 있을 것 같습니다.

다음은 뭘까요? 무엇보다 저는 기술 분야에서 완벽한 아웃사이더였습니다.

제가 기술 분야는 처음이지만, 일이란 것을 처음 해보는 것은 아니었습니다. 학교에서 일하고 영어를 가르치면서 십 년 가까이 밥벌이를 해왔는 걸요.

교사로 일할 때는 지식을 흩뿌리면서 돈을 벌었습니다. 개발자로 일하면서 코딩을 흩뿌리면서 돈을 벌겠지요.

저는 이미 일의 본질에 관한 아주 중요한 진실을 알고 있었습니다. 바로 당신이 누구를 아느냐는 것이지요.

저는 인맥의 힘을 알고 있었습니다. 기회를 향한 길은 반드시 문지기를 거쳐야만 나온다는 것이지요.

저와 돈 잘 버는 개발자 사이에 있는 것은 "좋아요. 이 퀸시라는 친구는 우리 팀에 합류해도 될 만해 보이는군요."라고 말해줄 수 있는 채용 담당자뿐이었습니다.

물론 기술 분야의 아웃사이더였던 저는 그런 문화를 몰랐지요.

학계의 문화에서는 조금 더 격식을 차립니다.

우선 정장부터 갖춰 입습니다.

당신이 "그룹"의 일원이라는 것을 보여주기 위해 멋들어진 학술 용어를 사용합니다.

X 대학에 다녔거나, Y 박사 밑에서 조교를 했었거나, Z 저널에 게재했다는 둥 모든 대화에 참여할 방법을 찾아냅니다.

승진하는 방법이 다릅니다. 컨퍼런스도 다릅니다. 권력 구조도 다릅니다.

그리고 저는 이 사실을 바로 알아차리지 못했습니다.

처음 참가했던 몇 군데의 기술 분야 행사에 저는 정장을 입고 갔었지요.

깔끔하게 접은 저의 이력서를 항상 주머니에 넣고 다녔습니다.

심지어 명함까지 들고 다녔습니다. 양극 산화 알루미늄 종이를 주문해서 레이저 커터로 제 이름과 이메일 주소, 전설적인 교육자 존 듀이(John Dewey)의 인용구까지 새긴 명함이었지요.

생각하기 시작한 사람은 세계의 일부를 위험에 빠뜨린다." - 존 듀이 (John Dewey)

여전히 제가 가장 좋아하는 인용구입니다.

하지만 너무 지나쳤죠.

"안녕하세요, 저는 퀸시라고 합니다. 이건 제 붉은 알루미늄 명함인데, 이것 때문에 집에 가실 때 공항에서 금속 탐지기가 울릴 수도 있어요. 미리 죄송합니다."

지나치게 열심이었죠. 그리고 저와 얘기를 나눈 모든 사람이 이를 아주 뚜렷하게 느꼈을 겁니다.

저는 밋업(*Meetup.com : 유사한 관심사, 취미 및 직업을 가진 사람과 커뮤니티를 위해 대면 및 가상 활동, 모임 및 이벤트를 주최하고 조직하기 위한 소셜 미디어 플랫폼)에서 찾을 수 있는 모든 개발자 이벤트에 참석하겠다고 회신을 보냈습니다. 산타 바버라는 작은 마을이었지만 로스앤젤레스와 가까웠지요. 그래서 그곳에서 열리는 행사도 운전해서 가곤 했습니다.

저는 황급히 정신을 차리고 정장에서 청바지와 후드티로 갈아입었습니다. 그리고 아무도 명함을 나눠주지 않는다는 사실을 알아차리고는 더 이상 명함을 갖고 다니지 않기로 했습니다.

해커스페이스에서 만난 개발자들에게서는 이런 것을 배웠습니다. 열정적이되 겸손할 것. 약간의 열정을 비축해 둘 것.

그리고 개발자의 문화를 더 잘 이해하기 위해 많은 책을 읽었습니다.

The Coders at Work는 1980년대에 나온 좋은 책입니다.

Hackers:Heroes of the Revolution(*'해커, 광기의 랩소디 : 세상을 바꾼 컴퓨터 혁명의 영웅들'이란 제목으로 한국어로 번역되었습니다)은 1990년대에 나온 좋은 책입니다.

좀 더 현대적인 문화 자료로는 TV 시리즈 Mr.Robot이 있습니다. 등장인물들이 좀 극단적이긴 하지만, 많은 개발자의 사고방식과 매너리즘을 잘 포착했습니다.

곧 저는 교사보다는 개발자처럼 얘기하게 되었습니다. 어색하게 튀지 않게 되었지요.

일주일에 몇 차례씩 지역의 기술 관련 행사에 참석했습니다.

제가 제일 좋아했던 이벤트는 사실 개발자가 메인은 아닌, 산타바바라 스타트업 나이트(Santa Barbara Startup Night)였습니다.

그 모임에서는 몇 주에 한 번씩 개발자가 프로토타입을 발표하는 행사를 했습니다.

코드를 시연하는 개발자 중 몇몇은 신생기업 투자자들로부터 자금을 확보할 수도 있었습니다.

그 이벤트의 주최자는 마이크였습니다. 산타바바라의 개발자와 창업자라면 누구라도 그를 알 것입니다.

마침내 용기를 내어 마이크에게 저를 소개했을 때, 저는 감격에 휩싸였습니다.

그는 안정 시 심박수가 40대 초반이었던 엄청난 마라토너였습니다. 머리와 수염도 완벽하게 다듬었지요. 저에게 그는 지구상에서 가장 쿨한 남자였습니다. 항상 우아하고 존경스러웠습니다.

마이크는 "기술자"는 아니었습니다. 그는 프로덕트 매니저였습니다. 그는 기술과 사용자 경험 디자인에 대해서 많이 알고 있었지만, 코딩하는 방법은 몰랐습니다.

때때로 개발자들은 기술자가 아닌 사람을 경시하기도 합니다. "그는 그냥 비즈니스를 하는 사람이야," 혹은 "그녀는 비즈니스 의상을 입은 사람이야"라고 말할지 모릅니다. 그러나 마이크에 대해서 그렇게 말하는 사람은 한 번도 없었습니다. 모두가 그를 존경했습니다.

저는 마이크가 개발자들과 어떻게 상호소통하는지를 주목했습니다. 결국 저도 비(非) 기술자와 별 다를 바 없었습니다. 그저 코딩 몇 달 해본 게 다였지요.

오래된 습관이 슬그머니 되살아나는 일도 종종 있었습니다. 얘기를 나누다 보면 제가 배운 것이나 만든 것을 자랑하고 싶어지기도 했지요.

많은 개발자는 자기 기술이나 업적에 대해서 겸손합니다. 그들은 아마도 "저는 파이썬을 조금 해봤어요"라고 말할지 모릅니다. 그런데 저는 딱히 자신도 없으면서 "아, 그래요. 저는 파이썬으로 알고리즘 코딩을 많이 해 봤어요. 자면서도 파이썬을 쓸 정도인걸요."라는 식으로 떠벌리곤 했지요.

그런 다음 집에 돌아와서 그 개발자의 이름을 검색해 보고 그들이 주요한 파이썬 라이브러리의 핵심 기여자라는 것을 깨닫고는 심하게 자책했지요.

저는 곧 제 업적이나 기술을 자랑해선 안 된다는 교훈을 배웠습니다. 상대방이 저보다 훨씬 뛰어난 코딩 실력을 갖췄을 가능성이 높습니다. 그러나 그들 대부분은 이러한 사실을 스스로 드러내지 않지요.

최악의 상황은 자랑스럽게 랩탑을 꺼내서 코드를 보여주다가 대답할 준비가 안 된 질문을 받게 되는 일이지요.

이벤트에 참가하기 시작한 처음 몇 달의 경험은 초라했습니다. 그러나 이 이벤트들은 제 기술들을 계속 발전시켜 나갈 수 있는 에너지가 되었습니다.

곧 남부 캘리포니아 사람들은 저를 알아보기 시작했습니다. 그들은 "행사에서 자주 마주치네요. 이름이 뭐였죠?"라고 말하곤 했죠.

어느 날 밤 한 개발자가 "트위터에서 서로 팔로우해요."라고 말했습니다. 사실 저는 며칠 전에 트위터가 그저 겉만 그럴싸한 웹사이트라고 생각하면서 마지못해 계정을 하나 만들었지요. 140자만으로 얼마나 많은 것을 전달할 수 있을까요? 저는 거의 아무것도 트윗하지 않았습니다. 하지만 어쨌든 트위터 계정이 있었기에 그녀는 제게 팔로우 신청을 했습니다.

그로 인해 저의 온라인 존재를 다듬는 데 더 많은 시간을 할애하게 되었습니다. 링크드인 프로필을 덜 형식적이고 더 친근하게 만들었습니다. 커뮤니티 내 다른 개발자들이 온라인에서 자신을 어떻게 표현하는지 살펴보았습니다.

몇 달 안에 저는 다양한 분야의 사람들을 알게 되었습니다:

• 경력 있는 개발자들
• 기술 회사들에서 일하는 비 기술자 또는 준 기술자인 사람들
• 채용 관리자들과 채용 담당자들
• 그리고 가장 중요한, 어느 정도의 경력이 있고 기술 분야에 진출하려는 비슷한 상황에 있는 사람들

왜 비슷한 상황에 있는 사람들이 가장 중요할까요? 확실히 그들은 제가 직장을 구하는 데 가장 도움이 안 될 텐데 말입니다. 그렇죠?

좋아요, 제가 비밀을 하나 말해드리죠. 채용 관리자가 새로운 개발자를 고용하고, 교육하고, 그들이 일을 매우 잘 수행한다고 가정해 봅시다. 그 채용 관리자는 아마도 "어디서 당신 같은 사람을 더 찾을 수 있나요?"라고 물을 것입니다.

비슷한 상황에 있는 사람들은 중요한 인맥 중 하나입니다. 많은 프리랜서 일자리와 취업 면접 기회는 저와 비슷한 시기에 코딩을 배우기 시작한 사람들로부터 찾아왔습니다.
우리는 같이 여정을 시작했고 형제자매와 같았습니다. 이런 유대가 가장 강한 것이지요.

어쨌든, 몇 달에 걸친 이 모든 네트워킹은 어느 날 밤 개발자 행사에 참여하기 위해 멋진 시내 호텔의 바에 들어갔을 때 궁극적으로 결실을 보았습니다.

그러나 더 자세한 것은 다음 장에서 다루겠습니다. 이제 인맥 구축에 관한 기술과 과학에 대해서 자세히 얘기해 보겠습니다.

정말 당신이 아는 사람입니까?

아마도 성공이란 "무엇을 아는가보다 누구를 아는가?"라는 표현을 들어보셨을 것입니다.

실제로는 둘 다에 관한 것입니다.

예, 인맥은 꿈의 직업을 얻는 데 도움이 될 수 있을 것입니다. 그러나 깊이가 얕거나 성공할 수 있는 기술이 부족한 경우에는 취직해도 그 역할을 잘 수행하기 어려울 것입니다.

그러나 당신이 능동적으로 기술을 잘 쌓고 있다고 가정해 봅시다. 당신은 1장부터 내 조언을 잘 따랐습니다. 인맥 쌓기 시작하기 좋은 시기는 언제일까요?

인맥 쌓기 시작하기에 가장 좋은 시기는 어제입니다.

그러나 이를 위해 타임머신이 필요하지는 않습니다. 왜냐하면 이미 인맥이 있기 때문이죠. 원하는 것보다 훨씬 작을 수 있지만, 알고 있는 사람들이 있지 않습니까.

고향 친구일 수도 있고 부모님의 동료일 수도 있습니다. 과거에 알았던 사람이 조금이라도 도움이 될 수 있습니다.

따라서 첫 번째 단계는 당신이 아는 사람들의 전체 목록을 작성하는 것입니다. 걱정하지 마세요, 아직 누구에게 연락하라거나 개인적인 관계를 부담스럽게 만들려는 것이 아닙니다.

행동하기 전에 생각하고 전략을 세우세요.

첫 번째로, 당신이 알고 있는 모든 사람의 목록을 작성해 봅시다.

개인 네트워크 보드 만드는 방법

먼저 알고 계신 사람들의 명단을 작성해 보세요.

스프레드시트나 판매직원들이 사용하는 고객 관리 도구(CRM)로도 작성할 수 있습니다. 하지만 여기서 우리가 하려는 것에 비하면 그것은 과도한 일일 수도 있습니다.

무료 칸반 보드 도구인 Trello를 사용하는 것을 추천합니다.

예를 들어서 이 보드에 "평가 대상", "연락할 대상", "답변 대기 중", "최근 연락한 대상", "아직 연락하지 말아야 할 대상"이라는 5개의 열을 만드는 겁니다.

그런 다음에, 각각의 사람들을 어떻게 아는지에 따라서 분류하기 위해 라벨을 만드는 게 좋습니다. 이렇게 라벨을 만들어 볼 수도 있습니다. "어린 시절 친구", "가족 친구", "전 동료", "동창", "테크 이벤트에서 만난 친구들".

이제 카드를 만들어 볼 수 있습니다. 각 카드는 그 사람들의 이름만 포함하면 되며, 시간이 된다면 카드에 사진을 추가할 수도 있습니다.

개인 네트워크 보드의 예시로 쓰기 위해 Trello 보드를 만들어 보았습니다. 저는 제가 어린 시절 가장 좋아했던 영화 중 하나인 1989년의 대표작<닌자 거북이>에서 캐릭터들을 사용했습니다.

제 파트타임 범죄 퇴치일에 참여하는 친구들과 함께 만든 개인 네트워크 보드입니다.

소셜 미디어 계정을 훑어보거나, 학교 졸업 앨범을 갖고 계시다면 그 또한 확인해 볼 수 있습니다. 그리고 사람들을 추가하기 시작하면 됩니다.

이들 중에는 도움이 되지 않을 사람들도 많겠지만, 그래도 보다 종합적으로 리스트를 작성하고자 추가해 보는 것을 추천합니다. "어, 이 사람이 이런 회사에 취업했네. 연락해 봐야겠다."라는 생각이 갑자기 들 수 있기 때문입니다.

이 과정은 하루나 이틀이 걸릴 수도 있습니다. 하지만 이것은 투자라는 것을 기억하세요. 이 보드는 당신의 커리어 전체에 걸쳐 사용할 수 있습니다.

"난 이미 링크드인 계정이 있으니까 이걸 할 필요 없다"고 생각할 수도 있겠지만, 링크드인은 실질적인 이점이나 효과가 작은 도구입니다. 여기에서 유용한 정보를 최대화하고 그렇지 않은 소음은 최소화해야 합니다. 그렇기 때문에 이러한 전용 개인 네트워크 보드를 만들 것을 권장합니다.

보드에 사람들을 추가하면서 라벨을 붙일 수 있습니다. 이들 각각에 대해 조사해 보세요. 요즘 이들은 어떻게 지내고 있나요? 일하고 있나요? 회사를 운영하고 있나요?

각각의 카드에는 새로운 사실을 발견하면 메모를 추가할 수 있습니다. 최근에 5K 자선 마라톤 행사에 참가했나요? 그 사람의 할머니께서 최근에 90번째 생신을 맞이하셨나요? 이러한 사실들은 불필요한 것처럼 보일 수 있지만, 사람들이 이를 소셜 미디어에서 공유하고 있다면, 그 사실들은 그들에게 중요한 것이라는 것을 의미합니다.

다른 사람들에게 관심을 가져보세요. 그 사람들의 일상생활과 포부에 대해 말이에요. 다른 이의 동기와 목표를 이해함으로써, 당신은 그들을 어떻게 도울 수 있는지에 대한 깊은 통찰력을 갖게 될 것입니다.

그리고 앞서 언급했듯이, 나의 편으로 만들 수 있는 가장 좋은 방법은 사람들을 도와주는 것입니다. 곧 이에 대해 자세히 이야기해보겠습니다.

당신의 개인 네트워크 보드에 추가하는 각 사람마다, 그들에게 연락해 볼 가치가 있는지 고려해보세요. 그런 다음 "연락할 대상" 또는 "아직 연락하지 말아야 할 대상" 열에 그들을 배치하세요.

"왜 '아직 연락하지 말아야 할 대상' 라는 열이 있는 건가요?" 라는 의문이 드실 수도 있습니다. 왜냐하면 언제 누군가를 알고 있으면 도움이 될지 모르기 때문입니다. 어떠한 친구나 지인 관계도 당연하게 여겨선 안 됩니다.

이 보드를 채우고, 모두에게 라벨을 붙이고, 각 열에 정렬했다면, 이제 연락을 시작할 준비가 되었습니다.

네트워크 확장을 위해 준비하는 방법

네트워크 확장을 준비할 때 염두에 둬야 할 주요한 사항은 전달해야 할 메시지를 간단하게 하는 것입니다.
사람들은 바쁘고, 당신에 대해 기억할 수 있는 것들에는 한계가 있습니다. 당신은 자신이 누구인지를 근본적이고 단순하게 요약해야 합니다. 가장 좋은 방법은 자기 소개를 쓰는 것입니다.

소셜미디어에 자기 소개를 쓰는 방법

여러 소셜 미디어 계정들에서 일관성을 유지하는 것이 좋습니다.
다음은 저의 자기소개입니다.
"저는 퀸시입니다. 저는 프리코드캠프에서 교사로 활동하고 있습니다. 텍사스 주 댈러스에 거주하고 있습니다. 코딩을 배우는 데 도움을 드릴 수 있습니다."

이제 한번 자기 소개를 작성해보세요. 100자 이하로 줄여보고 어려운 단어나 전문 용어는 피하는 것이 좋습니다.

내 자신이 누구인지 몇 마디로 요약하는 것은 어려울 수 있습니다. 그러나 이것은 중요한 과정입니다.

한가지 기억할 점은 사람들은 바쁘다는 것입니다. 사람들은 당신 인생 전체를 알 필요가 없어요. 시간이 지남에 따라 서로 더 잘 알게 되면서 내가 누구인지에 대한 세부 정보를 점차 채워 넣을 수 있습니다. 사람들의 질문에 대답을 해주다 보면 시간이 지나면서 당신에 대해 더 잘 알아갈 수 있습니다.

이에 관련하여, 당신의 웃고 있는 얼굴을 담은 좋은 사진이 필요합니다.

소셜미디어의 프로필 사진을 만드는 방법

돈이 있다면, 동네의 사진작가를 찾아서 전문적인 프로필 사진을 찍어보세요.

카메라에 관심이 있는 친구에게 부탁해서 무료로 찍을 수도 있을 것입니다.

저는 MacOS에 미리 설치된 Photobooth를 사용하여 스스로 프로필 사진을 찍었습니다. 친구가 약 10분에 걸쳐 포토샵으로 배경과 그림자를 약간 수정해주었습니다. 아마 제 치아를 더 하얗게 만들었던 것 같습니다. 이것이 저의 프로필 사진입니다.

어디에나 쓰는 나의 프로필 사진

눈으로 웃는 미소를 지어 보세요. 그렇게 하면 딱딱한 미소로 보이지 않을 것입니다. 더 좋은 방법은 제가 했던 것처럼 웃긴 일을 생각해보세요. 그러면 웃음이 진실돼 보일 것입니다.

다양한 각도에서 많은 사진을 찍어서 어떤 것이 가장 잘 어울리는지 골라 사용하세요.

하루하루 실제로 보이는 자신의 모습과 같은 프로필 사진을 사용하는 것을 추천합니다. 과도하게 포토샵으로 가공해서 자신의 매력을 극대화하는 사진을 사용하는 대신 말입니다. 행사에 참석하는 사람들이 사진에서 당신을 알아볼 수 있도록 해야 합니다. 그리고 완벽한 모습으로 인해 사람들을 거리감을 주지 말아야 합니다. 오히려 사람들이 편안하게 느끼도록 해주어야 합니다.

사람들을 편안하게 해주기 위해서는 선글라스를 쓴다거나 멋있게 보이려고 너무 노력하지 않는 것이 좋습니다. 친근하고 다가갈 수 있는 이미지를 보여주는 것이 좋습니다. 이를 확인하기 위한 좋은 방법은 자신의 사진을 한번 보는 것입니다. 만약 길을 잃었을 때 이 사람을 거리에서 본다면 가서 길을 물어볼 만큼 충분히 용기가 날 것 같은지 생각해보세요.

선택한 프로필 사진을 모든 곳에 일관되게 사용하세요. 모든 소셜 미디어 계정에 올리세요. 개인 웹사이트에도 사용하세요. 심지어 이메일 계정의 프로필 사진에도 추가하세요.

여러 해 동안 동일한 사진을 사용하는 것을 추천합니다. 사진을 변경할 때마다 몇몇의 사람들이 즉시 당신을 알아보지 못할 수 있는 위험이 있습니다. 조명, 각도, 배경의 미묘한 변화조차도 사람들의 익숙함을 떨어뜨릴 수 있습니다.

사진은 고화질 버전을 유지하는 것이 중요합니다. 그렇게 하면 사람들이 컨퍼런스에서 당신의 강연을 홍보하거나, 팟캐스트에서 당신의 게스트 등장을 홍보하는 데 사용할 수 있습니다. (걱정하지 마세요 - 이런 것들은 시간이 지나면 성취할 수 있을 겁니다.)

과거에 알던 사람들에게 다가가는 법

소개 글과 사진 정리가 다 되었으면 이제 사람들과 대화를 시작할 준비가 된 겁니다.

15년 전이었다면 사람들에게 메시지를 보내지 말고 직접 전화를 걸라고 말했겠지요. 하지만 스마트폰의 등장과 함께 문화가 많이 바뀌었습니다. 이제 대부분의 사람은 전화를 잘 받지 않습니다.

마찬가지로 한참 대화를 나누기도 전에 커피나 점심 약속을 청하는 것도 추천하지 않습니다. 사람들은 바쁩니다. 그리고 그런 부탁을 난처하게 여길 수도 있습니다.

서둘러 요점을 말해야 합니다.

그러니까 그 요점이란 게 뭘까요?

기본은 이렇습니다:

1. 당신을 압니다
2. 당신에게 호감이 있습니다
3. 그리고 당신이 하는 일을 존경합니다

그거면 됩니다.

사람들은 알아봐 주는 것을 좋아하지요. 자기를 좋아해 주는 것도 좋아합니다. 하는 일과 일상에 관심 가져주는 것도 좋아하고요.

우리 대부분은 생일날 관심을 받곤 합니다. 예전에 알던 사람들이 "생일 축하합니다"라며 문자 메시지를 보내기도 하고, 소셜 미디어 포스팅을 보내주거나, 전화를 해주기도 합니다.

하지만 나머지 364일은 어떨까요? 사람들은 생일이 아니더라도 자기를 알아봐 주는 것을 좋아하지요.

자, 사람들을 알아봐 주는 간단한 방법을 알려 드리겠습니다.

Step 1: 그 사람에 대해 알아보세요. 검색도 해 보고, 최근에 소셜 미디어에 올린 포스팅을 꼼꼼히 읽어 보십시오. 링크드인도 죽 읽어 보세요. 가족사진을 올리면 시간을 들여 사진을 들여다보십시오.

Step 2: 그 사람의 하루를 조금 더 활기차게 해 줄 말을 떠올려 보십시오.

Step 3: 그 사람이 가장 최근에 활동했던 소셜 미디어 플랫폼을 골라 DM(Direct Message, 개인에게 보내는 메시지)을 보내십시오.

제가 템플릿을 하나 공유할 텐데, 절대 그걸 그대로 복사해서 쓰시면 안 됩니다. 받은 사람이 그 메시지를 구글에서 검색해 보면 그게 템플릿인 걸 알게 될 테고, 당신의 선의는 헛되이 버려질 것입니다.

몇 달 혹은 몇 년 동안 연락을 하지 않던 누군가에게 느닷없이 메시지를 보낸다면 저는 이런 식으로 보내겠습니다:

"[이름]님 안녕하세요, [새해/봄/새로운 한 주] 즐겁게 시작하시기를 바랍니다. [새 직장 구하신 것/승진/아기의 탄생/프로젝트 완료]을(를) 축하드립니다. 일을 척척 해내시는 모습을 보니 좋은 자극이 됩니다."

짤막하고 간결하게 하십시오. 안부 인사 + 축하 + 칭찬. 그것이 기본 공식입니다.

그냥 빈말이 아니라 진심을 담으십시오.

이 사람이 인정받는다고 느끼도록 진심으로 노력하십시오. 활기를 주기 위해 진심으로 노력하십시오. 그들이 목표를 향해 계속 전진하도록 진심으로 격려해 주십시오.

인간은 진심이 아닌 것을 감지하는 데 탁월한 능력이 있습니다. 오버하지 않도록 하세요. "이 사람, 나한테 원하는 게 있군"이라고 생각할 여지를 주지 마십시오.

"간결함"이 가장 중요한 이유가 바로 이것입니다. 다른 사람의 시간을 존중해 주십시오. 길게 답장해 줘야 할 것 같은 부담을 주는 긴 편지는 누구도 받고 싶어 하지 않습니다.

다시 함께 말해 볼까요, 왜냐하면 사람들은 바쁘기 때문입니다.

더 깊은 관계를 쌓는 법

사람들은 너무 바쁘기 때문에, 나에게 다음과 같은 일을 해줄 수 있는 타인을 더욱 찾게 됩니다.

• 버스를 운전해서 나를 회사에 출근시켜 주는 사람
• 음료수를 내가 원하는 방식으로 만들어 주는 사람
• 휴가에 대한 내 질문에 답변해 주는 인사부 담당자
• 멋진 애시드 재즈 재생 목록을 만들어 내가 코딩하는 동안 들을 수 있게 해 주는 사람
• 매주 유용한 무료 코딩 강좌에 관한 이메일을 보내 주는 사람

어떤 의미에서는, 다른 사람을 위해 하는 일이 당신을 정의합니다.

압니다. 알아요. 지나치게 환원주의적으로 들리겠지요. 냉소적으로도 들릴 겁니다. 또한 가까운 친구들과 가족들에게는 100퍼센트 들어맞지 않는 이야기입니다.

그러나 당신을 잘 모르는 사람, 일과 중에 어쩌다 마주친 사람들 눈에는 당신이 그렇게 보일 것입니다.

사람들에게 당신에게 관심을 가질 이유를 만들어 줘야 합니다. 당신에 대해 더 알고 싶어 하도록 영감을 줘야 합니다.

그들이 진정으로 아끼고, 곁에 없을 때도 생각나는 친한 친구가 되기 전에, 그들에게 도움이 되는 사람이 되는 일부터 시작해야 합니다.

그리고 지금 우리가 하려는 일이 바로 그것입니다. 우리는 사람들에게 도움을 주는 것으로 더욱 깊은 관계를 만들어 갈 것입니다.

이는 기나긴 과정이 될 것입니다. 또한 구직 활동을 시작하기 훨씬 전에 시작해야 합니다. 다른 사람이 "아, 이 사람은 지금 나한테 뭔가 바라는 게 있어서 연락하는 것뿐이구나"라고 생각하게 해서는 안 됩니다.

반대로, 당신은 그들에게 해줄 수 있는 일이 있기 때문에 연락하는 겁니다.

무엇보다도 당신은 한 인간이 습득할 수 있는 가장 강력한 기술 중 하나를 가진 사람입니다. 기계를 뜻대로 다룰 수 있는 능력 말입니다. 당신은 바로 프로그래머입니다.

코딩을 잘한다는 것은 이런 느낌입니다.

혹은, 적어도 당신은 그런 사람이 되어가는 중이지요.

그러니까 당신은 이미 다른 사람에게 다가갈 수 있는 좋은 구실을 하나 갖고 있는 겁니다.

"콜드 콜(cold call)"이라는 말을 들어보셨겠지요. 이는 거의 알지도 못하는 누군가에게 전화해서 뭔가를 팔려고 시도하는 것을 뜻합니다. 쉽지 않지요. 그리고 대다수의 콜드 콜은 상대방이 전화를 끊어버리는 것으로 끝납니다.

하지만 상대방에 대해 더 많은 것을 알수록 통화는 따스해지고, 성공할 확률이 높아집니다.

당신은 지금 뭔가 팔려는 게 아닙니다. 앞서 언급했듯이 전화를 걸지도 않을 거고요. 당신이 할 일은 DM을 보내는 것입니다.

트위터, 링크드인, 디스코드, 레딧(Reddit, 미국의 소셜 뉴스 초대형 커뮤니티 사이트 - 나무위키) 등 어디에서든 가능합니다. 그저 메시지 한 단락으로 접근하는 겁니다.

말씀드렸듯이 대화의 장을 여는 가장 강력한 방법이자 답을 받을 가능성이 가장 높은 접근법은 부담 없이 도움을 제안하는 것입니다.

저라면 이런 단순한 템플릿을 사용하겠습니다. 이 템플릿을 그대로 쓰지 않도록 하십시오. 친구에게 말하는 것처럼 자신의 목소리 톤으로 다시 써보세요.

"[이름]님 안녕하세요, [새 직장 구하신 것/승진/아기의 탄생]을 축하드립니다. 제가 요즘 프로그래밍을 조금 공부하면서 포트폴리오를 만들고 있습니다. 그러다 많은 일을 척척 해내시는 [이름]님이 바로 떠오르더군요. [이름]님의 생활을 더 편하게 만들어 줄 어떤 툴이나 앱 같은 게 있을까요? 연습도 할 겸 제가 [이름]님을 위해 코딩을 좀 할 수 있을 것 같은데 말입니다."

이는 강력한 접근 방식입니다. 개인 맞춤형인 데다 자동 메시지가 아니기 때문이지요. 요즘 사람들은 자동 메시지를 너무나 많이 받기 때문에 그와 조금이라도 비슷하면 바로 무시하는 경향이 있습니다.

이것이 제가 모든 메시지를 수동으로 보내고 자동화에 의존하지 않는 이유입니다. 스크립트나 메일 머지 기능을 사용해서 시간을 절약하는 것보다 천천히 하나씩 메시지를 작성하는 편이 좋습니다.

누군가에게 차단당하는 가장 빠른 방법은 "안녕하세요, 잘 지내세요?" 같은 메시지를 보내는 것입니다. 분명히 이름이 빠져 있지요. 템플릿이라는 증거입니다.

가끔 저는 제 이름 대신 성이 들어간 메시지를 받습니다. "안녕하세요 라슨." 뭡니까, 제가 지금 사관학교에 다니고 있기라도 합니까?

그리고 많은 링크드인 이용자가 이름 앞에 이모티콘을 넣기 시작했습니다. 이러면 자동 메시지를 쉽게 알아볼 수 있습니다. 보통 DM에 이모티콘을 넣지는 않으니까요.

메시지가 "🍜사라님 안녕하세요, 새로운 직장을 찾고 계십니까?"로 시작하면 대량 메시지라는 것을 알 수 있겠지요.

그리고 위에 있는 제 템플릿에는 "우리, 같은 학교에 다녔지요"라든가 그런 비슷한 내용은 없다는 걸 염두에 두십시오. 며칠 전에 만난 사람이 아닌 이상 둘이 어떻게 알게 되었는지 구구절절 늘어놓지 않도록 하세요.

왜냐고요? 사람들에게 서로 어떻게 아는 사이인지 상기시키는 바로 그 행동이 누군가를 뒷걸음치게 하고 이렇게 생각하게 만들기 때문입니다. "이런, 나 이 사람 잘 모르는데."

대화를 계속 이어가는 법

다시 말씀드리자면, 당신의 목표는 대화의 물꼬를 터주는 답장을 받아내는 것입니다.

이런 메시지 서비스 플랫폼은 상대방도 부담스럽지 않지요. 그 가벼움을 계속 유지하도록 하세요.

한 번에 여러 단락의 긴 메시지를 보내서는 안 됩니다. 메시지를 짧고 산뜻하게 보내세요. 당신에게 답장하는 것이 귀찮은 일로 여겨지지 않도록 하십시오.

답을 받으면 당신의 "개인 네트워크 보드"에 메모하기 시작하십시오. 나중에 이 사실을 기억할 수 있도록 말입니다.

그 사람들에게 진짜로 앱이나 툴에 관한 아이디어가 있을 수도 있습니다. 잘 됐군요. 그 아이디어에 대해 질문해 보십시오. 그들을 위해 그걸 만들 수 있을지 살펴보세요.

사용자 인터페이스의 간단한 모형을 스케치하는 것부터 해보십시오. 더 세련되게 보이고 싶다면 모눈종이를 사용하세요. "이런 식이면 될까요?"하고 사진을 찍어 보내십시오.

이는 당신이 그들을 돕는데 진지하다는 것을 확실히 보여줄 것입니다. 그리고 확신하건대, 대부분에게는 새로운 경험이 될 겁니다.

"절 도와주시는 거예요? 저한테 이 앱을 만들어 주신다고요?" 이 제안은 사람들을 기쁘게 할 것이고, 기억에 남을 가능성도 높습니다. 앱 자체는 별 쓸모가 없어도 말이지요.

거기서부터는 그냥 대화의 흐름을 따라가면 됩니다. 그러다 흐지부지될 수도 있지요. 그래도 걱정하지 마십시오. 그냥 둬도 됩니다. 몇 주 뒤면 대화를 이어갈 구실을 또 찾을 수 있을 겁니다.

이런 소셜 미디어 DM의 훌륭한 점은, 전체 대화 내용이 기록된다는 것입니다. 다음에 메시지를 보내면, 그 사람은 스크롤을 위로 올려서 이전 메시지를 읽어보고는 "아, 나한테 그 앱 만들어 준다던 사람이구나."하고 알 수 있을 겁니다. 얼굴을 마주 보고 대화하던 상대방이 고개를 갸웃하며 "그런데 누구라고 하셨죠?"라고 하는 일은 더 이상 없을 것입니다.

다시 강조하자면, 부담 없고 가벼운 분위기를 유지하십시오. 대화가 끊기기 시작하는 것 같아도 문제없습니다. 다른 대화도 수십 개는 예정되어 있으니까요. 다른 대화 상대가 또 있잖습니까. 인맥을 쌓느라 꿀벌처럼 바빠지실 겁니다.

새로운 사람을 만나고 인맥을 넓혀 가는 방법

이미 알고 있는 사람에게 연락하는 법에 관해 이야기했지요. 그런 연결 고리는 해가 바뀌면서 조금씩 약해지기야 했겠지만, 여전히 그대로 남아있습니다.

그런데 완전히 새로운 인맥은 어떻게 만들까요?

이는 쉬운 일이 아닙니다. 그렇지만 이 과정을 조금 덜 까다롭게 만드는 팁을 몇 가지 알려 드리겠습니다.

먼저, 사람과의 첫 만남은 온라인보다 직접 만나는 편이 훨씬 더 강력합니다.

누군가를 직접 만나면 그 사람에 관해 훨씬 더 많은 것을 기억하게 됩니다.

• 생김새와 자세 및 걸음걸이
• 목소리와 말투
• 조명, 소리, 향기, 온도 등 그 장소의 전반적인 느낌
• 그 밖에 수많은 디테일이 기억에 남게 되지요.

몇 주에 걸쳐 메시지를 수십 개 주고받는 것보다, 직접 만나 10분 대화를 나눴을 때 훨씬 더 깊은 관계를 다질 수 있습니다.

밖으로 나가 지역 행사에서 사람들을 만나는 것을 강력하게 추천하는 이유가 바로 이것입니다.

동네 주변의 지역 행사에서 사람들을 만나는 방법

어떤 행사냐고요? 인구가 밀집된 도시에 사신다면, 입맛대로 고를 수 있는 선택지가 수두룩할 것입니다. 매주 테크 이벤트에 최소한의 왕복으로 몇 번이나 갈 수도 있고요.

작은 마을에 사신다면, 꾸준히 지역 행사에 나가서 사람을 만나시는 게 좋습니다. 도서 박람회, 아이스크림 모임, 스포츠 행사 같은 것 말이지요.

교회나 모스크, 혹은 절에 다니신다면, 그곳에 다니는 사람들도 알아 두십시오.

그래요, 터무니없이 들린다는 것 압니다. "축구 경기장 관람석에서 옆에 서 있는 저 사람 말이에요? 저 사람이 제가 개발자로 취직하도록 어떻게든 도와줄 거라고요?"

어쩌면요. 어쩌면 아닐 수도 있지요. 하지만 사람을 얕잡아 봐서는 안 됩니다.

저 사람이 작은 사업체를 운영하고 있을 수도 있습니다.

포춘(Forturne) 500대 기업의 엔지니어링 파트 부사장과 동창일 수도 있고요.

그리고 어쩌면 그 사람도 소프트웨어 엔지니어일 수도 있지요. 무엇보다 세상에는 우리 같은 소프트웨어 엔지니어가 수백만 명은 있잖겠습니까. 그리고 우리가 모두 실리콘 밸리에 살고 있지는 않지요. 😉

새로운 사람을 만나기가 무섭게 다짜고짜 전화를 꺼내 들고 "제 링크드인에 친구 추가를 해도 될까요?"라고 말해서는 안 됩니다.

그 대신 침착한 태도로 자신을 소개하십시오.

이름을 기억하세요. 인맥을 쌓을 때 이름을 외우는 것은 필수입니다. 이름 외우는데 서툴다면, 이름 기억하는 연습을 하십시오. TV 프로그램이나 영화를 볼 때 모든 인물의 이름을 외우려고 노력하는 걸로 이름 외우기를 연습할 수 있습니다. 아주 사소한 배역이라도 말이지요.

이름을 잊었다면, 억지로 맞추려고 하지 마세요. 그저 "성함을 다시 알려주시겠습니까?"하고 물어보고는, 다음에는 확실히 기억하도록 하세요.

악수하거나 주먹 인사(fist bump)를 하십시오. 무엇이든 자연스러운 주제에 관해 대화를 나누세요. 대화가 점점 끊어지더라도 걱정하지 말고, 그대로 흘러가게 두십시오.

인간관계는 오랜 시간을 들여서 쌓아 가는 것입니다. 누군가와 함께 보낸 시간의 총합이 중요한 것이 아닙니다. 더 오랜 기간에 걸쳐 얼마나 자주 만났는가가 중요한 것입니다.

언젠가 또 그 사람을 다시 만날 수 있을 것입니다. 몇 주 후에 똑같은 장소에서 볼 수도 있고요. 그리고 그때야말로 당신이 움직일 때입니다.

"[이름]님 안녕하세요, [전에 말씀하시던 것]은(는) 어떻게 되어가나요?"

지난번 대화가 끝난 지점에서 다시 대화를 시작하십시오. 당신의 "개인 네트워크 보드"에 도움이 되는 인물로서 추가할 만한 사람 같으면, 그 사람에게 "혹시 다음 [요일]에 뭐 하시나요? [다가오는 지역 행사]에 저랑 가실 생각 없으세요?"하고 물어보십시오.

항상 다음 주 행사를 기억해 두도록 하십시오. 그래야 같이 가자는 말을 꺼낼 수 있을 테니까요.

이는 안전한 공공장소에서 사람들과 어울릴 수 있는 좋은 방법입니다. 그리고 당신은 다음 행사 소식처럼 가치 있는 무언가를 사람들에게 제공하고 있지요.

상대방이 관심을 보이면, "그거 잘됐네요. 제가 메시지를 보내거나 행사 세부 정보를 알려드릴 가장 좋은 방법은 어떤 걸까요?"하고 물어보실 수 있겠지요.

짠! 이제 당신은 그 사람의 이메일 주소나 소셜 미디어, 혹은 전화번호를 얻었고, 거기서부터 관계를 시작할 수 있는 겁니다.

이는 느릿한 접근 방법으로 들릴 수도 있습니다. 왜 그렇게 조심스러워야 할까요?

다시 말씀드리자면, 사람들은 바쁩니다. 똑똑한 사람들은 자신의 시간과 개인 정보에 대해 방어적입니다.

세상에는 다른 사람들로부터 이득을 얻어내려는 뱀파이어들이 널려 있습니다. 뭔가를 팔거나, 사기를 치거나, 다단계 마케팅에 끌어들이거나, 개종시키려고 하면서요.

이렇게 사람들이 반사적으로 품는 경계심을 누그러뜨리는 가장 좋은 방법은, 이전의 만남에서 괜찮은 사람이라는 인식을 미리 심어두는 것입니다.

인맥을 최대로 활용하는 방법

네 번째 챕터에서는 인맥을 잘 활용할 수 있는 방법에 대해 조금 더 자세히 다룰 겁니다. 일단 지금은 시간과 에너지의 투자 대상으로 인맥 쌓기를 살펴보도록 합시다.

저는 인맥을 과수원에 빗대어 생각하는 걸 좋아합니다. 관계를 마치 나무심기처럼 생각하는 거죠. 심은 나무가 건강하게 자라게 하려면 정성스러운 보살핌과 관리가 필요합니다.

그렇게 성심껏 키운 인맥이라는 나무가 무럭무럭 자라 멋진 결실을 맺을지 누가 알겠어요. 목표는 계속해서 나무를 심는 겁니다. 훗날 그 나무들이 당신의 삶을 지탱해주는 존재로 거듭날 거예요.

언제나 긍정적인 태도를 유지하세요. 당신이 가진 능력뿐만 아니라 인맥을 활용해서도 주변 사람을 도울 수 있습니다. 대부분의 경우 당신이 각각 알고 지내는 두 사람을 서로에게 정중히 소개해주고 연결해주는 건 좋은 인상을 줄 겁니다.

친절하고 사려 깊으며 기꺼이 도움을 주는 사람이 되세요.

취업을 준비하는 과정이 더디게 느껴지더라도 조급해하지 마세요. 그 과정에서 스스로가 모욕이나 무시를 당했다고 여기지 않도록, 또 타인의 성공을 보며 질투를 느끼지 않도록 마음을 잘 다스리세요.

언제나 선택에 따른 책임을 지게 된다는 걸 기억하세요. 뿌린 대로 거두는 법이니까요. 긍정적인 에너지를 꾸준히 심고 가꾼다면 그에 알맞는 풍성한 결과가 필연적으로 따를 겁니다.

3장: 평판을 쌓는 방법

"좋은 평판을 얻고자 한다면, 자신이 보이고 싶은 모습이 되기 위해 노력하라." - 소크라테스

기술과 인맥을 쌓기 시작했으면, 평판을 쌓을 준비가 된 것입니다.

기술 분야의 완벽한 초보자로서 처음부터 평판을 쌓기 시작할 수도 있습니다. 혹은, 다른 일을 하면서 이미 어느 정도 신용을 쌓아두셨을 수도 있겠군요.

이 장에서는 동료 사이에서 훌륭한 평판을 쌓을 수 있는 실용적인 팁을 드리겠습니다. 이는 프리랜서로서 고객을 확보하고, 첫 직장을 구하고, 커리어를 발전시키는 열쇠가 될 것입니다.

그러면 먼저 제가 평판을 어떻게 쌓았는지부터 말씀해 드리겠습니다.

스토리 타임: 30대의 교사가 어떻게 개발자로서 평판을 쌓았는가?

지난 이야기: 퀸시는 기술 분야의 개발자, 사업가 및 채용 담당자와 인맥을 쌓기 시작했습니다. 그는 부지런히 도시 근방의 해커스페이스나 테크 이벤트를 찾아다녔지요. 하지만 아직 경기장에 올라 자신의 힘을 시험해 보지는 못했습니다...

마침내 용기를 내어 첫 번째 해커톤에 참가했을 때는 이미 코딩 여정을 시작한 지 몇 달이 지난 뒤였습니다.

그러던 어느 날 저는 몹시 어려운 버그와 맞닥뜨렸고, 어떻게 고쳐야 할지 알 수가 없었습니다. 그래서 저는 이런 상황에서 많은 사람이 할 만한 행동을 했습니다. 바로, 인터넷 서핑을 하면서 최대한 일을 미루는 겁니다. 그때 발견한 것이 스타트업 위켄드 에듀(Startup Weekend EDU)였습니다.

스타트업 위켄드는 54시간 동안 진행되는 경연 대회로, 앱을 제작하여 심사위원들 앞에서 선보이는 과정이 포함되어 있습니다. 이러한 행사는 참가자의 코딩, 디자인 및 기업가 정신에 관해 축적한 지식에 보상을 해주지요.

실리콘밸리의 중심부에서 열린 이 특별한 행사에는 교육자와 교육 사업가들이 심사위원단으로 참여했습니다. 이는 성인 교육 분야의 경력이 있는 저에게 이상적인 첫 번째 해커톤으로 보였습니다.

저는 스티브에게 이 행사에 관해 이야기했습니다. 그리고 마법의 말을 했지요. "운전은 제가 할게요." 괜찮은 제안이었죠. 스티브는 운전면허가 없었으니까요.

스티브를 섭외한 후, 산타 바바라 해커스페이스에서 알게 된 개발자를 몇 명 더해 팀을 하나 만들었습니다.

저는 몇 주간 심사위원과 그들이 재직 중인 회사에 대해 알아보면서 행사 준비를 했습니다. 스폰서도 알아봤습니다. 물론 코딩도 소림사의 승려처럼 열심히 수련했지요.

한 달간의 준비 끝에 드디어 그날이 되었습니다. 우리는 칠이 벗겨져 가는 제 차 토요타 코롤라 2005에 올라타고, 에너지 넘치는 음악을 들으며 5시간의 드라이브를 시작했습니다.

가는 길에 우리는 뭘 만들지 논의했습니다. 당연히 교육에 초점을 맞춰야 했고요. 고교생을 대상으로 하는 것이 좋을 것 같았습니다. 심사위원들 회사에서 중점을 두는 대상 학년이 고등학생이었기 때문입니다.

하지만 이 앱이 어떤 기능을 구현해야 할까요? 사람들의 생활을 어떻게 편리하게 해줄 수 있을까요?

제 고교 시절을 떠올려 봤습니다. 1년만 다니고 자퇴했기 때문에 떠오르는 게 많지는 않았지요. (저는 타코 벨에서 일하면서 공부한 끝에 GED(우리는 'Good Enough Degree, 충분히 괜찮은 수준'이라고 부르지요)를 통과하고 마침내 컬리지에 진학했습니다.(GED: General Equivalency Diploma/General Education Development, 미국/캐나다에서 정규 고교 교육을 마치지 못한 사람을 위한 고졸 학력 인증서 - 옥스퍼드 영한사전))

그러나 제 고교 시절 기억 중 몇 년이 지난 지금도 떠오를 정도로 힘들었던 한 가지는, "영어 논문"입니다.

사실 저는 글 쓰는 것은 좋아했습니다. 하지만 엄격한 인용 규칙을 따라야 하는 MLA 포맷(Modern Language Association format, 논문의 참고 문헌 페이지 작성 시 따라야 할 형식 중 하나 - 옮긴이)으로 쓰는 것은 좋아하지 않았지요. 참고 문헌 페이지(Work Cited page) 쓰는 것이 늘 두려웠습니다. 선생님은 언제나 제가 인용 형식을 정확히 따르지 않았다며 점수를 깎으셨지요.

차에 탄 다른 동승자들로부터 그럴듯한 아이디어를 잔뜩 듣고 난 뒤에 저는 이렇게 말을 꺼냈습니다. "저한테 아이디어가 하나 있어요. 참고 문헌 페이지를 만들어 주는 앱을 코딩하는 거예요."

그러자 누군가 웃으며 이렇게 말했습니다. "멋진 생각이네요." (원문: "Out of Sight.", 미국에서 슬랭으로 쓰일 때의 뜻은 '멋지다' - 옮긴이)

그랬더니 스티브가 "어, 그거 좋은 이름인데요. 'C'로 바꿔서 Out of Cite라고 이름을 붙일 수 있겠네요."라고 말했습니다. ("Out of Sight"의 Sight와 Cite(인용하다)가 발음이 같은 점을 이용한 언어유희 - 옮긴이)

우리는 모두 기발하다고 여기며 웃었습니다. 그러고는 어떻게 구현할지 세부 사항에 대해 논의하기 시작했습니다.

행사장에 도착했을 때 그곳에는 약 100명의 다른 개발자들이 있었습니다. 행사장은 개방형 사무실 공간으로, 야트막한 칸막이가 있고 화이트보드를 옆에 배치한 부스들이 차려져 있었습니다.

거기 있던 개발자 중 한 사람에 대해 사람들이 속닥거리는 소리가 들렸습니다. "봐, 저 사람이 작년 대회 우승자야." 팬들에 둘러싸인, 자신만만해 보이는 개발자 쪽을 가리키며 이런 말을 하는 것도 들렸습니다. "어쩌면 저 사람이 자기 팀에 날 끼워줄지도 몰라."

발표와 함께 행사가 시작되었습니다. 누구나 방 앞으로 가서 마이크를 잡고 60초 가량 만들고 싶은 앱 아이디어를 소개할 수 있었습니다.

저는 너무 긴장해서 가슴이 터져버릴 것만 같았죠. 그래서 당연하다는 듯이 첫 순서를 자처했어요. 쇠뿔도 단김에 빼라고 하잖아요?

발표를 하면서 땀을 흘렸고 격한 손짓을 했죠. 이렇게 말하면서요. "인용은 거지같아요. 물론 인용 자체가 거지같다는 말은 아닙니다. 인용이 필요한 순간들이 종종 있습니다. 논문을 작성할 때도 인용을 표기해야 하죠. 하지만 해당되는 인용을 일일이 표기하는 것은 꽤 귀찮습니다. 인용된 자료나 참고 문헌을 알아서 작성해주는 앱을 만든다면 어떨까요? 저와 함께 하시겠습니까?"

침묵이 맴돌았습니다. 제 발표가 끝났다는 것을 알아챈 청중들은 저에게 의례적인 박수를 보냈습니다. 사회자가 마이크를 가져갔고 다음 발표자에게 넘겨주었습니다. 전 경쾌한 발걸음으로 자리에 돌아갔죠.

모든 발표가 끝나고, 팀을 구성하는 시간이 다가왔습니다. 우리 산타 바바라 대표단은 서로를 쳐다보며 말했죠. "아무래도 이렇게 우리가 한 팀인 것 같군요."

우리는 와이파이 비밀번호를 알아냈고 최적의 작업 공간을 잡았습니다. 여닫을 수 있는 문이 있는 고급 사무실이었죠.

저는 화이트보드에 와이어프레임을 대강 그렸고, 이렇게 말했습니다. "클릭 한 번만으로 충분하면 좋겠어요. 웹 브라우저 메뉴바에서 곧바로 기능을 사용할 수 있었으면 합니다."

"마치 브라우저 플러그인처럼 말이죠." 스티브가 덧붙였습니다.

"바로 그거예요. 브라우저 확장 프로그램을 만들어 봐요."

저는 팀원들에게 가장 대표적인 논문 인용 스타일 가이드인 MLA, APA, Chicago를 예시로 제시했습니다.

그리고는 "세 가지 형식을 한꺼번에 생성할 수 있을까요? 그저 복사, 붙여넣기만 하면 되도록 말이에요."라고 물었죠.

"더 좋은 방법이 있어요." 스티브가 답했습니다. "각각의 형식에 대응하는 버튼 여러 개를 만들면, 필요한 인용 형식만 곧바로 클립보드에 복사할 수 있죠."

우리는 빠르게 작업했고, 금요일 밤까지 최소한의 기능만 구현한 제품(Minimum Viable Product, MVP)을 간단히 만들었습니다. 웹사이트의 메타데이터를 가져와서 인용문으로 구조화한 것뿐이지만, 잘 동작했습니다.

이번 프로젝트가 저에게는 첫 번째 해커톤이었기 때문에, 호스텔에 지내면서 불필요한 스트레스를 받고 싶지는 않았습니다. 그래서 다소 무리해서 비싼 호텔 룸을 예약했습니다. 트윈베드 2개가 달린 룸을 팀원들과 함께 썼기 때문에 서로 돌아가며 바닥에서 자야 했지만요.

토요일 아침, 우리의 의욕이 한 단계 더 뜨겁게 끓어올랐습니다. 저는 화이트보드 쪽으로 걸어가 팀원들에게 말했습니다. "웹사이트를 인용하는 것은 물론 좋습니다. 하지만 학생들이 인용하는 자료가 책이나 학술 논문일 때도 많이 있습니다. 이러한 경우에도 마찬가지로 인용문을 생성할 수 있어야 할 겁니다."

우리는 IBSN(각각의 도서를 나타내는 고유한 일련번호)를 통해 인용 정보를 얻을 수 있는 API를 찾았습니다. 그리고 DOI(특정 학술 논문을 나타내는 고유한 일련번호)를 기반으로 학술 논문을 찾고 결과 페이지로부터 데이터를 수집하는 스크립트도 작성했습니다.

토요일 밤이 되었을 때 우리의 브라우저 확장 프로그램을 위한 코드는 거의 완성 단계에 이르렀습니다. 저는 앉아서 발표 슬라이드를 준비하기 시작했죠. 팀원들에게 마지막으로 남은 코딩 작업을 맡긴 채 저는 몇 시간 동안이나 반복하고 또 반복해서 발표 연습을 했습니다.

심지어 그날은 제가 침대에서 자는 차례였지만, 초조함 때문에 잠들 수 없었습니다. 제가 있는 이곳은 바로 기술 생태계의 중심지인 실리콘 밸리였습니다.

교사인 제게 동료들 앞에서 강연을 하는 건 일상적인 일이었습니다. 어떨 때는 수십 명 앞에서 강연하기도 했죠. 하지만 이번은 그때와 달랐습니다.

고작 몇 시간 뒤면 열정적인 개발자들로 가득찬 공간에서 발표해야 했습니다. 박사 학위를 가진 심사위원들 중에는 기술 회사를 창업한 사람도 있었습니다. 그렇게 대단한 사람들이 우리의 결과물을 평가한다고요. 혹시라도 제가 실수를 할까봐 무서웠죠.

도저히 잠이 오지 않아서 저는 메일함을 열었습니다. 스타트업 위켄드(Startup Weekend) 스태프가 보낸 메일이 있었고, PDF로 된 책이 한 권 첨부되어 있었습니다. 그 파일은 기술 스타트업 도서의 고전인 깨달음에 이르는 4단계(4 Steps to the Epiphany)와 린 스타트업(The Lean Startup)의 내용이 혼합되어 있는 비공식 버전의 책이었습니다.

둘 다 2010년대 초반 소프트웨어 제품을 만들고 싶은 사람들에게는 필독 도서였으므로 저는 이미 그 책 모두를 읽은 상태였습니다. 그뿐만 아니라 다른 스타트업 관련 책도 수십 권 읽었죠. 그러다 보니 여러 책에서 얻은 지식이 다소 뒤죽박죽 얽혀서 잘 기억이 나지 않았습니다.

어느덧 4시였습니다만, 저는 여전히 잠들 수 없었습니다. 그래서 차라리 책을 읽기로 했습니다. "사람들이 기꺼이 돈을 지불할 만큼 매력적인 무언가를 만들어라." 이런 종류의 책이 공통적으로 전달하는 메시지입니다. 궁극적인 형태의 고객 검증이죠.

그 순간 저는 깨달았습니다. 내 발표를 진정으로 완성하려면 우리가 만든 제품이 시장에서 수요가 있다는 것을 입증해야 해. 우리가 만들고 있는 앱은 사람들이 실제로 안고 있는 문제를 해결해 줄 거라고 증명해야겠어. 사람들이 기꺼이 지갑을 열 만큼 충분히 가치있는 앱이라고 말이지.

한 가지 아이디어가 떠올랐습니다. 우리 앱을 밖에 가져가서 지나가는 사람들에게 팔아보면 좋겠어.

하지만 그날은 일요일 아침이었죠. 어디에 가야 잠재적 고객을 만날 수 있지? 잠깐, 우리가 머무르는 이 호텔이 마침 스탠포드 대학교 메인 캠퍼스와 가까워.

저는 이벤트 장소에 팀원들을 태워다 줬고, 손을 흔들어 작별 인사를 하며 말했습니다. "고객들에게 현금을 두둑이 받고 돌아올게요."

팀원들은 빙그레 웃으며 "발표에 늦지만 마세요."라고 말했습니다. 그들은 제 말이 농담이라고 생각했을지도 모르겠어요.

하지만 전 진지했습니다. 제 노트북에는 앱을 사용해볼 수 있는 프로토타입이 깔려있었습니다. 저는 GPS에 스탠포드를 입력했고 본격적으로 미션 수행의 길에 올랐습니다.

참고로 전 오클라호마에 있는 매우 저렴한 주립 대학교에서 공부했습니다. 그렇다 보니 세계 최고의 명문 대학교 중 하나인 스탠포드 대학교에 도착하자 부담감이 밀려왔습니다.

스탠포드에 다니려면 연간 50,000 달러의 등록금을 납부해야 합니다. 그에 비해 스탠포드 주차장으로 끌고 온 제 차는 등록금의 1/10 정도밖에 안 되는 가격이었습니다.

주말 오전의 캠퍼스는 유령 도시처럼 텅 비어 있었습니다. 궁전 같이 화려한 유령 도시였지만요. 사람만 없을 뿐 가는 곳마다 동상과 상징적인 아치형 장식이 있었습니다.

저는 스스로에게 질문했죠. 이 시간에 가장 성과지향적이고 열정적으로 공부하는 학생들은 어디에 있을까? 일일이 논문 인용 표기를 작성하는 것 따위에 낭비할 시간적 여유가 없는 학생들은 어디에 있지?

저는 경비원 데스크와 "잡상인 출입 금지"라고 적혀 있는 표지판을 지나쳐 중앙 도서관 쪽으로 걸어갔습니다.

서가 근처를 활보하다 공부하고 있는 소수의 사람들을 발견했습니다. 어떤 아이 하나가 두꺼운 교과서를 읽으며 열심히 필기하고 있었습니다. 찾았다!

저는 그 학생 옆자리에 슬쩍 앉았습니다. "흠흠. 저기요, 혹시 인용(Citation) 좋아하세요?"

"뭐라고요?"

"인용 말이에요. 그러니까 저기, 참고 문헌 같은 거요."

"어..."

"그 왜 있잖아요, 논문 마지막 페이지에 줄줄이 써야 하는 그..."

"참고 문헌 페이지가 뭔지는 저도 아는데요."

"좋아요. 자 이것 좀 보세요." 저는 약장수처럼 외투 자락을 옆으로 젖히고는 200달러짜리 넷북을 꺼냈습니다. 그 학생은 제가 어눌하게 영업하는 걸 잠시 경청해 줬습니다.

제가 한 말은 이랬습니다. "여기 이 브라우저 플러그인 보이시죠. 어느 웹사이트든 가서 버튼을 클릭하면, 짠! 이렇게 인용이 표기됩니다."

학생은 눈썹을 치켜올렸습니다. "MLA도 할 수 있나요?"

저는 흥분을 억누르고 말했지요. "MLA, APA(American Psychological Associatoin, 인용 양식의 하나), 게다가 Chicago(인용 양식의 하나)도 할 수 있어요. 보세요." 그러고는 버튼을 클릭하자 세 가지 형식으로 표기된 인용이 각각 '클립보드에 복사하기' 버튼과 함께 나타났습니다.

그 학생은 다소 감명받은 듯 고개를 끄덕였습니다. 그래서 저는 거래를 시도해 봤습니다.

"제가 지금 이 앱을 연간 구독 요금제로 출시하려고 하는데 말이죠, 지금 가입하시면 1년이 아니라 평생 이용하실 수 있게 해 드릴게요. 어때요?"

학생은 잠시 생각했습니다.

어디선가 침묵은 장사꾼의 가장 좋은 친구라는 말을 들은 적이 있습니다. 그래서 저는 그 불편하게 긴 시간 내내 완벽하게 침묵을 지킨 채 그를 빤히 쳐다보며 기다렸습니다.

마침내 그가 말했습니다. "좋아요, 가입할게요."

"잘 생각하셨어요. 20달러 내시면 됩니다."

학생이 움찔하더군요. "뭐라고요? 그거 비싸네요."

물론 그 당시는 스타트업 회사들이 창업 자금을 지원받던 시대로, 우버(Uber)와 리프트(Lyft)가 시장점유율 경쟁으로 손님을 한 번 태울 때마다 돈을 잃던 때였습니다. 그래서 학생의 반응은 전혀 놀랄 일이 아니었습니다.

하지만 저는 잽싸게 머리를 굴렸죠. "그럼, 지금 현금 얼마나 갖고 계시죠?"

그는 지갑을 뒤적거리더니 말했습니다. "5달러요."

그 꼬깃꼬깃한 지폐를 보고 저는 어깨를 으쓱했습니다. "좋아요, 5달러에 드리겠습니다."

그러자 그 학생이 씨익 웃더군요. 그리고 저는 그에게 설치 안내 메일을 보내줬습니다. 그런 다음, "한 가지만 더 부탁할게요. 같이 셀카 한 장만 찍어 주세요."라고 말했습니다.

제가 폰을 셀카 모드로 바꾸자 그는 미소를 띠기 시작했고, 저는 "여기 보세요. 5달러 지폐를 번쩍 들어 주세요."라고 말했습니다.

그 뒤로 얼마 동안 도서관에서 사람들에게 앱을 홍보한 끝에 간신히 다른 유료 고객을 확보할 수 있었습니다. 그런 다음 팀원들과 프로토타입을 완성하기 위해 서둘러 행사장으로 달려갔습니다.

그날 오후, 저는 지금도 제 인생 최고로 꼽는 발표를 했습니다. 우리는 제대로 작동하는 앱을 라이브 시연했고, 앱은 완벽하게 잘 작동했습니다.

그리고 이제는 우리의 유료 고객이 된 스탠포드 학생들과 포즈를 취한 사진들로 발표를 마쳤습니다. 제가 현금다발을 들어올리자 박수갈채가 터졌습니다.

전체적으로 제 인생에서 가장 짜릿했던 경험 중 하나였습니다. 우리 팀은 2등을 했고, 행사 스폰서 중 한 회사에서 API 크레딧을 받았습니다.

저는 뒤풀이 파티에 가서 부지런히 피자를 먹었습니다. 가능한 한 모든 사람과 교류할 시간을 벌기 위해서였죠. 트위터에서 팔로우도 하고, 사람들과 셀카도 찍고, 그 행사 해시태그도 마구 써먹었습니다.

그 순간은 제 코딩 여정의 분수령이 되었습니다. 그곳에 있던 사람들에게 제가 앱의 디자인과 코딩, 판매까지 할 수 있다는 것을 보여줬지요. 더 중요한 건, 그걸 나 자신에게 보여줬다는 것입니다.

해커톤 순회하기

그때부터 저는 해커톤에 푹 빠졌습니다. 그해 열린 수십 개의 해커톤에 참가했지요. 순회하는 외판원처럼 해안선을 따라 오르내리며 갈 수 있는 모든 대회를 찾아갔습니다.

이때부터는 더 어려워졌습니다. 더 이상 함께할 팀이 없었거든요. 저 혼자 해야 했습니다.

행사장에 도착하면, 저는 가능한 한 많은 사람을 만나고는 단상에 올라가서 심사위원들을 사로잡을 아이디어를 발표했습니다.

사람들이 제 팀에 합류할 때도 있고, 제가 다른 사람들 팀에 합류할 때도 있었지요.

저는 단순히 앱의 디자인만 하는 게 아니라 코딩도 하고 싶었습니다. 그리고 할 수 있는 범위 이상으로 손을 뻗는 일도 종종 있었습니다.

무대에 오르기 직전까지 버그를 고치려고 애쓰던 해커톤도 많았습니다. 가끔 라이브 데모 중에 앱이 갑자기 작동을 멈추는 일도 있었지요.

라스베가스에서 열린 한 해커톤에서는 제가 코드베이스를 엉망으로 망가뜨리는 바람에 슬라이드쇼를 쓸 수밖에 없었습니다. 앱을 계획대로 완성했다면 어땠을지, 팀원이 이를 가상으로 시연하는 모습을 저는 관중석에서 머리를 부여잡고 속절없이 지켜보고 있었습니다. 심사위원들은 만족하지 못했지요.

하지만 저는 계속 노력했습니다. 새로운 동네에 도착해서, 호스텔에 체크인하고, 행사장에 찾아가고, 공짜 피자를 먹을 수 있는 한 잔뜩 먹는 일을 계속했습니다.

우리 팀이 2등이나 3등을 한 적은 셀 수 없을 정도로 많았습니다. 하지만 해커톤에서 완벽하게 우승을 거머쥔 적은 한 번도 없었습니다.

돌파구를 찾다

그러나 샌디에고에서 열린 행사에서는 달랐습니다. 내가 만든 무언가가 관객과 심사위원들을 사로잡아 우승이 기정사실로 여겨질 정도였던 그 기분은 평생 잊지 못할 것입니다.

우리 팀의 우승이 발표된 후 뒷문으로 슬쩍 나가 주차장에서 조부모님께 전화를 드린 일이 생각납니다. 마침내 해냈다고 말씀드렸죠. 제가 제작과 발표에 기여한 앱이 해커톤에서 우승했다고 말입니다.

조부모님께서 소프트웨어 개발이나 해커톤에 관해 얼마나 이해하고 계셨는지는 모르겠습니다. 그저 장하다고만 하셨지요.

그분들이 계시지 않는 지금 종종 그 대화를 돌이켜 보곤 합니다. 저는 그분들의 격려를 마음속 깊이 소중하게 간직하고 있습니다. 개발자가 되려고 미친 듯이 애쓰던 30대 교사를 향한 믿음을 말입니다.

그 후로도 해커톤에 계속 참가했습니다. 계속해서 새로운 팀을 꾸리고 새로운 툴을 배워 나갔죠. 처음으로 API가 작동하도록 만들었을 때의 기분이란 결코 잊을 수 없을 겁니다. 혹은 깃(Git) 명령어가 어떻게 작동하는지 드디어 이해하게 되었을 때를요. 그리고 앱 데모를 위해 함께 진땀을 흘리던 사람들도 결코 잊지 못할 겁니다.

테크크런치 디스럽트 해커톤(The TechCrunch Disrupt hackathon). 디벨로퍼윅 해커톤(The DeveloperWeek hackathon). 프로그래머블웹 해커톤(The ProgrammableWeb hackathon). 백만 달러 상금이 걸린 세일즈포스 해커톤(The $1 Million Prize Salesforce Hackathon). 대규모 해커톤도 정말 많았고, 배우는 것도 정말 많았습니다. 제가 개발자로서 혹독한 담금질을 거쳤던 도가니였던 셈입니다.

그러면서 기술과 인맥을 쌓았을 뿐만 아니라 실제로 해커톤에서 우승할 수 있는 사람이라는 평판을 얻게 되었지요.

이제 닻을 올릴 준비가 되었습니다.

제가 유명인이 된 것입니다.

또한 이 평판은 프리랜서로서 첫 고객을 얻고, 처음으로 개발자로 취직하고, 무엇보다도 저의 개발자 본능을 스스로 신뢰하는 데에 결정적인 역할을 했습니다.

평판이 중요한 이유

사회에서 평판이 하는 역할은 인류의 선사시대까지 거슬러 올라갑니다. 대부분의 부족과 부락에는 누가 누구에게 무엇을 빚졌는지 추적하는 시스템이 있었습니다.

화폐가 생기기 전에는 신용이 있었습니다.

서면 장부가 있었을지도 모릅니다. 혹은 이 모든 기록을 머릿속에 간직하신 어르신이 계셨는지도 모르지요.

이런 원시사회의 회계 외에도, 형태는 없지만 동등하게 중요시되던 '사람의 인상'이란 게 있었습니다. 예를 들면,

"존은 말굽 다는 일에 일가견이 있지."

"제인은 세상에서 이야기를 제일 잘하는 사람이에요."

"세 번의 겨울 전 침략자들과의 전쟁에서 제이의 용기가 우리를 구했어요."처럼 말입니다.

이 예문에는 모두 누군가가 무언가를 잘한다는 내용이 들어있다는 사실을 알아차리셨을 겁니다. 단순히 누군가가 사람 좋고 호감이 간다는 내용이 아니라요.

느긋하면서 현실적인 사람이 되는 것은 분명 쓸모가 있습니다. 하지만 이곳은 '위대한 레보스키(The Big Lebowski, '레보스키'라는 성을 가진 느긋한 건달이 주인공인 코미디 영화. - 옮긴이)' 영화 속이 아니며, 우리가 가진 매력에만 의지해서는 살아남기 어려운 세상입니다.

위대한 레보스키(왼쪽). 그는 직업도 없고 기술도 없고 의욕도 없지만 여유는 넘칩니다.

개발자라면 이런 말을 쉽게 할 수 있겠지요. "아 네, 자바스크립트라면 제 손바닥 들여다보듯 훤합니다. 필요에 따라 어떤 종류의 자바스크립트 앱이든, 생각할 수 있는 어떤 기기에서도 실행되도록 만들어 드릴 수 있어요."

혹은 "저는 언제든 기한 내에 예산 안쪽에서 코딩을 완료합니다."라고 할 수도 있을 겁니다.

하지만 그 주장이 과장이 아니란 것을 어떻게 알 수 있을까요?

한 거짓말쟁이가 이렇게 말한 적이 있답니다.

"딱 한 가지만 잘할 수 있다면, 거짓말에 능통하라."

(이 인용구의 진짜 출처는 알려지지 않았습니다. 하지만 저는 높은 실크 모자에 외눈 안경을 쓴 1920년대 사기꾼을 상상하고 싶군요.)

누구나 거짓말을 할 수 있습니다. 그리고 실제로 거짓말을 하는 사람도 있습니다.

제가 사회 초년생일 때 석사 학위를 위조한 교사를 해고하는 불쾌한 일을 맡은 적이 있습니다. 위조 사실을 몇 년간 아무도 몰랐지요.

그는 매해 연간 서류 작업에 거짓을 보태서 다른 교사들보다 높은 연봉 인상을 받아 냈습니다. 그리고 매해 들키지 않고 잘 넘어갔지요.

그러던 어느 날, 일치하지 않는 사소한 부분이 제 눈에 띄더군요. 저는 그의 파일을 다시 검토하고 몇몇 대학의 기록 부서에 전화를 걸어 그가 학위를 마치려는 노력을 전혀 하지 않았다는 사실을 알아냈습니다.

그를 잡아낸 순간은 마치 스쿠비 두의 한 장면 같았습니다. "너희 망할 꼬마 놈들만 아니었다면 그냥 넘어갈 수 있었을 텐데."("And I would have gotten away with it, if not for you darn kids.", 미국의 인기 애니메이션 'Scooby-Doo'시리즈에 나오는 대사로, 청소년 탐정단 '미스터리 주식회사'의 활약으로 범행이 발각된 악당들이 체포될 때 주로 하는 대사 - 옮긴이)

이 사람이 거리낌 없이 거짓말을 한 덕에 수년간 학교에서 아이들을 가르치고 다른 많은 교사보다 높은 연봉을 받아왔다는 사실은 참으로 열받는 일이었습니다.

거짓말의 전리품은 언제나 탐스럽게 반짝이지요. 그 유혹에 기꺼이 굴복하는 사람도 있습니다.

고용주는 이를 잘 알고 있습니다. 풀스택 자바스크립트 개발자라는 주장을 그대로 믿어서는 안 된다는 걸 잘 알고 있어요. 회사 로고를 넣은 명함, 회사 이메일 주소 및 프로덕션 데이터베이스 접근 권한을 받는 사람을 고를 때는 신중해야 합니다.

고용주가 행동 면접(behavioral interview)을 보는 이유가 바로 이것입니다. 부정행위에 능한 사람을 가려내기 위해서죠.

순진하게 들리겠지만, 저는 사람들 대부분의 천성은 선하다고 믿습니다. 규칙이 아주 공평하다면 대부분은 기꺼이 그 규칙에 따를 것입니다.

하지만 만약 열 명 중 한 명이라도 잘못 고용하면 모두가 더 철저한 조사를 받게 된다는 걸 의미합니다.

최악의 시나리오는 단지 돈을 더 벌기 위해 거짓말을 하는 사람이 아닙니다. 회사의 기밀을 팔거나, 고객과의 관계를 망치거나, 숫자를 부풀린다는 명목으로 법을 어기는 사람입니다.

역사는 자신의 개인적인 이득을 위해 회사 전체에 치명적인 손실을 끼친 직원들로 가득합니다.

그래서 대부분의 대기업에서 개발자를 채용하는 과정은 지독하게 편집증적입니다. 아마 그래야 하겠지요. 하지만 안타깝게도 이는 개발자로 취직하고자 하는 모두를 더욱 힘들게 합니다. 심지어 가장 정직한 지원자도 예외는 아닙니다.

개발자로서 자신이 주장하는 만큼 실제로 강력한 기술을 갖추고 있다는 증거가 필요합니다. 고용주가 필요로 하는 만큼 직업윤리가 건실하다는 증거도 필요합니다.

그때가 바로 평판이 필요할 순간입니다. 이는 불분명함을 줄여 주지요. 상대편의 위험 부담을 줄여 주기도 하고요. 고용주 입장에서는 채용을 결정하고 고용 계약을 체결할 때 안전장치 역할을 합니다.

다시 말해, 평판이 좋은 사람은 다른 지원자들이 줄을 길게 늘어선 정문이 아닌 옆문을 통해 회사에 들어갈 수도 있다는 겁니다.

일부 회사에는 평판에 따라 면접 절차를 단축할 수 있는 사내 채용 담당자도 있습니다. 평판이 좋으면 연봉 협상에서도 유리하지요.

이제, 좋은 평판을 쌓고 상사들에게 인기를 얻을 방법을 알려 드리겠습니다.

개발자로서의 평판을 쌓는 방법

다음은 개발자로서 평판을 쌓을 때 확실한 효과를 거둘 수 있다고 알려진 여섯 가지 방법입니다.

1. 해커톤 참가
2. 오픈소스에 기여하기
3. 개발자를 대상으로 하는 콘텐츠 만들기
4. "누구나 알 만한" 회사에서 일하면서 몸값 높이기
5. 프리랜서 개발자로 작업한 결과물을 모아 포트폴리오 만들기
6. 직접 오픈소스 프로젝트, 회사 또는 비영리 단체를 만들고 운영하기

해커톤과 같은 개발 경진 대회에 참가하는 방법

해커톤은 가장 즉각적으로 자신의 이름을 알리고 인맥을 쌓는 한편 코딩 스킬까지 향상시킬 수 있는 방법입니다.

대부분의 해커톤은 무료이며 누구에게나 열려있습니다. 필요한 건 그저 시간과 여행 경비뿐입니다.

샌프란시스코, 뉴욕, 벵갈루루, 베이징처럼 해커톤이 많이 열리는 대도시에 산다면 행사를 마치고 집에 돌아가 편안히 잠자리에 들 수도 있죠.

제가 살던 산타 바바라는 해커톤이 몇 달에 한 번 드물게 열리는 도시였습니다. 그렇지만 샌프란시스코에 사는 동창이 종종 그의 집에 머무를 수 있게 해준 덕분에 꽤 많은 행사에 참가할 수 있었죠.

해커톤 일정은 꽤 극악무도한 편입니다. 어떻게든 시간 내에 프로젝트를 완성하기 위해 참가자들은 에너지 드링크를 마시고 바닥에서 잠을 자기도 합니다.

그렇지만 점차 해커톤 주최 측이 참가자의 건강 및 행사의 지속 가능성에 신경을 쓰는 추세입니다. 해커톤 참가자 중 아이가 있거나 풀타임 근로자인 이들이 많기 때문에 현실적으로 주말을 통째로 코딩에 쓸 수 없다는 점을 고려하게 된 것이죠.

다가오는 해커톤 행사를 찾는 가장 좋은 방법은 "해커톤"+"거주 중인 도시명"으로 구글에 검색하고 검색 결과로 나오는 다양한 행사 일정을 살펴보는 것입니다. 대부분의 해커톤은 대학, 지역 기업, 또는 교육 관련 비영리 단체에서 주최합니다.

만일 해커톤 우승을 목표로 한다면, 사전 조사를 꼼꼼히 해두는 걸 추천합니다.

해커톤 후원사가 어디인지 잘 보세요. 보통은 개발자를 대상으로 API, 데이터베이스 도구 또는 SaaS(서비스형 소프트웨어) 등을 제공하는 기업인 경우가 많습니다.

이러한 후원사들은 아마 행사장 안에 개발자 지원 부스를 따로 두고 있을 겁니다. 기술 지원 엔지니어는 자사 제품을 홍보하기 위해 사람들에게 해당 툴 사용법을 기꺼이 알려줍니다. 가끔 후원사 부스에서 핵심 직원이나 창업자들을 만날 수도 있는데, 이는 좋은 네트워킹 기회가 될 수 있습니다.

해커톤에서는 종종 "최고의 (스폰서 사의) API 활용"처럼 스폰서에 특화된 상을 제공합니다. 단순히 최우수상을 받기 위해 애쓰는 것보다 특정 스폰서 툴을 프로젝트에 적용하는 데 시간을 들이는 게 더 쉬운 길일지도 모릅니다. 스폰서에 특화된 상도 링크드인이나 이력서에 넣을 수 있습니다. 어쨌든 수상을 했으니까요.

해커톤이 세간의 이목을 끌거나 상금이 상당한 경우라면 우승에 전면승부를 걸어보는 것도 합리적이겠죠.

저는 해커톤에 참여하면서 몇 달치 월세에 해당하는 상금과 몇 년간 무료로 사용 가능한 공동 작업 공간을 얻었고, UN 뉴욕 본부에서 비공개 특별 투어까지 경험할 수 있었습니다.

해커톤 활동 중에 주수입원이 해커톤 우승 상금인 사람들도 만났습니다. 제가 아는 한 개발자는 같은 해커톤에서 스폰서 상을 9개나 동시에 수상했습니다. 프로젝트에 모든 스폰서 툴을 통합시켜서 적용했는데 끝끝내 준우승을 차지했죠.

해커톤에서 자주 마주쳤던 사람이 벤처 투자를 받아 회사를 설립하거나 주목받는 오픈소스 프로젝트를 출시하는 게 그리 놀라운 일은 아닙니다.

해커톤에 정기적으로 참여하는 이들의 야망은 보통의 개발자가 평균적으로 가지고 있는 것보다 훨씬 큽니다. 평일과 주말을 가리지 않고 일하기를 주저하지 않죠. 이들은 프라이팬에서 빠져나와 더 뜨거운 불구덩이 속으로 기꺼이 뛰어드는 사람들입니다.

오픈소스에 기여하는 방법

오픈소스에 기여하는 것도 빠르게 평판을 쌓을 수 있는 방법 중 하나입니다. 대부분의 고용주들은 당신의 깃 커밋 기록이 한눈에 보이는 깃허브 프로필을 유심히 살펴볼 것입니다.

위의 예시는 freeCodeCamp.org에서 수많은 플랫폼 개발과 데브옵스를 담당하는 Mrugesh Mohapatra의 깃허브 프로필입니다. 초록색으로 가득찬 잔디를 보면 그의 활동이 얼마나 왕성한지 알 수 있습니다. 지난 1년 동안 혼자서 무려 2,208회의 기여를 했죠.

Linux 재단이나 Mozilla(Firefox)와 같이 오픈소스 프로젝트를 주관하는 단체들은 대부분 높은 규격의 코드 품질을 유지하고 있습니다. freeCodeCamp도 마찬가지입니다.

깃허브 이슈를 훑어보면 해당 프로젝트와 관련해 어떤 버그가 발견되었는지, 또는 어떤 새로운 기능 개발이 요청되어 있는지를 알 수 있습니다. 이를 기반으로 프로젝트에 기여할 수 있는 코드를 직접 작성하고 풀 리퀘스트를 요청할 수 있는 것이죠. 프로젝트 관리자가 여러분이 보낸 풀 리퀘스트를 머지한다면 이는 큰 자랑거리가 될 겁니다.

테크 기업에 취직하는 가장 좋은 방법 중 하나는 해당 회사에서 관리하는 오픈소스 레퍼지토리에 많이 기여하는 것입니다.

오픈소스에 기여하면 내가 기여한 것이 공개적으로 드러나기 때문에 효과적으로 평판을 쌓을 수 있습니다. 다른 개발자로부터 코드 리뷰와 작업에 대한 승인을 받는 건 곧 개발자로서 사회적 인정을 받는다는 뜻이니까요.

오픈소스를 통해 평판을 쌓는 것에 관심이 생겼다면 Hillary Nyakundi가 쓴 오픈소스 시작하기를 읽어보세요. 오픈소스에 대해 전반적으로 이해할 수 있을 겁니다.

개발자를 대상으로 하는 콘텐츠를 만드는 방법

개발자도 사람입니다. 다른 사람들과 마찬가지로 개발자도 일하지 않거나 깨어있을 때, 친구와 가족과 함께 있지 않을 때 시간을 보낼 수 있는 무언가를 원합니다.

저를 포함한 많은 사람들은 책과 영상 에세이, 또는 비주얼 노벨과 같이 상호적인 활동을 통해 다른 사람들의 생각을 살펴보며 시간을 보내기도 합니다.

많은 사람들이 보통 "콘텐츠"라고 부르는 바로 그것입니다. 창작물을 일회용으로 여기게 하는 어감 때문에 저는 이 단어를 그다지 좋아하지는 않지만요.

소프트웨어 개발은 매우 광범위한 분야라서 다룰 수 있는 주제가 많습니다. 개발자들의 일상을 다룬 브이로그, 코딩 면접 대비 튜토리얼, Twitch에서의 코딩 라이브 스트림, 개발자 인터뷰 팟캐스트 등 다양한 콘텐츠를 찾아볼 수 있죠.

그렇지만 아직 우리가 생각하지 못한 개발자 컨텐츠 범주가 아마 한참 남았을 겁니다. 향후 10년 간 쏟아져 나올 거고요.

영화, 언론, 창작 끌쓰기에 관심이 있다면, 개발자 컨텐츠를 만들면서 효과적으로 평판을 쌓을 수 있습니다.

특정 주제를 선택해서 점점 전문가로서 명성을 떨칠 수도 있겠죠.

예를 들자면 특정 기술 스택과 관련된 튜토리얼에 특화된 콘텐츠를 만들 수 있습니다.

제 친구 Andrew Brown는 주요 데브옵스 시험을 모두 통과한 토론토의 전 CTO입니다. 그는 AWS, Azure, Google Cloud 자격증을 준비하는 무료 강좌를 만들고, 시험 대비 서비스도 운영합니다.

이 세상에는 2천만 명 이상의 소프트웨어 개발자가 있습니다. 이는 당신의 컨텐츠를 소비함으로써 곧 당신이 누구인지 알게 될 잠재적 고객이 많이 있다는 뜻입니다.

유명한 회사에서 일하면서 몸값 올리기

자신을 소개할 때 前 구글러(Ex-Googler) 또는 前 넷플릭스 개발자(Ex-Netflix engineer)라는 표현을 사용하는 걸 본 적이 있을 겁니다.

몇몇 테크 기업의 채용 절차는 철저하고 까다롭기로 악명이 높습니다. 이런 기업에 입사한다는 건 그 자체만으로도 하나의 큰 성과입니다.

기업이 채용 과정에서 지원자의 이전 근무지를 살펴보는 데에는 여러 가지 현실적인 이유가 있습니다. 일단 채용의 실패 가능성을 크게 줄여주거든요.

더 크고 유명한 회사로 이직하며 계급의 사다리를 타고 올라가는 방식으로 당신의 평판을 쌓을 수도 있습니다. 지역의 작은 회사에서 시작해서 포춘(Fortune)지가 선정한 500대 기업으로 이직할 수 있고, 궁극적으로 그보다 더 큰 빅테크 기업에서 일해볼 수도 있겠죠.

물론 대기업에서 일하는 게 모든 사람에게 잘 맞는 건 아닐 겁니다. 그렇지만 업계에서 명망을 얻기 위해서 택할 수 있는 한 가지 방법이라는 건 분명해요. 이와 관련해서는 네 번째 장에서 좀 더 자세히 다루겠습니다.

프리랜서로 일하며 만든 포트폴리오로 평판 쌓기

프리랜서로 회사와 일을 하며 평판을 쌓는 방법도 있습니다.
프리랜서 개발자는 주로 규모가 작은 1인 프로젝트를 맡게 됩니다. 그렇기 때문에 작은 지역에서 이름을 알리고 싶을 경우 이는 좋은 전략이 될 수 있죠.

예를 들어 지역 법률 사무소와 새로운 계약을 따내려 할 때, 이전에 동일한 지역의 은행과 계약한 일을 성공적으로 마무리한 경험이 있다면 큰 도움이 될 겁니다.

이 구역의 대표 주자가 되는 것이 꽤 큰 의미가 있다는 뜻입니다. 물리적으로 회의에 참석할 수 있고 지역 사회에서 인지도가 있다는 점만으로도 온라인 상의 수많은 경쟁자 사이에서 우위를 가지는 개발자를 실제로 여럿 알고 있습니다.

실무 경험을 녹여낸 개발 포트폴리오 만들기

프로젝트를 잘 만들고 나면 결과물을 다른 이들에게 보여주고 싶을 겁니다. 가장 효과적인 건 짧은 영상에 이를 담아내는 겁니다.

사람들은 바쁩니다. 당신의 코드를 직접 컴퓨터에 받아서 실행시켜 볼 만한 여유가 없다는 거예요.

배포된 사이트를 보내는 경우에도 보는 이가 자신이 보고 있는 화면에 담겨있는 의미나 적용된 기술을 단번에 이해하기 어려울 겁니다. 이 프로젝트가 왜 특별한지도 잘 알지 못할 거고요.

그래서 저는 약 2분짜리 화면 녹화 영상을 통해 프로젝트를 소개하는 방법을 추천합니다.

2분 정도면 프로젝트 시연을 하기에 충분합니다. 그 이후에 추가로 세부적인 구현 방법이나 디자인에 대해 좀 더 자세히 다룰 수도 있고요.

그렇지만 가장 중요한 건 언제나 프로젝트 시연 영상으로 시작하는 겁니다. 사람들은 무언가 실제로 작동하는 모습을 시각적으로 보고 싶어 합니다.

일단 프로젝트 시연 영상으로 사람들의 관심을 끌어모으고, 그다음에 당신이 보여주고 싶었던 디테일을 보여주는 겁니다. 큰 맥락을 이해한 후이므로 당신의 이야기가 좀 더 흥미롭게 느껴질 거예요.

또 한 가지 중요한 건 2분이라는 시간이 가진 위력입니다. 2분짜리 영상은 트위터에서 피드를 스크롤 할 때 자동으로 재생이 되며, 자동 재생이 되는 영상은 사람들의 눈길을 사로잡을 확률이 훨씬 높습니다. 재생 버튼을 누르거나 해당 영상을 재생할 수 있는 페이지로 이동해야 하는 허들을 없애주기 때문입니다.

프리코드캠프의 졸업생이 만든 트위터 클론 프로젝트 소개 영상을 예시로 들어보겠습니다. 음성 설명이 없는 영상이고, 2분 동안 UI 데모를 보여주는 정도이지만 여전히 무척 훌륭하죠.

이렇게 만든 프로젝트 시연 영상을 모아 유튜브나 트위터, 깃허브 프로필 또는 개인 포트폴리오 사이트에 올려 활용해 보세요.

그리고 이런 짧은 영상을 만들 때 화면 녹화 프로그램으로 맥 OS에 기본으로 탑재된 QuickTime 프로그램을 사용하는 걸 추천합니다. 만약 윈도우 컴퓨터를 사용하고 있다면 윈도우 10에서 무료로 제공하는 Game Recorder를 사용해도 좋습니다.

이보다 좀 더 강력한 툴을 원한다면 OBS라는 무료 오픈 소스 프로그램을 사용해 보세요. 사용법이 조금 더 어렵긴 하지만 다양한 커스텀 기능을 제공합니다.

영상을 촬영할 때 염두에 둘 점은 영상에 담기는 글자 크기를 최대한 크게 하는 것과, 별도의 마이크를 연결하는 것입니다. 어떤 마이크든지 괜찮습니다. 저렴한 헤드폰에 달린 마이크라도 노트북에 내장된 마이크보다는 나을 거예요.

투자할 수 있는 최대의 시간을 영상 촬영에 투자하세요. 흠잡을 데 없는 영상이 나올 때까지 촬영하고, 또 촬영하세요.

이렇게 프로젝트 시연 영상을 촬영하고 당신의 코드를 설명할 줄 안다는 건 개발자로서의 커리어를 이어가는 데에 있어 귀중한 역량이 될 겁니다. 연습에 들인 시간은 결코 헛되이 사라지지 않으니까요.

직접 오픈소스 프로젝트, 회사 또는 비영리 단체를 만들어 보기

무언가를 스스로 창립한다는 건 개발자로서 평판을 쌓기에 가장 빠른 동시에 가장 위험한 방법입니다.

결과가 어떨지 알 수 없는 곳에 당신의 시간과 돈, 거기에 당신이 가진 인맥까지 걸어봐야 한다는 점에서 위험 부담이 큰 일입니다.

만일 오랜 시간 동안 오픈 소스에 기여한다면 당신은 필히 유명한 개발자가 될 겁니다.

매년 해커톤에 꾸준히 참여한다면 마찬가지로 유명한 개발자가 될 수 있을 거예요.

그렇지만 새로운 사업으로써 프로젝트를 시작하는 경우는 다릅니다. 몇십 년을 투자해도 눈에 띄는 성장을 이루기 어려울 수 있습니다. 그 과정에서 앞서 언급했던 당신의 시간, 돈, 인맥 모두를 허비하면서요.

기업가 정신은 이 책에서 다루는 내용 밖의 주제입니다. 그렇지만 관심이 있는 분을 위해 짧은 조언을 드릴게요.

Entrepreneur(기업가)는 프랑스어로, 이 단어에 담긴 뜻의 핵심은 "위험을 견디는 자"입니다.

대부분의 기업가는 실패합니다. 외부 요인으로 실패하는 기업가도 있긴 합니다. 그렇지만 많은 경우 그들이 감당하고자 하는 위험의 크기를 가늠하지 못하기 때문에 실패합니다.

성급하게 무언가를 새로 만들려 하지는 마세요. 당신이 관심을 두고 있는 분야에 이미 좋은 성과를 내고 있는 조직에서 일하는 걸 먼저 해보세요.

다른 누군가를 위해 일을 하는 건 돈을 받으면서 배우는 것이기도 합니다. 당신이 하고자 하는 일에 대해 속속들이 알게 되고, 그에 따르는 위험에 대해서도 알 수 있습니다. 그리고 당신이 스스로 기업가로서의 여정을 떠나기 전까지 그에 필요한 자금을 모을 수 있다는 의미도 있겠죠.

평판을 망치지 않는 방법

"좋은 평판을 쌓는 데는 평생이 걸리지만, 잃는 건 한순간이다." - 윌 로저스(Will Rogers), 배우이자 카우보이. 그리고 오클라호마 시티가 고향인 나의 우상 중 하나.

평판을 쌓는 일은 단거리 경주가 아닌 마라톤입니다.

원하는 곳으로 향하는 문을 열 수 있을 정도로 강력한 평판을 쌓는 데는 몇 년이 걸릴 수도 있습니다.

그러나 경쟁이 치열한 마라톤과 마찬가지로 발을 한 번 헛디디면 귀중한 시간을 낭비할 수 있습니다. 그러다 다치기라도 하면 경주에서 완전히 탈락할 수도 있고요.

온라인에서 실언하지 마십시오

사람들이 실언하는 일은 늘 일어납니다. 그 언어의 파편은 모두가 움찔하는 짧은 시간 동안 공중에 떠 있다가 결국에는 사라지기 마련입니다.

요즘 사람들은 종종 온라인에서 말실수를 저지릅니다. 절대로 지워지지 않는 잉크로 말이죠.

웹 사이트에서 뭔가를 타이핑하고 엔터 키를 누르는 순간, 이는 데이터베이스에 저장될 것이란 사실을 언제나 기억하세요. 그 데이터베이스는 전 세계의 몇몇 데이터 센터에 백업될 것입니다.

데이터의 존재는 증명할 수 있지만 데이터의 부재는 증명할 길이 없습니다.

어떤 의도나 목적이든지 온라인에 글을 남길 때는 가방에서 고양이가 풀려난 상황을 가정해야 합니다. 그 고양이를 다시 가방에 넣을 방법은 없습니다. 방금 무슨 말을 했건 간에 그 말은 영원히 기록됩니다.

물론 게시물을 삭제할 수는 있습니다. 계정을 삭제할 수도 있고요. 구글 검색어 목록에서 지우는 것도 가능합니다. 그러나 이미 누군가 웨이백 머신(Wayback Machine, 인터넷 아카이브가 만든 디지털 타임캡슐)에 백업한 뒤일 것입니다. 그리고 지금으로부터 몇 년 후 그 데이터베이스 중 하나가 불가피하게 해킹당하더라도 데이터는 어딘가에 계속 남아 언제든 다시 나타날 수도 있습니다.

수다쟁이에게는 무서운 순간이지요. 그러니까 그러지 마십시오. 말하기 전에 생각하세요.

소심하게 들릴지도 모르겠지만, 제 조언은 이렇습니다. 온라인에서 사람들과 다투는 습관을 버리십시오.

어떤 사람들은 "예의 바르게 말할 수 없다면 차라리 아무 말도 하지 말라"는 규칙을 준수합니다.

저는 "칭찬은 공개적으로, 비판은 사적으로" 하는 쪽을 선호합니다.

개발자 커뮤니티에서 누군가 잘하고 있는 모습을 보면 공개적으로 칭찬하고, 어떤 프로젝트에 감명받으면 그대로 말해주는 겁니다.

그렇지만 다른 사람의 기분을 상하게 하는 일은 하지 않으려는 편입니다. 그런 취급을 받아 마땅한 사람에게도요.

싸움에서는 모두가 지저분해 보이지요.

다툼에 끼어들어 편을 가른다거나, 실언을 한 누군가를 사정없이 몰아세우면서 격분한 모습을 보여서는 안 됩니다.

물론 신랄한 논평으로 잠깐 인터넷상에서 점수를 딸 수는 있겠지요. 그러나 동시에 다른 사람들로부터 호감을 잃고 두려움을 얻게 될 수도 있습니다.

저는 불평도 자제하려고 합니다. 그래요, 취소된 항공편에 관해 트윗하겠다고 협박하면 더 좋은 고객 서비스를 받을 순 있겠지요.

하지만 사람들은 바쁩니다. 크게 보면 별것도 아닌 불편을 가지고 징징거리는 글을 읽는 데 귀한 시간을 쓸 사람은 거의 없습니다.

소셜 미디어 활동에 관해 제가 드릴 조언은 그것입니다. 긍정적인 태도를 유지하세요.

강력한 신념에 대한 문제라면 속마음을 털어놓은 걸 말리지 않겠습니다. 다만 타이핑하기 전에 생각하시고, 전송 버튼을 누르기 전에 또 생각하시길 바랍니다.

지키지 못할 약속을 하고는 실망스러운 결과를 내놓지 않도록 하십시오

개발자가 스스로 평판을 망치는 가장 흔한 길은, 지키지 못할 약속을 하고는 실망스러운 결과를 내놓는 겁니다. 이는 반드시 치명적인 실수라 할 수는 없지요. 하지만 좋지 못한 일입니다.

제가 발표 시간까지 프로젝트를 완전히 끝내지 못하는 바람에 제대로 작동하는 앱 대신 슬라이드를 이용해야 했던 라스베가스 해커톤 이야기, 기억하십니까?

그건 저의 코딩 학습 여정을 통틀어 가장 형편없는 순간 중 하나였습니다. 팀 동료들은 예의 바르게 대해 줬지만 틀림없이 저에게 실망했을 테지요. 결국 제가 지나치게 자신만만했던 겁니다. 시간 내에 할 수 있다며 지나치게 많은 것을 약속하고, 제대로 해내지도 못했지요.

자신의 능력은 겸손하게 평가할수록 좋습니다.

밀랍으로 이어 붙인 날개를 달고 태양에 너무 가까이 날아갔던 이카로스 이야기를 떠올려 보십시오. 그가 조금 더 신중하게 접근했거나 조금만 더 천천히 날아올랐다면 어땠을까요. 그럼 날개가 녹는 일도, 아버지를 죄책감 속에 남겨두고 바다에 빠지는 일도 없었을 겁니다.

큰 피터르 브뢰헐(Pieter Bruegel the Elder, 네덜란드의 화가. 장남 피터르 브뤼헐 역시 화가이며, Pieter Bruegel the Younger라고 불린다. - 옮긴이)가 약 1560년에 그린 '이카로스의 추락이 있는 풍경'. 이카로스는 도전자가 될 수도 있었습니다. 역사에 남는 어떤 사람이 될 수도 있었고요. 하지만 그러는 대신 그저 바닷속으로 사라지는 다리가 되고 말았습니다. 그리고 농부와 목동은 굳이 하던 일을 멈추고 그 하찮은 장면을 보려고 하지는 않습니다.

평판을 잃기 전에 중독에서 벗어나십시오

약물이나 음주, 혹은 도박 중독을 겪고 있으나 치료받은 적이 없다면 도움을 구하는 일이 우선입니다. 개발자로서 일을 찾는 과정은 길고도 험하기 때문에 온 신경을 집중해서 최선을 다해야 합니다.

비디오 게임 중독처럼 겉보기에 무해해 보이는 것조차 주의를 산만하게 하고 시간을 지나치게 빼앗을 수 있으므로 자제력을 길러 두는 것이 좋습니다.

저는 의시가 아닌 데다 "마약은 위험합니다"는 연설을 하려는 것도 아닙니다. 하지만 이 말씀을 드리겠습니다. 실리콘밸리의 개발자들이 코딩이나 문제 해결 능력이 어떻게든 향상될 거란 생각에 약물을 남용한다는 이야기를 들어보셨겠지요.

한동안 "극소량의 LSD(마약의 일종) 복용"이 유행했습니다. 필로폰이 유행한 적도 있었고요.

저의 직감은 이렇게 말합니다. 약물 사용이 주는 어떤 이점도 지속 불가능할뿐더러 장기간에 걸쳐 부정적인 결과만 가져올 것이라고요.

다들 한다고 굳이 향정신성 약물에 손을 대지는 마십시오. 다들 해피 아워에 술을 마신다고 따라 할 필요도 없고요. (저는 7년 전 딸아이가 태어난 이후로는 맥주를 한 번도 마시지 않았습니다. 그렇다고 허전함을 느낀 적은 전혀 없습니다.)

중독에서 회복 중인 경우라면, 코딩을 배우고 개발자로 취직하는 일은 스트레스가 상당한 과정이란 걸 염두에 두십시오. 다시 중독에 빠지지 않으려면 자신의 속도를 잘 조절해야 합니다.

서둘러 커리어를 전환하고 너무 많은 것을 이루려고 하지는 마십시오. 그랬다가 낡은 습관이 되살아나고 애써 일군 일은 말짱 도루묵이 될 수도 있습니다.

본업과 사생활을 분리해 보세요

아마 이런 표현을 들어본 적이 있을 것입니다, "사업과 즐거움을 혼동하지 말자."

개발자로서 당신은 영향력 있는 사람이 될 것입니다. 도시에 있는 다른 사람들로부터 어느 정도의 존경을 받게 될 것입니다.

아마도 의사나 우주비행사만큼은 아닐 것입니다. 그래도. 사람들은 당신을 올려다 볼 것입니다.

당신과 같은 일을 하고 싶어하는 사람들과 이야기하게 것입니다.

부를 과시하지 마세요.

다른 사람들보다 더 똑똑한 것처럼 행동하지 마세요.

관계에서 원하는 것을 얻기 위해 권력을 남용하지 마세오.

그로 인해 주변 사람들에게 호감을 얻지 못할 것입니다. 그리고 만약 그러한 행동이 어떻게든 포착되어 온라인에 게시된다면, 남은 경력 내내 계속해서 당신을 괴롭힐 수도 있습니다.

가진 것을 절대 잊지 마세요. 그리고 얼마나 많은 것을 잃어야 하는지도.

내레이터 트릭을 사용해 보세요

제 자신을 격려하기 위해 사용하는 작은 요령으로 이 장을 마치겠습니다.

먼저 본인이 가는 코딩 여정에 스스로가 영웅이라는 것을 기억하세요. 자신만의 마음 극장에서 여러분은 모든 사람들이 보고 있는 사람입니다 - 그들이 응원하는 사람이요.

내레이터 트릭은 머릿속에서 당신의 행동을 다른 사람에게 하는 것처럼 이야기하는 것입니다.

퀸시는 그의 노트북을 겨드랑이에 끼고 해커스페이스를 가로질러 걸어갑니다. 그는 머그잔을 온수기 밑에 놓고 티백 하나를 꺼내 넣습니다. 그는 레버를 뒤로 당깁니다. 그리고 김이 모락모락 나는 물이 머그잔에 가득 찰 때, 그가 낼 수 있는 가장 멋진 영국 억양으로 크게 말합니다: "차. 얼 그레이. 뜨겁게."

말도 안 되는 소리로 들릴 수도 있습니다. 그래요, 그건 말도 안 돼요. 하지만 저는 항상 그렇게 합니다. 그리고 효과가 있어요.

심지어 당신의 인생에서 가장 평범한 순간들조차 머릿속에서 이야기하는 것으로 활력을 얻을 수 있습니다.

당신 앞에 놓인 순간을 명확하고 견고하게 만들어 주며 스스로에게 분명한 목적을 줄 수 있습니다.

당신의 삶을 시대("타코 벨 시대")의 관점에서 생각할 때보다 훨씬 더 효과적입니다. 또는 변곡점("GED 시험 통과")같은 것보다도요.

이런 게 당신의 평판을 쌓는 것과 무슨 상관이 있을까요? 평판은 본질적으로 당신이 누구인지 요약한 것입니다. 주변 사람들에게 당신이 어떤 의미인지요.

자신을 더 진지하게 대하고, 스스로의 삶을 영화처럼 생각함으로써, 여러분은 점차 자신이 누구인지에 따라 일하게 됩니다. 그리고 언젠가 당신이 되고 싶은 사람을 쫓아서요.

자신의 행동을 서술함으로써, 당신은 스스로의 마음 속에서 그 행동에 더 밝은 빛을 비춥니다. 내가 왜 그랬을까? 나는 무슨 생각을 했을까? 거기서 더 나은 움직임이 있었나?

많은 사람들이 자신도 모르는 사이에 스스로 평판을 파괴하는데 그냥 단지 나쁜 습관이 들었기 때문입니다.

수년간 저는 항상 "웃겨야 한다"고 생각했습니다. 저는 자기비하적 유머를 하곤 했습니다. 많은 사람들이 제가 무엇을 하고 있는지 알아차리고 즐거울 거라고 생각했습니다. 하지만 그들 중 많은 사람들이 이해하지 못했고, 제가 바보라는 인상만 갖게 되었습니다.

제가 왜 그랬을까요? 생각건대 초등학교 시절 제가 항상 교실 안의 광대가 되어 사람들을 웃기기 위해 노력했던 때로 인한 것 같습니다.

하지만 수십 년이 지난 지금, 침묵을 웃음으로 채우려는 반사적 행동은 저에게 크게 도움이 되지 않았습니다.

"실수를 반복하면 더 이상 실수가 아닙니다. 그것은 결정입니다." – 파울로 코엘료

어쩌면 이런 나쁜 습관을 눈치채지 못하고 훨씬 더 오래 진행했을 수도 있습니다. 하지만 내레이터 트릭으로 제 행동의 어색함이 드러났습니다.

물론 제가 다른 방식의 생각이나 다른 방식의 행동을 많이 가지고 있다고 확신합니다. 그리고 그러한 것들이 다른 사람들에게 잘못된 인상을 주기 이전에 내레이터 트릭의 도움을 받아 그것들을 인지하고 다듬으려고 합니다.

당신의 평판은 당신의 재산이 될 것입니다.

당신의 이야기 마지막에 되고 싶은 사람이 누구인지 생각해 보세요. 사람들이 당신의 지구에서의 시간을 어떻게 생각하기를 바라는지를요. 그리고 나서 거기서에서부터 거꾸로 적용하면 됩니다.

영화 마지막에 되고 싶은 사람. 사람들이 존경하기를 바라는 그 영웅. 지금부터 그렇게 행동하면 어떨까요?

당신은 성공적인 개발자가 되는 것이 어떨지 상상할 수 있나요? 사람들이 의존하는 소프트웨어 시스템을 구축하는 것도요.

그 미래의 당신 - 그들은 어떻게 생각할까요? 그들은 어떻게 상황에 접근하고 문제를 해결할까요? 그들은 성과에 대해 어떻게 말할까요? 실패에 대해서는요?

단지 미래의 스스로에 대해 생각하는 것만으로도 당신의 생각을 명확히 하는데 도움을 줄 수 있습니다. 당신의 우선순위를요.

저는 종종 허리가 안 좋은 "퀸시 노인"을 생각합니다. 30분마다 화장실에 가기 위해 양해를 구해야 합니다.

하지만 퀸시 노인은 여전히 그가 처한 상황 속에서 일하려고 최선을 다합니다. 관절이 아픈데도 움직입니다. 심란할 때도 열중합니다.

퀸시 노인은 여전히 일을 끝내고 싶어 합니다. 그는 자신이 이룬 것에 자부심을 느끼면서도 크게 과거를 되돌아보지 않습니다. 그는 그날 자신이 무엇을 할 것인지, 어떤 목표를 달성할 것인지 기대하고 있습니다.

저는 종종 퀸시 노인에 대해 생각하고, 오늘 지금의 제 모습으로 되돌아갑니다.

제가 내일 존경할 만한 사람이 될 수 있으려면 오늘 어떤 결정을 내려야 할까요? 그러한 평판을 얻기 위해 수십 년을 기다려야 되는 걸까요? 아니면 제가 미래로부터 그 존경심을 빌릴 수도 있을까요?

미래의 나 자신이 생각할 수 있는 것처럼 생각함으로써, 현재의 나에게 긍정적인 평판을 얻을 수 있는 행동을 할 수 있지 않을까요?

저는 당신이 지금 당장 미래의 명성, 즉 당신의 재산을 활용할 수 있다고 믿습니다. 미래의 자신에 대해서, 그리고 스스로 성취할 것에 대해 생각해 보세요. 그것을 앞으로 나아가는 데 사용하세요.

이러한 도구들(내레이터 트릭과 미래의 모습을 형상화하는 트릭)이 평판의 본질을 생각하는데만 도움이 그치지 않기를 바랍니다. 저는 그러한 과정이 당신의 평판을 올리기 위한 구체적인 단계를 취하는 데 도움이 되기를 바랍니다.

왜냐하면 평판을 쌓아 이름을 떨치는 일이 개발자로서 지속 가능한 성공으로 가는 가장 확실한 길이기 때문입니다.

성공은 많은 사람들에게 많은 것을 의미할 수 있습니다. 하지만 대부분의 문화권의 대부분 사람들은 동의할 것입니다: 성공의 큰 측면 중 하나는 자신과 가족을 위한 음식을 식탁에 올리는 것이다.

이것이 바로 우리가 다음에 이야기할 내용입니다.

4장: 코딩으로 돈 버는 방법 - 프리랜서로서 고객 유치와 구직 활동

기술, 인맥 및 평판을 쌓는 중이라면 개발자로 취직하는 일 자체는 그리 복잡하지 않습니다.

복잡하지 않다고는 말씀드렸지만, 노력을 정말 많이 해야 하는 일입니다. 또 시간이 오래 걸리는 고된 일이기도 하지요.

먼저 제가 첫 직장을 어떻게 구했는지부터 말씀드리겠습니다.

스토리 타임: 30대 교사가 개발자로서 첫 직장을 어떻게 구했을까요?

지난 이야기: 퀸시는 해커톤마다 열심히 참가했고, 몇몇 이벤트에서 우승도 했습니다. 그는 "무서운 신인" 자바스크립트 개발자로 명성을 쌓아가고 있었지요. 아주 숙련된 건 아니었습니다. 그저 이제 막 뜨고 있는 정도...

저는 산타 바바라 시내의 도서관에서 차를 홀짝이고 프로젝트를 제작해가며 종일 하던 공부를 막 마친 참이었습니다.

캘리포니아에 살면서 가장 좋은 점은 날씨입니다. 외곽의 터무니없이 비싼 방 하나짜리 아파트를 렌트할 때는 집 내부가 아닌 바깥에 대한 비용을 지불하는 거라는 농담이 있을 정도지요.

저의 목표는 그 비좁고 백 년은 된 쥐덫 같은 공간에서 꼭 필요한 최소한의 시간만 보내고 남은 시간은 동네를 걸어 다니는 데 보내는 것이었습니다.

아름다운 수요일 저녁이었습니다. 그 주말에 있을 해커톤을 준비할 시간이 아직 이틀 더 남아 있었지요. 게다가 종일 코딩을 공부하느라 머리가 터질 지경이었습니다. 아내는 늦게까지 일을 하기에 저는 할 일을 찾아 달력을 확인해 봤습니다.

매월 첫 번째 월요일마다 저는 그달에 캘리포니아 남부에서 열리는 모든 테크 이벤트를 다 확인해 둡니다. 그래서 에너지만 충분하다면 언제나 가 볼 행사가 있었지요.

아하, 오늘 밤에는 산타 바바라 루비 온 레일즈(Ruby on Rails) 밋업이 있을 예정이고, 이미 가겠다고 신청해 뒀군요.

저는 루비 온 레일즈에 관해 많이 알지는 못했지만 작은 프로젝트 몇 개를 완성한 적은 있었습니다. 루비 온 레일즈보다는 자바스크립트와 파이썬 개발자라 할 수 있었죠.

하지만 저는 인맥 쌓는 걸 게을리해선 안 된다는 걸 잘 알고 있었습니다. 게다가 행사 장소는 겨우 몇 블럭 떨어진 곳이었습니다.

걸어서 행사장에 도착해 보니 몇몇 개발자들이 테이블을 둘러싸고 앉아 이야기를 나누고 있었습니다. 그들 모두가 그 지역의 한 스타트업 회사에서 대규모 루비 온 레일즈 코드베이스의 유지 보수를 맡고 있다는 사실을 곧 알게 되었습니다. 대부분은 그 회사에서 몇 년째 근무하고 있었습니다.

그때쯤 저는 기술, 인맥 및 평판을 쌓는 데 한 해를 보낸 뒤였습니다. 그래서 대화를 따라갈 수는 있었지요.

하지만 동시에 능력의 한계 역시 느꼈습니다. 그래서 저는 겸손하고 절제된 태도를 유지했습니다. 테크 이벤트에서 그러고 있으면 다른 성공적인 개발자들이 대화를 이끌어가더군요.

알고 보니 테이블에 앉아 있던 개발자 중 한 사람은 엔지니어링 파트의 이사급이었습니다. CTO에게 직접 보고하는 직급이었지요.

그리고 알게 된 사실은 그들이 루비 온 레일즈 개발자를 채용할 예정이란 것이었습니다.

저는 제 경력과 능력에 대해 솔직하게 말했습니다. "저는 성인 교육 분야에서 일했습니다. 영어를 가르치고 학교를 운영했지요. 코딩을 공부한 지는 막 일 년쯤 되었습니다."

하지만 그는 놀랄 만큼 침착했습니다. "면접 보러 오시면 우리 팀에 잘 맞는지 알 수 있겠죠."

그날 밤 저는 감전된 기분으로 터벅터벅 귀가했습니다. 설렘보다는 두려움이 훨씬 컸지요.

조금도 준비가 되지 않은 기분이었습니다. 구직 중이었던 것도 아니었고요. 그 당시 저는 저축해 둔 돈을 쓰면서 하루 종일 코딩을 공부하고, 아내의 직장에서 제공해 주는 건강 보험의 혜택을 받고 있었지요.

저는 강박적으로 돈을 아꼈습니다. 사람들은 그걸 가지고 제게 뭐라고들 했지요. 직접 엔진 오일을 갈고, 머리를 깎고, 음식을 테이크아웃하면 곁들여 먹을 쌀밥은 집에서 짓곤 했습니다. 고작 몇 달러 아끼려고요.

10년간 교사로 일하면서 저는 세후 소득의 4분의 1 가까이 저축할 수 있었습니다. 또 크레이그리스트(Craigslist, 판매를 위한 광고 및 토론 공간 등을 제공하는 웹 사이트)에서 옛날 비디오 게임을 구입한 다음 이베이(eBay)에서 되팔기도 했습니다. 어리석게 들릴지도 모르겠습니다만, 제게는 상당한 수입원이었지요.

무엇을 위해 그렇게 아끼고 살았던 걸까요? 뚜렷한 목표가 있었던 건 아니었습니다. 먼 훗날 언젠가 캘리포니아에 집 한 채 사는 게 목표였을까요? 그런데 그런 이유라면 제가 급히 일을 구해야 할 이유는 없었습니다. 저는 제가 특권을 누리고 있다는 사실을 알고 있었고, 그 특권을 최대한 활용해서 매일 더 많은 것을 배우고자 했습니다.

요컨대 아직 개발자로 일할 준비가 되지 않았다고 생각했습니다. 그리고 그 회사에서 저를 채용하는 것이 큰 실수는 아닐까 걱정이 됐지요. 회사 사람들은 제가 얼마나 경험이 부족한지 알아채고는 해고할 텐데, 그럼 전 다음에 면접을 볼 때마다 그 해고 사유에 관해 설명해야 할 겁니다.

물론 지금의 저는 그때 기회를 잘못된 방향으로 보고 있었다는 것을 알고 있습니다. 하지만 이야기를 마저 해보겠습니다.

제가 면접 일정을 잡았을 때 그들은 저에게 이력서를 요청했습니다. 무엇을 해야 할지 확신할 수 없었기 때문에 모든 경력을 적었습니다. 제가 수년간 일했던 모든 학교들이요. (타코 벨에서 드라이브 스루를 담당하는 일은 적지 않았습니다.)

물론 저의 업무 경험 중 코딩과 관련된 것은 없었습니다. 하지만 제가 어떻게 해야 했을까요, 백지 한 장을 건네주었어야 했을까요?

제가 만든 프로젝트의 온라인 포트폴리오를 가지고 있었습니다. 그리고 가장 중요하게도 제가 우승하거나 참여했던 모든 해커톤들의 목록을 가지고 있었습니다. 그래서 저는 그것들을 포함시켰습니다.

저는 인터뷰 직전 마지막 몇 시간 동안 지난 1년 동안 제가 사용했던 모든 루비 온 레일즈 튜토리얼을 복습하며 기억을 되살렸습니다. 그리고 나서 저는 후드티, 청바지, 그리고 배낭 차림으로 사무실에 걸어갔습니다.

여성 사무실 관리자가 친절하게 저를 개발자 팀 자리로 데려가서 소규모 개발자 팀을 소개해주었습니다. 그 자리에 아마 열댓명쯤이 있었는데, 대부분은 청바지와 후드티를 입고 20대 초반에서 40대 후반 사이의 나이였습니다. 여성은 두 명이었습니다.

저는 책상과 케이블이 뒤엉킨 곳을 번갈아 가며 돌아다니며 그들과 일일이 악수를 나누고 제 소개를 했습니다. 교실에서 선생님으로서 학생들의 이름을 외우던 모든 경험이 도움되었습니다. 그들의 이름을 모두 기억할 수 있었기 때문에 그날 오후 퇴근하면서 일일이 이름을 부르며 "만나서 반갑습니다, OO 씨. 함께 일하게 되길 기대하고 있습니다"라고 말할 수 있었습니다.

처음에 저는 엔지니어링 팀장님을 만났습니다. 우리는 작은 사무실로 들어가서 문을 닫았습니다.

벽면의 화이트보드는 Unified Modeling Language(UML) 다이어그램의 스케치로 덮여 있었습니다. 다양한 서버와 서비스 간의 관계를 보여주는 마커 흔적이 건조된 채로 다양하게 남아 있습니다.

저는 그 화이트보드를 계속 쳐다보았는데 팀장님이 그 내용을 저에게 보내 코딩 문제 같은 과제를 설정하고 실력을 보여달라고 할까봐 두려웠습니다. fizzbuzz 문제인가? 이진 트리를 뒤집으라고 할까?

하지만 그는 화이트보드에 대해서는 언급조차 하지 않았습니다. 그냥 내내 저를 뚫어지게 바라보기만 했습니다.

회사는 약 50명의 직원을 고용하고 있었고 많은 벤처 자본 자금과 수천 명의 유료 고객(대부분 소기업)을 보유하고 있었습니다. 회사는 실용적이라고 자신했습니다. 팀장님은 제가 학교에서 무엇을 공부했는지, 과거에 어떤 일을 했는지 전혀 묻지 않았습니다. 정말로 신경쓰는 것은...

팀장님께서 "자, 코딩 할 수 있다는 것을 알아요,"라고 말했습니다. "지금까지 해커톤에서 우승하며 코딩을 해오셨죠. 포트폴리오 프로젝트를 몇 가지 확인했습니다. 코딩을 처음 하는 사람치고는 코드가 꽤 괜찮았습니다. 그래서 제가 할 진짜 질문은 - 우리가 여기서 일하는 것들을 어떻게 배울 수 있을거 같나요? 팀의 다른 개발자들과 함께 일할 수 있을까요? 그리고 가장 중요한 부분인데, 일을 해낼 수 있을 것 같은가요?"

저는 침을 꿀꺽 삼켰고 몸을 앞으로 내밀며 가능한 모든 자신감을 모아 "네,"라고 대답했습니다 "제가 할 수 있다고 생각합니다."

그러자 팀장님께서 말씀하셨습니다. "좋아요. 좋네요. 네. 아래층 쌀국수 식당에 가서 기다리세요. CTO님이 곧 내려가실 겁니다."

그렇게 CTO와 국수를 먹으며 이야기를 나눴습니다. 대부분 듣기만 했습니다. 사람들은 조용한 사람들이 똑똑하다고 생각하는 걸 배웠습니다. 열심히 듣는 것은 여러분이 더 똑똑해지도록 도울 뿐만 아니라 심지어 여러분을 더 똑똑하게 보이게 합니다.

그리고 그 접근법은 효과가 있었습니다. 회의는 약 한 시간 동안 진행되었습니다. 국수는 맛있었습니다. 저는 회사의 역사와 단기 목표에 대해 많은 것을 배웠습니다. CTO는 "좋아요 다시 올라가서 엔지니어링 팀장과 이야기하시면 됩니다."

제가 해냈어요. 팀장님은 저에게 합격을 내어 주었습니다.

여기서 제가 강조하고 싶은 것이 있습니다. 이것은 대부분의 사람들이 그들의 첫 번째 개발자 직업을 얻는 방법이 아니라는 점입니다.
여러분은 아마 이렇게 생각할 것입니다, "이런, 여기 퀸시가 그가 찾고 있지도 않았던 개발자 일로 포레스트 검핑을 하고 있잖아. 우리 모두가 그렇게 운이 좋다면 되는 거겠지".

그 당시의 저에게도 확실히 그렇게 느껴졌습니다. 하지만 다음 섹션에서는 고용주와 개발자 간의 관계에 대해 알아보겠습니다. 그리고 제가 그 직업을 어떻게 얻었는지는 면접자로서의 능력보다는 코딩하던 시간과 네트워킹, 그리고 그 이전에 얻은 평판에 대한 것이 더 많은 부분을 차지하였습니다.

모든 보상 체계와 혜택, 사내 볼링장을 갖춘 어떤 대기업 테크 회사에서 편안하게 할 수 있는 그런 일이 아니었습니다. 그저 제가 교사로서 벌었던 것과 거의 같은 보수를 받는 하나의 계약직일 뿐이었습니다.

하지만 그것은 개발자 일이었습니다. 어떤 회사가 저에게 코드를 작성하는데 비용을 지불하는 것이요.

이제 저는 전문 개발자가 된 것입니다.

고용주는 어떤 것을 바랄까요

10년 뒤로 생각보세요. 이제 저는 테이블 양쪽에 앉았습니다. 한 편에서는 개발자로 채용 담당자에게 면접을 보고 있습니다. 반대쪽에서 저는 채용 담당자로서 개발자들을 인터뷰 하고 있습니다.

저는 구직 중인 개발자들과의 통화에 많은 시간을 보냈습니다. 그들 중 일부는 수백 개의 일자리에 지원했다가 정말 얼마 되지 않는 "통과"만 받고 면접 기회를 얻었습니다.

저는 또한 매니저들과 채용 담당자들과의 통화에 많은 시간을 보내며 그들이 어떻게 채용하고 어떤 인재를 찾는지 더 잘 이해하려고 노력했습니다.

저는 개발자들이 채용 과정에 대해 느끼는 좌절감의 상당 부분이 오해로 귀결된다고 생각합니다.

고용주들은 어느 무엇보다도 한 가지 가치를 중요시합니다: 바로 예측 가능성입니다.

이 후보자들 중 고용주라면 누구를 선호할 것으로 생각하십니까?

X는 종종 천재적인 순간을 가지고 있는 "록스타" 10배속 코더입니다. X는 또한 엄청난 생산성을 자랑합니다. 하지만 X는 종종 동료들에게 심술궂게 굴고, 종종 마감일이나 회의를 놓칩니다.

Y는 평범한 개발자이며 업무 속도가 느리지만 일관성이 있습니다. Y는 동료들과 잘 지내고, 회의나 마감일을 거의 놓치지 않습니다.

Z는 속도가 Y와 비슷하며, 동료들과 잘 어울리고 마감일을 맞출 수 있습니다. 하지만 Z는 지난 3년 동안 세 번이나 직장을 옮겼습니다.

좋아요, 지금까지 제가 말한 모든 것에서 짐작하실 수 있을 겁니다: Y가 선호되는 인재입니다. 그것은 고용주들이 무엇보다도 예측 가능성을 중요시하기 때문입니다.

X는 일부 초임 관리자들이 채용 실수를 저지를 수 있는 함정 후보입니다. X를 고용하는 것이 왜 그렇게 나쁜 생각인지 궁금하다면 우리는 최고의 인재를 해고했습니다. 우리가 내린 최고의 결정이었죠를 읽어보세요.

저는 단지 이 목록에 Z를 추가했을 뿐입니다: 너무 자주 직업을 바꾸지 않도록 하세요.

이직으로 직장을 옮겨다니며 당신의 수입을 꽤 빠르게 늘릴 수 있습니다. 새 직장에 계약하는 순간에도 새로운 일자리를 지원할 수 있습니다. 하지만 그러한 상황은 대부분 고용 담당자들이 선호하지 않을 것입니다.

결국 구르는 돌에는 이끼가 끼지 않습니다. 코드베이스가 어떻게 작동하는지 이해할 시간을 갖기도 전에 코드베이스를 들락날락하게 될 것입니다.

이 점을 고려해 보십시오: 매니저가 새로운 개발자를 데려와 팀에 적응을 시키고 업무 성과를 내게 하기까지 6개월 이상이 걸릴 수 있습니다.

그 시점까지 신규 채용은 기본적으로 회사 리소스를 소모하고, 온보딩을 담당한 동료들이 신입을 도와 코드베이스를 검색하고 버그를 수정해야 하는 방식을 알려주는 시간과 에너지를 소비합니다.

대부분의 고용주는 위험을 감수하려 하지 않습니다

인사 담당자가 개발자를 잘못 채용했다고 가정해 봅시다. 팀에 어떤 영향을 줄까요? 최악의 상황까지 한번 쭉 떠올려 봅시다.

평균적으로 개발자 공석 한 자리를 채우는 데까지 세 달 정도가 걸립니다. 채용이 마무리되기까지 회사에서 처리해야 하는 일은 다음과 같습니다.

• 대표로부터 개발자 채용에 들어갈 적정 연봉 범위 결재 받기
• 채용 공고 작성하기
• 채용 사이트에 글을 올리고 채용 담당자와 소통하기
• 수많은 이력서 살펴보기 - 최대한 많은 회사에 지원하려고 크게 신경 쓰지 않고 이곳저곳 이력서를 때려 넣은 지원자의 이력서가 대다수일 겁니다.
• 면접 진행 준비하기 - 지원자를 회사가 위치한 도시까지 데려오고 그들이 머물 호텔 예약해 주기
• 다양한 팀원과 함께 들어가야 하는 다수의 그룹 면접 진행하기 - 며칠씩 소요되는 경우도 있습니다.
• 최종 후보 추려내고 합류를 제안하기
• ... 그러나 대부분은 제안을 거절할 겁니다
• 계약서를 작성하고 신규 입사자 온보딩 돕기
• 민감한 정보가 포함된 회사의 내부 시스템에 접근할 권한 부여하기
• 팀원에게 새로운 구성원 소개하기, 그리고 그들이 잘 어울릴 수 있도록 돕기
• 구성원이 운영 중인 서비스 및 익혀둬야 하는 레거시 코드베이스를 이해할 수 있도록 여러 달에 걸쳐 내부 교육 진행하기
• 기존 팀의 일하는 방식과 문화에 새로운 구성원을 잘 적응시키기

한마디로 해야 할 일이 무지 많습니다.

신규 팀원이 이 모든 절차를 다 거친 뒤 갑자기 "다른 곳에서 더 좋은 제안을 받아서 거기로 갑니다. 그럼 이만 안녕히 계세요, 여러분!" 같은 말을 남기고 떠나간다고 생각해 보세요.
아니면 새로 채용한 사람이 알고 보니 몇 시간씩 늦게 출근하는 날이 잦아서 도통 신뢰할 수 없는 사람이거나, 약물, 알코올, 도박에 중독되어 치료가 필요한 사람이거나, 분노를 잘 조절하지 못하는 문제가 있거나, 또는 매사에 수동 공격적인 태도로 다른 팀원의 사기를 꺾는 사람이라면 어떨까요.

앞서 나열한 수많은 일을 다시 처음부터 진행하며 또 다른 후보자 물색을 시작해야 할 겁니다.

채용은 정말 힘든 일이에요.

그렇기 때문에 고용주는 위험을 감수하고 싶어 하지 않습니다. 대부분의 고용주는 기준에 거의 부합하는 사람은 뽑지 않으려 할 거예요. 최소 99%의 확신이 든 다음에야 채용에 동의할 겁니다.

고용주가 위험을 기피하기 때문에 구직자도 고달파집니다

채용하는 사람의 입장에서 채용이 얼마나 힘든 일인지를 살펴보았으니 이번엔 지원자의 입장을 한 번 살펴봅시다. 이미 잘 알고 있는 내용일지도 모르겠지만 우선은 쭉 나열해 볼게요.

• 이력서(레쥬메 또는 CV)를 준비하기 - 아마 구직 활동을 지속하는 동안 자신의 결정에 대해 끊임없이 의구심이 들겠지만요.
• 온라인에서 채용 중인 구직 공고를 찾아보고, 회사에 대해 알아보며, 그 자리가 당신에게 잘 맞는 자리일지 가늠해 보기
• 또 이력서 쓰기, 쓰는 도중 서버 오류가 발생해서 작성하던 내용이 날아가 버리거나 자바스크립트 유효성 검증에 실패하는 일이 부디 없길 바라며... - 대부분의 구직 공고는 그들이 원하는 양식에 맞춰 이력서를 재작성할 것을 요구할 겁니다.
• 기다리기 - 지원서를 제출한 뒤 할 수 있는 건 입사 지원서가 처리되길 기다리는 일뿐입니다. 지원자가 많이 몰리는 회사의 경우 모든 지원서를 검토하지 않을 수도 있으며(구글에는 하루에 9,000개의 지원서가 접수됩니다), 지원서를 1차로 거르기 위해 소프트웨어를 사용하는 곳도 있습니다. 사내 채용 담당자는 평균적으로 각 지원서를 훑어보는 데 6초의 시간을 쓴다고 알려져 있습니다. 즉 당신의 이력서를 인간이 훑어보지도 않는 일이 꽤 자주 발생할 겁니다.
• 깜깜무소식 - 지원한 회사로부터 어떤 연락도 받지 못하는 일도 빈번할 겁니다. 회사 입장에서는 당신을 떨어뜨렸다는 소식을 전함으로써 얻는 이득이 거의 없기 때문입니다. 차별을 받아서 탈락했다는 지원자의 소송을 피하고 싶은 것도 있고요. "아쉽지만 저희가 찾고 있는 포지션에..." 같은 내용의 뻔한 이메일을 받았다면 그것만으로도 운이 꽤 좋은 겁니다.
• 무급으로 정신노동 하기 - 무엇보다도 이 모든 걸 잘 알면서도, 어떠한 보상도 없이 주에 몇 시간씩 시간을 들여 이력서를 넣는 건 정신적으로 너무나도 지치는 일입니다.

맙소사! 왜 채용이 고용주에게 악몽 같은 일이고, 지원자에게는 더더욱 큰 악몽인지 아시겠지요.
그렇지만 포기하지 않고 나아가다 보면 언젠가는 원하는 결과에 다다르게 됩니다. 그리고 한 번 물꼬가 트이면 그땐 제안이 비 오듯 쏟아져 내릴 겁니다.

아래는 프리코드캠프의 컨트리뷰터이기도 한 사람이 12주 동안 진행한 구직 활동에 대한 데이터입니다.

총 291개의 지원서를 냈고, 그중 8개 회사에서 입사 제안을 받았네요.

그리고 입사 제안이 들어오면 들어올수록 연봉은 계속해서 높아집니다. 다만 전 세계에서 가장 비싼 도시 중 한 곳인 샌프란시스코에 위치한 회사의 입사 제안임을 감안해 주세요.

마지막 주에 제안받은 연봉은 두 번째 주에 받은 제안의 두 배에 가까운 금액입니다.

이 개발자의 경우 서류 전형을 통과하여 면접 제안을 받은 비율이 상대적으로 높은 편입니다. 협상 능력 역시 좋은 편이었고요. 좀 더 자세한 이야기가 궁금하다면 이 포스팅을 참고하세요.

그렇지만 앞서 이야기했듯, 정문이 아닌 옆문으로도 회사에 들어갈 방법이 있습니다. 제가 이 책을 쓴 이유 중 하나이기도 하고요. 이미 줄이 길게 늘어선 정문 앞에 당신 역시 줄을 서는 걸 바라지 않기 때문입니다.

개발 역량과 인맥을 잘 관리하며 좋은 평판을 쌓다보면 구직 절차의 여러 단계를 건너뛸 수 있습니다

이 책을 통해 여러분은 취업 제안을 받을 "운"의 확률을 높이는 전략을 배웠습니다.

"행운은 준비된 자에게 오는 기회입니다. 기회가 찾아왔을 때 준비가 되어 있지 않다면, '행운'을 잡을 수 없을 겁니다." – 오프라 윈프리

취업에 대한 기회의 폭을 넓히는 것. 이게 바로 개발 역량, 인맥, 평판 모두를 골고루 발전시켜야 한다는 점을 책 전반에 걸쳐 강조한 이유입니다. 본격적인 구직에 앞서 이 세 가지 영역을 처음부터 동시에 챙겨야 한다고 줄곧 말씀드렸죠.

별다른 구직 활동 없이 취업에 성공한 제 이야기가 다소 허황되게 들릴지도 모르겠습니다. 하지만 저뿐만이 아니에요. 저처럼 취업한 사례가 여러분의 생각보다 상당히 더 많습니다.

코딩을 배우는 건 사실 어렵습니다.

하지만 코딩을 하는 방법을 아는 것은 매우 중요합니다.

산업 분야를 막론하고 전 세계 모든 회사의 관리자는 사실상 소프트웨어를 활용해 업무를 자동화하고 싶어 합니다.

그만큼 개발자가 더 필요하다는 뜻이기도 하죠.

가끔씩 테크업계에서도 대규모 구조조정 소식이 들리기도 합니다. 하지만 한 발짝 떨어져 보다 장기적인 관점에서 바라보면 개발자 고용 트렌드는 분명 증가하는 추세라고 할 수 있습니다.

여러분이 강력한 기술, 끈끈한 네트워크, 탄탄한 평판을 바탕으로 구직의 수고를 덜고 좋은 직장을 구할 수 있길 바랍니다.

머지 않아 고용주와 숙련된 구직자들 사이의 매칭이 길고 지난한 구직 절차와 인터뷰 과정 없이 좀 더 수월해지기를 기대합니다.

신입 개발자로 취업 시 연봉 협상을 시도해도 괜찮을까요?

일반적으로 연봉을 높이기 위해 협상을 시도하는 것은 충분히 예의만 갖춘다면 도전해볼 만한 일입니다.

제가 쓴 개발자로 취업 제안을 받았을 때 연봉 협상 방법을 읽으면 좀 더 참고가 될 겁니다.

근본적으로 당신이 얼마나 강력한 패를 지니고 있는지에 따라 좀 더 높은 초봉을 위한 협상 결과가 좌우됩니다.

여러분의 고용주에게는 달성하고자 하는 목표가 있습니다. 고용주가 목표에 도달하려면 여러분이 얼마나 필요한지, 여러분 외에 또 다른 선택지는 없는지에 따라 연봉 협상 결과가 달라지겠죠.

반면 여러분은 생계를 위해 소득이 필요합니다. 여러분에게 이 회사 외에 다른 선택지가 있는지, 플랜 B가 있는지에 따라 마찬가지로 연봉 협상이 달라지겠죠.

다른 회사로부터 일정 수준의 연봉과 함께 취업 제안을 받았다면 이를 협상 카드로 활용할 수 있습니다.

여러분이 가진 최선의 플랜 B가 학교로 돌아가서 학위를 따는 것이라면... 그렇게까지 강력한 협상 카드는 아니겠지만 아무것도 없는 것보다야 나을 겁니다. 이것도 연봉 협상 과정에서 언급할 수 있겠죠.

앞서 묘사한 지루한 채용 절차로 돌아가 봅시다. 고용주는 합격자를 뽑기 전까지 또 다시 최소 수십 단계의 절차를 거쳐야 합니다. 그들은 이미 여러분과 연봉 협상할 계획을 세우고 있을 것이고, 여러분이 더 높은 연봉을 요구하더라도 그다지 놀라지 않을 거예요.

그렇지만 저처럼 갑작스럽게 취업 제안을 받은 경우라면 선뜻 먼저 연봉 협상을 시도하는 것이 꽤 난처할 수 있습니다.

"이 나라는 대체 뭐가 문제야? 취업 제안을 안 받고는 길거리를 마음대로 걸을 수조차 없다니!" – 스미더스('심슨 가족'의 등장인물)

인정하겠습니다. 취업 제안을 받았을 당시 저 역시 연봉 협상을 하지 않았습니다.

제가 좀 더 큰 보상을 요구했어야 했을까요? 아마도요.

당시 제가 그만한 협상력이 있었을까요? 아마 크게 없었을 거예요. 제 플랜 B는 기껏해야 계속해서 해커톤에 나가 경쟁하거나 공공 도서관에서 차를 홀짝이며 코딩을 하는 것뿐이었으니까요.

물론 더 협상을 해서 시급을 조금이나마 올릴 수도 있었을 겁니다. 하지만 취업 제안을 받았을 당시 저에게 연봉은 중요하지 않았습니다. 당시의 저는 그저 돈을 받고 일하는 전문 개발자가 된다는 사실 자체에 도취되어 있었던 거죠.

또 한 가지, 한 회사에서 개발자로 최소 일 년 정도 일을 한 후 임금 인상을 요구하고 싶어질 수 있습니다. 개발자가 임금 인상을 요구하는 방법에서 이와 관련된 내용을 상세히 다루었습니다. 하지만 이런 경우에도 마찬가지로 여러분이 어떤 패를 지니고 있는지가 중요한 협상의 요소로 작동합니다.

개발자로 취업하는 데 리크루터의 도움을 받아야 할까요?

그렇습니다. 개발자로 첫 직장을 잡는 데 도움을 줄 리크루터를 찾을 수 있다면 그래야 한다고 생각합니다.

리크루터가 과소평가 받는 이유(why recruiters are an underrated tool in your toolbox)에 관해서는 자세히 쓴 적이 있습니다.

많은 고용주가 좋은 지원자를 찾아주는 대가로 리크루터에게 수수료를 지급합니다.

그래서 리크루터가 받는 보상은 구직자로서 당신의 목표와 직결됩니다.

1. 리크루터가 받는 수수료는 지원자가 채용되어 처음으로 받는 임금에 따라 책정되기 때문에 당신이 가능한 한 높은 임금을 받을 수 있도록 기꺼이 협상을 도울 것입니다.
2. 리크루터는 회사에 더 많은 지원자를 더 빨리 연결해 줄수록 돈을 더 벌지요. 따라서 다음 구직자로 넘어가기 위해 당신이 최대한 빨리 채용되도록 지원해 줄 겁니다.
3. 지원자가 성공적으로 채용되어 최소 90일간 고용이 유지될 경우에만 리크루터에게 수수료가 지급되기 때문에, 당신이 일을 잘 해낼 수 있으며 회사 문화와도 잘 맞는 지원자인지 확실히 확인해 두려고 할 것입니다.

이 말은, 만약 리크루터가 당신에게 어떤 이유에서든 돈을 요구한다면 위험 신호로 봐야 한다는 뜻입니다.

또한 모든 리크루터가 똑같지는 않습니다. 그들과 일하기 전에 조사부터 해보십시오.리크루터에게 돈을 주는 건 결국 고용주지만, 당신 역시 그들이 후보를 확보하는 데 도움을 주는 것으로 시간을 투자하는 겁니다. 돈보다 귀한 시간을 말입니다.

시간 얘기가 나와서 말인데, 구직을 준비하는 동안에도 코딩으로 빨리 돈을 벌 수 있는 한 가지 방법을 알려드리겠습니다. 바로 프리랜서로 일하는 겁니다.

프리랜서로서 고객을 유치하는 법

막 개발자로 일을 시작하려는 분이라면 구직을 시작하기 전에 프리랜서로 일해보시기를 권해 드립니다. 여기에는 그럴 만한 이유가 세 가지 있습니다.

1. 프리랜서로 고객을 찾는 일이 정규직으로 취직하기보다 훨씬 쉽습니다.
2. 프리랜서는 본업을 그만두지 않고도 할 수 있기 때문에 위험 부담이 덜합니다.
3. 코딩으로 돈을 버는 것도, 전문 개발자로서 포트폴리오를 구축하는 것도 더 빨리 시작할 수 있습니다.

프리랜서로서 고객을 구하는 것이 개발자로 회사에 취직하기보다 훨씬 쉬울 수 있다고 말씀드렸지요. 왜 그럴까요?

지역의 소규모 사업체를 떠올려 보십시오. 가족끼리 운영하는 작은 식당일 수도 있고, 가게나 배관 회사, 혹은 로펌일 수도 있겠지요.

대화형 웹 사이트, 백 오피스 관리 시스템, 또 공통 작업의 흐름을 자동화하는 도구를 통해 이익을 얻는 사업체가 얼마나 될까요? 대부분이 그렇지요.

그렇다면 그러한 시스템을 구축하고 유지 보수할 소프트웨어 개발자를 정규직으로 고용할 수 있는 회사는 얼마나 될까요? 그리 많지 않습니다.

바로 프리랜서가 필요한 순간이지요. 프리랜서는 더 경제적으로 상황에 맞춰 일할 수 있습니다. 작은 사업체의 경우 단일 프로젝트나 단기간을 위해 프리랜서를 고용할 수 있습니다.

활발하게 인맥을 쌓고 계신 중이라면 당신이 만나는 사람 중 누군가가 고객이 될 수도 있습니다.

예를 들어 웹 사이트를 업데이트하려는 동네 회계사를 만날 수도 있겠지요. 상담 일정을 관리하는 기능이나 신용 카드 결제 기능을 추가하고 싶어 할 수도 있고요. 이들은 작은 사업체에서 필요로 할 만한 일반적인 기능이며, 당신이라면 이를 제법 능숙하게 구현할 수 있을 겁니다.

ERP 시스템(기업자원관리 시스템), CRM 시스템(고객관계관리 시스템), 재고 관리 시스템, 또는 셀 수 없이 많은 기타 도구 중 한 가지가 필요한 작은 사업체의 경영자를 만날 수도 있습니다.

대부분의 경우 오픈 소스 툴을 사용한 시스템의 설치 및 환경 설정이 가능합니다. 그런 다음 고객에게 사용법을 알려줄 수 있지요. 또한 문제가 발생했을 때 당신에게 연락하면 바로 고쳐주는 대가로 매달 서비스 요금을 청구할 수도 있습니다.

프리랜서 작업에 계약서가 필요할까요?

계약서의 표준 양식을 찾아서 상황에 맞게 작성한 다음 그걸 승인해 줄 변호사를 찾는 것을 추천해 드립니다.

동네 빵집의 웹 사이트나 소셜 미디어 페이지 업데이트를 돕는 일로 계약서를 쓰는 것이 어색하게 느껴질 수도 있습니다. 하지만 그럼으로써 전체 거래가 그저 구두로 계약하는 것보다 더 전문적으로 느껴질 것입니다.

작은 사업체가 수천 달러를 가지고 당신을 고소할 가능성은 작습니다. 그러나 그런 일이 생긴다면, 계약서를 작성해 두길 잘했다는 생각이 들 겁니다.

프리랜서로 일할 때 단가를 어떻게 책정해야 할까요?

현재 직장에서 받는 급여에서 시급을 계산한 뒤 시급의 두 배로 책정할 수 있습니다. 단가가 다소 높은 것처럼 느껴지겠지만, 프리랜서 일이 정규직 일보다 훨씬 어려운 점을 감안하면 그렇지 않습니다. 알아야 할 게 많기 때문이죠.

또 다른 방법으로는 프로젝트별로 단가를 책정할 수도 있습니다. 예컨대 어떤 시스템을 배포하고 구성하는 비용을 1,000달러로 산정할 수 있겠죠.

다만 프로젝트 유지보수 기간을 분명히 해두는 것을 잊지 마세요. 작업이 끝나고 3년이나 지난 후에 고객이 그동안 아무도 유지보수 하지 않은 시스템을 고쳐달라고 요구한다면 꽤 난감할 테니까요.

고객으로부터 프리랜서 대금을 확실하게 받으려면 어떻게 해야 할까요?

저를 포함한 많은 프리랜서들은 일을 시작하기 전에 선불로 대금의 절반을 요구하는 편입니다. 그 후 작업을 절반 정도 완료해서 어느 정도 고객에게 보여줄 만한 결과물이 나오면 나머지 절반의 대금을 요구합니다. 간단하고 편리한 방법이죠.

항상 프로젝트를 실질적으로 마무리하기 전에 모든 대금을 미리 수금하세요. 그렇게 해야 고객이 아직 지급되지 않은 대금을 볼모로 삼아 추가적인 작업을 요구하지 않을 거예요.

미리 모든 대금을 받았다면 사후에 고객을 도와줄 때 고객을 위해서 계약 범위를 넘어선 추가적인 작업을 해주고 있다는 인상을 줄 수 있습니다.

반대로 작업을 완료하고도 대금을 모두 받지 못했다면 고객이 추가적인 일을 요구할 때 이 일까지 해준다면 남은 대금을 지급해줄 수 있는지 저자세로 물어볼 수밖에 없겠죠.

Upwork나 Fiverr 같은 프리랜서 웹사이트를 사용해야 할까요?

만약 시골 지역에 있어서 현지에서 고객을 찾기 어렵다면 프리랜서 웹사이트의 도움을 받을 수도 있을 겁니다. 하지만 그런 경우가 아니라면 프리랜서 웹사이트를 이용하는 걸 추천하지는 않습니다.

프리랜서 웹사이트에서 계약을 따내려면 전세계에 있는 프리랜서들과 경쟁해야 하기 때문이죠. 여러분보다 생활 물가가 저렴한 도시에 사는 사람도 많고, 여러분과 달리 평판을 신경쓰지 않기에 고객에게 저품질의 작업물을 제공하는 사람도 일부 있을 겁니다.

이러한 웹사이트들은 남들보다 파격적인 단가로 매우 저렴하게 노동력을 제공해야 겨우 계약을 따내는 "치킨게임" 상황을 조장합니다.

지역 사회 네트워크를 통한 고객 탐색에 집중할 수 있다면 굳이 이러한 해외 프리랜서들과 경쟁할 필요가 없습니다.

프리랜서 개발자를 구하는 경우에도 마찬가지입니다. 프리랜서를 고용하고 싶다면, 대면으로 만날 수 있는 지역 사회의 일원과 함께 일하는 것을 강력히 추천합니다.

다년간 여러분과 같은 도시에 살았고 여러분과 비슷한 사회적 모임에 참석하는 사람이라면 여러분을 이용하려는 경향이 덜할 것입니다. 양측 모두가 각자의 평판을 신경쓸 수밖에 없기 때문에 업무에 있어서 협력적인 관계를 구축하는 일에 심혈을 기울일 것입니다.

또한 서로의 포트폴리오에 성공적인 협업 사례로 남을 수도 있습니다.

프리랜서 일을 그만두고 정규직으로 취업해야 할 때는 언제입니까?

프리랜서로 활동하며 생계를 유지할 수 있다면, 프리랜서 일을 계속하고 싶을 수 있습니다. 프리랜서로 경력을 쌓고 언젠가 소프트웨어 개발 에이전시를 자체적으로 구축해서 여러분을 도와줄 다른 개발자를 고용할 수도 있겠죠.

반대로 안정적인 정규직 일자리를 원하는 경우에도 프리랜서 일을 하다보면 행운이 찾아오기도 합니다. 프리랜서 고객과 오랫동안 협업하다 보면 정규직 전환을 제안해오는 경우가 있기 때문이죠. 고객 입장에서 프리랜서를 정규직으로 전환하면 비교적 낮은 시급으로 개발자를 고용할 수 있어 경제적으로 합리적입니다. 여러분은 주 40시간씩 일하는 안정적인 일자리를 얻을 수 있고 고객은 정해진 근무 시간 동안 여러분의 기술을 안정적으로 활용할 수 있습니다.

또 정규직으로 취직을 하게 되었어도 몇몇 프리랜서 고객을 유지할 수도 있습니다. 이는 소득을 보충해주는 좋은 공급책이 될 겁니다. 그렇지만 개발자로서의 첫 직장에 몸과 마음의 모든 에너지를 쏟아붓게 될 거라는 점을 명심하세요. 다음 장에서 좀 더 자세히 다루겠지만, 최소한 첫 직장은 그럴 겁니다.

전문적인 개발자로 취업한 첫 해는 얼마나 험난할까요? 다음 장에서 이야기 해봅시다.

5장: 개발자로서 첫 직장에서 성공하는 방법

“배는 항구에 있을 때 안전하지요. 하지만 그러려고 배를 만든 게 아닙니다.” - 그레이스 호퍼(Grace Hopper), 수학자, 미 해군 소장, 그리고 컴퓨터 과학의 선구자.

개발자로서 첫 직장을 구하면, 진정한 배움은 그때부터 시작됩니다.

다른 개발자 동료들과 함께 생산적으로 일하는 방법,

대규모 레거시 코드베이스를 탐색하는 법,

버전 관리 시스템(Version Control Systems), 지속적 통합(CI, Continuous Integration) 및 지속적 배포(CD, Continuous Delivery) 툴, 프로젝트 매니지먼트 툴(project management tools) 등을 배우고,

엔지니어링 파트의 상사 밑에서 일하는 법, 마감일 전에 일을 끝내는 법, 그리고 수많은 애매함을 헤쳐 나가는 법도 배우게 될 것입니다.

그중에서도 가장 중요한 깨우침은 자기 관리법입니다.

가면 증후군(Imposter Syndrome, 유능하고 사회적으로 인정받는 사람이 자신의 능력에 대해 의심하며 언젠가 무능함이 밝혀지지 않을까 걱정하는 심리 상태를 가리키는 용어 - 두산백과)처럼 우리가 모두 겪을 수 있는 심리적 장벽을 극복하는 방법, 그리고 당신의 한계와 그것을 어찌어찌 뛰어넘는 방법을 깨우칠 것입니다.

스토리 타임: 30대의 교사는 어떻게 개발자로서 첫 직장에서 성공했을까?

지난 이야기: 퀸시는 그 지역 테크 스타트업 회사에서 첫 개발자 일을 시작하게 되었습니다. 그는 대규모의 정교한 코드베이스를 관리하는 12명의 개발자 중 한 명으로 일할 예정이었습니다. 그리고 자신이 하게 될 일에 관해 아는 것이 아무것도 없었습니다...

새벽 4시에 잠이 깼습니다. 그리고 다시 잠들 수 없었지요. 아무리 애써도 잠은 오지 않고, 불안과 공포 때문에 속이 쓰렸습니다.

저는 10년 동안 교육 분야에서 일했습니다. 과외 교사로 시작해서 학교의 교사가 되고, 그다음에는 학교 이사직을 맡았지요.

몇 시간 뒤면 저는 개발자로서 맨 밑바닥부터 시작하게 됩니다.

지금까지 배우고 성취한 것 중에서 이 새로운 커리어에 도움이 될 만한 게 있을까요?

저는 불안할 때마다 하는 것을 하러 나갔습니다. 바로 달리기입니다. 어둠 속에서 헤드램프를 출렁이며 언덕을 달려 내려갔지요. 해변에 도착해서 해안선을 따라 달리고 있자니 나무 위로 해가 떠 올랐습니다.

집에 돌아왔을 때 아내는 벌써 출근하는 중이었습니다. 아내가 제게 걱정하지 말라며 말했습니다. "일에 관해 아무것도 모른다는 이유로 해고된다 해도 난 변함없이 당신을 사랑할 거야."

새 직장에 도착해 보니 아무도 없었습니다. 교사 시절 저는 정확히 오전 7시 30분에 학교에 도착하곤 했습니다. 하지만 소프트웨어 개발자 대부분은 그렇게 일찍 일을 시작하지 않는다는 사실을 곧 깨달았습니다.

그래서 저는 입구 근처 복도에 책상다리로 앉아 넷북으로 튜토리얼을 보며 코딩을 하고 있었습니다.

직원 한 명이 겁먹은 표정으로 제게 걸어오더군요. 아마 제가 불법 침입자인 줄 알았겠죠. 하지만 저는 제가 그 회사에서 일하게 된 사람이라고 안심시키고, 안으로 들여보내 달라고 설득했습니다.

비상구 표시등 불빛에만 의존한 채 텅 빈 개방형 사무실을 가로질러 개발자 자리를 향해 걷고 있으려니 비현실적인 기분이 들었습니다.

저는 빈 스탠딩 책상 하나 위에 넷북을 올려놓고 코딩 튜토리얼을 마쳤습니다.

잠시 후 주위에 불빛이 깜박이기 시작했습니다. 상사가 도착했군요. 처음에 그는 저의 존재를 신경 쓰지 않았습니다. 그저 곧바로 책상 앞에 앉아 기계식 키보드를 두들기기 시작했지요.

그러더니 마침내 말을 걸었습니다. "라슨 씨, 중요한 첫 근무일이네요! 준비되셨나요?"

솔직히 조금도 준비되지 않았습니다. 하지만 자신감을 보여주고 싶었지요. 그래서 제가 가장 좋아하는 80년대 영화 중 하나인 "빅 트러블(Big Trouble in Little China)"에서 처음 등장한 명대사를 읊었습니다. "태어날 때부터 준비되어 있습니다(I was born ready)."

이 말을 백만 번쯤 들어보셨겠죠. 사실 이는 1986년 잭 버튼이 친구 왕치(Jack Burton, Wang Chi. 영화 "빅 트러블" 속 인물들)에게 했던 대사로, 죽음의 창고에서 천 년 묵은 마법사와 맞설 준비를 하면서 한 말입니다. 그 당시 부모님이 이 영화를 보도록 허락해 주셨다는 게 믿기지 않지만, 보여주셨다는 사실에 그저 감사하고 있습니다.

상사가 말했습니다. “좋습니다. 이제 컴퓨터를 드릴게요.”

“아, 컴퓨터라면 이미 갖고 있습니다.” 저는 제 200달러짜리 넷북을 톡톡 치면서 말했습니다. “얘한테 리눅스 민트가 설치되어 있고요, 제가 이미 이맥스(.emacs) 파일을 커스터마이즈해서 쓸 수 있도록 해놨고…”

“우린 맥북 매장이나 다름없어요.” 그는 물품 보관 창고를 향해 걸어가면서 말했습니다. 그러고는 거기서 잠시 부스럭거리더니 나왔습니다. “이걸 쓰세요. 3년 된 모델이긴 하지만 잘 작동할 거예요. 공장 기본값으로 초기화 해뒀거든요.”

저는 이미 제 넷북 설정에 익숙하고 그걸로 훨씬 더 빨리 작업할 수 있다고 말했지만 그는 조금도 받아주지 않았습니다.

“우리 모두 똑같은 툴을 쓰고 있어요. 그럼 협업이 훨씬 쉬워지지요. 설정보다 관례가 우선(Convention Over Configuration)이란 거, 아시죠?”

저는 그 “설정보다 관례”라는 말을 그때 처음 들었는데, 그 뒤로도 며칠간 수시로 들었습니다.

개발자들이 하나둘 출근하는 사이 저는 새 작업용 컴퓨터의 환경을 세팅하느라 몇 시간을 보냈습니다.

우리 팀이 “스탠드업 미팅”을 시작한 건 거의 오전 10시가 다 되었을 때였습니다. 모두 화이트보드 옆에 둥글게 둘러서서 그날 할 일에 대해 돌아가며 얘기했습니다.

다들 빠르고 정확하게 상황을 업데이트하더군요.

제 차례가 되어 저는 제 소개를 하기 시작했습니다. 다른 누구도 아닌, 산타 바바라 스타트업 이벤트의 주최자이자 훌륭한 마라톤 선수인 마이크가 들어왔을 때부터 전 이미 완전히 긴장한 상태였습니다. 그는 아침에 벌써 한 30마일 정도 뛰고 와서 미니 당근(Baby Carrot, 당근의 한 품종으로 새끼손가락만 한 사이즈)을 우적우적 먹고 있었습니다.

제가 말을 마치자 마이크는 저를 반갑게 맞이하며 자기가 주최한 몇몇 이벤트에서 절 본 적이 있다고 말했습니다. 그런 다음 그가 작업 중인 일에 관한 15초짜리 업데이트를 했습니다.

전체 미팅은 다 해서 10분 정도밖에 걸리지 않았고, 끝나자마자 각자 자기 자리로 돌아갔습니다.

저는 마침내 새 랩탑에서 회사 코드베이스를 실행할 수 있었습니다. 최근 5년간 성장해 온 루비 온 레일즈 앱이었지요. rake stats 명령어를 실행했더니 수백만 줄의 코드가 나타났습니다. 덜덜 떨리더군요. 저걸 어떻게 다 이해하지요?

턱수염을 기른 걸걸한 인상의 옆자리 개발자가 말했습니다. “아 그거 대부분은 그냥 패키지예요. 진짜 작업해야 할 코드베이스는 약 100,000줄밖에 안 되는걸요. 걱정하지 말아요. 하다 보면 금방 감이 올 거예요.”

저는 침을 꿀꺽 삼키고 속으로 생각했습니다. '수백만 줄보다 적다니 거참 잘 됐군.'

“그건 그렇고 저는 닉이에요. 도움이 필요하면 바로 말해요. 전 이 코드베이스 때문에 몇 년째 고생하고 있거든요. 아마 제가 도와줄 수 있을 거예요.” 그가 자신을 소개하고 말했습니다.

그 후 며칠간 저는 맞닥뜨리는 모든 내부 시스템에 관해 닉에게 질문을 퍼부었습니다.

결국 닉은 그의 채팅 상태를 “코딩 중”으로 해놓고 노이즈 캔슬링 헤드폰을 쓰더군요. 저한테서 등을 빙그르르 돌리고는 “나도 일 좀 하게 혼자 내버려 둬.”라는 제스처를 취했지요.

팀이 돌아가는 방식에 관해 제가 처음으로 배운 교훈 중 하나는 바로 이것입니다. 환영해 주는 사람을 너무 많은 질문으로 지치게 하지 말 것. 좀 더 스스로 익히려고 노력해야 합니다.

하지만 이 코드베이스는 너무나 방대했고, 얼마 안 되는 인라인 주석과 팀 내에 띄엄띄엄 공유된 정보를 제외하고는 문서화된 부분도 별로 없었습니다.

제 주변에 앉은 동료 개발자들이 지금까지 비공개로 작업해 온 코드였기 때문에 Stack Overflow에 물어본다고 해서 어디에 어떤 로직이 사용되었는지 알 수 있는 상황이 아니었습니다. 떠듬떠듬 길을 찾아가는 수밖에 없었어요.

그래서 저는 질문별로 답을 알고 있을 것 같은 사람을 붙들고 귀찮을 정도로 질문을 하기 시작했습니다. 그렇지만 이런 방식은 저를 향한 팀원들의 신뢰를 빠르게 소진하는 일인 것처럼 느껴졌어요.

과도한 자기 검열이었던 거죠. 그러다 보니 단순한 질문을 할 때조차 저는 점점 더 위축되어 갔습니다. 모르는 게 있어도 최소 2시간은 스스로 문제 해결을 시도해 본 뒤에만 질문을 하자는 규칙을 만들고 지키려고도 해보았습니다.

몇 시간 동안 문제를 해결하지 못해 허덕이다 결국에는 도움을 요청하곤 했습니다. 제가 오전 내내 삽질했다는 걸 알게 된 매니저는 "왜 진작 도와달라고 말하지 않았어요?"라고 묻기도 했습니다.

저를 힘들게 했던 또 다른 부분은 모놀리식 아키텍처와 그에 포함된 다수의 마이크로서비스, 즉 코드 베이스 자체를 이해하는 일이었습니다.

코드 베이스에는 수천 개의 단위 테스트와 통합 테스트가 포함되어 있었습니다. 새로운 코드를 작성한다는 건 곧 테스트 코드 역시 함께 추가해야 한다는 뜻이었죠. 테스트 코드는 당신이 작성한 코드가 의도대로 작동하고 있다는 점과 기존에 쓰인 코드의 정상 동작에 영향을 미치지 않았다는 점 두 가지 모두를 확인하는 데에 큰 도움을 줬습니다.

그렇지만 제가 작성한 코드는 자주 "빌드에 실패"했습니다. 충분히 테스트했다고 생각했지만, 관련이 없다고 생각한 다른 부분이 제대로 작동되지 않게 만드는 문제를 유발했죠. 제 코드로 인해 유발된 문제가 해결되기 전까지는 다른 팀원이 작업한 내용을 머지할 수 없으니 이는 팀원들을 성가시게 만들었습니다.

일주일에 몇 번씩이나 빌드에 실패하는 일이 발생했습니다. 물론 저만 이런 실수를 한 건 아니었죠. 그렇지만 모두 제 잘못인 것처럼 느껴졌어요.

개발자의 자질이 부족한 것처럼 느껴지는 날이 많았습니다. "미쳤었나 봐. 나 같은 게 하루아침에 갑자기 개발자가 되겠다는 결심을 했다고?" 이런 말을 혼잣말로 내뱉곤 했어요.

그리고 몇 년 전 제가 코딩의 길에 첫발을 내디뎠을 때 개발자 친구들에게서 들었던 말이 자꾸 귓가에 맴돌았습니다.

"어릴 때부터 코딩을 해온 사람들과 어떻게 어울릴 작정이야?"
"네가 잘할 수 있는 걸 계속하는 게 낫지 않겠어?"
"야, 새로 배워야 할 게 산더미 같을걸."

점점 더 컴퓨터 앞을 벗어나 있는 시간이 길어졌습니다. 회사에는 간식이 가득 들어차 있는 탕비실이 있었어요. 저는 간식을 챙겨온다는 핑계로 점점 더 자주 자리를 비웠습니다. 내가 지금 여기서 뭘 하고 있는지 모르겠다는 끔찍한 기분이 드는 걸 미룰 수만 있다면 어떤 핑계든 써먹을 수 있을 것 같았습니다.

특히 초반 몇 달은 정말 힘들었습니다. 아침마다 진행되는 스탠드업 미팅에서 저를 제외한 모두가 열려있는 버그 티켓을 해결하고, 새로운 기능을 내보내면서 빠르게 앞으로 달려가는 것 같았어요. 저는 공유할 게 아무것도 없었어요. 어제 진행하고 있던 태스크를 오늘도 여전히 하고 있었으니까요.

"오늘이야말로 내가 잘리는 날이 되겠지." 매일 아침 두려움에 떨며 일어나서 회사로 향했습니다.

그렇지만 막상 회사에 가보면 모든 사람은 꽤 친절했고, 인내심 있게 저를 대했습니다. 정말 모르겠는 문제가 있으면 도움을 요청했어요. 저는 시간이 지나면서 조금씩 성장하고 있었고, 버그 한두 개 정도를 고치기도 했습니다.

또 코드 베이스를 훑는 속도도 빨라지고 있었습니다. 제 코드에서 에러가 났을 때 원인을 추적하는 속도도, 맡은 기능을 운영에 내보내는 속도도 모두 전보다 빨라졌습니다.

대표님 방에 불려 갈 때면 여전히 이런 생각이 머릿속을 가득 채웠습니다. "아, 올 게 왔구나. 이제 진짜 쫓겨나는구나." 그렇지만 막상 가보면 버그 몇 개를 고치는 일이나 새로운 기능 개발 태스크를 배정받는 게 전부였어요. 휴, 정말이지.

막상 상대는 아무 생각도 없는데 저 혼자 분명 해고를 당할 거라는 공포에 잠식당해 있었습니다. 비현실로 느껴질 만큼 정말 생경한 경험이었죠.

물론 전에도 "가면 증후군"에 대해 들어본 적은 있습니다. 하지만 제가 그걸 겪고 있는 줄은 몰랐지요. 전 그저 "형편없는 코딩 실력" 증후군에 시달리고 있는 게 분명했거든요. 그렇지 않나요?

어느 날 문득 옆자리의 닉이 몹시 초췌해 보이더군요. 그래서 부엌에서 소다 한 캔을 가져다주겠다고 했습니다.

제가 음료수를 갖고 돌아오자 그는 캔을 따고 한 모금 들이켜더니 의자에 등을 기대고는 코드로 가득한 자기 모니터 화면을 뚫어져라 쳐다보았습니다. "있잖아요, 이 버그 말이에요. 이거 하나를 고치려고 3주째 애쓰고 있어요. 요즘엔 꿈에서도 디버깅을 할 정도라니까요."

"버그 하나를 고치는 데 3주요?" 제가 물었죠. 그런 건 한 번도 들어본 적이 없었습니다.

"어떤 버그는 다른 것보다 유난히 까다로워요. 이건 특히나 애먹이는 버그 중 하나지요."

마치 누군가에게 연어로 뺨을 철썩 얻어맞은 것 같은 기분이 들더군요. 그때까지 저는 개발을 시간을 정해놓고 할 수 있는 일거리들로 여겨 왔습니다. 말하자면 어떤 버그를 고치는 데 반나절이면 되는데 그보다 더 걸리면 뭔가 잘못하고 있는 거죠.

하지만 여기 닉을 보면, 캘리포니아 주립 대학에서 컴퓨터 과학 학사 학위를 취득하고 동일한 코드베이스를 몇 년째 다루고 있는데도 버그 하나 해결하는 데 3주나 쩔쩔매고 있는 게 아니겠습니까.

어쩌면 제가 자신에게 너무 엄격했는지도 모르겠습니다. 제가 고쳐온 버그 중 몇 개는 "반나절이면 되는 버그"가 아닌 "2, 3일은 필요한 버그"였을지도 모릅니다. 그래요, 물론 저는 경험도 얕고 속도도 느렸지요. 하지만 그렇다고 해도 저 자신을 너무 비현실적인 기준에 맞추려고 노력하고 있었던 게 아닐까 싶었습니다.

어떤 기능을 추가하면서 시간을 분배하다 보면 "5일 걸리는 기능"이나 "2주 걸리는 기능"을 맞닥뜨리는 일도 있겠지요. 버그를 고칠 때 시간을 분배하는 작업을 해보진 않았지만 아마 비슷한 양상을 보일 것입니다.

집에 돌아와 가면 증후군에 관해 더 찾아봤습니다. 읽을수록 제 불안증의 상당 부분이 설명되더군요.

그 후 몇 달간, 저는 팀원들과 협업하면서 코드베이스에 기능을 추가하는 일을 계속했습니다. 여전히 힘들고 머리가 터질 것 같았지만 조금씩 수월해지기 시작했습니다.

매일 점심시간이면 팀원들과 보드게임을 하며 친목을 다졌습니다. 어느 주인가는 사내 체스 토너먼트가 있었습니다.

몇 라운드 후에 저는 CEO와 대결하게 되었습니다.

CEO가 체스를 두는 방식은 정통적인 스타일과는 거리가 멀었습니다. 고수들이라면 거의 하지 않는 방식으로 게임을 시작했지요. 그래서 초반에는 제가 승기를 잡을 수 있었습니다.

하지만 게임을 진행할수록 서서히 그가 게임의 승부를 가져가기 시작하더니 마침내 우위를 점하고 저를 이겼습니다.

회사를 운영하면서 체스 실력을 갈고닦을 시간을 어떻게 만드는지 물어보자 그가 말했습니다. "아, 딱히 시간 내서 체스를 두진 않아요. 일 년에 한두 번 하는 게 다입니다."

그는 강의라도 하려는 것처럼 손을 앞으로 내민 채 잠시 말을 멈췄다가 이렇게 말했습니다. "제 삼촌은 호승심이 강한 체스 선수였지요. 그리고 이건 삼촌이 제게 해 주신 단 하나의 조언입니다. 상대방이 한 번 움직일 때마다 속도를 늦추고, 말을 저렇게 움직인 목적이 무엇인지 상대방의 관점에서 게임을 이해하려고 노력해라."

그는 고개를 꾸벅 숙이고는 미팅이 있다며 양해를 구하고 떠났습니다.

몇 년간 저는 그가 한 말을 곱씹어 보곤 했습니다. 그리고 이 조언이 그저 체스에만 국한되는 것이 아니라 어떤 대립적인 상황에서도 쓸 수 있다는 사실을 깨달았습니다.

계속 반복해야 하는 작업은 자동화하는 것이 맞습니다

제가 소프트웨어 개발에 관해 배운 또 하나의 교훈을 말씀드리겠습니다. 팀에서 제일 경력이 얕은 저에겐 모두가 기피하는 "단순노동"이 곧잘 주어지곤 했습니다. 그중의 하나는 "빌드 지킴이"였지요.

누군가 빌드를 망가뜨릴 때마다 저는 우리의 메인 브랜치 최신 버전을 풀(pull)해서 가져오고 git bisect 명령어를 사용하여 빌드를 망가뜨린 커밋을 찾아내곤 했습니다.

그 커밋을 열어보고 테스트를 실행해서 뭐가 잘못된 건지 알아봤습니다. 그런 다음 빌드를 무너뜨린 당사자에게 메시지를 보내 고쳐야 할 부분을 알려줬습니다.

제가 이 작업을 하는 속도는 아주 빨라졌습니다. 혼란스러운 버그 리포트와 막연한 기능 추가 요청으로 가득한 하루를 보내고 있노라면 누군가 빌드를 망가뜨려 주기를 고대하게 되었지요. 그럼 전 순식간에 쓸모 있는 사람이 된 기분을 누릴 수 있을 테니까요.

얼마 지나지 않아 팀원 한 사람이 이런 말을 했습니다. "빌드가 이렇게 자주 망가지니까 이 작업은 자동화하는 게 좋겠어요."

저는 아무 말도 하지 않았지만 속으론 상처받았습니다. 별로 좋은 생각 같지 않았죠. 고작 스크립트가 피와 살을 가진 개발자인 저만큼 문제의 커밋을 잘 찾아낼 리가 없잖겠습니까?

며칠 걸리긴 했지만 팀원 중 누군가가 결국 스크립트를 만들어 냈습니다. 그렇게 저의 빌드 지킴이 일은 끝나고 말았습니다.

빌드가 망가졌다는 메시지를 받고 잠시 후에 어떤 커밋이 빌드를 망가뜨렸으며 누가 고쳐야 할지 알려주는 메시지를 받는 건 참 낯선 기분이었습니다.

저는 분했습니다. 아무 말도 하지 않았지만 속으로는 이렇게 생각했지요. "그건 원래 내 일이야. 저 스크립트가 내 일을 빼앗았어."

지금 그때의 제 반응을 돌이켜보면 그저 웃음이 나옵니다. 40대가 되어서도 여전히 일주일에 몇 번이고 만사를 제쳐놓고 빌드를 지키러 달려가는 제 모습을 상상해 보면 말이지요.

사실 실제 업무에서는 작업을 자동화할 수 있는 경우, 즉 컴퓨터가 안정적으로 수행할 수 있도록 개별 단계로 세분화할 수 있는 작업이라면 자동화하는 게 맞습니다.

그 시간에 할 수 있는 더 흥미로운 일이 아주 많으니까요.

XKCD(미국의 웹툰 https://xkcd.com - 옮긴이)에 나온 이 표는 어떤 작업이 자동화에 시간을 투자할 가치가 있는지 파악할 수 있도록 해줍니다.

선배들로부터 배운 교훈

저는 다른 팀원들로부터 많은 것을 배웠습니다. 마이크에게는 제품 디자인 컨셉을 배웠지요. 또 그는 저를 해변으로 데려가 함께 달리면서 발 앞꿈치로 뛰는 법을 가르쳐 줬습니다. 발뒤꿈치가 땅에 닿기 전에 앞꿈치로 땅을 차는 법이었지요. 그렇게 하면 관절에 무리가 덜 갑니다.

그리고 애자일(agile) 소프트웨어 엔지니어링 개념은 닉에게 배웠습니다. 그는 도서관에서 좋은 소프트웨어 개발 책을 골라 줬고, 집들이 파티에도 초대해 줘서 그의 아이들도 만날 수 있었지요.

그 회사에서 일 년 정도 근무한 뒤, 저는 스스로 뭔가를 시도할 때가 됐다고 느꼈습니다. 온라인 강의를 들으며 프로젝트를 몇 가지 해보고 싶었지요. 그래서 CTO와 자리를 마련하여 일을 그만두겠다고 얘기했습니다.

제가 말했습니다. "절 고용해 주셔서 감사합니다. 저는 틀림없이 회사에서 가장 실력이 없는 개발자였는데도 말이지요."

그러자 CTO는 웃음을 터뜨리고는 말했습니다. "맞아요. 라슨 씨가 처음 들어왔을 때 팀에서 가장 실력이 없는 개발자였지요. 사실 지금도 팀의 최약체라고 할 수 있지요."

저는 어색하게 웃으면서 그를 보며 눈을 깜빡거렸습니다. 혹시 제가 그만둔다고 해서 기분이 상한 건가 싶었지요.

그러더니 그가 말했습니다. "하지만 그건 영리한 겁니다. 라슨 씨는 영리한 분입니다. 밴드에서는 언제나 가장 실력이 부족한 뮤지션인 편이 좋으니까요. 언제나 자신보다 뛰어난 사람들에 둘러싸여 있도록 하세요. 그게 바로 성장하는 길입니다."

2주 후, 저는 제 코드에서 당일 변경 사항을 체크인하고 제 앞으로 오픈된 티켓을 넘겼습니다. 맥북은 공장 초기 설정으로 리셋하고 상사에게 돌려줬습니다.

그리고 팀원들과 악수하고는 캘리포니아의 저녁 공기 속으로 발을 내디뎠습니다.

커리어를 계속 이어줄 프리랜서 일감들을 머릿속으로 나열하며 저는 땅을 박차고 달리기 시작했습니다. 그 후에는 테크 분야의 고동치는 심장부, 샌프란시스코 소마(SoMA, South of Market San Francisco)에서 다리 하나 건너인 오클랜드에서 아파트를 물색했습니다.

저는 이제 1년의 경력을 가진 전문 개발자입니다.

새로운 꿈을 꾸고 새로운 곳으로 나아갈 준비가 되었습니다.

저는 스타트업의 세계로 출발합니다.

개발자로서 첫 1년을 보내며 배운 점

저는 현업 개발자로서 첫해에 많은 일을 해냈습니다. 스스로 점수를 매긴다면 B-가 되겠네요.

하지만 이 모든 것을 처음부터 다시 할 기회가 주어진다면 어떤 일들은 다른 방식으로 해보고 싶습니다.

팁을 조금 드리겠습니다. 이 팁을 이용하여 배움은 극대화하고 고뇌는 최소화하길 바랍니다.

자아는 문 앞에 두고 오십시오

소프트웨어 개발 분야에 뛰어드는 사람들의 대다수는 가장 밑바닥부터 시작합니다. 그러면서 달게 될 직함 중 하나는 “주니어 개발자”겠고요.

중년의 나이에 “주니어” 딱지를 다는 것이 조금 어색하게 느껴질지도 모르겠습니다. 하지만 조금만 참고 노력하면 그 단계를 넘어갈 수 있습니다.

제가 매일 같이 직면했던 문제는 바로 이것입니다. 전 이미 한 분야에서 10년이라는 경력을 갖고 있었지요. 경력이 하나도 없는 신입사원은 아니었습니다. 물론 개발은 처음이었지만, 가르치는 일이나 사람들 관리하는 일에는 경험이 풍부했습니다. (가장 최근 교사직을 맡았을 때는 30명의 직원을 관리했습니다.)

그러나 지금껏 쌓아온 모든 경력에도 불구하고 저는 여전히 주니어 개발자였습니다. 그야말로 초짜에 신출내기 신입이었지요.

“저는 원래 상사였어요. 베이비시터는 필요 없다고요.”라고 소리 지르고 싶은 심정이었지만, 사실 제게는 베이비시터가 꼭 필요했습니다.

제가 실수로 프로덕션을 망가뜨리면 어쩌지요? 앱에서 보안 취약성을 노출하면요? 데이터베이스를 통째로 지우면 어쩌죠? 아니면 뭔가 중요한 걸 암호화하고선 키를 잃어버리면요?

이런 대형 사고는 언제든 일어날 수 있습니다. 게다가 주니어 개발자만 그런 실수를 하는 건 아니지요.

실무에서 주니어 개발자란 도자기 가게의 황소나 다름없습니다. 조심해서 걸으려고 하지만 움직일 때마다 근처에 있는 모든 걸 깨부수는 황소 말입니다.

팀원들에게 인정받고 싶은 마음에 초조해하지는 마십시오. 석박사 학위라든지, 수상 이력이라든지, 혹은 시장으로부터 표창장을 받은 일에 대해 자랑하고 싶어도 참으세요. (사실 마지막 일은 절대로 제게 일어날 리 없지만 말입니다.)

작업을 힘들게 할 뿐 아니라 당면한 과제에 집중하기 어렵게 만들기 때문입니다.

개발자로서 커리어를 시작한 초반의 몇 달 동안 저는 과거에 성취한 것들을 일종의 안정제처럼 써먹었습니다. “뭐 제가 코딩 실력이 형편없긴 하지요. 하지만 영문법을 가르치는 능력은 가히 경이롭다고 할 수 있답니다. 제가 학교를 운영했다는 얘기 했나요?”

손은 키보드 위에, 눈은 코드 에디터를 향하고 있을 때는 과거의 자신은 잊어야 합니다. 어제의 성공은 오늘 밤에 음미할 수 있습니다. 오늘 하루 일을 다 마친 다음에 말이죠.

하지만 지금 이 순간만큼은 초보자로서 겪게 되는 모든 감정을 다시금 받아들여야 합니다. 당장 눈앞에 있는 과제에 집중해서 일을 마쳐야 합니다.

어쩌면 그저 가면 증후군일지도 모릅니다

제가 아는 거의 모든 사람이 가면 증후군을 경험한 적이 있습니다. 내가 있을 자리가 아닌 것 같은 기분, 당장이라도 팀원들이 당신의 코드가 얼마나 형편없는지 알아차리고 “진정한 개발자”가 아닌 것을 밝혀낼 것 같은 기분이지요.

그 기분이 완전히 사라지는 일은 없습니다. 언제나 마음속 깊은 곳에 도사리고 있다가 뭔가 새로운 걸 시도하려고 할 때 고개를 들지요.

“이 에러 메시지 해결하는 것 좀 도와주시겠어요?” “어… 저한테 물어보시는 건 별로 도움이 안 될 텐데요.”

“이 기능을 구현하는 데 저와 페어 프로그래밍(Pair Programming, 애자일 개발 방법 중 하나로, 하나의 컴퓨터에서 두 사람의 프로그래머가 짝을 이루어 작업하는 방식)을 해주시겠어요?” “어… 저 말고 적당한 사람을 찾지 못하신다면요.”

“곧 있을 컨퍼런스에서 한마디 해주시겠어요?” “어… 제가요?”

제가 아는 시니이 엔지니어 중에는 경력이 10년 이상인데도 여전히 가면 증후군으로 고통받는 사람들도 있었습니다.

당신이 부족하거나 아직 준비되지 않았다고 느낄 때, 그건 그저 가면 증후군일지도 모릅니다.

물론 누군가 제게 메스를 건네면서 “심장 수술하는 걸 도와주세요”라고 말한다면 저 자신이 부적격자로 여겨지겠지요. 어찌 보면 정말로 할 수 없는 분야에서 능력 밖의 일이라고 느끼는 건 당연한 겁니다.

문제는, 계속해서 소프트웨어 개발을 해왔고 뭔가를 할 수 있는데도 영문 모를 불안으로 고통받는다는 사실입니다.

저는 의사가 아니지만, 제 직감은 이렇게 말합니다. 대부분의 경우 가면 증후군은 더 많이 연습하고 자신감을 쌓으면 시간이 흐르면서 점차 가벼워질 것이라고요.

하지만 아무 때고 튀어나올 수 있습니다. 저도 여전히 뭔가 새로운 일이나 오랫동안 하지 않았던 일을 할 때면 가면 증후군이 튀어나오려는 걸 느끼는걸요.

이를 해결하는 열쇠는 그저 받아들이는 겁니다. “이건 아마도 그저 가면 증후군일 거야.”하고요.

그리고 계속 앞으로 나아가시면 됩니다.

같은 관심사를 가진 사람들을 찾되, 너무 한쪽에만 치우치지 않도록 하십시오

처음 개발자로 취직하면 다른 개발자들과 함께 일하게 됩니다. 만세! 운명 공동체를 찾으셨네요.

그들과 많은 시간을 함께 보내면서 아주 친밀한 관계로 여겨지기 시작할 것입니다.

하지만 주변의 비(非) 개발자들도 잊지 마십시오.

앞서 제 경험담에서 마이크에 관한 언급을 한 적이 있었지요. 스타트업 이벤트를 주최하던 프로덕트 매니저 말입니다. 그는 기술자는 아니었습니다. 그의 코딩 지식은 한정되어 있었지요. 하지만 저는 회사의 다른 누구 못지않게 그에게서도 많은 것을 배웠다고 말할 수 있습니다.

일을 하다 보면 다른 부서 직원들과 함께 일할 기회도 있을 겁니다. 디자이너, 프로덕트 매니저, 프로젝트 매니저나 IT 부서, QA 부서, 마케팅 부서, 재무 경리부도 포함해서 말입니다. 이분들에게서도 많은 것을 배울 수 있습니다.

물론 팀의 다른 개발자들과 끈끈한 관계를 쌓는 데에도 집중해야 합니다. 하지만 언제나 다양한 사람에게 흥미를 갖도록 하세요. 점심시간이나 회사 행사에서 여러 사람과 어울려 보십시오. 그들 중 누군가가 당신이 기술이나 인맥, 혹은 평판을 쌓는 데 도움을 줄 수도 있습니다.

너무 빨리 전문 분야를 만들고 거기에 안주하지는 마십시오

저는 코딩 여정을 막 시작하려는 사람들에게 종종 이런 조언을 주곤 합니다. “일반적인 코딩 기술(자바스크립트, SQL, 리눅스 등등)을 먼저 익힌 후에 실무에서 전문 분야를 만드십시오.”

말하자면, 가장 일반적인 툴의 원리를 파악하면 덜 보편적이지만 동일한 원리의 툴도 익힐 수 있다는 얘기입니다.

예를 들어, 일단 PostgreSQL을 배우면 MySQL은 쉽게 배울 수 있습니다. Node.js를 배우면 Ruby on Rails나 Java Spring Boot도 쉽게 배울 수 있지요.

하지만 어떤 사람들은 회사에서 너무 빨리 전문 분야를 만듭니다. 직장 상사가 특정한 API나 기능을 “보유”하길 요청했을 수도 있지요. 그리고 그 일을 잘 해내면 상사는 계속해서 비슷한 프로젝트를 맡길 겁니다.

당신은 자기 자신만 관리하면 되지만 상사는 많은 사람을 한꺼번에 관리하지요. 그러다 보니 개개인의 능력과 흥미를 깊이 이해하기엔 너무 바쁠지도 모릅니다. 그저 당신을 “아무개 씨”로 보고는 관련된 업무를 맡기는 걸 수도 있습니다.

하지만 당신은 자신이 무엇을 잘하고 어떤 일에 흥미가 있는지 잘 알고 있지요. 익숙한 영역에서 벗어난 프로젝트에 자발적으로 도전해 보는 것도 좋습니다. 상사에게 그런 업무를 할당받는 것이 가능하다면 계속해서 기술을 확장하고 잠재적으로 새로운 팀과 일할 수도 있습니다.

이 점을 기억해 두세요. 상사는 당신이 맡은 직무에서의 성과만 책임지겠지만, 커리어 전반에 걸친 성과에 대한 책임은 자신에게 있다는 것을요.

고용주에게 의무를 다하면서 장기적인 커리어 목표도 달성할 수 있는 프로젝트를 맡으십시오.

에필로그: 할 수 있습니다

여기에 꼭 남기고 싶은 메시지 하나는 바로 이것입니다. “할 수 있습니다.”

개념을 이해하고,

툴을 배우고,

개발자가 되는 것 모두 당신이 할 수 있는 일입니다.

그리고 코딩의 대가로 돈을 버는 순간, 당신은 개발자 지망생 딱지를 떼고 현업 개발자가 되는 겁니다.

코딩을 배우고 개발자로 첫 일자리를 구하는 과정은 험난합니다. 하지만 주눅 들지 마세요.

포기하지 않고 꿋꿋이 계속 도전하면 결국 성공하는 날이 올 것입니다. 그건 그저 연습을 얼마나 많이 하느냐에 달린 일입니다.

프로젝트를 만들어 친구들에게 보여주십시오. 친구들을 위한 프로젝트도 만들어 보시고요.

인맥을 넓히고, 그러면서 알게 되는 사람들을 도와주십시오. 뿌린 대로 거두는 법이지요. 언젠가 은혜를 갚는 사람이 있을 겁니다.

지금도 늦지 않았어요. 인생은 깁니다.

몇 년이 흐른 뒤에 지금 이 순간을 돌아보며 그때 시작하길 잘했다고 생각하게 될 겁니다.

이 여정을 길게 보고, 불확실성을 염두에 두고 계획하십시오.

무엇보다도 언제든 키보드로 돌아오는 것을 잊지 마십시오. 이벤트에도 계속 참가하고, 우승의 기쁨을 친구들과 함께하세요.

옛 철학자 노자(老子)가 이런 말을 했지요.

“천릿길도 한 걸음부터 시작된다.”

이 책을 다 읽으신 분은 벌써 첫걸음을 떼신 겁니다. 아니, 어쩌면 목표를 향해 이미 많이 걸어오셨는지도 모르겠네요.

무엇보다 중요한 건 모멘텀입니다. 이 책을 읽는 몇 시간 동안 생긴 모멘텀을 계속 유지하도록 하세요.

오늘 당장 다음 프로젝트를 위한 코딩을 시작하십시오.

그리고 언제나 기억하세요.

당신은 할 수 있습니다.