내가 아는 최고의 개발자들이 공통적으로 가진 특성
(endler.dev)- 저자는 다양한 개발자를 만나면서, 최고의 개발자들이 가진 공통된 특성에 대해 고민하게 됨
- 이 글은 초보 개발자나 성장하고 싶은 사람들에게 영감을 주기 위해 작성된 관찰 기록임
레퍼런스 문서를 먼저 읽을 것
- Stack Overflow나 LLM을 먼저 찾기보다는 공식 문서를 먼저 읽는 습관을 들이는 것이 중요함
- Apache, Python, TOML 등의 공식 문서는 실제로 꽤 잘 작성되어 있음
- 소스에서 직접 배우는 습관은 장기적으로 큰 도움이 됨
도구를 깊이 이해할 것
- 도구를 ‘사용’할 줄 아는 것과, 그것을 ‘이해’하는 것은 다른 수준임
- 도구를 잘 아는 사람은 설정 하나하나를 설명할 수 있음
- 잘 이해하려면 도구의:
- 역사 (왜 만들어졌는가)
- 현재 (누가 관리하는가)
- 한계 (언제 안 맞는가)
- 생태계 (주변 도구, 라이브러리 등)
를 모두 파악하고 있어야 함
- Kafka 등을 주력으로 쓴다면, Reddit에서 본 수준 이상으로 알고 있어야 함
에러 메시지를 꼼꼼히 읽을 것
- 에러 메시지를 곰곰이 들여다보면 힌트가 담겨 있음
- 최고의 개발자는 적은 정보만 보고도 문제를 추론함
- 문제의 80%는 에러 메시지만 잘 봐도 해결 가능함
문제를 잘게 나눌 줄 알 것
- 막히는 건 누구나 겪는 일이고, 잘게 나눌 수 있어야 풀 수 있음
- 경험이 많거나, 문제 해결 능력이 뛰어난 사람은 쉽게 나눔
- 개발자의 핵심 업무는 결국 큰 문제를 작은 문제로 나누는 작업임
- 단순한 문제들을 차근차근 풀면 전체 문제도 해결됨
두려움 없이 코드를 다룰 것
- 최고의 개발자들은 코드 읽기를 두려워하지 않음
- “그건 내 영역이 아니야” 같은 말 없이 그냥 시도하고 배움
- 처음 다룬 코드도 금세 팀 내 전문가가 되는 경우가 많음
항상 다른 사람을 도울 것
- 바쁜 와중에도 도와주는 개발자는 좋은 팀원이자 훌륭한 전문가임
- 호기심과 협력적인 태도는 좋은 개발자의 필수 자질임
글을 쓸 것
- 뛰어난 개발자는 말도 잘하고, 생각을 글로 풀 줄 앎
- 블로그, 발표, 오픈소스 활동 등으로 생각을 나눔
- 글쓰기 능력은 사고의 구조와 직접적으로 연결되어 있음
- 잘 쓰는 사람의 코드는 구조적이고, 명확하고, 때론 재치있음
배움을 멈추지 말 것
- 나이와 상관없이 계속 배우는 사람이 진짜 뛰어난 개발자임
- 새로운 도구나 언어를 시도하는 것에 거리낌이 없음
- 최신 기술을 맹목적으로 따르지 않고, 장단점을 스스로 분석할 줄 앎
- 젊은 나이에도 고정관념에 빠지면 성장이 멈춤
지위에 연연하지 말 것
- 좋은 개발자는 직책과 상관없이 누구에게나 배움을 구함
- 신입에게도 배울 게 있다는 태도를 가짐
- 새로운 시각을 가진 사람들과의 대화에서 영감을 받음
명성을 쌓을 것
- 실력도 중요하지만, 실력을 알려지는 것도 중요함
- 명성은 영향력을 넓히는 수단임
- 다음과 같은 방법으로 명성을 쌓을 수 있음:
- 중요한 서비스를 직접 만들거나 배포함
- 잘 알려진 도구를 개발함
- 유명한 오픈소스에 기여함
- 자주 인용되는 책을 씀
- 명성은 하루아침에 쌓이지 않으며, 꾸준한 노력과 시간이 필요함
인내심을 가질 것
- 사람과 컴퓨터 모두에게 인내심이 필요함
- 주변 사람은 바보가 아니라 정보가 부족한 것일 뿐임
- 인내심 없으면 쉽게 불만이 쌓이고 협업이 어려워짐
- 어려운 문제를 해결하려면 집중력과 끈기가 필요함
컴퓨터를 탓하지 말 것
- 최고의 개발자는 절대 시스템이나 외부 요인을 탓하지 않음
- 겉보기엔 무작위로 보이는 문제도 논리적인 이유가 있음
- 원인을 찾기 위해 끝까지 파고드는 태도가 중요함
“모르겠습니다”를 말할 줄 알 것
- 인터뷰에서 일부러 “모르겠습니다”를 말하는 순간을 기다린 적 있음
- 중요한 건 답이 아니라 태도임
- 최고의 후보는 모른다고 인정하고, 추론을 시작함
- 모른다고 인정하는 태도는 학습 가능성을 보여줌
- 거짓말하거나 아는 척하는 사람은 팀에 부정적임
추측하지 말 것
- PEP 20의 철학처럼, 모호할 땐 절대 추측하지 말 것
- 추측의 위험:
- 틀리면 버그
- 맞아도 잘못된 전제를 믿게 되어 나중에 문제 유발
- 확신이 없으면:
- 질문하고
- 문서 읽고
- 디버깅 도구를 쓰고
- 근거를 찾아야 함
단순하게 유지할 것
- 똑똑한 사람은 똑똑한 코드를, 훌륭한 사람은 단순한 코드를 씀
- 단순한 코드가 유지보수에 훨씬 유리함
- 복잡함이 필요한 상황과 아닌 상황을 구별할 줄 알아야 진짜 실력임
마무리 생각
- 이 글은 체크리스트가 아니며, 훌륭한 엔지니어링은 경쟁이 아님
- 단, 어려운 작업을 건너뛸 수 있다고 스스로를 속이지 말 것
- 훌륭한 개발자가 되는 길에 지름길은 없음
회사의 프로젝트를 이해한다면,
어느 분야의 시니어 개발자가 되더라도
그 분야가 펌웨어든 앱이든 웹이든,
웹, 앱 또는 펌웨어 디버그 로그를 보면서
문제가 어떻게 발생했는지 디버깅이 가능한 수준이 되는 것 같습니다.
Hacker News 의견
-
추측하지 않는 것이 사업에서 가장 중요함
- 반도체 제조에서 문제 해결 능력을 개발했으며, 잘못된 가정의 비용이 매우 큼
- 항상 근본 원인을 100% 파악해야 함
- 비정상적인 기술 스택을 피하는 이유는 근본 원인 분석을 방해하기 때문임
- 정확하게 문제를 해결하는 것이 명성을 쌓는 가장 빠른 방법임
-
새로운 것을 다룰 때, 참조 자료를 깊이 읽기 전에 약간의 추측을 즐김
- 새로운 언어나 API를 배울 때, 튜토리얼을 통해 추측하고 나서 참조 자료를 읽음
- Intellisense 같은 기능을 지원하는 언어와 IDE를 선호함
-
Stack Overflow나 LLM에 의존하지 않고 직접 소스를 참조하는 것이 좋음
- 수학 책처럼 처음엔 어렵지만, 시간이 지나면서 이해할 수 있게 됨
- Rust crates의 docs.rs, Haskell의 hoogle, C++ reference 등은 훌륭한 참조 자료임
-
최고의 개발자는 모든 계층의 사람들과 소통하며 배움
- 새로운 사람들은 신선한 시각을 제공하며, 과거의 장애물이 사라졌을 수도 있음
- 규칙의 존재 이유를 주기적으로 확인해야 함
-
Stack Overflow를 잘 활용하면 많은 도움이 됨
- LLM은 실시간 이벤트 분석이나 자동화에 유용하지만, 프로그래머를 대체할 수 없음
- LLM을 통해 주제를 이해하고 나면 공식 문서를 참조하는 것이 좋음
-
최고의 프로그래머는 CS 배경이 없어도 뛰어난 성과를 낼 수 있음
- 비전공자가 프로그래밍을 배우고 빠르게 성장한 사례가 있음
-
프로그래밍 외에도 비즈니스 도메인과의 소통이 중요함
- 프로그래밍 외의 다양한 요소를 고려해야 함
-
오류 메시지를 읽고 이해하는 것이 문제 해결에 큰 도움이 됨
-
asdf를 사용하여 Python, Go, NodeJS 버전을 관리할 때, 오류 메시지를 통해 문제를 해결할 수 있었음
-