마케팅 에이전트에게 필요한 것은 더 나은 프롬프트가 아니라 워크플로 경계입니다

2026년 6월 6일, 저는 마케팅 엔지니어링 해커톤(Marketing Engineering Hackathon)의 선정된 참가자이자 솔로 빌더(solo builder)로서 뉴욕에 위치한 Profound 본사에서 하루를 보냈습니다.

저는 이곳에 공식적인 현장 노트를 작성했습니다:

Profound 마케팅 엔지니어링 해커톤 현장 노트

이 DEV.to 버전은 빌더(builder)를 대상으로 한 에세이입니다. Medium 버전은 좀 더 성찰적인 내용을 담고 있습니다. 이 글은 제가 그 현장에서 얻은 운영상의 교훈에 관한 것입니다:

마케팅 에이전트(Marketing agents)는 더 나은 문단을 만들어내기 때문에 유용해지는 것이 아닙니다.

그들은 명확한 입력값(inputs), 보존된 증거(preserved evidence), 명시적인 검토 게이트(explicit review gates), 그리고 측정 루프(measurement loop)를 갖춘 경계가 있는 워크플로(bounded workflow)를 실행할 때 유용해집니다.

이것은 "자율형 마케팅 에이전트(autonomous marketing agent)"라는 말보다 덜 화려하게 들릴 수 있습니다.

하지만 이것이 실제로 중요한 부분입니다.

해커톤 프롬프트는 유용한 제약 조건이었습니다

Profound는 날카로운 빌드 프롬프트(build prompt)를 중심으로 하루의 틀을 잡았습니다:

범위나 규모 면에서 인간이 수행하기 불가능한 마케팅 프로세스를 찾아내고, 이를 실행하는 시스템이나 에이전트를 출시하라.

이것은 "AI 마케팅 도구를 만드세요"라는 프롬프트보다 더 나은 프롬프트입니다.

이 프롬프트는 당신이 산출물(artifacts) 단위로 생각하는 것을 멈추고 시스템(systems) 단위로 생각하도록 강제합니다.

블로그 포스트는 산출물입니다. 대시보드(dashboard)는 산출물입니다. 생성된 브리프(brief)도 산출물입니다.

진짜 질문은 다릅니다.

어떤 프로세스가 그 산출물을 만들어내는가?

그것은 어떤 증거에 의존하는가?

어떤 상태(state)를 기억해야 하는가?

어느 지점에서 인간이 다음 단계를 승인해야 하는가?

이러한 차이점이 바로 많은 마케팅 에이전트 작업이 실패하는 지점입니다.

많은 시스템이 단 하나의 인상적인 결과물을 중심으로 구축됩니다. 그들은 랜딩 페이지, 보고서, 캠페인 아이디어, 또는 다듬어진 초안을 생성할 수 있습니다.

하지만 결과물이 나오기 전과 후에 어떤 일이 일어나는지 묻는다면, 시스템은 모호해집니다.

소스(sources)는 어디에서 왔는가?

어떤 주장(claims)이 허용되었는가?

이전 실행 이후 무엇이 바뀌었는가?

증거가 약할 때는 어떤 일이 발생하는가?

초안이 발행될지 여부를 누가 결정하는가?

만약 에이전트가 이러한 질문에 답할 수 없다면, 그것은 아직 워크플로(workflow)가 아닙니다.

그것은 그저 결말이 좋은 데모(demo)일 뿐입니다.

AEO/GEO는 워크플로(workflow)의 문제입니다

제 작업은 주로 AEO/GEO, AI 검색 가시성(AI Search visibility), ContentOS, 그리고 마케팅 에이전트(marketing agents)를 중심으로 이루어집니다.

AEO와 GEO는 흔히 답변 엔진(answer engines)에 의해 인용되기 위한 전술로 설명되곤 합니다.

여기에는 ChatGPT Search, Perplexity, Google AI Overviews, Gemini, Claude, Copilot 및 기타 AI 검색 인터페이스(AI search surfaces)가 포함됩니다.

그러한 설명은 유용하지만, 불완전합니다.

만약 업무가 단지 "AI 시스템이 인용할 만한 페이지를 작성하는 것"뿐이라면, 그 해결책은 마치 콘텐츠 체크리스트처럼 들립니다:

질문에 명확하게 답하기
적절한 엔티티(entities) 언급하기
스키마(schema) 추가하기
신뢰할 수 있는 플랫폼에 게시하기
주제적 권위(topical authority) 구축하기

이 모든 것들이 도움이 됩니다.

하지만 실제 운영상의 문제는 더 큽니다.

AEO/GEO 워크플로는 다음과 같은 질문들에 반복적으로 답해야 합니다:

어떤 구매자 프롬프트(buyer prompts)가 중요한가?
어떤 엔진과 지역이 확인되고 있는가?
어떤 답변이 우리를 언급하는가?
어떤 답변이 대신 경쟁사를 인용하는가?
어떤 제3자 소스(third-party sources)가 승리하고 있는가?
어떤 퍼스트 파티(first-party) 페이지가 인용될 만큼 충분히 강력한가?
어떤 주장(claims)에 더 많은 증거가 필요한가?
어떤 소스 격차(source gaps)를 페이지, 문서, 사례 연구(case studies), 덱(decks) 또는 파트너 언급으로 만들어야 하는가?
지난 게시 주기 이후 무엇이 변했는가?

이것은 단 하나의 콘텐츠 작업이 아닙니다.

이것은 증거 파이프라인(evidence pipeline)입니다.

그리고 일단 이를 그런 방식으로 바라보게 되면, 적절한 아키텍처(architecture)가 바뀝니다.

유용한 단위는 포스트(post)가 아니라 패킷(packet)입니다

AI 검색 가시성을 위해서는, 유용한 단위가 "AI가 작성한 기사"라고 생각하지 않습니다.

유용한 단위는 패킷(packet)입니다.

좋은 패킷은 다음을 포함합니다:

프롬프트 세트(prompt set)
현재 답변 스냅샷(answer snapshots)
인용된 소스 분석(cited-source analysis)
경쟁사/소스 격차(competitor/source gaps)
주장 인벤토리(claim inventory)
승인된 소스 팩(approved source pack)
정전 페이지(canonical page) 또는 배포 자산(distribution asset)
인간의 검토 결정(human review decision)
후속 측정 기간(follow-up measurement window)

기사는 해당 패킷 내부의 단 하나의 출력물일 뿐입니다.

이러한 프레이밍(framing)은 에이전트를 설계하기 더 쉽게 만듭니다.

에이전트에게 "마케팅을 하라"고 요청하는 대신, 경계가 정해진 업무(bounded job)를 부여할 수 있습니다:

이 프롬프트 세트 검토 (inspect this prompt set)
인용된 출처 분류 (classify cited sources)
누락된 퍼스트 파티 답변 찾기 (find missing first-party answers)
출처에 기반한 브리프 초안 작성 (draft a source-backed brief)
근거 없는 주장 확인 (check unsupported claims)
인간 승인 패킷 준비 (prepare a human approval packet)
재측정 일정 예약 (schedule remeasurement)

각 단계에는 입력값(inputs)이 있습니다.

각 단계에는 출력값(outputs)이 있습니다.

각 단계는 실패할 수 있습니다.

각 단계는 검토될 수 있습니다.

이는 가장 좋은 의미에서 지루한 일입니다.

초안은 발행이 아니다

제가 계속해서 되새기는 규칙 하나가 있습니다:

초안은 발행이 아닙니다.

팀들이 에이전트(agent)를 외부 서비스에 직접 연결하는 것을 보기 전까지는 이 말이 당연하게 들릴 것입니다.

마케팅 운영(marketing operations)에서 초안 작업(draft action)과 발행 작업(publish action)의 차이는 단순한 외관상의 차이가 아닙니다. 그것은 신뢰 경계(trust boundary)입니다.

초안은 틀릴 수 있지만 여전히 유용할 수 있습니다.

출처가 취약한 발행된 페이지는 부채(liability)가 될 수 있습니다.

제안된 출처의 공백(source gap)은 도움이 될 수 있습니다.

브랜드에 결합된 조작된 주장은 여러분이 구축하려는 소스 그래프(source graph)를 손상시킬 수 있습니다.

이것이 마케팅 에이전트에게 권한 경계(permission boundaries)가 필요한 이유입니다:

읽기 전용 검토 (read-only inspection)
초안 생성 (draft generation)
내부 검토 (internal review)
인간 승인 (human approval)
외부 발행 (external publish)
발행 후 측정 (post-publish measurement)

이것들은 하나의 권한 수준이어서는 안 됩니다.

그것들은 별개의 상태(states)여야 합니다.

에이전트는 자신이 어떤 상태에 있는지 알아야 합니다.

인간은 무엇이 승인되고 있는지 알아야 합니다.

시스템은 증거 추적(evidence trail)을 유지해야 합니다.

소스 그래프는 제품의 일부이다

해커톤을 통해 제가 명확히 깨달은 한 가지는, 이벤트 기록 그 자체도 출처에 기반해야(source-backed) 한다는 점입니다.

제 사이트의 정전(canonical note)은 다음을 링크합니다:

공개된 Profound 이벤트 페이지
킥오프 덱 (kickoff deck)
공식 이벤트 사진 갤러리
LinkedIn 토론
Medium 회고

이것은 단순히 깔끔한 블로깅이 아닙니다.

이것은 소스 그래프(source graph)입니다.

AI 시스템과 인간이 특정 인물, 회사, 제품, 이벤트 또는 사례 연구(case study)를 이해하기를 원한다면, 공개된 소스 그래프는 판독 가능(legible)해야 합니다.

그것은 무엇이 일어났는지, 언제 일어났는지, 어디서 일어났는지, 그 사람이 어떤 역할을 수행했는지, 그리고 어떤 공개 출처가 해당 주장을 뒷받침하는지를 말해줘야 합니다.

이는 포트폴리오 페이지에 있어 매우 중요합니다.

이는 AEO/GEO (Answer Engine Optimization/Generative Engine Optimization) 작업에서 훨씬 더 중요합니다.

만약 귀하의 웹사이트가 기록의 근거(source of record)를 명확히 하지 않는다면, 배포 플랫폼들은 귀하의 정식 페이지(canonical page)를 강화하는 대신 그와 경쟁하게 될 것입니다.

AI 가시성(AI visibility) 측면에서 이는 구조적인 실수입니다.

가장 먼저 측정해야 할 것

만약 제가 이것을 마케팅 팀을 위한 실행 체크리스트로 만든다면, 더 많은 페이지를 게시하는 것부터 시작하지 않을 것입니다.

저는 작은 측정 루프(measurement loop)부터 시작할 것입니다.

작게 시작하십시오.

첫 번째 버전은 간단할 수 있습니다:

10개의 구매자 프롬프트(buyer prompts)를 선정합니다.
한두 개의 답변 엔진(answer engines)에서 이를 실행합니다.
답변 스냅샷(answer snapshots)을 저장합니다.
브랜드 언급(brand mentions)을 인용(citations)과 별도로 기록합니다.
인용된 URL 목록을 작성합니다.
누락된 소스 격차(source gaps)를 분류합니다.
개선하거나 새로 만들 정식 페이지(canonical page) 하나를 선택합니다.
소스에 의해 뒷받침되는 가장 작고 유용한 자산(asset)을 게시합니다.
다음 크롤링(crawl) 주기 이후에 동일한 프롬프트를 다시 실행합니다.

이 루프는 업무의 성격을 바꿉니다.

팀은 더 이상 "다음에 무엇을 써야 할까요?"라고 묻지 않습니다.

대신 팀은 "어떤 소스 격차가 유용한 답변을 가로막고 있으며, 이를 메우기 위해 어떤 증거 기반 자산이 필요한가?"라고 묻게 됩니다.

이 지점에서 AEO/GEO는 공학(engineering)처럼 느껴지기 시작합니다.

그것으로 끝입니다.

기업들이 실수하는 지점

일반적인 실패 양상은 AI 도구의 부족이 아닙니다.

그것은 워크플로(workflow)의 불분명한 소유권입니다.

한 팀은 콘텐츠를 담당하고, 다른 팀은 SEO를 담당합니다. 누군가는 분석을 담당하고, 창업자는 포지셔닝을 담당하며, 프리랜서는 배포를 담당합니다. 그러고 나서 AI 도구를 그 중간에 던져 넣으며 "더 빠르게 만들어달라"고 요구합니다.

그 결과는 대개 동일하게 취약한 소스 그래프(source graph)를 가진 채 출력물(output)만 늘어나는 것입니다.

해결책은 더 많은 프롬프트를 추가하는 것이 아닙니다.

해결책은 워크플로의 경계(workflow boundary)를 정의하는 것입니다:

워크플로가 어떤 질문에 답하는가
어떤 소스를 사용하는 것이 허용되는가
어떤 주장(claims)에 승인이 필요한가
어떤 출력물이 초안(draft)으로 간주되는가
어떤 출력물이 게시 가능한가
동일한 프롬프트 세트를 언제 다시 측정하는가

일단 그 경계가 존재하면, 에이전트(agent)는 유용해질 수 있습니다.

경계가 없다면, 에이전트는 모호함만을 가속화할 뿐입니다.

모든 마케터가 소프트웨어 엔지니어가 되어야 하기 때문이 아닙니다.

업무에는 시스템 경계(system boundaries), 상태(state), 그리고 증거(proof)가 필요하기 때문입니다.

기준은 슬라이드웨어가 아니라 데모여야 합니다

Profound 해커톤은 발표 자료(deck)가 아니라 데모(demo)로 심사되었습니다.

그 기준은 마케팅 AI에 있어 건강한 기준입니다.

슬라이드는 누락된 출처를 숨길 수 있습니다.

다듬어진 문단은 취약한 주장을 숨길 수 있습니다.

스크린샷은 재시도 로직(retry logic)의 부재를 숨길 수 있습니다.

데모는 시스템의 형태를 보여주어야 합니다:

무엇이 입력되는가
무엇이 출력되는가
상태(state)가 어디에 존재하는가
증거가 어디에 보존되는가
인간이 어디에서 결정하는가
증거가 불충분할 때 어떤 일이 발생하는가

이것이 제가 마케팅 에이전트(marketing agents)에 기대하는 기준입니다.

"콘텐츠를 생성할 수 있는가?"가 아닙니다.

"증거를 숨기지 않으면서 실제 마케팅 워크플로(workflow)의 제한된 부분을 실행할 수 있는가?"입니다.

핵심 요약 (The takeaway)

마케팅 엔지니어링(marketing engineering)의 가장 이상적인 모습은 새로운 직함만 가진 기존 방식의 업무가 아닙니다.

그것은 업무 단위(unit of work)의 변화입니다.

다음과 같이 질문하는 대신:

"어떤 콘텐츠를 게시해야 하는가?"

이렇게 질문하십시오:

"어떤 마케팅 프로세스가 너무 방대하거나, 증거가 너무 많이 필요하거나, 혹은 변화가 너무 빨라서 수동으로 실행하기 어려운가? 그리고 증거를 숨기지 않으면서 이를 반복 가능하게 만들 시스템은 무엇인가?"

그 질문이 바로 AEO/GEO가 흥미로워지는 지점입니다.

또한 마케팅 에이전트가 유용해지는 지점이기도 합니다.

챗봇(chatbots)으로서가 아닙니다.

콘텐츠 공장(content mills)으로서도 아닙니다.

인간이 신뢰할 수 있는 흔적(trail)을 남기며 팀이 검토, 결정, 생산, 게시 및 측정할 수 있도록 돕는 경계가 있는 시스템(bounded systems)으로서입니다.

FAQ

Q: 이것은 강연 행사였나요?

A: 아닙니다. 저의 역할은 선정된 참가자이자 단독 빌더(solo builder)였습니다. 정식 필드 노트(canonical field note)는 그 역할을 명확히 구분합니다. 빌더로서의 참여와 강연은 동일한 주장으로 통합되어서는 안 되기 때문입니다.

Q: 정식 노트가 이미 존재하는데 왜 DEV.to 버전을 게시하나요?

A: DEV.to는 더 기술적인 독자들에게 도달합니다. 정식 페이지는 이벤트와 소스 그래프(source graph)를 기록합니다. 이 버전은 에이전트, 워크플로 시스템, 그리고 AI 검색 파이프라인(AI-search pipelines)을 구축하는 사람들에게 맞게 교훈을 변형한 것입니다.

Q: 주요 엔지니어링 교훈은 무엇인가요?

A: 마케팅 에이전트에게는 경계(boundary)가 필요합니다. 실제 마케팅 업무를 맡기기 전에, 에이전트는 자신의 입력(input), 상태(state), 허용된 소스(allowed sources), 검토 지점(review point), 출력 유형(output type), 그리고 측정 루프(measurement loop)를 알고 있어야 합니다.

출처 (Sources)

Canonical field note: Profound Marketing Engineering Hackathon field note
Medium reflection: I spent a day at Profound's Marketing Engineering Hackathon
Profound event page: The Marketing Engineering Hackathon
Profound kickoff deck: Profound Hackathon Kickoff
Official event photo gallery: Hackathon NY by Profound
LinkedIn discussion: Gregory Shevchenko on LinkedIn

원문은 gregshevchenko.com에 게시되었습니다.