핵심 이슈: "Headless 하면 빨라진다"는 절반의 진실
솔직히 말하면, Shopify 프로젝트 상담에서 가장 많이 듣는 질문이 "우리도 Headless 가야 하나요?"입니다. dev.to에 올라온 한 Shopify 전문 개발자의 분석이 정확히 이 지점을 찌릅니다. SSR/SSG로 Lighthouse 만점 찍고, 3D 컨피규레이터 같은 고상태(high-state) 인터페이스를 React로 우아하게 처리하고, /products/ 고정 URL 구조에서 벗어나 SEO 유연성을 확보하는 것—여기까지는 매력적이죠. 그런데 사용자 입장에서는 그 500ms 차이를 정말 체감할까요? Lighthouse 100점이 실제 전환율 상승으로 이어진다는 데이터가 우리 서비스에 있나요? 이걸 먼저 물어야 합니다.
맥락 해석 1: 앱 통합 갭이 프론트엔드 아키텍처를 잡아먹는다
Headless의 가장 과소평가된 비용은 "앱 통합 갭"입니다. Liquid 환경에서는 리뷰, 로열티, 검색 앱이 Theme App Extensions로 그냥 붙습니다. 드래그 앤 드롭이요. 그런데 Next.js나 Hydrogen으로 넘어가는 순간, 이 모든 서비스를 각각의 API로 수동 통합해야 합니다. 여기서 문제는 단순히 개발 시간이 늘어나는 게 아닙니다. 각 서드파티 API의 응답 구조에 맞춰 React 컴포넌트를 설계해야 하고, 그 컴포넌트들의 Props 패턴이 서비스마다 제각각이 됩니다.
Velog에 정리된 React Props 패턴 글을 보면, Forwarded Props(...props) 패턴이나 children + named slot 패턴, 동적 컨테이너(ButtonsContainer) 패턴처럼 컴포넌트 재사용성을 높이는 기법이 잘 나와 있습니다. 그런데 이런 패턴이 빛을 발하려면 컴포넌트 경계가 일관돼야 합니다. Headless 환경에서 리뷰 위젯은 A사 API, 검색은 B사 API, 로열티는 C사 API를 쓰면, 각각의 래퍼 컴포넌트가 서로 다른 데이터 스키마를 소화해야 하고, ...props 포워딩만으로는 해결 안 되는 타입 불일치가 쌓입니다. Figma에서 볼 때는 깔끔한 탭 UI인데, 실제로 구현하면 세 개의 서로 다른 API 응답을 정규화하는 어댑터 레이어가 필요해지는 거죠. 이건 px 단위의 문제가 아니라 아키텍처 단위의 문제입니다.
맥락 해석 2: "폴리시 데이"가 사라지는 애자일 환경
dev.to의 프론트엔드 통합 일지(Day 8)에서 인상적인 문장이 있었습니다: "때로는 아무것도 새로 만들지 않는 것이 최고의 엔지니어링 결정이다." JSON → Hook → Page → Sections → UI라는 일관된 데이터 흐름을 잡고, 내비게이션의 데드 라우트를 없애고, 폼 상태를 점검하는—이른바 시스템 품질(System Quality) 작업이죠. 사용자 입장에서는 눈에 안 보이지만, 네비게이션이 깨지는 순간 신뢰가 깨진다는 걸 우리는 압니다.
문제는 이런 "폴리시 데이"가 현실의 애자일 스프린트에서 설 자리가 없다는 겁니다. 또 다른 dev.to 글에서 한 프론트엔드 개발자가 2주간 자기 시간을 추적했더니, 21시간을 회의에 쓰고 실제 코딩은 19시간이었다고 합니다. 미국심리학회(APA) 연구에 따르면 태스크 스위칭만으로 생산성이 최대 40% 감소하는데, 스프린트 안에서 버그 수정, 신규 기능, 리팩토링, 기술 부채, 서포트 티켓을 동시에 저글링하면서 "오늘은 통합·정리만 하겠다"고 선언할 수 있는 팀이 얼마나 될까요?
Headless 전환은 이 컨텍스트 스위칭 문제를 구조적으로 악화시킵니다. Liquid 테마에서는 Shopify가 호스팅·빌드·프리뷰를 다 관리해줬는데, Headless로 가면 Vercel/Netlify 인프라 관리, CI/CD 파이프라인, 커스텀 프리뷰 시스템까지 프론트엔드 팀의 책임이 됩니다. 번들 사이즈 신경 쓰랴, Core Web Vitals 모니터링하랴, API 어댑터 유지보수하랴—"간단한 프론트엔드 수정"조차 개발자 없이는 불가능해지는 거죠. 그 "드래그 앤 드롭 민첩성"을 잃는 대가가 생각보다 큽니다.
시사점: State를 필요한 곳 가장 가까이 두듯, 복잡성도 필요한 곳에만
React에서 State를 그것을 필요로 하는 컴포넌트 가장 가까운 곳에 두는 게 원칙이듯, 아키텍처 복잡성도 마찬가지입니다. selectedTopic이 Examples 컴포넌트 안에서만 쓰이면 App에 올리지 않는 것처럼, Headless라는 무거운 아키텍처도 정말 그 복잡성이 필요한 곳에서만 도입해야 합니다.
원문의 결론이 명쾌합니다: Headless는 (1) 500ms 개선이 매출로 직결되는 대규모 트래픽, (2) Liquid로는 불가능한 복잡한 UI 요구사항, (3) 지속적 기술 부채를 감당할 전담 엔지니어링 팀—이 세 조건을 동시에 충족할 때만 정당화됩니다. 그 외에는 잘 최적화된 Liquid 테마가 여전히 가장 민첩하고 비용 효율적인 선택입니다.
전망: "빌드 안 하는 날"을 설계할 수 있는 팀만 Headless를 감당한다
사실 이건 Shopify만의 이야기가 아닙니다. Next.js를 도입하든, Hydrogen을 쓰든, 어떤 Headless 프레임워크를 선택하든 핵심 질문은 같습니다: 우리 팀에 "Day 8"—아무것도 새로 만들지 않고 시스템을 정렬하는 날—을 스프린트에 정기적으로 확보할 역량이 있는가?
기술 부채에 스프린트 용량의 20~30%를 할당하고, 폴리시 작업을 "기능"과 동등하게 추적하고, 개발자의 집중 시간(Focus Time)을 공격적으로 보호하는 문화가 없다면, Headless 전환은 Lighthouse 점수를 올리는 대신 팀의 지속 가능한 속도(Sustainable Pace)를 갈아넣는 교환이 됩니다.
로딩 스켈레톤 하나 넣으려면 그 스켈레톤의 높이가 실제 콘텐츠와 몇 px 차이나는지, CLS에 영향은 없는지 확인해야 하잖아요. 아키텍처 선택도 마찬가지입니다. 겉으로 보이는 "성능"과 "자유도"라는 큰 그림 뒤에, 1px 단위의 유지보수 비용이 숨어 있습니다. 그 비용을 감당할 준비가 됐는지—Headless 전환 전에 반드시 물어야 할 질문입니다.