htmx로 SPA 없이 동적 웹 개발 혁신: 새로운 접근 방식 심층 분석

복잡한 SPA 없이도 강력한 동적 웹 애플리케이션을 구축하는 htmx의 혁신적인 접근 방식을 심층 분석합니다. 기존 SPA 프레임워크와 비교하여 htmx의 장단점, 핵심 원리, 실제 적용 사례를 살펴봅니다.

htmx로 SPA 없이 동적 웹 개발 혁신: 새로운 접근 방식 심층 분석

현대 웹 개발에서 사용자에게 풍부하고 반응성 높은 경험을 제공하는 것은 필수적입니다. 이러한 요구사항을 충족하기 위해 많은 개발자가 단일 페이지 애플리케이션(SPA) 프레임워크, 예를 들어 React, Vue, Angular 등을 선택해왔습니다. SPA는 뛰어난 사용자 경험과 클라이언트 사이드 렌더링의 이점을 제공하지만, 그 대가로 상당한 복잡성, 번들 크기 증가, 초기 로딩 시간 지연, 그리고 백엔드와의 복잡한 상태 관리 문제와 같은 난관에 부딪히기도 합니다.

그렇다면, 복잡한 JavaScript 프레임워크 없이도 동적이고 반응성 높은 웹 인터페이스를 구현할 수 있는 방법은 없을까요? 여기 htmx라는 흥미로운 대안이 등장합니다. htmx는 서버에서 렌더링된 HTML을 활용하여 동적인 웹 페이지를 구축하는 새로운 패러다임을 제시합니다. 이 글에서는 htmx가 무엇인지, 어떻게 작동하는지, 그리고 기존 SPA 방식과 비교하여 어떤 장단점을 가지는지 심층적으로 분석하여 웹 개발에 대한 새로운 시야를 제공하고자 합니다.

📑 목차

• 복잡한 SPA 없이 동적인 경험: htmx가 제시하는 새로운 패러다임
• htmx란 무엇인가? 핵심 원리와 작동 방식
• htmx의 선언적 문법과 데이터 교환 원리
• htmx vs. SPA 프레임워크: 접근 방식 비교 분석
• htmx와 전통적인 웹 개발 방식의 시너지
• htmx의 장점: 왜 htmx를 고려해야 하는가?
• htmx의 단점과 한계점: 언제 htmx가 적합하지 않을까?
• htmx 실제 활용 사례와 적용 시 고려사항
• 간단한 htmx 예제: 동적 내용 로딩 구현
• 결론: htmx, 웹 개발의 새로운 선택지

Image by NickyPe on Pixabay

복잡한 SPA 없이 동적인 경험: htmx가 제시하는 새로운 패러다임

웹 애플리케이션의 복잡성은 끊임없이 증가하고 있으며, 특히 프론트엔드 개발은 눈에 띄게 복잡해졌습니다. 수많은 라이브러리, 번들러, 상태 관리 솔루션, 라우터 등이 필요한 SPA 개발은 그 자체로 거대한 생태계를 이루며, 때로는 과도한 학습 곡선과 유지보수 비용을 요구합니다. 작은 프로젝트나 내부 관리 도구와 같이 모든 기능을 SPA로 구현할 필요가 없는 경우에도, 동적인 인터랙션을 위해 어쩔 수 없이 무거운 프레임워크를 도입하는 경우가 많았습니다.

htmx는 이러한 고민에 대한 해답으로 등장했습니다. htmx는 "HTML을 확장한다(HTML eXtended)"는 의미처럼, HTML에 몇 가지 속성(attribute)을 추가하는 것만으로 AJAX 요청, CSS 트랜지션, 웹소켓, 서버 발송 이벤트(Server Sent Events) 등을 손쉽게 처리할 수 있게 합니다. 이는 개발자가 복잡한 JavaScript 코드를 작성하거나 방대한 프론트엔드 생태계를 익히는 대신, 익숙한 HTML과 백엔드 로직에 집중하여 동적인 웹을 구현할 수 있도록 돕습니다.

핵심 아이디어는 간단합니다. 브라우저는 AJAX 요청을 보내고, 서버는 응답으로 HTML 조각(fragment)을 보냅니다. htmx는 이 HTML 조각을 받아와 페이지의 특정 부분에 삽입하거나 교체합니다. 이 과정에서 페이지 전체를 다시 로드하거나 복잡한 클라이언트 사이드 렌더링 로직을 수행할 필요가 없습니다. 마치 오래된 웹 페이지가 새 페이지로 이동하는 것처럼 보이지만, 실제로는 필요한 부분만 비동기적으로 업데이트되는 것입니다. 이는 웹 개발의 본질로 돌아가면서도 현대적인 사용자 경험을 제공하는 혁신적인 접근 방식이라고 할 수 있습니다.

htmx란 무엇인가? 핵심 원리와 작동 방식

htmx는 단일 파일로 구성된 경량의 JavaScript 라이브러리로, 개발자가 HTML에 직접 AJAX 기능을 추가할 수 있도록 해줍니다. 기존의 웹 개발 방식이 AJAX 요청을 위해 JavaScript 코드를 작성하고 DOM을 직접 조작해야 했던 것과 달리, htmx는 HTML 속성을 통해 이러한 과정을 선언적으로 처리합니다. 이는 "Hypertext As The Engine Of Application State (HATEOAS)" 원칙을 웹 프론트엔드 영역으로 확장한 것이라고 볼 수 있습니다.

htmx의 선언적 문법과 데이터 교환 원리

htmx의 핵심은 몇 가지 특별한 HTML 속성(attribute)에 있습니다. 가장 대표적인 속성들은 다음과 같습니다:

• hx-get: GET 요청을 보낼 URL을 지정합니다.
• hx-post: POST 요청을 보낼 URL을 지정합니다.
• hx-put: PUT 요청을 보낼 URL을 지정합니다.
• hx-delete: DELETE 요청을 보낼 URL을 지정합니다.
• hx-target: 서버 응답으로 받은 HTML을 삽입할 대상 DOM 요소를 지정합니다. (CSS 선택자 사용)
• hx-swap: 대상 요소에 HTML을 삽입하는 방식을 지정합니다. (예: innerHTML, outerHTML, afterbegin, beforend 등)
• hx-trigger: AJAX 요청을 발생시킬 이벤트를 지정합니다. (기본값은 클릭 또는 변경)

예를 들어, 버튼을 클릭했을 때 서버로부터 새로운 내용을 가져와 특정 영역에 표시하고 싶다면 다음과 같이 작성할 수 있습니다.

<button hx-get="/api/items" hx-target="#item-list" hx-swap="innerHTML">새로운 아이템 로드</button>
<div id="item-list">
    <!-- 여기에 서버에서 온 내용이 삽입됩니다 -->
</div>

이 코드는 버튼 클릭 시 `/api/items` 엔드포인트로 GET 요청을 보냅니다. 서버는 이 요청에 대한 응답으로 HTML 조각을 반환하고, htmx는 이 HTML을 `#item-list` ID를 가진 <div> 요소의 innerHTML로 교체합니다. 이 모든 과정이 별도의 JavaScript 코드 없이 HTML 선언만으로 이루어집니다.

htmx는 또한 요청 헤더에 HX-Request: true와 같은 특별한 헤더를 추가하여, 서버가 htmx 요청임을 인지하고 부분적인 HTML 응답을 보낼 수 있도록 합니다. 이는 백엔드 개발자가 더욱 효율적으로 응답을 구성할 수 있게 해주는 중요한 메커니즘입니다.

htmx vs. SPA 프레임워크: 접근 방식 비교 분석

htmx와 SPA 프레임워크는 동적인 웹 애플리케이션을 구축한다는 공통 목표를 가지고 있지만, 그 접근 방식과 철학은 매우 다릅니다. 이 차이점을 이해하는 것은 프로젝트에 가장 적합한 기술을 선택하는 데 중요합니다.

SPA 프레임워크는 클라이언트 사이드 렌더링(CSR)을 기반으로 합니다. 초기 로딩 시 최소한의 HTML과 대량의 JavaScript 번들을 다운로드하고, 이후 모든 UI 렌더링과 상태 관리를 브라우저에서 처리합니다. 반면 htmx는 서버 사이드 렌더링(SSR)의 장점을 유지하면서 부분적인 AJAX 업데이트를 통해 동적인 경험을 제공합니다. 이는 'HTML over the wire' 패러다임이라고도 불립니다.

다음 표는 htmx와 일반적인 SPA 프레임워크의 주요 특징을 비교한 것입니다.

특징	htmx	SPA 프레임워크 (예: React, Vue)
렌더링 방식	서버 사이드 렌더링 기반, 부분적 AJAX HTML 업데이트	클라이언트 사이드 렌더링 (CSR)
주요 기술 스택	HTML, CSS, 백엔드 언어 (Python, Ruby, PHP, Java 등), 최소한의 JS (htmx 라이브러리)	JavaScript/TypeScript, 프레임워크 (React, Vue, Angular), 번들러 (Webpack, Vite), 상태 관리 라이브러리 등
번들 크기	매우 작음 (htmx 라이브러리 자체는 약 10-15KB)	상대적으로 큼 (프레임워크, 라이브러리, 앱 코드 포함)
개발 복잡성	낮음 (익숙한 HTML과 백엔드 로직 활용)	높음 (별도의 프론트엔드 생태계, 상태 관리, 컴포넌트 개발)
SEO 친화성	매우 높음 (기본적으로 서버에서 완전한 HTML 렌더링)	초기 로딩 후 JS 렌더링 필요, SSR/SSG 도입 시 복잡성 증가
상태 관리	주로 서버에서 관리, 클라이언트 상태는 최소화	클라이언트에서 복잡한 상태 관리 로직 필요
프론트엔드 개발자 필요성	풀스택 또는 백엔드 개발자가 쉽게 접근 가능	전문 프론트엔드 개발자 역할 중요

htmx와 전통적인 웹 개발 방식의 시너지

htmx의 가장 큰 장점 중 하나는 기존의 서버 사이드 웹 프레임워크(예: Django, Flask, Ruby on Rails, Laravel, Spring Boot 등)와 매우 잘 통합된다는 점입니다. 이들 프레임워크는 이미 강력한 템플릿 엔진(Jinja2, ERB, Blade, Thymeleaf 등)을 가지고 있으며, htmx는 이러한 템플릿 엔진이 렌더링하는 HTML 조각을 클라이언트에 전달하여 동적인 부분을 업데이트합니다.

이는 백엔드 개발자가 별도의 프론트엔드 API를 구축하고 클라이언트에서 데이터를 처리하는 복잡한 과정을 거치지 않고도, 익숙한 컨트롤러와 뷰 로직으로 동적인 기능을 구현할 수 있음을 의미합니다. 예를 들어, Django에서 폼 제출 후 유효성 검사 결과를 부분적으로 업데이트하거나, Rails에서 목록의 항목을 비동기적으로 추가하는 등의 작업이 극도로 간소화됩니다. 이러한 시너지는 개발 생산성을 크게 향상시키고, 풀스택 개발자에게 특히 매력적인 요소로 작용합니다.

Image by RuslanSikunov on Pixabay

htmx의 장점: 왜 htmx를 고려해야 하는가?

htmx는 특정 유형의 프로젝트에 매우 강력한 이점을 제공하며, 기존 SPA 방식의 대안을 찾는 개발자들에게 매력적인 선택지가 될 수 있습니다. 주요 장점은 다음과 같습니다.

1. 개발 복잡성 감소 및 생산성 향상:가장 큰 장점은 개발 복잡성을 획기적으로 줄여준다는 것입니다. 별도의 프론트엔드 빌드 시스템, 번들러, 상태 관리 라이브러리, 라우터 등을 설정할 필요가 없습니다. 개발자는 익숙한 HTML과 백엔드 로직에만 집중하면 됩니다. 이는 특히 작은 팀이나 풀스택 개발자가 신속하게 기능을 구현해야 할 때 생산성을 크게 높여줍니다. 예를 들어, 백엔드 개발자가 새로운 API 엔드포인트를 만들고, 그 데이터를 받아와 복잡한 JS 코드로 렌더링하는 대신, 서버에서 바로 HTML 조각을 렌더링하여 반환하는 방식으로 수 시간에서 수 일의 개발 시간을 단축할 수 있습니다.
2. 작은 번들 크기와 빠른 초기 로딩:htmx 라이브러리 자체의 크기는 약 10-15KB에 불과합니다 (gzip 압축 시). 이는 수백 KB에서 수 MB에 달하는 SPA 프레임워크 번들과 비교하면 압도적으로 작은 크기입니다. 결과적으로 웹 페이지의 초기 로딩 속도가 매우 빨라지고, 사용자 경험 측면에서 이점을 제공합니다. 특히 모바일 환경이나 네트워크 대역폭이 제한적인 환경에서 더욱 두드러집니다.
3. 네이티브 SEO 친화성:htmx는 기본적으로 서버에서 완전한 HTML을 렌더링합니다. 이는 검색 엔진 크롤러가 페이지의 모든 콘텐츠를 쉽게 파싱할 수 있음을 의미합니다. SPA의 경우, 검색 엔진이 JavaScript를 실행하여 콘텐츠를 인덱싱해야 하므로 초기 인덱싱에 어려움이 있거나 추가적인 SSR/SSG 설정이 필요합니다. htmx는 이러한 복잡성 없이 기본적으로 SEO에 매우 친화적입니다.
4. 기존 백엔드 스택 활용 극대화:개발팀이 이미 Django, Rails, Laravel, Spring과 같은 서버 사이드 프레임워크에 숙련되어 있다면, htmx는 기존 기술 스택을 최대한 활용할 수 있도록 돕습니다. 새로운 프론트엔드 스택을 학습하거나 전문 프론트엔드 개발자를 고용할 필요 없이, 기존 백엔드 개발자들이 동적인 웹 인터페이스를 구축할 수 있게 됩니다. 이는 기술 부채를 줄이고 팀의 역량을 효율적으로 활용하는 데 기여합니다.
5. 점진적 개선 (Progressive Enhancement):htmx는 HTML을 기반으로 하므로, JavaScript가 비활성화되거나 로드되지 않더라도 기본적인 기능(정적 페이지 이동 등)은 작동합니다. 이는 접근성과 견고성 측면에서 큰 장점입니다. htmx는 점진적 개선 원칙에 따라 웹 애플리케이션을 구축할 수 있게 하여, 모든 사용자에게 최소한의 경험을 보장하면서 JavaScript가 활성화된 사용자에게는 더 풍부한 인터랙션을 제공합니다.

htmx의 단점과 한계점: 언제 htmx가 적합하지 않을까?

htmx는 많은 장점을 가지고 있지만, 모든 프로젝트에 만능 해결책은 아닙니다. 특정 상황에서는 SPA 프레임워크가 더 적합할 수 있으며, htmx의 단점과 한계점을 이해하는 것이 중요합니다.

1. 복잡한 클라이언트 사이드 상태 관리의 어려움:htmx는 주로 서버에서 상태를 관리하고 HTML을 렌더링하는 방식에 의존합니다. 만약 애플리케이션이 클라이언트에서 매우 복잡하고 상호 의존적인 상태를 관리해야 하거나, 빈번한 클라이언트 사이드 업데이트가 필요한 경우, htmx만으로는 효율적인 구현이 어려울 수 있습니다. 예를 들어, 드래그 앤 드롭 인터페이스, 실시간으로 수많은 요소가 동기화되어야 하는 협업 도구, 복잡한 그래픽 에디터 등은 클라이언트에서 강력한 상태 관리가 필요한 대표적인 사례입니다.
2. 클라이언트 사이드 로직의 분산:htmx는 HTML 속성을 통해 동적인 동작을 정의하지만, 이로 인해 JavaScript 로직이 HTML 마크업에 흩뿌려질 수 있습니다. 이는 규모가 커지거나 복잡한 인터랙션이 많아질수록 코드의 가독성을 해치고 유지보수를 어렵게 만들 수 있습니다. 특정 컴포넌트나 모듈에 모든 로직이 캡슐화되는 SPA 방식과 비교됩니다.
3. 강력한 컴포넌트 생태계 및 도구 부족:React, Vue와 같은 SPA 프레임워크는 거대한 컴포넌트 생태계와 개발자 도구를 가지고 있습니다. 수많은 UI 라이브러리, 상태 관리 도구, 라우팅 솔루션, 테스트 유틸리티 등이 존재하여 개발 생산성을 높여줍니다. htmx는 이러한 광범위한 생태계를 제공하지 않으므로, 특정 고급 UI 컴포넌트나 복잡한 기능은 직접 구현하거나 다른 경량 JavaScript 라이브러리와 함께 사용해야 할 수 있습니다.
4. 백엔드 부하 증가 가능성:모든 동적인 업데이트가 서버에서 HTML 조각을 렌더링하고 전송하는 방식에 의존하므로, 매우 빈번하거나 많은 사용자가 동시에 동적인 요청을 보낼 경우 백엔드 서버에 부하가 증가할 수 있습니다. SPA는 초기 로딩 후 대부분의 렌더링을 클라이언트에서 처리하여 백엔드 부하를 줄이는 데 유리합니다. 물론 캐싱 전략이나 효율적인 백엔드 구현으로 완화할 수 있는 부분이긴 합니다.
5. 새로운 패러다임에 대한 학습 곡선:htmx는 사용하기 쉽지만, 기존의 프론트엔드 개발 방식(SPA 또는 전통적인 jQuery 방식)에 익숙한 개발자에게는 새로운 사고방식을 요구할 수 있습니다. 클라이언트 상태 관리 없이 서버 상태를 중심으로 생각하고, HTML 속성을 통해 동작을 정의하는 방식에 적응하는 시간이 필요할 수 있습니다.

결론적으로, htmx는 관리자 페이지, 내부 도구, 비교적 단순한 동적 인터랙션이 필요한 웹사이트, 또는 기존 서버 사이드 렌더링 애플리케이션에 점진적으로 동적인 기능을 추가하고자 할 때 매우 효과적입니다. 반면, 복잡한 대규모 사용자 인터페이스, 오프라인 지원, 방대한 클라이언트 사이드 상태 관리가 필요한 경우, SPA 프레임워크가 여전히 더 적합한 선택일 수 있습니다.

Image by Boskampi on Pixabay

htmx 실제 활용 사례와 적용 시 고려사항

htmx는 다양한 시나리오에서 강력한 성능을 발휘할 수 있습니다. 다음은 htmx가 특히 빛을 발하는 몇 가지 실제 활용 사례입니다.

• 동적인 폼 처리 및 유효성 검사:사용자가 폼 필드를 입력할 때 실시간으로 유효성 검사 메시지를 표시하거나, 특정 필드의 값에 따라 다른 필드를 동적으로 활성화/비활성화할 수 있습니다. 폼 제출 후 서버로부터 받은 결과 메시지를 페이지의 특정 영역에 업데이트하는 것도 매우 간단합니다. 이는 사용자 경험을 개선하면서도 백엔드에서 모든 유효성 검사 로직을 유지할 수 있게 합니다.
• 무한 스크롤 및 지연 로딩:소셜 미디어 피드나 상품 목록과 같이 스크롤 시 새로운 콘텐츠를 동적으로 로드해야 하는 경우, htmx의 hx-trigger="revealed" 속성을 사용하여 페이지 하단에 도달했을 때 자동으로 다음 페이지의 데이터를 가져와 추가할 수 있습니다. 이는 사용자에게 끊김 없는 탐색 경험을 제공합니다.
• 탭 인터페이스 및 모달 창:클릭 시 탭 내용을 비동기적으로 로드하거나, 버튼 클릭 시 서버에서 동적으로 생성된 모달 창의 내용을 가져와 표시하는 등의 작업에 htmx를 활용할 수 있습니다. 이는 페이지 전체를 다시 로드하지 않고도 깔끔하고 반응성 있는 UI를 구현합니다.
• 실시간 대시보드 및 알림:웹소켓(hx-ws) 또는 서버 발송 이벤트(hx-sse) 확장 기능을 사용하여 서버로부터 실시간 데이터를 받아와 대시보드의 특정 위젯을 업데이트하거나 사용자에게 알림을 표시할 수 있습니다. 이는 별도의 WebSocket 클라이언트 코드를 작성할 필요 없이 HTML 속성만으로 구현 가능합니다.
• 관리자 페이지 및 내부 도구:복잡한 프론트엔드 기능을 요구하지 않으면서도 동적인 인터랙션이 필요한 관리자 페이지나 내부 사내 도구는 htmx의 이상적인 사용처입니다. 개발 속도와 유지보수 용이성 측면에서 큰 이점을 제공합니다.

간단한 htmx 예제: 동적 내용 로딩 구현

다음은 버튼 클릭 시 서버에서 가져온 새로운 내용을 동적으로 로드하는 간단한 예제입니다. 서버의 /quotes 엔드포인트는 매번 다른 명언을 HTML 조각으로 반환한다고 가정합니다.

<!-- htmx 라이브러리 포함 -->
<script src="https://unpkg.com/htmx.org@1.9.12" integrity="sha384-dlT5TUDkmGmJkVMVADjmsscK7HT4iuR5WzffkXJMzMvWzB0a+H9bhmfhtO4YxXw" crossorigin="anonymous"></script>

<h2>오늘의 명언</h2>
<div id="quote-display" style="border:1px solid #eee; padding: 15px; margin-bottom: 20px;">
    <p>버튼을 눌러 새로운 명언을 확인하세요.</p>
</div>

<button hx-get="/quotes" hx-target="#quote-display" hx-swap="innerHTML">새로운 명언 불러오기</button>

<!-- 서버 사이드 (예: Python Flask) -->
<!--
from flask import Flask, render_template

app = Flask(__name__)

quotes = [
    "성공은 최종적인 것이 아니며, 실패는 치명적인 것이 아니다. 중요한 것은 계속하는 용기이다. - 윈스턴 처칠",
    "상상력은 지식보다 중요하다. - 알베르트 아인슈타인",
    "나는 실패한 적이 없다. 그저 작동하지 않는 1만 가지 방법을 찾았을 뿐이다. - 토마스 에디슨"
]
import random

@app.route('/')
def index():
    return render_template('index.html')

@app.route('/quotes')
def get_quote():
    return f"<p>{random.choice(quotes)}</p>"

if __name__ == '__main__':
    app.run(debug=True)
-->

이 예제에서 사용자는 별도의 JavaScript 코드를 작성할 필요 없이, 오직 HTML 속성만으로 버튼 클릭에 따른 동적 콘텐츠 업데이트 기능을 구현할 수 있습니다. 백엔드 개발자는 간단히 HTML 조각을 반환하는 엔드포인트를 구현하기만 하면 됩니다.

결론: htmx, 웹 개발의 새로운 선택지

htmx는 현대 웹 개발의 복잡성에 대한 사려 깊은 대안을 제시합니다. 모든 프로젝트가 풀스택 JavaScript 기반의 SPA가 될 필요는 없으며, 때로는 서버 사이드 렌더링의 견고함과 HTML의 단순함을 유지하면서도 충분히 동적이고 반응성 높은 웹 경험을 제공할 수 있습니다.

htmx는 개발자가 익숙한 HTML과 백엔드 로직에 집중하여 더 빠르게 개발하고, 더 가벼운 웹 애플리케이션을 만들 수 있도록 돕습니다. 특히 기존 서버 사이드 렌더링 애플리케이션에 점진적으로 동적인 기능을 추가하거나, 관리 도구, 내부 시스템과 같이 복잡한 클라이언트 사이드 상태 관리가 필요 없는 프로젝트에서 그 가치를 극대화할 수 있습니다.

물론, htmx가 모든 웹 개발 문제를 해결하는 만능 솔루션은 아닙니다. 복잡한 클라이언트 사이드 인터랙션이나 방대한 상태 관리가 필요한 경우에는 여전히 React, Vue와 같은 SPA 프레임워크가 더 적합할 수 있습니다. 중요한 것은 프로젝트의 요구사항과 팀의 역량을 고려하여 가장 적합한 도구를 선택하는 유연한 접근 방식입니다.

htmx는 웹 개발의 복잡성을 줄이고자 하는 개발자들에게 신선하고 강력한 대안을 제공하며, 웹 기술 스택 선택의 폭을 넓혀주는 중요한 흐름으로 자리매김하고 있습니다. 여러분의 다음 프로젝트에서 htmx를 고려해보는 것은 어떨까요? 이 새로운 패러다임이 여러분의 개발 경험을 어떻게 변화시킬지 기대됩니다.

htmx에 대해 어떤 의견을 가지고 계신가요? 여러분의 경험이나 생각이 궁금합니다. 댓글로 자유롭게 공유해주세요!

📌 함께 읽으면 좋은 글

• [기술 리뷰] React Native vs Flutter: 크로스 플랫폼 모바일 앱 개발 프레임워크 성능 및 개발 경험 비교 분석
• [보안] DevSecOps CI/CD 파이프라인 보안 자동화: SAST, DAST, SCA 통합 전략 완벽 가이드
• [튜토리얼] tRPC와 Next.js로 구현하는 타입 안전 풀스택 웹 애플리케이션 구축 가이드

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.