숨고 스마트견적으로 견적 자동화, 자체 입찰 파이프라인을 버린 이유

무엇이 문제였나: 숨고 캐시 0, 보낸 견적 0건

숨고에서 견적을 한 건도 보내지 못하고 있었습니다. 숨고는 고객이 “이런 일을 맡기고 싶다”는 요청서를 올리고, 전문가가 그 요청서를 보고 견적을 보내는 마켓입니다. 견적을 보내려면 캐시가 필요한데, 저희 계정의 보유 캐시는 0이었습니다. 요청서가 아무리 많이 올라와도 보낼 수 있는 견적은 0건이었습니다.

겉으로는 영업 채널 하나가 조용한 상태로 보였습니다. 오류 메시지도 없고 경고도 뜨지 않았습니다. 하지만 비용으로 따지면 이 채널의 매출 기회는 정확히 0이었습니다. 마켓에 가입하고 프로필을 채우는 데 들인 시간이 그대로 묶여 있었고, 다른 마켓에서 쌓은 영업 장치도 여기서는 하나도 작동하지 않았습니다.

다른 마켓도 사정이 넉넉하지는 않았습니다. 이 결정 뒤인 2026년 10월 13일 기준으로도 위시켓에서 열람된 9건은 미팅 0건으로 끝나 있었고, 그래서 프로필 신뢰 신호를 따로 보강하고 있었습니다. 저희가 관리하는 채널 목록 파일에는 26곳이 올라 있고, 숨고도 그중 하나입니다. 한 채널에 기대기 어려운 구조라, 가입만 해 두고 멈춘 채널을 하나씩 움직이게 만드는 일이 중요했습니다.

그래서 질문은 단순했습니다. “숨고에서 견적을 자동으로, 빠르게, 싸게 보내려면 무엇을 바꿔야 하나?” 이 글은 그 질문에 저희가 처음 내놓은 답이 틀렸고, 실제로 바꾼 지점은 다른 곳이었다는 기록입니다. 숨고 스마트견적을 쓸지 고민하는 1인 사업자나 소규모 팀에게 판단 순서를 보여 드리려고 씁니다.

처음 잰 숫자: 요청 수명 1시간, 알림 경로는 카카오톡 하나

자동화를 설계하기 전에 숨고가 요청을 어떻게 흘려보내는지부터 확인했습니다. 근거는 두 곳입니다. 보유 캐시는 전문가 계정의 잔액으로 확인했고, 요청서 수명과 알림 경로는 2026년 10월 3일에 자동 입찰 구조를 검토하면서 기록으로 남긴 내용입니다. 정밀한 계측 장비를 쓴 측정은 아니고, 검토 기록에 적힌 사실을 그대로 옮깁니다.

결과는 세 숫자로 정리됐습니다. 첫째, 보유 캐시는 0이었습니다. 둘째, 요청서는 1시간 안에 사라졌습니다. 고객이 올린 요청에 견적을 넣을 수 있는 창이 길지 않다는 뜻입니다. 셋째, 새 요청을 알려 주는 알림은 카카오톡 알림톡 하나뿐이었습니다. 검토 기록에는 이 경로 하나만 적혀 있고, 프로그램이 바로 받아 쓸 수 있는 다른 경로는 없었습니다.

이 셋을 나란히 놓으면 자동화가 넘어야 할 조건이 보입니다. 1시간이라는 짧은 창 안에 요청을 알아채고, 요청 내용을 읽고, 가격이 붙은 견적을 보내야 합니다. 그리고 그 전에 보낼 캐시가 있어야 합니다. 처음에는 이 넷 가운데 앞의 셋만 눈에 들어왔습니다.

어떤 가설을 세웠나?: 알림을 모아 직접 입찰하면 된다

처음 세운 가설은 “알림을 모아 우리 프로그램이 직접 견적을 넣으면 해결한다”였습니다. 저희는 이미 위시켓 같은 다른 마켓에서 공고를 수집하고 프로필을 입력하는 스크립트를 여럿 운영하고 있었습니다. 같은 방식을 숨고에도 쓰면 사람이 화면을 들여다보지 않아도 요청마다 견적이 나갈 거라고 봤습니다.

• **가설 1: 속도가 병목이다.** 요청서가 1시간 안에 사라지니, 사람이 알림을 보고 손으로 견적을 쓰면 늦는다. 프로그램이 알림을 받자마자 견적을 넣으면 놓치는 요청이 줄어든다.
• **가설 2: 직접 만들어야 통제할 수 있다.** 숨고 안의 기능에 맡기면 견적 문안과 가격을 우리 기준대로 조정하기 어렵다. 우리 파이프라인이면 요청마다 문안을 고르고 기록을 남길 수 있다.
• **가설 3: 캐시는 나중 문제다.** 자동 입찰 구조부터 만들어 두면, 캐시는 필요할 때 채우면 그만이다.

세 가설 모두 그럴듯했습니다. 가설 1은 측정한 1시간이라는 숫자에서 나왔고, 가설 2는 다른 마켓에서 실제로 해 온 방식이었습니다. 가설 3은 순서 문제로 보였습니다. 그래서 바로 만들지 않고, 2026년 10월 3일에 이 구조를 검토하면서 가설마다 무엇이 보여야 맞는지 정했습니다.

가설 1이 맞다면 우리 파이프라인이 숨고 내부 기능보다 요청을 빨리 받아야 합니다. 가설 2가 맞다면 우리 쪽 통제력이 만드는 비용보다 커야 합니다. 가설 3이 맞다면 캐시 없이도 파이프라인이 무언가를 만들어 내야 합니다. 이 세 질문을 하나씩 따져 봤습니다.

자체 입찰 파이프라인 가설은 어디서 틀렸나?

가설 1부터 무너졌습니다. 새 요청을 알려 주는 경로가 카카오톡 알림톡뿐이니, 우리 파이프라인은 먼저 카카오톡 메시지를 읽어 와야 합니다. 알림이 휴대폰에 도착하고, 그 메시지를 프로그램이 가져오고, 다시 숨고 화면에 들어가 견적을 넣는 세 단계를 거칩니다. 숨고 내부 자동 발송은 이 중간 단계 없이 요청이 들어온 그 자리에서 돕니다. 속도 경쟁이라면 바깥에서 따라가는 쪽이 이길 수 없습니다.

가설 2도 비용 앞에서 버티지 못했습니다. 메신저 알림을 수집하는 장치, 숨고 화면에 로그인해 입력하는 장치, 실패했을 때 다시 시도하는 장치를 전부 새로 만들어야 합니다. 요청서 수명이 1시간이니 이 장치들은 늘 켜져 있어야 하고, 하나라도 멈추면 그 시간대 요청은 그대로 사라집니다. 통제력을 얻는 대가로 유지보수할 부품이 셋 이상 늘어나는 구조였습니다.

결정적으로 틀린 쪽은 가설 3이었습니다. 보유 캐시가 0이면 파이프라인이 아무리 빨라도 보낼 수 있는 견적은 0건입니다. 자동화 구조를 먼저 만들고 캐시를 나중에 채운다는 순서는, 지금 막힌 문제를 뒤로 미룬 채 막히지 않은 문제에 공수를 쓰는 선택이었습니다.

돌이켜 보면 이 가설들은 저희가 잘하는 일에서 출발했습니다. 수집 스크립트와 입력기를 만드는 일은 익숙했고, 익숙한 도구로 보면 대부분의 문제가 “아직 자동화하지 않은 문제”처럼 보입니다. 이 글에서 가장 남기고 싶은 교훈도 여기에 있습니다. 증상을 처음 읽을 때 쓴 렌즈가 그 뒤의 가설 전부를 정합니다.

2026년 10월 3일 검토의 결론은 기각이었습니다. 기록에 남긴 이유는 한 줄입니다. “요청은 1시간 내 소멸, 알림은 카톡뿐이라 숨고 내부 자동 발송이 빠르고 싸다.” 가설 셋을 버린 자리에 남은 질문은 하나였습니다. 그렇다면 무엇이 실제로 견적을 막고 있었나.

진짜 원인은 무엇이었나?: 속도보다 먼저 잔액

진짜 원인은 기술이 아니라 잔액이었습니다. 견적 0건의 원인을 거슬러 올라가면 첫 칸에 보유 캐시 0이 있었고, 속도나 문안 품질은 그다음 칸이었습니다. 캐시가 0인 동안에는 자동화를 어떻게 설계하든 결과가 같았습니다.

이 순서를 늦게 본 이유도 기록해 둡니다. 저희는 자동화를 만드는 일에 익숙했고, 그래서 “견적을 못 보낸다”는 증상을 “견적 보내는 속도가 느리다”로 읽었습니다. 1시간이라는 숫자가 눈에 띄면서 속도 문제처럼 보였고, 0이라는 숫자는 너무 단순해서 문제 목록 맨 아래로 밀렸습니다.

두 번째 원인은 속도였지만, 이 문제의 답은 우리 손 밖에 있었습니다. 요청이 숨고 안에서 생기고 숨고 안에서 사라지니, 가장 빠른 발송 지점도 숨고 안입니다. 그래서 진짜 원인을 두 줄로 정리했습니다.

• **1순위: 보유 캐시 0.** 이 문제를 풀기 전에는 어떤 자동화도 견적 0건을 바꾸지 못한다.
• **2순위: 1시간 창과 카톡 알림.** 바깥에서 알림을 받아 따라가는 구조로는 숨고 내부 발송보다 빠를 수 없다. 이 칸의 답은 플랫폼 기능을 쓰는 쪽이다.

결제가 손해로 끝날 위험도 따져 봤습니다. 이벤트 조건에는 20일 안에 견적 30건과 스마트견적 1회를 쓰고도 거래가 없으면 19,900원을 전액 돌려준다는 조항이 있었습니다. 견적을 충분히 보내기만 하면, 거래가 0건이어도 잃는 돈은 0원에 가깝다는 뜻입니다. 반대로 견적을 30건 채우지 못하면 환급 조건도 사라집니다. 결제 위험을 줄이는 열쇠가 다시 견적 발송량으로 돌아오는 구조였고, 이 점이 자동 발송을 서둘러 켜야 하는 이유가 됐습니다.

이렇게 나누고 나니 해야 할 일이 바뀌었습니다. 새 파이프라인을 만드는 일은 목록에서 빠졌고, 캐시를 확보하는 일과 숨고 스마트견적을 우리 기준에 맞게 켜는 일 두 가지가 남았습니다.

조치: 19,900원 이벤트 결제와 숨고 스마트견적

캐시는 숨고의 “첫 출발 이벤트”로 확보했습니다. 조건은 19,900원을 결제하면 보너스캐시 50만을 주는 구조였습니다. 계산하면 결제 금액의 약 25배를 캐시로 받는 셈입니다. 대신 보너스캐시는 20일 뒤 사라지고, 20일 안에 견적 30건과 스마트견적 1회를 쓰고도 거래가 한 건도 없으면 결제 금액을 전액 환급해 주는 조건이 붙어 있었습니다. 이벤트 마감은 2026년 10월 5일 14시경이었습니다.

결제에는 대표 승인을 먼저 받았습니다. 돈이 나가는 일이라 담당자가 혼자 결정하지 않는 규칙을 따랐습니다. 승인은 2026년 10월 4일에 났고, 같은 날 14:28:53에 결제를 마쳤습니다. 마감보다 하루 앞선 시점이었습니다.

자동 발송은 우리 파이프라인을 만들지 않고 숨고 스마트견적으로 정했습니다. 다만 그냥 켜지는 않았습니다. 자동 견적은 가격이 붙은 채 고객에게 나가는 외부 메시지이고, 한 번 나간 견적은 되돌리기 어렵습니다. 그래서 켜기 전에 대표 승인 한 줄을 받는 단계를 넣었습니다. 순서는 다음과 같습니다.

• 스마트견적 문안 5개 초안을 작성한다
• 대표가 문안과 가격을 보고 승인 한 줄을 남긴다
• 승인한 문안으로만 스마트견적을 켠다

돌아보면 조치 자체는 작았습니다. 새 코드는 한 줄도 쓰지 않았고, 결제 한 번과 설정 한 번이 전부입니다. 처음 가설대로 갔다면 알림 수집기와 입력기를 만드는 데 시간을 쓰고도 캐시 0 앞에서 멈췄을 겁니다.

재측정 결과는 어떻게 나왔나?: 잔액 500,000캐시, 성과 판정은 10월 24일

결제 직후 잔액 화면을 다시 열어 쟀습니다. 보유 캐시는 0에서 500,000캐시로 바뀌었습니다. 견적을 보낼 수 없던 계정이 견적을 보낼 수 있는 계정으로 바뀐 셈이고, 이 글에서 확정된 개선은 여기까지입니다.

성과는 아직 재지 못했습니다. 이 글을 쓰는 시점의 기록에는 결제와 잔액 확인까지만 있습니다. 대신 결과가 나오기 전에 예측을 숫자로 적어 두었습니다. 20일 동안 자동 견적 15~40건, 고객 응답 2~5건, 계약 0~1건입니다. 판정일은 2026년 10월 24일로 잡았습니다.

예측을 먼저 적은 이유가 있습니다. 결과를 본 뒤에 “이 정도면 괜찮다”고 말하기는 쉽습니다. 미리 범위를 적어 두면 실제 숫자가 그 범위를 벗어났을 때 어디서 판단이 틀렸는지 가려낼 수 있습니다. 계약 0건도 예측 범위 안에 넣었습니다. 20일 만에 계약이 나오지 않을 가능성을 처음부터 열어 두었다는 뜻입니다.

판정일에는 결과를 세 갈래로 나눠 읽을 생각입니다. 자동 견적이 예측 범위 안에 들고 응답도 2건 이상이면, 캐시를 먼저 풀고 플랫폼 기능에 맡긴 판단이 맞았다는 근거가 됩니다. 견적은 충분히 나갔는데 응답이 2건에 못 미치면, 병목이 발송에서 견적 문안과 프로필 쪽으로 옮겨 갔다고 봅니다. 견적 자체가 15건 아래라면 숨고에 들어오는 요청이 적었거나 스마트견적 설정이 요청을 너무 좁게 걸렀다는 뜻이라, 설정부터 다시 봅니다. 어느 쪽이든 한 번 재고 끝내지 않고 그 숫자로 다음 조치를 정합니다.

환급 조건과 예측을 나란히 놓으면 긴장도 하나 보입니다. 환급을 받으려면 견적 30건을 써야 하는데, 예측한 자동 견적은 15~40건입니다. 예측 하단으로 끝나면 환급 조건을 채우지 못합니다. 이 차이는 판정일에 실측으로 확인합니다.

남는 한계: 20일 소멸, 환급 조건, 가격이 붙은 자동 메시지

첫째, 보너스캐시는 20일 뒤 사라집니다. 500,000캐시가 잔액에 찍혀 있어도 기한 안에 쓰지 못하면 남는 값이 없습니다. 견적 30건과 스마트견적 1회라는 환급 조건도 같은 20일 안에 채워야 합니다. 시간이 지날수록 이 숫자들은 기회가 아니라 마감이 됩니다.

둘째, 자동 견적은 사람 승인이 한 번 끼는 구조입니다. 가격이 붙은 메시지가 고객에게 바로 나가니, 문안 5개를 승인받기 전에는 스마트견적을 켤 수 없습니다. 승인이 늦어지면 20일 가운데 쓸 수 있는 날이 줄어듭니다. 안전장치와 속도가 서로 당기는 지점입니다.

셋째, 숨고 스마트견적에 맡긴 만큼 통제력을 잃었습니다. 가설 2에서 걱정했던 대로 요청마다 문안을 세밀하게 고르거나 우리 쪽 기록을 자동으로 남기는 일은 어렵습니다. 저희는 이 손실을 속도와 비용 이득과 바꿨고, 그 교환이 옳았는지는 10월 24일 판정에서 확인합니다.

넷째, 이 판단은 한 마켓에서 내린 결론입니다. 위시켓처럼 공고를 공개로 띄우는 마켓에서는 지금도 수집 스크립트가 쓸모 있습니다. 숨고처럼 요청 수명이 짧고 알림 경로가 하나뿐인 마켓이라 플랫폼 기능이 이겼을 뿐, “직접 만들지 말라”는 일반 규칙으로 옮기기는 어렵습니다. 위시켓 쪽 채점 기준을 바꾼 이야기는 외주 공고 채점, 키워드 대신 시간당 수령액으로에 따로 정리했습니다.

다섯째, 예측이 빗나갈 수 있습니다. 응답이 2건 아래로 나오면 문제는 캐시도 속도도 아닌 견적 문안이나 프로필 신뢰일 가능성이 큽니다. 위시켓에서 열람 9건이 미팅 0건으로 끝난 경험이 있어서, 노출이 계약으로 바로 이어지지 않는다는 점은 이미 알고 있습니다.

마지막으로, 이 글이 보여 준 개선은 아직 한 칸뿐입니다. 보유 캐시 0을 500,000캐시로 바꿔 견적을 보낼 수 있게 만든 데까지가 확정이고, 그 캐시가 응답과 계약으로 이어지는지는 판정 전입니다. 개선율 대신 절대값을 그대로 남긴 이유도 여기 있습니다. 판정일에 숫자가 예측보다 나쁘게 나오더라도 이 기록은 고치지 않고 그 아래에 이어 적겠습니다.

숨고 스마트견적을 켜기 전에 무엇을 확인해야 하나?

같은 고민을 하는 1인 사업자나 소규모 팀을 위해 저희가 거친 판단 순서를 체크리스트로 남깁니다. 자동화부터 만들고 싶을 때 한 번 멈춰서 아래 순서로 따져 보면, 저희가 돌아간 우회로를 건너뛸 수 있습니다.

이 판단에 특별한 계측 도구가 필요하지는 않았습니다. 잔액은 계정에서 바로 보이고, 요청 수명과 알림 경로는 마켓을 며칠만 써 봐도 드러나는 사실입니다. 어려운 일은 숫자를 구하는 쪽이 아니라 순서를 매기는 쪽이었습니다. 다만 이 세 숫자를 같은 표에 놓기 전까지는 무엇이 첫 칸인지 보이지 않았습니다. 숫자를 따로따로 보면 각자 그럴듯한 문제로 보이고, 한 줄로 세워야 순서가 드러납니다.

• **잔액부터 본다.** 보유 캐시가 0이면 어떤 자동화도 견적 0건을 바꾸지 못한다. 첫 칸이 막혀 있으면 그 칸부터 푼다.
• **요청 수명을 잰다.** 요청이 1시간 안에 사라지는 마켓이라면 바깥에서 따라가는 구조는 늦는다.
• **알림 경로를 센다.** 알림이 메신저 하나로만 온다면 수집 장치가 하나 더 필요하고, 그 장치가 멈추는 시간만큼 요청을 잃는다.
• **플랫폼 기능과 직접 구축을 같은 표에 놓는다.** 속도·유지보수 부품 수·통제력 세 칸을 비교한다.
• **가격이 붙은 자동 메시지는 사람 승인 한 줄을 거친다.** 한 번 나간 견적은 되돌리기 어렵다.
• **결과 전에 예측을 숫자로 적는다.** 견적 수·응답 수·계약 수의 범위와 판정일을 미리 정한다.

이벤트 조건은 마켓과 시기마다 다르니, 결제 전에 금액·지급 캐시·소멸 기한·환급 조건 네 칸을 직접 확인하시길 권합니다. 마켓별 견적 자동화를 어디까지 직접 만들고 어디부터 플랫폼에 맡길지 정하기 어렵다면 상담으로 상황을 보내 주셔도 좋습니다.

작성: SGK Studio 개발팀. 10월 24일 판정이 나오면 실측 숫자로 이 글의 재측정 결과 칸을 이어서 채우겠습니다.