LLM이 코드를 작성하는 시대에도 Ruby on Rails 같은 프레임워크는 구조와 보안 업데이트, 성능 개선을 제공하므로 여전히 유용하다는 의견이다. 기존 애플리케이션을 Rust로 전면 재작성하면 동작이 달라질 수 있어, 특히 사용자가 매일 쓰는 제품에서는 충분한 테스트와 신중한 판단이 필요하다고 본다.
프레임워크와 라이브러리는 코드 작성의 수고를 덜고 프로젝트에 일관된 구조를 제공한다. 이런 장점은 사람이 아닌 LLM이 코드를 작성할 때도 유효하다고 본다. 제품 개발은 작업 큐나 ORM을 직접 만드는 데 집중하기보다 사용자의 문제를 해결하는 데 초점을 맞춰야 한다는 설명이다.
다른 언어로 옮기면 원래 프레임워크와 라이브러리, 언어가 만들어내던 동작도 달라질 수 있다. 테스트를 통과하는 기능적으로 동등한 프로그램을 만들더라도 기존 앱의 버그가 고쳐지는 대신 사용자가 의존하던 동작이 바뀌거나 새로운 버그가 생길 수 있다. 매일 여러 시간 애플리케이션을 쓰는 사용자는 작은 인터페이스 변경에도 반응할 수 있어, 전면 재작성의 핵심 부담은 코드 생성보다 동작을 철저히 검증하는 데 있다는 주장이다.
성능을 높이려면 언어를 바꾸기 전에 LLM에 기존 애플리케이션을 최적화하도록 요청하는 방법도 있다고 제안한다. 의존성을 업데이트하면 활발히 개발되는 프레임워크와 라이브러리, 언어의 개선과 보안 점검을 활용할 수 있다는 점도 Rails를 계속 쓰는 이유로 든다. 다만 새 Ruby 버전이 기존 코드의 속도를 10배 높이고 메모리 사용량을 10분의 1로 줄일 수 있다는 대목은 가능성을 든 질문이지, 확인된 성과가 아니다.
코드를 직접 살펴보면 LLM이 확인하지 않고 넘어간 기존 구조나 모호한 요청의 영향을 파악할 수 있다고 본다. Rails와 Ruby에 익숙하면 에이전트가 큰 변경을 제안했을 때 중요한 부분을 알아보기 쉽다는 설명이다. Ruby의 코드 즉시 재로딩과 REPL도 컴파일이나 배포 없이 변경 사항을 시험하고 문제를 진단하는 데 도움이 된다고 덧붙인다.
새로 배우고 성능을 개선할 목적으로 일부 소프트웨어에 Go를 적용하는 방안을 생각하고 있다. 기존 Rails 구조와 복잡한 연동이 필요 없는 백그라운드 작업이 후보이며, Go는 간결성과 빠른 컴파일이 장점이라고 평가한다. Rust는 성능이 더 나을 수 있지만 컴파일이 느리고 코드를 읽기 어렵다는 단점이 있다고 본다. 프런트엔드는 HTMX에서 Svelte로 옮기는 방안도 언급하지만, 이는 큰 변경을 수반하며 백엔드를 Node로 바꾸거나 Rails가 JSON 또는 GraphQL로 데이터를 제공해야 할 수 있다고 설명한다.
당분간 기존 애플리케이션을 Rails로 계속 개발하고 새 프로젝트에도 Rails를 사용할 생각이다. 성능이 무엇보다 중요한 경우에는 Rust를 고려할 수 있지만, 일반적인 업무용 소프트웨어에는 적합하지 않을 수 있다는 견해다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요