덕규의 아즈카반

KCD x Ceph x OpenInfra Korea Day 2026

frontheadlock — Tue, 1 Sep 2026 22:18:06 +0900

KCD x Ceph x OpenInfra Korea Day 2026에 다녀왔습니다.

AI는 더 이상 특별한 기술이 아닌, 인프라 생태계의 기저에 깔리는 전제 조건이 되었습니다.

어플리케이션 레이어 뿐만 아니라 kubernetes, storage , GPU 스케줄링 등 모든 주제에 AI가 들어가 있었습니다.

분산 스토리지/CPU/GPU 등 하드웨어를 운영하면서도 AI가 도입되고,

거의 모든 회사가 AIOps를 통한 운영 자동화를 도입하고 있었습니다.

앞으로는 AI 도입 여부보다 이걸 어떻게 더 잘 활용하는 지에 대한 고민이 필요한 시대인 것 같습니다.

행사에서는 다양한 연사자 분들이 나오셔서,

각자의 전문 분야에 대해서 겪으셨던 문제와 이를 어떻게 해결했는 지 등을 공유했습니다.

특히 인상 깊었던 부분은 Naver 하현님의 세션이었습니다.

위 세션에서는 Multi-Cluster 환경에서 발생 가능한 자원 파편화를 해결 과정을 공유해주셨습니다.

최근 HW 자원의 가격이 기하급수적으로 오르며,

네이버처럼 초대규모 수준의 회사라면 운영하는 스토리지의 수와 보장해야하는 신뢰성이 중요하다보니,

멀티 클러스터를 구축할 경우 늘어나는 비용을 쉽게 감당하기는 어려운 상황이 발생했습니다.

그렇기에, 자원 파편화 상황에 대해 효율적인 대책이 필요해졌다 설명하셨습니다.

이 과정에서 노드 단위로 파편화 개선을 하게 될 경우,

유휴 클러스터의 노드를 떼내어 busy resource에 붙이면 replica가 깨지는 문제가 발생할 수 있습니다.

그렇기에 클러스터 구성의 최소 단위를 노드에서 디스크로 변경해 이를 해결한 것입니다.

또한 그렇게 구성을 하며 자체적으로 ceph 스토리지에 오케스트레이터 패턴을 구축했다는 점이 인상깊었습니다.

부족한 기술에 대해서는 그 위에 추가적인 기술 구현을 통해 문제를 해결해내는 점이 너무 멋있었습니다.

실제로 고수준의 엔지니어라면,

맞닥뜨리는 문제들에 대해 어떻게든 해결책을 찾아내고,

이를 기술적으로 개선해나갈 수 있어야 한다는 점을 알 수 있었습니다.

이번 행사에서 한가지 충격적이었던 것은 AI의 중요성으로 오히려 오픈소스의 중요성이 더 커진다는 점이었습니다.

오프닝에서 ASIA CNCF의 Director인 Horace Li 가 얘기한 AI 인프라의 성장이 폐쇄적으로 흘러갈 경우,

소수 플랫폼에 종속되고 우리에게 여러 문제를 일으킬 것이라는 점은 그동안 생각해지 못했었습니다.

CNCF에서 키워내는 다양한 오픈소스들이 성장하고, 사람들이 관심을 가지는 것이 얼마나 중요한 지 알 수 있었습니다.

기계처럼 AI를 소비만 하는 것이 아니라,

AI가 돌아가는 판에 대해 더 이해하고 더 미래를 바라볼 수 있는 눈을 키울 필요성을 깨달을 수 있었습니다..

HW 기본 원리

frontheadlock — Tue, 25 Aug 2026 22:37:43 +0900

컴퓨터 구성도

오늘날 컴퓨터는 폰 노이만 구조(Von Neumann Architecture) 를 따라 구성됩니다.
프로그램(명령어)과 데이터를 메모리에 저장하고,
CPU가 이를 순서대로 읽어 실행하는 구조를 가집니다.
이러한 구조로 인해 프로그램도 결국 데이터로 동작을 하며,
디스크에 저장되었다가 메모리에 올라가 실행되게 됩니다.

운영체제에 대해 얘기를 할 때, 가장 많이 나오는 예시인 주방에 비유하면 쉽습니다.
요리를 할 때는 창고에 있는 재료들로 바로 요리를 시작할 수는 없습니다.
재료들을 조리대로 가져와야 하고,
그 중에서도 자주 쓰이는 것은 손이 닿는 선반 위에 올려두며,
손에 쥔 재료들에 대해서만 실제로 썰고 볶아 요리를 할 수 있습니다.

CPU	명령어 실행·연산	요리사
레지스터	연산 직전/직후 값 보관	요리사의 양손
캐시 (L1~L3)	곧 쓸 데이터를 미리 근처에	조리대 위 선반
RAM (1차)	실행 중인 프로그램·데이터	주방 조리대
SSD/HDD (2차)	영구 보관	창고/냉장고

2차 메모리(창고) → 1차 메모리(조리대) → 캐시(선반) → 레지스터(손) → ALU(계산)

1. CPU

실행과 연산

CPU는 다른 말로 Machine (명령을 내릴 대상)이라고도 부릅니다.
CPU에 내려가는 명령들은 전기 신호로 입력되고,
CPU는 그러한 신호를 굉장히 빠른 속도로 처리하며 컴퓨터를 동작시킵니다.

여기서 용어 두 개를 구분할 수 있어야 합니다.

연산(operation): ALU가 수행하는 개별 계산 하나로, 덧셈, 비교 등이 각각 연산
실행(execution): 명령어들이 연속적·순차적으로 이어진 하나의 흐름

이러한 구분이 중요한 이유는, 실행이라는 흐름이 맥락을 만들기 때문입니다.
지금 어떤 명령을 실행 중이고, 레지스터에 어떤 값이 들어있는 지 등이 모여 맥락이 되고,
맥락들이 결국에는 실행의 단위가 됩니다.

운영체제에서 배우는 프로세스와 스레드가 바로 이러한 개념들로부터 비롯됩니다.

프로세스(Process): 실행 중인 프로그램. 독립된 메모리 공간(가상 주소 공간)을 가진다
쓰레드(Thread): 프로세스 안의 실행 흐름. 메모리는 공유하되 실행 맥락(레지스터·스택)은 별도
- 이벤트 루프 : 루프를 돌며 이벤트를 기다리며, 반응이 없어 보여도 죽은게 아니라 대기 중인 것
- 쓰레드가 죽으면 OS에서 알아서 거둬들임

CPU SPEC 조회

이러한 CPU에는 어떤 기능 들이 중요할까요?

예를 들어, CPU를 사고자 할 때 눈여겨 보는 사례에 대해서 알아 보겠습니다.
쇼핑몰에서 흔히 보는 AMD Ryzen / 8코어,16스레드 / 기본 3.8GHz / L2 8MB, L3 32MB

코어(Core)	물리 연산 장치 개수. 8코어 = 8개 실행 흐름을 물리적으로 동시 처리
스레드(Thread)	논리 프로세서 수. SMT(하이퍼스레딩)로 코어당 2개 → 8C/16T
기본/부스트 클럭	초당 동작 사이클 수. 3.8GHz = 초당 38억 사이클
L2 / L3 캐시	코어 전용(L2) / 코어 공유(L3) 캐시 용량
메모리 규격	지원 RAM 종류·속도 (DDR5-5600, 듀얼 채널 등)

클럭(Hz)의 의미
1Hz = 1초에 1번. 1kHz = 1,000번, 1GHz = 10억 번.
사이클마다 트랜지스터 스위치들이 on/off 상태를 바꾸며 연산이 한 단계씩 진행된다.
단, 클럭이 높다 ≠ 무조건 빠르다.

비트(bit)

컴퓨터가 다루는 가장 작은 정보 단위는 비트입니다.
1비트는 두 가지 상태를 표시하는 전기 스위치 1개로, 전류가 흐르면 1, 흐르지 않으면 0입니다.

32bit 신호란 이런 스위치 32개를 전자적 속도로 on/off 하는 것이고,
이 조작이 1초에 1000번 일어나면 1kHz입니다.

bit	0 또는 1	최소 단위
Byte	8 bit	메모리 주소 부여의 기본 단위, ASCII 문자 1개
KB / KiB	10³ / 2¹⁰ Byte	마케팅은 10진, OS는 2진 단위 혼용
Word	CPU가 한 번에 처리하는 크기	64bit CPU = 8 Byte

BitStream → Format → Protocol

비트가 쭉 나열된 것을 BitStream이라 부릅니다.
그런데, 비트 자체에는 아무 의미가 없습니다.
01001000이라는 비트열은 숫자 72일 수도, 문자 'H'일 수도, 기계어 명령의 일부일 수도 있습니다.

Format: 한 곳에 저장된 비트열에 해석 규칙(구조)을 부여한 것. 파일 / 파일 시스템 포맷.
Protocol: 두 주체 사이를 오가는 비트열의 규약. 네트워크로 가면 프로토콜

다만, 실제로 2진수를 활용하기에는 표기가 너무 길어지기에 16진수(hex)로 축약해 씁니다.
16진수 한 자리를 4비트에 대응시켜 변환을 빠르게 가져갈 수 있습니다.

2진수  1111 1111  =  16진수 FF  =  10진수 255
2진수  0100 1000  =  16진수 48  =  10진수 72  ('H'의 ASCII)

CPU가 실제로 읽고 실행하는 것은 기계어(machine code), 순수한 비트열입니다.

이를 사람이 읽기는 너무 어려워 만든 것이 어셈블리어입니다.

2. CPU의 연산 흐름

CPU 내부에서 연산은 아래와 같이 흘러갑니다.

구성 요소

ALU (Arithmetic Logic Unit): 산술·논리 연산을 실제 수행하는 핵심 회로.
레지스터(Register): CPU 내부의 초고속 저장 공간.
- 각 레지스터가 값을 하나씩 담고, 레지스터의 값들을 ALU가 연산합니다.
제어 장치(CU): 명령어를 해석(decode)하고 각 장치에 제어 신호를 보냅니다.

실행 절차

2차 메모리(SSD)에 저장된 실행 코드를 1차 메모리(RAM)에 Load
RAM에 로드된 실행 코드를 CPU가 Fetch.
이때 L1~L3 캐시에 다음에 쓰일 명령과 데이터가 미리 로드(pre-fetch).
가져온 데이터를 CPU 레지스터에 저장
레지스터 값에 대해 ALU가 연산, 결과를 레지스터에(필요 시 메모리에) 기록

실제로 컴퓨터가 동작할 때, 실행되는 스레드는 수백개지만 실행 가능한 Core는 n개입니다.
그래서 운영체제는 코어 위에서 실행 흐름을 빠르게 변경하며 실행합니다.
스레드의 레지스터 상태를 메모리에 저장해 두고,
다른 스레드의 상태를 레지스터에 복원해 이어돌립니다.
이러한 맥락이 바뀌는 이 과정을 컨텍스트 스위칭이라고 합니다.

하드웨어

메인보드에 CPU는 어떻게 올라가게 될까요?

CPU는 메인보드에 있는 소켓이란 칸 위에 올라가 그 안에서 동작합니다.
이러한 소켓에는 PGA, LGA, BGA 등의 종류가 있습니다.

PGA : CPU에 핀 부착
LGA : 소켓에 핀 부착
BGA : 납땜되어 출고

1개의 Socket 내에는 1개의 CPU를 꽂을 수도,
여러 개의 CPU를 꽂아 넣을 수도 있습니다.
서버의 성능이 높아질 수록 CPU 코어 수가 계속 늘어나게 되고,
여러 CPU를 꽂기 위해 패키지 안에 들어가는 소켓의 수도 늘어나게 됩니다.

여기서, 패키지를 통해 분리된 CPU 간의 원활한 통신을 위해서 NUMA 아키텍처를 사용합니다.

CPU는 기본적으로 RAM으로부터 데이터를 읽어와 작업을 진행합니다.
여러 개의 CPU가 존재하는 상황에서,
몇몇 CPU가 메모리를 선점유 시 남은 CPU가 유휴 상태에 빠지게 될 수 있습니다.
이러한 병목을 방지하고자 나온 아키텍처 구조로,
소켓 옆에 DIMM을 분리해 꽂아 메모리를 고루 할당합니다.

NUMA의 경우는, 말하면 이야기가 길어져 추후에 별도로 작성해보겠습니다..

3. 메모리 계층

기억장치 계층

기억장치들은 위로 갈수록 빠르고, 작고, 비싸고, CPU에 가깝습니다.
반면 , 아래로 갈수록 느리고, 크고, 싸고, 비휘발성이 됩니다.

레지스터 ~ Cache Memory : CPU 내부
RAM : 메모리 (컴퓨터 내부)
HDD , SSD : 외부 저장소 (External Storage)

작업 지연시간을 근사치로 표현하면 다음과 같이 확인할 수 있습니다.

레지스터 접근	~0.3 ns
L1 캐시 히트	~1 ns
L2 캐시 히트	~4 ns
L3 캐시 히트	~15 ns
RAM 접근	~100 ns
HDD 탐색	~5–10 ms

각 저장 계층의 데이터들은 항상 인접 계층 사이로 이동합니다.

2차 메모리 → 1차 메모리 → 캐시 → 레지스터 순으로 올라와 작업이 실행됩니다.

아래로 갈 수록 다녀오는 비용이 커지기 때문에 이동하는 데이터들의 단위가 달라지게 됩니다.

디스크 ↔ RAM: 블록/페이지 (4KB)
RAM ↔ 캐시: 캐시 라인 (64B)
캐시 ↔ 레지스터: 워드 (8B)

Cache Memory

저장장치의 계층적 구조를 통해 CPU가 연산을 하기 위해서는,

SSD에서 정보를 가져와 RAM에 올리고, 그 정보를 CPU가 참조해서 연산함을 확인할 수 있었습니다.

그런데, CPU가 매 작업에 대해 RAM을 거쳐오기에는 RAM과 CPU의 작업 속도차이가 300배 이상 납니다.

이를 극복하고자 나온 것이 Cache Memory 입니다.

RAM보다 훨씬 빠른 SRAM을 CPU 안에 넣고, 사용할 명령어와 데이터를 미리 가져다 두는 것입니다.

이처럼 명령어 혹은 데이터를 prefetch 하여 RAM과 CPU 간의 속도 간극을 메우게 됩니다.

여기서, 얼마나 예측을 잘하는 지를 캐시 히트율이라고 합니다.

RAM에서 올라온 데이터와 명령어는 모두 L3로 들어오고, 각 코어가 필요로 하는 것이 L2 → L1로 분배된다.

L3 (전체 코어 공유, LLC): 가장 큰 캐시로 코어들 사이에 데이터가 오가는 접점
L2 (코어당, 통합형): 각 코어별로 해당되는 명령과 데이터를 구분 없이 함께 저장
L1 (코어당, 분리형): L1d(데이터)와 L1i(명령어)가 별도로 존재
- 명령어 인출과 데이터 접근을 동시에 하기 위함

2차 메모리

2차 메모리란 1차 메모리와 정확히 반대입니다.

저속이지만 비휘발성이라 전원이 꺼져도 데이터가 유지됩니다.

CPU는 2차 메모리를 직접 연산 대상이 아닌, 데이터의 저장 장치로 사용을 합ㄴ다.

HDD (기계식 저장 장치)

HDD는 자성 물질을 입힌 원판(플래터)을 회전시키고, 그 위를 헤드가 움직이며 읽고 쓰는 장치입니다.

플래터는 동심원 모양의 트랙으로, 트랙은 다시 섹터로 나뉩니다.

HDD는 기계식이기 때문에 전기로 동작하는 다른 장치들에 비해 느립니다.

탐색(seek): 헤드가 목표 트랙까지 물리적으로 이동 (밀리초 단위)
회전 지연: 원판이 돌아 원하는 섹터가 헤드 밑에 올 때까지 대기

헤드를 거의 움직이지 않는 순차 접근은 나쁘지 않게(~150MB/s) 해내지만,

헤드가 계속 이동해야 하는 랜덤 접근은 많이 느립니다.(~1MB/s 수준)

옛날 윈도우 컴퓨터에서 "조각 모음"을 돌리던 이유가 여기 있습니다.

파일 조각이 흩어지면 순차 읽기가 랜덤 읽기로 변해 버리므로, 조각을 모아 다시 순차로 만들어 주는 것입니다.

SSD (전자식 저장 장치)

SSD는 NAND 플래시 반도체 셀에 전하를 가둬 저장합니다.

움직이는 부품이 없으니 랜덤 접근도 빠르고 충격에 강하며 소음도 없습니다.

다만, SSD 내부는 생각보다 까다로운 제약 위에서 돌아갑니다.

페이지(4~16KB) 단위로 읽고 쓰지만, 삭제는 페이지 수백 개를 묶은 블록(수 MB) 단위만 가능
덮어쓰기 불가: 이미 쓰인 페이지는 수정할 수 없음

이를 다음과 같은 기술을 통해 가능하게 합니다.

FTL (Flash Translation Layer)	OS가 보는 논리 주소 ↔ 실제 물리 페이지 매핑 관리
Garbage Collection	무효 페이지가 쌓인 블록의 유효 데이터를 옮기고 블록을 지워 재활용
Wear Leveling	셀당 쓰기 수명(수천~수만 회)이 있어 마모를 고르게 분산
TRIM	삭제된 파일임을 알려 GC 보조

뿐만 아니라, SSD는 HDD와 다르게 중복 제거를 지원합니다.

엔터프라이즈 급의 SSD 스토리지 서버를 사용할 경우,

여러 명의 유저가 중복된 데이터를 저장할 때 이를 중복 처리합니다.

데이터 중복 제거를 지원하여 하나만 바라보게 함으로 저장 공간을 효율적으로 제공합니다.

인터페이스
- SATA : HDD 시절에 설계된 프로토콜로 직렬 전송 방식 지원
- NVMe : 플래시를 위해 새로 설계, PCIe 인터페이스를 통해 SSD의 성능 극대화

마무리

충격

사실 여태껏 DevOps 라는 직무에 대해 개발자들의 빌드/배포만 지원하면 된다고 생각했습니다.

그런데 실제로 업무를 하다보니 단순히 빌드 지원 뿐만 아니라,

개발자들의 개발 서버에 대해서도 관리를 하게되는 일이 생겼습니다.

서버가 느려졌다는 문의를 받았을 때,

뭘 어떻게 확인하고 개선해야 하는지 조차 모르는 제 자신을 보면서 답답함이 느껴졌습니다...

최근 'DevOps/SE 개발자를 위한 리눅스 커널 이야기'라는 책을 읽으며,

buff/cache가 차 있는지 , iowait이 튀는 지 안튀는 지 확인하는 것을 넘어서

문제가 생기는 환경에 따라서는 커널 수준에 대해서까지 확인하는 것도 DevOps 개발자의 영역임을 알았습니다.

더 나은 개발자가 되기 위해서 CS 기초 , 특히나 하드웨어의 영역에 대해서 미리 이해를 하고,

부족하다에서 멈추지 않고 문제를 차근차근 짚고 넘어가는 개발자가 되보고자 합니다.

사내에서 문제가 터졌을 때, 누군가에게는 의지될 수 있는 엔지니어가 되고싶습니다.

GenAI on EKS/K8s 인퍼런스 최적화(4)

frontheadlock — Wed, 12 Aug 2026 22:13:09 +0900

작업을 진행해오며 모델, 게이트웨이, 관측성을 갖춘 Agentic AI 플랫폼을 구축했습니다.

이번에는 이 플랫폼 위에,
"Loan Buddy" 라는 지능형 대출 처리 어플리케이션을 구축해보겠습니다.

이 과정에서 AI 에이전트가 복잡한 워크플로우를 어떻게 자동화하는지,
배포하고 추적하며 확인하겠습니다.

어플리케이션 목표

AI 어플리케이션 구축: 앞서 구축한 플랫폼 사용
지능형 에이전트 배포: 비즈니스 의사결정을 자동으로 수행
Model Context Protocol(MCP) 사용: 에이전트에 외부 도구와의 기능 제공
에이전트 워크플로우 추적: Langfuse를 활용한 관측성 확보
아키텍처: Kubernetes 위의 AI 에이전트 구조

아키텍처

이전에 만들어 놓은 플랫폼에 에이전트와 MCP 서버를 추가해 구축할 예정입니다.
플랫폼을 통해 모델 서빙과 라우팅, 추적을 진행하고,
에이전트와 MCP를 이용해 해야할 업무들을 자동화할 수 있습니다.

모든 AI 요청은 LiteLLM Gateway를 통해 처리
모든 에이전트 활동을 Langfuse로 추적
어플리케이션은 지금까지 학습한 패턴 그대로 EKS에 배포

사용하는 기술 스택은 다음과 같습니다.

AI Frameworks
- LangGraph: AI 에이전트를 위한 워크플로우 오케스트레이션
- LangChain: AI 애플리케이션 구축 기반
- Model Context Protocol: 도구 통합 표준
- Pydantic: 데이터 검증 및 직렬화
Platform Integration
- LiteLLM Gateway: 모든 AI 요청 라우팅
- Langfuse: 모든 에이전트 활동 추적
- Claude 4.5 Sonnet: AI 모델
Application Components
- Loan Processing Agent: 메인 워크플로우 오케스트레이터
- Address Validator: 주소 검증 MCP 서버
- Employment Checker: 고용 검증 MCP 서버
- Image Processor: 문서 분석 MCP 서버

John의 대출 신청

Loan Buddy는 다음과 같은 대출 신청서 이미지들을 처리할 예정입니다.

서류는 John Michael Doe 씨의 것으로,
개인정보와 고용 정보(Tech Solutions Inc, Software Engineer, 연봉 $75,000),
주소 정보(123 Main Street, 자가 4년 거주),
대출 조건($8,500, 36개월, 월 $275)을 가지고 있습니다.

은행의 대출 담당자가 이 서류를 사람 손으로 처리한다면 다음 작업이 필요합니다.

데이터 추출: 이름, 생년월일, SSN 등 신청서 항목 옮겨 적기
고용 확인: Tech Solutions Inc에 연락해 재직 여부 확인
소득 검증: 연봉 $75,000 (월 $6,250) 확인
주소 검증: 123 Main Street가 실재하는 주거용 주소인지 확인
안정성 평가: 거주 기간, 주택 소유, 근속 연수 기록
비율 계산: 대출액 대비 소득, 월 상환액 산출
결정: 모든 요소를 종합해 승인 또는 거부

이 모든 과정은 통상 2~3시간을 소모합니다.

Loan Buddy는 이 전체 프로세스를 자동화합니다.

신청서 읽기: 비전 LLM을 활용해 이미지에서 데이터 추출
정보 검증: 외부 서비스를 통해 주소·고용 확인
비즈니스 규칙 적용: 대출 한도, 소득 비율, 위험 평가
결정과 기록: 판단 근거를 Langfuse에 감사 추적으로 보존

이처럼 자동화 도구를 도입하여 기존 대비 처리 시간을 2~3시간에서 분 단위로 줄이고,
동일한 기준을 도입 및 모든 결정에 대한 근거를 남길 수 있습니다.

처리 구조

그렇다면 Loan Buddy는 이를 어떻게 처리할까요?

John의 신청서가 업로드되면 Loan Processing Agent(LangGraph) 가 이를 처음 맡습니다.

LangGraph를 활용해 Workflow를 Orchestrate 하여 LiteLLM으로 넘깁니다.
에이전트에 대한 모든 요청은 LiteLLM을 거쳐 Claude가 추론과 판단을 맡고,
주소 검증, 고용 확인, 이미지 처리를 각 MCP 서버가 담당합니다.

그리고 이 모든 과정을 Langfuse로 추적합니다.

구성요소

이 구조를 코드 레벨에서 하나씩 살펴보겠습니다.

LangGraph와 LangChain

LangGraph란?
LLM 기반 에이전트의 워크플로우를 그래프로 정의하고 실행하는 오케스트레이션 프레임워크.
상태 관리, 분기, 오류 처리, 도구 호출 루프를 담당합니다.
출처: LangChain Docs

AI 시스템의 프로젝트 관리자에 해당하는 역할입니다.

# 에이전트에서 LangGraph는 워크플로우를 생성합니다
from langgraph.prebuilt import create_react_agent

# 다음을 수행할 수 있는 에이전트를 생성:
# 1. 입력에 반응
# 2. 도구 사용 (MCP 서버)
# 3. 단계 간 상태 유지
# 4. 결정 내리기
graph = create_react_agent(model, tools, debug=True)

LangChain이란?
LLM 애플리케이션을 구성하는 빌딩 블록 프레임워크.
모델 연결, 도구 추상화, 메모리 관리, 프롬프트 템플릿을 제공합니다.
출처: LangChain Docs

LangChain이 구성요소를 제공하면, LangGraph가 이를 워크플로우로 엮는 관계입니다.

# LangChain이 플랫폼에 연결
from langchain_openai import ChatOpenAI

model = ChatOpenAI(
    model="bedrock/claude-4.5-sonnet",
    api_key=model_key,
    # 게이트웨이
    base_url="http://litellm.litellm.svc.cluster.local:4000"
)

여기서 base_url은 Bedrock이나 Anthropic의 엔드포인트가 아니라,
클러스터 내부의 LiteLLM 서비스 주소를 바라봅니다.

에이전트 입장에서는 OpenAI 호환 API 하나를 쓰고,
모델 라우팅과 비용 추적은 전부 게이트웨이가 처리하는 것입니다.

MCP 서버 3종

MCP(Model Context Protocol)란?
AI 모델이 외부 도구와 데이터 소스에 접근하는 방식을 표준화한 오픈 프로토콜.
도구를 MCP 서버로 만들어두면, 어떤 에이전트든 같은 방식으로 연결해 사용할 수 있습니다.
출처: modelcontextprotocol.io

각 MCP 서버는 한 가지 작업에만 전문성을 가지며, Loan Buddy는 3개의 MCP 서버를 사용합니다.

1. Image Processor MCP (신청서 이미지에서 구조화된 데이터 추출)

신청서 이미지 ID 수신
S3 스토리지에서 이미지 검색
Claude의 비전 기능으로 문서 읽기
구조화된 JSON 데이터 추출

이미지는 S3에 한 번 저장된 후 ID로만 참조됩니다.
모든 LLM 호출에 이미지를 다시 실어 보내지 않기에, 토큰 비용을 절약할 수 있습니다.

2. Address Validator MCP (주소 실재 여부와 위험도 평가)

주소 형식 및 우편번호 검증
주거용 여부 확인
사기 위험 지표 평가
소유 상태 검증
거주 기간 기반 안정성 점수 계산

3. Employment Validator MCP (고용 및 소득 주장 확인)

고용 상태 확인 (정규직 여부)
소득 정확성 검증 (연봉/월급 일치)
고용 기간 확인
고용 이력 기반 안정성 평가

오케스트레이터

이 모든 과정을 Loan Processing Agent가 지휘하며, 전체 워크플로우는 다음과 같습니다.

신청서 업로드부터 데이터 추출, 여러 검증을 거쳐 승인/거부 결정에 이릅니다.
순차적으로 이루어지고, 모든 단계를 Langfuse로 기록합니다.

이런 아키텍처 구성이 가지는 장점은 다음과 같습니다.

관심사 분리
- 각 MCP 서버는 한 가지 작업만 잘 수행
- 에이전트는 오케스트레이션만 하고 비즈니스 로직을 직접 구현하지 않음
- 인프라(라우팅, 추적)는 플랫폼 컴포넌트가 처리
확장성
- MCP 서버는 독립적으로 확장 가능
- 여러 에이전트가 동일한 MCP 서버를 공유 가능
유지보수성
- 에이전트를 건드리지 않고 MCP 서버의 비즈니스 규칙 업데이트
- 기존 코드 변경 없이 새로운 검증 도구 추가
비용 최적화
- 이미지는 한 번 처리되고 캐시됨
- 효율적인 토큰 사용 (모든 호출에 이미지를 싣지 않음)

어플리케이션 배포

배포에 앞서 플랫폼 컴포넌트가 실행 중인지 확인합니다.

# 플랫폼 구성요소 확인
kubectl get pods -n litellm
kubectl get pods -n langfuse

# LiteLLM 게이트웨이 접근 확인
echo "LiteLLM URL: http://$(kubectl get ingress -n litellm litellm -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')"

# Langfuse 접근 확인
echo "Langfuse URL: http://$(kubectl get ingress -n langfuse langfuse -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')"

배포에 필요한 구성

Loan Buddy가 동작하려면 다음 요소들이 연결되어야 합니다.

S3 Bucket: 업로드된 대출 문서 저장. Langfuse 배포 시 Terraform이 만든 버킷을 재사용
- terraform output langfuse_bucket_name
AWS Region: .env 파일의 REGION 값. S3 및 AWS 서비스 호출에 사용
LiteLLM API Key: Virtual Key(agent-key). 에이전트가 모델을 호출할 수 있게 함
Langfuse Credentials: 관측성을 위한 공개/비밀 키 쌍
Service Account + Pod Identity: Langfuse 서비스 계정을 workshop 네임스페이스로 복사
- Pod Identity Association 생성

Pod Identity Association을 사용하게 된다면,
Pod는 하드코딩된 자격 증명 없이 IAM 역할을 통해 S3에 접근합니다.

# 서비스 계정 복사
kubectl get serviceaccount langfuse -n langfuse -o yaml | \
  sed 's/namespace: langfuse/namespace: workshop/' | \
  kubectl apply -f -

# Pod Identity Association 생성
aws eks create-pod-identity-association \
  --cluster-name genai-on-eks \
  --namespace workshop \
  --service-account langfuse \
  --role-arn <IAM_ROLE_ARN>

자동 배포

이 모든 절차를 배포 스크립트 하나로 자동화했다면, 딸깍으로 끝납니다.

# credit validation 디렉토리로 이동
cd /workshop/workshops/eks-genai-workshop/static/code/module3/credit-validation

# 배포 스크립트 실행
chmod +x deploy-workshop-app.sh
./deploy-workshop-app.sh

스크립트는 앞서 정리한 구성을 순서대로 수행도록 구성됐습니다.

Terraform 출력에서 S3 버킷을 조회,
LiteLLM/Langfuse 키를 매니페스트에 주입,
네임스페이스와 서비스 계정, Pod Identity를 만들어,
어플리케이션을 배포합니다.

# 배포 예시
Loan Buddy Workshop Deployment

Step 1: Checking prerequisites...            ✅
Step 2: Retrieving S3 bucket name...         ✅ genai-on-eks-bucket-langfuse-xxxxx
Step 3: Getting AWS region...                ✅ us-west-2
Step 4: Getting LiteLLM API key...           ✅ sk-xxxxx...
Step 5: Getting Langfuse credentials...      ✅ lf_pk_xxxxx... / lf_sk_xxxxx...
Step 6: Creating workshop namespace...       ✅
Step 7: Setting up service account...        ✅ (+ Pod Identity Association)
Step 8: Configuring deployment file...       ✅
Step 9: Deploying Loan Buddy application...  ✅
Step 10: Waiting for deployments...          ✅

NAME                                     READY   STATUS    RESTARTS   AGE
loan-buddy-agent-xxx                     1/1     Running   0          1m
mcp-address-validator-xxx                1/1     Running   0          1m
mcp-employment-validator-xxx             1/1     Running   0          1m
mcp-image-processor-xxx                  1/1     Running   0          1m

에이전트 1개와 MCP 서버 3개, 총 4개의 Deployment가 올라갑니다.

동작 확인

배포한 어플리케이션을 이용해서 John의 신청서를 실제로 처리해보겠습니다.
example1.png 를 사용해 테스트를 진행해보겠습니다.

# 새 터미널에서 에이전트 로그 관찰
kubectl logs -f deployment/loan-buddy-agent -n workshop

# Loan Buddy 배포
kubectl port-forward service/loan-buddy-agent 8888:8080 -n workshop &

# 테스트 데이터 디렉토리로 이동
cd /workshop/workshops/eks-genai-workshop/static/code/module3/credit-validation/

# John Michael Doe의 대출 신청서 처리
curl -X POST -F "image_file=@./example1.png" \
  http://localhost:8888/api/process_credit_application_with_upload | jq

요청이 들어가면 로그에서 에이전트의 작업 흐름을 실시간으로 볼 수 있습니다.

  Starting credit application processing...
  Processing uploaded loan application image...
✅ Image stored in S3 with ID: a7b9c2d4e5f6...
  Loading MCP tools...
  Processing with agent...

[Agent]: I'll help you process this credit application.

[Image Processor MCP]: Extracting data from loan application...
Found: John Michael Doe, DOB: 03/15/1985, SSN: ***-**-7890
Income: $75,000, Employer: Tech Solutions Inc
Address: 123 Main Street, Anytown, CA 90210

[Address Validator MCP]: Checking 123 Main Street, Anytown, CA 90210
✅ Valid residential address - Owner occupied - 4 years
✅ Risk score: 15 (Low risk)

[Employment Validator MCP]: Verifying Tech Solutions Inc
✅ Employment confirmed - Software Engineer, $75,000, 3.5 years
✅ Stability score: 85 (High stability)

[Agent]: Calculating loan metrics...
- Loan amount: $8,500 / Monthly payment: $275
- Debt-to-income ratio: 4.4% (Excellent)

FINAL DECISION: ✅ APPROVED

워크플로우 순서도에 따라서,
이미지 추출 → 주소 검증 → 고용 확인 → 비율 계산 → 승인 결정이 차례로 실행됩니다.

만약 사람이 했다면 2~3시간 걸릴 검토가, 업로드 한 번으로 몇 분 안에 끝납니다.

Langfuse에서 에이전트 추적

이 실행은 Langfuse에도 그대로 기록되는데,
지금까지 봤던 단일 호출과는 다른 모양의 에이전트 트레이스가 찍힙니다.

단일 span이 아니라, 에이전트 실행 전체가 중첩된 트리형태로 기록됩니다.

최상위 트레이스 하위에 agent → call_model → 도구 호출이 계층으로 쌓이고
agent와 tools span이 번갈아 반복되며 ReAct 루프(추론 → 행동 → 관찰)가 시각화돼
각 단계의 지연시간과 LLM 호출별 토큰 사용량을 개별적으로 확인할 수 있습니다

지난 글에 잠시 등장한 애플리케이션 레이어(Langfuse SDK) 추적이 바로 이것입니다.

게이트웨이 레이어가 "LLM을 몇 번, 얼마에 불렀는가"를 보여준다면,
SDK 레이어는 "에이전트가 왜 호출을 했고, 어떤 도구를 거쳐 도달했는가"를 보여줍니다.

대출 심사처럼 근거가 중요한 도메인에서는,
이 추적 기록이 규정 준수에 대한 중요한 감사 자료가 됩니다.

마무리

Loan Buddy를 끝으로, 전체 워크샵을 진행할 수 있었습니다.

Phase 1 : 모델과 상호작용
- EKS Auto Mode 클러스터 위에 Open WebUI 배포
- AWS Neuron 칩에서 vLLM으로 Qwen 3 8B, DeepSeek R1 서빙
- Bedrock을 통한 Claude 4.5 Sonnet 통합, 자체 호스팅 vs 관리형 비교
Phase 2 : 플랫폼 컴포넌트
- LiteLLM 통합 게이트웨이 구성과 무중단 모델 추가
- Langfuse 관측성 스택과 게이트웨이/SDK 이중 추적
Phase 3 : 어플리케이션 구축
- LangGraph 에이전트와 MCP 서버 3종으로 Loan Buddy 구현
- Pod Identity 기반의 자격 증명 없는 S3 접근
- 에이전트 워크플로우의 완전한 추적

이번 모듈을 만들면서 가장 크게 느낀 것은,
에이전트 애플리케이션 코드가 생각보다 얇다는 점입니다.

이러한 과정을 거치며 에이전트를 활용하는 어플리케이션의 경우,
생각보다 코드가 그렇게 무겁지 않다는 것을 배울 수 있었습니다.

어플리케이션 내에서 모델 선택, 라우팅, 비용 집계, 추적 등을 하지 않다보니,
플랫폼으로 책임을 분산시켜 어플리케이션의 크기가 줄어드는 것 같습니다..

문서 처리, 고객 서비스 자동화, 모니터링 등 Loan Buddy와 같은 패턴을 적용할 수 있는 곳은 많습니다.

이번 워크샵에서 배운 플랫폼 우선 접근을 바탕으로,
실무에서도 작은 에이전트들을 도입해 볼 생각입니다.

참고로, 워크샵과 동일한 플랫폼을 직접 배포해볼 수 있는
AWS GenAI on EKS Starter Kit이 GitHub에 오픈소스로 공개되어 있습니다.

이 스타터 킷에는 llm-d라는 K8s 기반 분리형 LLM 서빙 프레임워크도 포함되어 있습니다.
제가 진행한 과정을 따라 진행해보고자 한다면, 깃허브에서 참고하시면 좋을 것 같습니다..

Gen AI on K8s/EKS 인퍼런스 최적화 (3)

frontheadlock — Sun, 9 Aug 2026 21:58:56 +0900

LiteLLM 게이트웨이를 구성하며,
모든 모델 요청이 한 지점을 지나가는 구조를 만들었습니다.

이번 글에서는 게이트웨이를 지나간 모든 대화를 추적하는 관측성 플랫폼에 대해 살펴보겠습니다.

Langfuse

Langfuse란?
Langfuse는 다음을 제공하는 오픈소스 LLM 관측성 플랫폼

포괄적인 추적: 전체 컨텍스트와 함께 캡처되는 모든 LLM 상호작용

비용 추적: 모든 모델에 걸친 토큰 사용량 및 비용

성능 분석: 지연시간, 처리량, 품질 지표

디버깅 도구: 상세한 요청/응답 검사

다중 데이터베이스 아키텍처: 확장을 위한 PostgreSQL + ClickHouse + Redis

출처: AWS Workshop

관측성 스택 탐색

먼저 Langfuse가 어떤 컴포넌트로 구성되어 있는지 확인합니다.

# 완전한 관측성 스택 확인
kubectl get all -n langfuse

langfuse-web: 대시보드 UI와 API를 담당하는 메인 어플리케이션
langfuse-worker: 수집된 이벤트를 비동기로 처리해 ClickHouse에 적재
langfuse-postgresql-0: 추적 메타데이터, 프로젝트, 사용자 정보 저장
langfuse-clickhouse-shard0-0: 대량의 트레이스 분석을 위한 컬럼형 데이터베이스
langfuse-zookeeper-0: ClickHouse 복제 코디네이터
langfuse-redis-primary-0: 큐잉과 캐싱 레이어

요청을 받아 대시보드 역할을 하는 역할(web)과,
트레이스를 소화해 분석 DB에 쌓는 역할(worker)이 나눠져 있습니다.

구성과 배포

실제 구성은 IDE에서 확인할 수 있습니다.

# Langfuse Helm values 확인
cat /workshop/components/o11y/langfuse/values.template.yaml

# 스택 구성 확인
grep -A 5 "postgresql:\|clickhouse:\|redis:" /workshop/components/o11y/langfuse/values.template.yaml

배포는 공식 Langfuse Helm Chart를 사용합니다.

# Langfuse Helm 레포지토리 추가
helm repo add langfuse https://langfuse.github.io/langfuse-k8s
helm repo update

# 커스텀 values로 Langfuse 배포
helm upgrade --install langfuse langfuse/langfuse \
  --namespace langfuse \
  --create-namespace \
  -f values.rendered.yaml

# 배포 상태 확인
kubectl rollout status deployment/langfuse-web -n langfuse

배포 과정에서 일어나는 일을 정리하면 다음과 같습니다.

템플릿 렌더링: values.template.yaml → values.rendered.yaml
Helm 설치: 렌더링된 values로 차트 배포
데이터베이스 초기화: PostgreSQL, ClickHouse, Redis 설정
프로젝트 설정: 조직 및 프로젝트 자동 생성, 워크샵 자격 증명으로 사용자 계정 생성
통합 준비: LiteLLM 연결을 위한 API 키 구성

4~5번을 거쳐, 접속하면 LiteLLM의 트레이스가 쌓이는 상태로 시작할 수 있습니다.

Langfuse 사용해보기

첫 접속

echo "Langfuse URL: http://$(kubectl get ingress -n langfuse langfuse -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')"

로그인하면 Organizations 화면이 먼저 나타납니다.

Provisioned Org와 Provisioned Project가 이미 만들어져 있습니다.

Go to project를 눌러 프로젝트로 들어갑니다.

홈 대시보드

Past 1 day 기준으로 다음이 집계되어 있습니다.

Traces: 4건 (중간에 DB 초기화 해서 일부 날아갔습니다..)
Model costs: $0.002727 — bedrock/openai.gpt-oss-20b-1:0, 20.17K 토큰
Scores: 0건 (아직 평가를 붙이지 않았으므로)

지난 글에서 LiteLLM Usage 탭으로 봤던 것과 같은 데이터가,
이번에는 모델별 비용과 시간대별 차트로 훨씬 자세하게 펼쳐집니다.

트레이스 목록

Tracing 메뉴에서는 개별 대화 기록을 볼 수 있습니다.

각 행에 타임스탬프, 입력/출력 미리보기, Latency, 토큰 수, 비용이 정리되어 있습니다.

트레이스 4건 중 실제로 질문을 한 것은, "Langfuse에 대해 설명해줘", "트레이스 분석하게 도와줘" 2건입니다.

나머지 2건은 Suggest 3-5 relevant follow-up questions...로 시작하는,
Open WebUI가 후속 질문 추천을 위해 자동으로 보내는 요청입니다.

채팅 한 번에 실제로는 LLM 호출이 두 번 나가고 있었던 것입니다.
관측성을 켜보면, UI가 뒤에서 조용히 보내던 요청까지 확인할 수 있던것입니다.

개별 트레이스 검사

목록에서 트레이스 하나를 클릭하면 상세 화면으로 들어갑니다.

Latency: 5.29초 (Time to first token 5.29초)
Total Cost: $0.0005
Token Usage: 5,575 프롬프트 → 367 완성 (총 5,942)
모델: bedrock/openai.gpt-oss-20b-1:0
파라미터: stream: false, max_retries: 0, aws_region_name: us-west-2

Preview 탭에는 요청 전문이 그대로 담겨 있는데, Chat History에 낯익은 대화가 보입니다.

지난 글에서 gpt-oss-20b를 테스트하며 물었던 "오늘 저녁 메뉴 추천 해줘" 를 볼 수 있습니다.

이 트레이스가 바로 그 대화에 대한 후속 질문 생성 요청이었던 것입니다.

프롬프트가 실제로 사용한 5,575 토큰에 대한 근거도 확인해볼 수도 있습니다.
후속 질문을 만들기 위한 직전 대화 전체가 컨텍스트로 다시 들어가기 때문입니다.

응답 몇 줄을 추천받자고 대화 전체를 다시 지불하는 셈이니,
이런 부가 기능의 비용도 관측성이 있어야 보입니다.

기본 제공 대시보드

Dashboards 메뉴에는 Langfuse가 관리하는 대시보드 4종이 기본 제공됩니다.

Langfuse Home: 프로젝트 홈에 표시되는 전체 개요
Langfuse Cost Dashboard: LLM 비용 리뷰
Langfuse Latency Dashboard: 트레이스/생성 단위 지연시간 모니터링
Langfuse Usage Management: 리소스 할당을 위한 사용량 추적

이 중 Cost Dashboard를 열어보겠습니다.

Total Count Traces 7 / Observations 10: 전체 기간 누적 집계
Cost by Model Name: bedrock/openai.gpt-oss-20b-1:0가 비용 대부분을 차지
Cost by Environment: default 환경에 전액($0.002727)이 몰린 도넛 차트
Top 20 Users / Use Cases by Cost: 사용자와 유스케이스 단위의 비용 분석 틀

위젯을 직접 추가해 커스텀 대시보드를 만들 수도 있지만,
기본 제공 대시보드만으로도 비용, 지연시간, 사용량 관점이 이미 갖춰져 있습니다.

고급 기능: LLM-as-a-Judge

Langfuse는 AI 모델을 심사자로 사용해 응답 품질을 자동 평가하는 기능도 지원합니다.

자동 채점: 응답의 품질, 정확성, 유용성을 모델이 평가
일관성 평가: 서로 다른 모델의 응답을 객관적으로 비교
품질 벤치마킹: 표준화된 지표로 시간 경과에 따른 개선 추적
지속적인 평가: 모든 상호작용을 자동으로 평가해 품질 패턴 파악

모델 비교, 프롬프트 최적화, 품질 저하 감지, A/B 테스트에 활용되며,
모듈 4에서 사용할 수 있습니다.

자세한 내용은 Langfuse LLM-as-a-Judge 문서를 참고하세요.

Langfuse 동작 원리

그렇다면 이 트레이스들은 어떻게 Langfuse까지 흘러온 걸까요?

LiteLLM은 모델 호출과 별개로 트레이스를 전송합니다.

사용자가 메시지를 보내면 Open WebUI가 LiteLLM에 API 요청
LiteLLM이 모델로 라우팅하면서 동시에 Langfuse에 Start trace
모델 응답이 돌아오면 Complete trace with metrics 전송
Langfuse는 프롬프트, 응답, 토큰, 비용, 지연시간을 저장

Open WebUI는 Langfuse의 존재를 전혀 모릅니다.
게이트웨이가 추적을 대신 해주기에, 어플리케이션 코드 변경이 없는 것입니다.

Langfuse로 트레이스를 보내는 경로는 이 방법 하나만이 아닙니다.

통합 작동 방식

LiteLLM Callbacks	게이트웨이를 통과하는 모든 LLM 요청을 자동 추적. 어플리케이션 코드 변경 불필요
Langfuse SDK	어플리케이션 코드에 CallbackHandler를 직접 삽입해, 에이전트 워크플로우와 도구 호출 수준까지 추적
OpenTelemetry	표준 OTEL 프로토콜로 Langfuse의 OTEL 호환 엔드포인트에 전송. 다국어 환경이나 기존 OTEL 계측에 유용

이 중 두 레이어를 함께 사용합니다.

게이트웨이 레이어 (LiteLLM Callbacks): 모든 LLM 호출의 토큰, 비용, 지연시간 캡처
어플리케이션 레이어 (Langfuse SDK): 에이전트 워크플로우, 도구 호출, 의사결정 체인 캡처

낮은 수준의 모델 성능과 높은 수준의 어플리케이션 동작을,
하나의 Langfuse 대시보드에서 모두 볼 수 있게 되는 구조입니다.

마무리

이번 작업으로, 플랫폼의 관측성 레이어를 완성할 수 있었습니다.

모델별 응답 시간과 비용이 상호작용 단위로 집계되고,
UI가 뒤에서 보내는 자동 요청까지 포함해 모든 호출을 기록합니다.

관측성 모델을 통해 채팅 한 번이 LLM 호출 두 번이 되고,
그 부가 호출이 대화 전체를 컨텍스트로 다시 소비한다는 사실을 알 수도 있었습니다.

또한, 기능을 추가할 때마다 토큰 비용이 어디서 새는지 알 수도 있었습니다.

이제 LiteLLM(게이트웨이)과 Langfuse(관측성)를 모두 갖추며,
EKS 위의 Agentic AI 플랫폼 기반을 완성했습니다.

다음 모듈에서는 이 기반 위에서 LangChain과 LangGraph를 사용해,
도구 호출과 메모리를 갖춘 실제 에이전트 어플리케이션을 구축해보겠습니다.

GenAI on K8s/EKS 인퍼런스 최적화 (2)

frontheadlock — Tue, 4 Aug 2026 22:35:16 +0900

지난 글에서는 EKS 위에 배포된 개별 모델들과 직접 상호작용해보았습니다.

이어서, 개별 컴포넌트들이 어떻게 하나의 플랫폼으로 통합되는지 정리해보겠습니다.

이번에는 LiteLLM을 통합 API 게이트웨이로,
Langfuse를 관측성 플랫폼으로 연결해,
Agentic AI 어플리케이션을 지탱하는 인프라를 완성합니다.

오늘은 LiteLLM을 중점적으로 다루고, Langfuse는 다음 글에서 이어가겠습니다.

아키텍처

Open WebUI의 모든 요청은 API Gateway Layer의 LiteLLM을 지나,
vLLM 또는 AWS Bedrock으로 라우팅됩니다.

이 과정에서 발생하는 모든 Trace가 Langfuse로 흘러가고,
Langfuse는 이를 PostgreSQL, ClickHouse, Redis에 저장합니다.

이러한 아키텍처는 Helm 차트를 사용하여 실제 배포 패턴에 중점을 둡니다.

동적 구성: Helm 템플릿이 유연한 배포를 가능하게 하는 방법
자동 통합: 컴포넌트가 서로를 발견하고 연결하는 방법
확장 가능한 패턴: 리소스 관리, Ingress 및 보안 이해
실습: 새 모델 추가와 관측성 기능 탐색

LiteLLM

LiteLLM이란?

LiteLLM은 다음을 제공하는 오픈소스 프록시

통합 API: 모든 모델을 위한 단일 OpenAI 호환 엔드포인트

스마트 라우팅: 적절한 백엔드로 요청을 자동으로 라우팅

영구 스토리지: 구성을 위한 PostgreSQL, 캐싱을 위한 Redis

로드 밸런싱: 여러 모델 레플리카 간에 요청 분산

출처: AWS Workshop

LiteLLM 스택 구성

LiteLLM은 단일 Pod가 아니라, 세 개의 컴포넌트로 구성된 스택입니다.

LiteLLM Pod: 모든 모델 요청을 라우팅하는 API 게이트웨이 본체
PostgreSQL: 모델 구성, 사용 데이터, Virtual Key 등 저장
Redis: 응답 캐싱을 통한 응답 시간 개선

지난 글에서 kubectl get svc로 확인했던 litellm 네임스페이스의
litellm, litellm-postgresql, litellm-redis 서비스가 바로 이 구성입니다.

모델 구성 확인

먼저 실행 중인 vLLM 모델을 확인하고,
LiteLLM이 이 모델들을 어떻게 바라보는지 구성 파일에서 살펴봅니다.

# 실행 중인 vLLM 모델 확인
kubectl get pods -n vllm -l app

# LiteLLM의 모델 구성 확인
grep -A 16 "model_list:" /workshop/components/ai-gateway/litellm/values.rendered.yaml

# LiteLLM
model_list:
  # Bedrock 모델 (AWS 구성에서)
  - model_name: bedrock/claude-4.5-sonnet
    litellm_params:
      model: bedrock/global.anthropic.claude-sonnet-4-5-20250929-v1:0
      aws_region_name: us-west-2

  # vLLM 모델 (실행 중인 Pod에서 자동 발견)
  - model_name: vllm/qwen3-8b-neuron
    litellm_params:
      model: openai/qwen3-8b-neuron
      api_key: fake-key
      api_base: http://qwen3-8b-neuron.vllm:8000/v1
  - model_name: vllm/deepseek-r1-qwen3-8b-neuron
    litellm_params:
      model: openai/deepseek-r1-qwen3-8b-neuron
      api_key: fake-key
      api_base: http://deepseek-r1-qwen3-8b-neuron.vllm:8000/v1

api_base: vLLM Service의 클러스터 내부 DNS를 그대로 사용
api_key: fake-key: vLLM 엔드포인트에는 별도 인증이 없어 Mock 사용
model: openai/...: vLLM이 OpenAI 호환 API를 제공

모델 자동 발견

이러한 구성 파일은 직접 작성하지 않고,
배포 시점에 실행 중인 모델을 스캔해 자동으로 렌더링됩니다.

# 통합 발견 로직 확인
grep -A 15 "integration.*llm-model" /workshop/components/ai-gateway/litellm/index.mjs

// LiteLLM의 모델 발견 프로세스
for (const model of value.models) {
  if (model.deploy) {
    // 모델 Pod가 실제로 실행 중인지 확인
    const result = await kubectl get pod -n ${namespace} -l app=${model.name}
    if (result.stdout.includes(model.name)) {
      // 모델을 찾아 통합에 추가
      integration["llm-model"][namespace][model.name] = true;
    }
  }
}

프로세스를 정리하면 다음과 같습니다.

스캔: 실행 중인 모델 Pod를 Kubernetes에서 탐색
검증: 각 모델이 정상적으로 사용 가능한지 확인
빌드: 발견된 모델로 통합 객체 생성
렌더링: 사용 가능한 모델만으로 Helm 템플릿 렌더링
배포: 해당 모델 구성으로 LiteLLM 배포

이 덕분에 LiteLLM은 실제로 실행 중인 모델만 바라보도록 구성되어,
고아 모델이 model_list에 남아 라우팅을 혼잡스러게 하지 않습니다.

LiteLLM 배포

배포에는 커스텀 values 템플릿과 공식 LiteLLM Helm Chart를 사용합니다.

# 렌더링된 values로 공식 차트 배포
helm upgrade --install litellm oci://ghcr.io/berriai/litellm-helm \
  --namespace litellm \
  --create-namespace \
  -f /workshop/components/ai-gateway/litellm/values.rendered.yaml

동작 시퀀스

배포된 LiteLLM의 요청 처리 흐름은 다음과 같습니다.

사용자가 모델을 선택하고 메시지를 전송
Open WebUI가 LiteLLM에 POST /v1/chat/completions 호출
선택된 모델에 따라 vLLM 엔드포인트 또는 Bedrock API로 분기
어느 쪽이든 동일한 응답 형식(Unified response format) 으로 반환

백엔드가 무엇이든 응답 형식이 같기에,
클라이언트는 모델이 어디서 서빙되는지 전혀 신경 쓸 필요가 없습니다.

LiteLLM 웹 인터페이스 탐색

이제 LiteLLM 관리 인터페이스에서 모델과 지표를 확인하고, API를 테스트해보겠습니다.

1. LiteLLM 접속

echo "LiteLLM URL: http://$(kubectl get ingress -n litellm litellm -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')"

ALB 주소로 접속하면 먼저 Swagger 기반의 API 문서가 나타납니다.

"Proxy Server to call 100+ LLMs in the OpenAI format"라는 소개 문구처럼,
모델 관리부터 채팅까지 모든 기능이 OpenAI 형식의 REST API로 노출되어 있습니다.

상단 링크는 각각의 페이지로 이동시켜 다양한 대시보드를 제공합니다.

/ui: 관리 패널 (Admin Panel)
LiteLLM Model Cost Map: 모델별 비용 단가표
Model Hub: 사용 가능한 모델 확인

2. 모델 대시보드

관리 패널의 Models + Endpoints 메뉴로 이동하면, 구성된 모델을 확인할 수 있습니다.

Show results: values.rendered.yaml의 model_list와 동일한 3개 모델이 등록
LiteLLM이 OpenAI 호환 API를 통해 제공하기에 Provier가 openai
Costs 열은 bedrock/claude-4.5-sonnet에만 할당

3. 사용량 및 비용 모니터링

Usage 탭에서는 게이트웨이를 지나간 모든 요청의 지표를 볼 수 있습니다.

Total Requests 18 / Successful 17 / Failed 1: 실패한 요청까지 그대로 집계
Total Tokens 19,701: 워크샵 기간 사용한 토큰 총량
Total Spend $0.0008: 단가가 등록된 Bedrock 호출분만 계산된 금액

지난 글의 대화들이 전부 이 지표에 쌓여 있습니다.

4. Playground에서 모델 테스트

Playground에서는 대화형 인터페이스로 모델 응답을 바로 테스트할 수 있습니다.

TTFT 1.86s, Total Latency 10.73s, In 22 / Out 696 토큰
요청 단위의 성능 지표가 함께 표시되어, 모델별 응답 성능을 비교하기에 좋습니다.

Bedrock 모델 추가

이제 게이트웨이의 편리함은 이제 시작입니다.
어플리케이션 코드 변경 없이, 구성 변경만으로 새 모델을 추가해보겠습니다.

# 액세스 권한이 있는 Bedrock 모델 확인
aws bedrock list-foundation-models \
  --query "modelSummaries[?contains(modelId, 'gpt-oss')].{ModelId:modelId,ModelName:modelName}" \
  --output table

# 구성 파일에 모델 추가 (components/ai-gateway/litellm/values.rendered.yaml)
model_list:
  - model_name: bedrock/gpt-oss-20b
    litellm_params:
      model: bedrock/openai.gpt-oss-20b-1:0
      aws_region_name: us-west-2

# 업데이트된 구성 적용
helm upgrade litellm oci://ghcr.io/berriai/litellm-helm \
  --namespace litellm \
  -f /workshop/components/ai-gateway/litellm/values.rendered.yaml

# 배포 완료 대기
kubectl rollout status deployment/litellm -n litellm

돌아가면, bedrock/gpt-oss-20b가 드롭다운에 새로 등록되어 있습니다.

바로 "오늘 저녁 메뉴 추천 해줘"라고 물어보니,
4초 동안 생각한 뒤 한식 메뉴와 디저트를 표로 정리해줍니다.
~~(밥 줘)~~

여기서 중요한 점은, Open WebUI를 한 번도 건드리지 않았다는 것입니다.
values 수정과 helm upgrade로, 서비스 중단 없이 스택 전체에 전파되었습니다.

Virtual Key 생성

이후 모듈에서 만들 에이전트가 모델들에 접근하려면 전용 API 키가 필요합니다.
LiteLLM은 이를 Virtual Key로 해결합니다.

Virtual Key란?

LiteLLM 프록시가 발급하고 관리하는 가상 API 키.
AWS 자격 증명 같은 실제 제공자 키를 노출하지 않으면서,
키 단위로 접근 가능한 모델, 예산, 속도 제한, 사용량 추적을 관리할 수 있습니다.

출처: LiteLLM Docs

관리 패널의 Virtual Keys 메뉴에 처음 들어가면 키가 하나도 없습니다.

+ Create New Key를 누르면 키 생성 폼이 나타납니다.

Owned By: You (기본값)
Team: 선택하지 않음 (선택 사항)
Key Name: agent-key
Models: 사용 가능한 모든 모델 선택
- bedrock/claude-4.5-sonnet
- bedrock/gpt-oss-20b
- vllm/qwen3-8b-neuron
- vllm/deepseek-r1-qwen3-8b-neuron
Key Type: Default

Create Key를 클릭하면 sk-로 시작하는 키가 발급됩니다.

키 전문은 이 화면에서 단 한 번만 표시되므로, 복사해서 안전한 곳에 보관합니다.

Key 동작 검증

발급받은 키가 실제로 동작하는지 Playground에서 검증합니다.

Virtual Key Source를 Current UI에서 Virtual Key로 변경하고,
발급받은 키를 붙여넣은 뒤 테스트 메시지를 보냅니다.

이후, 모델(claude-4.5-sonnet)이 정상적으로 응답하는 것을 확인할 수 있습니다.

이 키는 이후 모듈에서 LangGraph 에이전트가 모델에 접근할 때 그대로 사용됩니다.

마무리

이번 실습을 통해 통합 AI 게이트웨이가 주는 이점을 직접 확인할 수 있었습니다.

원활한 모델 전환: 애플리케이션 변경 없이 모든 모델 간 전환
자동 발견: 실행 중인 모델만 스캔해 구성에 반영
무중단 모델 추가: values 수정과 helm upgrade만으로 새 모델 전파
내장 관측성: 요청, 토큰, 비용이 게이트웨이 한 곳에 집계
접근 제어: Virtual Key로 모델 접근과 사용량을 키 단위로 관리

모델 종류에 상관없이, 클라이언트 입장에서는 전부 같은 OpenAI 호환 API입니다.
덕분에 모델 추가, 비용 집계, 키 관리가 전부 LiteLLM 한 곳에서 해결됩니다.

다음 글에서는 이 게이트웨이를 지나간 모든 상호작용을 추적하는
관측성 플랫폼, Langfuse를 살펴보겠습니다.

GenAI on K8s/EKS 인퍼런스 최적화

frontheadlock — Sun, 2 Aug 2026 01:40:08 +0900

최근 OSSAI 활동을 통해, GenAI On EKS에 대해 교육받을 수 있는 기회가 생겼습니다.

교육 기간 중 Amazon EKS 기반의 Agentic AI 플랫폼 설계 및 배포와 관련하여,
AWS로부터 핸즈온 가능한 플랫폼을 제공받아 직접 작업해볼 수 있었습니다.

이번 핸즈온의 목표는,
LLM 배포부터 지능형 어플리케이션 구축까지 AI 플랫폼을 구축하는 것이었습니다.

핸즈온 환경

Agentic AI 플랫폼: EKS Auto Mode
LLM: AQwen 3 8B와 DeepSeek R1 Qwen 3 8B(Neuron Chip), Amazon Bedrock (Claude)
최신 AI 패턴: 관측성, 비용 추적, 확장성
프레임워크: LangChain, LangGraph, Model Context Protocol(MCP)

워크샵 구성

워크샵은 총 5개의 모듈로 구성되어 있습니다.

1. 모델과 상호작용

다양한 배포 패턴을 통해 LLM과 상호작용하며 시작합니다.

Open WebUI: 모델 상호작용을 위한 ChatGPT 유사 인터페이스 배포
vLLM on AWS Neuron: Neuron 위에서 Qwen 3 8B와 DeepSeek R1 Qwen 3 8B 호스팅
AWS Bedrock: Bedrock을 통해 Claude 4.5 Sonnet 연결

2. Agentic AI 플랫폼 컴포넌트

개별 컴포넌트를 통합 플랫폼으로 전환합니다.

LiteLLM Gateway: 모든 모델을 위한 통합 API 생성
Langfuse Observability: 모든 토큰, 비용, 상호작용 추적
Platform Integration: 컴포넌트들을 원활하게 연결

3. Agentic AI 애플리케이션 구축

최신 프레임워크를 사용해 챗봇을 넘어선 지능형 에이전트를 만듭니다.

LangChain & LangGraph: 체인, 에이전트, 워크플로우 구축
Model Context Protocol: MCP 서버로 외부 도구 및 API 통합
Loan Buddy Agent: LangGraph 기반의 대출 처리 애플리케이션 구축
Secure and Observe: 에이전트 플로우를 플랫폼 컴포넌트와 통합

4. 플랫폼 확장 및 평가

플랫폼이 대규모에서도 품질을 유지하도록 만듭니다.

LLM-as-a-Judge: Langfuse로 에이전트 출력 품질 자동 평가
A/B Model Routing: LiteLLM의 가중치 기반 트래픽 분할로 모델 비교
AMP/AMG Monitoring: Prometheus / Grafana로 대시보드 구축
Auto-Scaling: HPA와 Karpenter를 통한 탄력적 추론 용량 확보

5. 프로덕션 준비

엔터프라이즈 요구사항에 맞춰 에이전트를 프로덕션 수준으로 끌어올립니다.

RAG with Milvus: 정책 인식 결정을 위한 벡터 데이터베이스
Ragas Evaluation: RAG 품질 측정 (충실도, 관련성, 정확도)
Security Hardening: Pod Identity, External Secrets, Bedrock Guardrails
Streaming Responses: 더 나은 UX를 위한 실시간 SSE 출력

이번 글에서는 워크샵 환경 구성과 모듈 1(모델과 상호작용)까지를 정리하고,
이후 모듈은 다음 글에서 이어서 다뤄보겠습니다.

아키텍처

워크샵에서 구축하는 플랫폼의 전체 아키텍처는 다음과 같습니다.

사용자는 Open WebUI로 대화하고,
모든 요청은 LiteLLM 게이트웨이를 거쳐 vLLM 또는 Bedrock으로 라우팅됩니다.
그리고 이 과정 전체가 Langfuse로 추적됩니다.

어떤 모델을 쓰든 요청이 반드시 게이트웨이 한 곳을 지나가도록 만든 구조 덕분에,
비용 추적과 관측성, 모델 교체가 전부 이 지점에서 해결됩니다.

Agentic AI에 EKS가 유용한 이유

Scalability
- AI 워크로드 수요에 따른 오토스케일링
- 특수 하드웨어 지원 (GPU, Neuron)
- 분산 추론 및 다중 모델 배포 패턴
Flexibility
- 자체 호스팅 오픈소스 모델과 관리형 클라우드 서비스 통합
- 하이브리드 배포 패턴, 커스텀 최적화 전략
Operations
- Langfuse를 통한 포괄적인 관측성
- Helm을 통한 자동화된 라이프사이클 관리
- 비용 최적화 및 추적, 보안 모범 사례

워크샵 환경

시작하기

EKS를 무료로...!

AWS에서 핸즈온용 플랫폼을 제공해주어, 비용 부담 없이 개발 가능한 환경을 제공받았습니다.

Workshop Studio에 액세스하면 위와 같이,
브라우저에서 바로 열리는 Visual Studio Code 기반의 IDE가 주어집니다.

workshop 폴더에는 components, terraform 등 실습에 사용할 코드가 미리 담겨 있고,
하단 터미널은 participant 계정으로 EKS 클러스터와 AWS CLI에 바로 연결되어 있습니다.

사전에 구성된 EKS 클러스터와 임시 자격 증명이 포함되어 있기에,
별도 설정 없이 바로 kubectl을 사용할 수 있었습니다.

워크샵의 주제는 어디까지나 Agentic AI인 만큼,
애플리케이션을 구축하고 배포하기 이전의 기반 인프라는 모두 사전 구성되어 제공되었습니다.

EKS Auto Mode

워크샵 환경에는 완전히 작동하는 Amazon EKS 클러스터가 포함되어 있고,
이 클러스터는 EKS Auto Mode로 구성되어 있습니다.

EKS Auto Mode는 컴퓨팅, 스토리지, 네트워킹 리소스 관리의 운영 오버헤드를 제거하는
완전 관리형 Kubernetes 경험을 제공합니다.

자동 컴퓨팅 프로비저닝: EC2 인스턴스를 수동으로 생성하거나 관리할 필요 없음
동적 확장: 워크로드 수요에 따라 용량을 자동으로 조정
패치 관리: OS 및 Kubernetes 컴포넌트 자동 업데이트
비용 최적화: 지능형 인스턴스 선택 및 Spot 인스턴스 통합

터미널에서 클러스터를 조회해보면 다음과 같습니다.

조회된 노드가 모두 Ready 상태인데, COMPUTE-TYPE 레이블이 전부 auto입니다.
제가 직접 만든 노드가 하나도 없이,

Auto Mode로 워크로드에 맞춰 알아서 프로비저닝되었습니다.

클러스터 노드 구성

노드풀과 스토리지를 조회해보면 클러스터의 구성이 한눈에 들어옵니다.

여기서 재미있는 부분이 노드풀별 노드 수입니다.

일반적으로 AI는 gpu 환경 위에서 동작을 하는데,

neuron 노드풀에만 노드 2개가 떠있고, gpu 노드풀은 0개입니다.

노드풀 정의는 되어 있지만, GPU 워크로드가 없는 동안에는 비싼 노드를 하나도 유지하지 않습니다.

StorageClass로는 ebs(기본)와 efs가 준비되어 있고,

huggingface-cache, neuron-cache라는 100Gi EFS 볼륨 2개가 바인딩되어 있습니다.

이 두 캐시는 뒤의 vLLM 섹션에서 다시 등장합니다.

클러스터는 워크로드 성격에 따라 세 종류의 노드로 나뉘어 있습니다

General Purpose Nodes (Multi-Architecture)

Instance Types: 최신 세대 컴퓨팅(C), 메모리(M), 범용(R) 최적화 인스턴스
- AWS Graviton (ARM64): 비슷한 x86 대비 최대 40% 향상된 가격 대비 성능
- x86 (AMD/Intel): 기존 x86 아키텍처 인스턴스
Architecture Support: 워크로드 호환성에 따라 자동 선택되는 멀티 아키텍처 (amd64/arm64)
Purpose: 일반 워크로드, 웹 서비스, 컨트롤 플레인 컴포넌트 실행
Scaling: Karpenter가 Pod 요구사항에 따라 비용이 효율적인 인스턴스를 자동 선택, 낮은 노드는 통합

GPU-Accelerated Nodes

Instance Types: NVIDIA GPU (g5, g6, p4, p5 패밀리)
Purpose: GPU 집약적 AI/ML 워크로드 실행
Features: CUDA 지원, GPU 오퍼레이터 사전 설치

AWS Neuron Nodes

Instance Types: inf2, trn1, trn2 인스턴스
Purpose: 대규모 언어 모델을 위한 최적화된 추론
Benefits:
- GPU 대비 추론당 최대 50% 낮은 비용
- 최적 성능을 위한 사전 컴파일 모델
- 네이티브 int8 양자화 지원

스토리지 구성

클러스터는 영구 스토리지로 Amazon EFS(Elastic File System)를 사용합니다.

Shared Storage: 여러 Pod가 동시에 읽기/쓰기 가능
Elastic Throughput Mode: 워크로드에 따라 성능을 자동으로 확장
Model Caching: 빠른 배포를 위해 사전 다운로드된 모델을 EFS에 저장
Cross-AZ Availability: 여러 가용 영역에 걸친 고가용성

사전 설치된 Agentic AI 스택

Agentic AI 애플리케이션을 바로 구축할 수 있도록, 주요 컴포넌트들이 미리 배포되어 있습니다.

서비스를 조회해보면 스택 전체가 실제로 떠 있는 것을 확인할 수 있습니다.

langfuse 관측이 많죠?

각 컴포넌트의 역할은 다음과 같습니다.

Open WebUI

대규모 언어 모델과 상호작용하기 위한 웹 인터페이스입니다.

Features: 채팅 인터페이스, 대화 기록, 모델 전환
Integration: LiteLLM 게이트웨이와 연동되도록 사전 구성

LiteLLM

여러 LLM 제공자에 대한 단일 인터페이스를 제공하는 통합 API 게이트웨이입니다.

Purpose: 서로 다른 모델 제공자 간 API 호출 표준화
Supported Models: vLLM, AWS Bedrock, OpenAI 호환 엔드포인트
Load Balancing: 사용 가능한 모델 전반에 요청을 자동 분산

Langfuse

LLM 애플리케이션을 위한 포괄적인 관측성 플랫폼입니다.

Monitoring: 토큰 사용량, 지연시간, 비용 추적
Debugging: 전체 스택을 관통하는 개별 요청 추적
Analytics: 모델 성능 및 사용자 상호작용 분석

vLLM

대규모 언어 모델을 위한 고성능 추론 엔진입니다.

Pre-loaded Models: Qwen 3 8B, DeepSeek R1 Qwen 3 8B (Neuron)
Optimization: Continuous Batching, PagedAttention, Tensor Parallelism
Hardware Acceleration: AWS Neuron 칩에 최적화

모듈 1. 모델과 상호작용

모듈 1에서 다루는 구성요소들은 다음과 같이 연결됩니다.
Open WebUI가 LiteLLM 통합 API를 바라보고, LiteLLM이 세 개의 모델에 요청을 나눠줍니다.

Open WebUI

Open WebUI는 원래 Ollama WebUI라는 이름으로 시작한 오픈소스 프로젝트로,
다음과 같은 기능을 제공합니다.

최신 채팅 인터페이스: ChatGPT와 유사한 깔끔하고 반응형 디자인
다중 모델 지원: 여러 모델 간 원활한 전환
대화 관리: 채팅 기록 저장, 정리 및 검색
파일 업로드: 문서 및 이미지 지원 (모델이 지원하는 경우)
프롬프트 템플릿: 자주 쓰는 작업을 위한 사전 구성 프롬프트
다중 사용자 지원: 개인화된 설정을 가진 개별 계정

워크샵에서 사용된 Helm values는 다음과 같습니다.

# Open WebUI Helm values
nameOverride: openwebui

# ALB Ingress 구성
ingress:
  enabled: true
  annotations:
    alb.ingress.kubernetes.io/target-type: ip
    {{#if DOMAIN}}
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    {{/if}}
  host: openwebui.{{{DOMAIN}}}

# LiteLLM API 게이트웨이 연결 (클러스터 내부 주소 사용)
openaiBaseApiUrl: http://litellm.litellm:4000/v1

extraEnvVars:
  - name: OPENAI_API_KEY
    value: {{{LITELLM_API_KEY}}}
  - name: WEBUI_ADMIN_EMAIL
    value: {{{OPENWEBUI_ADMIN_EMAIL}}}
  - name: WEBUI_ADMIN_PASSWORD
    value: {{{OPENWEBUI_ADMIN_PASSWORD}}}

# 로컬 Ollama 비활성화 (외부 모델 사용)
ollama:
  enabled: false
pipelines:
  enabled: false

# 대화를 위한 영구 스토리지
persistence:
  enabled: true
  size: 100Gi

# 리소스 할당
resources:
  requests:
    cpu: 1
    memory: 2Gi
  limits:
    memory: 2Gi

1. LiteLLM 통합

Open WebUI는 모델 엔드포인트에 직접 연결하는 대신 LiteLLM에 연결합니다.

통합 API: 모든 모델에 대한 단일 엔드포인트
로드 밸런싱: 모델 레플리카 간 자동 분산
Fallback 지원: 모델 간 원활한 전환

LiteLLM은 AI 게이트웨이 역할을 하며,
모든 모델에 대해 통합된 OpenAI 호환 인터페이스를 제공합니다.
LiteLLM 자체는 모듈 2에서 자세히 다루겠습니다.

2. AWS Load Balancer 통합

Ingress 구성은 Application Load Balancer(ALB)를 생성합니다.

HTTPS Termination: SSL/TLS를 로드 밸런서에서 처리
Target Type IP: 더 나은 성능을 위한 직접 Pod 네트워킹
커스텀 도메인: https://openwebui.${DOMAIN}으로 접근 가능

3. 영구 스토리지

100Gi의 EBS 스토리지가 다음을 보장합니다.

대화 기록: 모든 채팅이 보존됨
사용자 설정: 세션 간 설정 유지
안정적인 성능: 애플리케이션의 일관된 I/O 성능

EKS Auto Mode는 StorageClass만 정의하면 PVC에 대한 EBS 자동 프로비저닝
수동 CSI 드라이버 설치와 노드 구성이 필요 없다는 점이 편리했습니다.

배포와 접속

인프라 설정 중에 실행된 배포 프로세스는 다음과 같습니다.

# Helm 레포지토리 추가
helm repo add open-webui https://open-webui.github.io/helm-charts
helm repo update

# 커스텀 구성으로 Open WebUI 설치
helm upgrade --install openwebui open-webui/open-webui \
  --namespace openwebui \
  --create-namespace \
  -f values.rendered.yaml

# Open WebUI URL 확인
echo "Open WebUI URL: http://$(kubectl get ingress -n openwebui openwebui -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')"

# 생성된 관리자 계정 조회 후 로그인
helm get values openwebui -n openwebui

발급된 ALB 주소로 접속해 로그인하면, 모델 선택 드롭다운이 표시됩니다.

드롭다운에는 qwen3-8b, deepseek-r1, 그리고 bedrock이 나타납니다.

EKS에서 직접 서빙 중인 모델과 Bedrock의 관리형 모델이
하나의 UI에서 완전히 같은 방식으로 노출되는 것인데, 이것이 LiteLLM 게이트웨이의 효과입니다.

다만 bedrock/claude-4.5-sonnet은 EKS에서 호스팅되는 것이 아니라,
LiteLLM을 거쳐 Bedrock API로 라우팅됩니다.

Open WebUI는 Agentic AI 스택에서 다음과 같이 통합되어 사용됩니다.

vLLM 모델이면 클러스터 내부 Pod로, Bedrock 모델이면 AWS API로 분기하지만,
사용자 입장에서는 어떤 백엔드든 동일한 요청과 응답 형태를 갖습니다.

vLLM: 자체 호스팅 모델 서빙

그렇다면 이러한 GenAI 모델들은 Kubernetes에서 실제로 어떻게 실행되고 있을까요?

실행 중인 모델은 다음과 같이 탐색할 수 있습니다.

# 현재 실행 중인 vLLM 모델 확인
kubectl get pods -n vllm

# 채팅 경험 뒤의 실제 Deployment 확인
kubectl get deployments -n vllm -o wide

# 모델을 호스팅하는 노드 확인
kubectl get pods -n vllm -o wide

# vLLM 구성 디렉터리 확인
ls /workshop/components/llm-model/vllm/

# 방금 사용한 Qwen 3 배포 살펴보기
cat /workshop/components/llm-model/vllm/model-qwen3-8b-neuron.rendered.yaml

# DeepSeek 배포와 비교
cat /workshop/components/llm-model/vllm/model-deepseek-r1-qwen3-8b-neuron.rendered.yaml

실제로 조회해보면 다음과 같습니다.

방금까지 채팅하던 두 모델이 각각 1/1 Running 상태의 Pod로 돌아가고 있습니다.

채팅 한 번의 요청 흐름은 다음과 같습니다.

메시지 입력 → Open WebUI → LiteLLM → vLLM Pod
Pod가 AWS Neuron 하드웨어에서 요청 처리
응답이 동일한 경로를 역으로 거쳐 브라우저에 도착

vLLM이란?

LLM을 고속으로 추론하기 위한 효율적 엔진으로, 서빙 환경에서 높은 처리량과 낮은 지연 시간이 목표
출처: SKT Enterprise

vLLM은 다음과 같은 기능을 제공합니다.

높은 처리량: 여러 요청을 효율적으로 서빙하도록 최적화
Continuous Batching: 최적의 하드웨어 활용을 위한 동적 요청 배칭
PagedAttention: 긴 컨텍스트를 위한 효율적인 메모리 관리
Tensor Parallelism: 여러 가속기에 모델 분산
OpenAI 호환 API: OpenAI API의 드롭인 대체

그럼 이러한 모델은 요청을 받았을 때 실제로 어떻게 동작할까요?

마침 치킨을 시켰던 터라, 치킨을 주제로 모델의 동작 과정을 살펴보았습니다.

Open WebUI에서 DeepSeek 모델에게
"교촌 치킨이랑 처갓집 양념치킨 중에 어떤 게 더 맛있어? 근거를 수치 기반으로 제공해줘."라고 물어봤습니다.
~~(선택장애..)~~

교촌이 이겼습니다

그러고는 가격 대비 맛 만족도부터 성분 라벨 비교까지, 수치를 들어가며 제법 진지하게 비교해줍니다.
~~(둘 다 처음 보는 메뉴인데?)~~

이 질문에 답하는 동안 vLLM Pod의 로그를 실시간으로 지켜보면 다음과 같습니다.

participant:/workshop$ kubectl logs -f --tail=0 -n vllm deployment/deepseek-r1-qwen3-8b-neuron
(APIServer pid=1) INFO:     10.0.45.96:60236 - "POST /v1/chat/completions HTTP/1.1" 200 OK
INFO 08-01 13:16:36 [metrics.py:398] Avg prompt throughput: 4.2 tokens/s, Avg generation throughput: 0.1 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.
INFO 08-01 13:16:41 [metrics.py:398] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 17.8 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.
INFO 08-01 13:16:46 [metrics.py:398] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 18.2 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.
...(약 2분간 18 tokens/s 내외로 토큰 생성)...
INFO 08-01 13:18:22 [metrics.py:398] Avg prompt throughput: 301.5 tokens/s, Avg generation throughput: 11.9 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.
(APIServer pid=1) INFO:     10.0.45.96:60236 - "POST /v1/chat/completions HTTP/1.1" 200 OK
INFO 08-01 13:18:57 [metrics.py:398] Avg prompt throughput: 343.0 tokens/s, Avg generation throughput: 11.6 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.
INFO 08-01 13:19:02 [metrics.py:398] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 18.2 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.

....

이 로그에서 볼 수 있는 것은 다음과 같습니다.

요청 수신: POST /v1/chat/completions로 프롬프트가 도착
모델 처리 중: 토큰 생성 및 처리 지표가 5초 단위로 갱신
성능 통계: 처리량, 실행 중인 요청 수, KV 캐시 사용률

주목할 주요 지표는 다음과 같습니다.

Prompt throughput
- 평소에는 0, 요청이 들어와 프롬프트를 읽는 순간 300 tokens/s 이상으로 튀어 오릅니다.
Generation throughput
- 응답을 생성하는 동안 약 18 tokens/s로 일정하게 유지됩니다.
KV cache usage
- GPU KV cache가 0인 이유는, GPU가 아닌 Neuron 위에서 실행되고 있기 때문입니다.

AWS Neuron 배포 구성

AWS Neuron은 AWS Inferentia(inf2) 및 Trainium(trn1) 칩을 위한 SDK입니다.

비용 효율성: GPU 대비 추론당 최대 50% 낮은 비용
LLM 최적화: 트랜스포머 아키텍처에 대한 기본 지원
Quantization: 메모리 사용을 줄이기 위한 INT8 및 FP8 지원
컴파일: 최적의 성능을 위한 사전 컴파일 모델

vLLM 배포는 네임스페이스, 스토리지, 시크릿, Deployment, Service로 구성됩니다.

# Namespace 격리
apiVersion: v1
kind: Namespace
metadata:
  name: vllm

스토리지: 두 개의 캐시

Amazon EFS를 사용해 다운로드한 모델과 컴파일된 Neuron 그래프를 캐시합니다.

# pvc-huggingface-cache.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: huggingface-cache
  namespace: vllm
spec:
  storageClassName: efs
  accessModes:
    - ReadWriteMany  # 여러 Pod가 읽기/쓰기 가능
  resources:
    requests:
      storage: 100Gi
---
# pvc-neuron-cache.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: neuron-cache
  namespace: vllm
spec:
  storageClassName: efs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi

앞서 클러스터 구성에서 kubectl get pv로 확인했던 100Gi EFS 볼륨 2개가 바로 이 캐시들입니다.

캐시를 두 개로 나눠 사용하는 이유는 다음과 같습니다.

HuggingFace 캐시: 다운로드한 모델 가중치 저장
Neuron 캐시: 컴파일된 모델 그래프 저장
재사용성: 캐시된 데이터는 Pod 재시작 후에도 유지되어, 재배포가 훨씬 빨라짐

시크릿: HuggingFace 토큰

# secret.template.yaml
apiVersion: v1
kind: Secret
metadata:
  name: hf-token
  namespace: vllm
type: Opaque
stringData:
  token: ${HF_TOKEN}  # 배포 중 주입됨

Deployment: Neuron 최적화 Qwen 3 8B

# model-qwen3-8b-neuron.rendered.yaml (주요 섹션)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: qwen3-8b-neuron
  namespace: vllm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: qwen3-8b-neuron
  template:
    spec:
      # Neuron 하드웨어를 위한 노드 선택
      nodeSelector:
        eks.amazonaws.com/instance-family: inf2
        node.kubernetes.io/instance-type: inf2.xlarge
      containers:
        - name: vllm
          image: public.ecr.aws/agentic-ai-platforms-on-k8s/vllm-neuron:qwen3-8b
          command: ["vllm", "serve"]
          args:
            - --served-model-name=qwen3-8b-neuron
            - --trust-remote-code
            - --gpu-memory-utilization=0.90
            - --enable-auto-tool-choice
            - --tool-call-parser=hermes
            - --reasoning-parser=qwen3
            - --tensor-parallel-size=2
            - --max-num-seqs=1
            - --max-model-len=16384
          resources:
            requests:
              cpu: 3
              memory: 12Gi
              aws.amazon.com/neuroncore: 2  # 2개의 Neuron 코어 요청
            limits:
              aws.amazon.com/neuroncore: 2

주요 구성 세부 사항은 다음과 같습니다.

노드 선택: Pod가 Neuron이 장착된 inf2 인스턴스에서만 실행되도록 보장
Neuron 코어: neuroncore 리소스는 요청(requests)과 제한(limits)이 반드시 일치해야 함
Tensor Parallelism: 더 빠른 추론을 위해 2개의 Neuron 코어에 모델 분할
컨텍스트와 동시성: 16K 컨텍스트 윈도우로, 한 번에 하나의 시퀀스만 처리

Service

Service는 vLLM Deployment를 노출해, LiteLLM 같은 다른 컴포넌트가 접근할 수 있도록 합니다.

apiVersion: v1
kind: Service
metadata:
  name: qwen3-8b-neuron
  namespace: vllm
spec:
  selector:
    app: qwen3-8b-neuron
  ports:
    - name: http
      port: 8000

Selector: app: qwen3-8b-neuron 레이블이 있는 Pod와 매칭
포트 8000: OpenAI 호환 엔드포인트를 위한 표준 vLLM API 포트
ClusterIP: 클러스터 내부에서만 접근 가능한 내부 서비스

이 외에도 LiteLLM을 통해 Bedrock 모델을 같은 인터페이스로 호출할 수 있습니다.

Open WebUI에서의 RAG

Open WebUI에는 또한 기본 RAG(Retrieval Augmented Generation) 기능이 내장되어 있습니다.

RAG가 문서의 특정 컨텍스트를 제공해 AI의 응답을 어떻게 변화시키는지 확인해보겠습니다.

먼저 IDE 터미널에서, 모델이 알기 힘든 내용의 테스트 파일을 만듭니다.

cat > super-secret.txt << 'EOF'
Super Secret Document

This document contains classified information about the secret project.
Only authorized personnel are allowed to access this data.

Project Codename: Nightfall
Objective: Develop an untraceable communication device.
Status: In progress

Remember, this information is top secret and must not be shared with anyone.
EOF

이 파일을 IDE 파일 탐색기에서 로컬 머신으로 다운로드한 뒤, Open WebUI에 업로드합니다.

다음으로 Open WebUI에서 Knowledge Base를 생성합니다.

Workspace > Knowledge로 이동해 새 Knowledge Base 생성

양식 작성
- Name: super-secret-info
- Description: Store secret info in knowledge base
- Visibility: Private
Create Knowledge 클릭 후, + > Upload files로 super-secret.txt 업로드

이제 bedrock/claude-4.5-sonnet에게 같은 질문을 RAG 유무에 따라 비교해봅니다.

질문은 "What is the objective of project nightfall?"입니다.

RAG 없이 질문

RAG 없이 질문하면, 모델은 "Project Nightfall에 대한 구체적인 정보가 없다"며
소설이나 게임, 군사 프로젝트 등의 가능성만 나열하고 오히려 맥락을 되묻습니다.

학습한 적 없는 내용이니 당연한 결과입니다.

2. Knowledge Base 연결 후 질문

Knowledge Base를 연결한 뒤에는 Retrieved 1 source 표시와 함께,
super-secret.txt를 출처로 인용하며 "추적 불가능한 통신 장치 개발"이라고 정확히 답합니다.

같은 모델이라도 어떤 컨텍스트를 쥐여주느냐에 따라,
답변의 질이 완전히 달라진다는 것을 직접 확인할 수 있었습니다.

마무리

이번 글에서는 EKS Auto Mode 기반의 워크샵 환경 구성과,
모듈 1에서 다룬 모델과의 상호작용까지 정리해보았습니다.

다음 글에서는 모듈 2를 이어서,
LiteLLM 게이트웨이와 Langfuse 관측성을 중심으로
개별 컴포넌트들이 어떻게 하나의 플랫폼으로 통합되는지 정리해보겠습니다.

관련하여 더 자세한 내용이 궁금하시다면,

https://github.com/aws-samples/sample-genai-on-eks-starter-kit

GitHub - aws-samples/sample-genai-on-eks-starter-kit: A comprehensive toolkit for deploying production-ready Generative AI infra

A comprehensive toolkit for deploying production-ready Generative AI infrastructure on Amazon EKS. Includes pre-configured components for: AI Gateway (LiteLLM) LLM Serving (vLLM, SGLang, Ollam...

github.com

LDAP 알아보기

frontheadlock — Wed, 15 Jul 2026 23:16:20 +0900

LDAP란?

LDAP란?
LDAP(Lightweight Directory Access Protocol)는 디렉토리 서비스를 제공하기 위한 프로토콜
네트워크상에서 조직이나 개인, 파일, 디바이스 등을 쉽게 조회할 수 있도록 해줍니다.
출처 : 삼성 SDS 블로그

우선 LDAP를 이해하기 위해서는 "디렉터리 서비스"에 대한 이해가 필요합니다.

디렉터리 서비스는 사람, 그룹, 장비, 계정 같은 개체의 속성 정보를 계층적으로 저장하고,
조회와 인증에 최적화된 특수 목적의 데이터 저장소입니다.

쉽게 말하면, 디렉터리 서비스란 일종의 조직도와 같습니다.
읽기(조회, 인증)가 압도적으로 많고, 쓰기(사용자 추가, 수정)는 드물다는 가정 위에서 만들어졌습니다.

여기서, 일반적으로 사용되는 RDB와의 차이가 있습니다.

흔히 사용되는 MySQL 같은 RDB와 디렉터리 서비스는 목적 자체가 다릅니다.

데이터 구조
- RDB : 정규화된 테이블과 조인으로 관계 표현
- DS : 하나의 계층 트리에 데이터를 배치
워크로드
- RDB : 복잡한 트랜잭션이나 조인, 즉시 정합성 등을 이뤄냄
- DS : 읽기 중심으로, 복제를 이용해 읽기 부하 분산
스키마
- RDB : 애플리케이션들마다 제각각
- DS : objectClass와 속성이 표준화되어 서로 다른 시스템이 같은 cn, mail, uid 공유

LDAP는 디렉터리 서비스라고 하지만, 실제로는 프로토콜입니다.

디렉터리 서비스의 표준 모델로 자리 잡은 X.500에 대해,
X.500 디렉터리에 접근하기 위한 프로토콜이 DAP(Directory Access Protocol)였습니다.

DAP는 무거운 OSI 프로토콜 스택 전체를 요구하며, 사용에 있어 부담이 생길 수밖에 없었습니다.

이를 극복하기 위해 나온 것이 LDAP로, Lightweight가 붙은 것입니다.

다만, 이름에 Lightweight가 붙어 데이터도 가벼운? 줄 알지만,
데이터가 가볍거나 작다는 것이 아니라,
OSI 스택 전체를 요구하던 DAP 대비 프로토콜과 구현이 가볍다는 의미입니다.

또한 TCP 389번 포트 하나로 접속한다는 점에 차이가 있습니다.
(평문으로 관리하기엔 어려움이 있어, TLS로 감싸는 636(LDAPS)또는 StartTLS로 암호화합니다.)

LDAP의 데이터 모델

트리

앞서 LDAP는 트리를 이용해 데이터를 담는다고 하였습니다.

이 트리는 DIT (Directory Information Tree)라 부릅니다.

DIT 내 최소 단위는 Entry로,
엔트리 하나가 사람 한 명, 그룹 하나, 조직 하나에 대응합니다.

그리고 이러한 엔트리는 DN(Distinguished Name)으로 트리 내에서 유일하게 식별됩니다.

DN을 이해하는 가장 좋은 비유는 파일 시스템의 절대 경로입니다.

uid=hong,ou=people,dc=lab,dc=example,dc=com

DN을 분해하면 이렇게 됩니다.

uid=hong : 같은 부모 밑 형제들 사이에서만 유일하면 되는 이름.
ou=people : 부모 컨테이너(organizationalUnit, 부서/그룹 같은 계층).
dc=lab,dc=example,dc=com : 트리의 뿌리(base DN).

DN에 자주 등장하는 약어들은 각각 계층과 용도가 다릅니다.

dc : domainComponent. 도메인을 조각낸 것, 보통 트리 뿌리를 짓는 데 씁니다.
ou : organizationalUnit. 부서나 그룹 같은 컨테이너 계층.
cn : commonName. 표시 이름(사람, 그룹 모두 사용).
uid : userID. 로그인 아이디.

objectClass

objectClass란?
objectClass는 엔트리의 종류를 규정하고, 어떤 속성이 필수/선택인지 정하는 스키마 요소입니다.
출처 : RFC 4512

objectClass는 엔트리가 사람인지 그룹인지 결정합니다.

objectClass는 일종의 폼 템플릿으로,
엔트리에 inetOrgPerson 폼을 붙이면 이름칸(cn, sn)은 필수가 되고 메일칸은 선택이 됩니다.

이러한 objectClass는 STRUCTURAL, AUXILIARY, ABSTRACT(top)로 나뉩니다.

이 중 실무에서는 주로 STRUCTURAL과 AUXILIARY을 사용합니다.

STRUCTURAL
- 엔트리의 본질적 종류를 정하는 것
AUXILIARY
- 기존 엔트리에 속성을 덧붙이는 보조 클래스
- posixAccount가 대표적인 예시

이렇게 구성된 엔트리들을 텍스트로 표현하는 표준 포맷이 LDIF입니다.

LDIF는 서버 간 데이터를 가져오고 내보내거나 변경을 기술할 때 사용됩니다.
dn:으로 시작해 '속성: 값' 줄이 이어지고, 빈 줄로 레코드를 구분합니다.

dn: uid=hong,ou=people,dc=lab,dc=example,dc=com
objectClass: top
objectClass: inetOrgPerson
cn: Gildong Hong
sn: Hong
uid: hong
mail: hong@lab.example.com

ldapsearch 를 사용할 경우, 스크립트를 활용해 ldap 내 조회를 더 쉽게 가져갈 수도 있습니다.

LDAP_URI="ldapIP"
DN="$1"

if ldapsearch -x -H "$LDAP_URI" -b "$DN" -s base dn &> /dev/null; then
    echo "[OK] 존재하는 DN: $DN"
else
    echo "[NO] 없는 DN: $DN"
fi

LDAP 활용

이러한 LDAP는 특정 회사의 제품이 아니라, IETF의 RFC로 정의된 개방형 프로토콜입니다.

사용자는 LDAP라는 프로그램을 설치하는 것이 아니라,
LDAP라는 프로토콜(규칙)을 구현한 구현체를 설치해 사용하는 것입니다.

LDAP의 구현체에는 다음과 같은 프로그램이 있습니다.

OpenLDAP
Microsoft Active Directory
389 Directory Server
Apache DS
Red Hat Directory Server

이들은 모두 LDAP 프로토콜을 구현한 서로 다른 제품으로,
LDAP 자체는 표준 문서로서 벤더에 종속되지 않고 ldapsearch 같은 클라이언트로 접근이 가능합니다.

389DS

사내에서는 389를 이용해 LDAP를 관리하고 있습니다.

사실 그동안 써 온 AD도 내부적으로는 LDAP(과 Kerberos)로 동작하는 디렉터리 서버입니다.
다만 스키마와 관리 방식이 Windows에 강하게 묶여 있을 뿐이죠.

같은 LDAP 구현체임에도, 사내에서 389 DS를 택한 데에는 Linux라는 장벽이 있었습니다.

Linux는 user를 모두 숫자(uidNumber, gidNumber)로 알아보는데,
Windows AD는 사람을 SID로 알아보는 문제가 있었습니다.

같은 사용자를 두 OS가 서로 다른 방식으로 식별하고 있던 것입니다.

Linux가 사용자를 로그인시키려면 다음 값들이 필요합니다.

uidNumber : 숫자 사용자 ID
gidNumber : 기본 그룹 ID
homeDirectory : 홈 디렉터리 경로
loginShell : 로그인 셸

Windows AD는 사용자에게 SID, samAccountName은 주지만, POSIX를 쓰지 않습니다.

이를 극복하고자 사용하던 것이 SFU였습니다.

SFU는 AD 사용자에 uidNum, gidNum 같은 POSIX 속성을 붙여주고,
이를 NIS처럼 배포해 UNIX가 AD 계정을 인식하도록 해줍니다.

이러한 SFU를 MS에서 deprecate하며, 내부적으로 Linux 환경 유저들에 한해 AD에서 분리하게 된 것입니다.

운영환경

다만, 389 DS를 세웠다고 해서 리눅스가 알아서 계정을 봐주지는 않습니다.

실제로 계정을 읽어오는 주체는 서버가 아니라 각 클라이언트의 연동 데몬입니다.
서버가 조직도를 들고 있어도, 이를 열람해 로그인에 반영하는 것은 클라이언트의 몫인 것이죠.

연동을 담당하는 클라이언트 패키지도 하나가 아니라, 세대별로 나뉘어 있습니다.

nslcd : LDAP 조회와 인증만 담당하는 가볍고 단순한 데몬 (nss-pam-ldapd 패키지)
nscd : 엄밀히는 LDAP 클라이언트가 아니라, 조회 결과를 캐시해주는 보조 데몬
sssd : 조회에 캐싱, 오프라인 로그인, 접근 제어까지 묶은 현대적 기본값

~~이름이 다 비슷하게 생겨서 헷갈려요..~~

무엇을 고르느냐에 따라 권한 관리의 위치도 달라집니다.

nslcd를 쓸 경우 PAM 계층의 pam_access로 관리자와 그룹의 접근 권한을 제어하지만,
sssd를 쓸 경우 LDAP 연결, TLS, 캐시, 접근 제어까지 sssd.conf 한 파일로 수정점이 집약됩니다.

이처럼 같은 프로토콜을 쓰더라도,
어떤 클라이언트 구성을 고르고 보안과 접근 제어를 어떻게 챙기느냐에 따라 운영의 결이 크게 달라집니다.

마무리

입사 후 LDAP를 맡아 열심히 적응하는 중이지만,
팀은 기존에 사용하던 389 DS에서 FreeIPA로의 전환을 검토 중입니다.

순수 LDAP은 '디렉터리', 즉 신원을 저장하고 조회하는 계층까지만 주기에,
Kerberos 기반 SSO, HBAC, 중앙 sudo 규칙 같은 것들을 관리자가 직접 관리해야합니다.

하지만, FreeIPA는 이를 미리 묶어, ipa라는 단일 인터페이스로 관리하게 해줍니다.
~~(FreeIPA 야호 ..!)~~

다만 이런 FreeIPA도 결국은 LDAP을 활용합니다.
FreeIPA의 디렉터리 백엔드가 바로 389 DS이기 때문입니다.

즉 FreeIPA로 넘어가는 것은 LDAP을 버리는 것이 아니라, LDAP 위에 관리 계층을 얹는 것에 가깝습니다.
앞서 'AD도 결국은 LDAP'라고 했는데, FreeIPA도 열어보면 심장은 389 DS인 셈이죠.

정리하면 LDAP은 특정 제품이 아니라,
X.500에 뿌리를 둔 디렉터리 서비스에 TCP/IP로 접근하기 위한 경량 프로토콜입니다.

디렉터리는 트리(DIT)에 엔트리를 담아 DN으로 식별하고, objectClass로 종류와 속성을 규정합니다.

그리고 그 위에서 389 DS 같은 구현체, SSSD 같은 클라이언트, TLS 같은 보안 장치가 실제 운영을 만듭니다.

AD든 FreeIPA든, 속을 열어보면 결국 LDAP이 있습니다.

팀은 FreeIPA로 넘어가지만, LDAP에 대한 공부가 헛수고가 아닐 것이라 믿습니다.

요즘 개발자

frontheadlock — Mon, 18 May 2026 22:36:10 +0900

요즘 개발자

오랜만에 본가에 갔다가 들린 도서관에서, 『요즘 개발자』 이라는 책을 보게 되었다.

제목부터 뭔가 MZ 개발자인 나와 딱 어울리는 책인 것 같아 보자마자 읽어보게 되었다.

이 책은 개발자에 대한 정의,

요즘 개발자들은 어떻게 학습하는지,

개발자로써 협업하는 방법,

'나'라는 개발자를 어떻게 브랜딩할 지에 대해 이야기 한다.

책을 읽으면서 생각보다 많은 고민을 해볼 수 있었다.

책에서는 개발자를 다음과 같이 표현했다.

1. 소프트웨어 장인 정신을 갖는 개발자

2. 회사가 정의하는 개발자

3. 내가 정의하는 개발자

개인적으로 3가지 모두 중요한 것 같다고 느꼈다.

개발자는 직업에 맞게 내가 만드는 것들에 대해 높은 수준의 완성도를 가지는 것도 중요하고,

동시에 회사원으로써 회사의 문제를 해결하고 비전을 가져다주며,

최종적으로 한 명의 인간으로써 내가 이 직업으로 어떤 가치를 실현하고 싶은지 알아야 한다.

처음 개발자라는 직업을 선택했던 이유는 단순했다.

코드를 통해 내가 무언가를 만들어내는게 즐거워서였다.

내가 만들어낸 작업물들로 큰 가치를 창출해본 경험은 없지만,

주변인들로부터 해당 작업물에 대해 멋있다는 소리를 들을 때면 알게 모르게 뽕이 찼고,

산출물을 만들어 나가며 동료들과 협업하는 그 과정 자체가 너무 즐거웠다.

물론 아직 내가 어떤 개발자가 되고 싶은지 명확하게 알고 있지는 못한다.

하지만 책을 읽으며 한가지는 확실히 느낄 수 있었다.

짧게는 수 년, 길게는 수십 년 뒤에는 개발 시장이 지금과 전혀 달라져 있을 것이고,

살아남기 위해서는 '나'라는 사람을 팔 수 있어야 한다는 것이다.

나는 남들보다 월등히 뛰어난 재능을 가지고 있지도, 특출난 언변을 가지고 있지도 못하다.

하지만, 동료들과 협업하는 과정을 즐기는 성향은 분명히 가지고 있다.

그래서 따뜻하게 다가갈줄 알고, 동료들에게 귀 기울일 줄 아는,

함께 일하고 싶은 동료로 성장하고 싶다.

뛰어난 개발자가 되는 것도 중요하지만, 함께하고 싶은 사람이 되는 것도 중요하다고 생각한다.

물론 이를 위해서는 꾸준한 학습으로 최소한 뒤쳐지지는 않는 실력을 만들어야겠지만 말이다...

책을 읽으며 저자가 얼마나 밝은 사람이고, 독자에게 따뜻한 말을 통해 도움이 되고 싶어하는 지가 느껴졌다.

나도 그들처럼 언젠가는 타인에게 도움이 될 수 있는 사람으로 성장하고싶다.

기술적으로는 계속 성장하고자 노력하고,

협업과정에서는 신뢰를 주며,

내가 배운 것들을 다시 누군가에게 나눌 수 있는 사람.

아직은 부족한 점 투성이지만, 적어도 내가 어떤 방향으로 성장해야 하는지 방향성을 잡을 수 있었던 것 같다.

앞으로도 기록하고, 회고하며 나의 길을 정립해 나가,

『요즘 개발자』에 끝나는 사람이 아니라, 시간이 지나도 함께 하고 싶은 국밥 같은 개발자가 되어야지!

OpenStack 시작 전에 알아 볼 컨테이너 이야기

frontheadlock — Tue, 12 May 2026 18:32:27 +0900

OpenStack을 이해하기 위해서는 컨테이너를 함께 이해해야 합니다.

OpenStack을 배포하는 데에는 컨테이너가 사용되고,
OpenInfra Foundation 내에서도 컨테이너와 관련된 기술이 계속 중요해지고 있습니다.

초기 컴퓨팅 환경

배치처리 vs 시분할처리

컨테이너의 개념은 VM이 대중화되기 이전부터 존재했습니다.

초창기의 컴퓨터 환경은 메인프레임 중심이었습니다.

이 시기에는 배치 처리를 중심으로 컴퓨팅 처리를 진행하였습니다.

작업 목록을 일렬로 세워두고, 하나의 작업이 끝나면 다음 작업을 실행하여,
하나의 작업이 진행되는 동안 뒤에 있는 작업들은 기다렸습니다.

이 시기에는 안정성을 위해 하나의 서버에서 하나의 어플리케이션만을 실행했었습니다.

이때, 대부분의 어플리케이션은 서버의 모든 자원을 사용하기 힘들어,
고가의 장비가 배치되었음에도 컴퓨터의 많은 리소스가 유휴 상태인 경우가 많았습니다.

이러한 흐름 속에서 시분할 처리의 개념이 도입되기 시작했습니다.

시분할 처리는 CPU 시간을 아주 작은 단위로 쪼개 여러 프로세스에 차례대로 할당하여,

여러 프로세스가 동시에 계속 실행되는 것처럼 느끼도록 하였습니다.

그럼에도 배치 처리와 시분할 처리에는 큰 문제가 있었습니다.

누군가 코드를 잘못 작성해 시스템을 망가뜨리면 전체 시스템이 함께 영향을 받는다는 점이었습니다.

이 문제를 해결하기 위해 최초의 가상화 기술이 만들어지기 시작했습니다.

1960년대 중반 IBM은 CP-40 / CP-67 계열 시스템에서,
하드웨어 전체를 가상으로 복제하는 기술을 만들었습니다.

사용자에게 완전히 독립된 형태의 가상 컴퓨터를 제공하는 최초의 VM 개념이 처음으로 등장한 것입니다.

다만, 이 시기의 VM은 CPU 등을 포함한 많은 요소가 소프트웨어적으로 에뮬레이션되는 방식이었습니다.

메인프레임에서 x86 서버로

이전까지 서버 환경은 메인프레임 시대였습니다.
( 심지어 오늘날까지도 은행권에서는 메인프레임을 사용하는 경우가 있습니다 )

1990년대 후반과 2000년대 초반 닷컴 버블과 인터넷 보급으로,
인터넷 서비스가 빠르게 늘어나며 기업들은 폭발적으로 증가하는 트래픽을 감당해야 했습니다.

메인프레임에서는 IBM이 제공하는 가상화 기술이 있었으나,
x86 기반 저비용 서버 환경에서는 같은 수준의 가상화 기술이 없었습니다.

x86 서버는 메인프레임과 비교하여 값이 저렴하더라도 가상화 기술의 부재로,

서버를 온전히 사용할 수 없다면 서버의 증설로 추가적인 비용 소모가 발생하게 됩니다.

하지만 VMware가 VMware ESXi, VMware Workstation 같은 솔루션으로,

x86 서버에서 사용 가능한 제품들을 만들며 x86 서버에서의 가상화를 이뤄냈습니다.

이로 인해, 사용자들은 물리 자원의 사용량을 극대화할 수 있게 되었습니다.

또한, 호스트의 운영체제에 상관없이 게스트 OS로 다양한 OS를 올릴 수 있게 되며,

대폭의 비용 절감으로 인한 x86 서버 시장의 확대로 이어졌습니다.

결국 고가의 메인프레임만으로는 트래픽에 대한 비용 부담이 컸기에,

기업들은 인텔 기반 CPU를 사용하는 저비용 서버를 IT 인프라로 도입하기 시작했고,

UNIX 기반의 서버에서 Linux 로 변화가 이뤄졌습니다.

x86의 유래

x86 서버는 Intel CPU 모델 명에서 비롯되었습니다.
Intel CPU 모델 명이 80386, 80486 .. 처럼 86으로 끝났기 때문에,
이 계열 CPU를 사용하는 서버를 x86 서버라고 불렀습니다.

VM의 한계와 컨테이너적 사고

가상 머신은 강력한 격리를 제공하지만 무겁습니다.

starting time이 오래 걸리고, OS 전체를 포함해야 합니다.

초기의 가상화는 하드웨어 전체를 격리된 가상 컴퓨터로 제공하는 방식이었습니다.

하지만 실제로 어플리케이션을 운영해보며, 사용자들은 그 이상의 격리를 원하게 되었습니다.
누군가 시스템 파일을 깨뜨리거나 의존성을 파괴하기에, 영향을 주는 것을 막길 원한 것입니다.

이를 위해 어플리케이션과 그 의존성, 시스템 lib, fsystem,network 등 프로세스 단위로 격리하고자,

컨테이너 기술의 흐름이 시작되었습니다.

chroot

컨테이너를 만드는 기술의 핵심은 1979년의 chroot 기술로 볼 수 있습니다.

chroot는 격리된 루트 파일 시스템을 제공합니다.
특정 사용자나 프로세스에게 실제가 아닌 별도의 루트 파일 시스템을 보여줘,

네트워크가 연결되고, 시스템에 원격 접속이 가능해지며,
원격 접속 사용자에게 가짜 파일 시스템을 보여주는 방식이 필요해졌습니다.

사용자가 shell을 얻어 접속하더라도, 사용자가 보는 환경을 제한할 수 있어졌습니다.

Docker Container 안으로 shell 접속을 하면, 해당 컨테이너 만의 파일 시스템이 보이게 됩니다.

이는 호스트가 완전히 격리되어 있기에 가능한 것으로, Docker 만의 격리된 파일 시스템인 것입니다.

chroot는 파일 시스템 격리에 초점이 맞춰져 있습니다.

다만 파일 시스템의 격리만으로는 공격자의 기업 네트워크 격리를 차단하기에 적절하지 않아,

FreeBSD는 Jail을 만들게 되었습니다.

이는 파일 시스템 뿐만 아니라 네트워크까지 격리하는 개념으로, 현재 컨테이너 기술에 많은 영향을 끼쳤습니다.

OpenStack , K8s 모두 이와 동일한 것으로 존재하는 기술들을 잘 엮어 하나의 플랫폼으로 포장한 것입니다.

cgroups , namespaces

현대 컨테이너의 근간은 cgroups와 namespaces입니다.

Linux의 대표적인 기술인 cgroups와 namespaces는 사실 구글에서 만든 기술로,
2006년도 구글에서 진행한 process containers 프로젝트에서 비롯되었습니다.

해당 프로젝트에서는 프로세스의 CPU, memory, I/O 같은 리소스 사용량을 제한하며,
여러 기존에 있던 격리 기술들을 활용하는 기술을 개발하였습니다.

이 과정에서 computerolegroup (cgroup)으로 이름을 바꿔 리눅스 커널을 통합하며, 세상에 나왔습니다.

이는 noisy neighbor 문제를 해결하기 위한 것으로,
cloud service에서 특정 서비스에 트래픽이 몰려 리소스를 못쓰게 되는 현상을 방지하기 위한 것으로,

프로세스 컨테이너를 활용해 컨테이너로 서비스를 돌렸습니다.

이로 인해, cgroup을 만들었고, 이를 발전시켜 실행 환경 자체를 격리하는 namespace까지 이어진 것입니다.

cgroup과 namespace를 기반으로 사용자들은,
PID, 네트워크 스펙, 마운트 지점 등 시스템의 주요 포인트들을 프로세스마다 격리된 시각으로 볼 수 있게 되었습니다.

이렇게 만들어진 cgroups 와 namespace가 리눅스 커널에 들어오게 되며 리눅스가 발전하게 됩니다.

LXC의 등장

LXC는 LinuX Containers의 약자로,

cgroups와 namespaces를 통합해 커널 패치 없이 컨테이너를 관리할 수 있게 한 최초의 사용자 도구입니다.

하지만 이때까지만 해도 컨테이너는 Linux 시스템을 매우 잘 아는 사람들의 전유물로,
SW 개발자나 이에 관심없는 개발자들은 컨테이너에 대해 알지 못했습니다.

설령 이에 대해 알고 있더라도,
namespaces를 만들고, cgroups 설정 및 파일 시스템 준비 후 네트워크를 붙여 어플리케이션을 배포하는 일은
일반 개발자가 쉽게할 수 있는 일이 아니었습니다.

Docker의 등장

2013년 3월 13일, Docker가 처음 등장하였습니다.

Docker는 기존의 Linux 엔지니어만 활용 가능했던 컨테이너 기술을,
추상화하여 개발자가 사용가능한 쉬운 인터페이스로 개선하였습니다.

개발자는 컨테이너 내부에서 cgroups와 namespaces가 어떻게 동작하는지 몰라도,
docker start, docker run 같은 명령으로 컨테이너를 실행시킬 수 있게 되었습니다.

몇 줄의 짧은 파일 작성을 통해, 어플리케이션을 컨테이너 이미지로 만들 수 있었습니다.

특히나, 2010년대 초반 개발자들 사이에서 Agile 방법론이 매우 중요한 키워드로 떠오르던 환경에서,
MSA가 주목받으며 Docker도 함께 주목받게 되었습니다.

Docker를 활용하면 서비스를 작게 나눠 각각을 빠르게 배포하고, 교체함에 있어 훨씬 수월해지는 것입니다.

컨테이너를 빠르게 만들고 실행할 수 있기에 MSA와 Agile 흐름 속에서 더욱 각광받았습니다.

DockerFile

특히나 Docker가 성공할 수 있었던 가장 큰 이유 중 하나는 Dockerfile 이었습니다.

Docker의 이미지는 Layer 구조를 가져,

어플리케이션을 새로 배포할 때, 전체 환경을 매번 다시 만드는 것이 아니라, 변경된 레이어만 새로 만들 수 있습니다.

예를 들어, OS와 런타임, 라이브러리 레이어는 그대로 재사용하고,
어플리케이션 코드가 바뀐 마지막 레이어만 교체해 저장공간을 줄이고, 빠른 배포를 가능케합니다.

Dockerfile은 실행 환경을 파일로 정의하게 해주었습니다.
이를 통해, 개발자는 어플리케이션이 어떤 환경에서 실행되어야 하는지,
코드처럼 관리할 수 있게 되었습니다.

Registry

또한, Docker가 대중화될 수 있었던 또 다른 이유는 Registry에 있습니다.

Registry란 원격 저장소로 GitHub, PyPI, npm과 같은 역할을 수행합니다.

과거에는 개발자가 매번 웹 서버, DB , runtime 구성들을 반복해야 했습니다.
오픈소스 라이브러리를 가져다 쓸 수 있었으나, 실행 환경 전체를 재사용하는 것은 쉽지 않았습니다.

Registry가 등장하며 다른 사람이 만들어놓은 이미지를 가져와 이를 사용할 수 있게 되었습니다.

Registry는 이미지를 공유하고, 재사용하게 만들었고, 컨테이너 생태계 확장에 결정적 역할을 했습니다.

Docker의 한계

Docker Engine은 croups와 namespaces 같은 Linux 커널 기능을 이용해 컨테이너를 만들고 실행합니다.

하지만 Docker는 기본적으로 한 서버 내에서 컨테이너를 실행하고 관리하는 도구입니다.

엔터프라이즈 환경에서는 멀티 서버에서 컨테이너를 실행해야 하기에,
Dokcer만으로는 여러 서버의 컨테이너를 중앙에서 파악하고, 제어하기에 어려움이 있습니다.

이를 극복하기 위해 Docker Compose 같은 도구가 등장했지만,
이는 여전히 대규모 클러스터 운영 문제를 해결하는 도구는 아닙니다.

서비스가 커지고 컨테이너 개수가 많아지며 이를 해결하기 위한 오케스트레이션 도구의 전쟁이 벌어지게 되었습니다.

이런 컨테이너가 많아지자 오케스트레이션이 필요해졌고,
Apache Mesos, Docker Swarm, Kubernetes가 경쟁했습니다.

Google에서 Go를 기반으로 만든 K8s가 오늘날 산업의 표준으로 자리 잡았고,
CNCF로 기부되며 오픈소스 생태계 전략도 K8s 확산에 중요한 역할을 하였습니다.

오늘날 OpenStack과 K8s는 분리된 개념이 아닙니다.

OpenStack은 프라이빗 클라우드의 컴퓨트, 네트워크, 스토리지 기반을 제공하고,
Kubernetes는 그 위에서 컨테이너와 AI 워크로드를 운영합니다.

OpenStack 관점에서의 컨테이너

컨테이너는 어플리케이션을 가볍게 실행하는 기술만은 아닙니다.

운영 관점에서 보면 컨테이너는 아래의 기술이 OpenStack과 연결됩니다.

실행 환경 표준화
배포 단위 최소화
서비스의 일관된 운영 방식 기술

OpenStack은 하나의 거대한 프로그램이 아닌,

Nova, Neutron, Cinder, Glance, Keystone 같은 여러 서비스가 함께 동작하는 분산 시스템입니다.

각 서비스는 API 서버, 스케줄러, 에이전트, 데이터베이스, 메시지 큐 등 다양한 컴포넌트와 함께 운영됩니다.

이런 시스템을 직접 설치하고 관리하기 위해서는 의존성 충돌, 버전 관리, 배포 순서, 장애 복구 같은 문제가 복잡해집니다.

컨테이너는 이 복잡성을 줄이는 데 도움을 줍니다.

각 OpenStack 서비스를 컨테이너 이미지로 패키징해,

실행 환경을 더 일관되게 유지할 수 있고,

배포와 업그레이드도 더 예측 가능해집니다.

컨테이너는 OpenStack 위에서 실행되는 워크로드이기도 하지만,

동시에 OpenStack 자체를 배포하고 운영하는 방식에도 깊게 들어와 있습니다.

파이팅

컨테이너는 어느 날 갑자기 등장한 기술이 아닙니다.

이 흐름을 이해하면 OpenStack과 Kubernetes의 관계도 더 선명해집니다.

OpenStack은 컴퓨트, 네트워크, 스토리지 같은 하부 인프라를 제공합니다.

Kubernetes는 그 위에서 컨테이너화된 애플리케이션과 AI 워크로드를 운영합니다.

컨테이너는 OpenStack 위에서 실행되는 대상일 뿐 아니라, OpenStack 자체를 배포하고 운영하는 방식에도 사용됩니다.

OpenStack을 이해하기 위해서는 Nova, Neutron, Cinder 같은 컴포넌트와 더불어,

현대 인프라가 어떤 문제를 해결하기 위해 가상화로 발전했고,

다시 컨테이너와 오케스트레이션으로 확장되었는지를 이해해야합니다.

OpenStack Client 사용해보기

frontheadlock — Mon, 27 Apr 2026 16:19:44 +0900

OpenStack을 사용하는 방법에는 여러가지가 있습니다.

OpenStack의 DevStack을 이용해 직접 구축한 후 이를 사용해보거나,

openstack client를 이용해 구축된 환경에 cli 형태로 접근할 수도 있습니다.

다만 openstack client는 단독으로 모든 것을 구성해주는 도구는 아니기에,

OpenStack 환경이 사전에 준비되어 있어야 합니다.

저의 경우 이미 사용 가능한 OpenStack 환경을 제공받았기 때문에,

이번에는 python-openstackclient를 직접 내려받아 CLI 동작을 확인해보겠습니다.

1. Source Code Clone

우선 작업을 진행할 디렉토리에 소스코드를 clone 받습니다.

git clone https://opendev.org/openstack/python-openstackclient

필요한 코드를 직접 받아두면,
실행 흐름을 따라가거나 디버깅할 때도 조금 더 수월하게 볼 수 있습니다.

2. clouds.yaml 파일 생성

OpenStackClient는 인증 정보를 clouds.yaml 파일로 관리할 수 있습니다.

clouds:
  my-cloud:
    auth:
      # Keystone 인증 엔드포인트 주소
      auth_url: 접속할 원격 서버 url
      username: '접속 유저명'
      password: '비밀번호'
      # 접속 테넌트명
      project_name: '프로젝트명'
      user_domain_name: 'Default'
      project_domain_name: 'Default'
    region_name: 'RegionOne'
    interface: 'public'
    identity_api_version: '3'

clouds.yaml은 현재 clone 받은 루트 디렉토리에 생성하겠습니다.

위와 같이 clouds.yaml을 생성해두면,
이후 명령어에서 my-cloud라는 이름으로 해당 OpenStack 환경에 접근할 수 있습니다.

3. PyCharm을 이용한 venv 생성

PyCharm을 이용해 python-openstackclient와 tox 등을 실행할 virtualenv를 생성해줍니다

OpenStack의 경우 python3.10 버전과 특히 잘맞아 3.10버전으로 가상환경을 세팅하였습니다.

4. 의존 라이브러리 설치

python-openstackclient를 실행하기 위해 의존 라이브러리를 virtualenv에 설치합니다.

# 실행용 기본 의존성 설치
python3 -m pip install -r requirements.txt

# 테스트용 기본 의존성 설치
python3 -m pip install -r test-requirements.txt

5. python-openstackclient를 develop 모드로 설치하기

이제 virtualenv에 python-openstackclient 자체를 설치합니다.

일반적으로 파이썬 코드를 받아 설치할 때는 `python setup.py install`을 이용하지만,

개발을 위해서는 아래 명령어로 develop 모드로 설치해아 합니다.

python3 setup.py develop

6. openstack server list 실행해보기

python-openstackclient의 진입점은 openstackclient/shell.py에 있습니다.

이 파일을 그냥 실행시키면 OpenStack CLI가 구동되므로,
우리는 server list와 같은 인자를 함께 넘겨줘야 합니다.

server list 값을 넣어주기 위해서는 shell.py 실행 이후,
PyCharm에서 제공하는 Edit Configurations를 이용해 스크립트 인자를 넣어줄 수 있습니다.

스크립트 인자를 넣는 곳에 아래와 같이 입력합니다.

# 서버 목록 조회
# clous.yaml에 정의한 my-cloud 설정 사용
server list --os-cloud my-cloud

여기서 --os-cloud my-cloud는 clouds.yaml에 설정한 OpenStack 환경 이름을 의미합니다.

간혹 Working Directory의 경로가 openstackclient 폴더까지 잡히는 경우가 있는데,
이럴 때는 프로젝트 루트인 python-openstackclient까지 경로가 잡히도록 수정합니다.

이후 shell.py를 실행하면 아래와 같이 터미널에 서버 목록이 출력됩니다.

이렇게 확인한 결과는 터미널에서

openstack server list 직접 실행했을 때와 동일한 의미를 가집니다.

PyCharm에서 소스 기준으로 실행해도,

결국 우리가 사용하는 OpenStack CLI 동작을 그대로 확인할 수 있다는 뜻입니다.

출력되는 주요 항목은 아래와 같이 이해하면 됩니다.

ID
- UUID 형태로 구성된 서버의 고유 식별자입니다.
- OpenStack 내부에서 인스턴스를 구분할 때 사용됩니다.
Name
- 서버 생성 시 지정한 인스턴스 이름입니다.
Status
- 서버의 현재 상태를 나타냅니다.
- 예를 들어 ACTIVE, SHUTOFF, ERROR 같은 값으로 확인할 수 있습니다.
Networks
- 서버가 연결된 네트워크와 할당된 IP 정보를 보여줍니다.
Image
- 서버를 생성할 때 기반이 된 이미지 정보입니다.
- 환경에 따라 Ubuntu를 쓰기도 하고, 가벼운 cirros 이미지를 사용하기도 합니다.
Flavor
- 서버의 스펙을 결정하는 값입니다.
- CPU, 메모리, 디스크와 같은 자원 크기를 정의하며, n1.nano는 1 vCPU, 512mb RAM 입니다.

7. tox 실행해보기

여기까지 실행이 잘 되었다면,
마지막으로 tox를 실행해 현재 소스 기준에서 테스트가 정상적으로 수행되는지도 확인해볼 수 있습니다.

tox는 OpenStack 프로젝트에서 자주 사용하는 테스트 실행 도구이므로,
코드를 읽거나 수정해보기에 유용합니다.

# tox 설치
python3 -m pip install tox

# tox 실행
tox

이 과정을 마치면 설치만 해보는 수준을 넘어,
python-openstackclient 소스 코드를 직접 실행하고,
원격 OpenStack 환경에 인증해 실제 CLI 명령이 어떻게 동작하는지 확인할 수 있습니다.

즉, 이미 구성된 OpenStack 환경이 있다면,

openstackclient는 OpenStack의 동작을 가볍게 확인해보고,

소스 수준에서 흐름을 따라가기에 꽤 좋은 출발점이 됩니다.