스크립트를 더 짜는 순간, 자동화는 이미 늦었다

주간 리포트 하나를 만들기 위해 메일을 열고, 첨부된 CSV를 내려받고, 파일명을 바꾸고, 폴더를 찾고, 대시보드를 갱신하고, 요약을 써서 다시 보낸다. 정작 판단은 몇 분이면 끝나는데, 판단에 도달하기 위한 이동이 한 시간을 먹는다.

우리는 이 이동을 줄이려고 스크립트를 만든다. 그런데 파일명 하나가 달라지고, 고객마다 저장 위치가 달라지고, 숫자 하나가 비면 스크립트는 멈춘다. 사람이 예외를 처리하고 나면 자동화는 사라지고, 사람이 스크립트의 런타임이 된다.

에이전트가 필요한 이유는 AI가 더 똑똑해서가 아니다. 사람이 모든 분기를 미리 코드로 적는 대신, 목표와 도구와 중단 조건을 설계하는 쪽으로 자동화의 단위를 바꿀 수 있기 때문이다. 다만 이 변화는 “이제 AI가 알아서 다 한다”는 선언과는 거리가 멀다. 어디까지 맡길지 정하지 않으면, 자동화는 편리한 조수가 아니라 권한을 가진 사고 지점이 된다.

핵심 결론

스크립트를 버리고 에이전트를 사는 것이 아니다. 반복 수집·계산은 코드로 남기고, 문서 검색·맥락 해석·초안 작성만 도구를 쓸 수 있는 에이전트에 맡긴다. 외부 발송과 데이터 변경은 사람의 승인 뒤에 둔다.

외부 정보: 자동화의 다음 단위가 ‘조건’에서 ‘목표’로 바뀐다

Search Engine Land의 Frederick Vallaeys는 PPC 자동화가 수동 최적화, 자동 규칙, Google Ads 스크립트, 여러 자동화의 결합을 거쳐 에이전트로 이동하고 있다고 설명한다. 이 흐름에서 에이전트는 광고 문구를 생성하는 데서 멈추지 않는다. 캠페인 데이터를 읽고, 관련 문서를 찾고, 필요한 도구를 호출하고, 다음 작업을 이어간다.

전통적인 스크립트는 if X, do Y에 강하다. 입력과 규칙이 고정되어 있을수록 빠르고 재현 가능하다. 반면 에이전트는 “지난주 캠페인 리포트를 읽고 이상한 변화를 찾아 검토용 요약을 만들어라”처럼 결과 중심의 요청을 받아, 허용된 도구를 조합해 다음 단계를 선택한다.

구분스크립트도구를 쓰는 에이전트
출발점미리 정한 조건과 분기달성할 목표와 제약
변화 대응예외가 생길 때 코드 수정상황을 해석하고 다음 도구 선택
잘하는 일계산, 정규화, 검증, 반복 호출검색, 분류, 요약, 맥락 연결
실패 대응오류 코드와 재시도 규칙질문, 중단, 사람 승인으로 전환
필수 관리입력·출력 테스트권한·trace·평가·승인 기준

OpenAI는 2025년 3월 Responses API와 Agents SDK를 공개하며 이 구조를 개발 단위로 만들었다. Responses API에는 웹 검색, 파일 검색, 컴퓨터 사용 같은 내장 도구를 연결할 수 있고, Agents SDK에는 단일·멀티 에이전트 오케스트레이션, handoff, guardrail, 실행 추적 기능이 포함됐다.

핵심은 API 이름이 아니다. 모델의 출력문을 받는 데서 끝나지 않고, 검색하고 → 읽고 → 판단하고 → 도구를 호출하는 한 덩어리를 애플리케이션의 기본 단위로 만들었다는 점이다. 자동화가 답변 생성에서 업무 실행으로 한 칸 이동한 셈이다.

MCP는 만능 열쇠가 아니라 권한이 적힌 메뉴판이다

이 연결을 가능하게 하는 중요한 부품이 Model Context Protocol, MCP다. 원문 기사는 MCP를 에이전트와 외부 도구·데이터를 연결하는 배관에 비유한다. AgentKit이 수도꼭지라면 MCP는 어떤 물이 어느 방향으로 흐를 수 있는지 정하는 배관이다.

이 비유에서 빠뜨리면 안 되는 단어가 capability다. MCP를 연결했다고 시스템 전체의 권한이 모델에 넘어가는 것이 아니다. MCP 서버 개발자가 정의한 기능 목록만 노출되고, 에이전트 workflow에 어떤 기능을 붙일지도 다시 선택한다.

Search Engine Land가 소개한 Google Ads MCP의 당시 기능은 엔티티 검색과 연결된 고객 목록 조회처럼 읽기 중심이었다. 입찰가를 바꾸거나 광고를 생성하는 기능은 제공하지 않았다. 이 제한은 제품이 덜 완성됐다는 증거이면서 동시에 좋은 설계의 예이기도 하다. 자동화의 신뢰성은 할 수 있는 일의 수가 아니라, 할 수 없는 일이 명확한지에서 시작한다.

AgentKit이 보여준 것과, 이미 바뀐 것

OpenAI는 2025년 10월 AgentKit을 소개했다. Agent Builder는 멀티 에이전트 workflow를 시각적 canvas에서 구성하고 버전 관리하는 도구였고, Connector Registry는 데이터와 도구 연결을 중앙에서 관리하는 기능이었다. ChatKit은 제품 안에 에이전트형 채팅 경험을 임베드하는 역할을 맡았다. Evals에는 데이터셋, trace grading, 프롬프트 최적화 같은 평가 기능이 추가됐다.

표면적으로는 “AI를 위한 Zapier”처럼 보인다. Gmail, Dropbox, Slack 같은 서비스를 블록으로 연결하고, 자연어로 작업을 설명한다는 점은 익숙하다. 그러나 이 소식에서 더 중요한 부분은 블록 수가 아니다. 제품·법무·엔지니어링이 같은 workflow를 보면서 업무의 숨은 판단 단계를 표면으로 끌어낼 수 있다는 점이다.

동시에 제품 수명주기는 따로 봐야 한다. OpenAI는 공식 AgentKit 발표문을 2026년 6월 3일 업데이트해 Agent Builder와 Evals를 종료할 예정이라고 밝혔다. 2026년 11월 30일부터 두 제품은 OpenAI 플랫폼에서 제공되지 않으며, 코드로 계속 운영할 workflow에는 Agents SDK를, 자연어 중심 사용 사례에는 ChatGPT의 Workspace Agents를 권장한다.

이 변화는 에이전트 전략이 틀렸다는 뜻이 아니다. 오히려 반대다. 제품의 canvas가 아니라 workflow의 계약을 자산으로 삼아야 한다는 뜻이다. 입력 데이터, 출력 형식, 도구 권한, 승인 기준, 실패 시 중단 조건을 문서와 코드로 남겨야 한다. 그러면 builder가 바뀌어도 업무 설계는 옮길 수 있다.

컴퓨터를 조작할 수 있다고, 컴퓨터를 맡겨도 되는 것은 아니다

OpenAI의 computer use 도구는 API가 없는 레거시 시스템이나 브라우저 기반 workflow까지 자동화할 가능성을 열었다. 기존 RPA가 다루기 어려웠던 화면을 보고 클릭하고 입력하는 방식이다. 연결할 API가 없는 시스템을 아직 버리지 못한 조직에는 분명한 이득이 있다.

하지만 OpenAI가 공개한 초기 평가에서 OSWorld 성공률은 38.1%였고, 같은 표에서 인간 성능은 72.4%였다. OpenAI도 특히 브라우저 밖의 환경에서는 사람의 감독이 필요하다고 설명한다. 이 숫자는 “절반도 못 한다”는 단순한 조롱거리가 아니라, 자동화의 경계를 계산하게 하는 신호다.

화면 조작은 결제, 삭제, 게시, 권한 변경처럼 되돌리기 어려운 작업과 만나면 위험이 급격히 커진다. 컴퓨터 사용 도구는 사람이 사라지는 버튼이 아니라, 사람이 확인할 화면과 승인 지점을 설계해야 하는 새로운 실행 방식이다.

실제 워크플로에 넣는 가장 작은 단위

첫 도입 대상으로 고객 대응 전체나 광고 집행 전체를 고르면 안 된다. 결과가 틀려도 손실이 작고, 반복 빈도가 높고, 사람이 쉽게 검토할 수 있는 작업부터 고른다. 좋은 첫 후보는 지난 7일의 데이터를 읽어 검토용 요약을 만드는 일이다.

  1. 목표를 결과물로 쓴다. “캠페인 데이터를 분석해줘”가 아니라 “지난 7일 데이터를 읽고 변화 세 가지, 누락된 데이터, 확인이 필요한 항목을 포함한 검토용 문서를 만든다”라고 적는다.
  2. 읽기 전용 도구만 연결한다. 승인된 리포트 폴더, 분석 API, 정책 문서만 연결한다. 처음부터 메일 발송, 광고 수정, 결제, 삭제 권한을 넣지 않는다.
  3. 판단 경계를 표시한다. 전주 대비 급격한 변화, 숫자 누락, 출처 불일치가 있으면 결론을 내리지 말고 질문으로 중단하게 한다.
  4. 초안과 실행을 분리한다. 에이전트의 성공을 “고객에게 발송했다”로 정의하지 않는다. “사람이 검토할 수 있는 초안을 만들었다”를 첫 성공으로 삼는다.
  5. 결과와 trace를 함께 평가한다. 문장이 자연스러운지만 보지 않는다. 올바른 파일을 읽었는지, 도구를 과하게 호출하지 않았는지, 근거를 남겼는지, 실패를 숨기지 않았는지를 확인한다.

에이전트에 줄 지시는 길 필요가 없다. 대신 성공 조건과 금지 행동이 빠지면 안 된다.

지난 7일 캠페인 리포트를 읽고 검토용 요약을 작성하라.
- 승인된 리포트 폴더의 파일만 사용한다.
- 변화, 데이터 누락, 확인 필요 항목을 구분한다.
- 광고 수정이나 외부 발송은 하지 않는다.
- 근거로 사용한 파일명과 행을 표시한다.
- 조건을 충족하지 못하면 추측하지 말고 질문으로 중단한다.

이것은 프롬프트 요령이 아니다. 업무를 읽기 → 해석하기 → 초안 만들기 → 승인받기 → 실행하기로 분해하는 운영 설계다. 모델이 잘하는 앞의 세 단계와, 실수 비용이 큰 뒤의 두 단계를 분리하면 도입 효과를 측정할 수 있다.

스크립트는 버리는 대신 에이전트의 울타리로 쓴다

에이전트 시대라고 기존 스크립트를 전부 없앨 이유는 없다. 날짜 계산, 합계 검증, 파일 형식 확인, 허용된 폴더 판별처럼 정답이 분명한 작업은 결정론적 코드가 더 빠르고 예측 가능하다. 에이전트는 문서의 위치가 달라지거나 표현이 달라져도 맥락을 찾아야 하는 구간에 투입한다.

업무권장 조합자동화 경계
수집·합계·형식 검증스크립트결과를 재현 가능하게 고정
문서 검색·요약·분류에이전트 + file search근거 파일과 불확실성을 표시
API가 있는 반복 조회스크립트 + 에이전트 해석수집과 의미 부여를 분리
메일·광고·문서 발송에이전트 초안 + 사람 승인승인 전에는 외부 상태를 바꾸지 않음
API 없는 화면 조작computer use + 강한 승인저위험 작업부터, 고위험 작업은 수동 확인

이 조합은 화려하지 않다. 그래서 오래 간다. 모델이 바뀌거나 Agent Builder가 사라져도, 어떤 데이터를 읽고 어떤 계산은 코드로 고정하며 어디에서 사람에게 멈출지는 남는다. 제품 이름보다 중요한 것은 업무의 입력·출력·권한·검증 기준을 분리해 적어두는 습관이다.

결론: 자동화의 다음 단계는 더 많은 봇이 아니라 더 나은 경계다

OpenAI의 새 도구와 AgentKit이 보여준 방향은 분명하다. AI는 글을 써주는 화면에서 데이터를 찾고, 도구를 호출하고, 여러 단계의 업무를 이어가는 실행 계층으로 이동하고 있다. 그러나 그 방향을 특정 builder의 성공담으로만 이해하면 제품이 바뀌는 순간 전략도 함께 사라진다.

내 결론은 단순하다. 오늘 에이전트를 도입하되, 오늘부터 에이전트에게 권한을 주지는 말자. 반복 수집은 스크립트로 고정하고, 검색·해석·초안 작성은 읽기 전용 에이전트로 묶고, 외부 상태를 바꾸는 순간에는 사람의 승인을 둔다. 이 작은 루프가 실제로 줄인 이동과 남긴 오류를 측정한 뒤에만 권한을 한 단계 넓힌다.

CTA: 지금 반복 업무 하나를 골라 세 줄로 적어보자. ① 에이전트가 읽을 source, ② 절대 하지 않을 행동, ③ 사람이 승인할 지점. 먼저 “리포트를 읽어 검토용 요약 만들기”를 Agents SDK나 현재 쓰는 agent runtime으로 구현하고, 첫 실행의 trace와 결과를 함께 확인하라. 한 번에 모든 일을 맡기는 것보다, 안전하게 맡길 수 있는 경계를 직접 발견하는 편이 더 빠른 자동화다.

근거 출처

외부 정보 (하베스터 수집)

상호작용 (에이전트-드루 대화·작업)

이번 글에는 에이전트-드루 대화나 실제 OpenAI 도구 실행에서 얻은 성과 수치·사례를 사용하지 않았다. 워크플로 예시와 도입 순서는 외부 자료를 바탕으로 재구성한 분석과 제안이며, 개인 실행 경험이나 외부 통계로 포장하지 않았다.

외부 정보와 상호작용 경험을 구분해 작성한 AI & TOOLS 분석 글입니다.