[한영자막] 사내 AI는 결국 회사 기밀을 유출합니다: 대형 은행에서 이를 막아낸 방법

한 줄 핵심

사내 AI가 기밀을 새지 않게 하려면 거대한 지식베이스를 한 번에 만들기보다, 전사 위키와 권한 제어를 중심으로 컨텍스트와 도구 실행을 분리해 유기적으로 성장시키는 설계가 필요하다.

시간별 요약

1. 0:00
   사내 AI에서 비밀이 유출되는 이유와 전사 도입의 걸림돌 사내 AI를 전사적으로 풀면 신입 사원도 민감한 정보에 접근하는 상황이 생길 수 있어 보안 우려가 가장 큰 도입 장벽이 된다. 회사 브레인을 만들수록 기밀 유출 위험이 커진다는 점이 핵심 문제로 제기된다.
2. 0:54
   Hasura GraphQL 엔진에서 PromptQL로의 여정 Hasura GraphQL 엔진을 만들며 데이터 접근과 보안 문제를 다뤄온 경험이 PromptQL의 출발점이 되었다. Apple, Meta, JP Morgan 등 다양한 환경에서의 배포 경험이 이후 설계의 기반이 된다.
3. 1:50
   스타트업부터 은행까지, 세 가지 고객 유형과 니즈 AI 네이티브 회사, 기술 수용성이 높은 회사, 강한 보안 규칙을 가진 대형 은행은 서로 다른 도입 기준을 가진다. 특히 은행 환경에서는 바이브 코딩된 에이전트가 아무 제약 없이 작동하는 것을 허용할 수 없다는 보안 요구가 강하게 드러난다.
4. 3:02
   사내 두뇌 모델링과 5,000개 링크 페이지 구축 회사 브레인은 GitHub의 마크다운 파일 묶음, 지식 그래프, 위키 등 여러 형태로 구현할 수 있지만, 실제로는 약 5,000개의 서로 연결된 페이지로 운영된다. 중요한 것은 저장 형식보다 서로 연결된 지식을 어떻게 계속 축적하느냐이다.
5. 3:28
   건강한 지식 업데이트 곡선은 무엇인가 회사 브레인이 잘 작동하면 업데이트가 초기에만 몰리지 않고 매일 꾸준히 발생하는지 살펴봐야 한다. 단발성 구축 후 방치되는 방식보다 지속적으로 학습과 갱신이 일어나는 구조가 건강한 신호로 제시된다.
6. 5:04
   예상을 깨고 매일 꾸준히 우상향하는 업데이트 곡선 실제 운영 데이터에서는 일일 업데이트 수가 시간이 갈수록 완만하게 증가하는 모습이 관찰된다. 시스템이 유용해질수록 사람들이 더 많이 가르치고, 작은 학습들이 누적되면서 전체 곡선이 우상향한다.
7. 6:24
   사내 두뇌의 두 가지 활용: 개인 지식 검색과 협업 AI 회사 브레인의 첫 번째 활용은 보안 질의서처럼 개인 업무를 돕는 지식 검색이고, 두 번째는 Slack 같은 공간에서 여러 사람이 함께 쓰는 협업형 AI다. 두 방식 모두 공유 지식이 늘어날수록 보안 통제가 더 중요해진다.
8. 9:38
   거대하게 짓지 말고 유기적으로 키워나가라 100년 된 조직에 중앙집중식 회사 브레인을 한 번에 완성하겠다는 접근은 비현실적이다. 각 사람이 자신의 업무 일부를 책임지고 그 부분을 스스로 키워가며 브레인을 성장시키는 방식이 맞다.
9. 10:56
   보안 질의서 실전 답변 시연: AI가 알아서 초안 작성 실제 이메일과 보안 온보딩 문서를 바탕으로 AI가 질의서 초안을 만들고, 사용자는 이를 검토한 뒤 바로 발송할 수 있다. 다만 이 흐름이 가능하려면 이전에 다른 사람이 만든 지식이 안전하게 공유되어 있어야 한다.
10. 12:20
    GitHub 공유 스킬을 아무도 작성하지 않는 현실적인 이유 사람들이 다른 사람을 위해 GitHub에 공유 스킬을 꾸준히 작성해 줄 것이라는 기대는 현실적이지 않다. 개인이 자기 문맥도 정리하기 어려운데, 남을 위해 별도 저장소에까지 기록하는 일은 자연스럽지 않다.
11. 13:40
    팀 단위 격리 두뇌가 결국 또 다른 사일로가 되는 이유 팀 단위로만 공유되는 메모리나 채널별 기억은 편해 보여도 결국 또 하나의 고립된 사일로가 된다. 한 채널 안에서는 작동해도 전사적으로 재사용되지 못하면 회사 브레인이라는 목표에는 도달하지 못한다.
12. 14:46
    전사 단일 위키, 파일별 권한 제어, 자동 쓰기 금지 원칙 모든 컨텍스트를 하나의 공유 위키에 모으고, 각 파일마다 읽기·쓰기 스코프를 분리해야 한다. 에이전트가 내용을 자동으로 써 넣게 두지 말고, 제안을 사람이 승인하는 구조가 보안과 운영성의 균형점이다.
13. 18:32
    모든 변경 사항에 사람의 이름과 책임을 남겨라 위키에 들어간 모든 변경은 반드시 사람 이름으로 귀속되어야 하며, AI가 수정 주체로 남아서는 안 된다. 그래야 책임 추적이 가능하고, 잘못된 정보가 퍼졌을 때 후속 조치를 취할 수 있다.
14. 19:54
    멀티플레이어 환경: 치열한 토론 속에서 탄생하는 진짜 지식 여러 사람이 동시에 문제를 파고들며 토론할 때 가장 질 높은 컨텍스트가 만들어진다. 서로 다른 판단이 충돌하고 검증되는 과정에서 문서화할 가치가 높은 실제 원인과 수정 원칙이 도출된다.
15. 23:04
    권한 상승 방지: 샌드박스 외부에서 주입하는 사용자 자격 증명 에이전트가 실행 도구를 쓸 때도 자격 증명은 샌드박스 안에 저장하지 말고 HTTP나 SQL 계층에서 사용자 자격 증명을 주입해야 한다. 이렇게 해야 읽기와 실행이 모두 사용자의 권한 범위 안에서만 동작하며, 권한 상승 위험을 줄일 수 있다.

실무 인사이트

• 전사 AI의 핵심은 ‘무엇을 답하게 할까’보다 ‘어떤 문맥을 누구 권한으로 읽고, 어떤 도구를 어떤 자격으로 실행할까’를 먼저 설계하는 것이다.
• 지식 축적은 중앙에서 대량 수집하는 방식보다, 각 업무 담당자가 제안을 검토·승인하는 흐름으로 만들어야 지속된다.
• 보안이 중요한 조직일수록 자동 쓰기보다 인간 승인, 역할 기반 스코프, 실행 시점 자격 증명 주입이 필수이다.