Git, 아직도 autocrlf라니 참 답답하다

가끔 회사 레포를 보면 아직도 core.autocrlf에 의존하는 경우가 있다. 솔직히 말해, 2025년에 이걸 쓰고 있다는 건 답답하다.

줄바꿈 문제는 과거엔 꽤 큰 골칫거리였다. Windows는 CRLF, 리눅스와 맥은 LF. 서로 다른 운영체제를 쓰는 사람들이 같은 코드를 건드리면 사소한 변경에도 diff가 잔뜩 생기고, 스크립트는 ^M 오류를 뿜으며 죽었다. Git은 여기에 "개인 Git 설정에서 알아서 줄바꿈을 바꿔주자"는 식으로 autocrlf를 내놨다. 처음엔 편리해 보였지만, 시간이 지나면서 이 방식은 오히려 혼란만 불러왔다. 팀원마다 설정이 다르면, 같은 저장소라도 누군가는 CRLF로, 다른 누군가는 LF로 작업하게 된다. 결국 "줄바꿈 전쟁"은 끝나지 않았다.

Git, 회사에서 늘 애매했다

사실 Git은 오픈소스 협업을 위해 만들어졌다. 리눅스 커널처럼 수많은 기여자가 제각각 패치를 보내오는 환경에서는 뛰어났다. 하지만 회사 환경은 달랐다. 회사는 특정 플랫폼과 툴을 표준으로 정해놓고, 수십 명의 개발자가 동일한 규칙 아래서 일한다. 이런 곳에선 Git의 철학—"개인 자유, 분산된 선택"—이 때때로 불편하게 작동한다. 줄바꿈이 대표적인 예다. 팀 차원의 규칙이 필요한데, Git은 오랫동안 그걸 개인 설정에 떠넘겼다.

지금은 많이 나아졌다. Windows 지원도 좋아졌고 IDE 통합도 훨씬 매끄러워졌다. 그럼에도 불구하고 Git을 회사에서 쓰다 보면 여전히 "쓸데없이 괴로운" 부분이 남아 있다. 줄바꿈 문제처럼 말이다.

사실 요즘은 CRLF든 LF든 큰 상관이 없다

현실을 보자. Visual Studio, VS Code, IntelliJ, Rider, Xcode, 심지어 메모장까지 이제는 CRLF와 LF를 모두 잘 다룬다. 어떤 라인 엔딩으로 저장돼 있어도 IDE는 알아서 열고, 저장도 무리 없이 해낸다. 그래서 대부분의 코드 파일은 사실 CRLF든 LF든 별 의미가 없다. 예전처럼 "어느 쪽으로 통일해야만 한다"는 절박함은 많이 줄었다.

그렇다면 왜 여전히 줄바꿈 이야기를 해야 할까? 이유는 간단하다. 특정 파일은 반드시 특정 라인 엔딩을 써야만 하기 때문이다.

특정 파일은 반드시 지켜야 한다

예를 들어 Windows 배치 파일(.bat, .cmd), 파워셸(.ps1), Visual Studio 솔루션과 프로젝트 파일(.sln, .csproj, .vcxproj)은 CRLF가 아니면 정상 동작하지 않거나 도구가 깨질 수 있다. 반대로 셸 스크립트(.sh)나 Dockerfile은 LF가 아니면 실행이 꼬인다.

이런 경우에 필요한 게 바로 .gitattributes다. 이 파일을 레포지토리에 넣어두면 Git은 개인 설정과 관계없이 정해진 규칙대로 줄바꿈을 처리한다. 다시 말해, 팀 차원의 합의가 코드로 강제되는 것이다.

예시: Windows 중심 조직

Windows가 주력인 조직이라면 이런 식으로 설정할 수 있다.

# 기본은 CRLF
* text=auto eol=crlf

# 리눅스/유닉스 환경에서 실행되는 파일만 LF
*.sh       text eol=lf
Dockerfile text eol=lf

# Windows 전용 파일은 CRLF
*.bat     text eol=crlf
*.cmd     text eol=crlf
*.ps1     text eol=crlf
*.sln     text eol=crlf
*.vcxproj text eol=crlf
*.csproj  text eol=crlf

# 바이너리는 변환 금지
*.png -text
*.jpg -text
*.gif -text
*.pdf -text
*.zip -text

이렇게 하면 꼭 필요한 파일만 라인 엔딩을 강제하고, 나머지는 IDE에 맡겨도 된다. "무조건 LF로 정규화" 같은 과잉 대응이 필요 없다.

그래서 autocrlf는 꺼둬야 한다

이제는 autocrlf를 켜둘 이유가 없다. autocrlf는 개인 로컬에서 파일을 강제로 변환하는데, 이게 문제를 일으키는 주범이다. .gitattributes가 있으면 Git은 이 규칙을 우선시하므로, 개인 설정은 불필요하거나 혼란만 만든다.

따라서 팀 차원에서는 core.autocrlf=false를 기본으로 두는 게 가장 안정적이다. 줄바꿈 처리는 저장소가 책임지고, 개발자의 Git은 "있는 그대로" 다루는 편이 낫다. 필요하다면 core.safecrlf=true를 켜서 이상한 변환을 막으면 충분하다.

git config --global core.autocrlf false
git config --global core.safecrlf true

결론

줄바꿈 문제는 더 이상 IDE가 해결하지 못해서 생기는 문제가 아니다. IDE는 이미 CRLF와 LF를 모두 잘 지원한다. 하지만 특정 파일은 여전히 특정 라인 엔딩을 필요로 한다. 이걸 해결하는 방법은 개인 Git 설정이 아니라, 저장소에 .gitattributes를 두는 것이다.

그러니 이제는 autocrlf를 꺼두자. "모든 텍스트 파일을 LF로 정규화해야 한다"는 강박도 내려놓자. IDE는 양쪽을 다 지원하고, 우리가 신경 써야 할 건 단 하나다. 반드시 특정 라인 엔딩을 필요로 하는 파일만 .gitattributes로 명확히 강제하는 것.

이렇게 하면 줄바꿈 전쟁은 끝나고, 더 이상 의미 없는 diff와 blame 오염으로 고생할 일도 없어진다.

제대로 대우받는 개발자 | 부족한 컴공지식 배우기 | MIT급 컴공인강

최저임금으로 고통받는 일회성 프로그래머는 그만! POCU 아카데미가 올해 연봉협상을 책임지겠습니다!