확장 가능하고 세션 인식이 가능한 브라우저 자동화 아키텍처 구축: Selenium Grid, Kubernetes 및 컨테이너 네이티브 솔루션 심층 분석

Executive Summary

사용자의 핵심 과제는 selenium/standalone-chrome 컨테이너를 상태 비저장(stateless) 로드 밸런서 뒤에서 확장할 때 발생하는 세션 지속성 실패 문제입니다. 이 보고서는 이 문제에 대한 세 가지 주요 해결책 범주를 심층적으로 탐구합니다. 첫째, Selenium Grid 4가 제공하는 공식적인 분산 아키텍처를 활용하여 문제를 해결하는 방법을 제시합니다. 둘째, Kubernetes Ingress와 같은 네트워크 계층 도구를 사용하여 "스티키 세션(sticky sessions)"을 강제하는 인프라 수준의 세션 어피니티(session affinity) 방법을 분석합니다. 마지막으로, Selenoid, Zalenium 또는 Aerokube Moon과 같이 컨테이너화된 환경을 위해 특별히 설계된 차세대 전문 플랫폼으로 전환하는 방안을 검토합니다. 결론적으로, 일반적인 기업 환경의 확장성 및 복원력 요구사항을 기반으로 가장 견고하고 미래 지향적인 솔루션을 제시하며, 독자가 최적의 아키텍처를 선택할 수 있도록 안내합니다.

---

섹션 1: 아키텍처 결함 진단: 독립형 Selenium 컨테이너 확장의 함정

이 섹션에서는 사용자의 현재 접근 방식에 내재된 근본적인 결함을 분석하여 문제의 원인을 명확히 규명합니다. 이는 이어지는 해결책 제시의 이론적 기반이 될 것입니다.

1.1. selenium/standalone-chrome의 역할과 한계

Selenium 4의 standalone 모드는 Hub, Node, 브라우저 드라이버를 단일 프로세스 또는 컨테이너에 모두 포함하는 올인원 패키지입니다.¹ 이 모드의 주된 용도는 완전한 분산 그리드의 오버헤드 없이 로컬 환경에서 간단한 테스트를 실행하거나 소규모 프로젝트를 진행하는 것입니다.¹

standalone JAR 또는 컨테이너 내부에는 Router, Distributor, Session Map과 같은 Grid 4의 모든 구성 요소가 암묵적으로 실행되지만, 이들은 모두 해당 단일 인스턴스 내에 국한됩니다.¹

가장 중요한 점은 각 standalone 컨테이너가 완전히 고립된 독립적인 Selenium Grid라는 사실입니다. 각 컨테이너는 자신만의 내부 세션 맵(Session Map)을 가지며, 다른 형제 컨테이너에서 실행 중인 세션에 대해서는 전혀 알지 못합니다.²

1.2. 상태 비저장 로드 밸런서: 세션 라우팅 실패의 근본 원인

Docker Swarm, Kubernetes Service 또는 클라우드 제공업체의 로드 밸런서와 같은 표준 로드 밸런서의 기본 동작은 일반적으로 라운드 로빈(round-robin) 또는 최소 연결(least-connections) 방식입니다.⁸ 이러한 로드 밸런서의 목표는 애플리케이션 수준의 "세션" 컨텍스트에 대한 이해 없이 트래픽을 균등하게 분산하는 것입니다.

이로 인해 다음과 같은 실패 시나리오가 발생합니다.

1. 요청 1 (세션 생성) -> 로드 밸런서 -> 컨테이너 A. 컨테이너 A는 세션 ID-123을 생성하고 클라이언트에게 반환합니다.
2. 요청 2 (ID-123에 대한 명령 실행) -> 로드 밸런서 -> 컨테이너 B.
3. 컨테이너 B는 ID-123에 대한 요청을 수신하고, 자신의 내부 세션 맵을 확인합니다. 해당 세션이 존재하지 않으므로 오류를 반환합니다.

이는 Selenium의 버그가 아니라, 상태 저장(stateful) 애플리케이션(Selenium 세션)과 상태 비저장(stateless) 분산 메커니즘 간의 근본적인 아키텍처 불일치에서 비롯된 문제입니다. 이러한 시나리오는 상태가 임시 인스턴스 내에서 로컬로 관리되는 분산 시스템에서 발생하는 고전적인 문제입니다.⁹

1.3. 분석 및 시사점

사용자는 여러 standalone 인스턴스가 하나의 통합된 그리드를 형성할 수 있다고 잘못 가정했습니다. 실제로는 여러 개의 독립적이고 서로 경쟁하는 그리드를 생성한 것입니다. 더 나아가, 단순히 컨테이너 수를 늘리는 방식으로 손쉽게 확장을 시도한 것이 아키텍처 안티패턴으로 이어진 것입니다. standalone 이미지의 단순함은 매력적이지만, 분산 시스템에 필요한 상태 관리의 복잡성을 감추고 있습니다.

이러한 접근 방식의 실패는 중요한 원칙을 드러냅니다. 확장 전략은 반드시 애플리케이션의 아키텍처와 호환되어야 합니다. 상태 저장 애플리케이션을 상태 비저장 애플리케이션처럼 취급하면 예기치 않은 문제가 발생할 수밖에 없습니다. 사실 이 문제는 Selenium Grid 4가 완전히 재설계된 이유를 명확히 보여줍니다. 이전 버전인 Grid 3 역시 유사한 상태 관리 및 확장성 문제를 겪었으며, Grid 4의 새로운 마이크로서비스 스타일 분산 아키텍처는 바로 이러한 문제를 해결하기 위해 고안되었습니다.⁵ 즉, 사용자가 겪고 있는 문제는 현대적인 Grid 4 설계의 타당성을 역설적으로 증명하는 셈입니다.

---

섹션 2: 표준 해결책: 진정한 Selenium Grid 4 분산 아키텍처 구현

이 섹션에서는 Selenium 프로젝트가 의도한 공식 아키텍처를 사용하여 문제를 올바르게 해결하는 방법을 제시합니다.

2.1. Selenium Grid 4 아키텍처 심층 분석

Selenium Grid 4는 분산 테스트를 위해 특별히 설계된 현대적인 아키텍처를 채택했습니다.⁵ 이는 이전 버전의 단일체(monolithic) Hub와 대조됩니다. 각 핵심 구성 요소의 역할은 다음과 같습니다.

• Router: 모든 테스트 요청의 단일 진입점 역할을 하는 그리드의 "정문"입니다.10
• New Session Queue: 들어오는 세션 요청을 FIFO(First-In, First-Out) 방식으로 보관하는 큐입니다. 그리드의 과부하를 방지하고 요청을 순서대로 처리합니다.5
• Distributor: 그리드의 "두뇌" 역할을 합니다. 큐에서 요청을 가져와 요청된 사양(capabilities)과 일치하는 가용 Node를 찾아 새 세션을 특정 Node에 할당합니다.5
• Session Map: 이것이 바로 사용자의 문제를 직접적으로 해결하는 핵심 구성 요소입니다. 모든 session_id를 해당 세션이 실행 중인 특정 Node의 URI에 매핑하는 중앙 집중식 키-값 저장소(데이터 저장소)입니다.6
• Node: 브라우저 명령을 실행하는 작업자 머신 또는 컨테이너입니다. 자신의 사양을 Distributor에 등록합니다.5
• Event Bus: 구성 요소 간의 내부 통신을 위한 메시징 백본으로, 직접적인 HTTP 호출 의존도를 줄입니다.11

2.2. 분산 그리드에서의 세션 라우팅 흐름

분산 그리드에서 세션은 다음과 같은 생명주기를 거칩니다.¹⁰

1. 클라이언트가 "새 세션" 요청을 Router로 보냅니다.
2. Router는 이 요청을 New Session Queue로 전달합니다.
3. Distributor가 큐에서 요청을 가져와 일치하는 유휴 Node를 찾습니다.
4. Distributor는 선택된 Node에 브라우저 세션을 생성하도록 명령합니다.
5. Node는 세션 생성을 확인하고 세션 세부 정보를 반환합니다.
6. 결정적으로, Distributor는 Session Map에 {"session_id": "ID-123", "node_uri": "http://node-chrome-1:5555"}와 같은 항목을 기록합니다.
7. 세션 ID가 클라이언트에게 반환됩니다.
8. 클라이언트가 ID-123에 대한 후속 명령을 Router로 보냅니다.
9. Router는 이것이 기존 세션에 대한 요청임을 인지하고, ID-123을 키로 Session Map을 조회합니다.
10. Session Map은 http://node-chrome-1:5555를 반환합니다.
11. Router는 Distributor를 거치지 않고 해당 명령을 올바른 Node로 직접 전달합니다. 이로써 세션 지속성이 보장됩니다.

2.3. Docker Compose를 이용한 실제 구현

Docker Compose는 로컬 환경이나 단일 호스트에서 이러한 다중 컨테이너 애플리케이션을 정의하고 실행하는 데 이상적인 도구입니다.¹¹ 다음은 견고한 Hub 및 Node 설정을 위한

docker-compose.yml 예시입니다.

YAML

# docker-compose-hub-node.yml
version: "3"
services:
selenium-hub: # Router, Distributor, Session Map 등을 포함하는 Hub
image: selenium/hub:latest
container_name: selenium-hub
ports:
- "4442:4442" # Event Bus Publish
- "4443:4443" # Event Bus Subscribe
- "4444:4444" # 주 Router 진입점

chrome-node:
image: selenium/node-chrome:latest
depends_on:
- selenium-hub
environment:
# 이 Node를 Hub의 Event Bus에 연결
- SE_EVENT_BUS_HOST=selenium-hub
- SE_EVENT_BUS_PUBLISH_PORT=4442
- SE_EVENT_BUS_SUBSCRIBE_PORT=4443
# 확장 예시: docker-compose up --scale chrome-node=5

이 파일의 각 부분, 특히 Node를 Hub에 연결하는 데 필수적인 environment 변수들은 Node가 Hub의 Event Bus를 찾을 수 있도록 설정하는 핵심적인 역할을 합니다.¹¹

docker-compose up --scale chrome-node=5와 같은 명령어를 통해 그리드를 시작, 확장 및 종료할 수 있습니다.

2.4. 분석 및 시사점

공식 Selenium Grid 4 아키텍처는 Session Map에서 상태를 중앙 집중화함으로써 세션 라우팅 문제를 직접적으로 해결합니다. 하지만 이는 아키텍처적 트레이드오프를 수반합니다. 세션 상태를 중앙 집중화하면 Grid 4 Hub(특히 Session Map과 Distributor)가 시스템의 핵심 구성 요소가 됩니다. 이는 라우팅 문제를 해결하는 동시에 잠재적인 단일 장애점(SPOF) 및 성능 병목 지점을 만듭니다.

만약 selenium-hub 컨테이너가 충돌하면 어떻게 될까요? Session Map은 기본적으로 메모리에 저장되므로, 충돌 시 모든 활성 세션 매핑이 사라져 진행 중인 모든 테스트가 실패하게 됩니다. 이는 Grid 4 아키텍처가 큰 발전을 이루었음에도 불구하고, 진정한 고가용성을 달성하기 위해서는 Hub 구성 요소 자체를 이중화하고 상태를 영구적으로 만들어야 함을 시사합니다(예: Session Map을 외부 Redis 저장소로 백업). 이러한 복잡성은 Grid 4가 본질적으로 클라우드 네이티브 환경에 친화적인 마이크로서비스 기반 인프라 도구로 나아가는 추세를 보여줍니다.⁵

---

섹션 3: 인프라 수준 접근 방식: Kubernetes Ingress를 통한 세션 어피니티 강제

이 섹션에서는 다른 철학을 탐구합니다. 애플리케이션이 상태를 인식하도록 만드는 대신, 네트워크 인프라가 상태를 인식하도록 만드는 방법입니다.

3.1. 세션 어피니티("스티키 세션") 소개

세션 어피니티는 단일 클라이언트의 모든 요청을 세션이 지속되는 동안 동일한 백엔드 서버/파드(pod)로 보내는 로드 밸런싱 전략입니다.⁸ 이 방법은 테스트 실행과 관련된 모든 API 호출을 세션을 처음 생성한

standalone-chrome 컨테이너에 "고정"시킴으로써 사용자의 문제를 해결할 수 있습니다. 주요 방법으로는 ClientIP 기반과 쿠키 기반 어피니티가 있습니다.⁸

3.2. 이 사용 사례에서 쿠키 기반 어피니티가 더 우수한 이유

ClientIP 기반 어피니티는 소스 IP가 NAT 게이트웨이, 기업 프록시에 의해 마스킹되거나 세션 중에 변경될 수 있어 신뢰성이 떨어집니다. 특히 Kubernetes 환경에서는 서비스가 보는 소스 IP가 원래 클라이언트가 아닌 내부 프록시의 IP일 수 있어 무용지물이 될 수 있습니다.⁸

반면, 쿠키 기반 어피니티는 Ingress 컨트롤러가 클라이언트에 대한 첫 번째 응답에 고유한 쿠키를 주입하는 방식으로 작동합니다. 클라이언트는 이후 모든 요청에 이 쿠키를 포함하며, Ingress 컨트롤러는 이 쿠키를 사용하여 요청을 원래 파드로 다시 라우팅합니다.¹⁵ 이 방법이 훨씬 더 안정적입니다.

3.3. NGINX Ingress Controller를 이용한 실제 구현

다음은 NGINX Ingress Controller를 사용하여 스티키 세션을 구현하는 Kubernetes Ingress 매니페스트 예시입니다.

YAML

# ingress-sticky-session.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: selenium-sticky-ingress
annotations:
# 쿠키 기반 어피니티 활성화
nginx.ingress.kubernetes.io/affinity: "cookie"
# 라우팅에 사용할 쿠키 이름 지정
nginx.ingress.kubernetes.io/session-cookie-name: "SELENIUM_SESSION_ROUTE"
# 합리적인 쿠키 만료 시간 설정 (예: 30분)
nginx.ingress.kubernetes.io/session-cookie-max-age: "1800"
# 선택 사항: 쿠키 경로 정의
nginx.ingress.kubernetes.io/session-cookie-path: "/"
spec:
rules:
- host: selenium-grid.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: selenium-standalone-service # standalone 파드를 로드 밸런싱하는 서비스
port:
number: 4444

이 매니페스트는 nginx.ingress.kubernetes.io/affinity: "cookie" 어노테이션을 사용하여 스티키 세션을 활성화합니다.⁸ 이를 적용하기 위해서는 실행 중인 Kubernetes 클러스터, NGINX Ingress Controller, 그리고

Service를 통해 노출된 selenium/standalone-chrome 파드의 Deployment가 필요합니다.

3.4. 스티키 세션의 트레이드오프에 대한 비판적 분석

스티키 세션은 즉각적인 라우팅 문제를 해결할 수 있지만, 몇 가지 단점이 있습니다.

• 불균등한 부하 분산: 세션이 균등하게 분산되지 않습니다. 하나의 테스트가 매우 길면 해당 파드는 계속 바쁜 상태로 남아 다른 파드는 유휴 상태일 수 있습니다. 이는 리소스 "핫스팟"을 유발할 수 있습니다.8
• 장애 허용성 감소: 사용자가 "고정된" 특정 파드가 충돌하거나 종료되면(예: 스팟 인스턴스에서) 세션은 완전히 손실됩니다. 장애 조치가 없습니다.9
• 확장 복잡성: 파드 수를 늘려도 새 파드는 새로운 세션만 받게 됩니다. 기존 세션은 재분배되지 않아 새로운 리소스를 비효율적으로 사용하게 됩니다.20

3.5. 분석 및 시사점

스티키 세션은 실행 가능하지만 결함이 있는 해결책입니다. 이는 즉각적인 라우팅 문제를 해결하지만, 2차적인 안정성 및 효율성 문제를 야기합니다. 이 접근 방식은 근본 원인인 부적절한 상태 관리 아키텍처 대신 증상(잘못된 라우팅)을 치료하는 것과 같습니다. 즉, 애플리케이션 계층의 전략적 문제를 인프라 계층에서 전술적으로 수정하는 것입니다.

이러한 접근은 클라이언트 세션을 단일하고 임시적인 파드에 강하게 결합시킵니다. Kubernetes와 같은 동적 오케스트레이션 환경에서 파드는 본질적으로 소멸 가능하도록 설계되었습니다.⁹ 장시간 실행될 수 있는 사용자 세션을 소멸 가능한 파드에 묶는 것은 본질적으로 위험합니다. 가장 견고한 시스템은 애플리케이션 아키텍처가 인프라의 특성에 역행하는 것이 아니라, 그와 조화를 이루도록 설계된 시스템입니다.

---

섹션 4: 차세대 솔루션: 컨테이너 네이티브 브라우저 자동화 플랫폼 검토

이 섹션에서는 사용자가 요청한 기성 전문 인프라 솔루션에 대해 직접적으로 답변합니다.

4.1. Selenoid: 경량의 온디맨드 엔진

• 아키텍처: Selenoid는 Selenium Hub를 대체하는 경량의 단일 Go 바이너리입니다. 새 세션 요청을 수신하면 정적 노드로 라우팅하는 대신, 각 테스트마다 격리된 새 브라우저 컨테이너를 Docker API를 통해 동적으로 시작합니다. 그런 다음 모든 통신을 해당 컨테이너로 프록시합니다.22 Selenoid 자체가 컨테이너를 생성하고 프록시 연결을 관리하므로, 별도의 Session Map 구성 요소 없이도 내부적으로 세션 라우팅 문제를 해결합니다.23
• 주요 기능: 모든 테스트에 대해 새로운 브라우저 제공(높은 격리성), 비디오 녹화, 로그 수집, UI(Selenoid-UI).22
• 한계: 주로 Docker용으로 설계되었으며, Kubernetes 스케줄러를 우회하여 노드를 과부하시킬 수 있는 Docker 소켓에 직접 통신하는 방식은 Kubernetes에서 안티패턴으로 간주됩니다.23 또한, 메모리 내 세션 목록을 유지하므로 Selenoid 프로세스 자체가 단일 장애점이 됩니다.27

4.2. Zalenium: 자동 확장, 일회용 그리드

• 아키텍처: Zalenium은 docker-selenium 기반 그리드의 확장을 자동화하는 "Selenium Grid 확장"입니다. 주 Zalenium 컨테이너는 스마트 프록시 및 노드 관리자 역할을 합니다. 새 테스트가 도착하면 이를 처리하기 위해 docker-selenium 노드 컨테이너를 동적으로 시작하고, 비활성 기간이 지나면 노드를 축소합니다.29
• 주요 기능: 동적 확장 및 축소, 대시보드, 라이브 미리보기, 비디오 녹화, 로컬에서 실행할 수 없는 브라우저에 대한 클라우드 테스트 제공업체와의 통합.30
• 참고: Zalenium은 영향력이 있었지만 개발이 둔화되었으며, 공식 GitHub 저장소(zalando/zalenium)는 현재 아카이브 상태입니다.35 따라서 새로운 프로덕션 환경에는 권장되지 않습니다.

4.3. Aerokube Moon: 상태 비저장, Kubernetes 네이티브 엔터프라이즈 솔루션

• 아키텍처: Moon은 Selenoid의 진화된 형태로, Kubernetes를 위해 특별히 제작되었습니다.36 Selenium, Playwright, Cypress를 지원하며, Kubernetes의 기본 기능을 활용하여 최고의 복원력과 확장성을 제공합니다.39
• 세션 라우팅 해결 방식 (상태 비저장 혁신): 이것이 Moon의 핵심 혁신입니다.
  1. 새 세션이 요청되면, Moon은 Kubernetes API를 사용하여 브라우저를 위한 새 Pod를 생성합니다.
  2. 또한 해당 새 파드를 가리키는 고유한 Kubernetes Service를 생성합니다.27
  3. 임의의 UUID를 세션 ID로 반환하는 대신, Moon은 새로 생성된 Kubernetes Service의 DNS 이름(예: chrome-71-0-uuid.moon.svc.cluster.local)을 클라이언트에게 반환합니다.27
  4. 이 "세션 ID"를 사용하는 클라이언트의 모든 후속 명령은 Kubernetes의 내부 DNS 및 네트워킹에 의해 올바른 파드로 직접 라우팅됩니다.
  5. 이는 Moon 자체가 완전히 상태 비저장임을 의미합니다. 세션 맵을 유지할 필요가 없습니다. "상태"는 고가용성의 분산된 Kubernetes 제어 평면 자체에 위임됩니다.27
• 주요 기능: 진정한 상태 비저장(높은 장애 허용성), Kubernetes HPA를 통한 무제한 자동 확장, 균일한 부하 분산, 네임스페이스를 통한 멀티테넌시, 강력한 UI.28
• 시사점: Moon 복제본은 실행 중인 테스트에 영향을 주지 않고 언제든지 종료, 재시작 또는 확장/축소될 수 있습니다. 라우팅은 Kubernetes가 처리하기 때문입니다.27 이는 Selenium Grid나 Selenoid와 같은 상태 저장 시스템이 상당한 추가 엔지니어링 없이는 달성할 수 없는 수준의 복원력입니다.

4.4. 분석 및 시사점

이러한 도구들에는 명확한 진화 경로가 보입니다: Selenium Grid (단일체) -> Selenoid (컨테이너 인식) -> Moon (컨테이너 네이티브/오케스트레이터 네이티브). 이 진화의 각 단계는 기반 인프라(Docker, 그 다음 Kubernetes)에 더 많은 책임을 위임하여 더 견고하고 확장 가능하며 운영이 간단한 시스템을 만듭니다.

이러한 진화는 기반 플랫폼(Kubernetes 등)이 기본적으로 제공하는 기능을 위해 애플리케이션 수준의 로직을 구축하는 것에서 벗어나는 추세를 보여줍니다. 이는 단순히 플랫폼 안에서 구축하는 것이 아니라, 플랫폼 위에서 구축하는 것에 관한 것입니다. 이러한 도구들 사이의 선택은 팀이나 회사의 DevOps 성숙도를 반영합니다. Kubernetes를 전략적 플랫폼으로 깊이 있게 투자한 조직은 Moon이 클라우드 네이티브 원칙과 완벽하게 일치하므로 가장 시너지 효과가 크고 강력한 솔루션임을 발견할 것입니다.

---

섹션 5: 전략적 분석 및 권장 사항

이 마지막 섹션에서는 분석 내용을 종합하여 사용자를 위한 의사 결정 프레임워크를 제공합니다.

5.1. 솔루션 비교 분석

다음 표는 논의된 솔루션들의 핵심적인 차이점을 요약합니다.

기준	Selenium Grid 4 (Hub/Node)	Kubernetes 스티키 세션	Selenoid	Zalenium (아카이브됨)	Aerokube Moon
핵심 아키텍처	분산 마이크로서비스 (Router, Distributor, Session Map 등) 5	지능형 네트워크 계층을 갖춘 표준 배포 8	Docker 인식 Hub 역할을 하는 단일 Go 바이너리 22	docker-selenium 노드를 동적으로 생성/파괴하는 스마트 프록시 30	Kubernetes 네이티브 컨트롤러 역할을 하는 상태 비저장 Go 바이너리 27
세션 관리	중앙 집중식 상태: Hub의 메모리 내 Session Map이 세션 ID를 Node URI에 매핑 10	인프라 상태: Ingress 컨트롤러가 쿠키를 사용하여 클라이언트를 특정 파드에 "고정" 8	로컬 상태: Selenoid 프로세스 내의 메모리 내 맵이 세션을 특정 컨테이너로 프록시 23	중앙 집중식 상태: Zalenium 컨테이너가 Hub 역할을 하며 자식 노드로의 세션 프록시 관리 30	상태 비저장 (위임된 상태): Kubernetes Service DNS 이름을 세션 ID로 사용; 라우팅은 K8s가 처리 27
확장성 모델	Node 컨테이너/VM의 수동 또는 스크립트 기반 확장 (예: docker-compose --scale) 11	표준 Kubernetes Deployment 확장 (예: kubectl scale) 20	단일 Docker 호스트의 리소스로 제한됨; 다중 노드 클러스터용으로 설계되지 않음 23	수요에 따라 단일 Docker 호스트에서 노드 자동 확장/축소 31	전체 클러스터에 걸쳐 Moon 복제본 및 브라우저 파드에 대한 네이티브 Kubernetes 자동 확장(HPA) 28
장애 허용성	낮음: Hub가 단일 장애점. 충돌 시 모든 세션 매핑 손실 (섹션 2.4 분석)	낮음: "고정된" 파드가 죽으면 세션은 장애 조치 없이 손실됨 9	낮음: Selenoid 프로세스가 단일 장애점 28	낮음: Zalenium 컨테이너가 단일 장애점	높음: Moon 복제본은 상태 비저장이며 활성 세션에 영향을 주지 않고 충돌/재시작 가능. Kubernetes가 파드 장애 처리 27
리소스 효율성	중간: Node는 장기 실행됨. 그리드 구성 요소는 전용 리소스 필요 (무거울 수 있음) 42	낮음: 불균등한 부하와 유휴 파드를 유발하여 리소스 낭비 가능 9	높음: 경량 Go 바이너리. 온디맨드 컨테이너는 테스트 중에만 리소스 사용 25	높음: 유휴 상태일 때 동적으로 리소스 축소	매우 높음: 상태 비저장 Go 바이너리는 경량. K8s 클러스터 자동 확장은 최소한의 유휴 리소스 보장 42
설치 복잡성	중간: 구성 요소 아키텍처 이해 및 docker-compose 파일 구성 필요 11	중간: 실행 중인 K8s 클러스터 및 Ingress 어노테이션 지식 필요 16	낮음: 단일 Docker 호스트에서 매우 간단하게 시작 가능 22	낮음: 간단한 docker run 명령으로 시작 가능 31	높음: 실행 중인 Kubernetes 클러스터 및 K8s 매니페스트/Helm에 대한 친숙함 필요 36
주요 기능	공식 Selenium 프로젝트, 관찰 가능성, 유연한 배포 모드 5	K8s Ingress가 이미 사용 중인 경우 간단하게 구현 가능	비디오 녹화, 로그, 테스트별 새로운 환경 22	대시보드, 라이브 미리보기, 비디오 녹화, 클라우드 프록시 30	Playwright/Cypress 지원, 멀티테넌시, 강력한 UI, 엔터프라이즈급 복원력 28
이상적인 사용 사례	표준적이고 잘 문서화된 분산 그리드가 필요한 공식 Selenium 생태계에 전념하는 팀	즉시 애플리케이션을 재설계할 수 없는 Kubernetes 팀을 위한 빠르고 임시적인 수정. 프로덕션용으로는 권장되지 않음	단일 고성능 머신 또는 CI 에이전트에서 테스트를 실행하는 개인 개발자 또는 소규모 팀	(과거) 단일 Docker 호스트에서 간단한 자동 확장이 필요한 팀. 아카이브 상태로 인해 새 프로젝트에는 권장되지 않음	엔터프라이즈 수준의 브라우저 자동화를 위해 가장 확장 가능하고 복원력 있으며 기능이 풍부한 솔루션을 찾는 Kubernetes에 집중 투자하는 팀

5.2. 권장 사항

• 즉각적인 수정 및 표준화를 위해: Selenium Grid 4 Hub 및 Node 아키텍처(섹션 2) 채택을 권장합니다. 이는 사용자의 문제에 대한 공식적이고 잘 지원되는 직접적인 해결책입니다. 분산 시스템의 원칙을 올바르게 적용하며 안정적인 기반을 제공할 것입니다.
• Kubernetes 네이티브 환경을 위해 (전략적 권장 사항): **Aerokube Moon(섹션 4.3)**의 평가 및 채택을 강력히 권장합니다. Kubernetes를 표준화한 모든 조직에게 Moon의 상태 비저장 아키텍처와 깊은 플랫폼 통합은 공식 Selenium Grid를 능가하는 독보적인 복원력, 확장성 및 효율성을 제공합니다. 이는 이 문제 영역에서 현재 가장 진보된 기술을 대표합니다.
• 전술적 해결책으로 (주의해서 사용): **Kubernetes 스티키 세션 접근 방식(섹션 3)**은 임시적이거나 전술적인 해결책으로만 고려해야 합니다. 위험을 명확히 명시하고 프로덕션 등급 테스트 플랫폼을 위한 장기적인 전략이 되어서는 안 됨을 조언합니다.
• 간단한 단일 호스트 설정을 위해: 다중 노드 클러스터 확장성이 필요하지 않은 시나리오에서는 **Selenoid(섹션 4.1)**를 훌륭하고 가벼운 대안으로 언급할 수 있습니다.

---

결론

사용자의 초기 아키텍처 결함에서 시작하여, 단순하지만 잘못된 확장 모델에서 정교하고 복원력 있으며 확장 가능한 인프라로 나아가는 여정을 살펴보았습니다. 핵심 과제는 분산 환경에서의 상태 관리 문제였습니다. 결론적으로, Kubernetes와 같은 오케스트레이터의 힘을 활용하는 컨테이너 네이티브 솔루션으로의 전환이 뚜렷한 추세이며, Moon은 미래 지향적인 아키텍처의 대표적인 예입니다. 현재의 문제를 해결할 뿐만 아니라 조직의 광범위한 인프라 전략과도 일치하는 솔루션을 선택하는 것이 중요합니다.

참고 자료

1. Difference between Selenium Standalone server and Grid | BrowserStack, 9월 19, 2025에 액세스, https://www.browserstack.com/guide/difference-between-selenium-standalone-server-and-selenium-server
2. Selenium Standalone Server and Selenium Server [Differences] - LambdaTest, 9월 19, 2025에 액세스, https://www.lambdatest.com/blog/selenium-standalone-server-and-selenium-server/
3. Getting started with Selenium Grid, 9월 19, 2025에 액세스, https://www.selenium.dev/documentation/grid/getting_started/
4. Selenium grid: all you need to know - DECODE, 9월 19, 2025에 액세스, https://decode.agency/article/selenium-grid-guide/
5. Selenium Grid 4 Tutorial: How to use it | BrowserStack, 9월 19, 2025에 액세스, https://www.browserstack.com/guide/selenium-grid-4-tutorial
6. Selenium Grid 4 Tutorial For Distributed Testing | LambdaTest, 9월 19, 2025에 액세스, https://www.lambdatest.com/blog/selenium-grid-4-tutorial-for-distributed-testing/
7. What is Selenium Server Standalone and How to set it up? - BrowserStack, 9월 19, 2025에 액세스, https://www.browserstack.com/guide/selenium-server-standalone
8. Sticky Session on Kubernetes Cluster | Baeldung on Ops, 9월 19, 2025에 액세스, https://www.baeldung.com/ops/kubernetes-cluster-sticky-session
9. Session Affinity and Kubernetes— Proceed With Caution! | by Paul Dally - Medium, 9월 19, 2025에 액세스, https://pauldally.medium.com/session-affinity-and-kubernetes-proceed-with-caution-8e66fd5deb05
10. Selenium Grid Components | Selenium, 9월 19, 2025에 액세스, https://www.selenium.dev/documentation/grid/components/
11. Setting Up Selenium Grid 4: A Step-by-Step Tutorial for Scalable Test Automation, 9월 19, 2025에 액세스, https://momentic.ai/resources/setting-up-selenium-grid-4-a-step-by-step-tutorial-for-scalable-test-automation
12. A Complete Guide to Selenium Grid 4: Architecture and Configuration - Testsigma, 9월 19, 2025에 액세스, https://testsigma.com/blog/selenium-grid-4/
13. How to Set Up Selenium Grid 4 With Docker Compose - DZone, 9월 19, 2025에 액세스, https://dzone.com/articles/set-up-selenium-grid-with-docker-compose
14. Selenium 4 Grid Architecture - Way2Automation, 9월 19, 2025에 액세스, https://www.way2automation.com/selenium-4-grid-architecture/
15. Sticky sessions and canary releases in Kubernetes - DEV Community, 9월 19, 2025에 액세스, https://dev.to/danielepolencic/sticky-sessions-and-canary-releases-in-kubernetes-5a92
16. Sticky sessions/Session Affinity based on Nginx Ingress on OVHcloud Managed Kubernetes, 9월 19, 2025에 액세스, https://help.ovhcloud.com/csm/en-public-cloud-kubernetes-sticky-session-nginx-ingress?id=kb_article_view&sysparm_article=KB0049963
17. All About Kubernetes Session Affinity - Bobcares, 9월 19, 2025에 액세스, https://bobcares.com/blog/kubernetes-session-affinity/
18. Enable Session Affinity (a.k.a Sticky Session) to Kubernetes service - GitHub Gist, 9월 19, 2025에 액세스, https://gist.github.com/fjudith/e8acc791f015adf6fd47e5ad7be736cb
19. Configure a sticky session - Mirantis Kubernetes Engine, 9월 19, 2025에 액세스, https://docs.mirantis.com/mke/3.8/ops/deploy-apps-k8s/nginx-ingress/configure-sticky-session.html
20. Session Affinity and Kubernetes—Proceed With Caution! - Support Tools, 9월 19, 2025에 액세스, https://support.tools/session-affinity-kubernetes/
21. Services - Kubernetes, 9월 19, 2025에 액세스, https://jamesdefabia.github.io/docs/user-guide/services/
22. Selenoid Tutorial | Docker-Selenium Alternative for Parallel Testing, 9월 19, 2025에 액세스, https://swtestacademy.com/selenoid-tutorial/
23. Selenoid - A cross browser Selenium solution for Docker - Aerokube, 9월 19, 2025에 액세스, https://aerokube.com/selenoid/latest/
24. What Are Selenium, Selenide, Selenoid, Selendroid and What's the Difference Between Them? - TestMatick, 9월 19, 2025에 액세스, https://testmatick.com/what-are-selenium-selenide-selenoid-selendroid-and-what-s-the-difference-between-them/
25. Efficient Selenium Infrastructure with Selenoid, 9월 19, 2025에 액세스, https://seleniumcamp.com/workshop/efficient-selenium-infrastructure-with-selenoid/
26. 6 Ways to Do Automated UI Testing in Parallel With Selenium - Better Programming, 9월 19, 2025에 액세스, https://betterprogramming.pub/6-ways-to-do-automated-ui-testing-in-parallel-with-selenium-132e47403c4f
27. Moon - A cross browser Selenium, Cypress, Playwright and Puppeteer solution for Kubernetes or Openshift cluster - Aerokube, 9월 19, 2025에 액세스, https://aerokube.com/moon/1-latest/
28. Moon - A cross browser Selenium, Cypress, Playwright and ..., 9월 19, 2025에 액세스, https://aerokube.com/moon/latest/
29. opensource.zalando.com, 9월 19, 2025에 액세스, http://opensource.zalando.com/zalenium/#:~:text=A%20flexible%20and%20scalable%20container,tests%20in%20Firefox%20and%20Chrome.
30. Zalenium - A flexible and scalable Selenium Grid. - Zalando Open Source, 9월 19, 2025에 액세스, http://opensource.zalando.com/zalenium/
31. How to set up your Selenium Grid Infrastructure using Zalenium. - GeeksforGeeks, 9월 19, 2025에 액세스, https://www.geeksforgeeks.org/software-testing/how-to-set-up-your-selenium-grid-infrastructure-using-zalenium/
32. How to set up your Selenium Grid Infrastructure using Zalenium - Educative.io, 9월 19, 2025에 액세스, https://www.educative.io/answers/how-to-set-up-your-selenium-grid-infrastructure-using-zalenium
33. Simplify Selenium Grid Management with Zalenium | by Ram - Medium, 9월 19, 2025에 액세스, https://medium.com/@ram.machavaram/simplify-selenium-grid-management-with-zalenium-730c6363c038
34. Selenium Grid, Automated Testing with Zalenium: Best Guide - ContextQA, 9월 19, 2025에 액세스, https://contextqa.com/zalenium-use-selenium-grid-infrastructure/
35. zalando/zalenium: A flexible and scalable container based ... - GitHub, 9월 19, 2025에 액세스, https://github.com/zalando/zalenium
36. Deploy Moon on Azure and Google Cloud | by Ashish Ghosh - Medium, 9월 19, 2025에 액세스, https://ghoshasish99.medium.com/deploy-moon-on-azure-and-google-cloud-607a9604bccc
37. Browser Automation: To Infinity And Beyond | by Alexander Andryashin | Aerokube, 9월 19, 2025에 액세스, https://blog.aerokube.com/browser-automation-to-infinity-and-beyond-94261f305193
38. Moon - Aerokube, 9월 19, 2025에 액세스, https://aerokube.com/moon/1.2.0/
39. A Cross Browser Selenium, Playwright and Cypress Solution For Kubernetes or Openshift Cluster - Aerokube Moon, 9월 19, 2025에 액세스, https://aerokube.com/moon/
40. aerokube/moon: Browser automation solution for Kubernetes and Openshift supporting Selenium, Playwright, Puppeteer and Cypress - GitHub, 9월 19, 2025에 액세스, https://github.com/aerokube/moon
41. Selenium: Exploring the Moon - Aerokube, 9월 19, 2025에 액세스, https://blog.aerokube.com/selenium-exploring-the-moon-b7402936cafe
42. Selenium Grid 4: Do you really need it? | by Alexander Andryashin | Aerokube, 9월 19, 2025에 액세스, https://blog.aerokube.com/selenium-grid-4-do-you-really-need-it-ab03366625b0
43. Test automation: scalable Selenoid as an alternative for Selenium Grid - a1qa, 9월 19, 2025에 액세스, https://www.a1qa.com/blog/test-automation-scalable-selenoid-as-an-alternative-for-selenium-grid/