API 테스트에 셀레늄 활용: 가능할까? 필요할까?

Selenium은 브라우저 자동화 프레임워크입니다. 사람이 하는 방식으로 Chrome, Firefox 및 기타 브라우저를 구동합니다. 버튼 클릭, 양식 작성, 렌더링된 페이지 읽기 등이 해당됩니다. 이는 엔드투엔드 UI 테스트를 위한 표준 도구이며, 이 역할을 매우 잘 수행합니다.

사람들은 여전히 Selenium이 API를 테스트할 수 있는지 묻습니다. 솔직히 말하면 HTTP 호출을 발생시키도록 만들 수는 있지만, 이 작업에는 적합하지 않은 도구입니다. 이 가이드는 그 이유를 정확히 설명하고, Selenium을 통한 API 테스트가 실제로 어떻게 보이는지 보여주며, 이 작업에 적합한 도구를 알려줍니다. 목표는 나중에 여러분을 좌절시킬 설정을 피하는 데 도움을 드리는 것입니다.

Selenium과 API 테스트가 맞지 않는 이유

API 테스트는 HTTP 요청을 서버로 직접 보내고 응답(상태 코드, 헤더, 본문, 시간)을 확인합니다. 사용자 인터페이스는 전혀 개입되지 않습니다. 테스트는 빠르고, 독립적이며, 수천 번 실행해도 비용이 저렴해야 합니다.

Selenium은 설계상 그 반대입니다. 실제 브라우저를 실행하고, 페이지를 로드하며, JavaScript가 렌더링될 때까지 기다립니다. 이 브라우저는 UI를 테스트할 때는 핵심적인 요소이지만, API를 테스트할 때는 순전히 오버헤드입니다. 전용 클라이언트가 수십 밀리초 만에 보내는 요청이 브라우저 프로세스, WebDriver 세션, 페이지 렌더링이 개입되면 수 초가 걸리는 작업이 됩니다.

더 깊은 불일치도 있습니다. Selenium의 전체 API는 페이지의 요소에 관한 것입니다. 이 버튼을 찾고, 이 텍스트를 읽고, 이 요소를 기다리는 식입니다. HTTP 응답은 페이지가 아닙니다. DOM이 없습니다. 따라서 Selenium은 JSON 본문을 검사하거나, 헤더를 단언하거나, 상태 코드를 확인하는 데 유용한 것을 전혀 제공하지 않습니다. 결국 도구를 활용하는 대신 도구를 우회하는 방식으로 작업하게 됩니다.

비용은 속도만이 아닙니다. 브라우저 기반 테스트는 불안정하기로 유명합니다. 페이지 렌더링에 시간이 조금 더 걸리거나, WebDriver 세션이 끊기거나, 브라우저 업데이트로 인해 타이밍이 변경되어 실패합니다. API 테스트는 결정적이어야 합니다. 동일한 요청은 동일한 응답을 생성해야 하며, 실패는 뭔가 실제로 고장 났음을 의미합니다. Selenium을 통해 API 검사를 라우팅하면, 불안정할 이유가 전혀 없는 계층에 브라우저의 모든 불안정성을 가져오게 됩니다. 시간이 지남에 따라 불안정한 테스트 스위트는 팀이 빨간색 빌드를 무시하도록 훈련시키고, 이는 테스트의 목적을 상실하게 만듭니다. 유효성 검사(validation)와 확인(verification)의 구별은 여기서 좋은 관점입니다. Selenium은 렌더링된 경험을 확인하는 반면, API 테스트는 그 밑의 계약을 유효성 검사합니다.

“Selenium으로 API 테스트”가 실제로 의미하는 것

기사에서 Selenium이 API를 테스트할 수 있다고 주장할 때, 그들은 보통 두 가지 해결 방법 중 하나를 의미합니다. 어느 쪽도 Selenium을 API 테스트 도구로 만들지는 않습니다. 그들은 단지 HTTP를 Selenium을 통하거나 Selenium과 함께 라우팅할 뿐입니다.

첫 번째 옵션: Selenium의 JavaScript executor 사용. Selenium은 자신이 제어하는 브라우저에서 임의의 JavaScript를 실행할 수 있습니다. 최신 브라우저에는 fetch API가 있으므로, 브라우저에게 요청을 보내고 그 결과를 테스트 코드로 다시 전달하도록 요청할 수 있습니다.

JavascriptExecutor js = (JavascriptExecutor) driver;
Object status = js.executeAsyncScript(
    "const callback = arguments[arguments.length - 1];" +
    "fetch('https://jsonplaceholder.typicode.com/users/1')" +
    "  .then(r => callback(r.status))" +
    "  .catch(e => callback('error: ' + e));"
);
System.out.println("Status code: " + status);

이것은 작동합니다. 하지만 이는 일반적인 HTTP 클라이언트가 직접 수행할 HTTP 호출 하나를 위해 브라우저, WebDriver, JavaScript 브리지를 순전히 시작했다는 의미이기도 합니다. 또한 서버-서버 API 테스트에서는 고려할 필요가 없는 CORS와 같은 브라우저 제약 조건도 상속받게 됩니다.

두 번째 옵션: Selenium을 무시하고 실제 HTTP 라이브러리를 함께 사용. Java 프로젝트에서 이는 API 부분에 Selenium과 REST Assured를 함께 사용하는 것을 의미합니다.

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

given()
    .when()
    .get("https://jsonplaceholder.typicode.com/users/1")
    .then()
    .statusCode(200)
    .body("email", equalTo("Sincere@april.biz"));

여기서 실제 API 테스트는 전적으로 REST Assured에 의해 수행됩니다. Selenium은 아무런 기여도 하지 않습니다. 두 라이브러리가 같은 프로젝트에 존재할 뿐입니다. 이는 괜찮지만, “Selenium으로 API 테스트”라고 할 수는 없습니다. 이는 적절한 API 테스트 라이브러리를 사용한 API 테스트이며, Selenium은 관련 없는 UI 테스트를 위해 존재할 뿐입니다.

두 가지를 함께 사용하는 것이 합리적일 때

Selenium 스위트 내에서 HTTP 작업을 하는 한 가지 합법적인 경우가 있으며, 이에 대해 명확히 설명할 가치가 있습니다. Selenium UI 테스트는 종종 브라우저를 통해 수행하는 것보다 API를 통해 설정 또는 해체하는 것이 더 빠른 경우가 많습니다.

주문 내역 페이지를 확인하는 UI 테스트가 있다고 가정해 봅시다. 이를 테스트하려면 주문이 존재해야 합니다. 해당 주문을 생성하기 위해 브라우저에서 전체 결제 흐름을 클릭하는 것은 느리고 불안정합니다. 대신, 테스트는 직접 API 호출을 통해 주문을 생성한 다음, 브라우저가 진정으로 필요한 부분, 즉 내역 페이지를 로드하고 주문이 표시되는지 확인하는 부분에만 Selenium을 사용합니다.

이것은 건전한 관행입니다. API 호출은 목적을 위한 수단이지, 테스트 대상 자체가 아닙니다. API 호출은 여전히 JavaScript executor가 아닌 실제 HTTP 클라이언트를 통해 이루어져야 합니다. 따라서 이 경우에도 Selenium은 API 테스트를 수행하는 것이 아닙니다. UI 테스트를 수행하며, 적절한 HTTP 클라이언트가 API 측면을 처리합니다.

API를 통한 설정 패턴은 충분히 흔하며, 대부분의 성숙한 테스트 스위트가 의도적으로 이를 채택합니다. 이는 느리고 브라우저 기반의 스위트 부분을 최대한 작게 유지하여, 렌더링된 페이지가 진정으로 필요한 소수의 여정에만 사용합니다. 모든 데이터 준비와 대부분의 검증을 포함한 다른 모든 작업은 빠른 HTTP 호출을 통해 이루어집니다. 그 결과는 몇 시간이 아닌 몇 분 안에 실행되고 실제 이유로 인해 실패하는 스위트입니다. UI와 자동화된 계층이 어떻게 함께 작동하는지에 대한 더 넓은 그림을 보려면 기능 테스트와 자동화 테스트를 참조하세요.

API 테스트를 위해 만들어진 도구 사용

API 테스트가 목표라면, 그 목적에 맞게 설계된 도구를 사용하세요. 그 차이는 작지 않습니다. 실제 API 테스트 도구는 브라우저를 실행하지 않고도 요청 빌딩, 환경 관리, 상태, 헤더 및 본문에 대한 단언, 요청 체이닝, 데이터 기반 실행, CI 통합을 제공합니다.

접근 방식	가장 적합한 용도	API 테스트 적합성
Selenium	UI / 브라우저 엔드투엔드 테스트	부적합. HTTP용으로 설계되지 않음.
REST Assured / requests / supertest	코드 프로젝트 내 API 테스트	적합. 실제 HTTP 라이브러리.
Postman, Insomnia, Talend API Tester	수동 및 스크립트 기반 API 테스트	적합. 전용 클라이언트.
Apidog	전체 API 라이프사이클: 설계, 디버그, 모의, 테스트, 문서화	강력함. 모든 것을 위한 하나의 작업 공간.

코드를 선호한다면, Java의 REST Assured, Python의 requests, 또는 Node의 supertest와 같은 HTTP 라이브러리가 올바른 선택입니다. 이 라이브러리들은 요청을 보내고 응답을 직접 돌려주며, 상태 코드와 JSON 본문을 위한 단언 도우미를 내장하고 있습니다. 브라우저, WebDriver, 렌더링이 없으므로 전체 스위트는 빠르게 실행되고 API 자체에 변경이 있을 때만 실패합니다.

시각적 작업 공간을 원한다면, Apidog는 API 설계, 요청 디버깅, 엔드포인트 모의, 자동화된 테스트 시나리오 구축, 문서 생성 등 모든 것을 하나의 프로젝트에서 다루는 올인원 API 플랫폼입니다. 시각적으로 또는 스크립트로 단언을 구축하고, 요청을 다단계 흐름으로 연결하며, 데이터 기반 반복을 실행하고, CI에서 모든 것을 실행할 수 있습니다. 또한 OpenAPI 및 Postman 파일을 가져올 수 있어 기존 API를 빠르게 통합할 수 있습니다. 이 모든 과정에는 브라우저가 개입되지 않으며, 개입될 필요도 없습니다. 실제 API를 대상으로 시도해 보려면 Apidog를 다운로드할 수 있습니다.

코드 우선 프레임워크를 원하는 팀을 위해, API 자동화를 위한 Robot Framework 및 API 자동화 테스트 프레임워크 구축에 대한 가이드는 Selenium과는 달리 HTTP 테스트에 실제로 적합한 접근 방식을 다룹니다.

솔직한 결론

Selenium은 브라우저 자동화를 위해 만들어진 역할에 있어 훌륭한 소프트웨어입니다. API 테스트는 그 역할이 아닙니다. 기술적으로 Selenium의 JavaScript executor를 통해 HTTP를 푸시할 수 있으며, Selenium과 동일한 프로젝트에 HTTP 라이브러리를 유지할 수도 있지만, 두 경우 모두 Selenium이 API 테스트 자체에 가치를 더하는 것은 아닙니다.

잘못된 도구를 선택하는 것은 중립적인 결정이 아닙니다. 이는 테스트를 느리게 만들고, 유지보수하기 어렵게 하며, API와는 전혀 관련 없는 실패가 발생하기 쉽게 만듭니다. 해당 작업에 맞게 만들어진 도구를 사용하십시오. 여러분의 테스트 스위트는 더 빠르고, 더 신뢰할 수 있으며, 이해하기 훨씬 쉬울 것입니다. 최고의 자동화 테스트 플랫폼 목록은 특정 목적에 맞게 구축된 옵션들을 비교하기에 좋은 곳입니다.

자주 묻는 질문

Selenium으로 REST API 테스트가 아예 불가능한가요?

브라우저의 JavaScript executor를 통해 HTTP 요청을 보낼 수 있으므로, 좁은 기술적 의미에서는 가능합니다. 하지만 Selenium은 응답 검사, JSON 단언, 헤더 확인을 위한 기능이 없으며, 브라우저의 전체 오버헤드를 동반합니다. 이는 REST API 테스트 도구가 아니며, 그렇게 사용하면 느리고 취약한 테스트를 만들게 됩니다.

일부 튜토리얼에서 Selenium과 REST Assured를 함께 보여주는 이유는 무엇인가요?

해당 튜토리얼의 API 테스트는 실제 HTTP 테스트 라이브러리인 REST Assured에 의해 전적으로 수행되기 때문입니다. Selenium은 관련 없는 UI 테스트를 위해 같은 프로젝트에 있을 뿐입니다. 이러한 조합은 괜찮지만, Selenium이 API를 테스트한다는 의미는 아닙니다. REST Assured가 API를 테스트하는 것입니다.

Selenium 테스트에서 API 호출을 하는 것이 괜찮은 경우도 있나요?

네, 설정 및 해체 작업에는 괜찮습니다. API를 통해 테스트 데이터를 생성하는 것이 UI를 클릭하여 데이터를 만드는 것보다 빠르고 신뢰할 수 있습니다. API 호출은 테스트 대상이 아니라 UI 테스트를 지원하는 역할이며, Selenium의 JavaScript executor가 아닌 적절한 HTTP 클라이언트를 사용해야 합니다.

API 테스트를 위해 Selenium 대신 무엇을 사용해야 하나요?

코드 우선 테스트의 경우, REST Assured, Python의 requests, 또는 Node의 supertest와 같은 HTTP 라이브러리를 사용하세요. 시각적 작업 공간의 경우, Apidog와 같은 전용 API 플랫폼 또는 Postman, Insomnia, Talend API Tester와 같은 클라이언트를 사용하세요. 이 모든 도구는 HTTP를 위해 구축되었으며 Selenium이 부과하는 브라우저 오버헤드를 피합니다.

API 테스트에 Selenium을 사용하면 CI 파이프라인 속도가 느려지나요?

상당히 느려집니다. Selenium 기반의 각 API 호출은 브라우저 프로세스와 WebDriver 세션을 시작하여, 1초 미만의 HTTP 요청을 수 초가 걸리는 작업으로 바꿉니다. 전체 스위트에 걸쳐 이는 길고 불안정한 파이프라인 실행으로 이어집니다. 전용 API 테스트 도구는 브라우저를 시작하지 않으므로 동일한 검사를 훨씬 빠르게 실행합니다.