AI 코딩 도구로 만든 앱도 출시 전에 확인할 것은 일반 앱과 같습니다. 다만 AI가 "일단 돌아가게" 만드는 데 능하다 보니, 겉으로는 멀쩡한데 보안과 예외 처리가 비어 있는 경우가 훨씬 많습니다. 출시 전에는 비밀 키가 앱 안에 들어 있지 않은지, 다른 사람의 데이터를 읽을 수 없는지부터 보고, 그다음에 스토어 심사와 출시 후 관리를 챙기시면 됩니다.

화면이 돌아간다고 출시 준비가 끝난 건 아닙니다

요즘 상담에서 "Lovable로 만들어 봤는데 이대로 내도 될까요", "Cursor로 거의 다 만들었는데 마무리만 부탁드려요" 하는 이야기를 자주 듣습니다. 실제로 코드를 열어 보면 화면과 기본 흐름은 꽤 잘 되어 있습니다. 문제는 보이지 않는 쪽입니다.

AI 도구는 요청받은 기능이 동작하는 데 집중합니다. "로그인 기능 만들어 줘"라고 하면 로그인은 됩니다. 그런데 로그인한 사용자가 남의 주문 내역을 주소창만 바꿔서 볼 수 있는지까지는 따로 요청하지 않으면 잘 챙기지 않습니다. 혼자 써 보는 단계에서는 이런 구멍이 드러나지 않습니다. 사용자가 생기고 나서야 보입니다.

그래서 아래 항목은 대부분 "기능이 되는가"가 아니라 "엉뚱한 사람이 엉뚱한 걸 할 수 없는가"를 묻는 내용입니다.

비밀 키가 앱 코드에 들어 있지 않은가

가장 먼저 보는 항목입니다. 결제, 문자 발송, AI API(OpenAI, Anthropic 등), 데이터베이스 관리자 키 같은 비밀 값이 앱이나 웹 프론트엔드 코드에 들어 있으면 누구나 꺼내 쓸 수 있습니다. 모바일 앱도 설치 파일을 풀어 보면 문자열이 그대로 나옵니다. 웹은 브라우저 개발자 도구만 열어도 보입니다.

유료 API 호출 구조

앱비밀 키 없이 서버에 요청

서버키 보관, 호출 횟수 제한

외부 유료 API결제, 문자, AI 호출

AI 도구가 빠르게 동작을 확인하려고 키를 코드에 직접 적어 두는 경우가 있고, .env 파일이 Git 저장소에 같이 올라가 있는 경우도 흔합니다. 확인할 것은 이렇습니다.

• 프론트엔드나 앱 코드에서 sk-, secret, service_role 같은 문자열을 검색해 봅니다.
• .env 파일이 .gitignore에 들어 있는지, 이미 커밋된 적은 없는지 봅니다. 한 번이라도 공개 저장소에 올라갔다면 지우는 것으로는 부족하고 키를 새로 발급해야 합니다.
• 유료 외부 API는 앱에서 직접 부르지 말고 서버(또는 서버리스 함수)를 거치게 합니다. 그래야 키도 숨기고 호출 횟수도 제한할 수 있습니다.

AI API 키가 새면 피해가 바로 요금으로 돌아옵니다. 다른 사람이 그 키로 호출한 사용량까지 청구되기 때문에, 서비스 대시보드에서 사용 한도와 알림을 설정해 두는 것도 함께 권합니다.

데이터베이스 접근 규칙이 걸려 있는가

Supabase나 Firebase처럼 앱이 데이터베이스에 직접 붙는 구조는 AI 도구들이 아주 좋아하는 조합입니다. 서버를 따로 만들지 않아도 되니 빠릅니다. 대신 접근 규칙을 제대로 걸지 않으면 데이터가 통째로 열립니다.

Supabase 키 두 종류

공개용 키

• 앱에 넣어도 됨
• RLS 정책 범위만 접근
• 모든 테이블 RLS 필요

secret 키

• 앱, 브라우저에 금지
• RLS를 모두 무시
• 저장소에도 올리지 않기

Supabase를 예로 들면, 공식 문서는 앱에 넣는 공개용 키(publishable 또는 anon 키)는 노출돼도 괜찮지만 그 키로 무엇에 접근할 수 있는지는 행 단위 보안(RLS, Row Level Security) 정책이 정한다고 설명합니다. 그래서 배포 전에 모든 테이블에 RLS를 켜라고 안내합니다. 반대로 secret 키나 service_role 키는 RLS를 무시하기 때문에 앱이나 브라우저, 소스 저장소에 절대 넣지 말라고 적혀 있습니다.

실무에서 자주 보는 실수는 이런 것들입니다.

• 개발 중에 오류가 나서 RLS를 꺼 두고 그대로 잊어버린 경우
• 정책을 "로그인한 사용자는 모두 읽기 가능"으로 넓게 잡아서, 로그인만 하면 남의 데이터도 보이는 경우
• 앱 쪽 코드에서 "내 글만 보여 주기"로 걸러 놓고 안심한 경우. 앱에서 거르는 것은 화면 표시일 뿐이고, 요청을 직접 보내면 다 받아 갈 수 있습니다.

확인 방법은 단순합니다. 테스트 계정을 두 개 만들고, A 계정으로 로그인한 상태에서 B 계정의 데이터를 조회하거나 수정하는 요청을 직접 보내 봅니다. 막히는 게 정상입니다. Firebase를 쓴다면 Security Rules에 대해 같은 방식으로 확인합니다.

입력값 검증과 오류 처리

AI가 만든 폼은 보통 앱 화면에서만 입력값을 검사합니다. 이메일 형식, 글자 수 제한 같은 것들입니다. 그런데 화면 검사는 요청을 직접 보내면 건너뛸 수 있습니다. 가격, 수량, 권한 등급처럼 바뀌면 곤란한 값은 반드시 서버나 데이터베이스 쪽에서 다시 확인해야 합니다. 결제 금액을 앱이 계산해서 서버로 보내는 구조라면 특히 위험합니다.

예외 상황 점검

• 가격, 수량을 서버에서 다시 확인
• 네트워크가 끊겨도 무한 로딩 없음
• 서버 오류에도 앱이 꺼지지 않음
• 버튼 두 번 눌러도 주문은 한 번
• 오류 메시지에 내부 정보 없음

오류 처리는 정상 흐름만 만들어진 경우가 많습니다. 네트워크가 끊겼을 때 무한 로딩이 뜨는지, 서버가 오류를 돌려줬을 때 앱이 꺼지는지, 같은 버튼을 빠르게 두 번 눌렀을 때 주문이 두 번 들어가는지를 봅니다. 오류 메시지에 데이터베이스 테이블 이름이나 내부 경로가 그대로 찍히는 것도 흔한데, 사용자에게는 짧은 안내만 보여 주고 자세한 내용은 로그로 보내는 게 맞습니다.

이런 예외 시나리오는 출시 전 QA 점검 글에 영역별로 더 자세히 정리해 두었습니다.

스토어 심사에서 걸리는 것들

웹으로만 낼 거라면 이 부분은 건너뛰셔도 됩니다. 앱스토어나 구글 플레이에 올린다면 AI가 거의 챙기지 않는 항목이 몇 가지 있습니다.

구글은 계정을 비활성화하거나 잠시 정지하는 것은 삭제로 인정하지 않는다고 안내합니다. 탈퇴를 누르면 실제로 무엇이 지워지는지 정해 두셔야 합니다.

개인 개발자 계정으로 구글 플레이에 처음 올리는 경우라면 일정도 미리 잡아 두세요. 2023년 11월 13일 이후 만든 개인 계정은 테스터 12명 이상이 14일 연속으로 참여한 비공개 테스트를 거쳐야 정식 출시를 신청할 수 있습니다. 구글 플레이 콘솔 도움말에 나온 개인 계정 기준이니, 회사 명의로 계정을 만들 계획이라면 조건을 따로 확인해 보세요. 애플 심사 반려에 대한 대응은 심사 거절 사유와 대응 방법에서 따로 다뤘습니다.

성능과 크래시 수집

AI가 만든 코드는 데이터가 적을 때 문제가 없다가, 데이터가 쌓이면 느려지는 경우가 많습니다. 목록 화면에서 전체 데이터를 한 번에 불러오거나, 목록의 항목마다 따로 요청을 보내는 식입니다. 테스트 데이터를 수천 건 넣어 놓고 목록, 검색, 정렬 화면을 열어 보면 대부분 드러납니다. 자주 조회하는 컬럼에 인덱스(검색을 빠르게 해 주는 색인)가 있는지도 봅니다.

이미지도 자주 걸립니다. 원본 사진을 그대로 올리고 그대로 내려받으면 데이터 요금과 로딩 시간이 함께 늘어납니다. 업로드할 때 크기를 줄이거나 썸네일을 따로 만들어 두는 게 좋습니다.

출시 전에 크래시 수집 도구는 꼭 붙여 두세요. Firebase Crashlytics나 Sentry 같은 도구가 있으면 사용자가 신고하기 전에 어느 기기, 어느 화면에서 앱이 꺼졌는지 알 수 있습니다. 혼자 만든 앱일수록 사용자가 직접 알려 주는 경우가 드뭅니다. 조용히 지우고 떠납니다.

출시 후에 이 코드는 누가 고치나요

마지막 항목이 사실 가장 오래 남는 문제입니다. 출시하고 나면 OS 업데이트, 라이브러리 보안 패치, 스토어 정책 변경이 계속 들어옵니다. 애플은 해마다 새 Xcode와 SDK로 빌드하라는 요건을 내고, 구글도 대상 API 수준을 주기적으로 올립니다. 그때마다 누군가는 코드를 열어서 고쳐야 합니다.

AI로 만든 코드는 만든 사람도 구조를 잘 모르는 경우가 많습니다. 문제가 생겼을 때 AI에게 다시 고쳐 달라고 하면 되긴 하지만, 그러다 다른 곳이 깨지는 일이 반복되면 감당이 어려워집니다. 출시 전에 최소한 아래 정도는 정리해 두시길 권합니다.

• 소스코드가 Git 저장소에 있고, 접근 권한을 가진 사람이 둘 이상인지
• 서버, 데이터베이스, 도메인, 스토어 계정이 개인이 아닌 회사 명의로 되어 있는지
• 어떤 외부 서비스를 쓰고 있고 각각 어디에 키가 있는지 적은 문서
• 배포하는 방법을 처음 보는 개발자도 따라 할 수 있게 적은 메모

저희도 AI 도구로 만든 앱을 이어받는 일을 종종 하는데, 이 네 가지가 있느냐 없느냐에 따라 인수에 드는 시간이 크게 달라집니다.

자주 묻는 질문

AI가 만든 코드는 원래 보안이 약한가요?

AI가 일부러 허술하게 만드는 건 아닙니다. 요청한 범위 안에서 동작하는 코드를 만들다 보니, 권한이나 예외 상황처럼 요청하지 않은 부분이 비는 경우가 많은 겁니다. 처음부터 "RLS를 켜고 사용자 본인 데이터만 접근 가능하게"처럼 조건을 명시하면 결과가 꽤 달라집니다.

개발자에게 검토만 맡길 수도 있나요?

가능합니다. 전체를 다시 만들 필요는 없고, 키 노출, 데이터 접근 규칙, 결제나 개인정보 흐름처럼 위험한 부분부터 보는 방식으로 진행할 수 있습니다. 검토 결과에 따라 고칠 범위가 정해집니다.

사용자가 적으면 보안은 나중에 챙겨도 되지 않나요?

사용자가 열 명이어도 그 열 명의 개인정보는 보호해야 합니다. 그리고 공개된 키나 열린 데이터베이스는 사용자 수와 관계없이 자동화된 도구로 찾아내는 경우가 있습니다. 비밀 키와 접근 규칙만큼은 첫 출시 전에 확인하시는 게 맞습니다.

AI로 만든 앱의 출시 전 점검이나 이후 운영을 맡길 곳을 찾으신다면 상담으로 연락 주세요. 저희가 AI 기능을 넣은 앱을 만드는 방식은 AI 앱 개발 페이지에 정리해 두었습니다.