LearningCollector: 커밋 분류 방식 변경 및 코드 리팩토링

이번 커밋에서는 기존의 커밋 메시지를 기반으로 백준(Baekjoon) 또는 개발 관련 커밋을 분류하던 방식을 변경하고, 관련 코드를 간결하게 리팩토링했습니다. 핵심 변경 내용은 CommitClassifier 클래스를 제거하고, 대신 CollectionRules의 is_baekjoon_repo() 함수를 활용하여 저장소(repository) 이름을 기준으로 커밋을 분류하도록 로직을 수정한 것입니다.

요약

이번 작업은 core/classifier.py 파일을 제거하고 core/github_collector.py 파일의 로직을 수정하여, 커밋 메시지 대신 저장소 이름을 기준으로 백준 관련 커밋과 개발 관련 커밋을 분류하도록 변경했습니다. 이를 통해 CommitClassifier 클래스가 불필요해졌으며, collect() 및 collect_interactive() 함수의 코드 구조가 더욱 간결해졌습니다.

배경 및 목적

기존에는 커밋 메시지에 특정 접미사(-BaekjoonHub)가 붙어있는지를 확인하여 백준 커밋을 식별했습니다. 하지만 이 방식은 커밋 메시지 작성 규칙에 대한 의존성이 높고, 만약 접미사가 누락되거나 잘못 작성될 경우 분류 오류가 발생할 수 있다는 단점이 있었습니다.

이러한 문제를 해결하고, 보다 안정적이고 명확한 기준으로 커밋을 분류하기 위해 저장소 자체를 기준으로 백준 관련 커밋을 판단하는 방식으로 변경을 추진했습니다. 이를 통해 코드의 유지보수성을 높이고, 잠재적인 분류 오류를 방지하는 것을 목표로 했습니다.

구현 내용

이번 변경으로 인해 core/classifier.py 파일은 완전히 삭제되었으며, core/github_collector.py 파일에서 관련 로직이 제거 및 수정되었습니다.

• 파일명: core/classifier.py
  • 삭제 라인 수: 60
  • 설명: 백준 커밋을 판단하던 CommitClassifier 클래스와 관련된 모든 코드가 삭제되었습니다.
• 파일명: core/github_collector.py
  • 추가 라인 수: 47
  • 삭제 라인 수: 135
  • 설명:
    • CommitClassifier 인스턴스 생성이 제거되었습니다.
    • collect() 및 collect_interactive() 함수 내에서 커밋 메시지 대신 commit.get("repository")를 통해 저장소 이름을 가져와 CollectionRules.is_baekjoon_repo() 함수로 백준 저장소인지 판단하도록 변경되었습니다.
    • 분류 로직이 단순화되어, 백준 저장소 커밋은 백준 중복 체크를, 개발 저장소 커밋은 개발 중복 체크를 수행하도록 통합되었습니다.
    • 중복 커밋 처리 및 분류 결과 출력 로직도 함께 간소화되었습니다.

기술적 의사결정

새로운 분류 기준: 저장소 이름

• 선택: CollectionRules.is_baekjoon_repo(repo_name) 함수를 사용하여 저장소 이름을 기준으로 백준 관련 커밋을 분류했습니다.
• 이유:
  • 명확성 및 안정성: 커밋 메시지의 규칙에 의존하는 것보다 저장소 이름 자체를 기준으로 삼는 것이 훨씬 명확하고 안정적입니다. 저장소는 프로젝트의 성격을 직접적으로 나타내므로, 해당 저장소에 포함된 커밋은 그 성격을 따른다고 보는 것이 합리적입니다.
  • 유지보수 용이성: 커밋 메시지 규칙이 변경되더라도 분류 로직에 영향을 미치지 않으며, CollectionRules 파일만 수정하면 되어 유지보수가 용이합니다.
• 다른 대안:
  • 기존 커밋 메시지 패턴 유지: 이번 변경의 가장 큰 이유로, 이 방식은 이미 언급된 단점을 가지고 있어 선택하지 않았습니다.
  • git blame 또는 커밋 히스토리를 통한 추가 분석: 이는 구현 복잡성이 매우 커지고, 현재 프로젝트의 목표 범위를 넘어선다고 판단하여 선택하지 않았습니다.
• 장단점 분석:
  • 장점:
    • 분류 로직의 명확성과 안정성 향상
    • 코드 복잡성 감소 및 가독성 증진
    • 유지보수 용이성 증대
  • 단점:
    • CollectionRules 파일에 백준 관련 저장소 목록이 정확하게 정의되어 있어야 함 (하지만 이는 이미 잘 관리되고 있을 것으로 예상됩니다.)

배운 점 및 개선점

이번 작업을 통해 커밋 분류 방식의 중요성과, 코드의 의존성을 최소화하고 명확한 기준으로 로직을 설계하는 것의 가치를 다시 한번 느낄 수 있었습니다. 특히 CommitClassifier와 같이 특정 패턴에 의존하는 방식보다는, 데이터 자체의 성격을 명확히 나타내는 정보를 활용하는 것이 장기적으로 더 나은 설계임을 배웠습니다.

• 배운 점:
  • 복잡한 로직을 단순화하기 위해 외부 라이브러리나 규칙 파일(예: CollectionRules)을 적극적으로 활용하는 것의 중요성.
  • 메시지 패턴 대신 데이터의 근본적인 속성(저장소 이름)을 기반으로 분류하는 것이 더 견고한 설계임을 깨달았습니다.
• 개선할 점:
  • CollectionRules 파일의 백준 관련 저장소 목록이 최신 상태로 유지되고 있는지 주기적으로 확인할 필요가 있습니다.
• 다음 단계 계획:
  • 새로운 분류 로직이 예상대로 작동하는지, 수집된 데이터에 오류는 없는지 추가적인 테스트 및 모니터링을 진행할 예정입니다.
  • 이후 백준 외 다른 유형의 프로젝트(예: 다른 코딩 테스트 플랫폼)에 대한 수집 로직을 확장할 경우, 동일한 저장소 기반 분류 방식을 적용하여 일관성을 유지할 수 있을 것으로 기대됩니다.

참고 자료

• https://claude.ai/code/session_01NEhEqyz9T2tGuaHtyNkkBP (원본 커밋 참조 링크)