AI 요약
이 기사는 현대 개발 조직에서 '단순함(Simplicity)'이 미덕임에도 불구하고 실제 보상과 승진 체계에서는 외면받는 역설적인 상황을 다룹니다. Edsger Dijkstra의 말을 인용하며, 단순함은 성취하기 어렵고 이해시키기 위한 교육이 필요하지만, 복잡성은 그 자체로 똑똑해 보이기 때문에 더 매력적으로 보인다고 지적합니다. 구체적인 사례로 50줄의 코드로 깔끔하게 기능을 구현한 '개발자 A'와, 동일한 기능을 위해 3주 동안 pub/sub 시스템과 추상화 레이어를 도입한 '개발자 B'를 비교합니다. 결과적으로 승진 심사에서 A의 성과는 '기능 X 구현'이라는 짧은 문구로 남는 반면, B의 성과는 '확장 가능한 이벤트 기반 아키텍처 설계'라는 화려한 서사로 포장되어 더 높은 평가를 받게 됩니다. 이러한 복잡성 선호 경향은 채용 면접의 시스템 디자인 단계에서부터 시작되어, 1,000만 명의 사용자를 가정한 과도한 설계를 유도함으로써 개발 문화 전반에 악영향을 미치고 있습니다.
핵심 인사이트
- 에츠허르 데이크스트라(Edsger Dijkstra)의 통찰: 단순함은 위대한 미덕이지만 이를 달성하기 위해서는 노력이 필요하며, 반대로 복잡성은 더 잘 팔린다는 점을 강조함
- 단순함의 보이지 않는 가치: 개발자 A는 단 50줄의 코드로 며칠 만에 기능을 배포했지만, 결과물이 너무 단순해서 오히려 승진 평가서에 쓸 내용이 부족해지는 역설 발생
- 복잡성의 서사적 유리함: 개발자 B는 3주 동안 복잡한 추상화와 프레임워크를 도입해 'Staff+' 직급에 걸맞은 화려한 기술적 성과 서사를 확보함
- 시스템적 인센티브 오류: 기업의 평가 시스템이 '구축하지 않은 복잡성'에 대해서는 보상하지 않기 때문에 개발자들이 의도적으로 오버 엔지니어링을 선택하게 됨
주요 디테일
- 기술적 비교: 개발자 A의 직관적인 구현 방식과 대비되는 개발자 B의 신규 추상화 레이어, 구성 프레임워크, pub/sub 통신 시스템 도입 사례 제시
- 승진 서사의 차이: 단순 구현은 '기능 X 구현'으로 끝나는 반면, 복잡한 구현은 '확장 가능한 이벤트 기반 아키텍처 설계' 및 '타 팀 도입 유도'로 포장됨
- 면접 시스템의 문제: 시스템 디자인 면접에서 단일 DB와 간단한 API를 제안하면 면접관은 '1,000만 명 사용자(ten million users)' 시나리오를 던지며 복잡한 솔루션을 강요함
- 학습된 행동: 개발자들은 면접 과정에서 '복잡성이 사람들을 감동시킨다'는 교훈을 얻고 이를 실제 경력 전반에 적용하게 됨
- 유지보수 측면: A의 코드는 읽기 쉽고 테스트하기 용이하지만, B의 복잡한 시스템은 수많은 PR(Pull Request)과 문서를 양산하며 조직의 비용을 높임
향후 전망
- 엔지니어링 문화의 왜곡: 성과 측정이 코드의 질이나 간결함보다 가시적인 기술적 복잡성에 치중될 경우 조직 전체의 유지보수 부채가 급증할 것으로 예상됨
- 평가 모델의 변화 필요성: 단순함을 추구하는 엔지니어의 가치를 제대로 평가하기 위해 '피한 복잡성'이나 '비용 절감 효율'을 측정하는 새로운 인사이트가 요구됨