Introduction
수많은 개발자들 중에서도 단 몇 명만이 진정한 '엘리트'라 불리는 이유는 무엇일까요? 그들은 정말 남다른 두뇌를 타고났을까요, 아니면 평범한 개발자들과는 다른 무언가를 실천하고 있을까요?
'최고의 개발자들'에게서 반복적으로 발견되는 패턴이 있다고 합니다. 놀랍게도 이들이 가진 특별함은 알고리즘에 관한 깊은 지식이나 언어의 마스터리가 아니었다고 하는데요.
오늘은 독일 뒤셀도르프에서 활동 중인 오픈소스 메인테이너이자 Rust 컨설턴트인 마티아스 엔들러(Matthias Endler)가 작성한 <The Best Programmers I Know>를 번역해 가져왔습니다. 그는 Rust 컨설팅 회사인 corrode의 창립자이며, 이전에는 호텔 검색 엔진 trivago에서 백엔드 엔지니어로 일했습니다. 스케일링, 성능 최적화, 분산 시스템에 관심이 많은 그가 수년간의 개발 경험을 통해 발견한 '최고의 개발자들'이 공통적으로 가진 특징들을 소개합니다.
마티아스가 처음 개발자 커리어를 시작했을 때 이 목록을 알았더라면, 몇 년의 시행착오는 피할 수 있었을 거라고 합니다. 이 글을 가져오는 저 역시 마찬가지구요. 아마도 여러분도 이 글을 읽고 "아, 이거였구나" 하는 순간이 올 수 있을 겁니다. 진정한 개발 대가가 되기 위한 비밀을 지금 확인해보세요. 정말 훌륭한 개발자가 되기 위한 비법을 공개합니다.
내가 아는 최고의 프로그래머들
저는 살면서 많은 개발자들을 만났습니다. 최근에 스스로에게 물었습니다:
"최고의 개발자가 되려면 무엇이 필요할까? 그들에게는 어떤 공통점이 있을까?"
누군가에게 영감이 되길 바라며, 저는 제가 관찰한 우리 분야에서 가장 뛰어난 사람들의 특징을 정리해 보았습니다. 제가 처음 시작했을 때 이런 목록이 있었으면 좋았을 거라고 생각합니다. 이 길을 따랐다면, 많은 시간을 절약할 수 있었을 테니까요.
레퍼런스를 읽어라
제가 신입 프로그래머였을 때 했어야 했던 한 가지가 있다면, 그것은 사용하는 도구의 레퍼런스를 읽는 것이었습니다. Apache 웹서버 문서, Python 표준 라이브러리, 또는 TOML 스펙 같은 것들이요.
Stack Overflow에 가지 말고, LLM에게 물어보지 말고, 추측하지 말고, 바로 원천 자료로 가세요. 놀랍게도, 대부분의 레퍼런스는 생각보다 접근하기 쉽고 잘 작성되어 있습니다.
사용하는 도구를 정말 잘 알아라
훌륭한 개발자들은 그들이 사용하는 기술을 근본적인 수준에서 이해합니다.
도구를 단순히 사용할 수 있는 것과 그것을 진정으로 '그록(grok)'하는 것(완전히 이해하는 것)은 완전히 다른 차원의 일입니다. 일반 사용자는 헤매기 마련이고, 쉽게 혼란스러워하며, 도구를 제대로 활용하지 못하고 설정을 최적화하지 못합니다.
전문가는 (물론 레퍼런스를 먼저 읽은 후에!) 들어가서 도구에 대한 설정을 작성할 때 모든 줄을 완벽히 이해하고 동료에게 명확히 설명할 수 있습니다. 이런 상태에서는 어떤 의심의 여지도 없죠!
도구를 잘 알기 위해서는 다음을 알아야 합니다:
- 역사: 누가 만들었나? 왜? 어떤 문제를 해결하기 위해서?
- 현재: 누가 유지보수하나? 그들은 어디서 일하나? 무엇을 하나?
- 한계: 이 도구가 적합하지 않은 경우는 언제인가? 언제 문제가 생기나?
- 생태계: 어떤 라이브러리가 있나? 누가 사용하나? 어떤 플러그인이 있나?
예를 들어, 당신이 백엔드 엔지니어이고 Kafka를 많이 사용한다면, 저는 당신이 Kafka에 대해 많이 알기를 기대합니다 - 레딧에서 읽은 것만으로는 부족합니다. 적어도 당신이 최고의 엔지니어 중 한 명이 되고 싶다면 그렇습니다.
면접관이 놓을 수 없는 이력서를 만들고 싶다면?
이번에 새로 전자책을 출시했습니다 :)
작년부터 인프런을 통해서 이력서 및 취업 멘토링을 해주고 있습니다. 좋은 기회로 부트캠프로부터 졸업생 대상으로 단체 멘토링 역시 진행하고 있구요. 어느새 수십 명의 예비 개발자 분들의 이력서를 검토해주게 되었네요.
그러다보니 멘티 분들이 놓치는 실수가 공통적으로 겹치는 걸 발견했습니다.
면접관은 하루에도 수십 개의 이력서를 검토하면서 단 3초 만에 "더 볼지 말지"를 결정합니다. 그런데 그 귀중한 3초 안에 자신의 경험과 역량을 제대로 드러내지 못하고 있었어요.
제가 주로 해드린 피드백은 아래와 같습니다:
- 10페이지 이력서를 1장으로 압축해 서류 합격률 3배 높이는 법
- 기술 스택을 과도하게 나열하는 대신 깊이를 보여주는 전략
- 문제 해결 경험을 구체적 수치로 표현해 임팩트 만드는 방법
- 면접관을 당신의 편으로 만드는 이력서 작성의 황금 법칙
이런 경험들을 바탕으로 "면접관을 사로잡는 이력서 전략"이라는 짧은 가이드를 작성했습니다. 개발자로서 기술적 역량을 쌓는 것도 중요하지만 그 역량을 효과적으로 어필하는 법도 알아야 한다고 생각합니다.
서류 탈락에 지치셨나요? 당신의 개발자 이력서가 3초 안에 면접관의 시선을 사로잡을 수 있습니다. 현직 멘토가 수십 명의 개발자를 코칭하며 발견한 이력서 전략을 공개합니다.
관심 있으신 분들은 [링크]에서 확인해보세요.
다시 본론으로 돌아가볼까요?
에러 메시지를 읽어라
정말로 에러 메시지를 읽고 거기에 쓰여진 내용을 이해하려고 노력해 보세요. 사실, 에러 메시지 앞에 앉아서 명상하듯 집중하면, 그 메시지가 당신에게 말을 걸기 시작합니다. 최고의 엔지니어들은 아주 적은 맥락에서도 풍부한 정보를 추론해낼 수 있습니다. 에러 메시지를 제대로 읽는 것만으로도 대부분의 문제를 스스로 해결할 수 있죠.
이런 기술이 없는 사람을 도울 때는 마치 당신이 특별한 능력을 가진 것처럼 느껴질 수 있습니다. 마치 "물 위에 글자를 읽는" 능력이라고 할까요.
문제를 분해하라
모든 사람이 때때로 막힙니다. 최고의 개발자들은 막힘에서 빠져나오는 방법을 알고 있습니다. 그들은 문제를 소화할 수 있을 때까지 단순화합니다. 이것은 배우기 어려운 기술이며 많은 경험이 필요합니다. 대안으로, 그냥 뛰어난 문제 해결 능력을 가지고 있다면, 즉 당신이 영리하다면 좋습니다. 그렇지 않다면, 연습할 수 있지만, 어려운 문제를 분해하는 것을 피할 방법은 없습니다. 이 세상에는 관련된 누구에게도 한 번에 해결하기에는 너무 어려운 문제들이 있습니다.
전문 개발자로 일한다면, 그것이 당신이 받는 돈의 대부분을 차지하는 일입니다: 문제를 분해하는 것. 제대로 하면 속임수처럼 느껴질 것입니다: 당신은 그냥 간단한 문제들을 해결하다가 결국 완료하게 됩니다.
손을 더럽히는 것을 두려워하지 마라
제가 아는 최고의 개발자들은 많은 코드를 읽고 그것을 만지는 것을 두려워하지 않습니다. 그들은 절대 "그건 내 일이 아니야" 또는 "여기서는 도울 수 없어"라고 말하지 않습니다. 대신, 그들은 시작하고 배웁니다. 코드는 그저 코드일 뿐입니다. 그들은 시간과 노력을 들여 필요한 기술을 습득할 수 있습니다. 알기도 전에, 그들은 팀에서 그들이 만진 어떤 것에 대한 전문가가 됩니다. 대부분은 그들이 처음부터 그것을 만지는 것을 두려워하지 않은 유일한 사람들이었기 때문입니다.
항상 다른 사람을 도와라
앞서 언급한 내용과 관련된 점인데요. 훌륭한 엔지니어들은 수요가 많아 항상 바쁘지만, 그럼에도 불구하고 항상 다른 사람을 도울 준비가 되어 있습니다. 그들이 본래 가진 호기심과 남을 돕고자 하는 마음가짐이 바로 그들을 훌륭한 엔지니어로 만든 원동력이기 때문이죠. 이런 사람들이 팀에 있다는 것은 그 자체로 큰 행운입니다. 그들은 문제가 생길 때마다 해결책을 찾아내는 진정한 문제 해결사니까요.
글을 써라
대부분의 뛰어난 엔지니어들은 말을 잘하고 지식을 공유하는 것을 즐깁니다.
최고의 엔지니어들은 자신의 생각을 표현할 수 있는 출구를 가지고 있습니다: 블로그, 발표, 오픈 소스, 또는 이들의 조합이죠.
글쓰기 능력과 프로그래밍 사이에는 강한 상관관계가 있다고 생각합니다. 제가 아는 최고의 엔지니어들은 적어도 하나의 자연어를 잘 다룹니다 - 종종 그 이상이죠. 글쓰기 방식을 마스터하는 것은 사고방식을 마스터하는 것이고, 그 반대도 마찬가지입니다. 한 사람의 글쓰기 스타일은 그들이 생각하는 방식에 대해 많은 것을 말해줍니다. 만약 그것이 혼란스럽고 구조가 부족하다면, 그들의 코딩 스타일도 그럴 것입니다. 그것이 간결하고, 교육적이며, 잘 구조화되어 있고, 때로는 재치가 있다면, 그들의 코드도 그럴 것입니다.
뛰어난 프로그래머들은 단어를 가지고 노는 것에서 기쁨을 찾습니다.
배움을 멈추지 마라
제가 아는 최고의 개발자 중 일부는 60대 이상입니다. 그들은 저를 압도합니다. 그 이유 중 하나는 그들이 계속 배우기 때문입니다. 아직 시도해보지 않은 새로운 도구나 그들이 좋아하는 언어가 있다면, 그들은 배울 것입니다. 이런 방식으로, 그들은 많은 노력 없이도 항상 최신 상태를 유지합니다.
이것은 당연시되어서는 안 됩니다: 많은 사람들이 대학을 졸업하거나 첫 직장에 들어간 후 빠르게 배움을 멈춥니다. 그들은 학교에서 배운 것이 일을 하는 '올바른' 방법이라고 생각하는 데 고착됩니다. 새로운 모든 것은 나쁘고 그들의 시간을 들일 가치가 없다고 생각합니다. 그래서 '정신적으로 은퇴한' 25세가 있고, 여전히 마음이 신선한 68세가 있습니다. 저는 언젠가 후자 그룹에 속하고 싶습니다.
어느 정도 관련이 있는데, 최고의 엔지니어들은 트렌드를 따르지 않지만, 항상 새로운 기술의 이점을 신중하게 평가합니다. 그들이 기술을 거부한다면, 왜 그런지, 언제 그 기술이 좋은 선택이 될지, 대안은 무엇인지 정확히 말할 수 있습니다.
지위는 중요하지 않다
최고의 개발자들은 수석 엔지니어와 주니어 개발자에게 똑같이 이야기합니다. 계층 구조가 없습니다. 그들은 젊은이와 노인 모두에게서 배우려고 합니다. 신입 직원들은 종종 아직 사무실 정치에 얽매이지 않았고 여전히 신선한 마음을 가지고 있습니다. 그들은 왜 일이 어려운지 모르기 때문에 창의적인 해결책을 제안합니다. 아마도 과거의 장애물들이 더 이상 존재하지 않을 수도 있으며, 이는 이러한 사람들을 훌륭한 영감의 원천으로 만듭니다.
평판을 쌓아라
좋은 일을 한다면 견실한 엔지니어가 될 수 있지만, 적어도 (대규모) 조직 내에서 자신의 좋은 일로 알려지지 않는다면 최고 중 한 명이 될 수는 없습니다.
자신의 평판을 쌓는 방법은 여러 가지가 있습니다:
- (대규모) 조직을 위한 중요한 서비스를 구축하고 출시했다
- 유명한 도구를 작성했다
- 인기 있는 오픈 소스 도구에 기여했다
- 자주 언급되는 책을 썼다
왜 내 일로 알려지는 것이 중요하다고 생각할까요? 위의 모든 것은 커뮤니티에서 자신의 영향력 반경을 확장하는 방법입니다. 유명한 개발자들은 유명하지 않은 개발자들보다 훨씬 더 많은 사람들에게 영향을 미칩니다. 작성할 수 있는 코드는 한정되어 있습니다. 영향력을 '확장'하고 싶다면, 사상적 리더가 되어야 합니다.
평판 구축은 장기적인 목표입니다. 하룻밤 사이에 일어나지 않으며, 그럴 필요도 없습니다. 그리고 우연히 일어나지도 않습니다. 매일 나타나서 일을 합니다. 시간이 지나면, 일이 스스로 말할 것입니다. 더 많은 사람들이 당신과 당신의 일을 신뢰하고 당신과 함께 일하고 싶어할 것입니다. 당신은 더 명망 있는 프로젝트에서 일하게 될 것이고 그 원이 커질 것입니다.
저는 한번 당신의 최신 작업이 이전에 한 모든 것을 가리게 되어야 한다는 생각을 들었습니다. 그것은 당신이 올바른 길에 있다는 좋은 신호입니다.
인내심을 가져라
컴퓨터와 사람들에게 인내심이 필요합니다. 특히 자신에게요. 모든 것이 바로 작동하지는 않을 것이고 사람들은 배우는데 시간이 걸립니다. 당신 주변의 사람들이 바보가 아닙니다; 그들은 단지 불완전한 정보를 가지고 있을 뿐입니다. 인내심이 없다면, 세상이 당신을 대적하고 당신 주변의 모든 사람이 무능하다고 느껴질 것입니다. 그것은 비참한 곳입니다. 당신은 자신의 이익을 위해 너무 영리합니다.
최고 중 한 명이 되려면, 믿을 수 없을 정도의 인내심, 집중력, 그리고 헌신이 필요합니다. 어려운 문제를 해결하려면 쉽게 산만해질 여유가 없습니다. 그것을 극복하기 위해 키보드로 돌아가야 합니다. 프로젝트를 완성선까지 밀어붙이기 위해 노력해야 합니다. 그리고 오만한 놈이 되지 않고도 그렇게 할 수 있다면, 더 좋습니다. 그것이 최고와 나머지를 구분하는 것입니다.
절대 컴퓨터를 탓하지 마라
대부분의 개발자들은 불안정하고, 겉보기에 '무작위적인' 버그에 대해 소프트웨어, 다른 사람들, 자신의 개, 또는 날씨를 탓합니다.
최고의 개발자들은 그렇게 하지 않습니다.
컴퓨터의 행동이 아무리 변덕스럽거나 장난스럽게 보일지라도, 항상 논리적인 설명이 있습니다: 당신이 아직 찾지 못했을 뿐입니다!
최고의 개발자들은 이유를 찾을 때까지 계속 파고듭니다. 그들은 즉시 이유를 찾지 못할 수도 있고, 절대 찾지 못할 수도 있지만, 외부 환경을 탓하지 않습니다.
이런 태도로, 그들은 믿을 수 없는 진전을 이루고 다른 사람들이 실패하는 것을 배울 수 있습니다. 버그를 이해할 수 없는 마법으로 착각하면, 그것은 항상 마법으로 남게 될 것입니다.
"모르겠다"라고 말하는 것을 두려워하지 마라
면접에서, 저는 지원자들이 적어도 한 번은 "모르겠습니다"라고 말하도록 강하게 밀었습니다. 이유는 제가 우월해 보이고 싶었던 것이 아닙니다(물론 일부 사람들은 그런 인상을 받았을 수도 있습니다). 아니요, 저는 그들 지식의 경계에 도달하고 싶었습니다. 저는 그들이 알고 있다고 생각하는 것의 가장자리에 그들과 함께 서고 싶었습니다. 종종, 저 자신도 답을 몰랐습니다. 그리고 솔직히, 저는 답에 관심이 없었습니다. 제가 관심을 가진 것은 사람들이 면접에서 허풍을 떨 때였습니다.
최고의 지원자들은 "음, 모르겠네요, 하지만 그것은 흥미로운 질문이네요! 추측해야 한다면, 저는..."라고 말한 후 답을 추론했습니다. 그것은 위대한 엔지니어가 될 잠재력이 있다는 신호입니다.
"모르겠다"라고 말하는 것을 두려워한다면, 당신은 오만함이나 방어적인 위치에서 오는 것입니다. 저는 제 팀에 허풍쟁이가 있는 것을 좋아하지 않습니다. 모든 것을 알 수 없다는 것을 인정하는 것이 더 낫습니다. 그것을 받아들이면, 당신은 자신에게 배움을 허락합니다. "중요한 것은 질문을 멈추지 않는 것입니다,"라고 알버트 아인슈타인이 말했습니다.
추측하지 마라
"모호함에 직면했을 때, 추측하려는 유혹을 거부하라" 이것은 PEP 20 - 파이썬의 선(The Zen of Python)에서 제가 가장 좋아하는 규칙 중 하나입니다.
그리고 추측하는 것은 정말, 정말 유혹적이죠. 저는 여러 번 그곳에 있었고 제 자신의 야망으로 실패했습니다.
추측할 때, 두 가지 일이 일어날 수 있습니다:
- 최선의 경우, 당신이 틀리고 당신의 잘못된 가정이 버그로 이어집니다.
- 최악의 경우, 당신이 맞습니다... 그리고 당신은 절대 멈추고 자신을 의심하지 않을 것입니다. 당신은 잘못된 가정을 기반으로 정신적 모델을 구축합니다. 이것은 오랫동안 당신을 괴롭힐 수 있습니다.
다시 말하지만, 추측하려는 충동을 저항하세요. 질문하고, 레퍼런스를 읽고, 디버거를 사용하고, 철저히 하세요. 답을 얻기 위해 필요한 것을 하세요.
단순하게 유지하라
영리한 엔지니어들은 영리한 코드를 작성합니다. 뛰어난 엔지니어들은 단순한 코드를 작성합니다.
그것은 대부분의 경우, 단순함으로 충분하기 때문입니다. 그리고 단순한 것이 복잡한 것보다 더 유지보수하기 쉽습니다. 때로는 일을 올바르게 하는 것이 중요하지만, 그 차이를 아는 것이 최고와 나머지를 구분하는 것입니다.
단순함을 유지함으로써 많은 것을 달성할 수 있습니다. 올바른 것에 집중하세요.
마지막 생각
위의 내용은 체크리스트나 경쟁이 아닙니다; 그리고 훌륭한 엔지니어링은 경주가 아닙니다.
단지 자신을 속여서 어려운 일을 건너뛸 수 있다고 생각하지 마세요. 지름길은 없습니다. 당신의 여정에 행운을 빕니다.
👥 더 나은 데브필을 만드는 데 의견을 보태주세요
Top 1% 개발자로 거듭나기 위한 처방전, DevPill 구독자 여러분 안녕하세요 :)
저는 여러분들이 너무 궁금합니다.
어떤 마음으로 뉴스레터를 구독해주시는지,
어떤 환경에서 최고의 개발자가 되기 위해 고군분투하고 계신지,
제가 드릴 수 있는 도움은 어떤 게 있을지.
아래 설문조사에 참여해주시면 더 나은 콘텐츠를 제작할 수 있도록 힘쓰겠습니다. 설문에 참여해주시는 분들 전원 1개월 유료 멤버십 구독권을 선물드립니다. 유료 멤버십에서는 아래와 같은 혜택이 제공됩니다.
- DevPill과의 1:1 온라인 커피챗
- 멤버십 전용 슬랙 채널 참여권
- 채용 정보 공유 / 스터디 그룹 형성 / 실시간 기술 질의응답
- 이력서/포트폴리오 템플릿
의견을 남겨주세요