Does Hypermedia Scale?

htmx와 하이퍼미디어에 대해 종종 듣는 반론 중 하나는 다음과 같은 변형된 주장입니다:

“작은 규모에서는 잘 작동할지 모르지만, 확장성에는 문제가 있을 것이다.”

우리를 에세이 소재로 자극하는 것은 언제나 위험한 일이기 때문에, 이번 기회에 이 주장을 좀 더 파헤쳐서 하이퍼미디어 기반 애플리케이션 (HDA)이 확장 가능할지 여부에 대해 알아보겠습니다.

#확장성

먼저 “확장성“이라는 용어를 정의하고, 이 단어가 개발에서 사용될 수 있는 맥락들을 살펴보겠습니다. 소프트웨어 맥락에서 확장성은 일반적으로 소프트웨어가 “더 큰” 것들을 처리할 수 있는 능력을 의미합니다. 이러한 “더 큰” 것들은 다음과 같습니다:

• 일반적인 시스템에서 더 많은 노드
• 더 많은 사용자 요청 (개별 애플리케이션의 성능 확장)
• 더 많은 기능 (코드베이스의 확장)
• 더 복잡한 기능
• 더 많은 개발자 (팀 규모의 확장)

이 확장성의 각 측면에 대해 HDA와 관련된 분석이 필요합니다.

#일반적인 노드 확장

개발자가 자신의 애플리케이션에 대한 결정을 내릴 때는 크게 관심이 없는 부분일 수 있지만, 웹은 분산 네트워킹 시스템으로서 엄청나게 잘 확장되었다는 점을 언급할 필요가 있습니다. 이것은 제가 알고 있는 가장 성공적인 분산 시스템입니다.

이것은 개별 애플리케이션 개발자에게는 관심이 없을 수 있지만, 하이퍼미디어가 확장 가능하다는 점을 잘 보여줍니다.

#애플리케이션 성능 확장

하이퍼미디어가 성능 측면에서 잘 확장될 수 있을까요? 이 질문에 답하기 위해, 먼저 성능 확장이 가능한 소프트웨어의 특성을 살펴보겠습니다. 이러한 특성에 대한 권위 있는 출처는 없지만, 소프트웨어 확장 경험이 있는 대부분의 엔지니어들은 이 목록에 있는 대부분의 항목들이 최소한 도움이 된다는 데 동의할 것입니다:

• 소프트웨어는 _무상태_이어야 한다.
• 소프트웨어는 _수평 확장_을 지원해야 한다.
• 소프트웨어의 기능은 _독립적_이어야 한다.
• 시스템의 성능은 _관찰 가능_해야 한다.
• 소프트웨어는 캐싱을 활용해야 한다.

다행스럽게도, 적절하게 설계된 하이퍼미디어 시스템은 이러한 모든 특성을 가질 수 있습니다.

무상태성은 Roy Fielding이 웹을 설명하기 위해 만든 REST-ful 아키텍처의 제약입니다. 실무에서는 많은 하이퍼미디어 기반 애플리케이션이 _세션 쿠키_를 사용하여 서버 측에 소량의 상태를 관리하지만, 이는 확장성 애플리케이션에서 치명적이지 않은 것으로 잘 알려진 기술입니다.

수평 확장은 하이퍼미디어 기반 애플리케이션에서 오랜 역사를 가지고 있으며, 대부분의 하이퍼미디어 기반 애플리케이션의 무상태 특성과 잘 맞아떨어집니다. 초기 PAAS 제공업체인 Heroku (영광의 기억으로)는 예를 들어 레일스 기반 애플리케이션의 수평 확장을 쉽게 제공했습니다.

기능 독립성은 HDA의 또 다른 강점입니다. HDA에서는 화면을 위한 엔드포인트가 일반적인 JSON API와 다르게 독립적으로 존재하는 경향이 있습니다. 이는 이러한 엔드포인트들이 서로 독립적으로 모니터링, 진화 및 조정될 수 있음을 의미합니다. 우리는 이러한 종류의 엔드포인트를 조정하여 100밀리초 이하의 응답 시간을 만드는 오랜 역사를 가지고 있습니다 (예: SQL 튜닝을 통해 특정 엔드포인트에 대한 데이터베이스 쿼리를 최소화).

뷰를 지원하는 다양한 엔드포인트의 독립성을 바탕으로 플랫폼 성능을 쉽게 모니터링하고 이해할 수 있습니다. 일반화된 JSON API가 애플리케이션 전체에서 여러 방식으로 액세스되는 것과 달리, HDA에서는 특정 뷰에 대해 하이퍼미디어를 구성하는 UI 특정 엔드포인트가 있습니다. 성능 문제를 유발하는 원인을 파악하는 것은 서버 측에서 뷰가 구성되고 요청이 간단한 하이퍼미디어 교환을 통해 구동될 때 훨씬 쉬워집니다.

마지막으로, 웹 애플리케이션은 캐싱의 오랜 역사를 가지고 있습니다. HTTP는 브라우저에서 헤더로 제어되는 캐싱을 제공합니다. 레일스와 같은 성숙한 서버 측 프레임워크는 컨트롤러 레벨에서 정교한 캐싱을 제공합니다. 캐싱은 HDA에 있어 매우 자연스러운 작업입니다.

이 모든 것들이 결합되어 HDA를 성능 관점에서 매우 확장 가능하게 만듭니다. 사용자 로드가 증가함에 따라 HDA를 확장할 수 있는 검증된 성능 기술이 존재합니다.

HDA 접근 방식이 서버 측에 더 많은 계산을 밀어 넣을까요? 어느 정도는 그렇습니다. 그러나 특정 리소스에 대한 JSON 표현과 HTML 표현 간의 차이는 일부 사람들이 생각하는 것만큼 크지 않습니다. 특히 htmx 기반 애플리케이션에서 일반적으로 HTML 요청에 헤더와 푸터 정보를 포함하지 않는 경우에는 더욱 그렇습니다. 네트워크 지연 시간과 데이터 저장소 액세스가 일반적으로 요청 시간의 대부분을 차지하며, SQL(또는 유사한 서버 측 쿼리 언어)을 사용할 수 있는 능력은 요청의 해당 측면을 최적화할 기회를 제공합니다.

HDA는 또한 “뷰당 하나의 요청“이 최적의 상태를 자연스럽게 가지며, 이는 HDA에서 요청이 곧 뷰이기 때문입니다.

#기능 수에 따른 확장

HDA는 일반적인 JSON 데이터 API가 아니라 UI 요구에 의해 구동되는 독립적인 엔드포인트를 갖는 경향이 있기 때문에, 기능 수에 따른 확장은 일반적으로 매우 쉽습니다. 서버 측에서 합리적인 모델-뷰-컨트롤러(MVC) 분할이 이루어진다고 가정하면, 컨트롤러와 모델은 서로 독립적인 경우가 많습니다. 기능들이 실제로 겹치는 경우에도, 기능을 서버 측에서 개발하고 테스트하는 것이 더 통제 가능하고 테스트하기 쉬운 환경을 제공합니다.

뷰는 거의 모든 서버 측 템플릿 라이브러리에서 찾을 수 있는 서버 측 포함 기능을 통해 재사용할 수 있거나, 상호 의존성을 피하기 위해 별도로 유지 관리할 수 있습니다.

결론적으로, 합리적인 애플리케이션 아키텍처를 갖추고 있다면, HDA는 애플리케이션 내 기능 수가 증가함에 따라 매우 잘 확장될 수 있습니다. 특히 이 기능들이 본질적으로 서로 독립적일 경우 더욱 그렇습니다.

#기능 복잡도에 따른 확장

기능 수에 따른 확장은 어느 정도 _수평 확장_과 유사합니다. 즉, 기능이 상대적으로 독립적이라면 문제없이 확장될 것입니다. (그리고 그렇지 않더라도, HDA는 종종 다른 옵션들보다 더 잘 확장될 수 있습니다.)

그러나 깊은 기능, 즉 자체적으로 복잡한 기능에 대해서는 어떨까요?

여기서는 깊은 기능을 두 가지 범주로 나눠서 살펴봐야 합니다:

• 서버 측 깊은 기능
• 클라이언트 측 깊은 기능

서버 측 깊은 기능에 대해서는, HDA가 종종 훌륭한 선택이 됩니다. 예를 들어, AI 채팅봇과 같은 기능은 매우 복잡한 서버 측 기능이지만, 사용자와의 상호작용은 간단한 텍스트 인터페이스를 통해 이루어집니다. AI 채팅봇 중 많은 수가 htmx를 사용해 구축되었으며, 많은 사람들이 그 간단함에 대해 놀라워하고 있습니다.

반면, 깊은 클라이언트 측 기능에 대해서는 HDA가 항상 최선의 선택이 아닐 수 있습니다. 이 주제에 대한 자세한 내용은 언제 하이퍼미디어를 선택해야 하는가라는 에세이에서 다루고 있습니다. 그 요약은 다음과 같습니다: 만약 UI가 많은 이벤트에 빠르게 반응해야 하거나 (예: 지도 뷰 드래그) 또는 대량의 하이퍼미디어 교환으로 업데이트할 수 없는 상당한 상호 UI 종속성을 가지고 있다면 (예: 스프레드시트 애플리케이션), 하이퍼미디어 접근 방식은 잘 작동하지 않을 것입니다.

그러나 두 가지를 언급하고 싶습니다:

• 보다 복잡한 프론트엔드 동작을 HDA 애플리케이션 내에서 _래핑_하고 이벤트를 통해 통합하는 것이 종종 가능합니다.
• 복잡한 프론트엔드 기능에 대해 “아니요“라고 말하거나, 적어도 복잡한 프론트엔드 프레임워크에서 발생하는 추가 복잡성을 수반하지 않는 단순한 구현이 받아들일 만한지 고려해보는 것이 좋습니다.

#팀 확장

마지막으로 고려할 확장성의 측면은 개발 팀의 규모를 확장하는 것입니다. 여기서는 불행히도 더 주관적이고 일화적인 측정에 의존해야 합니다.

우리의 경험(그리고 다른 사람들의 경험)으로 볼 때, HDA는 더 적은 개발자로 더 많은 것을 성취할 수 있게 해주는 경향이 있습니다. 또한 프론트엔드와 백엔드의 분리를 없애고, 이 분리로 인해 발생하는 커뮤니케이션 마찰도 제거합니다. 개발자들은 전체 기능에 대한 책임을 지게 되기 때문입니다. 일부 사람들은 프론트엔드와 백엔드의 분할을 좋아하며, 이는 팀이 독립적으로 운영되기 때문에 팀 확장이 더 잘 이루어진다고 생각할 수 있습니다.

우리는 동의하지 않습니다. 대부분의 웹 애플리케이션에서 프론트엔드와 백엔드는 본질적으로 연결되어 있으며, 따라서 가장 좋은 접근 방식은 이 연결성을 수용하고 변화에 잘 대응할 수 있도록 설계된 아키텍처를 채택하는 것입니다. 하이퍼미디어 접근 방식이 바로 그런 아키텍처입니다(균일한 인터페이스를 통해).

HDA가 100명 이상의 팀으로 확장될 수 있을까요? 이에 대해서는 우리가 그런 시나리오를 본 적이 없기 때문에 확답할 수 없습니다. 하지만 10명 단위로 확장될 수 있다는 것은 확실합니다. 우리는 이 접근 방식이 훨씬 더 크게 확장될 수 있을 것이라고 _상상_할 수 있습니다(결국 웹 1.0 시대에 그랬으니까요). 하지만 이 시점에서는 추측일 뿐입니다.

어차피 우리는 작은 팀을 선호합니다. 10명의 개발자면 어떤 애플리케이션에도 충분할 것입니다.

#결론

이 모든 것을 종합해 보면, 하이퍼미디어 기반 애플리케이션의 확장성과 관련하여 다음과 같은 결론을 내릴 수 있습니다:

HDA는 성능과 기능 수에 대해 매우 잘 확장될 수 있습니다. 기능 복잡성에 대해서는 주의할 점이 있지만 확장될 수 있습니다. 그리고 마지막으로, 팀 규모의 확장성에 대해서는 아직 확실한 결론이 나지 않았지만, HDA 접근 방식이 팀을 더 작게 유지하고 팀 간의 커뮤니케이션 마찰을 줄이는 경향이 있다는 것을 알 수 있습니다.