
난징대와 호주 CSIRO Data61 등 국제 공동 연구진이 지난 26일 arXiv에 공개한 논문에 따르면, 파이썬 코드 검사 도구는 속도뿐 아니라 점검 규칙의 범위와 설정 방식에서도 차이를 보였다. 연구진은 Ruff, Pylint, Flake8, Mypy, Black을 비교해 한 도구가 모든 측면에서 우위에 있지는 않다고 분석했다.
연구진이 공식 문서에서 수집한 규칙은 1,551개다. 두 명의 분석자가 규칙 설명을 대조해 의미상 같은 검사를 분류한 결과, 56%는 특정 도구에만 있었고 나머지는 둘 이상의 도구와 겹쳤다. Ruff와 Pylint를 함께 사용하면 조사 대상 규칙의 80% 이상을 포괄할 수 있었다. 이는 실제 버그의 80%를 찾아낸다는 의미가 아니라, 연구진이 수집한 검사 규칙의 범위를 비교한 수치다.
검사 성격도 달랐다. Pylint는 문법 오류와 객체의 잘못된 사용에 관한 규칙이 상대적으로 많았고, Ruff는 논리적 모순, 코드 스타일, 모범 사례 범주에서 더 많은 규칙을 갖췄다. 연구진은 중복 검사를 줄이면서 필요한 범위를 확보하는 조합이 중요하다고 설명했다.
속도 실험에서는 GitHub의 별 수 상위 파이썬 프로젝트 1만 개 가운데 1,000개를 무작위로 골라 기본 규칙과 전체 규칙 설정을 시험했다. 단일 규칙 실험은 계산 비용을 고려해 이 가운데 278개로 범위를 좁혔다. 최소 세 개의 가상머신 인스턴스에서 준비 실행과 반복 측정을 거친 결과, 연구에서 평가한 설정별 속도 순서는 Ruff, Mypy, Flake8, Black, Pylint였다.
다만 비교 대상의 역할이 완전히 같지는 않다. Mypy 공식 소개는 이 도구를 정적 타입 검사기로, Black 공식 문서는 코드 포매터로 설명한다. Ruff도 공식 문서에서 린터와 포매터 기능을 함께 제공한다고 밝히고 있다. 실행 시간이 짧다는 이유만으로 서로 다른 검사를 그대로 대체할 수 있다고 보기는 어렵다.
도입 양상을 살핀 표본에서는 다중 도구 사용이 흔했다. 연구진은 같은 상위 1만 개 프로젝트에서 다섯 도구의 설정이 확인된 3,094개를 분석했고, 이 중 56.6%가 둘 이상의 도구를 사용하는 것으로 집계했다. 전체 파이썬 생태계의 보급률이 아니라 해당 표본의 설정 파일을 조사한 결과다.
이번 연구는 arXiv에 사전 공개된 논문이다. 규칙 분류에 분석자의 판단이 개입할 수 있고, 연구 범위도 다섯 도구로 제한된다. 결과를 적용할 때는 조사에 사용된 규칙과 설정, 프로젝트 특성을 구분해야 하며, 현재의 모든 버전에 같은 속도 차이나 검사 범위가 보장되는 것은 아니다.
출처: arXiv 논문 초록 및 제출 이력 https://arxiv.org/abs/2610.35485 · 연구자 논문 본문 https://arxiv.org/html/2610.35485v1 · Ruff 공식 문서 https://docs.astral.sh/ruff/ · Mypy 공식 소개 https://mypy-lang.org/ · Black 공식 문서 https://black.readthedocs.io/en/stable/