● AX 사례 · 방법론

챗 한 줄에서 견적서까지 — 파이프라인 속 스킬

2026년 6월 24일 · 이종진

요약 — 개발 견적서를 챗 한 줄로 만든다. 다만 우리가 만든 건 자동 견적기가 아니라, 세일즈 파이프라인 안에서 사람과 함께 일하는 스킬이다. 사람은 숫자를 승인하고 메일을 보내는 두 순간만 쥐고, 시트 복사와 수식, PDF, 메일 초안 같은 기계적인 일은 스킬이 처리한다. 자동화의 값은 PDF가 아니라 사람이 판단할 두 순간만 남기고 나머지를 지운 데 있다.

세일즈에는 흐름이 있다. 리드가 들어오고, 상담으로 자격을 보고, 견적을 내고, 보내고, 닫는다. 이 중 견적은 유독 손이 많이 가는 칸이다. 시트를 열어 템플릿을 복사하고, 회사명과 항목과 단가를 채우고, 합계 수식을 확인하고, PDF로 뽑고, 메일에 첨부하고, 서명을 붙인다. 매번 같은 동작을 사람이 반복한다.

그래서 자동 견적기를 만들려 했다. 그런데 만들다 보니 방향이 조금 틀렸다. 우리에게 필요한 건 견적서를 뱉는 별도 도구가 아니라, 영업하는 흐름 안에서 그 한 칸을 대신 밟아 주는 스킬이었다.

세일즈 파이프라인(리드→상담→견적→발송→클로징) 속 견적 스킬 — 영업 담당의 챗 한 줄, ①승인 게이트(사람), gog 엔진(시트·PDF), ②발송 게이트(사람, 메일 초안), 산출물(PDF·Drive·Gmail 초안) — 세일즈 파이프라인 속 견적 스킬 — 사람은 승인·발송 두 게이트만 쥐고, 그 사이는 스킬이 처리한다

도구가 아니라 스킬

왜 앱이 아니라 스킬인가. 앱을 만들면 사람은 견적을 내려고 그 앱으로 가야 한다. 창이 하나 더 늘고, 로그인이 하나 더 는다. 스킬은 반대다. 이미 일하고 있는 자리, 그러니까 챗에서 자연어 한 줄이면 된다.

슬래시 커맨드 /견적서 뒤에 "주식회사 ○○ 김□□ 팀장님, 크롬 확장 수정 500만, 메일 boss@example.com"이라고 던진다. 스킬이 수신처와 항목과 단가를 알아서 뽑고, 빠진 정보는 한 번에 모아 되묻는다. 도구를 찾아가는 게 아니라, 일하던 자리에서 부른다.

사람이 쥐는 두 개의 게이트

자동화가 무서운 이유는 분명하다. 사람 손을 떠난 뒤 잘못 나간다. 그래서 사람이 반드시 붙잡아야 할 두 순간을 게이트로 뒀다.

① 숫자 승인. 정보를 뽑아도 스킬은 곧장 만들지 않는다. 공급가액·VAT(10%)·총액을 계산해 표로 보여주고 멈춘다. 사람이 숫자를 확인하고 "좋다"고 해야 그때 생성이 돈다. 승인 전에는 어떤 파일도 만들어지지 않는다.

② 메일 발송. 메일까지 원하면 스킬은 PDF를 첨부하고 서명까지 붙인 초안을 만든다. 딱 거기까지다. 절대 자동으로 보내지 않는다. 받는 사람, 제목, 문구를 사람이 Gmail에서 최종 검토하고 직접 보낸다.

두 게이트는 우연이 아니라 설계다. 얼마를 부를지, 누구에게 보낼지. 판단이 필요한 두 순간은 사람이 정하고, 그 사이 기계적인 일만 스킬이 가져간다. human-in-the-loop을 나중에 덧댄 게 아니라, 처음부터 그렇게 그었다.

기계적인 가운데는 스킬이

그 "가운데"는 이렇게 돈다. 엔진은 서버도 Apps Script도 아닌 gog라는 CLI 하나다.

견적서 양식 자체는 우리가 처음부터 만든 게 아니다. Bolta가 제공한 견적서 템플릿을 참고해 우리 것으로 내재화했다. 스킬은 그 표준 템플릿을 이렇게 다룬다.

Google Drive의 표준 견적 템플릿을 복사한다.
복사본 셀에 값과 수식을 기입한다(USER_ENTERED). 수신 정보와 항목표, 그리고 행별 =G*H 합계와 =SUM(...) 총액을 수식으로 넣는다. 숫자를 우리가 계산해 박지 않고 시트가 계산하게 둔다.
PDF로 export 한다. 로컬에 저장하고 Drive 링크를 돌려준다.
(선택) PDF를 첨부한 Gmail 초안을 만든다. 기본 서명은 자동으로 붙인다.

서버 한 대 없이, 파이썬 표준 라이브러리와 CLI 하나로 시트 복사부터 메일 초안까지 이어진다.¹ 인프라가 가벼우니 스킬이 가볍다. 가벼워야 파이프라인의 한 칸으로 부담 없이 끼워 넣는다.

스킬이 생성한 견적서 PDF 샘플 — 공급자(801플래닛) 정보는 템플릿에 고정, 수신처는 비어 있고, 항목·제안가(VAT 별도)가 채워진 상태 — 스킬이 뽑아낸 견적서 PDF — 공급자 정보는 템플릿에 고정되고, 수신처와 항목만 채워진다 (수신처를 비운 샘플)

비슷한 과제를 다루고 계신가요?30분 무료 진단 받기 →

가드레일이 곧 신뢰

스킬에 일을 맡기려면 스킬이 사고를 안 쳐야 한다. 그래서 몇 개의 가드레일을 코드에 박았다.

공급자 정보는 고정. 공급자(우리) 정보는 템플릿에 박혀 있고, 스킬은 입력받지도 수정하지도 않는다. 잘못 덮어쓸 여지 자체를 없앴다.
항목 한도. 템플릿 항목 행은 7개다. 8개가 들어오면 늘리는 대신 막고 알린다 — 초과분이 비고 영역을 덮어쓰는 사고를 방지한다.
금액 정규화. "1500만"이라고 말하면 15,000,000으로, "1.5억"이면 150,000,000으로 스킬이 바꾼다. 사람의 말투와 시트의 정수 사이를 스킬이 메운다.
발송 금지. 앞서 말한 대로, 메일은 초안까지만.

가드레일은 제약이 아니라 신뢰의 조건이다. 스킬이 밟을 수 있는 범위를 좁게 그어야, 그 안에서 사람이 손을 떼도 된다.

파이프라인으로 이어붙는다

스킬이 뱉는 건 파일 하나가 아니라 다음 단계로 넘어가는 산출물들이다. 로컬 PDF, Drive 링크, 발송 대기 중인 메일 초안. 견적 칸에서 발송 칸으로 손을 바꿔 쥐는 핸드오프다.

파이프라인 자체는 거창한 CRM 도구가 아니라 Notion으로 굴린다. 세일즈 단계는 Notion 데이터베이스 한 곳에서 관리하고, 고객사 정보는 별도의 Notion Database에 둔다. 둘은 관계형 속성으로 연결돼 있어, 딜 하나를 열면 어느 고객사인지와 지금 어느 단계인지가 함께 딸려 온다.

그래서 견적 스킬은 혼자 돌지 않는다. 다른 스킬과 엮여 Notion을 CRM처럼 읽는다. 견적을 만들기 전에, 필요하면 그 고객사가 파이프라인의 어느 단계에 있는지, 지금까지 어떤 접점이 있었는지 타임라인을 조회한다. 챗 한 줄이 백지에서 시작하지 않는다는 뜻이다. 스킬이 견적을 뽑는 순간에도 이 고객이 누구고 딜이 어디까지 왔는지가 손안에 있다.

여기서 핵심이 드러난다. 견적 스킬은 완결된 앱이 아니라 파이프라인의 조립 가능한 한 칸이다. 같은 방식으로 다음 칸도 스킬이 될 수 있다. 발송 후 팔로업, Notion 파이프라인 단계 갱신, 계약서 초안. 각 스킬은 자기 자리에서 기계적인 일을 가져가고, 사람이 판단할 게이트만 남긴다. 앱을 여러 개 만드는 게 아니라 일하는 흐름에 스킬을 하나씩 심는다.

견적 다음에 오는 정형 업무도 같은 패턴에 잘 맞는다. 세금계산서 발행이 그렇다. Bolta가 보여준 CLI 기반 세금계산서 자동화²가 좋은 참고인데, 우리도 같은 방향을 지금 검토하고 있다.³

남는 것

자동화의 값을 PDF 개수로 세면 오해다. 이 스킬이 실제로 한 일은 사람이 판단할 두 순간만 남기고, 그 사이 반복 동작을 지운 것이다. 얼마를 부를지와 누구에게 보낼지는 그대로 사람이 쥔다. 시트를 복사하고 수식을 확인하고 서명을 붙이던 손만 사라졌다.

"AI로 자동화했다"가 슬라이드에서 근사해 보여도, 운영에서 살아남는 건 사람의 판단을 지우지 않는 자동화다. 도구를 하나 더 만드는 대신 일하는 방식 안에 스킬을 심는 것 — 그게 우리가 견적서 한 장에서 다시 확인한 방법이다.

이런 식으로 AI를 실제 업무 흐름에 심는 일은 AX 컨설팅과 제품 개발에서 다루는 일의 일부다. 핵심은 근사한 데모가 아니라, 사람이 계속 쥐고 있어도 되는 자동화다.

참고 자료

본문의 스킬 동작은 우리가 실제로 운영하는 내부 스킬의 구성이다. 외부 도구·플랫폼은 아래 공식 문서를 따른다.

gog — Google Workspace를 다루는 CLI. https://gogcli.sh ↩
Bolta — CLI 기반 세금계산서 자동화. https://bolta.io/insight/bolta-cli-tax-invoice-automation ↩
Anthropic — Claude Code 문서(Skills). https://docs.claude.com/en/docs/claude-code ↩