Playwright를 Aside로 바꿔도 될까 — 스크립트와 에이전트의 경계
손익분기는 월 51회입니다. 그보다 자주 돌리면 스크립트가, 그보다 드물면 에이전트가 쌉니다. CI를 통째로 에이전트로 바꾸면 비용이 25배가 됩니다.
셀렉터가 또 깨졌을 때 드는 생각
Playwright로 E2E를 짜본 사람은 이 사이클을 압니다.
프런트에서 클래스명 하나 바꿈
→ 셀렉터 깨짐
→ CI 빨개짐
→ 테스트 코드 고침
→ 기능은 멀쩡했음
그래서 "자연어로 시키면 셀렉터가 필요 없지 않나"는 생각이 자연스럽게 나옵니다. Aside 같은 브라우저 에이전트는 실제로 그렇게 동작합니다 — 사람처럼 화면을 보고 누릅니다.
바꿀 수 있는 부분과 절대 바꾸면 안 되는 부분이 꽤 선명하게 갈립니다. 계산으로 확인해 보겠습니다.
계산 1 — CI를 통째로 바꾸면
E2E 시나리오 20개, 하루 50회 실행(커밋마다 도는 규모)을 가정합니다.
Playwright (GitHub Actions Linux 2코어 $0.008/분)
10분 × 50회 × 30일 = 15,000분/월
15,000 × $0.008 = $120/월 (160,800원)
에이전트로 바꾸면 — 시나리오 하나가 태스크 하나입니다.
20개 × 50회 × 30일 = 30,000 태스크/월
| 태스크당 단가 | 월 비용 | Playwright 대비 |
|---|---|---|
| $0.05 | $1,500 (2,010,000원) | 12배 |
| $0.10 | $3,000 (4,020,000원) | 25배 |
| $0.30 | $9,000 (12,060,000원) | 75배 |
태스크 단가는 가정입니다 — Aside는 크레딧제라 태스크당 정확한 단가를 공개하지 않고, 자기 API 키로 붙이면 모델과 페이지 수에 따라 크게 달라집니다. 어느 값을 넣어도 결론은 같습니다. 자릿수가 다릅니다.
그리고 비용보다 먼저 걸리는 게 있습니다. 시간입니다. Playwright 시나리오 하나는 10초면 끝나지만, 에이전트는 화면을 읽고 판단하며 진행하므로 분 단위입니다. 10분짜리 CI가 몇 시간이 됩니다.
계산 2 — 시나리오 하나의 손익분기
그럼 어디서부터 에이전트가 유리한가. 시급 31,000원 기준으로 잡아 보겠습니다.
Playwright 시나리오 하나
작성 2시간 62,000원 → 12개월 상각 5,167원/월
월 유지보수 30분 15,500원/월
──────────
20,667원/월
에이전트 시나리오 하나
작성 10분(지시문 쓰기) 5,167원 (일회성)
실행당 $0.30 402원
손익분기는 여기입니다.
20,667원 ÷ 402원 = 약 51회/월 → 하루 1.7회
월 50회 남짓이 경계입니다. 이보다 자주 돌리면 스크립트가, 이보다 드물면 에이전트가 쌉니다.
이 숫자가 말해주는 건 단순합니다. CI에 들어가는 것은 전부 스크립트 영역이고(커밋마다 돌면 월 수백 회), 사람이 가끔 손으로 하던 것은 전부 에이전트 영역입니다(월 몇 회).
비용보다 중요한 경계 — 결정성
숫자를 빼고도 갈리는 지점이 있습니다.
Playwright의 실패는 재현됩니다. 셀렉터가 깨지면 언제나 같은 자리에서 같은 이유로 깨지고, 고치면 다시는 안 깨집니다. 플레이키 테스트조차 원인을 추적할 수 있습니다.
에이전트의 실패는 재현되지 않습니다. 같은 지시를 줘도 이번엔 다른 버튼을 누를 수 있습니다. "왜 이번엔 다르게 했는지"를 알 수 없고, 고칠 대상도 없습니다. 지시문을 다듬는 건 수정이 아니라 유도입니다.
이게 무엇을 뜻하냐면.
회귀 테스트 같은 걸 같게 반복해야 함 → 에이전트 부적합
탐색적 확인 매번 다르게 봐도 상관없음 → 에이전트 적합
회귀 테스트의 존재 이유가 결정성입니다. 어제 통과하고 오늘 실패하면 그건 코드가 바뀐 것이어야 합니다. 실행기가 바뀐 것이면 테스트가 아닙니다.
그래서 어디를 바꾸나
에이전트가 맞는 자리
1. 우리가 제어하지 못하는 사이트. 외부 벤더 콘솔, PG사 대시보드, 관공서 사이트. 여기는 셀렉터가 예고 없이 바뀌고, 바뀌어도 통보받지 못하고, 애초에 테스트용 계정도 없습니다. 유지보수 비용이 실행 빈도를 압도하는 전형적인 자리입니다.
2. 한 번 쓰고 버릴 확인. "결제 플로우 지금 깨졌나 확인해줘" 같은 일회성 요청. 스크립트를 짜는 2시간이 확인 10분보다 비쌉니다.
3. 스펙이 말로만 있는 탐색. "회원가입부터 첫 결제까지 해보고 이상한 데 있으면 알려줘." 기대값을 코드로 적을 수 없는 종류입니다.
4. 로그인 상태가 이미 있는 조사. Playwright로 사내 어드민을 자동화하려면 로그인 처리부터 짜야 합니다. 에이전트는 이미 로그인된 세션 위에서 시작합니다.
스크립트를 지켜야 하는 자리
1. CI에 들어가는 모든 것. 위 계산대로입니다.
2. 회귀 테스트 전부. 결정성이 요구사항입니다.
3. 정확한 입력이 필요한 작업. 특정 문자열, 특정 순서, 특정 타이밍. 에이전트는 "비슷하게" 합니다.
4. 대량 반복. 1,000건 처리에 에이전트를 쓰면 1,000번의 LLM 호출입니다.
그 사이 — aside repl
Aside에도 결정적인 층이 있습니다. aside repl은 페이지를 직접 뜯어보거나 스크린샷을 찍거나 브라우저 단계를 스크립트로 짤 때 씁니다.
aside "..." 자연어. 유연하고 비결정적
aside repl 스크립트. 결정적
로그인 세션은 필요한데 동작은 결정적이어야 할 때 이 조합이 의미가 있습니다. Playwright로는 인증 상태를 만드는 것부터가 일인 경우입니다.
실무 판단 규칙
월 50회 이상 실행 → Playwright
월 50회 미만 → 에이전트
결정성이 요구사항 → Playwright (횟수 무관)
우리가 제어 못 하는 사이트 → 에이전트 (횟수 무관)
바꿔 말하면 이렇게 됩니다. Playwright를 걷어내는 게 아니라, Playwright를 짜지 않기로 했던 것들을 자동화하는 겁니다.
지금까지 "자동화하면 좋겠지만 유지보수가 더 들 것 같아서" 포기한 목록이 각자 있을 겁니다. 벤더 콘솔 월간 점검, 만료일 확인, 사내 시스템 순회. 그게 에이전트가 새로 여는 영역이고, E2E 스위트는 그 영역이 아닙니다.
정리
- CI를 통째로 에이전트로 바꾸면 비용이 12~75배가 되고, 시간은 분 단위에서 시간 단위가 됩니다.
- 시나리오 하나의 손익분기는 월 51회(하루 1.7회) 입니다. 그보다 자주면 스크립트가 쌉니다.
- 비용보다 중요한 건 결정성입니다. 에이전트의 실패는 재현되지 않고, 고칠 대상도 없습니다.
- 회귀 테스트의 존재 이유가 결정성이므로 여기는 협상 대상이 아닙니다.
- 에이전트가 이기는 자리는 우리가 제어 못 하는 사이트, 일회성 확인, 탐색적 테스트, 이미 로그인된 조사입니다.
aside repl은 로그인 세션은 필요하고 동작은 결정적이어야 할 때의 중간 지대입니다.- 요점은 교체가 아닙니다. 애초에 자동화를 포기했던 것들이 새로 열리는 겁니다.
여러분이 "자동화하면 좋겠지만 유지보수가 더 들 것 같아서" 포기한 작업은 무엇인가요? 손익분기 월 51회를 대보면 답이 나옵니다.
출처
- Aside 문서 — 개발자 도구 —
aside repl과 CLI 실행 방식. - Aside 요금 — 크레딧 기반 과금과 플랜별 사용량.
- GitHub Actions 요금 — Linux 2코어 분당 단가.
- Playwright 공식 문서 — 테스트 안정성과 셀렉터 전략 권장 사항.