새로운 선택지가 등장했다, 그런데 왜 지금인가
콘퍼런스 현장에서 TanStack Start 이야기가 빠지지 않는다. 아직 Next.js를 대체할 만큼의 생태계 무게감은 없지만, "방향이 다르다"는 인상은 분명하다. dev.to의 한 글(TanStack Start Is Kind of a Big Deal)이 그 이유를 세 가지로 정리했는데, 읽고 나서 단순한 프레임워크 비교 이상의 질문이 남았다. 이건 단지 "Next.js냐 TanStack이냐"의 문제가 아니다. 우리가 AI 도구와 함께 프론트엔드를 설계하는 방식 자체가 바뀌고 있다는 신호다.
TanStack Start가 다른 세 가지 이유
첫째, createServerFn 하나로 읽기와 쓰기를 모두 처리한다. Next.js의 Server Actions는 POST 기반 뮤테이션에 최적화되어 있고, 읽기에는 Server Components나 Route Handler를 따로 쓰는 것이 관례다. TanStack Start는 이 구분 자체를 없앤다. method: 'GET'을 선언하면 동일한 createServerFn 패턴으로 캐시 가능한 데이터 페칭을 처리할 수 있고, 타입은 핸들러 반환부에서 한 번 선언하면 로더를 거쳐 컴포넌트까지 자동으로 흐른다. API 엔드포인트 문자열을 별도로 관리하거나 타입을 두 번 쓸 필요가 없다.
둘째, 검색 파라미터가 라우트 수준에서 타입과 함께 검증된다. Next.js의 useSearchParams는 범용 URLSearchParams를 반환하고, 값 레벨의 타입 안전성을 원하면 nuqs나 next-typesafe-url 같은 서드파티를 추가해야 한다. TanStack Router는 validateSearch를 라우트 정의에 포함시켜, Route.useSearch()가 이미 검증된 타입 객체를 돌려준다. URL 공유와 새로고침 생존을 클라이언트 상태 없이 구현할 수 있다는 건 상태 관리 복잡도를 줄이는 실질적인 이점이다.
셋째, 타입 안전성 체인이 기본값으로 연결된다. 라우트 파라미터, 검색 파라미터, 로더 데이터까지 하나의 타입 시스템 안에서 연결된다는 점이 핵심이다. Next.js typedRoutes는 경로를 타입화하지만 쿼리 스트링 값까지 내려오지는 않는다. TanStack은 이 체인을 옵트인이 아닌 기본 동작으로 제공한다. 단, 이는 컴파일 타임 안전성이다. 런타임 외부 API 응답의 실제 형태를 보장하려면 Zod 같은 스키마 검증을 별도로 얹어야 한다는 점은 솔직하게 짚고 넘어갈 필요가 있다.
AI가 정적 분석에서 멈추는 지점
TanStack Start를 AI 도구로 프로토타이핑할 때 흥미로운 문제가 생긴다. Claude나 Copilot은 createServerFn의 문법을 이해하고 보일러플레이트를 꽤 잘 만들어낸다. 타입 체인 추론도 IDE 지원과 결합하면 속도가 붙는다. 그런데 AI가 가장 자주 틀리는 지점이 있다. 런타임에서 뭔가 실제로 잘못됐을 때다.
이 문제를 정면으로 다룬 접근이 있다. dev.to의 또 다른 글(Debugging with AI: Stop Feeding It Files, Start Feeding It Snapshots)은 AI 디버깅의 고질적인 패턴을 정확히 짚는다. 대부분의 AI 어시스턴트는 버그를 분석할 때 소스 파일을 스캔하고 정적 텍스트로부터 이론을 만들어낸다. 그런데 실제 버그는 런타임 시점의 값, 즉 예상치 못한 페이로드 형태나 잘못된 분기 조건에서 터진다. 소스만 보고 추론하는 AI는 이 지점에서 자주 틀린다.
제안된 해법은 간단하다. AI에게 파일을 주는 대신 런타임 스냅샷을 주라는 것이다. @kaibelmo/snaplog 라이브러리는 이 워크플로우를 체계화한다. AI가 버그 경계를 식별하면, 해당 지점에 snaplog.injectLog()를 임시로 삽입하고, 재현 후 캡처된 구조화 로그를 AI에게 읽힌다. 토큰을 아끼면서도 AI가 추론할 수 있는 사실의 밀도가 높아진다. TanStack Start의 createServerFn 핸들러처럼 서버에서만 실행되는 코드의 버그를 추적할 때 이 접근이 특히 유효하다. 서버 사이드 실행 경로는 브라우저 DevTools로 관찰할 수 없기 때문이다.
그래도 멈춰야 할 지점이 있다
프레임워크가 좋아지고, AI 디버깅 워크플로우가 정교해지면, 한 가지 유혹이 커진다. 더 많이, 더 빠르게 AI에게 맡기는 것. dev.to의 세 번째 글(We're Building the Funnel and Standing Under It)은 이 흐름에 불편한 질문을 던진다. 도구가 보철이 되는 순간은 언제인가.
글이 제시하는 구분이 실용적이다. 도구는 당신이 할 수 있는 것을 확장한다. 보철은 당신이 더 이상 할 수 없게 된 것을 대체한다. 동일한 프롬프트, 동일한 모델도 어떤 개발자에게는 도구고 어떤 개발자에게는 보철이다. "이 버그의 원인을 설명해줘, 다음에 내가 직접 찾을 수 있도록"은 도구의 사용이다. "그냥 통과되게 해줘"는 보철로의 첫 걸음이다. 겉에서 보면 똑같아 보이지만, 차이는 전부 머릿속에 있다.
더 구조적인 우려도 있다. AI가 AI 생성 데이터로 학습되는 재귀 루프, 즉 모델 붕괴(model collapse) 문제다. Shumailov et al.의 2024년 Nature 논문이 문서화한 이 현상은, AI가 반복적으로 자신의 출력으로 학습될 때 원본 데이터의 다양성이 점진적으로 사라진다는 것을 보여준다. 개발자가 직접 쓴 코드, 직접 내린 아키텍처 결정, 직접 발견한 버그 패턴—이 불규칙하고 거친 원본들이 사라지면, AI의 기반이 되는 인간 신호의 품질도 함께 희석된다. 물론 후속 연구는 실제 데이터와 합성 데이터를 축적 방식으로 혼합하면 붕괴를 피할 수 있다고 주장하므로, 이는 예언이 아니라 관리해야 할 리스크다.
설계자의 포지션을 지키는 법
세 가지 흐름을 하나로 연결하면 이런 윤곽이 나온다. TanStack Start는 타입 안전성과 서버-클라이언트 경계를 더 명시적으로 설계할 수 있게 만드는 프레임워크다. AI가 보일러플레이트를 생성하는 속도가 빠를수록, 그 구조가 왜 그렇게 설계됐는지를 이해하는 개발자와 그냥 통과시키는 개발자의 격차가 벌어진다. 런타임 스냅샷 기반 디버깅은 AI를 정적 추론의 한계에서 꺼내 실제 사실 기반으로 작동하게 만드는 워크플로우다. AI에게 더 좋은 컨텍스트를 주는 것이 더 나은 결과를 만든다는 원칙은 여기서도 그대로 통한다. 그리고 의존성의 경계를 긋는 것은, 이 모든 도구를 쓰면서도 판단 주권을 잃지 않기 위한 습관의 문제다.
프레임워크는 계속 나온다. AI 도구는 계속 좋아진다. 그 속도가 빠를수록 진짜 병목은 점점 더 "뭘 선택할 것인가"가 아니라 "어디서 내가 직접 판단할 것인가"로 이동한다. TanStack Start가 흥미로운 건 성능이나 DX 때문만이 아니다. 서버와 클라이언트, 타입과 런타임, 프레임워크와 AI—이 모든 경계를 개발자가 명시적으로 설계하는 구조를 제안하고 있기 때문이다. 그 설계를 AI에게 위임하지 않는 것이, 결국 AI를 더 잘 쓰는 방법이다.