AI Project Portfolio

강민성

AI 서비스를 직접 구축하고 운영까지 연결하는 엔지니어

Cukee — LLM 서빙·RAG 기반 AI 큐레이션 플랫폼 Doc2Edu Sync — LLM 기반 업무 자동화 PoC (카카오 엔터프라이즈) Gleey — 웹소설 작가용 AI 워크스페이스

Project 01

Cukee

AI 영화 큐레이션 플랫폼

Qwen-14B 기반 AI 큐레이션과 3D 전시회 경험을 제공하는 팀 프로젝트.
LLM 서빙, RAG 파이프라인, GPU 운영, OpenAI 호환 API 구축을 담당했습니다.

기간

2025.11 ~ 2026.02

담당 영역

AI 서빙, RAG, GPU 운영, Public API

주요 기술

Qwen-14B, LoRA, BGE-M3, pgvector, FastAPI, PyTorch, Docker, Prometheus, Grafana

Cukee

LLM 서빙 — T4 16GB에서 Qwen-14B 안정 운영

과제: 모델 + LoRA + 임베딩 동시 서빙

상황

T4 GPU의 VRAM은 16GB. Qwen-14B 베이스 모델 + LoRA 어댑터 + BGE-M3 임베딩 모델을 동시에 올리면 VRAM이 초과되어 OOM(Out of Memory)이 발생했습니다.

접근

감으로 해결하지 않기 위해 Prometheus + Grafana + DCGM Exporter 모니터링 스택을 먼저 구축하고, VRAM 사용량·GPU Utilization·온도를 실측하며 구성을 결정했습니다.

해결

베이스 모델: bitsandbytes 4-bit 양자화 적용 — fp16 로드 시 16GB 초과 → 양자화 후 ~8GB로 안정화
LoRA 어댑터: fp32 → fp16 전환 — 응답 품질 차이 없이 VRAM 절약을 실측으로 확인
임베딩 모델: BGE-M3 추가 VRAM을 실측하여 전체 조합이 16GB 내 운영 가능함을 확인 후 채택

배포 환경 호환성 확보

베이스 이미지

BGE-M3의 PyTorch 2.6.0 요구에 맞춰 pytorch/pytorch:2.6.0-cuda12.4-cudnn9-runtime으로 변경. T4의 CUDA 12.4 지원을 확인 후 결정

의존성 대응

bitsandbytes 빌드 실패(C 컴파일러 부재)를 build-essential 추가로 해결하고 triton을 함께 설치하여 양자화 라이브러리 호환성 확보

정리: "될 때까지 시도"가 아니라 "측정하고 판단"하는 방식으로, 제한된 GPU 자원 안에서 LLM 서빙 구성을 완성했습니다.

Cukee

RAG 파이프라인과 프롬프팅 고도화

RAG 검색 파이프라인

임베딩

BGE-M3 임베딩 모델로 영화 데이터셋을 벡터화하고, PostgreSQL pgvector에 저장했습니다. 별도 벡터 DB 없이 기존 RDBMS 안에서 벡터 검색을 운영하는 구성입니다.

검색

embedding_loader와 retrieval_service 모듈로 적재와 검색을 분리 구현하여, 사용자 요청 시 관련 영화 정보를 검색해 생성 컨텍스트로 전달합니다.

생성

FastAPI 기반 AI 서버에서 전시회 생성(/generate), 영화 상세(/movie-detail) 엔드포인트를 구현하고 요청 파라미터를 설계했습니다.

프롬프팅 / 페르소나 최적화

Dynamic System Prompting

Qwen-14B에 페르소나 테마별 동적 시스템 프롬프트를 적용하여, 하나의 모델로 여러 큐레이터 캐릭터의 응답 스타일을 구현

Persona Summary 캐싱

페르소나 요약을 캐싱하고 DB에 저장하여 반복 생성 비용을 줄이고 응답 속도를 개선

정리: 임베딩 → 벡터 검색 → 컨텍스트 주입 → 생성까지 RAG 전 과정을 직접 구현하며, 검색 품질과 생성 비용을 함께 고려하는 설계를 경험했습니다.

Cukee

GPU 모니터링 — 측정 기반 의사결정

AI 서비스는 리소스 변동이 크기 때문에, GPU 서버의 상태를 실시간으로 관측할 수 있는 모니터링 스택을 docker-compose에 함께 구성했습니다.

DCGM Exporter

NVIDIA GPU 메트릭 수집. VRAM 사용량, GPU Utilization, 온도, 전력 소비를 Prometheus 포맷으로 노출합니다.

Node Exporter

시스템 메트릭 수집. CPU, RAM, 디스크 I/O를 수집하여 GPU 외 병목도 함께 확인합니다.

Prometheus

메트릭 수집 허브. 5GB 저장 + 7일 보존 정책으로 운영하며, DCGM과 Node Exporter 데이터를 통합 저장합니다.

Grafana

대시보드. /monitor/ 경로로 서빙. GPU 사용량, 시스템 리소스, 모델 서빙 상태를 시각화합니다.

모니터링이 의사결정에 기여한 사례

양자화 수준 결정

fp16 로드 시 16GB 초과 확인 → 4-bit 양자화 적용 후 ~8GB로 안정화

LoRA 정밀도 결정

fp32 vs fp16 VRAM 비교 → 응답 품질 차이 없어 fp16 확정

임베딩 모델 선택

BGE-M3 추가 VRAM 실측 → 전체 조합이 16GB 내 운영 가능 확인

Cukee

OpenAI 호환 Public AI API — AI를 서비스로 제공

GPU 서버에서 운영 중인 페르소나 모델(Qwen-14B + LoRA)을 외부에서도 API로 호출할 수 있도록, OpenAI chat completion 포맷과 호환되는 Public API를 구축했습니다.

전체 요청 흐름

1

인증

Bearer 토큰 또는 X-API-Key 헤더로 API Key 검증. 만료·폐기 상태 확인

2

요청 파싱

OpenAI messages 배열에서 사용자 프롬프트 추출. ticketId로 페르소나 테마 매핑

3

GPU 서버 프록시

백엔드가 내부망(10.0.x.x:5000)의 AI 서버로 요청을 중계. 120초 타임아웃 + 에러 핸들링

4

응답 변환 + 로깅

AI 서버 응답을 OpenAI chat.completion 포맷으로 변환하여 반환. 토큰 사용량·비용·레이턴시를 DB에 기록

설계 포인트

API Key 관리

콘솔에서 발급·폐기. RPM/TPM/RPD 제한 설정. 키별 사용량 독립 추적

빌링 시스템

요청별 토큰 추정 + 비용 산출. 일별 집계 테이블로 대시보드 조회 지원

보안 격리

GPU 서버는 내부망에서만 접근 가능. 백엔드가 유일한 프록시 경로로 외부 노출 차단

정리: 모델을 만드는 것에서 끝내지 않고, 인증·과금·사용량 관리를 갖춘 "서비스로서의 AI"까지 완성했습니다. 토큰 사용량 기반 빌링과 API 콘솔 대시보드(Usage·Billing·API Keys)도 직접 구축했습니다.

Project 02

Doc2Edu Sync

LLM 기반 업무 자동화 PoC — 카카오 엔터프라이즈 인턴

기술문서가 업데이트되면 교육 교안에서 수정이 필요한 슬라이드를 자동으로 찾아
LLM이 수정 방향까지 제시하는 파이프라인. 기획부터 설계·구현·시연까지 전 과정을 주도했습니다.

기간

2026.04 ~ 2026.05 (카카오 엔터프라이즈 클라우드솔루션팀)

담당 영역

기획, 아키텍처 설계, 구현, 시연 (전 과정)

주요 기술

OpenAI API, GitHub Actions, PostgreSQL, Python, Marp, SSH Tunnel

Doc2Edu Sync

자동화 파이프라인 — 수집부터 리포트까지

반복적으로 수작업에 의존하던 "기술문서-교안 현행화" 업무를 자동화 파이프라인으로 재설계했습니다.

파이프라인 구조

1

변경 수집

GitHub Actions + self-hosted runner 기반 하루 1회 자동 배치로 기술문서(GitHub Enterprise) commit 수집

2

태그 후보 추출

변경 파일 경로 · frontmatter · diff 본문 3가지 소스에서 태그 후보 추출 — commit 메시지만으로는 변경 의미 파악이 어려운 문제를 해결

3

DB 매칭

PostgreSQL 태그 관리 스키마(tags, units, unit_tags)로 수정 후보 슬라이드 탐색

4

LLM 판단 + 리포트

OpenAI API로 수정 필요 여부를 판단하고 '기존/변경' 형식의 구체적 수정안 도출. Markdown/PDF 리포트 자동 생성

운영을 전제로 한 설계

복원력

state 파일 기반 중복 수집 방지. Actions 실패 시에도 다음 실행에서 누락 없이 이어서 수집

인프라 접근

카카오클라우드 Managed PostgreSQL 인스턴스 생성, SSH 터널 기반 사내망 DB 접근 구조 구성

운영 도구

GitHub Actions 실행·상태 조회·리포트 확인이 가능한 GUI 도구 개발로 비개발 직군도 사용 가능하게 제공

Doc2Edu Sync

LLM 활용 설계 — 비용과 신뢰성을 함께 잡기

판단 1: 토큰 비용 절감

상황

기술문서와 교안 전체를 LLM에 그대로 넣으면 검토 범위가 넓어지고 토큰 비용이 통제되지 않습니다.

판단

태그 기반으로 수정 후보 슬라이드만 축소 전달하는 구조를 설계했습니다. LLM에 들어가는 입력 자체를 줄여 검토 범위와 비용을 동시에 통제했습니다.

결과

후보 축소 → LLM 판단 → 리포트 생성의 흐름으로 매일 배치가 돌아도 부담 없는 비용 구조를 만들었습니다.

판단 2: LLM 출력의 신뢰성 확보

상황

LLM이 후보 범위 밖의 슬라이드까지 판단하거나, 모호한 수정 의견을 내면 결과를 신뢰할 수 없습니다.

판단

LLM이 후보 밖의 슬라이드는 판단하지 않도록 제한하고, '기존/변경' 형식의 구체적 수정안만 유효 결과로 인정하는 평가 기준을 수립했습니다.

결과

PoC 로드맵 Phase 1(라벨 DB 설계) → Phase 2(문서 버전 모니터링) → Phase 3(LLM 수정 판단·리포트) 전체를 2개월 안에 완료하고 시연까지 마쳤습니다.

정리: LLM을 "붙여보는" 수준이 아니라, 비용 구조와 출력 신뢰성까지 설계한 업무 자동화 파이프라인으로 완성했습니다. 이 과정에서 기획안·아키텍처 설계서·README 문서화와 시연까지 직접 수행했습니다.

Project 03 — Gleey

웹소설 작가용 AI 워크스페이스 — AI 기능 서빙과 안정화

기획·집필·AI 보조를 하나의 흐름으로 연결하는 멀티플랫폼 작업 환경. FastAPI 기반 AI 서비스 서버와 배포 인프라를 담당했습니다. (2026.02 ~ 2026.03)

AI 기능 구현과 안정화

집필 보조 API 구현. 이어쓰기, 문체 변환, 캐릭터 이름 생성, 맞춤법 검사 등 작가용 AI 기능을 FastAPI 서버로 구현했습니다. AI 기능은 외부 Google Gemini API를 호출하는 구조입니다.

모델 교체·안정화. AI 모델 교체 과정에서 맞춤법 검사 응답이 불안정해지는 문제를 겪으며, 모델을 단계적으로 교체하고 기능별 안정성을 검증했습니다. 맞춤법 검사 모델을 4차례 반복 수정하며 안정화했습니다.

구독 플랜별 AI 사용량 관리. 플랜에 따라 AI 사용량을 관리하는 구조를 설계하여, AI 기능을 지속 가능한 서비스 형태로 제공했습니다.

운영 인프라. Traefik 리버스 프록시 + Docker Compose 멀티 서비스 구성, GitHub Actions CI/CD(GHCR), Prometheus·Grafana 모니터링으로 서비스 전체를 단일 VPS에서 운영했습니다.

정리: 자체 GPU 서빙(Cukee)과 외부 LLM API 활용(Gleey)을 모두 경험하며, 상황에 맞는 AI 서빙 방식을 선택하고 서비스로 안정화하는 감각을 익혔습니다.

Summary

AI를 만들고, 운영까지 연결합니다

LLM 서빙 최적화

T4 16GB 제약에서 4-bit 양자화·fp16 전환을 실측 기반으로 결정하여 Qwen-14B + LoRA + 임베딩을 안정 운영했습니다.

RAG 전 과정 구현

BGE-M3 임베딩 + pgvector 검색 파이프라인을 직접 구현하고, 동적 프롬프팅과 캐싱으로 생성 품질과 비용을 함께 관리했습니다.

LLM 업무 자동화

카카오 엔터프라이즈에서 기술문서-교안 현행화를 LLM 파이프라인으로 자동화하는 PoC를 기획부터 시연까지 완주했습니다.

서비스로서의 AI

인증·과금·사용량 관리를 갖춘 OpenAI 호환 API와 관리 콘솔까지 구축하여, 모델이 아니라 "운영 가능한 AI 서비스"를 완성했습니다.