앱 개발보다 앱 출시가 더 어려운 이유

홈페이지를 개발하는 사람들은 종종 앱 개발도 비슷할 것이라고 생각합니다. 하지만 실제로는 전혀 다릅니다. 홈페이지는 개발이 끝나면 서버에 업로드하는 순간 바로 서비스가 가능합니다. 반면 앱은 개발이 끝난 후에도 넘어야 할 과정이 많습니다. 홈페이지는 내가 결정한다 홈페이지는 개발자가 수정하고 서버에 업로드하면 바로 반영됩니다. 문제가 있으면 다시 수정해서 업로드하면 됩니다. 누군가의 승인을 받을 필요도 없습니다. 앱은 스토어가 결정한다 앱은 개발이 끝났다고 바로 공개할 수 없습니다. Apple App Store와 Google Play Store의 심사를 통과해야 합니다. 개발자가 보기에는 아무 문제가 없어도 심사 과정에서 수정 요청이 들어올 수 있습니다. 경우에 따라서는 기능 삭제나 정책 변경이 필요할 수도 있습니다. 개발보다 심사가 더 오래 걸릴 수 있다 특히 최근 구글 플레이 신규 개인 개발자 계정은 비공개 테스트 절차까지 거쳐야 합니다. 제가 최근 출시한 에듀페이의 경우도 개발보다 출시 절차에 더 많은 시간이 소요되었습니다. 내부 테스트, 비공개 테스트, 프로덕션 심사, 스토어 반영까지 거치다 보니 실제 정식 출시까지 약 20일 정도가 필요했습니다. 출시 후에도 끝이 아니다 정식 출시가 완료되면 모든 것이 끝날 것 같지만 그렇지 않습니다. 실제 사용자가 앱을 사용하기 시작하면 다양한 의견과 수정 요청이 들어옵니다. 문구 수정, 안내 메시지 변경, 사용 방법 개선 등 작은 요청들이 이어집니다. 개발자는 수정뿐 아니라 테스트와 검증도 함께 진행해야 합니다. 그래서 앱은 홈페이지와 다르다 홈페이지는 개발이 끝나면 바로 공개할 수 있습니다. 하지만 앱은 개발이 끝난 후부터가 진짜 시작이라고 해도 과장이 아닙니다. 심사, 출시, 운영, 유지보수까지 모두 포함해서 생각해야 하기 때문입니다. 그래서 많은 개발자들이 "앱 개발보다 앱 출시가 더 어렵다"는 말을 하게 되는 것 같습니다.

2026년 신규 개인 개발자 계정으로 구글 플레이 출시까지 실제 걸린 기간

최근 에듀페이(edupay)  앱을 구글 플레이 스토어에 정식 출시하면서 신규 개인 개발자 계정 기준으로 실제 어느 정도의 시간이 소요되는지 직접 확인할 수 있었습니다. 인터넷에는 "몇 달 걸린다", "출시가 매우 어렵다", "심사가 오래 걸린다"는 글도 많지만, 실제 진행 결과를 기록으로 남기겠습니다. 이번 에듀페이 프로젝트에서는 신규 개인 개발자 계정에 적용되는 출시 절차를 처음부터 직접 경험하게 되었습니다. 특히 비공개 테스트 14일 정책과 프로덕션 출시 심사 과정은 실제로 진행해 보기 전까지는 예상하기 어려운 부분이 많았으며, 이번 글은 제가 직접 진행하면서 측정한 실제 일정입니다. 1. 내부 테스트 앱을 업로드한 후 내부 테스트는 거의 즉시 진행할 수 있었습니다. 예전과 비교해도 특별히 지연된 부분은 없었으며, 업로드 후 바로 테스트가 가능한 수준이었습니다. 2. 비공개 테스트 신청 내부 테스트 이후 비공개 테스트를 신청했습니다. 구글 콘솔에는 심사에 최대 7일 정도 소요될 수 있다고 안내되어 있었지만 실제로는 약 1일 만에 승인되었습니다. 개인적으로는 이 단계에서 가장 오래 기다릴 것으로 예상했지만 의외로 매우 빠르게 처리되었습니다. 3. 비공개 테스터 모집 비공개 테스트에 참여할 테스터를 모집하는 과정이 필요했습니다. 실제로는 약 2~3일 정도가 소요되었습니다. 지인이 많으면 1일이면 충분할 걸로 생각됩니다.  개발 자체보다 참여자를 확보하는 과정이 더 어려울 수 있으므로 저 같은 찐따 개발자라면  일주일 전에 미리 준비하는 것이 좋다고 생각합니다. 4. 비공개 테스트 진행 신규 개인 개발자 계정은 12명 이상의 테스터가 참여하는 비공개 테스트를 진행해야 합니다. 에듀페이 역시 해당 절차를 그대로 진행했습니다. 비공개 테스트 기간은 14일이었으며, 이 기간이 전체 일정에서 가장 큰 비중을 차지했습니다. 비공개 테스터에게 리뷰 요청을 하세요. 리뷰가 있으면 프로덕션 출시 심사에 정말 유리합니다. ...

하이브리드 앱(WebView)에서 viewport 설정에 따른 화면 확대 차이

<meta name = "viewport" content = "width=device-width,initial-scale=1.0" > iOS에서는 화면 확대가 가능했다. Android에서는 대부분 확대되지 않았지만 간혹 확대되는 기기가 있었다. <meta name = "viewport" content = "width=device-width,initial-scale=1.0, viewport-fit=cover" > iOS와 Android 모두 화면 확대가 가능했다. Safe Area 대응 시 주로 사용한다. <meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0"> iOS와 Android 모두 화면 확대가 되지 않았다. 하이브리드 앱에서 화면 확대를 완전히 막고 싶을 때 사용한다. 리 2026년 기준 실제 하이브리드 앱 테스트 결과, 화면 확대를 완전히 막으려면 <meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0"> 가장 안정적으로 동작했다.

AI가 개발자를 대체한다? 현업에서 보면 전혀 다른 이야기

 요즘 AI 관련 광고를 보면 공통된 메시지가 있다. “이제 개발자 필요 없다” “AI가 대신 다 만들어준다” 처음 보면 맞는 말처럼 들린다. 코드도 만들어주고, 수정도 해주고, 심지어 앱도 만든다고 한다. 그런데 실제 개발 현장에서 보면 이야기가 완전히 다르다. AI는 분명히 빠르다. 간단한 기능이나 화면 정도는 금방 만들어준다. 검색보다 빠르고, 기본 코드 작성도 훨씬 편해졌다. 문제는 그 다음이다. 실제 서비스는 단순히 “코드가 돌아간다”로 끝나지 않는다. 로그인, 결제, 데이터 처리, 오류 대응까지 들어가는 순간 상황이 완전히 달라진다. 예를 들어 이런 경우가 있다. 기능은 정상적으로 동작하는데 특정 상황에서만 데이터가 저장되지 않는다. 또는 결제는 됐는데 DB에는 기록이 안 남는다. 이런 문제는 AI가 해결해주지 않는다. 오히려 원인을 찾는데 더 시간이 걸리는 경우도 많다. 그리고 더 중요한 건 따로 있다. 고객은 “코드”를 원하는 게 아니다. “문제가 없는 서비스”를 원한다. AI는 코드를 만들어준다. 하지만 구조를 설계하고, 예외를 고려하고, 문제가 생겼을 때 책임지는 건 사람이 해야 한다. 그래서 현업에서는 이렇게 말한다. AI는 도구다. 좋은 도구인 건 맞지만, 개발자를 대체하는 수준은 아니다. 오히려 반대다. AI 덕분에 개발 속도는 빨라졌지만 검수와 안정성의 중요성은 더 커졌다. 결국 개발자의 역할은 사라지는 게 아니라 조금씩 바뀌고 있다. 코드를 직접 다 치는 사람이 아니라 전체를 이해하고 문제를 해결하는 사람이 더 중요해지는 방향이다. 정리하면 이렇다. AI는 코드를 만들어준다. 하지만 서비스를 완성하는 건 여전히 사람이다.

“AI로 앱 하루 만에 만든다고? 직접 해본 개발자 후기”

 AI로 앱을 하루 만에 만들 수 있다고 해서 직접 해봤다. 결론부터 말하면, 가능은 하다. 근데 우리가 생각하는 ‘앱 개발’이랑은 완전히 다르다. 요즘 유튜브 보면 AI 앱 개발 영상이 넘쳐난다. 챗GPT 개발만으로 서비스 하나가 뚝딱 만들어지는 것처럼 보인다. 비개발자도 하루 만에 앱을 만든다고 한다. 여기까지는 틀린 말은 아니다. 간단한 기능 하나 정도는 진짜 금방 된다. 버튼 누르면 텍스트 바뀌는 거, 이미지 교체하는 거 이 정도는 AI 도움 없어도 30분이면 끝난다. 문제는 그 다음부터다. 실제 서비스는 버튼 하나로 끝나지 않는다. 회원가입, 로그인, 데이터 저장, 결제, 오류 처리 이걸 하나 씩 붙이기 시작하면 상황이 완전히 달라진다. 특히 결제 붙이는 순간부터 난이도가 확 올라간다. 테스트 결제, 취소, 재결제, 실패 케이스까지 한 번 제대로 돌려보면 “하루 만에 개발”이라는 말이 얼마나 단순화된 건지 바로 느껴진다. 예전에 이런 적도 있다. 테스트 결제 몇 번 돌리다가 승인은 됐는데 DB에 값이 안 찍히는 상황이 있었다. 로그 뒤지면서 원인 찾는데만 2시간 날렸다. 이런 건 AI가 대신 해결해주지 않는다. AI는 코드를 만들어준다. 그런데 그 코드가 실제 환경에서 바로 정상 동작하는지는 완전히 다른 문제다. 그리고 더 중요한 건 따로 있다. AI로 앱 만들기에서 가장 어려운 건 코드가 아니라 “구조”다. 어떤 흐름으로 만들지 어디서 오류가 날 수 있는지 사용자가 어디서 막힐지 이건 사람이 직접 경험해보고 설계해야 한다. AI는 방향을 잡아주지 않는다. 그냥 시키는 대로 만들어줄 뿐이다. 그래서 요즘 AI 개발 광고 보면 솔직히 좀 과하게 느껴진다. 틀린 말은 아닌데 중요한 부분은 다 빠져 있다. 정리하면 이렇다. 간단한 기능 → AI로 빠르게 가능 실제 서비스 → 여전히 사람 손 많이 간다 AI 앱 개발이 개발 속도를 올려준 건 맞다. 하지만 개발 자체가 쉬워졌다고 보...

“location.href vs replace 차이 때문에 삽질한 이야기”

 하이브리드 앱을 개발하면서 단순한 페이지 이동 로직을 만들었다. 버튼을 누르면 location.href 로 다른 페이지로 이동하고, 이전 버튼을 누르면 다시 돌아오는 구조였다. 웹에서는 이전 버튼을 자주 사용하지 않기 때문에 이 부분을 깊게 테스트 해 본적이 없다. 그런데 하이브리드 앱(WebView)에서 테스트하는 순간 문제가 바로 드러났다. 뒤로가기를 누르면 이전 페이지로 돌아가는 것이 아니라 같은 페이지를 계속 반복하면서 무한루프처럼 동작하기 시작했다. 처음에는 WebView 문제라고 생각했다. 하지만 원인은 location.href 와 히스토리 스택 구조였다. location.href 로 이동할 때마다 히스토리에 페이지가 계속 쌓이고 뒤로가기를 눌렀을 때 페이지가 다시 로드되면서 이동 스크립트가 또 실행되는 구조가 만들어진 것이다. 흐름은 이렇게 반복된다. A 페이지 → location.href → B 페이지 B 페이지 → 뒤로가기 → A 페이지 A 페이지 로드 → location.href 실행 → B 페이지 이 과정이 계속 반복되면서 하이브리드 앱에서는 뒤로가기 무한루프가 발생한다. 웹에서도 발생하는 문제지만 하이브리드 앱에서는 시스템 하단의 뒤로가기 버튼이 존재하기 때문에 이 문제가 훨씬 쉽게 드러난다. 특히 Android 물리 백버튼이나 iOS 제스처 뒤로가기와 결합되면 사용자는 앱이 고장난 것처럼 느끼게 된다. 해결 방법은 간단하다. 첫 번째는 location.href 대신 히스토리를 남기지 않는 location.replace 를 사용하는 것이다. location . replace( 'pageB.php' ); 이렇게 하면 히스토리가 쌓이지 않아 뒤로가기 루프가 발생하지 않는다. 두 번째는 자동 이동 로직이 한 번만 실행되도록 조건을 추가하는 방법이다. if (!sessionStorage.getItem('moved')) { sessionStor...

개발자가 AI를 고르는 기준, ChatGPT vs 퍼플렉시티 vs 제미나이 vs 그록

 요즘 개발자에게 AI는 필수 도구가 됐다. 대표적으로 많이 사용하는 AI는 ChatGPT, 퍼플렉시티, 제미나이, 그리고 그록이다. 각각 성격이 조금씩 다르다. 퍼플렉시티는 검색형 AI에 가깝다. 질문을 하면 핵심 정보를 빠르게 정리해 준다. 최신 문서나 정책 확인할 때 유용하다. 다만 코드 수정처럼 구체적인 작업에서는 설명이 짧게 끝나는 경우가 있어 추가 테스트가 필요할 때도 있다. 제미나이는 비교적 신중한 스타일이다. 정확성을 중요하게 보는 답변이 많다. 개념 설명이나 방향 정리에 도움이 된다. 하지만 코드 디버깅에서는 다소 보수적으로 느껴질 수 있다. ChatGPT는 대화형 AI에 가깝다. 코드 흐름을 같이 분석하고 문제 원인을 설명하고 바로 수정 가능한 방향까지 제시하는 방식이다. 그래서 기존 프로젝트 수정이나 디버깅 작업에서 활용도가 높다. 그록은 실험적인 기능이 빠르게 추가되는 편이다. 특히 이미지나 동영상 생성 기능이 주목을 받았다. 다만 일부 기능은 유료화되면서 접근 방식이 바뀌고 있다. 그래서 간단한 테스트 용도로는 괜찮지만 지속적으로 사용하려면 비용을 고려해야 한다. 결국 어떤 AI가 더 좋다고 말하기는 어렵다. 최신 정보 검색 → 퍼플렉시티 개념 설명 → 제미나이 코드 수정 / 디버깅 → ChatGPT 이미지 / 동영상 생성 → 그록 AI는 하나만 쓰기보다 상황에 맞게 선택하는 것이 가장 효율적이다. 개발자가 AI를 사용하는 이유는 단순하다. 삽질을 줄이기 위해서다. 어떤 AI를 쓰든 내 작업 스타일에 맞는 도구를 고르는 것이 가장 중요하다.

하이브리드 앱을 웹이랑 똑같이 견적 내면 안 되는 이유

 하이브리드 앱은 처음 보면 그냥 웹이랑 똑같아 보인다. URL 하나 올리면 끝나는 구조니까 쉽다고 생각하기도 한다. 나도 처음에는 그렇게 생각했다. “웹 만들었으니까 앱은 금방 나오겠지.” 이게 가장 큰 착각이었다. 실제로 개발을 시작해보면 완전히 다른 문제가 계속 나온다. 웹에서는 정상인데 앱(WebView)에서는 레이아웃이 깨진다. SafeArea 처리도 따로 해야 하고 스크롤 이벤트도 브라우저랑 다르게 동작한다. 하단 고정 버튼 하나 만드는 것도 웹에서는 간단하지만 하이브리드 앱에서는 기기별로 다 테스트해야 한다. 특히 로그인이나 결제 같은 외부 페이지를 거치면 화면이 풀스크린으로 깨지는 문제도 발생한다. 브라우저에서는 절대 안 나오던 버그가 앱에서만 나온다. 또 하나 큰 차이는 테스트다. 웹은 브라우저 하나에서 확인하면 되지만 하이브리드 앱은 안드로이드 iOS WebView 버전 기기 해상도 이걸 다 확인해야 한다. 결국 작업 시간은 웹보다 훨씬 오래 걸린다. 그런데 겉보기에는 웹이랑 비슷해 보여서 견적을 웹 기준으로 잡아버리면 개발자는 무조건 힘들어진다. 하이브리드 앱은 "웹 + 앱 대응 작업"이 추가된 구조다. 그래서 웹이랑 동일한 견적으로 보면 안 된다. 직접 개발해 보니까 느낀 건 하나다. 하이브리드 앱은 생각보다 훨씬 어렵다. 하지만 제대로 만들면 네이티브에 가까운 결과를 얻을 수 있다. 그래서 더 신중하게 견적을 잡아야 한다.