스토어에 올린 것만으로는 아무도 오지 않습니다: 앱 ASO 체크리스트

스토어 검색은 어떻게 작동하는가

스토어 검색은 웹 검색과 구조가 다릅니다. 읽히는 글자가 스토어가 정한 몇 개 필드로 제한되고, 순위에는 검색어와의 글자 일치도에 더해 그 검색어로 들어온 사람이 실제로 설치하고 남았는지가 함께 반영됩니다. App Store와 Google Play는 이 두 축의 범위를 서로 다르게 잡습니다.

두 축을 나눠서 보는 편이 이해가 빠릅니다. 하나는 관련성입니다. 사용자가 친 말과 등록정보에 들어간 말이 얼마나 겹치는지의 문제입니다. 다른 하나는 성과입니다. 검색 결과에 노출된 뒤 사람들이 상세 페이지를 열었는지, 열고 나서 설치했는지, 설치하고 나서 지웠는지의 문제입니다. 관련성만 손보면 노출은 늘어도 설치가 안 붙고, 성과만 신경 쓰면 애초에 검색 결과에 나타나지 않습니다.

App Store에서 검색에 읽히는 자리는 좁습니다. 앱 이름, 부제, 그리고 사용자에게 보이지 않는 키워드 필드가 중심입니다. 개발자명과 인앱 구매 항목명도 영향을 준다고 알려져 있습니다. 반면 상세 페이지의 설명문은 검색 색인에 쓰이지 않는다는 것이 업계에서 오래 통용된 이해입니다. 애플이 색인 규칙 전체를 공개하지 않기 때문에 이 부분을 확정된 사실로 쓰지는 않겠습니다. 다만 애플이 굳이 비공개 키워드 필드를 따로 둔 구조 자체가 힌트입니다. 최신 기준은 App Store Connect의 도움말 문서에서 직접 확인하시기 바랍니다.

Google Play는 별도의 키워드 필드가 없습니다. 대신 앱 제목, 짧은 설명, 전체 설명이 모두 검색에 읽힙니다. 그래서 같은 내용을 쓰더라도 글의 성격이 달라집니다. App Store 쪽 작업은 제한된 글자 수 안에 서로 다른 단어를 배치하는 목록 작업에 가깝고, Google Play 쪽 작업은 사람이 읽어도 자연스러운 문장을 쓰면서 그 안에 실제 검색어가 들어가게 하는 글쓰기 작업에 가깝습니다. 두 스토어에 같은 문장을 복사해 넣으면 양쪽 모두에서 손해를 봅니다.

성과 축에서 자주 발생하는 착시가 하나 있습니다. 브랜드 검색과 일반 검색을 섞어서 보는 경우입니다. 앱 이름을 정확히 아는 사람이 이름으로 검색해 들어오면 전환율이 당연히 높습니다. 이 숫자가 전체 평균에 섞이면 일반 검색어에서의 성과가 실제보다 좋아 보입니다. 두 종류를 분리해서 봐야 등록정보 개선이 효과가 있었는지 판단할 수 있습니다.

확인 경로는 스토어마다 다릅니다. Google Play Console은 사용자가 어떤 검색어로 들어왔는지 보여주는 리포트를 제공합니다. 여기부터 여는 것이 순서입니다. App Store Connect는 검색어별 유입 데이터를 같은 방식으로 주지 않습니다. 대신 Apple Search Ads의 키워드 도구에서 검색어의 대략적인 인기도를 볼 수 있고, 실제 기기에서 직접 검색해 자기 앱이 몇 번째에 나오는지 확인하는 수동 점검이 여전히 유효합니다. 이때 스토어프론트 국가와 기기 언어를 실제 목표 시장에 맞춰야 합니다. 한국 계정으로 켠 App Store에서 본 순위는 베트남 사용자가 보는 화면과 다릅니다.

작업 순서를 정할 때는 자기 앱의 실제 설치가 어느 플랫폼에서 나오는지부터 봅니다. 시장 전체의 점유율 통계보다 자기 앱의 분포가 우선입니다. iOS와 Android의 비율이 크게 기울어 있으면 그쪽 스토어의 규칙을 먼저 파고드는 편이 합리적입니다.

이름, 부제, 키워드 필드: 무엇을 어디에 넣는가

글자를 넣을 자리가 스토어마다 다릅니다. App Store는 앱 이름과 부제, 그리고 사용자에게 보이지 않는 키워드 필드로 나뉘고, Google Play는 제목과 짧은 설명, 전체 설명이 전부 검색에 읽힙니다. 자리마다 역할이 다르므로 같은 단어를 모든 칸에 반복해 넣는 방식은 자리 낭비입니다.

글자 수 제한은 스토어가 조정합니다. 오래 통용된 기준은 App Store의 앱 이름 30자, 부제 30자, 키워드 필드 100자, Google Play의 제목 30자, 짧은 설명 80자, 전체 설명 4,000자입니다. 다만 이 숫자를 기억에 의존해 쓰지 마시고 App Store Connect와 Play Console의 실제 입력창에 붙은 카운터로 확인하시기 바랍니다. 입력창이 언제나 최신 기준입니다.

앱 이름은 브랜드와 카테고리 단어를 함께 담는 자리입니다. 브랜드만 넣으면 이름을 이미 아는 사람에게만 검색됩니다. 반대로 카테고리 단어를 길게 붙이면 이름이 잘려서 검색 결과 목록에서 읽히지 않습니다. 기준은 사람들이 실제로 치는 말입니다. 출결 관리 앱이라면 사내에서 쓰는 정식 명칭이 아니라 관리자가 검색창에 칠 법한 말이어야 합니다. 구인구직 앱이라면 업계 용어가 아니라 구직자가 치는 말입니다.

부제는 이름에 넣지 못한 말을 담는 자리입니다. 이름에 이미 쓴 단어를 반복하는 것은 낭비입니다. 기능을 나열하기보다 누가 무엇을 하는 앱인지 한 줄로 읽히게 쓰는 편이 전환에도 유리합니다. 부제는 검색에도 읽히고 사람 눈에도 보이는 이중 역할이라 이 균형을 잡는 데 시간을 쓸 만합니다.

키워드 필드는 규칙이 명확한 편입니다. 쉼표로만 구분하고 공백은 넣지 않습니다. 공백도 글자 수를 차지하기 때문입니다. 앱 이름과 부제에 이미 넣은 단어는 다시 쓰지 않습니다. 애플이 필드에 있는 단어들을 조합해 구문을 만들어 내므로 구문 전체를 통째로 넣을 필요도 없습니다. 단수와 복수를 나란히 넣는 것도 대개 불필요합니다. 경쟁사 브랜드명을 넣는 방식은 상표 문제로 이어질 수 있어 권하지 않습니다.

Google Play의 전체 설명은 사람이 읽는 글이어야 합니다. 같은 단어를 억지로 반복해 넣는 방식은 정책 위반으로 다뤄지고 순위에도 도움이 되지 않습니다. 첫 두세 문장은 짧은 설명과 함께 접힌 상태에서 노출되므로 여기에 가장 중요한 말이 와야 합니다. 나머지는 기능과 사용 상황을 문장으로 풀되, 사용자가 실제로 쓰는 표현을 자연스럽게 포함시키는 정도가 적정선입니다.

로케일은 별도의 작업 단위입니다. 스토어프론트마다 필드가 따로 있고, 한 로케일을 비워 두면 그 시장에서 색인될 글자가 그만큼 줄어듭니다. 여우비 인터랙션이 운영하는 제품만 봐도 상황이 다릅니다. 랭토리는 한국어와 베트남어와 영어 로케일을 지원하고 주력이 베트남어이므로 베트남어 등록정보가 본진입니다. Job Connect VN은 베트남 시장에 한정된 서비스라 로케일 판단이 단순합니다. onSpots는 다국어를 지원하고 특정 국가에 매이지 않으므로 시장마다 사람들이 쓰는 말이 달라집니다. 영어 등록정보 하나로 모든 로케일을 덮으면 현지 사용자가 실제로 치는 단어가 색인에서 빠집니다.

마지막으로 한 가지를 덧붙이겠습니다. 이 절에 쓴 글자 수와 필드 구성은 스토어의 정책 변경에 따라 바뀝니다. 등록정보를 크게 손보기 전에 App Store Connect와 Play Console의 현재 화면과 공식 도움말을 한 번 확인하고 시작하시는 편이 안전합니다.

스크린샷 첫 세 장이 설치를 가른다

검색 결과 화면에서 사람이 보는 것은 아이콘과 이름, 그리고 스크린샷 앞쪽 몇 장입니다. 상세 페이지에 들어와도 스크롤 전에 보이는 범위는 첫 세 장 근처에서 끝납니다. 여기서 무슨 앱인지 잡히지 않으면 나머지 장은 열리지 않습니다.

App Store 검색 결과에서는 세로 스크린샷 세 장 또는 가로 스크린샷 한 장이 노출되는 형태가 오래 유지돼 왔습니다. 세로로 올렸다면 1번부터 3번까지가 사실상 검색 결과용 자산입니다. Google Play는 검색 결과에서 아이콘과 제목 중심으로 보여 주고 스크린샷은 상세 페이지에서 비중이 커지는 편입니다. 다만 이 노출 형태는 스토어가 실험적으로 자주 바꿉니다. 문서에 적힌 설명보다 실제 기기에서 지금 어떻게 보이는지가 정확합니다.

첫 장에는 가장 큰 이득 한 줄이 와야 합니다. 기능 이름이 아니라 사용자가 얻는 결과입니다. 출결 관리라면 기록 방식이 아니라 관리자가 매달 무엇을 덜 하게 되는지가 먼저입니다. 둘째 장에는 그 말이 실제로 구현된 핵심 화면 하나를 놓습니다. 셋째 장에는 설치를 망설이게 하는 요소를 미리 해소하는 내용이 유효합니다. 설정에 얼마나 걸리는지, 인터넷 없이도 되는지, 혼자 쓰는 앱인지 팀이 함께 쓰는 앱인지 같은 것들입니다.

스크린샷 위 카피는 짧아야 합니다. 검색 결과의 축소된 크기에서 읽혀야 하므로 다섯 단어에서 일곱 단어 정도가 상한입니다. 작은 글씨로 설명을 채우면 축소 상태에서 회색 얼룩으로 보입니다. 화면은 실제 앱 화면이어야 합니다. 없는 기능을 그려 넣으면 심사에서 지적받을 수 있고, 통과하더라도 설치 직후 리뷰에서 그대로 반박당합니다.

로케일별 스크린샷은 따로 준비해야 합니다. 베트남 스토어프론트에 영어 UI 캡처가 걸려 있으면, 앱은 베트남어를 지원하는데도 사용자는 지원하지 않는다고 판단합니다. 화면 안의 숫자 형식, 날짜 형식, 통화 표기도 현지 기준으로 맞추면 신뢰가 달라집니다. 번역만 얹은 캡처와 그 로케일에서 실제로 찍은 캡처는 눈에 띄게 다릅니다.

앱 미리보기 영상을 붙일 계획이라면 스토어별 재생 방식을 먼저 확인하시기 바랍니다. iOS의 앱 미리보기는 소리 없이 자동 재생되는 경우가 많아 첫 3초가 무음 상태에서 이해되어야 합니다. Google Play의 프로모션 영상은 붙는 위치와 재생 방식이 다릅니다. 영상이 준비되지 않았다면 만들지 않아도 됩니다. 완성도가 낮은 영상은 없느니만 못합니다.

점검 방법은 단순합니다. 실제 기기를 들고 목표 시장의 스토어프론트에서 자기 앱을 여러 검색어로 찾아 보십시오. 시뮬레이터나 웹 미리보기가 아니라 손에 든 기기에서 봐야 합니다. 그리고 같은 검색 결과에 함께 뜨는 다른 앱들과 나란히 놓고 보십시오. 자기 앱만 확대해서 볼 때는 괜찮아 보이던 스크린샷이 경쟁 목록 안에서는 구분되지 않는 경우가 흔합니다.

리뷰와 평점을 정직하게 다루는 방법

선부터 긋겠습니다. 리뷰를 구매하거나, 별점을 조건으로 보상을 주거나, 낮은 점수를 줄 것 같은 사용자를 미리 걸러 스토어로 보내지 않는 방식은 App Store와 Google Play 양쪽에서 금지된 행위입니다. 적발되면 리뷰가 삭제되고, 노출이 제한되며, 반복되면 개발자 계정이 정지됩니다.

이 선을 지키는 것이 윤리 문제만은 아닙니다. 실효도 없습니다. 조작된 평점은 설치까지는 밀어 올릴 수 있어도 설치 이후의 행동을 만들지 못합니다. 스토어의 성과 신호는 설치에서 멈추지 않고 그 뒤를 봅니다. 게다가 리뷰 본문의 칭찬과 실제 사용 경험이 어긋나면 상세 페이지를 꼼꼼히 읽는 사용자일수록 이탈합니다. 리뷰를 사서 얻는 것은 잠깐의 숫자이고 잃는 것은 계정과 신뢰입니다.

허용되는 방법은 스토어가 직접 제공합니다. iOS에는 시스템이 띄우는 리뷰 요청 프롬프트 API가 있고, Android에는 인앱 리뷰 API가 있습니다. 두 경우 모두 표시 여부와 빈도를 스토어가 통제하며 개발자가 강제로 띄울 수 없습니다. 이 제약이 답답해 보여도 그대로 쓰는 것이 맞습니다. 자체 UI로 별점 창을 흉내 내 만드는 방식은 가이드라인 위반으로 다뤄집니다.

요청 시점은 설계 대상입니다. 사용자가 무언가를 성공적으로 끝낸 직후가 좋은 자리입니다. 출퇴근 기록을 한 달 채웠을 때, 원하던 상대와 연결됐을 때, 처음으로 원하는 결과를 얻었을 때입니다. 반대로 오류 화면 직후, 결제 실패 직후, 앱을 처음 켠 직후는 최악입니다. 아직 판단할 재료가 없는 사람에게 판단을 요구하는 셈입니다.

불만이 있는 사용자를 위한 통로는 따로 두어야 합니다. 앱 안에 상시로 열려 있는 문의 버튼을 두고 그쪽에서 문제를 먼저 처리하는 방식입니다. 이것은 리뷰 게이트와 다릅니다. 리뷰 게이트는 별점을 먼저 물어 높은 점수를 줄 사람만 스토어로 보내는 필터이고, 이것은 별점과 무관하게 누구에게나 열려 있는 창구입니다. 앞의 것은 금지, 뒤의 것은 정상적인 제품 설계입니다.

받은 리뷰에는 답변합니다. 특히 1점과 2점은 빠짐없이 답변하는 편이 좋습니다. 사실 관계를 확인하고, 재현에 필요한 정보를 정중히 요청하고, 실제로 고친 뒤에 다시 답변을 갱신하는 순서입니다. Google Play는 개발자 답변이 달리면 작성자에게 알림이 갑니다. 문제가 해결됐음을 알게 된 사용자가 평점을 스스로 올리는 경우가 있고, 그것이 정상적인 경로입니다. 답변은 공개 문서이기도 합니다. 나중에 상세 페이지를 읽는 다른 사람이 그 대화를 봅니다.

두 스토어의 평점 구조도 다릅니다. Apple은 새 버전을 릴리스할 때 기존 평점을 초기화하는 선택지를 제공합니다. 이것은 실제로 제품을 크게 고쳤을 때에 한해 쓸 카드입니다. 쌓인 리뷰가 함께 사라지므로 가볍게 쓸 수단이 아닙니다. Google Play는 최근 평점에 더 큰 비중을 두는 방식으로 알려져 있어, 나쁜 시기가 시간이 지나며 희석됩니다. 다만 그 전제는 이후 버전이 실제로 나아지는 것입니다. 어느 쪽이든 정확한 현재 규칙은 각 스토어의 공식 문서에서 확인하시기 바랍니다.

마지막으로 리뷰를 제품 입력으로 쓰십시오. 분기마다 리뷰에서 반복되는 불만 세 가지를 뽑아 백로그 상단에 올리는 습관 하나로 평점은 서서히 움직입니다. 이 방식은 느리지만 되돌아오지 않는 종류의 개선입니다.

측정하고 반복하기: 무엇을 바꾸고 무엇을 기다리는가

ASO는 한 번 세팅하고 끝나는 작업이 아니라 바꾸고, 기다리고, 읽는 순환입니다. 한 번에 한 요소만 바꾸고 스토어가 주는 지표를 변경 전후로 비교합니다. 기본 지표는 넷입니다. 검색 결과 노출, 상세 페이지 조회, 설치, 그리고 이 사이의 전환율입니다.

App Store Connect는 노출과 상세 페이지 조회, 설치 수, 전환율을 유입 유형별로 나눠서 보여 줍니다. 스토어 검색으로 들어온 것과 스토어 탐색으로 들어온 것, 웹 링크를 타고 온 것, 다른 앱에서 넘어온 것은 성격이 완전히 다릅니다. 이걸 합쳐서 보면 등록정보를 바꾼 효과가 마케팅 캠페인 효과에 묻힙니다. 최소한 검색 유입만 따로 떼어 놓고 보십시오.

Play Console에서는 획득 보고서와 스토어 등록정보 방문자 수, 그리고 검색어 리포트를 봅니다. Google이 검색어 데이터를 주는 만큼 이 리포트를 안 보는 것은 그냥 손해입니다. 예상하지 못한 검색어로 사람들이 들어오고 있다면 그 말을 짧은 설명과 전체 설명에 자연스럽게 반영할 여지가 있습니다.

A/B 테스트 기능도 스토어 안에 있습니다. iOS에는 상품 페이지 최적화가, Android에는 스토어 등록정보 실험이 있습니다. 다만 전제 조건이 있습니다. 트래픽이 충분해야 결과에 의미가 생깁니다. 유입이 적은 상태에서 며칠 돌린 뒤 승자를 고르면 노이즈를 채택하는 것과 같습니다. 트래픽이 적다면 실험을 쪼개지 말고 큰 변경 하나를 통째로 적용한 뒤 충분히 긴 기간을 앞뒤로 비교하는 편이 낫습니다.

두 스토어는 변경 리듬도 다릅니다. App Store의 이름, 부제, 키워드 필드는 새 버전을 제출하는 흐름에 묶여 있어 아무 때나 바꿀 수 없습니다. Google Play의 등록정보는 상대적으로 자유롭게 바꿀 수 있고 대신 검토가 붙습니다. 이 차이 때문에 실무에서는 Play 쪽에서 먼저 문구를 실험해 배우고, 거기서 얻은 결론을 iOS의 다음 버전 제출에 반영하는 순서가 편할 때가 많습니다.

기다리는 시간을 계산에 넣어야 합니다. 등록정보 변경이 색인에 반영되는 데 며칠이 걸리고, 순위가 새 상태로 안정되기까지 1주에서 2주가 더 걸리는 것이 보통입니다. 사흘 보고 원래대로 되돌리면 아무것도 배우지 못합니다. 반대로 스크린샷과 아이콘은 전환율에 비교적 빠르게 반응하므로 판단을 조금 일찍 내려도 됩니다. 느린 것과 빠른 것을 구분해서 기대 시점을 다르게 잡으십시오.

읽기를 방해하는 요인도 같이 기록합니다. 명절과 연휴, 학기 시작, 외부 광고 집행, 언론 노출, 경쟁 앱의 대형 업데이트가 모두 숫자를 흔듭니다. 이 사건들을 적어 두지 않으면 몇 주 뒤에 그래프만 보고 잘못된 결론을 내리게 됩니다.

가장 값싸고 가장 자주 빠지는 도구는 변경 일지입니다. 날짜, 스토어, 바꾼 필드, 이전 값, 이후 값, 무엇을 기대했는지, 어떤 지표로 볼 것인지, 언제 판정할 것인지를 한 줄씩 남기면 됩니다. 스프레드시트 한 장이면 충분합니다. 이 기록이 없으면 반복이 성립하지 않고, 반복이 없으면 ASO는 그냥 추측입니다.

여우비 인터랙션도 제품마다 다른 순서로 이 작업을 합니다. onSpots는 여러 나라에서 쓰이므로 로케일별로 나눠서 봐야 하고, Job Connect VN은 베트남 한 시장이라 판단이 단순한 대신 그 시장 안에서의 표현 차이가 중요합니다. 랭토리는 배우는 사람과 가르치는 사람이라는 두 종류의 사용자가 서로 다른 말로 검색하므로 등록정보에서 둘의 균형을 잡아야 합니다. 어느 경우에도 다른 앱에서 통한 조합을 그대로 옮기면 맞지 않습니다. 자기 앱의 스토어프론트에서 확인한 것만 남기시면 됩니다.