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

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

---

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

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

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

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

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

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

진정한 고성과 조직의 조건

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

“평범함”의 의미 재정의

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

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

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

“10x 팀”을 만드는 방법

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

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

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

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

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

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

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

[GN⁺]

Hacker News 의견

• 소프트웨어 소유권과 딜리버리의 최소 단위를 엔지니어링 팀이라고 한 주장에 공감은 하지만, 조금은 아쉽게 느끼는 입장임. 이런 구조는 엔지니어가 매니저나 프로덕트 부서에 비해 이등 시민이 되는 문화와 맞닿아 있음. 우리는 배달(deliery)에만 책임이 있을 뿐, 진짜 의미 있는 결정을 팀의 아주 작은 범위 이상에서는 독립적으로 내릴 수 없음. 최고의 팀에서는 재량의 기간이 수개월, 심지어 수년에 이르지만, 대부분 팀에서는 며칠, 몇 주 수준으로 줄어듦. 하지만 실제로는 엔지니어가 실질적 소유권을 갖고 시스템이 깨지거나 위험해지는 것 없이 오래 갈 수 있는 구조가 충분히 가능함. 비결은 여유(slack)를 확보하고, 양질의 작업을 장려하며, 구성원 누구든 유연하게 업무를 바꿀 수 있도록 충분한 자유를 주는 것임. 각자 소유권을 갖고 장기적 결정을 내리면서도, ad hoc으로 협업하고 묵시적 지식을 공유하여, 누가 갑자기 들어와서 도움을 주거나 아예 이어받는 시나리오도 자연스럽게 가능해짐. 실제 경험상 이런 팀은 일반 팀보다 리라이트(재작성)는 많지만, 전반적으로 훨씬 더 생산적임. 시스템을 작은 덩어리로 점진적으로 리라이트하는 것이 디자인 진화와 조직 내 지식·역량 축적 양쪽 모두에 아주 효과적임. 겉으로는 낭비처럼 보여도, 조직 전체가 유연하고 회복력 있게 만드는 데 필수적인 여유임. 오히려 소위 낭비라고 줄이려는 톱다운 조직의 많은 프로세스가 실제로는 중요한 ‘슬랙’을 없애고 있다는 확신이 점점 커지는 입장임

  • 엔지니어링 외부 사람들은 엔지니어가 내린 장기적 결정을 바로 평가할 수 없고, 어떤 보상을 줘야 할지 모르는 경우가 많음. 이건 심지어 같은 엔지니어팀을 벗어나도 마찬가지임. 내부 가치를 가진 장기 작업에 대해, 그 가치가 실제로 있는지 아닌지 직접 평가하는 능력이 없기 때문임. 본인이 장기 의사결정과 슬랙 타임 사용에 자신 있다면, 배달(delivery)에 대한 보상을 받아도 괜찮음. 언젠가는 그 장기적 작업이 더 나은 결과로 돌아올 것이기 때문임

  • 소프트웨어 리라이트가 개발 과정에서 중요한 역할을 한다고 생각함. 진정한 ‘애자일’이란, 첫 아키텍처에 너무 신경 쓰지 않고 빠르게 프로토타입을 만들어 요구사항 변화에 유연하게 대응하는 방식임. 코딩은 글쓰기와 비슷해서, 첫 초안은 거칠더라도 일단 써 나가고 두 번째 버전에서 개선하는 게 훨씬 효율적임. 첫 초안은 좋은 걸 목표로 하는 게 아니라, 빠르게 뭔가를 만들어보고 문제영역을 탐색해 엣지케이스를 파악하는 데 목적이 있음. 이런 작업 방식은 경영진에게는 잘 통하지 않음. 작동하는 프로토타입을 보이는 순간 ‘이거 바로 출시하자’고 할 뿐, 리라이트할 시간을 주지 않음. 해법이라면, 조직의 계층을 납작하게 만들고, 엔지니어에게 코드 소유권을 실제로 돌려주는 것이 좋겠음. 엔지니어와 프로덕트 오너가 함께 민주적으로 의사결정을 하는 구조가 바람직함

  • 나도 한때는 ‘개인 소유권’을 중요하게 생각했고, 지금도 엔지니어가 소유권을 가질 수 있다고 보지만, 실제로 많은 엔지니어가 그걸 원하지 않는다는 사실도 인정함. 대부분 엔지니어는 팀 단위라면 괜찮아하지만, 개별 엔지니어 수준의 소유권에는 그다지 관심이 없음. 그냥 생업일 뿐임. 이를 개인에 맡기면 팀 내 불신을 낳거나, 리더십 성향이 없는 멤버를 소외시키게 되고, 결국 아무도 실질적 재량이 없는 사태가 벌어지기 쉬움. 팀 단위로 소유권과 재량을 주는 구조가 훨씬 간단하고 효과적임. 팀 리더 혹은 매니저가 있어서 가능한 역동성이기도 함. 개인별로 소프트웨어 소유권을 두면 인원 변화, 안정성, 커리어 등의 변수로 실패 위험이 너무 많아짐. 조직이 아무리 건강해도 크고 작은 문제는 있기 마련이고, 이런 구조에서는 실패로 이어지는 경로가 가장 짧아짐. 기어박스를 생각하면 이해하기 쉬움. 기어가 하나밖에 없고 고장나면 못 가지만, 여러 기어가 있으면 불편하더라도 당장 고장이 나도 계속 갈 수 있음

  • 진짜로 실질적 개인 소유권이 가능하다고 생각함. 오히려 유일하게 정말 ‘생산적’일 수 있는 방법이라고 봄. 하지만 이게 본질적 쟁점은 아님. 개개인은 대체 불가능하지만, 팀원은 구조에 따라 어느 정도 대체 가능함. 조직이 커질수록 팀 단위의 예측 가능성을 원하게 되고, 이를 위해서는 멤버 대체가능성 확보(즉, redundancy)가 필요함. 엔지니어링에서도 신뢰성(회복력)을 위해 redundancy를 두고, 효율성은 redundancy를 줄이는 트레이드오프와 같음

  • 우리는 그저 '딜리버리'에만 책임이 있다는 식의 구조에서 일하면서, 소유권이란 결국 부담만 늘릴 뿐 실질적 보상은 없었음. 일은 페이지에 기능만 붙이는 일로 국한됨. 추가 책임이 생긴다면 이에 대한 추가 보상도 마땅함. 매니저나 임원은 책임 인원수에 따라 보상이 커지는데, 개발자도 마찬가지여야 함

• 가장 좋은 팀은 평범한 엔지니어가 엄청난 성과를 내게 하는 문화에 있다고 확신함. 세간에서 말하는 ‘엔지니어링 퀄리티’나 인재 채용보다도, 문화와 신뢰, 시스템, 프로세스가 훨씬 더 중요함. “누구나 최고의 엔지니어가 있는 조직을 만들 수 있다”는 말이 있는데, 실제로 그런 팀을 만들어낸 조직은 정말 소수임. 거의 모두 트레이딩 회사나 특수/연구조직임. 도대체 다들 왜 못하는 건지 의문임. 결국 "생산성"이란 개념부터가 무엇을 의미하는지도 애매함. 단순히 조직 내 dysfunction을 견디고 돌파할 능력을 보는 평가 시스템도 있는데, 그게 진정한 ‘톱 엔지니어’의 의미는 아니라고 봄

  • 진짜로 뛰어난 엔지니어 공급은 제한적이라, 결국 더 큰 회사가 더 재밌는 일이나 더 높은 급여를 내걸고 같은 인재를 데려가게 됨

  • 다른 사람들이 말한 돈 문제도 크지만, ‘시간’도 매우 큼. 회사가 완벽한 “유니콘” 인재가 나타날 때까지 기다릴余유가 없고, 바로 채용할 수 있는 인재로 급하게 채울 수밖에 없기도 함. 일부 회사, 특히 퀀트 파이낸스 같은 분야에선, 시스템 프로그래머·수학자·금융시장 전문가 3인을 모두 아우르는 한 명의 슈퍼 엔지니어가 세 명의 전문가 팀보다 훨씬 큰 가치를 내기도 함. 하지만 그런 사람 찾기엔 시간이 너무 큼. 웹 개발만 봐도, 네트워크 프로토콜부터 시스템 어드민, 분산 시스템, 데이터베이스, 프론트엔드까지 정말 전방위로 두루 이해하는 ‘진짜 풀스택’ 개발자는 극소수임. 충분한 시간과 비용이 있는 조직만이 이런 인재를 모아서 최고의 제품을 만들 수 있음. 물론 제품이 정말로 그 정도의 품질이 필요한가는 별개의 질문임

  • 근본적으로 전 세계의 “최고 엔지니어” 공급량은 극히 제한적임. 상위 10% 급여를 줄 수 있고, 그만큼의 인재를 모으고 유지할 수 있다면야 성공임. 사실 ‘아무나’ 만들 수 있는 건 아니고, 정말로 경영진이 학습과 성장에 집중하는 소시오테크니컬 시스템을 설계하는 리더십이 필요함. 그 자체로도 훌륭한 일임

  • 가장 큰 문제는 대부분의 1~2선 경영진이 그다지 뛰어나지 못하다는 것임. 생산적 환경을 만들고 유지하는 능력이 부족함. 근본적 해결책은 결국 ‘돈’을 많이 주는 것임. 돈이 크면 대부분의 힘든 조건도 감수할 수 있음

  • 예산 문제를 떠나, 정말 뛰어난 엔지니어가 팀플레이엔 오히려 좋지 않을 수도 있음. 뛰어난 두뇌가 때론 필수적인 타협이나 지루하지만 필요한 작업에는 오히려 걸림돌이 될 수 있음

• “비즈니스 임팩트만이 유일한 생산성 척도”라는 주장에 크게 동의할 수 없음. 이런 관점은 측정 가능한 변화와 단기 성과로 시야가 옮겨지고, 숙련된 엔지니어의 진정한 가치를 놓치게 됨. 진짜 실력자는 프로젝트나 회사를 망칠 뻔한 위험(landmine)을 미리 막는 데 있음. 하지만 이런 ‘없어진 리스크’는 측정하기 어렵고, 평범하게 들리게 전달하는 것도 불가능에 가까움

  • “임팩트”는 꼭 단기적인 관점이 아님. 조직에 최대 임팩트를 주는 사람은 장기적 관점에서 움직임

  • 나는 ‘생산성’이나 ‘임팩트’를 일부러 모호한 표현으로 얘기함. 예를 들면 “전반적으로 생각하면 X는 일을 정말 잘 했다”처럼. 이런 게 수치화도, 명확한 규정도 어렵지만, 원래 복잡하고 창의적인 조직에는 인간의 통찰과 판단이 더 중요함. 경영을 무조건 수치화하려드는 건 근본적으로 근시안적임

  • 프로젝트 관리나 위험 회피 등만으로 엔지니어의 가치를 측정하는 건 동의하지 않지만, 모든 걸 ‘비즈니스 임팩트’로만 환원하는 건 불편함. 세상에는 돈과 무관하게 개인, 인류, 세계에 의미 있는 일이 많음. 내가 가장 존경하는 엔지니어는 포스트-2001 실리콘밸리의 신화적인 인물보다, 존 폰 노이만, 로버트 오펜하이머, 니콜라 테슬라, 레오나르도 다빈치, 로마 수로와 이집트 피라미드를 만든 누군가, 바빌로니아-메소아메리카의 천문학자 등임. 그들이 비즈니스 임팩트를 남겼는가? 테슬라가 한때 Westinghouse에 이익을 줬다고 해도 그게 그의 업적을 설명하지는 못함. 사실 그는 비즈니스면에서는 평범함. 최신 컴퓨팅 산업의 거장도 마찬가지. Nvidia나 Geoff Hinton이 엄청난 성공을 거둔 건 인터넷이 광고화되며 데이터가 폭증한 ‘운’도 한몫한 것임. 진짜 실력자가 소외된 채 사라진 빈 사례도 많음. Doug Lenat처럼 AI계의 대가도 결국 역사의 흐름에 따라 발굴되지 못한 경우도 있음. 성공 여부는 많은 경우 개인의 노력과도 무관함

  • 효율적인 시스템을 만들거나, 재난 가능성을 최소화하는 시스템을 만들거나 양자택일임. 실제로 어떤 재앙이 막혔는지는 증명하기도 어렵고, 부정적인 영향 자체가 ‘발생하지 않은 사건’이기에 결과로 보여주기도 힘듦

  • 회사는 ‘알려지지 않은 것’의 위험을 어떻게든 더 잘 정량화하려고 노력해야 함

• 운 좋게도 지금까지 여러 훌륭한 팀에서 일했고, 현재도 그런 팀을 이끌고 있음. 기사와 달리, 이런 팀일수록 조직이 관리하기가 더 어려운 경우가 많음. 대형 조직은 표준화에 초점을 맞추다 보니, 오히려 뛰어난 엔지니어가 역량을 펼치지 못하고 동기부여도 잃는 경우가 많음. 모든 사람을 뛰어난 엔지니어로 키우지 못한다는 비관적 관점에 동의하지 않음. 실제로 꾸준히 투자하면 훌륭한 엔지니어로 키울 수 있고, 장기적으로 뛰어난 인재 풀이 많아질 때 얻는 이득이 그만큼의 투자 비용을 충분히 뛰어넘는다고 생각함

• 효과적으로 측정할 수 없다고 해서, 그 무엇 자체가 존재하지 않는 것은 아님. 개별 생산성, 즉 개인의 업무 성과는 분명히 있음. 아마 그룹 단위 생산성이 측정하기 더 쉬울 뿐임. “비즈니스 임팩트”는 오히려 훨씬 더 임의적이고, 그런 척도로 보면 정말 생산적인 인재를 남기기 힘듦. 전문 지식의 평가는 동등한 경험이 없는 한 매우 어렵고, 조언은 할 수 있지만, 상대가 그걸 받아들일 지적인 여유가 있는지는 별개임. 내가 천재인지, 자신감만 앞선 사람인지 어떻게 알 수 있겠는가

  • 문제는 생산성을 ‘측정’할 수 없음이 아니라, 심지어 추상적으로 ‘정의’조차 못 한다는 것임. 단순히 “replacement”보다 얼마나 더 기여했는지 측정해도 그 결과가 정확히 어떻게 나온 건지 설명해주지는 못함. 실제로는 개인의 영향력이 맥락과 조직 전체에 의해 결정됨. 더 직접적인 정의를 내려해도 정답은 조직·상황마다 천차만별임. 이는 고민해볼 가치가 충분하지만, ‘Top 1%’ 엔지니어란 기준 자체가 정말로 의미가 있는지도 자체도 의문임

  • 진짜 천재는 자신의 결과를 에티켓을 지키며 쉽게 설명할 수 있음. 그래서 차이는 충분히 구분 가능하다고 생각함

• “정상적인 엔지니어가 위대한 업무를 할 수 있게 만들어주는 조직이 최고”라는 글귀가 마음에 듦. 모든 팀원이 다 슈퍼스타일 필요는 없음. 평균적인 개발자가 충분히 좋은, 신뢰할 만한 실력을 펼칠 수 있게 만드는 지원이 얼마나 잘 되는지가 정말 중요함

  • 모든 뛰어난 엔지니어도 처음에는 그저 좋은 엔지니어였음. 건강한 조직은 구성원이 이 성장 경로를 밟을 수 있게 돕는 역할을 함

• “옳은 것을 쉽게, 그른 것을 어렵게 만든다”는 원칙이 내가 만난 모든 플랫폼팀의 핵심 슬로건과 같음. 목표는 엔지니어가 마주치는 문제에 대해 ‘정답’이 자동으로 눈에 띄고, 쉽게 구현할 수 있도록 시스템을 설계하는 것임. 신뢰성과 관리 용이성을 갖춰, 자연스레 그런 방향으로 개발 ‘근육’을 길러주면 조직 전체가 이득을 봄. 이 진리는 앞으로도 계속 유효함

  • 우연히도 Charity Majors가 이에 관한 훌륭한 에세이를 쓴 적이 있음. 신뢰할 수 있는 시니어 엔지니어들로 소규모 위원회를 구성해서, 새 서비스에 쓸 기본 컴포넌트 추천 리스트를 만드는 것부터 시작함. 이게 바로 ‘골든 패스’가 됨. 조직은 골든 패스 컴포넌트만 완전 지원하며, 업그레이드·패치·백업·배포·환경·온콜 등 전반을 금과 같이 깔아줌. 꼭 사용하지 않아도 되지만, 골든 패스 밖의 선택은 본인이 모든 걸 다 책임져야 함

• golang, python, COBOL, lisp, perl, React, brainfuck 등 다양한 언어/프레임워크가 언급될 때마다, React를 프론트엔드 생태계 전체로 착각하는 경향이 있다는 느낌을 오래 받아왔음. 실제로는 React 외에도 다양한 프론트엔드 세계가 존재함에도, 다들 React가 전부라고 생각하는 듯함

• 우리 회사에선 항상 태도 좋은 평균 엔지니어 채용을 선호함. 자격만 좋은데 태도 나쁜 사람은 평판형성을 잘해서 윗선의 신임을 쉽게 얻고, 이후엔 무소불위가 됨. 이런 사람이 자리 잡으면, 주위는 억울해도 문제를 제기하기가 힘들어짐. 윗선도 자신의 인식에 맞지 않는 데이터를 쉽게 무시함. 객관적 데이터보다 인식에 기대는 게 훨씬 쉽기 때문임

• “누구나 최고의 엔지니어와 함께하는 조직을 만들 수 있고, 개별 능력 중심은 리더의 실질적 역할을 흐리게 만든다. 덜 숙련된 엔지니어가 역량을 쏟아 결과를 만들 수 있도록 시스템을 만드는 게 엄청난 경쟁우위”라는 주장에 정말 공감함. 난 10x 엔지니어는 아니지만, 최근 경험에 비추어 보자면, 팀에 경험치·실력이 적은 사람이 많을 때 나만이 복잡한 티켓을 도맡게 됐음. 이런 패턴이 반복되면 나 혼자 대부분의 일처리를 하게 되고, 실제로 그 역할이 고된 데다 공정하지 않게 느껴짐. 솔직히 좋은 SRE라면 약간 게으른 성향도 있어야 한다 생각하기에, 팀원들이 일을 분담해줬으면 하는 바람이 큼. 그래서 몇 주 동안 하드하게 일해서, 가장 복잡한 부분에 다양한 추상화를 도입했음(나는 IAC를 주로 다룸; 소프트웨어에서도 비슷한 패턴임). 그러자 상대적으로 실력이나 경험이 부족한 엔지니어도 내 역할을 나눠 맡게 됐고, 내 시간은 더 흥미로운 문제에 쓸 수 있게 되었음. 누구의 지시도 없이 이런 시도를 한 건 처음임. 반대로 이런 구조 없이, 혼자서 히어로처럼 굴게 되면, 팀 전원이 뒤에서 따라다니며 실수를 수습하느라 골머리를 앓게 되고, 결국 정말 비효율적인 팀이 되어버림