# 왜 당신의 최고 엔지니어들이 다른 곳에 면접을 보고 있을까 > Clean Markdown view of GeekNews topic #25115. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25115](https://news.hada.io/topic?id=25115) - GeekNews Markdown: [https://news.hada.io/topic/25115.md](https://news.hada.io/topic/25115.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-16T11:06:02+09:00 - Updated: 2025-12-16T11:06:02+09:00 - Original source: [codegood.co](https://codegood.co/writing/why-your-best-engineers-are-interviewing-elsewhere) - Points: 129 - Comments: 17 ## Summary 조직의 **정보 필터링 구조**는 엔지니어의 불만이 경영진까지 도달하지 못하게 만들고, 그 결과 문제는 종종 **퇴사 통보 이후에야** 드러납니다. 개발자는 보상만으로 움직이지 않는다는 말이 많은데, 실제로는 자신의 **기술적 판단이 무시**되고, **일정에만 쫓기며**, **의미 없는 업무가 반복**되는 상황이 누적될 때 조직을 떠나게 됩니다. 연봉 인상은 이를 늦출 수는 있어도, 근본적인 해결책은 되지 않습니다. 이 글에서는 대안으로 경영진이 관리 단계를 건너뛰어 **스킵레벨 대화**를 통해 현장의 목소리를 직접 듣는 구조를 제안합니다. 이렇게 하면 수개월 앞서 조기 경고를 포착할 수 있고, 결과적으로 **수억 원대의 인재 교체 비용**을 예방할 수 있습니다. 핵심은 보상이 아니라, **기술적 판단이 존중되고 말해도 바뀌는 구조를 유지하는 것**입니다. ## Topic Body - 조직 내 **정보 필터링 구조**로 인해 경영진은 **엔지니어들의 불만**을 퇴사 통보 후에야 알게 되며, 이미 수개월 전에 결정된 퇴사를 되돌리기엔 너무 늦음 - 엔지니어들이 퇴사하는 진짜 이유는 연봉이 아니라 **기술적 판단이 무시되는 경험**, 갚을 수 없는 기술 부채, 의미 없는 업무에 배치되는 것 - 중간 관리자들은 문제를 자신의 단계에서 해결하려 하며, 이를 **전문성으로 인식**하지만 실제로는 정보 억압으로 기능함 - **스킵 레벨 대화**(경영진이 하위 직급 엔지니어와 직접 대화)는 조직 건강을 해친다는 명목으로 기피되지만, 실제로는 중간 관리자를 책임에서 보호하는 역할임 - 시니어 엔지니어 한 명 교체 비용은 **$275,000~$395,000**에 달하며, 주 몇 시간의 스킵 레벨 대화 비용($50,000/년)보다 훨씬 큼 - 조직이 초기에 **스킵레벨, 외부 진단, 실제 문제 해결**에 투자하면 수억 원대 교체 비용을 줄일 수 있고, 그러지 못한 회사는 계속 이유를 모른 채 **좋은 엔지니어를 잃게 됨** --- ### 서론: 한 시니어 엔지니어의 이탈과 1.4M 달러 손실 - 연 4,000만 달러 ARR SaaS 회사에서, 시니어 엔지니어가 **확장 불가능한 DB 아키텍처**를 6개월간 반대했으나, 제품 조직의 “빨리 출시하고, 나중에 리팩터링 하자”는 결정이 그대로 진행됨 - 엔지니어링 리더십은 그가 옳다고 보면서도 **제품 팀에 맞서** 밀어붙이지 않았음 - 그는 기술 결정 자체가 아니라, **자신의 판단이 의미 없다는 사실** 때문에 그 주에 바로 면접을 보기 시작했음 - 8개월 뒤 시스템은 **매일 성능 문제**를 겪었고, 18개월 뒤에는 시니어 5명이 회사를 떠났으며, 회사는 왜 이런 일이 벌어지는지 파악하기 위해 fractional CTO를 고용함 - 진단 결과, 임원진은 엔지니어들이 불행하다는 사실을 **퇴사 이메일이 오기 전까지 전혀 모르고 있었음** - 퇴사 인터뷰에는 “더 나은 기회”, “더 경쟁력 있는 보상”만 표면적으로 기록됨 - CEO는 남은 **엔지니어 연봉을 15% 인상했지만, 그 후에도 이탈은 계속 이어졌음** - 시니어 5명을 교체하는 데 들어간 비용은 채용, 생산성 손실, 지식 유실까지 합쳐 **약 140만 달러 수준**으로 추산됨 - 이 문제는 **보상이 아니라 정보 흐름의 실패**에서 비롯되었고, **“위로 올라가는 정보가 걸러지는 계층 구조”** 가 핵심 원인임 ### Hierarchies filter bad news out — 계층 구조는 나쁜 소식을 지워버리는 필터 - 조직은 복잡성을 다루기 위해 **계층 구조와 관리 레이어**를 도입하지만, 그 효과로 정보가 각 레이어에서 걸러지는 구조가 생김 - 주니어가 “문제 있어 보인다”고 말하면, 시니어가 이를 정제해 매니저에게 올리고, 매니저는 “보고할 만한 일인지, 본인에게 불리한지”를 먼저 평가함 - VP→CTO→CEO로 올라갈수록, 원래 문제의 **세부 정보와 긴박감**이 하나씩 사라짐 - 이 필터링은 악의적이라기보다, **중간관리자가 “자기 레벨에서 문제를 처리하는 것”을 책임이라고 믿는 문화**에서 발생함 - “문제를 올리는 것 = 실패”로 간주되고, “해결책만 들고 올라가는 것”이 프로페셔널함으로 인식됨 - 결과적으로, 이는 **문제를 숨기는 메커니즘**으로 작동함 - 한 120명 규모 엔지니어 조직의 사례에서는, 프론트엔드 팀이 3월에 새 대시보드 성능 문제를 발견해 **코드 리뷰에서 공개적으로 우려**를 표했음 - 5월에 매니저가 해결 방안을 검토했고, 6월에 VP에게는 “대시보드 성능 최적화 진행 중” 정도로 전달됨 - 7월에 CTO는 “약간의 성능 작업”이 있다는 수준만 들었고, 8월에서야 **최대 고객이 대시보드가 못 쓸 정도라고 공식 항의를 하면서** 임원진에게 ‘갑작스러운’ 위기처럼 인지됨 - 실제로는 엔지니어들은 5개월간 문제를 알고 있었고, **자원을 배분해야 할 임원진은 항상 수개월 늦은, 희석된 정보**로 의사결정을 하고 있었음 - 이 구조에서, **엔지니어는 8월에 DB가 안 버틴다는 걸 알고**, 매니저는 10월에 불만을 알고, VP는 12월에 사기 저하를 인지하고, CTO는 2월에 대량 퇴사를 보게 되는 **정보 지연 사슬**이 반복됨 ### The convenient fiction of chain of command — ‘보고 라인’이라는 편리한 허구 - 많은 조직이 **스킵레벨(임원이 엔지니어와 직접 대화)** 을 “체계를 깨는 행동”으로 금기시함 - 중간관리 권위 약화, 불신 신호, 마이크로 매니지먼트라는 이유가 자주 동원됨 - 겉으로는 조직 건강을 위한 고려처럼 보이지만, 실제로는 **중간관리층이 책임과 검증에서 자신을 보호하는 장치**로 작동함 - CTO가 **엔지니어와 직접 이야기하는 경우**, 실제로 현장에서 어떤 일이 벌어지는지 알 수 있음 - 반대로, 관리 레이어를 거친 보고서만 보는 CTO는 **관리자가 보여주고 싶은 버전의 현실**만 보게 됨 - 스킵레벨 금기는 후자를 보장하는 메커니즘이 됨 - “임원 시간은 비싸니, 전략에만 집중해야 한다”는 논리는, **전략이 사실과 다른 정보 위에 세워지기 시작하는 순간** 무너짐 - CTO가 매주 몇 시간만 투자해도, **무엇이 실제로 막히고 있는지, 누가 마음이 떠나고 있는지, 어느 기술 베팅이 실패 중인지** 직접 들을 수 있음 - 계층을 3–4단계 거친 보고서에 의존하는 편이 시간당 비용은 싸게 보이지만, **잘못된 큰 결정을 반복적으로 낳는 훨씬 비싼 선택**이 됨 - 스킵레벨에 쓰는 시간은 많을 필요는 없고, **일관된 패턴과 전체 커버리지**만 확보하면 됨 - 조직이 커질수록 한 사람과 대화하는 주기는 길어지지만, **CTO가 분기마다 한 번이라도 모든 엔지니어와 직접 이야기하는 구조**를 유지할 수 있음 - 이런 직접 대화에서 엔지니어는 매니저에게는 절대 말하지 않을 문제를 이야기하고, **정식 라인보다 3–6개월 빠른 조기 경고**가 확보됨 - 한 결제 회사 사례에서, 새로운 CTO가 **매주 30분 오피스 아워**를 열어 누구나 매니저 허락 없이 예약할 수 있게 했을 때, - 배포 시스템이 불안정해 금요일 배포를 피하는 문화, **거짓 경보가 너무 많아 아무도 믿지 않는 모니터링**, API 문서 노후화로 온보딩 한 달이 모두 시행착오로 소비되는 문제가 드러났음 - 각 매니저는 “자기 레벨에서 처리 중”이라며 위로 올리지 않았던 내용이었고, CTO는 분기 안에 세 가지 문제를 모두 해결하도록 예산을 배정했으며, 6개월 뒤 **자발적 이직률이 거의 0에 가까워지는 변화**가 나타났음 ### Agency, not salary — 떠나는 이유는 보상이 아니라 ‘에이전시’ 상실 - 엔지니어 이직 사유는 **퇴사 인터뷰에서 자주 “보상”으로 포장되지만**, 실제 패턴은 더 미묘하고 말하기 난감한 요인에서 출발하는 경우가 많음 - 1\. 첫 번째 패턴은 **에이전시 상실**임 - 엔지니어가 분명히 실패할 것이라 아는 시스템을 만들도록 요구받고, 비기술적 이유로 판단이 지속적으로 뒤집히는 상태임 - 예측한 실패가 현실이 되었을 때, “왜 막지 않았느냐”는 책임까지 떠안는 구조에서 **전문가로서의 판단이 아무 의미 없다는 감각**이 누적됨 - 한 핀테크 회사는 **이미 검증된 인증 솔루션을 쓰지 않고 직접 구현**하기로 했고, 시니어들은 위험과 비핵심 영역이라는 점을 들어 반대했음 - 제품 쪽은 특정 UX 플로우를 위해 커스텀 구현을 강하게 밀었고, 엔지니어링 리더십은 시니어들 의견에 동의했으나 끝내 제동을 걸지 못했음 - 결과적으로 커스텀 인증 시스템은 첫 달에 **보안 취약점 3건**, 긴급 패치, 6개월 치 개발 리소스를 소모했고, 해당 시니어는 결정이 확정된 주에 바로 이직 준비를 시작했음 - 비용을 숫자로 보면, 커스텀 인증에 **18만 달러**를 쓰는 동안, 사서 쓸 수 있는 솔루션은 연 **1.2만 달러**였음 - 그 엔지니어가 남아 있었다면, 로드맵 기준 연 **40만 달러 ARR**를 창출할 기능에 쓸 수 있었고, - 이 결정으로만 **최소 58만 달러**가 1년 차에 날아간 셈임 - 2\. 두 번째 패턴은 **갚을 수 없는 수준까지 미뤄진 기술적 부채**임 - DB 복제, 배포 자동화, 모니터링 개선 같은 핵심 인프라 작업이 매 분기 기능 개발 뒤로 밀리며, - 엔지니어는 언제 어디서, 무엇이 깨질지를 거의 정확히 알고 있음에도 계속 막히는 것을 지켜보는 상황임 - 한 이커머스 회사는 18개월 동안 DB 인프라 작업을 계속 연기했고, 그 사이 트래픽은 연 40%씩 늘어났으나 인프라는 그대로였음 - 19개월 차에 DB가 전체 플랫폼의 병목이 되어, 피크 타임 응답 시간이 **200ms에서 4초**까지 늘어났고, 전환율 하락으로 **120만 달러 수준의 매출 손실**과 **24만 달러의 긴급 인프라 비용**이 발생함 - 인프라 작업을 가장 강하게 요청했던 시니어 3명 중 2명은 이미 떠난 상태였음 - 3\. 세 번째 패턴은 **똑똑한 사람에게 멍청한 일을 시키는 구조**임 - 연 18만~19만 달러를 받는 시니어에게, 이미 폐기해야 할 시스템 유지보수, 의미 없는 반복 작업, 아무도 믿지 않고 아무도 읽지 않는 문서와 추정 회의를 맡기는 상황임 - 한 SaaS 회사에서는 6년 된 레거시 리포팅 시스템이 1년에 **8만 달러 매출**을 내고 있었는데, 시니어 한 명(연 19만 달러)이 시간의 60%를 이 시스템 유지에 쓰고 있었음 - 회사는 사실상 **연 11.4만 달러를 8만 달러 매출을 위해 태우는 구조**였고, 엔지니어는 고객 12명을 신규 플랫폼으로 옮기자고 제안했지만 “전략적 고객”이라는 이유로 거절당했음 - 그녀는 3개월 뒤 퇴사했고, 교체 비용은 리크루팅과 온보딩까지 **22만 달러**에 달했으며, 고객 마이그레이션은 **4만 달러 정도면 끝낼 수 있었던 작업**이었음 ### The early signals executives miss — 임원이 보지 못하는 ‘조기 경고’ - 경영진이 사표를 받기 전까지 못 보는 신호들은 **6–12개월 전부터** 이미 다른 레벨에서 뚜렷하게 나타남 - 1\. 주니어/미들 엔지니어가 먼저 보는 신호는 **시니어의 싸움 포기**임 - 시니어가 아키텍처 리뷰에서 더 이상 강하게 의견을 내지 않고, 리뷰는 형식적인 통과 절차가 됨 - 백로그의 기술 작업은 계속 쌓이는데, 배정은 거의 이루어지지 않고, “이건 해봤는데 위에서 안 된다더라”는 말이 빈번해짐 - 한 물류 회사의 주니어 엔지니어는 6개월 동안 이런 변화를 관찰했음 - 과거에는 상세한 코드 리뷰를 하던 아키텍트가 이제 대부분 **“LGTM” 한 줄로 승인**하기 시작했고, - 비공식 대화에서 “어차피 내 의견은 결과를 못 바꾸니 그냥 시간을 아끼기로 했다”는 말을 들었을 때, 이 시니어가 곧 떠날 거라는 사실을 먼저 깨달았음 - 3개월 뒤 실제로 퇴사가 이뤄졌고, 매니저는 전혀 예상하지 못했다고 느꼈음 - 2\. 시니어 본인이 경험하는 단계는 **4–8개월 전부터 나타나는 패턴 인식과 도덕적 피로감**임 - “이건 실패할 거고, 리더십은 듣지 않을 거다”라는 확신, **옳지 않은 것을 만들게 되는 도덕적 상처**, “내 전문성이 이곳에서는 아무 의미 없다”는 감정임 - 외형상으로는 회의에서 덜 싸우고, 더 협조적으로 보이기 때문에, 리더의 눈에는 오히려 “성숙해진 것처럼” 보일 수 있음 - 3\. 매니저가 보는 신호는 **2–4개월 전의 미묘한 행동 변화**임 - 1:1에서 참여도가 떨어지고, 팀 토론에서 발언이 줄고, - LinkedIn을 업데이트하고, 업계 행사에 더 자주 나가고, 문서화가 갑자기 매우 꼼꼼해지고, 주니어에게 자신의 시스템을 열심히 가르치기 시작함 - 이때 많은 매니저는 높은 이직률이 본인에게 불리하다고 느껴, 상부 보고 대신 조용히 해결해보려다 **이미 오퍼를 받은 뒤에야 사태를 인정하게 됨** - 한 미디어 회사의 매니저는, 어떤 시니어가 갑자기 모든 것을 문서화하기 시작한 것을 “드디어 지식 공유를 실천한다”고 긍정적으로만 봤지만, - 실제론 떠나면서 **지식 공백에 대한 죄책감** 때문에 남기는 기록이었고, 이를 깨달은 건 퇴사 이후였음 - 4\. 임원이 보는 것은 **0–1개월 전에야 도착하는 퇴사 통보**뿐이고, 그 전 단계에 쌓인 신호들은 계층 구조 속에서 모두 흩어졌던 셈임 ### Why one departure becomes five — 한 명의 이탈이 다섯 명의 이탈로 번지는 구조 - 한 명의 퇴사는 하나의 데이터 포인트지만, **세 명이 연달아 나가면, 남은 사람들은 “뭔가 있다”고 해석**하기 시작함 - 특히 존경받던 동료가 떠나면, 남은 사람은 “저 사람이 보는 뭔가를 나는 못 보고 있는 건 아닐까”를 생각하게 됨 - 외부 리크루터도 이 패턴을 빠르게 감지함 - 같은 팀 출신 엔지니어들이 LinkedIn 검색에서 자주 보이고, 프로필 업데이트가 몰리면, 해당 팀을 **집중 공략 대상으로 삼게 됨** - 이직 생각이 없던 엔지니어들도 연락을 받으며 면접을 보게 되고, 그 중 일부는 더 나은 기회를 실제로 발견함 - 한 클라우드 인프라 회사는 시니어 두 명이 3주 간격으로 떠난 뒤, **다음 3개월 동안 추가로 다섯 명**을 더 잃었음 - 내부 회고 결과, 첫 두 명의 이탈이 “회사 재무 상태에 이상이 있는 것 아니냐”는 **정보 공백에서 오는 불안을 증폭**시켰고, - 실제 이유는 앞서 이야기한 **에이전시 상실과 기술 부채 문제**였지만, 남은 이들이 “내가 모르는 뭔가를 떠난 사람들이 안다”고 추측하는 사이 리크루터가 이 틈을 적극 활용했음 - 지식 유실 비용은 숫자로 잡기 어렵지만, **이후 분기마다 나오는 실수와 지연, 재작업**으로 드러남 - 떠난 시니어는 “어떤 3줄의 코드는 건들면 안 되고, 어떤 3,000줄은 없애도 된다”는 감각을 갖고 있었고, - 어떤 고객이 왜 특수한 요구사항을 갖는지, 어떤 기술 부채가 “보기만 나쁜지” vs “실제로 위험한지”를 알고 있었음 - 한 결제 회사 사례에서는, 정산 시스템을 만든 시니어가 퇴사한 뒤, 새 엔지니어가 코드를 수정하면서 **어느 결제사 API의 undocumented한 특이 케이스**를 몰라 특정 거래 유형이 모두 실패하는 문제가 발생했음 - 이 버그를 찾는 데 2주가 걸렸고, 엔지니어링 비용 약 **4.5만 달러**, 실패한 거래를 수동으로 맞추는 동안 **18만 달러** 규모의 문제가 발생했으며, - 원래 시니어는 이 API의 버그를 시행착오로 발견해 머릿속에만 기억하고 있었음 ### Sometimes it really is the money — 진짜로 보상인 경우와 ‘핑계로서의 보상’ 구분 - 보상이 실제 원인인 경우도 존재하며, **타이밍 패턴이 다름** - 시장 대비 명확히 낮은 연봉, 늘어난 책임에 맞지 않는 보상, 신규 입사자가 본인과 같은 연봉을 받는 구조가 계속될 때, - 이직 전 **직접적으로 보상 문제를 먼저 꺼내는 경우**는 보상 이슈로 해결 가능한 영역임 - 반대로, 퇴사 인터뷰에서만 “보상”이 등장하고, **이미 몇 달 전부터 조용히 면접을 보고 있던 경우**, 보상은 동기가 아니라 **정당화 수단**인 경우가 많음 - 새로운 오퍼가 30% 높아서 “시장 수준”을 말하지만, 매칭 제안을 해도 “이미 다른 곳을 수락했다”라며 미적지근하게 반응하는 패턴임 - 이런 경우 실제 떠나는 이유는 앞서 말한 **에이전시, 기술 부채, 무의미한 업무**에 대한 결론임 - 이 글에서 제안하는 간단한 테스트는 **“20% 인상으로 붙잡을 수 있는가”** 임 - “그 정도면 고민해 보겠다”라면 보상이 주된 이슈일 가능성이 크고, - 그럼에도 이미 마음이 떠난 상태라면, **환경이 망가졌다고 판단한 상태**라서 돈만으로는 해결이 안 되는 상황임 - 한 개발자 도구 회사는 보상을 이유로 떠난 8명을 자세히 분석했고, - 이 중 꼭 붙잡고 싶은 5명에게 **매칭 이상의 카운터 오퍼**를 했지만 3명이 거절했음 - 이후 대화를 통해, 그들이 떠난 이유가 **계속 바뀌는 로드맵과 의미 없어진 작업**이었고, “회사 방향을 더 이상 믿을 수 없다”는 감각이었음 - 퇴사 인터뷰에서는 “보상”만 언급했지만, 실제 문제는 **일 자체의 의미 상실**이었음 ### Prevention beats retention bonuses — 사후 보너스보다 ‘조기 개입’이 훨씬 싸다 - 조기 개입을 위해서는, **계층 필터를 우회하는 정보 채널**이 필요하며, 몇 가지 방법이 반복해서 효과를 보이는 패턴임 - 첫 번째는 **정기적인 스킵레벨 대화**임 - 매주 몇 시간만 엔지니어 전 레벨과 직접 대화에 쓰면, 정식 라인에서는 올라오지 않는 **실제 생산성 장애물, 문제되는 기술 결정, 떨어지는 사기 지점**을 들을 수 있음 - 조직이 커지면 한 사람과의 빈도는 줄이되, **전체 커버리지를 유지하는 설계**가 중요함 - 한 100명 규모 엔지니어 조직의 CTO는 매주 4시간을 스킵레벨에 쓰며, - 30분씩 2주 회전으로 한 달 약 30명, **7개월이면 조직 전체를 한 바퀴 도는 구조**를 만들었음 - 일정이 항상 열려 있어 엔지니어가 필요할 때 예약할 수 있었고, 그 결과 **자발적 이직률이 연 18%에서 7%로 감소**했으며, CTO는 이를 “문제가 작고 고칠 수 있을 때 듣게 된 덕분”이라고 인식함 - 두 번째는 **외부 진단 관점**임 - 리포트라인에 속하지 않고, 인사 권한이 없는 **fractional CTO나 외부 어드바이저**가 인터뷰를 하면, 사람들은 훨씬 솔직하게 말하는 경향이 있음 - 내부 임원도 같은 질문을 할 수 있지만, **답이 달라지는 이유는 ‘답변자가 느끼는 위험’ 차이**임 - 한 SaaS 회사는 6개월 동안 시니어 4명을 잃은 뒤 fractional CTO를 투입해 전 레벨 인터뷰를 진행했고, - 엔지니어들이 느끼는 핵심 문제는 “아키텍처 리뷰가 **실제 결정을 하는 장이 아니라, 나중에 책임을 돌리기 위한 연극**처럼 느껴진다”는 점이었음 - 리뷰 요구사항을 다 반영해 통과해도, 몇 주 뒤 제품 결정으로 다시 뒤집히는 일이 반복되었고, - 회사는 이 프로세스를 없애고, 기술 구현에 대해 **엔지니어링에 실질적인 거부권**을 부여했음 - 세 번째는 **적어도 하나는 실제로 고치는 것**임 - 이야기만 듣고 아무 변화가 없으면 “말해도 소용없다”는 학습이 이루어지고, - 한 가지라도 눈에 보이게 고치면 “말하면 바뀐다”는 신호가 조직 전체에 퍼짐 - 한 헬스케어 기술 회사에서, 개발자가 CTO와 스킵레벨에서 **테스트가 45분 걸려 개발 속도가 느리다**고 말했을 때, - CTO는 “왜 아직도 안 고쳤는지”를 물었고, 개발자는 여러 차례 매니저에게 이야기했지만 매번 후순위가 됐다고 답했음 - CTO는 즉시 2주 작업 시간을 배정했고, 테스트 시간을 8분으로 줄이는 데 성공했으며, - 이 경험이 입소문을 타며, 다른 엔지니어들도 스킵레벨에서 문제를 가져오기 시작했음 - 비용은 약 **1.2만 달러의 엔지니어 시간**이었지만, “말하면 바뀐다”는 신호 가치가 훨씬 컸음 ### The $1.4m misdiagnosis — 잘못된 진단이 낳는 140만 달러짜리 오판 - 시니어 한 명을 교체하는 데 드는 **보수적인 비용 추산**은 27.5만~39.5만 달러 수준임 - 리크루팅 비용: 연봉의 20–25% 수준 - 공석 기간 생산성 손실: 3–6개월 동안 연 15만 달러 생산성 기준 4만~7.5만 달러 - 온보딩 기간 반쪽짜리 생산성: 6개월 동안 50% 효율로 일하는 손실분 3.5만~4만 달러 - 여기에 정량화하기 어려운 지식 손실, 의사결정 지연, 재작업이 뒤따름 - 시니어 5명을 잃으면 **1.4~2.0M 달러 규모의 손실**이 발생하는 셈이며, 앞서 사례 회사의 비용 추산과 맞물림 - 반대로, **실제 문제를 고치는 비용**은 훨씬 작지만, 조직 구조와 정치에 손을 대야 한다는 부담이 있음 - 기능 몇 개를 미루고, 불필요한 프로세스를 제거하고, 기술 결정을 엔지니어에게 넘기는 대신, - 많은 조직은 “엔지니어는 원래 비싸고, 시장 경쟁이 치열하다”는 설명을 선호함 - 이 설명은 내부 변화를 요구하지 않기 때문에 편하지만, **실제 원인(정보 구조, 결정 방식)을 가리는 역할**을 함 - 한 Series B 회사는 18개월 동안 엔지니어 7명을 잃으면서, CEO는 “경쟁사가 더 많이 준다”고 생각했지만, - 사후 분석 결과, 이들 중 5명은 떠나기 6개월 전 **구체적인 기술 결정, 프로세스 부담, 우선순위 문제**를 매니저에게 이야기했었음 - 이 이슈들은 1:1 메모에 “모니터링 중” 정도로만 기록되고, **어느 레벨에서도 임원에게 올라가지 않았음** - 그 결과, 임원은 “보상 문제”라고 믿었고, 엔지니어들은 “내 의견은 중요하지 않다”고 결론 내린, **서로 완전히 다른 현실을 살고 있었음** ### Information is cheaper than replacement — 정보 확보는 교체보다 압도적으로 싸다 - 떠나는 엔지니어들은 **임원들이 모르는 사실**을 알고 있음 - 어떤 기술 결정이 실패하고 있는지, 어느 프로세스가 시간을 낭비하는지, 어떤 관리 방식이 사람을 지치게 하는지에 대한 구체적인 정보임 - 이 정보는 조직 안에 항상 존재하지만, 계층 필터와 중간관리 인센티브 때문에 **임원 레벨까지 올라오지 못함** - 핵심 질문은 “**퇴사 전에 이 정보를 들을 것인가, 아니면 그들이 막았을 문제를 사고로 겪고 나서야 배울 것인가**”임 - 이를 잘 하는 조직은 정보 흐름을 전략적 자산으로 보고, 스킵레벨 채널을 공식적으로 설계하고, - 필터링된 보고서보다 **현장으로부터 직접 얻는 ‘그라운드 트루스’에 더 높은 가치를 두는 구조**를 갖춤 - 이런 조직에서는, 임원 시간이 **잘못된 전략 회의**에 쓰이는 것보다, - 매주 몇 시간이라도 **현장 이야기를 듣는 데 쓰일 때 ROI가 더 크다**는 사실을 인정함 - 시니어 한 명의 이직만 막아도, 연간 수만~수십만 달러 수준의 임원 시간 투자를 다섯 배 이상 회수하는 계산이 나옴 - 반대로, 이걸 잘못 다루는 조직은 **관리자의 편안함을 정보 정확도보다 우선**시함 - 스킵레벨을 금기시하고, 나쁜 소식이 제거된 보고서에 의존하며, - 이직 문제를 사표에서야 인지하고, 수백만 달러를 들여 사람을 교체하면서도 “왜 최고의 사람들이 떠나는지”를 끝내 이해하지 못함 - 맨 처음 사례의 시니어 엔지니어는 지금 **기술 아키텍처에 대해 엔지니어링에 거부권이 있고, CTO가 정기적으로 스킵레벨을 유지하는 회사**에서 일하고 있음 - 그도, 동료들도 이직 준비를 하지 않고 있고, 회사의 자발적 이직률은 같은 단계 회사 평균의 절반 이하인 **12% 수준**임 - 이 회사 임원들은 “무너질 수 없을 만큼 늦기 전에” 무엇이 망가졌는지 듣고 있고, 이는 단순한 메커니즘, 즉 **꾸준히 묻고, 말할 수 있는 구조를 유지하는 것**으로 만들어진 결과임 ## Comments ### Comment 47835 - Author: wedding - Created: 2025-12-16T13:20:50+09:00 - Points: 5 임원들이 봐야 할 내용인데, 탈주할 저희가 보고 있는게 유머네요..ㅎ.. ### Comment 47959 - Author: rrr6ttt - Created: 2025-12-18T16:11:01+09:00 - Points: 1 ㅇㄱㄹㅇ ### Comment 47950 - Author: kuthia - Created: 2025-12-18T13:24:15+09:00 - Points: 1 사실, 좋은 엔지니어링이라는 비즈니스 목표를 가진 회사는 많지 않죠... ### Comment 47907 - Author: bakyeono - Created: 2025-12-17T15:55:08+09:00 - Points: 2 다들 같은 경험이신 것 같아 위안이 되는 걸까요...? ### Comment 47898 - Author: redlasha - Created: 2025-12-17T13:46:11+09:00 - Points: 2 진짜 공감되네요 ### Comment 47890 - Author: sinbumu - Created: 2025-12-17T11:33:28+09:00 - Points: 2 진짜 여러 부분에서 공감 ㅋㅋ 개 답답해서 걍 내려놓고 돈 받는만큼만 일하자 모드 되니 오히려 일이 스무스 하게 진행된다고 좋아함. 실제론 리스크가 있는 개발방향성이 보여도 알바아님 상태가 된건데 ### Comment 47872 - Author: nutella - Created: 2025-12-17T09:19:57+09:00 - Points: 2 이 글이 Part 1 examined why senior engineers leave이고 Part 2 The Economic Intervention That Stops Engineer Attrition 글도 있네요. https://codegood.co/writing/the-economic-intervention-that-stops-engineer-attrition ### Comment 47902 - Author: xguru - Created: 2025-12-17T15:13:19+09:00 - Points: 1 - Parent comment: 47872 - Depth: 1 오 감사합니다. 이것도 별도 토픽으로 등록했습니다 [엔지니어 이직을 멈추는 경제적 개입 방법](https://news.hada.io/topic?id=25146) ### Comment 47870 - Author: duddnd649 - Created: 2025-12-17T08:47:17+09:00 - Points: 1 임원이 이글을 볼 수 잇게 못할까.. ### Comment 47857 - Author: cysl0 - Created: 2025-12-16T22:17:09+09:00 - Points: 1 틀린 말이 없네요 ### Comment 47847 - Author: seoseonyu - Created: 2025-12-16T16:40:18+09:00 - Points: 1 너무 공감 되는 글입니다. ### Comment 47845 - Author: nicewook - Created: 2025-12-16T15:46:33+09:00 - Points: 1 공감이 됩니다. ### Comment 47839 - Author: nullptr - Created: 2025-12-16T13:54:37+09:00 - Points: 1 "세상은 다 똑같다" ### Comment 47837 - Author: qaplazlm41 - Created: 2025-12-16T13:52:44+09:00 - Points: 2 이걸 임원들이 봐야 하는데... ### Comment 47831 - Author: jjw9512151 - Created: 2025-12-16T12:47:01+09:00 - Points: 2 팩트로 진짜 조목조목 패는군요..ㅋㅋㅋ ### Comment 47828 - Author: caniel - Created: 2025-12-16T12:26:00+09:00 - Points: 1 공감백배네요. ### Comment 47827 - Author: ethanhur - Created: 2025-12-16T12:19:54+09:00 - Points: 1 we are the world