전문 지식 제로에서 생성 AI와 대화하며 브라우저 테스트를 자동화한 이야기

업무 시스템의 릴리스 전 회귀 테스트 (Regression Test)를 Playwright (브라우저 자동 조작 도구)로 자동화한 개인적인 노력의 기록입니다.

포인트는 "Playwright도 자동 테스트도 미경험인 상태에서, 생성 AI (Claude)와 일본어로 대화하며 만들었다"는 점입니다.

※ 특정 회사명, 시스템명, 업무 내용은 숨기고 일반화하여 작성했습니다.

개요

신청 업무 계열의 Web 앱에서,
**매주 릴리스 전에 수동 회귀 테스트 (Regression Test)**를 수행하고 있었음 - 하나의 신청이 여러 역할(신청자 → 중간 승인 → 최종 승인)을 거치는
**승인 플로우 (Approval Flow)**로 인해 조합이 많아 번거로웠음 - Playwright로
로그인 ~ 신청 ~ 각 역할에서의 승인/부인 ~ 통지까지를 자동화 - 코드는
생성 AI와의 대화로 생성 및 수정. 전문 지식이 없어도 "하고 싶은 것을 언어화"할 수 있다면 형태를 만들 수 있었음 - 입력 데이터를
외부 JSON으로 분리하고, 직접 만든 Chrome 확장 프로그램으로 실제 화면에서 데이터를 추출하는 메커니즘도 마련

1. 배경: 무엇이 힘들었나

대상은 여러 조직과 역할을 거쳐 승인이 진행되는 신청 업무 계열의 Web 앱입니다.

과제	내용
공수	「서류 종류 × 승인 패턴」의 곱셈으로 인해, 매번 다수의 수동 조작이 필요
...
「사람이 하지 않아도 되는 작업」의 전형으로, 자동화 효과가 나타나기 쉬운 영역이었습니다.

2. 만든 것

시스템 본체에는 일절 손을 대지 않고, 외부에서 브라우저를 조작하는 독립된 테스트 자산을 구축했습니다.

대상 조작: 로그인 → 폼 입력 → 첨부 → 신청 → 각 역할에서의 승인/부인/통지 → 로그아웃 -
승인 패턴: 실제 운용에서 수행하는 대표적인 플로우를 여러 개 준비 (정상 승인, 부인 → 재신청, 회수 → 삭제, 사퇴 등)

테스트 플로우 예시

플로우	검증 내용
신청 → 승인 → 최종 승인 → 통지	정상계 (최단 승인)
...
현시점에서는 일부 플로우와 폼에서 동작 확인을 마쳤습니다. 나머지는 틀을 마련한 후 순차적으로 검증을 넓혀가는 단계입니다.

3. 메커니즘

┌─────────────┐ ┌──────────────┐ ┌─────────────────┐
│ 테스트 데이터 │ → │ Playwright │ → │ 대상 Web 앱 │
│ (JSON/첨부) │ │ (조작의 실체) │ │ (실제 화면) │
...

설계에서 의식한 점은 3가지입니다.

입력 데이터의 재사용— 테스트 데이터를 코드에 내장하지 않고 외부 JSON으로 분리. 코드 내용을 몰라도 데이터 교체만으로 케이스를 변경할 수 있도록 했다. -
화면 구조 변화에 강한 구조— 버튼이나 입력란을 「고정된 좌표나 XPath」가 아닌 라벨 문구로 찾는 방식으로 접근하여, UI 개수 시에도 잘 깨지지 않게 했다. -
환경 스위치— 로컬 / 검증 / 운영을 환경 변수 하나로 전환 (Basic 인증도 자동 응답).

구성

부품 (로그인, 입력, 첨부, 승인…)과 이를 조합한 「플로우 (Flow)」를 분리했습니다.

새로운 승인 패턴은 부품의 조합으로 만들 수 있으므로 유지보수하기 쉬운 구성이 되어 있습니다.

project/
├─ config.js … 계정, 환경, 폼의 일원 관리
├─ flows/ … 테스트 플로우 (부품을 조합하기만 하면 됨)
...

4. 보조 도구: 직접 만든 Chrome 확장 프로그램

테스트 데이터 (입력 JSON)를 준비하는 작업을 편하게 하기 위해, Chrome 확장 프로그램도 직접 제작했습니다 (이 또한 생성 AI와의 대화로 작성).

단축키 2개뿐인 심플한 것입니다.

조작	기능	용도
Alt + 2	현재 표시 중인 화면의 입력값을 전부 JSON으로 내보내기	실제 화면에 수동 입력 → 그대로 테스트 데이터화
Alt + 1	준비된 JSON을 화면의 폼에 일괄 입력	수동 입력을 순식간에 재현 (동작 확인 및 디버깅에도 편리)

약간의 기술적 난관

대상이 React로 제작된 폼인 경우, 단순히 value를 바꾸는 것만으로는 값이 반영되지 않습니다. React가 "자신이 관리하지 않는 변경"을 감지하여 원래대로 되돌려 버리기 때문입니다.

그래서 React의 내부 값 트래커 (_valueTracker)를 경유하여 값을 업데이트하고, input 이벤트를 발생시킴으로써 화면 측에 확실히 반영되도록 했습니다.

const setter = Object.getOwnPropertyDescriptor(
HTMLInputElement.prototype, "value"
).set;
...

이 부분 역시 "왜 값이 사라지는가"에 대해 생성 AI (Generative AI)와 상담하며 해결해 나갔습니다.

5. 생성 AI와 직접 만들어보며 느낀 점

이번 시도를 통해 가장 전달하고 싶은 것은, 자동화의 진입 장벽이 크게 낮아지고 있다는 사실입니다.

Playwright의 작성법을 사전에 공부할 필요가 없었다
"이런 테스트를 하고 싶다"라고 일본어(한국어)로 전달하는 것이 주요 작업이었다. 코드를 쓰는 것보다 "무엇을 테스트하고 싶은지를 언어화하는 것"에 시간을 사용했다.
에러가 발생해도 로그를 붙여넣고 상담하면 원인과 수정안이 돌아온다.
"React 폼에 값이 입력되지 않는다"와 같이, 스스로는 원인을 찾아내기 어려운 난관도 돌파할 수 있었다.

이를 뒤집어 생각하면, 도구나 언어에 대한 지식 그 자체보다 "테스트 대상이 되는 업무와 확인하고 싶은 내용을 정리하는 능력"이 더 중요해진다는 감각이었습니다.

6. 어떤 프로젝트에 적합한가

이 접근 방식이 효과적인 경우는 다음과 같습니다.

Web 앱인 경우 (Playwright는 브라우저 조작 도구임)
정형화된 반복 조작이 있는 경우 (릴리스 전 확인, 상시 체크 등)
입력 항목이 많을수록 / 승인 플로우가 길수록 자동화의 효용이 큼

반대로, 화면이 빈번하게 크게 바뀌는 단계나, 조작이 매번 달라지는 탐색적 테스트(Exploratory Testing)는 자동화보다 수작업이 더 적합합니다.

재사용 가능한 설계의 고안

고안 사항	효과
본체 리포지토리와 분리	대상 시스템을 건드리지 않고 도입할 수 있음
...

솔직한 현황 및 과제

동작 확인이 완료된 것은 일부 플로우와 일부 폼뿐임. 나머지는 검증 범위를 넓혀가는 단계
라벨 문구로 요소를 찾기 때문에, 문구가 변경될 때는 데이터 측의 추종이 필요함
일부 특수한 폼(서브 화면 분할, 다중 파일 첨부 등)은 개별적인 구현이 필요함
CI (지속적 통합, Continuous Integration)에는 연결되지 않았으며, 현재는 로컬 실행을 전제로 함

7. 요약

"본체를 건드리지 않고, 명령어 하나로" 매주 진행하던 수동 회귀 테스트 (Regression Test)를 자동화하려는 시도.

가장 큰 포인트는 생성 AI와의 대화를 통해 전문 지식 제로 상태에서 착수할 수 있었다는 점입니다.

"자동 테스트는 허들이 높다"라고 느끼는 사람일수록, 한 번쯤 시도해 볼 가치가 있다고 생각합니다.

이번 시도의 목표는 "조작의 자동화"였습니다.

다만, 사내 공유를 통해 피드백을 받으면서,

"자동으로 움직이는 것"과 "올바르게 움직이는 것"은 별개다라는 사실을 깨달았습니다.

다음 단계는 각 스텝이 완료된 후 기대값과 대조하는 어서션 (Assertion, 타당성 검사)의 추가입니다.

"신청이 완료되었을 텐데, 사실은 에러였다"라는 상황을 감지할 수 있는 메커니즘을 만들어 나갈 것입니다.

속편도 작성할 예정이니, 관심이 있다면 팔로우해 주시면 감사하겠습니다.