일관성을 유지하는 다국어 알림 템플릿

다국어 알림이 일관성을 잃는 이유

다국어 알림 템플릿은 보통 명확한 단일 소유자가 없어서 점점 엇나갑니다. 제품팀이 영어 문구를 편집하고, 고객지원은 어조를 부드럽게 권장하며, 마케팅은 제목을 손보고, 번역가는 자신이 마지막으로 본 버전으로 작업합니다. 한 달쯤 지나면 같은 이벤트가 언어와 채널에 따라 세 가지 방식으로 설명되는 상황이 됩니다.

가장 큰 원인은 "한 메시지에만 적용한 작은 변경"입니다. 누군가 영어 문장 하나를 추가하고 다른 곳에 반영하는 걸 잊습니다. 또는 {first_name} 같은 플레이스홀더를 새 데이터 모델에 맞춰 {name}으로 바꿨는데 영어 템플릿만 업데이트된 경우가 있습니다. 결과는 인사가 사라지거나, 변수 오류가 나거나, 문구가 형식적인 서류처럼 느껴지는 것입니다.

사용자는 개인적이거나 금전과 관련된 세부사항을 잘 봅니다. 이름이 빠지거나, 날짜가 어색하게 보이거나, 금액이 잘못 보이면 메시지의 나머지가 정확하더라도 신뢰는 빠르게 떨어집니다. 어조도 중요합니다. 한 언어는 따뜻하고 사과 섞인 어조로 들리는데 다른 언어는 직설적으로 느껴질 수 있습니다.

일관성 문제는 예측 가능한 곳에서 시작됩니다:

• 채널 간 복사·붙여넣기(이메일을 SMS에 붙이고 언어별로 다르게 잘라냄)
• 번역 완료 후의 막판 수정
• 모든 언어에서 검증되지 않은 플레이스홀더 편집
• 같은 개념을 서로 다르게 번역하는 여러 사람
• 날짜, 통화, 이름에 대한 포맷 차이

채널별 제약은 드리프트를 악화시킵니다. 이메일은 제목, 헤딩, 문맥을 허용하지만 SMS는 짧고 글자 수에 민감합니다. 채팅 앱은 버튼이나 마크다운 유사 포맷을 지원할 수 있습니다. 각 언어를 채널에 맞게 따로 편집하면 길이만 바꾸는 것이 아니라 의미까지 바뀌는 일이 종종 발생합니다.

구체적 예: 영어 결제 영수증이 "Your card was charged {amount} on {date}"에서 "We received your payment of {amount}."로 바뀌었습니다. 스페인어 버전은 옛 문장을 유지하고 프랑스어 버전은 데이터에 {date}가 더 이상 없어서 날짜를 잃으면 고객은 스크린샷을 비교하고 문제가 생겼다고 생각할 것입니다.

드리프트는 사소하고 합리적인 편집들이 쌓이고 대부분의 시스템이 사용자가 메시지를 보기 전에 일관성을 강제하지 않기 때문에 발생합니다.

간단한 모델: 하나의 메시지 인텐트, 여러 출력

모든 알림을 먼저 하나의 인텐트로 취급하고, 채널별 출력은 두 번째로 생각하세요. 인텐트는 사용자가 받는 약속입니다: 무슨 일이 있었는지, 사용자가 다음에 무엇을 해야 하는지, 무시해도 되는 것은 무엇인지. 채널 포맷은 포장지입니다.

이 마인드셋은 이메일·SMS·채팅용으로 세 가지 다른 메시지를 쓰는 대신 하나의 메시지를 통제된 변형으로 만들게 해줍니다.

인텐트 카드로 시작하세요

템플릿을 건드리기 전에 짧고 평이한 명세서를 만드세요. 지역별로 변경하면 안 되는 것들(사실, 숫자, 필수 문구)과 변경해도 되는 것들(어조, 문장 순서, 문화적 규범)을 명확히 적습니다.

실용적인 인텐트 카드에는 다음이 포함됩니다:

• 목표: 사용자가 이해하거나 해야 할 것
• 필수 사실: 금액, 날짜, 상품명, 마감일
• 허용 변형: 인사 스타일, 구두점, 격식 수준
• 콜투액션: 하나의 명확한 다음 단계

이제 이메일, SMS, 채팅 버전은 별개의 카피 프로젝트가 아니라 동일한 인텐트의 출력물이 됩니다.

변수에 대한 단일 진실 소스

어떤 변수가 있고 그 의미가 무엇인지 한 번만 결정하고 모든 곳에서 재사용하세요. {{first_name}}, {{invoice_total}}, {{due_date}} 같은 플레이스홀더는 언어와 채널 전반에서 동일해야 하며, 같은 데이터 타입과 포맷 규칙을 가져야 합니다.

AppMaster 같은 도구로 알림을 만들 경우 워크플로(예: Business Process)에서 변수를 한 번 정의하고 각 템플릿에 주입하면 도움이 됩니다. 이렇게 하면 이메일에서는 {{amount}}, SMS에서는 {{total}}처럼 "거의 동일한" 플레이스홀더가 생기는 것을 피할 수 있습니다.

채널 드리프트를 방지하려면 카피 변경에 대한 단순한 승인 경로를 설정하세요:

• 카피 책임자가 인텐트 카드 변경을 제안
• 현지화 담당자가 영향을 받는 로케일을 업데이트
• 채널 소유자가 제약 조건이 여전히 맞는지 확인
• 한 명의 리뷰어가 최종 승인하고 릴리즈를 스케줄

이 과정은 인텐트를 안정적으로 유지하면서 각 출력이 짧고 명확하며 채널에 적합하도록 합니다.

변수와 플레이스홀더를 예측 가능하게 관리하기

템플릿은 대부분 변수에서 깨집니다. 한 언어는 괜찮아도 다른 언어에서는 이름이 사라지거나 날짜가 이상하게 보이거나 구두점 전에 여분의 공백이 생깁니다. 해결책은 "더 많은 교정"이 아니라 변수를 작은 제품처럼 규칙을 정해 다루는 것입니다.

채널과 언어 전반에 걸친 공유 변수 카탈로그로 시작하세요. 각 변수는 하나의 의미와 번역가가 이해할 수 있는 예시가 필요합니다. 변수 이름은 지루하고 안정적으로 유지하세요. 자주 이름을 바꾸면 오래된 템플릿이 조용히 망가집니다.

실용적 카탈로그 항목 예:

• 변수 이름(예: {order_id})
• 의미를 평이하게 설명
• 하나의 좋은 예시 값과 하나의 엣지 케이스
• 출처(시스템, 사용자 입력, 데이터베이스)
• 필수인지 선택인지

포맷 규칙은 번역만큼 중요합니다. 날짜, 통화, 숫자는 일관되게 포맷되어야 하며, 최소한 로케일별로 포맷하도록 결정하세요. 템플릿에 미리 포맷된 문자열을 넣을지(문자 메시지와 채팅에 더 안전) 아니면 템플릿 시스템 안에서 포맷할지(유연하지만 실수하기 쉬움)를 미리 정하세요.

누락 값에 대한 전략도 필요합니다. 한 가지 접근법을 변수마다 정하고 번역가마다 다르게 적용하지 마세요. 일반 규칙은 기본값 사용("Customer"), 문장 전체 제거, 또는 아무 것도 표시하지 않음입니다.

예: {first_name}이 없을 때 "Hi {first_name}, your receipt is ready"는 "Hi, your receipt is ready"(이름과 쉼표 제거)로 바뀌어야 합니다. 자동으로 텍스트를 제거할 수 없다면, 처음부터 인사가 이름에 의존하지 않도록 작성하세요.

간단한 팀 규칙 몇 가지:

• 이메일, SMS, 채팅에 대해 같은 변수 집합 사용
• 변수를 필수 또는 선택으로 표시하고 테스트에서 강제
• 날짜, 숫자, 통화는 로케일 인식 포맷터 사용
• 모든 템플릿이 승인된 카탈로그만 사용하도록 검증

어색하지 않은 폴백 설계

폴백은 번역이 없거나 늦을 때 살려주지만 반쪽 번역된, 어색하고 신뢰하기 힘든 최악의 메시지를 만들 수도 있습니다. 폴백이 발생하면 사용자는 여전히 명확하고 공손하며 의도된 느낌을 받게 해야 합니다.

먼저 하나의 폴백 순서를 정하고 모든 곳에서 사용하세요. 일반 규칙은 정확 로케일(fr-CA) → 기본 언어(fr) → 기본 언어(보통 en)입니다. 핵심은 일관성입니다. 이메일과 SMS가 서로 다른 폴백 순서를 쓰면 사용자가 눈치챕니다.

폴백 문구는 안전하고 중립적이어야 합니다. 기본 문구에는 농담, 속어, 문화 특정 참조를 피하세요. 문장을 짧게 유지하고 관용구를 피하며 날짜·시간·통화가 폴백 시에도 읽기 쉬운지 확인하세요.

일부 메시지는 폴백하면 위험이 너무 크기 때문에 절대 폴백하면 안 됩니다. 이런 경우 발송을 차단하거나 짧게 승인된 "지원 문의" 메시지를 보내는 편이 낫습니다.

• 비밀번호 재설정 및 일회용 코드
• 결제 실패, 환불, 송장
• 법률, 정책, 동의 관련 메시지
• 안전 또는 보안 알림
• 약속이나 의무를 만들 수 있는 모든 것

폴백은 팀에 가시적으로 만들고 추적하세요. 추적하지 않으면 누락된 번역이 몇 달간 눈에 띄지 않을 수 있습니다. 폴백 이벤트를 기록하고 정기적으로 검토하세요.

민감한 내용을 저장하지 않고도 조치할 수 있을 만큼의 로그 정보를 남기세요:

• 메시지 인텐트(예: "order_shipped")
• 채널(이메일, SMS, 채팅)
• 요청된 로케일과 실제 사용된 로케일
• 템플릿 버전 또는 커밋 태그
• 타임스탬프와 전송 결과(전송됨, 실패, 차단됨)

예: "배송 지연" 알림을 새로 배포했습니다. es-MX 로케일의 사용자가 이를 트리거했지만 es-ES만 존재한다면 로케일→언어→기본 규칙에 따라 스페인어(es)를 받게 되고 로그에는 es-MX가 es로 폴백되었다고 나옵니다. 그러면 작업은 명확합니다: 지역적 문구 차이가 필요할 경우에만 es-MX를 추가하세요, 단순히 번역이 없어서 추가하는 것은 피하세요.

채널별 제약: 이메일, SMS, 채팅은 다르다

이메일에서 잘 읽히는 템플릿이 SMS에서는 실패할 수 있고, 채팅 메시지는 수신함에 복사되면 어수선해 보일 수 있습니다. 하나의 공유 인텐트와 변수 계약을 유지하되 각 채널을 자체 포맷과 제한이 있는 독립적인 형태로 다루세요.

이메일: 여유는 있지만 부서질 곳이 많음

이메일은 문맥을 넣을 공간을 주지만 깨질 수 있는 지점도 많습니다. 제목은 사람들이 생각하는 것보다 짧아야 할 때가 많습니다, 특히 단어가 길게 늘어나는 언어에서는 더욱 그렇습니다. 미리보기 텍스트도 중요하며 원시 변수명이나 반복된 인사 같은 어색한 잔여물로 시작하면 안 됩니다.

HTML은 레이아웃에 도움이 되지만 반드시 플레인 텍스트 버전도 의미가 통하도록 유지하세요. 일부 언어는 추가 줄바꿈이나 다른 구두점이 필요할 수 있고, HTML에서는 괜찮아도 플레인 텍스트에서는 혼란스러울 수 있습니다. 간단한 테스트는 플레인 텍스트를 소리 내어 읽어보는 것입니다: 형식 문서처럼 빠져나간 부분이 들리면 준비가 된 것이 아닙니다.

SMS: 제한이 엄격하고 기능이 적음

SMS는 관대하지 않습니다. 인코딩에 따라 문자 수 제한이 달라지고, 비라틴 스크립트는 한 메시지에 들어가는 양을 줄일 수 있습니다. 핵심 요점을 먼저 넣으세요: 대상, 무슨 일이 있었는지, 다음에 무엇을 해야 하는지.

많은 팀이 SMS에 링크 금지 또는 승인된 단축 코드만 허용하는 엄격한 정책을 둡니다. 긴 URL은 문자를 잡아먹고 의심스러워 보일 수 있습니다. 이모지를 허용할지 여부도 미리 결정하세요. 허용하지 않으면 번역가가 친근하게 보이려고 추가하는 것을 막아야 합니다.

채팅 앱: 포맷팅, 버튼, 줄바꿈

채팅은 짧은 업데이트에 적합하지만 앱마다 포맷 규칙이 다릅니다. 어떤 앱은 간단한 마크다운을 지원하고 어떤 앱은 지원하지 않습니다. 줄바꿈이 합쳐지거나 작은 화면에서 줄바꿈 방식이 문장 느낌을 바꿀 수 있습니다. 버튼이나 빠른 응답을 사용하면 라벨은 모든 언어에서 짧아야 합니다.

긴 규칙 목록 대신 채널별로 작은 "발송 금지" 목록을 유지하고 모든 로케일을 그 기준에 대고 확인하세요. 예: 원시 플레이스홀더, 중복된 인사, 또는 잘려서 말이 안 되는 제목 등을 체크합니다.

실용적 습관으로는 SMS 버전을 먼저 쓰고 그 다음 채팅, 마지막으로 이메일 세부사항(제목과 포맷)을 추가하는 것입니다. 이렇게 하면 부가물을 더하기 전에 핵심을 명확히 할 수 있습니다.

일관된 템플릿을 만드는 단계별 워크플로

일관성은 반복 가능한 작업 순서에서 옵니다. 모두가 같은 단계를 따르면 템플릿은 드리프트를 멈추고 유지 관리가 쉬워집니다.

1) 하나의 명확한 인텐트로 시작

평이한 언어로 단일 기본 버전을 초안으로 작성하세요(보통 주 언어). 하나의 행동에 집중하세요: 확인, 리마인더, 경고, 요청 등. SMS나 채팅에 맞지 않을 세부사항은 생략하세요.

2) 초기에 변수와 규칙을 잠금

번역 전에 메시지가 사용할 수 있는 데이터를 결정하세요. 변수를 계약처럼 다루세요: 필수 vs 선택 정의, 누락 데이터 동작 정의, 포맷(날짜, 통화, 전화번호) 검증.

3) 동일한 플레이스홀더 세트로 로케일별 번역

단어 순서가 아니라 의미를 번역하세요. 모든 언어에서 정확히 같은 플레이스홀더를 유지하되 문장 순서를 바꿔도 괜찮습니다. 어떤 언어가 존칭이나 추가 단어를 필요로 하면 새 변수가 아니라 일반 텍스트를 추가하세요.

4) 의미를 바꾸지 않고 채널별로 적응

로케일 템플릿에서 채널별 버전을 만드세요. 이메일은 맥락을 제공할 수 있고, SMS는 간결해야 하며, 채팅은 짧은 줄이 유리할 수 있습니다. 약속과 다음 단계는 동일하게 유지하세요.

5) 로케일별 테스트 데이터로 미리보기

현실적인 샘플 데이터를 모든 로케일과 채널에 통과시켜 미리보기를 실행하세요. 여기서 어색한 줄바꿈, 누락 변수, 잘림을 잡을 수 있습니다.

간단한 빌드 루프:

1. 명확한 다음 단계가 있는 하나의 인텐트로 기본 메시지 초안 작성.
2. 필수·선택 변수와 유효성(타입, 길이, 허용 값) 정의.
3. 동일한 플레이스홀더로 각 로케일 번역.
4. 의미와 톤을 유지하며 채널별 변형 생성.
5. 테스트 데이터로 미리보기하고 릴리즈 전에 문제 수정.

AppMaster에 구현할 경우 한 가지 실용적 접근은 템플릿과 공유 변수 스키마를 워크플로 로직 근처에 두어 이메일, SMS, 채팅 버전이 같은 소스에서 생성되도록 하는 것입니다. 이렇게 하면 카피가 복사되어 유지되는 상황을 줄일 수 있습니다.

테스트를 위해 길게 늘어난 이름, 누락된 성, 큰 금액, 다른 시간대 같은 스트레스 샘플을 소수로 만들어 템플릿이 실제 사용자 데이터에서 잘 작동하는지 확인하세요.

현지화 관련 자주 발생하는 버그들

번역이 정확해도 작은 현지화 디테일이 실제 데이터가 플레이스홀더에 들어가면 템플릿을 망가뜨릴 수 있습니다.

복수형과 숫자 주변 문법

복수형 규칙은 단수 vs 복수만 있는 것이 아닙니다. 일부 언어는 여러 복수형을 가지며 동사나 형용사도 바뀝니다. "You have {{count}} new tickets" 같은 문장은 count가 0, 1, 2, 또는 11일 때 미묘하게 틀릴 수 있습니다.

복수형 규칙이 중요하면 숫자를 넣은 한 문장보다 구조화된 변형을 저장하세요. 숫자 포맷도 로케일별로 일관되게 유지(1,000 vs 1 000)하고 문자열 연결로 비즈니스 로직에서 문법을 만드는 것을 피하세요.

이름, 순서, 존칭

이름은 복잡합니다: 일부 문화는 성을 먼저 쓰고, 어떤 사람은 한 이름만 쓰며, 존칭도 다릅니다. 템플릿이 "Hi {{first_name}}"라고 하면 전체 이름만 있는 경우나 이름 분리 오류가 있을 때 실패합니다.

표시용 이름(display name) 필드를 우선으로 사용하고 일관된 폴백 체인을 정의하세요:

• 표시 이름
• 이름(first name)
• 전체 이름
• 중립적 인사(예: "Hello")

시간대와 날짜 포맷

테스트에서는 괜찮아 보이던 날짜도 프로덕션에서는 혼란을 줄 수 있습니다. "03/04/2026"은 로케일에 따라 의미가 다르고 시간대 없이 시간을 보내면 고객지원 티켓이 생깁니다.

로케일 인식 포맷을 사용하고 수신자 시간대로 변환하세요. 약속 리마인더는 같은 UTC 타임스탬프에서 한 로케일에는 "4 Mar 2026, 09:30"로, 다른 로케일에는 "Mar 4, 2026, 9:30 AM"으로 렌더링되어야 합니다.

우측에서 좌측(RTL) 언어와 구두점

RTL 언어는 까다롭습니다: 구두점, 괄호, 주문 ID 같은 혼합 콘텐츠가 시각적 순서가 뒤바뀔 수 있습니다. "Order #{{order_id}}" 같은 간단한 문자열도 뒤섞여 보일 수 있습니다.

실제 데이터(숫자, 이메일, 상품 코드)로 RTL 템플릿을 테스트하세요. 의심스러우면 변수 블록을 짧게 유지하고 변수 주변에 뒤집힐 수 있는 구두점을 피하세요.

피해야 할 일반적 실수와 함정

일관성을 망가뜨리는 가장 빠른 방법은 각 언어를 별개의 메시지로 다루는 것입니다. 그렇게 해도 발송은 할 수 있지만 작은 차이가 쌓여 사용자가 눈치챕니다.

드리프트를 유발하는 실수들:

• 언어별로 변수 이름 변경(영어는 {first_name}, 스페인어는 {name} 등). 번역가는 이를 우회하고 결국 한 로케일에서 빈칸이나 원시 플레이스홀더가 노출됩니다.
• 번역 텍스트 안에 값을 하드코딩(가격이나 날짜 포맷을 평문으로 작성). 값이 바뀌면 한 언어만 틀려집니다.
• 영어 버전 하나를 모든 곳에 재사용해 길이를 확인하지 않음. 영어에 맞춰진 문구가 독일어에서는 두 메시지가 되거나 통신사가 최악의 지점에서 분할할 수 있습니다.
• 로케일 간 어조 혼합. 영어는 친근하고 비공식적인데 프랑스어는 격식을 차리면 브랜드 음성이 무작위로 느껴집니다.
• 누락 데이터 테스트를 건너뜀. 실제 시스템에는 항상 엣지 케이스가 있습니다: 성 없음, 배송 창 없음, 알 수 없는 위치 등.

구체적 예: 비밀번호 재설정 SMS가 주 언어에서는 괜찮아도 다른 로케일에서는 링크 플레이스홀더 이름이 달라 사용자가 "Reset here: {url}."를 보게 되는 경우가 있습니다. 이런 건 피할 수 있는 고객지원 티켓입니다.

대부분을 예방하는 작은 습관:

• 플레이스홀더 계약을 하나로 유지하고 자동으로 검증하세요.
• 값(가격, 날짜, 이름)을 텍스트로 저장하지 말고 데이터로 저장하고 로케일별로 포맷하세요.
• 채널별 제한을 미리 정하세요(SMS 길이, 이메일 제목 길이, 채팅 미리보기 크기).
• 로케일별로 톤 규칙(격식 vs 비격식)을 합의하고 몇 가지 예시를 문서화하세요.

발송 전 빠른 체크리스트

실제 고객에게 보내기 전에 비밀번호 재설정 이메일만큼의 주의로 한 번 더 점검하세요.

데이터와 플레이스홀더에서 시작하세요. 메시지에 "Hi {first_name}"이 있으면 해당 값이 알림을 트리거하는 모든 경로에 존재하는지 확인하세요. 포맷 규칙이 로케일과 일치하는지(날짜, 시간, 통화, 이름 순서) 확인하세요.

사전 비행 체크리스트:

• 모든 플레이스홀더가 존재하고, 로케일 전반에서 철자가 동일하며 의도한 포맷인지 검증(예: "12 Jan" vs "12/01").
• 일부 필드를 의도적으로 제거해 폴백 동작을 테스트(이름 없음, 배송 창 없음 등)하고 메시지가 자연스럽게 읽히는지 확인.
• 실제 기기와 미리보기에서 길이 확인, 특히 잘리거나 분할되는 SMS와 채팅을 중점적으로 체크.
• 제목과 제목 행이 잘려도 의미가 통하는지 확인.
• 트리거부터 최종 전송 메시지까지 로케일별로 최소 한 번은 엔드 투 엔드 테스트 실행.

채널 현실감 체크도 하세요. 이메일에서는 친근해 보이는 문장이 SMS에서는 공격적으로 느껴질 수 있고, 채팅에서는 미리보기 때문에 첫 문장이 더 명확해야 합니다.

예: 주문 업데이트를 영어와 스페인어로 보냈더니 스페인어에서 고객 이름이 빠져 "Hola , tu pedido..."처럼 보이면 기술적 폴백("Hola,")만으로는 부족합니다. 문맥에 맞는 인간적인 폴백("Hola, gracias por tu pedido")처럼 작동하는 해결책이 필요합니다.

예시 시나리오와 실용적 다음 단계

일관성을 테스트하는 깔끔한 방법은 하나의 인텐트를 골라 세 채널로 보내보는 것입니다. 고위험 메시지로는 비밀번호 재설정과 보안 알림이 적합합니다.

두 경우 모두 동일한 소수 변수 집합을 한 번 정의하고 모든 곳에서 재사용하세요: first_name, reset_code, support_email, device_name, city, time, manage_link.

동일한 변수가 채널마다 어떻게 나타날 수 있는지, 각 채널에 맞게 유지하면서도 맞추는 예시는 다음과 같습니다.

이메일(여유 있고 따뜻한 어조):

"Hi {first_name}, we received a request to reset your password. Your code is {reset_code}. If you did not request this, secure your account here: {manage_link}."

SMS(간결, 여분 없음):

"Your reset code: {reset_code}. If this was not you, secure your account: {manage_link}"

채팅 메시지(짧고 친절):

"Password reset code: {reset_code}\nNeed help? Reply to this message or use {manage_link}."

폴백은 데이터가 없을 때 가장 문제가 됩니다. first_name이 비어 있으면 "Hi ,"를 보여주지 마세요. "Hi there," 또는 인사 생략을 사용하세요. device_name이 보안 알림에서 없으면 "New sign-in from null." 대신 "New sign-in from a new device"처럼 작성하고 나머지는 구체적으로 유지하세요: "Location: {city} at {time}."

약속은 인텐트가 일관될 때 유지됩니다. 차분하고 명확하며 과도하게 위협적이지 않은 하나의 음성 규칙을 정하고 언어와 채널 전반에 적용하세요.

실용적 다음 단계:

• 채널 중립적인 인텐트별 소스 버전 하나를 작성하세요.
• 기본값과 누락 값 테스트가 포함된 변수 사전을 만드세요.
• 채널별 제한을 정하고 의미를 바꾸지 않고 문구를 조정하세요.
• 소규모 테스트(사용자 5명, 언어 2개, 채널 3개)를 실행해 모든 출력이 실제 사람이 쓴 것처럼 읽히는지 확인하세요.

AppMaster(appmaster.io)에서 이러한 흐름을 빌드·오케스트레이션 한다면 주요 이점은 공유 데이터 모델과 워크플로 로직을 템플릿과 가깝게 유지해 변수가 일관되게 유지되며 동일한 인텐트에서 이메일, SMS, 채팅 출력을 생성할 수 있다는 점입니다.