- 미첼 하시모토 “지금 많은 기업이 심각한 AI 집단 광기에 빠져 있다” 경고와 인프라 시대 MTBF/MTTR 논쟁의 재림
- matklad 소프트웨어 아키텍처는 기술 구조가 아니라 인센티브 구조이며, rust-analyzer는 인센티브를 의도적으로 설계해 고효율 기여자를 모았다
- Diesel v2.3.6 SQLx v0.8.6 SeaORM v2.0 Rusqlite v0.38.0 네 종을 1년간 모두 프로덕션에 올린 개발자의 솔직한 비교와 의사결정 프레임
5월 18일 GeekNews 메인 상단에는 얼핏 무관해 보이는 세 글이 나란히 떠 있었다. HashiCorp 공동창업자 미첼 하시모토의 AI 집단 광기 경고, rust-analyzer 핵심 메인테이너 matklad(Aleksey Kladov)의 아키텍처 학습 회고(69포인트), 그리고 Diesel·SQLx·SeaORM·Rusqlite를 1년간 모두 운영에 써본 개발자의 비교 글이다. 표면은 다르지만 한 줄로 묶으면 이렇게 된다 — 속도와 인센티브, 그리고 도구 선택이 코드베이스의 1년 뒤 운명을 가른다.
미첼 하시모토 “AI 집단 광기가 회복력 있는 재앙 기계를 만든다”
MTTR 만능주의의 함정
HashiCorp 공동창업자 미첼 하시모토가 2026년 5월 16일 X에 올린 글의 첫 문장은 단호하다. “지금 많은 기업이 심각한 AI 집단 광기(AI psychosis)에 빠져 있으며, 그들과 이성적인 대화를 나누는 것은 불가능하다.” 그는 클라우드 자동화 초기에 인프라 업계가 겪었던 MTBF(평균 고장 간격) vs MTTR(평균 복구 시간) 논쟁이 이제 소프트웨어 개발 산업 전체로 확산되고 있다고 진단한다.
맹신론자들의 논리는 한 줄로 요약된다. “에이전트가 인간이 할 수 없는 속도와 규모로 버그를 고칠 테니, 버그를 출시해도 괜찮다.” 인프라 시대에 이미 한 번 실패로 검증된 사고방식이 이번에는 애플리케이션 코드 전체로 옮겨붙고 있다는 것이 그의 우려다. 그는 인프라에서 배운 한 가지 교훈을 반복한다 — “MTTR이 훌륭하더라도 회복력 있는 시스템 자체를 완전히 버릴 수는 없다.”
국지 지표는 건강한데 기저 아키텍처는 부식 중
하시모토가 문제를 직접 제기하면 돌아오는 답은 정해져 있다. “테스트 커버리지가 100%다”, “버그 리포트가 줄고 있다.” 그러나 그는 이런 즉각적 반박이 전체 그림을 보여주지 못한다고 본다. 버그 리포트는 줄어들지만 잠재적 위험은 폭증하고, 테스트 커버리지는 올라가지만 의미론적 이해는 떨어진다. 변화가 너무 빨라 아무도 기저 아키텍처의 부식을 인지하지 못한다.
답글에서도 묵직한 지적이 나왔다. @adamhjk는 “순수 바이브 코딩이 가장 먼저 파괴하는 것이 아키텍처 자체”라고 짚었다. @beyang은 현재 에이전트 UX가 “LGTM(Looks Good To Me)”을 가장 저항이 적은 경로로 만들면서, 코드 리뷰의 검증 문제를 즉각적 위협으로 격상시켰다고 평했다. tinygrad 계정은 “AI가 만든 결과가 잘못된 정보인지 판별하는 데 10초가 아닌 20분이 걸리는 시대”가 왔다고 말했다. 하시모토의 처방은 단순하다 — “AI를 쓰되, 생각하라.”
Tech Insight — 하시모토의 경고는 단순한 AI 회의론이 아니다. 인프라 자동화 시대의 교훈은 “MTTR이 훌륭해도 회복력 있는 시스템을 완전히 버릴 수는 없다”였다. CTO와 엔지니어링 리더가 지금 던져야 할 질문은 단 하나다 — “어떤 결정을 의식적으로 에이전트에 외주할 것이고, 어떤 결정은 절대 외주하지 않을 것인가.” 부채는 분기 단위로 쌓이고, 청구서는 연 단위로 도착한다.
matklad 아키텍처는 기술 구조가 아니라 ‘인센티브 구조’다
Conway’s Law를 도구가 아닌 설계로
rust-analyzer 핵심 메인테이너 Aleksey Kladov(matklad)가 5월 12일 자신의 블로그에 올린 글의 결론은 의외다. “소프트웨어 설계는 강의가 아니라 실제 프로젝트에서 책임을 맡고 문제가 자기 일이 될 때 가장 깊게 배운다.” 그가 IntelliJ Rust를 만들면서 진짜 학습이 시작됐다고 회고한 이유다.
그는 Conway’s Law를 단순한 격언이 아니라 설계 도구로 본다. 과학용 코드와 산업용 코드의 차이는 기술 지식이 아니라 “3개월 안에 논문을 내야 한다” 같은 인센티브 구조에서 갈린다. 그래서 아키텍트가 가장 큰 영향을 주는 순간은, 코드를 그리는 순간이 아니라 프로젝트의 인센티브 구조를 설계하거나 조정할 수 있는 드문 기회를 잡았을 때다.
rust-analyzer가 기여자를 끌어들인 진짜 비결
rust-analyzer는 의도적으로 두 종류의 기여자를 분리해 끌어들였다. 컴파일러 깊이에 헌신할 수 있는 코어 기여자와, 주말 한두 시간만 쓸 수 있는 캐주얼 기여자다. 후자를 위해 매우 구체적인 제약이 깔렸다 — rustc 빌드를 요구하지 않는다, stable Rust에서 빌드된다, C 의존성이 없다, 전체 테스트가 몇 초 안에 끝난다.
아키텍처적으로는 기능을 독립 모듈로 쪼개고 런타임에서 catch_unwind로 격리했다. 그래서 기능 PR의 기준은 “해피 패스가 동작하고 테스트가 있음”으로 충분했고, 크래시가 나도 다른 부분으로 번지지 않게 했다. 단, 기능을 떠받치는 핵심 spine에는 훨씬 엄격한 품질 기준을 적용했다. 그는 추천 자료로 Gary Bernhardt의 강연 “Boundaries”, ZeroMQ Guide, Ousterhout의 A Philosophy of Software Design, 그리고 Architecture of Open Source Applications 시리즈를 꼽았다. “실험적 구조가 장기 현실이 되는 위험”도 함께 경고했는데, rust-analyzer 자체가 결국 또 하나의 컴파일러를 유지하게 된 사례다.
Tech Insight — matklad의 글을 하시모토와 같이 읽으면 답이 보인다. 좋은 설계는 결국 “사람이 덜 위험한 선택을 자연스럽게 하도록 만드는 환경”이다. AI 에이전트를 도입할 때도 같은 질문이 유효하다. 우리 코드베이스에서 LGTM이 가장 저항 없는 경로인가, 아니면 의문을 던지는 것이 더 자연스러운가. 그 답이 1년 뒤 코드의 운명을 결정한다.
Rust 백엔드 DB 4종, 1년 운영 후 솔직한 비교
2026년 2월 기준 네 주자의 좌표
aarambhdevhub의 필자는 지난 1년간 Diesel, SQLx, SeaORM, Rusqlite를 모두 프로덕션에 올렸다고 밝히며 정면 비교를 내놓는다. 2026년 2월 기준 버전은 다음과 같다 — Diesel v2.3.6(2026년 1월, 컴파일 타임 SQL 풀 ORM), SQLx v0.8.6(비동기 SQL 툴킷, ORM 아님), SeaORM v2.0(2026년 1월, 비동기 우선 동적 ORM), Rusqlite v0.38.0(2025년 12월, SQLite 전용 래퍼). 네 도구 모두 SQL 인젝션 방지와 안정성은 충분하다는 것이 그의 전제다.
의사결정 프레임 — “당신의 뇌에 맞는 도구를 골라라”
Diesel은 컴파일러가 잘못된 JOIN과 타입 미스매치를 사전에 잡는다. 컬럼 세 개를 동시에 리네임해도 수정이 필요한 모든 쿼리를 빠짐없이 알려준다. 단 비동기는 diesel-async가 필요하고, 동적 쿼리가 많으면 타입 시스템과 싸우는 시간이 길어진다. SQLx는 raw SQL을 그대로 쓰면서 컴파일 시점에 실제 DB에 연결해 검증한다. 다만 CI에 DB 접근이 필요하거나 cargo sqlx prepare로 .sqlx 캐시를 유지해야 하는 운영 부담이 있다.
SeaORM 2.0은 Django ORM이나 ActiveRecord에서 넘어온 개발자가 가장 빠르게 적응한다. Entity Loader가 N+1을 우아하게 해결하고, 동적 쿼리와 관계 처리가 일급 시민이다. 단점은 런타임 에러와 상대적으로 작은 생태계. Rusqlite는 bundled 피처로 SQLite를 바이너리에 직접 컴파일해 시스템 의존성을 0으로 만든다. CLI 도구·데스크톱·임베디드에서는 사실상 단일 정답이다. 필자의 결론은 명쾌하다 — “SQLite면 Rusqlite, 정적 스키마에 안전성 최우선이면 Diesel, SQL 퍼스트면 SQLx, 동적·관계 중심이면 SeaORM. 그리고 연구는 그만하고 빌드를 시작하라.”
Tech Insight — 이 비교는 단순한 라이브러리 가이드가 아니라 matklad의 인센티브 설계론과 정확히 같은 결을 갖는다. 어떤 도구를 고르느냐는 “팀의 뇌가 어떻게 사고하는가, 그리고 잘못된 코드를 짜기 어렵게 만드는 가드레일을 어디에 둘 것인가”의 문제다. 새 프로젝트라면 PostgreSQL·MySQL 환경에서는 Diesel을 기본값으로 두고, SQL 퍼스트 팀이면 SQLx, Django 출신이 다수면 SeaORM부터 검토하는 것이 합리적이다.
관련 글
출처
- GeekNews 메인 (2026-05-18 캡처) — TOP 인기 글 목록
- Mitchell Hashimoto on X — “AI psychosis” 원문 (2026-05-16)
- matklad — Learning Software Architecture (2026-05-12)
- Rust ORMs in 2026: Diesel vs SQLx vs SeaORM vs Rusqlite (aarambhdevhub, Medium, 2026-05-12)
AI Biz Insider · Tech Digest · aibizinsider.com
댓글 남기기