철수네 소프트웨어 세상 [본점]

소프트웨어와 관련이 있다면 뭐든지 – I no longer work for Microsoft.

간만에 유레카를 외쳤다(IoC)

with one comment

최근 회사에서 이런 저런 문서들을 읽다가 "유레카!”를 외치게 되었다(벗고 뛰쳐나가지는 않았다). 젠장. 답은 눈앞에 있었는데도 불구하고 그 주변만 수년간 헤메고 있었던 것이었으니, 속 시원하고 한편으로는 내 능력이 한탄스럽기도 하고. 아무튼 유레카에 이른 그냥 짧은 談을 적어본다. (아쉽게도 교훈적인 이야기는 아니다^^)

SoC(Separation of Control), IoC(Inversion of Control)이라는 말을 알게 된 것은 거의 9년전 Apache의 Avalon과 Cocoon 프로젝트를 쫓아다니면서였다. (정확히는 이를 도입한 Stefano Mazzocchi의 글을 읽고 나서겠지) 그때는 마치 하나의 패턴처럼 그냥 그냥 외우고 썼었지만, 정작 태생적인 Why를 이해하기 위해서는 역부족이었다. 교과서에 나오는 것처럼 텍스트에 적힌 Why를 이야기할 수는 있지만, 제대로 된 이해에서 오는 것은 아니었으니 사용할때마다 얼마나 답답했으랴. 사실 이를 사용함으로써 생기는 장점만으로도 사용할 이유는 충분하니까.

Martin Fowler에 의해서 그 구현들이 IoC라는 말보다는 DI(Dependency Injection)이 더 맞다는 제안이 커뮤니티에 받아들여져서 요즘에는 DI로 통하는데, 이 DI 컨테이너 혹은 런타임 혹은 프레임웍 혹은 패턴은 Java 진영에서는 흔히 프레임웍(Avalon, Spring등)으로 사용되지만, .NET 쪽에서는 패턴식으로는 많이 사용되더라도, 어떤 제품 프레임웍으로써의 사용례가 많지 않고 역사(?)가 (상대적으로) 짧다. Spring.NET, Castle, Unity, Structure Map(PicoContainer가 있을때는 PicoContainer.NET)등. 어차피 만든 사람들은 진영과 상관없이 왔다갔다 하는 사람들이기 때문에 어느 쪽이 더 우월하다 어쩌다 논쟁을 할 가치도 없지만, 그 프레임웍들이 이전 Java 커뮤니티처럼 사용되지 않았던 것은 사실이다.

딱 찝어서 그렇다고 할 수는 없지만, 대개 Java의 커뮤니티의 경우에는 자생적으로 기술들을 만들어 이것이 그대로 Java 커뮤니티에 다시 돌려지지만(사용되지만), .NET 커뮤니티의 경우에는 조금 다르게 자생적으로 만들어도 이는 직접 커뮤니티로 가지 않고 .NET 팀에 “피드백”으로 들어가 .NET 커뮤니티에 돌려지는 경향이 많다. 한마디로, Java에서는 좋은 것이 만들어지면 바로 프로젝트에서 사용하지만, .NET에서는 이것이 제품에 반영될때까지 사람들이 사용하지 않는다는 것이다. ASF등의 힘이 컸을지도. (점차 사람들이 교환(?)되면서 이런 성격도 점차 섞이고 있긴 하고 이를 타파하기 위한 노력도 굉장히 많다)

근래 .NET Framework의 BCL 드자이너인 Krzysztof Cwalina가 Managed Extensible Framework(MEF)이라는 것에 대해서 포스팅을 했었다. 그 글에는 마이크소프트 내에서 Framework을 확장하는 여러가지 기술들에 대해서 이야기하면서 DI(Dependency Injection)을 이야기한다. 마이크로소프트에서도 뭔가 공식적인 움직임을 만든다고 공식적으로 이야기한 것이다. (사실 ObjectBuilder나 근래 Unity라는 Application Block이 Pattern&Practice 팀에서 나왔고, 정확히 이야기하면 수년간 계속 연구중이다)

MEF를 만드는 팀은 (수십개의 큰 팀으로 이뤄진) 커다란 Division으로 치면 나와 같은 Division이다. 해서 이에 대한 정보를 얼마든지 볼 수 있다는 뜻. 참새가 방앗간을 지나칠 수 없듯이, 나도 역시나 찾고 열심히 읽어보기 시작했고…거기서 유레카를 외치게 된 것이다. 그것도 별 것 아닌 몇십페이지짜리 문서의 몇장짜리 짧은 단락에서 말이다. 당연하지만, 회사에서 뭔가를 하고자 하면 이에 대한 정당성이 명확하고 매니저에게 설득이 되어야 펀딩이 되고 할 수 있는 것이다. 따라서 이런 문서들이 넘쳐난다. 하니, 이런 문서에서 진주를 발견하는 일은 흔할 수도 있다고 할 수 있겠지.

소프트웨어를 공부하면서 이해해야하는 것들 중에서는 나뉘어져 그 구분을 이해해야하는 것들이 많이 있다. 쉽게 온라인/오프라인, 정적 언어/동적 언어, 런타임/컴파일 타임등등. 여기서 또하나 중요한 것은 이들이 둘로 나눠지는 이유를 아는 것 뿐만 아니라 이 둘이 궁극적으로 겹치거나 애매하거나 혹은 상관관계를 가지는 중간 영역이 커다랗게 있다는 것이다. 언제나 그렇다. 예를 들어 소프트웨어의 발전 과정에 있어서 템플릿이나 메타 프로그래밍처럼 강력한 무기라고 하더라도 컴파일 타임에 모든것을 하려는 C++시대만 계속 될 수만은 없는 노릇이고, Java/C# Generics나 Duck Typing이라는 것도 나와야 한다. 디스크에 있더라도 메모리로 올려지게 마련이다. 동적 형식(Type)이 다가 아니고, 정적 언어에서도 Type Inferencing이라는 형태로 흉내낼 수도 있다. 온라인이라도 Google Gears등처럼 오프라인 스토리지 형태가 필요한 것이다.

이런 것들을 이해하기 쉬운 방법 중 하나는 그 역사(History)를 이해하는 것이다. 어떤 사람이 어떤 이유로 그런 것을 사용했는가는 이해에 있어서 좋은 접근 방법이라고 생각한다. 역사는 그 필요를 보여주고, 필요에 의한 사용과 생성은 언제나 말이 된다. 역사는 또한 Trial & Error를 직접 겪지 않고도 보여주는 멋진 자료이기도 하다. 그리고 나는 이를 맹신하면서 따른다. 맹신하기에 이 역사에 어떤 이해하지 못하는 갭이 있으면 앙금으로 남는다는 것이 문제다. 이 IoC의 이해 문제도 이런 앙금이 있었지만, 간단한 연결고리에 대한 설명 몇 문구로 내 머릿속의 화룡점정畵龍點睛격이 된 것이다.

그게 다는 아니다. 거기다가 요즘 C#을 처음부터 꼼꼼하게 다시 공부하겠다고 Accelerated C# 2008을 정독하고 있기도 한데 여기서 5번째 챕터를 읽는 중이었고, 마침 이 챕터에 또 연관된 내용이 들어있기도 했다. 여하튼 이래저래 관련 내용들이 우연히 한 곳에 비슷한 시기에 모여 딱 들어맞았으니 외칠만도 했겠지. 별게 아닌데도 쓰여있는 내용이 아니라 그걸 통해서 여태껏 생각하지 못했던 뭔가가 떠올랐을때의 그 신기함이란.

이 간단한 것을 5년 전에 알았다면, 어땠을까. 인생의 각도가 0.2도 정도 바뀌지 않았을까. 뭐 그 정도 가지고라고 이야기해도 실상은 아마도 내 공부 방향이 바뀌었을지도 모를 일이고, 0.2도 정도는 가능하다고 생각된다. 알고나면 허무할지도 모르나, 알고자 하는 과정이 챌린징하다는 것이 지식의 묘미 중 하나일 것이다. 위대한 업적은 아니더라도 뭔가를 알게 된다는 것은 벤젠을 발견한 꿈이나 목욕탕에서 유레카를 외친 것과 다를 것이 없지 않을까. 유한한 인간에게 있어서 알기 위한 과정이 너무 오래 걸려서 탈이지.

유레카 한번은 외쳐줘야 고루한 회사 생활 할맛 나는게 아니겠나…모두 즐공 하시길.^^

Written by charlz

2008년 5월 2일 , 시간: 오후 10:35

Uncategorized에 게시됨

One Response

Subscribe to comments with RSS.

  1. 나도 Accrelerated c# 2008 지금 몇주째 읽고 있는지 모르겠음요… 어쨌든 좋은 책.

    goodhyun

    2008년 5월 3일 at 오후 1:24


답글 남기기

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

WordPress.com 로고

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

Twitter 사진

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

Facebook 사진

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

Google+ photo

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

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: