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

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

사내 AI의 기밀 유출을 막기 위해, 발표자는 대형 은행 배포 경험을 바탕으로 지식 저장에는 사람의 승인과 접근 범위를, 조회·도구 실행에는 사용자별 권한을 적용하는 구조를 제안한다.

📌 핵심 요점

1. 회사 지식을 모으는 것만으로는 충분하지 않다. 신입 직원이 다른 직원의 보상 정보를 읽는 상황처럼, 공유 지식과 공유 AI 모두에서 권한 경계가 무너질 수 있다.
2. ‘회사 두뇌’는 공유 맥락과 데이터·도구 접근 규칙을 코딩 에이전트에 제공하는 체계다. 발표자는 전사 지식을 한 번에 구축하기보다 각 구성원이 자신의 업무 지식을 보태며 성장시키자고 제안한다.
3. 지식은 서로 연결되는 전사 위키에 모으되, 페이지별 읽기·쓰기 범위를 둔다. 에이전트는 저장할 사실과 접근 범위를 제안하고, 사람이 확인해 승인하거나 거절한다.
4. 모든 변경에는 책임지는 사람의 이름이 남아야 하며, 에이전트가 위키를 읽을 때마다 해당 사용자의 자격 증명과 권한 정보를 적용해야 한다.
5. 여러 사람이 함께 쓰는 AI는 도구 실행에서도 요청자의 권한으로 동작해야 한다. 샌드박스에 자격 증명을 저장하지 않고, HTTP·SQL 계층에서 사용자 자격 증명을 주입하며 실제 데이터 접근을 프록시로 통제하는 방식이다.

🧩 배경과 문제 정의

발표자는 사내 지식을 AI가 활용하는 ‘회사 두뇌’의 가장 큰 우려로 기밀 유출을 제시한다. 다른 직원의 보상 정보가 신입 직원에게 노출되는 사례처럼, 정보를 모으고 공유하는 과정에서 기존 접근 경계가 사라질 수 있다는 문제다.

발표팀은 데이터 접근 문제를 다뤄 온 경험과 약 15~20개 협력 대상과의 작업을 소개하며, 보안 요구가 높은 은행 환경에도 초기 형태의 회사 두뇌를 배포했다고 설명한다. 자체 환경에서는 약 5,000개의 연결된 위키 페이지를 사용한다. 다만 본문은 특정 은행의 사고 차단 사례보다 지식 축적과 도구 실행을 통제하는 설계 원칙에 초점을 맞춘다.

핵심 과제는 구성원이 각자의 업무에서 얻은 지식을 전사적으로 재사용하게 하면서도, 누가 무엇을 읽고 변경하며 실행할 수 있는지 유지하는 것이다. 발표자는 이를 공유 지식 활용과 공동 AI 사용이라는 두 가지 사례로 나누어 설명한다.

🕒 시간순 섹션별 상세정리

1. 회사 두뇌가 만드는 기밀 유출 위험

• 발표자는 사내 AI가 회사 기밀을 유출할 가능성을 제기하고, 신입 직원이 전 직원의 보상 정보를 알게 되는 상황을 예로 든다. 이런 우려가 OpenClaw와 Hermes 같은 에이전트의 광범위한 배포를 가로막는다고 보여준다. [00:33]
• 발표팀은 데이터 접근 문제를 다뤄 온 배경과 대기업 배포 경험을 보여준다. 이는 이후 보안 설계를 설명하는 경험적 배경으로 드러난다. [01:31]

2. 서로 다른 도입 환경과 자체 위키 규모

• 약 1년 동안 규모 측면의 특성이 있는 15~20개 협력 대상과 작업했으며, AI 중심 기업·기술 도입에 적극적인 기업·보안 요구가 높은 은행의 요구를 구분한다. 은행에도 초기 형태의 회사 두뇌를 배포했다고 드러낸다. [02:49]
• 자체 회사 두뇌는 약 5,000개의 연결된 페이지로 구성된 위키다. 저장 형태로 마크다운 파일이나 지식 그래프 등도 가능하다고 보여준다. [03:16]

3. 건강한 지식 체계의 업데이트 흐름

• 회사 두뇌의 일일 업데이트가 감소할지, 일정한 수준에서 변동할지, 계속 늘어날지를 청중에게 묻는다. 초기에만 지식을 수집하고 이후 관심이 사라지는 경우도 비교 대상으로 제시한다. [04:50]
• 자체 약 두 달 기록에서는 일일 업데이트가 완만하게 증가했다. 시스템이 유용해지면 구성원이 데이터 조회 다음에 해석과 행동 방법을 가르치는 식으로 지식을 더 보탠다는 해석이다. 다만 장기 지속 여부는 아직 모른다고 인정한다. [06:14]

4. 공유 지식과 공유 AI라는 두 사용 사례

• 첫 번째는 개인 에이전트가 회사 지식을 활용하는 경우다. 고객에게 받은 보안 질문지에 답하기 위해 다른 구성원이 축적한 지식을 찾는 작업이 예시다. [06:59]
• 두 번째는 여러 사람이 같은 AI와 협업하는 경우다. 공동 장애 대응에서 로그 확인, 코드 조사, PR 작성, 배포, 알림 설정까지 이어지는 흐름을 제시하며 두 사례 모두 보안 문제가 크다고 보여준다. [07:52]

5. 회사 두뇌의 구성 요소 정의

• 발표자는 회사 두뇌를 공유 맥락과 데이터·도구 접근 제어 규칙을 코딩 에이전트에 제공하는 체계로 정의한다. 마크다운 파일은 공유 맥락을 담는 형태로 드러난다. [08:18]
• 코딩 에이전트가 범용 업무를 해결할 수 있다는 관점에서 필요한 지식을 제공하려는 접근이다. 거대한 전사 지식 기반을 먼저 만든 뒤 보안을 붙이는 방식에는 회의적인 견해를 드러낸다. [09:24]

6. 각자의 업무에서 회사 지식을 성장시키기

• 오래된 대기업 전체의 지식을 장기 프로젝트로 한 번에 구축하려는 접근은 현실적이지 않다고 주장한다. 각 구성원이 자신이 수행하는 업무에 해당하는 부분을 소유하고 발전시키자고 제안한다. [10:12]
• 이를 회사 두뇌를 ‘성장시키는’ 방식으로 표현하며, 구성원이 자신의 지식을 직접 보탤 수 있는 흐름을 강조한다. [10:41]

7. 보안 질문지 답변과 지식 전달의 문제

• 시연에서는 고객 이메일의 보안 질문을 읽고 회사 지식을 활용해 답변 초안을 작성한다. 사용자가 초안을 확인하고 발송을 지시하자 이메일을 보낸다. [11:42]
• 이어서 다른 사람이 이전에 해결한 질문에서 얻은 지식이 현재 사용자의 에이전트에 어떻게 전달될 수 있는지 묻는다. 개인 메모리나 스킬에 남은 지식을 공유하는 경로가 필요하다는 문제다. [12:21]

8. 수동 스킬 공유와 팀별 기억의 한계

• 첫 대안은 구성원이 GitHub의 공유 스킬을 직접 갱신하는 것이다. 발표자는 본업을 마친 뒤 미래의 다른 사용자를 위해 별도 문서를 작성하는 부담 때문에 참여가 지속되기 어렵다고 본다. [13:35]
• 두 번째 대안인 팀별 공유 에이전트는 기억을 자동으로 쌓을 수 있지만, 팀이나 채널 안에 또 하나의 지식 저장소를 만들 수 있다. 해당 채널 밖에서는 지식을 활용하기 어렵다는 한계를 지적한다. [14:40]

9. 전사 위키와 페이지별 접근 범위

• 세 번째 대안은 모든 공유 맥락을 서로 연결되는 하나의 위키에 모으는 것이다. 각 파일에는 누가 읽고 쓸 수 있는지를 정하는 접근 범위를 부여한다. [15:21]
• 에이전트가 메모리를 곧바로 저장하게 하지 않고, 추가할 내용과 접근 범위를 제안하도록 한다. 사람은 제안을 승인하거나 거절한다. [16:06]

10. 업무 중 사실과 범위를 확인하는 승인 경험

• 발표자는 수동 PR 작성보다 가볍게 검토할 수 있는 흐름을 보여준다. 재무 정보에는 재무 범위를, 개인 정보에는 개인 범위를 적용하는 식으로 공유자가 범위를 확인한다. [16:53]
• 이메일 업무 뒤 추가할 사실을 짧은 목록으로 보여주는 시연을 보여준다. 사용자는 사실의 정확성과 페이지별 범위를 검토하고, 파일 배치와 연결은 에이전트가 처리한다. [18:19]

11. 변경 책임과 조회 시 사용자 권한 적용

• 전사 위키에 모으는 원칙과 함께 모든 변경에 사람의 이름을 남기는 원칙을 강조한다. ‘AI가 추가했다’는 기록만으로 끝내지 않고, 잘못된 공개가 발생했을 때 책임자를 추적할 수 있어야 한다는 설명이다. [18:59]
• 에이전트는 위키를 읽을 때마다 해당 사용자의 자격 증명과 권한 정보를 사용한다. 재무 위키에 접근할 수 있는 사용자를 대신해 읽는 구조를 예로 든다. [19:43]

12. 공동 장애 조사에서 학습 후보 얻기

• 여러 사람이 서로 다른 권한으로 같은 AI와 문제를 해결하는 상황은 더 복잡하지만, 많은 업무 지식이 만들어지는 지점이라고 보여준다. [20:24]
• 위키 학습 기능의 장애 조사에서 관측 데이터의 스팬 이름을 알려주고, 느린 LIKE 조회를 동등 비교 조회로 바꾸도록 지시한 사례를 보여준다. 에이전트는 조사 중 얻은 교훈을 저장 후보로 제안한다. [21:38]

13. 토론으로 관찰을 설계 지식으로 바꾸기

• 다른 사람이 대화에 합류해 기존 기술 결정을 문제 삼으면서, 문서화되지 않았던 결정과 오류 원인이 드러난다. 페이지 이름의 접두사를 제거하는 방향으로 논의가 발전해진다. [22:16]
• 단순히 ‘접두사가 있다’는 사실보다 ‘접두사가 조회 문제를 일으키므로 없어야 한다’는 해결 맥락이 더 유용한 지식이 된다고 보여준다. 공동 문제 해결이 높은 품질의 맥락을 만든다는 주장이다. [22:49]

14. 공유 에이전트의 권한 상승 위험

• 코드 수정 권한이 있는 사람이 같은 에이전트를 통해 운영 배포까지 할 수 있다면 위험하다. 특히 은행에서는 디버깅·스테이징 배포·알림 설정·운영 배포의 담당자가 같지 않다고 보여준다. [23:29]
• 해법으로 지식 조회뿐 아니라 도구 실행에도 사용자의 자격 증명을 적용하자고 제안한다. 자격 증명은 샌드박스에 저장하지 않고 HTTP·SQL 계층에서 주입해, 각 상호작용에서 AI가 해당 사용자 권한으로 동작하게 한다. [24:01]

15. 실제 데이터 접근을 통제하는 설계 원칙

• 실행 환경에 자격 증명을 저장하지 않는 원칙과, 실제 데이터와의 상호작용을 프록시 등으로 통제하는 원칙을 정리한다. 도구를 추가하는 사용자가 그 도구의 접근 대상을 통제하도록 한다. [24:35]
• 앞서 제시한 지식 관리 원칙과 도구 접근 원칙을 출발점으로 맥락·도구·보안 규칙을 설계하라고 마무리한다. [24:49]

16. 제품 소개와 여러 모델을 활용하는 방향

• 발표자는 추가 논의와 제품 출시를 안내하고, 청중과 사진을 촬영하며 본 발표를 마친다. [25:33]
• 마지막에는 앞서 설명한 아이디어를 적용한 제품 방향을 소개하며 GLM과 GPT 등 여러 모델을 사용할 수 있다고 드러낸다. 감사 인사와 함께 종료한다. [25:52]

🧾 결론

• 전사 지식의 연결성과 접근 제한은 함께 설계해야 한다. 하나의 위키를 쓴다는 것은 모든 직원에게 같은 정보를 공개한다는 뜻이 아니다.
• 지식 축적의 핵심 절차는 ‘에이전트의 제안 → 사람의 사실·범위 확인 → 책임자 기록’이다. 업무 중 간단히 승인할 수 있어야 지속적으로 참여하기 쉽다.
• 공유 AI의 권한은 대화방이나 에이전트 전체에 고정하기보다, 지식 조회와 도구 실행을 요청하는 사용자에 맞춰 적용해야 한다.
• 발표는 은행 환경에도 배포했다고 설명하지만, 특정 은행에서 유출을 차단한 사건이나 검증 수치를 제시하지는 않는다. 제안된 설계 원칙과 입증된 보안 성과를 구분해 읽어야 한다.

📈 투자·시사 포인트

• 기업용 AI 도입을 평가할 때 모델 성능과 함께 지식 접근 통제, 사용자별 도구 권한, 변경 책임 추적을 살펴볼 필요가 있다. 발표에서는 보안 우려를 전사 확산의 주요 제약으로 제시한다.
• 금융기관처럼 디버깅·스테이징 배포·운영 배포의 담당자가 다른 조직에서는, 협업 흐름을 유지하면서 권한을 분리하는 기능이 중요한 제품 평가 기준이 될 수 있다.
• 사용자가 업무 중 지식을 쉽게 검토하고 공유하는 경험은 지속적인 활용과 연결될 수 있다. 다만 발표자의 일일 업데이트 증가 사례만으로 고객 유지율이나 매출 성장을 추정할 수는 없다.
• 발표 말미에는 여러 모델을 활용하는 제품 방향을 소개한다. 이를 평가할 때는 모델 선택 폭뿐 아니라 모델이 바뀌어도 접근 통제 원칙이 유지되는지 확인필요가 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 제목은 기밀 유출과 은행에서의 차단 성과를 단정적으로 표현하지만, 본문은 유출 가능성과 방어 구조를 설명한다. 은행명, 차단 사건, 공격 실험, 유출률 등 성과 검증 자료는 제공되지 않는다.
• 일일 지식 업데이트 증가 관찰은 발표자 조직의 약 두 달 기록에 기반한다. 발표자도 초기 현상이며 향후 증가세가 둔화할 수 있다고 말한다.
• 사람의 승인과 페이지별 권한이 잘못 설정되었을 때의 예방·복구 절차, 이미 대화에 들어온 민감 정보의 처리 방식은 상세히 설명되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 사내 AI 사용 사례를 개인의 공유 지식 활용과 여러 사람의 공동 에이전트 사용으로 나누고, 각각 노출 가능한 정보와 실행 가능한 도구를 정리한다.
• 위키 페이지별 읽기·쓰기 범위와 책임자를 정의하고, 재무·개인 정보가 적절한 범위로 저장되는지 확인한다.
• 에이전트가 저장할 사실과 접근 범위를 먼저 제안하도록 구성하고, 사람이 승인한 변경에 승인자 이름을 남긴다.
• 위키 조회마다 실제 요청자의 자격 증명과 권한 정보가 적용되는지, 권한이 다른 사용자로 확인한다.

❓ 열린 질문

• 여러 권한 수준의 사용자가 한 대화에 참여할 때, 민감한 조회 결과를 누구에게 보여줄지 어떻게 결정하는가?
• 잘못 승인된 지식이나 과도하게 넓은 접근 범위를 발견하면, 이미 재사용된 내용까지 어떻게 추적하고 수정하는가?
• 업무 중 승인 절차가 형식적인 확인으로 흐르지 않으면서도 참여 부담을 낮추려면 어떤 검토 화면과 책임 분담이 필요한가?