IoC 메커니즘 중 의존성 검색 대비 의존성 주입의 큰 장점 중 하나는 개발자가 작성한 빈이 자신을 관리하는 컨테이너가 어떻게 구현되어 있는지 알 필요가 없다는 점입니다. 생성자나 수정자로 의존성을 주입 받는 빈에게 스프링 컨테이너는 구글 주스(Guice)나 피코 컨테이너(Pico Container)의 컨테이너와 동일합니다. 하지만 특정 환경에서는 몇 가지 다른 이유로 빈에서 컨테이너에 접근해야만 하며, 이에 필요한 의존성을 의존성 주입으로 공급받아야 합니다. 이런 예로 셧다운 후크를 자동으로 구성하는 빈을 들 수 있는데 이 빈은 ApplicationContext에 접근할 수 있어야 합니다. 또한, 다른 예로 빈이 컨테이너에서 어떤 이름(현재 ApplicationContext 내에서 부여된 빈 이름)으로 사용되는지 알아내 이를 기반으로 하는 부가 처리 작업을 수행해야 하는 것을 들 수 있습니다.

사실 이런 기능들은 스프링이 내부적으로 사용하려는 용도로 만들어졌습니다. 빈 이름에 비즈니스의 의미를 부여하는 것은 일반적으로 잘못된 생각이며 비즈니스 의미를 갖게 하려고 빈 이름에 인위적으로 조작하면 스프링 구성 시 문제를 유발할 수 있습니다. 하지만 애플리케이션 로그를 남길 때 런타임에 빈 이름을 알아낼 수 있다면 매우 유용하다는 사실을 알고 있습니다. 빈 이름을 로그 메시지에 포함하면 문제가 발생했을 때 에러로 발생한 메시지와 정상적인 로직에서 발생한 메시지를 구분하는 데 도움이 됩니다.