2>&1 뒤에 숨은 Unix 설계 이야기

이상한 문장 하나에서 시작된 질문 — 2>&1

터미널을 조금이라도 오래 사용해 본 사람이라면 이런 명령을 한 번쯤은 보았을 것이다.

command > file 2>&1

이 문장은 리눅스와 유닉스 환경에서 매우 흔하게 등장한다. 로그를 파일로 저장할 때나 자동화 스크립트를 작성할 때 거의 습관처럼 사용된다. 많은 개발자들은 이 문장의 의미도 알고 있다. 보통 “표준 출력과 에러 출력을 같은 곳으로 보낸다”라고 설명된다. 실제로도 대부분의 상황에서는 그렇게 이해하고 사용해도 큰 문제가 없다. 하지만 이 문장을 조금만 천천히 들여다보면 묘한 질문이 하나 떠오른다. 왜 굳이 2라는 숫자가 등장하고, 왜 & 같은 기호가 필요하며, 무엇보다 왜 stdout과 stderr가 따로 존재하는 것일까 하는 의문이다.

이 질문은 의외로 깊은 곳까지 이어진다. 많은 프로그래밍 언어에서는 콘솔 출력이 하나뿐이다. 프로그램이 출력하면 그것은 그냥 콘솔에 나타난다. 오류 메시지도 같은 콘솔에 출력되고, 프로그램의 결과 데이터도 같은 콘솔에 출력된다. 사용자 입장에서는 특별히 구분할 이유가 없어 보인다. 그런데 Unix는 초기에는 하나의 출력만 사용했지만, 파이프가 도입되면서 정상 데이터와 오류 메시지를 분리하기 위해 stderr라는 별도의 스트림을 추가하게 된다. 그리고 그 구조 위에서 2>&1 같은 문법이 등장했다. 이 구조는 단순히 편의성을 위해 추가된 기능이 아니라 Unix가 프로그램을 연결 가능한 도구로 만들기 위해 선택한 설계였다.

조금 더 넓게 보면 이 이야기는 단순한 셸 문법의 설명이 아니다. 2>&1이라는 짧은 문장은 사실 Unix의 I/O 모델, 파이프라인 철학, 그리고 프로세스 구조까지 이어지는 긴 설계 이야기의 입구에 가깝다. 우리가 터미널에서 아무 생각 없이 입력하는 이 문장은 사실 수십 년 전 Unix 설계자들이 고민했던 문제와 해결 방법을 그대로 담고 있다. 그래서 이 문장을 이해하는 가장 좋은 방법은 단순히 리디렉션 문법을 외우는 것이 아니라, 왜 이런 문법이 필요했는지를 따라가 보는 것이다.

이 글은 바로 그 질문에서 시작한다.
왜 Unix는 stdout과 stderr를 분리했을까?
그리고 왜 우리는 여전히 2>&1이라는 문장을 사용하고 있을까?

이 질문에 답하기 위해서는 먼저 Unix 프로그램이 시작될 때 어떤 상태에서 출발하는지를 살펴볼 필요가 있다. 그 이야기는 자연스럽게 파일 디스크립터라는 개념으로 이어진다.

Unix 프로그램은 세 개의 파일로 시작한다

Unix에서 프로그램이 실행될 때 이미 세 개의 파일이 열려 있다는 사실은 생각보다 잘 알려져 있지 않다. 프로그램이 시작되는 순간 운영체제는 기본적으로 세 개의 파일 디스크립터를 준비해 둔다. 하나는 입력을 위한 파일이고, 나머지 두 개는 출력을 위한 파일이다. 우리는 그것들을 각각 stdin, stdout, stderr라고 부른다. 많은 사람들이 이 이름을 특별한 시스템 기능처럼 생각하지만 실제로는 단지 파일 디스크립터 번호에 붙은 관례적인 이름일 뿐이다. Unix 시스템 내부에서는 이 세 개의 스트림이 단순히 0, 1, 2라는 숫자로 표현된다.

이 구조는 Unix 설계 철학과 깊게 연결되어 있다. Unix의 가장 유명한 설계 원칙 중 하나는 “Everything is a file”, 즉 모든 것은 파일이다라는 생각이다. 디스크에 저장된 데이터뿐 아니라 터미널, 파이프, 장치, 네트워크 소켓까지도 파일처럼 취급된다. 프로그램은 특별한 장치를 직접 다루는 대신 단순히 파일 디스크립터에 데이터를 읽고 쓴다. 이 모델 덕분에 Unix는 매우 단순하면서도 강력한 입출력 구조를 가질 수 있었다. 프로그램 입장에서는 출력이 터미널로 가는지, 파일로 저장되는지, 아니면 다른 프로그램으로 전달되는지를 알 필요가 없다.

프로세스가 시작될 때의 구조를 단순화해서 보면 다음과 같다.

0 → stdin
1 → stdout
2 → stderr

프로그램은 이 번호들에 데이터를 읽거나 쓸 뿐이다. printf나 write 같은 함수가 결국 하는 일도 특정 파일 디스크립터에 데이터를 보내는 것이다. 이 데이터가 실제로 어디로 향하는지는 셸과 운영체제가 결정한다. 터미널일 수도 있고, 파일일 수도 있고, 파이프를 통해 다른 프로그램으로 전달될 수도 있다. 이러한 구조 덕분에 Unix는 프로그램을 매우 유연하게 연결할 수 있는 환경이 되었다.

이 단순한 모델은 Unix 시스템 전체의 설계를 결정짓는 중요한 기반이 된다. 프로그램은 입출력 장치를 직접 다루지 않는다. 대신 파일 디스크립터라는 추상적인 인터페이스만 사용한다. 그 결과 동일한 프로그램이 터미널에서도 동작하고, 파일을 대상으로도 동작하며, 파이프를 통해 다른 프로그램과 연결될 수도 있다. 이것이 Unix가 매우 다양한 환경에서 동일한 도구들을 재사용할 수 있게 만든 이유 중 하나다.

하지만 이 구조만으로는 아직 설명되지 않는 부분이 하나 남아 있다.
왜 stdout과 stderr가 굳이 둘로 나누어져 있어야 했을까 하는 질문이다.

이 질문에 대한 답은 Unix 역사에서 매우 중요한 기능 하나와 연결된다. 바로 pipe다.

Unix를 바꿔버린 작은 기능 — pipe

1970년대 초 Doug McIlroy의 제안으로 Unix에 pipe라는 기능이 추가된다. 오늘날에는 너무나 익숙해서 별것 아닌 것처럼 보이지만, 당시에는 시스템 사용 방식을 완전히 바꿔 놓은 기능이었다. 바로 pipe다.

command1 | command2

지금은 거의 모든 개발자가 자연스럽게 사용하는 문법이다. 하지만 이 단순한 기호 하나는 Unix의 사용 방식 자체를 바꾸어 놓았다. 파이프가 등장하기 전에는 프로그램이 대부분 독립적으로 실행되는 도구였다. 프로그램은 입력을 받고 결과를 출력한 뒤 종료한다. 다른 프로그램과 직접적으로 연결되는 경우는 많지 않았다. 하지만 파이프가 등장하면서 프로그램은 더 이상 단독 도구가 아니라 서로 연결되는 구성 요소가 되었다.

예를 들어 다음과 같은 명령을 생각해 보자.

ls | sort

이 명령은 매우 간단해 보인다. ls는 파일 목록을 출력하고, sort는 입력된 데이터를 정렬한다. 하지만 이 명령 뒤에서는 흥미로운 일이 일어난다. ls 프로그램이 출력한 데이터가 운영체제를 통해 파이프로 전달되고, 그 데이터가 sort 프로그램의 입력으로 들어간다. 두 프로그램은 서로를 전혀 알지 못한다. 서로의 존재를 인식하지도 않는다. 그럼에도 불구하고 자연스럽게 하나의 작업 흐름을 만들어 낸다.

이 구조는 Unix 철학의 핵심을 보여 준다. 프로그램은 하나의 일을 잘 수행하면 된다. 복잡한 기능을 한 프로그램에 모두 넣을 필요가 없다. 대신 작은 프로그램들을 연결하면 더 큰 작업을 수행할 수 있다. 이러한 접근 방식은 Unix 시스템을 매우 유연하고 확장 가능한 환경으로 만들었다. 사용자들은 다양한 프로그램을 조합해 자신만의 작업 흐름을 만들 수 있었고, 새로운 프로그램도 기존 도구들과 쉽게 연결될 수 있었다.

하지만 이 아름다운 설계에는 예상하지 못한 문제가 하나 숨어 있었다. 프로그램은 항상 정상적인 데이터만 출력하는 것이 아니다. 때로는 오류 메시지도 출력한다. 만약 프로그램의 오류 메시지가 데이터와 같은 출력 스트림으로 전달된다면 파이프라인 전체가 깨질 수 있다. 예를 들어 파일 목록을 처리하는 파이프라인에서 에러 메시지가 데이터로 섞여 들어가면 결과가 완전히 달라질 수 있다. Unix 설계자들은 이 문제를 단순한 사용상의 불편함이 아니라 파이프 철학 자체를 위협하는 문제로 인식했다.

그래서 등장한 해결책이 바로 stdout과 stderr의 분리였다. 정상적인 데이터와 오류 메시지를 서로 다른 스트림으로 분리함으로써 파이프라인의 데이터 흐름을 보호할 수 있게 된 것이다. 그리고 이 설계 덕분에 Unix는 수십 년 동안 안정적인 파이프 기반 자동화 시스템으로 발전할 수 있었다.

다음 섹션에서는 바로 이 지점에서 등장한 중요한 설계 선택, 즉 stdout과 stderr의 분리가 실제로 어떤 의미를 가지는지를 좀 더 깊이 살펴보게 된다.

파이프라인을 깨뜨리는 에러 메시지

앞에서 살펴본 것처럼 Unix의 파이프는 프로그램을 연결 가능한 도구로 만들어 주는 강력한 기능이었다. 작은 프로그램들을 이어 붙여 복잡한 작업을 수행할 수 있게 되면서 Unix는 단순한 운영체제를 넘어 하나의 작업 환경으로 발전하게 되었다. 하지만 이 구조가 실제로 사용되기 시작하면서 예상하지 못한 문제가 하나 드러나기 시작했다. 프로그램이 출력하는 모든 텍스트가 항상 “데이터”인 것은 아니라는 사실이었다.

많은 프로그램은 정상적인 결과뿐 아니라 오류 메시지도 출력한다. 예를 들어 파일 목록을 출력하는 ls 명령을 생각해 보자. 특정 디렉터리와 존재하지 않는 경로를 동시에 전달하면 ls는 두 가지 종류의 메시지를 출력한다. 하나는 실제 파일 목록이고, 다른 하나는 존재하지 않는 경로에 대한 오류 메시지다. 터미널에서는 이 둘이 함께 출력되더라도 큰 문제가 되지 않는다. 사용자는 화면을 보면서 어떤 것이 데이터이고 어떤 것이 오류 메시지인지 쉽게 구분할 수 있기 때문이다. 하지만 파이프를 사용하기 시작하면 상황이 완전히 달라진다.

예를 들어 다음과 같은 명령을 실행한다고 가정해 보자.

ls /tmp /not-exist | wc -l

이 명령의 의도는 매우 단순하다. /tmp 디렉터리의 파일 개수를 세는 것이다. 하지만 실제로는 wc 프로그램이 ls의 출력 전체를 입력으로 받아들인다. 즉 파일 목록뿐 아니라 오류 메시지까지 모두 입력 데이터로 처리하게 된다. 그 결과 파이프라인의 결과는 완전히 다른 의미를 가지게 된다. 사용자 입장에서는 단순히 파일 개수를 세려고 했지만, 실제로는 오류 메시지까지 포함한 줄 수가 계산되는 것이다.

이 문제는 단순한 사용상의 불편함을 넘어 Unix 설계의 핵심 철학과 충돌하는 문제였다. 파이프라인이 안정적으로 동작하려면 프로그램의 출력은 가능한 한 예측 가능한 데이터 흐름이어야 한다. 만약 오류 메시지가 데이터와 섞여 버린다면 파이프를 기반으로 한 자동화 작업은 매우 불안정해질 수밖에 없다. 시스템 관리자나 개발자가 작성한 스크립트는 작은 오류 메시지 하나 때문에 완전히 다른 결과를 만들어 낼 수도 있다.

Unix 설계자들은 이 문제를 매우 심각하게 받아들였다. 파이프라는 기능이 Unix 철학의 중심이라면, 그 철학을 깨뜨리는 요소는 반드시 제거되어야 했다. 그래서 등장한 해결책이 바로 출력 스트림의 분리였다. 프로그램의 정상적인 결과 데이터와 오류 메시지를 서로 다른 경로로 보내는 구조를 도입함으로써 파이프라인의 데이터 흐름을 보호하려는 시도였다. 이 결정은 단순한 기능 추가가 아니라 Unix의 I/O 모델 전체를 바꾸는 중요한 설계 선택이었다.

다음 섹션에서는 바로 이 지점에서 등장한 핵심 개념, 즉 stdout과 stderr의 분리가 어떤 의미를 가지는지 조금 더 깊이 살펴보게 된다.

stdout과 stderr의 분리

파이프라인 문제를 해결하기 위해 Unix 설계자들이 선택한 방법은 의외로 단순했다. 프로그램의 출력을 하나의 스트림으로 처리하는 대신 두 개의 스트림으로 분리하는 것이었다. 하나는 프로그램이 생성한 정상적인 데이터 결과를 위한 출력이고, 다른 하나는 오류 메시지를 위한 출력이다. 이렇게 해서 등장한 개념이 바로 stdout과 stderr다.

이 구조의 핵심은 파이프가 기본적으로 stdout만 전달한다는 점이다. 프로그램이 정상적인 데이터를 출력하면 그 데이터는 파이프를 통해 다음 프로그램으로 전달된다. 반면 오류 메시지는 별도의 스트림인 stderr로 전달되며 기본적으로는 터미널로 출력된다. 이 구조 덕분에 파이프라인은 안정적으로 동작할 수 있게 되었다. 프로그램이 오류 메시지를 출력하더라도 파이프를 통해 전달되는 데이터 흐름은 영향을 받지 않는다.

이 설계는 매우 단순하지만 강력한 효과를 만들어 냈다. 프로그램은 더 이상 출력 메시지의 종류를 신경 쓸 필요가 없었다. 단지 정상적인 결과는 stdout으로 보내고, 오류 메시지는 stderr로 보내면 된다. 그 이후에 이 출력이 어디로 전달되는지는 셸과 운영체제가 결정한다. 사용자는 필요에 따라 stdout만 파일로 저장하거나, stderr만 따로 로그로 기록하거나, 두 스트림을 다시 합칠 수도 있다.

이 구조를 조금 더 단순한 형태로 표현하면 다음과 같은 흐름이 된다.

program
 ├ stdout → pipe → next program
 └ stderr → terminal

이렇게 분리된 구조 덕분에 Unix 파이프라인은 매우 강력한 자동화 도구가 될 수 있었다. 여러 프로그램을 연결해 복잡한 데이터 처리 작업을 수행하는 경우에도 오류 메시지는 데이터 흐름을 방해하지 않는다. 결과적으로 Unix 시스템은 작은 프로그램들을 자유롭게 조합할 수 있는 환경이 되었고, 이러한 구조는 수십 년 동안 Unix 계열 시스템의 핵심 특징으로 유지되었다.

흥미로운 점은 stdout과 stderr가 특별한 시스템 기능처럼 보이지만 실제로는 단지 서로 다른 파일 디스크립터일 뿐이라는 사실이다. 즉 운영체제 입장에서는 특별한 구분이 있는 것이 아니라 단순히 두 개의 서로 다른 출력 채널이 존재하는 것뿐이다. 이러한 단순한 모델 덕분에 Unix는 매우 유연한 입출력 구조를 유지할 수 있었다.

이제 여기에서 자연스럽게 다음 질문이 등장한다. 만약 stdout과 stderr가 단순히 다른 파일 디스크립터라면, 우리는 이 두 스트림을 서로 다른 방식으로 연결하거나 심지어 다시 합칠 수도 있어야 한다. 그리고 바로 그 지점에서 등장하는 것이 우리가 처음에 보았던 문장, 2>&1이다.

그래서 등장하는 문장: 2>&1

stdout과 stderr가 서로 다른 스트림이라는 사실을 이해하면 이제 처음에 등장했던 문장을 조금 다른 시선으로 볼 수 있게 된다.

command > file 2>&1

이 문장은 단순히 “출력을 파일로 저장한다”는 의미 이상의 구조를 가지고 있다. 사실 이 문장은 두 단계의 리디렉션을 포함하고 있다. 먼저 > 연산자는 stdout을 파일로 보낸다. 즉 프로그램의 정상적인 출력은 터미널 대신 file이라는 파일로 전달된다. 그 다음 2>&1이라는 문장이 등장한다. 여기서 2는 stderr를 의미하고 1은 stdout을 의미한다. & 기호는 파일 이름이 아니라 파일 디스크립터를 참조한다는 의미를 가진다.

결과적으로 2>&1은 stderr를 stdout이 향하는 곳으로 보내라는 의미가 된다. 즉 stderr의 출력 경로를 stdout과 동일하게 설정하는 것이다. 이 두 단계가 결합되면 프로그램의 정상 출력과 오류 메시지가 모두 같은 파일로 전달된다. 우리가 흔히 “stdout과 stderr를 합친다”라고 표현하는 동작이 바로 이 과정이다.

이 동작을 조금 더 시스템 내부의 관점에서 보면 dup2라는 시스템 호출과 연결된다. Unix 커널은 파일 디스크립터를 복제하거나 다른 번호에 연결하는 기능을 제공한다. dup2(1,2)라는 호출은 파일 디스크립터 1을 복제해서 2번 디스크립터로 설정하는 역할을 한다. 즉 stderr가 stdout과 동일한 목적지를 가지도록 만드는 것이다. 셸은 리디렉션 문법을 해석하면서 내부적으로 이러한 시스템 호출을 사용해 파일 디스크립터를 재구성한다.

이렇게 보면 셸의 리디렉션 문법은 단순한 문자열 규칙이 아니라 Unix 프로세스 I/O 모델을 그대로 노출하는 인터페이스라고 할 수 있다. 우리가 터미널에서 입력하는 2>&1이라는 문장은 사실 커널 수준의 파일 디스크립터 조작과 연결되어 있다. 셸은 이 문장을 해석해 새로운 프로세스를 실행하기 전에 파일 디스크립터 테이블을 재구성한다. 그 결과 프로그램은 stdout과 stderr가 동일한 목적지로 연결된 상태에서 실행된다.

이제 다시 처음의 질문으로 돌아갈 수 있다. 왜 Unix는 stdout과 stderr를 분리했을까? 그리고 왜 우리는 2>&1이라는 문장을 사용하고 있을까? 그 이유는 결국 하나의 설계 철학으로 이어진다. 프로그램을 서로 연결 가능한 도구로 만들기 위해서는 데이터 흐름이 안정적으로 유지되어야 한다. stdout과 stderr의 분리는 그 철학을 지키기 위한 선택이었고, 2>&1은 필요할 때 그 두 흐름을 다시 합칠 수 있도록 해 주는 도구였다.

이 작은 문장은 단순한 셸 문법이 아니라 Unix I/O 모델의 핵심을 보여 주는 하나의 창과 같다. 그리고 이 구조 덕분에 Unix 시스템은 수십 년 동안 동일한 철학을 유지하면서도 계속 발전할 수 있었다.

리디렉션 순서가 중요한 이유

지금까지 stdout과 stderr가 분리된 이유와 2>&1이 어떤 의미를 가지는지 살펴보았다. 하지만 실제로 셸 리디렉션을 사용할 때 종종 개발자들을 혼란스럽게 만드는 부분이 하나 더 있다. 바로 리디렉션의 순서다. 겉으로 보기에는 비슷해 보이는 명령이 실제로는 완전히 다른 결과를 만들어 내는 경우가 있기 때문이다.

예를 들어 다음 두 명령을 비교해 보자.

command > file 2>&1

command 2>&1 > file

많은 사람들은 이 두 문장이 같은 의미일 것이라고 생각한다. 두 경우 모두 stdout과 stderr를 파일로 보내는 것처럼 보이기 때문이다. 하지만 실제로는 전혀 다른 결과가 나온다. 첫 번째 명령에서는 stdout이 먼저 파일로 리디렉션되고, 그 다음 stderr가 stdout이 향하는 목적지를 따라가게 된다. 결과적으로 두 출력은 모두 파일로 저장된다.

반면 두 번째 명령은 전혀 다른 순서로 처리된다. 먼저 stderr가 현재 stdout이 향하는 곳을 따라가게 된다. 이 시점에서 stdout은 아직 터미널을 향하고 있기 때문에 stderr도 터미널로 연결된다. 그 다음에 stdout이 파일로 리디렉션된다. 결과적으로 stdout만 파일로 이동하고 stderr는 여전히 터미널에 남게 된다.

이 차이는 셸이 리디렉션을 처리하는 방식과 직접적으로 연결되어 있다. 셸은 리디렉션을 한 번에 해석하는 것이 아니라 왼쪽에서 오른쪽 순서로 차례대로 적용한다. 따라서 리디렉션 문장의 순서 자체가 파일 디스크립터 테이블의 상태를 단계적으로 바꾸는 과정이 된다.

이 점을 이해하면 셸 리디렉션이 단순한 문법이 아니라는 사실을 알 수 있다. 그것은 사실상 프로세스가 시작되기 직전에 파일 디스크립터 구조를 재구성하는 명령에 가깝다. 셸은 프로그램을 실행하기 전에 리디렉션 문장을 해석하고, 필요한 dup이나 dup2 시스템 호출을 수행하여 파일 디스크립터 테이블을 수정한다. 그런 다음에야 새로운 프로세스를 실행한다.

이 과정은 겉으로 보기에는 매우 단순한 셸 문법 뒤에 숨어 있는 Unix 내부 구조를 그대로 드러낸다. 우리가 터미널에서 입력하는 짧은 리디렉션 문장은 사실 커널 수준의 파일 디스크립터 조작을 직접 제어하는 인터페이스이기도 하다.

이제 이 구조를 이해하면 2>&1이라는 문장이 왜 그렇게 생겼는지도 자연스럽게 설명된다. 그것은 단순히 출력 경로를 지정하는 문법이 아니라 Unix의 파일 디스크립터 모델을 그대로 노출한 결과이기 때문이다.

50년이 지나도 살아 있는 설계

stdout과 stderr의 분리는 1970년대 Unix에서 등장한 설계다. 당시 Unix는 연구용 시스템에 가까웠고, 오늘날처럼 수십억 개의 시스템에서 사용되는 플랫폼이 될 것이라고 예상한 사람은 많지 않았다. 그럼에도 불구하고 이 작은 설계 선택은 수십 년 동안 거의 변하지 않고 유지되고 있다.

현대 시스템을 조금만 들여다보면 이 구조가 얼마나 깊게 자리 잡고 있는지 쉽게 발견할 수 있다. 예를 들어 Docker 컨테이너를 생각해 보자. Docker에서 컨테이너 로그를 수집할 때 기본적으로 사용하는 두 개의 스트림이 바로 stdout과 stderr다. 컨테이너 내부의 프로그램이 stdout으로 출력한 내용은 일반 로그로 처리되고, stderr로 출력된 내용은 오류 로그로 구분된다.

이 구조는 Kubernetes와 같은 오케스트레이션 시스템에서도 그대로 유지된다. Kubernetes는 컨테이너 로그를 수집할 때 stdout과 stderr를 각각 다른 스트림으로 저장한다. 사용자는 필요에 따라 두 로그를 함께 보거나 따로 분석할 수 있다. CI 시스템이나 로그 수집 플랫폼에서도 같은 방식이 사용된다.

이러한 사례들을 보면 한 가지 흥미로운 사실을 발견하게 된다. Unix에서 설계된 단순한 I/O 모델이 현대 클라우드 인프라에서도 그대로 사용되고 있다는 점이다. stdout과 stderr의 분리는 단순한 콘솔 출력 기능이 아니라 시스템 로그 구조의 기본 단위가 되었다.

이것은 Unix 설계의 중요한 특징을 보여 준다. Unix는 처음부터 거대한 기능을 가진 시스템을 만들기보다는 단순하고 일반적인 모델을 선택했다. 파일 디스크립터라는 단순한 추상화 위에서 모든 입출력을 처리하도록 만들었고, 프로그램들은 그 위에서 자유롭게 연결될 수 있었다.

그 결과 Unix는 예상하지 못했던 새로운 환경에서도 자연스럽게 확장될 수 있었다. 컨테이너, 클라우드, 분산 시스템 같은 현대 기술에서도 Unix I/O 모델은 여전히 유효하다. 수십 년 전에 만들어진 작은 설계가 지금도 새로운 기술 위에서 살아 움직이고 있는 것이다.

작은 문장 안에 담긴 Unix 철학

이제 다시 처음의 질문으로 돌아가 보자. 우리가 흔히 사용하는 2>&1이라는 문장은 단순한 셸 트릭이 아니다. 그 문장은 Unix 설계 철학의 작은 단면을 보여 주는 예에 가깝다.

Unix 시스템은 처음부터 복잡한 인터페이스를 만들기보다는 매우 단순한 추상화를 선택했다. 프로그램은 파일 디스크립터를 통해 데이터를 읽고 쓴다. 출력은 stdout과 stderr라는 두 개의 스트림으로 나뉜다. 프로그램들은 파이프를 통해 서로 연결된다. 이러한 구조는 놀라울 정도로 단순하지만 동시에 매우 강력하다.

2>&1이라는 문장은 바로 이 구조 위에서 등장한다. stderr라는 별도의 출력 스트림이 존재하기 때문에 필요할 때 두 스트림을 다시 합칠 수 있는 방법도 필요하다. 셸은 이를 위해 파일 디스크립터를 직접 조작하는 문법을 제공한다. 결과적으로 우리는 간단한 명령 하나로 프로그램의 입출력 구조를 자유롭게 재구성할 수 있게 된다.

이 점에서 보면 셸은 단순한 명령 실행 도구가 아니다. 셸은 사실상 프로세스의 입출력 구조를 구성하는 언어라고 할 수 있다. 우리가 작성하는 리디렉션 문장은 프로그램이 실행되기 전에 파일 디스크립터 테이블을 수정하는 명령과 같다.

이러한 구조는 처음에는 조금 낯설게 느껴질 수 있다. 숫자로 파일 디스크립터를 다루는 방식은 직관적이지 않을 수도 있다. 하지만 이 단순한 모델 덕분에 Unix는 매우 유연한 시스템이 되었다. 프로그램들은 서로를 알지 못해도 연결될 수 있고, 사용자들은 작은 도구들을 조합해 자신만의 작업 흐름을 만들 수 있다.

수십 년을 살아남은 가장 작은 인터페이스

우리가 터미널에서 입력하는 2>&1이라는 문장은 길지 않다. 숫자와 기호 몇 개가 전부다. 하지만 그 짧은 문장 안에는 꽤 많은 이야기가 담겨 있다. 파일 디스크립터라는 개념, stdout과 stderr의 분리, 파이프라인을 중심으로 한 Unix 철학, 그리고 프로세스 입출력 모델까지 모두 이 문장과 연결되어 있다.

흥미로운 점은 이러한 설계가 만들어진 지 이미 반세기가 넘었다는 사실이다. Unix가 처음 등장했을 때는 개인용 컴퓨터도 흔하지 않았고, 인터넷 역시 지금과는 전혀 다른 모습이었다. 그럼에도 불구하고 당시 선택된 I/O 모델은 지금까지 거의 변하지 않은 채 유지되고 있다.

오늘날 우리는 컨테이너와 클라우드 환경에서 프로그램을 실행하고 로그를 수집하며 자동화된 시스템을 운영한다. 하지만 그 아래에는 여전히 stdout과 stderr라는 두 개의 스트림이 존재한다. Docker 로그도, Kubernetes 로그도 결국은 이 두 개의 출력 채널 위에서 동작한다.

이것은 Unix 설계의 가장 흥미로운 특징 중 하나다. Unix는 미래를 예측하려고 하지 않았다. 대신 단순하고 일반적인 모델을 만들었다. 그리고 그 모델이 충분히 단순했기 때문에 새로운 기술 환경에서도 자연스럽게 살아남을 수 있었다.

그래서 가끔 터미널에서 2>&1 같은 문장을 입력할 때면 이런 생각이 든다. 우리가 사용하는 이 작은 인터페이스는 단순한 셸 문법이 아니라 수십 년 동안 이어져 온 설계 철학의 흔적일지도 모른다는 생각 말이다.