빌드 자동화 시스템으로 널리 사용되는 Gradle(그래들)의 개발팀이 기존 Git(깃)을 대체할 차세대 버전 관리 시스템(VCS)으로 Jujutsu(주주쓰, jj)를 도입하려 했으나, 예상치 못한 사소한 문제에 부딪혀 계획을 잠정 보류했습니다. 바로 윈도우 환경에서 사용되는 'gradlew.bat' 배치 파일의 줄바꿈(EOL) 처리 방식 때문입니다. jj가 .gitattributes 파일에 정의된 파일별 줄바꿈 규칙을 제대로 읽지 못하면서, Git이 자동으로 처리하던 줄바꿈 변환이 jj에서는 지속적인 '가짜 변경(phantom modification)'으로 인식되는 현상이 발생했습니다.
Jujutsu(jj)는 Git 백엔드를 사용하는 Git 호환 VCS로, 스테이징 영역을 없애고 작업 복사본을 실제 커밋으로 표현하는 등 Git의 복잡성을 줄이고 효율성을 높이는 데 초점을 맞추고 있습니다. 커밋 편집, 재정렬, 충돌 처리 등에서 더 유연한 워크플로우를 제공하여 개발자들 사이에서 주목받고 있습니다. 그러나 Gradle 프로젝트의 경우, 윈도우에서 'gradlew.bat' 파일이 안정적으로 실행되려면 반드시 CRLF(캐리지 리턴+라인 피드) 줄바꿈 형식을 사용해야 합니다. Git은 .gitattributes 파일의 'text eol=crlf' 설정을 통해 저장소에는 LF(라인 피드)로 정규화하고, 체크아웃 시에는 CRLF로 변환하여 이 문제를 해결해왔습니다. 하지만 jj는 이 .gitattributes 규칙을 지원하지 않아, 디스크의 CRLF 파일을 저장소의 LF 파일과 다른 것으로 간주하며 계속해서 변경 사항이 있다고 표시하는 것입니다.
이 문제는 비단 Gradle 팀만의 것이 아니라, jj를 도입하려는 다른 프로젝트에서도 유사하게 발생할 수 있는 문제입니다. 현재로서는 'gradlew.bat' 파일을 CRLF 그대로 커밋하고 .gitattributes에서 줄바꿈 정규화를 중단하는 우회책이 제시되었지만, 이는 편집기에서 LF로 변경해도 Git이 자동 복구하지 않아 윈도우 환경에서의 실행 안정성을 해칠 수 있습니다. Gradle 팀은 이러한 위험을 감수하기 어렵다고 판단, 당분간은 Git Worktree(깃 워크트리) 기능을 활용해 여러 작업 디렉터리를 운영하며 병렬 작업을 처리할 계획입니다. jj의 개발팀이 .gitattributes의 EOL 지원 기능을 구현하면 다시 도입을 시도할 예정입니다.
이번 사례는 새로운 기술 도입 시 기존 시스템과의 미묘한 호환성 문제가 얼마나 큰 걸림돌이 될 수 있는지 보여줍니다. 특히 버전 관리 시스템처럼 개발 워크플로우의 핵심 인프라를 변경할 때는 사소해 보이는 부분까지도 면밀히 검토해야 한다는 교훈을 줍니다. jj의 EOL 지원이 추가된다면, Git의 복잡성에 지친 개발자들에게 더 나은 대안을 제공하며 VCS 생태계에 긍정적인 변화를 가져올 수 있을 것으로 기대됩니다. 그 전까지는 기존 Git의 유연한 기능들을 활용하며 새로운 기술의 성숙을 기다리는 것이 현명한 선택으로 보입니다.