AI에게 회사 권한을 전부 줘도 괜찮을까

📋 오늘의 3줄 요약

• Vercel이 AI 에이전트가 회사 도구에 접근하는 방식을 바꾸는 Vercel Connect를 공개했어요.
• 오래 저장한 만능 토큰 대신, 작업마다 짧고 좁은 권한을 주는 쪽으로 가고 있어요.
• 사내 AI 자동화를 만들고 있다면 API 키부터 업무별 권한으로 쪼개야 해요.

안녕하세요, 오늘은 모델 성능보다 더 현실적인 질문을 보려고 해요. AI에게 회사 계정을 어디까지 열어줘야 할까요?

📌 오늘의 딥다이브 — Vercel Connect가 던진 AI 업무 권한 문제

무슨 일이 있었나

Vercel이 Vercel Connect를 공개 베타로 내놨어요. 에이전트가 Slack, GitHub 같은 외부 도구를 쓸 때, 예전처럼 환경 변수에 오래 사는 토큰을 넣어두지 말자는 제안입니다. 대신 앱이 작업할 때마다 Vercel Connect에 자기 신원을 증명하고, 그 작업에 필요한 짧은 권한만 받아오는 구조예요. 출처

이게 왜 중요하냐면요. AI 에이전트는 답변만 하는 챗봇이 아니잖아요. 이슈를 읽고, PR을 만들고, 고객 정보를 조회하고, Slack에 메시지를 보내고, Salesforce나 Linear 같은 업무 시스템까지 만질 수 있어야 진짜 쓸모가 생깁니다. 그런데 그 순간부터 문제는 모델이 아니라 권한이에요.

Vercel은 지금 많은 에이전트가 장기 provider token을 환경 변수에 넣어 쓰고 있다고 봅니다. 이 토큰은 모든 사용자에게 공유되고, 만료되지 않고, 작은 작업에도 너무 넓은 접근권을 갖기 쉽다는 거예요. 금고에 넣으면 훔치기 어려워질 수는 있습니다. 하지만 새면 여전히 위험합니다. 닿을 수 있는 모든 시스템이 같이 열리거든요. 출처

왜 지금인가

AI 도입이 "좋은 답변을 만든다"에서 "업무를 대신 처리한다"로 넘어가고 있어요. The Rundown도 최근 AI 가이드를 직무별로 나누고 있습니다. 마케팅, 세일즈, 디자인, 데이터 분석, 재무, 정부, 헬스케어, 법무, HR, 비즈니스 운영 같은 카테고리를 전면에 내세워요. 즉 AI의 전장은 모델 데모가 아니라 실제 업무 프로세스입니다. 출처

이 흐름은 국내 사례에서도 보여요. 카카오테크는 카카오톡 추천 지표 분석을 AI 에이전트로 자동화하는 사례를 공유했습니다. 추천 시스템을 운영하다 보면 "이번 주 CTR이 왜 떨어졌지?", "실험군 반응은 어땠지?", "배포 이후 특정 사용자군에서 달라진 점은 없을까?" 같은 질문이 계속 나온다는 설명이에요. 이런 질문은 답만 잘해서는 부족합니다. 데이터와 로그에 접근해야 해요. 출처

상상해 보세요. 추천 지표를 분석하는 에이전트가 Hadoop 데이터, 실험 로그, 사용자 세그먼트, 배포 기록을 볼 수 있습니다. 편하죠. 그런데 그 에이전트가 모든 테이블을 읽고, 모든 채널에 메시지를 보내고, 모든 저장소에 push할 수 있다면요? 그건 자동화가 아니라 운영 리스크입니다.

디테일

Vercel Connect의 핵심은 connector입니다. Slack이나 GitHub 같은 provider와 Vercel team 사이의 연결을 한 번 만들고, 프로젝트와 환경에 붙여서 재사용합니다. 중요한 건 그 연결을 프로젝트 단위 접근 제어로 관리한다는 점이에요. 토큰이 여러 환경 변수 패널에 흩어지는 대신, 하나의 관계로 보고 관리하는 구조입니다. 출처

그 다음이 runtime credential exchange입니다. 쉽게 말해, 에이전트가 일을 시작할 때마다 "나는 이 앱이고, 이 작업을 하려 한다"고 증명합니다. 그러면 Vercel Connect가 짧게 사는 credential(자격 증명)을 돌려줘요. 이 credential은 작업 범위에 맞게 제한됩니다. 에이전트가 모든 권한을 계속 쥐고 있는 게 아니라, 필요할 때 필요한 만큼 빌려 쓰는 방식입니다. 출처

Vercel의 Enterprise Apps and Agents 발표도 같은 방향이에요. 사내 앱과 에이전트를 안전하게 배포하려면 네 가지 질문에 답해야 한다고 봅니다. 누가 각 에이전트를 쓸 수 있는가. 내부 에이전트를 어떻게 내부에만 두는가. 어떤 데이터와 시스템을 만질 수 있는가. 어떤 모델을 쓰고 비용은 얼마나 나는가. 출처

구성요소도 명확합니다. Vercel Passport는 내부 앱과 에이전트를 identity provider 뒤에 둡니다. Vercel Connect는 Slack, GitHub, Snowflake, Salesforce, Linear 같은 시스템에 짧고 범위 제한된 credential을 줍니다. Enterprise Managed Users는 사용자 생명주기를 디렉터리와 연결합니다. Bring your own cloud on AWS는 앱과 에이전트를 자기 AWS 계정 안에서 돌리는 방향입니다. 출처

왜 중요한가

한국 빌더에게 이건 꽤 바로 오는 문제예요. 고객사에 AI 기능을 팔 때 "어떤 모델 쓰나요?"만 묻지 않습니다. "우리 데이터가 어디로 가나요?", "권한은 누가 관리하나요?", "퇴사자 계정은 자동으로 막히나요?", "감사 로그가 남나요?", "AI가 잘못 실행하면 누가 승인하나요?"를 물어요.

특히 B2B SaaS나 내부툴을 만드는 팀이라면, AI 에이전트가 고객사 업무 시스템에 붙는 순간 보안 질문지가 길어집니다. 그냥 `.env`에 `GITHUB_TOKEN` 하나 넣고 "우리 에이전트가 PR 만들어줘요"라고 말하기 어렵습니다. 고객 입장에서는 그 토큰이 어떤 저장소까지 접근하는지, 어느 사용자의 권한으로 움직이는지, 언제 만료되는지 알아야 하거든요.

정리하면 이렇습니다. AI 자동화의 다음 경쟁력은 더 똑똑한 프롬프트가 아닐 수 있어요. 권한을 작게 나누고, 짧게 빌려주고, 기록을 남기는 설계입니다. 모델은 바뀌어도 이 구조는 남습니다.

다음 전개

앞으로 에이전트 플랫폼은 세 가지를 기본값으로 만들 가능성이 큽니다. 첫째, 사용자별 권한입니다. 둘째, 작업별 scope(허용 범위)입니다. 셋째, 실행 전후 감사 로그입니다. 이 셋이 없으면 사내 자동화는 데모에서 멈춥니다.

Vercel Sandbox가 최대 24시간 실행을 지원하게 된 것도 같은 흐름에서 볼 수 있어요. 긴 E2E 테스트, 대규모 데이터 처리, 장시간 에이전트 워크플로를 돌리려면 실행 시간만 늘리는 것으로 끝나지 않습니다. 오래 도는 에이전트일수록 중간 취소, 권한 만료, 상태 유지, 실패 복구가 필요해집니다. 출처

그래서 오늘의 질문은 이겁니다. "어떤 AI 모델을 붙일까?"보다 먼저, "이 AI에게 회사 권한을 어디까지 줄까?"를 정해야 합니다. 제품에 들어가는 순간 이 질문이 비용보다 먼저 옵니다.

⚡ 빠른 소식

• GLM-5.2 공개 — Z.AI가 100만 토큰 문맥과 긴 코딩 작업 성능을 앞세운 GLM-5.2를 공개했고, MIT 오픈소스 라이선스를 강조했어요. 출처
• GLM 5.2, Vercel AI Gateway 지원 — Vercel AI Gateway에서 `zai/glm-5.2` 모델을 사용할 수 있게 됐고, 사용량·비용 추적과 API 키별 예산 기능도 함께 안내됐어요. 출처
• AWS Strands Robots와 LeRobot 연결 — Hugging Face 블로그에 AWS Strands Robots가 LeRobot 데이터셋, 시뮬레이션, 실제 SO-101 하드웨어 배포를 하나의 에이전트 루프로 묶는 예제가 올라왔어요. 출처
• OpenAI, 배포 전 행동 예측 방법 소개 — OpenAI가 실제 대화 데이터를 활용해 배포 전 모델 행동을 예측하는 Deployment Simulation을 소개했어요. 출처
• 카카오의 바이브 코딩 회고 — 카카오테크는 비개발자가 AI 에이전트와 함께 내부 도구를 만들고 실제 업무에 쓰면서 관심사가 다음 단계로 넘어간 경험을 정리했어요. 출처
• 구글 DeepMind, 영국 주택 계획 AI 프로토타입 — 영국 정부와 Google DeepMind가 주택 관련 의사결정을 더 빠르게 하기 위한 AI 기반 프로토타입을 만든다고 밝혔어요. 출처

🇰🇷 빌더 포인트 — 그래서 오늘 뭘 해야 하나

1. AI가 쓰는 API 키 목록부터 뽑으세요. GitHub, Slack, Notion, Linear, Salesforce, DB read 계정처럼 에이전트가 만지는 모든 credential을 표로 정리하세요. 그리고 "누구 권한인가", "언제 만료되나", "어디까지 접근하나" 세 칸을 채우세요.

1. 업무별 scope를 먼저 설계하세요. 고객 지원 에이전트는 티켓 읽기와 답변 초안 작성까지만, 개발 에이전트는 특정 저장소의 branch 생성까지만, 분석 에이전트는 익명화된 집계 테이블 읽기까지만 허용하는 식으로 자르세요. 만능 토큰 하나로 시작하면 나중에 쪼개기 어렵습니다.

1. 고객사 보안 질문지 답변을 제품 요구사항으로 바꾸세요. "감사 로그가 남나요?", "퇴사자 권한은 회수되나요?", "AI 실행 전 승인 단계가 있나요?" 같은 질문을 미리 문서화하세요. 이 답을 못 하면 엔터프라이즈 판매는 모델 성능과 상관없이 막힙니다.

오늘의 한 줄: AI에게 일을 맡기려면 먼저 회사 열쇠를 잘게 쪼개야 한다.

—
Korean AI Builder Brief · 매일 아침 한국 AI 빌더에게