무엇이 문제였나 — 이미 한 번 고친 숫자였다
SGK 스튜디오는 중소기업을 상대로 홈페이지 제작과 AI 챗봇 구축, 업무 자동화를 파는 작은 스튜디오다. 이 무렵 리걸테크 스타트업 고객사 한 곳과 계약을 준비하고 있었다. 이 고객사는 계약서를 자동으로 관리해 주는 AI 제품을 파는 곳이었고, 우리 쪽에 요청한 일은 이 제품에 가입할 만한 잠재 고객을 콜드메일로 찾아 주는 아웃바운드 영업 대행이었다. 이 AI 제품은 계약서를 업로드하면 상대방·금액·기한을 자동으로 추출하고, 마감일이 다가오면 미리 알려 주는 식이었다. 계약 관리를 전담하는 법무 인력이 없는 작은 회사가 주된 타깃이었다.
협의 중이던 조건은 이랬다. 예상 계약 규모는 월 100만원에서 150만원 사이, 최소 계약 기간은 3개월, 계약 시점에 선금 50%를 받는 구조였다. 이 고객사가 파는 제품은 첫 2개월이 무료였고 3개월차부터 100원짜리 프로모션 요금을 받았는데, 이 조건 덕분에 우리가 보내는 콜드메일을 클릭해 가입까지 이어지는 문턱이 낮다는 점이 이 딜의 강점이었다. 이 계약 하나가 차지하는 매출 비중도 작지 않았다 — 문서에는 이 딜이 그 시점 예상 매출의 15%에서 25%를 차지한다고 적혀 있었다.
제안서와 견적서에는 3개월 치 발송 계획을 담은 램프업 일정표가 함께 들어갔다. 1개월차부터 3개월차까지 매주 몇 건씩 콜드메일을 보낼지 적어 둔 표로, 고객사 입장에서는 이 표가 곧 '이 돈을 내면 무엇을 받는가'에 대한 가장 구체적인 근거였다. 발송량은 그 자체로 끝나는 숫자가 아니었다 — 이 숫자에서 예상 오픈율과 클릭률, 최종 회원가입 수까지 이어지는 퍼널 계산 전체가 걸려 있었다. 앞단의 숫자 하나가 흔들리면 뒤에 이어지는 계산도 같이 흔들린다.
그런데 이 문서는 이미 한 번 고친 이력이 있었다. 처음 계획은 월 200건에서 500건 사이였는데, 실제로 운영 가능한 규모를 다시 계산해 월 400건에서 1,000건 사이로 정정한 적이 있었다. 문서 앞부분의 요약 문단과 견적 금액은 그때 새 숫자로 다 바뀌었다.
금액 자체는 크지 않았지만 이 딜은 스튜디오의 첫 유료 아웃바운드 고객이 될 사례였다. 문서 안 시나리오 표에는 순조롭게 3개월을 채우는 경우가 확률 50%, 반대로 1개월차 목표 미달로 해지되는 경우가 확률 20%로 적혀 있었다. 해지 시나리오의 재무 영향은 -400만원, 순조로운 경우는 +450만원과 레퍼런스 1건이었다. 램프업 표 하나가 잘못돼 있으면, 이 확률과 재무 영향을 판단하는 기준 자체가 흔들린다. 이 딜이 잘 굴러가면 업계에서 쓸 수 있는 참고 사례 하나가 생기고, 잘못되면 그 반대 방향의 소문이 날 수 있다는 점도 문서 안에 적혀 있었다. 첫 유료 고객일수록 계산이 맞아떨어지는 문서 한 장의 무게가 커진다.
문제는 이 정정이 문서 구석구석까지 고르게 반영됐는지 아무도 확인하지 않았다는 데 있었다. 문서 하나에 같은 숫자가 몇 번이나 등장하는지, 그 숫자가 전부 같은 값을 가리키는지는 눈으로 훑어서는 확인하기 어렵다. 그래서 대표는 같은 문제가 다른 곳에도 남아 있는지 검증해 보라고 요청했고, 이 검증에는 서로 다른 관점 하나씩만 맡은 AI 에이전트 네 개를 병렬로 투입했다.
처음 잰 숫자 — 네 개 관점이 각자 다른 곳을 봤다
- 수치·수학 — 표와 문단에 적힌 숫자가 서로 맞는지, 계산이 맞는지만 본다
- 이행 가능성·인프라 — 문서에 적힌 약속을 실제 코드와 도구로 지킬 수 있는지만 본다
- 문서 간 정합성 — 한 문서 안에서 앞뒤 서술이 서로 어긋나지 않는지만 본다
- 법무·톤 — 문장이 법적으로 과장·보장처럼 읽히지 않는지만 본다
관점을 넷으로 나눈 기준은 이 문서가 실패할 수 있는 방식 네 가지에서 나왔다. 숫자가 틀리면 계산이 깨지고, 인프라가 안 되면 약속을 못 지키고, 문서끼리 어긋나면 신뢰가 깨지고, 표현이 과하면 법적 책임이 생긴다. 관점 하나가 나머지 세 개를 대신할 수 없었다.
네 개 에이전트는 관점을 하나씩만 맡아 같은 문서를 처음부터 끝까지 다시 읽었다. 검토 지침에는 자신이 맡은 관점 하나만 적어 뒀고, 다른 관점에서 이미 확인됐을 내용은 신경 쓰지 않아도 되니 같은 시간 안에 훨씬 좁고 깊게 볼 수 있었다. 실제로 이 방식이 아니었다면 이번 발견 중 상당수는 놓쳤을 가능성이 크다.
수치·수학 관점을 맡은 에이전트가 3개월 램프업 일정표를 짚었다. 표에는 2개월차 발송량이 여전히 주 100건에서 150건으로 적혀 있었다. 이 숫자 그대로 한 달을 계산하면 월 최대 645건이었다.
문제는 같은 문서 다른 곳에서는 이미 정정된 목표, 즉 월 800건에서 1,000건을 달성하겠다고 적혀 있었다는 점이다. 645건짜리 표로는 그 목표에 이르는 경로가 문서 안 어디에도 없었다.
이때까지 네 개 관점이 찾아낸 문제는 이 한 건이 아니었다. 문서 간 정합성 관점을 맡은 에이전트는 제안서 2쪽과 4쪽이 업종 필터를 두고 서로 반대로 말한다는 사실을 찾았고, 다른 하나는 이미 승인된 보고서를 만드는 스크립트 안에 예전에 기각된 결정이 그대로 남아 있다는 사실을 찾았다. 짧게 세면 네 건이었고, 네 건 모두 서로 다른 자리에서 나와 겹치는 발견이 하나도 없었다.
세운 가설 — 한 곳만 고치면 끝나는 게 맞을까
발송량 숫자를 처음 고쳤을 때 세운 가정은 단순했다. 문서 맨 앞 요약 문단과 견적 금액이 이미 새 숫자로 바뀌어 있었으니, 그 값 하나만 기준으로 삼아 고치면 나머지는 저절로 맞아떨어질 거라고 봤다.
이 가정이 그럴듯해 보인 이유가 있다. 실제로 문서 앞부분은 정확히 새 숫자로 바뀌어 있었다. 눈에 보이는 자리를 고쳤고 결과도 눈에 보였으니, 그 한 군데가 이 문서 전체를 대표하는 값이라고 믿기 쉬웠다. 확인 절차 없이 결과만 눈으로 보고 넘어가면, '고친 자리가 맞다'와 '문서 전체가 맞다'를 동일하게 여기기 쉽다.
게다가 발송량을 고치는 작업 자체가 별도로 시간을 들여야 하는 일이었다. 이미 한 번 처리한 일을 다시 여는 일보다는, 다음 문서로 넘어가는 편이 더 급해 보였다.
그래서 재검토를 요청받았을 때도 처음엔 큰 기대를 하지 않았다. 이미 맞게 고쳤다고 생각한 문서를, 그것도 서로 다른 관점 네 개로 다시 훑는 일은 확인 절차라기보다 형식적인 이중 점검처럼 보일 수도 있었다. 대표가 이 재검토를 굳이 요청한 이유는 따로 있었다. 직전 정정은 눈에 띈 오류를 고치는 작업이었지, 오류가 더 없다고 확인하는 작업은 아니었기 때문이다. 이 둘은 결과물이 비슷해 보여도 신뢰할 수 있는 정도가 다르다.
가설이 틀린 지점 — 표는 왜 그대로 남아 있었나
네 개 관점 중 수치·수학 쪽이 짚어 낸 자리는 정확히 램프업 일정표였다. 이 표는 요약 문단과 다른 문단에 따로 적혀 있었고, 요약 문단의 숫자를 고칠 때 이 표까지 같이 훑지 않았다.
더 나쁜 사실은 이번이 처음이 아니었다는 점이다. 발송량을 처음 정정하던 그 작업에서도 같은 표가 빠져 있었다. 같은 성격의 실수가 한 번 고쳐지지 않은 채 두 번째 검토까지 그대로 남아 있었던 셈이다.
요약 문단은 검토할 때 가장 먼저 눈에 들어오는 자리였고, 램프업 표는 뒤쪽 부록에 가까운 위치에 있었다. 눈에 잘 띄는 자리를 고치고 나면, 상대적으로 덜 보이는 자리는 그대로 지나치기 쉽다.
2개월차 '주 100~150건'으로는 월 최대 645건뿐, 정정된 목표(월 800~1,000건) 도달 경로가 문서 안에 없었음.
이 표현을 그대로 인용한 이유가 있다. 이 문장은 '숫자가 틀렸다'가 아니라 '이 문서만 봐서는 목표에 도달할 방법이 안 보인다'는 관찰이었다. 문서를 읽는 고객사 담당자 입장에서 보면 결과는 같다 — 계산이 맞아떨어지지 않는 계획서를 그대로 받는다.
가정이 틀린 지점은 명확했다. '앞부분 요약 문단 하나만 고치면 문서 전체가 맞아떨어진다'는 가정은, 이 문서 안에 같은 목표 숫자가 최소 두 군데(요약 문단과 램프업 표)에 따로 적혀 있다는 사실과 정면으로 부딪혔다.
진짜 원인 — 숫자가 사는 집이 두 곳이었다
이 제안서는 코드가 아니라 사람이 문단과 표를 따로 써 내려가는 문서다. 목표 발송량이라는 값 하나가 요약 문단에도 적히고, 3개월 램프업 표에도 따로 적힌다. 코드라면 값을 한 곳에서 정의하고 나머지는 그 값을 가져다 쓰게 만들 수 있지만, 문서는 값이 쓰이는 자리마다 숫자를 손으로 다시 적어야 한다.
코드라면 이 값을 상수 하나로 선언하고 나머지 코드가 그 상수를 참조하게 만든다. 상수를 한 번 고치면 그 값을 쓰는 모든 자리가 자동으로 같이 바뀐다. 문서에는 이런 참조 구조가 없으니, 값이 여러 번 나오는 문서일수록 사람이나 에이전트가 그 자리를 전부 손으로 찾아야 한다.
그래서 값을 고치는 작업은 '이 숫자가 문서 안에 몇 군데 적혀 있는지'를 먼저 확인하는 일부터 시작해야 하는데, 처음 정정 작업에는 그 확인이 없었다. 눈에 띄는 숫자 하나를 고치고 나니 일이 끝난 듯 보였을 뿐이다.
이 문제는 AI가 초안을 쓴 문서일수록 더 자주 일어난다. 사람이 쓸 때는 숫자를 고치면서 문서를 처음부터 끝까지 다시 읽는 경우가 많지만, AI에게 '이 문단만 고쳐 줘'라고 좁게 지시하면 그 문단 밖의 같은 값은 그대로 남는다. 좁게 지시할수록 빠르지만, 그만큼 문서 전체를 보는 눈은 줄어든다. 이 문제는 콜드메일 제안서에만 있지 않다. 환경변수를 여러 파일에 나눠 적어 두거나, 같은 상수를 코드 두 곳에 따로 선언해 둔 경우에도 똑같은 일이 일어난다. 한쪽만 고치고 나머지는 그대로 둔 채 넘어가면, 그 값이 다시 필요해지는 순간까지는 아무도 눈치채지 못한다.
같은 문서에서 발견된 나머지 세 건도 성격이 비슷했다. 제안서 2쪽 표와 4쪽 서술이 업종 필터를 두고 정반대로 말하고 있었던 사실도, 이미 승인된 계약 검토 보고서를 만드는 스크립트 안에 기각된 결정과 예전 발송량·예전 오픈율이 그대로 남아 있었던 사실도, 결국 같은 값이 여러 자리에 따로 적혀 있는데 그중 한 자리만 고쳤기 때문에 생긴 문제였다. 이런 값 불일치를 다룬 다른 사례는 AI 에이전트 확인 없이 답변, 같은 값을 물을 때마다 달랐다에도 남겨 뒀다.
법무·톤 관점에서 나온 세 건은 결이 조금 달랐다. '책임집니다'라는 표현이 목표 수치 바로 옆에 붙어 마치 성과를 보장하는 듯 읽혔고, 워밍업 보상 조항은 '계약 종료일 무상 연장'이라고만 적혀 있어 그 계산을 시작하는 날짜가 빠져 있었다. 값이 여러 곳에 흩어져 생긴 문제가 아니라, 문장 하나가 실제 의미보다 강하게 읽히는 문제였다. 관점을 넷으로 나눈 이유가 여기 있다 — 값 불일치와 표현 강도는 서로 다른 종류의 실수라서, 한 사람이 한 번에 다 잡으려 하면 둘 다 놓치기 쉽다.
조치 — 무엇을 어떻게 바꿨나
네 건의 발견에 맞춰 네 가지를 고쳤다. 가장 먼저 손댄 것은 램프업 표였다. 2개월차는 주 150건에서 180건으로, 3개월차는 주 180건에서 200건으로 다시 계산했고, 이번에는 표 옆에 '월 800건에서 1,000건'이라는 목표 숫자를 직접 적어 두 값이 서로 어긋나지 않게 했다.
두 번째는 문서 간 정합성 문제였다. 2쪽과 4쪽이 부딪힌 이유는 명확했다 — 고객사 스스로도 'ICP는 이후 단계에서 함께 구체화하겠다'고 답한 상태였는데, 문서는 이미 확정된 듯 적혀 있었다. 제안서 2쪽 표의 제목을 '초기 가설(참고 — 온보딩 단계에서 고객과 함께 확정)'로 바꾸고, 표 항목도 확정 필터가 아니라 우선순위 신호로 다시 정의했다. 표현을 가설로 낮추자 고객사의 실제 입장과도 맞아떨어졌고, 4쪽의 서술과 부딪히던 확정 표현을 아예 없앴다.
세 번째는 이미 승인된 계약 검토 보고서를 만드는 스크립트였다. 스크립트 안에는 대표가 이미 기각한 결정과 예전 발송량, 예전 오픈율이 그대로 남아 있어서, 이 스크립트를 다시 돌리면 기각된 안이 되살아날 위험이 있었다. 스크립트만 고치고, 이미 고정하기로 확정한 문서 파일 자체는 다시 굽지 않았다 — 한 번 확정한 산출물을 존중하는 쪽을 택했다.
네 가지를 고친 직후에는 이 네 군데만 눈으로 다시 확인했다. 문서 전체를 다시 보는 절차는 다음 단계로 미뤄 뒀다. 고친 자리 네 곳만 다시 보는 방식과, 문서 전체를 다시 훑는 방식은 서로 다른 확인이다. 앞의 확인은 '고친 부분이 맞는가'만 답하고, 뒤의 확인이라야 '이 문서에 아직 남은 문제가 있는가'에 답할 수 있다.
네 번째는 법무·톤 표현 세 곳이었다. '책임집니다'는 '집중합니다'로 완화했고, 워밍업 보상 조항에는 '선금 입금일 기준'이라는 기산일을 추가했고, 근거 없는 성과 주장으로 읽힐 수 있는 표현도 사실 진술로 바꿨다.
그림에서 굵게 표시한 첫 번째 항목이 이 글의 중심이다. 목표를 두 표에 나눠 적는 구조 자체를 없애지는 못했지만, 최소한 지금 이 문서 안에서는 두 표가 같은 숫자를 가리키게 맞췄다.
재측정 결과 — 나머지는 깨끗했다
네 가지를 고친 뒤, 같은 네 개 관점으로 문서를 다시 훑었다. 이번에는 새로 걸리는 문제가 없었고, 오히려 문제없다고 확인된 항목이 나왔다.
- 셋업비를 없앤 뒤에도 계산식에 그 흔적이 남아 있지 않았다
- 고객에게 나가는 문서에 대표 개인 이름이 그대로 적힌 곳이 0건이었다
- 오픈율·클릭률·최종 전환율 같은 퍼센트 기반 계산이 정확했다
- 워밍업 일정과 보상 조항 사이에 같은 비용을 두 번 계산한 흔적이 없었다
- 동시에 진행할 수 있는 고객사 한도 3개 중 이번 건 하나뿐이라 33%만 쓰고 있었고, 활성 고객은 0곳이었다
네 번째 항목은 워밍업 스케줄과 보상 조항을 나란히 놓고 본 결과다. '계약 종료일 무상 연장'이라는 혜택이 실제 계약 기간 계산과 겹쳐 이중으로 늘어나는 구조는 아닌지도 이번에 같이 확인했다.
문제없음으로 확인된 다섯 항목 각각은 이전 검토에서도 이미 손댄 적 없는 자리였다. 즉 이번 재검토가 새 오류를 만들어 내지도 않았다. 고친 자리를 건드리다 다른 자리를 깨뜨리는 일은 코드 수정에서도, 문서 수정에서도 똑같이 일어날 수 있는 실수다.
재측정의 측정 방법은 처음과 같았다 — 서로 다른 관점을 가진 네 개 에이전트가 같은 문서를 처음부터 끝까지 다시 읽는 방식이다. 다만 이번에는 고친 자리만 확인하지 않고 문서 전체를 다시 대상으로 삼았다. 고친 자리만 봤다면 두 번째로 놓친 부분이 있어도 몰랐을 가능성이 크다. 관점을 넷으로 유지한 이유도 여기 있다 — 관점을 하나로 합쳤다면 검토 시간은 줄었겠지만, 서로 겹치지 않는 네 자리에서 각각 문제를 찾아내는 정밀도는 낮아졌으리라고 본다.
남는 한계 — 사람 손이 여전히 필요한 곳
이번 검토는 문서 안의 숫자 불일치를 잡는 데는 효과가 있었지만, 문서 밖에서 실제로 벌어질 일까지 검증하지는 못했다. 이번에 확인한 범위는 어디까지나 지금 이 문서 한 건이다. 다음 고객사를 위한 문서를 새로 쓸 때 같은 절차 없이 넘어가면, 오늘 고친 값이 다른 문서에서 예전 숫자로 다시 등장할 수 있다.
실제 발송·응대 과정에는 아직 코드가 없는 영역이 세 곳 있었다. 회원가입 자격을 검증하는 절차, 발신 도메인을 인증하는 절차, 고객사별 주간 리포트를 만드는 절차다. 문서에 적힌 예상 규모는 월 24건에서 30건 정도라 지금은 사람이 손으로 처리할 수 있는 수준이지만, 이건 임시 대응이지 완성된 시스템이 아니다.
이 딜의 실제 운영 부담은 첫 달 25시간에서 35시간, 안정화된 뒤로는 15시간에서 25시간 정도로 예상됐고, 시간당 단가는 약 6만원에서 10만원 사이였다. 사람이 붙어야 하는 세 영역이 이 운영시간 대부분을 차지한다.
고객에게 나가는 문구는 자동화를 내세우지 않았기 때문에 표시 자체에 문제는 없었지만, 첫 3개월은 실제로 사람 손 의존도가 높다는 사실은 별도로 남겨 뒀다. 발송 규모가 지금의 24건에서 30건 수준을 크게 넘으면 이 대응은 다시 손봐야 한다. 코드가 없다는 사실을 감춘 적은 없다 — 지금 규모에서는 사람이 맡는 편이 더 확실하다고 판단해 남겨 뒀다는 점도 문서에 그대로 적어 뒀다.
값 하나가 문서 여러 곳에 따로 사는 구조 자체도 남는 문제다. 이번엔 네 개 관점으로 훑어서 잡았지만, 다음에 또 숫자를 고칠 때 똑같은 일이 반복되지 않으리라는 보장은 없다. 고객사가 여러 곳으로 늘어나면 문서마다 같은 방식으로 값이 흩어질 위험도 함께 늘어난다. 지금은 매번 네 관점을 병렬로 돌리는 방식으로 버티고 있지만, 문서 수가 늘면 이 방식도 손을 봐야 한다. 다음 문서부터는 목표 숫자가 나오는 자리를 미리 표시해 두고, 숫자를 고칠 때마다 그 표시를 전부 확인하는 절차를 시도해 볼 계획이다 — 아직 시험해 보지 않은 방법이라 이 글에 성과로 적지는 않는다. 비슷한 교차검증 체계가 필요한 문서 작업이 있으면 상담에서 물어봐도 된다.