Your company brain will leak secrets: how we stopped it for big banks — Tanmai Gopal, PromptQL

한 줄 핵심

회사용 AI 지식 기반은 잘 만들면 업무를 크게 돕지만, 권한·컨텍스트·기록 방식이 분리되지 않으면 내부 기밀을 쉽게 노출하므로 ‘한 위키에 모으되 사람의 승인과 권한 스코프를 강제하는 구조’가 핵심이다.

시간별 요약

1. 0:00
   회사 지식은 왜 새고, 배포를 막는 것은 무엇인가 회사 브레인을 만들면 내부 기밀이 새어 나갈 수 있다는 두려움이 가장 큰 장애물이다. 그래서 실제 도입은 열망보다 보안과 통제 문제에서 막히며, 이 문제가 회사용 AI 확산의 핵심 쟁점으로 제시된다.
2. 1:06
   Hasura GraphQL 엔진에서 PromptQL까지 Hasura GraphQL engine을 만들며 데이터 접근과 보안 문제를 대규모로 다뤄온 경험이 PromptQL의 출발점이 된다. 그 경험을 바탕으로 회사 지식과 데이터 보안을 함께 다루는 접근을 지난 1년간 실험했고, 그 학습을 공유하려는 흐름이 잡힌다.
3. 2:03
   스타트업부터 은행까지, 세 가지 고객 유형 고객은 AI native 회사, 기술 수용도가 높은 선도 기업, 강한 보안 규제를 가진 대형 은행으로 나뉜다. 특히 은행은 엄격한 보안 요구 때문에 가장 까다롭지만, 동시에 회사 브레인을 실제로 써야 하는 대표적 환경으로 다뤄진다.
4. 3:14
   브레인을 모델링하는 방식과 5,000개의 연결된 페이지 회사 브레인은 위키, GitHub의 markdown 파일, knowledge graph 등 다양한 형태로 표현할 수 있지만, 핵심은 약 5,000개의 상호 연결된 페이지로 이루어진 공유 지식 구조라는 점이다. 중요한 것은 저장 형식보다 이 지식들이 어떻게 서로 연결되는가이다.
5. 3:41
   건강한 수정 곡선은 어떤 모습인가 회사 브레인이 잘 작동한다면 매일의 업데이트 수가 어떻게 변해야 하는지를 묻는다. 단순히 초기에 급증했다가 끝나는 것이 아니라, 사용이 쌓이면서 꾸준히 개선이 계속되는 패턴이 건강한 브레인의 신호로 제시된다.
6. 5:16
   계속 올라가는 선 실제 관찰에서는 하루 수정 수가 점점 늘어나는 완만한 상승 곡선이 나타났다. 시스템이 유용해질수록 사람들이 더 많이 가르치고 더 많은 지식을 얹기 때문에, 건강한 브레인은 크기뿐 아니라 일일 업데이트량도 함께 커진다.
7. 6:37
   개인 회상과 공유 업무라는 두 가지 사용 사례 회사 브레인은 개인이 이메일이나 문서를 처리할 때 참조하는 용도와, 여러 사람이 함께 작업하는 공유 AI 용도로 나뉜다. 둘 다 매우 유용하지만, 다른 사람의 지식을 가져오고 여러 사람이 같은 시스템을 쓰기 때문에 보안 문제가 본질적으로 따라붙는다.
8. 9:50
   만들지 말고, 키워라 회사의 지식 체계는 중앙에서 한 번에 ‘완성’하는 프로젝트가 아니라, 각 업무 담당자가 자기 몫을 계속 보태며 성장시켜야 한다. 따라서 회사 브레인은 구축하는 것이 아니라 성장시키는 것이며, 조직 전체가 함께 형성해야 한다.
9. 11:09
   보안 질문서를 끝까지 자동으로 처리한 사례 이메일로 받은 security questionnaire를 회사 브레인이 읽고, 과거의 보안 정보와 연결해 답변 초안을 만든 뒤 실제 발송까지 이어지는 흐름이 예시로 나온다. 이 사례는 한 사람이 만든 지식이 다른 사람의 업무를 바로 돕는 전형적인 회사 브레인 활용을 보여준다.
10. 12:33
    왜 누구도 GitHub에 공유 스킬을 쓰지 않는가 공유 지식을 GitHub에 수동으로 남기게 하는 방식은 현실적으로 거의 작동하지 않는다. 사람들은 자기 업무도 겨우 정리하는데, 모르는 타인의 미래 사용을 위해 별도 문서를 작성하는 데 시간을 쓰지 않기 때문이다.
11. 13:52
    팀 브레인도 결국 또 하나의 사일로다 소규모 팀이 함께 쓰는 AI가 메모리를 자동 저장해도, 그 범위가 채널이나 팀 안에 묶이면 결국 또 다른 사일로가 된다. 회사 전체에서 재사용되지 못하면, 규모만 작은 하나의 울타리에 갇힌 지식 저장소에 그친다.
12. 14:59
    하나의 위키, 범위가 정해진 파일, 그리고 무음 쓰기 금지 해결책은 모든 컨텍스트를 하나의 공유 위키에 모으고, 각 파일에 읽기·쓰기 스코프를 부여하는 것이다. 특히 에이전트가 내용을 몰래 자동 추가하지 못하게 하고, 변경 제안만 만들게 한 뒤 사람이 승인하도록 해야 신뢰성과 통제가 동시에 확보된다.
13. 18:45
    모든 변경에는 인간의 이름이 붙어야 한다 위키에 들어간 지식은 반드시 특정 인간의 이름으로 추적 가능해야 하며, AI 이름만 남는 기록은 허용되지 않는다. 그래야 누가 어떤 정보 공개를 허용했는지 책임을 묻고, 필요하면 권한 회수나 개선 조치를 할 수 있다.
14. 20:06
    논쟁 그 자체가 지식이 되는 멀티플레이어 사례 여러 사람이 같은 문제를 두고 토론하고 반박하는 과정에서 가장 질 좋은 지식이 만들어진다. 단순한 답변보다, 왜 이런 기술 결정을 했는지와 무엇이 잘못됐는지를 함께 남길 때 회사 브레인이 실제로 강해진다.
15. 23:17
    권한 상승과 샌드박스 밖의 자격 증명 공유 AI가 디버깅과 배포를 동시에 할 수 있으면 권한 상승 위험이 커져서, 샌드박스 안에 자격 증명을 저장해서는 안 된다. HTTP나 SQL 레이어에서 사용자의 자격 증명을 주입해 실제 인간처럼 동작하게 하고, 도구 접근 권한도 사용자 기준으로 통제해야 한다.

실무 인사이트

• 회사 브레인은 문서 저장소가 아니라 권한이 연결된 지식 운영체제로 설계해야 하며, 자동 기록보다 사람 승인 흐름이 우선이다.
• 검색·메모리·도구 실행을 분리하지 않으면 기밀 유출과 권한 상승이 쉽게 발생하므로, 컨텍스트와 실행 계층을 함께 설계해야 한다.
• 실무에서는 위키 통합, 스코프 설정, 인간 책임자 명시만으로도 공유 AI의 도입 가능성이 크게 올라간다.