🧠 제어의 역전(Inversion of Control)

💌 요약

The principle of IoC says that we don't call the framework, the framework calls us.

외부의 API(라이브러리 제공 API, 언어 제공 메소드 등)에서 실행될 작업을 사용자(프로그래머) 쪽으로 넘기는 것

---

📣 문제 인식

좋은 프로그래밍 방식 중 하나는 보편적인 기능에 추상화 계층을 제공하고 그것을 재사용하도록 하는 것이다.

다음과 같은 예시를 들 수 있겠다.

function calculator(a, b, option) {
  switch (option) {
    case "add":
      return a + b;
    case "sub":
      return a - b;
    case "mul":
      return a * b;
    case "div":
      return a / b;
    default:
      return 0;
  }
}

console.log(calculator(1, 5, "sub"));

만약 계산 작업을 하는 기능을 재사용성을 위해 다음과 같이 만들었다고 해보자. 재사용 측면에서 충분히 제 기능을 하는 함수이지만 몇 가지 단점이 있다.

우리가 몇 개의 기능을 더 추가한다고 가정해보자. 각각 a와, b를 제곱해서 더하는 것, 그리고 a와 b의 절댓값을 구하는 기능을 추가해보자.

function calculator(a, b, option) {
  switch (option) {
    case "add":
      return a + b;
    case "sub":
      return a - b;
    case "mul":
      return a * b;
    case "div":
      return a / b;
    case "power":
      return a ** 2 + b ** 2;
    case "abs":
      return Math.abs(a - b);
    default:
      return 0;
  }
}

console.log(calculator(3, 6, "power"));
console.log(calculator(1, 5, "abs"));

다음과 같은 형태로 기능이 수정될 것 같다.

벌써부터 나쁜 냄새가 풀풀 풍긴다. 기능을 추가하면 할수록 함수는 거대해지고, 그것을 사용하는 사용자 또한 함수의 사용법을 익히는 데 부담을 느낄 것이다.

당연히 유지보수 측면에서도 안 좋아지기 때문에, 요구 사항을 모두 반영하기에는 이런 구조가 좋은 방식은 아니다.

---

🔑 개선

function IOCCalculator(a, b, callback) {
  return callback(a, b);
}

console.log(IOCCalculator(5, 6, (a, b) => a + b));
console.log(IOCCalculator(5, 6, (a, b) => a ** 2 + b ** 2));

위와 같은 구조로 개선했다.

사실 개선이라고 말하기는 조심스러운 부분이지만, 만약 추가적인 기능을 제공한다면 해당 함수 내에 로직을 추가해 로깅이나, validation 체크 등 다양한 기능을 제공할 수 있다.

function IOCCalculator(a, b, callback) {
  console.log(`${a} calc ${b} = ${callback(a, b)});

  return a < b ? callback(a, b) : 0;
}

console.log(IOCCalculator(5, 6, (a, b) => a + b));
console.log(IOCCalculator(5, 6, (a, b) => a ** 2 + b ** 2));

이런 방식이 바로 제어의 역전이다. 제어의 역전이라는 말이 조금 어렵다. 왜 그런 이름으로 부르는 지 살펴보자.

---

😥 일반적인 프로그래밍

기본적인 프로그래밍에서 프로그램의 흐름은 명령형으로 진행된다.

예를 들어 종이 비행기를 접는다고 했을 때를 생각해보자.

1. 종이를 반으로 접고 편다.
2. 위쪽 모서리를 중앙 선에 맞춰 삼각형 모양으로 접는다.
3. 위쪽 모서리를 접혀있는 상태에서 한번 더 접는다.
4. 종이를 반으로 접는다.
5. 양 옆을...

이처럼 모든 동작들을 하나하나, 그리고 순서에 맞춰 수행해야한다.

이렇게 세부적인 요소들을 모두 언어를 작성하는 쪽에서 수행하는 게 일반적인 프로그래밍의 흐름이다.

위의 예시에서 초기 calculator가 그런 방식이다. 이런 구현의 단점은 모든 usecase에 대응할 수 있도록 기능을 작성해야 한다는 것이다.

또한 추후 기능을 개선할 때, 불필요하다고 생각되는 기능을 빼고 싶어도 쉽지 않다. 기존에 해당 기능을 사용하는 부분이 있었다면 문제를 발생시키기 때문이다.

하지만 수행되어야 할 기능의 일부분을 사용자(프로그래머) 측으로 넘긴다면 다양한 usecase에 효율적으로 대응할 수 있다.

코드를 작성했지만 그것을 실행하는 것은 호출한 모듈이 되는 것이다. 이렇게 일반적인 흐름에서 벗어난 형태의 설계를 제어의 역전(Inversion of Control)이라고 한다.

즉 사용자가 작성한 코드가 해당 기능의 일부분으로 작동하게 되는 것이다.

😀 프론트엔드에서의 제어의 역전

생각보다 제어의 역전은 흔하게 썼다. 단지 그것이 제어의 역전이라는 개념인지는 모르고 있었지만... map, filter 등 다양한 배열 메소드 또한 제어의 역전 패턴이라고 볼 수 있다.

const Board = ({ author, title, content, date }) => {
  return (
    <div>
      <div>작성자: {author}</div>
      <div>
        제목: {title}, 날짜 {date}
      </div>
      <div>내용: {content}</div>
    </div>
  );
};

function App() {
  const { author, title, content, date } = {
    author: "lee",
    title: "My simple Board",
    content: "Hello this is my First Board",
    date: "today",
  };
  return (
    <div className='App'>
      <Board author={author} title={title} content={content} date={date} />
    </div>
  );
}

다음과 같은 컴포넌트가 있다고 해보자. Board 컴포넌트의 문제점을 찾아보자.

Board 컴포넌트는 props로 속성들을 받아 그것을 렌더링하고 있다. 이때 문제는 어떤 props가 들어오는지 정확히 알아야 하고, 만약 새로운 props를 추가해야 한다면 사용 측과 컴포넌트 측 모두 그것을 반영해야한다는 것이다.

const Board = ({ author, title, content, date, onClick }) => {
  return (
    <div
      onClick={() => {
        onClick(author);
      }}
    >
      <div>작성자: {author}</div>
      <div>
        제목: {title}, 날짜 {date}
      </div>
      <div>내용: {content}</div>
    </div>
  );
};

function App() {
  const { author, title, content, date, onClick } = {
    author: "lee",
    title: "My simple Board",
    content: "Hello this is my First Board",
    date: "today",
    onClick: () => {
      alert(`Hello!`);
    },
  };
  return (
    <div className='App'>
      <Board
        author={author}
        title={title}
        content={content}
        date={date}
        onClick={onClick}
      />
    </div>
  );
}

만약 컴포넌트의 요구사항이 달라져 특정 요소들을 추가해야한다면 위와 같이 수정할 수 있다. 예시에서 클릭 이벤트와 조회수를 추가했다.

벌써부터 심상치 않은 느낌이 든다. 이렇게 구현한다면 props의 길이가 점점 늘어나 코드가 괴물이 되어버릴 것 같다.

지금은 그나마 단순한 구조이지만, 특정 props 조건에 따라 props들의 위치가 바뀐다던지 그런 부분들을 상상해보면 끔찍한 코드가 만들어질 것이 분명하다.

const Board = ({ onClick, children }) => {
  return (
    <div
      onClick={() => {
        onClick();
      }}
    >
      {children}
    </div>
  );
};

function App() {
  const { author, title, content, date, views, onClick } = {
    author: "lee",
    title: "My simple Board",
    content: "Hello this is my First Board",
    date: "today",

    views: 15,
    onClick: () => {
      alert(`Hello!`);
    },
  };
  return (
    <div className='App'>
      <Board onClick={onClick}>
        <div>작성자: {author}</div>
        <div>조회수: {views}</div>
        <div>
          제목: {title}, 날짜 {date}
        </div>
        <div>내용: {content}</div>
      </Board>
    </div>
  );
}

이런 구조는 어떨까? 이 코드와 위에 있는 IOCCalulator의 구조를 비교해보자. 비슷한 구조라고 느껴진다. IOCCalulator처럼 Board 컴포넌트는 받은 children을 렌더링할 뿐, 그것이 무엇인지는 관심사가 아니다.

단점?

하지만 이런 방법은 좋은 점만 있는 건 아니다. 만약 같은 Board인데 author와 views가 홀수 번 째 Board에서만 위치가 바뀐다고 생각해보자. 매번 상황에 따라 children으로 들어갈 요소를 바꿔줘야한다.

물론 이런 것도 충분한 추상화 계층을 제공해서 해결할 수 있다. OddBoardContent, EvenBoardContent 등의 컴포넌트를 만들어 재사용하면 그만이다.

render props

const Counter = (props) => {
  const [count, setCount] = useState(0);

  return (
    <div onClick={() => setCount((prev) => prev + 1)}>
      props.children
    </div>
  );
};

render props 또한 IoC 패턴으로 사용할 수 있다. Counter 컴포넌트의 count를 children에 어떻게 전달할까? count가 업데이트될 때마다 children도 같이 업데이트 해보자.

const Counter = (props) => {
  const [count, setCount] = useState(0);

  return (
    <div onClick={() => setCount((prev) => prev + 1)}>
      {props.children(count)}
    </div>
  );
};

function App() {
  const { author } = {
    author: "lee",
  };

  return (
    <div className='App'>
      <Counter>
        {(count) => {
          return (
            <>
              <div>작성자: {author}</div>
              <div>{count}</div>
            </>
          );
        }}
      </Counter>
    </div>
  );
}

children에 함수를 전달하고 그것을 Counter 컴포넌트가 호출하고 있다. 이런 형식으로 작성한다면 매 state 업데이트마다, children 함수를 재실행한다.

그런 만큼 children의 렌더링 비용이 비싸지면 안 되기 때문에 적절하게 코드를 나누거나 사용 자체에 대해 고려해봐야한다.

후기

제어의 역전 개념에 대해 이해가 잘 되지 않아서 글을 작성하는데 오랜 시간이 걸렸다.

사실 이 패턴은 알게 모르게 많이 사용하고 있다. 당장 리액트의 전체적인 작동만 봐도 제어의 역전이다. 우리는 단순히 JSX와 로직들을 작성할 뿐이지만, 리액트가 제공하는 기능들을 보자.

V-DOM, 리렌더링, props 등 리액트 내부에서 디자인 된 기능들이다. 그것이 어떻게 동작하는지는 우리의 관심사가 아니다. 제어의 역전은 조금 더 유연한 추상화인가?

누군가 나에게 제어의 역전에 대해 묻는다면 대답은 할 수 있겠지만, 내 눈빛은 확신에 차있지 못할 것 같다.

https://kentcdodds.com/blog/inversion-of-control
https://www.lorenzweiss.de/inversion_of_control_with_react_components/
https://brunch.co.kr/@finda/556

위 문서들을 참고했습니다.