docs(drafts): add GPU sharing guide and Dify draft

Author: ppippi-dev

public/img/dify/image-20260107210940555.png

@@ -0,0 +1,141 @@
+---
+# description: 검색 결과 스니펫 (120-160자), 핵심 키워드 + 가치 제안
+# title: 검색 노출 핵심 (50-60자), 키워드 앞쪽 배치
+# tags: 주요 키워드 + 상위 카테고리 + 관련 기술
+description: ''
+pubDate: '2026-01-06'
+tags:
+  -
+title: ''
+---
+
+## TL;DR
+
+> 3~4문장 핵심 결론. 이것만 읽어도 글의 가치를 파악할 수 있게.
+> Featured Snippet 후보이므로 핵심 키워드 포함.
+
+<!-- 도입부: 1~2문단. 이 글을 쓰게 된 배경, 독자가 공감할 문제 상황 -->
+
+최근 Agent에 대한 관심이 많아지면서, 두 갈래로 나눠지는 것 같다.
+
+흔히 말하는 바이브 코딩이란 걸 이용한 코드 기반의 Agent 시스템 구축과, 노코드 기반의 Agent 워크플로우 구축이다. 노코드 툴의 한계는 존재하지만 Agent를 코드 없이 구현한다는 부분에서 진입장벽은 확실히 낮다. 오늘 살펴볼 내용은, 후자인 노코드 툴 [dify](https://github.com/langgenius/dify)이다.
+
+dify는 LangGenius 라는 회사에서 운영중인 오픈소스 플랫폼이다. 
+
+The name Dify comes from **D**o **I**t **F**or **Y**ou. 
+
+![image-20260107210940555](../../../public/img/dify/image-20260107210940555.png)
+
+일단 dify는 다음과 같은 Key features 가 존재한다고 소개한다.
+
+1. workflow: 시각적 캔버스에서 강력한 AI 워크플로를 구축하고 테스트할 수 있따.
+2. Comprehensive model support: GPT, Mistral, Llama3 및 모든 OpenAI API 호환 모델을 포괄하는 수십 개의 추론 제공업체 및 자체 호스팅 솔루션 등 수백 개의 오픈소스 LLM과 원활하게 통합
+3. Prompt IDE: 프롬프트 작성, 모델 성능 비교, TTS과 같은 추가 기능을 채팅 기반 앱에 추가하기 위한 직관적인 인터페이스
+4. RAG Pipeline: PDF, PPT 및 기타 일반적인 문서 형식에서 텍스트 추출, 문서 수집부터 검색까지 포괄적인 RAG
+5. Agent capabilities: LLM 함수 호출 또는 ReAct 기반으로 에이전트를 정의하고 에이전트에 대한 사전 구축된 도구나 사용자 정의 도구 추가
+6. LLMOps: 시간 경과에 따른 애플리케이션 로그와 성능을 모니터링, 이를 통한 생산 데이터와 주석을 기반으로 프롬프트, 데이터세트, 모델을 지속적으로 개선
+7. Backend-as-a-Service: Dify의 모든 제품에는 해당 API가 함께 제공되므로 Dify를 자신의 비지니스 로직에 쉽게 통합
+
+위에 내용들이 실제로 얼마나 유용한지 테스트해보는게 본 글의 목적이다.
+
+
+
+그 전에 Dify에 대해 조금 더 알아보면, 일단, Managed서비스로 Cloud환경과, Self-hosted 옵션이 존재한다.
+
+![image-20260107211713742](../../../public/img/dify/image-20260107211713742.png)
+
+가격 정책은 위의 사진과 같다. 가격은 사실 싼건지 비싼건지 잘 모르겠다. 
+
+
+
+---
+
+dify는 AgentOps를 대체할 수 있는가? 
+
+
+
+https://www.linkedin.com/posts/petrituomola_dify-leading-agentic-workflow-builder-activity-7324263717674590208-drLz?utm_source=share&utm_medium=member_desktop&rcm=ACoAADTtEIgBaRhOOmWcUXTxiIwUPzSj9QrJ4ek
+
+
+
+https://www.reddit.com/r/difyai/comments/1owtwj5/struggling_with_dify_should_i_stick_with_it_or/
+
+
+
+https://skywork.ai/blog/dify-review-2025-workflows-agents-rag-ai-apps/?utm_source=chatgpt.com
+
+
+
+
+
+## **⚠️** 
+
+## **하지만 여전히 남아 있는 한계**
+
+### **🛠 1)** 
+
+### **실질적인 운영·거버넌스 제어는 제한적**
+
+- Dify가 엔터프라이즈용 배포 옵션을 제공하는 건 사실이나,
+
+  *진정한 의미의 운영 정책(토큰 예산, 완전한 RBAC, 실패 정책, SLAs, SLO 적용 등)* 은 문서상 명시적으로 깊게 제공되지는 않음.
+
+  → 기능이 *존재하는 것처럼 보일 수 있으나*, **운영 정책 자동화 레벨은 여전히 낮음**. 
+
+
+
+👉 📌 Enterprise 페이지가 “옵션이 있다”일 뿐, 실제 **정책 거버넌스/운영 자동화까지 완전하진 않음.
+
+
+
+------
+
+
+
+
+
+### **🧪 2)** 
+
+### **운영 모니터링·Metrics가 완전하지 않음**
+
+- observability/logging은 여전히 **사용자 입력/출력 중심 정도**이고,
+
+  *agent/tool 단위 metric 집계, 롤백 트리거, 비용/지연 평가 지표가 실시간으로 정책화되는 수준*은 아님. 
+
+👉 📌 모니터링은 “있다고 말할 수 있으나”,
+
+정책 기반 운영 자동화로 보기엔 제한적.
+
+
+
+------
+
+
+
+
+
+### **📐 3)** 
+
+### **이벤트 기반·Trigger 시스템 제한**
+
+- 최신 릴리즈에서는 **워크플로우 트리거(스케줄/Webhook/SaaS Event)** 지원이 강화되긴 했지만,
+
+  *챗플로우/Agent 자체는 트리거 지원이 아직 제한적*이라고 명시됨. 
+
+👉 📌 이벤트 기반 자동화는 Workflow 중심이고, 전체 Agent 기능이 아니라는 한계.
+
+
+
+------
+
+
+
+
+
+### **📚 4)** 
+
+### **엔터프라이즈 컴플라이언스/보안 스펙 불명확**
+
+- Enterprise 문서에서 보안/접근 컨트롤을 이야기는 하지만 구체적인 **ISO/SOC2 같은 인증 레벨, 감사 로그 수준, 감사 추적 정책** 등은 상세하게 다루어지지 않음. 
+
+👉 📌 보안·규제 준수 요구가 높은 산업에서는 별도 평가가 필요.

public/img/dify/image-20260107211713742.png

@@ -1,25 +1,143 @@
 ---
-description: 설명
-pubDate: '2025-12-19'
+# description: 검색 결과 스니펫 (120-160자), 핵심 키워드 + 가치 제안
+# title: 검색 노출 핵심 (50-60자), 키워드 앞쪽 배치
+# tags: 주요 키워드 + 상위 카테고리 + 관련 기술
+description: ''
+pubDate: '2026-01-06'
 tags:
-- LLMOps
-- MCP
-- Agent
-title: template
+  -
+title: ''
 ---
 
 ## TL;DR
 
-> 요약
+> Kubernetes 환경에서 GPU Sharing은 **Time‑Sharing, MPS, MIG** 세 가지로 나뉜다.  
+> **MIG만이 컨테이너 단위에서 여러 GPU(slices)를 동시에 요청**할 수 있고,  
+> **MPS / Time‑Sharing은 컨테이너당 GPU 요청이 1개로 제한**된다.  
+> 이 제한은 CUDA가 아니라 **Kubernetes 스케줄링 정책** 때문이다.
 
-Intro
+GPU Sharing 방법으로 대표적인 전략은 **Time‑Sharing, MPS, MIG** 세 가지다.  
+이 글에서는 *Kubernetes 기준*으로 각 방식의 **리소스 모델, 제약, 실무에서 헷갈리는 포인트**를 정리한다.
 
-## 소제목
+---
+
+## 왜 GPU Sharing을 쓰는가?
+
+GPU가 충분하다면 굳이 Sharing을 할 필요는 없다.  
+GPU를 분할하거나 공유하면 다음과 같은 비용이 발생한다.
+
+- Context switching / scheduling 오버헤드
+- 메모리 및 연산 자원 간섭
+- 성능 예측성 저하 (특히 latency‑sensitive workload)
+
+그럼에도 GPU Sharing을 사용하는 이유는 다음과 같다.
+
+- 추론(workload)이 가볍고 GPU utilization이 낮은 경우
+- GPU 비용을 최대한 효율적으로 쓰고 싶은 경우
+- 다수의 소형 워크로드를 동시에 실행해야 하는 경우
+
+---
+
+## GPU Time‑Sharing
+
+### 개념
+- **GPU 전체를 여러 워크로드가 시간 분할로 공유**
+- Context switching 기반
+- 하드웨어 파티셔닝 없음
+
+### Kubernetes에서의 동작
+- 여러 파드가 **같은 물리 GPU를 동시에 공유**
+- 하지만 **컨테이너당 GPU 요청은 최대 1개**
+- `nvidia.com/gpu: 2` 같은 요청은 **스케줄러에서 reject**
+
+```yaml
+resources:
+  limits:
+    nvidia.com/gpu: 1  # 허용
+```
+
+### 특징 요약
+- 격리 ❌
+- 성능 예측성 ❌
+- 설정 간단
+- 경량 추론에 적합
+
+---
+
+## NVIDIA MPS (Multi‑Process Service)
+
+### 개념
+- **하나의 물리 GPU를 여러 CUDA 프로세스가 공유**
+- MPS 서버가 CUDA context / kernel 실행을 중재
+- 소프트웨어 레벨 공유 (MIG 아님)
 
-## 장점
+### Kubernetes에서의 핵심 제약
+> **MPS 활성화 노드에서는 컨테이너당 GPU 요청이 1개로 제한됨**
+
+- 여러 파드가 **같은 GPU를 동시에 사용** 가능
+- 하지만 **한 파드가 GPU 2개 이상을 요청하는 것은 불가**
+- `gpu per client = 8` 같은 설정은  
+  → *GPU 개수*가 아니라 **GPU 내부 리소스 비율 제어**
+
+```yaml
+resources:
+  limits:
+    nvidia.com/gpu: 2  # ❌ reject
+```
+
+### 중요한 오해 포인트
+- MPS는 **멀티 GPU 스케줄러가 아니다**
+- Kubernetes가 여러 GPU를 “합쳐서” 한 컨테이너에 주지 않는다
+- 이 제약은 CUDA가 아니라 **Kubernetes 리소스 모델의 정책**
+
+---
+
+## MIG (Multi‑Instance GPU)
+
+### 개념
+- GPU를 **하드웨어 단위로 물리 분할**
+- 각 MIG 인스턴스는:
+  - 독립된 메모리
+  - 독립된 SM
+  - 강한 오류 격리
+
+### Kubernetes에서의 동작
+- MIG 인스턴스는 **독립 GPU 리소스처럼 노출**
+- 하나의 컨테이너가 **여러 MIG slice를 동시에 요청 가능**
+
+```yaml
+resources:
+  limits:
+    nvidia.com/gpu: 3
+```
+
+> 단, **노드에 실제로 존재하는 MIG 인스턴스 수를 초과하면 스케줄 불가**
+
+### 특징 요약
+- 격리 ✅
+- 성능 예측성 ✅
+- 설정/운영 복잡도 높음
+- 안정성이 중요한 워크로드에 적합
+
+---
+
+## 핵심 비교 요약
+
+| 구분 | Time‑Sharing | MPS | MIG |
+|----|----|----|----|
+| 공유 방식 | 시간 분할 | 프로세스 공유 | 하드웨어 분할 |
+| 격리 | ❌ | ❌ | ✅ |
+| 컨테이너당 GPU 요청 | 1개 제한 | 1개 제한 | 여러 개 가능 |
+| 여러 파드 동시 사용 | ✅ | ✅ | ✅ |
+| 성능 예측성 | 낮음 | 낮음 | 높음 |
+| 실무 추천 용도 | 경량 추론 | 경량 추론 | 안정성/멀티 GPU |
+
+---
 
-## 단점
+## 한 문장 요약
 
-## 마무리
+> **Kubernetes에서 GPU Sharing을 쓸 때,  
+> 컨테이너가 여러 GPU를 동시에 가져가야 한다면 선택지는 MIG뿐이다.**
 
-## 참고 링크
+MPS와 Time‑Sharing은 “GPU를 나눠 쓰는 방법”이지  
+“GPU 개수를 늘려주는 방법”이 아니다.

src/content/drafts/dify.md

@@ -1,18 +1,16 @@
 ---
-# description: 검색 결과 스니펫 (120-160자)
-# title: 검색 노출 핵심 (50-60자), 키워드 포함
+# description: 검색 결과 스니펫 (120-160자), 핵심 키워드 + 가치 제안
+# title: 검색 노출 핵심 (50-60자), 키워드 앞쪽 배치
 # tags: 주요 키워드 + 상위 카테고리 + 관련 기술
 description: ''
-pubDate: '2025-12-19'
+pubDate: '2026-01-06'
 tags:
-  - 
+  -
 title: ''
 ---
 
-## 요약
-
-<!-- 본문 첫 단락: 검색엔진이 중요시함. 핵심 내용 + 키워드 자연스럽게 -->
-
 ## TL;DR
 
-<!-- 3-4문장 핵심 결론. 이것만 읽어도 글의 가치 파악 가능하게 -->
+> 3~4문장 핵심 결론. 이것만 읽어도 글의 가치를 파악할 수 있게.
+> Featured Snippet 후보이므로 핵심 키워드 포함.
+