2026년 6월 3일 · 티스토리 운영 메모 · 읽는 데 약 9분 소요
읽는 데 1분 소요는 어떻게 계산할까?
GitHub 알림을 확인하다가 “2026년 6월 2일 · 읽는 데 1분 소요”라는 문구가 눈에 걸렸습니다. 글은 짧았고 내용은 GPT-4.1 지원 종료 공지였지만, 정작 궁금해진 것은 모델보다 그 옆의 작은 시간 표시였습니다. 블로그와 뉴스 사이트가 말하는 “N분 소요”는 누가, 어떤 속도로, 무엇을 어디까지 읽는다고 가정한 숫자일까요?
대부분의 “읽는 데 N분”은 본문 단어 수 또는 글자 수를 평균 읽기 속도로 나눈 추정치입니다. Medium은 성인 평균 읽기 속도 약 275 WPM을 기준으로 삼고 이미지 시간도 더한다고 설명합니다. 읽기 속도 연구에서는 영어 성인 묵독 기준으로 논픽션 평균 238 WPM, 픽션 평균 260 WPM을 제시한 사례가 있습니다. 한국어 블로그는 영어식 WPM을 그대로 가져오기보다 어절 수나 공백 제외 글자 수 기준을 따로 정하는 편이 안정적입니다.
이 글 계산식: 5,039자 ÷ 700 + 이미지 5장 × 0.15 + 코드 2개 × 0.5 = 8.95분, 그래서 표시 문구는 “읽는 데 약 9분 소요”입니다.
작은 숫자가 독자를 붙잡는 방식
“읽는 데 1분”은 별것 아닌 문구처럼 보이지만, 실제로는 독자의 다음 행동을 정하는 아주 짧은 신호입니다. 지금 열어도 되는 글인지, 나중에 저장해 둘 글인지, 출근길에 훑을 수 있는지, 커피를 내려놓고 집중해야 하는지 판단하게 해 줍니다. 그래서 이 표시는 정확한 스톱워치라기보다 입구에 놓인 시간 표지판에 가깝습니다.
GitHub Changelog의 공지처럼 본문이 짧고 목적이 명확한 글은 “1 minute read”가 자연스럽습니다. 제목, 날짜, 상태, 한두 문단, 표 하나 정도라면 독자는 실제로 1분 안팎에 핵심을 파악할 가능성이 큽니다. 다만 여기서 중요한 것은 “모든 사람이 반드시 1분 안에 읽는다”가 아닙니다. 플랫폼은 독자마다 다른 속도를 하나하나 재지 못하므로, 대체로 평균 독자를 가정해 둡니다.
이때 평균 독자는 꽤 추상적인 존재입니다. 영어가 모국어인지, 모바일인지 데스크톱인지, 글이 쉬운 공지인지 복잡한 논문인지, 이미지와 코드가 많은지에 따라 체감 시간은 달라집니다. 결국 “N분 소요”는 정확한 약속이 아니라 독자에게 주는 대략적인 비용 안내입니다.
▲ 읽는 시간은 대체로 본문 길이를 평균 읽기 속도로 나눈 값입니다.
기본 공식은 단순하다
가장 흔한 공식은 다음처럼 정리할 수 있습니다.
예상 읽기 시간(분) = 본문 단어 수 ÷ 분당 읽는 단어 수(WPM)영어권 서비스라면 단어 수를 세고, 기준 WPM을 정하고, 계산 결과를 분 단위로 표시합니다. 예를 들어 본문이 550단어이고 기준 속도가 275 WPM이라면 계산값은 2분입니다. 본문이 230단어라면 0.84분이 나오지만, 독자에게 “0.84분 소요”라고 보여 주는 사이트는 거의 없습니다. 보통은 올림 처리해서 “1분”이라고 보여 줍니다.
그래서 짧은 공지 글의 “1분 소요”에는 두 가지 의미가 섞여 있습니다. 하나는 본문이 실제로 짧다는 뜻이고, 다른 하나는 표시 단위가 분이라서 1분 미만 또는 1분 안팎의 글이 모두 “1분”으로 묶인다는 뜻입니다. 날짜 옆의 작은 문구가 꽤 뭉뚱그린 숫자인 셈입니다.
▲ 계산값은 소수점으로 나오지만, 독자에게는 대개 분 단위로 정리되어 보입니다.
플랫폼마다 기준이 다른 이유
읽기 시간 계산에는 단 하나의 국제 표준이 있는 것이 아닙니다. Medium은 공식 블로그에서 성인 평균 읽기 속도를 대략 275 WPM으로 보고, 글의 단어 수를 분으로 바꾼 뒤 이미지에 걸리는 시간도 더한다고 설명했습니다. 특히 이미지가 많은 글은 첫 이미지와 이후 이미지에 별도 시간을 붙이는 방식으로 보정합니다.
반면 읽기 속도 연구에서는 다른 숫자도 나옵니다. Marc Brysbaert의 2019년 메타분석은 영어 성인의 묵독 속도를 논픽션 평균 238 WPM, 픽션 평균 260 WPM으로 추정했습니다. 즉 Medium의 275 WPM은 플랫폼이 채택한 실용적 기준이고, 연구 평균은 텍스트 유형과 실험 조건을 더 엄밀하게 나눈 값에 가깝습니다.
WordPress 쪽을 봐도 기준이 고정되어 있지 않습니다. WordPress의 Time to Read 블록 문서는 현재 글 또는 페이지의 내용을 바탕으로 언어 인식 계산을 한다고 설명하지만, 사용자가 초 단위나 WPM을 직접 설정하는 구조는 아니라고 안내합니다. 반대로 WordPress 플러그인 중에는 운영자가 WPM을 직접 정하게 하고, 예시로 1100단어를 275 WPM으로 나누면 4분이라고 설명하는 경우도 있습니다.
정리하면 플랫폼은 대체로 같은 방향을 바라봅니다. 본문 길이를 세고, 기준 속도로 나누고, 필요하면 이미지나 콘텐츠 유형을 보정합니다. 하지만 기준 속도와 보정 방식은 플랫폼의 독자층, 언어, 글 형식, 제품 철학에 따라 달라집니다.
▲ Medium은 약 275 WPM, Brysbaert 연구는 영어 논픽션 평균 238 WPM을 제시합니다. 플러그인은 운영자 설정값을 쓰는 경우가 많습니다.
| 구분 | 계산 기준 | 운영자가 기억할 점 |
|---|---|---|
| Medium 방식 | 성인 평균 읽기 속도 약 275 WPM + 이미지 보정 | 읽기 시간은 UX 안내에 가깝고, 이미지 많은 글은 별도 보정이 필요합니다. |
| 읽기 속도 연구 | 영어 성인 묵독 기준 논픽션 238 WPM, 픽션 260 WPM | 콘텐츠 난도와 장르에 따라 속도가 달라질 수 있습니다. |
| WordPress 계열 | 블록 또는 플러그인마다 기본값과 설정 가능 여부가 다름 | 도구를 쓸 때는 기본 WPM과 계산 범위를 먼저 확인해야 합니다. |
한국어 글은 영어 WPM을 그대로 쓰기 어렵다
한국어 블로그에서 읽기 시간을 계산할 때 가장 먼저 부딪히는 문제는 “단어”의 기준입니다. 영어는 공백으로 나뉜 단어를 세기 쉽습니다. 한국어도 공백 기준으로 어절을 셀 수 있지만, 어절 하나가 조사와 어미를 품고 길어지기도 하고, 영어의 word와 완전히 같은 단위라고 보기도 어렵습니다.
그래서 한국어 글에서는 두 가지 방식 중 하나를 선택하는 편이 현실적입니다. 첫째, 공백으로 나눈 어절 수를 세고 “분당 어절 수” 기준을 둡니다. 둘째, 공백을 제외한 한글 글자 수를 세고 “분당 글자 수” 기준을 둡니다. 전자는 영어식 WPM 구조와 비슷해서 구현이 쉽고, 후자는 한국어 텍스트의 실제 길이를 더 직접적으로 반영합니다.
개인 블로그라면 저는 보수적으로 시작하는 편을 권합니다. 예를 들어 가벼운 정보성 글은 공백 제외 한글 기준 600-800자/분 정도를 임시 운영 기준으로 두고, 코드나 표가 많은 기술 글은 더 낮게 잡습니다. 이 숫자는 공인 표준이라기보다 블로그 운영자가 독자에게 과장된 시간을 보여 주지 않기 위한 출발점입니다. 실제 방문자의 체류 시간, 스크롤 깊이, 댓글 반응을 보며 조정하는 것이 더 중요합니다.
▲ 한국어는 단어 수보다 어절 수 또는 글자 수 기준을 별도로 정하는 편이 자연스럽습니다.
티스토리 글에 적용한다면
티스토리 글에 “N분 소요”를 직접 표시하고 싶다면, 먼저 계산 범위를 정해야 합니다. 제목은 뺄지, 목차는 넣을지, 이미지 캡션은 셀지, 코드 블록은 어떻게 처리할지 결정해야 합니다. 계산 범위가 매번 바뀌면 숫자의 신뢰도가 떨어집니다.
제 기준을 하나 제안하면 이렇습니다. 본문, 소제목, 표 텍스트, 캡션은 포함합니다. 목차와 참고 링크 목록은 포함해도 되지만, 광고 문구와 블로그 공통 안내 문구는 제외합니다. 코드 블록은 일반 문장보다 읽는 속도가 느리므로 글자 수 그대로 세기보다 별도 보정 시간을 붙입니다. 이미지가 정보를 전달하는 경우에는 이미지당 5-12초 정도를 더합니다. 단순 장식 이미지는 시간에 넣지 않습니다.
그리고 마지막 표시에서는 소수점을 버리지 말고 올림하는 편이 안전합니다. 계산상 2.1분이 나오면 “2분”보다 “3분”이 독자 기대에 더 정직합니다. 반대로 글이 아주 짧아 0.3분이 나와도 “1분 미만” 또는 “1분”으로 보여 주면 충분합니다. 핵심은 독자를 속이지 않는 것입니다.
▲ 티스토리에 직접 적용한다면 계산 범위, 기준 속도, 보정 방식, 표시 방식을 먼저 고정합니다.
추천 운영 공식
한국어 정보성 글 예상 시간 =
ceil(공백 제외 한글 글자 수 ÷ 700 + 정보성 이미지 수 × 0.15 + 코드 블록 수 × 0.5)여기서 700은 예시 기준입니다. 독자층이 개발자이고 코드가 많다면 500-600으로 낮추는 편이 낫고, 짧은 생활 정보나 공지 위주의 글이라면 800 이상도 가능합니다. 중요한 것은 모든 글에서 같은 기준을 쓰는 것입니다. 그래야 “3분 글”과 “8분 글”이 블로그 안에서 서로 비교 가능한 신호가 됩니다.
예시로 다시 계산해 보기
가령 GitHub Changelog처럼 짧은 공지 글을 생각해 보겠습니다. 제목과 날짜를 제외한 본문이 몇 문단뿐이고, 표도 모델명과 대체 모델 정도만 담고 있다면 독자는 핵심을 거의 즉시 파악합니다. 이런 글은 계산상 0.4분이나 0.7분이 나오더라도 화면에는 “1분”으로 표시될 가능성이 큽니다. 여기서 “1분”은 가장 작은 표시 단위에 가깝습니다.
반대로 같은 1,500자라도 글의 성격이 달라지면 체감 시간은 달라집니다. 일상 에세이처럼 문장이 이어지는 글은 빠르게 읽히지만, API 변경점·요금제 비교·마이그레이션 절차처럼 낯선 용어가 많은 글은 독자가 멈추는 지점이 늘어납니다. 코드 블록이 있으면 독자는 코드를 읽고, 복사 여부를 판단하고, 자기 환경에 맞는지 해석합니다. 이 시간은 단순 글자 수만으로는 잘 잡히지 않습니다.
그래서 기술 블로그의 읽기 시간은 보수적으로 잡는 편이 좋습니다. “5분이면 된다”고 보고 들어온 글이 실제로는 12분짜리 설정 삽질로 이어지면 독자는 속았다고 느낍니다. 반대로 “10분 글”이라고 표시했는데 핵심 요약이 앞에 있고 필요한 사람만 뒤의 세부 절차를 보면 된다면, 독자는 오히려 시간을 계획하기 쉽습니다. 읽기 시간은 짧게 보이기 위한 마케팅 문구가 아니라 독자와의 작은 약속입니다.
무엇을 세고 무엇을 빼야 하나
계산 범위는 블로그 운영자의 판단이지만, 독자가 실제로 읽는 것을 기준으로 삼으면 헷갈림이 줄어듭니다. 본문 문단, 소제목, 표 안의 설명, 이미지 캡션은 포함하는 것이 자연스럽습니다. 이런 요소들은 글의 의미를 구성합니다. 독자가 건너뛸 수도 있지만, 글을 이해하려면 읽을 가능성이 높습니다.
반면 블로그 공통 영역은 제외하는 편이 좋습니다. 상단 메뉴, 사이드바, 광고, 관련 글 목록, 댓글, 구독 안내, 저작권 문구는 해당 글의 실제 독서량이 아닙니다. 티스토리 스킨에 따라 이런 요소가 HTML 안에 함께 섞일 수 있으므로 자동 계산을 구현한다면 본문 컨테이너만 대상으로 삼아야 합니다.
링크 목록은 애매합니다. 글의 참고 자료로 짧게 붙인 링크라면 포함해도 큰 문제가 없습니다. 하지만 링크 제목이 길고 설명문이 붙어 있는 큐레이션 글이라면 링크 목록 자체가 본문입니다. 이 경우에는 반드시 포함해야 합니다. 결국 기준은 단순합니다. “이 부분을 읽지 않으면 글의 가치가 줄어드는가?”라고 물었을 때 예라면 포함하고, 아니면 제외하면 됩니다.
독자 경험 관점에서 보는 좋은 표시
읽기 시간 표시는 제목 바로 아래, 날짜와 카테고리 근처에 놓을 때 가장 자연스럽습니다. 독자가 클릭한 직후 글의 비용을 확인할 수 있기 때문입니다. 너무 아래에 있으면 이미 읽기 시작한 뒤라 의미가 줄고, 너무 크게 강조하면 글보다 숫자가 먼저 보입니다. 작은 보조 정보로 충분합니다.
표현은 짧을수록 좋습니다. “읽는 데 4분”, “4분 소요”, “약 4분” 정도면 됩니다. 한국어 블로그에서는 “약”을 붙이는 것도 괜찮습니다. 이 숫자가 추정치라는 사실을 부드럽게 전달하기 때문입니다. 다만 모든 글에 “약”을 붙일지, 분 단위만 보여 줄지, 1분 미만을 따로 표시할지는 블로그 안에서 통일하는 편이 좋습니다.
긴 글에서는 읽기 시간만으로 부족할 수 있습니다. 이때는 본문 앞에 짧은 요약, 목차, 핵심 체크리스트를 함께 두면 좋습니다. 독자는 “전체는 12분이지만 요약만 보면 1분, 필요한 절만 보면 4분”처럼 자신의 시간을 조절할 수 있습니다. 특히 기술 글, 리뷰 글, 튜토리얼 글은 이런 구조가 체감 품질을 크게 올립니다.
숫자가 틀려 보일 때 점검할 것
읽기 시간이 이상하게 짧게 나오면 본문 텍스트를 제대로 세고 있는지 확인해야 합니다. 일부 에디터나 스킨은 표, 접기 영역, 코드 하이라이트 내부 텍스트를 일반 본문과 다르게 저장합니다. 외부 임베드나 이미지 안에 들어간 글자는 자동으로 세기 어렵습니다. 이미지 속 표가 핵심 정보라면 이미지 개수 보정이나 별도 설명문으로 시간을 보완해야 합니다.
읽기 시간이 지나치게 길게 나오면 반대로 본문 외 텍스트가 섞였을 가능성이 있습니다. 관련 글 목록, 태그 목록, 이전 글·다음 글 링크, 댓글 영역까지 함께 세면 실제보다 크게 부풀어 오릅니다. 자동화할 때는 제목 아래의 실제 글 영역만 선택하도록 범위를 좁혀야 합니다.
또 하나의 변수는 모바일입니다. 모바일에서는 줄 길이가 짧고 스크롤이 잦아집니다. 같은 글이라도 데스크톱보다 체감 시간이 길어질 수 있습니다. 그렇다고 모바일과 데스크톱의 읽기 시간을 따로 표시할 필요까지는 보통 없습니다. 대신 기준값을 너무 공격적으로 잡지 않는 것이 현실적인 타협입니다.
결국 중요한 것은 정직한 기대치
“읽는 데 N분”은 콘텐츠의 품질을 직접 증명하지는 않습니다. 하지만 독자가 글을 만나기 전에 마음속 일정을 잡게 해 줍니다. 짧은 공지는 짧다고 알려 주고, 긴 해설은 길다고 미리 말해 주는 것만으로도 독자는 덜 피곤해집니다. 그래서 좋은 읽기 시간 표시는 정확한 초 단위 계산보다 일관된 기준과 정직한 기대치에 가깝습니다. 내 블로그의 독자가 어떤 글에서 오래 멈추는지 관찰하고, 그 경험에 맞춰 기준을 조금씩 조정하면 됩니다. 그렇게 쌓인 기준은 글 목록에서도 힘을 냅니다. 독자는 제목만 보는 것이 아니라 시간까지 함께 보고, 지금 읽을 글과 나중에 읽을 글을 스스로 나눌 수 있습니다. 작은 숫자지만, 독자의 시간을 존중한다는 신호가 됩니다. 그리고 그 신뢰는 다음 클릭으로 이어집니다.
FAQ
참고 링크
- Medium Blog, Read Time and You
- Marc Brysbaert, How many words do we read per minute?
- WordPress.org, Time to Read block
- WordPress.org, Read Meter plugin
GPT-4.1 지원 종료 링크
'공부' 카테고리의 다른 글
| Kafka란 무엇이고 언제 쓰는가: Docker로 1000만 건 부하 테스트까지 (0) | 2026.06.13 |
|---|---|
| MSA란? 채용 공고에서 자주 보이는 마이크로서비스 아키텍처 이해하기 (0) | 2026.06.03 |
| k6 + Grafana 연계 및 응용 사용 후기 — InfluxDB로 실시간 부하테스트 대시보드 구축하기 (0) | 2026.04.14 |
| k6 성능 테스트 실 사용 후기 (0) | 2026.04.13 |
| Qdrant와 LLM을 활용한 고객지원 티켓 검색 시스템 구축기 (0) | 2025.10.02 |
