DHH의 AI 기반 Rust 및 Elixir 재작성 분석, 인간 감독의 중요성 재확인

AI 생성 코드의 맥락 일관성 부족

DHH(David Heinemeier Hansson)는 AI 에이전트를 활용해 Campfire Once 애플리케이션을 Ruby on Rails에서 Rust, Elixir, Go로 재작성했다. Piotr Sarnacki의 분석에 따르면, 프롬프트에 구체적인 제약 조건이 부족했던 탓에 AI는 임의적인 아키텍처 결정을 내렸다. 예를 들어 Rust 버전은 CSRF 토큰을 제거하고 Redis를 프로세스 내 큐로 대체한 반면, Elixir 버전은 하위 호환성을 더 잘 유지했다. 이러한 차이는 언어 자체의 특성이 아니라 AI의 암묵적인 선택에서 비롯된 것으로, 직접적인 비교를 어렵게 만든다.

성능 함정과 벤치마킹의 결함

인간 개발자라면 쉽게 발견했을 상당한 성능 문제가 재작성된 코드에 존재했다.

• Elixir: 읽기 작업의 동시성을 무시하고 단일 프로세스에서 순차적 SQL 쿼리를 실행했다.
• Rust: 비동기 런타임 내에서 비동기와 차단형 데이터베이스 작업을 혼합해 협력적 스케줄링으로 인해 워커 스레드가 멈출 수 있었다.

초기 벤치마크는 처리량에만 초점을 맞춰 오해를 불러일으켰다. Zach Daniels의 부하 테스트 결과, Rust 버전의 알림 전달 성공률은 **1%**에 불과한 반면 Elixir 버전은 **100%**였다. 그러나 이는 폐쇄 루프 테스트였다. 초당 100 POSTs의 일정 도착률로 재평가했을 때:

• Rust: HTTP 오류 없이 이벤트의 약 **14%**만 전달했으나, 지연된 클라이언트와의 연결을 끊었다.
• Elixir: 이벤트의 약 **60%**를 전달했으나 약 **23%**의 HTTP POST 요청이 타임아웃되었고, 최악의 경우 지연 시간은 180s에 달했다.

인간 판단이 필요한 트레이드오프

Rust 버전의 전달률을 개선하기 위해 tokio::sync::broadcast 채널 용량을 256에서 16384로 늘리자 전달률은 약 **90%**로 향상되었지만, pMAX 지연 시간이 130s 이상으로 증가했다. 저자는 이것이 원래의 fail-fast 방식보다 사용자 경험이 나쁘다고 주장한다. 한편, Elixir 버전은 스트레스 테스트 중 무제한 메일박스 때문에 1.8GB의 메모리를 소모했다. 이러한 사례들은 AI 에이전트가 지연 시간, 신뢰성, 리소스 사용량 간의 트레이드오프를 본질적으로 이해하지 못함을 보여주며, 개발자가 AI 생성 코드를 비판적으로 평가하고 제약해야 할 필요성을 강조한다.