화상회의 녹화본 자동 업로드 4주 후기

처음에는 화상회의 녹화본 업로드를 자동화하면 일이 거의 끝날 줄 알았습니다. Zoom이나 Google Meet에서 녹화가 끝나면 Google Drive로 올라가고, Slack에 알림만 오면 된다고 생각했습니다. 그런데 2026년 4월 1일부터 4월 28일까지 4주 동안 실제로 운영해보니, 자동 업로드 자체보다 업로드 후 확인, 파일명 규칙, 공유 권한 검증이 훨씬 중요했습니다. 자동화는 시작일 뿐이고, 검증 기준이 없으면 파일이 올라가도 팀원이 못 보거나 같은 이름으로 덮어쓰기될 뻔한 일이 생겼습니다.

사용 도구는 Zoom, Google Meet, Google Drive, Make, Slack이었습니다. 일부 반복 흐름은 Zapier로도 테스트했지만, 최종 운영은 Make 시나리오를 기준으로 잡았습니다. 4주 동안 업로드한 녹화본 수는 총 52개였고, 전체 녹화 용량은 64.8GB였습니다. 평균 녹화본 길이는 38분이었고, 주간회의, 고객 미팅, 내부 리뷰, 프로젝트 킥오프 녹화가 섞여 있었습니다. 자동 업로드 성공 횟수는 45회, 자동 업로드 실패 횟수는 7회였습니다.

자동화 전에는 수동 업로드가 생각보다 많이 새고 있었다

자동화 전에는 회의가 끝나면 녹화본을 내려받고, 파일명을 바꾸고, Google Drive 폴더에 올리고, Slack에 링크를 공유했습니다. 이 과정이 회의 1건당 평균 7분 40초 걸렸습니다. 하루에 회의가 3개 있는 날에는 녹화본 정리만 20분 이상 걸렸고, 바쁜 날에는 “나중에 올려야지” 하고 미뤄둔 파일이 쌓였습니다.

특히 금요일 오후 회의 녹화본이 자주 밀렸습니다. 3월 말 기준으로 수동 업로드 누락 또는 지연이 7건 있었고, 그중 3건은 팀원이 “녹화본 어디 있나요?”라고 Slack에서 다시 물어본 뒤에야 올렸습니다. 이 경험 때문에 4월부터 회의 녹화본 자동 업로드를 실험했습니다.

초기 자동화 구조와 실제 운영 방식

초기 구조는 단순했습니다. Zoom 또는 Google Meet 녹화가 생성되면 Make가 파일을 감지하고, Google Drive의 회의 녹화 폴더에 업로드한 뒤 Slack 채널에 링크를 보내는 방식이었습니다. 처음에는 폴더를 회의 유형별로만 나눴습니다. 예를 들어 주간회의, 고객회의, 내부리뷰, 기타회의 정도였습니다.

문제는 파일명과 권한이었습니다. 자동 업로드는 됐지만 파일명이 회의 제목만 들어가면 같은 이름이 반복됐고, Google Drive 권한이 기본 비공개로 남아 팀원이 접근하지 못하는 일이 생겼습니다. 4주 동안 권한 설정 오류는 5건, 파일명 중복 오류는 4건, 업로드 완료 알림 누락은 6건 발생했습니다.

실패 사례 1: 회의 제목이 같아 파일이 덮어쓰기될 뻔했다

가장 위험했던 사례는 4월 8일과 4월 15일에 있던 “주간회의” 파일이었습니다. 둘 다 회의 제목이 같았고, 처음 자동화 설정에서는 파일명이 단순히 주간회의.mp4로 생성됐습니다. 두 번째 파일이 업로드될 때 기존 파일과 이름이 같아 덮어쓰기될 뻔했습니다. 실제로 Google Drive에서 사본 처리되긴 했지만, 파일명만 보면 어떤 날짜의 회의인지 구분할 수 없었습니다.

이때부터 파일명 규칙을 바꿨습니다. 날짜, 회의명, 팀명, 버전명을 반드시 넣었습니다. 실제 파일명 예시는 2026-04-15_주간회의_teamA_v1.mp4였습니다. 같은 날 같은 회의가 다시 올라가면 v2를 붙였고, 고객사 회의는 팀명 대신 고객사 약어를 넣었습니다. 이 규칙을 적용한 뒤 파일명 중복 오류는 후반 2주 동안 0건으로 줄었습니다.

실패 사례 2: 자동 업로드는 됐지만 팀원이 보지 못했다

두 번째 실패는 권한이었습니다. 4월 11일 Google Meet 녹화본은 Google Drive에 정상 업로드됐고, Slack 알림도 왔습니다. 그런데 팀원 2명이 링크를 눌렀을 때 “액세스 권한이 필요합니다”라는 화면이 떴습니다. 업로드는 성공했지만 공유 권한이 비공개였던 것입니다. 이 파일은 고객 미팅 리뷰용이었고, 팀원이 확인하지 못해 다음 날 오전 리뷰가 30분 밀렸습니다.

이후 자동화 단계에 업로드 후 권한 확인을 넣었습니다. 완전 공개가 아니라 팀 도메인 내부 보기 가능으로 설정하고, 외부 공유가 필요한 파일은 별도 공유용 폴더로 복사했습니다. 권한 설정 오류는 초반 2주 5건에서 후반 2주 0건으로 줄었습니다.

자동 업로드 개선표

항목	자동화 전	자동화 후	오류 사례	개선 기준	실제 효과
업로드 시간	회의 1건당 평균 7분 40초	확인 시간 평균 1분 50초	회의 후 파일을 나중에 올리며 누락 발생	자동 업로드 후 Slack 알림 확인	주간 정리 시간 3시간 10분에서 48분으로 감소
업로드 성공률	수동 처리라 담당자 상태에 따라 편차 발생	52개 중 45회 성공, 7회 실패	녹화 파일 생성 지연으로 자동 감지 실패	실패 시 재시도 알림 생성	최종 누락 파일을 주간 점검에서 회수
권한 오류	파일마다 수동 공유	자동 권한 적용	업로드됐지만 비공개라 팀원이 못 봄	팀 도메인 보기 가능 기본값 설정	권한 설정 오류 5건 이후 0건으로 안정
파일명 중복	회의명만 사용	날짜, 회의명, 팀명, 버전명 사용	주간회의 파일이 덮어쓰기될 뻔함	2026-04-15_주간회의_teamA_v1.mp4 형식	파일명 중복 오류 4건 이후 추가 발생 없음
알림 안정성	업로드 후 사람이 Slack 공유	업로드 후 Slack 자동 알림	업로드 완료 알림 누락 6건	Drive 링크, 파일 용량, 업로드 시간 포함	알림만 보고도 확인 가능해짐
저장공간	파일 위치가 분산됨	Drive 회의 녹화 폴더로 통합	64.8GB가 한 폴더에 몰려 정리 부담 증가	월별 폴더와 보관 기준 설정	오래된 파일 정리 기준이 생김

자동 업로드 실패 7회가 발생한 이유

자동 업로드 실패 7회는 대부분 도구 문제가 아니라 조건 설정 문제였습니다. 첫 번째는 녹화 파일 생성 시간이 예상보다 늦은 경우였습니다. 회의 종료 후 바로 파일이 생기는 줄 알았지만, 긴 회의는 변환 시간이 10분 이상 걸렸습니다. Make가 너무 빨리 감지하려고 하면서 실패한 경우가 3회 있었습니다.

두 번째는 Google Drive 폴더 경로 오류였습니다. 폴더명을 중간에 바꾸면서 자동화 시나리오가 기존 경로를 보고 있던 일이 2회 있었습니다. 세 번째는 파일 용량 문제였습니다. 1시간이 넘는 녹화본 2개가 각각 2GB를 넘었고, 업로드는 됐지만 Slack 알림 단계에서 링크 생성이 늦어져 실패로 기록됐습니다.

Slack 알림 형식을 바꾼 뒤 확인 시간이 줄었다

처음 Slack 알림은 단순했습니다. “회의 녹화본이 업로드되었습니다”라는 문구와 Drive 링크만 보냈습니다. 그런데 링크만 있으면 어떤 회의인지, 파일 용량이 얼마인지, 권한이 정상인지 다시 눌러봐야 했습니다. 그래서 알림 형식을 바꿨습니다.

[녹화본 업로드 완료]
파일명: 2026-04-15_주간회의_teamA_v1.mp4
회의 길이: 38분
파일 용량: 1.24GB
저장 위치: Google Drive > 2026-04 > 주간회의
권한: teamA 보기 가능
확인 필요: 담당자 1명

이 형식을 적용한 뒤 자동화 후 확인 시간은 회의 1건당 평균 1분 50초로 줄었습니다. 자동화 전 수동 업로드 시간이 평균 7분 40초였으니, 회의 1건당 약 5분 50초를 줄인 셈입니다.

주간 정리 시간이 크게 줄었다

자동화 전에는 매주 금요일마다 녹화본을 정리하는 데 평균 3시간 10분이 걸렸습니다. 파일을 다운로드했는지, Drive에 올렸는지, Slack에 공유했는지 하나씩 확인해야 했습니다. 특히 Zoom 녹화와 Google Meet 녹화가 섞이면 위치가 달라 더 헷갈렸습니다.

자동화 후에는 주간 정리 시간이 평균 48분으로 줄었습니다. 완전히 0분이 되지는 않았습니다. 자동 업로드 성공 여부, 권한, 파일명, 용량을 확인해야 했기 때문입니다. 하지만 정리 시간이 줄어든 것보다 더 좋았던 점은 누락 파일을 금요일에 몰아서 찾지 않아도 된다는 점이었습니다. Slack 알림이 오지 않은 파일만 확인하면 됐습니다.

저장공간 문제도 뒤늦게 나타났다

4주 동안 전체 녹화 용량은 64.8GB였습니다. 처음에는 Drive 용량을 크게 신경 쓰지 않았습니다. 그런데 3주 차에 월별 폴더 용량이 빠르게 늘어나는 것을 보고 보관 기준이 필요하다는 것을 알았습니다. 평균 녹화본 길이는 38분이었지만, 1시간 이상 회의도 9개 있었고, 이 파일들이 용량을 많이 차지했습니다.

이후 저장공간 기준을 만들었습니다. 내부 회의 녹화본은 90일 보관, 고객 회의 녹화본은 프로젝트 종료 후 180일 보관, 교육용 회의는 별도 보관 폴더로 이동했습니다. 자동 업로드만 만들고 보관 정책이 없으면 Drive가 금방 지저분해질 수 있었습니다.

비교 기준별 실제 결과

비교 기준	측정 결과	느낀 점
업로드 성공률	52개 중 45회 자동 성공	자동화도 실패 감지 기준이 필요했다
권한 오류	총 5건 발생	업로드 성공과 공유 성공은 다른 문제였다
파일명 중복	총 4건 발생	회의명만으로는 관리가 불가능했다
알림 안정성	업로드 완료 알림 누락 6건	Slack 알림이 없으면 자동화 성공을 믿기 어려웠다
저장공간 사용량	4주간 64.8GB	보관 기간과 삭제 기준이 필요했다

가장 효과가 있었던 개선 기준

가장 효과가 있었던 것은 파일명 규칙과 업로드 후 Slack 알림이었습니다. 파일명은 날짜, 회의명, 팀명, 버전명을 넣었습니다. 예시는 2026-04-15_주간회의_teamA_v1.mp4입니다. 이 형식을 쓰니 검색도 쉬워졌고, 같은 회의명이 반복되어도 구분이 됐습니다.

Slack 알림은 단순 공유가 아니라 검증 메시지처럼 사용했습니다. 파일명, 용량, Drive 위치, 권한 상태가 표시되게 했습니다. 덕분에 업로드 후 사람이 해야 할 일은 파일을 다시 올리는 것이 아니라, 자동화가 맞게 되었는지 확인하는 것으로 바뀌었습니다.

최종 결론: 자동 업로드보다 업로드 후 검증이 더 중요했다

2026년 4월 1일부터 4월 28일까지 4주 동안 회의 녹화본 자동 업로드를 운영하면서, 화상회의 녹화본 자동화는 단순히 파일을 Drive로 옮기는 문제가 아니라는 것을 알게 됐습니다. 총 52개의 녹화본을 업로드했고, 전체 용량은 64.8GB였습니다. 자동 업로드 성공은 45회였고, 실패는 7회였습니다.

수동 업로드는 회의 1건당 평균 7분 40초가 걸렸지만, 자동화 후 확인 시간은 평균 1분 50초로 줄었습니다. 주간 정리 시간도 3시간 10분에서 48분으로 감소했습니다. 하지만 권한 설정 오류 5건, 파일명 중복 오류 4건, 업로드 완료 알림 누락 6건을 겪으며 자동화만 믿으면 안 된다는 것을 배웠습니다.

결론적으로 화상회의 녹화본 자동 업로드는 자동화보다 업로드 후 확인과 권한 검증이 더 중요했습니다. 파일이 올라갔다고 끝이 아니었습니다. 팀원이 볼 수 있는지, 파일명이 중복되지 않는지, Slack 알림이 왔는지, 저장공간 기준에 맞는지까지 확인해야 실무에서 안정적으로 쓸 수 있었습니다.

회의 녹화본 자동 업로드 전 확인해야 할 체크리스트

파일명에 날짜, 회의명, 팀명, 버전명이 포함되어 있는가?
예시처럼 2026-04-15_주간회의_teamA_v1.mp4 형식으로 저장되는가?
Zoom과 Google Meet 녹화 파일 생성 지연을 고려했는가?
Google Drive 업로드 후 권한이 팀 내부 보기 가능으로 설정되는가?
외부 공유 파일은 별도 공유용 폴더로 분리되는가?
업로드 완료 시 Slack에 파일명, 용량, 위치, 권한이 함께 표시되는가?
Slack 알림 누락 시 실패로 감지할 기준이 있는가?
같은 회의명이 반복될 때 v1, v2처럼 버전이 붙는가?
월별 폴더로 저장되어 나중에 검색하기 쉬운가?
전체 저장공간과 보관 기간 기준을 정했는가?
자동 업로드 실패 파일을 주 1회 점검하는 시간이 있는가?
자동화 성공과 공유 성공을 별도로 확인하고 있는가?