PostgreSQL용 최고의 AI 빌더는 통제권을 준다

기존 PostgreSQL 데이터베이스가 있으면 구매 기준이 달라진다. AI 빌더에게 프로토타입용 테이블 몇 개를 만들라고 하는 일이 아니다. 생성된 코드에 이미 중요한 데이터, 제약 조건, 확장 기능, 마이그레이션 기록, 운영 관행을 맡기는 일이다.

2026년에 일반적인 PostgreSQL을 다룬다면 네 제품 중 Replit이 가장 좋은 출발점이다. 실제 런타임, 셸, 암호화된 Secrets가 있고 원하는 드라이버와 마이그레이션 도구를 사용할 수 있기 때문이다. 앱이 Vercel에 속하고 데이터베이스가 Neon, Supabase 또는 일반 연결 문자열로 접근 가능한 서비스라면 v0가 근소하게 뒤를 잇는다. Lovable과 Bolt는 기존 Supabase에서 더 빠를 수 있지만, 그 쉬운 경로는 Supabase용이지 PostgreSQL 전반을 위한 것이 아니다.

단, 어느 제품에도 production owner 자격 증명을 주고 즉흥적으로 스키마를 바꾸게 해서는 안 된다. 탐색을 제한하고, 마이그레이션을 검토하며, 연결 동작을 명시할 수 있는 빌더가 승자다. 보기 좋은 데이터베이스 버튼은 이 문제를 해결하지 못한다.

기존 PostgreSQL도 한 가지 경우가 아니다

최선의 선택은 시스템에서 "기존"이 무엇을 뜻하는지에 달렸다. Supabase 프로젝트, Neon 데이터베이스, private network 안의 PostgreSQL cluster, 사용자 정의 타입을 가진 15년 된 데이터베이스는 모두 PostgreSQL이지만 빌더가 접근하는 control plane은 다르다.

Lovable은 기존 Supabase 프로젝트를 선택하는 직접 연동을 문서화했다. Bolt도 연결할 수 있지만 새 Claude Agent 프로젝트의 기본값은 Bolt Database다. v0는 Vercel Marketplace에서 Neon과 Supabase를 제공하고 프로젝트 변수도 받는다. Replit은 DATABASE_URL을 암호화된 secret으로 저장하고 일반 PostgreSQL client와 migration tool을 실행할 수 있는 runtime을 제공한다.

실무 선택은 네 가지다.

• Supabase의 auth, storage, function, table 위에 웹 UI를 만들면 Lovable.
• Supabase를 쓰며 지원 stack과 browser workspace가 맞으면 Bolt.
• Next.js나 React를 Vercel에 배포하고 Marketplace 연동 또는 표준 연결 문자열을 쓰면 v0.
• 임의의 PostgreSQL, custom server, 생성 backend의 직접 검토가 필요하면 Replit.

연결은 스키마 탐색이 아니다. public.customers를 읽는 client도 partial index, deferred constraint, row security, trigger, domain, 안전한 view를 모를 수 있다. 연결 버튼은 자격 증명 전달로 보고 탐색은 따로 시험한다.

넓은 비교에서는 Replit이 이기지만 한계가 있다

Replit은 hosted development environment에 가장 가깝다. 코드를 import하고 기존 DB package를 설치하며 Secrets에 자격 증명을 넣고 shell에서 SQL과 migration을 실행할 수 있다. 생성 파일을 확인하고 server process도 배포한다. 데이터베이스가 다른 회사 marketplace 상품이 아닐 때 이 자유가 중요하다.

v0가 두 번째다. 2026 project model은 chat을 Vercel project에 연결하고 encrypted variable을 project 단위로 보관하며 예전 browser preview보다 production에 가까운 sandbox에서 server code를 실행한다. 지원 SQL 연동에서는 SQL 생성과 실행도 가능하다. 데이터베이스 주변의 Next.js 앱을 만드는 데 강하지만 Vercel, Next.js 관례, 그 환경의 provider 쪽으로 기운다.

Lovable과 Bolt는 더 좁은 공동 3위다. "PostgreSQL"이 사실 "기존 Supabase"라면 첫날에는 Replit보다 편하다. 연동이 project context를 주고 흔한 auth와 data flow를 쉽게 만든다. 이 경로 밖에서는 수동 설정이 빠르게 늘어난다. Lovable의 외부 hosting 문서도 standalone PostgreSQL이 Supabase auth, storage, realtime, edge service를 대체하지 않는다고 밝힌다. Postgres URL 하나로 모든 backend가 교환 가능해지는 것은 아니다.

Replit은 임의 URL, custom schema inspection, app pool 제어에서 앞선다. repository와 기존 migration tool을 권위 있는 원본으로 유지할 수 있다. 다만 Secrets는 환경 변수로 code에 전달되므로 무엇을 출력하고 어느 process가 받는지 통제해야 한다.

v0도 server code가 DB에 닿으면 유연하다. imported repository, encrypted Vercel variable, 지원 연동을 함께 쓸 때 강하다. 설정 관례는 편하지만 migration review와 connection budget은 팀 책임이다.

Bolt와 Lovable은 기존 Supabase 직접 연결에서 앞선다. 설정은 적지만 생성 schema 변경은 검토해야 하고 pooling은 대체로 provider가 결정한다. Supabase 밖에서는 UI가 암시하는 것보다 수동 architecture가 많다.

안전한 development 사본이 없을 때도 결과가 바뀐다. Replit과 v0는 어떤 URL로든 향하기 쉬우므로 권한을 더 좁혀야 한다. 좁은 연동도 실제 permission이 좁지 않으면 안전하지 않다. 제품 종류는 grant, audit log, isolated DB를 대체하지 않는다.

Replit의 자유는 올바른 방식과 잘못된 명령 모두를 허용한다. Bolt와 Lovable의 좁은 연동은 설정을 줄이지만 서비스 경계를 숨길 수 있다. v0의 편한 variable propagation도 과도한 credential을 preview로 보낼 수 있다.

스키마 탐색은 제한된 role로 시작한다

migration이나 backup 계정이 아니라 metadata와 선택한 development data만 읽는 전용 login을 준다. 첫 실행은 검토할 inventory만 만들어야 하며 생성 code를 맞추려고 table을 바꾸면 안 된다.

이식 가능한 구조는 information_schema, PostgreSQL 고유 index, policy, extension, constraint는 pg_catalog에서 찾는다. table과 column 이름만 보면 쓰기 규칙을 놓친다. schema, table, view, primary와 foreign key, unique constraint, index, enum, domain, generated column, trigger, row policy, trigger function, extension을 보고하게 한다.

버릴 수 있는 branch 또는 staging에 탐색 role을 만들고 schema와 grant를 조정한다.

CREATE ROLE builder_reader LOGIN PASSWORD 'replace-at-secret-store';
GRANT CONNECT ON DATABASE app_staging TO builder_reader;
GRANT USAGE ON SCHEMA app, reporting TO builder_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA app, reporting TO builder_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA app
  GRANT SELECT ON TABLES TO builder_reader;

password를 chat에 붙이지 말고 Replit Secrets, v0 project variable, Lovable 또는 Bolt provider 설정에 넣는다. source는 환경에서 DATABASE_URL을 읽는다. 생성 파일에 URL이 그대로 있으면 삭제하고 credential을 rotate한 뒤 version history를 살핀다.

inventory는 사람이 확인해야 한다. view는 앱이 읽어도 되는 column만 노출할 수 있다. users는 auth subsystem의 내부 table일 수 있다. trigger가 audit table을 채우는데 생성 bulk import가 필요한 session variable을 설정하는 업무 경로를 우회할 수도 있다. 탐색은 존재를 알려 주지 소유권을 알려 주지 않는다.

custom command가 필요하면 Replit이 가장 쉽고 v0도 연동이나 terminal로 처리한다. Supabase 안에서는 Lovable과 Bolt가 맥락을 더 잘 알지만, 명시적 inventory를 받아 source control의 migration과 비교해야 한다.

생성 품질보다 마이그레이션 통제가 중요하다

유용한 builder는 기존 pipeline이 검토하고 적용할 migration file을 쓴다. 위험한 builder는 SQL 실행 성공을 production 적용 근거로 삼는다.

migration authority는 하나만 둔다. Prisma Migrate, Drizzle Kit, Flyway, Liquibase, Alembic, Rails, 번호 SQL 중 기존 system과 같은 것을 사용한다. Dashboard 변경, ORM auto sync, generated SQL folder가 함께 current schema를 설명하면 갈라지고 restore나 새 환경에서 드러난다.

Lovable 외부 deployment 문서는 migration이 supabase/migrations/에 있고 이동 시 timestamp 순으로 실행된다고 말한다. 좋은 증거지만 안전 보장은 아니다. policy, function, trigger, destructive statement를 읽는다. Bolt도 같다. v0는 chat history가 아니라 repository에 남기고, Replit은 command, file, diff를 보여 주게 한다.

credential을 둘로 나눈다.

DATABASE_URL=postgresql://app_runtime:[email protected]/app
MIGRATION_DATABASE_URL=postgresql://app_migrator:[email protected]/app

runtime role은 필요한 table과 operation만 받고 migrator는 승인된 object만 바꾼다. deployment는 후자를 migration job에만 준다. 검토된 migration을 isolated DB에 적용할 때가 아니면 preview에 MIGRATION_DATABASE_URL을 주지 않는다.

흔한 실패는 preview의 missing column error에서 시작한다. agent가 owner URL로 column을 직접 추가하고 ORM model을 고친다. preview는 정상이나 migration file은 없다. 새 DB build는 repository가 옛 schema를 설명하므로 실패한다. production까지 직접 바뀌었다면 rollback은 기억과 log에 의존한다. 앱은 우연한 한 상태에서만 재현된다.

Secret 저장만으로 안전해지지 않는다

네 제품 모두 비밀번호 hard coding은 피하지만 Secret이 읽히는 경계가 중요하다. 저장 화면이 암호화돼도 실행 process는 값을 받으며 generated server code, build log, browser bundle, debug endpoint, agent command가 노출할 수 있다.

Replit 문서는 Secrets가 환경 변수로 전달되고 DATABASE_URL을 포함한다고 설명하며 code가 이를 출력할 수 있다고 경고한다. 설정 화면 permission만으로 막을 수 없다. v0도 project variable을 암호화해 Vercel과 공유한다. NEXT_PUBLIC_는 client 변수이므로 DB credential에 붙이지 않는다.

Supabase를 쓰는 Lovable과 Bolt에서는 public client config와 privileged server credential을 분리한다. public key는 row policy가 접근을 강제할 때 client에서 쓸 수 있다. service role과 direct URL은 server에만 둔다. generated query를 고치려고 row security를 끄면 browser access를 허용한 통제가 사라진다.

local, preview, automated test, staging, production의 credential을 나눈다. preview는 synthetic 또는 scrubbed data를 쓴다. shared staging schema보다 DB branch가 낫다. 첫 prompt 전에 누가 password를 바꾸고 어디에 저장하며 어떤 deployment를 restart할지 정한다.

export에는 variable name과 setup note만 있고 값은 없어야 한다. Koder.ai는 source export, deployment, hosting, snapshot, rollback을 지원한다. 같은 규칙으로 Secret을 source 밖에 두고 schema change를 검토한다. 제품 snapshot은 PostgreSQL backup이나 검증된 migration rollback을 대신하지 않는다.

Connection pooling은 앱 설계에 속한다

안전한 pool size는 prompt만으로 정할 수 없다. DB connection limit, app instance 수, deployment concurrency, transaction 길이, PgBouncer 같은 proxy에 달렸다.

instance마다 10개를 열고 burst가 20 instance를 만들면 job과 migration 전에 200개를 요청한다. provider는 대기시키거나 거부한다. limit 증가는 증상만 다루고 memory를 늘릴 수 있다.

pooled endpoint와 direct endpoint를 구분한다. app은 보통 pooled URL을 쓰며 session state, advisory lock, 특별한 DDL이 필요한 migration은 direct URL이 필요할 수 있다. transaction pooling은 session이 유지된다고 가정한 code를 깨뜨린다. prepared statement도 driver와 pooler 설정이 맞아야 한다.

library default에 맡기지 말고 code에 제한을 쓴다.

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: Number(process.env.DB_POOL_MAX ?? 5),
  idleTimeoutMillis: 20_000,
  connectionTimeoutMillis: 5_000,
  ssl: { rejectUnauthorized: true }
})

값은 예시다. 운영 connection을 남기고 나머지를 최대 instance로 나누며 겹치는 deployment 여유를 둔다. provider의 TLS 검증 방식을 확인한다. preview 실패 때문에 rejectUnauthorized: false로 바꾸는 것은 위험하다.

Replit은 driver와 장기 server process를 직접 통제한다. v0도 code control은 비슷하지만 Vercel scale에는 명시적 limit와 serverless 친화 provider가 필요하다. Bolt와 Lovable은 Supabase pooling을 물려받는 경우가 많지만 URL 종류, ORM 지원, migration endpoint는 확인해야 한다.

수동 설정이 실제 차이를 드러낸다

공정한 시험은 같은 staging DB, schema brief, acceptance test를 쓴다. 한 제품의 managed wizard와 다른 제품의 private legacy cluster 수동 연결을 비교해 지능 차이라고 부르면 안 된다.

Replit에서는 app을 import하거나 만들고 staging DATABASE_URL을 Secrets에 추가하며 기존 driver와 migration tool을 설치한다. code 작성 전에 inventory를 요구한다. DB가 private network에서만 보이면 network access부터 확인한다. Replit의 자유가 firewall을 통과시켜 주지는 않는다.

v0에서는 올바른 Vercel project에 chat을 연결하고 맞는 Marketplace 연동이나 project variable을 쓴다. development, preview, production에 어느 값이 도달하는지 확인한다. migration이 든 repository를 import하고 기존 data layer를 보존시킨다.

Bolt에서는 생성 시 Supabase를 고르거나 기존 project를 연결한다. 현재 문서는 Supabase가 Vite project에서 가능하고 Next.js는 지원하지 않는다고 한다. 이 제한으로 시험 stack을 정한다. 일반 PostgreSQL에는 server 또는 API boundary를 직접 구성한다.

Lovable에서는 Supabase 조직과 project를 연결하고 client, policy, function, migration을 검토한다. 일반 PostgreSQL은 다른 Supabase 기능을 대체할 API나 server가 필요하며, 연결은 자체 architecture가 된다.

network reachability를 별도로 시험한다. subnet, VPN, fixed IP만 받는 DB는 모든 hosted preview를 거부할 수 있다. 인터넷에 열지 말고 private connector, internal API, temporary branch, 이미 접근 가능한 infrastructure로의 deployment를 선택한다. 경로를 못 쓰는 builder는 incompatible이다.

오래된 schema는 type support도 시험한다. numeric, timestamptz, jsonb, enum, array, nullable foreign key를 읽고 쓴다. JavaScript driver는 precision 유지를 위해 큰 integer와 exact numeric을 string으로 반환할 수 있다. 생성 form이 Number()로 바꾸면 DB error 없이 ID나 금액이 손상된다. timezone offset 제거도 같은 함정이다.

소유권 경계도 시험한다. app schema table, reporting view, runtime이 못 읽는 internal table을 둔다. 앞의 둘은 쓰고 세 번째 거부는 더 넓은 grant 없이 처리해야 한다. agent가 GRANT ALL을 답하면 중단한다. permission error는 경계가 작동한다는 증거다.

isolated DB에서 migration을 중간에 실패시킨다. 좋은 flow는 명확한 error를 남기고 적용 완료로 표시하지 않으며 migration system으로 수정할 수 있다. PostgreSQL DDL 상당수는 transaction 안에서 실행되지만 일부 concurrent index 명령은 특별한 규칙이 있다. prompt가 아니라 migration tool이 결정한다.

재현 가능한 acceptance 순서다.

1. 탐색 credential로 trigger, nonpublic schema, index, row policy를 포함한 inventory를 만든다.
2. nullable column과 index 같은 additive migration을 기존 형식으로 만들고 branch 적용 전에 검토한다.
3. runtime role로 읽는 page와 허용된 한 record를 쓰는 server action을 만들고 browser에 privileged credential을 보내지 않는다.
4. concurrent request로 pool metric을 보고 instance 수와 pool size의 곱을 budget 안에 둔다.
5. source와 migration으로 새 환경을 만들고 preview password를 rotate해 이전 것이 실패하는지 확인한다.

이 시험은 builder가 DB를 이해하는지, privileged URL이 실수를 감춘 것인지 보여 준다.

Production 접근은 좁은 gate를 통과해야 한다

일상 기능 작업에서 agent를 production에 직접 연결하지 않는다. scrubbed data가 든 DB branch나 restored snapshot을 주고, review된 code와 migration을 신뢰하는 deployment process로 옮긴다.

gate에는 네 검사가 있다. 사람이 generated SQL과 permission을 본다. automated test가 migration으로 새 DB를 만든다. release가 dedicated credential로 migration을 실행하고 version을 기록한다. monitoring이 connection saturation, slow query, lock wait, application error를 본다.

rollback은 code, schema, data 계획이 따로 필요하다. code 복구는 즉시 가능해도 column 삭제는 정보를 없앤다. compatible column을 추가하고 두 상태를 지원하는 code를 배포하며 batch backfill 후 read를 전환하고 나중 release에서 옛 형태를 제거하는 expand and contract를 쓴다. builder가 각 변경을 만들고 release process가 시기를 정한다.

Replit checkpoint는 code와 managed DB state를 담고 Koder.ai도 snapshot과 rollback을 지원한다. development에는 유용하지만 external PostgreSQL의 native backup, point in time recovery, tested restore를 대신하지 않는다. DB operator가 recovery를 책임진다.

규정이 데이터 실행 위치를 제한하면 연결 전에 배치를 해결한다. builder, app host, DB, log, backup, support access는 서로 다른 경계를 넘을 수 있다. 지역 deployment가 DB나 prompt context도 그 지역에 남았음을 증명하지 않는다. 각 system과 볼 수 있는 data를 기록한다.

제약을 받아들이는 빌더를 선택한다

가장 넓은 기존 PostgreSQL에는 Replit이다. driver, ORM, migration framework, server process, inspection command를 가져올 수 있다. 그 통제에는 diff를 읽고 credential을 제한할 사람이 필요하다.

Vercel의 React 또는 Next.js, 특히 Neon이나 Supabase에는 v0다. project variable, DB integration, repository import, server preview로 단순 UI generator가 아닌 DB client가 된다. environment scope와 serverless connection을 일찍 검증한다.

기존 Supabase가 중심이면 Bolt 또는 Lovable이다. auth, table, storage, function 연결 작업을 줄인다. 이 편의를 모든 PostgreSQL cluster에 적용하면 안 된다. Bolt의 지원 stack과 Lovable의 Supabase 의존성 때문에 단순해 보이는 연결이 수동 backend 작업이 될 수 있다.

두 제품이 기술 시험을 통과하면 생성 속도보다 유지 보수성으로 정한다. 누가 failed deploy를 조사하고 server를 고치며 local migration을 실행하고 code를 옮길 수 있는지 묻는다. project 복제가 data와 secret 없이 설정을 유지하는지, 새 개발자가 repository에서 재구축할 수 있는지도 본다. DB는 frontend 유행보다 오래 산다. 원래 chat과 prompt 작성자가 없어도 앱을 이해할 수 있어야 한다.

owner URL, 기록되지 않은 DDL, row security 비활성화, client code의 credential, 빈 DB 재구축 실패가 필요하면 탈락이다. 출시 후 고칠 사소한 문제가 아니라 builder가 DB 운영 규칙을 받아들이지 못했다는 증거다.