2015년 글이 2026년 HN 1면에 다시 오른 이유: '지루한 기술을 선택하라'

11년 된 슬라이드 한 편이 다시 개발자 커뮤니티 상단에 올라왔습니다. 댄 매킨리(Dan McKinley)가 2015년에 쓴 “Choose Boring Technology”, 우리말로 “지루한 기술을 선택하라"입니다. 새로 나온 글도 아니고 저자가 리메이크를 한 것도 아닌데 왜 지금일까요. 답은 아마 AI에 있습니다.

한 가지는 짚고 갑니다. 이번 재점화는 커뮤니티 데이터로 폭넓게 확인된 현상이라기보다, 요즘 개발자들 이야기에 자꾸 소환되는 쪽에 가깝습니다. 최근 30일 기준으로 잡히는 대규모 토론 데이터는 많지 않았습니다. 그래서 이 글은 “얼마나 많은 사람이 떠들었나"보다 “왜 하필 지금 이 글이 다시 읽히는가"를 봅니다.

혁신 토큰이라는 개념, 다시 짚고 가기

매킨리의 주장은 단순합니다. 어떤 회사든 쓸 수 있는 혁신 토큰(innovation token)이 몇 개뿐이라는 겁니다. 그가 제시한 숫자는 대략 3개입니다. 신기술을 도입할 때마다 이 토큰을 하나씩 씁니다. 토큰을 다 쓰면? 새로운 것을 시도할 여력이 없어집니다.

여기서 ‘지루하다’는 말은 ‘나쁘다’가 아닙니다. 예측 가능하다는 뜻입니다. PostgreSQL, MySQL, PHP, Python 같은 기술은 어떻게 망가지는지까지 문서에 남아 있습니다. 새벽 3시에 장애가 나도 스택오버플로에 답이 있습니다. 반면 나온 지 6개월 된 기술은 실패했을 때 무슨 일이 벌어질지 아무도 모릅니다.

매킨리는 이걸 “알려진 미지수(known unknowns)와 알려지지 않은 미지수(unknown unknowns)“의 차이로 설명했습니다. 성숙한 기술은 전자, 새 기술은 후자입니다. 그리고 회사를 망가뜨리는 건 대부분 후자입니다.

그런데 왜 하필 2026년일까

2015년의 맥락은 명확했습니다. 마이크로서비스와 NoSQL이 유행하던 시기입니다. 스타트업들이 필요도 없는데 MongoDB를 쓰고, 직원 10명짜리 회사가 서비스를 40개로 쪼개던 때였습니다. 매킨리의 글은 그 광풍에 건 브레이크였습니다.

2026년은 다릅니다. 지금 개발자가 마주한 건 선택 과잉이 아니라 생산 과잉입니다. AI 코딩 도구가 하루에 수천 줄씩 코드를 뱉어냅니다. 프레임워크 하나 배우는 비용이 확 낮아졌습니다. “이 라이브러리 처음 써봐요"라는 말이 더 이상 장벽이 아닙니다. AI에게 물어보면 되니까요.

함정은 여기서 생깁니다. 도입 비용이 낮아졌다고 운영 비용까지 같이 낮아지진 않았습니다.

AI는 ‘쓰는 비용’만 낮췄지 ‘고치는 비용’은 그대로다

요즘 논의가 걸려 있는 지점이 여기입니다. AI 어시스턴트는 코드를 작성하는 단계에서 정말 잘 씁니다. 처음 보는 프레임워크의 보일러플레이트를 5초 만에 만들어줍니다. 문서를 읽지 않아도 동작하는 코드가 나옵니다.

문제는 그 다음입니다. 프로덕션에서 이상한 방식으로 터졌을 때, AI가 학습한 데이터에 그 상황이 없으면 답이 안 나옵니다. 성숙한 기술은 11년치 장애 사례가 인터넷에 쌓여 있어서 AI도 잘 답합니다. 나온 지 3개월 된 도구는? AI도 그럴듯하게 지어낼 뿐입니다.

그래서 AI 시대에 지루한 기술의 값이 오히려 올라간다는 말이 나옵니다. AI가 제일 잘 아는 기술이 곧 학습 데이터가 제일 많이 쌓인 기술이고, 그건 대체로 오래되고 검증된 쪽이니까요. React, PostgreSQL, Django를 물었을 때와 최신 프레임워크를 물었을 때, 답변 품질은 체감상 차이가 큽니다.

반대편 주장도 만만치 않습니다

물론 반론도 있습니다. AI가 학습 곡선을 없애버렸으니 이제 ‘지루함’을 고집할 이유가 줄었다는 시각입니다. 예전에는 새 기술 하나 익히는 데 몇 주가 걸렸고, 팀원 전체가 그 비용을 나눠 져야 했습니다. 지금은 그 비용이 훨씬 작습니다.

또 하나. 매킨리의 조언을 지나치게 문자 그대로 받아들이면 기술 부채가 쌓입니다. 2015년에 “지루하니까"라며 고른 스택을 2026년까지 그대로 들고 있는 조직은, 그 사이 업계가 해결한 문제를 여전히 손으로 처리하고 있을 겁니다. 지루함이 정체의 알리바이가 되면 곤란합니다.

현실적인 답은 중간 어딘가입니다. 혁신 토큰은 여전히 유한하지만 개수보다 어디에 쓰느냐가 중요합니다. 매킨리도 이 점을 강조했습니다. 회사의 핵심 경쟁력에 걸린 부분에 토큰을 쓰라는 겁니다. 로그 수집 파이프라인에 최신 기술을 쓰는 건 낭비지만, 제품의 차별화 지점이라면 이야기가 다릅니다.

AI 자체가 지금의 ‘지루하지 않은 기술’입니다

한 걸음 물러나서 보면 그림이 좀 우습습니다. 지금 대부분의 조직은 이미 혁신 토큰을 AI에 몰아서 쓰고 있습니다. 에이전트, RAG 파이프라인, 벡터 DB, 프롬프트 오케스트레이션. 전부 나온 지 몇 년 안 됐고, 실패 양상이 제대로 정리되지 않은 영역입니다.

그렇다면 매킨리의 조언은 이렇게 번역됩니다. AI 스택에 토큰을 다 썼다면 나머지는 최대한 지루하게 가라. 데이터베이스는 PostgreSQL로 두고, 배포는 이미 검증된 방식으로. 언어는 팀이 아는 걸 씁니다. AI라는 미지수 하나만으로도 충분히 위험합니다. 거기에 새 언어와 새 인프라를 얹으면 장애가 났을 때 원인이 어디인지 특정조차 못 합니다.

이게 2015년 에세이가 2026년에 다시 읽히는 이유일 겁니다. 글이 새로워져서가 아니라, 그 글이 겨냥했던 문제가 훨씬 큰 규모로 돌아왔기 때문입니다.

기술 선택은 리스크 예산 문제입니다

기술 선택은 취향이 아니라 리스크 예산의 문제입니다. 매킨리가 11년 전에 한 말이 아직 먹히는 건, 사람이 감당할 수 있는 불확실성의 총량이 그때나 지금이나 별로 안 늘었기 때문입니다.

여러분의 팀은 지금 혁신 토큰을 몇 개나 쓰고 있나요. 그 토큰이 정말 제품의 차별화 지점에 쓰이고 있는지도 한번 따져볼 만합니다. AI 도입에 한 개, 새 프레임워크에 한 개, 새 인프라에 한 개를 이미 썼다면, 다음에 장애가 났을 때 무엇부터 의심할지 지금 정해두는 편이 좋겠습니다.