한국 개발 현장에서 오래 쓰인 에디터 EditPlus나 UltraEdit에는 줄바꿈 방식을 CR·LF·CRLF 중에서 명시적으로 지정해 저장하는 메뉴가 기본으로 들어 있다 — 그만큼 Windows 중심이던 개발·공공기관 환경에서 줄바꿈 불일치는 오래전부터 실무자들이 직접 챙겨야 했던 문제였다는 뜻이다.
이 차이는 어디서 왔는가
Unix와 macOS는 문자 하나를 사용합니다 — LF(라인 피드, \n). Windows는 오래된 텔레타이프 기기에서 한 쌍의 문자를 물려받았습니다 — CRLF(캐리지 리턴 + 라인 피드, \r\n): 하나는 캐리지를 줄 시작으로 되돌리고, 다른 하나는 그것을 아래 줄로 옮깁니다 — 타자기를 그대로 흉내 낸 것입니다.
지금도 중요한 이유
- Git. CRLF 줄바꿈을 가진 파일이 다른 파일들이 LF를 쓰는 저장소에 들어가면, 한 줄만 수정했어도 git이 "파일 전체가 변경됨"으로 표시할 수 있습니다 — 기술적으로 모든 줄의 끝이 바뀌었기 때문입니다.
- Shebang 줄. CRLF 줄바꿈으로 저장된 Unix 셸 스크립트는 배포 서버에서 실행에 실패할 수 있습니다. 인터프리터가 첫 줄에서 여분의
\r문자를 보기 때문입니다. - 코드 내 문자열 비교. CRLF 파일에서 읽은 줄은 화면에 보이는 텍스트가 같아 보여도 기대되는 LF 문자열과 비교할 때 일치하지 않을 수 있습니다.
어떻게 처리되는가
Git에는 checkout/commit 시 줄바꿈을 자동으로 변환하는 설정(core.autocrlf)이 있지만, 팀원 각자의 로컬 설정에 의존하는 방식은 불안정합니다. 저장소에 커밋하는 .gitattributes 파일로 파일 종류별 줄바꿈 스타일을 고정하는 편이 더 안정적입니다 — 그러면 에디터나 운영체제와 무관하게 규칙이 모두에게 동일하게 적용됩니다.
수동 변환이 필요한 이유
- 잘못된 줄바꿈 스타일로 저장소에 들어온 파일 고치기.
- Windows 에디터에서 편집된 스크립트를 리눅스 서버 배포 전에 준비하기.
- 겉보기에 동일한 두 파일 사이의 텍스트 비교에서 차이가 나는 이유 진단하기.
한 파일 안에 섞인 줄바꿈
여러 에디터나 서로 다른 OS에서 편집된 파일에는 CRLF와 LF가 동시에 섞여 있을 수 있습니다 — 일부 줄은 한 스타일, 일부 줄은 다른 스타일입니다. 이것이 가장 까다로운 경우입니다: "LF로" 변환해도 이미 LF였던 줄은 겉보기에 아무것도 바뀌지 않은 것처럼 보이지만, 눈에 띄게 "의심스러운" 줄만이 아니라 파일 전체에 변환을 적용하는 것이 중요합니다. 그렇지 않으면 문제가 눈에 보이지 않게 남아 있게 됩니다.