엔터프라이즈 클라이언트 사무실에서 보안팀장과 디자인팀장이 같은 테이블에 앉아 서로를 바라보지 않던 날이 있었습니다. 주제는 M365 Copilot 도입이었고, 두 사람의 입장은 처음부터 평행선이었습니다. 그 자리에서 저는 디자이너가 왜 회의실에 있어야 하는지를 몸으로 배웠습니다.
보안팀과 디자인팀, 같은 도구를 두고 싸우는 이유
M365 Copilot은 Microsoft 365 생태계에 자연어 AI 어시스턴트를 결합한 서비스입니다. 쉽게 말해 Word, Excel, Teams, Outlook 같은 업무 도구 안에서 "이 보고서 요약해줘", "이 이메일에 답장 써줘" 같은 명령을 자연어로 처리해주는 기능입니다. 겉으로 보면 생산성 도구지만, 조직 내부 데이터를 학습 맥락으로 참조한다는 점에서 보안팀 입장에서는 민감한 사안입니다.
제가 직접 겪어보니, 두 팀의 갈등은 도구에 대한 이해 차이라기보다 우선순위의 차이였습니다. 보안팀은 데이터 거버넌스(Data Governance)를 먼저 세워야 한다고 했고, 디자인팀은 그게 뭔지도 모르겠고 일단 쓰면서 맞춰가자는 입장이었습니다. 여기서 데이터 거버넌스란 조직이 보유한 데이터를 누가, 어떤 목적으로, 어디까지 접근할 수 있는지 규칙과 책임을 정해두는 체계를 말합니다. 이게 없으면 Copilot이 인사 데이터를 영업팀에 노출하거나, 보안 등급이 다른 파일을 AI가 무심코 요약해 공유하는 사고가 실제로 발생합니다. 저희 클라이언트에서는 제가 이 프로젝트를 시작하기 전 분기에 이미 한 건 있었습니다.
3주 만에 합의에 이른 매트릭스 워크숍
솔직히 이건 예상 밖이었습니다. 워크숍을 준비할 때 저는 두 팀이 적어도 두 달은 싸울 거라 생각했거든요. 그런데 데이터 영역, 기능, 접근 권한 세 축으로 구성한 매트릭스 한 장이 분위기를 바꿨습니다.
핵심 구조는 이렇습니다.
- 데이터 영역: 인사, 재무, 고객, 내부 운영 등 카테고리 분류
- 기능: Copilot이 수행할 수 있는 작업 유형(요약, 초안 작성, 데이터 분석 등)
- 접근 권한: 역할 기반 접근 제어(RBAC) 기준으로 팀·직급별 허용 범위 설정
여기서 RBAC(Role-Based Access Control)이란 사용자의 역할에 따라 시스템 접근 권한을 다르게 부여하는 방식입니다. 예를 들어 인사팀 직원은 급여 데이터에 접근할 수 있지만 영업팀 직원은 같은 데이터를 볼 수 없도록 제한하는 구조입니다. 이 개념을 매트릭스에 시각화하자 보안팀도 "이 범위면 허용 가능하다"는 말이 나왔고, 디자인팀도 "이 기능은 쓸 수 있는 거구나"를 명확히 확인했습니다. 언어가 달라서 싸우던 두 팀이, 같은 그림을 보면서 처음으로 같은 말을 했습니다.
이후 외주 두 건에서 동일한 워크숍 템플릿을 재사용했을 때 평균 합의 도달 시간이 6주에서 2주로 줄었습니다. 제 경험상 이건 도구의 힘이 아니라 시각화된 구조가 사람의 대화 방식을 바꾸는 힘입니다. 디자인이 갈등의 통역자라는 말을 저는 이 프로젝트에서 다시 확인했습니다.
한국 기업 환경에서는 한 가지가 더 필요합니다. 임원 보고 톤 문제입니다. Copilot이 생성한 문서를 그대로 경영진 보고에 올렸다가 "이게 무슨 말이냐"는 피드백이 돌아오는 경우가 생각보다 많습니다. 한국의 결재 문화는 보고서의 어조와 구조에 민감하기 때문에, 임원 보고 전용 프롬프트 라이브러리를 별도로 운영하지 않으면 Copilot이 오히려 일을 늘리는 도구가 됩니다.
합의 이후가 더 중요한 분기 거버넌스 운영
M365 Copilot을 도입한 조직에서 제가 직접 써봤는데, 도입 첫 달에 모든 에너지를 쏟고 두 달째부터 아무도 관리하지 않는 패턴이 반복됩니다. 그 결과는 분기당 한 건 이상의 데이터 사고로 이어집니다. 이건 제 추측이 아니라 실제 운영 경험에서 나온 수치입니다.
그래서 저는 매 분기 세 가지 축으로 구성된 리뷰를 정기 공유합니다.
- Copilot 신규 기능 업데이트 반영 여부 — Microsoft는 Copilot 기능을 꾸준히 업데이트하므로, 기존 RBAC 설정이 새 기능과 충돌하지 않는지 점검합니다.
- 임원 보고 톤 적합도 측정 — 프롬프트 라이브러리의 실사용 피드백을 모아 어조 기준을 조정합니다.
- 데이터 거버넌스 사고 건수 집계 — 아차 사고 포함 전체 이슈를 트래킹합니다.
이 구조를 유지하면 단순 도구 도입이 아니라 지속 가능한 디자인 자산으로 정착됩니다. 외주 클라이언트에게도 이 분기 보고서를 정기 제공하는데, 클라이언트 입장에서는 "AI 도입했더니 관리가 더 많아졌다"는 인상 대신 "거버넌스가 살아있다"는 신뢰감을 받는다고 합니다.
한국 개인정보보호법 적합성도 이 리뷰 사이클에 포함해야 합니다. 개인정보보호법은 개인을 식별할 수 있는 정보의 수집, 처리, 보관 방식에 대해 구체적인 의무를 부과하는 법률로, AI가 업무 데이터를 학습 맥락으로 참조하는 Copilot 환경에서는 적용 범위가 생각보다 넓습니다. 실제로 개인정보보호위원회는 AI 서비스의 개인정보 처리 기준을 지속적으로 정비하고 있습니다(출처: 개인정보보호위원회). Microsoft 역시 M365 Copilot의 데이터 처리 방식과 컴플라이언스 기준을 공식 문서로 공개하고 있으므로, 도입 전 이 내용을 확인하는 것이 필수입니다(출처: Microsoft Learn).
정리하면 한국 기업 환경에서 M365 Copilot을 안전하게 운영하려면 임원 보고 톤 프롬프트 라이브러리, 데이터 거버넌스 매트릭스, 그리고 개인정보보호법 적합성 운영 표준 세 가지를 묶어 다뤄야 합니다. 이 세 가지 중 하나라도 빠지면 나머지 두 개가 온전히 작동하지 않습니다.
Copilot은 충분히 좋은 도구입니다. 그런데 "좋아 보여서" 도입한 조직과, 갈등을 조율하고 거버넌스를 설계하고 분기마다 리뷰를 돌린 조직의 1년 후 모습은 제 경험상 완전히 다릅니다. 도구보다 구조가 먼저입니다. 지금 도입을 검토 중이라면 워크숍 설계부터 시작하는 것을 권합니다.