본문 바로가기
개발 노트/기타

[Android] 대형폐기물 정보 앱 화면 분리 및 데이터 구조 설계 기준 정리

by pposooj 2026. 5. 22.

이래저래 앱을 직접 개발하고 운영하다 보면, 지자체 행정 데이터나 공공 정보를 연동하는 유틸리티 서비스를 기획하게 될 때가 있습니다. 최근에 대형폐기물 수수료 안내 및 신고 절차를 다루는 서비스 구조를 고민해 볼 기회가 있었는데요.

이런 앱은 처음 만들 때 구현이 간단해 보인다는 이유로 품목 검색 결과 화면에 수수료, 배출 방법, 신고 버튼까지 한 번에 다 몰아넣기 쉽습니다. 하지만 운영을 하다 보면 지자체마다 데이터 차이가 커지고 안내 문구도 수시로 바뀌기 때문에, 한 화면에 다 때려 박은 구조는 나중에 유지보수할 때 그야말로 헬(Hell)이 됩니다.

자꾸 까먹기도 하고, 나중에 다시 참고하기 위해 Android 기반 대형폐기물 정보 앱을 기준으로 화면 책임 분리와 데이터 구조 설계 기준을 깔끔하게 정리해 둡니다.

1. 화면을 쪼개야 하는 이유 (화면 분리 기준)

품목 검색 화면과 신고 안내 화면은 사용자가 이 화면에 들어온 목적(Task) 자체가 완전히 다릅니다. 이 둘을 분리하지 않으면 화면이 과하게 무거워집니다.

  • 품목 검색 화면: 사용자가 버리려는 물건(의자, 책상, 매트리스 등)을 최대한 빠르게 찾는 데 집중해야 합니다. 검색 결과 목록에서는 품목명과 간단한 분류 정도만 가볍게 보여주고 상세 화면으로 넘기는 것이 안정적입니다.
  • 신고 안내 화면: 품목을 찾은 사용자가 실제로 '무엇을 해야 하는지' 다음 행동을 이해하도록 돕는 데 집중해야 합니다. 지역별 신고 절차와 주의사항을 명확히 전달하는 것이 핵심입니다.

화면 책임 분리를 단순하게 표로 정리하면 다음과 같습니다.

화면주요 목적포함하면 좋은 정보주의할 점
품목 검색 품목 후보 찾기 검색어, 품목명, 분류, 간단 안내 신고 절차를 너무 길게 넣지 않는다.
품목 상세 선택한 품목 정보 확인 품목명, 예상 수수료 범위, 지역별 확인 필요 문구 수수료를 확정 금액처럼 단정하지 않는다.
신고 안내 다음 행동 안내 신고 방법, 배출 전 확인사항, 지자체 안내 확인 문구 실제 신고 절차는 최신 지자체 안내를 확인하도록 안내한다.
지역 선택 지역별 차이 반영 시군구 선택, 지원 여부, 안내 메시지 정확하지 않은 지역 코드를 노출하지 않는다.
 

사용자의 행동 순서(지역 선택 → 품목 검색 → 상세 확인 → 신고 안내 → 외부 이동)에 맞춰 화면의 책임을 명확히 갈라놓으면, 나중에 특정 지자체의 안내 문구가 바뀌었을 때 검색 로직을 건드릴 필요 없이 해당 안내 화면만 수정하면 되므로 운영 관점에서 수정 범위가 아주 명확해집니다.

2. 데이터 구조도 화면 기준에 맞춰 나누기

화면을 나눴다면 백엔드와 클라이언트가 주고받는 데이터 모델도 함께 쪼개야 합니다. 당장 편하자고 품목 정보와 지자체 안내 데이터를 한 모델에 통으로 넣으면, 데이터 갱신할 때마다 불필요한 트래픽이 발생하고 모델 클래스 자체가 비대해집니다.

데이터 종류예시 필드사용 화면관리 기준
품목 기본 정보 품목명, 분류, 검색 키워드 검색, 상세 검색 품질에 영향을 주므로 변경 이력을 남긴다.
수수료 정보 금액, 단위, 지역, 기준일 상세 지역별 차이가 있으므로 확정 표현을 피한다.
신고 안내 신고 방법, 배출 전 확인사항, 외부 안내 여부 신고 안내 최신 지자체 안내 확인 문구를 함께 둔다.
지역 설정 지역명, 지원 여부, 안내 메시지 지역 선택, 상세, 신고 안내 실제 내부 코드나 API 주소는 보안상 외부로 공개하지 않는다.
 

⚠️ 실무 운영 팁 (수수료 데이터) 수수료 정보는 특히 조심해야 합니다. 지자체 조례가 바뀌어서 앱에 표시된 금액과 실제 금액이 다르면 사용자 컴플레인이 바로 들어옵니다. 따라서 금액 데이터에는 반드시 수수료 기준일이나 **"지자체 사정에 따라 변동될 수 있습니다"**라는 안내 문구를 세트로 묶어서 관리하는 편이 안전합니다.

3. 빈 결과(Empty)와 오류 상태(Error) 분리하기

이래저래 개발하다 보면 정말 놓치기 쉬운 부분이 바로 예외 처리 화면입니다. '검색 결과가 없는 상태'와 '네트워크 오류로 데이터를 못 불러온 상태'는 완전히 다른 상황입니다. 이를 같은 메시지로 퉁쳐서 보여주면 사용자는 내가 검색어를 잘못 입력한 건지, 앱이 고장 난 건지 알 방법이 없습니다.

사용자가 다음에 취해야 할 행동을 명확한 문구와 버튼으로 가이드해 줘야 합니다.

  • 검색 결과가 없을 때: 다른 품목명이나 비슷한 단어로 다시 검색하도록 유도 (예: '검색어 지우기' 버튼 제공)
  • 네트워크 오류일 때: 서버 일시 오류일 수 있으므로 잠시 후 다시 시도하도록 안내 (예: '다시 시도' 버튼 제공)
  • 지원하지 않는 지역일 때: 현재 앱에서 서비스를 제공하지 않는 지역임을 명확히 인지시킴 (예: '지역 다시 선택' 버튼 제공)

4. Android 화면 상태(UI State) 구현 예시

안드로이드에서 컴포즈(Compose)나 View 기반 화면을 만들 때, sealed interface를 활용해서 화면 상태를 먼저 정의해 두면 상태 분기가 아주 깔끔해집니다. 저의 경우 아래와 같은 형태로 구조를 잡아서 사용합니다.

Kotlin
 
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
)

이렇게 Empty와 Error를 명확히 인터페이스 수준에서 갈라놓아야 UI 단에서 각각에 맞는 안내 문구와 전용 일러스트, 인터랙션 버튼을 다르게 매핑하기 편합니다. 자꾸 한 클래스로 퉁치려고 하지 말고 처음부터 상태를 나누는 습관을 들여야 코드가 안 꼬입니다.

5. 신고 안내 화면에서 조심할 표현 (카피라이팅)

대형폐기물 앱은 결국 행정 정보와 맞물려 있기 때문에 문구 하나하나를 단정적으로 쓰지 않는 것이 중요합니다. 특히 앱 자체에서 결제 및 대형폐기물 스티커 발급을 직접 처리하지 않는 구조(정보 제공형 구조)라면 더더욱 문구에 신경 써야 합니다.

  • ❌ 피해야 할 표현: '접수 완료', '신고 완료', '수수료 5,000원 확정'
  • ⭕ 대체해야 할 표현: '지자체 페이지로 이동', '신고 안내 확인', '예상 수수료 약 5,000원 (지역별 확인 필요)'

앱 내 안내만 보고 진짜 신고가 끝난 줄 알고 폐기물을 밖에 그냥 내놓았다가 무단투기로 과태료를 무는 사용자가 생길 수 있습니다. 외부 신고 페이지로 이동하기 전에는 반드시 "외부 페이지로 이동합니다"라는 브릿지 안내를 띄워주는 편이 매끄럽습니다.

6. 배포 전 최종 테스트 기준 및 자주 하는 실수

글을 올리기 전이나 마켓에 앱을 빌드해서 올리기 전에 아래 체크리스트를 기반으로 누락된 부분이 없는지 항상 확인합니다.

📋 자체 검수 기준

  • [ ] 실제 행정 API URL이나 테스트용 인증 키가 본문 코드나 로그에 노출되지 않는가?
  • [ ] 서버 내부 관리자 주소나 가공되지 않은 지역 코드가 클라이언트에 그대로 노출되지 않는가?
  • [ ] 수수료를 무조건 맞는 '확정 금액'처럼 표현하지 않았는가?
  • [ ] 사용자가 앱 내에서 결제까지 끝난 것으로 오해할 만한 문구가 있는가?
  • [ ] Empty 상태와 Error 상태의 UI 및 대응 버튼이 다르게 동작하는가?
  • [ ] "최신 신고 절차는 각 지자체 안내를 확인해야 한다"는 면책 문구가 포함되었는가?

⚠️ 자주 하는 실수 요약

  1. 화면 몰아넣기: 구현이 빠르다는 이유로 한 화면에 검색, 수수료, 안내를 다 집어넣어 지자체 확장 시 코드가 터지는 경우
  2. 에러 퉁치기: 네트워크 에러와 검색 결과 없음을 동일한 에러 메시지로 처리해 사용자에게 혼란을 주는 경우
  3. 단정적 문구 사용: 공공데이터의 수수료 정보를 확정 금액인 것처럼 노출해 정보 불일치 컴플레인을 받는 경우
  4. 역할 모호성: 외부 페이지 연동 앱인데 마치 앱 내부에서 모든 행정 처리가 완료된 것처럼 UI 흐름을 설계하는 경우

마무리

대형폐기물 정보 앱과 같은 유틸리티 서비스의 핵심은 화려한 UI가 아닙니다. 사용자가 원하는 정보를 얼마나 오해 없이 빠르게 찾게 만들고, 지자체별로 계속해서 변하는 행정 데이터에 얼마나 유연하게 대응할 수 있도록 구조를 짜놓았는지가 핵심입니다.

처음부터 검색 화면은 가볍게 털어내고, 상세 확인과 신고 안내 화면의 역할을 엄격하게 분리해 두는 구조를 가져가시길 권장합니다.

🔗 참고 자료

  • Android Developers, Guide to app architecture
  • Android Developers, UI state production
  • Material Design, Empty states
  • 각 지자체 대형폐기물 배출 및 신고 안내 문서