AI 프로토타입을 실제 서비스로 옮기는 법

AI 프로토타입을 실제 서비스로 옮긴다는 것은 "내가 해보면 작동한다"와 "다른 사람들이 써도 계속 작동한다" 사이의 간격을 메우는 일입니다. 실제로는 다섯 가지를 의미합니다. 무언가를 바꿀 때마다 주요 흐름을 테스트하고, 누가 무엇을 보고 바꿀 수 있는지 잠그고, 사용자가 말하기 전에 오류를 알아차리고, 데이터를 백업하고 복구할 수 있음을 증명하고, 휴대폰에서도 충분히 빠르게 유지하는 것입니다. 이 중 어떤 것도 전면 재작성을 요구하지 않습니다. 프로토타입을 만든 AI와 함께 체크리스트를 하나씩 처리하면 됩니다.

프로토타입과 실제 서비스: 무엇이 실제로 달라지나

프로토타입에는 신중한 사용자가 한 명뿐입니다. 바로 나입니다. 어떤 버튼을 눌러야 하는지 알고, 합리적인 입력만 넣고, 무언가 깨지면 어깨를 으쓱하고 AI에게 고쳐 달라고 합니다. 실제 서비스에는 부주의한 사용자가 많고, 호기심 많은 사용자가 있으며, 가끔 적대적인 사용자도 있습니다. 코드를 "엔터프라이즈급"으로 만들 필요는 없습니다. 프로토타입이 한 번도 마주치지 않은 상황을 처리할 수 있어야 합니다.

이 가이드의 나머지는 위 표의 각 행을 하나씩 다룹니다.

1단계: 범위를 확정하고 주요 흐름 적기

무엇인가를 강화하기 전에, 1차 버전이 무엇인지 정하세요. 가장 중요한 흐름 3~6개를 적으세요. 예를 들어 "이메일로 가입하기, 프로젝트 만들기, 팀원 초대하기, 결제하기" 같은 것입니다. 이것이 테스트 스크립트, 모니터링 대상, 그리고 변경할 때마다 확인할 항목이 됩니다.

목록에 없는 것은 잘라내거나 베타라고 명확히 표시하세요. 네 가지 흐름을 안정적으로 만드는 것이 열네 가지를 만드는 것보다 훨씬 쉽습니다.

2단계: 낯선 사람처럼 테스트하고, 반복 가능하게 만들기

AI 빌더는 정상 경로(happy path)에서 작동하는 코드를 잘 만듭니다. 실제 문제는 비정상 경로에서 생깁니다. 각 주요 흐름을 다음 방식으로 테스트하세요.

• 잘못된 입력: 빈 필수 항목, 5,000자짜리 이름, @가 없는 이메일, 음수 수량, 과거 날짜.
• 새로고침과 뒤로 가기: 결제 도중 새로고침하기, 양식 제출 후 뒤로 가기. 무언가가 두 번 생성되지 않는지 확인하세요.
• 두 탭, 두 사용자: 서로 다른 두 계정으로 로그인하고, URL의 ID를 바꿔 상대방의 페이지를 열 수 있는지 시도하세요.
• 느리고 작은 화면: 휴대폰 크기 화면과 느린 네트워크(브라우저 개발자 도구로 시뮬레이션 가능).
• 빈 상태: 데이터가 전혀 없는 새 계정. 프로토타입은 샘플 데이터로 만들어진 경우가 많아, 데이터가 없으면 깨져 보이기 쉽습니다.

그다음 점검을 반복 가능하게 만드세요. 최소한 글로 쓴 체크리스트를 만들고 각 배포 전에 실행하세요. 더 좋은 방법은 가장 중요한 흐름에 대해 AI에게 자동화된 테스트를 작성하도록 요청하는 것입니다.

다음 흐름에 대한 자동화된 엔드 투 엔드 테스트를 추가해 주세요: 이메일로 가입, 프로젝트 생성, 두 번째 사용자 초대, Stripe 테스트 모드에서 결제 완료. 또한 URL을 바꿔서 다른 사용자의 프로젝트를 보거나 수정할 수 없음을 확인하는 테스트도 추가해 주세요.

사용자가 무언가를 할 수 없다는 것을 증명하는 테스트가 프로토타입에 가장 자주 빠져 있습니다.

3단계: 프로토타입이 놓치는 보안 기본기

AI로 만든 앱의 보안 문제 대부분은 특이하지 않습니다. 확인이 빠져 있을 뿐입니다. 다음 목록을 살펴보세요. 더 자세한 내용은 AI로 만든 앱을 위한 보안 체크리스트를 참고하세요.

• 서버에서의 권한 확인. 버튼을 숨기는 것은 보안이 아닙니다. 데이터를 읽거나 바꾸는 모든 요청은 로그인한 사용자가 그 작업을 할 수 있는지 서버에서 확인해야 합니다. 데이터베이스에 행 단위 규칙을 쓰고 있다면 켜져 있는지, 테스트되었는지 확인하세요.
• 브라우저 밖으로 빼낸 비밀 값. 결제, 이메일, AI 제공자의 API 키는 서버 측 환경 변수에 두고, 프론트엔드 코드에 절대 넣지 마세요. 이 말이 무슨 뜻인지 잘 모르겠다면 환경 변수와 비밀 값이란 무엇인가를 읽어 보세요.
• 서버 측 검증. 브라우저는 우회될 수 있으므로 중요한 검사는 서버에서도 반복하세요.
• 제대로 된 로그인. 검증된 인증 라이브러리나 서비스를 쓰세요. 직접 만든 비밀번호 저장 방식은 피하세요. 앱에 로그인 추가하는 법에서 선택지를 볼 수 있습니다.
• 요청 제한(rate limit): 로그인, 가입, 비밀번호 재설정, 이메일을 보내거나 유료 API를 호출하는 모든 기능에 적용하세요.
• 친절한 오류 메시지. 사용자에게는 "문제가 발생했습니다"만 보여 주고, 자세한 내용은 화면이 아니라 로그에 남기세요.
• 유출된 키는 교체하기. 실제 키가 채팅, 커밋, 스크린샷에 붙여 넣어진 적이 있다면 제공자에게서 바로 교체하세요.

여러 항목을 한 번에 점검하는 프롬프트 예시입니다.

이 앱을 실제 서비스 보안 관점에서 검토해 주세요. 모든 API 경로가 읽거나 바꾸는 레코드를 로그인한 사용자가 소유하는지 확인하고, 비밀 키가 브라우저로 전송되지 않는지 확인하고, 입력이 서버에서 검증되는지 확인하고, 로그인과 비밀번호 재설정에 요청 제한이 있는지 확인하세요. 무엇이든 바꾸기 전에 발견한 문제 목록을 먼저 보여 주세요.

먼저 목록을 받으면 한꺼번에 거대한 변경을 받는 대신, 문제를 보고 순서를 정할 수 있습니다.

4단계: 언제 깨지는지 알기 — 로깅과 모니터링

미리보기에서는 오류가 일어나는 것을 볼 수 있습니다. 실제 서비스에서는 앱이 알려 줘야 합니다. 비용이 낮은 것부터 가장 유용한 것까지 세 층위가 있습니다.

1. 서버 로그. 오류가 어떤 경로에서, 어떤 사용자 ID로(비밀번호나 카드 번호는 제외), 어떤 형태의 입력으로 발생했는지 재현할 수 있을 만큼 맥락과 함께 기록되는지 확인하세요. 앱이 콘솔에만 출력한다면 AI에게 구조화된 로깅을 추가하도록 요청하세요.
2. 오류 추적. Sentry 같은 서비스나 비슷한 도구가 프론트엔드와 백엔드의 예외를 수집하고, 묶어서 이메일로 알려 줍니다. 작은 앱이라면 이런 서비스의 무료 플랜으로 충분한 경우가 많습니다. 현재 한도는 각 서비스 사이트에서 확인하세요.
3. 가동 시간 점검. 외부 서비스가 몇 분마다 홈 페이지와 핵심 API 경로를 불러보고, 실패하면 알려 줍니다. 앱이 로그를 남기지 못할 만큼 멈춘 문제도 잡아냅니다.

습관 하나를 더하세요. 배포할 때마다 미리보기가 아니라 실제 URL에서 앱을 열고 주요 흐름 체크리스트를 실행하세요.

5단계: 백업과 되돌릴 방법

혼동하기 쉬운 두 가지를 보호해야 합니다.

• 코드. 프로젝트를 버전 관리에 넣어 두면 어떤 변경이든 되돌릴 수 있습니다. 많은 AI 빌더가 파일의 체크포인트를 보관하지만, Git 저장소와 동기화하면 빌더 밖에도 사본이 생깁니다.
• 데이터. 코드를 되돌린다고 데이터베이스가 되돌아가지는 않습니다. 잘못된 마이그레이션이나 버그가 있는 삭제 버튼은 어떤 코드 체크포인트로도 되돌릴 수 없는 행을 지울 수 있습니다.

데이터의 경우, 앱의 호스팅과 다른 곳에 정기 백업을 설정하세요. Postgres 데이터베이스라면 별도 저장소로 예약된 pg_dump가 일반적인 방법입니다. 많은 관리형 데이터베이스 호스트가 자동 백업이나 특정 시점 복구를 제공하기도 합니다. 그다음 대부분이 건너뛰는 단계를 하세요. 백업을 임시 데이터베이스에 복구하고, 데이터가 실제로 있는지 확인하세요.

또한 파괴적인 동작을 더 안전하게 만들도록 AI에게 요청하세요. 삭제 전 확인 단계, 사용자가 되돌리고 싶어 할 수 있는 항목에 대해서는 "소프트 삭제"(행을 지우는 대신 삭제 표시만 하기)를 적용하세요.

6단계: 휴대폰에서도 버티는 성능

프로토타입은 나 혼자 쓰고 데이터가 아주 작기 때문에 빠르게 느껴집니다. 출시 전에 다음을 확인하세요.

• 실제 크기의 데이터 넣기. AI에게 수천 행의 데이터를 채워 넣게 하고, 어떤 페이지가 느려지는지 보세요. 목록은 보통 페이지 나누기가 필요하고, 데이터베이스는 필터링하고 정렬하는 열에 인덱스가 필요합니다.
• 이미지 줄이기. 지나치게 큰 이미지가 페이지를 느리게 만드는 가장 흔한 이유입니다. 크기를 줄이고 압축한 이미지와, 화면 아래쪽 이미지의 지연 로딩을 요청하세요.
• 측정하기. 실제 URL에서 Chrome 개발자 도구의 Lighthouse를 모바일 모드로 실행하세요. Google의 Core Web Vitals가 합리적인 목표입니다. 가장 큰 콘텐츠의 표시(LCP)는 2.5초 이내, 다음 상호작용까지의 시간(INP)은 200ms 이하, 누적 레이아웃 이동(CLS)은 0.1 이하입니다.
• "깨어나는" 지연 주의. 유휴 상태에서 잠드는 호스팅은 돈을 아끼지만, 한동안 방문이 없었다가 처음 접속하면 느립니다. 새 앱이라면 대개 괜찮은 거래지만, 그런 일이 일어난다는 것을 알고 있어야 합니다.

5,000개 행이 있으면 프로젝트 페이지가 느립니다. 서버 측 페이지 나누기(페이지당 25개)를 추가하고, 필터링과 정렬에 쓰는 열에 데이터베이스 인덱스를 추가하고, 다음 페이지를 불러오는 동안 로딩 상태를 보여 주세요.

7단계: 운영의 기본

몇 가지 작은 것이 취미 앱과 사람들이 신뢰하는 앱을 구분합니다.

• HTTPS가 적용된 커스텀 도메인. 커스텀 도메인 연결 방법을 참고하세요.
• 인증된 도메인에서 보내는 트랜잭션 이메일. 가입 확인과 비밀번호 재설정 메일용입니다. 앱에서 이메일 보내는 법에서 다룹니다.
• 실제로 수집하는 정보를 설명하는 개인정보처리방침과 이용약관. 얻지 않은 준법 주장을 그대로 복사하지 마세요.
• 지원 창구. 모니터링되는 이메일 주소라도 있어야 합니다.
• 결제와 이메일용 테스트 키와 실제 키 분리, 그리고 어느 환경이 어느 키를 쓰는지 명확히 기록하기.

8단계: 깔끔한 인수인계

머지않아 다른 사람이 이 앱을 맡게 됩니다. 프리랜서, 새 공동창업자, 혹은 여섯 달 뒤의 나 자신일 수도 있습니다. 쉽게 만드세요.

• README: 실행 방법, 필요한 환경 변수 이름(값은 절대 넣지 않음), 배포 방법.
• 주요 흐름 체크리스트와 자동화된 테스트.
• 짧은 아키텍처 메모: 프론트엔드, 백엔드, 데이터베이스, 제3자 서비스, 그리고 각각을 어디서 호스팅하는지.
• 접근 권한 목록: 도메인, 호스팅, 데이터베이스, 결제, 이메일 계정의 관리자가 누구인지. 개인 이메일이 아니라 사업용 이메일로 계정을 두세요.
• Git에 있는 코드, 가능하면 내가 소유한 저장소와 동기화하세요. 나중에 호스팅을 옮길 수도 있다면 AI로 만든 앱을 내보내고 직접 호스팅하는 법을 읽어 보세요.

AI가 이 문서의 대부분을 초안으로 써 줄 수 있습니다.

이 프로젝트를 처음 보는 개발자를 위해 README를 작성해 주세요. 앱이 하는 일, 기술 스택, 로컬에서 실행하는 방법, 앱이 읽는 모든 환경 변수(이름과 용도만, 값은 제외), 데이터베이스 스키마의 구성, 배포 방법을 포함하세요.

실서비스 준비 체크리스트

• 주요 흐름을 적고 테스트함. "다른 사람의 데이터에 접근할 수 없음"도 포함
• 모든 데이터 경로에서 서버 측 권한 확인과 검증
• 프론트엔드 코드에 비밀 키 없음. 유출된 키는 교체함
• 인증과 돈이 드는 모든 기능에 요청 제한
• 오류 추적과 가동 시간 알림이 내가 실제로 읽는 받은편지함으로 전송됨
• 데이터베이스 백업이 앱 호스팅 밖에 있고, 복구를 한 번 성공적으로 테스트함
• 실제 크기의 데이터로 페이지 나누기와 인덱스 확인
• 커스텀 도메인, 인증된 발신 도메인, 개인정보처리방침
• 다음 사람을 위한 README와 접근 권한 목록

Mythex로 하기

Mythex에서 프로토타입을 만들었다면, 이 단계들 대부분은 같은 프로젝트 안의 프롬프트로 처리할 수 있습니다. /test를 입력하면 Mythex가 실시간 미리보기를 사용자처럼 클릭하며 깨진 흐름을 보고합니다. 앱 테스트를 참고하세요. 키는 채팅이 아니라 프로젝트 비밀 값에 넣고, 에이전트가 성공적으로 응답할 때마다 파일의 체크포인트가 저장되어 되돌릴 수 있습니다. 게시하면 호스팅과 데이터베이스를 함께 제공하는 공개 URL을 받을 수 있으며, 같은 크레딧 잔액에서 비용이 빠져나갑니다(호스팅 한도에서 앱과 데이터베이스가 어떻게 잠들고 깨어나는지 설명합니다). 체크포인트는 파일을 저장할 뿐 데이터베이스 행은 저장하지 않으므로, 데이터 백업은 따로 계획하세요. Pro 플랜에서는 커스텀 도메인을 연결하고, 인수인계를 위해 코드를 내보내거나 내 GitHub 저장소와 동기화할 수 있습니다.

자주 묻는 질문