AI업무자동화 견적서는 왜 52바퀴나 고쳐졌나?
AI업무자동화로 견적서를 만들면 사람 손이 줄어들 거라고 기대했습니다. 실제로는 반대였습니다. 2026년 10월 4일부터 7일까지 나흘 동안 정식 제안서·견적서를 보낸 고객은 3건이었고, 이 3건에서 “AI가 완성했다고 보고 → 대표가 지적 → AI가 수정”하는 왕복이 모두 52바퀴였습니다.
고객별로 나누면 편차가 컸습니다. 웹 개발 문의 고객 A 한 건이 35바퀴였고, 웹 개발 문의 고객 B가 6바퀴, AI 개발 문의 고객 C가 11바퀴였습니다. 한 건에 35번 손이 가면 자동화라고 부르기 어렵습니다. 대표가 검토에 쓰는 시간이 직접 쓰는 시간과 비슷해지기 때문입니다.
비용은 대표의 시간만이 아니었습니다. 숨고에서 견적을 보낸 문의는 17건이었는데, 끝까지 고용으로 이어진 건은 0건이었습니다. 수정이 길어지는 동안 답장을 기다리던 고객도 함께 식었을 가능성이 있습니다(추정: 고객이 답을 멈춘 이유는 직접 확인하지 않았습니다).
퍼널은 숨고 API를 읽기 전용으로 전수 조회해 2026년 10월 7일 밤에 셌습니다. 각 단계는 독립으로 집계했습니다. 17건이 열람 12건, 맞춤 제안 11건, 읽음 9건, 답장 5건, 정식 견적 3건으로 줄었고 고용은 0건이었습니다. 이 글에서 다루는 52바퀴는 마지막 정식 견적 3건 안에서 일어난 일입니다.
처음 잰 숫자: 지적 83개를 원문으로 다시 읽었다
감으로는 “AI가 아직 서툴다” 정도로 정리하고 넘어갈 수 있었습니다. 대신 지적을 하나씩 세기로 했습니다. 기준은 단순하게 잡았습니다. AI가 “완료, 발송 가능”이라고 낸 뒤 대표가 지적해 고친 항목 하나를 누수 1건으로 셉니다.
원자료는 요약이 아니라 작업 대화 기록에 남은 대표 발화 원문입니다. 출처 칸에 대화 식별자와 시각을 붙였고, 판독은 고객별로 끊어서 했습니다. 고객 3건 밖에서 짧게 오간 다른 문의와 공통 지적까지 합치니 누수는 모두 83개였습니다.
83개를 다시 종류별로 나눴습니다. 형식 18개, 절차 14개, 돈 13개, 범위 13개, 말투 10개, 월 비용 6개, 계정 3개, 권리 2개, 약관 2개, 사실 2개였습니다. 한쪽으로 몰리지 않았다는 점이 먼저 눈에 들어왔습니다. 문서 모양부터 금액, 말투, 플랫폼 약관까지 고르게 새고 있었습니다.
판독할 때 지적마다 “그 시점에 규칙이 있었나”도 표시했습니다. 표시는 세 가지입니다. 지적보다 먼저 규칙이 어딘가에 적혀 있었으면 “사전 존재”, 지적을 받고 나서야 적었으면 “지적 뒤 등재”, 어디에도 없었으면 “없음”입니다. 근거가 되는 문서 위치를 칸마다 적어서, 빈칸은 하나도 남기지 않았습니다. 이 표시가 다음 절에서 가설을 뒤집는 숫자를 만들었습니다.
종류마다 “기계가 판정할 수 있나”도 함께 적었습니다. 정규식이나 간단한 규칙으로 잡을 수 있는 지적이 60개, 사람이 문맥을 읽어야 판단할 수 있는 지적이 23개였습니다. 이 구분이 뒤의 조치에서 검사기와 생성 프롬프트로 일을 나누는 기준이 됐습니다.
- 형식 예: 포함·미포함·결제 조건이 전부 글머리표라 읽기 어렵다, 들여쓰기로 나눠 달라
- 돈 예: 부가세 별도를 반드시 적어라, 결제 조건을 범위로 주지 말고 계약금 비율을 하나로 정해라
- 말투 예: “입니다” 대신 “드리겠습니다” 투로, “님이”를 “님께서”로
- 약관 예: 숨고 채팅에 홈페이지 링크를 넣으면 약관 위반이다
세운 가설: 규칙이 모자라서 지적이 나온다
숫자를 보기 전까지 저희가 기대고 있던 가설은 단순했습니다. 지적이 나오는 이유는 아직 그 규칙이 없어서이고, 지적이 하나 나올 때마다 규칙을 하나 적어 두면 다음 견적부터는 같은 지적이 줄어든다고 봤습니다.
나흘 동안 실제로 그렇게 일했습니다. 지적이 나오면 견적 점검표 문서에 항목을 하나 더하고, AI 에이전트의 메모리 파일에 피드백을 한 줄 남기고, 중요한 건은 결정 기록에도 적었습니다. 복기 표의 “기존 규칙” 칸에 “지적 뒤 등재” 표시가 줄줄이 붙어 있는 이유가 이것입니다.
다음 견적부터 반영할 수 있도록 해줘.
이 말에 저희는 규칙을 하나 더 적는 것으로 답해 왔습니다. 그래서 다음 개선안도 처음에는 같은 방향이었습니다. 점검표 문장을 더 촘촘하게 보강하고, 빠진 항목을 채우는 안입니다.
가설은 어디서 틀렸나?
83개를 “지적 시점에 이미 규칙이 있었나”로 다시 나누자 가설이 무너졌습니다. 83개 중 21개(25%)는 지적이 나오기 전에 규칙이 이미 어딘가에 적혀 있었습니다. 규칙이 없어서 샌 게 아니라, 있는 규칙을 어기고 샌 것입니다.
고객 B는 더 두드러졌습니다. 누수 12개 중 8개가 이미 있던 규칙을 다시 지적한 경우였습니다. 고객 B 견적을 만들 무렵에는 고객 A와 C를 거치며 규칙이 꽤 쌓여 있었는데, 그 규칙이 고객 B 견적에 거의 반영되지 않았습니다.
가장 선명한 사례는 링크였습니다. 숨고 이용약관 제12조는 채팅 안에 개인 홈페이지·SNS 주소 같은 외부 연락 수단을 노출해 우회 거래를 유도하는 행위를 금지합니다. 저희는 2026년 10월 4일 저녁에 이 조항 원문을 확인했고, 그 자리에서 링크 금지 규칙을 학습 기록과 메모리에 적었습니다.
비정상적으로 시스템 설계상 제한을 회피하여 이익을 취하는 행위 (예시. 커뮤니티나 프로필 내 개인 휴대폰 번호, SNS/홈페이지 주소를 게시하여 우회 거래를 유도하는 행위 등)
그런데 이틀 뒤인 10월 6일, 다른 작업 세션이 “데모 링크는 숨고 채팅에 넣어 보낸다”고 결정했습니다. 링크 없이 스크린샷만 보내면 고객이 눌러 볼 수 없다는 이유였습니다. 그날 오전부터 낮까지 채팅방 5곳에 시안 링크가 나갔습니다. 10월 7일 오전에는 또 다른 고객의 초안에 링크가 다시 들어갔고, 대표가 다른 세션에서 나온 결론을 직접 전달하고 나서야 멈췄습니다.
링크만의 일이 아니었습니다. 고객 C의 제안서에서 대표는 “엽니다” 같은 표현이 한국인이 쓰지 않는 기계 번역체라고 지적했는데, 어색한 번역투를 피하라는 피드백은 같은 날 오전에 이미 메모리에 적혀 있었습니다. 고객 C 견적에 “화면을 같이 보며 약 30분” 같은 화상 미팅 안내가 들어간 것도 같습니다. 실시간 미팅·통화를 권하는 문구는 2026년 7월 20일에 이미 기각해 기각 문서에 남겨 둔 안이었습니다.
'엽니다' 이런 표현은 한국인은 안쓰는 어색한 표현이야. 기계 번역체 검수를 왜 안한거지?
고객 B에서는 결제 조건이 문제였습니다. 계약금 20%는 다른 고객의 요청을 받아들인 예외였고 기본은 선금 50%라는 결정이 이미 있었는데, 고객 B 견적은 예외를 기본처럼 가져다 썼습니다. 제안서 양식도 앞선 고객들에게 쓰던 표준 덱이 아니라 새 양식으로 나갔습니다. 어느 쪽이든 규칙을 새로 만들 일이 아니라, 있는 규칙을 생성 순간에 꺼내 오기만 하면 막을 수 있던 지적이었습니다.
규칙은 10월 4일부터 있었습니다. 다만 10월 6일에 견적을 만든 세션은 그 규칙을 읽지 않은 채 반대 결정을 내렸습니다. 점검표에 문장을 하나 더 적는 방식은 정확히 이 지점에서 샜습니다. 그래서 “체크리스트 문장 보강” 안은 기각했습니다. 21개가 바로 그 방식에서 나온 누수였기 때문입니다.
진짜 원인은 무엇이었나?
규칙은 여러 군데에 흩어져 있었습니다. 견적 점검표 문서, AI 에이전트의 메모리 파일들, 결정 기록, 기각한 안을 모은 문서, 분야별 판단 카드까지, 같은 종류의 규칙이 다섯 곳에 나뉘어 있었습니다. 견적을 만드는 순간 AI가 이 전부를 열어 읽는다는 보장이 없었습니다.
그러니 규칙을 더 쓰는 일은 문제를 키울 뿐이었습니다. 규칙이 늘어날수록 흩어진 장소가 늘고, 만들 때 빠뜨릴 확률도 함께 오릅니다. 복기 문서에 적은 원인은 한 줄이었습니다. 규칙이 없어서가 아니라 만들 때 규칙이 읽히지 않았다.
흩어진 규칙에는 또 하나의 위험이 있었습니다. 서로 모순되는 규칙이 동시에 살아 있을 수 있다는 점입니다. 링크 사례에서 10월 4일의 “채팅에 링크 금지”와 10월 6일의 “데모 링크는 채팅에 넣는다”는 서로 다른 문서에 함께 있었습니다. 어느 문서를 먼저 연 세션이냐에 따라 결과가 갈렸습니다. 규칙이 한 파일에 모여 있었다면 두 번째 결정을 적는 순간 첫 번째와 부딪힌다는 사실이 바로 보였을 것입니다(추정: 실제로 한 파일에 둔 상태에서 모순을 잡아낸 사례는 아직 없습니다).
원인을 이렇게 다시 쓰자 고칠 방향도 바뀌었습니다. 규칙을 더 쓰는 게 아니라 규칙이 생성 순간에 반드시 들어가도록 길을 하나로 묶고, 사람이 다시 볼 필요가 없는 규칙은 기계가 대신 막게 해야 했습니다. 비슷한 문제를 AI 에이전트 메모리 쪽에서 겪은 기록은 AI 에이전트 메모리의 빈칸, 기각한 제안이 세션마다 돌아왔다에 따로 정리했습니다.
조치: 규칙 34개를 한 파일에 모으고 15개는 검사기로 막았다
조치는 다섯 갈래였습니다. 모두 “사람이 기억해야 지켜지는 규칙”을 줄이는 쪽입니다.
- 규칙 정본 하나: 흩어진 규칙을 설정 파일 하나에 34개(P01~P34)로 모았습니다. 규칙마다 처음 나온 대화와 시각을 출처로 붙였고, 생성 프롬프트에는 34개를 고르지 않고 전부 넣습니다.
- 기계 검사 15개: 기계가 판정할 수 있는 규칙 15개는 검사 스크립트가 막습니다. 링크·연락처 금지는 발송 직전 검사기가 쓰는 금지 패턴 목록을 그대로 다시 씁니다.
- 요구는 고객 원문 인용: 생성기는 고객 요구를 고객이 쓴 문장 그대로 인용해 뽑습니다. 견적 범위의 줄마다 근거가 된 요구 번호를 답니다.
- 근거 없는 금액 차단: 근거 요구가 없는 범위 줄, 근거 없는 금액은 생성 단계에서 막고 대표 판단으로 넘깁니다. 가격은 사업 결정이라 AI가 혼자 정하지 않습니다.
- 선제 질문지: 서비스 종류별 질문지를 첫 메시지에 붙여, 견적을 확정하는 데 필요한 정보를 처음부터 묻습니다.
선제 질문지는 10월 4일의 한 문의에서 나왔습니다. 고객이 요청서의 자유 입력 칸에 이미 조건을 적어 두었는데, 그 칸을 읽지 않고 플랫폼 자동 견적을 먼저 보냈습니다. 숨고 자동 견적은 보낼 때마다 캐시가 차감되므로, 미리 읽었다면 보내지 않았을 견적에 돈을 쓴 셈이었습니다. 대표는 처음 견적을 보낼 때부터 상세 질문을 함께 보냈어야 했다고 지적했습니다. 지금은 웹 개발·챗봇·AI 개발 같은 서비스마다 질문 목록을 설정 파일에 두고, 첫 메시지가 그 목록을 꺼내 씁니다. 지금 쓰는 홈페이지에 매달 얼마가 나가는지 같은 질문이 여기 들어 있습니다. 월 비용 지적 6개 가운데 하나가 “고객이 지금 쓰는 홈페이지 운영비를 묻지도, 설명하지도 않았다”는 지적이었기 때문입니다.
링크 사건에서 배운 점은 금지 목록도 한 곳에 둬야 한다는 사실이었습니다. 이제는 발송 직전 검사기의 금지 패턴이 채팅 본문과 첨부 사진의 글자 인식(OCR) 결과를 막고, 견적 검사기의 플랫폼 규칙도 같은 목록을 읽습니다. 채팅에는 대표 사진 1장과 시안 책자 PDF만 보내고, 링크는 고객이 먼저 연락처를 준 경우 메일로만 보냅니다. 실제로 한 고객 건은 링크 없는 본문 748자, 사진 1장, 10쪽 PDF로 다시 준비해 보냈습니다.
검사기 자체도 시험했습니다. 누수 사례를 변형한 25종을 넣어 25종 전부를 잡는지 확인했고, 생성기는 분기 8가지를 시험했습니다. 견적 범위를 AI가 마음대로 키우지 않게 하는 기준은 홈페이지 제작 견적서, AI 검토가 붙인 기능을 걷어낸 기준에 따로 썼습니다.
재현 평가는 어떻게 쟀고 결과는 어땠나?
원래 계획은 운영에 먼저 올리고, 새로 들어오는 실제 리드에서 누수를 검수하는 순서였습니다. 그런데 고객 3건의 최종본이 이미 정답지 노릇을 할 수 있었습니다. 대표가 52바퀴를 돌며 고친 결과가 최종본에 남아 있기 때문입니다. 그래서 순서를 바꿔, 실제 리드를 기다리지 않고 지난 3건으로 먼저 재기로 했습니다.
재현 평가는 이렇게 돌립니다. 3건 당시 고객이 보낸 입력을 그대로 넣어 새로 생성하고, 결과물을 지적 83개와 하나씩 대조해 “대표가 다시 지적할 수준”의 지적이 몇 개 남았는지 셉니다. 판정은 LLM이 하고, 판정마다 초안 원문의 해당 문장을 인용하도록 강제했습니다. 인용 없는 판정은 세지 않습니다. 통과 기준은 2회 연속 0건이었습니다.
1회차는 생성물보다 검사기 쪽 문제가 먼저 드러났습니다. 검사기가 멀쩡한 문장을 위반으로 잡는 오탐이 3종 나왔습니다. 2회차에서 남은 지적은 6건, 3회차는 5건이었습니다. 3회차에서는 3건 모두 생성, 기계 검사, 첨부 글자 인식까지 통과했습니다. 기준선 83개에 비하면 크게 줄었지만, 목표한 “2회 연속 0건”에는 닿지 못했습니다.
판정에 원문 인용을 강제한 이유는 판정하는 LLM도 틀리기 때문입니다. “부가세 별도 표기가 빠졌다”고 판정하려면 초안의 해당 줄을 그대로 옮겨 와야 하고, 옮겨 올 문장이 없으면 그 판정은 버립니다. 이렇게 해야 사람이 결과를 다시 볼 때 판정 하나하나를 초안과 바로 대조할 수 있습니다.
그래서 자동 초안 발송 스위치는 꺼 둔 채로 두었습니다. 같은 시도를 계속 반복해 숫자를 0에 맞추는 대신, 개선 반복을 3회에서 멈추고 대표의 판단을 기다리는 쪽을 골랐습니다. 0건이 나올 때까지 규칙을 덧대면 결국 처음에 기각한 “문장 보강” 방식으로 돌아가기 때문입니다.
부수 발견도 하나 있었습니다. 숨고 채팅 메시지를 가져오는 수집 함수가 다음 페이지를 `?cursor=` 파라미터로 요청하고 있었는데, 이 방식으로는 최신 20건만 계속 되풀이해 받아 왔습니다. 고객 A 채팅은 메시지 27건 중 7건이 빠져 있었습니다. 파라미터를 `?next=`로 고쳐 페이지가 넘어가게 했고, 시험을 따로 하나 붙였습니다. 고객이 쓴 문장을 놓치면 “고객 원문 인용” 원칙도 무너지므로, 이 수리가 재현 평가보다 먼저 필요했습니다.
남는 한계는 무엇인가?
첫째, 생성이 느립니다. Claude Opus 모델로 1건을 만드는 데 약 6분이 걸립니다. 사람이 수십 바퀴를 고치던 때보다는 짧지만, 문의가 몰리면 줄을 섭니다(추정: 실제 대기 시간은 아직 재지 않았습니다).
둘째, 자동화 범위가 “텍스트 제안서 + 견적서”에 그칩니다. 디자인 시안을 만들고 고객이 참고로 준 사이트를 역설계하는 일(규칙 P22·P23)은 여전히 사람이 함께 보는 작업 세션의 몫입니다. 디자인은 취향의 영역이라 대표가 눈으로 먼저 봐야 한다는 원칙도 그대로입니다.
셋째, 평가의 천장이 낮습니다. LLM 판정은 “대표가 다시 지적할 수준인가”만 셉니다. 지적이 0건이라고 해서 견적이 좋다는 뜻은 아닙니다. 지적받지 않을 만큼 무난하다는 뜻일 뿐입니다. 품질의 상한은 이 평가로 보장하지 못합니다.
넷째, 퍼널의 끝은 그대로입니다. 견적 17건 중 고용은 아직 0건이고, 이번 작업은 고용률이 아니라 수정 왕복을 줄이는 일이었습니다. 수정이 줄어든 효과가 고용으로 이어지는지는 다음 문의들에서 따로 재야 합니다.
정리하면, 지적이 반복될 때 규칙을 하나 더 적는 습관은 25%의 누수를 남겼고, 규칙을 생성 단계 한 곳으로 모으자 지적은 83개에서 5건까지 줄었습니다. 견적·제안서 작성을 자동화하려는 회사라면 규칙이 몇 개인지보다 만드는 순간 그 규칙이 실제로 읽히는지를 먼저 확인해 보시길 권합니다. 비슷한 자동화를 검토 중이라면 상담으로 문의해 주세요.
글쓴이: SGK Studio 개발팀. 이 글의 숫자는 2026년 10월 8일 복기 문서와 같은 시기 결정 기록에서 가져왔습니다.