바이브 코딩으로 앱을 만들다 보면 "빌드 성공"이라는 말을 가장 먼저 듣습니다. 파일이 만들어지고 자동 검사가 초록색으로 끝나면 다 된 것처럼 느껴집니다. 저는 코드를 직접 짜지 않고 AI에게 맡기는 비개발자인데, 7월 말 휴대폰과 컴퓨터에서 쓸 작은 앱을 만들면서 이 착각에 여러 번 걸렸습니다.
이 글은 당시 개발 기록에 남은 실패를 바탕으로, 빌드가 성공한 뒤에 무엇을 더 확인해야 "쓸 수 있는 앱"이 되는지 순서대로 정리했습니다. 앱 자체의 기능은 다루지 않고, 어떤 앱을 만들더라도 쓸 수 있는 확인 순서만 담았습니다.
먼저 밝혀 둘 것이 있습니다. 기록을 쓴 시점에도 실제 기기에서 확인하지 못한 항목이 남아 있었습니다. 그래서 아래 표에는 "확인 완료"와 "아직 확인 전"을 나눠 적었습니다.
기록에 남은 실패 다섯 가지
개발 기록의 "발생한 문제" 항목을 읽기 쉽게 줄이면 다섯 가지입니다.
| 번호 | 무슨 일이 있었나 | 근본 원인 | 고친 방법 |
|---|---|---|---|
| 1 | 앱에 입력한 주소가 데이터가 아니라 웹페이지여서 오류가 났습니다 | 입력칸의 의미를 화면이 설명하지 않았고, 응답 종류를 확인하지 않았습니다 | 주소 형식 검사, 응답 종류 검사, 잘못된 주소는 요청 전에 차단 |
| 2 | 기술적으로 가능한 방식이 사용자에게는 지나치게 복잡했습니다 | 데이터를 어떻게 얻을지에만 집중했습니다 | 기기마다 독립 실행을 기본으로 변경 |
| 3 | 앱이 사이트를 여는 링크 하나뿐이었습니다 | 어려운 로그인 단계를 피하려고 기능을 너무 줄였습니다 | 위젯, 고정 알림, 백그라운드 갱신을 최소 요구사항으로 확정 |
| 4 | 파일이 만들어진 것을 완성처럼 보고했습니다 | 확인 단계를 구분하지 않았습니다 | 확인 단계를 10가지로 분리(아래 표) |
| 5 | 기기마다 못 하는 일을 뒤늦게 알았습니다 | 기획 단계에서 제약을 조사하지 않았습니다 | 못 하는 기능과 대체 방법을 먼저 확정 |
가장 아팠던 것은 3번이었습니다. 링크만 여는 앱을 보여 드렸을 때 돌아온 반응은 "그럴 거면 그냥 사이트를 즐겨찾기 하지, 왜 앱으로 만드냐"였습니다. 틀린 말이 아니었습니다. 로그인이 어렵다는 이유로 기능을 줄이다 보니 앱으로 만들 이유까지 같이 사라진 것입니다.
빌드 성공 뒤에 거쳐야 할 10단계
4번 실패 뒤에 기록에 정리한 확인 단계입니다. 아래로 갈수록 "진짜로 쓸 수 있다"에 가까워지고, 앞 단계는 컴퓨터가 대신 확인해 주는 반면 뒤 단계는 내가 직접 기기를 만져야 합니다.
| 단계 | 확인할 것 | 누가 확인하나 | 이 단계를 통과해도 모르는 것 |
|---|---|---|---|
| 1 | 소스 정적 검사 | 자동 | 앱이 실제로 켜지는지 |
| 2 | 컴파일 성공 | 자동 | 설치가 되는지 |
| 3 | 설치 파일 구조 검사 | 자동 | 내 기기에서 받아들이는지 |
| 4 | 설치 성공 | 내가 직접 | 로그인이 되는지 |
| 5 | 로그인 성공 | 내가 직접 | 데이터를 받아오는지 |
| 6 | 데이터 조회 성공 | 내가 직접 | 화면에 제대로 나오는지 |
| 7 | 위젯·알림 표시 | 내가 직접 | 계속 갱신되는지 |
| 8 | 갱신 성공 | 내가 직접 | 껐다 켜도 유지되는지 |
| 9 | 재부팅 후 복원 | 내가 직접 | 하루 이상 버티는지 |
| 10 | 24시간 이상 안정성 | 내가 직접 | — |
1~3단계는 자동 빌드가 대신 해 주기 때문에 초록색이 뜹니다. 그런데 4단계부터는 사람이 실제 기기에서 눈으로 봐야 합니다. 제 기록에서 "확인 완료"로 적힌 항목은 대부분 1~3단계에 해당했고, 4단계 이후는 "아직 확인 전"이었습니다. 빌드 성공을 완성이라고 부르지 말아야 하는 이유가 이 표 한 장에 들어 있습니다.
플랫폼마다 먼저 확인할 제약
5번 실패는 기획 단계에서 막을 수 있습니다. 개발 기록에는 기기별로 불가능한 항목이 네 가지 정리돼 있습니다.
| 기기 | 기록에 정리한 제약 | 공식 문서로 확인되는 것 |
|---|---|---|
| 안드로이드 | 상태표시줄 안에 임의의 숫자 글자를 넣을 수 없음 | 위젯 자동 갱신 주기는 30분 미만으로 설정할 수 없음(안드로이드 개발자 문서) |
| 아이폰 | 위젯을 매분 갱신하도록 강제할 수 없음 | 이 글에서는 공식 문서를 확인하지 못함 |
| 윈도우 | 서명 없는 실행 파일은 보안 경고가 뜸 | 스마트스크린이 앱의 평판과 서명을 검사함(마이크로소프트 문서) |
| 아이폰 설치 파일 | 애플 서명이 있어야 설치 가능 | 이 글에서는 공식 문서를 확인하지 못함 |
공식 문서에서 확인한 것만 조금 더 풀어 쓰면 이렇습니다. 안드로이드 개발자 문서는 위젯의 갱신 주기 설정값이 30분보다 짧으면 지원하지 않는다고 적었고, 주기 갱신을 끄려면 0을 쓰라고 안내합니다. 마이크로소프트 문서는 스마트스크린이 다운로드한 프로그램의 평판과 파일에 쓰인 디지털 서명을 검사한다고 설명합니다. 그래서 "1분마다 숫자가 바뀌는 안드로이드 위젯"이나 "서명 없이 배포한 윈도우 설치 파일"을 AI에게 처음부터 시키면, 만들어 놓고도 약속한 대로 동작하지 않을 수 있습니다.
1번 실패에서 배운 입력 검사 순서
입력 검사는 비개발자도 AI에게 그대로 시킬 수 있는 항목이라 따로 적습니다. 앱이 주소 하나를 받아 그 주소의 데이터를 읽는 구조였는데, 어느 날 웹페이지 주소를 그대로 넣었더니 데이터 대신 웹페이지 문서가 돌아와 변환 오류가 났습니다. 오류 문구만 보면 앱이 고장 난 것처럼 보였지만 원인은 입력값에 있었습니다.
개발 기록에 정리한 검사 순서는 아래와 같고, 이 순서대로 AI에게 요청하면 같은 문제를 앞에서 막을 수 있습니다.
1. 주소 형식이 유효한지 먼저 확인합니다.
2. 휴대폰 자신을 가리키는 주소(localhost 같은 것)는 막습니다. 휴대폰에서는 그 주소가 컴퓨터가 아니라 휴대폰 자신을 뜻하기 때문입니다.
3. 일반 웹페이지 주소는 데이터 주소로 쓸 수 없다고 안내합니다.
4. 예상한 경로와 필요한 값이 들어 있는지 확인합니다.
5. 응답 상태가 정상(200)인지 확인합니다.
6. 응답 종류가 데이터 형식(JSON)인지 확인합니다.
7. 데이터 안에 필수 항목이 모두 있는지 확인합니다.
이 일곱 줄을 AI에게 "입력 주소 검사 규칙으로 구현해 줘"라고 주면, 사용자가 잘못된 주소를 넣어도 "이건 웹페이지 주소라 쓸 수 없어요"처럼 이유가 보이는 문구가 나옵니다. 오류가 나는 것 자체보다 오류가 이유를 설명하지 못하는 것이 더 큰 문제였습니다.
실기기에서 직접 확인할 체크표
기록에는 실기기 테스트를 위한 양식도 있었습니다. 설치부터 하루 뒤까지 아래 순서로 해 보면 4~10단계가 한 번에 정리됩니다.
1. 설치: 기존에 설치된 다른 서명의 앱이 있으면 지우고 새로 설치합니다. 알림 권한을 허용합니다.
2. 로그인과 수치: 로그인한 뒤 앱에 나오는 값을 원본 화면의 값과 나란히 놓고 비교합니다.
3. 화면 표시: 위젯을 작은 것과 중간 것으로 각각 추가하고, 표시 방식을 바꿔 즉시 갱신되는지 봅니다.
4. 화면 회전과 재시작: 화면을 돌리거나 홈 화면 앱을 다시 켜도 유지되는지 봅니다.
5. 백그라운드: 앱을 최근 목록에서 지우고, 화면을 끄고 1시간 뒤에 확인합니다. 절전 모드를 켰다 끄고, 와이파이에서 모바일 데이터로 바꿔 봅니다.
6. 재부팅: 기기를 다시 켠 뒤 알림과 위젯이 복원되는지 봅니다.
7. 오류 상황: 로그아웃하고, 서버를 끄고, 일부러 틀린 주소를 넣고, 네트워크를 끕니다. 오래된 데이터와 오류 메시지가 구분되어 보이는지 확인합니다.
기록 양식에 들어 있던 항목은 테스트 일시, 운영체제 버전, 기기 모델, 앱 버전, 각 단계의 성공 여부, 오류 화면 캡처, 해결 조치입니다. 이 목록을 메모장에 복사해 두고 한 줄씩 채워 가면 "된 것 같아요"라는 말 대신 "7번까지 통과, 8번에서 막힘"처럼 말할 수 있게 됩니다.
AI에게 맡길 때 바꾼 말투
이 경험 뒤에 AI에게 일을 시키는 문장을 바꿨습니다. 아래 표는 바뀐 요청의 예입니다.
| 전에 쓰던 말 | 바꾼 말 |
|---|---|
| 앱 만들어 줘 | 매일 어떤 화면을 보게 될지 먼저 그려 주고, 그다음에 만들어 줘 |
| 잘 됐어? | 10단계 중 어디까지 확인됐고 어디가 아직인지 나눠서 말해 줘 |
| 오류 고쳐 줘 | 이 오류가 입력 때문인지 코드 때문인지 먼저 구분해서 알려 줘 |
| 모든 기기에서 되게 해 줘 | 기기마다 못 하는 기능을 먼저 알려 주고, 대신 쓸 방법을 제안해 줘 |
특히 두 번째 말이 도움이 됩니다. AI는 "빌드가 성공했습니다"라고 보고하면서도 어디까지 확인했는지 구분해 말하지 않는 경우가 많습니다. 확인 단계를 숫자로 나눠 달라고 하면 어디까지가 자동 확인이고 어디부터가 사람이 볼 일인지 구분된 보고를 받을 수 있습니다. 같은 이유로 "고쳤습니다"라는 보고에도 어떤 단계에서 어떻게 확인했는지를 함께 적어 달라고 요청하세요. 자동 검사만 통과했는지, 실제 기기에서 눈으로 확인했는지가 한 줄로 구분되면, 나중에 다시 열어 볼 때 어디부터 의심해야 하는지 바로 보입니다.
헷갈리기 쉬운 점
- 자동 빌드의 초록 표시는 1~3단계입니다. 내 기기에서 되는지는 별개입니다.
- 오류 문구가 곧 원인은 아닙니다. 변환 오류 같은 말은 입력값이 틀렸을 때도 똑같이 나옵니다.
- 기능을 줄이는 것과 단순하게 만드는 것은 다릅니다. 링크만 여는 앱은 단순하지만 앱으로서 가치가 없었습니다.
- 기록에 없는 확인은 확인이 아닙니다. 이 글에서도 실기기에서 확인하지 못한 부분은 확인하지 못했다고 적었습니다.
함께 읽으면 좋은 글: 같은 개발 경험을 이어서 보려면 인스타 DM 자동발송 만들 때 막히는 곳, Meta 앱 연결 순서와 클로드 코드 설치 방법, 처음 막히는 단계와 확인 순서 정리를 보시면 됩니다.
---
출처: App widgets: 위젯 갱신 주기(Android Developers) · Microsoft Defender SmartScreen 개요(Microsoft Learn) · 개발 기록: 휴대폰·컴퓨터용 앱 개발 전 과정 기록(2026년 7월 30~31일)