뒤늦게 토를 달긴 좀 그렇긴 합니다만, 사실 이문제는 모두들 PL 첫시간에 배우는 Binding Time 문제라 볼 수 있죠. 당연히 런타임에 바인딩이 가능해지도록 만들수록 유연성은 늘어나지만 반대 급부로 잃는것도 많죠. 전통적인 방식은 알고리즘(또는 코드)은 정적으로 바인딩하고, 데이터는 동적으로 바인딩 해왔지만, 그러다 보니 한계가 있는 부분들이 있어서 여러가지 다른 기법이 사용된 것으로 볼 수 있을겁니다.

결국 이건 어디까지를 DI로 볼꺼냐의 문제라 봅니다. 자바같은 경우 대부분 객체/클래스단위로 의존성을 지정할 수 밖에 없으니까 인터페이스를 사용해 프로그램을 짜고 DI로 실제 적용될 클래스를 지정하는 것이지만, 루비같은 경우 쓰는쪽에서 마음대로 제공하는쪽을 오버라이드할 수 있으니 그런 형태가 되는것 뿐이죠.

좀 더 공격적으로 이야기하자면, DHH도 디펜던시를 주입했죠.

Time.stub(:now) { Time.new(2012, 12, 24) } article.publish! assert_equal 24, article.published_at.day

좀 억지같다고 DHH는 주장할 지 모르겠만, 위 Time.stub(:now)가 바로 그거라면 그거죠. :now라는 메소드에 블럭을 지정해 블럭 호출을 가로챈건데, 이게 DI아니면 대체 뭐란 말인가요? ^^;;

다만, 루비에서는 DI시 좀 더 유연성이 있으므로 굳이 따로 클래스를 정의하거나 할 필요는 없겠지만, 용어만 다를 뿐이지 저것도 결국 DI와 같은 짓을 하고 있는거죠. 제 생각엔 DHH가 좀 공격적인 제목을 붙인것 같습니다. 아마도 루비로 개발하면서 자바와 같이 딱딱한 언어에서 사용하는 패턴이 널리 활용되는걸 막아보려는게 의도가 아닐까요? 언어 특성에 따라 같은 목적을 가지더라도 다른 형태의 해결책을 사용할 수 있어야 하는게 당연한거니까요.

@enshahar 저도 ruby를 깊이 있게 사용해 보지 않아서 아직 그 실체를 잘 느끼지 못하고 있어요. 지금 학생들과 ruby 스터디하고 있는데 이 DI에 대해서 다양한 방식으로 구현해 봐야겠어요.

모두들 좋은 의견 감사요. DI에 대해서 다른 시각을 가질 수 있는 좋은 답변들이었습니다. 역시 무림에는 뛰어난 고수들이 많다는 것을 다시 한번 느끼네요.