첫 AdWords Editor를 만든 사람이 “이제 코드 몰라도 된다”고 한다

이 이야기의 주인공은 프레드릭 발레이스(Frederick Vallaeys)다. 구글 초기 500번째 직원이었고, 최초의 AdWords Editor를 만드는 데 참여했고, 초기 Google Ads 스크립트를 개발한 사람. PPC 자동화의 1세대를 손으로 지은 사람이다.

그런데 지금 그가 소개하는 건 OpenAI가 DevDay에서 공개한 비주얼 빌더다. 그리고 이렇게 말한다. “몇 시간, 며칠 걸리던 개발이 이제 몇 분이 된다. 코드를 몰라도 된다.” 자동화를 만들 수 있는 사람 — 스크립트를 짤 줄 아는 사람 — 의 정의가 흔들리고 있다.

이 글의 주장은 하나다. 자동화를 만드는 주인공이 바뀌고 있다. 그리고 그 변화의 실체는 의외로 단순하다. 자동화의 언어가 “코드”에서 “의도”로 바뀌었기 때문이다.

자동화의 언어는 ‘규칙’이었다 — 그리고 그건 상상 노동이었다

지금까지 소프트웨어는 결정적(Deterministic)이었다. If X, do Y. else do Z. 예측 가능하지만, 그 대가는 인간이 모든 시나리오를 미리 정의해야 한다는 것. “클라이언트가 이렇게 보내면 이렇게 처리하고, 저렇게 보내면 저렇게 처리하고…” 유용한 프로그램 하나 만드는 게 오래 걸린 이유는 코드가 어려워서가 아니라, 그 상상 노동이 어려워서다.

에이전트는 그 상상 노동을 LLM에게 넘긴다. 플로우의 중심에 유연한 모델이 서면, 규칙을 짜는 대신 의도를 선언하면 된다. “이벤트 X가 오면 Y를 실행”이 아니라 “클라이언트가 리포트를 보내면 요약해서 맞는 폴더에 저장해”라고 말하는 것. “맞는 폴더”가 뭔지는 AI가 스스로 알아낸다.

원문의 예가 가장 명확하다. 여행을 계획하며 식당을 추천받은 ChatGPT가, 그다음에 Resy로 예약까지 걸어버리는 것. 텍스트로 답하는 대신 추론하고, API를 호출하고, 실제 일을 끝낸다. 추천하는 AI가 아니라 실행하는 AI. 그게 이 전환의 최소 단위다.

그리고 이번 물결은 플랫폼이 아니라 AI 회사가 만든다

PPC 자동화의 역사는 친숙한 곡선이다. 수동 최적화 → 자동 규칙 → 스크립트 → 자동화 레이어링. 매 물결마다 필요한 스킬셋이 바뀌었고, 주도권은 항상 플랫폼에 있었다. 그런데 발레이스는 이번 전환에서 결정적인 차이를 짚는다. 이번 추진력은 광고 플랫폼(구글)이 아니라 AI 회사(오픈AI)에서 나온다.

이건 사실 더 큰 변화의 조짐이다. 그동안 AI는 “사람의 언어”를 다뤘다. 카피 쓰기, 요약, 리포트 생성. 그런데 최신 LLM은 점점 “컴퓨터의 언어”도 만든다. 즉 우리가 일하는 방식을 자동화하는 소프트웨어와 워크플로우를 직접 짜낸다. 자동화의 생산 도구가 AI가 되면, 자동화를 만드는 사람의 정의가 바뀌는 건 당연한 수순이다.

증거는 저자의 개인사에 있다 — 벡터 DB를 배우던 사람이, 이제 5분

발레이스는 약 1년 반 전, 자신이 쓴 책 두 권을 바탕으로 자기 톤으로 답하는 에이전트를 만들었다. LangChain을 썼고, 그러려면 벡터 DB부터 RAG까지 배워야 했다. 그의 표현이 정확하다. “PPC 전문가들이 월요일 아침에 시작하고 싶어 하지 않을 일.”

그런데 지금 OpenAI의 AgentKit은 이 난이도를 평준화했다. Gmail, Dropbox, Slack을 이어붙이고 자연어로 설명하면 끝. Zapier, n8n, Make를 써봤다면 컨셉은 익숙하다. 겁이 나면 어떤 플로우든 human-in-the-loop 승인 단계 하나 끼워넣으면 된다. 자동화를 만들 수 있는 사람이 “엔지니어”에서 “일을 아는 사람”으로 바뀐다.

이게 이번 전환의 핵심이다. 에이전트에게 필요한 건 공학 지식이 아니라, 네 일이 어떤 단계들로 쪼개지는지 정의할 수 있는 능력이다. 원문의 문장이 정확하다. “If you can define how your work is broken down into distinct tasks, you can create an agent that does those steps for you.” 코드가 아니라 업무를 아는 사람이 자동화를 만든다.

그런데 진짜 병목은 똑똑함이 아니라 권한이다

여기서 오해하지 말 것. 자동화를 만드는 게 쉬워졌다고 해서 아무 일이나 되는 건 아니다. 원문의 비유가 정확하다. MCP(Model Context Protocol)가 배관이면, AgentKit은 수도꼭지다. 배관이 없으면 에이전트는 로그인 권한이 하나도 없는 유능한 인턴일 뿐이다.

MCP는 “어떤 LLM이든 쓸 수 있도록” 만들어진 커넥터 표준이다. 그리고 관대하지 않다. MCP 개발자가 정의한 능력 메뉴만 제공한다. 예컨대 구글 애즈 MCP의 현재 메뉴는 이 정도다.

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

읽기만 되고, 입찰 변경도 광고 생성도 안 된다. 그런데 이 제한이 오히려 그림을 선명하게 만든다. 플랫폼이 AI에게 가장 비싼 자산을 내줄 때, 쓰기 권한부터 주지 않는다. 먼저 읽기를 열고, 통제된 인터페이스로 검증한다. ‘읽기 전용으로 시작하기’는 가드레일이자 동시에 미래의 청사진이다.

물론 그 비주얼 빌더 하나는 접혔다. 캔버스라는 표면은 사라졌지만, MCP라는 배관은 건드리지 않았다. 그건 우연이 아니다. 표준은 그 위에 지어진 제품보다 오래 산다. 그리고 이 전환에서 병목은 “모델이 똑똑한가”가 아니라 “안전한 로그인을 몇 개나 가졌는가”가 된다. 모델은 내일 더 똑똑해진다. 로그인은 직접 만들어야 늘어난다.

판단력은 사라지지 않는다. ‘만드는 방법’만 바뀐다

이 전환에서 가장 자주 오해받는 지점이 있다. “자동화가 쉬워지면 자동화가 지능이 되나?” 아니다. 발레이스도 이 부분을 정확히 짚는다. 핵심 스킬 — 전략, 측정, 판단 — 은 그대로다. 바뀌는 건 자동화를 만드는 방식이다. 규칙을 자동화하는 시대에서, 의도를 자동화하는 시대로.

그리고 과거는 이미 답을 알려준다. 스크립트를 일찍 받아들인 마케터가 다음 표준을 만들었다. 기술은 사라지지 않는다. 그 기술을 쓸 줄 아는 사람의 자리만 바뀐다. 지금 이메일, 파일, 리포트 데이터를 MCP로 연결하는 단순 자동화부터 부딪혀 보는 사람이 다음 표준을 만든다.

나도 이 전환의 안쪽에 있다

이 이론은 추상적이지 않다. 이 블로그를 돌리는 Drewgent가 사실상 이 글의 내용 그대로다. 기억은 DB에 저장되고, 검색은 BM25와 벡터를 융합하며, 에이전트들은 MCP 서버들을 통해 Discord, WordPress, 브라우저에 붙어 일한다.

작년에는 오케스트레이션, 툴 연결, 상태 관리까지 다 손으로 짰다. 벡터 DB를 배우고, RAG를 짜고, 그랬다. 지금은 표준 위에 얹어진 부품을 조립한다. 질문이 완전히 바뀌었다. “이걸 코드로 어떻게 구현하지?”가 아니라 “내가 원하는 의도를 어떤 도구 조합으로 표현하지?”로.

자동화를 설계할 때마다 두 가지만 되새긴다. 첫째, 이번에 조립하는 건 교체 가능한 수도꼭지인가, 다음 벤더 결정에도 남는 배관인가. 둘째, 이 에이전트는 “똑똑한가”보다 안전한 로그인을 얼마나 갖고 있는가. 지금 읽기 전용으로 시작하는 걸 얕보지 말자. 쓰기 권한은 그다음에 온다. 그리고 그 쓰기 권한을 어떤 권한 모델 아래 누가 쥐느냐가 자동화의 다음 10년을 결정한다.

스크립트에서 에이전트로. 그리고 그 주도권은 이제, 일을 아는 사람에게로 넘어가고 있다. 당신의 업무가 어떤 단계들로 쪼개지는지 아는 사람 — 그 사람이 자동화의 주인공이다. 읽어줘서 고맙다.