핵심 이슈: 프론트엔드는 API의 모양대로 무너진다
프론트엔드 개발을 하다 보면 "이 API 누가 설계한 거예요?"라는 말이 입에서 튀어나오는 순간이 있습니다. 캐릭터 카드 하나 그리려는데 요청이 3개, 5개, 7개로 늘어나고, 검색 결과에 같은 책이 다섯 줄로 반복되고, 한국 유저한테 영문 코드명이 그대로 노출되는 상황—전부 "API가 프론트를 배려하지 않아서" 생기는 문제입니다. 최근 눈에 띄는 세 가지 사례를 엮어보면, 데이터의 형태가 곧 사용자 경험의 천장이라는 사실이 선명해집니다.
사례 1: SWAPI의 요청 폭포, BFF가 막아낸 것
dev.to에 공유된 Star Wars API(SWAPI) BFF 프로젝트는 프론트엔드 개발자라면 한 번쯤 겪어봤을 "요청 워터폴" 문제를 정면으로 다룹니다. 원본 SWAPI에서 루크 스카이워커 카드를 렌더링하려면 /people/1을 먼저 치고, 응답 안에 있는 homeworld URL로 /planets/1을 다시 치고, films 배열을 순회하며 /films/1, /films/2…를 또 칩니다. 사용자 입장에서는 카드 하나에 스피너가 3~4번 돌아가는 셈이죠. LCP(Largest Contentful Paint)가 처참해질 수밖에 없습니다.
이 프로젝트가 선택한 해법은 Next.js Route Handler를 BFF(Backend For Frontend) 레이어로 세우는 것이었습니다. ?expand=homeworld,films 한 줄이면 중첩 객체가 한 번의 응답에 담겨 내려옵니다. 2레벨 깊이 제한을 걸어 오버페칭도 방지했고, ?search=skywalker&gender=male&sort=name&page=1&limit=5 같은 쿼리 파라미터로 페이지네이션·필터·정렬까지 프론트 친화적으로 정규화했습니다. 사실 이건 flexbox 하나로 해결되는 레이아웃 문제가 아니라, 프론트가 필요한 데이터 셰이프를 백엔드가 미리 알고 맞춰주느냐의 문제입니다. BFF는 그 갭을 메우는 가장 현실적인 패턴이고, 이 사례는 React·Vue 프로젝트에서 바로 참고할 수 있을 만큼 구체적입니다.
사례 2: ISBN이 UX를 망가뜨리는 구조적 이유
GeekNews에 소개된 "ISBN의 위험성" 글은 데이터 모델의 설계가 프론트엔드 검색 UX를 어떻게 박살 내는지를 적나라하게 보여줍니다. Google Books API에서 "The Last Unicorn"을 검색하면 하드커버, 페이퍼백, eBook, 개정판이 각각 다른 항목으로 쏟아집니다. 사용자는 그냥 "이 책 읽었다"고 기록하고 싶을 뿐인데, 검색 결과 UI에는 같은 책이 다섯 줄로 반복되는 거죠.
이 문제의 근본 원인은 도서관학의 FRBR 모델—작품(work), 표현(expression), 형태(manifestation), 아이템(item)—에서 API가 '형태' 수준의 데이터를 반환하는데, 사용자는 '작품' 수준의 추상화를 기대한다는 점입니다. Figma에서 "검색 결과 카드 컴포넌트"를 예쁘게 그려봤자, 백엔드에서 내려오는 데이터가 중복 투성이면 UI는 어수선해질 수밖에 없습니다. OpenLibrary가 작품 중심 구조를 제공하지만 여전히 오가와 요코의 소설이 네 번 중복 표시되는 현실, 영화 데이터베이스 TMDB처럼 정제된 오픈 메타데이터가 도서 분야에는 부재하다는 지적—이 모든 것이 "프론트엔드가 아무리 잘해도, 데이터 인프라가 허술하면 UX에는 한계가 있다"는 걸 증명합니다.
실제로 Hacker News 댓글에서 한 개발자는 주(state) 단위 독서 대회에서 ISBN 매핑 SQL 조인 하나를 추가한 것만으로 "10년간 학생들이 백만 권 이상을 추가로 읽게 되었다"고 밝혔습니다. 데이터 정규화가 곧 사용자 행동의 변화로 이어진다는, 프론트엔드 개발자에게는 소름 돋는 사례입니다.
사례 3: 서브컬처 캘린더가 증명한 로컬라이징의 무게
Velog에 공유된 "오타쿠 캘린더" 기획서와 1일차 작업 보고서는 데이터 레이어의 품질이 UI/UX 프리미엄에 직결된다는 점을 보여줍니다. Luna IV, Phase, v2.6 같은 영문·비공식 코드명 50여 개를 전수 조사해 공식 한국어 명칭으로 교체하고, 모든 배너 제목에 [픽업] 또는 [복각] 접두사를 붙인 건—기획자가 이걸 의도한 건지 개발자가 직접 판단한 건지 모르겠지만—정보의 스캔어빌리티(scannability)를 200% 끌어올리는 결정이었습니다.
기술 스택은 Vanilla JS + JSON 정적 데이터라 번들 사이즈 걱정은 없겠지만, 사실 여기서 주목할 건 기술이 아니라 데이터 운영 정책 5대 원칙입니다. 공식 소스만 사용, 순수 한국어, 배너 유형 표준화, 미디어 퀄리티 제어, 브라우저 렌더링 검증 후 배포—이게 곧 디자인 시스템의 Data Layer 버전이라고 볼 수 있습니다. 반응형 다단 레이아웃에서 다중 캐릭터 수직 분할 뷰까지, 모바일에서 아이폰 14 Pro와 갤럭시 S24를 타겟으로 잡은 것도 꽤 구체적입니다.
시사점: 데이터 셰이프가 디자인 시스템의 시작점이다
세 사례를 관통하는 메시지는 명확합니다. 프론트엔드의 UX 천장은 API와 데이터 모델이 결정한다. BFF 패턴으로 요청 워터폴을 해소한 SWAPI 사례, ISBN의 FRBR 모델이 검색 UX를 구조적으로 망가뜨리는 사례, 그리고 데이터 로컬라이징 원칙이 서브컬처 캘린더의 정보 가독성을 극적으로 끌어올린 사례—모두 "컴포넌트를 아무리 잘 만들어도, 내려오는 데이터가 엉망이면 사용자 경험은 무너진다"는 동일한 교훈을 줍니다.
사용자 입장에서는 API의 구조 따위 알 바 아닙니다. 카드가 빨리 뜨는지, 검색 결과가 깔끔한지, 내가 아는 이름으로 정보가 보이는지—그게 전부예요. 그런데 그 "전부"를 결정하는 건 프론트엔드 코드가 아니라 백엔드에서 내려주는 JSON의 모양입니다.
전망: 프론트엔드 팀이 데이터 계약에 참여해야 한다
앞으로 디자인 시스템을 논할 때 Design Token만이 아니라 Data Contract—API 응답 스키마의 합의—까지 포함해야 합니다. Figma Dev Mode에서 컴포넌트 스펙을 넘기듯, API 스키마도 프론트엔드 팀이 리뷰하고 요구사항을 반영하는 워크플로우가 필요합니다. BFF 레이어를 직접 운영하든, 백엔드와 스키마를 공동 설계하든, "데이터의 모양은 프론트가 결정한다"는 원칙을 세우지 않으면—Lighthouse 점수를 아무리 올려봤자, 사용자가 보는 화면은 여전히 느리고, 어수선하고, 불친절할 겁니다.