자동화 시스템을 구축하거나 고객 알림을 보낼 때, 많은 비즈니스 소유자와 개발자들은 예상보다 두 배나 높은 월별 SMS 요금 고지서를 보고 깜짝 놀라곤 합니다. 이 종합 가이드에서는 SMS 전송 시 특수 문자가 차지하는 글자 수 표를 제공하여, 숨겨진 인코딩 전환이 어떻게 메시지 전송 비용을 급격히 증가시키는지 이해할 수 있도록 도와드립니다.
특수 문자가 SMS 길이와 비용을 변화시키는 이유
통신 표준에서 문자 메시지는 작성한 단어의 순수한 개수가 아니라 "세그먼트(segment)" 단위로 요금이 부과됩니다. 표준 SMS 세그먼트는 GSM-7 문자 세트를 사용하여 인코딩되며, 메시지당 최대 160자까지 전송할 수 있습니다. 하지만 이 표준 세트 이외의 단 하나의 문자(예: 이모지, 키릴 문자, 또는 Microsoft Word에서 복사한 세련된 "스마트 따옴표")라도 포함되는 순간, 전체 메시지 인코딩이 UCS-2(유니코드)로 전환됩니다.
UCS-2 인코딩 상태에서도 특수 문자와 이모지가 포함된 SMS 메시지가 160자로 제한된다는 것은 흔한 오해입니다. 실제로는 단 하나의 비 GSM(non-GSM) 문자가 감지되는 순간, 세그먼트당 최대 글자 수 제한이 160자에서 단 70자로 즉시 줄어듭니다. 만약 메시지 길이가 71자이고 이모지가 하나 포함되어 있다면, Twilio나 Plivo 같은 기존 API 제공업체에서는 이 메시지를 두 개의 별도 SMS 세그먼트로 분할하여 요금을 부과합니다.
어떤 특수 문자가 주로 메시지에 영향을 미치는지 이해하는 것은 운영 비용을 낮게 유지하는 데 매우 중요합니다. 특히 병원, 미용실, 수리점 등 고객에게 예약 알림을 보내는 지역 서비스 비즈니스를 운영하는 경우 더욱 그렇습니다.
GSM-7 vs. UCS-2 인코딩 설명
GSM-7은 SMS를 위해 특별히 설계된 7비트 문자 인코딩 표준입니다. 여기에는 대부분의 라틴 문자, 숫자 및 기본 문장 부호가 포함됩니다. UCS-2는 이모지를 포함하여 모든 언어의 거의 모든 문자를 표현할 수 있는 16비트 인코딩 표준이지만, 문자당 두 배의 데이터가 필요합니다. 이러한 데이터 오버헤드 때문에 UCS-2가 트리거되면 통신사 네트워크가 세그먼트 용량을 70자로 낮추는 것입니다.
최종 SMS 특수 문자 매핑 표
아래는 SMS 전송 시 특수 문자가 차지하는 글자 수 표입니다. 이 표는 표준 GSM-7 문자, GSM-7 확장 문자(160자 제한 내에서 2자 공간을 차지함), 그리고 엄격한 70자 제한을 강제하는 UCS-2 문자를 보여줍니다.
| 문자 카테고리 | 예시 문자 | 문자당 비트 수 | SMS 내 문자 가중치 | 최대 세그먼트 제한 |
|---|---|---|---|---|
| GSM-7 기본 | A-Z, a-z, 0-9, 공백, 기본 문장 부호(., !, ?, @, $, 등) | 7 bits | 1글자 | 160자 |
| GSM-7 확장 | ^, {, }, [, ], ~, |, \, € | 14 bits | 2글자 | 160자 (각 확장 문자는 2자로 계산됨) |
| UCS-2 (유니코드) | á, í, ó, ñ, ’ (스마트 따옴표), 이모지(😀), 키릴 문자, 아랍어 | 16 bits | 전체 메시지를 유니코드로 강제 변환 | 70자 |
표에서 볼 수 있듯이 중괄호 "{"나 백슬래시 "\"와 같은 확장 GSM-7 문자를 사용하더라도 유니코드가 강제 적용되지는 않지만, 160자 제한에서 2글자로 계산됩니다. 그러나 "á"(스페인어 sms y caracteres especiales 설정에서 자주 사용됨)나 둥근 아포스트로피 "’"와 같은 비 GSM 문자를 사용하면 메시지 세그먼트 제한이 즉시 70자로 줄어듭니다.
특수 문자가 SMS 비용에 미치는 영향
los caracteres especiales que impacto tienen en el coste de los sms(특수 문자가 SMS 비용에 미치는 영향)를 이해하기 위해 실제 예시를 살펴보겠습니다. 치과를 운영하며 다음과 같은 예약 알림 문자를 보낸다고 가정해 보겠습니다.
"Hi John, your appointment is scheduled for tomorrow at 3:00 PM. Please reply to confirm or call us if you need to reschedule! Él"
이 메시지는 123자입니다. 악센트가 있는 "É" 대신 표준 "E"를 사용하면 메시지가 GSM-7로 전송됩니다. 160자 제한 내에 여유 있게 들어가므로 정확히 1 SMS 세그먼트 비용만 발생합니다.
하지만 악센트가 있는 "É" 때문에 메시지가 강제로 UCS-2로 변환됩니다. 이제 세그먼트 제한은 70자가 됩니다. 123자짜리 메시지는 두 개의 세그먼트로 분할됩니다(세그먼트 헤더로 인해 첫 번째 세그먼트는 67자, 두 번째는 56자가 됩니다). 기존 API 게이트웨이는 1개가 아닌 2개의 SMS 메시지 요금을 청구하게 됩니다.
기존 업체를 사용하는 경우, 이러한 세그먼트 분할로 인해 월별 청구서가 두 배 또는 세 배로 늘어날 수 있습니다. 이것이 바로 많은 기업이 임의적인 세그먼트 기반 추가 요금을 피하기 위해 Twilio 대안을 찾거나 가장 저렴한 SMS API 가이드를 참고하는 이유입니다.
SMS에서 특수 문자를 피하는 방법은 무엇인가요?
메시지를 160자 제한 내로 유지하고 예기치 않은 비용을 방지하려면 SMS 페이로드를 적극적으로 정리(sanitize)해야 합니다. 다음은 SMS에서 특수 문자를 피하는 방법에 대한 실질적인 전략입니다.
- 복사하여 붙여넣은 텍스트 정리: 많은 CRM 템플릿에 "스마트" 문장 부호가 포함되어 있습니다. 예를 들어, 서식 있는 텍스트 편집기에서 복사한 아포스트로피(’)나 쉼표는 정상적인 전송을 방해하거나 유니코드를 트리거할 수 있습니다. 실제 사례로, 일부 내부 기업 시스템에서는 상담원에게 다음과 같은 짧은 경고를 보냅니다: "발신 SMS 특수 문자 주의: 발송되는 모든 SMS는 250자 이하여야 합니다. 저장된 템플릿에서 메시지를 복사하여 붙여넣었으며 쉼표(,)나 아포스트로피(')가 포함되어 있는 경우, 해당 특수 문자를 삭제한 후 전송 전에 다시 입력해 주십시오.". 스마트 따옴표를 표준 직선 따옴표(')로 대체하면 GSM-7 준수가 보장됩니다.
- 프로그램 방식으로 비 GSM 문자 대체: 시스템이 SMS를 동적으로 생성하는 경우, "á"를 "a"로, "é"를 "e"로, "“"를 """로 바꾸는 음역(transliteration) 기능을 구현하십시오.
- 플랫폼별 제한 사항 처리: 기업용 로코드(low-code) 플랫폼에서 개발하는 경우, JSON 직렬화 중에 텍스트 변수가 표준 문장 부호를 유니코드와 동일한 문자로 자동 변환할 수 있는 special characters in gsm outsystems 연동 등에서 인코딩을 처리하는 방식을 숙지해야 합니다.
SMS 텍스트 정리를 위한 Python 코드 스니펫
다음은 SMS가 인식하지 못하거나 비용이 많이 드는 UCS-2 인코딩을 강제하는 특수 문자를 제거하는 간단한 Python 함수입니다.
import unicodedata
def sanitize_for_gsm7(text):
# Map common smart punctuation to GSM-7 equivalents
replacements = {
'\u2018': "'", '\u2019': "'", # Smart single quotes
'\u201c': '"', '\u201d': '"', # Smart double quotes
'\u2013': '-', '\u2014': '-', # En and em dashes
'\u20ac': 'EUR' # Replace Euro sign if needed
}
for unicode_char, gsm_char in replacements.items():
text = text.replace(unicode_char, gsm_char)
# Normalize accents (e.g., é to e)
normalized = unicodedata.normalize('NFD', text)
gsm7_text = "".join([c for c in normalized if not unicodedata.combining(c)])
return gsm7_text
message = "Hello! Your appointment is confirmed for tomorrow é."
print(sanitize_for_gsm7(message))
# Output: "Hello! Your appointment is confirmed for tomorrow e."
MySMSGate로 인코딩 불안 해소하기
지역 서비스 비즈니스, 학교, 병원 등에서 문자 인코딩, 세그먼트 제한, 복잡한 요금 체계에 대해 걱정하는 것은 불필요한 두통거리입니다. 바로 이 지점에서 기존의 SMS 게이트웨이와 SMS API 중 어떤 것을 선택할지가 매우 중요해집니다.
MySMSGate는 이 문제를 완전히 해결합니다. 엄격한 세그먼트 곱하기 요금제가 적용되는 비싼 통신사 네트워크를 통해 메시지를 라우팅하는 대신, MySMSGate는 사용자의 Android 휴대폰과 SIM 카드를 SMS 게이트웨이로 변환합니다.
비용에 민감한 기업을 위해 MySMSGate가 어떻게 판도를 바꾸는지 소개합니다.
- 단일 요금제: 길이, 문자 인코딩, 세그먼트에 관계없이 전송된 메시지당 $0.02의 고정 요금을 부과합니다. 이모지나 악센트 문자가 요금을 두 배로 늘릴지 걱정할 필요가 없습니다.
- 본인 번호 사용: 메시지는 Android 휴대폰의 SIM 카드에서 직접 전송됩니다. 고객에게 친숙한 로컬 모바일 번호가 표시되므로 응답률과 오픈율이 향상됩니다.
- 복잡한 등록 절차 없음: Twilio와 같은 기존 API와 관련된 복잡한 10DLC 등록, 통신사 승인 및 월별 브랜드 수수료를 피할 수 있습니다.
- 듀얼 SIM 및 다중 기기 지원: 단일 대시보드에서 여러 대의 휴대폰과 SIM 카드를 관리하고, 각 고객과의 대화에 전송할 회선을 정확하게 선택할 수 있습니다.
자주 묻는 질문(FAQ)
SMS 문자 인코딩, 특수 문자 및 메시지 제한과 관련된 일반적인 질문을 확인해 보세요.
어떤 특수 문자가 SMS 제한을 70자로 줄이나요?
표준 GSM-7 문자 세트에 포함되지 않은 모든 문자는 UCS-2 인코딩을 강제하여 제한을 70자로 줄입니다. 여기에는 이모지, 비라틴 문자(키릴 문자, 아랍어, 그리스어, 히브리어), 특정 악센트 문자 또는 스타일이 가미된 문장 부호(예: 둥근 스마트 따옴표)가 포함됩니다.
SMS에서 공백도 글자 수로 계산되나요?
네, GSM-7과 UCS-2 인코딩 표준 모두에서 모든 공백은 1글자로 계산됩니다.
메시지를 하나만 보냈는데 SMS 플랫폼에서 왜 여러 개의 메시지 요금을 청구하나요?
메시지가 160자(GSM-7 기준) 또는 70자(UCS-2 기준)를 초과한 경우, 통신사에서 메시지를 여러 세그먼트로 분할했습니다. 기존 API는 세그먼트당 요금을 부과하므로, 긴 메시지 하나를 보낼 때 기본 요금의 2배 또는 3배의 비용이 쉽게 발생할 수 있습니다.
내 SMS 메시지에 특수 문자가 포함되어 있는지 어떻게 테스트할 수 있나요?
온라인 SMS 세그먼트 계산기를 사용하거나 백엔드에서 간단한 정리 스크립트를 실행하여, API 제공업체로 전송하기 전에 텍스트가 UCS-2 유니코드 인코딩을 트리거하는지 감지할 수 있습니다.
Comments (0)
Be the first to comment!