[한화시스템 Beyond SW캠프] 12주차 회고

현황

지금 진행하는 팀 프로젝트를 포함해 많은 부분에서 흥미를 잃어버리고 있는 것 같다.

이유라고 할 만 한 것들은 다양해 보여서 딱히 뭐 때문이라고 할 수 없을 것 같다.

프론트엔드는 항상 내 약점이었어서 솔직히 자신이 없고 아마도 데브옵스 들어가면 리눅스 때와 마찬가지로 조금 살아나지 않을까 하는 작은 희망을 가져본다.

학습

사실상 수업 시간은 많지 않고 프로젝트를 위한 시간이 많이 주어졌다.

Spring Security

토큰이나 세션 등의 내용은 이미 알고 있는 내용이라 적당히 넘어갔다.

한 가지 신기했던건 JWT가 나온지 시간이 꽤 지났음에도 불구하고 Spring이라는 거대한 프레임워크에서 간단하게 적용할 수 있는 도구를 별도로 제공하지 않고 복잡하게 구현해야 했던 것이다.

(밑으로는 정보 보안 전공자의 과몰입이다.)

또 생각해 볼 점은 JWT는 여러가지 보완을 한다고는 하지만 결국 인증 정보를 클라이언트에게 넘기는 구조이기 때문에 세션을 완전히 대체할 수 없다. 쿠키에 올라 탔으면 올라 탔지, 세션과는 전혀 다른 분류의 기술인 것이다. 이것은 명백하다.

하지만 이후에 배운 MSA의 관점에서 생각했을 때 하나의 서비스가 여러 서버에서 동작하게 되고, 여기에 인증 정보를 세션으로 관리한다는 것이 매우 난해해 보인다. 그래서 인증 정보를 서버에서 관리하는 것이 아닌 클라이언트에 위임해서 해결하려는 것으로 보이는데, 강사님이 말씀하셨듯이 세션을 별도의 DBMS로 관리하는 대안이 있는데 굳이 JWT로 구현을 하는 것이 옳은 것인가? 하는 생각을 해보게 된다.

아, 그리고 JWT의 도입 취지? 당위성? 같은 것을 강사님이 말씀하실 때 로드밸런싱 과정에서 이미 인증을 받은 클라이언트를 세션이 없는 서버로 연결해주는 경우를 예로 들으셨는데, 로드밸런싱에는 다양한 알고리즘이 있다. 인증 방식을 세션으로 구현하는 경우에는 예시로 들었던 라운드-로빈 방식의 로드밸런싱은 절대로 사용하지 않는다. 해시 방식으로 세션을 맺은 서버에 계속 연결해주는 방법이 멀쩡히 있는데 예시가 너무 세션을 안좋게 몰아가는 것으로 보였다!

MSA

MSA는 유행이라고는 하는데 여기 와서 처음으로 제대로 철학?이나 구조를 배운 것 같다.

AWS로 대표되는 클라우드 환경과, 도커와 쿠버네티스로 대표되는 컨테이너 기술이 맞물려서 빛을 보는 것 같은데, 이미 도커를 많이 사용해 본 입장에서 도커를 보고 MSA를 만든 게 아닌가 싶을 정도로 찰떡궁합으로 보였다. 로드밸런싱마저 스프링 클라우드의 게이트웨이라는 것으로 제공하고 있으니 정말 적용만 하면 되겠다 싶었다.

강사님 말씀대로 지금 우리가 진행하는 프로젝트에 적용하기에는 과한 기술이라 제대로 적용한 프로젝트는 진행하지 않겠지만, 나중에 개인적으로 해보면 재미있을 것 같았다.

계획

아무리 흥미를 잃었다고 해도 ‘팀’프로젝트다. 지금까지도 민폐 덩어리 였는데 흥미를 잃은 와중에도 할 일은 해야 한다…

제발…