한 명씩만

지난 주 돌아보기 — Week 4 인덱스

비유 — 콘서트 티켓 1장 vs 50명

티켓 1장 남았는데 50명 동시 결제.

• 락 없음 → 50명 성공 → 티켓 -49장
• 비관 락 → 1명 성공, 49명 대기
• 낙관 락 → 모두 시도, 1명 성공, 49명 재시도

이번 주 목표

1. 음수 재고 발생 직접 재현 (실패 로그 캡처)
2. @Lock(PESSIMISTIC_WRITE) 또는 @Version 적용 + 동시 요청 50건 검증
3. 비관 vs 낙관 trade-off — 왜 그걸 선택 했는지 evidence 에

어떤 락 고를까

경합이 _잦으면_ → 비관 락 (재시도 비용 ↑↑)
경합이 _드물면_ → 낙관 락 (대기 시간 ↑↑)

면접에서 이 trade-off 를 답하면 +1 점.

함정 — 동시성에서 흔한 실수

• synchronized 만 — 멀티 인스턴스에선 의미 X
• @Transactional 만 — 격리 수준 default 면 read 충돌 못 막음
• 비관 락 전체 적용 — 처리량 ↓↓
• 낙관 락 재시도 정책 없음 — 사용자에게 500 에러
• 재현 안 한 채 코드만 → k6 또는 ExecutorService 50 요청 직접 발사

이번 주 제출할 것

06-week5-concurrency/
├── report.md
├── project/                          # Spring Boot baseline + 락
└── evidence/
    ├── concurrency-failure-log.md    # 음수 재고 재현 로그
    ├── k6-script.js                  # 또는 동시 요청 스크립트
    ├── concurrency-success-log.md    # 락 적용 후 성공 로그
    └── lock-strategy-comparison.md   # 비관 vs 낙관 결정 근거

평가는 어떻게 (5축)

이번 주 일정

• 제출 마감: 2026-07-10 (금) 23:59
• 토 15:00–16:30: 학생 내부 발표 (강의 슬롯 아님)
• 오피스아워: 화·목 21:00 {cohort}-질문 스레드
• 5주차 = 중도 이탈 위험 구간 — 막히면 바로 질문, 혼자 끙끙 X