우리는 계속해서 같은 비교를 듣고 있습니다:

Harper는 Ruby on Rails와 비슷하게 느껴집니다.

이 비교는 포지셔닝 전략을 위해 만들어진 것이 아닙니다. 우리는 회의실에 앉아 Harper를 Rails처럼 들리게 하려고 애쓴 것이 아닙니다. 이 말은 Harper로 개발할 때 무엇이 다르게 느껴지는지를 설명하려는 개발자, 어드바이저, 분석가, 그리고 기술 리더들로부터 나온 것입니다.

그리고 이 말을 들으면 들을수록, 그 요점은 더욱 명확해집니다.

이 비교는 Ruby에 관한 것이 아닙니다. MVC에 관한 것도 아닙니다. CRUD 앱을 위한 스캐폴딩 (Scaffolding)을 하거나 JavaScript로 Rails를 재현하는 것에 관한 것도 아닙니다.

이것은 제품 철학 (Product philosophy)에 관한 것입니다.

Rails가 승리한 이유는 확고한 철학 (Opinions)이 있었기 때문입니다.

Rails는 개발자들을 위해 선택을 내렸습니다. 팀들에게 일관된 구축 방식을 제공했습니다. 아이디어에서 작동하는 애플리케이션으로 나아가는 데 필요한 아키텍처 결정 (Architectural decisions)의 수를 줄였습니다. 적절한 제약 (Constraints)이 훌륭한 개발자를 더 빠르게 만들 수 있다는 것을 증명했습니다.

소프트웨어 개발이 또 다른 큰 변화의 시기에 진입하고 있기 때문에, 이 교훈은 다시 한번 중요해졌습니다.

AI는 구현 결정 (Implementation decisions)을 누가, 혹은 무엇이 내리는지를 바꾸고 있습니다. 에이전트 (Agents)가 코드를 생성하고, 서비스를 서로 연결하며, 워크플로우 (Workflows)를 만들고, 팀을 대신하여 아키텍처 선택을 하기 시작했습니다. 그런 세상에서 철학이 담긴 시스템 (Opinionated systems)은 가치가 낮아지는 것이 아니라 더욱 높아집니다.

인간이 소프트웨어를 구축할 때, 좋은 관습 (Conventions)은 결정 피로 (Decision fatigue)를 줄여줍니다.

AI 에이전트가 소프트웨어를 구축할 때, 좋은 관습은 가드레일 (Guardrails)이 됩니다.

관습은 무엇이 생성될지, 조각들이 어떻게 맞물릴지, 그리고 결과물이 일관된 애플리케이션이 될지 아니면 단순히 작동하는 부품들의 더미가 될지를 결정합니다.

이것이 바로 Harper가 계속해서 Rails와 비교되는 이유입니다.

Rails와 마찬가지로, Harper는 너무 파편화되어 버린 스택의 한 부분인 분산 애플리케이션 인프라 (Distributed application infrastructure)에 철학적이고 통합된 모델을 가져옵니다.

Rails는 경로를 명확하게 만들었습니다

Rails는 일반적인 경로를 명확하게 만듦으로써 웹 개발을 변화시켰습니다.

Rails 이전에는 모든 프로젝트가 수많은 질문의 바다 속에서 시작되었습니다. 어떤 ORM을 사용할 것인가? 어떤 템플릿 엔진 (templating engine)을 사용할 것인가? 디렉토리는 어떻게 구조화해야 하는가? URL은 코드와 어떻게 매핑되어야 하는가? 설정 (configuration)은 어디에 위치해야 하는가? 의존성 (dependencies)은 어떻게 관리해야 하는가? 테스트는 어떻게 구성해야 하는가? 데이터베이스 스키마 (database schema)는 어떻게 진화해야 하는가?

Rails는 기본값 (defaults)을 통해 그 질문들에 답했습니다.

Active Record. ERB. 라우팅 컨벤션 (Routing conventions). 설정 패턴 (Configuration patterns). 마이그레이션 (Migrations). 테스트 기본값 (Testing defaults). 프로젝트 구조. 그리고 각 요소들이 함께 작동하게 만드는 명명 규칙 (Naming rules).

그것이 바로 돌파구였습니다.

Rails는 개발자들에게 무한한 유연성을 제공함으로써 속도를 높인 것이 아닙니다. 의미 없는 유연성을 줄임으로써 속도를 높였습니다. 대부분의 팀이 처음부터 직접 내릴 필요가 없는 결정들을 제거해 주었습니다.

최고의 개발자들에게는 여전히 커스터마이징할 여지가 남아 있었습니다. 하지만 그들은 백지 상태가 아닌, 일관성 있는 시스템에서 시작할 수 있었습니다.

그것이 바로 "설정보다 관습 (convention over configuration)"이 우리에게 실제로 준 것입니다: 속도, 명확성, 그리고 공유된 이해입니다.

그 마법은 단지 Ruby 때문만은 아니었습니다. 단지 MVC 때문만도 아니었습니다. 어떤 단일 추상화 (abstraction) 때문도 아니었습니다.

그 마법은 Rails가 애플리케이션 개발을 하나의 통합된 경험처럼 느끼게 만들었다는 점에 있었습니다.

스택이 프레임워크가 되다

현대적인 애플리케이션은 프레임워크를 중심으로 변화해 왔습니다.

Rails는 애플리케이션 계층 (application tier)의 더 많은 부분을 프레임워크 자체로 통합해 왔습니다. Rails 8과 Solid 스택 (Solid stack)이 완벽한 예시입니다. 캐시 (Cache), 큐 (queue), 작업 (jobs), 실시간 업데이트 (real-time updates), 라우팅 (routing), 인증 패턴 (authentication patterns), 그리고 배포 (deployment)가 모두 더 통합되고, 더 관습적이며, 별도의 서비스에 대한 의존성을 줄이는 방향으로 발전했습니다.

그것이 바로 작동하고 있는 Rails의 철학입니다.

하지만 데이터 계층 (data tier)은 여전히 다릅니다.

Rails가 애플리케이션 경험 속으로 더 많은 인프라를 흡수하더라도, 데이터베이스는 여전히 별도의 프로세스입니다. 종종 별도의 머신(machine)이기도 합니다. 규모가 커지면 별도의 리전(region)이 될 수도 있습니다. 그리고 애플리케이션의 더 많은 부분이 데이터베이스 기반의 프리미티브(primitives)에 의존함에 따라, 시스템의 더 많은 경로가 동일한 경계(boundary)를 통과하게 됩니다.

Solid Cache는 많은 경우 Redis의 필요성을 제거하지만, 여전히 캐시 데이터를 데이터베이스에 저장합니다. Solid Queue는 별도의 큐(queue) 서비스의 필요성을 제거하지만, 작업(jobs)은 여전히 데이터베이스에 저장됩니다. Solid Cable은 실시간 메시징을 Rails 패턴으로 가져오지만, 백킹 상태(backing state)는 여전히 데이터베이스에 존재합니다.

그러한 통합은 승리입니다. Rails는 이미 생태계를 더 적은 외부 서비스와 더 강력한 기본값(defaults)을 향해 이동시켰습니다.

하지만 이는 또한 Rails가 스스로 완전히 닫을 수 없는 경계를 드러냅니다:

앱 계층(app tier)과 데이터 계층(data tier)은 여전히 네트워크 홉(network hop)에 의해 분리되어 있습니다.

데이터가 필요한 모든 요청이 이를 가로지릅니다. 모든 쿼리(query)가 이를 가로지릅니다. 데이터베이스에 의존하는 모든 작업(job), 캐시 읽기, 메시지, 그리고 업데이트가 이를 가로지릅니다. 복제본(replicas)과 멀티 리전 배포(multi-region deployments)는 확장성과 회복 탄력성(resilience)을 향상시킬 수 있지만, 토폴로지(topology)를 더 복잡하게 만들기도 합니다.

이것이 결정 피로(decision fatigue)의 다음 단계입니다.

개발자는 더 이상 단순히 앱을 어떻게 구조화할지만 묻지 않습니다. 데이터가 어디에 있어야 하는지, 로직이 어디에서 실행되어야 하는지, 각 요청이 얼마나 멀리 이동해야 하는지, 상태(state)가 리전 간에 어떻게 이동하는지, 그리고 데이터 경계가 확장될 때 시스템이 어떻게 작동하는지를 묻게 됩니다.

Rails는 앱 계층을 일관성 있게 만들었습니다.

데이터 계층은 남겨진 개척지입니다.

[

]

AI는 잘못된 기본값의 비용을 높입니다

이 문제는 AI 시대에 더욱 날카로워집니다.

AI 에이전트(AI agents)는 코드를 생성하는 데 매우 능숙합니다. 이들은 엔드포인트(endpoints)를 생성하고, 함수를 작성하며, 스키마(schemas)를 만들고, 서비스를 연결하며, 아키텍처(architectures)를 빠르게 제안할 수 있습니다.

하지만 강력한 컨벤션(conventions)이 없다면, 이들은 기술적으로는 작동하지만 아키텍처적으로는 무질서하게 퍼져 있는(sprawl) 시스템을 만들 수도 있습니다.

에이전트는 서비스가 합리적으로 보인다는 이유로 서비스를 추가할 수 있습니다. 성능이 중요하니까 캐시(cache)를 추가합니다. 비동기 작업(async work)이 필요하니까 큐(queue)를 추가합니다. 상태(state)를 어딘가에 저장해야 하니까 테이블(table)을 추가합니다. 무언가가 다른 무언가를 호출해야 하니까 또 다른 API를 추가합니다.

매우 빠르게, 애플리케이션은 생성된 부품들의 집합체가 되어버립니다.

이 지점에서 Rails의 교훈이 새롭게 중요해집니다.

Rails는 인간 개발자에게 잘 닦인 길(paved path)을 제공했습니다. AI 네이티브 개발에는 그보다 훨씬 더 잘 닦인 길이 필요합니다.

에이전트가 더 많은 구현 결정(implementation decisions)을 내리게 될 것이라면, 플랫폼은 더 나은 아키텍처 기본값(architectural defaults)을 인코딩해야 합니다. 데이터, 로직(logic), 메시징(messaging), 캐싱(caching), 그리고 로컬리티(locality)에 관한 결정을 가이드해야 합니다. 파편화된 경로보다 일관된 경로를 더 쉽게 만들어야 합니다.

AI는 주관이 뚜렷한 플랫폼(opinionated platforms)의 필요성을 없애지 않습니다.

오히려 그 필요성을 증가시킵니다.

왜 Harper가 계속해서 Rails와 비교되는가

Harper는 Rails가 아닙니다.

Ruby 프레임워크도 아닙니다. MVC를 재현하려는 것도 아닙니다. Rails 개발자들에게 Rails를 위대하게 만들었던 것들을 버리라고 요구하는 것도 아닙니다.

이 비교는 문자 그대로의 것이 아니라 철학적인 것입니다.

Rails는 웹 애플리케이션 개발에 컨벤션(convention), 통합(integration), 그리고 일관된 개발자 경험(developer experience)을 가져왔습니다. Harper는 동일한 철학을 분산 애플리케이션 인프라(distributed application infrastructure)에 가져옵니다.

Harper는 데이터베이스(database), 캐싱(caching), 메시징(messaging), 그리고 애플리케이션 로직(application logic)을 하나의 고성능 런타임(runtime)으로 결합하는 통합 애플리케이션 플랫폼입니다. 팀들이 각 백엔드 관심사(backend concern)를 위해 별도의 시스템을 조립하도록 강요하는 대신, Harper는 개발자들에게 분산 애플리케이션을 구축하고 실행할 수 있는 더 통합된 방식을 제공합니다.

그것이 바로 Rails와 같은 느낌이 드는 이유입니다.

Rails는 애플리케이션이 일관되게 느껴지도록 만들었습니다.

Harper는 분산 백엔드가 일관되게 느껴지도록 만듭니다.

Rails는 웹 앱을 구축하는 데 필요한 결정의 수를 줄였습니다.

Harper는 분산 앱을 구축하는 데 필요한 시스템의 수를 줄입니다.

Rails는 개발자에게 생산적인 기본 경로 (default path)를 제공했습니다.

Harper는 개발자와 AI 에이전트에게 데이터, 로직, 메시지 및 캐싱 (caching)을 위한 더 강력한 아키텍처 경로를 제공합니다.

이것이 바로 Node.js와 JavaScript 기반이 비교의 장벽이 되지 않는 이유이기도 합니다. 개발자들이 Harper가 Rails처럼 느껴진다고 말하는 것은 그것이 Ruby라고 생각해서가 아닙니다. Rails가 옳았던 부분, 즉 확고한 철학 (strong opinions), 통합된 기본 요소 (integrated primitives), 그리고 사용자를 대신해 더 나은 결정을 내림으로써 더 빠르게 움직일 수 있도록 돕는 시스템을 경험이 상기시키기 때문입니다.

JavaScript는 단순히 그 모델을 현대적인 애플리케이션 생태계에서 사용할 수 있게 만듭니다. 이는 팀에게 Node.js 코드를 실행하는 것 이상의 훨씬 더 많은 일을 수행하는 플랫폼 내부에서 로직을 작성할 수 있는 친숙한 언어를 제공합니다.

중요한 것은 Harper가 JavaScript로 구축되었다는 점이 아닙니다.

중요한 것은 Harper가 철학 (opinions)을 가지고 구축되었다는 점입니다.

차이점은 더 적은 이음새 (Fewer Seams)

커머스 애플리케이션을 생각해 보십시오.

제품 페이지는 빠르고, 동적이며, 개인화되어야 하고, 전 세계적으로 사용 가능해야 하기 전까지는 단순해 보입니다.

어떤 콘텐츠는 안정적입니다: 제품 설명, 이미지, 사양, 편집 문구 등입니다. 어떤 콘텐츠는 끊임없이 변합니다: 가격, 재고, 프로모션, 추천, 로열티 상태, 배송 예상 시간, 그리고 고객별 맞춤 혜택 등입니다.

전통적인 해답은 이러한 관심사 (concerns)를 점점 커지는 스택 (stack) 전체에 분산시키는 것입니다.

앱은 요청을 처리합니다. 데이터베이스는 신뢰할 수 있는 원천 (source of truth)을 저장합니다. 캐시 (cache)는 빈번한 읽기 (hot reads)를 가속화합니다. 큐 (queue)는 업데이트를 처리합니다. 워커 (workers)는 변경 사항을 처리합니다. CDN은 가능한 것을 캐싱합니다. 커스텀 무효화 (invalidation) 로직은 모든 것이 사용자에게 잘못된 정보를 전달하지 않도록 노력합니다.

다시 말씀드리지만, 이 도구들 중 나쁜 것은 하나도 없습니다.

하지만 팀은 더 이상 단순히 제품 페이지를 만드는 것이 아닙니다. 분산 조정 시스템 (distributed coordination system)을 유지 관리하고 있는 것입니다.

더욱 의견이 명확한(opinionated) 플랫폼은 문제의 형태 자체를 바꿉니다. 데이터, 로직, 메시징, 캐싱을 하나의 런타임에서 처리할 수 있게 됩니다. 애플리케이션 동작을 데이터에 더 가깝게, 사용자에게 더 가깝게 배치할 수 있습니다. 업데이트가 발생해도 모든 팀이 자신만의 조정 계층(coordination layer)을 재구축할 필요 없이 시스템 전체를 통해 이동할 수 있습니다.

그 가치는 단순히 도구가 적다는 것이 아닙니다.

그 가치는 '접합부(seams)'가 적다는 것입니다.

개발자가 제품 개발을 멈추고 인프라 설계에 착수해야 하는 지점이 줄어듭니다. AI 에이전트가 기술적으로는 합리적이지만 아키텍처적으로는 복잡한 선택을 할 수 있는 지점이 줄어듭니다. 성능, 일관성, 그리고 개발자 속도(developer velocity)가 기본적으로 서로 상충되는 지점이 줄어듭니다.

이것이 Rails 개발자들이 '아, 알겠다'고 느끼는 순간입니다.

Rails가 웹 애플리케이션 구축에 마법처럼 느껴졌던 이유와 동일한 이유로, 의견이 명확한 분산 런타임(opinionated distributed runtime)은 지금 강력하게 느껴집니다.

이는 개발자에게 하나의 경로를 제공합니다.

[

](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fic87gi58o3ds25u78e4z.png