배경

상담센터를 타깃으로 제안할 자사 TTS 솔루션을 신규 구축하는 과제.기존 시스템 교체가 아니라, 실시간 상담에 쓸 수 있는 응답 속도와 음성 선택지를 갖춘 제품을 처음부터 만드는 것이 목표였음.모델 선정부터 서빙 아키텍처, 백엔드·프론트엔드, 배포·운영까지 전 구간을 단독으로 맡았고, 고객사 PoC·시연까지 진행.

차별점

① 스트리밍 품질 자동 감지 · 자가 치유 — 잘리거나 반복된 음성을 서버가 스스로 걸러내는 구조.

• 합성 오디오의 예상 길이 대비 실제 길이 비율로 잘림·반복을 판정 (0.35배 미만 = 잘림 의심, 3배 초과 = 반복 의심).텍스트에서 음절 버킷으로 기대 길이를 추정
• 이상 클립은 캐시에 넣지 않고 배제.같은 문장의 다음 요청이 정상 합성을 받아 자가 치유.스트리밍은 이미 나간 청크를 되돌릴 수 없으므로 후속 요청부터 회복되는 구조
• 감지(로깅)는 전 요청·전 언어 상시 동작.캐시 배제는 오탐이 정상 클립을 버리는 쪽이 더 위험하다고 판단해, 길이 추정이 신뢰되는 언어(CJK)로 게이팅하고 플래그로 단계 도입 — 현재 운영 관측 단계

② 처리량 천장 진단 → 돌파 — "1.7 rps가 천장"이라던 사내 결론을 벤치마크로 반증.

• 기존 사내 결론은 "약 1.7 rps는 버전 무관한 구조적 천장".버전(0.22/0.24) × executor(mp/uni) 2×2 전수 벤치로 이를 반증
• 처리량의 몸통은 보코더(Code2Wav)가 launch-bound eager bs≈1로 돌던 것이 CUDA-graph replay + 요청 간 배치 디코드로 바뀐 것.배칭 기계장치는 구버전 이미지에도 있었으나 자체 운영 config(eager 강제·EOS 튜닝·토큰예산)가 봉인하고 있었고, 네이티브 EOS·abort 레이스 수정이 그 봉인을 풀어줌
• 동일 부하(conc8)에서 0.73 → 1.61 rps, 각자 최대 안정치 0.73 → 3.09 rps(4.2배).자체 패치 3종·EOS 튜닝·문장분할 의존도 함께 제거
• 안정성도 질적 전환.conc16 진입 시 엔진 사망(3회 재현)하던 것이 conc48 무오류(1,500+ 요청)로

③ 용량 한계 실측 — 동시 몇 명까지 받을 수 있는지를 숫자로 확정.

• burst 스윕으로 SLA 확립.TTFB ≤500ms 동시 15 · ≤1000ms 동시 30, 수용 한계 36 (실링 약 40)
• 판정 기준은 지연이 아닌 RTF 여유.코덱 좌측 컨텍스트를 조정해 N30 RTF 0.91 → 0.71 확보, N40은 0.96~1.04로 마진이 사라지는 것을 확인하고 운영값을 실링 -1 티어(36)로 결정
• 자원 축도 함께 실측.per-stage VRAM(stage0 18.9G + stage1 7.2G) · 컨테이너별 CPU/메모리 피크 · GPU 온도와 SM 클럭까지 기록해 열 스로틀링 드리프트를 측정 오염과 구분

시스템 구조

구현

시스템 아키텍처: FastAPI WebSocket/REST 게이트웨이 + vLLM-Omni(Qwen3-TTS) 추론 엔진 + Redis 분산락 & 캐싱 + React 대시보드.문장 단위 논리 청킹 및 WebSocket 스트리밍으로 TTFB 단축.

성능 최적화: L40S 단일 GPU 환경에서 처리량과 지연을 함께 끌어올림.

• FP8 양자화 · executor backend 최적화 · 동시성 튜닝으로 추론 처리량 개선
• Pre-Normalization · CUDA Graph Warmup · 세마포어 동시성 제어로 GPU 메모리 활용 개선
• Redis 캐싱으로 동일 문장 재요청 시 즉시 스트리밍 개시 (캐시 히트 TTFB 50ms 미만)

지연 구조 분해: 튜닝에 앞서 TTFB가 어느 구간에서 나오는지부터 계측.엔진 패치에 전처리(prep)와 엔진 첫 청크(큐+prefill+보코더) 지표를 심어 분해.

• 전처리 3~6ms·API 약 100ms는 고정이고, 동시 요청 수에 선형 비례하는 구간은 엔진 디코드 루프(동시 +1당 약 +20ms)임을 확인
• 스트림 세마포어를 32→40으로 여는 통상적 처방은 대조 실험 결과 대기 위치만 엔진 안으로 옮길 뿐 SLA는 오히려 악화.세마포어의 역할을 병목 제거 장치에서 과부하 보호막으로 다시 규정
• 실효 레버를 코덱 좌측 컨텍스트(72→25, CUDA graph capture 목록 정합 수정 동반)와 첫 청크 프레임 수(4→2) 둘로 좁혀 확정
• 청크 경계 불연속을 z-검정으로 자동 판정하는 품질 게이트를 통과시킨 뒤 채택

측정 하네스: 성능 스윕을 도구화하던 중 "0.6B 라벨로 1.7B를 측정"한 오라벨 사고를 겪고, 측정 자체를 믿을 수 있게 만드는 안전장치를 하네스에 내장.

• 서빙 중인 모델 3중 검증 — 환경변수·엔진 응답·부하기 재검증.불일치 시 스윕 시작 불가
• 파라미터 반영 확인 실패 시 해당 값 스킵, SLA 판정에 연속성 요구(스파이크 하나로 뚫린 상위 동시성 채택 금지)
• 측정 오염 제거 — 1초마다 폴링하던 nvidia-smi가 GPU를 멈춰 세우던 것을 찾아 주기 조정, 동일 문장 반복의 prefix cache 낙관은 가변 문장 모드 병행 측정으로 해소

기능 확장: 참조 음성 5초만으로 화자 목소리를 복제하는 ICL 기반 음성복제 기능 구현.

• OpenAI TTS API 호환 인터페이스 + 기존 WebSocket 프로토콜 호환 레이어 — 외부 서비스가 코드 수정 없이 연동
• Redis 기반 Atomic quota·분산락·Circuit Breaker 등 장애 대응 로직
• Whisper 기반 CER/WER 자동 품질 측정 파이프라인

운영: vLLM(GPU)과 Supertonic(CPU) 듀얼 엔진 구성 — 장애 시 Circuit Breaker가 CPU 엔진으로 자동 폴백.

• 무중단 롤링 재배포 체계 + 온보딩 가이드·운영 런북·장애복구 절차·성능 명세 문서화로 운영 이관 가능한 수준까지 정비
• 배포 직후 활성 음성별 prefill 워밍과 정형 인사말 프리캐시를 자동 실행 — 첫 사용자가 콜드 경로를 밟지 않게
• 스트리밍 품질을 자동 감지해 자가 치유 (위 차별점 ① 참조).품질 사고가 캐시에 굳는 것을 차단

성과

• 자체 튜닝(FP8·executor)으로 0.68 → 1.41 rps, 엔진을 옮긴 뒤 최대 안정치 3.09 rps.측정 조건별 비교는 차별점 ②에 정리
• 정상 부하에서 TTFB p50 70ms, GPU 처리량 8.6 rps (2026.07 실측)
• 32개 언어 지원 단일 플랫폼 (vLLM 10개 + Supertonic 22개)
• ITN 정규화 정확도 50.1% → 70.9% (검증셋 기준)
• 같은 GPU에서 burst p95 TTFB 1,008ms → 652ms (동시 20 기준). ≤500ms는 달성 불가에서 동시 15로, ≤1000ms는 20~25에서 30으로 올랐다.동시 스트림 수용 한계 36 실측 (2026.07 말)
• TTFB 경로의 순차 Redis 왕복을 16회에서 13회로 줄이고, 문장 캐시는 일괄 조회로 바꿔 N왕복을 1왕복으로

운영 대시보드

데모 영상

핵심 엔지니어링

1. 스트리밍 팝 노이즈 — 스트리밍 중 간헐적으로 '틱' 잡음 발생.PCM 청크가 홀수 바이트로 끊겨 와 16bit 샘플 정렬이 깨지는 것이 원인.잔여 바이트를 다음 청크에 이어 붙이는 Residual Buffer로 정렬을 보장하고, 청크 경계에 Micro-fade를 적용해 해결
2. 스토리지 누수 — 보이스를 삭제해도 디스크 사용량이 계속 증가.원본을 지워도 파생된 MD5 해시 캐시 파일이 남는 구조여서, 파생 파일까지 추적해 함께 지우는 Deep GC를 구현해 차단
3. 웹소켓 세션 탈취 방어 — 비밀번호를 바꿔도 이미 발급된 토큰으로 웹소켓 연결이 열리는 허점 발견.토큰 발급 시점과 password_changed_at을 대조해 변경 이전 토큰을 전부 무효화
4. ITN 정규화 — URL·이메일을 한국어로 부자연스럽게 읽는 문제.자연스러운 발음으로 변환하는 스마트 ITN 엔진을 직접 개발해 정규화 정확도 50.1% → 70.9%
5. CPU 스파이크 (ReDoS 가드 오버헤드) — 정규식 치환의 ReDoS 방어용 ThreadPoolExecutor(max_workers=1) 가드가 치환마다 새로 인스턴스화되어 다수 합성 시 CPU 스파이크와 지연을 유발.오버엔지니어링된 가드를 철거하고 네이티브 C 구현체(re.sub) 동기 호출로 교체해 핫 패스 병목 제거
6. 전면 백색소음 장애 — vLLM 0.24 전환 직후 모든 합성이 백색소음으로 재생되는 문제를 추적해, 엔진의 SSE(JSON) 응답이 그대로 PCM으로 재생된 것이 원인임을 확인.응답 포맷을 오디오로 강제해 해결
7. 스트리밍 WAV 헤더 정리 — 엔진이 문장마다 RIFF 헤더를 붙여 보내 클라이언트 디코딩이 어긋나는 문제.문장별 헤더를 걷어내고 세션 전체에 스트리밍 WAV 헤더를 한 번만 내보내는 구조로 정리해 해결
8. 크래시로 오진할 뻔한 스트림 집단 절단 — 고부하 burst 중 스트림이 무더기로 끊기고 수 분간 무응답.엔진 크래시로 보였으나 컨테이너 재시작 횟수가 0인 것을 확인하고 가설 폐기.실체는 추론 엔진의 텐서 결합 오류가 집단 발생하자 API 서킷 브레이커가 열려 빈 응답을 반환한 연쇄.동시 한도를 실링(40)보다 한 티어 낮춰(36) 과부하 진입 자체를 완화
9. HTTP 스트림 tail 지연 — 저지연을 표방하면서 실제로는 tail 버퍼를 문장 끝까지 붙들어, 약 615ms 분량이 모일 때까지 한 바이트도 내보내지 않던 구조.WebSocket 경로에만 있던 무음 감지 기반 조기 flush를 HTTP에 이식해 단문 TTFB와 문장 경계 끊김을 함께 해소

오픈소스 기여 (vLLM-Omni)

• 운영 중 stage0(talker) 프로세스의 호스트 메모리가 선형 증가하고 끝내 플래토에 도달하지 않는 것을 발견.추론 엔진이 abort된 요청의 sender 측 상태(코덱 프레임 이력·참조 텐서·청크 카운터)를 회수하지 않는 것이 원인 — 회수 경로가 "terminal 청크 전송 성공"에만 걸려 있어, 클라이언트가 끊고 나간 요청은 프로세스가 죽을 때까지 남는 구조
• 인과를 수치로 좁힌 방법 — 부하·메모리 할당자·캐시 설정을 바꾼 4개 구성에서 증가율은 22~296 MiB/h로 13배 차이가 나는데, abort 건수로 나누면 36~56 KB/abort로 일정했다."부하가 높아서"가 아니라 "abort 하나당" 새는 것임을 이 불변량으로 확정하고, memray 스냅샷(10분 vs 20분 창)으로 해당 호출 경로의 미해제 할당이 창 길이에 비례해 늘어나는 것을 교차 확인
• abort 시점에만 sender 상태를 회수하는 최소 패치로 A/B 검증 — 257 → 60 MiB/h (77% 감소), 4.4시간 창 R²≈0.99.같은 런의 미패치 대조군은 15.2시간 동안 258 MiB/h, R²=1.00
• 고치고 끝내지 않고 잔여 ~13 KB/abort가 남는 것까지 측정해, 원인을 save 큐에 이미 적재된 청크가 상태를 되살리는 레이스로 특정.상위 RFC가 이미 구현해 둔 지연 정리 패턴(_deferred_send_cleanup)을 이식하면 닫힌다는 것까지 이슈에 남겼다
• 이슈로 리포트한 뒤 같은 원인을 다루는 기존 PR을 발견하고, 그쪽에 프로덕션 검증 데이터를 붙였다.PR 작성자와 리뷰어가 근거로 인용 (2026.08, 머지 대기)

이슈 #6352 (리포트)  ·  PR #4349 (검증 데이터 제공)

배경

고객 상담 센터용 기존 TTS(ZipVoice 기반)의 응답 지연(TTFB 2.3초)이 심각해 실시간 상담에 부적합했음.신규 플랫폼 구축에 앞서 기존 서비스의 응답성부터 개선 필요.

구현

SSE 청크 디코딩 실패 해결: 브라우저 decodeAudioData()가 두 번째 청크부터 실패한다는 고객 이슈를 추적.

• 원인 — 엔진이 첫 청크에만 RIFF WAV 헤더를 붙이고 이후는 raw PCM만 반환
• 조치 — 첫 청크 헤더에서 샘플레이트·채널을 파싱해 모든 SSE 청크에 독립 헤더를 재생성, 청크 단위 독립 디코딩 가능하게

실시간 스트리밍 엔드포인트 신설: 수정 후에도 기존 /sse는 전체 합성이 끝난 뒤 WAV를 분할 전송하는 구조라, 텍스트가 길수록 TTFB가 비례해 늘어났다.엔진의 gRPC server streaming을 활용한 /sse-realtime을 신설해 문장 단위 합성 → 즉시 전송 구조로 전환.

정비: API v2 경로 표준화(v1은 deprecated로 하위 호환 유지), Swagger 문서 정비, 구·신 버전 TTFB를 직접 비교하는 데모 페이지 제공.

성과

• TTFB 1,943ms → 985ms — 같은 텍스트를 양쪽 엔드포인트로 완주시킨 비교(58.0초 342청크 / 59.4초 364청크), 데모 페이지 콘솔 로그 그대로.첫 문장이 짧은 런에서는 334ms까지 측정됐으나 단일 런이라 대표값으로 쓰지 않음
• 원인 분석부터 조치·검증·고객 보고까지 단독 수행
• 이 경험이 이후 Qwen3-TTS 플랫폼을 저지연 스트리밍 중심으로 설계하는 출발점이 됨

데모 페이지

고객 안내용으로 제공한 데모 페이지 — 동일 텍스트로 구버전(/sse)과 신버전(/sse-realtime)의 TTFB를 직접 비교 체험할 수 있게 구성 (스크린샷의 예시 런: 1943ms → 985ms, 내부 서버 주소는 가림 처리)

배경

AIG 상담센터의 대량 상담 전화 실시간 처리 필요.기존 STT 시스템 병목으로 인한 채널 부족 및 추론 지연 불안정.

구현

AIG STT 구조 개선: Triton Inference Server 기반 음성인식 파이프라인을 전처리·후처리·서비스 계층으로 모듈화해 파일/스트리밍 공통 로직을 통합.YAML 기반 로그 로테이션·아카이빙 체계와 Docker 구성을 정비하고, 컨테이너 자동 재시작 정책으로 안정성을 보강.

엔진 구성: Triton Python 백엔드로 파일 기반(화자 분리 결합)과 실시간 스트리밍 두 추론 모델을 구성, HTTP와 gRPC 인터페이스를 모두 제공.화자 분리 결과를 STT에 결합해 화자별 전사를 생성 — 화자 구간을 추론 파라미터(clip timestamps)로 전달해 화자마다 정확한 전사를 얻는 구조를 구현.

성과

• AIG 요구사항 해결 4건
• Triton Inference Server 기반 배포 - 고성능 음성인식 파이프라인
• Docker 컨테이너화로 배포 자동화 및 안정성 강화
• 배치 처리와 스트리밍 처리 모두 지원
• 전처리·후처리·서비스 계층 분리로 코드 재사용성 확보

배경

상담 품질 분석을 위해 발화자 식별 필요.기존 STT는 음성 인식만 제공하여 상담사/고객 구분 불가.

구현

모델 파인튜닝: Pyannote 사전 학습 모델을 공개 화자분할 데이터로 파인튜닝 — 파라미터 튜닝과 학습을 수행하고 DER로 검증.

시스템 통합: 화자 분할 결과를 STT와 연동해 상담사/고객이 구분된 전사 결과를 만드는 파이프라인 작업 수행.

성과

• 공개 화자분할 데이터로 파인튜닝한 모델을 DER로 검증 (데이터 수집 → 파라미터 튜닝 → 학습)
• 화자 분할 결과를 STT에 연동해 상담사·고객이 구분된 전사 파이프라인 완성

배경

rag-agent에서 구축한 검색 평가 방법론(gold 라벨, 실패 원인 분해, 미채택 실험 기록)을 멀티모달로 확장.패션 상품 44,072개(공개 데이터셋)를 한국어 문장형 질의("체크무늬 네이비 남성 셔츠")로 검색하는 시스템을 CLIP 임베딩 인덱스부터 평가셋·대화형 데모까지 구축.

구현

• 이미지+텍스트 복합 질의 — "이 상품이랑 비슷한데 검정색으로": 스타일은 임베딩 가중 합성, 속성은 메타 필터가 담당
• 대화형 정교화 — 후속 발화를 조건 병합, 부정어(말고·빼고) 처리, 대화 경로 UI. 서버는 무상태
• FastAPI + 바닐라 JS 데모 — 검색 응답 약 80ms, 질의 임베딩 LRU 캐시(반복 질의 165 → 0ms), 단계별 타이밍 노출
• 44K 규모라 정확 탐색(numpy 내적) 채택 — ANN 도입 시점을 규모 기준으로 명시

GitHub 저장소 (데모 GIF·평가 리포트·번역문 전수 기록)

성과

• 한국어 50문항 × 44K 기준 hit@10 90% → 98%.임베딩 단독의 세부 조건 약점을 구간 분해로 먼저 규명(gold≤50 구간 precision@10 0.10)한 뒤, 질의에서 색·성별·용도를 뽑아 메타 필터로 결합해 해소(0.53)
• 같은 이미지 인덱스에서 텍스트 경로만 바꿔 다국어 전략 6종을 실측 비교.m-clip 48% < 소형 MT 86% < LLM(3B)+커머스 용어집 92%. 번역기는 크기순이 아님(NLLB 600M 76% < 8배 작은 opus 86%)
• 대형 멀티링구얼(jina-v2 865M)과는 상보 관계. 지표는 jina-v2가 앞서지만 임베딩 비용이 ko-clip의 약 130배.실패 문항도 정확히 갈림. 외래어는 멀티링구얼이, 콩글리시는 한국어 특화가 강세
• gold가 넓은 질의는 hit이 자동으로 나온다. 이 인플레이션을 구간별 분해·precision@10 병기로 해소.결과마다 재현 메타(모델 id·시각·top-10 id) 기록

배경

시계열 파운데이션 모델(Chronos)의 제로샷 성능 주장을 커머스 수요 데이터에서 직접 검증.월마트 일별 판매 30,490 시리즈(M5)에 h=28 롤링 오리진 백테스트를 구축하고, 오염 검증(M5가 Chronos 학습 코퍼스가 아닌 공식 제로샷 평가셋임을 확인)부터 선행.

구현

• 롤링 오리진 백테스트 하네스 — RMSSE(M5 공식)·MASE·WQL, 가변 길이 시리즈·시리즈별 시작 요일 대응, 스케일 미정의는 NaN+제외 보고
• 전 시리즈 공용 LightGBM(랙·롤링·요일·카테고리·달력 공변량, tweedie, 재귀 다단 예측) / Chronos-bolt 제로샷 / 시리즈 특성 기반 모델 라우팅
• 예측 곡선 시각화 — 집계 레벨의 주간 패턴 추종 vs 바닥 레벨 간헐 수요를 한 장으로 (재현 스크립트 포함)

GitHub 저장소 (라운드별 실측 기록·검증 리포트)

성과

• 계층 레벨에서 판정 역전 실측.판매 0이 55%인 바닥 레벨은 28일 이동평균이 RMSSE 1위(0.741), 집계 레벨(0 비율 ~0%)은 제로샷 Chronos가 전 레벨 1위(store 0.717·전사 0.675) — 파운데이션 모델의 가치는 "신호가 있는 곳"에서 크다
• 지표·집계 방식이 결론을 바꾸는 지점 문서화."전부 0 예측"이 naive를 이기는 간헐 수요 함정, MASE/RMSSE 승자 분화, 판매량 가중 시 이동평균-Chronos 동률(0.718 vs 0.720)
• 반론 봉쇄 — LightGBM 스윕 6구성 전수 기록·달력 공변량·집계 레벨별 재설계까지 측정.학습 모델이 학습 0초 제로샷을 평균에서 못 넘는 구도 확인(시리즈별 승수 4/10 한계 병기)
• 강건성 검증 — 겹치지 않는 대체 샘플·6폴드 확장에서 순위 재현, 컨텍스트 길이 민감도 ±0.5%.코드 감사로 잠재 버그 4건 수정, 회귀 테스트 10개

배경

LLM Agent 시스템(RAG, tool orchestration, state 관리)의 E2E 구축 역량 확보 목적.포트폴리오 기술문서를 지식 베이스로 하는 Q&A Agent를 전부 로컬 환경(Ollama)에서 구현.

구현

• LangGraph StateGraph 기반 Corrective-RAG — retrieve → grade(자가 평가) → 판정 부족 시 rewrite 재검색 → generate
• FAISS(의미) + BM25(키워드) RRF 융합 직접 구현 — 벡터 저장소는 환경변수로 Qdrant 교체 가능, 동일 평가로 비교해 선택 기준 실측
• 에이전트 레이어 3종 — ReAct 도구 호출, Planner–Worker–Synthesizer 멀티홉 분해, MCP 클라이언트
• 인덱싱 전 데이터 검수 CI 연결 — 노션 내부 링크가 코퍼스의 9.4%를 차지하던 오염 발견·제거

성과

• 51문항 기준 정답률 68% → 75%.실패를 검색·청킹·생성 층으로 나눠 병목이 생성 단계임을 수치로 확인하고 컨텍스트 수를 튜닝
• 검색 recall@1 90%, MRR 0.95 (무작위 기준선 3% 병기).이 과정에서 하이브리드 검색 결함 7건을 찾아 수정
• 채점기가 동의 표기를 오답으로 세고 있던 것을 발견.6%p를 정정 — 지표를 쓰기 전에 지표부터 검증한 경우다
• 코퍼스에 답이 없는 거부 문항 10개를 넣어 환각 측정 지표 신설.컨텍스트를 넓힐수록 환각이 느는 트레이드오프를 실측

평가 방법론

• 검색/생성 분리 평가 — recall@k(LLM 불필요)와 E2E 정답률을 분리해 실패 원인 귀속
• gold 라벨을 청크 md5·앵커 문자열로 고정 — 재청킹 시 자동 무효화, 전 지표에 무작위 기준선 병기
• 3B 모델의 런 간 편차 ±6%p 실측 — 모든 A/B는 반복 측정, 1~2문항 차이로 결론 내지 않는 원칙
• RAGAS 도입 검토 후 보류 — 로컬 3B 심판의 일치율 45~50%로 정보량이 없음을 실측하고, 재도입 조건(7B 이상·일치율 90%)을 코드에 명시

실험 기록

• Parent-Child 청킹 — 초기엔 유일하게 풀던 집계 질문을 base의 top-N 확장이 함께 해결했고 child recall@1도 열위(78% vs 89%)라 미채택.판단 근거를 코드 주석에 기록
• 시맨틱 청킹(임베딩 유사도 breakpoint, 직접 구현) — 동일 조건 비교에서 base가 전 지표 우위로 미채택
• 격리 단일 호출의 판단이 전체 파이프라인 반복 측정에서 뒤집힌 사례 확보 — n=1 실험의 함정을 실측으로 문서화
• 이 사이트의 프로젝트 검색이 살아있는 데모 — BM25 레이어를 순수 브라우저 JS로 이식 (다중 단어 AND, 한글 바이그램으로 조사·어미 대응, 관련도순 정렬). 목차의 검색창에서 바로 체험 가능

GitHub 저장소 (코드 및 개선 히스토리)

배경

음성 AI에서 실시간 신호를 다뤄온 경험을 산업 설비 시계열로 확장.회전기계 센서(진동·온도·전류)에서 이상을 탐지하고 LLM이 정비 진단 리포트를 작성하는 예지보전 데모.

구현

설계 원칙 — "탐지는 결정적 알고리즘, LLM은 해석만": 이상 탐지는 z-score(순간 충격)·EWMA 관리한계(과열)·추세 회귀+간이 RUL 추정(베어링 마모)의 신호처리 알고리즘이 담당.LLM은 탐지 근거를 종합해 원인 추정·권고 조치를 작성하되, 근거 밖 수치 생성을 프롬프트로 차단.

시뮬레이터: 부하 변동을 포함한 회전기계 모델에 결함 3종 주입 — 주입 시점이 ground truth로 남아 탐지기를 정량 평가.

성과

• 5개 시나리오에 주입한 결함 15건을 전부 탐지.재현율 100%에 오탐 0건이지만, 통제 실험 기준임을 함께 밝힌다
• 추세 탐지기가 "한계치 도달까지 약 29시간" RUL 추정 산출
• LLM 진단이 탐지 근거만으로 베어링 마모/윤활 불량 원인 후보 도출

실데이터 검증 (NASA C-MAPSS)

• 같은 탐지기를 터보팬 엔진 100대의 run-to-failure 벤치마크에 적용 — 합성에서 튜닝한 4σ 한계는 63/100으로 보수적, 3σ 완화 시 고장 전 경보 94/100, 조기 경보 0건 (관리한계 트레이드오프를 표로 공개)
• RUL은 보정(엔진 1~50)과 평가(51~100)를 분리해 라벨 누수 차단 — 선형 외삽 MAE 28.5사이클을 지수 열화 모델로 12.9사이클까지 절반 이하로 개선 (추정 보류 트레이드오프까지 기록)
• 4개 셋 전부로 확장(통합 CLI) — 운전 조건이 6개인 FD002는 정규화 없이 경보 0/130이었고, 조건별 z-정규화로 104/130 회복.난이도는 결함 모드 수보다 운전 조건 수
• 센서 10개를 하나의 health index로 융합 — 단일 결함 모드 셋은 대폭 개선(FD001 94→100/100, FD002 104→130/130), 결함 모드가 2개인 셋은 오히려 악화.평균 융합의 전제가 깨지는 지점까지 그대로 기록

GitHub 저장소

배경

포트폴리오를 AI 도구 생태계에 연결 — Claude Desktop/Claude Code 등 MCP 클라이언트가 경력·프로젝트·논문 정보를 도구로 조회할 수 있도록 표준 프로토콜 서버 구현.

구현

도구 설계: read-only 도구 4개 — 구조화 조회(프로필/프로젝트/논문·특허) + BM25 문서 검색.검색 실패 시 다음 행동을 안내하는 actionable 오류 응답 설계.

경량 아키텍처: 의존성 2개(MCP SDK + rank_bm25)만으로 구성 — 임베딩 서버·외부 API·GPU 불필요, clone 후 30초 내 동작.추론은 클라이언트 LLM에 위임하고 서버는 결정적으로 유지.

• FastMCP 기반 stdio 서버, Pydantic 입력 검증, read-only 어노테이션
• 확정 사실(profile.json)과 서술형 문서 검색을 이원화한 구조
• Claude Code에 사용자 스코프로 등록해 실제 에이전트 세션에서 도구 호출을 검증 — 세션을 재생한 SVG 데모를 README에 수록
• RAG Agent와 동일 지식 베이스 공유 — RAG·MCP 두 노출 방식 비교 경험

성과

• 노션 export의 퍼센트 인코딩 경로가 무의미 토큰으로 쪼개져 길이 정규화 페널티를 유발하던 문제를 원문 정제로 해결 (토큰 7,653 → 6,310개, 18% 감소)
• 응답이 오는지만 보던 스모크 테스트를 내용 단언(프로젝트 수·특허 건수)으로 전환, 과정에서 구 사명 미인식 버그 발견·별칭 매칭 추가
• rag-agent의 에이전트가 이 서버를 클라이언트로 사용.제공자와 소비자 양쪽을 모두 구현

GitHub 저장소

배경

휴가나 부재 후 복귀한 직원이 단체방에 쌓인 업무 대화를 따라잡는 데 오랜 시간이 걸린다는 문제에서 출발.사내 메신저에 넣을 한국어 요약 모델 개발이 목표.

구현

모델 설계: 대화 요약은 BART, 문서 요약은 T5로 나눠 개발.대화 요약 파인튜닝에는 사전 학습 표현을 훼손하지 않는 R3F 정규화 기법을 적용.

데이터 파이프라인: 한국어 대화-요약 쌍 데이터 수집과 전처리, 임베딩 모델 선정까지 학습 파이프라인을 직접 구축.ROUGE 점수와 사내 인원 휴먼 평가를 품질 지표로 사용.

성과

• 사내 메신저에 요약 기능을 붙여 실제 적용
• 긴 사내 공지 문서를 한 줄 요약으로 압축, 실제 업무 대화는 2초대에 요약
• 카카오톡 대화 요약 기능과 나란히 비교해 유사한 품질의 요약을 확인한 데모 수행
• STT 결과 텍스트를 활용한 자연어 처리 기능 개발과 전처리·평가 환경 구축도 함께 수행

배경

AI 서비스·API 20여 개를 수동 배포해 한 번에 수 시간이 소요.자동화·스케일링·자원 효율 개선이 필요했고, 클러스터로 옮긴 뒤에는 무엇이 어디서 터졌는지 볼 수단도 함께 있어야 했음.

팀 구성과 담당

인프라 엔지니어 3인이 온프레미스에 사내 첫 Kubernetes 플랫폼을 구축.아래가 팀이 만든 전체 구성이고, 그중 관측성 계층이 본인 담당.

• 클러스터·네트워크 — MetalLB LoadBalancer, Ingress-nginx 라우팅 팀
• 스토리지 — NFS 기반 PV/PVC로 모델·데이터 영속 볼륨 관리 본인
• 배포 파이프라인 — GitLab → Jenkins·Argo Workflow → Harbor → ArgoCD GitOps 팀
• 지표·경보 — Prometheus 수집, Grafana 대시보드, AlertManager 경보 규칙 본인
• 로그 — Elasticsearch(ELK)와 Loki를 클러스터에 직접 설치해 수집·조회 환경 구성 본인

구현

• Prometheus로 클러스터·노드·워크로드 지표를 수집하고, Grafana 대시보드로 20여 개 모델의 상태를 한 화면에서 보게 구성
• AlertManager 경보 규칙을 세워 장애를 사람이 발견하기 전에 알리도록 전환
• 로그는 관리형 서비스 없이 클러스터에 Elasticsearch·Loki를 직접 설치·운영 — 온프레미스라 외부 로깅 SaaS를 쓸 수 없는 조건
• NFS 기반 PV/PVC로 모델 가중치·데이터 볼륨의 영속 저장을 구성 — 파드가 재시작돼도 모델을 다시 받지 않게
• 구축 이후 클러스터 장애 대응과 리소스 관리에 팀의 일원으로 참여

성과

• 3인 인프라 팀으로 회사 최초 Kubernetes 기반 AI 플랫폼을 구축하고, 수동 배포를 GitOps 자동화로 전환 팀 성과
• 지표와 대시보드, 경보, 로그까지 관측성 5종을 혼자 구축 (Prometheus, Grafana, AlertManager, Elasticsearch, Loki)
• NFS 기반 PV/PVC로 20여 개 모델의 가중치와 데이터 볼륨을 영속 관리
• 20개 이상 ML 모델이 도는 클러스터를 지표와 로그로 들여다볼 수 있게 만들어, 장애 원인 추적이 가능해짐

시스템 구조

배경

TTS 게이트웨이 TTFB를 절반 이하로 줄이며 손으로 하던 측정을 도구화.OpenAI 호환 엔드포인트(Ollama, vLLM 등)에 동시 부하를 걸어 TTFT·지연 percentile·처리량을 측정하는 CLI.

구현

측정 설계: asyncio + httpx로 동시성 수준별 스윕.스트리밍 청크 단위로 TTFT(첫 토큰까지 시간)와 tokens/s를 요청별 기록, p50/p95 집계.예열 요청으로 모델 로드 시간을 측정에서 분리.의존성은 httpx 하나, 차트는 SVG 직접 생성.

성과

• 로컬 Ollama(CPU) 기준선: 동시성 1에서 TTFT 0.62초, 7.6 tokens/s
• 동시성을 2·4로 올리자 TTFT는 7.9초·12.4초로 악화되는데 처리량은 8.1 tokens/s에 고정.요청이 병렬로 처리되지 않고 줄을 서고 있다는 신호
• 원인은 Ollama 기본 설정(NUM_PARALLEL=1)의 요청 직렬화.벤치마크 도구가 병목의 위치를 짚어냄
• NUM_PARALLEL=4로 서버 설정만 바꿔 같은 스윕을 재실행하니 TTFT p50이 12.4초에서 0.93초로, 합산 처리량이 8.1에서 22.9 tokens/s로 스케일.진단 → 설정 변경 → 재측정으로 루프를 닫음

GitHub 저장소

배경

자율주행 환경 인식에 3D 거리/높이 정보 필수.기존 2D 세그멘테이션의 한계로 인한 센서 퓨전 필요.

구현

모델 아키텍처: Trans-Unet (Transformer + U-Net 하이브리드) 설계로 LiDAR 포인트 클라우드 + 카메라 이미지 효과적 퓨전.Transformer 장거리 의존성 + U-Net 다중 스케일 피처 추출 결합.

연구 기여: 논문 2편 제1저자 게재 (한국자동차공학회 2022.11, 2023.04) 및 특허 2건 등록 (제1발명자).

성과

• 논문 2편 게재 (제1저자, 한국자동차공학회 2022.11, 2023.04)
• 특허 2건 등록 (제1발명자, 등록번호: 1025382250000, 1025382310000)

배경

국방 도메인 AI 모델 개발의 학습 데이터 부족 (보안 제약으로 수집 어려움).GAN 모드 붕괴 문제 및 범용 생성 모델의 도메인 불일치.

구현

모델 개발: Latent Diffusion 노이즈 스케줄 + 조건부 생성 + LoRA 파인튜닝.국방 이미지의 스타일, 배경, 객체 특성 학습으로 현실성 높은 합성 데이터 생성.

검증 및 평가: 합성 데이터를 실제 모델 학습에 적용하여 유효성 검증.

성과

• 우수 논문상 수상: "국방 데이터 확보를 위한 생성모델 Latent Diffusion 실험" (한국국방기술학회 2023.11)
• 합성 데이터 생성 자동화 파이프라인 구축
• 추가 논문: "GAN을 활용한 데이터 생성 연구 동향" (한국항공우주학회 2023)

생성 결과

배경

정찰/드론 영상에서 전차 자동 탐지 필요.기존 수동 분석의 시간 및 비용 문제.

구현

모델 개발: YOLOv5/v8 기반 전차 탐지 모델.다양한 조도, 각도, 배경 시나리오 강건성 확보를 위한 데이터 증강 및 하이퍼파라미터 튜닝.

모델 학습 및 검증: 국방 도메인 데이터 기반 학습 및 성능 검증.다양한 환경 시나리오에서의 탐지 강건성 확보.

성과

• YOLO 기반 전차 탐지 모델 개발 완료
• 데이터 증강 및 하이퍼파라미터 튜닝으로 탐지 강건성 확보

배경

과기정통부·NIA 주최, 연세대·서울대병원 주관 의료 AI 데이터톤.심전도(ECG) 데이터셋으로 부정맥 여부를 진단하는 AI 모델 개발 트랙에 참가.

구현

신호 전처리: 기저선 변동(Baseline Wandering) 제거 — 침식·팽창 연산 및 spline 보간, 주파수 노이즈 제거, 근전도 노이즈는 moving average로 평활화.

모델: 8개 lead 중 심전도 관찰에 유리한 lead I의 5,000차원 신호를 입력으로, 1-D Convolution Layer(filter 32, kernel 5)를 계층적으로 연결한 1D-CNN으로 주기적 feature를 추출해 정상/부정맥 이진 분류.

배경

공공 데이터 비식별화에 쓰이는 모자이크 처리는 원본 데이터의 정보 손실을 일으켜, Re-ID·행동 인식 등 얼굴 데이터가 필요한 후속 태스크에 활용하기 어려움.이를 해결하기 위해 AI로 생성한 가짜 얼굴로 원본 얼굴을 대체하는 비식별화 기법을 제안.

구현

거리 영상에서 보행자 얼굴 영역 검출 및 랜드마크 검출 → 생성 모델 기반 가짜 얼굴 합성으로 정보 손실을 최소화하면서 개인정보를 보호하는 라벨링 파이프라인.

배경

PDF/이미지 문서에서 표 영역 추출을 위한 OCR 학습 데이터 필요.수동 주석 작업의 병목 해결 필요.

구현

시스템 아키텍처: PyQt GUI 기반 Annotation Tool 설계 및 단독 개발.이미지 로딩, 라벨링, 데이터 저장 기능 구현.

AI 모델 개발: Tesseract 및 ViT 기반 표 영역 탐지, RNN 기반 테이블 셀 내 텍스트 추출 모델 개발.OCR 학습 데이터 생성 프로세스 자동화.

성과

• Annotation Tool 설계 및 단독 개발 (상용 서비스 투입 전 단계까지 참여)
• OCR 학습 데이터 생성 프로세스 자동화
• OCR 문서 인식 성능 개선
• 프로젝트 성공 성과금 수령

배경

금융 데이터 분석을 위한 고품질 데이터 필수.다중 소스 수집 데이터의 수동 정제 및 통합으로 인한 비효율.

구현

데이터 수집 & 정제: 금융 데이터 크롤링 및 수집.Pandas/NumPy 기반 결측값 처리, 이상치 제거, 형식 정규화.

자동화 파이프라인: 수집 → 정제 → 검증 → 저장 자동화.SQL 기반 데이터 관리.

성과

• 금융 데이터 자동 수집 파이프라인 구축
• 데이터 품질 검증 도구 개발
• 데이터 엔지니어링 역량 확보