사내 문서 공유 자동화: AI 보고서를 회사 로그인 뒤의 링크로

사내 AI 에이전트 시리즈 4편. 1편 장기 기억과 온톨로지 · 2편 권한 설계 · 3편 슬랙·웹·CLI

TL;DR

AI가 만든 보고서와 발표자료를 채팅마다 첨부하다 보면 같은 문서의 여러 버전이 흩어져요. 저희는 사내 공유용 산출물을 S3에 올리고 Cloudflare Access(Google Workspace SSO) 뒤의 사내 도메인 주소로 열게 바꿨어요. 일회성 문서는 docs 티어의 파일 하나, 대시보드와 서비스는 앱 배포 명령으로 서브도메인을 받고, 외부 공유는 Access 정책에 이메일을 페이지 단위로 추가할 때만 열립니다.

파일을 올리고 링크만 보내던 때

마인드로직의 사내 AI 에이전트 인포미는 회의 내용을 정리하고, 업무 자료를 조사해 보고서를 만들고, 대시보드와 발표자료도 만들어요. 결과물이 늘면서 채팅에 파일을 붙이는 것만으로는 공유가 번거로워졌어요. 동료가 같은 분석을 찾으면 스레드를 뒤지거나 에이전트에게 다시 만들어 달라고 해야 했죠.

처음에는 S3 버킷에 파일을 올리고 오브젝트 URL을 나눴어요. 그때 버킷 정책은 내보내기용 접두사를 익명 읽기로 열어 둔 상태라, 사내용 대시보드도 URL을 아는 외부 사람이 열 수 있었어요. 반대로 presigned URL은 이 박스가 EC2 인스턴스 롤 자격증명으로 서명하는데 그 자격증명이 약 6시간마다 바뀌어서, 7일짜리로 만든 링크가 받은 사람이 열기 전에 끊기는 일이 있었고요. S3의 문제가 아니라 저희의 업로드·공유 방식이 사내 문서에 맞지 않았던 거죠.

첨부를 주고받던 때와 링크 하나를 두는 지금. 왼쪽은 버전이 세 개, 오른쪽은 주소가 하나예요.

그래서 회사 로그인 뒤에 산출물을 두는 공유 경로를 따로 만들었어요. 2026-08-25에 옛 접두사의 익명 읽기를 닫았고, 이제 그 경로로 업로드하려 하면 실행 전 훅이 업로드 자체를 막습니다. 문서를 만드는 사람이 매번 호스팅과 인증을 설정하지 않아도, 사내 공유에 맞는 주소를 받을 수 있게 했어요.

공개 버킷 차단 훅의 실제 출력. 업로드는 성공할 수 있어도 받는 사람이 403을 보게 되는 경로라서, 경고 대신 명령 자체를 거부하고 갈 곳을 안내해요.

회사 로그인은 어디까지 확인할까?

두 티어의 구조. 파일 하나는 S3에 올리면 docs 주소가 되고, 디렉터리는 앱 배포 명령으로 서브도메인이 되며, 둘 다 같은 Cloudflare Access 정책 뒤에 있어요.

이 경로로 공유한 페이지를 열면 Cloudflare Access가 Google Workspace로 넘겨 회사 계정 로그인을 받아요. 사내 도메인 전체에 걸린 Access 정책은 회사 이메일 도메인이고, 통과하면 서명된 JWT가 쿠키로 붙어 다음 요청부터는 로그인 없이 열립니다. 비로그인 상태로 curl을 치면 302로 로그인 페이지에 보내지는데, 이게 정상 응답이에요. 403이나 404가 진짜 장애입니다.

회사 구성원인지 확인하는 것과 문서별 열람 권한을 정하는 것은 별개예요. 건물 출입증이 있다고 모든 회의실 문이 열리지는 않는 것처럼, 팀이나 담당자만 봐야 하는 자료는 회사 전체에 열리는 공간에 두지 않아요. 회원 명단이나 인사·급여 자료처럼 개인정보가 든 산출물은 어느 티어에도 올리지 않고 Slack 파일 업로드로 받을 사람에게 직접 붙이고, 그때도 채널의 참여 범위를 먼저 확인합니다.

외부 파트너가 봐야 하는 자료는 해당 앱의 Access 정책에 열람할 이메일 주소를 추가해요. 앱마다 visibility와 allowed_emails가 있고 기본값은 빈 목록이라, 평소에는 최상위 정책 하나가 결정합니다. 누구나 볼 수 있는 공개 페이지로 바꾸는 일은 다른 버킷의 public/ 접두사로만 가능하고, 사람이 대화에서 명시적으로 허락했을 때만 진행해요. 사내에 공유하는 일과 외부에 공개하는 일을 같은 요청으로 취급하지 않도록 나눈 거예요.

모든 문서에 주소가 있고, 허브에는 자주 쓰는 앱을 모은다

일회성 보고서도 자기 URL을 받아요. 회의 정리, 조사 결과, 인수인계 문서처럼 한 번 읽고 넘길 자료는 S3 업로드 한 번으로 docs 티어에 올리고 docs 서브도메인 아래 파일 주소로 전달합니다. 이 호스트는 HTML과 Markdown을 페이지로 렌더하고, PDF·이미지·mp4는 브라우저에서 바로 열고, xlsx·pptx는 내려받게 해요. 파일명은 YYYY-MM-DD-<slug>.html로 두어 목록이 날짜순으로 정렬되게 합니다.

허브는 반복해서 찾아 쓰는 앱과 문서 묶음의 목차예요. 주기적으로 갱신되는 대시보드, 자체 목차가 있는 사용 안내, 서버에서 동작하는 업무 도구가 여기에 올라옵니다. 앱 배포 명령으로 디렉터리를 올리면 레지스트리에 버전이 기록되고 앱 이름의 서브도메인이 열려요. 정적 사이트가 기본이고 --service를 주면 WebSocket까지 통과하는 실행형 앱이 됩니다. 일회성 보고서가 쌓여도 상시 도구를 찾는 화면이 묻히지 않게 하려는 구분이에요.

허브 화면. 대시보드·서비스·정적 사이트가 종류별로 보이고, 계정과 일부 앱 이름은 가렸어요. 2026-09 기준 앱 60여 개, docs 티어 문서 3,700여 건이에요.

처음에는 docs 링크로 나눴다가 팀에서 계속 찾는 자료가 되면 허브에 올릴 수 있어요. 승격은 배포 명령 한 번이고, 반대로 일회성 문서를 허브에 올렸다가 내린 일도 있었습니다. 다시 찾아 쓸 이유가 있느냐가 목록에 올리는 기준이에요.

말로 만들고 같은 링크에서 고친다

공유할 자료가 있으면 채팅에서 "이거 링크로 줘"라고 말해요. 에이전트가 내용을 자기완결형 HTML 하나로 만들고(데이터는 인라인, 외부 fetch 없이) S3에 올린 뒤 주소를 돌려줍니다. 요청한 사람이 웹서버 설정을 만지거나 인프라 담당자에게 배포를 부탁할 필요는 없어요.

수정도 대화에서 이어가요. "저 표에서 지난달 열 빼고 이번 주 기준으로 다시 뽑아줘"라고 요청하면 같은 키로 다시 올려 기존 페이지를 덮어써요. 앱이라면 데이터 파일만 갈아 끼우거나 새 버전을 배포하고, 문제가 있으면 롤백 명령으로 이전 버전을 되살립니다. 이미 보낸 링크를 다시 배포하지 않아도 새 내용이 보이고, 문서를 받은 사람이 다른 버전의 첨부를 보고 있지는 않은지 확인하는 일이 줄었어요.

사업팀이 문의 추이를 살펴볼 화면을 요청하는 것처럼, 도구를 쓰려는 사람이 직접 제작을 시작해요. 허브에서는 누가 요청해 만든 앱인지 owner로 보여서, 내용이 이상할 때 누구에게 물어야 하는지 알 수 있어요.

대시보드는 갱신도 함께 챙겨요. 봇의 스케줄 잡을 앱에 연결하면 허브에 ↻ 표시가 붙고, 스케줄이 돌 때마다 데이터 파일이 갱신되며 생성 시각과 마지막 갱신 정보가 페이지에 표시됩니다. 보는 사람이 어느 시점의 자료인지 알아야 이후 논의도 같은 기준에서 이어지니까요.

사내 공유 자동화로 모인 업무들

상시 운영 대시보드에서는 백엔드 주간 인프라 지표나 제품 에이전트 검증 결과를 살펴봐요. 회의마다 자료를 새로 붙이는 대신 같은 화면을 열고 기간을 바꿔 가며 이야기합니다. 실험 비교 페이지에는 STT 엔진 두 개의 전사 결과와 오디오를 함께 두어, 오디오와 표가 채팅에 흩어졌을 때보다 비교 중인 대상을 링크로 짚기 쉬워졌어요.

팀별 리포트에는 주간 회의 자료, 콜봇 모니터링 결과, 릴리스 변경 사항이 모여요. 제품 사용 안내와 온보딩 문서는 목차가 있는 묶음으로 두고, 요청을 받아 계산하거나 외부 API와 연동하는 서비스형 앱도 같은 입구에서 찾아갑니다.

링크를 보내기 전의 짧은 검수

공유가 쉬워져도 AI 보고서의 내용 확인은 남아요. 수치와 근거가 맞는지, 문장을 다듬으며 고유명사나 의미가 바뀌지 않았는지 확인해요. 차트에는 기간과 단위가 보이는지, 페이지를 열었을 때 표와 글씨를 읽을 수 있는지도 headless 브라우저로 로컬 파일을 찍어 살펴보고, 공유 대상에 맞지 않는 내용이 없는지까지 마쳐야 링크를 보낼 준비가 끝납니다.

저희가 바꾼 건 문서를 만드는 순간부터 다시 찾아 수정하는 순간까지의 흐름이에요. 사내 공유용 보고서는 Cloudflare Access 뒤의 링크로 받고, 고칠 내용은 대화로 요청해요. 외부에 보여줄 일이 생기면 그 페이지의 Access 정책을 따로 정합니다. 파일을 매번 옮겨 보내던 일을 줄이면서도, 누가 읽을 자료인지 확인하는 단계는 남겨 두었어요.

에이전트가 자료를 만들 때 쓰는 도구의 권한과 실행 승인은 2편 권한 설계에, 이 결과물을 어디에서 요청하는지는 3편 슬랙·웹·CLI에 있어요.