OpenAI 에이전트 API로 나만의 AI 직원 만들기 (2026)

에이전트 네 개가 서로를 부르며 11일 동안 멈추지 않았습니다. 아무도 몰랐고, 청구서는 47,000달러였습니다. "AI 직원을 만든다"는 말은 모델을 고르는 일이 아니라, 그 직원이 어디까지 손대도 되는지를 정하는 일입니다.

문제의 파이프라인은 평범했습니다. 시장 조사를 자동화하려고 만든 네 개짜리 구성이었고, 그중 분석 담당과 검증 담당이 서로에게 "다시 확인해줘"를 주고받기 시작했습니다. 종료 조건이 없었고, 예산 상한도 없었습니다. 두 에이전트는 성실하게 일했습니다. 11일 동안.

이 글은 OpenAI Agents SDK가 무엇인지 소개하는 글이 아닙니다. 당신이 지금 하고 있는 업무 하나를 실제로 에이전트에게 넘길 때, 코드보다 먼저 결정해야 하는 네 가지 — 도구 정의, 권한 경계, 실패 처리, 비용 — 를 다룹니다. 이 네 가지가 비어 있으면 데모는 되고 업무는 안 됩니다.

"똑똑한 모델"은 실패 원인의 4분의 1도 아니다

2026년 들어 가장 많이 인용된 숫자가 있습니다. 에이전트 파일럿의 86~89%가 프로덕션까지 가지 못한다는 것. Deloitte의 2026 기술 트렌드 보고서는 89%를 제시했고, 독립적인 여러 조사가 비슷한 범위를 반복해서 내놨습니다.

흥미로운 건 총량이 아니라 분해입니다. Forrester가 실패 원인을 쪼갰더니 이렇게 나왔습니다.

앞의 두 항목을 더하면 74%입니다. 둘 다 모델이 똑똑한지와 아무 상관이 없습니다. "무엇을 잘한 것으로 칠지 안 정했다"와 "일할 도구를 안 줬다"는, 사람 신입사원을 앉혀놔도 똑같이 망하는 조건입니다.

그런데 우리가 에이전트를 도입할 때 실제로 시간을 쏟는 곳은 어디일까요. 모델 비교, 프롬프트 튜닝, 벤치마크 점수. 신입을 뽑을 때 학점만 보고 결재 권한·보고 라인·법인카드 한도를 아무것도 안 정해준 채 첫날 출근시키는 것과 같습니다. 회사는 그렇게 하지 않습니다. 에이전트에는 그렇게 합니다.

참고로 능력치 쪽 숫자도 생각만큼 편하지 않습니다. Stanford AI Index 2026 기준 에이전트의 단일 실행 성공률은 66%였고, 실제 프로덕션 환경 측정치는 56.6%였습니다. 더 뼈아픈 건 반복 실행입니다. 한 번 돌렸을 때 60% 성공하던 구성이 여덟 번 연속 성공(pass@8) 기준으로는 25%로 주저앉았습니다. 한 번 되는 걸 봤다고 매일 돌아간다는 뜻이 아니라는 얘기입니다.

업무를 자르고, 자른 조각을 도구로 적는다

Agents SDK는 네 개의 기본 개념 위에 서 있습니다. Agent(지시와 도구를 가진 주체), Tool(에이전트가 호출할 수 있는 함수), Handoff(다른 에이전트에게 넘김), Guardrail(입출력 검사). AgentKit이라는 이름으로 묶여 있는 건 이 SDK와 Responses API, 그리고 채팅 UI를 붙여주는 ChatKit입니다.

여기서 실무자가 실제로 고민하게 되는 지점은 SDK 문법이 아니라 업무를 어디서 자르느냐입니다. 예를 들어 "고객 환불 요청 처리"를 넘긴다고 해봅시다. 이걸 도구 하나로 만들면 이렇게 됩니다.

@function_tool
def process_refund(order_id: str, reason: str) -> str:
    """주문을 환불 처리한다."""
    ...

동작은 합니다. 그리고 사고도 납니다. 이 도구는 조회·판단·실행이 한 덩어리로 붙어 있어서, 에이전트가 판단을 틀리는 순간 돈이 이미 나갑니다. 중간에 끼어들 자리가 없습니다.

같은 업무를 세 조각으로 자르면 모양이 달라집니다.

@function_tool
def get_order(order_id: str) -> dict: ...          # 읽기 — 안전

@function_tool
def check_refund_policy(order: dict) -> dict: ...  # 판단 — 근거를 남김

@function_tool(needs_approval=True)
def issue_refund(order_id: str, amount: int) -> str: ...  # 실행 — 사람 확인

이제 에이전트가 정책을 잘못 해석해도 마지막 문에서 걸립니다. 그리고 check_refund_policy가 내놓은 근거가 로그에 남기 때문에, 나중에 "왜 이렇게 판단했지"를 되짚을 수 있습니다. 도구를 잘게 자르는 건 성능 최적화가 아니라 사고 조사 가능성을 확보하는 일입니다.

결재선을 어디에 그을 것인가

SDK에는 사람 확인을 위한 장치가 준비돼 있습니다. 도구 정의에 needs_approval을 True로 두면, 에이전트는 그 도구를 실행하는 대신 승인 요청(interruption)을 기록하고 멈춥니다. 실행 결과에는 대기 중인 항목 목록과 재개 가능한 상태가 함께 돌아옵니다.

result = await Runner.run(agent, "3만원 환불 처리해줘")

for it in result.interruptions:       # 대기 중인 승인 요청
    state = result.state
    state.approve(it)                 # 또는 state.reject(it)

result = await Runner.run(agent, state)   # 같은 run 을 이어서 재개

여기서 중요한 성질 하나. OpenAI 공식 문서는 이 state를 직렬화해 저장했다가 나중에 재개해도 같은 run으로 이어진다고 명시합니다. 즉 팀장이 퇴근했다가 다음 날 아침에 승인해도 흐름이 끊기지 않습니다. 슬랙 승인 버튼 하나로 결재를 받는 구조가 여기서 나옵니다.

그런데 바로 여기서 이 일의 가장 불편한 딜레마가 나옵니다.

승인 게이트를 전부 걸면 안전하지만, 그건 자동화가 아니라 그냥 사람이 하는 일에 클릭이 하나 더 붙은 것이다.

게이트를 하나도 안 걸면 11일짜리 청구서가 나오고, 전부 걸면 도입할 이유가 사라집니다. 정답은 "적당히"가 아니라 동작의 성질별로 다르게입니다. 실무에서 쓸 만한 구분선은 이 정도입니다.

OWASP가 2026년 문서에서 쓴 표현이 이 태도를 잘 요약합니다. 제로 트러스트 툴링 — 모든 도구 호출은 안전함이 증명되기 전까지 고위험으로 취급한다. 에이전트를 의심하라는 뜻이 아니라, 신뢰를 도구 단위로 쪼개서 부여하라는 뜻입니다.

실패하는 방식과 돈 쓰는 방식까지 정해줘야 한다

도구를 자르고 결재선을 그었다면 절반입니다. 남은 절반은 잘못됐을 때 무슨 일이 일어나는가입니다.

가드레일은 에이전트 실행과 병렬로 돌면서 입력·출력·도구 인자를 검사하고, 걸리면 즉시 중단합니다. input_guardrails는 들어오는 요청을, output_guardrails는 나가는 최종 답변을, tool_guardrails는 붙어 있는 함수 도구의 인자와 결과를 봅니다. 위반이 감지되면 tripwire_triggered가 켜지고 실행이 끊깁니다.

실무에서 특히 값어치를 하는 건 세 번째입니다. 모델이 "환불 3만원"을 "환불 3,000만원"으로 넘기는 사고는 출력 검사로는 못 잡습니다. 이미 실행된 뒤니까요. 인자 단계에서 상한을 검사해야 잡힙니다.

그리고 비용. 에이전트가 비싼 이유는 모델 단가가 아니라 호출 구조입니다. 추론 루프의 매 스텝은 새 메시지만 보내는 게 아니라 누적된 대화 전체를 다시 보냅니다. 같은 작업이라도 채팅 대비 토큰 소모가 수십 배로 뛰는 이유가 여기 있습니다.

단가만 보면 Luna가 싸 보이지만, 판단을 잘못해 루프를 세 번 더 도는 순간 Terra보다 비싸집니다. 모델 선택은 단가가 아니라 "한 번에 맞힐 확률 × 루프 길이"로 계산해야 합니다.

이 대목은 개인 프로젝트만의 이야기가 아닙니다. 2026년 상반기에 Uber는 연간 AI 코딩 예산을 4월에 다 썼고, Microsoft는 사내에 풀었던 코딩 도구 라이선스를 몇 달 만에 회수했습니다. 큰 회사도 한도부터 배웠습니다.

OpenAI가 자기 노코드 도구를 접은 이유

2026년 6월 3일, OpenAI는 Agent Builder의 지원 종료를 공지했습니다. 드래그앤드롭으로 에이전트 워크플로를 조립하던 그 비주얼 캔버스입니다. 종료일은 11월 30일. 출시 여덟 달 만이었습니다.

노코드가 나빠서가 아닙니다. 지금까지 이야기한 것들 — 도구를 어떻게 잘랐는지, 결재선이 어디 그어졌는지, 한도가 얼마인지 — 을 버전 관리하고, 테스트하고, 잘못되면 되돌리는 일이 캔버스 위에서는 되지 않기 때문입니다. 업무를 넘기는 일은 그림 그리기보다 코드에 가까웠던 겁니다. OpenAI는 코드 우선 SDK와, 비개발자를 위한 자연어 기반 워크스페이스 에이전트 두 갈래로 정리했습니다.

그렇다고 "직원을 대체한다"는 결론으로 건너뛰지는 맙시다. 국내 도입 사례들이 보여주는 모양은 훨씬 수수합니다. LG유플러스는 고객 응대 전체를 바꾼 게 아니라 로밍 챗봇 하나부터 시작했고, 포스코는 사내 문서 검색부터 열었습니다. 네이버웍스의 업무 에이전트도 회의록 생성·결재 문서 검토·인사 Q&A처럼 경계가 분명한 조각들입니다. 현장에서 보고되는 체감은 주당 3~5시간 절감 수준이고, 그 정도면 충분히 좋은 숫자입니다.

결국 "나만의 AI 직원"에서 어려운 단어는 AI가 아니라 직원 쪽이었습니다. 업무 기술서를 쓰고, 결재 권한을 정하고, 사고 났을 때 누가 어떻게 알아채는지를 정하고, 한 달에 얼마까지 쓸 수 있는지를 정하는 일. 그 네 가지를 문서로 못 쓰는 업무라면, 그건 아직 에이전트에게 넘길 수 있는 업무가 아닙니다. 사람에게도 못 넘기고 있었을 테니까요.

그러니 다음 질문은 "어떤 모델을 쓸까"가 아니라 이쪽이 낫습니다. 지금 내 업무 중에서, 되돌릴 수 있고 성공 기준을 한 줄로 쓸 수 있는 조각은 무엇인가. 거기서부터가 1일차입니다.