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

6 hours ago 3

검증 가능한 기술 스택에 집중하는 "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 해짐

기업은 한정된 "innovation tokens" 를 보유하며, 검증되지 않은 흥미로운 기술이 아니라 확립되고 잘 이해된 기술에 전략적으로 사용해야 함
지루한 기술은 알려진 실패 모드(failure modes), 잘 이해된 기능, 입증된 운영 신뢰성을 가짐
- 새벽 3시에 장애가 났을 때, 미지의 영역을 개척하기보다 Stack Overflow 답변이 존재하는 기술을 디버깅하는 편이 나음
이 원칙은 2015년에도 참이었고 오늘날에도 참임

모던 AI 코딩 도구는 상상할 수 있는 거의 모든 기술 스택에 대해 전문적으로 보이는 코드를 생성
- Claude나 Copilot에 Kubernetes 기반 microservices, GraphQL federation, 최신 JavaScript 프레임워크 구현을 요청하면 규칙을 따르고 실행도 되는 코드를 반환
본인이 모르는 기술 두 개 이상을 사용할 경우, AI가 잘못된 결과를 내놓고 있는지 검증할 방법이 전무함
- LLM은 인상적인 능력에도 불구하고 기술적 세부사항에서 hallucinate(환각) 를 일으킴
엔지니어들이 AI가 생성한 문제 코드를 그대로 수용하는 사례를 목격함
- deprecated API 사용, 보안 안티패턴 구현, 프로덕션 부하에서야 드러나는 미묘한 성능 문제
- 코드는 올바르게 보였고, 네이밍 규칙을 따랐으며, 적절한 에러 처리도 있었으나, 해당 기술에 익숙한 사람만 잡아낼 수 있는 방식으로 틀려 있었음

익숙하지 않은 기술과 AI 생성 코드를 결합하면 미지수를 더하는 것이 아니라 곱하는 결과를 낳음
- 프레임워크 선택이 적절한지 알 수 없음
- AI 구현이 best practice를 따르는지 알 수 없음
- 생성된 코드 중 어디가 boilerplate이고 어디가 핵심 비즈니스 로직인지 알 수 없음
- 어떤 실패 모드를 주시해야 하는지 알 수 없음
이는 단순한 cargo-culting을 넘어 "cargo-culting times 2,356" 수준의 문제임

기반 스택을 이해하고 있을 때 AI 코딩 도구는 매우 강력해짐
- Rails를 충분히 알기에 Claude가 의심스러운 제안을 할 때 포착 가능 (context7의 도움 활용)
- JavaScript의 특성을 이해하기에 Copilot의 제안을 fact-check 가능
AI는 이미 이해하고 있는 기술에서는 force multiplier가 되고, 모르는 기술에서는 의존용 목발(crutch)로 전락함

새 기술 평가 시 "AI가 이 기술의 구현 코드를 생성했을 때, 내가 적절히 리뷰할 수 있는가?"를 먼저 자문할 것
- 답이 "아니오"라면 mission-critical한 곳에 그 기술을 쓰지 말아야 함
새로운 것을 배우기로 했다면(innovation token은 하나뿐), AI 제안을 fact-check할 수 있을 만큼 깊이 이해하는 데 실제 시간을 들일 것
- 복사-붙여넣기 후 잘 되기만 바라지 말 것
AI 도구를 핑계로 여러 새 기술을 동시에 떠안는 유혹에 저항할 것
- AI는 새 언어·새 프레임워크·새 인프라를 한꺼번에 다룰 수 있을 것처럼 느끼게 하지만, 어느 것도 제대로 검증할 수 없음

원래의 "choose boring technology" 주장은 운영 복잡성과 인지 부하를 줄이는 것이었고, 이 우려는 여전히 유효함
AI 시대에는 추가 위험이 존재함: 어떤 스택이든 전문적으로 보이는 코드를 생성하는 AI가 주는 false confidence(거짓 자신감)
AI 생성 코드의 품질 때문에 문제 발견 난도가 오히려 높아짐
- 과거에는 나쁜 코드가 나빠 보였으나, 이제는 도메인을 충분히 이해해야만 미묘한 문제를 알아챌 수 있음
문제를 해결할 때는 이미 아는 것을 사용하고, 새로운 것을 배울 때는 배우는 데 집중하며, AI 생성 코드를 이해와 혼동하지 말 것
스택에서 가장 지루한 기술은, AI가 틀렸을 때를 알아챌 만큼 잘 이해하고 있는 그 기술일 수 있음
- 한 번도 써본 적 없는 기술로 AI가 수천 줄의 코드를 자신 있게 생성하는 세상에서, 그 이해의 가치는 그 어느 때보다 큼