솔직한 관점
대부분의 도구 비교 글은 벤더가 씁니다. 한쪽이 모든 지표에서 이기고 결론은 항상 “우리 제품을 쓰세요”입니다.
이 글은 그렇지 않으려 합니다. AWX와 Semaphore UI는 겹치는 문제를 풀지만, “당신이 누구이고 무엇을 갖고 있는가”에 대한 가정이 다릅니다. 정답은 상황에 따라 달라집니다.
각 도구가 하는 일, 아키텍처, 기능 차이, 그리고 무엇보다 어떤 팀이 어떤 도구를 써야 하는지를 다룹니다.
AWX란?
AWX는 Red Hat이 상용 Ansible Automation Platform(AAP)의 기반으로 삼는 오픈소스 업스트림 프로젝트입니다. 웹 UI, REST API, 인프라 전반에서 Ansible 플레이북을 실행하는 태스크 엔진을 제공합니다.
AWX는 무료이며 MIT 라이선스이고 커뮤니티가 지원합니다. Red Hat은 선별된 AWX 릴리스를 가져와 강화한 뒤 “Automation Controller”로 재패키징합니다. 이것이 AAP의 핵심입니다. 기능은 AWX에 먼저 들어가고, 엔터프라이즈 지원은 Automation Controller에 붙습니다.
현재 상태(2026년): 마지막 AWX 릴리스는 2024년 7월 2일의 24.6.1이었습니다. 대규모 아키텍처 재구성 동안 개발이 중단된 상태입니다. 팀은 “기존 애플리케이션 아키텍처가 변경 가능성을 제한한다”며 “기존 시스템으로 혁신할 수 있는 한계에 도달했다”고 인정했습니다. Ansible 컬렉션 awx.awx 역시 적극적인 유지보수가 없다는 지적을 받았습니다. AWX가 “죽었다”는 뜻은 아니고, 명확한 일정 없이 큰 전환기에 있다는 뜻입니다.
Semaphore UI란?
Semaphore UI는 Ansible, Terraform/OpenTofu, Bash, Python, PowerShell 자동화를 실행하기 위한 오픈소스 웹 인터페이스입니다. Go로 작성되었고 외부 런타임 의존성 없이 단일 바이너리로 제공됩니다.
AWX처럼 UI, REST API, 스케줄링, RBAC, 팀 관리를 제공하지만, Kubernetes에 묶여 있지 않고 상용 엔터프라이즈 제품 위에 올라가 있지도 않습니다.
Semaphore는 무료 오픈소스(MIT)와 프로젝트 러너, 2FA, Terraform HTTP 백엔드, 로그보내기를 더하는 Pro 티어가 있습니다. 엔터프라이즈에는 HA, LDAP/SSO, 우선 지원 등이 있습니다.
아키텍처와 설치
여기서 두 도구가 가장 크게 갈립니다.
AWX는 Kubernetes가 필요합니다. v18.0.0부터 프로덕션용 단일 호스트 Docker 배포는 공식적으로 지원되지 않습니다. 동작하는 Kubernetes 클러스터가 필요합니다. 한 대의 k3s, 완전한 멀티 노드 클러스터, 관리형 클라우드 서비스 모두 가능합니다. 권장 방식은 AWX Operator이며 kustomize 3.5.1+가 필요합니다. 최신 릴리스에는 PostgreSQL 15가 필요합니다.
Semaphore는 거의 아무것도 필요 없습니다. 컴파일된 Go 단일 바이너리입니다. 패키지 관리자(apt, dnf), Docker, Helm으로 설치하거나 바이너리를 받아 직접 실행하면 됩니다. 작은 환경에는 SQLite로 충분하고, 프로덕션에는 PostgreSQL 또는 MySQL입니다. 전형적인 Docker 설정은 명령 한 줄입니다.
실무적 차이: AWX를 제대로 구축하려면 시간이 걸리고 Kubernetes에 익숙해야 합니다. Semaphore는 몇 분이면 되고 전제 조건이 거의 없습니다.
| AWX | Semaphore UI | |
|---|---|---|
| 배포 방식 | Kubernetes + AWX Operator | 바이너리, Docker, Helm, 패키지 관리자 |
| 필수 의존성 | Kubernetes, kustomize, PostgreSQL 15 | 없음(SQLite 내장) |
| 권장 최소 RAM | 8 GB | 512 MB |
| 권장 최소 CPU | 4 코어 | 1 코어 |
| 단일 바이너리 설치 | ❌ | ✅ |
| Windows 지원 | ❌ | ✅ |
| 설치 시간 | 수 시간 | 수 분 |
기능 비교
둘 다 핵심 흐름을 다룹니다. 자동화 정의, 인벤토리·자격 증명 구성, 태스크 실행, 로그 확인입니다. 전체 기능 세트에서의 비교는 다음과 같습니다.
| 기능 | AWX | Semaphore UI |
|---|---|---|
| Ansible 플레이북 | ✅ | ✅ |
| Terraform / OpenTofu | ❌(Ansible 모듈로만) | ✅ 네이티브 |
| Bash / 셸 스크립트 | ❌(플레이북으로만) | ✅ 네이티브 |
| Python 스크립트 | ❌(플레이북으로만) | ✅ 네이티브 |
| PowerShell | ❌ | ✅ |
| REST API | ✅ 전체 | ✅ 전체 |
| 스케줄링 | ✅ | ✅ |
| Cron 표현식 | ✅ | ✅ |
| 인벤토리 관리 | ✅ | ✅ |
| 동적 인벤토리 | ✅(내장 플러그인) | ✅(Ansible 경유) |
| RBAC | ✅ 세밀 | ✅ 역할 기반(4단계) |
| LDAP | ✅ | ✅ 엔터프라이즈 |
| SAML | ✅ | ❌ |
| OpenID Connect / OAuth2 | ✅ | ✅(10개 이상 공급자) |
| 2FA(TOTP) | ❌ | ✅ Pro |
| 실행 환경 | ✅(컨테이너 격리) | ✅(러너) |
| 분산 러너 | ❌ | ✅(전역 + 프로젝트별) |
| 웹훅 연동 | ✅ | ✅ |
| 알림 | ✅(이메일, Slack 등) | ✅(Slack, Teams, Telegram, 이메일, Rocket.Chat, Gotify) |
| 감사 로그 | ✅ | ✅ |
| 고가용성 | ✅ | ✅ 엔터프라이즈 |
| 승인 워크플로 | ❌ | ✅(Terraform plan/apply) |
| Terraform HTTP 백엔드 | ❌ | ✅ Pro |
| HashiCorp Vault 연동 | ❌ | ✅ |
| AI 어시스턴트(MCP) | ❌ | ✅ |
| 멀티 도구 워크플로 | ❌ | ✅ |
| 내장 Swagger UI | ✅ | ✅ |
| 오픈소스 라이선스 | Apache 2.0 | MIT |
| 엔터프라이즈 지원 | AAP 경유(연 약 13k달러~) | 애드온으로 제공 |
자동화 범위
AWX는 Ansible 중심입니다. 모든 것이 플레이북을 실행하는 잡 템플릿을 둘러싸고 있습니다. cloud.terraform 컬렉션으로 플레이북 안에서 Terraform을 돌리는 것은 기술적으로 가능하지만 통합용 우회에 가깝고, Terraform state·워크스페이스·plan/apply 승인은 AWX의 네이티브 개념이 아닙니다.
Semaphore는 Ansible, Terraform, Bash, Python, PowerShell을 동급 실행 유형으로 취급합니다. 템플릿을 만들 때 유형을 고르면 UI·변수·승인 흐름이 그에 맞춰집니다. 구성에 Ansible, 프로비저닝에 Terraform을 쓰면 같은 인터페이스에서 우회 없이 둘 다 관리할 수 있습니다.
Ansible만 쓰면 큰 차이가 없습니다. 대부분의 팀처럼 도구를 섞으면 차이가 의미 있습니다.
접근 제어
둘 다 역할 기반 접근 제어를 지원하지만 구현이 다릅니다.
AWX는 객체 수준의 세밀한 권한이 있습니다. 특정 잡 템플릿, 인벤토리, 자격 증명에 사용자별로 독립적으로 접근을 줄 수 있습니다. 감사 역할은 모두 볼 수 있지만 바꿀 수 없습니다. RBAC는 LDAP나 SAML에서 동기화할 수 있습니다.
Semaphore의 RBAC는 프로젝트 범위에 Owner, Manager, Task Runner, Guest 네 역할이 있습니다. Owner와 Manager가 구성을 통제하고, Task Runner는 태스크만 실행하며 수정은 못 합니다. Guest는 읽기 전용입니다. 대부분의 팀 구조를 과도한 복잡성 없이 커버합니다.
규제상 감사자의 세밀한 접근이 필요하면 AWX 모델이 표현력이 큽니다. “자동화를 설정하는 사람”과 “실행하는 사람”만 나누면 되면 Semaphore 모델로 충분하고 훨씬 단순합니다.
팀·조직 규모
AWX는 대기업을 염두에 두고 설계되었습니다. Organizations, Teams, 객체 단위 권한이 엔터프라이즈 계층을 반영합니다. 여러 사업부에 수백 명의 사용자를 관리한다면 AWX 권한 모델이 통제력을 줍니다.
Semaphore는 프로젝트를 주요 격리 경계로 씁니다. 프로젝트마다 인벤토리, 템플릿, 시크릿, 팀이 있습니다. 다중 팀 환경에서는 Semaphore Pro가 Project Runner를 추가해 프로젝트별로 격리된 실행 환경을 둡니다. 뉴욕 러너는 뉴욕 인프라, 프랑크푸르트 러너는 프랑크푸르트 인프라를 담당합니다. 서로 다른 프로젝트의 태스크는 실행 환경을 공유하지 않습니다.
프로젝트 경계가 분명한 최대 약 100명 규모 팀에는 Semaphore 모델이 잘 맞고 관리 가능합니다. 수십 팀과 겹치는 권한을 가진 전사 플랫폼이라면 AWX의 세분도가 오버헤드를 감수할 만할 수 있습니다.
유지보수와 지원의 현실
둘 중 무엇을 쓰든 불편한 이야기입니다.
AWX 커뮤니티 지원은 SLA 없음, 취약성에 대한 명확한 약속 없음, 호환성 보장 없음을 뜻합니다. Red Hat 역시 AWX로 프로덕션 시스템을 관리하는 것은 기업에 “위험할 수 있다”고 말합니다. 이 도구는 Automation Controller의 개발 프리뷰에 가깝고, 커뮤니티가 든든히 받쳐 주는 프로덕션급 플랫폼이라 보기 어렵습니다. 문제가 생기면 스스로 해결해야 합니다.
현재 릴리스 중단은 불확실성을 더합니다. 2024년 7월 이후 릴리스가 없다는 것은 18개월 넘게 버그 수정·보안 패치·신기능이 없다는 뜻입니다. 오늘 AWX를 프로덕션에서 돌리면 적극적 유지보수가 없는 소프트웨어를 운용하는 셈입니다.
Semaphore 커뮤니티 지원도 커뮤니티이지만, 프로젝트는 활발히 개발되고 릴리스도 잦습니다. Pro와 엔터프라이즈는 SLA가 있는 유료 지원(표준 12시간, 긴급 옵션)을 제공합니다. 보장된 응답 시간이 필요하면 그 경로가 있습니다.
둘 다 무료로 Red Hat급 엔터프라이즈 보장을 주지는 않습니다. 차이는 Semaphore는 계속 움직이며 명확한 유료 에스컬레이션 경로가 있다는 점이고, AWX는 AAP 가격대 아래 상용 옵션 없이 정체 상태에 있다는 점입니다.
AWX가 맞는 경우
다음에 해당하면 AWX가 맞습니다.
- 이미 Kubernetes를 운영 중이고 그 운영 부담이 플랫폼에 흡수되어 있다.
- SAML 인증이 필요하다 — Semaphore가 현재 지원하지 않는 프로토콜은 이것뿐이다.
- 자동화가 100% Ansible이고, 결국 AAP가 되는 것의 업스트림을 원한다.
- AAP를 평가 중이고 상용 구독 전에 UI를 익히고 싶다.
- 객체 수준 RBAC가 필요하다 — 프로젝트 전체가 아니라 특정 플레이북만 허용하고 싶다.
- AAP로 이전할 계획이고 설정 이식성이 필요하다(AWX와 AAP는 동일 데이터 모델).
Semaphore UI가 맞는 경우
다음에 해당하면 Semaphore가 맞습니다.
- Kubernetes를 쓰지 않는다(Ansible UI만을 위해 돌리고 싶지 않다).
- Ansible만 쓰지 않는다 — Terraform, Bash, Python, PowerShell, OpenTofu가 스택에 있다.
- 제한된 하드웨어 — 1 CPU·1GB RAM VM으로 충분하다.
- Windows가 필요하다 — Semaphore는 Windows 네이티브, AWX는 아니다.
- CLI 없이 자동화를 실행해야 하는 비기술 사용자가 팀에 있다.
- 비용 때문에 AAP나 Tower를 대체한다 — Semaphore Pro는 월 15달러~, AAP는 연 약 13,000달러.
- Terraform HTTP 백엔드가 필요하다 — Semaphore Pro가 네이티브로 제공한다.
- 예측 가능한 유지보수를 원한다 — 활발한 릴리스, 명확한 로드맵, 5자리 약정 없이 유료 지원.
비용 현실
AWX는 무료지만 비용이 전혀 없지는 않습니다. Kubernetes는 인프라 복잡도와 운영 부담을 늘립니다. 원래 클러스터가 없었다면 AWX만을 위해 올리는 것은 엔지니어링 시간과 클라우드 리소스의 실질 비용입니다.
Semaphore 오픈소스 티어는 작은 VM이나 컨테이너 이상의 인프라 오버헤드 없이 진짜 무료입니다. Pro 플랜은 월 15달러부터입니다. 엔터프라이즈는 맞춤 가격이지만 AAP의 진입 가격과는 다른 축입니다.
Semaphore Pro의 대안이 Ansible Automation Platform이라면 계산이 단순합니다. Semaphore 엔터프라이즈도 AAP 라이선스 비용의 일부에 그칩니다.
요약
AWX와 Semaphore UI는 둘 다 성실한 오픈소스 프로젝트입니다. 둘 다 페이퍼 제품이 아니고 실제 프로덕션 배포가 있습니다. 선택은 제약에 달렸습니다.
Kubernetes에 이미 투자했고, SAML이 필요하거나 AAP로 가는 길이라면 AWX.
10분 안에 설치하고, Ansible만이 아니라 더 많은 것을 다루며, 명확한 지원 경로와 함께 적극 유지되는 것을 원하면 Semaphore UI.
지금 AWX를 검토하면서 Kubernetes 요구나 설치 복잡성에 걸린다면, 그 마찰은 실재하며 기술 부족이 아닙니다. 결정하기 전에 Semaphore와 직접 비교해 볼 가치가 있습니다.
