TwentyTwentyOne

세션이 좋을까, JWT가 좋을까? 로그인 이후 인증 상태를 유지하는 두 가지 방식 제대로 이해하기 — FastAPI · Spring Boot · Node.js비밀번호 해시까지 붙이고 나면, 이제 진짜로 다음 질문이 나옵니다.“로그인 성공한 사용자를 이제 어떻게 기억하지?”여기서 거의 무조건 나오는 단어가 두 개예요.세션(Session)JWT근데 이 주제는 늘 좀 이상하게 흘러갑니다.누군가는 “요즘은 무조건 JWT죠”라고 하고,또 누군가는 “아니, 세션이 더 안전해요”라고 하죠.솔직히 말하면… 둘 다 반쯤 맞고, 반쯤은 맥락이 빠진 말입니다.저도 예전엔 JWT가 더 최신이고 멋진 방식처럼 느껴졌어요.토큰 하나 들고 다니면 되니까 뭔가 더 현대적이고, 마이크로서비스랑도 잘 맞고, 모바일 앱에도 잘 어울려 보..

스프링 시큐리티 완전 처음부터 16편 (Kotlin)실무 케이스 스터디 — “이 보안 구조, 실제 서비스에 적용하면 이렇게 흘러간다”15편에서 우리는 태도 이야기를 했다.16편은 다시 현실로 내려온다.이번 글은 가상의 예제가 아니다.실제 서비스에서 정말 자주 나오는 요구사항을 하나 잡고,지금까지 만든 시큐리티 구조가 어떻게 자연스럽게 녹아드는지를 보여주는 글이다.“아, 그래서 이 구조였구나”이 감각을 남기는 게 목표다.0️⃣ 가정하는 서비스 시나리오🎯 서비스 설정B2B SaaS (회사별 계약 관리 서비스)고객사(테넌트) 여러 개사용자 역할ROLE_USER : 계약 조회ROLE_ADMIN : 계약 생성/삭제프론트엔드React SPA인증 방식자체 로그인 + JWT멀티 테넌트 필수👉 딱, 우리가 지금까지 ..

스프링 시큐리티 완전 처음부터 15편 (Kotlin)주니어에서 시니어로 갈리는 순간 — “보안 코드”를 대하는 태도이 글은 코드가 거의 없다.대신 생각 이야기다.솔직히 말하면,이 시리즈를 여기까지 읽은 사람은이미 “스프링 시큐리티를 모르는 주니어”가 아니다.그럼에도 불구하고실무에서 같은 스택을 쓰는데도어떤 개발자는 신뢰를 얻고,어떤 개발자는 계속 리뷰에서 막힌다.차이는 딱 하나다.“보안을 기능으로 보느냐,시스템의 책임으로 보느냐”1️⃣ 주니어 개발자가 보는 보안주니어 시절의 나는 이렇게 생각했다.로그인 되면 OK토큰 나오면 OK401 / 403 나오면 OK“일단 동작하면 됐지”이 시점의 보안은👉 구현 체크리스트에 가깝다.그래서 질문을 받으면 이렇게 답한다.“Spring Security 써서 JWT 인증..

스프링 시큐리티 완전 처음부터 14편 (Kotlin)“이걸 언제까지 직접 가져가야 할까?” — Spring Security 이후의 선택지 정리 (Keycloak · Cognito · Auth0)13편까지 따라왔다면이제 이런 질문이 자연스럽게 나온다.“이 정도면 충분히 잘 만든 것 같은데…이걸 언제까지 직접 유지해야 하지?”이 질문을 던질 수 있다는 것 자체가이미 시큐리티를 ‘구현’이 아니라 ‘운영 비용’의 관점으로 보기 시작했다는 증거다.이번 글은👉 Spring Security 자체를 더 파는 글이 아니다.👉 대신 **‘언제 직접 구현을 내려놓고, 외부 인증 서버를 써야 하는가’**를 정리한다.실무에서 굉장히 중요한 판단 포인트다.0️⃣ 이 글의 결론을 먼저 말하면❌ “외부 인증 서버가 무조건 더 좋..

스프링 시큐리티 완전 처음부터 13편 (Kotlin)보안 사고 리허설: 토큰 유출 · 권한 오류 · 테넌트 사고가 났다면 어떻게 대응할까이 글은 제발 안 겪었으면 좋겠지만,한 번은 반드시 겪게 되는 상황을 다룬다.“어… 로그 보니까이상한 요청이 계속 들어오는데요?”“다른 회사 데이터가 보였다는 문의가 왔어요…”“관리자 API에 평소보다 10배 많은 호출이 찍혔습니다.”이때 중요한 건코드를 얼마나 잘 짰는지가 아니라👉 얼마나 침착하게, 순서대로 대응하느냐다.이번 글은**실제 운영 환경에서 바로 써먹는 ‘보안 사고 대응 리허설’**이다.(책 한 챕터 쓴다는 마음으로 간다.)0️⃣ 보안 사고 대응의 기본 원칙 (이거부터 박자)🔴 절대 하지 말아야 할 것“일단 서버 재시작”“일단 다 막아”“일단 로그부터 지..

스프링 시큐리티 완전 처음부터 12편 (Kotlin)운영에서 진짜 중요한 것들: 보안 테스트 · 로깅 · 모니터링 (안 터지게 만드는 기술)이제 구현은 끝났다.근데 실무에서는 여기서 질문이 바뀐다.“이거… 운영에서 안 터질까요?”“누가 공격하면 어디서 확인하죠?”“권한 오류, 인증 실패… 로그로 남나요?”이번 글은 기능 추가가 아니라 ‘운영 안정성’ 이야기다.솔직히 말하면, 이 파트가 빠진 보안 구현은 반쪽짜리다.0️⃣ 이 글에서 다룰 것 (실무 필수)보안 테스트 전략 (단위 / 통합 / 시나리오)인증·인가 실패 로그 설계JWT 오류를 “사고 징후”로 바꾸는 방법운영에서 꼭 필요한 모니터링 포인트최소 비용으로 시작하는 실전 세팅1️⃣ “보안 테스트요? 로그인만 되면 되는 거 아닌가요?”❌ 이 생각이 제일..

스프링 시큐리티 완전 처음부터 11편 (Kotlin)실무 투입 전 최종 체크리스트 + 바로 쓰는 템플릿 (이 글 하나면 다시 안 헤맨다)이제 진짜 마지막이다.11편은 새 개념을 추가하는 글이 아니라,지금까지 만든 모든 걸 **“실무에서 바로 쓰게 만드는 정리 글”**이다.솔직히 말해서스프링 시큐리티는 한 번 이해해도몇 달만 손 놓으면 다시 헷갈린다.그래서 이 글은:프로젝트 시작할 때이직 과제할 때면접 전날실무에서 “우리 보안 구조 뭐지?” 싶을 때👉 북마크해두고 다시 보는 글을 목표로 쓴다.1️⃣ 전체 구조 한 번 더 리마인드 (머릿속 지도)이 그림을 보고아래 문장이 바로 떠오르면 성공이다.“로그인은 인증,이후 요청은 JWT 검증,인가는 ROLE + tenant 기준”2️⃣ 실무 투입 전 필수 체크리스..

스프링 시큐리티 완전 처음부터 9편 (Kotlin)“이 구조 왜 이렇게 설계했나요?” — 면접·설계 리뷰에서 살아남는 설명법이 글은 코드를 더 치는 글이 아니다.오히려 이런 순간을 위한 글이다.면접관이 묻는다“JWT 왜 쓰셨어요?”“세션 쓰면 안 됐나요?”“Refresh Token은요?”“멀티 테넌트에서 보안은 어떻게 보장했죠?”혹은사내 설계 리뷰외주/협업 미팅기술 문서 작성👉 이때 말로 설명 못 하면,아무리 잘 구현해도 ‘이해 못 한 사람’이 된다.이번 글은“우리가 만든 시큐리티 구조를 어떻게 설명해야 하는지”를 하나의 스토리로 정리한다.0. 먼저 이걸 인정하고 가자면접관이나 리뷰어가 원하는 건 이거다.❌ “정답 구조”⭕ “합리적인 선택 + 트레이드오프 인식”즉,왜 이 방식을 골랐는지다른 선택지는 뭐..

스프링 시큐리티 완전 처음부터 8편 (Kotlin)멀티 테넌트(Multi-Tenant) 환경에서 인증/인가 설계 – B2B SaaS 실무 구조이쯤 되면 질문이 하나 바뀐다.“한 서비스에 여러 회사(조직) 가 들어오면이 시큐리티 구조, 그대로 써도 되나요?”정답부터 말하면그대로 쓰면 100% 사고 난다.왜냐면 지금까지 만든 구조는‘사용자 단위’ 보안까지만 커버하고 있기 때문이다.B2B, SaaS, 내부 업무 시스템에서는보안의 기준이 하나 더 생긴다.“이 사용자는 누구인가?” +“어느 조직(테넌트)에 속해 있는가?”이번 글은멀티 테넌트 환경에서의 인증/인가를 어떻게 설계해야 하는지를진짜 실무 관점에서 풀어본다.0. 멀티 테넌트, 말부터 정리하자멀티 테넌트란 이거다.하나의 서비스에 여러 ‘조직(회사)’이 존재..

스프링 시큐리티 완전 처음부터 7편 (Kotlin)OAuth2 소셜 로그인 구조 이해 + “왜 실무는 이 방식을 선택할까”여기까지 온 사람이라면이제 “로그인을 직접 구현할 수 있느냐”는 질문은 끝났다.이제 다음 질문이 나온다.“근데…왜 대부분의 서비스는 직접 로그인 안 만들고구글/카카오/네이버 로그인을 쓰죠?”이번 글은OAuth2 소셜 로그인을“기능 구현 중심”이 아니라구조 + 설계 관점에서 풀어보는 글이다.👉 실무에서 왜 이 방식을 선택하는지👉 스프링 시큐리티에서는 내부적으로 어떤 일이 벌어지는지👉 우리가 만든 JWT 구조와 어떻게 결합되는지이걸 명확하게 정리해보자.0. OAuth2를 한 문장으로 정리하면OAuth2는 이거다.“비밀번호를 우리 서버에 주지 않고,신뢰 가능한 외부 서비스가 대신 인증..