새로운 프레임워크와 데이터베이스가 매주 쏟아지는 환경에서, 엔지니어가 가장 자주 마주치는 유혹은 '최신이면서 가장 좋은 도구'를 골라 쓰고 싶다는 욕구다. Etsy 출신 엔지니어 댄 매킨리(Dan McKinley)가 2015년에 쓴 'Choose Boring Technology'는 바로 그 유혹에 제동을 거는 글이다. 발표된 지 10년이 지났지만, 마이크로서비스와 폴리글랏 스택이 일반화된 지금 오히려 더 자주 인용된다. 이 글의 핵심은 단순하다. 기술 선택은 개인의 취향 문제가 아니라 조직 전체의 운영 비용을 좌우하는 결정이며, 대부분의 회사는 자신이 감당할 수 있는 혁신의 양을 과대평가한다는 것이다.
이노베이션 토큰이라는 사고 실험
글의 중심에는 '이노베이션 토큰'이라는 비유가 있다. 매킨리는 모든 회사가 대략 세 개의 혁신 토큰을 가지고 시작한다고 가정한다. 이 토큰은 원하는 곳에 쓸 수 있지만 공급은 오랫동안 고정되어 있고, 어느 정도 안정성과 성숙도를 확보한 뒤에야 몇 개를 더 얻을 수 있다. NodeJS로 웹사이트를 짓기로 하면 토큰 하나를 쓴 것이고, MongoDB를 도입해도, 나온 지 1년도 안 된 서비스 디스커버리 기술을 쓰기로 해도 각각 토큰 하나가 사라진다. 직접 데이터베이스를 만들기 시작하면 그건 이미 심각한 곤경이다.
물론 자바스크립트 컨설팅 회사나 데이터베이스 회사라면 이런 선택이 합리적일 수 있다. 그러나 대부분의 회사는 '글로벌 커머스를 재정의'하거나 '웹 결제를 재발명'하는 것 같은 본업의 미션을 좇는다. 그런 맥락에서 ssh를 혁신하는 데 한정된 주의력을 쏟는 것은 실패로 가는 훌륭한 지름길이거나, 잘해야 성공을 지연시키는 일이다. 토큰의 요점은 혁신을 금지하는 것이 아니라, 혁신에 쓸 수 있는 예산이 유한하다는 사실을 직시하게 만드는 데 있다.
'지루함'은 나쁨이 아니라 예측 가능함이다
여기서 매킨리는 '지루하다(boring)'는 말을 '나쁘다'와 혼동해서는 안 된다고 강조한다. 지루하면서 나쁜 기술도 분명히 존재하고 그런 것은 쓰지 말아야 한다. 하지만 지루하면서 좋은, 혹은 최소한 충분히 쓸 만한 기술은 많다. MySQL, Postgres, PHP, Python, Memcached, Squid, Cron 같은 것들이다. 이들의 강점은 기능이 잘 알려져 있다는 점보다도, 실패 방식이 잘 알려져 있다는 데 있다.
그는 이를 '알려진 미지(known unknowns)'와 '알려지지 않은 미지(unknown unknowns)'라는 구분으로 설명한다. 수십 년 된 기술에도 두 종류의 미지는 모두 남아 있지만, 반짝이는 신기술에서는 특히 후자, 즉 무엇을 모르는지조차 모르는 영역의 크기가 훨씬 크다. 새벽 세 시에 장애가 났을 때, 커뮤니티에 축적된 트러블슈팅 경험이 있는 성숙한 도구와 그렇지 않은 도구의 차이는 바로 이 지점에서 갈린다.
'최고의 도구'라는 착시와 운영 비용
기술을 하나 추가하는 데는 항상 비용이 따른다. 이미 Ruby를 쓰고 있는데 Python을 섞으면 복잡성이 Python의 한계효용을 넘어선다는 건 추상적으로는 자명하다. 그런데도 Python과 Scala, MySQL과 Redis 같은 조합 앞에서는 사람들이 제약을 잊고 '작업에 맞는 최고의 도구'를 외치기 시작한다. 문제는 이 사고방식이 '최고'와 '작업'을 근시안적으로 본다는 데 있다. 매킨리의 표현을 빌리면, 당신의 진짜 작업은 회사를 계속 굴러가게 하는 것이고, 최고의 도구란 최대한 많은 문제에 대해 '가장 덜 나쁜' 위치를 차지하는 도구다.
도구를 추가하면 모니터링을 붙여야 하고, 단위 테스트 방법을 마련해야 하고, init 스크립트를 짜야 하고, 손대려면 최소한의 지식을 갖춘 사람이 있어야 한다. 이 운영 부담과 인지적 오버헤드는 빠르게 누적된다. 매킨리가 반복해서 강조하는 명제는 이것이다. 시스템을 오랫동안 안정적으로 유지하는 장기 비용은 그것을 만드는 동안 겪는 불편함을 거의 언제나 압도한다. 개발자들에게 완전한 도구 선택의 자유를 주면 생산성이 오른다는 폴리글랏 프로그래밍의 약속은, 매킨리가 보기에 일상적 운영 노고의 무게에 짓눌려 사라지는 순진한 기대다.
도구를 추가하기 전에 거치는 관문
그렇다고 자바 하나로 모든 것을 구현하라는 극단이 답은 아니다. 매킨리는 새 기술을 들이는 과정을 하나의 대화이자 절차로 만들 것을 제안한다. 새 기술은 결국 회사 전체에 영향을 주므로 도입 결정에는 회사 차원의 가시성이 필요하고, 이것이 다 함께 논의할 사안이라는 문화적 기대를 세워야 한다. 가장 유용한 훈련은 '지금 가진 것만으로 이 문제를 어떻게 풀 수 있을까'를 먼저 자문하는 것이다. 이 질문은 진짜 문제가 '누군가 그 기술을 그냥 써 보고 싶어 한다'는 데 있는 상황을 걸러낸다. 실제로 답은 '불가능하다'인 경우가 거의 없고, 대개 '할 수는 있지만 너무 어렵다'는 스펙트럼 어딘가에 놓인다. 그리고 현재 스택으로 문제를 푸는 것이 왜 그렇게 비싸고 어려운지를 글로 명확히 적어 두라고 권한다. 새 기술이 기존 기능을 대체한다면 '마이그레이션하겠다'는 약속과 일정을 함께 정해, 국소적으로 최적화된 해법들이 난립하는 것을 막아야 한다.
Etsy의 액티비티 피드는 이 원칙이 실제로 어떻게 작동했는지 보여주는 사례다. 당시 팀은 대부분을 PHP·MySQL·Memcached·Gearman 위로 통합하고 있었고, Redis 같은 것을 썼다면 더 쉬웠을지도 모를 기능을 굳이 그 공유 스택 위에 더 복잡하게 구현했다. 그 결과 몇 년 동안 아무도 신경 쓰지 않는 사이 피드 사용량이 20배로 늘었지만, 액티비티 피드만을 겨냥한 변경은 단 한 번도 없이 모든 것이 잘 돌아갔다. 공유 플랫폼 위에 올려 둔 덕분이다. 다만 이것이 절대주의는 아니었다. 패싯이 포함된 전문 검색을 순수 PHP로 구현하는 것은 비현실적이라고 판단해 Etsy는 Solr를 도입했다. 지루한 기술을 기본값으로 두되, 토큰을 써야 할 진짜 자리에서는 아끼지 않는다는 것—한국의 실무 조직이 스택을 정리하고 기술 도입 기준을 세울 때, 이 균형감이야말로 10년 전 글에서 가장 오래 남는 교훈이다.