🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI Messaging App인 Bloom의 핵심은 5가지 도구를 단순히 줄이는 것이 아니라, 기억·역할 분담·공유 대화를 통해 AI 작업 흐름의 맥락 손실을 줄이는 데 있다.

📌 핵심 요점

1. Bloom은 Slack이나 WhatsApp처럼 보이는 메시징 구조 안에 AI 에이전트를 팀원처럼 배치해, 사용자가 매번 새 채팅에서 프로젝트 맥락을 다시 설명해야 하는 문제를 줄이려 한다.
2. 콘텐츠 리드, 작가, 아트 디렉터, 오디언스처럼 역할이 나뉜 에이전트들이 같은 스레드의 맥락을 공유하면서 브리프, 대본, 시각물, 리뷰까지 이어받는다.
3. 영상 제작 예시에서는 한 줄 브리프에서 시작해 콘텐츠 방향, 훅, 구조, CTA, 대본, 썸네일 검토까지 하나의 대화 안에서 연결되는 흐름이 제시된다.
4. 멀티모델 팀 기능은 여러 AI 모델의 답변을 탭마다 복사해 비교하는 대신, 한 스레드 안에서 서로 다른 관점과 판단 기준을 나란히 확인하게 해준다.
5. Bloom의 결과 품질은 에이전트 자체보다도 사용자의 브리핑 선명도에 크게 좌우되며, 일부 에이전트는 아직 초안처럼 느껴질 만큼 완성도 차이가 있다고 언급된다.

🧩 배경과 문제 정의

• 일반적인 AI 챗봇 기반 작업은 매번 빈 입력창에서 다시 시작되는 경우가 많고, 이전 결정·프로젝트 맥락·반복 입력이 대화마다 끊기는 문제가 있다.
• 영상에서 소개되는 Bloom은 AI 에이전트를 메시징 앱의 팀원처럼 배치해, 같은 대화 안에서 역할별 작업과 장기 맥락을 유지하려는 방식으로 이 문제를 다룬다.
• 핵심 변화는 하나의 범용 어시스턴트에게 모든 일을 맡기는 것이 아니라, 콘텐츠 리드·작가·아트 디렉터·오디언스처럼 서로 다른 역할을 가진 에이전트들이 같은 스레드에서 협업한다는 점이다.
• 이 구조에서는 브리프 작성, 스크립트 생성, 시각물 제작, 리뷰, 모델 비교가 각각 분리된 도구나 탭이 아니라 하나의 대화 흐름 안에서 이어진다.
• 다만 결과 품질은 도구 자체보다 사용자가 얼마나 명확하게 목표와 맥락을 전달하느냐에 크게 좌우된다는 점이 후반부의 핵심 문제의식으로 제시된다.

🕒 시간순 섹션별 상세정리

1. 반복되는 맥락 손실과 Bloom의 기본 구조

• 기존 AI 작업은 ChatGPT를 열 때마다 프로젝트 설명과 결정 사항을 다시 붙여 넣는 방식에 가까웠고, 발표자는 지난 2년 동안 빈 입력창에서 다시 출발하는 반복이 기본값처럼 굳어졌다고 보여준다 [00:59]
• Bloom은 Slack이나 WhatsApp처럼 보이는 메시징 앱 구조를 사용하지만, 실제 사람 연락처가 있는 자리에 AI 에이전트들이 들어가고 멘션을 받으면 같은 스레드 안에서 실시간으로 답한다 [01:14]
• 이 구조의 핵심은 대화가 일회성 프롬프트로 끝나지 않고, 프로젝트 맥락과 역할별 응답이 같은 채팅 안에 남는다는 점이다 [01:29]

2. 역할별 콘텐츠 팀과 기존 기획 방식의 차이

• 콘텐츠 팀은 콘텐츠 리드, 작가, 아트 디렉터, 오디언스로 구성되며, 각각 주제 선정·일정·품질 기준, 문장 작성, 시각물 제작, 최종 반응 검토를 맡는다 [02:22]
• 하나의 범용 어시스턴트가 모든 작업을 처리하는 방식과 달리, 네 개의 역할이 하나의 공유 채팅 안에서 각자 판단하고 다음 산출물로 이어받는다 [02:56]
• 이 방식은 콘텐츠 제작을 단일 프롬프트 응답이 아니라, 작은 팀이 회의하며 기획·작성·검토를 이어가는 흐름에 가깝게 만든다 [03:11]

3. 시각물 제작과 오디언스 리뷰까지 이어지는 공유 맥락

• 아트 디렉터는 같은 채팅과 같은 맥락 안에서 작가가 만든 대본 전체를 볼 수 있기 때문에, 영상 주제나 의도를 다시 설명하지 않아도 썸네일과 시각 레이어 작업으로 넘어갈 수 있다 [05:50]
• 썸네일 이미지는 단순 생성물로 끝나지 않고, 장점, 모바일 화면에서의 스케일 문제, 이미지 안 텍스트 배치 옵션까지 함께 검토 대상이 된다 [06:20]
• 이 흐름은 시각물 제작과 피드백이 따로 분리되지 않고, 앞서 만들어진 대본과 기획 맥락 위에서 이어진다는 점을 보여준다 [06:35]

4. 여러 모델을 한 스레드에서 비교하는 멀티모델 팀

• 멀티모델 팀에서는 Claude Code, Codex, DeepSeek이 같은 채팅에 들어오며, 같은 프롬프트를 여러 탭에 복사하지 않고 한 스레드에서 답변을 나란히 비교할 수 있다 [07:47]
• 발표자는 “2026년 콜드 이메일 작성에 가장 좋은 도구”라는 질문을 예시로 던지고, Claude Code는 Clay, Instantly, Lavender 조합을 제안한다 [08:06]
• 이어서 Codex와 DeepSeek을 태그해 같은 질문에 대한 각자의 판단을 요청함으로써, 한 대화 안에서 여러 모델의 관점을 비교하는 사용 방식을 보여준다 [08:21]

5. 사전 제작 팀, 커스텀 에이전트, 실제 장단점

• 콘텐츠 팀은 Bloom 안에 있는 여러 사전 제작 팀 중 하나로 소개되며, 투자 팀에는 금융 리드, 미국 전문가, 홍콩 전문가, A주 전문가처럼 서로 다른 페르소나의 에이전트가 들어간다 [09:23]
• 사용자는 기존 팀을 쓰는 것뿐 아니라 새 에이전트를 만들 수도 있으며, 이때 로컬 컴퓨터 기반 에이전트나 24시간 온라인 상태의 클라우드 기반 에이전트를 선택할 수 있다 [10:11]
• Claude Code, Codex, Gemini CLI, OpenCode 같은 코딩 도구도 같은 공유 채팅에 연결할 수 있어, 일반 대화형 에이전트와 개발 도구를 한 흐름 안에서 다루는 방식이 가능해진다 [10:26]
• 다만 이런 확장성은 자동으로 좋은 결과를 보장한다기보다, 사용자가 역할과 목적을 어떻게 설정하느냐에 따라 효용이 달라지는 구조로 드러난다 [10:41]

6. 명확한 브리핑이 결과 품질을 좌우한다

• 발표자는 결과가 모호하게 나올 때 단순히 버튼을 누르는 사용법만 익히는 것으로는 부족하다고 말하며, 실제 팀에 업무를 맡기듯 방향과 맥락을 분명히 잡아야 한다고 보여준다 [12:03]
• 산출물의 품질은 지시의 선명도와 직접 연결되며, 사용자가 목표와 방향을 흐리게 주면 결과도 그만큼 불안정해진다 [12:11]
• 이 대목에서 Bloom의 가치는 에이전트 수나 기능 자체보다, 사용자가 여러 역할에게 명확한 브리프를 주고 협업 흐름을 설계할 때 더 잘 드러난다는 논지가 압축된다 [12:26]

7. 협업형 에이전트 모델과 실제 업무 테스트

• 후반부에서는 에이전트가 사용자를 기억하고, 자기 역할을 정의하며, 다른 에이전트와 협업하는 방향으로 움직인다는 점이 중요하다 [12:37]
• 이 모델은 일반적인 단일 AI 도구와 달리, 역할이 나뉜 에이전트들이 같은 맥락 안에서 상호작용하는 작업 환경에 가깝게 묶인다 [12:52]
• 더 많은 사람이 기여할수록 에이전트가 개선되는 구조로 설명되며, 개인용 자동화 도구를 넘어 협업형 제작 환경으로 확장될 가능성이 드러난다 [13:07]
• 마지막 논지는 Bloom을 실제 업무에 적용해보면, 여러 도구를 오가며 맥락을 잃는 방식 대신 하나의 메시징 기반 작업 공간에서 팀처럼 AI를 다루는 흐름을 테스트할 수 있다는 데 모인다 [13:12]

🧾 결론

• Bloom은 “하나의 더 똑똑한 챗봇”이라기보다, 여러 역할의 AI 에이전트가 같은 대화 맥락을 유지하며 협업하는 작업 환경에 가깝다.
• 영상에서 가장 반복적으로 강조되는 가치는 메모리와 공유 맥락이다. 프로젝트의 이전 결정, 방향, 산출물을 에이전트들이 이어받기 때문에 반복 설명과 도구 전환이 줄어든다.
• 콘텐츠 제작 사례에서는 아이디어 발굴, 대본 작성, 썸네일 검토, 오디언스 피드백이 한 흐름으로 묶이며, 기존의 ChatGPT·검색·문서·디자인 검토를 오가던 방식보다 덜 끊기는 작업 방식이 제시된다.
• 다만 결과가 항상 명확한 것은 아니며, 원하는 수준의 산출물을 얻으려면 실제 팀원에게 업무를 맡기듯 목표, 대상, 포맷, 판단 기준을 구체적으로 전달해야 한다.

📈 투자·시사 포인트

• AI 도구의 경쟁 축이 단일 모델 성능에서 “작업 맥락을 얼마나 오래 유지하고, 여러 역할을 얼마나 자연스럽게 연결하느냐”로 이동하고 있음을 보여준다.
• Bloom이 강조하는 메시징형 인터페이스는 사용자가 이미 익숙한 협업 방식 위에 AI를 배치하는 접근이다. 이는 AI 제품의 사용 장벽을 낮추는 방향으로 해석할 수 있다.
• 에이전트 마켓플레이스인 Plaza와 커스텀 에이전트 구조는, 향후 특정 업무에 최적화된 에이전트를 만들고 복제·수정하는 생태계형 모델의 가능성을 시사한다.
• 검증 필요: 영상에서는 무료 시작과 크레딧 충전 모델이 언급되지만, 실제 비용 효율성, 장기 사용 시 비용 구조, 팀 단위 사용 가치가 충분한지는 별도 확인이 필요하다.
• 검증 필요: 일부 에이전트의 완성도 차이와 모호한 응답 가능성이 언급되므로, 실무 도입 전에는 실제 업무를 넣어 품질·일관성·반복 사용성을 테스트하는 과정이 중요하다.

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

• Bloom의 “세션을 넘어 맥락과 결정을 기억한다”는 설명은 영상 내 데모와 제작자의 사용 경험에 기반한 주장으로 보이며, 실제로 얼마나 오래·정확하게 기억이 유지되는지는 별도 장기 테스트가 필요하다.
• 콘텐츠 리드, 작가, 아트 디렉터, 오디언스 에이전트가 같은 맥락을 공유한다는 흐름은 영상에서 핵심 장점으로 제시되지만, 복잡한 실제 프로젝트에서 충돌 없이 역할 분담이 되는지는 추가 검증이 필요하다.
• Claude Code, Codex, DeepSeek 등을 한 스레드에서 비교하는 기능은 유용해 보이지만, 각 모델의 응답 품질·최신성·도구 접근 권한이 동일한 조건에서 비교되는지는 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Bloom을 단순 호기심용이 아니라 실제 진행 중인 프로젝트 하나에 적용해, 기억 유지·역할 분담·산출물 품질을 함께 테스트한다.
• 콘텐츠 제작용으로 콘텐츠 리드, 작가, 아트 디렉터, 오디언스 역할을 나눠 브리프 → 대본 → 썸네일 → 리뷰까지 한 스레드에서 진행해 본다.
• 테스트할 때 “영상 하나 만들어줘”처럼 모호하게 요청하지 말고, 대상 독자, 플랫폼, 길이, 톤, 목표, CTA를 포함한 명확한 브리프를 먼저 작성한다.
• 멀티모델 비교가 필요한 작업에서는 같은 질문을 여러 탭에 복사하지 말고, 한 스레드에서 모델별 답변 차이와 판단 기준을 비교한다.

❓ 열린 질문

• Bloom의 장기 기억은 프로젝트별로 얼마나 정확히 분리되며, 서로 다른 작업 맥락이 섞이는 문제는 없는가?
• 에이전트가 여러 명 참여하는 구조에서 서로 다른 판단이 충돌할 때, 최종 의사결정은 어떻게 정리되는가?
• 콘텐츠 제작 외에 리서치, 코딩, 투자 분석, 운영 업무에서도 같은 방식의 팀형 에이전트 구조가 충분히 효과적인가?