앱 만들며 처음 부순 것들 — 비개발자가 첫 달에 밟는 함정

코드를 모르는 채로 앱을 만들기 시작한 첫 달 이야기입니다. 문법 때문에 고생한 기록은 아니에요.

달력이 화면에 떴습니다. 날짜를 누르니 입력창이 열리고, 저장을 누르니 일정 색깔이 칸에 들어갔어요. 그날 저는 큰 고비를 넘었다고 생각했습니다. 코드를 모르는 사람이 여기까지 왔으니 이제 예쁘게 다듬기만 하면 된다고요.

며칠 뒤 다른 계정으로 가입해 보고 생각이 바뀌었습니다. 새 제품의 회원 규칙을 손보는 과정에서 이미 잘 돌아가던 다른 제품의 가입 흐름까지 영향을 받을 수 있었거든요. 달력 화면은 멀쩡했어요. 대신 가게 입구의 장부가 섞일 뻔했습니다.

첫 달에 제가 가장 많이 틀린 건 코딩 문법이 아니라 보이는 화면을 제품 전체라고 생각한 것이었어요. 비개발자는 화면을 보면 안심하기 쉽습니다. 저도 그랬고요. 버튼이 눌리면 됐고 문구가 맞으면 끝난 줄 알았죠. 정작 오래 남는 문제는 가입, 권한, 저장, 빌드 설정, 스토어 식별자처럼 잘 안 보이는 데 있었습니다.

새 앱이 다른 제품의 장부를 건드렸습니다

제품 이름과 화면이 달라도 회원 저장소나 로그인 규칙을 같이 쓰면 한쪽 변경이 다른 쪽으로 번질 수 있어요. 새 앱에 필요한 사용자 정보를 추가하는 일이 기존 앱에는 예상 못 한 입력이 되기도 하고, 가입 직후 실행되는 자동 처리끼리 얽히기도 합니다.

처음엔 "새 앱 하나를 붙인다"고만 생각했어요. 실제로는 이미 영업 중인 가게 옆에 새 카운터를 내면서 같은 장부를 만진 셈이었죠.

그래서 제품을 나누는 기준을 폴더 이름이 아니라 실패가 어디까지 번지는가로 바꿨습니다. 새 앱 가입이 실패해도 기존 앱 가입은 계속돼야 하고, 한 제품의 탈퇴가 다른 제품 데이터까지 지우면 안 되니까요. 새 기능을 붙이기 전에 경계부터 확인했습니다.

이 일을 겪고 나서 제품 여러 개를 병행하는 법도 일정표가 아니라 격리 규칙으로 읽게 됐어요. 여러 제품을 동시에 만든다는 건 할 일 목록이 긴 상태가 아니라, 한쪽 실수가 다른 쪽 손님에게 닿을 가능성이 늘어난 상태였습니다.

"이 변경이 실패하면 어느 제품의 어느 사용자까지 영향을 받나요?"

코드를 몰라도 이 질문은 할 수 있어요. 오히려 코드를 모를수록 먼저 해야 합니다.

고친 설정이 다음번에 사라졌습니다

앱을 만들다 보면 생성된 파일을 직접 고치고 싶어지는 순간이 옵니다. 지금 보이는 설정 한 줄만 바꾸면 오류가 사라지니까요. 저도 그렇게 고치고 안심했어요.

문제는 다음번에 앱을 다시 만들 때 터졌습니다. 생성 도구가 그 파일을 처음부터 다시 만들면서 손으로 고친 내용이 통째로 날아갔거든요. 어제 분명히 해결한 오류가 오늘 그대로 돌아와 있었습니다.

비개발자에게는 정말 이상한 경험이에요. 파일을 저장했는데 왜 저장이 안 됐는지 이해가 안 되니까요. 하지만 생성되는 파일은 완제품이라기보다 출력물에 가깝습니다. 출력된 종이에 펜으로 고친 다음 원본 문서를 다시 인쇄하면 펜 자국이 사라지는 것과 같아요.

그 뒤로는 수정할 때 두 가지를 물었습니다. 이 파일이 원본인가 생성물인가, 그리고 다음 생성에도 남게 하려면 어디를 바꿔야 하는가. 임시 수정은 오류를 확인하는 실험으로만 쓰고 실제 해결은 원본 설정에 넣었어요.

기획서를 쓰는 법이 중요한 이유가 여기 있습니다. "이 파일을 고쳐 주세요"보다 "다음에 다시 만들어도 유지되게 해 주세요"가 훨씬 정확한 지시예요.

스토어 이름은 메모장 제목이 아니었습니다

앱 화면의 이름은 나중에 고칠 수 있어 보이죠. 그래서 패키지 이름과 식별자도 대충 임시로 시작하기 쉽습니다. 저도 "출시 전에 바꾸면 되지" 했고요.

Google Play의 공식 앱 생성 안내는 패키지 이름을 고유하고 영구적인 식별자로 설명합니다. 앱 삭제 안내에는 설치 이력이 있는 삭제 앱의 패키지 이름을 다른 앱에서 다시 쓸 수 없다고 적혀 있고요. 2026년 8월 기준으로 확인한 규칙입니다.

이건 사용자에게 보이는 앱 제목과 성격이 다릅니다. 가게 간판보다 사업자번호에 가깝죠. 표시 이름은 바꿔도 뒤에서 앱을 구분하는 번호는 계속 따라다닙니다.

그래서 첫 화면을 만들기 전에도 최소한 셋은 확정해야 해요. 제품을 구분할 이름, 어느 회사나 계정이 소유할지, 나중에 다른 제품과 충돌하지 않을 식별자. 예쁜 이름을 완벽하게 정하라는 뜻이 아니라 임시값을 영구 식별자 자리에 넣지 말라는 뜻입니다.

주소 하나가 심사에서 다른 페이지를 열었습니다

개인정보 처리방침과 지원 페이지도 화면 안 문구만 고치면 되는 줄 알았어요. 그런데 앱 안 버튼, 스토어 등록 정보, 심사 메모가 서로 다른 주소를 가리키고 있을 수 있더군요. 한 곳을 고쳤는데 다른 곳은 옛 주소로 남아서, 심사자가 누르는 링크에서는 빈 페이지가 열릴 수도 있었습니다.

그래서 문서가 있느냐보다 모든 입구에서 같은 문서가 열리느냐를 확인했어요. 로그인하지 않은 브라우저에서도 열리는지, 모바일에서도 읽히는지, 리다이렉트를 거친 뒤에 주소가 깨지지 않는지까지요.

앱스토어 심사가 가르쳐 준 것과 이어지는 이야기입니다. 심사는 우리가 설명한 제품이 아니라 심사자가 실제로 누른 링크와 버튼을 보니까요.

이런 반론을 자주 듣습니다

"개발자를 붙였으면 이런 실수는 없었다." 문법 오류나 설정 위치는 더 빨리 찾았겠죠. 하지만 어느 제품까지 영향을 받아도 되는지, 어떤 이름을 오래 쓸지, 심사 링크의 주인이 누구인지는 사업 판단입니다. 외주를 줘도 내가 결정하지 않으면 그 자리에 임시값이 들어가요. 개발자를 쓰지 말라는 게 아니라 책임질 경계는 맡길 수 없다는 이야기입니다.

"AI가 완료했다고 했으면 파일이 바뀐 것이다." 보고와 결과는 다릅니다. 계획만 만들고 실제 파일을 안 건드릴 수도 있고, 한 파일을 고쳤지만 다른 생성 과정에서 다시 덮일 수도 있어요. AI에게 맡기면 안 되는 일에서 결제와 권한뿐 아니라 완료 확인까지 따로 다룬 이유가 그겁니다. 완료 문장 말고 변경된 파일과 실제 동작을 보세요.

"처음엔 빨리 만들고 나중에 구조를 잡으면 된다." 색상과 문구는 그래도 됩니다. 회원 경계, 패키지 이름, 결제 귀속은 나중에 바꿀수록 이사 범위가 커져요. 그렇다고 모든 구조를 먼저 설계하라는 말로 과잉 해석하면 아예 시작을 못 합니다. 되돌리기 어려운 것만 먼저 고르자는 말이에요.

"테스트가 통과하면 출시 준비가 끝났다." 테스트는 내가 적어 둔 질문에만 답합니다. 다른 제품 가입이 여전히 되는지, 새로 만든 설정이 다음 빌드에도 남는지, 심사 링크가 로그아웃 상태에서도 열리는지는 묻지 않으면 그냥 빠져요. 초반에는 테스트 개수보다 질문의 경계가 중요했습니다.

첫 달엔 이 순서로 보면 덜 부서집니다

먼저 계정과 저장을 봅니다. 새 가입, 재로그인, 탈퇴, 다른 제품과의 분리가 맞는지. 그다음 권한이에요. 알림이나 캘린더 접근을 거절했을 때 앱이 멈추지 않는지, 나중에 다시 켤 길이 있는지 보고요. 그다음이 생성과 배포입니다. 오늘 고친 설정이 다음 생성에도 남는지, 실제 설치한 앱이 같은 동작을 하는지.

화면은 마지막에 다듬었어요. 화면이 안 중요해서가 아닙니다. 앞의 문제들은 잘못되면 데이터와 계정을 옮겨야 하지만 색과 간격은 다음 업데이트에서 고칠 수 있으니까요. 다음 앱에서 다르게 할 것도 이 순서에서 출발했습니다.

"내 폰에서는 되던데"를 벗어나는 가장 작은 검수

기기를 여러 대 살 필요는 없었어요. 같은 폰에서도 계정과 시간을 바꾸면 놓친 경계가 드러났거든요. 새 계정으로 가입하고, 앱을 완전히 닫았다 다시 열고, 로그아웃한 브라우저에서 지원 페이지를 눌러 보고, 마지막으로 앱을 지웠다 다시 설치한 뒤 저장과 구매 상태가 어떻게 돌아오는지 확인했습니다.

제가 만든 계정에서는 이미 권한과 설정이 다 갖춰져 있어서 잘되는 경우가 많았어요. 처음 온 사람의 빈 계정에서만 안내가 빠지거나 버튼이 막혔습니다. 그래서 출시 전 마지막 확인은 익숙한 제 계정이 아니라 아무것도 없는 계정으로 했어요. 첫 사용자가 막히는 자리는 오래 쓴 제작자 화면으로는 잘 안 보입니다.

여기서 잘못 따라 하면 안 되는 것

"보이지 않는 것부터 본다"를 화면은 대충 만들어도 된다는 뜻으로 읽으면 곤란해요. 사용자가 조작을 이해하지 못하면 저장이 아무리 정확해도 실패입니다.

다만 첫 달의 검수 우선순위를 정할 때는 복구 비용을 봐야 합니다. 버튼 간격은 업데이트로 고칠 수 있지만 다른 제품 사용자까지 잘못 지운 데이터는 되돌리기 어려우니까요. 둘 다 고치되 순서를 바꾸는 겁니다.

공식 문서의 한 문장을 모든 상황에 그대로 적용하는 것도 위험해요. 스토어 정책과 화면은 바뀌고, 계정 상태에 따라 가능한 작업도 달라집니다. 실제 콘솔에서 현재 상태를 확인한 뒤 결정하시지요.

확인 기준과 한계

스토어 규칙과 제품 상태는 2026년 8월 기준으로 공식 문서를 다시 확인했습니다. 패키지 이름의 재사용 가능 여부는 설치 이력 같은 조건에 따라 달라지므로 "모든 삭제 앱은 무조건 재사용 불가"라고 단순화하지 않았어요.

이 글은 첫 달에 겪은 사례를 통계처럼 일반화한 글이 아닙니다. 비개발자 몇 명 중 몇 명이 같은 실수를 하더라는 조사도 없고요. 제가 직접 만들고 배포를 준비하며 확인한 실패를 되돌리기 어려운 순서로 정리한 경험담입니다.

짧은 문답

코드를 모르는데 무엇으로 완료를 확인하나요?

실제 가입, 실제 저장, 앱 재실행 뒤 유지, 다른 계정에서의 보임을 봅니다. 파일 이름을 몰라도 "앱을 껐다 켠 뒤에도 남나요?"는 직접 확인할 수 있어요.

처음 정해야 할 이름은 앱 제목인가요, 패키지 이름인가요?

둘 다 보되 위험도가 다릅니다. 화면에 보이는 제목은 비교적 바꾸기 쉽고, 스토어와 앱을 구분하는 패키지 이름은 오래 남아요. 후자를 임시값으로 두지 않는 게 먼저입니다.

AI에게 어떤 문장으로 시켜야 덜 위험한가요?

"고쳐 줘"보다 완료 조건을 붙이세요. "다시 생성해도 유지되고, 기존 제품 가입은 그대로 되며, 변경 파일을 알려 줘"처럼 결과와 영향 범위를 같이 말하는 겁니다.

첫 달에 디자인은 언제 보나요?

매일 보셔도 됩니다. 다만 출시를 막는 순서는 가입·저장·권한·배포가 먼저예요. 디자인을 미루라는 게 아니라 예쁜 화면이 안전한 제품의 증거는 아니라는 뜻입니다.