Signal over Noise

터미널을 사용하다 보면 자연스럽게 이런 명령을 쓰게 된다.ps aux | grep nginx 또는ls | sort 이때 사용하는 | 기호는 너무 익숙해서 거의 의식하지 않는다. 그냥 “앞 명령의 결과를 뒤 명령으로 넘긴다” 정도로 이해하고 사용할 뿐이다.하지만 이 작은 기호 하나는 사실 소프트웨어 역사에서 꽤 중요한 아이디어 중 하나다. Unix가 단순한 운영체제가 아니라 프로그램을 조합해 문제를 해결하는 시스템이 된 이유도 바로 이 파이프(pipe) 때문이다.작은 프로그램들을 연결한다는 생각Unix 초기 프로그램들은 매우 단순했다.파일 목록을 보여주는 ls, 텍스트를 검색하는 grep, 파일 내용을 출력하는 cat 같은 도구들이 하나씩 만들어졌다.각 프로그램은 특정 기능 하나만 수행한다.이 방식은 단순..

리눅스나 macOS 터미널을 사용하다 보면 이런 명령을 종종 보게 된다.command > file 2>&1 많은 개발자들이 이 문장을 거의 습관처럼 사용한다.stdout과 stderr를 같은 곳으로 보내는 리디렉션이라는 것도 알고 있다. 그런데 여기서 한 번쯤 이런 생각이 든다.왜 Unix는 출력이 두 개일까? 대부분의 프로그래밍 언어에서는 출력이 하나뿐이다. 콘솔에 출력하면 그게 전부다. 하지만 Unix에서는 처음부터 stdout과 stderr가 분리되어 있다. 이 구조는 단순한 출력 기능이 아니라 Unix가 프로그램을 연결해서 사용하는 방식을 만들면서 등장한 설계다.Unix에서 프로그램은 서로 연결된다Unix의 가장 유명한 특징 중 하나는 파이프(pipe)다.command1 | command2 이 문..

터미널을 사용하다 보면 가끔 이해하기 어려운 문장을 보게 된다.command > file 2>&1 많은 개발자들이 이 문장을 익숙하게 사용한다. 보통은 “표준 출력과 에러 출력을 같은 곳으로 보낸다”는 의미 정도만 알고 넘어간다. 하지만 이 짧은 문장 안에는 생각보다 오래된 설계가 숨어 있다. 왜 Unix는 stdout과 stderr를 분리했을까?왜 프로그램은 | 하나로 서로 연결될 수 있을까?그리고 왜 Unix에서는 장치, 파이프, 심지어 네트워크까지도 파일처럼 다뤄질까? 이 질문들을 따라가다 보면 단순한 셸 문법을 넘어 Unix가 어떻게 설계되었는지에 대한 이야기로 이어진다. 우리가 매일 사용하는 커맨드라인 명령어들은 사실 수십 년 전에 만들어진 Unix의 입출력 모델과 철학 위에서 동작하고 있기 때..