에이전트 구축을 위한 새로운 도구

 (openai.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • OpenAI가 프로덕션용 에이전트 개발을 쉽게 만들기 위해 Responses API, 내장 도구, Agents SDK, 관측성 도구를 공개함
  • Responses API는 Chat Completions API의 단순성과 Assistants API의 도구 사용 기능을 결합해 웹 검색·파일 검색·컴퓨터 사용을 한 흐름에서 다룰 수 있게 함
  • 새 통합에는 Responses API 사용을 권장하며, Assistants API는 기능 동등성 확보 후 2026년 중반 종료 목표로 폐기 절차에 들어갈 예정임
  • 내장 도구는 최신 웹 정보, 대규모 문서 검색, 마우스·키보드 기반 컴퓨터 작업 자동화를 지원하지만 computer use는 특히 비브라우저 환경에서 사람의 감독이 권장됨
  • 개발자는 API, 도구, SDK, 추적·평가 기능을 한 플랫폼에서 조합해 에이전트를 구축·배포·최적화할 수 있음

에이전트 개발을 위한 새 구성 요소

  • OpenAI는 에이전트를 사용자를 대신해 작업을 독립적으로 수행하는 시스템으로 봄
  • 지난 1년 동안 고급 추론, 멀티모달 상호작용, 새로운 안전 기법이 도입되면서 복잡한 다단계 작업을 처리할 기반이 마련됨
  • 고객들은 이 기능들을 프로덕션 준비된 에이전트로 전환하는 과정에서 어려움을 겪음
    • 광범위한 프롬프트 반복이 필요함
    • 맞춤형 오케스트레이션 로직을 직접 만들어야 함
    • 충분한 가시성과 내장 지원이 부족함
  • 이번에 공개된 구성 요소는 다음과 같음

Responses API

  • Responses API는 OpenAI의 내장 도구를 활용해 에이전트를 만들기 위한 새 API 기본 단위임
  • Chat Completions의 단순성과 Assistants API의 도구 사용 기능을 결합함
  • 단일 Responses API 호출에서 여러 도구와 여러 모델 턴을 사용해 더 복잡한 작업을 처리할 수 있음
  • 초기 지원 도구는 다음과 같음
    • 웹 검색
    • 파일 검색
    • 컴퓨터 사용
  • 사용성 개선도 포함됨
    • 통합된 item 기반 설계
    • 더 단순한 다형성
    • 직관적인 스트리밍 이벤트
    • response.output_text 같은 SDK 헬퍼
  • 여러 API나 외부 벤더를 따로 통합하지 않고 OpenAI 모델과 내장 도구를 앱에 결합하려는 개발자에게 맞춰 설계됨
  • OpenAI에 데이터를 저장하면 추적과 평가 기능으로 에이전트 성능 평가가 쉬워짐
  • OpenAI는 기본적으로 비즈니스 데이터를 모델 학습에 사용하지 않으며, 데이터가 OpenAI에 저장된 경우에도 동일함
  • 모든 개발자가 오늘부터 사용할 수 있고 별도 과금은 없으며, 토큰과 도구는 가격 페이지의 표준 요금으로 청구됨
  • 시작 문서는 Responses API quickstart guide에서 제공됨

기존 API와의 관계

  • Chat Completions API는 OpenAI에서 가장 널리 채택된 API로 계속 지원됨
    • 내장 도구가 필요 없는 개발자는 계속 사용할 수 있음
    • 내장 도구나 여러 모델 호출에 의존하지 않는 기능의 새 모델은 Chat Completions에도 계속 출시됨
    • Responses API는 Chat Completions의 상위 집합이며 동일한 성능을 제공하므로 새 통합에는 Responses API를 권장함
  • Assistants API의 베타 피드백은 Responses API에 반영되어 더 유연하고 빠르며 사용하기 쉬워짐
    • Assistant-like 객체, Thread-like 객체, Code Interpreter 도구를 포함해 Assistants API와 Responses API의 전체 기능 동등성 확보가 진행 중임
    • 기능 동등성이 완료되면 Assistants API 폐기를 공식 발표할 계획임
    • 목표 종료 시점은 2026년 중반임
    • 폐기 발표 시 데이터 보존과 애플리케이션 이전이 가능한 마이그레이션 가이드를 제공할 예정임
    • 공식 폐기 발표 전까지 Assistants API에도 새 모델을 계속 제공함
  • OpenAI는 Responses API를 OpenAI에서 에이전트를 구축하는 미래 방향으로 둠

Responses API의 내장 도구

  • 웹 검색

    • 개발자는 웹에서 빠르고 최신성 있는 답변을 명확한 출처 인용과 함께 얻을 수 있음
    • Responses API에서 웹 검색은 gpt-4o와 gpt-4o-mini 사용 시 도구로 제공되며, 다른 도구나 함수 호출과 함께 사용할 수 있음
    • 초기 테스트의 사용 사례는 쇼핑 어시스턴트, 리서치 에이전트, 여행 예약 에이전트처럼 최신 웹 정보가 필요한 앱으로 나타남
    • Hebbia는 웹 검색 도구로 자산운용사, 사모펀드·크레딧 회사, 법률 실무자가 대규모 공개·비공개 데이터셋에서 실행 가능한 인사이트를 빠르게 추출하도록 지원함
    • API의 웹 검색은 ChatGPT search에 사용되는 것과 같은 모델 기반임
    • SimpleQA에서 GPT‑4o search preview는 90%, GPT‑4o mini search preview는 88% 정확도를 기록함
    • API의 웹 검색 응답은 뉴스 기사와 블로그 글 같은 출처 링크를 포함함
    • 웹사이트나 퍼블리셔는 API 웹 검색에 표시되도록 선택할 수 있음
    • 웹 검색 도구는 Responses API에서 모든 개발자에게 프리뷰로 제공됨
    • Chat Completions API에서는 gpt-4o-search-preview, gpt-4o-mini-search-preview로 검색 모델에 직접 접근할 수 있음
    • 가격은 GPT‑4o search가 1,000쿼리당 30달러, 4o-mini search가 1,000쿼리당 25달러부터 시작함

  • 파일 검색

    • 개선된 file search 도구로 대규모 문서에서 관련 정보를 쉽게 검색할 수 있음
    • 여러 파일 형식, 쿼리 최적화, 메타데이터 필터링, 커스텀 재랭킹을 지원함
    • Responses API에서는 몇 줄의 코드로 통합 가능함
    • 사용 사례는 다음과 같음
      • 고객 지원 에이전트가 FAQ에 접근함
      • 법률 어시스턴트가 자격을 갖춘 전문가를 위해 과거 사건을 빠르게 참조함
      • 코딩 에이전트가 기술 문서를 조회함
    • Navan은 AI 기반 여행 에이전트에서 file search를 사용해 회사 여행 정책 같은 지식베이스 문서에서 정확한 답변을 빠르게 제공함
    • 내장 쿼리 최적화와 재랭킹으로 추가 튜닝이나 설정 없이 RAG 파이프라인을 구성할 수 있음
    • 사용자 그룹별 전용 벡터 저장소를 두면 계정 설정과 사용자 역할에 맞춘 답변을 제공할 수 있음
    • file search는 Responses API에서 모든 개발자가 사용할 수 있음
    • 사용량 가격은 1,000쿼리당 2.50달러이며, 파일 저장소는 하루 GB당 0.10달러이고 첫 1GB는 무료임
    • Assistants API에서도 계속 제공됨
    • Vector Store API 객체에 새 검색 엔드포인트가 추가되어 다른 애플리케이션과 API에서 사용할 데이터를 직접 조회할 수 있음

  • 컴퓨터 사용

    • computer use 도구는 Responses API에서 컴퓨터 작업을 수행하는 에이전트를 만들기 위한 기능임
    • 이 도구는 Operator를 가능하게 한 Computer-Using Agent(CUA) 모델로 구동됨
    • 연구 프리뷰 모델은 다음 벤치마크 결과를 기록함
    • 내장 computer use 도구는 모델이 생성한 마우스와 키보드 동작을 캡처함
    • 개발자는 이 동작을 자신의 환경에서 실행 가능한 명령으로 변환해 컴퓨터 사용 작업을 자동화할 수 있음
    • 사용 사례는 웹 앱 품질 보증, 레거시 시스템 간 데이터 입력 같은 브라우저 기반 워크플로 자동화임
    • Unify는 에이전트가 의도 파악, 계정 조사, 구매자 접촉을 수행하는 매출 성장용 시스템에서 computer use 도구를 사용함
    • API로 접근할 수 없던 정보도 에이전트가 활용할 수 있음
      • 예시로 부동산 관리 회사가 온라인 지도를 통해 사업체의 부동산 규모 확대 여부를 확인할 수 있음
    • Luminai는 API와 표준화된 데이터가 없는 레거시 시스템을 가진 대기업의 복잡한 운영 워크플로 자동화에 computer use 도구를 통합함
      • 한 대형 커뮤니티 서비스 조직 파일럿에서 신청 처리와 사용자 등록 절차를 며칠 만에 자동화함
      • 전통적 RPA는 같은 작업을 몇 달간 시도해도 달성하기 어려웠음
    • CUA를 Operator에 출시하기 전 오용, 모델 오류, 프런티어 위험이라는 세 영역에 대해 광범위한 안전 테스트와 레드팀을 수행함
    • API에서 CUA를 통해 Operator 기능이 로컬 운영체제로 확장되는 위험을 다루기 위해 추가 안전 평가와 레드팀도 진행됨
    • 개발자를 위한 완화책도 추가됨
      • 프롬프트 인젝션 방어를 위한 안전 점검
      • 민감한 작업에 대한 확인 프롬프트
      • 환경 격리를 돕는 도구
      • 잠재적 정책 위반에 대한 향상된 탐지
    • 완화책이 위험을 줄이지만 모델은 특히 비브라우저 환경에서 의도치 않은 실수를 할 수 있음
    • OSWorld 성능 38.1%는 운영체제 작업 자동화에서 아직 높은 신뢰성을 갖추지 못했음을 나타내며, 이 경우 사람의 감독이 권장됨
    • API별 안전 작업의 자세한 내용은 업데이트된 system card에서 확인할 수 있음

Agents SDK와 워크플로 오케스트레이션

  • 에이전트에는 핵심 로직과 도구 접근뿐 아니라 워크플로 오케스트레이션도 필요함
  • 새 오픈소스 Agents SDK는 멀티 에이전트 워크플로 오케스트레이션을 단순화함
  • 지난해 공개한 실험적 SDK Swarm보다 개선됨
  • 주요 기능은 다음과 같음
    • Agents: 명확한 지시와 내장 도구를 갖춘 쉽게 설정 가능한 LLM
    • Handoffs: 에이전트 간 제어권을 지능적으로 이전함
    • Guardrails: 입력과 출력 검증을 위한 설정 가능한 안전 점검
    • Tracing & Observability: 에이전트 실행 추적을 시각화해 디버깅과 성능 최적화를 지원함
  • 적용 가능한 실제 사용 사례는 고객 지원 자동화, 다단계 리서치, 콘텐츠 생성, 코드 리뷰, 영업 잠재고객 발굴임
  • Coinbase는 Agents SDK를 사용해 AI 에이전트가 암호화폐 지갑과 온체인 활동과 상호작용할 수 있게 하는 AgentKit을 빠르게 프로토타입하고 배포함
    • 몇 시간 만에 Developer Platform SDK의 커스텀 액션을 완전 동작하는 에이전트에 통합함
    • AgentKit의 간소화된 아키텍처가 새 에이전트 액션 추가를 단순화함
  • Box는 며칠 만에 웹 검색과 Agents SDK를 활용하는 에이전트를 만들어 Box 내부의 비정형 데이터와 공개 인터넷 소스에서 검색·질의·인사이트 추출을 가능하게 함
    • 기업 고객은 최신 정보뿐 아니라 내부 권한과 보안 정책을 따르는 방식으로 내부 독점 데이터를 검색할 수 있음
    • 예시로 금융 서비스 회사는 Box에 저장된 내부 시장 분석과 웹의 실시간 뉴스·경제 데이터를 결합하는 커스텀 에이전트를 만들 수 있음
  • Agents SDK는 Responses API와 Chat Completions API에서 동작함
  • Chat Completions 스타일 API 엔드포인트를 제공하는 경우 다른 제공자의 모델과도 함께 쓸 수 있음
  • Python 코드베이스에는 즉시 통합할 수 있으며, Node.js 지원은 곧 제공될 예정임
  • OpenAI는 Agents SDK 설계에서 Pydantic, Griffe, MkDocs의 작업에서 영감을 받음
  • Agents SDK를 오픈소스 프레임워크로 계속 구축해 커뮤니티가 접근 방식을 확장할 수 있게 할 계획임

에이전트 플랫폼 확장 방향

  • OpenAI는 에이전트가 곧 노동력의 핵심 요소가 되어 산업 전반의 생산성을 크게 높일 것으로 봄
  • 기업들이 복잡한 작업에 AI를 활용하려는 수요가 늘어나면서, 개발자와 기업이 실제 영향을 내는 자율 시스템을 만들 수 있는 구성 요소 제공에 집중함
  • 이번 공개는 신뢰할 수 있고 성능 높은 AI 에이전트를 더 쉽게 구축, 배포, 확장하기 위한 첫 구성 요소임
  • 모델 기능이 더 에이전트형으로 발전함에 따라 OpenAI는 API 전반의 더 깊은 통합과 프로덕션 에이전트 배포·평가·최적화를 돕는 새 도구에 계속 투자할 계획임
  • 목표는 어떤 산업의 다양한 작업에도 도움을 줄 수 있는 에이전트를 만들기 위한 끊김 없는 플랫폼 경험을 제공하는 것임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 실제 제품에 OpenAI를 붙이려는 개발자에게 이런 API 변동이 얼마나 도움이 될지 모르겠음
    대화, 메시지, 프롬프트 전달 등을 다루는 벤더 관리 상태 기계는 내 용도에서는 결국 부족하거나, 과도하게 가정하거나, 방해가 됐음
    결국 구조화 출력만 켠 Chat Completions API를 쓰게 되고, 그 안에서도 도구 사용, 재귀 대화, RAG 등을 충분히 하고 있음
    내 “에이전트”의 상태 관리를 서드파티에 맡길 가치는 못 느끼며, 이런 건 로컬에 두는 편이 훨씬 자율적임
    핵심은 어떤 문자열 리터럴을 블랙박스에 넣으면 새 문자열, 가능하면 JSON 같은 요청한 형식으로 받는다는 것뿐임
    매번 적절한 문자열을 조합한다는 관점에 집중하면 나머지는 사라지고, 데이터베이스의 비즈니스 상태로 고도로 구조화된 문자열을 만드는 일과 같아짐
    PHP로 웹페이지를 서버 사이드 렌더링하는 것과 사실상 같은 일이고, 진짜 차이는 제공 방식뿐임

    • 나도 같은 느낌임
      단순한 구조화 생성 호출 위에 내가 필요한 걸 더해주는 에이전트 프레임워크를 아직 못 찾았음
      LLM 요청 대부분은 “프롬프트 입력, 구조화 출력”이어야 하고, 이는 한 가지 일을 잘하라는 Unix 철학과도 맞음
      에이전트 프레임워크는 너무 이르고, 아직 흔하지 않은 설계 패턴 묶음을 추상화한 층일 뿐임
      모두가 바퀴를 다시 만들고 있음이 명확할 때만 추상화를 만들어야 하는데, 에이전트에는 발명할 바퀴가 없고 전부 단순한 언어 모델 호출임
      “언어 모델은 코드에서 가장 재미없는 부분이어야 한다”는 말을 자주 씀
      대부분의 시간은 실제 소프트웨어와 도구를 만드는 데 써야 하고, LLM은 소프트웨어의 작은 구성요소여야 함
      에이전트 프레임워크는 내 취향으로는 코드베이스에서 언어 모델의 존재감을 너무 키움
    • 나도 같은 생각임
      OpenAI의 function calling 추상화조차 매개변수와 스키마를 환각하고, JSON Schema 자체도 너무 장황해서 아주 단순한 함수 호출 5개보다 조금만 복잡해져도 완전히 무너짐
      이미 깨진 블랙박스 추상화 위에 더 쌓는 것처럼 보이고, 실제 애플리케이션에는 별로 쓸모가 없음
      작은 개념 증명 앱을 빨리 만드는 데는 도움이 될 수 있겠음
    • 맞음
      이런 API 위에 회사를 세우려면 순진해야 함
      LLM은 범용재가 될 것이고, OpenAI는 기업가치와 계속 필요한 투자 규모를 정당화하려면 그 운명에 맞서 싸울 수밖에 없음
      Assistant API 위에 만들었다면, 힌트를 받아서 Responses API로 그냥 다시 쓰지 말고 자기 제품을 소유해야 함
      오늘의 LLM은 블랙박스로 감싸두는 편이 낫다
    • 기존 API에서 비기술적 이유로 밀려나고 있다는 느낌이 듦
      “Chat Completions를 사용할 때 모델은 항상 응답 전 웹에서 정보를 가져옵니다. gpt-4o와 gpt-4o-mini 같은 모델이 필요할 때만 web_search_preview를 도구로 호출하게 하려면 Responses API로 전환하세요”라는 부분 때문임
      새 Responses API로 포팅하는 건 간단하지 않고, 우리는 이미 히스토리, RAG, 어시스턴트에 필요한 것들을 갖추고 있음
    • 더 잘 말할 수 없을 정도임
      function calling과 구조화 출력만으로 여러 에이전트를 개발했고, 1년 넘게 프로덕션에서 돌리고 있음
      예전에는 이걸 에이전트라고 부르지도 않았음
      이번 건 이미 에이전트 프레임워크와 OpenAI API를 같이 쓰는 사람들을 겨냥한 것 같음

  • 새 API 설계자가 여러 설계 결정의 배경을 설명한 좋은 Twitter 스레드가 있음: https://twitter.com/athyuttamre/status/1899541471532867821
    Twitter에 로그인하지 않은 사람을 위한 대체 링크도 있음: https://nitter.net/athyuttamre/status/1899541471532867821

  • 이런 AI 에이전트 시도들은 핵심부터 빗나간 것 같음
    새로운 방식을 만들기보다 기존 시스템에서 사람을 대체하려고 하기 때문임
    경제와 삶, 모든 것은 결국 사람과 사람의 상호작용에 관한 것이라 근본적으로 근시안적임
    지금의 AI 에이전트 접근은 “한 문장을 AI가 길고 그럴듯한 이메일로 늘리고, 받는 쪽 AI가 그 긴 이메일을 다시 한 문장으로 요약한다”는 농담의 변주처럼 보임
    기존 시스템의 작업을 자동화하는 쓸모는 이해하지만, 진짜 기회는 기존 시스템 대부분을 제거하는 데 있음
    인간이 그렇게 나쁘지는 않음
    AI로 인간용 UI를 만들고 다시 AI가 그 UI를 조작하게 하는 게 정말 앞으로 나아갈 길인지 의문임

    • “경제와 삶, 모든 것이 사람과 사람의 상호작용에 관한 것”이라면, 매일 손으로 빚고 인간 동력 가마에서 구운 수제 점토 그릇을 얼마나 쓰고 있음?
      손으로 꺾은 나뭇가지로 엮은 바구니는 얼마나 쓰고 있음?
      역사는 자동화할 수 있는 것은 자동화되고, 더 싸거나 더 빠르게 만들 수 있는 것도 그렇게 된다는 걸 보여줌
    • 현재 세대 AI 모델의 가장 가치 있는 길은 제품의 설정·관리 영역에 통합하는 것이라고 봄
      예를 들어 B2B SaaS 생태계에서 조직 내 고급 사용자가 고객 설정과 프로젝트 관리 작업을 매크로화할 수 있는 보조 사용자 경험으로 쓰는 식임
      추상화, 맥락, 사용자 집합이 잘 제한되어 있으면 도구 사용은 꽤 안정적일 수 있음

  • 눈에 띄게 빠진 것: Model Context Protocol
    https://www.anthropic.com/news/model-context-protocol

    • 100% 동의하지만, 이건 같은 것이 아니고 Agent SDK를 대체하지도 않을 것이며 그 반대도 아님
      에이전트에는 항상 어떤 형태의 통신 프로토콜이 필요하고, 에이전트형 프레임워크 세계는 로고의 바다라서 열린 표준이 없으면 어려워짐
      지금 Comet에 있고, MCP 구현 작업도 직접 했고 Agent SDK에도 네이티브 통합과 테스트 스위트 개선 형태로 기여했음
      https://github.com/comet-ml/opik-mcp
      https://github.com/openai/openai-agents-python/pull/91
      최근 통합은 첫날 바로 출시했음
      https://www.comet.com/docs/opik/tracing/integrations/openai_...
      OpenAI가 향하는 핵심은 쓰기 쉬운 구성요소를 통해 개발자에게 단순함을 제공하는 쪽이라고 봄
      전략이나 가격은 말하지 않겠지만, 개발자 관점에서 처음 봤을 때 SDK의 단순한 모듈식 접근과 군더더기 없음은 신선함
    • 직접 구현하지 않았다고 해서 지원이 안 된다는 뜻은 아님: https://github.com/dylibso/mcpx-openai-node
      이건 범용이 아니라 mcp.run 도구 호출을 OpenAI 모델과 쓰기 위한 것임
      그래도 MCP를 직접 지원하지 않는 건 개발자에게 가장 적대적인 움직임에 가깝고, OpenAI라면 놀랍지는 않음
      추가되면 아주 좋을 것임
    • 메인 스레드에는 언급되어 있음: https://nitter.net/athyuttamre/status/1899511569274347908
      “Agents SDK가 MCP 연결을 지원하나요? MCP 클라이언트-서버 연결로 특정 에이전트에 도구를 쉽게 줄 수 있나요?”라는 질문에 “원하는 도구를 정의할 수 있으므로 function calling으로 MCP 도구를 구현할 수 있다”는 답변임
      요약하면 약간의 배관 작업은 직접 해야 함
      관련 이슈: https://github.com/openai/openai-agents-python/issues/23
    • 둘 사이를 어느 정도 이어줄 수 있음: https://github.com/SecretiveShell/MCP-Bridge
    • MCP를 써본 적이 있다면 어떻게 생각하는지 궁금함

  • swyx임
    새 API 전반에 대해 API/DX 팀에게 미리 보고 자주 묻는 질문을 물어볼 시간이 있었음
    https://latent.space/p/openai-agents-platform
    재미있는 핵심은 이제 응답이 기본적으로 무료 저장되므로 Responses API를 데이터베이스처럼 남용할 수 있느냐는 것임
    HN 사람들이 좋아할 만한 질문들도 있음
    웹 검색의 하이퍼파라미터, 즉 DIY Deep Research를 만들 때 검색의 깊이와 폭을 조정하는 법
    OAI가 Responses API 일부로 RAG와 재순위를 기본 제공하게 된 지금, 언제 직접 RAG를 만들어야 하는가
    개인적으로는 Files API의 RAG 성능을 누군가 벤치마크해야 한다고 봄. 커뮤니티 인상은 Assistants API 첫 출시 때에서 크게 업데이트되지 않은 것 같음
    Agents SDK와 OAI Swarm의 차이는 대략 타입, 추적, 교체 가능한 LLM임
    search-preview와 computer-use-preview 파인튜닝이 GPT5에 병합될지도 궁금함

    • “qtns”가 뭐임?
    • Agents SDK는 마음에 들지만 프레임워크가 OpenAI에 묶이는 건 싫다면 PydanticAI가 꽤 마음에 듦
      0 - https://ai.pydantic.dev/
    • 웹 검색 하이퍼파라미터 질문은 고마움
      이런 AI 검색 도구를 직접 만드는 주된 이유 중 하나가 깊이와 폭을 완전히 제어하고, 로더도 원하는 데이터나 사이트에 맞게 커스터마이즈할 수 있기 때문임
      현재 웹 검색은 어떤 사이트에 전체 텍스트가 없고 어떤 사이트는 스니펫만 쓰는지 투명하지 않음
      컴퓨터 사용과 웹 검색을 함께 갖는 건 확실히 강력함. 본질적으로 OpenAI의 Deep Research 같은 것임

  • 발표에서 가격을 공개하지 않았음
    매우 비쌀 걸 알고 있었기 때문일 가능성이 큼
    웹 검색 [0]: GPT‑4o search와 4o-mini search가 1,000쿼리당 각각 $30, $25
    파일 검색 [1]: 1,000쿼리당 $2.50, 파일 저장은 $0.10/GB/일, 첫 1GB 무료
    컴퓨터 사용 도구(computer-use-preview 모델) [2]: 입력 100만 토큰당 $3, 출력 100만 토큰당 $12
    [0] https://platform.openai.com/docs/pricing#web-search
    [1] https://platform.openai.com/docs/pricing#built-in-tools
    [2] https://platform.openai.com/docs/pricing#latest-models

    • 특히 웹 검색 가격은 터무니없음
      이 API가 https://www.anthropic.com/news/model-context-protocol보다 어떻게 나은지 잘 모르겠음
      동기는 “사용자에게 어떻게 더 유용해질까”보다 “어떻게 더 돈을 벌까”였던 것처럼 보임
    • 결국 글자를 무게 단위로 팔던 데서 웹 검색과 클라우드 저장소를 파는 쪽으로 피벗하는 셈인가 봄
      마음에 듦, 대담한 움직임
      Google의 느린 사람들이 마침내 따라잡을 때쯤엔 Google에게 너무 늦을지도 모름
    • 찾는 사람을 위해, Brave Search는 1,000요청당 $3임 [0]
      웹을 검색하고 꽤 잘 동작하는 스크립트도 작성했음. vercel ai sdk를 사용함 [1]
      [0] - https://brave.com/search/api/
      [1] - https://gist.github.com/bramses/41e90b27d156590154bcefd4119f...

  • Responses API보다 훨씬 단순하고 강력한 버전을 직접 만들었고, 모든 LLM 제공자와 동작함
    https://github.com/Anilturaga/aiide

    • GitHub 별이 이렇게 적은데도 이틀 사이에 aiide 프로젝트를 네 번째로 보고 있어서 놀람
      보기 좋고, 정말 좋아 보임

  • “Assistant API의 지원 중단을 공식 발표할 계획이며 목표 종료 시점은 2026년 중반”이라는 문구가 있음
    새 Responses API는 내장 “handoff” 기능까지 포함해 올바른 방향의 한 걸음임
    다만 에이전트형 사용 사례에는 아직 좀 제한적으로 느껴지고, 공식적인 가드레일·상태 기계 로직이 부족함
    “개발자가 에이전트를 만들 수 있는 매끄러운 플랫폼 경험을 제공하는 것이 목표”라고 했는데, 이 플랫폼으로 어떻게 이동할지 흥미로움
    몇 달 안에 그래프 기반 제어 흐름을 보게 될 것 같음
    지금도 오픈소스 해법은 무수히 많지만 대부분 부족하거나 불필요한 불투명함과 복잡성을 더함
    도구 호출과 JSON 응답 조합으로 에이전트형 흐름을 만들 수는 있었지만, 아직 아무도 제대로 풀지 못한 상위 구성요소가 빠져 있음

  • 여기서 언급된 Computer Use의 발전이 인상적이라, 이미 사용성 테스트에 활용할 만큼 성숙했는지 궁금해짐
    일반적으로 AI가 탐색하기 어려운 UI라면 사람에게도 상대적으로 어려울 가능성이 높고, 어떤 식으로든 단순화하거나 개선해야 한다는 신호라고 봐도 될까?

    • 왜 그렇게 가정하는지 모르겠음
      LLM이 UI와 상호작용하는 양식과 인간이 UI를 쓰는 방식은 크게 다름

  • 링크된 Agents SDK가 404로 뜸
    참고로 MindRoot에는 task API를 사용해 Responses와 File Search 일부와 비슷한 것이 있음: https://github.com/runvnc/mindroot/blob/main/api.md
    이건 mr_kb 플러그인의 query_kb 도구와 결합할 수 있고, 여러 KB 검색을 허용하므로 실제로 File Search보다 나을 수도 있음
    내 프로그램을 돕거나 플러그인을 만들거나 PR을 보내고 싶은 사람은 GitHub, 이메일, Discord/Telegram(runvnc)으로 편하게 연락해도 됨

답변달기