데이터 관리는 처음부터 중요하다고 생각했지만, 막상 실무에서는 “일단 저장해두면 나중에 찾겠지”라는 식으로 처리한 적이 많았습니다. 문제는 데이터가 쌓일수록 저장하는 것보다 찾고 검증하는 시간이 더 많이 든다는 점이었습니다. 저는 한동안 엑셀 파일, 구글 드라이브, 메신저 첨부파일, 개인 다운로드 폴더에 데이터를 흩어놓고 일했습니다. 당시에는 급한 업무를 빨리 처리하는 방식이라고 생각했지만, 나중에 돌아보니 그 구조 때문에 매주 몇 시간씩 낭비하고 있었습니다.
이번 글은 제가 2024년 1월부터 2024년 7월까지 약 7개월 동안 데이터 관리 방식을 잘못 운영하면서 겪은 시간 낭비 사례를 정리한 후기입니다. 업무는 광고 성과 데이터, 콘텐츠 발행 데이터, 거래처 입금 데이터, 월간 보고서 원본 파일 관리였습니다. 관리한 데이터 파일은 총 214개였고, 월평균 원본 데이터 행 수는 약 32,000행이었습니다. 처음에는 파일명과 저장 위치 기준이 없었고, 이후 기준을 세우면서 실제 업무 시간이 얼마나 줄었는지 기록했습니다.
처음 데이터 관리 방식: 저장 위치가 4곳으로 흩어져 있었다
가장 큰 문제는 저장 위치였습니다. 광고 성과 파일은 제 개인 다운로드 폴더에 있고, 콘텐츠 일정표는 구글 드라이브에 있고, 거래처 입금 내역은 메일 첨부파일에 남아 있고, 월간 보고서 최종본은 메신저 대화방에 올라가 있었습니다. 당시에는 파일을 받은 곳에서 바로 열어 작업했기 때문에 저장 위치가 흩어지는 것을 크게 문제로 생각하지 않았습니다.
하지만 월말 보고서를 만들 때 문제가 터졌습니다. 2024년 2월 월간 광고 보고서를 작성하면서 전월 데이터와 당월 데이터를 비교해야 했습니다. 필요한 파일은 총 9개였습니다. 광고 플랫폼 원본 CSV 4개, 전월 보고서 1개, 콘텐츠 발행표 1개, 전환 데이터 2개, 비용 정산표 1개였습니다. 그런데 이 9개 파일이 4곳에 흩어져 있었습니다. 파일을 찾는 데만 46분이 걸렸습니다. 보고서 작성 전 준비 시간이 1시간 가까이 걸린 것입니다.
실패 사례 1: 파일명 기준이 없어 잘못된 데이터를 썼다
가장 크게 실수한 사례는 2024년 3월 광고 성과 보고서였습니다. 당시 다운로드 폴더에 비슷한 이름의 파일이 여러 개 있었습니다. “campaign_report.csv”, “campaign_report(1).csv”, “campaign_report_final.csv”, “campaign_report_final_수정.csv” 같은 식이었습니다. 저는 그중 “final”이 붙은 파일을 최종본이라고 생각하고 보고서에 사용했습니다.
나중에 확인해보니 실제 최종 데이터는 구글 드라이브에 있던 “2024-03_ads_raw_v2.csv”였습니다. 제가 사용한 파일은 3월 25일까지의 중간 데이터였고, 최종 데이터에는 3월 31일까지의 성과가 포함되어 있었습니다. 차이는 꽤 컸습니다. 보고서에 들어간 총 전환 수는 4,218건이었지만, 실제 최종 전환 수는 4,761건이었습니다. 543건 차이였고, 비율로는 약 11.4% 누락이었습니다.
다행히 외부 제출 전 내부 검토에서 발견했지만, 수정에 걸린 시간은 1시간 32분이었습니다. 원본 파일을 다시 찾고, 피벗테이블을 새로 만들고, 그래프 6개와 코멘트 4개를 수정해야 했습니다. 이때 처음으로 파일명 규칙이 없는 것이 단순히 지저분한 문제가 아니라 보고서 신뢰도까지 흔들 수 있다는 것을 느꼈습니다.
실패 사례 2: 같은 데이터를 여러 사람이 다르게 수정했다
두 번째 문제는 버전 관리였습니다. 콘텐츠 발행 데이터는 팀원 5명이 함께 수정했습니다. 제목, 담당자, 발행일, 키워드, 상태, 수정 요청 메모를 관리하는 표였고, 월평균 콘텐츠 항목은 48개였습니다. 처음에는 엑셀 파일을 공유하면서 각자 수정 후 다시 보내는 방식이었습니다.
2024년 4월 둘째 주에 실제 문제가 생겼습니다. 콘텐츠 일정표 파일이 총 5개 버전으로 나뉘었습니다. “콘텐츠일정_수정”, “콘텐츠일정_최종”, “콘텐츠일정_디자인반영”, “콘텐츠일정_발행팀확인”, “콘텐츠일정_최종2”가 동시에 존재했습니다. 이 중 한 파일에는 발행일이 4월 18일로 되어 있었고, 다른 파일에는 4월 19일로 되어 있었습니다. 결국 블로그 글 2개가 예약 발행되지 않았고, 다음 날 오전에 수동으로 발행했습니다.
이 사건으로 발행 지연은 2건 발생했고, 원인을 찾는 데 38분, 일정표를 다시 합치는 데 55분이 걸렸습니다. 총 1시간 33분을 버전 정리에 쓴 셈입니다. 그 후로 여러 명이 수정하는 데이터는 엑셀 파일로 주고받지 않고, 구글 스프레드시트 한 문서에서만 수정하도록 바꿨습니다.
실패 사례 3: 원본과 가공본을 구분하지 않았다
세 번째 문제는 원본 데이터와 가공 데이터를 같은 폴더에 넣은 것이었습니다. 광고 플랫폼에서 내려받은 원본 CSV와 제가 열을 추가하고 수식을 넣은 가공 파일이 한 폴더에 섞여 있었습니다. 파일명도 비슷하다 보니 나중에 어떤 파일이 원본인지 헷갈렸습니다.
2024년 5월 입금 확인 업무에서 이 문제가 크게 드러났습니다. 거래처 입금 내역 원본은 2,840행이었고, 제가 거래처 코드와 상태값을 붙인 가공본은 2,840행에 열이 5개 추가된 파일이었습니다. 그런데 다음 달 비교 작업을 할 때 가공본을 원본으로 착각하고 다시 가공했습니다. 그 결과 상태값 열이 중복으로 생기고, 일부 거래처 코드가 덮어씌워졌습니다.
문제를 발견했을 때 거래처 코드 오류가 27건 있었습니다. 이 중 8건은 입금 확인 상태가 잘못 표시됐습니다. 수정에는 총 1시간 18분이 걸렸습니다. 이 경험 이후 저는 폴더를 원본, 작업중, 최종본, 보관으로 나눴습니다. 원본 폴더 파일은 절대 직접 수정하지 않고, 작업할 때는 반드시 복사본을 만들어 사용했습니다.
데이터 관리 방식 변경 전 실제 낭비 시간
2024년 1월부터 3월까지 3개월 동안 제가 기록한 데이터 관련 낭비 시간은 생각보다 컸습니다. 파일 찾기에 월평균 3시간 20분, 버전 확인에 월평균 2시간 10분, 잘못된 데이터 수정에 월평균 1시간 45분, 중복 입력 제거에 월평균 52분을 썼습니다. 모두 합치면 월평균 약 8시간 7분이었습니다.
특히 월말 보고서 주간에는 낭비 시간이 더 컸습니다. 2024년 3월 마지막 주에는 데이터 파일을 찾고 검증하는 데만 총 3시간 45분을 썼습니다. 실제 보고서 해석보다 파일 찾기와 숫자 맞추기에 더 많은 시간을 쓴 날도 있었습니다. 이때부터 데이터 관리 방식을 바꾸지 않으면 매월 같은 문제가 반복될 것이라고 판단했습니다.
개선 1단계: 파일명 규칙부터 만들었다
가장 먼저 바꾼 것은 파일명 규칙이었습니다. 새 기준은 단순하게 만들었습니다. 날짜, 업무명, 데이터 종류, 버전 순서로 적었습니다. 예를 들어 “2024-05_ads_raw_v1”, “2024-05_ads_working_v1”, “2024-05_ads_final_v1”처럼 정했습니다. 날짜는 항상 연도-월 또는 연도-월-일 형식으로 통일했습니다.
이 규칙을 적용하는 데 처음에는 시간이 걸렸습니다. 기존 파일 214개 중 자주 쓰는 파일 86개를 먼저 정리했고, 파일명 변경과 폴더 이동에 총 3시간 40분이 걸렸습니다. 하지만 이후 파일 찾는 시간이 줄었습니다. 기존에는 특정 원본 파일 하나를 찾는 데 평균 6분 30초가 걸렸는데, 개선 후에는 평균 1분 45초로 줄었습니다.
개선 2단계: 폴더 구조를 4단계로 고정했다
두 번째로 폴더 구조를 고정했습니다. 업무별로 폴더를 나누고, 그 안에 원본, 작업중, 최종본, 보관 폴더를 만들었습니다. 광고 데이터, 콘텐츠 데이터, 입금 데이터, 보고서 데이터 모두 같은 구조를 적용했습니다.
예전에는 폴더 구조가 업무마다 달랐습니다. 광고 폴더에는 월별 폴더가 있고, 콘텐츠 폴더에는 담당자별 폴더가 있고, 입금 폴더에는 파일이 그대로 쌓여 있었습니다. 그러다 보니 다른 팀원이 파일을 찾기 어려웠습니다. 개선 후에는 팀원 5명에게 20분 정도 설명했고, 한 달 뒤 파일 위치 문의가 줄었습니다. 2024년 3월에는 파일 위치 질문이 23건이었는데, 2024년 6월에는 7건으로 줄었습니다.
개선 3단계: 원본 데이터 보호 기준을 만들었다
원본 데이터는 절대 수정하지 않는다는 기준도 만들었습니다. 원본 폴더에 들어간 파일은 읽기 전용처럼 취급했습니다. 가공이 필요하면 작업중 폴더로 복사한 뒤 수식, 피벗테이블, 추가 열을 넣었습니다. 최종 보고서에 반영한 파일만 최종본 폴더로 옮겼습니다.
이 기준을 만든 뒤 원본 훼손 문제가 줄었습니다. 2024년 1월부터 3월까지는 원본과 가공본 혼선으로 인한 오류가 총 9건 있었습니다. 2024년 5월부터 7월까지는 2건으로 줄었습니다. 완전히 없어지지는 않았지만, 오류를 찾는 시간이 크게 줄었습니다. 원본이 따로 남아 있으니 문제가 생겨도 다시 시작할 수 있었습니다.
데이터 관리 변경 전후 비교
| 구분 | 변경 전 | 변경 후 | 개선 결과 |
|---|---|---|---|
| 월평균 파일 수 | 약 30개 | 약 32개 | 업무량 유사 |
| 특정 파일 검색 시간 | 평균 6분 30초 | 평균 1분 45초 | 약 73% 감소 |
| 월 데이터 관련 낭비 시간 | 8시간 7분 | 2시간 35분 | 월 5시간 32분 절약 |
| 파일 위치 문의 | 월 23건 | 월 7건 | 약 70% 감소 |
| 버전 혼선 오류 | 월 5~6건 | 월 1~2건 | 검증 부담 감소 |
| 대표 실패 사례 | 11.4% 전환 수 누락 | 원본·최종본 분리 | 보고서 수정 시간 감소 |
개선 후 실제 업무 시간 변화
데이터 관리 기준을 바꾼 뒤 가장 먼저 줄어든 것은 파일 찾는 시간이었습니다. 2024년 6월에는 월간 보고서 작성 전 필요한 파일 10개를 준비하는 데 12분이 걸렸습니다. 2월에는 같은 수준의 파일을 찾는 데 46분이 걸렸으니 34분이 줄었습니다.
보고서 작성 전체 시간도 줄었습니다. 2024년 3월 월간 보고서 작성에는 총 6시간 20분이 걸렸습니다. 이 중 데이터 확인과 파일 정리에만 약 2시간이 쓰였습니다. 2024년 6월에는 같은 유형의 보고서를 4시간 35분에 끝냈습니다. 절약된 시간은 1시간 45분이었습니다. 자료를 찾는 시간이 줄어드니 보고서 코멘트 작성과 원인 분석에 더 많은 시간을 쓸 수 있었습니다.
데이터 관리에서 가장 중요한 것은 저장보다 기준이었다
이번 경험을 통해 느낀 것은 데이터를 많이 저장하는 것보다 어떤 기준으로 저장하는지가 더 중요하다는 점입니다. 예전에는 자료를 잃어버리지 않기 위해 일단 저장했습니다. 하지만 저장 위치와 파일명이 정리되지 않으면 저장한 자료는 없는 자료와 비슷했습니다. 필요할 때 찾지 못하면 의미가 없었습니다.
지금은 데이터를 받을 때 바로 세 가지를 확인합니다. 이 파일이 원본인지, 어느 업무에 속하는지, 언제 다시 쓸 가능성이 있는지입니다. 원본이면 원본 폴더에 넣고 수정하지 않습니다. 작업용이면 작업중 폴더에 복사합니다. 보고서에 반영한 파일은 최종본 폴더로 옮깁니다. 3개월이 지난 파일은 보관 폴더로 옮기고, 중복 파일은 삭제합니다.
최종 결론: 잘못된 데이터 관리는 조용히 시간을 잡아먹는다
7개월 동안 데이터 관리 방식을 바꾸며 가장 크게 느낀 것은 잘못된 데이터 관리가 생각보다 조용히 시간을 잡아먹는다는 점입니다. 처음에는 파일 찾는 데 5분, 버전 확인하는 데 10분 정도를 사소하게 여겼습니다. 하지만 기록해보니 월평균 8시간 7분을 데이터 정리 오류와 검색에 쓰고 있었습니다. 기준을 세운 뒤 이 시간은 월 2시간 35분으로 줄었습니다. 월 5시간 32분을 절약한 셈입니다.
실패 사례도 분명했습니다. 잘못된 중간 파일을 사용해 전환 수 543건, 약 11.4%를 누락했고, 콘텐츠 일정표 버전 5개가 생기며 발행 지연 2건이 발생했습니다. 원본과 가공본을 구분하지 않아 거래처 코드 오류 27건도 만들었습니다. 이 문제들은 모두 데이터 자체가 어려워서 생긴 것이 아니라, 관리 기준이 없어서 생긴 일이었습니다.
지금 제 기준은 단순합니다. 파일명은 날짜와 업무명, 데이터 종류, 버전을 넣는다. 저장 위치는 원본, 작업중, 최종본, 보관으로 나눈다. 여러 명이 수정하는 데이터는 파일로 주고받지 않는다. 원본은 절대 직접 수정하지 않는다. 월 1회 오래된 파일을 정리한다. 이 다섯 가지를 지키는 것만으로도 업무가 훨씬 안정됐습니다.
데이터 관리 방식이 복잡할 필요는 없습니다. 하지만 기준이 없으면 파일은 늘어나고, 사람마다 다른 버전을 보고, 보고서 숫자는 흔들립니다. 저도 처음에는 정리 시간을 아끼려고 대충 저장했지만, 결국 더 많은 시간을 잃었습니다. 데이터 관리에서 중요한 것은 멋진 시스템이 아니라, 팀원 누구나 같은 파일을 찾고 같은 기준으로 수정할 수 있는 단순한 구조였습니다.