[LNK-48] 공감하기 동시성 문제 해결 #83
Conversation
WalkthroughreactToFeed 호출 경로에 피드와 사용자에 대한 비관적 쓰기 락을 도입했습니다. 저장소와 서비스에 락 전용 조회 메서드를 추가하고, 테스트 인프라를 Kotlin 기반으로 전환하며 동시성 통합 테스트를 추가했습니다. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant FeedUsecase
participant FeedGetService
participant FeedRepository
participant UserGetService
participant UserRepository
participant Database
Client->>FeedUsecase: reactToFeed(userId, feedId, request)
FeedUsecase->>FeedGetService: findByIdWithLock(feedId)
FeedGetService->>FeedRepository: findByIdWithPessimisticLock(feedId)
FeedRepository->>Database: SELECT ... FOR UPDATE (PESSIMISTIC_WRITE, timeout)
Database-->>FeedRepository: locked Feed row (+fetch join author)
FeedRepository-->>FeedGetService: Optional<Feed>
FeedGetService-->>FeedUsecase: Feed
FeedUsecase->>UserGetService: findByIdWithLock(authorId)
UserGetService->>UserRepository: findByIdWithPessimisticLock(authorId)
UserRepository->>Database: SELECT ... FOR UPDATE (PESSIMISTIC_WRITE, timeout)
Database-->>UserRepository: locked User row
UserRepository-->>UserGetService: Optional<User>
UserGetService-->>FeedUsecase: User
FeedUsecase->>FeedUsecase: validate/create/update Reaction (in-memory)
FeedUsecase->>Database: persist Reaction and update counters
Database-->>FeedUsecase: commit
FeedUsecase-->>Client: Reaction 응답
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50분 Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧹 Recent nitpick comments
📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (8)
🚧 Files skipped from review as they are similar to previous changes (1)
🧰 Additional context used🧠 Learnings (2)📚 Learning: 2025-08-12T14:17:56.674ZApplied to files:
📚 Learning: 2025-08-12T14:17:56.674ZApplied to files:
🧬 Code graph analysis (1)src/main/java/leets/leenk/domain/feed/domain/service/FeedGetService.java (3)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (7)
✏️ Tip: You can disable this entire section by setting Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @src/test/kotlin/leets/leenk/domain/feed/test/fixture/FeedTestFixture.kt:
- Around line 8-18: The createFeed function's id parameter is unused (it isn't
applied to Feed.builder()), causing calls like createFeed(id = FEED_ID_100, ...)
to be misleading; fix by removing the id parameter from the createFeed signature
in FeedTestFixture (or, if you intentionally need a settable id for tests,
explicitly set the id on the built entity after construction or provide an
alternate constructor/helper that sets id), and update callers like
FeedUsecaseTest.kt to stop passing id or to use the new helper; ensure
references to createFeed and Feed.builder() reflect the change and add a brief
comment if you keep the parameter to explain why it's ignored with JPA
@GeneratedValue.
🧹 Nitpick comments (3)
src/test/resources/application-test.yml (1)
18-20: Hibernate 방언 설정 확인
org.hibernate.dialect.MySQL8Dialect는 Hibernate 6.x에서 deprecated되었습니다. Hibernate가 자동으로 방언을 감지하므로, 명시적 설정이 필요하지 않을 수 있습니다. 현재 사용 중인 Hibernate 버전을 확인해 주세요.src/test/kotlin/leets/leenk/config/TestContainersTest.kt (1)
15-35: 컨테이너 검증 테스트가 잘 작성되었습니다.테스트 인프라 구성을 검증하는 좋은 접근 방식입니다.
println문은 디버깅에 유용하지만, CI 환경에서는 로그를 깔끔하게 유지하기 위해 제거하거나 로거를 사용하는 것을 고려해 볼 수 있습니다.src/test/kotlin/leets/leenk/domain/feed/application/usecase/FeedUsecaseTest.kt (1)
220-223: 타임아웃 추가를 권장합니다.
latch.await()에 타임아웃이 없으면 스레드가 완료되지 않을 경우 테스트가 무한 대기할 수 있습니다. 또한executor.shutdown()후awaitTermination을 호출하여 모든 태스크가 완료될 때까지 대기하는 것이 좋습니다.♻️ 타임아웃 추가 제안
- latch.await() - executor.shutdown() + val completed = latch.await(30, java.util.concurrent.TimeUnit.SECONDS) + executor.shutdown() + executor.awaitTermination(10, java.util.concurrent.TimeUnit.SECONDS) + + if (!completed) { + throw IllegalStateException("동시성 테스트 타임아웃") + }
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (14)
src/main/java/leets/leenk/domain/feed/application/usecase/FeedUsecase.javasrc/main/java/leets/leenk/domain/feed/domain/repository/FeedRepository.javasrc/main/java/leets/leenk/domain/feed/domain/service/FeedGetService.javasrc/main/java/leets/leenk/domain/user/domain/repository/UserRepository.javasrc/main/java/leets/leenk/domain/user/domain/service/user/UserGetService.javasrc/test/java/leets/leenk/config/MysqlTestConfig.javasrc/test/java/leets/leenk/config/TestContainersTest.javasrc/test/kotlin/leets/leenk/config/MongoTestConfig.ktsrc/test/kotlin/leets/leenk/config/MysqlTestConfig.ktsrc/test/kotlin/leets/leenk/config/TestContainersTest.ktsrc/test/kotlin/leets/leenk/domain/feed/application/usecase/FeedUsecaseTest.ktsrc/test/kotlin/leets/leenk/domain/feed/test/fixture/FeedTestFixture.ktsrc/test/resources/application-test.ymlsrc/test/resources/application.yml
💤 Files with no reviewable changes (2)
- src/test/java/leets/leenk/config/MysqlTestConfig.java
- src/test/java/leets/leenk/config/TestContainersTest.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-12T14:17:56.674Z
Learnt from: hyxklee
Repo: Leets-Makers/Leenk-BE PR: 54
File: src/main/java/leets/leenk/domain/feed/domain/service/LinkedUserDeleteService.java:18-18
Timestamp: 2025-08-12T14:17:56.674Z
Learning: The LinkedUser entity in the Leenk-BE project has a unique constraint on the combination of feed_id and user_id columns (UniqueConstraint(columnNames = {"feed_id", "user_id"})), which requires explicit flush() calls after delete operations to prevent constraint violations during the delete-and-recreate pattern used in feed updates.
Applied to files:
src/main/java/leets/leenk/domain/feed/application/usecase/FeedUsecase.javasrc/main/java/leets/leenk/domain/feed/domain/repository/FeedRepository.java
🧬 Code graph analysis (3)
src/main/java/leets/leenk/domain/user/domain/service/user/UserGetService.java (1)
src/main/java/leets/leenk/domain/user/application/exception/UserNotFoundException.java (1)
UserNotFoundException(5-13)
src/test/kotlin/leets/leenk/config/MysqlTestConfig.kt (1)
src/test/java/leets/leenk/config/MysqlTestConfig.java (2)
TestConfiguration(8-19)Bean(13-18)
src/main/java/leets/leenk/domain/feed/domain/service/FeedGetService.java (1)
src/main/java/leets/leenk/domain/feed/application/exception/FeedNotFoundException.java (1)
FeedNotFoundException(5-9)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (12)
src/test/resources/application.yml (1)
1-3: LGTM!테스트 프로파일을 활성화하는 표준적인 Spring Boot 설정입니다.
application-test.yml의 설정이 올바르게 로드됩니다.src/test/resources/application-test.yml (1)
59-67: 중복된 AWS 자격 증명 설정 확인 필요
spring.cloud.aws(라인 21-27)와cloud.aws(라인 59-67)에 AWS 자격 증명이 중복 정의되어 있습니다. 이는 서로 다른 라이브러리(예: Spring Cloud AWS vs 커스텀 설정)를 위한 것일 수 있지만, 의도적인 설정인지 확인해 주세요.src/main/java/leets/leenk/domain/feed/domain/service/FeedGetService.java (1)
29-36: LGTM!비관적 락을 사용한 피드 조회 메서드가 기존
findById()패턴과 일관되게 구현되었습니다. JavaDoc이 사용 목적을 명확히 설명하고 있어 유지보수에 도움이 됩니다.src/main/java/leets/leenk/domain/user/domain/service/user/UserGetService.java (1)
26-33: LGTM!
FeedGetService.findByIdWithLock()과 동일한 패턴으로 구현되어 코드베이스 전체에서 일관성이 유지됩니다.UserRepository.findByIdWithPessimisticLock()은FeedRepository와 동일한PESSIMISTIC_WRITE락과 2000ms 타임아웃으로 올바르게 설정되었으며, 비관적 락을 통한 동시성 제어가 Feed와 User 도메인에 일관되게 적용되었습니다.src/main/java/leets/leenk/domain/feed/domain/repository/FeedRepository.java (1)
30-37: 비관적 락 구현이 적절하나 타임아웃 동작 검증 필요
PESSIMISTIC_WRITE락과JOIN FETCH f.user를 통한 동시성 제어는 적절합니다. 다만jakarta.persistence.lock.timeout힌트는 주의가 필요합니다.현재 환경(dev/local에서
MySQLDialect사용)에서는 Hibernate가 이 힌트를 MySQL 특정 문법으로 변환하지 않을 수 있으므로, 실제 타임아웃이 작동하지 않을 가능성이 있습니다. MySQL은innodb_lock_wait_timeout시스템 변수(기본값 50초)로 전역 제어되며, 쿼리 단위 타임아웃은 표준 지원하지 않습니다.실제 동작 검증이 필요합니다. 필요시 다음 옵션을 검토하세요:
innodb_lock_wait_timeout시스템 변수 설정 (세션 또는 연결 단위)- Hibernate 버전 확인 및 MySQL8Dialect 사용 고려
- 통합 테스트 추가로 락 타임아웃 동작 확인
src/main/java/leets/leenk/domain/user/domain/repository/UserRepository.java (1)
21-28: 비관적 락 구현이 적절합니다.락 타임아웃 힌트와 소프트 삭제 필터링이 올바르게 적용되었습니다.
PESSIMISTIC_WRITE모드와 2000ms 타임아웃은 동시성 제어에 적합한 선택입니다.src/test/kotlin/leets/leenk/config/MongoTestConfig.kt (1)
10-17: LGTM!MongoDB 테스트 컨테이너 설정이 깔끔하게 구현되었습니다.
@ServiceConnection어노테이션을 통해 자동으로 연결 속성이 주입됩니다.src/test/kotlin/leets/leenk/config/MysqlTestConfig.kt (1)
10-18: LGTM!Java에서 Kotlin으로의 마이그레이션이 올바르게 수행되었습니다. 기존 Java 설정과 동일한 이미지 버전(
mysql:8.0.41)과 데이터베이스 이름(testdb)을 유지합니다.src/main/java/leets/leenk/domain/feed/application/usecase/FeedUsecase.java (2)
213-227: 비관적 락 적용이 잘 구현되었습니다.락 순서를 명시하고(
피드 → 작성자) Javadoc에 관련 레포지토리 메서드를 참조한 점이 좋습니다. 공감하는 사용자(user)는 데이터가 수정되지 않으므로 락이 필요하지 않은 것이 맞습니다.
238-238:feedAuthor사용이 올바릅니다.락이 걸린
feedAuthor엔티티를 사용하여totalReactionCount를 업데이트함으로써 동시성 문제를 방지합니다.FeedUpdateService.updateTotalReaction메서드는User user파라미터를 받으며, 메서드 내에서feed,reaction,user엔티티의 totalReactionCount를 모두 업데이트합니다.src/test/kotlin/leets/leenk/domain/feed/application/usecase/FeedUsecaseTest.kt (2)
43-91: 동시성 테스트가 잘 구성되었습니다.테스트 시나리오가 명확하고,
afterEach에서 FK 제약조건을 고려한 올바른 순서로 데이터를 정리합니다. 여러 사용자의 동시 공감 시나리오를 효과적으로 검증합니다.
136-188: 데드락 방지 테스트가 PR 목표에 부합합니다.동일 작성자의 여러 피드에 대한 동시 공감 시나리오를 테스트하여
totalReactionCount업데이트 시 발생할 수 있는 데드락을 검증합니다.saveAndFlush사용으로 테스트 데이터의 즉각적인 영속화를 보장합니다.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/test/kotlin/leets/leenk/domain/feed/application/usecase/FeedUsecaseTest.kt (2)
30-31: 사용되지 않는 상수가 있습니다.
FEED_ID_100과FEED_ID_200상수가 정의되어 있지만 테스트 코드에서 사용되지 않습니다. 불필요한 경우 제거를 고려해 주세요.
198-225:latch.await()에 타임아웃 추가를 권장합니다.현재
latch.await()가 무한정 대기할 수 있어, 예상치 못한 상황에서 테스트가 영구적으로 멈출 수 있습니다. 타임아웃을 추가하면 CI 환경에서 더 안정적으로 동작합니다.♻️ 타임아웃 적용 제안
+import java.util.concurrent.TimeUnit + private fun executeConcurrentReactions( threadCount: Int, reactions: List<() -> Unit> ): Pair<Int, Int> { val executor = Executors.newFixedThreadPool(threadCount) val latch = CountDownLatch(reactions.size) val successCount = AtomicInteger(0) val failureCount = AtomicInteger(0) reactions.forEachIndexed { index, reaction -> executor.submit { try { reaction() successCount.incrementAndGet() } catch (e: Exception) { println("스레드 $index 실패: ${e.message}") failureCount.incrementAndGet() } finally { latch.countDown() } } } - latch.await() + val completed = latch.await(30, TimeUnit.SECONDS) + if (!completed) { + throw IllegalStateException("동시성 테스트 타임아웃: 30초 내에 완료되지 않음") + } executor.shutdown() return successCount.get() to failureCount.get() }
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/test/kotlin/leets/leenk/domain/feed/application/usecase/FeedUsecaseTest.ktsrc/test/kotlin/leets/leenk/domain/feed/test/fixture/FeedTestFixture.kt
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (4)
src/test/kotlin/leets/leenk/domain/feed/test/fixture/FeedTestFixture.kt (1)
6-19: LGTM! 간결하고 효과적인 테스트 픽스처입니다.Companion object를 활용한 팩토리 메서드 패턴이 적절하며, 기본값을 제공해 테스트 작성 시 유연성을 확보했습니다.
src/test/kotlin/leets/leenk/domain/feed/application/usecase/FeedUsecaseTest.kt (3)
53-90: 여러 사용자 동시 공감 테스트 - LGTM!비관적 락을 통한 동시성 제어를 검증하는 테스트가 잘 구성되어 있습니다. 모든 요청의 성공 여부, 리액션 개수, 그리고 집계 카운트까지 철저히 검증하고 있습니다.
97-133: 동일 사용자 동시 공감 테스트 - LGTM!동일 사용자의 중복 요청(멀티 디바이스 시나리오)에서 유니크 제약 조건 위반 없이
reactionCount가 정확히 증가하는지 검증합니다. PR 목표에서 언급된 중복 삽입 문제를 잘 커버하고 있습니다.
140-187: 동일 작성자의 다른 피드 동시 공감 테스트 - LGTM!작성자의
totalReactionCount업데이트 시 발생할 수 있는 데드락을 검증하는 핵심 테스트입니다.saveAndFlush를 사용하여 동시성 테스트 전에 데이터가 확실히 영속화되도록 처리한 점이 좋습니다.
| fun mongoContainer(): MongoDBContainer { | ||
| return MongoDBContainer(MONGO_IMAGE) | ||
| } | ||
| } |
There was a problem hiding this comment.
Leenk에서는 실제로 mongoDB를 사용하나요 ?
몽고디비 환경도 추가한 이유가 궁금합니다!
There was a problem hiding this comment.
알림 기능을 위해서 몽고디비 사용하고 있습니당
jj0526
left a comment
jj0526
left a comment
There was a problem hiding this comment.
수고하셨습니다! 피드랑 유저에 대해 비관적 락을 걸고, 테스트를 통해 락이 정상적으로 동작하는지까지 검증해주셨네요
| private fun executeConcurrentReactions( | ||
| threadCount: Int, | ||
| reactions: List<() -> Unit> | ||
| ): Pair<Int, Int> { | ||
| val executor = Executors.newFixedThreadPool(threadCount) | ||
| val latch = CountDownLatch(reactions.size) | ||
| val successCount = AtomicInteger(0) | ||
| val failureCount = AtomicInteger(0) | ||
|
|
||
| reactions.forEachIndexed { index, reaction -> | ||
| executor.submit { | ||
| try { | ||
| reaction() | ||
| successCount.incrementAndGet() | ||
| } catch (e: Exception) { | ||
| println("스레드 $index 실패: ${e.message}") | ||
| failureCount.incrementAndGet() | ||
| } finally { | ||
| latch.countDown() | ||
| } | ||
| } | ||
| } | ||
|
|
||
| latch.await() | ||
| executor.shutdown() | ||
|
|
||
| return successCount.get() to failureCount.get() | ||
| } |
| val updatedFeedAuthor = userRepository.findById(feedAuthor.id!!).get() | ||
| updatedFeedAuthor.totalReactionCount shouldBe ATTEMPT_COUNT.toLong() | ||
|
|
||
| val updatedFeed = feedRepository.findById(feed.id!!).get() | ||
| updatedFeed.totalReactionCount shouldBe ATTEMPT_COUNT.toLong() |
There was a problem hiding this comment.
useCase를 검증하는게 목적이지만 이 경우에는 비관적 락을 테스트 하기 위해서 실제 Repository를 통해 검증한건가요?
There was a problem hiding this comment.
넵 해당 테스트들은 통합 테스트의 성격이라서 Repository까지 다 사용하도록 구현했습니당
단위, 통합 테스트를 구분할 방법도 한 번 생각을 해봐ㅏ야겠군요
| @@ -0,0 +1,3 @@ | |||
| spring: | |||
| profiles: | |||
| active: test No newline at end of file | |||
There was a problem hiding this comment.
환경변수 파일에도 개행이 필요할까요??
There was a problem hiding this comment.
필수는 아니긴 하지만 경고가 떠서 말씀드렸어요
충돌만 해결하시면 될거같아요~!
# Conflicts: # src/test/java/leets/leenk/config/MysqlTestConfig.java # src/test/java/leets/leenk/config/TestContainersTest.java # src/test/resources/application-test.yml
soo0711
left a comment
soo0711
left a comment
There was a problem hiding this comment.
수고하셨습니다!!
원인 분석 -> 문제 해결 -> 테스트로 검증까지 꼼꼼하게 잘 되어있는 것 같습니다 👍
| * 공감하기 등 동시 수정이 발생할 수 있는 경우 사용 | ||
| */ | ||
| @Lock(LockModeType.PESSIMISTIC_WRITE) | ||
| @QueryHints(@QueryHint(name = "jakarta.persistence.lock.timeout", value = "2000")) |
There was a problem hiding this comment.
조회 쿼리에서 lock.timeout = 2000ms로 설정하신 기준이나 고려하신 부분이 있을지 궁금합니다!
There was a problem hiding this comment.
보통의 경우 3초 정도로 설정하는 듯 한데, 공감하기의 경우는 너무 느린 응답속도로 반응하면 사용성이 떨어질 것 같아 약간 짧게 2초로 설정했습니다!!
|
기존 @1winhyun 님께서 작성해주신 테스트와 성격이 다른 테스트라서 "FeedUsecaseIntegrationTest"로 명칭을 수정했습니당. 다음에도 통합 테스트를 구현하게 된다면 위 네이밍으로 작성해주세옴 |
1winhyun
left a comment
1winhyun
left a comment
There was a problem hiding this comment.
고생하셨습니다. 리뷰 하나 남겼으니 확인 부탁드려요!!
추가적으로 현재 락 타임아웃이 2초로 되어있는데, 이에 대한 예외를 별도로 처리하지 않는 것으로 보여 유저 입장에서는 500으로 보일 것으로 생각됩니다. 이를 따로 예외를 잡아 400번대 에러를 내는 것은 어떤가요?
| @Lock(LockModeType.PESSIMISTIC_WRITE) | ||
| @QueryHints(@QueryHint(name = "jakarta.persistence.lock.timeout", value = "2000")) | ||
| @Query("SELECT f FROM Feed f JOIN FETCH f.user WHERE f.deletedAt IS NULL AND f.id = :id") | ||
| Optional<Feed> findByIdWithPessimisticLock(@Param("id") Long id); |
There was a problem hiding this comment.
지금 JOIN FETCH를 통해 USER를 묶고 있는데 이렇게 할 경우 USER까지 락에 걸릴 수 있지 않을까요?
해당 메서드가 구현된 이유는 락 순서를 고정해 데드락을 피하기 위해서입니다. 그런데 만약에 첫번째 쿼리에서 이미 USER가 잠겨버린다면 Feed 락-> User 락이 아니라 User 먼저 잠그고 Feed가 잠기는 현상이 일어날 수도 있을 것 같습니다.
또한 락 범위가 늘어나 불필요한 대기가 늘어날 수도 있을 것 같아요!!
개인적인 의견입니다..
There was a problem hiding this comment.
3번 문제: 다른 피드더라도 작성자의 경우 “totalReactionCount” 필드를 동시에 업데이트 하기 때문에 데드락 발생
해당 문제 때문에 작성자에도 락을 걸어야하는 상황입니다!
테스트 해보니 페치 조인을 쓰는 경우 User 엔티티에도 락이 걸리는 것 맞네요! 다른 케이스라면 문제가 될 수 있지만 현재 요구사항으로는 딱 맞는 상황입니당. 주석에 해당 내용을 작성해둘테니 필요에 따라 구분해서 사용할 필요가 있어 보이네요!!
덕분에 해당 락이 중복이 되서 코드를 간략하게 만들 수 있겠네요 승현님 덕분에 하나 더 배웟습니당
There was a problem hiding this comment.
그리고 커스텀 예외 하나 만들어서 잡아주겟습니다!
문제상황
추가 문제 발생 (시나리오)
원인
1번 문제: 같은 피드에 동시에 요청을 하는 경우 Reaction INSERT시 락 충돌로 데드락 발생
2번 문제: 동시에 요청을 하는 경우 트랜잭션이 순서대로 동작하지 않아 Reaction이 중복으로 생성
3번 문제: 다른 피드더라도 작성자의 경우 “totalReactionCount” 필드를 동시에 업데이트 하기 때문에 데드락 발생
해결방안
동시성 제어 방안
비관적락
낙관적락
분산락
원자적 연산
네임드락
ReentrantLock
비관적락 선정 이유
스크린샷 📷
같이 얘기해보고 싶은 내용이 있다면 작성 📢
좋은 내용이라 메이커스 백엔드 전부 CC 했습니당. 다들 한 번씩 읽어보시길
잘못된 내용이 있다면 고쳐주세용
totalReactionCount를 업데이트 하는 경우는 락을 잡지 않고 쿼리를 하나로 묶어주는 "원자적 연산"을 도입할 순 있으나, 현재 트래픽 수준에서는 성능 차이가 크지 않을 것으로 보여 현행으로 작성했습니당
Summary by CodeRabbit
릴리스 노트
버그 수정
테스트
✏️ Tip: You can customize this high-level summary in your review settings.