읽기 좋은 글

들어가며

AI로 글을 쓰기 시작하면 가장 먼저 좋아지는 것은 속도다. 문장을 금방 만들 수 있고, 어색한 표현도 어느 정도 정리된다. 빈 화면 앞에서 오래 멈춰 있을 일도 줄어든다. 그래서 처음에는 글쓰기 자체가 쉬워진 것처럼 느껴진다.

그런데 글이 빨리 나온다고 해서 잘 읽히는 것은 아니다. 오히려 AI가 도와준 글에서 더 자주 보이는 문제가 있다. 문법은 맞고 정보도 틀리지 않았는데, 이상하게 눈에 잘 안 들어오는 글이다. 읽다 보면 틀린 말은 아닌데 머릿속에서 한 번 더 번역해야 한다.

이 문제가 더 거슬렸던 이유는 내가 원래 지향하던 글쓰기와 반대였기 때문이다. AI를 본격적으로 쓰기 전에도 글을 써왔고, 그때부터 내가 좋아하던 글은 어렵게 꾸민 글이 아니었다. 문장이 화려하지 않아도 술술 읽히는 글, 독자가 다음 문장으로 넘어갈 때 머뭇거리지 않는 글을 좋아했고, 나도 그렇게 쓰고 싶었다.

그런데 AI를 끼고 글을 쓰다 보니 내 글이 점점 다른 방향으로 가고 있었다. 정보는 많아졌지만 읽기는 어려워졌다. 문장은 정돈됐지만 말맛¹은 줄었다. 글 전체는 그럴듯한데, 막상 읽으면 피곤했다.

처음에는 단순히 문장을 짧게 만들면 해결될 문제라고 생각했다. 그런데 다시 보면 그보다 넓은 문제에 가까웠다. 번역투처럼 느껴지는 문장, 글쓴이가 별로 재밌어하지 않는 듯한 태도, 너무 반듯해서 사람 냄새가 빠진 문체가 같이 섞여 있었다. 이번 글은 그 이유를 정리해보려는 글이다.

맞는 말인데 안 읽히는 글

안 읽히는 글이 꼭 틀린 글은 아니다. 오히려 더 자주 만나는 쪽은 맞는 말을 모아뒀는데도 잘 넘어가지 않는 글이다. 문장 하나하나는 그럴듯하고 문단의 순서도 크게 이상하지 않은데, 읽다 보면 어딘가에서 계속 걸린다. 틀렸다고 말하기는 애매하지만, 끝까지 읽는 데 힘이 들어간다.

내가 최근에 쓴 글에서도 그런 문장이 계속 나왔다.

MDX로 넘어가려는 이유가 직접 만든 미니 파이프라인을 줄이려는 것이었는데, 코드블럭에서 다시 원문을 훑고, code fence metadata를 파싱하고, 렌더링 순서에 맞춰 HTML을 끼워 넣으면 구조는 다시 복잡해진다.

내용만 보면 틀린 말은 아니다. MDX로 옮긴 이유도 맞고, 코드블럭을 다시 직접 파싱하면 구조가 복잡해진다는 말도 맞다. 문제는 독자가 이 문장을 읽는 동안 해야 할 일이 너무 많다는 점이다.

먼저 “MDX로 넘어가려는 이유”를 붙잡아야 한다. 그다음 “직접 만든 미니 파이프라인”이 무엇이었는지 떠올려야 한다. 이어서 “원문을 훑고”, “metadata를 파싱하고”, “HTML을 끼워 넣는” 과정을 머릿속에서 순서대로 복원해야 한다. 마지막에야 “그래서 구조가 복잡해진다”는 결론에 도착한다.

문장이 길어서만 문제가 되는 것은 아니다. 문장을 짧게 끊어도 같은 문제가 남을 수 있다.

직접 파싱 경로는 Blog v3의 목적과 맞지 않았다. MDX로 넘어가려는 이유는 직접 만든 미니 파이프라인을 줄이는 데 있었다. 그런데 코드블럭에서 다시 원문을 훑기 시작하면 같은 문제가 반복된다.

이 문장은 앞의 문장보다 짧다. 그래도 완전히 편하게 읽히지는 않는다. “직접 파싱 경로”, “Blog v3의 목적”, “미니 파이프라인” 같은 말이 문장의 뼈대가 되기 때문이다. 독자는 실제 장면보다 추상어를 먼저 만난다.

더 낫게 쓰려면 실제로 사람이 해야 하는 일을 앞에 둬야 한다.

코드블럭을 다시 직접 파싱하면 MDX로 옮긴 이유가 흐려진다. 원문을 다시 읽고, 코드블럭 순서를 맞추고, HTML을 끼워 넣는 코드를 또 유지해야 하기 때문이다.

이 문장은 대단히 멋진 문장은 아니다. 하지만 읽는 사람은 바로 그림을 그릴 수 있다. “원문을 다시 읽는다”, “순서를 맞춘다”, “HTML을 끼워 넣는다”는 동작이 보이기 때문이다. 사소하지만 읽기 좋은 글은 대개 여기서 갈린다. 추상적인 판단보다 독자가 따라갈 수 있는 일을 먼저 보여준다.

AI가 문장을 매끈하게 만들 때 생기는 문제

AI는 대체로 평균적인 설명을 잘 만든다. 문법이 틀리지 않고, 문단도 그럴듯하게 나눈다. 단어도 너무 튀지 않는다. 그래서 초안 단계에서는 도움이 된다.

문제는 AI가 글을 매끈하게 만들면서 구체적인 마찰까지 같이 없애버린다는 점이다. 사람이 쓴 초안에는 이상한 부분이 남아 있다. 말이 덜 다듬어졌거나, 생각이 튀거나, 특정 장면이 과하게 들어가기도 한다. 그런데 바로 그 부분이 글을 읽히게 만들 때가 있다. 글쓴이가 실제로 어디서 막혔는지 보이기 때문이다.

AI가 다듬은 문장은 이런 흔적을 쉽게 지운다. “내가 어디서 헷갈렸는지”보다 “이 문제의 핵심은 무엇인지”를 먼저 말한다. “무엇을 다시 해야 했는지”보다 “구조가 복잡해졌다”고 정리한다. “이 코드를 지우니 페이지가 본문 렌더링까지 알 필요가 없어졌다”보다 “책임 경계를 재정의했다”고 말한다.

이런 문장은 틀리지는 않다. 다만 독자에게 일을 넘긴다. 글쓴이는 구체적인 장면을 추상어로 압축해버리고, 독자는 그 추상어를 다시 장면으로 풀어야 한다. 읽는 사람이 피곤해지는 이유가 여기에 있다.

번역투는 이상한 한국어만의 문제가 아니다

번역투라고 하면 보통 영어 문장을 그대로 옮긴 듯한 표현을 떠올린다. “~에 대한”, “~를 통해”, “~함으로써” 같은 말이 반복되는 문장이다. 물론 그런 표현도 문제일 수 있다. 그런데 내가 더 자주 느끼는 번역투는 문법보다 거리감에 가깝다.

예를 들어 이런 문장은 기술 글에서 흔하게 나온다.

이 기능의 적용을 통해 사용자 경험의 개선을 기대할 수 있다.

틀린 문장은 아니다. 하지만 사람이 무슨 일을 했는지 잘 보이지 않는다. “기능의 적용”, “사용자 경험의 개선” 같은 말이 앞에 서면 글이 갑자기 보고서처럼 멀어진다.

조금 더 자연스럽게 쓰면 이렇게 바꿀 수 있다.

이 기능을 넣으면 사용자가 같은 작업을 한 번 덜 해도 된다.

여전히 대단한 문장은 아니다. 그래도 읽는 사람은 바로 상황을 떠올릴 수 있다. 버튼을 덜 누르거나, 같은 값을 다시 입력하지 않아도 되는 장면이 보인다.

AI가 만든 글은 이 거리감을 쉽게 만든다. 문장을 정리하면서 동사를 명사로 바꾸고, 사람이 하는 일을 “개선”, “적용”, “처리”, “구현” 같은 말로 압축한다. 그러면 문장은 반듯해지지만 말하는 사람은 뒤로 물러난다. 글이 틀린 말을 하지는 않는데, 읽는 사람 입장에서는 자꾸 한 번 더 풀어 읽어야 한다.

한국어가 항상 짧고 구어체여야 한다는 뜻은 아니다. 다만 글이 너무 명사 중심으로 굳어지면, 독자는 실제 장면을 다시 복원해야 한다. 내가 줄이고 싶은 번역투는 바로 이 지점이다. 영어식 표현 하나를 고치는 문제가 아니라, 사람이 한 일을 다시 사람이 한 일처럼 쓰는 것이다.

잘 읽히는 설명문이 하는 일

읽기 좋은 설명문은 친절하기만 한 글이 아니다. 설명을 늘어놓는다고 잘 읽히는 것도 아니다. 오히려 잘 읽히는 글은 독자가 어디에 힘을 써야 하는지 잘 나눠준다.

예를 들어 프로그래밍 입문자가 운영체제를 고르는 글을 생각해보자. 잘 읽히는 글은 “운영체제란 무엇인가”로 시작하지 않는다. 먼저 독자가 실제로 할 법한 고민을 꺼낸다. “프로그래밍을 하려면 리눅스로 바꿔야 하나?” 같은 질문이다.

그다음 흔한 오해를 한 번 인정한다. 리눅스가 서버 개발에서 많이 쓰이는 것은 맞다. macOS가 개발 환경으로 편한 경우도 있다. 하지만 그 말이 곧 입문자가 쓰던 운영체제를 당장 바꿔야 한다는 뜻은 아니다. Windows에서도 WSL이나 Docker를 쓸 수 있고, 대부분의 입문 단계에서는 지금 쓰는 환경으로도 충분한 경우가 많다.

이런 글은 정보가 적어서 읽히는 것이 아니다. 오히려 정보는 많다. 다만 정보가 독자의 질문을 따라 배치되어 있다. 독자는 “내가 뭘 해야 하지?”라는 질문을 놓치지 않는다. 그래서 중간에 사례와 예외가 들어와도 길을 잃지 않는다.

내 블로그 글에도 같은 기준을 적용할 수 있다. “MDX를 도입했다”로 시작하면 독자는 도구 이름부터 받아들여야 한다. 반대로 “Markdown에 기능을 계속 얹다 보니 새 글을 쓸 때마다 예외가 늘어났다”로 시작하면 상황이 먼저 보인다. 그다음에 MDX가 나오면 도구가 아니라 해결책으로 읽힌다.

글쓴이가 재미없으면 글도 쉽게 마른다

읽기 좋은 글을 말할 때 정보 구조만 보면 조금 부족하다. 글에는 글쓴이의 태도도 남는다. 쓰는 사람이 이 주제를 재밌어하는지, 아니면 설명해야 하니까 설명하는지, 생각보다 티가 난다.

기술 블로그를 읽다 보면 중간에 짤 하나가 들어가거나, 갑자기 가벼운 비유가 나오는 글이 있다. 모든 글이 그래야 한다는 뜻은 아니다. 억지로 밈을 끼워 넣으면 그것도 금방 티가 난다. 그래도 그런 장면이 글을 살릴 때가 있다. 글쓴이가 지금 이 이야기를 그냥 전달하는 게 아니라, 자기 나름대로 가지고 놀고 있다는 느낌이 들기 때문이다.

반대로 너무 드라이한 글은 정보가 있어도 오래 붙잡기 어렵다. 문단마다 안전한 말만 하고, 예시는 무난하고, 결론은 예상 가능한 곳으로 간다. 읽고 나면 틀린 내용은 없는데 기억나는 문장도 없다. 글쓴이가 그 글을 쓰면서 어디서 웃었는지, 어디서 짜증났는지, 어디서 “아 이거 좀 이상한데?”라고 느꼈는지가 다 빠져 있기 때문이다.

AI 시대에는 이런 드라이한 글이 더 많아진 것 같다. AI는 평균적인 설명을 빠르게 만든다. 그래서 초안의 바닥은 올라간다. 대신 글쓴이가 일부러 자기 감각을 넣지 않으면, 글은 쉽게 평균으로 수렴한다. 어색하지 않고, 틀리지 않고, 무난하지만 잘 기억나지 않는 글이 된다.

재미있는 글을 쓰려면 반드시 웃겨야 하는 것은 아니다. 짤을 넣어야만 하는 것도 아니다. 다만 쓰는 사람이 이 주제에서 무엇을 재밌게 봤는지는 남아야 한다. 어떤 부분이 이상했는지, 어디서 생각이 바뀌었는지, 어떤 표현이 마음에 안 들었는지 같은 것들이다. 그런 흔적이 있어야 글이 단순한 정보 묶음이 아니라 누군가가 통과한 생각처럼 읽힌다.

읽기 어려움은 인지 부담의 문제이기도 하다

글을 읽는 일은 생각보다 많은 작업을 요구한다. 독자는 단어를 읽고, 앞 문장을 기억하고, 지금 문장이 앞 문장과 어떻게 이어지는지 판단한다. 새로운 개념이 나오면 기존 지식과도 맞춰본다. 이 과정에서 작업기억을 계속 쓴다.

인지부하 이론에서는 작업기억이 한 번에 처리할 수 있는 정보가 제한적이라고 본다.² 그래서 학습 자료는 불필요한 부담을 줄여야 한다. 물론 블로그 글을 수업 자료와 똑같이 볼 수는 없다. 그래도 읽기 어려운 글을 볼 때 생기는 피로를 설명하는 데에는 도움이 된다.

읽기 어려운 글은 독자의 작업기억을 본론이 아닌 곳에 쓰게 만든다. “이 구조”가 무엇을 가리키는지 다시 찾게 한다. “책임 경계”라는 말이 페이지 컴포넌트에서 렌더링 코드를 뺐다는 뜻인지, 다른 파일로 옮겼다는 뜻인지 추측하게 한다. “확장 방식”이라는 말도 컴포넌트를 추가한 건지, Markdown 문법을 늘린 건지, 설정을 분리한 건지 독자가 직접 복원하게 한다.

반대로 읽기 좋은 글은 독자의 부담을 줄인다. 지시어 대신 실제 이름을 다시 써준다. 추상어를 쓰기 전에 예시를 먼저 보여준다. 원인과 결과를 한 문장에 몰아넣지 않는다. 독자가 기억해야 할 단위를 작게 나눈다.

처리 유창성이라는 관점도 비슷한 힌트를 준다. Reber, Schwarz, Winkielman은 사람들이 대상을 더 쉽게 처리할수록 더 긍정적으로 받아들이는 경향이 있다고 설명한다.³ 글도 완전히 다르지 않다. 독자는 내용이 쉬워서만 좋은 글이라고 느끼는 게 아니다. 글을 따라가는 과정이 덜 버거울 때, 그 글을 더 신뢰하고 계속 읽게 된다.

여기서 조심할 점도 있다. 읽기 좋다는 말이 단순하다는 뜻은 아니다. 어려운 내용을 다루는 글은 당연히 어느 정도 부담이 있다. 중요한 것은 부담의 위치다. 독자는 개념을 이해하는 데 힘을 써야지, 문장을 해독하는 데 힘을 다 쓰면 안 된다.

여백도 글의 일부다

문장을 고치다 보면 단어와 문장 구조만 보게 된다. 하지만 화면에서 글은 여백까지 같이 읽힌다. 문단이 논리적으로 이어져 있어도, 예시를 읽은 직후 곧바로 분석이 붙으면 독자는 방금 읽은 문장을 붙잡을 시간이 없다.

그래서 이 글에는 예시와 분석 사이처럼 의도적으로 한 박자 쉬어야 하는 곳에 빈 줄을 남겼다. 일반 Markdown에서는 빈 줄을 여러 번 넣어도 실제 화면에 그대로 남지 않기 때문에, 필요한 곳에서만 <BlankLines /> 컴포넌트를 썼다.

물론 여백을 많이 넣는다고 글이 읽기 좋아지는 것은 아니다. 모든 문단 사이를 띄우면 오히려 글의 구조가 흐려진다. 어색한 연결을 여백으로 가리는 것도 좋은 방법이 아니다. 이 글에서는 예시를 읽은 뒤, 또는 문제를 진단하고 더 나은 문장으로 넘어가기 전에만 짧게 숨을 둔다.

여백은 장식이라기보다 안내에 가깝다. 독자에게 여기서 잠깐 멈춰도 된다고 알려주는 표시다. 문장이 독자의 작업기억을 덜 쓰게 만들어야 한다면, 문장 사이의 거리도 그 일에 조금은 기여할 수 있다.

이미지는 장식보다 안내에 가깝다

기술 블로그에서 이미지는 보통 두 가지 일을 한다. GitHub 블로그처럼 글 목록이나 헤더에서 추상적인 장면으로 주제를 먼저 보여주기도 하고, Cloudflare 글처럼 아키텍처 설명 중간에 다이어그램을 넣어 구조를 한 번에 보게 하기도 한다. GitHub Docs처럼 스크린샷을 다룰 때는 더 조심스럽다. UI 요소가 작거나 숨겨져 있거나, 선택지가 많아 글만으로 헷갈릴 때 보조로 넣는 식이다.⁴

이 글에는 글에서 말하는 문제를 한 번 더 짚어주는 이미지만 남겼다. 앞부분에는 AI가 만든 정보가 빠르게 쌓이는 느낌을, 여백을 말하는 부분에는 잠깐 멈추는 느낌을 담은 SVG를 넣었다. 두 그림 모두 AI의 도움을 조금 받아 만든 간단한 이미지다.

내 글에서 특히 문제였던 습관

내 글에서 가장 자주 보인 문제는 추상명사가 문장의 주어가 되는 습관이었다.

문제는 디자인보다 글 작성 구조에 있었다. 포맷을 하나로 줄인 효과는 여기서 크게 보인다. 직접 파싱 경로는 Blog v3의 목적과 맞지 않았다.

이런 문장은 문법적으로 틀리지 않다. 하지만 사람이 하는 일이 보이지 않는다. “글 작성 구조”, “효과”, “경로”, “목적” 같은 말이 앞에 나오면 독자는 실제 장면을 뒤에서 찾아야 한다.

더 자연스러운 문장은 보통 실제 대상을 주어로 둔다.

.md와 .mdx를 같이 열어두면 처음에는 안전해 보인다. 하지만 시간이 지나면 글을 읽는 코드가 두 포맷을 계속 구분해야 한다.

이 문장은 같은 내용을 말하지만 독자가 덜 힘들다. 두 파일 형식이 같이 있고, 코드가 그것을 구분해야 하는 장면이 보인다.

두 번째 문제는 지시어였다. “이 문제”, “이 방식”, “이 구조”, “이 기준” 같은 말은 글쓴이에게는 편하다. 하지만 독자는 매번 앞 문장을 다시 봐야 한다. 한 문단에 지시어가 여러 번 나오면 읽는 속도가 떨어진다.

세 번째 문제는 명사화였다. “관리할 수 있다는 점”, “복잡해지는 구조”, “책임을 갖는지” 같은 표현은 설명문에서 자주 나온다. 하지만 너무 많아지면 번역투처럼 보인다. 한국어는 명사만 쌓는 것보다 동사가 살아 있을 때 훨씬 읽기 쉽다. “관리할 수 있다”보다 “한 곳에서 본다”가 나을 때가 있고, “복잡성이 증가한다”보다 “다시 원문을 읽어야 한다”가 나을 때가 있다.

AI 시대에 더 필요한 능력

AI가 없던 시절에는 글 한 편을 쓰는 데 시간이 오래 걸렸다. 초안을 쓰는 데에도 힘이 들었고, 문장을 다듬는 데에도 시간이 걸렸다. 그 과정이 불편하긴 했지만 장점도 있었다. 글쓴이가 문장 하나하나를 직접 통과했기 때문에, 어디가 이상한지 몸으로 느낄 시간이 있었다.

AI를 쓰면 이 과정이 압축된다. 초안은 빠르게 나오고, 문장은 금방 정돈된다. 대신 글쓴이가 문장을 충분히 의심하기 전에 그럴듯한 결과물이 먼저 생긴다. 이때 필요한 능력은 더 많은 문장을 만드는 능력이 아니다. 그 문장이 정말 읽히는지 다시 보는 능력이다.

앞으로 글쓰기에서 중요한 것은 생산량이 아닐 수 있다. 이미 정보는 너무 많다. 검색 결과도 많고, AI가 요약한 답도 많고, 비슷한 설명문도 많다. 이런 환경에서는 글을 더 빨리 쓰는 것보다, 독자의 인지 부담을 덜어내는 쪽이 더 중요해진다.

그러려면 문장을 볼 때 질문이 달라져야 한다.

• 이 문장은 맞는가?
• 이 문장은 자연스러운가?
• 이 문장은 독자가 한 번에 따라갈 수 있는가?
• 독자가 지금 이해해야 할 대상이 문장 안에 보이는가?
• 추상어를 읽고 다시 장면으로 번역해야 하지는 않는가?

나는 마지막 질문이 특히 중요하다고 느낀다. 읽기 어려운 글은 독자에게 계속 번역을 시킨다. 글쓴이는 “구조가 복잡해졌다”고 쓰지만, 독자는 “그래서 실제로 뭘 다시 해야 한다는 거지?”를 떠올려야 한다. 이 번역 비용이 쌓이면 글은 틀리지 않아도 읽히지 않는다.

정리

읽기 좋은 글은 쉬운 말만 쓰는 글이 아니다. 어려운 내용을 피하는 글도 아니다. 독자가 어디에 힘을 써야 하는지 정리해주는 글에 가깝다.

AI는 글을 빠르게 만들 수 있다. 하지만 AI가 만든 문장은 종종 너무 빨리 정리된다. 구체적인 장면은 사라지고, 추상적인 판단만 남는다. 번역투처럼 멀어진 문장도 늘어난다. 문법은 맞지만 읽는 사람은 피곤해진다.

그래서 AI로 글을 쓸수록 더 의식적으로 봐야 할 것이 있다. 문장이 맞는지보다 먼저, 독자가 그 문장을 읽으며 무엇을 기억해야 하는지 봐야 한다. 추상어를 실제 장면으로 바꿀 수 있는지 봐야 한다. 지시어를 실제 이름으로 되돌릴 수 있는지 봐야 한다. 그리고 글쓴이가 이 주제에서 어디를 흥미롭게 봤고, 어디서 생각이 바뀌었는지도 남아 있는지 봐야 한다.

AI 정보 홍수 시대에서 살아남는 글은 더 많은 정보를 담는 글이 아닐지도 모른다. 오히려 독자가 문장을 해독하느라 힘을 다 쓰지 않게 하고, 중요한 생각을 붙잡을 여유를 남겨주는 글일 수 있다. 지금 내가 다시 배우고 싶은 글쓰기도 그런 방향이다.

Footnotes

1. 사전적으로 말맛은 말소리나 말투의 차이에 따른 느낌과 맛을 뜻한다. 이 글에서는 문장이 정보를 전달하는 방식뿐 아니라, 읽을 때 자연스럽게 이어지는 리듬, 글쓴이의 목소리, 문장 사이의 호흡까지 포함한 감각에 가깝다. ↩

2. Cognitive Load Theory는 작업기억의 제한을 전제로 한다. NSW Department of Education의 정리 자료는 작업기억이 한 번에 처리할 수 있는 정보가 제한적이며, 불필요한 인지부하가 학습을 방해할 수 있다고 설명한다. Cognitive load theory: Research that teachers really need to understand ↩

3. 처리 유창성(processing fluency)은 사람이 어떤 대상을 얼마나 쉽게 처리하는지와 관련된 개념이다. Reber, Schwarz, Winkielman은 대상이 더 유창하게 처리될수록 더 긍정적인 반응으로 이어질 수 있다고 설명한다. Processing Fluency and Aesthetic Pleasure ↩

4. GitHub Blog의 글 목록은 글마다 장식적인 헤더 이미지를 함께 보여주고, Cloudflare의 기술 글은 아키텍처를 설명할 때 다이어그램을 본문 중간에 둔다. GitHub Docs는 스크린샷이 글을 더 훑어보기 쉽게 만들 수 있지만, UI 요소를 찾기 어렵거나 선택지가 많을 때처럼 기준을 만족할 때만 넣으라고 설명한다. Vercel은 OpenGraph 이미지를 글 공유와 발견성을 위한 별도의 이미지 자산으로 다룬다. GitHub Engineering Blog, Cloudflare Radar 2.0 architecture, GitHub Docs screenshot criteria, Vercel OG Image Generation ↩