CRM AI 에이전트를 고를 때 반드시 확인해야 할 2가지
요즘 CRM 솔루션마다 "AI 에이전트"를 이야기해요. 그런데 같은 단어 뒤에 숨은 실제 제품은 꽤 달라요. 데모에서는 다들 잘 돌아가니까, 도입을 검토할 때는 두 가지를 따져보는 게 좋아요.
한 번의 대화가 얼마나 멀리 가나요? 분석 결과만 보여주고 끝나는지, 아니면 그 분석이 실제 캠페인 집행까지 이어지는지.
그 에이전트는 누가 책임지고 고치나요? 잘못 분석하거나 엉뚱한 메시지를 만들 때, 품질을 검증하고 고치는 주체가 있는지.
이 두 질문의 답은 결국 한 곳에서 갈려요. 에이전트를 직접 만들었느냐, 아니면 도구(MCP)만 열어뒀느냐.
같은 "AI 에이전트"라도 두 갈래로 나뉘어요
MCP만 제공하는 방식
최근 많은 솔루션이 택한 방식이에요. 자사 데이터와 기능을 MCP(Model Context Protocol) 도구로 노출하고, 실제 "에이전트" 역할은 고객사가 붙이는 외부 LLM(ChatGPT, Claude 등)에 맡겨요.
구조를 풀어보면 이래요.
솔루션사는 도구(tool) 표면만 만들어요 — "캠페인 목록 조회", "세그먼트 생성" 같은 함수를 MCP로 열어두는 거죠.
그 도구를 언제, 어떻게, 어떤 판단으로 쓸지 결정하는 두뇌는 고객사가 연결한 외부 AI예요.
따라서 분석의 정확도, 메시지 카피의 품질, 잘못된 판단을 거르는 일은 솔루션사가 아니라 고객사(와 고객사가 붙인 AI)의 몫이 돼요.
내부 코드 위에 MCP 도구만 설계하면 되니 솔루션사 입장에서 공수가 훨씬 적게 들어요. 빠르게 "AI 지원"을 외칠 수 있는 합리적인 선택이고요. 다만 그 대가로, 에이전트가 실제로 잘 동작하는지에 대한 책임과 통제권이 솔루션사 손을 떠나요.
자체 에이전트를 직접 만들고 운영하는 방식
블럭스가 택한 방식이에요. 도구만 여는 게 아니라, 분석·기획·실행을 수행하는 에이전트 자체를 제품으로 만들고 직접 운영해요. 자연어 인터페이스, 도구를 호출하는 판단 로직, 응답 품질까지 전부 블럭스 안에 있어요.
이 방식은 훨씬 어려워요. 좋은 에이전트 경험을 만드는 건 MCP 도구 몇 개를 여는 것과는 차원이 다른 일이거든요. 하지만 어려운 만큼, 도입하는 팀 입장에서 결정적인 차이를 두 가지 만들어요.
하나 — 한 번의 대화가 얼마나 멀리 가나요?
먼저 볼 건 에이전트가 어디까지 해내는지예요. 분석 결과만 보여주고 끝나는지, 아니면 그 분석을 실제 캠페인·시나리오 집행까지 옮겨주는지. 데모에서는 잘 드러나지 않지만, 도입한 뒤 매일 쓰다 보면 이 차이가 가장 크게 다가와요.
블럭스 에이전트는 이 구간을 한 대화로 이어요. "지난 30일간 이탈 위험이 높아진 고객을 찾아줘"라는 한 줄에서 시작해서, 그 분석 결과를 오디언스로 만들고, 그 오디언스를 대상으로 한 캠페인이나 시나리오 초안까지 — 전부 한 대화 안에서 콘솔에 바로 만들어져요. 검토한 다음 곧바로 집행할 수 있는 상태로요.



이게 가능한 건 에이전트가 콘솔의 거의 모든 기능 스펙을 알고 있기 때문이에요. 데이터 분석, 오디언스, 캠페인, 시나리오, 인앱 메시지, 개인화 메시지와 상품 추천 설정, 알림톡 템플릿, 이미지 생성까지 — 분석가·기획자·실행자의 역할을 한 대화에서 끊김 없이 이어줘요.
반면 다른 솔루션의 에이전트는 대개 한 구간씩만 맡아요. 데이터 분석만 되거나, 캠페인 설정만 되는 식이죠. 분석과 실행이 둘 다 가능하더라도 기능별로 에이전트가 따로 나뉘어 있어서, 분석한 결과가 캠페인을 만드는 단계로 자연스럽게 이어지지 않는 경우도 많아요.
분석에서 끝나는 에이전트는 "흥미로운 리포트"를 주지만, 그걸 보고 실제 캠페인을 만드는 일은 결국 사람 몫으로 남아요. 반대로 캠페인만 만들 수 있는 에이전트는 분석 결과와 이어지지 않으니, 정작 어떤 캠페인을 만들어야 할지부터 막막하죠. 블럭스는 이 끊긴 구간 — 분석을 실제 집행으로 옮기는 일 — 을 한 대화로 메워요.
실제로 마케터가 한 줄로 던질 수 있는 요청은 이런 모습이에요.
"최근 30일간 특정 카테고리에 관심 보인 고객을 오디언스로 만들고, 이 그룹 대상 재구매 유도 캠페인 초안까지 잡아줘"
"장바구니 이탈 직전에 띄울 인앱 모달을 만들어줘 — 카피랑 노출 조건까지"
"함께 구매 추천 시나리오 초안 만들어줘. 앱푸시랑 알림톡 중 뭐가 나을지도 같이 제안해줘"
둘 — 그 에이전트는 누가 책임지고 고치나요?
두 번째로 볼 건 품질을 책임지는 주체가 누구인지예요. AI 에이전트는 도입한 뒤에도 계속 점검하고 고쳐야 하는 제품이거든요.
MCP만 제공하는 솔루션은 자기 에이전트가 없어요. 실제 판단과 응답은 고객사가 붙인 외부 AI가 하니까, 그 도구들이 실제 대화에서 좋은 결과를 내는지 검증할 방법도, 검증할 의무도 구조적으로 없어요. 에이전트가 엉뚱하게 동작해도 "그건 고객사가 연결한 AI 문제"가 될 수밖에 없고요. "이 도구로 무엇을 어떻게 시킬지" 설계하고 품질을 관리하는 부담도 결국 도입팀에게 남아요.
블럭스는 에이전트가 곧 자사 제품이에요. 그래서 에이전트의 품질이 곧 자사 제품의 품질이 되어요. 모니터링·점검·수정도 공급사의 책임 범위 안에 들어오고요. 도입한 팀이 "이 에이전트, 믿고 써도 되나?"를 직접 물을 수 있는 상대가 생기는 거예요.
그리고 자체적으로 운영하기 때문에 실시간 모니터링이 자동화돼 있어요. 매 대화의 품질을 자동으로 평가하고, 이상 신호가 있는 세션을 자동으로 골라내고, 에러나 비정상 동작을 즉시 감지해요. 그래서 대부분의 문제는 고객사가 저희에게 알려주시기도 전에 저희가 먼저 발견해서 고쳐요. 알려주시는 경우에도 곧바로 대응하고, 보통 1~2주 안에 수정이 반영돼요. "다음 분기 로드맵"이 아니라 운영 중에 매일 돌아가는 사이클이에요.

이건 자체 에이전트가 있어야만 가능한 일이에요. 모니터링은 내가 통제하는 대상에만 할 수 있어요. 에이전트의 판단과 응답이 외부 AI에 있으면, 솔루션사는 채점할 대상도, 고칠 대상도 갖고 있지 않아요. 그래서 MCP만 제공하는 방식은 이 운영 사이클을 구조적으로 돌릴 수가 없어요.
정리하면
CRM AI 에이전트를 고를 때는 이 두 가지를 보세요. 한 번의 대화가 분석에서 집행까지 가는지, 그리고 그 에이전트를 누가 책임지고 고치는지. 두 질문은 결국 한 지점으로 모여요 — 그 솔루션이 에이전트를 직접 만들어 운영하느냐예요. 블럭스는 이 두 가지에 자신 있게 답하려고 에이전트를 직접 만들고, 매일 들여다보며 고쳐요.
이런 팀이라면 블럭스가 잘 맞아요
분석에서 끝나지 않고, 분석부터 캠페인·시나리오 집행까지 한 흐름으로 가고 싶은 팀
AI 에이전트를 도입하되, 품질을 책임지고 지속적으로 고쳐줄 공급사가 필요한 팀
마케팅 리소스는 한정돼 있어, AI 인프라를 직접 만들기보다 운영까지 받는 편이 합리적인 팀
대규모 운영에서 장애·이상 동작을 즉시 감지하고 빠르게 대응받는 안정성이 중요한 팀
자주 묻는 질문
Q. MCP를 제공하는 솔루션과 가장 큰 차이가 뭐예요?
두 가지예요. 첫째, 블럭스는 한 번의 대화가 분석에서 끝나지 않고 캠페인·시나리오·인앱 집행까지 이어져요 — 에이전트가 콘솔 기능 전반을 알고 있거든요. 둘째, 에이전트가 자사 제품이라 품질을 직접 검증하고 고쳐요. MCP만 제공하면 실제 에이전트는 고객사가 붙인 외부 AI라서, 솔루션사가 그 품질을 책임지기 어려워요.
Q. "한 대화로 집행까지"가 정확히 무슨 뜻이에요?
분석 → 오디언스 → 캠페인·시나리오·인앱 초안 생성까지를 하나의 대화 흐름으로 처리한다는 뜻이에요. 만들어진 결과는 콘솔에 초안으로 들어오고, 담당자가 검토한 뒤 집행해요. 사람이 마지막에 확인하는 단계는 그대로 두되, 거기까지 가는 길을 한 번의 대화로 좁히는 거예요.
Q. 에이전트가 잘못 동작하면 어떻게 되나요?
블럭스는 실시간 모니터링과 자동 평가로 이상 신호를 감지하고, 전담 팀이 원인을 분석해 수정해요. 수정은 운영 중에 빠르게 반영돼요. 도입팀이 직접 원인을 추적하거나 외부 AI 제공사에 문의해야 하는 구조가 아니에요.
Q. 도입 후 지원은 어떻게 받나요?
Enterprise 플랜부터 전담 PM이 배치되어 캠페인 설계·운영과 에이전트 품질 개선을 함께 해드려요. 운영 중 막히는 지점은 슬랙의 Blux Support Agent로 즉시 풀어볼 수 있어요.
고지사항: 본 콘텐츠는 작성 시점 기준 공개된 정보와 일반적인 솔루션 아키텍처를 바탕으로 CRM AI 운영 방식의 차이를 설명하기 위한 글이에요. 특정 솔루션을 비방할 목적이 아니라, AI 에이전트를 검토하는 팀이 기능 범위와 운영·책임 구조의 차이를 이해하는 데 도움을 드리기 위해 작성되었습니다. 솔루션별 세부 기능은 플랜·계약 범위, 그리고 업데이트 시점에 따라 달라질 수 있어요.