Google은 앱을 14일간 테스트할 낯선 사람 12명을 직접 찾게 했습니다 — 아무도 그 일이 얼마나 어려운지 알려주지 않았습니다

AI 요약

첫 Android 앱을 완성하는 일보다 Google Play에 실제로 출시하는 일이 더 어려울 수 있습니다. 글쓴이는 앱 개발을 끝낸 뒤에야 신규 개인 개발자 계정에 적용되는 출시 조건을 알게 됐습니다. 2023년 11월부터 Google은 신규 개인 개발자 계정이 어떤 앱이든 production access를 요청하기 전에 closed test를 진행하도록 요구하고 있습니다. 이 테스트에는 최소 12명의 테스터가 참여해야 하며, 모든 테스터가 opt-in 상태로 앱을 설치하고 활동한 기록이 14일 연속 유지되어야 합니다. 하루라도 활성 테스터 수가 부족하면 기간이 다시 시작됩니다. 글쓴이는 이것이 단순히 확인란을 체크하는 절차가 아니며, 자동으로 집행되고 신규 계정이 우회할 방법도 없다고 설명합니다.

■ 출시를 막는 것은 앱 개발보다 테스터 모집입니다

문제는 앱을 완성한 뒤 생겼습니다. 글쓴이에게는 앱을 기다리는 사용자층도, mailing list도, 도움을 요청할 수 있는 Discord 커뮤니티도 없었습니다. 남은 것은 앱과, 12명의 실제 사용자가 앱을 설치하고 2주 동안 계속 유지해야 한다고 알려주는 Google Play Console 화면뿐이었습니다. 친구와 가족에게 부탁하는 방법은 처음에는 가능하지만, 결국 요청할 사람 수가 바닥납니다. 또한 대부분의 사람은 특별한 보상 없이 호의를 베푸는 일이므로 3일쯤 지나면 연락을 끊거나 테스트를 중단한다고 합니다.

테스터에게 돈을 지급하는 방법도 해결책이 되지 않습니다. 글쓴이는 유료 테스터 모집이 Google 자체 정책에 어긋나며, Google이 처음부터 걸러내려는 가짜 참여와 같은 유형으로 감지될 수 있다고 설명합니다. 개발자 포럼에 “앱을 테스트해 달라”고 무작정 글을 올리는 방법도 효과가 낮습니다. 그런 글을 읽는 사람 대부분이 잠재적인 테스터가 아니라, 똑같이 12명의 테스터를 구해야 하는 다른 개발자이기 때문입니다.

■ 같은 문제를 가진 개발자끼리 테스트를 교환합니다

글쓴이가 얻은 핵심 아이디어는 이 구조를 경쟁이 아니라 상호성으로 바꾸는 것입니다. 테스터 모집 글을 볼 가능성이 있는 사람이 대부분 개발자라면, 그들은 타인의 앱을 도와줄 여유가 없는 사람이 아니라 자신도 같은 문제를 해결해야 하는 사람입니다. 따라서 한 개발자가 다른 개발자의 앱을 실제로 테스트하고, 상대방도 자신의 앱을 테스트하면 비용을 지불하거나 낯선 사람의 선의만 기다리지 않아도 됩니다.

이 아이디어를 구현하기 위해 글쓴이는 PeerPlay를 만들었습니다. PeerPlay의 목적은 여러 개발자와의 교환을 spreadsheet로 직접 추적하지 않고, 테스트 교환을 자동으로 연결하는 것입니다. 핵심은 handshake 시스템입니다. 상대방이 자신의 앱을 테스트하기로 동의하는 순간, 해당 사용자를 상대방 앱의 테스터로 등록하는 방식입니다. 여기에 verification layer도 추가했습니다. 이 계층은 대상 앱을 실제로 열고, 진짜 최소 세션을 유지하도록 요구합니다. Google의 fraud detection이 앱을 열자마자 닫는 패턴을 잘 감지하기 때문에, 단순히 설치만 해서는 교환이 성립하지 않도록 하려는 장치입니다. 양쪽 모두 실제로 테스트해야 하며, 설치 기록만 남기는 방식은 의도한 해결책이 아닙니다.

■ 설치 수와 실제 사용 사이의 간극

댓글에서는 Google의 검증 지표가 실제 앱 품질이나 사용성을 충분히 반영하지 못할 수 있다는 문제가 제기됩니다. 한 댓글은 “19명 중 4명만 실제로 남았는데도 통과했다”는 사례를 언급합니다. Google은 설치가 이어지는 streak를 확인하지만, 개발자가 알고 싶은 것은 사람들이 앱을 실제로 사용했는지입니다. 즉, 플랫폼이 저렴하게 검증할 수 있는 지표와 개발자가 확인하려는 사용자 참여가 서로 다른 방향을 가리킬 수 있습니다.

PeerPlay에 포함된 quit counter도 이 문제를 완전히 해결하지는 못합니다. 이 카운터는 테스트를 중단한 사람의 이력을 다음 교환 참여자가 볼 수 있게 하지만, 현재 테스트 중인 사람이 중간에 이탈하는 것을 즉시 막지는 못합니다. 댓글의 설명에 따르면 이는 예방 장치라기보다 평판 정보에 가깝습니다. 상대방이 자신의 테스트 기간을 마치면 참여 동기가 사라질 수 있고, 상대방의 14일과 자신의 14일이 서로 맞물리지 않을 수도 있습니다. 이를 막으려면 한쪽의 완료 일부를 상대방 테스트가 끝날 때까지 보류하거나, 두 테스트의 기간이 겹치도록 교환을 단계적으로 진행하는 구조가 필요하지만, 글쓴이는 아직 그런 기능을 만들지는 않았다고 밝힙니다.

글쓴이는 quit counter가 실제로 이탈을 줄였다고 단정하지도 않습니다. 도입 전후를 비교할 수 있는 깨끗한 데이터가 없기 때문에, 카운터가 행동을 바꿨다고 주장하는 것은 추측에 불과하다고 설명합니다. 현재 방어할 수 있는 주장은 카운터가 테스트 도중 이탈하는 사람을 막는다기보다, 어떤 사람과 교환할지 결정할 때 참여자를 걸러내는 데 도움이 된다는 정도입니다. 결국 PeerPlay는 작지만 실제 Android 개발자의 출시를 가로막는 문제에서 출발했으며, 자동화된 검증과 상호 교환이라는 방식으로 그 문제를 다루려 합니다. 동시에 플랫폼이 요구하는 설치 streak와 개발자가 필요로 하는 실제 사용 세션 사이에는 여전히 해결되지 않은 차이가 남아 있습니다.

■ Indie Hackers 반응

• @MananShah — “19명 중 4명만 실제로 남았는데도 통과했다”는 문장이 이 글의 전부라고 느낍니다. Google의 검사는 관심이 아니라 설치를 세므로, 개발자는 기준을 통과해도 앱이 작동하는지 알지 못할 수 있습니다. 측정하기 가장 쉬운 지표가 의미 있는 지표인 경우는 드물다는, 아주 흔한 형태입니다. aryan_sinh와 이어진 대화를 보면서 묻고 싶습니다. 종료 카운터가 스스로 행동을 바꾼 것입니까, 아니면 사후에 잠수를 보이게 만든 것에 가깝습니까? 눈에 보이지만 처벌되지 않는 문제와 실제로 막는 문제에는 서로 다른 수정이 필요해 보입니다.

• @Viktor Molnar — 대부분 사후에 보이게 만든 것입니다. 두 문제에 서로 다른 수정이 필요하다는 지적이 맞습니다. 카운터는 앞으로 작동하지, 뒤로 작동하지는 않습니다. 오늘 잠수하는 사람을 막지는 못하고, 다음 사람이 그 사람과 교환할지 결정하는 데 도움을 줄 뿐입니다. 유용하지만 예방이 아니라 평판입니다. 예방하려면 12일 차에도 참여 동기가 남아 있어야 하는데, 지금은 그렇지 않습니다. 그 사람은 이미 자신이 원한 것을 얻었기 때문입니다. 수치심만으로는 그 간극을 메울 수 없습니다. 구조적인 장치가 필요합니다. 예를 들어 상대방의 테스트가 끝날 때까지 완료의 일부를 보류하거나, 두 테스트 기간이 겹치도록 교환을 엇갈리게 진행하는 방식입니다. 아직 어느 쪽도 만들지는 않았습니다. 지표에 관한 지적도 맞습니다. 측정되는 것에 맞춰 모두가 최적화하고, 저 역시 streak를 더 쉽게 달성하게 만드는 것을 만들었습니다.

• @praneetbrar — 19명 중 실제로 남아 있던 사람이 4명뿐인데도 통과했다는 점이 계속 기억에 남습니다. Google은 설치 streak를 확인하고, 개발자는 실제 세션을 추적하려 하므로 두 목표가 충돌합니다. 3일쯤 지나 친구들이 잠수하는 일도 더 작은 규모에서 같은 문제입니다. 종료 카운터가 보통의 죄책감을 유도하는 이메일 대신 기록으로 남는다는 점은 더 나아 보입니다. 그 카운터 때문에 실제로 9일 이후까지 남은 사람이 있습니까? 아니면 교환이 공평해 보이는 순간 사라집니까?

• @Viktor Molnar — 솔직히 말하면, 그 행동 변화가 카운터 때문이라고 입증할 수 없습니다. 전후를 깔끔하게 비교할 수 있는 자료가 없으므로, 카운터가 작동한다고 주장하는 것은 추측입니다. 하지만 “교환이 공평해 보이는 순간”이 핵심입니다. 사람들은 무작위로 사라지는 것이 아니라 자신의 캠페인이 완료되는 시점에 사라집니다. 그 사람의 14일 차와 여러분의 14일 차가 다르고, 두 시계가 맞물리지 않습니다. 제 추측으로는 카운터가 끝까지 남는 사람보다 참여할 사람을 걸러내는 데 더 효과적입니다. 주장은 약하지만, 제가 방어할 수 있는 주장은 그것입니다.

• @veris_social — 제가 만들고 있는 아이디어에 대한 관심을 확인하려고 waitlist를 운영하고 있습니다. 그냥 beta를 열고 사람들이 테스트하게 하는 편이 좋습니까?

원문: Indie Hackers / 번역·요약: Trawling