├─📁 main
│  ├─📁 java
│  │  └─📁 Sopkathon
│  │      └─📁 SopkathonAndroidTeam3Server
│  │         ├─📁 config
│  │         ├─📁 controller
│  │         ├─📁 domain
│  │         ├─📁 dto
│  │         │  └─📁 request
│  │         │  └─📁 response   
│  │         ├─📁 repository
│  │         └─📁 service
│  │         └─📁 util
│  └─📁 resources
│      ├─static
│      └─templates
└─📁 test

Branch Strategy
1. main 브랜치에 바로 push하는 것을 지양합니다.
2. 기능 하나당 이슈를 한개 생성 후 기능 구현완료 후 해당 이슈를 닫고 브랜치를 삭제합니다.
3. 문제가 발생한 기능은 fix브랜치를 생성하고 작업완료 후 해당 이슈와 브랜치를 삭제합니다.
4. API 하나씩, 기능 개발 할때 마다 PR

Type
- [FEAT]: 새로운 기능 추가
- [UPDATE]: 기능 업데이트
- [FIX]: 버그 수정
- [REFACTOR] : 버그 수정이나 기능 추가가 없는 코드 변경 ( 코드 구조 변경 등의 리팩토링 )
- [TEST] : 테스트 추가 또는 이전 테스트 수정
- [DOCS]: README, wiki 문서를 수정
- [STYLE]: 코드 변경 없이 스타일 변경
- [CHORE]: 기타 사항이에요. (주석 추가 등등)

Naming
1. 변수는 CamelCase를 기본으로 한다.
2. URL, 파일명 등은 kebab-case를 사용한다.
3. 패키지명은 단어가 달라지더라도 무조건 소문자를 사용한다.
4. ENUM이나 상수는 대문자로 네이밍한다.
5. 함수명은 소문자로 시작하고 동사로 네이밍한다.
6. 클래스명은 명사로 작성하고 UpperCamelCase를 사용한다.
7. 객체 이름을 함수 이름에 중복해서 넣지 않는다. (= 상위 이름을 하위 이름에 중복시키지 않는다.)
8. 컬렉션은 복수형을 사용하거나 컬렉션을 명시해준다.
9. 이중적인 의미를 가지는 단어는 지양한다.
10. 의도가 드러난다면 되도록 짧은 이름을 선택한다.

Structure
1. 패키지는 목적별로 묶는다.
2. Controller에서는 최대한 어떤 Service를 호출할지 결정하는 역할과 Exception처리만을 담당하자.
3. 하나의 클래스 안에서는 같은 목적을 둔 코드들의 집합이여야한다.
4. 메소드와 클래스는 최대한 작게 만든다.
5. 도메인 서비스를 만들어지는 것을 피하자.


- 코드 포맷팅 : `ctrl + alt + l`(window), `command + option + l`(mac)
- 미사용 Import문 삭제 : `ctrl + alt + o`