전체학습프로젝트트러블슈팅

#Authorization#HTTP#HTTPS#Security#Spring#Spring Boot#TLS#apache kafka#authorization#broker#config#git#github#kafka#message#next-auth#nextjs#nodejs#oauth#oauth2#offset#partitions#redis#replication#security#session#spring#spring boot#sprint boot#topic#version#개발자#그룹#네트워크#버전#보안#복제#설정#소셜로그인#오프셋#이벤트#이벤트 기반 아키텍처#인증서버#카프카#커머스#컨슈머#토픽#파티션#프로듀서

• 프로젝트

  [14] 커머스 프로젝트 - 주문, 결제 기능 2차 수정

  이전 글 $1 구현 목표 기존 주문, 결제 기능에 대한 전체적인 로직을 변경합니다. 주요 변경 사항은 다음과 같습니다. 주문 생성 시 PENDING 상태 주문 취소 로직 제거 주문 생성 시 재고 차감 로직 재거 재고 차감을 결제 승인 이후로 이전 테스트에서 발견한 주문 생성 문제 해당 글에서는 작성하지 않았지만 K6 동시성 테스트를 진행하면서 아래와 같은 문제를 발견했습니다. 기존 주문 생성 흐름은 다음과 같습니다. <br / 문제가 발생하는 케이스 동시에 10개의 주문 생성 요청이 들어오면 아래와 같은 흐름이 진행됩니다. 문제가 발생하는 케이스는 아래와 같습니다. 1. 주문 생성 요청을 동시에 10개 진행합니다. 2. PENDING 주문이 없는 경우 모든 요청이 다음 단계 실행합니다. 3. 10개의 신규 PENDING 주문이 생성됩니다. 4. 이후 다시 주문 생성을 실행하면, 최근 PENDING 주문 1개만 실행되기 때문에 9개의 주문이 남겨집니다. 해결 방법 - 비즈니스 로직 변경 동시성 문제를 해결하기 위해 주문 생성이 담당하는 책임을 단순화했습니다. 주문 생성 단계에서 하던 작업을 결제 승인 단계로 이전합니다. 기존 PENDING 주문 취소 기능은 제거합니다. 재고 차감 기능은 제거합니다. PENDING 주문 생성은 그대로 유지합니다. 1단계 주문 생성 주문 생성 단계에서는 순수하게 PENDING 상태의 주문만 생성합니다. 기존 PENDING 주문 취소와 재고 차감 로직을 제거했습니다. 단순하게 상품 정보를 조회해 OrderItem을 생성하고, PENDING 주문을 저장합니다. 2단계 Toss PG 결제 진행 주문이 생성되면 프론트에서 Toss SDK 위젯을 사용해 결제를 진행합니다. Toss에 전달하는 주문 ID는 형식으로 가공합니다. orderId: 내부 DB 조회용 주문 ID toosOrderId: Toss API 전달용 (재시도 허용을 위해 Date.now() 사용) 3단계 - 결제 대기 (PENDING 결제 생성) 페이지에서 Payment 레코드를 생성합니다. REQUIRES\NEW 속성을 사용해서 결제 승인 트랜잭션과 독립적으로 동작하도록 구현합니다. Toss PG 승인이 실패하더라도 PENDING 상태의 결제는 보존됩니다. 4단계 - 결제 승인 요청 PENDING 결제가 생성된 뒤, 내부 서버에서 Toss 승인 API를 호출합니다. Toss는 결제 요청 완료 후 10분 이내에 승인을 하지 않으면 자동으로 취소 처리됩니다. 따라서 프론트에서 리다이렉트를 받은 직후 바로 승인 요청을 해야합니다. 5단계 - 내부 결제 승인 처리 (재고 차감) Toss PG 승인이 완료되면 내부에서 아래 작업을 순차로 처리합니다. <br / 재고 차감 순서 - 데드락 방지 여러 상품을 동시에 구매하는 경우, 재고 차감 순서가 달라지면 데드락이 발생할 수 있습니다. productId를 오름차순으로 정렬하고 순서대로 재고를 차감하면, 모든 트랜잭션이 동일한 순서로 Lock을 획득하므로 데드락이 발생하지 않습니다. 6단계 - 재고 부족 처리 결제 승인은 성공했지만 재고가 부족한 경우, 승인 트랜잭션 자체가 롤백됩니다. 재고 부족으로 결제 상태를 APPROVE로 변경하는 트랜잭션이 롤백되면 주문도 CONFIRMED 상태가 되지 않습니다. 프론트에서는 에러 응답을 받으면 별도로 주문 취소 API를 호출해 주문을 명시적으로 CANCELLED 처리합니다. 7단계 - 환불 결제 승인 완료 이후 환불이 필요한 경우의 흐름입니다. <br / 전체 플로우 정리 이번 리팩토링의 핵심은 주문 생성의 책임을 최소화 하는 것입니다. 주문 생성 단계는 순수하게 PENDING 주문을 생성하는 일만 합니다. 재고 차감과 상태 전환은 결제 승인이 확전된 시점에 한 번에 처리합니다. 이렇게 하면 동시 요청에서 발생하는 코드 자료 <https://github.com/dodudi/commerce-spring-nextjs/tree/version/v1 참고 자료 <https://grafana.com/docs/k6/latest/set-up/install-k6/ <https://grafana.com/docs/k6/latest/using-k6/k6-options/reference/

  #spring#sprint boot2026-05-03 · 5분
• 프로젝트

  [13] 커머스 프로젝트 - 주문 기능 리팩토링 + 중간점검

  이전 글 $1 구현 목표 주문 생성에서 재고 선점에 대한 문제를 해결하기 위해 구현을 진행합니다. 주문 생성에서 발생하는 문제에 대해 파악하고 해결 방안을 정의합니다. 재고 고갈의 해결 방안 제가 생각해본 방식은 총 3가지로 아래와 같습니다. 1. 주문을 생성할 때 PENDING 상태의 주문을 취소 처리합니다. 2. 주문을 생성할 때 재고 선점하지 않고, 결제가 완료되면 차감 합니다. 3. 재고를 선점하는 것이 아닌, 예약 방식으로 보관해둡니다. 첫 번째 방법은 가장 간단하게 구현이 가능한 방법입니다. 1. 주문 진행 중 강제 종료를 한 상태에서 주문을 진행하지 않으면 재고 선점한 PENDING 주문이 남게 됩니다. 이를 방지 하기 위해서 Scheduler 로 정리해주는 기능을 구현합니다. 2. 주문을 생성할 때 이전 PENDING 주문을 취소 처리합니다. 두 번째 방법은 재고 선점과, 환불 방식이 단순해 집니다. 1. 주문 생성 단계에서 재고 선점을 구현하지 않습니다. 2. 결제 승인이 완료되고 돈이 지불된 이후 재고를 차감합니다. 3. 재고 부족을 확인하는 시점이 돈을 지불한 이후입니다. 4. 재고 차감이 실패하는 것과 재고 부족을 확인한 시점에 대한 처리가 필요합니다. 5. PENDING 상태로 남은 주문을 처리하는 기능이 필요합니다. 세 번째 방법은 두 번째 방법을 보완할 수 있습니다. 1. 주문 생성에서 재고가 감소하지 않는 것은 동일하나, 재고 선점을 예약 방식으로 진행합니다. 2. 주문 생성에서 재고의 예약 재고를 조회해야 하는 추가적인 구현이 필요합니다. 3. 결제 승인이 완료되고 예약 재고를 차감하도록 구현합니다. 4. 주문 생성, 환불 등 예약을 진행하기 위한 추가 기능 구현이 필요합니다. 첫 번째 방식으로 구현을 진행 첫 번째 방식으로 진행하는 이유는 다음과 같습니다. 1. 재고 선점 문제에 대한 직관적으로 해결합니다. 2. 복잡한 구현이 필요하지 않습니다. 3. 재고 선점 방식을 예약 선점 방식으로 변경하는 것에 문제가 없습니다. API 레이어 리팩토링 OrderRequest OrderResponse OrderController Application 레이어 리팩토링 CreateOrderCommand OrderResult OrderSearchCommand OrderFacade 서비스가 서비스를 의존하는 방식을 줄이기 위해 추가한 클래스입니다. 이것은 개인적인 취향으로 기존 OrderService 내부에서 ProductService 를 의존해도 전혀 문제 없습니다. OrderService Domain 레이어 리팩토링 Order OrderItem OrderRepository OrderStatus Infrastructure 레이어 리팩토링 OrderItemJpaEntity OrderJpaEntity OrderJpaRepository OrderRepositoryImpl OrderSpecification 다음 글

  #spring#spring boot2026-05-03 · 3분

• [12] 커머스 프로젝트 - 장바구니 기능 리팩토링 + 중간점검

  이전 글 $1 구현 목표 도메인 레이어 추가로 인한 장바구니 기능 리팩토링 API 레이어 리팩토링 CartItemResponse CartItemUpdateRequest CartResponse CartController Application 레이어 리팩토링 CartItemResult CartResult CartSearchCommand CartUpdateCommand CartService Domain 레이어 리팩토링 Cart CartItem CartRepository Infrastructure 레이어 리팩토링 CartItemJpaEntity CartJpaEntity CartJpaRepository CartRepositoryImpl 다음 글

  #spring#spring boot2026-04-28 · 1분

• [11] 커머스 프로젝트 - 상품 기능 리팩토링 + 중간점검

  구현 목표 도메인 레이어를 추가하면서, 상품 기능을 수정합니다. API 레이어 리팩토링 ProductCreateRequest 상품 생성을 위해 외부에서 요청 받는 데이터를 나타내는 객체 상품 생성에서는 기본 상태가 ACTIVE로 입력받지 않도록 구현 ProductResponse 상품 정보를 반환하기 위한 응답 객체 ProductUpdateRequest 상품 수정을 위해 외부에서 요청 받는 데이터를 나타내는 객체 ProductController 상품 데이터는 로그인하지 않은 사람도 조회가 가능해야 합니다. 상품 생성 API는 요청을 할 때마다 새로운 상품을 생성해야 합니다. 상품 수정 API는 상품 전체 정보를 수정할 수 있어야 합니다. 상품 삭제 API는 상품을 DB에서 제거하는 것이 아닌 상태를 변경하는 방식으로 구현합니다. Application 레이어 리팩토링 ProductCreateCommand 상품을 생성할 때 사용하는 레코드입니다. ProductResult 상품에 전체적인 응답을 하기 위한 레코드 입니다. ProductSearchCommand 상품을 조회하기 위한 레코드 입니다. 현재는 상태값만 추가했습니다. ProductUpateCommand 상품을 수정하기 위한 레코드 입니다, ProductService Domain 레이어 리팩토링 Product 도메인 create 메서드는 새로운 상품을 추가할 때 사용하는 메서드입니다. 객체에 ID 설정을 하지 않기 때문에 DB에 저장할 때 새로 생기도록 구현했습니다. reconstitue 메서드는 도메인 객체로 변경하기 위한 메서드입니다. update 메서드는 Product 객체를 업데이트 하기 위해 구현했습니다. ProductStatus ProductRepository ProductStock 도메인 create 메서드는 새롭게 생성하기 위해 사용하는 메서드 입니다. reconstitute 는 도메인 객체로 변환하기 위한 메서드입니다. ProductStockRepository Infrastructure 레이어 리팩토링 ProductJpaEntity Domain 레이어에서 update 를 구현한 것과 중복되는 내용이다. 이것은 추후 다시 수정을 진행해야 합니다. ProductQuery Product 와 ProductStock 의 관계를 끊어 JPA 기능으로 한번에 쿼리하기 위해 생성하는 DTO 레코드 ProductJpaRepository JpaRepository 를 상속 받는 인터페이스 입니다. ProductRepositoryImpl Domain 레이어에서 선언한 ProductRepository 를 구현하는 구현체입니다. ProdcutStockJpaEntity ProductStockJpaRepository JpaRepository를 상속받는 인터페이스입니다. ProductStockRepositoryImpl Domain 레이어에서 선언한 ProductStockRepository 를 구현하는 클래스 ProductStockJpaRepository, QueryDSL 클래스를 주입받아 DB 작업을 진행합니다.

  #spring#spring boot2026-04-28 · 4분

• [10] 커머스 프로젝트 - 토큰에서 user_id 추출하여 수정하기

  이전 글 $1 구현 목표 Cart 기능에 하드코딩된 user\id 교체 진행합니다. Order 기능에 하드코딩된 user\id 교체 진행합니다. Payment 기능에 하드코딩된 user\id 교체 진행합니다. 인증 객체를 @AuthenticationPrincipal 객체로 컨트롤러에서 주입 받습니다. Cart 리팩토링 Controller 리팩토링 전체 조회 기능에 사용자의 카트 목록만 조회할 수 있도록 수정합니다. 장바구니 수정 기능에 토큰에서 전달 받은 user\id 값을 사용하도록 수정합니다. Service 리팩토링 전체 조회 기능에 사용자의 카트 목록만 조회할 수 있도록 수정합니다. 장바구니 수정 기능에 토큰에서 전달 받은 user\id 값을 사용하도록 수정합니다. Order 리팩토링 Controller 리팩토링 전체 조회 기능에 사용자의 주문 목록만 조회할 수 있도록 수정합니다. 주문 추가 기능에 토큰에서 전달 받은 user\id 값을 사용하도록 수정합니다. Service 리팩토링 Payment 리팩토링 Controller 리팩토링 Service 리팩토링 다음 글

  #spring#spring boot2026-04-27 · 2분

• [9] 커머스 프로젝트 - 인증 서버 연결하기

  이전 글 $1 구현 목표 기존 인증 서버와 연동하여 로그인을 구현합니다. 인증 서버에서 발급받은 토큰을 사용해 user\id를 사용하도록 수정합니다. SecurityConfig 기존에 구현한 인증 서버가 있어서 리소스 서버는 구현하기 어렵지 않습니다. 인증 서버의 주소와 CORS 설정을 진행해줍니다.

  #spring#spring boot2026-04-26 · 1분

• [7] 인증 서버 구현하기 - 토큰에 user_id 추가하기

  이전 글 $1 구현 목표 다양한 서비스에서 user\id 를 사용하기 위해 토큰에 추가하여 반환하도록 구현합니다. AuthorizationServerConfig

  #spring#spring boot#oauth#인증서버2026-04-26 · 1분
• 프로젝트

  [8] 커머스 프로젝트 - 도메인 레이어 추가

  이전 글 $1 구현 목표 기존 DDD + 레이어드 아키텍처를 사용하는 방식에서는 재고 차감, 주문 상태 변경, 결제 상태 변경 같은 기능을 서비스 레이어에서 담당하고 있었습니다. 이러한 기능은 도메인 객체에서 수행하면 코드의 가독성이 좋아질 것이라고 판단했습니다. 기존 레이어드 아키텍처에 도메인 레이어를 추가하는 방식으로 구현했습니다. 프로젝트 디렉터리 구조 API 레이어 HTTP 요청을 받고 응답을 보내는 역할을 합니다. DTO는 외부에 노출하기 위한 객체입니다. Request - Command 처럼 내부 비즈니스 요청으로 변환합니다. Result - Response 처럼 내부 비즈니스 결과를 외부에 응답하기 위해 변환합니다. application 레이어 트랜잭션을 관리하고 도메인 객체와 인프라 서비스를 조합합니다. DTO는 서비스 내부에서만 사용하는 객체입니다. Repository Interface 객체는 도메인 객체를 조회/저장하기 위한 인터페이스입니다. domain 레이어 핵심적인 규칙이 담긴 곳입니다. Domain VO는 데이터베이스와 무관한 순수 자바 객체입니다. 자신에 대한 상태를 검증하고 로직을 수행합니다. 외부 레이어에 의존하지 않도록 구현합니다. infrastructure 레이어 JpaEntity는 DB 테이블 구조와 매핑되는 클래스입니다. JPA 에서 사용하는 어노테이션을 적용합니다. RepositoryImpl는 application 레이어에서 정의한 인터페이스를 실제로 구현하는 클래스입니다. JpaRepository, QueryDSL을 사용해 데이터를 조회/저장하고, 도메인 객체로 변환하여 application 레이어로 전달합니다. 데이터 변환 흐름 다음 글

  #spring#spring boot2026-04-26 · 2분
• 프로젝트

  [7] 커머스 프로젝트 - 리팩토링 진행

  API 공통 응답 클래스로 통일 API 응답 코드 중에서 공통 클래스를 사용하지 않은 코드가 있어 수정을 진행합니다. 변경된 Order 컨트롤러 코드 변경된 Payment 컨트롤러 코드 주문 전체 조회에서 N+1 문제 주문 엔티티에 Lazy 로딩 설정으로 상품 목록(중간 테이블)을 가지고 있습니다. Fetch Join을 사용해 조회에서 바로 가져올 수 있도록 수정을 진행합니다. 변경된 OrderRepository 코드 결제 서비스 수정 기존 코드에서는 상품 상태도 관리를 했습니다. 결제 서비스에서는 결제에 대한 상태 관리만 가능하도록 수정했습니다. 변경된 PaymentService 코드 다음 글 $1

  #spring#spring boot2026-04-24 · 1분
• 프로젝트

  [6] 커머스 프로젝트 - 장바구니 기능 구현

  이전 글 $1 구현 목표 $1 에서 누락된 설계 구현 테스트를 위해서 주문을 어떻게 만들어야 하는지 생각하는 과정에서 발견한 문제 장바구니를 추가하여 구매할 상품 목록을 만들고, 한번에 결제할 수 있도록 구현 데이터 베이스 ERD 데이터 베이스 스키마 시퀀스 다이어그램 장바구니 초기 설정 처음 장바구니를 이용하는 사람을 위해 빈 장바구니를 조회합니다. 이때 DB에 비어있는 카트 데이터를 저장하지 않도록 구현합니다.(정말 빈 값만 반환) 데이터가 있는 이용자인 경우 DB에서 조회하여 반환합니다. 상품 담기 / 수량 변경 장바구니에서 상품의 재고 수량을 확인하지만 데이터의 변경은 구현하지 않습니다. 누군가 악의적으로 장바구니에 추가할 때 상품 재고가 남아있지 않는 문제가 발생하는 것을 예방하기 위해서 입니다. 개별 아이템 삭제 Entity 구현 Cart 엔티티 구현 CartItem 엔티티 구현 서비스 구현 회원 아이디의 경우 인증 서버를 연결하기 전으로 임시 아이디로 사용합니다. 컨트롤러 구현 다음 글 $1

  #spring#spring boot2026-04-23 · 2분
• 프로젝트

  [5] 커머스 서비스 - 결제 기능 구현

  이전 글 $1 구현 목표 주문을 완료한 이후 결제를 위한 기능을 구현한다. 사용자가 주문을 취소하거나, 결제에 문제가 생기는 경우 데이터의 상태 처리를 적절하게 처리한다. 주문 - 결제 시퀀스 다이어그램 머리로만 생각해서 구현하려다 보니 막히는 부분이 너무 많아서 다이어그램을 작성했습니다. 해당 시퀀스 다이어그램은 환불 단계 이전을 나타내고 있습니다. 주문이 취소(CANCLED)되는 경우 사용자가 결제 도중에 중단했다. 일정 시간 동안 주문 상태가 PENDING 상태이다. 사용자가 결제 환불을 진행했다. 결제가 취소(FAIELD)되는 경우 사용자가 결제 도중에 중단했다. 일정 시간 동안 결제 상태가 PENDING 상태이다. PG사에서 결제 승인 거부했다. 결제 서비스 진행에서 에러가 발생했다. 결제 진행 시퀀스 다이어그램 주문 생성과 결제 실패 시퀀스 다이어그램 결제에 실패하는 경우를 나타내는 시퀀스 다이어그램입니다. 주문 생성과 결제 실패의 재시도 시퀀스 다이어그램 결제에 실패한 이후 재시도를 위한 시퀀스 다이어그램입니다. 사용자가 결제창을 이탈하는 경우를 나타내는 시퀀스 다이어그램입니다. 사용자가 주문과 결제를 취소하는 것으로 판단합니다. Front 에서 확실하게 제어하고 싶었는데, 네트워크가 끊기거나, 강제로 종료하는 경우 처리하는 방법을 찾지 못해 Scheduler 를 통해서 처리했습니다. <br / Entity 구현 PaymentStatus enum 결제 상태를 나타내는 enum 입니다. PENDING 상태는 결제를 시작하면 생성되는 기본 상태입니다. APPROVED 상태는 결제가 승인되면 설정되는 상태입니다. FAILED 상태는 결제가 실패하면 설정되는 상태입니다. REFUNED 상태는 사용자가 환불을 진행하는 경우 설정되는 상태입니다. Payment 서비스 구현 현재 구현은 PG 외부 API를 구현하지 않은 상태로 서비스가 제대로 작동하는지 확인하기 위해서 임시 결제를 처리할 수 있도록 구현하였습니다. 결제 요청과 컨트롤러 구현 다음 글 $1

  #spring#spring boot2026-04-23 · 2분
• 프로젝트

  [4] 커머스 프로젝트 - 주문 CRUD 기능 구현

  이전 글 $1 구현 목표 주문을 생성할 수 있다. 주문 목록을 조회할 수 있다. 주문을 취소할 수 있다 Entity 구현 OrderStatus enum 구현 PENDING 상태는 주문을 생성하면 기본적으로 설정됩니다. 주문 취소가 가능합니다. CONFIRMED 상태는 결제가 승인된 이후 설정됩니다. 결제 환불이 가능합니다. CANCELLED 상태는 주문 취소 혹은 결제 환불이 완료된 이후 설정됩니다. COMPLETED 상태는 배송이 완료된 이후 설정됩니다. Order 엔티티 구현 주문 서비스는 Order 엔티티를 주로 사용하게 될 예정으로 OrderItem 엔티티를 조회하기 위해 OneToMany 설정을 추가했습니다. OrderItem 엔티티 구현 Order 엔티티와 Product 엔티티의 중간 테이블 역할을 합니다. 하나의 주문에는 여러 개의 상품을 추가할 수 있기 때문에 추가하게 되었습니다. 서비스 구현 주문 생성 기능에서 동시성 처리를 구현하지 않은 상태입니다. 동시성 문제가 발생하는지 직접 확인한 이후에 처리를 구현할 예정입니다. 주문 삭제 기능은 DB에서 실제로 삭제하는 것이 아닌 상태를 변경하는 방식으로 구현했습니다. 주문 수정 기능은 구현하지 않았습니다. 주문을 취소하고 재주문을 하는 방식으로 구현할 예정입니다. 회원 아이디의 경우 현재는 임의로 UUID를 생성하여 넣어주고 있습니다. 추후 인증 서버와 연동 하면서 구현을 진행할 예정입니다. 다음 글 $1

  #spring#spring boot2026-04-22 · 2분
• 프로젝트

  [3] 커머스 프로젝트 - 상품 CRUD 기능 구현

  이전 글 $1 구현 목표 상품을 등록할 수 있어야 한다. 상품을 수정할 수 있어야 한다. 상품을 삭제할 수 있어야 한다. 상품 목록을 조회할 수 있어야 한다. Entity 구현 ProductStatus enum 구현 현재 상품의 상태를 나타내는 enum 클래스입니다. ACTIVE 상태이면 조회를 하도록 구현할 예정입니다. Product 엔티티 구현 ProductStock 엔티티를 Product 엔티티에서 관리하도록 구현했습니다. 이유는 상품 로직은 대부분 Product 엔티티를 사용하기 때문입니다. ProductStock 엔티티 구현 Deprecated 어노테이션이 붙은 메서드는 삭제를 진행해야 합니다. increase, decrease 방식으로 구현하는 것이 내부에서 처리할 수 있다는 장점이 있어 안전하다고 판단했습니다. ProductStock 엔티티를 따로 분리한 이유는 재고 감소 로직에서 비관적 락 혹은 낙관적 락을 사용해 동시성 문제를 해결할 때 업데이트를 하기 위한 DB만 락을 적용할 수 있습니다. 서비스 구현 상품 서비스 자체에는 크게 어려운 구현 부분이 없습니다. 컨트롤러 구현 다음 글 $1

  #spring#spring boot2026-04-22 · 2분
• 프로젝트

  [2] 커머스 프로젝트 - 공통 처리 코드 추가

  이전 글 $1 구현 목표 API 응답 데이터를 일관성 있도록 반환하기 위해 구현 공통 에러 처리를 위해 구현 공통 응답 객체 구현 제네릭 타입을 사용해서 여러 타입의 데이터를 응답할 수 있도록 공통 레코드 구현합니다. 앞으로 API 응답 데이터는 모두 ApiResponse 객체와 ResponseEntity 객체에 담아서 응답합니다. 공통 에러 처리 에러 코드 enum 구현 지금 선언한 에러 코드는 개발을 진행하면서 수정될 수 있습니다. 커스텀 예외 클래스 구현 CommerceException 는 RuntimeException 를 상속받아 구현하는 클래스입니다. 어떤 에러가 발생했는지 가독성이 좋아지고, 예외 처리를 구체적으로 할 수 있습니다. 공통 예외 처리 클래스 구현 ExceptionHandler 어노테이션을 이용해 예외 클래스마다 다양한 구현이 가능합니다. RestControllerAdvice 어노테이션을 이용해 적용 Controller을 설정할 수 있습니다. 다음 글 $1

  #spring#spring boot2026-04-22 · 1분
• 프로젝트

  [1] 커머스 프로젝트 - 기초 작업

  프로젝트 목적 면접을 통해 기존에 진행했던 커머스 프로젝트에 대한 이해에 대한 부족함을 극복하기 위한 프로젝트입니다. 모놀리스 아키텍처에서 마이크로서비스 아키텍처로 변환하는 과정을 경험하기 위해 처음은 모놀리스 아키텍처로 구현을 진행합니다. 마이크로서비스 아키텍처에서 발생하는 문제들을 직접 경험하고 해결해보기 위한 프로젝트 입니다. Kafka 메시지 서비스를 적용하고 알아보기 위한 프로젝트입니다. 이전 글에서 구현한 인증 서버를 적용하기 위한 프로젝트입니다. 백엔드 기술에 대한 글이며, 프론트 기술에 대한 상세한 설명은 제외했습니다. 기술 스택 Backend 분류 기술 버전 :----------- :-------------------------- :---- Language Java 21 Framework Spring Boot 4.0.5 Web Spring MVC - Validation Spring Validation - ORM Spring Data JPA - Batch Spring Batch - DB Migration Flayway - Monitoring Spring Actuator, Prometheus - Frontend 분류 기술 버전 :-------- :----------- :----- Framework Next.js 16.2.4 Language Typescript 5 Styling Tailwind CSS 4 Runtime React 19.2.4 Database 분류 기술 용도 :-------- :--------- :----- RDBMS PostgreSQL 운영 서버 In-Memory H2 개발/테스트 NoSQL Redis 캐싱 <br / 화면 흐름 시스템 아키텍처 모놀리식 아케텍처로 구성 주문, 결제 상태 변경 플로우 <br / 데이터 베이스 ERD <br / DB 스키마 쿼리 작성 다음 글 $1

  #커머스#spring#spring boot2026-04-21 · 2분
• 프로젝트

  [6] 인증 서버 구현하기 - OAuth2 소셜 로그인 구현하기

  이전 글 $1 Json 핸들러 구현 SecurityConfig 에서 하드 코딩 되어 있던 인증 성공, 실패 기능을 핸들러 클래스로 분리합니다. 1. JsonAuthenticationSuccessHandler 구현 2. JsonAuthenticationFailureHandler 구현 3. SecurityConfig 적용 Google 소셜 로그인 구현 기존 회원가입 기능이 있는 상황에서 소셜 로그인을 구현합니다. 소셜 로그인하는 사용자는 기존 회원가입 절차 없이 자동으로 계정이 생성되어야 합니다. 같은 이메일로 기존 회원가입을 했던 사용자는 소셜 로그인을 했을 때 기존 계정과 통합해야 합니다. 1. 소셜 로그인 서비스 구현 먼저 oauth2-client 라이브러리를 사용하도록 설정합니다. 소셜 로그인과 기존 회원가입을 동기화 하기 위한 코드를 작성합니다. 2. oauth2Login 메서드를 설정한다 SecurityConfig 설정에 추가합니다. 3. application.yml 파일에 Provider 설정 작성자는 Google 로그인을 구현했습니다. 환경 설정 주입 방식으로 구현했습니다. 사용 방식에 따라서 추가적인 설정은 아래 참고 자료에서 확인합니다. 테스트용 UI 1. index.html 2. server.js 참고 자료 $1 $1

  #oauth2#spring#소셜로그인#인증서버2026-04-20 · 2분
• 프로젝트

  [5] 인증 서버 구현하기 - Spring Session Redis 적용하기

  이전 글 $1 <br / 현재 문제점 1. 인증 서버 재시작 시 세션 유지가 불가능하다. 2. 수평 확장(다중 인스턴스 실행) 시 세션 공유가 불가능하다. 이 문제들을 해결하기 위해서 Spring Session Redis 라이브러리를 적용합니다. Spring Session Redis 적용 1. 라이브러리를 적용합니다. 2. 세션 설정 파일을 구현합니다 3. CustomUserDetailsService 수정하기 기존에 CustomUserDetails 클래스를 직접 만들어서 사용했는데, 직렬화에 문제가 발생합니다. 이에 대한 해결책을 찾지 못하여 임시로 Spring Security 에서 제공하는 기본 User 클래스를 사용하도록 수정합니다. 문제가 발생하는 클래스는 PolymorphicTypeValidator 입니다. 테스트 테스트를 진행하기 위해서 redis 를 실행합니다. 아래 docker-compose.yml 은 redis에 비밀번호를 설정하지 않았으므로 운영 환경에서 사용하지 말아야 합니다. 로그인을 완료 하면 세션 설정 파일에서 지정한 key로 Redis 에서 조회하면 아래와 같이 조회가 완료된다. 쿠키에 세션 정보가 저장되고 있다. <br / 다음 글 <https://rudy.it.kr/post/cmo6joe2r000d13yrx2ydbswt 참고 자료 <https://docs.spring.io/spring-session/reference/configuration/redis.html

  #spring#session#인증서버#redis2026-04-17 · 2분
• 프로젝트

  [4] 인증 서버 구현하기 - RegisterClientRepository DB 저장으로 수정하기

  이전 글 $1 RegisteredClientRepository 구현체 변경 Spring Security는 RegisterdClientRepository 인터페이스 객체를 구현하는 기본 클래스 2가지를 제공합니다. InMemoryRegisteredClientRepository는 메모리에 클라이언트 정보를 담아 수정하기 위해서 서버를 종료해야합니다. JdbcRegisteredClientRepository는 JdbcOperations 인터페이스 객체를 사용하여 RegisteredClient 인스턴스를 영구 저장하는 JDBC 구현체입니다. AuthorizationServerConfig 설정에 적용 사용자 인증을 위한 기능으로, AuthorizationServerConfig 클래스에 설정을 적용해야 합니다. JdbcRegisterdClientRepository를 사용해 구현을 진행합니다. 설정 객체 구현 1. 환경 설정에 변수를 추가합니다. 2. 설정값을 사용 위해서 컴포넌트 클래스를 추가합니다. JdbcRegisterdClientRepository 사용 구현 1. AuthorizationServerConfig 에서 구현한 메서드를 수정해줍니다. DB 스키마 추가 JdbcRegisterdClientRepository 에서 DB를 연결하기 위해 테이블을 추가해야 합니다. 공식 문서에 DB 스키마에 대한 정보가 나와 있습니다. 에러 처리 추가 클라이언트에서 /oauth2/authorize 처리 진행 중에 서버에게 제어권이 넘어가도록 되어있습니다. authorize 요청에서 파라미터 요청에 대한 검증에 실패하면 아래와 같은 페이지가 나타납니다. OAuth2 공식 문서를 확인했을 때 '권한 부여 서버는 리소스 소유자에게 오류를 알려야 하며, 사용자 에이전트를 유효하지 않은 리디렉션 URI로 자동으로 리디렉션해서는 안 됩니다.' 라고 명시되어 있습니다. 그렇다면 서버 사이드에서 JSON 데이터로 에러 메시지와 코드를 반환하는 방식과, UI를 만들어 출력하도록 구현하는 방법이 있습니다. 작성자는 UI를 만들어 출력하도록 구현했습니다. 서버 로직 구현 1. 에러 핸들러 구현 추가 /oauth2/authorize 요청에 대해 에러 처리를 담당하는 AuthenticationFailureHandler 인터페이스를 상속 받아 핸들러를 구현합니다. 2. Thymeleaf 를 위한 컨트롤러 구현 /oauth/error API를 서버 내부에서 처리하여 UI를 출력하기 위한 컨트롤러를 구현합니다. oauth-error.html 코드 해당 html 코드는 resources/templates 에 위치합니다. 다음 글 $1 참고 자료 $1\ $1\ $1 <https://datatracker.ietf.org/doc/html/rfc6749section-4.1.2.1

  #spring#security#인증서버2026-04-16 · 3분
• 프로젝트

  [3] 인증 서버 구현하기 - RSA키를 환경 설정으로 사용하기, Security 설정 리팩토링

  이전 글 $1 <br / 현재 RSA키는 서버를 재실행하면 계속해서 변경이 되어버리기 때문에 모든 사용자가 발급받은 토큰이 무효화된다. 이를 해결하기 위해서 환경 설정을 활용해보자. RSA키를 DB에 저장해보자 Key 발급 받기 1. 아래 명령어로 private.pem, public.pem 파일을 순서대로 생성합니다. 2. public.pem 내용에서 헤더 내용을 제거한 내용을 기억합니다. 3. Spring 프로젝트 환경 설정(application.yml)에 설정해줍니다. SecurityConfig 설정 수정 1. RsaProperty 컴포넌트 클래스를 구현합니다 2. SecurityConfig 에서 JWT에 서명에 RSA 키를 사용하기 위해 등록하는 메서드를 수정합니다. keyID() 설정은 JWT 헤더에 들어가는 이 토큰은 어떤 키로 서명했는지를 나타내는 식별자입니다. Authorization Server 는 /.well-known/jwtk.json 엔드포인트로 공개키 목록을 제공합니다. 검증에 사용하기 때문에 고정값으로 지정해서 설정합니다. test-client 수정 진행 테스트를 위해서 Client 코드를 수정해줍니다. 1. server.js 코드 수정 2. index.html 수정 SecurityConfig 분리 여기까지 수정 완료된 상태에서 SecurityConfig 코드를 분리할 것입니다. 1. AuthorizationServerConfig 클래스를 생성합니다. 해당 클래스는 등록한 SecurityFilter 에서 가장 먼저 실행하도록 추가합니다. OAuth2/OIDC 관련 엔드포인트에 대해서만 처리하며, 이외에 엔드포인트는 무시합니다. 매칭된 엔드포인트에서 인증되어 있지 않다면, 'http\://localhost:3000/login' 경로로 리다이렉트 합니다. 2. ResourceServerConfig 클래스를 생성합니다. 3. 남아있는 SecurityConfig 에서 필요없는 코드를 정리합니다. 인증 절차 <br / 다음 글 $1

  #spring#security#인증서버2026-04-16 · 2분
• 학습

  Spring Security의 필터에 대해 알아보자

  인증 로직 파악 Spring Security는 서블릿 필터 기반으로 동작합니다. 따라서 제대로 이해하기 위해서 필터 체인의 구조와 역할을 파악해야 합니다. 클라이언트가 서버로 HTTP 요청을 보내면, 서블릿 컨테이너는 다음과 같은 흐름으로 요청을 처리하게 됩니다. 1. 요청 URI를 기반으로 어떤 자원을 처리할지 결정 2. 해당 요청을 처리할 필터 체인 생성 3. 필터들을 순서대로 실행 4. 최종적으로 서블릿 실행 - Spring MVC에서는 DispatcherServlet이 해당 역할을 수행합니다. Client → Filter Chain → DispatcherServlet → Controller 필터의 핵심 역할 필터는 서블릿에 도달하기 전 단계에서 요청/응답을 가로채어 다양한 작업을 수행합니다. 핵심 역할은 크게 두 가지로 분류됩니다. 필터는 다음 필터 또는 서블릿으로 요청을 전달하지 않고 중단할 수 있습니다. 대표적인 예로 인증되지 않은 사용자 요청 차단, 권한이 없는 사용자 접근 제한인 경우가 있습니다. 이 경우 필터는 직접 응답을 생성하여 클라이언트에게 반환합니다 Client → Filter Chain → Filter(차단) - Response 반환 필터는 HttpServletRequest 와 HttpServletResponse 가공이 가능합니다. 예를 들어 JWT 토큰 파싱 후 사용자 정보를 추가, 요청 헤더 수정, 응답 헤더 추가(CORS, 보안 헤더 등)이 있습니다. Client → Filter Chain → Filter (가공) → 다음 Filter → Servlet 필터 체인의 특징 필터 체인에는 여러 개의 필터가 존재할 수 있습니다. LoggingFilter → JwtAuthenticationFilter → AuthorizationFilter → DispatcherServlet 필터 체인에 추가된 필터 순서에 따라서 동작 결과가 달라지기 때문에 주의해야 한다. 예를 들어 인증 필터보다 권한 필터가 먼저 실행되면 인증 정보가 없는 상태에서 오류가 발생하기 때문입니다. 필터 체인은 체인 기반으로 실행하는 구조로 동작하여 이러한 구조 덕분에 요청 전/후 처리가 가능하고, AOP와 유사한 흐름 제어가 가능합니다. 아래는 필터가 실행되는 코드입니다. 필터 성능 필터는 요청마다 실행되므로 필터 체인이 길어질수록 처리하기 위한 비용이 증가합니다. 불필요한 필터 추가는 성능 저하로 이어지며, 반드시 필요한 필터만 유지해야 합니다. 필터에서는 DB 접근을 최소화하고, 복잡한 로직을 지양하며, 캐시를 활용하는 방법도 좋습니다. Spring Security 에서 필터란 Spring Security는 필터 구조 위에 인증, 보안, 세션 관리, CSRF 보호 같은 보안 기능을 추가합니다. 즉 내부적으로 수십 개의 필터 체인을 구성하여 동작합니다. 예를 들어 'UsernamePasswordAuthenticationFilter', 'BearerTokenAUthenticationFilter' 등이 있습니다. DelegatingFilterProxy DelegatingFilterProxy는 서블릿 컨테이너와 스프링 컨테이너를 연결하는 '다리' 역할을 합니다. 기본적으로 서블릿 컨테이너(Tomcat 등)는 자신만의 규칙으로 필터를 관리하기 때문에, 스프링이 관리하는 빈(Bean) 객체들을 직접 인식할 수 없습니다. 이를 해결하기 위해 스프링은 표준 서블릿 필터를 구현한 DelegatingFilterProxy를 제공합니다. 이 대리자는 톰캣으로부터 요청을 전달받은 뒤, 실제 보안 로직을 가진 스프링 빈을 찾아 처리를 위임합니다. <br / Client - Filter - DelgatingFilterProxy(Bean Filter) - ... DelegatingFilterProxy의 또 다른 장점은 필터 빈 인스턴스 조회 시간을 지연시킬 수 있습니다. 서블릿 기반 애플리케이션 에서는 아래와 같은 초기화 순서를 가집니다. 1. 서블릿 컨테이터 시작 2. 필터 등록 및 초기화 3. Spring Context 로딩 (ContextLoaderListener) 여기서 문제가 발생하는데, 필터는 컨테이너 시작 시점에 먼저 생성 및 등록되지만 Spring Bean 은 그 이후에 생성됩니다. 즉 일반적인 방식으로는 필터에서 Spring Bean을 바로 주입 받을 수 없습니다. 이 문제를 해결하기 위해서 컨테이너에는 DelegatingFilterProxy만 미리 등록하고, 실제 필터 Bean은 Spring Context 로딩이 완료된 이후 생성되도록 구현합니다. 필터에 요청이 들어오는 시점에 Bean을 조회하여 위임하도록 설계되어 있습니다. FilterChainProxy Spring Security 내부에서는 실제 보안 필터들이 DelegatingFilterProxy에 직접 연결되는 것이 아닌 FilterChainProxy를 중심으로 관리됩니다. FilterChainProxy는 모든 서블릿 보안 기능이 시작되는 핵심 진입점입니다. 따라서 인증/인가와 강튼 보안 문제를 분석할 때는 FilterChianProxy에 디버깅 포인트를 잡는 것이 가장 좋습니다. FilterChainProxy는 단순 라우팅이 아니라 필수 보안 작업을 수행합니다. 예를 들어 SecurityContext, HttpFirewall 등이 있습니다. 일반 서블릿 필터는 URL 기반으로 동작하지만 FilterChainProxy의 경우 RequestMatcher 기반으로 다양한 요청 방법으로 매칭 가능합니다. 예를 들어 HTTP Method, Header, 파라미터, 경로 패턴이 있습니다. SecurityFilterChain SecurityFilterChain은 HTTP 요청에 대해 어떤 Spring Security 필터들을 실행할지 결정하는 기준이 됩니다. 특정 요청 조건(RequestMatcher)에 매칭되고, 그 요청에 적용할 필터 목록을 정의하는 객체라고 볼 수 있습니다. DelegatingFilterProxy → FilterChainProxy → SecurityFilterChain → Security Filters 보안 필터들은 일반적으로 Spring Bean으로 등록되지만, DelegatingFilterProxy 대신 FilterChainProxy 내부에서 관리합니다. Multiple SecurityFilterChain SecurityFilterChian은 여러개를 추가할 수 있습니다. 이때 FilterChainProxy는 어떤 SecurityFilterChain을 사용할지 결정하는 역할을 합니다. 이때 중요한 규칙은 다음과 같습니다. 조건에 매칭되는 첫 번째 SecurityFilterChain만 실행된다는 점입니다. 예를 들어 '/api/messages' 요청이 들어온 경우 먼저 SecurityFilterChain0의 '/api/\\' 패턴과 매칭되어 SecurityFilterChain0만 실행되고 이후 체인은 검사하지 않습니다. 즉, 뒤에 있는 SecurityFilterChain(n)은 매칭이 되더라도 실행되지 않습니다. 이 동작 방식 때문에 SecurityFilterChain을 구성할 때는 우순위와 패턴 설계가 매우 중요합니다. 참고 자료 $1

  #Spring#Security#인증서버2026-04-15 · 8분
• 프로젝트

  [2] 인증 서버 구현하기 - 로그인, 회원 인증 수정

  들어가기 전에 아래 글에서 이어서 작성합니다. $1 인증 서버 로직 수정 이번 글에서는 아래의 내용을 수정해봅니다. 회원 관련 인증 로직 수정 CORS 설정 진행 127.0.0.1 로 설정된 URL 을 localhost 로 통일 Spring 에서 제공하는 UI에서 프론트에서 제공하는 UI를 사용하기 위해 수정 <br / 로그인 인증 로직 수정 진행 코드를 설명하기 이전에 이번 글에서 작성하는 모든 코드를 미리 소개합니다. User 엔티티 생성 UserDetails 인터페이스 상속 받아 구현 UserDetailsService 인터페이스 상속 받아 구현 SecurityConfig 설정 변경 authorizationServerSecurityFilterChain 메서드 수정 기존 Spring Boot 서버에서 제공하던 UI 엔드포인트가 아닌 프론트에서 만든 UI를 사용하기 위해 인증되어있지 않은 요청이 있다면, 경로로 이동하도록 구현. MediaTypeRequestMatcher에 TEXT\HTML 설정은 프론트에서 Accept 헤더가 text/html 형태인 경우 작동하도록 설정한 것이다. defaultSecurityFilterChain 메서드 수정 CSRF 관련 기능은 다른 글에서 설정합니다. 현재는 사용하지 않도록 설정합니다. CORS 설정은 서버와 프론트의 Origin 정보가 다르기 때문에 설정을 진행해야 한다. loginProcessingUrl은 프론트가 로그인 요청을 보내는 API 엔드포인트입니다. 응답 데이터는 JSON으로 반환해야 프론트 로그인 페이지에서 처리할 수 있기 때문에 성공, 실패 핸들러를 커스텀으로 설정해줍니다. CorsConfigurationSource 메서드 추가 프론트의 Origin 정보를 입력해서 허용해줍니다. UI 수정 server.js index.html 마무리 1. 클라이언트 설정이 코드에 하드코딩되어 있다. 클라이언트 수정을 위해서 코드를 변경하고 재실행해야 한다. 2. 서버를 재시작하면 기존에 발급된 토큰이 모두 무효화된다. JWT 서명에 사용하는 RSA 키 쌍이 재시작할 때마다 새로 생성되어 발생하는 문제이다. 3. SPA 환경에서 인증이 불가능하다. 클라이언트 인증 방식이 'client\secret\basic'으로 고정있어 보안상 위험 설정에서 PKCE가 강제되지 않는다. 4. 다중 인스턴스 환경에서 SSO가 동작하지 않는다. 인증 서버의 로그인 세션이 각 인스턴스 메모리에 따로 저장되어 발생하는 문제 참고 자료 $1

  #spring#authorization#oauth2#인증서버2026-04-15 · 3분
• 프로젝트

  [1] 인증 서버 구현하기 - 기초 설정

  들어가기 전에 기본적으로 참고 자료를 사용해서 구현을 진행합니다. 일부 코드 수정이 있으며, 구현하면서 발견했던 트러블 슈팅에 대한 내용은 아래에서 작성했습니다. 인증 서버 구축 시작하기 전에 프로젝트에 라이브러리를 설치하자 Security Config 설정 해당 예제는 공식 문서에 작성된 코드에서 문제가 생기는 부분을 수정한 코드이다 테스트를 위한 페이지 추가 해당 페이지는 SPA 환경이 아닌 MPA 환경으로 Spring 에서 CORS나 PKCE 설정을 안해도 문제없이 UI 테스트가 가능하도록 작성했다. 물론 SPA 환경에서 테스트 하려면 Spring 에서 수정할 코드가 생긴다. 폴더 트리 package.json server.js index.html 트러블 슈팅 로그인이 지속적으로 실패하는 경우 Password Encoder 설정을 확인하자. 테스트 페이지에서 테스트할 때 문제가 발생하는 경우 마무리 지금 구현한 인증 서버는 동작 확인을 위해 최소한의 설정만 갖춘 상태입니다. 실제 서비스에 적용하기 위해서는 아래 내용을 인지하고 보완해야 한다. 1. 로그인 계정이 코드에 하드코딩되어 있다. 회원가입, 비밀번호 변경 등 동적인 사용자 관리가 불가능하다. 2. 클라이언트 설정이 코드에 하드코딩되어 있다. 클라이언트 수정을 위해서 코드를 변경하고 재실행해야 한다. 3. 서버를 재시작하면 기존에 발급된 토큰이 모두 무효화된다. JWT 서명에 사용하는 RSA 키 쌍이 재시작할 때마다 새로 생성되어 발생하는 문제이다. 4. SPA 환경에서 인증이 불가능하다. 클라이언트 인증 방식이 'client\secret\basic'으로 고정되어 있다. 설정에서 PKCE가 강제되지 않는다. CORS 설정이 없다. 5. 다중 인스턴스 환경에서 SSO가 동작하지 않는다. 인증 서버의 로그인 세션이 각 인스턴스 메모리에 따로 저장되어 발생하는 문제 다음 글 $1 참고 자료 $1\ $1

  #spring#spring boot#authorization#인증서버#oauth22026-04-14 · 2분
• 학습

  Spring Authorization Server 간단히 살펴보자

  기술 스택 Spring Authorization Server 1.5.6 Spring Boot 7.0.4 해당 글을 작성하는 이유 Spring Authorization Server 라이브러리를 사용하여 자체적인 인증 서버를 구축하고 싶어 프로젝트를 시작했고, 어떻게 구현해야 할지 모르는 상황에서 AI를 사용해 진행하다 보니 수정이 불가능한 상황에 도달했다. 수정하기 위해서는 라이브러리의 동작 방식과 어떤 설정이 있는지 파악을 진행해야 한다는 것을 느꼈고 작성을 해본다. Spring Authorization Server 사용 사례 고급 사용자 지정 시나리오가 필요한 경우 구성 및 사용자 지정에 대한 완벽한 제어 기능을 제공합니다. 모든 기능을 갖춘 상용 제품보다 경량 인증 서버를 선호합니다. 소프트웨어 라이선스 및/또는 호스팅 비용 절감 가능성 익숙한 스프링 프로그래밍 모델을 사용하여 개발 과정에서 빠른 시작과 간편한 사용이 가능합니다. Spring Authorization Server가 제공하는 기능 Authorization Grant 권한 부여 방식은 애플리케이션이 사용자나 리소스로부터 권한을 얻어 액세스 토큰을 발급받는 일련의 절차를 의미합니다. Authorization Code 방식은 가장 많이 사용되는 표준 방식으로, 웹 서버 사이드 애플리케이션에 적합합니다. 사용자가 로그인을 완료하면 서버가 'Authorization Code'를 발급하고, 애플리케이션은 코드와 자신의 비밀키를 교환해 실제 토큰을 발급 받는 방식입니다. 브라우저에 토큰이 노출되지 않아 안전합니다. 흔히 사용하는 카카오로 로그인, 구글로 로그인이 대부분 이 방식을 사용합니다. Client Credentials 방식은 사용자가 개입하지 않는 머신 대 머신 통신에 사용됩니다. 애플리케이션 자체가 하나의 사용자처럼 동작하며 자신의 ID와 비밀키만으로 토큰을 발급받습니다. 사용자 정보가 필요 없는 백엔드 서비스 간의 통신에 주로 사용합니다. Refresh Token 방식은 기존에 발급 받은 엑세스 토큰이 만료되었을 때, 다시 로그인하지 않고 새 토큰을 얻는 방식입니다. 토큰을 발급 받을 때 함께 받은 'Refresh Token'을 권한 서버에 보내면, 서버는 이를 검증하고 새로운 'Access Token'을 발급합니다. 보안을 위해 짧게 설정된 액세스 토큰의 유효 기간을 보완하면서도 사용자의 편의성을 유지합니다. Device Code 방식은 브라우저가 없거나 입력이 제한적인 기기를 위한 방식입니다. 기기가 화면에 일련번호(User Code)와 URL을 표시하면, 사용자는 스마트폰이나 PC에서 해당 URL에 접속해 코드를 입력하고 인증합니다. TV 리모컨으로 아이디/비밀번호를 입력하는 번거로움을 해결해 줍니다. 유튜브나 넷플릭스를 TV에서 연결할 때 이용됩니다. Token Exchange 방식은 이미 가지고 있는 토큰을 권한 서버에 제출하고, 특정 대상 서비스에서만 쓸 수 있는 새로운 토큰으로 교환합니다. 서비스 간 호출 시 보안 범위를 좁히거나, 'A 서비스가 사용자를 대신해 B 서비스를 호출한다'는 대리 권한을 명확히 할 때 유용합니다. Token Formats \\Self-contained(JWT)\\는 토큰 자체에 사용자 정보, 권한, 만료 시간 등의 데이터를 담고 있는 방식입니다. 가장 대표적인 예로 JWT(JSON Web Token) 입니다. 서버가 DB를 조회하지 않고도 토큰 내의 정보(Claims)만 보고 유효성을 판단할 수 있습니다. 상태가 없는(Stateless) 아키텍처나 MSA 환경에서 서버 간 통신 비용이 줄어듭니다. 토큰이 한 번 발급되면 만료 전까지 강제로 삭제하기 어렵습니다. \\Reference(Opaque)\\는 토큰 자체에는 의미 없는 임의의 문자열만 담겨 있는 방식입니다. 서버는 이 토큰을 받으면 DB나 메모리(Redis)에서 해당 토큰과 연결된 정보를 조회해야 합니다. 서버에서 토큰을 즉시 무효화(Revoke)하기 쉽습니다. 정보가 외부에 노출되지 않아 보안에 유리합니다. 매 요청마다 저장소를 조회해야 하므로 서버 부하가 생길 수 있습니다. Token Types \\DPoP (Demonstrating Proof-of-Possession)\\는 '토큰 소유 증명' 기술입니다. 기존 Bearer 토큰의 문제점은 해커가 내 'Access Token'을 가로채기만 하면 누구든 사용할 수 있습니다. 토큰과 특정 '개인키'를 묶어 해커가 토큰을 훔쳐가더라도, 그 토큰과 쌍이 되는 개인키가 없다면 토큰은 무용지물이 됩니다. DPoP 방식에서 발급되는 'Access Token'은 특정 클라이언트의 공개키 정보와 결합되어 있습니다. JWT 형태의 토큰 내부에 해당 토큰을 사용할 수 있는 키의 식별자(Confirmation, cnf 클레임)가 포함됩니다. 1. 클라이언트(리액트 등)은 요청을 보낼 때마다 자신의 개인키로 서명한 DPoP Proof(증명서)를 헤더에 함께 담아 보냅니다. 2. 서버는 'Access Token'에 적힌 키 정보와 전송된 DPoP Proof가 일치하는지 확인합니다. 3. 일치할 때만 API 요청을 허용합니다. 토큰 탈취를 방지하거나, 보안 강화, 발급 범위 제한을 위해 사용을 고려할 수 있습니다. Client Authentication 공유 비밀번호 기반 (Shared Secret) 클라이언트와 서버가 미리 공유한 'client\secret'을 직접 활용하는 고전적인 방식입니다. client\secret\basic은 클라이언트 ID와 Secret을 'ID:Secret' 형태로 결합 후 Base64 인코딩하여 HTTP Authorization 헤더로 전송합니다. OAuth 2.1에서 가장 권장되는 기본 인증 방식입니다. client\secret\post은 ID와 Secret을 HTTP POST 바디의 파라미터(client\id, client\secret)로 전달합니다. URL이나 헤더보다 로그에 노출될 가능성이 있어 basic 보다 보안성이 낮다고 평가됩니다. JWT 기반 인증 (RFC 7523) 비밀번호를 직접 보내지 않고, 클라이언트가 생성한 JWT를 통해 인증합니다. 이를 Assertion 방식이라고도 합니다. client\secret\jwt은 공유된 'client\secret'을 대칭 키로 사용하여 JWT를 서명합니다. 서버는 동일한 Secret으로 서명을 검증합니다. private\key\jwt은 클라이언트가 자신의 비공개 키로 JWT를 서명하여 보냅니다. 서버는 미리 등록된 클라이언트의 공개 키로 검증합니다. Secret이 네트워크를 타지 않으므로 매우 안전합니다. 상호 TLS 기반 인증(mTLS, RFC 8705) HTTPS 연결 자체에서 클라이언트 인증서를 요구하여 하드웨어/네트워크 수준의 보안을 제공합니다. tls\client\auth는 신뢰할 수 있는 외부 인증 기관(CA)에서 발급받은 인증서를 사용합니다. self\signed\tls\client\auth는 클라이언트가 직접 서명한(Self-signed) 인증서를 사용하며, 서버는 해당 인증서의 지문을 미리 등록해 두고 대조합니다. 공용 클라이언트 및 보안 보완 (RFC 7636) 비밀번호를 안전하게 저장할 수 없는 환경(브라우저 기반 SPA, 모바일 앱 등)을 위한 방식입니다. \\none (Public Clients)\\은 클라이언트 암호가 없습니다. 암호가 없기 때문에 누구나 클라이언트인 척 코드를 교환하려 할 수 있습니다. \\PKCE (Proof Key for Code Exchange)\\는 none 방식의 취약점을 보완하기 위해 도입되었습니다. 인증 요청 시 임의로 생성한 'code\challenge'를 보내고, 토큰 교환 시 'code\verifier'를 보내 일치 여부를 확인합니다. OAuth 2.1에서는 보안 강화를 위해 모든 클라이언트(Public & Confidential)가 PKCE를 사용하는 것을 권장/필수화하고 있습니다. 참고 자료 1.5.7 버전 이후로 Spring Security 7 버전으로 이전되었다. $1 $1

  #Spring#Spring Boot#Authorization#인증서버2026-04-14 · 8분
• 학습

  Kafka Topic 복제

  토픽 복제 계수(Topic Replication Factor) 복제 계수(RF)는 토픽의 데이터를 몇 개의 브로커에 복사할지 결정하는 값입니다. 운영 환경에서는 3을 권장합니다. 예를 들어 브로커 3대, 파티션 2개, 복제 계수 2인 경우 각 파티션은 서로 다른 2개의 브로커에 분산 저장됩니다. Brokder 102번이 다운되더라도 파티션 0, 1 모두 다른 브로커에 복제본이 있어 서비스가 계속됩니다. 파티션 리더(Partition Leader) 토픽 복제가 이루어지면 파티션의 리더가 선출됩니다. 파티션마다 리더는 반드시 1개이며, 팔로워(복제본)은 여러개가 가능합니다. 프로듀셔는 리더 브로커에만 쓰기 작업을 진행하고, 컨슈머는 리더 브로커에서만 읽기 작업을 진행합니다. 리더가 다운되면 ISR 중 하나가 새 리더로 승격되어 서비스를 이어갑니다.

  #kafka#topic#토픽#복제#replication2026-04-13 · 1분
• 학습

  Kafka Cluster(클러스터), Broker(브로커)

  Kafka 브로커(Broker)와 클러스터? 카프카는 대규모 데이터를 안정적으로 처리하기 위해 여러 대의 서버를 하나로 묶어 운영하는 분산 시스템입니다. 그 중심에는 데이터를 저장하고 전달하는 브로커와 이들의 집합인 클러스터가 존재합니다. 브로커? 브로커는 카프카가 설치된 개별 서버를 의미합니다. 데이터를 저장하고, 전달하는 역할을 합니다. 각 브로커는 전체 클러스터 내에서 고유한 정수 ID로 구분됩니다. 특정 토픽의 데이터는 한 대의 브로커에만 저장되지 않고, 여러 파티션으로 나뉘어 모든 브로커에 골고루 분산됩니다. 덕분에 한 대의 서버가 감당할 수 없는 대용량 데이터도 처리가 가능합니다. 클러스터? 여러 개의 브로커가 모여 동작하는 집합체를 클러스터라고 합니다. 일부 브로커에 문제가 발생해도 다른 브로커가 데이터를 안전하게 보관하고 있어 중단 없는 서비스가 가능합니다. 보통 최소 3대 이상의 브로커로 구성하는 것이 권장됩니다. 데이터 처리량이 늘어나면 새로운 브로커를 추가해 클러스터의 성능을 높일 수 있습니다. 클라이언트의 연결 방식 카프카 클러스터의 가장 큰 특징은 클라이언트(컨슈머, 프로듀서)가 클러스터 내의 모든 브로커 주소를 미리 알 필요가 없습니다. 부트스트랩 서버 클라이언트는 클러스터에 포함된 브로커 중 하나의 주소만 알아도 전체 클러스터에 연결 가능합니다. 이때 연결의 통로가 되는 브로커를 부트스트랩 서버라고 부릅니다. 클라이언트가 부트스트랩 서버에 접속하면 해당 서버는 클러스터 내 모든 브로커의 ID, IP, 포트 정보 등이 담긴 메타데이터를 전달합니다. 정보를 받은 클라이언트는 이후 데이터를 실제로 주고받아야 하는 파티션이 위치한 브로커와 자동으로 통신합니다. 이러한 성질 덕분에 처리해야 하는 양이 늘어나면, 새로운 브로커를 추가하기만 하면 됩니다. 클라이언트는 별다른 설정 없이 확장된 클러스터의 모든 리소스를 활용 할 수 있습니다 파티션 분산 저장의 예시 브로커 3대로 구성된 클러스터에서 데이터가 어떻게 배치되는지 예로 알아봅시다. 토픽 A는 파티션 3개로 이루어져 있으며, 파티션 순서에 상관 없이 서로 다른 브로커에 골고루 배치됩니다. 토픽 B는 파티션 2개로 이루어져 있으며, 브로커 수보다 파티션 수가 적으므로, 브로커 2대에 각각 저장됩니다. 남아있는 브로커 1대에는 기록되지 않습니다.

  #kafka#broker#topic2026-04-12 · 3분
• 학습

  Kafka Consumer Group(컨슈머 그룹), Offset(오프셋)

  Consumer Group(컨슈머 그룹)? 카프카에서는 컨슈머들이 협력하는 단위를 컨슈머 그룹이라고 합니다. 파티션이 5개이고 컨슈머가 3개인 상황이라면, 5개의 일감을 3명이 나누어 갖는 것과 같습니다. 중요한 점은 한 파티션은 컨슈머 그룹 내에서 하나의 컨슈머만 담당합니다. 덕분에 컨슈머들은 각자의 파티션에서 데이터를 읽어오며, 결과적으로 모든 파티션의 데이터를 효율적으로 공유하여 처리하게 됩니다. 만약 컨슈머 개수가 파티션 수보다 많은 경우, 남는 컨슈머 대기 상태가 되고, 특정 컨슈머에 문제가 생기는 경우 그룹 내 다른 대기 상태인 컨슈머가 해당 파티션을 자동으로 넘겨 받아 중단 없는 처리를 이어갑니다. 대기 상태인 컨슈머가 없는 경우 컨슈머 그룹 내의 작동 중인 컨슈머가 추가적으로 넘겨받아 처리를 이어갑니다. 다중 컨슈머 그룹 하나의 토픽에 여러 컨슈머 그룹이 연결되어도 문제 없이 동작합니다. 이는 카프카가 가진 Pub/Sub 모델의 강력한 특징 중 하나입니다. 각 컨슈머 그룹은 서로 독립적입니다. 동일한 토픽의 데이터를 읽더라도, 그룹 A가 어디까지 읽었는지는 그룹 B에 전혀 영향을 주지 않습니다. 하나의 파티션은 그룹 내에서 오직 하나의 컨슈머에 할당된다는 규칙은 각 그룹 내부에서만 적용됩니다. 즉 파티션 0번의 데이터는 그룹 A의 컨슈머 1번도 읽고, 그룹 B의 컨슈머 1번도 동시에 읽을 수 있습니다. 예시로 동일한 주문 데이터를 결제 서비스 그룹과 물류 알림 서비스 그룹이 각각 독립적으로 처리해야 할 때 유용하게 사용할 수 있습니다. "컨슈머 그룹은 토픽의 데이터를 소비하는 '독립적인 단위'입니다. 덕분에 동일한 데이터를 여러 서비스가 각자의 목적에 맞게 중복 없이, 그리고 서로 방해 없이 처리할 수 있습니다." 다중 컨슈머 그룹으로 나누는 이유 하나의 토픽에 담긴 동일한 데이터를 여러 서비스가 각기 다른 목적으로 사용해야 하기 때문입니다. 예를 들어 주문 생성이라는 메시지가 발생했을 때, 알림 서비스는 메시지를 소비해 알림을 보내고, 물류 서비스는 같은 메시지를 읽어 배송 준비를 시작합니다. 각 서비스는 자신만의 group.id 를 가집니다. 이를 통해 서로 다른 서비스들이 동일한 데이터를 읽더라도, 서로에게 영향을 주지 않고 각자의 방식대로 처리할 수 있습니다. 컨슈머 오프셋 컨슈머 그룹이 단순히 '묶음' 이상의 의미를 갖는 이유는 바로 오프셋 관리에 있습니다. 카프카는 각 컨슈머 그룹이 특정 파티션의 데이터를 어디까지 읽었는지 기록합니다. 이 기록은 카프카 내부의 특수 토픽인 에 저장됩니다. 컨슈머가 데이터를 가져와 처리를 완료하면 브로커에게 알리는 커밋하는 과정을 거칩니다. 오프셋 커밋이 중요한 이유 우리가 주기적으로 오프셋을 커밋하는 이유는 시스템의 연속성을 보장하기 위해서 입니다. 컨슈머 애플리케이션에 문제가 생기는 경우, 다시 실행했을 때 카프카 브로커에 저장된 마지막 커밋 지점을 조회하여 중단된 시점부터 다시 읽기 시작할 수 있기 때문입니다. 이러한 구조 덕분에 분산 시스템 환경에서도 데이터 처리에 대한 신뢰성을 확보할 수 있습니다. 카프카 컨슈머의 데이터 전달 전략 카프카 컨슈머는 비즈니스 요구사항에 따라 메시지를 얼마나 정확하게 처리할지 결정하는 세 가지 전달 전략을 제공합니다. 기본적으로 Java 컨슈머는 \\최소 한 번(At Least Once)\\를 목표로 자동 커밋을 수행하지만, 수동 커밋을 통해 이를 제어할 수 있습니다. At Least Once 메시지가 유실되지 않도록 보장하는 가장 일반적인 전략입니다. 컨슈머가 메시지를 가져와서 비즈니스 로직 처리를 완료한 직후에 오프셋을 커밋합니다. 만약 처리 도중 에러가 발생하거나 컨슈머가 다운되어 커밋이 실패하면, 해당 메시지를 다시 읽어 오게 됩니다. 같은 메시지를 여러 번 처리하게 될 수 있어 서비스 로직이 멱등성을 유지해야 합니다. At Most Once 데이터 유실이 발생하더라도 중복 처리는 절대 없어야 할 때 사용합니다. 컨슈머가 메시지를 받자마자 즉시 오프셋을 커밋하고 로직을 수행합니다. 처리 도중 오류가 나면 해당 메시지는 이미 커밋된 상태라 다시 읽을 수 없으므로 유실됩니다. 일부 데이터가 누락되어도 시스템 전체에 큰 영향이 없는 로그 수집이나 모니터링 지표 등에 사용됩니다. Exactly Once 가장 이상적이지만 구현이 까다로운 전략입니다. 메시지 읽기-처리-쓰기 과정이 하나의 트랜잭션으로 묶여 정확히 한 번만 반영됩니다. Kafka-to-Kafka 같은 카프카 내부의 트랜잭션 API나 Kafka Streams API를 활용하면 비교적 쉽게 구현이 가능합니다. 데이터베이스나 외부 API로 데이터를 보낼 때는 멱등 컨슈머(Idempotent Consumer) 패턴을 적용해 외부 시스템에서 중복을 걸러내야 합니다.

  #kafka#카프카#이벤트#컨슈머#그룹#오프셋2026-04-11 · 5분

• Kafka Producer(프로듀서), Consumer(컨슈머)

  메시지 구조와 직렬화, 역직렬화 메시지 구조 Kafka는 네트워크 전송 효율을 위해 데이터를 바이트 형태로 주고 받습니다. 분류 필수 여부 설명 :--------------- :------- :------------------------------------------------------ Key - binary Optional null 허용 Value - binary <br / 실제 전송하는 데이터 null 허용 Compression Type Optional 데이터 압축 방식을 결정합니다. Headers Optional Key-Value 상의 리스트, 메타데이터를 바이트 형태로 담을 수 있습니다. Partition Optional 0 이상의 정수, 미지정 시 파티셔너가 결정하며, 직접 지정하면 해당 파티션으로 고정 전송 됩니다. Timestamp Optional 미지정 시 브로커 수신 시간 또는 생성 시간이 자동으로 기록됩니다 Serialize(직렬화) 직렬화는 메시지를 Kafka가 이해할 수 있도록 바이트 형태로 변환하는 작업을 말합니다. StringSerializer, IntegerSerializer, JSON/Avro Serializer 등 여러 방식이 존재합니다. Kafka 에서는 메시지의 Key, Value 각각 직렬화 방식을 설정해야 합니다. DeSerialize(역직렬화) 역직렬화는 메시지를 애플리케이션이 이해할 수 있도록 복원하는 과정을 말합니다. 컨슈머가 데이터를 정상적으로 읽기 위해서 프로듀서가 사용한 직렬화 방식과 동일한 역직렬화 설정이 필요합니다. 만약 데이터의 형식이 일치하지 않는다면 'SerializationException' 가 발생합니다. 이미 운영 중인 토픽의 데이터 자료형을 변경하는 것은 기존에 저장된 바이트 데이터와 새로 들어올 데이터의 형식이 충돌하여 문제가 발생할 수 있으며, 자료형을 변경해야 하는 경우 새로운 토픽을 생성하는 방식으로 처리하는 것이 좋습니다 Producer(프로듀서) 프로듀서는 데이터를 생성하여 Kafka 토픽으로 전송하는 주체입니다. 부하 분산과 확장성 프로듀서는 여러 파티션에 데이터를 분산 전송함으로 시스템의 부하를 분산하고 확장성을 확보합니다. 파티션 개수를 적절하게 설정하면 많은 데이터를 동시에 처리할 수 있어 시스템의 확장성이 높아집니다. 고가용성 및 복구 메커니즘 브로커나 파티션에 장애가 발생해도 시스템이 멈추지 않도록 설계되었습니다. 프로듀서는 브로커로부터 응답을 받거나, 메타데이터를 갱신하며 파티션의 상태를 실시간으로 파악합니다. 특정 파티션에 문제가 생기면 사용 가능한 다른 파티션으로 데이터를 재전송하거나, 설정된 로드 밸런싱 알고리즘에 따라 복구 작업을 수행합니다. 파티셔닝 결정권 데이터가 어떤 파티션에 기록할지 프로듀서 내부의 파티셔너가 결정합니다. 프로듀서는 메시지의 특성(Key 존재 여부 등)에 따라 기록될 파티션을 스스로 선택합니다. 별도의 설정이 없다면 기본 파티셔너가 작동하며, 필요에 따라 특정 파티션으로 고정해서 보내는 커스텀 로직을 적용할 수도 있습니다. \[메시지 키가 null 인 경우]\ 라운드 로빈 방식으로 데이터를 전송합니다. 모든 파티션에 데이터가 골고루 쌓여 부하가 완벽히 분산됩니다. \[메시지 키가 null 이 아닌 경우]\ 해싱 기법을 사용해 특정 키를 가진 메시지를 항상 동일한 파티션으로 전송합니다. 기본적으로 murmur2 알고리즘을 사용해 키 값을 해싱합니다. Consumer(컨슈머) Pull 모델 기반의 데이터 조회 컨슈머는 브로커가 데이터를 보내줄 때까지 기다리는 것이 아니라, 직접 데이터를 요청하여 가져오는 Pull 모델을 사용합니다. 컨슈머가 자신의 처리 능력에 맞춰 원하는 시점에 데이터를 브로커에 요청할 수 있으며, 컨슈머가 처리 속도를 감당하지 못해 과부하가 걸리는 현상을 방지 가능합니다. 브로커 연결 및 자동 복구 컨슈머는 지능적으로 브로커와 통신하며 시스템의 안정성을 유지합니다. 각 파티션의 리더가 어느 브로커에 있는지 자동으로 파악하고 연결하며, 특정 브로커에 장애가 발생하더라도, 컨슈머는 메타데이터를 갱신하여 새롭게 선출된 리더 브로커를 찾아가 데이터를 계속 읽어올 수 있습니다. 데이터 읽기 순서 Kafka 에서 메시지의 순서는 파티션 단위로만 보장됩니다. 단일 파티션 내에서는 메시지가 기록된 순서대로 읽히는 것이 엄격히 보장됩니다. 컨슈머가 여러 파티션에서 동시에 데이터를 읽는 경우 파티션 사이의 순서는 보장되지 않습니다.

  #kafka#카프카#프로듀서#message#컨슈머2026-04-10 · 5분
• 학습

  Kafka Topic(토픽), Partitions(파티션), Offsets(오프셋)

  Kafka Topic(토픽) 이 뭘까? Kafka 토픽은 Kafka 클러스터 내에서 데이터(메시지)를 구분하는 단위이자 데이터 스트림 그 자체를 의미합니다. 토픽은 텍스트, Json, 바이너리 등 모든 종류의 메시지 형식을 지원합니다. 토픽 내부에 메시지들이 쌓이는 순차적인 흐름을 데이터 스트림이라 부르며, 이것이 카프카가 데이터 스트리밍 플랫폼이라 부르는 이유입니다. 프로듀서를 통해 데이터를 토픽에 기록하고, 컨슈머를 통해 실시간으로 읽습니다. 한 번 파티션에 기록된 데이터는 수정하거나 삭제할 수 없습니다. 데이터는 설정된 보관 기간 이후에 자동으로 삭제됩니다. Partitions(파티션) 은 뭘까? 토픽이 데이터를 담는 큰 바구니라면, 파티션은 그 바구니를 여러 칸으로 나눈 작은 공간입니다. 하나의 토픽을 100개의 파티션으로 나눌 수 있습니다. 이렇게 하면 데이터를 100곳에 나누어 담을 수 있기 때문에, 여러 대의 서버가 동시에 데이터를 처리할 수 있는 병렬성이 확보됩니다. Topic으로 전송된 메시지는 지정된 방식에 따라 100개의 파티션 중 하나에 배치됩니다. 중요한 점은 각 파티션 내부에서는 메시지가 들어온 순서대로 쌓인다는 것입니다. Offset(오프셋)은 뭘까? 파티션에 들어간 메시지들이 가지는 ID를 오프셋이라 합니다. 각 파티션마다 0번부터 시작하여 1씩 증가하며 부여됩니다. 오프셋은 해당 파티션 내에서 메시지의 절대적인 위치를 나타냅니다. 컨슈머는 '이 파티션의 50번 오프셋까지 읽었어'라고 기억함으로써 데이터 읽기를 관리합니다. 오프셋은 각 파티션마다 별도로 매겨집니다. <br / 요약 및 정리 토픽은 병렬 처리를 위해 여러 개의 파티션으로 나뉘며, 각 파티션에 저장된 메시지는 오프셋이라는 고유 번호를 통해 순서와 위치를 보장받습니다. 파티션 개수는 한 번 늘리면 다시 줄이는 것이 불가능하기 때문에 처음에 신중하게 결정합니다. 보통 처리해야 할 데이터 양과 컨슈머의 개수를 고려해서 설정합니다.

  #topic#kafka#카프카#partitions#파티션#오프셋#offset2026-04-09 · 2분
• 학습

  Kafka 설정을 알아보자

  들어가기 전에 맨 아래에서 참고 자료 링크를 들어가서 확인하면 알겠지만, Kafka에 대한 설정 값이 어마무시하게 많다. 모든 설정을 파악하고 싶은 분들은 AI를 통해서 파악하시는 것을 권장드리며, 여기서는 제가 느끼기에 자주 사용했던 설정 값들을 정리하는 글입니다. 해당 글은 지속적으로 업데이트 할 예정입니다. controller.listener.names 컨트롤러에서 사용하는 리스너 이름들을 쉼표로 구분한 목록입니다. 이는 컨트롤러 쿼럼과 통신할 때 필요하며, 브로커는 항상 이 목록의 첫 번째 리스너를 사용합니다. 쿼럼은 어떤 동작을 하기 위해서 필요한 최소한의, 동등한 무언가들의 찬성표 개수를 뜻한다. 특정 행위를 하기 위해서 정족수가 필요하다는 규칙을 가리킨다 node.id process.roles가 비어 있지 않은 경우, 이 프로세스가 수행하는 역할과 연결된 노드 ID입니다. 이는 KRaft 모드로 실행할 때 필요한 구성입니다. process.roles 이 프로세스가 수행하는 역할은 '브로커', '컨트롤러' 또는 둘 다인 경우 '브로커, 컨트롤러'입니다 add.partitions.to.txn.retry.backoff.max.ms 서버 측에서 트랜잭션에 파티션을 추가하는 데 허용되는 최대 시간 제한입니다. 이는 실제 파티션 추가 작업에만 적용되며 검증에는 적용되지 않습니다. request.timeout.ms보다 큰 값으로 설정하면 효과가 없습니다. add.partitions.to.txn.retry.backoff.ms 서버가 트랜잭션에 파티션을 추가하려고 시도할 때 서버 측 재시도 백오프가 적용됩니다. advertised.listeners Kafka 브로커가 클라이언트 및 다른 브로커에 알릴 리스너 주소를 지정합니다. 이 설정은 클라우드 환경처럼 실제 리스너 구성이 클라이언트가 연결에 사용할 주소를 나타내지 않는 경우에 유용합니다. 주소는 컨트롤러에 게시되고 관리되며, 브로커는 필요에 따라 컨트롤러에서 이러한 데이터를 가져옵니다. IaaS 환경에서는 이 주소가 브로커가 바인딩하는 인터페이스와 달라야 할 수도 있습니다. 참고 자료 $1 $1

  #kafka#config#설정#카프카2026-04-09 · 3분
• 프로젝트

  Next.js 프로젝트를 생성해보자

  참고 자료 $1 기술 환경 기본적으로 node.js 설치가 완료되어 있어야 합니다. node 버전은 v24.11.1 바탕으로 작성됩니다 프로젝트 설치 next.js 프로젝트를 설치하기 위해서 아래 명령어를 원하는 디렉토리에서 실행해요. 해당 명령어로 우리는 벌써 프로젝트 생성을 완료했어요 중요한 파일 설명 프로젝트의 모든 파일을 다 다루기엔 분량이 꽤 많은 편이에요. 가독성을 위해서 꼭 알아야 할 핵심 파일들만 골라서 설명해 드릴게요 파일 혹은 디렉터리 설명 :---------------- :--------------------------------------------- app/ App Router 기반 페이지, 레이아웃, API 라우트를 관리해요 public/ 정적 파일 (이미지, favicon)을 관리해요 node\modules 프로젝트 의존성 패키지들이 설치되는 곳이에요. Git에 저장할 때에는 제외해야 해요 next.config.ts Next.js 사용자 정의 설정을 담당해요. 16 버전부터는 TS가 기본 권장되요 package.json 의존성 + 실행 스크립트를 관리해요 package-lock.json 의존성 버전이 고정되어 있는 파일이에요 tsconfig.json Typescript 설정을 관리해요 자세한 설명은 아래 링크에서 확인해보자 <https://nextjs.org/docs/app/getting-started/project-structure 간단한 화면 수정 지금 프로젝트는 Next.js 에서 기본적으로 만들어주는 페이지를 보여주고 있어요. 이것을 변경해 볼거에요 1. app/components/LoginForm.tsx 파일을 생성해서 문자열을 출력하는 화면을 만들어요 2. Next.js 에서 기본적으로 만들어준 app/page.tsx 내부를 청소하고 생성한 LoginForm.tsx를 넣어줘요 3. 페이지가 제대로 적용되었는지 확인해봐요

  #nextjs#nodejs2026-04-06 · 2분
• 학습

  개발자가 말하는 "버전 관리" 가 뭐지?

  취업 준비를 하다 보면, 모집 공고나 개발자 프로젝트에서 이런 말을 한 번쯤 들어봤을 거예요 "Git 에 올려놨어." / "Github 링크 공유해줄게." / "커밋 내역 보면 돼." 오늘은 "버전 관리"와 "Git"의 개념을 간단하게 알아보는 시간을 가져볼게요 <br / 버전 관리란 무엇일까? "버전 관리"라는 말이 어렵게 들리지만, 이미 일상에서 비슷한 개념을 쓰고 있어요. 예를 들어 아래와 같은 상황이 있습니다 보고서\최종.docx 보고서\최종 2.docx 보고서\최최최종.docx 보고서\최최최최종.docx 파일을 통째로 복사해서 이름을 바꿔가면서 저장한 경험이 있을 것이라고 생각합니다. 이게 바로 원시적인 형태의 "버전 관리"예요. 수정 전 상태를 보존해두고 싶어서 생기는 자연스러운 행동이거든요 버전 관리는 파일의 변경 이력을 체계적으로 기록하고 관리하는 것입니다. 언제, 무엇이, 어떻게 바뀌었는지를 추적할 수 있어요 개발자들은 코드 파일이 수백, 수천 개를 다루기 때문에 이를 수동으로 관리하는 것은 매우 힘든 작업이 됩니다. 그래서 등장한 도구가 바로 Git 입니다. Git 이란 무엇일까? Git은 "버전 관리 시스템"의 일종으로, 쉽게 말해 코드의 수정 이력을 자동으로 기록해주는 기능입니다. Git을 사용하면 아래와 같은 것들이 가능해져요 언제, 누가, 어떤 작업을 했는지 모두 기록됩니다 이전 버전으로 즉 복원이 가능합니다 여러 사람이 동시에 같은 코드를 수정했을 때 발생하는 충돌 문제를 해결 가능하도록 기능을 제공해줘요 꼭 알아야할 Git 핵심 용어 Git을 이해하기 위해서는 자주 등장하는 용어 네 가지만 알면 충분해요 용어 뜻 일상 비유 :--------------- :---------------- :------------------ Commit (커밋) 변경 내용을 기록 문서를 저장하여 메모를 남기는 것 Repository (저장소) 코드와 이력이 모두 저장된 공간 파일과 수정 이력이 담긴 폴더 Branch (브랜치) 독립적인 작업 공간 원본 건드리지 않고 복사본에서 작업 Merge (병합) 브랜치를 하나로 합치는 것 복사본의 수정 내용을 원본에 반영 Commit (커밋)을 쉽게 설명하면 커밋은 "현재 시점에 상태를 저장해둔다"는 행위에요, 세이브 포인트를 만드는 것이죠. 나중에 뭔가 잘못되었을 때 세이브 포인트를 사용하여 되돌아올 수 있습니다. 그리고 커밋을 할 때는 보통 "어떤 작업을 했는지", "무엇을 적용했는지" 설명을 같이 남기는게 좋아요 - Git, Github 차이점이 뭘까? Git과 Github는 이름이 비슷해서 혼동되는데, 사실은 서로 다른 것이에요 구분 Git Github :- :------------- :-------------------- 정체 소프트웨어 (프로그램) 웹사이트 (서비스) 역할 버전 기록을 로컬에서 관리 Git 저장소를 온라인에 보관 및 공유 비유 개인 일기장 일기장을 올려두는 클라우드 Git은 내 컴퓨터에서 코드 이력을 관리하는 프로그램이라면, Github는 코드 이력을 인터넷에 올려 다른사람들과 공유하고 함께 작업할 수 있게 해주는 플랫폼이에요 Github 링크를 포트폴리오에 활용하는 이유도 본인이 어떤 코드를 작성했고, 얼마나 꾸준히 개발 활동을 했는지 다른사람들에게 보여줄 수 있기 때문이에요 또한 집에서 작업하고, 외부에 나가서 다른 PC에서 작업을 진행할 때 Github 를 이용하면 이어서 작업하기가 편해요 왜 버전 관리가 중요하지? 버전 관리가 없을 때 발생하는 문제를 간단하게 생각해 봅시다. 잘 되던 기능을 수정했는데 오류가 발생했어요. 이때 이전 코드가 없으면 어떻게 하죠? 팀원 5명이 같은 파일을 수정하고 병합을 했어요. 마지막에 병합한 파일만 남았으면 어떻게 하죠? 3개월 전에 왜 이 코드를 이렇게 만들었는지 기억이 안나는데 어떻게 하죠? Git을 사용하게 되면 이 모든 문제가 해결돼요. 그래서 요즘은 1인 개발자도, 수백 명이 함께 일하는 대기업 개발팀도 Git을 기본 도구로 사용하고 있어요 Git은 개발자들의 "팀 협업 도구" 입니다. 규모에 상관없이 모든 개발 프로젝트의 기본이에요 오늘의 핵심 정리 버전 관리는 파일의 수정 이력을 체계적으로 기록, 관리해요 Git은 코드 파일의 버전을 자동으로 관리해주는 프로그램이에요. 커밋은 특정 시점의 상태를 저장하는 행위를 말해요 Github는 Git 저장소를 온라인에서 공유하고 협업하는 플랫폼을 말해요 버전 관리와 Git은 개발을 배우지 않아도 기본 개념만 알아두면 개발자와 대화하거나, IT 직군을 이해하는데 큰 도움이 될거에요.

  #git#github#version#버전2026-04-06 · 5분
• 학습

  Kafka 왜 쓰는가?

  나는 Kafka, 메시지 큐가 같은 기능을 하는 것으로 알고 있었다. IT 블로그를 탐색하던 와중에 글을 하나 읽어서 저만의 생각을 정리하려고 포스팅을 진행합니다. 메시지 큐 vs Kafka 무엇이 다를까? 메시지 큐와 Kafka는 모두 시스템 간 데이터를 주고받는 메시지 브로커 역할을 하지만 설계 부분에서 큰 차이가 있다는 것을 검색으로 찾아봤다. 메시지 큐(Rabbit MQ, SQS) 메시지 소비 후 즉시 데이터를 삭제해서 보관하고 싶다면 별도로 처리해야 한다. 하나의 메시지는 하나의 컨슈머가 소비한다. 재처리를 위해 추가 작업이 필요하다 - DB, DLQ 수천 TPS 수준에서 한계가 존재한다. 라우팅 로직이 브로커에 집중된다. Kafka 로그처럼 메시지를 설정에 따라 보존할 수 있다. 하나의 메시지를 컨슈머 그룹을 이용해서 여러 컨슈머가 소비할 수 있다. 오프셋 되감기를 통해 재처리가 비교적 쉽다. 수십만 TPS 처리가 가능하다. 이벤트를 여러 서비스가 동시에 구독이 가능하다. <br / 오프셋은 어디까지 메시지를 소비했는지 기록하는 좌표라고 생각하면 이해가 쉽습니다. 재처리는 이미 소비한 메시지를 다시 읽어서 동일하거나 다르게 처리하는 것을 말합니다. 컨슈머 그룹은 메시지를 중복 없이 나누어 처리하거나 다른 그룹과는 독립적으로 메시지를 소비할 수 있는 설정을 말합니다. 그래서 Kafka를 왜써? 솔직히 제가 만든 개인 프로젝트 규모에서는 Kafka의 필요성을 체감하기 어려웠습니다. 작은 서비스라면 메시지 큐든 Kafka든 결과적으로 큰 차이가 없거든요. 이러한 상황을 바탕으로 Kafka가 필요한 상황을 MQ와 비교하여 다음과 같이 정리했습니다. 메시지 큐 메시지 전달의 정확성과 복잡한 라우팅이 중요할 때 데이터를 처리한 즉시 삭제해도 문제없는 로직일 때. 사용자 수가 상대적으로 적고 실시간 트래픽이 폭발적이지 않을 때. Kafka 대용량 로그 데이터나 실시간 이벤트 스트리밍을 처리할 때 동일한 데이터를 여러 서비스에서 동시에 활용해야 할 때 과거 데이터를 확인해서 장애 복구나 분석을 해야할 때 서비스 규모가 커서 높은 가용성과 확장성이 필수적일 때 정리 Kafka는 데이터 보관 및 재처리 기능에 강점이 있어, 대용량 로그 파이프라인 구축에 최적화되어 있습니다. 일반적인 메시지 큐는 시스템 간의 논리적 연결(Point-to-Point)가 생기기 쉬운 것과 달리, Kafka는 Pub/Sub 구조의 서비스 간 유연성을 제공합니다. 이는 새로운 서비스가 추가되어도 기존 시스템의 수정 없이 데이터를 공유할 수 있어 MSA 환경에서 시스템 결합도를 낮추는 결정적인 역할을 합니다.

  #kafka#이벤트 기반 아키텍처#apache kafka2026-04-05 · 3분
• 학습

  HTTP vs HTTPS - 개발자라면 이 정도는 알아야 한다

  브라우저 주소창을 보면 사이트에 혹은 가 붙는다. 둘의 차이를 'HTTPS 가 안전한 거 아닌가요?' 정도로 알고 있다면, 이번 기회에 제대로 정리해 보자. HTTP란? HTTP(HyperText Trasnfer Protocol)는 클라이언트(브라우저)와 서버가 데이터를 주고받기 위해 약속된 통신 규칙을 의미한다. 문제는 HTTP는 데이터를 \\평문(Plain Text)\\로 전송한다는 것이다.\ 중간에서 누군가 패킷을 가로채면 내용을 그대로 조회할 수 있다 HTTPS란? HTTPS(HTTP Secure)는 HTTPS에 TLS(Transport Layer Security) 암호화를 얹은 것이다. 데이터를 암호화해서 주고받기 때문에 중간에 가로채도 내용을 알 수 없다 브라우저 - \[암호화 데이터] - 서버 - \[암호화된 응답] - 브라우저 TLS 핸드셰이크 HTTPS 연결 시 브라우저와 서버는 암호화 방식을 협상하는 과정을 거친다. 이것을 TLS 핸드 셰이크라고 한다. 1단계 - Client Hello 브라우저가 서버에 연결을 시도하며 자신이 지원하는 암호화 방식 목록을 함께 보낸다. 2단계 - Server Hello + 인증서 서버가 목록을 보고 둘 다 지원하는 암호화 방식을 하나 선택해서 응답한다. 동시에 자신의 신원을 증명하는 SSL 인증서를 함께 전송한다. 3단계 - 인증서 유효성 검사(CA 확인) 브라우저가 받은 인증서가 믿을 수 있는 기관(CA)가 서명한 것인지 확인한다. 브라우저에는 신뢰할 수 있는 CA 목록이 미리 내장되어 있다. 4단계 - 세션 키 생성 & 전달 검증이 끝나면 브라우저가 이번 연결에만 쓸 1회용 비밀키(세션키)를 만들고, 서버의 공개키로 암호화해 전달한다. 공개키로 잠근 내용은 서버만 가진 개인키로 열 수 있다. 5단계 - 대칭 암호화 통신 시작 이후 모든 데이터는 이 세션 키로 빠르게 암호화/복호화한다. SSL 인증서는 어떻게 발급 받을까? HTTPS를 사용하기 위해 서버에 SSL/TLS 인증서가 있어야 하는데, 발급받는 방법은 대표적으로 두 가지가 있다. 무료 - Let's Encrypt 유료 - 상용 CA(DigiCert, Comodo) EV(Extended Validation) 인증서가 필요한 금융, 기업 서비스에서 주로 사용하며, 일반 서비스의 경우 Let's Encrypt로 충분하다 <br /

  #HTTP#HTTPS#TLS#네트워크#개발자#보안2026-04-04 · 3분
• 학습

  [2] Next.js 프로젝트에 Auth.js(v5) 도입하기: Credentials 인증 방식 설정

  본문에 들어가기 전에 이전 게시글을 읽으면 도움이 될 수도 있다. <https://blog.rudy.it.kr/post/cmnhjuyjr00012zmezygph614 <br / Credentials Auth.js에서 아이디/비밀번호 또는 외부 인증 방식을 지원하는 인증 방식의 이름이다. Credentials Provider Credentials 인증 방식을 구현하기 위해 providers 배열에 추가하는 객체이다. Credentials Provider 임포트 경로는 이다 credentials 필드 Credentials Provider 에서 로그인 폼의 입력 필드를 정의하는 객체로 Next.js 에서는 경로로 자동으로 렌더링된다. 각 필드는 다음과 같은 속성을 허용한다. : Input label : HTML input type (, , etc.) : Placeholder text 이러한 필드들은 자격 증명 인수를 통해 authorize 함수에도 전달된다. authorize 함수 Credentials Provider 에 정의된 authorize 는 사용자 지정 로그인 방식을 처리하고 제공된 자격 증명이 유효한지 여부를 판단한다. 실제 인증 로직을 작성한다고 생각하면 된다. <br / 예시 코드 정리 Signin Form 테스트용 로그인 페이지 <br / Validating credentials 자격 증명은 항상 서버 측에서 검증해야 합니다. 예를 들어 Zod와 같은 스키마 유효성 검사 라이브러리를 활용하자 <br / 참고 자료 $1

  #nodejs#nextjs#next-auth2026-04-03 · 2분
• 학습

  [1] Next.js 프로젝트에 Auth.js(v5) 도입하기: 기초 이론

  본문에 들어가기 전에 본 문서는 아래와 같은 특정 개발 환경을 기준으로 작성되었습니다.\ 명시된 버전과 다를 경우 일부 기능이 정상적으로 동작하지 않을 수 있습니다. 기술 스택 (Stack Specifications) Next.js: next-auth: (및 패키지) React: Node: Auth.js 가 무엇인가 Auth.js는 표준 Web API 기반의 런타임 독립 인증 라이브러리입니다. 최신 JavaScript 프레임워크와 자연스럽게 통합되며, 간편한 설정과 확장성, 그리고 보안 및 개인정보 보호를 고려한 인증 환경을 제공합니다. Auth.js 사용으로 사용자를 인증하는 방법 Auth.js는 다양한 인증 방식을 기본적으로 지원합니다. 1. OAuth 인증 (Social Login) 예시: Google, GitHub, LinkedIn 특징: 기존 소셜 계정을 활용한 간편 로그인 방식 2. 매직 링크 (Magic Links / Email) 예시: Forward Email, Resend, SendGrid 특징: 이메일로 전달된 일회용 링크를 통해 로그인 3. 자격 증명 (Credentials) 예시: 자체 DB, 외부 인증 API 특징: 인증 로직을 직접 구현해야 하므로 보안에 특히 주의 필요 4. WebAuthn (Passkeys) 예시: 지문, Face ID, 보안 키 특징: 비밀번호 없이 생체 인증 기반 로그인 Auth.js 설치 아래 명령어를 입력하여 설치를 진행한다. 환경 설정 진행 필수 환경 변수는 입니다. 이 값은 토큰 및 인증 데이터를 암호화하는 데 사용됩니다. 아래 명령어로 생성할 수 있습니다: 생성된 값을 파일에 등록합니다: 프로젝트 설정 Auth.js의 동작을 제어하기 위해 루트에 파일을 생성합니다. 주요 역할 인증 시스템 초기화 인증 관련 메서드 제공 (, , ) 라우트 핸들러 연결 1. auth.ts 생성 2. Route Handler 설정 Pages Router를 사용하더라도 해당 파일은 App Router 방식으로 반드시 작성해야 합니다. 3. (선택) 세션 유지 Proxy 설정 Next.js 16부터 → 로 변경되었습니다.\ 이전 버전에서는 에서 다음과 같이 사용합니다: 참고 자료 $1 $1 다음 게시글 <https://rudy.it.kr/post/cmnhmzutf00022zmeis2fb18a

  #nodejs#nextjs#next-auth2026-04-02 · 3분