diff --git a/.github/workflows/auto-comment.yml b/.github/workflows/auto-comment.yml
index 6c23c92..e4cf71e 100644
--- a/.github/workflows/auto-comment.yml
+++ b/.github/workflows/auto-comment.yml
@@ -11,5 +11,6 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           pullRequestOpenedReactions: 'hooray, +1'
           pullRequestOpened: |
-            👋 @{{ author }}
-            구현하시느라 고생하셨어요! 조금만 기다려주시면 리뷰어가 리뷰를 해줄거에요. 😄
+            👋 @{{ author }} 님, 진행하시느라 고생하셨어요!
+            조금만 기다려주시면 리뷰가 시작될거에요. 😄
+            PR 이 리뷰를 위한 정보를 충분히 담고 있는지 마지막으로 살펴봐주시는건 어떨까요? 🤔
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b265d30..1d5eaaa 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -2,7 +2,7 @@
 
 > 본 문서는 언제든 변경될 수 있습니다. Issue 를 생성해주시거나, Discord 를 통해 의견을 전달해주세요.
 
-본 문서는 원활한 스터디를 진행하기 위한 가이드라인을 구성원들에게 제공하는 것을 목표로 작성되었습니다.
+본 문서는 스터디를 원활하게 진행하기 위한 가이드라인을 구성원들에게 제공하는 것을 목표로 작성되었습니다.
 
 ## Test 작성
 
@@ -12,7 +12,7 @@
 취향에 맞는 방식의 Spec 을 사용하시면서 어떤 Spec 이 어떤 상황에 어울리는지 고민해보시는 것도 좋습니다. 다만 **Annotation Spec 의 경우는 Java 의 JUnit5 와 거의 차이가 없기 때문에
 Kotlin Style 을 학습하는 이 스터디의 목표와는 맞지 않다**고 생각되기 때문에 제외합니다.
 
-## Pull Request
+## Pull Request Guide
 
 - PR 은 기능 단위로 생성해주세요
     - 중간에 구현이 막혔다면, 어떤걸 하려했고 어떤 부분이 막혔는지를 PR 을 통해 대략적으로 설명해주세요
@@ -22,6 +22,8 @@ Kotlin Style 을 학습하는 이 스터디의 목표와는 맞지 않다**고 
 - Ktlint 는 가급적 모두 통과시켜주세요
     - 다소 엄격하다고 생각될 수 있지만, Standard Rule 로 설정되어 있으므로 Kotlin 진영에서 권장하는 스타일은 무엇인지 살펴볼 수 있는 기회가 될거에요
 
+최대한 편리하게 PR 생성 및 리뷰 과정이 이루어질 수 있도록 자동화를 적용해뒀습니다. 몇 가지를 간단하게 소개해드릴게요.
+
 ### Size Labeling
 
 PR 을 생성하면 코드의 변경 내용을 기반으로 size 라벨링이 진행됩니다.
@@ -30,6 +32,13 @@ PR 을 생성하면 코드의 변경 내용을 기반으로 size 라벨링이 
 
 리뷰어는 라벨만 봐도 리뷰해야할 코드 양을 대략적으로 파악할 수 있습니다.
 
+- `XS` : 1 ~ 9 lines
+- `S` : 10 ~ 29 lines
+- `M` : 30 ~ 99 lines
+- `L` : 100 ~ 499 lines
+- `XL` : 500 ~ 999 lines
+- `XXL` : 1000+ lines
+
 ### Codecov
 
 PR 을 생성하면 작성된 코드를 테스트한 뒤 커버리지 리포트를 생성합니다.
@@ -65,17 +74,23 @@ Approve 가 완료되면 **다음 Assignee 가 원하는 시점에 PR 을 merge*
 
 ## Reviewer Guide
 
-코드 리뷰를 통한 커뮤니케이션은 이번 스터디의 핵심 목적이기도 합니다. 어떻게 하면 좋은 리뷰를 남길 수 있을지 함께 고민해보기 전에 참고해볼만한 자료들을 링크해두었습니다.
+좋은 코드 리뷰, 즉 **서로에게 도움이 되는 커뮤니케이션**은 이번 스터디의 핵심입니다. 어떻게 하면 좋은 리뷰를 남길 수 있을지 함께 고민해보기 전에 참고해볼만한 자료들을 링크해두었습니다.
 
 - [코드 리뷰 코멘트는 어떻게 작성하면 좋을까? 코드 리뷰 원칙 들여보기](https://mong-blog.tistory.com/entry/Team-%EC%BD%94%EB%93%9C-%EB%A6%AC%EB%B7%B0-%EC%BD%94%EB%A9%98%ED%8A%B8%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%9E%91%EC%84%B1%ED%95%98%EB%A9%B4-%EC%A2%8B%EC%9D%84%EA%B9%8C-%EC%BD%94%EB%93%9C-%EB%A6%AC%EB%B7%B0-%EC%9B%90%EC%B9%99-%EB%93%A4%EC%97%AC%EB%B3%B4%EA%B8%B0)
 - [Best Practice 1 - zzimkkong](https://github.com/woowacourse-teams/2021-zzimkkong/pull/969)
 
-스터디 목적에 맞게 재구성해봤어요.
+위 내용을 기반으로 우리의 스터디 목적에 맞게 재구성해봤어요.
 
 ### 1. 리뷰는 최대한 빠르게
 
+> 우리는 지금 폭탄 돌리기를 하고 있다고 생각해보세요. 😂 나보다 앞에서 너무 오래 들고 있다면...? 🧨💥
+
 리뷰가 최대한 빠르게 진행되어야 전체적인 흐름이 원활하게 유지될 수 있어요.
 
+다음 Assignee 의 충분한 구현 시간 보장을 위해 가급적이면 빠르게 리뷰가 진행되도록 노력해주세요.
+Assignee 는 Approve 개수가 충분하다면 언제든지 PR 을 merge 할 수 있는 권한을 가집니다.
+원하는 시점에 merge 하고 다음 과정을 진행해주세요.
+
 ### 2. 의견은 근거와 함께
 
 Fact(사실)와 Opinion(의견)을 구분하고, 의견이라면 합리적인 근거와 함께 전달해주세요.
@@ -88,7 +103,7 @@ Fact(사실)와 Opinion(의견)을 구분하고, 의견이라면 합리적인 
 >
 > kotlin 에서는 property 라는 대안도 있으니 `get~` 보다는 property 를 사용하시는게 어떨까요?(결론)
 >
-> - [Java 14 Record Keyword](https://www.baeldung.com/java-record-keyword) (신뢰성 있는 자료까지)
+> - [Java 14 Record Keyword](https://www.baeldung.com/java-record-keyword) (공신력 있는 자료까지)
 
 #### 안좋은 예 👎
 
@@ -107,10 +122,18 @@ LGTM 라면 👍 이나 짤과 함께 칭찬합시다!
 
 ### 4. 리뷰어 지정 방식
 
-기본적으로 Team 인원 모두를 지정합니다.
+기본적으로 Team 인원 모두를 지정합니다. 자동화되어 있기 때문에 별도로 지정할 필요는 없어요.
 
 merge 에 필요한 Approve 는 2개만 필요하니, 너무 늦게 PR 을 확인하시면 이미 merge 가 끝나있을 수 있어요~ 😂
 
-### 5. Assignee 지정
+### 5. Assignee 지정 방식
+
+시작 전 짧은 OT 를 통해 순서를 지정합니다.
+
+## Just Do It!
+
+불편한 부분이나 개선할 점이 있다면 언제든지 알려주세요.
+
+그럼... `Happy Hacking!` 🚀
 
-고민 중...
+![computer-cat](https://github.com/Learning-Is-Vital-In-Development/23-17-pair-programming-game/assets/56438906/ee6a1f11-5f2e-445a-800c-807be10a8314)
diff --git a/README.md b/README.md
index 6471a54..723102a 100644
--- a/README.md
+++ b/README.md
@@ -5,7 +5,7 @@
 ## 목표
 
 이 스터디는 **요구사항 및 기능을 직접 정의**해나가면서, **페어 프로그래밍을 위한 커뮤니케이션**에 초점을 맞추고 있어요. 부담갖지 마시고 하고 싶은 모든 걸 해보시기 바랍니다. 다른 팀원이 추가한 기술이나
-구현 방식이 새롭게 다가오는 기술이라면, 이야기해볼 수 있는 좋은 기회가 될거에요!
+구현 방식이 접해보지 못한 새로운 내용이라면, 함께 이야기해볼 수 있는 좋은 기회가 될거에요!
 
 ## 진행 과정
 
@@ -29,7 +29,7 @@
 
 ## 가이드
 
-아래는 로또에 대한 가장 기본적인 규칙이에요. 뭘 구현해야할지 막막하다면 현재 진행상황과 아래 규칙을 비교해보세요!
+아래 내용은 로또의 가장 기본적인 규칙이에요. 뭘 구현해야할지 막막하다면 현재 진행상황과 아래 규칙을 비교해보세요!
 
 - 구입 금액 입력
 - 구입 금액에 따라 1장에 1000원씩 계산하여 로또 발급하기
diff --git a/build.gradle.kts b/build.gradle.kts
index a3a0e35..84a7a19 100644
--- a/build.gradle.kts
+++ b/build.gradle.kts
@@ -50,7 +50,7 @@ tasks.jacocoTestCoverageVerification {
         rule {
             element = "CLASS"
             limit {
-                minimum = "0.70".toBigDecimal()
+                minimum = "0.50".toBigDecimal()
             }
         }
     }
diff --git a/src/main/kotlin/.gitkeep b/src/main/kotlin/.gitkeep
new file mode 100644
index 0000000..e69de29
diff --git a/src/test/kotlin/.gitkeep b/src/test/kotlin/.gitkeep
new file mode 100644
index 0000000..e69de29