Meta 확인 → Excel 취합 → 분석 → 보고 → Slack 공유. 이 루틴, 낯익지 않나요?
월요일 아침, 마케터 A는 Meta 광고 관리자를 엽니다. 지난주 기간을 선택해 데이터를 내려받고, Excel의 기존 탭을 복사합니다. 열 순서와 기간을 맞춘 뒤 빈 값이 없는지 확인합니다. 캠페인별 변화를 분류하고 보고 문장을 다듬어 Slack에 올립니다.
A는 분석할 줄 모르는 사람이 아닙니다. 오히려 업무에 익숙하기 때문에 어긋난 숫자와 이상한 흐름을 빨리 발견합니다. 문제는 그 판단에 도달하기 전까지 데이터를 찾고, 옮기고, 맞추는 일을 매주 되풀이한다는 데 있습니다.
이 업무는 정말 ‘판단 업무’일까요?
주간 리포트에는 사람의 판단이 필요합니다. 다만 처음부터 끝까지 모든 단계가 판단 업무인 것은 아닙니다. A가 캠페인별 증감에 색을 칠한다고 해보겠습니다. 그 색을 칠하는 기준이 이미 정해져 있다면, 매번 새롭게 생각해야 하는 일이 아니라 합의된 규칙을 반복 적용하는 일에 가깝습니다.
아래 항목으로 현재 업무를 확인해 보세요.
[ ] 매주 또는 매월 정해진 시점에 같은 업무가 시작된다. — 정기성
[ ] 둘 이상의 화면·파일·표에서 데이터를 가져와 한 형식으로 맞춘다. — 데이터 취합
[ ] 목표 대비, 전주 대비, 임계값, 상태값처럼 정해진 기준으로 항목을 나눈다. — 정해진 기준의 분류
[ ] 결과를 공유하기 전에 사람이 누락과 예외를 반복 확인한다.
[ ] 최종 보고 형식과 공유 채널이 대부분 정해져 있다.
첫 세 항목이 모두 해당된다면, 보고서를 빨리 쓰는 요령보다 반복 구간을 어떻게 연결할지 먼저 살펴볼 필요가 있습니다. 마지막 두 항목은 사람이 확인할 지점과 예외 처리 방식을 정할 때 쓰는 질문입니다.
자동화 도구를 써도 왜 다음 주에 같은 일을 다시 할까요?
A도 Excel 함수와 대시보드를 사용합니다. GPT나 Claude에 CSV를 넣고 요약문을 만들어 본 적도 있습니다. 비정기 분석이나 초안을 만들 때 이런 도구는 분명 유용합니다.
그런데 다음 주 월요일이 되면 A는 지난 대화를 찾고, 새 CSV를 준비하고, 지표의 의미와 원하는 출력 형식을 다시 설명합니다. 답변을 받은 뒤에는 보고서에 옮기고 Slack에 공유해야 합니다. 도구가 부족해서가 아니라 업무의 앞뒤가 연결되지 않았기 때문입니다.
반복의 원인은 ‘설계 부재’에 있습니다. 언제 업무를 시작할지, 어느 데이터에 연결할지, 어떤 규칙으로 분류할지, 오류를 어떤 상태로 남길지, 누가 승인할지, 승인 뒤 무엇을 기록할지가 하나의 흐름으로 정리되지 않은 것입니다. 이 연결이 없으면 좋은 모델을 써도 담당자가 매주 작업을 다시 시작합니다.
단발성 GPT·Claude 사용과 Agent 워크플로우의 차이는 모델의 우열이 아닙니다.
단발성 사용에서는 담당자가 파일을 찾고 프롬프트를 입력해야 업무가 시작됩니다. 대화가 끝나면 실행 성공 여부, 누락, 승인 대기 같은 상태가 다음 주까지 이어지지 않을 수 있습니다.
Agent 워크플로우에서는 정해진 시각이나 승인된 데이터 갱신을 시작 신호로 삼습니다. 데이터 연결, 분류 규칙, 예외 상태, 담당자 승인, 후속 기록이 한 흐름 안에 놓입니다.
Agent를 도입한다는 말은 챗봇을 하나 더 추가한다는 뜻이 아닙니다. 반복 업무가 매번 같은 조건과 규칙으로 이어지도록 구조를 만드는 일에 가깝습니다.
Agent가 들어오면 월요일 아침은 어떻게 달라질까요?
가상의 회사가 주간 리포트 흐름을 바꾼다면 핵심은 다음과 같습니다.
Meta API → Agent 분석 → 담당자 판단 → Next Action
여기서 ‘Agent 분석’은 성과 변화의 원인을 확정한다는 뜻이 아닙니다. 승인된 데이터를 불러와 정해진 형식으로 맞추고, 합의된 규칙에 따라 검토 순서를 나누며, 이상 신호와 원인 후보를 제시하는 단계입니다.
실제 흐름을 조금 더 자세히 보면 이렇습니다.
정해진 주간 리포트 시각이나 승인된 데이터 갱신이 트리거가 됩니다.
Agent는 Meta API를 통해 필요한 기간과 범위의 승인된 지표를 불러옵니다.
지표명, 기간, 단위, 캠페인 식별자를 보고 형식에 맞게 정리합니다.
전주 대비, 목표 대비 등 사전에 합의한 기준으로 검토 우선순위를 분류합니다.
누락이나 급격한 변화를 발견하면 결론을 내리지 않고 ‘확인 필요’ 신호와 근거를 남깁니다.
담당자는 데이터의 완전성과 업무 맥락을 확인하고, 원인 가설과 보고 문구를 승인하거나 수정하거나 보류합니다.
승인된 조치는 Next Action으로 전환되어 담당자, 기한, 이후 확인할 지표와 함께 기록됩니다.
승인된 요약과 링크만 Slack에 공유합니다.
이 구조가 작동하려면 실제 구축 전에 API 접근 권한, 데이터 스키마, 지표 정의, 분류 규칙과 승인자를 정해야 합니다. 인증에 실패하면 보고서를 억지로 만들지 않고 연결 확인 요청을 남겨야 합니다. 데이터 일부가 비어 있다면 정상 결과와 섞어 확정하지 않고 검토 대기로 분리해야 합니다. 담당자가 승인하지 않은 예산 변경이나 최종 공유도 진행하지 않습니다.
Agent는 만능 자동화가 아닙니다. 잘 설계된 Agent는 오류와 예외를 감추지 않고 사람이 확인할 수 있는 상태로 드러냅니다.
무엇을 Agent에 맡기고, 무엇을 사람이 결정해야 할까요?
월요일 아침의 A는 더 이상 빈 Excel에서 보고서를 조립하는 것으로 업무를 시작하지 않습니다. Agent가 준비한 검토 화면에서 누락 경고, 주요 변화, 분류 근거를 먼저 봅니다. 그리고 “왜 이런 변화가 생겼는가”, “무엇을 바꿀 것인가”에 집중합니다.
그렇다면 A의 일이 사라진 걸까요? 그렇지 않습니다. A가 하던 일 가운데 찾고, 옮기고, 맞추는 일이 Agent 쪽으로 이동하고, 책임 있는 판단이 업무의 앞쪽에 놓인 것입니다.
Agent에 맡길 수 있는 반복은 다음과 같습니다.
정해진 시점에 승인된 데이터를 호출하는 일
지표명, 기간, 단위를 보고 형식에 맞추는 일
합의된 기준에 따라 검토 우선순위를 나누는 일
누락과 이상 신호 후보를 표시하는 일
보고 초안과 검토 항목을 준비하는 일
승인된 후속 행동을 기록하고 공유하는 일
사람에게 남겨야 할 판단은 분명합니다.
성과 변화의 실제 원인을 해석하는 일
시장 상황, 프로모션, 소재 맥락을 함께 보는 일
예산을 유지하거나 변경하거나 중단할지 결정하는 일
어떤 메시지와 소재를 선택할지 정하는 일
팀 리더와 관련 부서의 우선순위와 위험을 조율하는 일
기존 기준을 바꾸거나 예외를 승인하는 일
원칙은 간단합니다. 반복은 Agent, 판단은 사람. Agent가 검토 가능한 상태를 만들고, 사람은 결과에 책임을 지는 결정을 내립니다.
Before와 After의 업무 흐름은 무엇이 다를까요?
Before의 A는 업무가 시작된 뒤 각 화면에 접속합니다. 파일을 내려받아 열을 맞추고, 누락과 기간 오류를 찾습니다. 기준표와 지난 보고서를 다시 확인해 상태를 분류한 뒤 문장을 작성합니다. 리더의 수정 의견이 오면 문서에 다시 반영하고 Slack에 올립니다. 후속 조치는 별도 메시지나 A의 기억에 남기도 합니다.
After에서는 보고 시각 전에 정해진 트리거가 데이터 수집과 정규화를 시작합니다. 실패, 누락, 이상 신호는 근거와 함께 검토 대기로 모입니다. A는 준비된 비교와 분류 근거를 확인한 뒤 원인을 해석하고 예산, 메시지, 우선순위를 승인하거나 수정합니다. 승인된 결과는 Next Action으로 이어지고, 담당자와 기한, 이후 확인할 지표가 남습니다. 최종 요약과 링크는 승인 뒤 Slack에 공유됩니다. 다음 실행에서는 이전 상태와 끝나지 않은 조치도 다시 확인할 수 있습니다.
달라지는 것은 막연한 ‘속도’만이 아닙니다.
업무 시작점이 빈 Excel에서 검토 가능한 상태로 바뀝니다.
오류를 최종 문서 작성 중 발견하는 대신 수집·정리 단계에서 별도 상태로 확인합니다.
리더는 완성 문장 전체를 되돌려 보기보다 판단이 필요한 항목을 중심으로 검토합니다.
후속 조치는 대화 속에 흩어지지 않고 담당자, 기한, 확인 지표와 연결됩니다.
A는 데이터 운반보다 원인 해석과 실행 우선순위에 집중합니다.
이 변화가 저절로 생기는 것은 아닙니다. 트리거와 데이터 연결만 설정해 놓고 승인 규칙과 오류 상태를 비워 두면, 담당자는 결과 전체를 다시 검사하게 됩니다. Agent의 범위를 정할 때 정상 흐름보다 실패했을 때 멈추는 조건을 먼저 적어두는 편이 좋습니다.
우리 업무도 Agent로 바꿀 수 있을까요?
모델이나 도구를 고르기 전에 현재 업무를 한 장에 그려보세요. 아래 질문에 답하면 어디까지 Agent에 맡기고 어디부터 사람이 책임질지 구체적으로 정할 수 있습니다.
이 업무는 무엇을 계기로 시작되나요?
필요한 데이터는 어디에 있고 접근 권한은 어떻게 관리되나요?
반복 적용할 수 있는 분류 기준은 무엇인가요?
누락, 오류, 기준 밖 변화는 어떤 상태로 구분해야 하나요?
사람이 반드시 확인하고 승인해야 하는 지점은 어디인가요?
승인 뒤 어떤 Next Action을 누구에게 어떤 형식으로 남겨야 하나요?
다음 실행에서 참고해야 할 이전 상태는 무엇인가요?
답이 모이면 “Agent가 알아서 처리해 주세요”라는 모호한 요청 대신, 수집·분류·검토·승인·공유 중 어디부터 바꿀지 범위를 정할 수 있습니다. 처음부터 모든 단계를 연결할 필요도 없습니다. 기준이 분명하고 오류를 확인하기 쉬운 반복 구간부터 시작해 사람의 승인 지점을 붙이는 방법도 있습니다.
Flexwork는 실제 업무 문제를 기준으로 AI 시대형 전문가와 프로젝트·시간제 협업·커뮤니티·전문가 기회를 연결하는 전문가 네트워크입니다. 매주 되풀이되는 보고 업무가 있다면, 도구를 고르기 전에 시작 조건과 데이터 흐름, 분류 기준, 사람의 승인 지점, 후속 행동을 먼저 적어보세요. 어디가 반복이고 어디가 판단인지 구분되면 Agent로 바꿀 범위도 선명해집니다.