# Guideline 4.0 Design 리젝: 앱 인터페이스 거절 해결법

> Guideline 4.0 Design은 쓰기 어려운 인터페이스에 대한 거절로, iPad에서 자주 나와요. iPhone SE와 iPad에서 모든 화면을 확인하고 고친 뒤 답장하세요.

원본 페이지: [Guideline 4.0 Design 리젝: 앱 인터페이스 거절 해결법](https://devoria.fr/ko/blog/guideline-4-0-design-app-store-rejection)
작성자: [Mehdi Azizi](https://devoria.fr/ko/mehdi-azizi)
게시일: 2026-11-04
최종 내용 수정: 2026-11-04


"Guideline 4.0 - Design"은 다른 규칙처럼 번호가 붙은 조항이 아니에요. Apple 규칙 중 Design 섹션의 도입부로, 인터페이스가 기대 수준에 못 미친다고 판단될 때 인용돼요. 공개된 거절 사례들은 서로 비슷해요. iPad에서 화면이 비좁고, 텍스트가 읽기 어렵고, 로그인이 Safari로 넘어가고, Sign in with Apple이 제대로 통합되지 않은 경우예요. **수정은 거의 항상 메시지에 언급된 기기에서, 화면 하나하나를 확인하는 것부터 시작해요.**

저는 Expo로 제 iOS 앱을 직접 출시하고 있어요. Solys, TradaZen, Nolera는 iPhone 전용으로 설정했는데도 리뷰어는 Solys와 Nolera를 iPad에서 테스트했어요. 이 가이드는 Apple의 공식 문서, 다른 개발자들이 공개한 4.0 거절 사례, 그리고 제가 제출 전마다 쓰는 시각 점검표를 바탕으로 해요. 거절 사유 전체가 궁금하다면 [Apple이 앱을 거절하는 이유](https://devoria.fr/ko/blog/app-store-rejection-reasons-real-cases)를 읽어 보세요.

## 가이드라인 4.0 Design은 무엇을 다루나요?

[App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#design)의 4번 섹션은 번호 없는 문단으로 시작해요. "Apple customers place a high value on products that are simple, refined, innovative, and easy to use, and that's what we want to see on the App Store." 디자인은 개발자의 몫이지만, 이어지는 내용이 "minimum standards for approval"을 정한다고 덧붙여요. 승인 후 품질이 떨어지는 앱은 내려질 수 있다는 경고도 있어요.

쉽게 말해 **Apple은 단순하고 다듬어졌고 쓰기 쉬운 앱을 원하고, 4.0은 문제가 특정 하위 규칙에 해당하지 않을 때 쓰여요.** 문서에는 수치 기준이 없어요. 실질적인 기준은 Apple의 디자인 규칙인 [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/layout)예요.

## 가장 흔한 4.0 거절 사례

Apple 포럼에 공개된 메시지에서 찾은 네 가지 사례와 인용된 문구예요.

| 사례                     | Apple의 문구        | 해결책              |
| ------------------------ | ------------------- | ------------------- |
| iPad에서 비좁은 화면     | "crowded"           | 유연한 레이아웃     |
| 읽기 어려운 텍스트       | "hard to read type" | HIG 크기 준수       |
| Safari로 넘어가는 로그인 | "taken to Safari"   | 앱 안에서 로그인    |
| Sign in with Apple       | 이름을 다시 요구    | 이미 받은 이름 사용 |

### iPad에서 비좁거나 잘리는 화면

2025년 9월에 공개된 대표 메시지예요. "Parts of the app's user interface were still crowded, laid out, or displayed in a way that made it difficult to use the app when reviewed on iPad Air (5th generation) running iPadOS 26.0." 이어서 앱이 화면의 일부만 쓰고 있다고 지적했어요([포럼 스레드](https://developer.apple.com/forums/thread/800657)).

원인은 2.4.1 규칙에 있어요. "iPhone apps should run on iPad whenever possible." [Expo 앱 설정 문서](https://docs.expo.dev/versions/latest/config/app/)에 따르면 Expo에서 `ios.supportsTablet` 옵션의 기본값은 `false`예요. 그러면 iPhone 앱이 iPad에서 호환 모드로, iPhone 비율의 창 안에서 실행돼요. **앱을 iPhone 전용으로 설정해도 iPad 테스트를 피할 수는 없어요.** Solys의 데모를 통과할 수 없게 된 것도 iPad Air에서였어요. 이 사례는 [guideline 2.1](https://devoria.fr/ko/blog/guideline-2-1-app-store-rejection-fix) 가이드에 자세히 적어 두었어요.

해결 방법은 두 가지예요. 하나는 iPad를 제대로 지원하는 거예요. 사용 가능한 공간에 맞춰 레이아웃이 바뀌어야 해요. Apple 디자인 규칙은 기기 모델이 아니라 사이즈 클래스에 따라 배치를 정하라고 해요. 다른 하나는 iPhone 전용으로 남는 거예요. 이 경우 모든 화면이 호환 모드 창 안에 제대로 들어가야 해요.

### 읽기 어려운 텍스트

2025년 1월에 공개된 메시지예요. "Your app included hard to read type or typography." Apple은 사용자들이 "simple, refined, and easy to use"한 앱을 기대한다고 다시 강조해요([포럼 스레드](https://developer.apple.com/forums/thread/772671)).

[Apple 타이포그래피 규칙](https://developer.apple.com/design/human-interface-guidelines/typography)은 iOS 기준으로 기본 17포인트, 최소 11포인트를 제시해요. [접근성 규칙](https://developer.apple.com/design/human-interface-guidelines/accessibility)은 17포인트 이하 텍스트에 최소 4.5:1의 명암비를, 터치 영역은 기본 44×44포인트를 요구해요.

작은 화면에서 폰트를 줄인다면 주의하세요. 저도 어디서나 줄바꿈을 똑같이 유지하려고 그렇게 하는데요. **iPhone SE에서 줄어든 가장 작은 텍스트도 최소 11포인트인지 확인하세요.**

### Safari로 넘어가는 로그인

[Apple 포럼](https://developer.apple.com/forums/thread/126333)에 공개된 메시지예요. "We noticed that the user is taken to Safari to sign in or register for an account, which provides a poor user experience." Apple은 앱 안에서 가입과 로그인을 할 수 있게 하라고 요구하고, 앱 내장 Safari 뷰를 권장해요.

Expo에서는 [expo-web-browser](https://docs.expo.dev/versions/latest/sdk/webbrowser/)로 앱을 벗어나지 않고 두 가지를 모두 처리할 수 있어요. `openAuthSessionAsync`는 모달 창에서 인증 세션을 열고, `openBrowserAsync`는 앱 내장 Safari 뷰에 페이지를 띄워요. 반대로 `Linking.openURL`로 로그인을 열면 Safari 앱으로 넘어가요. 어떤 로그인 수단을 제공할지는 별개의 규칙인 4.8에서 다뤄요.

### 제대로 통합되지 않은 Sign in with Apple

2024년 5월에 공개된 메시지예요. "Your app requires users to provide their name after using Sign in with Apple. This information is already provided by the Authentication Services framework."([포럼 스레드](https://developer.apple.com/forums/thread/751115)).

[expo-apple-authentication](https://docs.expo.dev/versions/latest/sdk/apple-authentication/) 문서가 함정을 설명해요. 이름과 이메일은 첫 로그인 때만 제공돼요. **바로 저장하세요.** 그렇지 않으면 다시 물어보고 싶어질 거예요. 라이브러리가 제공하는 버튼도 쓰세요. 색상은 `buttonStyle`로, 모서리는 `cornerRadius`로 정하고, 절대 `style`로 바꾸지 마세요.

## 4.0, 4.2, 4.3: 헷갈리기 쉬운 세 가지 디자인 거절

| 규칙 | 평가 대상   | 해결책             |
| ---- | ----------- | ------------------ |
| 4.0  | 인터페이스  | 화면 수정          |
| 4.2  | 앱의 유용성 | 네이티브 기능 추가 |
| 4.3  | 유사성      | 콘셉트 변경        |

[4.2, Minimum Functionality](https://devoria.fr/ko/blog/guideline-4-2-minimum-functionality-app-rejected)는 앱을 "beyond a repackaged website" 수준으로 끌어올리는 기능, 콘텐츠, 인터페이스를 요구해요. 4.0과의 경계는 미묘해요. 웹사이트를 앱으로 감싸기만 했다면 두 가지 모두 받을 수 있어요. **앱에 알맹이가 부족하다면 화면만 손봐서는 해결되지 않아요.**

4.3은 복제 앱과 포화된 카테고리를 겨냥해요. 두 항목은 [guideline 4.3 Design Spam](https://devoria.fr/ko/blog/guideline-4-3-design-spam-rejection) 가이드에서 자세히 설명했어요. 인터페이스가 아무리 다듬어져도 수많은 앱과 닮았다면 통과하지 못해요.

## 제출 전 시각 점검표

제출할 때마다 제가 추가로 하는 단계예요. 제 앱은 모든 화면을 가장 큰 iPhone 기준으로 디자인한 뒤, 작은 기기에서는 한 가지 비율로만 축소해요. 비율도 줄바꿈도 똑같아요. 그다음 결과를 나란히 비교해요. iPhone SE, 일반 iPhone, 가장 큰 iPhone, 그리고 호환 모드 확인용 iPad예요.

| 점검 항목   | 기기         | 확인할 점                           |
| ----------- | ------------ | ----------------------------------- |
| 첫 실행     | iPhone SE    | 잘리는 부분 없음                    |
| 온보딩 전체 | iPad         | 모든 버튼에 접근 가능               |
| 키보드 열림 | iPhone SE    | 입력란과 버튼이 보임                |
| 큰 텍스트   | 일반 iPhone  | 잘리는 텍스트 없음                  |
| 다크 모드   | 전체         | 모든 곳에서 텍스트가 읽힘           |
| 안전 영역   | 가장 큰 기기 | Dynamic Island 아래에 아무것도 없음 |
| 페이월      | iPhone SE    | 가격과 링크가 보임                  |
| 로그인      | iPad         | 앱 안에서 진행됨                    |

세 가지를 덧붙일게요.

- **큰 텍스트.** Apple 타이포그래피 규칙은 간단한 테스트를 제안해요. Settings > Accessibility > Display & Text Size에서 가장 큰 텍스트 크기를 켜고, 모든 것이 여전히 읽히는지 확인하는 거예요.
- **다크 모드.** [다크 모드에 관한 Apple 규칙](https://developer.apple.com/design/human-interface-guidelines/dark-mode)은 두 가지 모드 모두에서 앱이 읽혀야 한다고 해요. `userInterfaceStyle`을 설정하지 않으면 Expo는 기본으로 `light`를 적용해요. Solys는 휴대폰 설정을 따르고, TradaZen은 다크, Nolera는 라이트로 고정이에요. 세 경우 모두 실제로 표시되는 모드를 테스트해요.
- **안전 영역.** 콘텐츠가 Dynamic Island나 홈 인디케이터 아래로 들어가면 안 돼요. Expo의 [안전 영역](https://docs.expo.dev/develop/user-interface/safe-areas/) 가이드에 방법이 자세히 나와 있어요.

Mac에서는 시뮬레이터를 명령줄로 설정할 수 있어서 점검표를 빠르게 다시 돌릴 수 있어요.

```bash
xcrun simctl ui booted appearance dark
xcrun simctl ui booted content_size accessibility-extra-extra-extra-large
xcrun simctl io booted screenshot ecran-se-sombre.png
```

실제 휴대폰에서는 [TestFlight](https://devoria.fr/ko/blog/testflight-iphone-app-beta-testing) 빌드로 같은 점검을 한 번 더 해요. 방법론: 이 점검표는 제 앱들이 받은 거절을 바탕으로 제가 만든 것이고, Apple이 제공하는 목록이 아니에요. 예상 밖의 거절을 줄여 주지만 승인을 보장하지는 않아요.

## 4.0 거절에는 어떻게 답하나요?

1. 메시지에 언급된 **기기와 버전을 확인**하고, 같은 모델을 시뮬레이터에서 여세요.
2. **문제가 있는 곳을 모두 고치세요.** 대표 메시지는 스크린샷 속 화면만이 아니라 문제의 "address all instances"를 요구해요.
3. **새 빌드를 보내세요.** 리뷰어는 앱에 포함된 코드를 테스트해요.
4. 같은 기기에서 찍은 **스크린샷과 함께 답하세요.** [App Review 메시지에 답장](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/)하면 돼요.
5. **확신이 있을 때만 이의를 제기하세요.** Apple은 [App Review Board에 이의 제기](https://developer.apple.com/distribute/app-review/)를 허용하지만, 거절된 제출 건당 한 번만 가능해요.

제가 쓸 템플릿이에요. 상황에 맞게 고쳐 쓰세요.

```text
Hello,

Thank you for your feedback regarding Guideline 4.0.

We reproduced the issue on [device] running [OS version].

Changes in build [X]:
- [Screen]: [what was crowded or hard to read], now [fix].
- [Screen]: [fix].

We also checked every screen on iPhone SE, a standard
iPhone, the largest iPhone and iPad, with larger text
sizes and Dark Mode.

Attached: screenshots of the updated screens on [device].

Best regards,
```

## 디자인 거절 없이 제출 준비하기

[Review Kit](https://devoria.fr/ko/kits/app-review)에는 iPad에 관한 2.4.1 규칙 등을 다루는 제 제출 전 체크리스트와, 프로젝트를 검토해 주는 Claude Code 스킬이 들어 있어요. 사람의 눈으로 확인받고 싶다면 [저와 1시간 상담을 예약하세요](https://devoria.fr/ko/coaching). 화상으로 여러 크기에서 화면을 함께 열어 봐요. 거절 후 전체 대응 과정은 [Apple에 거절된 앱](https://devoria.fr/ko/expertise/app-rejected-by-apple) 페이지에 있어요.

첫 출시를 준비 중이신가요? [무료 진단을 받아 보세요](https://devoria.fr/ko/diagnostic). 단계를 순서대로 정리해 주고, 제 Apple 거절 방지 체크리스트도 보내 드려요.

## 자주 묻는 질문

### 거절 메시지의 "Guideline 4.0 - Design"은 무슨 뜻인가요?

Apple이 특정 하위 규칙을 지목하지 않고, 인터페이스가 기대 수준에 못 미친다고 판단했다는 뜻이에요. 비좁은 화면, 읽기 어려운 텍스트, 좋지 않은 로그인 흐름 같은 경우예요. 메시지에는 보통 사용한 기기가 언급되고, 스크린샷이 첨부되는 경우가 많아요.

### 앱을 iPhone 전용으로 설정했는데 왜 Apple은 iPad에서 테스트하나요?

2.4.1 규칙이 iPhone 앱은 가능하면 iPad에서도 실행되어야 한다고 정하고 있기 때문이에요. 앱은 iPad에서 호환 모드로, iPhone 비율의 창 안에서 열리고, 그 안에서도 모든 화면을 쓸 수 있어야 해요.

### 4.0 거절 후에는 새 빌드가 필요한가요?

대부분의 경우 그래요. 리뷰어는 첫 실행 때 앱에 포함된 코드를 테스트하기 때문에, 원격으로 배포한 수정 사항은 놓칠 수 있어요. 이 내용은 guideline 2.1 가이드에서 설명했어요.

### 승인받으려면 다크 모드가 필수인가요?

심사 규칙 문서에서 의무로 정하지는 않아요. 다만 디자인 규칙은 사용자들이 앱이 자기 설정을 따르기를 기대한다고 말해요. Expo에서 가능한 것처럼 라이트나 다크로 고정한다면 그 모드를 테스트하세요. 휴대폰 설정을 따른다면 두 모드를 모두 테스트하세요.

### 4.0 거절에 이의를 제기할 수 있나요?

네, 앱이 규칙을 지킨다고 생각한다면 App Review Board에 제기할 수 있어요. Apple은 구체적인 이유를 요구하고, 거절된 제출 건당 한 번만 허용하며, 정보 요청이 있다면 먼저 답하라고 해요.


## 내 프로젝트

[Review Kit](https://devoria.fr/ko/kits/app-review): 제 App Store 심사 체크리스트, 수정해서 통과한 Apple 리젝 사례, Google Play 체크리스트, Claude Code 스킬 3개를 담았어요. ₩73,000.

[iOS & Android Kit](https://devoria.fr/ko/kits/ios): Claude Code로 iPhone·Android 앱을 만들어 보세요. 제 앱들의 시작 코드, 스토어 출시까지의 과정, 모든 키트를 담았어요. ₩148,000.

[진단: 내 아이폰 앱까지 남은 거리](https://devoria.fr/ko/diagnostic): 7개 질문, 60초. 아이폰 앱 출시를 진짜 가로막는 게 뭔지, 4단계 로드맵, 나에게 맞는 키트까지 알려드려요.