AI로 만든 홈페이지 인수인계 — 계정 4개와 따라오지 않는 것들

1.왜 "계정 하나 넘기면 끝"이 아닌가

AI 빌더로 만든 사이트는 겉보기에 한 덩어리지만, 실제로는 서로 다른 회사의 서비스 서너 개가 묶여 돌아갑니다.

채팅으로 만들었다는 이유로 결과물도 한 곳에 있다고 생각하기 쉽습니다. 그런데 화면을 그리는 곳, 그 화면을 인터넷에 올려두는 곳, 회원과 주문을 담아두는 곳, 주소를 파는 곳이 각각 다른 회사입니다. 넘겨받는 쪽 입장에서 ‘내 사이트’가 되려면 이 네 군데의 계정이 전부 그쪽 이름으로 되어 있어야 합니다.

하나라도 제작자 계정에 남아 있으면 어떻게 되는지는 간단합니다. 제작자가 카드를 해지하거나 계정을 정리하는 순간 그 부분이 멈춥니다. 사이트는 열리는데 로그인만 안 되거나, 화면은 뜨는데 주소가 만료되는 식으로 반쪽만 죽습니다. 넘기는 사람도 몇 달 뒤에 남의 사이트 요금을 계속 내고 있는 상태가 됩니다. 그러니 인계는 파일을 주는 일이 아니라 결제 수단과 소유자 이름을 옮기는 일에 가깝습니다.

2.첫째 — 빌더 계정 (Lovable 기준)

Lovable은 프로젝트 설정 안에 소유권 이전 메뉴가 있습니다. 다만 아무에게나 넘길 수 있는 것은 아닙니다.

공식 문서가 안내하는 경로는 이렇습니다. “Go to Project settings → Transfer ownership and select a workspace member.” 프로젝트 설정에서 소유권 이전을 고르고 워크스페이스 구성원을 지정하라는 뜻입니다. 여기서 걸리는 조건이 하나 있습니다.

“Collaborators and pending invitees are not eligible.” 협업자 자격이거나 초대장을 아직 수락하지 않은 상태면 대상이 되지 않습니다. 즉 고객을 먼저 정식 구성원으로 초대해 수락까지 끝낸 뒤에야 이전 버튼이 의미를 갖습니다. 설정의 People 메뉴에서 초대하고, 고객이 메일을 열어 수락한 것을 확인한 다음 넘기십시오. 이 순서를 건너뛰고 목록에서 이름을 찾다가 안 보여서 헤매는 경우가 흔합니다.

코드 자체의 권리는 문서가 짧게 못 박아 두었습니다. 누가 코드를 소유하느냐는 물음에 “You as the creator do!” 라고 답합니다. 만든 사람 것이라는 뜻이고, 그래서 계약서에 ‘결과물 일체를 발주자에게 귀속’ 같은 문장이 들어 있다면 그 약속을 실제로 이행하는 행위가 바로 이 이전 작업입니다. 문서상 권리와 계정상 소유자를 같이 맞춰야 말이 됩니다.

내보내기 경로도 열어 두는 편이 좋습니다. 문서는 코드를 “transfer your code to GitHub or GitLab and do whatever you'd like with it” 라고 설명합니다. 저장소로 한 번 빼두면 나중에 빌더를 떠나더라도 결과물이 남습니다. 반대 방향은 막혀 있습니다 — “currently there is no way to start a Lovable project from already existing code”. 기존 코드를 가져와 새 프로젝트를 시작하는 길은 없다는 뜻이니, 저장소는 백업이지 복귀 경로가 아니라는 점만 알아두면 됩니다.

3.둘째 — 배포 계정 (Vercel 기준)

배포는 무중단으로 옮길 수 있습니다. 대신 따라오지 않는 목록이 꽤 깁니다.

Vercel 문서는 팀 사이 프로젝트 이동을 “zero downtime” 으로 설명합니다. 권한 조건은 보내는 팀에서는 소유자, 받는 팀에서는 구성원입니다. 설정 화면의 General 맨 아래 Transfer Project에서 시작하고, 소요 시간은 데이터 양에 따라 10초에서 10분 사이라고 안내합니다. 진행 중에는 새 배포를 만들거나 설정을 고칠 수 없으니 트래픽이 적은 시간대에 하는 편이 낫습니다.

같이 옮겨지는 것은 배포 기록, 환경변수, 도메인과 별칭, 깃 저장소 연결, 크론 작업 등입니다. 문제는 안 옮겨지는 쪽입니다. 문서가 명시한 항목 가운데 실무에서 자주 사고가 나는 것만 추리면 이렇습니다.

이전 후 다시 붙여야 하는 것
  - 통합(Integrations)          → 연결이 끊긴다. 수동으로 다시 추가
  - vercel.json 의 env / build.env → 환경변수로 옮겨두지 않으면 사라진다
  - Blob 저장소, Global Config   → 별도 이전 절차가 따로 있다
  - 로그·모니터링 데이터         → 넘어가지 않는다 (사용량도 초기화)

도메인은 규칙이 조금 다릅니다. example.com 처럼 루트 주소를 쓰고 있으면 도메인 자체가 받는 팀으로 넘어갑니다. 그런데 blog.example.com 같은 하위 주소만 쓰고 있었다면, 그 하위 주소는 위임되지만 루트 도메인은 원래 계정에 그대로 남습니다. 문서는 이 경우 원래 계정이 계속 소유자로서 요금을 부담한다고 적고 있습니다. 하위 도메인으로 서비스하던 사이트를 넘겼는데 몇 달 뒤 제작자 카드에서 도메인 값이 계속 빠져나가는 상황이 여기서 나옵니다.

4.셋째 — 데이터베이스 (Supabase 기준)

회원과 주문이 들어 있는 곳입니다. 네 군데 중 가장 늦게 손대되, 가장 꼼꼼히 확인해야 합니다.

Supabase는 조직 단위로 프로젝트를 옮깁니다. 조건은 두 줄로 정리됩니다. “You need to be the owner of the source organization.” 그리고 받는 쪽 조직에 대해서는 “You need to be at least a member of the target organization you want to move the project to.” 보내는 조직에서는 소유자, 받는 조직에서는 최소한 구성원이어야 한다는 뜻입니다.

요금은 시점으로 나뉩니다. 문서는 보내는 조직이 “the source organization will still be charged for the usage up until the transfer” 라고, 즉 이전 시점까지의 사용량을 부담한다고 밝힙니다. 그 이후분은 받는 조직 청구서에 잡힙니다. 정산을 깔끔하게 끊고 싶다면 결제 주기가 바뀌는 날짜 근처를 피하는 편이 설명하기 쉽습니다.

중단 시간도 조건부로 생깁니다. “Transferring a project might come with a short 1-2 minute downtime if you're moving a project from a paid to a Free Plan.” 유료에서 무료 요금제로 내려가는 경우 1–2분 정도 멈출 수 있다는 안내입니다. 제작자가 유료로 쓰던 프로젝트를 고객의 무료 조직으로 넘기는 상황이 정확히 여기에 해당하니, 고객에게 미리 말해두면 됩니다.

넘어가지 않는 항목도 확인해야 합니다. 문서는 이전을 시작하기 전에 GitHub 연동 연결이 없어야 하고, 프로젝트 범위 역할과 로그 드레인 설정도 없어야 한다고 요구합니다. 연동을 잠시 끊고 옮긴 뒤 다시 붙이는 순서가 됩니다. 받는 조직의 요금제가 낮으면 쓰던 기능이 사라지거나 권한이 좁아질 수 있다는 경고도 함께 실려 있습니다.

5.넷째 — 도메인, 그리고 순서를 마지막에 두는 이유

주소를 파는 회사의 계정이 진짜 소유권입니다. 그리고 이건 맨 나중에 옮기는 게 안전합니다.

빌더에서 연결해 둔 커스텀 도메인은 ‘연결’일 뿐입니다. 실제 권리는 등록업체 계정에 있고, 그 계정 안의 등록자 정보가 누구 이름인지가 전부입니다. 국내 등록업체를 쓴다면 등록자 정보 변경 또는 기관이전 절차를 밟게 되고, 해외 업체를 쓴다면 계정 간 이동 기능을 씁니다. 등록 직후나 정보 변경 직후에는 이전이 일정 기간 막히는 정책이 있는 곳이 많으니, 일정이 촉박하면 등록업체 정책을 먼저 확인하고 역산하십시오. 구체적인 대기 기간은 업체마다 달라 여기서 숫자로 적지 않습니다.

순서를 마지막에 두는 이유는 단순합니다. 도메인이 새 계정으로 넘어가면 네임서버나 연결 설정을 다시 잡아야 할 수 있는데, 이때 빌더와 배포가 이미 고객 계정에 있어야 고객이 직접 확인하고 고칠 수 있습니다. 반대로 주소부터 넘겨놓고 나머지를 옮기면, 화면이 안 뜨는 상태에서 양쪽이 서로 다른 계정을 들여다보며 원인을 찾게 됩니다. 권장하는 차례는 이렇습니다.

① 고객 계정 만들고 각 서비스에 정식 구성원으로 초대 → 수락 확인
② 빌더 프로젝트 소유권 이전
③ 배포 프로젝트 이전 → 끊어진 통합·환경변수 다시 연결
④ 데이터베이스 이전 → 연동 재연결, 백업 한 번
⑤ 도메인 등록업체 계정 이전 → 주소로 접속해 눈으로 확인
⑥ 결제·메일·외부 API 키 전부 재발급하고 옛 키 폐기

6.가장 자주 빠뜨리는 것 — 키를 새로 발급하지 않는다

계정을 전부 옮겨도 키가 그대로면 인계가 끝난 게 아닙니다.

결제사 시크릿 키, 메일 발송 키, 외부 API 키는 계정 소유자가 바뀐다고 자동으로 바뀌지 않습니다. 제작 과정에서 그 값이 어디를 거쳐 갔는지 생각해 보면 이유가 분명해집니다. 채팅 기록에도, 예전 저장소에도, 로컬 파일에도 남아 있을 수 있습니다. 넘긴 뒤에는 고객 계정에서 새로 발급하고 옛 키는 폐기하는 것이 맞습니다.

특히 결제 키는 자리를 잘못 잡으면 재발급으로도 못 막습니다. 승인 호출이 브라우저 코드에 들어 있으면 새 키를 넣어도 다시 노출될 뿐입니다. 이 구조를 서버 쪽으로 옮기는 방법은 Lovable에 토스페이먼츠 붙이기 — 시크릿 키를 프론트에 두지 않는 법에 따로 정리해 두었습니다. 인계 전에 이 점검을 한 번 하고 넘기시길 권합니다.

7.넘길 때 같이 주는 종이 한 장

계정 이전이 끝나면, 고객이 6개월 뒤에 열어볼 문서가 하나 필요합니다.

인계 사고의 상당수는 권한이 아니라 기억에서 납니다. 어느 회사 계정으로 무엇이 돌아가는지, 요금이 어디서 빠지는지, 무언가 고장 났을 때 어디부터 보는지를 고객이 모르는 상태로 남습니다. 한 장이면 충분하니 아래 항목만 채워 함께 넘기십시오.

사용 중인 서비스 이름과 각각의 로그인 계정, 요금제와 결제 수단, 도메인 만료일, 데이터 백업을 받는 방법, 그리고 ‘이건 건드리지 마세요’에 해당하는 설정 두어 개. 여기에 이전 완료 날짜를 적어 두면 나중에 요금 정산을 두고 이야기할 때 기준이 됩니다. 문서를 만들지 않으면 반년 뒤 제작자에게 전화가 오고, 그때는 이미 계정이 없어 확인해 줄 수도 없습니다.

§이 글의 근거

소유권 이전 경로와 협업자 제외 조건, 코드 귀속, 저장소 내보내기 문구는 Lovable 공식 문서에서 확인했습니다. 배포 이전의 무중단 여부, 10초–10분 소요, 함께 옮겨지는 항목과 옮겨지지 않는 항목, 하위 도메인 위임 규칙은 Vercel 프로젝트 이전 문서에서 가져왔습니다. 조직 소유자 권한 조건, 청구 시점 분리, 1–2분 중단 조건, 사전에 해제해야 하는 연동 목록은 Supabase 프로젝트 이전 문서가 원문입니다.

확인하지 못해 뺀 것도 밝혀둡니다. 도메인 등록업체별 이전 제한 기간, 국내 등록업체의 등록자 정보 변경 수수료, 그리고 v0·Bolt 등 다른 빌더의 소유권 이전 메뉴 위치는 이번 조사에서 원문으로 못 박지 못해 숫자와 단정적 표현을 넣지 않았습니다. 화면 구성과 메뉴 이름은 서비스 업데이트로 바뀔 수 있으니 실제 작업 전에 각 공식 문서를 한 번 더 확인하시기 바랍니다. 다른 글은 블로그 목록에, 문의는 SLOHERO 홈에서 받습니다.