AI 데모가 작동한 뒤에 무엇이 깨지는가

Source: Dev.to

몇 주 전, 나는 작은 AI API를 만들었습니다. 별다른 것이 아니라 단순한 엔드포인트였을 뿐입니다.

response = llm(prompt)

잘 동작했습니다. 요청이 들어왔고, 모델이 응답했습니다. 모든 것이 괜찮아 보였지만—두 번째 주가 되면서 상황이 달라졌습니다.

첫 번째 질문

팀원이 물었습니다:

“어떤 요청이 이 출력을 생성했나요?”

로그를 확인했습니다. 유용한 내용이 없었습니다.

• 요청 ID 없음
• 추적 정보 없음
• 프롬프트와 출력 사이에 연결 고리 없음

시스템은 작동했지만 — 추적할 수 없었습니다.

두 번째 질문

“왜 어제 우리 AI 청구서가 급증했나요?”

우리는 API 래퍼를 통해 모델을 호출했지만, 다음을 기록하지 않았습니다:

• 토큰 사용량
• 모델 가격
• 요청 수준 비용

우리는 보이지 않게 비용이 발생하는 AI 시스템을 구축한 것이었습니다.

세 번째 질문

그때 좀 더 미묘한 일이 일어났습니다. 사용자가 출력이 잘못된 것처럼 보인다고 보고했습니다. 모델은 성공적으로 응답했지만 답변은 명백히 유용하지 않았습니다. 이것은 또 다른 질문을 제기했습니다:

“모델 응답이 허용 가능한지 어떻게 알 수 있나요?”

우리는 알지 못했습니다. API는 모델이 응답했는지 여부만 알았을 뿐, 결과가 의미가 있는지는 알지 못했습니다.

깨달음

모델 자체가 문제가 아니었습니다. 모델을 둘러싼 시스템이 문제였습니다. AI API는 전통적인 API와 근본적으로 다릅니다. 세 가지 운영상의 과제를 도입합니다:

이 문제들을 해결하지 않으면 AI 시스템은 빠르게 운영하기 어려워집니다. 그래서 이 문제를 탐구하기 위해 작은 레퍼런스 프로젝트를 만들었습니다. 저는 이를 Maester 라고 이름 붙였습니다.

최소 신뢰성 아키텍처

신뢰할 수 있는 AI API 요청은 몇 가지 구조화된 단계를 거쳐야 합니다.

Client Request
      ↓
API Middleware (request_id + trace_id)
      ↓
Route Handler
      ↓
Model Gateway
      ↓
Cost Metering
      ↓
Evaluation
      ↓
Structured Logs
      ↓
Response

각 단계는 운영상의 명확성을 추가합니다.

1. 가시성: AI 요청을 추적 가능하게 만들기

첫 번째 기본 요소는 가시성입니다. 모든 요청은 추적 가능해야 합니다.

Maester에서는 미들웨어가 request_id와 trace_id를 요청 컨텍스트에 붙입니다:

request_id = new_id()
trace_id   = start_trace()

이러한 식별자는 전체 요청 수명 주기 동안 전파됩니다. 작업은 스팬으로 감싸집니다:

with span("model_generate", model=model_name) as sp:
    response = gateway.generate(prompt)

스팬은 다음을 기록합니다:

• 작업 이름
• 지속 시간
• 속성

예시 로그 출력:

{
  "event": "span_end",
  "span": "model_generate",
  "duration_ms": 412,
  "model": "gpt-4o-mini"
}

이를 통해 시간이 어디에 소비되는지 즉시 파악할 수 있습니다.

2. Cost Metering: AI Systems Spend Money Per Request

전통적인 API와 달리, AI 요청은 직접적인 금전적 비용이 발생합니다. 토큰 사용량은 실제 지출로 연결되므로, 모든 요청은 비용 기록을 생성해야 합니다.

Example:

cost_record = meter.record(
    model=model_name,
    input_tokens=usage.input_tokens,
    output_tokens=usage.output_tokens,
)

The meter uses a pricing catalog:

MODEL_PRICING = {
    "gpt-4o-mini": {
        "input_per_1k": 0.00015,
        "output_per_1k": 0.00060,
    }
}

The request returns:

{
  "input_tokens": 1200,
  "output_tokens": 350,
  "total_cost_usd": 0.00042
}

Now the API can answer the critical question: “What did this request cost?”
이제 API는 중요한 질문에 답할 수 있습니다: “이 요청의 비용은 얼마였나요?”

3. 평가: 성공적인 호출이 항상 올바른 것은 아니다

모델이 성공적으로 응답하더라도 출력이 사용 불가능할 수 있습니다. 바로 여기서 평가가 필요합니다.

Maester에서는 응답이 간단한 평가자를 통과합니다:

result = evaluator.evaluate(prompt, response)

현재 확인 항목은 다음과 같습니다:

• 비어 있지 않은 응답
• 필수 용어 존재 여부
• 최대 길이 제한

예시 평가 결과:

{
  "passed": true,
  "checks": {
    "non_empty": true,
    "required_terms": true,
    "max_length": true
  }
}

시스템이 커짐에 따라 이 패턴은 더욱 중요해집니다. 평가는 다음과 같이 확장될 수 있습니다:

• 구조화된 출력 검증
• 환각(허위 정보) 탐지
• 정책 시행
• 안전 필터

왜 OpenTelemetry만 사용하지 않을까?

프로젝트 초기에 OpenTelemetry를 도입하는 것을 고민했지만, … 때문에 직접 만든 솔루션을 사용하기로 결정했습니다. (원본 내용은 여기서 끊깁니다)

OpenTelemetry vs. Maester

OpenTelemetry는 다른 문제를 해결합니다. 제공하는 기능은 다음과 같습니다:

• Distributed tracing
• Metrics exporters
• Telemetry pipelines

Maester (GitHub)는 application‑level reliability primitives에 초점을 맞춥니다. 다음과 같은 질문에 답하는 레이어라고 생각하면 됩니다:

이러한 신호는 나중에 전체 관측성 스택으로 내보낼 수 있습니다.

The Worker Path

AI 시스템은 HTTP 요청 안에서만 실행되는 경우는 드뭅니다. 백그라운드 작업은 종종 다음과 같이 실행됩니다:

• Batch inference
• Evaluation pipelines
• Data‑enrichment tasks

Maester는 worker example을 포함하고 있어 동일한 신뢰성 프리미티브가 적용된다는 것을 보여줍니다. 워커 실행은 동일한 도구를 사용합니다:

• Tracing
• Cost metering
• Evaluation
• Structured logs

Reliability should not depend on the entrypoint.

What This Architecture Achieves

몇 개의 모듈만으로도 시스템은 다음 질문에 답할 수 있습니다:

이러한 신호는 블랙‑박스 AI API를 추적 가능한 시스템으로 변환합니다.

Final Thought

AI와 관련된 대부분의 신뢰성 논의는 모델에 초점을 맞추지만, 신뢰성은 종종 모델 품질이 아니라 시스템 설계에서 비롯됩니다.

다음과 같은 내용을 기록하는 간단한 아키텍처:

1. 무엇이 일어났는지
2. 그 비용
3. 결과가 허용 가능한지

는 AI 시스템 운영 방식을 크게 개선할 수 있습니다.

이러한 아이디어를 시스템에 일찍 도입할수록, 시스템을 유지보수하기가 더 쉬워집니다.

참고: 이 글은 원래 제가 공개적으로 구축한 AI SaaS 인프라스트럭처 시스템인 Maester의 설계를 문서화하는 엔지니어링 블로그에 게시되었습니다.