add dev-culture and dev-process

README.md

@@ -4,6 +4,8 @@
 <!-- TODO: 각 제목마다 폴더 링크 추가 -->
 ### 개발 문화 / 프로세스
 <!-- 대략적인 설명 -->
+#### [개발 문화](./development-culture)
+#### [프로세스](./development-process)
 
 ### 브랜치 전략
 

development-culture.md

@@ -0,0 +1,44 @@
+# 개발 문화
+
+## 1. 수평적인 조직 문화
+- 명령과 복종의 구조가 아닌, **상호 존중에 기반한 수평적 관계**를 지향합니다.
+- 질문에 대해 사과할 필요가 없으며, 질문을 부담스럽게 여기지 않습니다.
+  - 특히 **기초적이거나 단순해 보이는 질문**일수록 더욱 자유롭게 할 수 있습니다.
+  - 질문을 받는 상황에서는 언제나 **적극적이고 친절하게 답변**합니다.
+  - 질문으로 인한 시간 소모를 염려하지 않으며, **질문도 중요한 피드백의 일종**으로 인식합니다.
+  - 깊이 있는 질문 또한 언제든 환영하며, 질문을 받는 것이 개인에 대한 **비난이나 공격이 아님**을 인지합니다.
+
+## 2. 피드백의 개방성
+- **모든 상황에서 피드백을 수용**할 수 있는 환경을 조성합니다.
+- 피드백은 이성적으로 받아들이며, **긍정적이든 부정적이든 항상 선의로** 받아들입니다.
+- 항상 **친절하고 예의 있는 방식**으로 피드백을 주고받습니다.
+
+## 3. PR(코드 리뷰) 자주 수행
+- **작은 단위로 자주 PR**을 수행하여 피드백과 검토의 부담을 최소화합니다.
+- 주기적인 피드백을 통해 **코드 품질을 개선**하며, 진행 상황을 공유하고 조율할 수 있는 기반을 마련합니다.
+
+## 4. 공동 코드 작성 의식
+- 개인의 소유를 넘어서 **모두가 함께 사용할 수 있는 공용 코드**를 작성한다는 의식을 갖습니다.
+
+## 5. 스터디 참여 활성화
+- 다양한 스터디에 참여하여 **전문 지식과 경험을 확장**하고, 상호 간의 학습을 지원합니다.
+
+## 6. 유용한 자료 및 학습 자료 공유
+- 본인이 정리하거나 적용한 사례를 포함해 **유용한 자료를 공유**하며, 공동 학습에 기여합니다.
+
+## 7. 개인 활동의 공개
+- 학습, 개발 등 본인이 수행하는 활동을 **적극적으로 공개**합니다.
+- **주제와 무관한 내용**도 공유할 수 있으며, 특정 플랫폼이나 기술에 국한되지 않습니다.
+
+## 8. 코드 개선 기회 활용
+- **기회가 생길 때마다 코드 품질 개선**에 적극적으로 참여합니다.
+- 코드에 대한 소유권 개념을 벗어나, **누구나 기여할 수 있는 공용 코드**로서의 가치를 강조합니다.
+- **회의시간, 슬랙채널, github issues** 등 간접적으로도 제안하거나 도울 수 있는 방법이 있습니다.
+
+## 9. 모여서 각자 코딩(모각코) 세션
+- 혼자서 문제를 해결하려 하기보다는, **다른 구성원들과 적극적으로 논의**하고 아이디어를 공유합니다.
+
+## 10. 주간 회의
+- **자유로운 근황 공유 시간**을 마련하며, 누구나 회의 안건을 추가할 수 있습니다.
+- 관습적으로 진행할 필요없습니다.
+- 회의내용을 회의록으로 남겨야합니다.

development-process.md

@@ -0,0 +1,87 @@
+# 개발 프로세스
+
+## 1. 코드 리뷰 (Code Review)
+
+### 1.1. 코드 리뷰의 목적과 과정
+- **코드 리뷰**는 PR(Pull Request)에 대해 피드백을 제공하고 코드의 품질을 개선하는 과정입니다.
+- 프로젝트는 **공동의 책임** 아래 진행되므로, 코드 리뷰 역시 개발의 중요한 일부입니다.
+- **최소 1명 이상의 팀원**이 리뷰를 진행해야 하며, 관련된 팀원들이 최대한 참여하는 것이 권장됩니다. _(Assignee가 아니더라도 의견을 남길 수 있음)_
+- 리뷰를 통해 다음과 같은 작업이 이루어집니다:
+  - 피드백 수용 및 코드 수정.
+  - 코드 스타일 변경, 질문, 개선된 코드 제시 등 다양한 방식 활용.
+
+### 1.2. 코드 리뷰의 기본 원칙
+- 피드백은 권위나 실력과 무관합니다. **잘하는 사람이 못하는 사람에게 하는 것이 아님**을 인지해야 합니다.
+- 코드 리뷰는 **상호 학습**의 과정입니다.
+  - 남이 작성한 코드를 읽는 것만으로도 실력 향상에 도움을 줍니다.
+  - 같은 기능도 여러 가지 방식으로 구현될 수 있으므로, 리뷰를 통해 **시야를 넓히고 질문**합니다.
+- 리뷰의 **친절함과 배려**는 필수적입니다.
+
+### 1.3. 작성자와 리뷰어의 역할
+#### 코드 작성자
+- 코드의 **오류 및 오타**를 확인합니다.
+- **권장되지 않는 스타일**을 수정합니다.
+- **주석**을 추가하여 리뷰어의 이해를 돕습니다.
+
+#### 리뷰어
+- 작성자의 **의도를 이해**하고 피드백을 제공합니다.
+- **친절하고 배려 있는 태도**로 리뷰를 진행합니다.
+
+### 1.4. 리뷰 체크리스트
+- **코드 설계**: 코드가 잘 설계되어 있는가? 더 나은 방법이 있는가?
+- **함수의 기능**: 함수의 역할이 명확한가?
+- **복잡성**: 복잡한 구조를 단순화할 수 있는가?
+- **변수 이름**: 변수 이름이 직관적인가?
+- **코드 스타일**: 일관성을 유지하고 있는가?
+
+---
+
+## 2. 이슈 생성 (Issue Creation)
+
+### 2.1. 이슈의 정의와 활용
+- **이슈**는 프로젝트의 문제, 제안, 개선 사항 등을 기록하고 관리하는 도구입니다.
+- 과거에는 노션 칸반보드에서 이슈를 관리했으나, 현재는 **GitHub Issues**를 활용합니다.
+
+### 2.2. 이슈 생성 가이드
+- **자신의 코드뿐만 아니라 다른 팀원의 코드**에도 이슈를 등록할 수 있습니다.
+- 관련 예시는 [Soomsil-Android Issues](https://github.com/yourssu/Soomsil-Android/issues)를 참고하십시오.
+- **Assignees**: 이슈와 관련된 팀원을 추가합니다.
+- **Labels**: 이슈의 성격(버그, 기능 추가 등)을 명시합니다.
+- **Projects/Milestone**: 해당 기능을 활용하면 이슈 관리가 더욱 체계화됩니다.
+
+### 2.3. 이슈 제목과 내용
+- 제목은 **프로젝트 명**과 **핵심 내용**을 포함합니다. 예시:
+  - `[Soomsil 검색] 디자인 변경 사항 반영`
+  - `[Feature/Search] 검색 기능 추가`
+- 내부 문서는 **마크다운 형식**을 활용하며, 실제 사례를 참조하여 작성합니다.
+
+---
+
+## 3. PR (Pull Request)
+
+### 3.1. PR의 정의와 목적
+- **PR**은 브랜치 전략에 따라 분리된 변경 사항을 주 브랜치에 병합하기 전에 **리뷰와 동의**를 구하는 과정입니다.
+- **자주**, **작게**, **명확하게** PR을 작성해야 합니다.
+  - **자주**: 변경 사항이 발생할 때마다 즉시 PR 생성.
+  - **작게**: 여러 기능이나 변경 사항을 하나의 PR에 포함하지 않음.
+  - **명확하게**: 상세한 설명과 시연 자료를 제공.
+
+### 3.2. PR 작성 가이드
+- [Soomsil-Android Pull Requests](https://github.com/yourssu/Soomsil-Android/pulls)와 같은 실제 사례를 참고합니다.
+- 제목은 **프로젝트명**과 **핵심 변경 사항**을 포함합니다. 예시:
+  - `[Feature/Search] 검색 뷰 진입 시 키보드 활성화 기능 추가`
+- PR 내용은 보통 다음과 같은 섹션으로 구성됩니다:
+  1. **Summary**: 변경 사항의 요약.
+  2. **Describe your changes**: 변경 전(As-is)과 변경 후(To-be) 상태를 설명.
+  3. **To reviewers**: 관련된 팀원을 호출하여 피드백 요청. _(예: @yourssu/android-maintainer)_
+
+### 3.3. PR의 중요성
+- PR은 팀 간 **소통과 협업**의 핵심 도구로, **개발 문화의 중심**입니다.
+- 자주 PR을 올리고, 이를 통해 **피드백을 자주 주고받아** 코드 품질을 지속적으로 개선합니다.
+
+---
+
+## 추가적으로 고려할 사항
+1. **자동화 도구 활용**: GitHub Actions, CI/CD 등을 도입하여 코드 검증을 자동화.
+2. **문서화**: 코드와 PR 과정에서 문서화를 철저히 하여 프로젝트 가시성을 높임.
+3. **주간 리뷰**: 정기적으로 이슈와 PR을 검토하고 진행 상황을 공유하는 회의를 통해 투명성을 강화.