서비스 객체의 형태와 누락된 아이디어

Ivan Nemytchenko, "The Curse of Service Objects"

작성자
EuRuKo
발행일
2025년 01월 13일

핵심 요약

  • 1 Ruby on Rails 서비스 객체는 복잡성 관리의 표준이지만, 발표자는 이를 '가짜 개념'으로 규정하고 기존 방식의 비효율성을 지적합니다.
  • 2 코드 토폴로지 표기법을 활용하여 서비스 객체가 내부로 복잡성을 증대시키는 문제를 시각화하고, 이는 최적의 방식이 아님을 강조합니다.
  • 3 대신, 코드의 '작업 유형'에 따라 비즈니스 규칙, 뮤테이션, 컨트롤러 로직 등을 분리하여 진정한 계층형 아키텍처를 구축하고 모듈성을 높일 것을 제안합니다.

도입

본 강연은 Ruby on Rails 개발자이자 CTO인 발표자가 '서비스 객체(Service Object)'라는 개념에 대해 비판적인 시각을 제시하며 시작합니다. 발표자는 Rails 애플리케이션에서 복잡성을 조직하는 사실상의 표준인 서비스 객체가 실제로는 '가짜 개념(fake concept)'이라고 주장합니다. 그는 자신이 고안한 '코드 토폴로지 표기법(Code Topology Notation)'을 활용하여 코드의 복잡성을 시각적으로 표현하고, 이를 바탕으로 서비스 객체의 본질적인 형태와 그 안에 담겨야 할 '누락된 아이디어'를 탐구하고자 합니다.

발표자는 개발자들이 서비스 객체를 “그냥 무언가를 하는 것”으로 인식하며, 일반적인 서비스 객체의 형태는 생성자, 인자 없는 공개 메서드, 다수의 비공개 메서드를 포함한다고 설명합니다. 그는 GitLab 코드베이스 사례를 통해 서비스 객체 내부에서 복잡성이 ‘안쪽으로(inward)’ 성장하여 유지보수성을 저해하는 비효율성을 지적합니다. 이러한 문제 해결을 위해 발표자는 자신의 ‘Painless Rails’ 방법론을 제시합니다. 이 방법론은 계층형 아키텍처 실천, 단일 수준의 추상화 유지, 그리고 코드를 ‘작업 유형(types of work)’에 따라 다른 빌딩 블록으로 분리하는 세 가지 핵심 원칙에 기반합니다.

구체적인 리팩토링 예시를 통해 그는 서비스 객체가 수행하던 다양한 작업을 분리하는 과정을 설명합니다. 비즈니스 규칙은 모델의 메서드로, 데이터베이스 변경과 같은 ‘뮤테이션’은 ‘뮤테이터’라는 단일 책임의 함수 형태로 관리됩니다. ‘컨트롤러 로직’은 다시 컨트롤러로 복원됩니다. 이 과정을 거치면 원래의 서비스 객체는 저수준 작업을 직접 수행하지 않고, 모델, 뮤테이터, 메일러 등 다른 빌딩 블록들을 조율하는 ‘고수준의 오케스트레이터’ 역할만 수행합니다. 이러한 분리 전략은 코드의 모듈성을 높이고, 진정한 계층형 아키텍처를 복원하며, 각 빌딩 블록을 독립적으로 테스트하기 쉽게 만듭니다. 발표자는 기존 서비스 객체 방식이 ‘우발적 복잡성’을 초래하고 계층형 아키텍처를 파괴한다고 강조합니다.

더 나아가 발표자는 Martin Fowler와 Eric Evans의 ‘서비스 계층’ 및 ‘도메인 서비스’ 개념을 인용하며, 이들이 정의한 도메인 서비스의 특성(상태 없음, 활동 지향적 이름, 비즈니스 오퍼레이션 표현, 도메인 객체 조율, 트랜잭션 제어, 부수 효과 발생 가능성, 애플리케이션 로직 배제)을 ‘Fowler-Evans Ruler’로 명명합니다. 이 척도를 통해 서비스 객체의 적절성을 측정할 수 있으며, 척도에서 높은 점수를 받는 서비스 객체는 종종 단순한 함수로 대체될 수 있음을 시사합니다.

결론

결론적으로, 발표자는 '서비스 객체'라는 용어가 비어 있는 개념이므로 사용을 지양하고, 명확한 철학적 아이디어 없는 서비스 객체 사용을 자제할 것을 강력히 권고합니다. 대신, 개발자는 코드의 '작업 유형'에 따라 적절한 빌딩 블록을 식별하고 구성하는 데 집중해야 합니다. 그는 Fowler-Evans Ruler를 활용하여 자신의 서비스 객체가 진정한 '도메인 서비스'의 역할을 수행하는지 측정해 볼 것을 제안하며, 이 모든 정보와 자료는 'rails.services' 웹사이트에서 확인할 수 있다고 덧붙입니다. 궁극적으로 이 강연은 개발자들이 서비스 객체에 대한 피상적인 이해를 넘어, 코드의 본질적인 구조와 책임에 대한 깊이 있는 사고를 통해 더욱 견고하고 유지보수 가능한 애플리케이션을 구축하도록 독려합니다.

댓글 0

댓글 작성

0/1000
정중하고 건설적인 댓글을 작성해 주세요.

아직 댓글이 없습니다

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