박스 공식 계정이 8월 28일 글 하나를 걸었습니다. 「Box Tutorial: Creating a company brain with Box and the Hermes Agent」라는 튜토리얼입니다. 조회 182,037을 기록했어요.
쓴 사람은 박스 데브렐 소속 크리스 킴입니다. 형식은 흔한 튜토리얼이에요. 그런데 첫 문단이 제품 설명이 아니라 명제로 시작합니다.
"AI 에이전트에게는 기업 콘텐츠를 안전하게 열고, 작업하고, 저장할 파일시스템이 필요하다."
에이전트에게 왜 파일시스템이 필요할까요?
지금까지 에이전트에게 회사 문서를 물리는 방법은 대개 하나였어요. 필요한 파일을 골라 내려받고, 잘라서 넣어주고, 결과를 사람이 다시 붙여넣는 겁니다.
이 방식에는 구멍이 하나 있습니다. 파일이 저장소를 떠나는 순간 권한이 벗겨진다는 점이에요. 원래 문서에 걸려 있던 열람 제한, 부서 경계, 만료 정책이 복사본에는 따라붙지 않습니다.
박스가 내놓은 답은 파일을 꺼내오지 않는 쪽입니다. 에이전트가 저장소 안에서 일하게 만들고, 저장소가 원래 갖고 있던 통제를 그대로 적용하는 구조예요.
회사 문서함은 어떻게 두뇌가 됩니까?
튜토리얼은 박스를 "거버넌스가 걸린 콘텐츠 층"이라고 부릅니다. 그 층이 조직 콘텐츠를 에이전트용 컴퍼니 브레인으로 바꾼다는 표현이 본문에 그대로 나옵니다.
원문은 이렇게 적었습니다.
"박스는 거버넌스가 걸린 콘텐츠 층을 제공하고, 기존 권한과 접근 통제를 보존한 채 조직 콘텐츠를 에이전트용 컴퍼니 브레인으로 바꾼다."
핵심은 뒤에 붙은 단서입니다. 기존 권한과 접근 통제를 보존한 채로 바꾼다는 조건이에요.
풀어 쓰면 이렇습니다. 재무팀 문서를 못 보는 계정으로 봇을 돌리면, 봇도 그 문서를 못 봅니다. 봇에게 권한을 새로 발급하는 게 아니라, 봇을 사람 자격 아래에 세워두는 방식입니다.
두뇌라는 말이 붙은 자리가 여기예요. 문서 저장소가 검색 대상에서 작업 공간으로 옮겨 앉았습니다.
스킬은 어떻게 일을 넘깁니까?
박스는 누스 리서치와 손을 잡았습니다. 그 결과로 공식 박스 스킬이 헤르메스 에이전트 신규 설치본에 기본 포함됩니다.
튜토리얼에서 가장 무거운 대목이 이 문장입니다. 사용자가 찾아서 붙이는 확장이 아니라, 깔면 이미 들어 있는 기본값이라는 뜻이거든요. 도입 장벽이 설치 시점으로 당겨졌습니다.
스킬 자체는 얇습니다. 들어온 작업을 세 갈래로 넘길 뿐이에요.
간단한 조회는 CLI로, 정형화된 호출은 box request로, 복잡한 작업은 공식 SDK로 갑니다.
에이전트가 API 문법을 외우지 않아도 되는 구조입니다. 어디로 보낼지 판단하는 층을 스킬이 대신 갖고 있습니다.
갱신 브리핑 한 장은 몇 단계로 나옵니까?
튜토리얼은 계약 갱신 담당자를 세워둡니다. 가상 회사 노스스타 시스템즈, 다음 분기 갱신을 앞둔 고객사 상황을 정리해야 하는 자리예요.
작업은 여섯 단계로 흘러갑니다.
먼저 폴더를 만들고 관련 문서를 모아요. 계약서, 지원 티켓, 통화 기록 같은 문서 8건이 들어갑니다. 튜토리얼용으로 만든 가상 문서예요.
다음이 고객 360 허브 구성입니다. 허브는 봇이 바라볼 범위를 확정하는 울타리 역할을 합니다. 봇은 허브 바깥을 보지 않습니다.
셋째로 봇을 만들고 허브에 붙입니다. 넷째가 검증이에요. 질문을 던져 답이 실제 문서에 근거하는지 확인합니다.
다섯째로 인용이 달린 갱신 브리핑을 뽑습니다. 논의점 5개가 항목으로 정리돼 나와요. 마지막으로 그 결과를 박스 노트로 저장해 원래 저장소에 되돌립니다.
여기서 눈여겨볼 대목이 하나 있습니다. 박스 AI가 승인된 허브 콘텐츠를 저장소 안에서 분석한다는 점이에요. 헤르메스가 원문을 따로 내려받아 처리할 필요가 없습니다. 문서는 한 번도 울타리 밖으로 나가지 않습니다.
봇이 잘못 써넣으면 누가 잡습니까?
쓰기 권한이 붙는 순간 질문이 달라집니다. 읽기만 하는 봇은 틀려도 오답으로 끝나지만, 쓰는 봇은 틀리면 흔적을 남기니까요.
스킬은 두 가지 장치를 걸어뒀습니다.
첫째, 쓰기 작업 뒤에 스스로 확인합니다. 같은 사용자 자격으로 다시 조회해서 반영 여부를 검증하는 방식이에요. 봇이 "저장했습니다"라고 보고하고 끝내지 못하게 막는 장치입니다.
둘째, 권한 변경이나 파괴적 작업은 실행 전에 사람에게 묻습니다. 삭제와 공유 설정 변경이 자동 실행 대상에서 빠져 있다는 뜻이에요.
두 장치 모두 화려하지 않습니다. 다만 사내 문서를 다루는 봇에 붙일 최소 조건이 무엇인지는 분명하게 보여줍니다.
이 패턴은 어디까지 늘어납니까?
튜토리얼은 갱신 브리핑 하나로 끝내지 않고 확장 방향을 열거합니다.
사내 정책 문답이 첫째입니다. 규정 문서를 허브로 묶어두고 직원 질문을 받는 구조예요. 둘째는 메타데이터 추출입니다. 들어오는 문서에서 금액과 기한 같은 항목을 뽑아 필드로 채웁니다. 셋째가 계약 비교입니다. 조항 차이를 짚어 표로 만드는 작업이에요.
세 가지 모두 같은 뼈대를 씁니다. 허브로 범위를 자르고, 봇을 붙이고, 결과를 다시 저장소에 넣는 순서입니다. 바뀌는 건 서랍 위치뿐이에요.
튜토리얼은 시작 경로도 짧게 정리해뒀습니다. 헤르메스를 설치하고, 공개된 스킬 소스를 들여다보고, 박스 커넥트 튜토리얼로 연결을 잡으라는 세 줄이에요. 문서 하나로 따라 할 수 있는 분량으로 끊어놓은 셈입니다.
남는 생각
저는 이 발표를 기능 발표가 아니라 서랍 문제로 읽습니다.
스킬 설치는 한 줄로 끝납니다. 헤르메스를 새로 깔면 그마저도 필요 없어요. 반면 어느 폴더까지 봇에게 보일지, 어느 허브에 묶을지는 여전히 사람이 정합니다. 자동화되지 않는 유일한 결정이 거기 남았습니다.
권한 설계가 곧 에이전트 설계가 됐습니다. 모델을 고르는 일보다 서랍을 고르는 일이 먼저 온다는 뜻이에요.
회사에서 이 구조를 검토한다면 순서는 이렇습니다. 봇을 어떤 계정 자격으로 세울지 먼저 정하고, 그 계정이 볼 수 있는 범위를 허브로 좁히고, 쓰기 권한은 마지막에 붙입니다. 열어주는 건 언제든 할 수 있지만, 이미 읽힌 문서는 되돌릴 방법이 없습니다.
원문·소스
- 박스 공식 계정 튜토리얼(@Box): https://x.com/Box/status/2093454212986556683 (조회 182,037, 북마크 489)
FAQ
자주 묻는 질문
- 에이전트에게 왜 파일시스템이 필요할까요?
- 지금까지는 파일을 골라 내려받고, 잘라서 넣어주고, 결과를 사람이 다시 붙여넣는 방식이 대부분이었습니다. 파일이 저장소를 떠나는 순간 열람 제한과 부서 경계와 만료 정책이 복사본에 따라붙지 않습니다. 박스가 내놓은 답은 파일을 꺼내오지 않는 쪽입니다.
- 회사 문서함은 어떻게 두뇌가 됩니까?
- 튜토리얼은 박스를 거버넌스가 걸린 콘텐츠 층이라고 부릅니다. 그 층이 기존 권한과 접근 통제를 보존한 채 조직 콘텐츠를 에이전트용 컴퍼니 브레인으로 바꾼다고 적었습니다. 재무팀 문서를 못 보는 계정으로 봇을 돌리면 봇도 그 문서를 못 봅니다.
- 스킬은 어떻게 일을 넘깁니까?
- 박스가 누스 리서치와 손을 잡으면서 공식 박스 스킬이 헤르메스 에이전트 신규 설치본에 기본 포함됩니다. 스킬 자체는 들어온 작업을 세 갈래로 넘길 뿐입니다. 간단한 조회는 CLI로, 정형화된 호출은 box request로, 복잡한 작업은 공식 SDK로 갑니다.
- 갱신 브리핑 한 장은 몇 단계로 나옵니까?
- 폴더 생성, 고객 360 허브 구성, 봇 연결, 검증, 브리핑 생성, 박스 노트 저장까지 여섯 단계입니다. 계약서와 지원 티켓과 통화 기록 같은 가상 문서 8건이 폴더에 들어가고, 마지막에 논의점 5개가 항목으로 정리돼 나옵니다.
- 봇이 잘못 써넣으면 누가 잡습니까?
- 스킬에 장치가 두 가지 걸려 있습니다. 쓰기 작업 뒤에 같은 사용자 자격으로 다시 조회해 반영 여부를 검증하고, 권한 변경이나 파괴적 작업은 실행 전에 사람에게 묻습니다. 삭제와 공유 설정 변경이 자동 실행 대상에서 빠졌다는 뜻입니다.
- 이 패턴은 어디까지 늘어납니까?
- 튜토리얼이 열거한 확장 방향은 사내 정책 문답, 메타데이터 추출, 계약 비교 셋입니다. 셋 다 허브로 범위를 자르고, 봇을 붙이고, 결과를 다시 저장소에 넣는 같은 뼈대를 씁니다. 바뀌는 건 서랍 위치뿐이에요.