게시물 첨부파일은 스냅샷일까 참조일까, 협업툴 설계의 갈림길
게시물 첨부에도 버전관리를 둘지 정하면서 업계가 불변 스냅샷과 살아 있는 참조로 갈린다는 걸 조사했다. 혼란은 패러다임이 아니라 기본값을 숨기거나 바꿀 때 생기고, 두 의미론은 사용자가 고르게 공존시키는 쪽으로 정리했다.
협업 플랫폼에서 "게시물에 첨부된 파일도 버전관리(덮어쓰기와 히스토리)가 되어야 하나?"를 정해야 했다. 파일 저장소에는 이미 버전관리가 있는데, 게시물 첨부에는 적용되지 않는 구조였다.
단순해 보이지만 업계가 정확히 두 진영으로 갈리는 문제였다.
두 진영이 있다
먼저 불변 스냅샷 쪽이다. 이메일, Slack, Notion 의 파일 블록이 여기에 든다. 첨부는 보낸 시점에 고정된 사본이다. Slack 은 API 에 파일 콘텐츠를 갱신하는 메서드 자체가 없다. 기록관리 규정(NARA 36 CFR 1236.22)이나 WORM 아카이빙도 이 불변성을 법적 증빙의 근거로 쓴다.
반대편은 살아 있는 참조다. Teams/SharePoint, Google Drive, Confluence 가 그렇다. 게시물에는 링크만 담고(Graph API 의 chatMessageAttachment.contentType="reference"), 파일 ID 는 평생 불변이라("File IDs are stable throughout the life of the file", Drive API) 버전을 올리면 모든 참조 지점이 자동으로 최신을 본다.
혼란은 패러다임이 아니라 기본값에서 난다
조사하면서 가장 눈에 띈 건, 사용자 혼란이 어느 한쪽 패러다임 자체에서 나오지 않는다는 점이었다. 제품이 어느 쪽인지 숨기거나 기본값을 바꿀 때 난다.
New Outlook 이 첨부 기본값을 사본에서 클라우드 링크로 바꾸자 반발이 이어졌다. 반대로 Teams 채팅에 OneDrive 파일을 드래그하면 동기화되지 않는 사본이 생겨서 "수정이 반영 안 된다"는 불만이 나온다. 방향은 반대인데 원인은 같다. 멘탈모델 불일치다.
Microsoft 조차 2025년에 Teams 에서 같은 이름으로 업로드할 때 'Replace existing file' 옵션을 뺐다. 살아 있는 문서 모델에서도 무단 덮어쓰기는 실제 사고로 이어진다는 얘기다.
그래서 세운 원칙 세 가지
첫째, 소급 변경은 피한다. 기존 첨부의 의미론(스냅샷)을 나중에 바꾸면 같은 행을 재참조하는 모든 위치(전달, 복사본)에 소급 전파된다. 본문에 비정규화해 둔 파일명과 크기 사본, 변환 캐시, CDN 캐시도 전부 깨진다. 첨부가 불변이라는 가정 위에 쌓인 코드는 생각보다 많다.
둘째, 두 의미론은 선택으로 공존시킨다. 업로드할 때 "사본 첨부(불변, 기록용)"와 "저장소 파일 연결(항상 최신, 협업용)" 중에서 사용자가 고르게 한다. Gmail 의 일반 첨부와 Drive 링크가 정확히 이 모델이다.
셋째, 살아 있는 참조에는 투명성 장치를 묶어서 붙인다. 수정자와 수정 시각을 상시 노출하고, 버전 히스토리를 누구나 열람하게 하고(SharePoint 는 Read 권한으로도 볼 수 있다), 변경이 생기면 대화에 자동 메시지를 올린다(Slack canvas 의 update message 패턴). 결재나 승인 맥락은 SharePoint 콘텐츠 승인처럼 독자가 마지막 승인본을 보도록 고정하는 예외로 둔다.
결국 어느 쪽이 맞느냐보다, 지금 이 첨부가 어느 쪽인지 사용자에게 숨기지 않는 게 먼저인 것 같다.