목차
- 1. 왜 OpenStack Horizon 커스터마이징이 필요했는가
- 2. OpenStack Horizon UI/UX를 쉽게 풀어보면
- 3. 기업 환경 기준으로 설계한 Horizon 커스터마이징 방향
- 4. 실전 구현: OpenStack 대시보드 커스터마이징 단계
- 4-1. 작업 전 백업과 구조 확인
- 4-2. 기본 설정 점검
- 4-3. 브랜딩과 안내 문구 반영
- 4-4. CSS로 Horizon UI/UX 정리
- 4-5. 메뉴와 패널(Panel, 기능 화면 단위) 정리
- 4-6. 정적 리소스 반영
- 5. ⚠️ 실제로 겪었던 트러블슈팅
- 5-1. 수정했는데 화면이 안 바뀌는 문제
- 5-2. 업그레이드 후 Horizon 커스터마이징이 깨지는 문제
- 5-3. 권한은 맞는데 메뉴가 보이지 않는 문제
- 6. 검증: OpenStack Horizon 커스터마이징 결과를 어떻게 확인했나
- 7. 적용 전후 비교 정리
- 8. 자주 묻는 질문과 마무리
- Q1. OpenStack Horizon 커스터마이징은 어디부터 시작하는 게 좋을까요?
- Q2. 템플릿을 크게 바꿔도 될까요?
- Q3. 기업 클라우드 사례에서 가장 효과가 큰 변경은 뭔가요?
[OpenStack] OpenStack Horizon 대시보드 커스터마이징 성공 사례
OpenStack Horizon 커스터마이징 이야기를 꺼내면, 많은 분들이 먼저 "그거 로고만 바꾸는 거 아닌가요?"라고 물으시더라고요. 저도 처음엔 그렇게 생각했습니다. 그런데 실제 기업 환경에서 OpenStack 대시보드(Horizon Dashboard)를 운영해보니, 로고 몇 개 바꾸는 수준으로는 끝나지 않더군요. 사용자 권한별 메뉴 정리, 운영팀에 맞춘 화면 흐름, 브랜드 가이드 반영, 그리고 실수 줄이기 위한 UI/UX 개선까지 손볼 게 꽤 많았습니다. 특히 여러 부서가 같은 클라우드 포털을 쓰는 환경에서는 Horizon 대시보드 UI/UX가 생각보다 업무 효율에 큰 영향을 줍니다.
제가 직접 해보니, OpenStack Horizon 커스터마이징은 단순한 꾸미기가 아니라 운영 표준화와 사용자 실수 방지를 위한 작업에 가깝습니다. 오늘 글에서는 제가 실제로 기업형 사설 클라우드(Private Cloud, 사설 클라우드) 환경에서 적용했던 방식들을 바탕으로, 어떤 포인트를 바꿨고 왜 그게 효과적이었는지 차근차근 풀어보겠습니다.
기업용 OpenStack 대시보드와 인증, 네트워크, 프로젝트 구성이 연결된 전체 아키텍처 개요입니다.
1. 왜 OpenStack Horizon 커스터마이징이 필요했는가
쉽게 말해, 기본 Horizon은 범용으로 잘 만들어져 있지만 모든 회사의 운영 방식에 딱 맞지는 않습니다. 개발팀은 빠른 인스턴스 생성이 중요하고, 보안팀은 권한과 노출 메뉴를 더 민감하게 보거든요. 운영팀 입장에서는 "눌러도 되는 버튼"과 "보이면 안 되는 버튼"을 명확히 나누는 게 훨씬 중요했습니다.
처음엔 기본 화면으로도 되겠지 싶었는데, 실제로 써보니까 다음 문제가 반복됐습니다.
- 프로젝트(Project, 테넌트 단위 자원 공간)마다 필요한 메뉴가 다른데 화면은 모두 동일하게 보임
- 사용자가 자주 안 쓰는 메뉴까지 노출되어 클릭 실수가 잦음
- 사내 포털과 디자인 톤이 달라 이질감이 큼
- 운영 공지나 가이드 링크가 없어 문의가 헬프데스크로 몰림
여기서 중요한 포인트! 기업 클라우드 사례를 보면 기술 자체보다 사용자 경험 때문에 만족도가 갈리는 경우가 정말 많습니다. 특히 OpenStack Horizon 대시보드는 인프라팀만 보는 화면이 아니라, 개발자와 운영자, 때로는 외부 협력사도 함께 쓰는 경우가 있거든요.
2. OpenStack Horizon UI/UX를 쉽게 풀어보면
Horizon은 Django(장고, Python 기반 웹 프레임워크) 위에서 동작하는 OpenStack 웹 대시보드입니다. 다시 말해, 웹 템플릿과 설정 파일, 정적 리소스(static assets)를 조정해서 기업 환경에 맞게 바꿀 수 있다는 뜻입니다.
제가 현장에서 가장 자주 손댄 영역은 크게 네 가지였습니다.
- 브랜딩(Branding, 로고/색상/문구 통일)
- 메뉴 구조 정리
- 안내 문구와 링크 보강
- 권한별 화면 노출 최소화
사실 이 네 가지만 잘 정리해도 체감이 확 달라집니다. 사용자 입장에서는 "이 시스템이 우리 회사용으로 잘 다듬어져 있네"라는 느낌을 받게 되더라고요.
3. 기업 환경 기준으로 설계한 Horizon 커스터마이징 방향
커스터마이징에 들어가기 전에 저는 먼저 요구사항을 표로 정리했습니다. 이 단계 안 하고 바로 파일부터 건드리면 삽질 확률이 높습니다 ㅎㅎ
| 항목 | 기본 Horizon | 기업 환경 최적화 방향 |
|---|---|---|
| 브랜드 노출 | 기본 로고/문구 중심 | 사내 포털과 동일한 로고, 색상, 안내 문구 반영 |
| 메뉴 구성 | 범용 메뉴 다수 노출 | 부서별 필요한 메뉴만 우선 노출 |
| 사용자 안내 | 기본 도움말 위주 | 운영 가이드, 문의 채널, 정책 링크 추가 |
| 실수 방지 | 기본 버튼/플로우 유지 | 경고 문구, 기본값 정리, 불필요 기능 숨김 |
이런 식으로 기준을 잡아두면 OpenStack Horizon 커스터마이징의 범위가 명확해집니다. 무작정 예쁘게 만드는 게 아니라, 운영 효율과 장애 예방에 초점을 맞출 수 있거든요.
4. 실전 구현: OpenStack 대시보드 커스터마이징 단계
이제 실제 작업 흐름입니다. 아래 예시는 Horizon이 일반적인 패키지 기반 배포 환경에 설치되어 있다는 가정으로 정리했습니다. 배포판이나 패키징 방식에 따라 경로는 조금 다를 수 있습니다. 저도 처음엔 경로가 배포판마다 미묘하게 달라서 좀 헤맸습니다.
4-1. 작업 전 백업과 구조 확인
sudo cp -a /etc/openstack-dashboard /etc/openstack-dashboard.bak
sudo cp -a /usr/share/openstack-dashboard /usr/share/openstack-dashboard.bak
ls /etc/openstack-dashboard
ls /usr/share/openstack-dashboard/openstack_dashboard여기서 핵심은 설정 파일과 정적 파일 위치를 먼저 분리해서 보는 겁니다. 보통 운영 중인 환경에서는 설정은 local_settings.py, 화면 관련 수정은 템플릿이나 정적 리소스 쪽에서 진행하게 됩니다.
4-2. 기본 설정 점검
가장 먼저 확인한 파일은 local_settings.py였습니다. 이 파일은 Horizon 동작에 영향을 주는 핵심 설정이 모여 있어서, 운영 정책 반영의 출발점이 되더라고요.
# /etc/openstack-dashboard/local_settings.py
OPENSTACK_HOST = "controller.example.internal"
WEBROOT = "/horizon/"
ALLOWED_HOSTS = ['*']
# 기업 환경에서는 로그인 후 안내 메시지나 지원 링크를
# 별도 템플릿과 함께 구성하는 경우가 많습니다.물론 실제 운영에서는 ALLOWED_HOSTS를 더 제한적으로 두는 게 일반적입니다. 위 예시는 구조 설명용입니다.
4-3. 브랜딩과 안내 문구 반영
사용자 만족도에 가장 빨리 반응이 오는 부분이 이겁니다. 로고, 상단 문구, 로그인 화면 설명을 사내 기준에 맞춰 정리해두면 문의량이 꽤 줄어듭니다.
sudo mkdir -p /usr/share/openstack-dashboard/openstack_dashboard/static/custom
sudo mkdir -p /usr/share/openstack-dashboard/openstack_dashboard/templates/custom<div class="login-note">
<p><strong>사내 클라우드 포털</strong>입니다.</p>
<p>프로젝트 생성 정책과 보안 가이드는 내부 문서를 참고해 주세요.</p>
</div>이런 식으로 안내 문구를 넣어두면 "이건 어디에 문의하나요?" 같은 반복 질문이 확실히 줄어듭니다. 별거 아닌 것 같아도 현장에서는 꽤 큽니다.
기업 로고, 색상, 안내 문구가 반영된 Horizon 로그인 화면 예시입니다.
4-4. CSS로 Horizon UI/UX 정리
운영팀이 요청했던 건 화려한 디자인이 아니라, 눈에 잘 들어오는 구조였습니다. 그래서 저는 경고성 버튼 색상, 상단 배너, 도움말 박스 정도만 정리했습니다.
/* custom.css */
.topbar {
background-color: #1f3a5f;
}
.login-note {
margin-top: 16px;
padding: 12px;
border-left: 4px solid #1f3a5f;
background: #f4f7fb;
}
.btn-danger {
font-weight: 700;
}과한 커스터마이징은 업그레이드 때 발목을 잡습니다. 그래서 저는 CSS도 최소 범위로 유지했습니다. 이게 나중에 진짜 편하더라고요.
4-5. 메뉴와 패널(Panel, 기능 화면 단위) 정리
Horizon은 enabled 디렉터리 아래 설정으로 패널 노출을 제어하는 구조를 많이 씁니다. 기업 환경에서는 여기서 자주 안 쓰는 메뉴를 정리하거나 특정 기능을 숨기는 방식이 효과적이었습니다.
ls /usr/share/openstack-dashboard/openstack_dashboard/enabled
ls /usr/share/openstack-dashboard/openstack_dashboard/local/enabled# 예시: 커스텀 패널 등록 또는 기본 패널 순서 조정 시 사용하는 형식 예시
PANEL = 'overview'
PANEL_DASHBOARD = 'project'
PANEL_GROUP = 'compute'
ADD_PANEL = 'openstack_dashboard.dashboards.project.overview.panel.Overview'여기서는 배포 환경에 따라 파일 이름과 구성 방식이 조금 다를 수 있으니, 기존 enabled 파일 구조를 먼저 읽고 맞춰 들어가는 게 안전합니다. 저도 예전에 이걸 무시하고 새 파일부터 만들었다가, 로딩 순서 때문에 화면이 안 뜬 적이 있었습니다. 삽질 좀 했습니다 ㅎㅎ
4-6. 정적 리소스 반영
Django 기반 앱이다 보니, 수정 후에는 정적 리소스 수집과 웹 서버 재시작이 필요할 수 있습니다.
sudo python manage.py collectstatic --noinput
sudo systemctl restart apache2
# 환경에 따라 httpd를 사용할 수도 있습니다.이 단계에서 파일은 바뀌었는데 화면은 그대로라면, 대부분 캐시나 정적 파일 반영 문제였습니다. 처음엔 "내가 잘못 수정했나?" 싶었는데 알고 보니 브라우저 캐시인 경우도 많더라고요.
프로젝트 대시보드, 패널 그룹, 메뉴 노출 흐름을 설명하는 구성 다이어그램입니다.
5. ⚠️ 실제로 겪었던 트러블슈팅
여기서부터가 현업 포인트입니다. 문서만 보면 쉬워 보이는데, 실제 운영 환경에서는 생각보다 자잘한 이슈가 많습니다.
5-1. 수정했는데 화면이 안 바뀌는 문제
- 정적 파일 수집이 반영되지 않았는지 확인
- 웹 서버 재시작 여부 확인
- 브라우저 캐시 강제 새로고침 확인
- 수정 경로가 실제 서비스 경로와 같은지 재확인
특히 패키지 업그레이드 후 경로가 달라졌는데 예전 위치만 수정하고 있는 경우가 있었습니다. 이건 진짜 허무합니다.
5-2. 업그레이드 후 Horizon 커스터마이징이 깨지는 문제
이건 거의 반드시 한 번은 겪습니다. 템플릿 파일을 직접 크게 덮어쓴 경우, Horizon 버전 변경 시 구조 차이 때문에 충돌이 나기 쉽습니다. 그래서 저는 다음 원칙으로 정리했습니다.
- 가능하면 전체 템플릿 교체보다 최소 오버라이드만 적용
- CSS와 안내 문구 중심으로 커스터마이징 범위 제한
- 변경 파일 목록을 Git(깃, 형상관리)이나 문서로 반드시 관리
- 업그레이드 전후 비교 테스트 체크리스트 운영
5-3. 권한은 맞는데 메뉴가 보이지 않는 문제
이 경우는 RBAC(Role-Based Access Control, 역할 기반 접근 제어) 정책과 Horizon 메뉴 노출 조건을 함께 봐야 합니다. 백엔드 정책과 프론트 메뉴 조건이 어긋나면 사용자 입장에서는 "권한이 있는데 왜 안 보이지?"가 되거든요. 저도 처음엔 Keystone(키스톤, 인증/권한 서비스) 쪽만 봤다가 한참 돌아갔습니다.
6. 검증: OpenStack Horizon 커스터마이징 결과를 어떻게 확인했나
커스터마이징은 예쁘게 보이면 끝이 아니라, 실제 운영 효과가 있어야 합니다. 저는 검증을 아래 순서로 진행했습니다.
- 관리자 계정과 일반 프로젝트 사용자 계정으로 각각 로그인
- 메뉴 노출 범위가 의도대로 다른지 확인
- 인스턴스 생성, 볼륨 연결, 네트워크 조회 같은 자주 쓰는 작업을 반복 테스트
- 운영 가이드 링크와 공지 문구가 정상 노출되는지 점검
- 브라우저별 렌더링 차이 확인
실제로 써보니까 가장 반응이 좋았던 건 두 가지였습니다. 첫째, 불필요한 메뉴를 줄이니 사용자가 덜 헷갈렸습니다. 둘째, 로그인 화면과 상단 안내에 운영 기준을 넣어두니 헬프데스크 티켓이 덜 쌓이더군요. 숫자를 지어내서 말씀드리진 않겠습니다만, 체감상 차이는 분명했습니다.
권한별 메뉴 정리와 브랜드 요소가 반영된 최종 OpenStack 대시보드 예시입니다.
7. 적용 전후 비교 정리
| 비교 항목 | 적용 전 | 적용 후 |
|---|---|---|
| 첫 화면 인상 | 범용 솔루션 느낌 | 사내 포털과 일관된 브랜드 경험 |
| 사용자 혼란도 | 메뉴가 많아 진입 장벽 존재 | 필요 기능 중심으로 단순화 |
| 운영 문의 | 기본 사용법 문의 빈번 | 가이드 노출로 반복 문의 감소 |
| 업그레이드 부담 | 직접 덮어쓰기 시 위험 큼 | 최소 변경 원칙으로 관리 용이 |
혹시 이런 경험 있으신가요? "기능은 멀쩡한데 왜 이렇게 쓰기 어렵지?" 하는 느낌이요. Horizon 대시보드 UI/UX는 바로 그 지점을 손보는 작업입니다. 클라우드는 결국 사람이 쓰는 도구니까요.
브랜딩, 메뉴 구조, 사용자 안내 측면에서 적용 전후 차이를 요약한 인포그래픽입니다.
8. 자주 묻는 질문과 마무리
Q1. OpenStack Horizon 커스터마이징은 어디부터 시작하는 게 좋을까요?
제 경험상 브랜딩보다 메뉴 정리가 먼저입니다. 로고보다 중요한 건 사용자가 덜 헷갈리게 만드는 구조거든요.
Q2. 템플릿을 크게 바꿔도 될까요?
가능은 하지만, 업그레이드 유지보수를 생각하면 최소화하는 편이 좋습니다. 처음엔 멋있어 보여도 나중에 고생합니다.
Q3. 기업 클라우드 사례에서 가장 효과가 큰 변경은 뭔가요?
권한별 메뉴 노출 정리, 운영 가이드 링크 추가, 경고 문구 보강. 이 세 가지가 체감 효과가 컸습니다.
정리하자면, OpenStack Horizon 커스터마이징은 화면을 예쁘게 꾸미는 일이 아니라 운영 프로세스를 UI에 녹여내는 작업입니다. 제가 직접 해보니, 기술적인 난이도보다도 "무엇을 숨기고 무엇을 드러낼지"를 정하는 게 더 중요했습니다. 그 기준만 잘 잡으면 OpenStack Horizon 대시보드는 훨씬 실무 친화적으로 바뀝니다.
다음 글에서는 Horizon과 Keystone 정책을 함께 보면서, 권한별 메뉴 제어를 좀 더 깊게 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 기반 OpenStack 구성 글이 있다면 그것과 함께 보셔도 흐름이 잘 이어질 거예요. 기업 환경 최적화는 결국 작은 불편을 하나씩 걷어내는 과정이더라고요. 드디어 됐다! 싶은 순간이 분명 옵니다.
'IT > openstack' 카테고리의 다른 글
| [OpenStack] OpenStack Octavia 성능 벤치마크: 실제 환경 부하 테스트 분석 (0) | 2026.06.23 |
|---|---|
| [OpenStack 비용] 자체 구축 vs 퍼블릭 클라우드 1년 운영비를 정확하게 계산하는 방법 (0) | 2026.06.21 |
