회사 지식 두뇌는 비밀을 새어 나가게 한다: 대형 은행에서 이를 막은 방법

URL: https://www.youtube.com/watch?v=0uC6u0lJJl4 날짜: 2026-09-04 채널: aiDotEngineer

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

기업의 모든 지식과 작업 맥락을 AI가 활용하는 ‘회사 지식 두뇌(company brain)’는 유용하지만, 권한 통제가 없으면 인턴이 입사 첫날 임원 보상 정보까지 읽는 것처럼 비밀을 유출한다. ==하나의 회사 전체 위키에 지식을 모으되, 각 페이지의 접근 범위와 모든 변경의 책임자를 사람에게 귀속하고, 에이전트는 자동 기록이 아니라 변경을 제안하게 해야 한다.==

• 회사 전체의 맥락은 상호 연결된 마크다운 위키로 모으고, 파일별 읽기·쓰기 범위를 둬야 한다.
• 에이전트가 메모리를 마음대로 추가하면 무엇이 언제 왜 들어갔는지 알 수 없으므로, 사람이 제안을 검토하고 수락해야 한다.
• 컨텍스트를 읽거나 도구를 실행할 때마다 실제 사용자의 자격 증명(credential)과 클레임(claim)을 주입하고, 샌드박스에 자격 증명을 저장하지 않아야 한다.

회사 지식 두뇌의 핵심은 거대한 지식 그래프를 한 번에 구축하는 데 있지 않다. 각 구성원이 자신의 업무에서 생성한 지식을 회사 전체 위키에 제안하고, 사람이 사실성과 권한 범위를 확인하면서 점진적으로 성장시키는 데 있다. 개인이 혼자 쓰는 에이전트와 여러 사람이 함께 쓰는 공유 AI는 모두 같은 지식 기반을 활용하지만, 특히 장애 대응처럼 여러 권한 수준이 한 대화에 섞이는 상황에서는 읽기뿐 아니라 도구 실행도 사용자의 권한으로 가상화해야 한다.

1. 회사 지식 두뇌가 필요한 이유와 성장 방식

1.1. 회사 지식 두뇌를 둘러싼 가장 큰 두려움

1. 유용한 회사 두뇌가 곧 비밀 저장소가 되는 문제

   1. 회사의 이메일, 재무, 인사, 엔지니어링 지식이 AI 에이전트에 연결되면 새로 입사한 사람이 짧은 질문 하나로 회사 보상(compensation) 세부 정보까지 얻을 수 있는 상황이 생긴다.
   2. 회사의 일을 대신하는 ‘회사 두뇌’를 만들고 싶은 욕구와 회사 기밀을 지켜야 한다는 요구가 정면으로 충돌한다.
   3. 이런 위험이 OpenClaw와 Hermes 같은 에이전트를 회사 곳곳에 배포하는 일을 막아 온 가장 큰 이유다. 최근 출시된 Claude 계열 도구가 회사 두뇌가 될 수 있다는 기대를 만들었지만, 실제로는 아직 회사 두뇌처럼 보이지 않는다는 반응도 나온다.

2. 데이터 접근 문제에서 출발한 문제의식

   1. Tanmai Gopal은 PromptQL의 공동 창업자이며, GraphQL 분야의 인기 오픈소스 프로젝트인 Hasura GraphQL Engine을 만든 팀 출신이다.
   2. Hasura 팀은 Apple, Meta, JP Morgan 등 여러 조직에 데이터 접근 시스템을 배포하면서 데이터와 데이터 보안에 대해 ‘애증 관계’에 가까운 경험을 쌓았다.
   3. 지난 1년 동안 실제로 회사 두뇌를 구축하고 여러 규모의 조직에 적용하며 얻은 설계 원칙을 공유하고, 각 조직이 자신의 환경에서 직접 실험해 보기를 제안한다.

1.2. 서로 다른 조직이 요구하는 서로 다른 안전성

1. 초기 파트너의 범위

   1. 지난 1년 동안 실험한 조직은 약 15~20곳으로, 규모가 커지면서 회사 지식과 권한 문제가 실제로 드러나는 곳들이었다.
   2. 이제 더 많은 조직에 공개하기 시작했지만, 초기에는 서로 다른 요구를 가진 세 부류를 중심으로 검증했다.

2. AI 네이티브 기업

   1. AI 네이티브 기업은 작동하기만 한다면 새로운 방식을 거의 무엇이든 시도할 의향이 있다.
   2. 이 부류는 가장 빠르게 실험할 수 있지만, 다른 조직에 그대로 적용할 수 있는 보안 기준을 제공하지는 않는다.

3. 기술 선도 기업

   1. Instacart 같은 기술 선도 기업은 동급 최고(best-of-breed)의 기술을 원한다.
   2. 빠르게 움직이고 일부가 깨지는 상황은 감수할 수 있지만, 결과물은 정말 뛰어나야 한다.

4. Fortune급 은행

   1. 대형 은행은 매우 엄격한 보안 규칙과 권한 체계를 요구한다.
   2. 발표자는 자신의 돈이 들어 있는 은행 안에서 ‘바이브 코딩된(vibe-coded)’ AI 에이전트가 마음대로 돌아다니는 것을 원하지 않는다며 농담했고, 은행이 높은 수준의 보안 규칙을 유지하는 것이 다행이라고 말했다.

1.3. 건강한 회사 두뇌의 크기와 업데이트 곡선

1. 회사 두뇌를 어떻게 저장할 것인가

   1. PromptQL 팀이 사용하는 회사 두뇌는 약 5,000개의 페이지로 구성된다.
   2. 현재는 페이지끼리 서로 연결되는 위키(wiki)로 모델링했지만, 특정 저장 형식 자체가 핵심은 아니다.
   3. GitHub의 마크다운 파일 집합, 메모리 그래프(memory graph), 지식 그래프(knowledge graph) 등 원하는 저장소를 사용할 수 있다.

2. 청중에게 던진 업데이트 수 질문

   1. 회사 두뇌가 회사 전체에서 학습한 내용을 매일 업데이트한다고 가정하면, 건강한 회사 두뇌의 일일 업데이트 수는 어떤 그래프가 되어야 하는지 청중에게 물었다.
   2. 선택지는 크게 세 가지였다. 첫째는 초기에 많이 업데이트된 뒤 감소하는 하향 곡선, 둘째는 사람들의 관심에 따라 오르내리지만 장기적으로 일정한 곡선, 셋째는 시간이 갈수록 꾸준히 증가하는 곡선이었다.
   3. 발표자는 청중에게 A, B, C를 차례로 선택하게 했고, C를 선택한 사람이 있자 “좋다”고 반응했다.

3. 초기에 급증하고 사라지는 모델

   1. 첫 번째 그래프는 회사가 첫날과 둘째 날에 큰 열정으로 회사 두뇌를 구축하는 상황을 뜻한다.
   2. 누군가에게 “공유 스킬 저장소(shared skills repo)를 전부 만들라”고 시키고, Slack과 이메일을 긁어모아 모두가 쓰게 하려 하지만, 곧 아무도 관심을 두지 않으면서 업데이트가 멈춘다.

4. 자동 학습 시스템의 안정적인 증가 모델

   1. Hermes처럼 내부에 배포한 자동 학습 시스템은 구성원이 사용하는 동안 더 많은 내용을 계속 추가할 수 있다.
   2. 누가 열정적으로 기여하는지에 따라 일일 업데이트가 오르내리므로, 전체적으로는 일정한 수준에서 변동하는 두 번째 그래프처럼 보일 수 있다.

5. 실제 회사 두뇌에서 관찰한 증가 모델

   1. 최근 두 달의 업데이트 이력을 그려 보자 완만하지만 계속 상승하는 곡선이 나타났고, 발표자는 처음에 그 이유를 보고 놀랐다.
   2. 시스템이 실제로 작동하기 시작하면 사람들이 더 많이 가르치기 때문이다. 데이터 조회(query) 방법을 가르친 다음 날에는 그 데이터를 해석하는 방법을, 그다음에는 해석 결과를 바탕으로 행동하는 방법을 가르치고, 이후에는 그 행동을 A/B 테스트하는 방법을 추가한다.
   3. 에이전트가 배우는 내용은 한 번에 완벽해지지 않는다. 각각의 학습 항목이 일정한 속도로 계속 개선되며, 그 속도가 누적되면서 일일 업데이트 수도 함께 증가한다.
   4. 아직 초기 데이터이므로 결국 두 번째 그래프처럼 증가세가 둔화될 가능성도 있지만, 건강한 회사 두뇌는 전체 크기뿐 아니라 하루에 추가되는 업데이트 수도 커지는 것이 좋은 신호다.

2. 회사 지식 두뇌의 정의와 두 가지 사용 사례

2.1. 개인 에이전트가 회사 지식을 활용하는 경우

1. 보안 설문지 응답 자동화

   1. 고객에게서 보안 설문지(security questionnaire)가 포함된 이메일을 받으면, 사용자는 AI에게 회사 두뇌를 찾아 설문 답변을 도와달라고 요청할 수 있다.
   2. 이메일에는 Stitch Fix의 Dave가 보낸 메시지와 보안 온보딩 질문의 스크린샷이 있었다.
   3. 에이전트는 회사의 트러스트 센터(trust center), 보안 체계, 게이트웨이(gateway) 등에 관한 답을 회사 두뇌에서 찾아 설문지의 질문을 채웠다.
   4. 사용자가 초안을 확인한 뒤 “이 초안을 Dave에게 보내라”고 말하자 에이전트가 이메일을 전송했다.

2. 지식의 출처를 추적해야 하는 문제

   1. 사용자는 자신이 알지 못하는 보안 답변을 에이전트가 어떻게 알고 있는지 의아해했다.
   2. 다른 보안 담당자가 과거에 같은 설문지를 처리하면서 에이전트에 메모리를 저장했거나 스킬(skill)을 기록했을 가능성이 있다.
   3. 그 지식이 다른 사람의 AI 에이전트로 이동하려면, 누가 어떤 사실을 어떤 권한 범위로 공유할지 결정하는 경로가 필요하다.

2.2. 여러 사람이 하나의 공유 AI를 사용하는 경우

1. 멀티플레이어 회사 AI

   1. 회사 두뇌는 다른 사람의 지식을 개인 에이전트가 가져오는 용도뿐 아니라, 여러 사람이 Slack 같은 공간에서 같은 AI와 상호작용하는 용도로도 쓰인다.
   2. 여러 사람이 함께 쓰는 AI는 일종의 공유 AI(shared AI)이며, 최근 여러 도구가 지향하는 멀티플레이어(multiplayer) 모델과 연결된다.

2. 협업형 장애 관리(incident management)

   1. 한 대화에서 로그를 가져오고, 장애를 조사하고, 코드베이스를 확인하고, PR(pull request)을 만들고, 스테이징(staging)과 프로덕션(production)에 배포하고, 알림(alert)을 설정하는 작업을 이어서 수행할 수 있다.
   2. 이 과정에는 여러 사람이 참여하고, 각자 할 수 있는 작업과 승인할 수 있는 배포 단계가 다르다.
   3. 따라서 개인 이메일을 답하는 첫 번째 사용 사례보다 공유 AI 장애 관리는 회사 지식과 권한 통제가 훨씬 많이 얽힌 ‘대형’ 사용 사례다.

2.3. 회사 지식 두뇌를 정확히 정의하기

1. 핵심 정의

   1. 회사 두뇌는 코딩 에이전트(coding agent)에 제공할 공유 맥락(shared context)을 마크다운(markdown) 파일 집합에 저장하고, 그 안의 데이터와 사용할 도구에 접근 제어 규칙(access-control rules)을 부여한 것이다.
   2. 이 정의는 발표자가 자신의 발표를 위해 설정한 것이며, 모든 사람이 따라야 하는 유일한 정의라고 주장하는 것은 아니다.

2. 일반적인 AI 지식베이스와의 차이

   1. 회사 전체의 거대한 지식 그래프나 지식베이스를 만들고, 그 지식베이스를 읽어 도구를 호출하는 일반 목적 AI를 보안으로 감싸는 접근은 목표가 아니다.
   2. 핵심은 어떤 문제를 던져도 해결하도록 설계된 코딩 에이전트다.
   3. 예를 들어 “트윗 하나를 써라”는 요청은 작은 스크립트가 AI를 호출해 트윗을 반환하면 되므로 코딩 에이전트가 과할 수 있지만, Claude Code를 거의 모든 일에 쓰는 발상, Claude Cowork와 Codex 앱이 따르는 구조는 코딩 에이전트가 일반 문제를 해결하도록 확장될 수 있음을 보여준다.
   4. 회사 두뇌는 그런 코딩 에이전트가 업무를 수행할 수 있도록 맥락과 권한을 공급한다.

2.4. 회사를 위해 두뇌를 ‘구축’하지 말고 ‘성장’시키기

1. 중앙집중식 2년 프로젝트의 한계

   1. 100년 된 JP Morgan 같은 조직을 대상으로 “2년 동안 회사 두뇌를 만들어 내자”는 프로젝트를 시작하는 것은 현실적이지 않다.
   2. 몇 달 또는 몇 년 된 가족의 지식조차 한 번에 완전한 두뇌로 만들기 어렵다는 비유가 나왔다.

2. 구성원별 소유권

   1. 회사에서 조금씩 일을 하는 각 사람이 자신이 담당하는 부분의 회사 두뇌를 소유하고 구축해야 한다.
   2. 중앙 팀이 모든 지식을 수집해 완성하는 대신, 각 구성원이 업무 중 얻은 맥락을 스스로 회사 두뇌에 기여한다.
   3. 따라서 표현도 ‘회사 두뇌를 만든다(build)’보다 ‘회사 두뇌를 성장시킨다(grow)’가 정확하다.

3. 셀프 서비스(self-service) 원칙

   1. 각 구성원이 자신의 업무 영역을 직접 회사 두뇌에 추가하는 흐름을 만들어야 한다.
   2. 발표자는 이 원칙을 이후의 구체적인 UX와 권한 모델로 확장하겠다고 설명했지만, 시간 관계상 일부는 빠르게 지나갔다.

3. 지식 공유에서 실패하는 세 가지 방식

3.1. 모두가 GitHub에 공유 스킬을 직접 쓰게 하는 방식

1. 이상적인 첫 번째 해법

   1. 보안 담당자가 처음 보안 설문지를 처리한 뒤, 다른 사람이 재사용할 수 있도록 GitHub의 공유 스킬 저장소에 스킬을 기록하는 방식이다.
   2. 이 방식은 변경 사항을 코드 리뷰와 PR로 관리할 수 있어 겉보기에는 안전하고 명확하다.

2. 일상 업무와 맞지 않는 기여 방식

   1. 보안·컴플라이언스 담당자는 거대한 Excel 설문지를 답하는 것만으로도 힘든데, 그 뒤 GitHub로 가서 공유 스킬까지 갱신할 시간과 동기가 거의 없다.
   2. 발표자는 그런 일을 기꺼이 해 주는 사람을 “우리의 주님이자 구세주인 그리스도를 닮을 정도로 친절한 사람”이라고 과장해 농담했다. 대부분의 사람은 다른 사람을 위해 GitHub 스킬을 작성하지 않는다.
   3. 업무 중인 사람은 자신과 연결되지 않은 미래의 누군가에게 도움이 될 정보를 갑자기 정리하지 않는다. 자기 자신의 메모리와 맥락을 큐레이션하는 것조차 어렵기 때문이다.

3.2. 회사 두뇌 대신 팀 두뇌 하나를 두는 방식

1. 팀 단위 에이전트

   1. 보안팀처럼 작은 팀이 공유된 하나의 공간을 사용하고, 그 안의 에이전트가 메모리를 자동 저장하고 맥락을 자동 추가하게 할 수 있다.
   2. 청중에게 이런 팀 두뇌를 이미 운영하는지 물었고, 한 명을 시작으로 몇 명이 손을 들었다.

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

   1. 팀 두뇌는 팀 내부에서는 편리하지만 다른 팀이 접근할 수 없는 또 하나의 사일로(silo)다.
   2. 회사 전체에서 사용되는 지식이 아니라 특정 팀이 보유하는 별도 저장소가 되므로, 지식이 다른 업무로 이동하지 않는다.

3.3. 채널별 자동 메모리의 고립

1. 채널 메모리의 장점

   1. Claude 계열 공유 도구에 채널별 메모리가 있으면 특정 Slack 채널에서 대화한 사실을 그 채널의 AI가 계속 활용할 수 있다.
   2. 해당 채널에 새 구성원이 들어오면, 그 사람도 채널의 기존 맥락을 활용할 수 있다.

2. 재사용 범위의 한계

   1. 채널 메모리는 여전히 한 채널에 갇힌 또 하나의 사일로다.
   2. 그 채널에 추가되지 않은 사람이나 다른 업무의 에이전트는 그 지식에 접근할 수 없다.
   3. 회사 전체 지식을 공유하려면 특정 대화 공간의 자동 메모리를 넘어서야 한다.

4. 하나의 회사 위키와 인간 승인 기반의 권한 모델

4.1. 상호 연결된 단일 위키

1. 모든 맥락을 한곳에 모으기

   1. 모든 맥락을 하나의 공유 위키에 넣는다. 위키는 서로 링크할 수 있는 마크다운 파일들의 거대한 폴더로 생각하면 된다.
   2. 정보가 특정 팀이나 채널 내부에 저장되는 대신, 각 마크다운 페이지가 서로 연결되면서 회사 전체의 맥락 네트워크를 이룬다.

2. 파일별 범위(scope)

   1. 각 파일마다 누가 읽고 쓸 수 있는지 읽기·쓰기 범위(read/write scope)를 설정한다.
   2. 금융 정보는 금융 범위(finance scope), 개인 정보는 개인 범위(personal scope)처럼 내용의 민감도와 소유 조직에 맞춰 페이지별 권한을 지정한다.

3. 자동 기록을 막고 변경을 제안하기

   1. 가장 중요한 규칙은 에이전트가 메모리를 자동으로 추가하지 못하게 하는 것이다.
   2. 에이전트가 무단으로 기록하면 무엇이 추가되었는지, 왜 추가되었는지, 누구에게 보이는지 알 수 없고, 특정 에이전트의 메모리를 우연히 공유하는 사람만 그 내용을 활용하게 된다.
   3. 에이전트는 추가할 내용과 적절한 범위를 제안하고, 사람이 수락하거나 거부해야 한다.
   4. 이 방식은 GitHub PR처럼 무겁게 직접 스킬을 작성하고 리뷰받는 절차와, 에이전트가 메모리를 마음대로 쓰는 무모한 방식 사이의 절충점이다.

4.2. 실제 UX: 사실을 검토하고 위키에 추가하기

1. 영업 이메일에서 생성된 제안

   1. 영업 담당자가 전화를 잡기 위해 보낸 최근 이메일을 에이전트가 읽고 답장을 도왔다.
   2. 작업이 끝난 뒤 작은 상자가 나타나며, 회사 위키에 추가하려는 여러 bullet을 보여 준다.
   3. 사용자는 ‘위키에 추가(add to wiki)’를 누르기 전에 제안된 사실을 검토한다.

2. 검토의 대상은 파일 배치가 아니라 사실이다

   1. 사용자가 관심을 두는 것은 에이전트가 어떤 마크다운 파일에 기록하는지, 페이지를 어떤 링크로 연결하는지가 아니다.
   2. 중요한 질문은 제안된 사실이 정확한가이다. 사실이 맞으면 위키에 추가하고, 파일 배치와 링크 관리는 시스템에 맡긴다.

3. 페이지별 범위 결정

   1. 위키에 추가하는 순간 각 페이지에 적용할 범위를 선택할 수 있다.
   2. 이메일 우선순위와 처리 방법을 적어 둔 개인 이메일 위키 페이지처럼, 페이지마다 접근자와 소유자를 정할 수 있다.
   3. 구체적인 시스템 구현은 조직마다 달라도 되지만, 핵심은 에이전트가 변경(change)을 실행하는 것이 아니라 변경을 제안(suggest)해야 한다는 점이다.

4.3. 회사 위키를 운영하기 위한 두 가지 강제 규칙

1. 규칙 1: 하나의 회사 전체 위키

   1. 모든 내용을 회사 전체 위키에 넣어야 하며, 팀·채널별 별도 저장소로 후퇴하지 말아야 한다.
   2. 단일 위키가 있어야 한 사람이 만든 지식을 다른 사람이 자신의 권한 범위 안에서 발견할 수 있다.

2. 규칙 2: 모든 변경에는 사람의 이름이 있어야 한다

   1. 위키 안에 “Claude가 추가함”, “AI 에이전트가 추가함”, “Hermes가 추가함” 같은 기록을 남겨서는 안 된다.
   2. 반드시 “Tanmai가 추가함”처럼 실제 책임자의 이름을 남겨야 한다.
   3. 누군가 회사 전체의 보상 정보를 잘못 노출했다면, 어떤 사람이 해당 변경을 승인했는지 추적하고 시정 조치를 취할 수 있어야 한다.
   4. 발표자는 잘못 편집한 사람을 성과 개선 계획(PIP, performance improvement plan)에 넣는 상황을 농담으로 언급했지만, 농담과 별개로 사람에게 책임을 연결하는 것이 보안 운영의 핵심이라고 강조했다.

3. 사용자별 클레임으로 읽기

   1. 사용자가 에이전트와 대화하면, 에이전트는 회사 위키를 읽을 때 그 사용자의 클레임(claim)을 사용한다.
   2. 금융 문제를 해결하는 사용자가 금융 위키를 읽을 권한을 가지고 있다면, 에이전트도 매번 사용자를 대신해 금융 범위의 내용을 읽는다.
   3. 에이전트 자체가 가진 포괄적 권한으로 읽는 것이 아니라, 요청을 시작한 사람의 자격 증명으로 허용된 부분만 읽게 한다.

5. 여러 권한 수준이 섞인 공유 AI를 안전하게 실행하기

5.1. 가장 많은 지식을 만드는 ‘대형’ 사용 사례

1. 공유 맥락을 통한 다중 사용자 문제 해결

   1. 한 사람이 이메일을 답하는 경우보다, 여러 사람이 같은 회사 맥락을 이용해 복잡한 문제를 해결하는 과정에서 더 많은 고품질 지식이 만들어진다.
   2. 이 대화에는 조사, 코드 변경, 리뷰, 배포처럼 권한 단계가 다른 작업이 연속으로 들어간다.

2. 자동 학습 위키의 장애 사례

   1. 실제 서비스 요청(SR, service request)에서 자동 학습과 위키 학습이 제대로 작동하지 않는 문제가 발생했다.
   2. 에이전트가 처음에는 관련 스킬 없이 조사했기 때문에 일이 잘되지 않았고, 사용자는 “그러지 말고 이 OpenTelemetry span 이름을 사용하라”고 지적했다.
   3. 개선된 뒤에도 너무 느리자 코드를 확인했고, LIKE 쿼리를 사용하고 있다는 사실이 드러났다.
   4. 에이전트가 LIKE 대신 equals 쿼리를 사용하도록 바꾸자 더 많은 세부 정보가 노출됐다.

3. 도구 사용에서 얻은 학습 제안

   1. 에이전트는 LIKE가 아니라 equals를 사용해야 한다는 학습을 제안했다.
   2. 위키 페이지 이름에 사용자 정의 접두사(custom prefix)를 붙이면 조회(lookup) 문제가 발생할 수 있다는 학습도 제안했다.
   3. 사용자는 제안된 학습을 검토하고 수락할 수 있다. 자동으로 위키에 쓰지 않고 사람이 승인하기 때문에, 장애를 해결하는 실제 맥락이 지식으로 남는다.
   4. 발표자는 이 과정에서 Opus 4.5를 향해 LIKE 쿼리를 쓴 것을 “멍청하다”는 식으로 놀렸고, 기술적 비판과 가벼운 농담을 섞어 설명했다.

5.2. 논쟁과 근본 원인이 고품질 지식이 되는 과정

1. 두 번째 사람이 합류하는 순간

   1. 대화에 다른 사람이 들어와 “여기서 내린 기술적 결정이 잘못됐다. 왜 이렇게 되었나?”라고 문제를 제기했다.
   2. 두 사람은 “이렇게 하면 안 되고 저렇게 해야 한다”, “그런데 왜 지금은 이렇게 되어 있나”를 놓고 논쟁한다.

2. 문서화되지 않은 기술 결정의 발견

   1. 논쟁을 따라가면 실제 원인은 이전에 누군가 기술적 결정을 내렸지만 그 결정을 문서화하지 않았다는 사실로 드러난다.
   2. 팀이 문제를 고치면서 특정 접두사를 제거해야 한다는 사실을 확인하고, 그것이 실제 근본 원인인지 관찰해 검증한다.

3. 최종적으로 저장할 지식

   1. 단순한 권고는 “페이지에는 접두사를 쓰지 말라”일 수 있다.
   2. 더 정확한 지식은 “페이지 이름에 접두사가 있으면 프로덕션에서 조회 문제가 발생할 수 있으므로 접두사를 제거해야 한다”이다.
   3. 여러 사람이 Slack 스레드에서 실제 문제를 함께 조사하고 해결한 뒤 남기는 맥락이 회사 두뇌에 추가할 수 있는 가장 질 높은 지식이다.

5.3. 공유 AI에서 권한 상승이 위험한 이유

1. 하나의 에이전트에 모든 권한을 주는 위험

   1. 여러 사람이 모든 작업을 하나의 에이전트로 이어서 수행하면 편리하지만, 그 에이전트가 가진 권한이 너무 커진다.
   2. 엔지니어에게 PR을 만들 권한만 주었는데, 같은 대화와 같은 에이전트를 이용해 프로덕션 배포까지 실행할 수 있다면 위험하다.

2. 은행에서 분리되어야 하는 역할

   1. 장애를 디버깅하는 사람, 스테이징에 배포하는 사람, 알림을 설정하는 사람, 프로덕션에 배포하는 사람은 대형 은행에서 보통 서로 다르다.
   2. 한 대화에서 디버깅부터 안전한 프로덕션 배포까지 자동으로 이어지는 구조는 특히 은행 환경에서 허용하기 어렵다.

3. 지식과 권한의 긴장

   1. 그렇다고 작업을 사람별로 완전히 분리하면 문제를 함께 해결하는 대화가 끊기고, 가장 좋은 학습 맥락도 사라진다.
   2. 따라서 같은 공유 AI와 맥락을 유지하면서도, 매 작업을 실제로 수행하는 사람의 권한만 적용해야 한다.

5.4. 도구 실행에도 사용자의 자격 증명 주입하기

1. 읽기 권한과 실행 권한을 같은 원리로 관리하기

   1. 회사 위키를 읽을 때 사용자의 자격 증명과 클레임을 쓰는 것처럼, 코드가 도구를 실행할 때도 사용자의 자격 증명을 사용해야 한다.
   2. AI가 “에이전트의 권한”으로 실행되는 것이 아니라 특정 상호작용을 시작한 사람을 대신해 실행되도록 만든다.

2. 샌드박스에 자격 증명을 저장하지 않기

   1. 자격 증명을 클라우드 샌드박스나 실행 환경에 저장해서는 안 된다.
   2. 샌드박스가 탈취되거나 에이전트가 잘못된 경로로 접근해도 장기 자격 증명이 함께 유출되지 않도록 해야 한다.

3. HTTP와 SQL 계층에서 권한을 주입하기

   1. HTTP 계층과 SQL 계층에서 사용자의 자격 증명을 주입한다.
   2. 이렇게 하면 AI는 해당 상호작용에서 사람처럼 행동하지만, 그 사람이 실제로 접근할 수 있는 데이터와 도구만 사용할 수 있다.
   3. 도구 실행 권한을 대화의 분위기나 이전 메시지에서 추론하지 않고, 실행 순간의 사용자 자격 증명으로 판정한다.

5.5. 네 가지 설계 원칙으로부터 도출되는 아키텍처

1. 자격 증명 보호

   1. 클라우드 샌드박스에 사용자의 자격 증명을 저장하지 않는다.
   2. 각 요청을 실제 사용자 정체성과 연결해 필요한 순간에만 권한을 전달한다.

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

   1. 실제 데이터와의 모든 상호작용을 프록시(proxy)하거나 가상화(virtualize)한다.
   2. 조직이 어떤 단어를 쓰든 핵심은 AI가 원본 데이터에 직접 무제한 접근하지 못하게 하고, 통제 가능한 경계에서 요청을 중개하는 것이다.

3. 도구 접근권의 사용자 통제

   1. 특정 도구를 회사 두뇌에 추가한 사용자가 그 도구를 누가 사용할 수 있는지 통제해야 한다.
   2. 도구를 한 번 등록했다는 이유만으로 회사의 모든 사용자가 자동으로 실행할 수 있게 해서는 안 된다.

4. 권한과 맥락을 거꾸로 설계하기

   1. 위 원칙들에서 거꾸로 출발하면, 맥락을 어떻게 관리하고 어떤 제약을 둘지, 도구를 어떻게 관리하며 어떤 보안 규칙을 적용할지에 맞는 아키텍처가 도출된다.
   2. 구조 자체는 특별히 복잡하지 않지만, 회사 위키의 범위·책임자·사용자 자격 증명·도구 실행 경계를 빠짐없이 지키는 것이 어렵고 중요하다.

6. 마무리와 PromptQL의 확장 방향

6.1. 발표의 마무리

1. 발표자는 시간이 거의 끝났기 때문에 두 번째 사용 사례의 아키텍처를 더 깊게 설명하지 못했다고 말했다.
2. 부스에서 설계의 세부 사항과 각 조직에 적용하는 방법을 계속 이야기할 수 있다고 안내했다.
3. 본인을 Tanmai라고 소개하고 Twitter에서 찾을 수 있으며, 회사 이름은 PromptQL이라고 알렸다.

6.2. 제품 출시 예고와 모델 독립성

1. AI 엔지니어링 커뮤니티와 함께 제품 출시를 준비하고 있으며, 청중이 다른 사람들에게도 소식을 공유해 주기를 요청했다.
2. 발표 직후 무대 위에서 다 함께 사진을 찍어 공유하겠다고 했고, “치즈”라고 외치자 청중이 웃었다.
3. PromptQL의 접근 방식은 앞서 설명한 Claude 계열 도구의 아이디어와 유사하지만, 특정 모델에 묶이지 않는다는 점을 강조했다.
4. Claude만 고집하지 않고 GLM, GPT 등 여러 모델을 사용할 수 있으므로, 같은 권한·맥락 구조 위에서 원하는 모델을 선택해 활용할 수 있다.

주요 발언 모음

“회사 두뇌를 만들(build) 것이 아니라 성장시킬(grow) 것이다.”

“건강한 두뇌는 전체 크기뿐 아니라 하루 업데이트 수도 계속 증가한다.”

“에이전트가 변경을 하게 하지 말고, 무엇을 추가할지 제안하게 한 다음 사람이 수락하거나 거부하게 하라.”

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

“위키 안에는 ‘Claude가 추가했다’고 쓰면 안 된다. ‘Tanmai가 추가했다’고 써야 한다.”

“자격 증명을 샌드박스에 저장하지 말고, 실제 데이터와의 모든 상호작용을 가상화하라.”

“엔지니어가 PR을 할 수 있다고 해서 같은 에이전트로 프로덕션 배포까지 할 수 있어서는 안 된다.”

핵심 데이터 & 수치

• 약 15~20개 조직: 지난 1년 동안 회사 두뇌를 실제로 함께 검증한 초기 파트너 수다.
• 약 5,000페이지: PromptQL 팀이 회사 지식 두뇌를 위키로 모델링한 규모다.
• 최근 두 달: 실제 업데이트 이력을 관찰해 일일 업데이트 수가 완만하게 증가하는 곡선을 확인한 기간이다.
• 세 가지 업데이트 그래프: 초기 대량 입력 후 감소, 변동하지만 일정, 시간이 갈수록 증가하는 세 패턴을 청중에게 제시했다.
• 100년 된 조직: JP Morgan 같은 오래된 조직의 회사 두뇌를 중앙 팀이 2년 프로젝트로 완성한다는 접근이 비현실적이라는 예시다.
• 5개 이상 작업 단계: 장애 대응 사례에서 로그 조회, 조사, 코드베이스 확인, PR 생성, 스테이징 배포, 프로덕션 배포, 알림 설정이 이어졌다.
• OpenTelemetry: 자동 학습 위키 장애를 조사할 때 사용해야 한다고 지적된 span 이름과 관측성(observability) 맥락이다.
• LIKE 대 equals: 느린 조회를 개선하는 과정에서 LIKE 쿼리 대신 equals 쿼리를 사용해야 한다는 학습이 생성됐다.
• 커스텀 접두사: 위키 페이지 이름에 사용자 정의 접두사를 붙이면 프로덕션 조회 문제가 발생할 수 있다는 근본 원인이 발견됐다.
• Opus 4.5: 잘못된 LIKE 쿼리를 사용한 에이전트를 지적하는 대목에서 언급된 모델 버전이다.
• GLM·GPT 등: PromptQL이 특정 Claude 모델에 종속되지 않고 여러 모델을 선택할 수 있다고 설명한 예시다.

결론 및 시사점

1. 회사 지식 두뇌는 모든 회사 지식을 먼저 수집해 완성하는 프로젝트가 아니라, 구성원들이 실제 업무에서 얻은 맥락을 계속 제안하고 승인하면서 성장하는 시스템으로 설계해야 한다.
2. 단일 회사 위키는 지식의 사일로화를 막고, 파일별 읽기·쓰기 범위는 “모든 것을 공유하되 모든 사람에게 공개하지는 않는” 구조를 만든다.
3. 에이전트의 자동 메모리 기록은 편리해 보여도 출처, 사실성, 노출 범위를 통제하기 어렵다. 변경 제안과 인간 승인을 결합해야 지식 품질과 감사 가능성을 함께 확보할 수 있다.
4. 모든 위키 변경에 승인한 사람의 이름을 남기면 잘못된 권한 설정이나 기밀 노출의 책임 소재를 추적하고 시정할 수 있다.
5. 회사 위키를 읽는 권한과 API·SQL·배포 도구를 실행하는 권한은 모두 실제 사용자의 자격 증명으로 결정해야 한다. 에이전트 자체에 회사 전체 권한을 부여하면 공유 AI가 곧 권한 상승 경로가 된다.
6. 자격 증명을 샌드박스에 보관하지 않고 HTTP·SQL 계층에서 요청별로 주입하면, 같은 에이전트와 대화를 유지하면서도 사람마다 허용된 데이터와 도구만 사용할 수 있다.
7. 장애 대응 대화에서 나온 논쟁, 근본 원인, 수정 결과는 단순한 정답보다 훨씬 높은 품질의 조직 지식이다. 다만 그 지식도 사람이 검토하고 적절한 범위를 부여해 위키에 넣어야 한다.
8. PromptQL이 제시한 모델 독립적 구조는 특정 LLM의 성능보다 회사 맥락의 품질, 사용자 권한, 도구의 실행 경계를 먼저 설계해야 한다는 점을 보여준다.

핵심 요약 (20줄)

1. 회사 지식 두뇌는 업무를 빠르게 만들지만 권한 통제가 없으면 기밀을 유출한다.

2. OpenClaw와 Hermes의 사내 확산을 막은 가장 큰 장벽은 회사 지식에 대한 접근 통제다.

3. PromptQL 팀은 Apple, Meta, JP Morgan 등에 데이터 접근 시스템을 배포하며 보안 경험을 쌓았다.

4. 초기 회사 두뇌 실험에는 규모가 큰 조직 약 15~20곳이 참여했다.

5. PromptQL의 회사 두뇌는 서로 연결된 약 5,000개의 위키 페이지로 구성된다.

6. 건강한 회사 두뇌는 전체 크기뿐 아니라 하루 업데이트 수도 계속 증가한다.

7. 데이터 조회를 배운 뒤 해석과 실행, A/B 테스트를 배우면서 지식 증가 속도가 누적된다.

8. 회사 두뇌는 중앙 팀이 완성하기보다 각 구성원이 자신의 업무 영역을 성장시켜야 한다.

9. GitHub에 모든 사람이 공유 스킬을 직접 쓰게 하는 방식은 일상 업무의 자연스러운 행동이 아니다.

10. 팀별 자동 메모리는 편리하지만 회사 전체에서 재사용할 수 없는 사일로가 된다.

11. 하나의 회사 전체 위키에 마크다운 페이지를 연결하고 파일별 읽기·쓰기 범위를 부여해야 한다.

12. 에이전트는 메모리를 자동 저장하지 말고 추가할 사실과 권한 범위를 제안해야 한다.

13. 사람은 에이전트가 선택한 파일보다 제안된 사실의 정확성을 검토하고 위키 추가를 승인한다.

14. 모든 위키 변경에는 AI 이름이 아니라 승인한 실제 사람의 이름을 남겨야 한다.

15. 사용자의 금융 클레임이 있어야 에이전트가 금융 위키를 그 사용자 대신 읽을 수 있다.

16. 장애 대응 대화에서 LIKE 대신 equals를 써야 한다는 학습과 접두사 조회 문제가 발견됐다.

17. 여러 사람이 논쟁하며 문서화되지 않은 기술 결정의 근본 원인을 찾아야 고품질 지식이 만들어진다.

18. PR 권한을 가진 엔지니어가 같은 에이전트로 프로덕션 배포까지 하는 구조는 위험하다.

19. 샌드박스에 자격 증명을 저장하지 말고 HTTP·SQL 계층에서 사용자의 권한을 주입해야 한다.

20. PromptQL은 Claude에 종속되지 않고 GLM·GPT 등 여러 모델을 사용하는 회사 AI 구조를 지향한다.