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

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

---

단순함 vs 복잡함: 승진 서사의 비대칭

• 같은 팀의 두 엔지니어 사례: Engineer A는 50줄의 간결한 코드로 며칠 만에 기능을 출시, Engineer B는 새로운 추상화 레이어, pub/sub 시스템, 설정 프레임워크를 도입해 3주에 걸쳐 완성
• Engineer B의 작업은 승진 패킷에 "확장 가능한 이벤트 기반 아키텍처 설계, 재사용 가능한 추상화 레이어 도입, 설정 프레임워크 구축"으로 기술 가능
• Engineer A의 작업은 "기능 X 구현"이라는 세 단어로만 표현됨
  • 실제로는 더 나은 작업이었지만, 단순하게 보이도록 만들었기 때문에 비가시적 기여가 됨
• "피한 복잡성"으로는 아무도 승진하지 못함 — 복잡성이 똑똑해 보이는 이유는 평가 체계가 그것을 보상하도록 구성되어 있기 때문

면접과 디자인 리뷰에서 복잡성이 강화되는 구조

• 시스템 디자인 면접에서 단순한 솔루션(단일 데이터베이스, 직관적 API, 캐싱 레이어)을 제안하면 면접관이 "천만 명의 사용자가 오면?"이라고 압박
  • 서비스, 큐, 샤딩을 추가할수록 면접관이 만족하는 경험을 하게 됨
  • 후보자가 배우는 교훈: "단순한 답은 충분하지 않았다"
• 면접관이 압박하는 데 합리적 이유(압박 속 사고력, 분산 시스템 이해도 확인)가 있을 수 있지만, 후보자에게 전달되는 메시지는 "복잡성이 인상적"이라는 것
• 디자인 리뷰에서도 "미래 대비(future-proof) 를 해야 하지 않나?"라는 질문에 불필요한 레이어와 추상화를 추가하게 되는 패턴 반복
  • 문제가 요구해서가 아니라, 회의실이 기대해서 추가하는 것
• 코드 중복 몇 줄을 피하려고 만든 추상화가 오히려 이해와 유지보수를 어렵게 만드는 사례 다수 경험
  • 코드는 더 "전문적"으로 보였지만, 사용자는 기능을 더 빨리 받지 못했고, 다음 엔지니어는 변경 전 반나절을 추상화 이해에 소비

적정 복잡성 vs 불필요한 복잡성(Unearned Complexity)

• 복잡성 자체가 문제가 아님 — 수백만 건의 트랜잭션 처리에는 분산 시스템이, 10개 팀이 같은 제품을 만들면 서비스 경계가 필요
• 문제는 불필요한 복잡성: "데이터베이스 한계에 도달했으니 샤딩 필요"와 "3년 후에 한계에 도달할 수 있으니 지금 샤딩하자"의 차이
• 이를 이해하는 엔지니어의 코드와 아키텍처는 "당연히 그렇지"라는 느낌, 마법도 영리함도 없고 이해 못해서 바보 같은 느낌도 없음
• 시니어로 가는 실제 경로는 더 많은 도구와 패턴을 배우는 것이 아니라, 언제 사용하지 않을지를 아는 것 — 복잡성을 추가하는 건 누구나 가능하지만, 빼는 데는 경험과 자신감 필요

엔지니어를 위한 실천 방안

• 단순함을 가시화해야 함 — 작업이 스스로 말해주지 않음, 평가 체계가 그것을 들을 수 있도록 설계되어 있지 않기 때문
• "기능 X 구현" 대신 "이벤트 기반 아키텍처와 커스텀 추상화 레이어를 포함한 세 가지 접근법을 평가한 뒤, 단순 구현이 현재와 예상 요구사항을 모두 충족한다고 판단, 2일 만에 출시하고 6개월간 무장애 운영" 으로 기술
  • 무언가를 만들지 않기로 한 결정도 결정이며, 중요한 결정 — 그에 맞게 문서화 필요
• 디자인 리뷰에서 "미래 대비해야 하지 않나?"라는 질문에 단순히 굴복하지 말고, "나중에 추가하려면 이만큼 걸리고, 지금 추가하면 이만큼의 비용 발생, 기다리는 게 낫다"고 제시
  • 반박이 아니라 검토를 마쳤음을 보여주는 것
• 매니저에게 "작업 문서화 방식이 코드뿐 아니라 내가 내린 결정을 반영하도록 하고 싶다"고 직접 대화 — 매니저 입장에서도 옹호할 언어를 제공받는 것
• 이 모든 노력에도 가장 정교한 시스템을 만든 사람만 승진시키는 팀이라면, 그것도 유용한 정보 — 일부 조직은 단순함을 진심으로 가치 있게 여기고, 다른 조직은 말만 그렇게 하면서 반대를 보상

엔지니어링 리더를 위한 실천 방안

• 인센티브를 설정하는 것은 리더의 책임 — 대부분의 승진 기준은 복잡성을 보상하도록 설계되어 있으며, "임팩트"는 구축한 것의 규모와 범위로 측정되는 경향
  • 구축한 것뿐 아니라 회피한 것도 평가에 반영해야 함
• 디자인 리뷰에서 "확장성은 고려했나?" 대신 "출시 가능한 가장 단순한 버전은 무엇이고, 더 복잡한 것이 필요하다는 구체적 신호는 무엇인가?" 로 질문 변경
  • 이 한 가지 질문이 게임을 바꿈: 단순함을 기본값으로, 복잡성에 입증 책임 부여
• 승진 논의에서 인상적인 시스템 목록으로 구성된 패킷에 "그게 전부 필요했나? pub/sub 시스템이 실제로 필요했나, 아니면 서류상 좋아 보였을 뿐인가?"라고 반문 필요
• 팀원이 깔끔하고 단순한 것을 출시하면 서사 작성을 도와야 함 — "여러 접근법을 평가하고 문제를 해결하는 가장 단순한 것을 선택"이 설득력 있는 승진 사례가 되려면 리더가 실제로 그렇게 취급해야 함
• 팀 채널에서 공개적으로 축하하는 대상에 주의 — 크고 복잡한 프로젝트만 칭찬하면 사람들은 그것에 최적화
  • 코드를 삭제한 엔지니어, "아직 필요 없다"고 말하고 맞았던 엔지니어를 인정해야 함

[shakespeares]

평가자의 이해도가 좋아야 한다고 봅니다.
설명들도 충분히 들어야하는 것도 맞구요.

[aa1567]

대부분의 현실은 단순하게 기능구현만 할줄 앎 vs 확장성 있게 설계 가능하면서 트레이드오프도 잘함 아닌가요

[devsepnine]

복잡하게 작업 했어도 기능 X 구현이라고 할 수 있는건데
평가자에게 그걸 어떤 방식으로 표현 하느냐의 차이네요

[GN⁺]

Hacker News 의견들

• 면접 질문에서 두 사람이 이메일로 스프레드시트를 주고받는 상황을 제시받았음
  나는 Google Sheets로 옮기겠다고 답했는데, 면접관은 내가 직접 도구를 설계하길 원했던 것 같음
  그때는 어색했지만, 지금도 어떤 교훈을 얻어야 할지 잘 모르겠음

  • 이런 상황은 면접관 교육 실패라고 생각함
    좋은 답변을 인정하고, 그다음에 “이건 기술 설계 평가를 위한 가상 상황이니 새 시스템을 설계해보자”고 유도했어야 함
    지원자가 그 설정을 받아들이지 못하면 그건 또 다른 신호로 평가하면 됨
    나 같으면 “기존 솔루션이 없다고 가정하고 새로 설계할까요?”라고 물어볼 것임
    이건 면접관이 자신이 원하는 답만 듣고 싶어 하는 시스템 설계 버전의 알고리즘 논쟁과 같음
  • 내 공동창업자가 Stripe 인수 논의 중에 시스템 설계 면접을 봤는데, 요구사항을 듣고 “그냥 Postgres에 넣겠다”고 답했음
    실제로 그게 맞는 판단이었지만, Patrick Collison이 직접 전화해서 “면접은 통과 못 했지만, 취지는 이해하냐”고 물었음
    결국 다시 면접을 보고 통과했음
    면접의 목적을 이해하는 게 중요함을 보여주는 일화였음
  • 친구와 이 주제로 토론한 적 있음
    어떤 대형 페리 회사가 Google Sheets로 선박 위치와 직원 배정을 관리하는데, 친구는 “이건 대기업이 할 일이 아니다”라고 했음
    하지만 나는 이미 검증된 도구로 문제를 해결한 게 훌륭하다고 생각함
    덕분에 사내 개발팀이나 비싼 외주 없이 운영 가능함
    내 자만심을 깊이 묻어두게 된 경험이었음
  • 이런 면접 질문이라면, 먼저 “왜 이게 문제인가요?”라고 되묻는 게 좋다고 생각함
    상대가 구체적으로 어떤 점이 안 맞는지 설명하게 한 뒤, 그제야 기술적 설계를 시작해야 함
  • 올바른 답은 “왜 Google Sheets를 안 쓰고 이메일로 주고받고 있나요?”라고 묻는 것임
    Sheets를 못 쓰는 이유는 다양함 — 기능 제약, 중국 내 접근 제한, 회사 정책, 네트워크 문제 등
    고객이 이미 이런 이유로 커스텀 솔루션을 원할 수도 있음
    즉, 단순히 “Google Sheets 쓰세요”가 아니라 고객의 맥락을 이해하는 것이 개발자의 역할임

• AI 코딩 도구가 문제를 더 미묘하게 악화시키고 있음
  이제는 복잡한 아키텍처를 5분 만에 생성할 수 있지만, 유지보수 비용은 그대로임
  결과적으로 더 화려한 구조가 빠르게 만들어지고, 승진용 문서도 금세 완성됨
  하지만 실제로는 아무도 그 코드를 완전히 이해하지 못함
  진짜 단순함의 기준은 “다음 사람이 질문 없이 이해할 수 있는가”인데, AI 생성 코드는 그 시험을 완전히 통과하지 못함

  • 사실 LLM 이전에도 새벽 3시에 호출된 온콜 담당자들이 시스템을 잘 모르는 경우가 많았음
    이제는 그게 더 심해질 뿐임
    그래서 나는 조직의 코드 이해 문화가 얼마나 강한지를 커리어 선택의 기준으로 삼고 있음
    아무도 시스템을 모르는 상황은 다시 겪고 싶지 않음
  • 이런 이유로 앞으로는 소프트웨어 제품 자체의 가치가 줄어들 것 같음
    문제 해결이 목표라면, AI로 만든 도구든 구매한 도구든 결국 문제를 해결해야 함
    하지만 기성 제품이 맞지 않으면 결국 직접 생성한 커스텀 솔루션이 늘어날 것임
    다만 그걸 아무도 이해하지 못하면, 다음 사람이 또 새로 만들겠지
    그래도 사용자와 제작자가 가까워지는 점에서는 개선일 수도 있음
  • AI 도구를 쓸 때 유지보수성 원칙을 문서화하는 게 중요함
    예를 들어 AGENTS.md에 “KISS”, “YAGNI” 같은 지침을 명시해두면 도움이 됨
  • 나도 AI로 코딩하면서 단순함을 유지하려고 노력함
    문제는 “다음 사람”이 결국 6개월 뒤의 나 자신이라는 점임
    AI도 context window 한계로 같은 문제를 겪음
  • AI가 만들어낸 코드의 운영 비용도 무시 못함
    많은 개발자가 인기 스택만 좇고, 운영 용이성은 고려하지 않음
    AI도 “이건 과한 설계야”라고 말해주지 않음
    Kubernetes와 ElasticSearch를 원하면, 그대로 만들어줄 뿐임

• FAANG과 스타트업을 모두 경험한 입장에서, 복잡성과 단순성의 균형이 핵심임
  대기업에서는 임시방편식 해킹이 수천 명의 생산성을 해칠 수 있고,
  스타트업에서는 과도한 인프라가 회사를 망칠 수 있음
  진짜 숙련된 엔지니어는 두 상황을 구분하고, 경험으로 적절한 트레이드오프를 선택할 줄 아는 사람임

  • 팀 규모가 5명일 때와 500명일 때의 결함 발생률은 완전히 다름
  • 자기 관리형 프로젝트 매니징 능력은 정말 배우기 어려운 기술임

• Amazon(2005~2008) 근무 시절, 회사 문화의 상징이었던 두 가지 상이 있었음
  “Just Do It” 상은 자발적 문제 해결, “Door Desk” 상은 절약과 단순함을 상징했음
  실제로 쓸모없는 TV를 치운 직원이 상을 받았는데, 보상으로 그 TV를 줬던 일화가 있음

  • 하지만 그 문짝 책상은 사실 Ikea보다 비싸고 조립도 어려웠음
    은유로서의 단순함이 현실에서는 좀 모호했음
  • 지금도 “Just Do It” 상은 여전히 수여되고 있음

• 단순함을 주장하려면 비즈니스 언어로 표현해야 함
  “사건 80% 감소”, “비용 40% 절감”, “성능 33% 향상” 같은 식으로
  단순함 자체는 평가받지 못하지만, 그 결과는 높이 평가받음

  • 하지만 “복잡한 걸 만들지 않은 덕분”의 효과는 측정하기 어려움
  • 처음부터 빠른 시스템을 설계해도, 느린 걸 만든 뒤 80% 개선한 사람보다 덜 인정받음
  • 단순함은 P&L에 보이지 않기 때문에 승진으로 이어지기 어려움
    나는 리팩터링을 비용 모델로 전환해 KPI를 계측하고, MTTR을 60% 줄였음
    이런 수치를 직접 보여줘야 인정받음
  • 대부분의 경영진은 “더 빨리”를 선택함, “더 단순하게”는 거의 선택하지 않음

• 관리자로서 나는 단순한 코드를 선호했음
  하지만 팀이 숙련된 인원으로 구성되어 있었기 때문임
  경험이 적은 팀에서는 The Parable of The Toaster 같은 일이 벌어짐

• 나이가 들수록 복잡성에 저항하게 됨
  하지만 리더십은 종종 “이해 못 해서 반대한다”고 오해함
  가장 오래 살아남은 프로젝트는 단순하고 교체가 쉬운 것들이었음
  AI 도구는 이런 접근을 더 쉽게 만들어줌 — 독립된 샘플 프로젝트로 컴포넌트를 실험하고, 검증된 코드를 본 프로젝트에 통합함
  내부망 환경이라 AI를 직접 연결하진 않지만, 이 방식은 매우 유용함

  • 리더십은 종종 단순한 접근을 게으름으로 오해함
    그래서 나는 “복잡한 것도 만들 수 있지만, 먼저 간단한 버전으로 시작하자”고 제안함
    대부분 그 단순한 버전이 결국 수년간 운영되는 프로덕션 코드가 됨
  • 이런 교훈은 결국 직접 고생해봐야 배움

• 단순한 솔루션을 빠르게 내놓은 개발자는 남은 시간에 여러 기능을 더 구현할 수 있음
  반면 복잡한 솔루션에 매달린 사람은 한 기능에 몇 주를 쏟음
  결국 생산성 지표에서는 단순한 접근이 더 매력적으로 보임
  나 역시 “큰 아이디어”보다 꾸준히 결과를 내는 사람으로 커리어를 쌓아왔음

  • 하지만 너무 단순하면 “작은 기능만 한 사람”처럼 보일 위험도 있음
  • 또 어떤 사람은 “남성 중심적 표현”을 문제 삼았지만, 핵심은 결과 중심의 문화였음

• 우리 회사 면접 중 하나는 공공 도서관 시스템 설계 문제임
  처음엔 작은 마을 도서관 규모로 시작해, 전국 단위로 확장하는 시나리오임
  최고의 답변은 “최대 규모여도 중간급 서버와 Postgres면 충분하다”였음

  • 하지만 어떤 면접관은 “초당 10,000 요청” 같은 비현실적 스케일을 요구함
    현실적으로는 10이나 10,000이나 큰 차이 없는데, 경험 없는 면접관이 프롬프트만 읽는 경우가 많음
  • “모든 회사가 Spotify급 시스템을 설계하진 않는다”는 걸 잊지 말아야 함
  • 초기 웹은 서버실 한 구석의 장비로도 수백 요청을 처리했음
    이후 과도한 인프라와 이력서 중심 개발이 문제를 키웠음

• AI는 결국 사용자의 역량을 증폭시키는 도구라고 생각함
  숙련된 개발자에게는 생산성을 높여주지만, 미숙한 사람에게는 혼란을 빠르게 확산시키는 도구가 됨

  • 나는 단순함을 선호하는 엔지니어인데, AI가 코드를 더 단순하게 만들지는 못했음
    오히려 불필요한 래퍼 함수와 타입 변환을 추가하는 경향이 있음
    AI는 “코드를 더 추가하는 쪽”에 가깝다고 느낌
  • 하지만 경험이 부족해도 비판적으로 학습하려는 태도로 AI를 사용하면, PR 전에 스스로 코드를 개선하는 데 도움이 될 수 있음
  • 나도 ChatGPT Codex로 시작하기 어려웠던 작업을 착수하게 된 경험이 있음
    다만 깊이 없는 “vibe coding”이 늘어나는 건 우려스러움