운영안 문서로 구글 애즈 캠페인 자동 생성 시, LLM에 맡길 수 없는 값

엑셀이나 PDF 운영안을 LLM(Large Language Model, 대규모 언어 모델)에 넣으면 구글 애즈 캠페인 자동 생성이 될까요? 됩니다. 문제는 만들어진 캠페인이 의도한 캠페인인지를 무엇으로 확인하느냐입니다. 확인을 LLM에 맡길지, 코드에 맡길지, 사람에게 남길지를 정하는 것이 자동화 도구 설계의 전부입니다.

광고 운영안 파싱부터 Google Ads API(구글 애즈 API) 호출까지 이어지는 파이프라인을 설계하고, 구글 애즈 캠페인 자동 생성 업로더를 구현해 보았습니다. 그 과정에서 확인한 것은 LLM에 맡길 수 없는 값이 세 종류이고, 세 종류의 이유가 전부 다르다는 사실입니다. 어느 층도 LLM 추출 정확도를 올려서는 해결되지 않습니다.

층위	LLM에 맡길 수 없는 이유	대표 값	처리
1층	뽑을 수는 있지만 틀렸을 때 손실이 비대칭	예산 단위, 위치·언어, 집행 기간, 입찰 목표값, 랜딩 URL	사람이 확인
2층	원리적으로 뽑을 수 없음. 정보가 문서가 아니라 계정에 있음	전환 액션(ConversionAction), 결제 프로필, Merchant Center 링크	계정 조회
3층	잘 뽑아도 실행할 수단이 없음	동영상 캠페인 생성, 매니저 계정 생성, 결제 수단 등록	수동 작업 안내

1층과 2층을 구분하지 못하면 개발 리소스가 잘못된 방향으로 투입됩니다. 1층은 프롬프트를 다듬어도 사라지지 않고, 2층은 광고 운영안을 잘 써도 사라지지 않습니다. 세 층으로 나누는 목적은 분류 자체가 아니라 각 층을 누구에게 배정할지 정하는 데 있습니다.

Google Ads 내에 문서 업로드로 캠페인을 만드는 기능은 없습니다

Google Ads(구글 애즈) 안에는 이미 AI가 들어가 있습니다. Performance Max의 자산 자동 생성, 스마트 입찰, Gemini 기반 대화형 캠페인 생성이 해당합니다. 이 글의 대상은 Google Ads 플랫폼 제공 기능이 아니라 광고주 운영안을 LLM으로 파싱해 Google Ads API로 업로드하는 파이프라인입니다. 두 방식은 책임 소재가 다릅니다. 플랫폼 자동화는 구글이 생성한 값을 구글이 검증하지만, 자체 파이프라인은 내 LLM이 뽑은 값을 내가 검증해야 하고 검증하지 않으면 아무도 대신 잡아주지 않습니다.

문서 업로드로 캠페인을 생성하는 기능은 Google Ads에 없습니다. Google Ads 고객센터 "About conversational experience in Google Ads"(https://support.google.com/google-ads/answer/14145186)에 따르면 대화형 캠페인 생성은 랜딩 페이지 URL을 입력받아 비즈니스 설명과 키워드, 헤드라인, 설명, 이미지, 사이트링크를 제안하는 방식입니다. 운영안 문서나 PDF를 업로드해 캠페인을 구성하는 기능은 공식 문서에서 확인되지 않습니다. 운영안 문서에서 출발해야 한다면 파이프라인을 직접 만드는 수밖에 없습니다.

광고 운영안 파싱 파이프라인의 실패는 LLM이 필드를 채우는 주체일 때만 생깁니다. 동일한 실수를 세 경로에서 비교하면 차이가 드러납니다.

실수	관리 화면	Google Ads API 직접 코딩	광고 운영안 파싱 + Google Ads API
위치·언어 미지정	입력란이 비어 있는 것이 화면에 보임	코드에 명시하므로 누락이 드묾	문서에 없으면 조용히 누락
예산 단위 오인	입력한 값이 그대로 표시됨	상수로 고정	표기 해석마다 값이 달라짐
설정 조합 오류	설정 시점에 경고 노출	조합 규칙을 코드로 관리	필드 단위 추출이라 미검출

관리 화면에서 사람이 만들 때는 발생하지 않던 사고가, LLM과 Google Ads API를 조합하는 순간 새로 생깁니다. 자동화 도구를 설계할 때 참고할 선례가 관리 화면 운영 경험에는 없다는 뜻이기도 합니다.

사람이 반드시 확인해야 하는 값 5가지

LLM이 값을 정확히 뽑아왔더라도 그대로 올려서는 안 되는 필드가 다섯 개 있습니다. 앞의 표에서 1층에 해당하는 필드들입니다. 위치·언어, 예산 단위, 집행 기간, 입찰 목표값, 최종 도착 URL입니다. 공통점은 틀렸을 때 손실이 광고비로 직결되는 비대칭 구조라는 것이고, 그래서 추출 신뢰도와 무관하게 확인 절차가 필요합니다.

위치·언어 — 세 조건이 겹쳐야 발생하는 사고

위치와 언어 타겟팅을 지정하지 않아도 Google Ads API는 요청을 거부하지 않습니다. 대신 캠페인이 전 세계 전 언어를 대상으로 게재됩니다. 업로더를 구현하면서 로컬 검증 단계에 이 항목을 넣게 된 이유입니다.

위치·언어 누락 사고는 세 조건이 동시에 성립할 때만 일어납니다. 광고 운영안에 지역이 명시되지 않았고, LLM이 없는 값을 지어내지 않고 건너뛰었고, Google Ads API가 빈 값을 오류로 취급하지 않는 경우입니다. 세 조건 중 하나만 빠져도 발생하지 않기 때문에, 관리 화면 운영 상황이나 API 직접 코딩 상황에서는 발생하지 않는 유형입니다.

관리 화면에서는 입력란이 비어 있는 것이 눈에 보입니다. 코드를 직접 쓸 때는 지역 코드를 상수로 박아둡니다. 광고 운영안 파싱에서만 값이 조용히 사라지고, 오류 메시지 없이 광고비가 소진됩니다. 며칠 뒤 리포트에서야 발견되는 구조입니다.

위치·언어는 Google Ads API가 필수로 요구하지 않더라도 자동화 파이프라인에서 필수 항목으로 승격시켜야 합니다. 대응 방법은 이것 하나입니다.

예산 — 표기 해석을 검증할 방법이 없습니다

Google Ads API의 예산 필드는 micros 단위를 씁니다. 1원이 1,000,000 micros이므로, 일 예산 5,000원은 5,000,000,000이라는 값으로 전달됩니다.

단위 변환 자체는 코드가 처리합니다. 문제는 그 앞 단계입니다. 광고 운영안에는 "일 5만", "50", "5,000천원", "월 150"이 같은 문서 안에 섞여 등장합니다. LLM은 이 중 하나를 골라 숫자로 변환하는데, 어떤 해석을 했는지가 결과 숫자만 봐서는 드러나지 않습니다. 만원 단위를 원 단위로 읽으면 100배 예산이 그대로 올라갑니다.

검증이 불가능한 이유는 정답이 문서 밖에 있기 때문입니다. "50"이 5만 원인지 50만 원인지는 그 광고주의 통상 예산 규모를 아는 사람만 판단할 수 있습니다.

집행 기간, 입찰 목표값, 최종 도착 URL

집행 기간은 생략하면 캠페인이 즉시 시작하고 종료일 없이 게재됩니다. 광고 운영안에서 기간이 본문이 아니라 표 헤더나 파일명에만 적히는 경우가 많아 LLM 추출에서 자주 누락됩니다.

목표 CPA와 목표 ROAS는 계정의 실제 성과 수준과 동떨어지면 캠페인이 생성되고도 노출이 나오지 않습니다. 생성 성공과 게재 성공이 다르다는 점이 드러나는 지점입니다.

최종 도착 URL은 형식 검증은 코드로 되지만, 어느 페이지로 보낼지의 판단은 LLM도 코드도 대신할 수 없습니다.

광고 계정을 조회해야만 알 수 있는 값

LLM이 원리적으로 뽑을 수 없는 값들이 2층에 속합니다. 공통점은 광고 운영안을 아무리 잘 써도 거기에 없다는 것으로, 정보가 문서가 아니라 광고 계정 안에 있기 때문입니다.

전환 액션(ConversionAction) 설정 여부가 대표적입니다. 목표 CPA·목표 ROAS를 포함한 스마트 입찰은 계정에 전환 액션이 설정되어 있어야 정상 작동합니다. 광고 운영안에는 "목표 CPA 15,000원"이라고만 적혀 있고, 그 계정에 전환 추적이 붙어 있는지는 적혀 있지 않습니다.

결제 프로필 등록 상태와 Merchant Center 링크 상태도 같은 성격입니다. 쇼핑 캠페인은 승인된 Merchant Center 계정과의 링크가 선행되어야 하고, 링크 없이는 상품 그룹 구성 자체가 불가능합니다.

개발자 토큰 등급도 여기 속합니다. Google Ads API 문서 "Access Levels and Permissible Use" (https://developers.google.com/google-ads/api/docs/access-levels)에 따르면 테스트 등급은 테스트 계정에만 접근할 수 있고, 실계정 업로드에는 기본(Basic) 등급 이상이 필요하며 심사에 약 5영업일이 걸립니다. 기본 등급의 일일 한도는 15,000 operations이고, 캠페인 하나 생성에 수십에서 수백 operations가 소모됩니다.

자동화 도구는 광고 운영안을 읽기 전에 광고 계정을 먼저 읽어야 합니다. 첫 화면이 문서 업로드가 아니라 계정 준비도 진단이어야 한다는 뜻입니다.

Google Ads API로 생성 자체가 불가능한 항목

3층은 LLM의 능력과 무관합니다. 소재와 타겟팅을 완벽하게 추출해도 Google Ads API가 기능 자체를 제공하지 않아 실행할 수단이 없습니다.

가장 자주 걸리는 항목이 동영상 캠페인입니다. Google Ads API 문서 "Video campaigns" (https://developers.google.com/google-ads/api/docs/video/overview)는 이렇게 적고 있습니다.

"The Google Ads API only supports fetching and reporting on existing Video campaigns and their criteria. You cannot create new Video campaigns or update existing ones using the Google Ads API."

조회와 리포팅만 됩니다. 생성뿐 아니라 일시중지, 타겟팅 변경, 광고그룹 추가 같은 수정도 불가능합니다. 문서는 대안으로 Google Ads 스크립트 또는 Demand Gen 캠페인을 제시합니다.

불가 항목	상태	대응
동영상 캠페인 생성·수정	조회·리포팅만 지원	관리 화면 수동 생성 또는 Demand Gen 대체
결제 프로필·결제 수단 등록	관리 화면 전용	사전 셋업 체크리스트로 안내
매니저(MCC) 계정 생성	관리 화면 전용	수동 생성 후 링크만 API로 처리
확장 텍스트 광고(ETA) 생성	지원 종료	반응형 검색 광고(RSA)로 대체
동영상·앱·쇼핑 캠페인 드래프트	검색·디스플레이만 지원	드래프트 없이 PAUSED 생성

계정 생성은 구분이 필요합니다.

광고주(클라이언트) 계정은 CustomerService.CreateCustomerClient로 API 생성이 가능하고, 관리 화면 전용인 것은 매니저 계정 쪽입니다. 이 둘을 뭉뚱그리면 "계정 생성은 다 수동"이라는 과도한 제약을 스스로 걸게 됩니다.

3층 항목을 감지하면 생성을 시도하는 대신 수동 작업 체크리스트를 자동으로 생성해야 합니다. 자동화 도구에서 실패시키는 것과 안내하는 것은 사용자 경험이 완전히 다릅니다.

API 제한 목록이 버전마다 이동하는 이유

Google Ads API의 제한 사항은 버전마다 바뀝니다. 3층 목록은 한 번 조사해두고 재사용할 수 있는 상수가 아니라는 뜻입니다.

AI Max for Search가 대표 사례입니다. 처음 요건을 매핑하던 시점에 AI Max는 고객센터 안내 기준으로 Google Ads API와 에디터에서 사용할 수 없는 기능이었습니다. 명백한 3층 항목이었습니다. 그런데 지금은 다릅니다. Google Ads API v25 문서는 Campaign.AiMaxSetting을 통한 AI Max 설정 지원을 명시하고 있습니다. 3층에 있던 항목이 아래로 내려온 것입니다.

고객센터의 "API 미지원" 안내는 아직 갱신되지 않은 채 남아 있어, 두 문서가 서로 다른 이야기를 하고 있습니다. 어긋날 때는 API 문서가 기준입니다. 고객센터는 관리 화면 사용자를 위한 문서라 API 지원 여부의 갱신이 늦습니다.

필드 단위 검증으로는 잡히지 않는 제약

AI Max가 지원되면서 새 조건이 하나 생겼습니다. AI Max가 켜진 캠페인에서는 캠페인 수준의 키워드 매치 타입 설정(Campaign.keyword_match_type)이 적용되지 않고, 값을 설정하려 하면 CANNOT_SET_CAMPAIGN_KEYWORD_MATCH_TYPE 오류가 발생합니다.

설정 조합 제약은 광고 운영안 파싱에서 특히 까다롭습니다. 필드는 스키마에 존재하는데 특정 설정 조합에서만 거부되기 때문입니다. 운영안에 "매치타입: 구문검색"이라고 적혀 있으면 LLM은 당연히 그 값을 추출합니다. LLM은 필드 단위로 값을 뽑지 조합의 유효성을 판단하지 않습니다. 필드 존재 여부만 보는 검증도 통과시키고, API 호출 시점에야 거부됩니다.

규칙 엔진에 필드 단위 규칙과 별도로 설정 조합 단위 규칙을 두어야 하고, 각 규칙에 확인 시점을 함께 기록해야 합니다. 확인 시점이 없으면 AI Max처럼 이미 풀린 제약을 계속 막고 있게 됩니다.

결론: 규칙 엔진에 넘기면 안전하다는 말은 절반만 맞습니다

추출은 LLM에, 판정은 규칙 엔진에 맡기라는 원칙 자체는 새롭지 않습니다. 이 글이 더하는 것은 그 원칙이 광고 캠페인 생성에서 다르게 작동한다는 점입니다.

대부분의 LLM 애플리케이션은 결과가 틀리면 다시 생성하면 됩니다. 캠페인 생성은 실행이 곧 지출이라 되돌릴 수 없습니다. 잘못 만들어진 캠페인은 삭제할 수 있어도 이미 소진된 예산은 돌아오지 않습니다. "일단 돌려보고 고친다"가 성립하지 않는 영역이고, 그래서 안전장치를 사후 수정이 아니라 사전 차단으로 설계해야 합니다.

규칙 엔진에도 판정할 수 없는 영역이 있습니다. 헤드라인이 15자를 넘었는지, Performance Max에 Manual CPC를 걸었는지는 코드가 확정적으로 판정합니다. 반면 예산 "50"이 5만 원인지 50만 원인지는 코드도 판정할 수 없습니다. 정답이 문서 밖에 있기 때문입니다.

규칙 엔진이 판정할 수 없는 이 영역이 1층입니다. 규칙 엔진을 아무리 촘촘하게 만들어도 1층은 줄어들지 않습니다. 처음 질문으로 돌아오면, 운영안 문서로 캠페인을 자동 생성하는 것은 가능합니다. 자동화 도구의 완성도는 규칙을 몇 개 넣었느냐가 아니라, 사람에게 남길 것을 얼마나 정확히 골라냈느냐로 결정됩니다.

사전 차단으로 설계한 안전장치 3가지

규칙 엔진이 판정할 수 없는 영역으로 발생하는 문제를 막기 위한 안전장치는 세 가지입니다. 셋 다 사후 수정이 아니라 사전 차단에 해당합니다.

단일 atomic mutate — 예산·캠페인·광고그룹·키워드·광고를 한 번의 호출로 생성합니다. 이걸 고른 이유는 부분 실패가 눈에 띄지 않기 때문입니다. LLM 추출 오류로 광고만 거부되면 예산과 캠페인은 생성된 채 남는데, 관리 화면에서는 정상 캠페인처럼 보입니다. 전체 롤백으로 이 상태 자체를 만들지 않습니다.
기본값 PAUSED 생성 — 사전 차단 원칙의 마지막 관문입니다. 생성과 게재를 분리해두면 앞의 모든 검증을 통과한 오류도 광고비를 쓰기 전에 잡을 기회가 한 번 더 생깁니다.
API 호출 전 로컬 검증 — 반응형 검색 광고(RSA) 헤드라인 3~15개, 설명 2~4개 같은 개수 조건과 문자 수, 매치 타입, 입찰 전략별 필수값, URL 형식을 확인합니다. API 거부는 비용이 들지 않지만, 거부 사유를 해석하고 재시도하는 과정에서 사람의 판단이 개입해 오히려 오류가 끼어듭니다.

1층을 사람에게 넘기는 방법

1층이 사람에게 남는다는 말은 사람이 처음부터 다시 입력한다는 뜻이 아닙니다. 확인해야 할 것만 골라 순서대로 물어보는 구조가 필요합니다.

LLM이 추출한 값 중 불확실한 필드는 값을 채우는 대신 확인 필요 상태로 표시합니다. 규칙 엔진이 누락된 필수 항목을 유형별로 묶어 우선순위대로 질문하고, 사용자가 입력하면 스펙을 갱신해 다시 검증합니다. 통과할 때까지 이 루프를 돕니다. 한 번에 모든 빈칸을 보여주는 폼보다 확인 누락이 적습니다.

모든 추출값에는 원문 근거를 붙입니다. "예산 50,000원 — 운영안 3페이지 표 2행에서 추출"처럼 표시하면 사람은 값을 입력하는 대신 근거를 대조하기만 하면 됩니다. 광고 운영안 파싱 기반 자동화에서 사람의 역할은 값을 입력하는 것이 아니라 추출 근거를 대조하는 것으로 바뀝니다.

검증을 통과한 스펙은 파일로 남깁니다. 이 스펙이 곧 감사 로그이자 재실행 가능한 산출물입니다. 같은 구조를 다른 계정에 다시 올리거나, 나중에 무엇이 어떤 근거로 설정됐는지 추적할 때 이 파일 하나면 됩니다. 캠페인이 만들어진 뒤에 남는 것이 광고 계정의 결과물뿐이면, 왜 그렇게 설정됐는지는 아무도 알 수 없습니다.

자주 묻는 질문

왜 LLM에게 업로드 판정까지 맡기면 안 되나요?

LLM은 동일한 입력에 다른 출력을 낼 수 있고 판정 단계의 오류는 광고비 손실로 직결되기 때문입니다. 추출은 문서 형식이 다양해 규칙 처리가 어렵지만 판정은 조건이 유한해 규칙 처리가 가능합니다. 확률적 처리와 결정적 처리를 구분하는 기준이 여기 있습니다.

구글 애즈 API에서 일 예산 5,000원은 얼마로 입력하나요?

5,000,000,000으로 입력합니다. Google Ads API의 예산 필드는 micros 단위를 사용하며 1원이 1,000,000 micros입니다. 단위 변환은 코드가 처리하지만 운영안의 "50"이 5만 원인지 50만 원인지 판단하는 단계는 코드가 검증할 수 없습니다. 만원 단위를 원 단위로 해석하면 100배 예산이 반영됩니다.

Google Ads API로 동영상 캠페인을 생성할 수 있나요?

생성할 수 없습니다. Google Ads API 개발자 문서 "Video campaigns"(구글, 2026년)는 기존 동영상 캠페인의 조회와 리포팅만 지원한다고 명시합니다. 생성뿐 아니라 수정, 일시중지, 타겟팅 변경, 광고그룹 추가도 같은 범위에 포함됩니다. 해당 문서가 제시하는 대안은 Google Ads 스크립트 또는 Demand Gen 캠페인입니다.

실계정에 캠페인을 업로드하려면 어떤 개발자 토큰 등급이 필요한가요?

기본(Basic) 등급 이상이 필요합니다. 테스트 등급은 테스트 계정에만 접근할 수 있으며 Basic 등급 심사에는 약 5영업일이 소요됩니다. 일일 operation 한도는 Basic이 15,000, Explorer가 2,880이고 캠페인 1개 생성에 수십에서 수백 operations가 소모되므로 대량 세팅 시 한도 관리가 필요합니다.

Google Ads API는 사용료가 있나요?

API 사용 자체는 무료이며 광고비만 과금됩니다. Google Ads API 개발자 문서 "Rate Sheet"(구글, 2026년)에 따르면 Standard 액세스 사용자가 필수 최소 기능 요건(RMF)을 준수하지 않을 경우 비용이 발생할 수 있습니다. 실질적 제약은 비용이 아니라 개발자 토큰 등급과 일일 operation 한도입니다.