[항해99] 21일차 WIL

항해99 기간 동안 매니저님을 참 많이 괴롭혔다. 이 과정을 따라가지 못하고 있다는 불안감과 내가 제대로 가고 있는지에 대한 의심이 끊이질 않았다. 매니저님께 뺀질나게 하차해야 할 것같다고 인사를 드리러 같다가 매번 한번 더 해보자 라는 다짐을 하고 돌아왔다.

진상 수강생인 나의 상담 요청에 항상 차분하게, 진심으로 응해주신 최경식 매니저님께 감사드린다. 그 외에 참 많은 분들이 도와주셨다. 사실 TIL을 읽을 사람이 없다고 생각하고 TIL + 일기로 작성했는데 velog 통계 기능으로 포스트를 읽은 사람 수를 조회 할 수 있다는 사실을 알았다. 그리고 살짝 충격을 받아버렸다.

누군가 내 글을 읽고 있다!!

별안간 하차 다짐글을 읽으신건지 이전에 함께 팀원으로 만났던 분들이 혹시 도와줄게 뭐 없냐며 계속 메세지를 보내왔다. 하차 결심을 한 당일이 하필 내가 CS 스터디 발표를 할 차례라 맡은것은 깔끔하게 끝을 내야할 것 같아서 발표 후 생각 정리중에 주희님께서 오시더니 할 수 있다며 응원해주셨다. 매니저님과 항해99 동료들에게 말로 표현할 수 없을 만큼 감사한 한 주였다.

또한 폭풍이 휘몰아친것 같은 주였다. 삶은 항상 선택의 연속이라 했던가. 이렇게 내가 선택한 길을 끊임 없이 의심하고 있을때 별안간 좋은 제안들이 여기저기서 들어온 주이기도 했다. 끈질긴 조팀장님도 이번 한번 더 거절하면 본인도 자존심이 있으니 더이상 연락하지 않겠다며 협박성 전화를 하시고, 내가 생각하지도 못한 필드에서도 몇 군데 구미가 당기는 제안이 있었다.

하지만, 내가 퇴사를 결심한 가장 큰 이유 중의 하나는 연봉도 아니고 뉴스 헤드라인에 장식할 법한 끔찍한 사내 부조리도 아니었다(물론 끔직한 기억이 있지만 그만두는 판국에 시끄러운 일을 만들기 싫어 나한테만 말해보라는 조팀장님의 유혹도 뿌리치고 조용히 나왔다). 누군가는 철밥통 회사를 왜 그만 두냐며, 너무 아깝다며 이해하지 못한다고 했지만, 나는 한 번도 회사에서 내가 성장하고 있다는 느낌을 받지 못했다. 어느 순간부터 내가 맡은 일에 대한 인정을 받으면서도 나의 업무는 내가 충분히 해낼 수 있는 일이었고, 그 이상 잘하고 싶지도 않았다. 이런 루틴이 계속 반복되다 보니 나의 10년 20년뒤가 아득해졌다. 내가 결정한 일이고 내가 하고싶은 일이니 별 수 없었다. 조팀장님께도 죄송하다고 말씀드리고 싱숭생숭한 마음을 추스렸다.

이 글을 쓰기 몇시간 전까지 도저히 풀리지 않는 문제가 있었다. 슬랙 질문방에 내가 너무 자주 질문을 올린탓인지 누군가 댓글로 더이상 글을 올리지 말았으면 좋겠다는 뜻이었는지 어떤지 알수 없지만 절취선 ==== ==== 댓글을 남겨 상처 아닌 상처를 받고, 그 이후에는 글을 올리기가 조심스러웠다. 그래도 별 수가 없어서 고민 끝에 SpringSecurity 버전 문제에 관한 질문을 올렸고 감사하게도 고성빈 매니저님께서 SpringSecurity 자체 버전 말고 스프링 버전을 수정해보라 답글을 달아주셔서 해결할 수 있었다.

위의 질문 외에도 Spring MVC 관련 Request/Response 를 어떻게 구분하는것인지 도저히 이해가 되지않아 질문글을 올렸다가 SpringSecurity 부분이 더 급하다고 생각하여 해당 질문을 소심하게 삭제했다. 이것을 또 어떻게 보시고 경이님께서 잘 알려주신 덕분에 이해하고 넘어갈 수 있었다. 나는 왜 이걸 코드 뭉치 전체로 나눈다고 생각했는지 모르겠다. 항해99를 진행하면서 참 많은 분을 만났지만 경이님께도 배울점이 많다. 똑같이 비전공자에다 어려운것은 같을텐데 흔들림 없이, 너무나 차분하게 또 묵묵히 항해99를 이어나가는 태도가, 또 그 의지가 부럽고 배우고 싶다. 다음주 부터는 슬슬 과제를 시작해봐야겠다. 부디 평안한 한 주가 되기를 바래본다.

🌸 이번주에 배운것

DI(의존성 주입)

• 각 클래스마다 다른 클래스의 정보를 이용할 때 클래스 자체를 멤버 변수로 선언하고 new 선언을 하여 객체를 매번 생성하면 특정 클래서의 매개변수 정보가 바뀔 경우 new() 했을대의 매게 변수를 줄줄이 소시지로 바꾸어야한다.
• 이러한 문제는 클래스간 결합도가 매우 강해서 생기는 일이며 DI(의존성 주입)을 통해 어느정도 해결할 수 있다.
• 새로운 객체를 생성하는것이 아니라 클래스 자체를 참조형 자료형으로 매개변수로 활용하여 매번 객체를 생성하는것이 아니라, 해당 정보를 매개변수로 그대로 끌고 오는 방식이 DI(의존성 주입)이라고 이해했다.

IoC

• 이 부분은 조금더 공부를 해 봐야할 것같다. 무슨 컨셉인지 이해는 가는데 이걸 활용하는 강의를 따라가다가 어딘가 길을 잃은 기분이다.
• DI 를 위해서는 최초 객체 생성이 필요한데 이 부분을 어노테이션을 통해 스프링에게 일임한다는 컨셉 자체는 이해가 가지만, 아직 어떤 상황에서 어디에 어노테이션을 붙이는지가 이상하게 햇갈린다.

Bean

• @Component 선언을 하면 스프링이 알아서 객체를 생성해주고 이것을 Bean이라는 곳에 담는다.
• @Component 의 커버리지는 같은 패키지 내에서 이다.
• 의존성 주입을 위해서 흐름이 시작되는 객체에서 최초로 new(); 생성을 해준다는 부분을 이해했는데, 또 이것을 Ioc를 통해 자동으로 해준다는것이 참 간편은 해 보이는데 막상 또 어디에다 @Autowired를 해야하는지 머릿속이 복잡해진다. 조금더 공부해 보아야겠다.