UI 테스트 병목과 2025년 3월의 전환점

First Orion은 2025년 3월 Amazon Nova Act(자연어 기반 UI 조작 에이전트) 사전 릴리스를 채택하며 UI 테스트 병목으로 인한 릴리스 속도 저하와 회귀 버그 증가 문제를 해결했다. 이는 기존의 UI 탐색 방법을 코드로 일일이 기술하던 방식에서 벗어나, 테스트 목적을 일상어로 정의하고 지능형 에이전트가 이를 수행하게 만드는 선택이었다. 단순한 도구 교체가 아니라 QA 엔지니어가 스크립트 유지보수에 쏟던 시간을 테스트 설계로 돌리려는 실무적 판단이 작용한 결과다.

First Orion은 미국과 캐나다, 영국, 독일의 주요 통신사를 대상으로 브랜디드 커뮤니케이션(발신자 신원 확인 및 브랜드 표시) 솔루션을 운영하는 기업이다. 미국 내에서는 T-Mobile, Verizon, AT&T, Boost Mobile과 같은 대형 사업자와 협력하며, 영국 Vodafone과 독일 Deutsche Telekom 등으로 서비스 범위를 확장해 글로벌 익스체인지(Global Exchange)를 구축했다. 이들은 기업이 브랜디드 콜링과 메시징, 정체성 솔루션을 통해 고객과 연결되도록 돕는 동시에 스팸이나 스캠, 스푸핑으로부터 양측 모두를 보호하는 서비스를 제공한다. 고객층 역시 소규모 사업자부터 포춘 500대 기업까지 매우 넓으며, 서비스 대상 국가와 통신사 환경이 다양해질수록 검증해야 할 접점은 기하급수적으로 늘어날 수밖에 없다.

기술적 임계점은 시스템 아키텍처를 전환하는 과정에서 명확해졌다. 기존의 거대한 단일 구조인 모놀리식 포털에서 제품별로 기능을 쪼갠 모듈형 셀 기반 아키텍처로 전환하면서 관리하고 검증해야 할 웹 애플리케이션의 절대적인 수가 급증했다. 여기에 SMB(중소기업) 시장으로 고객군을 공격적으로 확장하며 테스트해야 할 디바이스 폼팩터와 브라우저 버전의 조합이 크게 늘어났다. 모바일과 데스크톱을 아우르는 다양한 화면 크기와 브라우저 엔진에서 동일한 사용자 경험을 보장해야 하는 물리적 제약이 추가되었고, 이는 곧 테스트해야 할 시나리오의 폭발적인 증가로 이어졌다.

결국 기존의 스크립트 기반 QA 방식은 개발 속도를 따라가지 못하는 결정적인 병목 지점이 되었다. UI 요소의 위치나 속성이 조금만 바뀌어도 테스트 스크립트가 즉시 파손되는 특성 때문에, 개발자가 기능을 수정하면 QA 담당자는 깨진 셀렉터를 다시 찾아 수정하는 단순 반복 작업에 매몰되었다. 이 과정에서 테스트 케이스의 누락이 발생하고, 이미 해결된 버그가 다시 나타나는 회귀 버그가 증가하며 전체 릴리스 주기가 정체되는 현상이 발생했다. First Orion은 UI 탐색 경로를 코딩하는 대신, 무엇을 테스트할지 자연어로 설명하면 에이전트가 화면을 인식해 처리하는 구조로의 전환이 시급하다고 판단했다.

React에서 Bedrock Browser까지의 자동화 파이프라인

QA 분석가는 React로 구축된 Test Case Authoring UI에서 자연어로 테스트 시나리오를 생성하고 편집하며 검증하는 과정을 거친다. 이 도구는 복잡한 스크립트 작성 없이 평문으로 동작을 정의할 수 있게 하며, 내부의 커스텀 템플릿 엔진이 전화번호, 이메일 주소, 사업자명 같은 동적 변수를 처리한다. 템플릿 엔진은 매 실행 시마다 고유하고 실제적인 데이터를 생성해 동일한 테스트 컬렉션이라도 매번 다른 데이터 세트로 검증하게 만든다. 이는 테스트 데이터의 중복을 막고 실제 사용자 환경과 유사한 변동성을 확보해 테스트의 정밀도를 높이는 장치가 된다. 결과적으로 전문 개발 지식이 없는 QA 분석가가 직접 테스트 설계의 전 과정을 주도할 수 있는 환경을 구축했다.

작성 완료된 테스트 컬렉션은 JSON 형식의 문서로 변환되어 Amazon S3에 저장되며, 이곳이 전체 시스템의 중앙 저장소 역할을 수행한다. 테스트 정의를 코드 내에 하드코딩하지 않고 S3라는 외부 저장소에 JSON 형태로 분리함으로써, 테스트 케이스의 수정이나 업데이트가 실행 엔진의 재배포 없이 즉각적으로 반영된다. 여러 제품 팀이 동일한 테스트 세트를 공유하거나 특정 버전의 테스트 케이스를 빠르게 호출할 수 있는 구조적 기반이 된다. 데이터 저장소와 실행 로직을 완전히 분리한 설계는 테스트 시나리오의 관리 효율성을 극대화하고 파이프라인의 유연성을 확보하는 핵심 요소다.

QA 분석가가 테스트 실행을 트리거하면 Amazon ECS와 AWS Fargate 위에서 구동되는 Nova Act Test Runner가 S3에서 해당 JSON 파일을 가져와 실행을 시작한다. 이 러너는 Python 기반의 애플리케이션으로, Amazon Nova Act SDK를 사용하여 자연어 지시문을 실제 브라우저 동작으로 변환하는 오케스트레이션을 담당한다. 특히 서버 관리 부담이 없는 AWS Fargate 환경을 채택해, 테스트 케이스의 양이 급증하거나 병렬 실행이 필요할 때 컴퓨팅 자원을 자동으로 확장해 대응한다. 인프라의 프로비저닝과 관리를 AWS에 맡김으로써 엔지니어는 러너의 로직 최적화와 테스트 정확도 향상에만 집중할 수 있는 실무 환경을 만들었다.

실제 웹 페이지와의 상호작용은 Nova Act Test Runner가 직접 처리하지 않고 Amazon Bedrock AgentCore Browser에 모든 브라우저 작업을 위임하는 방식으로 작동한다. AgentCore Browser는 테스트 실행에 최적화된 관리형 브라우저 인스턴스를 즉시 할당하고, 실행되는 모든 세션의 과정을 녹화해 기록으로 남긴다. 기존의 Selenium이나 Playwright 환경에서 겪었던 브라우저 드라이버 버전 충돌이나 OS별 렌더링 차이 같은 환경 설정 문제를 관리형 서비스 도입으로 완전히 제거했다. 브라우저 인스턴스의 생명주기 관리와 세션 기록을 자동화함으로써, 테스트 실패 시 정확한 시점의 화면을 확인하고 원인을 분석하는 디버깅 속도를 획기적으로 높였다.

DOM 셀렉터 기반 스크립트 vs AI 에이전트 추론

기존의 Selenium(셀레늄)이나 Playwright(플레이라이트) 기반 자동화는 DOM(Document Object Model, 웹 페이지의 구조적 표현)의 ID나 클래스 같은 명시적 셀렉터를 지정해야 했으며, UI가 조금만 바뀌어도 스크립트가 즉시 파손되는 제약이 있었다. QA 자동화 엔지니어는 대개 개발자가 코드를 모두 마친 후 릴리스 직전에야 애플리케이션을 전달받아 테스트를 시작했다. 이 시점에서 요소 ID나 JavaScript 속성이 조금만 변경되어도 기존에 작성한 스크립트는 요소를 찾지 못해 작동을 멈췄다. 엔지니어가 개발자 도구로 바뀐 셀렉터를 찾아 일일이 수정하는 속도가 UI 변경 속도를 따라가지 못해 결국 전체 릴리스 일정이 밀리는 현상이 반복되었다.

Amazon Nova Act는 UI의 구체적인 경로를 코딩하는 대신 무엇을 할지 지시하는 자연어 기반 방식으로 동작한다. 예를 들어 빌링 페이지로 이동해 송장 합계를 확인하라는 지시문을 입력하면 AI 에이전트가 화면을 직접 분석해 수행한다. 이 과정에서 특정 CSS 클래스 명칭이나 복잡한 XPath에 의존하지 않고 레이블, 레이아웃, 컨텍스트를 통해 화면 요소를 인식한다. 제출 버튼의 클래스 이름이 내부적으로 바뀌더라도 버튼의 위치와 텍스트, 주변 요소와의 관계라는 맥락을 통해 클릭 동작을 그대로 유지한다.

동적 콘텐츠 처리와 예외 상황 대응 능력에서도 기존 방식과 뚜렷한 차이를 보인다. 기존 스크립트는 예상치 못한 안내 팝업이 뜨거나 콘텐츠 로딩 순서가 미세하게 바뀌면 즉시 에러를 내며 실행이 중단되었다. Nova Act는 실행 중 화면을 가리는 불필요한 팝업을 스스로 인식해 제거하거나, 일시적인 네트워크 지연으로 에러가 발생했을 때 스스로 복구 경로를 찾아 다시 시도하는 동작을 수행한다. 사람이 웹 브라우저를 사용하는 방식과 유사하게 화면의 시각적 변화에 유연하게 대응하며 테스트 시나리오를 끝까지 완수한다.

단순한 자연어 지시를 넘어 정밀한 제어가 필요한 구간에는 Python 코드를 직접 삽입해 하이브리드 형태로 운영한다. Nova Act 명령 사이에 어설션(Assertion, 기대 결과와 실제 결과가 일치하는지 확인하는 검증 단계)을 배치해 화면에 표시된 금액이 데이터베이스의 값과 일치하는지 정밀하게 검증한다. 또한 중단점(Breakpoint, 코드 실행을 일시 정지하고 상태를 확인하는 지점)을 설정해 특정 단계에서 AI의 추론 상태를 점검하거나, 여러 테스트 케이스를 동시에 실행하는 병렬 처리 로직을 결합해 전체 테스트 수행 시간을 단축한다. AI의 유연한 추론 능력과 프로그래밍의 엄격한 제어권을 결합해 테스트의 신뢰도를 확보했다.

QA 분석가와 개발자의 워크플로 변화

QA 분석가는 이제 DOM(문서 객체 모델, 웹 페이지의 구조를 정의하는 인터페이스) 요소가 확정되기 전에도 자연어로 테스트 케이스를 먼저 작성한다. 기존에는 새로운 기능의 테스트를 작성하려면 해당 기능이 먼저 개발되어 테스트 환경에 배포되어야만 했다. 그래야만 QA 자동화 엔지니어가 스크립트 작성에 필요한 셀렉터나 레이블 같은 구체적인 식별자를 확보할 수 있었기 때문이다. 개발 완료 시점과 테스트 작성 시점이 완전히 분리되면서 테스트 케이스 갭이 사라졌다. 기획 단계의 요구사항을 즉시 실행 가능한 시나리오로 옮기는 워크플로가 가능해지며 개발자가 코드를 작성하기 전에도 QA 팀이 검증 기준을 확립할 수 있게 되었다.

QA 엔지니어는 셀렉터 확인을 위해 개발 완료를 기다리며 다른 업무로 전환하던 컨텍스트 스위칭(작업 전환 시 발생하는 인지적 비용) 낭비를 제거했다. 수많은 기능이 짧은 주기로 출시되는 환경에서 배포 대기 시간 동안 다른 업무로 주의를 돌렸다가 다시 돌아오는 과정은 심각한 인지 부하를 일으켰다. 특히 여러 기능의 배포 순서가 복잡하게 얽혀 있을 때 발생하는 의존성 관리 문제는 팀 전체의 릴리스 속도를 늦추는 결정적인 원인이었다. 이제는 개발 진행 상황과 무관하게 테스트 정의를 마칠 수 있어 불필요한 대기 시간이 사라졌다. 대기 시간의 소멸은 QA 엔지니어가 테스트 시나리오의 논리적 완결성에 더 집중할 수 있는 환경을 만들었다.

개발자는 테스트 환경에 정식 배포하기 전 자신이 수정한 경로에 대해 직접 회귀 테스트(기존 기능이 새 수정으로 인해 망가지지 않았는지 확인하는 검사)를 실행한다. 이전에는 수정 사항을 배포한 뒤 QA 팀이 구축한 자동화 스크립트의 결과가 나올 때까지 기다려야만 결함 여부를 알 수 있었다. 이제는 개발자가 스스로 테스트를 수행하는 자가 서비스 체계가 구축되어 배포 전 단계에서 1차 검증이 이루어진다. 수정 직후 즉시 피드백을 받는 구조로 바뀌면서 버그 수정 사이클이 짧아졌고, 이는 개발자의 심리적 안정감으로 이어졌다. 개발자가 직접 테스트를 돌려보는 습관이 정착되며 단순 실수로 인한 회귀 버그가 배포 단계로 넘어가는 빈도가 줄었다.

UI 변경 시마다 스크립트를 일일이 수정하던 수작업은 AI의 UI 추론으로 대체되었다. CSS 클래스나 ID 같은 명시적 셀렉터가 변경되어도 AI가 레이블과 레이아웃, 컨텍스트를 통해 화면을 스스로 인식하므로 테스트가 중단되지 않는다. 기존의 자동화 프레임워크는 UI의 작은 변화에도 스크립트가 즉시 파손되어 이를 복구하는 데 막대한 시간이 소요되는 취약한 구조였다. 이제 유지보수 인력이 단순한 코드 수정에 쏟던 에너지를 테스트 시나리오의 엣지 케이스를 발굴하는 고부가가치 업무로 전환했다. 결과적으로 UI의 외형적 변화가 테스트 자동화의 장애물이 되지 않는 환경이 구축되었다.

한국 AI 실무자를 위한 도입 판단 기준

UI 변경이 잦은 대규모 웹 포털이나 다양한 브라우저 환경 대응이 필수적인 B2B 솔루션이 에이전트 기반 QA의 주 적용 대상이다. 기존의 셀렉터 기반 방식은 HTML 구조가 조금만 바뀌어도 테스트가 실패하며 이를 수정하는 데 많은 시간이 소요된다. 특히 고객사마다 서로 다른 설정값이 적용되어 UI 구성이 미세하게 달라지는 B2B 환경에서는 기존 방식의 한계가 더 명확하게 드러난다. 브라우저 버전이나 폼팩터가 다양해질수록 각 환경에 맞는 셀렉터를 개별 관리하는 비용은 기하급수적으로 증가하기 때문에 자연어로 동작을 지시하는 방식이 실질적인 대안이 된다.

도구의 변화는 QA 조직 내부의 역할 정의를 다시 세우는 과정으로 이어진다. DOM(문서 객체 모델, 웹 페이지의 구조를 트리 형태로 나타낸 것)에서 정확한 ID나 클래스 값을 찾아내는 자동화 엔지니어의 비중은 줄어든다. 대신 어떤 사용자 경로가 비즈니스적으로 중요한지 정의하고 테스트 시나리오를 정교하게 설계하는 QA 분석가의 역량이 핵심이 된다. 기술적인 구현보다 서비스의 논리적 흐름을 검증하는 기획적 관점이 테스트의 품질을 결정하는 구조로 바뀐다. 이는 엔지니어가 코드 수정에 쏟던 시간을 시나리오 고도화와 엣지 케이스 발굴에 투입함으로써 제품의 전체적인 완성도를 높이는 결과로 이어진다.

자연어 지시문은 편리하지만 지시 내용이 모호할 경우 테스트 결과의 불확실성이 높아지는 위험이 있다. 에이전트가 지시문을 자의적으로 해석해 잘못된 요소를 클릭하거나 예상치 못한 경로로 진입할 가능성이 존재한다. 이를 방지하기 위해 최종 검증 단계에서는 Python 어설션(Assertion, 조건이 참인지 확인하는 구문)을 통한 명시적 검증 과정을 병행해야 한다. 예를 들어 자연어로 송장 페이지 이동을 지시한 뒤 실제 화면에 나타난 합계 금액이 기대값과 일치하는지는 Python 코드로 정확히 확인하는 식이다. 자연어로 흐름을 제어하되 결과값의 정확성은 코드로 확정 짓는 하이브리드 방식이 실무적인 안정성을 보장한다.

에이전트 기반 QA 도입 시점을 결정하는 정량적 기준은 유지보수 비용의 역전 현상이다. 기존 스크립트의 깨진 셀렉터를 찾아 수정하는 시간이 새로운 테스트 케이스를 작성하는 시간보다 많아지는 시점이 전환의 적기다. 단순한 도구 교체가 아니라 운영 비용의 구조를 바꾸는 결정이므로 현재 팀이 겪는 병목이 코드 수정에 있는지 시나리오 부족에 있는지 먼저 파악해야 한다.

스크립트 수정 시간이 신규 케이스 작성 시간을 앞지르는 시점에 에이전트 기반 QA로 전환하라.