‘10배 엔지니어’ 신화의 한계를 짚으며 진정 위대한 엔지니어링 조직이 어떻게 ‘평범한’ 엔지니어들이 최고의 성과를 낼 수 있도록 뒷받침하는지에 대한 고찰.
이 글은 2025년 2월 11일, refactoring.fm의 Luca Rossi의 의뢰로 최초 작성되었으며(유료), '10배 엔지니어링 팀'의 중요성을 강조하는 버전이 나간 바 있습니다. 이후 IEEE Spectrum(!!!)에도 실렸으나, 대부분 팀 이야기는 빠지고 짧고 다른 글로 3월 13일 새로 출판되었습니다.
아래는 제 개인 편집본이며, 공개된 두 버전과는 조금 다릅니다. 최근 런던 #LDX3, CraftConf에서 발표한 강연 “‘평범한’ 엔지니어를 칭찬하며”의 소스 자료도 많이 담겨 있습니다.
우리 대부분은 마치 마법사와도 같은 엔지니어, 복잡한 추상화나 문제를 단숨에 해결하는 특별한 동료를 몇 번쯤 만나본 경험이 있습니다.
이런 놀라운 존재와 부딪히며 ‘10배 엔지니어’라는 신화가 지속되는 것 같습니다. 그 개념을 뒷받침하는 연구는 허술하고, “10배 엔지니어는 어두운 배경을 선호하며, UI 작업을 꺼리고, 멘토링도 못한다”는 주장이나(때론 웃음거리), “우리는 마크 저커버그를 떠올리게 하는 젊은 후드티 청년을 찾는다”는 식의 고정관념도 있지만, 실제 이런 사람이 있다는 경험과 느낌은 쉽게 사그라지지 않습니다.
저는 어떤 분야에서는 남보다 10배 더 생산적인 엔지니어가 있을 수 있다는 사실 자체는 부정하지 않습니다. 문제는 2가지입니다.
첫째, 생산성을 어떻게 측정하냐는 점입니다. 단일 척도로 엔지니어를 줄 세울 수 있다는 생각 자체가 문제입니다. 잠시만 생각해 보세요. 해당 분야와 경험, 기술은 천차만별입니다.
또한 시간에 따라 사람의 능력은 달라집니다. 한때 저는 꽤 괜찮은 DBRE였고 책도 썼습니다. 그땐 10배 DB엔지니어였을지는 몰라도 지금은 아닙니다. 쿼리 플랜을 들여다본 지도 오래됐습니다.
‘10배 엔지니어’를 마치 불변의 개인적 특성처럼 여기는 건 잘못입니다. 어느 한 기술집합에서는 ‘10배’지만, 대부분 평범하거나 그 이하일 때가 훨씬 많습니다. 세계적 엔지니어도 모든 면에서 남보다 10배 뛰어난 이는 없었습니다.
둘째이자 결정적으로 중요한 점: 그래서? 그게 뭐가 중요한가요. ‘개인’ 엔지니어가 소프트웨어를 소유하지 않습니다. 소프트웨어의 최소 소유·전달 단위는 팀입니다. 한 명이 아무리 빨라도 전체 팀이 집단적으로 코드 작성, 검증, 리뷰, 릴리즈, 유지보수, 리팩토링, 확장, 아키텍처 개선, 수정을 얼마나 잘 하느냐가 진짜 중요합니다.
기업 내 가장 느린 엔지니어가 한 줄 코드 배포에 5시간이 걸린다면, 가장 빠른 이도 똑같이 5시간 걸릴 수밖에 없습니다. 코드 작성 시간 외에 개발 생명주기의 다른 활동에 소요되는 시간이 더 많기 때문이죠.
만약 서비스/컴포넌트가 1명에게만 의존한다면, 그건 단일 실패점(SPOF)입니다.
물론 스타트업 초창기에는 개인 소유가 자연스러울 수 있습니다. 빠른 실행, 시장 적합성 확보가 사활이 걸린 문제이기 때문이죠. 하지만 고객이 늘고 회사의 장기 존속이 중요해질수록 소유권은 반드시 팀으로 넘어가야 합니다. 개인은 아프기도, 휴가 가기도, 퇴사할 수도 있고 비즈니스는 이에 대응해야 하니까요.
소프트웨어를 팀이 소유한다면, 엔지니어링 리더의 핵심은 고성능 팀을 만드는 것입니다. 만약 10배 더해야 할 게 있다면, 바로 10배 엔지니어링 팀을 만드는 것이어야 합니다.
사람들은 ‘월드클래스’ 엔지니어링 조직을 떠올릴 때, Staff/Principal 엔지니어가 포진했거나 전직 FAANG, 명문대를 채용한 “최상위 집단”을 생각합니다.
하지만 진짜 위대한 조직은 세계 최고가 아니어도, 평범한(하지만 훌륭한 역량을 갖춘) 엔지니어들이 지속적으로 빠르고, 안정적으로 코드를 내고, 사용자에 응답하며, 시스템을 이해하고, 매일 비즈니스를 조금씩 앞으로 나아가게 만드는 곳이라고 봅니다.
최고의 인재들이 성과를 내는 환경을 만드는 건 쉽습니다. 하지만 “개인의 역량”에만 초점을 맞추면, 리더들이 자신의 본분(팀 빌딩/시스템 설계/조직문화 등)에서 손을 떼는 부작용이 생깁니다. 다양한 배경의 평범한 엔지니어도 성장하며 성과를 내게 돕는 시스템을 만드는 것이야말로 엄청난 경쟁력입니다.
진짜 좋은 조직에서야말로 월드클래스 엔지니어가 탄생합니다. 하지만 순서를 착각하지 않아야 합니다.
많은 기술인은 ‘영리한 아이’였던 자기 정체성에 집착합니다. 소프트웨어 업계 역시 Netflix의 “세계 상위 10% 인재”, Amazon의 “기준치 높이기”, Coinbase의 “상위 0.1%만 채용”(진짜…? 그렇다면 Honeycomb은 상위 0.00001%만 뽑나요!)처럼 이를 조장하죠.
이번 글에서는 그런 집착을 버리고 우리 모두 _평범한 사람_임을 인정하면 어떨까 합니다.
자신을 평범하다고 생각하기 어려울 수 있지만, 사실 우리 대부분은 꽤 평범합니다(다만 아주 특화된 훈련과 경험이 있을 뿐). 특정 능력 기준으로 천재인 사람도 몸짓, 감정, 공간, 음악, 언어지능 등 다른 면에선 평범할 가능성이 높죠.
소프트웨어 엔지니어링은 특정 추상적 사고를 요구·발달시키지만, 뛰어난 엔지니어는 태어나는 게 아니라 만들어지는 것입니다. 자신을 특별한 계급으로 여기기보다는, 평범한 이들이 (비교적 특수한) 기술을 오래 연마해온 집단으로 보면 오히려 얻는 것이 많습니다.
분명, 채용에서는 각자의 뛰어난 강점·특장을 알아보는 게 중요합니다. 하지만 소프트웨어 딜리버리용 사회-기술 시스템을 설계할 때는, 모든 엔지니어가 평범하다는 전제로 접근해야 합니다.
평범한 사람은 확증 편향, 최신 기억 강조, 사후 편향 등 다양한 인지적 오류가 있습니다. 열심히 일하고 성실하지만, 가끔 잊고, 참을성 잃고, 멍해질 때도 있습니다. 빨간색(혹은 적색맹이 아니라면)에 시선이 끌리고, 반복되는 텍스트는 아예 읽지 않습니다. 습관과 관성을 갖고, 변화를 꺼려합니다.
피로와 스트레스에도 취약합니다. 새벽 3시에 경고 알림이 오면 평소보다 실수하기 쉽습니다. 감정 상태, 주변 인간관계 역시 일의 질에 영향을 미칩니다.
여러분의 시스템이 ‘평범한 엔지니어’도 쓸 수 있게 설계된다면, 그들이 가진 뛰어난 역량은 제품 자체 발전에 집중될 수 있습니다. 시스템을 헤매는 데 낭비되지 않습니다.
이 내용이 새로울 것은 없습니다. 평범한 엔지니어도 빠르게 반복·배우며 팀이 뛰어난 성과를 내도록 만드는 소프트웨어 딜리버리용 사회-기술적 시스템을 구축하려면:
최대한 짧게, 짧을수록 좋습니다. 발표에서도 여러 번 강조했습니다. 간극이 짧을수록 인지적 부담도 줄고, 반복 속도도 빨라집니다. 제품에 더 많은 뇌역량을 쏟을 수 있죠.
배포 주기가 짧아 커밋 1개당 배포가 기본인 구조가 이상적입니다. 배포주기가 길어지면 여러 엔지니어의 변경분을 한 번에 묶게 되어(‘엔지니어링 죽음의 소용돌이’), 문제 추적·롤백이 더 어려워집니다.
배포는 개발 프로세스의 피드백 루프입니다. 이 간격을 짧고 타이트하게 유지하는 게 매우 중요합니다.
개발자는 자기 코드를 직접 배포하고, 정상 동작 여부를 즉시 확인, 문제 시 어려움 없이 롤백(또는 롤포워드)해야 합니다.
디자인팀, 플랫폼팀의 협력을 통해 엔지니어가 프로덕션 시스템과 접점에서 안전하게 자율적으로 작업할 수 있게 하세요. 많은 작업이 밤중이거나 피로/스트레스 상태에서 이루어질 수 있다는 점을 반드시 고려해야 합니다. 가드레일을 구축해, 한 줄 배포가 쉽고, 언제나 정확한 프로세스를 따르도록 해야 합니다.
코드만 봐서는 실제 동작을 절대 알 수 없습니다. 반드시 인스트루먼테이션을 통해 실제 사용자 상황을 관찰해야 하며, 이런 도구에 아낌없이 투자하세요. 엔지니어링 추상화 체계를 실제 엔지니어가 체감하기 위해서는, 자신의 작업물을 눈으로 확인할 수 있어야 합니다.
고품질 배포·가드레일·관측·병렬화된 테스트 등은 ‘모두의 일’이라고 방치하면, 아무도 제대로 하지 않습니다. 엔지니어링 생산성은 외주화할 수 없습니다. 외부 벤더와 내 팀의 인터페이스 관리도 과학이자 예술이며, 직관적이고 간편하게 만드는 일에는 반드시 책임자가 필요합니다.
성장이 기본값입니다. 구성원이 소속감, 질문의 자유, 실수의 안전망을 느낄 때 최고의 결과가 나옵니다. 모두에게 공정한 높은 기준과, 목표 달성에 필요한 지원·격려가 필요합니다.
슈퍼시니어로만 구성된 팀은 단기적으로 빠르지만, 모노컬처는 약점이 많습니다. 팀원이 아프거나, 육아휴직, 신규 인원/다른 배경 인력 유입이 있을 때 빠르게 무너집니다.
성별, 인종, 정체성, 연령, 가족, 지역, 경험 등의 다양성이 기본이 된 팀은 어떤 변화에도 더 잘 대처할 수 있습니다.
최고의 팀은 Staff만 많은 무거운 팀이 아닙니다. 누구도 반복 작업(예: 로그인 화면 복붙)을 무의미하게 하지 않고, 모두가 자신의 한계에 도전하게 설계된 팀이 최고입니다. 배우고, 가르치며, 늘 성장하는 상태여야 합니다.
이러한 회복성 높은 시스템 구축은 신입 온보딩, 주니어 육성, 팀 이동에도 도움이 됩니다. 여러 번 재사용되는 중요한 투자입니다.
엔지니어 생산성의 유일한 의미는 결국 비즈니스를 실질적으로 전진시키는가 뿐입니다. 그에 따라, 우리가 올바른 문제를 풀고 있는지도 제품, 디자인, 비즈니스와 긴밀히 협업해야 알 수 있습니다.
소프트웨어 엔지니어링은 코드를 많이 쓰는 일이 아니라, 기술로 비즈니스 문제를 해결하는 일입니다.
실제로 산업을 이끌어가는 건 시니어, 미들급 엔지니어들입니다. 그들이 비즈니스를 한 걸음씩 진전시키고, 조직 문제에 머리 싸매기보다 자신의 일에 집중할 수 있어야 합니다. Staff+급만이 비즈니스를 이끈다면 뭔가 심각한 문제가 있다는 신호입니다.
거듭 강조하지만, 위대한 조직이란 세계 최고 엔지니어가 아니어도 큰 임팩트를 낼 수 있는 곳입니다. 그리고 역설적이게도, 이런 조직에서야말로 월드클래스 엔지니어도 지속적으로 탄생합니다.
최고의 조직은 가장 똑똑하고 경험 많은 사람들이 모인 곳이 아니라, ‘평범한’ 엔지니어가 매일, 꾸준히 가치를 창출하고 비즈니스를 이끌 수 있는 곳입니다.
이런 곳이야말로, 좋은 인재를 끌어모읍니다. 엔지니어는 ‘만들고, 문제를 해결하며, 성과를 내는 것’에 가장 큰 만족감을 얻으니까요.
월드클래스 인재가 있다면 리더는 그 재능이 조직 전체와 고객, 동료들의 성장에 쓰이게 유도하는 것이지, 그 능력에 의존해선 안 됩니다. 이런 인재도 언제든 떠날 수 있으니까요.
이런 사람들은 엄청난 자산이 될 수 있겠지만, 팀워크와 겸손이 전제되어야 합니다. 그래서 실리콘밸리 대형 기업들이 ‘어떻게든 찾아내 채용’에 집착하곤 합니다.
문제는, 그런 사람을 이미 ‘길러낸’ 다음에만 찾으려 하기 때문에 사회 전반의 편견과 불평등만 반복·증폭됩니다. 재능은 사회 전체에 고르게 분포할 수 있지만, 기회는 절대 그렇지 않습니다.
전 인류 전체가 ‘개인의 능력’만 지나치게 강조하고, 우리를 둘러싼 시스템의 영향을 과소평가한다고 봅니다.
후보자가 스스로 포기하거나 지원자의 다양성이 떨어지는 등 여러 문제도, 엔지니어 채용이 “최고의 사람” 집착에서 벗어나, 더 합리적이고 정확한 ‘적합한 사람’ 중심으로 맞춰진다면 자연스레 개선될 것 같습니다.
팀 ‘조합’에 중점을 두고, 약점 없는 인재가 아니라 개개인의 장점에 집중하는 채용, 다양성이 윤리적 이유뿐 아니라 집단의 성과까지 높인다는 전제가 쉼 없이 적용되어야 합니다. 포용성 있는 문화가 ‘실질적’ 실력주의의 토대입니다.
이런 환경이야말로 실력이든 인성이든 최고 인재가 저절로 모입니다. 코드가 바로 서비스로 반영되는 것, 비즈니스가 앞으로 나아가는 것, 스스로 능력을 날카롭게 갈고 성장하는 것—이 모두가 매우 짜릿하고 좋은 경험입니다. 이곳이 바로 월드클래스 엔지니어가 성장하고, 또 그들이 차세대 엔지니어를 키우며 오래 남는 곳입니다.
<3, charity
