목요일 밤 10:30, 동료 Anna 와 공유 Dropbox 에서 같은 제안서를 편집 중. 그녀는 3 단락을 추가했습니다. 당신은 동시에 마지막 CTA 를 추가. 둘 다 Cmd+S. 다음 날 폴더를 열면 한 파일이 더 있습니다: 제안서 (Anna 의 충돌된 사본 2026-05-02).docx. 그녀의 수정은 당신 쪽에 없고, 당신의 수정은 그녀 쪽에 없습니다. 1 시간 동안 손으로 합치고, 30 분 동안 빠진 게 없는지 확인.
이건 버그가 아닙니다. Dropbox 가 충돌 감지층이 없는 결과입니다. 먼저 충돌된 사본이 생기는 진짜 메커니즘 을 보고, 그 다음 3 가지 동기화 설계로 어떻게 근본 해결하는지 보여드릴게요.
목차
충돌된 사본이 나타나는 시점
「충돌된 사본이 계속 생긴다」를 풀어보면, 4 가지 완전히 다른 시나리오가 각각 트리거합니다:
| # | 시나리오 | 메커니즘 |
|---|---|---|
| 1 | 두 명 동시 편집 | 양쪽 다 Cmd+S 업로드, Dropbox 는 앞에서 변경됐는지 모름 |
| 2 | 오프라인 편집 후 온라인 | 기차에서 편집, Wi-Fi 에서 동기화 시 클라우드 버전과 안 맞음 |
| 3 | 여러 디바이스 전환 | 노트북 중간까지→폰 계속→노트북이 나중에 동기화 충돌 |
| 4 | 크로스 OS 동기화 지연 | Mac vs Windows 시계 몇 초 차이, Dropbox 가 충돌 판정 |
말 안 하면 모르는 사실: 4 가지 중 하나만 밟아도 충돌된 사본이 생깁니다. 당신의 평소 업무 방식은 최소 2 개는 밟습니다.
Dropbox 가 이렇게 설계한 이유
Dropbox 는 「나중에 저장한 버전이 이기고, 앞 버전을 따로 보관」 으로 설계(Dropbox 공식 설명): 두 명 동시 편집, 나중 업로드가 이김, 앞 버전은 (충돌된 사본) 으로 보존.
충돌 감지가 기술적으로 어려운 게 아닙니다. 상업적 트레이드오프입니다:
- 실시간 경험 우선: 동기화 가 작업을 막을 수 없음. 매번 「병합 방식 선택」이 뜨면 Dropbox 가 불편해짐.
- 충돌 해결을 사용자에게 떠넘김: 다른 버전 별도 저장 = 「다 보관해드릴게요, 직접 결정하세요」
- 설계자의 선택: 아무도 잃지 않지만, 당신이 일을 함.
맞아요, 이게 짜증나는 부분입니다. Dropbox 는 도구가 해야 할 일 (충돌 감지층) 을 사용자 규율에 떠넘깁니다. 그리고 규율은 자동화를 절대 이기지 못합니다.
Keeply 를 만들기 전에 저도 Dropbox 에서 같은 일을 수백 번 겪고 나서야, 이게 제가 부주의해서가 아니라 Dropbox 가 원래 이렇게 설계된 거라는 걸 깨달았습니다.
두 파일을 수동으로 합치는 건 증상 치료
Dropbox Help Center 가 가르치는 해결: 「두 파일 열기, 차이 비교, 수동으로 메인에 병합, 충돌된 사본 삭제.」 들어보면 합리적.
하지만 이 해결 는 메커니즘 을 바꾸지 않습니다. 다음 주에 또 동기화 충돌, 새로운 충돌된 사본 생성, 또 수동 병합. 한 달 후 4-5 번 했습니다.
병합을 못해서가 아닙니다. 충돌을 막지 않도록 설계된 도구 를 쓰고 있습니다. 해법은 동기화 메커니즘 을 바꾸는 것이지, 자기를 더 빨리 병합하도록 훈련하는 게 아닙니다.
Google 상위 3 위 (Dropbox Help / EaseUS / Wondershare) 와 비교: 모두 증상 치료 가이드. 메커니즘 각도에서 자르는 사람 없음. 이 글이 자릅니다.
3 가지 동기화 설계로 근본 해결
동기화 설계가 할 수 있는 일을 3 가지 패턴으로 나눕니다. 각각 다른 충돌 시나리오 해결:
설계 A: 감지 + 확인 (동기화 시 먼저 묻기)
양쪽이 같은 파일을 편집, 동기화 시 충돌을 감지하고 UI로 사용자에게 묻기: A 유지, B 유지, 둘 다 병합. 예: 엔지니어들이 쓰는 버전 관리 도구가 이 방식. Keeply 는 같은 감지를 오피스 도구에 가져옴: 충돌이 일어나면 「Anna 의 버전 / 당신의 버전 / 둘 다 합치기」 같은 일상 언어로 묻고, 전문 용어는 보여주지 않습니다.
실제 동작은 이렇습니다. Anna 가 프로젝트 보관함에 한 버전을 푸시했습니다. Keeply 는 「그녀의 변경을 적용할지」를 다이얼로그로 띄워 당신이 결정하게 합니다:
「적용」을 누르기 전에 Keeply 는 현재 버전을 자동으로 스냅샷합니다 (잘못 눌러도 되돌릴 수 있음). 양쪽이 같은 단락을 편집했다면 두 번째 단계 프롬프트가 뜹니다: 당신 버전 유지 / Anna 버전 사용 / 둘 다 보관. 시나리오 #1 + #2 해결.
설계 B: 파일 잠금 (먼저 연 사람이 사용)
파일을 열면 도구가 자동으로 잠금. 동료가 열면 「Anna 가 편집 중」 표시되어 변경 불가, 기다려야 함. 예: SharePoint, Adobe Creative Cloud Files, Bentley ProjectWise (건설·엔지니어링 업계에서 쓰는 프로젝트 관리 시스템). 시나리오 #1 + #3 + #4 해결, 트레이드오프: 동료가 기다려야 함.
설계 C: 로컬 사본 + 능동 푸시 (Keeply 모델)
작업 버전은 당신 머신에 있고, 동기화는 당신이 「푸시」를 능동적으로 누름 (Dropbox 의 실시간 미러가 아님). 충돌은 푸시 시 감지하고 일상 언어 UI 로 묻습니다. Keeply 는 이 방식: 로컬에서 편집, 차이를 눈으로 확인, 문제 없으면 NAS / SharePoint / 공유 폴더로 푸시 — 「Dropbox 가 모르는 사이에 당신의 버전을 덮어쓰는」 깜짝 상황이 없습니다.
마지막 CTA 를 다 쓴 뒤 Keeply 메인 창의 「버전 저장」 버튼을 누르면 이 다이얼로그가 나타납니다:
「마지막 CTA 추가 — Anna 의 머지 대기」 같은 한 줄을 적고 버전을 저장합니다. Anna 도 자기 쪽에서 같은 동작을 합니다. 두 버전이 공유 보관함 타임라인에 각각 따로 자리하며 서로 덮어쓰지 않습니다:
두 버전이 나란히 있고, 각각에 무엇이 바뀌었는지 메모가 붙어 있습니다. 어떻게 합칠지는 당신이 결정합니다 — 조용한 (충돌된 사본) 파일명도, 3 주 뒤에야 발견하는 놀라움도 없습니다. 시나리오 #1-#4 해결, 트레이드오프: Dropbox 만큼 즉시는 아님.
이때 알게 됩니다, 시나리오 #4 (OS 간 시계 차이) 가 가장 어렵습니다, 순수 시계 문제니까. 설계 A 와 C 는 감지 가능하지만, 해결은 여전히 사용자 개입 필요.
Keeply 가 맞지 않는 경우
Keeply 가 모든 Dropbox 시나리오를 해결하진 않습니다:
- 대용량 파일 실시간 동기화: Premiere 프로젝트를 편집하며 동기화, Keeply 의 로컬 사본 모델은 부적합 (푸시에 몇 분).
- 모바일 디바이스 접근: Keeply 는 데스크톱 우선, Dropbox 앱이 폰에서 훨씬 부드러움.
- 외부 공유 링크: Dropbox 의 「Share link」는 Keeply 에 대응 기능 없음.
- 협업 빈도 매우 높음 (1 시간 내에 여러 명이 번갈아 편집): Keeply UX 가 Dropbox 보다 느림, 그 경우엔 Google Docs 공동 편집 사용 권장.
다음에 (충돌된 사본) 을 보기 전에
다음에 폴더에 (충돌된 사본) 파일명 이 더 생겨도, 더 이상 1 시간 수동 병합에 쓰지 않습니다. 그게 메커니즘 문제임을 알고, 다른 선택지가 있다는 걸 아니까요.
Keeply 가 동기화 충돌을 어떻게 해결하는지 보고 싶나요? 「파일 버전 관리 완전 가이드」 계속 읽기.
저자 소개: Ting-Wei Tsao, Keeply 창업자. LinkedIn
