AI 코드의 80/20 법칙: 왜 프로덕션 단계에서 시간의 80%를 소비하는가

저는 플레이그라운드(playground)에서는 완벽하게 작동하던 GPT-4 함수 호출(function call)이 프로덕션(production) 환경에서 조용히 실패하는 것을 목격했습니다. 출력값은 유효한 JSON이었습니다. 구조도 정확했습니다. 하지만 내용은 환각(hallucination)이었습니다. 문제를 인지하는 데 2시간이 걸렸고, 이를 잡아낼 가드레일(guardrail)을 구축하는 데 또 하루가 걸렸습니다.

그 순간은 제가 함께 일하는 모든 창업자에게 말해주는 교훈을 남겼습니다. AI 기능의 첫 20%는 시간의 20%만을 차지합니다. 마지막 20%는 시간의 80%를 차지합니다. 코드가 어려워서가 아닙니다. 코드는 쉬운 부분이기 때문입니다. 어려운 부분은 그 주변의 모든 것입니다.

저는 대규모 프로덕션 AI 파이프라인(pipeline)을 구축해 왔습니다. LLM 함수 호출(function calling)을 통해 매일 10,000개 이상의 채용 공고를 점수화하는 채용 정보 플랫폼, 한 세션에서 수십 개의 맞춤형 이력서를 생성하는 AI 이력서 맞춤 도구, 실시간 전사(transcription) 기능이 있는 회의 어시스턴트 등이 그것입니다. 모든 프로젝트는 동일한 패턴을 따랐습니다. 데모는 한 시간 만에 작동했지만, 프로덕션 시스템을 구축하는 데는 몇 주가 걸렸습니다.

그 마지막 80%가 실제로 어떤 비용을 치르게 하는지 알려드리겠습니다.

실제 데이터에서 깨져버린 프롬프트(Prompt)

여러분의 첫 번째 프롬프트는 테스트 케이스에서는 작동할 것입니다. 하지만 실제 데이터에서는 실패할 것입니다.

채용 정보 플랫폼을 만들 때, 저는 원문 채용 공고에서 구조화된 필드(structured fields)를 추출하기 위해 GPT-4 프롬프트를 작성했습니다. 회사 이름, 직함, 위치, 기술 스택 등입니다. 플레이그라운드에서는 완벽한 결과를 보여주었습니다. 그래서 배포했습니다.

한 시간도 채 되지 않아 파이프라인은 쓰레기 데이터를 생성하기 시작했습니다. 어떤 공고는 ATS(채용 관리 시스템) 소스에서 직함과 부서를 하나로 합쳐버리는 바람에 직함이 400자나 되었습니다. 또 다른 공고는 위치 필드에 "원격 - 분기별로 시카고 출장 가능해야 함"이라고 적혀 있었습니다. 제 프롬프트는 위치가 단일 도시 이름일 것이라고 가정했었습니다.

해결책은 더 나은 프롬프트가 아니었습니다. 그것은 계층적인 접근 방식(layered approach)이었습니다. 저는 LLM 호출 전에 입력 유효성 검사(input validation)를 추가하여 합리적인 길이를 초과하는 필드를 잘라냈습니다. 호출 후에는 출력 유효성 검사(output validation)를 추가하여 추출된 필드가 예상 패턴과 일치하는지 확인했습니다. 또한 신뢰도가 낮은 출력에 대해 수동 검토를 요청하는 재시도 메커니즘(retry mechanism)을 구축했습니다.

이제 제가 모든 LLM 추출 작업에 사용하는 패턴은 다음과 같습니다:

const extractionSchema = {
  type: "object",
  properties: {
...

이 스키마(schema)는 구조를 강제합니다. 검증(validation)은 예상치 못한 상황을 잡아냅니다. 이 단일 패턴만으로 추출 오류의 90%를 제거했습니다. 하지만 제대로 구현하기까지 세 번의 반복(iteration)이 필요했습니다.

아무도 말하지 않는 비용의 반전

여러분의 AI 기능은 예상보다 더 많은 비용이 들 것입니다. API 호출당 비용이 비싸기 때문이 아닙니다. 계획했던 것보다 훨씬 더 많은 호출을 하게 될 것이기 때문입니다.

저는 100만 개 이상의 매물에 대한 SEO를 개선하기 위해 AI 기반 채용 공고 재작성 파이프라인(pipeline)을 구축했습니다. 프로토타입(prototype) 비용은 몇 푼 되지 않았습니다. 하지만 프로덕션(production) 비용은 눈이 휘둥그레질 정도였습니다. 대규모 운영 시 발생하는 LLM 비용을 감당할 수 없었기에 파이프라인은 중단되었습니다. 재작성할 때마다 토큰(token)이 소비되었습니다. 100만 개의 매물 규모에서는 계산이 맞지 않았습니다.

그 경험을 통해 저는 기능이 출시된 후가 아니라, 첫날부터 비용을 생각하는 법을 배웠습니다.

제가 효과적이라고 본 해결책들은 다음과 같습니다:

• 배치 처리 (Batch processing). OpenAI의 Batch API는 비용을 50% 절감합니다. 워크로드(workload)가 실시간일 필요가 없다면 배치로 처리하세요.
• 모델 선택 (Model selection). 모든 작업에 GPT-4가 필요한 것은 아닙니다. 저는 재작성 파이프라인을 위해 23배 더 저렴한 대안으로 DeepSeek V4 Flash를 검토하고 있습니다. SEO 콘텐츠를 만들기에는 품질이 충분합니다.
• 캐싱 (Caching). 동일한 입력이 두 번 나타난다면, LLM을 두 번 호출하지 마세요. 출력을 캐싱하세요.
• 요청 셰이핑 (Request shaping). 입력을 필요한 최소한으로 줄이세요. 긴 컨텍스트 윈도우(context window)는 유혹적이지만, 모든 토큰에는 비용이 따릅니다.

이력서 맞춤화 프로젝트에서 저는 대량 생성 파이프라인에 GPT-4o-mini를 사용했습니다. 해당 특정 작업에 있어서는 품질이 GPT-4와 구별할 수 없을 정도였습니다. 비용은 아주 일부분에 불과했습니다. 핵심은 어떤 작업에 비싼 모델이 필요하고, 어떤 작업에는 필요하지 않은지를 아는 것입니다.

플레이그라운드(Playground)에서는 절대 일어나지 않는 오류

LLM은 비결정론적(non-deterministic)입니다. 타임아웃(time out)이 발생합니다. 속도 제한(rate limits)에 걸립니다. 빈 응답을 반환합니다. 환각(hallucination)을 일으킵니다. 여러분의 코드는 이 모든 상황을 처리할 수 있어야 합니다.

구직 게시판 플랫폼에서는 스코어링 파이프라인 (scoring pipeline)이 매일 10,000개의 작업을 실행합니다. OpenAI의 API는 가끔 429 Rate Limit (속도 제한) 에러를 반환합니다. 가끔 요청이 타임아웃 (timeout) 되기도 합니다. 가끔 모델이 함수 스키마 (function schema)와 일치하지 않는 응답을 반환하기도 합니다.

저는 지수 백오프 (exponential backoff)를 적용한 재시도 계층 (retry layer)을 구축했습니다. 에러율이 급증하면 파이프라인을 일시 중단하는 서킷 브레이커 (circuit breaker)를 추가했습니다. 기본 모델이 실패할 경우 더 간단한 모델 (GPT-4o-mini)을 사용하는 폴백 (fallback) 로직을 작성했습니다. 이제 시스템은 사람의 개입 없이도 실패 상황을 유연하게 처리합니다.

async function callWithRetry(prompt: string, maxRetries = 3): Promise<LLMResponse> {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
...

이 코드는 단순합니다. 하지만 언제 재시도하고 언제 실패할지를 결정하는 것은 단순하지 않습니다. 속도 제한 (rate limits) 상황에서는 재시도하십시오. 잘못된 입력 (invalid input)에 대해서는 빠르게 실패 (fail fast) 하십시오. 이 차이가 중요합니다.

평가 문제 (The Evaluation Problem)

여러분의 AI 기능이 프로덕션 (production) 환경에서 올바르게 작동하고 있다는 것을 어떻게 알 수 있을까요?

정답은 "몇 가지 예시를 확인하는 것"이 아닙니다. 정답은 자동화된 평가 (automated evaluation)입니다.

이력서 맞춤 제작 프로젝트에서, 저는 조건부 존재 플래그 (conditional presence flags)를 사용하여 안티-환각 (anti-hallucination) 스키마를 구축했습니다. LLM은 모든 필드에 대해 has_* 가드 (guard)를 출력합니다. 만약 has_company가 false라면, company 필드는 반드시 null이어야 합니다. 이는 모델이 정보를 조작하는 것을 방지합니다. 모든 출력은 사용자에게 도달하기 전에 이 스키마에 따라 검증됩니다.

구직 게시판 스코어링 파이프라인의 경우, 매일 점수가 매겨진 목록의 1%를 샘플링하여 수동 검토 (manual reviews) 결과와 비교하는 품질 게이트 (quality gate)를 구축했습니다. 에러율이 임계값 (threshold)을 초과하면 알림이 발생합니다. 이를 통해 드리프트 (drift) 현상이 사용자에게 영향을 미치기 전에 포착할 수 있습니다.

평가는 대부분의 팀이 건너뛰는 마지막 20%의 영역입니다. 그들은 기능을 출시하고, 수동으로 테스트한 뒤, 완료되었다고 생각합니다. 그러다 3주 뒤, 사용자들은 AI 성능이 나빠지고 있다고 불평하기 시작합니다. 모델이 업데이트되었습니다. 데이터가 변했습니다. 프롬프트 (prompt)가 저하되었습니다. 평가가 없다면 너무 늦기 전까지는 이를 알 수 없을 것입니다.

실제 비용 (The Real Cost)

AI 기능의 마지막 20%는 단순한 버그 수정이 아닙니다. 그것은 하나의 시스템입니다.

입력 검증 (input validation), 출력 검증 (output validation), 재시도 로직 (retry logic), 비용 모니터링 (cost monitoring), 모델 선택 (model selection), 캐싱 (caching), 평가 (evaluation), 그리고 드리프트 탐지 (drift detection)가 필요합니다. 아직 상상하지 못한 예외 케이스 (edge cases)를 처리해야 합니다. 또한 당신의 AI가 언제 틀리는지를 알아야 합니다.

저는 여러 프로젝트를 통해 이러한 시스템들을 구축해 왔습니다. 한 채용 정보 플랫폼은 수동 관리 없이도 매일 10,000개의 매물을 처리합니다. 이력서 맞춤 제작 서비스는 환각 데이터 (hallucinated data) 없이 수십 개의 맞춤형 이력서를 병렬로 생성합니다. 회의 어시스턴트는 실시간 전사 (transcription) 및 분석을 스트리밍합니다. 이 모든 것들은 마지막 80%의 과정이 필요했습니다.

만약 당신의 팀이 데모에서는 작동하지만 프로덕션 (production) 단계에서는 실패하는 AI 기능으로 고군분투하고 있다면, 그것이 바로 제가 도움을 드릴 수 있는 부분입니다. 함께 의견을 나누게 된다면 기쁘겠습니다.

작성자: Abdul Rehman, 프로덕션 SaaS, MVP 및 AI 자동화를 구축하는 풀스택 AI 엔지니어. 더 자세한 내용은 PrimeStrides에서 확인하세요.