데이터 정규화란?
모든 필드와 레코드가 논리적으로 구성되어 중복을 방지할 뿐만 아니라, 관계형 데이터베이스를 보다 효율적으로 사용하도록 하는 방법입니다.
라고 설명하고 있지만, 설명만 봐서는 이해가 조금 어려웠다. 핵심은 데이터베이스를 효율적으로 관리 하는 게 목적인 거 같다.
Redux와 데이터 정규화와 관계
점진적 과부하 프로젝트를 진행할 때 프론트에서 상태관리를 하기 때문에 좀 더 효율적으로 관리하고 싶었다.
지금 까지 생각해보면, 백엔드가 있을 때는 API문서를 통해 데이터를 어떤 식으로 주고받을지 정해서 했지만, 혼자 프로젝트를 했을 때 그때마다 필요한 데이터를 만들고, 조합해서 사용했었다.
위 링크에 들어가 보면 Redux 공식문서에서 상태 정규화를 통해 상태관리를 하는 방법을 알려준다.
내가 점진적 과부하 프로젝트에서 Redux를 통해 데이터 정규화를 진행했던 가장 큰 이유다. 공식문서에서 자세히 알려주고 있어, 궁합이 잘 맞을 거라고 생각했고, 학습하기에도 수월했다.
데이터 정규화를 통해 내가 사용할 상태들을 어떻게 관리할지 만들었고, 그렇게 프로젝트를 진행했다.
Redux에서 데이터 정규화를 통해 상태관리를 보다 효율적이게 할 수 있다고 알려주고 있다.
간단하게 설명하면, 만약 블로그의 상태관리를 한다고 해보면, post라는 상태값과 그안에 byId안에 post1, post2 이런 식으로 데이터를 만들고 allIds 안에 post들을 배열로 관리하면서 byId에 객체 체이닝을 통해 값을 확인하지 않고, allIds를 통해 바로 접근할 수 있다.
아래 예시를 보자 참고로 아래 예시는 Redux 공식문서 데이터 정규화 부분에서 가져왔다.
posts : { byId : { "post1" : { id : "post1", author : "user1", body : "......", comments : ["comment1", "comment2"] }, "post2" : { id : "post2", author : "user2", body : "......", comments : ["comment3", "comment4", "comment5"] } } allIds : ["post1", "post2"] },
위처럼 allIds 통해 post id에 접근해서 게시물을 삭제, 추가, 개수 확인 등의 기능을 만들 수 있고, 그리고 user와 comment역시 위와 같은 형태로 만들어 똑같이 관리할 수 있다.
posts라는 데이터 안에 모든 값이 계속 중첩되는 게 아니라, 각각 따로 만들어서 사용하면, 데이터가 깊게 중첩이 되지 않아 관리하기 편하다는 장점이 있었다.
Redux에서 데이터 정규화의 장점
위에서 말했던 장점이 외도 많은 장점이 있다.
- 각 항목이 하나의 위치만 정의해서, 상태값이 업데이트돼도 여러 위치를 바꾸지 않아도 되고
- 리듀서로직이 깊게 중첩된 데이터를 관리하지 않아 보다 편리하게 데이터를 관리할 수 있고
- 모든 데이터는 ID가 있어, 어떤 데이터를 찾거나 업데이트할 때 쉽게 찾을 수 있고
- 데이터 타입이 분리되어 있어, 어떠한 데이터를 변경하거나 업데이트할 때 필요한 곳만 상태가 변경되고 그곳만 리렌더링 되면서 불필요한 리렌더링을 막을 수 있다. 이는 만약 상태값이 모두 중첩이 된 데이터라면 작은 부분만 바꿔도 전체가 렌더링 되기 때문에, 속도, 메모리 등의 측면에서 효율적이다.
내가 프로젝트를 하면서 가장 장점이라고 느낀 것은 2번과 3번이다.
프론트에서만 데이터를 관리해서 데이터 자체를 다루는데 복잡하긴 했지만, 리듀서의 로직은 간단하게 구현할 수 있었고, 데이터를 수정, 삭제, 추가, 업데이트 등의 기능을 구현할 때도 ID로 관리가 가능했다.
4번은 약간 React에서 리렌더링이 되는 조건들을 생각해보면 state가 변경되고, 새로운 props가 들어고, 기존 props가 업데이트되고, 부모 컴포넌트가 리렌더링 될 때 이 정도 인거 같은데, Redux를 통해 전역으로 상태관리를 하고 데이터가 중첩이 많이 된 상태를 페이지에서 UI로 보여준다고 했을 때, 중첩된 데이터에서 조금이라도 변경이 되면 전체를 리렌더링 하는 상황이 발생한다.
이것을 방지하기 위해 모든 데이터가 분리되고 ID만으로 찾을 수 있고, 페이지 안에 여러 UI의 데이터가 분리되어 어떠한 상태가 변경돼도 그 UI만 리렌더링되는게 장점인 거 같다.
Redux에서 데이터 정규화의 단점
- 코드의 복잡성이 증가한다.
- 데이터 정규화를 구현하면서 구조, 관계 등을 고려하면서 개발 시간이 늘어난다.
- 위와 비슷하게 중첩되는 중첩되는 되어 과잉 정규화가 생겨 복잡성과 개발 시간이 늘어난다.
위 3가지 단점들은 구글링을 통해 조금 알아본 것들이다.
1번 공감한다. 처음 정규화를 통해 프로젝트를 했을 때, 리듀서 로직은 비교적 간단했지만, 데이터를 다루는 데 있어서 어려움이 많았다...
백엔드가 있었으면, 요청하고 받은 데이터로 편리하게 할 수 있었겠다 라는 생각을 많이 했었다.
2번 처음 상태를 정규화하고 프로젝트를 진행하면서 몇 번이고 데이터 구조를 변경하면서 기능도 수정하고 좀 더 괜찮은 구조가 생각나면 다시 적용하고, 변경하고 생각보다 구조 변경을 많이 했었다. 한번 구조를 잡으면 이대로 구현을 할 생각이었지만, 데이터를 이렇게 하면 좀 더 UI를 만들 때 편하겠다. 이런 생각들이 개발 시간을 늘어나게 했었다.
1번, 2번을 겪으면서 3번의 문제처럼 절충안을 찾아야 했다. 데이터 정규화를 통해 모든 데이트를 분리할까 고민도 했지만, 데이터의 중첩이 많지 않으면 크게 복잡하지 않게 UI와 기능들을 구현할 수 있다고 생각했고, 그렇게 프로젝트도 마무미를 할 수 있었다.
회고
Redux와 데이터정규화를 알게 된 계기는 프로젝트를 할 때마다 상황에 맞춰 상태 데이터를 만들어 관리했었고, 상태 데이터를 규칙적이게 관리를 하고 싶었던게 시작이었다.
프론트엔드 개발자는 UI만 만드는 개발자라고 생각해서 시작했지만, 지금은 많은 상태관리 툴이 생기고, 효율적으로 상태 데이터를 관리하는 게 좀 더 취중이 높아진 거 같다.
데이터정규화를 통해 처음으로 혼자 데이터 구조를 잡고 진행했었고, 나름 체계적으로 진행했다고 생각한다.
데이터 구조에 관심이 생긴 계기가 되었고, 몇 번의 프로젝트를 통해 데이터 정규화 방법도 좀 더 잘할 수 있으면 좋겠고, 다른 상태관리 툴과 다른 데이터 구조 및 관리 방법도 공부해야겠다.