“사람이 클릭하던 일을 코드가 한다” 웹 자동화와 브라우저 자동화

들어가며

웹 개발을 하다 보면 똑같은 작업을 계속 반복해야 하는 순간이 있습니다.

관리자 페이지에 로그인해서 데이터를 확인하고, 특정 버튼을 누르고, 결과를 저장하는 작업처럼 사람이 직접 하면 몇 분이면 끝나는 일도 매일 반복하면 꽤 귀찮아집니다.

테스트를 할 때도 마찬가지입니다.

로그인 → 메뉴 이동 → 검색 → 버튼 클릭 → 결과 확인.

이 과정을 기능을 수정할 때마다 사람이 직접 확인한다면 생각보다 시간이 많이 들어갑니다.

이런 반복 작업을 코드로 처리할 수 있도록 도와주는 것이 웹 자동화(Web Automation)입니다.

그리고 웹페이지를 실제 브라우저처럼 열고 클릭, 입력, 이동 등을 코드로 처리하는 방식이 브라우저 자동화(Browser Automation)입니다.

처음에는 두 용어가 거의 같은 것처럼 느껴집니다.

실제로 개발 현장에서도 두 용어를 섞어서 사용하는 경우가 많습니다.

하지만 조금 깊게 들어가 보면 범위에서 차이가 있습니다.

웹 자동화란 무엇일까?

웹 자동화는 말 그대로 웹에서 사람이 반복적으로 하던 작업을 프로그램이 대신 수행하도록 만드는 것입니다.

예를 들어 이런 작업을 생각해볼 수 있습니다.

• 웹페이지 자동 접속
• 검색어 자동 입력
• 버튼 자동 클릭
• 로그인 과정 자동화
• 데이터 확인
• 반복적인 관리자 작업
• 자동 테스트
• 화면 캡처
• 특정 페이지 상태 점검

사람이 직접 브라우저를 열고 처리하던 과정을 프로그램이 대신하는 것입니다.

여기서 꼭 실제 브라우저가 필요한 것은 아닙니다.

API가 제공되는 서비스라면 API를 호출하는 것만으로도 자동화가 가능합니다.

예를 들어 매일 특정 데이터를 가져와 데이터베이스에 저장하는 작업은 브라우저를 띄우지 않고 HTTP 요청이나 API 호출만으로 처리할 수 있습니다.

그래서 웹 자동화가 더 넓은 개념이라고 생각하면 이해하기 쉽습니다.

브라우저 자동화는 조금 다르다

브라우저 자동화는 실제 웹 브라우저의 동작을 프로그램으로 제어하는 데 초점이 맞춰져 있습니다.

예를 들어 Chrome을 코드로 실행한 뒤,

페이지 접속
↓
입력창 찾기
↓
검색어 입력
↓
검색 버튼 클릭
↓
결과 페이지 이동
↓
특정 내용 확인

이런 과정을 자동으로 수행하는 것입니다.

여기서 중요한 점은 단순히 HTML을 가져오는 것이 아니라 실제 브라우저에서 사용자가 하는 행동을 코드로 재현할 수 있다는 것입니다.

그래서 JavaScript로 동작하는 웹사이트를 테스트하거나 복잡한 사용자 시나리오를 자동화할 때 브라우저 자동화가 유용합니다.

단순 HTTP 요청과 무엇이 다를까?

이 부분은 실제 개발하면서 꽤 중요합니다.

간단한 웹페이지라면 HTTP 요청만으로 HTML을 받아 필요한 정보를 처리할 수 있습니다.

예를 들어 서버에서 URL을 요청하고 HTML을 받은 다음 특정 데이터를 파싱하는 방식입니다.

이 방법은 상당히 빠르고 가볍습니다.

그런데 요즘 웹사이트를 보면 처음 받은 HTML에는 원하는 데이터가 없고 JavaScript가 실행된 이후 화면에 내용이 나타나는 경우가 많습니다.

특히 SPA 형태의 웹사이트에서는 이런 상황을 쉽게 만날 수 있습니다.

이런 경우 단순 HTTP 요청만 보내면 원하는 화면을 제대로 얻지 못할 수 있습니다.

브라우저 자동화를 사용하면 실제 브라우저 환경에서 JavaScript를 실행하면서 페이지를 처리할 수 있습니다.

그래서 개발할 때는 무조건 브라우저 자동화를 사용하는 것이 아니라 먼저 API나 일반 HTTP 요청으로 해결할 수 있는지 확인하고, 정말 브라우저가 필요한 경우 자동화 도구를 선택하는 방식이 효율적입니다.

웹 자동화에 브라우저를 꼭 써야 할까?

꼭 그렇지는 않습니다.

예를 들어 공식 API가 있는 서비스에서 데이터를 가져오는 작업이라면 브라우저 자동화보다 API를 사용하는 것이 훨씬 깔끔할 수 있습니다.

const response = await fetch('/api/products');

const data = await response.json();

console.log(data);

이런 작업에 굳이 브라우저를 실행할 필요는 없습니다.

브라우저를 실행하는 것 자체가 상대적으로 무겁기 때문입니다.

반면 다음과 같은 작업이라면 브라우저 자동화의 장점이 커집니다.

JavaScript 실행 필요
사용자 클릭 재현 필요
동적 UI 테스트
팝업 확인
로그인 상태 확인
화면 캡처
여러 페이지 이동 테스트

즉, 브라우저가 필요한 작업인지부터 판단하는 것이 중요합니다.

Headless Browser와 연결하면 이해하기 쉽다

앞에서 Headless Browser를 알아봤다면 웹 자동화와의 관계도 자연스럽게 연결됩니다.

Headless Browser는 브라우저 창을 사용자에게 보여주지 않고 브라우저의 기능을 실행하는 방식입니다.

예를 들어 서버에서 테스트를 실행한다고 생각해보겠습니다.

사용자가 화면을 볼 필요가 없습니다.

프로그램이 알아서 브라우저를 실행하고 페이지에 들어간 다음 버튼을 클릭하고 결과를 확인하면 됩니다.

이때 Headless 모드를 사용하면 화면을 띄우지 않고 자동화 작업을 실행할 수 있습니다.

그래서 서버 환경의 자동화 테스트에서는 Headless Browser가 상당히 유용합니다.

Puppeteer와 Playwright

브라우저 자동화를 이야기하면 자연스럽게 등장하는 것이 Puppeteer와 Playwright입니다.

Puppeteer는 Chrome 또는 Chromium 계열 브라우저를 자동화하는 데 많이 사용되어 온 Node.js 기반 도구입니다.

간단한 브라우저 자동화라면 비교적 직관적으로 코드를 작성할 수 있습니다.

const browser = await puppeteer.launch({
    headless: true
});

const page = await browser.newPage();

await page.goto('https://example.com');

console.log(await page.title());

await browser.close();

Playwright 역시 브라우저 자동화 도구입니다.

특히 Chromium뿐만 아니라 Firefox와 WebKit 등 여러 브라우저 환경을 대상으로 테스트할 수 있다는 점이 특징입니다.

그래서 단순한 브라우저 작업뿐만 아니라 E2E 테스트를 체계적으로 구축하려는 프로젝트에서도 많이 활용됩니다.

웹 자동화에서 가장 많이 활용되는 분야

웹 자동화의 활용 범위는 생각보다 넓습니다.

1. E2E 테스트

가장 대표적인 활용 사례입니다.

사용자가 실제로 서비스를 사용하는 과정을 코드로 재현합니다.

예를 들어,

로그인
→ 상품 검색
→ 상품 선택
→ 장바구니 추가
→ 결제 페이지 이동

이 과정을 자동으로 실행하면서 중간에 오류가 발생하지 않는지 확인할 수 있습니다.

개발자가 기능을 수정할 때마다 같은 작업을 반복할 필요가 없다는 것이 가장 큰 장점입니다.

2. 관리자 페이지 자동화

관리자 페이지에서 매일 반복하는 작업이 있다면 자동화할 수 있습니다.

예를 들어 특정 조건의 데이터를 조회하거나 결과를 확인하는 등의 반복 업무를 자동화할 수 있습니다.

다만 해당 서비스가 자동화를 허용하는지 먼저 확인해야 합니다.

3. 웹사이트 상태 점검

특정 URL이 정상적으로 열리는지 주기적으로 확인하는 방식도 가능합니다.

로그인 후 특정 페이지까지 정상적으로 이동할 수 있는지 확인하거나 중요한 버튼이 정상적으로 표시되는지 검사할 수도 있습니다.

4. 스크린샷 자동 생성

특정 페이지를 열어서 스크린샷을 자동으로 저장하는 작업도 가능합니다.

관리자 대시보드나 리포트 화면을 정기적으로 캡처해야 한다면 사람이 직접 캡처하는 것보다 훨씬 편리합니다.

자동화한다고 해서 무조건 좋은 것은 아니다

웹 자동화를 처음 접하면 할 수 있는 것은 전부 자동화하고 싶어집니다.

그런데 실제 프로젝트에서는 오히려 자동화하지 않는 것이 나은 작업도 있습니다.

예를 들어 한 번만 실행하면 되는 단순한 작업이라면 자동화 코드를 만드는 시간이 더 오래 걸릴 수 있습니다.

또 웹사이트 UI가 자주 변경되면 자동화 코드도 같이 수정해야 합니다.

특히 CSS 선택자를 너무 구체적으로 작성하면 화면 구조가 조금만 바뀌어도 테스트가 깨질 수 있습니다.

예를 들어,

await page.click(
    '#container > div:nth-child(2) > div > button'
);

같은 선택자는 처음에는 작동하더라도 HTML 구조가 변경되면 문제가 생길 가능성이 높습니다.

가능하다면 의미 있는 요소를 기준으로 찾는 방법을 고려하는 것이 좋습니다.

await page.getByRole('button', {
    name: '로그인'
}).click();

이런 식으로 작성하면 코드만 봐도 무엇을 클릭하는지 이해하기 쉽습니다.

웹 자동화에서 대기 처리가 중요한 이유

자동화 코드를 작성할 때 가장 흔하게 만나는 문제가 페이지 로딩과 실행 타이밍입니다.

사람은 화면을 보면서 버튼이 나타날 때까지 자연스럽게 기다립니다.

하지만 프로그램은 그렇지 않습니다.

페이지가 아직 로딩 중인데 버튼을 찾으려고 하면 실패할 수 있습니다.

그래서 자동화에서는 특정 요소가 나타날 때까지 기다리거나 페이지 상태를 확인하는 과정이 중요합니다.

예전에는 단순하게 몇 초를 기다리는 코드도 많이 사용했습니다.

await new Promise(resolve =>
    setTimeout(resolve, 2000)
);

하지만 서버 상태에 따라 2초보다 오래 걸릴 수도 있고, 반대로 너무 빨리 끝났는데도 무조건 2초를 기다릴 수도 있습니다.

그래서 가능하면 실제 요소나 네트워크 상태 등을 기준으로 기다리는 방식이 더 안정적입니다.

이런 부분에서 Playwright 같은 자동화 도구가 제공하는 자동 대기 기능이 상당히 편리합니다.

웹 자동화와 크롤링은 같은 것일까?

이것도 많이 헷갈리는 부분입니다.

웹 자동화와 크롤링은 서로 겹치는 영역이 있지만 완전히 같은 개념은 아닙니다.

크롤링은 일반적으로 웹페이지를 자동으로 방문하고 필요한 데이터를 수집하는 작업에 초점이 있습니다.

반면 웹 자동화는 데이터 수집뿐 아니라 테스트, 클릭, 입력, 로그인, 페이지 검증 등 다양한 작업을 포함합니다.

즉,

크롤링은 웹 자동화의 한 활용 사례가 될 수 있지만 웹 자동화 전체가 크롤링은 아닙니다.

특히 브라우저 자동화는 사용자 행동을 재현하는 테스트 분야에서도 상당히 중요하게 사용됩니다.

자동화하기 전에 꼭 확인할 것

기술적으로 자동화할 수 있다고 해서 모든 사이트에서 자유롭게 자동화해도 되는 것은 아닙니다.

이 부분은 실제 프로젝트에서 상당히 중요합니다.

외부 사이트의 데이터를 자동으로 수집하거나 로그인 과정 등을 자동화하려는 경우에는 해당 사이트의 이용약관과 API 정책 등을 확인해야 합니다.

공식 API가 제공된다면 API를 사용하는 것이 더 안정적이고 정책 측면에서도 명확한 경우가 많습니다.

또한 과도한 요청으로 서비스에 부담을 주지 않도록 요청 빈도와 동시 실행 수 등을 적절하게 관리해야 합니다.

결국 웹 자동화는 단순히 “코드로 클릭하는 기술”이 아니라 정해진 작업을 안정적으로 반복하도록 만드는 개발 방법이라고 보는 것이 좋습니다.

마무리

웹 자동화를 처음 접하면 Puppeteer나 Playwright 같은 도구부터 찾아보게 됩니다.

하지만 도구를 선택하기 전에 먼저 생각해볼 것이 있습니다.

“내가 자동화하려는 작업은 정말 브라우저가 필요한가?”

API로 해결할 수 있다면 API가 더 좋을 수 있습니다.

단순 HTTP 요청으로 데이터를 가져올 수 있다면 굳이 브라우저를 실행할 필요도 없습니다.

반대로 실제 사용자처럼 페이지를 열고 JavaScript가 실행되는 화면에서 클릭과 입력을 반복해야 한다면 브라우저 자동화가 훨씬 적합합니다.

이 기준만 잡아도 자동화 도구를 선택하는 일이 훨씬 쉬워집니다.

정리하면 웹 자동화는 더 넓은 개념이고, 브라우저 자동화는 실제 브라우저의 동작을 코드로 제어하는 방법이라고 이해하면 됩니다.

그리고 Headless Browser, Puppeteer, Playwright는 이 영역을 이해할 때 함께 알아두면 좋은 기술입니다.

처음부터 거창한 자동화 시스템을 만들 필요는 없습니다.

로그인 테스트 하나, 검색 기능 테스트 하나처럼 반복되는 작업부터 자동화해보면 됩니다.

직접 몇 번 사용해보면 왜 개발자들이 웹 자동화를 테스트와 반복 작업에 활용하는지 생각보다 빨리 체감할 수 있습니다.