내가 읽기 쉬운 AI 출력이 남에게도 좋은 글은 아니다

TL;DR

• AI에 질문한 사람은 출력의 배경을 알지만 전달받은 독자는 모른다. 변경 사항을 빠짐없이 나열해도 목적과 위험, 검토할 지점이 없으면 읽는 사람이 맥락을 복원해야 한다. 문서의 완성도는 생성된 정보량만으로 판단할 수 없다.
• 668명이 참여한 기술 블로그 독자 대상 익명 설문에서 78%는 AI 글로 의심되면 읽기를 멈춘다고 답했다. 71%는 이후 그 저자를 피하고 98%는 저자 자신의 문장을 선호했다. 자발적 참여자의 응답이므로 전체 개발자의 실제 행동 비율로 일반화할 수는 없다.
• 브렉은 논문을 직접 쓰면서 AI에 사실 확인과 교정, 인용 정리와 도표 작성을 맡겼다. 반대로 문단 자체를 생성하게 했을 때는 같은 만족을 얻지 못했다. 다만 이미 완성한 작업을 압축하는 초록은 AI가 쓴 것을 그대로 채택했다.
• 글을 쓰는 과정에는 생각을 다듬고 관계를 맺으며 불확실성을 견디는 일이 포함된다. 기술 문서에도 결론에 도달한 과정과 작성자의 판단이 필요하다. 요약하기 쉬운 질문만 반복하면 무엇을 묻고 관찰할지까지 도구에 맞추게 될 위험이 있다.

설계 문서가 완성품의 설명서로 바뀔 때

Colin Breck이 문제 삼는 장면은 AI로 소프트웨어를 만든 뒤 다시 AI로 그 결과를 설계 문서처럼 정리하는 일이다. 설계 제안서는 원래 다른 사람과 합의를 만들고 아이디어를 천천히 고치는 과정에 쓰인다. 이미 구현한 내용을 사후에 길게 나열하면 검토자는 결정에 참여하기보다 완성품을 따라잡는 사람이 된다. 동작하는 결과물이 있다는 이유로 문서를 읽지 않는 동료를 재촉하면 이 간극은 더 커진다.

풀 리퀘스트에서도 변경 목록과 검토에 필요한 설명은 다르다. 무엇을 나누거나 합쳤는지와 어떤 테스트를 추가했는지는 자세해도 변경 이유와 가치, 위험도와 긴급성, 의견을 구하는 지점은 빠질 수 있다. 독자는 모든 줄을 살펴보며 중요도를 스스로 추정해야 한다. 그렇다고 모든 작업에 설계 문서가 먼저 필요하다는 주장은 아니다. 브렉은 실제 동작하는 소프트웨어를 중심으로 빠르게 협업하는 편이 합의 형성에 더 적합한 경우도 인정한다.

작성자가 생략한 맥락을 독자가 떠안는다

AI에 프롬프트를 넣은 사람은 이미 목적과 제약을 정했고 문서나 코드, 로그 같은 자료도 골라 제공했다. 어떤 응답이 왜 나왔는지 알기 때문에 출력을 훑으며 쓸 부분과 틀린 부분을 빠르게 가려낼 수 있다. 같은 텍스트를 전달받은 사람은 이 과정에 참여하지 않았다. 작성자에게 편리한 출력이 독자에게도 이해하기 쉬운 글이라는 보장은 없다.

관계가 걸린 글에서는 매끈한 문장보다 작성자의 판단과 감정이 중요해진다. 브렉은 민감한 문제를 조심스럽게 전하려고 AI로 다듬은 개인 메시지에서 오히려 비인격적이고 연결되지 않는 문장들을 경험했다. 자신이 남긴 의견을 AI로 요약해서 답장한 사례와 기존 합의 문서를 함께 고치는 대신 새 위키 페이지를 만든 사례도 같은 불만으로 이어진다. 상대와 직접 조율하는 수고와 관계의 위험을 피하면서 텍스트만 늘려서는 대화에 참여한 셈이 되지 않는다.

독자가 거부하는 것은 문법 오류만이 아니다

Cynthia Dunlop의 연결 설문은 X와 Bluesky, LinkedIn에서 참여자를 모집해 익명 응답 668개를 받았다. 기술 블로그가 AI의 도움을 받았거나 AI가 쓴 것 같을 때 어떻게 반응하는지 묻는 복수 선택 문항에서 78%는 즉시 읽기를 중단하고 71%는 이후 저자를 피한다고 답했다. 별도의 선호 문항에서는 98%가 어색한 표현이나 문법 문제가 있어도 저자가 직접 쓴 글을 골랐다. 비원어민의 번역·언어 보조라는 사정을 알면 다르게 반응하겠다는 응답은 23%였다.

이 수치는 독자가 실제 AI 사용 여부를 정확히 판별했다는 증거는 아니다. 설문은 AI가 쓴 것 같다는 인상에 대한 자기 보고이며 익명 참여자의 직업도 보장하지 않는다. 자발적으로 참여한 기술 블로그 독자층의 반응을 전체 독자의 이탈률로 바꾸어 읽으면 안 된다. 다만 브렉이 중시하는 저자 고유의 관점과 신뢰가 독자 선택에 어떻게 연결되는지를 살펴볼 구체적인 자료는 된다.

직접 쓴 문장을 검증하게 했을 때

브렉은 자신이 만든 데이터베이스를 설명하는 논문을 LaTeX로 쓰면서 AI를 적극적으로 활용했다. 투고 형식과 템플릿, 기존 논문, 시스템 소스 코드와 운영 설정, 로그와 지표를 맥락으로 제공했다. 문단을 쓴 뒤 데이터베이스의 인덱스 대상 열이나 Parquet 파일의 정렬 방식이 맞는지 확인하게 하고 자신은 다음 문단으로 넘어갔다. 이 순서는 글쓰기 흐름을 유지하면서 빠진 내용과 부정확한 설명을 찾는 데 도움이 됐다.

인용할 자료를 표시해 두면 AI가 BibTeX 정보를 채웠고 철자와 문법, 길거나 모호한 문장을 점검했다. TikZ 기술 도표를 그리는 작업도 맡겼다. LSM의 기존 명칭인 Gen1·Gen2·Gen3을 논문에서 L0·L1·L2로 바꾸는 과정에서는 L2여야 할 곳을 L1로 쓴 오류를 AI가 찾아냈다. 시스템을 잘 아는 사람 검토자 4명이 놓친 오류였다는 점은 구체적인 효용 사례지만 일반적인 검토 정확도 비교 실험은 아니다.

같은 자료를 주고 문단을 처음부터 쓰게 하는 역순의 작업에는 브렉이 만족하지 못했다. 블로그 편집에서도 오류 지적과 수정 제안을 받되 자신의 목소리와 관점을 통째로 바꾸는 재작성은 허용하지 않는다. 예외는 논문의 초록이다. 이미 만들어진 연구를 짧고 정형화된 문장으로 압축하는 초록은 AI 출력 그대로 채택했다. 글을 한 줄도 맡기지 않았다는 앞부분의 표현은 이 예외와 함께 읽어야 한다.

명료한 설명과 요약으로 남지 않는 판단

브렉은 AI 글쓰기를 개선할 가능성도 닫지 않는다. 검토하려는 방법 중 하나는 제한된 어휘와 문법·문체 규칙을 사용하는 ASD-STE100 Simplified Technical English다. 적용 대상으로 떠올린 것은 설치 안내와 런북처럼 명료한 지시가 중요한 문서이며 모든 종류의 글에 적합하다고 보지는 않는다. 또 다른 관심사는 AI 글 탐지 도구 Pangram이다. Bryan Cantrill은 Oxide의 공개 글에 이 도구의 인간 작성 판정을 요구하는 정책을 설명했지만 자신의 사용 경험에 근거한 평가이며 탐지 결과가 저작 과정을 확정하는 증거는 아니다.

운영과 장애 대응, 제품 개발과 성능 분석에도 불확실한 상황에서 관계를 찾아가는 과정이 있다. 브렉의 관점에서는 사실과 결론뿐 아니라 무엇을 관찰하고 왜 의심했는지에 관한 서사가 그 작업을 이해하는 데 중요하다. 시나 문학에서 드러나는 간접적인 의미의 문제도 기술 업무와 완전히 분리되지 않는다. 많은 정보를 한데 요약하는 능력만 보고 AI를 뛰어난 시스템 사고의 주체로 받아들이면 관찰자의 경험과 판단이 빠지는 차이를 놓칠 수 있다.

Simon Sarris의 요약 비판을 따라가면 도구의 영향은 결과물에서 끝나지 않는다. 요약을 받아들이는 동안 복잡한 관계를 자기 머릿속에서 구성할 기회를 건너뛸 수 있고 도구가 답하기 좋은 질문에 익숙해질 수도 있다. 잘 정리된 답을 더 많이 얻는 동시에 애초에 묻지 않게 된 질문이 생기는 셈이다. 브렉이 지키려는 글쓰기에는 불완전한 표현을 감수하며 자기 관찰을 정리하고 상대에게 무엇이 중요한지 직접 판단해 전달하는 과정이 포함된다.

참고 자료

Colin Breck — I Don’t Want to Read What You Didn’t Write

Cynthia Dunlop — Report: How developers react to AI-scented blog posts

Bryan Cantrill — The revolt of the reader