Toolbar · Text · Tab Bar · Sheets · Safe Area Bar · System Materials · Menu 목차별 설명 — 언제 · 기준 · 설계 의도
원래 목차 구조를 그대로 유지하고, 각 항목마다 다섯 가지를 달았습니다:
어느 상황에서 사용하는가 /
이렇게 해야하는 이유 /
TIP 실무 참고 /
적절한 예 실제 앱 기준 좋은 사례 2개 /
잘못된 예 흔한 오용 사례 2개 /
참고 자료 해당 항목의 근거 출처.
각 항목 오른쪽의 미니 프리뷰는 해당 요소가 화면 어디에 놓이는지(파란 하이라이트)를 보여줍니다.
본문은 iOS 26(WWDC25) 기준이며, 그 이후 바뀐 내용은 iOS 27 업데이트 행으로 구분해 반영했습니다 (WWDC26 발표 + iOS 27 베타·보도 기준, 최종 업데이트 2026-07-17). 전체 출처는 참고자료 페이지에 있습니다. 왼쪽 목차를 누르면 해당 항목 페이지로 바로 이동합니다.
trailing에 아이템이 폭보다 많을 때, 시스템이 나머지를 … (overflow) 메뉴로 자동으로 접는 동작.
어느 상황에서 사용하는가
액션이 4개 이상으로 많은 화면. 노출할 소수의 핵심과 접어도 되는 다수를 나눌 때. 드물게 쓰는 액션·파괴적 액션(삭제)은 의도적으로 overflow 안으로.
이렇게 해야하는 이유
두 원칙의 타협 — 기능은 다 제공하되(완전성), 화면은 어지럽히지 않는다(content-first). 또한 버튼을 무한정 줄여 넣으면 터치 타깃이 손가락 크기 이하로 작아지므로, 시스템이 자동으로 접어 최소 타깃 크기를 보장. "많으면 접는다"가 기본 동작인 이유.
Tip
overflow에 뭐가 들어갈지는 선언 순서/우선순위로 제어 가능. "자주 쓰는 걸 접어버리는" 상황이 안 되게 순서를 설계하세요.
iOS 27 업데이트
WWDC26에서 visibilityPriority(_:)가 추가되어, 공간이 좁아질 때 어떤 아이템을 화면에 남길지 우선순위를 직접 지정할 수 있습니다. overflow 메뉴 구성도 ToolbarOverflowMenu로 제어 가능 — "자주 쓰는 게 접히는" 문제를 API 차원에서 해결한 것.
적절한 예
① 문서 앱 — 핵심 2개(공유·편집)만 노출하고 내보내기·인쇄·버전 기록은 overflow로 ② 삭제를 의도적으로 overflow 안에 둠(오조작 방지)
잘못된 예
① 가장 자주 쓰는 저장이 선언 순서 탓에 overflow로 접힘 ② overflow를 피하려고 아이콘 7개를 우겨넣어 터치 타깃이 손가락보다 작아짐
이 기능이 존재하는 근본 이유: 툴바가 반투명 유리로 콘텐츠 위에 떠 있기 때문에, 그 밑을 지나가는 콘텐츠와 겹치면 컨트롤이 안 보일 수 있음. 가장자리 효과는 가독성을 지키는 안전장치라서 기본으로 켜져 있습니다. 선택 기준은 하나 — "바 뒤로 지나갈 콘텐츠가 얼마나 복잡한가."
1.3.1
Soft
경계 없이 부드럽게 번지는(diffused) 페이드. 콘텐츠가 유리 아래로 은은하게 사라짐.
어느 상황에서 사용하는가
대부분의 일반 화면. 텍스트 목록, 카드 피드처럼 평범한 밝기·대비의 콘텐츠. 고민되면 soft(=automatic이 주로 택하는 값).
이렇게 해야하는 이유
경계선은 그 자체로 시각 요소라 UI의 존재감을 늘림. 콘텐츠가 "잘리는" 게 아니라 "스며드는" 표현이 유리라는 재질 은유와 맞고, 몰입을 덜 깨기 때문에 이것이 기본값.
Tip
soft에서 컨트롤 가독성이 부족하게 느껴지면 그때 hard로 올리는 순서로 결정하세요.
적절한 예
① 텍스트 목록·카드 피드 등 평범한 콘텐츠의 기본값으로 ② 이미지가 적은 설정류 화면
잘못된 예
① 표·그리드처럼 구획이 중요한 화면에 soft — 경계 위치가 흐림 ② 하단 입력창 위에 soft — 입력 영역의 시작점이 모호
Placement: Toolbar (w/ an item in the bottom toolbar)
하단 툴바에서 검색 필드와 다른 버튼이 공존하는 구성.
어느 상황에서 사용하는가
검색도 자주 쓰고 작성·필터 같은 액션도 자주 쓰는 화면 — 메일함(검색+새 메일), 메모(검색+새 메모)가 전형.
이렇게 해야하는 이유
고빈도 기능이 둘 이상이면 둘 다 하단에 있어야 reachability가 일관됨. 이때 DefaultToolbarItem(kind:.search)으로 검색의 자리를 명시하고 ToolbarSpacer로 분리 — 검색(입력)과 버튼(액션)은 성격이 다르므로 다른 캡슐로 보이게 하는 것.
Tip
하단에 검색+버튼 2개 이상이면 과밀입니다. 검색 + 핵심 액션 1개가 균형점.
적절한 예
① 메일함 — 검색 캡슐 + 작성 버튼을 별도 캡슐로 분리 ② 노트 목록 — 검색 + 새 노트 버튼 공존
잘못된 예
① 검색 필드와 액션 버튼을 같은 캡슐에 묶음(입력과 액션 혼합) ② 하단에 검색+버튼 3개 — 캡슐 과밀로 오탭 유발
Integrating System Search Bar w/ Other Toolbar Items
시스템 검색바를 다른 툴바 아이템들과 한 툴바 체계 안에 통합 — 자리 확보·분리·축소를 조합.
어느 상황에서 사용하는가
검색과 여러 액션이 공존하되 검색이 항상 클 필요는 없는 화면. 도구 조합: DefaultToolbarItem(.search)(자리), ToolbarSpacer(분리), searchToolbarBehavior(.minimize)(평소엔 돋보기 버튼으로 축소, 탭하면 확장).
이렇게 해야하는 이유
"기능은 제공하되 평소엔 물러난다"는 minimization 원칙의 검색 버전. 검색이 조연인 화면에서 풀사이즈 검색바는 공간 낭비 — 버튼 크기로 접어두면 다른 액션에 공간을 양보하면서도 한 탭 거리 유지. overflow가 버튼에 하는 일을 검색바에 하는 것.
Tip
.minimize는 "검색을 숨기는" 게 아니라 "접는" 것 — 검색을 거의 안 쓰는 화면이라면 애초에 searchable을 빼는 게 맞습니다.
적절한 예
① 브라우저 — 검색은 minimize로 접고 탭·공유 버튼과 공존 ② 파일 앱 — 축소된 검색 + 정렬·보기 버튼 조합
잘못된 예
① 검색을 거의 안 쓰는데 minimize로라도 상시 배치(searchable 자체가 불필요) ② 축소된 돋보기 옆에 비슷한 아이콘(필터)을 붙여 혼동 유발
텍스트는 콘텐츠 길이를 예측할 수 없다는 게 본질입니다. 다섯 케이스는 전부 "공간은 유한한데 텍스트는 가변"이라는 하나의 문제에 대한 서로 다른 답 — 자른다(limit·truncation), 줄인다(scale), 예약한다(range), 그리고 선택하게 한다(selection).
2.1.1
Line Limit
lineLimit(n) — 텍스트가 차지할 수 있는 최대 줄 수를 고정. 넘치는 내용은 잘림.
어느 상황에서 사용하는가
목록 셀·카드 미리보기처럼 레이아웃 높이가 일정해야 하는 곳. 메일 목록의 본문 2줄 미리보기, 뉴스 카드의 제목 2줄이 전형. "전문은 상세 화면에서"가 전제일 때.
이렇게 해야하는 이유
SwiftUI Text의 기본은 무제한 줄바꿈 — 콘텐츠를 자르지 않는 게 원칙이기 때문. 하지만 목록에서 셀마다 높이가 다르면 스캔 리듬이 깨지고 한 화면에 보이는 항목 수가 줄어듦 → 목록의 목적은 훑기(scan)이지 정독이 아니므로, 미리보기 맥락에선 개발자가 명시적으로 제한하는 설계.
Tip
Dynamic Type 큰 글씨 설정에서는 같은 문장도 더 많은 줄을 차지합니다. lineLimit을 정할 땐 접근성 글자 크기에서 핵심 정보가 살아남는지 확인하세요.
적절한 예
① 피드의 본문 미리보기를 lineLimit(3)으로 통일 ② 목록 셀 제목을 1줄로 고정해 행 높이 일정 유지
잘못된 예
① 주소·금액 같은 핵심 정보가 잘리는데 전체 보기 경로가 없음 ② 접근성 큰 글씨 설정에서 1줄 고정+축소가 겹쳐 사실상 판독 불가
minimumScaleFactor(0.5) (+ lineLimit(1)) — 자르는 대신 글자 크기를 줄여서 공간에 맞춤.
어느 상황에서 사용하는가
전체가 보여야만 의미 있는 짧은 값 — 타이머 숫자, 금액, 온도, 버튼 라벨. "12:34:5…"처럼 잘리면 정보가 파괴되는 종류의 텍스트.
이렇게 해야하는 이유
truncation과 scale은 같은 문제의 반대 해법 — 잘라도 뜻이 통하면 자르고(문장), 잘리면 뜻이 죽으면 줄인다(값·수치). 시스템이 자동으로 정하지 않고 개발자에게 맡기는 이유는, 텍스트가 "문장"인지 "값"인지는 의미론이라 코드만으로 판단할 수 없기 때문.
Tip
scaleFactor가 0.5 밑으로 내려가야 들어간다면 축소가 아니라 설계 문제입니다 — 폭을 늘리거나 표기 자체를 줄이는(예: 1,234,000 → 1.2M) 쪽을 검토하세요. 같은 줄의 이웃 텍스트와 크기가 어긋나 보이는 부작용도 확인.
적절한 예
① 타이머·계기판의 큰 숫자 — 길이가 변해도 한 줄 유지 ② 로컬라이즈로 길이가 널뛰는 버튼 라벨의 안전장치
잘못된 예
① 본문 문단에 적용해 화면마다 글자 크기가 제각각 ② minimumScaleFactor(0.3) 같은 과도한 축소 허용 — 가독성 파괴
textSelection(.enabled) — 읽기 전용 텍스트를 길게 눌러 선택·복사할 수 있게 허용.
어느 상황에서 사용하는가
사용자가 가져다 쓸 가치가 있는 텍스트 — 주소, 전화번호, 쿠폰·인증 코드, 오류 메시지, 인용문. "이걸 복사하고 싶을까?"에 예스면 켜기.
이렇게 해야하는 이유
기본이 비활성인 이유 — UI의 텍스트 대부분은 라벨(장치의 일부)이지 콘텐츠(데이터)가 아니기 때문. 버튼 이름이 선택되기 시작하면 롱프레스 제스처(컨텍스트 메뉴 등)와 충돌하고 화면 전체가 "문서"처럼 행동하게 됨. 선택 가능 여부 자체가 "이건 데이터다"라는 신호.
Tip
iOS에서는 부분 선택이 아니라 해당 텍스트 전체가 한 번에 복사됩니다. 코드·주소처럼 통째로 쓰는 값에 적합하고, 긴 본문의 부분 인용이 필요하면 다른 UX(공유 시트 등)를 고려하세요.
적절한 예
① 오류 코드·주문번호처럼 복사해 쓸 값에 허용 ② 약관·주소 등 참조용 텍스트에 허용
잘못된 예
① 버튼 라벨에 선택 허용 — 탭과 길게 누르기가 충돌 ② 운송장 번호에 미적용 — 사용자가 화면 보며 수기로 옮겨 적음
핵심 원칙은 하나 — 데이터를 문자열로 직접 조립하지 말 것. 단위·이름·날짜·숫자는 문화권마다 표기 규칙이 다르므로, FormatStyle에 데이터를 주고 표기는 시스템에 맡기는 것이 이 API 군의 존재 이유.
2.2.1
Format Styles (Units)
Text(measurement, format: .measurement(width: .wide)) — Measurement 값(길이·무게·온도)을 로케일에 맞는 단위 표기로 자동 변환.
어느 상황에서 사용하는가
거리·무게·온도·속도 같은 단위 있는 수치를 보여주는 모든 곳 — 운동 거리 "5 km", 날씨 "23°C", 몸무게 기록. 특히 글로벌 출시 앱이라면 선택이 아니라 필수.
이렇게 해야하는 이유
"\(value) km" 식의 문자열 조립은 미국 사용자에게 마일 대신 킬로미터를 강요하는 국제화 버그. Measurement + FormatStyle은 값과 표기를 분리해, 같은 데이터가 로케일에 따라 "5 kilometers" / "3.1 miles" / "5킬로미터"로 렌더링됨. 단위 환산·복수형·기호 위치까지 시스템이 책임지므로 앱은 값만 소유하면 됨.
Tip
width로 밀도를 고르세요 — .wide("5 kilometers", 문장 속), .abbreviated("5 km", 목록·라벨), .narrow("5km", 좁은 공간). 시뮬레이터 로케일을 en_US로 바꿔 마일 변환까지 확인하는 게 검증 포인트.
적절한 예
① 러닝 앱의 거리 — 로케일 따라 km/mi 자동 전환 ② 날씨 온도 — °C/°F를 시스템 설정에 위임
잘못된 예
① “\(value) km” 문자열 하드코딩 — 마일 사용권 사용자에게도 km ② 단위 변환을 직접 구현해 반올림·표기 오류 발생
PersonNameComponents + .name(style:) — 사람 이름을 성·이름 구성요소로 다루고 표기 순서는 시스템에 위임.
어느 상황에서 사용하는가
사용자·연락처·참여자 등 사람 이름이 화면에 나오는 모든 곳. 전체 이름, 목록의 축약 이름, 아바타 이니셜까지 이름 표기가 필요한 자리 전부.
이렇게 해야하는 이유
"이름 성"(John Appleseed) 순서 하드코딩은 한국·일본·중국·헝가리에서 틀린 표기(홍길동을 "길동 홍"으로) — 이름 순서는 데이터가 아니라 문화권 규칙이기 때문. components(givenName·familyName)로 저장하고 표기는 로케일이 결정하게 하면, 같은 데이터가 문화권마다 올바른 순서로 나옴.
Tip
style로 용도를 구분 — .long(경칭 포함), .medium(기본 전체 이름), .short(친근한 호칭), .abbreviated(이니셜 "JA" → 아바타에 최적). 이름을 firstName/lastName 문자열 두 개로 저장하고 있다면 PersonNameComponents로의 이관부터가 시작입니다.
적절한 예
① 연락처 표시 — 한국어는 성-이름, 영어는 이름-성 순서 자동 ② 이니셜 아바타에 .abbreviated 스타일 활용
잘못된 예
① “\(first) \(last)” 하드코딩 — 동아시아 이름이 역순으로 표기 ② 표시용 문자열을 정렬 키로 사용 — 성/이름 기준이 뒤죽박죽
.tabBarMinimizeBehavior(.onScrollDown) — 아래로 스크롤하면 탭바가 작게 접힘, 위로 스크롤하면 복원.
어느 상황에서 사용하는가
콘텐츠 몰입이 중요한 피드·리더형 화면. “아래로 스크롤 = 읽는 중, 위로 = 탐색 복귀”가 성립하는 앱.
이렇게 해야하는 이유
Liquid Glass의 minimization 원칙을 탭바에 적용한 것 — 이동 장치는 이동할 때만 크면 됩니다. 스크롤 방향으로 사용자 의도를 추론하며, 사라지는 게 아니라 접히는 것이라 위치 단서는 유지됨.
Tip
탭 전환이 잦은 앱(메신저 등)에선 오히려 방해입니다. 콘텐츠 소비형 화면에만 켜세요.
iOS 27 업데이트
Apple이 방향을 일부 수정했습니다 — iOS 27 베타에선 뮤직·팟캐스트 등 자체 앱들의 스크롤 축소 동작을 제거하고 탭바를 항상 노출하는 쪽으로 회귀 중("복원에 탭 한 번을 더 쓰게 하는 건 우아한 애니메이션보다 나쁘다"는 피드백 반영). API 자체는 유지되지만, 새로 만드는 앱이라면 minimize 채택을 더 보수적으로 판단하세요.
적절한 예
① 읽기 몰입형 뉴스·아티클 피드 ② 세로 스크롤 영상 피드 — 소비 중 이동이 드묾
잘못된 예
① 탭 전환이 잦은 메신저에 적용 — 전환마다 복원 동작 필요 ② 스크롤이 거의 없는 짧은 화면에 적용 — 동작만 거슬림
Tab(role: .search) — 시스템이 검색 탭을 인식해 다른 탭과 분리된 유리 캡슐(오른쪽)로 배치. iOS 26 신규.
어느 상황에서 사용하는가
iOS 26에서 검색 탭을 둘 때의 새 표준. 역할만 선언하면 위치·모양·전환 동작을 시스템이 알아서 처리.
이렇게 해야하는 이유
탭은 “장소 이동”이지만 검색은 “모드 진입” — 성격이 다른 것을 시각적으로도 분리(별도 캡슐)해 OS 전체에서 일관되게 표현한 것. 탭하면 캡슐이 그 자리에서 검색 필드로 변형되어, 화면 이동 없이 모드가 전환됩니다.
Tip
role만 선언하고 위치·모양 커스텀은 하지 마세요 — 시스템 규약에서 벗어나면 사용자의 기대가 깨집니다.
iOS 27 업데이트
iOS 27에선 Apple 자체 앱들(뮤직·팟캐스트·TV·뉴스 등)이 검색 탭을 다시 메인 탭 줄로 통합하는 방향 수정이 보도·베타에서 확인됩니다. 분리 캡슐이 "새 표준"에서 "선택지 중 하나"로 위상이 조정되는 중 — 검색이 정말 별도 모드인지(이 섹션 서두의 질문)를 더 엄격히 물은 뒤 채택하세요.
적절한 예
① 스트리밍 앱 — 검색을 별도 모드로 보고 분리 캡슐 채택 ② role만 선언하고 위치·모양·전환은 시스템에 위임
잘못된 예
① 분리 캡슐의 위치·모양을 커스텀 — 시스템 규약 이탈 ② 검색 캡슐 자리를 흉내내 작성 버튼을 배치(자리 오용)
Tab(role: .prominent) — search role 전용이던 trailing 분리 캡슐 자리를 일반 탭에도 개방. 시스템이 해당 탭에 추가 시각 강조를 적용.
어느 상황에서 사용하는가
앱에서 특별히 강조하고 싶은 핵심 목적지가 하나 있을 때 — 장바구니, 티켓, 여행, 결제 내역처럼 “자주 가는 장소”. 검색이 아닌 탭도 분리 캡슐에 둘 수 있게 된 iOS 27의 확장.
이렇게 해야하는 이유
iOS 26에서 분리 캡슐이 검색 전용이자 “버튼처럼 생긴 자리”가 되자, 개발자들이 이 자리를 작성·업로드 버튼으로 오용하는 패턴이 퍼짐 → Apple이 “강조된 목적지”라는 공식 경로를 열어 수요를 흡수한 것. 단 prominent도 여전히 탭 — 탭의 의미(장소 이동)는 그대로이고 겉모습만 강조됩니다.
Tip
액션 버튼(작성·업로드·스캔·새로 만들기)을 여기 두면 안 됩니다. FAB(플로팅 액션 버튼)의 대용이 아님 — “탭하면 어딘가로 이동하는가?”에 예라고 답할 수 없으면 그건 탭이 아니라 액션이고, 액션의 자리는 툴바입니다.
적절한 예
① 커머스의 장바구니 탭 강조 — 자주 가는 장소 ② 여행 앱의 내 여행 탭 — 핵심 목적지 하나를 부각
잘못된 예
① 작성·업로드 버튼을 prominent 탭으로 위장 — 액션은 탭이 아님 ② 탭하면 이동 없이 시트만 띄우는 가짜 탭 — “어디로 가는가”에 답 못 함
.safeAreaBar(edge:) — 커스텀 뷰를 “바”로 승격시키는 iOS 26 API. 시스템 바처럼 콘텐츠를 자동으로 인셋시키고 스크롤 가장자리 효과에 참여합니다. overlay(가림)와 safeAreaInset(인셋만)의 상위 호환.
5.1.1
Top
.safeAreaBar(edge: .top) — 커스텀 뷰를 상단 safe area에 배치. 스크롤 콘텐츠는 자동으로 그 아래부터 시작.
어느 상황에서 사용하는가
시스템 내비바로는 안 되는 상단 상시 UI — 필터 칩 줄, 동기화 상태 배너, 커스텀 헤더처럼 콘텐츠 위에 늘 떠 있어야 하는 것.
이렇게 해야하는 이유
overlay는 콘텐츠를 가리고, safeAreaInset은 밀어내기만 하고 가장자리 효과가 없음 — safeAreaBar는 인셋 + 스크롤 가장자리 효과까지, 시스템 바의 인프라 전체를 커스텀 뷰에 개방한 것입니다. 커스텀 UI도 시스템과 같은 문법으로 행동해야 화면이 하나의 시스템으로 읽히기 때문.
Tip
첫 번째 콘텐츠가 바에 가려지지 않는지(자동 인셋), 스크롤 시 콘텐츠가 바 밑으로 지나갈 때의 가독성을 확인하세요.
적절한 예
① 필터 칩 줄을 상단 바로 — 콘텐츠가 자동으로 그 아래부터 ② 동기화 상태·오프라인 배너
잘못된 예
① safeAreaBar 대신 ZStack으로 얹어 콘텐츠 첫 줄이 가려짐 ② 상단 바가 과하게 높아 콘텐츠 영역 잠식
Bottom, Hard Scroll Edge Effect, with Toolbar Items
하단 커스텀 바 + hard 가장자리 효과 + 시스템 툴바 아이템이 공존하는 구성.
어느 상황에서 사용하는가
커스텀 바와 시스템 툴바 아이템이 하단에 함께 있고, 콘텐츠와의 경계가 또렷해야 하는 구조적 화면(표·입력 폼 위).
이렇게 해야하는 이유
핵심은 커스텀 바도 시스템 바와 같은 가장자리 효과 문법을 따른다는 것 — scrollEdgeEffectStyle이 safeAreaBar에도 적용되므로, 시스템 툴바와 커스텀 바가 하나의 하단 시스템으로 읽힙니다. hard를 고르는 기준은 1.3.2와 동일: 분위기보다 명료함.
Tip
툴바 아이템 + 커스텀 바로 하단이 두 층이 되면 무겁습니다 — 한 층으로 합칠 수 있는지 먼저 검토하세요.
적절한 예
① 입력창(hard로 경계 명확) + 시스템 툴바 버튼 공존 ② 결제 바 + 도움말 버튼 — 커스텀과 시스템의 역할 분담
잘못된 예
① 경계가 중요한 입력창 위에 soft 유지 — 시작점 모호 ② 커스텀 바와 시스템 아이템의 겹침(z-순서)을 방치
material은 색이 아니라 배경과의 관계입니다 — 뒤를 블러·채도 조정으로 비추는 반투명 레이어라서, 같은 material도 배경에 따라 표정이 달라집니다. 이 데모가 “여러 배경 위”를 보여주는 이유.
6.1.1
Materials in Different Backgrounds
.ultraThinMaterial ~ .thickMaterial — 뒤 배경을 비추는 두께가 다른 반투명 레이어. 밝은 배경, 사진, 다크모드 어디서든 자동 적응.
어느 상황에서 사용하는가
콘텐츠 위에 떠 있는 레이어(바·카드·패널)의 배경이 필요한 모든 곳. 두께 선택 기준은 하나 — 뒤로 지나갈 콘텐츠가 복잡할수록 두껍게(1.3.3의 가독성 논리와 동일).
이렇게 해야하는 이유
고정 색 배경은 배경과 단절된 “스티커”처럼 보입니다 — material은 뒤를 비춤으로써 “이 레이어는 콘텐츠 위에 떠 있다”는 깊이 관계를 형태로 표현합니다. 라이트/다크·배경 밝기에 맞춰 시스템이 자동 보정하므로, 개발자가 배경별 색을 계산하지 않아도 대비가 유지됨 — material이 “색”이 아니라 “재질”인 이유.
Tip
material에 색을 얹어 커스텀하지 말고 두께로만 고르세요. 그 위의 텍스트·아이콘은 다음 항목(vibrancy)과 세트로 써야 완성됩니다.
적절한 예
① 사진 위 컨트롤 배경에 .thinMaterial — 배경이 비쳐도 판 유지 ② 라이트/다크 적응을 시스템에 위임하고 색을 하드코딩하지 않음
잘못된 예
① 스크린샷 기준으로 rgba 반투명색을 하드코딩 — 다른 배경·다크모드에서 깨짐 ② material 위에 또 material을 중첩 — 뿌옇게 겹쳐 탁해짐
material이 “유리”라면 vibrancy는 유리에 새기는 법 — material 위의 콘텐츠가 배경색을 끌어와 렌더링되어, 분리되지 않고 또렷해집니다.
6.2.1
Vibrancy
material 위의 텍스트·심볼이 배경색을 혼합해 렌더링되는 효과 — .foregroundStyle(.secondary) 같은 시맨틱 스타일이 material 위에서 자동으로 vibrant해짐.
어느 상황에서 사용하는가
material 배경 위에 올라가는 모든 텍스트와 아이콘 — 특히 보조 정보(secondary·tertiary). 유리 바 안의 라벨, 카드 위의 캡션.
이렇게 해야하는 이유
material 위에 불투명 고정 회색을 얹으면 배경과 단절되어 탁해집니다 — vibrancy는 뒤 색을 섞어 “유리에 새겨진” 통합감과 가독 대비를 동시에 확보합니다. primary/secondary/tertiary 계층이 vibrancy 강도와 연결되어, 색이 아니라 위계로 정보를 구분하는 시스템 철학의 텍스트 버전.
Tip
material 위에서는 커스텀 고정색 대신 시맨틱 스타일(.primary/.secondary)을 쓰세요 — vibrancy가 자동 적용됩니다. 고정 hex를 쓰는 순간 이 효과를 전부 잃습니다.
적절한 예
① material 위 보조 텍스트에 .secondary — 자동으로 배경과 조화 ② SF Symbol에 시맨틱 스타일 적용 — 어떤 배경에서도 판독 유지
잘못된 예
① material 위에 고정 회색 hex — 배경과 섞이지 않아 탁하고 죽은 색 ② 본문 긴 문단까지 vibrant 처리 — 읽기 피로 증가
메뉴는 “요청할 때만 나타나는 UI”의 대표 장치입니다 — 평소엔 버튼 하나의 존재감, 탭하면 전체 선택지. minimization 원칙이 액션 목록에 적용된 형태입니다.
7.1.1
Menu Configurations
Menu — 버튼을 탭하면 열리는 액션 목록. 아이콘·섹션(Divider)·서브메뉴·role(.destructive)·Toggle/Picker 포함까지 조합 가능.
어느 상황에서 사용하는가
한 컨트롤에 여러 관련 액션을 접을 때 — 더보기(⋯) 버튼, 정렬·필터 옵션, 항목별 액션. 화면에 버튼을 늘어놓기엔 많고, 시트를 열기엔 가벼운 중간 지대. 툴바 overflow(1.1.7)가 자동으로 만드는 것도 결국 이 메뉴.
이렇게 해야하는 이유
배치 규약이 시스템 전역에서 동일해 학습이 필요 없는 것이 메뉴의 가치 — 자주 쓰는 항목은 버튼 가까운 쪽(열리는 방향에 따라 위/아래), 관련 항목은 섹션으로 묶고, 파괴적 액션은 Divider로 분리해 빨간색. 아이콘을 곁들이는 이유는 텍스트보다 스캔이 빠르기 때문 — 메뉴는 정독이 아니라 훑는 UI입니다.
Tip
서브메뉴는 1단까지만 — 2단부터는 발견 불가능해집니다. 항목이 8개를 넘으면 메뉴가 아니라 구조 문제: 섹션을 나누거나 일부를 시트·화면으로 승격하세요.
적절한 예
① ⋯ 메뉴 — 관련 액션끼리 섹션을 나누고, 삭제는 맨 아래 분리 + 빨강 ② 정렬 기준을 Picker로 넣어 현재 값에 체크 표시
잘못된 예
① 삭제를 일반 항목들 사이에 섞어 배치 — 오탭 사고 ② 메뉴 안에 서브메뉴 3단 중첩 — 사용자가 길을 잃음
⋯ 버튼에서 열리는 액션 목록 — 섹션 구분, 서브메뉴(›), 파괴적 액션은 분리 + 빨강
8
디자인 원칙 & 기준 — 잘된 예 · 나쁜 예로 검증하기
8.1
원칙별 기준과 사례
1~7장 68개 항목의 적절한 예·잘못된 예를 관통하는 원칙은 결국 일곱 가지입니다. 각 원칙마다 판단 기준을 한 문장으로 정의하고, 그 기준을 통과한 적절한 예와 기준을 위반한 잘못된 예를 대조합니다. 괄호 번호는 본문의 해당 항목.
8.1.1
Content-First · Minimization — UI는 콘텐츠를 위해 물러난다
크롬(제목·바·버튼)은 콘텐츠를 돕는 수단이지 주인공이 아님. 안 쓰는 순간에는 접히거나 사라져야 함.
기준
"이 UI 요소가 지금 이 순간 사용자의 과업에 기여하는가?" 기여하지 않는 순간이 있다면 그 순간에는 축소·접힘·숨김이 기본이어야 한다.
적절한 예
① Large 타이틀의 스크롤 축소 (1.2.1) — 진입 순간엔 방향감이 과업에 기여하므로 크게, 읽기 시작하면 기여가 끝나므로 inline으로 접혀 공간을 콘텐츠에 반납. "지금 기여하는가" 기준을 순간마다 다시 묻는 동작 ② Overflow 자동 접힘 (1.1.7)과 Menu (7.1.1) — 드물게 쓰는 액션은 지금의 과업에 기여할 확률이 낮으므로 접어둠. 기능의 완전성은 유지하면서 화면 점유는 기여도에 비례 ③ searchToolbarBehavior(.minimize) (1.4.6) — 검색이 조연인 화면에서 돋보기 버튼 크기로 접어 한 탭 거리는 유지하되 평소 점유는 최소.
잘못된 예
① 액션이 하나뿐인 화면에 bottom bar 신설 (1.1.1 위반) — 하단 바 전체가 상시 세로 공간을 차지하지만 기여하는 건 버튼 하나. "기여하지 않는 순간에도 화면을 점유"하는 기준 위반 ② 저빈도 검색 화면에 drawer .always (1.4.4 위반) — 대부분의 순간 과업에 기여하지 않는 검색바가 세로 한 줄을 상시 소모 ③ leading·principal·trailing·bottom 전부 채우기 (1.1.9 위반) — "자리가 있으니 채운다"는 기준의 정반대.
"자주·반복해서 누르는가?" 그렇다면 하단(엄지의 홈 그라운드). 가끔 쓰는 확정성 액션(완료·저장)이라면 상단. 빈도와 높이가 반비례해야 한다.
적절한 예
① 메일의 "새 메일 작성"을 bottom bar에 (1.1.4) — 메일함에서 가장 자주 반복되는 액션이므로 기준상 하단이 정답. 실제 iOS 메일 앱의 배치 ② iOS 26의 검색 하단 이동 (1.4.1) — 고빈도 기능인 검색이 기존엔 가장 닿기 어려운 상단에 있었음. 빈도-높이 반비례 기준에 맞게 시스템 차원에서 교정한 사례. iPad는 양손 파지 기준으로 상단 trailing — 같은 기준을 기기 인체공학에 맞게 적용.
잘못된 예
① 1회성 "완료" 버튼을 bottom bar에 — 완료는 화면당 한 번 누르는 저빈도 확정 액션이므로 기준상 상단 trailing 자리. 하단에 두면 고빈도 자리를 낭비하고, 탭바(이동)와 인접해 역할 혼동까지 유발 (1.1.4 Tip 위반) ② 가장 자주 쓰는 액션을 상단 구석에 두고 하단은 비움 — 카메라 앱의 셔터를 상단 trailing에 두는 격. 빈도 최상위 컨트롤이 도달성 최하위 위치에 있어 한 손 사용 시 매번 그립을 바꾸게 됨.
leading=이동 · principal=정체성 · trailing=확정 · bottom=빈도. 그리고 같은 유리 캡슐 = 한 세트. 위치와 묶음이 곧 언어.
기준
"이 컨트롤의 역할이 그 자리의 문법과 일치하는가? 한 캡슐에 묶인 것들이 정말 한 세트인가?" 문법이 지켜져야 사용자가 처음 보는 앱에서도 버튼 위치를 예측할 수 있다.
적절한 예
① "지도/목록" 세그먼트를 principal에 (1.1.5) — 이 컨트롤 값에 따라 화면 전체 내용이 바뀌므로 "화면의 정체성"이라는 principal의 문법과 정확히 일치 ② 도구 클러스터(leading)와 완료 버튼(trailing)의 분리 (1.1.2) — 보기 전환·정렬·필터는 한 캡슐(한 세트=도구), 완료는 별도 단일 캡슐(결정). 캡슐 사이의 빈 공간이 "서로 다른 일"이라는 정보를 전달 (1.1.3).
잘못된 예
① 단순 공유 버튼을 principal에 (1.1.5 위반) — 공유는 화면의 정체성이 아니라 부가 액션. 위계상 가장 강한 중앙 자리에 두면 제목까지 사라지면서 "이 화면이 무엇인지"를 말할 장치가 없어짐 ② 관계없는 기능들을 한 캡슐에 몰아넣기 (1.1.3 위반) — 정렬·공유·설정·삭제를 한 유리 캡슐에 붙이면 사용자는 "한 세트"로 읽음. 묶음이 거짓 정보가 되어 인지 부담 증가 ③ Custom Large Title 자리에 버튼·입력 필드 (1.2.6 위반) — 제목 자리는 "화면 정체성" 문법. 인터랙티브 컨트롤을 넣으면 자리의 문법이 깨짐.
Liquid Glass의 투명함은 미학이고, 컨트롤이 읽히는 건 기능. 충돌 시 우선순위는 항상 가독성·접근성.
기준
"최악의 배경(사진·고대비 그래픽) 위에서, 그리고 접근성 설정(큰 글씨·투명도 감소)에서도 읽히고 눌리는가?" 가장 좋은 조건이 아니라 가장 나쁜 조건이 검증 기준이다.
적절한 예
① 사진·영상 위 Hard + Thick Material (1.3.3) — 복잡한 배경에서 반투명 유리의 대비가 부족해지면 투명도(미학)를 포기하고 불투명 배경으로 가독성을 확보. "예쁜데 안 읽힌다"에 대한 공식 탈출구 ② Overflow의 최소 터치 타깃 보장 (1.1.7) — 아이템이 많다고 버튼을 무한정 축소하면 손가락 크기 이하로 작아지므로, 시스템이 자동으로 접어 "눌리는가" 기준을 지킴.
잘못된 예
① 사진 피드 화면에서 scroll edge effect를 hidden으로 (1.3.4 위반) — 밝은 화면 한 조건에서만 확인하고 끄면, 흰 사진이 바 뒤를 지나는 순간 컨트롤이 사라짐. "최악의 배경에서 검증" 기준을 건너뛴 경우 ② 접근성 큰 글씨를 확인하지 않은 lineLimit(1) (2.1.1 위반) — 기본 글자 크기에선 멀쩡해 보여도 Dynamic Type 최대 설정에선 핵심 정보가 첫 어절만 남고 잘림 ③ 유리 툴바 위 커스텀 뷰에 불투명 배경색 (1.1.8 위반) — 시스템이 배경 대비를 관리하는 유리 위에 임의 배경을 얹으면 재질 계층이 깨지고 다크모드·투명도 감소 설정에서 대비가 예측 불가능해짐.
공간은 유한한데 텍스트 길이는 예측 불가. 잘림·축소·예약 중 무엇을 쓸지는 그 텍스트가 "문장"인지 "값"인지가 정한다.
기준
"잘려도 뜻이 통하는가?" 통하면 자르고(문장 → truncation), 잘리면 뜻이 죽으면 줄이고(값 → scale), 레이아웃 균일성이 목적이면 공간을 예약한다(reserve). 그리고 잘림·축소는 안전장치이지 레이아웃 설계 수단이 아니다.
적절한 예
① 메일 목록의 본문 2줄 미리보기 (2.1.1) — 본문은 문장이라 잘려도 앞부분으로 뜻이 통하고, 전문은 상세 화면이 담당. 목록의 목적(훑기)에 맞게 높이를 계약으로 고정한 정석 ② 타이머·금액에 minimumScaleFactor (2.1.3) — "12:34:56"은 잘리는 순간 정보가 파괴되는 "값"이므로 자르지 않고 줄임 ③ 파일 경로에 .middle truncation (2.1.2) — 경로는 앞이 공통 접두사라 앞만 보이면 구분 불가. 정보 가치가 양 끝에 있으니 가운데를 접는 것이 기준에 맞는 선택.
잘못된 예
① 금액·타이머를 기본 .tail로 자르기 (2.1.3 위반) — "₩1,234,0…"은 뜻이 통하는 게 아니라 틀린 값을 보여주는 것. "잘려도 뜻이 통하는가"에 노(No)인 텍스트에 문장용 해법을 적용한 오류 ② scaleFactor 0.3까지 내려 우겨넣기 (2.1.3 위반) — 절반 이하로 줄여야 들어간다면 축소가 아니라 설계 문제. 폭을 늘리거나 표기를 줄이는(1,234,000 → 1.2M) 게 정답 ③ 세로 목록 전체에 reservesSpace (2.1.4 위반) — 공간 예약의 목적은 그리드·가로 카드의 균일성. 균일성이 필요 없는 세로 목록에선 짧은 셀마다 빈 공간만 상시 소모.
단위·이름·날짜의 표기 규칙은 문화권마다 다름. 앱은 값만 소유하고 표기는 시스템(FormatStyle)에 위임해야 함.
기준
"데이터를 문자열로 직접 조립하고 있는가? 그 표기 규칙이 문화권마다 다른가?" 둘 다 예스라면 국제화 버그가 이미 심어진 것 — FormatStyle로 옮겨야 한다.
적절한 예
① Measurement + .measurement 포맷 (2.2.1) — 앱은 "5km"라는 문자열이 아니라 거리 값만 소유. 같은 데이터가 한국에선 "5킬로미터", 미국에선 "3.1 miles"로 자동 렌더링 — 값과 표기의 분리 기준 그대로 ② PersonNameComponents + .abbreviated로 아바타 이니셜 (2.2.2) — 이니셜 추출 규칙조차 문화권마다 다르므로 직접 substring 하지 않고 시스템에 위임.
잘못된 예
① "\(distance) km" 문자열 조립 (2.2.1 위반) — 표기 규칙(단위계)이 문화권마다 다른데 문자열로 굳혔으니 기준의 두 조건을 모두 위반. 미국 사용자에게 킬로미터를 강요하는 국제화 버그 ② "이름 성" 순서 하드코딩 (2.2.2 위반) — "\(firstName) \(lastName)"은 홍길동을 "길동 홍"으로 표기. 이름 순서는 데이터가 아니라 문화권 규칙인데 앱이 소유해버린 경우.
액션의 대상이 화면에 보인다면, 별도 버튼을 만들어 관계를 유추시키지 말고 대상을 직접 조작하게 한다.
기준
"이 액션의 대상이 화면에 보이는가? 사용자가 버튼과 대상의 관계를 유추해야 하는가?" 대상이 보이는데 유추가 필요하다면, 액션을 대상 위로 옮겨야 한다.
적절한 예
① toolbarTitleMenu (1.2.5) — 현재 폴더 이름(=대상)이 제목으로 보이므로, 이름변경·전환은 제목을 탭해서. 대상과 액션이 한 몸이라 관계 설명이 필요 없고, 툴바 버튼 하나도 절약 ② 인증 코드·주소에 textSelection(.enabled) (2.1.5) — "복사"라는 액션의 대상이 그 텍스트 자체이므로, 별도 복사 버튼 대신 텍스트를 길게 눌러 직접 가져가게 함.
잘못된 예
① 제목 옆에 별도 "폴더 변경" 버튼 (1.2.5 위반) — 대상(폴더 제목)이 화면에 보이는데 액션은 떨어진 버튼에 있어, 사용자가 "이 버튼이 저 제목에 대한 것"임을 유추해야 함 ② title menu에 설정·로그아웃 같은 화면 전체 액션 (1.2.5 위반) — 제목 메뉴는 "제목이 가리키는 대상"에 대한 액션 자리. 무관한 액션을 넣으면 대상-액션 결합이라는 문법 자체가 거짓이 되어 이후의 모든 title menu를 못 믿게 만듦.