왜 최고의 엔지니어들은 다른 회사 면접을 보고 있는가
https://codegood.co/writing/why-your-best-engineers-are-interviewing-elsewhere
아티클을 번역하고, 간결하게 정리한 글입니다. 원문을 모두 번역한 글은 숨김 단락을 누르면 확인 할 수 있어요!
1. IT 기술·조직 관점 번역
2018년의 한 사례
2018년, 연 매출(ARR) 4,000만 달러 규모의 SaaS 회사에서 한 시니어 엔지니어는 제안된 데이터베이스 아키텍처가 확장성 문제를 일으킬 것이라며 6개월 동안 반대했다. 프로덕트 조직은 “빠르게 출시하는 것”을 원했다. 엔지니어링 리더십은 그의 기술적 판단에 동의했지만, 프로덕트 조직에 맞서지는 않았다. 결론은 늘 흔한 결정이었다.
“지금은 출시하고, 나중에 리팩터링하자.”
그 엔지니어는 그 주에 바로 이직 면접을 시작했다. 이유는 기술적 결정 때문이 아니었다. 그런 결정은 늘 있기 때문이다. 문제는 그의 판단이 중요하지 않았다는 사실이었다.
8개월 후 시스템은 매일 성능 이슈를 겪기 시작했다. 18개월 후 회사는 시니어 엔지니어 5명을 잃었고, 문제 원인을 파악하기 위해 프랙셔널 CTO(외부 CTO)를 고용했다.
진단 결과
진단은 단순했다.
“임원진은 엔지니어들이 불만을 가지고 있다는 사실을 퇴사하기 전까지 전혀 알지 못했다.”
퇴사 인터뷰에는 늘 그렇듯 “더 나은 기회”, “경쟁력 있는 보상” 이라는 말이 적혀 있었다. CEO는 남아 있는 엔지니어들에게 15% 연봉 인상을 승인했다. 그러나 그 후에도 엔지니어들은 계속 떠났다.
문제는 보상이 아니었다. 정보가 조직의 위계 구조를 따라 위로 전달되지 않았다는 것이 진짜 문제였다. 문제가 임원 레벨에 도달했을 때는 이미 수개월 전에 퇴사 결심이 끝난 상태였다.
계층 구조는 나쁜 소식을 걸러낸다
조직은 복잡성을 관리하기 위해 계층을 만든다. 하지만 그 부작용은 정보가 각 단계에서 필터링된다는 것이다.
주니어 엔지니어: “이 기술적 결정, 위험한 것 같아요”
시니어 엔지니어 → 매니저에게 전달
매니저:
이 문제가 자신을 나쁘게 보이게 하는지,
아니면 굳이 올릴 가치가 있는지 판단
VP of Engineering: 축약된 버전만 듣거나 아예 못 들음
CTO: “우리가 처리 중입니다”
CEO: “모든 게 계획대로입니다”
각 계층을 거칠수록 디테일과 긴급성은 사라진다. 임원에게 도달했을 때는 이미 위기이거나, 완전히 사라진 정보다.
중간관리자는 악의를 가진 것이 아니다. 그들은 “자기 레벨에서 문제를 해결하는 것”이 역할이라고 믿는다. 하지만 그 결과는 정보 억압(information suppression)이다.
실제 예시: 120명 엔지니어 조직
3월: 프론트엔드 팀이 신규 대시보드 성능 문제 인지
4월: 코드 리뷰에서 공개적으로 논의
5월: 엔지니어링 매니저 인지
6월: VP of Engineering → “성능 최적화 작업 중”
7월: CTO → “일부 성능 작업 진행 중”
8월: 최대 고객이 “대시보드를 쓸 수 없다”고 항의
임원진은 이를 갑작스러운 위기로 인식했다. 하지만 엔지니어들은 5개월 전부터 알고 있었다.
결과
리소스를 결정하는 사람들은 항상 몇 달 뒤처진 정보, 그리고 나쁜 소식이 제거된 정보를 기반으로 판단한다.
엔지니어: “이 DB는 8월에 터진다”
매니저: “엔지니어들이 10월부터 불만”
VP: “12월쯤 사기(morale) 이슈”
CTO: “2월에 엔지니어 퇴사 발생”
모두 각자 문제를 잘 처리하고 있다고 믿었다. 하지만 그들은 문제를 해결 불가능하게 만드는 정보 지연(latency)을 만들고 있었다.
체계적인 명령 체계라는 편리한 허구
많은 조직은 skip-level 대화(임원이 중간 단계를 건너 직접 엔지니어와 대화)를 부적절하다고 여긴다.
이유는 늘 비슷하다.
중간관리자 권한 약화
지휘 체계 붕괴
불신 조성
마이크로매니지먼트
겉으로는 조직 건강을 위한다지만, 실제로는 중간관리자를 보호하는 조직의 면역 반응이다.
CTO가 주니어 엔지니어와 직접 이야기하면 현실을 듣게 된다. 보고서에만 의존하면 관리자가 들려주고 싶은 이야기만 듣게 된다.
엔지니어가 떠나는 진짜 이유: 연봉이 아니다
퇴사 인터뷰는 원인을 잘못 진단한다. 보상은 측정 가능하고 말하기 쉬운 이유일 뿐이다.
반복적으로 등장하는 실제 원인은 세 가지다.
1) 자율성(Agency)의 상실
실패할 걸 아는 시스템을 만들라고 강요받음
기술적 판단이 비기술적 이유로 반복적으로 무시됨
결과가 실패하면 책임은 엔지니어 몫
이는 자존심 문제가 아니다. 전문가로서의 판단이 무의미해졌다는 신호다.
2) 감당 불가능한 기술 부채
DB 복제, 배포 자동화, 모니터링 개선 필요
매 분기마다 “기능 개발이 우선”이라며 밀림
결국 예측된 시점에 장애 발생
“왜 미리 막지 않았냐”는 질문을 받음
엔지니어는 자신이 예측한 실패의 책임을 지고 싶지 않아서 떠난다.
3) 똑똑한 사람이 멍청한 일을 하게 되는 상황
연봉 1억~2억 엔지니어가 폐기해야 할 시스템 유지
의미 없는 프로세스 쇼(Process Theatre)
누구도 믿지 않는 산출물을 만드는 회의들
이는 경제적 낭비이자 인재 소진이다.
2. IT 조직 관점 핵심 정리
① 문제의 본질
기술 문제가 아니라 정보 구조 문제
계층형 조직은 나쁜 소식을 위로 전달하지 않는다
임원은 “문제가 있다”는 사실을 퇴사 통보로 처음 안다
② 엔지니어 이탈의 조기 신호
주니어
6~12개월 전
시니어가 더 이상 기술적으로 싸우지 않음
시니어
4~8개월 전
회의에서 동의만 함, 코드 리뷰 피상적
매니저
2~4개월 전
문서화 급증, 지식 이전
임원
0~1개월 전
“퇴사합니다”
③ 효과적인 대응 전략
정기적인 skip-level 미팅
외부 시각(프랙셔널 CTO, 어드바이저)
최소 1개의 문제라도 실제로 해결
“문제를 듣는 것”이 아니라 “문제를 말하면 바뀐다”는 신호가 중요
④ 경제적 결론
시니어 엔지니어 1명 교체 비용: 약 3~4억 원
CTO가 매주 몇 시간 엔지니어와 직접 대화하는 비용: 연 수천만 원
ROI는 비교 불가
3. 한 문장 요약
최고의 엔지니어는 연봉 때문에 떠나는 것이 아니라, 자신의 기술적 판단이 조직에서 의미 없다고 느끼는 순간 떠난다. 그리고 그 신호는 항상 퇴사 훨씬 이전에 조직 내부에 존재한다.
4. Reference
Last updated