프로세스 A가 생성한 데이터를 프로세스 B가 곧바로 읽어야 할 때, B가 A의 메모리를 직접 들여다보면 어떨까요? 직관적으로는 효율적일 것 같지만, 운영체제는 이를 철저히 통제합니다.

각 프로세스는 자신만의 독립적인 주소 공간을 갖습니다. 다른 프로세스의 메모리를 함부로 읽고 쓰도록 내버려 두면, 시스템의 보안과 안정성 모두가 무너지고 맙니다. 이것이 바로 오늘 다룰 핵심입니다. 프로세스들은 서로 직접 소통하는 대신, 커널이 안전하게 마련해 둔 통로를 통해 만납니다. 커널이 중간에서 우체국이나 창고, 도로, 그리고 신호등 같은 중재자 역할을 하는 셈이죠.

물론 파일 락(file lock)을 활용해 임시 파일로 프로세스를 동기화할 수도 있습니다. 하지만 디스크를 거치는 파일시스템 접근은 비용이 매우 큽니다. 그래서 커널은 디스크 접근을 우회하거나, 겉으로만 파일처럼 보일 뿐 실제로는 메모리 기반의 빠른 내부 구조를 사용하는 전용 IPC 메커니즘을 다양하게 제공하는 것입니다.

파이프는 유닉스 계열에서 가장 고전적이면서도 여전히 강력한 프로세스 통신 방식입니다. 원리는 명쾌합니다. 한 프로세스가 파이프에 밀어 넣은 데이터를 커널이 맡아두었다가, 다른 프로세스가 꺼내어 읽을 수 있게 해주는 것입니다. 흐름은 철저히 한 방향(단방향)으로만 흐릅니다.

우리가 셸에서 ls | more를 실행할 때, 셸은 내부적으로 두 개의 자식 프로세스를 생성합니다. 이때 ls의 표준 출력은 모니터 화면이 아닌 파이프의 입구로 연결되고, more의 표준 입력은 키보드가 아닌 파이프의 출구로 연결됩니다. 사용자는 무심코 | 기호 하나를 입력했을 뿐이지만, 무대 뒤에서는 파일 디스크립터 복제, 프로세스 생성, 입출력 방향 재지정이라는 일련의 작업이 순식간에 일어납니다.

물론 ls > temp 이후에 more < temp를 실행해 임시 파일로 같은 결과를 낼 수도 있습니다. 그러나 파이프를 사용하면 명령어가 훨씬 직관적이고 간결해지며, 디스크 I/O를 발생시키지 않아 속도도 훨씬 빠릅니다. 이처럼 파이프는 생산자-소비자 패턴에 완벽하게 부합합니다.

다만 제약도 있습니다. 일반적인 익명 파이프(Anonymous Pipe)는 pipe()를 호출한 부모 프로세스와 이를 상속받은 자식 프로세스처럼, 핏줄이 이어진 관계에서만 사용할 수 있습니다. 이 한계를 극복하기 위해 등장한 것이 바로 FIFO입니다.

파이프를 생성하려면 프로세스가 pipe() 시스템 콜을 호출해야 합니다. 이 함수는 성공 시 크기가 2인 배열에 두 개의 파일 디스크립터를 담아 돌려주는데, 하나는 파이프의 출구(읽기 끝), 다른 하나는 입구(쓰기 끝) 역할을 합니다.

POSIX 표준에 따르면 파이프는 기본적으로 단방향(half-duplex)입니다. 양방향으로 대화하려면 파이프 두 개를 엮어야 합니다. 만약 매번 pipe(), fork(), dup2() 등을 직접 호출하는 것이 번거롭다면, C 라이브러리에서 제공하는 popen()과 pclose()를 활용하면 됩니다. 이 함수들은 내부적으로 복잡한 연결 과정을 대신 처리하고 다루기 쉬운 FILE * 포인터를 던져줍니다.

사용자 프로세스 입장에서 파이프는 그저 파일 디스크립터로 접근하는 대상일 뿐입니다. 그렇다면 커널은 이 환상을 유지하기 위해 보이지 않는 곳에서 무엇을 만들어낼까요? 정답은 **하나의 inode 객체와 두 개의 file 객체(읽기용, 쓰기용)**를 생성하는 것입니다.

여러 프로세스가 파이프에 동시에 달려들면 데이터가 꼬일 수 있으므로, 커널은 inode 구조체 내부에 있는 i_sem 세마포어로 파이프 데이터를 단단히 보호합니다. 나아가, 커널은 pipefs라는 특수한 파일시스템을 띄워 파이프를 VFS(가상 파일 시스템) 계층과 자연스럽게 엮어냅니다. 일반 사용자의 눈에는 보이지 않는 투명한 파일시스템이지만, 이 덕분에 파이프는 여느 파일과 똑같은 커널 인터페이스의 혜택을 누릴 수 있습니다.

응용 프로그램에서 pipe() 시스템 콜을 부르면, 커널 공간에서는 sys_pipe()가 응답하며 실질적인 뼈대 구축은 do_pipe() 함수가 전담합니다.

그렇다면 이렇게 만들어진 파이프는 언제 사라질까요? 프로세스가 사용을 마치고 파일 디스크립터를 닫으면 fput()이 호출되며 참조 카운트가 하나씩 줄어듭니다. 이 카운트가 완전히 0으로 떨어져야 pipe_release()가 실행됩니다. 읽기용과 쓰기용 채널 양쪽이 모두 완전히 닫혀야만, 커널은 그제야 버퍼가 쥐고 있던 물리적 페이지 프레임들을 시스템에 반환합니다. 만약 한쪽이라도 아직 열려있다면 대기 큐에서 잠자고 있는 상대편 프로세스를 깨워 파이프의 상태 변화를 알리게 됩니다.

프로세스가 파이프의 읽기 쪽 디스크립터에 대고 read()를 호출하면 커널은 pipe_read() 함수로 응답합니다. 사용자가 요청한 바이트 수를 n, 현재 버퍼 안에 읽지 않고 남아있는 유효한 바이트 수를 p라고 할 때, 파이프의 동작은 당시의 미묘한 상황에 따라 완전히 달라집니다.

pipe_read()의 세밀한 처리 과정은 다음과 같습니다: i_sem 세마포어를 잡아 동시성 문제를 막고 → nrbufs로 데이터 유무를 파악합니다 → 데이터가 0이면 기다릴지 말지 결정하고 → 데이터가 있다면 curbuf 위치의 페이지를 매핑(map)하여 → 데이터를 유저 공간으로 밀어 넣은 뒤 → 매핑을 해제(unmap)합니다 → 읽은 만큼 offset과 len을 조절하고 → 만약 버퍼 하나가 완전히 비워지면 curbuf를 다음 칸으로 넘기고 nrbufs를 1 줄입니다 → 마지막으로 세마포어를 풀며 공간이 생기길 기다리던 쓰기 프로세스를 깨워줍니다.

프로세스가 파이프의 쓰기 쪽에 대고 데이터를 밀어 넣으려 할 때 호출되는 함수가 바로 pipe_write()입니다. 이때 커널은 크게 세 가지 중요한 이슈를 점검합니다. **읽어줄 프로세스가 살아있는가, 버퍼에 남은 공간은 충분한가, 그리고 쓰기 작업의 원자성(Atomicity)을 보장할 수 있는가**입니다.

FIFO는 흔히 named pipe라는 이름표를 달고 불립니다. 일반적인 익명 파이프가 지닌 가장 치명적인 약점은 "가계도가 이어지지 않은 완전히 남남인 프로세스들끼리는 이미 만들어진 파이프의 존재조차 알 길이 없다"는 점이었습니다. FIFO는 파일시스템의 디렉터리 트리에 명시적인 '이름'으로 당당히 존재하기 때문에 이 딜레마를 깔끔하게 해결해 냅니다.

실제 백엔드 시스템을 떠올려봅시다. 데이터베이스 서버가 늘 백그라운드에서 깨어 있습니다. 서버는 기동할 때 특정 디렉터리(예: /tmp/db_req)에 FIFO 파일을 하나 만들어 둡니다. 나중에 언제든 클라이언트 프로그램이 실행되면, 그저 약속된 경로의 FIFO를 파일 열듯 열어서 요청을 들이밀면 됩니다. 이처럼 FIFO의 명시적 이름은 서로 일면식도 없는 프로세스들이 안전하게 조우할 수 있는 굳건한 약속 장소가 되어줍니다.

오해하기 쉬운 점이 있습니다. 파일시스템에 버젓이 존재한다고 해서 FIFO에 쓰인 데이터가 덜컥 하드 디스크에 쓰이는 것은 결코 아닙니다. 데이터는 디스크를 스쳐 지나지 않고 오로지 열려 있는 커널 메모리 버퍼를 통해서만 쏜살같이 오고 갑니다. 리눅스 2.6 커널 구조를 뜯어보면 FIFO와 파이프는 뿌리가 같습니다. 둘 다 동일한 pipe_inode_info 구조체를 다루며, 읽기와 쓰기를 담당하는 핵심 엔진 역시 똑같이 pipe_read()와 pipe_write()를 공유합니다.

원하는 곳에 FIFO를 심으려면 프로세스에서 mknod() 시스템 콜이나 POSIX가 챙겨주는 mkfifo() 래퍼 함수를 부르면 됩니다. 뼈대가 세워진 FIFO는 이제 여느 파일과 다름없이 open(), read(), write(), close()의 친숙한 패턴으로 가지고 놀 수 있습니다.

사용자가 FIFO에 대고 open()을 찌르면 VFS는 지체 없이 fifo_open() 커널 함수를 호출합니다. 이 함수는 동시성 제어용 i_sem을 꽉 쥔 채, 아직 i_pipe 구조체가 없다면 새로 뚝딱 만들어 붙입니다. 그런 뒤 호출자가 요청한 접근 모드(읽기 전용, 쓰기 전용 등)에 맞춰 파일 연산(f_op) 테이블의 기어를 철컥 변속해 줍니다.

fifo_open()은 열리는 모드에 발맞춰 readers, writers 카운트를 성실하게 올려줍니다. 새로운 독자가 등장하면 기다리다 지친 작가를 흔들어 깨우고, 반대로 새로운 작가가 등장하면 목빠지게 기다리던 독자를 일깨웁니다. 요컨대 FIFO는 단순히 데이터를 나르는 파이프를 넘어, 열리는(open) 그 순간부터 이미 두 프로세스의 만남을 조율하는 정교한 동기화 무대인 셈입니다.

이제 파이프와 FIFO의 세계를 지나, 더욱 다채로운 기능을 자랑하는 System V IPC로 넘어가 보겠습니다. 세마포어, 메시지 큐, 공유 메모리라는 각기 다른 개성의 도구들이 하나의 거대한 철학 아래 가족으로 묶여 있습니다.

커널은 식별자 번호가 너무 뻔하게 돌려막기 되는 것을 몹시 꺼립니다. 리눅스 2.6에서는 대략 identifier = s × M + i라는 교묘한 공식을 씁니다. s는 빙글빙글 도는 시퀀스, M은 한계치(IPCMNI = 32768), i는 실제 배열 슬롯의 인덱스입니다. 커널 심층부에는 세마포어, 큐, 공유메모리 삼형제를 통제하기 위한 ipc_ids 통제소가 각각 존재하며, 개별 자원들은 소유자와 권한 마스크를 품은 kern_ipc_perm이라는 방패를 반드시 두르고 있습니다.

IPC 세마포어는 메시지나 파일처럼 데이터를 싣고 나르는 용도가 아닙니다. 여러 프로세스가 탐내는 공유 자원 앞을 지키며, 누가 언제 들어갈지 깐깐하게 조율하는 스마트 신호등입니다. 내부 카운터가 양수이면 쾌속 통과, 0이 되면 멈춰 서서 기다려야 한다는 아주 원초적인 규칙을 따릅니다.

하지만 IPC 세마포어는 커널 내부에서 쓰이는 일반 세마포어보다 구조가 훨씬 복잡합니다. 단순한 정수 카운터 하나 달랑 있는 게 아니라, 여러 개의 원시 세마포어(primitive semaphore)들이 옹기종기 모여 거대한 배열 세트를 이룹니다. 덕분에 식별자 하나만 까서 여러 개의 복잡한 공유 자원을 한방에 동시에 걸어 잠글 수 있는 막강한 파워를 뽐냅니다.

메시지 큐는 이름 그대로 프로세스들이 덩어리진 메시지 단위로 데이터를 주고받을 수 있게 해주는 훌륭한 비동기 통신 장치입니다. 한 녀석이 메시지를 정성껏 포장해 큐에 던져두고 떠나면, 받을 녀석은 한가할 때 스윽 와서 꺼내 갑니다. 당연하게도, 누군가 꺼내 간 편지는 커널의 우편함에서 깔끔하게 파쇄되어 사라집니다.

여기서 메시지는 고정된 규격의 헤더와 자유로운 길이의 본문 텍스트로 구성되는데, 가장 짜릿한 기능은 바로 메시지 타입(message type)이라는 정수형 라벨표입니다. 받는 프로세스는 우체통을 통째로 엎는 대신, 자신이 관심 있는 타입 번호만 콕 짚어서 선택적으로 낚아챌 수 있습니다.

커널은 메모리 관리의 달인답게, 메시지를 메모리 페이지 하나(약 4KB)에 꽉꽉 눌러 담으려 애씁니다. 헤더(msg_msg) 공간을 살짝 떼어내고 나면 대략 4072바이트의 본문을 첫 페이지에 채울 수 있죠. 만약 그보다 말이 많은 장문의 메시지라면, msg_msgseg라는 이음새를 달아 다음 페이지로 줄줄이 엮어냅니다. 시스템의 기본 제약(메시지 최대 크기 8192, 큐 최대 크기 16384)이 갑갑하다면, 관리자 권한으로 /proc/sys/kernel/msgmax 등을 수정해 우체통을 확장할 수 있습니다.

공유 메모리 방식을 사용하면, 여러 프로세스가 동일한 물리적 page frame들을 각자의 가상 주소 공간에 매핑하여 직접 접근할 수 있습니다. 데이터를 커널 버퍼로 복사해 넣고 다시 빼내는 지루한 과정(Context Switch 및 Memory Copy)이 통째로 생략되므로, 전달할 데이터 덩치가 클수록 속도 이득은 상상을 초월합니다.

이 거대한 공유 덩어리는 시스템 메모리가 쪼들릴 때 어떻게 될까요? 공유 메모리 페이지는 디스크의 일반 파일과 엮여있지 않아 툭 버릴 수 없고(비동기화), IPC의 철칙에 따라 시스템 재부팅 전까지는 무조건 보존(persistent)되어야 합니다. 그래서 메모리 압박이 심해지면, 커널은 shmem_writepage()를 부랴부랴 가동하여 페이지를 잠시 스왑 공간(Swap Area)으로 대피시킵니다. 훗날 누군가 다시 접근하면 스왑-인(Swap-in) 마법을 통해 페이지가 생생하게 복원되는 놀라운 구조를 갖추고 있습니다.

POSIX 메시지 큐는 앞서 배운 System V IPC 메시지 큐와 철학은 결을 같이 하지만, 현대적인 시스템에 걸맞은 몇 가지 치명적인 장점으로 무장하고 있습니다. 우선순위(priority) 정렬 지원, 메시지 도착 시 비동기 알림(asynchronous notification), 대기 시간 설정(timeout), 그리고 파일 디스크립터에 찰떡같이 녹아든 직관적인 인터페이스가 그 핵심입니다.

리눅스 2.6 커널은 POSIX 메시지 큐를 구현하기 위해 mqueue라는 앙증맞은 특수 파일시스템을 돌립니다. 큐가 하나 생길 때마다 inode도 하나씩 알을 깨고 나옵니다. 큐의 심장부인 mqueue_inode_info 구조체에는 밀린 메시지들의 연결 리스트, 우선순위별로 줄 세우는 정렬 로직, mq_notify()를 위한 예약 정보 등이 야무지게 담겨 있습니다. 개별 메시지의 데이터 구조 자체는 System V 시절의 msg_msg를 그대로 재활용하여 커널의 코드 중복을 피했습니다.