[OpenStack] 1-1. 한국형 오픈스택의 조건

 

---

이전 글에서 알 수 있듯이 OpenStack은 해외에서 시작된 오픈소스 클라우드 플랫폼이다.

 

그렇다면 해외에서 개발된 OpenStack을 국내 기업의 데이터센터에 설치하기만 하면

곧바로 ‘한국형 OpenStack’이 되는 것일까?

 

그렇지는 않다.

 

OpenStack의 소스 코드를 국내 업체가 설치했다고 해서 한국형 클라우드가 완성되는 것은 아니다.

국내 기업이 사용하는 서버와 네트워크 장비, 보안 체계, 조직 구조, 승인 절차, 운영 인력의 역량까지

반영되어야 실제 업무에서 사용할 수 있는 클라우드가 된다.

 

이러한 환경을 만들기 위해서는 크게 8가지 조건이 필요하다.

 

---

첫 번째 조건 : 국내 인프라에서 검증된 아키텍처

 

OpenStack은 다양한 하드웨어와 소프트웨어를 조합할 수 있다는 장점이 있다.

 

서버는 여러 제조사의 장비를 사용할 수 있고, 네트워크도 기존 스위치와 가상 네트워크 기술을 조합할 수 있다.

스토리지 역시 로컬 디스크, Ceph, 외부 스토리지 장비 등 여러 방식을 선택할 수 있다.

 

하지만 선택지가 많다는 사실이 항상 장점만 되는 것은 아니다.

 

구성요소 사이의 호환성이 충분히 검증되지 않으면 다음과 같은 문제가 발생할 수 있다.

1. 서버 운영체제를 업그레이드한 뒤 가상 머신이 정상적으로 실행되지 않는다.
2. 네트워크 드라이버를 변경한 뒤 기존 포트가 연결되지 않는다.
3. 스토리지 장애가 발생했을 때 복구 시간이 예상보다 길어진다.
4. 특정 장비의 펌웨어와 커널 버전이 충돌한다.
5. OpenStack을 업그레이드했지만 기존 플러그인이 새 버전을 지원하지 않는다.

 

현재 OpenStack은 지속적으로 새로운 버전을 출시하고 있으며,

2026년 7월 기준 최신 유지보수 릴리스 계열은 2026.1 Gazpacho다.

 

OpenStack 릴리스에는 각기 지원 단계와 수명주기가 존재하므로,

단순히 가장 최신 버전을 설치하는 것보다 조직의 업그레이드 계획과 지원 기간에 맞는 버전을 선택하는 것이 중요하다.

 

운영체제와 OpenStack의 호환 관계도 함께 확인해야 한다.

OpenStack-Ansible 공식 문서에서도 OpenStack 릴리스별로 지원하는 운영체제와 버전이 다르며,

Python이나 libvirt 같은 의존성 변화로 운영체제 지원이 조기에 종료될 수 있다고 설명한다.

 

따라서 국내 환경에 적합한 OpenStack을 구축하려면 먼저 다음 항목을 검증해야 한다.

1. 국내 데이터센터에서 사용하는 서버와 NIC가 정상적으로 인식되는가
2. 필요한 운영체제와 커널 버전을 지원하는가
3. 기존 네트워크 장비 및 방화벽과 연결할 수 있는가
4. 사용하려는 스토리지와 Cinder·Glance가 안정적으로 연동되는가
5. 장애가 발생했을 때 대체 노드로 서비스를 전환할 수 있는가
6. 향후 OpenStack과 운영체제를 단계적으로 업그레이드할 수 있는가

 

중요한 것은 단순히 “가상 머신이 만들어졌다”는 사실이 아니다.

 

실제 업무 트래픽을 처리했을 때도

성능이 유지되는지, 일부 장비가 고장 났을 때 서비스가 계속 동작하는지,

업그레이드 이후에도 기존 자원이 정상적으로 관리되는지까지 확인해야 한다.

 

---

두 번째 조건 : 설치 자동화보다 중요한 운영 자동화

 

OpenStack을 구축할 때 흔히 자동 설치를 중요하게 생각한다.

 

여러 서버에 필요한 패키지를 설치하고 설정 파일을 배포하는 작업을 자동화하면

구축 시간을 줄일 수 있기 때문이다.

 

그러나 OpenStack은 한 번 설치하고 끝나는 시스템이 아니다.

운영을 시작한 뒤에는 다음과 같은 작업이 계속 발생한다.

• 컴퓨트 노드 추가 및 제거
• 장애가 발생한 서비스 재시작
• 인증서 교체
• 운영체제 보안 패치
• OpenStack 버전 업그레이드
• 데이터베이스 백업
• 메시지 큐와 API 상태 점검
• 이미지·볼륨·네트워크 자원 정리
• 사용량과 용량 모니터링
• 장애 원인 분석

 

따라서 진정한 자동화는 설치 명령을 한 번 실행하는 것이 아니라

구축부터 변경, 확장, 장애 복구, 업그레이드까지 전체 수명주기를 반복 가능한 방식으로 관리하는 것을 의미한다.

 

예를 들어 컴퓨트 노드 한 대를 추가한다고 가정해보자.

 

수작업 방식이라면 관리자는 운영체제를 설치하고 네트워크를 설정한 뒤,

필요한 패키지와 인증 정보를 구성하고 OpenStack 서비스에 노드를 등록해야 한다.

 

자동화된 환경에서는 장비 정보를 등록한 뒤 정해진 배포 절차를 실행하면 다음 설정이 동일한 기준으로 적용되어야 한다.

• 운영체제와 필수 패키지
• 시간 동기화
• 네트워크 인터페이스
• 인증서
• Nova Compute
• Neutron 에이전트 또는 OVN 구성
• 모니터링 에이전트
• 로그 수집 정책
• 보안 설정

 

이처럼 자동화가 중요한 이유는 단순히 작업 시간을 줄이기 위해서만은 아니다.

 

사람이 장비마다 직접 설정하면 작은 차이가 누적된다.

어떤 서버에는 설정값이 들어가 있고 다른 서버에는 빠지는 ‘구성 불일치’가 발생할 수 있다.

반면 동일한 코드와 템플릿을 사용하면 서버가 늘어나더라도 같은 기준을 반복해서 적용할 수 있다.

 

최근의 OpenStack 운영에서는 Ansible 기반 배포 도구와 컨테이너화된 서비스 운영 방식이 널리 활용된다.

예를 들어 Kolla-Ansible은 OpenStack 서비스들을 컨테이너 방식으로 배포하고 업그레이드하는 데 사용된다.

다만 자동화 도구를 사용한다고 해서 업그레이드 위험이 사라지는 것은 아니므로,

릴리스별 변경사항과 운영체제 호환성을 확인하고 사전 검증 환경에서 테스트해야 한다.

 

---

세 번째 조건 : 국내 조직의 업무 절차를 반영한 셀프서비스

 

OpenStack을 구축하는 목적은 관리자가 모든 요청을 대신 처리하기 위해서가 아니다.

사용자가 필요한 자원을 직접 요청하고, 조직이 정한 정책 안에서 빠르게 사용할 수 있도록 하기 위한 목적이 크다.

 

예를 들어 개발자가 테스트 서버 한 대를 사용하려고 할 때 기존 방식에서는 다음 과정을 거칠 수 있다.

1. 서버 사용 신청서를 작성한다.
2. 팀장의 승인을 받는다.
3. 인프라 담당자가 여유 장비를 확인한다.
4. 운영체제를 설치한다.
5. IP 주소와 방화벽을 설정한다.
6. 계정 정보를 전달한다.

 

이 과정에 며칠이 걸리면 개발자는 실제 업무를 시작하기 전에 오랫동안 기다려야 한다.

 

OpenStack 기반 셀프서비스 환경에서는 사용자가 포털에서 필요한 사양을 선택하고 요청할 수 있다.

 

요청이 정책 범위 안에 있으면 자동으로 생성하고,

중요 자원이나 외부망 연결처럼 추가 검토가 필요한 항목만 승인 절차로 넘길 수 있다.

 

기본적인 OpenStack 자원 관리는 Horizon이나 Skyline 같은 웹 대시보드를 사용할 수 있다.

Skyline은 OpenStack 서비스에 접근할 수 있는 현대적인 웹 인터페이스로 개발되고 있으며,

Kolla-Ansible에서도 Skyline 배포와 SSO 구성을 지원한다.

 

그러나 국내 기업 환경에서는 기본 대시보드만으로 부족할 수 있다.

국내 조직은 회사마다 다음과 같은 정책이 다르기 때문이다.

• 조직도와 결재 단계
• 프로젝트별 예산
• 서버 신청 및 회수 절차
• 개인정보와 중요정보 처리 기준
• 외부망 연결 승인
• 야간 및 휴일 작업 승인
• 표준 운영체제와 보안 프로그램
• 장기 미사용 자원 회수 기준

 

따라서 필요한 경우 Horizon이나 Skyline 앞에 별도의 사내 클라우드 포털을 두고 OpenStack API와 연동할 수 있다.

 

사용자는 사내 포털을 사용하지만 실제 서버, 네트워크, 스토리지 생성 요청은 OpenStack에 전달되는 구조다.

 

여기서 중요한 점은 기능을 많이 넣는 것이 아니다.

사용자가 어렵지 않게 요청할 수 있고, 관리자는 승인·회수·변경 내역을 확인할 수 있으며,

누가 어떤 자원을 만들었는지 추적할 수 있어야 한다.

 

---

네 번째 조건 : 국내 환경에 맞는 네트워크와 스토리지 설계

 

클라우드를 구축할 때 가상 서버 생성 기능만 먼저 확인하기 쉽다.

그러나 실제 운영에서는 컴퓨트보다 네트워크와 스토리지에서 더 복잡한 문제가 발생할 수 있다.

 

네트워크

 

국내 데이터센터에는 이미 다양한 네트워크 장비와 정책이 존재할 수 있다.

 

예를 들면 다음과 같다.

• 업무망과 인터넷망 분리
• 개발망·운영망 분리
• VLAN 기반 네트워크
• 방화벽을 통한 외부 연결
• 로드밸런서
• 고속 네트워크
• GPU·HPC용 SR-IOV
• 기존 IP 주소 관리 시스템

 

OpenStack의 Neutron은 가상 네트워크 연결을 API로 제공하지만,

실제 패킷이 어떤 방식으로 전달될지는 백엔드 구성에 따라 달라진다.

 

OVN, OVS, SR-IOV 등 여러 방식을 사용할 수 있으며 각각 제공하는 기능과 운영 복잡도, 성능 특성이 다르다.

 

따라서 “SDN 기능을 제공한다”는 설명만으로는 부족하다.

다음 질문에 답할 수 있어야 한다.

1. 기존 물리 네트워크와 가상 네트워크를 어떻게 연결할 것인가
2. 동서 트래픽과 남북 트래픽을 어디에서 처리할 것인가
3. 외부 IP와 Floating IP를 어떻게 관리할 것인가
4. 방화벽과 보안 그룹의 역할을 어떻게 나눌 것인가
5. 고속 네트워크가 필요한 워크로드를 어떻게 배치할 것인가
6. 네트워크 장애를 어떻게 탐지하고 추적할 것인가

 

스토리지

 

스토리지도 단순히 디스크 용량만 결정하는 문제가 아니다.

업무 성격에 따라 요구사항이 달라진다.

 

데이터베이스 서버는 낮은 지연 시간과 안정적인 IOPS가 중요할 수 있고,

개발 서버는 비용 효율적인 대용량 저장소가 더 중요할 수 있다.

이미지나 백업 데이터는 객체 스토리지가 적합할 수 있다.

 

OpenStack에서는 Cinder와 Glance가 다양한 스토리지 백엔드와 연동될 수 있다.

Ceph은 그중 대표적인 선택으로, Glance 이미지를 Ceph 블록 장치에 저장하고

Cinder 볼륨을 이미지의 Copy-on-Write 복제로 빠르게 생성할 수 있다.

 

또한 Ceph RBD는 씬 프로비저닝, 크기 확장, 스냅샷, 복제와 같은 기능을 제공한다.

 

하지만 Ceph을 선택하는 것만으로 안정적인 스토리지가 완성되는 것은 아니다.

다음 항목을 함께 설계해야 한다.

• 복제본 수
• 장애 도메인
• 디스크 종류
• 네트워크 대역폭
• 용량 증가 계획
• 스냅샷과 백업 정책
• 장애 복구 절차
• 모니터링 기준
• 데이터 삭제 및 보존 정책

 

---

다섯 번째 조건 : 보안과 권한을 처음부터 구조에 포함하기

 

OpenStack은 여러 사용자가 같은 클라우드 인프라를 함께 사용하는 구조다.

따라서 누가 어떤 자원에 접근할 수 있는지, 프로젝트별로 자원이 제대로 분리되는지,

관리 작업이 기록되는지를 처음부터 설계해야 한다.

 

특히 다음 요소가 중요하다.

• 사용자와 서비스 계정 분리
• 프로젝트 단위 자원 격리
• 역할 기반 권한 관리
• API 통신 구간 암호화
• 관리자 계정 최소화
• 이미지 등록 권한 제한
• 로그와 감사 기록 보존
• 외부 인증 시스템 연동
• 중요 정보와 비밀값 관리
• 정기적인 보안 업데이트

 

과거에는 관리자와 일반 사용자 정도로 단순하게 권한을 구분하는 경우가 많았지만,

현재 OpenStack은 시스템·도메인·프로젝트 범위를 고려하는 세분화된 RBAC 방향으로 발전하고 있다.

 

Nova의 기존 RBAC 전환 옵션도 최신 릴리스에서 제거되는 방향이며, 새로운 기본 권한 정책 적용이 강화되고 있다.

 

국내 기업에서는 사내 계정 시스템이나 SSO와 연동하는 요구도 많다.

Skyline을 Kolla-Ansible로 배포할 경우 OpenID 기반 IdP와의 SSO 구성도 지원된다.

 

다만 인증 연동만 했다고 보안이 완성되는 것은 아니다.

 

예를 들어 퇴사자의 사내 계정이 삭제되더라도 기존 API 자격 증명이나 애플리케이션 계정이 남아 있으면 문제가 될 수 있다.

따라서 계정의 생성부터 권한 변경, 만료, 폐기까지 전체 과정을 관리해야 한다.

 

또한 OpenStack 서비스를 외부망에 그대로 노출하기보다

관리망, API망, 스토리지망, 테넌트망 등을 목적에 맞게 분리하고 접근 경로를 제한해야 한다.

---

여섯 번째 조건 : 장애를 발견하는 것이 아니라 원인을 추적할 수 있는 운영 체계

 

클라우드에는 많은 서비스가 서로 연결되어 있다.

 

가상 서버 생성이 실패하더라도 원인은 Nova에만 있지 않을 수 있다.

예를 들어 다음과 같은 문제가 원인이 될 수 있다.

• Keystone 토큰 발급 실패
• Glance 이미지 다운로드 오류
• Placement 자원 정보 불일치
• Nova Scheduler 배치 실패
• 메시지 큐 지연
• Neutron 포트 생성 실패
• 스토리지 용량 부족
• 하이퍼바이저 또는 libvirt 오류
• 데이터베이스 연결 장애

 

따라서 운영자는 “서버 생성 실패”라는 결과만 보는 것이 아니라 요청이 어느 서비스에서 중단됐는지 추적할 수 있어야 한다.

이를 위해서는 다음 세 가지 정보가 필요하다.

 

메트릭은 CPU 사용률, 메모리, 디스크 용량, API 응답 시간, 메시지 큐 적체량처럼 수치로 표현되는 상태다.

로그는 어떤 서비스에서 어떤 오류가 발생했는지 확인하는 기록이다.

알림은 정상 범위를 벗어난 상태를 운영자에게 알려주는 기능이다.

 

여기에 요청 ID나 자원 ID를 함께 사용하면 여러 서비스에 흩어진 로그를 연결해 하나의 작업 흐름으로 추적할 수 있다.

 

예를 들어 사용자가 서버 생성 버튼을 눌렀는데 실패했다면 다음과 같은 순서로 확인할 수 있어야 한다.

1. API 요청이 정상적으로 들어왔는지 확인한다.
2. 사용자 권한과 할당량을 확인한다.
3. Scheduler가 적합한 노드를 찾았는지 확인한다.
4. 이미지와 네트워크 준비 과정을 확인한다.
5. 하이퍼바이저가 인스턴스를 실행했는지 확인한다.
6. 실패 지점의 로그와 자원 상태를 연결해 원인을 찾는다.

 

---

일곱 번째 조건 : 기술지원보다 중요한 내부 역량

 

OpenStack은 오픈소스이므로 소스 코드를 내려받아 사용할 수 있다.

하지만 내려받을 수 있다는 사실과 안정적으로 운영할 수 있다는 사실은 전혀 다르다.

 

운영자는 적어도 다음 영역을 함께 이해해야 한다.

• Linux
• 가상화와 KVM
• 네트워크와 라우팅
• 분산 스토리지
• 데이터베이스
• 메시지 큐
• 인증과 권한
• 자동화 도구
• 로그 및 모니터링
• 장애 복구
• OpenStack 서비스 구조

 

한 사람이 모든 영역의 전문가일 필요는 없다.

 

다만 컴퓨트, 네트워크, 스토리지, 보안 담당자가 각자의 영역만 보고 문제를 넘기는 구조에서는 장애 대응이 느려질 수 있다.

서비스 사이의 연결 관계를 이해하고 함께 원인을 분석할 수 있는 협업 체계가 필요하다.

 

---

여덟 번째 조건 : 초기 구매비가 아닌 전체 수명주기로 비용 계산하기

 

OpenStack은 오픈소스이므로 소프트웨어 라이선스 비용을 줄일 가능성이 있다.

그러나 오픈소스라는 이유만으로 무료 클라우드라고 생각해서는 안 된다.

 

실제 OpenStack 운영에는 다음과 같은 비용이 발생한다.

• 물리 서버와 네트워크 장비
• 스토리지 장비와 디스크
• 데이터센터 공간과 전력
• 구축 및 통합 비용
• 운영 인력
• 기술 지원
• 모니터링과 백업 시스템
• 업그레이드와 마이그레이션
• 장애 대응
• 교육과 문서화
• 장비 교체와 증설

 

또한 너무 많은 기능을 직접 수정하면 초기에는 편리해 보여도 향후 업그레이드가 어려워질 수 있다.

 

예를 들어 OpenStack의 기본 동작을 대규모로 수정했다면 새로운 릴리스가 나올 때마다 다음 작업이 필요할 수 있다.

1. 기존 변경사항이 새 버전에서도 동작하는지 확인한다.
2. 충돌한 코드를 다시 수정한다.
3. 플러그인과 API 호환성을 검증한다.
4. 운영 중인 자원을 이전한다.
5. 장애 발생 시 자체 수정 코드까지 분석한다.

 

따라서 국내 환경에 맞추는 것과 OpenStack 본체를 과도하게 변경하는 것은 구분해야 한다.

 

가능하면 다음 순서로 접근하는 것이 좋다.

1. 공식 설정과 정책 기능으로 해결한다.
2. 공개 API를 통해 외부 시스템과 연동한다.
3. 표준 플러그인과 드라이버를 사용한다.
4. 필요한 경우 별도의 포털이나 자동화 계층에서 기능을 구현한다.
5. OpenStack 핵심 코드를 수정하는 방법은 마지막에 검토한다.

 

이렇게 해야 상위 버전으로 이동하기 쉽고 장기 운영 부담도 줄일 수 있다.

 

---

OpenStack의 장점은 모든 기능을 처음부터 제공하는 완제품이라는 데 있지 않다.

 

조직이 필요한 기능을 공개 API와 표준 기술을 바탕으로 조합하고,

직접 운영하며, 특정 공급자에게 지나치게 종속되지 않을 수 있다는 데 있다.

 

그러나 이러한 자유도는 동시에 책임을 요구한다.

 

아키텍처를 검증하고, 반복 작업을 자동화하고, 운영 인력을 육성하며, 업그레이드 가능한 구조를 유지해야 한다.

 

이 조건을 갖추었을 때 OpenStack은 단순한 가상화 관리 도구를 넘어 국내 환경에 적합한 프라이빗 클라우드 기반이 될 수 있다.