Asuene 주식회사에서 엔지니어로 근무하고 있는 타시로입니다!

이번에는 AI 코딩 에이전트(AI Coding Agent)를 전제로 한 E2E 테스트 설계에 대해 쓰겠습니다.

서론

AI 코딩 에이전트를 사용하기 시작하면서 개발 속도는 올라갔습니다.

하지만 품질 보증(QA)이 개발 속도를 따라가고 있느냐 하면 그렇지 않은 경우도 있다고 생각합니다.

이 상황을 바꾸기 위해 E2E 테스트 정비를 시작했는데, 단순히 "E2E 테스트를 작성한다"가 아니라, AI에게 작성 및 업데이트를 맡기는 것을 처음부터 전제로 하여 설계했습니다.

이 기사에서는 그 설계, 특히 테스트 케이스의 관리 방법과 인간과 AI의 리뷰 분담에 대해 쓰겠습니다.

전제로, 저희 프로덕트는 프론트엔드와 백엔드가 분리된 구성의 Web 애플리케이션이며, E2E 테스트는 제로 베이스에서 시작했습니다.

크리티컬 유저 저니(Critical User Journey)에 집중하지 않기로 한 판단

E2E 테스트의 이론(Theory)으로서, 테스트 케이스는 크리티컬 유저 저니에 집중해야 한다는 생각이 있습니다.

이는 E2E 테스트가 단위 테스트(Unit Test)나 통합 테스트(Integration Test) 등에 비해 작성 및 유지보수 비용이 높기 때문입니다.

하지만 이번에는 E2E 테스트의 테스트 케이스를 크리티컬 유저 저니에 한정하지 않고, 정상계(Happy Path)를 넓게 커버하는 방침으로 정했습니다.

이유는 AI에 의해 테스트 작성 비용이 낮아졌기 때문입니다.

이 이론은 비용이 높다는 것을 전제로 한 것이므로, 전제가 바뀌면 이야기도 달라집니다. AI로 작성 및 유지가 돌아가는 메커니즘을 먼저 만들고, 그 위에서 넓게 확보하기로 했습니다.

그렇다고 전부 다 쓰는 것은 아니며, 대상은 정상계로 한정하고 있습니다. 이상계(Edge Case)까지 포함하면 케이스 수가 방대해지므로, 우선은 주요 기능이 정상적으로 작동한다는 것을 담보하는 것을 우선시하고 있습니다.

E2E 테스트에서 정상계를 넓게 커버하는 방침을 채택할 경우, 흔히 채택되는 테스트 피라미드(Test Pyramid)와 비교하면 테스트 피라미드보다 E2E 테스트의 범위가 늘어나므로, 삼각형보다는 사다리꼴이 되는 이미지입니다.

테스트 케이스는 Gherkin 구문으로 작성하고, YAML로 관리한다

이번 설계의 중심은 테스트 케이스의 관리 방법입니다. 테스트 케이스는 Gherkin 구문(Given / When / Then)으로 기술하고, YAML 파일로 관리하고 있습니다.

# test-cases/report-export.yaml
- id: TC-0012
feature: 리포트 출력
...

셀렉터(Selector)나 API 엔드포인트(Endpoint)와 같은 시스템 측의 용어는 나오지 않습니다.

자연어이므로, 사용자 관점 그대로 리뷰나 관리가 가능합니다.

.feature 파일이 아닌 YAML을 선택한 이유

Gherkin이라면 Cucumber 계열의 .feature 파일이 표준이지만, 이번에는 YAML을 채택했습니다.

YAML을 채택한 이유는, ID나 태그, 우선순위와 같은 메타데이터를 시나리오와 동일한 계층에서 구조적으로 가질 수 있다는 점과 스키마 검증(Schema Validation)을 할 수 있다는 점 때문입니다.

스키마 검증을 할 수 있음으로써, AI 에이전트가 생성한 테스트 케이스에 대해 ID 중복이나 필수 필드 누락을 기계적으로 걸러낼 수 있습니다.

이를 통해 생성물을 인간이 육안으로 형식 체크를 할 필요가 없어져, 리뷰 부하를 낮출 수 있습니다.

테스트 케이스 ID와 테스트 코드의 연결

각 테스트 케이스의 ID는 Playwright의 태그(Tag)로 테스트 코드와 연결하고 있습니다.

test(
'관리자가 연차 리포트를 PDF로 출력할 수 있다',
{ tag: '@TC-0012' },
...

테스트 케이스 ID와 테스트 코드를 연결함으로써, YAML 측의 목록과 코드 측의 태그를 기계적으로 대조할 수 있습니다.

아직 구현되지 않은 테스트 케이스나, 반대로 대응하는 케이스가 사라졌는데 남아 있는 테스트 코드를 검출할 수 있습니다.

테스트 케이스와 테스트 코드가 조금씩 괴리되어 가서, 정신을 차려보니 둘 다 신용할 수 없게 되어 있다는 것은 E2E 운용의 흔한 사례(Common Pitfall)라고 생각합니다.

이 부분을 인간의 주의력에 의존하지 않고, ID 대조를 통해 기계적으로 방지하도록 했습니다.

--grep @TC-0012

와 같이 특정 테스트를 개별 실행할 수 있는 것도 편리합니다.

리뷰는 인간이 사양을 보고, AI가 코드를 본다

AI에게 테스트를 생성하게 하면, 생성된 것을 누가 리뷰할 것인가라는 문제가 반드시 발생합니다.

전부 인간이 읽는다면, AI로 작성 비용을 낮춘 의미가 반감됩니다.

이번에는 테스트 케이스(YAML)는 인간이 중점적으로 리뷰하고, 테스트 코드는 AI 리뷰를 메인으로 하되 인간은 보조적으로 확인하는 방식으로 역할을 분담하고 있습니다.

테스트 케이스의 정확성은 "사양으로서 올바른가"의 문제이므로, 프로덕트의 맥락을 알고 있는 인간만이 판단할 수 있습니다.

반면, 테스트 코드의 정확성은 "테스트 케이스에 충실하게 구현되었는가"라는 대조 작업이므로, AI가 잘하는 영역입니다.

자연어로 테스트 케이스를 관리함으로써 이러한 분담이 용이해집니다.

인간이 리뷰해야 할 대상이 인간에게 가장 읽기 쉬운 형식으로 되어 있기 때문입니다.

병렬 실행 관련 데이터 설계

범위를 넓게 커버하면 테스트 수가 늘어나므로 실행 시간 문제가 발생합니다. 병렬 실행으로 대응하고 있으며, 이를 뒷받침하는 데이터 설계에 대해 간단히 언급해 두겠습니다.

먼저, 시스템을 사용하는 데 있어 최소한으로 필요한 기초 데이터를 사전에 준비해 두어, 각 테스트가 매번 처음부터 데이터를 구성하지 않도록 하고 있습니다.

그 위에서 각 테스트는 데이터의 생성부터 삭제까지 자기 완결적(Self-contained)으로 수행하여, 실행 전후의 상태가 변하지 않도록 하고 있습니다.

이를 통해 병렬 실행을 하더라도 서로 간섭하기 어렵게 만들었습니다.

그럼에도 영향을 받기 쉬운 테스트는 Playwright의 프로젝트를 분리하여 단독으로 실행할 수 있도록 했습니다.

테스트 데이터 생성은 SQL을 직접 호출하는 것이 아니라 API를 경유하도록 했습니다.

실제 유스케이스(Use case)에 가까운 형태로 데이터가 생성되며, 스키마(Schema)가 변경되어도 API가 흡수해주기 때문에 유지보수가 편리합니다.

이 설계는 사내 테크 리드(Tech Lead) 분이 추진하셨던 설계를 참고했습니다!

(이 자리에서 다시 한번 감사드립니다! 🙇♂️)

마치며

E2E 테스트의 세계에는 오랜 세월 이어져 온 몇 가지 이론이 있지만, 그 상당수는 "E2E 테스트는 작성 및 업데이트 비용이 높다"라는 전제 위에 성립되어 있습니다.

하지만, AI 코딩 에이전트(AI Coding Agent)의 등장으로 인해 그 전제는 변하고 있다고 생각합니다.

테스트 케이스의 YAML 관리와 ID 매핑, 정상계(Normal case)의 광범위한 커버리지, 병렬 실행 메커니즘은 실제로 운용하고 있지만, 아직 검토 중인 부분도 있습니다.

향후에는 AI 코딩 에이전트를 통한 테스트 케이스 및 테스트 코드의 정기적인 자동 업데이트를 진행할 예정입니다.

AI를 전제로 한 E2E 테스트 설계에 대해 비슷한 한계(Deadlock)를 느끼고 있는 팀이 있다면, 이 설계가 참고가 되기를 바랍니다.

마지막으로, Asuene에서는 함께 일할 엔지니어를 모집하고 있습니다!

관심이 있으시다면 우선 이야기라도 나누어 보고 싶으니, 많은 지원 부탁드립니다!

Discussion