AI업체 홈페이지에 실적을 쓰기 전에, 방문자가 직접 세어 볼 수 있는지부터 쟀다

무엇이 문제였나: AI업체의 실적 수치를 링크가 반박했다

AI업체가 홈페이지에 운영 실적 수치를 쓸 때, 가장 먼저 그 수치를 반박하는 쪽은 경쟁사가 아니라 같은 화면에 걸어 둔 우리 링크였다. 서비스 소개 페이지에 숫자 세 개를 넣다가 이 사실을 알았고, 문구를 두 번 갈아엎었다. 이 글은 처음 쟀던 숫자, 틀린 가설, 바꾼 기준, 고친 뒤 다시 잰 결과를 순서대로 적는다.

출발점은 영업 쪽 진단이었다. 실제 문의가 10건 들어왔는데 계약은 0건이었고, 사인이 막힌 자리는 문의 도달이 아니라 신뢰와 단가였다. 한국 4대 회계·전략 회사가 모두 밟은 경로를 살펴보니 「내부 효율화 도구를 만들고, 그 도구를 외부 판매 상품으로 바꾼다」였다. 이 회사들이 파는 신뢰는 「우리가 이미 이걸로 우리를 굴린다」에서 나온다.

우리에게도 그 자산이 있었다. 매일 도는 예약 작업이 있고, 쌓아 둔 기술 글이 있고, 만들어 둔 데모가 있었다. 그런데 홈페이지는 그 이야기를 하지 않고 있었다. 그래서 검색에 노출하는 서비스 소개 페이지 한 곳(/ai/automation)에 「우리 운영 실측」 세 칸을 넣고, 각 칸에서 데모 페이지로 잇기로 했다. 방문자가 상담을 누르기 전에 「이 회사는 말만 하지 않는다」고 판단하게 하는 것이 목표였다.

먼저 결론을 적어 둔다. 신뢰 문구에 쓰는 숫자는 방문자가 링크를 눌러 직접 세어 볼 수 있어야 한다. 직접 세어 볼 수 없는 숫자는 맞더라도 쓰지 않는 편이 낫다. 이 한 줄에 닿기까지 숫자를 고르는 기준을 세 번 바꿨다.

처음 잰 숫자는 무엇이었나?

2026년 9월 3일에 세 가지를 직접 쟀다. 크론은 서버의 예약 목록을 출력하는 명령(crontab -l)에 주석이 아닌 줄만 세는 grep -c를 붙여 167개가 나왔다. 기술 글은 글 목록 데이터 파일의 항목 수로 9편이었고, 새벽 2시 20분에 도는 발행 예약 작업이 올리며 공개 목록 페이지는 200 응답을 냈다. 데모는 로컬 데모 폴더 아래 하위 디렉터리를 세어 14종이었다.

세 숫자는 전부 직접 센 값이었고, 숫자 옆에 세는 명령도 적을 수 있었다. 그래서 처음에는 안전하다고 느꼈다. 이 느낌이 첫 번째로 틀린 가설의 뿌리였다.

세 숫자는 성격도 서로 다르다. 크론 167개는 서버 한 대의 설정을 센 값이라 방문자가 따라 해 볼 수 없다. 글 9편은 공개 목록 페이지에서 누구나 셀 수 있다. 데모 14종은 우리 컴퓨터의 폴더 안을 센 값이라 방문자 눈에는 보이지 않는다. 같은 「직접 센 숫자」라도 방문자가 같은 값을 얻을 수 있는 정도가 셋 모두 달랐는데, 초안은 이 차이를 구분하지 않았다.

세운 가설: 직접 센 숫자 세 개면 신뢰가 생긴다

가설은 둘이었다. 첫째, 직접 센 숫자는 그 자체로 증거다. 둘째, 데모 14종은 「우리가 실제로 돌려 본 자동화」의 증거다. 카피 초안은 두 가설을 합쳐 「실제로 돌려 산출물까지 뽑아 뒀습니다」라고 썼다.

가설 뒤에는 기대가 하나 더 깔려 있었다. 숫자가 클수록 신뢰도 커진다는 기대다. 크론 167개와 데모 14종은 서로 규모를 키우는 방향으로 읽히는 숫자였고, 우리는 그 방향이 방문자에게도 같은 효과를 낸다고 가정했다. 신뢰를 만드는 쪽은 규모가 아니라 확인 가능성이라는 사실은 아래에서 반증이 나온 뒤에야 보였다.

이 가설에는 검증 계획이 따로 없었다. 숫자를 센 것으로 검증을 끝냈다고 착각했기 때문이다. 센 일과 확인한 일은 다르다. 센 일은 만든 사람의 관점이고, 확인한 일은 방문자의 관점이다. 아래에서 두 가설이 차례로 무너진다.

가설이 틀린 지점은 어디였나?

첫 번째 반증은 코드를 쓰기 전에 숫자의 출처를 하나씩 따져 보다가 나왔다. 데모 14종은 크론에 등록된 것이 0건이었다. 우리 회사를 굴리는 코드가 아니라, 가상의 회사를 가정해 만든 데모 산출물 그대로였다. 「우리가 쓴다」고 쓰면 거짓이었다. 이 문장을 반대로 썼다면 문의한 사람이 「무슨 업무에 쓰시나요」라고 한 번만 물어도 무너졌을 것이다.

그래서 문구를 「만들어 뒀다」로 낮추고, 각주에 이 데모가 운영 중인 시스템과 별개라고 밝혔다. 같은 이유로 데모 페이지의 검색 노출 제외 설정(noindex)도 그대로 두었다. 부수 수리도 하나 나왔다. 영어 판이 /en/ 접두사를 붙인 데모 링크를 걸고 있었는데 실제로 열어 보니 404였다. 데모 페이지는 한국어와 영어가 한 경로를 같이 쓰므로 접두사를 붙이면 안 됐다.

여기까지는 만든 쪽이 스스로 찾았다. 두 번째 반증은 밖에서 왔다. 카피를 마케팅 관점 다섯 가지로 나눠 병렬로 교차 검토했더니, 이 블록의 실패는 「약하다」가 아니었다. 가장 강한 부분이 스스로를 해친다는 결과였다.

카피 5렌즈 교차검증에서 이 블록의 실패가 「약하다」가 아니라 가장 강한 부분이 자해한다로 나왔다. 링크가 자기 숫자를 반박했다.

지적은 세 건이었고, 실측으로 확인하니 전부 사실이었다.

• 크론 167개: 이 칸의 카드 하나가 방문자를 보내는 통계 페이지가 같은 대상을 121개로 이미 게시하고 있었다. 세는 명령까지 화면에 띄우고 「그대로 실행하면 같은 숫자가 나옵니다」라고 적어 둔 페이지였다.
• 데모 14종: 도착지인 데모 페이지의 카드는 8장이었다. 방문자는 14를 셀 수 없었다. 게다가 14개 중 3개는 실행 산출물이 아니라 분석 문서였는데, 「산출물까지 뽑아 뒀습니다」가 그것까지 덮고 있었다.
• 「매일」과 9편: 글의 발행일이 9월 1일 3편, 9월 2일 1편, 9월 3일 5편이었다. 누적 편수와 하루 발행 속도를 붙여 놓아 「매일 한 편」으로 읽혔다.

진짜 원인은 무엇이었나?

원인은 숫자가 틀린 것이 아니었다. 같은 대상의 값이 사는 집이 두 곳이었다. 통계 페이지가 121을 들고 있고, 서비스 소개 페이지가 167을 들고 있었다. 통계 페이지의 121은 8월 9일에 잰 값이었다. 값의 집이 둘이 되면 어느 한쪽은 반드시 낡는다. 통계 페이지 소스 주석이 막으려던 사고가 그대로 재발한 셈이다.

발행일 문제도 같은 뿌리다. 9편은 몇 주에 걸쳐 쌓은 양이 아니라 사흘 사이에 올린 양이었다. 「매일」이라는 단어는 속도를 말하고 「9편」은 쌓인 양을 말한다. 속도와 양은 단위가 다른데, 두 값을 한 문장에 붙이면 읽는 사람은 둘을 곱해서 규모를 상상한다. 방문자가 발행일을 열어 보는 순간 그 상상은 깨진다.

한 겹 더 들어가면 판단 기준이 원인이었다. 처음 기준은 「그럴듯하고 직접 센 숫자 세 개」였고, 이 기준은 숫자가 맞는지만 따졌다. 방문자는 맞는지를 보지 않고 눌러서 같은 숫자가 나오는지를 본다. 만든 사람의 기준과 읽는 사람의 기준이 달랐고, 그 차이를 잡는 검사가 우리 쪽에 없었다.

한 가지는 이 글을 쓰며 끝까지 풀지 못했다. 9월 3일 같은 날 소개 페이지용으로 센 크론이 167개인데, 통계 페이지를 고치며 갱신한 값은 171개다. 세는 명령이 다른 데서 오는 차이로 보이지만, 두 명령을 맞대 보지는 않았다. 확인 필요 항목으로 남긴다. 그리고 이 차이가 바로 숫자를 칸에 옮겨 적으면 안 되는 이유이기도 하다.

어떻게 고쳤나: 숫자 세 개가 아니라 도착지 세 개

기준을 바꿨다. 칸에 들어올 자격은 「링크를 눌러 방문자가 직접 세어 확인되는가」 하나다. 숫자 세 개를 고르는 대신 도착지 세 개를 고르고, 칸의 문구는 그 도착지에서 센 값과 같은 수만 쓴다.

• 9편: 공개 기술 글 목록 페이지에서 센다.
• 8종: 데모 페이지의 카드 수와 일치시킨다. 코드의 카드 목록 상수(DEMO_CARDS)가 8이다.
• 명령: 통계 페이지가 세는 명령까지 화면에 내므로, 숫자를 옮겨 적지 않고 그 페이지로 보낸다.

명령을 보여 주는 쪽을 고른 데는 이유가 있다. 크론 수는 예약 작업을 등록하거나 지울 때마다 바뀐다. 숫자를 문구에 옮겨 적으면 다음 갱신 때 또 한 곳이 낡는다. 명령을 보여 주는 페이지로 보내면 값의 집은 그 페이지 하나로 남고, 소개 페이지는 그 값을 빌려 쓰기만 한다. 한 값은 한 곳에서 정의하고 나머지는 가져다 쓴다는 원칙을 문구에도 적용한 것이다.

결과적으로 크론 167이라는 숫자는 칸에서 사라졌고, 데모는 14종에서 8종으로 줄었다. 줄어든 숫자가 아깝다는 의견이 있었지만 기준에서 밀려난 숫자는 방문자가 확인할 수 없는 숫자였다. 같은 수정에서 함께 고친 것이 다섯 가지다.

• 헤딩에서 규모를 부풀리는 표현을 뺐다. 「우리 회사를 굴립니다」는 증거가 마케팅·리드 수집 파이프라인뿐이라 「무슨 업무를 굴렸는데요」라는 질문에 무너진다. 「저희가 자는 동안」도 뺐다.
• 각주가 앞의 숫자까지 다시 심사하게 만들던 우산 불일치를 없앴다. 서브 문구를 「지금 돌고 있는 것」에서 「만들어 돌린 것」으로 좁혔다. 8종이 우산 밖에 있었기 때문이다.
• 각주 글자 농도 값을 /45에서 /60으로 올렸다. 주장만 진하고 단서가 옅으면 정직한 각주가 사실을 축소해 표시하는 모양이 된다.
• 블록 끝에 다음 행동을 1개 넣었다. 기존 견적 문의 경로다. 신뢰가 가장 높은 지점에서 누를 것이 0개였고, 기존 링크 2개는 둘 다 페이지 밖으로 나가고 있었다.
• 스크롤 시 나타나는 설정(triggerOnScroll)이 이 헤딩에만 빠져 있어서 같은 페이지의 다른 섹션과 맞췄다.

선행 수리도 하나 있었다. 링크 도착지가 틀린 숫자를 내고 있으면 그 칸이 틀린 숫자를 물려받는다. 그래서 칸을 고치기 전에 통계 페이지부터 갱신했다.

고친 뒤 다시 재니 무엇이 달라졌나?

다시 잰 방법은 네 가지다. 첫째, 칸의 링크 4개를 모두 열어 응답을 확인했고 전부 200이었다. 둘째, 한국어 판과 영어 판을 각각 렌더해 눈으로 확인했다. 셋째, 타입 검사 오류 0건과 빌드 통과를 확인했다. 넷째, 변경 범위를 가격·판매 서비스 구성 변경 0건, 실명·고객사·이메일 0건으로 대조했다.

변경량은 이렇다. 처음 커밋은 122줄 추가에 삭제 0줄이었다. 반증을 받아 고친 뒤 두 커밋을 합친 최종 변경은 파일 4개, 148줄 추가, 3줄 삭제다. 코드는 늘었지만 새 주장은 늘지 않았다. 칸은 처음과 같은 세 개다. 달라진 것은 칸마다 방문자가 직접 세어 볼 도착지가 하나씩 있다는 점이다.

이 확인 네 가지는 서로 다른 오류를 잡는다. 링크 응답은 깨진 경로를, 두 언어 렌더는 접두사 같은 로케일 문제를, 타입 검사와 빌드는 코드 오류를, 범위 대조는 요청하지 않은 변경을 잡는다. 이번에 가장 크게 놓친 것은 이 넷 어디에도 걸리지 않는 종류, 곧 문구와 도착지 화면이 서로 어긋나는 문제였다. 그건 사람이 링크를 눌러 두 화면을 나란히 보는 수밖에 없었다.

도착지 쪽에서도 같은 결과가 나왔다. 통계 페이지는 커밋 3,520에서 4,846으로, 크론 121에서 171로, 설계 결정 기록 589에서 776으로 갱신해 측정일이 8월 9일에서 9월 3일로 바뀌었다. 이제 칸을 누른 방문자가 보는 값과 칸에 적힌 문구가 서로 반박하지 않는다.

앞서 다룬 크론 수를 업무 기준으로 다시 세어 본 글도 같은 교훈에서 출발한다. 개수는 세기 쉽지만, 그 개수가 무엇을 증명하는지는 따로 확인해야 한다.

남는 한계: 아직 못 재고 못 푼 것

• 계약에 미친 영향은 재지 못했다. 출발 지표였던 문의 10건·계약 0건이 이 블록으로 움직였는지는 아직 데이터가 없다. 이 글은 「신뢰 문구가 덜 위험해졌다」까지만 말한다.
• 「우리가 회사를 굴린다」의 증거는 지금도 마케팅·리드 수집 파이프라인뿐이다. 다른 업무 사례를 올릴 만큼 쌓지 못했다.
• 값의 집을 하나로 모으는 일은 이 페이지에서만 했다. 다른 페이지가 같은 숫자를 옮겨 적고 있는지는 전수 확인하지 않았다. 확인 필요 항목이다.
• 같은 날 센 167과 171이 왜 다른지 두 명령을 맞대 보지 않았다.

이 한계를 숨기면 이 글도 같은 함정에 빠진다. 고친 뒤 재측정에서 확인한 것은 링크 응답, 렌더, 타입 검사, 변경 범위처럼 기계가 답할 수 있는 항목이다. 「방문자가 이 블록을 읽고 더 믿게 되었는가」는 기계가 답할 수 없고, 아직 아무도 재 보지 않았다. 재 보지 않은 것을 개선했다고 쓰지 않는다.

한계 중 첫 번째가 가장 크다. 신뢰 문구를 고쳤다는 사실과 그 문구가 계약을 늘렸다는 사실은 별개고, 후자는 몇 주치 문의가 쌓여야 잴 수 있다. 숫자가 나오면 이 글 끝에 다시 붙이기로 한다.

AI업체가 실적 수치를 쓰기 전에 거는 점검표

이 사례에서 뽑은 점검 네 가지다. 홈페이지에 AI 도입 실적을 쓰려는 업체라면 숫자를 쓰기 전에 한 번씩 확인해 볼 만하다.

• 숫자를 쓰기 전에 링크 도착지 화면에서 같은 값을 직접 세어 봤는가.
• 숫자가 누적인지 속도인지 문구에서 갈랐는가. 9편과 「매일」은 한 문장에 둘 수 없다.
• 만들어 둔 것과 돌리고 있는 것을 구분했는가. 데모 14종은 크론 등록이 0건이었다.
• 단서를 단 각주가 눈에 읽히는 농도인가. 옅은 각주는 사실을 줄여 보이게 한다.

비슷한 문제로 실적 문구를 못 올리고 있다면 상담 문의로 보내 주면 도착지부터 같이 센다. 증거 등급을 어떻게 붙이는지는 자동화 절감 시간의 근거 등급을 다룬 글에 정리해 두었다.