현대 소프트웨어 개발 환경에서 QA(Quality Assurance) 엔지니어와 개발자가 겪는 가장 큰 고통은 ‘테스트 코드의 유지보수’입니다. 특히 Playwright와 같은 강력한 E2E(End-to-End) 테스트 프레임워크를 사용할 때, 기능이 조금만 변경되어도 수많은 셀렉터가 깨지고 테스트 스크립트를 수정하는 데에만 수 시간이 소요됩니다. 우리는 더 나은 품질을 위해 테스트를 짜지만, 정작 그 테스트를 유지하기 위해 정작 중요한 기능 개발 시간을 뺏기는 역설적인 상황에 놓여 있습니다.

많은 팀이 자동화 테스트의 효율성을 높이기 위해 노력하지만, 대부분은 ‘어떻게 하면 더 효율적으로 코드를 짤까’라는 관점에 머물러 있습니다. 하지만 이제는 관점을 완전히 바꿔야 합니다. ‘어떻게 하면 코드를 짜지 않을 수 있을까?’라는 질문이 필요합니다. 단순히 코딩 보조 도구로 AI를 쓰는 수준을 넘어, 요구사항 정의서(Jira Ticket)를 읽고 직접 테스트 시나리오를 설계하며 PR(Pull Request)까지 생성하는 완전 자동화 파이프라인이 가능해졌기 때문입니다.

왜 우리는 Playwright 테스트 작성에 지쳤는가

Playwright는 매우 훌륭한 도구입니다. 하지만 E2E 테스트의 본질적인 한계는 ‘취약성(Fragility)’에 있습니다. UI의 작은 변경, 클래스 명의 수정, 혹은 비동기 처리의 미세한 타이밍 차이만으로도 테스트는 실패합니다. 개발자는 기능을 완성한 뒤 다시 테스트 코드를 수정하고, 이를 다시 커밋하는 반복적인 루프에 갇히게 됩니다.

특히 지라(Jira) 티켓에 적힌 기획 내용을 바탕으로 테스트 케이스를 도출하고, 이를 다시 코드로 옮기는 과정에서 발생하는 컨텍스트 스위칭 비용은 상상 이상입니다. 기획서의 문구를 해석하고, DOM 구조를 분석하고, 적절한 Assertion을 설정하는 이 모든 과정은 논리적 사고가 필요하지만, 동시에 매우 정형화된 반복 작업이기도 합니다. 바로 이 지점이 AI가 인간을 완전히 대체할 수 있는 최적의 영역입니다.

AI 기반 테스트 자동화의 핵심 메커니즘

단순히 Copilot에게 “로그인 테스트 코드 짜줘”라고 요청하는 것은 진정한 자동화가 아닙니다. 진정한 혁신은 AI가 개발 프로세스의 ‘맥락(Context)’을 완전히 이해하고 스스로 움직이게 하는 것입니다. 이를 위해 다음과 같은 워크플로우가 구축되어야 합니다.

• 컨텍스트 주입: AI가 현재 프로젝트의 코드베이스, 기존 테스트 패턴, 그리고 지라(Jira) 티켓의 API를 통해 요구사항을 직접 읽어오게 합니다.
• 시나리오 설계: 읽어온 요구사항을 바탕으로 ‘Given-When-Then’ 구조의 테스트 시나리오를 먼저 생성하고, 이를 인간이 검토하거나 AI가 스스로 검증하게 합니다.
• 코드 생성 및 실행: 설계된 시나리오를 Playwright 코드로 변환하고, 로컬 환경 혹은 CI 환경에서 실제로 실행하여 통과 여부를 확인합니다.
• PR 자동 생성: 테스트가 통과하면 변경 사항을 브랜치에 커밋하고, 지라 티켓 번호를 참조하여 PR을 생성합니다.

이 과정에서 GitHub Copilot의 Workspace나 커스텀 에이전트를 활용하면, 개발자는 코드를 한 줄도 쓰지 않고 “이 티켓에 맞는 테스트 케이스를 추가해줘”라는 명령어 하나만으로 전체 프로세스를 트리거할 수 있습니다.

기술적 구현의 득과 실: 냉정한 분석

물론 모든 자동화가 장점만 있는 것은 아닙니다. AI에게 테스트 작성을 맡겼을 때 얻는 이득과 감수해야 할 리스크를 명확히 구분해야 합니다.

가장 큰 위험은 ‘맹신’입니다. AI가 생성한 테스트가 통과했다고 해서 기능이 완벽하다는 뜻은 아닙니다. AI는 주어진 텍스트(지라 티켓)를 바탕으로 코드를 짜기 때문에, 만약 티켓 자체에 오류가 있거나 모호한 표현이 있다면 AI는 ‘틀린 요구사항을 완벽하게 구현한 테스트’를 만들어낼 것입니다.

실제 적용 사례: A사의 QA 혁신

최근 한 핀테크 기업에서는 매주 수십 개의 마이너 업데이트가 발생하는 환경에서 이 방식을 도입했습니다. 이전에는 개발자가 기능을 구현하고 QA 엔지니어가 이를 확인한 뒤 Playwright 스크립트를 짰습니다. 이 과정에서 평균 2일의 리드 타임이 발생했습니다.

이들은 GitHub Copilot과 Jira API를 연동한 커스텀 봇을 구축했습니다. 개발자가 지라 티켓 상태를 ‘In Progress’에서 ‘Review’로 변경하면, AI가 자동으로 티켓 내용을 분석해 테스트 코드를 생성하고 PR을 올립니다. 결과적으로 테스트 코드 작성에 소요되던 시간이 0에 수렴하게 되었으며, QA 엔지니어는 코드를 짜는 대신 ‘AI가 설계한 시나리오가 비즈니스적으로 타당한가’를 검토하는 전략적 리뷰어의 역할로 전환되었습니다.

지금 당장 실행할 수 있는 액션 아이템

갑자기 모든 프로세스를 AI에게 맡기는 것은 위험합니다. 단계적인 접근이 필요합니다. 실무자라면 다음의 단계로 시작해 보십시오.

• 1단계: 프롬프트 표준화 – 지라 티켓의 형식을 AI가 읽기 좋게 구조화하십시오. (예: 요구사항, 기대 결과, 테스트 데이터 명시)
• 2단계: Copilot Chat 활용 – 티켓 내용을 복사해 Copilot에게 주고 “이 요구사항을 Playwright 테스트 코드로 변환해줘”라고 요청하며 패턴을 학습시키십시오.
• 3단계: 테스트 템플릿 구축 – AI가 일관된 스타일로 코드를 짤 수 있도록 Page Object Model(POM)과 같은 표준 구조를 미리 정의하고 AI에게 가이드로 제공하십시오.
• 4단계: 파이프라인 자동화 – GitHub Actions나 Jenkins를 통해 AI 생성 코드가 자동으로 실행되고 결과가 보고되는 환경을 구축하십시오.

결론: 코더에서 오케스트레이터로

우리는 이제 ‘어떻게 코드를 짤 것인가’를 고민하는 코더(Coder)에서, AI가 생성한 결과물을 검증하고 전체 흐름을 설계하는 오케스트레이터(Orchestrator)로 진화해야 합니다. Playwright 테스트를 직접 작성하는 행위 자체는 가치 있을 수 있지만, 그것이 비즈니스 가치를 창출하는 핵심 활동은 아닙니다.

AI가 지라 티켓을 읽고 PR을 올리는 세상은 이미 왔습니다. 이 변화를 거부하는 것이 아니라, AI가 짠 코드를 어떻게 더 정교하게 검증하고 관리할 것인지에 집중하는 팀만이 진정한 개발 속도의 혁신을 이룰 수 있을 것입니다.