출시를 2주 앞두고 처음으로 앱의 전체 흐름을 확인하는 날이 있습니다. 회원가입을 하고, 상품을 고르고, 결제를 끝낸 다음 관리자 화면에서 주문을 처리해 봅니다. 기능은 대부분 작동합니다. 그런데 그때 이런 말이 나옵니다.

“우리가 원한 흐름은 이게 아닌데요.”

버튼 색이나 문구처럼 금방 바꿀 수 있는 문제라면 다행입니다. 회원가입에 필요한 정보가 달라졌거나, 결제 취소 뒤 재고와 알림이 어떻게 움직여야 하는지 정해지지 않았거나, 관리자가 어떤 주문을 먼저 봐야 하는지가 빠져 있다면 이야기가 달라집니다. 코드를 조금 고치는 문제가 아니라 이미 만든 구조와 일정, 운영 방법을 다시 결정해야 하기 때문입니다.

검수가 늦었다는 말은 오류를 늦게 발견했다는 뜻만은 아닙니다. 더 정확히는 결정해야 할 질문을 너무 늦게 만났다는 뜻입니다.

검수는 마지막 시험이 아니다

검수를 개발이 끝난 뒤 하는 최종 시험으로 생각하면 자연스럽게 마지막 주에 일이 몰립니다. 모든 화면이 나와야 확인할 수 있다고 보기 때문입니다. 하지만 앱을 만들며 확인해야 하는 것은 단계마다 다릅니다.

기획 단계에서는 사용자가 무엇을 완료해야 하는지 봅니다. 디자인 단계에서는 정상 화면뿐 아니라 데이터가 없을 때, 입력을 잘못했을 때, 권한을 거절했을 때의 상태를 확인합니다. 개발 중에는 실제 기기에서 핵심 행동이 끝까지 이어지는지 봅니다. 출시 전에는 마켓 계정, 개인정보 안내, 서버 알림, 복구 담당처럼 앱 화면 밖의 준비를 점검합니다.

이 네 가지를 마지막에 한꺼번에 보면 서로 다른 문제가 모두 ‘수정 요청’이라는 이름으로 섞입니다. 오류인지, 빠진 요구사항인지, 새로 생긴 아이디어인지 구분되지 않습니다. 개발자는 어디까지 고쳐야 완료인지 알기 어렵고, 서비스 담당자는 왜 일정이 다시 늘어나는지 이해하기 어렵습니다.

그래서 검수의 첫 번째 목적은 오류 개수를 세는 일이 아닙니다. 지금 단계에서 합의해야 할 것을 다음 단계로 넘기지 않는 것입니다.

네 번으로 나누면 질문이 달라진다

1. 기획과 프로토타입: 무엇이 되면 완료인가

화면 수보다 먼저 핵심 사용 흐름을 확인합니다. 사용자는 어디에서 시작하고, 무엇을 입력하고, 어떤 결과를 보면 행동이 끝났다고 느끼는지 정합니다.

예를 들어 예약 앱이라면 ‘예약 버튼이 있다’만으로는 부족합니다. 예약 가능한 시간은 누가 정하는지, 이미 찬 시간은 어떻게 보이는지, 결제에 실패하면 예약이 남는지, 취소 가능 시간은 언제까지인지가 함께 있어야 검수할 수 있습니다.

이 단계의 산출물은 예쁜 화면이 아니라 한 문장으로 판정할 수 있는 완료 기준입니다.

2. 디자인: 정상 화면 밖의 상태가 있는가

실제 서비스에서는 첫 화면부터 데이터가 가득 차 있지 않습니다. 로딩 중일 수도 있고, 검색 결과가 없을 수도 있고, 네트워크가 끊기거나 접근 권한이 없을 수도 있습니다.

정상 화면만 보고 개발을 시작하면 이런 상태는 구현 중 개발자의 추측으로 채워집니다. 이후 담당자가 처음 의도한 방식과 다르다는 사실을 발견하면 디자인과 개발을 함께 되돌려야 합니다.

최소한 빈 상태, 로딩, 오류, 권한 거절, 성공 후 다음 행동은 디자인 단계에서 먼저 확인하는 편이 좋습니다.

3. 개발 중간: 핵심 행동이 실제 환경에서 이어지는가

모든 기능이 끝날 때까지 기다리지 않고 가장 중요한 흐름부터 실제 기기에서 확인합니다. 로그인, 결제, 예약, 알림처럼 여러 시스템이 연결되는 기능은 화면만 완성됐다고 끝나지 않습니다.

이때 “안 됩니다”라고만 남기면 수정이 느려집니다. 확인한 기기와 운영체제, 사용한 계정, 실행 순서, 기대한 결과와 실제 결과, 화면 캡처를 함께 기록해야 다른 사람도 같은 문제를 재현할 수 있습니다.

그리고 반드시 나눠야 합니다.

• 약속한 동작과 다른 오류
• 처음부터 요구사항에 빠져 있던 결정
• 확인하다 새로 떠오른 기능

세 가지를 한 목록에서 같은 우선순위로 다루면 출시는 계속 밀립니다. 오류는 합의한 기준에 맞춰 고치고, 새 기능은 출시를 막는 이유가 분명할 때만 이번 범위에 넣어야 합니다.

4. 출시 전: 화면 밖에서도 운영할 수 있는가

앱이 잘 작동해도 출시 준비가 끝난 것은 아닙니다. 앱스토어와 플레이스토어 계정은 회사가 가지고 있는지, 심사에 필요한 설명과 이미지가 준비됐는지, 개인정보 처리 내용이 실제 기능과 맞는지, 장애 알림을 누가 받는지 확인해야 합니다.

결제나 회원 데이터처럼 중요한 기능은 문제가 생겼을 때 되돌릴 방법과 담당자도 정해 둡니다. 소스코드와 서버, 도메인, 외부 서비스 계정의 소유권도 출시 전에 확인해야 합니다. 이 항목은 화면을 다시 눌러 보는 방식만으로는 발견할 수 없습니다.

작은 팀일수록 기록 방식은 단순해야 한다

검수 도구가 복잡하면 사람들은 메신저로 돌아갑니다. 작은 팀에서는 문서 여러 개보다 하나의 공용 목록이 낫습니다. 대신 한 항목에 최소한 다음 정보는 남겨야 합니다.

• 어느 화면과 기능인지
• 어떤 조건과 순서로 확인했는지
• 기대한 결과와 실제 결과가 무엇인지
• 중요도와 출시 차단 여부
• 누가 언제까지 수정하고 누가 다시 확인할지
• 수정 완료를 무엇으로 증명할지

여기서 중요도와 처리 순서는 다릅니다. 작은 문구 오류가 매우 눈에 띌 수는 있지만 결제를 멈추지는 않을 수 있습니다. 반대로 자주 보이지 않는 권한 오류가 특정 사용자에게는 서비스를 전혀 이용할 수 없게 만들 수 있습니다. ‘얼마나 불편해 보이는가’와 ‘출시를 막아야 하는가’를 따로 판단해야 합니다.

또 하나, 검수 담당자만 있고 결정 담당자가 없으면 목록은 쌓이기만 합니다. 오류인지 새 기능인지 의견이 갈릴 때 범위와 일정을 결정할 사람이 필요합니다. 작은 팀에서는 대표나 서비스 책임자가 이 역할을 맡되, 모든 항목을 직접 시험하기보다 판단이 필요한 항목만 빠르게 확인하는 방식이 현실적입니다.

좋은 검수는 애매함을 결정으로 바꾸는 속도다

검수 항목이 많다고 출시 품질이 자동으로 좋아지지는 않습니다. 무엇을 확인해야 하는지, 어떤 상태를 완료로 볼지, 문제가 생기면 누가 결정할지가 분명해야 합니다.

출시 직전의 검수는 여전히 필요합니다. 다만 그때 처음 질문을 발견해서는 안 됩니다. 기획에서는 완료 기준을, 디자인에서는 예외 상태를, 개발 중에는 실제 동작을, 출시 전에는 운영 가능성을 확인해야 합니다. 이렇게 나누면 마지막 검수는 새로운 요구사항을 발굴하는 회의가 아니라 이미 합의한 기준을 확인하는 절차가 됩니다.

앱 검수를 처음 맡아 어떤 항목부터 기록해야 할지 막막하다면, 데브크래프트가 기대 결과·실제 결과·수정 담당·재검수·최종 승인을 한 줄로 관리할 수 있게 만든 앱 개발 검수 체크리스트 엑셀 양식을 이메일로 받아볼 수 있습니다. 장기 뉴스레터에 자동 등록하는 방식은 아닙니다.

앱 개발 검수 체크리스트 엑셀 양식 보기