QA 자동화

남이 만든 테스트 자동화를 뜯는 자리. 디바이스 팜, 실기기 무인 회귀, 게임 오토플레이 도구, 에이전트 기반 테스트 플랫폼.

제 본업인데 수확이 제일 적습니다. 다섯 편에서 기법 이전은 4.5건입니다. 잘못 뜯어서가 아니라, 같은 제약 아래 굴러온 시간이 길어서 대개 이미 같은 결론에 가 있기 때문입니다.

그래서 여기서 나오는 값어치가 다르다

대상	기법	실제로 남은 것
에이슬립 QA 자동화	11종 중 1	같은 제약 아래서 남이 독립적으로 같은 결정에 도달했다는 사실
토스 네뷸라	0	남의 원칙을 자로 삼으니 제 관문이 두 벌이라는 게 보였다
오토플레이 테스트 툴	4종 중 2	끼임을 데이터의 모순으로 잡고, 오탐을 타이머 둘의 AND로 걷는다
QA 인프라 발표	0	도구가 아니라 증거의 성격이 접근 권한에서 갈린다는 사례
watermarks-remover	4종 중 1.5	검출기를 들이기 전에 자기 코퍼스로 오탐률부터 재라 — 그것도 실제로 걸 자리의 코퍼스로

가져올 게 없어도 조사가 헛되지 않습니다. 에이슬립 쪽은 표본이 하나뿐이던 결론을 둘로 만들었고(온프레미스·라이브 fail-closed·무인 회귀·요소 기준 타겟팅), 네뷸라 쪽은 기법을 0개 주는 대신 제 코드에서 정식 관문의 방어가 실제 런에 하나도 안 걸려 있다는 걸 찾아냈습니다.

그리고 두 편 다 제 판정이 뒤집혔다

에이슬립은 두 번 고쳤습니다. “침묵 감지가 신규 수확”이라고 적었다가 제 코드에 이미 있어서 지웠고, 그래서 “신규 0건”으로 닫으려다 발췌가 얇아서 저자가 핵심이라 부른 절을 통째로 놓친 걸 발견해 다시 열었습니다.

네뷸라는 초판의 유일한 수확이 기각됐습니다. uiautomator dump가 2,350ms라는 실측을 근거로 채택했는데, 제 파이프라인에 그 호출이 0건이었습니다. 게임 클라이언트는 화면을 네이티브 서피스 하나에 그려서 접근성 트리가 애초에 안 잡힙니다.

실측은 맞았는데 대상이 틀렸다. 벤치마크를 재기 전에 “이 호출이 내 런에서 실제로 일어나는가”를 먼저 봐야 했다.

네 편이 되니 「이미 가 있다」의 뜻이 갈렸다

두 편일 때는 “이미 같은 결론에 가 있다” 하나로 읽었습니다. 넷이 되니 그 안에 두 종류가 섞여 있었습니다.

하나는 진짜로 같은 자리입니다 — 에이슬립의 결정 열한 개 중 열이 그랬습니다. 다른 하나는 같은 자리인 줄 알았는데 한 겹이 얕은 것입니다. 오토플레이 편이 그랬습니다. 저도 봇의 끼임을 판정하고 있었고 틀린 것도 아니었는데, 후보를 잡는 층과 오탐을 걷는 층을 나누지 않았을 뿐이었습니다.

이 둘은 안 뜯어보면 구분이 안 됩니다. 둘 다 “우리도 하고 있는데” 로 보이기 때문입니다. 층을 나누자마자 오탐의 원인이 이름을 갖게 됐습니다 — “의도적으로 멈춘 정상 상태”.

그리고 이 분류에는 도구가 아닌 수확이 하나 있다

QA 인프라 편에서 남은 건 기법이 0종인데, 뽑기 확률 검증 사례 하나가 남았습니다. 수백 판을 뽑아 통계로 추정하던 것이, 원본 조회 권한이 생기자 쿼리 한 줄 5초가 되면서 증거의 성격이 추정에서 확정으로 바뀌었습니다.

빨라진 게 아닙니다. 무엇을 증거로 칠 것인가가 바뀐 겁니다. 판정을 다루는 글에 그대로 들어갈 예시라, 이 분류에서 나온 것 중 글로 가는 유일한 수확입니다.

다섯 번째는 이 분류의 첫 레포였고, 검출기를 심판하러 갔다가 제가 걸렸다

앞의 넷은 전부 남의 발표·아티클이었습니다. watermarks-remover가 이 분류에서 처음으로 코드를 읽은 편이고, 그래서 여기서만 할 수 있는 일을 했습니다 — 남의 검출기를 제 데이터에 직접 돌려 봤습니다.

결과가 이 분류에서 제일 값비쌌습니다. AI 글을 가르라고 만든 지표가, 첫 발화에서 사람이 쓴 제 글을 잡았습니다. 문장길이 변동계수를 제 사이트 장문 98편에 돌리니 중앙값 0.668 로 널찍했는데, 그 규칙이 실제로 살 채널의 원고로 옮겨 재니 여섯 중 하나가 임계 아래였고 그 하나는 이미 게시까지 끝낸 제 글이었습니다.

오탐률을 잴 자리를 틀리면 오탐률 자체가 거짓말이 된다. 장문에서 재고 짧은 글에 걸면, 재기 전보다 나빠진다.

QA 로 읽으면 이건 익숙한 실패입니다. 테스트 데이터가 프로덕션 분포와 다른 것. 다만 이번엔 제가 그 테스트 데이터를 고른 사람이었습니다. 네뷸라 편에서 “이 호출이 내 런에서 실제로 일어나는가” 를 배웠는데, 같은 구멍의 한 칸 옆이었습니다 — 호출은 일어나는데 재는 표본이 다른 곳에서 왔습니다.