실제로 프로덕션에서 살아남는 4가지 LLM 워크플로우

대부분의 팀은 돈을 벌어다 주거나 시간을 절약해 주는 지루한 워크플로우 하나를 갖추기도 전에 마법 같은 어시스턴트를 출시하려고 시간을 낭비합니다. 프로덕션에서의 승리는 보통 좁은 범위의 작업, 엄격한 가드레일(Guardrails), 그리고 명확한 성공 지표에서 나옵니다. 만약 당신이 LLM 기능을 데모 단계를 넘어 실제 서비스로 구현하는 책임을 맡고 있다면, 트래픽이 몰리고, 입력값이 지저분하며, 사용자들이 짜증을 내는 상황에서도 버텨내는 제가 목격한 패턴들은 다음과 같습니다.

1. 신뢰성이 필요할 때는 대화보다 추출(Extraction)이 유리합니다.
   많은 비즈니스 데이터가 PDF, 이메일, 티켓, 양식, 그리고 채팅 기록 속에 갇혀 있습니다. LLM은 산문(Prose)을 요구하는 대신 스키마(Schema)를 요구하기 시작하면, 지저분한 텍스트를 구조화된 객체(Structured objects)로 변환하는 데 매우 능숙합니다. 핵심은 모델이 한 가지 일만 하도록 만드는 것입니다: 읽고, 정규화(Normalize)하고, 검증 가능한 필드를 반환하는 것입니다. 사람의 검토가 필요한 경우가 아니라면 모델에게 스스로를 설명하라고 요구하지 마세요. 프로덕션 환경에서 설명(Explanation)은 더 긴 출력, 더 높은 비용, 그리고 포맷 드리프트(Format drift)가 발생할 여지를 만듭니다.

다음과 같은 프롬프트는 이미 대부분의 첫 시도보다 낫습니다:

system : |
원문 텍스트에서 지원 케이스 세부 정보를 추출하세요. 유효한 JSON만 반환하세요. 필드가 누락된 경우 null을 사용하세요.

user : |
스키마: {{ "customer_name": string | null, "issue_type": string | null, "priority": "low" | "medium" | "high" | null, "refund_requested": boolean | null }}
원문 텍스트: {{ticket_text}}

그 다음, 신뢰할 수 없는 모든 입력값을 검증하듯이 응답을 검증하세요:

from pydantic import BaseModel, ValidationError

class TicketFields(BaseModel):
customer_name: str | None
issue_type: str | None
priority: str | None
refund_requested: bool | None

raw = llm_extract(ticket_text)
try:
fields = TicketFields.model_validate_json(raw)
except ValidationError:
fields = None

이 패턴이 작동하는 이유는 모델이 모호한 언어(Fuzzy language)를 처리하는 동안, 애플리케이션은 여전히 계약(Contract)을 제어하기 때문입니다. 검증에 실패하면 더 좁은 범위의 프롬프트로 재시도하거나 해당 케이스를 수동 검토로 보냅니다. 그것이 바로 느낌(Vibe)이 아닌 진짜 시스템입니다.

초안 생성 (draft generation)은 결정론적 계층 (deterministic layer)이 사실 관계를 소유할 때 제대로 작동합니다. 팀들은 모델에게 고객 이메일, 장애 요약 (incident summaries), 또는 릴리스 노트 (release notes)를 기억(memory)에서 직접 생성하도록 요청할 때 낭패를 봅니다. 해결책은 간단합니다. 사실 수집 (fact gathering)과 언어 생성 (language generation)을 분리하는 것입니다. 먼저 결정론적인 컨텍스트 객체 (context object)를 구축하십시오. 신뢰할 수 있는 시스템으로부터 티켓 필드, 데이터베이스 값, 최신 주문 상태, 또는 장애 타임라인 (incident timeline)을 가져옵니다. 그런 다음 모델에게 해당 컨텍스트를 사람이나 다운스트림 도구 (downstream tool)를 위한 문구로 변환하도록 요청하십시오.

def build_context ( ticket , order , policy ):
    return {
        " customer " : ticket . customer_name ,
        " issue " : ticket . issue_type ,
        " order_status " : order . status ,
        " eligible_refund " : policy . allows_refund ( order ),
        " refund_amount " : order . refund_amount ,
    }

prompt = f """
Write a support reply in plain English. Use only these facts: { build_context ( ticket , order , policy ) } Do not invent policy details. Keep it under 120 words.
"""

reply = llm_generate ( prompt )

이제 모델은 자신이 가장 잘하는 영역인 스타일과 합성 (synthesis)을 수행하고 있습니다. 자격 규칙, 가격, 계정 상태, 그리고 정책 로직은 여전히 귀하의 소프트웨어가 소유합니다. 이것이 유용한 어시스턴트와 리스크 (liability) 사이의 차이입니다.

LLM 분류 (triage)는 신뢰도 (confidence)가 전달 (handoff)을 제어할 때 강력합니다.
가장 좋은 실용적 용도 중 하나는 1차 분류 (first pass triage)입니다: 티켓 분류, 알림 라우팅 (route alerts), 피드백 라벨링, 또는 리드 (leads) 점수 산정 등입니다. 실수는 모델이 모든 결정을 내리도록 강제하는 것입니다. 귀하는 신뢰도 임계값 (confidence thresholds)과 탈출구 (escape hatch)를 원해야 합니다. 깔끔한 패턴은 라벨과 신뢰도 점수를 모두 요청한 다음, 점수 구간 (score bands)에 따라 라우팅하는 것입니다. 높은 신뢰도는 자동화된 처리를 거칩니다. 중간 신뢰도는 모델의 제안이 첨부된 대기열 (queue)로 이동합니다. 낮은 신뢰도는 기존 프로세스로 돌아갑니다(fall back). 이것은 귀하에게 업그레이드 경로를 제공합니다. 보수적으로 시작하여 오류를 검토하고, 첫날부터 전체 워크플로우를 거는 대신 점진적으로 더 많은 카테고리를 자동화할 수 있습니다.

사람들이 실제로 실수하는 부분
모델이 주요 문제인 경우는 드뭅니다.

끔찍한 실패는 대개 그 주변의 모든 것에서 발생합니다. 첫째, 제품 변경을 통해 프롬프트 드리프트 (Prompt Drift)가 몰래 스며듭니다. 누군가 새로운 필드를 추가하고, 다른 팀이 상태(status) 이름을 변경하지만, 아무도 프롬프트나 스키마 (Schema)를 업데이트하지 않습니다. 기능은 쉬운 케이스에서는 여전히 작동하기 때문에, 오류는 조용히 방치됩니다. 둘째, 팀들이 적대적 입력 (Adversarial Inputs)을 건너뜁니다. 그들은 깨끗한 예시로 테스트할 뿐, OCR 쓰레기 데이터, 비꼬는 고객, 혼합된 언어, 복사된 이메일 체인, 또는 지원 박스에 붙여넣은 로그 데이터로 테스트하지 않습니다. 여러분의 평가 세트 (Eval Set)는 가장 멋진 데모가 아니라, 최악의 화요일 상황처럼 보여야 합니다. 셋째, 사람들은 재시도 (Retries), 속도 제한 (Rate Limits), 그리고 타임아웃 (Timeout) 동작에 대한 예산을 책정하지 않습니다. 모델 호출이 실패하면 요청은 어떻게 됩니까? 작업을 버립니까, 안전하게 재시도합니까, 아니면 중복을 생성합니까? 프로덕션 시스템은 더 멋진 프롬프트가 필요하기 훨씬 전부터 멱등성 키 (Idempotency Keys)와 큐 세맨틱스 (Queue Semantics)가 필요합니다. 넷째, 무엇이 '좋은 것'인지에 대해 아무도 합의하지 않습니다. "도움이 됨"은 지표 (Metric)가 아닙니다. 측정 가능한 것을 선택하십시오: 정확한 필드 정확도, 처리 시간 단축, 첫 응답 품질 점수, 디플렉션 레이트 (Deflection Rate), 또는 인간 수용률 (Human Acceptance Rate). 점수를 매길 수 없다면, 개선할 수도 없습니다. 4. 검색 (Retrieval)은 유용하지만, 문서 위생 (Document Hygiene)을 먼저 해결한 후에만 유용합니다. 많은 팀이 검색 증강 생성 (RAG, Retrieval Augmented Generation)으로 서둘러 뛰어들고, 답변이 부실하면 모델을 탓합니다. 대개 진짜 문제는 쓰레기 같은 소스 자료입니다. 실행 지침 (Runbooks)이 충돌하고, 문서가 오래되었으며, 명명 규칙이 일관되지 않다면, 검색은 단지 나쁜 컨텍스트 (Context)를 더 빠르게 전달할 뿐입니다. 청크 크기 (Chunk Sizes)를 튜닝하는 데 일주일을 쓰기 전에, 코퍼스 (Corpus)를 정제하십시오. 중복을 제거하고, 소유권을 추가하고, 업데이트 날짜를 찍고, 거대한 페이지를 안정적인 섹션으로 나누십시오. 그런 다음 검색 범위를 좁게 유지하십시오. 컨텍스트를 모델로 보내기 전에 적절한 제품 영역, 고객 등급, 또는 서비스 경계 내에서 검색하십시오. 작고 깨끗한 코퍼스가 거대하고 지저분한 코퍼스를 이깁니다. 매번 말입니다. 시간이 지나도 잘 버티는 스택. 결과를 얻기 위해 거대한 플랫폼이 필요하지는 않습니다.

대부분의 팀은 다음과 같은 간단한 스택으로 충분합니다: 비동기 작업 (asynchronous jobs)을 위한 큐 (queue), 모델 출력 (model output)을 위한 타입 지정 검증 (typed validation), 버전 관리 (version control) 시스템 내의 프롬프트 템플릿 (prompt templates), 지연 시간 (latency)·토큰 사용량 (token use)·실패 (failures) 추적 (tracing), 신뢰도가 낮은 케이스 (low confidence cases)를 위한 리뷰 UI (review UI), 프롬프트나 모델을 변경하기 전의 오프라인 평가 (offline evals). 그 스택은 의도적으로 지루하게 설계되었습니다. 당신의 기능이 고객이나 내부 운영에 직접 닿을 때는 지루한 것이 좋습니다. 만약 이번 주에 하나의 실용적인 LLM 프로젝트를 선택한다면, 당신의 팀이 이미 이해하고 있는 워크플로우 (workflow) 상의 추출 (extraction) 또는 분류 (triage)부터 시작하세요. 베이스라인 (baseline)을 계측 (instrument)하고, 신뢰도가 높은 부분 (high confidence slice)만 자동화하며, 매주 금요일마다 놓친 부분 (misses)을 검토하세요. 한 달이 지날 때쯤이면, 실제로 시간을 절약해주거나 혹은 배포해서는 안 된다는 깔끔한 근거를 제공하는 시스템을 갖게 될 것입니다. 오늘, 반복적인 텍스트 입력이 있는 큐 (queue) 하나를 선택하고, 스키마 (schema) 또는 라벨 세트 (label set)를 정의한 뒤, 첫 100개의 예시를 평가 파일 (eval file)에 넣으세요.