본문 바로가기

전체 글61

Server-Side Design for Social Login (Pre-Implementation Architecture) I have been thinking about how to design the server when implementing social login. I want to implement automatic login properly, but there are many different cases to consider: existing users, new users who want to sign up, users who have agreed to the terms, and so on. It is not as simple as it first seems. I am writing this post hoping that developers who are facing similar 고민 will read it an.. 2026. 1. 23.
소셜 로그인을 위한 서버 설계(코드가 아닌 사전 설계) 소셜 로그인을 구현할 때 서버를 어떻게 설계할까를 고민하고 있었다. 자동 로그인까지 잘 구현하고 싶은데....기존 사용자, 새로 가입을 원하는 사용자, 약관 동의한 사용자 등등 케이스별로 상황이 다양해서 쉽지가 않다. 비슷한 고민을 하고 있는 개발자들이 보고 피드백을 남겨주길 바라면서 글을 적는다. 이 글에서는 “소셜 로그인 + 약관 동의 + JWT + RefreshToken” 서버 설계를 코드 없이 설계 관점으로 정리한다. 정리하려는 핵심 질문은 다음이다.Firebase 인증과 서버 로그인(JWT)은 무엇이 다를까?sign-up과 sign-in은 API를 분리해야 할까?약관 동의는 어디까지가 “회원가입 완료”일까?RefreshToken은 언제 발급/저장해야 자동 로그인이 깔끔해질까? 1. 한 줄 결론외.. 2026. 1. 23.
Auth in Spring Boot - what is JWT and How to make it While implementing JWT, I managed to get things working with the help of AI, but I couldn’t shake the feeling that I didn’t truly understand what was going on under the hood. It was hard to grasp, at a glance, how a token is actually created and how it is used for authentication. Eventually, that curiosity became impossible to ignore, so I decided to break the whole process down piece by piece. .. 2026. 1. 22.
Spring Boot 인증 - JWT 정체와 생성 원리 JWT를 구현하다보니 AI의 도움을 받아 구현을 어찌 저찌 했는데 도저히 동작원리를 한눈에 알기 어렵고 어떻게 토큰이 만들어져서 이게 인증에 쓰이는건지 궁금함을 참을 수 가 없었다. 그래서 하나하나 뜯어 알아보았고 내용이 많은 서버 개발자들에게도 유익할거라고 생각해 공유하기로 했다. 이 글에서는 다음 내용을 정리한다.JWT는 어떤 구조로 만들어지는가? (header.payload.signature)header는 누가 만들지? 랜덤 문자열인가?Base64 인코딩은 암호화인가?서명(Signature)은 무엇이고, 왜 payload를 바꾸면 걸리는가?.signWith(key, HS512)가 실제로 하는 일 1. JWT는 “암호화된 토큰”이 아니다JWT는 흔히 “토큰”이라고 부르지만, 실제로는 세 덩어리 문자열.. 2026. 1. 22.
Practical Strategies for Centralized Cache-Control in GET APIs Recently, while designing a server, I found myself thinking deeply about cache strategies for read-only APIs. As traffic grows, questions like how to reduce server load and how to apply caching without introducing security risks become unavoidable.This article starts with the following questions:Why is Cache-Control necessary for GET read APIs?What is the difference between Redis cache and HTTP .. 2026. 1. 20.
GET 방식 API에서 Cache-Control을 중앙 통제로 관리하는 실무 전략 최근 서버를 설계하면서 조회 API의 캐시 전략에 대해 깊게 고민하게 됐다. 특히 트래픽이 늘어날수록 서버 부하를 어떻게 줄일 것인가, 그리고 보안 이슈 없이 캐시를 어떻게 적용할 것인가는 피할 수 없는 주제다.이 글은 다음 질문에서 출발한다.GET 조회 API에 Cache-Control은 왜 필요한가?Redis 캐시와 HTTP 캐시는 무엇이 다른가?Cache-Control을 컨트롤러마다 두는 게 맞을까?중앙에서 캐시 정책을 통제하는 방법은? 1. 캐시는 왜 쓰는가? (진짜 이유)캐시를 쓰는 이유를 흔히 "응답을 빠르게 하기 위해서"라고 말하지만, 실무에서는 더 중요한 목적이 있다.캐시는 트래픽이 커질수록 서버가 같은 일을 반복하지 않게 막기 위한 장치다.예를 들어 일정 조회 API가 초당 수천 번 호출.. 2026. 1. 20.