Update README.md

[munhyerin22]

README 작성

[github-actions]

🤖 AI 코드리뷰

리더보드 — 현재 4위 (리뷰 105건) | 전체 8개 팀 참여 중
업데이트 확인 — 리뷰가 질문을 던지다 — 생각해보기

📋 과제 요구사항 준수 여부

• 필수 기능 (동시성 제어, 캐싱, 검색): 아키텍처, 테스트 코드, 구현 전략이 README에 매우 상세하게 잘 정리되어 있습니다. 과제의 핵심 의도를 완벽히 이해하고 구현했습니다.
• 🔴 사용 금지 기술 사용 (필수 기능): 기술 스택 및 동시성 제어 파트에서 Redisson을 필수 구현에 혼용하고 있습니다. 과제 요구사항에 명시된 "Lettuce 기반 Redis Lock 필수 (Redisson 사용 금지)" 원칙 위반입니다. Lettuce와 Redisson이 혼재되어 있어, 필수 요구사항에서 Lettuce만 사용했는지, 아니면 Redisson이 기본 락으로 설정되어 있는지 코드 레벨의 검증이 필수적입니다.
• 도전 기능 (실시간 채팅, 인덱스 최적화, 캐싱 고도화, 동시성 고도화): 요구사항을 충실히 반영하여 구현한 흔적이 문서에 잘 드러납니다.

🟢 잘된 점

• 테스트 기반의 검증: ExecutorService + CyclicBarrier를 활용해 락 적용 전후의 정합성을 테스트로 증명하고, v1~v8까지 전략별로 벤치마크하여 최종 전략을 선택한 과정이 매우 훌륭합니다. 이런 접근은 실무에서도 높은 평가를 받습니다.
• 비즈니스 로직의 격리: 결제 확정 시 재고를 차감하는 흐름이나, 채팅방 생성 시 Race Condition을 REQUIRES_NEW + Unique 제약조건 + 예외 캐치로 풀어낸 설계는 실무적인 디테일이 돋보입니다.
• 명확한 트레이드오프 분석: 인덱스 설계, 캐시(L1/L2) 도입 이유, Write-back 스케줄링 등 구조적 선택의 이유가 명확합니다.

🟡 개선 제안

• README와 실제 코드의 불일치 리스크: <<v1 평균 응답시간>> ms, <<개선율>>% 등 빈칸(Placeholder)이 다수 존재합니다. PR을 올리기 전에 실제 테스트 결과값으로 치환하는 것을 잊지 마세요. 구멍 뚫린 문서는 운영 환경에서의 모니터링과 트러블슈팅을 방해하는 심각한 부채가 됩니다.
• Caffeine Eviction 제어: 트러블슈팅에 nativeCache.cleanUp()을 테스트에서 호출해 해결했다고 적어두셨습니다. 테스트야 통과하겠지만, 운영 환경에서 Caffeine은 여전히 비동기/지연 Eviction을 수행합니다. 캐시의 강한 일관성이 필요한 도메인이라면 만료(TTL) 외에 크기 정책(maximumSize)을 재검토하거나, Redis L2 캐시를 신뢰하는 구조로 아키텍처를 수정해야 합니다.

💡 학습 포인트

• 분산 락과 DB 락의 경계: v7(Redisson)과 v8(Redisson + 비관락)을 비교하며 v7을 선택한 이유가 "불필요한 DB 락 오버헤드" 때문이라고 명시했습니다. 이 결정이 유효하려면, Redis 분산 락이 잡힌 상태에서 스레드가 DB에 접근할 때 커넥션 풀을 얼마나 점유하는지, DB 락 대기 시간이 길어지면 어떤 연쇄 장애(Thread Starvation)가 발생할 수 있는지 고민해 보세요.

🤔 생각해보기

README에 명시된 "채팅방 자동 종료 스케줄러"는 1분마다 실행되어 비활성 방을 배치 단위로 종료합니다. 만만한 로직이 아닙니다. 이 1분 주기 스케줄러가 실행 중에 DB 커넥션 풀을 모두 점유하거나, Lock 경합으로 인해 1분 안에 작업을 마치지 못하고 다음 스케줄이 또 실행된다면 애플리케이션은 어떤 형태로 장애(Deadlock, OOM 등)로 이어질까요?

💬 이 질문에 대해 궁금한 점이 있으면 코멘트에 @sparta 를 남겨보세요!
예: @sparta 이 상황에서 스케줄러에 @SchedulerLock을 적용하는 것이 답일까요?

---

AI 리뷰는 참고용입니다. 최종 판단은 팀원이 직접 합니다.