살아오면서 수많은 개발자를 만났습니다. 최근 문득 스스로에게 물었습니다. “최고가 되려면 무엇이 필요할까? 그들에게는 어떤 공통점이 있을까?”

어딘가에 있는 누군가에게 영감이 되기를 바라는 마음으로, 이 분야에서 가장 뛰어난 사람들에게서 발견한 특징들을 적어 보았습니다. 막 시작하던 시절에 이런 목록이 있었더라면 좋았을 텐데 하고 생각합니다. 그때 이 길을 따랐더라면 많은 시간을 절약할 수 있었을 것입니다.

레퍼런스 읽기

어린 프로그래머 시절로 돌아간다면 꼭 했어야 할 일이 하나 있다면, 그것은 바로 내가 사용하는 것의 레퍼런스를 읽는 것이었을 것입니다. 이를테면 Apache 웹서버 문서, Python 표준 라이브러리, 혹은 TOML 스펙 같은 것 말입니다.

Stack Overflow에 가지도, LLM에 묻지도, 추측하지도 말고 바로 원전으로 가십시오. 대부분 생각보다 훨씬 접근하기 쉽고 잘 쓰여 있습니다.

도구를 제대로 이해하기

뛰어난 개발자는 자신이 사용하는 기술을 근본적인 수준에서 이해합니다.

도구를 그저 쓸 줄 아는 것과 진정으로 꿰뚫어 이해하는 것(grok)은 완전히 다른 차원의 일입니다. 단순히 사용하는 사람은 허둥대고 쉽게 혼란에 빠지며, 도구를 잘못 다루고 설정도 제대로 최적화하지 못합니다.

반면 전문가라면 (레퍼런스를 읽은 뒤!) 자리에 앉아 도구의 설정을 작성하는데, 모든 한 줄 한 줄을 이해하고 동료에게 설명할 수 있습니다. 그러면 의심의 여지가 없습니다.

도구를 잘 안다는 것은 다음을 안다는 뜻입니다:

• 역사: 누가 만들었는가? 왜 만들었는가? 어떤 문제를 해결하기 위해서인가?
• 현재: 누가 유지보수하는가? 그들은 어디서 일하며 무엇을 하고 있는가?
• 한계: 언제 이 도구가 적합하지 않은가? 언제 고장 나는가?
• 생태계: 어떤 라이브러리가 있는가? 누가 사용하는가? 어떤 플러그인이 있는가?

예를 들어 백엔드 엔지니어로서 Kafka를 많이 사용한다면, Reddit에서 본 단편적인 지식이 아니라 Kafka에 대해 깊이 알아야 합니다. 적어도 최고의 엔지니어가 되고 싶다면 말입니다.

에러 메시지 읽기

말 그대로 에러 메시지를 제대로 읽고 쓰여 있는 내용을 이해하려 노력하라는 뜻입니다. 가만히 앉아 에러 메시지를 곱씹어 보면, 메시지가 말을 걸어오기 시작합니다. 최고의 엔지니어는 아주 적은 맥락만으로도 엄청난 정보를 추론해 냅니다. 에러 메시지만 제대로 읽어도 대부분의 문제는 스스로 해결할 수 있습니다.

이 능력이 없는 사람을 도와주면 마치 초능력처럼 느껴지기도 합니다. 마치 찻잔 점치기 같은 느낌입니다.

문제 쪼개기

누구나 때때로 막히기 마련입니다. 가장 뛰어난 사람들은 막혔을 때 빠져나오는 법을 압니다. 그들은 문제가 충분히 작고 소화할 수 있을 때까지 단순화합니다. 이것은 배우기 어려운 기술이며 엄청난 경험을 필요로 합니다. 혹은 애초에 문제 해결 능력이 탁월한 경우도 있습니다. 즉, 영리한 경우 말입니다. 그렇지 않다면 훈련으로 기를 수 있지만, 어려운 문제를 쪼개는 과정을 피할 수는 없습니다. 이 세상에는 누구라도 한 번에 해결하기에는 너무 어려운 문제들이 있습니다.

전문 개발자로 일한다면, 돈을 받고 하는 일의 대부분이 바로 문제를 쪼개는 일입니다. 제대로 하면 마치 속임수를 쓰는 것처럼 느껴질 것입니다. 그저 단순한 문제들을 하나씩 해결하다 보면 어느새 끝나 있는 식이니까요.

직접 손을 더럽히기 두려워하지 않기

제가 아는 최고의 개발자들은 코드를 많이 읽고, 직접 손대는 것을 두려워하지 않습니다. 그들은 절대 “그건 내 분야가 아니야”라거나 “여기선 도와줄 수 없어”라고 말하지 않습니다. 대신 그냥 시작하고 배웁니다. 코드는 그저 코드일 뿐입니다. 시간과 노력만 들이면 필요한 어떤 기술이든 익힐 수 있습니다. 어느새 그들은 건드렸던 분야마다 팀에서 찾는 사람이 됩니다. 애초에 손대는 것을 두려워하지 않은 유일한 사람이었기 때문입니다.

항상 다른 사람 돕기

앞선 이야기와 이어집니다. 뛰어난 엔지니어는 늘 수요가 많고 항상 바쁘지만, 그래도 도우려 노력합니다. 본래 호기심이 많고, 남을 돕는 마음이 그들을 뛰어난 엔지니어로 만든 것이기 때문입니다. 그런 사람이 팀에 있다는 것은 정말 큰 즐거움입니다. 그들은 문제 해결사이기 때문입니다.

글쓰기

대부분의 훌륭한 엔지니어는 말을 잘하고 지식을 나누는 것을 즐깁니다.

최고의 엔지니어들은 자신의 생각을 풀어낼 창구가 있습니다. 블로그, 강연, 오픈소스, 혹은 이들의 조합 같은 것 말입니다.

글쓰기 능력과 프로그래밍 능력 사이에는 강한 상관관계가 있다고 생각합니다. 제가 아는 최고의 엔지니어들은 모두 적어도 하나의 인간 언어에 능통하며, 종종 그 이상입니다. 글을 쓰는 방식을 익히는 것은 사고하는 방식을 익히는 것이며, 그 반대도 마찬가지입니다. 한 사람의 글쓰기 스타일은 그 사람의 사고방식을 그대로 드러냅니다. 글이 혼란스럽고 구조가 부족하면 코드 스타일도 그럴 것입니다. 글이 간결하고, 교육적이며, 체계적이고 때로는 재치 있다면 코드도 그럴 것입니다.

뛰어난 프로그래머는 단어를 가지고 노는 즐거움을 압니다.

배움을 멈추지 않기

제가 아는 최고의 개발자 중에는 60대가 넘은 분들도 있습니다. 그들은 저를 가볍게 압도합니다. 이유 중 하나는 그들이 계속 배우기 때문입니다. 시도해 보지 않은 새로운 도구가 있거나 마음에 드는 언어가 있으면 기꺼이 배웁니다. 그렇게 하면 큰 노력 없이도 항상 최전선에 있을 수 있습니다.

이건 당연한 일이 아닙니다. 많은 사람들이 대학을 졸업하거나 첫 직장을 시작한 뒤 금방 배움을 멈춥니다. 학교에서 배운 것이 무언가를 하는 “올바른” 방법이라고 굳게 믿게 됩니다. 새로운 것은 모두 나쁘고 시간 낭비라고 생각합니다. 그래서 25세에 이미 “정신적으로 은퇴한” 사람이 있는가 하면, 68세에도 여전히 마음이 싱싱한 사람이 있습니다. 저는 언젠가 후자에 속하고 싶습니다.

조금 관련된 이야기로, 최고의 엔지니어들은 유행을 따르지 않지만, 새로운 기술의 이점은 항상 신중하게 평가합니다. 만약 그 기술을 배제한다면 왜 그런지, 그 기술이 언제 좋은 선택이 되는지, 그리고 대안은 무엇인지 정확히 설명할 수 있습니다.

직급은 중요하지 않다

최고의 개발자들은 수석 엔지니어와 주니어 개발자를 가리지 않고 대화합니다. 그들에게는 위계가 없습니다. 그들은 나이를 불문하고 모든 사람에게서 배우려 합니다. 새로 온 사람들은 아직 사내 정치에 물들지 않았고 여전히 신선한 시각을 가지고 있습니다. 그들은 왜 어떤 일이 어렵다고 여겨지는지 모르기 때문에 창의적인 해결책을 제안합니다. 어쩌면 과거의 장애물이 더 이상 존재하지 않을 수도 있고, 그래서 그런 사람들이 훌륭한 영감의 원천이 되기도 합니다.

평판 쌓기

좋은 일을 하는 것만으로도 유능한 엔지니어가 될 수 있지만, 좋은 일로 알려져 있어야만 최고 중 하나가 될 수 있습니다. 적어도 (큰) 조직 안에서는 말입니다.

평판을 쌓는 방법은 여러 가지가 있습니다:

• (큰) 조직을 위한 핵심 서비스를 만들고 배포한 경우
• 유명한 도구를 만든 경우
• 인기 있는 오픈소스 도구에 기여한 경우
• 자주 언급되는 책을 쓴 경우

왜 자신의 일로 알려지는 것이 중요하다고 생각할까요? 위에 든 것들은 모두 커뮤니티에서 자신의 영향력 반경을 넓히는 방법이기 때문입니다. 유명한 개발자는 유명하지 않은 개발자보다 훨씬 더 많은 사람에게 영향을 미칩니다. 혼자서 쓸 수 있는 코드의 양에는 한계가 있습니다. 영향력을 “확장”하고 싶다면 사고를 이끄는 사람이 되어야 합니다.

평판을 쌓는 것은 장기적인 목표입니다. 하룻밤 사이에 이루어지지도 않고, 그럴 필요도 없습니다. 그리고 우연히 생기지도 않습니다. 매일 나타나 묵묵히 일을 해 나가는 것입니다. 시간이 지나면 일 자체가 스스로를 말해 줄 것입니다. 더 많은 사람이 당신과 당신의 일을 신뢰하게 되고, 함께 일하고 싶어 할 것입니다. 더 중요한 프로젝트를 맡게 되고, 그 영향의 원은 점점 커질 것입니다.

언젠가 이런 말을 들은 적이 있습니다. 당신의 가장 최근 작업이 이전의 모든 작업을 압도해야 한다는 것입니다. 당신이 올바른 길을 가고 있다는 좋은 신호입니다.

인내심 갖기

컴퓨터와 사람, 특히 자기 자신에게 인내심이 필요합니다. 모든 것이 바로 통하지는 않으며, 사람이 배우는 데는 시간이 걸립니다. 주변 사람들이 어리석어서가 아니라, 그저 정보가 불완전할 뿐입니다. 인내심이 없으면 세상이 자신을 거스르는 것처럼 느껴지고, 주변 사람들은 모두 무능해 보일 것입니다. 그건 참으로 비참한 상태입니다. 당신은 스스로에게 너무 똑똑해서 탈인 셈입니다.

최고 중 하나가 되려면 엄청난 인내와 집중, 헌신이 필요합니다. 어려운 문제를 풀고 싶다면 쉽게 산만해져서는 안 됩니다. 극복하기 위해 다시 키보드 앞에 앉아야 합니다. 프로젝트를 마무리까지 끌고 가기 위해 노력을 쏟아야 합니다. 그리고 그렇게 하면서도 거만한 사람이 되지 않는다면 더욱 좋습니다. 그것이 최고와 나머지를 가르는 지점입니다.

컴퓨터를 탓하지 않기

대부분의 개발자는 불안정하고 겉보기에 “무작위”로 보이는 버그를 두고 소프트웨어나 다른 사람, 심지어 반려견이나 날씨 탓을 합니다.

최고의 개발자는 그렇지 않습니다.

컴퓨터의 동작이 아무리 불규칙하고 짓궂어 보여도, 항상 논리적인 설명이 존재합니다. 다만 아직 찾지 못했을 뿐입니다!

최고의 개발자들은 이유를 찾을 때까지 계속 파고듭니다. 바로 찾지 못할 수도 있고, 영영 찾지 못할 수도 있지만, 외부 환경을 탓하지는 않습니다.

이런 태도로 그들은 엄청난 진전을 이루고 다른 사람들이 놓치는 것을 배울 수 있습니다. 버그를 이해할 수 없는 마법으로 치부하는 순간, 그것은 영원히 마법으로 남을 것입니다.

“모른다”고 말하기를 두려워하지 않기

채용 인터뷰에서 저는 지원자가 최소 한 번은 “모르겠습니다”라고 말할 때까지 강하게 밀어붙이곤 했습니다. 우월해 보이고 싶어서 그런 것이 아니었습니다(물론 그렇게 느낀 사람도 있었겠지만). 아니, 저는 그들의 지식의 경계에 도달하고 싶었습니다. 그들이 안다고 생각하는 것의 가장자리에 함께 서 보고 싶었습니다. 종종 저 자신도 답을 몰랐습니다. 솔직히 말해 답 자체는 중요하지 않았습니다. 제가 중요하게 여긴 것은 사람들이 둘러대며 얼버무리는지 여부였습니다.

가장 뛰어난 지원자들은 “아, 모르겠네요, 하지만 흥미로운 질문입니다! 추측해 보자면…”이라고 말한 뒤 답을 추론해 나갔습니다. 그게 훌륭한 엔지니어가 될 잠재력이 있다는 신호입니다.

“모른다”고 말하는 것을 두려워한다면, 오만하거나 방어적인 태도에서 비롯된 것입니다. 저는 팀에 둘러대며 얼버무리는 사람을 원하지 않습니다. 모든 것을 알 수는 없다는 사실을 인정하는 편이 낫습니다. 일단 그것을 받아들이면 배울 수 있게 됩니다. 알베르트 아인슈타인은 “중요한 것은 질문을 멈추지 않는 것이다”라고 말했습니다.

추측하지 않기

“모호함에 직면했을 때, 추측하려는 유혹을 뿌리쳐라”는 제가 가장 좋아하는 PEP 20 – 파이썬의 선 규칙 중 하나입니다.

그런데 추측은 정말, 정말 유혹적입니다!

저도 여러 번 그런 상황을 겪었고, 제 야망 때문에 실패한 적도 많습니다.

추측을 하면 두 가지 중 하나가 일어납니다:

• 가장 좋은 경우 당신은 틀렸고 잘못된 가정이 버그로 이어집니다.
• 최악의 경우 당신은 맞습니다… 그리고 당신은 절대 멈춰서 스스로를 의심하지 않을 것입니다. 잘못된 가정을 바탕으로 정신적 모델을 쌓아 올리게 됩니다. 이는 오랫동안 당신을 괴롭힐 수 있습니다.

다시 한 번 말하지만, 추측하려는 충동을 억누르십시오. 질문하고, 레퍼런스를 읽고, 디버거를 사용하고, 철저해지십시오. 답을 얻기 위해 필요한 일을 하십시오.

단순하게 유지하기

영리한 엔지니어는 영리한 코드를 씁니다. 뛰어난 엔지니어는 단순한 코드를 씁니다.

대부분의 경우 단순한 것으로 충분하기 때문입니다. 그리고 단순한 것이 복잡한 것보다 유지보수하기 쉽습니다. 때로는 제대로 하는 것이 중요한 경우도 있지만, 그 차이를 아는 것이 최고와 나머지를 가르는 지점입니다.

단순함을 유지하면 많은 것을 이룰 수 있습니다. 중요한 것에 집중하십시오.

마무리하며

위 내용은 체크리스트도 경쟁도 아니며, 훌륭한 엔지니어링이 경주인 것도 아닙니다.

그저 어려운 과정을 건너뛸 수 있다고 스스로를 속이지 마십시오. 지름길은 없습니다. 당신의 여정에 행운을 빕니다.