구독 중인 기술 블로그 RSS 피드 목록 이 블로그는 다양한 기술 소식을 RSS 피드로 구독하여 콘텐츠를 생성하고 있습니다. 토스 기술 블로그: https://toss.tech/rss.xml 카카오 기술 블로그: https://tech.kakao.com/feed/ 당근(Daangn) 미디엄 블로그: https://medium.com/f...

서론: 프로덕션 준비는 배포 버튼 앞에서 시작되지 않는다 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에서 데이터를 재현 가능하게 만들었다면, 오늘은 학습 과정 자체를 추적·자동화한다. 추적하지 않은 실험은 ...