[Mission] 닉 8주차 미션

[Nick9417]

📌 PR 제목

8주차 미션

#️⃣ 연관된 이슈

closes #81

✅ 변경 사항

이번 PR에서 변경된 내용을 간략히 정리해주세요.

• 기존에 만들었던 RecyclerView + Adapter 코드를 LazyColumn으로 교체하기
• 아직 ViewModel이나 Repository를 따로 만들지 않아서 역할이 깔끔하게 분리되어 있지 않습니다ㅠ

📷 영상 및 스크린샷

2026-05-24.232907.mp4

🔗 알게 된 사항

List를 이용하는 방법과 items, LazyColumn, LazyRow, LazyGrid를 다루는 방법을 알 수 있었습니다.

📝 질문 사항

xml 말고 Compose에서의 정석적인 구조는 어떻게 구성되는지 알고 싶습니다.

[hw4nx02]

8주차 피드백

안녕하세요, 닉🦊! 서서히 종강이 다가오는 게 느껴집니다... 조금 더 파이팅해봅시다!!

총평

이번 주에는 Compose에서의 리스트 구현에 대해 학습했는데요. 이는 성능과 안정성에 직접적인 영향을 미치는 요소입니다. 때문에 불필요한 Recomposition을 방지하고, 스크롤 가능한 컴포넌트의 올바른 사용에 대한 고민이 항상 필요한 지점이라고 볼 수 있겠습니다!
기존 RecyclerView 기반의 리스트 구현을 Compose의 Lazy List (LazyColumn, LazyRow, LazyVerticalGrid)로 성공적으로 전환했습니다. 이는 Compose 학습 목표에 부합하며, UI 성능 개선의 기반을 마련합니다. 또한, presentation 및 core/data 패키지 구조를 도입하여 프로젝트 아키텍처를 개선하려는 노력이 엿보입니다. MainActivity에서 mutableStateListOf를 사용하여 리스트 상태를 관리하는 방식은 초기 단계에서 합리적인 접근입니다. 전반적으로 미션 목표를 잘 달성하고 있으며, Compose의 핵심 개념을 적용하는 데 좋은 진전을 보였습니다.

리뷰

Good!

1. Lazy Composable의 적절한 선택

HomeScreen에서 다양한 리스트 요구사항에 맞춰 LazyColumn, LazyRow, LazyVerticalGrid를 적절히 선택하여 사용한 점이 좋습니다. 이는 Compose의 성능 이점을 잘 활용하는 것 같습니다.

2. 스크롤 방향 중첩 없음

같은 방향으로 스크롤하는 Lazy Composable을 중첩하지 않아 잠재적인 스크롤 충돌이나 비효율성을 잘 방지했습니다. 이는 사용자 경험과 성능에 긍정적인 영향을 미칩니다.

3. 상태 관리의 초기 구현

MainActivity에서 mutableStateListOf<Goods>()를 사용하여 장바구니 및 위시리스트 아이템을 관리하고, wishOnClick 람다를 통해 이 상태를 업데이트하고, 이 상태는 하위 Composable에 전달되어 UI를 업데이트하고 있습니다. Compose의 상태 관리 원칙에 따라 mutableStateListOf를 사용하여 리스트의 변경 사항을 효율적으로 감지하고 UI를 업데이트하는 방식으로 반응성을 향상시키고 있습니다.

To Improve

1. 아이템 Key 지정 개선

HomeScreen의 HomeGoodsRow, PurchaseScreen의 PurchaseGridList, WishScreen의 WishGridList에서 items(list) { item -> ... } 형태로 사용하고 있으며, key 파라미터를 명시적으로 지정하지 않았습니다.
피드백: Lazy Composable의 items 함수에서 key 파라미터를 지정하지 않으면 기본적으로 아이템의 인덱스를 키로 사용하게 됩니다. 이는 리스트의 아이템이 추가, 삭제, 재정렬될 때 불필요한 Recomposition을 유발하거나, 아이템의 상태가 올바르게 유지되지 않는 문제를 일으킬 수 있습니다. Goods 데이터 클래스에 goodsId가 있으므로, 이를 key = { goods -> goods.goodsId }와 같이 사용하여 각 아이템에 고유한 키를 부여하는 것이 좋습니다.

2. ViewModel 도입을 통한 아키텍처 개선

PR 설명에서 ViewModel이나 Repository가 아직 분리되지 않았다고 언급하셨습니다. 현재 MainActivity에서 리스트 데이터를 직접 관리하고 있지만, 앱의 규모가 커지면 데이터 관리 로직이 복잡해지고 테스트하기 어려워질 수 있습니다. ViewModel을 도입하면 UI 로직과 데이터 로직을 분리하여 코드의 응집도를 높이고, 생명주기에 안전하게 데이터를 관리할 수 있습니다.
-> 각 화면(HomeScreen, PurchaseScreen, WishScreen 등)에 해당하는 ViewModel을 생성하고, ViewModel에서 리스트 데이터를 관리하도록 리팩토링하는 것을 고려해 보세요. 데이터 변경 로직(예: 위시리스트 추가/삭제)도 ViewModel에서 처리하고, Composable은 ViewModel의 상태를 관찰하여 UI를 업데이트하도록 변경할 수 있습니다.

3. 불변 데이터 클래스 사용 고려

Goods 데이터 클래스의 isWished 필드가 var로 선언되어 있습니다. Compose에서는 불변(immutable) 객체를 사용하는 것이 Recomposition 최적화에 유리하며, 데이터 흐름을 예측하기 쉽게 만듭니다. mutableStateListOf 내의 객체라도, 객체 자체가 불변이면 변경 감지가 더 명확해질 수 있습니다.
제안: Goods 데이터 클래스의 isWished 필드를 val로 변경하고, isWished 상태를 변경해야 할 때는 copy() 함수를 사용하여 새로운 Goods 객체를 생성한 후 mutableStateListOf에서 해당 객체를 업데이트하는 방식으로 변경하는 것을 고려해 보세요.

예. val updatedGoods = goods.copy(isWished = !goods.isWished)와 같이 사용할 수 있습니다.