출시 전 앱 테스트하는 법: 실전 출시 전 계획
출시 전에 앱을 테스트하려면, 사용자가 반드시 완료할 수 있어야 하는 몇 가지 여정을 적고, 처음 방문한 사용자의 입장에서 노트북과 휴대폰 모두에서 각각을 실행하세요. 그다음 사용자가 잘못될 수 있는 방식을 시도해 보세요. 빈 데이터, 잘못된 입력, 두 번째 계정, 느린 연결 같은 것입니다. 돈이나 개인 정보가 걸린 부분은 특히 신경 쓰고, 게시 후에는 실제 URL에서 주요 여정을 다시 반복하세요. 마지막으로, 앱을 처음 보는 사람이 사용하는 모습을 지켜보세요.
QA 팀이나 테스트 프레임워크가 필요한 것은 아닙니다. 목록, 한두 시간, 그리고 실제로 끝까지 클릭해 보는 습관이 필요합니다.
1단계: 중요한 여정 적기
여정이란 사용자가 처음부터 끝까지 해내려고 오는 작업입니다. 대부분의 앱에는 정말 중요한 여정이 3~6개 있습니다. 예약 앱이라면 다음과 같습니다.
- 가입하고 계정 확인하기
- 수업을 찾아 예약하기
- 예약 취소하기
- 수강권 결제하기
- 직원: 오늘 예약 보기
사용자 스토리를 작성했다면, 그 인수 조건이 이미 테스트 케이스입니다. 아니라면 여정마다 한 줄씩, "성공"이 어떤 모습인지 적으세요.
순위를 매기세요. 돈을 벌어 주거나, 모든 사용자가 거치는 여정(가입, 로그인, 핵심 동작)을 가장 먼저, 가장 깊게 테스트하세요.
2단계: 신규 사용자로서 정상 경로 테스트하기
"정상 경로(happy path)"는 의도대로 여정이 진행되는 것입니다. 낯선 사람이 겪게 될 방식으로 테스트하세요.
- 비공개 브라우저 창을 사용하세요. 로그인되어 있지 않고, 저장된 데이터도 없어야 합니다.
- 새 계정을 사용하고, 확인할 수 있는 실제 이메일을 쓰세요.
- 홈 페이지나 링크에서 시작하세요. 만드는 동안 북마크해 둔 페이지에서 시작하지 마세요.
신규 사용자에게는 데이터가 없습니다. 목록이 비어 있거나, 프로필에 사진이 없거나, 아직 구매한 것이 없을 때에야 드러나는 버그가 많습니다. 테스트 데이터가 가득한 내 관리자 계정은 이런 버그를 가립니다.
3단계: 망가뜨려 보기
이제 각 여정을 다시 반복하면서 일부러 잘못된 행동을 해 보세요.
| 이렇게 해 보기 | 확인할 것 |
|---|---|
| 빈 칸으로 또는 공백만으로 양식 제출 | 필수 항목이 강제되고, 명확한 메시지가 나옴 |
| 아주 긴 텍스트, 이모지, 악센트가 있는 이름 | 레이아웃이 유지되고, 데이터가 올바르게 저장됨 |
| 잘못된 형식: 전화번호 칸에 문자, 과거 날짜 | 페이지와 서버 모두에서 검증 |
| 제출 버튼 더블 클릭 | 중복 주문이나 중복 예약이 없음 |
| 중간에 브라우저 뒤로 가기 | 깨진 상태나 데이터 손실이 없음 |
| 모든 페이지에서 새로고침 | 데이터가 유지되고, 빈 화면이나 404가 없음 |
| 로그아웃한 뒤 뒤로 가기 | 비공개 페이지가 보이지 않음 |
| 같은 항목을 두 탭에서 수정 | 나중 저장이 먼저 저장된 내용을 조용히 지우지 않음 |
새로고침은 특히 짚어 둘 가치가 있습니다. 클릭으로는 잘 작동하지만 더 깊은 페이지에서 새로고침하면 404가 뜬다면, 배포 후 404 오류 고치는 법을 참고하세요.
4단계: 계정 두 개로 권한 테스트하기
계정이 있는 모든 앱에서 가장 중요한 테스트이며, 가장 자주 건너뛰는 테스트입니다.
일반 사용자 두 명 A와 B를 만들고, (앱에 있다면) 관리자도 하나 만드세요.
- A로 로그인해서 레코드를 하나 만드세요. B로 로그인하면 그것을 보거나, 수정하거나, 삭제할 수 있나요? 설계상 그래야 하는 경우가 아니라면 할 수 없어야 합니다.
- A로 레코드 하나의 URL을 복사하세요. B로 로그인한 뒤 그 URL을 직접 여세요.
- 일반 사용자로서 URL을 직접 입력해 관리자 페이지를 여세요.
- 완전히 로그아웃한 상태에서도 같은 URL을 시도하세요.
여기서 문제가 나오면 고치기 전에는 출시하지 마세요. 확인은 버튼을 숨기는 것이 아니라 서버에서 일어나야 합니다. AI로 만든 앱을 위한 보안 체크리스트에서 더 자세히 다룹니다.
5단계: 실제 기기에서 테스트하기
좁은 브라우저 창이 아니라 실제 휴대폰에서 앱을 열어 보세요.
- 모든 버튼을 확대하지 않고 탭할 수 있나요?
- 키보드가 내가 입력하는 칸을 가리나요?
- 표와 넓은 콘텐츠가 페이지를 옆으로 밀어내지 않고 스크롤되거나 줄바꿈되나요?
- 확대하지 않고도 글씨를 읽을 수 있나요?
가능하다면 iPhone(Safari) 하나와 Android 휴대폰(Chrome) 하나에서 테스트하세요. 특히 Safari는 날짜, 동영상, 고정 위치 요소에서 고유한 문제가 있습니다.
6단계: 결제와 이메일을 처음부터 끝까지 테스트하기
카드 결제를 하거나 이메일을 보내는 기능은 전체 흐름을 모두 돌려 봐야 합니다.
결제. 결제 서비스의 테스트 모드와 테스트 카드 번호를 쓰세요. 결제 성공, 카드 거절, 결제 취소를 확인하세요. 결제 후 주문이나 구독이 결제 서비스 대시보드에만 있는 것이 아니라 내 앱에도 나타나는지 확인하세요. 앱이 웹훅(결제 서비스가 내 서버로 보내는 메시지)에 의존한다면, 개발 환경에서만이 아니라 게시된 앱에서 웹훅이 도착하는지 확인하세요. 그다음 출시 전에 실제 키로 바꾸고, 작은 금액을 실제로 결제한 뒤 환불하세요.
이메일. 서로 다른 세 제공자의 실제 주소로 가입해 보세요. 이메일이 도착하는지, 스팸함으로 가지 않는지, 그리고 이메일 속 모든 링크가 미리보기 주소가 아니라 실제 도메인을 가리키는지 확인하세요.
7단계: 속도와 오류 확인하기
- 브라우저 개발자 도구(우클릭 후 검사)를 열고 주요 페이지마다 콘솔 탭을 보세요. 겉으로 깨져 보이지 않아도 빨간 오류는 고칠 가치가 있습니다.
- Wi-Fi가 아니라 모바일 데이터로 휴대폰에서 사이트를 열어 보세요. 첫 화면이 몇 초 걸린다면 이미지 크기부터 확인하세요.
- Chrome 개발자 도구의 Lighthouse 같은 무료 감사 도구로 성능과 접근성을 빠르게 확인하세요.
8단계: 미리보기가 아니라 게시된 앱을 테스트하기
미리보기와 게시된 앱은 같은 환경이 아닙니다. 출시를 알리기 전에 실제 URL에서 주요 여정을 반복하세요.
- 게시된 앱에 모든 환경 변수와 비밀 값이 설정되어 있나요?
- 올바른 데이터베이스를 쓰고 있고, 기대한 데이터가 있나요?
- 로그인 리디렉션과 이메일 링크가 실제 도메인을 쓰나요?
- 깊은 페이지에서 새로고침해도 제대로 로드되나요?
9단계: 다른 사람이 쓰는 모습 지켜보기
한두 명에게 목표를 주세요. 예를 들어 "토요일 요가 수업 예약하기"처럼요. 지시하지 말고, 도와주지 말고, 지켜보세요. 어디서 망설이는지 적어 두세요. 헷갈리는 문구와 숨겨진 버튼을 찾는 가장 빠른 방법입니다. 더 큰 규모로 하고 싶다면 베타 테스트 진행 방법을 보세요.
버그를 발견하면 재현 단계, 기대한 결과, 실제 결과를 포함해 제대로 기록하세요. 좋은 버그 리포트 작성법에서 형식을 볼 수 있습니다.
테스트에 AI 활용하기
AI로 앱을 만들고 있다면, 테스트 계획과 실행을 AI에게 도와 달라고 할 수 있습니다.
이 앱의 주요 사용자 여정을 나열하고, 각 여정마다 가장 깨지기 쉬운 예외 상황을 적어 주세요. 빈 상태, 잘못된 입력, 권한, 새로고침을 포함하세요. 내가 따라 할 수 있는 체크리스트로 정리해 주세요.
서로 다른 두 테스트 사용자로 로그인해서, 사용자 B가 사용자 A가 만든 것을 보거나 바꿀 수 있는지 확인해 주세요. A의 레코드 URL을 직접 여는 것도 포함하세요. 무엇이든 고치기 전에 발견한 내용을 보고해 주세요.
AI의 테스트 보고서는 첫 번째 검토로 취급하세요. 돈과 권한이 걸린 여정은 여전히 직접 클릭해서 확인하세요.
Mythex에서 테스트하기
Mythex에서는 /test 명령으로 앱 테스트(App Testing)를 실행합니다. 에이전트가 브라우저로 실시간 미리보기를 조작하며 페이지를 클릭하고, 스크린샷을 찍고, 깨진 흐름을 채팅에 보고합니다. "가입과 수업 예약 테스트"처럼 구체적인 여정에서 가장 잘 작동합니다. 발견된 문제는 /fix 또는 일반 메시지로 고친 뒤 /test를 다시 실행하세요. 앱 테스트는 미리보기를 사용하므로, 게시 후에는 실제 URL의 주요 여정을 직접 확인하세요. 자세한 내용은 문서의 앱 테스트를 보고, 실패했을 때는 AI로 만든 앱 디버깅하는 법을 참고하세요.
자주 하는 실수
- 나 자신으로만 테스트하기. 데이터가 많은 관리자 계정은 빈 상태와 권한 버그를 가립니다.
- 노트북에서만 테스트하기. 많은 사이트의 방문자는 휴대폰으로 들어옵니다.
- 두 번째 계정을 건너뛰기. 사용자 간 데이터 노출은 앱이 출시될 때 가질 수 있는 가장 심각한 버그입니다.
- 미리보기를 믿기. 실제 앱은 설정이 다르므로 거기서도 테스트하세요.
- 버그를 고친 뒤 주변을 다시 테스트하지 않기. 한 양식의 수정이 같은 코드를 쓰는 다른 양식을 망가뜨릴 수 있습니다.
출시 전 체크리스트
- 주요 여정을 나열하고 순위를 매김
- 비공개 창에서 신규 사용자로서 각 여정이 통과함
- 빈 입력, 잘못된 입력, 긴 입력, 중복 입력을 처리함
- 모든 페이지에서 새로고침이 작동함
- 사용자가 URL을 통해서도 서로의 데이터를 보거나 바꿀 수 없음
- 일반 사용자와 로그아웃한 방문자는 관리자 페이지에 접근할 수 없음
- 실제 iPhone과 Android 휴대폰에서 작동함
- 결제 테스트 완료: 성공, 거절, 취소, 그리고 이후 앱 업데이트 확인
- 이메일이 도착하고, 스팸으로 분류되지 않으며, 실제 도메인으로 연결됨
- 주요 페이지 콘솔에 빨간 오류가 없음
- 게시된 URL에서 주요 여정을 반복함
- 최소 한 명의 외부인이 내가 지켜보는 가운데 사용해 봄
자주 묻는 질문
작은 앱은 출시 전에 얼마나 테스트해야 하나요?
처음 방문한 사용자가 휴대폰과 노트북에서 주요 여정을 완료할 수 있고, 사용자끼리 서로의 데이터를 볼 수 없고, 돈이 걸린 기능이 처음부터 끝까지 제대로 작동한다는 확신이 들 만큼 해야 합니다. 대부분의 작은 앱에는 몇 주가 아니라 집중적인 몇 시간이면 충분합니다.
MVP에도 자동화된 테스트가 필요한가요?
꼭 그렇지는 않습니다. 핵심 여정을 수동으로 테스트하면 출시를 막는 대부분의 버그를 잡아낼 수 있습니다. 자동화된 테스트는 앱을 자주 바꾸고, 예전에 작동하던 것을 망가뜨리지 않았는지 빠르게 알고 싶을 때부터 가치가 생깁니다.
미리보기에서 테스트해야 하나요, 아니면 실제 앱에서 테스트해야 하나요?
둘 다입니다. 미리보기에서 철저히 테스트한 다음, 게시된 앱에서 주요 여정을 다시 해 보세요. 환경 변수가 빠졌거나, 데이터베이스가 다르거나, 라우팅 설정이 다르면 실제 버전이 다르게 작동할 수 있기 때문입니다.
나 말고 누가 앱을 테스트해 줄 수 있나요?
앱을 한 번도 본 적 없는 사람이 최소 한 명은 필요합니다. 지시 대신 목표를 주고, 도와주지 않고 지켜보세요. 만든 사람은 무의식적으로 문제가 생기는 경로를 피하게 됩니다.