Inversion of Control(제어 역전)

이전 게시물 의존성 역전 원리(Dependency Inversion Principle) 관련 용어에서 Inversion of Control(제어 역전, 이하 Ioc)에 대해 간단히 정리했습니다. 비록 짧지만 제가 알고있는 범위에서 가장 중요한 부분은 설명이 되었다고 생각합니다. 물론 IoC가 쉽게 이해될 수 있는 개념은 아니지만 제가 이해하는 것보다 훨씬 어렵게 생각하는 반응들을 목격하고 혹시 내가 IoC를 오해하고 있는 것은 아닌가 하는 의문과 함께 내 이해에 대한 좀 더 자세한 기록을 남겨야겠다는 생각이 들었습니다.

Reflectionprojection

이 글은 IoC라는 용어에 대해 고민하지만 프로그래머에게 동작하는 코드보다 중요한 것은 없습니다. 단지 용어가 가진 의사소통 수단으로서의 기능에 도움을 주는 것이 목적입니다.

잠깐 개인적인 얘기를 하면, 저는 오래 전 학창시절부터 프레임워크를 만들어왔습니다. 처음엔 데이터 시각화를 지원하는 라이브러리를 만들다가 자연스럽게 데이터 시각화 프레임워크를 만들게 되었습니다. 그런데 프레임워크를 만들기 시작했던 당시에 막연하게 전에 만들던 형태와는 다르다는 생각은 했지만 라이브러리와 프레임워크에 대한 분류 기준을 가지진 못했습니다. 하지만 둘은 분명 차이가 있다고 생각했고 그 차이를 명확하게 설명할 방법을 알고싶었죠. 안타깝게도 주변에서 접했던 몇 가지 기준은 답답함을 풀어주지 못했습니다. 그러던 중 IoC라는 개념을 접하게되었고 10년 이상 묵은 의문 하나가 풀렸습니다.

저에게 IoC를 처음으로 설명한 것은 Martin Fowler의 글 중 한 섹션이었습니다. 일부 내용을 살펴보겠습니다.

Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels.

“IoC는 프레임워크의 일반적인 특성이기 때문에 컨테이너(원 표현은 ‘lightweight container’이지만 문서 전반부에 PicoContainer나 Spring을 지칭한다고 언급했기 때문에 ‘컨테이너’라고 표현해도 무리가 없다고 판단합니다.)가 IoC를 사용하기 때문에 특별하다고 말하는 것은 내 차는 바퀴를 가졌기 때문에 특별하다고 말하는 것과 같다.”

When I first ran into inversion of control, it was in the main control of a user interface.

“처음 IoC에 뛰어들었을 때, 그것은 사용자 환경의 주 제어였다.”

순차적 명령 기반의 응용프로그램과 그래픽 사용자 환경 응용프로그램의 명령 흐름이 역전됨을 말합니다.

For this new breed of containers the inversion is about how they lookup a plugin implementation.

“이 컨테이너의 새로운 등장에 있어 역전은 어떻게 플러그인 구현체를 찾는지에 대한 것이다.”

Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

“IoC는 너무 일반적인 용어라서 사람들이 혼동한다. 여러 IoC 주창자들과의 많은 토론 끝에 우리는 Dependency Injection(의존성 주입, 이하 DI)이란 이름에 다다랐다.”

앞서 언급된 응용프로그램 명령 흐름의 예가 보여주 듯 IoC는 컨테이너(IoC 컨테이너)에 종속된 용어(혹은 개념)이 아니라는 의미입니다. 여기서 자칫하면 컨테이너와 DI가 동일 개념인 것으로 오해될 수 있는데 Fowler의 글은 이후 그렇지 않음을 설명합니다.

자, 이것이 제가 처음으로 이해한 IoC였습니다. 이후 다른 IoC에 대한 설명을 접할 때에도 제가 가진 지식과 충돌하는 부분은 거의 없었습니다. 예를 들면 위키피디아의 영문 IoC 페이지가 그렇습니다. 이 페이지의 중간쯤 이런 문장이 있습니다.

Software frameworks, callbacks, schedulers, event loops and dependency injection are examples of design patterns that follow the inversion of control principle, although the term is most commonly used in the context of object-oriented programming.

가끔 IoC를 Dependency Inversion Principle(의존성 역전 원리, 이하 DIP)와 동일하게 얘기하거나 DIP를 위한 하위 개념으로 얘기하는 경우가 있는데 여기에서 IoC에 대한 혼동이 야기됩니다. 아마도 DIP를 학습하는 과정에서 IoC를 접하게 되어 이런 오해가 발생하는 것이 아닌가 싶습니다. 혹은 IoC 컨테이너를 ‘IoC를 따르는 컨테이너’가 아니라 ‘IoC를 위한 컨테이너’로 인식하는 것일지도요. 사실 이런 오해를 하지 않으면 IoC는 그리 어려운 개념은 아닙니다.

정리하면 IoC는 코드 흐름이 전통적인 방식에서 역전되는 것을 의미하는 일반적인 용어입니다. 이것이 핵심입니다. 설령 OOP(Object-oriented programming, 개체지향 프로그래밍)나 DIP와 관련되어 IoC가 적용되는 디자인 기법들이 주목을 받을지라도 IoC는 DIP와 동일하거나 하위 개념이 아닙니다.

제 글과 다른 의견이 있으시다면 댓글로 남겨주세요.

Advertisements

Inversion of Control(제어 역전)”에 대한 1개의 생각

  1. 핑백: 2016년 7월 1차 스크랩 – jundols.com

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중