CRLF 너가 뭔데 날 힘들게 해?
(↓ 클릭해서 기계식 타자기 ASMR을 들으며 읽어보자)
CRLF가 대체 뭔지 알기 위해서는 일단 키보드의 전신이라고 할 수 있는 기계식 타자기에 대해 이야기해야 한다.
기계식 타자기는 한 자씩 글자를 입력할 때마다 종이가 물려있는 캐리지Carriage를 왼쪽으로 한 글자 만큼씩 움직여서 자연스럽게 다음 위치에 글자가 찍힐 수 있도록 한다. 이렇게 글자를 입력하다가, 줄을 바꾸고 싶으면 기계식 타자기에서는 두가지 동작이 필요하다. 하나는 이동되어 있는 캐리지를 다시 시작점으로 되돌리는 작업(= 글자가 찍힐 가로 위치를 줄의 시작점으로 바꾸는 작업) 그리고 두번째는 종이를 한 줄만큼 위로 올리는 작업(= 글자가 찍힐 세로 위치를 한 줄 내리는 작업)이다. 여기서 첫번째 작업을 캐리지 반환Carriage Return 이라고 하고, 두번째 작업을 줄 삽입Line Feed 이라고 한다. 그리고 이 두가지 동작은 컴퓨터에서 각각 /r과 /n이라는 글자로 표현된다.
문제는 OS마다 줄바꿈을 표기하는 방법이 다르다는 점이다.
Windows에서는 줄바꿈을 표현할 때 CRLF = /r/n = 캐리지 반환 후 줄 삽입 으로 표현하고 있고, MacOs를 포함한 대부분의 UNIX 시스템들은 LF = /n = 줄 삽입 만으로 줄바꿈을 표현하고 있다. 사실 컴퓨터에는 캐리지 따위가 없다보니 UNIX처럼 한 byte로 표현하는 것이 무조건 더 합리적인 방식으로 보이지만, Windows에도 그들만의 합리적인 이유가 있다. 초기형 프린터 중에는 teletype라 해서 기계식 타자기와 같은 메커니즘을 사용하며 이를 컴퓨터를 통해 동작시키는 제품들이 있었다고 한다. 이들도 그 근본이 타자기이다보니 CR과 LF 입력이 별도로 필요했고, Windows는 타자기와의 호환성을 위해 CRLF를 본인들의 줄바꿈 표기 방법으로 결정했다고 한다.
MacOS에서 작성된 문서를 Windows에서 불러온다거나 할때 에러의 주범이 된다.
물론 대부분의 경우에는 각 OS에서 자동으로 줄바꿈 표기를 변환하는 과정을 거치기는 하지만, 가끔씩 변환이 이루어지지 않는 확장자라던가, Windows에서 UNIX 타입으로 스스로 생성한 파일이라 인식이 안된다던가 하는 문제들이 발생하고는 한다.
이번에 팀에서 환경설정을 하면서 겪은 일을 예로 들자면, Windows PC에서 eslint 설정파일을 생성할 때에 줄바꿈 방식을 UNIX 스타일로 지정을 했더니 에러가 발생했다. 외부에서 가져온 파일이 아니고, Windows OS에서 직접 LF만 사용하도록 설정했더니 별도의 컨버전 과정이 일어나지 않아 파일을 제대로 읽을 수 없었던 것이다.
결국 OS간의 호환성 문제이므로, 항상 유의하는 수밖에 없는 것 같다.
그래도 대부분의 경우 자동으로 변환이 이루어지므로 너무 걱정할 것은 없다. 예를 들어, Github의 경우 remote에서 local, local에서 remote를 오고 갈 때에 자동으로 변환되게끔 설정해 줄 수 있다. 대부분의 경우 remote에서는 UNIX 스타일을 사용하므로, Windows 사용자들은 대부분 local에서 읽을 때는 CRLF로, remote에 업로드 할 때에 LF 방식으로 변환되게끔 설정하는 편이다. 실제로 앞서 이야기한 문제 상황에서도 파일을 github remote repository에 push한 다음 다시 pull 받으면서 자동으로 변환이 이루어져서 문제를 간단하게 해결 할 수 있었다. 다만 여러 OS를 오고가며 작업을 하게되면 꽤나 자주 발생하는 문제이고 대부분의 경우 육안으로는 문제의 원인을 파악할 수 없으므로, 항상 마음속 한켠에 이런 문제가 발생할 수 있음을 인지해 두어야 예상치 못한 시간낭비를 막을 수 있을 것이다.