살면서 정말 많은 개발자를 만났다. 최근 문득 스스로에게 물었다. “최고가 되려면 무엇이 필요한 걸까? 그들에겐 어떤 공통점이 있을까?”

혹시 누군가에게 영감이 되길 바라며, 내가 본 우리 분야에서 가장 뛰어난 사람들에게서 관찰한 특징들을 적어 보았다. 시작할 때 이 목록이 있었더라면 좋았을 텐데. 이 길을 따라왔다면 시간을 정말 많이 아낄 수 있었을 것이다.

레퍼런스를 읽어라

젊은 프로그래머 시절 꼭 했어야 할 일이 하나 있다면, 내가 쓰고 있는 것의 레퍼런스를 읽는 것이었을 것이다. 이를테면 Apache Webserver Documentation이나 Python Standard Library, 혹은 TOML spec을 읽는 것이다.

Stack Overflow에 가지도, LLM에 묻지도, 짐작하지도 말고, 그냥 바로 원문으로 가라. 놀랍게도 생각보다 훨씬 접근하기 쉽고 잘 쓰여 있는 경우가 많다.

도구를 정말 잘 알아라

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

도구를 쓸 수 있는 것과 진정으로 grok(꿰뚫어 이해)하는 것은 전혀 다른 차원의 일이다. 그저 쓰는 사람은 허둥대고 쉽게 혼란에 빠지며, 잘못 다루고 설정도 최적화하지 못한다.

전문가는 (레퍼런스를 읽은 뒤!) 들어가 앉아서 도구의 설정을 작성하는데, 한 줄 한 줄을 모두 이해하고 동료에게 설명할 수 있다. 그러면 의심의 여지가 남지 않는다!

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

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

예를 들어 당신이 백엔드 엔지니어로서 Kafka를 많이 쓴다면, 나는 당신이 Kafka에 대해 많이 알기를 기대한다. Reddit에서 주워들은 얘기가 아니라. 적어도 최고의 엔지니어 중 한 명이 되고 싶다면 말이다.

에러 메시지를 읽어라

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

그 능력이 없는 사람을 도와줄 때는 마치 초능력처럼 느껴지기도 한다. “찻잔 읽기” 같은 느낌이라고 할까.

문제를 쪼개라

누구나 막힐 때가 있다. 최고들은 막힌 상황에서 빠져나오는 법을 안다. 그들은 문제가 소화 가능한 수준이 될 때까지 단순화한다. 배우기 어려운 기술이고 엄청난 경험을 필요로 한다. 물론 타고난 문제 해결 능력이 뛰어나 영리한 경우도 있다. 그렇지 않다면 훈련하면 되지만, 어려운 문제를 쪼개는 것을 피할 길은 없다. 세상에 한 번에 해결하기엔 너무 어려운 문제들이 있기 때문이다.

프로 개발자로 일한다면, 돈을 받고 하는 일의 대부분이 바로 문제를 쪼개는 일이다. 제대로 하면 마치 꼼수를 쓰는 것처럼 느껴질 것이다. 그저 간단한 문제들을 하나씩 풀다 보면 끝나는 것이니까.

손을 더럽히는 것을 두려워하지 마라

내가 아는 최고의 개발자들은 코드를 많이 읽고, 만지는 것을 두려워하지 않는다. “그건 내 분야가 아니야”라거나 “여기선 도움 못 드리겠네요”라고 말하지 않는다. 대신 그냥 시작하고 배운다. 코드는 그저 코드일 뿐이다. 시간과 노력을 들이면 필요한 어떤 기술이든 익힐 수 있다. 어느새 그들은 만졌던 분야에 대해 팀에서 가장 먼저 찾는 사람이 된다. 애초에 만지는 것을 두려워하지 않은 유일한 사람이었기 때문인 경우가 많다.

항상 다른 사람을 도와라

연관된 얘기다. 훌륭한 엔지니어는 수요가 많고 항상 바쁘지만, 그래도 도우려 노력한다. 본래 호기심이 많고, 돕고자 하는 마음이 그들을 훌륭한 엔지니어로 만든 것이기 때문이다. 그런 사람이 팀에 있다는 것은 큰 즐거움이다. 그들은 문제 해결사이니까.

글을 써라

대부분의 뛰어난 엔지니어는 말을 잘하고 지식을 나누는 것을 즐긴다.

최고들은 자신의 생각을 풀어낼 창구가 있다. 블로그, 발표, 오픈소스, 혹은 이들의 조합이다.

나는 글쓰기 실력과 프로그래밍 사이에 강한 상관관계가 있다고 생각한다. 내가 아는 최고의 엔지니어들은 모두 적어도 하나의 인간 언어에 능숙하다. 종종 그 이상이다. 글쓰기를 다듬는 것은 사고방식을 다듬는 것이고, 그 반대도 마찬가지다. 한 사람의 글쓰기 스타일은 그 사람의 사고방식을 많이 보여준다. 글이 혼란스럽고 구조가 없으면 코드 스타일도 그럴 것이다. 글이 간결하고, 가르침을 주며, 잘 짜여 있고 때로는 위트 있다면 코드도 그럴 것이다.

탁월한 프로그래머는 말을 가지고 노는 데서 즐거움을 찾는다.

절대 배움을 멈추지 마라

내가 아는 최고의 개발자 중 일부는 60대 이상이다. 그들은 나를 가볍게 압도한다. 그 이유 중 하나는 계속 배우기 때문이다. 써보지 않은 새로운 도구나 마음에 드는 언어가 있으면 배운다. 덕분에 큰 노력 없이도 항상 앞서 나갈 수 있다.

이건 당연한 일이 아니다. 많은 사람이 대학을 졸업하거나 첫 직장을 시작한 뒤 금방 배움을 멈춘다. 학교에서 배운 것이 일을 하는 “올바른” 방법이라고 굳게 믿게 된다. 새로운 것은 다 나쁘고 시간 들일 가치가 없다고 생각한다. 그래서 “정신적으로 은퇴한” 25살과 여전히 머리가 맑은 68살이 공존한다. 나는 언젠가 후자에 속하려 노력한다.

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

지위는 중요하지 않다

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

평판을 쌓아라

좋은 일을 하면 탄탄한 엔지니어가 될 수 있지만, 그 좋은 일로 알려져야 최고의 반열에 오를 수 있다. 적어도 (더 큰) 조직 안에서는 그렇다.

평판을 쌓는 방법은 많다:

• (더 큰) 조직을 위한 핵심 서비스를 만들고 출시했다.
• 유명한 도구를 만들었다
• 인기 있는 오픈소스 도구에 기여했다
• 자주 언급되는 책을 썼다

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

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

당신의 가장 최근 작업이 이전의 모든 작업을 압도해야 한다는 말을 들은 적이 있다. 올바른 궤도에 있다는 좋은 신호다.

인내심을 가져라

컴퓨터와 사람, 특히 자기 자신에게 인내심이 필요하다. 모든 것이 바로 되는 것은 아니고, 사람들은 배우는 데 시간이 걸린다. 주변 사람들이 멍청해서가 아니라 그저 정보가 불완전할 뿐이다. 인내심이 없으면 세상이 자신을 적대하는 것처럼, 주변 모두가 무능한 것처럼 느껴질 것이다. 그건 참 비참한 상태다. 제 꾀에 제가 넘어가는 것이다.

최고가 되려면 엄청난 인내와 집중, 헌신이 필요하다. 어려운 문제를 풀고 싶다면 쉽게 산만해져서는 안 된다. 극복하려면 다시 키보드로 돌아와야 한다. 프로젝트를 결승선까지 밀어붙일 노력을 들여야 한다. 그리고 그걸 거만한 인간이 되지 않고 해낼 수 있다면 더 좋다. 그게 최고와 나머지를 가르는 지점이다.

컴퓨터를 탓하지 마라

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

최고들은 그러지 않는다.

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

최고들은 이유를 찾을 때까지 계속 파고든다. 바로 찾지 못할 수도 있고, 어쩌면 영영 찾지 못할 수도 있지만, 외부 상황을 탓하지는 않는다.

이런 태도로 그들은 엄청난 성장을 이루고 남들이 놓치는 것을 배운다. 버그를 이해할 수 없는 마법으로 착각하면, 그것은 영원히 마법으로 남을 것이다.

“모른다”고 말하는 것을 두려워하지 마라

채용 면접에서 나는 지원자가 최소 한 번은 “모른다”고 말할 때까지 강하게 몰아붙이곤 했다. 우월해 보이고 싶어서가 아니었다(물론 그렇게 느낀 사람도 있었겠지만). 그들의 지식의 경계에 도달하고 싶었기 때문이다. 그들이 안다고 생각하는 것의 가장자리에서 함께 서 있고 싶었다. 사실 나 자신도 답을 모르는 경우가 많았다. 솔직히 답 자체는 중요하지 않았다. 내가 중요하게 본 것은 사람들이 둘러대며 면접을 넘기려 하는 순간이었다.

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

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

짐작하지 마라

“모호함에 직면하면, 짐작하려는 유혹을 떨쳐내라.” 내가 가장 좋아하는 PEP 20 – The Zen of Python의 규칙 중 하나다.

그런데 짐작하는 건 정말, 정말 유혹적이다!

나도 여러 번 그런 상황에 놓였고, 내 야심 때문에 실패했다.

짐작하면 두 가지 중 하나가 일어난다:

• 가장 좋은 경우에도 틀리게 되고, 잘못된 가정이 버그로 이어진다.
• 가장 나쁜 경우에는 맞는다… 그리고 다시는 스스로를 의심하지 않게 된다. 잘못된 가정을 토대로 머릿속 모델을 쌓게 되고, 이는 오랫동안 당신을 괴롭힐 수 있다.

다시 한번, 짐작하고 싶은 충동을 억눌러라. 질문하고, 레퍼런스를 읽고, 디버거를 쓰고, 철저해져라. 답을 얻기 위해 필요한 일을 하라.

단순하게 유지하라

영리한 엔지니어는 영리한 코드를 쓰고, 탁월한 엔지니어는 단순한 코드를 쓴다.

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

단순하게 유지하는 것만으로도 많은 것을 이룰 수 있다. 중요한 것에 집중하라.

맺으며

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

다만 어려운 과정을 건너뛸 수 있다고 스스로를 속이지는 마라. 지름길은 없다. 당신의 여정에 행운을 빈다.