'빠르게 만든다'와 '잘 만든다'는 오랫동안 서로 다른 방향처럼 보였다. 하지만 최근 세 가지 실전 사례를 나란히 놓고 보면, 그 두 방향이 이제 하나의 워크플로우 안에서 수렴하고 있다는 걸 알 수 있다. AI 도구로 구현 속도를 확보하고, 캐싱 설계로 사용자 경험을 정밀하게 다듬고, 데이터 시각화로 정보를 진짜 경험으로 바꾸는 흐름이다.
1단계: 복잡한 기능을 프롬프트 한 줄로 — Cursor + MCP
dev.to에 소개된 FFmpeg Micro 사례는 AI 코딩 워크플로우의 가능성을 선명하게 보여준다. 비디오 처리 기능은 MVP 단계에서 자주 생략되는 항목이다. FFmpeg의 400개 이상 플래그를 익히는 데 드는 시간과, 그 시간을 쓰지 않으면 제품이 '그냥 텍스트 피드'에 머문다는 현실 사이에서 대부분의 팀이 포기를 선택한다.
FFmpeg Micro가 제안하는 해법은 간단하다. MCP(Model Context Protocol) 서버를 Cursor에 연결하면, AI 어시스턴트가 도구 명세를 직접 읽고 올바른 API 호출 코드를 생성한다. "영상 앞 30초만 잘라줘"라고 말하면, Cursor는 -ss, -t, -c copy 플래그를 알아서 조합한다. 개발자가 FFmpeg를 몰라도 된다. 설정은 .mcp.json 파일 하나, 소요 시간은 5분 이내다.
이 사례가 흥미로운 이유는 단순한 자동화가 아니라는 점이다. MCP는 AI 어시스턴트에게 '추측'이 아닌 '명세'를 제공한다. Cursor가 FFmpeg 문서를 크롤링해서 추측하는 게 아니라, MCP 서버가 노출한 도구 스펙을 정확히 이해하고 그에 맞는 코드를 만든다. 이 차이가 신뢰할 수 있는 코드 생성과 '그럴싸한 할루시네이션' 사이를 가른다. AI 도구를 단순한 자동완성이 아닌 통합된 개발 파이프라인의 구성 요소로 쓰는 방법을 잘 보여주는 예시다.
2단계: 캐싱 설계로 사용자 경험을 정밀하게 — Next.js + TanStack Query
프로토타입을 실제 서비스로 올리는 순간, 속도보다 더 중요한 문제가 드러난다. 어떤 데이터를 서버에서 캐싱하고, 어떤 데이터를 클라이언트에서 신선하게 유지할 것인가. velog에 공유된 Next.js 캐싱 전략 도입기는 이 질문에 실무적으로 답한다.
Next.js는 Request Memoization, Data Cache, Full Route Cache, Router Cache라는 네 가지 캐싱 레이어를 제공한다. 서버 렌더링 결과를 재사용하고, 동일한 fetch 요청을 하나로 병합하고, 이전에 방문한 페이지로 돌아갈 때 서버 요청 없이 즉시 화면을 보여주는 것까지. 이 구조는 공용 데이터나 정적에 가까운 콘텐츠에는 강력하다.
하지만 사용자별로 다른 데이터를 보여주는 어드민 서비스나 개인화 화면에서는 이야기가 달라진다. 서버 캐시를 공격적으로 활용하다가는 서로 다른 사용자에게 엉뚱한 데이터를 보여줄 수 있다. 이 팀이 찾은 해법은 대체가 아닌 분업이다. Next.js 캐시는 서버 렌더링 결과와 공용 데이터의 재사용을 담당하고, TanStack Query는 브라우저에서 서버 상태의 생명주기를 관리한다.
실제 패턴은 이렇다. 서버 컴포넌트에서 prefetchQuery로 초기 데이터를 미리 가져와 HydrationBoundary로 클라이언트에 전달한다. 이후 TanStack Query가 staleTime 기반으로 데이터 신선도를 관리하고, mutation 이후엔 invalidateQueries로 관련 데이터를 정밀하게 무효화한다. Query Key는 페이지 내부에 흩어지지 않고 도메인 단위의 공통 영역에서 중앙 관리한다. 이 설계 덕분에 팀 전체가 일관된 서버 상태 관리 컨벤션을 공유할 수 있었다고 한다.
이 사례가 말해주는 건 기술 선택의 문제가 아니다. 서버에서 재사용할 데이터와 클라이언트에서 지속적으로 동기화할 데이터를 명확히 구분하는 설계 사고가 핵심이다. 도구는 그 결정을 실행하는 수단일 뿐이다.
3단계: 데이터를 경험으로 바꾸는 설계 — WebGL 데이터 시각화
dev.to에 공개된 BTC War 프로젝트는 '데이터를 어떻게 보여줄 것인가'라는 오래된 질문에 새로운 방식으로 답한다. 비트코인 시장 데이터는 숫자로는 빠르게 읽히지 않는다. 가격, 스프레드, 잔존 유동성, 체결된 매수·매도 볼륨, 변화 속도를 동시에 추적하는 건 인간의 주의력 한계를 시험하는 일이다.
이 프로젝트가 선택한 방식은 시장 구조를 전장 메타포로 매핑하는 것이다. 매수세와 매도세가 각각 대립하는 진영을 차지하고, 현재 가격이 경계선을 형성하며, 체결된 거래가 움직임과 충격으로 표현된다. Binance 퍼블릭 스트림에서 받은 BTC/USDT 데이터가 WebGL 씬으로 실시간 렌더링된다.
하지만 이 프로젝트가 기술적 과시에 그치지 않는 이유는 제약 설계에 있다. 스펙터클은 허용하되, 조작된 확신은 없다는 원칙이다. 얇은 호가창이 강한 벽처럼 보이거나, 거래 애니메이션이 다음 가격 방향을 암시해선 안 된다. 시각적 효과는 항상 실제 데이터에 종속되어야 한다. 또한 3D 씬에 관심 없는 방문자를 위한 정적 가격 페이지도 별도로 제공한다. 모든 사용자를 같은 경험으로 밀어붙이지 않는 설계다.
실시간 스트림과 WebGL 렌더링을 동시에 처리하는 브라우저 성능 예산 관리, 스트림 단절 시 우아한 복구 설계, 정보 계층을 시각적 우선순위에 맞게 배분하는 방식까지 — 이 사례는 데이터 시각화가 단순한 차트 라이브러리 선택이 아니라 UX 설계의 영역임을 잘 보여준다.
세 사례가 하나의 흐름으로 수렴하는 지점
세 사례를 순서대로 보면 하나의 개발 철학이 보인다. AI 도구(Cursor + MCP)로 구현의 진입 장벽을 낮추고, 캐싱 설계(Next.js + TanStack Query)로 사용자 경험을 정밀하게 제어하고, 시각화 UX(WebGL)로 데이터를 의미 있는 경험으로 변환한다. 각 단계는 독립적이지만, 이 순서로 쌓일 때 '빠르게 만들고 잘 동작하고 사용자에게 진짜 도움이 되는' 제품이 완성된다.
특히 주목할 부분은 세 사례 모두 도구 자체보다 설계 결정을 강조한다는 점이다. MCP는 AI가 '추측' 대신 '명세'를 읽게 한다. TanStack Query는 Next.js 캐시를 대체하는 게 아니라 보완한다. WebGL 시각화는 스펙터클이 아닌 데이터 충실성을 우선한다. 도구를 선택하기 전에 무엇을, 왜 해결하려는지를 먼저 정의하는 팀만이 이 도구들을 제대로 활용할 수 있다.
AI 시대 프론트엔드 개발자의 역할은 코드를 타이핑하는 데서 '어떤 경험을 설계할 것인가'를 결정하는 쪽으로 무게중심이 이동하고 있다. Cursor가 FFmpeg 플래그를 대신 써줄 수는 있지만, 그 기능이 사용자에게 진짜 필요한지를 판단하는 건 여전히 사람의 몫이다.