# 가이드라인 4.2 Minimum Functionality 앱 리젝 해결법

> 가이드라인 4.2는 웹사이트 이상의 가치가 없는 앱을 리젝해요. 핵심 사용 흐름에 네이티브 기능을 넣고, 리뷰어에게 그 위치를 알려 주세요.

원본 페이지: [가이드라인 4.2 Minimum Functionality 앱 리젝 해결법](https://devoria.fr/ko/blog/guideline-4-2-minimum-functionality-app-rejected)
작성자: [Mehdi Azizi](https://devoria.fr/ko/mehdi-azizi)
게시일: 2026-10-19
최종 내용 수정: 2026-10-19


가이드라인 4.2 "Minimum Functionality"는 웹사이트와 다를 게 없거나, 계속 쓸 이유가 없을 만큼 기능이 적은 앱을 리젝해요. **해결책은 네이티브 기능을 잔뜩 쌓는 게 아니에요. 핵심 사용 흐름 한가운데에 하나를 넣고, 리뷰어에게 어디서 찾을 수 있는지 알려 주는 거예요.** 수정하려면 거의 항상 새 빌드가 필요해요.

저는 직접 만든 iOS 앱을 출시하고 있어요. Solys, TradaZen, Nolera가 App Store에 올라가 있죠. 이 가이드는 2026년 10월 15일에 읽은 Apple 공식 문서와, 개발자들이 Apple 포럼에 공개한 4.2 리젝 사례를 바탕으로 해요. 아래에 나오는 리젝된 앱들은 예시예요. 모든 리젝 사유를 한눈에 보고 싶다면 [Apple이 앱을 리젝하는 이유](https://devoria.fr/ko/blog/app-store-rejection-reasons-real-cases)를 먼저 읽어 보세요.

## 가이드라인 4.2는 무슨 내용인가요?

4.2는 [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#4.2)의 4번 섹션 "Design"에 있어요. 첫 문장이 기준을 정해요. "Your app should include features, content, and UI that elevate it beyond a repackaged website." 즉, 앱은 웹사이트를 상자에 다시 담은 수준을 넘어서는 기능, 콘텐츠, 인터페이스를 갖춰야 해요.

문서는 두 가지를 덧붙여요. 딱히 유용하지도, 독특하지도, "앱다운(app-like)" 느낌도 없는 앱은 App Store에 있을 자리가 없어요. 그리고 오래가는 재미도 충분한 쓸모도 없는 앱은 리젝될 수 있어요. **그러니까 4.2는 두 가지를 봐요. 웹과의 차이, 그리고 가치의 양이에요.**

## 메시지에 인용될 수 있는 하위 규정

| 하위 규정 | Apple이 요구하는 것                   | 흔한 리젝 사례                |
| --------- | ------------------------------------- | ----------------------------- |
| 4.2       | 웹사이트 이상의 것                    | WebView에 사이트를 띄운 앱    |
| 4.2.1     | 제대로 된 증강현실 경험               | AR 화면에 3D 모델 하나만 놓음 |
| 4.2.2     | 마케팅이나 링크 모음에 그치지 않을 것 | 홍보용 앱, 애그리게이터, 링크 |
| 4.2.3     | 단독 실행 가능, 명확한 다운로드 안내  | 다른 앱이 필요한 앱           |
| 4.2.6     | 상용 템플릿으로 만든 앱 금지          | 대행 업체가 제출한 템플릿 앱  |

세 가지를 짚고 갈게요. 4.2.2는 카탈로그를 예외로 둬요. "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." 그래서 상품 카탈로그는 통과할 수 있어요. 광고 전단 같은 앱은 안 돼요.

4.2.3에는 두 항목이 있어요. (i)은 다른 앱을 설치하지 않아도 앱이 혼자 작동해야 한다는 거예요. (ii)는 첫 실행 때 리소스를 다운로드해야 한다면, 다운로드 크기를 알리고 먼저 동의를 받으라는 거예요.

상용 템플릿과 앱 생성 서비스를 다루는 4.2.6은 [가이드라인 4.3 가이드](https://devoria.fr/ko/blog/guideline-4-3-design-spam-rejection)에서 자세히 설명해요. 스팸 방지 규정과 함께 묶이는 내용이라서요.

## 가장 흔한 4.2 메시지 두 가지

Apple 메시지는 "Guideline 4.2 - Design - Minimum Functionality"라는 제목으로 시작해요. 그 뒤 내용을 보면 리뷰어가 두 문제 중 어떤 걸 봤는지 알 수 있어요. 아래는 개발자들이 Apple 포럼에 공개한 두 가지 문구예요. 몇 년 전 것이라 정확한 문장은 바뀌었을 수 있지만, 두 유형 자체는 그대로예요.

**앱이 웹사이트처럼 보이는 경우.** "Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience." [Apple 포럼에 공개된](https://developer.apple.com/forums/thread/108931) 이 메시지에는 결정적인 문장이 있어요. "Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store."

**앱이 너무 빈약한 경우.** "We found that the usefulness of your app is limited by the minimal amount of content or features it includes." 이 [두 번째 메시지](https://developer.apple.com/forums/thread/115230)는 콘셉트를 다시 검토하라고 하면서, 무엇이 유용하거나 재미있는지 정하는 수치 기준은 없다고 인정해요.

> 웹사이트를 감싼 앱에 알림, 위치, 공유 버튼을 추가하는 것만으로는 부족해요. Apple이 직접 리젝 메시지에 그렇게 썼어요.

## 대표적인 4.2 리젝 사례 네 가지

아래 네 가지는 규정을 설명하려고 만든 예시이고, 실제 앱은 아니에요.

### 웹사이트를 감싼 앱

예시: 피트니스 클럽이 모바일 사이트를 WebView에 띄우고, 위에 네이티브 탭 바만 얹었어요. 시간표, 예약, 계정 화면은 전부 웹 페이지예요. 리뷰어는 Safari에서 보던 것과 똑같은 걸 보게 되죠. Apple은 [App Review 페이지](https://developer.apple.com/distribute/app-review/)에서 이렇게 말해요. iOS 앱 안에 띄운 웹사이트, iOS에 맞추지 않은 웹 콘텐츠, 제한적인 웹 인터랙션으로는 좋은 앱이 되지 않는다고요.

제가 한다면: 핵심 흐름의 화면, 여기서는 시간표와 예약을 네이티브로 다시 만들 거예요. 그다음 웹사이트가 못 하는 걸 추가해요. 수업 전 리마인더, 오프라인에서도 볼 수 있는 시간표, 다음 수업을 보여 주는 위젯 같은 거요.

### 너무 단순한 앱

예시: 하루에 명언 하나만 보여 주고 다른 건 없는 앱이에요. 10초면 다 둘러봐요. 4.2는 "lasting entertainment value or adequate utility", 즉 오래가는 가치나 충분한 쓸모를 말해요. **고치려면 주변에 화면을 늘리지 말고, 핵심 흐름에 깊이를 더하세요.** 이 경우라면 기록, 즐겨찾기, 원하는 시간에 오는 리마인더, 홈 화면 위젯이에요.

### 네이티브 요소 없이 AI로 만든 앱

예시: 텍스트 입력창 하나, 버튼 하나, 그리고 AI 답변을 일반 텍스트로 보여 주는 앱이에요. Apple은 도구를 평가하지 않아요. 리뷰어 화면에 뜨는 결과를 평가하죠. 경험 전체가 웹 페이지 하나로 해결된다면 4.2에 걸릴 가능성이 높아요.

AI가 잘하는 것과 놓치는 것은 [AI로 앱 만들기](https://devoria.fr/ko/blog/ai-ios-app-pitfalls-verification)에서 자세히 다뤄요. 각 생성 도구가 웹 앱을 만드는지 모바일 프로젝트를 만드는지는 [Lovable, Rork, FlutterFlow 비교](https://devoria.fr/ko/blog/lovable-rork-flutterflow-mobile-app-comparison)에서 볼 수 있어요.

### 콘텐츠를 기다리는 빈 껍데기

예시: 매물이 없는 마켓플레이스, 텅 빈 디렉터리, "곧 공개됩니다"만 뜨는 피드예요. 리뷰어가 열었는데 보여 줄 게 없어요. 이 경우는 임시 콘텐츠를 리젝하는 2.1에도 해당해요. [가이드라인 2.1 가이드](https://devoria.fr/ko/blog/guideline-2-1-app-store-rejection-fix)를 참고하세요. 실제 콘텐츠가 생긴 뒤에 제출하거나, 데이터가 채워진 데모 계정을 제공하세요.

## 제가 하는 테스트: "Safari에서는?"

제출 전에 웹사이트로도 같은 핵심 기능을 제공할 수 있는지 스스로 물어봐요. 그렇다면 그 앱은 4.2에 걸릴 위험이 있어요. 아래는 네이티브 기능을 판단하는 제 기준표예요. **기능은 꾸밈이 아니라 핵심 흐름에 도움이 될 때 의미가 있어요.**

| 기능         | 의미가 있는 경우                   | 부족한 경우                 |
| ------------ | ---------------------------------- | --------------------------- |
| 알림         | 사용자가 기다리는 정보를 줄 때     | 블로그 글을 퍼 나를 때      |
| 오프라인     | 핵심 콘텐츠를 계속 쓸 수 있을 때   | 오류 화면만 뜰 때           |
| 위젯         | 그 사람만의 데이터를 보여 줄 때    | 로고만 보여 줄 때           |
| 공유         | 콘텐츠를 앱으로 보낼 수 있을 때    | 링크만 공유할 때            |
| 카메라, 센서 | 핵심 흐름의 일부일 때              | 웹사이트를 열 뿐일 때       |
| 로컬 데이터  | 앱이 계산하고, 정리하고, 기억할 때 | 모든 게 웹 페이지에 있을 때 |

Apple의 권장 사항도 같은 방향이에요. [위젯](https://developer.apple.com/design/human-interface-guidelines/widgets)은 한눈에 읽히는 시의성 있는 콘텐츠를 보여 줘요. [알림](https://developer.apple.com/design/human-interface-guidelines/notifications)은 짧은 말로 유용한 정보를 전하고, 앱 안의 작업으로 끌어들이는 용도로 쓰지 않아요.

## 제 앱이 웹사이트는 못 하는 일

저는 앱마다 브라우저에는 없는 핵심 기능, 또는 다시 돌아오게 만드는 가치를 중심으로 설계해요.

- **Solys**는 알람 앱이에요. 알람은 iOS 26의 알람 서비스인 AlarmKit을 거쳐 울려서, Apple 기본 알람처럼 무음 모드를 뚫어요. 끄려면 미니 게임을 이겨야 하고, 선택한 앱은 기상 후에도 잠긴 상태로 남아요. 어떤 웹 페이지도 무음 모드인 iPhone을 울리지 못해요.
- **TradaZen**은 트레이딩 시뮬레이터예요. 실제 날짜의 실제 차트, 결정, 하나씩 공개되는 캔들, 랭킹이 매겨지는 대결, 올라가는 등급이 있어요. 여기서는 네이티브 기능이 앱을 이끄는 게 아니에요. 4.2가 말하는 오래가는 재미가 그 역할을 해요.
- **Nolera**는 옷장 앱이에요. 옷을 찍으면 앱이 배경을 지우고 정리한 다음, 매일 아침 코디를 추천해요. 카메라는 핵심 흐름의 일부예요. 덤이 아니에요.

**4.2가 요구하는 건 네이티브 기능 목록이 아니에요. 웹사이트를 여는 대신 앱을 설치할 이유예요.**

## 4.2 리젝 단계별로 고치기

1. **유형을 파악하세요.** 웹 브라우징 이야기라면 웹사이트를 감싼 앱이에요. 최소한의 콘텐츠나 기능 이야기라면 빈약한 앱이에요. 4.2.3이라면 다른 앱에 의존하거나 다운로드를 안내하지 않은 거예요.
2. **문구가 아니라 제품을 바꾸세요.** 아무것도 바꾸지 않고 반박만 하는 답변은 설득력이 없어요. 핵심 흐름의 화면을 네이티브로 다시 만들거나, 부족한 깊이를 더하세요.
3. **새 빌드를 준비하세요.** 원인이 앱 안에 있으니 원격 업데이트로는 부족해요. 제출할 때마다 다시 대기열을 거쳐요. [App Store 심사 기간](https://devoria.fr/ko/blog/app-store-review-time-how-long)을 참고하세요.
4. **리뷰어를 안내하는 리뷰 노트를 쓰세요.** Apple은 [완전한 심사를 위한 정보](https://developer.apple.com/help/app-review/before-submitting-for-review/complete-review) 페이지에서 콘셉트, 기능, 대상 사용자를 설명하라고 해요. 업데이트라면 무엇이 바뀌었고 어디서 찾을 수 있는지 적어요.
5. **리뷰어가 뭔가를 놓쳤을 때만 이의를 제기하세요.** 네이티브 기능이 이미 있었는데 리뷰어가 못 본 거라면, App Store Connect에서 짧은 영상과 함께 답하세요. App Review Board에 이의를 제기하는 건 앱이 잘못 이해됐을 때 의미가 있지, 앱이 빈약할 때가 아니에요.

제가 쓸 노트 템플릿이에요. 영어로 되어 있으니 상황에 맞게 고쳐 쓰세요.

```text
Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]
```

제출한 빌드에 실제로 있는 것만 쓰세요. 적어 놓고 찾을 수 없는 기능이 있으면 다시 리젝돼요. 이번엔 2.1 사유로요.

## 제출 전 4.2 체크리스트

- 내 앱이 웹사이트는 못 하는 일을 한 문장으로 말할 수 있다.
- 핵심 흐름의 화면이 웹 페이지가 아니라 네이티브다.
- 모든 네이티브 기능이 핵심 흐름에 도움이 되고, 리뷰어가 2분 안에 마주친다.
- 첫 실행부터 실제 콘텐츠가 있거나, 데이터가 채워진 데모 계정이 있다.
- 다른 앱을 설치하지 않아도 앱이 혼자 작동한다.
- 첫 실행 때 큰 다운로드가 있다면 크기를 알리고 동의를 받는다.
- 리뷰 노트에 콘셉트, 대상 사용자, 각 기능의 위치가 적혀 있다.
- 아이디어가 경계선에 있다면, 코딩 전에 범위를 잘 잡은 [iOS 앱 MVP](https://devoria.fr/ko/expertise/ios-app-mvp)로 검증했다.

## 다음 제출에서 4.2 통과하기

앱이 방금 4.2로 리젝됐다면, [Apple Review Kit](https://devoria.fr/ko/kits/review-apple)이 인용된 규정과 그 요구 사항을 찾도록 도와주고, 리뷰어용 노트 템플릿도 함께 제공해요. 아직 만드는 중이라면 [iOS Kit](https://devoria.fr/ko/kits/ios)의 과정은 첫 코드 한 줄 전에 핵심 기능부터 정해요. 사람의 시선이 필요하다면 [저와 1시간 상담을 예약하세요](https://devoria.fr/ko/coaching). 전체 과정은 [Apple에 리젝된 앱](https://devoria.fr/ko/expertise/app-rejected-by-apple) 페이지에 있어요.

첫 출시를 준비 중이라면 [무료 진단을 받아 보세요](https://devoria.fr/ko/diagnostic). 단계를 순서대로 정리해 주고, 제 Apple 리젝 방지 체크리스트도 보내 드려요. 홈페이지에서는 처음부터 심사를 고려한 [모바일 앱 만들기](https://devoria.fr/ko) 방법을 볼 수 있어요.

Apple이 앱을 승인할 거라고 누구도 장담할 수 없어요. 다만 앱이 App Store에 있어야 할 이유를 만드는 건 제가 도와드릴 수 있어요.

## 자주 묻는 질문

### "Guideline 4.2 - Design - Minimum Functionality"는 무슨 뜻인가요?

최소 기능 부족으로 리젝될 때 붙는 제목이에요. Apple이 보기에 앱이 웹사이트와 너무 비슷하거나, 콘텐츠나 기능이 너무 적다는 뜻이에요. 같은 제목이 하위 규정을 가리킬 수도 있어요. 홍보용 앱이나 링크 모음이면 "Guideline 4.2.2", 다른 앱에 의존하는 앱이면 4.2.3이에요.

### WebView 앱은 무조건 리젝되나요?

아니요. 규정이 겨냥하는 건 기술이 아니라 앱에 담아 놓은 웹사이트예요. 리뷰어는 핵심 경험을 봐요. 핵심 화면이 Safari와 똑같은 일을 하는 웹 페이지라면 위험이 커요. 브라우저로 여는 도움말 페이지 정도는 문제가 아니에요.

### 푸시 알림만 추가하면 4.2를 통과할 수 있나요?

아니요. Apple은 포럼에 공개된 리젝 메시지에서 알림, 위치, 공유만으로는 경험이 충분히 풍부해지지 않는다고 썼어요. 알림은 알람이나 사용자가 직접 설정한 리마인더처럼 핵심 기능에 도움이 될 때 의미가 있어요.

### 가이드라인 4.2와 4.3은 뭐가 다른가요?

4.2는 앱 자체를 봐요. 웹사이트에 비해 충분한 가치를 주는가? 4.3은 다른 앱과 비교해요. 복제품이나 변형판인가, 포화된 카테고리에 하나 더 얹은 앱인가? 한 앱이 둘 다 받을 수도 있지만, 고치는 방법은 달라요.

### 4.2 리젝 후에는 새 빌드가 꼭 필요한가요?

거의 항상 필요해요. 원인이 앱 자체에 있으니까요. 유일한 예외는 이미 있던 기능을 리뷰어가 찾지 못한 경우예요. 이때는 빌드를 바꾸지 말고, App Store Connect에서 구체적인 노트와 짧은 영상으로 답하세요.


## 내 프로젝트

[Apple Review Kit](https://devoria.fr/ko/kits/review-apple): 제가 쓰는 App Store 심사 체크리스트, 수정한 Apple 리젝 사례, 심사자용 메모, 앱을 검토하는 Claude Code skill 두 개. 29 €.

[iOS Kit](https://devoria.fr/ko/kits/ios): Claude Code로 iPhone 앱을 만드세요. 제 앱들의 Starter Code, 작업을 검사하는 skill, Apple Review Kit, App Store Screenshots Kit, ASO Kit 포함. 129,99 €.