---
author: OOMOL
author_url: https://oomol.com/ko/about/
datePublished: 2026-09-23
title: "Meta Muse에서 Leina까지: 나를 이해하는 AI 비서에게 필요한 연결"
description: 개인과 기업의 AI 비서가 여러 앱의 맥락을 필요로 하는 이유와 OOMOL 및 오픈 소스 OpenConnector가
  제공하는 계정 연결, 권한 부여, 앱 작업 기반을 살펴봅니다.
lang: ko
canonical_url: https://oomol.com/ko/blog/meta-muse-ai-assistant-oomol/
markdown_url: https://oomol.com/ko/blog/meta-muse-ai-assistant-oomol.md
---

![개인 생활과 기업 업무의 맥락을 연결 계층을 통해 기억과 행동으로 이어 주는 AI 비서](/img/blog/meta-muse-ai-assistant-oomol/ko-cover.webp)

나를 정말 잘 아는 비서라면 무엇을 알고 있어야 할까요?

다음 주에 출장을 간다는 사실, 통로 쪽 좌석을 선호한다는 것, 고객 미팅 시간이 방금 바뀌었다는 것을 알고 있을 겁니다. 저녁 모임을 부탁하면 친구들의 식이 제한, 모두가 가능한 시간, Instagram에 저장해 둔 식당까지 고려하겠죠.

이 정보는 이미 존재합니다. 다만 채팅, 이메일, 캘린더, 저장한 항목, 업무 시스템에 흩어져 있습니다. 우리는 매번 이를 찾아 복사하고 다시 설명합니다.

**Muse 같은 제품이 필요한 이유입니다. 사람들은 자신의 상황을 이해하고, 전달한 내용을 기억하며, 후속 업무까지 이어 가는 비서를 원합니다.**

Meta는 2026년 9월 8일 개인용 AI 에이전트 Muse를 발표했습니다. [공식 소개](https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/)에 따르면 Muse는 자체 클라우드 컴퓨팅 환경에서 브라우저를 사용하고, 작업을 처리하고, 사용자 선호를 기억하며, 앱을 닫은 뒤에도 계속 일할 수 있습니다. 사용자는 Muse 앱이나 WhatsApp에서 대화하고, 어떤 앱에 어떤 권한을 부여할지 결정합니다.

이런 경험이 개인 생활과 기업 업무로 확장되면 공통된 기반이 필요합니다. **AI가 허가된 범위 안에서 사람들이 이미 쓰는 시스템에 지속적으로 접근할 수 있어야 합니다.** OOMOL의 연결 게이트웨이가 맡는 역할입니다.

## AI 비서가 나를 알아야 하는 이유

두 가지 요청을 비교해 보겠습니다.

“출장 준비 체크리스트를 작성해 줘.”

“다음 주 고객 미팅에 맞춰 이번 출장을 준비해 줘.”

두 번째 요청에는 구체적인 정보가 필요합니다. 미팅 장소와 시작 시간, 고객이 보낸 자료, 일정 충돌 여부, 교통편과 숙박 선호가 있어야 합니다. 비서는 최신 캘린더를 확인하고, 이메일을 검색하고, 관련 문서를 읽은 뒤, 허가받은 다음 작업을 진행해야 합니다.

Meta의 Muse 디자인 글에는 일상적인 사례가 나옵니다. 자녀의 새 학기와 관련된 학교 이메일과 웹사이트 정보를 정리하고, 주요 날짜를 가족 캘린더에 추가하고, 준비물을 챙기는 일을 돕습니다. 흩어진 정보를 완료 가능한 일로 묶는 능력이 가치를 만듭니다. [제품 디자인 소개](https://introducing.muse.ai/)

개인의 생활은 여러 앱에 걸쳐 있습니다. Facebook, Instagram, WhatsApp에는 관계와 관심사, 대화가 있고, Gmail, Google Calendar, Google Drive에는 이메일과 일정, 파일이 있습니다. 쇼핑, 여행, 결제 등 다른 서비스도 맥락의 일부를 가지고 있습니다.

사용자는 소프트웨어의 경계에 맞춰 생각하지 않습니다. 그냥 “주말 일정을 정리해 줘”라고 말합니다.

**유용한 비서는 사람의 목표를 중심으로 여러 앱의 정보를 정리해야 합니다.** 실제로 읽거나 실행할 수 있는 범위는 각 플랫폼의 API, 계정 유형, 사용자가 부여한 권한에 따라 달라집니다.

## 기업에서도 필요하지만, 맥락은 더 복잡합니다

직장에서는 “나를 이해해 줘”가 “우리 사업을 이해해 줘”로 확장됩니다.

영업 담당자가 “내일 고객 미팅을 준비해 줘”라고 요청하면 CRM의 후속 대응 기록, 이메일로 받은 최신 요구사항, ERP의 주문 및 납품 상태, 지식 베이스의 제품 자료가 필요할 수 있습니다.

운영 책임자가 “다음 달에 어떤 제품을 홍보할지 살펴봐 줘”라고 요청하면 시장 조사, 고객 의견, 재고, 과거 매출을 함께 검토해야 해당 기업에 맞는 제안을 할 수 있습니다.

| 비서가 이해해야 할 내용 | 정보가 있는 곳 | 지원할 수 있는 업무 |
| --- | --- | --- |
| 개인 일정과 선호 | 이메일, 캘린더, 채팅, 저장 항목 | 출장 준비, 정보 정리, 후속 알림 |
| 고객의 상황 | CRM, 이메일, 고객 지원 및 팀 메시지 | 미팅 준비, 위험 검토, 후속 연락 초안 |
| 사업상 약속할 수 있는 범위 | ERP, 주문, 재고, 업무 데이터베이스 | 납품 확인, 이상 원인 조사, 재고 보충 분석 |
| 팀의 업무 방식 | 지식 베이스, 공유 문서, 프로젝트 기록 | 근거 검색, 방법 재사용, 인수인계 자료 |
| 외부 시장의 변화 | 검색, 조사 도구, 산업 및 소셜 데이터 | 경쟁사 관찰, 수요 조사, 기회 요약 |

위 내용은 작업 예시입니다. 실제 구현에서는 필요한 연결, 권한, 사용 가능한 작업을 각각 확인해야 합니다.

기업에는 한 가지 요구가 더 있습니다. 같은 회사의 구성원이라도 접근할 수 있는 정보와 실행할 수 있는 작업이 다릅니다. 담당 고객을 볼 수 있다고 모든 재무 데이터에 접근할 수 있는 것은 아닙니다. 주문을 읽을 수 있어도 가격을 바꿀 권한까지 있는 것은 아닙니다.

기업용 비서는 업무 맥락, 지속적인 기억, 접근 권한을 함께 다뤄야 합니다.

## Leina: 팀이 평소 일하는 곳에서 업무를 받는 AI

[Leina](https://leina.ai/)는 이 개념을 팀 채팅에 적용합니다. 동료들이 업무를 논의하고 정보를 공유하는 곳에 도구를 사용할 수 있는 AI 직원이 합류합니다.

공식 사이트는 지속적인 업무에 필요한 몇 가지 특징을 소개합니다.

**익숙한 채팅 채널에서 업무를 맡깁니다.** 사이트에는 Feishu, WeCom, DingTalk, Slack, Teams, Discord가 나와 있습니다. 채널을 연결하면 구성원은 채팅에서 요청하고, 비서는 작업에 필요한 연결된 앱을 호출합니다.

**배경을 저장하고 이전 작업을 이어 갑니다.** Leina는 Memory에 팀의 습관과 프로젝트 배경을 저장합니다. 그룹 채팅과 개인 대화는 별도의 작업 맥락을 가집니다. 오래 걸리는 작업과 예약 작업은 백그라운드에서 계속 실행하고 완료 후 결과를 알려 줄 수 있습니다.

**검증한 방법을 재사용 가능한 Skill로 만듭니다.** 작업 단계, 필요한 앱, 확인 항목을 Skill로 정리하면 팀이 비슷한 업무에서 재사용하고 개선할 수 있습니다.

**조직과 구성원의 권한에 따라 계정을 사용합니다.** 관리자가 업무 계정을 연결하고 작업 범위를 설정합니다. 구성원은 비밀번호나 원본 토큰을 받지 않고도 허가된 기능을 사용할 수 있습니다.

예를 들어 다음 요청을 바탕으로 업무 흐름을 설계할 수 있습니다.

> @Leina, 이번 주 고객 의견을 정리하고 고객 기록과 납품 상황을 확인해 줘. 후속 대응이 필요한 문제를 목록으로 만들어서 우선 초안으로 보여 줘.

여러 시스템을 조회하고, 팀의 우선순위를 이해하고, 접근 범위를 지켜야 하는 작업입니다. 채팅은 요청 창구, 기억은 배경 정보, Skill은 작업 방법, 연결 계층은 도구에 접근하는 경로를 제공합니다.

![채팅으로 요청을 받고 Memory로 배경을 보완하며 Skill로 단계를 정리하고 연결 계층으로 허가된 시스템을 호출한 뒤 결과를 전달하는 다섯 단계](/img/blog/meta-muse-ai-assistant-oomol/ko-workflow.webp)

*여러 시스템을 사용하는 팀 비서의 개념 흐름입니다. 제품 화면이나 실제 실행 기록이 아닙니다.*

## OOMOL: 비서와 실제 시스템을 연결하는 게이트웨이

이런 비서를 개발하면 반복적으로 마주치는 질문이 있습니다.

플랫폼마다 접근 권한을 어떻게 받아야 할까요? 토큰이 만료되면 어떻게 처리할까요? 사용자가 두 개의 메일 계정을 연결했다면 이번에는 어느 계정을 써야 할까요? 해당 작업에는 무슨 권한이 필요할까요? 호출이 실패하면 실행 기록은 어디에서 찾을까요?

앱 수가 늘어나면 이 문제들은 지속적인 유지보수 업무가 됩니다.

**OOMOL은 계정 연결, 권한 부여, 자격 증명 관리, 구체적인 앱 작업을 재사용 가능한 연결 기반으로 구성합니다.** 에이전트나 제품 백엔드는 일관된 호출 방식으로 허가된 서비스에 접근하고, 작업 이해와 기억, 사용자 경험에 더 집중할 수 있습니다.

### 다양한 연결로 작업에 필요한 맥락을 확보합니다

2026년 9월 23일 기준 OOMOL의 [공개 카탈로그 API](https://connector.oomol.com/v1/catalog)에는 **서비스 1,559개와 작업 18,035개**가 등록되어 있습니다. 카탈로그 규모를 나타내는 수치이며, 개별 작업에서는 대상 서비스, 작업 구현, 권한 조건을 확인해야 합니다.

이메일, 문서, 고객 기록, 분석 도구, 업무 시스템을 오가는 작업에서 개발자가 필요한 접근 기능을 찾을 수 있어야 합니다.

작업의 깊이도 중요합니다. 기록 검색, 상세 조회, 콘텐츠 생성, 허가에 따른 데이터 갱신 중 어디까지 지원하는지가 비서가 진행할 수 있는 범위를 결정합니다.

### 권한과 자격 증명을 관리해 연결을 유지합니다

OOMOL 호스팅 연결에서는 게이트웨이가 서비스 자격 증명을 보관하고 실제 호출을 실행합니다. 애플리케이션 코드는 연결 식별자로 계정을 선택하므로 각 제공자의 원본 토큰을 직접 보관할 필요가 없습니다. [SDK 문서](/ko/docs/connector-sdk/)

여러 사용자를 위한 비서에는 `ProjectConnector`를 통해 최종 사용자별 계정 연결을 제공할 수 있습니다. 사용자가 자신의 서비스에 권한을 부여하면 제품 백엔드가 올바른 계정을 선택해 작업을 실행합니다. [SaaS 연동 가이드](/ko/docs/connector-saas/)

### 명확한 작업 정의와 실행 기록으로 연결을 관리합니다

OpenConnector는 입출력 스키마, 필요한 권한, 연결 계정의 식별 정보, 작업 허용·차단 정책, 민감 정보가 가려진 실행 로그를 제공합니다. 개발자는 허용 범위를 확인하고 실패한 호출을 추적할 수 있습니다.

이러한 통제는 비서 제품 자체의 사용자 식별, 작업 확인, 업무 승인과 함께 적용합니다. 예를 들어 고객에게 보낼 초안을 작성하는 일과 실제로 보내는 일에는 제품 설계에 따른 실행 절차가 각각 필요합니다.

![Leina 또는 자체 비서가 OOMOL이나 OpenConnector를 통해 이메일, CRM, ERP, 지식 시스템에 접근하는 구조](/img/blog/meta-muse-ai-assistant-oomol/ko-gateway.webp)

*비서 아키텍처에서 OOMOL의 위치를 나타냅니다. 시스템 분류는 일반적인 요구를 보여 주며, 실제 지원은 현재 카탈로그와 API 권한에 따라 달라집니다.*

## OpenConnector: 연결 기반도 직접 관리할 수 있어야 합니다

비서가 업무에 깊이 참여할수록 팀은 자격 증명 보관 위치, 연결 서비스 실행 환경, 동작을 조사하고 제한할 수 있는 주체에 관심을 갖게 됩니다.

OOMOL은 호스팅 연결 서비스와 함께 오픈 소스 [OpenConnector](https://openconnector.io/)를 통한 자체 배포 경로를 제공합니다. 도입 속도와 운영 요구에 맞춰 선택할 수 있습니다.

| 경로 | 적합한 팀 |
| --- | --- |
| OOMOL 호스팅 | 앱을 빠르게 연결하고 호스팅 연결 및 자격 증명 계층 운영을 OOMOL에 맡기려는 팀 |
| Cloudflare에 OpenConnector 배포 | 자체 Cloudflare 환경에서 연결 서비스를 실행하려는 팀 |
| OpenConnector 자체 호스팅 | 자체 환경에서 런타임, 자격 증명, 정책, 실행 기록을 관리하려는 팀 |

공개 범위에는 연결 런타임, 서비스 정의, 작업 스키마, 해당 구현이 있는 로컬 실행 코드가 포함됩니다. 타사 서비스 자체와 API 사용 조건은 각 플랫폼이 정합니다. [자체 호스팅 가이드](/ko/docs/openconnector-self-hosting/)

2026년 9월 23일 기준 [GitHub 저장소](https://github.com/oomol-lab/open-connector)는 **Stars 5,873개와 Forks 512개**를 기록했습니다. 이는 커뮤니티의 관심과 파생 개발 활동을 보여 줍니다. 기반 기술을 선택하는 팀에게 더 직접적인 가치는 구현과 작업 계약을 검토하고, 필요할 때 직접 배포하고 유지보수할 수 있다는 점입니다.

## 다음 세대의 비서는 이해와 행동을 연결합니다

Muse는 중요한 내용을 기억하고, 백그라운드에서 작업을 진행하고, 사용자의 판단이 필요할 때 돌아와 확인하는 개인 비서의 방향을 보여 줍니다. Leina는 기억, Skills, 권한에 따른 앱 사용을 팀 채팅으로 가져와 지속적인 협업에 활용합니다.

이런 경험에는 작업을 이해하는 모델, 맥락을 유지하는 기억, 실제 시스템에 안정적으로 접근하는 경로가 필요합니다.

**개인이나 기업을 이해하려면 AI 비서가 그들이 사용하는 정보와 도구에 허가된 범위에서 접근할 수 있어야 합니다. OOMOL은 이를 위한 재사용 가능한 연결 게이트웨이를 제공합니다.**

팀의 구체적인 업무부터 시작하려면 [Leina를 사용해 보고](https://leina.ai/), 필요한 앱을 연결한 뒤, 검토할 수 있는 결과물 하나를 요청해 보세요.

자체 비서를 개발한다면 [OOMOL Connector SDK](/ko/docs/connector-sdk/)로 연동을 시작할 수 있습니다. 연결 런타임을 직접 관리하려면 [OpenConnector](https://github.com/oomol-lab/open-connector)를 살펴보세요.

---

*자료와 범위: Meta와 Leina의 공식 소개, OOMOL 문서, 2026년 9월 23일 조회한 카탈로그 및 GitHub 데이터를 바탕으로 작성했습니다. 제품을 독립적으로 실험하거나 검증하지는 않았습니다. Muse는 개인 AI 비서의 사례이며, Meta Muse가 OOMOL을 사용하거나 두 회사가 제휴했다는 뜻이 아닙니다. 이미지는 직접 제작한 개념도입니다.*