---
title: "게시물 첨부파일은 스냅샷일까 참조일까, 협업툴 설계의 갈림길"
description: "게시물 첨부에도 버전관리를 둘지 정하면서 업계가 불변 스냅샷과 살아 있는 참조로 갈린다는 걸 조사했다. 혼란은 패러다임이 아니라 기본값을 숨기거나 바꿀 때 생기고, 두 의미론은 사용자가 고르게 공존시키는 쪽으로 정리했다."
date: 2026-11-08
updated: 2026-11-08T01:13:50.757Z
tags: [system-design, file-storage, collaboration, versioning]
canonical: https://blog.wooncloud.com/posts/attachment-snapshot-vs-living-reference
---

협업 플랫폼에서 "게시물에 첨부된 파일도 버전관리(덮어쓰기와 히스토리)가 되어야 하나?"를 정해야 했다. 파일 저장소에는 이미 버전관리가 있는데, 게시물 첨부에는 적용되지 않는 구조였다.

단순해 보이지만 업계가 정확히 두 진영으로 갈리는 문제였다.

![알림 없는 참조 첨부는 원본이 바뀌어도 눈치챌 수 없지만, 변경 알림을 붙이면 사용자가 바뀐 시점을 바로 안다.](/images/posts/attachment-snapshot-vs-living-reference/7f0b4962-0236-477b-8455-11afcb6c0b8d.webp)

## 두 진영이 있다

먼저 불변 스냅샷 쪽이다. 이메일, 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) 버전을 올리면 모든 참조 지점이 자동으로 최신을 본다.

![첨부를 사본으로 고정하든 참조로 연결하든 사용자가 반대 의미로 기대하면 수정이 반영되지 않거나 몰래 바뀌는 멘탈모델 불일치가 생긴다.](/images/posts/attachment-snapshot-vs-living-reference/66b3a7af-beea-4b97-9166-46c328344e8c.svg)

## 혼란은 패러다임이 아니라 기본값에서 난다

조사하면서 가장 눈에 띈 건, 사용자 혼란이 어느 한쪽 패러다임 자체에서 나오지 않는다는 점이었다. 제품이 어느 쪽인지 숨기거나 기본값을 바꿀 때 난다.

New Outlook 이 첨부 기본값을 사본에서 클라우드 링크로 바꾸자 반발이 이어졌다. 반대로 Teams 채팅에 OneDrive 파일을 드래그하면 동기화되지 않는 사본이 생겨서 "수정이 반영 안 된다"는 불만이 나온다. 방향은 반대인데 원인은 같다. 멘탈모델 불일치다.

Microsoft 조차 2025년에 Teams 에서 같은 이름으로 업로드할 때 'Replace existing file' 옵션을 뺐다. 살아 있는 문서 모델에서도 무단 덮어쓰기는 실제 사고로 이어진다는 얘기다.

## 그래서 세운 원칙 세 가지

첫째, 소급 변경은 피한다. 기존 첨부의 의미론(스냅샷)을 나중에 바꾸면 같은 행을 재참조하는 모든 위치(전달, 복사본)에 소급 전파된다. 본문에 비정규화해 둔 파일명과 크기 사본, 변환 캐시, CDN 캐시도 전부 깨진다. 첨부가 불변이라는 가정 위에 쌓인 코드는 생각보다 많다.

둘째, 두 의미론은 선택으로 공존시킨다. 업로드할 때 "사본 첨부(불변, 기록용)"와 "저장소 파일 연결(항상 최신, 협업용)" 중에서 사용자가 고르게 한다. Gmail 의 일반 첨부와 Drive 링크가 정확히 이 모델이다.

셋째, **살아 있는 참조에는 투명성 장치를 묶어서 붙인다.** 수정자와 수정 시각을 상시 노출하고, 버전 히스토리를 누구나 열람하게 하고(SharePoint 는 Read 권한으로도 볼 수 있다), 변경이 생기면 대화에 자동 메시지를 올린다(Slack canvas 의 update message 패턴). 결재나 승인 맥락은 SharePoint 콘텐츠 승인처럼 독자가 마지막 승인본을 보도록 고정하는 예외로 둔다.

결국 어느 쪽이 맞느냐보다, 지금 이 첨부가 어느 쪽인지 사용자에게 숨기지 않는 게 먼저인 것 같다.

## 참고

- [chatMessageAttachment (Microsoft Graph)](https://learn.microsoft.com/en-us/graph/api/resources/chatmessageattachment)
- [Google Drive API, Files 개요](https://developers.google.com/workspace/drive/api/guides/about-files)
- [How versioning works in lists and libraries (Microsoft)](https://support.microsoft.com/en-us/office/how-versioning-works-in-lists-and-libraries-0f6cd105-974f-44a4-aadb-43ac5bdfd247)
- [Slack canvas update messages](https://slack.com/help/articles/29692277750291-Understand-canvas-update-messages)
- [36 CFR 1236.22](https://www.law.cornell.edu/cfr/text/36/1236.22)