자동화의 역사는 ‘도구’의 역사가 아니라 ‘문법’의 역사다. 그리고 지금 그 문법이 또 한 번 바뀌고 있다. 코드로 쓰던 것들이 설명으로, 조건문으로 짜던 것들이 의도로. OpenAI가 DevDay에서 꺼낸 AgentKit과 그 뒤에 숨은 MCP는 이 전환을 정확히 보여주는 한 장면이다.

이 글은 광고 자동화의 현장에서 온 이야기지만, 결국 모든 자동화를 짜는 사람들의 이야기다. 스크립트를 짜본 적 있는 사람이라면, 또는 “자동화는 나랑 상관없다”고 생각하는 사람이라면 끝까지 읽어볼 만하다. 전환의 본질은 결국 한 가지다.

‘if X, do Y’의 종말 — 결정적 소프트웨어가 사라진다

소프트웨어는 오랫동안 결정적(deterministic)이었다. X면 Y, 아니면 Z. 예측 가능하지만, 그만큼 뻣뻣하다. 그리고 무엇보다 인간이 모든 시나리오를 미리 정의해야 한다는 게 문제였다.

자동화를 짜봤다면 누구나 겪는 일이 있다. “이런 경우도 예외로 처리해야 하나?”, “클라이언트가 빈 CSV를 보내면?”, “폴더명에 한글이 섞이면?” — 좋은 프로그램을 만드는 데 시간이 오래 걸리는 이유는 로직이 어려워서가 아니라 일어날 수 있는 일의 경우의 수가 너무 많아서다.

그런데 LLM은 질문에 유연하게 답하듯, 다음 행동도 유연하게 추론한다. 텍스트로 답하는 대신 단계를 세우고, API를 호출하고, 실제 작업을 수행한다. Optmyzr의 공동창업자이자 초기 AdWords Editor 개발에 참여했던 Frederick Vallaeys는 최근 Search Engine Land 기사에서 이 전환을 이렇게 진단했다. 이번에는 추진력이 애드 플랫폼이 아니라 AI 회사에서 나온다고.

에이전트를 한 문장으로 정의하면 이렇다. 의도를 이해하고 실제 행동을 취하는 도우미. 여행을 계획하면서 ChatGPT에 식당을 물어보면, 추천만 하는 게 아니라 Resy 같은 앱으로 예약까지 걸어버린다. 그게 에이전트다. GPT Actions와 function calling이 “통제된 접근”을 줬다면, 에이전트는 이유추론과 실행을 같은 흐름에 결합한 다음 단계다.

코딩 프로젝트가 5분짜리 빌드로 — AgentKit, ‘AI의 Zapier’

1년 반 전, Vallaeys는 직접 쓴 두 권의 책을 기반으로 “내 어조로 답하는 에이전트”를 만들었다. LangChain을 쓰긴 했지만, 벡터 DB와 RAG를 배우는 데 꽤 많은 시간이 걸렸다고 한다. 월요일 아침에 대부분의 마케터가 하고 싶은 일은 아니었다.

그런데 OpenAI DevDay에서 나온 AgentKit은 그 진입 장벽을 대폭 낮췄다. Gmail, Dropbox, Slack을 이어붙이고, 하고 싶은 일을 설명하면 되는 비주얼 빌더다. Zapier, n8n, Make를 써봤다면 익숙한 화면. 다만 핵심에는 유연한 AI 모델이 있어서 결정적인 규칙 대신 추론을 쓴다.

구체적인 차이는 이렇게 드러난다. 기존 자동화라면 “X가 발생하면 Y를 수행”이라고 써야 한다. AgentKit에서는 이렇게 말한다. “클라이언트가 캠페인 리포트를 보내면 요약해서 맞는 폴더에 저장해.” 그러면 AI가 “맞는 폴더”가 뭔지 맥락을 보고 이해해서 처리한다. 무섭다면 어느 플로우든 human-in-the-loop 승인 단계 하나 끼워넣으면 된다.

진짜 주인공은 MCP다 — 배관이 수도꼭지를 만든다

그런데 이 이야기의 진짜 주인공은 다른 데 있다. 원문의 비유가 정확하다. MCP가 배관이면, AgentKit은 수도꼭지다. 배관이 어떤 데이터가 어디로 흐를지 정하고, 수도꼭지는 그것을 실사용 가능하게 꺼내는 장치다.

MCP(Model Context Protocol)는 에이전트가 도구·데이터와 구조적으로 대화하게 해주는 커넥터 표준이다. API가 웹의 커넥터라면, MCP는 “어떤 LLM이든 쓸 수 있도록 만들어진” 그 표준이다. OpenAI가 만든 Dropbox·Gmail 커넥터도 있고, Box 같은 서드파티 것도 있고, 직접 만들어 내부 시스템에 붙일 수도 있다.

배관이 없으면 에이전트는 로그인 권한이 하나도 없는 유능한 인턴일 뿐이다. 배관이 있으면, 명확한 권한 아래 데이터와 도구를 안전하게 쓴다. 이 한 문장이 에이전트 자동화의 성패를 사실상 결정한다.

구글 애즈 MCP는 아직 ‘읽기 전용’이다 — 그게 설계의 핵심

여기서 오해하면 안 되는 게 있다. MCP는 LLM에게 시스템 전체를 열어주는 문이 아니다. MCP 개발자가 정의한 능력 메뉴를 주는 것이다. 예컨대 구글 애즈 MCP의 현재 메뉴는 이 정도다.

  • 엔티티 검색 (Search for entities)
  • 연결된 고객 목록 (List connected customers)

읽기만 되고, 입찰 변경도 광고 생성도 안 된다. 이 제한은 설계의 핵심이다. 에이전트가 시스템에 접근할 수 있게 하는 것과, 통제되지 않은 상태로 마음대로 두는 것은 전혀 다른 문제다. 권한 경계를 누가, 어떻게 정의하느냐가 에이전트 자동화에서 가장 중요한 설계 결정이 된다.

실용 예시도 원문에 있다. Dropbox에 브랜드 가이드라인을 두고, 벡터 스토어에 톤·정책 문서를 넣은 ‘브랜드 세이프 광고 어시스턴트’. “가을 캠페인 RSA 헤드라인을 우리 스타일과 디스클레이머로 써줘”라고 하면 파일을 읽고 규칙을 뽑아내 컴플라이언트 카피를 만든다. 최종 승인은 사람 몫이지만, 준비 작업은 자동화된다. 메일 MCP를 붙이면 에이전트가 클라이언트에게 승인 요청을 직접 보내기까지 한다.

전환의 본질: 필요한 스킬이 ‘코딩’에서 ‘일 쪼개기’로 바뀐다

PPC 자동화를 오래 해온 사람에게는 익숙한 곡선이다. 수동 최적화 → 자동 규칙 → 스크립트 → 자동화 레이어링. 매번 물결이 바뀔 때마다 필요한 스킬셋도 바뀌었다. 그리고 지금, 에이전트가 다음 물결이다.

이번 전환의 재미있는 점은, 기술 장벽이 아니라 사고 방식이 달라진다는 것이다. 스크립트 시대에는 “코드를 쓸 줄 아는가”가 문턱이었다. 에이전트 시대에는 “자신의 일을 명확한 작업 단위로 쪼갤 수 있는가”가 문턱이 된다. 코딩 실력은 이제 그리 중요하지 않다. 스크립트를 짜거나 API로 워크플로우를 조립하는 대신, 자연어로 로직을 설명하면 AI가 그 로직을 만들어낸다.

즉, 일을 정의하는 능력이 곧 자동화 능력이 된다. “어떤 작업을, 어떤 순서로, 어떤 권한 아래 처리할 것인가”를 명확히 말할 수 있는 사람이라면, 개발자가 아니어도 오늘 당장 에이전트를 만들 수 있다. 이것은 마케터뿐 아니라 모든 지식 노동자의 이야기다.

물론 바뀌지 않는 것도 있다. 전략, 측정, 판단. 에이전트가 일의 속도를 높이고 유연성을 키워주지만, 방향을 정하고 결과를 평가하고 최종 승인을 내리는 건 여전히 사람 몫이다. 자동화는 판단을 대체하지 않고, 판단의 대상이 되는 시간을 늘려준다.

그래서 지금, 작게 시작하라

결론은 의외로 담백하다. 지금 당장 거창한 에이전트를 설계할 필요가 없다. 내 이메일, 파일, 리포트 데이터를 MCP로 연결하는 단순 자동화부터 해보는 것. 지금 에이전트가 뭘 할 수 있고 뭘 못 하는지 직접 부딪혀 보는 것. MCP 설정이 아직 수동적이고, 구글 애즈 커넥터가 읽기 전용인 건 분명하지만, 그 잠재력은 명확하다. AI가 텍스트 생성에서 워크플로우 실행으로 옮겨가고 있다.

과거 스크립트를 일찍 받아들인 마케터가 표준을 만들었듯, 이 전환을 지금 배우는 사람이 다음 표준을 만든다. 코드를 모른다고 뒤에 있어도 된다는 뜻이 아니라, 오히려 반대다. 문법이 코드에서 의도로 바뀌는 순간, 자동화를 짜는 손이 누구에게나 열린다. 결국 이 전환의 승자는 “일을 잘 쪼개고, 그 경계를 잘 정의하는 사람”이다.

당신이 지금 자동화를 설계하고 있다면, 또는 아직 시작조차 못 해봤다면 한 번만 생각해보길. 이번 주에 내가 자동화하고 싶은 일을, 조건문이 아니라 한 문장의 의도로 표현할 수 있는가. 그 질문에 답할 수 있다면, 당신은 이미 이 전환의 반을 지나온 것이다.

참고: 이 글은 Search Engine Land의 “From scripts to agents: OpenAI’s new tools unlock the next phase of automation” (Frederick Vallaeys, 2025)를 기반으로 작성되었다.