파이프 (소프트웨어)

소프트웨어 공학에서 **파이프라인**은 각 요소의 출력이 다음 요소의 입력이 되도록 배열된 처리 요소(프로세스, 스레드, 코루틴, 함수 등)의 체인으로 구성된다. 이 개념은 물리적인 파이프라인과 유사하다. 일반적으로 연속적인 요소들 사이에 어느 정도의 버퍼링이 제공된다. 이러한 파이프라인에서 흐르는 정보는 종종 스트림 형태의 레코드, 바이트 또는 비트이며, 파이프라인의 요소는 필터라고 불릴 수 있다. 이것은 또한 디자인 패턴인 **파이프 및 필터**라고도 불리는데, 이는 모놀리식이다. 이 방식의 장점은 단순성과 저비용이며, 단점은 유연성, 내결함성 및 확장성이 부족하다는 점이다.isbn=978-1492043454 요소를 파이프라인으로 연결하는 것은 함수 합성과 유사하다. 좁은 의미에서 파이프라인은 선형적이고 단방향이지만, 때로는 더 일반적인 흐름에도 이 용어가 적용된다. 예를 들어, 주로 단방향 파이프라인은 되돌림 채널 또는 백채널이라고 알려진 다른 방향으로의 통신을 가질 수 있으며, 어휘 분석기 핵에서처럼 파이프라인은 완전히 양방향일 수도 있다. 단방향 트리와 유향 비순환 그래프 토폴로지를 가진 흐름은 선형 파이프라인과 유사하게 동작한다. 이러한 흐름에서 순환이 없으면 단순해지므로 느슨하게 "파이프라인"이라고 불릴 수 있다.
# 구현
파이프라인은 종종 다중작업 OS에서 모든 요소를 프로세스로 동시에 실행하고, 각 프로세스의 데이터 읽기 요청을 업스트림 프로세스가 작성한 데이터로 자동 처리하는 방식으로 구현된다. 이를 다중 프로세스 파이프라인이라고 부를 수 있다. 이런 식으로 스케줄러는 CPU 유휴 시간을 최소화하기 위해 프로세스 간에 CPU를 자연스럽게 전환할 것이다. 다른 일반적인 모델에서는 요소를 경량 스레드 또는 코루틴으로 구현하여 프로세스와 관련된 OS 오버헤드를 줄인다. OS에 따라 스레드는 OS 또는 스레드 관리자에 의해 직접 스케줄링될 수 있다. 코루틴은 항상 어떤 형태의 코루틴 관리자에 의해 스케줄링된다. 읽기 및 쓰기 요청은 일반적으로 블로킹 작업이다. 이는 소스 프로세스의 실행이 쓰기 시에 모든 데이터를 대상 프로세스에 쓸 수 있을 때까지 일시 중단됨을 의미한다. 마찬가지로 대상 프로세스의 실행은 읽기 시에 요청된 데이터 중 일부라도 소스 프로세스에서 얻을 수 있을 때까지 일시 중단된다. 이로 인해 교착 상태가 발생할 수 없는데, 양쪽 프로세스가 서로 응답하기를 무한정 기다리는 상황은 적어도 하나의 프로세스가 곧 운영 체제에 의해 요청이 처리되어 실행을 계속할 것이기 때문이다. 성능을 위해 파이프를 구현하는 대부분의 운영체제는 파이프 버퍼를 사용하며, 이를 통해 소스 프로세스가 대상 프로세스가 현재 받으려는 또는 받을 수 있는 것보다 더 많은 데이터를 제공할 수 있다. 대부분의 유닉스 및 유닉스 계열 운영체제에서는 "buffer"라는 특수 명령이 제공되는데, 이는 잠재적으로 훨씬 크고 구성 가능한 파이프 버퍼를 구현한다. 이 명령은 대상 프로세스가 소스 프로세스보다 훨씬 느리지만, 소스 프로세스가 가능한 한 빨리 작업을 완료하기를 원할 때 유용할 수 있다. 예를 들어, 소스 프로세스가 CD에서 오디오 트랙을 읽는 명령으로 구성되고 대상 프로세스가 파형 오디오 데이터를 MP3와 같은 형식으로 압축하는 명령으로 구성되는 경우이다. 이 경우 전체 트랙을 파이프 버퍼에 버퍼링하면 CD 드라이브가 더 빨리 스핀다운되고, 인코딩 프로세스가 완료되기 전에 사용자가 CD를 드라이브에서 제거할 수 있게 된다. 이러한 버퍼 명령은 데이터 읽기 및 쓰기를 위한 시스템 호출을 사용하여 구현할 수 있다. 낭비적인 바쁜 대기는 poll 또는 select 또는 멀티스레딩과 같은 기능을 사용하여 피할 수 있다. 파이프라인 소프트웨어 시스템의 주목할 만한 예시로는 다음이 있다: * RaftLib – C/C++ Apache 2.0 라이선스
# VM/CMS 및 z/OS
CMS 파이프라인은 파이프라인 아이디어를 VM/CMS 및 z/OS 시스템으로 포팅한 것이다. 이 시스템은 유닉스 셸보다 훨씬 복잡한 파이프라인 구조를 지원하며, 단계가 여러 입력 스트림을 받아 여러 출력 스트림을 생성할 수 있다. (이러한 기능은 유닉스 커널에서 지원되지만, 복잡한 구문과 블로킹 모드를 유발하여 이를 사용하는 프로그램은 거의 없지만, 일부 셸은 임의의 파일 서술자 할당을 통해 이를 지원한다.) IBM 메인프레임 운영 체제의 기존 애플리케이션 프로그램에는 리디렉션이나 파이핑을 허용하는 표준 입출력 스트림이 없다. 외부 프로그램으로 프로세스를 생성하는 대신 CMS 파이프라인은 200개 이상의 내장 프로그램을 동시에 실행하는 경량 디스패처를 특징으로 하며, 이 프로그램들은 일반적인 UNIX 유틸리티를 구현하고 장치 및 운영 체제 서비스와 인터페이스한다. 내장 프로그램 외에도 CMS 파이프라인은 파이프라인에서 사용할 수 있는 입력 및 출력 스트림을 가진 사용자 작성 REXX 프로그램을 허용하는 프레임워크를 정의한다. IBM 메인프레임의 데이터는 일반적으로 레코드 지향 파일 시스템에 존재하며 연결된 I/O 장치는 스트림 모드 대신 레코드 모드로 작동한다. 결과적으로 CMS 파이프라인의 데이터는 레코드 모드로 처리된다. 텍스트 파일의 경우 레코드는 한 줄의 텍스트를 담는다. 일반적으로 CMS 파이프라인은 데이터를 버퍼링하지 않고 잠금 단계 방식으로 한 프로그램에서 다음 프로그램으로 데이터 레코드를 전달한다. 이는 상호 연결된 파이프라인 네트워크를 통한 데이터의 확정적 흐름을 보장한다.
# 객체 파이프라인
바이트 스트림 기반 파이프라인 외에도 객체 파이프라인도 존재한다. 객체 파이프라인에서 처리 요소는 텍스트 대신 객체를 출력한다. 파워셸은 파워셸 런타임 내에서 함수 간에 .NET 객체를 전송하는 내부 객체 파이프라인을 포함한다. 림보 프로그래밍 언어에 있는 채널은 이러한 은유의 또 다른 예시이다.
# GUI의 파이프라인
RISC OS 및 ROX 데스크톱과 같은 그래픽 환경도 파이프라인을 사용한다. 사용자에게 프로그램이 데이터를 어디에 쓸지 지정하도록 파일 관리자를 포함하는 저장 대화 상자를 제공하는 대신, RISC OS 및 ROX는 아이콘 (및 이름을 지정하는 필드)을 포함하는 저장 대화 상자를 제공한다. 대상은 아이콘을 드래그 앤 드롭하여 지정된다. 사용자는 아이콘을 이미 저장된 파일이 놓일 수 있는 모든 곳, 즉 다른 프로그램의 아이콘 위에도 놓을 수 있다. 아이콘이 프로그램의 아이콘 위에 놓이면 프로그램이 로드되고, 그렇지 않으면 저장되었을 내용은 새 프로그램의 표준 입력 스트림으로 전달된다. 예를 들어, 월드 와이드 웹을 탐색하는 사용자는 압축된 .gz 이미지를 발견하여 편집하고 다시 업로드하고 싶을 수 있다. GUI 파이프라인을 사용하면 해당 링크를 압축 해제 프로그램으로 드래그하고, 추출된 콘텐츠를 나타내는 아이콘을 이미지 편집기로 드래그한 다음 편집하고, 다른 이름으로 저장 대화 상자를 열어 아이콘을 업로드 소프트웨어로 드래그할 수 있다. 개념적으로 이 방법은 기존 저장 대화 상자와 함께 사용될 수 있지만, 사용자 프로그램이 파일 시스템에서 명확하고 쉽게 접근할 수 있는 위치를 가져야 한다. 그러나 종종 그렇지 않으므로 GUI 파이프라인은 드물다.
# 기타 고려사항
"파이프라인"이라는 이름은 물리적인 배관과의 대략적인 비유에서 비롯되었다. 파이프라인은 일반적으로예외가 있는데, "손상된 파이프" 신호와 같은 경우이다. 물이 파이프에서 흐르듯이 정보가 한 방향으로만 흐르도록 허용한다. 파이프와 필터는 바이트 스트림을 데이터 객체로 사용하는 함수형 프로그래밍의 한 형태로 볼 수 있다. 더 구체적으로, 모나드의 특정 형태로 볼 수 있다."Monadic I/O and UNIX shell programming" date=2020-11-09. 파이프라인 개념은 코쿤 웹 개발 프레임워크나 XProc (W3C 표준) 구현에서도 핵심적인 역할을 하며, 이를 통해 소스 스트림을 최종 표시 전에 수정할 수 있다. 이 패턴은 텍스트 스트림을 프로그램의 입력 및 출력으로 사용하는 것을 장려한다. 이러한 텍스트 의존성은 텍스트 프로그램에 대한 그래픽 셸을 만들 때 고려되어야 한다.