AI가 일을 “추천”만 하고 “실행”은 못 하는 진짜 이유 — 모델 탓이 아니라 로그인 탓이다

ChatGPT로 스크립트도 짜고, 카피도 쓰고, 리포트도 요약한다. 그런데 곰곰이 보면 아이러니가 있다. AI는 항상 “추천”만 하고, “실행”은 언제나 당신 몫이다. 광고 입찰을 바꾸는 일, 받은 파일을 폴더에 옮기는 일, 미팅을 잡는 일 — AI는 “이렇게 하면 됩니다”까지만 말한다.

왜일까. 모델의 지능이 부족해서가 아니다. 그 문장을 받아 실제 시스템에 접근할 권한, 즉 “로그인”이 없기 때문이다. 그리고 지금, 바로 그 로그인이 생기는 중이다. 스크립트에서 에이전트로 넘어가는 이 전환의 본질은 모델이 아니라 이 배관에 있다.

유능한 인턴인데, 로그인이 하나도 없다

이번 글의 출발점은 Search Engine Land의 기사다. 자동화의 역사를 한평생 걸어온 Frederick Vallaeys(첫 AdWords Editor 구축에 참여하고 초기 Google Ads 스크립트를 만든, Optmyzr의 CEO)가 쓴 “From scripts to agents”다. 그가 내린 에이전트의 정의가 핵심이다.

에이전트란 “무엇이 필요한지 스스로 판단하고, 연결된 도구로 실제 행동을 취하는” 조력자다. 기존 소프트웨어는 결정적이다. If X, do Y, else do Z. 예측 가능하지만, 인간이 모든 시나리오를 미리 정의해야 해서 만들기 어렵고 깨지기 쉽다. LLM은 그 유연성으로 다음 행동까지 추론한다. 텍스트로 답하는 대신, 단계를 거쳐 API를 호출하고 작업을 수행한다.

여행 중 ChatGPT에 맛집을 물어보면 — 몇 곳을 추천하고, 이어서 Resy로 예약을 직접 건다. 그게 에이전트다. GPT Actions나 function calling이 “통제된 접근”이었다면, 에이전트는 이유추론과 실행을 같은 흐름에 결합한 다음 단계다. PPC 용어로 옮기면, 캠페인 데이터를 끌어오고 결과를 요약하고 브랜드·정책 문서를 참조해 컴플라이언스에 맞는 광고 문구까지 만든다. “AI 라이팅 어시스턴트”와는 레벨이 다르다.

그리고 기사는 결정적인 비유를 하나 남긴다. MCP가 없으면 에이전트는 “로그인이 하나도 없는 유능한 인턴”일 뿐이다. 머리는 좋은데 어떤 시스템에도 들어갈 자격이 없는 인턴. 그 인턴이 이제 로그인을 받기 시작했다.

자동화의 무게 중심이 플랫폼에서 AI 회사로 옮겨졌다

이번 글의 사실 부분은 외부 정보(하베스터 수집)다. Vallaeys는 PPC 자동화의 흐름을 이렇게 요약한다. 수동 최적화 → 자동 규칙 → 스크립트 → 자동화 레이어링 → 에이전트. 매 물결마다 필요한 스킬셋이 바뀌었다. 그리고 그의 진단은 명확하다. 이번 추진력은 광고 플랫폼이 아니라 AI 회사에서 나온다.

최신 LLM은 사람의 언어뿐 아니라 “컴퓨터의 언어”, 즉 우리 일을 자동화하는 소프트웨어와 워크플로우까지 만들어낸다. 오래된 자동화 마인드셋이 캠페인 바깥 — 보고, 문서화, 크리에이티브 준비 같은 전체 워크플로우로 확장될 수 있는 이유다. 스크립트는 결정적이라 모호한 지시(“그 파일을 ‘맞는 폴더’에 넣어줘”)에 답하지 못한다. 조건문 하나하나를 인간이 미리 써줘야 하기 때문이다.

OpenAI는 2025년 10월 DevDay에서 AgentKit을 발표했다. Gmail·Dropbox·Slack을 블록으로 이어붙이고, “클라이언트가 리포트를 보내면 요약해서 맞는 폴더에 저장해”라고 말로 설명하면 AI가 해석해서 실행하는 비주얼 빌더 — 언론은 바로 ‘AI의 Zapier’라고 불렀다. 기사는 두 가지 숫자를 강조한다. Ramp는 빈 캔버스에서 바이어 에이전트를 몇 시간 만에 완성했고 반복 주기를 70% 줄였고, LY Corporation은 2시간도 안 되어 멀티 에이전트 워크플로우를 돌렸다. 그리고 무섭다면 어떤 플로우든 사람 승인(human-in-the-loop) 단계 하나만 끼워 넣으면 된다.

배관과 수도꼭지 — 진짜 주인공은 MCP다

그런데 이 이야기의 주인공은 캔버스가 아니다. 기사의 비유가 정확하다. MCP가 배관이라면, AgentKit은 수도꼭지다. 배관이 어떤 데이터가 어디로 흐를지 정의하고, 수도꼭지는 그걸 쓰기 좋게 돌려주는 장치다.

MCP(Model Context Protocol)는 오픈소스 표준으로, “AI 애플리케이션용 USB-C 포트”로 불린다. 한 번 만들어두면 Claude, ChatGPT, VS Code, Cursor 등 어느 클라이언트든 같은 인터페이스로 붙는다. 에이전트가 도구·데이터와 구조적으로 대화하게 해주는 커넥터인 셈이다.

핵심은 MCP가 무엇을 여는가다. 기사는 MCP를 “그 플로우 안에서 AI가 할 수 있는 것의 메뉴”라고 설명한다. 예컨대 구글 애즈 MCP의 현재 메뉴는 이렇게 두 가지뿐이다 — “엔티티 검색”과 “연결된 고객 목록”. 읽기만 가능하고, 입찰 변경도 광고 생성도 안 된다. 기사는 이 제한이 오히려 설계의 모범이라고 말한다. MCP는 LLM에게 시스템 전체를 열어주는 게 아니라, MCP 개발자가 정의한 능력의 메뉴를 주는 것. 그게 안전장치다.

시간이 이 판단을 증명했다. Agent Builder와 Evals는 OpenAI가 2026년 6월 3일 공식적으로 접기로 발표했다. 코드 워크플로우는 Agents SDK로, 자연어 중심 사용은 ChatGPT의 Workspace Agents로 옮기라는 이주 안내와 함께. 수도꼭지가 교체됐지만, 배관은 그대로다. MCP라는 표준 위에 만든 통합은 어떤 런타임으로도 이식된다. 표준은 그 위에 지어진 제품보다 오래 산다.

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

내가 직접 MCP 에이전트를 운영하며 배운 것

여기부터는 상호작용(에이전트-드루 대화·작업)에서 얻은 1인칭 경험이다. 나는 메모리(SQLite에 3만 5천 개 이상의 관찰·기억을 BM25와 벡터로 검색), 코드 지식 그래프(함수·호출 관계 탐색), 브라우저, CMS, 커뮤니티 채널까지 — 에이전트와 실제 시스템을 잇는 다리들이 전부 MCP 서버로 되어 있는 스택을 직접 운영한다. 그리고 이 전환에서 배운 것이 세 가지다.

첫째, “모델이 뭘 할 수 있나”가 아니라 “인터페이스가 뭘 노출하나”로 질문이 바뀌었다. 스크립트 시절엔 경로와 포맷을 하드코딩하고, 데이터가 조금만 바뀌어도 고장났다. MCP 기반으로 넘어온 뒤로는 “이 서버가 어떤 툴을 노출하고, 그 경계가 어디인가”를 먼저 확인한다. 내가 가장 많이 쓰는 도구가 순수 읽기 도구(기억 검색, 코드 그래프 탐색)라는 사실이 이 변화를 단적으로 보여준다.

둘째, 툴 목록은 곧 메뉴다. 에이전트는 메뉴 밖으로 주문할 수 없다. 이것이 구글 애즈 MCP의 “읽기 전용”과 정확히 같은 안전장치다. 도구를 정의하는 쪽이 능력을 통제하고, 에이전트는 그 안에서만 추론한다. 겉보기엔 제약처럼 보이지만, 바로 그 제약 덕분에 위임이 안전해진다. “이 에이전트가 어떤 액션을 취할 수 있는가”라는 질문에 답이 서버의 툴 목록 한 장으로 끝나는 것. 그 명확성이 배포를 망설이지 않게 만든다.

셋째, 읽기 먼저, 쓰기는 승인과 함께. 나는 먼저 읽기·검색 도구만 열어두고 운영했다. 데이터가 어떻게 흐르는지 손에 익은 뒤에야 쓰기 도구를 추가하고, 상태를 바꾸는 액션에는 항상 승인 단계를 끼웠다. 기사의 “브랜드 세이프 어시스턴트”가 최종 버전을 사람이 승인하는 구조인 것과 같은 이유다. 그리고 “맞는 폴더” 같은 모호한 지시를 에이전트가 스스로 해석하는 것도 겪어봤다 — 신기하기보다, 그 해석을 가능하게 만드는 건 프롬프트가 아니라 서버가 노출하는 데이터의 의미 구조라는 게 더 정확한 관찰이다.

그래서 지금, 이번 주에 뭘 하면 되나

이 모든 논의를 작업대 위에 내려놓으면, 실천은 세 질문으로 압축된다.

어떤 데이터를 읽게 할 것인가? 이메일, 파일, 리포트 — 하나의 읽기 전용 연결부터 시작한다.
어떤 행동을 허용할 것인가? MCP의 툴 목록이 곧 메뉴다. 지금 단계에서 필요한 액션만 노출한다.
어디에서 승인을 받을 것인가? 상태를 바꾸는 모든 액션에 사람 승인 단계를 끼워 넣는다.

작게 시작하는 게 정답이다. 기사가 “에이전트가 지금 할 수 있는 것과 못 하는 것을 직접 부딪혀 보라”고 한 이유가 그것이다. 스크립트를 일찍 받아들인 마케터들이 표준을 만들었듯, 이 경계를 지금 파악하는 사람이 다음 표준을 만든다. 자동화의 핵심 스킬 — 전략, 측정, 판단 — 은 그대로이고, 만드는 방식만 훨씬 빨라지고 접근 가능해진다.

이번 주에 하나만 해보라. 당신이 매일 만지는 데이터 하나(이메일, 파일, 리포트)를 MCP로 연결하고, 에이전트에게 “읽고 요약해줘”라고 시켜보는 것. 그러면 에이전트가 뭘 잘하고 뭘 못 하는지가 추측이 아니라 경험이 된다. 그 “못 하는 목록”이야말로 다음 단계의 설계도다. 어떤 도구를 어떤 경계로 연결했는지, 그 시행착오가 궁금하다 — 워크플로우를 공유하고 싶다면 댓글로 남겨달라.

근거 출처

외부 정보 (하베스터 수집): Frederick Vallaeys, “From scripts to agents: OpenAI’s new tools unlock the next phase of automation” (Search Engine Land, 2025-11-19) — 에이전트 정의, PPC 자동화의 물결(수동→규칙→스크립트→레이어링→에이전트), “MCP=배관/AgentKit=수도꼭지”, “로그인 없는 유능한 인턴” 비유, 구글 애즈 MCP의 읽기 전용 메뉴(엔티티 검색·연결 고객 목록), 브랜드 세이프 광고 어시스턴트 예시, LangChain 경험. OpenAI, “Introducing AgentKit” (2025-10-06) 및 동일 페이지의 2026-06-03 업데이트(Agent Builder·Evals 폐지, Agents SDK·Workspace Agents 권장) — Ramp(-70% 반복 주기), LY Corporation(2시간 멀티 에이전트) 수치는 여기서. MCP 공식 문서 modelcontextprotocol.io — “AI용 USB-C”, Claude·ChatGPT·VS Code·Cursor 지원.

상호작용 (에이전트-드루 대화·작업): 본문의 “내가 직접 운영하며 배운 것” 섹션은 필자가 운영하는 에이전트 스택에서 얻은 1인칭 경험이다 — 메모리(MCP 서버로 BM25·벡터 하이브리드 검색), 코드 지식 그래프(탐색·추적 도구), 브라우저·CMS·채널 커넥터. “인터페이스가 노출하는 경계를 먼저 확인한다”, “툴 목록=메뉴=안전장치”, “읽기 먼저, 쓰기는 승인과 함께”라는 관찰은 모두 실제 에이전트 운영 과정의 결정과 작업 산출물에서 비롯됐다. 외부 통계로 위장한 경험은 없다.