1인 개발 준비하기 시리즈
스택의 중심은 웹 코어 하나입니다. 어떤 제품이든 이 코어를 공유하고, 유형에 따라 감싸는 방식만 달라집니다.
하나의 웹 코어로 시작
웹 코어는 TanStack Start와 React입니다. SaaS든 일반 웹앱이든 공개 사이트든, 서버 렌더링(SSR)이 필요한 제품은 여기서 출발합니다. React 진영에서 가장 대중적인 선택은 Next.js지만 이번에는 고르지 않았습니다. 가장 큰 이유는 4편에서 정한 인프라와 맞물립니다. Next.js는 Vercel을 우선하는 프레임워크라 클라우드플레어에서는 어댑터를 경유해야 하고 그만큼 제약이 따르는 반면, TanStack Start는 클라우드플레어를 정식 파트너로 두고 어댑터 없이 곧장 배포됩니다. 인프라를 클라우드플레어로 정한 이상, 그 위에서 가장 매끄럽게 도는 프레임워크를 고르는 편이 자연스러웠습니다.
이유는 더 있습니다. TanStack Start는 TanStack Router를 기반으로 하기 때문에, 뒤에서 이야기할 어드민 SPA를 만들 때 라우팅을 따로 익힐 필요가 없습니다. 웹 제품과 어드민이 같은 라우터를 공유합니다. 데이터 패칭에서 널리 쓰이는 TanStack Query도 같은 팀이 만들었으니 궁합이 좋으리라 기대했습니다. 정식 버전 직전 단계인 RC(Release Candidate)이긴 하지만 기능은 사실상 완성됐고 API도 안정적이라 호환성을 깨는 큰 변경은 예정에 없고, 하나둘 전환 후기가 올라오는 것도 마음을 놓게 하는 근거였습니다. 무엇보다 테너 린슬리가 예고한 그들만의 방식의 RSC(React Server Components)와 TanStack 생태계 전반에 대한 기대가 컸습니다. 서버 우선 아키텍처에 전부를 내어 주는 대신, RSC를 또 하나의 서버 사이드 상태로 두고 캐싱하고 합성하겠다는 방향입니다. 같은 이유로 SPA도 여전히 일급 시민으로 남습니다.
어드민처럼 서버 렌더링이 필요 없는 내부 도구는 TanStack Router만으로 SPA를 구성합니다. 웹 코어가 이미 Start를 통해 같은 라우터를 쓰고 있으니, 추가 학습 없이 그대로 이어집니다. 순수하게 콘텐츠 중심인 사이트, 이를테면 문서나 블로그, 랜딩은 Astro로 갑니다.
API가 필요하면 Hono로 만들어 Cloudflare Workers에 배포합니다. 워커 하나를 하나의 작은 서비스로 두고, 필요한 자원은 바인딩으로 연결하는 방식입니다. 같은 코드베이스에서 CLI와 MCP 서버를 함께 뽑아 클로드와 연동하면 운영까지 하나의 흐름으로 이어지는데, 이 부분은 확장 이야기에서 다시 다룹니다.
인증은 외부 서비스에 기대지 않고 BetterAuth로 자체 호스팅해 내재화합니다. 4편에서 인증은 내재화하는 편이 낫다고 짧게 언급했는데, 그 이야기입니다.
모바일은 이 웹 코어를 모바일 우선으로 반응형 설계한 뒤 하이브리드로 감싸는 데서 출발합니다.
모바일도 웹에서 시작
모바일 앱도 결국 같은 웹 코어에서 시작합니다. 1편에서 모바일은 초기에 웹뷰를 감싸는 하이브리드로 처리하고 넘어간다고 했는데, 그 방침은 지금도 유효합니다. 모바일 우선으로 반응형을 적용한 웹을 React Native나 Flutter, 또는 안드로이드와 iOS 네이티브 등으로 감싸 앱으로 배포합니다. 무엇으로 감쌀지는 팀 사정과 이후 계획에 따라 달라집니다. 이 부분은 좀 더 연구해 볼 필요가 있어 추후 별도 포스트로 다뤄 보겠습니다.
핵심은 처음부터 전부 네이티브로 만들지 않는다는 데 있습니다. 하이브리드로 출발한 뒤, 성능이 중요하거나 UI/UX가 중요한 화면만 골라 점진적으로 네이티브로 옮깁니다. 반대로 공지사항이나 마케팅, 이벤트처럼 자주 바뀌고 앱 심사와 무관하게 갱신하고 싶은 부분은 웹으로 남겨 둡니다. 초기 네이티브 전환은 기능을 늘리기보다 동작의 자연스러움과 성능에 초점을 맞추는 편이 좋습니다. 사용자가 가장 먼저 체감하는 지점이 바로 거기이기 때문입니다.
이 전략이 성립하려면 한 가지 원칙이 필요합니다. 비즈니스 로직은 가능한 한 서버로 밀어 두고, 프론트는 화면을 그리는 역할에 가깝게 두는 것입니다. 로직이 프론트에 두껍게 얹혀 있으면 플랫폼마다 그것을 다시 구현하게 되고, 네이티브로 옮기는 순간마다 부담이 커집니다. 반대로 로직이 서버에 모여 있으면, 프론트가 웹이든 네이티브든 같은 서버를 바라보기만 하면 되므로 전환이 한결 가벼워집니다.
안드로이드와 iOS 네이티브 개발자들은 앱 안에 클린 아키텍처를 비롯한 여러 구조를 독립적으로 적용하려 애쓰는 경우가 많습니다. 필요한 부분이 없지는 않지만, 설계가 지나치고 레이어가 잘게 나뉠수록 복잡도가 올라가 초기 생산성이 떨어집니다. 하나의 서비스를 이루는 시스템 전체로 보면 앱의 본질은 프레젠테이션 레이어입니다. 담당 개발자는 자기 구현에만 몰두하기 쉽지만, 지금 비즈니스가 어느 단계에 와 있는지 파악하는 일이 무엇보다 중요합니다.
확장은 필요해진 다음에
여기까지가 출발 지점의 스택입니다. 중요한 것은 이 스택이 성공을 전제로 처음부터 크게 설계되지 않았다는 점입니다. 필요가 생길 때, 그러니까 서비스가 어느 정도 성공했을 때 그만큼만 확장합니다.
처음에는 웹 워커 하나가 데이터베이스를 직접 바라보게 둡니다. 공통 로직을 별도 패키지로 빼 두면, 웹은 별도의 API 호출 없이 그 로직으로 데이터를 읽습니다. 거의 모노리스처럼 단순합니다. 그러다 CLI나 어드민, 혹은 외부에서 같은 데이터를 필요로 하는 순간이 오면, 같은 로직을 API 워커로 떼어내 HTTP로 엽니다. 로직 자체는 그대로이므로 다시 짤 일이 없습니다. 웹은 계속 직접 읽고, 새로 붙는 클라이언트는 API를 거칩니다.
서비스가 더 늘면 워커를 더 쪼갭니다. 도메인 하나에 가벼운 게이트웨이 워커를 두고 기능별로 경로를 나눠 독립 워커에 매핑하면, 각 기능이 독립적으로 배포되고 확장됩니다. 워커끼리 내부에서 호출해야 할 때는 서비스 바인딩으로 잇습니다. 같은 스레드에서 지연 없이, 추가 비용 없이 이어집니다. 모노리스인 듯 아닌 듯 여러 워커를 두는 데 부담을 느낄 필요가 없습니다. 필요한 만큼 나누고, 필요 없으면 합쳐 두면 그만입니다.
인프라도 같은 방식으로 넓혀 갑니다. 처음에는 워커와 R2만으로 이미지를 다루다가, 리사이징이나 최적화가 본격적으로 필요해지면 Cloudflare Images로 옮깁니다. 데이터베이스는 D1의 SQLite로 시작하되, 기능이나 성능이 부족해지는 시점이 오면 Neon과 Hyperdrive를 얹어 정식 PostgreSQL로 전환합니다. 어느 쪽이든 처음부터 큰 것을 들이지 않고, 벽에 부딪히는 그 지점에서만 한 칸씩 올립니다.
인증도 마찬가지입니다. 인증 자체는 BetterAuth로 내재화해 워커 안에서 끝나지만, 인증 과정에서 사용자에게 메일을 보내야 하는 경우에는 전송 수단을 하나 붙여야 합니다. 지금은 Resend 같은 외부 발송 서비스를 연결하거나, 아예 구글 같은 소셜 로그인만 지원해 메일 발송 자체를 없애는 방법이 있습니다. 다만 이 의존도 오래가지 않을 것 같습니다. Cloudflare Email Service가 지금은 비공개 베타지만 가까운 시일에 열리면, 이미지에 이어 이메일까지 플랫폼 안으로 들어와 커버리지가 한층 넓어집니다.
마지막은 운영입니다. 확장이 진행될수록 손이 가는 곳도 늘어납니다. 이때 필요한 것이 앞서 말한 CLI와 MCP 서버입니다. API를 그대로 소비하는 얇은 CLI를 두면 반복 작업을 명령 한 줄로 처리할 수 있고, 같은 API를 MCP로 노출해 클로드와 연동하면 운영의 상당 부분을 대화로 넘길 수 있습니다.
덧붙이면 여기 적은 것이 전부 검증된 이야기는 아닙니다. 직접 만들어 확인한 부분이 있고, 아직 계획에 머문 부분도 있습니다. Cloudflare Email Service나 Hyperdrive와 Neon 조합이 후자입니다. 포트폴리오와 데모 프로젝트를 진행하면서 다듬어 볼 생각이고, 그 과정은 따로 포스트로 공유하겠습니다.
참고
Why choose TanStack Start and Router? - 타입 안전 라우팅, SPA 지원, Query 통합, RSC를 서버 사이드 상태로 다루는 방향
TanStack Start v1 Release Candidate - RC 도달, API 안정, RSC 지원 예고
Why Cloudflare, Netlify, and Webflow are collaborating to support Open Source tools like Astro and TanStack - 클라우드플레어의 Astro·TanStack 후원과 파트너십
Announcing Cloudflare Email Service's private beta - 워커 바인딩 기반 이메일 발송, 비공개 베타