아무도 단순함으로는 승진하지 못한다.

요약 번역

엔지니어 A는 기능을 50줄의 깔끔한 코드로 이틀 만에 완성한다. 읽기 쉽고, 테스트하기 쉽고, 다음 사람이 바로 이해할 수 있다. 엔지니어 B는 비슷한 기능을 받아들고 "더 견고하게" 만들겠다며 추상화 레이어, pub/sub 시스템, 설정 프레임워크를 도입해 3주를 쓴다. 승진 시즌이 오면 B의 이력은 "확장 가능한 이벤트 기반 아키텍처 설계, 여러 팀이 채택한 재사용 추상화 레이어 구축"으로 화려하게 채워진다. 반면 A의 이력은 "기능 X 구현" 세 단어뿐이다. A의 작업이 더 나았지만, 단순하기 때문에 보이지 않는다. 아무도 자신이 피한 복잡성으로는 승진하지 못한다.

이 인센티브 문제는 입사 면접에서부터 시작된다. 시스템 설계 면접에서 단순한 솔루션을 제안하면 "사용자가 천만 명이면?"이라는 압박이 날아온다. 서비스를 추가하고, 큐를 넣고, 샤딩을 그려야 면접관이 만족한다. 후보자가 배우는 교훈은 "단순한 답은 틀리진 않았지만 충분히 인상적이지 않다"는 것이다. 디자인 리뷰에서도 마찬가지다. 깔끔한 설계를 내놓으면 "미래 대비는?" 질문이 돌아오고, 결국 아직 존재하지도 않는 요구사항을 위한 추상화를 쌓게 된다. 코드 중복 몇 줄을 피하려고 만든 추상화가 오히려 다음 엔지니어가 반나절을 이해하는 데 쓰게 만드는 결과를 낳기도 한다.

저자는 복잡성 자체가 나쁜 것이 아니라고 분명히 선을 긋는다. 수백만 트랜잭션을 처리하거나 10개 팀이 같은 제품을 개발한다면 분산 시스템과 서비스 경계가 필요하다. 문제는 정당하지 않은 복잡성, 즉 "3년 후 DB 한계에 부딪힐 수도 있으니 지금 샤딩하자"는 식의 선제적 과잉 설계다. 진정한 시니어의 길은 더 많은 도구와 패턴을 익히는 것이 아니라 그것들을 언제 쓰지 않을지 아는 것이다. 복잡성을 추가하는 건 누구나 할 수 있지만, 빼놓을 줄 아는 데는 경험과 자신감이 필요하다.

해법으로 엔지니어에게는 단순함을 가시화하라고 조언한다. "기능 X 구현" 대신 "이벤트 기반 아키텍처 등 세 가지 접근을 검토한 뒤, 현재 및 예상 요구사항에 직접 구현이 충분하다고 판단하여 이틀 만에 출시, 6개월간 무장애 운영"이라고 써야 한다. 만들지 않기로 한 결정도 결정이며, 그에 맞게 문서화해야 한다. 리더에게는 "확장성을 고려했나?" 대신 "출시할 수 있는 가장 단순한 버전은 무엇이고, 더 복잡한 것이 필요하다는 신호는 무엇인가?" 를 먼저 물으라고 제안한다. 승진 심사에서 화려한 시스템 목록에 "이게 정말 다 필요했나?"라고 되물어야 하고, 코드를 삭제한 엔지니어, "아직 필요 없다"고 말한 엔지니어를 공개적으로 인정해야 한다. 복잡성을 보상하고 단순함을 무시하면서 결과가 달라지길 기대해서는 안 된다.