내가 만난 최고의 엔지니어들이 가진 7가지 기본 습관

Introduction

저자가 FAANG에서 일하며 들었던 이 말의 주인공들은 대부분 지금 실리콘밸리에서 가장 핫한 기업들을 이끌고 있습니다. 수천 명의 개발자와 일하며 봤던 그들만의 특별한 점이 있었죠.

흥미로운 건, 이 최고의 엔지니어들이 '완벽한 코드'를 쓰려 하지 않았다는 겁니다. 오히려 90% 완성된 코드도 과감히 버리고, 처음부터 다시 시작하는 걸 두려워하지 않았죠. 그들에겐 '더 나은 결과'만이 중요했으니까요.

저자가 FAANG과 스타트업을 오가며 관찰한 '진짜 실력자'들의 비밀스러운 습관 7가지를 공개합니다. 이 습관들은 평범한 개발자를 '10배 뛰어난 개발자'로 만든 결정적인 차이였다고 하는데요. <7 simple habits of the best engineers I know>를 번역해 가져왔습니다.

어떤 개발자는 이 습관들을 통해 자신만의 회사를 차렸고, 어떤 이는 웹 개발의 패러다임을 바꾸는 Vercel을 만들어냈으며, 또 다른 이들은 수십억 달러 규모의 프로젝트를 이끄는 리더가 되었다고 하네요. 과연 그들은 어떤 습관으로 이런 놀라운 성과를 만들어낼 수 있었을까요?

내가 만난 최고의 엔지니어들이 가진 7가지 기본 습관: 탁월한 소프트웨어 엔지니어가 지속적인 성과를 내는 방법

저는 FAANG과 같은 대기업부터 스타트업까지 다양한 회사에서 뛰어난 엔지니어들과 함께 일했습니다. 그들은 제게 전설로만 알았던 "10배" 엔지니어가 실제로 존재한다는 것을 보여주었어요.

이 엔지니어들 중 일부는 자신만의 회사를 창업하거나, 웹의 패러다임을 바꾸는 개발을 주도하거나(Vercel과 같이), 현재 빅테크 기업에서 수십억 달러 규모의 프로젝트를 이끌고 있습니다.

그들과 함께 일하면서 코드에서 발견한 공통된 습관들을 소개하겠습니다.

사람을 위한 코드 작성하기

코드는 단순히 컴퓨터만을 위한 것이 아닙니다.

코드는 여러분의 팀 동료들을 위한 것입니다. 그들이 그 코드를 읽고, 유지보수하고, 발전시켜 나갈 것이기 때문입니다.

코드는 최종 사용자를 위한 것입니다. 그것이 휴대폰을 사용하는 어린이든, API를 호출하는 개발자든, 혹은 자기 자신이든 말입니다.

제가 만난 최고의 엔지니어들은 제품 중심적 사고방식을 가지고 있었습니다. 즉, 먼저 사람의 문제를 해결하는 것에 초점을 맞췄죠. 최고의 엔지니어들은 항상 모든 독자를 위한 코드의 가치를 평가했습니다. 만약 어느 한 독자라도 충족시키지 못한다면, 그 코드는 프로덕션에 배포되지 않았습니다.

코드에 대한 집착 버리기 

뛰어난 엔지니어들은 자신이 작성한 코드에 집착하지 않았습니다. 전체적으로 더 나은 결과를 위해서라면, 90% 완성된 코드라도 과감히 버리고 처음부터 다시 시작하는 것을 두려워하지 않았습니다.

코드는 개인의 것이 아니었기에, 피드백을 열린 마음으로 받아들였습니다. 완벽한 코드는 없습니다. 어느 누구도 완벽한 코드를 추구하지 않습니다. 그들이 중요하게 여기는 것은 실질적인 변화를 가져오는 코드입니다.

코드에 집착하지 않도록 스스로를 가르치는 가장 좋은 방법이 하나 있습니다. 20년 후에는 여러분이 작성한 코드의 대부분이 1) 기술 부채가 되거나 2) 더 이상 사용되지 않거나 3) 다시 작성될 가능성이 높다는 사실을 깨닫는 것이예요.

일관된 컨벤션 준수하기

코드를 작성할 때는 일관된 코딩 컨벤션과 스타일을 따르세요. 일관성은 미래의 자신과 팀원들이 코드를 더 쉽게 읽고 이해할 수 있게 합니다.

일관된 스타일 가이드는 팀과 코드베이스의 확장성을 높여줍니다. Meta와 Google이 방대한 코드베이스를 가독성과 유지보수성을 유지하면서 배포할 수 있는 비결이 바로 여기에 있습니다. 제가 아는 모든 뛰어난 엔지니어는 팀의 코드 표준을 내재화하고 그 이점을 잘 알고 이를 최대한 충실히 따랐습니다.

단순한 코드 작성하기

제가 아는 모든 훌륭한 엔지니어들은 작성 과정은 복잡했을지 몰라도, 결과적으로는 읽고 이해하기 쉬운 코드를 만들어냈습니다.

그들의 코드는 깔끔하고, 체계적이며, 논리적이었습니다. 코드의 모든 결정에는 명확한 이유가 있었고, 그렇지 않은 경우에는 코드 내에 상세한 설명이 문서화되어 있었습니다.

깔끔한 코드를 작성하는 좋은 방법은 SOLID 원칙을 따르는 것입니다. 이 원칙들은 원래 객체 지향 프로그래밍(OOP)을 위해 설계되었지만, 일반적인 프로그래밍에도 적용할 수 있습니다:

예측 가능한 코드 작성하기

코드는 예상치 못한 동작을 해서는 안 됩니다. 이는 코드 원칙을 준수하고 적절한 테스트를 작성함으로써 달성할 수 있습니다.

좋은 코드는 예측 가능합니다. 이때, 테스트는 코드의 명확성과 예측 가능성을 강제해줍니다. 자동화된 테스트는 팀이 보이지 않는 부분까지 망가뜨릴 걱정 없이 코드를 변경할 수 있게 하죠.

주요 테스트 유형은 아래와 같습니다:

테스트는 단순해야 합니다. 테스트가 실패했을 때 무엇이 잘못되었는지 쉽게 파악할 수 있어야 합니다.

무엇을 테스트하지 말아야 하는지 아는 것도 중요합니다. 예를 들어, 엔드투엔드 테스트의 노력이 프로그램의 실제 이점보다 크다면, 대신 신중한 문서화와 모니터링, 그리고 적절한 담당자(코드 주인)에게의 알림으로 대체해야 합니다.

활발한 소통 유지하기

위대한 시스템은 결코 혼자서 만들어지지 않았습니다. 뛰어난 엔지니어들은 설계 리뷰를 거치고, 적극적으로 피드백을 구하며, 초기 설계를 지속적으로 개선해 나갔습니다.

모든 사람에게는 지식의 빈틈이 있고, 이는 다른 사람들의 관점으로 채워질 수 있습니다. 새로운 시각은 종종 코드를 더 명확하게 만들거나 이전에 생각하지 못했던 새로운 접근 방식을 제시할 수 있습니다.

최고의 엔지니어들은 소통력과 협업 능력이 뛰어났습니다. 더 나은 결과를 위해 시간을 투자하여 함께 일하는 것을 두려워하지 않았죠. 문서에 대한 빠른 검토를 요청하거나 중요한 풀 리퀘스트에 추가 리뷰어를 포함시키는 것과 같은 작은 행동으로도 이를 실천할 수 있습니다.

천천히 코딩하고 빠르게 완성하기

제가 아는 최고의 엔지니어들은 천천히 코딩함으로써 오히려 프로젝트를 빨리 완성했습니다.

이상하게 들리시나요?

위의 모든 원칙과 습관들은 초기 코딩 단계에서는 더 많은 시간이 소요됩니다. 하지만 이를 통해 엔지니어들은 프로젝트를 착실하게 한 단계씩 진행할 수 있습니다.

인턴이나 주니어 엔지니어였을 때 저도 그랬고 많은 개발자들이 경험했듯이, 급하게 3단계를 전진했다가 막히면 5단계를 후퇴해야 하는 상황이 발생하곤 합니다. 천천히 가야 빨리 갈 수 있고, 빨리 가려면 천천히 가야 합니다.

규칙에 대한 맹목적인 추종 피하기

위의 "규칙"과 "원칙"들은 단순한 지침일 뿐입니다. 모든 것이 지침에 완벽하게 들어맞을 수는 없습니다.

때로는 여러분이 작성하는 코드가 기존의 틀에 맞지 않는 경우도 있습니다. 그래도 괜찮습니다. 그런 경우에는 코드가 특정 방식으로 작성된 이유를 명확히 문서화하세요. 그렇지 않으면 미래의 누군가(혹은 미래의 자신)가 코드를 보고 "당시의 내가 왜 이렇게 멍청했지? 왜 표준을 따르지 않았을까?"라고 생각할 수 있습니다. 그리고는 결국 같은 결론에 도달하기까지 20시간을 허비하며 코드를 다시 작성하게 될 수 있죠. 익숙한 상황 아닌가요?

소프트웨어 개발의 현실은 모든 코드가 깔끔하거나 규칙을 완벽하게 따를 수 없다는 것입니다. 하지만 코드는 일관되고, 깔끔하며, 이해하기 쉽고, 테스트 가능하며, 가치 있을 수 있습니다.

이 엔지니어들에게서 발견한 다른 패턴들도 있는데, 이는 다음 글에서 다루도록 하겠습니다:

👥 더 나은 데브필을 만드는 데 의견을 보태주세요

Top 1% 개발자로 거듭나기 위한 처방전, DevPill 구독자 여러분 안녕하세요 :) 

저는 여러분들이 너무 궁금합니다. 

어떤 마음으로 뉴스레터를 구독해주시는지, 

어떤 환경에서 최고의 개발자가 되기 위해 고군분투하고 계신지, 

제가 드릴 수 있는 도움은 어떤 게 있을지. 

아래 설문조사에 참여해주시면 더 나은 콘텐츠를 제작할 수 있도록 힘쓰겠습니다. 설문에 참여해주시는 분들 전원 1개월 유료 멤버십 구독권을 선물드립니다. 유료 멤버십에서는 아래와 같은 혜택이 제공됩니다.

설문 참여하고 유료 멤버십 혜택받기 →