제휴 및 광고 고지: 오토픽고는 자동화 도구를 비교하는 정보성 콘텐츠를 제공합니다. 일부 링크나 추천에는 제휴 또는 광고 성격이 포함될 수 있으며, 최종 선택 전 공식 요금제, 약관, 개인정보 처리 조건을 직접 확인해야 합니다.
제휴 고지: 이 글에는 제휴 링크가 포함될 수 있습니다. 링크를 통해 가입하거나 결제하면 오토픽고가 수수료를 받을 수 있지만, 추천 기준은 한국어 업무 적합성, 무료 검증 가능성, 설정 난이도, 개인정보 리스크, 비용 구조를 함께 봅니다.
문의가 Slack에 올라왔는데 모두 다른 사람이 맡았다고 생각하면 응대는 늦어집니다. 신규 리드 알림은 접수 사실뿐 아니라 누가 확인하고 어디에 처리 상태를 남길지까지 정해야 쓸모가 있습니다. 이 글은 구글폼의 새 상담 신청을 팀에 전달하는 흐름을 다루며, 이메일 견적 내용을 읽거나 견적 금액을 계산하는 자동화와는 구분합니다.
2026년 9월 27일 Google·Slack 공식 문서를 확인했습니다. 아래는 Apps Script 유지관리 담당자가 있는 팀을 위한 설정·구현 명세입니다. 바로 설치할 수 있는 완성 스크립트나 실행 결과를 제공하는 글은 아니며, 폼 제출·Slack 발송 시험은 하지 않았습니다.
문의 유형과 기본 담당자를 먼저 정합니다
구글폼의 문의 유형을 선택식으로 만들면 자유 입력을 다시 해석하는 부담을 줄일 수 있습니다. 아래는 소규모 영업팀의 가상 배정표입니다.
| 문의 유형 | 1차 담당 | 예외 처리 |
|---|---|---|
| 도입 상담 | 상담 담당자 | 부재 시 당일 대기 담당자가 인수 |
| 제휴 제안 | 제휴 담당자 | 담당자 미지정 시 운영 담당자가 확인 |
| 기타 | 운영 담당자 | 내용을 읽고 재배정 |
원문에는 연락처가 필요하더라도 알림에는 접수 식별자, 유형, 희망 일정, 담당자, 권한이 제한된 원문 위치만 남기는 편이 좋습니다. 상세 예산이나 전화번호 전체를 채널에 복제해야 하는지 먼저 판단하세요.
알림 설계 예시는 ‘신규 문의 L-024 / 도입 상담 / 희망 일정: 다음 주 / 1차 담당: 상담팀 / 상태: 확인 대기 / 원문: 접근 권한이 있는 기록’입니다. 실제 접수번호나 시험 결과가 아닌 표시 형식 예시입니다.
Google Forms 제출과 Sheets 수정 이벤트를 혼동하지 않습니다
이 방식은 Google Forms 제출 → 연결된 Sheets 응답 → 설치형 제출 트리거 → Slack 웹훅 순서입니다. 담당 개발자는 응답 시트에 연결된 Apps Script에서 처리 함수를 준비하고, 트리거 화면에서 해당 함수의 스프레드시트 양식 제출 이벤트를 선택합니다.
Google은 Forms 자체의 제출 트리거와 응답을 받는 Sheets 제출 트리거를 별도로 제공합니다. Sheets 방식에서는 이벤트의 namedValues에 질문 이름과 응답값이, range에 응답 범위가 제공됩니다. Forms용 이벤트 구조를 Sheets 코드에 그대로 쓰면 안 됩니다. 설치형 트리거, 제출 이벤트 구조
질문 제목을 바꾸면 제목을 기준으로 읽는 매핑도 점검해야 합니다. 개발자에게 현재 질문 제목·필수 여부·배정값을 함께 전달하고, 이름이 겹치는 질문을 만들지 않도록 합니다. 이미 쌓인 행을 수정하는 작업과 새 응답 접수도 별도로 취급합니다.
Slack에는 제한된 알림 채널을 연결합니다
Slack 앱에서 Incoming Webhooks를 켜고 Add New Webhook to Workspace로 알림 대상 채널을 선택합니다. 비공개 채널에 추가하려는 사람은 먼저 그 채널의 구성원이어야 합니다. 생성된 웹훅 URL에 JSON 메시지를 HTTP POST로 보내는 구조입니다. Slack Incoming Webhooks 설정
웹훅 URL은 비밀값입니다. 폼 설명, 응답 시트의 일반 셀, 공개 코드 저장소에 붙여 넣지 말고 실행 환경에서 접근을 통제해 보관합니다. 또한 이 방식은 설치할 때 정한 채널을 사용하며, 메시지마다 임의 채널로 덮어쓰는 방식이 아닙니다. 유형별로 여러 채널을 요구한다면 채널별 연결 또는 다른 API 설계를 별도로 검토해야 합니다. 웹훅 보안과 채널 제한
워크스페이스가 앱 설치를 제한한다면 관리자의 승인 경로를 먼저 따릅니다. 연결이 허용되지 않은 상태에서 개인 워크스페이스로 고객 데이터를 우회 전송하지 않습니다. Slack 앱 승인 관리
개발 담당자에게 넘길 처리 순서
아래는 제품에 기본 제공되는 배정 기능이 아니라 이 업무에 필요한 구현 요구사항입니다.
- 새 응답의 필수 항목과 문의 유형을 읽습니다. 매핑되지 않은 유형은 기본 담당자에게 보냅니다.
- 접수별 식별자와 알림 상태를 별도 관리 기록에 남깁니다. 같은 요청의 재처리인지 확인할 수 있어야 합니다.
- 배정표에서 담당자를 결정하고, 원문을 복제하지 않은 요약 메시지를 만듭니다.
- 웹훅 응답을 확인해 발송 성공·실패·확인 필요를 기록합니다. HTTP 200과
ok는 메시지 게시 성공의 근거이며 담당자의 인수 완료를 뜻하지 않습니다. - 담당자는 원문을 읽은 후 관리 기록에 인수 시각을 남깁니다. 정해 둔 시간까지 인수가 없으면 운영 담당자가 확인합니다.
웹훅은 잘못된 데이터, 비활성 연결, 보관된 채널 등에 대해 오류를 반환할 수 있습니다. invalid_payload처럼 수정이 필요한 오류를 무한 재시도하지 않습니다. Slack 웹훅 오류 처리
전송 직후 연결이 끊기면 Slack에는 게시됐지만 관리 기록은 실패일 수 있습니다. 이 경우 재전송 전에 접수 식별자로 게시 여부를 사람이 확인하도록 운영 규칙을 둡니다. ‘항상 정확히 한 번’ 전송된다고 보장하지 않습니다.
시험은 실제 폼 화면에서 제출합니다
설치형 트리거는 만든 사람의 권한으로 실행됩니다. 담당자의 계정 변경·퇴사 때 누가 유지할지 기록하고, Sheets 읽기와 외부 전송에 필요한 권한을 승인 화면에서 검토합니다. Google은 스크립트 실행이나 API 요청이 일반적으로 트리거를 발생시키지 않는다고 안내하므로, 시험 데이터를 API로 넣고 제출 트리거 검증이 끝났다고 보면 안 됩니다. 트리거 실행 계정과 제한
운영 전 시험안은 다음과 같습니다. 실제 결과는 수행 후 기록해야 합니다.
- 폼에서 정상 문의 제출: 응답 기록과 Slack 요약, 담당자가 서로 일치하는지 확인합니다.
- 기타 유형·선택 항목 공란: 기본 담당자에게 가고 빈 값 때문에 전송이 멈추지 않는지 확인합니다.
- 동일 접수 재처리: 새 리드처럼 다시 배정하지 않는지 확인합니다.
- 연결 실패: 원문은 남아 있고 실패 기록으로 수동 인수가 가능한지 확인합니다.
- 담당자 부재: 알림 게시 뒤 대체 담당자가 실제로 인수할 수 있는지 확인합니다.
Apps Script에는 사용량 제한이 있으므로 계정별 실행 조건도 확인해야 합니다. 운영 책임자가 배정표·예외 처리·노출 정보를 승인하고 이 시험을 마친 다음에만 실제 접수 흐름에 연결하세요. Apps Script 할당량
