OpenAI Agent Builder 종료 해설: 에이전트 자동화는 화면 빌더보다 SDK·Workspace Agent·운영 경계를 먼저 나눠야 하는 이유

1. 한 줄 문제 정의

핵심 한 줄: Agent Builder 종료는 단순한 제품 종료가 아니라, 에이전트 자동화를 어디에서 소유하고 운영할지 다시 정해야 하는 신호입니다.

2026년 6월 3일 OpenAI는 Agent Builder와 Evals 제품을 단계적으로 종료한다고 공지했습니다. 공지에 따르면 2026년 11월 30일 이후 두 제품은 OpenAI 플랫폼에서 더 이상 제공되지 않으며, 코드로 유지해야 하는 워크플로는 Agents SDK로, 자연어 기반 팀 업무 자동화는 ChatGPT의 Workspace Agents로 옮기는 방향이 권장됩니다.

이 글의 대상은 Agent Builder로 고객지원, 내부 리서치, 문서 생성, 검수 자동화를 만들었거나 만들 계획이 있던 개발자와 운영 담당자입니다. 단순 챗봇 실험에는 과한 내용일 수 있지만, 반복 업무를 팀 프로세스에 붙이려는 조직이라면 지금 이전 설계를 시작해야 합니다.

2. 먼저 결론

핵심 한 줄: 제품 화면에서 만든 에이전트는 빠르게 시작하기 좋지만, 장기 운영은 코드와 권한 체계로 옮겨야 흔들리지 않습니다.

저는 기존 Agent Builder 사용자가 먼저 해야 할 일을 “기능 복제”가 아니라 “운영 경계 재설계”라고 봅니다. 에이전트가 어떤 도구를 호출하는지, 실패하면 누가 복구하는지, 로그를 어디까지 남기는지, 팀원이 수정할 수 있는 범위가 무엇인지부터 분리해야 합니다.

추천 방향은 세 갈래입니다. 제품 안에서 팀원이 같이 쓰는 반복 업무는 Workspace Agents, 애플리케이션 백엔드나 고객-facing 기능은 Agents SDK, 단순한 단발성 응답 생성은 Responses API 직접 호출이 더 적합합니다. 반대로 규정 준수 로그, 승인 흐름, 테스트 자동화가 없는 상태에서 “기존 빌더 화면과 똑같이 빨리 옮기기”만 목표로 잡는 것은 비추천합니다.

3. 핵심 구조 분해

핵심 한 줄: 전환 대상은 프롬프트 하나가 아니라 모델 호출, 도구 권한, 상태, 추적, 배포 위치의 묶음입니다.

Agent Builder를 쉽게 말하면 화면에서 에이전트의 지시문, 도구, 흐름을 조립하는 방식입니다. 편리하지만 운영 책임의 일부가 제품 UI 안에 묶입니다. Agents SDK는 같은 개념을 코드로 가져옵니다. SDK 문서 기준으로 Agent와 Runner가 대화 턴, 도구, guardrails, handoffs, sessions를 관리합니다.

Workspace Agents는 팀 업무 자동화에 더 가깝습니다. ChatGPT Business, Enterprise, Edu 릴리스 노트에 따르면 워크스페이스 단위로 공유되고, 연결 앱별 작업 안전장치를 설정하며, 관리자 콘솔에서 활동과 사용량을 볼 수 있습니다. 즉 “앱 안의 기능”보다는 “조직 안의 반복 작업자”에 가깝습니다.

4. 설계 의도 해설

핵심 한 줄: OpenAI의 권장 경로는 “모든 것을 한 화면에서 만들기”보다 “업무 성격에 맞는 실행 위치를 고르기”에 가깝습니다.

코드형 SDK는 개발팀이 운영 책임을 가져가는 선택입니다. 장점은 테스트, 버전 관리, CI/CD, 자체 로그 파이프라인과 잘 붙는다는 점입니다. 비용은 분명합니다. 개발자가 에이전트 루프와 도구 권한을 이해해야 하고, 장애 대응도 제품 팀 책임이 됩니다.

Workspace Agents는 업무 부서가 반복 프로세스를 공유하기 좋은 선택입니다. 예를 들어 주간 리서치 요약, Slack 채널 기반 이슈 정리, 내부 문서 초안 작성처럼 “팀 안에서 돌고, 관리자가 볼 수 있어야 하는 작업”에 맞습니다. 대신 제품 백엔드처럼 세밀한 런타임 제어가 필요한 경우에는 SDK보다 답답할 수 있습니다.

이 변화의 설계 의도는 한 문장으로 정리됩니다. 에이전트를 실험 도구에서 운영 자산으로 바꾸려면, 빌더의 편의성보다 실행 위치와 책임 경계를 먼저 분리해야 합니다.

5. 근거 및 비교

핵심 한 줄: 선택 기준은 “무엇을 만들 수 있나”가 아니라 “누가 고치고, 누가 승인하고, 어디에 로그가 남나”입니다.

Agents SDK의 추적 기능도 중요한 근거입니다. SDK 문서는 LLM 생성, 도구 호출, handoff, guardrail, 사용자 정의 이벤트까지 실행 기록을 수집한다고 설명합니다. 에이전트 운영에서 trace는 “나중에 보면 좋다”가 아니라, 실패 원인을 찾기 위한 최소 장치입니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 한 줄: 이전은 화면 캡처가 아니라 인벤토리, 분류, 재구현, 검증, 컷오버 순서로 진행해야 합니다.

1. Agent Builder 인벤토리 작성: 에이전트 이름, 목적, 입력, 출력, 연결 도구, 사용 권한, 실패 시 사람 개입 지점을 표로 만듭니다.
2. 업무 성격 분류: 팀 내부 공유 업무는 Workspace Agents 후보, 제품 기능은 Agents SDK 후보, 단발성 호출은 Responses API 후보로 나눕니다.
3. 도구 권한 재정의: 읽기 전용, 초안 생성, 외부 전송, 결제/삭제처럼 위험도가 다른 행동을 분리합니다.
4. SDK 후보 PoC 작성: 지시문, 도구 함수, guardrail, trace 확인을 최소 단위로 구현합니다.
5. 평가 데이터셋 준비: 성공 케이스 10개, 실패 케이스 10개, 애매한 케이스 5개를 만들어 배포 전마다 돌립니다.

python -m venv .venv
source .venv/bin/activate
pip install openai-agents
pytest tests/agent_cases -q

from agents import Agent, Runner, function_tool

@function_tool
def lookup_policy(topic: str) -> str:
    return "정책 문서에서 확인한 요약을 반환합니다."

agent = Agent(name="internal-policy-helper", instructions="근거가 없으면 답하지 말고 필요한 문서를 요청하세요.", tools=[lookup_policy])
result = Runner.run_sync(agent, "휴가 정산 규칙을 확인해줘")
print(result.final_output)

7. 실수/함정(Pitfalls)

핵심 한 줄: 가장 큰 실패는 기능은 옮겼지만 운영 기준은 옮기지 않는 것입니다.

함정 1: 프롬프트만 복사하고 권한을 그대로 둔다

예방책은 도구별 위험 등급을 새로 매기는 것입니다. 복구는 외부 쓰기 작업을 일시 중지하고, 승인 필요한 액션을 별도 도구로 분리하는 방식이 좋습니다.

함정 2: trace 없이 “잘 되는 것 같다”로 배포한다

예방책은 최소한 도구 호출, 최종 응답, guardrail 결과를 남기는 것입니다. 장애가 난 뒤에는 사용자 보고만으로 원인을 찾기 어렵기 때문에, trace 대시보드나 자체 로그에 실행 단계를 남겨야 합니다.

함정 3: Workspace Agents와 제품 에이전트를 섞는다

예방책은 실행 위치를 먼저 정하는 것입니다. 팀 업무 자동화는 워크스페이스 관리 모델과 잘 맞지만, 고객별 권한과 결제, 데이터 격리가 필요한 제품 기능은 SDK나 자체 백엔드가 더 적합합니다.

함정 4: 2026년 11월 30일을 단순 마감일로 본다

복구 가능한 이전을 하려면 최소 한 번의 병행 운영 기간이 필요합니다. 저는 8월까지 인벤토리, 9월까지 PoC, 10월까지 병행 운영, 11월 초 컷오버를 권합니다.

8. 강점과 한계

핵심 한 줄: 전환은 번거롭지만, 성공하면 에이전트를 더 오래 운영할 수 있는 구조가 됩니다.

Agents SDK로 옮기면 에이전트가 코드 저장소 안으로 들어옵니다. 그래서 리뷰, 테스트, 배포, 롤백이 가능해집니다. 특히 여러 에이전트가 handoff로 역할을 나눠야 하거나, 세션 상태를 이어가야 하거나, 도구 호출 로그를 감사해야 한다면 SDK 쪽이 유리합니다.

Workspace Agents의 강점은 팀 확산입니다. 기술자가 아닌 팀원도 반복 업무를 공유하고, 관리자는 활동과 사용량을 확인할 수 있습니다. 다만 모든 조직이 곧바로 써야 하는 것은 아닙니다. 연결 앱 권한 정리가 안 됐거나, 외부 전송 승인이 불명확한 팀은 먼저 데이터 접근 정책을 정해야 합니다.

한계도 있습니다. 전환 과정에서 기존 빌더 기능과 1:1로 맞지 않는 부분이 생길 수 있고, 평가 체계를 직접 보완해야 할 수 있습니다. 따라서 “더 좋은 도구가 나왔으니 전부 이동”이 아니라, 업무별로 남길 것과 옮길 것을 분리해야 합니다.

9. 더 깊게 공부할 포인트

핵심 한 줄: 공식 공지, SDK 실행 루프, trace, guardrail, Workspace Agents 관리 기능을 순서대로 보면 됩니다.

• OpenAI AgentKit 공지 및 2026년 6월 3일 업데이트 - Agent Builder와 Evals 종료 일정 및 권장 전환 경로 확인
• OpenAI Agents SDK: Agents 문서 - Agent와 Runner가 무엇을 관리하는지 확인
• OpenAI Agents SDK: Running agents 문서 - 도구 호출, handoff, 최종 출력까지의 실행 루프 이해
• OpenAI Agents SDK: Tracing 문서 - LLM 생성, 도구 호출, guardrail 이벤트 추적 방식 확인
• ChatGPT Enterprise & Edu 릴리스 노트 - 2026년 5월 7일 EKM 지원, 5월 22일 Workspace Agents GA, 2026년 7월 6일 과금 시작 일정 확인

초보 개발자라면 먼저 Runner의 실행 루프를 보세요. 에이전트는 “똑똑한 프롬프트”가 아니라, 모델 호출과 도구 실행을 반복하면서 멈출 조건을 찾는 작은 운영 시스템입니다.

10. 실행 체크리스트 + 작성자 관점

핵심 한 줄: 이전 완료 기준은 “새 도구에서 한 번 실행됨”이 아니라 “실패해도 추적하고 되돌릴 수 있음”입니다.

• 기존 Agent Builder 에이전트 목록과 소유자를 문서화했다.
• 각 에이전트를 Workspace Agents, Agents SDK, Responses API, 폐기 후보로 분류했다.
• 연결 도구를 읽기, 쓰기, 외부 전송, 삭제/결제 같은 위험 등급으로 나눴다.
• 배포 전 평가 케이스를 최소 25개 이상 만들었다.
• trace 또는 자체 로그에서 입력, 도구 호출, 최종 출력, 실패 원인을 확인할 수 있다.
• 2026년 11월 30일 전에 병행 운영과 롤백 경로를 한 번 이상 검증했다.
• Workspace Agents를 쓰는 경우 관리자 콘솔에서 활동과 사용량을 확인할 담당자를 정했다.

제 판단은 명확합니다. Agent Builder 종료를 “귀찮은 마이그레이션”으로만 보면 손해입니다. 이번 기회에 에이전트의 권한, 상태, 평가, 로그를 코드와 워크스페이스 운영 기준으로 나누면, 다음 제품 변화에도 덜 흔들리는 자동화가 됩니다.

WRITING-STANDARD 자가채점