화면이 보인 뒤에 더 오래 걸리는 이유: PawRelay 테스트를 빡세게 보는 중

앱이 화면에 보이기 시작하면, 일은 거의 끝난 것처럼 느껴진다. 그런데 실제로는 그때부터가 더 오래 걸린다. 기능이 돌아가는 것과, 실제 사용자가 막힘 없이 끝까지 쓰는 것은 다르기 때문이다.

PawRelay도 지금 그 구간에 있다. 겉으로는 “앱이 만들어졌다”에 가까워 보여도, 제품으로 보기 위해서는 아직 확인할 게 많다. 가장 먼저 보는 것은 업데이트가 실제로 내려오는지다. 개발 화면에서 정상처럼 보이는 것과, Play Store 쪽 흐름에서 사용자가 같은 결과를 받는 것은 다를 수 있다. 배포 경로가 하나라도 어긋나면 이후 테스트는 전부 헛돌기 때문에, 이 부분은 먼저 확인 기준을 세워둔다.

그다음은 결제다. 특히 테스트 결제가 진짜 테스트 결제로 처리되는지 보는 일은 생각보다 중요하다. 겉보기에는 같은 버튼을 눌러도, 내부적으로는 전혀 다른 경로를 탈 수 있다. 테스트 단계에서 실제 결제처럼 보이거나, 반대로 테스트인데도 예외 처리로 빠지면 QA가 무너진다. 그래서 결제는 “된다/안 된다”보다 “어떤 환경에서 어떤 값으로 들어오는지”를 먼저 본다. 숫자를 잘못 믿기 시작하면 이후 기록도 흔들리기 때문이다.

재설치 흐름도 확인 중이다. 앱 삭제 후 다시 설치했을 때 상태가 어떻게 보이는지, 처음 진입이 자연스러운지, 이전에 입력한 값이 남아야 하는지 비워져야 하는지 같은 기준을 계속 점검한다. 이런 흐름은 기능 하나만 보면 잘 안 보이지만, 실제 사용자는 이 경로를 자주 지난다. 그래서 한 번만 통과하면 끝내지 않고, 지웠다가 다시 넣는 방식으로 확인하는 편이 낫다.

PawRelay는 가족이나 커플처럼 둘 이상이 함께 쓰는 상황도 염두에 두고 있다. 이때 중요한 건 “같이 쓴다”는 사실보다, 어디서 헷갈리는지다. 반려동물 돌봄 앱은 밥, 약, 증상, 리필 같은 항목이 서로 닮아 있어서, 작은 오해가 곧 불편으로 이어진다. 어떤 버튼이 무엇을 뜻하는지, 변경한 내용이 어디까지 반영되는지, 확인해야 할 화면이 너무 많지 않은지 같은 부분을 빡세게 보는 이유가 여기에 있다.

이 과정에서 판단 기준은 단순하다. 대충 되는 수준이면 넘기지 않는다. 반려동물 돌봄은 재미있는 기능보다 실수 방지가 더 중요하다. 그래서 “한 번 눌러서 되는가”보다 “다시 열어도 같은 결과가 나오는가”, “다른 사람이 봐도 의미가 같은가”, “실패했을 때 어디서 멈췄는지 알 수 있는가”를 더 신경 쓴다.

테스트를 오래 잡는 이유도 여기에 있다. 화면을 만드는 속도는 빠르게 올릴 수 있지만, 실제 제품처럼 믿을 수 있게 만드는 속도는 훨씬 느리다. 특히 공개 개발일지를 남기는 입장에서는, 그냥 잘 됐다고 적는 것보다 무엇을 확인했고 무엇을 보류했는지 남기는 편이 나중에 더 유용하다. 같은 문제를 다시 만나도, 어디서 판단이 갈렸는지 복기할 수 있어야 하기 때문이다.

지금 단계에서 남겨둔 결정은 분명하다. 첫째, 업데이트 경로는 실제 배포 환경 기준으로 본다. 둘째, 테스트 결제는 테스트 결제로만 끝까지 확인한다. 셋째, 삭제와 재설치를 포함한 반복 흐름을 넣는다. 넷째, 가족/커플 사용 시 혼선 지점을 별도로 본다.

다음 확인 기준도 정해져 있다. 업데이트가 기대한 대로 내려오는지, 결제 결과가 환경별로 일관적인지, 재설치 뒤 초기 흐름이 무너지지 않는지, 그리고 공유 맥락에서 의미가 헷갈리는 화면이 없는지다. 이 기준을 통과해야만 “작동한다”가 아니라 “테스트 가능한 제품이다”라고 말할 수 있다.

결국 이번 작업은 기능을 더 많이 넣는 일이 아니라, 믿을 수 있는 상태로 좁혀 가는 일에 가깝다. PawRelay는 아직 그 과정에 있고, 그래서 지금은 속도보다 확인을 택하고 있다.

---

🐦 X에서 더 빠르게: @baegseungh7061
📚 이 시리즈 더 보기: Code 빌드
💌 새 글 알림: X 팔로우 또는 블로그 RSS 구독