"Git 갈아타려다 포기함" Gradle 팀이 신규 툴 jj 도입 접은 사소하지만 치명적인 이유

요약 최근 차세대 Git 호환 버전 관리 시스템으로 개발자들 사이에서 큰 주목을 받고 있는 '주주츠(Jujutsu, jj)'의 도입을 검토하던 Gradle 팀이 뜻밖의 '소소하지만 치명적인' 이유로 도입을 포기한 사연을 공개했습니다. jj는 Git 저장소와 완벽하게 호환되면서도 스테이징 영역(Index) 없이 작업 디렉터리가 바로 커밋으로 기록되는 혁신적인 방식을 취하고 있습니다. 히스토리 재작성이나 rebase가 간편하고 충돌 발생 시에도 작업을 멈추지 않는 등 뛰어난 장점이 많아, Gradle 개발팀의 한 엔지니어가 일상 업무 흐름에 jj를 적용하려고 시도했습니다. 하지만 근본적인 아키텍처나 기능 결함이 아니라, 빌드 래퍼 스크립트인 'gradlew.bat'의 줄바꿈(EOL) 처리 문제에 발목을 잡혔습니다. Gradle 프로젝트에는 윈도우 환경 실행을 위한 배치 파일인 gradlew.bat이 포함되는데, 이 스크립트는 cmd.exe의 특성상 줄바꿈이 LF로만 되어 있으면 goto나 라벨 인식 오류가 발생해 반드시 CRLF로 체크아웃되어야 합니다. Git에서는 '.gitattributes' 설정(*.bat text eol=crlf)을 통해 저장소에는 LF로 정규화해 저장하고 윈도우 체크아웃 시에만 CRLF로 자동 변환해 줍니다. 문제는 현재 jj가 .gitattributes 설정을 지원하지 않는다는 점입니다. Git과 jj를 함께 쓰는 환경(colocated repo)에서 jj는 디스크에 CRLF로 풀려 있는 배치 파일을 보고 저장소(LF)와 다르다고 판단해 끊임없이 유령 변경 사항(phantom modification)을 만들어냅니다. 전역 설정으로 모든 파일을 CRLF로 강제 변환할 수도 있지만 이는 다른 코드 파일까지 엉망으로 만들며, 배치 파일을 CRLF 고정 바이너리처럼 커밋하는 우회책은 향후 누군가의 편집기에서 줄바꿈이 깨졌을 때 자동 복구되지 않아 빌드가 터지는 위험이 있습니다. 결국 Gradle 팀은 생태계의 안정성을 희생하면서까지 무리하게 전환할 수는 없다고 판단해 당분간 기존처럼 'git worktree'를 유지하기로 결정했습니다. 향후 jj에 파일별 줄바꿈 필터 기능이 정식 도입되면 다시 도입을 검토하겠다고 덧붙였습니다.