서론

최근 풀스택 앱 개발 경험이 상당히 변하고 있다고 느끼고 있습니다.

조금 전까지만 해도 "스마트폰으로 개발한다"라고 하면, GitHub의 PR을 보거나 가볍게 리뷰 코멘트를 남기는 정도의 이미지였습니다.

하지만 지금은, Claude Code on the web으로 GitHub 상의 리포지토리(Repository)를 직접 만지고, Vercel Preview Deployment로 확인하며, Supabase로 DB/Auth를 갖추고, Doppler로 환경 변수를 관리하는 구성이 상당히 현실적으로 다가오고 있습니다.

이 부분들이 맞물리면, 이제 평범하게,

이불 속에서 스마트폰을 만지면서 풀스택 앱의 수정을 넣고, Preview 환경에서 확인하는

식의 작업이 가능해집니다.

이 기사에서는 Claude Code on the web × Vercel × Supabase × Doppler를 조합하여, PC를 열지 않고도 풀스택 개발을 진전시키기 쉽게 만드는 구성에 대해 쓰겠습니다.

참고로, Vercel Services / Vercel Container Images는 beta 단계이며, 저 자신도 이제부터 본격적으로 시도해 나가는 단계입니다. 이 기사는 "완전 운용 중인 구성 소개"라기보다, Claude Code on the web 시대에 상당히 좋아 보이는 구성의 정리입니다.

무엇이 좋은가

가장 좋은 점은, 구현부터 확인까지의 루프가 클라우드 상에서 돌아간다는 것입니다.

기존에는,

Frontend: Vercel
Backend: Railway / Render / Fly.io 등
DB/Auth: Supabase
...

와 같이 환경이 나뉘기 쉬웠습니다.

물론 이대로도 동작합니다.

다만, Claude Code on the web과 같은 클라우드 상의 AI 개발 환경을 중심으로 둔다면, frontend, backend, Preview 환경, 환경 변수, DB/Auth 연동은 가능한 한 가까운 곳에서 다룰 수 있는 편이 편합니다.

그래서 눈여겨보고 있는 것이 Vercel Services와 Vercel Container Images입니다.

Vercel Services는 하나의 Vercel Project 내에 여러 개의 frontend/backend service를 deploy할 수 있는 메커니즘입니다. 공식 문서에서는 Next.js frontend와 FastAPI backend를 동일한 repository 내에서 deploy하고, routing, environment variables, domain을 공유할 수 있다고 설명되어 있습니다.

나아가, Vercel Container Images에서는 Dockerfile.vercel 또는 Containerfile.vercel을 배치함으로써, Vercel Functions 상에서 OCI 호환 컨테이너 이미지(container image)를 실행할 수 있습니다.

즉, Next.js뿐만 아니라 FastAPI나 Go 등의 backend도 Vercel 측으로 모을 수 있는 가능성이 생기고 있습니다.

지향하고 싶은 구성

대략적인 구성은 이렇습니다.

사용하는 것을 정리하면 다음과 같습니다.

영역	사용하는 것
AI 개발 환경	Claude Code on the web
...

이 구성의 포인트는, GitHub PR을 중심으로 개발 루프가 돌아간다는 것입니다.

Claude Code on the web으로 구현한다.

PR을 만든다.

Vercel Preview가 생성된다.

필요하다면 Claude Code on the web에서 Playwright로 Preview URL을 확인한다.

사람도 스마트폰으로 Preview를 본다.

문제가 있다면 그대로 Claude에게 되돌린다.

이 루프를 만들 수 있다면, 개발 경험이 상당히 달라집니다.

Vercel Services로 frontend/backend를 같은 Project로 모으고 싶다

Vercel Services를 사용하면 하나의 Vercel Project 내에 여러 개의 service를 정의할 수 있습니다.

예를 들어, 다음과 같은 모노레포(monorepo) 구성입니다.

.
├── frontend/
│ └── Next.js app
...

vercel.json으로 services를 정의하고, /api/*는 backend로, 그 외에는 frontend로 흐르도록 합니다.

{
"services": {
"frontend": {
...

Vercel Services의 공식 문서에서는 모든 service가 동일한 deployment를 공유한다고 설명합니다.

즉, Preview Deployment가 생성되면, 해당 deployment 안에 frontend service와 backend service를 한꺼번에 담을 수 있는 구성을 취할 수 있습니다.

예를 들어, Preview URL이 다음과 같다고 가정해 봅시다.

[IMG:1]

이때,

/ → frontend service
/api/* → backend service

와 같이 routing할 수 있다면, 동일한 Preview URL에서 frontend/backend가 포함된 동작 확인을 할 수 있습니다.

이는 Claude Code on the web과 궁합이 매우 좋습니다.

Claude에게 구현을 시킨다.

PR을 생성한다.

Vercel Preview가 생성된다.

Preview URL에서 frontend/backend가 포함된 상태로 확인한다.

안 되면 다시 Claude에게 수정을 시킨다.

이 루프를 매우 쉽게 돌릴 수 있게 됩니다.

Dockerfile.vercel로 backend를 제공하고 싶다

더욱 궁금한 점은 Dockerfile.vercel입니다.

Vercel Container Images에서는 project root에 Dockerfile.vercel 또는 Containerfile.vercel을 두면, Vercel이 이를 자동으로 감지하여 container image로서 build 및 deploy할 수 있습니다.

Services와 조합할 경우, frontend/backend 각각의 service에 Dockerfile.vercel을 둘 수도 있습니다.

{
"services": {
"frontend": {
...

예를 들어 FastAPI backend라면, 이미지(image)는 대략 다음과 같습니다.

FROM python:3.13-slim
WORKDIR /app
COPY pyproject.toml uv.lock ./
...

실제로는 project 구성에 맞춰 조정이 필요하지만, 중요한 점은 backend의 실행 환경까지 repository에 가둘 수 있다는 것입니다.

이 점이 Claude Code on the web과 궁합이 좋습니다.

Claude에게 다음과 같이 요청하기가 쉬워집니다.

• backend 구현을 수정해줘
• 필요하다면 Dockerfile.vercel도 조정해줘
• vercel.json의 routing도 확인해줘
• Preview에서 동작하도록 만들어줘

이 부분은 앞으로 직접 테스트해 볼 예정이지만, 기대가 매우 큽니다.

Supabase와 Vercel Preview를 맞물리게 하기

Supabase는 Postgres, Auth, Storage, Edge Functions, Realtime을 한꺼번에 다룰 수 있으므로, 풀스택 애플리케이션의 토대로서 매우 편리합니다.

여기서 중요한 것이 Supabase와 Vercel의 연동입니다.

Vercel Marketplace의 Supabase 연동을 사용하면, Supabase project의 환경 변수를 Vercel projects로 자동 동기화하거나, Supabase Preview branches에 redirect URL을 자동으로 생성할 수 있습니다.

Preview 환경에서 흔히 겪는 고충 중 하나는 다음과 같습니다.

- frontend preview는 떠 있다
- 하지만 backend는 staging을 바라본다
- DB도 staging을 공유한다
...

이런 상황이라면, 어렵게 PR마다 Preview를 띄워봤자 결국 제대로 된 검증을 할 수 없습니다.

Vercel Preview Deployment, Supabase 연동, 그리고 Doppler의 환경 변수 관리가 맞물린다면, PR별 검증 환경이 매우 사용하기 편리해질 것입니다.

Doppler가 매우 중요하다

이 구성에서 가장 핵심적인 부분은 Doppler입니다.

특히 중요한 것은, Claude Code on the web의 개발 환경에 Doppler Service Token을 DOPPLER_TOKEN으로 설정해 두는 것입니다.

이때 사용해야 하는 것은 Personal Access Token이 아니라, 기본적으로 Doppler Service Token입니다.

Doppler의 Service Token은 특정 project / config의 secrets에 접근하기 위한 token입니다. 개인 계정에 광범위하게 연결된 token을 전달하는 것이 아니라, 대상 config로 scope를 제한한 Service Token을 사용하는 것이 중요합니다.

예를 들어 Doppler 측에서 config를 다음과 같이 나눕니다.

dev
stg
prd

그리고 각각의 config에 대해 Service Token을 발행합니다.

DOPPLER_TOKEN=dp.st.dev.xxxx
DOPPLER_TOKEN=dp.st.stg.xxxx
DOPPLER_TOKEN=dp.st.prd.xxxx

Claude Code on the web의 개발 환경에는 기본적으로 dev config용 Service Token을 DOPPLER_TOKEN으로 설정합니다.

그리고 명령어를 실행할 때 doppler run을 사용합니다.

doppler run -- npm run dev

백엔드(backend)라면 예를 들어 다음과 같습니다.

doppler run -- uvicorn app.main:app --host 0.0.0.0 --port 8000

Claude Code on the web에 대량의 .env를 붙여넣을 필요는 없습니다.

전달하는 것은 대상 config로 제한된 Service Token뿐입니다.

실제 secret의 source of truth는 Doppler에 둔 채로, doppler run을 통해 필요한 환경 변수를 읽어옵니다.

이 방식이 상당히 다루기 쉽습니다.

Doppler에서 Vercel Preview로도 주입할 수 있다

Doppler는 Vercel integration도 제공합니다.

Doppler의 Vercel 연동 문서에서는 Vercel의 Development, Preview, Production 각각의 environment마다 integration을 만들고, Vercel project, Vercel environment, Doppler config를 선택하여 sync할 수 있다고 설명되어 있습니다.

즉, 다음과 같은 대응이 가능합니다.

Doppler dev → Vercel Development
Doppler stg → Vercel Preview
Doppler prd → Vercel Production

Vercel의 환경 변수 문서에 따르면, Preview 환경 변수는 production branch 이외의 branch에서 생성되는 Preview Deployment에 적용됩니다. 또한, Preview 환경 변수는 모든 Preview branch를 대상으로 하거나 특정 branch를 대상으로 설정할 수 있습니다.

다만, Doppler의 Vercel integration을 통해 공식적으로 확인할 수 있는 것은 기본적으로 다음과 같은 sync입니다.

Doppler config ↔ Vercel environment

따라서 우선은 다음과 같이 생각하는 것이 안전해 보입니다.

Claude Code on the web → Doppler dev
Vercel Preview → Doppler stg
Vercel Production → Doppler prd

branch마다 세밀하게 Doppler config를 자동으로 전환하는 구성은 별도로 검증해보고 싶습니다.

최종적으로는 Preview 환경에서 확인하면 된다

중요한 것은 Claude Code on the web 위에서 모든 것을 완벽하게 완결 지으려 하지 않는 것입니다.

구현은 Claude Code on the web에 상당히 맡깁니다.

하지만 최종적으로 제대로 작동하는지는 Vercel Preview에서 확인합니다.

이 역할 분담이 딱 적당하다고 생각합니다.

예를 들어, Claude Code on the web에 다음과 같이 요청합니다.

"이 화면에서 backend API를 호출하여 Supabase에 저장할 수 있도록 해줘"

Claude가 frontend, backend, 필요하다면 vercel.json이나 Dockerfile.vercel까지 수정합니다.

그 후 PR을 생성하면 Vercel Preview Deployment가 실행됩니다.

그곳에서 실제로 브라우저나 스마트폰으로 직접 만져봅니다.

만약 화면에서 에러가 발생한다면, 그 에러 메시지나 스크린샷, Network 탭의 정보, Vercel의 로그를 Claude Code on the web에 전달하여,

"Preview에서 이 에러가 발생하고 있으니 수정해줘"

라고 요청하면 됩니다.

AI에게 모든 것을 한 번에 완벽하게 만들게 할 필요는 없습니다.

사람이 Preview 환경에서 직접 만져보며 위화감이나 에러를 찾아내고, 그것을 Claude에게 다시 전달합니다.

이 루프(Loop)를 얼마나 가볍게 돌릴 수 있는지가 중요합니다.

Playwright로 간단한 E2E 확인까지 돌릴 수 있다

게다가 이 구성이라면 간단한 E2E (End-to-End) 확인도 Claude Code on the web에 맡기기가 쉬워집니다.

Vercel Preview URL이 생성되어 있다면, Claude Code on the web에서 Playwright를 사용하여 실제 화면을 열고 최소한의 동작 확인을 수행할 수 있습니다.

예를 들어,

"Preview URL을 Playwright로 열어서 로그인 화면이 표시되는지 확인해줘"
"주요 버튼을 눌러서 화면 전환(Screen Transition)이 깨지지 않았는지 봐줘"
"에러가 발생하면 스크린샷을 찍어서 원인을 조사해줘"

와 같은 의뢰가 가능합니다.

물론 본격적인 E2E 테스트 스위트(Test Suite) 전체를 AI에게 통째로 떠넘기겠다는 뜻은 아닙니다.

다만 UI의 가벼운 확인이나, 화면이 백지로 나오지는 않는지, 주요 동선이 깨지지는 않았는지, API 에러가 발생하지는 않는지 정도의 확인에는 상당히 적합합니다.

사람이 매번 Preview URL을 열어 세세하게 확인하기 전에, Claude 측에서 대략적으로 화면을 만져보게 하는 것.

이것이 가능해지면 UI의 빠른 수정이나 확인 작업이 훨씬 수월해집니다.

누워서라도 개발 루프를 돌릴 수 있다

이 구성이 갖춰지면 개발할 수 있는 장소가 매우 자유로워집니다.

예를 들어, 이불 속에서 스마트폰을 만지면서,

1. Claude Code on the web을 연다
2. 수정 내용을 던진다
3. Claude가 frontend/backend를 수정한다
...

와 같은 일을 할 수 있습니다.

전철 안에서도 마찬가지입니다.

사소한 UI 수정, 경미한 API 수정, 타입 에러 (Type Error) 수정, 환경 변수 누락 확인, Preview에서의 동작 체크 정도라면 PC를 켜기 전에 상당히 진척시킬 수 있습니다.

지금까지는 외출 중에 "아, 여기 고치고 싶다"라고 생각해도,

"나중에 PC 켜면 해야지"

가 되기 일쑤였습니다.

하지만 이 구성이라면 그 자리에서 바로 Claude Code on the web에 던질 수 있습니다.

게다가 단순히 코드만 쓰는 것이 아니라, Preview 환경에서 실제로 확인할 수 있습니다.

이 점이 굉장히 큽니다.

아직 검증하고 싶은 부분

Vercel Services / Container Images에 대해서는 아직 앞으로 제대로 시도해보고 싶은 부분들이 있습니다.

구체적으로는 다음과 같습니다.

- Services에서 frontend/backend를 동일한 Preview Deployment에 올렸을 때의 실제 동작
- /api/* rewrite로 backend에 흘려보내는 구성의 사용 편의성
- Service Bindings의 개발 경험
...

이 글에서 "이 구성이 이미 완전히 완성되었다"라고 말하려는 것이 아닙니다.

오히려,

"Claude Code on the web 중심의 개발 경험을 고려하면, Vercel Services / Container Images / Supabase / Doppler의 조합이 상당히 좋아 보인다"

라는 이야기입니다.

보안 측면에서 주의할 점

Claude Code on the web에 환경 변수를 전달할 때는 신중해야 합니다.

권장하는 방법은 다음과 같습니다.

- .env를 그대로 붙여넣지 않는다
- production secret을 평소의 개발 환경에 전달하지 않는다
- Doppler Service Token을 사용한다
...

Claude Code on the web의 개발 환경에 전달할 때는 기본적으로 dev config의 Service Token을 사용합니다.

staging / production은 배포(deploy) 환경 측에서 다룹니다.

이러한 분리가 중요합니다.

요약

Claude Code on the web, Vercel Services, Vercel Container Images, Supabase, Doppler를 조합하면, PC를 켜지 않고도 풀스택 앱 개발을 상당히 진척시킬 수 있을 것 같습니다.

포인트는 다음과 같습니다.

Claude Code on the web
→ GitHub 상에서 구현
Vercel Services
...

이를 통해,

구현한다
↓
PR(Pull Request)을 생성한다
...

라는 루프를 상당히 원활하게 돌릴 수 있게 됩니다.

단순히 "AI가 코드를 작성해 준다"는 것뿐만 아니라, AI가 작성한 코드를 즉시 Preview (미리보기) 환경에서 확인할 수 있다는 점까지 클라우드 측으로 넘어온 것이 핵심입니다.

이불 속에서도, 전철 안에서도, 잠깐의 여유 시간에도, 풀스택 앱 개발을 앞으로 나아가게 할 수 있습니다.

이를 위한 현실적인 구성으로서, Claude Code on the web × Vercel × Supabase × Doppler는 상당히 좋은 선택지가 될 것 같습니다.

Vercel Services / Container Images는 앞으로 실제로 시도해 볼 예정이므로, 검증이 완료되면 다시 후속 글을 쓰고 싶습니다.

Discussion