서론: OAuth는 로그인 프로토콜이 아니다 OAuth 2.0의 핵심은 사용자가 비밀번호를 제3자 앱에 주지 않고 특정 자원 접근을 위임하는 것이다. “이 사용자가 누구인가”를 표준화한 계층은 OpenID Connect(OIDC)다. 둘을 구분해야 Access Token을 사용자 프로필처럼 오용하거나 ID Token으로 API를 호출하는 실수를 피할...

서론: JWT가 세션의 상위 호환은 아니다 세션은 서버에 상태를 두고, JWT는 서명된 토큰에 일부 상태를 담는다. 둘 다 인증 결과를 다음 요청에 연결하는 방법이며, 시스템 구조와 폐기 요구에 따라 장단점이 달라진다. “마이크로서비스니까 JWT” 같은 한 문장으로 결정하면 로그아웃·권한 변경·키 유출 시점에 비용을 치른다. 1. 세션 인증의 흐름...

서론: 로그인 API보다 먼저 흐름을 이해하자 Spring Security는 설정 몇 줄로 로그인과 접근 제어를 붙여준다. 하지만 인증 실패가 어디서 처리되는지, 현재 사용자가 어떻게 Controller까지 전달되는지 모르면 커스텀 필터가 늘어날수록 디버깅이 어려워진다. 첫날은 사용자 이름·비밀번호나 JWT 같은 방식보다 아래에 있는 공통 인증 구조...

서론: 프로덕션 준비는 배포 버튼 앞에서 시작되지 않는다 Day 1~4에서 요청 경계, 트랜잭션, 데이터 접근, 외부 연동을 설계했다. 마지막 단계는 변경이 그 경계를 깨뜨리지 않는지 배포 전에 검증하고, 배포 후 실제 동작을 관찰하며, 이상이 생기면 빠르게 되돌리는 것이다. 테스트·관측성·배포는 별개의 운영 항목이 아니다. 테스트에서 확인한 유스...

서론: 네트워크 호출은 성공·실패 둘 중 하나가 아니다 Day 3에서 애플리케이션과 DB 사이의 대기열을 다뤘다. 외부 API는 더 불확실하다. 요청이 상대에게 도착하지 않았을 수도 있고, 처리는 성공했지만 응답만 유실됐을 수도 있다. 따라서 타임아웃은 “실패했다”가 아니라 결과를 아직 모른다는 뜻일 수 있다. 복원력은 실패를 없애는 기술이 아니다...

서론: 느린 API는 계층 전체의 문제다 Day 2에서 트랜잭션을 짧고 정확하게 잡았다. 하지만 요청 하나가 불필요한 쿼리 수십 개를 만들거나, 느린 쿼리가 연결을 오래 점유하면 트랜잭션 설계만으로는 버틸 수 없다. 애플리케이션의 스레드, 커넥션 풀, DB CPU와 락은 하나의 대기열로 연결되어 있다. 성능 튜닝의 출발점은 설정값을 키우는 것이 아...

서론: 어노테이션보다 중요한 것은 범위다 Day 1에서 Controller·Service·Domain의 책임을 나눴다. 상태를 바꾸는 유스케이스는 중간에 실패해도 데이터가 절반만 반영되지 않아야 한다. Spring은 @Transactional 한 줄로 이를 쉽게 보이게 하지만, 실제 장애는 그 한 줄의 시작과 끝을 잘못 잡을 때 생긴다. 트랜잭션은...

서론: 동작하는 코드와 오래 버티는 코드의 차이 Spring Boot로 API 하나를 만드는 일은 어렵지 않다. @RestController에서 요청을 받고 Repository를 호출하면 금방 응답이 나온다. 문제는 기능이 늘어난 뒤다. 검증은 여기저기 흩어지고, Entity가 API 계약이 되며, Controller에 비즈니스 규칙이 쌓인다. 프로...

서론: 한 바퀴를 닫기 Day 1~4에서 데이터·학습·서빙·모니터링을 다뤘다. 이것들은 따로 떨어진 단계가 아니라 하나의 순환 고리다. 모니터링(Day 4)이 드리프트를 감지하면 재학습이 돌고, 새 모델이 검증·배포(Day 3)되고, 다시 모니터링된다. 마지막 편은 이 고리를 자동화하는 것 — ML의 CI/CD에 더해진 CT(Continuous Tr...

서론: 배포는 끝이 아니라 시작이다 일반 소프트웨어는 배포 후 코드를 안 바꾸면 동작이 그대로다. ML 모델은 다르다. 코드가 그대로여도, 세상이 변하면 모델이 조용히 틀려간다. 사용자 행동이 바뀌고, 시장이 변하고, 새로운 패턴이 등장한다. 모델은 에러를 던지지 않고 그냥 점점 나쁜 예측을 낸다. 이 “조용한 실패”를 감지하는 것이 ML 모니터링의...