지금까지는 통합 앱 구조, 화면 분리, 데이터 모델, 오류 처리처럼 비교적 범용적인 설계 기준을 정리해왔습니다. 이번 글에서는 그 기준을 조금 더 구체적인 예시로 가져와보려고 합니다.
예시로 볼 주제는 대형폐기물 정보 앱입니다. 대형폐기물 앱은 품목 검색, 수수료 안내, 지역별 신고 방법처럼 화면과 데이터의 역할이 섞이기 쉬운 구조를 가지고 있습니다. 그래서 공통 화면 설계와 데이터 분리 기준을 설명하기에 꽤 좋은 사례가 될 수 있을것 같아서 적어보려 합니다.
대형폐기물 정보 앱을 만들 때는 품목을 찾는 화면과 신고 방법을 안내하는 화면을 같은 화면에 몰아넣기 쉽습니다. 검색 결과 아래에 수수료, 배출 방법, 신고 버튼까지 모두 보여주면 한 화면에서 끝나는 구조처럼 느껴질 수 있습니다.
막상 화면 흐름을 정리해보면 품목 검색과 신고 안내는 역할이 조금 다릅니다. 품목 검색 화면은 사용자가 버리려는 물건을 빠르게 찾는 데 집중해야 하고, 신고 안내 화면은 지역별 신고 절차와 다음 행동을 이해하도록 돕는 데 집중해야 합니다.
이 둘을 분리하지 않으면 화면이 복잡해지고, 지역별 데이터 차이가 커질수록 유지보수도 어려워질 수 있습니다. 특히 수수료, 배출 장소, 신고 방법처럼 지역마다 달라질 수 있는 정보는 검색 화면에 모두 넣기보다 별도 안내 흐름으로 나누는 편이 좋습니다.
이 글에서는 Android 기반 대형폐기물 정보 앱을 기준으로 품목 검색, 품목 상세, 신고 안내 화면을 나누는 기준을 정리해보겠습니다. 실제 행정 API 주소나 지역 코드, 내부 관리자 URL은 예시에서 제외하고, 화면 구조와 데이터 분리 기준 위주로 살펴보겠습니다.
품목 검색 화면의 역할
품목 검색 화면의 목적은 사용자가 원하는 품목을 빠르게 찾도록 돕는 것입니다. 검색 화면에서는 신고 절차 전체를 설명하기보다, 검색어 입력과 결과 확인 흐름을 단순하게 유지하는 편이 좋습니다.
- 사용자가 입력한 검색어를 기준으로 품목 후보를 보여준다.
- 비슷한 품목명이 있을 때는 여러 후보를 비교할 수 있게 한다.
- 검색 결과가 없을 때는 다른 검색어를 시도하도록 안내한다.
- 네트워크 오류와 검색 결과 없음 상태를 구분한다.
예를 들어 의자, 책상, 매트리스처럼 사용자가 자주 검색할 만한 품목은 검색 결과에서 바로 찾을 수 있어야 합니다. 이때 수수료와 신고 방법을 모두 길게 보여주면 검색 결과 목록이 금방 무거워집니다.
목록에서는 품목명, 간단한 분류, 지역별 상세 확인 여부 정도만 보여주고 상세 화면으로 넘기는 구조가 더 안정적입니다. 검색 화면은 가볍게 유지하고, 자세한 안내는 상세나 신고 안내 화면에서 다루는 편이 사용자 흐름도 더 자연스럽습니다.
신고 안내 화면의 역할
신고 안내 화면은 검색 화면과 목적이 다릅니다. 여기서는 사용자가 품목을 찾은 뒤 실제로 무엇을 해야 하는지 이해하는 것이 중요합니다. 특히 대형폐기물은 지역마다 신고 사이트, 수수료 기준, 배출 방식이 달라질 수 있습니다.
| 화면 | 주요 목적 | 포함하면 좋은 정보 | 주의할 점 |
|---|---|---|---|
| 품목 검색 | 품목 후보 찾기 | 검색어, 품목명, 분류, 간단 안내 | 신고 절차를 너무 길게 넣지 않는다. |
| 품목 상세 | 선택한 품목 정보 확인 | 품목명, 예상 수수료 범위, 지역별 확인 필요 문구 | 수수료를 확정 금액처럼 단정하지 않는다. |
| 신고 안내 | 다음 행동 안내 | 신고 방법, 배출 전 확인사항, 지자체 안내 확인 문구 | 실제 신고 절차는 최신 지자체 안내를 확인하도록 안내한다. |
| 지역 선택 | 지역별 차이 반영 | 시군구 선택, 지원 여부, 안내 메시지 | 정확하지 않은 지역 코드를 노출하지 않는다. |
신고 안내 화면에서는 사용자가 바로 신고할 수 있는지, 별도 사이트로 이동해야 하는지, 앱에서는 정보만 제공하는지 구분해야 합니다. 이 기준이 흐려지면 사용자는 앱에서 신고가 완료된 것으로 오해할 수 있습니다.
화면을 나누는 가장 단순한 기준
화면 분리 기준은 복잡하게 잡기보다 사용자의 행동 순서에 맞추는 것이 좋습니다. 사용자는 보통 품목을 찾고, 수수료나 조건을 확인하고, 신고 방법을 확인한 뒤 실제 신고 절차로 이동합니다.
- 검색 화면에서는 품목을 찾는다.
- 상세 화면에서는 선택한 품목의 기본 정보를 확인한다.
- 신고 안내 화면에서는 지역별 절차와 주의사항을 확인한다.
- 외부 신고 페이지가 필요하면 앱 밖으로 이동하기 전 안내를 제공한다.
이렇게 나누면 각 화면의 책임이 분명해집니다. 검색 화면에서 문제가 생기면 검색어 처리와 결과 표시를 보면 되고, 신고 안내가 바뀌면 안내 문구와 지역별 설정을 중심으로 확인하면 됩니다.
운영 관점에서는 화면 책임이 분리되어 있을수록 수정 범위도 더 명확해집니다. 품목 검색 품질을 개선하는 작업과 신고 안내 문구를 수정하는 작업이 서로 과하게 얽히지 않기 때문입니다.
데이터 구조도 화면 기준에 맞춰 나누기
화면을 나눴다면 데이터도 함께 나눠야 합니다. 품목 데이터와 신고 안내 데이터를 한 모델에 모두 넣으면 당장은 편할 수 있습니다. 다만 지역이 늘어나거나 안내 문구가 바뀔 때 수정 범위가 커지기 쉽습니다.
| 데이터 종류 | 예시 필드 | 사용 화면 | 관리 기준 |
|---|---|---|---|
| 품목 기본 정보 | 품목명, 분류, 검색 키워드 | 검색, 상세 | 검색 품질에 영향을 주므로 변경 이력을 남긴다. |
| 수수료 정보 | 금액, 단위, 지역, 기준일 | 상세 | 지역별 차이가 있으므로 확정 표현을 피한다. |
| 신고 안내 | 신고 방법, 배출 전 확인사항, 외부 안내 여부 | 신고 안내 | 최신 지자체 안내 확인 문구를 함께 둔다. |
| 지역 설정 | 지역명, 지원 여부, 안내 메시지 | 지역 선택, 상세, 신고 안내 | 실제 내부 코드나 API 주소는 공개하지 않는다. |
수수료 정보는 특히 조심해야 합니다. 앱에 표시된 금액이 오래된 정보라면 사용자가 잘못된 금액으로 이해할 수 있습니다. 그래서 금액을 보여줄 때는 기준일, 지역, 최종 확인 필요 문구를 함께 두는 편이 안전합니다.
빈 결과와 오류 상태는 다르게 보여주기
대형폐기물 검색 화면에서 놓치기 쉬운 부분이 빈 결과 처리입니다. 검색 결과가 없다는 것과 데이터를 불러오지 못했다는 것은 전혀 다른 상태입니다. 두 상태를 같은 메시지로 보여주면 사용자는 검색어를 바꿔야 하는지, 다시 시도해야 하는지 알기 어렵습니다.
| 상태 | 사용자에게 보여줄 메시지 방향 | 버튼 예시 |
|---|---|---|
| 검색 결과 없음 | 다른 품목명이나 비슷한 단어로 다시 검색하도록 안내 | 검색어 지우기 |
| 네트워크 오류 | 데이터를 불러오지 못했으므로 잠시 후 다시 시도하도록 안내 | 다시 시도 |
| 지원하지 않는 지역 | 현재 앱에서 제공하지 않는 지역임을 안내 | 지역 다시 선택 |
| 신고 정보 확인 필요 | 최신 신고 절차는 지자체 안내를 확인하도록 안내 | 안내 확인 |
실제로 구현 흐름을 따라가다 보면 빈 결과 문구 하나가 생각보다 중요합니다. 검색 결과가 없을 때 단순히 데이터가 없다고만 보여주면 앱이 제대로 동작하지 않는 것처럼 보일 수 있습니다. 사용자가 다음에 무엇을 하면 되는지 한 문장으로 알려주는 것이 좋습니다.
Android 화면 상태 예시
검색 화면을 만들 때는 화면 상태를 먼저 나눠두면 유지보수가 편해집니다.
sealed interface WasteSearchState {
data object Idle : WasteSearchState
data object Loading : WasteSearchState
data class Success(val items: List<WasteItem>) : WasteSearchState
data class Empty(val keyword: String) : WasteSearchState
data class Error(val message: String) : WasteSearchState
}
data class WasteItem(
val name: String,
val category: String,
val regionNotice: String
)
이 정도로 상태를 나누면 검색 결과 없음, 로딩, 오류, 정상 결과를 UI에서 분리하기 쉽습니다. 특히 Empty와 Error를 구분해두면 사용자 안내 문구를 다르게 만들 수 있습니다.
코드를 나눠보다 보면 상태 구분은 화면 문구와도 바로 연결됩니다. 빈 결과는 다른 검색어를 시도하도록 안내하고, 오류는 다시 시도할 수 있게 도와야 합니다.
신고 안내 화면에서 조심할 표현
대형폐기물 앱은 행정 정보와 연결되기 때문에 문구를 단정적으로 쓰지 않는 것이 좋습니다. 앱이 실제 신고를 처리하지 않는다면 신고 완료, 접수 완료 같은 표현은 피해야 합니다. 사용자가 앱 안내만 보고 신고가 끝났다고 오해할 수 있기 때문입니다.
- 수수료는 지역과 기준일에 따라 달라질 수 있다고 안내한다.
- 앱에서 신고를 처리하지 않는다면 정보 제공 범위를 명확히 적는다.
- 외부 신고 페이지로 이동하기 전에는 이동 사실을 안내한다.
- 최신 신고 절차는 각 지자체 안내를 확인하도록 문구를 둔다.
공공데이터나 행정 정보를 다루는 앱은 정보가 틀렸을 때 사용자 불편으로 바로 이어질 수 있습니다. 그래서 화면을 예쁘게 구성하는 것만큼, 정보의 기준과 한계를 같이 보여주는 일이 중요합니다.
추천 화면 구조
대형폐기물 정보 앱을 단순하게 시작한다면 아래 구조를 먼저 검토해볼 수 있습니다. 사용자의 행동 흐름에 맞춰 화면을 나누면 각 화면에서 해야 할 일이 더 분명해집니다.
| 단계 | 화면 | 핵심 기능 |
|---|---|---|
| 1 | 지역 선택 | 사용자가 확인할 지역을 선택한다. |
| 2 | 품목 검색 | 품목명이나 키워드로 검색한다. |
| 3 | 품목 상세 | 품목 정보와 수수료 안내를 확인한다. |
| 4 | 신고 안내 | 신고 방법과 배출 전 확인사항을 확인한다. |
| 5 | 외부 안내 이동 | 필요한 경우 지자체 안내 페이지나 신고 페이지로 이동한다. |
모든 내용을 한 화면에 넣는 방식은 작은 앱에서는 빠르게 만들 수 있습니다. 다만 지역이 늘어나고 안내 문구가 바뀌기 시작하면 수정 범위가 넓어집니다. 검색, 상세, 신고 안내를 분리해두면 나중에 데이터 구조를 바꾸거나 화면을 개선할 때 부담이 줄어듭니다.
테스트 기준
게시 전에는 화면 구조와 문구 기준을 함께 확인하는 편이 좋습니다. 특히 실제 행정 정보처럼 오해가 생기기 쉬운 데이터는 단정적인 표현을 피해야 합니다.
- 실제 행정 API URL이나 인증 키를 본문에 넣지 않는다.
- 내부 관리자 주소와 지역 코드 원문을 공개하지 않는다.
- 수수료를 확정 금액처럼 단정하지 않는다.
- 앱에서 신고가 완료되는지, 외부 페이지로 이동하는지 명확히 구분한다.
- 검색 결과 없음과 네트워크 오류를 다른 상태로 처리한다.
- 최신 신고 절차는 각 지자체 안내를 확인해야 한다는 문구를 남긴다.
자주 하는 실수
1. 품목 검색, 수수료 안내, 신고 안내를 한 화면에 모두 넣는 경우가 있습니다. 처음 만들 때는 빠를 수 있지만 지역별 안내가 늘어나면 화면이 금방 복잡해집니다.
2. 검색 결과 없음과 네트워크 오류를 같은 메시지로 처리하는 경우도 있습니다. 사용자는 검색어를 바꿔야 하는지, 다시 시도해야 하는지 구분하기 어렵습니다.
3. 수수료를 확정 금액처럼 표현하는 경우가 있습니다. 수수료는 지역과 기준일에 따라 달라질 수 있으므로 최종 확인 문구를 함께 두는 편이 좋습니다.
4. 앱에서 실제 신고가 완료되는 것처럼 문구를 쓰는 경우도 있습니다. 외부 신고 페이지로 이동하는 구조라면 앱은 안내 역할이라는 점을 명확히 보여줘야 합니다.
마무리
대형폐기물 정보 앱에서 중요한 것은 검색 기능 하나를 넣는 데서 끝나지 않습니다. 사용자가 품목을 찾은 뒤 어떤 안내를 보고, 어떤 행동으로 이어져야 하는지까지 흐름을 나눠야 합니다.
품목 검색, 수수료 안내, 신고 안내를 한 화면에서 처리하면 빠르게 구현할 수 있습니다. 운영 관점에서는 화면과 데이터를 나눠두는 편이 수정하기 쉽고, 사용자에게도 더 명확합니다. 특히 지역별 정보가 들어가는 앱이라면 검색 화면은 가볍게 유지하고, 신고 안내 화면에서 최신 확인 문구와 주의사항을 충분히 보여주는 구조를 먼저 검토해보면 좋습니다.
참고 자료
- Android Developers, Guide to app architecture
- Android Developers, UI state production
- Material Design, Empty states
- 각 지자체 대형폐기물 배출 및 신고 안내 문서
'개발 노트 > 기타' 카테고리의 다른 글
| [Android/공공데이터앱] 외부 검색 API와 내부 관리자 API를 함께 사용할 때의 경계 (0) | 2026.05.22 |
|---|---|
| [Android/공공데이터앱] 검색 결과가 없는 Android 앱에서 empty state를 설계하는 방법 (0) | 2026.05.22 |
| [UI/반응형] 앱 화면 최적화를 위한 문서와 테스트 체크리스트 작성 방법 (0) | 2026.05.21 |
| [UI Test] GitHub Actions UI 테스트 실패 로그를 읽고 원인을 좁히는 순서 (0) | 2026.05.21 |
| [Android Release] 여러 개의 Android 앱을 Play Store에 관리할 때 필요한 release matrix (0) | 2026.05.21 |