행복한 내 이야기

[Android/오르다 다이어리] 레거시 리팩토링 10 - Release 2 (v2.0.0) 완료 및 후기

yujinius — Sun, 2 Mar 2025 21:57:11 +0900

[Android/오르다 다이어리] 3년 전 레거시 리팩토링, 기능 완성 & UI/UX 개선 - Release 2 (v2.0.0) 후기

지난 글:https://yujinius45.tistory.com/164

[Android/오르다 다이어리] 레거시 리팩토링 09 - HomeFragment 애니메이션 적용 & UI 개선

[Android/오르다 다이어리] 레거시 리팩토링 09 - HomeFragment 애니메이션 적용 & UI 개선 지난 글:https://yujinius45.tistory.com/163 이제 기능 미완성이었던 것도 완성되고 UI/UX 개선도 완료되어서 릴리즈를

yujinius45.tistory.com

3년 전 레거시 코드 리팩토링, 그리고 마침내 기능 완성

오르다 다이어리를 처음 만들었을 때는 기능이 많았지만, 구조적으로 정리가 덜 되어 있었고, UI/UX에 대한 고민이 부족했던 상태였다.

처음 앱을 만들었을 때는 "기능만 구현되면 된다!"라는 마인드로 개발했었다.

하지만 3년이 지난 지금 다시 프로젝트를 리팩토링하면서,

과거에 미처 고려하지 못했던 부분들이 많았다는 걸 깨달았고, 이를 하나하나 개선해 나갔다.

이번 Release 2 (v2.0.0)에서는 미완성 기능을 완성하고, UX를 개선하며, 코드 구조를 리팩토링했다.

이번 프로젝트를 통해 많이 배웠던 점들을 정리해 보려고 한다.

3년 전 코드에서 개선이 필요했던 점

v1.0.0에서는 기본적인 일정 관리, 일기 작성, 알람, 지도 메모 기능이 포함되어 있었다.

하지만, 실제 사용하면서 여러 문제점이 드러났다.

❌ 기존 코드에서 개선이 필요했던 부분

UI/UX 문제
- 모든 화면이 개별적인 Activity로 구성되어 있어, 사용자가 홈으로 돌아가서 버튼을 눌러야만 다른 기능으로 이동 가능
- 화면 이동이 불편하고 비효율적이었으며, 처음 사용자가 홈 화면에서 어떻게 앱을 시작해야 하는지 명확하지 않았음
- 홈 화면이 정적 → 처음 앱을 실행한 사용자는 어떤 기능을 먼저 사용해야 할지 알기 어려움
기능 미완성
- MapMemo 기능이 완성되지 않음 → 앱을 종료하면 저장한 데이터가 사라지는 문제 발생
- DiaryWritingFragment의 상태 유지 불가 → 화면 회전 시 입력한 내용이 사라짐
코드 구조 및 보안 문제
- DBHelper가 MainActivity에 종속되어 있음 → 독립적인 테스트 및 유지보수가 어려움
- SQL Injection 취약점 존재 → 사용자의 입력값이 SQL 문과 함께 실행되어 보안 위험이 있었음
- 직접 SQLite를 사용 → 관리가 어려워 유지보수성이 떨어짐

리팩토링을 하며 배운 점

이번 프로젝트를 진행하면서 단순히 기능을 추가하는 것이 아니라, 어떻게 하면 유지보수하기 좋은 코드가 될까?를 고민하게 되었다.

내가 내 코드를 다시 보면서 개발을 할 때, 당장 기능이 동작하는 것보다, 이후 유지보수가 편하고 확장 가능한 코드를 작성하는 것이 중요하다는 것을 깨달았다.

1️⃣ 싱글톤 패턴을 적용하며 유지보수성이 높아진 사례

기존 코드 문제점:

기존에는 DBHelper가 MainActivity에서 static 변수로 선언되어 있었다.

즉, 어떤 Fragment에서든 DBHelper를 사용하려면 MainActivity를 먼저 실행해야 했다.

문제 발생 예시

public class MainActivity extends AppCompatActivity {
    public static DBHelper mDBHelper;  // MainActivity에 종속
}

이렇게 되면 DBHelper가 MainActivity에 강하게 결합되면서,

다른 클래스에서 MainActivity 없이 DBHelper를 사용할 수 없음
MainActivity가 실행되지 않으면 DBHelper도 초기화되지 않음
테스트 코드에서 독립적으로 DBHelper를 사용하기 어려움

해결 방법: 싱글톤 패턴 적용

public class DBHelper extends SQLiteOpenHelper {
    private static DBHelper instance;

    public static synchronized DBHelper getInstance(Context context) {
        if (instance == null) {
            instance = new DBHelper(context.getApplicationContext());
        }
        return instance;
    }
}

유지보수성이 어떻게 향상되었는가?

✅ DBHelper가 특정 Activity에 의존하지 않게 됨 → 어디서든 DBHelper.getInstance(context)로 호출 가능

✅ 테스트 코드에서 독립적으로 DBHelper를 사용할 수 있음

✅ 메모리를 절약하고 중복 인스턴스 생성을 방지함

2️⃣ MVVM 패턴 적용으로 개선

기존 코드 문제점:

기존에는 Activity, Fragment 등 UI에서 UI 상태를 직접 관리하고 있었다.

다른 화면들은 DB에서 데이터를 로드해와서 상태 유지를 하고 있었으나 일기 작성 화면 같은 경우 화면이 회전되면 데이터가 초기화되는 문제가 있었다.

문제 발생 예시

public class DiaryWritingFragment extends Fragment {
    private EditText diaryContent;

    @Override
    public void onViewCreated(@NonNull View view, @Nullable Bundle savedInstanceState) {
        diaryContent = view.findViewById(R.id.diaryContent);
    }
}

이렇게 하면 Fragment가 다시 생성될 때 데이터가 사라지는 문제 발생

해결 방법: ViewModel을 사용하여 데이터 상태 유지

public class DiaryViewModel extends ViewModel {
    private final MutableLiveData<String> diaryContent = new MutableLiveData<>();

    public LiveData<String> getDiaryContent() {
        return diaryContent;
    }

    public void setDiaryContent(String content) {
        diaryContent.setValue(content);
    }
}

어떻게 개선되었는가?

✅ 화면 회전 시에도 데이터가 유지됨 → 사용성이 향상됨

✅ UI 로직과 비즈니스 로직이 분리됨 → 이후 추가 기능을 넣는다면 ViewModel에 추가해주면 됨

✅ 테스트 코드에서 ViewModel만 따로 테스트 가능 → 추후 기능이 추가된다면 진행할 수 있음

3️⃣ SQL Injection 방지 및 코드 관리가 쉬워진 사례

기존 코드 문제점:

기존에는 사용자 입력값을 그대로 SQL 쿼리에 삽입하여 SQL Injection 취약점이 존재했다.

문제 발생 예시 (보안 취약)

db.execSQL("INSERT INTO TODOLIST_TB (title, content) VALUES ('" + title + "', '" + content + "');");

만약 사용자가 "'); DROP TABLE TODOLIST_TB; --"을 입력하면, DB 테이블이 삭제될 수 있음

해결 방법: Prepared Statement 사용

SQLiteDatabase db = getWritableDatabase();
String query = "INSERT INTO TODOLIST_TB (title, content) VALUES (?, ?)";
SQLiteStatement stmt = db.compileStatement(query);
stmt.bindString(1, title);
stmt.bindString(2, content);
stmt.executeInsert();

어떻게 개선되었는가?

✅ SQL Injection이 방어됨 → 보안 강화

✅ 쿼리가 가독성 좋게 정리됨 → 이후 추가할 때는 좀 더 읽기 쉬워졌음

✅ 테스트 코드에서 SQL이 정상 동작하는지 검증 가능

결론 및 마무리

이번 리팩토링을 통해, 앱을 단순히 기능만 구현하는 것이 아니라, 유지보수성이 높은 구조로 만드는 것이 중요하다는 것을 배웠다.

특히, 싱글톤 패턴 적용, MVVM 구조 도입, UI/UX 개선, 보안 강화 등의 작업을 진행하면서 성장할 수 있었다. (이후 더 작업을 진행한다면 RoomDB 적용을 고려해볼 것 같다. )

예전에는 기능이 돌아가기만 하면 된다고 생각했지만, 이제는 코드의 확장성과 유지보수성까지 고민하게 되었다.

앞으로도 더 좋은 코드와 UI/UX를 고민하면서 발전해 나가야겠다!

https://github.com/yujin45/Team3_Orda_Diary/releases/tag/v2.0.0 (상세 변경 사항은 릴리즈 노트 참고)

Release Orda Diary Release 2 (v2.0.0) · yujin45/Team3_Orda_Diary

What's Changed [Refactor] targetSdk 34 적용 및 권한 변경 대응 by @yujin45 in #1 [Refactor] Activity → Fragment 전환 및 기능 개선 + DB 수정 버그 해결 by @yujin45 in #2 [Refactor] DiaryWritingFragment Configuration Chang...

github.com

[Android/오르다 다이어리] 레거시 리팩토링 09 - HomeFragment 애니메이션 적용 & UI 개선

yujinius — Sun, 2 Mar 2025 20:24:35 +0900

[Android/오르다 다이어리] 레거시 리팩토링 09 - HomeFragment 애니메이션 적용 & UI 개선

지난 글:https://yujinius45.tistory.com/163

이제 기능 미완성이었던 것도 완성되고 UI/UX 개선도 완료되어서 릴리즈를 하려고 한다.

그 전에 마지막으로 HomeFragment를 개선했다.

HomeFragment UI 개선 및 애니메이션 적용

오르다 다이어리의 홈 화면(HomeFragment)에 애니메이션을 적용하여 UX를 개선했다.

기존에는 화면에 정적인 UI 요소만 배치되어 있었는데, 처음 앱을 실행하는 사용자가 어떤 동작을 해야 하는지 안내가 부족했다. 만약 처음 앱을 설치한 사람이었다면 Home 화면이 splash 화면이라고 오해했을 수도 있을 것 같아 개선이 필요함을 느꼈다.

▼ 아무런 안내가 없고 Home 화면이 정적이다.

이를 해결하기 위해 아래와 같은 작업을 수행했다.

"하단 버튼을 눌러 시작하세요" 문구에 fade in/out 애니메이션 추가하여 앱 사용 안내하기
타이틀, 서브타이틀, 메인 이미지에 슬라이드 애니메이션 추가하여 동적 요소 추가하기
Fragment 생명주기에 맞춰 애니메이션을 관리하여 메모리 누수 방지하기

개선 전 문제점

홈 화면이 너무 정적 → 첫 화면에서 아무런 UI 변화가 없어 사용자가 어떻게 시작해야 하는지 알기 어려움
사용자 안내 부족 → 앱을 실행하면 아무런 인터랙션 없이 로고와 타이틀만 표시
UX 향상 필요 → 애니메이션을 활용하여 자연스럽게 UI 요소를 배치하고 안내할 필요가 있음

✨ 개선된 UI 설계

적용된 애니메이션

UI 요소	적용된 애니메이션
메인 이미지 (`imageViewMain`)	위에서 아래로 슬라이드 등장
타이틀 (`textViewTitle`)	위에서 아래로 슬라이드 등장
서브타이틀 (`textViewSubTitle`)	위에서 아래로 슬라이드 등장
안내 문구 (`textViewInfo`)	Fade In/Out 반복

애니메이션 적용 과정

1️⃣ 애니메이션 XML 추가

애니메이션을 정의한 XML 파일을 res/anim/ 디렉토리에 추가해서 사용했다.

✅ 슬라이드 애니메이션 (text_slide_up.xml)

위에서 아래로 부드럽게 내려오는 애니메이션

<?xml version="1.0" encoding="utf-8"?>
<translate xmlns:android="http://schemas.android.com/apk/res/android"
    android:fromYDelta="-50%"
    android:toYDelta="0"
    android:duration="1000"
    android:interpolator="@android:anim/decelerate_interpolator"/>

✅ Fade In/Out 애니메이션 (fade_in_out.xml)

안내 문구가 부드럽게 깜빡이며 사용자에게 안내

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android"
    android:interpolator="@android:anim/accelerate_decelerate_interpolator">

    <alpha
        android:duration="2000"
        android:fromAlpha="0.0"
        android:toAlpha="1.0"
        android:repeatMode="reverse"
        android:repeatCount="infinite" />
</set>

2️⃣ HomeFragment UI 변경 (fragment_home.xml)

TextView ID 및 UI 구조 개선

"하단 버튼을 눌러 시작하세요" 안내 문구 추가

<TextView
    android:id="@+id/textViewInfo"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:fontFamily="@font/nanumleo_bold"
    android:gravity="center"
    android:text="@string/home_fragment_info"
    android:textColor="@color/orda_is_your_diary"
    android:textSize="16sp"
    app:layout_constraintBottom_toBottomOf="parent"
    app:layout_constraintEnd_toEndOf="parent"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintTop_toBottomOf="@id/textViewSubTitle" />

3️⃣ HomeFragment에서 애니메이션 적용

ViewBinding을 활용하여 UI 요소를 바인딩하고, Fragment 생명주기에 맞춰 애니메이션을 관리

onResume()에서 애니메이션 시작 / onPause()에서 정지하여 메모리 누수 방지

package smu.team3_orda_diary.ui.home;

public class HomeFragment extends Fragment {

    private FragmentHomeBinding binding;
    private Animation fadeAnimation, slideAnimation;

    @Override
    public View onCreateView(@NonNull LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
        binding = FragmentHomeBinding.inflate(inflater, container, false);
        return binding.getRoot();
    }

    @Override
    public void onViewCreated(@NonNull View view, @Nullable Bundle savedInstanceState) {
        super.onViewCreated(view, savedInstanceState);

        // 애니메이션 로드
        fadeAnimation = AnimationUtils.loadAnimation(requireContext(), R.anim.fade_in_out);
        slideAnimation = AnimationUtils.loadAnimation(requireContext(), R.anim.text_slide_up);
    }

    @Override
    public void onResume() {
        super.onResume();
        // 애니메이션 시작
        binding.imageViewMain.startAnimation(slideAnimation);
        binding.textViewTitle.startAnimation(slideAnimation);
        binding.textViewSubTitle.startAnimation(slideAnimation);
        binding.textViewInfo.startAnimation(fadeAnimation);
    }

    @Override
    public void onPause() {
        super.onPause();
        // 애니메이션 정지
        binding.imageViewMain.clearAnimation();
        binding.textViewTitle.clearAnimation();
        binding.textViewSubTitle.clearAnimation();
        binding.textViewInfo.clearAnimation();
    }

    @Override
    public void onDestroyView() {
        super.onDestroyView();
        binding = null; 
    }
}

애니메이션 적용 후 실행 화면

결과 & 개선 효과

✅ 홈 화면이 정적이지 않고 자연스러운 UI 변화 제공

✅ "하단 버튼을 눌러 시작하세요" 안내 추가로 사용자 경험 개선

✅ Fragment 생명주기에 맞춰 애니메이션 관리

✅ ViewBinding 적용으로 더 안전한 UI 참조 방식 적용

마무리

홈 화면에서의 사용자 경험을 개선하고, 보다 직관적인 안내를 제공할 수 있게 되었다.

이제 홈 화면을 더 쉽게 이해할 수 있으며, 앱을 처음 실행하는 사용자가 자연스럽게 다음 동작을 유도할 수 있다.

[Android/오르다 다이어리] 레거시 리팩토링 08 - SQL Injection 테스트 및 해결

yujinius — Sun, 2 Mar 2025 19:46:54 +0900

[Android/오르다 다이어리] 레거시 리팩토링 08 - SQL Injection 테스트 및 해결

지난 글: https://yujinius45.tistory.com/162

[Android/오르다 다이어리] 레거시 리팩토링 07 - SQLite, MapMemo 기능 완성

[Android/오르다 다이어리] 레거시 리팩토링 07 - SQLite, MapMemo 기능 완성지난 글: https://yujinius45.tistory.com/161 [Android/오르다 다이어리] 레거시 리팩토링 06 - DBHelper 싱글톤 패턴 적용[Android/오르다 다이

yujinius45.tistory.com

지난 번 MapMemo 기능을 완성 작업을 진행하면서 DBHelper를 보다가 문득 SQL Injection이 가능한 코드라는 생각이 들었다. 그래서 이에 대해 시도해보고 Injection을 방어할 수 있게 해결해보고자 한다.

SQL Injection 테스트 및 해결 과정

기존 DBHelper 코드

현재 DBHelper 클래스의 insertTodo 메서드는 아래와 같이 구현되어 있다.

public void insertTodo(String _title, String _content, String _writeDate) {
    SQLiteDatabase db = getWritableDatabase();
    db.execSQL("INSERT INTO TODOLIST_TB (title, content, writeDate) VALUES ('" + _title + "','" + _content + "','" + _writeDate + "');");
}

이전 테스트 코드들을 작성하면서 SQL Injection이 실제로 가능한지 확인해보고 싶어졌다. Room DB와 같은 ORM을 사용하면 이러한 문제를 방지할 수 있지만, 현재 레거시 코드에서는 직접 SQL을 실행하기 때문에 보안 위험이 존재한다고 판단하여 이를 직접 테스트해보기로 했다.

SQL Injection 테스트 코드

아래와 같은 테스트 코드를 작성하여 SQL Injection의 가능성을 검증했다.

@Test
public void testSQLInjectionUpdateTodo() {
    dbHelper.insertTodo("Todo A", "Content A", "2025-03-01");
    dbHelper.insertTodo("Todo B", "Content B", "2025-03-01");
    dbHelper.insertTodo("Todo C", "Content C", "2025-03-01");

    ArrayList<TodoItem> todoList = dbHelper.getTodoList("2025-03-01");
    assertEquals(3, todoList.size());

    int targetTodoId = todoList.get(0).getId();

    // SQL Injection 시도 - 모든 데이터를 업데이트하도록 WHERE 조건 변경
    String injectionTitle = "Injected Title', writeDate='2025-03-02' WHERE id=id OR 1=1 --";

    dbHelper.updateTodo(targetTodoId, injectionTitle, "Injected Content", "2025-03-02", "2025-03-01");

    ArrayList<TodoItem> manipulatedList = dbHelper.getTodoList("2025-03-02");

    // Injection이 성공했다면 모든 To-Do의 날짜가 변경됨 (원래 1개만 변경되어야 함)
    assertTrue("SQL Injection should have updated multiple rows unexpectedly!", manipulatedList.size() > 1);
}

테스트 결과

3개의 값을 넣어두고 의도대로라면 1개만 변경되어야 하지만, WHERE 1=1을 추가하는 Injection을 시도하여 모든 행이 업데이트되는 결과가 발생했다.

테스트 결과 SQL Injection이 성공하여 1개가 아니라 모든 행이 다 업데이트 되어 버렸다.

▼ SQL Injection 테스트 코드 통과 캡쳐

실제 앱에서 실행한 결과

실제 앱에서도 동일한 Injection을 수행했을 때, 앱이 크래시하는 문제가 발생했다.

▼ 할 일 추가 제목에 Injection 시도 → 결과: 앱 크래시 종료

이처럼 SQL 쿼리에 사용자 입력값을 직접 포함하면 발생하는 문제다. SQL Injection에 대해 이론적으로만 알고 있었는데, 직접 테스트를 통해 실제로 발생할 수 있는 보안 문제임을 확인할 수 있었다.

✅ 잠깐, SQL Injection이란?

SQL Injection은 사용자 입력값이 SQL 쿼리에 직접 삽입될 때 발생하는 보안 취약점으로, 악의적인 사용자가 SQL 문을 변조하여 데이터베이스의 내용을 무단 조회, 수정, 삭제하는 공격 기법이다.

SQL Injection의 위험성

데이터 변조: WHERE 1=1을 추가하여 모든 데이터를 변경할 수 있음
데이터 유출: UNION SELECT 등을 사용하여 테이블의 모든 데이터 조회 가능
데이터 삭제: DROP TABLE 명령을 삽입하여 테이블 삭제 가능

SQL Injection 방지 방법 (Prepared Statement 사용)

SQLite를 사용하는 현 상황에서 SQL Injection을 방지하기 위해 Prepared Statement를 사용할 수 있다.

✅ Prepared Statement란?

Prepared Statement는 SQL 쿼리를 실행할 때 미리 컴파일된 SQL 문을 사용하는 방식이다. 즉, 애플리케이션이 SQL 문을 실행할 때마다 전체 SQL 문을 다시 해석(파싱)하고 실행하는 것이 아니라, 미리 컴파일된 SQL 문을 재사용하는 방식이다.

이 방식은 SQL Injection 공격을 방지하고, 성능을 최적화하는 데 도움을 준다.

✅ Prepared Statement의 동작 과정

SQL 템플릿을 미리 컴파일→ ?(바인딩 변수)를 포함한 SQL 문을 먼저 데이터베이스에 전달하여 컴파일함.
사용자 입력 값과 SQL을 분리→ ? 자리에 들어갈 실제 값을 나중에 바인딩(대입)하여 실행.
실제 값이 SQL과 함께 실행됨→ 입력 값은 데이터베이스 엔진에서 문자열 값 그대로 처리되며, 실행 계획을 변경하지 않음.

✅ Prepared Statement 예제 (SQLite 사용)

SQLiteDatabase db = getWritableDatabase();
String sql = "INSERT INTO TODOLIST_TB (title, content, writeDate) VALUES (?, ?, ?)";

SQLiteStatement stmt = db.compileStatement(sql);
stmt.bindString(1, title);
stmt.bindString(2, content);
stmt.bindString(3, writeDate);
stmt.executeInsert();

여기서 ?에 들어갈 값을 bindString()으로 바인딩(대입)하고 실행하는 방식
이렇게 하면 사용자가 입력한 값이 SQL 문 자체에 포함되지 않고 독립적인 데이터 값으로 처리됨

✅ ? 바인딩이 Escape 처리를 한다는 의미

SQL Injection의 핵심은 사용자의 입력값이 SQL 문법과 결합되어 의도치 않은 실행을 유도하는 것이다.

예를 들어, 기존 코드에서는 다음과 같이 문자열을 직접 SQL 문에 삽입하고 있었다

String query = "SELECT * FROM TODOLIST_TB WHERE title = '" + userInput + "'";

위 코드에서 userInput에 만약 ' OR 1=1 -- 같은 값이 들어가면?

SELECT * FROM TODOLIST_TB WHERE title = '' OR 1=1 --'

1=1은 항상 참(True)이므로 모든 데이터가 반환됨.
- 이후는 주석 처리되어 SQL 구문이 변조됨.

하지만 Prepared Statement에서는 ? 바인딩을 사용하여 Escape 처리를 자동으로 수행한다.

String query = "SELECT * FROM TODOLIST_TB WHERE title = ?";
Cursor cursor = db.rawQuery(query, new String[]{userInput});

여기서 ? 자리에 입력값이 들어갈 때, 자동으로 Escape 처리되어 문자열 그대로 사용된다.

즉,

사용자가 ' OR 1=1 -- 같은 값을 입력하더라도
데이터베이스 엔진은 이를 문자열 값 그대로 해석하고,
SQL 문법과 결합되지 않도록 안전하게 처리하게 되는 것이다.

✅ Escape 처리란?

Escape 처리는 특수 문자(', ", ;, -- 등)가 SQL 문법으로 해석되지 않도록 보호하는 방법이다.

Prepared Statement에서 자동으로 Escape 처리를 수행하므로,
개발자가 따로 replace("'", "\\'") 같은 조작을 할 필요가 없다.

다시 돌아와서 수정해보자.

☠️ 기존의 취약한 코드 (❌ 위험한 방식)

public void updateTodo(int _id, String _title, String _content, String _writeDate) {
    SQLiteDatabase db = getWritableDatabase();
    db.execSQL("UPDATE TODOLIST_TB SET title='" + _title + "', content='" + _content + "', writeDate='" + _writeDate + "' WHERE id=" + _id);
}

문제점:

사용자 입력값이 직접 SQL 문에 삽입됨 → SQL Injection 위험

개선된 안전한 코드 (✅ Prepared Statement 사용)

public void updateTodoSecure(int _id, String _title, String _content, String _writeDate) {
    SQLiteDatabase db = getWritableDatabase();
    String query = "UPDATE TODOLIST_TB SET title = ?, content = ?, writeDate = ? WHERE id = ?";
    db.execSQL(query, new Object[]{_title, _content, _writeDate, _id});
}

✔ ? 바인딩을 사용하면 SQL Injection을 방어할 수 있음
✔ 입력값을 자동으로 Escape 처리하여 악의적인 SQL 코드 실행 방지
✔ SQL 문법이 깨지지 않아 앱이 크래시하는 문제도 해결

개선된 코드 테스트

위의 방법으로 DBHelper를 수정하고 다시 테스트 코드를 실행한 결과, Injection이 차단되어 더 이상 여러 개의 행이 변경되지 않음을 확인할 수 있었다.

▼ SQL Injection 테스트 코드가 통과되지 못하는 것 캡쳐 및 앱이 크래시 되지 않은 상태 캡쳐

✅ Injection 시도 후에도 1개의 행만 업데이트됨
✅ 앱 크래시 문제 해결
✅ Injection 방어 성공

⭐ DBHelper에 Prepared Statement를 적용하기 전 테스트 코드를 작성해두자.

변경이 원래 기능에 영향이 미치지 않는지 확인용으로 테스트 코드를 작성해두고자 한다.
또한, 위의 Injection 테스트 코드를 아래와 같이 변경하여 Injection 방어가 되었다면 테스트가 통과 되도록 변경했다.

 // Injection이 성공했다면 모든 To-Do의 날짜가 변경됨 (원래 1개만 변경되어야 함)
        //assertTrue("SQL Injection should have updated multiple rows unexpectedly!", manipulatedList.size() > 1);
        // Injection 방어 코드 작성 후 False가 되어야 테스트 코드 통과
        assertFalse("SQL Injection should have updated multiple rows unexpectedly!", manipulatedList.size() > 1);

아래와 같이 코드 변경 전, 후로 동일하게 테스트 코드가 통과되는 것을 확인했다.

자세히 보면 Prepared Statement 적용 후 실행 시간이 살짝 증가한 것을 볼 수 있다. 이는 테스트 환경에서 Prepared Statement가 처음 실행되어 SQL 파싱, 컴파일, 실행 준비 과정으로 인해 증가한 것으로 볼 수 있다. 이후 실제 앱 사용에서 같은 SQL을 다시 실행할 때는 이미 준비된 SQL을 활용해서 파싱/컴파일 과정 없이 값만 바인딩해서 바로 실행되므로 시간이 절약될 것이다.

⭐ SQL Injection 테스트 및 해결 과정 결론

이번 테스트를 통해 레거시 코드에서 SQL Injection이 발생할 수 있음을 확인했고, 이를 방지하기 위해 Prepared Statement를 사용한 안전한 SQL 실행 방식을 적용했다.

☺️ 후기

SQL Injection을 직접 테스트하면서 배운 점
- 예전에는 이론적으로만 알던 SQL Injection이 실제로 앱에서 어떻게 발생하는지 경험하면서 더 확실히 이해할 수 있었다.
- Prepared Statement를 적용하고 나서 Injection이 방어되는 걸 직접 테스트로 확인하니 보안적인 개선이 체감되었다.
- 앱 보안을 고려한 SQL 실행 방식이 얼마나 중요한지 다시 한번 깨달았다.
향후 개선하고 싶은 부분
- SQLite → Room으로 마이그레이션 하는 것을 고려하고 있다.
- SQLite를 사용해도 충분히 구현 가능하지만 버전 관리 및 유지보수 편리성으로 Room으로 마이그레이션 하는 것이 좋을 것 같다는 생각을 했다. 추가 리팩토링이나 기능 추가가 된다면 그때 Room으로 변경해보는 것을 고려해봐야겠다.

[Android/오르다 다이어리] 레거시 리팩토링 07 - SQLite, MapMemo 기능 완성

yujinius — Sun, 2 Mar 2025 19:39:57 +0900

[Android/오르다 다이어리] 레거시 리팩토링 07 - SQLite, MapMemo 기능 완성

지난 글: https://yujinius45.tistory.com/161

[Android/오르다 다이어리] 레거시 리팩토링 06 - DBHelper 싱글톤 패턴 적용

[Android/오르다 다이어리] 레거시 리팩토링 06 - DBHelper 싱글톤 패턴 적용 지난글: https://yujinius45.tistory.com/160 [Android/오르다 다이어리] 레거시 리팩토링 05 - Configuration Change 대응 (ViewModel 적용)[Androi

yujinius45.tistory.com

지난 글을 통해 DBHelper를 싱글톤으로 변경하였고 이에 따라 테스트 코드 작성이 원활해졌다. DBHelper를 싱글톤으로 변경하면서 테스트 코드 작성이 가능해진 이유는 다음과 같다.

기존 구조의 문제 (MainActivity 의존)

기존에는 MainActivity에서 static으로 선언된 mDBHelper를 import해서 사용
즉, DBHelper를 사용하려면 반드시 MainActivity가 실행되어야 하는 구조
→ 테스트 코드에서 DBHelper를 단독으로 사용하기 어려웠음.

✅ 싱글톤 패턴 적용 후 개선된 점

MainActivity 의존성 제거
- MainActivity.mDBHelper를 참조하는 방식이 사라짐
- DBHelper.getInstance(context)를 호출하면 어디서든 같은 인스턴스를 사용할 수 있음.
  → 테스트 코드에서 MainActivity 없이 독립적으로 DBHelper를 사용할 수 있음!
테스트 환경에서도 context를 넘겨줄 수 있음
- 테스트 코드에서 ApplicationProvider.getApplicationContext() 같은 방식으로 독립적인 context를 제공 가능.
- 따라서, DBHelper.getInstance(context)를 호출해서 데이터베이스 테스트가 가능해짐.

정리하면?

✅ 이전에는 MainActivity 실행이 필요했지만, 이제는 테스트 코드에서 직접 DBHelper.getInstance(context)를 호출할 수 있어서 독립적인 테스트 코드 작성이 가능해진 것이다!

오늘 진행 내용 미리보기

그래서 오늘은 테스트 코드를 추가하고, MapMemo의 기능을 완성해줄 예정이다. MapMemo 같은 경우 DB에 저장되지 않아 메모가 날라가는 문제가 있었다.

▼ MapMemo 데이터 유지X Configuration change 대응X

이번 작업에서는 ⭐ MapMemo를 저장할 Table을 추가하고, 데이터 저장/불러오는 코드를 작성한 후, 테스트를 먼저 진행한 뒤 로직을 추가하는 방식으로 진행했다.

이 과정에서 SQLite 사용의 불편한 점도 함께 살펴보았다. 또한, SQL Injection을 직접 테스트 해보고 이를 방지하기 위해 Prepared Statement를 적용해보았다 . 이 부분은 다음 글에 작성해보겠다. 오늘은 MapMemo 기능 완성에 집중해보자.

현재 방식: SQLite로 cursor 옮기며 직접 쿼리 실행

현재 SQLite를 사용할 때, 직접 SQL 쿼리를 실행하고 Cursor를 통해 데이터를 처리하는 방식이다.

// SQLite 방식 - Cursor 사용 (불편한 점)
Cursor cursor = db.rawQuery("SELECT * FROM MAPMEMO_TB", null);
while (cursor.moveToNext()) {
    int id = cursor.getInt(cursor.getColumnIndexOrThrow("id"));
    String title = cursor.getString(cursor.getColumnIndexOrThrow("title"));
    String content = cursor.getString(cursor.getColumnIndexOrThrow("content"));
    double latitude = cursor.getDouble(cursor.getColumnIndexOrThrow("latitude"));
    double longitude = cursor.getDouble(cursor.getColumnIndexOrThrow("longitude"));
}
cursor.close();

이 방식은 코드가 길어지고 가독성이 떨어진다는 문제가 있다.

❓만약 Room이라면?

// Room 방식 - DAO를 활용한 간결한 코드
@Query("SELECT * FROM mapmemo_tb")
fun getAllMapMemos(): List<MapMemoItem>

차이점:

SQLite는 Cursor를 사용하여 getColumnIndex()로 일일이 값을 가져와야 함 (가독성이 안 좋음).
Room에서는 SQL 없이 DAO 메서드를 호출하는 것만으로 데이터를 가져올 수 있음.

✋ 잠깐! 혹시 cursor를 처음 보나요?

그렇다면 아래를 읽어보면 좋다. 요즘은 RoomDB를 많이 써서 이렇게 cursor로 직접 db를 다루는 코드는 익숙하지 않을 수 있다.

️ SQLite란?

SQLite는 경량화된 관계형 데이터베이스(RDBMS)로, 앱 내에서 독립적으로 실행되는 데이터베이스이다.

즉, 별도의 서버 없이 파일 기반으로 동작하고, 안드로이드에서도 기본 제공되는 내장 DB이다.

✅ 특징

서버 없이 동작하는 임베디드(Embedded) 데이터베이스
파일 기반으로 동작 (앱 내부의 .db 파일에 데이터 저장)
SQL 문법을 지원 (SELECT, INSERT, UPDATE, DELETE 등)
앱이 설치된 기기에서 로컬 데이터 저장 용도로 사용됨

✅ SQLite 사용 방법

데이터베이스 생성 및 테이블 정의
SQL 쿼리를 실행하여 데이터 삽입, 조회, 수정, 삭제
조회된 데이터를 Cursor를 통해 접근 및 처리

️ Cursor란?

Cursor는 SQL 조회(SELECT) 결과를 가리키는 포인터이다.

즉, 쿼리 실행 결과를 담고 있는 데이터셋을 가리키는 객체로, 데이터를 한 행씩 이동하면서 읽을 수 있다.

✅ Cursor의 역할

SELECT 쿼리를 실행하면, 결과 데이터들이 Cursor에 저장됨
moveToNext()를 호출하여 한 행씩 이동하면서 데이터를 읽을 수 있음
getColumnIndex("컬럼명") 또는 getColumnIndexOrThrow("컬럼명")을 사용하여 특정 컬럼의 데이터를 가져옴
데이터 처리가 끝나면 cursor.close()를 호출하여 메모리 해제를 해줘야 함

SQLite + Cursor를 이용한 데이터 조회 원리

SQLite에서 데이터를 조회하고 Cursor를 사용하여 데이터를 가져오는 기본적인 원리를 코드와 함께 설명하자면 다음과 같다.

✅ 1. 데이터베이스 테이블 생성

db.execSQL("CREATE TABLE IF NOT EXISTS USERS (" +
           "id INTEGER PRIMARY KEY AUTOINCREMENT, " +
           "name TEXT NOT NULL, " +
           "age INTEGER NOT NULL);");

USERS 테이블을 만들고, id, name, age 컬럼을 포함함.

✅ 2. 데이터 삽입 (INSERT)

SQLiteDatabase db = getWritableDatabase();
db.execSQL("INSERT INTO USERS (name, age) VALUES ('Alice', 25)");
db.execSQL("INSERT INTO USERS (name, age) VALUES ('Bob', 30)");

INSERT INTO USERS를 실행하여 데이터를 추가함.

✅ 3. 데이터 조회 (SELECT)와 Cursor 사용

SQLiteDatabase db = getReadableDatabase();
Cursor cursor = db.rawQuery("SELECT * FROM USERS", null);

while (cursor.moveToNext()) {
    int id = cursor.getInt(cursor.getColumnIndexOrThrow("id"));
    String name = cursor.getString(cursor.getColumnIndexOrThrow("name"));
    int age = cursor.getInt(cursor.getColumnIndexOrThrow("age"));

    System.out.println("ID: " + id + ", Name: " + name + ", Age: " + age);
}
cursor.close();

처리 과정

rawQuery("SELECT * FROM USERS", null)를 실행하면, Cursor 객체가 반환됨.
moveToNext()를 호출하여 Cursor가 한 행씩 이동하면서 데이터를 읽음.
getColumnIndexOrThrow("컬럼명")을 사용하여 컬럼의 인덱스를 가져옴.
getInt(), getString() 등의 메서드로 데이터를 읽음.
cursor.close()를 호출하여 Cursor를 닫고 메모리 해제.

Cursor를 사용하지 않으면?

만약 Cursor를 사용하지 않는다면, 데이터 조회 후 반환되는 행들을 직접 처리할 방법이 없다.

즉, 반복문을 사용하여 데이터를 한 줄씩 이동하면서 읽는 과정이 불가능해진다.

→ Cursor는 SQLite의 데이터를 읽는 핵심적인 역할을 담당하는 객체!

정리

SQLite는 앱 내부에서 독립적으로 실행되는 가벼운 RDBMS이며, SQL 문법을 그대로 사용해서 데이터를 저장하고 조회할 수 있다.

Cursor는 SQL 쿼리 결과를 가리키는 포인터로, 데이터를 한 행씩 이동하면서 읽는 역할을 한다.

moveToNext()를 이용해 한 줄씩 데이터를 이동하면서 컬럼 값을 가져오는 방식으로 처리한다.

참고: Room

Room은 SQLite의 기능을 추상화하여 보다 편리하게 데이터베이스 작업을 수행할 수 있도록 설계된 라이브러리이다.
Room은 내부적으로 SQLite를 사용하지만, 개발자가 직접 SQL 쿼리를 작성하고 Cursor를 다루는 복잡성을 줄여준다. 대신, Entity, DAO(Data Access Object), Database의 세 가지 주요 구성 요소를 통해 데이터베이스 작업을 수행한다.

Room은 Nature Album에서 사용했었는데 확실히 지금 이렇게 cursor로 하는 것보다 헷갈리지 않고 편했었다. 그래도 오르다 다이어리는 우선 기존 방식 그대로 SQLite를 cursor를 통해 접근하는 기존 방식으로 일단 진행해보고자 한다.

MapMemoItem 추가

Java 버전과 Kotlin 버전 비교

기존 Java 방식:

public class MapMemoItem {
    private int id;
    private String title;
    private String content;
    private double latitude;
    private double longitude;

  // getter, setter, constructor 필요
    public MapMemoItem(int id, String title, String content, double latitude, double longitude) {
        this.id = id;
        this.title = title;
        this.content = content;
        this.latitude = latitude;
        this.longitude = longitude;
    }

    public int getId() {
        return id;
    }

    // 생략
}

Kotlin으로 변경하면 가독성이 좋아진다.

package smu.team3_orda_diary.model

data class MapMemoItem(
    val id: Int,
    val title: String,
    val content: String,
    val latitude: Double,
    val longitude: Double
)

getter, setter 없이 가독성이 좋아져서 Kotlin을 선택했다.

MapMemo 테이블 추가와 DB Upgrade

테이블 수정이 있을 때마다 DB 버전을 올려야 한다.
기존 유저와 신규 유저 모두 정상 동작하도록 CREATE와 onUpgrade()에 추가해야 한다.

public class DBHelper extends SQLiteOpenHelper {
    public static final int DB_VERSION = 2;
    public static final String DB_NAME = "Ordatest5.db";
...
    @Override
    public void onCreate(SQLiteDatabase db) {
    ...
        db.execSQL("CREATE TABLE IF NOT EXISTS MAPMEMO_TB (" +
                "id INTEGER PRIMARY KEY AUTOINCREMENT, " +
                "title TEXT NOT NULL, " +
                "content TEXT NOT NULL, " +
                "latitude REAL NOT NULL, " +
                "longitude REAL NOT NULL);");
    }
...
    @Override
    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
        if (oldVersion < 2) {
            db.execSQL("CREATE TABLE IF NOT EXISTS MAPMEMO_TB (" +
                    "id INTEGER PRIMARY KEY AUTOINCREMENT, " +
                    "title TEXT NOT NULL, " +
                    "content TEXT NOT NULL, " +
                    "latitude REAL NOT NULL, " +
                    "longitude REAL NOT NULL);");
        }
    }
}

의문점: 테이블 수정 있을 때마다 onUpgrade()이 변경되어 복잡해지는가? ⇒ yes

이전까지는 버전 1인 상태였지만 테이블 수정이 일어나면 버전을 올리고 onUpgrade()에 작업을 해줘야 한다. 위의 코드에서 볼 수 있듯이 버전 업되어 수정사항이 생길 수록 많은 코드가 작성될 것으로 보이지 않는가?

맞다. 테이블 수정이 있을 때마다 onUpgrade()가 점점 복잡해질 수 있다.

해결 방법

1️⃣ DB Migration 클래스를 따로 관리하기

public class DBMigration {
    public static void migrate(SQLiteDatabase db, int oldVersion, int newVersion) {
        if (oldVersion < 2) {
            db.execSQL("CREATE TABLE IF NOT EXISTS MAPMEMO_TB (" +
                    "id INTEGER PRIMARY KEY AUTOINCREMENT, " +
                    "title TEXT NOT NULL, " +
                    "content TEXT NOT NULL, " +
                    "latitude REAL NOT NULL, " +
                    "longitude REAL NOT NULL);");
        }
    }
}

DBHelper에서는 아래처럼 DBMigration.migrate() 호출만 하면 된다.

@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
    DBMigration.migrate(db, oldVersion, newVersion);
}

2️⃣ Room Database 사용 고려 (장기적으로 가장 효율적인 방법)

Room을 사용하면 자동으로 버전 변경을 감지하고 Migration을 쉽게 관리할 수 있다.

@Database(entities = {MapMemoItem.class}, version = 2)
public abstract class AppDatabase extends RoomDatabase {
    public abstract MapMemoDao mapMemoDao();
}

✅ 고민과 결론

현재만 수정이 이루어졌고 이후에 또 추가 기능이 언제 들어올지는 모른다. 그래서 사실 class로 빼지 않아도 된다. 또한 Room DB도 지금 저 버전 업 하나 때문에 교체하기에는 애매하다.
결론적으로 다음에 DB 변경이 필요하게 되면 Room으로 아예 Migration 하여 관리하기 쉽게 해야겠다.
현재는 방법만 알아두고 일단 MapMemo 기능 완성부터 진행하고자 한다.

진행 결과

MapMemo가 이제 DB에 저장되도록 수정되었다.
테스트 코드 작성 후, SQLite 정상 동작 확인 완료했다.
Fragment 로직 적용: 저장 시 DB에 저장하고, 앱 재시작 시 DB에서 불러와 지도에 표시하도록 했다.

결과적으로, 이전에는 MapMemo가 유지되지 않았지만, 이제는 저장 후 다시 불러와도 유지되어 데이터 저장은 물론 Configuration change 대응도 된 것이다!

▼ MapMemo 데이터 유지O Configuration change 대응O

[Android/오르다 다이어리] 레거시 리팩토링 06 - DBHelper 싱글톤 패턴 적용

yujinius — Sat, 1 Mar 2025 23:52:55 +0900

[Android/오르다 다이어리] 레거시 리팩토링 06 - DBHelper 싱글톤 패턴 적용

지난글: https://yujinius45.tistory.com/160

[Android/오르다 다이어리] 레거시 리팩토링 05 - Configuration Change 대응 (ViewModel 적용)

[Android/오르다 다이어리] 레거시 리팩토링 05 - Configuration Change 대응 (ViewModel 적용) 지난 글: https://yujinius45.tistory.com/159 [Android/오르다 다이어리] 레거시 리팩토링 04 - Fragment 마이그레이션[Android/오

yujinius45.tistory.com

ViewModel 도입 과정에서 발견한 DBHelper 문제

지난 글에서는 Configuration Change 대응을 위해 ViewModel을 도입하고, LiveData와 DataBinding을 활용하여 MVVM 패턴을 적용했다.

이 과정에서 ViewModel에서 DBHelper를 주입하는 과정에서 예상치 못한 문제를 발견했다.

바로, DBHelper가 여러 개 생성될 수 있다는 점이었다!

"어? 우리는 DBHelper가 하나만 존재해야 한다고 생각했는데...?"

MVVM 패턴 적용을 통해 UI와 비즈니스 로직을 분리하면서 오히려 과거 우리가 의도했던 구조의 문제점이 드러난 것이었다.

과거 우리 팀이 DBHelper를 설계했던 방식

⏳ 3년 전, 오르다 다이어리를 처음 만들던 시절

오르다 다이어리 프로젝트를 처음 시작할 때, 우리 팀은 DBHelper를 어떻게 관리할지 고민했다.

당시 우리 팀의 프로그래밍 사고방식은 이랬다.

"DBHelper는 어차피 SQLite에 접근해서 데이터를 저장/조회하는 용도인데, 굳이 여러 개 만들 필요 있을까?"

"하나만 만들어서 모든 곳에서 공유해서 쓰면 되지 않을까?"

그래서 MainActivity에서 DBHelper를 static으로 선언한 후, 모든 곳에서 MainActivity.mDBHelper를 import해서 사용했다.

당시 우리가 선택한 코드 (기존 방식)

public class MainActivity extends AppCompatActivity {
    private ActivityMainBinding binding;
    private NavController navController;
    public static DBHelper mDBHelper;  // static으로 선언

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        binding = ActivityMainBinding.inflate(getLayoutInflater());
        setContentView(binding.getRoot());

        mDBHelper = new DBHelper(this);  // MainActivity에서 직접 생성
    }
}

이 방식을 선택한 이유는 단순했다.

"static으로 선언하면 앱 전역에서 같은 인스턴스를 공유할 수 있겠지?"

결과적으로 우리가 원했던 대로 동작했다.

한 번 생성된 DBHelper를 여러 Fragment에서 import하여 그대로 사용할 수 있었음.

하지만...!

이 방식이 생각보다 많은 문제를 내포하고 있었다.

ViewModel에 DBHelper를 주입하며 발견한 문제

이전 포스팅에서 MVVM 패턴을 적용하면서 ViewModel에서 DBHelper를 주입하는 코드가 필요했다.

그런데 이 과정에서 충격적인(?) 사실을 발견했다.

DBHelper를 새로 생성해서 넣을 수 있었다!

즉, 우리가 의도했던 "DBHelper는 하나만 있어야 한다"는 규칙이 깨질 가능성이 있었다.

이제 이 방식의 구체적인 문제점을 살펴보자.

❌ 기존 방식의 문제점 (MainActivity에서 관리하는 방식)

1️⃣ MainActivity에 대한 강한 의존성

현재 코드에서는 DBHelper를 사용하려면 반드시 MainActivity를 import해야 한다.

즉, MainActivity가 없으면 DBHelper를 독립적으로 사용할 수 없다.

예제 코드 (Fragment에서 DBHelper 사용)

public class SomeFragment extends Fragment {
    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // MainActivity를 통해서만 DBHelper를 참조할 수 있음
        DBHelper dbHelper = MainActivity.mDBHelper;
        dbHelper.insertData(...);
    }
}

참고 구조 이미지 ▼

오르다 다이어리 레거시 리팩토링 전 모든 화면은 Activity였고 MainActivity에서 DBHelper를 import해서 사용했다. 그리고 리팩토링하여 Fragment로 바뀐 지금도 DBHelper를 MainActivity에서 import해서 사용하고 있는 상태인 것이다. (이전 이야기는 이전 포스팅을 참고하길 바란다.)

확장성을 고려하여 넓게 봤을 때의 문제점

독립적인 모듈(예: ViewModel)에서 DBHelper를 사용하려면 아래 그림처럼 MainActivity를 import해야 함.

테스트 코드 작성이 어려움 → MainActivity가 실행되지 않으면 DBHelper를 사용할 수 없음.
MainActivity가 종료되면 DBHelper도 사라질 위험이 있음.
- 아래의 그림처럼 mDBHelper를 가진 Activity가 destory된다면 이를 import 해서 쓰던 A, B, C는 오류가 발생할 것이다.

2️⃣ DBHelper가 여러 개 생성될 가능성

DBHelper는 오직 하나만 유지되어야 한다.

하지만, 기존 방식에서는 다른 사람이 DBHelper를 new DBHelper(context)로 직접 생성할 수도 있는 구조였다.

예제 코드 (ViewModel에서 DBHelper를 또 생성한 경우)

public class DiaryViewModel extends ViewModel {
    private DBHelper dbHelper;

    public DiaryViewModel(Application application) {
        super(application);
        dbHelper = new DBHelper(application);  // 새로운 DBHelper 인스턴스 생성!
    }

    public void insertDiary(...) {
        dbHelper.insertData(...);
    }
}

문제점

같은 DBHelper를 써야 하는데, 새로운 인스턴스가 여러 개 생성될 가능성이 있다.
메모리 낭비가 발생할 수 있음.
동일한 DB에 여러 개의 객체가 접근하면 데이터 동기화 문제가 발생할 가능성이 있음.

실제 발생한 상황

아래의 그림처럼 A, B는 Activity의 mDBHelper를 import하고 쓰고 있었는데, 어떤 사람이 mDBHelper를 C에서 새로 만들어서 DB에 접근한다고 생각하면 된다.
그리고 실제로 우측과 같이 수정 도중에 발견했는데, 팀원이 작성한 코드 중 일부에서 DBHelper를 생성하여 사용하고 있는 것이 확인되었다

✅ 해결 방법: DBHelper를 싱글톤 패턴으로 변경!

이제 DBHelper를 싱글톤 패턴(Singleton Pattern)으로 변경하여 하나의 인스턴스만 유지하고, 어디서든 같은 DBHelper를 사용할 수 있도록 개선하자.

잠깐, 싱글톤(Singleton) 패턴이란?

하나의 클래스에 대해 오직 하나의 객체만 생성되도록 보장하는 디자인 패턴.
모든 코드에서 같은 인스턴스를 공유하며 사용하므로, 메모리 절약 & 데이터 일관성 유지가 가능하다.
DBHelper 같은 객체는 여러 개 만들 필요 없이, 앱 전역에서 하나만 유지하면 되므로 싱글톤 패턴이 적합하다.

수정 후 코드 (싱글톤 적용)

public class DBHelper extends SQLiteOpenHelper {
    private static volatile DBHelper instance;  

    private DBHelper(Context context) {
        super(context.getApplicationContext(), DB_NAME, null, DB_VERSION);
    }

    public static DBHelper getInstance(Context context) {
        if (instance == null) {  // 첫 번째 체크 (동기화 불필요)
            synchronized (DBHelper.class) {
                if (instance == null) {  // 두 번째 체크 (동기화 블록 내 실행)
                    instance = new DBHelper(context);
                }
            }
        }
        return instance;
    }
}

왜 더블 체크 락킹(Double-Checked Locking)을 사용했을까?

현재 오르다 다이어리는 멀티 스레드가 아닌데?

처음에는 synchronized 키워드를 메서드 전체에 적용하려 했지만, 현재 오르다 다이어리는 따로 멀티 스레드를 만들어서 처리하고 있는 작업이 없기 때문에 동기화 작업이 매번 필요하지 않다.

public static synchronized DBHelper getInstance(Context context) {
    if (instance == null) {
        instance = new DBHelper(context);
    }
    return instance;
}

이렇게 synchronized 키워드를 메서드 전체에 적용하면 매번 getInstance()를 호출할 때마다 동기화가 발생하여 성능 저하 가능성이 있다고 판단했다.

그렇지만 확장성을 고려한다면?

그러나 추후 확장성을 고려했을 때 추가 스레드를 만들어 처리한다고 하면 synchronized가 필요하게 될 것이다.

고민 해결!

그래서 더블 체크 락킹을 통해 현재 상황에서 불필요한 synchronized 진입을 하지 않게 하면서 추가 스레드가 있을 때 동기화 처리는 되는 방식으로 구현했다. 더블 체크 락킹을 적용하여 불필요한 동기화를 최소화하고 성능을 최적화했다.

더블 체크 락킹의 장점

이미 인스턴스가 있으면 동기화 블록에 진입하지 않고 바로 반환하여 성능 최적화
멀티스레드 환경에서도 인스턴스가 여러 개 생성되지 않도록 보장
volatile 키워드 사용으로 CPU 캐시 일관성 유지

잠깐, synchronized 키워드?

synchronized는 멀티스레드 환경에서 한 번에 하나의 스레드만 특정 코드 블록을 실행하도록 보장하는 키워드이다.
즉, 공유 자원(예: DBHelper 인스턴스)에 여러 스레드가 동시에 접근하는 것을 막고, 데이터 정합성을 보장한다. JVM 내부적으로 모니터 락을 요청하는 등의 작업이 이루어진다. 스레드가 락을 얻고 반환한느 과정이 포함된다는 것이다.
싱글톤 패턴에서 synchronized를 사용하는 이유?→ 여러 개의 스레드가 동시에 getInstance()를 호출할 경우, 여러 개의 객체가 생성되는 문제를 방지하기 위해 사용한다.

잠깐, volatile 키워드?

volatile 키워드는 CPU 캐시와 메인 메모리 간의 일관성을 보장하는 키워드이다.
멀티스레드 환경에서 한 스레드가 변수 값을 변경하면, 다른 스레드에서도 즉시 변경된 값을 볼 수 있도록 보장한다.
싱글톤 패턴에서 인스턴스 변수를 volatile로 선언하는 이유?→ 더블 체크 락킹(Double-Checked Locking)에서 CPU 캐시 최적화로 인해 발생하는 인스턴스 초기화 순서 문제를 방지하기 위함.

싱글톤 적용 후 개선된 점

문제	기존 코드 (MainActivity에서 관리)	개선 코드 (싱글톤 적용)
MainActivity 의존성	`MainActivity.mDBHelper` 필요	❌ `MainActivity` 없이 `DBHelper.getInstance(context)` 사용 가능
여러 개의 인스턴스 생성 가능성	가능 (new DBHelper() 가능)	❌ 하나의 인스턴스만 존재
테스트 코드 작성	MainActivity 없으면 불가능	✅ MainActivity 없이 독립적으로 사용 가능
메모리 낭비	여러 개의 DBHelper 인스턴스 생성 가능	✅ 싱글톤 적용으로 메모리 절약

결론

기존 코드에서는 DBHelper를 MainActivity에서 관리하며 static으로 선언, 모든 곳에서 MainActivity.mDBHelper를 사용해야 했다.
이로 인해 의존성이 강해지고, 여러 개의 DBHelper 인스턴스가 생성되는 등의 문제가 발생했다.
싱글톤 패턴을 적용하여 DBHelper.getInstance(context) 방식으로 변경함으로써 의존성을 줄이고, 인스턴스를 하나만 유지하도록 개선했다.

✍️ 현재 구조 도식화

✅ DBHelper를 싱글톤 패턴으로 변경하여 MainActivity 의존성을 제거하고, 어디서든 같은 인스턴스를 사용 가능하도록 개선

✅ 더블 체크 락킹을 적용하여 불필요한 동기화 호출을 최소화하고 성능을 최적화

✅ 이제 DBHelper가 중복 생성되지 않으며, 모든 코드에서 DBHelper.getInstance(context)를 통해 하나의 객체만 유지됨

참고: Kotlin에서 싱글톤 패턴 적용하는 방법

현재 오르다 다이어리는 Java로 작성되어 리팩토링도 Java 코드 그대로 수정하고 있다. 최근 진행했던 Nature Album 프로젝트는 Kotlin 기반이었는데, Kotlin에서의 싱글톤 패턴 구현 방법도 간단히 적어두고자 한다. Kotlin에서는 object를 활용하면 기본적으로 안전한 싱글톤을 쉽게 구현할 수 있으며, 필요한 경우 companion object와 lazy 초기화를 활용하면 된다. companion object는 주로 java랑 호환을 중요시 한다면 사용하고, Kotlin에서는 object를 사용하는 것을 권장한다.
object 키워드는 클래스를 인스턴스화하지 않고 즉시 싱글톤 객체를 생성한다. JVM 레벨에서 자동으로 스레드 안전(Thread-Safe)하게 관리되므로, synchronized 또는 volatile을 사용할 필요가 없다.

☺️ 후기

3년 전, 우리는 DBHelper를 하나만 만들고 공유해서 쓰고 싶었다.
그런데 시간이 지나고 보니, 우리가 했던 고민이 싱글톤 패턴과 맞닿아 있었던 것 같다.
그리고 이번 리팩토링을 통해 왜 싱글톤 패턴이 필요한지, 어떻게 동작하는지를 확실하게 이해할 수 있었다.

싱글톤 패턴을 확실하게 알고 넘어갈 수 있는 리팩토링이었다.
과거 3년 전 그때는 싱글톤 패턴도 몰랐는데 우리가 하나의 객체만 만들고 접근해서 사용하려고 했던 것이 싱글톤 패턴과 유사한 것 같아 기분이 묘하다. 그러면서 동시에 왜 싱글톤 패턴이 만들어졌고 이를 위해 멀티 스레드가 동시에 만들려고 했을 때의 처리 등도 고려해야 한다는 것을 확실하게 알게 되었다.
Kotlin 기반 프로젝트를 진행할 때는 object를 사용하다 보니 Thread-Safe까지는 직접 고려할 필요가 없었는데 이번 기회에 고려할 수 있게 되어서 좋았다.

[Android/오르다 다이어리] 레거시 리팩토링 05 - Configuration Change 대응 (ViewModel 적용)

yujinius — Sat, 1 Mar 2025 19:12:53 +0900

[Android/오르다 다이어리] 레거시 리팩토링 05 - Configuration Change 대응 (ViewModel 적용)

지난 글: https://yujinius45.tistory.com/159

[Android/오르다 다이어리] 레거시 리팩토링 04 - Fragment 마이그레이션

[Android/오르다 다이어리] 레거시 리팩토링 04 - Fragment 마이그레이션지난 글: https://yujinius45.tistory.com/158 [Android/오르다 다이어리] 레거시 리팩토링 03 - Navigation Component 적용[Android/오르다 다이어리]

yujinius45.tistory.com

지난번에 Activity에서 Fragment로 전환하는 마이그레이션 작업을 진행했다. 이를 통해 화면 이동이 불편했던 문제를 해결하고, 네비게이션 바를 추가하여 더 나은 UX를 제공할 수 있었다. 하지만 이 과정에서 새로운 문제들이 발견되었다.

이번 글에서는 Fragment 마이그레이션 후 발견한 문제점(일기 작성 페이지 Configuration change 대응 문제 등)과 이를 해결하기 위해 ViewModel을 적용한 과정을 정리해보고자 한다.

✨ Fragment 마이그레이션 후 느낀 점 정리

지난 리팩토링 작업을 통해 여러 가지 이슈를 발견했다. 그중에서도 가장 크게 불편함으로 느낀점은 UI와 로직이 분리되지 않은 점과 DB 관련 버그가 존재한 점이었다. 각각의 문제를 분석하고, 개선 방안을 찾아보았다.

1. UI와 로직이 분리되지 않아 관련 수정에서 시간이 오래 걸림(유지보수성 떨어짐)

기존 Activity 기반 코드에서는 UI와 데이터 처리 로직이 뒤섞여 있었기 때문에 Fragment로 이동할 때 많은 코드 수정이 필요했다.

UI를 Fragment로 옮기면서, 데이터 로직도 함께 이동해야 해서 불필요한 코드 이동이 많았고, 시간이 오래 걸려 유지보수성이 낮다고 느낌

만약 UI와 로직을 분리했다면 UI만 이동하면 되므로 변경 작업이 훨씬 간결했을 것

오르다 다이어리 같은 경우는 해당되지 않지만, 더 큰 규모의 프로젝트에서 여러 view를 재사용한다면 View와 로직이 분리되지 않으면 재사용성이 떨어지고, 다른 곳에서 동일한 로직을 사용하고 싶을 때 중복 코드가 발생

➡️ 이를 해결하기 위해 ViewModel을 도입하여 UI와 로직을 분리하기로 결정했다. 현재는 Configuration Change 대응이 필요한 일기 작성 페이지에만 ViewModel을 적용하고, 다른 페이지들은 기존 방식으로 상태가 유지되므로 그대로 두었다.

2. DB 관련 SQL 쿼리 문제

기존 SQLite 코드에서 UPDATE가 날짜(writeDate)를 기준으로 이루어지는 문제가 있었다. 이로 인해 데이터가 꼬이는 문제가 발생했다.

해결책: ID를 기준으로 업데이트하도록 수정

하지만 SQL 직접 작성 방식이 유지보수하기 어려웠음 (최근에 진행한 프로젝트에서는 RoomDB를 사용했는데, 이를 다시 보니 가독성이 많이 떨어지는 것이 느껴짐)

➡️ SQLite 유지 vs RoomDB 마이그레이션 여부를 검토하기 위해 이후 테스트 코드 작성을 진행해볼지 고려중이다.

그래서 다시 본론으로 돌아와서, 오늘 진행할 내용을 아래에 정리하고자 한다.

지난번 Fragment 전환 과정에서 일기장 작성 페이지의 Configuration Change 대응이 필요하다는 걸 알게 되었고, 이를 해결하기 위해 이번 리팩토링을 진행했다

️ Configuration Change 문제 분석

오르다 다이어리는 Activity 기반일 때부터 Configuration Change(화면 회전 등)에 어느 정도 대응이 되어 있었다. (과거의 우리 팀 기특하다! )

그 이유는?

기존 Activity 구조에서는 onCreate()가 실행될 때마다 DB에서 데이터를 다시 불러오는 방식을 사용했다.

➡️ 따라서 Fragment에서도 onViewCreated()에서 DB를 다시 로드하여 데이터가 대부분 유지됨

하지만! 예외적인 경우가 있었는데, 일기 쓰기 페이지에서 이미지 상태가 유지되지 않는 문제가 발생했다.

일기 쓰기 페이지에서 이미지 상태 유지 문제

▼ Configuration change 대응 안되는 모습 (사진 부분 참고)

사용자가 일기 작성 도중 이미지를 추가하고 화면을 회전, 다크 모드 변경 등을 하면 이미지가 사라짐
기존 방식에서는 DB에서 다시 불러오기 때문에 유지됨, 하지만 일기 작성 도중의 데이터(입력 내용, 이미지)는 DB에 저장되지 않음
즉, Configuration Change가 발생하면 Fragment가 재생성되면서 imageUri가 초기화되는 문제가 발생

➡️ 이를 해결하기 위해 ViewModel을 도입하여 데이터 상태를 유지하는 방식으로 개선하기로 결정했다.

Configuration Change 해결 방법

Configuration Change(예: 화면 회전, 다크 모드 변경 등) 발생 시 데이터를 유지하는 방법에는 두 가지 방법이 있다.

`onSaveInstanceState()` 활용

✔️ 원리

onSaveInstanceState()는 Activity/Fragment가 소멸될 때 데이터를 Bundle에 저장하고, 이후 Bundle을 통해 데이터를 복원하는 방식
간단한 UI 상태(텍스트, 숫자, Boolean 등)를 저장하는 용도로 사용됨

❌ 단점

https://developer.android.com/topic/libraries/architecture/saving-states#viewmodel
Don't use saved instance state to store large amounts of data, such as bitmaps, nor complex data structures that require lengthy serialization or deserialization. Instead, store only primitive types and simple, small objects such as String.

Data limitations : only for primitive types and simple, small objects such as String

크기 제한이 있어서 Bitmap, Uri 같은 대용량 데이터 저장 불가능

Read/write time: slow (requires serialization/deserialization)

데이터가 많아질수록 Bundle을 파싱하는 과정이 성능 저하를 일으킬 수 있음.

➡️ 텍스트, 체크박스 상태 등 간단한 UI 상태 저장에는 적합하지만, 이미지 상태 유지에는 적절하지 않음. 물론 uri만 저장시키면 되지만 일기 저장 로직도 분리할 예정이기에 viewmodel 선택.

ViewModel 활용 (선택한 방법)

https://developer.android.com/topic/libraries/architecture/saving-states#viewmodel

Use ViewModel to handle configuration changes

ViewModel is ideal for storing and managing UI-related data while the user is actively using the application.

✔️ 원리

ViewModel은 Configuration Change 시에도 유지되는 객체
Fragment가 소멸되더라도, Activity가 살아 있는 동안 ViewModel은 유지됨
LiveData를 함께 사용하면 자동으로 UI 업데이트 가능

✅ 장점

Configuration Change 후에도 자동으로 데이터 유지됨
Fragment가 여러 번 생성되더라도 같은 ViewModel을 공유 가능
LiveData와 함께 사용하면 UI 자동 갱신 가능

➡️ 이미지 상태 유지, UI와 로직 분리를 위해 ViewModel을 활용하기로 결정

☺️ 적용 결과 및 후기

1. Configuration Change 대응 강화

화면 회전, 다크 모드 변경 후에도 입력 데이터와 이미지 상태가 유지됨

2. UI와 비즈니스 로직 분리

UI는 Fragment에서 관리하고, 데이터 처리는 ViewModel에서 수행하여 코드 구조가 더 명확해짐
아래 이미지와 같이 UI의 데이터를 가져와 유효값인지 체크하고 일기장 저장을 하던 로직을 ViewModel로 이전하여 UI는 저장 됐는지만 체크하고 토스트 메세지 출력.

3. DataBinding 및 LiveData 활용

DataBinding을 적용하여 UI와 ViewModel 데이터를 직접 연결
데이터 변경 시 UI에서 setText() 등을 명시적으로 호출할 필요 없어서 편리했음.

4. MVVM 패턴 적용 후 개선된 점

setText() 등의 과정이 없어서 코드가 깔끔해짐.
LiveData를 활용하여 UI가 자동으로 업데이트되도록 구성
하지만 현재 작업에서는 ViewModel이 단순 데이터 저장소 역할만 하고 있음

➡️ 현재는 일기 작성 페이지에서만 ViewModel을 적용했고, 다른 페이지들은 기존 방식으로도 상태가 유지되므로 그대로 두었다. 추후 더 복잡한 기능이 추가될 경우 ViewModel 활용도를 높일 계획이다.

이제 다크 모드로 변경해도 작성하던 것 사라지지 않는다!!

▼ Configuration change 대응 되는 모습

[Android/오르다 다이어리] 레거시 리팩토링 04 - Fragment 마이그레이션

yujinius — Mon, 24 Feb 2025 23:56:01 +0900

[Android/오르다 다이어리] 레거시 리팩토링 04 - Fragment 마이그레이션

지난 글: https://yujinius45.tistory.com/158

[Android/오르다 다이어리] 레거시 리팩토링 03 - Navigation Component 적용

[Android/오르다 다이어리] 레거시 리팩토링 03 - Navigation Component 적용이전 글: https://yujinius45.tistory.com/156 [Android/오르다 다이어리] 레거시 리팩토링 02 - targetSdk 34 적용 이슈와 해결보호되어 있는 글

yujinius45.tistory.com

지난 번 오르다 다이어리 앱의 메뉴 이동 과정이 불편하여 Navigation을 도입해 사용자 경험을 향상시켰다. 그리고 이제 기존 Activity 중심 구조에서 Fragment로 전환하는 작업이 필요해지게 되었다. 오늘은 그 기나 긴 여정을 보내며 남겨둔 기록을 정리해두려고 한다.

1. 패키지 구조 변경

기존의 Activity 중심 구조에서 Fragment 중심으로 전환하면서, 패키지 구조를 보다 체계적으로 정리했다.
이전에는 모든 UI 관련 클래스가 한 패키지에 섞여 있었다. 이번에 다시 코드를 수정하다 보니, 파일을 찾아 가는 데에 불편함이 있어 각 기능별로 폴더를 나누어 가독성을 높였다.

아래와 같이 변경되었다.

2. Activity에서 Fragment로 전환

지난번 Navigation Component를 적용했지만, 아직 모든 Activity를 Fragment로 전환하지 않은 상태였다. 이번 작업에서는 실제 기능을 하는 모든 Activity를 Fragment로 전환하는 작업을 진행했다.

이 과정은 예상보다 시간이 오래 걸렸다. Fragment로 바꾸면서 기존 Activity에서 쉽게 처리하던 기능들이 Fragment 환경에서는 다르게 동작하기 때문에 여러 이슈가 발생했다.

Activity → Fragment 전환 시 주의할 점

Activity에서는 Intent를 사용하여 데이터를 전달하지만, Fragment에서는 Bundle 또는 Safe Args를 활용해야 한다. & Fragment에서 데이터를 다른 Fragment로 전달할 때 Safe Args를 사용할 수 있다.
- 처음에는 Activity 간 데이터 전달에서 Intent를 사용했었다.
- Fragment에서는 Intent를 사용할 수 없기 때문에 Bundle을 활용해야 한다는 것을 알게 되었고, 따라서 putSerializable()을 사용하여 데이터를 전달하는 방식으로 변경했었다.
- Bundle을 사용하고 null 체크를 확인해주는 작업을 해주었는데, Safe Args를 사용하면 아래와 같은 장점이 있다는 것을 알게 되었다.
  - 타입 안전성 보장 → OnePageDiary를 넘기기로 설정했으면, 다른 타입을 넘길 수 없음.
  - 컴파일 타임 오류 방지 → key값을 잘못 쓰거나 타입이 다르면 컴파일 시점에 오류를 잡아줌.
  - 더 간결한 코드 → Bundle을 따로 만들 필요가 없음.
- ✅ Safe Args의 장점
- 그래서 Navigation Component에서 제공하는 Safe Args 기능을 활용하기로 했다.
Fragment에서 getSupportFragmentManager()가 아니라 getChildFragmentManager()를 써야 할 때가 있다.
- Fragment 내에서 다른 Fragment를 다룰 때는 getChildFragmentManager()를 사용해야 했다.
- Fragment 내부에서 또 다른 Fragment(SupportMapFragment)를 다룰 때, 기존의 getSupportFragmentManager()를 사용하면 런타임 오류가 발생한다.

3. 데이터 전달 방식 변경 (Intent → Bundle → Safe Args 적용)

처음에는 Fragment 간 데이터 전달을 위해 Bundle을 사용했지만, Navigation Component에서 Safe Args를 제공하는 것을 알게 되었다. Safe Args는 타입 안정성을 보장하고, key 값을 직접 관리할 필요가 없어 코드의 유지보수성이 더 높아지는 장점이 있다.

Activity에서 데이터 전달 방식 (기존 방식)

기존에는 Intent를 사용하여 데이터를 전달했다.

기존 코드 (Activity 간 데이터 전달)

Intent intent = new Intent(myViewHolder.itemView.getContext(), DiarySelectedActivity.class);
intent.putExtra("selectedDiary", dataModels.get(position));
ContextCompat.startActivity(myViewHolder.itemView.getContext(), intent, null);

Activity에서 데이터 받기

Intent intent = getIntent();
selectedDiary = (OnePageDiary) intent.getSerializableExtra("selectedDiary");

➡️ 문제점: Activity에서 Fragment로 전환할 때 Intent를 사용할 수 없기 때문에, 새로운 데이터 전달 방식이 필요했다.

Fragment에서 데이터 전달 방식 (Bundle 적용 후 Safe Args로 개선)

처음에는 Bundle을 사용하여 데이터를 전달했다.

Fragment 간 데이터 전달 (Bundle 방식)

Bundle bundle = new Bundle();
bundle.putSerializable("selectedDiary", diary);
Navigation.findNavController(v).navigate(R.id.action_diaryListFragment_to_diarySelectedFragment, bundle);

Fragment에서 데이터 받기 (Bundle 방식)

if (getArguments() != null) {
    selectedDiary = (OnePageDiary) getArguments().getSerializable("selectedDiary");
}

➡️ 문제점: Bundle을 사용하면 key-value 형식으로 데이터를 전달해야 하며, 타입 안전성이 보장되지 않는다. 또한 key 관리도 필요하다.

Safe Args 적용 (최종 개선)

Navigation Component에서는 Safe Args를 제공하여 타입 안전한 데이터 전달을 보장한다.

Safe Args 적용 코드 (nav_graph.xml 수정)

<fragment
    android:id="@+id/diarySelectedFragment"
    android:name="smu.team3_orda_diary.ui.diary.DiarySelectedFragment"
    android:label="Diary Selected">
    <argument
        android:name="selectedDiary"
        app:argType="smu.team3_orda_diary.model.OnePageDiary" />
</fragment>

Fragment 간 데이터 전달 (Safe Args 적용)

DiaryListFragmentDirections.ActionDiaryListFragmentToDiarySelectedFragment action =
        DiaryListFragmentDirections.actionDiaryListFragmentToDiarySelectedFragment(diary);
Navigation.findNavController(v).navigate(action);

Fragment에서 데이터 받기 (Safe Args 적용)

DiarySelectedFragmentArgs args = DiarySelectedFragmentArgs.fromBundle(getArguments());
selectedDiary = args.getSelectedDiary();

➡️ Safe Args 적용 후 개선점

타입 안전성 보장 (컴파일 시점에서 타입 검증 가능)
Key 값 없이 직관적인 메서드 호출로 데이터 전달 가능
Nullable / Non-nullable 자동 처리 → selectedDiary는 Non-nullable 타입이므로 null 체크가 필요 없음

➡️ 따라서 if (selectedDiary != null) 체크를 하지 않아도 경고가 발생하지 않음.

4. XML 및 리소스 정리

모든 하드코딩된 문자열을 strings.xml로 이동시켰다.
UI 대응을 위해 ConstraintLayout을 적용하여 다양한 화면 크기에 적절히 대응할 수 있도록 변경했다.

5. Fragment 내에서 Fragment 사용 시 주의점 (`getChildFragmentManager()` 활용) 관련 추가 사항

Fragment 내부에서 또 다른 Fragment(SupportMapFragment)를 다룰 때, 기존의 getSupportFragmentManager()를 사용하면 런타임 오류가 발생한다.

문제 상황
기존에는 getSupportFragmentManager()를 사용하여 SupportMapFragment를 추가하려고 했으나, Fragment 내부에서 Fragment를 추가할 경우 getChildFragmentManager()를 사용해야 한다는 점을 간과했다. Activity 내에서 Map이 어떻게 사용되고 있는지를 먼저 체크하지 않은 탓이었다.

수정 전 (잘못된 코드)

SupportMapFragment mapFragment = new SupportMapFragment();
getSupportFragmentManager().beginTransaction()
        .replace(R.id.map_container, mapFragment)
        .commit(); // ❌ 오류 발생

수정 후 (정상 작동 코드)

SupportMapFragment mapFragment = new SupportMapFragment();
getChildFragmentManager().beginTransaction()
        .replace(R.id.map_container, mapFragment)
        .commit(); // ✅ 정상 동작

➡️ getChildFragmentManager()를 사용해야 하는 이유

getSupportFragmentManager()는 Activity에 속한 Fragment 관리자를 가져오는 것이기 때문에 Fragment 내부에서 새로운 Fragment를 추가하는 경우에는 사용하면 안 된다.
getChildFragmentManager()를 사용하면 현재 Fragment 내부에서 새로운 Fragment를 관리할 수 있다.

6. 가장 어려웠던 작업: 일기장 관련 변경

Fragment로 전환하는 과정에서 가장 어려웠던 부분은 일기장 관련 화면이었다. 특히 포토피커(Photo Picker)의 동작 방식에 대한 오해가 큰 문제였다.

✅ 포토피커(Photo Picker)란?
Android의 Photo Picker API는 사용자가 갤러리에서 이미지를 선택할 수 있도록 돕는 기능이다.
하지만, 선택된 이미지는 임시 URI로 제공되며, 개발자가 직접 이를 저장하거나 사용해야 한다.

잘못된 예상

처음에는 Photo Picker에서 선택한 이미지가 자동으로 DB에 저장될 것이라고 착각했다. 기존 Media를 선택하고 저장하는 로직이 이미 있었기에 그 부분만 Photo Picker로 변경하면 저장될 것이라 생각해버린 것이었다. 하지만 실제로는 앱에서 URI를 활용하여 별도로 저장해야 했다.

해결 방법

Photo Picker에서 선택한 이미지의 URI를 DB에 저장하는 방식으로 변경
URI가 만료되지 않도록 앱 내부 저장소에 이미지를 복사하여 보관 및 참조하여 해당 이미지 표시 (갤러리에서 삭제되더라도 앱 내부 저장소에 저장된 이미지가 유지되도록 함)

7. 할 일 목록(DB) 수정 로직 개선 (버그 수정)

문제 발생 원인

할 일 목록 수정 기능을 테스트하는 과정에서, 같은 날짜에 여러 개의 할 일을 추가한 후 하나를 수정하면 모든 아이템이 동일하게 변경되는 버그를 발견했다.
이는 기존 updateTodo()가 WHERE writeDate = '기존 Date'로 조건을 걸고 수정했기 때문이다.

해결 방법

기존 방식에서는 WHERE writeDate=?로 쿼리를 실행하여, 같은 날짜에 존재하는 모든 할 일이 동시에 변경되는 문제가 발생했다. 이를 해결하기 위해 각 할 일 항목이 고유한 ID(id)를 가지도록 설계하고, WHERE id=?로 변경하여 특정 아이템만 수정할 수 있도록 개선했다.

ID 기반 업데이트로 변경 (writeDate 대신 id 사용)
- 기존: UPDATE TODOLIST_TB SET title=?, content=?, writeDate=? WHERE writeDate=?
- 변경: UPDATE TODOLIST_TB SET title=?, content=?, writeDate=? WHERE id=?

이제 각 할 일 항목이 고유한 ID를 기준으로 업데이트되도록 수정하여, 같은 날짜에 여러 개의 할 일이 있을 경우에도 개별적으로 수정할 수 있게 되었다.

8. 결론

이번 작업을 통해 Activity를 Fragment로 전환하고, Navigation Component와 Safe Args를 활용하는 구조로 변경했다. Activity에서 사용하던 데이터 전달 방식을 Intent → Bundle → Safe Args 순으로 개선하며, 타입 안전성과 유지보수성을 높였다. 특히 Safe Args를 적용하면서 null 체크가 필요 없는 구조로 변경되었으며, Fragment 간 데이터 전달이 더욱 명확하고 안전하게 이루어질 수 있도록 개선했다. 또한, 할 일 목록의 데이터 수정 오류를 해결하여, 같은 날짜의 모든 할 일이 동시에 변경되는 문제를 방지했다.

마지막으로, 알람 관련 RingingAlarmActivity는 Fragment로 변경하지 않고 유지했다. 알람이 울릴 때는 사용자의 인터랙션이 흔들기로 제한되어 독립적인 화면이 필요하며, Navigation Component와의 연관성이 낮아 별도의 Activity로 유지하는 것이 적절했기 때문이다.

이번 리팩토링을 통해 코드 구조가 단순해지고, 유지보수성이 향상되었으며, UI/UX 측면에서도 개선된 사용자 경험을 제공할 수 있게 되었다.

▼ 변경된 구조

이제 홈 화면을 들렸다가 다른 곳으로 이동하지 않아도 된다!

아래 영상과 같이 Navigation을 통해 메뉴를 빠르게 이동할 수 있어서 사용자 경험이 개선되었다.

[Android/오르다 다이어리] 레거시 리팩토링 03 - Navigation Component 적용

yujinius — Thu, 20 Feb 2025 00:39:22 +0900

[Android/오르다 다이어리] 레거시 리팩토링 03 - Navigation Component 적용

이전 글: https://yujinius45.tistory.com/156

[Android/오르다 다이어리] 레거시 리팩토링 02 - targetSdk 34 적용 이슈와 해결

보호되어 있는 글입니다. 내용을 보시려면 비밀번호를 입력하세요.

yujinius45.tistory.com

✅ SDK 업그레이드 관련 간단 정보 (이전 글 요약)

지난 글에서 오르다 다이어리의 targetSdkVersion을 업그레이드하면서 권한 설정을 수정했다.

당시 필요한 변경 사항을 직접 찾아 적용했는데, 최근 Android Studio에서 제공하는 SDK Upgrade Assistant라는 기능이 있다는 것을 알게 되었다.

✅ SDK Upgrade Assistant란?

Android Studio의 도구 중 하나로, 버전 업그레이드 시 필요한 변경 사항을 자동으로 분석하고 가이드해준다.

targetSdkVersion을 변경하면 API 변경점, 권한 정책 변경, 비호환 요소 등을 체크할 수 있어, 업그레이드 시 놓치기 쉬운 부분을 쉽게 보완할 수 있다.

결론: 다음 SDK 업그레이드 시에는 이 도구를 적극 활용하면 더 편리할 듯하다.

▼ 아래처럼 되어 있다.

SDK 업그레이드는 이미 직접 적용한 상태이므로, 이번 작업에서는 기존 Activity 기반 네비게이션을 Fragment 기반으로 전환하는 과정에 집중한다

오르다 다이어리의 레거시 코드를 리팩토링하면서 가장 먼저 해결해야 할 문제로 화면 구성과 데이터 관리 방식 개선을 뽑았다.

오르다 다이어리의 기존 화면 구조는 모든 기능이 개별 Activity로 구성되어 있으며, 화면 간 이동은 Intent를 통해 이루어졌다.

이 방식은 화면 이동이 직관적이지 않고, Activity 간 전환 비용이 발생하며, UI 상태 관리가 어렵다는 단점이 있었다.

이 문제를 해결하기 위해 하나의 MainActivity에서 여러 개의 Fragment를 관리하는 구조로 변경하고, Navigation Component와 BottomNavigationView를 적용하여 Fragment 간 전환을 간편하게 만들고자 한다.

기존 오르다 다이어리의 화면 구조와 문제점

기존 화면 구조

기존 구조의 문제점

✅ 화면 이동의 불편함

현재 사용자는 메인 화면에서 버튼을 눌러 특정 화면으로 이동할 수 있지만, 다른 화면으로 이동하려면 항상 백 버튼을 눌러 MainActivity로 돌아와서 다시 다른 버튼을 눌러야 한다.
즉, 일정 화면에서 일기 화면으로 바로 이동할 수 없고, 항상 MainActivity를 거쳐야 하는 구조다.

✅ UI 상태 관리 부족

일부 화면의 UI 상태가 유지되지 않는다.
Configuration Change(예: 화면 회전) 발생 시 앱이 종료되거나, 데이터가 초기화되는 문제가 있다.

✅ Activity 개수가 많아 성능 저하 우려

각 화면이 독립적인 Activity로 이루어져 있어, 화면 전환 시 메모리 사용량이 증가한다.
사용자가 여러 화면을 빠르게 전환하면 불필요한 Activity가 누적되어 앱 성능에 영향을 미칠 수 있다.

✅ 비효율적인 사용자 경험(UI/UX)

한 화면에서 다른 화면으로 바로 이동하는 기능이 부족하여, 사용자가 불편함을 느낀다.
네비게이션 바와 같은 직관적인 전환 기능이 없어 앱 사용 경험이 비효율적이다.

해결 방법: Single Activity + Multi Fragment 구조로 전환

기존 구조의 문제를 해결하기 위해, 하단 네비게이션 바(Bottom Navigation Bar)를 도입하여 사용자들이 더욱 직관적으로 화면을 전환할 수 있도록 개선하기로 했다.
이를 위해 각 Activity를 Fragment로 변경하고, Navigation Component를 활용하여 Fragment 전환을 관리하도록 구조를 변경하고자 한다.

리팩토링 후 새로운 화면 구조

✅ 하단 네비게이션 바 추가 → 빠른 화면 전환 가능으로 사용자 경험 개선

✅ Fragment 전환 방식 사용 → Activity 생성 부담 감소

✅ ViewModel을 활용한 UI 상태 유지 가능 (추후 적용 예정)

Navigation Component 적용 과정

1️⃣ `nav_graph.xml` 생성 및 Fragment 등록

Navigation Component를 사용하기 위해 nav_graph.xml을 생성하고, 기존 Activity를 Fragment로 등록했다.

적용된 코드 (nav_graph.xml)

<navigation xmlns:android="http://schemas.android.com/apk/res/android"
    app:startDestination="@id/homeFragment">

    <fragment
        android:id="@+id/homeFragment"
        android:name="smu.team3_orda_diary.HomeFragment"
        android:label="Home" />

    <fragment
        android:id="@+id/todolistFragment"
        android:name="smu.team3_orda_diary.ToDoListFragment"
        android:label="Todolist" />

    <fragment
        android:id="@+id/mapMemoFragment"
        android:name="smu.team3_orda_diary.MapMemoFragment"
        android:label="Map Memo" />

    <fragment
        android:id="@+id/diaryListFragment"
        android:name="smu.team3_orda_diary.DiaryListFragment"
        android:label="Diary List" />

    <fragment
        android:id="@+id/alarmFragment"
        android:name="smu.team3_orda_diary.AlarmFragment"
        android:label="Alarm" />
</navigation>

✅ BottomNavigationView와 연결하여 클릭 시 자동으로 Fragment 이동이 가능하게 만들었다.

2️⃣ BottomNavigationView 추가 및 Navigation 연동

기존 Activity 간 이동 버튼을 제거하고, BottomNavigationView를 사용해 Fragment 전환을 자동화했다.
메뉴 ID와 Fragment ID를 일치시키는 것이 중요하다. (초기에 ID 불일치 문제로 오류가 발생했다.)

Navigation Component 설정 실수로 발생한 오류 해결기

프로젝트에서 BottomNavigationView와 Navigation Component를 연동하는 과정에서, bottom_nav_menu.xml의 메뉴 ID와 nav_graph.xml의 Fragment ID가 일치하지 않아 NavigationUI가 목적지를 찾지 못하는 오류가 발생했다.
오류 메시지를 분석한 결과, menu의 ID(nav_home, nav_schedule 등)와 nav_graph.xml에서 해당 Fragment의 ID(homeFragment, todolistFragment 등)가 불일치한 것이 원인이었다. 이를 해결하기 위해 모든 메뉴 ID를 Fragment ID와 동일하게 통일하였고, 이후 NavigationUI가 정상적으로 목적지를 찾으며 오류 없이 BottomNavigationView를 통한 Fragment 전환이 원활하게 이루어졌다. 오랜만에 xml으로 돌아오다 보니 이름 맞추는 것을 망각하고 있었다.

▲ 위의 캡쳐처럼 id를 동일하게 설정해야 하는 것! 잊지말자!!!!

수정된 bottom_nav_menu.xml

<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item
        android:id="@+id/homeFragment"
        android:icon="@drawable/ic_home_24dp"
        android:title="홈" />

    <item
        android:id="@+id/todolistFragment"
        android:icon="@drawable/ic_today_24dp"
        android:title="일정관리" />

    <item
        android:id="@+id/mapMemoFragment"
        android:icon="@drawable/ic_location_on_24dp"
        android:title="지도 메모" />

    <item
        android:id="@+id/diaryListFragment"
        android:icon="@drawable/ic_feed_24dp"
        android:title="일기장" />

    <item
        android:id="@+id/alarmFragment"
        android:icon="@drawable/ic_alarm_24dp"
        android:title="알람" />
</menu>

✅ Navigation Component와 BottomNavigationView를 연동하여 Fragment 전환을 자동화했다.

3️⃣ MainActivity 수정 (`findNavController()` 오류 해결)

초기에 findNavController(this, R.id.fragmentContainer) 호출 시 NavController가 설정되지 않아 IllegalStateException 오류가 발생했다.

이를 해결하기 위해 NavHostFragment에서 직접 NavController를 가져오는 방식으로 수정했다.

수정된 MainActivity.java

NavHostFragment navHostFragment = (NavHostFragment) getSupportFragmentManager()
        .findFragmentById(R.id.fragmentContainer);
if (navHostFragment != null) {
    navController = navHostFragment.getNavController();
}
NavigationUI.setupWithNavController(binding.bottomNavigation, navController);

✅ findNavController()를 안전하게 호출하도록 변경했다.

현재 상태 & 다음 작업

✔ Fragment 전환이 정상적으로 동작하는 것까지 확인했다.

마무리

이번 작업을 통해 BottomNavigationView + Navigation Component를 활용하여 Fragment 기반 네비게이션 구조를 적용했다.

기존 Activity 간 이동 방식에서 Fragment 전환 방식으로 변경하면서 nav_graph 등을 활용해 코드가 깔끔해졌다.

이후 작업에서는 기존 Activity의 UI와 기능을 Fragment로 이동하며, 필요에 따라 ViewModel을 활용한 데이터 관리도 적용할 계획이다.

다음 목표: 기존 Activity의 UI 및 기능을 각각 Fragment로 마이그레이션하기!

[Android/오르다 다이어리] 레거시 리팩토링 02 - targetSdk 34 적용 이슈와 해결

yujinius — Tue, 11 Feb 2025 20:57:04 +0900

오르다 다이어리 레거시 리팩토링 02 - targetSdk 34 적용 이슈와 해결

최근 3년 전 개발한 레거시 프로젝트를 리팩토링하면서 targetSdkVersion을 32에서 34로 변경해야 하는 상황에 직면했다.

왜 Target SDK를 34로 올려야 했을까?

처음에는 targetSdkVersion 32로 유지하면서 UI 상태 관리 및 아키텍처 리팩토링을 진행하려 했으나, 아래와 같은 고민이 있었다.

Google Play에 출시해보고 싶어질 수도 있고
최신 Android 보안 정책을 반영해야 하며
다른 라이브러리 사용할 때의 확장성을 고려해야 했기 때문
또한, 현재 사용자인 나의 핸드폰이 Anroid 14ㅇ이다.

결과적으로 최신 정책을 준수하는 것이 장기적으로 유지보수와 배포를 고려했을 때 더 나은 선택이라 판단했다.

그러나 targetSdk를 34로 변경하자마자 Android Studio에서 다양한 권한 정책 변경과 보안 강화로 인해 일부 기능이 정상 동작하지 않음을 알리는 경고 메시지가 발생했다.

Configuration Change만 안되던 모든 기능들이 삐그덕 거리며 정상 동작하지 않기 시작했다.

오르다 다이어리는 내 프로젝트 중에서도 가장 다양한 권한을 요청하는 앱이었기에, 이를 해결하기 위해 SDK 버전별 정책을 하나하나 살펴보는 과정이 필요했다.

targetSdkVersion이란?

targetSdkVersion은 Android 시스템이 앱을 실행할 때 어떤 버전의 동작 방식을 따를지를 결정하는 값이다.

새로운 Android 버전이 출시되면서, 보안과 성능 향상을 위한 변경 사항이 추가되며, targetSdkVersion이 낮으면 최신 기능을 사용할 수 없거나 새로운 정책이 적용되지 않는다.

즉, 최신 SDK 버전으로 올리면 새로운 보안 정책과 권한 변경 사항을 준수해야 한다.

공식 문서: Target API Level

Target SDK 34 적용 시 발생한 문제들

1️⃣ 권한 요청 관련 변경 사항

Android 13(API 33) 및 14(API 34)에서는 기존의 READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE 권한이 동작하지 않고, 새로운 미디어 접근 권한을 사용해야 한다.

기존에는 READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE로 모든 갤러리에 접근 가능했지만,

Android 14(API 34)부터는 사용자가 선택한 사진만 접근할 수 있도록 Photo Picker 사용이 권장된다.

그래서 API 33 이상에서는 Photo Picker를 사용하고, API 32 이하에서는 기존 방식 유지하도록 했다.

참고: https://support.google.com/googleplay/android-developer/answer/14115180?hl=ko

✅ 결정 사항:

기존 READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE 대신 Photo Picker 사용
API 32 이하는 기존 권한을 유지하도록 maxSdkVersion="32" 설정

2️⃣ 알람 설정 (AlarmManager) 이슈

Android 12(API 31) 이상에서는 정확한 시간(Exact) 알람을 설정할 때 추가적인 권한이 필요하게 변경되었다.

기존에는 권한 없이 AlarmManager.setExact()를 호출했으나,

SCHEDULE_EXACT_ALARM 권한을 추가해야 정상 작동.

공식 문서 참고:

출처: AlarmManager API 변경 사항 (Android 개발 문서)

Android 12 이상에서는 정확한 알람을 설정하려면 SCHEDULE_EXACT_ALARM 또는 USE_EXACT_ALARM 권한이 필요합니다.

단, USE_EXACT_ALARM은 시스템 앱에서만 사용 가능하므로, 일반 앱에서는 SCHEDULE_EXACT_ALARM을 추가해야 합니다.

✅ 결정 사항:

SCHEDULE_EXACT_ALARM 권한 추가

3️⃣ PendingIntent의 FLAG 변경

Android 12(API 31) 이상에서는

PendingIntent를 생성할 때 FLAG_IMMUTABLE 또는 FLAG_MUTABLE을 반드시 명시해야 한다.

이전 코드에서는 PendingIntent.FLAG_UPDATE_CURRENT 만 사용했으므로 앱이 충돌하는 원인이 된다.

공식 문서 참고:

출처: https://developer.android.com/reference/android/app/PendingIntent

Android 12(API 31) 이상에서는 모든 PendingIntent가 FLAG_IMMUTABLE 또는 FLAG_MUTABLE을 포함해야 합니다.

그렇지 않으면 앱이 충돌하거나 보안 문제로 인해 거부될 수 있습니다.

다른 참고 블로그:

https://itstory1592.tistory.com/127

✅ 결정 사항:

PendingIntent 생성 시 FLAG_IMMUTABLE 또는 FLAG_MUTABLE 추가

Target SDK 34 적용을 위한 주요 변경 사항 정리

변경 사항 설명

Photo Picker 적용	READ_MEDIA_IMAGES, READ_MEDIA_VIDEO API 33+에서 요청하나, 사진 선택 1개라 권장되는 Photo Picker 적용
알림 권한 POST_NOTIFICATIONS 추가	API 33+에서만 요청하도록 변경
Android 32 이하의 저장소 권한 유지	maxSdkVersion="32"를 통해 API 32 이하에서만 기존 권한 사용
불필요 권한 삭제 (READ_MEDIA_AUDIO)	사용되지 않던 READ_MEDIA_AUDIO 권한 제거

✅ 마무리 및 느낀 점

이번 리팩토링을 하면서 targetSdk를 높이는 과정에서 SDK 버전별 정책을 유지하면서 새로운 정책을 반영하는 과정의 중요성을 직접 경험했다.

사실, 나는 아직 서비스를 출시해 본 경험이 없었기 때문에 이런 버전 업과 정책 대응을 경험할 기회가 있을까 싶었다.

그러나 이번에 targetSdk를 올리는 과정에서 버전별로 이전 기능을 유지하면서도 새로운 정책에 맞게 설정하는 과정이 필수적임을 배웠다.

특히,

구버전(Android 31 이하)에서는 기존의 권한 방식 유지
신버전(Android 33 이상)에서는 최신 보안 정책에 맞게 Photo Picker 등 새로운 API 적용
정확한 알람 설정, PendingIntent 보안 정책 대응

이 모든 것이 버전별 대응 전략을 갖추는 것이 얼마나 중요한지를 깨닫게 한 경험이었다.

아직도 리팩토링할 부분은 많지만, 이번 작업을 통해 Android 버전별 정책을 꾸준히 살펴보는 것이 얼마나 중요한지 다시금 실감했다.

앞으로도 이런 변화를 꾸준히 학습하고 적용해나가면서 더욱 안정적인 앱을 개발할 수 있도록 노력해야겠다!

다음 목표

✅ Navigation Component 적용 & Single Activity 구조로 전환

✅ UI 상태 관리

결론: SDK 업데이트, 어렵지만 성장하는 기회였다!

처음에는 targetSdk 34로 올리는 것이 불필요한 복잡성을 초래하는 것 아닌가 고민했지만,

장기적인 유지보수와 확장성을 위해 필수적인 과정이라는 점을 실감했다.

이 경험을 바탕으로 앞으로도 Android 정책 변화를 지속적으로 모니터링하고, 유지보수 및 개선에 신경 써야겠다고 다짐했다.

[Android/오르다] 오르다 다이어리 레거시 리팩토링 01 - 현재 코드 분석

yujinius — Tue, 11 Feb 2025 15:43:18 +0900

오르다 다이어리 레거시 리팩토링 01 - 현재 코드 분석

https://yujinius45.tistory.com/154

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

보호되어 있는 글입니다. 내용을 보시려면 비밀번호를 입력하세요.

yujinius45.tistory.com

▲ 이전 글에서는 오르다 다이어리의 리팩토링 계획을 정리했다. 이번 글에서는 현재 코드가 어떤 문제를 가지고 있으며, 이를 개선하기 위해 어떤 방향으로 리팩토링할 것인지 분석한 내용을 정리한다.

오르다 다이어리 v1.0.0 주요 기능

대략적으로 위와 같이 4가지의 기능이 존재한다.

오르다 다이어리는 일정 관리, 일기 작성, 알람, 지도 메모 기능을 제공하는 다기능 다이어리 앱이다. 사용자가 일상 기록을 보다 편리하게 관리할 수 있도록 설계되었다.

️ 일정 관리 (To-Do List)

캘린더에서 일정 확인 및 관리
사용자가 입력한 일정 목록을 내장 DB(SQLite)에 저장
일정 추가/수정/삭제 기능 제공
RecyclerView를 활용한 일정 목록 UI 구성

일기장 기능 (Diary)

사진 추가: 카메라 촬영 또는 갤러리에서 이미지 첨부
음성(STT) 지원: 음성 입력으로 빠르게 일기 작성 가능
텍스트 입력: 키보드 타이핑을 통한 일기 작성 지원
내장 DB(SQLite) 저장: 영구적으로 데이터 저장 가능

⏰ 알람 기능 (Alarm)

지정한 시간에 알람 설정 가능
플래시 & 사운드 알람: 알람이 울릴 때 플래시와 음악이 함께 재생
가속도 센서를 활용한 알람 해제
- 단순한 버튼 클릭이 아닌 핸드폰을 일정 강도로 흔들어야 알람이 해제됨 (가속도 센서 활용)

️ 지도 기반 메모 기능 (Map Memo)

지도(Google Maps)를 활용한 특정 위치에 메모 추가 가능

내장 DB(SQLite) 기반 데이터 저장

일정, 일기, 알람, 지도 메모 등 모든 데이터를 영구 저장
SQLiteOpenHelper를 활용하여 데이터 관리
앱을 종료해도 데이터 유지

현재 코드의 특징 및 분석

프로젝트 이야기

오르다 다이어리는 3년 전 개발된 Java & XML 기반의 레거시 코드로, 현재의 Android 개발 트렌드와는 다소 거리가 있는 구조를 가진다.

당시에는 Android Jetpack이나 AAC(Android Architecture Components)와 같은 최신 기술을 적용하지 않고, Activity 중심의 화면 전환과 SQLite 직접 접근 방식을 사용했다.

현재 코드에서 발견된 주요 사항

1️⃣ AAC 미적용 (Jetpack Architecture 미사용)

현재 프로젝트는 AAC(Android Architecture Components)를 전혀 활용하지 않고 있다.
ViewModel, LiveData, RoomDB 등의 개념이 적용되지 않았으며, Activity에서 직접 데이터베이스에 접근하거나 UI 상태를 관리하고 있다.
현재의 안드로이드 개발 방식에서는 AAC를 활용한 구조적 개선이 필수적이다.

2️⃣ 모든 화면이 Activity 기반으로 구현됨

현재 모든 주요 기능이 Activity 단위로 구현되어 있다.
화면 이동 시 Intent를 통해 데이터를 주고받으며, 각 Activity가 독립적으로 동작하도록 설계되었지만, 그로 인해 화면 간 상태 유지가 어렵다.
예를 들어, 일정 관리 화면에서 일기 작성 화면으로 이동하려면 뒤로 가기를 눌러 홈 화면을 거쳐야 하는 불편함이 있다.
해결 방향:
- Fragment를 활용하여 화면을 전환하고, Navigation Component를 적용하여 보다 자연스러운 화면 이동을 구현한다.

3️⃣ UI 상태 관리 문제 (Configuration Change 미대응)

화면 회전(Configuration Change) 시 일부 화면의 UI 상태가 유지되지 않는다.
확인된 문제점:
- 일정 화면(캘린더)에서 화면을 회전하면, 선택한 날짜가 초기화된다.
- 지도 화면에서는 회전 시 저장된 메모가 사라진다.
- 일기 작성 화면은 회전하면 입력 중이던 내용이 손실된다.
- 반면, 일기 목록 화면에서는 데이터가 유지된다.
원인:
- 상태 저장 로직이 대부분 적용되지 않았다.
- Activity 간 이동이 Intent를 통한 데이터 전달 방식이므로, 화면이 재생성되면서 데이터가 유지되지 않는다.
해결 방향:
- ViewModel과 LiveData를 적용하여 UI 상태를 유지하고, 회전 시에도 데이터가 보존되도록 개선한다.

4️⃣ SQLite 직접 접근 방식 사용 (RoomDB 미적용)

현재 프로젝트는 SQLiteOpenHelper를 활용하여 SQL 쿼리를 직접 작성하여 데이터베이스를 관리한다.
문제점:
- SQL 쿼리가 직접 코드에 포함되어 있어 가독성이 낮고, 유지보수가 어렵다.
- 데이터 접근 로직이 UI 코드와 섞여 있어 관심사 분리가 되지 않은 구조이다.
해결 방향:
- RoomDB를 적용하여 ORM(Object Relational Mapping) 방식으로 변경한다.
- DAO(Data Access Object) 패턴을 적용하여 데이터 관리 로직을 분리하고, Repository 패턴을 도입한다.

5️⃣ ViewModel 및 MVVM 미적용

현재 Activity에서 UI 로직과 데이터 로직이 섞여 있다.
ViewModel을 활용하여 UI 데이터를 관리하지 않으며, Activity가 종료되면 데이터가 모두 사라지는 구조이다.
해결 방향:
- ViewModel을 활용하여 UI 데이터를 관리하고, LiveData를 통해 UI와 데이터의 의존성을 낮춘다.
- MVVM 아키텍처를 적용하여 유지보수성을 높인다.

리팩토링 방향 정리

문제점	현재 방식	개선 방법
AAC 미적용	Jetpack 미사용	AAC(ViewModel, LiveData, RoomDB) 적용
Activity 기반 구조	모든 화면을 Activity로 관리	Fragment + Navigation Component 적용
UI 상태 미유지	DB에서 데이터를 불러와 바로 표시	ViewModel, LiveData 활용하여 상태 유지
DB 직접 접근	SQLiteOpenHelper 사용	RoomDB + DAO 패턴 적용
비효율적인 UI 로직	Activity 내 UI 및 데이터 로직 혼재	MVVM 패턴 적용하여 관심사 분리

✅ 다음 목표: UI 상태 관리 개선

이제 첫 번째 리팩토링 작업으로 UI 상태 관리를 개선하는 작업을 진행할 예정이다.

화면 회전 및 Activity 재생성 시 데이터가 유지되도록 ViewModel과 LiveData를 적용한다.
기존의 Intent 기반 화면 전환 구조를 Fragment로 변경하고, Navigation Component를 적용한다.

다음 글에서는 UI 상태 유지 문제를 해결하기 위한 접근법과 구현 방안을 다룰 예정이다.