*PR 제목은 한글(외래어, 외국어는 영어로)로 알아보기 쉽게 적습니다.*

ex: 로그인 기능 구현, input 컴포넌트 디자인 변경

## 💡 이슈번호

- close: #

## 📝 Points
> 리뷰어들이 중점적으로 보았으면 하는 부분을 적습니다. 
(ex: 어려웠던 점, 개선하고자 하는 점, 논의 하고자하는 점)

• 가이드를 따라 PR 합니다.
• 최대한 모든 팀원이 리뷰하고 merge 합니다. (1명 이상 approve)
• commit 컨벤션을 지킵니다.
• 본인 PR은 본인이 merge하고 conflict를 해결합니다.
• 코드 리뷰는 최대 3시간안에 작성합니다.
• merge는 최대한 틈틈히 자주합니다.

코드리뷰 체크리스트

1. 돌아 가는가 : 물론 PR을 올리는 개발자는 돌아가지 않는 코드를 PR해서는 안 됩니다. 하지만 컴파일 오류가 날 수 있는 치명적이고 명백한 코드가 수정된 소스안에 남아 있다면 코멘트를 남깁시다.
2. 컨벤션 : 팀의 코드 컨벤션을 어기는 부분은 없는지 점검합니다. 변수명이나 함수명, 이벤트명등이 직관적으로 이해되지 않는다면 코멘트를 남깁니다.
3. 디렉토리 : 새로운 파일이 생성되었다면 생성된 파일이 적합하고 가시성있는 위치에 컨벤션을 준수하여 저장되어 있는지 확인합니다.
4. 컴넌 구조 : 컴포넌트의 네스팅 깊이가 너무 깊어 특정 코드에 접근하기 어렵거나 너무 얕아 코드의 재사용성이 떨어지고 특정 파일이 특히 길어진다던지 하는 컴포넌트 구조와 배치를 확인합니다. 수정된 컴포넌트의 구조가 확장에 용이한지 살핍니다.
5. 최적화 : 코드가 불필요한 http 요청을 굳이 하지는 않는지, 렌더링 과정에서의 부하나 불필요한 컴포넌트의 재랜더링이 이루어지고 있지는 않나 확인합니다.
6. 중복 : 컴포넌트들 사이에서 같은 로직과 코드를 하드코딩해서 사용하고 있지는 않나 확인합니다. 그런 로직이 있다면 util로 분리하는게 좋습니다.
7. UI : 코드를 보고 구현된 실제 뷰가 요구사항에 맞게 잘 렌더링 되지 않을 수도 있겠다는 우려가 생길 수 있습니다. 그런 경우 직접 브랜치를 내려받아 돌려보시고, 무슨 문제인지 눈으로 직접 보고 판단하는게 좋습니다. 귀찮은 일일지도 모르겠습니다만, 더 나은 팀을 위해서는 적극적으로 서로의 실수를 검증하는 깐깐한 자세가 필요하다고 생각합니다.

브랜치명 규칙

브랜치명은 기능단위로 생성 후 삭제합니다.
이름/타입/기능 형태로 만들고, merge 즉시 삭제합니다. (잊지않고 삭제해주세요!)

thddlmy/feat/login
thddlmy/feat/comment-delete