코드를 옮겨 화면이 켜지면 이사가 끝난 걸까? 같은 기기의 합성 앱 모의실험에서 ‘다른 폴더에서 실행’과 ‘원래 서비스 경로를 막고 기록·파일 사용’을 나눠 살폈다.

합성 앱 하나를 같은 Mac의 별도 폴더로 복사했다. 원래 서비스를 흉내 낸 프로그램을 두고 일부 묶음에서 구성요소를 의도적으로 뺐다. 한 앱을 두 번 초기화해 반복한 결과이며 실제 업체의 내보내기, 다른 컴퓨터로의 이전, 일반적인 성공률을 말하지 않는다. 앱은 Astra라는 AI 에이전트의 작업 세션에서 작성했다. 측정 중 모델 호출은 없었으며 AI 자체를 평가한 시험도 아니다.
이 글의 목차
공식 설명: 코드 밖에도 옮길 것이 있다
Lovable 문서는 사용자가 보는 화면을 다른 곳에 두면서 데이터 등 뒤쪽 기능을 맡는 Cloud 서비스를 계속 쓰는 구성을 설명한다. Supabase 문서는 데이터베이스 백업에 파일 저장 기능인 Storage의 파일 자체가 포함되지 않는다고 설명한다. 파일을 옮길 수 없다는 뜻은 아니다. 두 문장의 근거는 2026년 10월 5일 재확인했다. 이번 실험에서 두 제품을 내보낸 것은 아니다.
실험 기록: 같은 코드, 다른 세 묶음
이 글에서는 코드·기록·설정·파일 내용·서비스를 나눠 본다. 설정에는 접속 주소, 서비스에는 기록·파일을 제공하는 프로그램 등이 해당한다. 의존성은 앱 작동에 아직 필요한 것이다.
2026년 9월 27일 기록 20개·첨부 3개로 시험했다. 코드는 세 묶음 모두 같다. A에는 코드와 원래 서비스로 연결하는 설정만 있다. B에는 기록 DB 사본과 기록을 로컬에서 쓰는 설정을 더했지만 파일은 원래 서비스에서 가져온다. C에는 파일 3개의 내용과 상대 경로로 로컬 기록·파일을 쓰는 설정까지 넣었다. 별도 서비스 프로그램을 추가로 옮긴 것이 아니다. 결과는 설계한 누락의 동작을 확인한 것이며 뜻밖의 업체 결함을 발견한 것이 아니다.
매번 새 사본과 새 브라우저 상태로 시작하고 캐시와 서비스 워커를 우회했다. 원래 서비스로 향하는 중계 경로를 허용하거나, 원래 서비스에 전달하지 않고 즉시 HTTP 503(서비스 이용 불가)을 돌려주도록 했다. 아래 ‘차단’은 이 조건이다. 해지·와이파이 끄기와 다르며 캐시가 켜진 상태, 시간 초과·연결 거부·부분 장애·인증 오류의 동작은 시험하지 않았다. 둘째 반복은 상태가 다음 조건에 남는지 살피려고 순서를 뒤집었다. 한 앱의 3묶음×2상태×2반복, 12조건이지 독립된 앱 12개가 아니다.
비교 기준을 확인하려고 원래 서비스의 일회용 사본만 실행한 기준 시험도 1회 했다. 원래 서비스 재시작 전후 기록 20/20, 파일 내용·연결 각각 3/3이 일치했다. R05 기록의 메모 수정은 일회용 원래 서비스 DB에만 남았다. 사용하지 않은 목적지 DB 사본과 보존 원본은 그대로였고 이 수정은 이후 조건에 넘기지 않았다.
표의 ‘기록’은 7개 필드가 모두 일치한 기록 수/20이다. 목록과 상세를 따로 확인했고 매 조건 두 수가 같았다. 20/20에는 값·자료형 일치와 ID 누락·추가·중복 없음이 포함된다. 일곱 필드 밖의 의존성은 이 판정으로 알 수 없다. ‘파일 내용’은 다운로드 경로에서 받은 내용의 일치 수/3이다. 일치 수는 처음과 옮긴 앱 재시작 후에 같았다. 수정에 성공했다면 재시작 뒤 R05 메모 하나만 지정대로 바뀌어 있어야 맞다고 봤다.
A 허용의 기록·파일과 B 허용의 파일은 원래 서비스 응답이며 목적지에 들어 있는 내용이 아니다. B의 기록과 C의 기록·파일은 로컬 구성에서 제공했다. ‘옮긴 곳’은 복사한 앱의 폴더·DB를 뜻한다. 요청은 처음·수정·재시작 관측을 합친 원래 서비스로의 앱 전달 시도다. 조건 전에 경로의 허용·차단을 확인한 진단 요청은 제외했다.
| 반복·조건 | 기록 | 파일 내용 | 수정 저장 위치 | 요청: 시도/차단/도달 |
|---|---|---|---|---|
1·A 허용 |
20/20 |
3/3 |
원래 서비스 |
52/0/52 |
1·A 차단 |
0/20 |
0/3 |
저장 실패 |
51/51/0 |
1·B 허용 |
20/20 |
3/3 |
옮긴 곳 |
6/0/6 |
1·B 차단 |
20/20 |
0/3 |
옮긴 곳 |
6/6/0 |
1·C 허용 |
20/20 |
3/3 |
옮긴 곳 |
0/0/0 |
1·C 차단 |
20/20 |
3/3 |
옮긴 곳 |
0/0/0 |
2·C 차단 |
20/20 |
3/3 |
옮긴 곳 |
0/0/0 |
2·C 허용 |
20/20 |
3/3 |
옮긴 곳 |
0/0/0 |
2·B 차단 |
20/20 |
0/3 |
옮긴 곳 |
6/6/0 |
2·B 허용 |
20/20 |
3/3 |
옮긴 곳 |
6/0/6 |
2·A 차단 |
0/20 |
0/3 |
저장 실패 |
51/51/0 |
2·A 허용 |
20/20 |
3/3 |
원래 서비스 |
52/0/52 |
C의 0/0/0은 감사한 앱 전달 요청 수다. 차단 6조건 모두 이 요청의 원래 서비스 도달은 0회였다. 브라우저의 모든 통신이나 원본 파일을 읽는 모든 경로를 감사한 결과는 아니다. 운영체제 수준 브라우저 격리는 제거됐고, 별도 브라우저 차단 점검의 실행 근거도 없어 C를 포함한 완전 격리를 입증하지 못한다.
12/12조건에서 처음과 재시작 후 페이지 응답은 HTTP 200이고 앱 제목이 있었다. 이것만으로 기능 정상은 아니다. A 허용에서는 R05 메모가 원래 서비스의 일회용 DB에만 저장됐다. 옮긴 앱을 재시작해도 보였지만 새 곳에 저장된 것은 아니었다. 저장 위치는 화면이 아니라 양쪽 DB의 수정 전후·재시작 후 상태와 요청 기록으로 판정했다. A 차단은 목록·상세·파일·수정 모두 HTTP 503이었다. 0/20은 접근 불가이지 삭제가 아니며 저장 실패는 이전에 저장된 기록의 소실이 아니다.
B 차단에서는 기록과 파일의 연결이 3/3 남았지만 메모.txt, table.csv, bytes.bin 내용은 0/3이었다. 이름·링크와 파일 자체의 차이다. 다른 조건의 파일 연결도 3/3이었으나 A 차단은 기록을 불러오지 못해 연결을 확인할 수 없었다. B·C 수정은 옮긴 DB에만 저장돼 재시작 후 유지됐다. 각 조건에서 지정 메모 외 DB 변경은 없었고 보존 원본은 그대로였다.
C가 확인한 범위는 이 기록·파일·메모 수정·재시작뿐이다. 기록 생성·삭제와 첨부 교체는 시험하지 않았다. 로그인, 결제, 메일, 백그라운드 작업, 실행 중 AI 기능은 구현하지 않았고 시험하지 않았다.
B의 요청 6건은 처음과 재시작 때 파일 3개씩 요청한 것이다. A의 52건과 51건의 경로별 구성은 요약 기록에 열거돼 있지 않아 같은 요청 집합이라고 단정하지 않는다. 각 조건 전에 허용 진단 1회가 원래 서비스에 도달했으므로 차단 조건 폴더의 로그에도 그 과거 접속이 남는다. 표의 앱 요청과는 별도다.
실패한 준비와 확인하지 못한 것
최초 사전 점검은 통신·브라우저 허용 범위 충돌로 보류됐다. 범위 명시 뒤 세 시도가 각각 설정·기록 무결성·브라우저 실행 문제로 멈췄다. 각 시도의 측정은 0/12였고 앱 기능 실패로 세지 않았다. 범위 명시 뒤 넷째 시도에서 12조건을 관찰했다. 세부 오류와 기준 시험 준비 내역은 실험 기록에 보존했다.
측정 전 시험 실행 프로그램을 고쳤지만 앱·데이터·묶음·순서·판정 기준은 유지했다. 다만 운영체제의 브라우저 격리를 제거했으므로 브라우저 자체의 백그라운드 통신 차단은 미입증이다. 브라우저가 허용 목록 밖 로컬 포트를 막는지 보는 별도 점검은 실행 기록이 없고 결과·시간도 미확인이다. 관측된 원래 서비스 경로의 503 차단과는 다른 점검이다. 시험용 임시 폴더의 중간 재배치 과정 일부도 기록으로 확인되지 않는다.
환경은 macOS 27.0 arm64, Python 3.9.6, SQLite 3.54.0, Chrome 153.0.8010.53과 Node v24.19.0·설치된 Playwright였다. 마지막 자동 실행은 기준 시험 포함 약 42초로, 앱 이전에 걸린 시간이 아니다. 전체 제작·수정·초보자 이전 시간, 총비용·모델 식별자·CLI 버전·구독 사용량은 미측정이다. 비용이 들지 않는 이전이나 생산성 향상을 입증하지 않는다.
다른 기기·OS, 실제 업체의 내보내기 권한·난이도·비용, 공개 배포·운영 보안·법적 소유권·라이선스·실제 해지는 확인하지 않았다. 브라우저 저장값의 이전, 운영체제 다운로드 창을 통한 저장, 별도 앱에서 파일 열기도 시험하지 않았다.
판단: 저장 위치와 파일 내용을 함께 적자
필자의 판단으로 ‘수정이 보이나’ 다음에는 **‘어디에 저장됐나’와 ‘원래 서비스 경로 없이 파일 내용도 남나’**를 물어야 한다. C를 모든 앱의 이전 가능성·성공률로 일반화할 수 없다. 원래 서비스를 의도적으로 유지하는 구성도 선택지다.
아래는 첫 확인표다. 원래 계정과 데이터는 보존하고, 먼저 사본에서 읽기 기능 하나를 골라 기대한 내용과 대조한다. 코드 사본도 원래 서비스에 쓸 수 있으므로 수정 시험은 연결된 서비스까지 일회용 시험 데이터로 분리한 뒤에만 한다. 이를 확인할 수 없다면 쓰지 말고 ‘모름’으로 남긴다. 초보자 사용성은 미검증이며 이전 성공이나 계정 해지의 안전을 인증하는 표가 아니다.
| 확인할 것 | 현재 → 계획 위치 | 포함: 예/아니오/모름 | 확인 방법·범위 | 남은 의존·미시험·문의 대상 |
|---|---|---|---|---|
코드 |
___ |
___ |
___ |
___ |
기록 |
___ |
___ |
___ |
___ |
설정(비밀번호·키 제외) |
___ |
___ |
___ |
___ |
파일 내용 |
___ |
___ |
___ |
___ |
서비스 |
___ |
___ |
___ |
___ |
각 행에 계획한 위치를 ‘로컬/원래 서비스/모름’으로 적는다. 확인란에는 **원래 서비스 경로 없이 확인했는지(예/아니오/안 함), 수정은 어느 DB에 저장됐는지(위치/안 함/모름)**를 반드시 남긴다. 실서비스 해지나 통신 차단을 바로 실행하라는 뜻은 아니다. 시험 환경의 경로와 저장 위치를 확인할 수 없다면 독립 실행 판정은 ‘모름’이다. 내보내기에 포함됐다는 사실과 원래 서비스 없이 작동한다는 판단도 구분한다.
내용 대조 범위, 내려받은 파일 내용의 일치 여부, 일회용 데이터에서 수정 후 재시작해도 남는지를 적는다. 3개만 봤다면 ‘3개 확인’으로 쓰고 전체 일치로 넓히지 않는다. 모르는 항목은 ‘모름’으로 표시하고 문의 대상을 적는다.
이 글은 AI를 활용해 자료 조사와 초안 작성을 보조했으며, 작성자가 최종 원고를 검토하고 수정 방향을 결정했습니다.
답글 남기기