AI 서비스 개발 일지 #02 | 왜 Gencow는 Supabase와 비교될까? AI 시대에도 백엔드는 여전히 중요한 이유

본 글은 Gencow 베타 크리에이터 프로그램 참여 과정에서 작성한 사용기입니다. 현재 베타 버전을 기준으로 작성되었으며, 앞으로 실제 서비스를 제작하면서 느낀 점을 지속적으로 기록할 예정입니다.

---

첫 번째 글을 쓰고 가장 궁금했던 것은 'Supabase'였다.

첫 번째 글을 작성하면서 Gencow 공식 문서를 천천히 읽어보기 시작했습니다.

설치 방법과 프로젝트 구조를 살펴보다가 유독 눈에 들어오는 이름이 하나 있었습니다.

바로 Supabase였습니다.

공식 문서에서는 Gencow를 소개하면서 여러 백엔드 서비스와 비교하고 있었는데, 그중에서도 가장 많이 언급되는 서비스가 Supabase였습니다.

사실 저도 Supabase라는 이름은 이전부터 많이 들어봤습니다.

AI를 활용한 서비스 제작 영상을 보다 보면 Cursor와 Supabase를 함께 사용하는 사례가 정말 많았습니다.

'AI에게 코드를 작성하게 하고 Supabase를 연결하면 금방 서비스를 만들 수 있다.'

라는 이야기도 많이 접했습니다.

그래서 자연스럽게 궁금증이 생겼습니다.

"그렇다면 Gencow는 무엇이 다를까?"

이번 글에서는 실제 서비스를 만들어보기 전에 공식 문서를 읽으며 느낀 첫인상과 앞으로 어떤 부분을 집중적으로 비교해 볼 것인지 정리해 보려고 합니다.

---

Supabase는 왜 많은 개발자들이 사용할까?

먼저 Supabase가 무엇인지 간단하게 알아보겠습니다.

Supabase는 PostgreSQL 기반의 Backend as a Service(BaaS) 플랫폼입니다.

쉽게 말하면 서비스를 만들 때 필요한 백엔드 기능을 비교적 쉽게 사용할 수 있도록 만들어진 플랫폼입니다.

대표적으로

• 데이터베이스(Database)
• 로그인(Auth)
• 파일 저장소(Storage)
• 실시간 기능(Realtime)

등을 제공합니다.

예전에는 서비스를 만들기 위해 서버를 직접 구축하고 데이터베이스를 설치하며 로그인 기능도 직접 구현해야 했습니다.

하지만 Supabase를 사용하면 이러한 과정을 상당 부분 줄일 수 있습니다.

그래서 개인 프로젝트나 스타트업, MVP를 만드는 개발자들에게 많이 선택되고 있습니다.

실제로 유튜브나 블로그를 찾아보면

"Cursor + Supabase"

조합으로 서비스를 만드는 콘텐츠도 쉽게 찾아볼 수 있습니다.

저 역시 AI를 활용한 개발을 공부하면서 Supabase를 자주 접했습니다.

그래서 이번 Gencow 프로젝트를 시작하면서도 가장 먼저 비교 대상이 떠오른 서비스가 Supabase였습니다.

---

 

Gencow 공식 문서 (Introduction)

 

---

Gencow는 어떤 방향을 지향하는 걸까?

공식 문서를 읽어보면서 가장 먼저 느낀 것은 Gencow가 단순한 데이터베이스 서비스라기보다 AI와 함께 개발하는 경험 자체를 하나의 흐름으로 만들려고 한다는 점이었습니다.

문서를 보면 가장 먼저 소개하는 내용이

• Frontend + Backend AI Framework
• Vibe Coders
• Ship Fast

입니다.

즉,

AI를 활용하여 빠르게 서비스를 만들고 배포하는 경험 자체를 중요하게 생각하는 것처럼 느껴졌습니다.

또한 프로젝트를 생성하면

• Database
• Auth
• CRUD API
• Realtime
• AI
• File Storage
• Deployment

등이 하나의 프로젝트 안에서 관리되도록 구성되어 있습니다.

아직 실제 서비스를 만들어본 것은 아니지만,

프로젝트 구조를 살펴보면서

"처음부터 백엔드 구조를 고민하는 시간을 줄여주려는 것이 아닐까?"

라는 생각이 들었습니다.

---

Your App
├── gencow/                  ← Backend code (this is what you write)
│   ├── schema.ts            ← Starter tables; prefer `schema-*.ts` per domain as you grow
│   ├── schema-auth.ts       ← User-owned auth tables
│   ├── generated/           ← Server codegen (do not edit by hand)
│   │   ├── schema-auth.gen.ts ← Generated auth schema
│   │   └── db-schema.gen.ts   ← Aggregated schema for typed ctx.db
│   ├── auth.ts              ← Auth config (defineAuth)
│   ├── runtime.ts           ← Typed `procedure`, `httpRoute`, and `createCrud` bound to your schema + auth
│   ├── index.ts             ← Registers procedures & routes (`defineApi`)
│   ├── tasks.ts             ← Example: CRUD + custom procedures (optional)
│   ├── files.ts             ← Example: file upload/download logic (optional)
│   ├── seed.ts              ← Seed data (optional)
│   ├── README.md            ← Auto-generated AI guide
│   └── SECURITY.md          ← Security checklist
├── src/                     ← Vite + React frontend (recommended for new apps)
├── gencow.config.js         ← Project configuration
├── gencow.json              ← Cloud app ID (auto-created on deploy)
├── drizzle.config.ts        ← Database config (PostgreSQL)
└── package.json

---

공식 문서를 보면서 가장 흥미로웠던 부분

공식 문서를 보다 보니 Why Gencow라는 항목이 있었습니다.

이 부분에서는 Gencow와 Supabase, Firebase를 비교한 표가 나옵니다.

물론 공식 문서이기 때문에 Gencow의 장점을 중심으로 작성되어 있습니다.

그래서 이 표만 보고

"Gencow가 무조건 더 좋다."

라고 판단하는 것은 맞지 않다고 생각합니다.

하지만 앞으로 직접 사용하면서 어떤 부분이 실제로 차이가 있는지는 충분히 확인해 볼 수 있을 것 같습니다.

특히 제가 가장 관심 있게 본 부분은

• Schema-first 개발 방식
• AI Components
• CRUD 자동 생성
• Cloud Deploy

였습니다.

실제로 이 부분들이 개발 시간을 얼마나 줄여주는지는 앞으로 프로젝트를 하나씩 만들어 보면서 확인해 보려고 합니다.

---

 

Gencow 공식 문서 (Introduction)

기능	Gencow	Supabase	Firebase
데이터베이스 스키마	Drizzle 기반 TypeScript 코드로 관리	SQL(Console) 기반 관리	NoSQL(Console) 기반 관리
API 생성	procedure + createCrud를 활용한 자동 API 생성	SQL / REST API	Firestore API
인증(Auth)	Better Auth 기반 내장 인증	기본 인증 기능 제공	기본 인증 기능 제공
실시간 기능	WebSocket Push 방식 기본 지원	Realtime Extension 사용	Firestore Listener 사용
파일 저장소	ctx.storage 사용	Storage 제공	Cloud Storage 제공
AI 기능	gencow add AI 명령으로 AI 기능 추가	직접 구현 필요	Vertex AI 연동
Cron 작업(예약 작업)	cron 기능 기본 제공	pg_cron 사용	Cloud Functions 사용
배포(Deploy)	gencow dev 명령으로 배포	Dashboard에서 배포	firebase deploy 명령 사용
셀프 호스팅	✅ 지원 (Docker)	✅ 지원	❌ 미지원
로컬 개발 DB	Cloud PostgreSQL 사용	PostgreSQL 사용	Emulator 사용

---

아직은 비교보다 '검증'이 더 중요하다.

개발 커뮤니티를 보다 보면 종종

"A가 B보다 좋다."

라는 이야기를 쉽게 볼 수 있습니다.

하지만 실제 프로젝트에서는 사용하는 목적이 모두 다릅니다.

누군가는 빠른 MVP가 중요할 수도 있고,

누군가는 커스터마이징이 더 중요할 수도 있습니다.

그래서 이번 프로젝트에서는

어느 서비스가 더 뛰어나다고 결론을 내리기보다

같은 서비스를 직접 만들어 보면서 어떤 차이가 있는지 기록하는 방식으로 진행하려고 합니다.

앞으로 직접 비교해 볼 것들

이번 프로젝트를 시작하면서 스스로 하나의 원칙을 세웠습니다.

'문서를 읽고 판단하지 말고, 직접 만들어 보고 판단하자.'

아직 Gencow를 하루 정도밖에 사용하지 않았기 때문에 어느 서비스가 더 좋다고 이야기하는 것은 무책임할 수도 있습니다.

그래서 앞으로는 같은 기능을 하나씩 만들어 보면서 실제 개발 경험을 비교해 보려고 합니다.

예를 들어 가장 먼저 만들어 볼 서비스는 Todo 서비스입니다.

Todo 서비스는 단순해 보이지만 생각보다 많은 요소를 포함하고 있습니다.

• 데이터베이스 설계
• CRUD(Create, Read, Update, Delete)
• 사용자 인증
• 실시간 데이터 반영
• API 연결

이 모든 과정을 경험할 수 있기 때문입니다.

이후에는 게시판 서비스를 만들어 보려고 합니다.

게시판은 회원가입과 로그인, 글 작성, 수정, 삭제 등 실제 웹 서비스에서 가장 많이 사용하는 기능들을 포함하고 있기 때문에 Gencow가 어느 정도까지 생산성을 높여주는지 확인하기에 적합한 예제라고 생각합니다.

그다음에는 AI 기능도 하나씩 추가해 볼 예정입니다.

예를 들어 OCR(문자인식), AI Chat, RAG(Retrieval-Augmented Generation), 이미지 생성(Text-to-Image) 같은 기능들은 최근 AI 서비스에서 빠질 수 없는 요소가 되었습니다.

과연 이러한 기능들을 Gencow에서는 얼마나 쉽게 추가할 수 있는지도 직접 확인해 보고 싶습니다.

---

제가 가장 기대하는 부분은 '개발 속도'입니다.

사실 요즘은 AI에게 코드를 작성하게 하는 것 자체는 그렇게 놀라운 일이 아닙니다.

Cursor나 Claude Code를 사용해 본 분들이라면 이미 경험해 보셨을 것입니다.

하지만 실제 서비스를 만들다 보면 코드 작성보다 시간이 더 많이 걸리는 작업들이 있습니다.

예를 들면

• 프로젝트 구조 설계
• API 연결
• 데이터베이스 구성
• 사용자 인증
• 환경 변수 설정
• 배포
• 유지보수

이런 작업들입니다.

AI는 코드를 생성해 줄 수 있지만, 이 과정을 모두 자연스럽게 연결하는 것은 또 다른 문제입니다.

그래서 저는 Gencow를 사용하면서 가장 기대하는 부분이 바로 "얼마나 빠르게 서비스를 출시할 수 있는가"입니다.

결국 서비스를 만드는 목적은 코드를 많이 작성하는 것이 아니라 사용자에게 빠르게 가치를 전달하는 것이라고 생각하기 때문입니다.

만약 Gencow가 이런 반복적인 작업들을 줄여준다면 개인 개발자나 작은 팀에게는 꽤 매력적인 선택지가 될 수도 있을 것 같습니다.

물론 이것 역시 앞으로 직접 서비스를 만들어 보면서 검증해 보려고 합니다.

---

앞으로 이 시리즈는 이렇게 진행됩니다.

이번 프로젝트는 단순한 사용 후기로 끝낼 생각이 없습니다.

오히려 하나의 장기 프로젝트처럼 진행해 보려고 합니다.

현재 계획하고 있는 콘텐츠는 다음과 같습니다.

• Gencow Fullstack 템플릿으로 첫 서비스 만들기
• AI에게 Todo 서비스를 만들어 달라고 해보기
• CRUD 기능은 얼마나 쉽게 구현되는가
• 로그인 기능 추가하기
• 게시판 서비스 만들기
• OCR 기능 추가하기
• AI Chat 기능 구현하기
• RAG 기능 적용하기
• 랜딩페이지 제작하기
• 실제 배포 후 사용해 보기

그리고 중간중간

"Supabase에서는 어떻게 구현하는가?"

도 함께 비교해 보려고 합니다.

아직은 Gencow를 처음 사용하는 단계이기 때문에 비교보다는 학습에 가까운 기록이 될 것 같습니다.

하지만 프로젝트가 계속 진행될수록 두 서비스의 차이도 조금씩 보이기 시작할 것이라 기대하고 있습니다.

---

결국 중요한 것은 '얼마나 빨리 만들어서 검증할 수 있는가'

서비스를 만드는 이유는 결국 사용자의 문제를 해결하기 위해서입니다.

좋은 아이디어가 있어도 출시하지 못하면 의미가 없습니다.

요즘 AI 개발이 빠르게 발전하는 이유도 여기에 있다고 생각합니다.

조금 덜 완벽하더라도 빠르게 만들어 보고, 사용자 반응을 확인하고, 다시 개선하는 방식이 점점 더 중요해지고 있습니다.

이번 프로젝트 역시 그런 방향으로 진행해 보려고 합니다.

완벽한 서비스를 만드는 것이 아니라,

'AI와 함께 어디까지 빠르게 서비스를 만들 수 있는지'

그리고

'실제로 수익까지 연결할 수 있는지'

를 직접 검증해 보겠습니다.

---

마무리

첫 번째 글에서는 Gencow를 시작하게 된 이유와 설치 과정을 기록했습니다.

이번 글에서는 공식 문서를 읽으면서 가장 궁금했던 Supabase와의 차이, 그리고 앞으로 어떤 관점으로 Gencow를 사용해 볼 것인지 정리해 보았습니다.

아직 하루밖에 사용하지 않았기 때문에 성급한 결론을 내리지는 않으려고 합니다.

오히려 이 프로젝트를 통해 실제 서비스를 하나씩 만들면서 Gencow의 장점과 아쉬운 점을 솔직하게 기록해 보려고 합니다.

다음 글에서는 드디어 첫 번째 서비스를 만들어 보려고 합니다.

AI에게 Todo 서비스를 만들어 달라고 요청하면 정말 몇 분 만에 동작하는 서비스가 완성될까요?

아니면 결국 사람이 직접 수정해야 하는 부분이 많을까요?

다음 글에서는 실제 개발 과정을 그대로 공유해 보겠습니다.

혹시 Gencow를 사용해 보신 분들이나 Supabase를 사용하고 계신 분들이 있다면 댓글로 경험을 공유해 주세요.

저도 함께 배우면서 이 프로젝트를 계속 이어가 보겠습니다.

---