이 영상에서 단테는 교토 기온 지역을 걷는 여행 지도 앱 하나를 React, Solid 2, HTMX 4 세 가지 방식으로 연결하고, 상태 관리와 데이터 요청, 화면 갱신 코드가 어떻게 달라지는지 나란히 비교합니다. React에는 익숙하지만 다른 프레임워크가 어떤 문제를 다르게 푸는지 궁금한 프론트엔드 개발자에게 맞는 내용입니다.
예제 앱: 교토 산책 지도
앱은 야사카 신사, 하나미코지, 시라카와 세 장소를 산책 일정으로 잇는 지도입니다. 기온의 실제 도로와 건물, 강을 한 화면에 담고, 검색창에 장소 이름을 입력해 결과를 누르면 카메라가 그 장소로 이동하며 지도 표식과 장소 설명이 함께 바뀝니다. 2D와 3D를 전환하면 같은 동네를 다른 각도에서 볼 수 있습니다. 건물 높이는 빈 데이터가 있어서 측량값이 아니라 지도를 읽기 위한 표현으로만 씁니다.
세 장소를 일정에 담으면 앱이 미리 준비한 보행로를 따라 순서를 연결하고, 옆에 도보 거리와 예상 시간을 보여 줍니다. 장소를 추가하거나 순서를 바꾸면 경로선과 합계가 함께 바뀌고, 하나를 빼면 다음 구간이 다시 계산됩니다. 화면에 선을 그려 넣는 것이 아니라 준비된 도로망을 일정 계산에 쓰는 방식입니다.
AI에게 맡긴 첫 지도와 수정 결과
첫 버전은 Luna에게 구현을 맡겼습니다. 장소를 누르고 일정에 담는 기능은 됐지만, 골목을 찾아다닐 지도라기에는 너무 단순했습니다. 작업 지시를 다시 보니 처음부터 단순한 로우폴리 입체 모형으로 방향을 잡아 두었고, 실제 도로 데이터 대신 건물과 길을 코드로 직접 배치하고 있었습니다.
그래서 디자인은 Claude MCP를 통해 Fable에 맡기고, 교토의 실제 OpenStreetMap 도로와 건물 윤곽을 쓰도록 바꿨습니다. 그 결과 큰길 사이 골목과 다리가 보이고, 일정 순서를 바꾸면 그 길을 따라 경로가 다시 계산되는 지도가 됐습니다.
단테는 이 결과로 Luna보다 Fable이 무조건 낫다고 말할 수 없다고 선을 긋습니다. 모델뿐 아니라 작업 지시, 지도 데이터, 확인 기준을 함께 바꿨기 때문입니다. 이번에 얻은 교훈은 도시를 자세히 보여 주려면 처음부터 실제 도시 데이터와 도로 연결을 요구해야 한다는 점입니다. 구현을 AI에 많이 위임해도 무엇을 만들고 어떤 구조를 택할지는 사람이 판단해야 합니다.
공통 구조: 3D 장면과 프레임워크의 역할 분담
도로, 건물, 강을 그리는 3D 장면은 공통 어댑터가 맡고, 각 프레임워크는 선택한 장소와 일정만 넘깁니다. 장소를 누르면 작은 여행자 표시가 경로를 따라 이동하고, 옆 패널이 바뀌어도 지도 장면은 계속 살아 있습니다.
React 버전에서는 검색어, 선택한 장소, 일정을 컴포넌트 상태로 관리합니다. 장소를 고르면 상세 요청을 시작하고, 이전 요청이 늦게 도착해도 지금 선택한 장소의 설명만 남깁니다. 상태가 바뀌면 컴포넌트 계산이 다시 실행되고 React는 필요한 DOM만 커밋합니다. 오래 살아야 하는 3D 장면은 한 번 연결한 뒤 화면이 사라질 때 정리합니다. 상태와 캔버스의 수명을 나눠 갖는 구조입니다.
Solid 2: 세밀한 반응성과 비동기 값
Solid의 createSignal은 React의 useState처럼 상태를 담는 자리입니다. 차이는 값을 읽을 때 selectedId가 아니라 selectedId()처럼 함수를 호출한다는 점입니다. React는 상태가 바뀌면 컴포넌트를 다시 계산하지만, Solid는 그 값을 읽는 반응성 계산이나 표현식만 갱신합니다. 이 세밀한 반응성은 Solid 1부터 있던 특징입니다.
달라진 부분은 비동기 데이터입니다.
- Solid 1에서는
createResource에 선택값과 요청 함수를 연결하고,Suspense로 기다리는 화면을 감쌌습니다. React에서 데이터 요청과 로딩 화면을 준비하던 역할을 떠올리면 됩니다. - Solid 2에서는 비동기
createMemo로 요청 결과를 반응성 값으로 읽고, 그 결과를 다음 memo가 다시 읽습니다. 로딩과 에러용 컴포넌트가 기다리는 동안과 실패했을 때의 화면을 맡습니다.
React의 useMemo도 계산 값을 재사용하지만, useMemo에 async를 넣는다고 같은 동작이 되지는 않습니다. Solid 2는 비동기 값의 의존 관계까지 반응성 그래프로 연결한다는 점이 다릅니다. 영상의 Solid 2는 RC 버전이므로, 옮길 때 호환성을 확인해야 합니다.
HTMX 4: 서버가 보낸 HTML로 화면 바꾸기
React에서는 버튼을 누르면 fetch로 JSON을 받고 상태를 바꿔 JSX로 상세 카드를 그립니다. HTMX에서는 HTML 속성에 요청과 교체를 선언합니다. hx-get에 요청 주소를 적고, hx-target으로 응답을 넣을 영역을, hx-swap으로 그 영역을 어떻게 바꿀지 정합니다. 서버가 완성한 HTML을 받아 그대로 넣는 방식이며, 이 속성들이 React의 훅과 같은 역할은 아닙니다. 지도 캔버스는 교체 영역 밖에 두고, 지도 선택이나 일정 저장은 자바스크립트가 이어서 처리합니다.
HTMX 2와 4의 예제를 나란히 보면 차이가 분명합니다. 2에서는 부모의 설정을 자식이 암묵적으로 물려받았지만, 4에서는 상속을 명시적으로 적어 그 관계를 드러냅니다. 요청 처리도 XHR 중심에서 fetch 중심으로 옮겨 갔습니다. 상속이 드러나면 마크업을 옮기거나 고칠 때 따라오는 동작을 찾기 쉽지만, 버전을 올릴 때는 이벤트와 서버 응답 형식까지 함께 점검해야 합니다.
정리
- 같은 교토 지도 앱을 세 방식으로 만들면, 화면은 같아도 상태와 HTML을 누가 책임지는지가 크게 다릅니다.
- React는 브라우저 상태와 컴포넌트 흐름을 중심으로 팀 작업을 할 때 자연스럽습니다.
- Solid 2는 Solid 1의 세밀한 반응성 위에 비동기 계산과 로딩·에러 표시를 반응성 값으로 잇고 싶을 때 볼 만하며, 영상 시점에는 RC 버전입니다.
- HTMX 4는 서버 HTML을 중심에 두고 3D 캔버스는 별도로 연결하는 구조에 맞고, 상속을 명시하며 fetch 기반으로 바뀌었습니다.
- AI가 만든 첫 지도가 단순했던 원인은 작업 지시에 있었고, 실제 도시 데이터를 처음부터 요구해야 한다는 교훈을 남겼습니다.