무엇이 문제였나 — 문의마다 다시 조사하고, 답이 매번 조금씩 달랐다
SGK 스튜디오는 홈페이지 제작과 AI 챗봇 구축, 블로그 운영 대행을 맡아 처리하는 서비스 업체입니다. 카카오톡 채널을 활용한 상담봇·접수봇 문의는 반복해서 들어오는데, 2026년 8월에는 한 공제조합 성격 기관에서, 2026년 9월에는 한 정밀기기 제조사 한국법인에서 각각 문의가 왔습니다. 두 문의 모두 카카오 쪽 정책과 기술 문서를 확인해야 답할 수 있는 내용이 많았고, 그때마다 카카오 공식 문서를 처음부터 다시 뒤졌습니다.
같은 조사를 반복하는 비용도 문제였지만 더 나쁜 것은 따로 있었습니다. 매번 새로 조사하다 보니 답이 조금씩 다르게 나갔고, 다르게 나간 답을 나중에 정정하는 자리가 신뢰를 깎았습니다. 카카오 채널 구성만 해도 접수봇·상담봇·선발신·자동응답 네 가지로 나뉘는데, 구성에 따라 확인해야 할 조항이 다르고 어떤 조항은 공식 문서에 값 자체가 없습니다.
그래서 조사를 반복하는 대신 사실 하나하나를 기록해 두고, 고객에게 나갈 초안을 발송하기 전에 자동으로 확인하는 절차를 만들기로 했습니다. 이 절차를 이 글에서는 게이트라고 부릅니다 — 초안을 내보내기 전에 반드시 통과해야 하는 자동 검사 관문입니다. 규칙은 사람이 외워서 지키는 대신 코드로 짜서 실행되게 했습니다. 규칙은 잊혀도 코드는 잊히지 않기 때문입니다.
이 방식의 목표는 새 문의가 올 때마다 처음부터 조사하던 방식을 조회로 바꾸는 데 있습니다. 새 문의가 들어오면 먼저 지금까지 쌓인 기록표 안에 같은 축 문의가 이미 있는지부터 확인하고, 있으면 그 기록을 그대로 다시 쓰고 없을 때만 새로 조사합니다. 상담봇 축과 접수봇 축, 두 가지 문의 형태는 이번 작업을 거치며 기록표 안에서 이미 구분돼 있었습니다.
네 가지 구성은 역할이 다릅니다. 접수봇은 신청 내용을 받아 정리하는 역할이고, 상담봇은 질문에 자동으로 답하는 역할입니다. 선발신은 정해진 시점에 먼저 말을 거는 방식이고, 자동응답은 정해진 문구로만 짧게 답하는 방식입니다. 구성이 다르면 확인해야 할 사실의 축도 달라집니다.
처음 잰 숫자 — 사실 48건, 첫 검사에서 위반 15건 전부 검출
먼저 카카오 공식 문서를 뒤져 사실을 하나씩 기록표에 적었습니다. 공식 문서 원문으로 확인한 사실 40건과 저희가 직접 실측해 확인한 사실 8건을 더해 총 48건을 기록했습니다. 사실 하나마다 주장·공식 원문 인용·출처 주소·확인한 날짜·상태·근거·고객에게 그대로 쓸 수 있는 문장까지 9개 항목을 함께 적어, 나중에 이 사실을 다시 찾을 때 매번 원문을 다시 열어보지 않아도 되게 했습니다.
출처로 쓴 공식 문서 주소는 12개였고, 전부 정상 접속되는지 확인했습니다. 확인되지 않는 주소를 근거로 쓰면 나중에 그 근거 자체가 사라지는 문제가 생기기 때문입니다. 요건 문장을 카카오 채널 구성과 견적 갈래로 연결하는 문서에서는 이 기록표의 사실 식별번호 35건을 그대로 참조하게 했습니다 — 참조한 식별번호가 기록표 안에 실제로 있는지도 함께 확인 대상입니다.
이 요건 문서는 순서가 정해져 있습니다. 고객이 쓴 요건 문장을 먼저 접수봇·상담봇·선발신·자동응답 네 구성 중 어디에 해당하는지로 가르고, 그 구성에 맞는 견적 갈래 두 가지 중 하나로 이어지고, 마지막에는 고객이 준비해야 할 항목을 5개 단계로 정리해 마무리됩니다. 구성부터 잘못 가르면 뒤의 견적 갈래와 준비물까지 전부 다시 잡아야 하므로, 이 첫 분류가 기록표의 사실만큼이나 중요합니다.
기록표를 채운 다음에는 검사 도구를 만들었습니다. 이 도구가 잡는 것은 세 가지입니다. 카카오 비용이나 레퍼런스, 복수 주소처럼 실제로 나갈 뻔했던 단정 표현, 용량·해상도·처리량·알림 발송 단가처럼 공식 문서에 값 자체가 없는 축에 붙는 수치, 그리고 영업일처럼 짝을 이뤄 함께 나가야 하는 유보 문구의 누락입니다. 이 도구를 처음 시험할 때는 위반 표현을 일부러 심어 놓은 초안을 만들어 넣었습니다. 결과는 15건 중 15건, 전부 잡아냈습니다.
공식 문서를 인용할 때는 요약이 아니라 원문 그대로 옮겨 적기로 정했습니다. 요약을 적으면 그 순간부터 기록표가 원본이 아니라 다시 가공된 자료가 되고, 근거로서 확인할 수 있는 값어치가 사라지기 때문입니다.
세운 가설 — 위반만 잡아내면 검수가 끝난 줄 알았다
위반을 심은 초안 15건을 전부 잡아내자 이 정도면 검사 도구가 완성됐다고 판단했습니다. 가설은 단순했습니다 — 위반 문구가 들어간 초안을 넣었을 때 그 위반을 전부 찾아내면, 이 도구는 발송 전 확인 절차로 충분하다고 봤습니다.
이 가설에는 한 가지가 빠져 있었습니다. 위반을 잡아내는 능력만 쟀지, 위반이 없는 정상적인 초안을 넣었을 때 이 도구가 엉뚱한 곳을 위반으로 잘못 짚지는 않는지는 아직 확인하지 않았습니다. 위반본에서 15건을 전부 잡아냈다는 결과 하나만으로 이 도구를 신뢰할 수 있다고 여긴 것이 이 가설의 전제였습니다.
가설이 틀린 지점 — 정상 초안을 넣었더니 무엇이 나왔을까?
실제로 발송을 기다리던 정상 초안 한 건과, 고객에게 나갈 예정이던 서식 3종(기능명세서·검수항목표·데이터흐름도 및 수탁자목록)을 같은 검사 도구에 넣어봤습니다. 위반이 없어야 정상이니 이번에는 0건이 나와야 맞는 결과입니다. 그런데 이 검사 과정에서 도구 자체의 결함 3건이 먼저 드러났습니다.
첫째, 사실 식별번호에 포함된 숫자를 수치 주장으로 잘못 셌습니다. 식별번호는 그냥 이름표인데, 그 안의 숫자를 미확인 축의 수치처럼 취급해 위반으로 잘못 짚을 뻔했습니다. 둘째, 부정을 나타내는 여러 어미를 하나하나 나열해 검사하는 방식이었는데, 그 목록에 '없으므로'라는 어미 하나가 빠져 있어 실제로 있는 부정 표현을 놓쳤습니다. 셋째, 문장이 끝나는 자리를 줄바꿈 하나로 판단하다 보니, 줄을 바꿔 이어지는 부정 표현을 못 봤습니다.
도구 결함 3건을 고치는 과정에서 서식 쪽에서도 실제 결함 2건이 나왔습니다. 하나는 고객에게 나가는 문서에 내부용으로만 써야 할 지침 문구가 그대로 섞여 있었던 것이고, 다른 하나는 카카오 과금과 관련해 반드시 붙어야 할 유보 문구가 빠져 있었던 것입니다. 위반본만 통과시키는 시험으로는 절대 드러나지 않았을 결함들이었습니다.
진짜 원인 — 규칙은 있는데 그 규칙을 검증할 예시가 없었다
왜 이런 결함이 남아 있었는지 따라가 보니, 검사 규칙을 늘릴 때마다 그 규칙이 실제로 작동하는지 확인할 예시 문장을 자체 시험 자료에 같이 넣지 않은 것이 원인이었습니다. 규칙은 코드로 짜여 있어도, 그 규칙 하나하나가 오타나 조사 하나 차이로 조용히 죽어 있을 수 있습니다. 예시가 없으면 그 죽음을 아무도 알아채지 못합니다.
실제로 이 문제가 다른 자리에서도 한 번 더 났습니다. '~는 없는 구성입니다'라는 금지 문구 규칙이 '는'이라는 조사 하나만 잡도록 적혀 있었는데, '비용은 없는 구성입니다'처럼 조사가 '은'으로 바뀐 문장은 잡지 못했습니다. 이 문장은 실제로 배포 중이던 안내 자료 한 페이지에 그대로 살아 있었는데도 검사 도구는 통과 판정을 냈습니다. 이 규칙에 해당하는 예시가 자체 시험 자료에 단 한 줄도 없었기 때문에, 자체 시험을 아무리 돌려도 이 결함은 보이지 않았습니다.
값이 없다는 판단, 즉 '아직 확인되지 않았다'는 상태를 내리는 방식에도 같은 뿌리의 문제가 있었습니다. 한 공식 문서에서 못 찾았다고 곧바로 '값이 없다'로 기록하면, 실제로는 다른 공식 문서에 그 정의가 있는데도 놓칠 수 있습니다. 실제로 '비즈앱'이라는 용어 정의가 다른 공식 문서 쪽에 있었는데, 그 한 층을 더 따라가지 않아서 관련 사실 하나가 미확인으로 잘못 남았고, 그 결과 틀린 문장이 안내 자료 초안에 실려 발송 직전까지 갔습니다.
운영 채널과 개발 채널이 모두 동일한 비즈앱에 연결
이 인용문만 보고는 '채널이 2개 필요하다'로 좁게 읽었습니다. 그런데 '비즈앱'이 정확히 무엇을 가리키는지는 이 문서가 아니라 카카오디벨로퍼스 쪽 다른 문서에 정의돼 있었고, 그 문서에는 '비즈 앱과 비즈니스 채널로 각각 전환해야 합니다'라는 문장이 따로 있었습니다. 낯선 명사가 나오면 그 명사 정의까지 한 번은 따라가야 하는데, 이번에는 그 한 층을 가지 않아서 사실 하나가 실제보다 더 불확실한 상태로 기록됐습니다.
조치 — 어떻게 정상과 위반을 동시에 확인하는 시험으로 바꿨나?
먼저 검사 규칙을 추가하거나 고칠 때마다 그 규칙 전용 예시 문장을 자체 시험 자료에 최소 한 줄이라도 반드시 같이 넣기로 정했습니다. 이렇게 하면 자체 시험이 통과한 건수가 '규칙이 다 살아 있다'는 뜻에 실제로 가까워집니다. 예시 없이 추가한 규칙은 죽어 있어도 계속 통과만 뱉는 고장 난 계기와 다르지 않기 때문입니다.
사실의 상태도 4종으로 나눠 관리하기로 했습니다 — 공식 문서 원문으로 확인됨, 방향은 맞지만 초판이 좁거나 세게 적었던 것, 공식 문서에 값이 아직 없는 것, 외부 신호로 반박된 것입니다. 특히 '값이 아직 없다'는 판단은 한 문서만 보고 내리지 않고, 그 문서 안에 나오는 낯선 용어의 정의까지 한 층 더 따라간 뒤에 내리기로 원칙을 세웠습니다.
고객에게 나가는 서식도 슬롯 방식으로 표준화했습니다. 기능명세서는 타사가 같은 범위로 견적할 수 있는 수준으로 만들어 비교 견적 요청을 거절하지 않아도 되게 했습니다. 검수항목표는 18개 항목 전부에 숫자로 된 합격 조건을 달았습니다 — 예를 들어 '8건을 연달아 접수하면 8건 전부 도착해야 한다'처럼 고객이 직접 재현해 확인할 수 있는 조건만 적었고, 값을 알 수 없는 해상도·용량 같은 항목은 검수 조건이 아니라 인도 후 보고 항목으로 따로 뺐습니다. 데이터흐름도와 수탁자목록은 저장이 일어나는 지점과 일어나지 않는 지점을 구분해서 적었습니다.
비교 견적을 위해 명세서를 요구하는 요청도 거절하지 않기로 했습니다. 명세를 내주지 않으면 그 자리에서 지는 것은 경쟁 업체와의 비교가 아니라 절차 자체이기 때문입니다. 데이터흐름도와 수탁자목록에서 저장 지점을 가른 이유도 비슷합니다 — 규모가 큰 고객사일수록 이 문서 하나로 위탁 여부를 먼저 판단하려는 경우가 있었습니다.
짝을 이뤄야 하는 유보 문구 규칙도 다시 정리했습니다. '영업일 3일에서 5일'처럼 처리 기간을 언급하면 '반려되면 다시 신청할 수 있다'는 문구가 같은 초안 안에 함께 있어야 통과하도록 했고, 카카오 과금을 언급하면 '정확한 금액은 카카오 쪽에 다시 확인해 달라'는 문구가 함께 있어야 하도록 했습니다. 내부 문서에는 있던 이 유보 문구가 고객 문서로 옮겨지며 사라지는 경로가 실제로 있었기 때문에 넣은 규칙입니다.
짝 유보 규칙에는 예시가 하나 더 있습니다. 카카오 이벤트 API 기능을 언급하면 '정확한 사항은 고객센터에 다시 확인해 달라'는 문구가 같은 초안에 함께 있어야 통과하도록 정했습니다. 두 예시 모두 내부 문서에는 원래 붙어 있던 유보 문구가 고객 문서로 옮기는 과정에서 조용히 빠졌던 자리였습니다.
마지막으로 검사 도구의 자체 시험 자체를 다시 짰습니다. 위반을 심은 초안과 위반이 없는 정상 초안을 같은 시험 안에서 동시에 돌리고, 위반본에서는 전부 검출되고 정상본에서는 전부 통과해야만 이 시험이 통과로 판정되게 했습니다. 어느 한쪽만 확인하는 시험은 더 이상 쓰지 않기로 했습니다.
검사 도구에는 조회용 명령 두 가지도 함께 붙였습니다. 하나는 이미 기록된 사실인지 키워드로 찾는 명령이고, 다른 하나는 그 사실 중 고객에게 그대로 쓸 수 있는 문장만 뽑아 보여주는 명령입니다. 새 문의가 오면 초안부터 쓰지 않고 이 조회 명령부터 실행해 같은 축의 사실이 이미 있는지 확인하고, 없을 때만 새로 조사하는 순서로 바꿨습니다.
재측정 결과 — 위반 15건 검출 유지, 정상 0건, 실제 사례 2건 통과
고친 검사 도구로 자체 시험을 다시 돌렸습니다. 위반을 심은 초안에서는 여전히 15건 중 15건을 전부 잡아냈고, 이번에는 정상 초안에서 잘못 잡아낸 위반이 0건이었습니다. 두 결과가 동시에 나와야 통과로 정의했는데, 이번에는 실제로 둘 다 통과했습니다.
자체 시험을 새로 짠 뒤에는 실제 사례에도 적용해 봐야 한다고 판단했습니다. 자체 시험 자료 안의 결과와 실제 상담에서 오간 문서의 결과가 다르면, 그 차이 자체가 아직 못 찾은 결함일 수 있기 때문입니다. 이 검사 도구를 과거에 실제로 오간 상담 사례 2건에도 소급 적용했습니다. 2026년 8월 문의를 준 공제조합 성격 기관은 상담봇 구성이었고, 회신·제안 자료·팔로업 2회까지 검사 항목 5종 전량을 통과했습니다. 2026년 9월 문의를 준 정밀기기 제조사 한국법인은 접수봇 구성이었고, 회신 초안과 검증 보고서, 서식 3종까지 같은 검사 항목 5종 전량을 통과했습니다.
소급 적용 과정에서 기록표 자체의 결함도 하나 더 나왔습니다. 초판 기록표가 '채널 개설' 관련 사실을 미확인 묶음에 넣어 놨는데, 그 바람에 2026년 8월 13일에 실제로 나갔던 정확한 문장 하나('카카오비즈니스 가입 후 무료로 개설 가능합니다')를 위반으로 잘못 판정할 뻔했습니다. 공식 문서를 다시 확인해 보니 이 내용은 명시돼 있었고, 사실을 갈라 다시 정정했습니다. 옳았던 과거 답변을 검사 도구가 틀렸다고 하면, 틀린 것은 과거가 아니라 검사 도구 쪽이라는 원칙을 이때 세웠습니다. 이 소급 확인을 건너뛰었다면 과거에 정확했던 답변 하나가 이유 없이 위반으로 뒤바뀐 채 남았을 자리입니다.
남는 한계 — 아직 사람이 층을 직접 따라가야 하는 지점
규칙을 추가할 때마다 예시를 같이 넣는다는 절차는 사람이 기억해서 지키는 습관입니다. 코드를 작성하는 순간 자동으로 예시 등록을 강제하는 장치는 아직 없습니다. 규칙 목록과 예시 목록이 각각 다른 자리에 있는 한, 둘 사이의 연결은 계속 사람이 챙겨야 합니다.
'값이 아직 없다'는 판단 앞에서 한 층 더 따라가는 습관도 마찬가지입니다. 이 습관이 없어서 정의가 다른 문서에 있는 용어 하나 때문에 틀린 문장이 발송 직전까지 갔던 사고가 이미 한 번 있었고, 앞으로도 같은 형태의 사고가 완전히 없어졌다고 보장할 수는 없습니다. 확인해야 할 문서가 몇 층으로 이어질지는 매번 미리 알 수 없고, 그 층을 끝까지 따라갈지 말지도 지금은 사람이 그때그때 판단합니다.
카카오 쪽 정책과 기술 문서는 공지 없이 바뀝니다. 그래서 기록표 전체를 90일 주기로 다시 확인하기로 정했는데, 이 재확인도 사람이 실행해야 하는 일이고 아직 자동으로 도는 절차는 아닙니다.
재확인할 때도 페이지를 하나씩 열어 보는 방법은 가장 느립니다. 카카오 쪽 문서 사이트는 전체 페이지 목록을 담은 파일을 따로 제공하는데, 이 목록 파일을 통째로 내려받아 한 번에 검색하는 편이 페이지를 하나씩 여는 것보다 훨씬 쌉니다. 다만 이 방법도 지금은 재확인이 필요하다고 판단한 사람이 그때그때 직접 실행해야 하는 절차로 남아 있습니다.
이번 작업을 거치며 얻은 습관 하나는 명확합니다. 검사 도구를 만들었다는 사실 자체보다, 그 도구를 위반본과 정상본 양쪽으로 실제로 시험해 봤는지가 더 중요하다는 습관입니다. 위반을 잡아내는 능력만 보고 검수가 끝났다고 판단했다면, 정상 문서에 남아 있던 결함 5건은 드러나지 않은 채로 다음 상담 사례까지 그대로 넘어갔을 가능성이 큽니다.
짝 유보 규칙도 지금까지 실제로 빠졌던 사례 두 가지만 등록돼 있습니다. 영업일과 반려, 이벤트 API와 고객센터 확인, 이 두 짝 말고 아직 걸리지 않은 새로운 조합은 이 목록에 없으므로 검사를 통과했다고 안심할 수 없습니다. 새 조합은 실제로 나갈 뻔한 문장이 한 번 발견돼야 비로소 목록에 등록됩니다.
검사 도구가 잡아내는 범위도 기록표 안에 이미 들어 있는 축(비용·레퍼런스·복수 주소·용량·해상도·처리량·단가·영업일 등)으로 한정돼 있습니다. 기록표에 아직 없는 새로운 종류의 단정 표현이 나오면, 그 표현을 처음 발견하는 것은 여전히 사람의 몫입니다. 비슷한 확인 절차를 다른 영역에 적용한 사례는 AI 법령 인용 검증 게이트 이야기에도 있습니다. 고객에게 나가는 답변에 확인 절차를 직접 설계해야 하는 상황이라면 상담에서 저희가 실제로 쓰는 방식을 더 자세히 나눌 수 있습니다.