그래서 바이브코딩의 인프라, 뭐 써요?

안녕하세요. 로기에요!

요즘 바이브코딩 정말 많이 하죠.

예전에는 서비스를 하나 만들려면 프론트엔드부터 백엔드, 데이터베이스까지 직접 코드를 작성해야 했는데요.

이제는 AI에게 이렇게 이야기할 수 있습니다.

“로그인 있는 웹서비스 만들어줘.”

“게시판도 추가해줘.”

“관리자 페이지도 만들어줘.”

그러면 생각보다 그럴듯한 결과물이 금방 나와요.

그런데 어느 순간 이런 문제가 생깁니다.

“그래서 이거 어디에 올리지?”

코드는 AI가 만들어줬는데 서비스를 실제 사용자에게 공개하려면 서버가 필요하고, 데이터베이스도 필요하고, 이미지도 저장해야 하고, 도메인도 연결해야 합니다.

바로 여기서 인프라라는 단어가 등장해요.

그리고 찾아보기 시작하면 AWS, Cloudflare, Supabase, Netlify, Render 같은 이름이 줄줄이 나옵니다.

오늘은 바이브코딩으로 서비스를 만들었을 때 어떤 인프라를 선택할 수 있는지 이야기해보려고 해요.

코드를 만들었다고 서비스가 완성된 건 아니에요

우리가 웹서비스 하나를 운영한다고 생각해볼게요.

사용자가 접속할 웹페이지가 있어야 하고, API를 실행할 서버가 필요할 수도 있습니다.

회원가입을 한다면 사용자 정보를 저장해야 하고요.

사진을 올린다면 파일을 저장할 공간도 필요합니다.

여기에 도메인, HTTPS, CDN, 로그, 백업 같은 것들도 하나씩 붙기 시작하죠.

그러다 보면 이런 생각이 들어요.

“나는 서비스를 만들려고 했는데 왜 AWS 공부를 하고 있지?”

특히 바이브코딩에서는 이 문제가 더 크게 느껴집니다.

코드를 만드는 속도는 엄청나게 빨라졌는데, 인프라를 직접 구성하는 순간 갑자기 기존 개발 방식으로 돌아온 것처럼 느껴지거든요.

그래서 요즘은 인프라를 얼마나 세밀하게 구성할 수 있느냐보다 얼마나 적은 관리로 서비스를 운영할 수 있느냐도 꽤 중요한 선택 기준이 됩니다.

일단 인프라 하면 AWS?

AWS는 여전히 클라우드 인프라를 이야기할 때 빼놓기 어려운 서비스입니다.

EC2로 서버를 만들 수도 있고, S3에 파일을 저장할 수도 있고, RDS로 데이터베이스를 운영하거나 Lambda를 이용해 서버리스 구조를 만들 수도 있어요.

필요한 거의 모든 것을 AWS 안에서 구성할 수 있다는 게 가장 큰 장점입니다.

반대로 그게 진입장벽이 되기도 해요.

무엇을 사용할지부터 직접 결정해야 하고 IAM, VPC, 보안 그룹, 리전, 네트워크, 비용 구조 같은 개념도 하나씩 등장합니다.

AI에게 코드를 만들어달라고 해서 30분 만에 프로토타입을 만들었는데 배포하려고 AWS 콘솔을 열었다가 몇 시간을 보내는 상황이 생길 수도 있는 거죠.

물론 규모가 커지고 복잡한 인프라가 필요해진다면 이야기가 달라집니다.

세밀한 인프라 설계와 확장성이 필요할수록 AWS가 제공하는 선택지는 강력합니다.

하지만 “일단 내가 만든 서비스를 빨리 공개해보고 싶다”가 목표라면 처음부터 AWS의 모든 기능을 직접 조합할 필요는 없어요.

그래서 Supabase가 바이브코딩에서 자주 보여요

Supabase는 바이브코딩을 하다 보면 정말 자주 만나게 됩니다.

쉽게 이야기하면 백엔드를 만들 때 필요한 것들을 상당 부분 준비해둔 서비스라고 보면 돼요.

프로젝트를 만들면 PostgreSQL 데이터베이스를 사용할 수 있고 Auth, Storage, Realtime, Edge Functions와 자동 생성 API 등을 함께 제공합니다.

예를 들어 AI에게

“이메일 회원가입 추가해줘.”

“사용자가 작성한 게시물을 DB에 저장해줘.”

“프로필 사진도 업로드할 수 있게 해줘.”

라고 했다고 생각해볼게요.

직접 만든다면 인증 서버부터 DB, 파일 저장소까지 고민할 부분이 많습니다.

Supabase를 사용하면 상당 부분을 이미 준비된 기능과 연결할 수 있어요.

특히 데이터베이스가 실제 PostgreSQL이라는 것도 매력적입니다.

그래서 빠르게 MVP를 만드는 바이브코딩과 궁합이 상당히 좋은 편이에요.

다만 Supabase 하나가 모든 종류의 서버를 완전히 대신한다고 생각하면 곤란합니다.

복잡한 백그라운드 작업이나 특정 런타임이 필요한 서버, 별도의 애플리케이션 서버를 계속 실행해야 하는 구조라면 다른 인프라가 필요할 수 있어요.

Cloudflare는 CDN 회사 아니었어요?

Cloudflare라고 하면 예전에는 CDN이나 DNS, 보안 서비스를 먼저 떠올리는 경우가 많았습니다.

그런데 지금은 이야기가 꽤 달라졌어요.

Cloudflare Workers에서는 서버리스 방식으로 프론트엔드와 백엔드 코드를 실행할 수 있고 D1, R2, KV, Durable Objects, Queues 같은 서비스도 함께 사용할 수 있습니다.

간단하게 보면

Workers → 코드 실행

D1 → SQL 데이터베이스

R2 → 파일 저장

KV → Key-Value 데이터

같은 식으로 조합할 수 있는 거죠.

특히 D1은 SQLite의 SQL 문법을 사용하는 서버리스 데이터베이스이고 Workers와 바로 연결할 수 있습니다.

그래서 Cloudflare 역시 단순히 앞단에서 CDN만 제공하는 서비스가 아니라 애플리케이션 전체를 구성할 수 있는 플랫폼 쪽으로 영역이 넓어지고 있어요.

바이브코딩 관점에서는 꽤 재미있는 선택지입니다.

서버를 직접 관리하지 않으면서 프론트엔드, API, 데이터, 스토리지를 Cloudflare 생태계 안에서 구성할 수 있기 때문이에요.

프론트엔드를 빠르게 공개하고 싶다면 Netlify

Netlify도 Git 저장소와 연결해서 웹서비스를 빠르게 배포할 때 자주 사용하는 플랫폼입니다.

코드를 Git에 올리면 빌드와 배포를 연결하기 쉽고, 변경사항을 실제 배포 전에 확인할 수 있는 Deploy Preview도 제공합니다.

여기에 Functions도 사용할 수 있어요.

Functions를 이용하면 별도의 서버를 직접 운영하지 않고 API나 Webhook, 백그라운드 작업 같은 서버 측 코드를 실행할 수 있습니다.

그러니까 단순한 정적 사이트만 올리는 서비스라고 생각하면 조금 부족합니다.

최근에는 Functions뿐 아니라 데이터베이스, 인증, 스토리지 같은 기능까지 플랫폼 안에서 제공하는 방향으로 확장되고 있어요.

바이브코딩으로 React나 여러 웹 프레임워크 기반 프로젝트를 만들고 일단 인터넷에 빠르게 공개하고 싶을 때 접근하기 쉬운 선택지 중 하나입니다.

“그냥 Node 서버 하나 띄우고 싶은데요?”라면 Render

바이브코딩을 하다 보면 서버리스보다 오히려 평범한 서버가 편할 때도 있습니다.

예를 들어 AI가 NestJS나 Express, FastAPI 서버를 만들어줬다고 해볼게요.

이걸 그대로 실행하고 싶다면 Render 같은 서비스가 상당히 직관적입니다.

Render는 Node.js, Django, FastAPI 등을 Web Service 형태로 실행할 수 있고 Git 저장소와 연결하면 코드 변경에 맞춰 빌드와 배포도 할 수 있습니다. Docker 이미지 배포도 지원합니다.

여기에 PostgreSQL, Key Value, Background Worker, Cron Job 같은 서비스도 함께 구성할 수 있어요.

그래서 구조를 이해하기도 쉽습니다.

프론트엔드는 프론트엔드대로 배포하고,

“내가 만든 백엔드 서버는 Render에서 계속 실행한다.”

이렇게 생각하면 되거든요.

기존 백엔드 개발 방식에 익숙하다면 서버리스 플랫폼보다 오히려 이런 구조가 편하게 느껴질 수도 있습니다.

결국 하나만 골라야 하는 건 아니에요

여기서 중요한 부분이 있습니다.

AWS, Cloudflare, Supabase, Netlify, Render 중에서 반드시 하나만 골라야 하는 건 아니에요.

실제로는 서로 조합하는 게 자연스럽습니다.

예를 들어 프론트엔드는 Netlify에 배포하고 데이터베이스와 인증은 Supabase를 사용할 수 있습니다.

또는 Cloudflare Workers에서 API를 실행하면서 Supabase의 PostgreSQL을 사용할 수도 있고요.

조금 더 전통적인 백엔드가 필요하다면 Render에 서버를 두고 Cloudflare를 DNS와 CDN 앞단에 붙이는 구성도 가능합니다.

결국 중요한 건 “어떤 서비스가 가장 유명한가?”가 아니라 “내 서비스에서 내가 직접 관리하고 싶지 않은 부분이 무엇인가?”예요.

바이브코딩에서는 인프라 선택 기준도 조금 달라져야 해요

예전에는 개발자가 기술 스택을 먼저 결정하고 그 환경에 맞춰 애플리케이션을 만드는 경우가 많았습니다.

하지만 바이브코딩에서는 순서가 조금 바뀔 수 있다고 생각해요.

아이디어를 이야기합니다.

AI가 코드를 만듭니다.

실행해봅니다.

사용자가 생깁니다.

그리고 그때 필요한 인프라가 하나씩 보이기 시작합니다.

초기 서비스라면 처음부터 완벽한 인프라를 설계하는 것보다 빠르게 배포하고 실제 사용자를 만나보는 것이 더 중요할 수도 있어요.

그런 관점에서 보면 Supabase, Cloudflare, Netlify, Render 같은 서비스가 바이브코딩과 잘 맞는 이유도 자연스럽습니다.

개발자가 직접 관리해야 하는 영역을 줄여주기 때문이죠.

그런데 다음 문제는 따로 있습니다

AI가 코드를 만들어주는 시대가 되면서 서비스를 만드는 진입장벽은 확실히 낮아지고 있습니다.

인프라도 점점 관리형 서비스로 넘어가고 있고요.

그런데 서비스를 실제로 운영하기 시작하면 또 다른 질문들이 생깁니다.

트래픽이 갑자기 늘어나면 어떻게 할까요?

DB가 느려지면 누가 알려줄까요?

에러가 계속 발생하면 AI가 알아서 원인을 찾아줄 수 있을까요?

사용자가 특정 화면에서 계속 이탈한다면 그것까지 분석해서 서비스를 수정해줄 수 있을까요?

결국 바이브코딩의 다음 단계는 단순히 “코드를 대신 만들어주는 것”에서 끝나지 않을지도 모르겠습니다.

코드는 이제 대화하면서 만들 수 있으니까요.

어쩌면 앞으로 더 중요한 질문은 이것일지도 모르겠어요.

“인프라까지 내가 직접 관리해야 할까?”