대규모 Rails 애플리케이션에서 비즈니스 로직 분리 및 모듈화 전략

Fito von Zastrow and Alan Ridlehoover, Derailing our app: How and why. SF Ruby Conference 2025

작성자
Evil Martians
발행일
2026년 01월 13일
원문 보기
www.youtube.com

핵심 요약

  • 1 Rails 애플리케이션의 비즈니스 로직을 컨트롤러, 뷰, 모델에서 순수 Ruby 객체로 분리하여 복잡성을 줄이고 테스트 용이성을 극대화했습니다.
  • 2 Kent Beck의 3X 개발 수명 주기(탐색, 확장, 추출)를 이해하고 애플리케이션의 현재 단계에 맞춰 아키텍처 및 투자 결정을 내리는 것이 중요합니다.
  • 3 도메인별 디렉토리 구조와 네임스페이스를 도입하여 팀의 자율성과 책임감을 강화하고, 모듈화된 코드의 테스트 커버리지를 97%까지 대폭 향상시켰습니다.

도입

본 발표는 Cisco Maro의 대규모 Ruby on Rails 모놀리스 애플리케이션이 직면한 과제와 이를 해결하기 위한 비즈니스 로직 분리 및 모듈화 전략을 다룹니다. Rails는 초기 탐색 단계에서는 민첩성을 제공했으나, 수백만 라인의 코드와 수백 명의 기여자가 참여하는 확장 단계에 이르러서는 오히려 개발을 방해하고 충분한 구조를 제공하지 못했습니다. 이에 발표자들은 Kent Beck의 3X 개발 수명 주기 모델(탐색, 확장, 추출)을 기반으로 애플리케이션의 현재 위치를 파악하고, 복잡성을 줄이며 테스트 용이성을 높이기 위한 접근 방식을 모색했습니다.

Cisco Maro의 애플리케이션은 2006년 Rails 1.0으로 시작하여 2022년에는 5백만 라인 이상의 Ruby 코드와 600명 이상의 월별 활성 기여자를 가진 거대한 모놀리스로 성장했습니다. 이러한 급격한 확장 과정에서 초기 개발 시 확립되지 않았던 Rails 베스트 프랙티스와 맞물려 다음과 같은 문제점이 발생했습니다.

주요 문제점

  • 높은 복잡성: 대규모 모델 및 컨트롤러로 인해 코드 이해, 변경, 테스트가 어려워졌습니다.

  • 낮은 테스트 커버리지: 복잡한 구조로 인해 테스트 작성이 부담이 되어 수동 테스트 의존도가 높아졌습니다.

  • 낮은 응집도 및 높은 결합도: 비즈니스 로직이 컨트롤러, 뷰, 모델에 산재하여 특정 도메인에 대한 책임이 불분명해졌습니다.

  • 협업의 어려움: 조직 전체의 합의 없이는 코드 개선이 어려워 팀의 자율성이 저해되었습니다.

해결 전략: 비즈니스 로직 모듈화

이러한 문제를 해결하기 위해, 발표자들은 Rails의 전통적인 MVC 아키텍처를 넘어 비즈니스 로직을 Rails 컨스트럭트로부터 분리하는 모듈화 접근 방식을 채택했습니다. 이는 궁극적으로 복잡성을 줄이고 테스트 용이성, 팀의 자율성 및 책임감을 높이는 것을 목표로 합니다.

  1. 컨트롤러에서 비즈니스 로직 추출:
    • 컨트롤러 내의 복잡한 액션들을 UpdateWaterTankSettings와 같은 작고 테스트하기 쉬운 순수 Ruby 객체(PORO)로 분리했습니다.
    • 결과적으로 컨트롤러는 HTTP 요청 처리 및 응답 전송에만 집중하게 됩니다.
  2. 뷰(ERB)에서 비즈니스 로직 추출:
    • ERB 템플릿 내에 혼재된 비즈니스 로직을 CoffeeMachineConfiguration과 같은 PORO로 옮겼습니다.
    • 이를 통해 뷰 테스트의 어려움을 해소하고, 로직에 대한 커버리지 및 복잡도 측정이 용이해졌습니다.
  3. 모델에서 비즈니스 로직 추출:
    • 모델이 코드를 끌어당기는 자석(junk drawer)이 되는 것을 방지하기 위해 broadcast_details와 같은 핵심 로직을 CoffeeMachineBroadcastDetails와 같은 별도의 클래스로 분리했습니다.
    • 이는 모델 속성과의 암묵적 결합을 줄이고, 테스트 용이성을 높이며, 코드의 응집도를 향상시킵니다.

도메인 기반 조직화

추출된 순수 Ruby 객체들은 domain/coffee_machine과 같은 도메인별 디렉토리 및 네임스페이스에 배치됩니다. 이는 팀이 특정 도메인에 대한 소유권을 가지고, 조직 전체의 합의 없이도 코드 개선을 실험하고 책임감을 가질 수 있도록 합니다. 각 팀은 도메인 디렉토리 내에서 코드 조직 방식(예: 서브도메인 또는 서비스/시리얼라이저 패턴)을 자율적으로 결정할 수 있습니다.

결론

이러한 모듈화 전략은 Cisco Maro의 개발 생산성에 상당한 긍정적 영향을 미쳤습니다. 2019년 46%에 불과했던 테스트 커버리지는 2022년 모듈화 프로젝트 시작 후 97%로 급증했으며, 모듈화된 코드의 평균 메서드 복잡도는 기존 코드 대비 30% 감소했습니다. 이는 코드의 이해, 변경, 테스트를 훨씬 용이하게 만들었습니다. 또한, 문제 발생 시 책임 팀을 명확히 파악할 수 있어 신속한 대응이 가능해졌습니다. 비록 팀 자율성 부여로 인한 일부 도전 과제(예: 전역 공간 오염)가 있었지만, 도메인 경계를 명확히 하고 비즈니스 로직을 분리하는 접근 방식은 대규모 Rails 애플리케이션의 지속 가능한 성장을 위한 필수적인 전략임을 입증했습니다.

관련 글들

대규모 Rails 애플리케이션의 비즈니스 로직 분리 및 모듈화 전략

대규모 Rails 애플리케이션의 복잡성과 테스트 용이성 문제를 해결하기 위해 비즈니스 로직을 Rails 컨스트럭트로부터 분리하고 모듈화하는 전략을 제시합니다.

07/24 읽어보기 →

모듈형 모놀리스의 신화: 대규모 Rails 애플리케이션의 인간적, 문화적 문제

대규모 Rails 모놀리스의 근본적인 문제는 아키텍처 변경이 아닌 조직의 문화와 인간적 요소에 있으며, 모듈화는 이러한 문제를 해결하는 만능 해결책이 아닙니다.

11/10 읽어보기 →

사일런트 킬러: 위기에서 얻은 교훈

성장하는 Rails 애플리케이션에서 발생하는 숨겨진 문제인 '사일런트 킬러'와 그 원인인 안티패턴을 다룹니다.

07/24 읽어보기 →

GitHub UI 아키텍처 7년 반의 교훈: 네이티브 기준, 추상화의 역설, 그리고 프론트엔드 비용

네이티브 앱 경험이 새로운 UI 기준이 되고 있으며, 웹은 이에 맞춰 '앱과 같은' 경험을 제공해야 합니다.

10/06 읽어보기 →

댓글 0

로그인이 필요합니다

댓글을 작성하거나 대화에 참여하려면 로그인이 필요합니다.

로그인 하러 가기

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!