폼도 라우팅도 '경험 설계'가 먼저다

폼도 라우팅도 '경험 설계'가 먼저다

Jelly UI의 물리 기반 인터랙션과 Next.js Parallel·Intercepting Routes가 동시에 가리키는 하나의 질문—기술을 쌓기 전에 사용자가 느끼는 순간을 먼저 설계했는가.

Jelly UI 소프트바디 물리 마이크로 인터랙션 Parallel Routes Intercepting Routes Next.js App Router 폼 UX 어포던스
광고

버튼을 누를 때 손끝에 저항감이 느껴진다면, 그 UI는 이미 절반은 성공한 셈이다. Jelly UI는 소프트바디 물리 엔진을 네이티브 HTML 폼 컨트롤에 입힌 라이브러리다. 버튼이 눌리면 눌린 만큼 형태가 변형되고, 체크박스는 체크되는 순간 미세하게 흔들린다. 처음 보면 '재미있는 데모'로 분류하기 쉽다. 하지만 조금만 더 들여다보면 이 라이브러리가 건드리는 지점은 단순한 시각 효과가 아니라 어포던스(affordance)—UI가 스스로 '이렇게 쓰면 된다'고 말하는 능력—임을 알 수 있다.

우리가 매일 마주하는 웹 폼은 기능적이지만 거의 언제나 납작하다. 입력하고, 클릭하고, 기다린다. 상태 변화는 색상이나 텍스트 변경으로만 전달된다. Jelly UI가 제안하는 것은 이 과정에 촉각적 피드백의 은유를 더하는 것이다. 제출 버튼이 클릭 압력에 반응해 살짝 눌렸다가 되돌아오는 장면은, '처리 중'이라는 상태를 텍스트 없이도 전달한다. 이것은 장식이 아니라 커뮤니케이션이다. CSS transform으로 만드는 단순한 스케일 애니메이션, Lottie로 구현하는 복합 모션에 이어, 물리 기반 인터랙션은 디지털 인터페이스가 물리 세계의 감각에 한 발 더 가까워지는 단계로 읽힌다.

물론 실무 적용에는 냉정한 시각이 필요하다. 성능 오버헤드, 스크린 리더와의 호환성, 모션 감도에 민감한 사용자를 위한 prefers-reduced-motion 대응—이 세 가지는 Jelly UI를 프로덕션에 올리기 전에 반드시 검토해야 할 체크리스트다. 라이브러리 자체는 비교적 가벼운 물리 엔진 위에 올라가 있고, 커스텀 컴포넌트를 새로 만드는 것이 아니라 네이티브 엘리먼트를 강화하는 구조라 초기 우려보다는 실용적이다. 그러나 모든 폼에 젤리를 바를 이유는 없다. 핵심 CTA 하나, 중요한 확인 버튼 하나에 절제된 방식으로 적용할 때 이 라이브러리의 가치는 가장 선명해진다.

한편, 같은 '경험 설계'의 문제의식은 라우팅 레이어에도 똑같이 적용된다. Next.js App Router의 Parallel RoutesIntercepting Routes는 단순한 파일 시스템 컨벤션이 아니다. 이 두 패턴의 조합이 가능하게 하는 것은—velog의 Next.js 고급 라우트 패턴 정리가 잘 요약하듯—'같은 URL에서 컨텍스트에 따라 다른 렌더링 결과를 보여주는' 경험 분기다. 피드에서 사진을 클릭하면 URL은 /photo/123으로 바뀌지만 피드는 사라지지 않고, 사진 상세는 모달로 떠오른다. 새 탭에서 같은 URL을 열면 전체 화면 상세 페이지로 렌더링된다. 사용자가 어느 경로로 진입했느냐에 따라 '적절한 경험'이 자동으로 선택된다.

이 패턴의 구현은 @슬롯으로 정의한 Parallel Route와 (..) 계열 컨벤션으로 정의한 Intercepting Route를 조합하는 방식이다. 핵심은 파일 시스템 경로가 아니라 라우트 세그먼트 기준으로 단계를 계산한다는 것—슬롯 폴더는 세그먼트 계산에서 제외된다. default.tsx는 해당 슬롯에 매칭되는 URL이 아닐 때 보여줄 폴백을 정의하고, 모달을 닫을 때 router.back()을 사용하는 이유는 브라우저 히스토리를 '뒤로 가기'처럼 동작시켜 모달 이전 상태로 자연스럽게 복귀하기 위해서다. Link로 다른 페이지로 이동할 때 슬롯 상태가 남는 문제는 catch-all 라우트([...catchAll])로 정리한다.

두 기술—Jelly UI의 물리 인터랙션과 Next.js의 고급 라우팅—은 표면적으로 전혀 다른 레이어에 속한다. 그런데 둘 다 같은 질문에서 출발한다. "사용자가 이 순간에 무엇을 느껴야 하는가?" Jelly UI는 버튼을 누르는 0.1초의 피드백을 설계하고, Parallel + Intercepting Routes는 페이지 전환이라는 수백 밀리초의 흐름을 설계한다. 스케일만 다를 뿐 문제의 본질은 같다—기술 선택 이전에 경험의 흐름을 먼저 그려야 한다.

AI 프로토타이핑 도구가 일반화된 지금, 빠른 UI 생성은 더 이상 병목이 아니다. v0.dev로 컴포넌트를 뽑고, Cursor로 라우팅 구조를 잡고, Claude로 폼 로직을 초안 잡는 데는 몇 시간이 걸리지 않는다. 병목은 오히려 그 결과물이 진짜 사용자 경험을 설계한 것인지 아닌지를 판단하는 데 있다. 버튼이 맞게 동작하는가가 아니라, 이 버튼을 누를 때 사용자가 무엇을 느끼도록 의도했는가. 라우팅이 기술적으로 작동하는가가 아니라, 이 전환이 사용자의 컨텍스트를 유지하고 있는가.

마이크로 인터랙션과 라우팅 패턴은 앞으로도 계속 정교해질 것이다. Jelly UI가 실험하는 물리 기반 피드백은 View Transitions API, CSS @starting-style 같은 브라우저 네이티브 모션 기능과 결합할 때 더 넓은 가능성을 가진다. Next.js의 Parallel/Intercepting Routes 역시 Partial Prerendering과 맞물리면 독립 영역별 스트리밍 렌더링이라는 새로운 UX 패턴을 열어준다. 도구는 계속 진화한다. 그러나 그 도구를 쥐는 손이 먼저 물어야 할 것은 변하지 않는다—이 경험이 사용자에게 진짜 도움이 되는가.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요