Rails 8과 Hotwire로 모놀리스 운영 복잡도 낮추기

Hotwire는 HTML 응답을 화면 전환의 중심에 둔다

Hotwire는 JSON 대신 서버가 완성된 HTML을 보내는 “HTML Over the Wire” 방식이다. 2026년 기준 Rails 신규 프로젝트의 기본 구성으로 채택되어 있으며, Turbo Drive·Turbo Frames·Turbo Streams와 Stimulus가 서로 다른 화면 갱신 범위를 맡는다.

⤢✕

Turbo Drive는 링크 클릭과 폼 제출 때 전체 페이지를 다시 읽지 않고 <body>를 교체한다. <head>를 공유하므로 CSS와 JavaScript 재로딩을 피하고, 히스토리 스택과 뒤로가기·앞으로가기 캐시도 관리한다.

부분 갱신이 필요한 화면에는 Turbo Frames를 둔다. <turbo-frame>로 독립 갱신 영역을 선언하면 해당 프레임 안의 링크와 폼은 프레임만 업데이트한다. loading="lazy"로 초기 렌더링을 늦출 수 있고, 중첩 프레임으로 복잡한 레이아웃도 분해할 수 있다.

Turbo Streams는 한 응답으로 여러 DOM 영역을 바꿀 때 사용한다. append, prepend, replace, update, remove, before, after의 7가지 액션을 제공하며, ActionCable이나 SSE(Server-Sent Events)와 연결해 실시간 갱신을 처리한다. Turbo 8의 모핑(Morphing)은 DOM을 비교해 깜빡임을 줄이고 컨트롤러 단절을 최소화한다.

Stimulus는 Turbo만으로 처리하기 어려운 드래그앤드롭이나 클립보드 복사 같은 상호작용을 담당한다. HTML의 data-controller, data-action, data-target 속성으로 동작을 연결하며, 컨트롤러 인스턴스는 DOM 생명주기를 따른다.

데이터베이스로 잡·캐시·실시간 기능을 묶는 Solid Trifecta

Rails 8의 Solid Trifecta는 Redis와 Sidekiq 같은 외부 인프라 의존성을 데이터베이스 중심으로 옮기는 전략이다. 애플리케이션 데이터와 운영용 기능을 함께 관리해 구성 복잡성과 운영 비용을 낮추는 데 초점이 있다.

⤢✕

Solid Queue는 FOR UPDATE SKIP LOCKED 쿼리로 잡 경쟁 조건 없이 처리한다. ActiveJob 인터페이스와 완전 호환되며, Sidekiq·Resque를 대체할 수 있다. 우선순위, 지연 실행, 반복 잡, 재시도를 기본 지원하고, 데이터베이스 트랜잭션 안에서 잡을 인큐해 데이터 일관성을 유지한다. 실행 이력도 데이터베이스에 남으므로 감사(Audit) 추적이 쉽다.

기능	Solid Queue	Sidekiq (Redis)
별도 인프라	불필요	Redis 서버 필요
처리량	중간	매우 높음
트랜잭션 안전성	보장	미보장
잡 이력 보존	DB 저장	인메모리/별도 설정
운영 복잡도	낮음	중간

Solid Cache는 RAM 대신 SSD·NVMe 디스크를 활용해 대용량 캐시를 구성한다. Basecamp는 10TB 캐시를 60일 보존 기간으로 적용했고 렌더링 시간을 대폭 단축했다. LRU(Least Recently Used) 만료 정책을 지원하며, 기존 Rails 캐시 API와 호환되므로 코드 변경 없이 전환할 수 있다. 멀티 데이터베이스 구성에서는 캐시 전용 DB를 분리할 수도 있다.

Solid Cable은 Redis Pub/Sub 대신 데이터베이스로 WebSocket 메시지를 브로드캐스트한다. 폴링 방식으로 근-실시간(near real-time) 성능을 내며, 메시지는 기본 1일 보존된다. 소규모·중규모 트래픽 환경이라면 Redis 없이 실시간 기능을 운영할 수 있다.

Rails 8에 포함된 인증·배포·프록시 기능

세션 기반 인증은 서드파티 gem인 Devise 등에 의존하지 않고 공식 생성기로 만들 수 있다.

bin/rails generate authentication

생성기는 User, Session 모델과 비밀번호 재설정 이메일용 PasswordsMailer, 로그인·로그아웃 처리를 위한 SessionsController를 만든다. 컨트롤러 인증 헬퍼는 Authentication concern에 포함되고, 비밀번호 해싱에는 BCrypt가 기본 적용된다.

Kamal 2는 클라우드 VM이나 온프레미스 서버에 kamal setup 한 명령으로 배포하는 방식을 제공한다. Kamal Proxy는 Traefik을 대체하는 자체 프록시로, 무중단 배포와 Let's Encrypt 자동 SSL 인증서 발급을 지원한다. 단일 서버에서 여러 애플리케이션을 호스팅할 수 있어 복잡한 PaaS 설정 없이 Heroku급 배포 경험을 목표로 한다.

Thruster는 Puma 앞단에서 동작하는 Go 기반 경량 HTTP 프록시다. X-Sendfile 가속, 자산 캐싱, 압축을 담당하며 Nginx 없이도 정적 자산을 효율적으로 서빙할 수 있다.

Rails 8.1은 2025년 10월 22일 출시됐고, 500명 이상의 기여자와 2,500개 커밋 규모의 업데이트를 포함한다. 장시간 실행 중 중단된 잡을 다시 이어가는 잡 컨티뉴에이션(Job Continuations), 오류 추적·로그 분석 개선, 복잡한 조인 쿼리의 ActiveRecord 최적화가 포함됐다. 2025년 8월 8.0.2.1 보안 릴리스 등 보안 패치도 이어졌다.

서비스 분리보다 먼저 검토할 모놀리스의 경계

마이크로서비스는 2010년대 후반 엔터프라이즈 표준으로 자리 잡았지만, 2024~2026년에는 모놀리스 부활(Monolith Renaissance)이 다시 주목받았다. Shopify와 GitHub 같은 대형 Rails 기반 서비스는 모놀리식 핵심을 유지하면서도 확장성을 확보한 사례로 재조명되고 있다.

서비스를 나누면 분산 트랜잭션에서 데이터 일관성을 보장하기 어려워지고, 서비스 간 HTTP/gRPC 호출의 네트워크 레이턴시가 누적된다. 각 서비스마다 배포, 모니터링, 로깅 파이프라인도 따로 운영해야 한다. Conway의 법칙 관점에서 마이크로서비스는 큰 조직에 더 맞으며, 초기 단계 스타트업에서는 과도한 복잡성을 만들 수 있다.

DHH(David Heinemeier Hansson)가 제창한 Majestic Monolith는 내부 경계를 명확히 설계한 단일 애플리케이션이다. 배포 단위는 하나로 유지해 복잡성을 낮추고, 코드 차원에서 도메인 간 의존성을 제어한다. 공유 데이터베이스를 활용해 트랜잭션과 조인 쿼리를 단순화하면서, 필요해진 도메인만 점진적으로 마이크로서비스로 추출한다.

⤢✕

Packwerk로 모놀리스 안의 도메인 의존성을 관리한다

Shopify가 개발한 Packwerk는 Rails 모놀리스에 명시적 패키지 경계를 두는 정적 코드 분석 도구다. 2025~2026년에는 대규모 Rails 애플리케이션의 확장 전략으로 채택이 빠르게 늘고 있다.

관련 코드는 같은 팩에 모아 높은 응집도(High Cohesion)를 유지하고, 팩 사이의 접근은 공개 API로 제한해 낮은 결합도(Loose Coupling)를 만든다. 순환 의존성(Circular Dependency)은 정적으로 검출하며, package.yml에서 내부 API와 외부 공개 API를 구분한다.

app/
  packs/
    billing/          # 결제 도메인 팩
      app/
        models/
        services/
      package.yml     # 공개 API 선언
    catalog/          # 카탈로그 도메인 팩
      app/
        models/
        controllers/
      package.yml
    shared/           # 공통 컴포넌트
      app/
        concerns/
        helpers/

팩은 주문·결제·사용자처럼 비즈니스 도메인을 기준으로 나눈다. 외부에서 허용할 경로는 package.yml의 public_path로 선언하고, bin/packwerk check로 경계 위반을 검사한다. 전체 애플리케이션을 한 번에 바꾸기보다 도메인별로 순차 이전하는 방식이 전제다.

AI 에이전트가 Rails 모놀리스에서 얻는 컨텍스트

AI 개발 도구와 LLM 통합은 Rails 모놀리스 재부상의 촉매로 작용한다. MVC와 Convention over Configuration으로 대표되는 Rails 구조는 AI 에이전트가 코드베이스를 탐색하고 작업하는 환경과 맞닿아 있다.

RubyLLM은 ActiveRecord 패턴으로 LLM 호출을 구조화하는 Rails 네이티브 통합 라이브러리다. Langchain.rb는 Pinecone 등을 포함한 벡터 데이터베이스와 Agent를 활용하는 복잡한 AI 워크플로우를 구성한다. 2025년에는 OpenAI 공식 Ruby SDK인 openai-ruby SDK가 출시됐고 OpenAPI 스펙 자동 생성을 제공했다. Rails와 pgvector를 조합하면 PostgreSQL 벡터 확장으로 외부 벡터 DB 없이 시맨틱 검색을 구현할 수 있다.

단일 코드베이스에서는 AI 에이전트가 컨텍스트 손실 없이 코드 생성과 수정을 수행할 수 있다. 반면 마이크로서비스 환경에서는 서비스 간 의존성을 추론해야 한다. Packwerk로 모듈화한 모놀리스는 이 과정에서 도메인 경계를 더 분명하게 드러낸다.

⤢✕

RubyLLM::Chat은 대화형 AI 기능을 구현하고 ActiveRecord 모델에 이력을 저장하는 데 쓸 수 있다. pgvector와 Solid Cache를 함께 사용하면 임베딩 캐싱 비용을 줄일 수 있고, Solid Queue는 비동기 LLM 호출로 응답 지연을 분리한다. Hotwire Turbo Streams는 LLM 스트리밍 응답을 UI에 실시간으로 반영한다.

Rails 8의 방향은 기능을 외부 서비스로 계속 분리하기보다, 필요한 인프라와 화면 상호작용을 Rails 애플리케이션 안에서 관리하는 데 있다. Solid Trifecta는 운영 의존성을 줄이고, Majestic Monolith와 Packwerk는 커진 코드베이스의 복잡성을 통제한다. AI 보조 개발이 보편화된 환경에서는 단일 컨텍스트와 일관된 관례가 Rails의 “개발자 행복”이라는 설계 철학을 다시 경쟁력으로 만든다.