OpenCSP/Index

OpenCSP 프로젝트 내용 정리

miiml 2026. 3. 20. 14:16

 

진행 중인 오픈소스 프로젝트 OpenCSP의 깃허브 문서가 영어로만 있어서 한글로도 정리해보고 싶어졌다.

 

GitHub

 

일단 프로젝트 목적은 간단함. 

여러 클라우드 도메인에 해당되는 오픈소스들을 엮어서 남는 서버/ PC를 클라우드처럼 운영할 수 있게 도와주는 건데 

 

비슷한 목적의 프로젝트인 OpenStack은 너무 무겁고 러닝커브도 크기 때문에 개인이나 중/소규모 업체에서 당장 활용하기엔 부담되는 경우가 많은거 같다. 그래서 오픈소스 도구들을 선택할 때 최대한 기능 제한이 없고, 다양한 프로토콜(또는 패턴)을 지원하는 경량화된 툴들을 위주로 선택했다.

 

만약 기존에 사용하던 도구가 있다면 연동할 수 있어야 하고 (지향점)

HA나 DRS, 레거시 시스템 연계 등이 더 중요한 환경이라면 각 레이어의 도구를 확장하거나 변경할 수 있어야 한다. (k3s -> k8s, zitadel -> keycloack 등) 

 

근데 아직은 초기 단계라 돌아가는 코드를 만드는게 목표이므로 하나씩 정해서 구현중임

 

우선 프로젝트의 전체 구조는 아래 이미지처럼 구성된다. 

클라우드를 구성하는 여러 요소들을 위한 오픈소스 툴들을 하나의 인프라(k3s)에 구성(Core)해두고, 오케스트레이션과 사용자 인터페이스(Console)는 별도로 개발한다. 

 

사용자는 IAM(Zitadel) 한 곳에서만 관리하고, 나머지 툴에선 해당 데이터를 사용만 하는 개념. 

리소스 접근과 Audit은 Teleport, 프로비저닝은 Terraform과 Ansible이 담당한다.  

그리고 빌링은 프로젝트의 컨셉상 core가 너무 무거워지지 않도록 Lago를 선택했었지만, 구성해보니 필요한 기능들이 프리미엄으로 다 막혀 있었다..

 

어차피 클라우드 운영하려면 데이터 파이프라인과 분석도구도 필요할테니 Billing을 Core에서 분리하고 kafka, click house 같은 구성을 더해줬음

 

그리고 위에 툴들도 어딘가엔 구성되어야 하니까 사용자에게 리소스를 제공해줄 Infrastructure 레이어에 같이 올려주기로 했다. 

근데 이렇게 구조가 중첩되면 프로비저닝 절차와 순서를 잘 보장해야한다. (아니면 닭이 먼저인지 달걀이 먼저인지 정해야하는 문제가 생김..)

 

 

구성 순서를 요약하면 이미지처럼 먼저 인프라 레이어를 먼저 엔지니어가 구성하고, 이후 core와 console을 해당 인프라에 Bootstrap하는 과정이 필요하다. Bootstrap 이후는 FluxCD가 계속 reconcile하면서 자동으로 관리한다. 

그리고 이후 사용자 리소스의 구성은 인프라에 잘 올라간 OpenCSP에 맡기면 됨

 

 

문제점

조금 생각해보면 현재 구조에서 몇가지 문제가 있는데

일단은 의존성(현재 사용중인 오픈소스가 정책을 변경하거나 기능이 제한되면 어떻게 할지), 학습/ 관리 부담(개인 사용자가 저기 있는 모든 오픈소스를 직접 구성하고 관리해야함), 높은 결합도(설계 하나가 변경되었는데 수정해야할 포인트가 많다면?) 등이 생각난다. 

 

우선 의존성 부분은 초기부터 여러 오픈소스를 사용할 수 있도록 코드를 작성하려고한다. 예를들어 백엔드에서 인터페이스 패턴을 적용해 코드가 특정 툴에 종속되지 않게 하고, 프로비저닝 부분도 모듈화시켜두면 최소 조건은 충족이 될거 같고
학습/ 관리 부분은 다른 오픈소스처럼 최대한 많은 문서화, 사용 예시 코드, 활발한 discussions, 커뮤니티 등으로 해결해야 할 거 같아서 우선 docs 레포지토리를 만들었다.

결합도 문제도 아래처럼 프로비저닝 모듈과 각 역할들(IAM, PAM 등)을 중앙화시켜 하나만 수정하면 여러 레이어에서 적용할 수 있도록 설계하긴 했다. 

 

여기까지가 현재까지의 설계와 아키텍쳐들인데 

장점은 스택에 제한을 두지 않고 각 역할을 중앙화/일원화 시켜 인프라 구성의 유연성과 확장성을 어느정도 확보했다는 점인거 같다.

단점은 그거 때문에 초기의 구성(기존 인프라에 맞춰 엔지니어링이 필요하니까)이 복잡해진다는 점

 

이 부분은 계속 해결해 나가야될 과제인 듯.

 

당장은 Core 구성을 마무리하는 게 목표이고, 이후에 Console 개발과 프로비저닝 자동화 순서로 진행할 예정이다.

그리고 문제들을 해결해가면서, 프로젝트 진행이랑 관련된 내용을 계속 포스팅해보겠음

 

 

진행 내용 정리용 인덱스 링크

 

 

기타 자료

더보기
NIST 특성 정의 OpenCSP
On-demand self-service 사용자가 직접 리소스 프로비저닝 Console → Core → Infra
Broad network access 네트워크를 통한 접근 API + 대시보드
Resource pooling 리소스 풀링, 멀티테넌트 Proxmox/OpenStack 클러스터링
Rapid elasticity 빠른 확장/축소 tofu-controller + Semaphore
Measured service 사용량 측정 + 과금 Meteroid 빌링