자동화 파이프라인10 분 읽기

동기화 잡은 누락 0이라고 했고, 그건 사실이었습니다

앱이 심사를 통과하면 여러 페이지에 스토어 링크를 걸어 주는 잡이 있습니다. 세 번 연속 누락 0이었습니다. 그런데 랜딩 페이지 세 곳은 여전히 '검색' 링크였습니다. 잡이 틀린 게 아니라, 잡이 아는 목록이 짧았습니다.

#automation#app-store-connect#gotchas#data-quality#reality-check
왼쪽은 지면 6종을 대조해 누락 0을 낸 동기화 잡, 오른쪽은 목록에 없던 일곱 번째 지면인 랜딩 페이지에 남아 있던 App Store 검색 링크
차집합은 목록 안에서만 0입니다. 목록 밖은 묻지 않습니다.

심사 통과는 아무 이벤트도 쏘지 않습니다

혼자 iOS 앱 59개와 Android 앱 37개를 스토어에 올려 두고 있습니다. 앱 하나가 심사를 통과하면 손대야 할 곳이 많습니다. 앱 디렉터리, 홈 4개 언어, 사이트맵, 홍보 봇이 읽는 목록, 플랫폼 표시, 스토어 감시 목록까지.

문제는 심사 통과가 저에게 아무 신호도 보내지 않는다는 점입니다. 실제로 한 앱은 iOS가 공개된 뒤 일주일 넘게 홈과 홍보 목록에서 "Android 전용"으로 남아 있었습니다.

그래서 6시간마다 도는 잡을 만들었습니다. 하는 일은 단순합니다.

  • 스토어에서 공개된 앱 집합을 잰다(App Store Connect + 공개 조회 API, Play 리스팅).
  • 지면마다 그 지면에 걸린 앱 집합을 읽는다. 라이브 페이지를 직접 받아 온다.
  • 공개 집합 − 지면 집합을 지면별로 낸다.
  • 누락이 있으면 에이전트가 배선하고, 끝나면 차집합을 다시 돌려서 판정한다. 에이전트의 "다 했습니다"는 안 믿습니다.

어제 이 잡은 세 번 연속 누락 0을 찍었습니다.

그런데 랜딩 세 곳이 '검색' 링크였습니다

혹시 몰라 손으로 한 바퀴 더 돌았습니다. 질문을 바꿔서요. "잡이 보는 곳에 누락이 있나"가 아니라 "앱 ID가 적힌 파일이 디스크 어디에 있나"로.

그러자 잡이 한 번도 본 적 없는 지면이 나왔습니다. 앱별 랜딩 페이지입니다. 세 앱의 랜딩과 개인정보·약관·지원 페이지 9개 파일에서 App Store 버튼이 이렇게 걸려 있었습니다.

https://apps.apple.com/search?term=Somnul

출시 전에 페이지를 먼저 만들면서 넣어 둔 임시 링크입니다. 앱 ID가 아직 없었으니까요. 앱이 공개된 뒤에도 그대로 남았습니다. 이 링크를 누르면 앱 페이지가 아니라 검색 결과로 갑니다. 거기에는 경쟁 앱도 같이 뜹니다.

잡이 틀린 건 아닙니다. 잡은 자기가 아는 지면 6종에 대해서는 정확했습니다. 지면 목록에 랜딩이 없었을 뿐입니다.

당신의 동기화나 감사 도구가 "0건"이라고 할 때, 그 0은 어떤 목록 위에서 센 숫자입니까?

같은 스캔이 하나 더 찾아냈습니다

같은 방식으로 훑다가 홍보 영상용 앱 목록 생성기를 다시 봤습니다. 이 스크립트에는 앱 44개가 하드코딩돼 있었습니다. 그런데 이 스크립트가 만든다는 결과 파일에는 58개가 들어 있었습니다. 최근 앱들은 결과 파일에 직접 넣어 왔기 때문입니다.

누가 이 생성기를 한 번 돌리면 결과 파일에서 14개 앱과 손으로 쓴 카피가 조용히 사라집니다. 앱 수가 줄어드는 게 눈에 띌 수도 있겠지만, 그날 다른 앱이 추가됐다면 숫자만 보고는 모릅니다.

당신이라면 생성기에 14개를 다시 채우겠습니까, 아니면 생성기를 고치겠습니까?

저는 채우지 않았습니다. 손 카피와 아이콘 경로가 생성기 규칙과 이미 달라서, 채워도 다시 돌리면 덮어쓰기는 똑같이 일어납니다. 대신 덮어쓰기 전에 잃게 될 앱을 세고, 하나라도 있으면 중단하게 했습니다. 지금 돌리면 14개 이름을 찍고 rc=1로 멈춥니다. 결과 파일은 바이트 하나 안 바뀝니다.

일곱 번째 지면을 넣고, 오늘 바로 쓰였습니다

랜딩을 잡의 일곱 번째 지면으로 넣었습니다. 공개된 iOS 앱 ID와 Play 패키지가 랜딩에 직링크로 있는지 봅니다. 회귀 테스트에는 search?term= 랜딩을 누락으로 잡는 케이스를 넣었습니다.

오늘 오후, 앱 하나(Mosslock)가 심사를 통과했습니다. 15:16 회차가 누락 6건을 냈습니다. 디렉터리, 홈 4개 언어, 홍보 목록입니다. 에이전트가 13분 만에 배선했고, 다시 잰 차집합은 0이었습니다.

그런데 이 6건에 랜딩은 없었습니다. 랜딩에는 스토어 링크가 아예 없었는데도요. 잡은 랜딩 주소를 디렉터리의 링크에서 찾습니다. 새 앱은 아직 디렉터리에 없었으니 첫 측정에서는 랜딩을 읽지도 않은 겁니다. 에이전트는 절차서대로 랜딩 버튼까지 넣었습니다. 디렉터리 배선이 끝난 뒤의 재측정은 랜딩까지 읽었고, 그때 0이 나왔습니다. 일곱 번째 지면도 결국 목록을 어디서 얻느냐에 묶여 있다는 걸 하루 만에 다시 봤습니다. 그래서 랜딩 주소를 스토어 쪽 번들 ID에서도 뽑도록 바꿨습니다. 어느 목록에도 아직 없는 새 앱이라도 스토어에는 있으니까요.

목록은 기억이 아니라 grep으로 만듭니다

이번에 쓸모 있었던 건 새 검사가 아니라 목록을 만드는 방법이었습니다. 제가 기억하는 지면을 적는 대신, 디스크 전체에서 앱 ID가 10개 이상 들어 있는 파일을 찾았습니다. 그 결과를 지면 목록과 맞춰 보면, 목록에 없는 카탈로그가 드러납니다.

같은 스캔으로 반대 방향도 봤습니다. 내려간 앱으로 가는 죽은 링크입니다. 이건 0건이었습니다.

자가진단 체크리스트

  • 당신의 동기화·감사 잡이 대조하는 대상 목록은 어디서 왔습니까? 사람이 적은 목록이라면, 식별자 grep으로 만든 목록과 한 번 맞춰 봤습니까?
  • 출시 전에 넣어 둔 임시 값(검색 링크, 플레이스홀더, "준비 중")을 출시 뒤에 다시 찾는 단계가 있습니까?
  • 손으로 고친 파생물이 있다면, 그 생성기를 지금 돌리면 무엇이 사라지는지 알고 있습니까?

이번 일과 닮은 이야기가 하나 더 있습니다. 모든 잡이 초록불이었는데 사이트는 낡아 있던 2주입니다. 그때는 성공 신호가 결과를 대신했고, 이번에는 0이라는 숫자가 범위를 대신했습니다.

솔직한 부분

일곱 번째 지면은 잡이 아니라 사람이 손으로 훑다가 찾았습니다. 여덟 번째가 없다고 말할 근거는 아직 없습니다. 반복할 수 있는 건 grep 스캔인데, 그 스캔은 아직 스케줄에 넣지 않았습니다. "누락 0"은 이제 "일곱 곳에서 0"이라는 뜻으로 읽습니다. 여러분의 0은 몇 곳에서 센 0인지, 한 번 세어 보시길 권합니다.

관련 글