"평범한" 엔지니어를 찬양하며

• “10x 엔지니어”는 직관적으로 그럴듯하지만, 실제 생산성을 객관적으로 측정하는 것은 매우 어렵고, 불변의 개인 특성으로 보는 것도 잘못된 접근임
• 소프트웨어의 실질적 소유권과 결과물은 엔지니어링 팀 단위의 협업과 역량에 의해 결정됨
• 정말 뛰어난 조직은 특별히 탁월한 사람만이 아니라, 평범한 엔지니어가 꾸준히 좋은 결과를 내는 환경을 만드는 곳임
• 시스템은 평범한 사람이 실수하거나 지치기도 한다는 점을 고려해서 설계해야 하며, “10x 팀” 을 만드는 데 집중해야 함
  • 소프트웨어 시스템 설계와 문화는 “평범한 사람” 의 특성, 다양성, 성장의 가능성을 기반으로 해야 함
• 궁극적으로 생산성의 핵심 지표는 비즈니스 임팩트이며, “최고의 인재”가 아니라 “적합한 사람”을 채용하고 팀을 구성하는 것이 중요함

“평범한 엔지니어”를 찬양하며

• 이 글은 “10x 엔지니어”라는 개념에 대한 비판과, 평범한 엔지니어들이 탁월한 팀 성과를 내는 조직의 중요성을 설명함

“10x 엔지니어” 신화와 그 한계

• 누구나 커리어에서 마치 마법사처럼 비범한 엔지니어를 만난 경험이 있음
• 이로 인해 “10x 엔지니어”라는 개념이 생겨났으나, 이는 근거가 빈약하고, 편견을 강화하기도 함
• 생산성의 단일 척도를 정하는 것은 불가능에 가까움
  • 사용하는 기술 스택, 도메인, 개발 단계, 시장 상황, 경험 등 변수의 조합이 무한함
  • 한 사람이 특정 분야에서는 10x 엔지니어일 수 있지만, 대부분의 영역에서는 평범하거나 평균 이하일 수 있음
• 한때 뛰어난 DBRE였어도, 시간이 지나면 해당 분야에서 평범한 수준이 될 수 있음
• 결국, 누구도 모든 분야에서 항상 10배 뛰어날 수 없음

팀 중심의 소프트웨어 소유권

• 소프트웨어는 팀이 소유하고 관리하는 것이지, 개인이 담당하는 것이 아님
• 소프트웨어의 전달과 유지보수, 개선, 확장, 리팩터링 등 모든 과정은 팀 단위로 이루어짐
• 한 명이 소유하는 시스템은 그 사람이 휴가, 이직 등으로 자리를 비우면 단일 장애 지점(SPOF) 이 되어 조직의 취약점으로 작용함
• 스타트업에서 초기에는 개인 소유가 불가피할 수 있으나, 조직이 성장하면 반드시 팀 소유권으로 전환해야 함
• 엔지니어링 리더의 핵심 임무는 고성능 팀의 조성에 집중해야 하며, “10x 엔지니어”보다 10x 팀을 만드는 것이 중요함

진정한 고성과 조직의 조건

• 많은 기업이 FAANG 출신, 명문대, Staff Engineer 위주로 팀을 꾸리는 것을 선호함
• 그러나 진짜 좋은 조직은, 평범한 엔지니어가 안정적으로 실질적 임팩트를 낼 수 있는 곳임
• “최고”만이 성과를 낼 수 있는 조직이 아니라, 일반적인 개발자도 주도적으로 성장하고, 제품과 비즈니스에 긍정적 영향을 주는 시스템을 만드는 것이 더 큰 경쟁력임
• 오히려 이런 조직이 더 많은 월드클래스 엔지니어를 길러냄

“평범함”의 의미 재정의

• 소프트웨어 업계는 “상위 10%”, “top .1%” 등 엘리트 중심 사고가 만연함
• 하지만 대다수 엔지니어는 다양한 경험과 연습을 통해 성장한, 평범한 사람임을 인정하는 것이 중요함
• 아무도 선천적으로 “뛰어난 엔지니어”로 태어나지 않음
• 위대한 엔지니어는 만들어지는 것임 - 누구나 학습과 경험을 통해 훌륭해질 수 있음

평범한 사람을 위한 시스템 설계

• 채용 시에는 특출난 강점을 보는 것이 맞지만, 시스템을 설계할 때는 사람들이 평범하게 실수하고, 지치고, 익숙함에 기대는 현실을 고려해야 함
• 일반적인 엔지니어는 인지 편향, 피로, 감정 기복 등에 영향을 받음
• 시스템이 똑똑한 소수가 아니라 평범한 엔지니어 관점에 맞추어 설계되어야, 뛰어난 인재의 창의적 역량이 제품 자체에 집중될 수 있음

“10x 팀”을 만드는 방법

• 코드 작성과 배포 사이의 간격을 최대한 줄임
  • 빠른 배포 주기는 인지 부담을 줄이고, 더 빠른 실험과 피드백을 가능하게 함
  • 배포가 느릴수록 여러 변경이 한꺼번에 모여, 문제 추적과 롤백이 어려워짐
• 실수 복구와 롤백을 쉽게 만듦
  • 개발자가 스스로 코드를 배포하고, 문제를 발견하면 신속하게 복구할 수 있어야 함
• 옳은 행동을 쉽게, 잘못된 행동을 어렵게 만듦
  • 디자이너, 플랫폼 엔지니어와 협력해, 가드레일과 셀프서비스 체계를 구축
• 관측성과 계측 도구에 적극 투자
  • 실제 코드 동작을 시각화하여, 모든 엔지니어가 쉽게 시스템을 이해하고 디버깅할 수 있도록 지원
• 내부 도구와 생산성 향상에 엔지니어링 리소스 투자
  • 이런 시스템은 별도의 오너십이 필요하고, 전사적 우선순위가 되어야 함
• 포용적 문화 조성
  • 누구나 질문, 실수, 탐색이 가능한 환경
  • 다양한 배경, 스킬, 연차가 어우러진 팀이 더 회복력 있고, 변화에 강함
• 모든 레벨의 엔지니어가 섞인 팀 구성
  • 주니어부터 시니어까지 서로 배우고 가르치며 함께 성장하는 구조
  • 이런 시스템은 신입 온보딩, 팀 간 이동 등에도 재활용 가능

생산성의 진짜 척도: "비즈니스 임팩트"

• 궁극적으로 소프트웨어 엔지니어링의 생산성 척도는 비즈니스 임팩트임
• 많은 코드를 작성하는 것이 아니라, 문제를 해결하고 가치를 창출하는 것이 본질임
• 실제로 산업을 움직이는 주역은 Staff+ 엔지니어가 아니라, 시니어와 미드레벨 엔지니어임
  • 이들이 조직의 기반을 이루고, 지속적으로 비즈니스를 전진시킴
  • Staff+ 레벨만이 임팩트를 낼 수 있다면, 조직에 문제가 있다는 신호

월드클래스 엔지니어를 키우는 조직

• 뛰어난 엔지니어가 아니어도, 누구나 임팩트 낼 수 있는 조직이 진짜 좋은 조직임
• 최고의 조직은 반드시 세계 최고 수준의 인재를 따로 뽑지 않아도, 자연스럽게 월드클래스 엔지니어가 가장 많이 탄생함
• 엔지니어가 문제 해결과 성장, 임팩트에 몰입할 수 있는 곳에 인재가 모이고, “행복하게 일하고 성장하는 경험” 자체가 선순환을 이끔
• 리더는 뛰어난 인재의 개인 역량에 의존하지 않고, 이를 조직 전체의 성장과 고객 가치로 연결하는 역할을 해야 함

“최고의 인재”보다 “적합한 사람” 채용

• 업계는 “최고”만 찾으려 하지만, 진짜 중요한 건 시스템과 환경임
• “최고의 인재”보다, 팀과 조직에 적합한 사람을 찾는 것이 더 큰 경쟁력임
• 약점이 없는 사람보다, 특유의 강점을 지닌 조직의 다양성과 조화를 증진할 “적합한 인재” 로 팀을 구성하는 것이 효율적임
• 포용적이고, 다양한 팀이 실질적으로 성과와 성장, 장기적 성공을 이끌어냄
• 모두가 일을 즐기고, 성장하며, 의미 있는 결과를 내는 곳이 진짜 세계 최고 조직이며, 실패나 실수에도 배울 수 있는 문화에서 엔지니어와 조직이 모두 성장함
• 이런 조직이야말로 차세대 엔지니어도 끌어들이고, 이미 뛰어난 인재가 머물고 싶어하는 환경임