최종, 진짜최종, 이게최종. 엑셀 버전관리 두 번 실패하고 배포 방식을 바꿨습니다
지난달 숫자로 만든 보고서가 그대로 올라갔습니다
법인별 월 정산표를 취합해 경영 보고용 요약을 만드는 일이 있습니다. 어느 달, 보고가 올라가고 이틀 뒤에 한 법인의 매입 합계가 다르다는 연락을 받았습니다. 확인해보니 제가 요약에 끌어다 쓴 정산표가 최신본이 아니었습니다. 담당 직원이 수정한 버전은 메일 첨부로 와 있었고, 저는 공유폴더에 있는 파일을 열어 작업했던 겁니다. 두 파일의 이름은 같았고 내용은 달랐습니다.
숫자를 바로잡아 정정 보고를 올리는 것으로 사건 자체는 끝났습니다. 그런데 폴더를 뒤져보니 이 파일의 사본이 여섯 개였습니다. 정산표_최종, 정산표_최종수정, 정산표_0810, 제 PC에 하나, 메일함에 둘. 어느 것이 진짜인지 파일을 전부 열어 셀 값을 비교해야 알 수 있는 상태였습니다. 이 글은 그 상태를 고치려다 두 번 실패하고, 세 번째에 방향을 바꿔 잡은 기록입니다.
첫 시도: 파일명 규칙
가장 먼저 한 일은 파일명 규칙을 만드는 것이었습니다. 날짜와 수정자 이니셜을 뒤에 붙이는 방식으로 정하고, 관련된 사람들에게 공지했습니다. 정산표_20260810_K 같은 식입니다.
한 달을 못 갔습니다.
- 규칙을 지키는 사람이 사실상 저 혼자였습니다. 다른 사람에게 이 규칙은 자기 업무가 아니라 제 요청사항이었고, 바쁜 날에는 요청사항이 먼저 무너집니다.
- 규칙대로 이름을 붙여도 사본이 생기는 것 자체는 막지 못했습니다. 이름이 정돈된 사본 여섯 개는 이름이 엉망인 사본 여섯 개보다 아주 조금 나을 뿐이었습니다.
- 최신 파일이 무엇인지는 알게 됐지만, 두 사람이 같은 날 각자 고치면 최신이 두 개가 됐습니다. 파일명 규칙은 이 상황에 답이 없었습니다.
두 번째 시도: 원본은 공유폴더 한 곳
다음으로 원본 단일화를 선언했습니다. 공유폴더의 파일 하나만 원본이고, 수정은 반드시 거기서 하고, 메일로 엑셀을 보내지 않기로 했습니다.
이번에는 다른 방식으로 무너졌습니다. 사람들이 여전히 사본을 떠서 작업한 뒤에 원본에 붙여넣었습니다. 왜 그러는지 물어보니 답이 뜻밖이었습니다. 원본을 직접 고치다가 망칠까 봐 그런다는 겁니다. 수식이 얽혀 있는 파일이라, 잘못 건드리면 되돌릴 방법을 모르니 자기 자리에서 사본으로 연습하고 결과만 옮긴다는 것이었습니다.
여기서 알게 됐습니다. 사본은 게으름 때문에 생기는 게 아니라 불안 때문에 생깁니다. 되돌리기가 보장되지 않는 파일을 여럿이 만지면, 각자 자기를 지키려고 사본을 뜹니다. 규칙으로 사본을 금지하는 건 불안의 원인을 그대로 두고 증상만 단속하는 일이었습니다.
원본 단일화 선언에는 다른 구멍도 있었습니다. 세무법인이나 외부 담당자에게 자료를 보낼 일이 매달 있는데, 그쪽에는 공유폴더 접근 권한이 없으니 결국 파일을 첨부해 보내야 합니다. 보낸 파일에 상대방이 메모를 달아 회신하면, 그 회신본은 원본도 사본도 아닌 세 번째 무언가가 되어 메일함에 남습니다. 안에서만 통하는 규칙은 밖과 닿는 경계에서 반드시 깨진다는 것도 이때 배웠습니다.
복기: 문제는 편집과 배포가 섞여 있던 것
사본 여섯 개의 출처를 하나씩 따져보니 두 종류였습니다. 고치려고 만든 사본과, 보내려고 만든 사본입니다. 편집용 사본은 망칠까 봐 생겼고, 배포용 사본은 메일에 첨부하느라 생겼습니다. 그러니까 이 파일은 편집 원본과 배포본이라는 서로 다른 두 역할을 파일 하나로 감당하고 있었고, 역할이 섞이니 사본이 늘 수밖에 없었습니다.
사고가 난 그날의 경로도 이 틀로 다시 보면 정확히 설명됩니다. 담당 직원은 배포하려고 사본을 떠서 메일로 보냈고, 그 뒤에 원본이 아닌 자기 사본을 한 번 더 고쳐 다시 보냈습니다. 저는 원본을 열었으니 규칙대로 한 셈인데, 최신 내용은 규칙 밖의 메일 첨부에 있었습니다. 둘 다 자기 기준으로는 잘못한 게 없습니다. 잘못은 사람에게 있지 않고, 최신이 어디 있는지가 구조적으로 정해져 있지 않은 데 있었습니다.
역할을 갈라야 한다는 결론은 여기서 자연스럽게 나왔습니다. 고치는 파일은 한 곳에 하나만 있고 되돌릴 수 있어야 하며, 나가는 파일은 더 이상 고쳐질 수 없어야 합니다. 이 두 성질은 파일 하나가 동시에 가질 수 없는 성질입니다.
세 번째 시도: 규칙이 아니라 구조를 바꿨습니다
세 번째에는 규칙이 아니라 구조를 바꿨습니다.
- 원본은 공유폴더 한 곳에 두되, 동시 편집과 버전 기록이 되는 형태로 바꿨습니다. 누가 언제 무엇을 고쳤는지 자동으로 남고, 이전 상태로 되돌릴 수 있습니다. 되돌리기가 보장되니 원본을 직접 고치는 데 대한 불안이 실제로 줄었습니다.
- 배포는 엑셀 파일을 보내지 않습니다. 보고용으로 나가는 건 PDF로 굳혀서 보냅니다. 받은 쪽에서 수정할 수 없으니 배포본이 새 편집본으로 둔갑하는 경로가 끊겼습니다.
- 파일 첫 시트에 변경 이력 칸을 만들어 큰 수정만 한 줄씩 적습니다. 자동 기록이 있어도, 사람이 읽을 요약은 따로 있어야 대조할 때 빠릅니다.
- 수식이 들어 있는 셀은 잠그고 입력 칸만 열어뒀습니다. 망칠 수 있는 범위 자체를 좁힌 겁니다.
이 구조를 다른 사람에게 설명할 때는 원본과 사본을 나누는 게 아니라 고치는 파일과 보내는 파일을 나누는 것이라고 말합니다. 처음에는 다들 파일명 규칙이나 폴더 정리 이야기인 줄 알고 듣는데, 실제로 바뀐 건 파일이 하는 역할이었습니다. 이 구분을 먼저 설명해야 왜 배포는 PDF로만 나가는지, 왜 편집 파일은 잠긴 셀이 많은지가 납득이 됩니다.
전환에는 저항도 있었습니다. 동시 편집 형태로 바꾼 첫 주에는 열이 밀린다, 익숙한 단축키가 다르게 먹는다는 불평이 나왔고, 실제로 복잡한 수식 하나는 새 환경에서 다시 만들어야 했습니다. 하루치 품이 들었습니다. 그래도 되돌리기 기능을 한 번씩 직접 보여주고 나니 분위기가 달라졌습니다. 망쳐도 돌아간다는 걸 눈으로 확인한 뒤에야 사람들이 원본을 직접 만지기 시작했습니다. 구조를 바꾸는 일의 절반은 도구 설정이었고, 나머지 절반은 이 시연이었습니다.
바꾸고 두 달이 지난 시점에 사본 개수를 다시 세어봤습니다. 편집용 사본은 없어졌고, 남는 건 PDF 배포본뿐인데 이건 수정될 수 없는 파일이라 세는 의미가 없습니다. 어느 것이 진짜인지 묻는 일 자체가 사라졌습니다.
혼자 쓰는 파일에는 과합니다
모든 파일에 이 구조가 필요하지는 않습니다. 여러 사람이 고치는 파일인지, 밖으로도 나가는 파일인지가 기준입니다. 혼자 만들고 혼자 보는 파일이라면 사본이 여섯 개씩 생길 일도 없으니 구조를 바꿀 이유가 없습니다. 여러 사람이 고치면서 동시에 외부로도 나가는 파일에서만 이 구분이 값을 합니다.
동시 편집과 버전 기록이 되는 환경도 전제입니다. 이게 안 되는 환경이라면 되돌리기가 보장되지 않으니, 사람들이 원본을 직접 고치는 데 대한 불안이 그대로 남습니다. 환경이 먼저고, 역할 분리는 그다음입니다.
PDF로 굳히는 한 단계가 늘었습니다
배포 직전에 PDF로 바꾸는 손질이 매번 한 번씩 더 들어갑니다. 예전에는 엑셀 파일을 그대로 첨부하면 끝이었는데, 이제는 PDF로 바꾸고 그 안에서 페이지가 깨지지 않았는지 확인하는 절차가 하나 늘었습니다. 큰 손은 아니지만 매달 한 번씩 빠짐없이 해야 하는 일입니다.
변경 이력 칸을 만든 뒤로도 이 칸을 채우는 걸 깜빡하는 일이 몇 번 있었습니다. 자동으로 남는 기록과 별개로 사람이 한 줄 요약을 적어야 하는데, 급하게 수정한 날일수록 이 칸을 놓치기 쉬웠습니다. 결국 큰 수정을 한 사람에게 이력 칸을 확인해달라고 따로 알리는 절차를 하나 더 붙였습니다.
고치는 파일과 보내는 파일을 가른 뒤의 원칙
- 사본이 자꾸 생기는 파일은 사람을 단속하지 않고 이유를 물어봅니다. 망칠까 봐 생기는 사본은 되돌리기를 보장해야 없어지고, 보내느라 생기는 사본은 배포 형식을 바꿔야 없어집니다.
- 편집할 파일과 배포할 파일을 같은 파일로 쓰지 않습니다. 고칠 수 있는 상태로 나간 파일은 언젠가 어딘가에서 다른 원본이 되어 돌아옵니다.
- 파일명 규칙은 마지막 수단입니다. 구조로 막을 수 있는 문제를 사람의 성실함으로 막으려 하면, 가장 바쁜 날에 무너집니다.
- 외부와 주고받는 파일은 처음부터 왕복을 설계합니다. 상대가 고쳐서 돌려보낼 파일이면 회신본을 원본에 반영하는 담당과 시점을 정해두고, 고칠 일이 없는 파일이면 PDF로 보냅니다.
전수 조사를 해보니 네 개 법인을 통틀어 사본이 여섯 개씩 생기던 그런 파일은 대여섯 개뿐이었고, 그 대여섯 개만 옮기는 것으로 충분했습니다.
정정 보고를 올리던 날에는 파일명을 어지럽게 쓴 사람들의 문제라고 생각했습니다. 지금 와서 보면 이름 붙일 파일이 여섯 개가 되도록 놔둔 구조의 문제였습니다.
두 번의 실패를 거치며 배운 것 중 하나는, 사람들이 규칙을 안 지킨다고 느껴질 때 그 사람을 탓하기 전에 규칙이 요구하는 행동이 그 사람 입장에서 합리적인지부터 봐야 한다는 점입니다. 사본을 뜨는 행동은 파일명 규칙 시절에도, 원본 단일화 시절에도 각자에게는 나름의 이유가 있는 선택이었습니다. 그 이유를 없애지 않고 행동만 금지하려 했던 게 두 번의 시도가 무너진 진짜 이유였습니다.
지금은 다른 부서에서 비슷한 사본 문제가 보이면 파일명 규칙부터 권하지 않습니다. 대신 그 사본이 편집용인지 배포용인지부터 물어봅니다. 두 가지가 섞인 파일은 규칙을 아무리 잘 짜도 오래가지 못했습니다.
이어서 읽을 기록
