Lovable로 시작한 프로젝트, 코드를 쓰기 전부터 잡히는 두 항목

clone 직후, 어떤 상태였는가

Lovable에서 GitHub 연결로 export한 프로젝트를 clone한 직후 워킹 트리에는 다음 두 항목이 같이 있었습니다.

• .env 파일이 워킹 트리와 git history 양쪽에 들어 있음. 안에는 Supabase project URL과 publishable JWT가 그대로 적혀 있습니다.
• .gitignore에는 *.local 패턴만 있고 .env·.env.*·.env.local처럼 자주 쓰이는 환경변수 파일 패턴이 빠져 있습니다.

.env 자체가 first commit에 포함되었고, .gitignore는 그것을 막아주지 않는 상태입니다. 두 항목이 동시에 빠진 셈이라 점검 시 한 항목이 아니라 두 항목으로 잡힙니다.

두 항목이 동시에 잡히는 이유

Preflight은 항목을 지금 막을 것, 출시 전 확인할 것, 불확실한 것, 나중에 개선할 것으로 나눕니다. Lovable 시작점에서는 두 항목이 모두 가장 앞 단계인 지금 막을 것으로 들어옵니다.

• 키 커밋 — 지금 막을 것. 이미 외부에서 접근 가능한 자격이 코드 저장소에 적혀 있는 상태입니다. 추가 변경 없이도 시작 시점부터 노출이 발생합니다.
• gitignore 패턴 누락 — 지금 막을 것. 키 회전 후에 새 .env.local을 만들어도 다시 commit 될 가능성이 남습니다. 재발 방지 차원이라 시점상 같이 처리하는 편이 맞습니다.

한 항목씩 따로 보면 평범한 점검 결과지만, 두 항목이 묶이면 의미가 달라집니다. 노출이 이미 일어났고, 같은 곳에 다시 누출될 수 있는 구조가 그대로 남아 있다는 뜻입니다.

로컬 파일 삭제만으로는 부족한 이유

가장 자주 시도되는 응답이 로컬 .env 파일을 삭제하고 다시 commit하는 것입니다. 보안 조치처럼 보이지만 실제로는 노출을 회수하지 못합니다.

first commit에 들어간 byte는 git history에 그대로 남습니다. 이미 fork된 repo, 누군가의 로컬 clone, organization 단위의 webhook 페이로드, GitHub의 archive·search 인덱스 같은 곳에 키가 흩어져 있을 수 있고, 이 모두를 사후에 회수할 방법은 없습니다.

첫 동작은 키 자체를 무효화하는 것입니다. Supabase 콘솔에서 새 키를 발급해 이전 키를 폐기하면, history에 남은 byte는 더 이상 사용 가능한 자격이 아닙니다.

고치는 순서

노출이 이미 일어난 경우라면 다음 순서가 가장 안전합니다.

1. 키 회전. Supabase 대시보드의 API settings에서 publishable key와 service_role key를 새로 발급하고 이전 키를 폐기합니다. publishable key는 RLS 정책 위에서 동작하므로, 회전과 별개로 RLS 규칙이 의도대로 좁혀져 있는지 같이 확인하는 편이 안전합니다.
2. .gitignore 보강. .env, .env.*, .env.local, *.pem, *.key 같은 시크릿 파일 패턴을 추가합니다. 이후의 commit이 같은 실수를 자동으로 막아주는 단계입니다.
3. 새 값은 git 밖에. 새로 발급한 키는 .env.local처럼 추적되지 않는 파일에 두고, 운영 환경에선 호스팅 플랫폼의 환경변수 저장소(Vercel·Netlify·Railway 등의 secrets 화면)에만 둡니다.
4. history 정리는 선택. 키를 이미 회전했다면 history에 남은 byte는 더 이상 자격이 아닙니다. 그래도 history에서 .env 자체를 제거하고 싶다면 git filter-repo 또는 BFG Repo-Cleaner를 쓰고, force-push 전 협업자에게 영향을 알립니다. 작은 토이 프로젝트라면 새 repo를 만드는 편이 더 빠를 때도 있습니다.

여기서 자주 빠지는 함정이 3번 다음에 1번으로 가는 순서입니다. 새 키를 git 밖으로 옮겨도 이전 키가 살아 있으면 노출은 진행 중인 상태로 남습니다.

다른 바이브코딩 플랫폼은?

이 글에서 정리한 디폴트는 Lovable 한정으로 관찰한 패턴입니다. Bolt, v0, Cursor의 starter template, 그 외 코드 생성 플랫폼들도 비슷한 디폴트인지는 별도로 확인되지 않았습니다.

그래서 권하는 점검은 단순합니다. 사용하는 플랫폼이 GitHub로 export 가능하다면, 한 번 비어 있는 프로젝트를 export한 직후 다음 두 가지를 확인해보세요.

• first commit에 .env가 들어가 있는가 — git log -- .env 또는 GitHub 웹의 파일 history로 확인.
• .gitignore에 .env 계열 패턴이 들어가 있는가 — 파일을 직접 열어 확인.

플랫폼 디폴트는 시간이 지나면서 바뀝니다. 위 두 항목이 이미 잘 처리되어 있다면 이 글의 관찰은 더 이상 들어맞지 않는 셈이고, 그건 좋은 변화입니다.

Preflight에서 이걸 어떻게 봐 왔는가

Preflight은 보안 감사를 대체하지 않습니다. 이 글에 적은 두 항목도 전문 점검 도구가 자동으로 잡아주는 흔한 패턴이고, 새로운 발견은 아닙니다. 다만 출시 직전에 사용자가 처음 점검을 돌렸을 때, 이 두 항목이 가장 먼저 우선순위 위로 올라온다는 것이 관찰된 결과입니다.

Lovable 시작점은 Preflight 입장에서 보면 입력 패턴이 분명한 경우입니다. 어떤 항목이 잡힐지 시작 전에도 짐작 가능하다는 뜻입니다. 이런 항목은 점검 결과로 시간을 쓰게 두기보다, 시작 화면에서 일찍 안내하는 편이 맞습니다.

자신의 프로젝트가 비슷한 곳에서 출발했다면, 점검을 한 번 돌려 현재 키가 어디까지 노출되어 있는지부터 확인해보는 편이 빠릅니다. 고치는 첫 단계는 코드 수정이 아니라 Supabase 콘솔에서 이전 키를 폐기하고 새로 발급하는 일입니다.