회사 문서 8건을 허브로 묶자 봇이 저장소 안에서 브리핑을 썼습니다

박스 공식 계정이 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가 승인된 허브 콘텐츠를 저장소 안에서 분석한다는 점이에요. 헤르메스가 원문을 따로 내려받아 처리할 필요가 없습니다. 박스는 문서를 한 번도 울타리 밖으로 내보내지 않습니다.

봇이 잘못 써넣으면 누가 잡습니까?

봇에게 쓰기 권한을 주면 따져 볼 게 달라집니다. 읽기만 하는 봇은 틀려도 오답으로 끝나지만, 쓰는 봇은 틀리면 흔적을 남기니까요.

스킬은 두 가지 장치를 걸어뒀습니다.

첫째, 쓰기 작업 뒤에 스스로 확인합니다. 같은 사용자 자격으로 다시 조회해서 반영 여부를 검증하는 방식이에요. 봇이 "저장했습니다"라고 보고하고 끝내지 못하게 막는 장치입니다.

둘째, 권한 변경이나 파괴적 작업은 실행 전에 사람에게 묻습니다. 스킬은 삭제와 공유 설정 변경을 자동으로 실행하지 않아요.

두 장치 모두 화려하지 않습니다. 다만 사내 문서를 다루는 봇에 최소한 무엇이 필요한지는 이 두 장치로 분명히 알 수 있어요.

이 패턴은 어디까지 늘어납니까?

튜토리얼은 갱신 브리핑 하나로 끝내지 않고 확장 방향을 열거합니다.

사내 정책 문답이 첫째입니다. 규정 문서를 허브로 묶어두고 직원 질문을 받는 구조예요. 둘째는 메타데이터 추출입니다. 들어오는 문서에서 금액과 기한 같은 항목을 뽑아 필드로 채웁니다. 셋째가 계약 비교입니다. 조항 차이를 짚어 표로 만드는 작업이에요.

세 가지 모두 같은 뼈대를 씁니다. 허브로 범위를 자르고, 봇을 연결하고, 결과를 다시 저장소에 넣는 순서입니다. 서랍 위치만 바꾸면 돼요.

튜토리얼은 시작 경로도 짧게 정리해뒀습니다. 헤르메스를 설치하고, 공개된 스킬 소스를 읽어 보고, 박스 커넥트 튜토리얼로 연결을 잡으라는 세 줄이에요. 문서 하나로 따라 할 수 있는 분량으로 끊어놓은 셈입니다.

남는 생각

저는 이 발표를 서랍 문제로 읽습니다.

스킬 설치는 한 줄로 끝납니다. 헤르메스를 새로 깔면 그마저도 필요 없어요. 반면 어느 폴더까지 봇에게 보일지, 어느 허브에 묶을지는 여전히 사람이 정합니다. 사람이 직접 내려야 하는 결정은 그것 하나예요.

이제 권한을 설계하면 곧 에이전트를 설계하는 셈입니다. 모델을 고르기 전에 서랍부터 골라야 한다는 뜻이에요.

회사에서 이 구조를 검토한다면 순서는 이렇습니다. 봇을 어떤 계정 자격으로 세울지 먼저 정하고, 그 계정이 볼 수 있는 범위를 허브로 좁히고, 쓰기 권한은 마지막에 줍니다. 권한을 여는 건 언제든 할 수 있지만, 봇이 이미 읽은 문서는 되돌릴 방법이 없습니다.

---