이번 주에 자동화 시스템이 수학적 오류를 수정했습니다. 깨진 링크도, 오래된 날짜도 아니었습니다. 수학적 오류 — 실제로 세 가지의 오류가 세 개의 서로 다른 예시(worked examples)에서 각기 다른 방식으로 나타났습니다. 모두 EBITDA 계산기에서 발생한 문제였습니다.

EBITDA를 계산하는 페이지가 EBITDA를 잘못 계산하고 있었습니다.

저는 이를 git 로그에서 발견했습니다. 7월 28일의 커밋 f501018: "SEO: EBITDA 계산기 콘텐츠 개선 — 예시 수학 오류 수정, 검증된 벤치마크(benchmarks) 업데이트." 각 계산기 페이지를 검토하는 동일한 일일 개선 루틴이 이 페이지에도 적용되어, 이전의 출력 결과가 잘못되었음을 스스로 찾아낸 것입니다.

설정 (The setup)

개선 자동화는 현재 42개의 커밋을 기록하고 있습니다 — 평일마다 매일 밤 하나의 계산기 페이지를 처리합니다. 프로세스는 간단합니다: 대기열에서 페이지를 선택하고, 현재 산업 벤치마크(benchmarks)를 가져오고, 검증된 수치로 예시(worked examples)를 다시 작성하고, 내부 링크를 연결한 뒤 커밋합니다. 자동화 시스템은 초기 검토와 후속 패스(passes)를 모두 처리합니다.

이번 주에는 WACC, GRM, EBITDA, 점유율(Occupancy Rate), 주가수익비율(P/E Ratio), CPM, 그리고 SaaS 가치 평가(SaaS Valuation) 등 7개의 페이지를 다루었습니다. 이 중 5개는 GSC(Google Search Console)에서 보이지 않습니다 — 지난 28일 동안 노출량(impression volume) 기준 상위 50개 페이지에 포함되지 않았습니다. 구글은 이 페이지들이 존재한다는 것을 알고 있지만, 단지 누구에게도 보여주지 않을 뿐입니다.

EBITDA 커밋은 예외적이었습니다. 이번 주의 다른 모든 커밋은 "검증된 벤치마크 추가, 내부 링크 업데이트"라는 내용의 변형된 문구였습니다. 하지만 이 커밋은 "예시 수학 오류 수정"이라고 적혀 있었습니다. 이는 예시들이 잘못된 수학 계산과 함께 커밋되었으며, 이제 수정되고 있음을 의미합니다.

실제 차이점(diff)이 보여준 것

EBITDA 계산기에는 세 가지 예시 — SaaS 기업, 제조 기업, 전문 소매 체인 — 가 있었습니다. 각 예시는 손익계산서(P&L statement)로부터 EBITDA를 계산하는 과정을 보여주었습니다. 그리고 각각의 예시에서 산술 오류가 발생했습니다.

소매 체인 (수정 전):

매출(Revenue): $8,000,000
- 매출원가(COGS): $5,200,000
- 운영 비용(OpEx): $2,000,000
...

$800,000 + $225,000 = $1,025,000이며, $575,000이 아닙니다. 예시에서 감가상각비(D&A)를 더하는 대신 빼버리는 실수를 범했습니다. EBITDA에서 "DA"의 핵심은 비현금성 비용인 감가상각비(Depreciation)와 무형자산 상각비(Amortization)를 다시 더해주는(add-back) 것입니다. 예시는 말 그대로 그 반대로 수행했습니다.

제조 기업 (수정 전):

매출(Revenue): $10,000,000
- 매출원가(COGS): $6,500,000
- 운영 비용(OpEx): $2,200,000
...

$1,300,000 + $450,000은 $1,300,000과 같지 않습니다. D&A 항목이 나타나기는 하지만, 결과값은 영업 이익(Operating Income)과 동일합니다. 마치 가산(add-back)이 전혀 적용되지 않은 것처럼 말입니다. 사실상 EBITDA = EBIT인 상태입니다.

SaaS 기업 (수정 전):

매출(Revenue): $5,000,000
- 매출원가(COGS): $750,000
- 운영 비용(OpEx): $2,500,000
...

$1,750,000 + $250,000 = $2,000,000입니다. 명시된 EBITDA $1,500,000은 위의 수치들로부터 도출되지 않습니다. 어떤 산술 방식을 사용해도 해당 결과에 도달할 수 없습니다.

수정 작업에서는 계산 체계의 일관성을 맞추기 위해 각 예시의 운영 비용(OpEx)을 조정했습니다. SaaS의 OpEx는 $2.5M에서 $3M으로 변경되었습니다 (영업 이익 $1.25M, + D&A $250K = EBITDA $1.5M, 마진 30% — 정확함). 제조 기업의 OpEx는 $2.2M에서 $2.75M으로 변경되었습니다 (영업 이익 $750K, + D&A $450K = EBITDA $1.2M, 마진 12% — 정확함). 소매 기업의 OpEx는 $2M에서 $2.4M으로 변경되었습니다 (영업 이익 $400K, + D&A $225K = EBITDA $625K, 마진 7.8% — 정확함). 이제 모든 예시의 계산이 맞아떨어집니다.

수정 전에는 그 어떤 것도 맞지 않았으며, 각각 서로 다른 방식으로 틀려 있었습니다.

발견 사항 #1: 해당 페이지에는 트래픽이 없었습니다. 오류는 보이지 않았습니다.

지난 28일 동안 EBITDA 계산기에 대한 쿼리 수준의 GSC(Google Search Console) 분석 데이터를 추출했습니다. 확인된 쿼리는 단 하나였습니다: "ebitda quality calculator", 노출(impression) 1회, 순위(position) 70위, 클릭 0회. 그게 전부였습니다. 이 페이지는 본질적으로 SEO(검색 엔진 최적화) 흔적이 거의 없습니다.

이는 두 가지 측면을 시사합니다. 잘못된 계산 예시를 본 사람이 아무도 없었다는 것입니다. 페이지에 아직 트래픽이 발생하지 않고 있기 때문입니다. EBITDA를 배우기 위해 클릭했다가 더해야 할 곳에서 빼기를 마주하게 된 사용자는 없었습니다. 피해 규모: 제로(0).

하지만 반대 측면도 있습니다. 수학적 오류를 수정한다고 해서 제가 볼 수 있는 어떤 지표(metric)도 움직이지는 않을 것입니다. 콘텐츠 품질이 트래픽 변수가 되기 전에는, 해당 페이지가 검색 순위에 오를 수 있을 만큼 충분한 권위(authority)를 쌓아야 합니다. 우리는 Google이 아직 누구에게도 노출하지 않고 있는 콘텐츠를 수정하고 있는 것입니다. 산술적 계산은 이제 맞지만, 청중은 아직 오지 않고 있습니다.

발견 사항 #2: 자신의 출력을 스스로 잡아내는 자동화가 제기하는 감사(audit) 문제

이 오류들을 찾아내고 수정한 자동화는 42개의 모든 개선 커밋(commit)을 실행하는 것과 동일한 시스템입니다. 이 시스템이 원래의 EBITDA 콘텐츠를 작성한 것은 아닙니다. 해당 콘텐츠는 이 리포지토리(repository)의 git 히스토리보다 앞선 것입니다. 하지만 이 시스템은 몇 주 동안 다른 페이지들을 검토하며, 별도의 검증 단계 없이 "검증된 벤치마크 (verified benchmarks)"와 "작동 예시 (worked examples)"를 커밋해 왔습니다.

EBITDA 사례는 그것이 어떻게 잘못될 수 있는지를 보여줍니다. 수학적 계산이 겉보기에는 그럴듯해 보이지만 (숫자가 있고, 순서가 맞으며, 올바른 라벨이 붙어 있음), 실제로는 합계가 맞지 않습니다. 생성 단계(generation pass)에서 이런 종류의 유창하지만 틀린 출력이 나올 수 있습니다. 검토 단계(review pass)에서 이를 잡아낼 수 있지만, 이는 검토 단계가 단순히 콘텐츠의 완전성(completeness)이 아니라 산술적 정확성(arithmetic correctness)을 구체적으로 확인하고 있을 때만 가능합니다.

다른 41개의 페이지 중 수학적으로 일치하지 않는 작동 예시가 얼마나 더 있을지는 알 수 없습니다. EBITDA 오류는 커밋 메시지(commit message)에 명시적으로 표시되어 있었기 때문에 제가 발견할 수 있었습니다. 다른 페이지들의 커밋 메시지는 이전에 무엇이 잘못되었는지에 대한 어떠한 표시도 없이 "검증된 벤치마크 추가 (add verified benchmarks)"라고만 되어 있습니다.

발견 사항 #3: 아직 배포하지 못한 15분짜리 수정 사항

습관적으로 Googlebot의 관점에서 EBITDA 계산기를 훑어보고, og:title을 확인합니다.

<meta property="og:title" content="Valuefy - Free Business Calculators &amp; Financial Tools">
...
<meta property="og:title" content="EBITDA Calculator: Add-Backs &amp; EV Multiple | Valuefy" data-rh="true">

두 개의 태그가 있습니다. 홈페이지도 마찬가지입니다:

저는 이 시리즈의 첫 번째 포스트에서 이 문제를 지적했습니다. 해결책은 index.html에서 두 줄만 수정하면 되는 것이었습니다. 정적인 og:title과 og:description을 제거하고 React Helmet이 단일 소스(Single Source of Truth)가 되도록 하는 것입니다. 당시에는 15분 정도 걸릴 것이라고 예상했습니다. 7주가 지나고 42번의 자동화 커밋(Automation Commits)이 진행된 지금도, 그 버그는 여전히 남아 있습니다.

대조가 극명합니다. 자동화 시스템은 요청받지 않아도 매일 밤 신뢰할 수 있게 하나의 계산기 개선 사항을 배포합니다. 템플릿 파일의 두 줄짜리 구조적 수정은 1주 차부터 백로그(Backlog)에 쌓여 있었습니다. 자동화 시스템은 index.html을 건드리도록 설계되지 않았습니다. 제가 해야 하는데, 아직 하지 않았습니다.

내가 할 일

1. 이번 주에 og:title 버그를 수정한다. 다음 주가 아니라 이번 주입니다. index.html의 두 줄입니다. 자동화는 이를 수행하지 못하므로, 제가 직접 해야 합니다.
2. 개선 루틴에 산술 검증(Arithmetic Check)을 추가한다. 예시 계산(Worked Example)을 커밋하기 전에, 코드 블록의 숫자 합계가 명시된 결과와 일치하는지 확인합니다. 이는 기계적인 작업이며, 프롬프트(Prompt)에 포함되기만 하면 됩니다.
3. 노출량(Impression Volume) 기준 상위 10개 페이지를 샘플 점검한다. 이 페이지들은 실제 사용자들에게 콘텐츠 품질이 중요해지기 시작하는 지점입니다. 각 페이지에서 예시 계산을 추출하여 산술 계산을 수동으로 검증할 것입니다. 만약 더 많은 오류를 발견한다면, 오류의 분포가 어떤지 보고하겠습니다.

계속 머릿속을 떠나지 않는 생각

자동화 시스템은 배포(Shipping)를 하는 데 능숙합니다. 7주 동안 평일마다 단 하루도 거르지 않고 42번의 커밋을 수행했습니다. 그 부분은 잘 작동합니다.

하지만 자동화 시스템이 덜 신뢰할 수 있는 부분은 자신이 배포한 내용이 정확한지 아는 것입니다. 그럴듯한 것(Plausible)과 정확한 것(Correct)은 같은 것이 아닙니다. 특히 산술(Arithmetic)이 필요한 영역에서는 더욱 그렇습니다. 재무 계산기 페이지에는 단순히 듣기에 좋은 문장이 아니라, 검증 가능한 수학적 계산이 필요합니다.

솔직하게 말씀드리자면: 자동화 프로세스를 더 많이 실행하는 것이 도움이 됩니다. 검토 단계(review pass)가 생성 단계(generation pass)에서 놓친 부분을 잡아내기 때문입니다. 하지만 이는 검토 단계가 실제로 정확성을 확인하고 있으며, 모든 페이지가 결국 검토를 거친다는 전제하에만 유효합니다. 단 한 번의 프로세스만 거친 뒤 다시는 검토되지 않는 페이지들은 제가 알 수 없는 영역입니다.

다음 주에 샘플을 추출할 예정입니다. 만약 EBITDA 오류가 특이 사례(outlier)라면 그렇게 말씀드리겠습니다. 만약 그것이 대표적인 사례라면, 그것은 다른 문제이며 매일 밤 이루어지는 커밋(commit)과는 다른 해결책이 필요한 문제입니다.

저는 valuefy.app에서 이러한 실험을 진행하며 발견한 내용을 기록하고 있습니다. 만약 여러분이 AI 기반 콘텐츠 파이프라인(content pipelines)을 구축하거나, SEO 개선을 자동화하거나, 혹은 "정확한 콘텐츠"와 "더 많은 콘텐츠" 사이의 간극을 해결하려 노력 중이라면, 함께 의견을 나누고 싶습니다. 댓글을 남기거나 연락해 주세요.

또한 저는 기업을 위한 AI 툴링(tooling)을 제작하는 AImiten을 운영하고 있습니다. 이 사이드 프로젝트는 고객 업무에 적용되기 전에 무엇이 고장 나는지를 파악하는 공간입니다.