Python으로 공부하는 OpenAI 26편 — FastAPI + OpenAI 서비스, 출시 후 첫 90일 안에 무엇을 자동화해야 할까?

Python으로 공부하는 OpenAI 26편 — FastAPI + OpenAI 서비스, 출시 후 첫 90일 안에 무엇을 자동화해야 할까?

이번 글도 계속 같은 방식으로 갑니다.
질문형 제목으로 시작하고, 첫 문단에서 바로 답하고, 본문은 체크리스트 중심으로 정리하고, 마지막엔 FAQ·출처·추천 태그까지 넣겠습니다. 이런 구조가 AI가 답변 재료로 가져가기 좋은 형태라는 점은 올려주신 문서가 강조한 포인트이기도 합니다.

한 줄 요약

FastAPI + OpenAI 서비스를 출시한 뒤 첫 90일에는 새 기능을 무작정 늘리기보다, usage/cost 집계, prompt 캐시 안정화, background 처리, batch 작업, 대표 평가셋, 장애 대응 문서를 우선 자동화하는 편이 훨씬 낫습니다. OpenAI는 새 프로젝트에 Responses API부터 시작하라고 권장하고, 운영 단계에서는 production best practices, prompt caching, batch, rate limits, evals를 별도 주제로 다루며 점진적인 운영 자동화를 권합니다. (OpenAI 개발자)

---

이 글에서 다루는 내용

• 출시 후 90일 안에 꼭 자동화해야 할 것
• 무엇은 수동으로 두고, 무엇은 빨리 자동화해야 하는지
• FastAPI 기준으로 어떤 자동화가 비용과 운영에 가장 도움이 되는지
• 실행 가능한 점검 코드 예제
• FAQ

---

왜 “자동화”를 90일 안에 봐야 할까?

출시 직후 30일은 보통 관찰의 시간입니다.
누가 쓰는지, 뭐가 비싼지, 어디가 느린지 보는 시기죠. 그런데 30일이 지나도 여전히 사람이 손으로만 보고 있다면, 그다음부터는 같은 문제를 반복해서 겪기 쉽습니다.

OpenAI는 production best practices에서 운영 단계의 핵심으로 비용, 지연, 보안, 아키텍처를 함께 다루고, prompt caching과 batch는 각각 latency/cost 절감 수단으로 별도 설명합니다. FastAPI도 요청 응답 이후에 처리할 작업에는 BackgroundTasks를 쓸 수 있다고 안내합니다. 즉, “관찰했다면 다음은 자동화”가 자연스러운 순서입니다. (OpenAI 개발자)

---

먼저 결론부터: 첫 90일 자동화 우선순위

제가 추천하는 현실적인 우선순위는 이렇습니다.

1. usage / cost 로그 자동 수집
2. 에러 분류와 알림 자동화
3. background 처리 분리
4. 반복 작업 batch 전환
5. prompt prefix 안정화
6. 대표 eval 세트 자동 실행
7. runbook 기반 점검 자동화

이 순서가 좋은 이유는 단순합니다.
기능 추가보다 먼저 돈 새는 곳, 느린 곳, 자주 실패하는 곳을 자동으로 잡아줘야 이후 개발이 덜 흔들리기 때문입니다. OpenAI pricing은 input, cached input, output 비용을 분리해 보여주고, prompt caching은 반복 prefix가 있으면 비용과 지연을 줄일 수 있다고 설명합니다. Batch는 대량 비동기 작업에 더 높은 rate limits와 50% 낮은 비용을 제공한다고 안내합니다. (OpenAI 개발자)

---

1. 가장 먼저 자동화할 것: usage / cost 수집

이건 거의 무조건 1순위입니다.
사람이 대시보드 들어가서 가끔 확인하는 정도로는 금방 놓칩니다.

OpenAI cookbook은 Usage API와 Costs API로 사용량과 비용을 시각화하는 예제를 제공하고, deployment checklist는 운영 단계에서 usage와 costs를 모니터링하라고 안내합니다. 즉, 첫 90일 안에 최소한 “매일 자동 집계” 정도는 붙이는 편이 좋습니다. (OpenAI 개발자)

자동화 포인트

• endpoint별 요청 수
• model별 사용량
• input / output / cached input tokens
• 하루 총 비용
• 사용자별 상위 사용량
• RAG endpoint와 일반 endpoint 비용 비교

왜 이게 먼저인가

이게 있어야 나중에
“RAG가 비싼가?”
“출력이 너무 긴가?”
“캐시가 안 먹나?”
를 숫자로 말할 수 있습니다.

---

2. 두 번째 자동화: 에러를 “모아보는 것”이 아니라 “분류해서 알리는 것”

운영 초반엔 에러가 나도 하나하나 로그를 보는 경우가 많습니다.
그런데 90일이 넘어가면 이 방식이 너무 비효율적입니다.

OpenAI Python 라이브러리는 일부 오류에 대해 기본 재시도를 제공하고, rate limits 가이드는 429에 대해 random exponential backoff를 권장합니다. 이 말은 곧, 운영에서는 오류를 적어도 재시도 가능한 것 / 즉시 실패해야 하는 것 / 권한/설정 문제 정도로 나눠 봐야 한다는 뜻입니다. (OpenAI 개발자)

자동화 포인트

• 401/403: 키/권한 문제 즉시 알림
• 429: rate limit 경고
• timeout / 5xx: 일시 장애 집계
• validation error: 입력 구조 문제 집계
• worker failed job 수 알림

여기서 중요한 것

에러 “개수”만 모으지 말고, 에러 타입별로 분류해야 합니다.

---

3. 세 번째 자동화: background 처리 분리

반응형

FastAPI는 BackgroundTasks를 통해 응답 이후 작업을 실행할 수 있다고 설명합니다. 다만 문서에서도 이 방식은 요청 후 간단히 뒤에서 처리해도 되는 작업에 적합하다고 안내합니다. 긴 OpenAI 작업, 문서 색인, 대량 생성처럼 무거운 일은 별도 worker나 job 구조로 나누는 편이 더 낫습니다. (FastAPI)

출시 후 90일 안에 분리할 만한 작업

• 파일 업로드 후 색인
• 긴 문서 요약
• 대량 태깅
• 벡터 스토어 업로드
• 후처리 저장
• 주기적 usage 리포트 생성

왜 이걸 자동화해야 하나

이걸 계속 API 요청 안에서 처리하면:

• p95 latency가 늘고
• retry가 꼬이고
• 사용자 경험이 나빠지고
• worker 적체가 API 장애처럼 보일 수 있습니다

---

4. 네 번째 자동화: 반복 작업은 batch로 돌릴지 검토

OpenAI는 Batch를 대량 비동기 작업용으로 설명하며, input file 기반으로 많은 요청을 한 번에 처리할 수 있고 비용이 일반 실시간 대비 50% 낮을 수 있다고 안내합니다. (OpenAI 개발자)

batch 후보 작업

• 밤마다 문서 임베딩
• FAQ 대량 요약
• 콘텐츠 태깅
• 평가셋 주기 실행
• 백필(backfill) 작업

batch를 검토해야 하는 이유

실시간 응답이 필요 없는 작업을 계속 일반 요청으로 보내면:

• rate limit을 더 빨리 소모하고
• 비용이 더 들고
• API 서버와 worker가 불필요하게 바빠집니다

즉, 첫 90일 안에
“이건 진짜 실시간이어야 하나?”
를 한 번 꼭 따져보는 게 좋습니다.

---

5. 다섯 번째 자동화: prompt prefix를 안정화해서 캐시 이점 챙기기

OpenAI prompt caching은 자동으로 동작하지만, 반복되는 긴 prefix가 있을 때 효과가 큽니다. cookbook 예제는 캐시 히트가 정확히 같은 prefix에서 의미 있게 발생하고, 길이가 충분히 긴 프롬프트에서 특히 중요하다고 설명합니다. (OpenAI 개발자)

자동화라기보다 운영 규칙에 가까운 것

• system prompt 버전 관리
• prefix 템플릿 고정
• request 앞부분에 가변 문자열 최소화
• prompt_cache_key 일관성 유지

왜 첫 90일 안에 보냐

초반에는 기능에 집중하느라 prompt가 자주 흔들립니다.
그런데 어느 정도 기능이 자리 잡으면, 이제는 같은 요청 구조를 안정화해서 비용과 latency를 줄일 타이밍입니다.

---

6. 여섯 번째 자동화: 대표 eval 세트 정기 실행

OpenAI evals와 agent evals 가이드는 대표 사례 기반 데이터셋, graders, eval runs를 조합해 시스템 품질을 반복 측정하라고 설명합니다. trace grading 문서는 traces로 실패 패턴을 먼저 보고, 그다음 eval loop로 들어가라고 안내합니다. (OpenAI 개발자)

자동화 포인트

• 대표 질문 10~30개 세트 보관
• 주요 기능 변경 시 eval 재실행
• prompt/tool definition 수정 전후 비교
• RAG 품질 regression 점검
• tool selection / argument correctness 체크

왜 90일 안인가

이 시기부터는 “되는 것 같음”이 아니라
“이번 수정이 품질을 깼는지 안 깼는지”를 봐야 하기 때문입니다.

---

7. 일곱 번째 자동화: 운영 체크리스트를 코드로 돌리기

이건 생각보다 많이 안 하는데, 진짜 효과 좋습니다.
사람이 runbook을 읽는 것도 중요하지만, 반복 점검은 코드가 해주는 편이 낫습니다.

예:

• prod에서 docs 비활성 확인
• 필수 env 존재 확인
• vector store id 존재 확인
• worker heartbeat 확인
• 최근 failed jobs 수 확인

이건 24편에서 다룬 출시 점검표와도 바로 이어집니다. OpenAI deployment checklist가 점검 항목을 운영 전/후로 나눠 보여주듯, 앱 쪽에서도 “자동 점검 스크립트”를 만드는 편이 좋습니다. (OpenAI 개발자)

---

지금 바로 써볼 수 있는 “90일 자동화 점검” 예제 코드

아래 코드는 단순하지만,
지금 서비스 로그를 보고 “무엇부터 자동화할지” 우선순위를 빠르게 확인하는 데 쓸 수 있습니다.

import json
from collections import Counter, defaultdict
from pathlib import Path
from statistics import mean


def load_jsonl(path: str) -> list[dict]:
    rows: list[dict] = []
    for line in Path(path).read_text(encoding="utf-8").splitlines():
        line = line.strip()
        if not line:
            continue
        rows.append(json.loads(line))
    return rows


def p95(values: list[int]) -> int:
    if not values:
        return 0
    values = sorted(values)
    index = int(len(values) * 0.95) - 1
    index = max(0, min(index, len(values) - 1))
    return values[index]


def recommend_automation(rows: list[dict]) -> list[str]:
    recommendations: list[str] = []

    by_endpoint: dict[str, list[dict]] = defaultdict(list)
    error_counter = Counter()

    for row in rows:
        endpoint = row.get("endpoint", "unknown")
        by_endpoint[endpoint].append(row)

        if row.get("status") != "succeeded":
            error_counter[row.get("error_type", "unknown")] += 1

    # 1) 에러 자동화 필요 여부
    if error_counter:
        recommendations.append("에러 타입별 알림 자동화를 먼저 붙이세요.")

    # 2) latency 높은 endpoint
    for endpoint, items in by_endpoint.items():
        latencies = [int(i.get("latency_ms", 0)) for i in items]
        if p95(latencies) > 5000:
            recommendations.append(
                f"{endpoint}: p95 latency가 5초 초과입니다. background 처리 분리를 검토하세요."
            )

    # 3) output token 과다
    for endpoint, items in by_endpoint.items():
        avg_output = mean(int(i.get("output_tokens", 0)) for i in items)
        if avg_output > 800:
            recommendations.append(
                f"{endpoint}: 평균 output tokens가 큽니다. 응답 길이 제한 또는 포맷 단순화를 검토하세요."
            )

    # 4) RAG 비용 과다
    for endpoint, items in by_endpoint.items():
        if any(i.get("rag_enabled") for i in items):
            avg_input = mean(int(i.get("input_tokens", 0)) for i in items)
            avg_chunks = mean(int(i.get("retrieved_chunk_count", 0)) for i in items)
            if avg_input > 1200 or avg_chunks > 4:
                recommendations.append(
                    f"{endpoint}: RAG 입력이 큽니다. top-k 축소나 chunk 최적화를 검토하세요."
                )

    # 5) 캐시 비율 낮음
    cached = [int(i.get("cached_input_tokens", 0)) for i in rows]
    inputs = [int(i.get("input_tokens", 0)) for i in rows]
    if sum(inputs) > 0:
        cache_ratio = sum(cached) / sum(inputs)
        if cache_ratio < 0.1:
            recommendations.append(
                "cached input 비율이 낮습니다. prompt prefix 안정화와 prompt_cache_key 일관성을 검토하세요."
            )

    # 6) 반복 사용 낮음
    user_counter = Counter(i.get("user_id") for i in rows if i.get("user_id"))
    repeat_users = sum(1 for _, count in user_counter.items() if count >= 2)
    if repeat_users < 5:
        recommendations.append(
            "반복 사용자가 적습니다. 기능 추가보다 핵심 사용 흐름과 결과 UX를 먼저 다듬는 편이 좋습니다."
        )

    return recommendations


if __name__ == "__main__":
    rows = load_jsonl("openai_requests.jsonl")
    recommendations = recommend_automation(rows)

    print("=== 90일 자동화 우선순위 ===")
    for idx, item in enumerate(recommendations, start=1):
        print(f"{idx}. {item}")

실행 방법

python automation_audit.py

예상 결과

=== 90일 자동화 우선순위 ===
1. 에러 타입별 알림 자동화를 먼저 붙이세요.
2. /rag-chat: p95 latency가 5초 초과입니다. background 처리 분리를 검토하세요.
3. /rag-chat: RAG 입력이 큽니다. top-k 축소나 chunk 최적화를 검토하세요.
4. cached input 비율이 낮습니다. prompt prefix 안정화와 prompt_cache_key 일관성을 검토하세요.

이 코드는 완벽한 운영 도구는 아니지만,
“지금 어디부터 자동화할지”를 감으로 정하지 않게 해줍니다.

---

출시 후 90일 자동화 체크리스트

꼭 자동화할 것

• usage / cost 집계
• 에러 타입별 알림
• worker / queue 상태 확인
• 반복 eval 실행
• prompt 버전 관리
• runbook 기반 점검

조건부로 자동화할 것

• batch 대량 작업
• background mode 기반 긴 작업 분리
• RAG 품질 리포트
• 사용자별 제한 정책

아직 수동이어도 괜찮은 것

• 아주 드문 edge case 분석
• 사용 빈도 낮은 부가 기능 개선
• 작은 UI 카피 수정

---

FAQ

Q. FastAPI BackgroundTasks만으로도 충분한가요?

짧고 간단한 후처리에는 꽤 유용합니다. FastAPI도 응답 이후 실행할 작업에 적합하다고 설명합니다. 다만 긴 OpenAI 호출, 대량 문서 처리, 색인처럼 무거운 일은 별도 worker나 job 구조가 더 안전합니다. (FastAPI)

Q. 언제 batch를 붙여야 하나요?

실시간 응답이 필요 없는 반복 작업이 쌓일 때입니다. OpenAI는 Batch가 대량 비동기 작업에 적합하고 비용도 더 낮을 수 있다고 안내합니다. 야간 요약, 임베딩 생성, 백필 작업이 대표적입니다. (OpenAI 개발자)

Q. prompt caching은 출시 후 꼭 봐야 하나요?

네. 초반에는 기능 구현 때문에 prompt가 흔들리기 쉽고, 그 결과 캐시 이점이 거의 사라질 수 있습니다. 30일 관찰 후 90일 자동화 단계에서 prefix를 안정화하는 게 비용과 지연 둘 다에 도움이 됩니다. (OpenAI 개발자)

Q. eval 자동화는 아직 이른 거 아닌가요?

대표 사례 10~20개만 있어도 시작할 수 있습니다. 너무 거창하게 가지 말고, 운영 중 실제 실패 사례를 eval set으로 쌓는 방식이 가장 현실적입니다. (OpenAI 개발자)

---

핵심 요약

• 출시 후 첫 90일은 새 기능보다 자동화 우선순위 정리가 더 중요합니다.
• 가장 먼저 자동화할 것은 usage/cost, 에러 분류, background 분리, 대표 eval 실행입니다. (OpenAI 개발자)
• FastAPI BackgroundTasks는 가벼운 후처리에 적합하고, 무거운 OpenAI 작업은 별도 worker 구조를 검토하는 게 낫습니다. (FastAPI)
• Batch는 실시간이 아닌 대량 작업에 특히 유용합니다. (OpenAI 개발자)
• prompt caching은 기능이 안정된 뒤 비용과 latency를 줄이는 핵심 포인트가 될 수 있습니다. (OpenAI 개발자)

---

출처

• OpenAI API deployment checklist — 운영 단계 점검과 Responses API 권장 흐름. (OpenAI 개발자)
• OpenAI Prompt caching guide — 자동 캐시 동작과 안정적인 prefix의 중요성. (OpenAI 개발자)
• Prompt Caching 201 cookbook — 정확한 반복 prefix와 1024+ 토큰 구간에서의 캐시 활용. (OpenAI 개발자)
• FastAPI Background Tasks — 응답 후 작업 실행 용도와 사용 방식. (FastAPI)
• Migrate to the Responses API — Responses API가 향후 방향이라는 설명. (OpenAI 개발자)
• OpenAI Developer quickstart — Python SDK와 기본 시작 흐름. (OpenAI 개발자)
• 올려주신 “AI 검색에 잘 걸리는 글” 구조 참고.

Python, OpenAI, FastAPI, 출시 후 90일, OpenAI 운영 자동화, usage logging, prompt caching, Batch API, BackgroundTasks, AI 백엔드 운영, SaaS 자동화, OpenAI 비용 최적화, RAG 운영, 주니어 개발자, FastAPI 운영