UI/UX 가이드
이 문서는 앱인토스 미니앱을 디자인하고 개발할 때 지켜야 할 UI/UX 기준을 한 곳에 모은 가이드예요.
브랜드 로고·이름·컬러 설정 방법부터 다크패턴 방지 정책, UX 라이팅 원칙, 그래픽 리소스 활용법, 해상도 설계 기준까지 순서대로 안내해요.
서비스를 출시하기 전에 각 항목을 꼼꼼히 확인하고 적용해 주세요.
미니앱 브랜딩 가이드
앱인토스 서비스가 토스와 명확히 구분되는 브랜드 경험을 전달할 수 있도록 준비한 기준들이에요.
사용자가 토스와 앱인토스를 혼동하지 않도록 하는 데 중요한 기준이니, 꼭 가이드를 읽고 지켜주세요.
1. 브랜드 로고 / 이름 / 컬러
브랜드 로고, 브랜드 이름, 브랜드 컬러를 토스와 앱인토스 화면 곳곳에 노출해 사용자가 브랜드를 분명하게 인지할 수 있게 해요.
브랜드 로고
파트너사의 로고는 전체탭, 혜택탭, 푸시, 알림, 내비게이션, 브릿지에 보여져요.
아래에 첨부된 이미지 또는 일러스트 파일을 반드시 사용해 로고를 제작해 주세요.
App_in_Toss_Logo_Guide_600_600.ai
로고 제작과 적용 시 다음 기준을 지켜주세요.
- 크기는 600×600px의 각진 정사각형이어야 해요. 모서리가 둥근 형태는 사용할 수 없어요.
- 로고 뒤에는 반드시 배경이 있어야 하며, 라이트 모드와 다크 모드 모두에서 잘 보이는 배경 색상을 사용해요.
- 애니팡처럼 로고 자체에 배경이 포함된 경우에는 이미지를 600×600px 영역에 꽉 차게 배치해요.
- 앱인토스 콘솔에 로고 파일을 업로드하고,
granite.config.ts파일 상단의appsInToss함수에서brand.icon속성에 동일한 로고 링크를 입력해요.
브랜드 이름
브랜드 이름은 전체 탭, 혜택 탭, 푸시, 알림, 내비게이션, 브릿지에 노출돼요.
특별한 이유가 없다면 한글로 작성해 주세요.
예를 들면 토스는 가능하지만 Toss는 권장하지 않아요.
- 앱인토스 콘솔에 브랜드 이름을 입력해요.
granite.config.ts파일 상단의appsInToss함수에서brand.displayName속성에 동일한 브랜드 이름을 입력해요.
브랜드 컬러
브랜드 컬러는 토스 내 진입점, 브릿지, 버튼(토스 디자인 시스템 사용 시) 등에 사용돼요.
브랜드 컬러 설정 기준은 다음과 같아요.
- 이미 브랜드 컬러가 있다면 그대로 사용해요.
- 브랜드 컬러가 없다면 로고에서 가장 많이 사용된 색상을 선택해요.
- 선택이 어렵다면 컬러 추출 사이트를 사용해 로고 이미지에서 대표 색상을 뽑아도 좋아요.
- 브랜드 컬러가 색 대비 기준을 충족하지 못하면, 기존 색상을 최대한 유지하면서 자동으로 보정돼요.
granite.config.ts파일 상단의appsInToss함수에서brand.primaryColor속성에#을 포함한 여섯 자리 헥스 코드 값을 입력해요.
예를 들면#3182F6처럼 입력해요.
2. 내비게이션 바
내비게이션 바는 화면 상단에 고정되는 영역으로, 앱인토스 전용 컴포넌트를 제공해요.
입점하는 서비스의 유형에 따라 아래 가이드를 참고해 내비게이션 바를 설정해 주세요.
3. 탭바
탭바는 필수 컴포넌트는 아니에요.
다만 탭바가 필요하다면, 반드시 토스에서 제공하는 플로팅 형태의 탭바를 사용해서 직접 구현해야 해요.
자체 UI를 사용하더라도 탭바만큼은 제공된 형태에 맞춰 구현해 주세요.
토스 메인 화면의 기본 하단 탭과 형태가 겹치면, 사용자가 현재 위치를 헷갈릴 수 있기 때문이에요.
탭바 설정 시 다음 기준을 지켜주세요.
- 탭 개수는 최소 2개, 최대 5개까지 사용할 수 있어요.
- 토스에서 제공하는 플로팅 형태를 유지해야 해요.
다크패턴 방지 정책
토스 사용자는 어디서든 일관되고 신뢰할 수 있는 사용 경험을 기대해요.
서비스마다 기준이 달라지면 사용자는 혼란을 느끼고, 이는 서비스 전반에 대한 신뢰 저하로 이어질 수 있어요.
UX 가이드라인은 창의성을 제한하기 위한 규칙이 아니라, 사용자에게 예측 가능하고 편리한 경험을 제공하기 위한 최소한의 기준이에요.
이를 위해 토스는 반드시 지켜야 할 최소한의 사용 경험 기준을 정했고,
아래 사례들은 이 기준을 벗어난 치명적인 사용성 오류로, 앱인토스 서비스로 출시할 수 없는 경우에 해당해요.
1. 서비스에 진입하자마자 바텀시트가 뜨는 경우
서비스에 들어오자마자
사용자가 기대한 화면 대신 전면을 가로막는 광고성 바텀시트가 노출되는 경우예요.
알림 동의를 요청하는 바텀시트도 여기에 포함돼요.
사용자는 서비스에 진입한 순간, 자신이 의도한 목적을 바로 수행할 수 있기를 기대해요.
이때 예상하지 못한 인터럽트가 나타나면 몰입이 끊기고, 서비스를 바로 이탈할 가능성이 높아져요.
2. 뒤로 가기 버튼을 눌렀을 때, 이전 화면을 막는 바텀시트가 뜨는 경우
사용자가 이전 화면으로 돌아가 다른 서비스를 탐색하려는 순간,
예상과 달리 알림 동의를 유도하는 바텀시트가 노출되는 경우를 말해요.
이탈을 막기 위해 의도적으로 설계된 추가 인터럽트는 사용자에게 자율성이 침해된다는 인상을 줄 수 있어요.
이 경험은 서비스에 대한 신뢰를 떨어뜨릴 수 있어요.
3. 나갈 수 있는 선택지가 없는 경우
파트너사가 유도한 CTA를 선택하는 것 외에는 사용자가 다른 선택을 할 수 없는 구조를 의미해요.
이처럼 거절할 수 없는 설계는 사용자에게 강제적으로 느껴질 수 있어요.
결과적으로 서비스에 대한 반감과 불신으로 이어질 가능성이 높아요.
4. 예상하지 못한 순간에 광고가 노출되는 경우
사용자가 아이템을 받기 위해 메뉴를 선택했는데,
예상과 달리 전면 광고가 노출되는 경우예요.
사용 흐름 중 갑작스럽게 등장하는 광고는 몰입을 방해하고,
서비스와 브랜드에 대한 불쾌한 인상을 남길 수 있어요.
5. CTA 버튼만 보고 다음 행동을 예상할 수 없는 경우
CTA에 이미 화면에서 설명한 가치를 그대로 반복해서 사용해,
버튼을 눌렀을 때 어떤 화면이나 행동으로 이어지는지 알 수 없는 경우예요.
CTA는 사용자가 다음에 무엇을 하게 되는지 명확하게 알려주는 장치예요.
버튼 라벨이 모호하거나 설명만 반복하면 사용자는 클릭 결과를 예측하지 못해 불안함을 느껴요.
이 불안함은 클릭을 망설이게 만들고, 결국 전환율 저하로 이어질 수 있어요.
또한 CTA 위에 과장되거나 중복된 보조 설명을 함께 노출하면
버튼의 역할이 흐려지고, 사용자에게 혼란을 줄 수 있어요.
UX 라이팅
본 가이드라인은 토스 앱의 보이스톤을 적용한 문구를 쓸 수 있도록 제공된 지침이에요.
아래 가이드라인을 지켜주세요.
1. 해요체
제품 안의 모든 문구는 '해요체'로 써요.
일관성 있는 사용자 경험을 만들 수 있도록 상황, 맥락을 불문하고 모든 문구에 해요체를 적용해주세요.
2. 능동적 말하기
제품 안에서 최대한 능동형 문장을 써주세요. 수동형 문장은 특정 상황에서만 쓰는 게 좋아요.
됐어요 → 했어요
'~었' 빼기
동사 바꿔쓰기
3. 긍정적 말하기
제품 안에서 부정적 커뮤니케이션을 최대한 줄이고 긍정형 문장을 써주세요.
예 : 안 돼요, 없어요 (X) → ~하면 할 수 있어요 (O)
없어요 → 있어요
에러 메시지
다이얼로그 왼쪽 버튼은 [닫기]
다이얼로그 왼쪽 버튼은 닫기로 문구를 통일해요. 취소는 사용자가 하고 있는 작업이 취소된다고 오해할 수 있어 쓰지 않아요.
혜택을 받을 수 없을 때
혜택 대상 안내
서비스는 쓸 수 있지만, 특정 혜택은 받을 수 없을 때 → 긍정형 문장
사용자는 스캔하기 때문에 제품 전체를 쓸 수 없다고 이해하기 쉬워요.
4. 캐주얼한 경어
제품 안에서 '~시겠어요?', '시나요?', '~께' 같은 과도한 경어를 쓰지 않아요.
최대한 캐주얼하고 친근한 말투를 쓰는 게 좋아요.
동사에서 '~시' 빼기
'계시다' → '있다'
'여쭈다' → '확인하다, 묻다'
'께' → '에게'
경어를 뺐을 때 어색한 경우
사용자의 정보를 받는 질문에서 기계적으로 '~시'를 뺐을 때 문장이 어색할 수 있어요.
파악하고 싶은 정보를 '주어'로 써서 문장을 새롭게 써보세요.
5. '{명사} + {명사}' 쓰지 않기
한자어 풀어쓰기
한자어 명사를 풀어서 동사 형태로 쓸 수 있어요.
한자어를 풀어쓰기 어려울 경우
'{명사}가 {명사}해서' 형태로만 풀어줘도 더 캐주얼하게 쓸 수 있어요.
예외 규칙
수동형 문장을 써도 되는 경우
수동형 문장이 더 명확 하고 간결한 커뮤니케이션을 만드는 때도 있어요.수동형으로 더 좋은 문장을 쓸 수 있는 사례를 알려드릴게요
⚠️ 서비스 종료, 기간 만료
- 주어(종료 서비스, 기간 등)를 강조할 수 있어요.
- '종료'와 '만료'의 뉘앙스를 정확히 전달할 수 있어요.
⚠️ 사용자에게 미치는 영향을 알려줄 때
(주요 동사 : 연체, 해지, 적용 등)- 인과 관계를 명확하게 설명해요.
'사용자의 행동에 의해 따라오는 결과'라는 점을 알려줄 수 있어요.
⚠️ 사용자 안심
- '정보 수집 안내' 등의 민감한 상황에서 사용자를 안심하게 할 수 있어요.
⚠️ 되어요 (X) → 돼요 (O)
모바일 화면의 좁은 공간을 고려, '되어요'는 모두 '돼요'로 통일해서 써주세요.
경어를 써도 되는 경우
특정 상황에서 제한적으로 '시나요?, 셨나요?' 의문형 어미를 쓸 수 있어요.⚠️ 사용자의 맥락을 활용해서 질문할 때
⚠️ 사용자의 상황을 추정할 때
⚠️ 사용자의 선의가 필요할 때
부정형 문장을 써도 되는 경우
사용자에게 명확하게 부정적인 내용을 알려줘야 할 때는 부정형 문장을 써도 좋아요.⚠️ 서비스를 정책 상 쓸 수 없을 때
- 사용자에게 상황을 명확하게 인지시킬 수 있어요.
쓸 수 없는 이유를 함께 안내해주세요.
⚠️ 일부 기능만 쓸 수 없을 때
- 사용자가 어떤 기능을 쓸 수 없는지 명확하게 인지 할 수 있어요.
- 사용자 선택의 결과를 명확하게 안내할 수 있어요.
⚠️ 사용자 안심
- '정보 수집 안내' 등의 민감한 상황에서 사용자를 안심하게 할 수 있어요.
그래픽
토스에서 제공하는 그래픽 리소스와 올바른 활용 방법을 안내드려요.
그래픽 저작권 안내
토스의 모든 그래픽 자산 및 토스트를 통해 생성된 그래픽은 「저작권법」 및 관련 법령에 따라 보호받는 ㈜비바리퍼블리카의 지식재산권입니다.
제공된 그래픽은 앱인토스 제휴 환경 내에서의 서비스 운영 및 홍보 목적으로만 사용할 수 있으며, 다른 서비스나 매체에서 복제·수정·배포·전송·공중송신 등으로 활용하는 행위는 금지됩니다.
토스에서 제공하는 그래픽 리소스
1. 아이콘 & 이모지
토스에서는 약 7,000개 이상의 아이콘과 이모지 세트를 제공해요.
앱빌더와 피그마에서 디자인을 할 때 아이콘과 이모지 목록을 확인할 수 있어요.
앱빌더는 워크스페이스에서 앱을 등록한 뒤 '디자인' 메뉴에서 시작할 수 있어요.
직접 아이콘을 제작해야 한다면, 앱인토스 아이콘 제작 가이드를 참고해 기준에 맞게 만들어 주세요.
[사용 시 유의사항]
- 아이콘은 화면에서 24~40px 크기로 사용해 주세요.
- 아이콘이나 이모지를 두 개 이상 병렬로 조합하는 방식은 지양해요. 한 번에 하나만 사용해 주세요.
- 토스에서 제공하는 그래픽 리소스는 서비스 화면 내 UI 디자인 용도로만 사용할 수 있으며, 앱 로고, 썸네일 등 앱 정보에서 활용할 수 없어요.
2. 스마트폰 목업 파일
스마트폰 목업 파일
스마트폰 목업으로 리소스를 제작할 때는 위 제공된 파일을 그대로 사용해 주세요.
아이콘은 크기별로 제공되니, 임의로 크롭하거나 색상을 보정하거나 형태를 왜곡하지 말아 주세요.
디자인 업데이트 반영을 위해, 개발 시에도 아래 URL로 넣으시는 것을 권장드려요.
- Full
- Large
- Medium
- Small
3. 토스트 (AI 이미지 생성 툴)
1번에서 제공된 아이콘과 이모지를 바탕으로 3D 이미지를 생성할 수 있어요.
생성한 그래픽은 실제 화면에 사용하기 전에 토스 그래픽 디자인 팀의 사용 승인을 받아야 해요.
승인은 보통 1일 이내에 진행돼요.
4. 그 외
3D 그래픽이나 애니메이션은 토스에서 제공한 모듈에 포함된 리소스만 사용할 수 있어요.
제공 범위는 앞으로 점진적으로 확대할 예정이에요.
그래픽의 올바른 사용법
1. 문맥에 맞는 그래픽을 사용해 주세요.
그래픽은 장식이 아니라, 사용자가 화면의 의미를 더 쉽게 이해하도록 돕는 역할이에요.
2. 정보 밀도에 맞는 크기로 사용해 주세요.
단순한 그래픽은 작게, 디테일이 많은 그래픽은 충분히 크게 사용해 주세요.
3. 한 화면에 그래픽을 많이 사용하지 마세요.
비슷한 크기의 그래픽이 많아질수록 시선이 분산돼요.
가장 핵심적인 그래픽 하나만 사용하고, 나머지는 보조적인 그래픽이나 아이콘으로 대체해 주세요.
4. 핵심 정보를 가리지 않게 배치해 주세요.
중요한 내용이 아래로 밀려 불필요한 스크롤이 생기지 않도록 크기와 위치를 조정해 주세요.
5. 부정적이거나 호소하는 감정 표현은 피해주세요.
사용자에게 불쾌감을 주거나 애원, 호소처럼 느껴지는 표현은 다크 패턴에 해당해요.
이런 감정 표현은 사용하지 말아 주세요.
6. 장식적인 효과나 이펙트는 사용하지 마세요.
의미 없는 묘사, 파티클, 과한 그라데이션 같은 요소는 화면을 복잡하게 만들고 정보 전달을 방해해요.
7. 상황을 정확히 전달하는 그래픽을 사용해 주세요.
오류가 아닌 상황에서 느낌표 아이콘을 사용하거나,
기다릴 필요가 없는데 로딩 애니메이션을 사용하는 경우 사용자가 상황을 오해할 수 있어요.
파트너사에서 직접 그래픽을 제작할 때 유의사항
1. 토스 스타일의 일관성을 지켜주세요.
토스는 단순하고 명료하며 깨끗한 디지털 그래픽 스타일을 지향해요.
손그림 느낌, 서정적인 화풍, 만화적인 표현은 화면에서 이질적으로 보일 수 있어요.
토스의 그래픽 스타일 예시
2. 고화질의 그래픽을 사용해 주세요.
그래픽은 선명하고 깨끗한 고화질로 제작해 주세요.
해상도가 낮거나 파티클처럼 자잘한 효과가 많으면 퀄리티가 낮아 보일 수 있어요.
3. 다크 모드와 라이트 모드 모두에서 잘 보여야 해요.
토스 앱에서 사용하는 그래픽은 다크 모드와 라이트 모드 모두를 고려해야 해요.
너무 밝거나 너무 어두운 색은 특정 모드에서 잘 보이지 않을 수 있으니, 중간 명도의 색감을 사용해 주세요.
4. 화면 전체와 어울리게 구성해 주세요.
그래픽이 텍스트나 CTA 버튼 같은 다른 요소보다 튀지 않도록,
화면 전체의 컬러와 레이아웃 균형을 맞춰 주세요.
5. 긍정적이고 정돈된 인상을 주세요.
그래픽은 서비스의 안정감과 신뢰감을 만드는 데 중요한 역할을 해요.
모노톤이 과도하게 많거나, 뿌옇고 칙칙한 인상은 피하고 밝고 정돈된 느낌으로 디자인해 주세요.
해상도
이 가이드는 앱인토스 미니앱을 개발할 때 어떤 해상도를 기준으로 화면을 설계하고 최적화하면 좋은지를 안내해요.
권장 기준과 함께, 다양한 디바이스 환경에서도 안정적으로 동작하는 설계 방향을 설명해요.
앱인토스 미니앱은 여러 해상도와 화면 비율의 기기에서 실행돼요.
이 가이드는 이러한 환경 차이로 인한 혼란을 줄이기 위해,
기기별 대응이 아닌 '기준 해상도 중심 설계' 방식을 제안해요.
꼭 확인해 주세요
하나의 논리 해상도를 기준으로 설계하고 에셋을 1x·2x로 준비하면,
앱인토스 실제 트래픽의 대부분을 안정적으로 커버할 수 있어요.
앱인토스 미니앱 풀스크린 설계 기준
앱인토스의 게임 미니앱은 풀스크린 구현이 필수예요.
풀스크린 환경에서는 다음을 반드시 고려해야 해요.
- 콘텐츠가 화면을 완전히 채워야 해요.
- 웹뷰 여백이나 반투명 영역이 남지 않아야 해요.
- 기기 회전에 따라 비율이 깨지거나 레터박스(검은 여백)가 생기면 안 돼요.
- 노치, 카메라 홀, Dynamic Island는 Safe Area로 처리해야 해요.
- 스케일링으로 인해 에셋 품질이 눈에 띄게 저하되지 않아야 해요.
그래서 해상도는 기기마다 다르게 맞추기보다,
하나의 기준 해상도를 정하고 스케일링으로 대응하는 방식이 중요해요.
해상도를 바라보는 두 가지 기준
앱인토스 미니앱에서는 해상도를 아래 두 가지로 나누어 생각하는 것을 권장해요.
① 논리 해상도 (Logical Resolution)
UI 배치와 좌표 계산, 게임 로직의 기준이 되는 해상도예요.
- 실제 디바이스 픽셀 해상도와는 다른 개념이에요.
- 논리 해상도는 하나만 선택하는 것을 권장해요.
- 모든 디바이스에서 동일한 플레이 감각과 화면 구성을 유지해야 해요.
② 에셋 해상도 (Asset Resolution)
이미지, 배경, 캐릭터, UI 리소스의 픽셀 밀도를 의미해요.
- 디바이스별로 에셋을 따로 준비할 필요는 없어요.
- 소수의 해상도 그룹으로 묶어 관리하는 방식이 효율적이에요.
앱인토스 권장 해상도 기준
① 논리 해상도 권장 범위
아래 범위 중 하나를 기준 해상도로 선택해 주세요.
- 세로형 미니앱: 약 360 × 640 ~ 420 × 740
- 가로형 미니앱: 약 640 × 360 ~ 740 × 420
이 범위 안에서 하나의 기준 해상도를 정하고, 기기 간 차이는 스케일링으로 대응하는 방식을 권장해요.
② 에셋 해상도 권장 기준
에셋은 그룹 단위로 준비하는 것이 좋아요.
- 1x 에셋: 기본 해상도 대응
- 2x 에셋: 고해상도 디바이스 대응
그래픽 품질이 특히 중요한 경우에만 3x 에셋을 선택적으로 추가해 주세요.
꼭 확인해 주세요
대부분의 미니앱은 1x + 2x 구성만으로 충분해요.
에셋 해상도를 과도하게 나누면 메모리 사용량 증가, 로딩 지연, 유지보수 비용 증가로 이어질 수 있어요.
데이터 기반 참고 사항
이 가이드는 앱인토스 실제 서비스 환경에서 수집된 디바이스 해상도 데이터를 기반으로 정리했어요.
- 전체 미니앱 트래픽의 약 70~80% 가 가로 약 800~900, 세로 약 360~420 범위의 viewport 해상도에 집중돼 있어요.
- 나머지 트래픽은 다양한 해상도로 분산된 롱테일 형태예요.
그래서 모든 해상도를 개별 대응하기보다,
대표적인 해상도 범위를 기준으로 설계하는 방식이 가장 효율적이에요.
테스트 기기 가이드
모든 디바이스에서 테스트할 필요는 없어요.
아래 조건을 만족하는 대표 기기 3~5종이면 충분해요.
- 화면 비율이 서로 다른 기기 2~3종
- Safe Area가 크게 적용되는 기기 1종
- 비교적 작은 화면 크기의 기기 1종
권장하지 않는 방식
다음과 같은 방식은 피해주세요.
- 디바이스 모델별로 다른 논리 해상도를 사용하는 방식
- 실제 픽셀 해상도를 기준으로 UI나 좌표를 계산하는 방식
- 필요 이상으로 많은 에셋 해상도 그룹을 운영하는 방식
- 해상도마다 다른 UI 레이아웃을 유지하는 방식
이런 접근은 UI 깨짐, 레터박스 발생, 유지보수 비용 증가로 이어질 수 있어요.