당신이 쓰지 않은 글은 읽고 싶지 않다 — 생성 비용과 읽기 비용의 비대칭
당신이 쓰지 않은 글은 읽고 싶지 않다 — 생성 비용과 읽기 비용의 비대칭
AI가 쓴 글이 거부당하는 이유는 품질 때문인가, 아니면 그 글이 더 이상 아무것도 보증하지 않기 때문인가?
도입
2026년 9월 21일(UTC) 해커뉴스에 Colin Breck의 에세이 「I Don’t Want to Read What You Didn’t Write(당신이 쓰지 않은 글은 읽고 싶지 않다)」가 올라왔고, 1,070점을 받았다. 블로그 게시일은 9월 20일이다. 이틀 전인 9월 19일에는 Erich Grunewald의 「I think you should almost never use AI to write(AI로 글을 쓰는 일은 거의 언제나 하지 말아야 한다고 생각한다)」가 363점을 받았다. 같은 주에 같은 주장을 하는 글이 연달아 1면에 오른 셈이다. 해커뉴스의 한 이용자(idreyn)는 최근 며칠 사이 비슷한 내용의 블로그 글이 작은 흐름처럼 올라오고 있고 자신은 그 글들을 모두 즐겁게 읽었다고 적었다(직접 인용은 아니고, 코멘트의 요지를 요약).
Breck의 첫 문장은 관찰이다. 예전에는 독창적인 글을 거의 쓰지 않던 사람들이 이제 설계 제안서, 사업 계획서, 문서, 프레젠테이션, 티켓, 풀 리퀘스트, 블로그 글, 회의록을 대량으로 만들어 내는데, 모두 AI가 생성한 것이고 모두 읽을 수 없다는 것이다. 그런데 같은 글에서 그는 AI가 자신의 글쓰기를 더 낫고 빠르게 만들어 준다고도 말한다. 이 글은 AI 거부론이 아니다. AI를 쓰는 방향이 어느 쪽을 향하느냐에 관한 글이다.
이 글에서는 Breck과 Grunewald의 주장을 원문에 근거해 정리하고, 해커뉴스 토론에서 나온 반론까지 포함해 하나의 질문으로 좁혀 본다. 생성은 거의 공짜가 되었는데 읽기는 여전히 비싸다. 이 비대칭이 글이라는 매체의 계약을 어떻게 바꾸고 있는가.
현상 분석 — 「읽을 수 없는」 글은 어디서 생기는가
Breck이 드는 사례는 구체적이다. 첫 번째는 설계 문서다. 사람들이 AI로 무언가를 먼저 만들고, 그다음 이미 만든 것을 AI로 사후 요약해 설계 문서로 만든다. 그는 이런 문서를 읽는 일이 어렵기만 한 것이 아니라 「징벌적」이라고 쓴다. 설계 문서는 원래 합의를 만들고, 사람들을 함께 데려가고, 느리고 신중한 사고로 아이디어를 다듬기 위한 제안이었다. 그런데 이제 그것은 기계가 만든, 맥락도 관점도 없는, 지칠 만큼 상세한 요약이 되었다. 더 곤란한 것은 저자들이 동료가 관심을 보이지 않으면 조바심을 낸다는 점이다. 동료 입장에서는 관심을 갖기 어렵다. 만든 것은 이미 돌아가고 있기 때문이다.
두 번째는 풀 리퀘스트 요약이다. Breck은 기계가 기계를 위해 쓴 것이 분명한 PR 설명이 늘고 있다고 말한다. 이것을 저것으로 바꿨고, 이것들을 나눴고, 저것들을 합쳤고, 이것은 건드리지 않았고, 테스트를 추가했다는 식의 세부 사항은 풍부하다. 하지만 정작 리뷰어가 알고 싶은 것은 빠져 있다. 왜 이 작업을 하는가. 가치는 무엇인가. 얼마나 위험하고 급한가. 어디에 내 의견이 필요한가. 무엇에 주의해야 하는가. 그는 이런 글을 「맥락 바깥의 진술들」이라고 부른다.
해커뉴스 토론에서 이 지점은 가장 실무적인 공감을 얻었다. 한 이용자(zmmmmm)는 설명이 너무 많다는 이유로 PR을 반려한다고 썼다. 20줄짜리 변경에 생성된 설명이 몇 페이지씩 붙어 있고, 왜 안전한지에 대한 합리화, 설계 결정마다의 변호, 위험과 부작용 분석이 따라온다. 작성자는 「문서가 너무 많다고 거절하느냐」며 분개하지만, 그의 답은 이렇다. 그걸 읽을 시간이 없는데, 승인한다는 것은 읽고 받아들였다는 뜻이 되므로 읽지 않을 수도 없다. 자기가 프롬프트 한 번이면 할 수 있는 코드 변경의 가치에 비해 그 독해 비용이 너무 크다는 것이다(직접 인용은 아니고, 코멘트의 요지를 요약).
이 코멘트는 문제의 구조를 정확히 드러낸다. 승인은 서명이다. 서명에는 「나는 이것을 읽었다」는 주장이 포함된다. 글의 양이 늘수록 그 주장을 정직하게 유지하는 비용이 리뷰어 쪽으로 넘어간다. 작성자는 생성 버튼 하나로 페이지를 늘렸고, 그 페이지를 소화하는 비용은 전부 상대방이 진다.
세 번째 사례는 더 개인적이다. Breck은 민감한 주제에 관해 누군가가 보낸 개인 메시지를 받았는데, 자신을 불쾌하게 하지 않으려고 AI와 함께 다듬은 것이 분명했다고 쓴다. 결과는 비인격적이고 감정이 없으며 이음새가 맞지 않는 글이었다. 부분은 다 갖췄지만 전체로는 말이 되지 않았다. 그는 차라리 상대가 자기 목소리로, 단어를 잘 찾지 못하더라도, 혹은 자신을 불쾌하게 할 위험을 감수하더라도 썼으면 했다고 말한다. 관계에는 취약함과 위험이 있는데, AI와의 소통에는 그것이 없고, 취약함과 위험을 제거하려는 시도는 관계라는 과정 자체를 제거한다는 것이 그의 진단이다.
그가 「가장 게으르고 모욕적인 사용」으로 꼽은 사례는 이렇다. 누군가의 제안서에 그가 코멘트를 달았더니, 상대가 그 코멘트를 AI로 요약해서 자신에 대한 답장으로 보냈다. Breck은 「고맙다, 나도 그보다 잘 말할 수는 없었을 것」이라고 비꼰다.
독자 반응에 대한 데이터도 인용된다. Breck은 Cynthia Dunlop이 공유한 설문 결과를 들며, 다수의 독자가 글이 AI의 도움을 받았거나 AI가 썼다고 생각하면 읽기를 멈추고(78%), 이후 그 저자를 피한다(71%)고 전한다. 가장 강한 결과는 결점과 개성을 포함한 저자 본인의 글을 AI의 재작성보다 압도적으로 선호한다는 응답(98%)이었다고 한다. 다만 이 수치는 Breck의 글을 통해 간접적으로 확인한 것이고, 설문의 표본과 방법은 이 글에서 직접 검증하지 못했다. 개발자 대상 블로그 독자라는 특정 집단의 반응으로 읽는 것이 안전하다.
심층 분석 — 맥락은 프롬프트를 쓴 사람에게만 있다
Breck의 글에서 가장 날카로운 부분은 왜 AI 출력이 작성자에게는 유용하고 독자에게는 읽을 수 없는지를 설명하는 대목이다. AI에 프롬프트를 준 사람에게 그 출력은 꽤 쓸모가 있다. 하지만 그것을 효과적인 글쓰기로 착각해서는 안 된다는 것이 그의 경고다.
출력을 읽을 때 작성자는 이미 많은 맥락을 갖고 있다. 프롬프트를 구성했고, 제약을 정했고, 문서와 소스 코드, 로그, 통계, 그림 같은 자료를 제공했다. 그래서 출력을 훑어보고 무엇이 관련 있고 가치 있는지, 무엇이 무관하거나 틀렸는지를 빠르게 가려낼 수 있다. 작성자는 과정의 일부이기도 하다. 묻고 답을 보는, 부름과 응답의 과정이다. 그런데 같은 텍스트를 다른 사람에게 보내면 그 사람에게는 맥락이 거의 없다. 펼쳐지는 과정에 참여하지 않았으므로 무엇이 중요하고 무엇이 아닌지 판단하기가 훨씬 어렵다. 그래서 모든 줄을 철저하게 읽고 고려해야 한다. 맥락을 얻기 위해 기계의 내부를 들여다보는 셈이다. 읽기를 멈추는 것은 자연스러운 반응이다.
이 설명을 비용의 언어로 바꿔 보면 비대칭이 선명해진다. 생성 비용은 0에 가까워졌다. 그러나 읽는 쪽의 비용은 줄지 않았고, 오히려 늘었다. 맥락이 빠진 상세함은 독자에게 「어디가 중요한지」를 스스로 재구성하라고 요구하기 때문이다. 작성자가 출력을 훑어볼 수 있는 것은 그 출력을 걸러낼 필터, 즉 맥락을 이미 머릿속에 갖고 있어서다. 독자는 그 필터 없이 같은 텍스트를 받는다.
해커뉴스 최상위 코멘트(hatthew)는 이를 정보량으로 설명했다. 글쓰기는 근본적으로 작성자의 뇌에서 독자의 뇌로 정보를 옮기는 일이다. 전하고 싶은 의미 정보가 1,000비트라면, LLM에 300비트만 주고 나머지 700비트를 채우게 할 수는 없다. LLM은 그 700비트가 무엇인지 모르기 때문이다. 만약 LLM이 그 700비트를 정확히 추측할 수 있다면 그것은 진짜 의미 정보가 아니며, 실제로 전할 것은 300비트뿐이었다는 뜻이다. 그렇다면 그 300비트를 독자에게 직접 주는 편이 낫다. 독자가 걸러내야 할 불필요한 700비트를 덧붙일 이유가 없다(직접 인용은 아니고, 코멘트의 요지를 요약).
이 논리는 단순하지만 강력하다. 생성된 문장 중 프롬프트로부터 예측 가능한 부분은 독자에게 새로운 정보가 아니다. 예측 불가능한 부분은 작성자의 의도와 무관한 모델의 추측이다. 어느 쪽이든 독자는 손해를 본다. 앞의 것은 시간 낭비이고, 뒤의 것은 작성자가 주장하지 않은 내용을 작성자의 이름으로 받는 것이다.
Grunewald의 글은 같은 문제를 「사고」의 측면에서 다룬다. 그는 세 가지 이유를 든다. 글쓰기 과정이 사고 과정의 핵심이라는 것, AI의 글은 알아차리기 어려운 방식으로 모호하고 틀린다는 것, 그리고 AI로 쓴 글을 표시 없이 내보내는 것은 무례하고 오해를 부른다는 것이다. 두 번째 논점에서 그는 실제 실험을 보여 준다. Claude Fable 5에 AI 칩 밀수 문제를 소개하는 짧은 단락을 써 달라고 하고, 그 출력을 한 문장씩 해부한다. 「수출 통제는 집행만큼만 강하다」는 문장은 뻔한 말이거나 아무 말도 아니다. 칩이 「소형」이라는 묘사는 사실이지만 실제로 밀수되는 것은 대개 소형이 아닌 AI 서버이고, 밀수는 주로 숨기기보다 다른 품목으로 라벨을 바꿔 공공연히 운송된다. 규모 추정치를 「수만에서 10만 이상까지 다양하다」고 쓴 부분은 문자 그대로는 맞지만, 그의 판단으로는 낮은 추정치는 거의 확실히 틀렸으므로 오해를 부른다. 그가 보기에 출력은 「나쁘지 않고 꽤 그럴듯하기까지」 하지만, 작은 단어 선택마다 조금씩 틀어져 있다.
이 해부가 보여 주는 것은 품질의 문제가 아니라 책임의 문제다. 그럴듯한 단락의 각 문장에 대해 「이것이 정확히 무슨 뜻인가」를 물을 수 있는 사람은 그 문장을 쓴 사람뿐이다. AI가 쓴 문장은 그 질문에 답할 주체가 없다. Grunewald는 그래서 독자와 저자 사이에 암묵적 계약이 있다고 말한다. 독자는 주의를 내주고, 저자는 그 대가로 가치 있는 것을 돌려준다. 글이 AI로 쓰였다는 것을 알아차리는 순간, 독자는 저자가 그 글에 생각을 얼마나 들였는지 알 수 없게 되고, 그래서 신뢰가 즉시, 그리고 합리적으로 떨어진다고 그는 쓴다.
Breck이 인용한 Bryan Cantrill의 문장도 같은 계약을 가리킨다. LLM으로 글을 쓰는 것은 작성자와 독자 사이의 사회적 계약을 무효로 만드는 일이며, 작성자 자신이 공들여 만들지 않은 문장을 독자가 애써 이해하리라 기대해서는 안 된다는 것이다. Breck에 따르면 Cantrill은 AI 생성 글 탐지 모델인 Pangram을 실험하기 시작했고, Oxide의 모든 공개 글이 Pangram에서 사람이 쓴 것으로 판정되도록 의무화하기까지 했다.
전망과 시사점 — AI가 정당한 자리와 신뢰가 깨지는 자리
흥미롭게도 Breck은 AI를 글쓰기에 광범위하게 쓴다. 그는 최근 학술 논문을 썼는데 AI 덕분에 과정이 더 빠르고 즐거웠다고 말한다. 하지만 논문의 한 줄도 AI가 쓰지 않았다. 그는 LaTeX로 직접 썼고, AI에게는 학술지 스타일 가이드와 템플릿, 그 학술지에 실린 기존 논문들, 논문이 다루는 소프트웨어의 소스 코드, 프로덕션 배포의 설정과 로그, 지표를 맥락으로 주었다.
그가 AI를 쓴 방향은 일관된다. 단락을 하나 쓰고 나면 AI에게 소스 코드나 설정, 로그를 참조해 그 내용이 맞는지 검증하게 했다. 예컨대 데이터베이스의 어느 컬럼에 인덱스가 걸려 있는지, Parquet 파일의 행이 어떻게 정렬되는지를 올바르게 서술했는지 확인하는 식이다. 그동안 그는 다음 단락으로 넘어갔다. 인용 정보를 채우는 일도 맡겼다. 본문에 {TODO: reference the Amazon Aurora paper} 같은 지시를 남겨 두면 AI가 BibTeX 항목을 처리했다. 맞춤법과 문법 오류를 찾는 데는 「무자비할 만큼」 뛰어났고, 너무 길거나 불명확한 문장을 단순화하는 제안도 좋았다. TikZ로 기술 도식을 그리는 일도 맡겼다. 심지어 전문가 리뷰어 네 명이 모두 놓친 표기 오류, 즉 LSM의 레벨을 L2라고 써야 할 곳에 L1이라고 쓴 실수를 AI가 찾아냈다.
반대 방향은 어땠는가. 그가 준 맥락으로 AI에게 단락을 쓰게 하는 것, 예컨대 소스 코드로부터 어떤 것의 동작 방식을 설명하게 하는 것은 한 번도 가치가 없었다고 그는 쓴다. 읽기에 일관되게 불쾌했고 종종 부정확했다. 예외는 하나였다. 초록(abstract)이다. 논문에서 가장 간결하고 기계적이며 비인간적인 부분, 말 그대로 가장 추상화된 부분을 AI는 아주 잘 썼고, 그는 그것을 수정 없이 실었다.
이 경험에서 경계선을 하나 그을 수 있다. AI가 검증자, 교정자, 서지 관리자, 작도 도구로 쓰일 때는 사람이 쓴 글의 정확도를 높인다. 이때 텍스트의 주장과 목소리는 여전히 작성자의 것이고, AI는 그 주장이 사실과 맞는지 확인할 뿐이다. 반대로 AI가 주장 자체를 생성하면, 그 텍스트는 작성자의 이름을 달고 있지만 작성자의 사고를 보증하지 않는다. 초록이 예외인 것도 같은 원리로 설명된다. 초록은 이미 사람이 쓴 본문의 요약이라 새 주장을 만들지 않는다. 요약할 원본이 사람의 사고로 채워져 있을 때만 요약은 정직하다.
Grunewald의 선도 거의 같은 곳에 있다. 그는 반AI주의자가 아니라고 밝히며, 음성 전사, 데이터 분석, 정보 검색, 브레인스토밍, 초고에 대한 피드백, 그리고 사람이 하나하나 수락하거나 거절하는 조건의 교열은 괜찮다고 말한다. 반대하는 것은 AI가 텍스트를 쓰는 것이다. AI 출력을 명확히 표시하고 인용하는 것, 예를 들어 「Claude Fable 5에 따르면 이러저러하다」고 적는 것도 대체로 괜찮다고 본다. 독자가 그 부분을 알아서 할인해 들을 수 있기 때문이다.
반론도 있다. 해커뉴스의 한 이용자(gfody)는 AI가 그동안 듣지 못했던 많은 사람에게 목소리를 주고 있다고 반박했다. 모든 사람이 명료한 산문으로 생각하지는 않으며, 자신의 깨달음을 공유 가능한 언어로 꺼내려면 노력이 들거나, AI와 민망할 정도로 긴 반복을 거쳐 「그래, 이게 내가 하려던 말이다」라고 확인할 수 있는 지점에 도달해야 한다는 것이다. 그런 사람들도 그냥 직접 말했으면 더 열정적이고 덜 이음새가 어긋났을 것이라는 생각은 반드시 맞지 않다는 주장이다(직접 인용은 아니고, 코멘트의 요지를 요약). 사실을 다루는 글이라면 사실을 진술하는 방법은 한정되어 있으며, 최신 모델에 이르러서는 사람의 글과 AI의 글을 구별하기도 어려워졌다는 반론(tygon)도 있었다(직접 인용은 아니고, 코멘트의 요지를 요약).
그리고 토론에서 반복적으로 등장한 아이러니가 있다. 여러 이용자(blandcoffee, almondfestival)가 Breck의 글 자체에 있는 「이런 문서를 읽는 것은 단지 어려운 것이 아니라—징벌적이다」라는 문장이 바로 AI 특유의 문형처럼 보인다고 지적했다(직접 인용은 아니고, 코멘트의 요지를 요약). 이 지적은 농담에 가깝지만 실제 문제를 드러낸다. 「AI 냄새」를 문체로 판별하는 순간, 그 판별은 오탐을 낳는다. 대시를 쓰는 사람은 이제 의심받는다. 문체 탐지는 신뢰 문제의 해법이 될 수 없다는 뜻이다. Pangram 같은 도구를 공개 글에 의무화한 Oxide의 시도가 어디까지 유효할지도 아직은 판단하기 이르다.
실무적으로 남는 질문은 팀 규범이다. idreyn은 AI로 글 쓰기를 즐기는 동료들에게 이 문제를 어떻게 꺼낼지가 고민이라고 했다. 「slop」이라는 말은 거칠고 그 자체로 사고를 끊는 상투어이며, 「당신이 쓰지 않은 글은 읽고 싶지 않다」도 더 짧고 격려하는 말, 예컨대 「당신에게서 직접 듣고 싶다」 같은 표현이 필요하다는 것이다(직접 인용은 아니고, 코멘트의 요지를 요약). 이 제안은 문제의 핵심을 짚는다. 규범은 「AI 금지」가 아니라 「누가 무엇을 보증하는가」를 묻는 형태여야 한다. PR 설명이라면 생성된 변경 목록이 아니라 작성자가 직접 쓴 세 문장, 즉 왜 하는지, 무엇이 위험한지, 어디를 봐 달라는지가 요구되어야 한다. 그 세 문장은 프롬프트로 대체할 수 없다. 그것을 알고 있는 사람이 작성자뿐이기 때문이다.
결론
처음의 질문으로 돌아가자. AI가 쓴 글이 거부당하는 이유는 품질 때문인가, 보증의 부재 때문인가. Breck과 Grunewald의 글을 함께 읽으면 답은 후자에 가깝다. Grunewald가 해부한 Claude의 단락은 「나쁘지 않았다」. Breck이 받은 PR 설명은 「세부 사항이 풍부했다」. 문제는 그 텍스트가 무엇을 주장하는지, 그 주장에 누가 책임을 지는지가 보이지 않는다는 데 있었다.
글은 오랫동안 두 가지를 동시에 운반했다. 정보, 그리고 그 정보를 정리하는 데 누군가 시간과 주의를 들였다는 신호다. 생성 비용이 0에 수렴하면서 두 번째 신호가 붕괴했다. 독자는 더 이상 분량에서 노력을 추론할 수 없고, 그래서 모든 줄을 의심하며 읽거나 아예 읽지 않는다. 읽기 비용은 그대로인데, 그 비용을 정당화하던 신호가 사라진 것이다.
Breck의 경험이 보여 준 경계선은 실용적이다. AI가 사람이 쓴 문장을 검증하고 교정하고 정리하는 방향은 독자의 비용을 줄인다. AI가 사람 대신 주장을 생성하는 방향은 독자의 비용을 늘린다. 같은 도구, 반대 방향이다.
당신이 이번 주에 보낸 문서와 PR 설명 가운데, 상대가 「이 부분은 무슨 뜻이냐」고 물었을 때 프롬프트 기록을 다시 열지 않고 답할 수 있는 문장은 몇 개인가.
출처: