Thready Rebuild
AI 콘텐츠 생성 backend를 전면 재구축하고, cutover 이후 개발·운영을 전담한 케이스.
- Role
- Rebuild · Ownership
- Scope
- Generation Quality
- Stack
- FastAPI · LLM
- Status
- 운영 중
01
문제
ProblemAI 콘텐츠 생성 제품 Thready의 backend를 인계받았을 때, 생성 품질이 프롬프트·모델 호출에 흩어져 있어 무엇이 좋은 출력인지 판정하고 회귀를 잡을 기준이 없었다. 프롬프트는 문자열로 조립되어 타입 안전성과 재사용이 약했고, 실패·품질 저하를 관측할 로깅 축도 부족했다.
그래서 부분 수정이 아니라 backend 전면 재구축과 cutover를 선택하고, 이후 개발·운영을 전담하기로 했다.
02
결정
Decision품질을 “감”이 아니라 시스템으로 다루기 위해 세 가지를 결정했다.
- Typed Prompt프롬프트를 문자열이 아닌 typed prompt builder로 구성 — 입력 계약을 타입으로 고정하고 재사용 가능하게 만든다.
- Judge LoopLLM judge 기반 평가 루프를 도입 — 출력 품질을 판정 가능한 축으로 만들어 회귀를 감지한다.
- Observability관측 로깅을 표준으로 심어 — 생성 흐름과 실패를 사후에 추적할 수 있게 한다.
03
시스템
System결정을 실제 backend 구조로 옮긴 결과, 생성 품질이 재구축된 FastAPI backend 위의 시스템으로 자리 잡았다.
Typed Prompt Builder
프롬프트 조립을 타입으로 계약화 — 입력 누락·형 오류를 호출 전에 차단하고 재사용을 표준화.
LLM Judge · 평가 루프
생성 출력을 judge로 채점하는 루프 — 품질을 판정 가능한 값으로 만들어 회귀 감지에 사용.
관측 로깅
생성 흐름·실패 지점을 로깅 — 운영 중 문제를 사후 추적하고 원인을 좁힘.
Rebuild + Cutover
부분 패치가 아닌 전면 재구축 후 cutover — 이후 개발·운영을 전담하는 단일 오너십.
04
운영 근거
Operating Evidence재구축 이후 이 backend는 월 수만 건 규모의 요청을 처리하는 production으로 운영되고 있다. 아래 근거 chip을 눌러 claim 요약을 확인할 수 있다.