구글 앱스 스크립트로 견적 발송 자동화, 하루에서 5분으로
회사 홈페이지 두 개를 Cloudflare로 옮기고 나서, 미뤄둔 업무 목록을 다시 펼쳤습니다. 가장 시급한 것은 견적서 발송 자동화였습니다.
우리는 구글 워크스페이스를 메일함으로만 쓰고 있었습니다
회사 메일은 지메일 기반의 구글 워크스페이스를 씁니다. 꽤 강력한 IT 인프라를 이미 갖고 있었던 셈입니다.
그런데 실제로 쓰는 것은 메일을 주고받는 일과 구글 드라이브로 파일을 공유하는 일, 딱 거기까지였습니다. 워크스페이스가 가진 진짜 강점은 하나도 쓰지 않고 있었습니다.
그리고 저는 대부분의 회사가 여기서 멈춰 있을 것이라고 생각합니다. 매달 계정 수만큼 요금을 내면서, 실제로는 메일함과 파일 서랍으로만 쓰는 상태입니다.
진짜 강점은 앱스 스크립트인데, 늘 뒤로 밀렸습니다
워크스페이스에는 기능이 아주 많습니다. 그중에서 가장 돋보이는 것은 구글 앱스 스크립트입니다. 워크스페이스 생태계와 그대로 연결되는 프로젝트를 만들어 업무 자동화에 쓸 수 있습니다. 시트, 문서, 지메일, 드라이브가 이미 하나로 묶여 있는 자리에서 시작하는 것입니다.
그런데 손을 대지 못했습니다. 이유는 두 가지였습니다. 참고할 만한 사례가 많지 않았고, 차분히 앉아서 이것을 개발할 시간이 없었습니다. 그래서 늘 우선순위에서 뒤로 밀렸습니다.
그래서 견적을 이렇게 처리하고 있었습니다
우리 회사의 견적 흐름은 이랬습니다.
- 고객이 구글 양식으로 견적을 요청합니다
- 요청 내용이 구글 시트에 쌓입니다
- 알림 메일이 옵니다
- 사람이 메일을 열어 요청 내용을 파악합니다
- 사람이 수동으로 견적을 작성합니다
- 사람이 메일로 발송합니다
자동으로 돌아가는 구간은 1번부터 3번까지입니다. 그런데 실제로 시간이 드는 4번부터 6번은 전부 사람 손입니다. 요청이 들어왔다는 사실만 자동으로 알려주고, 일은 그대로 남아 있는 구조입니다.
견적 발송 외부 서비스를 쓰지 않고, 자동화 기술을 따로 갖고 있지도 않다면, 지메일을 쓰는 회사 대부분이 이 선에서 멈춰 있을 것이라고 생각합니다.
미룬 진짜 이유는 견적 로직이었습니다
시간이 없었다는 것은 절반만 맞는 말입니다. 진짜 이유는 우리 견적이 생각보다 복잡했기 때문입니다.
- 우리 회사는 제품 가격을 USD로 고시합니다. 그런데 고객에게 나가는 견적은 원화입니다. 요청 시점의 환율을 반영해야 합니다
- 제품마다 할인율이 다릅니다
- 수량이 올라가면 붙는 볼륨 할인도 제품마다 제각각입니다
이 셋이 겹치면 견적 한 장에 들어가는 계산이 단순해지지 않습니다. 가격표를 불러와서 수량만 곱하면 되는 일이 아닙니다. 자동화하기 까다로운 조건이 맞고, 그래서 계속 사람이 했습니다.
클로드와 함께, 몇 시간
이번에는 클로드와 같이 붙었습니다. 놀랍게도 몇 시간 만에 끝났습니다.
견적 요청 양식을 홈페이지 안으로 옮겼습니다
기존 요청 양식은 구글 양식이었습니다. 기능에는 문제가 없는데 디자인이 홈페이지와 너무 달랐습니다. 회사 사이트를 보던 고객이 견적 요청을 누르는 순간 갑자기 구글 화면으로 넘어갑니다. 이질감이 큽니다.
마침 홈페이지가 이번 이전 작업으로 HTML과 CSS와 JS 파일이 되어 제 손에 들어와 있었습니다. 그래서 견적 요청 양식을 홈페이지 안에 새로 만들었습니다. 지난 이전 작업이 여기서 바로 값을 했습니다.
가격과 할인율을 코드 밖으로 뺐습니다
복잡한 계산은 이렇게 풀었습니다. 제품 가격 테이블과 할인율 테이블을 별도 구글 시트로 만들고, 앱스 스크립트가 그 시트를 참조해서 견적을 계산하도록 했습니다.
이 구조가 중요합니다. 가격이 바뀌거나 할인 정책이 바뀔 때 코드를 고칠 필요가 없습니다. 시트의 숫자만 바꾸면 됩니다. 자주 바뀌는 값을 개발자가 아닌 사람도 관리할 수 있는 자리에 꺼내 둔 것입니다.
환율은 실시간으로, 그리고 기관을 3중으로
원화 견적의 핵심은 환율입니다. 한국수출입은행이 제공하는 API로 견적을 만드는 시점의 환율을 실시간으로 가져오게 했습니다.
여기서 하나를 더 했습니다. 수출입은행 쪽에 문제가 생기면 견적이 아예 나가지 못합니다. 자동화에서 가장 곤란한 상황입니다. 그래서 1순위가 응답하지 않으면 2순위로, 그것도 안 되면 3순위 기관에서 환율을 가져오도록 코드 안에 대체 경로를 넣었습니다.
자동화를 만들 때 이 부분을 빠뜨리기 쉽습니다. 잘 되는 경우의 흐름만 만들어 두면, 안 될 때는 아무 일도 일어나지 않습니다. 그리고 그 사실을 며칠 뒤에 알게 됩니다.
PDF 발송까지 5분
계산이 끝나면 견적서를 PDF로 만들어 고객에게 메일로 보냅니다. 고객이 요청을 넣은 순간부터 견적 PDF를 받기까지 5분을 넘지 않도록 전체 흐름을 맞췄습니다.
하루가 5분이 됐습니다
제품을 파는 회사 입장에서 견적 요청에 얼마나 빨리 답하느냐가 얼마나 중요한지는, 물건을 팔아 보신 분들이라면 설명이 필요 없을 것입니다.
| 이전 | 이후 | |
|---|---|---|
| 요청 양식 | 구글 양식 | 홈페이지 안 |
| 견적 작성 | 사람이 수동으로 | 자동 계산 |
| 환율 반영 | 그때그때 확인 | 요청 시점 환율 자동 |
| 가격과 할인 관리 | 담당자 머릿속과 파일 | 구글 시트 |
| 견적서 형태 | 작성하는 사람에 따라 | PDF로 통일 |
| 고객이 받기까지 | 몇 시간에서 하루 | 5분 이내 |
수작업일 때는 견적을 만드는 일 자체보다 다른 일에 밀려서 손을 못 대는 시간이 길었습니다. 바쁘면 반나절이 지나갔고, 더 바쁘면 다음 날이 됐습니다. 지금은 제가 바쁜 것과 견적이 나가는 속도 사이에 아무 관계가 없습니다.
비슷한 상황이라면
- 구글 워크스페이스를 쓰고 계시다면 앱스 스크립트는 이미 요금에 포함돼 있습니다. 새로 결제할 것이 없습니다
- 가격이나 할인율처럼 자주 바뀌는 값은 코드가 아니라 시트에 두세요. 나중에 사람을 부르지 않아도 됩니다
- 외부 API를 쓴다면 그 API가 죽는 날을 가정하고 대체 경로를 넣으세요. 자동화는 조용히 실패합니다
- 견적 요청 양식은 가능하면 자사 사이트 안에 두세요. 이탈이 줄고 디자인도 지켜집니다
- 로직이 복잡해서 자동화가 안 된다는 판단은 다시 볼 만합니다. 규칙이 복잡할수록 사람이 반복하면 실수가 납니다. 자동화가 더 필요한 쪽입니다
- 대응 속도는 그 자체가 영업력입니다. 견적이 하루 늦으면 그 하루 동안 고객은 다른 곳을 봅니다
그래서
이번에 든 생각은 이렇습니다. 우리는 이미 도구를 갖고 있었습니다. 구글 워크스페이스 요금은 몇 년째 내고 있었고, 앱스 스크립트는 그 안에 계속 있었습니다. 부족했던 것은 도구가 아니라 앉아서 그것을 코드로 옮길 시간이었습니다.
AI가 바꾼 것이 정확히 그 지점입니다. 몇 년을 미룬 일이 몇 시간이 됐습니다. 홈페이지 이전 때와 똑같은 경험을 두 번째로 한 셈입니다.
그런데 이 다음 항목에서 저는 도구를 하나 더 들이게 됩니다. 잘 돌아가는 자동화를 그대로 두고 왜 그랬는지는 다음 글에 적겠습니다.
비슷한 상황이라면 편하게 물어보세요. hello@codechains.dev
← 목록으로