바이브코딩으로 만든 앱, 출시 전에 확인해야 할 것들

1 화면 완성과 출시 준비를 구분합니다

AI로 바이브코딩을 해서 로그인 화면과 결제 버튼까지 만들었습니다. 그렇다면 개발자에게 비용을 쓰는 이유는 무엇일까요?

코드를 대신 입력하는 일보다, 서비스가 약속한 대로 동작하는지 확인하고 문제를 해결하는 일이 남아 있기 때문입니다. 키플도 AI를 적극적으로 활용합니다. 중요한 것은 도구가 아니라 무엇을 검증했고 누가 이후의 변경을 맡을지입니다.

개인용 도구나 아이디어 검증용 시제품은 직접 만들어 보는 선택이 합리적일 수 있습니다. 반면 다른 사람의 정보나 결제를 다루는 서비스라면, 보이는 화면 밖의 동작까지 완료 기준에 넣어야 합니다. 아래 사례는 특정 고객에게 발생한 사고가 아니라 출시 전 확인할 상황입니다.

2 로그인 성공과 데이터 접근 권한을 따로 확인합니다

로그인은 사용자가 누구인지 확인하는 과정입니다. 그 사람이 어느 기록을 읽거나 수정할 수 있는지는 별도의 권한 문제입니다. 화면에서 버튼을 숨겼다고 서버의 접근까지 막히는 것은 아닙니다. OWASP 권한 검증 지침은 요청마다 권한을 확인하고 클라이언트의 판단에만 의존하지 않도록 안내합니다.

• 테스트 계정 A가 B의 비공개 기록을 조회·수정할 수 없는지 확인합니다.
• 로그아웃 후 B로 로그인했을 때 A의 기록과 알림 연결이 남지 않는지 확인합니다.
• 관리자 기능은 일반 계정에서 직접 요청해도 거절되는지 확인합니다.

Firebase를 사용하더라도 로그인 연동만으로 이 범위가 완성되지는 않습니다. Firestore 공식 예제도 로그인 여부 확인과 소유자 확인을 구분합니다. 검사 방법은 사용하는 서버 구조에 맞게 정해야 합니다.

3 결제 성공 뒤의 이용 권한까지 검수합니다

결제창이 닫히는 순간과 유료 기능이 열리는 순간은 같은 일이 아닙니다. 구매 확인, 이용 권한 반영, 앱 재실행 후 유지까지 이어서 확인하세요. Google Play도 구매 처리 흐름에서 구매 검증과 콘텐츠 제공을 별도 단계로 다룹니다.

• 결제가 대기·실패·취소된 경우 화면과 이용 권한이 실제 상태에 맞는가
• 결제 직후 통신이 끊겨도 다시 실행했을 때 결과를 확인할 수 있는가
• 복원 대상 상품이 재설치·기기 변경 후 정한 조건대로 복원되는가
• 갱신 취소, 이용 기간 만료, 환불에 따라 권한이 올바르게 갱신되는가

구독 갱신 취소와 즉시 이용 종료, 환불은 같은 의미가 아닙니다. Google Play 구독 상태를 기준으로 실제 상태를 확인해야 합니다. Apple도 현재 이용 권한에서 환불·철회된 상품과 소모성 상품을 별도로 다룹니다. 복원 범위는 상품 종류와 계정 설계에 따라 다르며, iOS와 Android 사이의 구매 이전이 자동으로 보장되는 것은 아닙니다.

4 잘 되는 순간보다 실패 이후를 확인합니다

저장 버튼을 한 번 눌러 성공한 것만으로 검수를 끝내지 않습니다. 같은 요청이 반복되거나 응답이 늦게 도착하는 조건도 필요합니다.

• 저장 도중 통신이 끊긴 뒤 다시 시도했을 때 기록이 빠지거나 중복되지 않는가
• 버튼을 연속으로 눌러도 주문·예약·보상이 의도치 않게 여러 번 처리되지 않는가
• 계정을 바꾸는 동안 이전 요청의 결과가 새 계정 화면에 섞이지 않는가
• 앱을 종료했다 다시 열거나 버전을 업데이트해도 필요한 기록이 유지되는가

지원 범위에 맞는 실제 기기에서 확인하고, 예상 결과·실제 결과·앱 버전을 남기세요. 오류 기록에는 문제를 찾을 정보가 필요하지만 비밀번호나 불필요한 개인정보까지 남겨서는 안 됩니다. 이 목록은 키플이 제안하는 검수 출발점이며 전체 보안 감사를 대신하지 않습니다.

5 다음 수정과 운영 인수까지 작업 범위에 넣습니다

기능 하나를 바꾼 뒤 로그인·결제·저장도 다시 확인할 수 있어야 합니다. 개발자가 작성한 코드도 오류가 생길 수 있으므로, 외주 계약 자체를 품질 보증으로 생각하지 않는 편이 좋습니다. 맡길 사람을 고를 때는 결과물과 검수 기록을 함께 보세요.

• 소스 저장소, 빌드 방법, 필요한 설정을 인계받는가
• 스토어·서버·도메인의 소유 및 관리 권한이 정리돼 있는가
• 장애 확인 방법, 백업과 복구 범위, 운영 비용을 설명받는가
• 수정 범위, 인수 기준, 출시 후 대응 담당자가 정해져 있는가

소스와 외부 라이브러리의 이용 조건도 확인하세요. 앱 개발 인수인계 체크리스트와 함께 정리하면 다음 개발자에게 넘어갈 때 필요한 자료를 빠뜨리지 않기 좋습니다.

6 이미 만든 앱을 버리기 전에

AI로 만들었다는 이유만으로 전부 다시 개발할 필요는 없습니다. 먼저 현재 동작과 구조를 확인하고, 사용할 수 있는 부분과 보완할 부분을 나누세요.

혼자 계속 개발하며 점검만 의뢰하거나, 로그인·결제 등 특정 구간을 보완하거나, 출시 준비와 운영 인수만 맡길 수도 있습니다. 전체 재개발은 점검 결과와 비용을 비교한 뒤 판단할 선택지입니다.

AI를 쓸지 개발자를 쓸지보다, 어디까지 직접 만들고 무엇을 함께 검증할지가 중요합니다. 개발비는 코드 양이 아니라 합의한 결과와 확인 범위로 비교해 보세요.

키플에 기존 앱을 문의할 때는 현재 되는 기능, 막힌 상황, 출시 목표를 알려주시면 됩니다. Flutter 앱 유지보수 안내에서 작업 범위를 확인할 수 있습니다. 실제 고객 데이터나 비밀번호를 먼저 보내실 필요는 없습니다.