글자 수·단어 수 제한 2026 — Twitter, SMS, SEO, Instagram

**글자 수 제한(character limit)**이란 플랫폼이 단일 필드에서 허용하는 Unicode 코드 포인트(codepoint)의 최대 개수입니다. Twitter 게시물은 280, GSM-7 인코딩의 단일 세그먼트 SMS는 160, Google meta description은 잘리기 전까지 약 160입니다. 어떤 숫자가 중요한지는 게시 위치에 따라, 그리고 텍스트에 이모지, 스마트 따옴표, CJK 문자가 포함되었는지에 따라 달라집니다.

이 가이드는 소셜 미디어 작성자, SEO 전문가, 마케팅 카피라이터, 세그먼트 단위로 청구되는 SMS 발송자, 그리고 Twitter, Instagram, SMS 게이트웨이가 실제로 세는 방식과 일치해야 하는 유효성 검사를 작성하는 개발자를 위한 것입니다. 25개 플랫폼 치트 시트는 빠른 참조 표로 바로 이동하거나, 6개 주요 플랫폼에 대해 글자 수 세기에서 초안을 실시간으로 확인하세요 — 제한을 넘는 순간 진행 표시줄이 빨간색으로 바뀝니다.

Quick Reference — Every Platform’s Character & Word Limit

아래 표는 작성자와 개발자가 가장 자주 마주치는 30개 이상의 필드를 다룹니다. “Hard limit”은 플랫폼이 강제하는 상한이고, “Visible / above the fold”는 잘림 지점 이전에 독자가 보는 양이며, “Sweet spot”은 콘텐츠가 가장 좋은 성과를 내는 경험적 범위입니다.

Platform	Hard limit	Visible / above the fold	Sweet spot	Counts emoji as
Twitter / X post	280 chars	280	70-100 chars	1 codepoint
Twitter / X bio	160 chars	160	—	1 codepoint
Twitter / X display name	50 chars	50	—	1 codepoint
X Premium long-form	25,000 chars	—	—	1 codepoint
Instagram caption	2,200 chars	first 125 (then “more”)	<125 for hook	1 codepoint
Instagram bio	150 chars	150	—	1 codepoint
Instagram hashtags	max 30	—	5-10	—
LinkedIn post	3,000 chars	first 210 (then “see more”)	<1,300	1 codepoint
LinkedIn article	110,000 chars	—	—	1 codepoint
LinkedIn headline	220 chars	220	—	1 codepoint
Facebook post	63,206 chars	~477 desktop / ~125 mobile	<80 for organic	1 codepoint
TikTok caption	2,200 chars	first ~100	<150	1 codepoint
YouTube title	100 chars	70 (search)	<60	1 codepoint
YouTube description	5,000 chars	first 100-150 above fold	first 150 for hook	1 codepoint
YouTube comment	10,000 chars	—	—	1 codepoint
Reddit title	300 chars	—	<60 (subreddit-dependent)	1 codepoint
Reddit comment	10,000 chars	—	—	1 codepoint
Discord message	2,000 chars	2,000	—	1 codepoint
Discord embed description	4,096 chars	—	—	1 codepoint
Slack message	40,000 chars	—	<2,000 for readability	1 codepoint
Pinterest pin description	500 chars	first 50-60	<125	1 codepoint
Mastodon toot	500 chars (configurable)	500	—	1 codepoint
Bluesky post	300 chars	300	—	1 grapheme cluster
Threads post	500 chars	500	—	1 codepoint
SEO meta description (Google)	~160 chars desktop / ~120 mobile	150-160	150-160	1 codepoint
SEO page title (Google)	~60 chars desktop / ~50 mobile	50-60	50-60	1 codepoint
Open Graph description	~200 chars before LinkedIn/FB clip	150-200	150-200	1 codepoint
Twitter Card description	200 chars max	200	150-200	1 codepoint
SMS single segment (GSM-7)	160 chars	—	—	special — see below
SMS single segment (UCS-2 / emoji)	70 chars	—	—	1 codepoint
WhatsApp message text	65,536 chars	—	—	1 codepoint
Email subject line	no platform limit	~60 desktop / ~30 mobile	<50	1 codepoint
Google Ads headline	30 chars × 15 headlines	30 each	30	1 codepoint
Google Ads description	90 chars × 4 desc	90 each	90	1 codepoint
App Store title	30 chars	30	30	1 codepoint
App Store subtitle	30 chars	30	30	1 codepoint
App Store description	4,000 chars	first 252 above fold	252 hook	1 codepoint
Play Store short description	80 chars	80	80	1 codepoint
Play Store long description	4,000 chars	first 80 above fold	80 hook	1 codepoint

“Sweet spot” 위쪽의 콘텐츠는 잘리거나 순위가 내려가는 경향이 있습니다. X Premium 장문 형식과 Mastodon(인스턴스별 설정 가능)은 500자를 넘어서도 페널티 없이 작성할 수 있는 드문 예외입니다. 위의 모든 카운트는 — SMS 규칙이 적용되는 경우를 제외하면 — Unicode 코드 포인트 카운트입니다. 이모지 하나는 2가 아니라 1글자입니다. 가장 흔한 6개 제한에 대해 한 번에 초안을 검증하려면 글자 수 세기에 붙여넣으세요. 진행 표시줄이 게시 전에 제한 초과 텍스트를 잡아냅니다.

How Characters Are Actually Counted (Unicode Code Points vs UTF-16)

세 가지 도구가 같은 문자열에 대해 세 가지 다른 글자 수를 알려줄 수 있습니다. 이유는 “글자(character)“가 하나의 정의로 고정되어 있지 않기 때문입니다 — Unicode 코드 포인트일 수도, UTF-16 코드 유닛일 수도, 그래픽 단위(grapheme cluster)일 수도 있으며, 각 플랫폼은 그중 하나를 선택합니다.

What is a “character” — codepoint vs code unit vs grapheme

**코드 포인트(codepoint)**는 Unicode 스칼라 값으로, U+0000부터 U+10FFFF까지의 정수 중 Unicode가 문자에 할당했거나 예약 상태로 표시한 모든 값을 가리킵니다. **코드 유닛(code unit)**은 인코딩의 최소 단위입니다. UTF-16은 16비트 코드 유닛, UTF-8은 8비트 코드 유닛을 사용합니다. **그래픽 단위(grapheme cluster)**는 사람이 하나의 가시적 글자로 인식하는 단위입니다 — 때로는 코드 포인트 하나, 때로는 베이스 코드 포인트와 결합 표시(combining mark)의 조합, 때로는 가족 이모지 👨‍👩‍👧‍👦처럼 zero-width joiner 시퀀스(코드 포인트 7개가 하나의 가시 글리프로 결합)일 수도 있습니다.

문자열 "a🌍👨‍👩‍👧"에 대해 세 가지 카운트는 서로 다릅니다.

Counting method	Result	Used by
UTF-16 code units (JS string.length)	10	Naive JavaScript code
Unicode code points	6	Twitter, Instagram, SMS gateways
Grapheme clusters	3	Bluesky, screen readers, text editors

Why string.length lies about emoji

JavaScript는 내부적으로 문자열을 UTF-16으로 저장합니다. U+FFFF를 넘는 모든 코드 포인트(모든 이모지, 모든 astral plane 문자)는 서로게이트 페어(surrogate pair) — 즉 16비트 코드 유닛 두 개로 인코딩됩니다. .length 속성은 이 두 유닛을 보고하며, 글자 하나로 보고하지 않습니다.

"🌍".length              // 2   (UTF-16 code units)
[..."🌍"].length         // 1   (codepoints — what Twitter/SMS counts)
"🌍".match(/./gu).length // 1   (codepoints via regex with /u flag)

전개 연산자와 /u 정규식 플래그는 모두 코드 포인트 단위로 순회하며, 이는 Twitter, Instagram, SMS 게이트웨이가 제한과 대조하는 방식과 일치합니다. 원시 .length를 사용하는 유효성 검사 함수는 실제로는 한도 미만인 트윗을 거절하거나, 더 나쁜 경우 다운스트림 시스템이 거절할 메시지를 통과시키게 됩니다.

What about CJK and combining marks

중국어, 일본어, 한국어 표의문자는 각각 하나의 코드 포인트이며 모든 플랫폼에서 한 글자로 계산됩니다. 비용이 커지는 곳은 SMS입니다. GSM-7에 없는 문자가 하나라도 들어가면 메시지 전체가 UCS-2 인코딩으로 바뀌고, 세그먼트 한도가 160에서 70으로 떨어집니다(다음 절에서 다룹니다).

결합 표시(combining mark)는 동작이 다릅니다. 악센트 á를 á로 작성하면 코드 포인트 하나이지만, 같은 á를 a + ́(결합 acute accent)로 쓰면 코드 포인트 두 개이면서 그래픽 단위 하나입니다. 대부분의 플랫폼은 코드 포인트로 세므로, 두 번째 형식은 한 글자가 추가로 듭니다. Bluesky는 눈에 띄는 예외로, 그래픽 단위를 세기 때문에 양쪽 모두 1로 계산됩니다.

Counting in different languages — quick reference

// JavaScript
[...str].length                          // codepoints
Array.from(str).length                   // codepoints

// Python 3 — len() is codepoint by default
len(s)

// Go — utf8 package
utf8.RuneCountInString(s)

// Rust — chars() iterates codepoints
s.chars().count()

// Java — codePointCount
s.codePointCount(0, s.length())

비교 차원에서 Base64 인코더 디코더는 반대 방향을 떠올리게 해줍니다. 전송용으로 텍스트를 Base64로 인코딩하면 UTF-8 입력 3바이트마다 ASCII 출력 4글자가 되므로, 인코딩된 길이는 코드 포인트 수가 아니라 바이트 수에 의존합니다. 이모지 하나를 붙여 넣고 Base64 출력이 8글자로 늘어나는 것을 확인해 보세요 — Twitter에서 1글자가 드는 같은 이모지가 UTF-8로는 4바이트를 차지합니다.

어떤 초안이든 코드 포인트 카운트(Twitter가 실제로 측정하는 수치)를 확인하려면 글자 수 세기가 기본적으로 Unicode 기준입니다.

SMS Character Limit — GSM-7, UCS-2 & Multi-Part Messages

SMS는 이모지 하나로 청구 금액이 그대로 두 배가 될 수 있는 유일한 주요 채널입니다. 이유는 인코딩이고, 계산식은 1985년 이후 그대로입니다.

The 160-character magic number — GSM-7 history

1985년 GSM-03.38 표준은 SMS 페이로드를 140바이트로 고정했습니다. 7비트 문자 인코딩에서는 140바이트가 1,120비트 ÷ 7 = 160글자를 담습니다. 그 유명한 sms character limit 160은 여기서 나왔습니다. GSM-7 문자 집합은 128개의 기본 문자와 10자 확장({ } [ ] | \ ~ ^ € 및 폼 피드 포함)을 포함합니다. 이 집합 내에서는 세그먼트당 160자 예산을 모두 사용할 수 있습니다.

GSM-7 밖에 있어 인코딩 전환을 강제하는 문자들:

• 모든 이모지
• 둥근(스마트) 따옴표(" " ' ') — ASCII 직선 따옴표 " '와 다릅니다
• GSM-7의 35자를 벗어나는 대부분의 악센트 라틴 문자(é á ñ ü ø 등; GSM-7은 ä ö å æ ø à è ì ò ù 등 일부만 포함)
• 전각 구두점, CJK 문자, 아랍어, 히브리어, 그리스어 소문자, 키릴 문자
• 백틱 `과 틸드 ~ (틸드는 GSM-7 확장 표에 있어 160자 예산 중 2자를 차지합니다)

UCS-2 trap — one emoji drops you from 160 to 70

메시지 어디든 GSM-7 밖 문자가 하나라도 등장하는 순간, 메시지 전체가 UCS-2 인코딩으로 바뀝니다. UCS-2는 문자당 16비트를 사용하므로 140바이트 ÷ 2 = 세그먼트당 70글자입니다. 실제 예시:

"Hello, your code is 12345"            → 26 chars, GSM-7, 1 segment
"Hello, your code is 12345 ✓"          → 28 chars, GSM-7 (✓ in extension), 1 segment
"Hello, your code is 12345 ✅"          → 28 chars, UCS-2 (emoji), 1 segment (under 70)
"Hello, "your" code is 12345 ✅"        → smart quotes + emoji → UCS-2
"Hi 你好"                                → CJK → UCS-2, 1 segment (5 chars)

마지막 “Hi 你好” 예시가 함정입니다. 5자뿐이지만 UCS-2 가격을 적용받고, 그다음에 추가하는 65자가 한 세그먼트에 들어간 뒤 세그먼트 2가 시작됩니다.

Multi-part SMS segments (concatenation)

160(GSM-7) 또는 70(UCS-2)을 넘는 순간, 메시지는 여러 세그먼트로 분할됩니다. 각 세그먼트는 재조립용 7자 User Data Header (UDH)를 싣기 때문에 세그먼트당 사용 가능한 페이로드가 줄어듭니다.

• GSM-7 다중 분할: 세그먼트당 153자
• UCS-2 다중 분할: 세그먼트당 67자

수신 단말은 수신자가 모르게 세그먼트들을 재조립하지만, 과금은 메시지가 아니라 세그먼트 단위입니다. 161자 GSM-7 메시지는 2세그먼트입니다. 1,000자 GSM-7 메시지는 7세그먼트입니다(153 × 6 = 918, 7번째 세그먼트가 마지막 82자를 운반).

Cost math — when one emoji doubles your bill

80자 일반 텍스트 마케팅 메시지를 가정해 봅시다.

• 일반 텍스트: 80자 → GSM-7 → 1세그먼트, 가격 X
• 이모지 하나 추가: 80자 → UCS-2 → 80 > 70 → 2세그먼트, 가격 2X

이모지 하나로 청구액이 두 배가 되는 일은 실제로 일어나고, 규모도 따라 커집니다. 세그먼트당 $0.0075 기준으로 10만 건 캠페인은 GSM-7에서 $750, UCS-2에서 $1,500 — $750짜리 이모지인 셈입니다. 주요 SMS 공급자(Twilio, Bandwidth, AWS SNS, MessageBird, Vonage)는 모두 이 방식으로 청구합니다. 인코딩 규칙은 공급자 정책이 아니라 GSM 표준입니다. 바이트 수준 인코딩 트레이드오프의 역사 — ASCII / UTF-8 / UCS-2가 왜 별개의 표준으로 존재하는지 — 는 Base64 이해하기에서 다룹니다. “비트를 글자로 옮기는” 같은 문제의 계열이 SMS 대신 이메일에 적용된 사례입니다.

How to keep messages in GSM-7

• 스마트 따옴표 대신 ASCII 직선 따옴표 " ' 사용
• em-dash —이나 en-dash – 대신 ASCII 하이픈 - 사용
• ©와 ® 대신 (c)와 (R)로 풀어 쓰기
• 캠페인 예산이 UCS-2 비용을 전제하지 않는 한 이모지 회피
• 공급자 콘솔(Twilio, Bandwidth, MessageBird)은 미리보기 옆에 “encoding: GSM-7” 또는 “UCS-2”를 표시합니다 — 발송 전에 확인하세요

초안 작성 중 가장 빠른 점검 방법은 글자 수 세기의 SMS 진행 표시줄입니다 — 160자 기준으로 보고합니다. 텍스트가 UCS-2를 유발하면, 글자 수를 2.29로 나눠 70자 규칙 하의 세그먼트 수를 어림하면 됩니다.

SEO Limits — Meta Description, Title Tag, OG, Twitter Card

SEO 글자 수 제한은 플랫폼 제한보다 부드럽습니다. meta description이 300자에 닿아도 Google이 페이지를 거절하지는 않습니다. 그렇지만 실제 잘림 규칙은 클릭률에 영향을 미칩니다.

Meta description — 150-160 character sweet spot

Google의 데스크톱 검색 결과는 meta description을 약 155-165자 부근에서 자르고, 모바일은 100자에서 120자 사이 어딘가에서 자릅니다. 정확한 잘림 지점이 다른 이유는 Google이 글자가 아니라 디스플레이 픽셀을 측정하기 때문입니다. W와 M 글리프가 가득한 description은 i와 l로 가득한 description보다 잘림 픽셀에 더 빨리 도달합니다.

실무 작성 규칙:

• 전체 150-160자를 목표로 합니다
• 핵심 메시지는 첫 120자 안에 둡니다(모바일 안전선)
• meta description character limit 키워드는 첫 30자 안에 배치합니다
• 마지막 30자에는 CTA를 둡니다 — 데스크톱이 가운데를 잘라도 읽힙니다

2017-2018년 사이 Google이 meta description 표시를 320자까지 잠시 확장했고, 그 시기의 SEO 튜토리얼 세대가 아직도 이 숫자를 인용합니다. Google은 2018년 중반에 160으로 되돌렸습니다. 오늘날 200자를 넘겨 쓰면 뒤쪽 절반이 묻힐 뿐입니다.

다른 실패 양상: 120자 미만의 description은 통째로 교체되는 경우가 많습니다. Google이 그 description으로는 쿼리에 충분히 답하지 못한다고 판단해 본문에서 다른 구절을 끌어옵니다 — 경고 없이 CTR 통제권을 잃습니다.

Title tag — 60 desktop, 50 mobile

Title 태그는 데스크톱에서 약 60자, 모바일에서 약 50자에서 잘립니다. description과 동일한 픽셀 기반 잘림이고, 폭이 넓은 글리프에 대한 동일한 주의도 적용됩니다.

Sweet spot: 50-60자. 타깃 키워드는 첫 30자 안에 두어 어떤 잘림도 견디게 합니다. 롱테일 브랜드 접미사(| Brand Name)는 끝에 두어, 잘려도 가장 손해가 적도록 합니다.

Pixel-width vs character-count — Google’s actual rule

Google의 SERP description 컨테이너는 데스크톱에서 대략 920픽셀 폭입니다. 평균 글자 폭은 약 6.5픽셀이고, 이로부터 140-160자라는 경험적 목표가 나옵니다. 그러나 글자별 편차가 큽니다. i는 약 3픽셀, M은 약 11픽셀로 렌더링됩니다. 전부 대문자로 된 텍스트(“BEST WIDGETS FOR WINTER WEDDINGS”)는 동일한 소문자 텍스트보다 훨씬 일찍 잘립니다.

게시 전에는 픽셀 정확도의 SERP 시뮬레이터로 미리 보는 편이 SEO 카피에 대해 글자 수 카운터보다 더 믿을 만합니다.

OG description & Twitter Card description

Open Graph 프로토콜의 og:description은 Facebook, LinkedIn, Slack, Discord가 공유 링크 미리보기 아래에 렌더링하는 텍스트입니다. 표시 상한은 플랫폼마다 다릅니다 — 대부분은 약 200자에서 자르고, 일부는 300자까지 확장합니다. Twitter Card의 twitter:description은 Twitter 파서에서 200자로 하드캡됩니다.

합리적인 기본값:

• OG와 Twitter Card 모두 150-200자
• meta description과 같아도 되지만, OG는 검색 순위에 영향을 주지 않으므로 조금 더 길어도 괜찮습니다
• 구조화된 데이터 선택(특히 실수로 OG에 끌려 들어간 항목)은 보안 모범 사례의 패턴으로 검증하세요. 신뢰할 수 없는 OG 메타데이터는 흔한 피싱 벡터입니다

What “no character limit” actually means

H1 태그, 본문 콘텐츠, URL 슬러그에는 플랫폼이 강제하는 SEO 글자 수 제한이 없지만, 부드러운 제한은 여전히 적용됩니다.

• H1이 70자를 넘으면 시각적 계층과 훑어 읽기가 깨집니다
• URL 슬러그는 기술적으로 무제한이지만 Google이 SERP에 표시하는 길이는 약 90자입니다 — 그 이상은 외관용일 뿐입니다
• 본문 콘텐츠에는 길이 상한이 없지만 Google은 분량보다 유용한 콘텐츠를 우대합니다 — 단어 수 자체는 순위 신호가 아닙니다

글자 수 세기는 작성 중 meta description (160)과 title 태그 (60)를 실시간으로 추적하며, 잘림 픽셀에 가까워질수록 진행 표시줄이 호박색과 빨간색으로 바뀝니다.

Social Platforms — Twitter/X, Instagram, LinkedIn, Facebook & Beyond

콘텐츠가 실제로 잘 작동하는 sweet spot은 대부분 hard limit보다 아래쪽에 있습니다.

Twitter / X — 280, premium 25,000, URL substitution rule

표준 twitter character limit은 280자이며, 2017년 11월에 140자에서 두 배로 늘어났습니다. X Premium 구독자는 풍부한 서식과 함께 최대 25,000자의 장문 콘텐츠를 게시할 수 있지만, 오가닉 도달의 주력 형식은 여전히 280자 게시물입니다.

직관에 반하는 규칙은 URL 치환입니다. Twitter는 게시 시점에 길이에 상관없이 모든 URL을 23자 t.co 단축 링크로 감쌉니다. 23자 비용은 고정입니다.

published_length = raw_length − URL_length + 23

예시: "Check this: https://example.com/very-long-path?id=12345"라는 초안은 원시 기준 53자입니다. URL은 38자이므로 23자 t.co 링크로 치환되고, 게시 길이는 53 − 38 + 23 = 38자가 됩니다. 모르고 있던 15자를 절약하는 셈입니다.

긴 URL을 초안에 붙여 넣을 때는 URL 인코더 디코더가 무엇이 URL로 인식되는지 빠르게 확인하는 방법입니다(Twitter는 RFC 3986 패턴으로 URL을 인식합니다 — 쿼리 문자열과 프래그먼트 포함). 서브도메인, 스킴, 포트, 경로, 쿼리, 프래그먼트 모두 23자 치환에 흡수됩니다.

다른 Twitter 필드: display name 50자, bio 160자, 핸들 15자. Threads(Meta의 Twitter 대응 서비스)는 500자 제한을 사용합니다.

Instagram — 2,200 caption, 30 hashtags, 125-char hook

Instagram 캡션은 2,200자까지 허용하지만, 피드는 첫 125자만 보여주고 나머지는 ”… 더 보기” 탭 뒤로 접어 둡니다. 절반이 넘는 독자는 그 탭을 누르지 않습니다. 참여도에서 의미 있는 instagram caption limit은 따라서 hard limit이 2,200이라 해도 125입니다.

30개 해시태그 상한은 hard limit입니다 — 31번째 해시태그를 시도하면 게시가 실패합니다. 5-10개 해시태그 범위가 가장 좋은 성과를 내는 경향이 있습니다. 11개를 넘으면 발견 부스트가 평탄해지고, 게시물은 알고리즘에 스팸처럼 보이기 시작합니다.

다른 필드: bio 150자, display name 30자, DM 1,000자.

LinkedIn — 3,000 post, 1,300 sweet spot, “see more” fold

LinkedIn 게시물의 linkedin character limit은 3,000이지만, 피드는 “see more” 접힘선 이전의 첫 210자만 표시합니다. 1,200-1,500자 범위의 게시물이 LinkedIn에서 참여도를 가장 잘 얻습니다(여러 Buffer와 Hootsuite 연구가 약 1,300 부근으로 수렴합니다). 가치를 입증하기에는 충분하면서도 독자의 스크롤 피로가 시작되기 전 길이입니다.

LinkedIn Articles(장문 출판 표면)는 110,000자를 허용합니다 — 사실상 무제한입니다. 프로필 헤드라인은 220자, About 섹션 텍스트는 2,600자로 제한됩니다.

Facebook — 63,206 chars, 80-char organic sweet spot

Facebook의 63,206자 게시물 한도는 대체로 트리비아에 가깝습니다. 실제로는 80자 미만 게시물이 더 긴 게시물보다 오가닉 참여도가 약 30% 더 높습니다(HubSpot이 여러 해에 걸쳐 일관되게 보고합니다). 접힘선 위로는 데스크톱이 약 477자, 모바일이 약 125자에서 끊습니다.

댓글 최대 길이는 8,000자입니다. 반응, 공유, 클릭은 모두 짧은 게시물 쪽으로 기울어집니다 — 긴 카피는 Facebook 캡션이 아니라 링크된 글 안에 있어야 합니다.

Newer platforms — Bluesky, Mastodon, Threads, TikTok

• Bluesky 게시물은 300자에서 끊기며, 특이한 경우입니다. Bluesky는 그래픽 단위를 세기 때문에 코드 포인트 7개로 이루어진 가족 이모지 👨‍👩‍👧‍👦가 7이 아니라 1자로 계산됩니다
• Mastodon은 toot당 기본 500자이지만, 인스턴스 관리자가 5,000자나 심지어 무제한까지 올릴 수 있습니다 — 게시 중인 인스턴스를 확인하세요
• Threads는 Twitter 방식의 500자 제한과 코드 포인트 카운팅을 사용합니다
• TikTok 캡션은 2,200자를 허용하며, 접힘선 위에 약 100자가 보입니다

Reddit, Discord, Slack — long-form & community defaults

• Reddit 제목 300자(서브레딧 모더레이터가 AutoModerator로 60자 미만을 강제하는 경우가 많음), 댓글 10,000자
• Discord 표준 메시지 2,000자, 임베드 description 4,096자, Nitro는 일반 메시지를 4,000자로 늘립니다
• Slack 메시지 40,000자, 2,000자를 넘으면 가독성이 급격히 떨어지고 많은 수신자가 긴 메시지를 무시합니다

Word Count Targets by Content Type

소셜과 SEO에서는 글자 수가 지배적이지만, 나머지 거의 모든 영역 — 학술, 청구, 콘텐츠 마케팅, 원고 — 은 단어 수가 지배합니다. 아래 표는 각 일반 콘텐츠 유형에 대한 목표 범위와 읽기 시간 추정치(230 wpm, Brysbaert 2019 묵독 메타분석의 중앙값)를 제공합니다.

Content type	Word target	Reading time @ 230 wpm	Notes
Tweet	30-40 words	10 sec	optimize for character, not word
LinkedIn post (sweet spot)	170-250 words	1 min	above the fold
Instagram caption (hook)	20-25 words	<10 sec	first 125 chars
Blog post — short	500-700 words	2-3 min	listicle, news, hot take
Blog post — standard	1,000-1,500 words	4-7 min	tutorial, deep guide
Blog post — long	2,000-3,000 words	9-13 min	comprehensive guide
SEO pillar page	2,500-5,000 words	11-22 min	topical authority
Academic essay (high school)	500-1,500 words	2-7 min	varies by assignment
Academic essay (undergrad)	1,500-3,000 words	7-13 min	per assignment
NaNoWriMo daily	1,667 words/day	—	50K words in 30 days
Novel — short	50,000-70,000 words	—	YA, mystery
Novel — standard	80,000-100,000 words	—	adult fiction
Conference talk (12 min @ 130 wpm)	1,500-1,600 words	speaking	rehearse to confirm
Podcast episode (30 min @ 130 wpm)	3,900 words	speaking	scripted portion

콘텐츠 마케팅에서 더 유용한 목표 단위는 읽기 시간입니다 — 독자는 “1,150 단어” 라벨보다 “5분 소요” 라벨에 더 안정적으로 반응합니다. 단어 수는 청구(원문 단어당 번역료), 플랫폼 준수(NaNoWriMo 5만 단어, 학술 2,000단어 상한), 계약 조항의 단위로 남아 있습니다. 글자 수 세기는 입력과 동시에 두 값을 실시간으로 보여주며, 강연과 팟캐스트를 위해 130 wpm 기준 발화 시간도 함께 제공합니다.

6 Counting Mistakes That Break Real Apps

다음은 실제 출시된 코드와 출시된 마케팅 캠페인에서 반복적으로 보이는 실패들입니다. 각 항목은 증상, 근본 원인, 해결책의 순서로 짝지어 있습니다.

Mistake 1: Using string.length for character-limit validation

증상: 사용자가 이모지 3개가 포함된 — 실제로는 코드 포인트 270개인 — 트윗을 붙여 넣습니다. 프론트엔드 유효성 검사는 276이라고 표시하며 제출을 거절합니다. 또는 더 나쁘게는, 이모지 예산이 상쇄되어 285 코드 포인트 초안을 코드가 통과시키고, Twitter가 서버 측에서 거절합니다.

근본 원인: JavaScript의 String.prototype.length는 UTF-16 코드 유닛을 반환합니다. 모든 이모지는 서로게이트 페어이며 유닛 2개를 차지합니다. 모든 astral plane 문자(수학 기호, 고대 문자)도 마찬가지입니다.

해결책: 전개 연산자나 Array.from으로 코드 포인트 단위로 순회합니다.

// ❌ wrong
function isUnderTwitterLimit(text) {
  return text.length <= 280;
}

// ✅ correct
function isUnderTwitterLimit(text) {
  return [...text].length <= 280;
}

정규식 기반의 더 깊은 코드 포인트 순회 패턴(그래픽 단위 처리 포함)은 정규식 치트 시트에서 /u와 /v 플래그, Unicode property escape를 다룹니다.

Mistake 2: Splitting CJK text on whitespace for word count

증상: 500자 분량의 중국어 글이 1단어로 보고됩니다. 그 기준으로 산출된 번역 견적은 500배 어긋납니다.

근본 원인: CJK 언어는 단어 구분 공백을 쓰지 않습니다. text.split(/\s+/)는 글 전체를 하나의 토큰으로 반환합니다.

해결책: 각 CJK 표의문자를 1단어로 세는 방식 — Microsoft Word, Google Docs, 모든 네이티브 CJK 워드 프로세서가 사용하는 관습 — 을 따릅니다.

function countWordsMixed(text) {
  const cjk = (text.match(/[一-鿿぀-ヿ가-힯]/g) || []).length;
  const latin = (text
    .replace(/[一-鿿぀-ヿ가-힯]/g, ' ')
    .match(/[A-Za-z0-9]+(?:['’-][A-Za-z0-9]+)*/g) || []).length;
  return cjk + latin;
}

Unicode 범위는 CJK Unified Ideographs (U+4E00 ~ U+9FFF), 히라가나·가타카나 (U+3040 ~ U+30FF), 한글 음절 (U+AC00 ~ U+D7AF)을 포함합니다 — Microsoft Word의 단어 수가 표의문자로 세는 네 개 블록입니다.

Mistake 3: Forgetting Twitter URL 23-char substitution

증상: 80자 URL을 포함한 초안이 카운터에서 320자로 표시됩니다. 10분 동안 다듬은 끝에야 Twitter는 원본을 263자로 받았으리란 사실을 깨닫습니다.

근본 원인: Twitter는 게시 시점에 모든 URL을 23자 t.co 링크로 치환합니다. 원시 카운터는 이를 알 길이 없습니다.

해결책: 각 URL에 대해 raw − URL_length + 23 공식으로 게시 길이를 미리 계산합니다. URL이 여러 개인 초안에서는 보정값을 합산합니다. 게시 콘텐츠의 URL 인식은 RFC 3986을 따릅니다 — URL 인코딩과 디코딩 가이드가 다루는 것과 같은 파싱 규칙입니다.

Mistake 4: Writing meta description to 320 chars (old guideline)

증상: CTA를 끝에 둔 280자짜리 meta description을 정성껏 작성했습니다. Google 검색 결과에서는 설명이 158자에서 문장 중간에 잘리고, CTA는 끝까지 등장하지 않습니다.

근본 원인: 2017년 12월부터 2018년 5월 사이, Google이 meta description 표시를 잠시 320자까지 확장했습니다. 많은 SEO 튜토리얼이 아직도 그 숫자를 인용합니다. Google은 2018년 중반에 약 160으로 되돌렸고, 이후로 유지하고 있습니다.

해결책: 150-160자로 작성합니다. 핵심 키워드는 첫 30자에, CTA는 마지막 30자에 배치합니다. 중요한 페이지에는 픽셀 정확도의 SERP 시뮬레이터를 사용하세요 — 폭이 넓은 글리프(W, M, K)는 좁은 글리프(i, l, t)보다 예산을 빠르게 소진합니다.

Mistake 5: Confusing 280 characters with 280 words

증상: 팀의 누군가가 “280단어 트윗이 필요하다”라고 말하고 1,500자 분량의 멀쩡한 산문을 만듭니다. 그 트윗은 게시되지 않습니다.

근본 원인: 글자 대 단어 혼동입니다. 영어 산문에서 두 단위는 대략 5-6배 차이가 납니다.

해결책: 플랫폼별로 규칙을 못 박으세요. Twitter, SMS, SEO meta는 글자를 셉니다. NaNoWriMo, 학술 과제, 번역 계약, 그리고 대부분의 콘텐츠 마케팅 브리프는 단어를 셉니다. 헷갈릴 때는 사양을 확정하기 전에 플랫폼 자체 카운터(Twitter 작성창, Word의 검토 > 단어 수)를 확인하세요.

Mistake 6: Pasting smart quotes that silently switch SMS to UCS-2

증상: Google Docs의 고객 영수증 템플릿을 SMS 발송기에 복사합니다. 원본은 145자이고 GSM-7 1세그먼트로 발송됐습니다. 붙여 넣은 뒤에도 같은 145자이지만 UCS-2 2세그먼트로 청구됩니다. 100만 건 캠페인에서 비용이 두 배가 됩니다.

근본 원인: Google Docs와 Word는 "와 '를 자동으로 활자 따옴표 " "와 ' '로 변환합니다. 이 따옴표는 GSM-7 문자 집합에 없으므로 메시지 전체가 UCS-2로 전환됩니다.

해결책: 전송 전에 정규화합니다.

function toGsm7Quotes(s) {
  return s
    .replace(/[“”]/g, '"')   // " " → "
    .replace(/[‘’]/g, "'")   // ' ' → '
    .replace(/[–—]/g, '-');  // – — → -
}

청구에 영향을 주는 발송 전에는 항상 실행하세요. Twilio, MessageBird, Bandwidth 모두 응답에 인코딩 필드를 노출합니다 — 로그를 남기고, GSM-7로 의도한 템플릿에 UCS-2가 등장하면 알림을 발생시키세요.

FAQ

What is the difference between character count and word count?

글자 수는 공백, 구두점, 이모지를 포함한 모든 글자를 세며, 대부분의 현대 플랫폼에서 Unicode 코드 포인트 기준으로 측정합니다. 단어 수는 라틴 문자 기준으로 공백으로 분리된 토큰을, CJK 기준으로 표의문자 단위를 셉니다. Twitter, SMS, SEO meta description은 글자 수를 사용합니다. 학술 에세이, NaNoWriMo 원고, 번역 청구서는 단어 수를 사용합니다.

Why does Twitter count emoji as 1 character but JavaScript counts them as 2?

Twitter는 Unicode 코드 포인트로 측정합니다 — 모든 이모지는 코드 포인트 1개, 글자 1개입니다. JavaScript의 string.length는 UTF-16 코드 유닛을 측정합니다. 대부분의 이모지는 U+FFFF를 넘으며 UTF-16에서 서로게이트 페어로 인코딩되므로, 코드 유닛 2개를 차지하고 .length는 2를 반환합니다. Twitter가 실제로 세는 코드 포인트 수를 얻으려면 [...text].length 또는 Array.from(text).length를 사용하세요.

Why is the SMS character limit 160 sometimes and 70 other times?

SMS는 기본적으로 7비트 GSM-7 인코딩을 사용하며, 140바이트 페이로드에 160자를 담습니다. 메시지에 GSM-7 밖 문자가 하나라도 — 이모지, 스마트 따옴표, CJK, 작은 집합을 벗어난 악센트 라틴 문자 — 포함되면 메시지 전체가 16비트 UCS-2 인코딩으로 바뀌고 세그먼트당 한도는 70자로 떨어집니다. 메시지 어디든 이모지 하나로 전환이 일어납니다.

What is the ideal meta description length in 2026?

150-160자를 목표로 합니다. Google의 데스크톱 SERP는 디스플레이 픽셀 폭에 따라 155-165자 부근에서 자르고, 모바일은 100자에서 120자 사이에서 자릅니다. 120자 미만일 때 Google은 본문에서 추출한 구절로 description을 통째로 교체하는 경우가 많습니다. 핵심 키워드는 첫 30자에, CTA는 마지막 30자에 배치해 어느 방향의 잘림에도 메시지가 살아남도록 하세요.

Does character limit include spaces and emoji?

거의 모든 플랫폼에서 그렇습니다. 공백, 줄바꿈, 구두점, 이모지는 각각 Unicode 코드 포인트 1개로 계산됩니다. 알아둘 만한 예외 두 가지: SMS에서는 이모지가 위에서 설명한 인코딩 전환을 유발하고, Bluesky는 그래픽 단위를 세기 때문에 가족 이모지 👨‍👩‍👧‍👦처럼 코드 포인트가 여러 개인 이모지도 7이 아니라 1자로 계산됩니다.

How is word count calculated for Chinese, Japanese, Korean text?

각 CJK 표의문자가 1단어로 계산됩니다 — Microsoft Word의 중국어 모드 단어 수, Google Docs, 네이티브 CJK 에디터, 그리고 모든 상용 번역 메모리 시스템이 사용하는 관습입니다. 500자 분량의 중국어 글은 500단어로 보고됩니다. 혼합 텍스트는 CJK 표의문자를 글자 단위로, 라틴 토큰을 공백 단위로 세서 둘을 합산합니다.

How does Twitter handle URL length in the 280-character limit?

Twitter는 게시 시점에 원본 길이와 상관없이 모든 URL을 23자 t.co 단축 링크로 자동 변환합니다. 게시 길이는 URL마다 published = raw − URL_length + 23 공식을 따릅니다. 100자 URL 하나를 포함한 320자 초안은 243자로 발송됩니다. Twitter는 URL을 RFC 3986 패턴으로 인식하므로 쿼리 문자열과 프래그먼트도 URL 토큰에 흡수됩니다.

Related reading

• 정규식 치트 시트 — 글자 유효성 검사를 위한 패턴 매칭, Unicode property escape
• 텍스트 비교(Diff) 온라인 가이드 — 두 텍스트를 줄과 글자 단위로 비교하기
• URL 인코딩과 디코딩 가이드 — 텍스트가 URL을 통과할 때의 문자 이스케이프 규칙
• Base64 이해하기 — 이메일과 바이너리 데이터에 적용된 “비트를 글자로” 인코딩의 다른 절반