저는 개인적으로 api gateway를 쓸 때 auth구현을 jwt로 할 때 이득을 본다고 생각하는데, 작은 규모의 서비스에서 jwt가 갖는 이점이 어떤것이 있는지 궁금합니다. jwt에 담는 유저 정보를 자주 변경하는 케이스를 말씀하시는 것 인지요?
말씀하신 것과 큰 틀에서는 같습니다. 단지, 유저 자체에 대한 모델링이 바뀌어 정보를 자주 변경해야하기보다는 새로운 피쳐 추가나 서드파티툴을 이용해야하는 새로운 서비스가 부가적인 정보를 요구할 때 옵셔널하게 추가하는 경우에 가까웠습니다. (조금 더 하자면 잠재적으로 auth 를 api gateway 같은 걸 이용해서 관리단위를 분리할지 말지, 혹은 그와 준하는 역할을 하는 서버가 하나 있을지 미묘한 상황속에서...)
조금 구체적으로 예를 들면, A라는 서비스를 메인으로 가져가고 있는 상황이었는데요. MVP 다보니 결제정보나 인증된 유저인지 정보만 유저 테이블에서 가지고 있었습니다. 그런데 유저마다 다른 인증정보가 있어야 이용할 수 있는 서비스인 B와 C를 추가해달라는 요청이 들어온 상황이었습니다. 그중에서 또 B는 A라는 서비스 안으로 들어갈지 말지도 결정 안났고, C는 사라질수도 있어서 가볍게 테스트하고 싶어하는 상태였습니다. (플랜관리 기능은 말하지 않아도 추가해줘야 탈이 없었을 거고요). 이에 더해 B, C를 기존에 A 서비스를 제공하는 웹 서비스 페이지에서 같이 사용해보는 형태로 시작하고 싶어했습니다. 운영중인 서비스 특성상 플랜관리 테이블(혹은 범용적인 인증관련 테이블)을 만들어서 도메인 관계를 서비스마다 그려가지고 매핑해서 구현하기 전까지는 여러 개의 테이블 조회(혹은 콜렉션 조회)가 불가피한 상황이었습니다. 이게 프로젝트를 정리해줄 사람이 있는 상황에서는 몇 번 회의도 해서 도대체 해결하고자 하는 문제는 뭐고 원하는 피쳐는 뭔지 뾰족하게 뽑았으면 좋았겠지만, 그게 보장되는 상황은 아니었습니다. 또 언제 이런 부채들을 걷어낼 수 있는지 불투명하기도 했고요. 그래서 이런 일이 벌어질 법 했던게 A라는 서비스 런칭 전부터 조짐이 보였어서...첫 구성 때 auth 시 최대한 조회비용/추후 관리비용을 아낄 수 있는 형태로 가자 생각하다보니 JWT 로 했습니다. 그외에도 자잘하게 비슷한 일들이 워낙 많았던 거 같습니다.
하지만 댓 마지막에 언급했다시피 사실 뭘로 구현했어도 프로젝트 자체에는 아주 큰 영향은 없었을 거 같습니다. 세션으로 구현해놓았으면 세션 나름대로 방법을 찾았을 거 같아요. 오히려 개발자가 타 직무 일을 해야하는 상황이나 소통비용이 깨져야 하는 상황에 계속 노출되었던 게 훨씬 치명적이었던 거 같습니다.
개인 경험에 비추자면 MVP 를 만들 때 JWT 의 이점이 있었습니다.
예를들어, 혼자서 만들고 유지하는 서비스라면 갑작스런 요청에 의한 기획비용을 줄인다는 생각인데요. 아무래도 처음에 세웠던 데이터 관계가 한 두달 뒤에는 완전히 달라져 버리다보니, 기획이 명확하게 나오지 않은 상태에서는 (auth 와 관련된 거 한해서) 차라리 JWT 페이로드 구성 시 옵셔널필드 형태로 가져가 피쳐 구현을 해놓으면, 기획단에서 도메인 분리랑 서비스 분리 업무를 하지 않아도, 일단 모놀리틱 서비스에서 도메인만 쉽게 분리하는 형태로 구현 후 시장 테스트 해볼 수 있었던 기억이 납니다. (그리고 추후 서비스를 분리하는 수순을 가져가는 겁니다. 아님 없애거나.)
그렇지만 만들고자하는 서비스의 도메인별로도 다를 거 같습니다. 해당 프로젝트는 실시간 서비스 중에서도 써드파티랑 결합도가 높은 프로젝트다보니....아무래도 빠르게 구현하다보면 디비에 엄청난 양의 도큐먼트/row 들이 쌓이거나하면 관리 비용이 커질 거 같다는 생각 하에 진행했던 기억이 있습니다.
물론, 빠르게 만드는데 집중하자면 세션 방식이 낫다고 봅니다. (초반에는 여러 서비스 간 커플링이 세지 않다보니 갈아엎고 다시 만들기도 편하고) 타 팀원 합류 시 인계비용도 적으니까요.
당시에는 잠깐이라도 이래저래 고민했습니다만, 사실 지금와서 돌이켜보면 어느쪽으로 구현 했든 프로젝트의 영향도가 심각하지는 않았을 거 같네요.