바이브 코더 Supabase로 DB 설계하다

 

 

DB는 PostgreSQL 기반의 RDMBS 오픈소스인 Supabase를 사용하기로 했다. 향후 빌드할 때 vercel 이라는 툴을 쓰는데 이것과도 연동이 잘 된다고 한다. 물론 Gemini가 추천해줬다.

 

내가 노션 템플릿에서 사용중인 테이블을 기준으로 필드를 작성했다. 제미나이에게 던져주니 컬럼명을 짓고 자료형을 추천해주었다. 그대로 Antigravity에 인풋! Supabase에 입력할 SQL을 짜 주고, Run 하고 알려달란다. 이상 없는 쿼리인지 내가 알 방도가 없는 게 아쉽지만, Gemini와 더블체크하니 괜찮겠지 뭐

 

 

 

테이블이 아름답게 생성됐다. 내 노션 데이터를 CSV로 다운로드 받아서 한꺼번에 밀어넣다가 'NULL'의 습격을 받았다. 엑셀에서는 그저 콤마로 구분된 단어들이었지만, 엄격한 데이터베이스 세계에서는 그들만의 문법이 필요했다. 기획서에 '복수 선택 가능'이라고 적는 건 쉽지만, 그것을 데이터로 실체화할 때는 자료형이라는 보이지 않는 문턱을 넘어야 한다는 것을 배웠다.

 

Gemini는 Antigravity에게 쿼리 짜달라고 시키라는데, 이럴땐 그냥 노가다지 ㅋㅋㅋ 바로 수작업으로 뚱땅뚱땅 처리했다. 데이터가 준비됐으니 이제 대시보드에 얹어보자! 가라 안티그라비티!

 

 

분명 Supabase에는 데이터가 가득한데 프론트에는 보이지 않는다. Antigravity에게 console.log를 작성하고 디버깅을 시켰다. 알고보니 초기에 세운 보안 정책이 너무나 완벽하게 작동하고 있었기 때문이었다. 로그인하지 않은 '외부인'인 나에게는 데이터가 보이지 않는 게 당연한 거였다. 굿

 

Antigravity는 캠페인 리스트를 모두가 볼 수 있게 푸는 A안과 로그인 기능 구현 후 진행하는 B안을 제안했다. A안으로 처리하게 되면 개인화 된 캠페인 관리 솔루션이라는 Nody의 가치가 완전히 사라져 버린다. 서비스 코어를 잡고 권한을 관리하는 기획자의 역할도 무엇보다 중요하다는 점을 깨달았다. 정공법으로 가야한다. 로그인 기능을 구현해보자.