[WIL] 셋째주 회고 - IoC, Bean, DI

벌써 셋째주가 됐다.

생각보다 지치지 않고 열심히 하고 있는 내 모습이 조금 장하게 느껴진다.

하지만 이번주는 상당히 힘든 주였다.

여태까지 배워왔던 기본적인 개념들이 뭉쳐서, 스프링이라는 하나의 뼈대에 하나씩 갖다 붙이면서 연결 짓기를 시작했기 때문이다. 대략적으로 공부했던 DI나, 컴포넌트의 개념들을 다 다시 공부해야 했다. 순서대로 공부하는 게 익숙해서, 이렇게 다시 돌아갈 때마다 꽤 좌절감을 맛보는 중이다. 틀리는 것과는 별개로, 빈 구멍을 만들어놓고 공부하는 방식이 익숙하지 않은 탓이다.

그렇지만 강의에서도 그렇고, 나 스스로도 끊임없이 강조하고 있는 건, 지금 이해가 안 되면 나중에 다시 돌아와서 하면 된다는 것이다. 학교 공부처럼 시간이 많은 것도 아니고, 방대한 분량의 스프링을 지금 완벽히 이해하려고 하면 지쳐버리고 말 것임이 틀림없다. 내가 천재도 아니고...오히려 이번 기회에 깨달은 건데, 시간 차를 두고 여러 번을 봐야 이해가 더 쉬운 듯 하다. 이것도 모르고 한 번 보고 치우면서 살았으니 얼마나 오만한 인생이었나...

어쨌거나 이런 방식으로 공부하다 보면, 계속해서 하나의 핵심 개념으로 돌아오게 되는데, 그건 DI의 개념이다.

DI는 개발자가 스스로 객체를 생성하는 대신, 스프링 컨테이너가 필요한 객체를 반환해 주는 것이다. 개발자가 컨트롤하지 않고 외부의 힘을 빌리므로 이것은 또 IoC(제어의 역전)이 발생한 것이다.

DI가 가능하려면 스프링이 객체의 존재를 알아야 한다. @Controller, @Service, @Repository 라는 어노테이션을 클래스에 달아주면, 스프링은 그 클래스가 스프링에 등록된 필요가 있는 객체라는 걸 알고, 스프링 컨테이너에서 생성/소멸을 관리한다. 스프링 컨테이너에서 관리되는 객체는 Bean이라고 부른다. 상기 어노테이션들은 스프링에 등록되는 것 외에 다른 역할을 가지고 있어, 모든 클래스에 달아주어서는 곤란하다.

스프링에게 등록될 필요가 있다는 걸 알려주려면, @Configuration-@Bean 이나, @Component 를 달아주는 방식으로도 처리할 수 있다. 또, DI가 필요한 곳에 @Autowired를 적어주면 여기다 주입하라는거구나, 하고 넣어줄 것이다.

다음주에는 이 개념에 추가적으로 더 얹어서, DI를 왜 쓰면 좋은지 더 명확하게 이해하는 것이 목표다. 이것을 이해하려면 다형성을 더 잘 이해해야 한다. 화이팅.