New tools for building agents
Quick Summary
OpenAI는 에이전트형 애플리케이션 개발을 위해 Responses API를 중심으로 웹 검색, 파일 검색, 컴퓨터 사용 도구와 Agents SDK를 제공하며, 기존 Chat Completions와 Assistants API의 역할도 함께 정리했다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
OpenAI는 에이전트형 애플리케이션 개발을 위해 Responses API를 중심으로 웹 검색, 파일 검색, 컴퓨터 사용 도구와 Agents SDK를 제공하며, 기존 Chat Completions와 Assistants API의 역할도 함께 정리했다.
📌 핵심 요약
- Responses API는 Chat Completions의 단순성과 Assistants API의 도구 사용 능력을 결합한 새로운 API 기본 단위로 소개되며, 개발자가 여러 도구와 모델 턴을 한 번의 호출 흐름 안에서 활용해 더 복잡한 작업을 해결하도록 설계됐다.
- 초기 내장 도구로 웹 검색, 파일 검색, 컴퓨터 사용이 제공되며, OpenAI는 이 도구들이 모델을 실제 세계의 최신 정보, 문서 저장소, 컴퓨터 조작 환경과 연결해 에이전트의 실용성을 높인다고 설명한다.
- 기존 API와의 관계에서는 Chat Completions를 계속 지원하되 새 통합에는 Responses API를 권장하고, Assistants API는 기능 동등성 확보 후 2026년 중반을 목표로 종료 일정을 공식화할 계획이라고 밝혔다.
- 웹 검색 도구는 최신 웹 정보를 인용과 함께 제공하고, 파일 검색 도구는 대량 문서에서 관련 정보를 빠르게 찾도록 쿼리 최적화, 메타데이터 필터링, 재랭킹, 벡터 저장소 검색 기능을 제공한다.
- 컴퓨터 사용 도구는 Operator에 쓰인 Computer-Using Agent 모델 기반의 연구 프리뷰로, 브라우저 및 일부 컴퓨터 작업 자동화를 가능하게 하지만 운영체제 수준 작업에서는 신뢰성이 아직 제한적이므로 사람의 감독과 안전장치가 필요하다고 강조한다.
🧩 주요 포인트
- Responses API는 Chat Completions의 단순성과 Assistants API의 도구 사용 능력을 결합한 새로운 API 기본 단위로 소개되며, 개발자가 여러 도구와 모델 턴을 한 번의 호출 흐름 안에서 활용해 더 복잡한 작업을 해결하도록 설계됐다.
- 초기 내장 도구로 웹 검색, 파일 검색, 컴퓨터 사용이 제공되며, OpenAI는 이 도구들이 모델을 실제 세계의 최신 정보, 문서 저장소, 컴퓨터 조작 환경과 연결해 에이전트의 실용성을 높인다고 설명한다.
- 기존 API와의 관계에서는 Chat Completions를 계속 지원하되 새 통합에는 Responses API를 권장하고, Assistants API는 기능 동등성 확보 후 2026년 중반을 목표로 종료 일정을 공식화할 계획이라고 밝혔다.
- 웹 검색 도구는 최신 웹 정보를 인용과 함께 제공하고, 파일 검색 도구는 대량 문서에서 관련 정보를 빠르게 찾도록 쿼리 최적화, 메타데이터 필터링, 재랭킹, 벡터 저장소 검색 기능을 제공한다.
- 컴퓨터 사용 도구는 Operator에 쓰인 Computer-Using Agent 모델 기반의 연구 프리뷰로, 브라우저 및 일부 컴퓨터 작업 자동화를 가능하게 하지만 운영체제 수준 작업에서는 신뢰성이 아직 제한적이므로 사람의 감독과 안전장치가 필요하다고 강조한다.
🧠 상세 정리
1. Responses API의 등장 배경과 목적
OpenAI는 2025년 3월 11일 에이전트를 만들기 위한 새로운 도구 묶음을 소개하면서, 그 중심에 Responses API를 두었다. 이 API는 OpenAI의 내장 도구를 활용해 에이전트형 애플리케이션을 만들기 위한 새로운 API 기본 단위로 설명된다. 원문은 모델 성능이 계속 발전함에 따라 개발자가 더 유연한 기반 위에서 여러 도구와 여러 모델 턴을 조합해야 한다는 흐름을 제시한다. Responses API는 단일 호출 안에서 점점 복잡한 작업을 처리할 수 있도록 설계되었으며, 단순한 텍스트 응답 생성보다 더 넓은 작업 수행 체계를 목표로 한다.
2. Chat Completions와 Assistants API의 결합
Responses API는 Chat Completions의 단순성과 Assistants API의 도구 사용 기능을 결합한 형태로 소개된다. OpenAI는 개발자가 여러 API나 외부 공급업체를 복잡하게 통합하지 않고도 OpenAI 모델과 내장 도구를 앱에 쉽게 결합할 수 있다고 설명한다. 이 API에는 통합된 아이템 기반 설계, 더 단순한 다형성 처리, 직관적인 스트리밍 이벤트, response.output_text 같은 SDK 헬퍼가 포함된다. 또한 OpenAI에 데이터를 저장하면 tracing과 evaluations 같은 기능으로 에이전트 성능을 평가하기 쉬워진다고 덧붙인다.
3. 데이터 저장, 과금, 비즈니스 데이터 처리 원칙
원문은 Responses API가 모든 개발자에게 제공되며 별도 API 요금이 붙는 방식이 아니라 토큰과 도구 사용량이 표준 요금에 따라 청구된다고 설명한다. 또한 OpenAI에 데이터가 저장되는 경우에도 기본적으로 비즈니스 데이터로 모델을 학습하지 않는다는 점을 명시한다. 이는 개발자가 에이전트 성능 평가나 추적을 위해 데이터를 보관하는 상황에서 중요한 운영 조건으로 제시된다. OpenAI는 빠른 시작 가이드를 통해 Responses API 사용법을 확인할 수 있다고 안내하며, 이 API를 새 에이전트 개발의 기본 출발점으로 위치시킨다.
4. 기존 API와의 관계 및 Assistants API의 향후 계획
OpenAI는 Chat Completions API가 여전히 가장 널리 채택된 API이며, 새 모델과 기능으로 계속 지원하겠다고 밝혔다. 내장 도구가 필요하지 않은 개발자는 Chat Completions를 계속 사용해도 된다고 설명하지만, 새 통합에는 Chat Completions의 상위 집합으로 제시되는 Responses API를 시작점으로 권장한다. Assistants API에 대해서는 베타 과정에서 얻은 개발자 피드백을 Responses API에 반영해 더 유연하고 빠르며 사용하기 쉽게 만들었다고 설명한다. Assistant-like, Thread-like 객체와 Code Interpreter 도구를 포함한 기능 동등성을 달성한 뒤, Assistants API의 폐기를 공식 발표하고 2026년 중반을 목표 종료 시점으로 제시할 계획이라고 밝혔다.
5. 웹 검색 도구: 최신 정보와 인용 제공
Responses API의 웹 검색 도구는 개발자가 빠르고 최신성 있는 답변을 명확한 출처 인용과 함께 얻을 수 있도록 한다. 이 도구는 gpt-4o와 gpt-4o-mini 사용 시 Responses API 안에서 활용할 수 있으며, 다른 도구나 함수 호출과 결합될 수 있다. 원문은 쇼핑 어시스턴트, 리서치 에이전트, 여행 예약 에이전트처럼 웹의 시의성 있는 정보가 필요한 사례를 예로 든다. Hebbia 사례에서는 자산운용사, 사모펀드·크레딧 회사, 법률 실무 조직이 공개 및 비공개 데이터에서 실행 가능한 인사이트를 더 빠르게 추출하는 데 웹 검색을 활용한다고 설명한다.
6. 웹 검색의 성능, 출처 연결, 접근 방식
OpenAI는 API의 웹 검색이 ChatGPT search에 사용되는 것과 같은 모델로 구동된다고 설명한다. 짧은 사실형 질문 답변 정확도를 평가하는 SimpleQA에서 GPT-4o search preview와 GPT-4o mini search preview가 각각 90%와 88%를 기록했다고 제시한다. 웹 검색을 통해 생성된 응답에는 뉴스 기사나 블로그 글 같은 출처 링크가 포함되어 사용자가 더 깊이 확인할 수 있으며, 콘텐츠 소유자는 더 넓은 독자에게 도달할 기회를 얻는다고 설명한다. 이 도구는 Responses API에서 프리뷰로 제공되며, Chat Completions API에서도 gpt-4o-search-preview와 gpt-4o-mini-search-preview 모델에 직접 접근할 수 있다고 안내한다.
7. 파일 검색 도구와 문서 기반 질의
파일 검색 도구는 대량 문서에서 관련 정보를 쉽게 검색하도록 개선된 도구로 소개된다. 여러 파일 형식 지원, 쿼리 최적화, 메타데이터 필터링, 맞춤형 재랭킹을 통해 빠르고 정확한 검색 결과를 제공할 수 있다고 설명한다. 원문은 고객 지원 에이전트가 FAQ에 접근하거나, 법률 보조 도구가 전문가를 위해 과거 사건을 빠르게 참조하거나, 코딩 에이전트가 기술 문서를 질의하는 사례를 제시한다. Navan은 AI 기반 여행 에이전트에서 회사 여행 정책 같은 지식베이스 문서로부터 정확한 답변을 제공하기 위해 이 기능을 사용하며, 사용자 그룹별 전용 벡터 저장소로 계정 설정과 역할에 맞춘 답변을 제공한다고 설명된다.
8. 컴퓨터 사용 도구와 실제 작업 자동화
컴퓨터 사용 도구는 Operator를 가능하게 한 Computer-Using Agent 모델을 기반으로 하며, Responses API에서 연구 프리뷰 형태로 제공된다. 이 도구는 모델이 생성한 마우스와 키보드 동작을 포착해 개발자 환경에서 실행 가능한 명령으로 변환할 수 있게 한다. 원문은 웹 앱 품질 보증, 레거시 시스템 간 데이터 입력 작업처럼 브라우저 기반 워크플로 자동화에 활용될 수 있다고 설명한다. Unify 사례에서는 API로 접근하기 어려운 정보를 온라인 지도 등에서 확인해 영업 신호로 활용하고, Luminai 사례에서는 API와 표준화된 데이터가 부족한 레거시 엔터프라이즈 시스템의 운영 워크플로를 자동화했다고 제시한다.
9. 컴퓨터 사용 도구의 성능 한계와 안전장치
OpenAI는 컴퓨터 사용 도구의 성능 지표로 OSWorld 38.1%, WebArena 58.1%, WebVoyager 87.0%를 제시하며, 이전 최고 성능과 비교한 결과도 함께 제공한다. 동시에 OSWorld 성능이 38.1%라는 점은 실제 운영체제 작업 자동화에서 아직 높은 신뢰성을 갖췄다고 보기 어렵다는 의미라고 설명한다. CUA를 Operator에 출시하기 전 오용, 모델 오류, 프런티어 위험이라는 세 영역에서 안전 테스트와 레드팀을 수행했으며, API에서 로컬 운영체제 능력 확장과 관련한 추가 평가도 수행했다고 밝힌다. 개발자에게는 프롬프트 인젝션 방지 안전 확인, 민감 작업 확인 프롬프트, 환경 격리 도구, 정책 위반 탐지 강화가 제공되지만, 특히 비브라우저 환경에서는 사람의 감독이 권장된다.
10. Agents SDK와 에이전트 플랫폼 방향
원문 후반부는 에이전트가 유용해지려면 핵심 로직과 도구 접근뿐 아니라 에이전트형 워크플로를 오케스트레이션할 수 있어야 한다고 전환한다. 이를 위해 OpenAI는 새로운 오픈소스 Agents SDK가 다중 에이전트 워크플로 오케스트레이션을 단순화한다고 소개한다. 제공된 source_body는 이 문장에서 끝나기 때문에 SDK의 세부 기능이나 전체 구성은 확인할 수 없다. 다만 기사 전체의 흐름상 Responses API, 내장 도구, 평가·추적 기능, 오케스트레이션 도구를 묶어 에이전트 개발 플랫폼을 구축하려는 방향을 설명하는 맥락으로 볼 수 있다.
🧾 핵심 주장 / 시사점
- OpenAI는 Chat Completions를 즉시 대체하기보다 계속 지원하면서도, 도구 사용과 다중 모델 호출이 필요한 새 개발의 기본 경로를 Responses API로 옮기려는 전략을 분명히 했다.
- 웹 검색과 파일 검색은 각각 최신 공개 정보와 조직 내부 문서 접근을 담당하므로, 에이전트 애플리케이션의 핵심 차별점이 모델 자체보다 정보 연결 방식과 검색 품질로 이동하고 있음을 보여준다.
- 컴퓨터 사용 도구는 API가 없는 레거시 환경까지 자동화 범위를 넓히지만, 원문이 수치와 안전장치를 함께 제시한 것처럼 아직은 고위험 작업에 사람의 감독이 필요한 연구 프리뷰 성격이 강하다.
✅ 액션 아이템
- 새 에이전트형 기능을 설계할 때 Chat Completions 단독 사용보다 Responses API 기반의 도구 호출 흐름으로 구성할 수 있는지 우선 검토한다.
- 문서 검색이나 최신 정보 조회가 필요한 작업은 웹 검색·파일 검색 도구를 분리해 적용하고, 인용·메타데이터 필터·재랭킹 활용 기준을 정한다.
- 컴퓨터 사용 도구를 브라우저 자동화 실험에만 제한적으로 적용하고, 운영체제 수준 작업에는 사람의 감독과 안전장치를 포함한 검증 절차를 둔다.
❓ 열린 질문
- 기존 Chat Completions 기반 기능 중 어떤 흐름이 Responses API로 옮겼을 때 여러 도구와 모델 턴을 한 호출 흐름 안에서 가장 큰 이점을 얻을까?
- 파일 검색 도구의 쿼리 최적화, 메타데이터 필터링, 재랭킹, 벡터 저장소 검색 중 현재 문서 기반 작업의 병목을 가장 직접적으로 줄일 기능은 무엇일까?
- Assistants API 종료 일정이 공식화될 경우, 기능 동등성 확보 전후로 어떤 내부 통합이나 마이그레이션 순서를 먼저 정해야 할까?