🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

How to Build AI Agents That Actually Work의 핵심은 코딩보다 명확한 업무 정의, 실제 도구 접근, 메모리, 비용 통제를 갖춰 AI 에이전트가 반복 업무를 끝까지 수행하게 만드는 것이다.

📌 핵심 요점

1. AI 에이전트는 단순히 답변하는 챗봇이 아니라, 목표를 받은 뒤 계획을 세우고 브라우저·이메일·업무 앱 같은 도구를 사용하며 결과를 확인해 작업 완료까지 이어가는 시스템으로 설명된다.
2. 작동하는 에이전트의 기본 조건은 명확한 job description, 업무에 필요한 tools, 반복 실행에서 누적되는 memory이며, 모호한 지시나 권한 부족은 실패 가능성을 높인다.
3. 초보자는 바로 실행하는 execute mode보다 plan first mode로 시작해 계획을 검토하고, approve plan·request changes·reject plan을 통해 비용과 방향 오류를 먼저 통제하는 흐름이 강조된다.
4. 일회성 리서치 작업은 공유 가능한 웹 리포트로 전환될 수 있고, 이후 weekly agent로 저장하면 일정 실행, 예산 상한, 이메일·웹훅·Slack 같은 호출 방식까지 운영할 수 있다.
5. Scout와 Producer처럼 역할이 다른 여러 에이전트를 연결하면 리서치 보고서가 콘텐츠 기획안과 썸네일 같은 후속 산출물로 이어지며, 비용 대시보드와 최적화 기능으로 반복 작업의 비용 구조를 관리할 수 있다.

🧩 배경과 문제 정의

• 이 영상은 “AI agent”를 단순히 질문에 답하는 챗봇이 아니라, 목표를 받고 계획을 세우며 도구를 사용하고 결과를 확인해 실제 업무를 끝내는 자동화 단위로 설명한다.
• 핵심 문제는 많은 agent가 실제 업무에서 실패한다는 점이다. 실패 원인은 주로 지시가 모호하거나, 이메일·브라우저·업무 앱 같은 실제 도구에 접근하지 못하거나, 반복 작업에서 맥락과 학습이 쌓이지 않는 데 있다.
• 작동하는 agent를 만들려면 먼저 agent가 맡을 job description을 분명히 해야 하고, 업무 수행에 필요한 도구와 앱 권한을 agent별로 부여해야 한다.
• 또한 한 번 만든 agent가 매번 처음부터 다시 시작하지 않도록 memory, rubric, prompt 개선을 통해 반복 작업에서 학습이 누적되도록 관리해야 한다.
• 초보자에게 중요한 운영 안전장치는 바로 실행시키는 것이 아니라 계획을 먼저 검토하고, 비용 한도와 실행 일정, Slack 응답 방식, 앱 권한 범위를 명확히 설정하는 것이다.
• 영상의 시연은 하나의 리서치 agent를 만든 뒤 Slack에 연결하고, 이어 두 번째 제작 agent를 붙여 리서치 결과가 콘텐츠 기획과 썸네일 제작으로 이어지는 흐름을 보여준다.
• 검증이 필요한 내용: 가입 링크의 1,000달러 free credits 제공 여부, 시연 당시 실제 비용 수치, HyperAgent의 최신 기능·가격·연동 앱 목록은 영상 시점 기준 설명으로 보이며 현재 상태는 별도 확인이 필요하다.

🕒 시간순 섹션별 상세정리

1. AI agent의 기준과 세 가지 필수 조건

• AI agent는 리드 선별, 미납 인보이스 후속 연락, 고객지원 티켓 처리, 파트너십 outreach처럼 실제 업무를 대신 수행하는 방향으로 설계된다 [00:06]
• 챗봇은 질문에 답한 뒤 사용자가 다음 단계를 직접 처리해야 하지만, agent는 목표를 받은 뒤 계획 수립, 도구 사용, 결과 점검을 거쳐 작업 완료까지 계속된다 [00:51]
• 이 차이를 기준으로 보면 작동하는 agent에는 명확한 역할 정의, 브라우저·이메일 같은 업무 도구 접근, 반복 실행에서 유지되는 메모리가 필요하다 [01:06]

2. 가입과 빈 thread에서 시작하는 첫 작업 설계

• 시연에서는 가입 링크가 1,000달러 free credits를 제공한다고 설명하며, 이 credits는 agent가 수행하는 작업 비용에 쓰이는 초기 실행 여유분으로 묶인다 [02:32]
• dashboard에는 personal agent, team of agents, interview flow, OpenClaw agent import 같은 시작점이 있지만, agent 구조를 이해하려면 blank page에서 task를 먼저 실행하는 방식이 적합하다고 보여준다 [02:55]
• 즉 처음부터 완성된 agent를 만드는 대신, 빈 thread에서 한 번의 실제 업무를 시켜 보고 그 과정을 agent로 저장하는 접근을 택한다 [03:10]

3. 프롬프트 템플릿과 계획 검토로 방향 오류 줄이기

• 예시 prompt는 content creation software market 조사를 대상으로 하지만, 핵심 변수는 market 하나이므로 온라인 스토어의 product market이나 freelancer의 client industry로 바꿔도 같은 절차가 유지된다 [04:07]
• 메시지를 보낸 뒤에는 edit이 불가능하므로 오류를 발견하면 stop button으로 중단하고 corrected message를 다시 보내야 불필요한 진행을 줄일 수 있다 [04:30]
• agent가 바로 실행에 들어가기 전에 계획을 보여주는 단계는 방향 오류를 조기에 잡는 안전장치로 활용된다 [04:45]

4. 일회성 research report를 공유 가능한 결과물로 전환

• 완료 후 final response 안의 brief는 canvas에서 열리는 organized report가 되고, 실제 web page 형태로 full screen 확인이 가능하다 [06:03]
• public link는 private window에서도 열리기 때문에 HyperAgent account가 없는 사람에게도 report 공유가 가능하다 [06:24]
• 이 단계에서 일회성 채팅 답변은 단순 텍스트가 아니라 외부 공유가 가능한 보고서 산출물로 바뀐다 [06:39]

5. weekly agent 저장과 비용·일정 관리

• “save this as an agent and turn on live mode” prompt는 기존 brief 작업을 자동 주간 보고 agent로 바꾸고, draft agent card에는 system prompt와 model 설정이 포함된다 [07:17]
• system prompt는 Creator Tools Weekly를 content creation software industry의 weekly market brief를 만드는 research analyst로 정의하며, 저장 전 edit으로 조정할 수 있다 [07:36]
• 반복 agent로 저장할 때는 단순히 프롬프트만 고정하는 것이 아니라, 실행 일정과 예상 비용, agent가 수행할 역할을 함께 관리해야 한다 [07:51]

6. 내장 tools, app integrations, Slack identity로 teammate화

• agent의 built-in toolbox에는 web search, real website browsing, document creation, slide와 presentation 생성, image·video·audio generation이 포함된다 [10:16]
• integrations는 Airtable, Dropbox, GitHub, Gmail, Google Calendar, Google Drive, HubSpot, OneDrive, Slack 등 실제 업무 앱과 연결되며, 권한은 global이 아니라 agent별로 부여된다 [10:53]
• 이 구조 덕분에 agent는 모든 권한을 한꺼번에 갖는 범용 봇이 아니라, 맡은 업무에 필요한 권한만 가진 팀원처럼 구성된다 [11:08]

7. Scout의 Slack 연결과 전용 봇 정체성 구성

• HyperAgent에서 Slack 채널 추가를 시작하고, Slack 워크스페이스 접근을 허용한 뒤 기본 공유 봇 대신 별도 Slack identity를 만들 수 있다 [12:00]
• Slack app management에서 토큰을 생성하고 HyperAgent에 붙여 넣으면, HyperAgent 봇과 구분되는 Slack 앱 정체성을 구성할 수 있다 [12:38]
• Scout처럼 특정 업무를 맡은 agent에는 별도 봇 정체성을 부여해 팀원이 누구를 호출하는지 명확히 알 수 있게 한다 [12:53]

8. 채널 트리거·응답 방식·권한을 협업 환경에 맞춤

• Scout는 content creation 채널에 추가되고 mentions only로 설정되어, 누군가 직접 호출할 때만 응답하며 채널 소음을 줄인다 [13:32]
• reply style을 stream the response로 두면 웹 검색과 도구 사용 같은 중간 단계가 모두 채널에 올라와 빠르게 시끄러워지므로, final response only가 동료처럼 완성본만 전달하는 방식에 가깝다 [14:12]
• 협업 환경에서는 agent가 얼마나 자주 말할지, 어느 채널에서 반응할지, 중간 과정을 공개할지까지 운영 방식의 일부로 설계해야 한다 [14:27]

9. Slack에서 Scout를 호출하고 결과물 형식을 대화로 조정

• Scout가 Slack 채널에 들어오면 팀은 @Scout 멘션으로 최신 리서치와 추천을 요청할 수 있고, speech balloon 반응은 작업이 진행 중이라는 신호가 된다 [15:48]
• mentions only 모드에서는 Scout가 만든 스레드 안에서도 반드시 @Scout를 붙여야 하며, 응답이 없는 것처럼 보이는 문제는 대부분 호출 방식에서 생긴다 [16:12]
• 결과물이 원하는 형식과 다르면 Slack 대화 안에서 다시 요청해 형식을 조정할 수 있으며, 이 과정은 agent를 협업 팀원처럼 다루는 흐름에 가깝다 [16:27]

10. 학습 탭에서 메모리·루브릭·프롬프트 개선을 승인

• 작업이 끝난 뒤 에이전트는 보관할 학습 항목을 제안하고, Learning 탭의 배지는 확인이 필요한 제안 수를 보여준다 [17:19]
• 메모리는 비즈니스 정보와 전달 위치 같은 사실을 유지하고, rubric은 향후 작업을 평가할 점수표 역할을 하며, prompt suggestion은 업무 지시 자체를 더 날카롭게 만든다 [18:11]
• 사용자는 agent가 제안한 학습 내용을 검토하고 승인함으로써 다음 실행에서 같은 맥락을 반복 설명하지 않아도 되도록 만든다 [18:26]

11. 두 번째 에이전트 Producer를 만들어 Scout의 결과를 후속 제작물로 전환

• 두 번째 에이전트가 생기면 Scout의 주간 리서치 brief를 받아 촬영 가능한 영상 기획안과 썸네일로 바꾸는 역할 분담이 가능해진다 [19:16]
• 새 에이전트는 chat 기반 생성 흐름에서 업무를 정의하며, Scout의 최신 보고서를 받아 최상위 제안의 script outline과 thumbnail image를 만드는 역할을 맡는다 [19:32]
• 여기서 agent 운영은 하나의 자동화 작업을 넘어, 리서치 담당과 제작 담당이 연결되는 작은 워크플로로 확장된다 [19:47]

12. Producer를 passive mode로 Slack에 연결하고 백그라운드 실행을 확인

• Producer도 Scout와 다른 Slack identity를 가져야 하므로 같은 절차로 별도 Slack 앱을 만들고, content creation 채널에 연결한다 [21:27]
• Producer는 passive mode로 설정되어 채널 메시지를 훑고 자신과 관련된 내용이면 응답하며, 관련 없는 메시지는 무시한다 [22:08]
• passive mode는 모든 메시지에 반응하는 방식이 아니라, 맥락상 자기 업무와 연결된 경우에만 백그라운드에서 개입하도록 만드는 설정으로 드러난다 [22:23]

13. 리서치 결과가 콘텐츠 제작 파이프라인으로 이어짐

• Slack 스레드에 Producer 결과가 돌아왔고, 썸네일 이미지와 스크립트 아웃라인이 함께 포함되어 바로 영상 작업을 시작할 수 있는 상태가 된다 [24:05]
• 산출물에는 작업 제목 후보, 훅, 세팅, 주요 비트가 들어 있으며, 단순 요약이 아니라 실제 제작에 필요한 구성 요소가 묶여 있다 [24:17]
• 이 장면은 Scout가 발견한 리서치 인사이트가 Producer를 거쳐 실행 가능한 콘텐츠 제작 패키지로 바뀌는 파이프라인을 보여준다 [24:32]

14. 비용 가시화와 반복 작업 최적화

• 실제 작업에는 비용이 들고, Command Center에서는 에이전트별 실행, 실행당 비용, 전체 비용을 한곳에서 확인할 수 있어 운영 비용이 블랙박스로 남지 않는다 [25:30]
• Scout 실행은 Hyper Agent 스레드와 Slack에서 각각 한 번씩 총 두 번 발생했고, 두 실행의 총비용은 12.64달러였으며, 전체 시연 비용은 18.21달러로 집계된다 [25:52]
• 영상의 후반 결론은 agent를 “멋진 데모”가 아니라 비용, 권한, 일정, 메모리, 협업 채널을 함께 관리해야 하는 반복 업무 시스템으로 보아야 한다는 점으로 압축된다 [26:07]
• 검증이 필요한 내용: 제공된 section-detail은 25:52까지의 비용·운영 정리까지만 포함하므로, 영상 전체 28:30 중 25:52 이후의 추가 마무리 발언은 원 transcript 확인이 필요하다 [26:22]

🧾 결론

• 이 영상은 “노코드로 AI 에이전트를 만든다”는 주제를 단순 자동화 설정이 아니라, 업무 정의·도구 연결·메모리 승인·비용 관리까지 포함한 운영 방식으로 설명한다.
• 핵심 메시지는 에이전트가 똑똑해 보이는 답변을 내는 것보다, 실제 업무 앱에 접근하고 반복 가능한 역할을 맡아 결과물을 끝까지 만드는 구조가 더 중요하다는 점이다.
• HyperAgent 사례에서는 Scout가 주간 리서치를 만들고 Producer가 이를 콘텐츠 제작물로 전환하는 흐름을 통해, 여러 에이전트가 팀처럼 협업하는 패턴을 보여준다.
• 다만 영상 속 무료 크레딧, 실제 비용, 특정 플랫폼 기능은 영상에서 제시된 내용이므로, 사용 전 현재 제공 조건과 가격 정책은 별도로 확인해야 한다.

📈 투자·시사 포인트

• AI 에이전트 시장의 경쟁력은 단순 모델 성능보다 실제 업무 도구와의 통합, 권한 관리, 메모리 관리, 비용 가시성 같은 운영 레이어에서 갈릴 가능성이 크다.
• 기업 도입 관점에서는 “완전 자동 실행”보다 계획 승인, 예산 상한, 권한 범위 제한, final response only 같은 안전장치가 초기 확산의 핵심 조건이 될 수 있다.
• 반복 업무 자동화의 ROI는 한 번의 실행 비용보다 같은 작업을 얼마나 안정적으로 재사용하고 최적화해 비용을 낮추는지에 달려 있다.
• Slack 같은 협업 도구 안에서 에이전트가 개별 정체성을 갖고 팀원처럼 호출되는 방식은, AI 도입이 별도 앱 사용에서 업무 흐름 내 상시 협업으로 이동하고 있음을 시사한다.
• 검증 필요: 영상에서 언급된 1,000달러 free credits, 실행 비용 예시, HyperAgent의 세부 기능과 통합 범위는 업로드 시점 기준 설명이므로 실제 가입·구독·운영 전 최신 조건을 확인해야 한다.

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

• HyperAgent 가입 링크의 “1,000달러 free credits” 제공은 영상 내 안내 기준이며, 현재 프로모션 조건, 적용 대상, 만료일, 실제 과금 단위는 별도 확인이 필요하다.
• Scout 실행 2회 총비용 12.64달러, 전체 시연 비용 18.21달러는 특정 데모 조건의 결과이므로, 실제 업무량·모델·도구 호출·스케줄 빈도에 따라 비용이 달라질 수 있다.
• Slack 별도 identity, passive mode, automated messages 응답, 채널별 read/write 권한 설정은 각 워크스페이스의 보안 정책과 Slack 앱 승인 절차에 따라 가능 여부가 달라질 수 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 첫 에이전트를 만들기 전에 job description에 목표, 대상 시장·고객, 완료 기준, 결과물 형식, 금지 행동을 명확히 적는다.
• 초도 실행은 execute mode가 아니라 plan first mode로 시작해 summary와 to-do list를 검토한 뒤 approve, request changes, reject 중 하나로 통제한다.
• 반복 실행 에이전트에는 query당 budget limit를 설정하고, 첫 주에는 Command Center에서 실행당 비용과 전체 비용을 모니터링한다.
• Slack 연동 시 에이전트별로 필요한 채널만 연결하고, mentions only 또는 passive mode 중 업무 목적에 맞는 트리거 방식을 선택한다.

❓ 열린 질문

• 우리 업무에서 첫 번째로 자동화할 반복 작업은 주간 리서치, 고객 응답, 콘텐츠 기획, 보고서 작성 중 무엇이 가장 효과가 큰가?
• 에이전트가 접근해도 되는 업무 앱과 데이터 범위는 어디까지이며, 어떤 정보는 절대 읽거나 공유하면 안 되는가?
• Slack에서 에이전트를 동료처럼 쓰려면 mentions only, passive mode, scheduled run 중 어떤 호출 방식이 팀의 소음과 응답 속도 균형에 가장 적합한가?