숨고 스마트견적으로 자동 견적, 입찰 봇을 직접 만들지 않은 이유

무엇이 문제였나: 요청서는 보이는데 견적을 한 건도 못 보냈다

숨고 스마트견적을 켜기로 한 이유는 단순합니다. 견적을 못 보내던 진짜 원인은 손이 느려서가 아니라 견적을 보낼 캐시가 0이었기 때문입니다. 저희는 이 사실을 확인하기 전까지 엉뚱한 쪽, 즉 견적을 더 빨리 보내는 프로그램을 먼저 떠올렸습니다. 이 글은 그 계획을 왜 접었는지, 그리고 그 대신 무엇을 했는지를 숫자와 함께 남긴 기록입니다.

숨고는 구조가 분명한 플랫폼입니다. 고객이 '홈페이지를 만들고 싶다' 같은 요청서를 올리면, 그 분야에 등록한 고수들이 견적을 보내고, 고객은 받은 견적 중에서 마음에 드는 쪽과 대화를 시작합니다. 고수 쪽에서 보면 영업의 첫 단계가 곧 견적 발송입니다. 견적을 보내지 못하면 요청서가 아무리 많이 올라와도 저희와는 상관없는 일이 됩니다.

문제는 견적 발송에 비용이 든다는 점이었습니다. 숨고는 견적을 보낼 때 플랫폼 화폐인 캐시를 씁니다. 당시 저희 계정의 보유 캐시는 0이었고, 그래서 견적을 한 건도 보내지 못했습니다. 비용으로 따지면 매출이 0인 상태가 그대로 이어졌고, 시간으로 따지면 요청서를 읽고도 아무 행동을 못 하는 시간이 쌓였습니다. 실패율로 말하면 보내려던 견적의 전부가 출발선에서 멈췄습니다.

여기에 속도 문제가 겹쳤습니다. 나중에 확인한 사실이지만 숨고의 요청은 1시간 안에 사라집니다. 고객이 요청서를 올린 뒤 그 1시간 안에 견적을 보내지 못하면 기회 자체가 없어집니다. 대표가 본업을 하면서 휴대폰 알림을 보고 그때그때 견적을 써서 보내는 방식으로는 이 속도를 맞추기 어렵습니다.

작은 스튜디오에게 이 상태는 꽤 아픕니다. 광고비를 쓰지 않고 일감을 받을 수 있는 통로가 중개 플랫폼인데, 그 통로의 입구에서 막혀 있었기 때문입니다. 요청서를 읽는 데 쓴 시간은 그대로 버려지고, 첫 계약이라는 목표는 한 걸음도 움직이지 않습니다. 그래서 이 문제를 '언젠가 손볼 일'이 아니라 바로 풀어야 할 일로 올렸습니다.

처음 잰 숫자: 보유 캐시 0, 견적 발송 0건

손대기 전에 상태를 숫자로 적었습니다. 측정 방법은 따로 도구를 만든 것이 아니라 숨고 고수 화면의 캐시 잔액과 보낸 견적 수를 직접 확인한 방식입니다. 결과는 보유 캐시 0, 보낸 견적 0건이었습니다. 이 두 숫자가 출발점입니다.

돌아보면 이 0이라는 숫자는 눈에 잘 띄지 않았습니다. 요청서 목록은 캐시가 없어도 계속 보입니다. 화면에는 일감이 넘치는데 손이 닿지 않으니, 처음에는 '요청을 빨리 잡지 못해서'라고 해석하기 쉬웠습니다. 그래서 숫자를 먼저 적는 단계가 중요했습니다. 보낸 견적 0건의 원인이 속도인지 자원인지는 잔액 화면 하나로 갈립니다.

같은 시기에 숨고가 신규 고수에게 여는 '첫 출발 이벤트'를 발견했습니다. 조건은 이렇습니다. 19,900원을 결제하면 보너스캐시 50만을 줍니다. 이 보너스캐시는 20일이 지나면 사라집니다. 그리고 20일 안에 견적 30건을 보내고 스마트견적을 1회 쓰고도 거래가 하나도 성사되지 않으면 결제한 19,900원을 전액 돌려줍니다. 이벤트 마감은 2026년 10월 5일 14시경이었습니다.

이 조건을 읽으면 위험의 상한이 보입니다. 조건을 채우고도 거래가 없으면 돌려받으니, 실제로 걸리는 돈은 결제액 19,900원을 넘지 않고, 환급 조건을 채우면 0원으로 끝납니다. 반대로 놓치면 캐시 0인 상태가 그대로 남습니다. 숫자만 보면 결제는 고민할 거리가 아니었습니다. 고민은 그다음, 50만 캐시를 20일 안에 어떻게 쓰느냐에 있었습니다.

정리하면 처음 잰 숫자는 세 개입니다. 보유 캐시 0, 보낸 견적 0건, 그리고 이벤트 마감까지 남은 하루 남짓한 시간입니다. 앞의 두 숫자는 문제를, 뒤의 숫자는 결정을 미룰 수 없는 이유를 보여 줬습니다. 이 셋을 적어 둔 뒤에야 무엇을 만들지가 아니라 무엇부터 할지를 따질 수 있었습니다.

세운 가설: 알림을 모아 직접 입찰하면 더 빠르고 정확하다

저희는 업무 자동화를 만드는 회사라서, 자연스럽게 만드는 쪽부터 생각했습니다. 첫 가설은 이랬습니다. 숨고가 보내는 새 요청 알림을 모으고, 요청 내용을 읽어 저희 서비스와 맞는지 판정한 뒤, 맞는 요청에만 저희가 쓴 견적을 자동으로 보내는 파이프라인을 직접 만들면 된다는 생각입니다.

이 가설에는 그럴듯한 근거가 있었습니다. 직접 만들면 판정 기준을 저희 마음대로 정할 수 있고, 견적 문구도 요청마다 다르게 쓸 수 있습니다. 다른 외주 플랫폼에서 공고를 모아 채점하는 수집기를 이미 운영해 본 경험도 있었습니다. 그 경험을 숨고에 옮기면 된다고 봤습니다. 비슷한 수집기를 다룬 글은 RPA로 외주 공고 수집 자동화, 하루 2회를 2시간 간격으로에 있습니다.

이 파이프라인이 제대로 돌려면 칸마다 할 일이 있었습니다. 요청 알림을 놓치지 않고 받아야 하고, 요청 내용에서 업종과 일의 종류를 뽑아야 하고, 맞는 요청이면 숨고 화면에 들어가 견적을 채워 보내야 합니다. 세 칸 모두 저희가 만들고, 고장 나면 저희가 고쳐야 하는 부분입니다. 가설은 이 일을 감수할 만큼 직접 만드는 쪽이 빠르고 정확하다는 데 걸려 있었습니다.

2026년 10월 3일, 이 가설을 실제로 검토했습니다. 검토 방법은 코드를 먼저 쓰는 대신, 요청이 들어와서 견적이 나갈 때까지의 경로를 한 칸씩 따라가 보며 각 칸에서 무엇이 필요한지 적어 보는 방식이었습니다.

가설이 틀린 지점은 어디였나? 요청은 1시간이면 사라지고, 알림은 카카오톡뿐이었다

경로를 따라가자 첫 칸에서 막혔습니다. 숨고가 새 요청을 알려 주는 경로는 카카오톡 알림톡 하나뿐이었습니다. 자체 파이프라인을 만들려면 먼저 이 카카오톡 메시지를 프로그램이 읽어야 합니다. 메일이나 공개 API처럼 프로그램이 받아 가기 좋은 통로가 아니라, 사람의 메신저로 들어오는 메시지를 다시 꺼내 와야 하는 구조였습니다.

두 번째 칸에서는 시간이 문제였습니다. 요청은 1시간 안에 사라집니다. 알림톡을 받아 → 내용을 꺼내고 → 판정하고 → 숨고 화면을 열어 견적을 보내는 경로는 칸이 하나 늘 때마다 지연과 고장 지점이 함께 늡니다. 1시간이라는 창은 넉넉해 보여도, 바깥에서 돌아 들어가는 경로가 한 번 멈추면 그 요청은 그대로 놓칩니다.

세 번째로 비용을 따졌습니다. 자체 파이프라인은 수집, 판정, 발송을 전부 만들고 유지해야 합니다. 반면 숨고에는 이미 '스마트견적'이라는 자동 견적 기능이 있었습니다. 고수가 견적을 미리 써 두면 조건에 맞는 요청에 숨고가 내부에서 자동으로 보내 줍니다. 같은 일을 플랫폼 안에서 하는 쪽이 빠르고 쌉니다. 결국 10월 3일 검토에서 자체 파이프라인 가설을 기각했습니다.

이 검토에서 저희가 틀린 지점은 분명합니다. 직접 만들면 더 정확하다는 생각은 맞을 수도 있지만, 더 빠르다는 생각은 틀렸습니다. 판정을 아무리 정교하게 만들어도 알림이 메신저를 거쳐 들어오는 순간 출발이 늦습니다. 정확도를 높이려고 만든 칸들이 오히려 1시간이라는 창을 갉아먹는 구조였습니다.

만들 수 있다는 사실과 만들어야 한다는 결론은 다르다. 요청이 1시간 안에 사라지는 곳에서는 플랫폼 안에서 가장 짧은 경로가 이긴다.

진짜 원인은 무엇이었나? 견적이 0건인 이유는 속도가 아니라 캐시 0이었다

가설을 접고 나서 처음 문제로 돌아가 다시 물었습니다. 왜 견적이 0건이었나. 답은 자동화가 없어서가 아니었습니다. 보유 캐시가 0이라 손으로든 자동으로든 견적을 보낼 수 없었습니다. 자체 파이프라인을 완성했더라도 캐시가 0이면 그 파이프라인은 첫 견적에서 멈췄을 것입니다.

두 번째 원인은 경로의 위치였습니다. 요청이 1시간 안에 사라지는 구조에서는 견적을 보내는 주체가 플랫폼 안에 있어야 유리합니다. 바깥 경로는 알림을 기다려야 하고, 알림은 사람의 메신저로 옵니다. 숨고 스마트견적은 이 대기 자체가 없습니다. 속도 경쟁에서 저희가 이길 수 있는 자리는 저희 코드가 아니라 숨고 안에 있었습니다.

저희가 처음에 만드는 쪽으로 기운 데도 이유가 있었습니다. 자동화를 만드는 회사는 문제를 보면 먼저 무엇을 만들지부터 떠올립니다. 그런데 이번 문제의 앞쪽에는 만들 거리가 아니라 사야 할 자원이 있었습니다. 원인을 잘못 짚으면 해결책도 엉뚱한 곳에 들어갑니다. 이 글에 실패한 가설을 지우지 않고 남긴 까닭이 여기 있습니다.

정리하면 원인은 둘이었습니다. 견적을 보낼 자원(캐시)이 없었고, 속도가 필요한 일을 플랫폼 밖에서 하려 했습니다. 첫째는 이벤트 결제로, 둘째는 숨고 스마트견적으로 풉니다. 어느 쪽도 새 코드를 쓸 필요가 없었습니다.

조치: 19,900원 결제, 견적 초안 5개, 켜기 전 승인 1줄

조치는 세 단계로 나눴습니다. 첫째, 이벤트 결제입니다. 결제는 되돌리기 어려운 돈의 지출이라 대표의 승인을 먼저 받았습니다. 2026년 10월 4일 승인이 났고, 같은 날 14시 28분 53초에 결제를 마쳤습니다. 마감인 10월 5일 14시경보다 하루 앞선 시점입니다.

둘째, 자동 지원 방식입니다. 저희 쪽 파이프라인은 만들지 않고 숨고 자체 스마트견적을 씁니다. 대신 스마트견적에 넣을 견적 초안 5개를 먼저 씁니다. 요청이 들어오면 숨고가 미리 써 둔 초안 가운데 하나를 보내는 구조라, 저희가 할 일은 코드가 아니라 초안의 문장과 금액을 다듬는 일로 바뀝니다.

셋째, 켜기 전 승인입니다. 자동 견적은 가격이 붙은 외부 메시지입니다. 한 번 나가면 고객의 화면에 저희 이름과 금액이 그대로 남습니다. 그래서 초안 5개를 쓴 뒤 대표가 승인 1줄을 남겨야 스마트견적을 켜도록 순서를 정했습니다. 자동화는 앞단에서 최대한 하고, 되돌릴 수 없는 송출만 사람의 한마디로 남기는 원칙입니다.

• 2026년 10월 4일: 대표 승인 → 14시 28분 53초 결제 완료
• 결제 직후: 고수 화면에서 잔액 500,000캐시 확인
• 다음 단계: 스마트견적 초안 5개 작성 → 대표 승인 1줄 → 스마트견적 켜기
• 환급 조건: 20일 안에 견적 30건 + 스마트견적 1회

승인을 결제와 켜기 두 곳에만 둔 이유도 적어 둡니다. 결제는 돈이 나가는 일이고, 켜기는 가격이 붙은 메시지가 나가는 일입니다. 둘 다 한 번 일어나면 되돌리기 어렵습니다. 반대로 초안 5개를 쓰고 고치는 일은 몇 번이든 다시 할 수 있으니 사람의 승인을 따로 받지 않습니다. 사람의 확인을 꼭 필요한 두 지점에 모아 두어야 나머지가 멈추지 않고 굴러갑니다.

재측정 결과: 보유 캐시 0에서 500,000캐시로

재측정은 결제 직후 바로 했습니다. 측정 방법은 처음과 같이 고수 화면의 잔액을 직접 확인하는 방식입니다. 결과는 500,000캐시였습니다. 처음 잰 숫자 0과 비교하면, 견적을 한 건도 못 보내던 상태에서 견적을 보낼 수 있는 상태로 바뀌었습니다.

이 재측정이 말해 주는 범위는 좁습니다. 견적을 보낼 수 있게 됐다는 사실까지만 확인했고, 그 견적이 몇 건 나가 몇 명이 답했는지는 아직 재지 않았습니다. 그래서 전후 비교는 캐시와 발송 가능 여부에 한정하고, 계약 쪽 숫자는 예측으로만 적습니다. 절대값을 감추지 않으려면 잰 것과 아직 안 잰 것을 같은 표에 섞지 않아야 합니다.

이것만으로 개선이 끝났다고 말하지는 않겠습니다. 캐시는 수단이고 목표는 계약입니다. 그래서 결제와 함께 결과를 미리 예측해 적어 두었습니다. 20일 동안 자동 견적 15~40건, 고객 응답 2~5건, 계약 0~1건입니다. 판정일은 이 글을 쓰는 2026년 10월 24일입니다.

예측을 먼저 적은 이유는 나중에 결과를 보고 '원래 그 정도일 줄 알았다'고 말하지 않기 위해서입니다. 이 기록에는 결과 숫자가 아직 없습니다. 예측과 실제가 어긋난 지점이 생기면, 그 차이가 다음 판단의 재료가 됩니다. 결과는 이 예측표 옆에 그대로 붙여 비교할 계획입니다.

남는 한계: 20일, 30건, 그리고 남의 기능 위에 선 자동화

첫 번째 한계는 시간입니다. 보너스캐시는 20일이 지나면 사라지고, 환급 조건인 견적 30건과 스마트견적 1회도 같은 20일 안에 채워야 합니다. 사전 예측의 하단인 15건에 머물면 환급 조건 30건에 못 미칩니다. 위험의 상한은 19,900원이지만, 그 상한도 조건을 채워야 0원으로 내려옵니다.

두 번째 한계는 통제권입니다. 숨고 스마트견적은 숨고의 기능이라 어떤 요청에 어떤 견적이 나갈지 정하는 기준을 저희가 끝까지 쥐지 못합니다. 자체 파이프라인을 버리면서 얻은 속도와 비용 이점의 대가입니다. 숨고가 기능을 바꾸거나 이벤트 조건을 바꾸면 저희 쪽 흐름도 함께 바뀝니다.

세 번째 한계는 가격의 책임입니다. 자동 견적은 가격이 붙은 외부 메시지라서, 초안 5개가 실제 요청과 어긋나면 맞지 않는 금액이 고객에게 그대로 나갑니다. 켜기 전 승인 1줄로 첫 관문은 막았지만, 켠 뒤에 나가는 견적 하나하나를 사람이 보지는 않습니다.

네 번째 한계는 예측의 근거입니다. 15~40건, 2~5건, 0~1건이라는 범위는 실측 표본에서 나온 숫자가 아니라 결제 시점에 적어 둔 사전 예측입니다. 이 범위가 맞는지는 판정일에 실제 숫자를 붙여 봐야 압니다.

다섯 번째 한계는 20일 이후입니다. 보너스캐시가 사라진 뒤 견적 한 건에 드는 캐시와 그 비용을 어떻게 감당할지는 이번 기록에 없습니다. 이벤트 덕분에 출발선은 넘었지만, 그 뒤로도 숨고 스마트견적을 계속 켜 둘 만한지는 판정일 숫자를 보고 따로 정해야 합니다.

판정일에는 네 가지를 확인합니다. 20일 동안 실제로 나간 자동 견적이 몇 건인지, 그 수가 환급 조건 30건에 닿았는지, 고객 응답이 몇 건이었는지, 계약이 있었는지입니다. 그리고 각 숫자를 사전 예측 15~40건, 2~5건, 0~1건과 나란히 놓습니다. 예측 범위를 벗어난 칸이 있다면, 그 칸이 다음에 숨고 스마트견적을 어떻게 쓸지 정하는 근거가 됩니다.

이 결정에서 무엇을 남겼나?

• 견적이 0건인 이유부터 잰다. 캐시가 0이면 자동화를 아무리 잘 만들어도 첫 견적에서 멈춘다
• 요청이 1시간 안에 사라지는 곳에서는 플랫폼 안의 가장 짧은 경로가 이긴다. 바깥을 돌아 들어가는 5칸은 칸마다 지연과 고장이 붙는다
• 만들 수 있는 회사일수록 '만들지 않기'를 먼저 검토한다. 이번 조치에서 새로 쓴 코드는 없다
• 위험의 상한을 숫자로 적는다. 19,900원 결제, 조건을 채우면 0원
• 가격이 붙은 자동 송출은 켜기 전에 사람의 승인 1줄을 남긴다
• 결과를 보기 전에 예측을 적는다. 20일 견적 15~40건 · 응답 2~5건 · 계약 0~1건

이 판단은 숨고에만 해당하는 이야기가 아닙니다. 요청에 유효 시간이 있고, 알림이 사람의 메신저로만 오고, 플랫폼이 자체 자동 발송 기능을 이미 갖추고 있다면, 바깥에 입찰 프로그램을 따로 세우기 전에 그 기능부터 열어 볼 만합니다. 직접 만드는 일은 플랫폼 기능으로는 안 되는 지점이 숫자로 드러난 다음에 해도 늦지 않습니다.

같은 회사가 다른 플랫폼에서 공고를 모으는 수집기를 고친 이야기는 RPA로 외주 공고 수집 자동화, 하루 2회를 2시간 간격으로에 있습니다. 중개 플랫폼 영업이나 반복 업무를 자동화할 때 무엇을 만들고 무엇을 만들지 않을지부터 정리하고 싶다면 상담으로 문의해 주세요.