다음에 앱을 만든다면 — 기능보다 먼저 검증할 일곱 장면

첫 화면이 나왔을 때는 거의 다 만든 줄 알았습니다. 날짜를 누르면 일정 입력창이 열리고, 저장을 누르면 달력에 색 막대가 생겼어요. 휴대폰 안에서 제가 만든 앱이 움직인다는 사실만으로도 충분히 놀라웠고요.

그런데 다른 사람을 초대하니까 일정이 안 보였습니다. 위젯을 붙이니 앱 안과 다른 날짜가 남았고, 결제를 취소한 뒤 다시 열었더니 창이 잠긴 적도 있었어요. 계정을 바꾸면 이전 사람의 화면이 잠깐 남는 문제도 있었고요. 각각은 작은 버그처럼 보였지만 사용자 입장에서는 제품의 중심이 깨진 일이었습니다.

다시 시작한다면 더 빨리 만들려고 하지 않을 겁니다. 기능을 덜 만들겠다는 말도 아니고요. 만드는 순서와 완료를 판단하는 장면을 바꾸겠다는 뜻이에요. 화면이 존재하는 날보다 처음 보는 사람이 끝까지 사용하고 다시 돌아오는 날을 앞에 두겠습니다.

이 글은 코딩 도구 추천이 아닙니다. 개발을 모르는 사람도 제품을 맡기고 확인할 수 있게, 다음 앱의 첫 주에 볼 장면을 쉬운 말로 정리한 글이에요. 스토어 절차와 위젯 동작은 2026년 8월 22일 Apple 공식 문서에서 다시 확인했습니다.

기능 목록 대신 마지막 장면을 씁니다

"공유 캘린더를 만든다"는 지시는 너무 커요. 달력 화면만 있어도 공유 캘린더라고 부를 수 있고, 초대 링크까지 있어도 그렇게 부를 수 있으니까요. 그런데 사용자가 원하는 마지막 장면은 훨씬 구체적입니다.

"한 사람이 약속을 넣으면, 초대받은 사람의 홈 화면에도 같은 약속이 보여요."

이 한 문장에 가입, 초대, 권한, 서버 저장, 동기화, 위젯 갱신이 전부 들어 있어요. 어느 한곳이 끊기면 문장이 거짓이 됩니다. 그래서 기능 이름보다 검증력이 훨씬 큽니다.

다음에는 모든 핵심 기능을 이런 문장으로 바꿀 거예요. 결제라면 "돈을 낸 뒤 해당 공간만 열리고, 앱을 다시 켜도 권한이 남아요." 계정 삭제라면 "삭제 뒤 다시 로그인해도 옛 일정이 돌아오지 않고 위젯도 비어요."

기획서가 실제 실력인 이유는 긴 문서를 잘 쓰는 데 있지 않습니다. 끝났는지를 누구나 같은 화면에서 판단하게 만드는 데 있어요.

첫 주부터 두 사람, 두 계정으로

공유 기능을 한 사람의 휴대폰에서만 시험하면 절반만 본 겁니다. 내가 만든 일정을 내가 보는 건 개인 캘린더 시험이에요. 초대 링크를 받은 사람이 가입하고, 공간에 들어오고, 일정을 수정하고, 나간 뒤에 무엇이 남는지까지 봐야 공유 시험이 됩니다.

다음에는 테스트 계정을 처음부터 둘로 만들 겁니다. 한쪽은 초대하는 사람, 다른 쪽은 처음 들어오는 사람으로 고정해서요. 서로 다른 네트워크에서도 보고, 앱을 완전히 닫았다 다시 열고, 초대를 두 번 눌렀을 때 중복이 생기는지도 확인하고요.

기기가 다르면 더 일찍 봐야 합니다. 데이리플의 공식 App Store 설명에는 서로 다른 휴대폰에서도 함께 쓸 수 있다는 방향이 적혀 있지만, 2026년 8월 22일 공식 다운로드 페이지의 Android 버전은 아직 Google Play 준비 중이에요. 그러니 지금 혼합 기기 사용자에게 "된다"고 말하면 안 됩니다. 개발 화면에서 Android 앱이 돌아가는 것과 사용자가 스토어에서 설치할 수 있는 것은 다른 완료 상태예요. 아이폰과 Android를 함께 만들며 배운 것도 결국 같은 이야기입니다. 코드가 둘 다 있다는 사실보다 두 스토어에서 실제로 만날 수 있는지가 먼저예요.

위젯은 앱 뒤의 장식이 아닙니다

캘린더의 핵심 장면이 홈 화면이라면 위젯은 부가기능이 아니에요. 앱 안에서 오늘 일정이 맞아도 위젯에 어제 일정이 남으면 사용자는 어제를 믿게 됩니다. 오히려 앱보다 자주 보이는 잘못된 화면이 되는 거죠.

Apple의 WidgetKit 갱신 공식 문서는 위젯 확장이 계속 실행되는 게 아니며 미리 만든 시간표와 시스템의 갱신 판단을 이용한다고 설명합니다. 앱이 새 데이터를 받았다고 위젯 화면이 매 순간 자동으로 다시 그려지는 구조가 아니에요.

다음에는 첫 주부터 위젯을 실제 홈 화면에 붙이겠습니다. 일정 추가, 수정, 삭제, 공간 전환, 로그아웃, 계정 전환, 날짜 변경을 차례로 보고요. 시뮬레이터 미리보기는 디자인 확인에 쓰고, 완료 판정은 제가 매일 쓰는 휴대폰 화면에서 하겠습니다. 아이폰 위젯 하나가 오래 걸린 이유와 위젯 검증 목록을 뒤 단계가 아니라 첫 주 자료로 둘 거예요.

결제창보다 권한의 끝을 먼저

결제 버튼이 열리고 영수증이 생기면 끝났다고 생각하기 쉽습니다. 실제 제품에서는 "무엇을 샀는가"가 서버의 권한으로 이어져야 해요. 공유 캘린더라면 특히 어느 공간을 샀는지가 중요합니다. 결제하는 사이 사용자가 다른 공간으로 옮겼다고 엉뚱한 데가 열리면 안 되니까요.

다음에는 결제 화면을 만들기 전에 상태표부터 적을 겁니다.

장면	확인할 것
결제 성공	올바른 계정·공간만 열림
결제 취소	잠금 상태가 깨지지 않고 다시 시도 가능
앱 재실행	구매 권한이 그대로 복원됨
기기 변경	공식 복원 경로로 같은 구매를 확인
환불·취소	서버 권한이 정책에 맞게 갱신됨

Apple의 인앱 구매 공식 제출 문서는 2026년 8월 기준 각 상품 유형의 첫 항목을 새 앱 버전과 함께 제출해야 한다고 안내합니다. 이런 절차를 AI의 기억이나 예전 블로그로 정하지 않고 제출하는 날 공식 페이지에서 다시 확인할 거예요. 결제를 붙이며 배운 것은 가격 화면보다 복원과 귀속이 먼저였다는 기록입니다.

삭제와 로그아웃을 출시 뒤로 미루지 않습니다

가입이 입구라면 로그아웃과 삭제는 출구예요. 입구만 잘 만들면 처음 설치한 화면은 멀쩡해 보입니다. 그런데 계정을 바꾸거나 지운 뒤에 옛 일정이 남는 순간 그건 개인정보 문제가 돼요.

Apple의 계정 삭제 공식 안내는 계정을 만드는 앱이 앱 안에서 삭제를 시작할 수 있게 하고 관련 개인정보를 처리해야 한다고 안내합니다. Sign in with Apple을 지원하는 경우 사용자 토큰 해지도 설명하고요.

다음에는 가입 기능과 삭제 기능을 같은 주에 만들겠습니다. 데이터베이스의 사용자 행만 지우고 끝내지 않고 공유 공간의 소유권, 초대, 결제 권한, 기기 저장, 알림, 위젯 화면까지 목록으로 볼 거예요. 삭제 뒤 같은 이메일로 가입했을 때 옛 데이터가 붙지 않는지도 확인하고요.

이건 개발자만 이해하는 보안 시험이 아닙니다. 비개발자도 "로그아웃했는데 홈 화면에 이전 일정이 남아 있는가"는 볼 수 있거든요. AI에게 최종 판단을 맡기지 말아야 할 것이 바로 이런 장면이에요.

스토어 문구를 마지막 날에 쓰지 않습니다

앱 설명과 스크린샷을 출시 직전에 만들면, 아직 없는 기능을 미래형으로 적거나 개발 화면의 약속을 현재 기능처럼 쓰게 됩니다. 데이리플에서도 앱은 한 플랫폼에 먼저 나왔는데 설명은 더 넓은 상태를 말하는 간격이 생겼어요. 다음에는 제품 범위와 스토어 범위를 한 표에서 같이 관리하겠습니다.

Apple의 App Review Guidelines 2.3은 설명, 스크린샷, 개인정보 정보가 실제 핵심 경험과 맞고 최신이어야 한다고 안내해요. 스크린샷은 예쁜 광고판이 아니라 현재 기능의 증거입니다.

그래서 첫 제출 전에는 심사에서 배운 것을 열고 지원 URL·개인정보 URL·스크린샷·다른 플랫폼 표현·가상 계정 데이터를 함께 볼 거예요. 한 언어만 고치고 다른 언어에 옛 약속을 남기지 않도록 현지화도 같은 체크표에 넣고요.

기능을 늘리기 전에 사용 신호를

만들 수 있다는 사실은 계속 만들 이유가 아닙니다. 다음 앱에서는 가입 수 하나만 보지 않을 거예요. 공유 앱이라면 초대 발송, 초대 수락, 두 사람이 같은 공간에서 실제로 활동한 흐름까지 봅니다. 설치만 하고 상대를 부르지 않았다면 핵심 가치까지 가지 못한 거니까요.

유료 제품이라면 실결제와 반복 사용을 따로 볼 거고요. 화면이 많고 칭찬을 받았는데 돈을 내는 사람이 없다면 신기능이 답이라고 단정하지 않겠습니다. 사용자가 멈춘 장면을 먼저 찾고, 그 장면이 고쳐진 뒤에도 신호가 없는지 봐야죠. 여러 제품을 동시에 만들며 생긴 문제에서 배운 것도 기능 속도가 아니라 멈출 조건이었어요. 새 앱을 열기 전에 이미 있는 앱의 초대와 공동 사용이 끝까지 이어지는지 확인하는 편이 훨씬 쌉니다.

여기서 자주 갈리는 말들

"처음에는 빨리 만들고 품질은 나중에 잡으면 된다." 글자 간격이나 애니메이션은 나중에 다듬을 수 있어요. 하지만 계정 분리, 결제 귀속, 삭제, 공유 권한을 뒤에 붙이면 저장 구조 전체를 다시 건드리게 됩니다. 처음부터 완벽하자는 말이 아니라 되돌리기 비싼 경계를 먼저 시험하자는 뜻이에요.

"실기기 검증은 개발이 끝난 뒤 하는 일이다." 위젯, 알림, 로그인 복귀, 결제창은 실제 휴대폰의 상태와 묶여 있어요. 미리보기에서 보인다고 홈 화면에서도 갱신된다는 보장이 없습니다. 실기기는 마지막 시험장이 아니라 첫 주의 작업 도구예요.

"AI가 코드를 만들면 요구사항은 짧아도 된다." AI는 빈칸을 채웁니다. 문제는 그 빈칸을 사용자가 원한 방향으로 채운다는 보장이 없다는 거죠. "공유 기능"보다 "초대받은 계정의 위젯에 같은 일정이 보임"이 훨씬 좋은 지시예요. 코드를 몰라도 마지막 장면은 쓸 수 있습니다.

"출시됐으면 제품 검증도 끝났다." 스토어 승인은 배포 조건을 통과했다는 뜻이에요. 사용자가 상대를 초대하고 함께 쓰고 결제하고 다시 돌아오는지는 완전히 별개의 검증입니다. 데이리플도 iPhone 출시 사실과 Android 이용 가능 여부를 분리해서 말해야 해요. 출시와 시장 검증은 같은 단어가 아닙니다.

일곱을 전부 하라는 숫자로 읽지 마세요

이 일곱 가지를 모든 앱에 같은 분량으로 적용하라는 법칙이 아니에요. 계정이 없는 오프라인 메모 앱이라면 삭제와 공유 권한이 핵심이 아닐 수 있고, 결제가 없는 앱이라면 인앱 구매 제출도 해당이 없죠.

중요한 건 내 앱에서 되돌리기 비싼 경계를 골라 첫 주에 보는 겁니다. 이 글의 Apple 절차는 2026년 8월 22일 확인 기준이라 다음 제출 때는 바뀔 수 있어요. 공식 문서를 다시 여는 습관까지가 절차입니다.

다음 첫 주에는 이렇게 움직입니다

첫날에는 마지막 장면을 한 문장으로 적어요. 둘째 날에는 테스트 계정과 기기를 둘로 나눕니다. 그다음부터 가입·초대·공유·위젯·결제·로그아웃·삭제를 가장 짧은 길로 연결해요. 예쁜 테마와 언어 확장은 이 길이 닫힌 뒤에 붙이고요.

저는 다시 앱을 만들 겁니다. 다만 달력 화면이 나온 날을 완성이라고 부르지는 않을 거예요. 상대가 초대를 받고, 같은 일정을 보고, 결제 뒤 권한이 남고, 로그아웃하면 옛 정보가 사라지는 날. 그날을 첫 완성으로 보겠습니다.

자주 묻는 질문

비개발자도 이 검증을 할 수 있나요?

할 수 있습니다. 코드를 읽지 않아도 "상대 폰에 같은 일정이 보이는가", "결제 취소 뒤 다시 누를 수 있는가", "로그아웃 뒤 위젯이 비는가"는 직접 볼 수 있어요. 기술 설명 대신 끝나는 장면을 적으면 됩니다.

기능을 적게 만들라는 뜻인가요?

핵심 경로가 닫히기 전에는 기능 수를 늘리지 말자는 뜻이에요. 초대가 안 되는데 테마를 늘리면 제품의 중심 문제는 그대로 남습니다. 핵심이 검증된 뒤의 확장은 훨씬 안전해요.

시뮬레이터는 쓰지 말아야 하나요?

써야죠. 빠른 화면 확인과 반복 작업에 좋습니다. 다만 위젯 갱신, 알림, 결제, 계정 전환처럼 실제 기기 상태에 묶인 기능의 최종 증거로 삼지 않는 것뿐이에요.

다음 앱의 첫 지표는 무엇으로 잡나요?

앱의 핵심 가치가 끝까지 전달된 행동으로요. 공유 캘린더라면 설치 수보다 초대 수락 뒤 공동 공간에서 일정이나 할 일이 실제로 만들어졌는지를 봅니다. 단순 방문보다 제품이 약속한 마지막 장면에 가까운 지표를 고르세요.