🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude Managed Agents는 skills, MCP, memory, session을 묶어 고객 업무 안에 배포 가능한 AI agent workflow로 만들면서, AI 자동화를 “도구 사용”이 아니라 “판매 가능한 업무 솔루션”으로 바꾸려는 접근이다.

📌 핵심 요점

1. Managed agents는 특정 use case에 맞춘 system prompt, skills, MCP, connectors, tools, agents, memory, context를 사전 패키징해 장시간 실행 가능한 agent system으로 구성된다.
2. 고객은 Claude Code나 Co-work 같은 도구 자체를 쓰지 않더라도, custom dashboard, Slack, Notion, Zapier, n8n, 기존 SaaS 안에서 버튼·폼·트리거 기반으로 AI 자동화를 사용할 수 있다.
3. 판매 기회는 AI capability와 실제 adoption 사이의 격차에서 생기며, AI service provider는 복잡한 agent architecture를 고객 친화적 interface로 포장해 반복 판매할 수 있다.
4. Skills와 memory는 managed agent의 안정성, 고객별 맥락 유지, 반복 개선, IP 보호에 핵심 역할을 하며, 단순 시스템 프롬프트보다 테스트와 운영에 유리한 구조로 설명된다.
5. 실제 운영에는 environment 분리, credential vault, MCP 권한 최소화, session 관리, Dream 기반 memory 업데이트, 외부 트리거 연결이 필요하며, 콘솔만으로는 한계가 있어 API 기반 구축이 강조된다.

🧩 배경과 문제 정의

• Claude managed agents는 skills, MCP, memory, sub agents를 묶어 특정 업무에 맞는 AI agent workflow로 사전 패키징하고, API를 통해 고객 환경에 배포할 수 있는 구조다.
• 많은 기업은 Claude Code나 Co-work 같은 도구를 직접 사용하지 않지만, 업무 효율화와 자동화 성과에는 비용을 지불할 수 있다. 이 도입 격차가 곧 판매 기회가 된다.
• 기존 agent automation은 확률적 오류 때문에 바로 업무 자동화에 적용하기 어려웠다. managed agents는 skills와 memory를 결합해 더 안정적이고 고객 맞춤형인 AI 솔루션을 만들 수 있다.
• API 기반 배포는 custom app, Slack, Notion, Zapier, n8n, 기존 SaaS, 다른 AI agent까지 연결될 수 있어, AI service provider에게 제품화와 반복 판매의 여지를 만든다.

🕒 시간순 섹션별 상세정리

1. Managed agents의 기본 구조와 사전 패키징 가능성

• Managed agents는 특정 use case에 맞춘 system prompt, skills, MCPs, connectors, tools, agents, memory, context를 미리 결합한 장시간 실행형 agent system이다 [00:39]
• Claude Code나 Co-work에서 쓰던 기능을 특정 workflow용으로 사전 구축해 cloud API로 실행하면, 고객이 필요한 위치에 AI solution을 배포할 수 있다 [00:53]

2. Custom dashboard와 event trigger 기반 고객 배포

• 사전 패키징된 agent solution은 custom web app이나 dashboard에 탑재되어 여러 AI automation 기능을 하나의 고객용 interface로 제공할 수 있다 [01:50]
• Lead prospecting agent는 human query로 Google spreadsheet에 lead list를 만들고, LinkedIn repurposing agent는 YouTube 영상 등을 scrape해 tone of voice에 맞는 post로 변환한다 [02:09]

3. Slack·업무툴·다른 AI agent로 확장되는 배포 경로

• Slack에 배포된 LinkedIn repurposing agent는 팀원들이 agent를 tag하며 post를 함께 수정할 수 있게 한다 [03:31]
• Slack 같은 chat app은 동료가 agent를 사용하는 장면 자체가 학습 계기가 되므로, 기업 내부 AI adoption을 높이는 배포 채널이 된다 [03:47]

4. 판매 기회와 비용 구조의 현실적 경계

• AI service provider는 skills, memory, MCP를 묶은 AI automation solution을 빠르게 만들고, Claude를 쓰지 않는 고객에게도 익숙한 interface로 제공할 수 있다 [04:58]
• 특정 workflow를 product로 패키징하면 AI agent SaaS를 빠르게 만들 수 있고, 기존 SaaS에도 agent capability를 즉시 추가할 수 있다 [05:18]

5. Skills가 만드는 안정성, IP 보호, 수익화 구조

• Skills가 managed agent workflow에 포함되면 agentic automation이 더 deterministic해지고, 테스트와 개선을 반복하면서 무작위 오류 비율을 낮출 수 있다 [07:21]
• 기존 agent automation은 stochastic·probabilistic 특성 때문에 일부 업무에서 예측 불가능한 실수를 만들었고, business workflow는 이런 오류를 크게 허용하기 어렵다 [07:30]

6. Memory 기반 AI OS와 실제 구축 준비

• Memory stores와 dream feature는 고객사의 business context를 담는 second brain이자 continuous learning AI system을 구성하게 해준다 [09:01]
• 고객 팀이 더 많이 사용할수록 agent는 memory에 축적된 맥락을 바탕으로 학습하고, pre-integrated skills와 함께 고객별 AI OS infrastructure로 배포될 수 있다 [09:15]

7. 콘솔 설정 한계와 skill 중심 에이전트 구성

• 콘솔 채팅은 화면을 벗어나면 대화가 사라져 사용성이 낮고, agent 탭에서는 agent ID, 모델, 상태, 버전, 시스템 프롬프트, 내장 도구 접근 권한을 확인할 수 있다 [12:02]
• 새 에이전트 생성이나 scale 편집은 JSON 기반이라 실무 설정에는 불편하며, 그래서 Cloud Code를 통해 더 관리하기 쉬운 방식으로 에이전트를 구성해야 한다 [12:16]

8. 고객별 환경 분리와 self-hosted 구성

• environment는 고객별 작업 공간처럼 작동하며, 각 환경 안에 서로 다른 에이전트와 세션을 배치해 클라이언트 단위로 운영 맥락을 분리할 수 있다 [14:00]
• self-hosted environment를 사용하면 LLM 자체는 클라우드에서 실행되더라도 MCP credentials와 session memory 같은 민감한 운영 데이터는 자체 호스팅 환경에 둘 수 있다 [14:19]

9. Credential vault와 MCP 권한 최소화

• credential vault는 여러 MCP와 권한을 묶는 단위이며, 일반적으로 에이전트 하나당 vault 하나를 두면 필요한 도구만 노출하는 최소 권한 구조를 만들 수 있다 [14:58]
• LinkedIn writer agent처럼 특정 업무를 맡은 에이전트에는 Firecrawl, Apify, VidIQ 등 필요한 MCP만 허용하고, 다른 소프트웨어 접근은 막아 의도하지 않은 작업 실행 리스크를 줄인다 [15:14]

10. Session과 memory store로 작업 단위와 반복 맥락 관리

• session은 새 task를 실행하는 작업 단위이며, Cloud Co-Worker나 Cloud Code에서 특정 에이전트, environment, memory store를 묶어 시작한다 [16:22]
• Slack에서 에이전트를 태그할 때마다 LinkedIn post 작성이나 YouTube repurpose처럼 서로 다른 작업은 새 session으로 분리해 시작해야 한다 [16:48]

11. Persistent memory와 Dream 기반 지속 학습

• memory store는 churn recovery workflow의 churn log처럼 이미 follow-up한 client를 기록해 에이전트가 과거 작업 상태를 이어가게 하는 운영 저장소다 [18:24]
• 고객지원 에이전트는 고객별 문제, 해결 여부, 이전 조치 내역을 기억하고, 같은 고객이 새 thread를 열면 그 맥락을 바탕으로 응답할 수 있다 [18:44]

12. Cloud Code 구축 흐름과 배포 대시보드 필요성

• Cloud Managed Agent Console의 file context에는 전략 문서, Pinpoint 문서, brand doc 등을 붙일 수 있지만, 콘솔에 직접 업로드 버튼이 없어 Cloud Code를 통한 programmatic upload가 필요하다 [21:00]
• Cloud Code에 Managed API documentation을 먼저 읽히면, API context를 바탕으로 cloud console account 안에 managed agent를 만들 수 있다 [21:15]

13. 자동화 플랫폼을 통한 관리형 에이전트 배포와 트리거 연결

• 관리형 에이전트를 만든 뒤 배포하면 커스텀 앱 형태로 실행되며, 이후 테스트와 반복 개선을 거쳐 실제 사용 가능한 구조로 다듬는다 [24:02]
• 특정 시간 간격으로 에이전트를 실행하려면 n8n이나 Zapier 같은 자동화 플랫폼의 기본 트리거를 활용하는 방식이 가장 단순하다 [24:17]

14. Slack·챗봇 통합에서 필요한 세션 관리와 후속 학습 안내

• WhatsApp, Slack, Notion 같은 소프트웨어나 챗봇 안에서 에이전트를 실행할 때도 자동화 플랫폼을 쓰면 사전 통합된 트리거 덕분에 직접 구현 부담이 줄어든다 [26:10]
• Make.com의 Slack 트리거는 새 메시지 감지를 처리할 수 있으며, Slack 스레드별로 같은 세션을 유지해야 대화 맥락과 메모리가 끊기지 않는다 [26:17]

🧾 결론

• 이 영상의 핵심은 managed agents가 AI 자동화를 “채팅형 도구”에서 “고객 업무 흐름에 심는 제품형 솔루션”으로 전환할 수 있다는 주장이다.
• 특히 고객이 이미 쓰는 Slack, Notion, 업무 소프트웨어, 자동화 플랫폼 안에 agent를 배포하면, 새로운 도구를 학습시키는 부담을 줄이고 실제 adoption을 높일 수 있다.
• skills는 agent workflow를 더 예측 가능하게 만들고, memory는 고객별 맥락을 누적해 지속적으로 개선되는 AI OS 형태의 가능성을 만든다.
• 다만 managed agents 자체에는 trigger 기능이 없기 때문에, 실제 판매·운영 단계에서는 dashboard, webhook, schedule, automation platform 같은 외부 실행 구조를 별도로 설계해야 한다.
• 비용 측면에서는 API 비용과 실행 시간당 비용이 언급되므로, 내부 자동화인지 고객 판매용 제품인지에 따라 경제성을 따로 판단해야 한다.

📈 투자·시사 포인트

• AI service provider에게는 범용 AI 도구를 설명하는 것보다, churn recovery, lead prospecting, LinkedIn repurposing, customer support처럼 명확한 업무 단위로 패키징하는 전략이 더 판매 가능성이 높아 보인다.
• 기존 SaaS 기업은 managed agents를 통해 자사 제품에 agent capability를 빠르게 추가할 수 있으며, 이는 기능 확장과 고객 락인 강화의 수단이 될 수 있다.
• 기업 도입 관점에서는 agent의 성능뿐 아니라 credentials, memory, environment, 권한 제한, session routing 같은 운영 설계가 신뢰성과 보안 판단의 핵심 변수가 된다.
• 검증 필요: 영상에서는 skills가 더 deterministic한 workflow를 만든다고 설명하지만, 실제 업무별 오류율 감소와 운영 안정성은 각 use case에서 테스트와 eval로 확인해야 한다.
• 검증 필요: managed agents의 수익성은 API 비용, 실행 시간당 8센트 비용, 고객별 사용 빈도, 자동화가 절감하는 인건비나 매출 기여도를 기준으로 별도 계산해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상에서는 Managed Agents 비용이 “API 비용 + 실행 시간당 8센트”라고 설명하지만, 실제 과금 단위·최신 가격·무료/베타 조건은 공식 요금표와 콘솔 문서에서 별도 확인이 필요하다.
• “Dream” 기능이 과거 대화를 훑어 memory store에 learning을 추가하고 API로 스케줄링할 수 있다는 설명은 영상 기준 정보이므로, 현재 제공 범위와 API 지원 여부를 공식 문서로 검증해야 한다.
• self-hosted environment에서 MCP credentials와 session memory 같은 민감 데이터가 어느 범위까지 자체 환경에 남는지는 보안·컴플라이언스 관점에서 추가 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 고객에게 판매할 첫 Managed Agent use case를 하나로 좁히고, trigger·input·output·성공 기준을 정의한다.
• 해당 use case에 필요한 skills, MCP, memory store, credential vault, environment 구성을 문서화한다.
• API 기반 배포 전에 공식 Managed Agent API 문서에서 session 생성, agent 실행, memory 연결, 파일 업로드 가능 범위를 확인한다.
• Slack thread, dashboard form, webhook, schedule trigger 중 어떤 사용자 접점이 가장 자연스러운지 결정한다.

❓ 열린 질문

• Managed Agent를 고객별로 완전히 분리해 운영할 때, environment·vault·memory store를 어떤 단위로 나누는 것이 가장 안전하고 유지보수하기 쉬운가요?
• Slack 같은 대화형 배포와 custom dashboard 같은 버튼형 배포 중, 비기술 고객에게 더 높은 adoption을 만드는 방식은 무엇인가요?
• Skills 내부에 domain expert의 노하우를 숨겨 판매할 경우, 고객에게 어느 정도까지 설명해야 신뢰와 IP 보호 사이의 균형을 맞출 수 있을까요?