AI Playground 구축 가이드 1

2026.03.24 - [분류 전체보기] - AI Playground 구축 가이드 1

2026.03.24 - [분류 전체보기] - AI Playground 최종 구축 패키지2

2026.03.24 - [분류 전체보기] - AI playground 실제 적용용 파일 세트3

 

 

AI Playground 구축 가이드

1. 목표

이 플랫폼의 목적은 다음과 같습니다.

• 사내에서 LLM Playground 제공
• 프롬프트 실험 / Workflow 실험 / RAG 실험
• 여러 외부 LLM을 하나의 게이트웨이로 통합
• 추적/평가/배포를 쿠버네티스 중심으로 운영

2. 권장 시작 구조

사용자
  → Dify
  → LiteLLM
  → Gemini / OpenAI / Claude

보조 계층
  → PostgreSQL / Redis / OpenSearch
  → Phoenix
  → Argo CD

확장 계층
  → KServe
  → Kubeflow

3. 구성요소 역할

Argo CD

• Git 저장소를 실제 배포 상태로 동기화
• 앱 단위 롤백과 선언형 운영에 적합

LiteLLM

• OpenAI 호환 API로 여러 LLM 제공자 통합
• 모델 라우팅, fallback, 비용/로그 통합에 유리

Dify

• 비개발자도 Playground, Agent, Workflow, RAG 앱을 빠르게 만들 수 있는 UI 중심 플랫폼

Phoenix

• 프롬프트/응답/trace/평가 시각화
• LLM 관측성과 디버깅에 적합

KServe

• 모델을 InferenceService 형태로 운영
• 추론 API, autoscaling, 생성형 AI 서빙 확장에 적합

Kubeflow

• Notebook, Pipeline, 학습 워크플로, MLOps 확장
• 다만 초기 도입 난이도가 높음

4. 운영 추천 방식

먼저 구축할 것

• kubeadm 기반 Kubernetes
• Argo CD
• LiteLLM
• Dify
• OpenSearch/PostgreSQL/Redis
• Phoenix

나중에 붙일 것

• KServe
• Kubeflow 전체 플랫폼

5. 사용 흐름 예시

Playground 실험

1. 사용자가 Dify Playground 접속
2. 모델 Provider를 LiteLLM endpoint로 지정
3. LiteLLM이 Gemini 등 외부 모델에 프록시 호출
4. 응답 결과를 Phoenix로 trace 수집
5. Argo CD는 관련 설정을 GitOps로 관리

RAG 실험

1. Dify에 Knowledge 업로드
2. OpenSearch/외부 벡터 저장소와 연동
3. LiteLLM을 통해 생성 모델 호출
4. Phoenix로 품질/trace 확인

모델 서빙 확장

1. KServe에 모델 배포
2. 내부 inference endpoint 생성
3. LiteLLM 또는 Dify에서 내부 모델 endpoint 사용

6. 주의사항

• full Kubeflow와 standalone KServe는 설치 경로가 겹칠 수 있어 설계 결정이 먼저 필요
• Dify의 K8s 배포는 공식 본체보다 커뮤니티 Helm/YAML 의존성이 큼
• Phoenix는 VPC 내부 운영 또는 auth 설정을 추가하는 편이 안전
• LiteLLM API 키는 Secret/Vault로 관리해야 함

7. 추천 최종안

AI Playground 1차 버전

• Kubernetes 1.35
• Argo CD
• LiteLLM
• Dify
• PostgreSQL / Redis / OpenSearch
• Phoenix

AI Playground 2차 버전

• 위 구성 + KServe

AI Playground 3차 버전

• 위 구성 + Kubeflow