비주얼캠프 · 천지문

UI 디자인Flutter 적용

글꼴은 Pretendard 하나로 두고 글자 크기는 iOS와 Android 각자의 기준을 따랐습니다

문제
두 OS는 글자 크기 단위 · 기본 크기 · 글자 키우기 방식이 모두 달라 한 벌의 디자인 값으로는 한쪽 앱이 OS 기준과 어긋납니다.
결정
글꼴(Pretendard)만 공통으로 두고 글자 크기 · 줄 간격 · 단위 · 내비게이션은 iOS(HIG)와 Android(Material 3) 기준을 따로 따릅니다.
결과
글자 스타일 16종을 OS별 두 벌로 만들어 변수로 연결. 같은 상황의 모달 24개를 OS마다 따로 만들어 48개.
클라이언트
비주얼캠프 · 천지문 (출시된 앱)
역할
UI 디자인 · 디자인 적용 코드(Flutter)
범위
iOS · Android · 화면 16종 · 모달 24종씩
도구
Figma 변수 · Flutter · HIG · Material 3

실제 앱 화면

iOS / Android 설계 차이

iOSHIG

읽는 힘

display 34/41pt

지문을 끝까지 읽고 글쓴이가 가장 하고 싶은 말을 한 문장으로 찾아봅니다.

reading 17/30pt

오늘의 지문 1편

body 17pt + Dynamic Type
AndroidMaterial 3

읽는 힘

display 36/44sp

지문을 끝까지 읽고 글쓴이가 가장 하고 싶은 말을 한 문장으로 찾아봅니다.

reading 18/32sp

오늘의 지문 1편

body 16sp + 시스템 글꼴 배율

서체는 Pretendard 하나로 두고 크기 · 행간 · 단위만 OS를 따랐습니다. 플랫폼마다 타입 스케일 16종을 변수로 연결했고 글자를 키워도 본문을 고정 높이로 자르지 않고 줄바꿈 · 스크롤을 허용한다는 규칙을 파일에 적었습니다.

피그마 파일의 값으로 다시 그린 도식입니다. 화면 속 문구는 예시입니다.

  1. 문제

    iOS와 Android에 동시에 출시할 앱이었습니다. 두 OS는 글자 크기 단위(pt · sp)와 기본 크기(본문 17pt · 16sp), 사용자가 시스템에서 글자를 키우는 방식(Dynamic Type · 글꼴 배율)이 모두 다릅니다. 한 벌의 디자인 값으로 두 앱을 만들면 한쪽은 OS 기준과 어긋나고 큰 글자 설정에서는 본문이 잘릴 위험이 있었습니다.

  2. 대안 검토

    • 두 앱 공통 값 한 벌관리는 쉽지만 한쪽 OS 기준을 어깁니다.
    • 글꼴(Pretendard)만 공통으로 두고 크기 · 줄 간격 · 단위는 OS별 두 벌같은 앱처럼 보이면서 OS 기준도 지킵니다.선택
  3. 실행

    iOS는 pt와 Dynamic Type을 기준으로 삼고 Android는 sp와 시스템 글꼴 배율을 기준으로 플랫폼별 타입 스케일 16종씩을 변수로 연결했습니다.

    간격과 터치 토큰을 플랫폼 모드로 나눴습니다. 최소 터치 영역은 44×44pt / 48×48dp이고 Android는 8dp · 4dp 그리드를 따릅니다. 상단 바 좌우 여백은 iOS 24pt · Android 16dp로 두었습니다.

  4. 모달 체계

    같은 시나리오 24개를 플랫폼 관례에 맞춰 각각 만들어 모두 48개입니다. iOS는 시트와 Alert로 Android는 bottom sheet와 Dialog로 나누고 시트 · 확인 · 상태 세 갈래로 정리했습니다.

  5. 근거 기록

    공식 규격과 제품 결정을 구분해 기록했습니다. 'HIG는 모든 gap을 단일 고정값으로 지정하지 않음', '헤더 24/16은 이 파일의 제품 결정'처럼 근거와 결정을 나눠 적고 Apple · Android 공식 문서를 함께 달았습니다.

    민감한 권한 요청 흐름(권한 거절 · 대기 · 단계별 안내)도 실패 경로까지 두 플랫폼에 각각 설계했습니다.