서론 — 전사 도입은 라이선스 추가만으로 진행되지 않는다

우리는 기업의 DX(디지털 전환) 및 생성형 AI 활용을 지원하면서, 자사에서도 Notion / Notion AI를 전사의 업무 기반으로 활용하고 있습니다.

Notion을 전사로 확대하려는 DX 추진 담당자나 정보시스템(情シス) 담당자가 직면하는 문제는 기능의 사용법보다는, 누구에게, 어떤 정보를, 어디까지 공개할 것인가라는 설계의 문제입니다. 일부 팀에서의 이용과는 달리, 전사 전개에서는 멤버와 게스트, 전사 공통 정보와 기밀 정보, 사내 이용과 외부 공유의 경계를 결정해야 합니다.

하지만 통제를 강화한다고 해서 반드시 안전해지는 것은 아닙니다. 중요한 것은 필요한 경계를 설정한 후, 그 안쪽에서는 현장이 유연하게 사용할 수 있는 상태를 만드는 것입니다.

본 기사에서는 Notion / Notion AI의 전사 도입을 추진하는 담당자를 위해 플랜, Teamspace, 권한, 외부 공유, 커넥터, 일상 운영의 판단 기준을 정리합니다.

그림 1: 일부 이용에서 전사 이용으로 넘어갈 때 변하는 것

1. 우선, 도입 범위와 목표를 결정한다

거버넌스(Governance)의 구체적인 대책을 검토하기 전에, 누가, 어떤 업무로, 어디까지 Notion을 사용할 것인지를 결정합니다. 이 부분이 모호한 상태에서는 필요한 플랜도 권한도 평가할 수 없습니다.

「전사 도입」의 범위를 정의한다

전사 도입은 첫날부터 모든 직원에게 일제히 전개하는 것과 동일한 의미가 아닙니다. 대상 부서, 이용 인원, 다루는 정보, 대상 업무를 나누어 단계적으로 확대하는 방법도 있습니다.

우선, 적어도 다음 사항을 명문화합니다.

• 대상 부서 및 사용자
• Notion으로 다루는 업무
• Notion에 두는 정보와 기존 시스템에 남길 정보
• 초기 도입 후 이용 범위를 확대하는 조건
• 도입 효과를 평가하는 지표와 판단자

Notion에 집약할 정보와 집약하지 않을 정보를 결정한다

Notion을 전사에서 사용한다고 해서 모든 데이터를 Notion으로 옮길 필요는 없습니다.

CRM, 회계, 인사, 소스 코드 관리 등 전용 시스템이 공식적인 원천(Source of Truth)인 정보는 해당 시스템을 정본(正本)으로 유지합니다. Notion에는 참조 링크, 판단 경위, 회의의 맥락, 다음 액션 등 사람이 읽고, 생각하고, 행동하기 위한 정보를 남깁니다.

동일한 정보를 여러 장소에서 업데이트하는 구조는 정보의 신선도와 책임 소재를 무너뜨립니다. 정보마다 정본을 하나로 결정하는 것이 AI가 오래된 복사본을 참조하지 않게 하기 위해서도 중요합니다.

스몰 스타트(Small Start) 이후의 확대 조건을 결정한다

소수 인원으로 시작하는 경우에는 시작 인원뿐만 아니라 그 이후의 확대 로드맵까지 설계합니다.

조직이 클수록 아주 일부의 이용만으로는 업무 효과나 ROI(투자 대비 효율)를 파악하기 어렵습니다. '우선 테스트한다'에서 멈추지 않고, 언제, 무엇을 평가하며, 어떤 조건을 만족했을 때 대상 부서나 라이선스를 늘릴 것인지를 도입 전에 관계자들 사이에서 합의해 두어야 합니다.

그림 2: 스몰 스타트에서 이용 범위를 넓히는 사이클

2. 플랜은 「사용하고 싶은 기능」이 아니라 「필요한 통제」로 선택한다

플랜 선정 시에는 편리한 기능의 개수뿐만 아니라, 전사 운영에 필요한 관리 및 통제 기능을 기준으로 삼습니다.

필요한 관리 기능을 먼저 나열한다

검토 항목의 예는 다음과 같습니다.

• 도메인 및 워크스페이스 참여 관리
• 계정 발행·변경·삭제
• SSO / SCIM 등에 의한 ID 관리
• 감사 로그 (Audit Log)
• 데이터 보존 및 내보내기 (Export)
• 게스트 초대 및 웹 공개 제어
• Teamspace 및 페이지 권한 관리
• AI 및 커넥터 관리

이 중 현재 시점에서 필수적인 것과 조직 확대 시 필요해질 것을 구분합니다.

Enterprise가 필요해지는 조건을 생각한다

Enterprise를 선택하는 이유는 단순히 고도화된 기능을 사용하고 싶어서만은 아닙니다. 사용자 관리, 감사, 데이터 보존, 도메인 관리 등 전사 규모에서 필요해지는 통제 수단을 확보하는 것이 주요 판단 자료가 됩니다.

반면, Enterprise를 계약했다고 해서 SSO / SCIM이나 고도화된 모니터링을 첫날부터 모두 구현할 필요는 없습니다. 필요한 선택지를 확보하면서, 구현은 리스크와 비용 대비 효과에 따라 단계적으로 진행합니다.

3. 이용자와 정보의 경계로부터 Teamspace를 설계한다

Teamspace는 조직도를 그대로 재현하기 위한 것이 아닙니다. 누가 이용하는가, 어디까지 공개하는가, 외부 공유가 있는가라는 경계를 구조로서 나타내기 위해 설계합니다.

우선, 멤버와 게스트를 나누어 생각한다

직원 등 지속적으로 워크스페이스를 이용하는 멤버와 고객·파트너 등 특정 페이지 만을 열람하는 게스트는 액세스 권한을 주는 영역을 분리합니다.

멤버: 사내 업무 기반으로서 지속적으로 이용하는 사용자
게스트: 특정 안건이나 공유물에 한해서만 액세스하는 사용자

게스트에게 사내 공통 DB나 사내 지식(Knowledge)으로 향하는 경로를 제공하지 않는 것이 기본입니다. 외부 공유 가능성이 있는 정보는 사내 정보와 같은 장소에 둔 뒤 권한으로 분리하는 것이 아니라, 처음부터 배치 장소를 분리합니다.

전사 공통 정보는 일반 Teamspace로 집약한다

모든 멤버가 공통적으로 참조하는 규칙, 가이드, 온보딩 정보, 공통 DB, 템플릿 등은 일반 Teamspace로 집약합니다.

목적은 모든 사람이 봐도 좋은 정보의 위치를 명확히 하고, 동일한 DB나 규칙이 부서별로 복제되는 것을 방지하는 것입니다.

부문·프로젝트 고유 정보는 제한된 Teamspace에서 다룬다

특정 부문이나 프로젝트만이 다루는 정보는 필요한 멤버만 참여하는 Teamspace로 분리합니다.

단, Teamspace를 나눌 때마다 DB까지 복제하면 전사 집계와 유지보수가 어려워집니다. 데이터 구조와 권한을 공통화할 수 있는 경우에는 공통 DB를 기점으로 삼고, 각 Teamspace에는 필터링된 뷰(View)나 대시보드(Dashboard)를 배치합니다.

Teamspace를 나누는 주요 판단 기준은 다음과 같습니다.

기밀 정보는 일반적인 사내 영역에서 더욱 분리한다

인사, 계약, 경영, 고객 기밀 등은 일반 Teamspace나 통상적인 부문 영역에 혼재시키지 않고, 전용 영역과 최소 권한으로 관리합니다.

부문 정보는 해당 부문의 멤버가 통상적으로 이용하는 정보입니다. 반면, 기밀 정보는 동일 부문 내에서도 일부 인원만 액세스할 수 있는 정보입니다. 이 두 가지를 동일한 경계에서 다루지 않고, 필요에 따라 전용 DB나 페이지 단위의 액세스 제어(Access Control)를 조합합니다.

외부 협업은 전용 영역으로 한정한다

고객이나 파트너와의 공동 작업 시에는 외부 공유용 Teamspace 등에 공유 페이지를 집약하고, 게스트는 필요한 페이지에만 초대합니다.

• 게스트를 사내 일반 영역에 포함하지 않는다
• 외부 공유 페이지와 사내 전용 페이지를 동일한 계층에 두지 않는다
• 고객·안건별로 열람 범위를 나눈다
• 사내 DB와의 관계(Relation)나 부모-자식 구조를 부주의하게 연결하지 않는다

Teamspace는 부서의 수만큼 늘리는 것이 아니라, 이용자·공개 범위·기밀성·외부 공유의 경계가 바뀔 때 나누는 것이 기본입니다.

그림 3: 이용자와 정보의 경계 측면에서 본 Teamspace 구성

4. 외부 공유를 예외 운영으로서 통제한다

Teamspace로 내외부의 경계를 만든 후, 게스트 초대나 웹(Web) 공개 조건, 승인, 해제까지를 공통 규칙으로 정합니다.

외부로 나가는 출구를 한정한다

외부 공유는 워크스페이스 내 어디에서든 수행할 수 있는 상태로 두지 않습니다.

• 워크스페이스 전체 차원에서는 게스트 초대 및 웹 공개를 원칙적으로 제한한다
• 외부 공유를 허용하는 영역을 한정한다
• 외부로 내보내는 정보는 공개 전에 전용 영역으로 옮긴다
• 공유물은 페이지 단위로 열람 범위를 설정한다

이러한 구조를 통해 사내 DB에서 부주의하게 정보가 외부로 나가는 경로를 줄일 수 있습니다.

초대부터 해제까지 관리한다

외부 공유에는 시작 시점뿐만 아니라 종료 시점의 관리도 필요합니다.

• 누가 공유를 승인하는가
• 어떤 조건으로 게스트를 초대할 수 있는가
• 웹 공개를 허용하는 정보는 무엇인가
• 공유 기한을 어떻게 관리할 것인가
• 계약·프로젝트 종료 시 누가 권한을 해제하는가
• 잔존하는 게스트를 어느 빈도로 확인하는가

외부 공유를 단순히 '가능/불가능' 설정으로 끝내지 않고, 라이프사이클(Lifecycle)로서 설계합니다.

5. 권한은 '사람'과 'AI' 모두를 전제로 설계한다

Notion AI의 참조 범위도 원칙적으로 이용자가 액세스할 수 있는 정보의 범위에 기반합니다. 따라서 AI 전용의 복잡한 통제를 사후에 추가하기보다, 근간이 되는 정보의 권한을 올바르게 설계하는 것이 우선입니다.

권한은 필요 최소한부터 설계한다

모두에게 넓은 열람·편집 권한을 부여한 뒤 예외를 차단하는 것이 아니라, 업무상 필요한 사람에게 필요한 권한을 부여합니다.

• 정보군 전체를 분리할 경우, Teamspace나 DB 단위로 제어한다
• 레코드(Record)마다 열람자가 다른 경우, 페이지 단위로 제어한다
• 편집이 불필요한 사람에게는 열람 권한만 부여한다
• 권한 그룹이나 멤버 속성(Property)을 사용하여 개별 설정이 과도하게 늘어나는 것을 방지한다

AI가 참조할 정보의 공식성도 명시한다

액세스할 수 있다는 것과, 답변의 근거로서 우선시해야 하는 것은 별개입니다. AI가 올바른 정보를 참조하게 하려면 공식 버전과 초안, 현행 버전과 구버전을 구분할 수 있는 구조가 필요합니다.

중요한 페이지에는 정보 소유자(Information Owner), 최종 검토일, 정본(Source of Truth)의 소재, 유효 기간 등을 부여합니다. 오래된 페이지는 아카이브하거나 구버전임을 명시합니다.

그림4: 이용자의 권한과 Notion AI의 참조 범위

6. 커넥터는 「연결할 수 있는가」가 아니라 「연결해도 되는가」로 판단한다

외부 연동은 편리하지만, 연결 대상이 늘어날수록 AI가 참조하는 정보와 관리 대상도 늘어납니다.

외부 연동을 종류별로 구분하기

최소한 다음의 세 가지는 구분하여 평가합니다.

참조계 (Reference-based): Notion AI가 외부 정보를 검색·참조하는 연동 -
동기계 (Sync-based): Notion과 외부 서비스의 데이터를 동기화하는 연동 -
개인 연동 (Personal-based): 이메일이나 캘린더 등 개인 계정에 귀속되는 연동

같은 「연동」이라도 영향 범위와 리스크는 다릅니다.

연결 전 참조 범위와 책임자 확인하기

커넥터를 추가하기 전에 다음 사항을 확인합니다.

• 어떤 업무 과제를 해결하기 위한 연결인가
• 어떤 사용자가 이용하는가
• 어떤 외부 정보가 검색·참조 대상이 되는가
• 기밀 정보가 포함되어 있지 않은가
• 누가 설정과 정기 확인에 책임을 지는가
• 불필요해졌을 때 누가 해제하는가

개인이 자유롭게 연결 대상을 늘리는 것이 아니라, 이용 목적과 대상 데이터를 확인하는 신청·승인 프로세스를 마련합니다.

「연결하지 않는다」는 선택지를 남겨두기

연결할 수 있는 것을 모두 연결하는 것이 최선은 아닙니다.

검색 결과의 노이즈가 늘어나거나, 정본이 모호해지거나, 권한 관리가 복잡해지거나, 운영 책임자가 없는 등의 경우에는 연결을 보류합니다. 외부 시스템이 정본이라면 양방향 동기화가 아닌, 링크나 일방향 참조만으로도 충분할 수 있습니다.

그림5: 커넥터 연결 여부 판단 플로우

7. AI 이용 규칙은 툴이 아니라 정보의 저장 위치로 통제한다

전사 도입 시에는 「Notion AI를 쓸 것인가, 외부 AI를 쓸 것인가」라는 논의가 일어나기 쉽습니다. 하지만 조직 지식(Organizational Knowledge)의 관점에서는 어떤 툴로 생각하느냐보다, 공식적인 결론을 어디에 남기느냐가 중요합니다.

생각하는 장소는 자유롭게. 공식 버전은 조직이 참조할 수 있는 장소로 되돌린다.

브레인스토밍(Wall-hitting), 발산, 긴 추론은 용도에 맞는 AI로 수행할 수 있습니다. 다만, 의사결정, 재사용할 지식, 승인된 방침은 공식적인 저장 위치에 반영합니다. 개인의 대화 이력에만 남아 있는 정보는 조직 입장에서 보면 존재하지 않는 것과 같습니다.

또한, AI에게 요청할 때는 페이지나 DB를 지정하여 탐색 범위를 제한하는 것도 유효합니다. 논점은 「어떤 AI가 가장 뛰어난가」가 아니라, 올바른 정보원과 탐색 범위를 지정할 수 있는가입니다.

8. 일상 운영에 거버넌스(Governance)를 포함시키기

도입 시에 설정을 잘 갖추어 놓아도, 일상 업무에서 지켜지지 않으면 의미가 없습니다. 통제는 개인의 주의력에 의존하는 것이 아니라, 통상적인 작업 절차에 포함시켜야 합니다.

회의록은 지정된 DB에서 작성하기

AI Meeting Notes를 개인 영역에서 실행하면, 회의록이 개인의 수중에 축적되어 조직에서 참조하기 어려워질 수 있습니다.

따라서 회의 전에 회의록 DB에 레코드를 생성하고, 해당 페이지 내에서 Meeting Notes를 실행하는 운영 방식을 취합니다. 「어디에서 만들 것인가」를 결정하는 것만으로도, 회의 기록이 검색과 AI 참조 대상에 포함됩니다.

사외 회의의 녹음·텍스트 변환 조건 정하기

사외 회의에서는 녹음·텍스트 변환(Transcription)을 시작하기 전에 참가자의 동의와 계약상의 제약을 확인합니다.
동의를 얻을 수 없거나 판단할 수 없는 경우에는 녹음을 사용하지 않고 수동 메모로 전환합니다.

통제의 목적은 일률적으로 금지하는 것이 아니라, 안전하게 사용할 수 있는 조건을 명시하는 것입니다.

템플릿으로 입력 품질 통일하기

회사명, 제품명, 전문 용어, 인명 등의 표기 불일치는 검색성과 AI의 답변 품질을 떨어뜨립니다.

회의 템플릿이나 동기화 블록(Synced Block)에 용어·변환 규칙을 집약하면, 한 곳의 업데이트를 여러 회의에 반영할 수 있습니다. 이용자의 숙련도에 의존하지 않고 입력 품질을 맞추는 메커니즘을 만듭니다.

계정과 권한의 라이프사이클(Lifecycle) 결정하기

입사 시의 발급뿐만 아니라, 이동·휴직·퇴직 시의 변경과 삭제까지 운영화합니다.

• 신청자와 승인자
• 발급·변경·삭제를 수행하는 담당자
• 권한 그룹의 업데이트 방법
• 게스트 및 외부 공유의 점검(Inventory) 빈도
• 감사 로그(Audit Log)를 확인하는 상황·담당자·빈도

로그를 취득할 수 있는 상태만으로는 통제가 되지 않습니다. 누가 무엇을 보는지까지 결정해야 합니다.

9. 모든 것을 한 번에 구현하지 않기

전사 도입에 필요한 통제는 조직 규모, 다루는 정보, 법령·계약, 기존 IT 환경에 따라 달라집니다.

SSO/SCIM, MDM, 네트워크 제어, 고도화된 모니터링, 양방향 동기화 등은 유효한 수단이지만, 도입 그 자체를 목적으로 삼아서는 안 됩니다. 먼저 권한, 공유, 계정 관리, 표준 감사 수단으로 어디까지 대응할 수 있는지 확인하고, 남은 리스크에 대해 추가 대책을 선택합니다.

판단 순서는 다음과 같습니다.

• 보호해야 할 정보와 상정 리스크를 명확히 한다
• 권한 및 공유 설계로 방어할 수 있는 범위를 확인한다
• 일상적인 신청·확인·해제 절차를 정비한다
• 남은 리스크에 대해 추가적인 기술적 통제를 검토한다
• 조직이나 이용 범위의 확대에 맞춰 재검토한다

10. 도입 전 확인해야 할 체크리스트

• 대상 부서·인원·업무를 정의했는가
• Notion에 둘 정보와 외부 시스템을 정본(Source of Truth)으로 하는 정보를 정리했는가
• 초기 도입 후의 확대 조건과 평가 지표를 결정했는가
• 필요한 통제 기능에 따라 플랜을 판단했는가
• 멤버와 게스트의 이용 영역을 분리했는가
• 전사 공통·부서 한정·기밀·외부 협업의 경계를 설계했는가
• 공통 DB를 복제하지 않고 사용할 수 있는 구성을 검토했는가
• 게스트 초대·웹 공개 조건을 결정했는가
• 외부 공유의 승인·기한·해제 방법을 결정했는가
• 페이지·DB·Teamspace의 권한을 필요 최소한으로 설정했는가
• AI가 우선 참조할 공식 정보를 명확히 했는가
• 커넥터(Connector)별 목적·참조 범위·책임자를 확인했는가
• 계정 발급·이동·삭제 운영 방식을 결정했는가
• 회의 녹음·텍스트 변환(Transcription) 조건을 결정했는가
• 감사 로그와 권한 확인 책임자·빈도를 결정했는가

요약: 안전한 전사 도입은 경계와 운영 설계로 결정된다

Notion/Notion AI의 전사 도입에서 중요한 것은 제한을 늘리는 것이 아닙니다.

• Notion에서 다루는 정보와 외부 시스템에 남길 정보를 분리한다
• 멤버와 게스트, 전사 공통 정보와 한정 정보를 분리한다
• Teamspace, DB, 페이지의 권한 경계를 일치시킨다
• 외부 공유의 출구를 한정한다
• 커넥터의 참조 범위와 책임자를 명확히 한다
• 일상 업무 속에서 권한과 정보의 최신성을 유지한다

무엇을 어디까지 허용할지 판단할 수 있는 경계를 만드는 것이 편의성과 거버넌스(Governance)를 양립시키는 토대가 됩니다.

프로덕트와 조직은 변화합니다. 처음부터 완벽한 규칙을 만들기보다, 이용 범위와 리스크의 변화에 맞춰 경계와 운영을 지속적으로 업데이트하는 것이 중요합니다.

Discussion