diff --git a/docs/tech.md b/docs/tech.md
index 31dcda1..0448000 100644
--- a/docs/tech.md
+++ b/docs/tech.md
@@ -5,8 +5,22 @@
 ## 목차
 
 - [목차](#목차)
-- [의존성 제한](#의존성-제한)
-- [코드 품질 제한](#코드-품질-제한)
+    - [의존성 제한](#의존성-제한)
+    - [코드 품질 제한](#코드-품질-제한)
+        - [일관성 있는 코드](#일관성-있는-코드)
+        - [린트 도구](#린트-도구)
+    - [협업 방법](#협업-방법)
+        - [이슈 등록](#이슈-등록)
+            - [이슈 라벨](#이슈-라벨)
+            - [이슈 네이밍](#이슈-네이밍)
+        - [신규 브랜치 생성](#신규-브랜치-생성)
+            - [브랜치 네이밍](#브랜치-네이밍)
+        - [개발 중 커밋 컨벤션](#개발-중-커밋-컨벤션)
+        - [풀 리퀘스트](#풀-리퀘스트)
+            - [풀 리퀘스트 네이밍](#풀-리퀘스트-네이밍)
+            - [풀 리퀘스트 라벨링](#풀-리퀘스트-라벨링)
+            - [테스트 전용](#테스트-전용)
+        - [메인 브랜치 반영 이후](#메인-브랜치-반영-이후)
 
 ## 의존성 제한
 
@@ -17,11 +31,106 @@
 
 ## 코드 품질 제한
 
+### 일관성 있는 코드
+
 - 코드 베이스 반영 전에 import 최적화를 수행합니다.
 - 코드 베이스 반영 전에 불필요한 공백이 있는지 확인합니다.
 - 테스트가 실패할 경우, 코드 베이스에 절대 반영하지 않습니다.
 - 프로젝트 라인 커버리지 제한은 70% 이지만, 90% 이상을 목표로 합니다.
 - 중요하지 않은 hotfix를 제외한 모든 유형의 코드 반영은 PR을 통해 이루어져야 합니다.
-- develop 코드 베이스에 반영할 경우 gpt 리뷰를 받습니다.
+- 모든 develop 브랜치에 병합되는 PR은 협업자간에 코드 리뷰를 수행합니다.
+    - 만약, 시간적인 제약으로 인해서 코드 리뷰를 받지 못하는 경우에는 PR에 `run: gpt code review` 라벨을 붙이고 ChatGPT에게 리뷰를 받습니다.
+
+### 린트 도구
+
+- 린트와 인텔리제이 코드 자동 정렬 설정을 협업자간에 동일하게 구성합니다.
+- git commit 이전에 린트 검사를 수행합니다.
+    - commit 이전에 자동으로 스타일 검사를 수행하기 위해서 다음 명령어로 Hook을 등록합니다.
+    - `./gradlew addKtlintCheckGitPreCommitHook`
+- 린트로 인해 빌드가 안될 경우에 빌드 디렉터리에 들어가 원인을 파악하고 코드를 수정합니다.
+    - 코드를 수정한 다음, `./gradlew ktlintCheck` 를 수행해 린트 검사 결과를 최신화합니다.
+    - 만약, 어떻게 코드를 수정해야하는지 모르겠다면, `./gradlew ktlintFormat` 을 수행해 코드를 자동 수정할 수 있습니다.
+
+## 협업 방법
+
+### 이슈 등록
+
+새로운 작업을 하기 이전에 깃헙 이슈를 등록합니다.
+
+#### 이슈 라벨
+
+이슈에 등록 가능한 라벨의 유형은 다음과 같습니다. problem은 problem 이슈 템플릿을, 나머지는 task 이슈 템플릿을 사용합니다.
+
+- `new` : 신규 개발
+- `enhancement` : 리팩터링과 최적화를 비롯한 개선 작업
+- `chore` : 설정을 비롯한 부수적인 작업
+- `problem` : 문제 발생
+- `documentation` : 문서화
+
+#### 이슈 네이밍
+
+- 이슈의 이름 형식은 `[type] title` 입니다.
+
+- 이슈의 이름 형식 타입은 PR에서 사용하는 제목의 타입과 동일합니다. 단, PR 제목 타입에는 `배포`가 추가됩니다.
+    - `기능 구현` : new
+    - `개선` : enhancement
+    - `설정` : chore
+    - `문서` : documenation
+    - `문제` : problem
+
+### 신규 브랜치 생성
+
+현재 개인 환경에 있는 브랜치가 저장소에 있는 최신 코드인지 확인하고, **develop 브랜치**에서 신규 브랜치를 생성합니다.
+
+#### 브랜치 네이밍
+
+- 브랜치의 이름 형식은 `type/이슈 번호` 입니다.
+
+- 브랜치 이름의 타입은 다음과 같습니다. (앵귤러 JS 커밋 컨벤션의 타입을 따름)
+    - `feat` : new
+    - `refactor` : enhancement
+    - `chore` : chore
+    - `fix` : problem
+    - `docs` : documentation
+    - 기타 추가 가능
+
+### 개발 중 커밋 컨벤션
+
+개발 시 커밋 메시지는 [앵귤러 JS 커밋 컨벤션](https://gist.github.com/stephenparish/9941e89d80e2bc58a153)을 따르되, `type` + `subject`까지만
+작성해도 괜찮습니다.
+
+### 풀 리퀘스트
+
+#### 풀 리퀘스트 네이밍
+
+- 개발이 끝나면 develop 브랜치로 PR을 생성합니다.
+- 풀 리퀘스트 이름 형식은 이슈 형식과 거의 동일합니다.
+- 차이점은 PR 뒤에 () 내부에 연관 이슈를 추가하는 것입니다.
+    - 예시 : `[문서] 가이드 문서 작성(issue#58)`
+- 관련 이슈가 한 개가 아니라면 구분자를 콤마(,)를 이용해 나열합니다.
+- **(중요)** main 브랜치에 반영되는 경우에는 `[배포]`를 접두어로 사용하고, `deployment` 혹은 `no-deployment` 라벨을 등록합니다.
+- **(중요)** main 브랜치에 반영되는 경우에는 () 내부에 연관 PR을 추가합니다.
+    - 예시 :
+        - `[배포] 메인 브랜치 반영(PR#23,PR#28)` : 버전이 증가하지 않는 경우
+        - `[배포] v0.0.1(PR#12,PR#98)` : 버전이 증가하는 경우
+
+#### 풀 리퀘스트 라벨링
+
+- 현재 풀 리퀘스트의 라벨을 이용해서 자동으로 실행하는 github actions 작업이 존재합니다.
+    - `run: ci` : 빌드, 테스트, 테스트 커버리지 분석, 린트, 정적 코드 분석 실행
+    - `run: gradle test` : 빌드, 테스트, 테스트 커버리지 분석 실행
+    - `run: gpt code review` : ChatGPT 코드 리뷰 실행
+    - `no-deployment` : 컨테이너 이미지 저장소(docker hub)에 신규 이미지 릴리즈하지 않음
+
+#### 테스트 전용
+
+- `[테스트]` 접두어를 사용하고, `ignore` 라벨을 등록합니다.
+- 테스트 전용 PR은 코드 베이스에 반영하지 않습니다.
+
+### 메인 브랜치 반영 이후
+
+- 개인 개발 환경에서 머지 커밋을 포함한 최신 main 브랜치의 코드를 내려받습니다.
+- 태그를 만들고, 태그를 저장소에 push 합니다.
+- 해당 태그로 새로운 릴리즈 노트를 작성합니다.
 
 [⬆ 위로 올라가기](#목차)