심한 입덧으로 아무런 활동을 못하는 아내 대신 집안 일과 평화 돌보는 일을 전담해야 하는 요즘은 정말 시간이 모자라 쩔쩔매며 살긴 하지만 케빈님의 요청(http://toby.epril.com/?p=972&cpage=1#comment-30083)을 무시할 수 없어서 조금만 적어보기로 한다.

얼마전 클린 코드 가이 엉클 밥이 Dependency Injection Inversion(http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion)이라는 재밌는 글을 썼다. 제목이 의미심장한데, 내 생각으로는 "DI Framework Dependency Inversion”이라고 제목을 다는 것이 낫지 않았을까 싶다.

긴 얘기가 나오지만 핵심 주장은 이 것이다.

I don’t want framework code smeared all through my application. I want to keep frameworks nicely decoupled and at arms-length from the main body of my code.

I think Dependency Inversion is so important that I want to invert the dependencies on Guice! I don’t want lots of concrete Guice dependencies scattered through my code.

구글 주스의 튜토리얼에 나오는 예제를 가지고 예를 들어서 설명했는데, 엉클 밥은 아마도 DI 프레임워크를 사용하면 코드 곳곳에서 이렇게 Module(스프링이라면 XML이나 자바코드로 만들어진 통한 의존관계 메타정보)을 가지고 Injector(스프링으로 치면 ApplicationContext)를 만들어 그때 그때 Injector에게 getInstance(스프링이라면 getBean)을 호출해서 원하는 DI된 오브젝트를 가져와 사용해야 한다고 생각한 것 같다.

초 간단 예제만 가지고 SE의 개발 스타일로만 생각한다면 그럴지도 모르겠다. 아마도 엉글 밥은 DI의 원리인 DIP와 팩토리에 대해서는 잘 알고 있지만 프레임워크와 IoC컨테이너를 이용한 애플리케이션 개발에 대해서는 잘 모르는 듯 하다. 아무도 스프링이나 구글 주스를 가지고 이렇게 필요할 때마다 Object Factory(Injector)를 만들어 Service Locator처럼 사용하지 않는다. 애플리케이션 전체 오브젝트 그래프를 미리 메타정보에 설계해놓고 최소한의 엔트리포인트 오브젝트만 가져와 시작하면 그만이다. 이 예제에서 main이 바로 그런 엔트리포인트일 뿐이다. 보통은 서버에서 동작하므로 이런 코드마저 불필요하다. Front Controller Servlet등에서 URL로 들어온 웹 요청을 알아서 엔트리포인트 오브젝트에 연결해주기 때문이다. 대부분 싱글톤으로 미리 DI된 오브젝트들을 이용하면 되는 서버 애플리케이션이 아니라 그때 그때 필요한 새 오브젝트를 DI된 상태로 끌어오는 스타일이라면 쥬스의 Provider나  스프링의 ObjectFactory를 사용하면 충분히 프레임워크 의존적인 코드를 제거할 수 있다. Provider도 프레임워크 것이 아니냐고 깐깐하게 나온다면 임의의 팩토리 인터페이스만 주면 팩토리를 만들어 주는 스프링의 ServiceLocatorFactoryBean 를 사용하면 그만이다.

따라서 “main body of my code”에서 main() 메소드는 제외시켜야 한다. 그렇게 보면 구글주스를 쓴다해도 프레임워크 코드가 애플리케이션 코드 안에 등장할 필요는 없으니 엉클 밥은 쓸데없는 걱정을 했을 뿐이다. 간단한 튜토리얼성 예제를 보고 애플리케이션을 개발하는 스타일에 대한 오해가 있었던 듯. 물론 DI프레임워크를 저따위로 사용하는 개발자들도 없지는 않을 것이라고 보이긴 하지만 –_-;

 

그런데 한가지 남은 것이 있다. 바로 @Inject이다. 아무리 DI 프레임워크의 API가 코드에 등장할 필요가 없다고 하더라도 애노테이션은 남는다. 스프링처럼 XML DSL을 사용하면 상관없지만 최근 유행을 따라 애노테이션을 써버리면 코드에 프레임워크의 흔적과 정보가 남는다. 물론 @Inject에는 전혀 구체 의존관계에 대한 정보는 없으므로 DI원칙을 위배하는 것은 아니고, 애노테이션이 달렸다고 해도 프레임워크 없는 상황에서 사용할 수 없는 것은 아니니 프레임워크에 의존적인 코드라고는 말할 수 없다.

그래도 어떤 프레임워크를 사용하는지 노출된 것이 아니냐, 애노테이션이 달렸으면 POJO가 아니라고 우긴다면 뭐 그 말도 틀린 것은 아니라고 생각한다.

애노테이션에 의존관계 메타정보를 담는 방식을 선호하는 사람 – 구글주스를 만든 미친 밥(crazy bob)도 있고 애노테이션 방식을 도입 안하려고 오랜동안 발버둥쳤던 코드-프레임워크 불가지론자(framework agnostic) – 로드 존슨도 있다.

엉클밥이 지적한대로 코드 여기 저기에 DI 프레임워크 코드가 널려있는 것이 나쁘다는 것은 누구나 다 동의할 것이다. 코드가 구체적인 프레임워크에 의존하고 있는 관계를 역전시켜서 추상적인 인터페이스에만 의존하게 만들어야 하는 것은 당연한 일이다. 프레임워크는 가장 낮은 레벨에 있는 것이니 이를 상위 애플리케이션 코드가 의존하는 것은 DIP위반이다.

하지만 애노테이션으로 오면 좀 얘기가 달라진다. 애노테이션을 코드로 볼 것인가. 아니면 코드에서는 무시되는 단순한 부가정보, 코멘트 쯤으로 볼 것인가에 따라서 평가가 달라진다. private 필드주입처럼 기능적으로 코드에서는 불가능한 것을 하도록 만드는 애노테이션이 아니라면(구글 주스 예제처럼 생성자에 @Inject 애노테이션이 붙은 것) 이쯤에서 코드를 보는 미적인 감각에 따라 판단이 달라지는 것이 아닐까 하는 생각이 든다.

어떤 사람들은 코드에 @Inject니 @Autowired 같은 프레임워크의 애노테이션을 보면 불쾌해진다. 애노테이션이 덕지덕지 붙은 코드는 마치 리팩토링 안된 스파게티 코드처럼 느껴지는 것 같다. 코드가 프레임워크에 침범을 당한 것 같기도 하다. 반면에 어떤 개발자들은 그런 코드들이 자연스럽다. 심지어 코드만으로는 제대로 사용이 불가능한 setter없는 필드주입에 애노테이션이 붙은 것도 오히려 깔끔하고 좋은 코드로 보인다.

켄트 벡이 구현패턴 책에서 말했던 것처럼 코드를 보는 두뇌는 딱딱한 논리적인 사고보다는 미적인 감각에 의해서 영향을 받을 때가 많다. 켄트 벡은 미학(Aesthetics), 미적인 감각(aesthetic sense)에 대해서 많은 관심이 있고 이에 대해 자주 언급한다. 코드를 볼 때 느끼는 미적인 인상은 코드의 품질에 대한 매우 중요한 피드백이라고 설명하기도 한다. 켄트 벡이 굳이 아름다운(beautiful) 이나 좋은 (good), 깔끔한(clean) 코드라고 하지 않고 Y군과 같은 이들은 거부반응을 일으키는 미학(Aesthetics)과 같은 용어를 쓴 이유는 코드에서 미적인 감흥을 얻는 이유와 과정이 그리 단순하지 않기 때문이 아닐까 싶다. 미학에 대해서는 그다지 아는 바가 없지만 미의 본질에 대한 논쟁이 끊임없이 진행되고 있다는 정도는 알고 있다.  나는 미를 느끼는 상당한 이유는 대상이 가진 본래의 성질 보다는 학습된 지식 또는 경험 때문이라고 생각한다.

코드를 볼 때 느끼는 아름다움도 마찬가지가 아닐까 싶다. 어떤 이들은 의도를 잘 나타내며 세분화된 메소드를 가진 코드에서 매력을 느낀다. 하지만 어떤 이들은 그런 코드를 보면 현기증을 느낀다. 오히려 길지만 한 눈에 흐름을 볼 수 있는 코드가 더 매력적이라고 느끼기도 한다. 상속이나 합성도 마찬가지다. 확장성과 유연성에 따라서 잘 분리되고 설계된 코드를 보면 감탄을 하고 멋지다고 생각하기도 하지만, 그런 코드가 오히려 더 지저분하게 느껴지는 사람도 있다.

나는 이런 차이가 경험 때문에 발생한다고 생각한다. 내가 처음 SpringMVC코드를 분석할 때는 템플릿 메소드 패턴을 여러 단계에 걸쳐서 확장하며 만든 코드가 너무 복잡하다고 생각했다. 이해하기도 힘들었다. 그렇지만 그 패턴에 익숙해지도 나도 다 계층 템플릿 메소드 패턴을 적극 사용하기 시작한 이후로는 그런 비슷한 코드를 보면 오히려 시원해보이고, 이해도 훨씬 잘 된다. DI도 마찬가지이다. 다 계층 아키텍처, 상속과 다형성이 적용된 코드도 마찬가지였다. 나는 아직도 함수형 언어를 보면 깔끔하기는 커녕 어지럽다. 블록을 잔뜩 등장하는 루비 코드도 이해하기 힘들고 지저분해보인다. 아마 경험이 없기 때문이 아닐까 싶다. 근본적으로 용납할 수 없을만큼 문제가 있는 코드가 아니라면 충분한 경험을 통해서 익숙해지면 그런 코드를 볼 때 미적인 감각을 느낄 수 있을지도 모른다.

결국 @Inject와 같은 근본적인 코드 기능에 영향을 주지 않는 코드에 대한 거부감 또는 매력의 문제는 경험과 익숙함 또는 취향의 문제로 남겨두는 것이 좋을 것 같다. 아마 엉클 밥이 구글 주스로 1년간 수십만 라인의 코드를 개발하고 나면, @Inject도  “main body of my code”라고 느낄지도 모르겠다.

Related posts:

  1. JSR-330 Dependency Injection for Java 최종 승인

Facebook comments:

to “코드의 미학과 DI Inversion”

  1. Spot on with this write-up, I seriously believe that this site needs far more attention. I’ll probably be back again to see more, thanks for the advice!

  2. Your style is so unique compared to other folks I’ve read stuff from. Thank you for posting when you’ve got the opportunity, Guess I will just book mark this blog.

  3. This is the right website for anyone who wants to find out about this topic. You understand so much its almost tough to argue with you (not that I actually would want to…HaHa). You certainly put a fresh spin on a subject that’s been written about for years. Great stuff, just excellent!

  4. I’m impressed, I must say. Seldom do I encounter a blog that’s both educative and amusing, and without a doubt, you’ve hit the nail on the head. The issue is something which too few men and women are speaking intelligently about. I am very happy I found this during my hunt for something regarding this.

  5. Very good write-up. I certainly appreciate this site. Stick with it!

  6. Way cool! Some very valid points! I appreciate you penning this post and the rest of the site is extremely good.

  7. An interesting discussion is worth comment. I think that you ought to publish more about this topic, it may not be a taboo matter but usually people do not talk about these topics. To the next! All the best!!

  8. There’s certainly a great deal to find out about this subject. I like all the points you made.

  9. This page truly has all of the information I wanted concerning this subject and didn’t know who to ask.

  10. I blog often and I really thank you for your content. This great article has truly peaked my interest. I will bookmark your blog and keep checking for new details about once per week. I opted in for your RSS feed as well.

  11. I’m curious to find out what blog system you have been utilizing? I’m having some minor security problems with my latest site and I’d like to find something more safe. Do you have any recommendations?

  12. I really like it whenever people get together and share thoughts. Great website, continue the good work!

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha