조용한 개발 노트

3편에서는 JPA가 왜 상태(state)를 가진 객체를 전제로 설계됐는지를 살펴봤습니다.이제 그 선택의 결과로 등장한, JPA 내부 설계의 중심 개념을 마주할 차례입니다.바로 Persistence Context입니다.Persistence Context는 JPA를 설명할 때 가장 자주 등장하지만,가장 많이 오해되는 개념이기도 합니다.1. Persistence Context를 “캐시”라고 부르는 순간 생기는 오해Persistence Context를 설명할 때 흔히 이런 표현을 씁니다.“1차 캐시 같은 거예요”이 설명은 완전히 틀린 말은 아니지만,이 표현 때문에 JPA의 핵심 목적이 가려집니다.Persistence Context의 주 목적은조회 성능 최적화 ❌DB 부하 감소 ❌가 아닙니다.공식 문서 관점에서 ..

2편에서는 Spring JPA 공식 문서 관점에서“JPA는 무엇을 해주고, 무엇을 해주지 않는가”라는 책임 경계를 정리했습니다.이제 다음 질문으로 자연스럽게 넘어가야 합니다.그렇다면 JPA는 왜 이렇게까지 ‘상태를 가진 객체’를 전제로 설계됐을까?이 질문에 대한 답을 이해하지 못하면,엔티티는 왜 불변이면 안 되는지왜 setter가 필요해지는지왜 JPA가 이렇게 복잡해 보이는지를 끝까지 이해할 수 없습니다.1. JPA에서 Entity는 단순한 DTO가 아니다많은 개발자가 처음 JPA를 접할 때 엔티티를 이렇게 생각합니다.“DB 테이블을 객체로 옮긴 것”하지만 공식 문서에서 정의하는 Entity는영속성 컨텍스트에 의해 관리되는 객체입니다.즉, Entity는단순 데이터 구조가 아니라현재 어떤 상태에 있는지JP..

1편에서는 ORM과 JPA가 무엇을 해결하려 했는지를 살펴봤습니다.이번 글에서는 그 문제 정의에서 자연스럽게 이어지는 가장 중요한 질문을 다뤄보겠습니다.JPA를 쓰면 정말 SQL을 안 써도 되는 걸까?이 질문에 대한 오해가 JPA 사용에서 발생하는 대부분의 문제의 출발점입니다.1. JPA = SQL 제거라는 오해JPA를 처음 접할 때 많이 듣는 설명은 대체로 이렇습니다.SQL을 직접 작성하지 않아도 된다객체만 다루면 된다이 설명은 절반만 맞고, 절반은 틀립니다.JPA를 사용한다고 해서 SQL이 사라지는 것은 아닙니다.SQL은 “보이지 않게” 될 뿐입니다.그리고 이 차이를 이해하지 못하면, JPA는 곧바로“이유 없이 느린 기술”로 보이기 시작합니다.2. 공식 문서가 말하는 ORM의 역할Spring JPA ..

Spring을 사용하다 보면, 결국 반드시 마주치게 되는 기술이 있습니다.바로 JPA(Java Persistence API)입니다.JPA는 많은 개발자에게“편리한 ORM”“SQL을 안 써도 되는 기술”로 인식되곤 합니다.하지만 JPA를 어느 정도 이상 사용해 본 개발자라면, 다음과 같은 질문을 한 번쯤은 던져봤을 것입니다.왜 JPA는 항상 성능 문제의 중심에 있을까?왜 JPA 장애는 재현이 이렇게 어려울까?이 질문에 답하려면, 사용법 이전에 JPA가 무엇을 해결하려 했는지부터 다시 봐야 합니다.1. ORM이 등장하기 전의 세계ORM이 등장하기 전, 서버 애플리케이션의 데이터 접근은 대체로 다음 흐름을 따랐습니다.SQL 작성 → ResultSet 파싱 → 객체로 변환이 방식의 가장 큰 문제는 성능이 아..

48편에서는 실제 장애 시나리오를 통해 Spring 서비스 운영을 처음부터 끝까지 따라가 보았습니다.이번 글에서는 이 시리즈의 마지막 질문에 답해보겠습니다.“이 모든 지식과 경험을 어떻게 팀의 기본 역량으로 만들 수 있을까?”개인의 숙련도는 언제든 이직·휴가·업무 변경으로 사라질 수 있습니다.반면,팀에 내재화된 기술은 쉽게 사라지지 않습니다.1. ‘잘 아는 사람’에게 의존하면 생기는 문제많은 팀이 이런 구조를 가지고 있습니다.Spring 구조는 A가 제일 잘 안다배포는 B가 제일 잘 한다장애 대응은 C가 제일 빠르다이 구조의 문제는 명확합니다.특정 인원 부재 시 리스크 급증지식 전파 속도 저하새로운 시도에 대한 두려움기술 내재화의 목표는“A, B, C가 없어도 팀이 굴러가게 만드는 것”입니다.2. 문서만..

47편에서는 Spring 서비스에서 모니터링·알림을 어떻게 설계해야 하는지를 정리했습니다.이번 글에서는 그 설계를 바탕으로,“실제로 장애가 터졌을 때 처음부터 끝까지 어떻게 대응해야 하는가”를 하나의 현실적인 시나리오로 따라가 보겠습니다.시나리오 개요배포 직후 일부 API 응답 지연p99 급등 + 에러율 증가사용자 체감 장애 발생이 상황에서 감 → 추측 → 수동 조작으로 가면 대응이 늦어집니다.대신,“정해진 흐름대로”움직이는 것이 핵심입니다.1단계. 첫 알림 – 무엇이 문제인가알림 시스템에서 다음과 같은 신호가 옵니다.p99 응답 시간 SLO 초과에러율 증가여기서 중요한 건:“증상이 무엇인지”를 명확히 하는 것입니다.이 단계에서는 원인을 추측하지 않습니다.2단계. 영향 범위 판단바로 다음 질문으로 넘어갑..

46편에서는 CI/CD 파이프라인에 Rollback·Canary 판단을 자동화해 배포 안정성을 높이는 방법을 정리했습니다.이번 글에서는 그 자동화가 제대로 동작하기 위한 전제,“장애를 얼마나 빨리, 얼마나 정확히 감지할 수 있는가”를 다루겠습니다.핵심은 단순합니다. 지표는 적게, 의미는 분명하게입니다.1. 관측(Observability)의 세 축모니터링은 보통 다음 세 가지로 구성됩니다.Metrics – 숫자(상태)Logs – 사건(원인)Tracing – 흐름(경로)이 세 가지를서로 보완적으로설계해야, “왜 느린지/왜 터졌는지”를 빠르게 연결할 수 있습니다.2. Metrics – 무엇을 반드시 봐야 할까Spring 서비스에서 반드시 봐야 할 핵심 지표는 다음 네 가지입니다.요청 성공률 (Error Rat..

45편에서는 Rollback과 Canary 배포 전략을 통해 문제가 생겨도 빠르게 복구하는 운영 방식을 정리했습니다.이번 글에서는 그 전략을“사람이 아니라 파이프라인이 실행하게 만드는 방법”즉, Spring 서비스에 맞는 CI/CD 파이프라인 설계를 실무 기준으로 정리해보겠습니다.1. CI/CD 파이프라인의 목표좋은 CI/CD의 목표는 단순합니다.빠르게 배포하고문제가 있으면 즉시 멈추고안전하면 자동으로 확장즉,“배포 판단을 자동화한다”는 것입니다.2. Spring 서비스 기준 파이프라인 단계Spring + Kubernetes 환경에서 일반적인 CI/CD 파이프라인은 다음 단계로 구성됩니다.코드 변경 감지빌드 & 테스트이미지 생성배포 (Canary / Rolling)검증 (Health / Metric)확장..

44편에서는 Spring + Kubernetes 환경에서 무중단 배포를 구현하는 전략을 살펴봤습니다.하지만 실무에서는 이 질문이 반드시 뒤따릅니다.“배포 후 문제가 생기면 어떻게 빠르게 복구할 것인가?”이번 글에서는Rollback – 이미 배포된 것을 되돌리는 전략Canary – 문제를 사전에 감지하는 전략을 요청 흐름 기준으로 정리해보겠습니다.1. Rollback은 왜 별도 전략이 필요한가무중단 배포가 있어도,치명적인 버그성능 급락외부 연동 실패는 언제든 발생할 수 있습니다.이때 중요한 것은:“원인을 찾는 것”보다 “서비스를 살리는 것”입니다.그래서 Rollback은빠르고판단이 단순하며자동화되어 있어야합니다.2. Kubernetes에서의 기본 RollbackKubernetes Deployment는 기본..

43편에서는 Kubernetes 환경에서 Spring 애플리케이션의 기동·종료 생명주기를 어떻게 맞춰야 안정적으로 운영할 수 있는지를 살펴봤습니다.이번 글에서는 그 생명주기를 실제 배포 전략으로 연결해,“배포 중에도 사용자는 왜 아무것도 느끼지 못할까?”를 무중단 배포(Zero Downtime Deployment) 관점에서 정리해보겠습니다.1. 무중단 배포의 전제 조건무중단 배포는 단순히 Pod를 여러 개 띄운다고 자동으로 달성되지 않습니다.다음 조건이 모두 만족되어야 합니다.기동 중 트래픽 차단종료 중 신규 요청 차단진행 중 요청의 안전한 완료이 조건을 Spring과 Kubernetes가 서로 협력해서 만족시켜야 합니다.2. Rolling Update의 기본 동작Kubernetes의 기본 배포 전략은 ..