데모는 아이디어가 특정한 경로에서 작동할 수 있다는 것을 보여 줍니다. 제품을 설명하고, 흐름이 말이 되는지 확인하는 데 도움이 됩니다. 하지만 고객이 의지하기 전에, 사용자가 다를 때, 실제 데이터가 들어올 때, 중간에 끊길 때 어떻게 되는지도 이해해야 합니다.
프로토타입이 템플릿에서 나왔든, AI 도구로 만들었든, 내부 팀이나 이전 개발자가 만들었든 마찬가지입니다. 저는 이미 쓸모 있는 부분을 평가하고, 빠진 부분을 찾아내고, 이 제품에 중요한 위험을 중심으로 작업을 계획합니다.
실제와 시뮬레이션을 구분해 적기
프로토타입은 예시 기록을 보여 주거나, 결제를 흉내 내거나, 모든 요청이 성공한다고 가정할 수 있습니다. 이런 가정을 목록으로 적어 주세요. 예약 완료 화면이 있어도 예약 가능 규칙, 결제 연결, 믿을 수 있는 예약 기록은 아직 필요할 수 있습니다.
데모에서 쓸모 있는 부분은 살리세요. 검토에서는 무엇을 유지하고, 무엇을 바꿔야 하며, 무엇이 아직 검증되지 않았는지 설명해야 합니다. 화면만 봐서는 어느 것이 어디에 해당하는지 알 수 없습니다.
사람마다 무엇을 할 수 있는지 확인하기
제품의 역할과 각 역할이 볼 수 있거나 바꿀 수 있는 것을 적어 주세요. 화면에서 관리자 버튼을 숨기는 것은 일부일 뿐입니다. 보호해야 할 작업과 데이터는 서버에서도 막아야 합니다.
예를 들어 고객 포털이라면, 한 고객이 다른 고객의 기록을 가져올 수 없는지, 직원의 접근 권한을 해제하면 의도한 대로 적용되는지 테스트하세요.OWASP Application Security Verification Standard는 애플리케이션 보안 검증을 체계적으로 진행하기 위한 참고 자료입니다. 제품에 적용할 점검 항목은 그 제품의 데이터와 위험에 맞춰 골라야 합니다.
실패와 반복 동작을 따라가 보기
고객은 연결이 끊기거나, 페이지를 새로 고치거나, 두 번 제출하거나, 외부 연동이 시간 초과된 뒤 돌아올 수 있습니다. 특히 돈, 재고, 중요한 기록이 걸린 경우에는 이런 상황에서 어떤 결과가 나와야 하는지 합의해 두어야 합니다.
결제가 대기 중이거나 실패하면 어떻게 되어야 하나요?
중복을 만들지 않고 안전하게 요청을 다시 시도할 수 있나요?
업로드나 알림이 실패하면 사용자에게 무엇이 보이나요?
직원은 완료되지 않은 작업을 어떻게 찾아서 해결하나요?
예약 예시에서는 버튼을 여러 번 눌러도 한 번의 구매에 예약이 여러 건 생기면 안 됩니다. 알맞은 구현 방식은 결제 업체와 예약 규칙에 따라 달라지며, 이 동작은 작업 범위와 테스트에 포함해야 합니다.
실제와 비슷한 데이터와 흐름 사용하기
긴 이름, 빈 목록, 긴 이력, 비어 있는 입력 항목, 사람들이 실제로 쓸 기기로 테스트하세요. 예시 데이터가 다섯 줄뿐인 대시보드로는 수천 건 중에서 기록을 찾는 모습을 알 수 없습니다. 보호되지 않은 미리보기에 고객 개인정보를 복사하지 말고, 알맞은 테스트 데이터를 사용하세요.
기존 기록을 제품으로 옮겨야 한다면 항목 매핑, 시험 가져오기, 확인 절차를 계획하세요. 중복되거나 불완전한 기록을 어떻게 처리할지, 이전 작업 중에 생긴 변경은 어떻게 할지도 정해야 합니다.
릴리스와 복구 계획을 분명히 하기
호스팅과 서비스 계정의 소유자가 누구인지, 어떤 설정이 필요한지, 릴리스가 올바른 환경에 어떻게 반영되는지 알고 있어야 합니다. 변경 사항을 운영 환경에 반영하기 전에 확인 항목과, 문제가 생겼을 때 되돌리는 방법을 합의하세요.
복구는 이전 버전의 코드로 되돌리는 것 이상일 수 있습니다. 저장된 데이터의 변경에는 별도의 방법이 필요합니다. 팀은 어떤 백업이 있는지, 어떻게 복원하는지, 복원 후 제품이 작동하는지를 어떤 점검으로 확인하는지 알고 있어야 합니다.
배우기 위해 출시하되, 서비스 책임자 정하기
적절한 그룹에 한정해 공개하면 더 많은 사람에게 열기 전에 문제를 발견할 수 있습니다. 피드백과 오류를 어떻게 모을지, 누가 대응할지, 어떤 상황이면 출시를 멈추거나 되돌릴지 정하세요.GOV.UK의 베타 단계 가이드에서는 서비스를 더 넓게 열기 전에 제한된 공개로 배우고 개선하는 방법을 설명합니다.
핵심 흐름을 확인한 사람: …
권한과 주요 실패 사례를 확인한 사람: …
남아 있는 제약 사항: …
릴리스와 복구 절차를 기록해 둔 곳: …
피드백과 장애를 담당하는 사람: …
공개 범위를 넓힐 조건: …
이는 계획을 위한 질문일 뿐, 보안 인증이 아닙니다. 검증을 얼마나 할지는 제품의 성격과 실패했을 때의 결과에 맞춰야 합니다. 프로토타입이 있다면이미 작동하는 것과 출시하고 싶은 것을 알려 주세요. 다음 단계를 함께 검토하겠습니다.