QA 자동화

제 본업 이야기입니다. 그리고 다섯 칸 중에서 배워 온 게 제일 적은 칸입니다.

먼저 「QA 자동화」가 뭔지부터 말씀드리겠습니다.

게임이나 앱을 만들면 제대로 돌아가는지 일일이 눌러 보며 확인해야 합니다. 버튼을 누르고, 화면이 맞게 뜨는지 보고, 값이 제대로 들어갔는지 확인합니다. 그걸 사람이 손으로 하는 게 「QA」이고, 기계가 대신 눌러 주게 만드는 것이 「QA 자동화」입니다.

이 칸에는 남들이 만든 자동화를 열어 보고 적은 글이 여섯 편 있습니다.

본업인데 배워 온 게 제일 적습니다 — 그게 나쁜 뜻이 아닙니다

앞의 다섯 편을 뜯어서 제 것에 들여오겠다고 적은 기법은 4.5건입니다. 다른 칸에 비해 적습니다. (점검 때 실제로 들어가 있던 것은 1건이었습니다 — 아래 2026-09 점검.)

처음엔 「내가 잘못 뜯었나」 싶었는데 아니었습니다. 같은 문제를 오래 붙들고 있으면 다들 비슷한 답에 도착하기 때문입니다.

비유하면 이렇습니다. 산 정상에 오르는 길이 몇 개 안 될 때, 먼저 오른 사람과 나중 오른 사람이 만나는 지점이 같습니다. 그때 「배울 게 없네」가 아니라 「내 길이 맞았구나」가 소득입니다.

배울 게 없어도 조사가 헛되지 않은 이유

이게 이 칸에서 제일 중요한 이야기입니다. 두 가지 다른 종류의 소득이 나왔습니다.

첫째, 혼자만의 결론이 둘이 됐습니다. 어떤 판단은 저 혼자 해 온 것이라 맞는지 틀린지 확인할 길이 없었습니다. 그런데 전혀 모르는 사람이 전혀 다른 회사에서 똑같은 결론에 독립적으로 도착해 있었습니다. 표본 하나가 둘이 된 것입니다. 기법을 하나도 안 가져왔어도 이건 값이 큽니다.

둘째, 남의 원칙이 제 것을 재는 자가 됐습니다. 어떤 편에서는 가져올 기법이 0건이었습니다. 그런데 그 사람들이 세운 원칙을 자로 삼아 제 코드를 재 보니, 제가 만들어 둔 방어 장치가 실제 실행에는 하나도 안 걸려 있다는 걸 발견했습니다. 배운 게 없는데 고칠 게 나온 것입니다.

「이미 가 있다」가 늘 같은 뜻은 아니었습니다

두 편일 때는 「이미 같은 결론에 가 있다」 한 가지로 읽었습니다. 네 편이 되니 그 안에 두 종류가 섞여 있었습니다. 같은 답에 도착한 것과, 같은 답을 적어만 두고 실제로는 안 해 둔 것은 완전히 다릅니다.

그리고 실제로 제가 두 번째에 걸렸습니다 — 「해 뒀다」고 믿었던 것이 사실은 「하겠다고 적어 둔 것」이었습니다.

권한 하나가 증거의 성질을 바꾼 이야기

기법이 아닌 소득이 하나 있습니다.

게임에서 뽑기 확률이 광고한 대로인지 확인하는 일이 있습니다. 예전에는 수백 판을 직접 뽑아서 통계로 추정했습니다. 오래 걸리고, 나온 결과도 「아마 맞을 것이다」 수준입니다.

그런데 원본 데이터를 볼 권한이 생기자, 같은 확인이 질의문 한 줄에 5초로 끝났습니다. 그리고 결과가 「아마」가 아니라 확정이 됐습니다.

→ 배운 것: 도구를 바꿔서 빨라진 게 아니라, 볼 수 있는 자리가 바뀌어서 증거의 종류 자체가 바뀌었습니다.

다섯 번째 편에서는 심판하러 갔다가 제가 걸렸습니다

앞의 넷은 전부 남의 발표나 글을 읽은 것이었습니다. 다섯 번째는 처음으로 남의 코드를 직접 받아서 제 데이터에 돌려 본 편입니다.

남의 검출 도구가 제대로 잡는지 시험하러 갔는데, 제 데이터에 돌려 보니 엉뚱한 것을 잔뜩 잡았습니다. 그 도구가 나쁜 게 아니라 제가 쓰려던 자리에 안 맞는 도구였던 것입니다. 그걸 안 재 보고 들였으면 그대로 들어왔을 것입니다.

가져온다고 적은 4.5건 중 코드에 들어간 건 1건이었습니다 — 2026-09 점검

한 달쯤 지나, 편마다 「가져온다」고 적은 것이 정말 들어갔는지 제 코드를 열어 확인했습니다.

편	가져온다고 적은 것	2026-09 지금
에이슬립 QA 자동화	좌표로 대충 눌러 통과한 것을 따로 센다	들어갔습니다 — 탭마다 근거를 적는 «탭 원장»
오토플레이 테스트 툴	「힘은 주는데 안 움직임」으로 끼임 잡기 · 두 시계가 함께 울려야 확정	점검 때는 없었습니다 → 둘 다 넣었습니다(9/28)
watermarks-remover	문장 리듬 한 항 · 모르는 파일이 나오면 멈추는 검사	점검 때는 둘 다 없었습니다 → 멈추는 검사(9/28)와 리듬 한 항(9/29, 긴 글 전용) 둘 다 넣었습니다
토스 네뷸라	기법 대신 찾아낸 «관문 두 벌» 고치기	절반 — 실제 실행 길에 잠금은 걸었고, 관문은 아직 두 벌
QA 인프라 발표	뽑기 사례를 글의 예시로	들어갔습니다 — 「아마 맞다」는 판정이 아니다

「가져온다」고 적는 일과 실제로 넣는 일은 따로였습니다. 뜯고 나서 판정 표에 «채택»을 적으면 그 자리에서 일이 끝난 것처럼 느껴지는데, 코드는 그걸 모릅니다. 그래서 이 칸의 숫자를 «채택 4.5»가 아니라 «적용 4.5 / 4.5»로 고쳐 적습니다 — 점검 때 들어가 있던 1건에, 그 뒤 이틀 동안 넣은 3.5건(모르는 파일이면 배포를 멈추는 검사 · 끼임의 모순 감지 · 두 시계 확정 · 긴 글 전용 문장 리듬)을 더한 수입니다. 효과는 갈립니다. 문장 리듬은 첫 판에서 쉬운 설명 두 편을 잡아 고쳤고, 끼임 쪽 둘은 시뮬레이션에서 아직 거른 게 없습니다 — 지금 봇은 걷는 내내 밀고, 시뮬레이션에는 기어가는 경우도 없어서입니다. 넣은 것과 효과가 난 것도 따로 셉니다.

반대 방향의 틀림도 하나 나왔습니다. 오토플레이 편에서 「제 끼임 판정은 층이 하나뿐」이라고 적었는데, 코드를 열어 보니 둘째 층이 이미 있었습니다 — 그 편에 고쳐 적었습니다.

그리고 이 칸 밖에서, 남이 만든 물건이 처음으로 제 QA 파이프라인에 들어왔습니다. 판정용 모델 Jev를 사진 판독기의 «두 번째 눈»으로 붙였습니다(2026-09-24). 뜯기가 아니라 나흘 시범으로 재 보고 들였고, 잰 범위에서 진짜 오류를 잡은 적은 아직 없습니다 → 사진 판독기.

여섯 번째 편은 같은 대상을 두 번 뜯고, 한 번도 안 돌렸습니다

clumsy는 PC의 인터넷을 일부러 나쁘게 만드는 도구입니다. 끊김 테스트에 쓰려고 열었는데, 다 쓰고 나서야 8월에 이미 같은 결론을 적어 둔 리포트가 있다는 걸 알았습니다. 두 번 다 「쓴다」고 적었고, 두 번 다 돌려 보지 않았습니다.

위 점검에서 본 「적는 일과 넣는 일은 따로」를, 이번엔 한 대상 안에서 두 번 겪은 셈입니다. 그래서 이 칸의 숫자가 «적용 4.5 / 7»이 됩니다 — 적은 것에 clumsy의 2.5건이 더해졌고, 들어간 것은 그대로입니다.

여기부터는 자세한 기록입니다

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

제 본업인데 수확이 제일 적습니다. 다섯 편에서 기법 이전은 4.5건입니다(2026-09-29 기준: 판정 표에 적은 것 4.5 · 코드에 들어간 것 4.5 — 점검 때 1, 점검 뒤 3.5 · 위 «2026-09 점검» 절). 잘못 뜯어서가 아니라, 같은 제약 아래 굴러온 시간이 길어서 대개 이미 같은 결론에 가 있기 때문입니다.

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

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

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

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

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

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

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

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

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

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

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

(2026-09 기준 정정) 오토플레이 편의 「층을 나누지 않았다」는 틀렸다. 제 끼임 판정에는 후보(3초 동안 60cm 미만 이동) 뒤에 탈출 시도로 확정하는 둘째 층이 7월 코드부터 있었다. 한 겹 얕았던 건 층의 개수가 아니라 «입력과 실제를 같이 보는» 모순 감지다. 그건 2026-09-28 에 넣었다.

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

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

빨라진 게 아닙니다. 무엇을 증거로 칠 것인가가 바뀐 겁니다. 판정을 다루는 글에 그대로 들어갈 예시라, 이 분류에서 나온 것 중 글로 가는 유일한 수확입니다. (2026-09 기준 — 들어갔다: 「아마 맞다」는 판정이 아니다가 이 사례를 «표본에서 원본 직접 조회로» 몇 칸을 건너뛴 예로 쓴다.)

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

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

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

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

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