기업 선물 자동화를 단순히 “양식을 제출하면 선물이 발송되는 기능”으로 만들면 자격 판단, 예산, 개인정보, 배송 책임이 한 스프레드시트에 몰리기 쉽습니다. 안정적인 설계는 Google Workspace를 신청과 협업의 접점으로 제한하고, 각 판단의 책임자와 발송 사건의 고유성, 예외의 해결 경로를 처음부터 분명하게 둡니다.
Google Workspace가 맡을 범위를 먼저 정하기
스크립트보다 업무 경계를 먼저 설계합니다. 신청은 Google Forms API로 받을 수 있고, 검토 대기 정보는 Google Sheets API를 통해 표시할 수 있으며, 제한된 조정 처리는 Google Apps Script에 맡길 수 있습니다. 그러나 이 구성 요소들이 지출의 적법성, 수령인의 세무 처리, 직원의 자격, 배송 가능 국가를 스스로 결정해서는 안 됩니다. 책임자와 통제된 업무 시스템이 내린 결정을 전달하는 역할만 해야 합니다.
Forms는 구조화된 신청, Sheets는 확인 가능한 작업 대기열, Apps Script는 검증·알림·발송 조정, 선물 플랫폼은 수령 경험과 이행에 사용합니다. 자격 정책, 예산 권한, 신원 관리, 법률 해석, 급여 처리는 각각의 공식 시스템에 남겨 둡니다. 셀이 초록색이라고 승인 기록이 되는 것은 아니며, 탭 복사는 복구 가능한 백업이 아니고, 외부 호출의 성공 응답도 배송 완료를 뜻하지 않습니다.
구현 전에 한 쪽짜리 운영 헌장을 작성합니다. 대상 행사, 신청자, 승인자, 예산 출처, 수령인 유형, 필요한 증거, 금지 용도, 보존 기간을 적습니다. 결정 기록에는 승인자 신원, 시각, 정책 버전, 예산 코드, 수령인 참조값, 신청 내용의 해시값을 포함합니다. 이렇게 해야 자동화가 아무도 위임하지 않은 권한까지 조용히 떠맡는 것을 막을 수 있습니다.
각 사실에는 하나의 공식 출처를 지정합니다. 재직 상태는 인사 시스템, 고객 자격은 고객 관리 시스템, 가용 예산은 재무 시스템, 이행 상태는 실행 계층이 소유합니다. 스프레드시트는 참조값과 검토 가능한 시점 정보만 보관하며 새로운 원장을 만들지 않습니다. “누가 이 값을 바로잡을 수 있는가”에 답할 수 없다면 자동 발송을 시작할 준비가 되지 않은 것입니다.
경계 문서에는 장애 때 누가 무엇을 멈출 수 있는지도 적습니다. 운영은 신규 신청을 일시 중지할 수 있고, 보안 책임자는 위험한 자격 증명을 폐기할 수 있으며, 예산 책임자는 아직 발송되지 않은 금액을 동결할 수 있습니다. 그러나 이미 발생한 승인 사건을 직접 지워서는 안 됩니다. 중지, 재개, 보정 처리에는 시각, 실행자, 사유, 영향 범위를 남겨 복구 과정에서 기억에 의존하지 않게 합니다.
서비스 수준도 단계별로 정의합니다. 신청 접수, 보강, 승인, 발송, 대사는 서로 다른 목표 시간을 가질 수 있습니다. 전체 흐름의 평균 시간만 보면 소수의 오래된 예외가 가려집니다. 각 단계의 가장 오래된 항목과 백분위 지연을 보며, 정책 검토가 필요한 지연과 기술 장애로 생긴 지연을 구분합니다.
각 단계와 데이터에 한 명의 책임자 두기
신뢰할 수 있는 흐름은 신청, 보강, 승인, 발송, 대사의 다섯 단계로 나눌 수 있습니다. 각 단계에 설명 책임을 지는 한 사람, 명확한 입력과 출력, 기한이 지났을 때의 상향 경로를 둡니다. 인사, 정보기술, 행사, 구매, 재무가 막연히 공동 책임을 지면 예외가 개인 메시지에 흩어지고, 나중에는 왜 선물이 발송되었는지 설명할 사람이 없어집니다.
표: 통제된 기업 선물 업무의 책임 경계와 증거.
| 단계 | 주요 책임자 | 시스템 동작 | 필요한 증거 |
|---|---|---|---|
| 신청 | 프로그램 운영 | 필수값과 동의 경로 검증 | 신청 번호, 신청자, 목적, 정책 버전 |
| 보강 | 신원 또는 데이터 책임자 | 안정적인 수령인 참조값과 시장 확인 | 조회 결과, 출처, 시각, 신뢰 수준 |
| 승인 | 예산·정책 승인자 | 승인, 거절, 수정 반려 | 승인자, 결정, 사유, 예산 코드 |
| 발송 | 자동화 서비스 책임자 | 실행 계층에 중복되지 않는 요청 전송 | 사건 키, 신청 해시, 응답 번호 |
| 대사 | 프로그램 운영과 재무 | 접수, 선택, 출고, 배송, 실패, 환불 대조 | 상태 이력, 금액, 예외 책임자, 종료 증거 |
표시용 값과 통제용 값을 구분합니다. 이름은 사람이 읽기 좋지만 중복 방지에는 잘 바뀌지 않는 직원 번호나 고객 번호가 필요합니다. 캠페인 이름은 운영에 편리하지만 재시도를 안전하게 만드는 것은 기계용 사건 키입니다. 국가는 경로 결정에 필요해도 주소는 여러 사람이 편집하는 사내 표가 아니라 수령인이 통제된 수령 화면에서 입력하게 하는 편이 좋습니다.
표에 들어가는 정보를 최소화합니다. 검토자는 행사, 업무 목적, 지역, 예산 구간, 신청자, 승인자, 상태가 필요할 수 있습니다. 집 주소, 개인 전화번호, 상품 선택, 상세 배송 이력은 보통 필요하지 않습니다. 값의 종류별로 보존 기간과 삭제 책임자를 정하고, 판단·발송·대사에 쓰이지 않는 값은 없앱니다.
작업 시트를 자유로운 캔버스가 아니라 버전이 있는 대기열로 다룹니다. 열 이름을 고정하고, 통제 열을 보호하며, 허용값을 문서화하고, 코드에서도 다시 검증합니다. 편집자는 잘못된 값을 붙여 넣거나 열을 옮기고, 예전 버전을 복원하거나 수식을 덮을 수 있습니다. 따라서 발송기는 안정적인 머리글 이름으로 읽고 구조 버전을 확인한 뒤에만 동작해야 합니다.
별도의 데이터 사전을 두어 각 열의 목적, 형식, 허용값, 개인정보 여부, 공식 출처, 보존 기간, 가림 규칙을 설명합니다. 새 열을 추가하려면 사용 사례와 삭제 조건을 먼저 적습니다. “잠깐 편리하게” 만든 열이 몇 년 동안 민감한 내용을 보관하는 일을 줄이고, 자동화 변경 전에 호환성 영향을 검토할 수 있습니다.
편집 권한도 역할에 따라 나눕니다. 신청자는 자신의 초안만 수정하고, 검토자는 판단에 필요한 값만 보며, 통제 열은 서비스만 기록하게 합니다. 관리자는 구조를 바꿀 수 있지만 실제 신청을 대신 승인하지 않습니다. 공유 링크와 외부 협업자를 정기적으로 점검하고, 업무가 끝난 사람의 접근 권한을 즉시 제거합니다.
수정과 철회가 가능하고 기본값이 안전한 신청 만들기
신청 양식은 신청자가 정당하게 제공할 수 있는 정보만 요청합니다. 근속 기념이라면 직원 번호, 행사, 기준일, 프로그램 코드, 업무 사유를 받고, 배송지와 선호는 나중에 수령인이 초대 화면에서 직접 입력하게 합니다. 고객 행사라면 고객 관리 참조값, 조직, 관계 책임자, 행사, 국가, 승인 예산을 받고, 편리하다는 이유로 개인 주소를 붙여 넣게 하지 않습니다.
자유 서술은 검증하기 어렵고 과도하게 공유되기 쉬우며 일부만 지우기도 어렵습니다. 신청 단계에서 주소가 정말 필요하다면 이름이 있는 필드로 나누고, 이용 목적과 보존 기간을 설명하며, 응답 자료의 열람자를 제한합니다. 마케팅 동의와 이행을 위한 정보 사용은 서로 다른 목적이므로 하나의 동의 확인란으로 뭉치지 않습니다.
중요한 변경은 승인된 행을 직접 덮지 말고 새 버전으로 남깁니다. 이전 버전의 해시값, 변경자, 시각, 사유를 보관합니다. 승인 뒤 국가, 예산, 수령인, 행사가 바뀌면 다시 검토 상태로 돌아가고, 과거 승인 표시를 그대로 두지 않습니다. 철회도 독립된 사건으로 기록하여 예산 예약과 발송 대기열이 함께 해제되게 합니다.
안전한 기본값은 미완성 신청을 초안에 두기, 필수값이 없으면 승인하지 않기, 알 수 없는 시장으로 발송하지 않기, 예산을 넘으면 임의로 축소하지 않기, 같은 사건을 조용히 덮지 않기, 시간 초과를 즉시 실패로 보아 재전송하지 않기입니다. 거절할 때는 가능한 수정 방법을 알려 사용자가 행 복제로 통제를 우회하지 않게 합니다.
신청자에게 보이는 오류 문구는 정확하되 내부 자료를 노출하지 않아야 합니다. “이 시장은 추가 검토가 필요합니다”라고 안내하면 충분하며 민감한 위험 규칙을 모두 보여줄 필요는 없습니다. “직원 참조값을 확인할 수 없습니다”라는 안내가 전체 디렉터리 조회 결과보다 안전합니다. 내부 예외 기록은 기술 코드와 추적 번호를 담고, 신청 번호로 사용자 안내와 연결합니다.
수정 기한도 정책으로 정합니다. 예를 들어 발송 예정 5영업일 전까지는 신청자가 일부 값을 고칠 수 있지만, 그 이후의 국가나 예산 변경은 취소 후 새 버전을 요구할 수 있습니다. 기한은 편의를 위한 임의 숫자가 아니라 공급 가능성, 승인 소요 시간, 취소 가능 시점에 맞추고 시장별 차이를 문서화합니다.
Forms API의 알림 대상은 Cloud Pub/Sub이며 감시는 최장 일주일이어서 갱신해야 합니다. 알림에는 식별 정보만 들어 있으므로 실제 응답은 별도로 가져와야 합니다. 이 방식을 쓰면 감시 갱신, 중복 알림, 지연, 누락을 감시하고 정기 조회를 복구 수단으로 남깁니다. 알림 수신과 응답 처리 완료를 같은 상태로 보아서는 안 됩니다.
신원 확인과 선물 자격을 분리하기
Google Workspace Directory API는 회사 계정, 별칭, 상태를 확인하는 데 도움이 되지만, 어떤 사람이 검색되었다고 선물을 보낼 권한이 생기는 것은 아닙니다. 디렉터리는 “누구인가”와 일부 계정 상태를 답하고, 정책·인사·영업의 공식 시스템이 “이번에 자격이 있는가”를 답합니다. 두 결과를 따로 기록합니다.
이름이나 전자우편 주소보다 안정적인 식별 번호를 우선합니다. 퇴사, 이동, 개명, 도메인 통합, 별칭 때문에 표시값은 바뀔 수 있습니다. 조회 결과에는 출처, 조회 시각, 사용 범위, 결과 요약을 넣고 유효 기간을 정합니다. 발송 직전에 재직 상태를 다시 확인하더라도 전체 디렉터리 자료를 선물 시트로 복사할 필요는 없습니다.
권한은 최소 범위를 적용합니다. 읽기만 필요하다면 변경 가능한 넓은 범위 대신 읽기 전용 범위를 선택합니다. 기술 계정의 소유자, 용도, 승인자, 만료일, 폐기 절차를 등록부에 기록합니다. 전사 디렉터리를 읽는 자격 증명을 퇴사와 함께 사라질 개인 소유 설정에 의존하게 하지 않습니다.
분기마다 실제 사용하는 인증 범위와 등록부를 대조합니다. 더 이상 어떤 값을 읽지 않는다면 관련 범위를 제거하고 다시 승인합니다. 범위를 추가할 때는 목적, 자료 유형, 시험 결과, 승인자를 먼저 기록합니다. “지금 잘 작동한다”는 사실은 권한이 정당하다는 증거가 아니며, 검토하지 않은 오래된 권한은 시간이 갈수록 철회하기 어려워집니다.
외부 수령인을 다루는 경로는 내부 직원 조회와 분리합니다. 외부 주소를 내부 디렉터리에 임시 계정으로 만들거나 직원 번호 형식에 억지로 맞추지 않습니다. 외부 대상자에게는 고객 또는 행사 시스템의 안정적인 참조값, 관계 책임자, 자격 근거, 만료일을 사용하며, 행사가 끝나면 접근과 초대 상태를 정리합니다.
검색 실패는 최소 세 가지로 나눕니다. 번호 오류, 출처의 일시 장애, 사내 디렉터리 밖의 대상자입니다. 번호 오류는 신청자에게 돌려보내고, 일시 장애는 재시도 가능한 기술 예외로 두며, 외부 대상자는 고객 또는 외부 수령인용 통제 경로로 보냅니다. 모두를 “찾을 수 없음”으로 표시하면 운영자가 수동 입력으로 구멍을 메우고 감사 가능성을 훼손합니다.
승인을 확인란이 아닌 상태 기계로 운영하기
상태와 허용되는 전이를 분명히 정의합니다. 초안, 정보 보완, 정책 검토 대기, 예산 승인 대기, 발송 대기, 발송 중, 접수 완료, 배송 완료, 예외, 취소, 종료를 둘 수 있습니다. 상태가 바뀔 때마다 실행자, 시각, 사유, 정책 버전, 이전 상태와 다음 상태를 기록합니다.
표: 승인부터 발송까지 필요한 최소 통제.
| 현재 상태 | 허용 동작 | 실행자 | 보호 조건 |
|---|---|---|---|
| 초안 | 제출 또는 삭제 | 신청자 | 필수값과 구조 버전이 유효함 |
| 정책 검토 대기 | 승인, 거절, 반려 | 정책 책임자 | 자격 출처와 업무 사유를 확인함 |
| 예산 승인 대기 | 승인 또는 거절 | 예산 책임자 | 예산 코드가 유효하고 금액을 예약함 |
| 발송 대기 | 발송 또는 취소 | 발송 서비스 | 해시 불변, 사건 키 고유, 대상 지역 지원 |
| 예외 | 재시도, 취소, 수동 종료 | 지정된 예외 책임자 | 원인, 증거, 다음 행동을 기록함 |
위험이 큰 신청은 같은 사람이 신청, 승인, 수정을 모두 하지 않도록 직무를 분리합니다. 금액, 수령인 유형, 시장에 따라 단계 승인을 사용합니다. 위험이 낮은 직원 프로그램을 일괄 승인하더라도 고정된 대상자 버전, 총액, 정책 버전, 책임자를 보관합니다.
승인은 같은 셀의 “예/아니요”를 덮는 것이 아니라 변경 불가능한 사건으로 남겨야 합니다. 발송기는 현재 신청 해시와 승인 당시 해시를 비교하고 다르면 멈춥니다. 그래야 승인 후 수령인, 금액, 국가가 바뀌었는데 승인 표시만 남는 사고를 막을 수 있습니다.
기한 초과도 종류별로 처리합니다. 미승인은 대기 또는 취소이며 자동 동의가 아닙니다. 외부 서비스의 시간 초과는 결과 불명으로 두고 조회 후 재시도를 판단합니다. 사람의 예외 처리가 늦으면 대체 책임자에게 올립니다. 서로 다른 기한 초과를 하나의 “오류” 열에 모으지 않습니다.
일괄 승인은 총액 통제가 필요합니다. 승인 시 건수, 금액, 통화, 대상자 버전, 계산 규칙을 저장하고 발송 직전에 다시 계산합니다. 차이가 생기면 전체 묶음을 멈추거나 영향받은 항목만 격리할지 정책에 따라 결정합니다. “총 100건”만 저장해서는 내용이 바뀌지 않았음을 증명할 수 없습니다. 한 건을 지우고 다른 한 건을 추가해도 수는 같기 때문입니다.
대리 승인에는 기간과 범위를 둡니다. 휴가 중인 승인자를 대신할 사람은 특정 프로그램과 날짜에만 권한을 갖고, 대리 사유가 사건 기록에 남아야 합니다. 영구적인 공유 계정이나 누구나 쓰는 승인 버튼은 책임 소재를 없애므로 사용하지 않습니다.
사건 키, 해시, 잠금으로 중복 선물 막기
가장 위험한 실패는 명확한 오류보다 “요청은 성공했지만 응답을 받지 못한” 상황입니다. 사용자가 버튼을 다시 누르거나 일정 작업이 재실행되면 같은 선물이 두 번 갈 수 있습니다. 발송 가능한 사건마다 결정적이고 고유한 멱등 키를 만들고, 재전송 전에 기존 결과를 조회합니다.
사건 키는 프로그램, 행사, 안정적인 수령인 번호, 버전으로 만들 수 있습니다. 정렬이나 행 삽입에 따라 바뀌는 행 번호는 쓰지 않습니다. 신청 해시에는 시장, 예산 구간, 정책 버전, 수령인 참조값처럼 판단에 영향을 주는 표준화 필드를 포함합니다. 승인 후 해시가 달라지면 재승인을 요구합니다.
양식 트리거, 일정 작업, 수동 버튼이 같은 행을 동시에 처리할 수 있습니다. LockService는 짧은 임계 구간의 충돌을 막지만 영구 대기열이나 외부 중복 방지 장치가 아닙니다. 잠금을 얻은 뒤 상태를 다시 읽고, 여전히 발송 가능할 때만 “발송 중”과 시도 번호를 쓰고, 즉시 잠금을 풀어 외부 호출을 진행합니다.
구조와 승인 해시 검증
사건 키 생성 또는 조회
짧은 스크립트 잠금 획득
아직 발송되지 않았는지 재확인
발송 중 상태와 시도 번호 기록
잠금 해제
사건 키를 포함해 실행 계층에 전송
같은 키로 결과를 조회하여 대사 기록 갱신
재시도에는 횟수 제한과 대기 시간을 둡니다. 재시도 가능한 오류, 영구 검증 오류, 결과 불명을 구분합니다. 시간 초과는 결과 불명이므로 먼저 조회하고, 입력 오류는 사람이 고치며, 권한 거절은 멈추고 서비스 책임자에게 알립니다. 더 넓은 권한으로 바꾸어 우회해서는 안 됩니다.
외부 실행 계층이 고유 사건 키를 지원하지 않는다면 내부 등록부만으로 위험을 완전히 없앨 수 없습니다. 이때는 한 번에 처리하는 수를 줄이고, 같은 사건의 발송을 순차 처리하며, 응답이 불명확하면 자동 재시도를 중단해야 합니다. 외부 중복 방지 지원을 운영 전제조건으로 올리고, “평소에는 중복이 드물다”는 경험을 통제로 취급하지 않습니다.
사건 키의 생성 규칙도 버전으로 관리합니다. 구분자, 대소문자, 공백 정규화, 날짜 형식이 바뀌면 같은 업무 사건이 다른 키로 만들어질 수 있습니다. 규칙을 변경할 때는 기존 키를 다시 만들지 말고, 새 버전의 키와 이전 키의 연결을 보존하여 조회와 대사가 이어지게 합니다.
최소 권한으로 발송하고 멈춤을 관찰하기
Google OAuth 2.0의 클라이언트 정보와 토큰은 안전하게 보관하고 코드, 시트, 버전 저장소에 쓰지 않습니다. 필요한 최소 범위를 점진적으로 승인하며, 소유자와 폐기 절차를 기록하고, 더 이상 쓰지 않으면 철회하고 삭제합니다. 개인이 만든 설치형 트리거는 생성자의 권한으로 실행되므로 서비스 소유와 인수인계가 중요합니다.
Apps Script의 설치형 트리거는 일반 프로그램이나 외부 인터페이스 호출로 바뀐 값에는 다시 실행되지 않으며, 생성자 계정으로 동작합니다. 생성자 비활성화, 권한 변경, 할당량 초과로 흐름이 조용히 멈출 수 있습니다. 마지막 성공 시각, 대기열의 가장 오래된 항목, 트리거 소유자, 인증 상태를 감시하고 오류 전자우편에만 의존하지 않습니다.
공식 할당량에 따르면 한 번의 스크립트 실행은 6분, 동시 실행은 사용자당 30개와 스크립트당 1,000개, 트리거는 사용자·스크립트당 20개입니다. 속성 값 하나와 전체 속성 저장소에도 한도가 있습니다. 수치는 바뀔 수 있으므로 용량 설계 때 최신 공식 자료를 읽고 영구 보장처럼 코드에 고정하지 않습니다.
발송 요청은 작고 일정하게 유지합니다. 사건 키, 프로그램 코드, 수령인 참조값 또는 초대 목적지, 지역, 승인 예산, 언어, 정책 버전, 회신 참조값만 보냅니다. 행 전체, 사내 메모, 승인자의 의견, 관련 없는 디렉터리 자료를 보내지 않고, 로그에는 비밀이나 전체 개인정보 대신 요청 해시와 응답 번호를 기록합니다.
관찰 지표에는 대기 건수, 가장 오래된 대기 시간, 승인부터 발송까지의 시간, 고유 사건 수, 중복 차단 수, 결과 불명 수, 영구 실패 수, 취소 수, 배송률, 미종결 예외 수를 포함합니다. 각 경보에는 담당자와 대응 절차를 연결합니다. 다음 행동이 없는 경보는 소음일 뿐입니다.
로그는 운영자가 보는 내용과 보안 진단 내용을 분리합니다. 운영 화면에는 사건 키, 상태, 경과 시간, 책임자를 보여 주고, 보안 로그에는 권한 변경, 자격 증명 교체, 비정상 조회, 관리자 작업을 기록하여 열람을 제한합니다. 두 기록은 같은 추적 번호를 사용하지만 일반 화면에 토큰, 주소, 전체 요청 본문을 표시하지 않습니다.
배포에도 되돌리기 계획이 필요합니다. 새 스크립트 버전은 합성 자료와 복사된 구조에서 먼저 검증하고, 소수 프로그램에만 적용하며, 오류율과 처리 지연을 비교합니다. 문제가 생기면 이전 코드로 돌아갈 뿐 아니라 새 버전이 이미 만든 상태와 외부 요청을 어떻게 정리할지도 정해 둡니다. 코드 롤백만으로 외부 발송이 취소되지는 않습니다.
첫날부터 대사와 감사 증거 만들기
대사는 월말에 내보내는 보고서가 아니라 매 상태 변경의 일부입니다. 내부 신청, 실행 계층 응답, 재무 기록을 사건 키와 외부 응답 번호로 연결합니다. 이름과 금액으로 짐작해 맞추면 동명이인, 같은 금액, 반복 행사가 있을 때 실패합니다.
매일 승인되었으나 미발송인 건, 발송 중 서비스 목표를 넘긴 건, 외부는 접수했으나 내부가 미갱신인 건, 취소되었으나 비용이 남은 건, 환불되었으나 예산이 미해제인 건, 배송되었으나 필요한 증거가 없는 건을 추출합니다. 예외에는 경과 시간, 금액, 담당자, 다음 행동, 약속 날짜를 붙이고 닫힐 때까지 추적합니다.
감사 이력에는 결정 사건과 필요한 기술 증거를 남기고 불필요한 개인정보는 남기지 않습니다. 사건 키, 신청 버전, 요청 해시, 정책 버전, 승인자, 예산 코드, 발송 시각, 외부 응답 번호, 상태 이력, 예외 처리, 삭제 증명이 핵심입니다. 민감한 내용은 적절한 시스템에 두고 감사 기록에는 역산이 어려운 참조값만 보관합니다.
백업은 복원 시험까지 해야 합니다. 시트를 복사해도 트리거, 권한, 비밀, 보호 범위, 외부 상태가 함께 복원되지 않습니다. 분기마다 시트 삭제, 생성자 퇴사, 토큰 철회, 외부 부분 성공을 가정하고 공식 출처에서 대기열을 재구축해도 중복 발송하지 않는지 확인합니다.
대사 결과는 프로그램별로 닫는 기준을 가져야 합니다. 모든 승인 사건이 배송, 취소, 환불, 영구 실패 중 하나로 끝났고, 비용 차이가 허용 한도 안이며, 열린 개인정보 삭제 작업이 없어야 종료할 수 있습니다. 단지 대기열이 비었다는 이유로 프로그램을 닫으면 외부에 남은 접수 건과 늦은 환불을 놓칠 수 있습니다.
감사 요청에 대비해 증거 묶음의 재생 방법을 시험합니다. 무작위 사건을 골라 신청 버전, 승인, 사건 키, 외부 응답, 비용, 최종 상태를 정해진 시간 안에 연결할 수 있어야 합니다. 연결할 수 없는 값이 나오면 사람이 기억을 보완하기 전에 구조와 기록 규칙을 고칩니다.
먼저 지울 정보와 남길 증거는 무엇인가
주소, 전화번호, 자유 서술, 선호는 이행과 필요한 이의 제기 기간이 끝나면 우선 삭제합니다. 사건 키, 정책 버전, 결정 시각, 금액, 승인자, 되돌리기 어려운 외부 참조값은 재무·감사 정책에 따라 보관할 수 있습니다. 실제 기간은 개인정보, 법무, 재무, 인사 책임자가 정하며 스크립트 작성자가 혼자 결정하지 않습니다.
사례 하나: 세 나라의 근속 기념
미국, 일본, 독일의 근속 기념을 가정합니다. 인사 시스템은 매달 초기 조건을 충족한 직원 번호, 기념일, 근무 국가, 프로그램 코드를 내보내고 주소는 내보내지 않습니다. 운영 담당자가 인원과 예산 구간을 확인하고, 지역 인사가 재직 상태와 현지 정책을 확인하며, 재무가 예산을 예약합니다.
각 직원의 사건 키는 프로그램, 기념 월, 안정적인 직원 번호, 버전으로 만듭니다. 모든 승인은 고정된 대상자 버전과 정책 버전을 가리킵니다. 발송 직전에 재직 상태를 다시 확인하고 퇴사, 휴직, 국가 변경이 있으면 지역 검토로 돌립니다. 주소와 상품 선호는 실행 계층이 수령인에게 받고, Workspace에는 초대 상태와 외부 참조값만 둡니다.
400번째 건을 처리할 때 실행 시간 한도에 가까워지는 장애를 넣어 봅니다. 올바른 설계는 한 번에 가져오는 수를 제한하고 각 사건의 확인 지점을 저장하며, 다음 실행에서 여전히 발송 대기인 사건만 이어서 처리하는 것입니다. 현재 행 번호를 확인 지점으로 쓰지 않고, 묶음이 끝나지 않았다는 이유로 앞선 399건을 다시 보내지 않습니다.
직원 12명이 독일에서 일본으로 이동하면 국가는 선택지, 비용, 정책 처리에 영향을 주므로 신청 해시가 달라지고 이전 승인은 무효가 됩니다. 새 버전을 만들고 이전 버전의 취소 사건을 남기며, 지역 인사와 예산 책임자는 영향을 받은 12건만 다시 봅니다. 전체 대상자를 재승인할 필요는 없습니다.
종료할 때 고유 승인 사건, 실행 계층 접수, 수령 선택, 배송, 취소, 실패, 환불 건수를 맞춥니다. 재무 합계는 사건 단위 금액에서 예약 예산으로 되돌아가야 합니다. 차이는 책임자가 지정된 예외로 해결하고 총계의 수동 조정으로 감추지 않습니다.
개인정보 삭제도 결산 항목에 넣습니다. 초대가 만료된 사람의 주소와 선호가 실행 계층 정책에 따라 제거되었는지 확인하고, Workspace에는 필요한 사건 참조와 상태만 남깁니다. 지역별 보존 요구가 다르면 가장 긴 기간을 모두에게 적용하기보다 목적과 법적 근거에 맞춘 보존표를 사용합니다.
운영 책임자는 시범 종료 뒤 사용자의 우회 행동도 살펴봅니다. 신청자가 별도 시트를 만들거나 예외를 전자우편으로 보내고 있다면 통제가 불편하거나 필요한 경로가 빠진 신호입니다. 우회를 처벌하기 전에 원인을 분석하고, 정당한 예외 경로를 제품 흐름 안에 추가합니다.
사례 둘: 고객 행사와 막바지 변경
120명이 참여하는 고객 간담회를 가정합니다. 고객 관리 시스템은 관계와 연락 자격, 행사 시스템은 참석, 재무는 예산, 선물 프로그램은 정책과 이행을 맡습니다. 양식은 연사 감사 선물, 교환, 국가 변경처럼 승인된 예외에만 씁니다.
후보 자료에는 고객 연락처 번호, 행사 번호, 국가, 관계 책임자, 프로그램 코드, 예산 구간을 넣습니다. 마케팅은 업무 목적과 이해 충돌 확인을 수행하고, 더 민감한 수령인은 회사 정책에 따라 구매 또는 준법 담당자가 검토합니다. 고객 관리 시스템의 주소를 시트로 가져오지 않습니다.
행사 7일 전에 주 대상자 버전을 고정합니다. 막바지 추가자는 새 버전으로 만들고 기존 행을 조용히 바꾸지 않습니다. 발송 전 취소는 예산 예약을 풀고, 실행 계층 접수 후 취소는 그 계층의 규칙을 따릅니다. 수령인이 국가를 바꾸면 상품, 비용, 배송 시간이 달라질 수 있으므로 시장 검토로 돌아갑니다.
요청 30건이 시간 초과되었지만 실행 계층은 실제로 20건을 접수한 부분 장애를 넣습니다. 30건을 모두 다시 보내지 말고 사건 키로 조회하여 20건을 접수 완료로 표시하고, 존재하지 않음을 확인한 10건만 재시도합니다. 최종 보고서에서는 접수 건수가 고유 승인 사건 수와 일치함을 보여야 합니다.
성공은 스크립트가 끝났다는 뜻이 아닙니다. 발송된 모든 선물에 유효한 승인이 있고, 의도하지 않은 중복이 없으며, 예외에 책임자가 있고, 재무 합계가 맞고, 개인정보가 적절한 시스템에 남아 있어야 합니다. 이 기준이 있어야 행사가 끝난 뒤에도 결정을 설명할 수 있습니다.
막바지 추가가 반복된다면 행사를 운영하는 방식 자체를 바꿉니다. 추가 마감 시각, 긴급 승인자, 허용 예산, 지원 시장을 미리 정하고, 마감 이후에는 자동 발송이 아니라 검토 대기 상태로 보냅니다. 긴급함은 통제를 없애는 이유가 아니라 더 좁은 권한과 더 분명한 기록이 필요한 이유입니다.
행사 보고서는 선물의 반응만 보여 주지 않고 통제 성과도 보여 줍니다. 중복 차단, 기한 초과, 취소, 재시도, 개인정보 예외, 예산 차이를 함께 검토하면 다음 행사의 대상자 확정 시점과 승인 용량을 현실적으로 조정할 수 있습니다.
되돌릴 수 있는 단계로 도입하고 운영 결론 남기기
단계적으로 구축합니다. 경계, 데이터 분류, 상태를 문서화한 뒤 합성 자료로 구조를 검증합니다. 다음으로 읽기 전용 신원 조회, 승인 사건, 모의 발송기를 연결합니다. 위협 검토가 끝난 뒤에만 운영 자격 증명을 넣습니다. 작은 시범 운영에서는 모든 신청을 수동으로도 대사하고 자동 보고서와 차이가 사라진 뒤 확대합니다.
-
서비스, 데이터, 정책, 예산, 보안, 운영 책임자를 지정한다.
-
신원, 자격, 예산, 이행의 공식 출처를 확인한다.
-
신청과 검토 구조를 버전으로 고정하고 통제 열을 보호한다.
-
인증 범위, 자격 증명 소유자, 트리거 소유자, 철회 절차를 등록한다.
-
사건 키, 신청 해시, 짧은 잠금, 제한 재시도, 재전송 전 조회를 구현한다.
-
중복, 시간 초과, 할당량, 권한, 취소, 배송 실패를 시험한다.
-
보존, 삭제, 접근 검토, 백업, 복원 증거를 정의한다.
-
작은 시범에서 모든 접수 사건을 종료까지 대사한다.
핵심 경로를 Apps Script 밖으로 옮길 때는 언제인가
실행 시간, 동시 처리량, 보안 통제, 배포 규율, 지역 요구, 복구 목표가 스크립트가 안정적으로 감당할 범위를 넘을 때입니다. 익숙한 양식과 시트는 사용자 화면으로 남길 수 있지만, 지속 대기열, 비밀, 기록, 연동 로직은 소유자가 분명한 관리형 서비스로 옮깁니다.
오래가는 형태는 “양식에서 시트로 간 뒤 선물 발송”이 아니라 통제된 신청, 버전이 있는 승인, 중복되지 않는 발송, 증거에 기반한 대사입니다. Google Workspace는 익숙한 협업 화면을 제공한다는 점에서 유용하지만, 각 구성 요소의 권한을 좁히고 장애 때 추측으로 재전송하지 않는 설계가 있어야 안전합니다.
조직이 자격과 정책 결정을 마친 뒤 Giftpack은 최소화된 발송 자료를 받아 수령인의 선택과 글로벌 이행을 조정하는 실행 계층으로 활용할 수 있습니다. Giftpack은 Workspace 관리, 신원 통제, 동의, 세무, 급여, 법률, 고용주의 결정을 대신하지 않으며, 그 책임은 조직과 전문 자문가에게 남습니다.