지난달 AI에게 10,000단어의 제품 콘텐츠 작성을 맡겼습니다. 그리고 제 출시를 거의 망칠 뻔했습니다.

베타 마감일을 3주 앞두고, 저는 Google Doc을 열어 지금까지 존재했던 모든 SaaS 제품과 똑같이 들리는 47페이지 분량의 AI 생성 콘텐츠를 읽었습니다. 혜택 위주의 헤더. 매끄러운 전환. 마찰 없는 흐름. 하지만 영혼은 전혀 없었습니다. 저는 8개월 동안 구축해 온 무언가의 목소리를 인터넷의 집단적 평균값으로 학습된 모델에 외주를 주었고, 모델은 정확히 그 결과물인 '평균'을 내놓았습니다. 저는 그중 어느 것도 출시하지 않았습니다. 4일 동안 모든 것을 다시 썼습니다. 이 글은 제가 배운 것에 관한 것입니다.

자신감-역량 역전 현상 (The Confidence-Competence Inversion)

현재 LLM (Large Language Model) 출력물의 가장 위험한 특성은 환각 (Hallucination)이 아닙니다. 환각은 이미 알려진 문제이며, 개발자들은 사실 관계 오류를 잡아낼 도구와 본능을 가지고 있습니다. 진짜 문제는 제가 '자신감-역량 역전 현상 (confidence-competence inversion)'이라고 부르는 것입니다. 즉, AI 생성 콘텐츠는 가장 불확실해야 할 바로 그 순간에 최대치의 자신감을 보인다는 점입니다.

GPT-4o에게 쓰기 작업이 많은 워크로드(write-heavy workload)에서 특정 Postgres 인덱싱 전략의 트레이드오프(tradeoffs)에 대해 써달라고 요청하면, 모델은 어떤 인간이 훑어보더라도 통과할 만한, 인용 없는 구조화된 확신이 담긴 네 단락의 글을 만들어낼 것입니다. 시니어 DBA (Database Administrator)에게 같은 질문을 던지면,

해결책은 "더 많은 불확실성"을 프롬프트(prompt)로 요청하는 것이 아닙니다. 인간의 승인을 기반으로 학습된 모델들은 도움이 되는 것처럼 들리도록 최적화되어 있으며, 이는 근본적인 확신 태도를 유지하면서 스타일적으로만 완곡한 표현(hedges)을 추가한다는 것을 의미합니다. 해결책은 모든 AI 생성 기술적 주장들을 다듬어야 할 대상이 아니라, 적대적 검토(adversarial review)가 필요한 초안으로 취급하는 것입니다.

목소리의 균질화는 가중되는 문제

개발자가 심도 있는 수정 없이 AI 생성 콘텐츠를 배포할 때마다, 그들은 미래의 모델들이 학습하게 될 말뭉치(corpus)에 기여하게 됩니다. 우리는 인터넷이 점점 더 평균적으로 변하고, 그 평균적인 콘텐츠로 모델을 학습시키며, 그것이 다시 더 평균적인 결과물을 만들어내는 피드백 루프(feedback loop)를 집단적으로 구축하고 있습니다. 만약 당신이 공개적으로 글을 쓰는 빌더(builder)라면

코드는 버전 관리(version control), 테스트, 그리고 하중을 지탱하는 부분을 변경했을 때 작동을 멈추는 컴파일러(compilers)를 가지고 있습니다. 콘텐츠에는 그중 어느 것도 없습니다. 당신의 제품이 변할 때 — 온보딩 문서(onboarding docs)에서 약속했던 기능이 재설계되거나, 가격 모델이 바뀌거나, API 엔드포인트가 이동할 때 — AI가 생성한 콘텐츠는 이를 알지 못합니다. 이제 당신은 사용자가 직접 부딪히기 전까지는 보이지 않는 방식으로 틀려 있는 문서 코퍼스(documentation corpus)를 갖게 된 것입니다.

AI 콘텐츠는 볼륨 최적화(volume-optimized)되어 있기 때문에 문제는 더 악화됩니다. 오후 한나절 만에 50페이지 분량의 문서를 만들어내는 것은 매우 쉽습니다. 하지만 '빌드 인 퍼블릭(build-in-public)'을 진행하는 6개월 동안 50페이지의 문서를 유지 관리하는 것은 결코 쉽지 않습니다. 생성 시점의 속도 이득은 유지 관리 시점에 서서히 피를 흘리는 손실(slow bleed)로 변합니다. 저는 정확히 4개월 차쯤에 이 벽에 부딪힌 다른 세 명의 인디 빌더(indie builders)와 이야기를 나누었습니다.

복합적인 요인: AI가 생성한 콘텐츠를 업데이트하기 위해 다시 돌아왔을 때, 모델은 무엇이 왜 변했는지에 대한 컨텍스트(context)를 가지고 있지 않습니다. 당신이 모델에게 차이점(diff)을 입력하고 문서를 업데이트하라고 요청하면, 모델은 그 변화의 실제 함의(implication)를 놓친 채 그럴듯해 보이는 결과물을 만들어냅니다. 당신은 이제 AI에 의해 편집된 AI의 결과물을 다시 편집하고 있는 것이며, 오류 표면(error surface)은 더욱 넓어졌습니다.

프롬프트 드리프트(Prompt Drift)와 재현성 문제

빌드 인 퍼블릭(build-in-public) 분야에서 거의 아무도 이야기하지 않는 사실이 하나 있습니다: 특정 프롬프트로 오늘 생성한 콘텐츠는 3개월 뒤에 재현(reproducible)되지 않을 것이라는 점입니다. 모델은 업데이트됩니다. 시스템 프롬프트(System prompts)가 변경됩니다. 온도(Temperature)와 샘플링(sampling) 동작이 변합니다. 당신이 프롬프트를 통해 학습시킨 그 '목소리(voice)'는 안정적인 결과물이 아니라, 시간이 흐름에 따라 드리프트(drift)될 스냅샷일 뿐입니다.

이는 일관성(consistency) 측면에서 매우 중요합니다. 만약 당신이 6개월 동안 개발한 프롬프트 세트를 사용하여 블로그 포스트, 문서, 소셜 콘텐츠를 생성하고 있다면, 기반이 되는 모델(underlying models)이 변화함에 따라 해당 프롬프트들은 눈에 띄게 다른 결과물을 만들어낼 것입니다. 저는 거의 동일한 프롬프트를 사용하여 4개월 간격으로 생성된 두 그룹의 콘텐츠를 비교했을 때 이 현상을 발견했습니다. 최신 그룹은 대부분의 면에서 객관적으로 더 나았습니다. 하지만 전체 아카이브를 읽는 사람이라면 누구나 알아챌 수 있을 정도로 이전 콘텐츠와는 어조(tonally)가 완전히 일치하지 않았습니다.

콘텐츠 파이프라인(content pipelines)에 AI 네이티브 워크플로우(AI-native workflows)를 구축하는 개발자라면 명심하십시오. 당신의 프롬프트는 안정적인 인터페이스(interface)가 아닙니다. 외부 API 호출을 다루는 것과 동일하게 취급하십시오. 즉, 버전을 관리(versioning)하고, 출력값을 기록(log)하며, 기반 모델이 변경될 때 회귀 테스트(regression checks)를 실행해야 합니다. 만약 이렇게 하지 않고 있다면, 당신은 콘텐츠 시스템을 가진 것이 아니라 콘텐츠 슬롯머신을 가진 것입니다.

프레임워크: AI 생성 콘텐츠를 배포하기 전에

이것은 추상적인 의미에서 AI를 "책임감 있게" 사용하는 방법에 대한 체크리스트가 아닙니다. 이것은 제가 모델로 생성된 결과물을 배포하기 전에 실제로 실행하는 절차입니다.

구체성 테스트 (The Specificity Test)
콘텐츠 내의 모든 구체적인 주장(claim)을 읽으십시오. 각 주장에 대해 다음과 같이 질문하십시오: "이 문장은 실제로 이 일을 해본 사람만이 쓸 수 있는 문장인가?" 만약 대답이 '아니오'라면 — 즉, 주장은 사실이지만 누구나 쓸 수 있는 내용이라면 — 해당 부분을 표시(flag)하십시오. 표시된 주장의 최소 60%를 당신의 실제 경험에서 나온 내용으로 교체하십시오.

신뢰도 감사 (The Confidence Audit)
제한 조건(qualification)이 없는 모든 단정적인 진술(declarative statement)을 식별하십시오. 회의적인 전문가와 직접 대화할 때, 당신의 신뢰도를 걸고 그 진술을 할 수 있는지 스스로에게 물으십시오. 그 정도의 확신을 가지고 입 밖으로 내뱉지 못할 내용이라면, 완곡한 표현(hedge), 주의 사항(caveat), 또는 삭제가 필요합니다.

변화 취약성 점검 (The Change Fragility Check)
문서화(Documentation)를 위해 구체적으로 제안하자면: 각 섹션에 대해, 어떤 제품 결정(product decision)이 이 섹션을 틀린 것으로 만들 것인지 자문해 보십시오. 만약 답할 수 없다면, 당신은 해당 내용을 배포(ship)할 수 있을 만큼 충분히 이해하지 못한 것입니다. 만약 답할 수 있고 그 결정이 향후 6개월 내에 일어날 법한 일이라면, 해당 섹션을 정기 검토 대상으로 표시(flag)하십시오.

목소리 차이 점검 (The Voice Delta Check)
도움 없이 직접 작성한 문단 하나를 AI 출력물 문단 옆에 붙여넣으십시오. 그리고 두 문단을 소리 내어 읽어보십시오. 만약 두 문단이 서로 다른 사람처럼 들린다면, 그 차이(delta)가 좁혀질 때까지 AI 콘텐츠를 수정해야 합니다. AI의 버전을 더 "나은" 것으로 받아들이지 마십시오. 그것을 가공되지 않은 재료(raw material)로 받아들이십시오.

유지보수 의지 테스트 (The Maintenance Commitment Test)
기반이 되는 제품이 변경될 때, 이 콘텐츠의 모든 문장을 수동으로 업데이트할 의사가 있습니까? 만약 아니라면, 당신은 유지보수할 수 있는 능력보다 더 많은 콘텐츠를 생성한 것입니다. 배포하기 전에 삭제하십시오.

AI Handler의 접근 방식

AI Handler는 단순한 전제 위에 구축되었습니다: AI 생성 콘텐츠의 문제는 AI 자체가 아니라, 관리되지 않는 AI라는 점입니다. 콘텐츠를 위해 AI를 사용하는 대부분의 빌더(builders)들은 프롬프트(prompt)에 대한 버전 관리(version control) 없이, 출력물 간의 일관성 점검(consistency checks) 없이, 그리고 무엇이 생성되었고 무엇이 수정되었으며 무엇이 처음부터 인간이 작성했는지 감사(audit)할 방법도 없이 작업하고 있습니다.

AI Handler는 프롬프트를 버전이 관리되는 산출물(versioned artifacts)로 취급하고, 모든 출력물과 함께 모델 및 파라미터(parameter) 컨텍스트를 추적하며, 기반 모델이 변경될 때 일관성 드리프트(consistency drift)를 드러내는 통합 AI 워크플로우(workflow) 도구입니다. 이는 단순히 더 빠른 초안을 원하는 캐주얼한 사용자가 아니라, 재현성(reproducibility)을 신경 쓸 정도로 AI를 진지하게 사용하는 빌더들을 위해 설계되었습니다.

이 도구는 당신을 대신해 목소리(voice) 문제를 해결해주지 않습니다. 당신이 직접 앉아서 작업하는 것 외에는 그 무엇도 해결할 수 없습니다. AI Handler가 하는 일은 당신의 AI 생성 콘텐츠가 표류하고 있는지, 모델 업데이트에 따라 프롬프트가 일관되지 않은 출력을 생성하고 있는지, 그리고 당신의 문서에 해결되지 않은 유지보수 부채(maintenance debt)가 어디에 쌓여 있는지를 알 수 있는 인프라(infrastructure)를 제공하는 것입니다.

제가 이것을 만들고 있는 이유는 저에게 필요했기 때문이며, 기존에 존재하지 않았기 때문입니다. 이 포스트에서 설명된 모든 문제는 AI Handler 백로그(backlog)에 로그 항목으로 기록되어 있습니다.

AI Handler는 제가 구축하고 있는 통합 AI 워크플로(workflow) 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스 권한을 원하시면 ceo@eternalsix.com으로 이메일을 보내주세요.