이전에 Playwright로 E-GENE 화면 테스트를 자동화해 본 적이 있다. 이후 Aside라는 AI 브라우저를 접했고, CLI도 함께 쓰면서 요즘은 개발 직후 화면 테스트에 Aside CLI를 주로 쓴다. Aside를 메인 브라우저로 쓰지는 않지만, 개인 작업이나 개발 직후 화면을 확인할 때는 꽤 유용하다.
두 방식을 모두 써 본 입장에서, Aside CLI를 중심으로 차이와 장단점을 정리한다.
1. 두 방식은 무엇이 다른가
Playwright는 브라우저를 코드로 제어하는 오픈소스 자동화 도구다. 보통 별도의 브라우저 컨텍스트를 띄우고, 미리 쓴 스크립트대로 클릭하고 입력하고 결과를 확인한다. 로그인이 필요하면 로그인 과정을 스크립트에 넣거나, 미리 저장한 인증 상태를 불러온다.
Aside CLI는 Claude Code나 Codex 같은 코딩 에이전트가 Aside를 통해 브라우저를 직접 쓰게 하는 방식이다. 내가 이미 로그인해 쓰는 브라우저 환경에서, 테스트 스크립트를 먼저 쓰지 않고 목표만 전달하면 에이전트가 화면을 보며 다음 행동을 판단한다.
단순화하면 차이는 이렇다.
- Playwright: 정해진 절차를 브라우저에서 반복 실행
- Aside CLI: 현재 브라우저 상태를 바탕으로 에이전트가 화면을 보며 판단하고 실행
그래서 두 도구는 비슷해 보이지만 잘 맞는 상황이 조금 다르다.
2. Aside CLI의 장점
써 보면서 가장 크게 느낀 장점은 로그인과 인증을 다루기 편하다는 점이다.
로그인된 상태를 그대로 쓴다
Playwright로 E-GENE 스모크 테스트를 만들 때는 저장한 로그인 상태를 재사용했다. 그런데 세션이 만료되거나 계정 권한이 바뀌면 테스트 결과가 달라질 수 있어 인증 상태를 따로 관리해야 했다. Aside에서는 평소 쓰던 브라우저의 로그인 상태를 쓸 수 있어 이 불편이 크게 줄었다. Aside 공식 설명에 따르면 저장된 비밀번호는 에이전트에게 직접 보여 주지 않고, 필요한 사이트에 자동으로 입력하는 방식으로 처리한다.
테스트 스크립트를 먼저 만들 필요가 없다
Playwright는 반복할 동작을 코드로 미리 정의한다. Aside CLI는 "이 화면에서 이 기능이 제대로 동작하는지 확인해 줘"처럼 목표만 주면 에이전트가 현재 화면을 보고 판단해 움직인다. 화면 구성이 조금 바뀌어도 에이전트가 상황에 맞게 대응한다는 점도 편했다.
Playwright로 자동화할 때는 권한이나 예외 상황을 코드에서 미리 처리해야 하는 경우가 많았다. 예상 못 한 알림창 하나 때문에 무인 실행이 막히기도 했는데, Aside는 사람이 브라우저를 쓰듯 화면을 보며 대응한다.
코딩 에이전트의 개발 흐름과 바로 이어진다
개인적으로 가장 많이 쓰는 부분이다. 최근 한두 달 기록을 보니 Aside 호출 약 700건 중 대부분이 Claude Code가 로컬에 띄운 개발 중인 화면을 직접 열어 확인한 작업이었다.
코딩 에이전트가 코드 수정
→ 로컬 서버 실행
→ Aside로 화면 열기
→ 실제 화면 확인
→ 문제가 있으면 다시 코드 수정이 흐름을 한 세션 안에서 이어 갈 수 있다. 예전에는 내가 직접 브라우저로 가서 새로고침하고 화면을 본 뒤, 다시 에이전트에게 상태를 전달하는 일이 많았는데 이 과정이 상당 부분 줄었다. Aside의 개발자용 활용 사례에서도 코드는 코딩 에이전트가 고치고, 로그인 뒤에만 볼 수 있는 화면이나 실제 UI 검증은 Aside가 맡는 식으로 역할을 나눈다.
로그인된 업무 도구도 조사할 수 있다
Slack이나 Google Chat처럼 일반 웹 검색으로 닿지 않는 곳도, 내가 로그인해 있으면 읽기 전용 조사에 쓸 수 있다. 기존 자료나 대화 내용을 찾는 작업을 몇 번 맡겨 봤는데, 검색 범위를 브라우저 안쪽까지 넓힐 수 있다는 점이 유용했다.
3. 단점과 주의할 점
편한 만큼 Playwright에 비해 분명한 한계도 있다.
매번 같은 실행을 보장하기 어렵다
Aside CLI는 에이전트의 판단이 실행 과정에 들어간다. 같은 목표를 줘도 클릭 순서나 접근 방식이 실행마다 달라질 수 있다. Playwright 스크립트는 같은 입력에 대해 정해진 절차를 그대로 반복한다. 그래서 CI/CD에 넣어 매번 같은 조건으로 검증해야 하는 E2E 테스트나 회귀 테스트에는 여전히 Playwright가 더 맞다고 본다.
"완료했다"는 보고만으로 판단하면 안 된다
에이전트가 명령을 정상적으로 끝냈다고 해서, 기대한 작업이 실제로 다 끝났다는 뜻은 아닐 수 있다. 특히 사람 없이 돌리면 중간에 확인이 필요한 상황을 제대로 처리하지 못하거나 일부 단계를 건너뛸 수도 있다. 그래서 중요한 테스트에서는 결과를 한 번 더 확인하는 편이 좋았다.
- 최종 화면 확인
- 캡처 확인
- 실제 데이터 상태 확인
자동화와 탐색을 나눠 쓴다
Aside CLI가 편하다고 기존 Playwright 테스트를 모두 대체할 필요는 없다. Aside는 상황을 보고 판단하는 데 강하고, Playwright는 같은 과정을 정확히 반복하는 데 강하다.
4. 정리
| 구분 | Playwright | Aside CLI |
|---|---|---|
| 브라우저 | 깨끗한 새 브라우저 | 내가 쓰는 브라우저 |
| 로그인 | 스크립트나 저장한 상태로 처리 | 저장된 비밀번호로 자동 |
| 준비 | 스크립트를 먼저 작성 | 목표만 전달 |
| 반복 결과 | 매번 같음 | 달라질 수 있음 |
| 잘 맞는 곳 | 배포 전 자동 검사, 반복 회귀 테스트 | 개발 직후 화면 확인, 로그인이 필요한 조사, 개인 잡무 |
매번 같은 결과가 필요한 검사는 Playwright로, 사람이 옆에서 빠르게 확인하거나 로그인된 곳을 찾아볼 때는 Aside CLI로 나눠 쓰는 것이 맞다고 생각한다.
5. 마무리
Aside를 쓴 지 아직 한 달 정도라, 더 쓰면서 생각이 바뀔 수도 있다. 지금까지는 Playwright로 반복 가능한 테스트를 만들고, 개발 중에 사람이 브라우저를 오가며 확인하던 부분은 Aside CLI에 맡기는 조합을 가장 많이 쓴다. 특히 코딩 에이전트가 코드를 고친 직후 실제 브라우저까지 이어서 확인할 수 있다는 점은 생각보다 체감이 컸다. 반대로 배포 전 검증처럼 같은 결과를 반복해서 보장해야 하는 영역까지 에이전트의 판단에 맡기는 것은 아직 조심스럽다.
Aside를 메인 브라우저로 쓰기에는 아직 망설여진다. 안전하다고 설명하지만, 개인 정보를 키체인에 담아 넘겨주는 방식에 대한 거부감이 남아 있다. 다만 예전에는 낯설던 개인 정보의 온라인 입력과 보관이 지금은 자연스러워졌듯, 언젠가는 AI가 개인의 다양한 정보를 참고하는 것도 자연스럽게 받아들이는 시대가 오지 않을까 생각한다.