워크플로우 노트

OpenAI API 응답을 서비스 코드에 바로 넣을 계획이라면 첫 질문은 "JSON으로 받을 수 있나"가 아니다. 코드가 기대하는 key, type, enum, 실패 branch가 고정되어 있는지가 먼저다. JSON mode는 JSON 파싱 문제를 줄여 주지만, 원하는 schema와 맞는다는 뜻은 아니다.2026-05-02 기준 OpenAI 공식 문서로 보면 기본 선택지는 분명하다. 사용자가 보는 답변 자체를 구조화해야 하면 Structured Outputs를 보고, 외부 시스템에서 환불, 검색, 업데이트 같은 action을 실행해야 하면 function calling으로 분리한다. Responses API에서는 Structured Outputs를 text.format으로 정의한다.짧게 정리하면 이렇다...

OpenAI File Search를 붙일 때 첫 질문은 "RAG를 직접 만들까, API tool을 쓸까"가 아니다. 같은 문서를 반복해서 검색할 것인지, 그 문서를 며칠 보관할 것인지, 파일이 제한 안에 들어오는지, 검색 결과를 나중에 감사할 수 있어야 하는지가 먼저다.2026-05-01 기준 OpenAI 공식 문서로 보면 경계는 꽤 분명하다. File Search는 Responses API에서 쓰는 hosted tool이다. Vector Store는 그 tool이 검색할 수 있도록 파일을 chunking, embedding, indexing해 두는 저장/index layer다. 반복 질의가 있는 문서 지식베이스라면 Vector Store가 맞다. 반대로 회의록 파일 하나를 두 번 요약하는 작업이라면 p..

OpenAI Realtime API를 붙일 때 첫 질문은 "WebRTC가 좋나, WebSocket이 좋나"가 아니다. 마이크와 스피커가 어디에 있고, 표준 API key가 어디에 남아야 하며, 주문 조회나 정책 판단 같은 서버 로직을 누가 처리해야 하는지가 먼저다.2026-04-30 기준 OpenAI 공식 문서로 보면 기본 경계는 꽤 분명하다. 브라우저나 모바일에서 사용자가 음성으로 대화한다면 WebRTC부터 본다. 서버 worker가 음성 스트림과 이벤트를 직접 처리한다면 WebSocket이 맞다. 전화번호로 들어오는 통화는 SIP path다. 답변 생성 없이 실시간 자막만 필요하면 speech-to-speech session이 아니라 transcription session을 따로 봐야 한다.짧게 정리..

OpenAI Batch API는 싸게 호출하는 버튼이 아니다. 대량 요청을 비동기로 맡기고, 결과 파일과 에러 파일을 나중에 회수하는 운영 방식이다. 사용자가 채팅창에서 답을 기다리는 흐름이라면 Batch가 아니라 Standard, 필요하면 Priority 쪽을 봐야 한다.2026-04-29 기준 OpenAI 공식 문서로 보면 판단 기준은 분명하다. Batch API는 synchronous API 대비 50% 낮은 비용, 별도 rate-limit pool, 24시간 turnaround를 전제로 한다. 대신 .jsonl 파일, purpose=batch 업로드, unique custom_id, status polling, error file 처리, expired retry queue를 직접 설계해야 한다.먼..

OpenAI API 데모가 한 번 잘 답했다고 배포 준비가 끝난 것은 아니다. 실제 서비스에서는 모델이 답을 냈는지보다 먼저 봐야 할 것이 있다. 실패한 요청을 어떻게 다시 보낼지, 긴 작업을 어디서 기다릴지, 완료 알림을 믿어도 되는지, 민감한 데이터에서 background mode를 켜도 되는지부터 갈린다.2026-04-28 기준 OpenAI 공식 문서로 보면 결론은 단순하다. 새 OpenAI API 앱은 Responses API를 기본 출발점으로 두고, 배포 전에 eval, rate limit backoff, long-running task policy, webhook signature, ZDR 경계, tool-loop transport를 따로 잠가야 한다. 데모 프롬프트 3개가 통과한 상태는 la..

LLM API 비용을 줄이려고 prompt caching부터 보는 팀이라면 먼저 세 가지를 확인해야 한다. 반복되는 prefix가 몇 token인지, 다음 호출이 몇 분 뒤에 오는지, 할인되는 비용이 input인지 cache write인지 storage인지다. cache 지원이라는 한 줄만 보고 붙이면 생각보다 캐시가 안 먹거나, output token 비용 때문에 절감률이 작게 보이거나, TTL storage 비용이 계산에서 빠진다.2026-04-19 기준 current official docs로 보면 OpenAI, Anthropic, Google의 답이 꽤 다르다. 그리고 Google 쪽은 특히 latest preview와 stable을 나눠야 한다. 첫 발행본은 Gemini를 2.5 stable 기..

에이전트 코딩 모델을 고를 때 가장 자주 틀리는 질문은 누가 제일 똑똑하냐부터 묻는 것이다. 실제 운영에서는 그보다 먼저 갈리는 게 있다. 한 모델이 저장소를 직접 읽고 고치고 검증까지 해야 하는지, 긴 세션 하나로 refactor를 오래 끌어야 하는지, 문서와 URL을 많이 읽는 조사형 coding agent인지, 아니면 싸고 자주 도는 bugfix sweep인지다. 2026-04-18 기준 current official docs를 다시 잠그면 비교 단위도 바뀐다. OpenAI는 GPT-5.4와 current Responses tool surface, Anthropic은 Claude Opus 4.7과 current Claude tools, Google은 stable Gemini 2.5 Pro/Flash..

기준일은 2026년 4월 11일이다. Google Gemini 2.5에서 thinkingBudget과 implicit caching을 같이 볼 때 먼저 잡아야 할 결론은 단순하다. implicit caching은 반복되는 input prefix에만 도움을 주고, thinking token은 output bucket에 그대로 남는다. 그래서 공통 prefix가 길다는 이유만으로 비용이 크게 줄 거라고 보면 틀리기 쉽다. Flash는 thinkingBudget=0으로 thinking을 끌 수 있지만 Pro는 그게 안 되고, current caching guide 기준 Pro implicit cache minimum도 4096이다.빠르게 판단하면 이렇다.반복 extraction이나 classification이..

새 프로젝트를 시작한다면 Assistants API보다 Responses API를 기준으로 잡는 편이 안전하다. OpenAI는 2025년 3월 11일 Responses API를 에이전트 빌딩의 새 기본 축으로 소개했고, 공식 migration 문서에서는 Assistants API 종료일을 2026년 8월 26일로 적어두고 있다. 이미 Assistants API를 쓰고 있다면 핵심 질문은 옮길까 말까가 아니라 무엇부터 옮길까에 가깝다.빠르게 판단하면 이렇다.새 프로젝트면 Responses API로 시작한다.기존 Assistants API 프로젝트는 2026년 8월 26일 이전 migration 계획이 필요하다.먼저 옮길 것은 tool/function integration이다.종료 일정 같은 사실값은 모델 ..