첫번째로, 어떤 방식으로 상태를 다루는 라이브러리를 선택할까? 에 대한 고민을 했다.

방식에는 top-down, bottom-up 두가지 방식이 존재하는데, 우리의 선택은 top-down 이었다.

척척이의 상태는 숫자 한두개가 아닌 100~1,000개 단위의 수를 다룰 것으로 예상이 되고, 이 방대한 양의 상태를

각 컴포넌트에서 다루게 된다면 그 흐름을 따라 추적하는데 큰 어려움이 있을 것이라 생각했다.

이러한 어려움을 마주할 상황을 최소화 하기위해 상태를 중앙에서 관리하여 추적에 용이한 라이브러리를 사용하고자 하였고, 후보군은 Redux-toolkit, Zustand 로 압축되었다.

두번째로, 코드의 간결함을 고려했다.

redux-toolkit이 기존에 redux의 문제점으로 생각되던, 불필요한 보일러플레이트 코드를 줄이는 단점을 보완하였지만, 그럼에도 zustand와 비교하여 같은 기능을 수행하는 로직을 작성하여 코드양을 비교해보면 zustand가

더 짧은 코드양을 보여주었다.

왜 코드의 간결함을 기준으로 잡았냐? 에 대한 질문의 답은 역시 시간 비용이다.

우리 프로젝트의 핵심 로직이 될 3D 객체를 다루는 부분에 대하여, 다루어 본적이 없는 라이브러리라 시간이 얼마나 걸릴지 예측이 안되는 상황이다. 하지만 우리에게 주어진 시간은 한정되어있고, 해당 시간 내에 프로젝트를 완성해야하는게 우리 입장이기에 조금이라도 핵심 비즈니스 로직을 제외한 다른 코드들의 절대적인 양을 줄여서

시간 비용을 확보하는게 중요하다 생각된다.