YG Tech Blog

AI 모델을 개발하다 보면“어디에 저장해두었더라?”,“어떤 버전이 서비스 중이지?”,“팀원이 돌린 결과랑 내 결과랑 뭐가 다르지?“와 같은 질문이 반복됩니다. 이러한 문제를 해결하기 위해 등장한 것이Web-based Model Platform, 즉 웹 기반의 모델 저장소 및 협업 도구입니다. ✅ 왜 필요한가?필요성설명중앙 집중 관리모든 모델, 실험, 로그를 한 곳에서 관리협업 지원팀원 간 공유, 리뷰, 비교가 용이서빙 연계모델 버전 → API 배포까지 연결 가능모델 자산화조직 내 모델을 자산처럼 보관/활용접근 통제 및 기록누구나 언제, 어떤 모델을 썼는지 추적 가능 ✅ 주요 기능기능설명모델 업로드/다운로드.pt, .onnx, .ckpt 등 형식 지원버전 관리모델별 버전 구분 및 롤백 지원메타데이터 기록학..

GPU, 메모리, 스케줄링까지 하나씩 정리해왔지만,AI 인프라가 실전에서 제대로 쓰이기 위해서는 단순한 리소스 관리뿐 아니라,**“전체 흐름을 자동으로 제어하고 운영할 수 있는 체계”**가 필요합니다. 바로 그 체계를 설명하는 두 개념이 오늘의 주제, AIOps와 MLOps입니다. ✅ AIOps란? AIOps(Artificial Intelligence for IT Operations)는AI를 활용하여 인프라 운영(Ops) 전반을 자동화하고 최적화하는 전략입니다. 즉, 단순 모니터링 수준을 넘어서,장애 예측, 이상 감지, 자동 복구 등을 AI 기반 로직으로 수행합니다. 로그/메트릭/이벤트를 수집하여이상 징후를 탐지하거나,장애 발생 전에 조치를 취하거나,지속적인 개선을 위한 인사이트를 제공 대표 기능: 이상..

이번 글에서는 실제 환경에서 어떤 플랫폼을 선택해야 하는지,운영 환경, 인력 구성, 학습 형태, 인프라 유형 등의 관점에서 정리해보겠습니다. 🧩 핵심 비교 요약항목SlurmKubernetes설계 철학HPC용 정적 자원 최적화클라우드 네이티브 자동화주요 사용 사례과학/공학 시뮬레이션, 연구용 대규모 연산ML 실험, 배포, 추론, 서빙컨테이너 기반선택적 (Pyxis 필요)필수 (Docker, OCI)GPU 스케줄링GRES 기반 수동 설정GPU Operator + 오토스케일링분산 학습 지원MPI 기반, 높은 제어력Kubeflow, Ray, Operator 기반파이프라인 구성외부 스크립트 연동 필요Argo, Kubeflow Pipelines 등 통합 지원자동화 및 확장성낮음 (고정 노드 기반)높음 (클러스..

👋 왜 이 주제가 중요한가? 머신러닝 워크로드가 커지고 복잡해질수록, 단순히 학습 스크립트를 실행하는 것만으로는 부족해집니다.대규모 모델 학습 환경을 안정적으로 운영하려면 다음과 같은 기능들이 오케스트레이션 플랫폼 레벨에서 기본적으로 제공되어야 합니다: 자동화 (Automation)스케일링 (Scaling)모니터링 및 관찰성 (Observability) 이번 글에서는 Slurm과 Kubernetes가 이러한 요구사항에 어떻게 대응하는지 비교해보겠습니다. 🔁 1. 자동화 – 반복 작업을 줄이고 일관성 확보하기 ✅ Kubernetes: 자동화를 위한 도구 생태계 Manifest(YAML) 기반 선언형 인프라Helm, ArgoCD 등과 연계하여 GitOps 자동 배포 가능Kubeflow, MLflow ..

👋 이 글의 목적 대규모 ML 모델을 학습하는 과정에서 가장 중요한 요소 중 하나는 **“장애 대응”과 “비용 최적화”**입니다.GPU 서버는 값비싸고, 또 종종 예기치 않게 실패하며, 한번 실패하면 모든 학습 결과가 날아갈 수 있습니다. 이번 글에서는 Slurm과 Kubernetes가 이런 상황에서 어떻게 다르게 접근하고, 어떤 구조가 어떤 문제에 더 유리한지 비교해봅니다. 💥 GPU 서버는 왜 자주 실패하는가? 📌 이유 1: GPU 밀집형 서버 구조 일반적인 GPU 서버는 1대당 4~8개의 GPU를 탑재합니다.이는 곧 하나의 하드웨어 장애가 여러 GPU를 동시에 무력화시킬 수 있음을 의미합니다. 📌 이유 2: 장시간 고부하 연산 대규모 모델 학습은 보통 수 시간에서 수 일에 걸쳐 실행됩니..

🧠 왜 오케스트레이션이 중요한가? 대규모 ML 학습은 단순히 하나의 스크립트를 실행하는 문제가 아닙니다. 다음과 같은 요소들이 복합적으로 얽혀 있습니다: 수십 개의 GPU 자원 스케줄링분산 학습을 위한 노드 간 통신체크포인팅과 장애 대응클러스터 자원의 모니터링 및 자동화리소스 낭비 없이 고성능을 끌어내는 최적화 이러한 요구사항을 수작업으로 관리하는 것은 사실상 불가능하며,결국 자동화된 오케스트레이션 플랫폼 없이는 효율적이고 신뢰성 있는 ML 운영이 어려워집니다. 🧩 Slurm vs Kubernetes – 개요 🔷 Slurm: HPC의 전통 강자 원래는 슈퍼컴퓨터 및 연구기관의 배치 스케줄러로 시작현재도 Top500 슈퍼컴퓨터의 절반 이상이 Slurm 사용GPU, CPU, 메모리 등 정적인 리소스..

지금까지 우리는 LangChain 기반 RAG 시스템을 구축하며,문서 로딩부터 임베딩, 검색, GPT 응답 생성, 대화 메모리, 요약 전략까지 모두 다뤘습니다.이제는 이 기능들을 하나로 통합하여:📦 운영 가능한 RAG API 서버 구성🐳 Docker로 컨테이너화🧪 개발 → 운영 환경 이관을 위한 설정 전략까지 정리합니다.실무 배포를 고려한 구조로, 팀에서 공유 가능한 RAG 플랫폼을 구축하는 것이 목표입니다.🎯 목표RAG 서버 기능 통합 및 구조 정리Dockerfile 작성 및 실행운영 환경 배포 전략 (예: 포트 구성, API Key 관리, 볼륨 마운트)🗂️ 전체 프로젝트 구조 (예시)rag-iceberg/├── chroma_db/ # 벡터 DB 저장 ..

지금까지 우리는 사용자 질문을 기반으로적절한 Iceberg 테이블을 선택하고, 해당 문서에서 정보를 검색해GPT가 정답을 생성하는 단발성 RAG 시스템을 구축해왔습니다.하지만 실제 업무에서 사용자가 묻는 방식은 이렇습니다:“상품 목록 알려줘”(이후) “그 중에서 가격이 가장 높은 건 뭐야?”(이후) “그 상품의 고객 리뷰는 있어?”이처럼 대화 흐름이 이어지는 구조에서는이전 질문과 응답이 다음 질문에 영향을 주어야 합니다.이번 글에서는 이러한 흐름을 구현하기 위해ConversationBufferMemory를 기반으로 대화 상태를 유지하는 구조를 설계합니다.🎯 목표LangChain의 Memory 기능을 이해하고 적용질문-응답의 히스토리를 유지한 대화형 RAG 구현다양한 테이블에서 이어지는 질의를 자연스럽게..

이전 글에서는 질문에서 단순한 키워드 기반으로 Iceberg 테이블명을 추출하고,그에 따라 적절한 컬렉션을 자동으로 선택하는 방식을 구현했습니다.하지만 이 방식은 키워드가 명확하게 포함된 경우에만 작동하고,"이 고객이 어떤 상품을 구매했는지 알려줘" 같은 질문은 정확한 테이블 매핑이 어렵습니다.그래서 이번 글에서는:✅ GPT 모델을 활용하여 질문 문맥을 분석하고✅ 어떤 테이블이 가장 적절한지 의사결정(Mapping) 하도록 설계하며✅ 기존 FastAPI API에 이 기능을 통합합니다.이제는 질문에 "products"라는 단어가 없어도,GPT가 "아 이건 products 테이블 질문이군"이라고 판단해서 연결해줍니다.🎯 목표GPT 모델을 활용해 질문 → 테이블명 추론 기능 구현기존 키워드 매칭 방식보다 유..

RAG 시스템이 다양한 Iceberg 테이블을 다루게 되면,단일 벡터 컬렉션에 모든 문서를 저장하는 방식은 검색 정확도와 성능의 한계에 부딪히게 됩니다.예를 들어, products, orders, customers와 같은 테이블이 각각 존재한다면,각 테이블의 문서를 분리 저장하고 질문에 따라 적절한 컬렉션을 자동으로 선택해야 합니다.그래서 이 글에서는:✅ 사용자 질문에서 테이블명을 자동으로 추출하고✅ 해당 테이블에 맞는 Chroma 컬렉션을 자동으로 선택하여✅ 정확하고 빠른 검색이 가능한 RAG 시스템을 구현합니다.이 전략은 문서 수가 많거나 테이블이 10개 이상인 데이터 플랫폼에서 매우 유용합니다.🎯 목표사용자 질문에서 Iceberg 테이블명을 추출하는 로직 구현테이블별 벡터 컬렉션을 자동으로 선택하..