AI 에이전트의 실력은 모델이 아니라 ‘로그인’이 결정한다
유능한 인턴인데, 로그인이 하나도 없다면?
PPC 자동화의 1세대를 직접 만든 사람의 글에서 가장 오래 남은 문장은 제목과 달랐다. 최초의 AdWords Editor를 만드는 데 참여하고 초기 Google Ads 스크립트를 개발했던 프레드릭 발레이스(Optmyzr CEO)는 에이전트를 이렇게 정의한다. “MCP가 없으면 에이전트는 로그인이 하나도 없는 유능한 인턴일 뿐이다.”
사람들은 “AI가 스크립트를 대체한다”는 제목에 꽂히지만, 진짜 변화는 다른 데서 온다. AI가 얼마나 똑똑해지느냐보다, AI에게 안전한 로그인을 몇 개나 건네주느냐가 자동화의 실력을 결정하는 시대가 왔다. 이 글은 그 ‘권한(access)’의 이동을 읽어보려는 글이다.
자동화의 물결, 이번엔 주도권이 바뀌었다
PPC 자동화의 역사는 친숙한 곡선이다. 수동 최적화 → 자동 규칙 → 스크립트 → 자동화 레이어링. 매 물결마다 필요한 스킬셋이 바뀌었고, 주도권은 항상 플랫폼에 있었다. 그런데 발레이스는 이번 전환에서 결정적인 차이를 짚는다. 이번 추진력은 광고 플랫폼(구글)이 아니라 AI 회사(오픈AI)에서 나온다고.
그동안 AI는 “사람의 언어”를 다뤘다. 카피 쓰기, 요약, 리포트 생성. 그런데 최신 LLM은 점점 “컴퓨터의 언어”도 만든다. 즉 우리가 일하는 방식 자체를 자동화하는 소프트웨어와 워크플로우를 직접 짜낸다는 뜻이다. 스크립트를 짜는 일이 AI의 몫이 되면, 자동화의 주인공은 플랫폼이 아니라 도구를 조합하는 사람이 된다.
소프트웨어는 ‘모든 경우의 수’를 미리 아는 척했다
지금까지 소프트웨어는 결정적(Deterministic)이었다. If X, do Y. else do Z. 예측 가능하지만, 그 대가로 인간이 모든 시나리오를 미리 정의해야 했다. “클라이언트가 이렇게 보내면 이렇게 처리하고, 저렇게 보내면 저렇게 처리하고…” — 유용한 프로그램 하나 만드는 게 오래 걸린 이유가 바로 그 상상 노동이다.
에이전트는 그 상상 노동을 LLM에게 넘긴다. 원문의 예가 가장 명확하다. 여행을 계획하며 식당을 추천받은 ChatGPT가, 그다음에 Resy로 예약까지 걸어버리는 것. 텍스트로 답하는 대신 추론하고, API를 호출하고, 실제 일을 끝낸다. GPT Actions와 function calling이 “통제된 외부 접근”을 줬다면, 에이전트는 추론과 실행을 같은 흐름에 결합한 다음 단계다.
PPC 용어로 옮기면 이렇게 된다. 에이전트는 캠페인 데이터를 끌어오고, 결과를 요약하고, 브랜드·정책 문서를 참조해 컴플라이언스를 지킨 크리에이티브까지 생성한다. 전통적인 “AI 라이팅 어시스턴트”는 말을 대신하고, 에이전트는 일을 대신한다. 레벨이 다르다.
1년 반 전엔 벡터 DB까지 배워야 했다. 이제는 문장 하나
발레이스의 개인사가 이 전환의 체감 온도를 정확히 보여준다. 1년 반 전, 그는 자신이 쓴 책 두 권을 바탕으로 자기 톤으로 답하는 에이전트를 만들었다. LangChain을 썼고, 그러려면 벡터 DB부터 RAG까지 배워야 했다. 그의 표현이 정확하다. “PPC 전문가들이 월요일 아침에 시작하고 싶어 하지 않을 일.”
오픈AI의 AgentKit은 그 난이도를 평준화했다. Gmail, Dropbox, Slack을 드래그앤드롭으로 이어붙이고, 에이전트가 뭘 해야 하는지 자연어로 쓰면 된다. Zapier, n8n, Make를 써봤다면 컨셉은 익숙하다. 다만 결정적 차이가 하나 있다. 플로우의 중심에 유연한 AI 모델이 서 있다는 것.
그래서 지시를 “규칙”으로 내지 않아도 된다. “이벤트 X가 오면 Y를 실행”이 아니라 “클라이언트가 리포트를 보내면 요약해서 맞는 폴더에 저장해”라고 말하면, AI가 “맞는 폴더”가 뭔지 스스로 알아낸다. 규칙을 짜는 대신 의도를 선언하는 것. 겁이 나면 어떤 플로우든 human-in-the-loop 승인 단계 하나 끼워 넣으면 된다. 며칠 걸리던 일이, 코드 없이, 몇 분이 된다.
그런데 진짜 승부처는 ‘로그인’이다
이 이야기의 핵심은 AgentKit의 캔버스가 아니다. 원문의 비유가 정확하다. MCP(Model Context Protocol)가 배관이고, AgentKit은 수도꼭지다. 배관이 없으면 에이전트는 로그인 권한이 하나도 없는 유능한 인턴일 뿐이다. 배관이 있으면 명확한 권한 아래 데이터와 도구를 안전하게 쓴다.
MCP는 API처럼, “어떤 LLM이든 쓸 수 있도록 만들어진” 커넥터 표준이다. 오픈AI가 만든 Gmail·Dropbox 커넥터도 있고, Box 같은 서드파티 것도 있고, 직접 만들어 내부 시스템에 붙일 수도 있다. 그리고 MCP는 관대하지 않다. MCP 개발자가 정의한 능력 메뉴만 제공한다. 예컨대 현재 구글 애즈 MCP의 메뉴는 이 정도다.
- 엔티티 검색 (Search for entities)
- 연결된 고객 목록 (List connected customers)
읽기만 되고, 입찰 변경도 광고 생성도 안 된다. 그런데 이 제한이 오히려 그림을 선명하게 만든다. 플랫폼이 AI에게 가장 비싼 자산을 내줄 때, 쓰기 권한부터 주지 않는다. 먼저 읽기를 열고, 통제된 인터페이스로 검증한다. ‘읽기 전용으로 시작하기’는 가드레일이자 동시에 미래의 청사진이다.
수도꼭지는 접혀도 배관은 남는다
여기에 지난 몇 달간 있었던 일을 대입해 보자. “AI의 Zapier”라 불렸던 그 비주얼 빌더가 접혔다. 표면적으로는 “에이전트 도구가 실패했다”처럼 보일 수 있는 사건이었다. 그런데 폐지의 중심에는 캔버스라는 독점 표면이 있었고, MCP와 커넥터 레지스트리는 건드리지 않았다. 캔버스는 벤더 소유의 표면이고, MCP는 어느 LLM이든 쓸 수 있는 표준이다. 표준은 그 위에 지어진 제품보다 오래 산다.
그래서 이 전환은 오히려 개인·소규모 팀에게 유리하다. 진입 장벽이 낮은 독점 캔버스는 사라졌지만, 그 자리에 온 것은 오픈소스 SDK와 오픈 표준 MCP다. 어느 벤더의 캔버스에 묶이지 않으면서, 배관을 직접 손에 쥘 수 있게 됐다.
판단력은 사라지지 않는다. ‘만드는 방법’만 바뀐다
오해하지 말 것. 전환이 온다고 해서 판단력과 전략은 사라지지 않는다. 발레이스도 이 부분을 정확히 짚는다. 핵심 스킬 — 전략, 측정, 판단 — 은 그대로다. 바뀌는 건 자동화를 만드는 방식이다. 스크립트로 규칙을 짜는 대신 자연어로 의도를 선언하고, AI가 로직을 만들어낸다. 더 빠르고, 더 유연하고, 훨씬 더 접근 가능해진다.
그리고 과거는 이미 답을 알려준다. 스크립트를 일찍 받아들인 마케터가 다음 표준을 만들었다. 이번에도 같다. 지금 작게 시작하는 사람 — 이메일, 파일, 리포트 데이터를 MCP로 연결하는 단순 자동화부터 부딪혀 보는 사람 — 이 다음 표준을 만든다.
이 이론은 이제 제 실무에서 검증되고 있다. 이 블로그를 돌리는 Drewgent는 사실상 이 글의 내용 그대로다. 기억은 DB에 저장되고, 검색은 BM25와 벡터를 융합하며, 에이전트들은 MCP 서버들을 통해 Discord, WordPress, 브라우저에 붙어 일한다. 작년에는 오케스트레이션, 툴 연결, 상태 관리까지 다 손으로 짰다. 지금은 표준 위에 얹어진 부품을 조립한다. 질문이 완전히 바뀌었다. “이걸 코드로 어떻게 구현하지?”가 아니라 “내가 원하는 의도를 어떤 도구 조합으로 표현하지?”로.
결국 남는 질문은 이것이다
자동화를 설계할 때마다 두 가지만 되새겨보면 좋겠다. 첫째, 이번에 내가 조립하는 건 교체 가능한 수도꼭지인가, 아니면 다음 벤더 결정에도 남는 배관인가. 후자로 답이 나오는 순간, 도구가 접히는 소식을 봐도 무섭지 않다.
둘째, 이 에이전트는 “똑똑한가”보다 안전한 로그인을 얼마나 갖고 있는가. 모델은 내일 더 똑똑해진다. 로그인은 직접 만들어야 늘어난다. 지금 읽기 전용으로 시작하는 걸 얕보지 말자. 쓰기 권한은 그다음에 온다. 그리고 그 쓰기 권한을 어떤 권한 모델 아래 누가 쥐느냐가 자동화의 다음 10년을 결정한다.
스크립트에서 에이전트로. 규칙을 자동화하는 시대에서 의도를 자동화하는 시대로. 그리고 그 주도권은 이제, 배관을 직접 손에 쥔 사람에게로 넘어가고 있다. 당신이 자동화에 건네는 첫 로그인은 무엇인가요?