Android/오르다 다이어리

[Android/오르다] 오르다 다이어리 레거시 리팩토링 00 - 계획 수립

yujinius 2025. 2. 10. 15:40

https://github.com/yujin45/Team3_Orda_Diary

 

GitHub - yujin45/Team3_Orda_Diary: 2022-2 Mobile Programming Final Team Project Assignment

2022-2 Mobile Programming Final Team Project Assignment - yujin45/Team3_Orda_Diary

github.com

💡 오르다 다이어리 리팩토링 - 계획 수립

네이버 부스트캠프를 통해 다져진 기본기를 바탕으로 이전 프로젝트를 리팩토링하기로 결정했다. 부스트캠프에서의 목표는 Kotlin과 Compose를 학습하여 이전 프로젝트에도 리팩토링을 진행하는 것이었다. 그러나 부스트캠프에서 Android 개발을 심층적으로 학습하면서, 과거 프로젝트들의 구조적 문제를 인식하게 되었고, Kotlin Compose로의 전환보다 먼저 Java, XML 상태에서의 구조 개선이 선행되어야 한다고 판단했다.

이전 프로젝트들은 거의 Activity 중심의 구조를 따르고 있었고, SQLite를 직접 접근하는 방식으로 데이터베이스를 다루고 있었다. 따라서 먼저 구조를 개선한 후 Kotlin 및 Compose를 적용하는 것이 더욱 효과적이라고 판단했다.

 

📝 프로젝트 선택 과정

최근 진행된 네이버 부스트캠프 9기 프로젝트인 Nature Album은 Kotlin과 Compose 기반으로 개발되었기 때문에 리팩토링 대상에서 제외했다. (따로 팀끼리 리팩토링 하고 있기는 하다.)

Nature Album을 제외한 모든 프로젝트의 코드들은 현재 완전한 레거시 코드 수준이다. Java와 XML을 기반으로 한 개발 방식, Activity 중심의 화면 전환, 직접적인 SQLite 접근 등 현대적인 Android 개발 방식과는 거리가 먼 구조를 가지고 있다.

과거 진행했던 프로젝트들은 모두 Java와 XML 기반으로 개발되었으며, 후보군으로 고려했던 프로젝트는 다음과 같다.

  • ASAP
  • 오르다 다이어리
  • 모동사
  • 무물보

이 중 오르다 다이어리를 첫 번째 리팩토링 대상으로 선택한 이유는 다음과 같다.

  1. 다양한 기능을 포함하고 있어 리팩토링할 요소가 많다.
    • 일정 관리, 알람, 일기 작성, 사진 저장 등 여러 기능이 포함되어 있어 리팩토링을 통해 다양한 기술을 적용할 수 있다.
  2. 서버나 유료 API가 필수적이지 않다.
    • 일부 프로젝트는 외부 서버 및 유료 API가 필수적이지만, 오르다 다이어리는 로컬 데이터베이스(SQLite)를 활용하고 있어 독립적으로 개선할 수 있다.
  3. 다른 프로젝트보다 구조적 개선이 필요한 부분이 많다.
    • 모동사, 무물보는 특정 기능 위주의 프로젝트라 개선 범위가 비교적 작았고, ASAP은 서버 연동이 필요해 우선순위를 낮췄다. 반면, 오르다 다이어리는 Activity 중심 구조, SQLite 직접 접근, UI 상태 관리 부족 등 개선할 부분이 많아 가장 적절한 첫 번째 리팩토링 대상이었다.

 

✅ 리팩토링 주요 목표

1. UI 상태 관리 개선

  • Configuration change 대응

2. Activity 기반 구조 → Fragment 중심 구조 전환

  • 기존 모든 화면이 Activity 간 Intent 전환되는 것으로 되어 있다. 이를 Fragment를 활용한 화면 전환으로 변경하여 사용성을 높여보자.

3. 데이터베이스 접근 방식 개선 (SQLite → RoomDB)

  • 현재 SQLiteOpenHelper 기반의 데이터 접근 방식을 RoomDB로 전환하자.

4. MVVM 아키텍처 적용

  • 기존 Activity에서 비즈니스 로직과 UI 로직이 혼재된 구조를 개선한다.
  • ViewModel과 LiveData를 활용하여 관심사 분리를 적용하고 databinding을 적용해보자.

5. 성능 최적화 및 메모리 사용량 개선

  • Android Profiler를 활용하여 기존 메모리 사용량과 CPU 부하를 분석한다.
  • 불필요한 static 변수 사용을 제거하는 등의 작업을 진행해보자.

 

📄 앞으로의 계획

이번 리팩토링은 단계적으로 진행되며, 현재 코드 분석 → 구조 개선 → 데이터 접근 방식 개선 → 아키텍처 개선 → 성능 최적화 흐름을 따를 예정이다.

  1. 기존 처음 버전 릴리즈
  2. 현재 코드 분석 및 문제점 정리
  3. UI 상태 관리 개선 (화면 회전 및 상태 저장)
  4. Fragment 전환 및 Jetpack Navigation 적용
    • Activity 간 Intent 전환을 Fragment 중심으로 변경하고, Jetpack Navigation Component를 적용한다.
  5. RoomDB 적용 및 데이터 계층 분리
    • SQLite 직접 접근 방식을 제거하고, RoomDB를 도입한다.
  6. MVVM 아키텍처 적용 및 코드 개선
    • ViewModel을 활용하여 UI와 데이터 로직을 분리하고, 전체 코드 아키텍처를 개선한다.
  7. 리팩토링 전후 성능 비교 및 최적화 결과 정리
    • Android Profiler를 사용하여 리팩토링 전후 성능 차이를 분석하고 정리한다.

이 과정을 통해 과거 프로젝트를 현대적인 Android 개발 방식으로 개선하고, 블로그를 통해 학습한 내용을 정리하여 공유할 예정이다. 다음 포스팅에서는 현재 코드 분석과 문제점 정리를 진행할 예정이다.