[TIL] flutter 심화 - 도전 과제 Trouble Shooting

김영광·2026년 2월 3일

flutter 심화 개인 프로젝트 기간이 눈 깜짝하니 끝났다.
오늘은 도전 과제에 집중했는데, 진행하며 겪은 Trouble을 정리하고자 한다.

1️⃣ firestore에서의 offset?

Firestore에 저장되는 데이터들의 문서들에 index 같은 개념이 있다면 관리가 얼마나 편할까라는 생각을 해봤다.
이러한 생각은 무한 스크롤에서 시작됐다.
인덱스로 문서가 관리되면, CreatedAt 같은 속성이나 lastDoc 같은 세이브 포인트를 사용하지 않아도 되기 때문이다.

후에, Set을 사용하는 방법도 생각해봤다.
List가 아닌 Set으로 접근하면 중복되는 요소없이 접근할 수 있기 때문에 데이터 중복은 막을 수 있을 것으로 생각됐다.
하지만, 데이터 누락에 대해서는 똑같은 문제가 발생한다는 사실을 뒤늦게 알게 됐다.

Firestore는 NoQSL DB이다.
데이터가 100만개가 있다면, 50만번째 데이터에 접근하기 위해 처음부터 세는 방식은 상당히 비효율적이다.

관계형 데이터베이스의 같은 경우에는 OFFSET을 이용해 몇번째부터 몇개를 달라는 요청이 가능하다.
Firestore의 경우에는 읽기 비용이 기하급수적으로 늘어나기에 이론으로만 가능하다고 볼 수 있다.

대신 "Cursor"라는 책갈피를 사용한다.
DocumentSanpshot이 바로 그 역할을 해준다.
해당 객체는 전체 Document의 순간을 간직하고 있는데, 그 중 가장 뒤에 서있는 놈을 기억할 수 있다.
.last 메서드를 이용하면 해당 Document를 쉽게 구해낼 수 있다.
이후, 재호출 시에는 startAfterDocument(lastDoc)를 통해 "마지막놈 뒤에부터 불러와줘"를 시작할 수 있다.

그럼 여기서 문제가 발생한다.
DataSource에서 반환하는 데이터는 DTO, 즉 API를 호출하며 불러온 순수 객체를 반환해줘야 하는게 정석이다.

그럼 3가지 경우가 발생한다.

  • DTO 자체에 처음부터 lastDoc을 추가할 건가?
  • DTO를 repository layer에서 가공할 때, lastDoc을 추가한 Entity를 새롭게 만들 것인가?
  • DataSource layer의 본연의 맛과는 조금 멀어지지만, 반환 값 자체를 바꿔볼 것인가?

전자부터 보자면, DTO가 lastDoc을 기억하기에는 무리가 있다.
처음부터 불러올 값에 저장하기가 쉬운 일이 아니다.
또, 문서의 변화에 따라 Orderby, 즉 정렬은 새롭게 그려지는데 이에 따른 lastDoc을 일일이 넣어주는 건 무리데스.

2번째는 DTO는 순수 객체로 받아준 뒤, lastDoc을 추가하는 Entity를 새롭게 만드는 방법이다.
bool 타입으로 마지막 놈인지 체크하는 형식이나, lastDoc를 무겁지만 같이 들고 다니는 방식을 생각해봤다.
bool 타입과 id 값을 기준으로 두고 조합하면 될 것 같았지만, 3번째 방식이 좀 더 쉬워보였기에 뒤로 미뤘다,,

마지막은 내가 선택했는데, 위 방법 중 가장 쉽게 접근할 수 있었다.
cleanArchitecture에서 DataSource의 본연 기능과는 거리가 생기지만, 그래도 가장 빠르게 접근할 수 있기에 선택했다.

추후, 고민을 좀 더 해서 2번째 방법을 통해 id를 가지고 노는 방식으로 리팩토링 해봐야겠다.

2️⃣ CleanArchitecture와 Repository의 정확한 역할

Clean Architecture를 학습하며 많은 시간을 보낸 만큼 확실한 구조를 짜보고 싶었다.
결론부터 말하자면, 과하다.
나중에야 어쩔지 모르지만, compose 학습 중에도 느꼈었다.
정말 과하다.
Google에서 MVVM 단방향 Layer를 더 밀어주는 이유를 뼈저리게 느꼈다.

그래도 이번 학습을 통해 Repository 역할을 정확히 알게 되었다.
"데이터 가공" 정도로만 알고 있었는데, vm에 바로 사용할 수 있는 데이터를 넘김과 동시에 DataSource에서는 DTO 같이 쌩 데이터를 받아와 가공한다.
MVVM 아키텍처에서는 당연히 받아와 가공하는 부분이 함께 내포되어 있다.

앞으로 Clean Architecture를 사용할 거냐는 물음에는 들숨에 경멸의 눈빛, 날숨에 "No"를 뱉겠다.

3️⃣ 학습 방향

Clean Architecture에 많은 시간을 쏟은 만큼, 장단점을 확실히 알게 된 것 같다.
앞으로 팀프로젝트에서는 MVVM 패턴을 바탕으로 구조를 잡고싶다.

또 너무 틀에 치중하기보단 질 좋은 코드, 유연한 움직임에 초점을 두고 싶다.
컴포넌트화를 할 때도 Widget별로 특성을 파악한 뒤 움직이고 싶다.

마지막으로 "flutter는 라이브러리에 의존적이다"라는 말이 있는데 이번에는 라이브러리를 직접 사용해보며 느낀 것을 바탕으로 추후 직접 만들어보고 싶다..!!

profile
주니어 개발자

0개의 댓글