훌륭한 기술이 안 쓰이는 이유

Async Rust는 작동한다. 기술적으로는 완성됐다. 그런데 실무에서 쓰기엔 너무 복잡하다. "작동한다"와 "쓸 수 있다"는 전혀 다른 말이다.

Tweede golf 팀이 정리한 분석이 Hacker News 상위를 차지했다. 주장은 명쾌하다. Rust의 async/await가 언어 명세에 안착한 지 5년이 지났지만, 사용성(ergonomics)은 아직 초기 수준을 벗어나지 못했다는 것. 비동기 환경에서 생명주기(lifetime) 제약이 더 복잡해지고, 패턴은 불명확하며, 에러 메시지는 전문가조차 해독하기 어렵다. 기능 자체는 된다. 하지만 팀 전체가 안정적으로 쓰기엔 벽이 너무 높다.

이건 Rust만의 문제가 아니다. 기술 생태계 전반에서 반복되는 패턴이다. 커뮤니티는 "이게 됩니까?"를 해결하고 나면, "이걸 누구나 쉽게 쓸 수 있습니까?"는 뒷전이 된다. 그 사이에서 실무 팀이 고생한다.

이런 장면을 본 적 있을 것이다. 기술 스택 결정 회의. "업계 표준이다", "성능이 좋다", "큰 회사들이 이미 쓴다". 반론이 없다. 결정이 난다. 그리고 3개월 뒤, 분위기가 달라진다. 온보딩이 예상보다 훨씬 오래 걸린다. 팀원 절반은 아직 불안하다. 신기능 개발보다 기술 적응에 리소스가 먼저 빠져나간다. 출시 일정이 밀리기 시작한다. 그제야 "이게 맞는 선택이었나"를 묻는다.

벤치마크 문서에는 이 비용이 나오지 않는다. 학습 비용, 디버깅 비용, 팀 내 지식 공유 비용. 이것들이 누적되면 "훌륭한 기술"이 "비싼 기술"로 바뀐다. 그 비용을 치르는 건 결국 팀이다.

기술 선택은 취향이 아니라 전략이다. 그 전략에서 가장 과소평가되는 기준이 하나 있다. 익숙함이다. 팀원의 러닝 커브, 6개월 뒤 이 코드를 이해할 사람이 팀 안에 남아있는지, 장애가 났을 때 빠르게 디버깅할 역량이 있는지. 이것들을 따지기 전에 "업계 트렌드"라는 말 하나가 결정을 내리는 경우가 너무 많다. 익숙한 도구를 잘 쓰는 것이 새 도구를 도입하는 것보다 90%의 경우 낫다. 이것은 이론이 아니라, 수많은 팀이 반복해서 배운 현장의 교훈이다.

Async Rust가 MVP 상태에 머물러 있다는 게 문제가 아니다. 그것을 알면서도 "트렌드라서" 결정하는 게 문제다. 다음에 새 기술 스택을 검토할 때, 한 가지만 먼저 물어보자. "6개월 뒤, 우리 팀이 이 코드를 자신 있게 다룰 수 있는가?" 더 나은 기술보다 더 맞는 기술이 팀을 살린다.

---

The Riido Way의 시선으로 바라본 테크 이슈 칼럼입니다.

---

⚠️ AI 생성 콘텐츠

이 글은 LLM 에이전트가 자동으로 작성·편집·발행했습니다. 사람 편집자의 사전 검토는 없습니다.

• 작성: 페르소나 기반 LLM (Anthropic Claude)
• 편집 회의: 편집장·도메인 전문가 페르소나 LLM 의 자동 평가 (게시 / 수정 / 재작성 판정)
• 이미지: 자동 생성 이미지 — 텍스트·실재 인물·로고를 포함하지 않는 추상 이미지
• 출처: 본문 상단의 1차 출처 링크 — 사실 확인은 반드시 그곳에서

LLM 은 최신 발표·맥락·뉘앙스를 잘못 읽을 수 있습니다. 시간 민감하거나 의사결정에 영향을 주는 정보는 원 출처를 우선 으로 확인해 주세요. 글의 결론·관점은 LLM 페르소나의 자동 생성물이며, 운영자의 직접 견해는 별도 글에 명시됩니다.

오류·오해의 소지가 있는 표현·삭제 요청은 환영합니다. 알려주시면 사람이 직접 검토하고 정정합니다.