Infrastructure on ApexCaptain의 기술 블로그

클라우드 비용 절약을 위한 노력

Sat, 01 Nov 2025 00:00:00 +0900

들어가기 앞서

얼마 전에 “k8s에 Ollama AI 서버 올려보기”라는 포스트를 통해
“GPU가 너무 비싸 인프라 구축을 어떻게 해야 할지 고민이다“라는 내용을 토로했다.

얼핏 GPU 얘기에만 매몰된 것처럼 보였을 수도 있으나,
당연하게도 클라우드 비용은 GPU만의 문제가 아니다.

클라우드에는 컴퓨트, 스토리지, 네트워크 등 다양한 카테고리의
서비스가 존재하고, 상황에 따라 비용을 최적화할 수 있는 방법들도 제각각이다.
이번 포스트에서는 AWS를 중심으로 클라우드 비용 절약 팁을 공유하고자 한다.

왜 AWS? 🤔

GCP, Azure, OCI 등 다양한 클라우드가 있지만, 전부 다 다루기엔 한계가 있다.
다행히 대부분 기본 개념은 유사하므로 이 포스트에서는 공통된 원칙을 위주로 기술한다.

문제의 시작

On-Premise 서버 구축의 어려움

서버를 구축하는 일은 힘들다.
CPU, 메모리, 용도에 맞는 각종 스토리지, PSU_{(파워 서플라이)}, 메인보드, 가끔 GPU같은 PCI-E 확장 카드.
구매해야 하는 게 한두 가지가 아니다.

컴퓨터를 구매한다고 끝나는 것도 아니다.
정전을 대비한 외부 UPS, 끊김 걱정 없는 튼튼한 회선 역시 필요하다.

그 외에도 OS, RAID 구성, 각종 네트워크 / 방화벽 설정 등등…

그런데 이런 일은 보통 IDC _{(Internet Data Center)}에서 알아서 다 해주는 거 아닌가?

결코 그렇지 않다

막상 해보면 서버 도입부터 실제 센터에 설치/설정하는 일련의 과정 동안
하루에도 수십통씩 이메일과 전화, SMS 등을 보내고 받게 될 것이다. _{나도 알고싶지 않았다.}

그렇다고 IDC 직원이 뭔가를 잘못 했다는 건 아니다.
꼼꼼하게 하나하나 확인하면서 클라이언트에게 확인 받는 건 시스템 엔지니어로서 당연하다.

클라우드 서비스를 사용하는 이유

바로 위 섹션의 문제점 극복을 포함해서 기업들이 클라우드를 사용하는 이유는 여러 가지가 있다.

예를 들어:

유연성과 확장성

IDC에 데이터 서버를 구축한다고 생각해보자.

위 제품은 Seagate IronWolf Pro 7200rpm, 512MB 캐시 모델이다.
용량은 30TB, 가격은 작성일 기준 120만원 정도이다.
서버에 필요한 디스크 크기가 아직 미정인 상황이다.
디스크를 구매해야 하는데 어떤걸 사야할까?
1. 바로 제일 크고 아름다운 30TB HDD를 구매
2. 더 작은 디스크를 우선 구매 -> 추후 점진적으로 늘리기
후자를 택하는 게 합리적이긴 하나,
이러면 나중에 HDD를 장착할 물리적인 공간이나 포트가 부족해질 수도 있다.

그렇담 클라우드는?

클라우드 서비스를 통해 구축한다면 이러한 고민에서 해방된다.
물리적 제약에 신경 쓸 필요 없이 지금 필요한 만큼의 서버를 구성 할 수 있고
원하면 언제든, 원하는 만큼 스펙을 조절할 수 있다.
보안

민감한 정보를 안전하게 보호하는 것은 비즈니스를 성공적으로 운영하기 위한 기본적인 요소이다.

간단하게는 보안그룹 인바운드/아웃바운드 규칙부터, _{(단일 서버 기준으로 하면 firewall에 해당)}
IAM을 통한 단일화된 그룹 / 사용자 관리, KMS와 같은 별도 Key 관리 서비스 등 클라우드의
고급 보안 조치를 통해 보다 쉽게 관리하고 안심하고 사용할 수 있다.
IaC를 통한 신속한 배포

Terraform, Pulumi, CloudFormation 등 클라우드 서비스에 대한
인프라를 코드로 관리할 수 있는 도구들을 사용하면 새로운 환경을 빠르게 구축할 수 있다.

또한, 그 자체로 일련의 정리된 문서의 역할도 겸하므로 현재 어떤 서비스가 어떻게 구성되어 있는지,
혹은 Git과 같은 버전 관리 도구로 인프라의 변경 이력을 추적하는 것도 용이하다.

On-Premise 환경에서도 OpenStack을 통해 비슷한 작업이 가능하지만,
이는 엄연히 이야기하면 그 자체로 IaC 도구는 아니고, OS 혹은 플랫폼에 가까운 물건이다.

그래 그럼 클라우드 서비스가 최고다 이건가?

클라우드 서비스를 쓰면 생기는 문제

그럴 리가 있나. 세상만사 명이 있으면 암도 있는 법이다.

이번에도 몇 가지 예시를 들어보면 다음과 같다.

의존성

특정 클라우드의 생태계에 지나치게 의존하다보면 그 자체로 기업의 비즈니스 운영에 영향을 줄 수 있다.

예를 들어 AWS의 ECS를 사용해 컨테이너 클러스터를 구성했다고 가정해보자.
심지어 EC2가 아닌 Fargate를 컴퓨팅 엔진으로 사용했고 ALB로 고유한 라우팅 규칙,
CloudWatch를 사용한 모니터링 등등이 포함된 그야말로 AWS 환경에 특화된 클러스터를 만들어 냈다.

그런데 어느 날 당신의 상사가 “AWS 이거 너무 비싸“라며 자체적인 k8s 클러스터를 만들거나 아니면 다른 클라우드로의 마이그레이션을 지시했다.

대체 이 토폴로지를 어떻게 k8s 방식에 맞춰 이전해야 하는가?
사실상 처음부터 다시 만드는 게 현명하다.
기술적 허들

클라우드 서비스를 통해 인프라 환경을 설정하고 운영하는 것은 굉장히 난해한 일이다.
“클라우드 그거 마우스 딸깍 딸깍 아니냐?” 라는 비아냥도 몇 번 들은 적 있는데,
이게 보기보다 굉장히 방대하고 복잡한 기술/지식이 필요한 분야이다.

더욱이 클라우드마다 장단점도 있어서 2~3개의 클라우드에 걸쳐 인프라를 구축하는 경우도 많다.
요컨대, 해당 분야에 능통한 전문 인력을 고용해야 한다는 것이다.

On-Premise에 서버를 구축/운영할 때는 적어도 전문가의 서포트를 받을 수 있다.
24시간 언제나 상주하는 직원들이 사용자가 멍멍이 떡처럼 질문을 해도, 찰떡처럼 알아채고 문제 해결을 도와준다.

하지만 클라우드 서비스에서 그런 수준의 친절과 수고를 기대하긴 어렵다.
_{(물론 CSP가 대시보드 페이지만 띄워놓고 사용자에게 서버 임대료만 따박 따박 받아내는 자동사냥 시스템을 만들었단 소린 아니다.)}
비용

바로 위 기술적 허들에서 이어지는 문제이자 이번 포스트의 주제이다.

아이러니하게도 “비용"이라는 항목은 클라우드 서비스의 장점으로 더 많이 언급된다.
구축하려는 시스템의 성격에 맞춰 필요한 서비스와 자원을 정확하게 선택하면
효율성을 극대화할 수 있고, 결과적으로 비용을 최적화할 수 있다는 논리이다.

그런데 문제는 “그걸 대체 어떻게 하냐?“이다.

실제로 클라우드 비용 관리를 해보면 예상치 못한 지출이 발생하기 쉽다.
사용한 만큼만 지불한다는 Pay-as-you-go 모델의 양면성인 셈이다.
리소스를 제대로 관리하지 않으면 사용하지 않는 인스턴스가 계속 돌아가고,
네트워크 트래픽이나 스토리지 I/O 같은 숨겨진 비용까지 합쳐져서
결국 고정 비용이 거의 없는 IDC 대비 오히려 더 많은 비용이 나올 수도 있다.

그래서 클라우드를 효과적으로 사용하려면 체계적인 비용 최적화 전략이 필요하다.

공통사항

(클라우드) 리소스 태깅

AWS에는 “비용 할당 태그”를 통해 조직의 태그 할당 정책에 따라
Cost Explorer로 비용 분석/추적이 가능하다. 일단 어디에 얼마를 쓰는지 알아야 절약을 할 수 있다.

개인 가계부에 비유하자면 사용한 돈에 “범주"를 붙이는 것과 같다.

가령 여자/남자 친구와 주말에 롯데월드에 가서 놀았다면,
이때 사용한 비용들에는 다음과 같은 태그를 붙일 수 있다.

키	값	비고
Purpose	Personal-Date	무엇을 위한 지출인가?
Partner	Girlfriend 혹은 Boyfriend	누구에게 할당된 비용인가?
Location	LotteWorld	어디서 발생한 비용인가?

클라우드 리소스도 마찬가지다.

예를 들어 프로젝트 A의 개발팀 A가 사용한 EC2 인스턴스에는 다음과 같은 태그를 붙일 수 있다.

키	값	비고
Project	Project-A	어떤 프로젝트의 비용인가?
Team	Dev-Team-A	어느 팀이 사용하는가?
Environment	Development	어떤 환경인가? (Dev/Staging/Prod)

다만, AWS의 태그 값은 기본적으로 원자값만 사용할 수 있다.
CSV 형태, 예를 들어 "Managers" : "Aron,Ted,James" 이렇게는 쓸 수 없다.
정확히는 사용 자체는 가능하나, AWS 네이티브 기능의 한계로 이런 태그의 필터링이 불가능하다.
반드시 그렇게 사용해야 하는 경우 DataDog과 같은 외부 서비스를 알아보도록 하자.

전사적 지원

클라우드 비용 절약은 단순히 담당 엔지니어 1명, 혹은 DevOps팀만의 노력으로 달성하는 데 한계가 있다.

아마 대부분 회사에서 프로젝트/일정 관리, 커뮤니케이션의 역할 등을 하는 협업 툴을 사용할 것이다.
이를 통해 관련된 모든 인원들에게 클라우드 비용에 대한 지속적인 관심을 환기시키고 소통을 통해 해결해 나가고자 하는 노력이 필요하다.

(애플리케이션) 리소스 모니터링

한 명의 개발자가 인프라도 관리하면서 거기에 올라가는 모든 앱을 전부 다 만드는 경우는 없을 것이다.
애플리케이션을 빌드하는 건 결국 다른 팀, 다른 개발자일 확률이 높은데, 문제는 인프라에 올라간 리소스를
얼마나 잘 활용하는가는 그들의 손에 달려있다는 것이다.

조금 극단적인 예시를 하나 들어보겠다.

개발팀 A가 구축한 프로젝트 A가 있다.

이 프로젝트에는 RDS에 쿼리를 날려 데이터를 조회하고 분석한 뒤 다시 다른 테이블에 저장하는 프로세스가 있다. 만일 조회/분석해야 하는 데이터 튜플의 수가 1,000만개인데 별 생각 없이 한꺼번에 가져와서 작업하도록 만들었다면 어떻게 될까?

pod나 container에 리소스 제한을 걸어뒀다면 해당 서비스가 종료될 것이고, 그렇지 않았다면 물리적 한계까지 자원을 소모하게 될 것이다.

해당 로직을 만들어 사단을 낸 직원을 추적/섬멸하든, 조용히 타이르든 그것은 회사 내규에 따라 다르겠으나, 굳이 이런 극단적인 예시가 아니어도 크고 작은 메모리 누수는 제법 빈번하다.

Prometheus, Grafana등을 활용해 리소스를 모니터링 하고 사전에 알람을 보내게 구축하도록 하자.

컴퓨팅

AWS는 EC2(Elastic Computing Cloud)가 이 파트에 해당한다.
무슨 VM, Core Instance 등등 클라우드마다 부르는 방식은 다양한데 실제 앱이 동작하는 서버 컴퓨터를 대여해주는 서비스이다.

특별한 경우가 아니라면 클라우드 비용의 거진 대부분은 여기서 발생한다.

Arm CPU

EC2 구성 요소 중 GPU를 제외하면 가장 많은 비용을 차지하는 것이 바로 CPU이다.
CPU 아키텍처는 보통 AMD64(혹은 x86_64)와 Arm64(혹은 aarch64)가 가장 많이 사용된다.

이런 일반적으로 생각하는 PC나 서버에 들어가던 것이 AMD(x86)이고

이런 스마트폰이나 태블릿같은 모바일 장치에 들어가던 것이 Arm이다.

초고사양 모바일 게임을 즐기는 유저가 아니라면 스마트폰에 쿨링 팬을 다는 경우는 없을 것이다.
Arm 계열의 CPU는 AMD(x86)에 비해 저전력, 저발열, 고효율이라는 특징을 가진다.

본래 서버용 CPU는 AMD(x86) 계열을 사용하는 것이 일반적이었는데,
내 기억이 맞다면 애플의 M1 칩을 탑재한 맥북을 공개한 이후로 상황이 많이 바뀌었다.

요즘은 Arm CPU를 사용하는 서버 인스턴스를 어느 클라우드에서나 기본적으로 제공한다.

위 사진에서 vCPU 4, 메모리 8GiB로 통일하고 시간당 On-Demand 요금을 보면,
AMD(x86)의 경우 시간당 $ 0.281, Arm은 시간당 $ 0.195이다.

CPU 아키텍처를 Arm으로 바꾸면 대략 30% 정도 비용을 절감할 수 있다.

현재 근무중인 회사에서도 실제 Arm CPU를 굉장히 활발하게 사용하고 있다.
신규로 생성하는 서비스는 물론 기존 AMD(x86)으로 동작중인 것들도 하나씩 마이그레이션 중이다.
실제 수치상으로도 25~30% 정도의 비용 절감 효과를 보고 있다.

다만, 이 경우 애플리케이션을 빌드할 때 Arm CPU 아키텍처에 맞춰서 빌드해야 한다.
아무래도 이게 걸림돌이 되어서 전환을 망설이는 경우도 있을 것이다.

Docker로 애플리케이션을 패키징 하고 있다면 Docker buildx를 사용 해보는 것을 추천한다.

예를들어 다음은 회사에서 사용하고 있는 GitHub Action Workflow CI 스크립트중 하나의 일부이다.
조금 특이하게도 대상 환경이 Production일 경우엔 arm64, Stage일 경우엔 amd64에 맞춰 빌드한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


# ...... #
jobs:
 # ...... # 
 release_ocir:
 # ...... # 
 steps:
 # ...... # 
 # 대상 Container Registry에 접근 권한 획득
 - name: Login to OCIR repo
 uses: docker/login-action@v3.5.0
 with:
 registry: ${{ steps.get-ocir-region.outputs.result }}.ocir.io
 username: ${{ secrets.OCI_TENANCY_NAMESPACE }}/${{ secrets.OCI_CLI_USER_NAME }}
 password: ${{ secrets.OCI_AUTH_TOKEN }}

 # 목표 환경 (prod/stage)에 따라 platform(CPU 아키텍처) 값 지정 
 - name: Resolve target platforms
 id: resolve-platforms
 run: |-
 TARGET="${{ inputs.target }}"
 if [ -z "$TARGET" ]; then TARGET="stage"; fi
 if [ "$TARGET" = "prod" ]; then
 echo "platforms=linux/arm64" >> $GITHUB_OUTPUT
 else
 echo "platforms=linux/amd64" >> $GITHUB_OUTPUT
 fi
 
 # Docker Buildx 설정
 - name: Set up Buildx
 id: docker-buildx
 uses: docker/setup-buildx-action@v3.11.1
 with:
 driver-opts: |-
 image=moby/buildkit:master
 network=host
 platforms: ${{ steps.resolve-platforms.outputs.platforms }}

 # 이미지를 빌드하고 대상 Registry에 Push 
 - name: Build Container image and push
 uses: docker/build-push-action@v6.18.0
 with:
 push: true
 context: .
 file: ./Dockerfile

 # 위에서 지정한 플랫폼(아키텍처)로 지정
 platforms: ${{ steps.resolve-platforms.outputs.platforms }}
 tags: ${{ steps.get-ocir-repo.outputs.repo_path }}:${{ inputs.target || 'stage' }}-latest,${{ steps.get-ocir-repo.outputs.repo_path }}:${{ inputs.target || 'stage' }}-${{ steps.get-version.outputs.version }}

 # Buildx로 Builder 항목을 지정
 builder: ${{ steps.docker-buildx.outputs.name }}
 cache-from: type=gha
 cache-to: type=gha,mode=max
 # ...... #

Docker Buildx를 설정 해준 뒤 docker build action의 builder 값을 buildx의 이름으로,
platform은 원하는 타겟에 맞춰 빌드 후 레지스트리에 올리면 된다.

대부분의 호환성 이슈는 Docker Buildx로 대응이 가능하지만,
이미지 내부에 설치하는 라이브러리 수준에서 문제가 있는 경우 Dockerfile에 분기를 넣어 해결한다.

예를들어:

1
2
3
4
5
6
7


# ...... #

RUN if [ "$TARGETARCH" = "arm64" ]; then \
 # 아키텍처가 Arm64인 경우만 이 안의 코드를 실행
 fi

# ...... #

단순 분기 처리 정도로는 해결이 안 될 정도로 환경이 복잡하다면 아예 파일을 나눠 사용하기도 한다.

1
2
3


.
├── Dockerfile.amd64
└── Dockerfile.arm64

Serverless 프레임워크

AWS에는 “Lambda”라는 서비스가 있다.

24시간 실행되며 지속적으로 과금되는 EC2와 달리 Lambda는 서버 관리가 필요 없는 Serverless 방식이다.
특정 코드가 실행될 때만 비용이 부과되어 새벽 시간대처럼 사용자가 거의 없는 유휴 시간에는 비용 부과가 되지 않는다.

주요 특징은 다음과 같다:

이벤트 기반(Event-Driven) 방식:

CloudWatch, API Gateway와 연동하여 특정 이벤트,
가령 API 호출, 일정 시간 경과, 파일이 업로드 등이 발생할 때만 코드가 실행된다.
서버 관리 불필요:

문자 그대로 Serverless 방식이다.
EC2처럼 OS, H/W 용량 계획, 서버 프로비저닝, 스케일링 정책 등의 관리에 신경 쓸 필요가 없다.
실행 기반 과금:

코드가 실제로 실행되는 동안에만 비용이 부과된다.
사용자가 있든 없든 지속적으로 시간당 비용을 부과하는 EC2와의 가장 큰 차이점이다.

다만 몇 가지 단점도 있다:

콜드 스타트 지연:

Lambda 함수가 장시간 호출되지 않았다면
AWS가 런타임 환경을 준비하고 코드를 불러오는 초기 지연 시간이 발생한다.
리소스 제약:

Lambda 함수는 최대 15분까지만 실행 될 수 있고 메모리는 10GB가 한계이다.

구체적인 활용처:

사용자의 요청에 즉각적인 응답이 필요하지 않은 API 서비스
S3에 파일이 업로드 될 때 -> 이미지 썸네일, 동영상 트랜스 코딩, 데이터 필터링 등 데이터 처리 작업
일정 시간이 되면(가령 매일 새벽 1시) -> 오래된 스냅샷/AMI 정리 등 관리 자동화 작업

본격적인 Lambda 도입을 고려하고 있다면 AWS Serverless Appliaction Model에 대해 알아보도록 하자.
Java, Python, Go등 다양한 프로그래밍 언어를 사용 할 수 있는 Lambda 기반의 프레임워크이다.

특이한 점은 Serverless의 특성상 일반적인 API 서버 프레임워크랑은 다르게 각각의 독립된 코드들을
CloudFormation을 통해 클라우드 리소스의 형태로 배포한다.

CloudFormation은 AWS내 리소스를 yml 파일을 통해 구성/관리 할 수 있는 IaC 도구이다.
처음 회사에 입사했을 때 Lambda를 쓰면 저렴하게 API 구성이 가능하다고 한 번 만들어 보라길래
열심히 공부했던 기억이 난다. 그 덕에 IaC에 입문하게 되었다. _{(지금은 Terraform 쓰고 있지만…)}

스팟 인스턴스

스팟 인스턴스는 AWS에서 현재 사용되지 않고 남아있는 여유 컴퓨팅 용량이다.

이게 무슨 소리냐면 다른 사용자, 그러니까 다른 기업이 사용하고 있는 EC2 리소스 중
현재 놀고있는 분량만큼을 빌려와서 사용한다는 개념이다.

당연히 원래 주인이 내놓으라고 하면 돌려줘야 한다.

비용은 기존 EC2 대비 최대 무려 90%나 저렴하다!

좋아 보이긴 하는데 신뢰성에 의심이 가서 나도 개념만 들었지 실 도입은 못 해봤다.
그래도 시의적절하게 잘 활용하면 괜찮은 대안이 될 것이다.

장점:

비용 절감:

가장 큰 장점이다. On-Demand EC2 방식에 비해 70~90%까지 비용을 절약할 수 있다.
대규모 컴퓨팅:

낮은 비용으로 병렬 컴퓨팅 자원을 신속하게 확보할 수 있다.

단점:

회수 위험:

AWS가 용량을 회수하면 언제든지 인스턴스가 중지 될 수 있다.
일반적으로 중단 약 2분 전 Interruption Notice가 제공되고, 사전 분산을 위한 Rebalance Recommendation 신호도 제공된다.
관리의 어려움:

중단 가능성이 상시 존재하므로 체크포인트 저장, 워크 큐(재시도 가능),
중간 결과를 S3/DynamoDB 등에 저장하는 설계가 필요하다.

활용처:

배치 처리, 빅데이터 분석, 머신 러닝
기타 Stateless 서버의 부하 분산
이미지/비디오 렌더링

예약 인스턴스

EC2의 기본 요금은 흔히 On-Demand 방식이라고 한다.
간단히 한국식으로 표현하면 후불 요금제이다.

내가 어렸을 때는 PC방 1시간 사용료가 1,000원이었다.
고로 5시간 게임을 하고 나서 요금 정산을 하면 5,000원을 내야했다.
하지만 처음부터 5,000원을 내고 계정에 등록하면 6시간을 할 수 있었다.

예약 인스턴스는 이와 유사한 방식이다.

예약 인스턴스(Reserved Instance, RI)는 1년 혹은 3년동안
특정 인스턴스 유형과 리전을 사용할 것을 미리 약정하고 선결제 혹은 부분 선결제 함으로써
On-Demand 방식에 비해 상당한 할인을 받는 방식의 요금 모델이다.

마침 기존 포스트에서 조사한 정보가 있으니 여기에서 활용 해보겠다.
다음은 AWS g5g.16xlarge 인스턴스의 비용 비교 표이다.

비용모델	월 평균 사용료 (서울 리전전 / 단위 : USD)
On-Demand	$ 2388.29
Spot	$ 672.59
1년 예약 분할 지불	$ 1559.73
1년 예약 일시불	$ 1455.74
3년 예약 분할 지불	$ 1102.4
3년 예약 일시불	$ 959.5

비교를 위해 On-Demand와 Spot도 추가 하였다.
On-Demand와 비교하면 3년 RI 일시불 방식이 60%가량 저렴하다.

장점:

비용 절감:

Spot과 마찬가지로 엄청난 할인을 받을 수 있다.
AZ 선점:

이건 좀 특이한 케이스인데, 인스턴스 확보가 어려운 특정 AZ(가용 영역)에
미리 용량 사용을 보장받을 수 있다.

단점:

장기 약정:

1년 / 3년 이 2가지 옵션 밖에 없다. 그 기간 동안은 계속 써야한다.
초기 비용 부담:

할인을 받기 위해 처음 도입 시 엄청난 양의 비용을 지불해야 할 수도 있다.
유연성 부족:

Standard RI의 경우 인스턴스 유형을 변경할 수 없다.
Convertible RI는 유형/패밀리 전환은 가능한데 할인율은 더 낮다. (On-Demand 대비 최대 72% -> 54%)

활용처:

장기적으로 운영 해온, 혹은 운영 될 것으로 예측되는 서비스
k8s의 베이스 용량 확보:

k8s 클러스터를 사용하고 있다면 상시 필요한 최소한의 용량이라는 것이 있을 것이다.
보수적으로 접근해 최소 용량 수준에 맞춰 RI를 쓰면 비용 절감에 도움이 된다.

절약 플랜

절약 플랜(Savings Plan)은 RI의 단점을 극복하기 위해 나온 요금제이다.
기본적으로 RI와 유사한 비용 절감 효과는 최대한 제공하면서 부족한 유연성 제약을 완화한다.

회사 근처 구내식당에서 점심 한 끼를 먹으려면 10,000원이라고 하자.
직원이 10명 정도이고 한 달에 20일씩 출근을 한다면 한 사람이 최대 200,000원,
10명이니 200만원 정도의 식비가 소모 될 것이다.
만일 회사 차원에서 매달 100만원을 구내식당에 지불하면, 직원들의 식사를 무료로 해주겠다고 하면 어떠한가?

절약 플랜은 이와 유사한 개념이다.

다만 디테일하게 들어가면 굉장히 길고 복잡해서 이 부분만 추후 별도로 포스트 하도록 하겠다.
기본적으로는 다음의 전제를 기억하자.

리전, OS, 인스턴스 유형 패밀리 등의 제약이 많아질수록, 다시 말해
유연성을 포기할수록 -> 비용이 절감된다

종류:

Compute Savings Plans
EC2, Fargate, Lambda 등 컴퓨트 전반에 적용된다.
리전/인스턴스 패밀리/OS 제약이 비교적 적어 유연성이 높다.
EC2 Instance Savings Plans
특정 인스턴스 패밀리 + 리전에 묶는 대신 할인율이 더 크다.

주의사항:

약정은 시간당 약정 금액 기준이다. 미사용 약정은 그대로 비용 처리된다.
약정 기간은 1년/3년, 선결제 정도에 따라 할인율이 달라진다.
RI보다 유연하지만, 약정 초과분은 온디맨드로 과금된다.

절약 플랜은 예약 인스턴스에 비해 부담되는 제약사항이 덜하다.
그덕에 경영진을 설득해 도입하는 게 비교적 쉬웠던 것으로 기억한다.

더욱이 인스턴스 패밀리가 일치하는 모든 EC2에 구매한 절약 플랜이 일괄 적용되기 때문에
바로 다음달부터 즉각적으로 회사에서 소비되는 인스턴스 비용이 25~30% 줄어들었다.

다만 이는 절약 플랜의 제약조건에 해당하는 경우에만 그렇다는 거다.
예를들어 현재 회사에는 인스턴스 유형이 t2 패밀리에 속하는 서버가 여럿 존재한다.

현재 서비스 중인 t2 패밀리의 EC2 인스턴스 목록

이들은 내가 회사에 들어오기 전부터 있던 레거시 서버들인데,
이런 저런 이유, 가령, 클라이언트나 해당 개발팀이 독립된 EC2 인스턴스를 원하거나,
Arm 아키텍쳐로의 전환, 심지어는 컨테이너화 자체에 소극적인 서비스들이 이곳에 위치한다.

이 인스턴스들의 고정 비용을 줄이고자 “t2” 인스턴스 패밀리를 타겟하는 절약 플랜을 사용하고 있다.
아이러니하게도 그게 Excuse가 되어 되려 다른 시스템, 가령 Arm 계열의 인스턴스 패밀리나 아니면 아예
다른 클라우드 서비스 _{(우리의 경우 Oracle Cloud Infrastructure)}로의 마이그레이션에 장애가 되곤 한다.

그러니 환경에 발목 잡히지 않게 추후 계획을 충분히 고려해 도입에 신중을 기하도록 하자.

구내식당 비유를 계속 들자면 본래 매일 점심 식사 하라고 회사에서 10,000원씩 지급 해주다가
어느날부터 “앞으로 지정한 구내식당 가서 먹으면 무료니까 그쪽으로 가라” 라고 하는 것과 같다.

이제 점심에 햄버거 먹고 싶으면 본인 돈으로 사야한다.

햄버거를 좋아하는 나같은 몹쓸 인간은 슬퍼 하겠지만,
이모님의 김치찌개 솜씨에 매료된 직원이라면 두 팔 벌려 환영할 것이다.

스토리지

여기서 말 하는 스토리지는 블록 볼륨이나 RDS가 아닌 파일 저장소_{(일명 Bucket)}를 의미한다.
AWS의 경우 S3(Simple Storage Service)가 이에 해당된다.

S3 비용을 절감하는 핵심 전략은 데이터의 접근 빈도에 따라 적절한 스토리지 클래스를 선택, 수명 주기(Lifecycle) 규칙을 활용하여 불필요한 데이터를 관리하는 것이다.

스토리지 클래스 최적화

데이터 액세스 패턴에 맞는 스토리지 클래스를 선택하면 저장 비용을 크게 절감할 수 있다.

클래스	주요 용도	특징/주의
S3 Intelligent-Tiering	접근 패턴이 불명확·변동이 잦은 데이터	계층 자동 이동(Frequent, Infrequent, Archive Instant, Archive, Deep Archive), 모니터링/자동화에 소액 월 비용 발생
S3 Standard-IA	드물게 접근하지만 밀리초 단위 즉시 조회 필요	장기 보관용, 백업/DR에 적합
S3 One Zone-IA	재생성 가능 데이터, 2차 백업	단일 AZ 저장으로 더 저렴, 내구성은 동일하나 가용성 리스크가 있음
S3 Glacier Instant Retrieval	1년에 몇 번 수준 접근 + 즉시 조회 필요	빠르게 조회 가능, 보관 단가 저렴
S3 Glacier Flexible Retrieval / Deep Archive	매우 드문 접근의 장기 아카이브	가장 저렴(Deep Archive), 검색 시간 느림

주의사항:

적절한 주기 설정:

IA/Glacier 계열은 최소 저장 기간(대략 30~180일 수준)과 조기 삭제 위약, 조회/복원 비용이 존재한다.
전환 주기가 너무 짧으면 오히려 총비용이 증가할 수 있다.
파일 크기:

Intelligent-Tiering은 객체 크기/보관기간/접근 패턴에 따라 모니터링 비용 대비 이점이 작을 수 있다.
작은 객체를 단기적으로 보관하는 것은 효율적이지 못하다.

S3 수명 주기(Lifecycle) 규칙 활용

S3 수명 주기 규칙을 설정하여 자동으로 객체를 관리함으로써 비용을 절감할 수 있다.
요컨대, 과거 데이터를 지우거나 압축하거나 액세스 빈도가 낮은 백업 스토리지로 옮기는 것을 의미한다.

객체가 일정 기간이 지나면 액세스 빈도가 낮아질 것으로 예상하고, S3 Standard에서 Standard-IA, Glacier 등 저렴한 스토리지 클래스로 자동 전환되도록 규칙을 설정해주자.

불필요한 객체 자동 삭제/만료:

만료된 객체(Object Expiration): 더 이상 필요 없는 데이터(예: 오래된 로그 파일, 임시 파일)를 일정 기간 후 자동으로 삭제하도록 설정한다.
이전 버전 정리 (Versioning 활성화 시): 객체 버전을 활성화한 경우, 불필요하게 남아있는 이전 버전들을 일정 기간 후 영구 삭제하도록 설정한다.
불완전한 멀티파트 업로드 정리: 완료되지 않은 멀티파트 업로드 조각들이 남아있지 않도록 일정 기간 후 정리하는 규칙을 설정한다.

네트워크 (Data Transfer)

AWS를 포함해서 클라우드 서비스에서 네트워크 사용 비용이란 건 기본적으로

밖 -> 안(Inbound)으로 들어올 때는 문제가 없지만,
안 -> 밖(Outbound)으로 데이터가 전송되어 나갈 때 부과된다.

따라서 네트워크 비용을 낮추는 것은
아웃바운드 데이터 전송(Data Transfer Out, DTO)을 줄이는 게 포인트이다.

CDN 활용

CDN을 통해 컨텐츠를 캐싱하여 최종 사용자_{(ex: 페이지 방문자)}에게 가장 가까운 엣지 로케이션을 제공함으로써
서비스 품질도 올리고 비용도 줄이는 일거양득을 누릴 수 있다.

AWS의 경우 CloudFront라는 서비스가 이에 해당한다.

리전에서 직접 인터넷으로 데이터를 전송하는 것 보다 CloudFront를 통한 전송이 훨씬 저렴하다.
캐싱된 데이터는 S3나 EC2에서 다시 전송할 필요가 없으므로 원본 서버의 DTO가 줄어든다.

압축 전송

S3나 EC2에서 데이터를 전송할 때 Gzip이나 Brotli 등을 이용해 데이터를 압축해서 보내는 것이 좋다.

CloudFront를 사용한다면 CloudFront에서 자동 압축을 켜는 것이 가장 간단하다.

CloudFront의 동작 설정에서 압축(Compress Objects Automatically) 옵션을 “Yes"로 설정해주자.

별도 CDN이 없거나 보다 세밀한 제어가 필요하다면 Origin_{(EC2, ALB 뒤의 웹 서버나 S3 등)}에서 처리 해줘야 한다.
이는 인프라 관리자가 할 일은 아니고, 각 애플리케이션을 만든 개발자의 몫이다.

다행히 방법이 어렵진 않다.
예를들어 Docker 빌드시 사용할 nginx 파일을 다음과 같이 작성 할 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


gzip on;
gzip_static on; # filename.gz 존재 시, 클라이언트가 gzip 지원하면 직접 제공

brotli on;
brotli_static on; # filename.br 존재 시, 클라이언트가 br 지원하면 직접 제공
brotli_comp_level 6;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;

# 클라이언트 지원에 따라 우선 확장자 결정 (br > gzip)
map $http_accept_encoding $precompress {
 ~*\bbr\b ".br";
 ~*\bgzip\b ".gz";
 default "";
}

location / {
 try_files $uri$precompress $uri =404; # 지원 포맷 우선 제공, 없으면 원본
 add_header Vary "Accept-Encoding";
 expires 7d;
}

내부 전송 최적화

클라우드 내부적으로 이루어지는 통신 비용도 절약 할 필요가 있다.

동일 가용 영역(AZ)에 리소스 배치

동일 리전 내에서도 가용 영역(AZ)이 다르면 전송 요금이 붙는다.
통신이 잦은 인스턴스나 캐시같은 것들은 가급적 같은 AZ에 배치하자.
클라우드 서비스 제공자마다 약간의 차이는 있지만 동일 AZ 내 트래픽은 대체로 무료거나 매우 저렴하다.

⚠️ 여기서 잠깐!

단, 데이터베이스와 같이 데이터 영속성이 그 무엇보다 중요한 경우에는 예외이다.
이런건 가급적 멀티 AZ로 구성하는 걸 추천한다. _{(특히나 회사 생명이 걸려있다면)}

AZ라는건 결국 물리적인 데이터 센터인데, 다행히 아직까지 그런 경험은 없지만
“혹여나 센터나 불이라도 나면 어쩌지?” 라는 걱정을 한시름 놓을 수 있을 것이다.
VPC 내부 통신 활용

EC2 인스턴스간 통신을 할 때 대상의 Public IP를 목적지로 해서 보낸다고 생각해보자.
이는 마치 옆 집 사는 사람에게 물건을 전달하기 위해 우편을 붙이는 것과 같다.

이 경우 통신 패킷 자체가 IGW_{(Internet Gateway)}를 경유해 클라우드 밖으로 나갔다가
다시 들어오는 게 되어 사실상 외부 통신으로 간주된다. 비용 부과는 물론 지연까지 발생한다.

심지어 호출을 요청한 EC2가 Private Subnet에 있다면 문제는 더 심각해진다.
이 때는 NGW_{(NAT Gateway)}를 경유하게 되는데, 시간당 요금과 전송량 요금이 함께 부과된다.

이는 월간 비용 누수의 최상위 원인이 되기 쉽다.

S3, DynamoDB 등에 접근할 때도 마찬가지다.
반드시 VPC 엔드포인트(Gateway Endpoint)를 사용해 내부망으로 우회하자.
리전 간 전송 최소화

가장 비싼 내부 전송은 리전 간(Region to Region)의 통신이다.
데이터와 데이터를 소비하는 서비스를 가까운 리전에 두어 리전 간 복제 및 액세스를 최소화 하도록 하자.
비용 모니터링/관리

Cost Explorer로 전송 비용을 서비스/리전/AZ 기준으로 추적하고,
앞서 기술한 비용 할당 태그로 프로젝트 및 팀에 귀속시켜 원인을 파악하자.

기타 서비스

Elastic Kubernetes Service (EKS)

AWS에서 제공하는 KaaS_{(Kubernetes as a Service, 서비스형 k8s)}이다.
서비스 자체는 훌륭한데 역시나 가격이 문제다.

Kubernetes 버전 지원 티어	요금
표준 Kubernetes 버전 지원	시간 & 클러스터당 0.10 USD
확장 Kubernetes 버전 지원	시간 & 클러스터당 0.60 USD

원화로 바꾸면 표준형의 경우 1달에 약 10만원, 확장형은 60만원(!!)이 넘게 부과된다.
지금 이건 Node 하나 없는 클러스터 1개의 자체적인 가격이다.

대응전략:

Arm CPU, Spot, Savings Plan등 앞서 언급했던 내용들과 중복되는 것을 제외하겠다.

클러스터 수 조절

EKS 클러스터의 비용은 클러스터 개수에 비례한다.
당연한 얘기지만, 사용하지 않는 클러스터에 대해서도 비용이 부과된다.

특별한 이유가 있는게 아니라면
하나의 리전에는 k8s 1~2개(환경 분리 목적) 정도만 배치하도록 하자.
표준형(Standard)을 사용

표준형과 확장형의 가격 차를(6배) 보고 확장형에 엄청난 어드밴티지가 있겠거니 생각하겠지만,
사실 둘의 차이는 Kubernetes API의 지원 기간 정도가 전부다.

보통 k8s는 3개의 마이너 버전에 대한 패치를 제공하는데 EKS는 이 지원 정책을 따라간다.
표준형은 k8s에 대한 보안 패치, 버그 수정, 컨트롤 플레인 관리등을 표준 k8s 업데이트 사이클에 맞춰 하고,
확장형은 여기서 1년을 더 사용할 수 있도록 연장해준다.

EKS를 운영하는 가장 좋은 방법은 표준 지원 기간 내에 k8s 버전을 최신화 하는 것이다.
확장형으로 돈 더 내면서 1년 유예를 둔다고 해도 그 기간마저 지나면 API 지원이 중단된다.

그대로 방치해버리면 새로운 k8s 기능을 사용하지 못하거나 보안 위험에 노출 될 수도 있다.
관심을 가지고 부지런하게 대응 해주도록 하자.

CloudFront

앞서 얘기했듯 AWS의 CDN 서비스이다.
HTML / CSS / JS 같은 파일을 S3에 두고 웹사이트를 호스팅해주는 데 주로 사용한다.

이 역시 서비스 자체는 문제가 없는데 역시나 가격이 발목을 잡는다.

요금 페이지 첫 장부터 진정한 '프리' 티어 어쩌구 하면서 유혹한다.
조금만 더 내려보면 다음과 같다.

CloudFront는 상시 무료(Always Free) 혜택으로 월 1TB 데이터 전송 아웃이 무료이며, 초과분부터 과금된다.

대한민국이 인도 칼럼 옆에 다른 국가들과 함께 낑겨있는 걸 볼 수 있는데, GB당 $0.12라고 적혀있다.
예시로 한국에 위치한 Cloudfront에서 한국에 있는 소비자들에게 1달에 3TB 정도의 데이터를 전송한다고 생각해보자.

기본 1TB는 무료니 2,000 * 0.12

계산해보면 달에 약 $240가 부과될 것임을 알 수 있다.

대응전략:

캐시 관리

자주 바뀌지 않는 자산(기업 로고 등)은 TTL을 길게,
자주 바뀌는 컨텐츠는 짧게 혹은 no-cache로 설정을 해주자.

CloudFront는 요청 URL, 헤더, 쿼리 문자열 등을 기반으로 캐시 키를 생성한다.
캐시 키에 불필요한 Query String이나 Header는 제외해서 하나의 키로 적중 될 수 있게 단순화 하자.
원본 요청(Origin Fetch) 줄이기

엣지에서 캐시 미스가 나도 원본에 곧장 가지 않도록 중앙 캐시 계층을 둬 부하를 줄이자.
압축

앞서 네트워크 섹션에도 기술했듯 Gzip등을 활용해 전송 데이터를 압축해서 보내도록 하자.

다른 CDN을 고려하자

위 방법들 이외에도 전략은 많지만,
꼭 CloudFront에 매몰될 필요가 없다면 다른 CDN 서비스를 도입하는 것도 좋다.

개인적으로 CDN은 Cloudflare를 추천한다.
둘을 간단히 비교하면 다음과 같다 :

	Cloudflare	AWS CloudFront
네트워크 아키텍처	리버스 프록시	전통적인 CDN
기본 설정 방법	Nameserver	Special URLs
주요 기능	CDN과 DDoS 방어	CDN
마켓 포지셔닝	Standalone 플랫폼	AWS 클라우드 서비스 중 일부
프리티어	과금 없음	매달 1TB 데이터 전송, 천만건 요청, 2백만건 함수 호출 무료

다만 이건 어디까지나 나의 “개인적인” 의견이다.

다음과 같은 경우라면 CloudFront를 쓰는 게 낫다.

AWS 생태계와_{(S3 ,EC2등)} 긴밀하게 통합되길 원한다
웹 서비스가 대박이 나서 월 1,000TB 정도 트래픽이 나온다 _{(사용량이 올라갈수록 비용이 내려간다)}

ElasticIP (EIP)

ElasticIP는 AWS에서 제공하는 고정 IP 리소스이다. 별 건 없고 EC2 Public IP를 고정할 때 주로 쓴다.

문제는 AWS에서 Public IPv4 EIP의 경우,
현재 할당을 했는지 안 했는지 여부에 관계 없이 시간당 $0.005를 부과한다는 것이다.

계산해보면 한 달에 $3.6 ~ $3.72, 대략 $4 정도 부과된다. _{(그게 무슨 소리니 애떱아…)}

뭐, 자기들 말로는 IPv4 주소가 전 세계적으로 고갈 되어감에 따라 내놓은 정책이라고 한다.
주소 하나당 1달에 4달러가 별 거 아닌 거 같아도 이런게 많아지면 은근히 도트딜이 아프게 들어온다.

대응전략:

안 쓰는 ElasticIP는 지우도록 하자
IPv6 주소를 발급받아 쓰자

IPv6는 무료다. 워낙 대역폭이 넓어서 인류가 멸망할 때까지 써도 남아 돌 것이다.
다만 IPv6 할당이 가능한 리소스는 한정되어 있다. 이 점을 유의하자.

IPv4 문제는 다른 클라우드 서비스들도 대체로 상황은 비슷하다.

마치며

최대한 간략하게 쓰려고 했는데, 하다보니 한도 끝도 없이 늘어져 버렸다. _{(분량 조절 실패)}

AWS에는 워낙 예상치 못한 숨겨진 추가 비용이 많아서 관리하는데 이만저만 품이 드는 것이 아니다.

가장 좋은 접근법은 AWS에 너무 얽매이지 말고 AWS 이외의 다른 클라우드 서비스,
혹은 On-Premise의 인프라를 한데 묶어 멀티 & 하이브리드 클라우드 인프라로 전환하는 것이다.

다만 그러면서 따라오는 문제점도 있다.
멀티/하이브리드 전환은 다음의 교환비용을 수반한다.

벤더 종속성 감소 -> 관리 복잡성 증가(관제, 알림, 보안정책, 빌링 통합)
비용 최적화 옵션 확대 -> 아키텍처/데이터 일관성 유지 비용 상승
장애 내성·거점 다양성 -> 운영 인력/플랫폼 역량 요구 수준 상승

현실적인 실행 순서는 아래와 같이 추천한다.

비용 가시성 표준화:

비용 할당 태그 강제와 팀별 Cost 대시보드 고정 배치
낭비 차단 가드레일:

미사용 리소스 자동 종료·알림, EIP·스냅샷 정리 정기화
컴퓨팅 포트폴리오:

Arm 전환 검토 -> Serverless/스팟/RI·절약 플랜 혼합 적용
데이터 등급화:

S3 스토리지 클래스/라이프사이클로 자동 이전·만료 정책화
DTO 최소화:

VPC 엔드포인트, 동일 AZ 배치, 압축·CDN 캐시 키/TTL 최적화
멀티·하이브리드 파일럿:

단일 워크로드부터 이중화, 관제·빌링 통합 방식 검증

결국 원칙은 단순하다.

측정 → 표준화 → 자동화를 반복하며, 특정 환경에 과도하게 속박되지 않는 것이다.
각 조직의 위험 허용도와 인력 역량에 맞춰 작은 실험부터 시작해보자.

참고 자료

AWS 비용 할당 태그 (Cost Allocation Tags)

AWS EC2 스팟 인스턴스 개요

AWS EC2 예약 인스턴스(Reserved Instances)

AWS EC2 Auto Scaling Groups 개요

AWS Savings Plans 개요

AWS Lambda 개요

Docker Buildx 문서

AWS S3 스토리지 클래스 개요

AWS S3 수명 주기(Lifecycle) 관리

AWS VPC 엔드포인트(Gateway/Interface) 개요

AWS NAT 게이트웨이 요금

AWS EKS 요금

AWS CloudFront 요금

AWS Elastic IP(IPv4) 문서

Prometheus

Grafana

Kubernetes HPA (Horizontal Pod Autoscaler)

Kubernetes Cluster Autoscaler

Helm 공식 문서

Cloudflare CDN

k8s에 Ollama AI 서버 올려보기

Sun, 26 Oct 2025 00:00:00 +0900

들어가기 앞서

며칠 전에 “오프라인 환경에서 RAG 앱 동작시키기”라는 포스트를 올렸다.
마침 지난 금요일에 이 프로젝트가 마무리 되었는데 _{(포스팅 시간 기준으로는 이틀 전)}
대략적인 개요는 다음과 같다.

자체 인공지능 + VectorStore가 포함된 온전히 동작하는 RAG 서비스를 하나 만들어라
OS는 Windows 11 Pro이고
하드웨어는 8GB VRAM GPU가 장착된 노트북이다.
아, 그런데 이제 오프라인을 곁들인 _{(아예 와이파이 끊어버림)}

대략적인 시스템 구조

Windows, 노트북, 오프라인… 거를 타선이 없다.

그런데 결과는 의외로 잘 나와서 대표님도 만족하셨다.
그렇다고 마냥 기뻐하고 있을 수는 없다. 이런 걸 진행한 의도가 무엇인지 파악해야 한다.

듣자하니 추후 자체적인 AI 서버 도입을 희망하시는 듯 하다.
본래 예전부터 신기한 기술 나오면 눈에서 붉은 안광을 뿜으시긴 했는데,
이번엔 그게 AI인 모양이다.

고민이 깊어져 간다…

서비스를 만드는 건 그렇다 쳐도 "인공지능 인프라를 어떻게 구성해야 하는가"가 주요 과제다.
그리고 모든 이슈는 한 가지 단순한 사실로부터 시작되었다.

하드웨어 가격이 너무 비싸다

내가 회사 인프라를 관리하면서 가장 조심스러워 하는게 바로 비용 문제이다.
잘못되면 욕 먹기 제일 쉬운 분야라 눈에 불을 켜고 한 푼이라도 줄이기 위해 노력해야 한다.

인공지능을 제대로 동작시키기 위해선 고성능의 병렬 연산 장치가 필수적인데
GPU_{(그래픽 처리 장치)}건 NPU_{(신경 처리 장치)}건 이런 하드웨어들은 하나같이 무지하게 비싸다.

NPU는 나도 실물로 본 적이 없으니, GPU를 기준으로 생각해보면
데스크탑 PC 전체 가격의 심하면 50% 이상을 차지할 정도로 엄청난 몸값을 자랑한다.

모델

필요한 하드웨어 사양은 어떤 모델을 사용하는가에 따라 크게 달라진다.
마침 대표님이 눈독 들이고 있는 게 하나 있어 이를 예시로 쓰겠다.
얼마 전, 8월에 공개된 gpt-oss이다.

항목	gpt-oss-120b	gpt-oss-20b
모델 크기	120B	20B
성능	o4-mini와 매우 유사한 성능	o3-mini와 매우 유사한 성능
아키텍처	128개의 전문 모델 통합	32개의 전문 모델 통합
활성 영역	동작 시 5.1B 크기 영역 활성화	동작 시 3.6B 크기 영역 활성화
권장 VRAM	약 66GB	약 13GB
권장 하드웨어	H100 80GB 하드웨어 1대로 원활하게 동작	16GB VRAM 이상의 그래픽카드로 원활하게 동작

참고로 H100 1개당 가격은 작성일 기준 4,000만원정도 한다. 😱

노트북으로 먼저 테스트해보신 것으로 미루어 짐작하면, 여기선 gpt-oss-20b가 더욱 현실성이 있다.

상용 GPU 사용시

HuggingFace에 올라온 gpt-oss-20b의 모델 정보를 보면 16GB VRAM 이상의 그래픽 카드를 쓰면 원활하게 쓸 수 있다고 한다.

실제로는 Ollama뿐 아니라 Docling같이 보조 AI 서비스도 같이 올라갈 것으로 생각되기에,
넉넉하게 그 2배인 32GB VRAM을 생각하고 있다.

이러한 GPU는 1개당 대략 4~500만원 정도 나간다.

클라우드 사용시

AWS에서 32GB VRAM이 장착된 g5g.16xlarge 인스턴스의 작성일 기준 1달 평균 사용 비용은 다음과 같다.

온디맨드 : $2388.29

쓴 만큼 내기, 후불제, 기본가 _(최고가)
스팟 : $672.59

가장 저렴하긴 한데, 스팟을 쓰기엔 무리가 있다.

필요할 때만 잠깐 쓰는 머신러닝이나 Docling 문서 전처리 정도의 작업을 담당하는 거면 모르겠으나,
상용 서비스에는 부적합하다. _{저렴한 데는 이유가 있다.}

설마 그러겠냐만 한창 서비스중에 인스턴스가 종료되기라도 하면 인생이 아주 스펙타클 해질 것이다.
1년 예약 분할 지불 : $ 1559.73
1년 예약 일시불 : $ 1455.74
3년 예약 분할 지불: $ 1102.4
3년 예약 일시불 : $ 959.5

달러당 환율 1,400으로 계산하면 한달에 135만원이다.
3년 일시불이니 총 지출은 대략 4,800만원(!!)이다. _{그냥 H100 하나 사고 만다.}

전반적으로 보면 On-Premise 서버를 쓰는게 보다 합리적으로 보인다.
물론 클라우드에 올라가는 서버용 연산장치를 단순히 상용 GPU와 VRAM 크기가 같다고 동일선상에 두는 건 불합리하다.

더욱이 EC2의 인스턴스 타입은 CPU나 시스템 메모리 사이즈도 티셔츠마냥_{(large, x-large)} 모두 딱딱 정해진 값이다.
예시로 쓰인 g5g.16xlarge의 경우 Arm 64코어 CPU에 시스템 메모리 128GB가 적용된다.

그 비용도 포함된 가격임을 고려해봐야 한다.

클러스터 구성

앞서 H/W 가격과 이어지는 문제이다. 그렇다면 클러스터 구성을 어떻게 할 것인가?
포인트는 GPU가 포함된 Node의 위치이다.

싹 다 클라우드에 올리기 _{(상남자 스타일)}

문자 그대로의 의미이다.
대표님이 Microsoft Azure에 3년 예약 GPU 인스턴스가 저렴하다고 한 번 써보자고 하시는데…

개인적으로 가장 편한 방법이긴 하나,
GPU 사용료 비싼건 어느 클라우드를 쓰건 오십보백보라 그다지 추천하지는 않는다.
전부 IDC에서 운영

On-Premise에 모든 Node를 배치하는 방법이다.
IDC + 클라우드 — Istio 다중 클러스터 서비스 메시

클라우드에 k8s 하나, IDC에도 독립적인 On-Premise k8s 하나씩 두고 On-Premise에는 GPU Node들을 배치하는 방법이다.

이상적이긴 한데 Istio 구성이 다소 복잡해질 것으로 보인다.
EKS Hybrid Node

이건 나도 이번에 조사해보다가 알게 된 건데, AWS EKS에 외부 Node를 등록하는 방식이다.
요컨대 Control Plane은 여전히 AWS에 존재하고, Worker Node는 IDC에 둘 수 있다.

당연히 무료는 아니고, 등록한 Worker Node의 코어당 연결 시간에 비례해서 책정된다.
예를들어, 8 코어 16 쓰레드 CPU를 가지는 Node 1개를 연결하면 1달에 대략 33만원 정도가 나온다.
단순 연결하는데 쓰는 비용이 이렇다면 당장의 현실성은 없다.
그래도 이 접근방법의 개념은 되게 재밌어서 개인적으로 흥미가 많이 간다.

자세한 내용은 AWS 공식 문서를 참고해보자.

k8s에 Ollama 올려보기

고민거리를 늘어놓느라 서론이 길었는데, 결국 여태 내용 중 아직 확정된 것은 없다. _{(사실상 푸념)}
아무래도 큰 비용이 걸려있는 일이다보니 주말에 나 혼자 머리 싸맨다고 해결될 리 만무하다.

그래서 일단은 당장 할 수 있는 걸 해보기로 했다.
바로 내가 개인적으로 운영하는 On-Premise 클러스터에 Ollama 서비스를 올려보는 것이다.

사용할 GPU

이번에 고생해줄 GPU는 NVIDIA의 RTX 2080이다.

왕년에는 끗발 좀 날리던 녀석이었는데,
릴리스_{(디아블로 IV)}의 권능 앞에 무너져 새 GPU_{(RTX 4070)}에 자리를 내주고 쉬고 있었다.

그러다 몇 달 전에 Jellyfin이라는 서비스의 ffmpeg GPU 가속을 위해 싹 분해해서
먼지 청소도 해주고 써멀 패드도 갈아주고 팬도 전부 새걸로 바꿔 끼웠다.
분해 당시 부식이나 냉납도 없었다. 고로 사용하는데 지장은 없을 것이다.

대략적인 스펙은 다음과 같다.

항목	내용
NVIDIA 칩셋	RTX 2080
인터페이스	PCIe3.0×16
CUDA 프로세서	2944개
메모리 종류	GDDR6
메모리 용량	8GB

Nvidia GPU Operator 설치

Ollama에 GPU를 연결해야 하므로 Nvidia GPU Operator를 클러스터에 설치해줘야 한다.
AMD GPU를 사용한다면 AMD GPU Operator를 설치해야 하는데, 이번 포스트에서는 Nvidia를 기준으로 하겠다.

Nvidia Driver 설치

우선 GPU Node에 접속해서 Nvidia Driver부터 설치해야 한다.
OS나 CPU Architecture에 따라 방법이 천차만별인데, 일단 가장 보편적인 Ubuntu를 기준으로 하겠다.
환경별 설치 방법은 이 문서 참조.

1
2
3


sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt update
sudo ubuntu-drivers autoinstall

설치가 완료되면 시스템을 재부팅해준다.

1

sudo reboot

재부팅 후 다음의 명령어를 입력해보자.

1

nvidia-smi

다음과 같이 출력되면 정상이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


Mon Oct 27 01:57:28 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.195.03 Driver Version: 570.195.03 CUDA Version: 12.8 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 2080 Off | 00000000:29:00.0 Off | N/A |
| 0% 30C P8 2W / 240W | 1MiB / 8192MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| No running processes found |
+-----------------------------------------------------------------------------------------+

네임스페이스 생성

1
2
3


kubectl create ns gpu-operator
kubectl label --overwrite ns gpu-operator pod-security.kubernetes.io/enforce=privileged
kubectl get ns --show-labels | grep gpu

Nvidia GPU Operator가 설치될 네임스페이스를 만든 후 네임스페이스 내 pod의 보안정책을 privileged로 설정해 GPU 접근을 허용해야 한다.

Helm Repository 추가

1
2


helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

values 설정

다음의 커맨드로 기본 차트 values 값을 가져와 로컬에 저장해보자.

1

helm show values nvidia/gpu-operator > nvidia-gpu-operator.yml

nvidia-gpu-operator.yml에 보면 여러 옵션들이 있는데, 몇 가지 수정해줘야 할 것이 있다.

Driver 설정 변경

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 위에서 이미 Nvidia Driver를 설치했으므로 제외
driver:
 enabled: false
# 이 아래 옵션은 H100 등에서만 사용 가능하다
migManager:
 enabled: false
vgpuDeviceManager:
 enabled: false
vfioManager:
 enabled: false

Toolkit 설정 변경

나는 containerd를 기본 Runtime으로 사용하고 있어서 다음과 같이 설정해주었다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


operator:
 defaultRuntime: containerd  # 기본 런타임을 containerd로 설정

toolkit:
 enabled: "true"
env:
 - name: CONTAINERD_CONFIG
 value: /etc/containerd/config.toml
 - name: CONTAINERD_SOCKET
 value: /run/containerd/containerd.sock
 - name: CONTAINERD_SET_AS_DEFAULT
 value: "1"

차트 배포

1
2
3


helm install gpu-operator nvidia/gpu-operator \
 -n gpu-operator \
 -f ./nvidia-gpu-operator.yml

Ollama 설치

Ollama도 Helm으로 설치할 수 있다.

네임스페이스 생성

1

kubectl create namespace ollama

AI 모델을 저장할 PVC 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# ollama-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: ollama-models-pvc
 namespace: ollama
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 30Gi

1

kubectl apply -f ollama-pvc.yaml

Helm Repository 추가

1
2


helm repo add ollama https://ollama.ai/kubernetes/ollama
helm repo update

values 설정

Nvidia GPU Operator와 마찬가지로 values를 가져와 살펴볼 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# ollama.yml
ollama:
 gpu:
 enabled: true # GPU 사용 여부

runtimeClassName: nvidia # nvidia runtime 사용 (Nvidia GPU Operator)

persistentVolume:
 enabled: true
 existingClaim: ollama-models-pvc

# (선택) GPU가 설치되어 있는 Node에만 파드가 스케쥴링 되도록 하기
affinity:
 nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms:
 - matchExpressions:
 - key: nvidia.com/gpu.present
 operator: Exists

여담으로 Helm Chart를 통해 AI Models를 관리하는 것도 가능하다.

예를 들어:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


ollama:
 models:
 pull:
 - deepseek-r1:8b # DeepSeek 모델을 다운로드
 run:
 - deepseek-r1:8b # 원하는 모델을 메모리에 상주

 # 혹은 다음과 같은 방식으로 커스텀 모델 생성도 가능
 create:
 - name: deepseek-r1-ctx32768
 template: |
 FROM deepseek-r1:8b
 PARAMETER num_ctx 32768

 clean: false # 이 값을 true로 하면 위에서 지정한 모델만 남기고 다 지운다

그런데 그다지 추천하지는 않는다.

AI 모델 변경이 의외로 자주 일어나는데 그때마다 Helm 차트를 다시 배포하는 건 꽤나 번거롭다.

차트 배포

1

helm install ollama ollama/ollama -f ollama.yml -n ollama

Open Web UI 설치

Ollama Chart는 오로지 Ollama만 설치해준다.
직접 테스트해볼 수 있게 UI도 별도 Chart로 배포했다.
기본적인 AI 인프라만 필요하다면 이 섹션은 무시해도 된다.

네임스페이스 생성

1

kubectl create namespace open-webui

환경 설정을 저장할 PVC 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# open-webui-pvc.yml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: open-webui-pvc
 namespace: open-webui
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 2Gi

1

kubectl apply -f open-webui-pvc.yaml

Helm Repository 추가

1
2


helm repo add open-webui https://open-webui.github.io/helm-charts
helm repo update

values 설정

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


# open-webui-values.yml
ollama:
 enabled: false # Ollama 설치 안 함
 # 이 부분이 좀 의아할텐데 Open Web UI 차트에서는
 # 내부적으로 Ollama를 설치하는 것도 가능하다.
 # 여기에 위 Ollama 차트의 설정을 그대로 넣으면 가능하다.
 # 하지만 가급적 분리해서 배포하는 걸 추천한다.

# 자체 Ollama를 안 쓰기 때문에 UI가 연결할 Ollama의 URL을 지정해줘야 한다
# FQDN을 다 쓸 필요는 없고 http://<서비스>.<네임스페이스>:<포트>로 적으면 된다.
# 서비스와 네임스페이스는 모두 "ollama"이고 포트는 기본적으로 11434이다.
# 따라서 "http://ollama.ollama:11434"를 적어준다.
ollamaUrls:
 - http://ollama.ollama:11434

# (선택) Tika 설정
tika:
 enabled: true

# (선택) Health Check 설정
livenessProbe:
 httpGet:
 path: /health
 port: http
 failureThreshold: 1
 periodSeconds: 10

readinessProbe:
 httpGet:
 path: /health/db
 port: http
 failureThreshold: 1
 periodSeconds: 10

startupProbe:
 httpGet:
 path: /health
 port: http
 failureThreshold: 20
 periodSeconds: 5
 initialDelaySeconds: 30

# (선택) Ingress 설정
ingress:
 enabled: true
 class: nginx
 host: '<보유한 도메인 레코드, 가령 ai.example.com>'

# Persistence 설정
persistence:
 existingClaim: open-webui-pvc

차트 배포

1
2
3


helm install open-webui open-webui/open-webui \
 -f open-webui-values.yaml \
 -n open-webui

동작 테스트

ingress 설정을 해두었다면 설정한 domain으로, 별도 설정을 안 했다면
다음의 커맨드로 포트포워딩 후 localhost:8080으로 접속해보자.

1

kubectl port-forward -n open-webui svc/open-webui 8080:80

간단하게 관리자 설정을 마치고 로그인한 뒤
우측 상단의 프로필 클릭 -> 관리자 패널 -> 설정으로 들어가보자.
혹은 단순히 <Open Web UI Base URL>/admin/settings/general로 들어갈 수 있다.

굉장히 다양한 옵션이 있다.
우선 기본 동작 테스트를 해야하므로, 모델로 이동해 AI 모델 하나를 다운로드 받아보도록 하자.

Ollama.com 검색 페이지에 접속해서 원하는 모델을 찾아보자
AI 모델이 워낙 종류가 다양해서 뭐 하나 고르는 게 쉽지는 않다.
몇 가지 추천을 해보자면 다음과 같다.

하드웨어 사양과 취향에 맞춰 원하는 모델을 다운로드 받아보자.
내 경우 exaone-deep:7.8b란 모델을 다운로드 받았다.

모델 다운로드가 완료되면 간단하게 AI와 채팅해볼 수 있다.

마치며

이번 포스트에서는 Kubernetes 클러스터에 Ollama AI 서버를 구축하는 과정을 다뤄봤다.
Nvidia GPU Operator 설치부터 Ollama, Open Web UI 배포까지 전 과정을 Helm 차트를 통해 간단하게 구성할 수 있었다.

물론 실제 상용 환경에서는 앞서 언급한 비용 문제와 클러스터 구성 방식에 대한 고민이 필요하다.
특히 GPU 하드웨어의 높은 가격대와 클라우드 사용료는 여전히 큰 부담으로 남아있다.

하지만 이번 실험을 통해 얻은 경험은 향후 실제 AI 인프라 도입 시 큰 도움이 될 것 같다.
On-Premise 환경에서도 충분히 동작하는 것을 확인했으니, 비용 효율성을 고려한 하이브리드 구성도 충분히 검토해볼 만하다.

추후 계획

포스트에는 굳이 명시하지 않았는데, Ollama Chart 역시 별도의 Ingress 설정을 해주었다.

사용한 도메인 레코드는 ollama.ayteneve93.com.

OAuth2 Proxy를 보안 레이어로 감싸주고 Terraform이 랜덤하게
생성한 OAuth Bypass Key 헤더를 설정, 인증된 사용자라면 외부에서도 들어올 수 있게 환경을 마련하였다.

테스트로 설치한 Ollama지만 일단 자원을 잡아먹고는 있으니 이걸 앞으로 어떻게 활용할까도 생각해봐야 한다.

가령:

Cursor와 같은 인공지능 IDE와 연결한다거나
deepseek-coder 모델을 사용해서 코드 분석을 맡겨본다거나
llava 같은 Vision 모델을 사용해서 그림을 그리게 시킨다거나

또한 DCGM Exporter 차트를 배포해 Prometheus에서
GPU 사용량을 모니터링할 수 있도록 할 계획이다.

참고 자료

Nvidia GPU Operator 공식 문서

Ollama Kubernetes Helm Chart

Open Web UI Helm Chart

Nfs subdir external provisioner

Sat, 04 Oct 2025 00:00:00 +0900

연관 포스트

Oracle Cloud Infrastructure

문제의 시작

OCI Instance(Node)의 Boot Volume 최소값 제한

OCI Free Tier에 따르면 OKE에서 가용할 수 있는 자원은 다음과 같다.

CPU : 4개
메모리 : 24GB
블록 스토리지 : 200GB

이에 맞춰 Terraform으로 OKE 클러스터와 4개의 인스턴스를 가지는 ARM Node Pool을 생성했다.

각 Node는 1개의 CPU와 6GB의 메모리를 가진다.

스토리지의 경우 추후 PVC 생성을 위해서도 쓰이므로 최대한 작게 잡아주려고 했다.

Node에는 최소한의 용량만, 나머지 대부분은 PVC로 할당

그런데 실제로 생성된 Instance의 정보를 보니 Boot Volume이 비정상적으로 크게 만들어져 있다.

k8s Node의 역할을 하는 Oracle Instance 중 하나의 Boot Volume 정보

Boot Volume은 문자 그대로 Linux 시스템이 부팅하는데 필요한 기본 디스크로, 윈도우로 치면 C드라이브 같은 존재이다.

확인 결과, 다음과 같은 이슈가 발생했다.

Instance의 Boot Volume의 크기는 최소 47Gi (50GB) 이상 할당해줘야 한다.
당연히 이 용량은 Free Tier에서 제공되는 200GB에서 차감된다.
이러면 단순히 Node 4개를 만드는 것만으로도 Free Tier의 200GB를 다 써버리게 된다.

단 1개의 PVC도 생성할 수 없다.

Persistent Volume도 마찬가지

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-pvc
spec:
 storageClassName: oci-bv #OCI에서 기본적으로 제공하는 Storage Class
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 100Mi 

이처럼 OKE k8s 클러스터에 pvc 하나를 만든다고 가정해보자.
oci-bv는 Oracle에서 기본적으로 제공되는 Storage class로 OCI Block Volume을 저장소로 쓴다.

약 100MB 정도의 크기를 가지는 작은 PVC이다. 그럼 실제 만들어지는 OCI Block Volume의 크기도 100MB 정도여야 하지 않을까?

어림도 없다. 여기도 크기 제약이 걸려있어서 최소 47Gi (50GB) 이상을 할당해줘야 한다.

극단적으로 Node를 1개만 쓴다고 가정해도, PVC는 3개가 한계이다. 각각 50GB씩… _{오라클, 보고 있나?}

PVC 자체도 50GB가 최소라 노드 1개 PVC 3개가 한계이다.

해결방안

NodePool의 스펙 및 수 조정

우선 Node에 50GB씩 기본 할당 되는 건 어쩔 도리가 없기 때문에 Node 수를 타협해야 한다.
클러스터로써 구색은 맞춰야 하므로 기존 4개에서 2개로 줄였다.
각각 CPU는 2개, 메모리는 12GB씩 할당해줬다.

이걸로 벌써 100GB가 날아갔다

시스템 구성 요소

NFS Subdir External Provisioner를 사용해서 별도의 StorageClass를 만들어줘야 한다.

NFS Storage, 즉 NFS 서버를 Source로 해서 StorageClass를 만들고, 해당 StorageClass를 통해 PVC를 생성하면 NFS 서버에 볼륨이 생성되고 데이터가 저장되는 구조이다.

주요 구성 요소를 배포 순서에 따라 나열하면 다음과 같다.

OCI Block Volume

앞서 Node 2개를 배치했으므로, 사용 가능한 용량 제한은 100GB이다.

남은 100GB를 모두 사용하는 OCI Block Volume 1개가 필요하다.
NFS Server

1에서 생성한 OCI Block Volume을 PVC로 매핑 받아 NFS Storage를 제공하는 서비스이다.
NFS Subdir External Provisioner

이번 포스트의 핵심으로, 2에서 생성한 NFS 서버를 Source로 StorageClass를 제공한다.
(선택) FileBrowser, SFTP Container

보다 편한 관리를 위한 것으로, 선택사항이다.
oci-bv가 제공하는 PVC는 ReadWriteOnce 모드만 제공되므로 반드시 하나의 Pod에 NFS Container와 함께 정의해줘야 한다.

사용하는 도구

Terraform: 인프라 자원 관리 (OCI 볼륨, 백업 정책)
Kubernetes Manifests: NFS 서버, File Browser, SFTP 서비스
Helm: NFS Subdir External Provisioner 설치

실제 구현은 CDKTF를 써서 하나의 Stack 파일로 구성했다.

GitHub 링크에서 확인 가능하다.

Terraform 인프라 구성

OCI 인프라 구성은 Terraform OCI Provider를 사용했다.

HCL 코드에 프로바이더를 연결하는 과정은 여기선 생략한다. (추후 별도 포스팅 예정)

OCI 블록 볼륨

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# main.tf
resource "oci_core_volume" "nfs_core_volume" {
 compartment_id = var.compartment_id
 availability_domain = var.availability_domain
 size_in_gbs = 100
 display_name = "nfs-core-volume"

 lifecycle {
 prevent_destroy = true
 }
}

볼륨 백업 정책

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


# backup_policy.tf
resource "oci_core_volume_backup_policy" "nfs_core_volume_backup_policy" {
 compartment_id = var.compartment_id
 display_name = "nfs-volume-backup-policy"

 schedules {
 backup_type = "INCREMENTAL"
 period = "ONE_WEEK"
 retention_seconds = 60 * 60 * 24 * 7 * 3 # 3주 보관
 day_of_week = "SUNDAY"
 hour_of_day = 2
 offset_seconds = 0
 offset_type = "STRUCTURED"
 time_zone = "REGIONAL_DATA_CENTER_TIME"
 }

 schedules {
 backup_type = "FULL"
 period = "ONE_MONTH"
 retention_seconds = 60 * 60 * 24 * 30 * 2 # 2개월 보관
 day_of_month = 1
 hour_of_day = 3
 offset_seconds = 0
 offset_type = "STRUCTURED"
 time_zone = "REGIONAL_DATA_CENTER_TIME"
 }
}

백업 스케줄:

증분(INCREMENTAL) 백업: 매주 일요일 2시, 3주 보관
전체(FULL) 백업: 매월 1일 3시, 2개월 보관

백업 정책 할당

1
2
3
4
5


# backup_policy_assignment.tf
resource "oci_core_volume_backup_policy_assignment" "nfs_core_volume_backup_policy_assignment" {
 asset_id = oci_core_volume.nfs_core_volume.id
 policy_id = oci_core_volume_backup_policy.nfs_core_volume_backup_policy.id
}

변수 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# variables.tf
variable "compartment_id" {
 description = "OCI Compartment ID"
 type = string
}

variable "availability_domain" {
 description = "OCI Availability Domain"
 type = string
}

출력값 정의

1
2
3
4
5


# outputs.tf
output "nfs_volume_id" {
 description = "NFS Core Volume OCID"
 value = oci_core_volume.nfs_core_volume.id
}

nfs_volume_id 값은 PV를 만들 때 필요하다.

변수 파일 생성

1
2
3
4


cat > terraform.tfvars << EOF
compartment_id = "< 배포할 OCI Compartment의 ID >"
availability_domain = "< AD 이름, 예시: ibHX:AP-CHUNCHEON-1-AD-1 >"
EOF

Terraform 배포

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Terraform 초기화
terraform init

# 인프라 계획 확인
terraform plan -var-file="terraform.tfvars"

# 인프라 배포
terraform apply -var-file="terraform.tfvars"

# 출력값 확인 (볼륨 ID 등)
terraform output

k8s Manifest

네임스페이스 생성

1
2
3
4
5


# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
 name: nfs-system

PersistentVolume 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# persistentvolume.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
 name: nfs-pv
 annotations:
 pv.kubernetes.io/provisioned-by: blockvolume.csi.oraclecloud.com
spec:
 storageClassName: oci-bv
 persistentVolumeReclaimPolicy: Retain
 capacity:
 storage: 100Gi
 accessModes:
 - ReadWriteOnce
 persistentVolumeSource:
 csi:
 driver: blockvolume.csi.oraclecloud.com
 volumeHandle: <OCI_VOLUME_OCID> # Terraform에서 Output 된 Volume ID값을 넣어준다.
 # ocid1.volume.oc1 어쩌구 하는 값이다. Web Console에서 복사해서 가져와도 된다.
 fsType: ext4
 nodeAffinity:
 required:
 nodeSelectorTerms:
 - matchExpressions:
 - key: failure-domain.beta.kubernetes.io/zone
 operator: In
 values:
 - <AVAILABILITY_DOMAIN>

PersistentVolumeClaim 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# persistentvolumeclaim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: nfs-pvc
 namespace: nfs-system
spec:
 volumeName: nfs-pv # 위에서 생성한 PV의 이름이다
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 100Gi
 storageClassName: oci-bv

ConfigMap (Pod의 SFTP 컨테이너용 SSH 키 관리, 선택사항)

1
2
3
4
5
6
7
8
9


# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
 name: nfs-system-sftp-config
 namespace: nfs-system
data:
 ssh-public-key: |
 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ... # SSH 공개키

Service 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# service.yaml
apiVersion: v1
kind: Service
metadata:
 name: nfs-service
 namespace: nfs-system
spec:
 selector:
 app: nfs
 ports:
 - name: nfs
 port: 2049
 targetPort: 2049
 protocol: TCP
 # -- 선택 사항 -- #
 - name: file-browser
 port: 8080
 targetPort: 8080
 protocol: TCP
 - name: sftp
 port: 22
 targetPort: 22
 protocol: TCP

Deployment 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113


# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nfs-deployment
 namespace: nfs-system
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nfs
 template:
 metadata:
 labels:
 app: nfs
 spec:
 # FileBrowser를 안 쓸 거라면 initContainers는 필요 없음 
 initContainers:
 - name: init-filebrowser-db
 image: busybox:1.35
 command:
 - /bin/sh
 - -c
 - |
 mkdir -p /exports/fb-database
 chown -R 1000:1000 /exports/fb-database
 chmod -R 755 /exports/fb-database
 volumeMounts:
 - name: nfs-storage
 mountPath: /exports

 containers:
 # NFS 서버 컨테이너 (핵심!!)
 - name: nfs-server
 image: itsthenetwork/nfs-server-alpine:latest-arm
 imagePullPolicy: Always
 ports:
 - containerPort: 2049
 protocol: TCP
 securityContext:
 capabilities:
 add:
 - SYS_ADMIN
 - SETPCAP
 command:
 - /bin/sh
 - -c
 - |
 mkdir -p /exports/services
 /usr/bin/nfsd.sh
 volumeMounts:
 - name: nfs-storage
 mountPath: /exports
 env:
 - name: SHARED_DIRECTORY
 value: /exports
 - name: SHARED_DIRECTORY_2
 value: /exports/services

 # File Browser 컨테이너(선택)
 - name: file-browser
 image: filebrowser/filebrowser
 imagePullPolicy: Always
 ports:
 - containerPort: 8080
 protocol: TCP
 securityContext:
 runAsUser: 1000
 runAsGroup: 1000
 fsGroup: 1000
 volumeMounts:
 - name: nfs-storage
 mountPath: /database
 subPath: fb-database
 - name: nfs-storage
 mountPath: /srv
 subPath: services
 env:
 - name: FB_NOAUTH
 value: 'true'
 - name: FB_DATABASE
 value: /database/database.db
 - name: FB_PORT
 value: '8080'

 # SFTP 컨테이너(선택)
 - name: sftp-server
 image: jmcombs/sftp
 imagePullPolicy: Always
 command:
 - sh
 - -c
 - |
 chmod o+w /home/sftpuser/data
 /entrypoint sftpuser::::data
 ports:
 - containerPort: 22
 protocol: TCP
 volumeMounts:
 - name: ssh-keys
 mountPath: /home/sftpuser/.ssh/keys
 readOnly: true
 - name: nfs-storage
 mountPath: /home/sftpuser/data
 subPath: services

 volumes:
 - name: nfs-storage
 persistentVolumeClaim:
 claimName: nfs-pvc
 - name: ssh-keys
 configMap:
 name: nfs-system-sftp-config

컨테이너별 역할

NFS 서버: Alpine 기반 NFS 서버로 /exports 디렉토리 공유
File Browser: 웹 기반 파일 관리 인터페이스 제공 (선택)
SFTP 서버: SSH 키 기반 파일 전송 서비스 (선택)

FileBrowser Ingress 구성 (선택)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: nfs-ingress
 namespace: nfs-system
 annotations:
 nginx.ingress.kubernetes.io/backend-protocol: HTTP
 nginx.ingress.kubernetes.io/rewrite-target: /
spec:
 ingressClassName: nginx
 rules:
 - host: files.example.com # 소유한 도메인으로 변경 
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: nfs-service
 port:
 number: 8080

k8s 리소스 배포

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 네임스페이스 생성
kubectl apply -f namespace.yaml

# ConfigMap 생성
kubectl apply -f configmap.yaml

# PersistentVolume 생성
kubectl apply -f persistentvolume.yaml

# PersistentVolumeClaim 생성
kubectl apply -f persistentvolumeclaim.yaml

# Service 생성
kubectl apply -f service.yaml

# Deployment 생성
kubectl apply -f deployment.yaml

# Ingress 생성 (선택)
kubectl apply -f ingress.yaml

Helm

Helm 저장소 추가

1
2


helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm repo update

NFS Subdir External Provisioner Values 파일

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


nfs:
 # NFS 서버 서비스 주소
 # 위 k8s manifest에서 생성한 nfs service의 k8s service dns를 사용했다.
 server: 'nfs-service.nfs-system.svc.cluster.local'
 path: '/services' # 공유 경로

# StorageClass 설정
storageClass:
 # StorageClass 이름은 본인이 원하는대로 사용하면 된다
 storageClassName: 'nfs-client'

 accessModes: 'ReadWriteMany'
 # PVC 할당 시 Storage에 저장 될 경로 패턴을 의미한다.
 # 예시의 경우 ./pvc/<네임스페이스 명>/<PVC 명>으로 저장된다.
 pathPattern: '.pvc/${.PVC.namespace}/${.PVC.name}'

보다 구체적인 Values 설정은 다음의 링크를 참조하길 바란다.

Helm Chart 배포

1
2
3
4
5
6
7
8


helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
 --namespace nfs-system \
 --values values.yaml \
 --wait

# 설치 상태 확인
helm list -n nfs-system
helm status nfs-subdir-external-provisioner -n nfs-system

검증 및 테스트

리소스 상태 확인

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Pod 상태 확인
kubectl get pods -n nfs-system

# Service 확인
kubectl get svc -n nfs-system

# PVC 상태 확인
kubectl get pvc -n nfs-system

# StorageClass 확인
kubectl get storageclass

마치며

이제 다른 네임스페이스에서 PVC를 생성해보자.

FileBrowser와 ingress까지 설정했다면 웹상으로 접근해서 확인할 수 있다.

ingress가 별도로 없다면 다음 명령어로 포트포워딩해서 localhost:8080으로 접근해보자.

1

kubectl port-forward --address localhost -n nfs-system svc/nfs-service 8080:8080

PVC가 지정된 경로 (.pvc/namespace/pvc-name)에 생성됨을 알 수 있다.

추후 계획

현재 k8s 클러스터에 Vault가 배포되어 있는데, Node의 수가 2개뿐이라 HA (High-Availability) 구성이 안 되고 있다. (최소 3개 이상 필요)

NFS Provisioner는 외부에 존재하는 NFS Storage를 사용할 수도 있으므로, NAS용 컴퓨터 한 대를 구매해서 NFS 서버를 구축한 뒤 NFS Provisioner의 Source로 활용할 예정이다.

이는 또 다른 클러스터인 On-Premise에도 적용될 예정이다. On-Premise 클러스터는 Longhorn을 설치해서 PVC를 제공하고 있는데, 이래저래 마음에 안 드는 구석이 많아 심플하게 외부 NAS로 통합하려고 한다.

Longhorn에 대해서는 조만간 포스팅할 예정이다.

Oracle Cloud Infrastructure

Fri, 03 Oct 2025 00:00:00 +0900

연관 포스트

Nfs subdir external provisioner

OCI Block Volume 최소 크기 제한사항 해결

KaaS (Kubernetes as a Service)

정의

Kubernetes를 클라우드에서 관리형 서비스로 제공하는 모델이다.

특징

컨테이너화된 애플리케이션의 배포, 확장, 관리 등의 업무를 간소화
웹 콘솔, Terraform 등을 통해 k8s 클러스터를 자동화된 방식으로 구축 가능
클라우드와 통합된 StorageClass, LoadBalancer 제공

예시

가장 대표적인 Public Cloud Provider인 AWS, Azure, GCP에서는 다음과 같은 KaaS를 제공한다.

항목	AWS EKS	Azure AKS	Google GKE
지원 버전	1.16.8 (2020년 5월)	1.18.1, 1.18.2 (2019년 5월)	1.16.8 (2020년 4월)
업데이트	Master 및 Node 자동 업데이트	Master 및 Node 온디맨드 업그레이드	Master CLI 업그레이드, Node 수동 업데이트
CLI 지원	지원	지원	지원
리소스 모니터링	Stackdriver	Azure Monitor	타사 도구만 지원
Node 자동 확장	지원	프리뷰 단계	지원
Node 그룹	지원	미지원	지원
고가용성	지원	개발 중	지원
베어메탈 Node	미지원	미지원	AWS 제공
Master 업데이트	자동 수행	수동 수행	수동 수행
Node 업그레이드	자동 수행	수동 수행	관리형/비관리형 그룹
On-Premise	AWS Outposts	지원	Anthos GKE

Oracle Cloud Infrastructure

Oracle Cloud Infrastructure(이하 OCI)는 Oracle에서 운영하는 Cloud Provider이다.
AWS, Azure 등과 마찬가지로 OCI 역시 Oracle Kubernetes Engine(이하 OKE)라는 KaaS를 제공한다.

Oracle을 선택한 이유

OCI 자체는 다른 Cloud Provider들에 비해 특별한 장점이 있는 것은 아니다.
하지만 개인적으로 Cloud에 k8s를 구성하길 희망한다면, 그에 부합하는 한 가지 커다란 이점이 있다.

Oracle에는 무려 상시 무료 서비스가 존재한다!

클러스터 하나를 운영하기에는 부족함이 없다.

AWS를 무료로 사용할 수 있는 기간은 1년이 한계이고, 그마저도 EKS는 포함되지도 않는다.
EKS로는 Node 하나 없이 깡통 클러스터만 만들어 놔도 시간당 $0.1씩 과금된다.

환율 1,400원 기준으로 계산하면 한 달에 무려 10만원씩 나간다!

회사 차원에서 도입을 고려하는 경우라면, 이 정도 비용 격차는 그다지 큰 메리트는 아닐 것이다.
오히려 후술한 단점들을 생각한다면 AWS나 Azure를 선택하는 것이 훨씬 합리적이다.

하지만 개인 용도 + 학습을 목표로 하는 나와 같은 입장의 방문자가 있다면 썩 괜찮은 선택지이다.

단점

레퍼런스 부족: 어디서 정보를 찾기가 너무 힘들다. 대부분의 개발자들은 그 존재조차 모르는 것 같다.
부실한 공식 문서: 그럼 공식 문서라도 깔끔하게 되어있어야 하는데 그것도 아니다.

AWS에 익숙해져서 그런 것도 있겠지만, OCI의 공식 문서는 객관적으로 봐도 가독성이 매우 떨어진다.

공식 문서 사이트 링크가 있으니 궁금한 사람은 부디 들어가서 탐험 해보길 바란다.

OCI Always Free 제한사항

OCI Free Tier 페이지에도 나와있는데, 모든 서비스가 무제한으로 사용 가능한 건 당연히 아니다.
클러스터 1개를 운영한다고 가정하고, k8s에서 가용 가능한 자원을 간단하게 요약하면 다음과 같다.

자원 유형	제한사항
Node	Arm 기반 Ampere A1 코어 4개, 24GB 메모리
Persistent Volume	200GB
Load Balancer	Flexible Network Load Balancer 1개

Node의 경우 Node 1개당 최소 1개의 코어는 필요하므로 최대 사용 가능한 Arm Node 수는 4개이다.
AMD Node도 있긴 한데, 사이즈가 너무 작아서 여기선 무시한다.

OKE로 만드는 클러스터는 1개까지 무료로 사용 가능하다.
OKE는 KaaS이기 때문에 별도로 Control-Plane Node가 필요 없다.

따라서 4개의 Arm Node는 모두 Worker Node로 쓸 수 있다! 그것도 공짜로! _{아마존, 보고 있나?}

목표

OCI Free Tier에 제한된 리소스 안에서 k8s 클러스터를 자체적으로 운영
추가 비용 X
On-Premise 클러스터와 함께 멀티 클러스터 구성

On-Premise k8s에 Metallb 설치

Mon, 29 Sep 2025 00:00:00 +0900

들어가기 앞서

회사와 무관하게 개인적으로 관리하는 k8s 클러스터는 다음과 같다.
- 클라우드: OKE(EKS/GKE와 유사)처럼 기본 L4/L7 Load Balancer 제공
- 온프레미스: 집에서 운영하는 싱글 노드로 시작한 k8s, 리소스 집약적 워크로드 배치(Jellyfin, 7 Days To Die, Ollama, QBittorrent 등)
Jellyfin같은 앱은 클라우드에 설치하기엔 자원 소모량이 너무 크다.
- 내부망 대역: 93.5.22.0/24
- 초기 Worker Node: 93.5.22.44
- 공유기 포트포워딩: 외부 80/443 → 93.5.22.44:80/443, 클러스터 내 Nginx Ingress Controller가 도메인 기반 라우팅
로드밸런서란?
- 트래픽을 여러 노드/파드로 분산하고, 가상 IP(VIP)를 통해 단일 진입점을 제공
- 하드웨어 전용 장비도 있으나, 온프레미스 k8s에서는 소프트웨어 방식이 일반적
- Bare Metal 환경에서는 Metallb가 사실상 표준 솔루션
Metallb 핵심 개념
- 데몬셋 speaker가 호스트 네트워크로 동작하며 외부 IP를 네트워크에 광고
- LoadBalancer 서비스의 External IP 전파에 표준 프로토콜 사용: ARP(IPv4), NDP(IPv6), BGP
- 두 가지 모드
  - L2(ARP/NDP): 같은 서브넷에서 VIP를 광고 — 가정/소규모 환경에 적합
  - BGP: 라우터와 경로를 교환 — 데이터센터/고급 네트워크에 적합
- 관련 개념
  - GARP(Gratuitous ARP): 자신의 IP-MAC 정보를 네트워크에 알리는 ARP, VIP 전환 시 필수
  - Strict ARP: 노드가 소유하지 않은 IP에 응답하지 않도록 제한, L2 모드와 IPVS에서 안전성 향상

문제의 시작

초기에는 단일 노드(93.5.22.44)로 포워딩하면 충분했지만, 노드가 추가되면 단일 대상 포워딩만으로는 고가용성/확장성 확보 불가
이런 상황이라면 공유기는 대체 어느 Node로 포워딩을 해야하는가?
Kubernetes의 LoadBalancer 타입이 클라우드 밖에서는 기본 제공되지 않아, 외부에서 접근 가능한 VIP가 부재
결과적으로, 인입 트래픽을 안정적으로 받아 서비스로 라우팅할 수 있는 소프트웨어 로드밸런서가 필요

해결방안 — Metallb(L2 모드) 도입

같은 서브넷(93.5.22.0/24)에서 VIP를 광고하는 L2 모드로 간단하게 시작
예시 VIP: 93.5.22.100 (공유기 포트포워딩은 이 VIP로 설정)

설치(Helm)

1
2
3
4


helm repo add metallb https://metallb.github.io/metallb
helm repo update
kubectl create namespace metallb-system
helm upgrade --install metallb metallb/metallb -n metallb-system --wait

설치 후 CRD 확인:

1

kubectl get crd | grep metallb.io

다음과 같이 출력되면 정상이다.

1
2
3
4
5
6
7
8


bfdprofiles.metallb.io 2025-08-03T16:07:22Z
bgpadvertisements.metallb.io 2025-08-03T16:07:22Z
bgppeers.metallb.io 2025-08-03T16:07:22Z
communities.metallb.io 2025-08-03T16:07:22Z
ipaddresspools.metallb.io 2025-08-03T16:07:22Z
l2advertisements.metallb.io 2025-08-03T16:07:22Z
servicebgpstatuses.metallb.io 2025-08-03T16:07:22Z
servicel2statuses.metallb.io 2025-08-03T16:07:22Z

이중 IPAddressPool과 L2Advertisement CRD를 Manifest로 생성 해줘야 한다.
- IPAddressPool: Metallb이 할당할 수 있는 IP 주소(VIP) 풀이다.
- L2Advertisement: Layer2 광고 정의. L2 모드에서 Metallb이 IP 주소를 어떻게 광고하는가를 설정한다.

IP 풀/광고 리소스 생성

ipaddresspool.yaml:

1
2
3
4
5
6
7
8


apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
 name: workstation-ip-pool
 namespace: metallb-system
spec:
 addresses:
 - 93.5.22.100

Note: addresses는 범위로 지정할 수도 있다. 예를들면 192.168.0.100-192.168.0.104

적용:

1

kubectl apply -f ipaddresspool.yaml

l2advertisement.yaml:

1
2
3
4
5
6
7
8


apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
 name: workstation-l2adv
 namespace: metallb-system
spec:
 ipAddressPools:
 - workstation-ip-pool

적용:

1

kubectl apply -f l2advertisement.yaml

동작 확인 체크리스트

1
2
3
4
5
6
7
8


# 컨트롤러/스피커 파드 상태
kubectl get pods -n metallb-system -o wide

# 풀/광고 리소스 상태
kubectl get ipaddresspools.metallb.io,l2advertisements.metallb.io -n metallb-system

# LoadBalancer 서비스의 외부 IP 할당 여부
kubectl get svc -A | grep LoadBalancer || true

공유기 포트포워딩

외부 80/443 → VIP 93.5.22.100:80/443로 설정

참고(안전한 네트워킹을 위해)

Strict ARP를 활성화하면, 노드가 소유하지 않은 IP에 응답하지 않아 ARP 오류를 방지
kube-proxy IPVS 모드 사용 시에도 Strict ARP는 중요
BGP 모드는 외부 라우터와의 동적 라우팅이 필요할 때 선택
추가로 Nginx Ingress Controller가 VIP로 들어온 요청을 각 서비스로 라우팅하도록 설정했다

마무리

온프레미스 k8s에서 Metallb는 외부 트래픽을 받는 가장 간단하고 표준적인 방법이다. 같은 서브넷에서는 L2 모드만으로도 VIP를 안전하게 광고하여, 노드 수가 늘어나도 일관된 진입점을 유지할 수 있다.

ApexCaptain.IaC

Sun, 28 Sep 2025 18:05:00 +0900

GitHub

주요 목표

멀티 클러스터: OCI OKE(클라우드) + Workstation microk8s(온프레미스)
GitOps 파이프라인: ArgoCD 중심의 선언적 배포 자동화
보안·신뢰: Bastion, OAuth2 Proxy, Cert-Manager, Vault 중심 시크릿·인증 체계
관찰성: Prometheus + Grafana 모니터링 스택
개인 미디어 인프라: Jellyfin, qBittorrent, 게임 서버 등

아키텍처 개요

네트워크(OCI): VCN + Public/Private/DB Subnet, LB/Bastion, K8s 노드, 데이터 계층
클러스터 계층
- OKE(클라우드): System(NS)에 Istio, ArgoCD(개발 중), Vault(개발 중), 모니터링(개발 중), Ingress
- Workstation(microk8s): System(NS)에 Istio/모니터링/Longhorn, Application(NS)에 Dev/Media/Game/File 서비스

현재 성과(핵심)

인프라 자동화
- OKE 및 Workstation 클러스터 구성 정의, 선택적 스택 배포/병렬화, 상태 백업 스크립트 제공
보안/신뢰
- Bastion 접근 제어, OAuth2 Proxy, Cert-Manager 자동 인증서 발급
- Vault 기반 시크릿 관리 체계 설계계
운영 효율
- Prometheus/Grafana 관찰성 스택 구성, 로그 중앙화 계획
- 개인 미디어/유틸 서비스(Jellyfin, qBittorrent, SFTP, 7 Days to Die)
개발 생산성
- src/terraform/stacks 중심 스택화 구조, scripts/ 내 배포 선택/백업/터미널 도구
- Projen, ESLint/Prettier, Yarn 워크플로우 정착

진행 현황(요약)

OKE 클러스터 자동 프로비저닝
Workstation microk8s 클러스터
Istio 서비스 메시
ArgoCD(GitOps)
Vault(시크릿)
Prometheus/Grafana(모니터링)
Bastion/인증·인증서(Cert-Manager, OAuth2 Proxy)
미디어/게임/SFTP 서비스