서론: 로그인 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 모니터링의...

서론: 레지스트리의 모델은 아직 가치가 없다 Day 2에서 검증된 모델이 레지스트리에 등록됐다. 하지만 사용자에게 닿기 전까지 그 모델은 가치를 만들지 못한다. 서빙은 MLOps에서 코드와 인프라가 만나는 지점이고, 가장 사고가 잦은 곳이기도 하다. 오늘은 모델을 어떻게 제공하고, 어떻게 안전하게 배포하는지를 다룬다. 대규모 시스템·gRPC 시리즈의...

서론: 노트북 지옥에서 벗어나기 ML 연구는 보통 주피터 노트북에서 시작한다. 하지만 model_final_v2_real_final.ipynb가 쌓이고, “지난주에 0.92 나온 그 설정이 뭐였지?”를 못 찾는 순간 생산성이 무너진다. Day 1에서 데이터를 재현 가능하게 만들었다면, 오늘은 학습 과정 자체를 추적·자동화한다. 추적하지 않은 실험은 ...