송재욱 (MLOps)

전국 중·고등학교 대상 스포츠 행사 플랫폼. 수기 신청서와 디스코드 의존도를 없애고, 팀 신청·동적 대진표·일정 관리를 통합. 승부 예측 기능을 제공하여 사용자 98%가 “기존 체육대회보다 더 즐거웠다” 라고 응답. 본교 체육대회 DAU 300+명, GA 기준 누적 이벤트 17만+건, 본교 데브 페스티벌에서 우수상 수상

• 매 Kafka 메시지마다 predictor() 함수 내부에서 HuggingFace로부터 ELECTRA 모델 및 토크나이저를 재다운로드 후 디바이스 적재하던 구조를 ModelService 싱글톤으로 1회 로드 후 클래스 변수에 캐싱하도록 수정 → 메시지당 모델 로드 비용 제거
• 개선 전: Kafka 메시지 처리 시점마다 모델 및 토크나이저 로드



• 개선 후: FastAPI lifespan 시점에 사전 로드한 ModelService 재사용



• FastAPI lifespan 시점에 사전 로드 + asyncio.Lock으로 동시 호출 시 중복 로드 차단 → 첫 메시지 cold-start 제거, 컨테이너 lifecycle당 HuggingFace Hub 호출 N → 1로 감소
• async def로만 감싸여 있던 동기 torch 추론을 asyncio.to_thread로 분리 → 추론 중 이벤트 루프 블로킹 제거, Kafka consumer + 헬스체크 동시 응답성 회복
• 동일 샘플 N=20 마이크로벤치 결과
  • p50 1054.6ms → 17.7ms (98.3% 감소)
  • p95 1258.2ms → 29.2ms (97.7% 감소)
  • throughput 0.93 → 53.98 req/s (58배 향상)
  • 메시지당 약 1037ms 절감

학습 결과와 운영 추론 환경에서 분리되어 관리되던 문제를 해결하기 위해, MLflow 기반 실험 추적부터 HuggingFace revision pinning, 이미지 bake-in, Prometheus metrics까지 이어지는 모델 운영 흐름을 구축했습니다.

• MLflow Tracking을 도입해 학습 run별 hyperparameter, train/eval metric, base model metadata, model artifact를 기록
• train_loss, eval_loss, eval_accuracy, eval_f1을 epoch 단위로 추적하고, final_eval_loss와 final_eval_f1을 기준으로 run 간 성능 비교 → 선택된 모델 artifact를 MLflow artifact store에 경로에 저장하고, run ID와 모델 provenance를 운영 models.yaml에 연결하도록 설계

  

  

• HuggingFace model/tokenizer revision을 models.yaml 단일 출처로 고정하고 Docker build 시 사전 다운로드 → 런타임 HF Hub 장애, rate limit, cold-start 의존 제거
• health check 엔드포인트에서 현재 로드된 model/tokenizer revision과 loaded_at을 노출하고, Prometheus /metrics로 inference latency, prediction label, model load duration, Kafka 처리 상태를 관측
• 학습 데이터셋 SHA256, file count, size bytes 계산 스크립트를 추가해 model artifact뿐 아니라 학습 데이터 provenance까지 추적 가능하게 구성

규칙, 행동 텔레메트리, 요청 속도, 평판, 콘텐츠 유사도, ML 점수를 6개 채널의 가중 평균으로 결합. ML 응답이 없으면 분모에서 제외해 점수 분포가 깨지지 않도록 처리했습니다.

• mlScore=null이어도 rule-only 결정이 계속 반환되는 구조 구현
• 자동화 UA + 무텔레메트리, 초고속 제출 등 명확한 자동화 패턴은 score floor로 보정
• 모델 오탐이 곧바로 hard block으로 이어지지 않도록 영향 범위를 제한

AI 모드를 OFF / SHADOW / ENFORCE로 분리하고, 후보 모델과 canary ratio를 런타임 설정으로 선택하도록 설계했습니다. SHADOW에서는 모델 점수만 기록하고 실제 결정에는 반영하지 않아, 운영 데이터 위에서 모델을 먼저 검증할 수 있습니다.

• chooseModelForRequest()로 active / candidate 모델 라우팅
• SHADOW 점수는 audit metadata에 남기고, ENFORCE에서만 결정에 반영
• 모델 교체를 코드 배포가 아닌 운영 설정 변경 문제로 낮춤

gcml CLI로 학습·평가·드리프트 탐지·게시를 단일 진입점으로 묶었습니다. LightGBM을 우선 사용하되, 환경에 따라 XGBoost, sklearn HistGradientBoosting으로 fallback해 로컬/CI/운영 환경 차이를 흡수합니다.

• TrainingFeature Pydantic 스키마로 학습 데이터 컨트랙트 고정
• LightGBM class_weight="balanced"와 average_precision 지표로 불균형 라벨 대응
• Kaggle fraud / fake-social 데이터셋 어댑터로 콜드스타트 학습 데이터 확보
• baseline/current feature mean 변화율 기반 drift report 제공

FastAPI 추론 서버는 Mock / GBDT 모델을 동일한 RiskModel 인터페이스 뒤에 숨기고, 메인 앱은 250ms timeout + retry 후 실패 사유를 audit에 남긴 뒤 rule-only 경로로 계속 진행합니다.

• 초기 데이터 부족기에는 deterministic mock model로 운영 가능
• MODEL_PATH만 있으면 pickle 기반 GBDT artifact 로딩
• Bearer token, healthcheck, reason code를 포함한 운영형 API 구성
• timeout / http error / invalid response를 명시적 failure reason으로 분류

동기 요청 경로는 판단만 담당하고, 평판 조정·임시 차단·중복 콘텐츠 기록·의심 큐 집계는 worker로 분리했습니다. Docker Compose는 app, inference, worker, ml-pipeline, PostgreSQL, Redis, NATS, MinIO, Caddy를 한 스택으로 묶고 내부 서비스는 private network와 localhost binding으로 노출을 제한합니다.

• 결정 레벨별 reputation delta 테이블 정의
• user / ip / device 스코프를 분리하고 IP·device는 0.5배 가중
• TEMP_BLOCK TTL, suspicious queue flush 등 운영 부작용을 주기 job으로 분리
• app / ai-inference / postgres / redis healthcheck와 private network 구성

급식 조회, 자습 신청 리마인드, 미니게임 등의 기능을 제공하는 교내 디스코드 편의성 봇

• 자체 Ubuntu server로 Docker Compose 기반 릴리즈
• 40+개 디스코드 서버 도입, DAU 100+명

• Discord 봇의 자연어 명령 처리를 위해 vllm/vllm-openai 기반 LLM 서버를 Docker Compose로 별도 컨테이너로 분리하고, ChatOpenAI 클라이언트가 로컬 OpenAI-compatible endpoint를 바라보도록 구성
• MODEL_NAME(모델명), PORT, HF_HOME(허깅페이스 캐시 경로), HUGGING_FACE_HUB_TOKEN 등을 env로 빼고 llm_data:/data 볼륨을 사용해 모델을 캐시 영속화하여 재다운로드 비용을 절감
• NVIDIA GPU reservation 설정으로 GPU 서버 배포 대응

• Transformer 욕설 탐지 모델을 FastAPI inference service로 분리하고, application lifespan(서버 시작 시점)에 tokenizer/model을 1회 로드한 뒤 /predict 요청에서 재사용하는 구조로 구성
• fine-tuned 모델은 별도의 volume에 저장해 컨테이너 재시작 이후에도 유지
• fine-tuned 모델이 있으면 /data/fine_tuned_model에서 로드, 없으면 base model 로드

Discord reaction을 모델 피드백 인터페이스로 사용해 오탐/미탐 데이터를 수집하고, 누적 피드백을 기반으로 재학습을 트리거하는 human-in-the-loop 파이프라인을 구현

• 봇이 욕설 의심 메시지에 reaction 추가 → 관리자가 reaction으로 false positive or false negative 피드백 제공 → /feedback endpoint가 feedback.json에 학습 샘플 저장
• 쌓인 feedback을 바탕으로 /train endpoint가 FastAPI BackgroundTasks로 재학습 실행 → /status로 fine-tuned 모델 적용 여부와 피드백 개수 확인
• 피드백 데이터는 별도의 volume에 저장해 서비스 재배포에서 독립

외부 API 호출 경로를 bot 내부에서 FastAPI Gateway로 분리하고 Redis TTL 캐싱 적용 → 반복 요청 응답 속도 및 rate limit 부담 개선

• 모든 외부 API 접근을 jee6-api Gateway로 통합
• bot은 API_GATEWAY_URL만 호출하고, Gateway가 NEIS / Seoul Open Data / Riot / Spotify API 호출 담당
• 급식 조회는 주간 단위로 조회 후 Redis에 meal:{week} key로 6시간 캐싱 → 동일 주간 급식 외부 API 중복 호출 제거
• Riot 계정, 티어, 전적, 로테이션 응답을 Redis TTL 캐싱 → 반복 조회 지연 및 Riot API 호출량 감소
• 한강 수온, Spotify playlist metadata도 TTL 캐싱 및 in-memory cache 병행 적용
• Docker Compose로 bot, API Gateway, Redis, MariaDB, vLLM, filter service를 분리 운영하고 GitHub Actions + SSH 배포 자동화