브라우저는 모든 페이지에 자동으로 /favicon.ico 를 요청해요.리소스가 없으면 404가 나고, 설정에 따라 NoResourceFoundException 로그가 남습니다.아래 단계만 따라하면 조용하고 깔끔하게 정리됩니다. 1) 증상로그에 이런 메시지가 반복해서 찍힘:org.springframework.web.servlet.resource.NoResourceFoundException: No static resource favicon.ico.혹은 필터/핸들러에서 404(가끔 500처럼 보이는 로그)로 기록됨.2) 원인브라우저가 탭 아이콘을 표시하려고 항상 /favicon.ico 를 요청정적 리소스 폴더에 파일이 없으면 404전역 예외 처리에서 이 404를 잡아 로그를 쌓거나 다른 응답으로 바꿀 수도 있..
Spring
1) WebFlux란?정의: Spring의 논블로킹 리액티브 웹 프레임워크. Reactor(Mono/Flux) 기반으로 동작하며 기본 서버로 Reactor Netty를 사용.쓰임새I/O-bound 고동시성: 외부/내부 API, 파일, Redis 등 대기 시간이 긴 I/O를 동시에 많이 처리할 때 효율적스트리밍 응답: SSE/WebSocket/서버-push, 무한 스트림리액티브 스택: R2DBC, Reactive Redis/Kafka 등과 자연스럽게 연동언제 굳이 안 쓰나CPU-bound 위주, JPA(블로킹) 중심 CRUD 위주의 일반 백오피스팀이 리액티브 운영·디버깅 복잡도를 감당할 이유가 없을 때(주의) 리액티브 체인 안에 **블로킹 호출(JPA/외부 SDK)**을 섞으면 이점이 사라짐 → 필요 시 ..
1) 왜 JSON 컬럼인가?폼/설문/추가속성처럼 필드 구성이 자주 바뀌는 데이터를 RDB 테이블에 억지로 녹이면 컬럼 폭발이 납니다. 이때 한 컬럼에 JSON을 저장하면 스키마 변경 없이 확장 가능합니다.2) 접근 방식 요약방식특징권장도문자열(String) + ObjectMapper 수동 파싱간단하지만 매 요청마다 (de)serialize 코드 필요학습/프로토타입용Hypersistence Utils JsonType@Type(JsonType.class)로 Map/List/POJO/JsonNode 자동 매핑실무 권장 (Hibernate 5/6 둘 다 커버)Hibernate 6 내장 JSON 매핑@JdbcTypeCode(SqlTypes.JSON) 등으로 매핑 가능 (DB가 JSON 지원 시)대안 (H6 사용 ..
핵심 요약원칙: 객체 그래프는 단방향을 기본값으로. 정말 필요한 경우에만 양방향.DDD: 다른 애그리게이트는 ID로만 참조하고, 자식 조작은 루트의 메서드로 수행.구현 팁: 실무에선 @ManyToOne(자식→부모)만 둬도 대부분 충분하고 효율적. 거꾸로(부모→자식) 컬렉션이 꼭 필요할 때만 추가. 1) 왜 양방향 참조를 지양하나?1. 순환 참조(사이클) 자체가 설계 리스크양방향은 객체 간 의존 사이클을 만들어 책임 경계를 흐리고 변경에 취약해진다. 직렬화 시엔 무한 순환(스택오버플로)까지 유발할 수 있어, REST 출력에서 특히 치명적이다.직렬화 문제를 “애너테이션(@JsonBack/ManagedReference)”으로 가릴 수는 있어도, 근본 원인(순환 의존) 은 남는다. 가능하면 모델링 단계에서 사이..
요약@MapsId는 FK를 PK로도 쓰는 매핑을 선언해, 자식 엔티티의 기본키를 부모 엔티티의 기본키와 공유하게 만드는 JPA 어노테이션이다. 주로 @OneToOne에서 컬럼을 하나 줄이는 데 유용하고, @ManyToOne(또는 @OneToMany)에서는 복합키일 때만 의미가 있다. 단일 PK에 @OneToMany + @MapsId를 억지로 쓰면 저장 시 오류가 난다. 1) @MapsId가 정확히 뭐냐?정의: @MapsId는 @ManyToOne 또는 @OneToOne 연관 필드가 엔티티의 기본키를 구성하도록 지정한다. 단일 키, @EmbeddedId의 일부, 혹은 부모의 단일 PK와 타입이 같은 경우 모두 지원한다.왜 쓰나: 자식의 PK와 FK를 하나의 컬럼으로 합쳐 “FK 컬럼 + 별도 PK 컬럼”의 ..
OncePerRequestFilter — “요청당 딱 한 번 실행되는 서블릿 필터”무엇인가요?OncePerRequestFilter는 서블릿 필터의 편의 베이스 클래스로, 한 HTTP 요청 처리 흐름에서 필터가 중복 실행되지 않도록 보장합니다.스프링 MVC의 HandlerInterceptor보다 **더 앞단(서블릿 계층)**에서 동작합니다.언제 쓰나요?요청 입구에서 공통 전/후 처리할 때(예: TraceId 생성/헤더반사, MDC 세팅/정리, CORS/로깅/감사(Audit)/멀티테넌시 등)컨트롤러 진입 전, 응답 반환 후 finally 정리가 필요한 로직장점중복 실행 방지: 내부 guard로 동일 요청에서 한 번만 실행전/후처리 용이: try/finally로 리소스/컨텍스트 정리선택적 스킵: shouldN..