# 지루한 기술을 선택하라 (2015)

> Clean Markdown view of GeekNews topic #30035. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30035](https://news.hada.io/topic?id=30035)
- GeekNews Markdown: [https://news.hada.io/topic/30035.md](https://news.hada.io/topic/30035.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-31T11:06:02+09:00
- Updated: 2026-05-31T11:06:02+09:00
- Original source: [mcfunley.com](https://mcfunley.com/choose-boring-technology)
- Points: 4
- Comments: 0

## Summary

위클리 메인 마지막에 소개드린 고전입니다. **혁신 토큰**이라는 비유는 여전히 강력한데, 새로운 기술을 고를 때마다 팀의 학습·운영·장애 대응 비용을 함께 쓰고 있다는 사실을 직관적으로 보여줍니다. 기술 선택을 "무엇이 더 멋진가"가 아니라 **실패 양상을 얼마나 알고 있는가**로 바꿔 보게 만드는 글입니다.

## Topic Body

- 새로운 기술을 절제하고 **검증된 기술(boring technology)** 을 우선 채택하는 것이 회사의 장기 성공에 유리함  
- 모든 회사는 약 **3개의 혁신 토큰(innovation tokens)** 만 보유하며, NodeJS·MongoDB·신생 도구를 고를 때마다 한 개씩 소모  
- 검증된 기술은 **기능과 실패 양상(failure modes)** 이 잘 알려져 있어, 신생 기술 특유의 **미지의 미지(unknown unknowns)** 위험이 작음  
- 기술 선택은 팀·조직 전체에 영향을 주며, 운영 부담과 인지 부하 탓에 "직무에 맞는 최선의 도구"보다 **여러 문제에 두루 무난한 도구**가 유리  
- 신중한 기술 선택이 엔지니어에게 **더 큰 문제에 집중할 자유**를 주며, 기술 자체를 위한 기술은 무의미함  
  
---  
  
### 지루함을 받아들이기 (Embrace Boredom)  
- 모든 회사는 약 **3개의 혁신 토큰(innovation tokens)** 을 가지며 공급은 한동안 고정 — 안정성과 성숙도를 확보하면 일부 추가될 수 있으나 보유량을 과대평가하는 경향  
- NodeJS로 웹사이트 작성, **MongoDB** 사용, 출시 1년 이하의 서비스 디스커버리 기술 채택은 각각 혁신 토큰 1개를 소모하며, 자체 데이터베이스 작성은 큰 곤경  
  - 이런 선택은 javascript 컨설팅 업체나 데이터베이스 회사라면 합당할 수 있으나, 대부분은 global commerce 재정의나 web 결제 재발명 같은 큰 사명을 추구하는 회사 — ssh 같은 영역 혁신에 한정된 주의력을 쏟는 것은 실패 또는 성공 지연의 지름길  
- **"지루함(boring)"은 "나쁨(bad)"과 동일하지 않으며**, 지루하면서 나쁜 기술도 존재 — 지루하면서 충분히 좋은 예로 **MySQL, Postgres, PHP, Python, Memcached, Squid, Cron**  
- 지루한 기술의 장점은 **기능(capabilities)** 뿐 아니라 **실패 양상(failure modes)** 까지 잘 이해되어 있다는 점  
- 기술 선택에는 **known unknowns**(예: 데이터베이스가 CPU 100%에 도달했을 때의 동작 미상)와 **unknown unknowns**(예: 통계 기록이 GC 일시정지를 유발할 줄 몰랐던 경우)가 공존하며, 신생 기술일수록 unknown unknowns의 규모가 훨씬 큼  
  
### 전역적으로 최적화하기 (Optimize Globally)  
- 지루한 기술 선호는 좋은 편향이나 유일한 고려 요소는 아니며, 기술 선택은 팀·조직·전체 시스템에 미치는 **범위(scope)** 를 가짐  
- 기술 추가에는 비용이 따름 — 이미 Ruby를 쓰는데 Python을 더하면 복잡성이 한계 효용을 능가하나, Python vs Scala, MySQL vs Redis 논의에서는 제약을 버리고 **"직무에 맞는 최선의 도구(best tool for the job)"** 를 외치는 경향  
- 업무의 본질은 **비즈니스 문제를 소프트웨어 선택의 해법 공간에 매핑**하는 것이며, 선택에 부담이 없다면 문제마다 국소 최적 도구를 고를 수 있으나 현실에는 부담이 존재  
  - 그 부담은 **운영(operations)** 과 그보다 작은 정도의 **인지 부하(cognitive overhead)** — 모니터링, 단위 테스트, 수정에 필요한 지식, init 스크립트 등이 빠르게 누적  
- "직무에 맞는 최선의 도구" 사고의 문제는 "최선"과 "직무"를 근시안적으로 봄 — 진짜 직무는 회사를 존속시키는 것이며, "최선"의 도구는 가능한 한 많은 문제에서 **가장 덜 나쁜(least worst)** 위치를 차지하는 도구  
- 시스템을 안정적으로 유지하는 **장기 비용**은 구축 중 겪는 불편을 압도하며, 성숙하고 생산적인 개발자는 이를 이해  
  
### 때로는 새로운 기술을 선택하기 (Choose New Technology, Sometimes)  
- 위 논리를 극단으로 밀면 Java만으로 웹사이트를 구현하게 되어 비현실적 — 도구함에 새 도구를 추가할 수단이 필요  
- 새 기술은 결국 전사적 영향을 주므로, 추가는 **전사적 가시성(company-wide visibility)** 을 요하는 결정 — "이것은 우리 모두가 함께 논의하는 사안"이라는 문화적 기대 설정이 필요  
- 가장 권할 만한 연습은 **새 기술을 추가하지 않고 당면 문제를 어떻게 풀지** 자문하는 것 — "문제"의 실체가 누군가 그 기술을 쓰고 싶을 뿐인 상황을 감지하게 하며, 그 경우 즉시 중단  
  - 적은 수의 기술 선택만으로도 멀리 갈 수 있으며, 실제 답은 "할 수 없다"가 아니라 대개 "할 수는 있지만 너무 어렵다" 정도 — 현재 자원으로 목표 달성이 불가하다고 느낀다면 충분히 창의적으로 사고하지 못한 것일 가능성  
- 현재 스택에서 그 문제 해결이 왜 과도하게 비싸고 어려운지 **명확히 기록**하는 것이 도움  
- 새 기술 선택이 **순수 추가형**(예: 캐싱이 없어 memcached 추가)일 수도, 기존 것과 겹치거나 대체할 수도 있음 — 대체형이라면 **기존 기능의 마이그레이션**에 대한 명확한 기대 설정이 필요하며, 정책은 보통 제안된 일정과 함께 "마이그레이션을 약속"하는 형태  
  - 의도는 잔해를 관리 가능한 수준으로 유지하고 국소 최적 해법의 난립을 방지  
- 이 절차는 부담스럽지 않으며, 과제로 채울 몇 가지 질문과 이를 논의하는 회의 한 번 — 새 기술이나 새 서비스가 이 관문을 무사히 통과하면 추가는 적절  
  
### 그냥 출시하기 (Just Ship)  
- **폴리글랏 프로그래밍(polyglot programming)** 은 개발자에게 완전한 도구 선택의 자유를 주면 문제 해결이 더 효과적이라는 약속으로 팔리나, 이는 잘해야 순진한 문제 정의이고 나쁘면 동기화된 추론 — 일상 운영의 **toil**이 개발자를 짓누름  
- 신중한 기술 선택이야말로 엔지니어에게 **더 큰 질문을 숙고할 자유**를 주며, 기술 자체를 위한 기술은 사기(snake oil)  
  
### Etsy 사례 (각주)  
- Etsy는 초기에 이 문제로 크게 고생함 — **Python** 프로그래머를 다수 채용한 뒤 할 일을 찾다가 무의미한 중간 계층을 만들었고, 이를 제거하는 데 수년 소요 / 동시에 90 퍼센타일 검색 지연은 약 2분 — Etsy가 실패하진 않았으나 수년간 아무것도 출시하지 못해 성공이 늦어짐  
- 지루하면서 나쁜 기술의 교집합을 흔히 **"enterprise software"** 라 부르지만 부정확할 수 있음  
- Etsy의 **activity feeds** 사례 - 대부분을 PHP, MySQL, Memcached, Gearman으로 통합하던 시기에 구현 / Redis 같은 도구보다 구현이 훨씬 복잡했으나 해당 스택으로도 충분히 구축 가능  
  - 이후 수년간 관심이 다른 곳으로 옮겨간 사이 activity feeds 사용량이 **20배** 증가했지만, **공유 플랫폼** 덕에 별도 변경 없이도 정상 동작 — 기술 선택에서 절제가 주는 장기적 이점  
  - 다만 절대주의는 아님 — memcached 기반 activity feeds는 실용적이라 판단했으나, 순수 PHP로 패싯 검색이 포함된 전문 검색을 구현하는 것은 아니어서 Etsy는 **Solr**를 사용

## Comments



_No public comments on this page._