Github Pages
훌륭한 엔지니어들이 대기업에서 엉망인 코드를 작성하게 되는 이유
'빅테크에서 왜 나쁜 코드가 나올까' 에 대한 가장 현실적인 답: 대부분의 코드 변경은 해당 코드베이스를 잘 모르는 개발자가 한다. 평균 재직 1~2년, 잦은 조직 개편, 베테랑의 과부하가 낳는 구조적 결과.
핵심 요약
저자의 논증 흐름은 4단계다.
- 대부분의 변경은 '초심자' 가 한다 — 지난 6개월 내 회사/코드베이스/언어에 온보딩한 사람
- '베테랑' 역할은 비공식이고 지속 불가능 — 리뷰 대역폭 부족, 본인 업무 성과 감점 리스크
- 생산적 엔지니어의 평균 모습 — 유능하지만 낯선 코드베이스에서 마감에 쫓기는 상태
- 회사는 이를 '의도된 트레이드오프' 로 수용 — 엔지니어를 대체 가능한 자원으로 보고 특정 시스템에 묶이지 않게 설계
결론: 개인 엔지니어가 이를 바꿀 힘은 없다. 선택지는 '베테랑' 을 목표로 하되 PIP 리스크를 감수 하거나, 불순한 엔지니어링의 현실을 받아들이고 트레이드오프를 공개적으로 말하기.
'엉망인 코드 = 무능한 엔지니어' 라는 개인 귀인을 버리고, 코드 품질 = 시스템 상태(재직 기간, 이동 주기, 리뷰 대역폭)의 함수 로 보는 관점. 순수(pure) 엔지니어링 vs 불순(impure) 엔지니어링의 구분이 프레임이다.
면접/리뷰에서 '왜 빅테크 코드가 이 모양이냐' 를 '엔지니어 탓' 으로 귀결하는 답은 얕다. 실제 메커니즘:
- 평균 재직 1~2년: RSU 구조상 4년째 연봉이 50% 급감 → 이탈 유인
- 사내 이동 주기: 1년에 한 번 이상 조직 개편. 한 팀 3년이 장기 근속
- 코드베이스 수명 10년+: 변경자의 맥락 이해도가 체계적으로 부족
- 베테랑 = 과부하: 리뷰가 업무 성과로 잡히지 않아 충분한 시간 할애 불가
이건 채용 바의 문제가 아니라 조직 설계의 의도된 트레이드오프 (엔지니어 이동성 > 코드 전문성) 다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
순수 엔지니어링 vs 불순한 엔지니어링
| 축 | 순수(Pure) | 불순(Impure) |
|---|---|---|
| 예시 | Zig, TypeScript, 리액트 내부 | 빅테크 프로덕트 코드 |
| 마감 | 자율 | 외부 강제 |
| 컨텍스트 | 깊게 누적 | 프로젝트마다 새로 |
| 나쁜 코드의 원인 | 무능 | 환경적 불가피성 |
| 성공 기준 | 아름다움 + 일관성 | 전체 시스템 동작 |
빅테크 엔지니어는 배관공/전기공 에 가깝다. 팀 이동 = 건설 현장 이동.
오픈소스 기준으로 회사 코드를 평가하는 것. 회사 코드는 '충분히 동작' 이 성공 기준.
베테랑 = 정식 역할이 아니다
'이 시스템에 대한 깊은 지식을 가진 몇 안 되는 엔지니어' 는 자원봉사 상태다. 회사는 이 역할에 별도 보상을 하지 않고, 평가는 '본인 프로젝트 성과' 로 한다.
리뷰 시간에 투자 → 개인 성과 떨어짐 → PIP 위험
개인 성과에 투자 → 리뷰 얕아짐 → 나쁜 코드 방치
이 이중구속은 개별 엔지니어가 해결할 수 없다. 조직적 설계 문제.
'베테랑이 되라' 조언을 '본인 시간으로 리뷰 많이 하라' 로 받아들이는 것. 회사가 그 행동을 평가에 반영하지 않는다면 자기 착취 로 끝난다.
읽는 순서
- 1이론
저자의 전작 'Seeing like a software company' 도 함께 읽고, 조직 구조가 코드 품질에 미치는 영향을 정리.
- 2구현
본인 회사의 최근 변경된 PR 10개를 무작위로 골라 (1) 작성자의 해당 코드베이스 경험 기간, (2) 리뷰어의 경험 기간을 수집해 본다.
- 3실무
현재 팀의 '베테랑 한두 명' 을 파악하고, 그들에게 과부하가 걸리지 않도록 페어 리뷰/쉐도잉 으로 지식 이전을 제안.
- 4설명
'왜 이 코드가 이 모양인가' 에 대한 답을 '개인 탓' 이 아니라 '구조 탓' 으로 프레이밍하는 연습. 단, 자신의 PR 에는 높은 기준을 유지.
면접 연결 질문
[감점 답변] '엔지니어가 게을러서'. [좋은 답변] 세 가지 구조적 원인: (1) 평균 재직 1~2년 + 잦은 조직 개편으로 변경자 맥락 부족, (2) 코드베이스 수명은 10년 이상이라 기존 엔지니어 대부분이 '초심자' 상태, (3) 베테랑이 비공식 역할이라 리뷰 대역폭 부족. 이는 회사의 의도된 트레이드오프(엔지니어 이동성 ↔ 전문성).
[감점 답변] '좋은 코드 작성'. [좋은 답변] (1) 변경 전 git blame 과 관련 PR 맥락 읽기, (2) 테스트 없는 코드엔 테스트부터, (3) 리뷰어에게 '이 변경이 놓친 맥락이 있을 수 있다' 명시, (4) 한 시스템에 최소 6개월~1년 머무르기(회사가 허락한다면). 구조 변경은 개인 힘 밖이지만 본인 변경의 맥락 부족은 줄일 수 있다.
자기 점검
'시니어가 되면 자동으로 베테랑' 이라는 오해. 시니어리티(등급) 와 특정 시스템 전문성은 다른 축이다.