AI가 쓴 글, 읽는 사람이 30% 더 느리다… 작성자 편의가 독자 부담으로

개발자 디마가 개인 블로그에 올린 글이 해커뉴스에서 77점, 댓글 52개를 모으며 화제가 됐습니다. 학사 논문으로 저자 식별 시스템을 만들었던 그가 AI 글쓰기의 구조적 문제를 짚었습니다.

핵심은 세 가지입니다. 첫째, AI는 문체를 평균화합니다. 누가 썼는지 알 수 없게 만들고, 공감을 어렵게 합니다. 둘째, 정밀도가 떨어집니다. 프롬프트를 자세히 줘도 AI는 문장을 잇기 위해 모호한 단어를 고릅니다. 작성자는 자기 머릿속 생각이 명확하니 모호함을 못 봅니다. 셋째, 생각이 종이에 적히는 과정에서 생기는 검증 기회가 사라집니다. 글쓰기는 생각의 도구인데, AI가 결과를 바로 내놓으니 그 과정을 건너뜁니다.

읽는 사람이 치르는 숨은 비용

디마는 자신이 AI 생성 텍스트를 읽을 때 최소 3분의 1 더 느리다고 적었습니다. 길이가 같아도 문맥 단서가 부족해 모호한 단어를 풀어내느라 시간이 더 걸립니다. 대다수 모델이 지나치게 장황해 총 독해 시간은 더 늘어납니다.

작성자가 10분 아껴도 독자 10명이 각각 3분씩 더 쓰면 이미 손해입니다. 공동 작업이면 질문과 수정 라운드가 늘어나고, 독자와 작성자 사이 신뢰도 떨어집니다. 이차 효과까지 더하면 작성자 편의가 독자 부담으로 전가되는 구조입니다.

해커뉴스 댓글 중 하나는 이 점을 찌릅니다. "작성자가 시간과 노력을 들였다는, 지금까지 거의 깨지지 않던 전제가 무너졌다"는 지적입니다. 또 다른 댓글에서는 실제 프로젝트에서 AI가 생성한 기획 문서들이 서로 모순되고 이해 불가능해, 엔지니어링 팀이 헛수고한 사례가 등장합니다.

앞서 본지가 다룬 논쟁과 맞닿아 있습니다

본지가 43일 전 다룬 AI에게 글쓰기를 맡기면 내 생각이 사라질까에서는 한 개발자가 "AI로 글 쓰지 않겠다"며 공개 다짐한 사례를 전했습니다. 당시 논쟁은 생각의 주체성에 집중됐습니다. 이번 디마의 분석은 그 논점을 독자 측 비용으로 확장한 셈입니다.

당시 댓글에서도 "생각을 글로 정리하는 과정이 곧 생각"이라는 반론이 많았습니다. 디마가 지적한 '종이에 적으며 모순을 발견하는 과정'과 정확히 일치합니다. 두 글 모두 글쓰기를 도구가 아닌 사고 과정으로 보는 시각을 공유합니다.

쉽게 풀어보면

디마는 원래 글쓴이를 문체 통계로 찾아내는 프로그램을 만든 개발자입니다. 그는 AI 글을 뷔페에 비유합니다. 누가 요리했는지 모르는 음식이 식탁에 올라옵니다. 맛은 무난한데, 내 취향도 요리사 의도도 알 수 없습니다.

사람이 쓴 글에는 그 사람의 습관, 고민, 상황이 배어 있습니다. 오타 하나, 문장 호흡 하나에도 맥락이 있습니다. AI는 그런 맥락을 평균값으로 납작하게 만듭니다. 읽는 사람은 '이 사람이 왜 이 말을 했을까'를 추측할 단서를 잃습니다.

정밀도도 비슷합니다. 친구에게 편지 쓸 때 우리는 조심스럽게 단어를 고릅니다. AI는 '논리적 실수만 안 하면 된다'는 식으로 애매한 단어를 씁니다. 작성자는 자기 생각이 분명하니 애매함이 안 보입니다. 독자만 '이게 무슨 뜻이지' 하며 헤맵니다.

가장 큰 차이는 쓰는 과정입니다. 생각을 글로 옮기다 보면 "어? 내 논리에 구멍이 있네" 하고 발견합니다. AI에게 맡기면 이 검증 단계를 건너뜁니다. 결과물만 받고 과정은 생략되는 겁니다.

디마 말대로라면 AI 글 읽기는 안개 낀 창문으로 풍경 보기와 같습니다. 같은 거리인데 30% 더 걸립니다. 작성자 한 명이 10분 아껴도 독자 열 명이 각각 3분 더 쓰면 전체로는 손해입니다. 회의록, 기획안, 이메일… 독자가 많은 문서일수록 비용은 기하급수적으로 커집니다.

나에게 미치는 영향

오늘 당장 챗GPT·클로드·제미나이에서 확인해 볼 수 있는 것 세 가지입니다.

• 중요 메일·보고서는 AI 초안을 그대로 보내지 마세요. 한 번 읽고 "이 문장이 무슨 뜻인지 독자가 바로 알까?" 자문해 보세요. 모호한 표현을 구체적 단어로 바꿔주는 편집만으로도 독해 시간은 크게 줄어듭니다.
• AI로 초안 잡을 때 '내 생각이 빠진 부분'을 표시해 두세요. 나중에 그 부분만 직접 채워 넣으세요. 생각이 글이 되는 과정에서 발견되는 모순을 놓치지 않으려면, 완전히 맡기지 말고 공동 작업으로 쓰세요.
• 받은 글이 AI 티가 난다면(너무 장황하거나, 문체가 평평하거나) 작성자에게 "이 부분만 다시 써줄래요?"라고 물어보세요. 서로 시간 아끼는 길입니다. 앞서 다룬 기사 댓글에서도 "AI를 도구로 쓰되 판단은 내가 한다"는 원칙이 가장 많은 공감을 얻었습니다.

논쟁의 두 축: 효율 vs 신뢰

찬성 쪽은 "반복 업무 자동화로 본질적 사고에 집중할 수 있다"며 효율을 내세웁니다. 반대 쪽은 "글쓰기 자체가 사고 과정인데, 그걸 건너뛰면 생각도 얕아진다"며 주체성을 강조합니다. 디마의 분석은 여기에 독자 비용이라는 제3의 변수를 추가했습니다.

사실 다툼은 적습니다. 양쪽 모두 "AI 글이 장황하다", "문체가 평평하다"는 점은 인정합니다. 갈리는 건 어느 비용을 감수할 것인가입니다. 작성자 시간 vs 독자 시간, 속도 vs 정밀도, 편의 vs 신뢰. 이 트레이드오프를 어디서 끊을지가 조직마다, 개인마다 다릅니다.

남은 쟁점: 측정 가능한 기준이 없다

디마도 "개인적으로 3분의 1 느리다"고 했을 뿐, 통제된 실험 데이터는 없습니다. 해커뉴스 댓글에서도 "주관적 체감일 뿐"이라는 반론이 나옵니다. 독해 속도 저하를 정량화한 연구가 필요합니다. 또, 모델별·프롬프트별 편차도 큽니다. "AI 글"을 하나로 묶어 비판하기엔 스펙트럼이 넓습니다.

조직 차원에서는 문서 종류별 가이드라인이 시급합니다. 고객 대응 메일은 AI 초안 금지, 내부 메모는 허용 같은 식입니다. 국내 기업들이 'AI 사용 여부 표기'를 문서 템플릿에 넣기 시작했다는 주장은 본지가 확인하지 못했습니다. 투명성이 신뢰 비용을 낮추는 최소한의 장치로 보입니다.

작성자 편의가 독자 부담으로 전가되지 않으려면, 누가 읽을 것인가를 먼저 물어야 합니다. 디마의 글이 던진 질문이 그것입니다. "이 글을 읽을 사람이 내 시간을 아껴준 대가로 더 많은 시간을 쓰게 되는 건 아닐까."