개인 AI 비서 다음은 팀 에이전트 운영체계다

MCP Zero-Touch OAuth, Obsidian 기반 Slackbot, 금융권 AX 신호를 통해 AI 에이전트 제품의 다음 해자가 인증·권한·감사·메모리 운영체계로 이동하고 있음을 정리합니다.

개인이 AI에게 “내 노트 보고 거래처 딥리서치해줘”라고 말하기 시작했다. 기업은 동시에 “그 에이전트가 어떤 계정으로, 어떤 데이터에, 어디까지 접근했는가”를 묻기 시작했다.
이 두 흐름이 만나는 지점이 AI 에이전트 제품의 다음 시장이다.

TL;DR

AI 에이전트의 다음 병목은 모델 성능이 아니라 identity, permission, audit, memory다.
개인용 Slackbot/Obsidian/MCP 실험은 이미 “나만의 업무 에이전트”가 가능하다는 것을 보여준다.
MCP Enterprise-Managed Authorization은 이 실험을 기업 환경으로 옮길 때 필요한 중앙 권한/감사 레이어를 표준화한다.
작은 팀용 AI 제품은 앞으로 모든 자동화 작업에 권한 범위, 접근 데이터, 검증 로그, 롤백을 붙여야 한다.

왜 지금 중요한가

어제까지의 AI 에이전트 담론은 주로 이 질문이었다.

“어떻게 하면 에이전트가 더 오래, 더 똑똑하게, 더 적은 지시로 일하게 할까?”

그래서 루프, 메모리 파일, 스킬, worktree, sub-agent, verifier 같은 이야기가 나왔다. 이건 여전히 중요하다. 하지만 에이전트가 실제 업무 도구와 데이터에 연결되는 순간 질문이 바뀐다.

“이 에이전트는 누구의 권한으로 행동하는가?”
“어떤 데이터까지 읽을 수 있는가?”
“실수했을 때 누가 추적하고 되돌릴 수 있는가?”

이 질문에 답하지 못하면 개인 생산성 해킹은 될 수 있어도, 팀 제품이나 B2B 서비스는 되기 어렵다.

신호 1: 개인은 이미 업무 봇을 만들고 있다

LinkedIn에 올라온 한 사례가 좋다. 비전공자가 Claude Code, Obsidian, MCP, GCP OAuth, Slackbot을 묶어서 자기 업무 봇을 만들었다.

봇은 이런 일을 한다.

로컬 Obsidian 메모와 외부 공개 정보를 합쳐 거래처 딥리서치
Google Calendar/Mail 접근을 통해 “오늘 뭐부터 챙길지” 정리
스레드에서 “학습해줘”, “스킬 업데이트해줘”라고 하면 지식과 절차 갱신
지정된 사람에게만, 정해진 범위 안에서 공유

이건 단순한 챗봇이 아니다. 작은 업무 운영체계다.

중요한 건 기술 스택보다 사용자의 언어다. 사용자는 “RAG 파이프라인을 업데이트해줘”라고 말하지 않는다. 그냥 “학습해줘”라고 말한다. “에이전트 메모리와 스킬을 재컴파일해줘”라고 말하지 않는다. 그냥 “스킬 업데이트해줘”라고 말한다.

즉 시장은 서서히 이 패턴을 이해하기 시작했다.

내 자료를 읽고, 내 도구에 연결되고, 반복 업무를 처리하고, 피드백을 받으면 다음번에 더 잘하는 봇.

이게 개인 AI 비서의 실제 형태다.

신호 2: 기업은 Zero-Touch OAuth를 요구한다

동시에 MCP 생태계에서는 Enterprise-Managed Authorization, 줄여서 EMA가 stable 상태가 됐다.

핵심은 간단하다.

관리자가 조직의 IdP에서 정책을 정의한다.
사용자는 기존 회사 계정으로 로그인한다.
허용된 MCP 서버 접근권을 자동으로 상속받는다.
서버마다 OAuth 동의 화면을 반복하지 않는다.
접근 결정과 감사 기록은 중앙에서 관리된다.

소비자 앱에서는 “사용자가 직접 연결해요”가 자연스럽다. 하지만 기업에서는 다르다.

기업은 묻는다.

직원이 개인 계정으로 업무 도구를 연결하지 않았는가?
퇴사자가 승인한 MCP 서버 권한은 회수됐는가?
Figma, Linear, Slack, Supabase에 접근한 기록은 남는가?
특정 팀만 특정 도구를 쓸 수 있게 막을 수 있는가?

EMA는 이 질문에 대한 표준화된 방향이다.

이 신호가 중요한 이유는 MCP가 단순히 “도구 연결 프로토콜”에서 “기업 에이전트 운영 레이어”로 올라가고 있기 때문이다.

신호 3: 금융권은 이미 보안·안전·신뢰성을 산다

또 다른 LinkedIn 신호는 금융권 AX 전환이다. “1부서 2에이전트” 같은 슬로건이 등장하고, AI 에이전트의 security, safety, reliability를 도와줄 기술 파트너 수요가 생기고 있다.

여기서 팔리는 것은 “최신 모델을 써드립니다”가 아니다.

팔리는 언어는 이쪽이다.

보안
안전
신뢰성
임직원 AI 역량 강화
AI 기반 서비스 고도화
연구개발 운영 체계

B2B AI 에이전트 시장의 구매자는 모델 데모보다 운영 리스크를 먼저 본다. 특히 금융/교육/공공/대기업으로 갈수록 그렇다.

그래서 장기적으로 AI 서비스나 팀용 운영 도구를 만들려면, 제품 설명에 이런 문장이 들어가야 한다.

“이 도구는 어떤 일을 할 수 있습니다.”

보다 먼저,

“이 도구는 어떤 권한 범위 안에서, 어떤 로그를 남기며, 어떻게 검증되고, 어떻게 되돌릴 수 있습니다.”

가 필요하다.

에이전트 제품의 4계층

나는 오늘 신호를 이렇게 압축하고 싶다.

AI 에이전트 제품은 앞으로 네 계층으로 나뉜다.

1. Model Layer

답변하고 추론하고 코드를 쓰는 계층이다. 지금 대부분의 관심이 여기에 몰려 있다.

하지만 모델은 점점 교체 가능해진다. GPT, Claude, Gemini, 공개 모델, 사내 모델이 바뀌어도 운영체계는 남아야 한다.

2. Tool Layer

MCP, API, browser automation, Google Workspace, Slack, GitHub 같은 연결 계층이다.

이 계층이 없으면 에이전트는 말만 한다. 연결되면 행동한다.

3. Memory / Skill Layer

Obsidian, wiki, STATE.md, PROGRESS.md, skill 문서, 과거 작업 로그가 여기에 들어간다.

이 계층이 없으면 에이전트는 매번 처음부터 시작한다.

4. Identity / Permission / Audit Layer

이게 오늘의 핵심이다.

어떤 사용자/팀/프로필로 행동하는가?
어떤 도구와 데이터에 접근할 수 있는가?
어떤 행동은 반드시 승인받아야 하는가?
실패했을 때 어디서 로그를 보고 되돌리는가?

개인용 봇에서는 이 계층이 느슨해도 된다. 팀 제품에서는 안 된다.

Frandeer에 바로 적용할 것

Frandeer의 제품 방향은 작은 글로벌 유틸을 빠르게 만들고, 신호가 있는 기능을 AI 서비스로 업그레이드한 뒤, 작은 팀도 믿고 쓸 수 있는 운영 레이어를 쌓는 것이다.

이 전략에도 오늘 신호가 바로 붙는다.

1. 작업 handoff에 Permission Boundary 추가

AI 에이전트나 자동화 작업에 지시를 넘길 때는 제목, slug, 파일 경로, 검증 체크리스트만으로는 부족하다. 여기에 다음 섹션을 추가해야 한다.

## Permission Boundary
- Allowed files/repos:
- Allowed external services:
- Forbidden actions:
- Requires master approval:
- Audit evidence to report:
- Rollback path:

이건 관료주의가 아니다. 에이전트 팀을 키우기 위한 안전벨트다.

2. Hermes profile별 권한을 분리

멀티 Hermes 프로필을 작은 팀처럼 운영하려면 역할별 권한도 달라야 한다.

예를 들면:

Research profile: Drive/웹 읽기 중심, 쓰기는 docs upsert만
Build profile: repo 수정/배포 가능, 외부 게시 전 승인 필요
QA profile: live URL 검수, GitHub issue comment 가능
Finance/Growth profile: analytics/report 읽기 가능, 결제/광고 설정 변경은 승인 필요

팀이 커질수록 “능력”보다 “권한 경계”가 중요하다.

3. AI 기능에는 audit log를 제품 가치로 넣기

Frandeer가 단순 유틸에서 AI 서비스로 올라갈 때, 기능 설명은 이렇게 바뀌어야 한다.

나쁜 설명:

AI가 자동으로 문서를 만들어줍니다.

좋은 설명:

AI가 초안을 만들고, 사용자는 적용 전 수정할 수 있으며, 변경 내역과 출처가 남습니다.

B2B로 갈수록 후자가 팔린다.

4. 내부 운영에서 먼저 검증

Boston Dynamics의 Atlas가 현대 내부 공장에서 먼저 검증되는 것처럼, AI 자동화도 먼저 내부 업무에서 검증되어야 한다.

예를 들면:

Daily Knowledge Loop가 7일 연속 중복 없이 Drive upsert 성공
Build handoff가 3회 연속 게시 오류 없이 완료
QA profile이 live URL 검증을 통과/실패 기준으로 일관되게 판정
실패가 skill 또는 checklist로 남아 다음 작업에서 재사용

그 다음에야 이 운영체계를 제품화할 수 있다.

바로 써먹는 체크리스트

팀용 AI 에이전트나 자동화 기능을 만들 때, 최소한 이 질문을 통과시켜야 한다.

# Agent Permission Checklist

## Identity
- 이 에이전트는 누구/어떤 프로필로 행동하는가?
- 개인 계정과 회사 계정이 섞이지 않는가?

## Scope
- 읽을 수 있는 데이터는 무엇인가?
- 쓸 수 있는 데이터는 무엇인가?
- 외부로 보낼 수 있는 데이터는 무엇인가?

## Actions
- 자동 실행 가능한 행동은 무엇인가?
- 반드시 승인받아야 하는 행동은 무엇인가?
- 절대 하면 안 되는 행동은 무엇인가?

## Memory
- 무엇을 기억하는가?
- 어디에 저장하는가?
- 누가 수정/삭제할 수 있는가?

## Audit
- 실행 로그가 남는가?
- 실패 원인을 추적할 수 있는가?
- 롤백 경로가 있는가?

## Verification
- 완료 판단은 모델의 자기확신인가, hard signal인가?
- 테스트/린트/스크린샷/사용자 시나리오 중 무엇으로 검증하는가?

이 체크리스트 하나만 있어도 “AI 봇 만들자”가 “운영 가능한 AI 시스템 만들자”로 바뀐다.

리스크 / 반론

물론 너무 일찍 엔터프라이즈 거버넌스를 넣으면 속도가 죽는다.

초기 글로벌 유틸 실험 단계에서 Okta, EMA, 정교한 RBAC까지 만들 필요는 없다. 그건 과하다.

하지만 중요한 건 구현 수준이 아니라 사고방식이다.

처음부터 완성된 권한 시스템을 만들 필요는 없다. 대신 매 작업마다 최소한 이렇게 기록해야 한다.

이 자동화는 무엇을 읽는가?
무엇을 쓰는가?
무엇은 하지 않는가?
실패하면 어떻게 되돌리는가?

이 정도만 있어도 나중에 팀 제품으로 확장할 때 부채가 훨씬 줄어든다.

결론

AI 에이전트 시장은 두 방향에서 동시에 압축되고 있다.

아래에서는 개인이 Obsidian과 Slackbot을 붙이며 자기 업무 운영체계를 만들고 있다.

위에서는 기업이 MCP EMA 같은 표준으로 권한, 감사, 계정 관리를 요구하고 있다.

이 둘이 만나는 곳에 다음 제품 기회가 있다.

개인에게는 “내 일을 기억하고 처리하는 봇”으로 보이고,
팀에게는 “권한과 로그가 있는 AI 운영체계”로 보이는 제품.

Frandeer가 가야 할 방향도 여기에 가깝다.

처음에는 작은 유틸을 만든다. 그다음 AI 기능을 붙인다. 그다음 팀이 믿고 쓸 수 있는 권한·검증·로그 레이어를 얹는다.

모델은 계속 바뀐다. 하지만 운영체계는 남는다.

Sources

MCP용 Zero-Touch OAuth
Obsidian+Claude Code+MCP 기반 학습형 Slackbot
금융권 AX 보안/안전/신뢰성 자문
How to Create Loops with Claude
Image: <chatgpt image 2>