React 문법은 비대면 자료를 따라가며 익힐 수 있습니다. 하지만 팀 프로젝트에서 진짜로 막히는 지점은 문법만이 아닙니다. 브랜치를 어떻게 나누는지, PR을 어떻게 올리는지, 리뷰를 어떻게 주고받는지, 코드 스타일을 어떻게 맞추는지에서 많이 막힙니다.
오늘은 React 컴포넌트를 하나 더 만드는 시간보다, 팀으로 코드를 만들기 위해 필요한 운영 방식을 봅니다.
commit은 단순 저장이 아닙니다. "어떤 변경을 왜 했는지" 남기는 기록입니다. 좋은 commit은 나중에 문제를 추적할 때 도움이 됩니다.
feat: 스터디 목록 필터 추가
fix: 마감된 스터디 신청 버튼 비활성화
refactor: 카드 컴포넌트 props 이름 정리
main에서 바로 작업하면 팀 전체가 위험해집니다. branch는 기능별로 안전한 작업
공간을 만드는 방식입니다. 각자 다른 branch에서 작업하고, 완성되면 PR로
합칩니다.
PR은 "코드 다 짰으니 봐주세요"가 아니라, 팀에게 맥락을 공유하고 합의를 요청하는 문서입니다. 좋은 PR은 리뷰어가 어디를 봐야 하는지 알려줍니다.
## 무엇을
- 스터디 목록에 모집 상태 필터를 추가했습니다.
## 왜
- 마감된 스터디를 숨겨 보고 싶다는 요구가 있었습니다.
## 리뷰 포인트
- 필터 이름이 이해하기 쉬운지
- 빈 결과 상태 문구가 적절한지
컨벤션은 "누가 맞고 틀리냐"의 문제가 아니라, 팀이 같은 방식으로 생각하기 위한 약속입니다. 이름 짓기, 폴더 구조, 커밋 메시지, 컴포넌트 분리 기준이 모두 여기에 들어갑니다.
is, has, can으로 시작합니다.handleClick, handleSubmit처럼 동사로 시작합니다.timeoutMs, widthPx처럼 이름에 드러냅니다.컴포넌트를 무조건 작게 쪼개는 게 정답은 아닙니다. 다음 질문을 기준으로 봅니다.
코드 리뷰는 사람을 평가하는 자리가 아니라, 코드의 품질을 같이 맞추는 자리입니다. 좋은 리뷰는 구체적이고, 코드에 초점을 맞추고, 가능하면 대안을 제시합니다.
나쁜 리뷰: 이거 이상한데요.
좋은 리뷰: 이 함수는 getUser보다 fetchUserById가 더 명확해 보이는데 어떠세요?
리뷰를 받는 사람도 방어적으로만 반응할 필요는 없습니다. 리뷰어가 모르는 맥락이 있으면 설명하고, 더 나은 제안이면 받아들이면 됩니다. 좋은 팀은 리뷰를 통해 서로의 기준을 맞춰갑니다.
AI가 만든 코드를 그대로 올리는 것은 위험합니다. 최소한 다음은 확인해야 합니다.
AI를 썼다는 사실보다 중요한 건 어디까지 믿고, 어디를 직접 검토했는지 입니다. 이걸 설명할 수 있어야 협업에서 신뢰를 얻습니다.
다음 대면에서는 배포와 운영을 다룹니다. localhost에서 잘 되는 코드가 실제 사용자에게 전달되기까지 어떤 일이 필요한지 봅니다.