Tori의 개발 공부

🛠 문제 상황앱을 출시한 이후, 홈 화면에서 게시글 리스트가 늦게 로딩되는 현상을 발견하였습니다.특히 네트워크가 불안정한 환경에서는 빈 리스트 화면이 먼저 보여지고, 몇 초 뒤에야 게시글이 나타나는 문제가 발생하였습니다.이러한 구조는 사용자에게 앱이 멈춘 것 같은 인상을 줄 수 있으며, 데이터가 없는 줄 착각하는 사용자 경험을 유발할 수 있다고 판단하였습니다.또한, 앱 전체적으로 API 호출 횟수를 최대한 줄일 수 있는 방법에 대해서도 함께 고민하게 되었습니다.✅ 해결 방법FileManager 기반의 JSON 캐시를 도입하여, 게시글 리스트를 디스크에 저장하도록 하였습니다.현재 게시글 리스트에 우선적으로 적용했지만, 이후 확장성을 위해 CacheType enum과 CacheService 유틸 클래스를 ..

에러 핸들링은 소프트웨어 개발에서 피할 수 없는 과제입니다.하지만 이전 프로젝트들에서는 에러 처리 방식은 단순히 “에러 발생 시 메시지를 출력하고 멈춘다”는 수준에 머무르는 경우가 많았습니다.이렇게 단순화된 접근은 문제 해결에 필요한 정보를 제공하지 못하거나, 사용자 경험(UX)을 저해하는 결과를 초래할 수 있습니다.이번 글에서는 클린아키텍처 구조에서 맥락(Contextual) 에러와 프레젠테이션(Presentation) 에러를 도입하여 에러 핸들링 체계를 개선한 사례와 그로 인한 효과를 공유합니다.단순한 에러 처리의 한계처음 프로젝트를 시작했을 때 저희는 DataError만을 사용해 에러를 처리했습니다.예를 들어 네트워크 통신 에러, 디코딩 인코딩 에러 등 Data Layer에서 발생하는 에러들에 관해..

문제 상황프로젝트를 진행하면서 팀원들의 개발 일정 상 앱의 디자인을 어느 정도 진행 된 뒤 API 연결에 들어가게 되었다.그러다 보니 연결이 제대로 되었는지, 데이터는 제대로 받아오는지 확인하기 위해 클린아키텍처 구조 상 DataSource (API 연결부)부터 Repository, UseCase를 지나 Presentation 레이어의 뷰모델, 뷰 까지 모두 연결되어야지만 테스팅이 가능했다.그런데 이 때, 앱의 구현이 진행됨에 따라 프레젠테이션 레이어 연결 시 변경해줘야 하는 부분들이 점차 늘어났고, 테스팅 실패 시 최악의 경우 전체 구조를 변경해야 하는 경우도 있었다.따라서 이 부분에서 불편함을 느껴 단계별로 DataSource 의 API 테스트, Repository의 DTO -> Entity 변환 테..

ReactorKit을 사용하여 MVVM 모델로 구현을 하고 있었으며 클린아키텍처 구조로 프로젝트를 구성하고 있었다.프로젝트의 전체적인 구조를 살펴보면 다음과 같다Presentation ㄴ View(ViewController) ㄴ ViewModel(Reactor)Domain ㄴ Model ㄴ Usecase ㄴ Repository (프로토콜)Data ㄴ DTO Model ㄴ RepositoryImpl (구현부) ㄴ Datasource 로그인 로직을 구현하면서 여러 데이터 소스들을 사용하고 합치는 과정들을 거치게 되었고,이때 점점 레이어나 각 구성 요소들의 책임들을 모호하게 코드를 작성하고 있다는 생각이 들어 명확하게 책임 분리를 정리해야겠다고 생각했다.처음에 공부..