Amor DevFati(아모르 개발파티)

쿠폰 중복 사용 버그, 비관적 락 한 줄로 해결하기

고구마와 감자 — Fri, 21 Nov 2025 17:49:24 +0900

쿠폰 중복 사용 버그, 비관적 락 한 줄로 해결하기

문제 상황

주문 API를 만들고 테스트하던 중 이상한 현상을 발견했다.

동시에 여러 요청이 들어오면 같은 쿠폰이 2번 사용되는 버그가 발생했다.

분명히 쿠폰 사용 여부를 체크하는 로직이 있는데, 왜 이런 일이?

원인 분석

문제는 이랬다.

시간 →

스레드 A: 쿠폰 조회 (사용 가능!) → 사용 처리
스레드 B:      쿠폰 조회 (사용 가능!) → 사용 처리

두 스레드가 거의 동시에 조회하면 둘 다 "사용 가능"으로 판단한다. 그리고 둘 다 사용 처리를 해버린다.

이게 바로 Lost Update 문제다.

해결: 비관적 락

해결은 간단했다. 조회할 때 락을 걸면 된다.

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("""
    SELECT mc FROM MemberCoupon mc
    JOIN FETCH mc.coupon c
    WHERE mc.memberId = :memberId
    AND mc.coupon.id = :couponId
    AND mc.deletedAt IS NULL
""")
fun findByMemberIdAndCouponIdWithLock(memberId: String, couponId: Long): MemberCoupon?

@Lock(LockModeType.PESSIMISTIC_WRITE) 한 줄 추가했다.

이제 흐름이 이렇게 바뀐다:

시간 →

스레드 A: 쿠폰 조회 (락 획득) → 사용 처리 → 락 해제
스레드 B:      대기...              → 조회 (이미 사용됨!) → 실패

서비스 코드

fun getMemberCoupon(memberId: String, couponId: Long): MemberCoupon? {
    couponRepository.findByIdOrThrow(couponId)

    // 비관적 락으로 조회
    return memberCouponRepository.findByMemberIdAndCouponIdWithLock(memberId, couponId)
        ?: throw CoreException(ErrorType.COUPON_NOT_FOUND, "쿠폰을 보유하고 있지 않습니다")
}

락이 걸린 메서드를 호출하면, 트랜잭션이 끝날 때까지 다른 스레드는 해당 row에 접근하지 못한다.

왜 비관적 락?

낙관적 락도 고려했지만, 쿠폰은 비관적 락이 맞다고 판단했다.

구분	비관적 락	낙관적 락
방식	조회 시 락	수정 시 버전 체크
충돌 시	대기	예외 → 재시도
적합한 경우	충돌 많음, 실패 비용 큼	충돌 적음

쿠폰 사용은:

한 번 실패하면 UX가 나빠짐 (결제 실패)
동시 요청 가능성 있음 (여러 기기에서 동시 주문)
재시도보다 대기가 나음

그래서 비관적 락을 선택했다.

정리

동시성 문제는 단일 스레드 테스트로는 발견 안 됨
비관적 락은 @Lock(LockModeType.PESSIMISTIC_WRITE) 한 줄
쿠폰처럼 실패 비용이 큰 경우 비관적 락이 적합

재고 차감, 검증은 몇 번 해야 할까?

고구마와 감자 — Fri, 14 Nov 2025 17:41:33 +0900

재고 차감, 검증은 몇 번 해야 할까?

TL;DR: 주문 생성 시 재고 검증과 차감이 중복·분산돼 혼란스러웠다. 검증을 한 곳에 명확히 두고, 메서드 호출 방식을 통일하는 게 핵심임을 배웠다.

문제 발견

주문 생성 로직을 구현하다 보니 재고 처리 방식이 어색했다.

// Order.create()
product.validateStock(quantity)   // 검증
OrderItem.of(product, quantity)

// OrderService.createOrder()
order.items.forEach {
    it.product.decreaseStock(it.quantity)  // 차감만
}

Order 생성 시 검증
OrderService에서 차감 → 검증을 두 번? 한 번? 헷갈렸다.

Product에 메서드가 3개나…

fun validateStock(quantity: Quantity) { ... }           // 검증만
fun decreaseStock(quantity: Quantity) { ... }           // 차감만 (VO 내부 검증)
fun decreaseStockWithValidation(quantity: Quantity) { ... } // 검증+차감

"어느 걸 써야 정답이지?" → 일관성 없는 설계의 신호

원인

decreaseStock()은 재사용성을 위해 검증 없이 설계
Stock VO 내부에도 검증 존재 → 검증이 두 곳에 중복
에러 메시지에 상품명을 넣고 싶어 Product에도 검증 추가

선택지

방식 설명 장점 단점

1. 검증+차감 통합	decreaseStock()이 항상 검증	호출 측 부담 ↓	VO 검증 중복
2. VO 검증만 믿기	엔티티 검증 제거	중복 없음	에러 메시지 제한

내가 선택한 방식: 2번 + 타협

// Product.kt
fun decreaseStock(quantity: Quantity) {
    stock = stock.decrease(quantity.value)  // VO가 검증
}

fun validateStock(quantity: Quantity) {     // 상품명 포함 에러용
    if (!hasEnoughStock(quantity)) {
        throw CoreException(ErrorType.INSUFFICIENT_STOCK,
            "재고 부족. 상품: $name (요청: ${quantity.value})")
    }
}

Order.create() → validateStock() (구체적 에러)
OrderService → decreaseStock() (VO 검증 위임)

여전히 불편한 점

validateStock()이 public이라 오용 가능성
검증 후 차감 사이 동시성 문제 (트랜잭션/락 필요)
메서드 2개 → 여전히 많음

배운 점

검증은 한 곳에 명확히 (VO or 엔티티)
메서드 많으면 설계 의심
일관성 > 완벽함

다음엔 이렇게

fun decreaseStock(quantity: Quantity) {
    if (!hasEnoughStock(quantity)) {
        throw CoreException(ErrorType.INSUFFICIENT_STOCK,
            "재고 부족. 상품: $name (요청: ${quantity.value}, 재고: ${stock.quantity})")
    }
    stock = stock.decrease(quantity.value)
}

메서드 하나, 검증+차감+에러 메시지 통일

재고 차감은 단순해 보이지만, "누가 검증할까? 몇 번 할까? 어떻게 일관되게 할까?" 이 고민이 좋은 설계를 만든다.

다음엔 더 간결하게!

Round 2 회고

고구마와 감자 — Fri, 7 Nov 2025 16:01:08 +0900

회고

요구사항 정리는 한적 있지만

상세하게 작성한적도 없고, 다이어그램은 그려본 적이 한번도 없어서 코드 구현보다 어려운 과제였습니다.

1. 좋아요 기능의 멱등성 보장

멱등성이 뭐죠?

멱등성이란 동일한 연산을 여러 번 수행해도 결과가 달라지지 않는 성질을 말합니다

그래서 좋아요 기능의 멱등성 보장은 어떻게 하죠?

멱등성이 보장된다는건 뭐지?

- 같은 사용자가 같은 게시물에 좋아요를 100번 눌러도, 좋아요는 딱 1개만 저장되어야 한다는 거라고 합니다.

결론: 몇 번을 눌러도 좋아요는 1개만 저장되는 게 멱등성 보장

잘못된 경우 (멱등성 X)

사용자 A가 게시물 1번에 좋아요 3번 클릭
→ DB에 좋아요 3개 저장됨
→ 좋아요 개수 3 증가
→ ❌ 문제!

올바른 경우 (멱등성 O)

사용자 A가 게시물 1번에 좋아요 3번 클릭
→ DB에 좋아요 1개만 저장됨
→ 좋아요 개수 1만 증가
→ ✅ 정상!

그러면 이걸 어떻게 보장하지?

가장 확실한 방법:

1. DB에 유니크 제약

UNIQUE KEY (user_id, post_id)

- 이렇게 하면 같은 사용자 + 같은 게시물 조합은 절대 중복 저장 안됨

네트워크 지연으로 똑같은 요청이 2번 와도, 첫 번째만 저장되고 두 번째는 무시됩니다.

2. 애플리케이션 레벨에서 제어

- 좋아요 데이터 존재여부 확인 후 분기 처리

2. 재고 및 포인트 동시성 제어

여러 사용자가 동시에 주문할 때 발생할 수 있는 문제:

상황: 상품 재고 10개, 사용자 A와 B가 동시에 각각 8개씩 주문

[동시성 제어 없이]
T1: A가 재고 조회 (10개) ✓
T2: B가 재고 조회 (10개) ✓  ← 문제: 둘 다 10개로 보임
T3: A가 재고 차감 (10 - 8 = 2개)
T4: B가 재고 차감 (10 - 8 = 2개)  ← 재앙: 실제로는 -6개여야 함!
결과: 총 16개 판매, 재고는 2개로 표시 → 데이터 정합성 깨짐 ❌

처리 방안

- 비관적 락 적용

[비관적 락 적용 후]
T1: A가 재고 조회 + 락 획득 (10개)  
T2: B가 재고 조회 시도 → ⏳ 대기 (A의 락이 풀릴 때까지)
T3: A가 재고 차감 (10 - 8 = 2개)
T4: A의 트랜잭션 커밋 + 락 해제  
T5: B가 재고 조회 + 락 획득 (2개)  
T6: B가 재고 부족 확인 (2 < 8)
T7: B에게 InsufficientStockException 발생
결과: A만 주문 성공, B는 재고 부족 에러 → 정합성 보장 ✅

왜 비관적 락인가?

선택 이유:
1. 주문/재고는 충돌 가능성이 높음 (인기 상품일수록)
2. 재시도 로직보다 락으로 확실히 제어하는 것이 안전

3. 외부 시스템 연동 실패 시 트랜잭션 롤백

- 주문 생성 후 외부 시스템(배송/결제 등) 연동 필요
- 외부 시스템 장애 시 이미 차감된 재고와 포인트 처리 방법?

처리 방안

외부 시스템 연동을 트랜잭션 범위에 포함하여 연동 실패 시 재고 및 포인트 차감 자동 복원

블로그 글 작성도 조금 더 발전할 수 있을거 같은데 다음에는 좀 더 시간을 들여서 작성할 수 있도록 해야겠습니다.

Round 1 회고

고구마와 감자 — Fri, 31 Oct 2025 16:23:47 +0900

Loopers 2기 참여하여 첫주 과제진행 후 배운 점 및 느낌을 정리하고자 합니다.

종합적으로 전반적으로 새로운 아키텍처 구조에서 과제를 구현하며 새로운 테스트 스타일, 예외 처리 등을 배울 수 있는 과제였습니다.

1. 통합테스트, E2E 테스트 (Ent-to-End Test)

인프런 강의를 통해 도메인, 서비스, 레포지토리, 컨트롤러 레이어로 레이어 테스트를 학습해봤고, 도메인 레이어의 단위테스트는 타 교육에서 많이 진행해왔기에 익숙했습니다
하지만 통합테스트, E2E 테스트라는 이름으로 테스트를 진행한 것은 처음이라 통합테스트, E2E 테스트 작성에 대해서 학습할 수 있었습니다.
통합테스트는 Facade 에서 진행하였고, 기존에 하던 Service 테스트와 유사하였습니다.
E2E 테스트는 기존의 컨트롤러 API 테스트와 비슷한데 API 마다 @Nested 어노테이션과 함께 inner class 로 테스트를 작성하는 방식을 배울 수 있었습니다.
- 이렇게 하니 1개의 API 테스트에 대한 테스트들만을 작성하니 가독성이나 테스트 작성하는데에도 집중하기 좋았습니다.

통합테스트란?

통합 테스트는 애플리케이션의 여러 계층(Layer)이 함께 올바르게 작동하는지 검증하는 테스트입니다. 주로 Service Layer와 Repository Layer 간의 상호작용을 테스트합니다.

E2E 테스트란?

E2E 테스트는 사용자 관점에서 HTTP API를 직접 호출하여 전체 플로우를 검증하는 테스트입니다. 실제 사용자가 API를 호출하는 것과 동일한 환경에서 테스트합니다.

✅ 통합테스트 예시

@DisplayName("회원 가입 시 Member 저장이 수행된다")
@Test
fun saveMemberOnJoin() {
    // Given
    val command = JoinMemberCommand("user1", "test@email.com", "1990-05-15", "MALE")

    // When
    memberFacade.joinMember(command)

    // Then
    verify(memberFacade).joinMember(any())
}

✅ E2E 테스트 예시

@DisplayName("POST /api/v1/users/join - 회원 가입")
@Nested
inner class Join {
    @DisplayName("회원 가입이 성공할 경우, 생성된 유저 정보를 응답으로 반환한다")
    @Test
    fun successfulJoin() {
        // Given: 회원 가입 요청 데이터
        val request = JoinMemberRequest(
        "testUser1",
        "test@gmail.com",
        "1990-05-15",
        "MALE"
        )
        // When: POST /api/v1/users/join 호출
        val responseType = object : ParameterizedTypeReference<ApiResponse<MemberV1Dto.MemberResponse>>() {}
        val response = testRestTemplate.exchange(
            "/api/v1/users/join",
            HttpMethod.POST,
            HttpEntity(request),
            responseType
        )

        // Then: 응답 검증
        assertAll(
            { assertThat(response.statusCode).isEqualTo(HttpStatus.OK) },
            { assertThat(response.body?.data?.memberId).isEqualTo("testUser1") },
            { assertThat(response.body?.data?.email).isEqualTo("test@gmail.com") },
            { assertThat(response.body?.data?.gender).isEqualTo("MALE") },
        )
    }
}

고민한 부분

1. 제공된 예제 코드에는 Service를 통합테스트의 대상으로 삼고 있었으나, Facade에서 통합테스트 하는 것이 다수의 Service를 활용하고 트랜잭션 제어에도 용이, 그리고 전체 로직을 테스트하기 위해 Facade에서 테스트 하기로 결정하였습니다.

2. 대체적으로E2E 테스트가 API 호출을 다루다보니 코드양이 많아 자칫 한 클래스에 몰려서 테스트 작성 및 실행이 불편할 거 같아

MemberController 하나에 들어갈 API중에 Point 관련한 Api 들을 분리해서 PointController를 추가하였습니다.

2. Spy 검증

Mock과 Spy의 차이를 정확히 몰라 비슷한건가 보다 생각했는데 정확하게 이해할 수 있었습니다.

1. Spy란?

Spy는 실제 객체를 감싸서(wrapping) 실제 동작은 그대로 수행하면서, 메서드 호출을 추적할 수 있는 객체입니다.

2. Mock vs Spy

  // Mock: 가짜 객체 (모든 동작이 stubbing 필요)
  @MockBean
  private lateinit var memberFacade: MemberFacade
  // memberFacade.joinMember()는 아무 동작도 하지 않음 (null 반환)

  // Spy: 실제 객체를 감싼 것 (실제 동작 수행 + 호출 추적)
  @MockitoSpyBean
  private lateinit var memberFacade: MemberFacade
  // memberFacade.joinMember()는 실제로 동작함 (DB 저장 등)

3. 코드 예시

@MockitoSpyBean
private lateinit var memberFacade: MemberFacade

@DisplayName("회원 가입 시 Member 저장이 수행된다")
@Test
fun saveMemberOnJoin() {
    val command = JoinMemberCommand("user1", "test@email.com", "1990-05-15", "MALE")

    memberFacade.joinMember(command)

    verify(memberFacade).joinMember(command)
}

3. 예외 처리

위 2개의 과제 퀘스트를 처리하기 위해서는

먼저 발생하는 예외를 확인해서 이를 처리하는 예외핸들러 메서드를 구현해주어야 한다.

    @ExceptionHandler
    fun handleMethodArgumentNotValid(e: MethodArgumentNotValidException): ResponseEntity<ApiResponse<*>> {
        val fieldErrors = e.bindingResult.fieldErrors
        val errorMessage = fieldErrors.joinToString(", ") { error ->
            "${error.field}: ${error.defaultMessage}"
        }

        log.warn("Validation failed: {}", errorMessage)
        return failureResponse(
            errorType = ErrorType.BAD_REQUEST,
            errorMessage = errorMessage
        )
    }

    @ExceptionHandler
    fun handleMissingRequestHeader(e: MissingRequestHeaderException): ResponseEntity<ApiResponse<*>> {
        val errorMessage = e.message
        log.warn("MissingRequestHeaderException: {}", errorMessage)
        return failureResponse(
            errorType = ErrorType.BAD_REQUEST,
            errorMessage = errorMessage
        )
    }

성별 값이 없는 경우에는 MethodArgumentNotValidException 이 발생
RequestHeader 어노테이션이 달린 값이 헤더값이 부재한 경우에는 MissingRequestHeaderException 발생

MethodArgumentNotValidException, MissingRequestHeaderException 를 처리하는 메서드 구현하면 이를 잡아 처리함

colima 에서 testcontainer 사용테스트 시 에러 처리

고구마와 감자 — Thu, 25 Sep 2025 11:58:10 +0900

⚠️ 문제

colima 로 docker 사용 중 testcontainer 설정으로 테스트 시 아래와 같이 에러

원인

Docker 환경을 찾을 수 없다는 에러입니다. Colima와 테스트컨테이너를 함께 사용할 때 자주 발생하는 문제

해결

build.gradle 에 아래 4줄을 입력하고 Sync gradle changes 눌러주면 정상적으로 동작한다.

  environment "DOCKER_HOST", "unix://${System.getProperty("user.home")}/.colima/default/docker.sock"
  environment "TESTCONTAINERS_RYUK_DISABLED", "true"
  environment "TESTCONTAINERS_REUSE_ENABLE", "true"
  systemProperty "testcontainers.docker.socket.override", "/var/run/docker.sock"

fork/exec /Users/jihochoi/.docker/cli-plugins/docker-buildx: no such file or directory

고구마와 감자 — Wed, 24 Sep 2025 18:33:00 +0900

✅ 문제

docker-desktop을 사용하지 못하는 상황에서 colima 로 docker를 사용하면, docker-compose 설치 하고 docker-compose 실행 중에 아래와 같은 명령어로 실행이 안되는 경우 강 있다.

fork/exec /Users/jihochoi/.docker/cli-plugins/docker-buildx: no such file or directory

✅ 원인

docker buildx 가 설치되어 있지 않거나, 해당 경로에 실행 파일이 없어서 발생하는 오류이다.

✅ 해결

M3 맥기준 해결책이다.

아래 코드를 한 줄 씩 입력하자

# 1. 아키텍처 설정 (Intel Mac: amd64 / Apple Silicon M1, M2: arm64)
ARCH=arm64

# 2. buildx 버전 설정 (필요 시 최신 버전으로 변경 가능)
VERSION=v0.10.5

# 3. buildx 바이너리 다운로드
curl -LO https://github.com/docker/buildx/releases/download/${VERSION}/buildx-${VERSION}.darwin-${ARCH}

# 4. CLI 플러그인 디렉토리 생성
mkdir -p ~/.docker/cli-plugins

# 5. 바이너리 이동 및 실행 권한 부여
mv buildx-${VERSION}.darwin-${ARCH} ~/.docker/cli-plugins/docker-buildx
chmod +x ~/.docker/cli-plugins/docker-buildx

# 6. 설치 확인
docker buildx version

25년 1월 ~ 2월 헤이밥 알고리즘 과외 후기

고구마와 감자 — Fri, 7 Mar 2025 09:08:11 +0900

요약:
헤이밥 과외로 브론즈 문제만 많이 풀다가 16주 강의 듣고 골드 3 까지는 도전할만하게 됨

- 시작할 때

스터디를 하며 브론즈~실버 문제를 많이 풀었지만 스스로 풀지 못하고 있었다
그래서 실력이 늘지 못하고 골드 문제에 도전을 하지 못하고 있었다

또 주변에 코딩테스트 준비하는 사람도 없다보니
물어볼 사람도 없고, 어떻게 체계적으로 공부해야할 지를 몰랐었다

개발 회사에 다녀서 개발은 하지만, 알고리즘에 대한 공부는 체계적으로 한 적이 없는 상황이었다

- 선택한 이유

헤이밥 인프런 강의를 들어봤는데 문제 접근법이나 수학 내용 등을 세밀하게 알려주고 있었다
특히 Big-O를 어떻게 계산하는지 내용을 보고 좋다고 생각했다

로그 계산 내용을 알려주고 각 문제마다 계산 복잡도를 강의하는 것을 보고 과외를 받아도 좋겠다고 생각했다

- 좋았던 점

생각하는 법을 알려주었다. 어떻게 문제에 접근하는지 나의 케이스에 맞게 맞춰 배울 수 있었다

지식의 빈 공간을 채워주었다. 문제 읽는 법을 위한 글 읽기 과제도 있었고, 수학 과제와 수학 지식을 활용하는 법도 배울 수 있었고, 코딩테스트 문제 해결을 위한 소프트웨어 설계 또한 배울 수 있었다. 이런 내용은 코딩테스트 뿐만 아니라 회사에 돌아가 주중에 실무를 하는 데에도 쓸모가 있었다

수학 과제를 내주었는데, 고등학교 과정에서 필요한 내용만 빼서 알려주었기에 최적화된 공부를 할 수 있었다

- 결과

쉽게 풀지도 못하고 며칠 고생하면 골드 3 까지는 문제를 풀 수 있게 되었다
좀 더 노력해서 코딩테스트에 통과할 수 있는 실력을 갖춰야겠다.

끝.

Dto to Entity, Entity to Dto 변환

고구마와 감자 — Wed, 15 Nov 2023 09:33:43 +0900

# 1. Dto to Entity or Entity to Dto

서비스에서 변환처리

## 서비스에서 변환한 이유

우선 Spring Data JPA를 사용하게 되면 Entity를 받아 오므로 싸비스에서 변환해주는게 좋다.
비즈니스 처리, 로직 처리 등은 서비스에서 하는게 좋지 않을까 해서 서비스에서 함.

# 2. 사용한 변환 방법

포켓 몬스터 너로 정했다 !!! : Builder 패턴

생성자나 대신에 Builder 패턴을 사용한 이유는 유연성, 가독성, 불변성

1. 생성자는 파라미터가 많을 경우 가독성이 좋지 않고, 순서를 정해줘야한다.

2. 값 설정 순서가 상관이 없다. 생성자는 순서가 중요하다

3. 생성자는 그때 그때 파라미터 수에 맞게 생성자를 만들어줘야 함

Setter를 사용하지 않은 이유

여기저기서 쉽게 수정자를 사용하게 되면 값을 변경한 의도를 파악하기 힘듬
객체의 일관성 유지가 어려움. public으로 어디서든 객체의 상태를 변경하게 되므로 변경지점 파악도 어려움
Setter를 지양하고 변경의 이유가 있을 때는 객체에 변경에 관한 메서드를 만들어 사용하는 것이 객체지향적인 코드를 작성하기 용이함

빌더패턴 관련해서는 아래 블로그 참고 바람

https://dev-youngjun.tistory.com/197

@ResponseBody 와 JPA의 엔티티는 기본생성자가 필수

고구마와 감자 — Mon, 13 Nov 2023 15:06:27 +0900

# 1. Spring RequestBody와 JPA 엔티티에 기본 생성자가 필요한 이유

Reflection을 사용하기 때문이다.
Reflection은 구체적인 타입은 알지 못하더라도, 내부 변수와 메소드에 접근할 수 있는 방법이다.
만약 생성자가 여러 개 있다면, Reflection은 이 중 어떤 생성자를 호출해야 할지 알 수가 없다. 따라서 Reflection은 기본 생성자를 통해 객체를 생성한 후 값을 넣어준다.

출처: https://medium.com/sjk5766/%EC%99%9C-responsebody%EB%8A%94-%EA%B8%B0%EB%B3%B8-%EC%83%9D%EC%84%B1%EC%9E%90%EA%B0%80-%ED%95%84%EC%9A%94-%ED%96%88%EC%9D%84%EA%B9%8C-8104e6d02408

DDD 설계 vs SQL중심 설계

고구마와 감자 — Sat, 11 Nov 2023 13:45:36 +0900

# 1. DDD(Domain Driven Design) 설계

(1) DDD란?

도메인이란 ? 소프트웨어로 해결하고자 하는 문제 영역
온라인 쇼핑몰의 도메인은 전자상거래
이커머스 도메인, 상품 도메인

이런 도메인을 중심으로 설계해 나가는 방법을 DDD 라고 함.

# 2. SQL 중심 설계

데이터베이스 구조와 데이터의 흐름을 중심으로 시스템을 개발하는 것