APPLE ID 잘 챙기자.
Read이 글은 특정 기술/이슈에 대한 실무 경험 기반 문제 원인과 해결 과정을 정리한 트러블슈팅 기록이다.
ReadResilience4j의 Circuit Breaker는 서비스 장애가 발생할 때 요청을 차단하여 장애 전파를 막는 fault tolerance 패턴이다. 내부적으로는 CLOSED → OPEN → HALF_OPEN 상태를 가지는 상태 머신으로 동작하며, 실패율 등의 기준으로 상태가 전이된다. 장애 시에는 실제 호출 대신 fallback 처리 등을 통해 시스템 전체의 안정성과 사용자 경험을 유지하는 것이 핵심 목적이다.
ReadSameSite=None은 크로스 사이트(다른 도메인)에서도 쿠키를 전송하기 위한 설정이다. 하지만 보안 강화를 위해 SameSite=None을 사용하려면 반드시 Secure 옵션(HTTPS 전용)이 함께 필요하다. 이 정책은 Chrome 80 이후 적용되었으며, 미설정 쿠키는 기본적으로 SameSite=Lax로 처리되어 외부 요청에서 제한된다.
ReadHTTPS 페이지에서 HTTP 리소스를 요청하면 보안상 문제로 브라우저가 차단하는 “Mixed Content” 오류가 발생한다. 이는 보통 리다이렉트, 외부 리소스(이미지/스크립트), 프록시 설정 문제 등으로 HTTP 요청이 섞이면서 발생한다. 해결하려면 모든 요청을 HTTPS로 통일하거나, 프록시/헤더 설정 및 CSP 등을 통해 안전하게 HTTPS로 변환해야 한다.
ReadSpring Boot에서는 Thymeleaf와 JSP를 함께 사용할 수 있지만, 각각의 View Resolver 설정을 명확히 분리해야 한다. 일반적으로 Thymeleaf는 templates 경로, JSP는 WEB-INF 경로로 구분하여 처리한다. 다만 구조가 복잡해지고 유지보수가 어려워질 수 있어, 실무에서는 하나의 템플릿 엔진으로 통일하는 것이 권장된다.
ReadJPA는 엔티티 객체와 DB 테이블을 매핑하여 객체지향적으로 데이터를 다룰 수 있게 해주는 ORM 기술이다. 하지만 내부적으로는 영속성 컨텍스트, 변경 감지(Dirty Checking) 등 동작 원리를 이해하지 않으면 예상과 다른 쿼리나 성능 문제가 발생할 수 있다. 따라서 단순 CRUD 수준을 넘어서 JPA의 동작 방식과 생명주기를 이해하는 것이 실무에서 매우 중요하다.
ReadTomcat 8.5에서는 Hot Deploy/Reload 기능을 통해 서버 재시작 없이 변경된 클래스 반영이 가능하다. 하지만 신규 클래스 추가나 구조 변경은 반영되지 않아 결국 재기동이 필요한 한계가 있다. 또한 reload 기능은 메모리 누수나 안정성 문제 등으로 운영환경에서는 주의해서 사용해야 한다.
ReadJDK에서 제공하는 기본 HotSwap 기능은 디버깅 편의 수준으로 제한적이며, 클래스 구조 변경(필드/메소드 추가 등)은 지원하지 않는다. 따라서 실무에서 자유로운 클래스 리로딩을 하려면 JVM 한계를 보완하는 별도 도구나 에이전트 기반 방식이 필요하다.
ReadWAS에서 Class Reloading/HotSwap은 서버 재시작 없이 변경된 클래스 바이트코드를 즉시 반영하는 기술이다. 하지만 JVM 기본 HotSwap은 메소드 내부 수정만 가능하고 구조 변경(필드/메소드 추가 등)은 제한적이어서, 이를 보완하려면 별도 도구(JRebel 등)가 필요하다.
Read