루비 웹 프레임워크 'Hanami 3.0' 만개 — Rails 말고 다른 길을 가는 이유

무슨 일이냐면요

루비(Ruby)로 웹 서비스를 만든다고 하면 거의 다들 Rails(레일즈)를 떠올리죠. 실제로 루비 하면 Rails, Rails 하면 루비일 정도로 이 조합이 워낙 유명하니까요. 그런데 루비 진영에는 Rails와는 완전히 다른 철학을 가진 프레임워크들도 있어요. 그중 하나인 Hanami(하나미)가 이번에 3.0 버전을 내놨어요.

참고로 Hanami는 일본어로 '벚꽃 구경, 꽃놀이'라는 뜻이에요. 그래서 이번 릴리스 제목이 'In Full Bloom(만개)'인데, 프레임워크 이름이랑 딱 맞아떨어지는 재치 있는 말장난이죠. 벚꽃이 활짝 피었다는 건, 그만큼 이 프레임워크가 이제 완성된 모습에 도달했다는 자신감의 표현이기도 해요.

Rails랑 대체 뭐가 다른 거냐면

두 프레임워크의 차이를 이해하려면 'magic(마법)'이라는 단어를 알아야 해요. Rails는 "설정보다 관습(convention over configuration)"이라는 철학으로 유명한데요. 이게 뭐냐면, 개발자가 이것저것 일일이 안 적어도 Rails가 알아서 척척 연결해준다는 거예요. 예를 들어 클래스 이름만 규칙에 맞게 지으면 알아서 데이터베이스 테이블이랑 연결되고, 여러 기능이 자동으로 딸려 와요. 처음엔 정말 편하고 빠르거든요. 그런데 프로젝트가 커지면 문제가 생겨요. "이 값이 대체 어디서 튀어나온 거지?" 하고 추적하기가 점점 힘들어지는 거죠. 눈에 안 보이는 마법이 많을수록 디버깅이 어려워지니까요.

Hanami는 정반대 길을 가요. "암묵적인 것보다 명시적인 것(explicit over implicit)"을 택했거든요. 좀 귀찮더라도 필요한 걸 다 눈에 보이게 적으라는 거예요. 대표적인 게 의존성 주입(dependency injection)이라는 개념인데요. 이게 뭐냐면, 어떤 객체가 필요한 부품을 자기가 직접 만들어 쓰는 게 아니라, 밖에서 만들어서 넣어주는 방식이에요. 이렇게 하면 부품을 갈아 끼우기 쉬워지고, 특히 테스트할 때 가짜 부품을 넣어보기가 아주 편해져요. 코드끼리의 결합도(서로 얽혀있는 정도)가 확 낮아지는 거죠.

또 하나 특징적인 게 슬라이스(slice)예요. Rails에서는 앱이 커지면 코드가 한 덩어리로 뭉쳐서 관리가 힘들어지는데, Hanami는 하나의 앱 안에서 기능별로 독립된 구획을 나눠둘 수 있어요. 이걸 모듈러 모놀리스(modular monolith)라고 부르는데요. 지금은 한 덩어리로 편하게 개발하다가, 나중에 규모가 커져서 특정 기능을 별도 서비스로 떼어내고 싶을 때 훨씬 수월하게 분리할 수 있게 미리 선을 그어두는 거예요.

업계 흐름에서 보면

Hanami는 dry-rb라는 루비 라이브러리 생태계 위에 지어졌어요. 이 dry-rb 계열은 함수형 프로그래밍에서 영감을 받아서, 데이터를 예측 가능하게 다루고 부작용을 줄이는 걸 중요하게 여기는 도구 모음이거든요. 2.x 버전에서 이 기반 위에 컴포넌트 시스템과 슬라이스, 뷰 계층을 다시 지었고, 이번 3.0은 그 큰 그림이 드디어 완성 단계에 이르렀다는 의미로 볼 수 있어요.

이런 '명시적이고 구조적인' 흐름은 Hanami만의 얘기가 아니에요. 엘릭서(Elixir)의 Phoenix, 파이썬의 FastAPI, 그리고 요즘 여러 언어에서 유행하는 클린 아키텍처(clean architecture) 흐름도 다 비슷한 방향을 보고 있어요. "편한 마법"보다 "명확한 구조"를 선호하는 개발자들이 점점 늘고 있다는 신호인 거죠. Rails가 여전히 압도적 대세인 건 맞지만, 대규모 서비스를 오래 유지보수해본 팀일수록 이런 대안에 관심을 갖게 되거든요.

한국 개발자에게 주는 시사점

솔직히 한국에서는 웹 백엔드로 Spring이나 Node.js를 훨씬 많이 쓰고, 루비 자체가 흔하진 않아요. 그래서 "당장 Hanami를 도입하세요"라고 말하긴 어려워요. 하지만 이 프레임워크는 아키텍처 공부 교재로는 정말 훌륭해요. 의존성 주입, 클린 아키텍처, 모듈러 모놀리스 같은 개념은 언어를 안 가리고 통하는 원리거든요. Spring 쓰는 분들한테도 익숙한 이야기일 거예요. Hanami가 이걸 어떻게 프레임워크 차원에서 녹여냈는지 구경해보면, 내가 쓰는 언어에서도 "아 이렇게 구조를 잡으면 되겠구나" 하는 힌트를 얻을 수 있어요.

특히 마법에 익숙해진 나머지 "왜 이게 되는지"는 모르고 넘어가는 주니어라면, 모든 걸 명시적으로 적게 하는 Hanami의 접근을 한번 들여다보는 것만으로도 프레임워크의 속을 이해하는 눈이 트일 수 있어요.

한줄 정리: Hanami 3.0은 '편한 마법'이 아니라 '명확한 구조'를 택한 루비 프레임워크로, 대규모 앱을 오래 건강하게 유지하는 법에 대한 좋은 답안지예요.

여러분은 개발할 때 알아서 척척 해주는 '마법'이 좋은가요, 아니면 좀 귀찮아도 다 눈에 보이는 '명시적' 방식이 마음 편한가요? 프레임워크의 마법 때문에 디버깅으로 고생한 경험이 있다면 들려주세요.