Python으로 공부하는 OpenAI 29편 — FastAPI + OpenAI 서비스, 2년차에는 무엇을 직접 만들고 무엇을 플랫폼에 맡겨야 할까?

Python으로 공부하는 OpenAI 29편 — FastAPI + OpenAI 서비스, 2년차에는 무엇을 직접 만들고 무엇을 플랫폼에 맡겨야 할까?

한 줄 요약

FastAPI + OpenAI 서비스를 1년 이상 운영했다면, 2년차부터는 새 기능을 계속 직접 붙이기보다 Responses API는 기본 경로로 고정하고, 긴 작업은 Background mode, 대량 비동기 작업은 Batch, 저우선순위 비동기는 Flex processing, 문서 검색은 File Search/Vector Store, 권한과 리소스 관리는 Projects·Service Accounts에 맡기는 식으로 “플랫폼에 맡길 것”과 “우리 서비스가 직접 책임질 것”을 분리하는 편이 훨씬 현실적입니다. OpenAI도 새 프로젝트는 Responses API부터 시작하라고 권장하고, 운영 단계에서는 production best practices, background mode, batch, flex processing, prompt caching, projects/service accounts를 각각 별도 주제로 다룹니다. (OpenAI 개발자)

---

왜 2년차에는 “무엇을 맡길까”가 중요할까?

1년 차까지는 보통 이런 흐름이 많습니다.

• 일단 기능을 직접 만든다
• 필요하면 worker도 직접 붙인다
• RAG도 직접 튜닝한다
• tool calling도 직접 제어한다

이건 나쁘지 않습니다.
오히려 이 과정을 거쳐야 서비스 감각이 생기니까요.

그런데 2년차에도 모든 걸 계속 직접 들고 가면, 어느 순간부터는 속도보다 운영 복잡도가 더 빨리 커집니다. OpenAI의 production best practices는 프로토타입에서 프로덕션으로 갈수록 보안, 비용, 성능, 아키텍처를 같이 봐야 한다고 설명하고, Run and scale 영역에서 background mode, prompt caching, file inputs, batch, flex processing 같은 운영 도구를 따로 제공합니다. 즉, “직접 만드는 것”만이 능사가 아니라 어디까지를 플랫폼이 해결해주는지 활용하는 것도 운영 역량의 일부라는 뜻입니다. (OpenAI 개발자)

---

먼저 결론부터: 2년차 기준으로 이렇게 나누면 편합니다

저는 보통 아래처럼 나눕니다.

플랫폼에 맡기기 좋은 것

• 기본 모델 호출 인터페이스
• 긴 응답 처리
• 대량 비동기 처리
• 저우선순위 저비용 처리
• 문서 검색 인프라
• 프로젝트/서비스 계정/키 권한
• 기본적인 usage/cost 집계 기반 운영

우리 서비스가 직접 책임질 것

• 핵심 도메인 로직
• 사용자 경험과 결과 포맷
• 플랜 정책과 사용량 제한
• prompt 템플릿과 제품 규칙
• eval 세트와 품질 기준
• 제품별 source 처리 방식
• 내부 DB/권한/고객 데이터 흐름

즉,
범용 인프라는 플랫폼에 맡기고
차별화되는 도메인과 UX는 직접 쥐는 것이 핵심입니다.

---

1. Responses API는 이제 “선택지”보다 “기본값”으로 두는 편이 낫습니다

OpenAI는 migration 가이드와 deployment checklist에서 새 프로젝트는 Responses API부터 시작하라고 권장합니다. Python 라이브러리 문서도 현재 기본 인터페이스로 Responses 흐름을 안내합니다. (OpenAI 개발자)

그래서 2년차에는 이 질문을 해보는 게 좋습니다.

• 우리 서비스의 새 기능은 전부 Responses API 기준으로 붙고 있는가
• 아직 예전 인터페이스에 남아 있는 호출은 없는가
• tool calling, 멀티모달, structured outputs 흐름이 한 경로로 정리돼 있는가

왜 플랫폼에 맡기는가

이건 우리가 직접 프레임을 만들 필요가 없는 영역이기 때문입니다.
호출 인터페이스 표준화 자체를 OpenAI가 이미 제공하고 있으니, 앱 안에서는 adapter 계층만 얇게 유지하는 편이 낫습니다.

우리가 직접 가져가야 하는 것

• 어떤 model을 어느 기능에 쓰는지
• 어떤 prompt template을 쓰는지
• 어떤 tool schema를 노출할지
• 어떤 결과를 UI에 어떻게 보여줄지

---

2. 긴 작업은 직접 request-response로 버티지 말고 Background mode를 먼저 검토해야 합니다

OpenAI의 background mode 가이드는 긴 작업을 비동기로 실행해 timeout이나 연결 문제를 피할 수 있다고 설명합니다. deep research 가이드도 몇 분 걸릴 수 있는 작업에는 background mode를 권장합니다. (OpenAI 개발자)

플랫폼에 맡기기 좋은 이유

2년차쯤 되면 긴 작업이 늘어납니다.

• 긴 리포트 생성
• 복잡한 reasoning
• 멀티스텝 분석
• 문서 여러 개를 종합하는 작업

이걸 매번 우리 API 서버 요청 수명주기에 묶으면, 결국 timeout, 재시도, polling, 상태 저장 같은 걸 너무 많이 직접 떠안게 됩니다.

직접 책임질 것

• 어떤 작업을 background로 보낼지 기준
• 완료 후 사용자에게 어떻게 알릴지
• background 결과를 DB와 UX에 어떻게 연결할지
• 실패 시 재시도 정책과 runbook

즉,
긴 추론 실행 자체는 플랫폼,
그 결과를 제품 흐름으로 연결하는 건 우리 앱입니다.

---

3. 반복 대량 작업은 Batch로 옮기는 게 2년차부터 진짜 중요합니다

OpenAI Batch API는 비동기 요청 묶음을 처리하는 용도로 설명되며, 일반 실시간 요청보다 50% 낮은 비용과 더 높은 별도 rate limits를 제공합니다. (OpenAI 개발자)

Batch에 맡기기 좋은 작업

• 야간 요약
• 대량 임베딩
• 대량 분류/태깅
• 백필(backfill)
• 정기 리포트 생성
• eval 데이터셋 반복 실행

왜 직접 실시간 처리에서 빼야 하나

이 단계에서 흔한 안 좋은 패턴은 이겁니다.

• 여전히 모든 걸 일반 API 호출로 보냄
• worker가 있지만 사실상 실시간처럼 돌림
• rate limit과 비용이 같이 올라감

Batch는 “이건 지금 당장 안 끝나도 된다”는 작업을 플랫폼 쪽 비동기 처리로 넘길 수 있게 해줍니다.
우리가 직접 유지해야 하는 건 배치 입력 생성, 결과 반영, 실패 관리이지, 대량 처리 엔진 자체는 아닙니다.

---

4. 저우선순위 비동기 작업은 Flex processing을 더 적극적으로 볼 타이밍입니다

OpenAI Flex processing은 느린 응답과 간헐적 리소스 불가를 감수하는 대신 더 낮은 비용으로 처리하는 옵션이라고 설명합니다. 문서에서는 model evaluations, data enrichment, async workloads 같은 용도에 특히 적합하다고 안내합니다. (OpenAI 개발자)

Flex에 맡기기 좋은 작업

• 평가 자동화
• 데이터 정리
• 내부 품질 점검
• 중요도 낮은 리포트
• 사용자에게 즉시 안 보여도 되는 보조 처리

왜 2년차에 중요하냐

1년 차까지는 “일단 된다”가 중요했는데,
2년차부터는 “덜 비싸게 돌아간다”가 점점 중요해집니다.

그래서 작업을 이렇게 나누는 감각이 필요합니다.

• 지금 바로 보여야 하는가 → 실시간
• 오래 걸려도 되나 → Background
• 대량인가 → Batch
• 급하지 않고 싸야 하나 → Flex

이 기준이 생기면 운영비 구조가 훨씬 안정됩니다.

---

5. 문서 검색 인프라는 가능한 한 플랫폼 기능을 적극적으로 쓰는 편이 낫습니다

OpenAI는 Retrieval/File Search 가이드에서 vector store와 file search 도구를 제공하고, semantic search 기반으로 문서를 찾는 흐름을 설명합니다. Responses API에서도 built-in file search tool을 사용할 수 있습니다. (OpenAI 개발자)

플랫폼에 맡기기 좋은 것

• vector store 자체 관리
• 기본 검색 인프라
• file search tool 호출 경로

우리 서비스가 직접 가져가야 하는 것

• 어떤 문서를 올릴지
• chunking/업로드 정책
• 어떤 source를 사용자에게 보여줄지
• citation UX
• 문서 접근 권한
• 결과 검증 기준

즉, 2년차에는 “벡터 DB를 직접 깎아야 하나?”보다
플랫폼 file search로 충분한가, 아니면 정말 커스텀 검색이 필요한가를 먼저 물어보는 게 좋습니다.

직접 구현은 강력하지만, 운영 표면적도 커집니다.
문서 검색이 제품 핵심 차별화가 아니라면, 플랫폼 기능을 적극적으로 활용하는 편이 훨씬 현실적일 수 있습니다.

---

6. 프로젝트·서비스 계정·키 권한 관리는 꼭 플랫폼 단위로 정리해야 합니다

OpenAI의 Projects 관리 문서는 프로젝트 단위로 리소스, 멤버, 서비스 계정, 사용량을 관리할 수 있다고 설명합니다. API key permissions 문서는 All, Restricted, Read Only 같은 권한 수준을 제공합니다. API key safety 문서는 팀원마다 고유 키 사용을 권장합니다. (OpenAI 개발자)

플랫폼에 맡기기 좋은 것

• 프로젝트 단위 리소스 분리
• 서비스 계정
• 키 권한 정책
• 기본 사용량 추적 단위

우리가 직접 책임질 것

• 어떤 프로젝트를 어떤 환경에 쓸지
• 팀 권한 정책
• prod/staging 리소스 분리 규칙
• secret 주입 구조
• 로그 마스킹 정책

2년차에는 이게 정말 중요합니다.
운영 사고의 대부분은 기능보다 권한/환경 혼선에서 터지기 쉬우니까요.

---

7. Prompt 템플릿과 캐시 전략은 직접 쥐어야 합니다

반응형

Prompt caching은 플랫폼 기능이지만, 캐시가 먹는 구조를 만드는 일은 우리 책임입니다. OpenAI는 반복되는 긴 prefix가 있을 때 캐시가 비용과 latency를 크게 줄일 수 있다고 설명합니다. (OpenAI 개발자)

플랫폼이 해주는 것

• 캐시 메커니즘 자체
• cached input 가격 체계

우리가 직접 해야 하는 것

• prompt 템플릿 버전 관리
• system/developer prompt 안정화
• request prefix를 일관되게 유지
• 평가 없이 잦은 prompt 수정 방지

즉,
캐시는 플랫폼이 처리하지만
캐시가 잘 먹도록 설계하는 건 우리 일입니다.

이건 2년차에 특히 돈이 됩니다.
기능이 자리를 잡으면, 이제는 같은 기능을 더 싸고 빠르게 돌리는 쪽이 중요해지니까요.

---

8. Eval은 절대 플랫폼에 “전부” 맡길 수 없는 영역입니다

OpenAI는 Evals, evaluation best practices, trace grading, agent evals를 제공하지만, 대표 데이터셋과 합격 기준 자체는 결국 제품팀이 직접 만들어야 합니다. traces를 통해 문제를 먼저 보고, graders와 datasets로 반복 평가하라고 안내합니다. (OpenAI 개발자)

플랫폼이 해주는 것

• eval 실행 프레임워크
• graders/trace/eval run 기반 도구

우리가 직접 해야 하는 것

• 대표 사용자 질문 선정
• 실패 사례 수집
• 합격/불합격 기준 정의
• RAG/tool calling 품질 기준
• 비즈니스 기준의 “좋은 답” 정의

즉, 2년차에는
평가 엔진은 플랫폼 도움을 받되, 평가 기준은 절대 외주화할 수 없다
이 감각이 필요합니다.

---

9. 그럼 무엇은 끝까지 직접 만들어야 하나?

여기서 제일 중요한 결론이 나옵니다.

2년차 이후에도 끝까지 직접 가져가야 하는 건 대체로 이런 것들입니다.

• 사용자 문제 정의
• 핵심 워크플로 UX
• 도메인별 prompt 규칙
• 제품 정책
• 플랜/제한 정책
• source/citation 방식
• 품질 기준과 대표 eval 세트
• 내부 데이터/권한 연결
• 장애 대응 runbook

왜냐하면 이게 결국 제품 차별화 포인트이기 때문입니다.

플랫폼은 점점 더 많은 걸 해주지만,
무엇을 어떻게 묶어서 가치로 바꿀지는 여전히 우리 서비스가 직접 해야 합니다.

---

지금 바로 써볼 수 있는 “플랫폼 vs 직접 구현” 판단 코드 예제

아래 코드는 기능 하나를 두고

• 범용성
• 운영 복잡도
• 비용 최적화 영향
• 제품 차별화 영향
  을 기준으로 “플랫폼에 맡길지 / 직접 유지할지”를 아주 단순하게 판단하는 예제입니다.

from dataclasses import dataclass
from typing import List


@dataclass
class Capability:
    name: str
    generic_infrastructure: int   # 1~5, 높을수록 범용 인프라에 가까움
    operational_burden: int       # 1~5, 높을수록 직접 운영이 힘듦
    cost_leverage: int            # 1~5, 높을수록 플랫폼 최적화 이점 큼
    product_differentiation: int  # 1~5, 높을수록 직접 쥐어야 함


@dataclass
class Decision:
    name: str
    decision: str
    reason: str
    score: float


def evaluate(cap: Capability) -> Decision:
    platform_score = (
        cap.generic_infrastructure * 1.4
        + cap.operational_burden * 1.3
        + cap.cost_leverage * 1.2
        - cap.product_differentiation * 1.0
    )

    if platform_score >= 8:
        decision = "플랫폼에 최대한 맡기기"
        reason = "범용 인프라 성격이 강하고, 직접 운영할수록 복잡도와 비용이 커집니다."
    elif platform_score >= 5:
        decision = "혼합 전략"
        reason = "실행 인프라는 플랫폼을 쓰고, 제품 규칙과 UX는 직접 관리하는 편이 좋습니다."
    else:
        decision = "직접 내재화 유지"
        reason = "제품 차별화 요소가 커서 직접 제어하는 편이 유리합니다."

    return Decision(
        name=cap.name,
        decision=decision,
        reason=reason,
        score=round(platform_score, 2),
    )


def main() -> None:
    capabilities: List[Capability] = [
        Capability(
            name="긴 reasoning 작업 실행",
            generic_infrastructure=5,
            operational_burden=5,
            cost_leverage=4,
            product_differentiation=2,
        ),
        Capability(
            name="문서 검색 인프라",
            generic_infrastructure=4,
            operational_burden=4,
            cost_leverage=3,
            product_differentiation=3,
        ),
        Capability(
            name="Prompt 템플릿과 답변 UX",
            generic_infrastructure=1,
            operational_burden=2,
            cost_leverage=2,
            product_differentiation=5,
        ),
        Capability(
            name="대표 eval 세트와 품질 기준",
            generic_infrastructure=1,
            operational_burden=2,
            cost_leverage=1,
            product_differentiation=5,
        ),
    ]

    for cap in capabilities:
        result = evaluate(cap)
        print(f"[{result.name}]")
        print(f"판단 점수: {result.score}")
        print(f"권장 전략: {result.decision}")
        print(f"이유: {result.reason}")
        print("-" * 50)


if __name__ == "__main__":
    main()

실행 방법

python platform_vs_build.py

예상 결과

[긴 reasoning 작업 실행]
판단 점수: 14.0
권장 전략: 플랫폼에 최대한 맡기기
이유: 범용 인프라 성격이 강하고, 직접 운영할수록 복잡도와 비용이 커집니다.
--------------------------------------------------
[문서 검색 인프라]
판단 점수: 9.7
권장 전략: 플랫폼에 최대한 맡기기
이유: 범용 인프라 성격이 강하고, 직접 운영할수록 복잡도와 비용이 커집니다.
--------------------------------------------------
[Prompt 템플릿과 답변 UX]
판단 점수: 0.8
권장 전략: 직접 내재화 유지
이유: 제품 차별화 요소가 커서 직접 제어하는 편이 유리합니다.
--------------------------------------------------
[대표 eval 세트와 품질 기준]
판단 점수: -0.5
권장 전략: 직접 내재화 유지
이유: 제품 차별화 요소가 커서 직접 제어하는 편이 유리합니다.
--------------------------------------------------

이 코드는 단순하지만 꽤 쓸 만합니다.
“우리가 다 직접 해야 하나?”라는 질문을 감이 아니라 기준으로 보게 해주니까요.

---

2년차 추천 운영 원칙

플랫폼에 맡기기

• Responses API 기본 호출
• Background mode
• Batch
• Flex processing
• File Search / Vector Store
• 프로젝트·서비스 계정·권한 관리

직접 유지하기

• 도메인 로직
• Prompt 템플릿
• 핵심 UX
• eval 기준
• source/citation UX
• 사용량 제한/플랜 규칙
• 내부 데이터/권한 연결

혼합 전략이 좋은 영역

• RAG: 검색 인프라는 플랫폼, source 정책은 직접
• Tool calling: 호출 프레임은 플랫폼, tool 의미와 UX는 직접
• Observability: usage 집계는 플랫폼 일부 활용, 제품 지표는 직접

---

FAQ

Q. 2년차에는 모든 걸 플랫폼에 맡기는 게 정답인가요?

아닙니다.
범용 인프라와 실행 경로는 플랫폼에 맡길수록 유리한 경우가 많지만, 제품 차별화가 생기는 prompt, UX, 품질 기준, 도메인 로직은 직접 가져가는 편이 좋습니다.

Q. File Search가 있으면 RAG를 전부 직접 구현할 필요가 없나요?

많은 경우 그럴 수 있습니다. OpenAI는 file search와 vector store 기반 retrieval 흐름을 공식 도구로 제공하므로, 문서 검색 자체가 핵심 경쟁력이 아니라면 플랫폼 기능을 적극 검토할 만합니다. 다만 citation UX, source 노출 방식, 문서 권한 정책은 여전히 서비스가 직접 정해야 합니다. (OpenAI 개발자)

Q. Flex processing은 언제 특히 유용한가요?

즉시 응답이 필요 없고, 비용 절감이 더 중요한 작업에 특히 잘 맞습니다. OpenAI는 evals, data enrichment, async workloads 같은 예시를 듭니다. (OpenAI 개발자)

Q. pinned model은 언제 꼭 필요하나요?

핵심 기능, 반복 사용이 많고 품질 변동이 바로 제품 경험에 영향을 주는 기능이라면 pinned model과 eval 조합을 더 진지하게 고려하는 편이 좋습니다. 모델 alias는 편하지만, 일관성 측면에서는 pinned version이 더 나을 수 있습니다. (OpenAI 개발자)

---

핵심 요약

• 2년차부터는 “무엇을 더 만들까”보다 무엇을 플랫폼에 맡기고 무엇을 직접 가져갈까가 훨씬 중요합니다.
• Responses API는 기본 경로로 고정하는 편이 낫습니다. (OpenAI 개발자)
• 긴 작업은 Background mode, 대량 비동기 작업은 Batch, 저우선순위 작업은 Flex를 적극 검토할 만합니다. (OpenAI 개발자)
• 문서 검색 인프라는 File Search/Vector Store를 적극 활용할 수 있지만, source UX와 도메인 규칙은 직접 쥐는 편이 좋습니다. (OpenAI 개발자)
• prompt, eval, UX, 정책은 여전히 우리 서비스의 핵심 자산입니다.

---

출처

• OpenAI Production best practices — 프로토타입에서 프로덕션으로 갈 때 보안, 비용, 아키텍처를 함께 보라고 안내. (OpenAI 개발자)
• OpenAI Python API library — Python 3.9+ 지원, sync/async 클라이언트 제공. (OpenAI 개발자)
• Background mode — 긴 작업을 비동기로 처리하는 방식. (OpenAI 개발자)
• Batch API — 대량 비동기 작업, 50% 낮은 비용, 별도 높은 rate limits. (OpenAI 개발자)
• Flex processing — 느려도 되는 작업을 더 낮은 비용으로 처리하는 옵션. (OpenAI 개발자)
• Prompt caching — 반복 prefix에 대해 비용과 latency 절감. (OpenAI 개발자)
• Data controls — Responses API 저장/보존, background mode 저장 동작, MCP 서버 데이터 보존 관련 설명. (OpenAI 개발자)
• List models / API overview 관련 레퍼런스 — 사용 가능한 모델과 모델 운영 기준 확인. (OpenAI 개발자)

Python, OpenAI, FastAPI, Responses API, Background mode, Batch API, Flex processing, Prompt Caching, File Search, Vector Store, 서비스 계정, OpenAI Projects, AI 백엔드 운영, 2년차 로드맵, 주니어 개발자