워크플로우 노트

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 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..

Responses API에서 원격 MCP 서버를 붙이는 최소 형태는 생각보다 짧다. tools 배열에 type="mcp" 도구를 넣고 server_url 또는 connector_id, 필요하면 인증 정보와 require_approval 정책을 지정하면 된다. 내가 2026년 3월 13일에 직접 돌려본 결과, 공개 dmcp 서버는 mcp_list_tools -> mcp_call -> message 흐름이 깔끔하게 성공했고, OpenAI 문서용 MCP 서버는 연결은 성공했지만 중간 fetch_openai_doc 호출이 한 번 실패했다. 즉 MCP 연결 성공과 도구 호출 정확도는 같은 얘기가 아니다.먼저 요약하면 이렇다.최소 request는 responses.create(..., tools=[{"type":"..

새 프로젝트를 시작한다면 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이다.종료 일정 같은 사실값은 모델 ..