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

• 새로운 기술을 절제하고 검증된 기술(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를 사용