단순함으로는 승진하지 못한다

• 소프트웨어 엔지니어링 문화에서 복잡한 시스템을 만드는 사람이 더 인정받고, 단순한 해결책을 선택한 사람은 평가받지 못하는 구조가 지속됨
• 승진 평가와 인터뷰, 설계 리뷰 등에서 복잡성이 “영향력”으로 오인되어, 불필요한 추상화와 확장성을 추가하는 경향이 강화됨
• 단순한 구현은 “보이지 않는 성과”로 남지만, 복잡한 구조는 화려한 서술과 문서화로 승진 서류를 채우기 쉬움
• 진정한 숙련도는 더 많은 도구를 쓰는 것이 아니라, 언제 복잡성을 배제해야 하는지 아는 판단력과 자신감에 있음
• 엔지니어와 리더 모두 단순함을 가시화하고, 이를 공식적으로 인정하는 평가·보상 체계를 만들어야 함

복잡성이 보상받는 구조

• 엔지니어링 팀 내에서 과도한 설계와 추상화가 더 높은 평가를 받는 사례 제시
  • 단순한 기능을 빠르게 구현한 엔지니어 A는 “Implemented feature X”로 요약됨
  • 반면, 복잡한 아키텍처를 만든 엔지니어 B는 “확장 가능한 이벤트 기반 구조 설계” 등으로 서류를 채워 승진 가능성이 높음
• 복잡성은 똑똑해 보이지만, 실제로는 시스템이 잘못된 평가 기준에 의해 그렇게 인식됨
• 이러한 인센티브 왜곡은 채용 인터뷰 단계부터 시작되어, 단순한 답변보다 복잡한 설계가 더 인상적으로 받아들여짐

인터뷰와 설계 리뷰에서의 왜곡

• 시스템 설계 인터뷰에서 단순한 해법을 제시하면 “확장성은?” 같은 질문으로 복잡성을 유도받음
  • 지원자는 큐, 샤딩, 마이크로서비스를 추가하며 복잡한 다이어그램을 그려야 만족스러운 반응을 얻음
• 설계 리뷰에서도 “미래 대비(future-proof)” 요구로 인해 필요 없는 계층과 추상화가 추가됨
• 이런 문화는 “단순함은 충분하지 않다”는 잘못된 학습을 남김

불필요한 복잡성과 그 결과

• 코드 중복을 피하려다 이해하기 어려운 추상화를 만든 사례 언급
  • 결과적으로 유지보수가 어려워지고, 사용자에게는 아무런 이득이 없음
• 복잡성이 필요한 경우도 존재하지만, 문제의 본질은 “정당하지 않은 복잡성(unearned complexity)” 에 있음
  • 실제 한계에 부딪혀 샤딩이 필요한 경우와, “언젠가 필요할지도 모른다”는 이유로 미리 도입하는 경우는 다름

진정한 시니어 엔지니어의 판단

• 숙련된 엔지니어는 복잡성을 추가하지 않을 때를 아는 사람
  • 단순한 코드와 구조는 마법처럼 보이지 않지만, 그것이 바로 경험의 결과임
• “누구나 복잡성을 추가할 수 있지만, 그것을 생략하려면 경험과 자신감이 필요하다”는 점을 강조

단순함을 가시화하는 방법

• 엔지니어는 자신의 단순한 선택을 문서화하고 설명해야 함
  • 예: “세 가지 접근법을 검토한 뒤, 현재 요구사항에 가장 적합한 단순 구현을 선택해 2일 만에 배포, 6개월간 무사 운영”
• 설계 리뷰에서 “미래 대비” 요구가 나오면, 추가 복잡성의 비용과 시점을 명확히 제시해 판단 근거를 남겨야 함
• 매니저와의 대화에서도 의사결정의 맥락을 평가에 반영하도록 요청할 필요 있음

리더십과 조직의 역할

• 엔지니어링 리더는 인센티브 구조를 재설계해야 함
  • 현재의 승진 기준은 “구축 규모와 복잡성” 중심으로 짜여 있음
  • “피한 복잡성” 또한 영향력으로 인정해야 함
• 설계 리뷰에서는 “확장성은?” 대신 “가장 단순한 버전은 무엇이며, 복잡성이 필요한 신호는 무엇인가?”를 질문해야 함
• 승진 논의에서는 “이 모든 시스템이 정말 필요했는가?”를 검증해야 함
• 팀 내 공개 칭찬에서도 복잡한 프로젝트뿐 아니라 단순함을 지킨 결정을 함께 인정해야 함

결론

• 복잡성을 보상하고 단순함을 무시하는 한, 조직은 계속 복잡한 시스템을 얻게 됨
• 그러나 해결책은 단순함을 보이게 만들고, 공식적으로 보상하는 구조로 전환하는 것
• 결국 “복잡하지 않은 것이 바로 핵심”임