사내 AI의 기밀 유출을 막은 대형 은행의 실전 해법

URL: https://www.youtube.com/watch?v=WSPio2OavfU 날짜: 2026-09-10 채널: Tech Bridge

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==회사 전체의 지식을 AI가 활용하게 만들면서도, 사용자의 권한을 넘어선 기밀 열람과 도구 실행을 어떻게 막을 것인가?==

• 회사 지식이 한 사람의 AI 메모리나 팀별 사일로에 갇히지 않고 전사 단일 위키(Single Shared Wiki)에서 연결되어야 한다.
• AI 에이전트가 지식을 조용히 자동 저장(Silent Write)하지 않고, 저장 내용과 파일별 권한 범위를 제안하며 사람이 승인해야 한다.
• 지식을 읽을 때뿐 아니라 코드·데이터 도구를 실행할 때도 매 요청마다 사용자의 자격 증명(User Credentials)과 클레임(Claims)을 적용해야 한다.

Tanmai Gopal이 PromptQL과 Hasura GraphQL 엔진을 만들며 AI 네이티브 기업, 기술 선도 기업, Fortune 100 은행까지 실험한 결과, 회사 두뇌(Company Brain)는 거대한 지식 그래프를 한 번에 구축하는 프로젝트가 아니라 각 구성원이 자신의 업무 지식을 책임 있게 보태며 유기적으로 성장하는 공유 컨텍스트(shared context)로 설계해야 한다. 전사 위키, 파일 단위 스코프(scope), 사람의 승인과 책임 추적, 사용자 권한의 요청별 주입을 결합해야 개인형 AI와 다중 사용자형 공유 AI를 모두 안전하게 운영할 수 있다.

1. 회사 두뇌의 문제와 출발점

회사 두뇌의 가장 큰 장애물은 정보량이 아니라 지식이 한 사람의 권한을 넘어서 잘못 노출될 수 있다는 보안 문제다.

1.1. 전사 AI가 만드는 기밀 유출 공포

1. 회사 인턴 비유가 보여주는 위험

   1. 회사 전체를 학습한 AI가 새 인턴에게 연결되면 급여·보상(compensation) 같은 전 직원의 민감한 정보를 갑자기 보여줄 수 있다.
   2. 회사의 모든 지식에 접근하는 AI를 도입하려면, 편리한 검색보다 먼저 “누가 무엇을 볼 수 있는가”를 보장해야 한다.

2. 에이전트 전사 배포를 막아온 현실

   1. OpenClaw나 Hermes 같은 에이전트를 회사 곳곳에 배포하는 일을 주저하게 만든 핵심 이유가 회사 기밀의 범위 밖 유출이다.
   2. Claude 계열 제품이 최근 출시 때 회사 두뇌가 될 수 있다는 기대를 받았지만, 권한 경계가 불분명하면 실제 전사 두뇌로 쓰기 어렵다는 반응이 나온다.
   3. 따라서 핵심 과제는 더 똑똑한 모델을 만드는 일이 아니라, 회사 지식과 실행 권한을 안전하게 연결하는 아키텍처를 만드는 일이다.

1.2. Tanmai Gopal의 배경과 실험 범위

1. 데이터 접근 문제를 다뤄온 팀

   1. Tanmai Gopal은 PromptQL의 공동 창업자이며, Hasura GraphQL 엔진을 만든 팀의 일원이다.
   2. Hasura는 GraphQL 생태계에서 널리 쓰인 오픈소스 프로젝트로, 복잡한 데이터 접근 문제를 해결해 왔다.
   3. Apple, Meta, JP Morgan 등 다양한 조직에 배포한 경험이 데이터와 데이터 보안에 대한 팀의 “애증 관계”를 만들었다.

2. 지난 1년의 현장 학습

   1. 팀은 규모가 큰 조직적 실험을 할 수 있는 약 15~20개 파트너와 먼저 협업했고, 이제 더 많은 사용자에게 개방하기 시작했다.
   2. 고객은 서로 다른 위험 허용 수준과 도입 속도를 가진 세 부류로 나뉘었다.
      • AI 네이티브 기업: 작동하기만 하면 무엇이든 빠르게 시도한다.
      • 기술 선도 기업: Instacart 같은 기업으로, 최고 수준의 기술을 원하고 빠르게 움직이며 일부 고장은 감수하지만 결과 품질은 매우 높아야 한다.
      • Fortune 100 대형 은행: 돈이 있는 곳이므로 바이브 코딩(vibe coding)한 AI 에이전트를 무방비로 실행할 수 없고, 엄격한 보안 규칙과 통제가 필요하다.
   3. Tanmai는 자신의 은행 안에서 바이브 코딩한 에이전트가 마음대로 실행되는 상황을 원하지 않는다는 농담으로 금융권 보안 통제의 필요성을 강조했다.

2. 회사 두뇌의 구조와 건강 신호

실험 중인 회사 두뇌는 특정 제품에 종속되지 않는, 서로 연결된 약 5,000개 페이지의 위키(wiki)로 모델링되어 있다.

2.1. 저장 형식보다 연결된 공유 컨텍스트가 중요하다

1. 5,000페이지 규모의 실제 지식 구조

   1. 팀은 약 5,000개의 상호 연결된 페이지를 회사 두뇌로 운영하며, 이를 위키로 다룬다.
   2. 같은 원리는 GitHub의 마크다운(markdown) 파일 묶음, 메모리 그래프(memory graph), 지식 그래프(knowledge graph) 등 어떤 저장소에도 적용할 수 있다.
   3. 핵심은 특정 데이터베이스 제품이 아니라, 문서들이 서로 링크되고 필요할 때 권한에 맞게 함께 읽힌다는 점이다.

2. 지식이 회사 전체에서 오는 이유

   1. 회사 두뇌는 Finance, HR, Engineering을 비롯해 모든 부서 구성원이 매일 배우고 결정한 내용을 흡수한다.
   2. 잘 작동하는 두뇌는 단순히 전체 크기만 커지는 것이 아니라, 매일 추가·수정되는 지식의 양도 변화한다.

2.2. 건강한 업데이트 곡선은 우상향한다

1. 청중에게 던진 세 가지 가설

   1. 첫 번째 곡선은 초기에 열정적으로 구축한 뒤 업데이트가 빠르게 줄어드는 하향 추세다.
   2. 두 번째 곡선은 참여자의 열의에 따라 오르내리는 안정적인 변동 추세다.
   3. 세 번째 곡선은 시간이 갈수록 매일의 업데이트 수가 꾸준히 증가하는 우상향 추세다.
   4. Tanmai는 청중에게 A, B, C 중 선택하게 했고, 각 선택에 대한 반응을 확인한 뒤 자신의 실제 데이터를 공개했다.

2. 실패하는 일회성 구축 모델

   1. 초반의 열정으로 첫날과 둘째 날에 회사 두뇌를 만들고, 누군가에게 “모든 공유 스킬 저장소를 구축하고 Slack과 이메일을 긁어와 모두가 쓰게 하라”고 맡길 수 있다.
   2. 하지만 이런 하향 곡선은 초기 구축 뒤 아무도 꾸준히 관심을 갖지 않는 상황을 뜻한다.
   3. 거대한 저장소가 존재하는 것만으로는 살아 있는 회사 지식이 되지 않는다.

3. 자동 학습 모델의 한계와 가능성

   1. 내부에 Hermes 같은 시스템을 배포해 자동으로 코멘트와 메모리를 추가하면 업데이트가 참여자의 열의에 따라 오르내리는 두 번째 곡선이 될 수 있다.
   2. 자동 학습은 지속성을 높이지만, 누가 무엇을 어떤 권한으로 기록했는지 알 수 없으면 보안과 품질 문제가 생긴다.

4. PromptQL의 실제 관찰

   1. 지난 두 달의 업데이트 기록을 그려 보니, 예상과 달리 일일 업데이트 수가 완만하게 계속 증가했다.
   2. 시스템이 실제로 유용해지자 사람들이 더 많이 가르치기 시작했기 때문이다.
   3. 데이터 조회(data querying)를 가르친 다음에는 데이터 해석(data interpretation)을 가르치고, 그다음에는 해석 결과로 행동하는 방법과 A/B 테스트 방법을 추가하게 된다.
   4. 에이전트의 학습에는 완성이 없고 각각의 업무 영역에 꾸준한 추가 속도가 있으므로, 여러 영역의 속도가 합산되면서 일일 업데이트 수가 계속 커진다.
   5. 아직 초기라 언젠가 증가세가 둔화되어 두 번째 곡선처럼 될 가능성은 열어 두었지만, 현재 관찰로는 전체 크기와 일일 업데이트 수가 함께 증가하는 것이 건강한 회사 두뇌의 신호다.

3. 회사 두뇌의 두 가지 사용 사례

보안 설계는 회사 두뇌가 실제로 사용되는 두 상황을 기준으로 나눠야 한다.

3.1. 사용 사례 1 — 개인 에이전트가 공유 지식으로 일을 처리한다

1. 보안 질의서 답변

   1. 고객이 보낸 보안 설문(Security Questionnaire)에 답해야 할 때 사용자가 AI 에이전트에게 회사 두뇌를 찾아 답변을 도와달라고 요청한다.
   2. 개인 에이전트는 다른 구성원이 과거에 정리한 Trust Center, 보안 시스템, 게이트웨이(gateway) 관련 사실을 찾아 답변 초안을 만든다.
   3. 사용자는 초안을 검토한 뒤 “이 초안을 마음에 드니 Dave에게 보내라”고 지시하고, 에이전트는 이메일을 발송한다.

2. 핵심 보안 질문

   1. 현재 사용자에게 필요한 지식이 다른 사람이 과거에 답변한 질의서, 에이전트 메모리, 스킬(skill) 문서에서 왔다면 그 지식이 현재 에이전트까지 어떻게 도달하는지 설명할 수 있어야 한다.
   2. “누군가 자동 저장해 둔 메모리가 있으니 운 좋게 접근할 수 있다”는 구조는 회사 전체의 재사용성과 접근 통제를 모두 보장하지 못한다.

3.2. 사용 사례 2 — 여러 사람이 공유 AI로 함께 작업한다

1. 멀티플레이어(shared AI) 작업

   1. Slack 같은 공간에 여러 사람이 함께 사용하는 에이전트를 두면, 회사 두뇌는 공유 AI가 된다.
   2. 여러 구성원이 같은 컨텍스트를 보며 대화하고, 각자의 역할과 권한으로 작업을 이어간다.

2. 협업형 인시던트 관리(Incident Management)

   1. 팀이 에이전트에게 로그를 가져오고, 장애를 조사하고, 코드베이스를 분석하고, Pull Request(PR)를 만들라고 요청할 수 있다.
   2. 이어서 스테이징(staging)에 배포하고, 프로덕션(production)에 배포하고, 알림(alert)을 설정하는 일까지 연결할 수 있다.
   3. 사람 여러 명이 회사 두뇌를 사용해 실제 문제를 해결하므로 지식이 가장 많이 생성되는 환경이지만, 읽기 권한뿐 아니라 실행 권한 상승(privilege escalation)을 동시에 통제해야 한다.

4. 회사 두뇌를 거대하게 구축하지 않고 성장시키는 설계

회사 두뇌는 100년 된 조직의 모든 지식을 선행 수집하는 2년짜리 프로젝트가 될 수 없으며, 각 구성원이 자신이 담당한 부분을 소유하며 성장시키는 시스템이어야 한다.

4.1. “구축(build)”보다 “성장(grow)”을 선택한다

1. 전사 지식의 완성본을 만들 수 없다는 현실

   1. 기업에서 별일 없이 2년짜리 프로젝트를 맡을 수 있다면 JP Morgan을 위한 회사 두뇌를 처음부터 만들겠다고 생각할 수 있지만, 실제로는 그런 방식이 작동하지 않는다.
   2. 100년 된 조직의 회사 두뇌를 한 번에 만드는 일은 불가능하며, 몇 달 또는 몇 년 된 자기 가족의 두뇌조차 완전히 만들기 어렵다는 비유가 사용됐다.

2. 분산 소유 방식

   1. 회사에서 작은 업무를 수행하는 각 사람이 자신의 업무 영역에 해당하는 회사 두뇌의 일부를 직접 소유하고 구축해야 한다.
   2. 각자가 자기 업무를 수행하면서 필요한 컨텍스트를 보태면 전사 시스템이 유기적으로 함께 만들어진다.
   3. 따라서 “회사 두뇌를 만든다”보다 “회사 두뇌를 자라게 한다”는 표현이 적절하다.

3. 자기 서비스(self-serve) 원칙

   1. 구성원 각자가 자신의 업무 지식을 쉽게 회사 두뇌에 추가할 수 있어야 한다.
   2. 이후 제시되는 단계들은 이 자기 서비스 흐름을 바탕으로 하며, 시간 제약 때문에 전체 단계의 세부 설명 대신 보안 질의서 사례부터 전개한다.

4.2. 보안 질의서 사례가 드러낸 기여·재사용 문제

1. Stitch Fix 사례의 흐름

   1. 영업 담당자가 Dave from Stitch Fix의 이메일을 전달했고, 이메일에는 보안 온보딩 질문들이 들어 있었다.
   2. 에이전트는 이메일과 첨부된 질문 화면을 읽고 회사의 Trust Center와 보안 체계에 관한 모든 답변을 채웠다.
   3. 사용자는 에이전트가 그 사실을 어떻게 알았는지 놀랐지만, 답변의 근거는 회사 두뇌에 축적된 지식이었다.
   4. 사용자가 초안을 승인하자 에이전트는 Dave에게 답장을 보냈다.

2. 세 번째 사람이 지식을 재사용하려면 필요한 것

   1. 과거에 보안 담당자가 같은 설문에 답하며 얻은 지식이 현재 사용자의 AI 에이전트로 전달되어야 한다.
   2. 과거 담당자가 Hermes 같은 에이전트를 사용해 메모리를 자동 저장했거나 스킬을 작성했다면, 그 결과를 어떤 저장 위치와 권한으로 공유할지 결정해야 한다.
   3. 기여자와 사용자가 달라지는 순간 개인 메모리만으로는 부족하고, 회사 전체에서 재사용 가능한 공유 컨텍스트가 필요해진다.

5. 세 가지 지식 공유 방식의 비교

GitHub 공유 스킬과 팀별 두뇌는 각각 인간의 행동 패턴과 조직 사일로 때문에 전사 지식의 해법이 되지 못한다.

5.1. 방식 1 — 모두가 GitHub에 공유 스킬을 작성한다

1. 이상적인 흐름

   1. 보안·컴플라이언스 담당자가 거대한 Excel 보안 설문을 힘들게 작성한다.
   2. 그 담당자가 곧바로 GitHub에 다른 사람을 위한 공유 스킬을 업데이트하고, 조직 전체가 그 스킬을 사용한다.

2. 사람이 실제로 행동하지 않는 이유

   1. 업무를 마친 사람이 자신과 연결되지 않은 미래의 다른 사람을 위해 별도로 문서와 스킬을 작성하는 행동은 자연스럽게 발생하지 않는다.
   2. 대부분의 사람은 자기 메모리와 컨텍스트를 정리하는 일조차 시간이 부족하며, 남을 위해 GitHub 저장소에 공유 스킬을 쓰고 Pull Request 리뷰와 병합까지 진행할 여유가 없다.
   3. Tanmai는 이런 사람을 “주님의 은총을 받은 성인처럼 친절한 동료”라고 부르는 농담을 던졌지만, 실제 조직의 기본 행동으로 기대해서는 안 된다고 결론 내렸다.

5.2. 방식 2 — 팀 단위 두뇌를 만든다

1. 팀 사일로의 장점

   1. 보안팀처럼 작은 집단이 하나의 에이전트를 함께 쓰고, 그 에이전트가 메모리를 자동 저장하며 컨텍스트를 자동 추가하도록 만들 수 있다.
   2. Slack에 Hermes 같은 에이전트를 연결해 여러 사람이 사용하는 팀 두뇌를 이미 운영하는 청중도 있었고, 현장 투표에서 몇 명이 손을 들었다.

2. 전사 두뇌가 되지 못하는 이유

   1. 팀별 메모리는 편리하지만 여전히 하나의 격리된 사일로다.
   2. 예를 들어 Claude 계열 도구의 채널별 메모리는 각 Slack 채널 안에서만 저장되고, 다른 채널이나 다른 업무에서 재사용하기 어렵다.
   3. 해당 채널에 새 사람이 추가되면 그 채널의 컨텍스트를 쓸 수 있지만, 채널 밖의 사람은 같은 지식에 접근하지 못한다.
   4. 사일로를 하나 더 만드는 것은 회사 전체가 공유하는 컨텍스트와 권한 체계를 해결하지 못한다.

5.3. 방식 3 — 전사 단일 위키와 파일 단위 스코프를 사용한다

1. 하나의 연결된 위키

   1. 모든 컨텍스트를 하나의 전사 공유 위키에 넣는다.
   2. 위키는 서로 링크할 수 있는 마크다운 파일들의 거대한 폴더처럼 구성한다.
   3. 내용이 특정 에이전트나 채널의 내부 메모리에 갇히지 않고, 권한을 가진 사람의 요청에 따라 다른 업무에서 재사용된다.

2. 파일별 읽기·쓰기 스코프

   1. 각 파일마다 누가 읽고 쓸 수 있는지에 관한 스코프를 지정한다.
   2. Finance에 관한 민감한 내용을 추가하면 Finance 스코프를, 개인적인 내용을 추가하면 Personal 스코프를 부여한다.
   3. 스코프는 페이지마다 다르게 설정할 수 있고, 각 페이지의 소유자와 접근자를 별도로 결정할 수 있다.

3. 자동 쓰기 대신 승인 가능한 제안

   1. 에이전트가 메모리를 자동으로 추가하면 무엇이 왜 들어갔는지, 어떤 권한으로 노출되는지 알 수 없다.
   2. 반대로 GitHub 방식처럼 사람이 직접 문서를 쓰고 PR 리뷰와 병합을 거치면 너무 무겁다.
   3. 가장 실용적인 중간 지점은 에이전트가 추가할 사실, 수정 내용, 적절한 스코프를 제안하고 사람이 승인하거나 거부하는 방식이다.
   4. 작업 중 제안 상자를 띄워 사용자가 빠르게 검토하게 하면, 마크다운 파일 간 링크와 배치 작업은 에이전트가 처리하고 사람은 사실의 정확성과 권한만 판단할 수 있다.

5.4. 사람이 검토하는 UX

1. 영업 이메일에서 위키로 추가하는 흐름

   1. 영업 담당자가 통화에 사용자를 초대하는 이메일을 보냈고, 사용자는 에이전트의 도움으로 이메일에 답했다.
   2. 이후 작은 상자에 위키에 추가될 여러 bullet이 제시되어, 어떤 사실이 기록될지 한눈에 확인할 수 있었다.
   3. 사용자가 “Add to Wiki”를 누르면 에이전트가 어느 마크다운 파일에 넣고 어떤 페이지와 연결할지 처리한다.

2. 검토자가 집중할 대상

   1. 사용자는 내용이 어느 파일에 들어가고 어떤 링크가 생성되는지 일일이 관리할 필요가 없다.
   2. 대신 제안된 사실이 맞는지 확인하고, 페이지별로 어떤 스코프를 부여할지 결정한다.
   3. 예를 들어 이메일 우선순위와 처리법을 정리한 개인 이메일 위키 페이지에 소유자와 접근자를 지정할 수 있다.
   4. 핵심은 에이전트가 변경(change)을 실행하는 것이 아니라 변경을 제안하고, 사람이 승인하는 것이다.

6. 전사 위키의 책임 추적과 읽기 아키텍처

전사 위키를 허용하되 모든 변경에는 사람의 이름과 권한 판단이 남아야 하며, AI가 읽는 매 순간 현재 사용자의 권한을 재확인해야 한다.

6.1. 반드시 지켜야 할 두 가지 운영 규칙

1. 모든 것을 하나의 회사 전체 위키에 넣는다

   1. 팀별 사일로로 되돌아가면 지식의 전사 재사용성이 사라지므로 이 원칙을 포기하지 않는다.
   2. 저장소가 마크다운인지 다른 시스템인지는 부차적이고, 하나의 연결된 권한 체계로 운영되는지가 핵심이다.

2. 모든 변경을 사람의 이름으로 귀속한다

   1. “Claude가 추가함”, “AI 에이전트가 추가함”, “Hermes가 추가함” 같은 기록은 허용하지 않는다.
   2. 실제 승인자의 이름을 남겨 어떤 사실을 누가 책임지고 위키에 넣었는지 추적한다.
   3. 잘못된 권한으로 전 직원의 보상 정보를 노출했다면 승인자에게 원인을 되돌려 보고 시정 조치를 할 수 있어야 한다.
   4. Tanmai는 위키 편집을 잘못한 사람을 PIP(Performance Improvement Plan)에 넣을 수도 있다는 농담으로 책임 귀속의 강도를 강조했다.

6.2. 사용자 클레임을 매번 적용하는 읽기 흐름

1. 권한을 가진 사용자로서 읽는다

   1. 사용자가 에이전트와 대화하면 에이전트는 컨텍스트를 읽을 때 그 사용자의 claims를 사용한다.
   2. Finance 문제를 해결하는 요청이면 해당 사용자가 Finance 위키를 읽을 권한이 있는지를 나타내는 Finance claim을 적용한다.
   3. 에이전트는 매번 사용자의 자격 증명으로 올바른 위키 부분을 읽으며, 고정된 전역 에이전트 권한으로 전체 위키를 읽지 않는다.

2. 읽기 아키텍처의 효과

   1. 하나의 위키에 많은 정보가 모여도, 현재 요청을 보낸 사람에게 허용된 부분만 컨텍스트로 들어간다.
   2. 지식을 공유하는 범위와 지식에 접근하는 범위를 분리해, 전사 통합과 최소 권한(least privilege)을 함께 달성한다.

7. 멀티플레이어 AI에서 지식이 생성되는 과정

여러 사람이 서로 다른 권한 수준으로 하나의 공유 컨텍스트를 사용하면 가장 풍부한 지식이 만들어지지만, 도구 권한 상승을 별도로 통제해야 한다.

7.1. 협업형 장애 조사 사례

1. 자동 학습 실패에서 조사 시작

   1. 내부 SR(Service/Support Request) 상황에서 회사 위키의 자동 학습 기능이 작동하지 않는 문제가 제기됐다.
   2. 에이전트가 필요한 스킬을 갖고 있지 않아 조사를 제대로 시작하지 못했고, 대화 속에서 무엇이 문제인지 단계적으로 파고들었다.

2. 관찰 가능성(Observability)과 쿼리 수정

   1. 에이전트가 먼저 OpenTelemetry span 이름을 사용하라는 지시를 받아 약간 개선했지만 여전히 느렸다.
   2. 코드 조사 결과 LIKE 쿼리를 사용하고 있다는 사실이 드러났고, Tanmai는 Opus 4.5를 상대로 “이건 쓰지 마라, 정말 멍청한 선택이다”라는 식으로 거칠고 유머러스하게 반응했다.
   3. LIKE 대신 equals 쿼리를 사용하자 세부 정보가 더 빠르게 드러났다.
   4. 더 깊은 조사를 통해 오류가 발생한 코드 라인도 확인됐다.

7.2. 대화와 논쟁이 고품질 지식으로 바뀐다

1. 에이전트가 제안한 학습 내용

   1. 에이전트는 “위키 페이지 이름을 찾을 때 LIKE가 아니라 equals를 사용해야 한다”는 지식을 학습했다고 제안했다.
   2. 위키 페이지 이름에 사용자 지정 prefix를 붙이면 조회 문제가 생길 수 있다는 사실도 제안했다.
   3. 이 학습 내용은 자동으로 저장되지 않고, 사람이 선택해 승인할 수 있는 후보로 제시된다.

2. 두 사람의 기술적 논쟁

   1. 다른 사람이 대화에 합류해 현재의 기술적 결정 자체가 잘못됐다고 지적했다.
   2. 두 사람은 “이렇게 해야 한다”와 “왜 지금은 저렇게 되어 있는가”를 놓고 논쟁했다.
   3. 논쟁을 통해 실제 원인이 과거에 누군가 내린 기술적 결정이 문서화되지 않았다는 사실이 드러났다.

3. 문제를 해결한 뒤 기록해야 할 지식

   1. prefix를 제거하는 수정이 실제 근본 원인을 해결하는지 관찰하고, 해결이 확인되면 해당 결정을 표준으로 확정한다.
   2. 단순히 “페이지 이름에는 prefix가 있다”라고 기록하면 기존 문제를 반복할 수 있다.
   3. 더 정확한 지식은 “페이지 이름에 prefix를 넣지 않는다. prefix가 있으면 조회 문제가 발생하고 프로덕션에서 장애를 일으킬 수 있다”이다.

4. Slack 스레드가 만드는 지식의 품질

   1. 여러 사람이 실제 문제를 함께 해결하는 Slack 스레드에는 원인, 반론, 실험, 최종 결정이 함께 남는다.
   2. 이런 상호작용이 단편적인 자동 메모리나 사후에 누군가 억지로 작성한 스킬보다 고품질의 회사 컨텍스트를 만든다.
   3. 멀티플레이어 회사 두뇌가 지향해야 할 대상은 대화 속에서 검증된 해결 지식이다.

8. 실행 권한 상승을 막는 두 번째 아키텍처

다중 사용자 공유 AI는 지식 읽기 권한뿐 아니라 실제 도구 실행 권한도 동일한 사용자의 권한으로 제한해야 안전하다.

8.1. 하나의 에이전트에 모든 도구를 주면 생기는 문제

1. 디버깅 권한과 배포 권한의 불일치

   1. 엔지니어가 에이전트를 이용해 Pull Request 작업을 할 수 있다고 해서 같은 대화에서 프로덕션 배포까지 할 수 있어서는 안 된다.
   2. 특히 은행에서는 장애를 디버깅하는 사람, 스테이징에 배포하는 사람, 알림을 설정하는 사람, 프로덕션에 배포하는 사람이 서로 다를 수 있다.

2. 통합의 가치와 위험을 함께 다룬다

   1. 디버깅부터 배포까지 한 대화에서 이어지면 작업 맥락과 지식이 끊기지 않는다는 큰 장점이 있다.
   2. 그러나 동일한 에이전트가 모든 단계의 권한을 보유하면 대화 참여자의 실제 권한보다 큰 작업을 실행할 수 있어 위험하다.
   3. 회사 두뇌가 가장 많은 지식을 만들어내는 협업 환경일수록 이 권한 상승 문제를 아키텍처로 해결해야 한다.

8.2. 샌드박스에 자격 증명을 저장하지 않는다

1. 도구 실행에도 사용자 자격 증명을 사용한다

   1. 컨텍스트를 읽을 때 사용자 claims를 적용한 것처럼, 코드가 도구를 실행할 때도 사용자 자격 증명을 사용한다.
   2. 에이전트가 고정된 서비스 계정으로 행동하지 않고, 해당 상호작용의 사용자로서 행동하게 만든다.

2. HTTP·SQL 계층에서 권한을 주입한다

   1. 클라우드 샌드박스 안에 자격 증명을 저장하지 않는다.
   2. HTTP 계층 또는 SQL 계층에서 요청마다 사용자의 자격 증명을 주입한다.
   3. 프록시(proxy)나 가상화 계층이 사용자의 권한을 전달하면, 에이전트가 실행할 수 있는 실제 데이터와 도구 범위가 사용자별로 달라진다.

8.3. 공유 AI를 위한 두 가지 설계 규칙

1. 자격 증명 비저장

   1. 클라우드 샌드박스에 실제 자격 증명을 두지 않는다.
   2. 노출·복제·오용될 수 있는 장기 비밀 대신 요청을 보낸 사용자의 인증 맥락을 실행 계층에 전달한다.

2. 실제 데이터와의 모든 상호작용 가상화

   1. 에이전트가 데이터에 직접 닿게 하지 말고 프록시하거나 가상화한다.
   2. 어떤 표현을 쓰든 핵심은 사용자 통제 아래에서 실제 데이터 접근을 중개하는 것이다.
   3. 특정 도구를 추가한 사용자가 그 도구에 접근할 수 있는 사람을 통제해야 한다.

3. 아키텍처를 원칙에서 도출한다

   1. 컨텍스트 관리와 도구 실행에 이 원칙들을 적용하면, 사용자별 권한을 읽기와 쓰기 모두에 반영하는 아키텍처가 자연스럽게 도출된다.
   2. Tanmai는 이 구조가 특별히 복잡하지 않으며, 어떤 컨텍스트를 허용하고 어떤 도구 보안 규칙을 설정할지 두 규칙에서 거꾸로 설계하면 된다고 정리했다.

주요 발언 모음

“회사 두뇌를 구축하면 회사 기밀이 유출될 가능성이 높다.”

“우리는 회사 두뇌를 만들(build) 것이 아니라 자라게(grow) 할 것이다.”

“에이전트가 변경을 실행하게 하지 말고, 변경을 제안하게 하라.”

“모든 것은 하나의 회사 전체 위키에 들어가야 한다. 이 규칙에서 물러서지 마라.”

“위키 안의 어떤 것도 ‘Claude가 추가함’이나 ‘AI 에이전트가 추가함’으로 끝나서는 안 된다. 사람의 이름이 있어야 한다.”

“클라우드 샌드박스에 자격 증명을 저장하지 마라.”

“실제 데이터와의 모든 상호작용을 프록시하고 가상화하며, 사용자가 통제하게 하라.”

핵심 데이터 & 수치

• 약 15~20개 파트너: 지난 1년 동안 PromptQL 팀이 규모 있는 실험을 함께 진행한 기업 수다.
• 약 5,000개 상호 연결 페이지: 팀이 회사 두뇌를 위키로 모델링한 실제 규모다.
• 세 가지 고객 유형: AI 네이티브 기업, Instacart 같은 기술 선도 기업, 엄격한 보안 규칙을 가진 Fortune 100 대형 은행으로 구분된다.
• 지난 두 달의 관찰: 회사 두뇌 전체 크기뿐 아니라 일일 업데이트 수가 완만하게 계속 증가했다.
• 두 가지 핵심 사용 사례: 개인 에이전트의 공유 지식 활용과 여러 사람의 공유 AI 협업이다.
• 두 가지 최종 보안 규칙: 클라우드 샌드박스에 자격 증명을 저장하지 않고, 실제 데이터와의 모든 상호작용을 가상화·프록시한다.

결론 및 시사점

1. 전사 AI의 핵심 자산은 한 번에 완성한 거대 지식 베이스가 아니라, 업무가 진행될 때마다 검증된 사실이 누적되는 살아 있는 공유 컨텍스트다.
2. 팀별 메모리와 채널별 자동 저장은 빠르게 시작할 수 있지만 지식을 사일로에 가두므로, 회사 전체가 접근할 수 있는 단일 위키와 파일별 스코프가 필요하다.
3. AI는 기억을 자동으로 조용히 쓰지 말고, 사실·변경 내용·권한 범위를 제안해야 하며 사람은 승인 또는 거부로 품질과 책임을 확정해야 한다.
4. 모든 위키 변경에 승인자의 이름을 남기면 잘못된 정보와 과도한 노출의 원인을 추적하고 시정할 수 있다.
5. 사용자의 클레임은 위키를 읽는 순간마다 적용되어야 하며, 전역 에이전트 권한으로 민감한 문서를 읽게 해서는 안 된다.
6. 에이전트가 PR 생성부터 프로덕션 배포까지 이어서 수행하더라도, 각 도구 실행은 대화 참여자의 권한으로 제한되어야 한다.
7. 자격 증명은 샌드박스에 저장하지 않고 HTTP·SQL 계층에 요청별로 주입하며, 실제 데이터 접근은 프록시·가상화 계층을 거쳐야 한다.
8. PromptQL은 이러한 원칙을 Claude 계열 모델에만 묶지 않고 GLM, GPT 등 여러 모델에서 활용할 수 있는 제품으로 확장해 AI Engineering 커뮤니티에 출시할 계획을 밝혔다.
9. 발표 말미에는 무대에서 청중과 “치즈”를 외치며 기념사진을 찍었고, 웃음 뒤에 부스에서 아키텍처 세부 사항을 더 논의하자는 초대가 이어졌다.

핵심 요약 (20줄)

1. 회사 전체를 학습한 AI는 새 인턴에게 전 직원의 보상 정보까지 노출할 수 있어 전사 도입의 첫 조건으로 권한 경계가 필요하다.
2. Tanmai Gopal은 PromptQL 공동 창업자이며 Hasura GraphQL 엔진을 만든 팀에서 Apple·Meta·JP Morgan의 데이터 접근 문제를 해결해 왔다.
3. PromptQL은 지난 1년 동안 약 15~20개 기업과 협업하며 AI 네이티브 기업부터 Fortune 100 은행까지 보안 요구를 비교했다.
4. 팀의 회사 두뇌는 서로 연결된 약 5,000개 마크다운 페이지로 구성된 위키이며 저장 기술보다 공유 컨텍스트와 권한 구조가 중요하다.
5. 건강한 회사 두뇌는 전체 크기뿐 아니라 구성원이 매일 추가하는 업데이트 수도 시간이 갈수록 증가한다.
6. 데이터 조회를 가르치면 데이터 해석과 행동, A/B 테스트 지식까지 연쇄적으로 추가되어 유용한 시스템일수록 학습 속도가 빨라진다.
7. 첫 번째 활용은 개인 에이전트가 과거 보안 질의서 지식을 찾아 고객 이메일의 답변 초안을 만드는 방식이다.
8. 두 번째 활용은 Slack의 여러 구성원이 공유 AI로 로그 조사, 코드 분석, PR 생성, 배포와 알림 설정을 협력하는 방식이다.
9. 회사 두뇌는 100년 된 조직의 지식을 선행 구축하는 프로젝트가 아니라 각 구성원이 자신의 업무 지식을 보태며 성장하는 시스템이어야 한다.
10. 보안 담당자가 거대한 Excel 질의서 뒤에 다른 사람을 위한 GitHub 스킬까지 작성할 것이라는 기대는 실제 업무 습관과 맞지 않는다.
11. 팀별 자동 메모리는 편리하지만 채널과 팀이라는 사일로에 갇혀 전사 재사용성을 제공하지 못한다.
12. 모든 컨텍스트를 하나의 연결된 전사 위키에 넣고 각 파일의 읽기·쓰기 권한을 개별 스코프로 지정해야 한다.
13. Finance의 민감한 지식에는 Finance 스코프를, 개인 정보에는 Personal 스코프를 붙여 접근 범위를 분리해야 한다.
14. AI는 메모리 변경과 권한 범위를 제안하고 사람이 사실을 검토해 승인하거나 거부하는 중간 지점이 가장 현실적이다.
15. 영업 이메일 뒤에 표시된 Add to Wiki 제안 상자는 사람이 사실 정확성과 스코프를 검토하고 파일 연결은 에이전트가 처리하게 한다.
16. 위키 변경에는 Claude나 Hermes가 아니라 실제 승인자의 이름을 남겨 잘못된 노출의 책임과 시정 조치를 추적해야 한다.
17. Finance 문제를 읽을 때처럼 모든 요청은 현재 사용자의 claims로 위키를 조회해 전역 에이전트 권한의 과잉 열람을 막아야 한다.
18. 협업 장애 조사에서 LIKE 쿼리를 equals로 바꾸고 페이지 이름의 사용자 지정 prefix를 제거한 과정이 검증된 운영 지식으로 남았다.
19. 도구 실행도 사용자 자격 증명으로 수행하고 샌드박스에는 비밀을 저장하지 않으며 HTTP·SQL 계층에서 권한을 주입해야 한다.
20. 실제 데이터와의 상호작용을 프록시·가상화하고 도구를 추가한 사용자가 접근자를 통제하면 공유 AI의 생산성과 은행급 보안을 함께 확보할 수 있다.