에이슬립 QA 자동화

기법 이전은 1건입니다. 수면 측정 앱 회사의 1인 QA가 1년 반에 걸쳐 쓴 여덟 편에서 설계 결정 열한 개를 뽑아 제 것과 대봤더니, 열은 제가 이미 같은 방향으로 가 있었습니다. 남은 하나가 이 페이지의 값어치인데 — 이 조사의 진짜 소득은 그 하나가 아니라, 같은 제약 아래서 다른 사람이 독립적으로 같은 결정에 도달했다는 사실이었습니다. 그리고 그 판정에 이르기까지 제 결론이 두 번 뒤집혔습니다.

무엇을 만든 사람인가

수면 측정 앱을 만드는 회사의 1인 QA다. 2025년 1월부터 2026년 8월까지 여덟 편을 썼고, 층위가 다 다르다 — 커리어 동기 한 편, 배포 후 모니터링, 대규모 자동화 코드 표준, 24시간 실행 중 메모리 붕괴 디버깅, 온프레미스 디바이스 팜 구축, 그리고 자체 QA 플랫폼 회고.

클라우드를 먼저 고수하려 했다는 게 중요하다. 클라우드 디바이스 팜 베타에서 소리 주입을 시험하다 실패했고, 벤더가 5년 전 지원 종료된 프레임워크 버전으로 내려가라는 해결책을 제시했다. 그 버전 이후 아키텍처가 동기에서 비동기로 바뀌었으니 생태계 몰이해라고 반박했고, 결국 최신 버전에서 동작했다. 그럼에도 소리 주입 방식 자체가 이 제품 검증에 안 맞아 모바일은 클라우드를 접었다.

그리고 저자의 결론이 정직하다. 클라우드 벤더와 싸워 이기고도 이렇게 끝난다 — “대부분은 클라우드가 맞다.” 특수 요구가 클라우드로 해결 불가하고 허브·노드로 잘 설계할 수 있을 때만 온프레미스가 좋은 방향이라고. 자기 선택을 일반화하지 않는 글은 드물다.

핵심은 동시 제어다 — 병렬 실행이 아니라

둘을 섞어 읽으면 이 묶음을 잘못 읽는다. 성격이 완전히 다른 두 축이고, 저자가 “핵심”이라 부른 건 뒤쪽이다.

	병렬 실행	동시 조작
N대가 하는 일	각기 다른 테스트	같은 동작을 한꺼번에
목적	처리량 · 야간 무인 전수	기종 간 차이를 눈으로 대조
최대 난제	세션 충돌 · 기기 상태 오염	같은 버튼 누르기
해법	허브가 가용 노드를 스캔해 큐잉	좌표 대신 화면 위 실제 요소 기준

저자는 동시 제어를 “편의 기능이 아니라 1인 QA가 감당할 수 있는 검증 규모 자체를 바꾸는 기능”이라고 규정한다. 12조합을 기기 하나씩 붙잡고 확인하면 같은 조작을 기기 수만큼 반복해야 하는데, 동시 제어는 그 반복을 없앤다 — 2대든 10대든 걸리는 시간이 거의 같다.

성립 조건이 둘이었다.

• 정확도 — 화면 비율로 계산한 좌표는 기종마다 여백과 상단바 높이가 달라 같은 화면에서 100px 넘게 어긋난다. 그래서 화면 위 실제 요소를 찾아 누르는 방식으로 바꿨다
• 속도 — 한 대라도 느리면 전체가 어긋난 것처럼 느껴진다. 그래서 표준 프레임워크를 거치지 않고 기기와 직접 연결했고, 무선에서 화면 탭 14ms · 키 입력 4~7ms를 실측했다

그리고 이 묶음에서 제일 제대로 된 수치가 하필 여기 붙어 있다. 조건(“무선 실측”)을 밝히고 두 동작을 분리해 제시했다.

깨본 결과 — 결함 검출 데이터가 없다

여덟 편 전체를 관통하는 결손이 하나 있다.

디바이스 팜도, 플랫폼도, 자연어 검증 엔진도, 자체 테스트 900개도 만들었는데 — “수동으로는 못 잡았을 결함을 몇 건 잡았다”는 숫자가 어디에도 없다.

전부 돌아가는가로 평가되고 찾아내는가로 평가되지 않는다. 자동화가 가장 흔하게 실패하는 지점이 정확히 거기다.

나머지도 적어 둔다. “45초 안에 자동 복구”는 검증 불가다 — 감지 기전이 서술되지 않아 측정된 복구 지연이 아니라 설정한 타임아웃 값일 가능성이 높다. 그렇다면 45초는 성과가 아니라 파라미터다. “자체 테스트 900개”는 허영 지표다 — 커버리지도, 그것이 잡은 결함 수도 없고, 플랫폼과 그 테스트를 같은 한 사람이 썼으니 자기참조 오라클이라 맹점이 그대로 복제된다.

가장 취약한 부품에 증거가 0인 것도 걸린다. 자연어 시나리오 무인 검증이 이 플랫폼에서 제일 깨지기 쉬운 부분인데 정확도·플래키율·모호할 때의 동작이 한 줄도 없다.

그리고 메모리 붕괴 편은 절반이 틀린 가설의 확대 서술이다. 타임아웃 3계층 이야기는 유용한 지식이지만 원인이 아니었고, 실제 해결은 “녹화 세그먼트를 힙에 쌓지 말고 즉시 디스크에 쓴다” 한 줄이었다. 게다가 타임아웃을 전부 30시간으로 올린 건 멈춤 감지기를 꺼 버린 것이다 — 24시간 테스트에 한해 정당하지만, 상시 기본값이 되면 “멈춘 세션”과 “긴 세션”을 구분할 수단이 사라진다.

가져온 것은 하나였다

넘어온 하나가 이것이다.

요소를 못 찾아 좌표로 대신 누른 기기가 몇 대인지 세어서 화면에 즉시 표시한다.

제겐 좌표 폴백이 있는데 그 계수가 없다. 그래서 정확히 눌러서 통과한 탭과, 요소를 못 찾아 좌표로 대충 눌러서 통과한 탭이 같은 PASS로 기록된다.

PASS가 두 종류인데 리포트에는 한 종류로 남는다는 뜻이다. 폴백은 다음 빌드에서 조용히 깨질 자리인데, 계수가 없으면 그게 늘어나는 것도 모른다.

그리고 제 판정을 두 번 고쳤다

첫 번째. “침묵 연결 감지가 신규 수확”이라고 적었다가 틀렸다. 제 코드를 열어 보니 이미 있었다. 화면 변화량을 별도 축으로 두고 단계 복구를 거는 장치가 배선돼 있었다. 써 둔 운영 지침을 구현된 상태로 착각한 것이고, 이 실수는 Prime Agent에서도 똑같이 했다.

두 번째. 그래서 “신규 도입 0건”으로 닫으려 했는데 그것도 틀렸다. 저자가 “핵심”이라고 부른 절이 최초 발췌에 안 잡혀 있었고, 위의 채택 1건이 바로 거기 있었다.

발췌가 얇으면 결론이 통째로 바뀐다.

판정

기법 이전은 1건. 이 조사의 진짜 값어치는 다른 데 있었다.

같은 제약 — 1인 QA, 실기기, 장시간, 무인 회귀 — 아래서 다른 사람이 독립적으로 같은 결정에 도달했다. 온프레미스, 라이브 환경 기본 차단, 무인 회귀, 요소 기준 타겟팅. 제가 혼자 굴러서 얻은 결론들이라 표본이 하나뿐이었는데, 이제 둘이다.

기법이 적게 넘어왔다는 것과 조사가 헛됐다는 것은 다른 말이다.