20년간 자동화를 설계해온 건 애드 플랫폼이었다. 이번엔 아니다.

Search Engine Land에 이런 글이 하나 떴다. 글쓴이는 Frederick Vallaeys — Optmyzr의 CEO이자, Google에서 10년을 일하며 최초의 AdWords Editor를 만드는 데 참여했고 초기 Google Ads 스크립트를 직접 만들었던 사람이다. 자동화의 역사를 손으로 만져온 인물이라는 뜻이다. 그런 사람의 진단이 이렇게 시작한다.

“이번엔 추진력이 애드 플랫폼이 아니라 AI 회사에서 나온다.”

이 문장이 왜 중요한지, 잠깐 되새겨보자. PPC 자동화의 20년 동안 로드맵은 줄곧 플랫폼이 그려왔다. AdWords Editor, 자동 규칙, Google Ads 스크립트, 자동 입찰, PMax까지. 판을 깔고, 룰을 정의하고, “이렇게 자동화하면 된다”고 알려주는 쪽은 항상 구글이었다. 그런데 지금 자동화를 만드는 도구를 내놓는 쪽은 OpenAI다. 구글이 아니라. 애드 플랫폼이 아니라.

이건 단순한 도구 교체가 아니라, 자동화라는 분야의 힘의 중심이 이동하고 있다는 신호다. 두 달 전에 캔버스(Agent Builder)가 접힌 일까지 떠들썩했지만, 그 사건은 이 글의 테제를 뒤집지 않는다. 오히려 방향만 더 선명해졌다. 이번 전환에서 우리가 배워야 할 건 “어떤 도구를 쓸까”가 아니라, 자동화를 설계하는 방식 자체가 바뀌고 있다는 사실이다.

AI가 ‘사람의 언어’가 아니라 ‘컴퓨터의 언어’를 쓰기 시작했다

그동안 AI는 주로 사람의 언어 작업을 도왔다. 광고 카피 쓰기, 요약, 리포트 생성. 그런데 최신 세대의 LLM은 점점 컴퓨터의 언어도 만들어낸다. 우리가 하는 일을 자동화하는 소프트웨어와 워크플로우를, AI가 직접 짜내기 시작한다는 뜻이다.

그래서 오래된 자동화 마인드셋이 드디어 캠페인 바깥으로 확장될 수 있게 됐다. 캠페인 안의 최적화가 아니라, 보고, 문서화, 크리에이티브 준비 같은 ‘업무 전체’가 대상이 된다. 원문이 제시하는 시나리오를 읽어보면 이미 머릿속에 그림이 그려진다.

  • 클라이언트가 주간 결과 CSV를 보낸다. 내가 메일을 열어보기도 전에, 파일이 맞는 폴더에 저장되고 대시보드에 반영된다.
  • 클라이언트가 미팅을 요청한다. AI가 내 캘린더를 확인하고, 안건 초안을 짜고, 일정을 잡아버린다.
  • 새 광고 카피를 쓰기 시작하면, 시스템이 브랜드 가이드라인을 꺼내 톤과 컴플라이언스를 자동으로 점검한다.

핵심은 이 문장이다. “네 업무를 개별 태스크로 쪼개서 정의할 수 있다면, 그 단계를 수행하는 에이전트를 만들 수 있다.” 공학 학위는 필요 없다.

에이전트는 ‘추천’이 아니라 ‘실행’이다

에이전트가 기존 AI와 다른 지점은 딱 하나다. 텍스트로 답하는 대신, 실제 행동을 한다.

전통적인 소프트웨어는 결정적이다. If X, do Y, else do Z. 예측 가능하지만, 인간이 모든 시나리오를 미리 정의해야 하기 때문에 만드는 게 느리고 어렵다. LLM은 질문에 유연하게 답하듯, 다음 행동도 유연하게 추론한다. 식당 추천을 묻는 ChatGPT가 Resy로 예약을 걸어버리는 것. 그게 에이전트다.

이건 GPT Actions나 function calling의 자연스러운 다음 단계다. 그들이 모델에게 “통제된 외부 접근”을 줬다면, 에이전트는 추리(reasoning)와 실행(execution)을 같은 흐름에 결합한다. 계획을 세우고, 그 자리에서 실행한다.

PPC 용어로 옮기면 이렇다. 에이전트는 캠페인 데이터를 끌어오고, 결과를 요약하고, 브랜드 문서와 정책 문서를 참조해 컴플라이언스에 맞는 크리에이티브까지 생성한다. “AI 라이팅 어시스턴트”라고 부르던 것과는 레벨이 다르다. 말해주는 게 아니라, 해치운다.

1년 반 전엔 코딩 프로젝트였다, 지금은 5분 빌드다

에이전트는 새 개념이 아니다. Vallaeys 자신도 1년 반 전에 이미 만들어봤다. 자기 책 두 권을 기반으로 “내 어조로 답하고 내 생각을 인용하는” 에이전트를. 그런데 그때는 LangChain을 배우고, 벡터 데이터베이스와 RAG를 공부해야 했다. 됐다. 근데 월요일 아침에 하고 싶은 일은 아니었다고 저자는 쓴다. 공감된다.

그 고통이 사라진 게 이번 전환의 실제 체감이다. OpenAI의 AgentKit은 비주얼 빌더다. Gmail, Dropbox, Slack 같은 서비스를 이어붙이고, 에이전트에게 뭘 해줄지 자연어로 설명하면 끝. Zapier, n8n, Make를 써봤다면 익숙한 화면이다.

다만 결정적인 차이가 하나 있다. 그 플로우의 핵심에는 유연한 AI 모델이 들어가 있어서, 룰 대신 추리로 작동한다는 것. “If X happens, do Y”를 정의하는 대신, “클라이언트가 리포트를 보내면 요약해서 맞는 폴더에 저장해”라고 말하면 AI가 “맞는 폴더”가 뭔지 스스로 파악한다. 모호한 지시를 이해하기 위해 필요한 정보를 스스로 요청하면서 말이다.

무섭다면 걱정할 필요 없다. 어떤 플로우든 human-in-the-loop 승인 단계를 하나 끼워넣을 수 있다. 자동화의 최종 결정권은 여전히 사람 손에 있다.

‘AI의 Zapier’ 뒤에 숨어 있는 진짜는 MCP다

그런데 이 이야기의 진짜 주인공은 비주얼 빌더가 아니다. 원문이 “unsung hero”라고 부른 존재 — MCP(Model Context Protocol)다. 에이전트가 도구·데이터와 구조적으로 대화하게 해주는 커넥터 표준이다. API가 웹의 커넥터라면, MCP는 어떤 LLM이든 쓸 수 있도록 만들어진 그 표준이다. OpenAI가 만든 Dropbox·Gmail 커넥터도 있고, Box 같은 서드파티 것도 있고, 내부 시스템에 직접 만들어 붙일 수도 있다.

여기서 내가 특히 좋아하는 대목이 있다. 구글 애즈 MCP가 지금 제공하는 능력은 딱 두 가지다.

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

읽기만 되고, 입찰 변경도 광고 생성도 안 된다. 그리고 이 ‘제한’이 오히려 이번 전환의 본질을 정확히 보여준다. MCP는 LLM에게 시스템 전체를 열어주는 키가 아니다. MCP 개발자가 정의한 ‘능력 메뉴’를 건네는 것이다. 에이전트를 플로우에 통합할 때도, 내가 어떤 액션에 접근을 줄지 내가 통제한다. 이건 중요한 가드레일이다.

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

그래서 이제 필요한 스킬은 ‘경계 설계’다

이 시점에서 우리는 물결이 바뀔 때마다 스킬셋이 바뀌어온 사실을 기억할 필요가 있다. 수동 최적화 → 자동 규칙 → 스크립트 → 자동화 레이어링. 그리고 이제 에이전트. 원문의 지적처럼, 남는 스킬은 전략·측정·판단이고 바뀌는 건 “자동화를 만드는 방식”이다.

스크립트 세대의 스킬은 분기 로직을 빠짐없이 쓰는 것이었다. if-then-else의 모든 갈래를 미리 정의하는 능력. 그런데 에이전트 세대는 로직을 쓰는 대신 이런 걸 하게 된다.

  • 에이전트에게 뭘 시킬지 ‘설명’한다 (업무를 태스크로 쪼개는 능력).
  • 어떤 데이터·도구에 접근을 줄지 ‘경계’를 설계한다 (MCP 권한 설계).
  • 산출물을 검증할 기준을 세운다.
  • 인간 승인(HITL)을 어느 지점에 둘지 결정한다.

즉, 살아남는 스킬은 “If X, do Y를 정확히 쓰는 것”이 아니라 “무엇을 할 수 있게 하고, 무엇을 막을 것인가”를 설계하는 것으로 이동한다. 스크립트를 일찍 받아들인 마케터가 다음 표준을 만들었듯, 이걸 지금 배우는 사람이 그다음 표준을 만들 거라는 원문의 결론에 동의한다. 코드를 쓰는 능력보다, 경계를 설계하는 판단이 더 중요해지는 시대다.

작게, 내 일부터 붙여보기

나는 지금 내 일하는 방식에 에이전트와 MCP를 실제로 붙여 쓰고 있다. 파일, 데이터베이스, 메시지 시스템을 표준 커넥터로 연결한 에이전트가 내 옆에서 일한다. 그 경험에서 배운 건 단 하나다. 에이전트의 성능은 모델이 아니라 ‘연결된 데이터’로 결정된다. 어떤 도구에도 접근할 수 없는 에이전트는 로그인 하나 없는 유능한 인턴일 뿐이다. 반대로 접근 경계가 명확하게 설계된 에이전트는, 조심스럽게 쓰면, 내 시간을 진짜로 되돌려준다.

그래서 권하고 싶은 건 어렵게 생각하지 않는 것이다. 지금 당장 네 이메일, 파일, 리포트 데이터를 MCP로 연결하는 단순 자동화 하나부터 만들어보는 것. 원문의 지적처럼, “에이전트가 뭘 할 수 있고 뭘 못 하는지”는 읽는 것보다 직접 부딪혀 봐야 안다.

자동화의 주도권이 애드 플랫폼에서 AI 회사로 넘어가는 동안, 우리가 할 수 있는 건 그 흐름의 설계자로 참여하는 일이다. 분기를 미리 정의하는 대신 경계를 설계하는 쪽으로. “무엇을 시킬까”보다 “어디까지 맡길까”가 질문이 되는 순간, 당신은 이미 다음 물결 위에 있는 거다.