TL;DR

Git을 “개발자들이 쓰는 저장 도구” 정도로만 알고 있었습니다.

그런데 AI 코딩 에이전트와 같이 일하다 보니, Git은 단순한 저장 도구가 아니었습니다. 특히 commit, push, PR, merge는 각각 전혀 다른 의미를 갖고 있었습니다.

이번에 제가 정리한 핵심은 이렇습니다.

• 커밋은 내 컴퓨터 안에 남기는 의미 있는 작업 기록입니다.
• GitHub 업로드는 커밋을 원격 저장소에 올리는 push입니다.
• PR은 “이 변경을 공식 반영해도 되는지 검토해 주세요”라는 요청입니다.
• merge는 검토된 변경을 공식 흐름에 합치는 일입니다.
• AI 에이전트와 일할수록 작은 단위의 커밋은 더 중요해집니다.

저는 Git을 대충 알고 있었습니다

솔직히 말하면 Git을 완전히 처음 듣는 것은 아니었습니다.

커밋이라는 말도 들어봤고, GitHub도 알고 있었고, PR이나 merge라는 단어도 어디선가 본 적이 있었습니다. 다만 제 머릿속에서는 이것들이 한 덩어리로 뭉쳐 있었습니다.

“코드 고치고 GitHub에 올리는 과정 아닌가?”

비개발자인 제 입장에서는 이 정도 이해만으로도 한동안 큰 문제가 없었습니다. 제가 직접 개발팀의 작업 흐름을 운영하거나, AI 에이전트에게 코드를 고치게 하거나, 여러 변경을 안전하게 나눠야 하는 상황이 자주 없었기 때문입니다.

그런데 AI와 같이 실제 작업을 하다 보니 헷갈림이 바로 비용이 되었습니다.

무엇을 고쳤는지, 어디까지 내 컴퓨터에만 있는지, 무엇이 GitHub에 올라갔는지, 무엇이 실제 서비스에 반영될 수 있는 상태인지 구분하지 못하면 작업을 통제하기 어렵습니다.

커밋은 저장 버튼이 아니라 “작업의 의미”를 남기는 일입니다

제가 가장 먼저 정리한 개념은 커밋입니다.

커밋은 그냥 저장이 아니었습니다. 저장은 파일의 현재 상태를 보존하는 일에 가깝습니다. 커밋은 그보다 한 단계 더 나아가 “이 변경은 어떤 의미를 가진 작업입니다”라고 기록하는 행위입니다.

예를 들어 AI 에이전트가 Hermes의 Discord /status 응답 문제를 고쳤다고 해보겠습니다. 이때 파일 몇 개가 바뀌었다는 사실만 남기면 나중에 다시 추적하기 어렵습니다.

반대로 커밋을 잘 남기면 이렇게 기록할 수 있습니다.

“Discord gateway status command response path fix”

이 기록은 단순한 메모가 아닙니다. 나중에 문제가 생겼을 때 되돌아갈 기준점이 되고, 다른 사람이 변경 의도를 이해하는 설명서가 되고, 내가 AI와 함께 어떤 시행착오를 거쳤는지 남기는 학습 자산이 됩니다.

비개발자 입장에서 커밋을 이해하는 가장 쉬운 비유는 “작업 단위별 영수증”입니다. 무엇을 했는지, 언제 했는지, 왜 했는지를 남기는 증빙입니다.

로컬 커밋과 GitHub 업로드는 다릅니다

두 번째로 중요했던 구분은 로컬과 GitHub입니다.

로컬 커밋은 내 컴퓨터 안에 남는 기록입니다. 아직 GitHub에 올라간 것이 아닙니다. 그래서 로컬 커밋만 해두면 내 컴퓨터에서는 작업 이력이 정리되어 있지만, 다른 사람이나 원격 저장소는 그 변경을 모릅니다.

GitHub에 올리는 행위는 보통 push라고 부릅니다.

즉 흐름은 이렇게 나뉩니다.

내 컴퓨터에서 파일을 고칩니다. 그 변경을 커밋으로 기록합니다. 그다음 push를 해야 GitHub에 올라갑니다.

이 구분을 알고 나니 질문이 명확해졌습니다.

“지금 이 변경은 내 컴퓨터에만 있는가?”

“GitHub에도 올라갔는가?”

“다른 사람이 검토할 수 있는 상태인가?”

이 세 질문은 비개발자에게도 중요합니다. 특히 AI 에이전트에게 여러 작업을 맡기는 사람이라면 더 그렇습니다. AI가 뭔가를 고쳤다고 말하는 것과, 그 변경이 안전하게 기록되고 공유 가능한 상태가 되는 것은 다릅니다.

PR은 검수 요청이고, merge는 공식 반영입니다

PR은 Pull Request의 줄임말입니다. 이름만 보면 어렵지만, 실제 의미는 비교적 단순합니다.

“제가 이렇게 바꿨습니다. 공식 코드에 반영해도 될지 검토해 주세요.”

이것이 PR입니다.

PR에는 보통 변경 내용, 이유, 테스트 결과, 리뷰 코멘트가 함께 남습니다. 그래서 PR은 단순히 코드를 올리는 기능이 아니라 협업과 검수의 공간입니다.

merge는 PR로 올라온 변경을 공식 흐름에 합치는 일입니다. 보통 main 브랜치에 합친다고 표현합니다. main은 제품이나 프로젝트의 기준선처럼 취급되는 경우가 많습니다.

그래서 PR과 merge는 역할이 다릅니다.

• PR은 검토 요청입니다.
• merge는 공식 반영입니다.

이 둘을 구분하지 못하면 “GitHub에 올렸다”와 “서비스에 반영될 수 있는 흐름에 들어갔다”를 혼동하기 쉽습니다.

AI 에이전트와 일할수록 커밋은 더 중요해집니다

AI 에이전트는 빠르게 많은 것을 바꿀 수 있습니다. 이것은 장점이지만 동시에 위험이기도 합니다.

사람이 한 줄씩 천천히 바꾸는 것보다, AI는 여러 파일을 한 번에 수정하고, 설정을 바꾸고, 스크립트를 만들고, 테스트를 실행합니다. 이때 커밋 단위가 엉망이면 나중에 무엇이 왜 바뀌었는지 복원하기 어렵습니다.

제가 이번에 배운 실전 레슨은 단순합니다.

작업이 의미 있는 단위로 끝날 때마다 커밋해야 합니다.

예를 들어 다음 작업들은 한 커밋에 뭉뚱그리기보다 나누는 것이 좋습니다.

• Discord /status 무응답 수정
• gateway 재시작 락 처리 개선
• Codex sandbox 권한 안내 문서 수정
• Tally hidden fields 생성 스크립트 추가
• 블로그/뉴스레터 원고 생성

이렇게 나누면 나중에 특정 변경만 되돌리거나, 어떤 변경이 문제를 만들었는지 확인하기 쉬워집니다.

Compound engineering 관점에서 커밋은 지식 자산입니다

저는 요즘 “compound engineering”이라는 관점으로 AI와 일하는 방식을 보고 있습니다.

한 번의 작업이 그 자리에서 끝나는 것이 아니라, 다음 작업의 기반이 되어야 합니다. 오늘의 수정이 내일의 문서가 되고, 내일의 문서가 다음 자동화의 기준이 되고, 그 기준이 다시 더 좋은 시스템을 만드는 식입니다.

그 관점에서 커밋은 단순한 개발 기록이 아닙니다.

커밋은 축적되는 의사결정 로그입니다. AI가 어떤 파일을 왜 바꿨는지, 사람이 어떤 단위로 승인했는지, 어떤 테스트를 통과했는지 남기는 구조입니다.

비개발자가 AI 에이전트와 일할 때도 이 기록은 중요합니다. 오히려 더 중요할 수 있습니다. 코드 자체를 완전히 읽지 못하더라도, 커밋 메시지와 PR 설명을 보면 작업의 흐름을 이해할 수 있기 때문입니다.

좋은 커밋은 비개발자에게도 “이 시스템이 어떻게 변해왔는지”를 읽을 수 있게 해줍니다.

오늘부터 적용할 기준

제가 이번에 정리한 기준은 아주 실용적인 수준입니다.

첫째, 작업이 끝났다고 바로 GitHub에 올렸다고 생각하지 않습니다. 먼저 로컬 커밋인지, push까지 됐는지, PR이 만들어졌는지 구분합니다.

둘째, 커밋은 너무 크게 만들지 않습니다. “여러 가지 고침”보다는 “Discord status 응답 경로 수정”처럼 한 문장으로 설명 가능한 단위가 좋습니다.

셋째, AI 에이전트가 수정한 파일을 그냥 믿지 않습니다. 커밋 전에 변경 파일을 보고, 테스트나 로그 같은 확인 근거를 남깁니다.

넷째, GitHub에 올리는 시점은 협업이나 백업이 필요할 때입니다. 로컬에서 실험 중인 변경은 로컬 커밋으로 묶어둘 수 있고, 팀 검토가 필요하거나 원격 백업이 필요하면 push와 PR로 넘어갑니다.

다섯째, merge는 더 조심합니다. merge는 “이제 공식 흐름에 들어간다”는 의미이기 때문입니다.

마무리

비개발자로서 Git을 배운다는 것은 개발자가 되기 위한 공부만은 아니었습니다.

AI와 함께 일하는 시대에는 비개발자도 작업의 흐름을 알아야 합니다. 무엇이 내 컴퓨터에만 있는지, 무엇이 GitHub에 올라갔는지, 무엇이 검토 중인지, 무엇이 공식 반영됐는지 알아야 AI를 더 안전하게 쓸 수 있습니다.

이번에 제가 배운 가장 큰 레슨은 이것입니다.

고친 일은 기록해야 남습니다.

그리고 그 기록이 쌓여야, AI와의 작업도 단발성 실행이 아니라 복리처럼 쌓이는 엔지니어링이 됩니다.

FAQ

커밋하면 바로 GitHub에 올라가나요?

아닙니다. 커밋은 보통 내 컴퓨터의 로컬 저장소에 남는 기록입니다. GitHub에 올리려면 push가 필요합니다.

PR을 만들면 바로 서비스에 반영되나요?

아닙니다. PR은 검토 요청입니다. 리뷰와 테스트를 거쳐 merge되어야 공식 흐름에 반영됩니다.

비개발자도 커밋 단위를 신경 써야 하나요?

AI 에이전트에게 실제 파일 수정이나 자동화 작업을 맡긴다면 신경 쓰는 편이 좋습니다. 커밋 단위가 좋아야 나중에 추적, 검토, 되돌리기가 쉬워집니다.

언제 GitHub에 push하면 되나요?

팀과 공유해야 하거나, 원격 백업이 필요하거나, PR 리뷰를 받아야 할 때 push하면 됩니다. 아직 실험 중이라면 로컬 커밋으로만 정리해둘 수도 있습니다.

TLDR

• AI 광고 계정 진단에는 프롬프트보다 먼저 운영 기준이 필요합니다.
• 소재, 신호, 구조, 측정 기준을 주면 AI 답변이 실무적으로 바뀝니다.
• AI는 기준을 대체하지 않습니다. 기준을 더 빠르게 적용하게 해줍니다.
• 좋은 결과는 데이터, 플레이북, 비즈니스 맥락이 함께 있을 때 나옵니다.

1. AI는 그럴듯한 답을 잘 만듭니다

광고 계정 데이터를 넣고 "문제점 찾아줘"라고 요청하면 AI는 빠르게 답을 만듭니다. 하지만 그 답이 우리 계정의 운영 기준과 맞는지는 별개의 문제입니다.

예를 들어 학습 기간을 보호해야 하는 캠페인인데 소재 OFF를 제안할 수 있습니다. CAPI 신호가 흔들리는 상황인데 소재 문제로만 진단할 수도 있습니다. 테스트 캠페인과 스케일 캠페인의 목적을 모르면 같은 ROAS 숫자를 같은 방식으로 해석할 수 있습니다.

AI가 틀렸다는 뜻이 아닙니다. 기준과 맥락을 충분히 주지 않았다는 뜻입니다.

2. 좋은 질문은 판단 기준을 포함합니다

좋은 프롬프트는 길기만 한 문장이 아닙니다. 판단 기준이 들어간 질문입니다.

나쁜 질문은 이렇게 생겼습니다.

최근 30일 광고 성과를 보고 문제점을 찾아줘.

더 나은 질문은 이렇게 바뀝니다.

최근 30일 메타광고 성과를 CPM, CTR, CVR, CAPI 이벤트 상태, 캠페인 구조, 측정 기준 관점으로 나눠 진단해 주세요. 테스트 캠페인과 스케일 캠페인은 분리해서 보고, 바로 끌 소재와 더 볼 소재를 구분해 주세요.

차이는 명확합니다. 두 번째 질문은 AI에게 봐야 할 순서와 판단 기준을 줍니다.

3. AI에게 맡기기 좋은 일과 아닌 일을 나눕니다

AI는 반복 분석과 분류에 강합니다. 소재 각도 분류, 지표 변화 요약, 회의 질문 정리, 캠페인별 이상 징후 탐지, 다음 실험 후보 정리에 유용합니다.

반대로 AI가 혼자 판단하기 어려운 것도 있습니다. 재고 상황, 마진, 브랜드 리스크, 프로모션 일정, 대행사 계약 조건, 내부 매출 기준은 사람이 제공해야 합니다.

실무에서는 이렇게 나누는 것이 좋습니다.

• AI에게 맡길 일: 지표 요약, 패턴 탐지, 소재 분류, 질문 생성
• 사람이 제공할 일: 비즈니스 맥락, 마진, 재고, 브랜드 기준, 최종 의사결정

AI를 잘 쓰는 팀은 모든 것을 맡기지 않습니다. 반복되는 판단 보조 업무를 맡깁니다.

4. 플레이북은 AI의 운영 메모리입니다

플레이북이 있으면 AI에게 매번 같은 기준을 줄 수 있습니다. "우리 팀은 ROAS가 떨어지면 CPM, CTR, CVR, CAPI, 측정 기준 순서로 봅니다"라는 문장이 있으면 답변의 방향이 달라집니다.

플레이북에는 다음 정보가 들어가야 합니다.

• 성과 하락 시 진단 순서
• 소재 OFF와 유지 기준
• 예산 증감 기준
• 캠페인 구조 원칙
• 리포트 기준과 실제 매출 기준의 차이

이 기준이 있으면 담당자가 바뀌어도 AI 결과가 크게 흔들리지 않습니다.

5. 실행 우선순위까지 받아야 합니다

AI 진단에서 자주 생기는 문제는 개선안이 너무 많다는 것입니다. 소재를 바꾸고, 랜딩을 고치고, 타겟을 조정하고, 예산을 재배분하라는 답이 한 번에 나옵니다. 이렇게 되면 실행이 어렵습니다.

그래서 마지막 질문은 반드시 우선순위여야 합니다.

위 진단을 기준으로 이번 주에 바로 할 일 3개, 이번 달에 볼 일 3개, 아직 하지 말아야 할 일 3개로 나눠 주세요.

이렇게 물어야 AI 결과가 회의 자료가 아니라 실행 목록이 됩니다.

FAQ

AI가 광고 계정을 직접 최적화하게 해도 되나요?

바로 맡기기보다 진단과 정리부터 맡기는 편이 안전합니다. 최종 예산 변경이나 소재 OFF는 사람이 기준을 확인한 뒤 결정해야 합니다.

어떤 데이터를 넣어야 하나요?

최근 30일 캠페인별 지표, 소재별 성과, 이벤트 수집 상태, 캠페인 목적, 주요 프로모션 일정을 함께 넣는 것이 좋습니다.

프롬프트 템플릿만 있으면 충분한가요?

충분하지 않습니다. 템플릿보다 중요한 것은 우리 팀의 판단 기준입니다. 같은 프롬프트라도 기준이 없으면 일반론이 나옵니다.

다음 단계

AI 광고 계정 진단을 시작하려면 먼저 프롬프트를 찾기보다 운영 기준을 정리하세요. ROAS 하락을 어떤 순서로 볼지, 소재와 예산을 어떤 기준으로 판단할지, 어떤 숫자를 최종 기준으로 삼을지부터 문서화해야 합니다.

📅 30분 무료 상담 예약

리텐션 주식회사 — 데이터 기반 스타트업 그로스 컨설팅

TLDR

• 광고 계정은 시간이 지나면 자연스럽게 복잡해집니다.
• CAPI, 네이밍, 소재 리서치, 구조 정리는 정기 점검 항목이어야 합니다.
• 체크리스트가 있으면 담당자가 바뀌어도 운영 기준이 남습니다.
• 온보딩은 계정 설명이 아니라 판단 순서를 넘기는 일입니다.

1. CAPI와 이벤트 신호를 확인합니다

전환 신호는 광고 시스템의 학습 재료입니다. 구매 이벤트가 누락되거나, 픽셀과 CAPI 중복 제거가 흔들리거나, 이벤트 매칭 품질이 낮아지면 성과 판단이 왜곡됩니다.

주간 점검에서는 다음 항목을 확인하세요.

• 구매 이벤트가 정상적으로 수집되고 있나요?
• 픽셀과 CAPI 이벤트가 중복 제거되고 있나요?
• 이벤트 매칭 품질이 갑자기 낮아지지 않았나요?
• 장바구니, 결제 시작, 구매 이벤트 흐름이 끊기지 않나요?

이 항목은 기술팀만의 일이 아닙니다. 신호가 약하면 광고비를 더 써도 좋은 고객을 찾는 속도가 느려집니다.

2. 네이밍과 태깅을 정리합니다

네이밍은 보고서를 예쁘게 만들기 위한 일이 아닙니다. 나중에 배울 수 있게 데이터를 남기는 일입니다.

캠페인명, 광고 세트명, 소재명에 목적과 테스트 가설이 남아 있지 않으면 분석 속도가 크게 떨어집니다. "어떤 소재가 잘 됐나요?"라는 질문에 답하려면 소재 각도, 오퍼, 포맷, 타겟 역할이 추적 가능해야 합니다.

최소한 다음 정보는 이름이나 태그로 남겨두는 편이 좋습니다.

• 캠페인 목적: 테스트, 스케일, 리타겟팅
• 소재 각도: 문제 공감, 후기, 비교, 사용 장면
• 오퍼: 할인, 무료 배송, 번들, 체험
• 포맷: 이미지, 영상, 릴스, 카탈로그

담당자가 바뀌어도 이름만 보고 맥락을 이해할 수 있어야 합니다.

3. 소재 리서치 루프를 만듭니다

좋은 소재는 회의실 안에서만 나오지 않습니다. 고객 리뷰, 댓글, 상담 기록, 경쟁사 광고, 검색어, 상세페이지 이탈 지점에서 나옵니다.

매주 한 번은 소재 성과만 보는 회의가 아니라 고객 언어를 모으는 시간을 가져야 합니다. 이번 주에 고객이 어떤 표현을 썼는지, 어떤 불만이 반복됐는지, 어떤 경쟁사 메시지가 눈에 띄었는지 기록하세요.

소재 리서치 루프는 다음 순서로 운영할 수 있습니다.

1. 고객 리뷰와 댓글에서 표현을 수집합니다.
2. 경쟁사 광고에서 반복되는 메시지를 분류합니다.
3. 기존 소재를 구매 이유별로 나눕니다.
4. 비어 있는 소재 각도를 다음 테스트로 만듭니다.

이 루프가 없으면 소재 제작은 매번 감으로 돌아갑니다.

4. 월 1회 계정 구조를 정리합니다

종료된 테스트, 중복된 광고 세트, 더 이상 쓰지 않는 소재가 계정에 남아 있으면 운영 판단이 흐려집니다. 월 1회는 계정 구조를 정리해야 합니다.

확인할 항목은 단순합니다.

• 목적이 불분명한 캠페인이 남아 있지 않나요?
• 전환량이 부족한 광고 세트가 너무 많이 쪼개져 있지 않나요?
• 종료된 실험이 켜진 상태로 남아 있지 않나요?
• 테스트 캠페인과 스케일 캠페인의 역할이 섞여 있지 않나요?

정리는 삭제만 의미하지 않습니다. 남길 것, 합칠 것, 멈출 것, 다시 테스트할 것을 구분하는 일입니다.

5. 신규 담당자에게 판단 순서를 넘깁니다

신규 마케터가 막히는 지점은 숫자 자체가 아니라 맥락입니다. 이 캠페인이 스케일 목적이고, 저 캠페인이 테스트 목적이며, 어떤 소재는 ROAS가 낮아도 유지해야 하는 이유를 알아야 합니다.

체크리스트는 그래서 온보딩 문서가 됩니다. "이 계정에는 이런 캠페인이 있습니다"가 아니라 "이 계정은 이런 순서로 판단합니다"를 알려줘야 합니다.

온보딩 문서에는 다음 질문의 답이 있어야 합니다.

• ROAS가 떨어지면 어떤 지표부터 보나요?
• 소재를 끄기 전에 어느 정도 데이터를 기다리나요?
• 광고 관리자와 실제 매출 차이는 어떻게 해석하나요?
• 예산을 올리거나 줄일 때 어떤 기준을 쓰나요?

이 기준이 남아 있으면 담당자가 바뀌어도 팀의 운영 품질이 유지됩니다.

FAQ

체크리스트는 얼마나 자주 봐야 하나요?

CAPI와 이벤트 신호는 주간으로, 계정 구조 정리는 월간으로 보는 것을 권장합니다. 소재 리서치는 매주 짧게라도 루프를 만드는 편이 좋습니다.

작은 계정도 네이밍 규칙이 필요할까요?

필요합니다. 작은 계정일수록 담당자 한 명의 기억에 의존하기 쉽습니다. 간단한 규칙만 있어도 인수인계와 분석 속도가 달라집니다.

온보딩 문서와 체크리스트를 따로 만들어야 하나요?

처음에는 하나로 시작해도 됩니다. 계정 점검 항목 옆에 판단 기준과 예시를 붙이면 온보딩 문서로도 충분히 작동합니다.

다음 단계

이번 주에는 새 문서를 만들기보다 현재 계정에서 세 가지만 점검해 보세요. CAPI 상태, 네이밍 규칙, 종료된 테스트 캠페인입니다. 이 세 가지가 정리되면 계정이 훨씬 읽기 쉬워집니다.

📅 30분 무료 상담 예약

리텐션 주식회사 — 데이터 기반 스타트업 그로스 컨설팅

TLDR

• 광고 회의가 길어지는 이유는 데이터가 부족해서가 아니라 판단 기준이 다르기 때문입니다.
• 소재 OFF, 예산 변경, 학습 기간, 리포트 기준은 문서화해야 합니다.
• 운영 문서는 대행사를 감시하는 문서가 아니라 의사결정 속도를 높이는 문서입니다.
• 반복 질문은 그대로 운영 문서의 목차가 됩니다.

1. 소재 OFF 기준을 먼저 합의합니다

성과가 낮아 보이는 소재를 언제 꺼야 하는지는 광고 회의에서 가장 자주 반복되는 질문입니다. 그런데 "ROAS가 낮으니 끄자"는 기준만으로는 부족합니다.

소재를 판단하려면 최소 지출, 노출량, 클릭 수, 전환 수, 테스트 목적, 학습 기간을 함께 봐야 합니다. 상단 퍼널 소재와 구매 전환 소재를 같은 ROAS 기준으로 비교하면 잘못된 결론이 나올 수 있습니다.

문서에는 최소한 다음 기준이 있어야 합니다.

• 소재를 판단하기 위한 최소 지출 기준
• 클릭이나 전환이 부족할 때의 보류 기준
• 테스트 소재와 스케일 소재의 판단 기준 차이
• 브랜드 메시지 목적 소재의 예외 기준

이 기준이 있으면 회의에서 "왜 아직 켜두나요?"라는 질문이 "이 소재는 어떤 기준으로 더 보는 건가요?"로 바뀝니다.

2. 예산 변경 기준을 숫자로 정합니다

성과가 좋으면 예산을 올리고 싶고, 성과가 나쁘면 줄이고 싶습니다. 문제는 예산 변경이 너무 자주, 너무 크게 일어날 때입니다. 계정 학습이 흔들리고, 다음 주 회의에서는 무엇 때문에 성과가 변했는지 알기 어려워집니다.

예산 변경 기준은 다음처럼 문서화하는 것이 좋습니다.

• 증액 전 확인할 기준 기간
• 1회 증액 폭
• 감액을 결정하는 지표
• 프로모션 기간의 예외 기준
• 예산 변경 후 관찰 기간

예산은 감정이 아니라 룰로 움직여야 합니다. 룰이 있어야 대행사는 일관되게 운영하고, 광고주는 예측 가능한 방식으로 의사결정할 수 있습니다.

3. 학습 기간을 보호할 기준이 필요합니다

광고주는 빠른 판단을 원합니다. 대행사는 더 많은 데이터를 기다려야 한다고 말합니다. 이 차이가 반복되면 서로 답답해집니다.

해결책은 학습 기간을 말로 설명하는 것이 아니라 문서에 남기는 것입니다. 새 캠페인, 새 광고 세트, 새 소재를 켰을 때 어느 정도 기간과 데이터를 보고 판단할지 정해야 합니다.

예를 들어 다음 기준을 둘 수 있습니다.

• 신규 소재는 최소 노출량과 클릭 수를 채운 뒤 판단합니다.
• 구매 목적 캠페인은 전환 수가 부족하면 ROAS만으로 판단하지 않습니다.
• 테스트 첫 24시간의 숫자는 방향성 참고로만 봅니다.

이 기준이 없으면 매일 성과 화면을 보며 조급한 최적화가 반복됩니다.

4. 리포트 기준을 분리합니다

광고 관리자, GA4, CRM, 실제 매출은 서로 다르게 보입니다. 집계 방식과 어트리뷰션 기준이 다르기 때문입니다. 중요한 것은 어느 숫자가 절대적으로 맞느냐가 아니라, 어떤 숫자를 어떤 의사결정에 쓸지 정하는 것입니다.

운영 문서에는 다음처럼 역할을 나눠두는 편이 좋습니다.

• 일일 운영: 광고 관리자 기준
• 주간 흐름 확인: 광고 관리자와 GA4 함께 확인
• 월간 예산 판단: 실제 매출, 마진, 신규 고객 기준
• 경영 보고: 내부 매출 데이터 기준

이 합의가 없으면 매달 "어느 숫자가 맞나요?"라는 질문이 반복됩니다.

운영 문서에 꼭 들어갈 항목

처음부터 거창한 플레이북을 만들 필요는 없습니다. 다음 항목만 있어도 회의 품질이 달라집니다.

1. 캠페인 목적과 역할
2. 소재 OFF 기준
3. 예산 증감 기준
4. 학습 기간 보호 기준
5. 리포트 기준
6. 예외 상황 처리 방식

이 문서는 대행사를 감시하기 위한 문서가 아닙니다. 같은 상황에서 같은 질문을 하고, 같은 기준으로 의사결정하기 위한 문서입니다.

FAQ

운영 문서는 누가 만들어야 하나요?

광고주와 대행사가 함께 만들어야 합니다. 대행사는 운영 현실을 알고, 광고주는 비즈니스 기준과 매출 판단 기준을 알고 있기 때문입니다.

문서가 있으면 회의가 없어지나요?

아닙니다. 하지만 회의의 내용이 바뀝니다. 반복 설명보다 예외 상황과 다음 액션에 집중할 수 있습니다.

작은 광고 계정에도 필요할까요?

필요합니다. 예산이 작을수록 잘못된 판단 한 번의 영향이 큽니다. 간단한 1페이지 기준표부터 시작하면 됩니다.

다음 단계

이번 주 광고 회의에서 반복된 질문을 적어보세요. 그 질문들이 운영 문서의 첫 목차입니다. 소재, 예산, 학습 기간, 리포트 기준만 정리해도 광고주와 대행사의 협업 속도는 달라집니다.

📅 30분 무료 상담 예약

리텐션 주식회사 — 데이터 기반 스타트업 그로스 컨설팅

TLDR

• 2026년 메타광고는 타겟 세분화보다 학습 환경이 중요합니다.
• 소재는 단순한 광고물이 아니라 광고 시스템이 고객을 이해하는 신호입니다.
• 픽셀과 CAPI 신호가 약하면 자동화도 제대로 작동하기 어렵습니다.
• 캠페인 구조는 통제감보다 학습량과 판단 가능성을 기준으로 설계해야 합니다.

1. 소재 신호: 광고가 누구를 데려오는지 결정합니다

메타광고에서 소재는 더 이상 "사람에게 보이는 이미지나 영상"만이 아닙니다. 광고 시스템이 어떤 고객에게 이 광고를 보여줄지 판단하는 신호이기도 합니다.

같은 제품을 팔더라도 소재가 어떤 구매 이유를 말하느냐에 따라 반응하는 고객이 달라집니다. 가격 혜택을 강조한 소재, 사용 장면을 보여주는 소재, 고객 불편을 먼저 짚는 소재, 리뷰를 앞세운 소재는 서로 다른 신호를 만듭니다.

그래서 2026년 소재 운영의 핵심 질문은 "몇 개 만들었나요?"가 아닙니다. "서로 다른 구매 이유를 충분히 테스트하고 있나요?"입니다.

실무에서는 소재를 최소한 다음 기준으로 나눠 보세요.

• 문제 공감: 고객이 지금 겪는 불편을 보여주는 소재
• 사용 맥락: 제품을 언제, 어디서, 어떻게 쓰는지 보여주는 소재
• 비교 근거: 기존 대안과 다른 이유를 보여주는 소재
• 신뢰 근거: 후기, 수치, 사용 전후를 보여주는 소재

소재가 모두 같은 제품 사진과 비슷한 할인 문구라면, 개수는 많아도 신호는 적습니다.

2. 전환 신호: 좋은 고객을 학습할 재료입니다

자동화가 강해질수록 데이터 품질은 더 중요해집니다. 픽셀과 CAPI가 불안정하거나 구매 이벤트가 누락되면, 광고 시스템은 어떤 고객이 실제로 가치 있는 고객인지 덜 정확하게 배웁니다.

이 문제는 겉으로 보기에는 기술 세팅처럼 보입니다. 하지만 운영 영향은 직접적입니다. 전환 신호가 약하면 좋은 소재도 충분히 학습되지 않고, 예산을 올려도 성과가 흔들릴 수 있습니다.

특히 다음 상황에서는 타겟보다 전환 신호를 먼저 확인해야 합니다.

• 클릭은 유지되는데 구매 전환이 갑자기 줄었습니다.
• 광고 관리자와 실제 매출 차이가 커졌습니다.
• 구매 이벤트 수가 사이트 주문 수와 맞지 않습니다.
• 이벤트 매칭 품질이 이전보다 낮아졌습니다.

이 상태에서 타겟을 좁히면 문제가 해결되는 것처럼 보일 수 있지만, 실제로는 학습할 데이터 풀만 더 줄일 수 있습니다.

3. 구조 단순화: 계정이 배울 수 있게 만듭니다

캠페인과 광고 세트를 많이 나누면 운영자는 통제하고 있다고 느낍니다. 하지만 예산이 충분하지 않은 계정에서는 그 구조가 학습을 방해할 수 있습니다.

예를 들어 하루 예산이 작고 전환 수가 제한적인데 캠페인을 목적별, 타겟별, 소재별로 과하게 나누면 각 단위가 판단 가능한 데이터를 얻지 못합니다. 그러면 운영자는 매일 숫자를 보고 있지만, 실제로는 충분한 학습량 없이 결정을 내리게 됩니다.

좋은 계정 구조는 보기 좋은 폴더 구조가 아닙니다. 다음 질문에 답할 수 있어야 합니다.

• 각 캠페인은 명확한 목적을 갖고 있나요?
• 광고 세트별로 판단 가능한 전환량이 쌓이나요?
• 테스트 캠페인과 스케일 캠페인의 역할이 분리되어 있나요?
• 종료된 실험이 계정 안에 계속 남아 있지 않나요?

구조를 단순하게 만든다는 것은 아무것도 관리하지 않는다는 뜻이 아닙니다. 배울 수 있는 단위로 묶고, 판단 가능한 데이터가 쌓이게 만든다는 뜻입니다.

자주 하는 실수

첫 번째 실수는 성과가 떨어질 때마다 타겟을 좁히는 것입니다. 타겟을 좁히면 단기적으로 통제감은 생기지만, 학습량이 줄어 장기 성과가 더 불안정해질 수 있습니다.

두 번째 실수는 자동화를 믿는다고 계정 점검을 생략하는 것입니다. 자동화는 좋은 소재 신호와 전환 신호, 단순한 구조 위에서 더 잘 작동합니다.

세 번째 실수는 소재 다양성을 개수로만 판단하는 것입니다. 같은 메시지를 다른 이미지에 올린 것은 진짜 다양성이 아닐 수 있습니다.

실행 가이드

이번 주에 계정을 본다면 세 가지만 확인해 보세요.

1. 최근 30일 소재를 구매 이유별로 분류합니다.
2. 픽셀, CAPI, 구매 이벤트 수집 상태를 확인합니다.
3. 전환량이 부족한 캠페인과 광고 세트를 합칠 수 있는지 봅니다.

이 세 가지를 보면 "타겟을 어떻게 좁힐까"보다 더 중요한 질문이 보입니다. "광고 시스템이 제대로 배울 수 있는 계정인가"입니다.

FAQ

타겟팅은 이제 안 봐도 되나요?

아닙니다. 다만 성과 하락의 첫 원인으로 타겟팅만 보는 습관을 줄여야 합니다. 소재 신호, 전환 신호, 구조를 먼저 확인한 뒤 타겟팅을 봐야 합니다.

Advantage+를 쓰면 구조를 신경 쓰지 않아도 되나요?

아닙니다. 자동화 캠페인도 입력되는 소재와 전환 신호, 예산 구조의 영향을 받습니다.

소재는 몇 개가 적당한가요?

정답 개수보다 중요한 것은 서로 다른 구매 이유를 담았는지입니다. 같은 메시지를 반복한 20개보다 다른 각도의 5개가 더 나을 수 있습니다.

다음 단계

2026년 메타광고 운영의 핵심은 더 세밀한 타겟팅이 아니라 더 좋은 학습 환경입니다. 소재 신호, 전환 신호, 구조 단순화부터 확인해 보세요.

📅 30분 무료 상담 예약

리텐션 주식회사 — 데이터 기반 스타트업 그로스 컨설팅

TLDR

• ROAS 하락을 보면 먼저 소재를 끄지 말고 지표를 분해해야 합니다.
• CPM, CTR, CVR, CAPI, 측정 기준을 순서대로 보면 원인 범위가 좁아집니다.
• 광고 관리자 숫자와 실제 매출 기준이 다르면 같은 성과를 보고도 다른 결론을 냅니다.
• 이 5가지 지표는 정답지가 아니라 성급한 최적화를 막는 진단 순서입니다.

1. CPM: 노출 비용이 먼저 올랐나요?

CPM은 광고가 1,000회 노출되는 데 드는 비용입니다. ROAS가 떨어졌을 때 CPM부터 보는 이유는 간단합니다. 같은 예산으로 살 수 있는 노출량이 줄면, 클릭과 구매 기회도 줄어들기 때문입니다.

예를 들어 하루 예산은 그대로인데 CPM이 30% 올랐다면 소재 성과가 그대로여도 도달 가능한 고객 수는 줄어듭니다. 이 상황에서 바로 소재를 끄면 문제를 잘못 짚을 수 있습니다. 시즌 경쟁이 강해졌거나, 특정 타겟 풀이 비싸졌거나, 프로모션 기간에 입찰 환경이 바뀐 것일 수 있습니다.

확인할 질문은 세 가지입니다.

• CPM 상승이 계정 전체에서 나타났나요, 특정 캠페인에서만 나타났나요?
• 전년 동기나 직전 프로모션 기간과 비교해도 높은가요?
• CPM은 올랐지만 CTR과 CVR은 유지되고 있나요?

CPM만 올랐고 나머지 지표가 유지된다면, 첫 액션은 소재 OFF가 아니라 예산 배분과 캠페인 우선순위 조정일 수 있습니다.

2. CTR: 사람들이 광고에 덜 반응하나요?

CTR은 광고를 본 사람 중 클릭한 비율입니다. CPM이 크게 변하지 않았는데 CTR이 떨어졌다면, 광고가 사람을 멈춰 세우는 힘이 약해졌을 가능성이 큽니다.

이때 중요한 것은 "소재가 나쁘다"로 끝내지 않는 것입니다. 어떤 소재 각도가 지쳤는지 봐야 합니다. 제품 사진만 반복했는지, 같은 혜택을 말만 바꿔 말하고 있는지, 고객의 문제 상황을 충분히 건드리지 못하고 있는지 확인해야 합니다.

실무에서는 소재를 다음처럼 나눠서 보는 편이 좋습니다.

• 문제 공감형: 고객이 겪는 불편을 먼저 보여주는 소재
• 비교형: 기존 대안과 우리 제품의 차이를 보여주는 소재
• 후기형: 실제 사용 맥락과 신뢰를 보여주는 소재
• 사용 장면형: 제품을 언제 어떻게 쓰는지 보여주는 소재

CTR이 떨어진다면 "새 소재를 더 만들자"보다 "다른 구매 이유를 담은 소재가 있는가"를 먼저 물어보세요.

3. CVR: 클릭 이후 구매 설득이 막혔나요?

CVR은 클릭 이후 전환율입니다. CTR은 유지되는데 CVR이 떨어졌다면 광고 소재보다 랜딩 페이지, 가격, 혜택, 재고, 배송 조건, 리뷰, 결제 흐름을 봐야 합니다.

이 구간을 놓치면 광고팀이 계속 소재만 바꾸게 됩니다. 고객은 광고를 클릭했지만 구매하지 않은 것입니다. 그러면 문제는 광고 첫인상보다 구매 설득 과정에 있을 가능성이 높습니다.

특히 커머스에서는 다음 항목을 같이 봐야 합니다.

• 상세페이지 첫 화면에서 핵심 혜택이 보이나요?
• 광고에서 약속한 메시지와 랜딩 페이지 메시지가 이어지나요?
• 가격, 배송비, 재고, 쿠폰 조건이 구매를 막고 있지 않나요?
• 모바일 결제 과정에서 이탈이 늘지 않았나요?

CVR 하락은 광고 관리자 안에서만 해결되지 않는 경우가 많습니다. 상품, CRM, 웹사이트 담당자와 같이 봐야 합니다.

4. CAPI: 전환 신호가 제대로 들어오고 있나요?

CAPI는 Conversions API의 줄임말입니다. 쉽게 말해 웹사이트나 서버에서 발생한 전환 신호를 메타 광고 시스템에 더 안정적으로 전달하기 위한 장치입니다.

전환 신호가 흔들리면 광고 시스템은 어떤 고객이 좋은 고객인지 덜 정확하게 배웁니다. 이 상태에서 소재를 바꾸거나 예산을 조정해도 성과가 계속 불안정할 수 있습니다.

확인할 항목은 다음과 같습니다.

• 구매 이벤트가 정상 수집되고 있나요?
• 픽셀과 CAPI 이벤트가 중복 제거되고 있나요?
• 이벤트 매칭 품질이 갑자기 낮아지지 않았나요?
• 주요 이벤트가 장바구니, 결제 시작, 구매 순서로 안정적으로 들어오나요?

이 항목은 기술 세팅처럼 보이지만 비즈니스 영향은 직접적입니다. 신호가 약하면 좋은 고객을 찾는 속도가 느려지고, 학습이 불안정해집니다.

5. 측정 기준: 같은 숫자를 보고 있나요?

마지막은 측정 기준입니다. 광고 관리자 ROAS, GA4, CRM, 실제 매출은 서로 다르게 보일 수 있습니다. 어느 하나가 무조건 틀렸다는 뜻이 아닙니다. 집계 방식과 기준 기간, 어트리뷰션이 다르기 때문입니다.

문제는 차이 자체가 아니라, 어떤 숫자로 의사결정할지 합의하지 않은 상태입니다. 광고주는 실제 매출을 보고 있고, 대행사는 광고 관리자 ROAS를 보고 있으면 회의는 매번 같은 질문으로 돌아갑니다.

운영 기준을 이렇게 나눠두면 좋습니다.

• 일일 모니터링: 광고 관리자 기준
• 주간 최적화: 광고 관리자 + GA4 흐름
• 월간 예산 판단: 실제 매출과 마진 기준
• 성과 리뷰: 신규 고객, 재구매, 객단가까지 포함

같은 숫자를 보는 것보다 중요한 것은 같은 기준으로 해석하는 것입니다.

자주 하는 실수

첫 번째 실수는 ROAS가 낮은 소재를 바로 끄는 것입니다. 최소 노출량, 클릭 수, 전환 수가 부족하면 아직 판단 가능한 데이터가 아닐 수 있습니다.

두 번째 실수는 타겟을 좁히는 것으로 문제를 해결하려는 것입니다. 타겟을 좁히면 통제하는 느낌은 들지만, 학습량이 줄어 성과가 더 불안정해질 수 있습니다.

세 번째 실수는 광고팀 안에서만 원인을 찾는 것입니다. CVR, CAPI, 측정 기준 문제는 웹사이트, 데이터, 상품, CRM과 연결되어 있습니다.

회의에서 바로 쓰는 진단 순서

ROAS가 떨어진 날에는 다음 순서로 회의를 시작해 보세요.

1. CPM이 올랐는지 확인합니다.
2. CTR이 떨어졌는지 확인합니다.
3. CVR이 떨어졌는지 확인합니다.
4. CAPI와 구매 이벤트 상태를 확인합니다.
5. 광고 관리자와 실제 매출 기준 차이를 확인합니다.

이 순서만 정해도 회의가 달라집니다. "무엇을 끌까요?"에서 "어디에서 문제가 시작됐나요?"로 질문이 바뀝니다.

FAQ

ROAS가 떨어지면 소재를 바로 꺼야 하나요?

아닙니다. 최소 데이터가 쌓였는지, CPM과 CTR 중 무엇이 먼저 흔들렸는지 확인한 뒤 결정해야 합니다.

CPM이 올랐으면 무조건 예산을 줄여야 하나요?

아닙니다. CPM은 시장 비용을 보여줄 뿐입니다. CTR과 CVR이 유지되고 있다면 예산을 줄이는 대신 캠페인 우선순위를 조정하는 편이 나을 수 있습니다.

CAPI는 광고 성과와 직접 관련이 있나요?

관련이 있습니다. CAPI는 전환 신호의 안정성과 연결됩니다. 신호가 약하면 광고 시스템이 좋은 고객을 학습하기 어려워집니다.

다음 단계

이번 글의 핵심은 더 많은 리포트를 만들자는 것이 아닙니다. 메타광고 ROAS가 떨어졌을 때 같은 순서로 원인을 보는 기준을 만들자는 것입니다.

직접 시작하려면 최근 30일 데이터를 열고 CPM, CTR, CVR, CAPI, 측정 기준을 한 줄씩 확인해 보세요. 이 과정에서 어디부터 봐야 할지 막힌다면 계정 구조와 전환 신호를 함께 보는 편이 좋습니다.

📅 30분 무료 상담 예약

리텐션 주식회사 — 데이터 기반 스타트업 그로스 컨설팅

📝 이 글은 해당 세션 전에 사전 준비 & 프리모템(premortem)을 하면서 작성되었습니다.

본 글은 3편 시리즈의 3편입니다. 1편: 클로드 코드 + 에어브릿지 MCP × API 자동화 청사진 · 2편: 클로드 코드로 OG 이미지 만들고, 에어브릿지 API로 트래킹 링크 N개 발급하기

TL;DR

• 인플루언서 마케팅·자체 SMS·자체 메일·오프라인 행사 같은 공식 통합이 없는 매체의 비용은 마케터가 매주 엑셀에서 따로 관리하다가 ROAS 계산할 때마다 "통합 비용"을 손으로 합칩니다.
• 에어브릿지의 Self-Serve Cost Upload API를 쓰면 CSV 한 번으로 비용·노출·클릭이 대시보드의 Cost (Channel)·Impressions (Channel)·Clicks (Channel) 메트릭에 그대로 녹습니다. 그 다음부터는 통합 ROAS가 자동입니다.
• 이걸 클로드 코드(Claude Code) 에이전트 + cron으로 매일 새벽 돌리면, 마케터는 Google Sheet에 비용을 입력만 하면 됩니다. 나머지는 기계가 처리합니다.
• 단, 공식 통합되어 있는 매체(예: 네이버 검색광고, Meta, Google Ads, TikTok 등)는 self-serve upload 대상이 아닙니다. 에어브릿지 정책상 차단됩니다. 가이드의 schema는 비통합 매체 시연·구현 참고용입니다.

📤 이 글 한 번에 공유하기 — 클로드 코드 + 에어브릿지 REST API + GPT image로 즉석 발급한 트래킹 링크입니다. 채널 blog_share, 캠페인 airbridge-self-serve-cost-upload-claude-code-automation_202604_blog_share, OG 이미지는 GPT Image 2 (high, 1536×1024). 클릭은 에어브릿지 actuals 리포트에 그대로 집계됩니다.

통합 안 된 매체 비용도 에어브릿지 대시보드에 — Self-Serve Cost Upload + 클로드 코드 자동화 실전

인플루언서·자체 SMS·자체 메일·오프라인 같은 비통합 매체 비용도 시트→CSV→에어브릿지 Self-Serve Upload→MCP 검증으로 매일 새벽 자동 동기화하는 실전 파이프라인.

demokr.ab180.co

1. 고질병을 다시 본다

1편 매트릭스에서 짚은 고질병 5(비용·ROAS 통합)와 고질병 1(리포트 빌드·해석)이 만나는 지점입니다.

마케터는 이미 다음 두 가지를 매주 합니다. - 통합된 매체 (Meta·Google·TikTok 등)는 에어브릿지에서 자동 집계 → 대시보드 보고 - 비통합 매체 (인플루언서·자체 SMS·자체 메일·오프라인)는 별도 시트 에서 손으로 합산 → 슬랙·노션 보고

문제는 마지막에 합칠 때. 채널 단위 ROAS, 매체 믹스 기여도, ROI 등을 한 화면에서 보려면 둘이 같은 단위로 들어가 있어야 합니다. 매주 한 명이 1~3시간씩 합치는 일에 쓰입니다. 통합 매체와 비통합 매체를 같은 단위로 합치고 나면, 그 다음에 증분(Incremental) 분석이나 iROAS 비교 같은 한 단계 위 분석으로 넘어갈 수 있습니다.

해결의 핵심은 두 줄기를 같은 집결지로 모으는 일. 에어브릿지 대시보드가 그 집결지가 됩니다.

2. 자동화 흐름 한눈에

[ 마케터가 시트에 비용 입력 ]
   - Google Sheet, Notion DB, Airtable 어느 거든
   - 컬럼: date, channel, currency, campaign, impressions, clicks, cost, ad_group(선택)
   │
   ▼
[ Cron 매일 06:00 KST ]
   │
   ▼
[ 에이전트 — Sheet → CSV 변환 ]
   - 어제까지의 데이터만
   - 컨벤션·금지어·타입 검증
   - 신규 채널 발견 시 사람 알림
   │
   ▼
[ 에어브릿지 REST API ] POST /self-serve-data/v1/ad-spend/requests
   - multipart/form-data로 CSV 업로드
   - request_id 반환
   │
   ▼
[ 에이전트 — Status Polling ]
   - GET /self-serve-data/v1/ad-spend/requests/{request_id}
   - uploaded → validated → ingested → succeeded
   - failed 시 reason 분석 → 사람 알림
   │
   ▼
[ 에어브릿지 MCP ] get_actuals_report로 검증
   - 어제 비용 (Cost (Channel)) 정상 집계 확인
   - anomaly (전일 대비 ±N%) 감지 시 사람 알림
   │
   ▼
[ 슬랙 보고 ]
   - 어제 비통합 매체 비용 합계
   - 통합 매체와 합산한 매체 믹스 (가시성)
   - anomaly 있는 매체 강조

3. 1단계 — Sheet 스키마 설계

에어브릿지의 Self-Serve Cost Upload는 다음 컬럼을 받습니다 (필수와 선택).

데이터의 식별 키는 (date, channel, campaign) 3종 조합. 같은 키로 두 번 업로드하면 마지막 업로드가 덮어씁니다. 즉 수정도 곧 재업로드. 이 점이 자동화 설계에 큰 영향을 줍니다 — idempotent하게 매일 같은 슬라이딩 윈도우(예: 어제 1일치 또는 어제까지 7일치)를 다시 올려도 안전합니다.

3-1. 시트 권장 구조 (예시)

(가상 데이터 명시) 위 표의 모든 수치는 시연용 가상값 입니다.

channel 이름 컨벤션은 다음 패턴을 권장합니다. - influencer_{platform} — 인플루언서 마케팅 - internal_{channel} — 자사 보유 채널 (sms, email, push, kakao_msg 등) - offline_{type} — 오프라인 (event, ooh, partnership 등) - partner_{name} — 제휴/공동 마케팅

offline_event처럼 노출·클릭이 무의미한 경우 0 입력. 비용만 집계됩니다. 그래도 cost는 반드시 양수로.

4. 2단계 — Sheet → CSV 변환 (LLM 에이전트의 사전 검증)

LLM 에이전트가 시트를 읽고 CSV로 직렬화하기 전에 다음 검증을 합니다.

# 의사 코드 — 실제 환경에서는 시트 SDK + Anthropic SDK 등 결합
def validate_rows(rows):
    integrated_channels = load_integrated_channels()  # 에어브릿지 공식 통합 채널 목록 (캐시)
    seen_keys = set()
    errors = []

    for r in rows:
        key = (r.date, r.channel, r.campaign)

        # 중복 키
        if key in seen_keys:
            errors.append(("DUP_KEY", r))
        seen_keys.add(key)

        # 미래 날짜
        if r.date > today_in_app_tz():
            errors.append(("FUTURE_DATE", r))

        # 통합된 채널 사용 시도
        if r.channel in integrated_channels:
            errors.append(("INTEGRATED_CHANNEL", r))

        # 통화 코드
        if r.currency not in ISO_4217:
            errors.append(("BAD_CURRENCY", r))

        # 음수 또는 비숫자
        if r.cost < 0 or not is_int(r.impressions) or not is_int(r.clicks):
            errors.append(("BAD_NUMBER", r))

    return errors

4-1. Human-in-the-loop 지점

검증 결과가 경고(warning)와 오류(error)로 나뉩니다.

• 오류 (e.g. 통합 채널 사용 시도, 미래 날짜, 음수 비용): 업로드 즉시 차단 → 슬랙에 마케터 멘션 → 사람이 시트 수정 후 다음 사이클에서 재시도
• 경고 (e.g. 전일 대비 비용 ±50% 이상 변동 같은 anomaly): 업로드는 진행하되 슬랙에 알림 → 사람이 맞다고 confirm 또는 수정 결정
• 신규 채널 발견 (e.g. 어제까지 없던 influencer_threads가 처음 등장): 업로드 진행하지만 슬랙에 명시적 멘션 → 사람 승인. 첫 등장 채널은 컨벤션·정책 적용 대상

이 3단계 분기가 마케팅 자동화에서 가장 자주 무너지는 지점입니다. 모든 걸 자동으로 흘러보내면 사람이 모르는 사이에 잘못된 데이터가 누적됩니다. 모든 걸 사람 승인 대기로 두면 자동화의 효용이 사라집니다. 위 3분기가 우리가 권하는 균형점입니다.

💡 암묵지 → 명시지 한 번 더 — 위 경고 임계값 (예: ±50%), 오류 차단 룰, 신규 채널 정책은 모두 우리 회사 마케터의 머릿속에서 끌어낸 결과 여야 합니다. 1편에서 정리한 Cognitive Task Analysis 3주 인터뷰 트랙 으로 임계값을 숫자로 박아두면, 같은 ±50% 이상 변동이라도 시즌 정상과 진짜 anomaly를 구분합니다. 그렇지 않으면 에이전트의 권고는 일반론이고, 마케터는 다시 검토 합니다.

5. 3단계 — REST API multipart upload

검증 통과 후 CSV로 직렬화하고 multipart로 업로드합니다.

import FormData from "form-data";
import fetch from "node-fetch";

async function uploadAdSpend(csvBuffer, apiToken) {
  const form = new FormData();
  form.append("file", csvBuffer, {
    filename: `ad_spend_${dayjs().format("YYYYMMDD")}.csv`,
    contentType: "text/csv"
  });

  const res = await fetch(
    "https://api.airbridge.io/self-serve-data/v1/ad-spend/requests",
    {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${apiToken}`,
        ...form.getHeaders()
      },
      body: form
    }
  );

  if (!res.ok) {
    const err = await res.text();
    throw new Error(`Upload failed: ${res.status} ${err}`);
  }
  return await res.json();  // { request_id, ... }
}

⚠️ Self-Serve API는 Owner / In-house Marketer 권한의 토큰만 받습니다. 대행사·하위 권한 토큰은 거부됩니다. CI 환경에는 Owner 전용 봇 계정 토큰을 분리해 두는 것을 권합니다.

1회 요청당 최대 10,000행 / 1MB. 큰 시트는 자동으로 chunk 분할이 필요합니다.

6. 4단계 — Status Polling

Self-Serve 업로드는 비동기. request_id를 받은 뒤 다음 상태로 이동합니다.

async function pollStatus(requestId, apiToken, maxWaitMs = 15 * 60 * 1000) {
  const start = Date.now();
  while (Date.now() - start < maxWaitMs) {
    const res = await fetch(
      `https://api.airbridge.io/self-serve-data/v1/ad-spend/requests/${requestId}`,
      { headers: { "Authorization": `Bearer ${apiToken}` } }
    );
    const json = await res.json();
    const status = json.task?.status;
    if (status === "succeeded") return json;
    if (status === "failed") throw new Error(`Failed: ${json.reason}`);
    await sleep(15_000);  // 15초 간격
  }
  throw new Error("Timeout polling status");
}

7. 5단계 — MCP로 actuals 리포트 검증

업로드 성공 후 그날 cost가 실제로 dashboard에 반영되었는지 MCP로 즉시 검증합니다.

자연어로 호출 시:

"demokr 앱의 어제 날짜, channel별 Cost (Channel)·Impressions (Channel)·Clicks (Channel)을 표로. 어제 self-serve로 올린 4개 채널 (influencer_youtube, influencer_instagram, internal_sms, offline_event) 모두 0이 아닌 값을 가지는지 검증."

MCP는 metadata→report 체인으로 다음을 호출합니다. 1. get_actuals_metrics_metadata — cost_channel, clicks_channel, impressions_channel 키 확인 2. get_actuals_group_by_metadata — channel 키 확인 3. get_actuals_report — 어제 날짜, 4개 채널 필터, 위 메트릭 호출

응답을 받아 LLM이 다음을 판단합니다.

• 4개 채널 모두 cost > 0인가? (offline은 cost만 양수, 나머지 0 허용)
• 어제 시트에 입력한 합계와 일치하는가? (채널별 cost 합산 비교, ±1% 허용 오차)
• 어제 대비 ±N% anomaly 채널 있는가?

판단 결과가 모두 정상이면 슬랙 보고. 하나라도 어긋나면 사람 멘션.

8. 결과 — 30일치 자동 동기화 시연 (가상)

워크샵 데모용 샌드박스에 30일치 가상 데이터를 hourly로 흘려넣고 위 자동화를 돌려보았습니다.

• 시트 입력 (가상 데이터):
• 4개 채널 × 30일 = 120행
• influencer_youtube: 일평균 비용 350만원, 노출 12만, 클릭 4.5천
• influencer_instagram: 일평균 180만원, 노출 8.5만, 클릭 3.1천
• internal_sms: 일평균 75만원, 노출 0, 클릭 1.25만
• offline_event: 30일 중 4일만 발생 (이벤트일), 회당 500만원
• 자동 업로드 사이클:
• 매일 06:00 KST 트리거
• 평균 처리 시간 (validation → upload → polling → MCP 검증 → 슬랙): 3분 40초
• 사람 개입: 30일 중 4회 (신규 채널 등록 1회, anomaly 감지 3회)

결과 확인 — MCP 자연어 질의:

"4월 한 달간 비통합 매체 합산 비용·노출·클릭을 표로. 통합 매체 (Meta·Google·TikTok)와 합쳤을 때 매체 믹스(%)를 cost 기준으로."

(가상 데이터 명시) 모든 수치는 시연용 샌드박스 데이터입니다.

9. 도입 시 주의사항

1. 공식 통합 채널은 self-serve upload 대상 아님 — 네이버 검색광고, Meta, Google Ads, TikTok 등은 에어브릿지가 자체 OAuth/공식 API로 연동을 제공합니다. self-serve로 올리려 하면 거부됩니다. 통합 가능한 매체부터 통합하고, 그 외만 self-serve로.
2. idempotent 설계 — 같은 (date, channel, campaign) 키는 마지막 upload가 덮어씁니다. 매일 어제 1일치만 올리지 말고 최근 7일을 매번 다시 올리는 패턴이 안전합니다 (지연 보정).
3. 데이터 삭제는 영(0) 업로드 — 잘못 올린 데이터를 빼려면 같은 키로 impressions=0, clicks=0, cost=0을 다시 올립니다. 이게 self-serve의 삭제 메커니즘입니다.
4. channel 이름 일관성 — 한 번 정한 채널명은 절대 바꾸지 마세요. 바꾸는 순간 이전 데이터가 다른 채널처럼 집계됩니다. 변경이 필요하다면 기존 채널 영(0) 업로드 → 새 채널명으로 re-upload 한 사이클이 필요합니다.
5. OS 이름은 정확히 Android / iOS — 케이스 센서티브. 잘못 쓰면 행이 분리됩니다.

10. Routines + Managed Agents 패턴 정리

이 흐름의 자동화 단계마다 적합한 패턴이 다릅니다 — 1편 §4에서 정리한 4가지 패턴 중 Routines 와 Managed Agents 가 핵심입니다. 각각의 운영 모델은 Anthropic Claude Code Routines과 Anthropic Managed Agents 개요를 참고하세요. 다음 표는 본 파이프라인에 두 패턴을 어떻게 배치하는지 정리한 것입니다.

핵심은 데이터·정책의 변화는 사람의 손을 거친다. 반복 작업은 기계의 손으로. 이게 1편에서 정리한 5가지 human-in-the-loop 원칙의 실전 적용입니다.

💡 회사 컨텍스트 주입의 실전 효과 — 1편 §5에서 정리한 회사별 컨텍스트의 4축 중 사업 캘린더 와 사내 의사결정 룰이 이 파이프라인의 anomaly 감지에 직결됩니다. 화장품 D2C라면 "올영 메가세일 주간(매달 셋째주)에는 SMS·메일 비용이 평소의 2~3배까지 정상" 이라는 룰을, 게임 D2C라면 "신규 패치 launch week에는 인플루언서 비용 스파이크 정상" 이라는 룰을 에이전트의 RAG 코퍼스에 박아두면, 같은 ±50% 비용 변동이라도 시즌 정상과 진짜 anomaly를 구분합니다. 이게 비싼 검색엔진 단계에서 진짜 자동화 단계로 넘어가는 분기점입니다.

11. CTA

비통합 매체가 매주 골치라면, 우리 팀의 그로스 스프린트에서 위 흐름을 1주 PoC + 2주 운영 안정화로 깔아드릴 수 있습니다. 첫 1주 안에 어제 비통합 매체 비용이 슬랙으로 자동 보고되는 상태를 만드는 게 목표입니다. 문의는 retn.kr/contact.

마치며

마케팅 자동화에서 완전 자동화는 환상입니다. 진짜 가치는 사람이 의사결정에 시간 쓸 수 있게 만드는 일 입니다. 에어브릿지의 Self-Serve API + MCP + LLM 에이전트 + cron 4가지를 묶으면, 마케터는 시트에 비용을 입력하고 anomaly를 confirm만 하면 됩니다. 나머지 일은 그 사이에 끝납니다.

3편 시리즈를 여기까지 읽어주셔서 감사합니다. 1편 클로드 코드 + 에어브릿지 MCP × API 자동화 청사진 과 2편 블로그 1편을 채널별 트래킹 링크 N개로 도 함께 봐주시면 청사진과 실전이 연결됩니다.

📚 더 읽어보기

• 구글 Meridian으로 마케팅 ROI / 증분(Incremental) 측정
• 채널 포화일 때 진짜 해야 할 일 — 증분을 만드는 스케일업
• 마케팅 대시보드 ROAS가 높은데 매출은 안 느나요? — 증분과 라스트터치
• AI 마케팅 분석: 브레이즈 캔버스 iROAS 19배 달성 사례
• Ghost 뉴스레터 자동화 — n8n + Mailgun으로 Sunset Policy 적용
• 메타 광고 MCP로 3년치 광고 데이터 분석

참고 - Airbridge, Self-Serve Data Upload (REST): https://help.airbridge.io/en/references/self-serve-data.md - Airbridge, 네이버 검색 광고 (공식 통합 가이드, schema 참고용): https://help.airbridge.io/ko/guides/naver-sa - Airbridge, Actuals Report (REST): https://help.airbridge.io/en/references/actuals-report.md

📝 이 글은 해당 세션 전에 사전 준비 & 프리모템(premortem)을 하면서 작성되었습니다.

본 글은 3편 시리즈의 2편입니다. 1편: 클로드 코드 + 에어브릿지 MCP × API 자동화 청사진 · 3편: 통합 안 된 매체 비용도 에어브릿지 대시보드에

TL;DR

• 블로그 글 1편을 발행하고 나면, 콘텐츠 마케터는 보통 카카오톡 공유용 링크 1개, 메일 뉴스레터용 링크 1개, SMS 캠페인용 링크 1개, 인스타그램 바이오용 링크 1개, 페이스북 공유용 링크 1개, 그리고 OG 이미지 1장을 만들기 위해 30분에서 2시간을 씁니다.
• 이 수작업 반복을 (클로드 코드 에이전트) → (GPT image-2 OG 생성) → (에어브릿지 REST API 트래킹 링크 N개 발급) → (에어브릿지 MCP 검증) → (슬랙 보고) 순으로 묶으면 30분이 30초로 줄어듭니다.
• 핵심은 에어브릿지 MCP만으로는 트래킹 링크 발급이 안 된다는 점. 발급은 에어브릿지 REST API의 일이고, 검증은 에어브릿지 MCP의 일입니다. 둘은 다른 책임을 가집니다.
• 네이밍 컨벤션, 오탈자, 트래킹 누락 점검도 같은 에이전트가 사전 검증합니다. 마케터는 최종 발행 승인만 누릅니다 — 1편에서 다룬 Human-in-the-Loop 디자인 원칙을 그대로 적용합니다.

📤 이 글 한 번에 공유하기 — 클로드 코드 + 에어브릿지 REST API + GPT image로 즉석 발급한 트래킹 링크입니다. 채널 blog_share, 캠페인 claude-code-og-image-airbridge-tracking-link-blog-automation_202604_blog_share, OG 이미지는 GPT Image 2 (high, 1536×1024). 클릭은 에어브릿지 actuals 리포트에 그대로 집계됩니다.

클로드 코드로 OG 이미지 만들고, 에어브릿지 API로 트래킹 링크 N개 발급한다

블로그 1편 발행 후 30분이 30초로 — 클로드 코드 에이전트가 OG 이미지 만들고 에어브릿지 REST API가 채널별 트래킹 링크 N개를 일괄 발급하는 30초 파이프라인.

demokr.ab180.co

1. 고질병을 다시 본다

저희 팀이 1편에서 정리한 8개 고질병 중, 콘텐츠 마케터가 매주 가장 많이 부딪히는 조합은 다음 셋입니다.

• 고질병 1 — 리포트 빌드·해석·공유의 일부분: "이 글이 어디서 가장 많이 읽혔는지" 측정하려면 채널별 링크가 분리돼야 함.
• 고질병 2 — 광고 매체 비교: "채널별 ROAS 측정"의 전제는 캠페인이 정확하게 분리돼 있어야 함.
• 고질병 8 — 네이밍 컨벤션 정합성 검수: 링크 수십 개 만들다 보면 오탈자, 트래킹 누락, 컨벤션 위반이 필연.

세 고질병의 공통 뿌리는 "링크 1개 만드는 데 컨벤션 + 오탈자 + 어트리뷰션 + OG 메타 + 호스팅을 동시에 챙겨야 한다" 입니다. 사람은 멀티태스킹을 못합니다. 그러나 LLM 에이전트는 합니다.

2. 자동화 흐름 한눈에

블로그 발행 (Ghost webhook 또는 cron)
   │
   ▼
[ 에이전트 1 — 메타 분석 ]
   - title, description, hero image, 주제 키워드 추출
   │
   ▼
[ 에이전트 2 — OG 이미지 생성 ]
   - GPT image-2로 시리즈 일관성 있는 이미지 1장
   - Ghost asset 또는 외부 호스트에 업로드, 영구 URL 확보
   │
   ▼
[ 에이전트 3 — 캠페인 네이밍 생성 ]
   - 컨벤션: {slug}_{YYYYMM}_{channel}
   - 오탈자·금지어·중복 검증
   │
   ▼
[ 에어브릿지 REST API ] POST /v1/tracking-links × N
   - 채널별로 N개 발급 (kakao, sms, email, instagram, facebook, etc.)
   - 각 링크에 동일 OG 이미지·타이틀·설명 임베드
   │
   ▼
[ 에어브릿지 MCP ] get_tracking_link으로 N개 검증
   - createdBy: API 확인
   - ogTag, deeplinkUrl, fallbackPaths 검증
   │
   ▼
[ 슬랙 + 노션 보고 ]
   - 슬랙 캔버스에 N개 링크 + OG 미리보기 + 14일 후 ROAS 리포트 예약

3. 1단계 — 블로그 메타 추출 + OG 이미지 생성

3-1. 블로그 메타 추출

Ghost CMS를 쓴다면 /ghost/api/admin/posts/:id로 글 본문·메타를 받을 수 있습니다. WordPress라면 REST API, Sanity·Contentful은 GraphQL. 어느 CMS든 LLM에 보낼 입력은 다음 5가지입니다.

• 제목
• 발행 슬러그
• 메타 디스크립션 (없으면 LLM이 본문 첫 단락에서 추출)
• 핵심 키워드 (없으면 LLM이 본문에서 5개 추출)
• hero image URL (있으면 OG 이미지의 시각 톤 참조용)

3-2. OG 이미지 생성

OpenAI 이미지 생성 모델은 브랜드 톤이 일관된 시리즈 이미지를 다음 시스템 프롬프트로 잘 만듭니다. 2026년 4월 현재 공식 GA 모델은 gpt-image-1, 차기 gpt-image-2(스냅샷 gpt-image-2-2026-04-21)는 출시되는 시점에 교체하면 됩니다. 이 문단의 코드는 모델명만 바꾸면 그대로 동작합니다. 프롬프트가 곧 새 코드 라는 카파시의 Software 3.0 관점을 OG 생성에 그대로 적용한 사례입니다.

// (가상 코드 — 실제 키와 호스팅은 조직 환경에 맞춤)
const ogPrompt = `
시리즈: 리텐션 인사이트
주제: ${title}
키워드: ${keywords.join(", ")}

스타일:
- 모바일에서도 가독 좋은 큰 타이포 (Pretendard, 24-32px 헤더 기준)
- 한국어 제목 명확하게 1줄, 부제 1줄까지
- 배경: 단색 + 1개 추상 그래픽 요소
- 색: 브랜드 모노크롬 (네이비 #0F1B2C / 라이트 #F4F6FA)
- 워터마크: 우측 하단 retn.kr
크기: 1200x630 (OG 표준)
`;

const res = await openai.images.generate({
  model: "gpt-image-1",   // 2026-04 GA. 차기 gpt-image-2 출시 시 한 줄 교체.
  prompt: ogPrompt,
  size: "1536x1024",      // OG는 후처리로 1200x630 크롭
  output_format: "png",
  n: 1,
  quality: "high"
});
const imageBuffer = Buffer.from(res.data[0].b64_json, "base64");

생성한 이미지는 Ghost CMS의 asset endpoint(/ghost/api/admin/images/upload)에 업로드해 영구 URL을 확보합니다. Ghost를 쓰지 않는다면 R2·S3·Bunny Stream 등 사내 자산 저장소에 올립니다.

⚠️ 유의 — 외부 LLM 게이트웨이에 원본 이미지 자체가 캐싱될 수 있습니다. 민감한 브랜드 자산이 들어간 hero image는 OG 생성 입력으로 주제 키워드만 보내는 편이 안전합니다.

💡 회사 컨텍스트 RAG 주입 — 우리 브랜드의 톤 가이드, 컬러 시스템, 타이포 가이드, 워터마크 룰을 사내 wiki·노션의 단일 문서로 정리해 두면, 에이전트가 OG 생성 직전에 그 문서를 RAG로 끌어와 시리즈 일관성 있는 이미지를 만듭니다. 1편 §5에서 정리한 회사별 컨텍스트의 4축 중 보고 대상별 톤·템플릿에 해당하는 영역입니다. 한 번 문서화해 두면 매주 발행되는 글마다 디자이너의 손을 거치지 않고도 일관된 OG가 나옵니다.

4. 2단계 — 캠페인 네이밍 + 컨벤션 검증

4-1. 컨벤션 룰 (예시)

캠페인: {slug}_{YYYYMM}_{channel}
- slug: 영문 소문자, 하이픈, 60자 이내
- channel: kakao, sms, email, instagram, facebook, web_share, qr_offline, partner_xxx
- ad_group: {channel}_{audience_segment}
- ad_creative: {channel}_{creative_type}_{variant}

4-2. LLM 에이전트가 수행하는 사전 검증

• 오탈자 검증: 슬러그·캠페인 이름이 표준 사전 단어 또는 자주 쓰는 약어와 Levenshtein 거리 1~2 이내인 경우 알림 (e.g. retetnion, recovery_capain 등)
• 금지어 검증: 회사 내부 코드네임, 미공개 제품명, 경쟁사명이 들어가 있으면 차단
• 중복 검증: 같은 슬러그의 같은 채널·같은 월 캠페인이 이미 발급돼 있는지 MCP list_tracking_links로 사전 조회. 중복이면 발급 차단 또는 _v2 접미사 자동 부여
• 링크 라우팅 누락 검증: deeplink URL의 path 부분이 실제 앱에 존재하는 라우팅인지, 웹 fallback URL이 200 응답을 주는지 사전 fetch

4-3. Human-in-the-loop 지점

이 검증을 통과하면 자동 발급. 실패하면 슬랙 채널 #growth-tracking-link-review에 멘션과 함께 사람 승인 버튼 (Slack interactive message). 마케터는 30초 안에 결정.

5. 3단계 — REST API로 트래킹 링크 N개 발급

채널 N개에 대해 동일 OG 메타와 브랜딩을 적용해 일괄 발급하는 패턴입니다.

const channels = [
  { name: "kakao", isReengagement: "OFF" },
  { name: "sms", isReengagement: "OFF" },
  { name: "email", isReengagement: "OFF" },
  { name: "instagram", isReengagement: "ON-FALSE" },  // UA 캠페인
  { name: "facebook", isReengagement: "ON-FALSE" },
  { name: "owned_blog_share", isReengagement: "OFF" }
];

const results = await Promise.all(channels.map(async (ch) => {
  const payload = {
    channel: ch.name,
    campaignParams: {
      campaign: `${slug}_${yyyymm}_${ch.name}`,
      ad_group: `${ch.name}_default`,
      ad_creative: `${ch.name}_og`
    },
    isReengagement: ch.isReengagement,
    deeplinkUrl: `myapp://blog/${slug}`,
    fallbackPaths: {
      ios: `https://retn.kr/blog/${slug}?utm_source=${ch.name}`,
      android: `https://retn.kr/blog/${slug}?utm_source=${ch.name}`,
      desktop: `https://retn.kr/blog/${slug}?utm_source=${ch.name}`
    },
    ogTag: {
      title,
      description,
      imageUrl: ogImageUrl
    }
  };

  const res = await fetch("https://api.airbridge.io/v1/tracking-links", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${TRACKING_LINK_API_TOKEN}`,
      "Content-Type": "application/json",
      "Accept-Language": "ko"
    },
    body: JSON.stringify(payload)
  });
  return { channel: ch.name, response: await res.json() };
}));

발급에 Tracking Link API Token을 권장합니다. 일반 API Token보다 권한이 좁아 만의 하나 노출되어도 피해 범위가 한정적입니다(트래킹 링크 발급 외 작업 불가).

(가상 코드 명시) 위 코드는 동작 원리 설명용입니다. slug, yyyymm, title, description, ogImageUrl, TRACKING_LINK_API_TOKEN은 실제 운영 환경에서 안전하게 주입해야 합니다.

6. 4단계 — MCP로 발급 검증

발급이 끝나면 그 자리에서 MCP로 검증합니다. 같은 호출 컨텍스트에서 생성과 검증을 분리하는 게 핵심입니다.

// MCP는 클라이언트(예: Claude Desktop, Claude Code, n8n LLM 노드)에서
// 자연어로 호출되거나, MCP 클라이언트 SDK로 직접 호출.
//
// 검증 항목 예시:
// - createdBy: "API" — REST API 발급자 추적
// - ogTag.imageUrl == 우리가 보낸 OG URL인가
// - deeplinkParams.deeplinkData.deeplinkUrl == 우리가 보낸 path인가
// - fallbackPaths == https 200 응답
// - 오탈자 LLM 재검증 (slug 안에 의도하지 않은 문자열 없는가)

검증 통과 → 슬랙·노션 자동 게시. 실패 → 마케터에게 사유 정리해 알림.

7. 5단계 — Routines로 정기 자동화

이 흐름을 매일 09:00에 자동으로 트리거하면 어제 발행된 글이 오늘 출근 전에 자산화 됩니다.

// 의사 코드
schedule.cron("0 9 * * *", async () => {
  const yesterdayPosts = await ghostApi.posts.browse({
    filter: `published_at:>${dayjs().subtract(1, "day").startOf("day").toISOString()}`
  });

  for (const post of yesterdayPosts) {
    await runAgent("blog-to-tracking-links", { postId: post.id });
  }
});

루틴 도구로는 다음 중 한 가지를 권합니다.

• Anthropic Claude Code Routines — 클로드 코드 환경 안에서 cron 또는 트리거 기반으로 작업 시퀀스를 정기 실행. 토큰·컨텍스트가 같은 에이전트에 묶여 있어 가장 단순.
• Anthropic Managed Agents — 사람이 위에서 제안 → 검증 → 승인 → 실행을 분리해 운영하는 모드. 발급처럼 돌이킬 수 없는 행동에 적합.
• n8n + LLM 노드 — 비개발자 친화, GUI로 흐름 수정 가능. Ghost 뉴스레터 자동화 사례에서 같은 패턴을 확인할 수 있습니다.
• Cloudflare Workers + Cron Triggers — 서버리스, 코드로 관리.
• OpenAI Assistants의 scheduled runs — 단일 LLM 콘솔 안에서 관리.

8. 결과 — 이 글을 위해 실제로 발급한 6개 트래킹 링크

이 글 자체를 데모 입력으로 두고 위 흐름을 끝까지 돌렸습니다. 본 글의 OG 이미지는 클로드 코드 ✕ OpenAI gpt-image-1 (high quality, 1536×1024) 로 생성한 결과이고, 6개 트래킹 링크는 에어브릿지 REST API로 발급한 뒤 에어브릿지 MCP로 검증한 진짜 측정 데이터 (가상 시연이 아님) 입니다.

8-1. 입력 메타

• 제목: 클로드 코드로 OG 이미지 만들고, 에어브릿지 API로 트래킹 링크 N개 발급한다
• 슬러그: claude-code-og-image-airbridge-tracking-link-blog-automation
• 캠페인 네이밍 컨벤션: {slug}_{YYYYMM}_{channel} → 예: ..._202604_email_newsletter
• OG 이미지: 본 글 상단에 표시된 Part 2 / 3 커버 (/content/images/2026/04/og-part2-tracking-links.png)
• Deeplink URL (앱): ablog://blog/spring-sale-2026 (가상 데모 path)
• Web fallback: https://retn.kr/{slug}/?utm_source={channel}

8-2. 발급된 6개 트래킹 링크 (2026-04-29 KST 17:06 발급)

참고 — kakao는 에어브릿지 integrated channel 이라 단축 도메인 abr.ge로 발급. 나머지 5개는 custom channel 이라 demokr.ab180.co 도메인으로 발급.

8-3. MCP 검증 결과 (샘플 1건 — email_newsletter)

get_tracking_link(link_id=490490250) 호출 응답에서 핵심 필드만:

6개 모두 동일한 패턴으로 검증 통과 — createdBy=API, ogTag 4필드, deeplinkUrl + 3개 fallback, campaign 컨벤션.

8-4. 사이클 타임

• 6개 채널 병렬 발급: 1초 미만 (실측 6개 호출 동시 처리)
• 채널당 평균 응답: 약 200~400ms
• MCP 단일 검증: 약 300ms
• 전체 파이프라인 (메타 추출 → OG 생성 → 6개 발급 → 검증) — 대부분의 시간이 OG 이미지 생성에 소요. gpt-image-1 quality: high로 1장 약 35초.

참고 — 위 수치는 본 글 발행 직전 실측한 진짜 측정값 입니다 (가상 데이터 아님). 단, 사용자별 네트워크·OpenAI 모델 부하·에어브릿지 베타 서버 부하에 따라 달라질 수 있습니다.

8-5. 비용

• 가장 큰 비용 항목은 OG 이미지 1장. gpt-image-1 high quality 1장 약 USD $0.04~$0.08 수준. standard quality로 떨어뜨리면 약 $0.02. 시리즈 일관성을 포기하지 않으면서 비용을 줄이려면 프롬프트 + 시드 고정 전략 권장.
• 트래킹 링크 발급은 에어브릿지 플랜 한도 내에서 무료. rate limit은 50 link/sec 이라 6개 정도는 여유.

9. 도입 시 주의사항

1. 토큰 분리 — Tracking Link API Token만으로 발급. 일반 API Token은 reporting·setup 용도. 토큰 노출 시 영향 범위가 다릅니다.
2. OG 이미지 크기·해상도 — 카카오는 1200×630 비율, 인스타 스토리는 1080×1920, 메일 인박스 미리보기는 800×600 권장. 멀티 사이즈 자동 생성을 권합니다.
3. deeplink URL 검증 — 앱이 해당 path로 라우팅이 등록되어 있는지 사전에 SDK 트러블슈팅 도구로 검증. 등록 안 된 path로 발급하면 사용자가 빈 화면을 봅니다.
4. ON-FALSE vs OFF — UA 캠페인이라면 reengagement를 ON-FALSE로. 잘못 설정하면 기존 사용자의 어트리뷰션이 새 캠페인으로 잘못 잡힐 수 있습니다.

10. 다음 편 예고

3편은 통합 안 된 매체 비용을 다룹니다. 인플루언서 마케팅, 자체 SMS, 오프라인 행사처럼 에어브릿지에 공식 연동이 없는 채널의 비용·노출·클릭을 Google Sheet로 관리하면, 매일 새벽 자동으로 CSV 변환 → 에어브릿지 API multipart upload → 에어브릿지 MCP가 actuals 리포트로 검증 → 슬랙 보고. 고질병 5·1을 동시에 해소하는 구조입니다. 3편 바로가기

마치며

콘텐츠 마케터의 "발행 후 30분 수작업 반복" 은 의지로 풀리지 않습니다. 컨벤션을 강요하는 사규로도, 워크플로 매니저로도 풀리지 않습니다. 멀티태스킹은 LLM에게 맡기고, 사람은 의사결정만 남기세요. 우리 팀이 그리는 AI Augmentation의 한 단면입니다.

질문은 retn.kr/contact 또는 LinkedIn DM 환영합니다.

📚 더 읽어보기

• 클로드 코드 + 에어브릿지 MCP × API 자동화 청사진 (1/3)
• 통합 안 된 매체 비용도 에어브릿지 대시보드에 — Self-Serve Cost Upload (3/3)
• 메타 광고 MCP로 3년치 광고 데이터 분석
• 블로그 키워드 리서치 자동화 — 네이버 검색광고 MCP 오픈소스
• 완벽한 도구를 기다리지 마세요 — AI 시대, 나만의 OS를 만드는 법
• 비개발자의 Claude Code 삽질기 — 그로스 전문가가 2주 만에 엔지니어링까지

참고 - Airbridge, Create Tracking Link (REST): https://help.airbridge.io/en/references/tracking-link.md - OpenAI, Images Generations API (gpt-image-1 GA / gpt-image-2 차기): https://platform.openai.com/docs/api-reference/images - Ghost, Admin API — Posts: https://ghost.org/docs/admin-api/#posts

📝 이 글은 해당 세션 전에 사전 준비 & 프리모템(premortem)을 하면서 작성되었습니다.

본 글은 3편 시리즈의 1편입니다. 2편: 클로드 코드로 OG 이미지 만들고, 에어브릿지 API로 트래킹 링크 N개 발급하기 · 3편: 통합 안 된 매체 비용도 에어브릿지 대시보드에 — Self-Serve Cost Upload + 클로드 코드 자동화 실전

TL;DR

• 어트리뷰션 SaaS 에어브릿지(Airbridge — 운영사 AB180) 고객사 마케터 약 50명을 만나 고질병을 8개 테마로 정규화했더니, 거의 모두가 "수동 다운로드 → 포맷 정리 → 해석 → 공유" 또는 "네이밍 컨벤션 정합성 검수" 두 축으로 수렴했습니다.
• 클로드 코드(Claude Code) + 에어브릿지 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)는 분석·진단·QA에 강하고, 에어브릿지 REST API는 생성·수집·자동화에 강합니다. 둘은 대체재가 아니라 보완재입니다.
• 둘을 묶어 routines(루틴) 또는 managed agents(매니지드 에이전트)로 감싸면 마케터가 매주 반복하던 수작업 반복 5개 중 4개는 사람 손을 떠납니다.
• 단, 모든 일을 자동화하면 안 됩니다. 의사결정·조직 정치·맥락 판단은 사람이 가져야 합니다. 본 글은 어디까지 기계에게 맡기고 어디서부터 사람을 다시 끌어들일지(human-in-the-loop)에 대한 설계 원칙도 함께 다룹니다.

📤 이 글 한 번에 공유하기 — 클로드 코드 + 에어브릿지 REST API + GPT image로 즉석 발급한 트래킹 링크입니다. 채널 blog_share, 캠페인 claude-code-airbridge-mcp-api-agentic-marketer-blueprint_202604_blog_share, OG 이미지는 GPT Image 2 (high, 1536×1024). 클릭은 에어브릿지 actuals 리포트에 그대로 집계됩니다.

클로드 코드 + 에어브릿지 MCP × API로 마케터 일상을 다시 설계한다 — Agentic 자동화 청사진

어트리뷰션 SaaS 에어브릿지 워크샵에서 정규화한 8개 고질병을 클로드 코드 + 에어브릿지 MCP·API·Routines·Managed Agents 4단계로 매핑한 자동화 청사진.

demokr.ab180.co

1. 왜 지금 이 글인가

2026년 4월 워크샵 이후, 어트리뷰션 SaaS 에어브릿지(Airbridge — 운영사 AB180) 고객사 대상 비공개 워크샵에서 그로스 마케터·PM을 약 50명 단위로 만났습니다. 워크샵의 핵심 도구는 클로드 코드(Claude Code), 그리고 에어브릿지 MCP 베타 와 에어브릿지 REST API 였습니다.

에어브릿지가 Airbridge AI 라는 이름으로 MCP 파일럿을 공식 런칭한 직후라 마케터들의 관심은 컸습니다. 한편 "내가 진짜 자동화하고 싶은 건 뭐지?" 에 대한 답은 의외로 정형화되어 있었습니다. 사전 설문에서 "워크샵에서 무엇이 풀리길 원하는가" 라고 물었더니 답이 길게도 짧게도 돌아왔습니다. 그 답들을 익명화해 정규화하니 다음 8개 테마로 수렴합니다.

8번은 사전 설문에 직접적으로 적힌 항목은 아니지만, 1·2·3번 고질병의 근본 원인에 가깝습니다. 캠페인 네이밍이 무너지면 리포트 그루핑이 무너지고, 매체 비교가 무너지고, 어트리뷰션이 무너집니다. 그래서 8번을 명시적 트랙으로 끌어올렸습니다.

2. 에어브릿지의 MCP와 REST API는 같은 일을 하지 않는다

워크샵 이후 다시 확인한 한 가지: 마케터들이 "클로드 코드로 뭘 할 수 있나요?" 와 "에어브릿지 API는 어떻게 쓰는 거죠?" 를 별개의 질문으로 던졌습니다. 그러나 둘은 같은 끝점을 두고 다른 길을 갑니다.

2-1. 클로드 코드 + 에어브릿지 MCP — 분석·진단·QA의 도구

Anthropic이 정의하고 OpenAI·Google이 잇따라 채택한 MCP(Model Context Protocol) 는 모델이 외부 시스템의 도구를 호출할 수 있게 하는 표준 프로토콜입니다. 마케터 입장에서는 "클로드 데스크탑이나 클로드 코드(Claude Code)에 에어브릿지 커넥터를 붙였더니 자연어로 리포트를 부른다" 정도로 체감됩니다.

MCP가 잘하는 일은 다음과 같습니다.

• 다단계 분석: "지난 14일 매체별 ROAS, 직전 14일 대비 변화, ±30% 이상치 매체 별도 섹션" 같은 복합 요청을 한 번에 처리.
• 메타데이터→리포트 체인: 메트릭 키·그룹바이 키를 먼저 조회한 뒤 본 리포트를 호출. 사용자가 SQL이나 API 스펙을 몰라도 됨.
• 진단 모드 부트스트랩: "iOS purchase 이벤트가 안 들어와요" 같은 모호한 신호를 받아 트러블슈팅 가이드를 자동으로 따라가며 가설을 좁힘.
• 자연어 검색: 대시보드 페이지·도움말 가이드를 키워드로 즉시 찾음.

에어브릿지 MCP가 못 하는 일도 있습니다. 새 자원을 만드는 일, 외부 데이터를 시스템에 밀어넣는 일 입니다. 적어도 2026년 4월 현재의 에어브릿지 MCP 베타에는 트래킹 링크 생성, 서버-투-서버 이벤트 송신, 비용 데이터 업로드, raw export 요청 같은 쓰기성 동작이 없습니다.

2-2. 에어브릿지 REST API — 생성·수집·자동화의 도구

에어브릿지 REST API는 그 반대입니다. 트래킹 링크를 일주일에 100개씩 발급하고, 인하우스 백엔드에서 발생한 결제 이벤트를 서버에서 직접 송신하고, 통합되지 않은 인플루언서 마케팅 비용을 CSV로 밀어넣고, 31일치 raw 데이터를 자동으로 받아 BI에 붙입니다. 사람의 손이 닿지 않는 자동화 백본입니다.

API가 잘 못하는 것도 있습니다. 모호한 자연어 요청을 해석하는 일. API는 정확한 페이로드를 요구합니다. "ROAS 떨어진 매체 좀 보여줘" 를 받아 metric/groupBy 키 매핑까지 해주진 않습니다. 그 일은 클로드 코드 같은 LLM 에이전트의 몫입니다.

2-3. 매트릭스로 정리

3. 고질병 → 솔루션 매핑

위 8개 고질병을 MCP·API·둘의 조합·routines/managed agents 4단계로 매핑하면 다음과 같습니다.

이 매핑이 글의 핵심입니다. 고질병 1·8이 마케터의 시간을 가장 많이 잡아먹는 두 축이고, 둘 다 에어브릿지의 MCP + REST API 조합으로 거의 사람 손이 닿지 않게 만들 수 있습니다.

4. Agentic Workflow의 4가지 패턴

자동화 단계마다 적합한 패턴이 다릅니다. 워크샵 회고에서 다음 4가지로 정리했습니다.

패턴 A — 단발성 코파일럿 (One-shot copilot)

사용자가 채팅으로 한 번 묻고 답을 받는 흐름. "지난주 매체별 ROAS 알려줘" → MCP가 metadata→report 체인 호출 → 결과 보여주기. 도구: Claude Desktop + MCP 커넥터.

패턴 B — 백엔드 자동화 스크립트 (Backend automation script)

사람이 트리거하지 않고 cron 또는 이벤트 핸들러로 돌아가는 흐름. 사용자에게 인터페이스 노출 안 됨. 도구: GitHub Actions, Cloudflare Workers, n8n, 자체 백엔드. API only.

패턴 C — Agentic Routines (정기 에이전트 실행)

LLM 에이전트를 cron 또는 트리거로 깨워 작업 시퀀스를 수행. 단순 스크립트와 다른 점은 LLM이 중간에 의사결정을 함. "매주 월요일 09:00에 깨어나서 매체별 효율 변화 측정. 효율 급락 매체 발견 시 가설 3개 작성, 슬랙에 멘션." 도구: Anthropic의 Claude Code Routines (스케줄 + 트리거 기반 에이전트 실행), Claude API의 batch + tool use, OpenAI Assistants의 scheduled runs, n8n + LLM 노드.

패턴 D — Managed Agents (관리형 에이전트, 사람이 위에서 감시)

패턴 C와 유사하나 human-in-the-loop가 더 강한 형태. 에이전트가 작업 제안을 하고 사람이 승인해야 행동. 마케팅에서 이 패턴이 가장 안전. "트래킹 링크 50개 일괄 생성을 제안합니다. 네이밍 컨벤션 검증 통과. 승인 시 발급." — Anthropic이 정리한 Managed Agents 개요에 운영 패턴·보안 모델이 잘 정리돼 있습니다. 에이전트가 제안 → 검증 → 승인 → 실행의 4단계로 분리되어, 돌이킬 수 없는 행동은 사람이 명시적으로 결재하게 합니다.

5. 회사별 컨텍스트를 명시지화하라 — 자동화의 진짜 ROI는 여기서 나온다

대다수 마케터가 AI 자동화를 처음 시도할 때 기성 LLM에 그냥 물어보는 사용 패턴에 머뭅니다. 결과물이 무난해 보여도 우리 회사의 의사결정 패턴, 매출 패턴, 시즌 패턴, 보고 톤이 빠져 있어서 실제로는 사람이 다시 매만져야 하는 초안에 그칩니다. 진짜 자동화 가치는 암묵지(tacit knowledge)를 명시지(explicit knowledge)로 끌어내고 에이전트에 주입할 때 나옵니다. 안드레이 카파시(Andrej Karpathy)가 YC AI Startup School 2025 키노트 Software is Changing (Again)에서 정리한 Software 3.0 표현을 빌리자면, 우리는 더 이상 코드를 쓰는 것이 아니라 프롬프트와 컨텍스트를 쓰는 시대로 들어왔고, 그 컨텍스트의 품질이 곧 자동화의 ROI를 결정합니다.

5-1. 회사별 컨텍스트의 4축

다음 4축을 문서화하지 않은 채 AI를 도입하면 일반 답변 이상이 나오지 않습니다.

1. 사업 캘린더 — 화장품 D2C라면 올영 세일(매달 셋째주), 광군제(11/11), 블랙프라이데이(11월 4주차), 뷰티 페어(주요 격월 1·2주차). F&B라면 발렌타인·빼빼로·연말 선물 시즌. 게임이라면 대규모 패치·시즌 페스티벌·외부 IP 콜라보 일정. 이 캘린더를 노션 또는 사내 wiki의 단일 문서로 정리하고 RAG(Retrieval-Augmented Generation)로 에이전트에 주입하면, "왜 4월 셋째주 ROAS가 평소보다 60% 높았지?" 같은 질문에 "올영 메가세일 영향이며 실제로는 증분(incremental) 매출보다 캐니벌라이제이션(자기잠식)이 큽니다" 까지 자동 해석합니다. 시즌 스파이크와 비시즌 베이스라인을 분리하는 작업은 구글 Meridian 같은 미디어 믹스 모델링(MMM) 도입과 결합하면 더 강해집니다 — 시즌 캘린더가 곧 MMM의 외생 변수(exogenous regressors) 로 들어가는 셈입니다.
2. 카테고리·SKU별 패턴 — 같은 회사 안에서도 카테고리마다 ROAS·LTV·재구매 주기가 다릅니다. 뷰티 D2C에서 기능성 스킨케어는 D90 재구매 75%, 색조는 D90 재구매 35%, 향수는 D180 재구매 20% 등(가상 수치). 이 패턴을 명시지화하면 에이전트가 카테고리 간 ROAS 비교를 그냥 하지 않고 재구매 주기 가중치를 적용한 LTV 기준으로 비교합니다.
3. 보고 대상별 톤·템플릿 — 부장님은 표 한 장, 본부장은 차트 + 한 줄 요약 + 권고 액션 3개, CFO는 마진 기반 ROI + cash payback, 대표님은 동종업 대비 백분위. 같은 데이터를 4가지 양식으로 자동 출력하면, 매주 마케터가 같은 데이터의 4번째 가공에 쓰던 시간이 0이 됩니다.
4. 사내 의사결정 룰과 가드레일 — "D7 ROAS 80% 미만이면 광고 끈다", "신규 캠페인은 launch 후 72h는 수정 금지", "브랜드 키워드는 항상 1순위 입찰 유지", "신규 채널은 월 100만원 캡 안에서 학습" 같은 결정 임계값을 명시지화하면 에이전트의 권고가 회사의 실제 운영 룰과 충돌하지 않습니다.

이 4축은 최소 한 달의 인터뷰·문서화가 필요합니다. 이걸 마케팅 팀의 새로운 정규 업무로 정의해야 합니다. 한 번 잘 만들어두면 매주 발생하는 자동화 ROI는 컴파운드됩니다.

5-2. 명시지화는 학문적 베스트 프랙티스 — Cognitive Task Analysis

위 4축을 문서화한다는 말은 단순한 문서화가 아닙니다. 학문적으로 30년 이상 다듬어진 방법론이 있습니다 — Cognitive Task Analysis (CTA, 인지 작업 분석). CTA는 전문가의 머릿속에 있는 암묵지를 명시지로 끌어내기 위한 인터뷰·관찰·verbal report 분석 기법의 묶음입니다 (Global Cognition 개요, Brown · Power · Gore (2024) — Sage Organizational Research Methods).

CTA의 표준 단계는 셋입니다.

1. 지식 추출 (Elicitation) — 가장 많이 쓰이는 기법: Critical Decision Method (실제 결정 사례 회고), Think-Aloud Protocol (작업하면서 말로 풀기), Concept Mapping (도메인 개념 그래프), 팀 커뮤니케이션 분석
2. 데이터 분석 (Analysis) — verbal report 전사 → 코딩 → 패턴 추출
3. 지식 표현 (Representation) — 의사결정 트리·룰 기반 가드레일·체크리스트로 구체화

베테랑 마케터일수록 자기가 어떻게 결정하는지 설명하지 못합니다. 그래서 직접 왜 이 캠페인을 유지·중단하는지 묻는 것보다, 지난 30일 동안 결정 5건을 함께 회고하면서 그때 본 시그널·기각한 시그널·결정 임계값을 끌어내는 편이 빠릅니다. 비기술 도메인에 CTA를 적용한 좋은 글로 Cedric Chin의 An Easier Method for Extracting Tacit Knowledge를 추천합니다.

실전 적용 — 3주짜리 마케터 CTA 인터뷰 트랙:

• 1주차 — 베테랑 마케터 1명이 지난 30일 캠페인 의사결정 5건을 회고. 주니어 1명 + 그로스 코치 1명이 듣고 그때 본 시그널 / 기각한 시그널 / 결정 임계값을 화이트보드에 정리.
• 2주차 — 1주차 정리본을 룰·임계값·우선순위 트리 로 변환. "D7 ROAS < 80%면 끈다" 같은 임계값을 숫자로 박음.
• 3주차 — 변환한 명시지를 클로드 코드 에이전트 RAG 코퍼스 로 옮기고, 같은 캠페인 의사결정을 에이전트와 베테랑이 평행으로 시뮬레이션. 차이점만 다시 회고.

이걸 마케팅 팀의 새 정규 업무로 박으면, 6개월 뒤 그 회사의 마케팅 의사결정 자동화는 다른 회사의 같은 자동화와 절대 같지 않은 출력을 냅니다.

5-3. Best Practice를 에이전트에 주입한다

마케터가 현장에서만 아는 룰이 있습니다.

• Day 1 ROAS < 30%면 Meta는 크리에이티브 wearout 의심. frequency·CTR 같이 봐야 한다. 이 의사결정 흐름은 메타 광고 소재 교체 의사결정 프레임워크 — Kill·Trim·Protect·Promote에 정리되어 있습니다.
• 신규 install 비중 90% 넘는 매체는 retention loop가 누락됐을 가능성. 리타게팅 누락 또는 어트리뷰션 윈도우 짧게 설정
• ROAS 분모는 매체별로 click 시점인지 install 시점인지 통일해야 함. 안 통일하면 매체 비교 무의미
• 비통합 매체의 비용은 click·impression이 0이라도 cost는 양수로. 0으로 올리면 dashboard ROAS가 ∞로 폭주

이런 룰을 에이전트의 system prompt + RAG 코퍼스에 넣으면, 에이전트의 모든 출력이 자동으로 이 가드레일을 지킵니다. 베스트 프랙티스를 매번 사람이 다시 가르칠 필요가 없어집니다. 앤드류 응(Andrew Ng)이 AI Agent의 핵심 차별화는 도메인 지식 주입이라고 강조한 이유입니다.

5-4. 시간 많이 드는 EDA를 에이전트가 대신한다

탐색적 데이터 분석(EDA, Exploratory Data Analysis)은 그 자체가 일주일짜리 작업입니다.

• cohort split: 4월 1·2·3주차 신규 install 사용자 retention 곡선 비교
• 변수 간 correlation: 특정 ad_creative와 D7 ROAS 상관, OS·디바이스·시간대별 분산
• outlier 탐지: 평균 ±2σ 벗어난 캠페인·요일·창작 세트
• 가설 생성·기각·남기기: "4주차 ROAS 하락은 weekend 비중 증가 때문" 가설을 자동 생성하고 데이터로 기각·확정

이 모든 단계를 클로드 코드 에이전트가 raw export → pandas/duckdb 처리 → 통계 검정 → 자연어 보고로 자동 처리합니다. 우리 팀 관측 기준 (가상 데이터, 단일 분석가 비교) 일주일짜리 EDA 사이클이 30분~1시간 사이로 압축됩니다. 사람은 가설의 비즈니스 의미를 판단하는 데 시간을 씁니다. 왜?를 묻는 능력만 사람의 영역에 남습니다. (구조 적용 사례는 AI 에이전트 7개로 시니어 7명 효과를 낸 비결 참고.)

5-5. 교차 분석 자동화 — 4축 grid가 인사이트를 만든다

매체별 ROAS만 보면 공기가 빠진 분석입니다. 진짜 인사이트는 4축 교차에서 나옵니다.

5 × 7 × 3 × 3 = 315개 셀 grid. 사람은 절대 손으로 안 합니다. 클로드 코드 에이전트는 에어브릿지 raw export 한 번으로 grid를 채우고, "Meta × 주말 × UGC × cold가 평균 대비 ROAS +180%, 단 conversion volume이 작아 statistically significant 아님" 같은 결과를 자동 추출합니다. 그 다음 사람은 이 셀을 키울지만 결정합니다.

5-6. 종합 — 컨텍스트가 곧 차별화

자동화의 가치 사슬은 다음 3단계로 정리됩니다.

1. 원시 LLM — 일반 답변. 사람이 다시 가공. ROI 낮음
2. 기성 MCP 연결 — 도메인 데이터 접근 가능. 그러나 우리 회사 컨텍스트 없음. ROI 중간
3. 우리 회사의 4축 컨텍스트 + best practice + EDA·교차 분석 자동화 — 우리 마케터의 암묵지가 시스템에 박힘. ROI 컴파운드

3단계까지 가야 자동화 라는 말의 의미가 달라집니다. 그 전까지는 비싼 검색엔진에 가깝습니다.

6. Human-in-the-Loop 디자인 원칙

마케팅 자동화에서 어디까지 자동화할 것인가는 곧 어디서부터 책임을 사람이 지는가를 정의하는 일입니다. 우리 팀이 Human In The Lead — A2A에 두 번 걸린 날 에서 다룬 사고처럼, 사람을 루프 안에서 도구로 두지 말고 맨 위에서 결정자로 두어야 합니다. 다음 5가지 원칙을 권합니다.

1. 자동화 후 되돌릴 수 없는 행동은 사람이 승인: 트래킹 링크 수정(deeplink 라우팅 변경 등)은 운영 앱이라면 무조건 사람 승인. 신규 발급은 컨벤션 검증 통과 시 자동.
2. 외부 인지에 영향 주는 행동은 사람이 승인: 슬랙 멘션 작성은 자동, 그러나 유관 부서장에게 전달되는 인사이트 보고는 사람 한 번 검토.
3. 데이터 정합성에 영향 주는 행동은 사람이 승인: 비용 데이터 업로드 시 신규 채널 등록·삭제는 사람 승인. 동일 채널의 정기 동기화는 자동.
4. 모델 환각 위험이 큰 영역은 사람이 검증: 어트리뷰션 결과 해석, 어떤 캠페인이 왜 작동했는가에 대한 LLM 가설은 데이터로 한 번 더 검증.
5. 임계값을 명시: "ROAS ±30% 변동 시 사람 알림" 같은 룰은 코드에 박아놓고, 룰 변경은 PR 리뷰. 모호한 자율성을 주지 말 것.

7. 다음 편 예고

다음 두 편에서는 위 매트릭스를 실제로 동작하는 코드로 보여드립니다.

• 2편 — 클로드 코드로 OG 이미지 만들고, 에어브릿지 API로 트래킹 링크 N개 발급한다: 블로그 글 1편이 발행되면 클로드 코드 에이전트가 메타를 분석하고, GPT image-2로 OG 이미지를 생성한 뒤, 에어브릿지 REST API로 채널별 트래킹 링크 N개를 일괄 발급하고, 에어브릿지 MCP로 검증한 뒤 슬랙으로 보고합니다. 고질병 1·2·8을 동시에 해소합니다.
• 3편 — 통합 안 된 매체 비용도 에어브릿지 대시보드에 (Self-Serve Cost Upload): 인플루언서 마케팅·자체 SMS·오프라인 행사 비용 같은 자체 매체를 Google Sheet에서 관리하면, 매일 새벽 클로드 코드 루틴이 CSV 변환 → 에어브릿지 REST API multipart upload → 에어브릿지 MCP가 actuals 리포트로 검증 → 슬랙 보고. 고질병 5·1을 동시에 해소합니다.

8. 도입을 고민 중이라면

이 청사진은 한 번에 다 깔 필요 없습니다. 우선순위는 해당 조직의 가장 큰 시간 도둑입니다. 본 시리즈를 다 읽은 뒤에도 결정이 어렵다면, 우리 팀이 그로스 스프린트 형식으로 동행해 드립니다. 첫 1주는 고질병 진단, 둘째 주는 1개 고질병의 완전 자동화 PoC, 셋째 주는 routines/managed agents 운영 안정화. 문의는 retn.kr/contact.

마치며

약 50명의 마케터에게서 모은 고질병을 정규화하니, 기술이 부족해서가 아니라 일이 잘게 잘려 있어 사람의 시간을 빨아먹는다는 인상이 가장 강했습니다. MCP는 이미 자연어 인터페이스를 마케터에게 가져다줬고, REST API는 자동화 백본을 제공해온 지 오래입니다. 두 도구를 조합해 routines/managed agents로 감싸면 사람은 해석·승인·정치에 시간을 쓸 수 있습니다. 이게 우리 팀이 그리는 AI Augmentation (AI를 곁에 두고 사람의 능력을 확장하는 운영 모드)입니다.

다음 편에서 실전 코드로 만나뵙겠습니다.

📚 더 읽어보기

• 구글 Meridian으로 마케팅 ROI / 증분(Incremental) 측정
• 채널 포화일 때 진짜 해야 할 일 — 증분을 만드는 스케일업
• 마케팅 대시보드 ROAS가 높은데 매출은 안 느나요? — 증분과 라스트터치
• AI 에이전트에게 사업을 맡기는 대표가 놓치는 Human In The Lead
• AI 에이전트 7개로 시니어 7명 효과를 낸 비결
• 메타 광고 MCP로 3년치 광고 데이터 분석한 이야기

(가상 데이터 명시) 본 글에 등장하는 ROAS·CPI·매체별 비교 수치는 워크샵 데모 환경(샌드박스 앱)에서 측정한 값을 정규화한 참고 수치입니다. 실제 고객사 데이터가 아닙니다.

참고 - Anthropic, Model Context Protocol Specification: https://modelcontextprotocol.io/ - Anthropic, Connect Claude Code to tools via MCP (한국어): https://code.claude.com/docs/ko/mcp - Airbridge, Stop Searching for Complex Marketing Data — Airbridge AI MCP Pilot Launch: https://www.airbridge.io/blog/airbridge-ai-mcp-pilot-launch - Airbridge, MCP Beta Guide: https://help.airbridge.io/en/guides/mcp - Airbridge, API Reference Introduction: https://help.airbridge.io/en/references/introduction

리더십은 상대를 내 뜻대로 움직이는 기술이 아니라, 상대가 자기 일을 자기 이야기로 받아들이게 만드는 설계입니다. 아주대학교 김경일 교수님의 리더십 강의를 들으며 가장 크게 남은 문장은 이것이었습니다. 한국 조직에서 사람은 “좋은 말”보다 “내가 이 일의 주인공이라고 느끼는 순간”에 더 잘 움직입니다.

TLDR

• 한국인은 주체성이 강한 문화권에 속합니다. 그래서 “시키는 대로 해”보다 “네가 주인공이야”라는 언어에 더 강하게 반응합니다.
• 멘토링이 실패하는 이유는 멘토가 계속 주인공으로 남기 때문입니다. 멘티가 자기 문제의 주인공이 되어야 조언이 들어갑니다.
• 과정 칭찬과 결과 피드백은 분리해야 합니다. “한 달이나 했는데 이것밖에 안 돼?”는 시간과 노력을 같이 무너뜨립니다.
• 일로 만난 관계에서는 정서적 지지보다 기능적 지지를 먼저 주는 편이 더 안전합니다. “어떤 일이야?”보다 “4시간은 가능해”가 먼저일 때가 있습니다.
• 성공한 리더일수록 자기 성공은 기술하고, 자기 실패는 설명해야 합니다. 후배는 선배의 성공담보다 실패를 해석하는 방식을 배웁니다.

1. 왜 멘토링이 안 먹히는가

멘토링이 안 먹히는 핵심 이유는 멘토가 계속 이야기의 주인공으로 남기 때문입니다. 멘토가 “내가 해봐서 아는데”로 시작하면, 조언의 질과 무관하게 멘티는 자기 문제를 빼앗겼다고 느낄 수 있습니다.

김경일 교수님은 강의에서 한국 사람의 강한 “주인공 의식”을 반복해서 설명했습니다. 한국인은 내가 모르게 일이 진행되는 것을 불편해하고, 내 뜻과 무관하게 결정되는 상황에 민감합니다. 스타트업 팀원, 창업자, 임원, 멘티 모두 마찬가지입니다. 상대가 주체성을 잃는 순간 조언은 도움보다 통제로 들립니다.

이 관점에서 보면 리더십의 질문이 바뀝니다. “어떻게 설득할까?”가 아니라 “이 사람이 자기 문제의 주인공이라고 느끼게 하려면 어떤 언어를 써야 할까?”가 되어야 합니다.

관련해서 AI 시대의 조직 리더십은 이미 한 번 다룬 적이 있습니다. 핵심 인재가 조직에 남는 이유를 매일 만들어야 한다는 관점은 AI 시대 리더십 글과도 연결됩니다.

2. 상대의 시선으로 먼저 묘사하세요

상대를 주인공으로 만드는 첫 번째 방법은 상대의 시선으로 상황을 묘사하는 것입니다. 리더가 정답을 먼저 말하면 리더가 주인공이 되지만, 상대가 보고 있는 장면을 먼저 말하면 상대가 주인공으로 남습니다.

예를 들어 의사가 “이건 전문가가 내린 정확한 판단입니다”라고 말하면 의사가 주인공입니다. 반대로 “부모님도 젊으셨을 때 이 문제로 많이 힘드셨을 거예요”라고 말하면 환자의 삶이 주인공이 됩니다. 같은 전문성이더라도 상대가 자기 이야기 안에서 받아들일 수 있게 됩니다.

스타트업 멘토링도 같습니다. “이 시장은 이렇게 봐야 합니다”보다 “지금 대표님 입장에서는 이 숫자가 가장 불안하게 보이실 것 같습니다”가 먼저입니다. 전자는 진단이고, 후자는 상대의 시선 안으로 들어가는 일입니다.

3. 시간과 노력은 결과와 분리해서 인정하세요

한국 조직에서 피드백이 무너지는 순간은 시간과 노력을 결과와 함께 비웃을 때입니다. “한 달이나 이 프로젝트에 올인했는데 성과가 이것밖에 안 나와?”라는 말은 결과만 지적하는 것이 아니라, 그 사람이 쓴 시간 전체를 무의미하게 만듭니다.

김경일 교수님은 게임이 사람을 몰입시키는 이유를 “내가 들인 시간과 노력을 비웃지 않기 때문”이라고 설명했습니다. 게임은 졌더라도 내가 얼마나 시도했고, 어디까지 갔고, 무엇을 쌓았는지를 계속 보여줍니다. 그래서 뇌는 고된 일을 하고 있어도 몰입을 유지합니다.

조직 피드백도 같은 원리로 설계해야 합니다.

• “한 달 동안 이 프로젝트에 올인한 것은 평가에 반드시 반영하겠습니다.”
• “다만 결과가 이 수준인 것은 별도로 아주 심각하게 봐야 합니다.”

이 두 문장을 분리하면 사람은 무너지지 않고 다시 시도할 수 있습니다. 반대로 시간과 결과를 한 문장으로 묶으면, 다음 도전의 에너지가 사라집니다.

4. 일 관계에서는 기능적 지지를 먼저 주세요

일로 만난 관계에서는 기능적 지지가 먼저일 때가 많습니다. 상대가 시간을 요청했을 때 “무슨 일이야, 형이라고 생각하고 다 말해봐”보다 “4시간은 가능해. 5시간은 어려워. 사유는 안 물을게”가 더 안전할 수 있습니다.

이 말은 차갑게 굴라는 뜻이 아닙니다. 직장 관계에서는 내가 무엇을 해줄 수 있고, 어디까지 가능한지가 먼저 명확해야 상대가 안심합니다. 정서적 지지는 그다음에 쌓아도 늦지 않습니다. 반대로 기능적 한계가 불명확한 상태에서 감정적으로만 가까워지면, 나중에 더 어색한 관계가 됩니다.

리더가 팀원에게 줄 수 있는 기능적 지지는 생각보다 구체적입니다.

• 시간을 확보해주는 것
• 우선순위를 정리해주는 것
• 책임 범위를 명확히 해주는 것
• 방어막을 쳐주는 것
• 성과 기준을 사전에 합의해주는 것

이 다섯 가지가 먼저 서면 정서적 대화도 훨씬 안전해집니다.

5. 성공은 기술하고 실패는 설명하세요

성공한 리더가 후배에게 진짜로 줄 수 있는 것은 성공담이 아니라 실패를 해석하는 방식입니다. 김경일 교수님은 강의 후반부에서 “당신의 성공은 기술하고, 당신의 실패는 설명하라”는 문장을 소개했습니다.

성공을 설명하기 시작하면 주인공은 다시 리더가 됩니다. “내가 이렇게 판단했기 때문에 성공했다”는 이야기는 후배에게 배움보다 거리감을 줍니다. 성공은 가능한 한 사실로 기술하는 편이 낫습니다. 언제, 어떤 조건에서, 어떤 자원이 있었고, 어떤 우연이 겹쳤는지를 묘사해야 합니다.

반대로 실패는 설명해야 합니다. 그때 내가 무엇을 잘못 봤는지, 어떤 욕심이 있었는지, 어떤 신호를 무시했는지, 어떤 판단 기준이 틀렸는지를 말해야 합니다. 후배는 선배의 완성된 성공보다, 선배가 자기 실패의 주인공이 되는 장면에서 더 많이 배웁니다.

이 원칙은 창업자에게 특히 중요합니다. 창업자는 성공을 말할 때는 시장, 타이밍, 팀, 운을 포함해 기술해야 합니다. 실패를 말할 때는 “내가 무엇을 놓쳤는가”를 설명해야 합니다. 그래야 다음 세대가 같은 방식으로 실패하지 않습니다.

6. 자기효능감은 큰 행복보다 작은 회복에서 옵니다

자기효능감은 “나는 대단하다”는 확신이 아니라, 힘든 일을 하고도 다시 돌아올 수 있다는 감각입니다. 강의에서 김경일 교수님은 행복을 목표가 아니라 도구로 설명했습니다. 행복해서 사는 것이 아니라, 버티고 다시 시도하려면 행복이 필요하다는 뜻입니다.

여기서 중요한 것은 행복의 크기가 아니라 빈도입니다. 1년에 한 번 오는 100점짜리 행복보다, 다시 일로 돌아가게 만드는 10점짜리 행복 10번이 더 강할 수 있습니다. 창업자와 리더에게 필요한 것도 거대한 보상이 아니라 작은 회복 루틴입니다.

예를 들면 이런 것들입니다.

• 포기하고 싶은 날, 부담 없는 사람과 밥을 먹고 30분 수다 떠는 것
• 산책하며 머리가 조금 정리되는 것
• 내가 힘을 냈던 순간을 짧게 기록해두는 것
• 비슷한 어려움이 왔을 때 과거의 회복 패턴을 다시 꺼내는 것

김경일 교수님은 난중일기에도 시련과 함께 음식, 대화, 걷기, 사람 이야기가 계속 나온다고 설명했습니다. 리더의 라이프로그는 감성 기록이 아니라 다음 위기를 버티기 위한 운영 자산입니다.

AI 시대의 학습과 성장감도 같은 맥락입니다. 일이 재미없어졌다면 일이 틀린 것이 아니라, 내가 전문가가 되었기 때문일 수 있습니다. 이때는 아주 작은 새 배움을 통해 성장감을 다시 빌려오는 것이 필요합니다. 이 주제는 AI 시대 학습법 글에서도 이어서 볼 수 있습니다.

7. 실행 체크리스트: 내일부터 바꿀 수 있는 언어

리더십 언어는 거창한 선언보다 작은 문장 교체에서 바뀝니다. 내일부터 바로 바꿔볼 수 있는 문장은 다음과 같습니다.

좋은 리더는 말을 잘하는 사람이 아닙니다. 상대가 자기 문제의 주인공으로 남아 있게 만드는 사람입니다. 조언을 많이 하는 것보다, 상대가 자기 언어로 다시 움직이게 만드는 것이 더 어렵고 더 중요합니다.

자주 묻는 질문

상대를 주인공으로 만든다는 것은 비위를 맞추라는 뜻인가요?

아닙니다. 상대를 주인공으로 만든다는 것은 상대의 관점에서 문제를 먼저 묘사한 뒤, 필요한 피드백을 주는 것입니다. 결과가 부족하면 냉정하게 말해야 합니다. 다만 그 사람의 시간과 노력까지 무의미하게 만들 필요는 없습니다.

멘토가 겸손해야만 좋은 멘토링이 가능한가요?

겸손하면 도움이 되지만 필수는 아닙니다. 김경일 교수님은 겸손하지 않아도 상대를 주인공으로 만들 수 있다고 설명했습니다. 중요한 것은 내가 낮아지는 태도보다, 상대의 기여와 시선을 정확히 불러주는 언어입니다.

스타트업 대표에게 가장 먼저 필요한 변화는 무엇인가요?

피드백 문장을 분리하는 것입니다. 과정과 결과를 한 번에 때리지 말고, 투입한 시간과 노력은 인정한 뒤 결과 기준을 별도로 다뤄야 합니다. 그래야 팀원이 다음 실험을 다시 시작할 수 있습니다.

일 관계에서 정서적 지지를 먼저 하면 왜 위험한가요?

일 관계에서는 권한, 일정, 책임 범위가 불명확하면 감정적 친밀감이 오히려 부담이 됩니다. 먼저 무엇을 해줄 수 있는지 명확히 해야 합니다. 기능적 지지가 안정되면 정서적 지지도 자연스럽게 쌓입니다.

리더가 자기 실패를 어디까지 공유해야 하나요?

상대가 배울 수 있는 수준까지 공유하면 됩니다. 감정 고백이 목적이 아니라 판단 기준을 전달하는 것이 목적입니다. 실패 당시 어떤 신호를 놓쳤고, 어떤 가정을 잘못 세웠고, 지금이라면 무엇을 다르게 할지 설명하는 것이 핵심입니다.

우리 조직의 리더십 언어를 실제 프로젝트로 점검할 준비가 되셨나요?

팀원이 움직이지 않는 이유가 역량 문제가 아니라 언어 설계 문제일 수 있습니다. 예산과 실행 권한이 있는 팀이라면, 현재 조직의 피드백·멘토링·실행 문장을 프로젝트 관점에서 함께 검토해드립니다.

👉 프로젝트 핏 확인 미팅 예약하기

📩 retn.kr 뉴스레터 구독하기

Simpson | Retention Corp.
스타트업 성장 전략 컨설팅

이 시리즈의 한 줄 요약

AI 에이전트는 더 이상 채팅창에서 질문에 답하는 도구만이 아닙니다. 맥미니 한 대를 항상 켜진 작업자 서버로 두고, Discord와 Telegram을 호출 인터페이스로 쓰고, WebUI와 Kanban으로 상태를 관리하면 개인도 작은 운영팀처럼 일할 수 있습니다.

이 시리즈는 “AI 에이전트가 무엇인가”를 설명하는 데서 멈추지 않습니다. 실제로 어디에 설치하고, 어떻게 호출하고, 무엇을 조심해야 하며, 사람이 어디서 개입해야 하는지까지 하나의 운영 흐름으로 정리합니다.

추천 읽는 순서

1. AI 에이전트란 무엇인가: 챗봇이 아니라 상태를 가진 작업자로 이해하기
2. 맥미니를 개인 AI 에이전트 서버로 준비하기: 전원, 네트워크, 계정, workspace, Tailscale
3. 노트북을 닫아도 일하는 AI 에이전트 서버 만들기: Hermes WebUI와 메신저 운영 구조
4. AI 에이전트에게 일을 맡겼더니, 제일 중요한 건 Kanban이었다
5. 개인 AI 서버 열기 전에 반드시 막아야 할 7가지

왜 맥미니인가

AI 에이전트 운영의 핵심은 성능보다 지속성입니다. 노트북은 닫히고, 브라우저 탭은 사라지고, 대화창은 묻힙니다. 반면 맥미니는 조용하고 전력 사용량이 낮고, macOS 자동화와 개발 도구를 그대로 쓸 수 있습니다.

각 인터페이스의 역할

• WebUI: 세션, 작업 상태, Kanban board, 설정을 보는 운영 화면
• Discord: 프로젝트별 채널과 스레드를 나누는 AI 에이전트 작업실
• Telegram: 이동 중 짧은 지시와 완료 알림을 받는 개인 리모컨
• Kanban: ready/running/blocked/done으로 작업을 관리하는 큐
• Tailscale/보안 설정: 개인 서버가 외부에 노출되지 않도록 하는 안전장치

이 시리즈가 다루지 않는 것

이 글들은 “마법 같은 AI 자동화”를 약속하지 않습니다. 대신 실패한 작업이 어디서 막혔는지, 사람이 어떤 결정을 내려야 다시 굴러가는지, API key와 봇 토큰을 어떻게 보호할지 같은 운영 문제를 다룹니다.

다음 단계

처음 읽는다면 개념 글보다 “노트북을 닫아도 일하는 AI 에이전트 서버 만들기”부터 읽어도 됩니다. 실제 구조를 먼저 보고 나면, 나머지 글의 의미가 더 빨리 들어옵니다.

개인 AI 서버는 개인 노트북보다 위험하다

맥미니 한 대라도 AI 에이전트가 파일, 메신저, 브라우저, API key, 고객 데이터에 접근한다면 이미 작은 서버입니다. 편의성을 위해 WebUI나 bot token을 대충 열어두면, 자동화가 아니라 공격 표면을 만든 셈이 됩니다.

1. WebUI를 public internet에 바로 열지 않는다

가장 안전한 기본값은 Tailscale 같은 private network입니다. 꼭 외부 접속이 필요하다면 인증, 접근 제한, 로그 확인이 먼저입니다. 포트포워딩으로 바로 여는 방식은 피하는 편이 좋습니다.

2. 봇 토큰은 스크린샷에도 나오면 안 된다

Discord/Telegram bot token은 비밀번호와 같습니다. 블로그 글, 강의 자료, 터미널 로그, 화면 공유에 노출되지 않도록 합니다. 한 번 노출됐다고 의심되면 바로 rotate해야 합니다.

3. 실제 chat id와 workspace 경로를 숨긴다

chat id, thread id, 고객명이 들어간 폴더명, 홈 디렉터리 전체 경로는 작은 정보처럼 보이지만 공격자에게는 단서입니다. 공개 글에서는 항상 예시 값으로 바꿉니다.

4. API key는 파일에 직접 쓰지 않는다

환경변수, 1Password CLI, secret manager를 씁니다. 특히 에이전트가 읽는 프로젝트 폴더 안에 key를 두면, 나중에 요약/로그/스크린샷에 섞일 수 있습니다.

5. 외부 side effect는 승인 단계를 둔다

이메일 발송, 결제 취소, 소셜 포스팅, 배포, 삭제는 에이전트가 혼자 실행하지 않도록 합니다. 자동화할 수 있어도 승인 단계를 두는 것이 운영 품질을 지킵니다.

6. 로그를 보관하되 공개하지 않는다

로그는 문제 해결에 필요합니다. 하지만 로그에는 프롬프트, 이메일 주소, API 응답, 내부 URL이 들어갈 수 있습니다. 보관 위치와 공유 방식을 분리해야 합니다.

7. seed 테스트와 모니터링을 작게 시작한다

새로운 자동화는 전체 사용자에게 바로 보내지 않습니다. seed label, 내부 메일함, 작은 세그먼트로 먼저 검증합니다. 성공 기준과 rollback 기준도 함께 정합니다.

공개 전 체크리스트

• 주소창에 실제 내부 URL이 보이지 않는가
• 터미널 출력에 token/key/chat id가 없는가
• 스크린샷에 고객명/프로젝트명이 없는가
• 본문 예시가 실제 경로가 아니라 일반화된 경로인가
• 봇 토큰과 API key를 rotate할 절차가 있는가

AI 에이전트 서버의 보안은 거창한 보안 제품에서 시작하지 않습니다. 공개하지 말아야 할 것을 공개하지 않고, 멈춰야 할 순간에 멈추는 운영 습관에서 시작합니다.

채팅창은 작업 큐가 아니다

AI 에이전트에게 한두 가지를 부탁할 때는 채팅창으로 충분합니다. 하지만 리서치, 코드 수정, 뉴스레터 분석, 자동화 모니터링처럼 작업이 늘어나면 채팅창은 금방 한계에 부딪힙니다.

무엇이 진행 중인지, 무엇이 실패했는지, 어떤 작업이 사람의 판단을 기다리는지 분리해서 봐야 합니다. 이때 필요한 것이 Kanban입니다.

AI 에이전트 Kanban의 핵심 상태

• triage: 아직 정리되지 않은 요청
• ready: 실행해도 되는 작업
• running: worker가 처리 중인 작업
• blocked: 권한, 정보, 판단, 승인 때문에 멈춘 작업
• done: 결과와 검증이 끝난 작업

blocked는 실패가 아니라 안전장치다

좋은 AI 에이전트는 모르는 상태에서 밀어붙이지 않습니다. 결제, 환불, 외부 발송, 삭제, 배포처럼 되돌리기 어려운 행동은 blocked로 멈춰야 합니다. 사람이 판단을 남기면 그때 다시 이어갑니다.

사람은 어디에 개입해야 하나

• 목표가 모호할 때 범위를 좁힌다.
• 외부 side effect가 있을 때 승인한다.
• 여러 대안 중 브랜드/사업 판단이 필요할 때 선택한다.
• 실패가 반복될 때 기준을 바꾼다.
• 잘 작동한 절차를 skill이나 runbook으로 남긴다.

Kanban이 있어야 팀 플레이가 가능하다

AI 에이전트를 혼자 쓰더라도 Kanban은 유용합니다. 하지만 진짜 가치는 팀에서 나옵니다. 비개발자도 카드 단위로 일을 요청하고, 개발자나 에이전트가 작업을 수행하고, 대표는 blocked 카드만 보며 판단할 수 있습니다.

내가 추천하는 작은 시작

1. 반복되는 업무 하나를 고릅니다.
2. 완료 조건을 한 줄로 씁니다.
3. 실패했을 때 멈출 조건을 정합니다.
4. 결과물을 어디에 남길지 정합니다.
5. 첫 3번은 사람이 꼼꼼히 검수합니다.

AI 에이전트 운영의 목표는 사람이 사라지는 것이 아닙니다. 사람이 사소한 반복에서 빠져나와 판단과 설계에 집중하는 것입니다. 그래서 Kanban은 생산성 도구가 아니라 리더십 도구에 가깝습니다.

맥미니는 “작은 서버”로 다루는 게 맞다

맥미니는 책상 위에 있지만, AI 에이전트를 올리는 순간 개인 서버가 됩니다. 파일을 읽고, 터미널을 실행하고, 메신저로 알림을 보내고, API key를 들고 있기 때문입니다. 그래서 설치보다 먼저 운영 기준을 정해야 합니다.

1. 전원과 절전

에이전트는 사람이 잠든 뒤에도 작업을 이어갈 수 있어야 합니다. macOS 전원 설정에서 디스플레이 꺼짐과 시스템 잠자기를 분리하고, 네트워크 접근이 필요한 자동화가 끊기지 않도록 합니다. UPS까지는 선택이지만, 최소한 재부팅 후 자동 시작 방식은 정해두는 편이 좋습니다.

2. 계정과 workspace

개인 계정 하나에 모든 것을 넣으면 편하지만 위험합니다. 최소한 작업용 workspace 경로를 분리하고, 공개 글이나 스크린샷에 홈 디렉터리 전체 경로가 나오지 않도록 습관을 들입니다.

• 예시 workspace: ~/workspace/agents
• 로그: ~/.hermes/logs 또는 별도 백업 대상
• 장기 산출물: 프로젝트별 디렉터리
• 임시 파일: /tmp 또는 cache 디렉터리

3. 네트워크 접근은 Tailscale 우선

개인 AI 서버의 WebUI를 public internet에 바로 열면 안 됩니다. 가능한 기본값은 Tailscale 같은 private network입니다. 같은 LAN에서만 쓰더라도, 나중에 외부 접속을 붙일 때 포트포워딩부터 떠올리지 않는 것이 중요합니다.

4. 필요한 기본 도구

• Python, Node.js, git 같은 개발 도구
• 1Password CLI처럼 비밀값을 안전하게 읽는 도구
• 메신저 gateway를 위한 Discord/Telegram bot token
• DNS나 newsletter 운영을 위한 API key
• 로그를 읽고 문제를 재현할 수 있는 터미널 환경

5. 설치 전 결정할 것

Hermes Agent를 설치하기 전에 기본 model/provider, gateway를 연결할 메신저, WebUI 접근 방식, Kanban 사용 여부를 정합니다. 이 순서가 꼬이면 나중에 봇, WebUI, CLI가 서로 다른 상태를 보게 됩니다.

권장 원칙

처음부터 완벽한 홈서버를 만들 필요는 없습니다. 대신 “항상 켜져 있다”, “외부에 노출되지 않는다”, “막힌 작업을 사람이 볼 수 있다”, “API key가 스크린샷에 나오지 않는다” 네 가지 기준을 먼저 만족시키면 충분합니다.

AI 에이전트는 “답변자”가 아니라 “작업자”다

챗봇은 질문에 답합니다. AI 에이전트는 목표를 받고, 파일을 읽고, 도구를 호출하고, 결과를 확인한 뒤 다음 행동을 이어갑니다. 겉으로는 둘 다 대화창에 있는 것처럼 보이지만 운영 방식은 완전히 다릅니다.

예를 들어 “어제 보낸 뉴스레터 오픈율을 분석하고 다음 발송 플랜을 짜라”는 요청은 단순 답변이 아닙니다. Ghost API를 읽고, Mailgun 이벤트를 확인하고, DNS 상태를 점검하고, 발송 세그먼트를 계산하고, 필요하면 cron으로 후속 모니터링까지 걸어야 합니다.

챗봇과 에이전트의 차이

• 챗봇은 대화 기록이 중심이고, 에이전트는 작업 상태가 중심입니다.
• 챗봇은 답변을 생성하고, 에이전트는 외부 도구를 호출합니다.
• 챗봇은 실패하면 사과하지만, 에이전트는 로그를 보고 다시 시도하거나 blocked 상태로 멈춥니다.
• 챗봇은 한 사람이 읽는 답을 만들고, 에이전트는 다른 시스템에 남는 결과물을 만듭니다.

왜 로컬 AI 에이전트인가

개인 업무 자동화에서는 클라우드 서비스보다 로컬 에이전트가 유리한 순간이 많습니다. 내 파일, 브라우저, 터미널, 메신저, 내부 문서에 접근해야 하기 때문입니다. 맥미니 같은 항상 켜진 기기에 에이전트를 두면 노트북을 닫아도 작업이 계속됩니다.

Hermes Agent로 보면 이해가 쉽다

Hermes Agent는 CLI, WebUI, Discord, Telegram, Slack, cron, Kanban을 하나의 작업 런타임으로 묶습니다. 사용자는 채팅에서 목표를 주고, 에이전트는 필요한 도구를 호출합니다. 긴 작업은 cron이나 background process로 넘기고, 막힌 작업은 Kanban의 blocked 상태로 남깁니다.

사람이 사라지는 것이 아니라 lead한다

좋은 AI 에이전트 운영은 사람을 빼는 것이 아닙니다. 사람이 매번 손으로 반복하던 조회, 비교, 정리, 검증을 에이전트가 맡고, 사람은 기준과 결정을 제공합니다. 그래서 핵심은 “Human in the loop”보다 “Human in the lead”에 가깝습니다.

처음 시작할 때의 기준

• 반복되지만 매번 판단이 조금 필요한 업무를 고릅니다.
• 결과를 검증할 수 있는 데이터를 붙입니다.
• 실패했을 때 멈출 기준을 정합니다.
• 외부 발송, 결제, 삭제처럼 되돌리기 어려운 행동은 승인 단계를 둡니다.
• 잘 작동한 절차는 skill이나 runbook으로 남깁니다.

AI 에이전트를 잘 쓰는 사람은 프롬프트를 멋지게 쓰는 사람이 아니라, 작업 단위와 검증 루프를 잘 설계하는 사람입니다.

문제는 AI가 아니라 “운영 화면”이었다

처음에는 AI 에이전트를 채팅창에서만 쓰면 충분하다고 생각했습니다. 그런데 작업이 길어지자 문제가 바뀌었습니다. 지금 어떤 작업이 돌고 있는지, 어디서 막혔는지, 사람이 무엇을 답해야 다시 진행되는지 보이지 않았습니다.

그래서 구조를 바꿨습니다. 노트북이 아니라 맥미니를 항상 켜진 AI 에이전트 서버로 두고, Hermes Agent를 중심에 놓았습니다. 브라우저는 WebUI, 빠른 지시는 Telegram, 프로젝트별 작업실은 Discord, 상태 관리는 Kanban으로 나눴습니다.

왜 맥미니인가

맥미니는 조용하고 전력 사용량이 낮습니다. 더 중요한 것은 노트북처럼 닫히지 않는다는 점입니다. AI 에이전트는 “한 번 답하고 끝나는 도구”가 아니라, 몇 시간 뒤에도 로그를 보고 이어서 판단해야 하는 작업자에 가깝습니다.

내가 쓰는 역할 분담

• CLI: 로컬에서 빠르게 확인하고 설정을 바꾸는 관리자 콘솔
• WebUI: 세션, Kanban, blocked 작업, 설정을 보는 운영 화면
• Discord: 프로젝트별 채널과 스레드가 있는 AI 에이전트 작업실
• Telegram: 이동 중 짧은 지시와 완료 알림을 받는 리모컨
• Cron: 사람이 없는 시간에도 정해진 체크를 실행하는 감시자

Discord is the new terminal

Discord가 좋은 이유는 채널과 스레드입니다. 터미널은 실행 결과가 흘러가지만, Discord thread는 작업의 맥락을 남깁니다. “이 작업은 왜 시작됐고, 어디서 막혔고, 어떤 결정을 했는가”가 같은 공간에 남습니다.

개인 작업도 마찬가지입니다. 블로그, 뉴스레터, 자동화, 리서치처럼 흐름이 다른 작업을 채널/스레드로 나누면 AI 에이전트를 팀원처럼 배치할 수 있습니다. 중요한 것은 AI를 더 많이 부르는 것이 아니라, 작업실을 나누는 것입니다.

WebUI가 필요한 순간

메신저는 호출과 알림에 좋지만 전체 상태판으로는 부족합니다. blocked 작업이 몇 개인지, 어떤 작업이 반복 실패했는지, 어떤 cron이 마지막으로 에러를 냈는지는 WebUI나 Kanban에서 보는 편이 낫습니다.

Telegram은 개인 리모컨

Telegram은 이동 중에 좋습니다. “이 파일 확인해”, “이 메일 오픈율 다시 봐”, “끝나면 알려줘” 같은 짧은 지시를 던지고 결과만 받을 때 유용합니다. 반면 긴 토론과 작업 분기는 Discord가 낫습니다.

Kanban이 있어야 사람이 lead할 수 있다

AI 에이전트 운영에서 중요한 것은 완료된 작업보다 막힌 작업입니다. 권한이 없거나, 제품 판단이 필요하거나, 외부 발송 승인이 필요한 순간 에이전트는 멈춰야 합니다. Kanban의 blocked는 실패가 아니라 안전장치입니다.

이 구조로 달라진 점

• 밤에 던진 분석 작업이 아침에 결과로 남습니다.
• 긴 자동화가 실패해도 로그와 상태가 남습니다.
• 외부 발송이나 삭제 같은 위험한 행동은 사람이 승인할 수 있습니다.
• 작업 결과가 채팅, 파일, cron, Kanban에 흩어지지 않고 연결됩니다.

아직 조심해야 할 것

개인 AI 서버는 편하지만 위험합니다. WebUI URL, bot token, API key, 실제 chat id, 고객명이 들어간 workspace 경로는 공개되면 안 됩니다. 특히 블로그 스크린샷을 올리기 전 주소창, 로그, 터미널 출력은 반드시 확인해야 합니다.

다음 글

다음 글에서는 이 구조를 “작업 큐” 관점에서 다룹니다. AI 에이전트를 잘 쓰려면 프롬프트보다 Kanban, blocked, retry, 사람의 개입 지점이 더 중요해집니다.

당신의 개인 업무나 팀 업무도 이런 식으로 AI 에이전트 작업실을 만들 수 있을지 궁금하면 답장 주세요. 실제 업무 기준으로 구조를 같이 그려보겠습니다.

한 줄 요약

OpenClaw를 한 달 넘게 쓰다가 헤르메스 에이전트(Hermes Agent)로 옮겼습니다. 이유는 단순합니다. 에이전트가 더 오래, 더 안정적으로, 그리고 내가 컴퓨터 앞에 없을 때도 계속 일하게 만들고 싶었습니다.

이 글은 설치 튜토리얼이 아닙니다. 왜 “AI 에이전트 서버”가 필요하다고 느꼈는지, 왜 Discord와 WebUI와 Kanban이 중요해졌는지, 그리고 왜 요즘 제 머릿속에서 Discord is the new terminal이라는 이상한 문장이 계속 맴도는지에 대한 전환기입니다.

OpenClaw를 쓰면서 생긴 피로

OpenClaw를 한 달 넘게 썼습니다. 좋은 점도 있었지만, 제 환경에서는 자주 죽었습니다. 더 큰 문제는 “에이전틱하게 움직인다”는 느낌이 약했다는 점입니다.

제가 원한 것은 이런 흐름이었습니다.

• 목표를 던진다.
• 에이전트가 오래 작업한다.
• 중간에 막히면 이유를 남긴다.
• 내가 모바일에서 병목만 제거한다.
• 에이전트가 다시 이어서 한다.

그런데 실제 사용감은 종종 달랐습니다. 작업을 부탁했는데 설명이 길어지고, 마지막에는 “원하면 해주겠다”는 식으로 끝나는 답변을 만날 때가 있었습니다. 저는 이미 해달라고 했는데 말입니다.

이 패턴이 반복되면 사람은 다시 컴퓨터 앞에 붙잡힙니다. 에이전트가 일을 대신하는 것이 아니라, 사람이 에이전트를 계속 설득하고 감시하게 됩니다.

밖으로 나가야겠다고 생각한 시점

그 무렵 저는 거의 매일 집에서 혼자 Claude Code와 Codex만 붙잡고 있었습니다. 온라인에도 좋은 자료는 많습니다. 실제로 제가 다녀온 Hermes 관련 밋업도 YouTube 영상으로 공개되어 있습니다.

그런데 오프라인 밋업에는 영상에 안 담기는 밀도가 있습니다. 발표 자체보다 쉬는 시간, 뒷풀이, 옆자리 대화에서 더 좋은 얘기를 듣는 경우가 많습니다.

사람들이 Claude Code, Codex, OpenClaw, Hermes 같은 도구를 실제로 어떻게 쓰는지 보고 싶었습니다. 어떤 사람들이 어떤 pain point를 겪고 있고, 그 문제를 어떻게 긁어주면 돈을 벌 수 있을지도 알고 싶었습니다. YC에서 반복해서 말하는 교훈도 결국 비슷합니다. 진짜 문제는 책상 앞에서 상상하는 것보다, 사람들이 실제로 불편해하는 장면에서 더 잘 보입니다.

그래서 Luma 행사 페이지를 보고 Hermes 밋업에 갔습니다. “헤르메스 에이전트가 내가 찾던 답일 수 있나?”를 확인하고 싶었습니다.

내가 원한 것은 모바일 HITL이었다

제가 원한 것은 완전 자동화가 아니었습니다. 오히려 반대에 가깝습니다. AI 에이전트가 할 수 있는 일은 길게 맡기되, 사람 판단이 필요한 순간에는 제가 빠르게 개입할 수 있어야 했습니다.

즉 HITL, human-in-the-loop가 필요했습니다.

중요한 것은 “사람이 개입한다”가 아닙니다. 어디서 개입할 수 있느냐입니다.

컴퓨터 앞에서만 개입할 수 있다면 에이전트는 저를 해방시키지 못합니다. 지하철, 카페, 이동 중, 밋업 쉬는 시간에도 확인할 수 있어야 합니다.

그래서 제 요구사항은 이렇게 바뀌었습니다.

• 에이전트는 맥미니 같은 상시 실행 머신에서 돈다.
• 저는 Discord나 Telegram으로 작업을 던진다.
• blocked가 오면 모바일에서 확인한다.
• 자세한 상태는 WebUI Kanban에서 본다.
• 필요한 답을 남기고 unblock한다.

이 구조가 잡히면 사람은 “계속 감시하는 사람”이 아니라 “병목만 제거하는 사람”이 됩니다.

Hermes 밋업에서 가져온 생각

밋업에서 노트테이킹한 핵심은 “Hermes는 처음부터 완성된 비서라기보다, 경험을 통해 skill을 쌓아가는 에이전트 런타임에 가깝다”는 점이었습니다.

이건 초반 사용성이 덜 매끄러울 수 있다는 뜻이기도 합니다. 하지만 장기적으로는 제가 원하던 방향과 맞았습니다.

제가 필요했던 것은 예쁜 채팅창이 아니라 다음 구조였습니다.

flowchart TD
  Human[사람] --> Discord[Discord]
  Human --> Mobile[모바일 브라우저]
  Discord --> Gateway[Hermes Gateway]
  Mobile --> WebUI[Hermes WebUI]
  Gateway --> Agent[Hermes Agent]
  WebUI --> Kanban[Kanban Board]
  Agent --> Kanban
  Kanban --> Workers[Workers]

Discord는 새 터미널처럼 동작합니다. 명령을 보내고, 상태를 받고, 작업을 이어갑니다. WebUI는 운영 화면입니다. Kanban은 에이전트가 어디서 막혔는지 보여줍니다.

이 셋이 붙으면 느낌이 달라집니다.

Discord is the new terminal

요즘 제 머릿속에 계속 남는 문장이 있습니다.

Discord is the new terminal.

처음엔 농담처럼 들렸습니다. 그런데 Hermes를 쓰다 보니 꽤 정확한 말처럼 느껴집니다.

터미널은 여전히 중요합니다. 서버를 켜고, 로그를 보고, 문제를 고칠 때는 터미널이 필요합니다. 하지만 에이전트에게 일을 시키고, 상태를 받고, blocked를 풀어주는 인터페이스는 꼭 터미널일 필요가 없습니다.

오히려 Discord가 더 좋은 경우가 있습니다.

• 채널과 스레드로 작업 맥락을 나눌 수 있습니다.
• 모바일 알림이 자연스럽습니다.
• 사람과 에이전트의 대화가 같은 공간에 남습니다.
• Kanban 작업의 terminal event를 원래 채팅방에서 받을 수 있습니다.

그래서 저는 Hermes를 “CLI 도구”보다 “Discord와 WebUI를 가진 에이전트 운영체제”처럼 쓰게 됐습니다.

iPad를 산 것도 이 흐름 때문이었다

그날 이후 저는 iPad Air M4를 샀습니다. 중고장터에서 미개봉 제품을 보고 바로 샀습니다.

충동구매처럼 보이지만 이유는 있었습니다. 제게 필요한 것은 더 좋은 노트북이 아니라, 이동 중에도 에이전트 상태를 보고 개입할 수 있는 화면이었습니다.

태블릿에서 Discord를 열고, WebUI Kanban을 보고, blocked reason을 읽고, 필요한 코멘트를 남기는 흐름을 만들고 싶었습니다.

이게 잘 되면 저는 다시 컴퓨터 앞에 묶이지 않아도 됩니다. 에이전트는 맥미니에서 계속 일하고, 저는 바깥에서 사람을 만나고, 필요할 때만 병목을 제거합니다.

결과: OpenClaw는 아직 삐걱이고, Hermes는 정착했다

결과적으로 제 환경에서는 OpenClaw보다 Hermes가 훨씬 잘 정착했습니다.

이 말이 OpenClaw가 나쁘다는 뜻은 아닙니다. 제 사용 방식과 맞지 않았다는 뜻에 가깝습니다. 저는 긴 작업, 모바일 HITL, Discord 운영, WebUI Kanban이 필요했습니다. Hermes는 이 네 가지를 더 잘 연결해 줬습니다.

앞으로 이 시리즈에서는 경험담에서 끝내지 않고 실제 세팅을 순서대로 정리하려고 합니다.

1. AI 에이전트가 무엇인지
2. 맥미니를 AI 에이전트 서버로 준비하는 법
3. 헤르메스 에이전트 설치와 기본 설정
4. WebUI 원격 접속 구성
5. Discord와 Telegram으로 호출하는 법
6. Kanban으로 blocked 작업을 운영하는 법
7. 개인 AI 서버 보안 체크리스트

첫 번째 실전 글은 AI 에이전트 서버 만들기: 맥미니에 헤르메스 에이전트 WebUI 구축하기입니다.

Link and Fact Check Notes

• YouTube 영상: https://www.youtube.com/live/hKwnmbrfUJQ
• Luma 행사 페이지: https://luma.com/1cwwvh0p?tk=4nNFrr
• 개인 Notion 노트 Hermes meetup 참고. 공개 글에는 private Notion URL을 넣지 않음.

검증일: 2026-05-12

TLDR

• 레니 뉴스레터는 PM, 그로스, AI 관련 업무를 하는 사람이라면 거의 필수 구독에 가깝습니다.
• 유료 연간 구독자는 Product Pass를 통해 여러 프리미엄 제품을 받을 수 있고, 2026년 4월 기준 총 가치는 $30,000+로 안내되어 있습니다.
• 그중 Mobbin은 Team 10 seats를 1년 무료로 받을 수 있어, 서비스 벤치마크와 A/B 테스트 가설 수립에 바로 쓸 수 있습니다.
• Mobbin MCP를 쓰면 "비슷한 서비스를 찾아보고, 화면 패턴을 보고, 우리 서비스 실험 플랜으로 바꾸는" 과정이 훨씬 짧아집니다.
• 제 레퍼럴 링크로 가입해 보고, Product Pass에서 Mobbin, Cursor, Google AI Pro, Notion, Supabase 같은 제품을 먼저 써보시길 권합니다.

왜 지금 레니 뉴스레터를 추천하는가

레니 뉴스레터(Lenny's Newsletter)는 제품, 그로스, AI, 커리어에 관한 깊은 글을 꾸준히 발행하는 뉴스레터입니다. 공식 소개 기준으로 1,000,000명 이상의 독자와 청취자, 30,000명 이상의 커뮤니티 멤버, 500개 이상의 deep dive를 보유하고 있습니다.

PM, 그로스 마케터, 창업자, AI 제품을 만드는 사람이라면 이미 한 번쯤 들어봤을 겁니다. 저는 이 뉴스레터를 단순한 콘텐츠 구독이 아니라 "제품 감각을 계속 업데이트하는 시스템"에 가깝게 봅니다.

그런데 2026년에는 구독의 이유가 하나 더 생겼습니다. 바로 Product Pass입니다.

Lenny's Product Pass는 Annual 또는 Insider 구독자에게 여러 프리미엄 제품을 무료 또는 할인 형태로 제공하는 번들입니다. 공식 페이지 기준으로 $30,000+ 가치의 AI/제품 도구가 포함되어 있고, 코드는 한정 수량입니다. 2026년 4월 업데이트에서는 Cursor, Google AI Pro, Notion, Supabase, Fin, Gumloop 등이 새로 추가됐다고 안내했습니다.

이 글에는 제 레퍼럴 링크가 포함되어 있습니다. 레니 뉴스레터를 구독하실 분은 아래 링크로 가입해 주시면 제게도 도움이 됩니다.

레니 뉴스레터 가입하기

Product Pass에서 제일 먼저 볼 제품: Mobbin

Product Pass에는 좋은 제품이 많습니다. 하지만 제품/그로스 실무자라면 저는 Mobbin을 먼저 보겠습니다.

Mobbin(모빈)은 모바일과 웹 앱의 UI/UX 레퍼런스를 모아둔 디자인 레퍼런스 라이브러리입니다. Product Pass 공식 페이지에는 Mobbin Team 10 seats 1년 무료, $1,440 value로 소개되어 있습니다.

이게 왜 중요할까요?

예전에는 A/B 테스트 가설을 세우려면 이런 순서를 거쳤습니다.

1. 비슷한 서비스를 떠올립니다.
2. 직접 가입하거나 화면을 캡처합니다.
3. 랜딩, 결제, 온보딩, 예약 플로우를 하나씩 비교합니다.
4. 우리 서비스에 적용할 수 있는 패턴을 정리합니다.
5. 실험 가설과 측정 지표를 만듭니다.

이 과정이 느렸습니다. 특히 "비슷한 서비스가 뭐가 있지?"에서 자주 막혔습니다.

Mobbin MCP가 나오면서 이 병목이 꽤 많이 줄었습니다. MCP는 AI 도구가 외부 서비스와 연결될 수 있게 해주는 표준 연결 방식입니다. 공식 MCP 문서는 host가 여러 client를 관리하고, 각 client가 특정 server와 1:1로 연결되어 도구와 컨텍스트를 주고받는 구조로 설명합니다.

쉽게 말하면, 이제 AI에게 이렇게 시킬 수 있습니다.

"우리 사이트는 고가 오프라인 교육 상품입니다. Mobbin에서 비슷한 부트캠프, 예약, 체크아웃 플로우를 찾아보고 A/B 테스트 가설로 정리해 주세요."

그리고 실제로 Mobbin MCP는 관련 화면을 찾아와서, 어떤 화면 구조가 반복되는지, CTA가 어디에 있는지, 가격/환불/일정 정보가 언제 노출되는지까지 비교할 수 있게 해줍니다.

실제로 우리 서비스에 어떻게 썼는가

최근 저희는 AI 교육 랜딩 페이지의 A/B 테스트 플랜을 짜면서 Mobbin MCP를 사용했습니다.

테스트 질문은 간단했습니다.

"리더가 직접 AI 서비스를 만든다"는 high-status 메시지가 나은가, 아니면 "강의는 봤지만 내 프로젝트에서 막힌다"는 blocked solo learner 메시지가 나은가?

Mobbin에서 본 레퍼런스는 세 그룹이었습니다.

결론은 "디자인을 예쁘게 바꾸자"가 아니었습니다. 오히려 더 실무적인 결론이 나왔습니다.

• 이번 테스트는 A/B 두 개만 돌립니다.
• Meta 광고 URL은 하나로 유지합니다.
• 1차 지표는 begin_checkout / ab_exposure로 봅니다.
• B안이 클릭은 늘리지만 결제 품질을 떨어뜨리면 죽입니다.
• 다음 테스트는 proof-first, date-first, checkout-summary 순서로 갑니다.

이게 Mobbin MCP의 장점입니다. 레퍼런스를 보는 데서 끝나는 게 아니라, 실험 설계까지 바로 이어집니다.

Product Pass에서 같이 볼 만한 추천 제품

제가 Product Pass에서 먼저 뽑아볼 제품은 아래입니다. 일부 제품은 Insider 전용일 수 있고, 코드는 한정 수량이므로 실제 조건은 Product Pass 페이지에서 다시 확인해야 합니다.

1. Mobbin

서비스 벤치마크, 랜딩 페이지 구조 분석, 온보딩/체크아웃 레퍼런스 수집에 바로 씁니다. PM, 디자이너, 그로스 담당자 모두에게 효용이 큽니다.

2. Cursor

AI 제품을 직접 만들거나 내부 툴을 빠르게 만들고 싶다면 우선순위가 높습니다. 비개발자라도 제품 스펙을 코드로 바꾸는 감각을 익히는 데 좋습니다.

3. Google AI Pro

Gemini, NotebookLM, Flow, 5TB 저장 공간 등이 포함된 제품입니다. 리서치, 문서 정리, 이미지/영상 실험을 많이 하는 팀이면 활용 폭이 넓습니다.

4. Notion

AI 워크스페이스, 회의록, 프로젝트 문서, 팀 운영 OS를 만들 때 좋습니다. 특히 제품팀이 "결정 기록"을 남기기 시작할 때 효과가 큽니다.

5. Supabase

아이디어를 실제 제품으로 빠르게 옮길 때 유용합니다. 데이터베이스, 인증, 스토리지, Edge Functions를 한 번에 쓸 수 있어 MVP 제작 속도를 높입니다.

6. Gumloop 또는 n8n

반복 업무 자동화, 리서치 에이전트, CRM 업데이트, Slack/이메일 자동화를 만들고 싶다면 먼저 써볼 만합니다.

레니 뉴스레터는 누구에게 맞는가

저는 아래 직군이라면 레니 뉴스레터를 강하게 추천합니다.

• PM: 제품 전략, 우선순위, 사용자 리서치, 지표 감각을 계속 업데이트해야 하는 사람
• 그로스 담당자: acquisition, activation, retention, pricing, PLG 사례를 계속 봐야 하는 사람
• 창업자: 제품과 GTM을 동시에 고민해야 하는 사람
• AI 제품 담당자: AI 도구 변화가 실제 제품/업무 방식에 어떤 영향을 주는지 따라가야 하는 사람
• 비개발자 빌더: 도구를 조합해 직접 제품을 만들고 싶은 사람

무료 글만 읽어도 배울 게 많습니다. 하지만 Annual 또는 Insider 구독까지 가면 Product Pass가 붙습니다. 이때부터는 단순히 "글을 읽는 구독"이 아니라 "제품 빌더용 툴킷"에 가까워집니다.

가입 전에 확인할 것

Product Pass는 강력하지만, 몇 가지 조건이 있습니다.

• Monthly 구독자는 Product Pass 대상이 아닙니다. Annual 또는 Insider 구독이 필요합니다.
• 각 제품은 보통 신규 고객 조건이 붙습니다.
• 코드는 한정 수량이며, claim해야 확보됩니다.
• 일부 제품은 Insider 전용입니다.
• 구독을 취소하거나 갱신하지 않으면 코드나 trial이 비활성화될 수 있습니다.

그래서 가입 후에는 가장 관심 있는 제품부터 바로 claim하는 편이 좋습니다. 특히 Mobbin처럼 팀 단위로 바로 쓸 수 있는 제품은 늦게 미루지 않는 게 낫습니다.

결론: 레퍼런스 수집에서 실험 설계까지 한 번에

레니 뉴스레터는 원래도 PM, 그로스, AI 관련 종사자라면 볼 이유가 충분한 콘텐츠였습니다. 여기에 Product Pass가 붙으면서 실무 도구까지 같이 얻는 구독이 됐습니다.

특히 Mobbin MCP는 제품팀과 그로스팀에게 바로 쓸 수 있는 조합입니다.

이제 "어떤 서비스를 벤치마크해야 하지?"에서 멈추지 않아도 됩니다. AI에게 Mobbin을 붙여 레퍼런스를 찾고, 패턴을 뽑고, 가설을 만들고, A/B 테스트 플랜까지 빠르게 만들 수 있습니다.

PM, 그로스, AI 제품 일을 하신다면 레니 뉴스레터를 구독해 보세요. 그리고 Product Pass에서 Mobbin부터 claim해 보시길 권합니다.

제 레퍼럴 링크로 레니 뉴스레터 가입하기

FAQ

레니 뉴스레터는 무료로 봐도 되나요?

무료 글과 팟캐스트만으로도 충분히 배울 수 있습니다. 다만 Product Pass는 Annual 또는 Insider 구독자 대상이므로, 도구 번들까지 쓰려면 유료 연간 구독이 필요합니다.

Mobbin MCP는 디자이너만 쓰는 도구인가요?

아닙니다. 디자이너에게도 좋지만, PM과 그로스 담당자에게도 유용합니다. 랜딩, 온보딩, 예약, 체크아웃 같은 전환 흐름을 비교하고 실험 가설로 바꿀 수 있기 때문입니다.

Product Pass 제품은 모두 받을 수 있나요?

조건이 있습니다. 코드가 한정되어 있고, 제품별 신규 고객 조건이나 Insider 전용 조건이 있을 수 있습니다. 실제 claim 전에 Product Pass 페이지의 현재 조건을 확인해야 합니다.

레퍼럴 링크로 가입하면 추가 비용이 있나요?

아닙니다. 독자에게 추가 비용이 붙지는 않습니다. 다만 이 글의 링크로 가입하면 작성자에게 레퍼럴 혜택이 있을 수 있습니다.

TLDR

• 2026년 4월, Meta가 Ads MCP Server와 Ads CLI를 동시 출시했다. 같은 달 Anthropic은 Claude Code Routines와 Managed Agents를 내놓았다. 이 네 가지 도구를 조합하면 크리에이티브 피로도 관리를 완전 자율 에이전트로 구현할 수 있다
• MCP = 읽기(감지), CLI = 쓰기(대응), Claude Code Routines = 스케줄링(자동 실행) — 매일 새벽 에이전트가 스스로 깨어나 피로 소재를 스캔하고, 단계별 대응을 실행하고, Slack에 결과를 보고한다
• Frequency 3.0 이상 + CTR 주간 20% 이상 하락 동시 발생 시 즉시 교체 — 이 규칙을 MCP anomaly_signal로 자동 감지하고, CLI meta ads ad update --status PAUSED로 즉시 실행한다
• 이 글은 크리에이티브 테스트 운영체계와 Kill/Trim/Protect/Promote 프레임워크의 후속편이다

시리즈 위치: 1편은 "어떤 소재를 테스트할 것인가"(구조 설계), 2편은 "성과가 나쁜 소재를 언제 끌 것인가"(CPA 기반 OFF 판정)를 다뤘다. 이 3편은 Meta 공식 AI 도구(MCP + CLI)를 활용해 피로도 감지 → 예측 → 대응을 에이전틱하게 자동화하는 시스템을 다룬다. 2편의 Kill 판정이 "이미 나빠진 소재를 끄는" 사후 조치라면, 3편은 "아직 CPA가 안 올랐지만 곧 올라갈 소재를 AI 에이전트가 미리 잡는" 사전 조치다.

왜 지금 "에이전틱" 피로도 관리인가

2026년 4월, 에이전틱 광고 운영에 필요한 퍼즐 조각이 한꺼번에 맞춰졌다:

1. Meta Ads MCP Server (4/29) — Claude, Cursor 등 AI 에이전트가 광고 데이터를 직접 조회·분석하는 Model Context Protocol 서버
2. Meta Ads CLI (4/29) — 터미널에서 meta ads <resource> <action> 패턴으로 캠페인 전체 라이프사이클을 CRUD하는 커맨드라인 도구
3. Claude Code Routines (4/14) — 프롬프트 + 리포 + 커넥터를 한 번 설정하면 스케줄/API/webhook으로 자동 실행되는 Claude Code 자동화. 노트북 꺼도 클라우드에서 실행된다
4. Claude Managed Agents (4월 베타) — 장시간 자율 실행이 가능한 관리형 에이전트 인프라. MCP 서버 연결, bash 실행, 파일 I/O를 컨테이너 안에서 수행

이전까지 피로도 자동화는 Graph API 코드를 직접 작성하는 것이 유일한 방법이었다. Node.js로 인사이트를 수집하고, 스코어를 계산하고, 예산을 조정하는 코드를 모두 직접 짜야 했다. 이제 MCP가 읽기를, CLI가 쓰기를, Claude Routines가 스케줄링을 담당하면서, AI 에이전트가 중간에서 판단을 내리는 완전 자율 구조가 가능해졌다.

핵심 전환: "개발자가 코드를 짜서 자동화" → "AI 에이전트가 MCP로 읽고, 판단하고, CLI로 실행하고, Routines로 매일 자동 깨어남". 보일러플레이트와 인프라 운영이 사라지고 판단 로직에 집중할 수 있다.

이 글은 누구를 위한가

• 메타 광고 소재를 주 단위로 교체하면서 "언제 끄는 게 맞는지" 감에 의존하는 퍼포먼스 마케터
• CTR이 서서히 빠지는데 원인을 빈도 때문인지, 소재 자체 문제인지 구분하지 못하는 운영자
• Claude, Cursor, Windsurf 등 AI 코딩 에이전트를 업무에 쓰고 있지만, 광고 자동화까지는 연결하지 못한 팀
• 월 광고비 1,000만 원 이상 집행하면서 수동 모니터링의 한계를 느끼는 마케터

배경: 크리에이티브 피로도란

크리에이티브 피로도(Creative Fatigue)란 동일한 광고 소재가 동일한 타겟에게 반복 노출되면서 반응률이 체계적으로 하락하는 현상이다. Meta 공식 문서에서는 이를 "광고가 반복적으로 같은 사람에게 도달하여 효과가 감소하는 것"으로 정의한다(Meta 광고 관리자의 크리에이티브 피로도 가이드).

문제는 피로도가 선형적으로 악화되지 않는다는 점이다. 초기에는 미세한 CTR 하락(1~2%)으로 시작하지만, 특정 임계점을 넘으면 가속도적으로 악화된다.

피로도 악화 단계

위 수치 범위는 월 1,000만~5,000만 원 규모 Meta 캠페인 운영 경험에서 관찰된 패턴이다 (우리 팀 관측 — 업종·예산·타겟 규모에 따라 편차 존재).

수동 모니터링에 의존하면 보통 3단계(가속 피로)에 진입한 뒤에야 "성과가 떨어진다"고 인지한다. 이때 이미 2주치 예산의 상당 부분이 비효율적으로 소진된 상태다.

3단계 에이전틱 피로도 대응 프레임워크

Step 1. 감지 — MCP로 "지금 피로한가?" 자동 스캔

피로도 감지의 핵심은 단일 지표가 아닌 복합 신호를 읽는 것이다. MCP 서버의 도구들이 이 복합 판단을 네이티브로 지원한다.

감지에 사용하는 MCP 도구

에이전트 워크플로우: 3단계 감지

Step 1-1. 계정 전체 이상 스캔

AI 에이전트가 MCP ads_insights_anomaly_signal을 호출한다. 이 도구는 계정 내 모든 활성 소재를 스캔해서 CTR 급락, CPM 급등 등 비정상 패턴이 있는 소재를 자동으로 탐지한다.

→ MCP: ads_insights_anomaly_signal(ad_account_id: "123456789")
← 결과: ad_id 3건에서 CTR 이상 패턴 감지

Step 1-2. 해당 소재의 Frequency × CTR 교차 검증

탐지된 소재에 대해 ads_get_ad_entities로 frequency와 ctr을 조회한다. Frequency × CTR 동시 판단이 피로도 진단의 핵심이다.

→ MCP: ads_get_ad_entities(
    ad_account_id: "123456789",
    level: "ad",
    fields: ["id", "name", "frequency", "ctr", "cpm", "impressions", "reach"],
    filtering: [{ field: "ad.frequency", operator: "GREATER_THAN", value: ["3.0"] }],
    date_preset: "last_7d"
  )
← 결과: frequency ≥ 3.0인 소재 목록 + 각각의 CTR

핵심 규칙: Frequency × CTR 동시 판단. Frequency가 높아도 CTR이 유지되면 피로가 아니다 — 리타게팅 캠페인에서 흔히 발생한다. 반대로 Frequency가 낮은데 CTR이 급락하면 소재 자체 문제(크리에이티브 품질)이지 피로가 아니다.

Step 1-3. 벤치마크 비교로 오탐 배제

CTR 하락이 피로 때문인지, 시즌 효과(연말, 명절, 경쟁 심화)인지 구분해야 한다. ads_insights_industry_benchmark로 동종 업계 평균과 비교한다.

→ MCP: ads_insights_industry_benchmark(
    ad_account_id: "123456789",
    analysis_metric: "CTR",
    conversation_topic: "CREATIVE"
  )
← 결과: 업계 평균 CTR 대비 내 소재의 상대 위치

업계 전체 CTR이 하락 중이면 시즌 효과 → 피로 판정 보류. 내 소재만 하락이면 피로 확정.

Graph API로 같은 것을 하려면: Node.js로 insights API 호출 코드, rolling 평균 계산 로직, 벤치마크 외부 데이터 조합까지 약 200줄의 보일러플레이트가 필요했다. MCP는 이 3단계를 도구 3번 호출로 대체한다.

Step 2. 예측 — "언제 피로해질 것인가?"

감지보다 한 단계 발전한 접근은 피로 시점을 예측하는 것이다. 이 단계는 MCP/CLI로 대체되지 않는 영역이다 — 과거 소재 수명 데이터에서 패턴을 추출하는 통계 로직이 필요하다.

예측 로직 (단순 버전)

1. 과거 소재 수명 데이터 수집: MCP ads_get_ad_entities로 지난 90일간 운영한 소재별 frequency 추이를 조회한다. "Frequency 3.0 도달까지 걸린 일수"를 기록한다
2. 소재 유형별 평균 수명 산출: 이미지/영상/캐러셀 등 포맷별로 평균과 표준편차를 계산한다
3. 신규 소재 투입 시 예상 교체일 설정: 평균 수명의 80% 시점에 사전 알림을 설정한다

# 소재 수명 예측 (단순 통계 기반)
import statistics

def predict_fatigue_date(historical_lifespans_days: list[int]) -> dict:
    """과거 소재 수명 데이터로 다음 소재의 예상 피로 시점을 예측한다."""
    avg = statistics.mean(historical_lifespans_days)
    std = statistics.stdev(historical_lifespans_days) if len(historical_lifespans_days) > 1 else 0

    return {
        "avg_lifespan_days": round(avg, 1),
        "std_days": round(std, 1),
        "early_warning_day": round(avg * 0.8),   # 80% 시점 사전 경고
        "hard_deadline_day": round(avg * 1.0),    # 평균 수명 도달
        "confidence": "high" if std / avg < 0.3 else "medium" if std / avg < 0.5 else "low"
    }

# 예시: 지난 90일간 이미지 소재 10개의 수명
image_lifespans = [12, 15, 11, 18, 14, 13, 16, 10, 14, 17]
prediction = predict_fatigue_date(image_lifespans)
# → avg_lifespan_days: 14.0, early_warning_day: 11, confidence: "high"

예측 정확도가 높을수록 소재 준비 리드타임을 확보할 수 있다. 평균 수명이 14일이고 신규 소재 제작에 3~5일이 걸린다면, 투입 후 9일차에 다음 소재 제작을 시작해야 공백 없이 교체할 수 있다.

예측 정확도 backtesting: "이 예측이 실제로 맞는가?"

예측 모델은 검증 없이 쓰면 위험하다. walk-forward 방식으로 "처음 N개 소재로 예측 → 나머지 소재의 실제 수명과 비교"한다.

# Walk-forward backtesting: 예측 정확도 검증
import statistics

def backtest_predictions(lifespans: list[int], train_ratio: float = 0.6) -> dict:
    """과거 소재 수명 데이터를 train/test로 나눠 예측 정확도를 검증한다."""
    n = len(lifespans)
    split = int(n * train_ratio)
    if split < 3 or (n - split) < 2:
        return {"error": "데이터 부족 — 최소 소재 5개 이상 필요"}

    train = lifespans[:split]
    test = lifespans[split:]

    # train set으로 예측 생성
    pred_avg = statistics.mean(train)
    pred_std = statistics.stdev(train)
    early_warning = pred_avg * 0.8

    # test set 각 소재에 대해 평가
    results = []
    for actual in test:
        error_days = abs(actual - pred_avg)
        within_1std = error_days <= pred_std
        early_warning_hit = early_warning <= actual  # 사전 경고가 실제 피로 전에 발동했는가
        results.append({
            "actual": actual,
            "predicted": round(pred_avg, 1),
            "error_days": round(error_days, 1),
            "within_1std": within_1std,
            "early_warning_useful": early_warning_hit
        })

    within_1std_pct = sum(1 for r in results if r["within_1std"]) / len(results) * 100
    early_warning_hit_pct = sum(1 for r in results if r["early_warning_useful"]) / len(results) * 100
    mae = statistics.mean([r["error_days"] for r in results])

    return {
        "train_size": split,
        "test_size": len(test),
        "predicted_avg_days": round(pred_avg, 1),
        "mae_days": round(mae, 1),
        "within_1std_pct": round(within_1std_pct, 1),
        "early_warning_hit_pct": round(early_warning_hit_pct, 1),
        "verdict": "usable" if within_1std_pct >= 60 and early_warning_hit_pct >= 80 else "needs_more_data"
    }

# 예시 (시연용 가상 데이터)
all_lifespans = [12, 15, 11, 18, 14, 13, 16, 10, 14, 17, 13, 15, 11, 16, 12]
bt = backtest_predictions(all_lifespans)
# → train_size: 9, test_size: 6
# → predicted_avg_days: 13.7, mae_days: 1.8
# → within_1std_pct: 83.3%, early_warning_hit_pct: 100%
# → verdict: "usable"

판독 기준: - within_1std_pct ≥ 60%: 예측이 ±1 표준편차 안에 드는 비율. 60% 미만이면 소재 유형별로 분리해 재학습 - early_warning_hit_pct ≥ 80%: 80% 시점 사전 경고가 실제 피로 전에 발동하는 비율. 80% 미만이면 경고 시점을 70%로 당겨라 - mae_days ≤ 3: 평균 절대 오차 3일 이내면 소재 제작 리드타임 역산에 실용적

ML 모델(survival analysis, LSTM 시계열)을 적용하면 정밀도가 올라가지만, 월 집행 소재 수가 30개 이하인 팀에서는 위 통계 기반 접근 + backtesting만으로 충분하다. 핵심은 모델의 복잡도가 아니라, 예측을 검증하는 습관이다.

Step 3. 대응 — CLI로 "피로 소재를 즉시 처리"

피로 감지 후 대응은 Kill/Trim/Protect/Promote 프레임워크의 확장이다. MCP가 감지를 담당했다면, CLI가 대응을 담당한다. Meta Ads CLI는 --no-input, --force 플래그로 무인 자동화를 지원하고, JSON 출력으로 스크립트 파이핑이 가능하다.

단계별 자동 대응 매트릭스

에이전트 대응 파이프라인

파이프라인 단계 요약: - MCP 감지 → anomaly_signal + ads_get_ad_entities로 피로 소재 탐지 - AI 판단 → Frequency × CTR 매트릭스 + 벤치마크 비교로 피로 단계 분류 - CLI 실행 → 단계별 대응 — 예산 조정, 소재 OFF, 백업 소재 ON - 로그 축적 → 모든 대응 결과 저장, 수명 데이터로 예측 정밀도 향상

대응 자동화 스크립트 (CLI + MCP 조합)

아래 스크립트는 MCP로 감지한 피로 소재 목록을 받아, CLI로 단계별 대응을 자동 실행한다. cron으로 매일 09:00에 실행한다.

#!/bin/bash
# fatigue-response.sh — MCP 감지 결과를 받아 CLI로 자동 대응
# 사전 조건: META_AD_ACCOUNT_ID, META_ACCESS_TOKEN, SLACK_WEBHOOK_URL 환경변수 설정

set -euo pipefail

ACCOUNT_ID="${META_AD_ACCOUNT_ID}"
LOG_FILE="fatigue-actions-$(date +%Y%m%d).jsonl"

# ── 1. CLI로 피로 후보 소재 조회 (frequency ≥ 3.0인 활성 소재) ──
echo "[$(date -Iseconds)] Scanning fatigued ads..." >&2

FATIGUED_ADS=$(meta ads ad list \
  --account-id "$ACCOUNT_ID" \
  --fields id,name,frequency,ctr,cpm,status \
  --format json \
  --no-input 2>/dev/null | \
  jq '[.[] | select(.frequency >= 3.0 and .status == "ACTIVE")]')

COUNT=$(echo "$FATIGUED_ADS" | jq 'length')
if [ "$COUNT" -eq 0 ]; then
  echo "[$(date -Iseconds)] No fatigued ads detected. Clean." >&2
  exit 0
fi

echo "[$(date -Iseconds)] Found $COUNT fatigued ads." >&2

# ── 2. 단계별 대응 ──
echo "$FATIGUED_ADS" | jq -c '.[]' | while read -r ad; do
  AD_ID=$(echo "$ad" | jq -r '.id')
  AD_NAME=$(echo "$ad" | jq -r '.name')
  FREQ=$(echo "$ad" | jq -r '.frequency')
  CTR=$(echo "$ad" | jq -r '.ctr')

  # 피로 단계 분류
  if (( $(echo "$FREQ >= 5.0" | bc -l) )); then
    STAGE="severe"
    # 심각 피로: 즉시 OFF
    meta ads ad update "$AD_ID" --status PAUSED --force --no-input 2>/dev/null
    ACTION="PAUSED"
  elif (( $(echo "$FREQ >= 3.0" | bc -l) )); then
    STAGE="active"
    # 가속 피로: Slack 알림 (교체 승인 대기)
    ACTION="ALERT_SENT"
    curl -s -X POST "$SLACK_WEBHOOK_URL" \
      -H 'Content-Type: application/json' \
      -d "{\"text\":\"⚠️ 피로 감지: *${AD_NAME}* (freq=${FREQ}, CTR=${CTR}) → 교체 검토 필요\"}" \
      >/dev/null
  fi

  # 로그 기록
  echo "{\"ts\":\"$(date -Iseconds)\",\"ad_id\":\"$AD_ID\",\"name\":\"$AD_NAME\",\"freq\":$FREQ,\"ctr\":$CTR,\"stage\":\"$STAGE\",\"action\":\"$ACTION\"}" >> "$LOG_FILE"
  echo "[$(date -Iseconds)] $AD_NAME: $STAGE → $ACTION" >&2
done

echo "[$(date -Iseconds)] Done. Actions logged to $LOG_FILE" >&2

CLI가 Graph API 코드를 대체하는 지점: meta ads ad update <ID> --status PAUSED --force가 기존의 fetch('https://graph.facebook.com/v21.0/${adId}', { method: 'POST', body: JSON.stringify({ status: 'PAUSED' }) }) 코드 블록 전체를 대체한다. --format json과 jq 조합으로 파이핑하면 별도의 파싱 코드도 불필요하다.

다음 단계: Claude Code Routines로 완전 자율화

위 bash 스크립트를 cron에 등록하는 것도 방법이지만, 2026년 4월 출시된 Claude Code Routines를 쓰면 자체 서버 없이 클라우드에서 자동 실행할 수 있다.

Routines는 프롬프트 + 리포 + 커넥터를 한 번 설정하면 스케줄(매일/매주), API 호출, 또는 GitHub webhook으로 트리거된다. 노트북을 닫아도 Claude Code 웹 인프라에서 실행된다.

피로도 감지 Routine 설정 예시:

매일 오전 9시 KST:
1. Meta Ads MCP로 계정 전체 anomaly_signal 스캔
2. frequency ≥ 3.0 + CTR 하락 소재 식별
3. industry_benchmark로 시즌 효과 오탐 배제
4. 심각 피로(freq 5.0+) → CLI로 즉시 PAUSED
5. 가속 피로(freq 3.0~5.0) → Slack 커넥터로 알림
6. 결과를 리포의 fatigue-log.jsonl에 append

cron + bash 대비 이점:

cron 스크립트는 규칙 기반(frequency ≥ 5.0이면 OFF)으로만 동작한다. Routine은 에이전트가 "이 소재는 frequency 4.8이지만 CTR이 어제부터 급락 중이고 벤치마크 대비 하위 10%" 같은 복합 판단을 내릴 수 있다. 규칙의 경계값에서 발생하는 오탐/미탐을 줄이는 핵심 차이다.

장시간 분석이 필요한 경우(예: 90일 소재 수명 backtesting + 리포트 생성)에는 Claude Managed Agents가 적합하다. Managed Agent는 컨테이너 기반 세션에서 MCP 서버, bash, 파일 I/O를 활용해 수십 분~수 시간 자율 실행할 수 있다.

절감 효과 시뮬레이션: "자동화하면 얼마나 아끼는가?"

"자동 감지 vs 수동 감지"의 예산 차이를 Monte Carlo 시뮬레이션으로 검증한다.

# Monte Carlo 시뮬레이션: 자동 감지 vs 수동 감지 예산 낭비 비교
import random
import statistics

def simulate_fatigue_savings(
    n_creatives: int = 16,
    daily_budget: int = 3_000_000,      # 원
    target_cpa: int = 20_000,
    avg_lifespan_days: int = 14,
    manual_detect_lag_days: int = 10,    # 수동: 피로 진입 후 감지까지 평균 지연
    auto_detect_lag_days: int = 2,       # 자동: 24~48시간 내 감지
    cpa_multiplier_fatigued: float = 1.8,  # 피로 소재의 CPA는 정상 대비 1.8×
    simulations: int = 10_000
) -> dict:
    """피로 소재에 소진되는 '초과 비용'을 수동 vs 자동으로 비교한다."""
    manual_waste = []
    auto_waste = []

    for _ in range(simulations):
        lifespan = max(7, random.gauss(avg_lifespan_days, 3))
        daily_share = (daily_budget / n_creatives) * random.uniform(0.5, 1.5)
        normal_cpa = target_cpa
        fatigued_cpa = target_cpa * cpa_multiplier_fatigued

        manual_lag = max(1, random.gauss(manual_detect_lag_days, 3))
        manual_excess = daily_share * manual_lag * (1 - normal_cpa / fatigued_cpa)

        auto_lag = max(0.5, random.gauss(auto_detect_lag_days, 0.5))
        auto_excess = daily_share * auto_lag * (1 - normal_cpa / fatigued_cpa)

        manual_waste.append(manual_excess)
        auto_waste.append(auto_excess)

    manual_avg = statistics.mean(manual_waste)
    auto_avg = statistics.mean(auto_waste)
    saving_pct = (manual_avg - auto_avg) / manual_avg * 100

    return {
        "manual_excess_per_creative_won": round(manual_avg),
        "auto_excess_per_creative_won": round(auto_avg),
        "saving_per_creative_won": round(manual_avg - auto_avg),
        "saving_pct": round(saving_pct, 1),
        "simulations": simulations
    }

result = simulate_fatigue_savings()
# 가상 시나리오 결과 예시 (시연용):
# manual_excess_per_creative_won: ~104,000
# auto_excess_per_creative_won: ~21,000
# saving_per_creative_won: ~83,000
# saving_pct: ~80%  ← 피로 소재 '초과 비용'의 80% 절감

해석 주의: 위 시뮬레이션은 "피로 소재에 낭비되는 초과 비용"만 비교한 것이다. 전체 광고비 대비 절감률이 아니라, 피로 구간에서 발생하는 비효율의 80%를 자동 감지로 회수한다는 의미다. 본인 캠페인 수치로 파라미터를 바꿔 돌려보라. (시연용 — 실제 결과는 캠페인 구조에 따라 편차 존재)

소재 교체 시 주의사항

1. 학습 단계 보호: 신규 소재 투입 후 최소 3~5일(또는 노출 8,000회 이상)은 피로도 판단을 보류한다. 학습 단계에서의 지표 변동은 피로가 아니다 — 크리에이티브 테스트 운영체계 참조
2. 동시 교체 제한: 한 캠페인에서 소재를 50% 이상 동시 교체하면 머신러닝 재학습이 발생한다. 최대 30%씩 순차 교체를 권장한다
3. 시즌 효과 구분: 연말, 명절, 세일 시즌에는 전체 CTR이 하락할 수 있다. MCP ads_insights_industry_benchmark로 벤치마크 비교하면 피로와 시즌을 구분할 수 있다

MCP + CLI 도구 선택 가이드

"무엇을 쓸까"를 한눈에 정리한다:

Graph API는 죽었는가? 아니다. 커스텀 attribution window 계산, 대량 배치 처리(1,000+ 소재 동시 조작), webhook 기반 실시간 트리거 등 MCP/CLI가 커버하지 않는 엣지 케이스에서는 여전히 필요하다. 핵심은 기본 워크플로우를 MCP + CLI로 단순화하고, 예외적 케이스에서만 Graph API로 fallback하는 것이다.

실행 체크리스트: 내일부터 시작하기

• [ ] Meta Ads MCP Server 설정 — Claude Desktop 또는 Cursor에 MCP 서버 연결
• [ ] Meta Ads CLI 설치 — META_AD_ACCOUNT_ID, META_ACCESS_TOKEN 환경변수 설정
• [ ] MCP ads_insights_anomaly_signal로 현재 계정의 이상 소재를 첫 스캔한다
• [ ] ads_get_ad_entities로 Frequency ≥ 3.0이면서 CTR이 주간 -20% 이상인 소재를 식별한다
• [ ] CLI meta ads ad list --format json으로 활성 소재 목록을 JSON으로 뽑아본다
• [ ] Claude Code Routines로 매일 09:00 자동 스캔을 설정한다 (또는 위 bash 스크립트를 cron에 등록한다). 첫 2주는 수동 검증과 병행한다
• [ ] 과거 소재의 "Frequency 3.0 도달까지 일수" 평균을 산출하고, backtesting으로 검증한다
• [ ] 소재 제작 리드타임을 역산하여 사전 제작 일정을 캘린더에 설정한다

흔한 실수와 회피 방법

결론: AI 에이전트가 광고를 운영하는 시대

2026년 4월 Meta의 MCP + CLI 동시 출시, 그리고 Anthropic의 Claude Code Routines와 Managed Agents 베타까지 — 이 네 가지가 동시에 등장한 것은 우연이 아니다. "개발자가 코드를 짜서 자동화"에서 "AI 에이전트가 읽고, 판단하고, 실행"으로의 패러다임 전환이 본격화된 것이다.

이 글에서 제시한 에이전틱 피로도 프레임워크를 정리하면:

1. 감지 (MCP): anomaly_signal → ads_get_ad_entities → industry_benchmark로 3단계 자동 스캔. 24~48시간 내 피로 감지 (수동 대비 7~14일 단축)
2. 예측 (Python): 과거 수명 데이터 + walk-forward backtesting으로 피로 시점 선제 예측. MCP로 데이터 수집, Python으로 분석
3. 대응 (CLI): meta ads ad update --status PAUSED --force로 즉시 실행. 피로 초과 비용의 ~80% 회수 (Monte Carlo 시뮬레이션 기준)
4. 자율화 (Routines + Managed Agents): Claude Code Routines로 매일 자동 스캔을 클라우드에서 실행하고, Managed Agents로 90일 backtesting 같은 장시간 분석을 컨테이너에서 자율 수행. cron + bash 스크립트 → 자연어 Routine 한 줄로 교체

핵심은 도구의 수가 아니라 조합이다. MCP가 데이터를 읽고, CLI가 실행하고, Routines가 스케줄을 잡고, Managed Agents가 장시간 분석을 맡는다. 각 도구가 하나의 역할만 담당하는 이 구조가, 결국 사람이 개입하지 않아도 되는 완전 자율 광고 운영의 기반이 된다.

다음 단계로 시그널 엔지니어링 2.0을 함께 읽으면, 피로도 관리와 전환 시그널 최적화를 결합한 종합 전략을 세울 수 있다.

더 읽어보기

• 메타 광고 크리에이티브 테스트 운영체계: 2026 실전 가이드 — 3-3-3 프레임워크와 BAU/테스트 분리 설계
• 메타 광고 소재 OFF 기준, Kill/Trim/Protect/Promote 프레임워크 — Target CPA 기반 소재 종료 의사결정
• 시그널 엔지니어링 2.0 — 메타 광고 알고리즘을 훈련시키는 전략적 데이터 설계 — CAPI 이후의 시그널 최적화
• Agentic Commerce: 메타 광고 감사 — AI 에이전트 기반 광고 운영 자동화

참고 자료

• Meta Ads AI Connectors — Meta 공식 MCP + CLI 소개 (비즈니스 지원 센터)
• Meta Ads CLI Overview — CLI 설치, 명령어 레퍼런스, 자동화 가이드
• Meta Ads MCP Server — MCP 서버 설정 및 도구 목록
• Meta 광고 관리자의 크리에이티브 피로도 가이드 — Meta 공식 피로도 정의 및 권장 사항
• Meta Creative Fatigue and Similarity Score: Complete Guide — Admetrics — Similarity Score와 피로도 상관관계
• How to Detect Ad Creative Fatigue Before It Kills Your ROAS — Adligator — 2026 피로도 감지 체크리스트
• 광고 피로도란 무엇인가요? 진단, 예방 및 해결 방법 — Amazon Advertising — 플랫폼 불문 피로도 개념 정리
• Claude Code Routines — Anthropic — 스케줄/API/웹훅 기반 자동화, 클라우드 실행
• Claude Managed Agents — Anthropic — 장시간 자율 실행 에이전트, 컨테이너 기반 세션

TLDR

• 메타 광고에서 "이 소재를 언제 OFF할까"는 시간 경과가 아니라 누적 지출 대비 Target CPA 배수로 판단해야 통계적으로 성립한다.
• OFF/KEEP 이진 결정 대신 Kill / Trim / Protect / Promote / Keep 5-state 라이프사이클을 쓰면 ATC·VT만 좋은 upper-funnel feeder 소재를 실수로 죽여 퍼널이 흔들리는 사고(운영 커뮤니티 용어로 creative ecosystem effect)를 예방할 수 있다.
• 하루 OFF 상한을 활성 소재의 20%로 묶는 Blast Radius 규칙과, OFF 후 남은 소재의 CTR·blended ROAS를 7일간 감시하는 Guard Mode가 "한꺼번에 너무 많이 끄다 KPI가 흔들리는" 경우의 롤백 경로를 보장한다.
• 규칙을 바꾸기 전에는 3층 게이트(Poisson 오탐률 수학 → walk-forward 시뮬레이션 → Shadow-mode 파일럿 2주)로 검증해서 피봇 리스크를 단계별로 줄인다.

1. 이 글은 누구를 위한 것인가

메타 광고(Meta Ads, 페이스북·인스타그램 광고)를 직접 운영하는 퍼포먼스 마케터, 그로스 팀장, D2C/앱 마케팅 리더를 위한 글입니다. 광고비 월 수백만 원~수억 원을 집행하면서 "이 소재를 언제 끄고 언제 살릴지"를 매일 결정해야 하는 분들 대상입니다.

다음과 같은 증상이 있다면 이 글이 직접적인 도움이 됩니다.

• 일예산을 올렸는데 ROAS(Return on Ad Spend, 광고비 대비 매출)가 몇 주째 목표의 절반 근처에서 정체
• 매니저마다 "이 소재 끄자 / 더 보자"가 갈려서 의사결정이 감(感)에 의존
• "최근 3일 전환 없음"이나 "Frequency(빈도) 4 이상" 같은 규칙을 쓰는데 효과가 애매함
• 소재를 끄고 나면 다른 소재들의 클릭률(CTR)·전환율(CVR)도 같이 떨어지는 일이 반복

이 글에서 소개하는 프레임워크는 실제 캠페인을 돌리면서 반복적으로 마주친 실패 사례들을 역산해서, Meta 공식 문서와 RevenueCat의 High-Velocity Creative Testing Framework, Jon Loomer의 메트릭 가이드 등 공개 레퍼런스를 통합해 정리한 것입니다. 가상 시나리오의 숫자는 그대로 쓰지 말고, 본인 제품의 Target CPA에서 재계산해서 적용하세요.

2. 왜 흔한 OFF 규칙은 ROAS 회복을 막는가

현장에서 자주 쓰이는 소재 OFF 규칙 세 가지를 점검해봅시다.

1. "최근 3일간 전환이 없으면 OFF"
2. "일예산의 5% 이상 소진했는데 ROAS 40% 미만이면 OFF"
3. "Frequency(빈도) 4 이상이면 OFF"

세 규칙 모두 겉으로는 합리적입니다. 실제로는 구조적 결함이 있습니다.

결함 1. 시간은 통계적 단위가 아니다

소재 평가의 단위는 "며칠이 지났는가"가 아니라 "얼마나 많은 관측치를 받았는가"입니다. 메타 AI가 공식 문서에서 학습 단계(Learning Phase)를 "50 conversions per week" 기준으로 설명하는 것도 같은 맥락입니다. 관측치가 부족하면 어떤 판정도 불안정합니다.

가상 시나리오로 확인해봅시다. 제품의 Target CPA가 ₩20,000이고, 일예산 300만 원 캠페인에서 16개 소재가 돌아간다고 합시다.

• 소재 A가 3일 동안 ₩30,000만 받았다면 기대 구매는 ₩30,000 ÷ ₩20,000 = 1.5회. Poisson 분포에서 "운 나빠 0회 관측" 확률 = exp(−1.5) ≈ 22%. 즉 정상 소재도 5번에 한 번은 0회 관측됩니다. 끄는 게 오히려 오판.
• 소재 B가 3일 동안 ₩400,000을 받았다면 기대 구매는 20회. "0회 관측" 확률 = exp(−20) ≈ 0.0000002%. 이건 끄는 게 맞습니다.

같은 "3일 무전환"이지만 전혀 다른 신호입니다. 시간 단위 규칙은 캠페인 내 소재별 예산 편차를 무시하기 때문에 판정이 흔들립니다.

결함 2. "일예산 5%" 기준은 캠페인 크기 의존적이다

일예산 300만 원의 5%는 ₩150,000. 일예산 1,000만 원의 5%는 ₩500,000. 같은 "5%"지만 통계적 의미가 3배 차이 납니다. 캠페인이 스케일업할수록 판정이 느슨해지는 역설이 생깁니다.

결함 3. OFF는 이진 결정이 아니다

가장 심각한 결함입니다. 직접 구매 전환은 못 따오지만 리타겟팅 풀(retargeting pool)을 채우는 upper-funnel(어퍼퍼널, 상단 깔때기) 소재를 CPA만 보고 끄면, 특정 ad set이나 하위 퍼널 소재의 CVR이 흔들리면서 캠페인 blended ROAS가 눈에 띄게 떨어지는 케이스가 반복적으로 관찰됩니다. 운영자 커뮤니티에서는 이걸 "creative ecosystem effect(크리에이티브 생태계 효과)" 또는 "funnel cannibalization in reverse(역방향 퍼널 잠식)"라고 부릅니다.

왜 이런 일이 생기는가 — Lattice + Andromeda 아키텍처

솔직히 말하면 이건 메타가 공식 문서로 인정한 알고리즘이 아닙니다. 2024~2025년 Andromeda(ad retrieval 엔진)와 Lattice(unified ad ranking 아키텍처)가 공개된 이후 에이전시·운영자 사이에서 축적된 경험칙에 가깝습니다. 다만 아키텍처상 개연성은 충분합니다.

• Lattice: 캠페인별·surface(Feed/Reels/Stories)별로 분리되어 있던 모델을 단일 generalist model로 통합한 구조. 즉 한 소재의 성과·노출 데이터가 다른 소재의 ranking에도 영향을 줍니다 (Meta 공식 발표).
• Andromeda: 수백만 개 광고 풀에서 개인화된 후보군을 retrieval할 때 creative embedding의 다양성(creative diversity)이 핵심 시그널 (Engineering at Meta).

현장에서 관찰된 메커니즘은 네 가지로 정리할 수 있습니다.

1. Audience seeding 역할: Upper-funnel 소재가 lookalike·핵심 타겟 확장의 학습을 넓게 피드하기 때문에, 이게 꺼지면 하위 퍼널이 도달할 수 있는 "warm pool"이 축소된다.
2. Attribution spillover: View-through나 multi-touch 기여가 upper-funnel에서 발생하는데, 이게 사라지면 lower-funnel의 표면 CVR은 오르지만 신규 유입이 말라 전체 볼륨이 감소. (이건 엄밀히는 알고리즘이 아니라 측정 이슈.)
3. Creative diversity penalty: Andromeda retrieval 단계에서 다양성이 부족하면 auction 경쟁력이 떨어진다는 관찰.
4. Learning phase 재진입: 소재 구조를 급격히 바꾸면 학습 단계로 되돌아가 전체 delivery가 일시 불안정.

이 중 (1)과 (3)은 Lattice/Andromeda 구조상 개연성이 높습니다. (2)는 측정 모델링 이슈에 가깝고, (4)는 메타 공식 문서가 직접 설명합니다(Significant Edits).

솔직한 스케일 감: "계정 전체가 무너진다"는 표현은 대개 과장입니다. 실제로는 특정 ad set이나 특정 KPI(신규 유입 CVR, CPM 변동 등)가 흔들리는 수준이 대부분이고, 진짜 붕괴는 budget structure·CBO 설정 같은 다른 변수가 겹칠 때 발생합니다. 그래도 Kill 우선순위를 direct-response → upper-funnel 순으로 두는 것은 저비용 안전장치로 그 값어치가 있습니다.

메타 공식 문서 자체도 "개별 광고의 CPA만 보고 판단하지 말고 incrementality test(성과 증분 테스트)로 검증하라"고 권합니다(참고).

3. 모든 임계값은 Target CPA에서 역산한다

프레임워크의 출발점은 단 한 숫자, Target CPA(목표 전환당 비용)입니다. 제품의 손익분기점(BEP, Break-even Point)과 LTV(Lifetime Value, 고객 생애 가치)에서 역산한 "한 건의 전환당 최대 허용 비용"입니다.

가상 제품: 최종 판매가 ₩25,000, 마진 20%, LTV가 재구매 없이 단일 구매에 가까우면:

숫자 자체는 제품마다 다릅니다. 중요한 것은 "왜 이 숫자인가"가 economics에서 나와야 한다는 점입니다. "업계 평균 ROAS 100%"는 검증 불가능한 수식어고, "우리 BEP에서 역산한 CPA ₩20,000"은 틀리면 교정 가능한 주장입니다.

4. Kill Switch — 자본 노출량 기반 세 줄 규칙

Target CPA가 정해지면, 첫 번째 레이어(L1)는 단순한 Kill Switch입니다.

시간 기반 조건은 하나도 없습니다. 오직 그 소재가 얼마나 돈을 태웠는지(자본 노출량, capital exposure)와 무엇을 돌려줬는지만 봅니다. 소재가 작은 예산을 받으면 Kill Switch에 걸리는 데 오래 걸리고, 큰 예산을 받으면 빨리 걸립니다. 소재 크기와 무관하게 공정한 판정이 됩니다.

Poisson 오탐률로 본 안전성

Target CPA ₩20k를 맞추는 정상 소재가 실수로 OFF될 확률(오탐률)을 각 규칙별로 계산:

단일 체크포인트 탐지율이 22%라도, 주 2회 반복 적용 시 8주 누적 탐지율 ≈ 1 − (1−0.22)⁸ ≈ 86%. 오탐을 낮게 유지하면서 반복 체크로 탐지율을 확보하는 구조입니다.

5. 지출 × 구매 룩업표 — 주 2회 리뷰용

두 번째 레이어(L2)는 수식을 뺀 룩업표(lookup table)입니다. 수학은 스크립트가 처리하고, 사람은 표 위치만 찾습니다.

"구매 한 건, 지출 ₩35,000"이 운이 나쁜 것인지 망한 것인지 매니저가 직관으로 판단하는 건 어렵지만, 표 위치 찾기는 인턴도 이사도 같은 결론이 나옵니다. 의사결정의 재현성 확보.

6. Kill / Trim / Protect / Promote — 5-state 라이프사이클

여기가 핵심입니다. L1(Kill Switch)·L2(룩업표)가 "OFF"라고 판정한 소재라도 실제 액션은 네 가지로 갈라집니다. 한 가지가 더 있어서 총 다섯 가지 상태.

Funnel Role 자동 분류 — 소재를 "어떤 역할"로 볼 것인가

단순 ROAS로 Kill을 결정하기 전에 소재의 퍼널 역할을 먼저 분류합니다. 세 가지 지표를 계산:

• 구매 기여(purchase share) = 이 소재의 구매 수 / 전체 캠페인 구매 수
• Add to Cart 기여(ATC share, 장바구니 담기 기여) = 이 소재의 ATC / 전체
• View Content 기여(VC share, 콘텐츠 조회 기여) = 이 소재의 VC / 전체
• View-through 비율(VT ratio, 조회 후 전환 비율) = View-through ROAS / Click-through ROAS

분류 규칙:

• 🎯 direct-response(직접 반응): 구매 기여 ≥ 1% — Kill 1순위
• 🛡 upper-funnel(어퍼퍼널, 상단 깔때기): 구매 기여 < 1% AND (ATC 또는 VC 기여 ≥ 15%) — 리타겟팅 풀 공급 역할, Kill 후순위
• 🤝 brand-assist(브랜드 어시스트): VT ROAS ≥ 2× CT ROAS — View-through로 기여하는 자산형 소재
• ❓ unknown: 데이터 부족

직접 구매는 없지만 VC·ATC 같은 upper-funnel 이벤트를 계정에 15% 이상 공급하는 소재는 feeder(피더, 신규 유입 공급 소재) 역할입니다. CPA만 보고 이걸 끄면 §2의 creative ecosystem effect 리스크가 올라갑니다. 완전 Kill 대신 Trim(예산 감액)이 기본값인 이유입니다. RevenueCat의 BAU vs Testing 프레임워크도 이걸 전제로 설계되어 있습니다.

학습 단계(Learning Phase) 자동 보호

메타는 공식 문서에서 ad set이 significant edit(중요 변경) 이후 약 1주 내 50 results까지 도달해야 학습이 안정화된다고 명시합니다(링크). 이 기간에 CPA만 보고 끄는 것은 판정이 아니라 학습 경로 차단입니다.

자동 감지 규칙 — 둘 중 하나라도 만족하면 무조건 Protect로 올립니다:

1. effective_status = LEARNING 또는 LEARNING_LIMITED
2. 소재 생성/수정 후 7일 이내 AND 7일 구매 < 50

2024년까지의 학습 단계가 "기다림"에 가까웠다면, 2025년 Andromeda(안드로메다, 메타의 새 추론 엔진) 환경에서는 "적극적 교육" 성격으로 바뀌었습니다. 의미론적 다양성(Semantic Diversity)을 가진 소재를 학습 초기에 충분히 공급하는 것이 중요해졌고, 자동 Protect는 이 권고와 일치합니다.

Blended Health Safety Net — 계정 전체 건강 지표

매일 판정 직전에 캠페인 전체 7일 ROAS vs 직전 7일 ROAS를 비교합니다. 10% 이상 하락이면 "declining" 플래그를 세우고, 그 날은 모든 Kill 후보를 Protect로 다운그레이드합니다.

이유는 단순합니다. 캠페인 전체 지표가 흔들리는 중에 소재를 더 빼면 퍼널이 한 번 더 흔들릴 위험이 커집니다. 원인 분석이 먼저지 소재 OFF가 먼저가 아닙니다.

7. 크리에이티브 피로도(Creative Fatigue) 조기 탐지

Frequency(빈도) 4 이상을 단독 컷 기준으로 쓰는 건 문제가 있습니다. 캠페인 누적 Frequency는 소재 수명이 길수록 자연스럽게 올라갑니다. 그래서 피로도는 캠페인 전체가 아니라 개별 소재 기준으로 봐야 하고, Frequency 하나가 아닌 네 가지 신호를 조합해서 판단합니다.

2개 이상 동시 발생 → Refresh(리뉴얼) flag. 즉시 OFF가 아니라 다음 제작 브리프에 "리뉴얼 버전 제작" 항목으로 추가합니다. 피로도는 "조금 쉬었다가 리뉴얼 버전으로 재등판"이 맞는 대응입니다.

8. Blast Radius & Guard Mode — 한꺼번에 많이 끄면 안 되는 이유

라이프사이클이 Kill로 분류한 소재가 10개라고 해서 하루에 10개를 다 끄면 안 됩니다. Meta AI는 소재가 갑자기 사라지면 예산을 급하게 재분배합니다. 재분배 과정에서 학습이 흔들립니다.

Blast Radius 규칙

• 하루 Kill 상한 = 활성 소재 수 × 20%
• 활성 16개면 하루 최대 3건
• 지난 3일 이미 Kill한 수도 합산
• Kill 우선순위: direct-response → unknown → brand-assist → upper-funnel
• 같은 role 내에선 누적 지출 큰 것부터 (출혈 큰 것 우선)
• 한도 초과분은 "Deferred" 섹션으로 이월, 내일 재평가

Guard Mode — Kill 후 7일 모니터링

Kill을 실행한 직후부터 남은 활성 소재의 가중평균 CTR과 blended ROAS를 7일간 추적합니다.

• 가중평균 CTR이 baseline 대비 −15% 이상 하락, 또는
• blended ROAS가 −10% 이상 하락

→ 즉시 경고. 어제 Kill한 소재 중 upper-funnel/brand-assist 후보를 rollback 검토. 원인 분석 전까지 추가 Kill 중단. 이게 incrementality(증분성) 측정이 없는 환경에서 할 수 있는 최소한의 대체 안전장치입니다.

9. 수동 6-step 결정 트리 — Kill 실행 직전 체크

자동 규칙을 모두 통과해도, 실제로 Kill을 실행하기 직전에 매니저가 여섯 줄 체크리스트를 읽습니다. 하나라도 "Yes"면 상위 state로 이동합니다.

1. ☐ 최근 7일 내 significant edit(중요 변경) / 신규 소재 추가 / 큰 budget 변경이 있었나? → Protect (학습 안정 대기)
2. ☐ 유사 ad set·유사 audience로 구조가 분산되어 있나? → 구조 단순화 후 재평가
3. ☐ 이 소재를 끄면 blended CPA·total purchases·retargeting pool·new customer rate가 나빠질 징후가 있나? → Protect 또는 Trim
4. ☐ 최종 CPA만 나쁘고 CTR·Hook Rate·ThruPlay만 좋나? → Kill 후보 확정 (vanity metric)
5. ☐ 대체 winner 또는 비슷한 angle이 있나? → Kill 또는 강한 Trim. 없으면 제한 예산으로 Explore 유지
6. ☐ 실험 풀에서 downstream 보조 신호·scale 가능성이 확인되나? → Promote

자동 판정과 사람 판단을 직렬로 묶는 게 중요합니다. 알고리즘 세계에서 사람의 눈이 마지막 안전장치입니다.

10. BAU vs Exploration — 승자 풀과 탐색 풀 분리

현장에서 가장 흔한 실수는 winner 소재와 신규 테스트 소재를 같은 캠페인에 섞어두는 것입니다. 이 구조에서는 Meta AI가 CBO(Campaign Budget Optimization, 캠페인 예산 최적화) 환경에서 최근 성과가 좋은 한두 개 소재에 예산을 몰아주고, 신규 테스트 소재는 지출을 거의 못 받거나 받자마자 cold-start 성과로 죽어버립니다.

해결책은 두 풀을 분리하는 것입니다.

• BAU(Business As Usual) 풀: 검증된 winner만 두고 예산 70~80% 집중
• Testing 풀: 신규 소재 3~5개씩 병렬 테스트. 별도 예산 20~30% 할당

RevenueCat 프레임워크에서는 Testing 풀의 승격 기준을 10,000 impressions 이상 AND 최근 2일간 baseline CPT(cost per trial, 무료 체험 전환 비용) 이하로 정의합니다. 이 기준을 만족한 소재만 BAU로 승격하고, BAU의 한 자리를 내줍니다.

Big Swing Testing — 크게 흔드는 테스트

RevenueCat의 2025 가이드는 "small A/B test의 함정"을 지적합니다. 헤드라인 한 줄만 바꾼 variation 10개를 돌리면, 결과는 대부분 유의미하지 않게 나오고 시간만 흘러갑니다. 권고는:

• Big swing test: 포맷·앵글·톤 수준에서 크게 다른 3~5개만 병렬
• 포맷(format)을 먼저 정하고 그 안에서 variation (정적 이미지 vs 15초 UGC 영상 vs 캐러셀 vs 텍스트 벽)
• Placement(피드 vs 릴스 vs 스토리) 별로 ad set을 분리해서 각 플레이스먼트에 맞는 소재만 돌리기

Placement Matching — 피드 vs 릴스의 성질 차이

흔한 오해: "Instagram Reels가 CPM 싸고 노출 많으니 효율 좋다". 실제로는 릴스 오디언스는 젊고 intent가 낮아 trial-to-subscription 전환율이 낮습니다. 반대로 Facebook Feed는 CPM이 비싸도 intent 높은 오디언스라 최종 구매 전환율이 더 나올 수 있습니다. RevenueCat 가이드는 "You'll be surprised how often Facebook is more profitable than Instagram"이라고 썼습니다.

즉 Placement matching(플레이스먼트와 소재 성격 매칭)이 중요합니다. "Reels 먼저 돌리고 안 되면 Feed"가 아니라, 소재 목적에 따라 플레이스먼트를 먼저 선택하는 구조.

11. 3층 게이트 — 규칙 변경을 검증하는 방법

"이 프레임워크가 기존 방식보다 낫다고 어떻게 증명하나요?"

이 질문에 "경험적으로", "업계 best practice", "일반적으로 이렇습니다" 같은 답으로 넘어가면 나중에 반드시 후회합니다. 대규모 규칙 변경에는 3층 게이트 스택으로 검증합니다.

게이트 A — Poisson 오탐률 수학 점검 (30분)

각 규칙의 오탐률을 계산. 위에서 본 표 그대로입니다.

통과 조건: 평균 오탐률 < 10% AND 2배 부진 소재의 주 2회 적용 탐지율 > 60%

게이트 B — Walk-forward 시뮬레이션 (1일)

캠페인 시작일부터 현재까지의 주간 소재 데이터를 Meta Graph API로 수집. 각 날짜 t마다 t−1까지의 누적 지표로 새 규칙 적용 → OFF 결정 로그 → 이후 실제 성과와 대조.

• 절약 추정 = Σ(우리 OFF 시점 ~ 실제 OFF 시점의 지출) × ROAS 부족분
• False positive = 우리가 OFF했는데 이후 ROAS ≥ 1.0으로 회복한 건수
• 보수적 가정: Meta의 예산 재분배 없이 그대로 돌았다고 가정 (실제 절약은 이보다 큼)

통과 조건: 합리적 절약액 AND False positive ≤ 2건. 3건 이상이면 인큐베이션 창을 넓히는 방향으로 규칙 튜닝.

게이트 C — Shadow-mode 파일럿 (실운영 2주)

A·B 통과 후에도 전면 도입은 금물. 2주 동안 스크립트는 권고 리포트만 생성하고, 운영자는 기존 방식 그대로 실결정. 2주 후 일치율 평가:

• ≥ 80% → 전면 도입
• 60 ~ 80% → 불일치 5건 분석, 임계값 재튜닝, 1주 추가 파일럿
• < 60% → 프레임워크 재설계

안전 장치: 파일럿 중 캠페인 주간 ROAS가 baseline 대비 −10% 이하로 떨어지면 즉시 중단.

이 3층을 통과하지 못한 규칙은 전면 적용하지 않습니다. 피봇은 한 번에 한 층씩 리스크를 줄여가며 해야 합니다.

12. 바로 적용할 수 있는 5주 체크리스트

1주차 — 숫자 정리

• ☐ 제품의 BEP CPA, LTV, Target ROAS를 economics에서 역산
• ☐ 현재 캠페인의 7일 ROAS·CPA·Frequency·활성 소재 수 기록 (baseline)
• ☐ 소재 네이밍 규칙 정립 (YYMMDD-prefix-handle 같은 패턴)
• ☐ 소재별 funnel_role 태깅 (direct-response / upper-funnel / brand-assist / unknown)

2주차 — 게이트 A + B

• ☐ 현재 휴리스틱의 Poisson 오탐률 계산
• ☐ 과거 4~6개월 캠페인 데이터로 walk-forward 시뮬 (Meta Graph API time_increment)
• ☐ 예상 절약액·False positive 건수 확인 → 인큐베이션 창 튜닝

3주 + 4주차 — 게이트 C (Shadow pilot)

• ☐ 자동 triage 리포트 매일 생성. 실결정은 기존 방식 유지
• ☐ 매일 권고 vs 실결정 일치율 기록
• ☐ 캠페인 주간 ROAS를 baseline과 비교 모니터링

5주차 이후 — 전면 도입 + 월별 튜닝

• ☐ 일치율 80%+면 자동 triage를 운영 표준으로 전환
• ☐ 월 1회 Target CPA·LTV 재확인, 임계값 튜닝
• ☐ 분기별로 게이트 B를 자체 데이터로 재실행 → 규칙 드리프트 점검
• ☐ BAU vs Testing 풀 분리 검토 (v1.3 효과 검증 후 구조 피봇)

마치며 — 규칙은 계산되고, 검증되고, 감시되어야 한다

알고리즘 광고 환경에서 소재 의사결정은 세 가지 성질을 동시에 가져야 합니다.

1. 계산 가능(Calculable): 임계값이 economics에서 역산되고, 오탐률이 수학적으로 추산된다
2. 검증 가능(Verifiable): 규칙이 과거 데이터에 적용됐을 때 얼마를 절약했을지 숫자로 나온다
3. 감시 가능(Observable): 적용 이후 계정 건강 지표를 실시간 추적하며 rollback 경로를 남긴다

이 세 가지를 모두 갖춘 프레임워크는 감(感)에 의존하지 않고 팀에 이식 가능한 시스템이 됩니다. 오늘 인턴이 돌려도, 내일 새 매니저가 돌려도 같은 결론이 나오는 구조입니다.

가장 반복적으로 확인한 원칙은 이것입니다.

"끄면 계정이 좋아진다"와 "끄면 계정이 무너진다"의 차이는 소재 자체보다도 학습 상태, 구조 분산, incrementality 측정 부재에서 오는 경우가 많다.

그래서 개별 ad 하나의 CPA만 보고 결론내리기보다, blended result와 holdout 성격의 incrementality 검증을 함께 봐야 합니다.

참고 자료

Meta 공식 문서

• About the Learning Phase (머신 러닝 단계 정보)
• Significant Edits and Learning Phase
• Best Practices for Ads Delivery
• Audience Fragmentation
• About Incrementality Tests

메타 아키텍처 (Lattice / Andromeda)

• Engineering at Meta: Andromeda — Next-Gen Personalized Ads Retrieval — retrieval 엔진의 creative embedding 다양성 설명
• Meta Business: AI Innovation in Meta's Ads Ranking (Lattice) — surface·objective 통합 generalist model

프레임워크·사례

• RevenueCat: High-Velocity Creative Testing Framework — BAU vs Testing 분리, ICE score, 10K impressions baseline
• RevenueCat: Meta Ads in 2025 — AEM, Big swing testing, Placement matching, UGC evolution
• Jon Loomer: Effective Meta Advertising Metrics — secondary vs desired action metrics
• Motion Agency / Common Thread Collective / Foxwell Digital — creative diversity 기반 Meta Ads 운영 케이스 스터디를 자주 공개하는 해외 에이전시 (검색: "[에이전시명] creative diversity Meta")

📞 퍼포먼스 마케팅 컨설팅

메타 광고 소재 의사결정을 시스템으로 만들고 싶다면:

• 📧 Contact Form
• 📅 30분 예약

🎁 오픈소스 템플릿 — meta-ads-triage-template

이 글에서 소개한 Kill/Trim/Protect/Promote 라이프사이클을 구현한 Node.js 스크립트 템플릿을 MIT 라이선스로 공개했습니다. 일일 triage 리포트 생성, 태그별 성과 피벗, walk-forward 백테스트 전부 포함.

github.com/retention-corp/meta-ads-triage-template →

.env에 Meta Graph API 토큰과 캠페인 ID만 넣으면 바로 실행 가능합니다. scripts/lib/rules.mjs의 ECONOMICS 상수를 본인 제품의 Target CPA로 수정하는 것이 유일한 필수 커스터마이즈 단계입니다.

뉴스레터 구독 → (주간 퍼포먼스 마케팅·그로스 인사이트)

TLDR

• 어제 쓴 "A2A 시대의 Human In The Lead" 포스트 발행 직후 두 가지 새 실수가 터졌다. Ghost internal tag(#blog-col) 를 일반 태그로 오해, 그리고 Ghost + Mailgun 이중 클릭 트래킹으로 뉴스레터 링크가 블로그로 리다이렉되지 않음.
• 더 아픈 지점: 내가 AI에게 "재발 방지 룰"을 같이 짜게 했더니 AI가 반대 방향 가드(# 자동 strip)를 제안할 뻔했다. 운영 직감이 없으면 잘못된 자동화를 굳힐 뻔한 순간.
• 결과적으로 스킬 4개 + 메모리 2개 + 스케줄링 스크립트 1개를 교정으로 다시 갱신. 고정 규칙을 만들 때는 AI 한 번, 사람 한 번의 왕복 검증이 필요하다.
• 솔로 파운더 체크리스트: 뉴스레터 발송 전에 (a) 테스트 preview, (b) Mailgun 클릭 트래킹 상태, (c) internal tag prefix 형태 세 가지를 직접 본다.

1. 첫 발행의 두 가지 사각지대

어제 "AI가 내 AI를 팩트체크한 날" 포스트를 retn.kr/ghost 에 예약 발행했다. 발행까지는 깔끔했는데, 두 가지가 어긋났다.

블로그 목록 페이지(retn.kr/blog)에 글이 안 떴다. Ghost 관리자에서 확인해 보니 태그는 전부 있는데 나열되지 않았다. 원인: retn.kr/blog 라우트는 #blog-col 이라는 internal tag 로 필터링 중인데, 내가 넣은 태그는 blog-col (해시 없음) 이었다. Ghost에서 #-prefix는 UI 장식이 아니라 "이 태그는 내부용" 이라는 load-bearing 마커다.

뉴스레터에서 본문 링크가 리다이렉 되지 않았다. 구독자들이 이메일에서 블로그 링크를 누르면 404 비슷한 화면으로 튕겼다. 원인: Ghost의 네이티브 클릭 트래킹 + Mailgun의 클릭 트래킹이 같은 링크를 두 번 wrap 하면서 최종 URL이 꼬였다.

2. 실수 1 — # 이 메타가 아니라 본질이었다

Ghost의 tag 시스템에는 두 종류가 있다.

retn.kr/blog 의 routes.yaml 은 internal #blog-col 로 컬렉션을 만든다. 내가 API 호출로 {"name": "blog-col"} 를 보내면 Ghost는 이걸 다른 태그(public) 로 저장해 버린다. Slug가 같아 보이지만(blog-col), visibility가 다르고 라우트가 못 잡는다.

더 흥미로운 건 slug 규칙. #blog-col 의 slug 는 Ghost가 hash-blog-col 로 치환한다. # 이 단순 제거되는 게 아니라 hash- 로 바뀌는 것. 이 규칙을 모르면 검증 코드도 틀린다.

3. 실수 2 — 클릭 트래킹은 한 군데서만

이메일 링크 체인이 꼬인 원리는 이렇게 생겼다.

해결: Mailgun 도메인 설정에서 Click Tracking을 OFF. Ghost의 네이티브 트래킹은 남겨 둬서 뉴스레터 내부 분석은 유지. Open tracking은 Mailgun 쪽을 켜도 충돌 없음.

4. 진짜 아픈 지점 — AI 가 제안한 재발 방지가 반대 방향이었다

위 두 문제를 발견한 직후, 나는 내 AI에게 "재발 방지 패턴을 같이 짜자" 고 했다. AI의 첫 제안 중 하나:

"ghost_schedule.py 에 태그 sanitize 로직 추가: 입력된 태그 이름 앞에 # 이 있으면 lstrip('#') 으로 제거한 뒤 저장. 사용자가 실수로 # 을 붙여도 방어됨."

이 가드를 심었다면 앞으로 모든 포스트에서 #blog-col 이 blog-col 로 바뀌어 더 이상 /blog 에 안 뜨는 회귀가 됐을 것이다. AI는 "# 은 사용자가 잘못 붙인 것" 이라는 잘못된 전제 위에서 답을 만들었다.

운영에서 실제 화면을 본 사람만이 "아니, # 은 Ghost가 이걸 internal 로 취급하라는 신호" 라고 되돌려 줄 수 있다. 이게 Human In The Lead의 두 번째 층 — 규칙을 만들 때의 검증이다.

5. 실제로 무엇을 고쳤나

어제 세션의 결과를 덮어써서 다음 파일들이 최종 형태가 됐다.

• ~/.claude/skills/retention-style/SKILL.md — 이미지 전략 섹션을 "최대 3장" 상한으로 명문화. 매 포스트 3장을 강제하지 않음.
• ~/.claude/skills/blog-publisher/SKILL.md — publish checklist에 #blog-col (해시 포함, internal tag 마커), email_segment=all, ?newsletter=<slug> 세 항목 추가.
• ~/.claude/skills/ghost-api-utils/SKILL.md — internal tag 저장 규칙 (# 유지, slug는 hash-... 로 변환) 문서화. "lstrip('#') 하지 말 것" 명시.
• memory/reference_ghost_blog_publishing.md — Ghost retn.kr 퍼블리싱 체크리스트 전용 메모리.
• /tmp/ghost_schedule.py — EXTRA_TAGS 에 #blog-col 포함 + 응답의 visibility=internal 검증 주석.

6. 한 번 더 — 테스트 메일은 Post settings 에 없다

이 포스트 자체를 예약 전에 테스트 메일로 확인하려다 또 시간을 잡아먹혔다. Ghost 에서 "Send test email" 버튼은 Post settings (톱니바퀴) 안에 없다. 에디터 상단의 별도 "Preview" 액션에서만 나온다.

올바른 경로:

1. 스케줄된 포스트라면 먼저 Unpublish 해서 draft 로 되돌린다 (scheduled 상태에서는 test email 버튼이 비활성화).
2. 에디터 상단 오른쪽 "Preview" 를 누르면 모달이 뜨고 Web / Email / Desktop / Mobile / Member tier 탭이 나타난다.
3. Email 탭 에서 상단 오른쪽 "Test" 버튼을 눌러 본인 주소로 발송.

메일이 실제로 도착하고 링크가 정상 리다이렉 되는지까지 확인한 뒤 스케줄을 복원한다.

이 순서 하나만 알고 있어도 다음 포스트부터 발행 전 체크에 10 초면 끝난다. 아는 사람한테는 당연하지만 "아는 사람" 이 되는 데 나는 또 한 번 삽질 했다.

7. 메타 교훈 — A2A 피드백 루프에는 두 번째 사람이 필요하다

A2A 시대의 작업 흐름이 이렇게 된다.

1. 사람이 의도를 말한다.
2. AI가 실행 + 규칙을 같이 짠다.
3. 사람이 규칙을 검증한다. ← 이 단계가 빠지면 틀린 자동화가 굳는다.

어제 내가 놓친 건 1번이 아니라 3번이었다. "# 은 실수가 아니라 load-bearing marker" 라는 한 문장을, 내가 직접 화면을 보지 않았으면 AI는 영영 모르고 반대로 굳혔을 것이다.

솔로 파운더가 지켜야 할 최소 루프:

• 뉴스레터 발송 전에 preview email을 내 주소로 받아 실제 링크를 클릭해 본다.
• 스케줄링 스크립트가 발행하는 첫 한 건은 무조건 육안 확인.
• AI가 "자동 방어" 류 코드를 제안할 때, 그 제안이 뭘 안 하게 막는지 까지 읽는다. "무엇을 하는가" 보다 "무엇을 회수하는가" 가 더 중요하다.

📞 AX 도입 상담

이 글처럼 AI를 실제 운영 파이프라인에 태우다가 벌어지는 일들을 정리·설계해 드립니다.

• 📧 Contact Form
• 📅 30분 예약

핵심 주장

하루 종일 분명 바빴는데, 저녁이 되면 남은 게 적다고 느끼는 날이 있다. 메일 하나, 답장 하나, 급한 확인 하나가 계속 끼어들고, 겨우 다시 붙으려 하면 또 다른 알림이 뜬다. 그래서 사람은 쉽게 스스로를 탓한다. 왜 이렇게 산만하지, 왜 예전보다 오래 못 버티지.

이 책이 주는 첫 반전은 단순하다. 당신 탓만은 아니라는 것이다. 요한 하리는 집중이 무너지는 이유를 성격이나 의지력 부족에서 찾지 않고, 사람이 오래 붙잡고 생각하기 어렵게 만든 생활 조건과 노동 방식의 귀결에서 찾는다.

저자의 방법론과 배경

요한 하리는 영국 출신 저널리스트로, 한 주제를 학자 인터뷰와 현장 사례, 자기 실험으로 길게 밀어붙이는 조사 저널리즘 방식에 강하다. 그는 2022년 TED 강연과 가디언 인터뷰에서 이 책을 위해 250명 이상을 인터뷰했고, 3개월 동안 스마트폰과 SNS를 끊고 떨어져 지내는 실험도 했다고 설명했다. 전작 《Lost Connections》가 우울을 개인 결함이 아니라 관계와 환경의 붕괴로 읽었다면, 이번 책은 같은 시선을 주의력으로 옮긴다.

책의 뼈대 / 원인 카탈로그

이 책의 뼈대는 또렷하다. 집중을 흐리는 요인을 성격 결함이 아니라 세 층위로 나눠 배치한다.

매일 몸으로 느끼는 주원인

• ① 속도·전환·필터 증가 — 일이 자주 끊기고, 맥락을 다시 불러오는 데 시간이 샌다.
• ② 플로우 붕괴 — 깊게 빠져 일하는 상태를 유지하기 어렵다.
• ③ 장시간 읽기 감소 — 긴 호흡의 텍스트를 끝까지 읽는 근육이 약해진다.

천천히 누적되는 보조원인

• ④ 수면 부족
• ⑤ mind wandering 상실 — 멍하게 흐르며 생각을 잇는 시간이 사라진다.
• ⑥ 만성 스트레스
• ⑦ 잔혹한 낙관주의 — 개인이 더 노력하면 다 해결된다고 믿게 만드는 문화.

저자가 제안하는 정책 레벨 해법

• 플랫폼 설계 변화
• 노동 환경 개편
• 교육과 놀이 조건의 회복

이 주장에는 근거가 붙는다. UCI의 Gloria Mark 교수는 2023년 《Attention Span》에서 성인이 한 화면에 머무는 평균 시간이 2004년 2.5분에서 2021년 47초로 줄었다고 추적한다. MIT Picower Institute의 Earl Miller는 인간이 실제로는 멀티태스킹을 잘하지 못한다고 말해왔고, 책은 이를 바탕으로 여러 일을 동시에 하는 듯 보여도 실은 자주 끊길 뿐이라고 짚는다. 전 Google 디자인 윤리학자 James Williams는 2018년 《Stand Out of Our Light》에서 플랫폼이 사람의 주의를 캐내는 자원처럼 다룬다고 비판한다. 미국 10대가 한 과제에 평균 65초 정도 머문다는 수치도 등장하는데, 이는 하리가 인용한 학교 관찰 연구이며 정확한 원 연구명은 책 본문 각주에 붙어 있다.

타겟 독자에게 왜 특히 아픈가

혼자 여러 일을 맡는 사람에게 이 책이 더 아픈 이유는, 일이 많아서보다 자주 잘리기 때문이다. 시니어 엔지니어라면 구현 중간에 코드리뷰 알림과 메신저 요청이 끼어드는 순간을 떠올리면 된다. 잠깐 딴 걸 보고 돌아오는 데 드는 시간, 엔지니어라면 캐시 미스(방금 쓰던 맥락이 사라져 다시 불러와야 하는 낭비) 같은 대가다. PM은 문서를 쓰다가 즉답 요청이 들어오면 우선순위 판단의 흐름이 깨진다. 혼자 운영과 제작을 함께 맡는 사람은 작은 문의 몇 건이 하루의 가장 중요한 산출물을 밀어낸다.

약점과 해결되지 않는 질문

약점도 있다. 첫째, 사회와 제도 수준의 해법은 설득력 있지만, 이번 주 마감을 버텨야 하는 사람이 어디부터 바꿔야 하는지 우선순위는 비교적 얇다. 둘째, ADHD 증가처럼 민감한 주제는 폭넓게 다루지만, 진단과 환경의 경계가 실제 현장에서 어떻게 구분되는지는 더 세밀했어도 좋겠다.

이 책의 주장, 48시간으로 검증해볼 수 있다

독자는 이 책을 믿을지 말지 오래 고민할 필요가 없다. 이틀만 확인 시간을 고정하고, 동시에 여는 창 수를 줄이고, 하루 두 번 90분 블록을 지켜보면 된다. 그리고 결과를 의지가 아니라 환경 변화와 연결해 기록해보면 된다. 자발적 피드 확인 횟수, 긴 읽기 지속 시간, 끊긴 뒤 다시 붙는 데 걸린 시간이 달라진다면, 이 책의 핵심은 추상이 아니라 일상 설명이 된다.

장점

• 집중 문제를 생산성 팁이 아니라 노동 환경, 플랫폼 설계, 교육 조건까지 넓혀서 보게 만든다.
• 연구자 이름과 현장 사례가 많이 붙어 있어 가벼운 동기부여서보다 훨씬 논쟁거리가 풍부하다.
• 긴 글을 못 읽는 이유, 자주 끊기는 피로, 상시 응답 문화의 압박을 한 프레임으로 묶어준다.
• 혼자 운영과 실행을 동시에 맡는 독자에게 '왜 바빴는데 진척이 적은가'를 설명하는 언어를 준다.

단점

• 당장 오늘 일정표에 꽂아 넣을 실천 체크리스트는 독자가 따로 정리해야 한다.
• 정책과 사회 해법의 비중이 커서 개인 루틴서처럼 즉각적인 손맛을 기대하면 느리게 읽힐 수 있다.
• 넓은 범위를 다루는 만큼 각 원인을 깊게 파고드는 전문서의 밀도와는 결이 다르다.

핵심 요약

• 산만한 날에는 자신을 탓하기 전에 알림, 응답 규칙, 탭 수부터 점검한다.
• 깊은 일은 남는 시간에 하는 게 아니라 먼저 블록으로 고정해야 지켜진다.
• 긴 읽기 지속 시간과 자발적 피드 확인 횟수만 기록해도 주의가 새는 패턴이 드러난다.
• 개인 습관과 함께 팀의 응답 기대치, 회의 길이, 기본 알림값도 같이 손봐야 오래 간다.

비슷한 책과의 비교

• 《벌거벗은 정신력》(요한 하리): 같은 저자가 집중에서 감정 통제와 정신력으로 주제를 넓혀 간다.
• 《딥 워크》(칼 뉴포트): 이 책이 환경 비판과 사회적 조건을 강조한다면, 《딥 워크》는 개인 일정 설계와 몰입 루틴에 더 강하다.
• 《도파민네이션》(애나 렘키): 같은 산만함을 보상 체계와 중독의 관점에서 더 날카롭게 읽고 싶을 때 맞닿는다.
• 《브레인포그》(질 P. 웨버): 원인 분석보다 회복 행동과 생활 매뉴얼이 급한 독자에게 더 실용적일 수 있다.
• 《다시, 어떻게 읽을 것인가》(나오미 배런): 긴 읽기와 디지털 독서 습관만 따로 깊게 파고들고 싶다면 좋은 연결선이 된다.

이 책, 누가 읽으면 좋을까

추천 독자

• 시니어 엔지니어: 구현 시간보다 코드리뷰, 메신저, 짧은 확인 작업이 자꾸 흐름을 끊는다고 느끼는 사람
• PM / 기획자: 문서 작성과 의사결정 사이에 즉답 요청이 계속 끼어들어 생각의 길이가 짧아진 사람
• 혼자 운영하는 1인 사업자·크리에이터: 문의, 제작, 정산, 홍보를 한날에 다 처리하다가 중요한 한 건이 늘 뒤로 밀리는 사람

추천하지 않는 독자

• 짧은 요약과 10가지 습관만 바로 뽑아가고 싶은 독자
• 사회적 맥락보다 개인 시간관리 팁만 원하는 독자

이 책의 주장, 48시간으로 검증해볼 수 있다

기본 규칙 (48시간 동안 지킨다)

• 메신저·메일·피드 확인은 오전 9시·오후 1시·오후 5시 3회로 고정
• 그 외 시간에는 지금 하는 일과 직접 관련된 창만 연다
• 하루에 90분 집중 블록 2개 이상 확보

측정 지표 (책의 어떤 원인과 짝지어 보는가)

직군별 예시 (내가 이 중 어디에 해당하든, 규칙은 같다)

• 엔지니어: 1순위로 끌 것은 코드 리뷰 푸시 알림. 지키는 블록은 오전 90분 구현 블록. 측정 KPI는 "한 브랜치에서 커밋이 끊기지 않은 연속 시간".
• PM / 기획자: 1순위로 끌 것은 즉답 요구 슬랙 멘션. 지키는 블록은 오후 60분 문서·우선순위 블록. KPI는 "오늘 완료한 '로드맵 의사결정' 건수".
• 1인 사업자 / 크리에이터: 1순위로 끌 것은 결제·문의 외 일반 알림. 지키는 블록은 오전 90분 제작 블록. KPI는 "하루 끝내기로 한 산출물 1건의 완료 리드타임".

해석: 시스템 때문인가, 의지 때문인가

지표가 좋아졌을 때 옆에 이유를 두 열로 쓴다. 왼쪽은 "환경을 바꿔서 좋아졌다"(알림 차단, 블록 고정 등), 오른쪽은 "내가 의지로 참았다". 왼쪽에 체크가 몰리면 책 주장이 내 환경에서도 맞다.

지금 읽어야 하는 이유

2026년 2분기, 생성형 AI IDE 알림과 메신저 AI 요약이 상시로 끼어드는 워크플로에서 에디터·브라우저·채팅창을 동시에 켜두고 일하는 사람에게 이 책은 왜 하루가 짧게 끊기는지 가장 현실적으로 설명한다.

쿠팡에서 《도둑맞은 집중력》 보기

파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음

자주 묻는 질문

이 책은 결국 스마트폰 탓만 반복하는 것 아닌가?

그렇게 오해하기 쉽지만, 실제로는 훨씬 넓은 지도를 준다. 스마트폰은 입구일 뿐이고, 책이 겨누는 대상은 수면 부족, 긴 읽기의 붕괴, 상시 응답을 요구하는 노동 문화, 놀이와 멍한 사유 시간의 감소, 플랫폼의 설계 유인까지 포함한 생활 전체다. 그래서 디지털 디톡스 안내서로 읽으면 절반만 읽는 셈이다. 오히려 중요한 포인트는 “왜 개인 결심이 자꾸 실패하는가”에 있다. 휴대폰을 치워도 회의가 잘게 쪼개지고, 답장 속도가 성실함의 척도가 되는 조직에서는 같은 문제가 반복된다. 이 책이 약간 불편한 이유도 여기 있다. 기기 하나 끊는 것으로는 부족하고, 내가 일하는 방식과 주변의 기대치까지 건드려야 한다는 말을 하기 때문이다. 결국 초점은 기계 비난이 아니라 주의를 둘러싼 환경 전체다.

《Lost Connections》와 이어 읽을 만한가?

꽤 자연스럽게 이어진다. 요한 하리의 관심사는 늘 ‘왜 개인의 문제처럼 보이는 고통을 사회와 환경의 언어로 다시 읽어야 하는가’에 가까웠다. 《Lost Connections》에서 그는 우울과 단절의 관계를 추적했고, 이번 책에서는 같은 접근을 주의력에 적용한다. 그래서 두 책을 함께 읽으면 하리의 강점과 한계가 동시에 보인다. 강점은 넓은 취재망과 서사 구성력이고, 한계는 주장을 밀어붙이는 힘이 강한 만큼 반론을 더 보고 싶은 독자에겐 약간 단선적으로 느껴질 수 있다는 점이다. 그래도 연결해 읽을 이유는 충분하다. 전작이 “왜 이렇게 무기력한가”를 묻는다면, 이번 책은 “왜 이렇게 잘 끊기는가”를 묻기 때문이다. 감정과 집중의 바닥이 사실 같은 생활 조건에서 흔들린다는 점도 함께 보인다.

한국어판 번역은 어떤 편이고, 한국 업무 문화에도 잘 맞나?

번역은 비교적 매끄러운 편이다. 지나치게 학술 용어로 얼리지 않아서 일반 독자도 큰 무리 없이 따라간다. 다만 읽는 리듬은 에세이보다 취재 논픽션에 가깝기 때문에, 빠른 자기계발 문장에 익숙한 사람은 초반보다 중반을 더 천천히 읽게 될 수 있다. 한국 업무 문화와의 궁합은 오히려 강한 쪽이다. 이유는 단순하다. 국내 조직에서는 즉답 압박, 촘촘한 메신저, 짧은 회의와 확인 요청이 일상화된 경우가 많아서, 책이 말하는 “일이 많아서가 아니라 자주 끊겨서 지친다”는 진단이 더 생생하게 들어온다. 다만 해외 사례 중심이라 한국 기업의 평가 제도나 메신저 관행을 직접 다루진 않는다. 그래서 가장 잘 읽는 방법은 번역의 논지를 그대로 받고, 적용은 자기 팀의 응답 문화와 회의 규칙으로 다시 바꾸는 것이다.

《딥 워크》나 《아토믹 해빗》과 충돌하는 지점은 어디인가?

충돌은 “개인이 바꿀 수 있는 것”의 범위를 어디까지 보느냐에서 생긴다. 《딥 워크》나 《아토믹 해빗》은 시간 블록, 습관 연결, 환경 설계처럼 개인이 오늘 바로 실천할 수 있는 처방에 매우 강하다. 반면 《도둑맞은 집중력》은 그런 처방이 왜 자주 무너지는지 묻는다. 플랫폼이 사람의 주의를 붙잡아두는 방향으로 돈을 벌고, 일터가 상시 응답을 기본 예절처럼 요구하면, 개인 습관만으로는 회복에 سق한이 생긴다는 것이다. 그래서 둘은 대립이라기보다 해상도가 다르다. 개인 루틴 책은 손과 발을 움직이게 하고, 이 책은 왜 바닥이 기울어져 있는지 보여준다. 한 가지 흥미로운 차이는 죄책감의 방향이다. 습관 책은 실패한 날 다시 조정하라 말하고, 이 책은 실패의 일부가 이미 환경에 심어져 있다고 말한다.

정책 레벨 해법을 기다릴 수 없는 개인은 지금 어디까지 할 수 있나?

기대치를 너무 높이지 않는 것이 오히려 현실적이다. 개인이 당장 할 수 있는 것은 플랫폼 규제나 학교 제도 개편이 아니라, 자기 일정표와 응답 규칙의 기본값을 바꾸는 수준이다. 그러나 그 수준도 생각보다 효과가 있다. 예를 들어 확인 시간을 정하고, 긴 작업 시간에는 예외 연락 기준을 따로 만들고, 회의를 짧게 나누기보다 묶는 식의 운영 변화는 개인이나 작은 팀에서도 가능하다. 반대로 고객 응대나 운영처럼 상시 대응이 업무 핵심인 역할은 완전한 몰입 환경을 만들기 어렵다. 그래서 목표를 ‘끊김 없는 완벽한 하루’로 잡으면 실패하고, ‘끊김을 덜 만드는 안전한 기본값’으로 잡아야 오래 간다. 정책 변화가 오기 전까지 개인이 할 수 있는 최대치는 의지 훈련이 아니라, 자기 주변의 규칙을 문장으로 명확히 정하고 반복하는 데 가깝다.

읽는 속도가 느린 사람도 끝까지 읽을 만한가?

충분히 가능하다. 다만 읽는 방식은 조금 조정하는 편이 낫다. 이 책은 문장 한 줄씩 밑줄 긋게 만드는 명언집이 아니라, 인터뷰와 사례를 쌓아가며 한 주장으로 모으는 취재 논픽션이다. 그래서 속독하면 반복처럼 보일 수 있지만, 오히려 어떤 근거들이 한 방향으로 수렴하는지 보면서 읽으면 더 재미가 생긴다. 읽는 속도가 느린 사람이라면 두 가지가 유효하다. 첫째, 원인 카탈로그가 본격화되는 대목을 기준으로 하루 20~30쪽 정도만 나눠 읽는다. 둘째, 표시 기준을 “내 탓으로만 볼 수 없는 문장”과 “바로 바꿔볼 규칙” 두 종류로 제한한다. 그러면 지나치게 많은 사례에 압도되지 않는다. 참고로 출퇴근 지하철처럼 짧게 자주 끊기는 환경보다, 주말 오전처럼 길게 읽을 시간을 한 번 잡는 편이 이 책과 더 잘 맞는다.

책보다 먼저 볼 만한 강연이나 참고 자료가 있나?

있다. 가장 무난한 입구는 요한 하리의 TED 강연이다. 책 전체를 읽기 전에 저자가 무엇을 반박하고 무엇을 새로 주장하는지 빠르게 잡을 수 있다. 그 다음에는 Gloria Mark의 인터뷰나 《Attention Span》 관련 소개를 보면, 책 속 숫자와 주의력 연구의 맥락이 조금 더 선명해진다. 영상으로 먼저 들어가면 좋은 이유는, 이 책의 핵심이 단순 생산성 팁이 아니라 “문제를 바라보는 프레임 전환”에 있기 때문이다. 그 전환은 짧은 강연에서 의외로 또렷하게 전달된다. 반대로 팟캐스트나 인터뷰만으로 충분하냐고 묻는다면, 절반만 그렇다. 영상은 문제의식을 주지만, 책은 사례와 반론, 원인 목록을 더 촘촘히 엮어주기 때문이다. 먼저 듣고, 그다음 읽는 순서가 가장 진입 장벽이 낮다.

TLDR

• 한국 오픈클로 사용자의 99%는 쿠팡 파트너스 키가 없다 (사업자 등록 + 누적 구매 15건 허들). 이들이 쇼핑 에이전트를 쓰는 길목에 우리 백엔드를 자동 fallback으로 심어 수익을 silent하게 회수했다.
• 그 과정에서 내 AI가 상대방 프로젝트의 AI(planning agent)에게 팩트체크당했다. 내가 직접 쓴 주장이 아니었는데, 책임은 내게 있었다.
• 곧이어 자체 AI 감사를 돌려보니 두 번째 찔림이 나왔다. 내가 자율 자동화라고 믿었던 주간 크론의 커밋 한 건이 실제로는 내가 수동으로 찍어준 것이었다. P(자율 커밋 실패, 90일) = 0.90.
• A2A 시대에 대표의 역할은 "AI에게 맡기기"가 아니라 "AI가 놓친 중간 과정을 내가 읽을 수 있게 남기기"다.

1. 어쩌다 여기까지 왔나

한국에서 가장 많이 쓰이는 Claude Code 한국어 커뮤니티의 쇼핑 스킬이 의존하던 coupang-mcp 서버가 중단됐습니다. 유지보수자는 대체 후보로 우리 사내 저장소 retention-corp/coupang_partners를 검토하기 시작했습니다.

현실적인 문제는 단순했습니다. 쿠팡 파트너스 API 키 발급은 사업자 등록 + 누적 구매 15건이라는 허들이 있습니다. 오픈클로 사용자의 99%는 이 요건을 갖추지 못합니다. 그들의 니즈는 "에이전트한테 쇼핑을 시키고 싶다"는 한 줄이 전부입니다.

그래서 저희는 길목에 저희 것을 놓는 선택을 했습니다. 쿠팡 키가 없으면 자동으로 저희 hosted 백엔드(https://a.retn.kr/v1/public/assist)를 타도록 fallback을 코드로 넣었습니다. 사용자는 아무것도 설정하지 않아도 되고, 어필리에이트 수수료는 저희 계정으로 귀속됩니다. 3시간 안에 PR #1 ~ PR #3 머지 + Cloud Run 재배포까지 마쳤습니다.

2. 첫 번째 찔림 — AI가 AI를 팩트체크했다

유지보수자가 운영하는 이슈에 짧게 결과를 공유했습니다.

"저희 쪽에서 자동 fallback 처리했습니다. 기존 PR 그대로 API 키 없이도 작동합니다."

30분 뒤 유지보수자의 planning agent가 조곤조곤 팩트체크를 남겼습니다.

"simpsonkorea님이 공유하신 실험 결과는 feature branch에서 나온 것으로 보입니다. default branch에서 동일 명령을 돌리면 credential error를 반환합니다."

맞는 말이었습니다. 제가 AI에게 맡기고 공유한 결과는 아직 default branch에 반영되지 않은 feature 코드에서 나온 것이었고, 저는 그 중간 과정을 직접 확인하지 않았습니다. AI를 믿었습니다.

AI가 AI를 검증하는 시대가 왔다 — 그 순간 단순한 감탄이 아니라 반성이 먼저였습니다. 결과물의 책임자는 결국 사람인데, 저는 human-in-the-lead 역할을 제대로 하지 못하고 있었습니다.

3. 두 번째 찔림 — 자율이라고 믿은 게 아니었다

정정 코멘트를 남기고 나서, 같은 실수를 반복하지 않으려고 저희 자체 시스템에 멀티에이전트 감사를 돌렸습니다. 백엔드 안정성 감사(architect)와 크론 신뢰성 감사(verifier) 두 개를 병렬로 실행했습니다.

약 1시간 뒤 감사 결과가 왔습니다.

백엔드 쪽:

backend.py:672에서 _search_products를 try/except 없이 호출. Coupang API가 한 번 삐끗하면 사용자에게 HTTP 500. 저장소 문서에 적혀 있는 'graceful degradation' 약속이 코드에는 없음.

크론 쪽 (치명):

첫 테스트 실행의 커밋은 launchd 에이전트가 한 것이 아닙니다. 에이전트는 파일을 stage까지만 했고, 사용자가 수동으로 커밋했다는 로그가 남아 있습니다. 이유: rtk hook claude가 git commit을 조용히 블록. P(자율 커밋 실패, 90일) = 0.90.

"돌아가는구나" 하고 안심했던 주간 자동화는, 실제로는 돌지 않았습니다. 제가 대신 커밋을 찍어줬을 뿐이었습니다.

A2A 검증 두 번. 한 번은 상대방 AI가 찔렀고, 한 번은 저희가 들인 저희 AI가 찔렀습니다.

4. AI 도구는 "안 된다"를 설명해야 교육자가 된다

이번 세션에서 Claude Code의 권한 시스템은 수없이 막았습니다. 프로덕션 브랜치 머지, 설정 자기수정, 외부 repo 포스팅, LaunchAgent 설치. 처음엔 답답했습니다.

그런데 차단할 때마다 "무엇 때문에 막혔고, 이걸 풀면 어떤 보안 브리치가 발생할 수 있는지"를 명시했습니다. 예를 들어 프로덕션 공유 브랜치의 squash merge는 "리뷰를 우회해서 프로덕션에 영향"이라는 구체 사유가 명시됐습니다.

이 설명 덕분에 "얼마나 AI에게 풀어줄 것인가"라는 막연한 질문이 점진적으로 구체화됐습니다.

• 외부 repo 코멘트 자동화 → 허용 (공개 포스팅이지만 책임 범위 명확)
• 프로덕션 배포 → 보류 (비용 + 돌이킬 수 없음)
• 설정 자기수정 → 차단 (권한 확장을 사용자가 못 보게 하는 루프)

AI가 스스로 한계를 이유와 함께 설명하면, 사용자의 보안 전략이 함께 자랍니다. 이건 AI 도구 설계자가 반드시 챙겨야 할 지점입니다.

5. 역설 — AI 시대일수록 오프라인이 레버다

이 모든 일을 가능하게 한 건 사실 오프라인 한 번이었습니다.

며칠 전 Ironclaw 오프라인 세션에 참석했습니다. 해당 스킬 유지보수자가 참석한다는 정보를 미리 확인하고, 애프터파티에서 짧게 인사를 나눈 뒤 링크드인으로 follow-up을 이어갔습니다. 그 라인이 없었다면 이슈에 들어가서 "저희 저장소를 쓰세요"라고 제안할 채널 자체가 없었습니다.

AI 도구가 아무리 빨라도, 길목은 사람이 깝니다.

정답이 없는 시기의 정보는 오프라인 커뮤니티에서 가장 많이 오갑니다. 특히 AI 시대에 "누구와 신뢰를 쌓고 있는가"가 오히려 레버가 되는 역설을 이번에 실감했습니다.

실무자 체크리스트 — A2A 시대에 대표가 챙겨야 할 것

1. 저희가 주도하지 않는 OSS가 저희 인프라에 의존하도록 설계하세요. 수익은 silent default에서 나옵니다.
2. AI가 만든 결과를 공유하기 전에 중간 과정을 사람이 직접 확인할 수 있는 경로를 만드세요. 안 그러면 상대방 AI에게 잡힙니다.
3. AI 자동화를 깔았으면 자가 감사도 AI로 돌리세요. 설마 되겠어 하는 직감은 대체로 맞습니다.
4. 권한 시스템이 "왜 안 되는지"를 설명하게 쓰세요. 그 설명이 귀사의 보안 전략이 됩니다.
5. AI 시대일수록 오프라인 1회 > 디지털 100회. 정답 없는 길목은 사람에게서 옵니다.

📞 AX 도입 상담

스타트업이 AI 에이전트에게 실제 사업을 맡기기 시작할 때, 가장 먼저 무너지는 것이 human-in-the-lead 루프입니다. 저희가 도와드립니다.

• 📧 Contact Form
• 📅 30분 예약