2>&1이 이해 안 되는 이유 — 리눅스 I/O를 잘못 배운 신호

왜 2>&1은 항상 헷갈리는가 — 이해하지 못한 채 사용되는 문법의 시작점

2>&1은 대부분의 개발자가 사용해본 적이 있지만, 실제로 설명할 수 있는 경우는 드물다. 많은 경우 이 문법은 “에러를 출력으로 합친다”라는 형태로 기억된다. 하지만 이 설명은 결과만 전달할 뿐, 왜 그렇게 동작하는지는 전혀 설명하지 못한다. 그 결과 동일한 문법을 사용했음에도 상황에 따라 결과가 달라지는 순간, 이해는 즉시 무너진다. 이 글을 읽어야 하는 이유는 단순하다. 2>&1을 외우지 않고 이해하기 위해서다.

문제는 이 문법이 단순한 문자열이 아니라, 내부적으로는 리눅스의 I/O 구조를 직접 조작하는 표현이라는 점이다. 즉, 2>&1은 출력 결과를 바꾸는 명령이 아니라, 출력이 향하는 경로를 재구성하는 동작이다. 이 차이를 이해하지 못하면, 명령어의 실행 순서에 따라 결과가 달라지는 이유를 설명할 수 없다. 예를 들어 아래 두 명령은 표면적으로 매우 유사해 보이지만, 실제로는 완전히 다른 결과를 만든다.

command > file 2>&1
command 2>&1 > file

첫 번째 명령은 stdout이 먼저 파일로 이동한 뒤, stderr가 그 위치를 따라간다. 두 번째 명령은 stderr가 기존 stdout을 따라간 뒤, stdout만 파일로 이동한다. 이 차이는 단순한 문법의 문제가 아니라, “언제 무엇을 참조하느냐”의 문제다. 즉, 2>&1은 고정된 결과를 만드는 문법이 아니라, 실행 시점에 따라 달라지는 동적 구조다. 이 지점에서 대부분의 혼란이 발생한다.

이 문제를 해결하려면, 2>&1 자체를 설명하는 것이 아니라 그 아래에 있는 구조를 이해해야 한다. 단순히 “합친다”는 설명으로는 이 동작을 설명할 수 없다. 이 문법이 왜 이렇게 동작하는지를 이해하려면, 우리가 출력이라는 개념 자체를 잘못 이해하고 있다는 사실부터 짚어야 한다. 다음 단계는 바로 그 오해를 분해하는 것이다.

우리가 2>&1을 잘못 배우는 이유 — 개념이 아니라 패턴으로 학습했기 때문이다

대부분의 개발자는 리눅스 I/O를 처음 배울 때 개념이 아니라 사용법을 먼저 접한다. 즉, stdout과 stderr는 각각 무엇인지 대략적으로 설명을 듣고, 2>&1은 “이렇게 쓰면 된다”는 형태로 전달된다. 이 방식은 빠르게 결과를 얻는 데에는 도움이 되지만, 구조를 이해하는 데에는 전혀 도움이 되지 않는다. 결과적으로 2>&1은 하나의 문법 패턴으로 기억되고, 그 의미는 실제 동작과 분리된 채 남게 된다.

이러한 학습 방식의 문제는 예외 상황에서 바로 드러난다. 기본적인 사용에서는 문제가 없지만, 조금만 조건이 바뀌어도 결과를 예측할 수 없게 된다. 예를 들어 pipe와 함께 사용하거나, redirection 순서가 바뀌는 경우 대부분의 개발자는 결과를 직관적으로 설명하지 못한다. 이는 단순히 문법을 몰라서가 아니라, 그 문법이 어떤 구조 위에서 동작하는지를 이해하지 못했기 때문이다. 즉, 우리는 2>&1을 사용하는 방법은 알고 있지만, 왜 그렇게 동작하는지는 모르는 상태다.

이 문제는 단순한 학습 방식의 문제가 아니라, 개념을 분리해서 배우는 구조에서 발생한다. stdout, stderr, pipe, redirection은 각각 따로 설명되지만, 실제로는 하나의 시스템 안에서 동작한다. 하지만 학습 과정에서는 이 연결이 생략되기 때문에, 각각의 개념은 서로 독립적인 것으로 인식된다. 그 결과 2>&1처럼 여러 개념이 동시에 작동하는 경우에는 이해가 끊어진다. 즉, 문제의 본질은 특정 문법이 어려운 것이 아니라, 개념이 연결되지 않았다는 데 있다.

이제 이 연결을 복원해야 한다. 그러기 위해서는 먼저 출력이라는 개념 자체를 다시 정의할 필요가 있다. 우리가 출력이라고 생각하는 것이 실제로 무엇인지, 그리고 그것이 어떻게 동작하는지를 정확히 이해해야 한다. 다음 단계에서는 바로 이 지점을 다룬다.

문제의 본질 — 우리는 “출력”을 잘못 이해하고 있다

대부분의 개발자는 출력이 화면으로 간다고 생각한다. 즉, 프로그램이 실행되면 결과가 터미널에 표시되고, 그것이 출력의 전부라고 인식한다. 하지만 이 이해는 리눅스 I/O 구조를 설명하는 데에는 충분하지 않다. 출력은 특정 위치로 고정된 것이 아니라, 단지 데이터가 흘러가는 하나의 경로일 뿐이다. 즉, 출력은 “어디로 간다”가 아니라 “어디로든 갈 수 있다”는 구조를 가진다.

리눅스에서 출력은 stdout과 stderr라는 두 개의 스트림으로 나뉜다. 이 스트림은 특정 장치에 고정된 것이 아니라, 파일, 터미널, 파이프 등 다양한 대상으로 연결될 수 있다. 프로그램은 단지 이 스트림으로 데이터를 쓸 뿐이며, 그 데이터가 어디로 전달되는지는 별도의 구조에 의해 결정된다. 이 구조를 이해하지 못하면, 출력이 항상 동일한 방식으로 동작한다고 착각하게 된다. 그리고 바로 이 착각이 2>&1을 이해하지 못하는 원인이 된다.

이 지점에서 중요한 전환이 필요하다. 출력은 결과가 아니라 흐름이다. 즉, 프로그램은 결과를 “만드는 것”이 아니라, 데이터를 “흘려보내는 것”이다. 이 관점으로 보면 stdout과 stderr는 단순한 출력 채널이 아니라, 데이터가 지나가는 경로가 된다. 그리고 이 경로는 언제든지 변경될 수 있다. redirection은 이 경로를 바꾸는 것이고, pipe는 이 경로를 다른 프로그램으로 연결하는 것이다. 즉, 모든 것은 흐름 위에서 동작한다.

이제 출력이 무엇인지에 대한 정의가 바뀌었다. 더 이상 출력은 화면에 나타나는 결과가 아니라, 시스템 내부에서 이동하는 데이터 흐름이다. 이 관점이 잡히면, 다음 단계인 파일 디스크립터 구조를 이해할 수 있는 준비가 된다. 그리고 그 구조를 이해하는 순간, 2>&1은 더 이상 외워야 하는 문법이 아니라, 자연스럽게 설명 가능한 동작으로 바뀌게 된다.

리눅스 I/O 구조를 다시 세운다 — stdin, stdout, stderr의 관계

2>&1을 이해하려면 먼저 반드시 알아야 하는 전제가 있다. 그것은 stdout과 stderr가 단순한 “출력 종류”가 아니라, 시스템 내부에서 구분되는 독립적인 경로라는 점이다. 많은 경우 stdout은 일반 출력, stderr는 에러 출력이라고만 이해하지만, 이 설명은 기능적인 구분일 뿐 구조적인 설명은 아니다. 실제로는 두 출력은 서로 다른 파일 디스크립터를 통해 완전히 별도로 관리된다. 이 구조를 이해하지 못하면, 이후 등장하는 모든 redirection과 2>&1의 동작을 설명할 수 없다.

리눅스에서는 모든 입출력이 파일 디스크립터라는 숫자로 관리된다. stdin은 0번, stdout은 1번, stderr는 2번 파일 디스크립터를 가진다. 이 숫자는 단순한 식별자가 아니라, 각각이 독립적인 데이터 경로를 의미한다. 프로그램이 stdout으로 데이터를 출력한다는 것은, 내부적으로 1번 파일 디스크립터를 통해 데이터를 write하는 것이다. stderr도 동일하게 2번 파일 디스크립터를 통해 출력된다. 즉, 두 출력은 같은 방식으로 동작하지만, 서로 다른 경로를 통해 전달된다.

이 구조에서 중요한 것은, 이 파일 디스크립터가 특정 대상에 고정되어 있지 않다는 점이다. 기본적으로 stdout과 stderr는 터미널을 가리키지만, redirection을 통해 파일이나 다른 대상으로 변경될 수 있다. 즉, 출력은 항상 동일한 경로를 따르는 것이 아니라, 실행 시점에 연결된 대상에 따라 달라진다. 이 동작은 프로그램 내부 로직과는 무관하게, 외부에서 구성되는 구조다. 따라서 동일한 프로그램이라도 실행 방식에 따라 완전히 다른 출력 결과를 만들어낼 수 있다.

▶ 이 개념을 더 깊게 이해하려면: 리눅스 stdout stderr 리다이렉션 완전 정리 — 2>&1까지 쉽게 이해하기

이제 stdout과 stderr가 독립적인 경로라는 점이 명확해졌다. 다음 단계에서는 이 경로가 실제로 어떻게 변경되고 연결되는지를 이해해야 한다. 그 과정에서 redirection이 단순한 출력 변경이 아니라, 구조를 재구성하는 동작이라는 사실이 드러나게 된다.

핵심 전환 — 2>&1은 “합치는 것”이 아니라 “참조를 바꾸는 것”이다

2>&1을 단순히 “stderr를 stdout으로 합친다”라고 설명하면, 실제 동작을 이해할 수 없다. 이 표현은 결과를 설명할 뿐, 내부 구조를 설명하지 않기 때문이다. 정확한 의미는 stderr가 stdout과 같은 “값”을 가지는 것이 아니라, stdout이 가리키는 “대상”을 동일하게 참조하도록 만드는 것이다. 이 차이는 매우 중요하다. 값 복사와 참조 연결은 완전히 다른 동작을 의미하기 때문이다.

리눅스에서 파일 디스크립터는 특정 대상에 대한 참조를 가진다. stdout이 파일을 가리키고 있다면, 그 파일 디스크립터는 파일에 대한 참조를 유지한다. 2>&1은 stderr가 stdout이 가리키는 그 참조를 동일하게 가지도록 만든다. 즉, stderr가 stdout의 “현재 상태”를 따라가는 것이 아니라, stdout이 가리키는 “대상”을 공유하게 된다. 이 때문에 이후 stdout의 상태가 변경되더라도, 이미 연결된 stderr는 영향을 받지 않는다. 이 동작은 실행 시점의 상태에 따라 결정되며, 이후에는 독립적으로 유지된다.

이 구조를 이해하면 2>&1이 왜 순서에 민감한지 자연스럽게 설명할 수 있다. 파일 디스크립터는 실행 중에 순차적으로 설정되기 때문에, 어떤 시점에 어떤 참조를 가져가는지가 중요해진다. 즉, 2>&1은 고정된 변환이 아니라, 특정 시점의 상태를 기반으로 한 연결 작업이다. 이 연결은 이후 변경되지 않기 때문에, 실행 순서가 결과를 결정한다.

이제 2>&1의 핵심이 명확해졌다. 이것은 데이터를 합치는 것이 아니라, 경로를 공유하는 것이다. 다음 단계에서는 이 연결이 실제 명령어 실행 순서에 따라 어떻게 달라지는지를 구체적으로 살펴봐야 한다. 그 차이를 이해해야만, 동일한 문법이 다른 결과를 만드는 이유를 설명할 수 있다.

왜 순서에 따라 결과가 달라지는가 — 실행 시점의 문제

많은 개발자가 2>&1을 이해하지 못하는 결정적인 이유는, 실행 순서에 따른 차이를 설명하지 못하기 때문이다. 앞서 본 두 명령은 동일한 요소를 사용하지만, 실행 순서가 다르기 때문에 결과가 달라진다. 이 차이는 단순한 문법의 문제가 아니라, 파일 디스크립터가 언제 어떤 대상을 참조하느냐의 문제다. 리눅스 쉘은 명령어를 해석할 때, redirection과 파일 디스크립터 변경을 왼쪽에서 오른쪽 순서로 처리한다. 이 순서가 결과를 결정한다.

command > file 2>&1

이 경우 먼저 stdout이 파일로 리다이렉션된다. 즉, 파일 디스크립터 1번이 파일을 가리키게 된다. 이후 2>&1이 실행되면서 stderr는 stdout이 가리키는 파일을 참조하게 된다. 결과적으로 stdout과 stderr 모두 파일로 출력된다. 반면 아래 명령은 전혀 다른 흐름을 가진다.

command 2>&1 > file

이 경우 먼저 stderr가 stdout을 따라간다. 이 시점에서 stdout은 아직 터미널을 가리키고 있다. 따라서 stderr는 터미널을 참조하게 된다. 이후 stdout만 파일로 변경되기 때문에, stdout은 파일로, stderr는 터미널로 출력된다. 즉, 두 명령은 동일한 구성 요소를 사용하지만, 참조가 설정되는 시점이 다르기 때문에 결과가 달라진다.

이 구조를 이해하면 2>&1은 더 이상 예외적인 문법이 아니다. 단순히 파일 디스크립터가 설정되는 순서를 따라가는 결과일 뿐이다. 즉, 리눅스 I/O는 상태 기반 시스템이며, 각 단계의 상태가 다음 단계에 영향을 준다. 이 관점이 잡히면, pipe와 결합된 경우에도 동일한 원리로 동작을 예측할 수 있다. 다음 단계에서는 이 구조가 pipe와 결합될 때 어떻게 확장되는지를 살펴보게 된다.

pipe와 2>&1이 만나면 무엇이 달라지는가 — 데이터 흐름의 분리와 결합

2>&1을 이해했다고 해서 pipe까지 자동으로 이해되는 것은 아니다. 오히려 많은 경우 pipe와 결합되는 순간 다시 혼란이 시작된다. 그 이유는 pipe가 단순히 “출력을 다음 명령으로 넘긴다”는 수준으로 이해되기 때문이다. 실제로 pipe는 stdout만을 대상으로 동작한다. stderr는 기본적으로 pipe를 통과하지 않는다. 이 사실을 모르면 2>&1이 왜 pipe 앞에 위치해야 하는지 설명할 수 없다.

pipe는 두 프로세스 사이에 새로운 연결을 생성한다. 이 연결은 파일 디스크립터 수준에서 구현된다. 앞의 명령의 stdout이 뒤의 명령의 stdin으로 연결된다. 이때 stderr는 아무런 영향을 받지 않는다. 즉, pipe는 stdout 경로만 재구성하고, stderr는 기존 경로를 유지한다. 이 구조 때문에 에러 메시지는 여전히 터미널로 출력되고, 정상 출력만 다음 명령으로 전달된다.

command | grep something

이 명령에서 grep은 command의 stdout만 입력으로 받는다. stderr는 여전히 터미널로 출력된다. 따라서 에러 메시지는 grep을 거치지 않는다. 이 동작은 직관적이지 않을 수 있지만, 파일 디스크립터 관점에서는 매우 명확하다. pipe는 fd1만 연결하고, fd2는 그대로 둔다. 이 때문에 stderr를 pipe로 넘기고 싶다면 별도의 조작이 필요하다.

여기서 2>&1이 등장한다. stderr를 stdout과 동일한 대상으로 연결하면, pipe는 결과적으로 두 출력 모두를 전달받게 된다. 중요한 것은 순서다. command 2>&1 | grep something은 stderr를 먼저 stdout에 연결한 후, pipe가 stdout을 연결한다. 따라서 두 출력이 모두 grep으로 전달된다. 반면 command | grep something 2>&1은 전혀 다른 동작을 한다. 이 경우 2>&1은 grep 내부에서 처리되며, command의 stderr에는 영향을 주지 않는다.

이제 pipe와 2>&1의 관계는 단순한 조합이 아니라, 서로 다른 경로를 어떻게 결합할 것인가의 문제로 보이게 된다. 다음 단계에서는 이 구조를 실제 환경에서 어떻게 활용하는지 살펴보며, 단순한 문법이 아니라 설계 도구로서의 의미를 확인하게 된다.

실무에서 2>&1을 사용하는 이유 — 로그, 디버깅, 그리고 재현성

2>&1은 단순한 문법이 아니라, 실행 결과를 통제하기 위한 도구다. 실무에서는 출력의 내용보다 출력의 흐름이 더 중요해지는 경우가 많다. 특히 로그 수집, 장애 분석, 배치 처리에서는 stdout과 stderr를 분리할지, 결합할지가 결과 해석에 직접적인 영향을 준다. 이때 2>&1은 출력 경로를 명시적으로 제어하는 수단으로 사용된다.

대표적인 예는 로그 파일 생성이다. 프로그램을 실행할 때 stdout만 파일로 보내고 stderr를 터미널에 남기면, 로그가 불완전해진다. 반대로 stderr만 파일로 보내면 정상 흐름을 파악할 수 없다. 따라서 대부분의 경우 두 출력을 하나의 파일로 통합한다. 이때 사용되는 패턴이 > file 2>&1이다. 이 명령은 stdout을 파일로 보내고, stderr를 동일한 파일로 연결한다. 결과적으로 모든 출력이 하나의 로그로 기록된다.

command > app.log 2>&1

이 구조는 단순히 편의를 위한 것이 아니다. 재현성을 확보하기 위한 것이다. 동일한 입력에 대해 동일한 로그를 남기지 못하면, 문제를 재현할 수 없다. stderr가 별도로 출력되면, 로그만으로는 상황을 복원할 수 없다. 따라서 실무에서는 출력 경로를 통제하는 것이 필수적이다. 2>&1은 이 통제를 가능하게 하는 가장 기본적인 도구다.

또 다른 중요한 사용 사례는 디버깅이다. 특정 명령의 모든 출력을 다른 프로그램으로 넘겨 분석할 수 있다. 예를 들어 에러 메시지까지 포함하여 grep으로 필터링하려면, stderr를 stdout으로 합쳐야 한다. 이 경우 command 2>&1 | grep error와 같은 구조를 사용한다. 이 패턴은 단순히 문자열 검색이 아니라, 전체 실행 흐름을 분석 대상으로 만드는 것이다.

▶ 이 개념을 더 깊게 이해하려면: pipe(|)란 무엇인가 — 리눅스 파이프 개념 정리

이처럼 2>&1은 단순한 문법이 아니라, 출력 흐름을 설계하는 도구로 사용된다. 다음 단계에서는 이러한 설계가 왜 자주 오해되는지, 그리고 어떤 지점에서 잘못된 이해가 발생하는지를 분석하게 된다.

왜 대부분의 설명이 틀리는가 — “합친다”라는 잘못된 모델

2>&1을 이해하지 못하는 가장 큰 이유는, 대부분의 설명이 결과 중심으로 이루어져 있기 때문이다. “stderr를 stdout으로 합친다”는 설명은 직관적이지만, 구조를 설명하지 않는다. 이 표현은 출력이 하나로 보이는 결과만을 설명할 뿐, 내부에서 어떤 일이 일어나는지는 전혀 드러내지 않는다. 이 때문에 사용자는 순서에 따라 결과가 달라지는 이유를 이해하지 못한다.

문제의 핵심은 “합친다”라는 표현이 데이터 중심 사고를 유도한다는 점이다. 이 표현은 두 출력이 하나의 스트림으로 결합된다고 오해하게 만든다. 그러나 실제로는 데이터가 결합되는 것이 아니라, 경로가 재구성된다. stderr는 stdout이 가리키는 대상을 참조할 뿐이다. 이 차이를 이해하지 못하면, 동일한 명령이 다른 결과를 만드는 이유를 설명할 수 없다.

또한 많은 자료는 파일 디스크립터 개념을 생략한다. 이는 설명을 단순화하기 위한 선택이지만, 결과적으로는 구조를 이해할 수 없게 만든다. 파일 디스크립터를 이해하지 못하면, redirection은 단순한 “출력 변경”으로 보인다. 그러나 실제로는 “출력 경로 재설정”이다. 이 차이는 매우 중요하다. 경로를 이해해야만, pipe와의 결합, 실행 순서, 참조 구조를 모두 설명할 수 있다.

▶ 이 개념을 더 깊게 이해하려면: grep, sort, uniq를 파이프로 연결하는 이유 — 로그 분석의 기본 패턴

결국 2>&1을 이해하는 것은 하나의 문법을 이해하는 것이 아니라, 리눅스 I/O 전체를 구조적으로 이해하는 과정이다. 이 관점이 잡히면, 이후 등장하는 모든 redirection과 pipe는 동일한 원리로 해석된다. 다음 단계에서는 이러한 이해를 기반으로, 전체 흐름을 하나의 시스템으로 연결하는 단계로 넘어가게 된다.

리눅스 I/O를 구조로 이해하면 생기는 변화 — 예측 가능한 시스템으로 전환된다

2>&1을 이해했다면, 이제 중요한 변화가 하나 생긴다. 더 이상 명령어를 외우지 않아도 된다는 점이다. 대부분의 개발자는 redirection과 pipe를 “자주 쓰는 패턴”으로 기억한다. 그러나 이 방식은 상황이 조금만 바뀌면 바로 깨진다. 이유는 패턴이 아니라 구조를 이해하지 못했기 때문이다. 반대로 파일 디스크립터와 참조 구조를 이해하면, 새로운 상황에서도 결과를 예측할 수 있다.

이 변화의 핵심은 “출력이 어디로 가는가”를 항상 추적할 수 있게 된다는 점이다. stdout과 stderr는 각각 독립적인 경로를 가진다. 이 경로는 redirection을 통해 변경된다. 그리고 2>&1은 이 경로를 공유하게 만든다. pipe는 stdout 경로만 다음 프로세스로 연결한다. 이 세 가지 원리를 조합하면, 어떤 명령이든 결과를 계산할 수 있다. 이때 중요한 것은 결과를 기억하는 것이 아니라, 각 단계에서 파일 디스크립터가 무엇을 가리키는지를 추적하는 것이다.

예를 들어 복잡한 명령을 보더라도, 더 이상 “이게 될까”를 고민하지 않는다. 대신 “지금 stdout은 어디를 가리키는가”를 확인한다. 그리고 “stderr는 언제 stdout을 참조했는가”를 확인한다. 이 두 질문만으로 전체 흐름을 재구성할 수 있다. 이 접근 방식은 단순한 문법 이해를 넘어서, 시스템 동작을 해석하는 방식 자체를 바꾼다. 즉, 리눅스 I/O는 암기 대상이 아니라, 상태 기반 시스템으로 이해해야 하는 대상이다.

이 관점은 단순히 쉘 명령어에만 적용되지 않는다. 내부적으로는 모든 프로그램이 동일한 파일 디스크립터 모델 위에서 동작한다. 따라서 이 구조를 이해하면, 시스템 로그 처리, 프로세스 간 통신, 스트림 기반 처리까지 동일한 방식으로 해석할 수 있다. 다음 단계에서는 이 이해를 기반으로, 실제 시스템 설계에서 어떤 확장 개념으로 이어지는지를 살펴보게 된다.

확장 개념 — 파일 디스크립터는 단순한 출력이 아니라 시스템 인터페이스다

리눅스 I/O를 구조적으로 이해하면, 파일 디스크립터는 단순한 입출력 수단이 아니라는 점이 드러난다. 이것은 프로세스와 외부 세계를 연결하는 인터페이스다. stdout과 stderr는 그 중 일부일 뿐이다. 실제로 파일 디스크립터는 파일뿐 아니라, 소켓, 파이프, 디바이스 등 다양한 대상과 연결될 수 있다. 즉, 동일한 메커니즘으로 완전히 다른 시스템 요소를 다룰 수 있다.

이 구조의 핵심은 “모든 것이 파일처럼 다뤄진다”는 리눅스의 설계 철학이다. 프로그램은 대상이 무엇인지 알 필요가 없다. 단지 파일 디스크립터에 write를 수행하면 된다. 그 대상이 파일이든, 네트워크 소켓이든, 다른 프로세스이든 상관없다. 이 추상화 덕분에 pipe와 redirection이 자연스럽게 동작한다. 그리고 2>&1 역시 이 동일한 추상화 위에서 구현된다. 즉, 특정 기능이 아니라, 시스템 전체 설계의 일부다.

이 관점에서 보면 2>&1은 단순한 문법이 아니다. 이것은 인터페이스 연결을 재구성하는 연산이다. stderr가 stdout의 대상을 공유한다는 것은, 두 인터페이스가 동일한 대상과 연결된다는 의미다. 이 연결은 데이터 흐름을 통제하는 방식으로 확장된다. 예를 들어 로그를 파일이 아니라 네트워크로 보내거나, 다른 프로세스로 전달하는 것도 동일한 방식으로 구현할 수 있다. 결국 파일 디스크립터는 시스템 구성 요소를 연결하는 기본 단위다.