말씀하신 것과 큰 틀에서는 같습니다. 단지, 유저 자체에 대한 모델링이 바뀌어 정보를 자주 변경해야하기보다는 새로운 피쳐 추가나 서드파티툴을 이용해야하는 새로운 서비스가 부가적인 정보를 요구할 때 옵셔널하게 추가하는 경우에 가까웠습니다. (조금 더 하자면 잠재적으로 auth 를 api gateway 같은 걸 이용해서 관리단위를 분리할지 말지, 혹은 그와 준하는 역할을 하는 서버가 하나 있을지 미묘한 상황속에서...)

조금 구체적으로 예를 들면, A라는 서비스를 메인으로 가져가고 있는 상황이었는데요. MVP 다보니 결제정보나 인증된 유저인지 정보만 유저 테이블에서 가지고 있었습니다. 그런데 유저마다 다른 인증정보가 있어야 이용할 수 있는 서비스인 B와 C를 추가해달라는 요청이 들어온 상황이었습니다. 그중에서 또 B는 A라는 서비스 안으로 들어갈지 말지도 결정 안났고, C는 사라질수도 있어서 가볍게 테스트하고 싶어하는 상태였습니다. (플랜관리 기능은 말하지 않아도 추가해줘야 탈이 없었을 거고요). 이에 더해 B, C를 기존에 A 서비스를 제공하는 웹 서비스 페이지에서 같이 사용해보는 형태로 시작하고 싶어했습니다. 운영중인 서비스 특성상 플랜관리 테이블(혹은 범용적인 인증관련 테이블)을 만들어서 도메인 관계를 서비스마다 그려가지고 매핑해서 구현하기 전까지는 여러 개의 테이블 조회(혹은 콜렉션 조회)가 불가피한 상황이었습니다. 이게 프로젝트를 정리해줄 사람이 있는 상황에서는 몇 번 회의도 해서 도대체 해결하고자 하는 문제는 뭐고 원하는 피쳐는 뭔지 뾰족하게 뽑았으면 좋았겠지만, 그게 보장되는 상황은 아니었습니다. 또 언제 이런 부채들을 걷어낼 수 있는지 불투명하기도 했고요. 그래서 이런 일이 벌어질 법 했던게 A라는 서비스 런칭 전부터 조짐이 보였어서...첫 구성 때 auth 시 최대한 조회비용/추후 관리비용을 아낄 수 있는 형태로 가자 생각하다보니 JWT 로 했습니다. 그외에도 자잘하게 비슷한 일들이 워낙 많았던 거 같습니다.

하지만 댓 마지막에 언급했다시피 사실 뭘로 구현했어도 프로젝트 자체에는 아주 큰 영향은 없었을 거 같습니다. 세션으로 구현해놓았으면 세션 나름대로 방법을 찾았을 거 같아요. 오히려 개발자가 타 직무 일을 해야하는 상황이나 소통비용이 깨져야 하는 상황에 계속 노출되었던 게 훨씬 치명적이었던 거 같습니다.