AI로 만든 앱을 백업하는 법 — 그리고 왜 정말로 필요한지

제가 알고 지내는 한 창업자는 예약 사업 전체 — 지점 세 곳, 주당 200명가량의 고객 — 를 AI 앱 빌더로 직접 만든 앱으로 돌립니다. 그는 화요일에 그걸 제게 보여 주며 무척 자랑스러워했습니다. 수요일에 그는 조금 불안한 듯 물었습니다. “이게 망가지면, 저는 그냥… 다 잃는 건가요?”

솔직한 답은 이랬습니다. 어쩌면요. “망가진다”는 게 무슨 뜻이냐에 따라 다릅니다. 어떤 백업을 갖고 있느냐에 따라 다릅니다(그는 하나도 없었습니다). 제때 다시 만들어 낼 수 있느냐에 따라 다릅니다.

그 대화는 AI로 앱을 만든 사람들과 제가 가장 흔히 나누는 대화입니다. 만드는 일 자체는 작은 기적처럼 느껴집니다. “이게 사라지면 어떻게 되나” 하는 질문은 앱이 이미 진짜 일을 하고 있을 때까지 거의 떠오르지 않습니다 — 그리고 그때쯤이면 그것을 잃는 대가가 이미 심각해져 있죠.

이 글은 코드를 직접 쓰지 않고 진짜로 작동하는 앱을 만들었고, 이제 중요한 무언가를 거기에 의존하는 모든 사람을 위한 것입니다. 실제로 무엇이 위험한지, 무엇을 백업할지, 얼마나 자주 할지, 무언가 잘못되면 무엇을 할지 다루겠습니다. 기술적이지 않습니다. 돌릴 스크립트도 없습니다. 목표는, 당신이 무엇을 만들었든, 아무도 백업이라는 게 있다는 걸 말해 주지 않아서 그것을 잃는 일이 없도록 하는 것입니다.

AI로 만든 앱 안에 실제로 무엇이 있나 (그리고 무엇이 사라질 수 있나)

AI로 만든 앱은 매우 다른 두 가지로 이뤄져 있고, 각각을 다르게 백업해야 합니다.

첫째는 앱 그 자체 — 화면, 로직, 디자인, 연동입니다. AI 빌더가 당신을 위해 생성한 것이죠. 보통 프로젝트 안, 당신의 AI 빌더 계정에 있습니다. 그 계정 접근 권한을 잃거나, 빌더에 장애가 나거나, 프로젝트가 손상되면, 이것을 잃습니다.

둘째는 당신의 데이터 — 사용자, 주문, 메시지, 예약, 사람들이 업로드한 파일입니다. 이건 보통 어딘가의 데이터베이스에 있습니다. AI 빌더 안에 있을 때도 있습니다. Supabase, Firebase, Airtable 같은 서비스에 있을 때도 있습니다. 여러 곳에 흩어져 있을 때도 있습니다.

이 둘은 위험 성격이 완전히 다릅니다. 앱 구조는 당신이 AI에게 바꿔 달라고 할 때 바뀝니다. 당신의 데이터는 사용자가 무언가를 할 때마다 바뀝니다. 그래서 둘은 다른 백업 전략이 필요합니다.

이렇게 생각하면 유용합니다. 건물이 불타면, 앱은 설계도이고, 데이터는 불탈 때 건물 안에 있던 것입니다. 설계도로는 다시 지을 수 있습니다. 안에 있던 것은 되찾을 수 없습니다.

무엇이 위험한가: 실제로 일어나는 네 가지 시나리오

AI 앱 빌더로 만드는 사람들에게 이것들이 각각 일어나는 걸 봤습니다. 어느 것도 이론이 아닙니다.

1. 실수로 AI에게 앱을 망가뜨리라고 한다. 피곤하고, 자정에 작업하고 있는데, “회원가입 페이지를 없애 줘”라고 합니다. 다시 디자인하고 싶어서요. AI는 그렇게 합니다. 그러면서 기존 사용자가 로그인하게 해 주는 부분도 없앱니다. 이제 아무도 앱을 못 쓰고, 버전 기록을 켜 두지 않았다면(많은 빌더가 기본값으로 안 켜져 있습니다) AI의 마지막 작동 버전은 사라졌습니다.

2. AI 빌더에 장애나 데이터 문제가 생긴다. 드물지만, 실제입니다. 2024년에 인기 노코드 플랫폼 하나에서 고객 데이터에 접근할 수 없는 6시간짜리 장애가 있었습니다. 누구도 데이터를 영영 잃지는 않았지만, 많은 사업체가 하루를 잃었죠. 고객들이 토요일 오후 예약을 잡으려는 토요일 아침에 당신의 예약 앱이 다운돼 있다면, 그건 “데이터 손실 없음”이 아니라 — 되찾지 못하는 매출 손실입니다.

3. 계정이 잠긴다. 결제 문제일 수도, 새 위치에서의 로그인이 플래그된 것일 수도, 전파되지 않은 이메일 변경일 수도 있습니다. 앱도 멀쩡하고, 데이터도 멀쩡한데, 들어갈 수가 없습니다. 내보낸 사본이 없다면, 지원팀의 응답 시간에 운명을 맡기게 됩니다.

4. 플랫폼을 떠난다. 사람들이 대비하지 않는 그것입니다. 1년 뒤 당신은 다른 도구로 옮기거나, 만든 것을 넘겨받을 개발자를 고용하고 싶을 수 있습니다. 앱과 데이터의 유일한 사본이 한 빌더 안에만 있다면, 선택지는 좁고 비쌉니다.

이 시나리오 하나하나에서, “성가신 것”과 “재앙적인 것”의 차이는 백업이 있었느냐입니다.

무엇을 백업하고, 얼마나 자주 할까

화려한 시스템은 필요 없습니다. 습관이 필요합니다. 코드를 쓰지 않고 AI로 만드는 사람에게 제가 권하는 최소한입니다.

당신의 데이터 — 매일, 가능하면 자동으로.

데이터가 Supabase나 Airtable 같은 곳에 있다면, 둘 다 예약 내보내기나 백업을 제공합니다. 켜세요. 대부분은 세 번 클릭이면 되는데도 나중에 하겠다고 미루다 건너뜁니다. 출시하는 날 하세요.

데이터가 AI 빌더 자체 안에 있고 자동 내보내기가 없다면, 매주 일요일마다 수동으로 내보내도록 캘린더 알림을 설정하세요. 테이블당 CSV로 내보내세요. 빌더 바깥 어딘가에 저장하세요 — Google Drive, Dropbox, 외장 하드 드라이브 등. 같은 서비스만 아니면 어디든요.

이 내보내기를 적어도 4주 치는 보관하세요. 매번 같은 파일을 덮어쓰지 마세요. 화요일에 데이터가 손상됐는데 금요일까지 못 알아챘다면, 유일한 백업이 이미 망가진 금요일 데이터인 상황은 피하고 싶을 겁니다.

당신의 앱 구조 — 의미 있는 변경을 할 때마다.

AI 앱 빌더 대부분은 버전 기록이나 스냅숏 같은 게 있습니다. 이 기능을 찾으세요. 쓰세요. 앱에 큰 변경을 하기 전에 — “큰”이란 “한 시간 안에 기억만으로 다시 할 수 없는 것”을 뜻합니다 — 이름 붙인 스냅숏을 찍으세요. “결제 화면 추가 전”이나 “사용자 역할 변경 전”처럼 쓸모 있는 이름으로요.

빌더에 스냅숏이 없다면, AI에게 앱이 무엇을 하는지 긴 문서로 요약해 달라고 하세요. 그 문서를 저장하세요. 진짜 앱 백업은 아니지만, 레시피 입니다 — 최악의 경우, 그 문서를 프롬프트로 써서 다시 만들 수 있습니다.

당신의 계정과 자격 증명 — 한 번, 출시하는 날.

모든 게 어디에 있는지 한 곳에 적어 두세요. 어느 빌더 계정에 앱이 있는지. 어느 데이터베이스 서비스에 데이터가 있는지. 어느 이메일이 관리자 로그인인지. 어느 결제 처리업체가 연결돼 있는지. 어느 연동이 연결돼 있는지.

이것을 Google 문서가 아니라 비밀번호 관리자에 저장하세요. 내일 당신이 버스에 치이면, 동업자가 이 전부를 찾을 수 있어야 합니다. 1인 창업자라면, 미래의 당신(여섯 달 뒤, 지쳐서, 출시 때 무엇을 했는지 떠올리려는)도 이것을 찾을 수 있어야 합니다.

당신의 파일 — 사용자가 업로드하는 곳 어디든.

앱이 파일 업로드 — 이미지, PDF, 무엇이든 — 를 받는다면, 그 파일들은 어딘가에 있습니다. 어디인지 찾으세요. 빌더 대부분은 어떤 형태의 스토리지 버킷을 씁니다. 백업되는지 확인하세요. 안 된다면, 당신 소유의 스토리지로 주기적인 복사를 설정하세요.

일주일에 20분쯤 걸리는 간단한 백업 루틴

일요일 저녁, 어차피 일 안 하고 있을 때:

1. AI 빌더를 엽니다. 현재 앱 상태의 이름 붙인 스냅숏을 찍습니다. 날짜를 적습니다.
2. 각 데이터 테이블을 CSV로 내보냅니다. 클라우드 스토리지의 날짜별 폴더에 넣습니다. (대부분의 데이터는 테이블 3~10개에 있으니 — 큰일이 아닙니다.)
3. 스토리지 버킷을 슬쩍 봅니다. 이상한 일이 없는지 확인합니다(파일 수 폭증, 수상한 업로드).
4. 이번 주에 무언가 바뀌었으면 “모든 게 어디에 있는지” 문서를 업데이트합니다.

그게 전부입니다. 20분, 일주일에 한 번. 그것이 지켜 주는 것에 비하면 터무니없이 큰 보험입니다.

이걸 수동으로 하기 싫다면, 데이터가 기본 백업을 제공하는 곳에 있는지 알아보세요. 예를 들어 Supabase는 매일 자동 백업을 해 줄 수 있습니다. 무료 등급을 쓰고 있다면 그 백업은 제한적이고, 유료 플랜에서는 더 오래 거슬러 올라갑니다. 앱에 의존하는 사업이라면, 그 유료 플랜은 당신이 살 수 있는 가장 싼 보험입니다.

무언가 잘못되면 무엇을 할까

AI 빌더 버그나 잘못된 변경 때문에 앱이 망가지면:

• 공황 프롬프트를 던지지 마세요. 당장 AI에게 고쳐 달라고 하고 싶은 본능이 들 겁니다. 10분만 참으세요. 잘못된 방향으로 황급히 고치면 상황이 더 나빠질 수 있고, 빌더 대부분은 프롬프트 연쇄를 쉽게 되돌리지 못합니다.
• 마지막 스냅숏으로 롤백하세요. 있다면요. 이게 스냅숏을 찍은 이유 전부입니다.
• 스냅숏이 없다면, AI 빌더에게 마지막 특정 변경 을 되돌려 달라고 하세요. 정확하게요. “회원가입 페이지를 없앤 변경을 되돌려 줘”가 “다시 작동하게 해 줘”보다 낫습니다.

데이터가 손상되면:

• 즉시 쓰기를 멈추세요. 가능하면 앱을 오프라인으로 내리세요. 데이터가 망가진 상태에서 일어나는 새 사용자 동작 하나하나가, 나중에 맞춰야 할 데이터를 더 늘립니다.
• 가장 최근의 정상 백업에서 복원하세요. 어느 것이 정상인지 모르겠다면, 환경 사본에 하나씩 복원해 가며 마지막 깨끗한 버전을 찾으세요.
• 빠진 것을 맞추세요. 금요일에 일요일 백업을 복원하면, 닷새 치 활동을 잃은 겁니다. 영향받은 사용자에게 이메일을 보내, 한 일을 다시 해 달라고 부탁하고, 사과하세요. 정직하고 빠르게 대응하면, 사람들은 의외로 잘 이해해 줍니다.

계정 접근 권한을 잃으면:

• 즉시 지원팀에 연락하세요. “기다려 보자”고 하지 마세요. 빌더 지원 대기열은 제각각입니다. 어떤 곳은 훌륭하고, 어떤 곳은 느립니다.
• 신원을 준비해 두세요. 최초 가입 이메일, 결제 카드 정보, 가입한 날짜, 오래된 인보이스 등. 이것들 없는 계정 복구는 어렵습니다.

그 창업자에게 아무도 말해 주지 않은 것

이 글을 시작한 그 예약 사업 창업자는, 우리가 이야기한 뒤 데이터 서비스의 유료 플랜을 결제했습니다. 매일 자동 백업을 설정했습니다. 앱 스냅숏을 찍었습니다. 모든 계정을 비밀번호 관리자에 적었습니다. 전부 합쳐 일요일 한 시간쯤 걸렸죠.

한 달 뒤, 그가 요청한 AI 변경이 실수로 그의 반복 예약 로직을 망가뜨렸습니다. 고객들이 다음 예약을 볼 수 없었죠. 그는 20분 안에 알아챘습니다. 스냅숏을 두 번 클릭으로 복원했습니다. 데이터를 지켰고, 앱을 지켰고, 그의 고객들은 아무것도 보지 못했습니다.

그는 나중에 그게 자기가 쓴 가장 싼 한 시간이었다고 했습니다. 틀린 말이 아닙니다. AI로 만든 앱의 백업은 설정 한 시간과 일주일에 20분의 습관입니다. 그것이 막아 주는 것은, 그것을 잃어 본 그 누구도 자기에게 일어나리라고는 생각조차 못 했던 바로 그 일입니다.

진짜 무언가를 만들었다면, 오늘 스냅숏을 찍으세요.