Cloud Architecture: To Be Organized

0.1 프로젝트 개요

과제명: AI Agent 기반 지능형 기술 지식 플랫폼 구축

0.1.1 문제 배경

• 지식 파편화(사일로화), 정보 탐색 비효율, 인력 이탈로 인한 업무 병목
• 암묵지 의존으로 인수인계 부하 및 기술 부채 증가

0.1.2 3가지 핵심 개발 목표

#	기능	지표
1	지식 QnA Chatbot - 기존 문서 행간 해석 AI	데이터 표준화 원칙 100% 명시화
2	데이터 표준화 도우미 Agent - 메타데이터 자동화	물리명/설명/데이터타입 3종 추천
3	인실리코 알고리즘 분석 Agent - 코드 투명성 확보	인실리코 코드 분석 100% 커버

0.1.3 시스템 아키텍처

[FE] → [LB] → [Backend/Java] → [AI Engine (K8s/Docker)]
                                        ↓
                              RAG (FastAPI)
                              ├── Azure OpenAI Embeddings
                              ├── Azure Document Intelligence (문서 파싱)
                              ├── Vector Store (Azure AI Search)
                              ├── Rule-Based Engine (AST/CFG Parser 등)
                              └── Data-Driven Engine (DL/ML 모델)
                                        ↓
                              LLM (Azure OpenAI, OpenAI, HuggingFace 등)
                                        ↓
                              Data Storage (SQL DW, MySQL, Data Lake)

[Monitoring] Azure Monitor + Log Analytics + Cost Management

0.1.4 현재 워크스페이스와의 연관성

이 아키텍처의 Streamlit 기반 프로토타입으로 독립적으로 개발하고 후에 추상화하여 통합할 예정: - 1_QnA_Chatbot.py → 목표 1 (지식 QnA) - 2_Data_Standardizer.py → 목표 2 (데이터 표준화 Agent) - 3_Code_Analyzer.py → 목표 3 (인실리코 분석 Agent)

0.2 과제 규모 추정

중대형 엔터프라이즈 AI 프로젝트 (6~18개월, 팀 5~10명 수준)

0.2.1 개발 범위

• 3개 AI Agent (QnA Chatbot, 데이터 표준화, 코드 분석)
• Full-Stack: FE + Java Backend + AI Engine(Python) + Data Pipeline
• 현재 프로토타입 → 프로덕션 전환 수준의 작업

0.3 필요 인프라

0.3.1 Azure 핵심 서비스

서비스	용도	예상 티어
Azure OpenAI	LLM + Embeddings (text-embedding-3-large)	PTU 또는 Standard
Azure AI Search	Vector Store (RAG 근거 검색)	Standard S1+
Azure Document Intelligence	PDF/문서 파싱	S0+
Azure Kubernetes Service (AKS)	AI Engine 컨테이너 오케스트레이션	Standard B/D 시리즈
Azure Container Registry	Docker 이미지 관리	Basic/Standard
Azure SQL / Synapse	Data Warehouse	General Purpose
Azure Data Lake Storage	비정형 데이터 저장	Gen2
Azure Monitor + Log Analytics	모니터링	Pay-as-you-go
Azure Cost Management	비용 추적	무료

0.3.2 추가 인프라

Apache Airflow       - 데이터 파이프라인 오케스트레이션
Load Balancer        - 트래픽 분산 (Azure Application Gateway)
Java Backend         - Spring Boot 기반 API Gateway
FastAPI              - AI Engine REST API
MySQL                - 운영 DB (메타데이터 등)

0.4 리소스 요구사항

0.4.1 컴퓨팅 (AKS 기준)

컴포넌트	스펙	이유
AI Engine Pod	CPU 4코어 / 16GB RAM	FastAPI + RAG 처리
Rule-Based Engine	CPU 8코어 / 32GB RAM	메타데이터 파싱 부하
Data-Driven Engine	GPU (A100/T4)	DL 모델 추론
Backend (Java)	CPU 2코어 / 8GB RAM	API 처리

0.4.2 비용 추정 (월간, Azure Korea 기준)

Azure OpenAI (GPT-4o)       ~$500~2,000  (사용량에 따라 변동)
Azure AI Search (S1)        ~$250
AKS 클러스터                ~$300~800
Azure SQL / ADLS             ~$200
Document Intelligence        ~$150
기타 (모니터링, 네트워크 등) ~$200
─────────────────────────────────────
총계 (추정)                  ~$1,600~3,600/월

0.5 현재 PoC 상태 vs 목표 Gap

항목	현재 (프로토타입)	목표 (프로덕션)
UI	Streamlit	React/Vue FE + Java Backend
배포	로컬	AKS (K8s + Docker)
LLM	단일 Provider	Multi-LLM (OpenAI, HuggingFace 등)
문서 파싱	기본	Azure Document Intelligence
파이프라인	없음	Apache Airflow
모니터링	없음	Azure Monitor + Log Analytics

0.5.1 현재 PoC 상태

(2026-02-20 기준)

src/agent/ ├── app.py ✅ 완성 (메인 진입점, Streamlit multipage) ├── styles.css ✅ 완성 ├── config/ ✅ 완성도 높음 │ ├── settings.py ✅ RAG 실험 설정 전체 구현 (461줄) │ ├── env_loader.py ✅ Azure/Local 환경변수 중앙 관리 │ └── llm_config.py ✅ ├── shared/ ✅ 핵심 인프라 완성 │ ├── llm/provider.py ✅ Azure OpenAI ↔︎ Local(Ollama) 추상화 │ ├── rag/ │ │ ├── chatbot_retriever.py ✅ 문서 로더(PDF/Markdown), 청킹, 검색 (331줄) │ │ └── vectorstore_provider.py ✅ Azure AI Search ↔︎ FAISS 추상화 │ ├── metrics/experiment_metrics.py ✅ RAG 성능 측정 메트릭 구현 (394줄) │ ├── ui/ ❌ 비어있음 │ └── utils/ ❌ 비어있음 ├── pages/ │ ├── 1_QnA_Chatbot.py ✅ 가장 완성도 높음 (1306줄) - RAG 완전 구현 (추상화 전) │ ├── 2_Data_Standardizer.py ❌ UI 껍데기만 (분석 기능 미구현) │ └── 3_Code_Analyzer.py ❌ UI 껍데기만 (분석 기능 미구현) ├── agent_qna_chatbot/ │ └── modules/ │ └── docstring-generator.py ❌ 빈 파일 ├── prompts/ ✅ │ ├── chatbot_data_standardization_rules.yml ✅ │ ├── data_standardizer.yml ✅ │ └── code_analyzer.yml ✅ └── tests/ ❌ init.py만 존재 (테스트 없음)

0.5.2 기능별 완성도

기능	완성도	상태
인프라 (LLM/VectorStore 추상화)	90%	Azure/Local 전환 가능, 잘 설계됨
QnA Chatbot (Page 1)	70%	RAG 동작, 실험 메트릭 수집, 문서 선택 UI
데이터 표준화 (Page 2)	5%	UI 껍데기만, 로직 전무
코드 분석기 (Page 3)	5%	UI 껍데기만, 로직 전무
Docstring Generator	0%	빈 파일
테스트 코드	0%	없음
shared/ui, shared/utils	0%	없음

0.6 개발 로드맵

원칙	의미
POC 우선	추상화는 나중에, 지금은 기능 검증
계약 기반 확장	Phase 2 계약대로 agent를 찍어냄
Multi-repo Monolithic	repo는 분리, 각 repo 내부는 monolithic
Sub-agent 허용	main agent 아래 evaluator/helper 다수 가능
오버스펙 방지	실제 필요한 것만 공통화

0.6.1 Phase 1 - POC (현재 ~ 3개월)

• 3개 Agent 독립적으로 개발 (공유 의존성 최소화)
• 공유 자원: Streamlit UI만
• 목표: 기능 검증, 오버스펙 방지

pages/              ← UI만 공유
├── 1_QnA_Chatbot    ← 독립 POC
|   └── sub-agents (evaluator, helper 등)
├── 2_Data_Std       ← 독립 POC
|   └── sub-agents (evaluator, helper 등)  
└── 3_Code_Analyzer  ← 독립 POC
    └── sub-agents (evaluator, helper 등)

0.6.2 Phase 2 - 추상화 (POC 결과 기반)

• 3개 POC에서 실제로 반복된 패턴만 공통 모듈로 추출
• Agent 생애주기(lifecycle) 계약 정의
• 성능 평가 지표 표준화

contract/
├── BaseAgent         ← 모든 Agent가 따르는 계약
├── AgentLifecycle    ← 공통 생애주기
└── EvalMetrics       ← 공통 성능 평가

0.6.3 Phase 3 - Multi-Repo Monolithic 확장

repo: agent-qna/          ← Main Agent 1
  └── sub-agents/
      ├── retriever-agent
      ├── reranker-agent
      └── evaluator-agent

repo: agent-data-std/     ← Main Agent 2
  └── sub-agents/
      └── validator-agent

repo: agent-code-analyzer/ ← Main Agent 3
  └── sub-agents/
      ├── ast-agent
      └── docstring-agent

repo: agent-commons/      ← Phase 2에서 추출한 공통 계약/모듈

0.7 현재 PoC기준 Azure 자원 이용 현황

0.7.1 Resource Group:

rg-aipoc-test-krc-001 (테스트 구독)

0.7.1.1 구축된 리소스 전체 목록

리소스명	타입	리전	용도
test-agent	VM (D8as v5)	Korea Central	Streamlit 앱 실행 서버
aipoc-code-analyzer-krc-001	Azure OpenAI	Korea Central	LLM (주)
aipoc-code-analyzer-krc-002	Azure OpenAI	Sweden Central	LLM (백업/분산)
aipoc-code-analyzer-krc-003	Azure OpenAI	East US	LLM (백업/분산)
di-aipoc-test-krc-001	Document Intelligence	Korea Central	문서 파싱
vdb-aipoc-test-krc-001	Search service	Korea Central	Vector DB (Azure AI Search)
saaipoctestkrc001	Storage account	Korea Central	파일 저장
privatelink.openai.azure.com	Private DNS zone	Global	OpenAI Private 통신
pe-aipoc-code-analyzer-krc-001	Private endpoint	Korea Central	OpenAI 보안 접속
pe-aipoc-code-analyzer-krc-003	Private endpoint	East US	OpenAI 보안 접속
vnet-aipoc-test-krc-insilico-001	Virtual network	Korea Central	주 네트워크
vnet01~vnet01-4	Virtual networks	다중 리전	리전간 네트워크 피어링

0.7.2 아키텍처

인터넷
  │
  ▼
[VM: test-agent]  Public IP: 20.196.144.16
  │  (Ubuntu 24.04, 8vCPU/32GB)
  │  → Streamlit 앱 구동
  │
  └── Private Network (172.16.0.4)
        │
        ├── [Private Endpoint] → Azure OpenAI (KRC)  ← 주 LLM
        │                      → Azure OpenAI (EUS)  ← 분산 (특정 LLM의 배포유형이 서비스 지역에 따라 배포 제한이 있음)
        │                      (Sweden는 Public 접속)
        │
        ├── [Azure AI Search]   → Vector DB (RAG용)
        ├── [Document Intelligence] → 문서 파싱
        └── [Storage Account]   → 파일/데이터 저장

0.7.3 핵심 포인트 설명

1. Azure OpenAI를 3개 리전에 배포한 이유 - Azure OpenAI는 리전별 TPM(분당 토큰) 쿼터 제한이 있는 것으로 파악됨 - Korea Central 할당량이 부족하거나 너무 지연시간이 길면 Sweden/East US로 분산 - provider.py의 LLM_PROVIDER 환경변수로 전환 가능하게 설계할 것

2. Private Endpoint를 쓰는 이유 - Azure OpenAI를 인터넷 노출 없이 VM → Private IP로 직접 통신 - privatelink.openai.azure.com DNS zone이 이를 내부 라우팅 처리 - 보안 강화 + 네트워크 트래픽 비용 절감

3. VM 스펙 (D8as v5: 8vCPU/32GB) - Streamlit + RAG 파이프라인 동시 처리에 충분한 스펙 - GPU는 없음 → 현재는 Azure OpenAI API 호출만, 로컬 모델 추론은 불가

0.7.4 POC 관점에서 이 인프라 평가

항목	평가
LLM 다중화	✅ 3리전으로 쿼터 문제 대비
보안	✅ Private Endpoint 적용
VM 스펙	✅ POC에 충분
Vector DB	✅ Azure AI Search 준비 완료
문서 파싱	✅ Document Intelligence 준비 완료
GPU	❌ 없음 (로컬 모델 불가, API 전용)
K8s/AKS	❌ 없음 (향후 필요)

0.8 워크샵 내용

0.8.1 현재 PoC 공유할 상황

프로젝트: AI Agent 기반 지능형 기술 지식 시스템
단계:     Phase 1 POC 
팀:       소규모 (Seegene, Core개발팀)

[예정]
- Streamlit 기반 멀티페이지 앱
- LLM Provider 추상화 (Azure ↔ Local 전환)
- RAG 파이프라인 (QnA Chatbot, Azure AI Search + FAISS)
- Data Standardizer: 미구현
- Code Analyzer: 미구현
- Azure OpenAI 다중 리전 fallback 로직 구현 예정
- Storage Account 연동 로직 구체화

[목표]
- 추상화 후 Multi-repo 확장

0.8.2 현재 Azure 자원 이용도 현황

리소스	이용도	진단
VM (test-agent)	✅ 적극 사용	Streamlit 앱 구동
Azure OpenAI (KRC-001)	✅ 주력 사용	LLM + Embedding 모두 이 엔드포인트
Azure OpenAI (KRC-002, 003)	⚠️ 준비만 됨	다중화 목적이나 코드에 fallback 로직 구현 예정
Azure AI Search	✅ 주력 사용	vectorstore_provider에 연결됨. 실제 인덱스 운영 예정
Document Intelligence	❌ 미사용	필요시 사용
Storage Account	✅ 사용	주기적으로 사용 예정
Private Endpoint/DNS	✅ 인프라 구성	보안 통신 설정됨
VNet 다중구성	⚠️ 과잉 구성	vnet01~4 (4개 리전) - 네트워킹 개념 스터디 필요

0.8.3 Azure 활용 아키텍처

• 방향성 및 보완 사항 검토 요청
  • 모든 Agent가 동일한 Azure OpenAI 엔드포인트를 호출
    
  • 모든 Agent가 Azure AI Search를 공유 (인덱스 이름으로 논리 격리)
    
  • 모든 Agent의 성능 로그가 동일한 Monitor/App Insights로 수집
    
• Agent별 리소스 격리 전략과 쿼터 관리에 대한 질문하기
  • 후에 Agent가 늘어날수록 공유 리소스의 쿼터 경쟁과 인덱스 충돌이 생길 수 있을까?

[각 Agent Repo]
      │
      ▼
[Azure API Management]   ← 인증, 라우팅, 쿼터 관리, 버전 관리
      │
      ├── Agent 1 (Container Apps)──┐  ┌── [공유] Azure OpenAI (다중 리전 LB)
      ├── Agent 2 (Container Apps)──┤──├── [공유] Azure AI Search 
      └── Agent 3 (Container Apps)──┘  └── [공유] Azure Monitor + App Insights    
                                          
                              │
                              ▼
                    [대시보딩 (Grafana, Power BI, etc.)]
                    (Agent별 성능 비교)

0.9 질문 리스트

0.9.1 상황 설명 (워크샵에서 먼저 전달할 컨텍스트)

• “3개의 AI Agent POC를 단일 Streamlit 앱으로 개발하려합니다. 이후 각 Agent를 독립 repository로 분리하고, 새로운 도메인이 생길 때마다 동일한 계약 기반으로 Agent를 계속 추가하고 싶습니다. 각 Agent는 sub-agent를 가질 수 있고, 모든 Agent의 성능(RAG 품질, 응답시간, 토큰 비용 등)을 중앙에서 관리하고 싶습니다. 이런 ’Agent 플랫폼’을 Azure에서 어떻게 설계해야 하는지 자문을 받고 싶습니다.”

• “3개의 AI Agent POC를 Azure OpenAI + AI Search 로 구축 예정이며, 인프라는 준비됐지만 코드와의 연결은 진행중에 있습니다. 오늘 가장 확인하고 싶은 건 다중 리전 OpenAI fallback 전략, Document Intelligence 도입 가치, 현재 VNet 비용 최적화 3가지입니다.”

0.9.2 아키텍처 결정에 영향이 있는 질문

Q0. Azure RAG 생성 서비스

Azure AI Search - Integrated Vectorization: 문서를 업로드하면 청킹 → 임베딩 → 인덱싱을 자동으로 처리한다.

# 지금 vectorstore_provider.py에서 직접 하는 작업을 Azure가 대신 해주는 것
[Storage Account에 PDF 업로드]
    │
    ▼
[Indexer 자동 실행]
    ├── Document Intelligence로 파싱
    ├── 청킹 (maximumPageLength 설정)
    ├── Azure OpenAI로 임베딩 생성
    └── AI Search 인덱스에 자동 저장
    
→ 검색 API만 호출하면 RAG 검색 끝

# Azure AI Foundry - Playground / Chat on Your Data

[AI Foundry Portal]
    ├── 파일 업로드
    ├── 모델 선택 (GPT-4o 등)
    ├── AI Search 연결
    └── "배포" 클릭 → REST API 자동 생성

# 배포 구조

[IT팀 - Azure 포털에서 1회 설정]
    └── AI Foundry에서 RAG 챗봇 구성 + 배포 클릭
            │
            ▼
    [REST API Endpoint 자동 생성]
    또는
    [Web App 자동 배포 (Azure App Service)]
            │
            ▼
[BT 사용자 - 그냥 웹 브라우저로 접속]
    └── URL만 알면 됨, Azure 계정 불필요
    
# Managed RAG 한계

| 항목 | Managed RAG | 직접 구현 |
|------|------------|---------|
| 청킹 전략 커스터마이징 | 파라미터 몇 개만 | 완전 자유 (시맨틱 청킹, 문서 구조 인식 등) |
| 재랭킹 로직 | 없음 | Cohere Reranker, Cross-encoder 등 |
| 멀티홉 RAG (질문 분해) | 없음 | LangGraph, AutoGen으로 구현 가능 |
| 하이브리드 파서 (DI + PDFPlumber 혼용) | 불가 | 가능 |
| 비용 제어 | Azure가 결정 | 직접 최적화 |

지금 프로젝트처럼 **복잡한 도면/비정형 문서 + 멀티 Agent + 커스텀 메트릭**이 있으면 Managed RAG는 곧 한계에 부딪힌다. 
Q2(Document Intelligence 선택적 적용)나 Q3(Hybrid Search 튜닝)을 물어보는 것 자체가 이미 Managed RAG의 한계를 넘어서는 요구사항이다.

Azure AI Search - RAG Generation: LLM이 질문을 이해하고 자체적으로 검색 → 요약 → 응답 생성까지 하는 패턴이다. RAG 생성 서비스가 RAG 검색 + LLM 호출을 완전히 추상화해주는 건지, 아니면 여전히 검색과 LLM 호출을 분리해서 직접 구현해야 하는지 궁금합니다. 후자라면, RAG 생성 서비스가 제공하는 이점이 무엇인지도 알고 싶습니다.

Q1. Azure OpenAI 다중 리전 전략 > “Korea Central, Sweden Central, East US에 OpenAI 인스턴스를 3개 배포했습니다. LLM의 Deployment Type이 특정 Region에 제한을 받는 것이 파악되었고, 쿼터 초과 시 자동 failover 하려면 Provider 또는 LangChain 레벨에서 직접 구현해야 하나요, 아니면 Azure API Management나 다른 managed 방법이 있나요?”

API Key per Agent 분리 방법 & APIM 쿼터 할당 전략 관련 질문은 나중에:

APIM (Azure API Management): API 앞단에서 인증, 라우팅, 제한, 모니터링을 통합 관리하는 게이트웨이 서비스
  └── 인증, 라우팅, 버전 관리, 쿼터 관리 등 API 게이트웨이 기능 제공
  └── Agent별로 별도의 API Key 발급 → 쿼터 할당 → 모니터링 가능
  └── 백엔드 API마다 인증 코드를 따로 짜지 않아도 된다

클라이언트
    │
    ▼
[APIM]  ← 여기서 다 처리
    ├── 인증: API Key / OAuth / JWT 검증
    ├── Rate Limiting: 분당 100회 초과 차단
    ├── 라우팅: /agent1/* → Agent1 서버로
    ├── 변환: 요청/응답 헤더 수정
    └── 로깅: 모든 호출 기록
    │
    ▼
[실제 백엔드 API들]
    ├── Agent 1
    ├── Agent 2
    └── Agent 3


AI Gateway: APIM을 Azure OpenAI 전용으로 특화한 패턴(또는 기능)이다. 별도 서비스가 아니라 APIM 위에 구성하는 정책 조합이다.

[APIM + AI Gateway 정책]
    ├── 다중 OpenAI 엔드포인트 로드밸런싱
    │     KRC → SWE → EUS 순으로 자동 failover
    ├── 토큰 사용량 추적 (TPM 모니터링)
    ├── 모델별 Rate Limiting (GPT-4o는 엄격하게, mini는 느슨하게)
    └── 응답 캐싱 (동일 질문 반복 시 비용 절감)

Phase 1 PoC (지금): provider.py에서 직접 fallback 구현
Phase 3 (Agent 플랫폼화): APIM으로 다중 OpenAI 엔드포인트 관리

| 규모/상황 | 선택 | 이유 |
|----------|------|------|
| 스타트업 / PoC | 직접 구현 (`provider.py`류) | APIM 월 ~$200+ 고정비 부담, 오버스펙 |
| 중견기업 (API 10개+) | APIM | 인증/로깅 중앙화 비용이 직접 구현보다 낮아짐 |
| 대기업 / 금융 | APIM + 자체 게이트웨이 병행 | 규정 준수(감사 로그) 때문에 APIM 필수 |
| Azure 헤비유저 | APIM | Azure 생태계 통합(Monitor, AD, DevOps)이 자연스러움 |
| AWS/GCP 멀티클라우드 | Kong / AWS API GW | 벤더 종속 회피 |

가장 대중적인 관리 패턴 

* 소규모 ~ PoC:     직접 구현 (FastAPI 미들웨어, LangChain 콜백)
* 중규모 Azure:     APIM (AI Gateway 정책 포함)
* 대규모 멀티클라우드: Kong 또는 자체 Envoy 기반 서비스 메시

Azure 전용으로 간다면 APIM이 사실상 표준이고, **"직접 구현 → APIM 이관"** 순서가 가장 흔한 경로다. 
지금 `provider.py`로 시작해서 Phase 3에 APIM으로 올리는 계획이 업계 관행과 정확히 일치한다.

Q2. Document Intelligence vs LangChain PDFPlumber > “DI(Document Intelligence)가 비정형 이미지나 복잡한 도면에서는 성능이 떨어지거나 이용성 면에서 적절치 않다고 판단했습니다. DI가 어떤 문서 유형(1개의 노드에 수십개의 복잡한 엣지가 연결된 지식그래프, 수많은 그림이 포함된 문서처럼 사용되는 엑셀파일, 계약서, 표 중심 문서, 반정형 보고서 등)에서 실질적인 이점이 있나요? 그리고 DI를 선택적으로 적용할 때 문서 타입을 사전 분류하는 전략(문서가 들어왔을 때 DI로 보낼지 말지를 먼저 판단하는 로직)을 어떻게 설계하면 좋을까요?”

예를 들면:

문서 입력
    │
    ▼
[사전 분류기]
    │
    ├── "이건 표 중심 문서다"      → DI로 처리
    ├── "이건 텍스트 중심 PDF다"   → PDFPlumber로 처리
    ├── "이건 복잡한 도면이다"      → 비전 모델로 처리
    └── "이건 Markdown이다"        → 직접 로드

즉 모든 문서를 DI에 보내는 게 아니라, 먼저 문서 유형을 판별해서 적합한 파서를 선택하자는 의도

분류 기준은: - 파일 확장자 (.pdf, .xlsx, .docx) - 페이지당 이미지 비율 - 텍스트 추출 가능 여부 (텍스트 레이어 존재 여부) - 사용자가 업로드 시 직접 유형 지정

“DI를 무조건 쓰기엔 비용과 성능 이슈가 있으니, Azure 엔지니어들이 실제로 어떤 기준으로 DI 적용 여부를 결정하는지 베스트 프랙티스를 듣고 싶음”

Q3. Azure AI Search Hybrid Search 설정 > “gpt-4.1-mini에서 search_type=similarity를 설정할 경우 RAG의 성능이 저조한 것을 관찰했습니다. search_type=hybrid로 설정하여 성능이 향상되는 것을 확인했는데, 어떤 상황에서 Semantic Ranker(월 $250 추가 과금)를 함께 써야 효과가 극대화되나요? Semantic Ranker는 별도 과금인데 POC 단계에서 활성화할 가치가 있나요?”

0.9.3 인프라/비용 질문

Q4. VM vs Container Apps for Streamlit/REACT > “현재 D8as v5 VM에서 Streamlit을 직접 실행 중입니다. POC 단계에서 Azure Container Apps로 전환하면 비용이나 관리 측면에서 이점이 있나요? 추후 서비스 배포시 (내부 조직 약 100명 규모), AKS로의 마이그레이션 경로도 고려해야 하나요?”

Container Apps: Azure가 내부적으로 K8s 클러스터를 관리해주는 서비스로, 컨테이너 기반 배포의 편의성과 확장성을 제공하지만, VM에 비해 초기 설정과 디버깅이 복잡할 수 있다. AKS는 완전한 K8s 환경을 제공하지만, 운영과 관리가 더 복잡하다.

**결론: 지금 전환할 필요 없다**

[현재 PoC]          [Phase 2 이후]
VM (자유도 우선) →  Container Apps (운영 편의) → AKS (규모 확장 시)

Container Apps는 코드가 안정화되고 Docker로 패키징하는 시점, 즉 **Phase 2 이후**에 고려하는 것이 적절하다. AKS는 Agent가 늘어나고 트래픽 관리가 복잡해지는 Phase 3 시점에 검토하면 된다.

AKS 전환시기: Container Apps로 감당이 안 되는 상황이 생길 때다:

1. GPU가 필요해질 때 (Azure Container Apps가 GPU를 지원하지 않기 때문)
   → 로컬 모델 추론 (Llama, Mistral 등) 도입 시
2. 네트워킹을 세밀하게 제어해야 할 때
   → Agent 간 내부 통신 정책, Istio Service Mesh 등
3. Agent 수가 많아지고 리소스 격리가 복잡해질 때
   → Namespace 분리, Resource Quota, Node Pool 분리
4. 비용 최적화가 중요해질 때
   → Spot Node Pool, 노드 자동 확장 정밀 제어

Phase 1 (지금): VM — 자유롭게 개발, 디버깅
Phase 2 (코드 안정화 후) - Container Apps — Docker 이미지로 배포
Phase 3 (Agent 플랫폼 확장 시) - AKS 검토 — GPU 모델 도입 or 트래픽/격리 요구사항 복잡해질 때

Q5. VNet 구성 최적화 > “현재 네트워킹 지식이 부족해서 azure resource에서 자동 추천되는 옵션을 선택해서 vnet01~vnet01-4까지 4개 리전에 VNet이 만들어졌습니다. POC 목적에서 이 구성이 필요한지 또는 최적화할 수 있는지 검토해주실 수 있나요? 불필요한 비용이 발생하고 있지는 않은지 이해하고 싶습니다.”

검토 포인트: 
Private Endpoint DNS 조회 오버헤드 → 인프라 설정 문제이므로 워크샵에서 확인 가능
VNet 피어링 홉 수 → 불필요한 VNet이 있으면 경로가 늘어날 수 있음 (Q5와 직접 연결)

Q6. Private Endpoint + Streamlit 접속 > “VM은 Public IP로 Streamlit에 접속하고, Azure OpenAI는 Private Endpoint로 통신합니다. 현재 Streamlit에 인증이 없는데, Azure AD 기반 접근 제어를 가볍게 붙이는 방법이 있나요? (Azure Static Web App Auth, App Gateway + OIDC 등)”

개발자         → VM Public IP:8501 → Streamlit (인증 없음)
외부 누구든지  → VM Public IP:8501 → Streamlit (인증 없음) ← 문제
PoC 결과를 팀원이나 stakeholder에게 보여줄 때 "어떻게 접근하게 할 것인가" 와 "아무나 접근하지 못하게 막을 것인가" 
사내 NSG IP white list 를 작성해서 VM public IP를 등록 시키면 충분하지 않을까?

Azure AD까지 갈 것 없이, NSG(네트워크 보안 그룹)에서 회사 IP만 허용하는 것으로 충분하다고 생각
NSG 인바운드 규칙: 포트 8501 (Streamlit) → 회사 공인 IP만 허용

Q7. LLM Latency 질문 > “현재 PoC단계이기 때문에 Korea Central Region을 사용하고 있다. 그런데, 개인적으로 다른 용도로 OpenAI에서 api key를 받아 직접 LLM을 연결할떄는 latency가 azure openai에 비해 적은 것을 체감했습니다. 실제로 그런 이유가 있나 아니면 저의 개인적인 느낌일까요?” latency가 긴 이유가 있다면 다음의 원인 때문일까요? - 직접 OpenAI API: 개인 PC → OpenAI CDN (전세계 분산) → 가장 가까운 서버 선택됨 - Azure OpenAI: 개인 PC → Azure 리전 (Korea Central) → Azure 내부 → OpenAI 모델 - Private Endpoint 추가 경유: VM → VNet → Private DNS 조회 및 Internal Routing → Private Endpoint → Azure OpenAI - Azure 내부 안전장치 레이어: Content Filtering & Responsible AI 정책 검토

맞다면 어떻게 개선해야할까요?

0.9.4 향후 플랫폼화 대비 질문

Q7. Multi-repo Monolithic Agent 아키텍처에서의 Azure 전략 (리소스 격리 설계 전반”에 대한 질문) > “추후 3개의 Main Agent들을 독립 repository로 Agent를 분리하고, 각 Repository에 sub-agents를 다수 만들 계획입니다. 각 Agent가 동일한 Azure AI Search와 Azure OpenAI를 공유할 예정인데 리소스 격리(인덱스 네이밍 규칙, API Key 분리 등)를 어떻게 설계하는 게 베스트 프랙티스인가요?”

"현재 1개의 Azure AI Search 인스턴스에서 3개 Agent가 인덱스를 공유하려 합니다.
인덱스를 Agent별로 분리(agent-qna-idx, agent-std-idx)하는 게 나은지,
단일 인덱스에 필드로 구분하는 게 나은지 — PoC 단계 기준 권장 방향이 뭔가요?"

Q8. Azure AI Foundry / AI Studio 활용 > “실험 메트릭을 자체 코드기반 로그 데이터로 수집하려 하는데, Azure AI Foundry의 Evaluation 기능이 RAG 성능 평가에 도움이 될 수 있나요? Prompt Flow와의 통합도 고려해야 할까요?”

Azure Prompt Flow는 LLM 기반 애플리케이션의 프롬프트 → 검색 → 후처리 흐름을 시각적으로 설계·테스트·배포하는 MLOps 도구

입력(Query)
    │
    ▼
[Flow 설계]              
    ├── 노드 1: 임베딩 생성 (Azure OpenAI)
    ├── 노드 2: 벡터 검색 (Azure AI Search)
    ├── 노드 3: 프롬프트 조합
    └── 노드 4: LLM 호출 → 출력
    │
[Evaluation]             ← RAG 품질 평가 (groundedness, relevance, coherence 점수)
    │                       자체 eval 데이터셋 업로드 → 자동 채점
[Variants / A/B Test]    ← 프롬프트 버전 비교 실험 (동일 입력, 다른 시스템 프롬프트)
    │
[Tracing / Monitoring]   ← 각 노드별 latency, 토큰 사용량, 실패율 추적
    │
[Deployment]             ← Azure ML Online Endpoint로 Flow 자체를 API화

* multi-agent orchestration 기능 없음
* node 내 python 코드 작업이 허용되어 있나?

Q9. 비용 최적화 > “GPT-4.1, GPT-5-mini 등 최신 모델 deployment가 설정에 있는데, POC에서 비용 대비 성능이 가장 좋은 모델 선택 기준을 조언해주실 수 있나요? PTU(Provisioned Throughput) 전환 시점은 언제가 적절한가요?”

타입	설명	속도	비용
Standard	리전 내 공유 인프라. TPM 쿼터 상한 있음	보통 (쿼터 소진 시 429 에러)	토큰당 과금
Global Standard	MS가 전세계 여유 용량으로 자동 라우팅	빠름 (여유 용량 우선 사용)	Standard와 동일하거나 저렴
Provisioned (PTU)	전용 용량 예약. 시간당 고정 과금	가장 빠름 + 레이턴시 예측 가능	고정비 (~월 수천$), 사용량 무관
Global Provisioned	PTU를 전세계 분산 운영	PTU와 동일	PTU보다 높음
Data Zone Standard	EU 또는 US 데이터존 내에서만 라우팅	Standard와 유사	Standard와 유사

현재 KRC-001 (Private Endpoint) → Standard 타입만 가능 └── Private Endpoint는 리전 고정이므로 Global Standard 사용 불가

Sweden (Public) → Global Standard 사용 가능 └── GPT-4.1 등 최신 모델이 KRC Standard에 없을 때 Sweden Global Standard로 해결

Standard 월 비용 > PTU 고정비  → PTU 전환 검토
                        ↑
             대략 월 $3,000 이상 토큰 비용 발생 시점

PoC 단계에서는 Standard로 충분하고, 내부 100명 규모 서비스로 전환 시 토큰 사용량 측정 후 결정하면 된다.

TPM (Tokens Per Minute): 1분 동안 처리할 수 있는 토큰 수 한도다.
토큰 = 텍스트를 쪼갠 단위
"안녕하세요" ≈ 3~5 토큰
GPT-4o 1회 호출 ≈ 입력 500 + 출력 200 = 700 토큰 소모
TPM이 10,000이면 → 1분에 약 700토큰짜리 요청을 14번밖에 못 한다.

쿼터 (Quota): Azure가 리전별로 각 계정에 할당한 **TPM 상한선**

Azure OpenAI Korea Central
  └── 내 계정 할당 쿼터: GPT-4o → 30,000 TPM, GPT-4o-mini → 100,000 TPM
이 한도를 넘으면 `HTTP 429 Too Many Requests` 에러가 발생
리전마다 쿼터가 다른 이유: Azure가 리전별로 GPU 물리 서버 수가 다름
Korea Central은 서버가 적어서 기본 쿼터가 작고, East US는 많아서 크다.
- Korea Central: GPT-4o 쿼터 낮음 → 빠르게 한도 도달
- Sweden Central: 쿼터 높음 + Global Standard 가능 → fallback으로 적합
- East US: 쿼터 높음 + 최신 모델 먼저 배포됨

다른 지역이 TPM 쿼터가 높고 Korea Central이 네트워크 거리상 유리하지만, 실제 체감 속도는 East US나 Sweden이 더 빠를 수 있다. 워크샵에서 실측 latency 비교 데이터를 요청하는 게 가장 확실하다.

0.9.5 세부 질문 5가지

Q1. Agent별 리소스 격리 전략 > “Agent가 늘어날 때 Azure OpenAI, AI Search 인덱스, Storage를 Agent별로 분리해야 할까요, 아니면 공유 리소스에 네이밍 규칙으로 논리적 격리만 해도 충분할까요? 리소스 격리 수준(Resource Group 분리 vs 인덱스 네이밍 분리)의 기준이 뭔가요?”

Q2. 중앙 성능 관리 구조 > “각 Agent의 응답시간, 토큰 사용량, RAG 품질 점수(정확도, 관련성)를 중앙에서 수집하고 비교하려 합니다. Azure Monitor + Log Analytics로 충분한가요, 아니면 Azure AI Foundry의 Evaluation이나 Application Insights를 함께 써야 하나요? Agent별 성능 대시보드를 만들려면 어떤 구성이 권장되나요?”

Q3. Agent 배포 파이프라인 > “Agent마다 독립 repository를 가지는 Multi-repo 구조입니다. 각 Agent를 독립적으로 배포하되, 공통 계약(인터페이스)의 버전은 맞춰야 합니다. Azure DevOps나 GitHub Actions로 이런 구조의 CI/CD를 어떻게 설계하면 좋을까요? 공통 라이브러리 变更 시 downstream Agent 전체를 테스트하는 방법도 궁금합니다.”

Q4. Agent 트래픽 관리 및 확장 > “Agent별로 사용량이 다를 수 있고, 특정 Agent에 트래픽이 몰릴 수 있습니다. Azure API Management를 Agent 앞단에 두고 라우팅, Rate Limiting, 인증을 통합 관리하는 구조가 맞나요? Agent를 Container Apps vs AKS 중 어디서 운영하는 게 이 규모에 적합한가요?”

Q5. Azure OpenAI 쿼터 관리 (멀티 Agent 환경) > “Agent가 늘어나면 Azure OpenAI 쿼터 경쟁이 생깁니다. 현재 3개 리전에 OpenAI 인스턴스가 있는데, Agent별로 쿼터를 할당하거나 우선순위를 두는 방법이 있나요? APIM의 Load Balancing 정책으로 다중 OpenAI 엔드포인트를 관리하는 패턴을 써야 하나요?”

Q6. Azure Managed RAG와 직접 구현 RAG의 공존 전략 > “Azure AI Search의 Integrated Vectorization(Managed RAG)과 자체 구현 RAG를 동일한 AI Search 인덱스에서 혼용할 수 있나요? 또는 Agent 플랫폼에서 단순 Agent는 Managed, 복잡한 Agent는 직접 구현으로 분리 운영하는 게 권장되나요?”

1 정리해야할 사항

LLM Failover 전략 구현 위치: provider.py vs LangChain 레벨

짧게 정리하자면 — 둘 다 가능하지만 책임 구분 때문에 provider.py(인프라/엔드포인트 선택 책임)에 failover를 두는 게 권장됩니다. 이유와 권장 구현 요점은 아래와 같습니다.

• 왜 LangChain에서 묻나: LangChain은 LLM 호출과 재시도/콜백을 쉽게 제어하는 레이어라서 체인(비즈니스 로직) 단에서 재시도·로컬 폴백 정책을 붙이기 편함. 그래서 설계 문서에 LangChain 옵션도 적어둔 것임.
• 권장 아키텍처: 핵심은 중앙화된 엔드포인트/토큰·헬스체크 관리 → provider.py에 담당시킴. LangChain 쪽에는 옵셔널(체인별) 재시도/타임아웃 정책만 둠.
• 이유: 중앙화
  • 인증·프라이빗 엔드포인트 관리 한곳에서 처리
  • 로깅/메트릭/쿼터 제어 일관성 확보
  • 네트워크·리전별 접근성(Private Endpoint) 제어 쉬움
• LangChain의 역할: 호출 레벨에서 짧은 재시도, 체인별 타임아웃·로그 캡처, 사용자 친화적 콜백(모니터링) 제공
• 반드시 고려할 사항: 리전별 API 키/엔드포인트, 헬스체크(주기적), 지연시간 기반 라우팅, 지표(토큰 비용/latency), 세션 일관성(상태 있는 요청 주의)

간단한 provider.py 패턴 (의사코드):

class MultiRegionProvider:
    def __init__(self, endpoints):  # endpoints = [("krc", url, key), ("swe", ...), ...]
        self.endpoints = endpoints
        self.healthy = {e[0]: True for e in endpoints}

    def call(self, payload):
        for region, url, key in ordered_endpoints_by_health_and_latency():
            try:
                return send_request(url, key, payload, timeout=5)
            except (QuotaError, TimeoutError, HTTPError) as e:
                mark_unhealthy(region)
                log_warning(...)
                continue
        raise RuntimeError("All endpoints failed")

권장 단계 (작업 리스트) 1. provider.py에 엔드포인트 리스트 + 헬스체크 구현
2. 실패시 백오프 + circuit-breaker 간단 구현
3. LangChain 설정에는 짧은 재시도/체인 타임아웃만 남김
4. 모니터링(토큰 사용량·latency) 연결

원하면 provider.py용 구체적 코드 패치(테스트 포함)를 작성해 드릴게요. 진행할까요?