클라우드 동기화 충돌로 발주 일정표가 세 개가 된 날
아침에 공유 폴더를 열었더니 발주 일정표 파일이 세 개였습니다. 원래 이름의 파일 하나, 뒤에 충돌 사본이라는 꼬리표가 붙은 파일 둘. 나중에 알고 보니 클라우드 동기화 충돌이 만든 상황이었습니다. 열어보니 세 개의 내용이 전부 달랐고, 어제 오후에 제가 넣은 수정분은 셋 중 어디에도 온전히 들어 있지 않았습니다.
그날 오전을 통째로 이 파일 세 개를 대조하는 데 썼습니다. 이 글은 충돌이 왜 났는지, 사라진 줄 알았던 내용을 어디서 찾았는지, 그리고 그 뒤로 공유 파일을 다루는 규칙을 어떻게 바꿨는지의 기록입니다.
저는 여러 법인의 발주와 정산 실무를 보는 사람이라, 이런 일정표 파일은 저 혼자 쓰는 게 아닙니다. 사무실 PC, 제 노트북, 그리고 다른 직원의 PC까지 세 자리에서 같은 파일을 만집니다. 사고는 정확히 그 구조에서 났습니다.
충돌 사본은 오류가 아니라 동기화 프로그램의 최선입니다
처음에는 동기화 프로그램이 고장 났다고 생각했습니다. 알아보니 반대였습니다. 충돌 사본은 프로그램이 정상적으로 일한 결과였습니다.
동기화 프로그램은 두 자리에서 같은 파일이 서로 다르게 바뀐 것을 발견하면, 어느 쪽이 맞는지 판단하지 않습니다. 판단했다가 한쪽을 지우면 그게 진짜 사고이기 때문입니다. 대신 양쪽을 다 살리고 한쪽에 충돌 사본이라는 이름을 붙입니다. 내용을 합치는 일은 사람 몫으로 남깁니다.
그러니까 파일이 세 개가 된 것 자체는 유실이 아니었습니다. 문제는 충돌 사본에 다른 사람의 수정분이 있다는 사실을 모르고 삭제했다는 것, 그리고 세 개가 되도록 일하는 방식에 있었습니다.
이 구조를 이해하고 나니 그 뒤로 충돌 사본이 뜨는 화면을 봐도 예전만큼 놀라지 않게 됐습니다. 파일이 늘어난 것을 오류로 보지 않고, 누군가 다른 곳에서 손을 댔다는 신호로 읽게 됐다는 뜻입니다. 다만 신호를 침착하게 읽는 것과 그 신호가 뜨지 않게 애초에 막는 것은 다른 문제였고, 그래서 규칙을 따로 정할 필요가 있었습니다.
재구성해본 그날의 순서
파일 세 개의 수정 시각과 각자의 기억을 맞춰서 전날 일어난 일을 재구성했습니다.
- 오후 두 시쯤 다른 직원이 사무실 PC에서 파일을 열어 납품 일자를 고쳤습니다. 파일은 계속 열어둔 채였습니다.
- 오후 네 시쯤 제가 노트북에서 같은 파일을 열어 신규 발주 줄을 추가했습니다. 그런데 그 노트북은 오전에 외부 미팅을 다녀온 뒤 무선 연결이 끊긴 상태였고, 저는 그걸 모르고 있었습니다.
- 저녁에 노트북이 집 네트워크에 붙으면서 제 수정본이 올라갔습니다. 같은 시각 사무실 PC의 수정본과 충돌이 났고, 사본이 생겼습니다.
- 다음 날 아침 그 직원이 충돌 사본을 보고, 뭔가 잘못된 파일인 줄 알고 하나를 삭제했습니다. 하필 제 수정분이 든 쪽이었습니다.
어느 단계에서도 이상한 행동을 한 사람은 없었습니다. 각자 자기 자리에서는 합리적으로 움직였는데 결과가 사고였습니다. 이게 이 사고의 핵심이었습니다. 사람을 탓해서 고칠 수 있는 구조가 아니었습니다.
재구성에 걸린 시간도 적어둡니다. 파일 속성의 수정 시각과 동기화 서비스의 활동 기록을 맞춰보는 데 삼십 분쯤 들었습니다. 활동 기록에는 어느 기기에서 언제 올라왔는지가 남아 있어서, 기억에 기대지 않고 순서를 확정할 수 있었습니다. 이 기록 화면 역시 그날 처음 열어봤습니다.
사라진 내용은 휴지통과 버전 기록에 있었습니다
삭제된 충돌 사본부터 찾았습니다. 동기화 서비스의 웹 화면에 휴지통이 있었고, 지워진 파일이 30일 보관된다는 것을 이때 처음 확인했습니다. 파일은 거기 있었습니다. 복원 버튼 하나로 돌아왔습니다.
내친김에 버전 기록도 열어봤습니다. 파일을 우클릭하면 버전 기록 메뉴가 있고, 지난 며칠간의 저장본이 시각별로 줄지어 있었습니다. 어느 시점의 파일이든 골라서 되돌릴 수 있었습니다.
허탈했던 건, 이 기능들이 전부 처음부터 켜져 있었다는 점입니다. 몇 년을 쓰면서 한 번도 열어본 적이 없었을 뿐입니다. 복구 수단이 없어서 오전을 날린 게 아니라, 있는 복구 수단의 존재를 몰라서 세 파일을 눈으로 대조하고 있었던 겁니다.
그래도 완전히 돌아오지는 않았습니다
복원과 대조를 끝내고 최종본을 만들었는데, 한 가지가 끝까지 안 맞았습니다. 제가 전날 추가했다고 기억하는 발주 줄 중 하나가 어느 버전에도 없었습니다.
한참을 뒤지다가 원인을 찾았습니다. 노트북 쪽 엑셀이 자동 저장이 꺼진 상태였고, 제가 마지막 저장을 누른 기억도 불확실했습니다. 그러니까 그 줄은 동기화 충돌로 사라진 게 아니라, 애초에 파일로 저장된 적이 없었을 가능성이 높았습니다. 동기화는 저장된 것만 나릅니다. 저장 안 된 내용은 어떤 복구 수단으로도 못 돌립니다.
이 한 줄은 결국 거래처에 전화해서 다시 확인하고 채웠습니다. 사고 조사가 도구 문제에서 시작해서 제 저장 습관 문제로 끝난 셈입니다.
이 사고를 위쪽에 보고할 때는 원인을 기술 용어로 풀지 않고 이렇게 말했습니다. 같은 파일을 여러 자리에서 손대다 생긴 문제이고, 앞으로는 자리마다 맡는 구간을 나눠서 겹치는 일 자체를 줄이겠다는 것입니다. 보고는 그 한 문장으로 끝났습니다.
대조 작업에서 배운 요령 하나
세 파일을 대조하던 오전의 작업 방식도 적어둡니다. 처음에는 세 파일을 나란히 띄워놓고 눈으로 훑었는데, 일정표처럼 행이 많은 표에서는 이 방식이 오래 걸리고 빠뜨립니다. 중간에 방식을 바꿔서, 새 시트에 세 파일의 내용을 전부 붙여 넣고 정렬한 뒤 중복 값 표시 기능으로 한 파일에만 있는 행을 골라냈습니다. 눈 대조로 한 시간 걸리던 것이 이 방식으로 십 분쯤에 끝났습니다.
한 파일에만 있는 행이 곧 어느 한쪽에서만 수정된 부분입니다. 그 행들만 만든 사람에게 확인하면 되니, 대조의 대상이 파일 전체에서 행 몇 개로 줄어듭니다. 충돌 사본을 합칠 일이 또 생긴다면 처음부터 이 순서로 갈 겁니다.
다른 직원에게 알려줄 때는 정렬이니 중복 값 표시니 하는 기능 이름을 뺐습니다. 대신 세 파일을 새 시트에 다 모아놓고 겹치지 않는 줄만 골라내는 거라고 풀어서 말했습니다. 방법 자체보다 왜 이렇게 하는지, 그러니까 눈으로 훑다가 놓치는 일을 줄이려는 목적을 먼저 말해야 알아듣는다는 것도 이번에 다시 느꼈습니다.
바꾼 규칙
이 일 뒤로 공유 파일을 다루는 규칙을 네 가지로 정리해서 같이 쓰는 사람들과 공유했습니다.
- 동시에 만질 수 있는 파일은 편집 주체를 정합니다. 발주 일정표는 시트에 담당 구역을 나눴고, 구역 밖을 고칠 일이 있으면 메신저로 한 줄 알리고 고칩니다.
- 파일을 열어둔 채 자리를 뜨지 않습니다. 열어둔 파일은 그 시간 내내 충돌 후보입니다. 수정이 끝나면 저장하고 닫는 것까지가 편집입니다.
- 노트북에서는 작업 전에 동기화 상태 아이콘부터 봅니다. 끊긴 상태의 편집이 이번 사고의 방아쇠였습니다. 확인에 드는 시간은 1초입니다.
- 충돌 사본은 지우지 않고 이름을 유지한 채 두고, 만든 사람을 찾아 확인한 뒤에 정리합니다. 충돌 사본 삭제는 남의 수정분 삭제일 수 있습니다.
그리고 저 자신에게는 하나를 더 붙였습니다. 새 도구를 쓰기 시작할 때 복구 수단부터 확인하는 것입니다. 휴지통이 있는지, 며칠 보관되는지, 버전 기록이 있는지. 이번에 오전 반나절이 들어간 이유의 대부분은 이 확인을 몇 년 동안 안 한 데 있었습니다.
모든 공유 파일에 이 규칙을 걸지는 않았습니다
규칙을 만들고 나서 공유 폴더의 다른 파일도 하나씩 따져봤습니다. 가르는 기준은 이렇습니다. 그 파일을 두 사람 이상이 겹쳐서 만지는지, 아니면 사실상 한 사람만 쓰고 나머지는 참고만 하는지입니다. 후자라면 담당 구역을 나누는 규칙 자체가 필요 없고, 오히려 절차만 늘어납니다. 발주 일정표처럼 여러 사람이 실제로 값을 바꾸는 파일에만 이 규칙을 적용하기로 했습니다.
다음으로 보는 것은 동기화 프로그램 쪽입니다. 휴지통과 버전 기록이 있는 프로그램이라면 삭제나 덮어쓰기는 되돌릴 길이 있으니 규칙을 조금 느슨하게 가도 됩니다. 반대로 그런 기능이 없는 방식으로 공유하는 파일이라면, 담당 구역을 나누는 것보다 애초에 겹쳐 쓸 일이 없게 파일 자체를 쪼개는 쪽이 안전하다고 판단했습니다.
대신 손이 한 번 더 갑니다
규칙을 만든 뒤로 같은 사고는 다시 나지 않았습니다. 공짜는 아니었습니다. 담당 구역 밖을 고칠 일이 생기면 메신저로 한 줄 알리고 고치기로 했는데, 이게 매번 자연스럽게 되지는 않습니다. 급하게 숫자 하나만 바꾸면 되는 상황에서도 알림을 보내야 하니, 아주 사소한 수정까지 절차를 태우는 셈이 됩니다.
파일을 열어둔 채 자리를 뜨지 않는다는 규칙도 마찬가지입니다. 원래는 파일을 켜두고 다른 업무를 보다가 돌아와 이어서 고치는 습관이 있었는데, 이제는 수정이 끝나면 그때그때 저장하고 닫아야 합니다. 여러 파일을 오가며 일할 때는 이 여닫는 동작 자체가 이전보다 손이 하나 더 갑니다. 사고를 막는 대가로 받아들이고는 있지만, 편해졌다고 하기는 어렵습니다.
충돌 사본은 지우기 전에 누구 수정분인지부터
- 충돌 사본은 고장이 아니라 양쪽을 다 살리려는 동작입니다. 지우기 전에 어느 쪽 수정분인지 확인합니다.
- 동기화 서비스의 휴지통과 버전 기록은 대체로 기본으로 켜져 있습니다. 사고가 나기 전에 위치를 알아두면 사고 당일의 몇 시간이 몇 분이 됩니다.
- 동기화는 저장된 것만 지킵니다. 저장 안 된 내용의 유실은 동기화가 막아 주지 못합니다.
- 여러 사람이 만지는 파일의 사고는 사람을 고쳐서 막는 게 아니라 규칙을 만들어 막습니다. 이번 사고에서 충돌을 만든 행동 자체는 누구의 잘못도 아니었습니다.
파일 세 개를 대조하던 그 오전이 유쾌한 기억은 아니지만, 덕분에 몇 년 묵은 공유 폴더 운영 방식을 처음으로 글로 적게 됐습니다. 사고 없이 그 규칙이 나올 일은 아마 없었을 겁니다.
이어서 읽을 기록
