웹 서비스의 보안 수준이 지속적으로 강화되면서, 구형 암호화 프로토콜인 TLS 1.0과 TLS 1.1의 지원을 중단하고 TLS 1.2 및 TLS 1.3으로 전환하는 기업이 늘고 있습니다. 하지만 무턱대고 하위 버전의 지원을 끊어버리면 구형 브라우저나 오래된 디바이스(예: 구형 안드로이드, IoT 기기 등)를 사용하는 고객들의 접속이 전면 차단되는 장애가 발생할 수 있습니다. 따라서 보안 정책을 업데이트하기 전, 현재 우리 서비스에 … 더 읽기
PKCE 의무화, Implicit·ROPC 제거 등 OAuth 2.1 변경점과 Spring Security 마이그레이션 방법을 2026년 9월 기준으로 정리했습니다.
안정적으로 운영되던 서비스에서 갑작스럽게 특정 시간대에 API 응답 속도가 5초 이상 지연되는 현상을 겪어보신 적 있으십니까? 특히 TPS(초당 트랜잭션 수)가 평소와 다름없는 수준임에도 불구하고, 간헐적으로 발생하는 타임아웃과 지연은 개발자와 운영자를 곤혹스럽게 만듭니다. 네트워크 장비나 인프라의 문제가 아니라면, 그 원인은 의외로 우리가 무심코 사용했던 코드 한 줄에 숨어 있을 수 있습니다. 일부 서버에서 발생한 API 지연 … 더 읽기
서비스를 런칭하거나 인프라를 마이그레이션 할 때 가장 먼저 마주하는 거대한 장벽, 바로 ‘어떤 클라우드(IaaS)를 쓸 것인가?‘입니다. 과거에는 “그냥 AWS 쓰면 되는 거 아니야?”라고 했지만, 이제는 상황이 많이 달라졌습니다. 글로벌 3대장(AWS, Azure, GCP)의 기술 격전 속에, ‘K-클라우드’라 불리는 국내 3사(네이버, NHN, KT)가 압도적인 가성비와 현지화 전략으로 무섭게 치고 올라왔기 때문이죠. 오늘은 여러분의 비즈니스 성격에 딱 맞는 … 더 읽기
현대 웹 애플리케이션에서 소셜 로그인(Social Login)은 선택이 아닌 필수 기능이 되었습니다. 사용자 입장에서는 귀찮은 회원가입 절차를 건너뛸 수 있어 편리하고, 서비스 제공자 입장에서는 비밀번호 관리의 부담을 덜고 검증된 사용자 정보를 얻을 수 있다는 확실한 이점이 있기 때문입니다. 하지만 개발자 입장에서 소셜 로그인을 처음 구현하려고 하면 마주치는 장벽이 꽤 높습니다. “OAuth 2.0 프로토콜은 무엇이고, 리다이렉트 URI는 … 더 읽기
지난 포스팅들을 통해 우리는 사용자의 신원을 증명하는 인증(Authentication) 과정을 마스터했습니다. 세션과 JWT 중 아키텍처를 선택하고, 필터 체인을 커스텀하여 토큰을 검증하는 단계까지 구축했습니다. 이제 우리는 “이 사용자가 누구인가?”라는 질문을 넘어, “이 사용자가 무엇을 할 수 있는가?“라는 인가(Authorization, 권한 부여)의 영역으로 진입해야 합니다. 많은 초급 개발자들이 인증과 인가를 혼동하거나, 단순히 hasRole(‘ADMIN’) 정도의 간단한 설정으로 보안을 마무리하곤 합니다. 하지만 실무 비즈니스 로직은 … 더 읽기
Spring Security의 진입 장벽이 높은 가장 큰 이유는 바로 ‘필터 체인(Filter Chain)‘이라는 독특한 아키텍처 때문입니다. 이 구조를 이해하지 못하면 단순히 코드를 복사해서 붙여넣는 수준을 벗어날 수 없습니다. 오늘은 이 블랙박스를 열어 내부 구조를 파악하고, 원하는 위치에 나만의 로직을 심는 방법을 마스터해 보겠습니다. Spring Boot로 개발을 진행하다 보면, spring-boot-starter-security 의존성을 추가하는 순간 모든 API 요청이 차단되고 로그인 페이지로 … 더 읽기
지난 포스팅에서 우리는 MSA 및 모바일 환경에서의 확장성을 위해 JWT(Json Web Token) 기반의 인증 아키텍처를 선택하는 것이 유리함을 확인했습니다. 하지만 동시에 JWT가 가진 치명적인 약점인 ‘한번 발급되면 서버가 제어할 수 없다(Stateless)’는 딜레마에 대해서도 논의했습니다. 만약 유효기간이 긴 Refresh Token이 해커에게 탈취당한다면 어떻게 될까요? 해커는 그 토큰이 만료될 때까지 유유히 Access Token을 재발급받으며 사용자의 계정을 마음대로 … 더 읽기
웹 서비스의 규모가 커지고 아키텍처가 모놀리식(Monolithic)에서 마이크로서비스(MSA)로 진화함에 따라, 개발자들이 가장 먼저 마주하는 난관 중 하나는 바로 ‘인증(Authentication) 시스템의 설계‘입니다. 과거 단일 서버 시절에는 별다른 고민 없이 사용하던 세션(Session) 방식이, 서버가 여러 대로 늘어나고 도메인이 분리되는 통합 계정 환경에서는 확장성의 발목을 잡는 주범이 되기도 합니다. 이에 대한 대안으로 JWT(Json Web Token)가 표준처럼 자리 잡았지만, JWT가 만능열쇠는 아니며 … 더 읽기
지난 포스팅에서 Logback을 이용해 단일 서버 환경에서 로그를 파일로 남기고, 치명적인 에러가 발생했을 때 슬랙(Slack)으로 알림을 받는 방법까지 알아보았습니다. 서비스 초기 단계나 트래픽이 많지 않은 단일 서버 아키텍처(Monolithic Architecture)에서는 이 정도 설정만으로도 충분히 운영이 가능합니다. 개발자가 필요할 때 서버에 접속해서 vim이나 cat, grep 명령어로 로그 파일을 열어보면 되기 때문입니다. 하지만 서비스가 성장하여 서버가 10대, 100대로 늘어나거나, 마이크로서비스 아키텍처(MSA)를 도입하여 수십 … 더 읽기