과도한 설계가 더 그럴듯한 서사를 만들어 승진과 평가에서 보상받고, 가장 단순하게 작동하는 해법은 보이지 않게 되는 구조적 인센티브 문제를 다룬다.
* [About](https://terriblesoftware.org/about/)
단순함으로는 승진하지 못한다“단순함은 훌륭한 미덕이지만, 그것을 이루려면 어려운 노력이 필요하고 그것을 알아보려면 교육이 필요하다. 그리고 더 나쁜 점은, 복잡함이 더 잘 팔린다는 것이다.” — Edsger Dijkstra
조용히 많은 엔지니어링 팀을 망가뜨리는 무언가가 있다고 생각한다. 면접에서, 승진 패킷에서, 설계 리뷰에서: 과하게 만들어내는 엔지니어는 설득력 있는 서사를 얻지만, “작동하는 가장 단순한 것”을 출시한 엔지니어는… 아무것도 얻지 못한다.
물론 의도적인 건 아니다. 아무도 앉아서 “과설계하는 사람들을 반드시 승진시키자!” 라고 말하지 않는다. 하지만 회사가 일을 잘못 평가하는 방식 때문에 그런 일이 실제로 벌어질 수 있다(그리고 실제로 수없이 반복되어 왔다).
같은 팀의 두 엔지니어를 떠올려보자. 엔지니어 A는 어떤 기능을 맡는다. 그녀는 문제를 보고 몇 가지 선택지를 검토한 뒤 가장 단순한 것을 고른다. 직관적인 구현, 아마 코드 50줄 정도. 읽기 쉽고, 테스트하기 쉽고, 다음 사람이 이어받기 쉽다. 동작한다. 그녀는 며칠 안에 배포하고 다음 일로 넘어간다.
엔지니어 B도 비슷한 기능을 맡는다. 그는 문제를 보면서 더 “견고한” 무언가를 만들 기회가 있다고 본다. 새 추상화 레이어를 도입하고, 컴포넌트 간 통신을 위한 pub/sub 시스템을 만들고, 향후 사용 사례에 “확장 가능”하도록 구성 프레임워크까지 추가한다. 3주가 걸린다. PR이 여러 개 나온다. 이 모든 걸 설명하는 문서를 공유할 때 팀 채널엔 들뜬 이모지가 잔뜩 올라온다.
이제 승진 시즌이 온다. 엔지니어 B의 작업은 승진 패킷에 거의 자동으로 써진다: “확장 가능한 이벤트 기반 아키텍처를 설계 및 구현하고, 여러 팀이 채택한 재사용 가능한 추상화 레이어를 도입했으며, 향후 확장성을 가능하게 하는 구성 프레임워크를 구축함.” 이건 거의 Staff+라고 외치는 수준이다.
하지만 엔지니어 A의 작업은 쓸 말이 거의 없다. “기능 X 구현.” 세 단어. 그녀의 일이 더 나았다. 하지만 너무 단순해 보이게 만들어서 보이지 않는다. _만들지 않은 것_에 대한 설득력 있는 서사는 쓰기 어렵다. 피한 복잡성으로 승진하는 사람은 없다.
복잡성은 똑똑해 보인다. 실제로 똑똑해서가 아니라, 우리 시스템이 그렇게 보상하도록 설계되어 있기 때문이다. 그리고 이 인센티브 문제는 승진 시즌에서 시작되지 않는다. 취업하기 전부터 시작된다.
면접을 생각해보자. 시스템 설계 라운드에서 단순한 해결책을 제안한다. 단일 데이터베이스, 단순한 API, 어쩌면 캐시 레이어 하나. 그러면 면접관이 말한다: “확장성은요? 사용자가 천만 명이면 어떻게 하죠?” 그래서 서비스를 추가한다. 큐를 추가한다. 샤딩을 추가한다. 화이트보드에 박스를 더 그린다. 그제야 면접관이 만족한 듯 보인다.
여기서 배우는 건 “복잡성은 사람을 감탄하게 만든다”는 것이다. 단순한 답이 틀린 게 아니다. 그저 충분히 흥미롭지 않았을 뿐이다. 그리고 당신은 그 교훈을 커리어 내내 들고 갈지도 모른다. 공정하게 말하자면, 면접관이 규모를 압박하는 데는 종종 타당한 이유가 있다. 압박 속에서 어떻게 사고하는지, 분산 시스템을 이해하는지 보고 싶기 때문이다. 하지만 지원자가 가져가는 결론이 “단순함으로는 부족했다”라면, 뭔가 어긋나 있다.
설계 리뷰에서도 똑같이 나타난다. 어떤 엔지니어가 깔끔하고 단순한 접근을 제안하면 “이거 미래 대비 안 해도 되나요?” 라는 질문을 맞는다. 그래서 아직 필요하지 않은 레이어를 추가하고, 어쩌면 영원히 나타나지 않을 문제를 위한 추상화를 넣고, 아무도 요구하지 않은 요구사항을 위한 유연성을 끼워 넣는다. 문제가 요구해서가 아니라, 방 안의 기대가 그랬기 때문이다.
나는 엔지니어들이 (그리고 나 자신도) 몇 줄의 코드 중복을 피하려고 추상화를 만들었다가, 중복 그 자체보다 이해·유지보수하기 훨씬 어려운 무언가로 끝나는 것을 봐 왔다. 매번 그때는 올바른 선택처럼 느껴졌다. 코드는 더 “프로” 같아 보였다. 더 엔지니어링된 느낌이었다. 하지만 사용자는 기능을 더 빨리 받지 못했고, 다음에 이 코드를 만지는 엔지니어는 변경하기 전에 그 추상화를 이해하느라 반나절을 써야 했다.
이제 분명히 해두자: 복잡성이 때로는 올바른 선택이기도 하다. 수백만 건의 트랜잭션을 처리한다면 분산 시스템이 필요할 수 있다. 10개 팀이 같은 제품에서 일한다면 서비스 경계가 필요할 가능성이 크다. 문제가 복잡하다면 해법도(아마) 복잡해야 한다!
문제는 복잡성 자체가 아니다. “얻지 않은” 복잡성이다. “DB 한계에 부딪혀서 샤딩이 필요하다” 와 “3년 뒤에 DB 한계에 부딪힐지도 모르니 지금 샤딩하자” 는 다르다.
어떤 엔지니어들은 이를 이해한다. 그리고 그들의 코드(와 아키텍처)를 보면 “음, 그렇지. 당연하지.” 라고 생각하게 된다. 마법도 없고, 재치도 없고, 이해 못 한다고 해서 내가 바보가 된 느낌도 없다. 그게 정확히 핵심이다.
시니어로 가는 실제 경로는 더 많은 도구와 패턴을 배우는 게 아니라, 언제 그것들을 쓰지 말아야 하는지를 배우는 것이다. 복잡성은 누구나 더할 수 있다. 빼는 데는 경험과 자신감이 필요하다.
그럼 실제로 우리는 무엇을 해야 할까? “단순하게 유지하자”라고 말하는 건 쉽다. 인센티브 구조를 바꾸는 건 더 어렵다.
당신이 엔지니어라면, 단순함은 ‘보이게’ 만들어야 한다는 걸 배워라. 작업은 스스로 말하지 않는다. 좋지 않아서가 아니라, 대부분의 시스템이 그것을 듣도록 설계되어 있지 않기 때문이다.
우선 자기 일을 말하는 방식부터 시작하자. “기능 X 구현”은 큰 의미가 없다. 하지만 “이벤트 기반 아키텍처와 커스텀 추상화 레이어를 포함해 세 가지 접근을 평가했고, 직관적인 구현이 현재 및 예상 요구사항을 모두 충족한다고 판단했으며, 2일 만에 배포했고 6개월 동안 사고가 0건이었다” 라면, 같은 단순한 일을 ‘그 안의 판단’이 드러나게 설명한 것이다. 무언가를 만들지 않기로 한 결정도 결정이며, 중요한 결정이다! 그에 맞게 문서화하라.
설계 리뷰에서 누군가 “미래 대비해야 하는 거 아닌가요?”라고 묻는다면, 그냥 굴복해서 레이어를 추가하지 말라. 대신 이렇게 말해보자: “나중에 필요해지면 추가하려면 무엇이 필요한지, 지금 추가하면 어떤 비용이 드는지 여기에 정리했습니다. 저는 일단 기다리자는 쪽입니다.” 반발하는 게 아니라, 숙제를 했다는 걸 보여주는 것이다. 복잡성을 고려했고, 감당하지 않기로 선택했다는 뜻이다.
그리고 그렇다, 매니저에게도 이 이야기를 꺼내라. 예를 들어: “제가 문서화하는 방식이 제가 내리는 결정들을 반영하게 하고 싶습니다. 단지 제가 작성한 코드만이 아니라요. 다음 리뷰에서 그걸 어떻게 프레이밍하면 좋을지 이야기할 수 있을까요?” 대부분의 매니저는 당신이 그들의 일을 더 쉽게 해주기 때문에 이를 고마워할 것이다. 당신을 옹호하는 데 쓸 수 있는 언어를 제공하는 셈이다.
이 모든 걸 했는데도 팀이 여전히 가장 화려한 시스템을 만든 사람만 승진시킨다면… 그것도 유용한 정보다. 당신이 일하는 곳이 어떤지 알려준다. 어떤 문화는 진심으로 단순함을 가치 있게 여긴다. 다른 문화는 그렇다고 말하지만 정반대를 보상한다. 당신이 두 번째에 있다면, 게임을 하거나 판단력이 실제로 인정받는 곳을 찾으면 된다. 적어도 당신이 어느 쪽에 있는지는 알게 된다.
당신이 엔지니어링 리더라면, 이건 누구보다 당신 책임이다. 당신은 의식하든 못 하든 인센티브를 만든다. 그리고 문제는 대부분의 승진 기준이 의도와 상관없이 복잡성을 보상하도록 설계되어 있다는 점이다. “임팩트”는 누군가가 만든 것의 규모와 범위로 측정되곤 하고, 그건 대개 중요하다! 하지만 그들이 피한 것 역시 중요해야 한다.
그러니 먼저 질문을 바꿔라. 설계 리뷰에서 “확장성은 고려했나요?” 대신 “우리가 출시할 수 있는 가장 단순한 버전은 무엇이고, 언제 더 복잡한 것이 필요하다는 걸 알려줄 구체적인 신호는 무엇인가요?” 를 물어보라. 이 한 질문은 판을 바꾼다. 단순함을 기본값으로 만들고, 복잡성에 입증 책임을 지운다. 반대가 아니라!
승진 논의에서는 누군가의 패킷이 “그럴듯하게 들리는 시스템 목록”일 때 반문하라. “그게 다 필요했나요? 여기서 pub/sub 시스템이 정말 필요했나요, 아니면 문서상으로 좋아 보였던 건가요?” 그리고 팀의 엔지니어가 깔끔하고 단순한 무언가를 배포했을 때, 그들이 서사를 쓰도록 도와줘라. “여러 접근을 평가하고 문제를 해결하는 가장 단순한 것을 선택했다”는 충분히 설득력 있는 승진 사례다. 다만 당신이 실제로 그것을 그렇게 취급할 때만.
마지막으로 하나 더: 공개적으로 무엇을 축하하는지에 주목하라. 팀 채널에서의 모든 칭찬이 크고 복잡한 프로젝트에만 쏟아진다면, 사람들이 최적화할 대상은 그게 된다. 코드를 삭제한 엔지니어를 인정하기 시작하라. “우린 아직 이거 필요 없어”라고 말했고 실제로 맞았던 사람을.
결국 복잡성은 보상하고 단순함은 무시한다면, 우리가 정확히 그것을 얻게 되는 건 놀랄 일이 아니다. 하지만 해결책은 복잡하지 않다. 뭐, 그게 요점이기도 하겠지.
로드 중…
career, culture, engineering, leadership, teams
구독하면 최신 글이 이메일로 전송됩니다.
이메일을 입력하세요…
구독
날짜 2025년 6월 24일
날짜 2025년 11월 25일
날짜 2025년 3월 12일다른 구독자 663명과 함께하세요
가입하기
Terrible Software* 이미 WordPress.com 계정이 있나요? [지금 로그인하세요.](https://wordpress.com/log-in?redirect_to=https%3A%2F%2Fr-login.wordpress.com%2Fremote-login.php%3Faction%3Dlink%26back%3Dhttps%253A%252F%252Fterriblesoftware.org%252F2026%252F03%252F03%252Fnobody-gets-promoted-for-simplicity%252F)
*
* [ Terrible Software](https://terriblesoftware.org/)
* [구독](https://terriblesoftware.org/2026/03/03/nobody-gets-promoted-for-simplicity/)[구독 중](https://terriblesoftware.org/2026/03/03/nobody-gets-promoted-for-simplicity/)
* [가입하기](https://wordpress.com/start/)
* [로그인](https://wordpress.com/log-in?redirect_to=https%3A%2F%2Fr-login.wordpress.com%2Fremote-login.php%3Faction%3Dlink%26back%3Dhttps%253A%252F%252Fterriblesoftware.org%252F2026%252F03%252F03%252Fnobody-gets-promoted-for-simplicity%252F)
* [짧은 링크 복사](https://wp.me/pgdiWF-8r)
* [이 콘텐츠 신고](https://wordpress.com/abuse/?report_url=https://terriblesoftware.org/2026/03/03/nobody-gets-promoted-for-simplicity/)
* [Reader에서 글 보기](https://wordpress.com/reader/blogs/239592469/posts/523)
* [구독 관리](https://subscribe.wordpress.com/)
* [이 바 접기](https://terriblesoftware.org/2026/03/03/nobody-gets-promoted-for-simplicity/)
%d