[트러블슈팅] 리사이클러뷰 item 다중 삭제 구현 중 인덱스가 밀렸던 문제

sopt 세미나에서 리사이클러뷰 selection 라이브러리를 알게 됐고 이번 기회에 사용을 해봤다. 처음에는 selection 라이브러리를 활용해서 기능 구현을 했다가 몇가지 이슈가 있어서 안 쓰는 방향으로 리팩토링을 했다. item 삭제 시 인덱스가 밀리는 문제가 발생했다.
 
가령 인덱스가 [0], [1], [2]인 3개의 data가 있고 [1]을 삭제하면 data가 2개로 줄면서 [2]이 새로운 [1]이 돼야 하는데 이게 갱신이 안 된 형태로 여전히 [2]로 남아있어서 indexOutOfBounds 에러가 떴다.
인덱스 말고 리사이클러뷰 item 고유의 id 값을 기준으로 currentList에서 filter를 해주는 식으로도 코드를 짜봤는데 해결이 안 됐다. 
 
차선으로 selection 라이브러리의 활용을 유지하되 삭제를 할 때마다 어댑터를 매번 초기화하고 서버로부터 data를 새로 받아오는 방법을 선택했다.
 
그런데 좀 아쉬웠다. 매번 data를 새로 받아와야 하다보니 사용성이나 성능이 떨어질 수밖에 없기 때문이다. 결국 타협하지 않고 리팩토링을 했다.
 
selection 라이브러리를 버리고 selector를 활용해서 item의 isSelected 값에 따라 UI가 바뀔 수 있게 작업을 해주었고 선택된 item들은 별도의 MutableList로 관리해주었다. 추후 currentList에서 이 list에 담긴 item들을 filter하고 submitList하니 인덱스가 밀리는 오류 없이 잘 구현 되었다.
 
selection 라이브러리를 버린 결정적 이유 중 하나는 내가 라이브러리에 대한 이해가 충분치 않다보니 이슈가 생겼을 때 원인 파악을 명확히 해낼 수 없다는 것이었다. 그렇다고 이 라이브러리를 자세히 공부해보자니 다중삭제 기능 구현에 selection 라이브러리가 필수가 아닌데 너무 큰 리소스 투자라고 느껴졌다.
 
또 팀원과의 구현 방법도 통일해야 코드 관리가 수월한데 나 혼자 selection 라이브러리를 활용하는 방향으로 코드를 짜면 팀원이 나중에 내 코드를 봐주기가 어렵다. 이런 이유들로 selection 라이브러리를 버렸다.
 
라이브러리의 활용은 개발 시 편의성을 제공해주지만 학습 비용이 있기 때문에 trade off를 잘 고려해서 현명한 선택을 해야겠다고 느꼈다.