단순함 때문에 승진하는 사람은 없다

Source: Hacker News

“단순함은 훌륭한 미덕이지만, 이를 달성하려면 노력과 교육이 필요합니다. 게다가 상황을 더 악화시키는 것은 복잡함이 더 잘 팔린다는 점입니다.” — Edsger Dijkstra

숨겨진 문제

많은 엔지니어링 팀을 조용히 망치고 있는 무언가가 있다고 생각합니다. 인터뷰, 승진 서류, 디자인 리뷰에서 과도하게 설계(over‑builds) 하는 엔지니어는 설득력 있는 이야기를 얻는 반면, 가장 간단하게 작동하는 것(simplest thing that works) 을 출시하는 엔지니어는 … 아무것도 얻지 못합니다.

물론 이것이 의도된 것은 아닙니다. 아무도 앉아서 “과도하게 설계하는 사람들을 승진시키자!” 라고 말하지 않죠. 하지만 기업이 작업을 잘못 평가할 때(그리고 실제로 여러 차례 일어난 일) 이런 일이 일어날 수 있습니다.

두 가지 대조적인 엔지니어

엔지니어 A

• 기능을 할당받음.
• 문제를 살펴보고 몇 가지 옵션을 고려한 뒤 가장 단순한 해결책을 선택함.
• 직관적인 구현을 작성함 (~50 줄).
• 읽기 쉽고, 테스트하기 쉬우며, 다음 사람이 이어받기에도 편함.
• 며칠 안에 배포하고 다음 작업으로 이동함.

엔지니어 B

• 비슷한 기능을 할당받음.
• “더 견고한” 무언가를 만들 기회를 포착함.
• 새로운 추상화 레이어와 컴포넌트 통신을 위한 pub/sub 시스템, 그리고 향후 확장을 위한 설정 프레임워크를 도입함.
• 3주가 걸리고 여러 PR이 포함되며, 설계 문서를 공유할 때마다 흥분된 이모지를 많이 남김.

승진 시기가 되면 엔지니어 B의 작업은 승진 패킷에 거의 자동으로 들어감:

“확장 가능한 이벤트‑드리븐 아키텍처를 설계·구현하고, 여러 팀이 채택한 재사용 가능한 추상화 레이어를 도입했으며, 향후 확장을 가능하게 하는 설정 프레임워크를 구축했다.”

이는 Staff+ 수준을 외치듯 보인다.

엔지니어 A에 대한 서술은 거의 존재하지 않는다:

“기능 X를 구현했다.”

세 단어. 그녀의 작업은 더 좋았지만, 단순하게 만든 덕분에 눈에 띄지 않는다. 피했던 복잡성 때문에 승진하는 사람은 없다.

Source:

복잡성이 보상받는 이유

복잡성은 똑똑해 보입니다—그렇다고 실제로 똑똑한 건 아니지만, 우리 시스템이 복잡성을 보상하도록 설계돼 있기 때문이죠. 인센티브 문제는 승진 시점에 시작되는 것이 아니라 직장을 얻기 전부터 시작됩니다.

면접

시스템 설계 라운드에서 당신은 간단한 해결책을 제시합니다: 단일 데이터베이스, 직관적인 API, 어쩌면 캐시 레이어 하나. 면접관이 묻습니다, “확장성은요? 사용자가 천만 명이라면 어떻게 할 건가요?” 당신은 서비스, 큐, 샤딩, 그리고 화이트보드에 더 많은 박스를 추가합니다. 면접관은 결국 만족한 듯 보입니다.

당신이 얻는 교훈은 복잡성이 사람들을 감탄하게 만든다는 것입니다. 간단한 답이 틀린 것은 아니었지만, 충분히 흥미롭지는 않았던 겁니다. (면접관이 규모에 대해 강조할 합당한 이유가 있을 때도 있지만, 후보자에게 “단순함만으로는 부족했다”는 인상이 남는다면 뭔가 잘못된 것입니다.)

설계 리뷰

엔지니어가 깔끔하고 단순한 접근 방식을 제안하면 “미래를 대비해야 하지 않을까요?” 라는 반응을 맞이합니다. 그들은 아직 필요하지 않은 레이어를 추가하고, 결코 실현되지 않을 문제에 대한 추상화와, 아무도 요구하지 않은 요구사항에 대한 유연성을 넣습니다. 문제 자체가 요구해서가 아니라, 방 안의 기대 때문에 그렇습니다.

나는 엔지니어들을 본 적이 있습니다 (그리고 나 자신도 그 중 하나였습니다) — 몇 줄의 코드를 중복하는 것을 피하려고 추상화를 만들었지만, 결국 중복보다 이해하고 유지보수하기 훨씬 어려운 코드를 만들게 되었습니다. 매번 그때는 옳은 선택처럼 느껴졌습니다. 코드는 더 “전문적”이고, 더 엔지니어링된 것처럼 보였습니다. 하지만 사용자들은 기능을 더 빨리 받지 못했고, 다음 엔지니어는 변경을 하기 전에 그 추상화를 이해하는 데 반나절을 써야 했습니다.

복잡성이 실제로 옳을 때

이제 명확히 말하자면: 복잡성은 때때로 올바른 선택이다.

• 수백만 건의 트랜잭션을 처리한다면, 분산 시스템이 필요할 수 있습니다.
• 동일한 제품에 대해 10개의 팀이 작업하고 있다면, 서비스 경계가 필요할 가능성이 높습니다.

문제가 복잡하면, 해결책도 (아마) 복잡해야 합니다.

문제는 복잡성 자체가 아니라 불필요한 복잡성입니다. 다음과 같은 차이가 있습니다:

• “데이터베이스 한도에 도달하고 있어 샤딩이 필요합니다.”
• “3년 안에 데이터베이스 한도에 도달할 수 있으니, 지금 바로 샤딩합시다.”

진정한 기술: 복잡성을 추가하지 않아야 할 때를 아는 것

몇몇 엔지니어는 이를 이해한다. 그들의 코드(및 아키텍처)를 보면 “음, 당연하지.” 라는 생각이 든다. 마법도, 영리함도 없으며, 이해하지 못했다고 바보가 된 느낌도 없다. 바로 그것이 핵심이다.

The actual path to seniority isn’t learning more tools and patterns; it’s learning when not to use them. Anyone can add complexity. It takes experience and confidence to leave it out.

우리가 할 수 있는 일은?

“단순하게 유지하라”고 말하는 것은 쉽습니다. 인센티브 구조를 바꾸는 것은 더 어렵습니다.

엔지니어를 위한 조언

1. 단순함을 눈에 보이게 하라. 작업 자체가 스스로 말해 주지는 않습니다. 이는 작업이 좋지 않아서가 아니라 대부분의 시스템이 그것을 들을 수 있도록 설계되지 않았기 때문입니다.

2. 자신의 작업을 전략적으로 이야기하라.

   • 대신에: “기능 X를 구현했습니다.”
   • 이렇게 말하라: “세 가지 접근 방식을 평가했으며—이벤트‑드리븐 아키텍처와 맞춤형 추상화 레이어를 포함—직관적인 구현이 현재와 예상 요구 사항을 모두 충족한다는 결론에 도달했고, 2일 만에 배포했으며 6개월 동안 사고가 전혀 없었습니다.”

   무언가를 구현하지 않기로 한 결정도 중요한 결정입니다! 그에 맞게 문서화하십시오.

디자인 리뷰에서

누군가 “미래를 대비해서 설계하지 않겠습니까?”라고 물으면, 자동으로 레이어를 추가하지 말고 간결한 근거를 제시하십시오:

“우리는 미래 대비 옵션을 평가했으며 현재 범위가 추가 추상화를 정당화하지 못한다는 결론에 도달했습니다. 지금 추가하면 측정 가능한 이점 없이 유지 보수 부담만 증가합니다.”

Source: …

마무리 생각

복잡성은 쉽게 보여줄 수 있지만, 단순함은 간과하기 쉽습니다. 단순한 솔루션 뒤에 있는 트레이드‑오프를 명시적으로 설명함으로써 “많을수록 좋다”는 서술을 “적당한 양이 더 좋다”는 서술로 바꿀 수 있습니다. 이는 결국 엔지니어가 가져다 주는 진정한 가치—필요 최소한의 복잡성으로 신뢰할 수 있고 유지 보수 가능한 소프트웨어를 제공하는 것—과 승진, 인터뷰, 평가를 일치시킵니다.

단순함을 옹호하고 인정받는 방법

1. 데이터를 기반으로 결정 프레이밍하기

“나중에 필요하면 추가할 때 어떤 비용이 들고, 지금 바로 추가하면 어떤 비용이 드는지 보여줄게. 나는 기다리는 게 좋겠어.”

• 당신은 반대하는 것이 아니라, 숙제를 해왔음을 보여주는 것입니다.
• 복잡성을 고려했고, 의도적으로 그것을 받아들이지 않기로 선택한 것입니다.

2. 매니저와 이야기하기

“내가 하는 일을 문서화할 때 내가 내린 결정이 반영되길 원해, 단순히 코드를 적는 것만이 아니라. 다음 평가 때 이를 어떻게 프레이밍할지 얘기할 수 있을까?”

• 대부분의 매니저는 당신이 그들의 일을 더 쉽게 만든다고 생각해 고마워할 것입니다.
• 당신은 매니저가 당신을 옹호할 때 사용할 수 있는 언어를 제공하는 것입니다.

3. 결과 해석하기

• 팀이 가장 정교한 시스템을 만든 사람을 여전히 승진시킨다면:

  • 이는 유용한 정보입니다.
  • 당신이 속한 문화에 대해 무언가를 알려줍니다.

• 두 가지 가능한 문화:

  1. 단순함을 중시 – 좋은 판단이 인정받는다.
  2. 단순함을 표방하지만 복잡함에 보상 – 게임에 참여하거나, 좋은 판단이 실제로 인정받는 곳을 찾아야 한다.

• 최소한 어느 문화에 있는지 알 수 있게 됩니다.

엔지니어링 리더라면

당신은 인센티브를 설정합니다. 스스로 인식하고 있든 없든 말이죠. 대부분의 승진 기준은—의도했든 아니든— 복잡성을 보상하도록 설계되어 있습니다. “영향력”은 종종 누군가가 만든 것의 규모와 범위로 측정되지만, 불필요한 복잡성을 피하는 것도 중요해야 합니다.

A. 질문을 바꾸세요

• 디자인 리뷰:

  • “스케일에 대해 생각해봤나요?” 대신에 이렇게 물어보세요:

    “우리가 배포할 수 있는 가장 간단한 버전은 무엇이며, 더 복잡한 것이 필요하다는 구체적인 신호는 무엇인가요?”

  이렇게 하면 단순함이 기본이 되고, 복잡성에 대한 입증 책임이 복잡한 쪽에 놓이게 됩니다.

B. 승진 논의에서 반론을 제기하세요

• 승진 패킷이 인상적인 시스템들의 목록이라면, 이렇게 물어보세요:

  “그 모든 것이 정말 필요했나요? 여기서 퍼브/섭(pub/sub) 시스템이 꼭 필요했나요, 아니면 문서상으로만 멋져 보였나요?”

• 엔지니어가 깔끔하고 단순한 무언가를 배포했을 때, 그 서술을 도와주세요:

  “여러 접근 방식을 평가한 뒤 문제를 해결할 수 있는 가장 단순한 방식을 선택했습니다.”

  이것이 바로 설득력 있는 승진 사례입니다—그렇게 다루면.

C. 단순함을 공개적으로 축하하세요

• 팀 채널에서 모든 칭찬이 크고 복잡한 프로젝트에만 쏟아진다면, 사람들은 그것을 최적화 목표로 삼게 됩니다.
• 다음과 같은 사례를 인정하기 시작하세요:
  • 죽은 코드를 삭제한 엔지니어.
  • “아직은 필요하지 않다”고 말하고 옳았던 사람.

Bottom Line

복잡성을 보상하고 단순함을 무시하는 것을 계속한다면, 우리가 정확히 그런 결과를 얻는 것에 놀라지 않아도 됩니다. 해결책은 복잡하지 않습니다—그게 바로 요점인 것 같아요.