코딩 에이전트가 코드를 바꾸는 속도를 기존 테스트 자동화가 따라가지 못한다. 잦은 변경 앞에서 자동화가 무너지면서 테스트에 무엇을 남길지도 달라졌다.
셀렉터는 사용자의 의도를 모른다
LinkedIn은 13억 명이 쓰는 서비스를 세 플랫폼과 36개 이상 언어로 제공한다. 사용자 유형과 요금제, 상시 실험까지 더하면 UI 조합은 수천 가지 에 이른다. 고정된 DOM 셀렉터로 이 규모를 어떻게 따라가겠는가.
그중 button:nth-child(2)는 지금 화면의 구조일 뿐 사용자의 의도를 담지 않는다. 좋아요를 누른다는 동작은 그대로여도 버튼의 위치와 식별자는 자주 바뀐다. 비동기 처리, 실행 순서, 네트워크 문제까지 겹친다. 그래서 Google에서는 코딩 시간의 2%가 플래키 테스트(같은 코드라도 실행마다 성공과 실패가 갈리는 테스트) 조사에 쓰인다 는 분석도 나왔다.
여기에 코딩 에이전트는 변경 속도를 더 높인다. 에이전트가 만든 PR은 2025년 9월 월 400만 건에서 2026년 3월 1,700만 건으로 늘었지만, AI 코드를 커밋 전에 검증한 개발자는 48%에 그쳤다. 코드 생성이 빨라질수록 테스트 방식도 달라져야 한다.
DOM 대신 화면을 읽는 QA
LinkedIn은 화면을 직접 읽는 QA 에이전트를 만들었다. DOM 대신 픽셀을 보기 때문에 버튼 ID나 언어가 바뀌어도 문구와 위치를 바탕으로 기능을 찾는다. 명세에 남는 것은 좌표가 아니라 해야 할 행동이다.
이 작업은 여러 모델이 역할을 나눠 맡는다.
- 플래너가 다음 행동을 정하고, 분석 모델이 오류와 뷰트리(화면 구성 요소를 트리 구조로 표현한 데이터), 리포트를 살핀다.
- 시각 그라운딩 모델은 자연어 지시를 화면 좌표로 바꾼다.
계획, 분석, 좌표 탐색을 분리 해 각 모델을 따로 개선할 수 있다.
다만 ScreenSpot-Pro에서 GUI-Owl-1.5-32B의 정확도는 72.9%, 2단 정제 후에도 80.3% 였다. 장기 과제에서는 정확도가 더 떨어져, OSWorld 2.0에서 최상위 시스템의 완주율은 20.6% 에 머물렀다. 그래서 LinkedIn은 오판을 줄이려고 스크린샷뿐 아니라 뷰트리, 분석 이벤트, 행동 이력도 함께 확인한다.
정확도를 지키며 토큰을 줄이는 법
LinkedIn은 세 플랫폼에서 350개가 넘는 테스트를 30분마다 실행하는데, 매번 모델을 호출하면 비용과 시간이 커진다. 그래서 성공한 경로는 빠른 System 1이 재생하고, UI가 달라졌을 때만 System 2가 화면을 다시 해석한다.
System 1은 저장된 좌표의 요소 유형과 화면, 접근성 문구를 먼저 확인한다. 조건이 같으면 모델 없이 진행하고 하나라도 다르면 System 2로 넘긴다. 화면 변화가 곧 테스트 실패는 아니다. 재해석 신호로 다룬다.
System 2는 화면과 최근 행동, 목표를 보고 다음 행동을 고른다. 성공한 최근 지시 20개 도 참고해 처음부터 다시 찾는 일을 줄인다. 비슷한 방식의 LOOP 연구는 99% 성공률과 최대 99%대 토큰 절감 을 보고했다. 발견한 오류 역시 재검증까지 통과해야 버그로 등록한다.
골든 데이터로 에이전트를 시험하라
계속 바뀌는 라이브 앱만으로는 에이전트의 성능을 정확히 비교하기 어렵다. LinkedIn은 스크린샷, 뷰트리, 기대 행동을 고정한 골든 데이터셋을 만들었다. 실험용 플래너도 실제 플래너와 나란히 실행해 같은 화면에서 선택과 완료 판단을 비교한다.
정확도 문제는 curl에서도 반복됐다. 저품질 보안 신고가 쏟아지자 curl은 2026년 1월 말 HackerOne 프로그램을 종료했다. 2025년 신고의 약 95%가 오탐이었고, 이를 가려내는 일은 7명의 자원봉사자 몫이었다. 신고 건수보다 정확도가 운영 부담을 갈랐다.
결국 견고한 QA는 완전한 자율성보다 역할 분담에서 나온다.
의도는 자연어로 남기고 익숙한 구간은 재생하며 달라진 구간만 모델이 다시 본다.
판단에는 화면, 구조, 이벤트, 행동 이력을 함께 쓰고 에이전트도 고정된 데이터로 검증한다. LinkedIn은 이 방식으로 200건이 넘는 유효 버그와 매출 관련 흐름의 중대한 회귀 를 찾았다. 비개발자도 자연어로 테스트를 작성할 수 있게 됐다.
다만 자연어로 쓴 테스트가 늘면서 요구사항 문장의 표현이 실행 결과를 좌우한다. 모호한 표현을 줄이는 일도 제품 검증 과정의 일부가 됐다.