우테코 안드 8기 "칸반 보드 태스크 - 컴포즈 기초" 리뷰 정리 1차

블로그 글 작성을 더 이상은 늦춰서는 안되겠다는 생각이 들어서 지금이라도 시작하려고 한다. 일단은 쉬운 주제부터 시작!

첫 미션에다 처음으로 PR 리뷰를 받았는데 신선한 경험이었다. 나름 2~3년 개발을 했는데도 PR 자체가 처음이었다. 현업에 있을 때에는 PR 리뷰랄것도 없이 코드 리딩정도만 진행했는데, 이런 과정 자체가 굉장히 충격적이었다. 한편으론, 개발을 헛 했다는 기분도 든다. 그래도, 우테코에서 이러한 선진적인 방법을 배우고 싶은 것이었으니 굉장히 만족한다.

PR: woowacourse/compose-kanban-board-task#1

리뷰어: ㅋㄹ

---

1. ktlint와 테스트 확인 습관

README.md

• Q: 항상 제출하기 전 ktlint와 테스트를 확인해보는 습관을 들이면 좋을 것 같습니다.
• A: 코드 정렬만 하고 있었는데 그 생각을 못했네요. 주의하겠습니다.

---

2. 커밋 분리 기준

README.md

• Q: README 작성 잘해주셨습니다. 커밋 로그를 보니 기능의 구현과 README 수정을 다른 커밋에 진행했던데 그렇게 진행한 이유가 있을까요? 과연 두 커밋을 나누는 것이 의미가 있는 것일지 고민해보고 알려주세요.
• A: 말씀을 들어보니 굳이 둘로 나누지 않아도 괜찮았겠다 생각이 드네요. 두 커밋으로 나눈 이유는 커밋 컨벤션에 따라 feat와 docs를 생각해서 나누었습니다. 기능 구현은 feat, README는 docs에서 커밋하고 싶었습니다. 지금 고민해보니, readme 수정이라고 해도 단순히 체크리스트 체크만 하는 것이어서 둘로 나누지 않아도 괜찮을 것 같네요! 앞으로의 구현에 반영토록 하겠습니다!

---

3. FlowRow 외에 아이템 배치 방법

KanbanBoard.kt

• Q: FlowRow 외에 비슷한 방식으로 아이템을 배치하는 방법은 무엇이 있을지 찾아보고 간단하게 비교해서 알려주시겠어요?
• A: FlowRow처럼 수평으로 배치하는 컴포넌트는 Row, FlowRow, LazyRow가 있었습니다.
  • Row - 컴포넌트를 수평 배치하는 가장 간단한 컴포넌트
  • FlowRow - 컴포넌트를 수평 배치하되 설정한 너비를 넘어가면 자동으로 다음 줄로 넘어가는 컴포넌트
  • LazyRow - 화면에 보이는 항목만 렌더링하고 수평 스크롤하면 새 항목을 그리고 벗어난 항목은 해제하는 컴포넌트
  • 현재 요구사항으로는 칩(태그)이 카드의 너비를 넘어갔을 때 다음 줄로 표시되어야 했기에 FlowRow의 사용이 적절하다고 생각합니다. 그러나 FlowRow의 경우 화면 너비를 계산해야 하고 자식 위젯의 크기를 고려해야 하기에 해당 요구사항처럼 필요한 곳 이외에서 사용하면 오버킬이라고 생각합니다.
  • 추가로 궁금한 점: LazyColumn이 많은 수의 자식을 가지고 있고 화면에 그려지지 않았지만 그려질 항목이 많다면 이는 성능저하의 요소가 될 수 있을까요?

---

4. listOf() 내부 동작

KanbanBoard.kt

• Q: listOf() 함수는 내부적으로 어떻게 리스트를 만들어주고 있나요? 0단계에서 학습하셨으리라 믿고 질문드려봅니다.

• A: listOf의 실제 구현상 코드는 아래와 같습니다.

    public fun <T> listOf(vararg elements: T): List<T> =
        if (elements.size > 0) elements.asList() else emptyList()

  listOf가 하나 이상의 매개변수를 전달 받았을 때에는 vararg로 받은 elements는 함수 내부에서 Array로 취급되고 Array를 asList하여 리스트로 만드는 것이었습니다. listOf가 매개변수를 전달 받지 않았을 때에는 emptyList()를 통해 EmptyList를 반환하는데 여기에서 EmptyList가 List<Nothing>이라는 게 신기했습니다. 비어있는 ArrayList를 반환하는 줄 알았는데 이렇게 최적화하는 게 신기했습니다.

---

5. shape vs Modifier.clip

KanbanBoard.kt

• Q: shape를 주지 않고 Modifier.clip으로도 비슷한 결과를 도출할 수 있습니다. 둘은 어떤 차이가 있는지 알아보고 알려주세요.
• A: 프리뷰의 배경화면을 검은색으로 설정했는데 Modifier.background에 shape를 사용했을 때는 검은색이 보였는데 Modifier.clip을 사용하니까 검은색이 보이지 않았다. 알고보니 Modifier에서 순서를 조정하면 되는 일이었다. 백그라운드 설정 이전에 클립 해줘야 제대로 잘린다!
  • Modifier.background는 내부에 있는 콘텐츠나 터치 영역은 그대로 사각형
  • Modifier.clip은 그 이후 체인 전체에 클리핑을 적용. 배경, 콘텐츠, 이미지, 터치 영역까지 모두 해당 shape으로 자름
  • clip이 Modifier.background보다 더 강력하다고 느꼈습니다.

---

6. padding과 background 순서

KanbanBoard.kt

• Q: padding과 background의 위치가 바뀌면 어떤 일이 일어나는지, 그리고 왜 그런일이 일어나는지 확인해보고 알려주세요.
• A: 이전에 주로 했던 플러터와 비교를 통해 통찰을 얻을 수 있었습니다. 컴포즈에서 모디파이어 체이닝 순서가 무분별하다고 생각했는데 플러터에서도 똑같이 위젯을 감싸면서 순서를 적용했다는 사실을 깨달으니 연상이 쉽게 되었습니다.
  • background → padding 순서: "카드에 배경색을 설정하고 그 안에 여백을 적용하기"
  • padding → background 순서: "여백을 적용한 카드 내부에 배경색을 칠한다" → 여백이 미리 적용된 카드에 흰색 여백이 생기고 중간에만 배경색이 적용됨

---

7. sp와 dp의 차이

KanbanBoard.kt

• Q: sp와 dp는 어떻게 다른가요? dp를 fontSize로 사용하면 어떤 일이 일어나나요?
• A: 아래와 같이 정리했습니다.
  • dp (density independent pixel): 화면 기준 픽셀. 같은 기기라면 항상 같은 크기.
  • sp (scale independent pixel): 가변 글꼴 기준 픽셀. 시스템 글꼴 설정에 따라 1sp당 픽셀 수가 달라짐.
  • Text 뷰에 fontSize를 dp로 설정했더니 Argument type mismatch: actual type is 'Dp', but 'TextUnit' was expected. 오류 발생. 애초에 설계가 dp로 폰트 크기를 받지 않겠다는 오류라고 생각.
  • 기본적으로 폰트 관련 컴포넌트에서는 sp, 이외에는 dp로 사용하면 된다는 것을 알았습니다.
  • 추가 질문: 만약 시스템 폰트 크기 설정에 따른 폰트 크기 변화에 구애하지 않고 싶을 때에는 어떻게 하면 되는지 궁금합니다.

---

8. PreviewParameter 활용

KanbanBoard.kt

• Q: Preview 잘 구성해주셨습니다. 확인하고 싶은 텍스트 값들이 달라질 때마다 Preview 함수를 계속 만들어야 할지 고민해보면 좋겠어요. 하드코딩 하지 않고 같은/다른 내용을 보여줄 수 있도록 하는 방법을 찾아봅시다. PreviewParameter 키워드를 통해 고민해보시면 좋겠습니다.
• A: 실제로 코드로 구현해봤는데 컴포넌트를 줄일 수 있는 점에서 좋다고 생각합니다. 한편으론 Preview 말고도 @PreviewFontScale, @PreviewScreenSizes 등 여러가지 Annotation이 있다는 사실을 알 수 있었습니다.

---

9. 색상만 다른 같은 UI

KanbanBoard.kt

• Q: 색상만 다르고 정확히 같은 UI를 구성해야 하는 상황이 오면 어떻게 될까요? 여기서 생기는 문제를 어떻게 피해볼 수 있을까요?
• A: 저라면 색상 값을 매개 변수로 빼겠습니다. 그런데, 색상 값을 매개변수로 빼려고 했는데 아예 Modifier를 매개변수로 받고 색상을 조정하는 건 어떨까 싶었습니다. 그런데, 알고보니 코틀린에서는 Modifier은 기본적으로 바깥으로 빼는 게 맞았습니다. 그렇지만, 호출하는 쪽에서 여백이나 크기를 조절할 수 있게 Modifier를 열어두는 것이었지만 색상 같은 자식의 위젯은 따로 빼는 게 맞다고 생각했습니다. 마침, 이 부분으로 오늘 또 수업이 있어서 좋은 공부가 되었던 것 같습니다.

이번 리뷰에서는 기본적인 주제들에 대해서 많이 질문을 받았다. 컴포즈 기초 지식이나 커밋 방법 등을 점검 받을 수 있었다. 한편으론, DP와 SP를 왜 나누었는지에 대해서 잘 이해가 가지 않는다. 플러터에서는 논리적 픽셀 입력으로 단위도 쓰지 않고 정수로만 크기를 정할 수 있었는데, 컴포즈에서는 .dp, .sp를 붙여야하는 번거로운 방법을 택하고 있다. 또한, 텍스트만 sp 단위를 쓴다면 크기 단위는 정수로 통일하고 텍스트만 따로 처리하면 되지 않을까~ 싶기도 하고.. 이 주제로 새로운 글을 써보는 것도 좋다고 생각이 든다.