AI 에이전트가 코드를 재작성하는 시대에도 시스템 설계에 대한 인간의 비판적 사고와 판단은 여전히 필수적입니다. 단순히 AI에 맡겨 코드를 변환하는 것은 호환성, 지연 시간, 처리량, 메모리 한도 등 핵심적인 설계 결정을 AI에 암묵적으로 위임하는 결과를 낳을 수 있습니다. 이는 예상치 못한 성능 저하나 기능 문제로 이어질 수 있기에, AI가 생성한 코드와 벤치마크 결과도 비판적으로 검토하며 시스템의 실패 방식과 자원 한도를 직접 설계해야 합니다.
Ruby on Rails(레일즈) 창시자 DHH(David Heinemeier Hansson)는 Campfire Once(캠프파이어 원스) 프로젝트의 코드를 Rails에서 Rust(러스트)로, 그리고 Elixir(엘릭서), Go(고) 등 다른 언어로 AI 에이전트를 통해 재작성했습니다. 하지만 이 과정에서 AI에게 충분히 구체적인 프롬프트를 제공하지 않으면, 하위 호환성 유지 여부, 지연 시간과 처리량 우선순위, 메모리 허용치, 장애 시 알림 유실 허용 여부 등 중요한 설계 선택이 AI의 암묵적인 결정에 맡겨지게 됩니다. 예를 들어, Rust 재작성 버전은 캐싱을 위해 CSRF 토큰을 제거하고 Redis(레디스)를 내부 큐로 대체하는 등 하위 호환성을 완전히 유지하지 않았지만, Elixir 재작성 버전은 Rails 원본에 훨씬 가깝게 구현되었습니다. 이러한 구현상의 차이는 언어 자체의 성능 차이로만 해석하기 어렵게 만듭니다.
벤치마크 결과 해석에서도 신중함이 요구됩니다. 단순히 처리량(throughput)이나 알림 전달률(delivery rate) 같은 단일 지표만으로는 시스템의 품질을 온전히 판단할 수 없습니다. Zach Daniels(자크 다니엘스)의 테스트에서 Rust 버전의 알림 전달률이 1%에 불과했지만, 이는 이벤트 버퍼 용량 제한 때문이었습니다. 버퍼 용량을 늘리자 전달률은 90%로 높아졌지만, 최대 전달 지연 시간도 11초에서 130초 이상으로 급증했습니다. 이는 전달률과 응답성(responsiveness) 사이의 상충관계(trade-off)를 명확히 보여줍니다. 또한, Elixir 버전은 메모리 사용량이 1.8GB에 달하는 등, 어떤 언어를 사용하든 메모리 부족으로 인한 프로세스 종료 위험을 감수할지, 일부 메시지를 버릴지 등 실패 방식과 자원 한도를 직접 결정해야 합니다. 결국, 신뢰할 수 있는 시스템을 구축하려면 언어와 무관하게 실패 시점과 자원 한도를 명확히 설계하고, AI가 생성한 코드와 벤치마크 결과를 비판적으로 이해하는 것이 중요합니다.