Document Governance Integration
Document Management SDK는 파일 생성, 편집, 공유, 삭제 등 문서 Storage에서 발생하는 활동을 기록하고 감사 가능한 형태로 추적할 수 있는 Audit Log 기능을 제공합니다.
이 페이지에서는 Document Management SDK와 Document Governance SDK를 연동하여 Audit Log를 구현한 사례를 소개합니다. Document Governance SDK는 아직 정식 출시되지 않았으며, 현재는 Document Management SDK 하위의 연동 레퍼런스로 제공합니다.
공개 API나 설치 방법을 제공하는 문서가 아니라, Storage와 Editor 환경에서 사람과 AI의 문서 활동을 어떻게 기록하고 감사에 활용할 수 있는지 보여주는 문서입니다.
문서 활동을 감사 가능한 기록으로
일반적인 Storage 로그는 파일이 생성·수정·공유되었다는 사실을 기록할 수 있습니다. 그러나 문서 내부에서 무엇이 변경되었는지, 변경 주체가 사람인지 AI인지, 변경 사항을 누가 검토하거나 승인했는지까지 확인하기는 어렵습니다.
Document Governance SDK는 Storage, Editor, AI Agent, 검토·승인 시스템 등 문서 작업이 발생하는 다양한 환경과 연동하여 파일 활동부터 사람과 AI의 문서 편집, 검토, 승인 및 최종 결과물까지 감사 가능한 기록으로 구성하는 것을 목표로 합니다.
기록 대상
감사 가능한 기록으로 구성하는 활동
이를 통해 단순히 파일이 수정되었다는 사실뿐 아니라, 무엇이 변경되었고, 사람과 AI 중 누가 변경했으며, 누가 이를 검토·승인했는지를 추적할 수 있습니다.
연동 사례
Document Governance SDK는 문서 활동이 발생하는 다양한 Storage와 Editor 환경에 적용할 수 있습니다.
아래에서는 Document Management SDK를 활용한 Storage 연동 사례와 Microsoft Word Add-in을 활용한 Editor 연동 사례를 각각 소개합니다. 이를 통해 파일의 생성·공유·삭제와 같은 Storage 활동부터 사람과 AI의 문서 편집·검토·승인 과정까지 증적할 수 있는 활용 범위를 확인할 수 있습니다.
Storage와 Editor는 지금 문서로 정리한 두 사례이지 연결 지점의 한계가 아닙니다. 문서를 다루는 워크플로 서비스, 결재 시스템, AI Agent도 각각 또 하나의 연결 지점이 될 수 있고, 어떤 환경이든 같은 공통 형태의 활동으로 옮겨 같은 증적 기록에 쌓입니다. 원천이 하나 늘면 기록에 출처가 하나 늘 뿐, 감사자가 읽어야 할 형식이 하나 더 생기지는 않습니다.
Storage · Document Management SDK
Document Management SDK에서 발생한 파일·사용자·관리 활동을 Document Governance SDK를 통해 기록하고, Thinkfree Drive Audit Log에서 관리자가 조회할 수 있도록 구현한 사례입니다.
Storage는 문서의 생애주기가 드러나는 자리입니다. 생성, 공유, 이동, 삭제, 그리고 그 주변의 계정과 설정이 모두 여기서 보입니다. Storage 제품은 이미 자기 Audit Log를 위해 그 활동을 관측하고 있으므로, Document Governance SDK는 그 활동을 서버 쪽에서 이어받습니다. Storage 제품은 지금까지 하던 대로 활동을 기록하고, SDK가 각 활동을 하나의 공통 형태로 옮겨 서명한 뒤 증적 기록으로 보냅니다. 참조 연동에서는 수집을 켜고 기록 대상을 지정하는 설정 변경이었을 뿐, 활동을 남기는 코드를 다시 쓰는 작업이 아니었습니다.
연동 구조
문서 활동에서 감사 기록까지
기록 대상 예시
Storage 및 관리 활동
모든 기록은 누가 했는지, 무엇이 영향을 받았는지, 언제였는지를 담습니다. 공유는 수신자와 부여된 권한을 함께 남기고, 파일 변경은 결과 버전과 변경이 들어온 경로를 남깁니다. 성공과 실패는 같은 활동에 결과 값으로 기록하므로 로그인 실패와 로그인 성공은 결과만 다른 같은 종류의 기록이고, 감사자는 두 번째 용어 체계를 익히는 대신 결과로 걸러 보면 됩니다.
같은 저장을 Storage와 Editor가 함께 관측하면 두 기록을 모두 남깁니다. Storage는 파일이 갱신됐다는 것을 알고, 본문이 무엇이 됐는지는 Editor만 압니다.
Thinkfree Drive Audit Log 구현 화면
Document Management SDK에서 발생한 사용자·문서·관리 활동이 Thinkfree Drive Audit Log에 기록되는 예시입니다.
Editor · Microsoft Word Add-in
Editor 연동은 Storage 로그만으로 확인하기 어려운 문서 내부의 변경 활동을 기록합니다. 문서의 어느 부분이 변경되었는지, 사람과 AI 중 누가 변경했는지, 사용자가 변경 사항을 승인하거나 거절했는지를 증적할 수 있습니다.
Storage는 파일이 바뀐 사실을 봅니다. 어느 문장이 바뀌었는지, 누가 썼는지, 누가 검토했는지는 보지 못합니다. host 편집기 안에서 도는 애드인은 그것을 봅니다. 애드인은 문서를 열 때 기준 스냅샷을 잡고 현재 문서와 비교하며, 비교 단위는 문단 하나와 표의 셀 하나입니다. AI 편집은 트랙체인지로 문서에 들어오므로 바뀐 조각마다 그것을 만든 AI인지 직접 입력한 사람인지 귀속할 수 있습니다. 이후 그 제안이 수락되거나 거절되면 같은 대상에 그 결정을 기록합니다. 편집 더미가 검토 이력이 되는 지점이 바로 여기입니다.
연동 구조
편집에서 검토 결정까지
기록 대상 예시
Editor가 더하는 활동
변경 기록은 그 문단 또는 셀의 이전 모습과 이후 모습, 그 안에서 실제로 바뀐 조각들, 조각마다의 작성자, 검토자의 결정을 함께 담습니다. AI가 제안을 남긴 문단을 사람이 다시 고치면, 둘은 하나의 모호한 편집으로 합쳐지지 않고 각각의 기록으로 남습니다.
구현 화면 예시
아래 녹화에서 Word 애드인이 사람과 AI의 편집을 증적으로 남기는 과정을 확인할 수 있습니다.
애드인은 AI 편집 화면 자체도 함께 제공합니다. 어시스턴트가 만든 편집은 트랙체인지 제안으로 들어와 사용자의 승인을 기다린 뒤에야 문서에 반영되므로, 기능과 그 기능을 쓴 증적이 두 연동이 아니라 하나의 연동에서 나옵니다.
참조 host는 Microsoft Word이며, 브라우저 기반 편집기 host가 같은 어댑터 계약 위에서 동작합니다. 수집 범위는 host가 달라도 의도적으로 동일하게 두지만, host마다 표현할 수 있는 것은 다릅니다 - 네이티브 제안 모델이 없는 편집기는 같은 수락·거절 기록을 만들 수 없습니다. 사용자가 실제로 쓰는 host에서 그 차이가 어디까지인지 확인하는 것이 이 연동 사례의 목적 중 하나입니다.
증적 기록과 관리자 검토
Storage든 Editor든 어느 연결 지점에서 들어오든 같은 증적 기록으로 모이고, 그 기록은 나중에 근거로 쓸 수 있도록 만들어집니다.
기록 속성
기록의 무결성과 접근 범위
기록은 이어붙이기만 하고 고치거나 지우지 않습니다. 각 기록은 이전 기록의 해시를 포함하므로, 기록을 삭제하거나 변경하면 연결된 해시를 검증할 때 불일치를 확인할 수 있습니다. 원천이 신고한 값과 서버가 요청에서 관측한 값을 나눠 저장하므로 기록 안의 주장과 기록을 보관하는 쪽이 확인한 사실을 구분할 수 있습니다. 저장된 내용은 암호화하고, 전송은 건마다 인증하며, 조회 권한은 하나의 테넌트로 제한합니다.
관리자는 그 결과를 목록과 상세로 검토합니다. 정렬 기준은 서버에 도착한 시각이 아니라 활동이 실제로 일어난 시각입니다. 보관 기간과 개인정보 파기는 이 검토 화면과 함께 정의하고 있습니다.