AI로 앱 만들기, 화면보다 먼저 끝까지 작동하는 흐름을 만드세요

AI로 앱을 만들면 첫 화면은 정말 빠르게 나옵니다.

원하는 색과 메뉴를 설명하면 몇 분 안에 그럴듯한 화면이 생깁니다. 신청서, 목록과 대시보드처럼 자주 사용하는 형태는 예시 데이터까지 채워서 보여줘요.

그래서 처음에는 개발 속도가 이전과 완전히 달라졌다고 느낍니다. 실제로 달라졌습니다.

하지만 여기에서 한 가지를 구분해야 합니다.

앱처럼 보이는 화면
≠
누군가 처음부터 끝까지 사용할 수 있는 앱

AI로 앱을 만들 때 가장 먼저 완성해야 하는 것은 여러 개의 화면이 아닙니다. 사용자의 행동 하나가 화면에서 데이터베이스와 배포 환경까지 끝까지 이어지는 흐름입니다.

먼저 웹앱인지 모바일 앱인지 정하세요

“앱을 만들고 싶다”는 말에는 서로 다른 결과물이 섞여 있습니다.

웹앱

브라우저 주소로 접속합니다. 컴퓨터와 스마트폰에서 모두 열 수 있고, 수정한 뒤 다시 배포하면 사용자에게 바로 반영됩니다.

예약, 신청, 고객관리, 커뮤니티, 관리자 화면과 창업 아이디어의 첫 버전은 웹앱으로도 충분한 경우가 많습니다.

모바일 앱

앱스토어나 플레이스토어에서 설치합니다. 카메라, 위치, 푸시 알림, 건강 데이터와 백그라운드 동작처럼 스마트폰 기능을 깊게 사용해야 할 때 필요합니다.

개발자 계정, 앱 서명, 스토어용 이미지, 개인정보 안내와 심사 절차도 함께 준비해야 합니다.

내부 도구

나나 동료만 사용하는 관리 화면입니다. 공개 스토어가 필요하지 않고, 기존 업무를 줄이는 것이 목표입니다.

저는 처음 만드는 사람에게 특별한 이유가 없다면 웹앱부터 권합니다.

스마트폰에 설치되는 모양이 필요
→ 웹앱으로도 가능할 수 있음

카메라·푸시·오프라인 동작이 핵심
→ 모바일 앱 검토

스토어 앱이 더 완성된 제품이고 웹앱은 연습용인 것이 아닙니다. 사용자가 가장 쉽게 접근하고, 만드는 사람이 가장 빠르게 수정할 수 있는 배포 방식을 고르는 문제입니다.

모바일 앱이 꼭 필요한 경우와 기술 선택은 바이브코딩으로 모바일 앱을 만들 수 있을까요?에서 자세히 설명했습니다.

화면을 여러 개 만들면 왜 완성된 것처럼 보일까요?

화면은 눈에 보이고 진행 상황을 설명하기 쉽습니다.

로그인 화면
홈 화면
목록 화면
상세 화면
마이페이지

다섯 화면이 생기면 앱의 대부분을 만든 것처럼 느껴집니다. 하지만 버튼을 눌렀을 때 무엇이 저장되고, 새로고침한 뒤에도 남아 있는지 확인하지 않았다면 아직 하나의 기능도 끝나지 않았을 수 있어요.

사용자에게는 버튼 한 번이지만 내부에서는 여러 단계가 이어집니다.

사용자가 신청서를 작성합니다.
→ 화면이 입력값을 확인합니다.
→ 서버에 제출 요청을 보냅니다.
→ 서버가 권한과 데이터를 검사합니다.
→ 데이터베이스에 저장합니다.
→ 성공 또는 실패를 돌려줍니다.
→ 화면이 결과를 보여줍니다.

AI에게 “신청 화면을 만들어줘”라고 하면 화면을 만드는 것이 자연스럽습니다. 저장과 실패 처리까지 원했다면 그 흐름을 완료 조건에 포함해야 합니다.

첫 기능은 세로로 얇게 만드세요

앱을 빠르게 완성하려면 화면별로 넓게 만들지 말고, 기능 하나를 처음부터 끝까지 연결해야 합니다.

수강 신청 서비스를 예로 들어보겠습니다.

화면부터 넓게 만드는 방식

홈 화면 디자인
→ 강의 목록 디자인
→ 상세 화면 디자인
→ 마이페이지 디자인
→ 마지막에 신청과 저장 연결

처음에는 빠르게 진행되지만 마지막에 모든 화면과 데이터를 한꺼번에 연결해야 합니다. 어디에서 문제가 생겼는지도 찾기 어려워져요.

기능을 세로로 연결하는 방식

강의 하나를 보여줍니다.
→ 이름과 연락처를 입력합니다.
→ 신청 내용을 저장합니다.
→ 신청자에게 완료를 보여줍니다.
→ 관리자가 저장된 신청을 확인합니다.
→ 실제 주소에 배포해 다시 확인합니다.

화면은 적지만 실제 사용자 행동 하나가 끝납니다. 이 흐름이 작동하면 다음 강의, 로그인과 알림을 같은 방식으로 추가할 수 있습니다.

이런 작업 단위를 개발에서는 세로 조각이나 vertical slice라고 부르기도 합니다. 이름을 외우는 것보다 화면·서버·데이터가 함께 작동하는 가장 작은 단위로 이해하면 됩니다.

만들기 전에 완료 조건을 적으세요

AI에게 기능을 요청하기 전에 직접 확인할 문장을 적습니다.

신청 기능 완료 조건

1. 이름이 없으면 제출되지 않습니다.
2. 제출하면 데이터베이스에 한 건 저장됩니다.
3. 성공하면 신청 완료 문구가 보입니다.
4. 실패하면 이유를 사용자가 알 수 있습니다.
5. 관리자가 신청 내용을 확인할 수 있습니다.
6. 배포한 주소에서도 같은 결과가 나옵니다.

이 목록이 있으면 AI가 “완료했습니다”라고 말한 뒤 무엇을 실행해야 하는지 분명해집니다.

프롬프트도 달라집니다.

나쁜 요청
신청 페이지를 예쁘게 만들어줘.

더 나은 요청
사용자가 이름과 연락처를 제출하면 서버가 입력값을 확인하고
데이터베이스에 저장하는 신청 기능을 만들어줘.
위의 완료 조건을 기준으로 구현 계획부터 설명하고,
구현 후에는 각 조건을 어떻게 확인했는지 알려줘.

프롬프트가 길어서 좋은 것이 아닙니다. 사용자 행동과 저장 결과, 실패 조건이 분명해서 확인하기 좋은 요청입니다.

AI로 빠르게 만들수록 검증이 중요합니다

AI는 몇 분 동안 여러 파일을 바꿀 수 있습니다. 만드는 속도가 빨라진 만큼 잘못된 가정도 빠르게 퍼질 수 있어요.

기능을 만든 뒤에는 세 가지 증거를 봅니다.

사용자의 화면

실제로 버튼을 눌러 기대한 결과가 보이는지 확인합니다. 컴퓨터뿐 아니라 스마트폰 크기에서도 중요한 행동을 할 수 있는지 봅니다.

데이터

AI가 저장했다고 말하는 것과 실제 데이터베이스에 기록된 것은 다릅니다. 테이블을 열어 새 데이터가 생겼는지, 같은 값이 두 번 저장되지 않았는지 확인합니다.

로그와 네트워크 요청

실패했는데 화면에 이유가 보이지 않으면 브라우저 네트워크 탭과 서버 로그를 확인합니다. 요청 자체가 없었는지, 서버에서 실패했는지, 데이터베이스가 거절했는지를 나눌 수 있습니다.

AI가 만든 결과를 검증한다는 것은 모든 코드를 읽는 일이 아닙니다. 내가 정의한 행동을 실행하고, 그 결과가 화면과 데이터에 남았는지 확인하는 일입니다.

로컬에서 되면 절반을 확인한 것입니다

내 컴퓨터의 localhost에서 작동한 앱을 실제 주소에 올리면 새로운 조건이 생깁니다.

로컬
→ 내 컴퓨터의 최신 파일
→ 내 컴퓨터의 환경변수
→ 개발용 주소

배포
→ GitHub에 올라간 commit
→ 배포 서비스의 환경변수
→ 실제 도메인과 운영 데이터

로컬에서 저장됐다는 사실은 배포 환경에도 같은 데이터베이스 주소와 API 키가 있다는 뜻이 아닙니다. 코드를 commit했더라도 push하지 않았다면 배포 서비스는 이전 버전을 보여줄 수 있어요.

그래서 첫 기능부터 배포해야 합니다. 모든 기능을 로컬에서 만든 뒤 마지막 날 배포하면 환경 차이 때문에 전체 일정이 멈출 수 있습니다.

로컬에서는 되는데 배포하면 안 되는 이유에서 코드 버전, 환경변수와 도메인을 확인하는 순서를 살펴볼 수 있습니다.

로그인은 화면보다 권한이 중요합니다

로그인 폼을 만드는 것은 어렵지 않습니다. 중요한 것은 로그인한 사람을 서버에서도 확인하고, 각자 볼 수 있는 데이터를 제한하는 일입니다.

로그인 화면이 있음
≠
내 정보가 안전함

사용자 A가 주소의 숫자를 바꿨을 때 사용자 B의 신청을 볼 수 있다면, 화면에 로그인 버튼이 있어도 권한은 구현되지 않은 것입니다.

로그인이 필요한 첫 앱이라면 다음을 확인하세요.

• 새로고침해도 로그인 상태가 유지됩니다.
• 로그아웃하면 보호된 화면을 볼 수 없습니다.
• 서버가 요청한 사용자를 다시 확인합니다.
• 다른 사용자의 데이터는 조회하거나 수정할 수 없습니다.

웹 앱에 로그인을 붙일 때 결정할 것에 인증과 권한의 차이를 정리했습니다.

결제는 성공 화면보다 실패 이후가 중요합니다

결제창을 띄우는 것만 보면 결제 기능도 빠르게 만들 수 있습니다. 그러나 돈이 오가는 기능은 화면보다 주문 상태가 정확해야 합니다.

카드 결제는 성공했는데 주문 저장이 실패하면?
사용자가 결제창을 닫으면 주문은 어떤 상태인가?
같은 성공 요청이 두 번 오면 결제도 두 번 처리되는가?
환불하면 주문과 수강 상태는 함께 바뀌는가?

이 질문에 답하지 못했다면 결제 버튼이 보여도 출시할 단계는 아닙니다.

처음 앱을 만드는 사람이라면 핵심 기능과 사용자를 먼저 검증한 뒤 결제를 붙이는 편이 좋습니다. 결제 연동 전에 준비할 주문과 실패 처리는 웹 앱에 결제 기능을 붙이는 방법에서 확인할 수 있습니다.

모바일 앱은 개발 뒤에 배포 절차가 더 있습니다

모바일 앱을 만들었다면 스토어에 제출하기 위한 준비가 필요합니다.

• Apple과 Google 개발자 계정을 만듭니다.
• 앱 아이콘, 설명과 스크린샷을 준비합니다.
• 개인정보 처리와 데이터 수집 내용을 표시합니다.
• 테스트용 빌드를 실제 기기에 설치합니다.
• 심사 의견에 따라 수정하고 다시 제출합니다.

AI는 설명문을 작성하고 필요한 설정을 찾고 반려 사유를 해석하는 데 도움을 줄 수 있습니다. 하지만 계정 소유자가 약관에 동의하고 정보를 확인하며 심사 결과에 대응하는 책임까지 없어지는 것은 아닙니다.

스토어 출시가 필요하다면 이 일정을 개발과 별도로 잡으세요.

고치다가 깨지는 일을 줄이려면 기록하세요

AI에게 요청을 반복하다 보면 어제 되던 기능이 오늘 바뀔 수 있습니다.

기능 하나가 완료 조건을 통과했을 때 Git으로 기록합니다.

신청 저장이 로컬에서 작동
→ commit

배포 환경에서도 작동
→ commit

로그인 사용자만 신청 가능
→ commit

기록이 있으면 언제부터 문제가 생겼는지 비교하고 작동하던 상태로 돌아갈 수 있습니다.

모든 변경을 한꺼번에 commit하면 어떤 기능 때문에 문제가 생겼는지 찾기 어렵습니다. 바이브코딩에서는 언제 commit해야 하는지에 기능 단위로 기록하는 기준을 정리했습니다.

AI로 앱을 만들 수 있을까요?

만들 수 있습니다. 다만 질문을 조금 바꾸는 편이 좋습니다.

AI가 앱 전체를 한 번에 만들어줄 수 있나요?

보다 다음 질문이 실제 완성에 가깝습니다.

사용자의 중요한 행동 하나를
화면부터 저장과 배포까지
AI와 함께 연결하고 검증할 수 있나요?

이 과정을 한 번 끝내면 다음 기능도 같은 방식으로 만들 수 있습니다.

제가 처음 앱을 만드는 사람에게 권하는 순서는 다음과 같습니다.

1. 스마트폰 고유 기능이 꼭 필요하지 않다면 웹앱으로 시작합니다.
2. 사용자 한 명의 가장 중요한 행동 하나를 고릅니다.
3. 화면·서버·데이터베이스를 함께 연결합니다.
4. 직접 확인할 완료 조건을 먼저 적습니다.
5. 첫 기능부터 실제 주소에 배포합니다.
6. 다른 사람이 사용한 뒤 다음 기능을 정합니다.

AI는 코드를 만드는 속도를 크게 바꿨습니다. 그 덕분에 비개발자도 자기 아이디어를 실제 소프트웨어로 만들 수 있게 됐어요.

하지만 무엇을 만들지 줄이고, 기능의 흐름을 연결하고, 결과를 증거로 확인하는 일은 여전히 만드는 사람의 몫입니다.

뚝딱에서는 정해진 예제의 화면을 따라 만드는 대신 수강생 각자의 프로젝트에서 이 과정을 반복합니다. 수업이 끝난 뒤에도 새로운 기능을 혼자 만들 수 있도록 돕는 방식은 뚝딱 오프라인 바이브코딩 강의에서 확인할 수 있습니다.