AI가 테스트 코드를 써도 E2E 테스트의 실행·조합 부담은 남는다

본문

블로그 ‘若くない何かの悩み’의 Kuniwak(id:devorgachem)은 E2E 테스트의 정의와 설계 방식을 정리한 글을 공개했습니다. 저자는 여러 프로젝트에서 E2E 자동화를 다룬 경험과 이론을 정리했다고 설명합니다. 글의 핵심 주장은 생성형 AI가 테스트 코드 작성 속도를 높여도 E2E 테스트의 실행·유지 부담과 조합 폭발은 남는다는 것입니다. 단위 테스트는 세부 로직을, E2E 테스트는 실제 구성요소의 연결과 대표 사용자 흐름을 맡기는 방식을 제안합니다. 글은 개인 기술 에세이이며, 일부 용어와 분류는 저자가 기존 이론을 바탕으로 정리·확장한 정의입니다.

Kuniwak이 정의하는 E2E 테스트는 이용자가 접하는 인터페이스에서 시작해 데이터베이스 같은 지속성 계층까지 시스템 구성요소를 연결하고, 인터페이스를 통해 동작과 결과를 확인하는 방식입니다. 인터페이스는 웹 애플리케이션의 화면일 수도 있고 API 서비스의 공개 엔드포인트일 수도 있습니다. 조직이 관리하는 백엔드와 데이터베이스, 워커는 실제 구현을 연결합니다. 외부 결제 서비스나 인증 제공자처럼 조직이 통제하지 않는 구성요소는 스텁이나 모크로 대체할 수 있습니다. E2E 테스트의 경계는 화면 조작 여부보다 공개 인터페이스에서 지속성 계층까지 연결하는 범위에 있습니다. 백엔드와 연결하지 않은 컴포넌트의 스크린샷 비교는 UI 테스트에 해당하고, 화면 조작 없이 API 요청의 응답과 저장 결과를 검사하는 테스트는 E2E가 될 수 있습니다.

E2E 테스트가 단위 테스트를 대체하기 어려운 이유는 검사 범위가 다르기 때문입니다. 개별 구성요소가 각자 정해진 입력을 처리해도 구성요소 사이의 전제와 출력이 맞지 않으면 연결된 시스템에서 오류가 생길 수 있습니다. 글은 세 변의 길이로 삼각형의 종류를 판별하는 예를 듭니다. 입력 검증기는 문자열에서 자연수 세 개를 읽어 다음 단계로 전달하고, 분류기는 그 값이 오름차순으로 정렬됐다고 전제해 삼각형 여부와 종류를 판정합니다. 입력 5, 1, 1은 짧은 두 변의 합이 2여서 삼각형을 만들 수 없지만, 정렬되지 않은 값이 분류기에 전달되면 분류기는 5+1>1이라는 조건을 통과하고 이등변삼각형이라고 잘못 답할 수 있습니다. 각 구성요소의 단위 테스트가 통과해도 입력과 출력의 계약이 맞지 않는 문제는 결합된 흐름에서 드러납니다. 저자는 이런 불일치를 E2E 테스트가 찾아낼 수 있다고 설명하면서, 구성요소 명세 사이의 관계를 설계 단계에서 검토하면 구현 전에 발견할 수도 있다고 덧붙입니다.

반면 시스템 전체를 잇는 테스트는 실행과 유지에 부담이 따릅니다. Kuniwak은 단위 테스트가 케이스당 밀리초 수준인 데 비해 E2E 테스트는 브라우저 실행, 네트워크 통신, 프로세스 초기화와 화면 렌더링을 거쳐 수십 초 수준이 걸릴 수 있다고 설명합니다. 한 구성요소를 거치는 시나리오가 여러 개라면 해당 구성요소의 변경이 여러 E2E 테스트에 번질 수 있고, 네트워크 지연이나 비동기 작업 순서의 흔들림도 결과에 영향을 줍니다. 구성요소별 분기 조합을 E2E에서 모두 시험하려 하면 결합 수가 늘수록 필요한 테스트 조합도 불어납니다. 글은 AI가 테스트 코드를 더 빨리 작성해도 브라우저 실행 시간이나 환경의 불확실성, 조합 폭발은 해소되지 않는다고 주장합니다.

그래서 글은 세부 로직과 대표 흐름에 서로 다른 테스트를 배정합니다. 전자상거래 결제 사례에서는 일반 결제와 프리미엄 결제의 판정·할인 로직을 별도 전략으로 나누고 각 분기를 단위 테스트로 확인합니다. E2E에는 프리미엄 회원으로 로그인했을 때 프리미엄 결제 경로가 선택되는 대표 시나리오를 둡니다. 단위 테스트가 각 로직의 여러 경우를 확인하는 동안 E2E는 실제 연결을 거쳐 중요한 흐름이 이어지는지 살핍니다.

더 넓은 흐름을 탐색하는 방법으로 Kuniwak은 상태 전이 모델을 이용한 그래프 기반 테스트를 설명합니다. 모델은 어떤 상태에서 어떤 동작으로 다음 상태에 갈 수 있는지를 정합니다. 테스트는 실제 시스템에서 실행 가능한 동작과 거부되는 동작을 관찰해 모델의 전이와 대조한 뒤, 가능한 동작을 선택해 다음 상태로 이동하는 과정을 반복합니다. 이 모델은 테스트 입력이면서 개발자나 AI 에이전트가 구현을 진행할 때 참고하는 명세로도 쓰일 수 있습니다. 다만 탐색 알고리즘은 제한된 시간 안에 회원 가입부터 구매 완료까지 특정한 중요 흐름을 밟는다고 보장하지 않습니다. 저자는 탐색에 맡길 경로와 별도로 핵심 사용자 시나리오를 고정해 반복 실행하자고 제안합니다.

저자는 상태 모델을 작성할 여력이 있고 미지의 전이를 탐색하려는 팀에는 그래프 기반 테스트와 고정 시나리오를 함께 쓰는 구성을 제시합니다. 모델 작성이 어렵지만 과거 결함 기록이 있다면 오류가 잦았던 입력이나 경계값을 노리는 테스트와 핵심 시나리오를 조합하는 방법을 권합니다. 모델과 결함 기록이 모두 부족한 새 시스템에는 화면의 조작 가능한 요소를 자동으로 탐색하는 몽키 테스트를 핵심 시나리오와 병행하는 방안을 소개합니다. 이는 글에서 Kuniwak이 제시한 상황별 선택 기준입니다.

자료: 若くない何かの悩み / 정리·해설: Trawling