들어가며

오늘 팀원들과 프론트에서 컴포넌트를 어떻게 만들면 좋을까에 대해 얘기하다가 IoC(Inversion of Control)에 대한 얘기가 나와서 적어둠!

나는 소프트웨어공학 수업을 안들어서 그런가 IoC가 react에서 컴포넌트를 작성할 때 사용하는 패턴이라고만 생각했는데 알고보니 이게 소프트웨어공학에 이미 대문짝만하게 있던 개념이었던 것.

IoC(Inversion of Control)란

위키를 참고해서 알아보았다.

Inversion of Control (IoC)는 소프트웨어 공학에서 사용되는 디자인 원칙 중 하나로, 프로그램의 사용자 정의 코드가 제어 흐름을 프레임워크와 같은 외부 소스에서 받는 구조를 의미합니다. 여기서 “제어의 역전”이라는 용어는 역사적인 배경을 가지고 있습니다. 일반적인 절차적 프로그래밍에서는 프로그램의 사용자 정의 코드가 재사용 가능한 라이브러리를 호출하여 특정 작업을 수행합니다. 하지만 IoC가 적용된 구조에서는 그 반대로, 프레임워크나 외부 소스가 사용자 정의 코드를 호출합니다.

내가 이해한 바로는 전통적으로 프로그램에서 제어 흐름은 원래 개발자에게 있었다. 개발자가 어떤 흐름으로 동작할지 짜다가 특정 부분에서 편의를 위해 외부에서 가져온 코드 덩어리를 쓰는 느낌
근데 이제 점점 사람들이 이런 코드 덩어리들은 재사용할 수 있겠는데 하고 모듈화하고 하다보니 라이브러리가 되고 거기서 더 재사용하게! 더 편하게! 더 개발하기 간단하게! 채찍질 하는 것 그러면 이제 외부에서 가져온 코드가 전체 프로그램의 대다수를 구성하게 되고 제어의 흐름을 다 맡아버리게 되어버리고 이거 이거 프로그램 만들 때 편하잖아~~ 마치 뼈대같잖아 해서 이것을 프레임워크라고 하는게 아닐까
참고한 라이브러리와 프레임워크 차이에 대한 블로그

정신차려보니 이제 제어 흐름이 프레임워크에 다 넘어간 것. 개발자가 "아 이런 부분은 이렇게 하는게 더 나을 것 같은데?"생각해도 어쩔 수 없음! 할 수 있는건 중간중간에 개발자가 프레임워크한테 "야 이런 상황일 때는 이런 일 해줘"하고 일부분에 대해서만 개발자가 직접 짠 코드를 실행해달라고 하는 상황이 된거 아닐까. 주객이 전도된게 IoC인듯

약간 요런 예시도 맞을까나
A하면 B해줘라는 상황이 있을 때
전통적으론 개발자가 "A하면"에 해당하는걸 제어하고(개발하고?) "B해줘"를 외부 코드를 썻다면
IoC에서는 "A하면"에 해당하는걸 외부 코드(프레임워크)가 제어하고 "B해줘"를 개발자가 개발하는...

그리고 위키 보면 이후에

IoC는 GUI(그래픽 사용자 인터페이스) 환경이 등장한 이후 애플리케이션 개발 프레임워크에서 널리 사용되었고, 현재도 GUI 환경과 웹 서버 애플리케이션 프레임워크에서 계속 사용되고 있습니다. IoC를 통해 프레임워크는 애플리케이션 개발자가 정의한 메서드를 이용해 확장 가능해집니다.

이라고 하는데 GUI 이전엔 IoC 디자인 원칙이 잘 안 사용되었나 하는 생각이 든다.
나중에 더 찾아봐야겠다. cli 환경에서도 프레임워크는 있었을거 같은데 암튼
그러고보니 위키엔 IoC is a design principal이라는데 principal이란 말이랑 pattern이란 말이랑 차이가 있나 궁금함

IoC 개념의 확장

그리고 더 읽어보면 Java에서는

“Inversion of Control (IoC)“라는 용어는 원래 소프트웨어 아키텍처에서 제어 흐름의 반전을 의미하지만, Java 프로그래밍 커뮤니티에서는 별도로 “의존성 주입(Dependency Injection)” 패턴을 설명할 때도 사용됩니다.
의존성 주입은 객체가 필요한 의존성(즉, 다른 객체나 서비스)을 직접 생성하거나 관리하지 않고, 외부에서 주입받는 방식입니다. 예를 들어, 어떤 클래스가 데이터베이스 연결이 필요하다면, 개발자가 해당 클래스 내부에서 직접 데이터베이스 연결을 생성하는 대신, 프레임워크가 이 연결을 생성하고 해당 클래스로 주입해 줍니다. 이렇게 되면 클래스는 데이터베이스 연결을 “어떻게” 생성할지 알 필요가 없고, 단지 “무엇”을 사용할지만 알면 됩니다.
즉, 원래의 IoC 개념이 애플리케이션 코드의 실행 시점을 프레임워크가 제어하는 방식(예: 이벤트 핸들러 호출)이라면, Java 커뮤니티에서의 IoC는 프레임워크가 애플리케이션 객체들의 의존성을 관리하고 주입하는 방식으로 확장되어 사용되고 있습니다.

IoC란 개념이 이렇게 쓰인다고 한다.
이것도 내가 이해한 바로는 데이터를 연결하는 제어의 흐름이 원래 class에 있었는데 이걸 class의 의존성을 줄이려고 매개변수로 주입하는 형태로 바꾸면서 데이터 연결에 대한 제어의 흐름이 class에서 외부로 주객전도된거라 볼 수 있는듯.

Spring에서는 또 이렇게 쓰이는듯

스프링 컨테이너가 필요에 따라 개발자 대신 Bean들을 관리(제어)해주는 행위

참고한 블로그
여기선 개발자가 가지고 있던 제어의 흐름이 스프링으로 가서 IoC라고 하는듯 원래 의미랑 비슷하다

React에서는

리액트로 개발을 하다 보면 컴포넌트가 기본 기능대로만 동작하기보다는, 원하는 방식으로 확장되어 동작하길 바랄 때가 종종 있습니다. 이럴 때 우리는 IoC(Inversion of Control) 즉, 제어 역전 패턴을 통해 컴포넌트를 사용하는 개발자에게 컴포넌트의 제어권을 넘겨줌으로써, 개발자가 원하는 대로 컴포넌트를 컨트롤하도록 할 수 있습니다.

참고한 블로그
컴포넌트가 제어하던걸 개발자가 뺏어오는걸 IoC라고 하는듯

정리하면

IoC의 원래 의미는 제어의 흐름이 개발자한테 있던게 프레임워크로 넘어간 거였는데 React나 Java의 예시를 보면 제어의 흐름을 다시 개발자가 가져오는 걸 의미하는 것 같다.

그럼 React의 경우 원래 IoC의 개념을 살리자면 제어의 역전의 역전인가

역전재판하고싶다.

[OneStep] 혹시 할 일을 미루고 계시나요?

왜 사람들은 할 일을 미룰까?

사람들이 할 일을 미루지 않도록 도와줄 수 있는 방법이 있을까?

주변 지인들 중에서도 이 문제로 고통받고 있는 사람들이 많았고, ‘지연 행동’이라는 개념을 접하고 관련 활동을 하시는 전문가 분과 인터뷰도 하면서 본격적으로 이 문제를 조사하게 되었어요.

그리고 저희 팀이 깨달은 사실은, 지연 행동을 단순히 한 사람의 게으름만으로 볼 수는 없다는 거였어요.

지연 행동이 일어나는 원인들에는 심리적, 환경적인 여러 요인이 있었는데, 저희는 이 중에서도 할 일이 너무 많고 크게 느껴져서 섣불리 시작하지 못하는 사람들에게 집중하기로 했어요.

그렇다면 할 일을 작게 나눠주면 어떨까?

‘티끌 모아 태산이다’라는 말이 있는 것처럼, 막막해 보이는 태산 같은 일들을 티끌로 나눠준다면 어쩌면 사람들이 더 쉽게 시작할 수 있지 않을까?

저희 서비스 OneStep은 그 질문에서부터 시작했습니다.

그리고 이 문제에 동감하는 팀원들이 모여 개발을 이어가고 있습니다.
저희 서비스는 현재 구글 플레이 스토어에 런칭되어있는 상태입니다. 추가적으로 사용자들이 원하는 세부적인 기능이나 개선점이 있다면 바로 반영해서 사람들의 불편함을 해결해 보려고 합니다.

많이 이용해주세요.
구글 플레이 스토어

디스콰이엇에도 첫 글 올렸는데 봐주세요.
👉 디스콰이엇 첫 글 👈