구글 시트·앱스스크립트 거래처별 업무 자동화

문제

이 고객사는 광고대행 사업을 새로 시작하면서 거래처를 하나씩 받기 시작하는 단계였습니다. 첫 거래처가 다음 주부터 자료를 올리고 보고서를 받기로 되어 있었고 이후로도 거래처가 계속 붙을 예정이었습니다. 문제는 거래처가 늘 때마다 운영자가 손으로 처리해야 할 일이 그만큼 비례해서 늘어난다는 점이었습니다. 거래처별 자료를 어디에 두고 누구에게 어디까지 보여줄지, 매달 광고비를 어떻게 집계해 보고할지, 자료가 올라오면 누가 언제 확인하는지가 전부 사람의 기억과 반복 작업에 의존하고 있었습니다.

권한이 특히 까다로웠습니다. 같은 폴더 안에 거래처에 보여줄 자료와 본사만 봐야 할 내부 자료가 섞여 있으면 사고가 나기 쉽습니다. 거래처 A의 담당자가 거래처 B의 자료나 본사 내부 정산을 볼 수 있으면 안 되고 그렇다고 거래처마다 권한을 하나하나 수기로 관리하면 거래처가 늘수록 실수가 쌓입니다. 자료 공유의 경계가 처음부터 구조로 정해져 있어야 했습니다.

집계와 보고도 손이 많이 가는 일이었습니다. 매체별(구글·네이버·유튜브 등) 광고비를 월별로 모으고 소진액과 충전액에서 집행 금액과 잔액을 계산해 거래처가 읽을 수 있는 보고서로 만드는 작업이 매달 반복됩니다. 여기에 자료가 올라올 때마다, 일정이 잡히거나 바뀔 때마다 관련자에게 알려주는 일까지 더해지면, 운영자 한 사람이 감당하기 어려운 양이 됩니다.

마지막 조건은 운영 주체였습니다. 이 시스템은 개발자가 아니라 사업 운영자가 직접 이해하고 굴려야 했습니다. 별도 서버나 낯선 관리 도구를 새로 배우는 방식이 아니라, 이미 쓰고 있는 구글 워크스페이스 안에서 자연스럽게 돌아가고 새 거래처 추가도 매뉴얼대로 따라 하면 되는 구조여야 했습니다.

접근

폴더 트리는 앱스스크립트로 한 번에 생성합니다. 거래처 루트 아래에 공유 자료, 보고 자료(구글·네이버·유튜브·기타), 월별 자료(광고비 보고서·세금계산서·플랫폼 보고서)가 정해진 형태로 만들어지고 이때 반환되는 폴더 ID 맵이 그대로 알림 배선에 쓰입니다. 즉 폴더를 만드는 일과 그 폴더를 감시해 알림을 보내는 일이 같은 설정에서 이어집니다.

일정은 시트와 캘린더를 함께 씁니다. 거래처별 일정 시트를 두고 본사는 IMPORTRANGE로 거래처 시트들을 한 화면에 모아 통합 뷰로 봅니다. 일정 시트에 변화가 생기면 앱스스크립트 onEdit 트리거가 등록·변경·삭제를 감지해 관련자에게 알림을 보내고 매일 오전 정해진 시각에 다음 날 일정을 리마인드합니다.

알림 채널은 단계 전환을 전제로 설계했습니다. 즉시 가동되는 이메일을 1순위로 두고 발신번호 등록이 끝나면 문자로, 이후 사전 승인을 거쳐 카카오 알림톡으로 넘어가는 순서입니다. 문자 발송은 솔라피로 보내는데, 처음 검토했던 다른 서비스가 고정 IP 화이트리스트를 요구해 앱스스크립트 환경(발신 IP가 매번 바뀜)에서 쓸 수 없었던 반면 솔라피는 HMAC 서명 인증만으로 발송이 가능했기 때문입니다. 수신번호 같은 개인정보는 코드에 넣지 않고 본사 비공개 설정 시트에만 두었습니다.

전체 구조는 다음과 같습니다.

글로 요약하면 이렇습니다. 거래처별 드라이브와 시트가 원천이고 여기서 일어나는 업로드·입력·일정 변화를 앱스스크립트가 폴링과 트리거로 감지해 문자와 이메일 알림으로, 그리고 월별 보고서 PDF로 바꿉니다. 집계는 시트 수식이 맡고 자동집계 칸은 보호 범위로 지키며 새 거래처는 이 전체를 템플릿째 복제해 권한만 부여하면 붙습니다.

결과

거래처를 받는 절차가 반복 가능한 형태로 정리됐습니다. 폴더 트리와 시트 템플릿을 복제하고 권한을 부여하면 새 거래처가 곧바로 운영에 들어갑니다. 자료를 어디에 두고 누구에게 어디까지 보여줄지는 폴더 구조가 정해주므로, 거래처가 늘어도 권한을 매번 손으로 짜맞출 필요가 없습니다.

반복 작업도 사람 손을 떠났습니다. 광고비 집계는 시트 수식이 즉시 계산하고 자료 업로드와 일정 변화는 앱스스크립트가 감지해 관련자에게 알리며 월별 보고서는 시간 트리거로 매달 생성됩니다. 운영자는 이미 익숙한 구글 워크스페이스 안에서 이 흐름을 확인하면 됩니다.

무엇보다 이 구조는 운영자가 직접 이해하고 굴릴 수 있게 설계됐습니다. 알림 채널은 이메일에서 문자로, 다시 알림톡으로 준비되는 대로 단계 전환하도록 열어 두었고 개인정보와 자격증명은 코드가 아니라 비공개 설정에만 두어 운영자가 값만 바꾸면 되도록 했습니다.

이 프로젝트에서 내린 기술적 결정들은 아래 글에서 더 자세히 풀었습니다.

• 거래처별 공유 드라이브 권한 설계: 폴더 구조로 공유 경계를 정하는 법
• 구글 시트 자동집계 설계: SUMIFS·QUERY와 자동·수기 영역 보호
• 앱스스크립트에서 문자 발송: 고정 IP 문제와 HMAC 인증 발송
• 드라이브 업로드 폴링 알림: 새 파일 감지와 파일명 검증
• 구글 캘린더·시트 일정 동기화: onEdit 알림과 통합 뷰
• 앱스스크립트로 보고서 PDF 무인 생성: 시트 집계를 문서로 그려 PDF로

자주 묻는 질문

왜 별도 시스템 대신 구글 워크스페이스와 앱스스크립트로 만들었나요?

운영 주체가 개발자가 아니라 사업 운영자였기 때문입니다. 이미 쓰고 있는 드라이브·시트·캘린더 위에서 돌아가면 새 도구를 배우지 않아도 되고 자동화 로직도 워크스페이스 안에 있어 시간 트리거로 무인 실행됩니다. 새 서버를 두거나 별도 관리 화면을 익히는 부담 없이, 운영자가 아는 도구 안에서 확장할 수 있는 점이 이 방식의 핵심 이유였습니다.

거래처가 늘어나면 관리가 복잡해지지 않나요?

새 거래처 추가가 정해진 절차로 끝나도록 설계한 것이 이 프로젝트의 목표였습니다. 폴더 트리와 시트 템플릿을 복제하고 권한을 부여한 뒤 알림 배선 설정만 채우면 운영에 들어갑니다. 권한의 경계는 폴더 구조가 정해주기 때문에, 거래처가 늘어도 공유 범위를 매번 수기로 조정하다 실수하는 일이 줄어듭니다.

거래처가 본사 내부 자료를 보게 될 위험은 없나요?

공유 경계를 사람의 주의가 아니라 드라이브 구조로 고정했습니다. 본사 내부 전용 드라이브를 따로 두고 거래처 드라이브 안에서도 외부 공유는 거래처 공유 영역 폴더에만 엽니다. 수신번호 같은 개인정보와 발송 자격증명은 코드나 공유 시트가 아니라 본사 비공개 설정에만 보관해 자료와 권한이 처음부터 분리되어 있습니다.