1인 앱 출시 과정, 기획·디자인·서버·화면·출시를 AI 작업 창 다섯에 나눠 앱스토어 심사 제출까지
앱 하나를 혼자 내야 하는 1인 사업자나 초기 창업 대표라면, 기획부터 스토어 심사까지 일이 어디서 어디로 넘어가는지부터 궁금할 거예요. 이 글은 커플앱 하나를 역할별 AI 작업 창(터미널) 다섯에 나눠 진행한 1인 앱 출시 기록이에요. 2026년 10월 14일에 첫 커밋을 넣었고, 다음 날인 10월 15일에 앱스토어(App Store) 심사를 제출했습니다.
다섯 창은 기획·통합, 디자인, 서버·DB, 앱 화면, 출시·법규·웹을 하나씩 맡았어요. 창마다 고치는 폴더가 정해져 있고, 남의 영역이 필요하면 작업 보드에 요청을 적어요. 사람(대표)은 몇 군데에서만 결정하거나 버튼을 누르는데, 1인 앱 출시에서 그 자리가 어디였는지도 같이 정리했습니다.
1인 앱 출시 기록이지만 앱 이름과 화면, 계정 정보는 싣지 않았어요. 채팅이 들어간 커플앱이고, 원본 규칙 파일이 채팅 안정성을 최우선 품질 기준으로 적어 둔 앱이라는 정도만 밝혀 둘게요.
1인 앱 출시를 다섯 역할로 나누고, 고치는 폴더를 따로 정했어요
이 1인 앱 출시의 뼈대는 원본 저장소 맨 위 규칙 파일의 다섯 역할 표예요. 프로젝트 폴더의 규칙 파일에는 역할마다 소유 폴더가 붙어 있어요. 기획·통합 담당(PM)은 규칙 파일과 기획 문서 폴더를, 디자인 담당은 디자인 시스템과 이미지 폴더를 맡아요. 서버 담당은 데이터베이스 설정과 앱의 서버 연결 코드를, 앱 화면 담당은 화면과 기능 폴더를 가져가고요. 출시 담당은 위젯·분석 폴더, 웹, 앱 설정 파일 두 개, 출시 문서 폴더를 맡습니다.
협업 규칙의 첫 줄은 이래요.
자기 소유 폴더만 수정한다. 다른 영역 변경이 필요하면 작업 보드의 “요청” 칸에 적는다.
1인 앱 출시 작업 보드의 요청 칸은 “누가 → 누구에게”, 내용, 상태 세 칸짜리 표예요. 실제로 오간 요청 가운데 출시 담당에게 간 것을 몇 줄 옮기고, 그 뒤 원본에 남은 기록을 붙였습니다.
| 누가 → 누구에게 | 요청한 것 | 그 뒤 기록 |
|---|---|---|
| 앱 화면 → 출시 | 사진을 보낼 때 뜨는 앨범 접근 권한 문구를 앱 설정 파일에 넣어 달라 | 보드에 반영 완료 표시 |
| 서버 → 출시 | 네이티브 구글 로그인에 필요한 플러그인을 앱 설정 파일에 넣어 달라 | 10월 14일 출시 담당 커밋 |
| 서버 → 출시 | 심사 노트 칸에 데모 경로 안내 문안을 넣어 달라 | 10월 15일 기획·통합 담당이 제출할 때 심사 노트에 데모 경로 안내가 들어감 |
혼자 하는 1인 앱 출시라도 역할 사이의 약속은 “계약”이라는 이름으로 따로 적혀 있어요. 서버 담당은 함수 시그니처와 메모리에서 도는 가짜 구현(목, Mock)을 먼저 커밋하고, 앱 화면 담당은 그 목으로 화면을 먼저 만들어요. 디자인 담당은 토큰과 컴포넌트를 한 파일에서 내보내고, 앱 화면 담당은 화면에 색이나 글꼴 값을 직접 적지 않습니다. 계약을 바꾸면 보드 “공지”에 남기는 게 규칙이에요.
첫날 디자인·서버·앱 화면·출시가 같이 깐 것
1인 앱 출시의 첫날인 10월 14일, 커밋 기록으로 보면 첫 커밋에 앱 골격(Expo), 기획서와 구조 문서, 역할 표가 한꺼번에 들어갔어요. 같은 날 디자인 담당은 디자인 토큰(Design Token)과 공통 컴포넌트를, 서버 담당은 DB 구조와 행 단위 보안 규칙(RLS), 그 규칙의 테스트와 목 API를 올렸습니다. 앱 화면 담당은 화면 구조(라우트) 뼈대와 온보딩을 만들었고요.
1인 앱 출시 작업 보드는 원래 두 단계로 나뉘어 있어요. 1단계 뼈대는 디자인·서버·앱 화면이 동시에, 2단계 연결·출시 준비는 출시 담당이 합류하는 구조예요. 1단계가 첫날 안에 끝나면서 출시 담당 작업도 첫날부터 보여요. 계정 가입 안내, 개인정보처리방침·약관·계정 삭제 안내 웹 초안, 스토어 등록정보 초안이 모두 10월 14일 커밋이에요.
서버 담당 역할 파일에는 보안 규칙이 따로 박혀 있어요. 상대 데이터 접근 제어는 반드시 RLS로. 클라이언트 필터 의존 금지.라는 규칙이에요. 커플 두 사람 사이에서 무엇이 언제 보이는지를 데이터베이스 규칙으로 막고, 테스트로 확인하게 한 거죠.
같은 날 기획·통합 담당은 비용 원칙과 대화 규칙을 문서로 남겼어요. 첫 테스트플라이트(TestFlight) 빌드를 대표 기기에 설치해 동작을 확인했다는 공지도 10월 14일 날짜로 올라와 있습니다.
작업 하나 = 대화 하나
1인 앱 출시 프로젝트 규칙 파일의 컨텍스트 규칙이에요. 작업이 끝나면 커밋하고, 작업 보드를 갱신하고, 남길 메모를 “공지”에 적은 뒤, 사용자에게 대화를 비워도 된다고 한 줄 알려요. 새 대화에서는 규칙 파일 → 자기 역할 파일 → 작업 보드만 읽고 이어가고, 다른 창의 코드는 통째로 읽지 않고 계약 파일만 봅니다.
출시 담당은 등록정보부터 법규 웹, 빌드 설정까지 맡았어요
1인 앱 출시의 마지막 구간은 출시 담당 몫이에요. 역할 파일에 적힌 할 일은 위젯, 빌드·배포, 웹 문서, 스토어 준비, 분석이고, 커밋 기록에 남은 일은 이 정도예요.
- 앱스토어·구글 플레이 계정 가입 안내 문서. 공식 문서로 확인한 항목과 가입 화면에서 다시 볼 항목을 표시로 나눴어요.
- 개인정보처리방침·이용약관·계정 삭제 안내 웹 페이지. 10월 15일에 시행일과 사업자 정보 칸을 채웠고, 10월 16일에는 아동 안전 표준 페이지를 더해 방침·약관·랜딩 페이지 아래에 링크를 걸었어요.
- 스토어 등록정보와 스크린샷 문구. 문서 첫머리에 “앱에 실제로 들어가는 기능만 쓴다”는 원칙이 있어요.
- 앱 설정 파일. 번들 ID, 빌드 프로필, 사진·카메라 권한 문구, Apple 로그인 사용과 암호화 면제 선언, 무선 업데이트(OTA) 설정이 여기 들어가요.
- 등록정보를 파일로 관리하는 설정. 카테고리, 연령 설문, 심사 연락처를 한 파일에 적어 두었어요.
네이티브 로그인은 1인 앱 출시에서 두 역할이 나눠 맡은 사례예요. 로그인 모듈을 바꾸는 코드는 서버 담당이, 그 모듈이 쓰는 앱 설정 파일 플러그인은 출시 담당이 넣었어요. 앱 설정 파일이 출시 담당 소유라서, 서버 담당은 요청 칸에 적어 넘긴 거죠.
출시 담당 역할 파일에는 Apple·Google 정책을 최신 공식 문서로 다시 확인하라는 줄도 있어요. 출시 전 확인 항목을 버전별로 관리하는 방법은 앱인토스 쪽 글 출시 전 체크리스트와 버전 관리에도 정리해 두었습니다.
심사자가 혼자 둘러볼 수 있게 데모 경로를 만들었어요
1인 앱 출시 심사를 준비할 때 커플앱은 따로 챙길 게 있어요. 두 사람이 연결돼야 핵심 화면이 열리거든요. 스토어 등록정보 문서의 심사 노트 초안에는 데모 계정 두 개를 대표가 제출 직전에 만들어 적고, 한쪽에서 만든 초대 코드를 다른 쪽에 넣는 방식이 적혀 있었어요.
10월 15일 작업 보드에는 서버 담당이 만든 심사용 데모 경로가 올라왔어요. 심사자는 자기 계정으로 로그인하고, 나이 확인과 닉네임을 거쳐 초대 화면에 심사 노트의 코드 하나만 넣으면 돼요. 그러면 그 계정만의 데모 상대와 샘플 채팅·카드·기념일·일정이 만들어지고, 처음 보낸 메시지에 데모 상대가 한 번 자동으로 답합니다.
이 코드는 심사 모드가 켜져 있을 때만 통하고, 꺼지면 없는 코드로 처리돼요. 일반 초대와 같은 속도 제한과 나이 확인이 그대로 걸려요. 데모 상대는 심사자마다 새로 만들어 서로 공유하지 않고, 로그인할 수 없는 계정이에요. 연결이 끝나면 매일 도는 정리 작업이 데모 상대와 데모 연결을 지웁니다.
켜고 끄는 시점도 공지에 있어요. 출시 뒤에는 끄고, 다음 심사 전에 다시 켭니다. 10월 16일 공지에는 구글 플레이 심사가 끝날 때까지 켜 둔다는 줄이 덧붙었고요.
앱인토스 소개 – 출시 전 체크리스트와 버전 관리, 검토부터 롤백(Rollback)까지1인 앱 출시에서 대표가 직접 정하고 누른 자리
AI 작업 창이 문서와 코드를 만드는 동안, 1인 앱 출시 원본에 대표 몫으로 적힌 자리는 따로 있었어요. 프로젝트 규칙 파일의 제품 절대 원칙 첫 줄이 AI 말투 변환 기능을 만들지 않는다이고, 괄호 안에 “대표 결정”이라고 적혀 있어요. 비용은 무료 티어를 먼저 쓰고, 유료가 꼭 필요하면 기획·통합 담당에게 먼저 보고하는 규칙이에요.
이 1인 앱 출시에서 10월 15일 앱스토어 1.0 심사를 낼 때 출시 방식은 수동으로 두었어요. 승인이 나도 대표가 출시를 눌러야 공개돼요. 계정 가입 안내 문서에는 “가입 도우미 모드”라는 안전 규칙이 있는데, AI는 화면을 보며 안내만 하고 계정 생성, 비밀번호와 2단계 인증, 카드 결제, 신분증 업로드, 약관 동의와 제출 버튼은 대표가 직접 합니다.
제출은 기획·통합 담당이 정리했어요
1인 앱 출시의 제출 단계를 10월 15일 공지로 보면 등록정보는 파일로, 스크린샷·연령·국가·심사 노트 같은 항목은 스토어 API로 기획·통합 담당 스크립트가 넣었고, 앱 개인정보 항목은 웹 화면에서 게시했어요. 커밋 기록에서 등록정보 파일은 출시 담당이 만들었고, 제출 공지는 기획·통합 담당 이름으로 올라와 있어요.
구글 플레이는 10월 16일 등록정보 입력까지 와 있어요
1인 앱 출시의 두 번째 스토어인 구글 플레이는 10월 16일 공지 기준으로 앱을 만들고 등록정보를 입력했어요. 기획·통합 담당이 개인정보처리방침 주소, 광고 없음, 카테고리, 연락처를 넣고, 기본 등록정보와 데이터 보안 항목은 임시저장해 뒀어요. 로그인 세부정보(앱 액세스)와 콘텐츠 등급 설문은 대표가 직접 하는 항목으로 적혀 있고, 콘텐츠 등급에는 약관 동의가 포함돼요. 그 뒤 타겟층과 데이터 보안 최종 저장을 기획·통합 담당이 이어 하는 순서예요.
같은 날 출시 담당은 앱 링크 확인 파일을 웹에 올리고 서명 정보를 기록했어요. 구글 로그인용 Android 클라이언트도 이날 등록됐고, 새 앱 번들은 출시 담당이 빌드하는 중이라고 적혀 있어요. 원본 계정 가입 안내 문서에는 2023년 11월 13일 이후 만든 개인 개발자 계정이면 테스터 12명 이상이 14일 연속 비공개 테스트에 참여해야 프로덕션을 신청할 수 있다는 구글 요건이 확인 표시와 함께 정리돼 있습니다. 공식 안내는 Play Console 고객센터의 새로운 개인 개발자 계정의 앱 테스트 요구사항에 있어요.
10월 19일에 원본 프로젝트 표를 다시 열어 보니 이 1인 앱 출시의 상태 칸은 10월 15일 이후 그대로 “App Store 심사 중, Google Play 준비”였어요. 같은 다섯 역할 표는 이 저장소의 두 번째 프로젝트에도 그대로 쓰이고 있어요.
1인 앱 출시를 역할로 나눠 보려면 이 순서로
이 1인 앱 출시 프로젝트 문서를 바탕으로 정리한 AI 업무 설계 순서예요. 1인 앱 출시가 아니어도 일을 여러 AI 작업 창에 나누는 경우라면 그대로 옮겨 볼 수 있어요.
- 역할 표를 먼저 쓰고, 역할마다 고치는 폴더를 적어요. 나머지 폴더는 요청으로만 건드리게 해요.
- 역할 사이에 넘기는 것(함수 시그니처, 디자인 내보내기)을 계약으로 정하고, 받는 쪽이 기다리지 않게 목부터 커밋하게 해요.
- 작업 보드에 “공지”와 “요청” 칸을 두고, 계약이 바뀌면 공지에 남겨요.
- 작업 하나를 대화 하나로 끊고, 끝날 때마다 커밋·보드 갱신·메모를 남기게 해요.
- 대표 몫(제품 원칙, 결제와 동의)을 문서에 적어 두고, AI 쪽에는 절차를 안내하고 기다리라고 적어요. 승인 뒤 출시 버튼을 누가 누를지는 이 프로젝트처럼 심사를 제출할 때 정해 둬요.
일을 단계로 쪼개는 방법 자체는 AI 업무 설계, 일 맡기기 전에 이렇게 쪼개 보세요에서 따로 다뤘어요. 콘텐츠 쪽에서 같은 방식으로 역할을 나눈 사례는 혼자 하는 콘텐츠 제작 자동화에 있습니다.
이 글의 근거
원본 저장소의 공통 규칙 파일, 프로젝트 규칙 파일, 역할별 시작 파일 다섯 개, 작업 보드, 기획서·구조 문서·비용 정책, 출시 문서(계정 가입 안내·스토어 등록정보·구글 플레이 등록 체크리스트)와 커밋 기록을 2026년 10월 19일에 읽고 옮겼어요. 상태는 그날 다시 연 작업 보드 공지와 프로젝트 표 기준이에요. 앱 이름, 패키지명, 계정·키·코드 값, 서버 주소, 비용 금액, 테스트 개수 같은 숫자는 옮기지 않았습니다. 앱스토어 심사 기준은 Apple의 앱 심사 지침에서 확인할 수 있고, 지침은 바뀔 수 있으니 원문을 확인해 주세요.
업종과 업무에 맞춘 AX 설계 상담은 무료 AX 상담 신청에서 받습니다.
1인 앱 출시 자주 묻는 질문
AI 작업 창을 여러 개 띄우면 서로 같은 파일을 고치다 꼬이지 않나요?
이 프로젝트는 역할마다 고치는 폴더를 정해 두고 자기 폴더만 수정하게 했어요. 다른 영역을 바꿔야 하면 작업 보드의 “요청” 칸에 누가 누구에게 무엇을 원하는지 적고, 커밋도 경로를 지정해서만 합니다. 함수 시그니처나 디자인 내보내기 같은 계약을 바꾸면 보드의 “공지”에 남겨요.
서버가 다 만들어지기 전에 앱 화면 작업을 시작할 수 있나요?
서버 담당이 함수 이름과 입출력, 메모리에서 도는 가짜 구현(목)을 먼저 커밋하는 규칙이 있었어요. 앱 화면 담당은 그 목을 써서 화면을 만들고, 나중에 실제 서버로 바꿉니다. 그래서 10월 14일 서버 담당의 목이 올라온 같은 날, 앱 화면 담당도 바로 화면 작업을 시작했어요.
앱스토어 심사에서 커플앱처럼 두 사람이 있어야 하는 기능은 어떻게 보여 주나요?
이 프로젝트는 심사 모드가 켜져 있을 때만 통하는 고정 초대 코드를 심사 노트에 적었어요. 심사자가 그 코드를 넣으면 그 계정만의 데모 상대와 샘플 데이터가 만들어지고, 첫 메시지에는 데모 상대가 한 번 자동으로 답합니다. 출시 뒤에는 심사 모드를 끄고 다음 심사 전에 다시 켜요.
이 글은 직접 만들고 운영하며 남긴 기록입니다. 적힌 수치는 작성 시점의 운영 계정 기준이며, 같은 결과나 수익을 보장하지 않습니다.
