2015년 '지루한 기술을 고르라'는 조언, HN에서 에이전트 시대의 스택 선택 기준으로 재논의

이 글은 오래됐지만 여전히 잘 맞음. 특히 혁신 토큰이라는 표현은 PM이나 엔지니어링 리더가 트레이드오프를 설명할 때 정말 유용했음.

토큰을 정해진 개수로 보는 건 조금 부정확하다고 봄. 새 기술은 부채와 위험 잔액을 깎는 선택에 가깝고, 이메일 공급자 교체처럼 쉽게 되돌릴 수 있는 변화와 새 런타임으로 전체 앱을 만드는 변화는 위험도가 다름.

개인 프로젝트도 같다고 봄. 낯선 것을 만들거나 낯선 스택을 쓰거나 둘 중 하나만 해야지, 둘 다 하면 감당하기 어려움.

2015년의 Node.js는 토큰을 쓸 선택이었겠지만, 지금은 충분히 성숙해서 지루한 기술로 봄. 지금의 Bun 쪽이 토큰을 쓰는 선택에 가까움.

몇 년째 안정적으로 돌아가는 소프트웨어는 상품처럼 취급되지 않음. 화제는 덜 되지만 나는 거의 항상 새 기술보다 신뢰성을 고름.

이 원칙은 이력서에는 불리함. 관리자와 직원 모두 유행하는 기술로 보상받고, 유행은 대체로 새로움에서 나오니 지루한 기술을 고를 유인이 반대 방향임.

에이전트 시대에는 혁신 토큰을 에이전트에 몰아넣는 편이 낫다고 봄. 에이전트가 Zig보다 Rust를 훨씬 잘 다룬다면 Zig의 장점은 에이전트의 Rust 숙련도로 생기는 이득에 묻힐 수 있음.

AI로 웹을 만들 때는 TypeScript 모노레포보다 PHP, Ruby, Elixir가 배포 파이프라인과 서버-클라이언트 소통을 더 빠르게 만들 때가 많았음. TypeScript와 Effect를 좋아해도 그 언어들이 더 단단한 선택일 수 있더라.

기술이 지루해지는 기준은 계속 바뀌는데 사람들의 인식은 그보다 느림. Kubernetes는 이제 12년 넘게 널리 쓰였지만, 여전히 많은 사람이 새롭고 위험한 기술처럼 말함. 그래도 사용하는 회사의 약 90%에는 부적절하다고 봄.

'혁신 토큰'은 임의적이고 기술 평가를 흐림. 요구사항, 위험, 기대 이익, 테스트 수준을 보고 선택해야 하며, 새 프로젝트라도 Jepsen·퍼징·오라클 테스트가 충분하면 오래된 미검증 소프트웨어보다 나을 수 있음.

이 글은 대규모로 새 기술을 무비판적으로 따라 하던 시기에 나온 글임. 여기서 지루함은 오래됐다는 뜻보다, 날카로운 모서리와 실패 방식을 이미 아는 기술이라는 뜻으로 읽어야 함.