커밋 타입 개선 및 추가 의견을 나눠주세요!

[Seono-Na]

안녕하세요, 팀원 여러분!

최근 프로젝트 초기 설정 단계에서 commitlint를 설정하기 위해 커밋 타입을 아래와 같이 임의로 생각해두었습니다. 하지만 팀원들의 의견을 반영해 더 나은 커밋 타입 체계를 만들고 싶어서 이 Discussion을 열게 되었습니다.

현재 커밋 타입 목록:

• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 수정
• style: 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등)
• design: 사용자 UI 디자인 변경 (CSS 등)
• test: 테스트 코드, 리팩토링 (Test Code)
• refactor: 리팩토링 (Production Code)
• build: 빌드 파일 수정
• ci: CI 설정 파일 수정
• perf: 성능 개선
• chore: 자잘한 수정이나 빌드 업데이트
• rename: 파일 혹은 폴더명을 수정만 한 경우
• remove: 파일을 삭제만 한 경우

논의하고 싶은 질문:

1. 현재 커밋 타입 중 불필요하다고 생각되는 항목이 있나요?
2. 추가되었으면 하는 커밋 타입이 있다면 어떤 것이 있을까요?
3. 특정 커밋 타입의 정의나 용도를 변경해야 한다고 생각하는 부분이 있나요?

예를 들어, 일부 팀에서는 style과 design을 하나로 통합하거나, rename과 remove를 더 구체적으로 정의하기도 하더라고요. 여러분의 의견을 듣고 우리 팀에 가장 적합한 커밋 타입 체계를 만들어가고 싶습니다.

여러분의 생각과 경험을 자유롭게 공유해주세요! 미리 감사드립니다 😊

[rmkim7]

커밋 타입 관련 저의 질문 및 의견은 아래와 같습니다.

• 빌드 파일 수정은 build, 빌드 업데이트는 chore로 분류되서 기준이 좀 애매한거 같습니다.
• 테스트 코드 리팩토링은 test, 프로덕션 코드 리팩토링은 refactor로 분류돼있네요. 프로덕션 코드와 테스트 코드의 리팩토링이 각각 분류돼 있는데 이렇게 세분화하는 게 더 나을지 모든 코드의 리팩토링은 refactor로 분류하는 게 나을지 다른 분들의 의견이 궁금합니다!
• rename, remove라는 타입이 직관적으로 파악이 되는 건 장점인 것 같습니다. 다만 이 둘을 합쳐서 자잘한 변경 사항은 하나의 타입(예시: modify)으로 묶는 것은 어떨까요?
• 기능 관련 사항을 수정할 경우 feat로 분류하는 게 맞을까요? 아니면 refactor로 분류하는 게 맞을까요?

커밋 타입은 저도 논의해보면 좋을 것 같다고 생각했던 부분인데 이렇게 디스커션을 열어주셔서 감사합니다 @Seono-Na 님!

[Seono-Na]

@rmkim7 님 좋은 질문 감사드립니다! 저도 고민하던 부분들이라 정리하면서 같이 기준을 맞춰가면 좋을 것 같아요😊

---

🔹 build vs chore에 대한 구분

저도 이 부분이 애매하다고 느껴졌는데요, 일반적으로는 아래처럼 구분한다고 합니다:

• build: 빌드 설정 자체나 결과물에 영향을 주는 변경 (예: vite.config.ts, tsconfig.json 등)
• chore: 의존성 업데이트나 dev 설정처럼, 빌드 프로세스보다는 주변 도구 설정에 가까운 작업

그래서 "빌드 업데이트"라는 말이 build에 가까운 의미라면 build로 하는 것도 좋은 방법 같지만,
명확하게 구분이 힘든 작업은 chore로 처리해도 될 것 같습니다.

결국 중요한 건 팀에서 일관되게 사용하는 것이라고 생각합니다!
그래서 일단은 기존에 사용하던 방식인 chore로 통일하여 사용하는 것도 좋은 방법이라고 생각합니다.
추후 팀원들과 더 논의하여 build 사용 유무에 대해 검토하면 좋을 것 같습니다!

---

🔹 refactor (production code) vs test

production code는 제품에 포함되는 실제 코드, test는 테스트 전용 코드로 구분하는 기준을 생각하고 있었어요.

• 테스트 코드만 리팩토링 → test
• 제품 코드 리팩토링 → refactor
• 둘 다 포함되면 케이스에 따라 나누거나, 통일해서 refactor로 처리하는 방식도 고려해볼 수 있을 것 같아요!

테스트 코드 관련 작업은 보통 커버리지, 테스트 전략 같은 맥락에서 진행되기 때문에, test 타입으로 분류하는 것도 자연스럽다고 생각해요.

---

🔹 rename, remove를 modify로 통합?

rename과 remove는 커밋 히스토리에서 작업 의도를 파악하기 좋고, Git도 자체적으로 추적해주기 때문에
현재처럼 분리하는 편이 명확하다고 생각합니다.

다만 나중에 너무 자잘한 작업이 많아져서 불편하다는 의견이 생기면, 그때 modify로 통합하는 것도 검토해보면 좋겠네요!

---

🔹 기능 관련 코드 수정인데 feat vs refactor?

저도 기능 관련 코드라고 하더라도 실제 동작이나 UI에 변화가 없다면 refactor가 맞다고 생각해요.

• feat은 사용자에게 노출되는 기능이 새로 추가될 때
• refactor는 동작은 동일하지만 코드 구조만 개선될 때

이 기준이 명확하면 커밋 메시지를 해석하는 데 도움이 많이 되겠죠!

---

혹시 다른 분들 의견도 더 들어보면 좋을 것 같아요.
같이 정리해보면서 컨벤션 맞춰가면 개발 흐름이 더 깔끔해질 것 같습니다!!🔥

[hyeopsang]

저는 리팩토링도 성능 개선을 하기 위해 하는 것으로 알고 있는데 리팩토링과 성능 개선의 명확한 기준이 있을까요? 잘 몰라서 여쭤봅니다.

[Seono-Na]

@hyeopsang 님 좋은 질문 감사합니다!

refactor는 가독성, 유지보수성, 재사용성 등을 높이기 위해 코드 구조를 변경하는 경우 사용하고,
perf는 속도 개선, 리소스 절약 등 성능 최적화를 한 경우 사용하게 됩니다.

다만 둘 다 해당하는 경우들이 생겨 혼란스러운 일이 발생할 수도 있다고 생각합니다!
"리팩토링하다보니 성능이 좋아졌네?"
"성능 개선을 위해 이걸 바꿨어!"
이렇게 의도나 관점에 따라서 말이죠.

따라서 두 가지 해결 방법이 있을 것 같습니다.

첫 번째,

• "리팩토링하다보니 성능이 좋아졌네?" → refactor 사용
• "성능 개선을 위해 이걸 바꿨어!" → perf 사용

이렇게 사용하기

두 번째,

• refactor로 통일.
• 이후 성능 개선이 자주 생길 때 perf 활용

어떤 방법이 더 좋을 지 의견 남겨주시면 감사하겠습니다.
그리고 다른 팀원들의 의견도 궁금합니다!🙏