IoC는 간단히 말하자면 내 코드의 실행을 다른 API에 위임하는 방식입니다. 즉, API를 사용하는 쪽에게 내부적으로 어떻게 동작할지에 대한 권한을 부여합니다. 질문주신 State reducer 패턴도 reducer를 사용하는 쪽에서 정의하게 하는 패턴인데 결국 핵심은 IoC 입니다. (뭐 물론 기본 reducer를 쓰면 IoC가 일어나지 않긴 하는데 그 경우에는 이 패턴을 썼다고 하긴 좀 애매하다고 생각합니다.) 그럼 React 컴포넌트에서 사용하는 IoC는 어떤 문제를 풀려고 했을까요? 패턴이란게 결국 좋은 설계를 하기 위한 방법 중에 하나입니다. 좋은 설계란 응집도를 높이고 결합도를 낮추는 것이죠. 하지만 이렇게 말씀드리면 확 와닿진 않으실테니 좀 더 풀어서 설명하자면 우리가 유지보수&개발하기 편하도록 변경이 용이한 코드를 만드는 것을 의미합니다. 이러한 관점에서 IoC는 느슨한 결합도를 만들 수 있도록 도와줍니다. 아마 Kent C. Dodds의 설명을 보시고 계실거라고 생각하고 거기있는 예제코드로 설명을 하자면 Toggle 컴포넌트에 기능을 추가해야할 때 일반적인 케이스라면 useToggle에 이런저런 로직들을 추가해야하고 이에 따라 Toggle 컴포넌트에도 대응이 일어날 것입니다. 하지만 state reducer 패턴을 적용한다면 useToggle에는 수정없이 사용하는 쪽의 코드(reducer)에만 수정이 일어나는 상황이 되겠죠? 제어의 역전이 일어났으니까요! 또 뭔가 아직 와닿지 않으신다면 다른 컴포넌트에서도 useToggle이 사용된다고 가정해봅시다. 기능 추가를 위해 useToggle이 변경되면 사용하고 있는 모든 컴포넌트에 대응이 필요합니다. 높은 결합도라는거죠! 이 경우에 state reducer 패턴을 적용했다면 사용하는 컴포넌트에서만 reducer 로직을 바꿔주면 됩니다. 이제 좀 어떤 이점이 생기는지 감이 오시나요? IoC를 통해 이런 식으로 느슨한 결합도를 달성하게 만들 수 있습니다. 아 마지막으로 혹시 이 낮은 결합도가 왜 유지보수에 용이한지 모르신다면 모듈 간의 결합도가 낮다는 것은 한 쪽 모듈이 변경되어도 다른 쪽 모듈이 변경되지 않는 것을 의미하는데요! 당연히 어떤 코드의 변경이 있을 때 최소한의 코드만 작업할 수 있다면 당연히 좋은 코드겠죠!?