Queue에서 Consumer는 큐에 쌓인 메시지를 가져와 실제로 처리하는 역할을 하는 주체다. 메시지는 Consumer가 처리할 때까지 큐에 저장되며, Consumer는 필요할 때 메시지를 가져와 비동기적으로 처리한다. 여러 Consumer가 존재할 경우 부하 분산 및 병렬 처리로 시스템 처리량과 확장성을 높일 수 있다.
ReadQueue에서 Producer는 메시지(이벤트/작업)를 생성해 큐에 넣는 역할을 하는 주체다. Producer는 처리 완료를 기다리지 않고 메시지만 전달함으로써 비동기 처리와 서비스 간 디커플링을 가능하게 한다. 이 구조를 통해 시스템은 부하를 분산하고 장애 상황에서도 유연하게 처리할 수 있다.
ReadSQS는 간단한 메시지 큐 기반으로 서비스 간 비동기 처리와 디커플링에 적합한 서비스다. 반면 MSK(Kafka)는 고속·대용량 데이터 스트리밍과 실시간 처리, 이벤트 기반 아키텍처에 최적화된 플랫폼이다. 즉, 단순 메시지 전달이면 SQS, 실시간 스트리밍·분석까지 필요하면 MSK를 선택하는 것이 핵심 기준이다.
ReadHTTP Referer 헤더는 사용자가 어떤 페이지에서 현재 요청으로 이동했는지(유입 경로)를 전달하는 정보다. Chrome에서는 보안 강화를 위해 Referrer-Policy에 따라 전달되는 정보 범위를 제한하며, 기본적으로 도메인 수준만 보내도록 변경되었다. 즉, 과거처럼 전체 URL이 아닌 프라이버시 보호를 위해 최소한의 정보만 전달되는 방향으로 정책이 변화한 것이 핵심이다.
ReadAPI에서 404는 단순히 “데이터 없음”이 아니라, 해당 리소스 자체가 존재하지 않을 때 사용하는 상태 코드다. 따라서 조회 결과가 없는 경우까지 무조건 404를 쓰는 것은 부적절하며, 상황에 따라 200(빈 결과) 등으로 구분해야 한다. 핵심은 HTTP 상태코드를 “리소스의 존재 여부” 기준으로 정확히 설계해야 한다는 점이다.
ReadAPPLE 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로 변환해야 한다.
Read