"코드 안 읽어도 된다며?" AI한테 러스트 코딩 전부 맡겼다가 참사 난 사연

요약 루비 온 레일스(Ruby on Rails) 창시자로 유명한 DHH가 AI 에이전트를 이용해 자신의 프로젝트 'Campfire Once'를 러스트(Rust), 엘릭서(Elixir), Go 등 다양한 언어로 다시 작성(리라이트)해 화제를 모았습니다. DHH 본인이 러스트 코드를 직접 읽거나 작성하기 싫어해서 AI에게 전적으로 맡겼다고 밝혔는데, 필자는 이를 두고 '베테랑 개발자가 코드 한 줄 안 보고 AI에게 전권을 주었을 때 어떤 결과가 나오는지'를 보여주는 매우 흥미롭지만 암울한 사례라고 분석했습니다. 가장 먼저 지적된 문제는 프롬프트가 구체적이지 않을 때 AI가 내리는 기술적 결정들이 동전 던지기 수준이라는 점입니다. 하위 호환성 유지 여부, 레이턴시와 처리량 중 우선순위, 메모리 한계치, 장애 발생 시 알림 유실 허용 여부 등은 정답이 하나로 정해져 있지 않은 트레이드오프 영역입니다. 실제로 러스트 버전은 캐싱 편의를 위해 CSRF 토큰을 날려버리고 레디스(Redis) 대신 인프로세스 큐를 적용한 반면, 엘릭서 버전은 원본 레일스 구조에 훨씬 가깝게 구현되어 언어 간의 공정한 비교 자체가 무의미해졌습니다. 코드 내부를 뜯어보면 문제는 더 심각합니다. 엘릭서 버전은 SQL 쿼리를 병렬 처리가 가능한 조회 작업까지 단일 프로세스로 순차 처리해 비판을 받았지만, 러스트 버전 역시 비동기 런타임 환경에서 치명적인 결함을 보였습니다. 러스트의 비동기 런타임은 협조적 스케줄링(cooperative scheduling) 방식이라 특정 작업이 스레드를 양보하지 않으면 다른 작업이 멈추게 되는데, 러스트 구현체 곳곳에서 비동기 대신 블로킹 방식의 쿼리와 동기식 뮤텍스 락(sync lock)을 그대로 사용하고 있었습니다. 결과적으로 벤치마크에서도 심각한 허점이 드러났습니다. 높은 처리량만 자랑하던 겉보기 벤치마크와 달리, 부하 상태에서 새 글 알림 전송률을 측정한 테스트에서 러스트 버전은 전송 성공률이 겨우 1%에 불과했습니다. 반면 엘릭서는 배압(backpressure)을 훨씬 잘 처리하며 100% 전송에 성공했습니다. 필자는 이러한 사례들을 통해 "개발은 결코 완전히 해결된(solved) 영역이 아니며, AI가 코드를 짜주더라도 결국 사람이 무엇을 하고 있는지 직접 생각하고 이해해야 한다"고 꼬집었습니다.