# CRLF는 더 이상 사용되지 않으며 폐지되어야 합니다

> Clean Markdown view of GeekNews topic #17225. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=17225](https://news.hada.io/topic?id=17225)
- GeekNews Markdown: [https://news.hada.io/topic/17225.md](https://news.hada.io/topic/17225.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-10-14T09:57:41+09:00
- Updated: 2024-10-14T09:57:41+09:00
- Original source: [fossil-scm.org](https://fossil-scm.org/home/ext/crlf-harmful.md)
- Points: 9
- Comments: 8

## Summary

CRLF의 역사적 배경과 현대적 비효율성을 설명하며, 이를 폐지할 것을 촉구합니다. CRLF는 기계적 한계에서 비롯된 전통으로, 현대에는 불필요한 복잡성을 초래합니다. 관심을 끌었던 것은 이 글의 작성자가 SQLite의 개발자인 D. Richard Hipp 이기 때문입니다.

## Topic Body

##### 캐리지 리턴과 라인 피드의 정의

- **캐리지 리턴 (CR)**: 커서를 같은 행의 왼쪽 여백으로 이동시킴
- **라인 피드 (LF)**: 커서를 한 행 아래로 이동시키고, 이전 행들을 위로 스크롤함
- **뉴라인 (NL)**: 커서를 한 행 아래로 이동시키고 왼쪽 여백으로 이동시킴

##### 관찰

- CR과 NL은 유용한 제어 문자임. NL은 가장 일반적인 작업으로, 텍스트의 새로운 행을 왼쪽 여백에서 시작함
- LF는 실질적으로 쓸모없음. 아무도 행의 중간에서 다음 행으로 내려가서 같은 열에서 계속 쓰고 싶어하지 않음
- LF는 약 70년 전 기계식 전신 타자기 시대에 기원함

##### 역사적 배경

- 전신 타자기는 5초당 약 5개의 문자를 인쇄함
- CRLF의 전통은 1950년대 전신 타자기의 기계적 한계에서 비롯됨
- Multix와 Unix 시대에 CRLF를 NL로 사용하는 것이 비효율적이라는 인식이 확산됨

##### 현대의 상황

- 오늘날 CR은 U+000d로, LF와 NL은 U+000a로 표현됨
- 대부분의 현대 기계는 U+000a를 NL로만 사용함
- 일부 프로토콜은 여전히 CRLF를 요구하지만, 대부분의 소프트웨어는 단일 NL을 수용함

##### 행동 촉구

- U+000a 코드 포인트의 이름을 "라인 피드" 대신 "뉴라인"으로 변경
- 불필요한 CR 전송 중단
- CRLF를 요구하는 프로토콜에 대해 NL만 전송
- CR 없이 NL을 받으면 오류를 발생시키는 소프트웨어 수정

##### 요약 및 저자

- CRLF의 종말은 오래전부터 필요했음. 이 구시대적 유물을 없애기 위해 함께 노력해야 함
- 저자: D. Richard Hipp, SQLite의 창시자

##### # GN⁺의 정리

- 이 글은 CRLF의 역사적 배경과 현대적 비효율성을 설명하며, 이를 폐지할 것을 촉구함
- CRLF는 기계적 한계에서 비롯된 전통으로, 현대에는 불필요한 복잡성을 초래함
- 이 주제는 프로그래머와 소프트웨어 개발자에게 특히 유용할 수 있으며, 효율적인 데이터 전송을 위해 중요함
- 비슷한 기능을 가진 다른 프로토콜이나 시스템을 사용할 때도 CRLF의 필요성을 재고할 필요가 있음

## Comments



### Comment 30039

- Author: cosine20
- Created: 2024-10-14T16:21:02+09:00
- Points: 1

라인피드 가끔 쓰는뎅....

### Comment 30038

- Author: doolayer
- Created: 2024-10-14T14:42:33+09:00
- Points: 1

참 과격하네요 ㅎㄷㄷ

### Comment 30034

- Author: savvykang
- Created: 2024-10-14T13:02:43+09:00
- Points: 3

10월 14일 수정에 따르면 변경 제안을 철회한다고 합니다.  
  
단순히 한 시스템만 바꾸는 게 아니고 프로토콜과 영향있는 모든 시스템을 점진적으로 바꿔야 하는 일인데 제가 보기엔 필자가 신중하지 못했던 것 같네요

### Comment 30031

- Author: constexprif
- Created: 2024-10-14T12:54:34+09:00
- Points: 1

없애는 비용보다 없애서 얻는 이익이 크다고 생각한걸까요?

### Comment 30030

- Author: alstjr7375
- Created: 2024-10-14T12:44:57+09:00
- Points: 1

CR+LF has a long history...   
- https://www.revk.uk/2022/02/crlf-has-long-history.html  
  
오.. 이런 이유가..

### Comment 30023

- Author: bakyeono
- Created: 2024-10-14T11:13:46+09:00
- Points: 4

CRLF가 잘못 정의된 사양도 아니고, 당대의 하드웨어 환경을 반영한 것인데...  
하위 호환성은 잊어버리고, 오직 이 순간만 생각하는 것 같아요.  
하드웨어 사양이 바뀔 때마다 프로토콜을 갈아엎어야 할까요?

### Comment 30021

- Author: halfenif
- Created: 2024-10-14T11:00:57+09:00
- Points: 1

없애는것에 찬성도 반대도 안하지만.  
  
밀레니엄버그가 생각난건 왜일까요?

### Comment 30013

- Author: neo
- Created: 2024-10-14T09:57:41+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41830717) 
- 기존 프로토콜을 NL로 업데이트하는 것은 잠재적 버그를 초래할 수 있으며, HTTP/1.1은 이미 HTTP/2로 대체되었음
  - 새로운 프로토콜에서는 CRLF를 요구하지 않는 것이 합리적이지만, 기존 프로토콜을 업데이트할 필요는 없다고 주장함
- CRLF를 준수하지 않는 것은 의도적으로 버그를 도입하는 것과 같음
  - SQLite의 HTTP 서버가 \r\n 대신 \n을 사용하도록 업데이트되었으나, 이는 Zig의 HTTP 클라이언트와의 호환성을 깨뜨림
- CRLF를 후손들이 걱정할 필요가 없도록 하자는 의견
  - .gitattribute 파일 사용법을 가르치고, 바이트 순서 표시(Byte Order Mark)를 싫어하도록 교육해야 한다고 주장함
- Unix의 비표준 줄 끝맺음 선택은 실수였으며, 이는 수십 년간의 호환성 문제를 초래했음
  - CRLF는 터미널 API의 두 가지 다른 부분이며, 많은 프로그램이 CR과 LF의 올바른 작동에 의존함
- CRLF는 표준에서 가장 덜 중요한 요소 중 하나임
  - 표준을 깨는 것은 새로운 시도이며, 개인적으로는 낯선 태도임
- SMTP는 메시지 종료 시퀀스가 CR LF . CR LF임을 명확히 하고 있으며, LF . LF를 인식하는 구현도 존재함
  - 원래 SMTP 규칙이 더 이상 중요하지 않을 수도 있음
- CRLF는 많은 장치에 위험을 초래할 수 있으며, 예외를 줄여야 함
- 줄 끝맺음을 혼합했을 때 발생한 문제에 대한 언급이 없음
  - NL이라는 문자는 존재하지 않으며, 모든 키보드의 "ENTER" 키는 CR을 전송함
  - 현재 방식이 잘 작동하고 있음