대부분의 인디 iOS 개발자는 사람들이 자기 앱을 어떻게 찾는지 고민하기보다 기능을 만드는 데 더 많은 시간을 씁니다. 이건 비판이 아닙니다. 혼자서, 혹은 소규모 팀으로 만들다 보면 자연스럽게 그런 순서가 될 뿐입니다.

하지만 ASO 실수는 쌓여 갑니다. 첫 달에 내린 잘못된 키워드 결정은 조용히 실패로 끝나지 않습니다. 그것은 Apple이 여러 달에 걸쳐 당신의 앱을 중심으로 구축하는 시그널의 윤곽 자체를 형성합니다. 그리고 다운로드가 눈에 띄게 떨어져 마침내 알아차렸을 때쯤이면, 6주 전에 시작된 문제를 진단하고 있는 경우가 많습니다.

다음은 첫 해 앱에서 반복적으로 보게 되는 다섯 가지 실수와, 그 대신 무엇을 해야 하는지입니다.

1. App Store 메타데이터를 영구적인 것으로 다루기

가장 큰 실수는 어느 하나의 선택이 아닙니다. 첫 제출을 최종 정답처럼 다루는 것입니다.

App Store 메타데이터(제목, 부제, 키워드 필드)는 수정할 수 있습니다. 그런데도 많은 인디 개발자는 한 번 설정해 두고 넘어간 뒤, 다운로드가 절벽처럼 떨어질 때에야 비로소 다시 들여다봅니다. 그쯤이면 시그널은 이미 몇 주째 악화되고 있던 상태입니다.

키워드 순위는 끊임없이 변합니다. 경쟁사는 메타데이터를 업데이트합니다. 새로운 앱이 당신의 카테고리에 진입합니다. 1월에 특정 검색어로 상위 10위 안에 들었던 앱이, 당신은 아무것도 바꾸지 않았는데도 경쟁 환경이 달라졌다는 이유만으로 4월에는 30위 밖으로 밀려날 수 있습니다.

해결책은 메타데이터를 설정 파일이 아니라 살아 있는 변수로 다루는 것입니다. 타겟팅한 모든 키워드의 순위 변동을 추적하세요. 매주 점검하세요. 최소한 App Store 릴리스 주기마다 한 번은 업데이트하세요.

자신이 어떤 키워드로 순위에 올라 있는지, 그 순위가 안정적인지 아니면 무너지고 있는지를 추적하지 않는다면, 계기판 없이 비행하는 것과 같습니다. 보이지 않는 것은 최적화할 수 없습니다.

2. 경쟁 적합성이 아니라 검색량으로 키워드 고르기

검색량 데이터는 모든 ASO 도구에서 보이며, 거의 항상 개발자가 가장 먼저 정렬하는 열입니다. 경쟁도 점수는 바로 그 옆 열에 있는데도 대부분의 사람들은 그것을 건너뜁니다.

그 직감은 이해할 만합니다. 검색량이 크면 대상 사용자도 크다는 것이죠. 하지만 리뷰 이력도 없고 설치 수도 수백 건뿐인 첫 해 인디 앱에게 검색량이 큰 키워드로 순위에 오르는 것은 거의 불가능합니다. 상대는 수천 건의 평가, 수년 치 다운로드 시그널, 경우에 따라서는 에디토리얼 노출까지 갖춘 앱입니다. Apple의 알고리즘은 그 모든 것을 봅니다.

올바른 접근은 ‘키워드 사다리’입니다. 현실적으로 상위 5위 안에 들 수 있는, 구체적이고 경쟁이 적은 키워드부터 시작하세요. 그 검색어로 검색한 사용자가 다운로드로 이어진다는 것을 증명하세요. 그 전환 시그널을 활용해 권위를 쌓은 뒤에 더 넓은 검색어에 도전하는 것입니다.

검색량은 입력 데이터입니다. 순위는 출력입니다. 작은 앱에게, 출력에 영향을 줄 수 없는데도 오로지 입력만 최적화하는 것은 100자 키워드 필드, 제목, 부제를 낭비하는 일입니다. 이들은 모두 Apple이 서로 다른 방식으로 인덱싱합니다.

좁게 시작하세요. 순위를 쟁취하세요. 그런 다음 올라가세요. 첫날부터 넓게 노리려는 직감이 대부분의 인디 앱에게 첫 6개월을 대가로 치르게 합니다.

3. 영어를 제외한 모든 시장 무시하기

App Store는 175개 스토어프런트에서 운영됩니다. 전형적인 영어 인디 앱은 기술적으로는 그 전부에서 접근 가능합니다. 하지만 메타데이터가 영어로만 되어 있다면, 영어가 아닌 스토어프런트에서의 인덱싱은 거의 없거나 아예 없습니다.

Apple은 각 스토어프런트의 언어로 App Store 메타데이터의 키워드를 인덱싱합니다. 독일 사용자가 독일어로 검색해도 당신의 앱에 독일어 현지화가 없다면 그 검색 결과에는 나타나지 않습니다. 일본어, 브라질 포르투갈어, 프랑스어, 그 밖의 모든 주요 시장에서도 마찬가지입니다.

흔한 반론은 비용입니다. 20개가 넘는 로케일에 메타데이터를 수작업으로 번역하는 것은 비싸고 시간도 많이 듭니다. 예전에는 그랬습니다. 지금은 그렇지 않습니다.

자동 번역 도구를 사용하면 영어 메타데이터를 단 한 번의 작업으로 모든 활성 로케일에 적용할 수 있습니다. 에이전시 수준의 카피라이팅을 얻는 것은 아니지만, 이전에는 보이지 않던 시장에서 인덱싱되기 시작합니다. 대부분의 인디 앱에게, 독일, 일본, 브라질, 프랑스를 포함한 가치 높은 3~5개 시장에 현지화를 추가하는 것은 시간을 비례적으로 투입하지 않고도 키워드 노출 면적을 의미 있게 넓혀 줍니다.

한 번의 자동 번역으로 얻는 해외 노출은 비용이 거의 들지 않습니다. 반면 영어로만 머무름으로써 잃는 해외 노출은, 그렇게 머무는 매일같이 쌓여 갑니다.

4. 경쟁사가 무엇을 하는지 지켜보지 않기

대부분의 인디 개발자는 경쟁사를 단 한 번, 출시 전에만 확인합니다. 그 이후 경쟁사의 메타데이터는 다시는 열지 않는 북마크 속에서 잠들어 있습니다.

문제는 경쟁사가 계속 움직인다는 것입니다. 그들은 키워드를 업데이트합니다. 무엇이 순위에 오르는지 알아내고 거기에 집중합니다. 새 기능을 추가해 사용자가 자신들을 검색하는 방식을 바꿉니다. 만약 경쟁사가 당신과 둘 다 노리는 키워드로 부제를 바꾼다면, 당신이 메타데이터에 손을 대지 않았더라도 그 키워드 경쟁에서의 순위는 달라집니다.

경쟁사의 모든 움직임을 따라 할 필요는 없습니다. 중요한 움직임에 허를 찔리지 않을 정도의 인식만 있으면 됩니다.

특히 주목할 만한 것은, 경쟁사가 제목이나 부제를 바꿀 때(둘 다 키워드 필드보다 더 큰 인덱싱 가중치를 가집니다), 경쟁사가 당신이 차지한 키워드 영역에 진입할 때, 그리고 경쟁사의 리뷰 정서가 크게 변할 때(사용자의 니즈가 바뀌고 있다는 선행 지표인 경우가 많습니다)입니다.

이것을 수작업으로 확인하려면 매주 App Store에서 경쟁사 페이지를 열고, 메타데이터를 스크린샷으로 찍고, 무엇이 바뀌었는지 기억하려 애써야 합니다. 너무 번거로워서 대부분의 개발자는 한 달 안에 그만둡니다.

대안은 경쟁사의 메타데이터 변경을 자동으로 드러내 주는 도구입니다. 그러면 그 15분을 감시가 아니라 의사결정에 쓸 수 있습니다.

5. 측정 기간 없이 변경하기

이것은 다른 모든 실수를 바로잡기 어렵게 만드는 실수입니다. 한 번에 너무 많은 변수를 바꿔 버려서, 무엇이 효과가 있었는지 가려낼 체계가 없는 것입니다.

개발자는 한 번의 릴리스에서 앱 이름, 부제, 키워드, 스크린샷, 앱 설명을 모두 업데이트한 뒤, 일주일 후에 다운로드 수를 보고 무슨 일이 일어났는지 추측하려 합니다. 그러나 그 시그널은 해석이 불가능합니다. 새 스크린샷이 제품 페이지 전환율을 개선했을까요? 키워드 교체가 가지고 있던 순위를 떨어뜨렸을까요? 다운로드 하락은 애초에 업데이트 때문일까요, 아니면 계절적 변동 때문일까요?

ASO는 변경을 하나씩 분리해서 적용하고, 다음 변경을 하기 전에 결과를 관측할 수 있을 만큼 충분히 기다렸을 때에만 깨끗한 시그널을 돌려줍니다.

실용적인 주기는 ‘21일 윈도우’입니다. 메타데이터를 업데이트한 뒤, 순위 변동과 전환 영향을 평가하기 전에 21일을 기다리세요. Apple의 인덱싱은 즉시 이루어지지 않습니다. 노출 데이터가 정상화되는 데는 시간이 걸립니다. 전환 데이터는 안정화되는 데 그보다 더 오래 걸립니다. 3일째에 확인하고 “효과가 없었다”고 결론짓는 것은 거의 항상 틀린 판단입니다.

버전당 한 가지 변경. 21일의 관측 기간. 지표는 올바른 순서로 읽으세요. 먼저 노출, 그다음 페이지 조회 전환, 그리고 다운로드입니다. 그런 다음 다음에 무엇을 바꿀지 결정하세요.

이것이 ASO를 어림짐작에서 하나의 실천으로 바꿔 주는 피드백 루프입니다. 이것이 없으면 모든 업데이트는 거기서 아무것도 배울 수 없는 새로운 실험이 되어 버립니다.

주 단위로 보면 이런 모습입니다

인디 앱에게 이 체계를 돌리는 데 전담 ASO 인력이나 주 10시간은 필요하지 않습니다. 필요한 것은 믿을 수 있는 주 30분의 점검과, 잡음 없이 올바른 데이터를 보여 주는 도구입니다.

추적 중인 키워드의 순위 변동을 확인하세요. 몇 순위 이상 떨어진 것에는 표시를 해 두세요. 지난 7일간의 경쟁사 메타데이터 변경을 검토하세요. 지난번 메타데이터 업데이트 이후 제품 페이지 전환율이 달라졌는지 메모해 두세요.

새 버전이 준비되면, 메타데이터 변경은 하나, 많아야 둘로 하세요. 무엇을, 왜 바꿨는지 기록해 두면, 21일 윈도우가 무엇을 말해 주는지 실제로 해석할 수 있습니다.

그것이 이 체계입니다. 복잡하지 않습니다. 어려운 것은 꾸준함, 그리고 모든 것을 한꺼번에 고치고 싶은 직감을 누르고 한 번에 하나씩 바꾸는 절제입니다.

첫 해에 이 습관을 들인 개발자가 바로 둘째 해에 흔들리지 않는 순위를 손에 넣는 개발자입니다.