# 지루한 기술을 선택하라, Revisited (2025)

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30036](https://news.hada.io/topic?id=30036)
- GeekNews Markdown: [https://news.hada.io/topic/30036.md](https://news.hada.io/topic/30036.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-31T11:15:01+09:00
- Updated: 2026-05-31T11:15:01+09:00
- Original source: [brethorsting.com](https://www.brethorsting.com/blog/2025/07/choose-boring-technology%2C-revisited)
- Points: 8
- Comments: 0

## Summary

2015년의 조언을 AI 코딩 도구 시대에 다시 읽어낸 글입니다. AI는 모르는 기술 스택에서도 그럴듯한 코드를 만들어주지만, 사용자가 검증할 수 없는 영역이 늘어날수록 위험은 더 커집니다. 이미 잘 아는 기술에서는 AI가 **역량 증폭기**가 되지만, 모르는 기술에서는 의존성을 키우는 장치가 될 수 있다는 점에서 이번 주 주제와 가장 잘 맞습니다.

## Topic Body

- 검증 가능한 기술 스택에 집중하는 **"Choose Boring Technology"** 원칙은 AI 코딩 도구 시대에 더욱 중요해짐  
- 기업은 한정된 **"innovation tokens"** 를 신뢰성이 입증된 기술에 전략적으로 사용해야 함  
- 모던 AI 코딩 도구는 거의 모든 기술 스택에 대해 **그럴듯해 보이는 코드**를 생성하지만, 사용자가 모르는 기술이 둘 이상 결합되면 오류 검증이 불가능함  
- 이미 잘 아는 기술 스택에서는 AI 코딩 도구가 **force multiplier(역량 증폭 도구)** 로 작동하지만, 모르는 기술에서는 단순 의존 수단으로 전락함  
- AI가 생성한 코드의 품질이 높아질수록 문제를 발견하기 어려워지므로, 기술에 대한 **깊은 이해**의 가치가 더 커짐  
  
---  
  
### Choose Boring Technology 원칙의 재확인  
  
- 10년 전 Dan McKinley의 글 "Choose Boring Technology"에 공감했던 견해가 10년이 지나도 변하지 않음  
  - 새 프로젝트를 시작할 때 "새로운 것을 배우기 위한 핑계인가, 문제를 해결하려는 것인가"를 먼저 따짐  
  - 새로운 것을 배운다면 미지의 요소를 **하나로 제한**, 문제를 해결한다면 이미 아는 기술을 고수  
- LLM과 agentic AI 코딩 도구의 등장으로 이 원칙이 한층 더 critical 해짐  
  
### McKinley의 핵심 주장  
  
- 기업은 한정된 **"innovation tokens"** 를 보유하며, 검증되지 않은 흥미로운 기술이 아니라 확립되고 잘 이해된 기술에 전략적으로 사용해야 함  
- 지루한 기술은 알려진 **실패 모드(failure modes)**, 잘 이해된 기능, 입증된 운영 신뢰성을 가짐  
  - 새벽 3시에 장애가 났을 때, 미지의 영역을 개척하기보다 Stack Overflow 답변이 존재하는 기술을 디버깅하는 편이 나음  
- 이 원칙은 2015년에도 참이었고 오늘날에도 참임  
  
### AI 코딩 도구라는 새로운 변수  
  
- 모던 AI 코딩 도구는 상상할 수 있는 거의 모든 기술 스택에 대해 전문적으로 보이는 코드를 생성  
  - Claude나 Copilot에 Kubernetes 기반 microservices, GraphQL federation, 최신 JavaScript 프레임워크 구현을 요청하면 규칙을 따르고 실행도 되는 코드를 반환  
- 본인이 모르는 기술 두 개 이상을 사용할 경우, AI가 잘못된 결과를 내놓고 있는지 검증할 방법이 전무함  
  - LLM은 인상적인 능력에도 불구하고 기술적 세부사항에서 **hallucinate(환각)** 를 일으킴  
- 엔지니어들이 AI가 생성한 문제 코드를 그대로 수용하는 사례를 목격함  
  - deprecated API 사용, 보안 안티패턴 구현, 프로덕션 부하에서야 드러나는 미묘한 성능 문제  
  - 코드는 올바르게 보였고, 네이밍 규칙을 따랐으며, 적절한 에러 처리도 있었으나, 해당 기술에 익숙한 사람만 잡아낼 수 있는 방식으로 틀려 있었음  
  
### 미지의 기술 + AI 코드 = 불확실성의 곱셈  
  
- 익숙하지 않은 기술과 AI 생성 코드를 결합하면 미지수를 더하는 것이 아니라 **곱하는** 결과를 낳음  
  - 프레임워크 선택이 적절한지 알 수 없음  
  - AI 구현이 best practice를 따르는지 알 수 없음  
  - 생성된 코드 중 어디가 boilerplate이고 어디가 핵심 비즈니스 로직인지 알 수 없음  
  - 어떤 실패 모드를 주시해야 하는지 알 수 없음  
- 이는 단순한 cargo-culting을 넘어 **"cargo-culting times 2,356"** 수준의 문제임  
  
### 지루한 기술과 AI가 시너지를 내는 지점  
  
- 기반 스택을 이해하고 있을 때 AI 코딩 도구는 매우 강력해짐  
  - Rails를 충분히 알기에 Claude가 의심스러운 제안을 할 때 포착 가능 (context7의 도움 활용)  
  - JavaScript의 특성을 이해하기에 Copilot의 제안을 fact-check 가능  
- AI는 이미 이해하고 있는 기술에서는 force multiplier가 되고, 모르는 기술에서는 의존용 목발(crutch)로 전락함  
  
### AI 시대의 실용 가이드라인  
  
- 새 기술 평가 시 "AI가 이 기술의 구현 코드를 생성했을 때, 내가 적절히 리뷰할 수 있는가?"를 먼저 자문할 것  
  - 답이 "아니오"라면 mission-critical한 곳에 그 기술을 쓰지 말아야 함  
- 새로운 것을 배우기로 했다면(innovation token은 하나뿐), AI 제안을 fact-check할 수 있을 만큼 깊이 이해하는 데 실제 시간을 들일 것  
  - 복사-붙여넣기 후 잘 되기만 바라지 말 것  
- AI 도구를 핑계로 여러 새 기술을 동시에 떠안는 유혹에 저항할 것  
  - AI는 새 언어·새 프레임워크·새 인프라를 한꺼번에 다룰 수 있을 것처럼 느끼게 하지만, 어느 것도 제대로 검증할 수 없음  
  
### AI 시대에 높아진 위험과 결론  
  
- 원래의 "choose boring technology" 주장은 운영 복잡성과 인지 부하를 줄이는 것이었고, 이 우려는 여전히 유효함  
- AI 시대에는 추가 위험이 존재함: 어떤 스택이든 전문적으로 보이는 코드를 생성하는 AI가 주는 **false confidence(거짓 자신감)**  
- AI 생성 코드의 품질 때문에 문제 발견 난도가 오히려 높아짐  
  - 과거에는 나쁜 코드가 나빠 보였으나, 이제는 도메인을 충분히 이해해야만 미묘한 문제를 알아챌 수 있음  
- 문제를 해결할 때는 이미 아는 것을 사용하고, 새로운 것을 배울 때는 배우는 데 집중하며, AI 생성 코드를 이해와 혼동하지 말 것  
- 스택에서 가장 지루한 기술은, AI가 틀렸을 때를 알아챌 만큼 잘 이해하고 있는 그 기술일 수 있음  
  - 한 번도 써본 적 없는 기술로 AI가 수천 줄의 코드를 자신 있게 생성하는 세상에서, 그 이해의 가치는 그 어느 때보다 큼

## Comments



_No public comments on this page._