안녕하세요 👋 이곳에 올리는 첫 게시물입니다. QA 엔지니어로서 제가 만든 사이드 프로젝트를 공유하고 싶습니다. 왜냐하면 이 프로젝트가 우리 중 많은 이들이 느끼는 갈증을 해소해 주기 때문입니다.

그 갈증이란 이렇습니다: 단 하나의 비즈니스 흐름을 위해, 저는 결국 같은 것을 세 번 만들어야 했습니다 — Postman 컬렉션, Playwright API 테스트, 그리고 JMeter 플랜 말이죠. 요청도 같고, 변수도 같고, 단언(assertion)도 같은데, 단지 세 가지 다른 방식으로 타이핑할 뿐입니다. 이는 느리고 지루하며, 무언가 변경되는 순간 세 개의 복사본은 서로 어긋나기 시작합니다.

그래서 저는 이를 한 번에 처리하기 위해 **TestFlow Agent**를 만들었습니다. 이 도구는 두 가지 방식으로 작동하며, 저는 두 방식 모두를 설명해 드리고자 합니다. 왜냐하면 이들은 상당히 다른 두 가지 상황을 해결하기 때문입니다.

파트 1 — 본인의 서비스인 경우: 흐름을 설명하기만 하세요

첫 번째 모드는 테스트하려는 API를 직접 제어할 수 있는 경우를 위한 것입니다. 즉, 여러분 팀의 서비스이고, 엔드포인트(endpoint)를 알고 있으며, 어쩌면 같은 리포지토리(repo)에 있을 수도 있는 경우입니다.

이 경우, 아무것도 기록할 필요가 없습니다. 그저 평문 영어(plain English)로 테스트를 입력하기만 하면 됩니다:

텍사스 회원을 위한 등록(enrollment)을 생성합니다.
텍사스에서 사용 가능한 플랜을 가져옵니다. Silver 플랜을 선택합니다.
발효일 2026년 1월 1일로 등록을 제출합니다.
...

…그러면 TestFlow Agent가 의도(intent) — 상태, 플랜, 날짜, 그리고 이것이 해피 패스(happy path)인지 아니면 네거티브 케이스(negative case)인지 — 를 읽어내어 다음과 같은 API 시퀀스(sequence)를 생성합니다:

POST {{baseUrl}}/auth/token
POST {{baseUrl}}/members
GET  {{baseUrl}}/plans?state=TX
...

그로부터 Postman 컬렉션, Playwright 스펙(spec), 그리고 JMeter 플랜을 생성하며, 이들은 모두 동일한 변수를 공유합니다. 또한 리포지토리에 작은 모크 API(mock API)가 포함되어 있기 때문에, Run을 눌러 흐름이 실제로 엔드 투 엔드(end-to-end)로 실행되는 것(등록 생성, 상태 ACTIVE, ID 체이닝 등)을 지켜볼 수 있습니다. 이것은 단순한 정적 텍스트가 아니라 실제로 실행됩니다.

이 부분은 자신의 서비스를 테스트하는 팀에게 매우 유용합니다. 이미 흐름을 알고 있기 때문에, 이를 설명하는 것이 직접 클릭하며 테스트하는 것보다 빠릅니다.

하지만 한계가 있습니다. 흐름을 이미 알고 있고 서비스가 "본인의 것"일 때 가장 잘 작동합니다. 이는 제가 실제로 더 기대하고 있는 부분으로 이어집니다.

파트 2 — 어떤 앱이든 상관없을 때: 그냥 기록하세요

두 번째 모드는 API에 대한 지식이 전혀 필요 없습니다. 어떤 웹사이트든 지정하고, 손으로 직접 흐름을 따라 클릭하면, 시스템이 알아서 테스트를 파악합니다.

URL을 입력하고 **Start Discovery (탐색 시작)**를 누르면 실제 브라우저가 열립니다. 로그인을 하고 평소 하던 대로 무엇이든 수행하면 됩니다. 저는 실제 OrangeHRM 데모를 대상으로 테스트했습니다. 그 다음 **Stop (중지)**을 누릅니다. 백그라운드에서는 모든 네트워크 트래픽(network traffic)을 기록하며, 이제 여러분이 실제로 수행한 작업을 바탕으로 생성된 동일한 세 가지 결과물(Postman / Playwright / JMeter)을 제공합니다.

문제는 가공되지 않은 브라우저 트래픽은 매우 "지저분"하며, 이를 다시 실행 가능한 테스트로 만드는 과정이 실제 작업의 대부분을 차지한다는 점입니다. 시스템이 정확하게 처리해야 할 몇 가지 사항은 다음과 같습니다:

• 무엇이 변수(variable)인지 파악하기. ID, 토큰(token), 사원 번호 등을 감지하고 단계 간에 이를 연결합니다. 따라서 4단계에서는 2단계에서 생성된 ID를 사용하게 됩니다.
• 합리적으로 이름 짓기. URL이 아니라 해당 변수가 추출된 JSON 필드에서 이름을 가져옵니다 (employee.id → employeeId). 실제 앱에서는 ID의 의미와 상관없이 모든 URL에

그 모든 것을 고민할 필요가 없습니다. 앱을 클릭하며 돌아다니기만 하면 실행 가능한 테스트를 얻을 수 있습니다. 이것이 바로 소스 코드(source code)를 건드리지 않고도, 어떤 앱에서든, _누구_라도 혜택을 볼 수 있는 부분이라고 생각합니다.

간단한 Before/After

다음은 OrangeHRM 세션에서 캡처한 실제 요청 사례입니다:

브라우저가 보낸 내용:

PUT /web/index.php/api/v2/performance/reviews/17/evaluation/employee
{ "ratings": [ { "kpiId": 1, "rating": null } ] }

생성된 내용:

PUT {{baseUrl}}/web/index.php/api/v2/performance/reviews/{{reviewId}}/evaluation/employee
{ "ratings": [ { "kpiId": "{{kpiId}}", "rating": null } ] }

reviewId와 kpiId는 이제 생성된 환경 파일(environment file)로부터 해결되는 변수(variables)가 됩니다. 따라서 파일을 가져와서 실행하기만 하면 되며, 수동으로 값을 채워 넣을 필요가 없습니다.

직접 시도해보기

이 프로젝트는 오픈 소스 (MIT 라이선스)이며, Node + Express + React로 구성되어 있습니다. 단 한 번의 명령어로 Docker를 시작할 수 있습니다:

git clone https://github.com/sshankar07/test-flow-agent
cd test-flow-agent
docker compose up --build     # 그 다음 http://localhost:5173 을 여세요

(라이브 녹화(live-recording) 부분은 실제 브라우저를 실행하므로, 해당 부분은 네이티브(natively) 환경에서 실행하세요. README에 두 가지 방법이 모두 나와 있습니다.)

👉 Repo: https://github.com/sshankar07/test-flow-agent

이상입니다 — 저의 첫 번째 dev.to 포스팅이었습니다! 만약 여러분이 테스트/자동화 분야에 계신다면, 다음에는 무엇을 생성하기를 원하시는지 정말 궁금합니다 — k6? RestAssured? 아니면 CI 파이프라인(CI pipeline)? 댓글로 알려주세요 🙌