모든 개발자가 알아야 할 리눅스 시스템 API

1969년, Ken Thompson과 Dennis Ritchie는 Bell Labs의 사무실에 앉아 그 시대의 다른 기술 대부분보다 오래 살아남을 설계 결정들을 내렸습니다. Unix를 작성할 때 쓴 PDP-7은 이제 박물관 전시품이 되었고, 처음 사용했던 언어들도 사라졌습니다. 하지만 그들이 설계한 시스템 콜 인터페이스 — open, read, write, close, fork, exec — 는 오늘날 운영 중인 모든 리눅스 서버, 모든 안드로이드 폰, 그리고 모든 컨테이너의 기반으로 여전히 쓰이고 있습니다.

대부분의 개발자는 이런 API를 두꺼운 추상화 계층을 거쳐 사용합니다. Python의 open(), Node의 fs.readFile(), Go의 os.Open() 모두 결국 밑단에서는 같은 커널 시스템 콜을 호출합니다. 시스템 콜을 이해하는 것은 단순히 지적 호기심을 채우는 일이 아닙니다. 디버깅, 성능 튜닝, 그리고 압박 속에서도 실제로 잘 동작하는 시스템을 설계하는 능력을 눈에 띄게 높여 줍니다.

파일 디스크립터: 모든 것은 숫자다

Unix에서 가장 중요한 추상화는 파일 디스크립터입니다. 이것은 열린 리소스를 가리키는 작은 음이 아닌 정수에 불과합니다. 다만 여기서 “리소스”라는 표현은 일부러 모호하게 둔 것입니다. 파일 디스크립터는 디스크의 파일, 네트워크 소켓, 프로세스 간 파이프, 터미널, 타이머, 심지어 시그널 메커니즘까지 가리킬 수 있습니다. 커널은 신경 쓰지 않습니다. 프로그램 입장에서는 모두 read()로 읽고 write()로 쓸 수 있는 숫자일 뿐입니다.

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
int main() {
// fd 0 = stdin, 1 = stdout, 2 = stderr (always)
// open() returns the next available fd, typically 3
int fd = open("data.txt", O_RDONLY);
if (fd == -1) {
perror("open");
return 1;
}
char buf[1024];
ssize_t n;
// read() works the same whether fd is a file,
// a socket, a pipe, or a device
while ((n = read(fd, buf, sizeof(buf))) > 0) {
write(STDOUT_FILENO, buf, n);
}
close(fd);
return 0;
}

이 설계 덕분에 Unix는 조합이 가능합니다. 모든 것이 같은 인터페이스를 공유하기 때문에, 파일의 출력을 소켓으로 돌리거나, 한 프로그램의 stdout을 다른 프로그램의 stdin으로 연결하거나, 프로세스의 stderr을 로그 파일로 바꿀 수 있습니다. 프로그램 자체는 이런 사실을 알 필요도 없고 신경 쓸 필요도 없습니다. 셸 파이프라인이 동작하는 이유이고, Docker 같은 도구가 컨테이너 출력을 손쉽게 가져갈 수 있는 이유이기도 합니다.

운영 환경에서 “too many open files” 오류를 만났다면 파일 디스크립터 한도에 걸린 것입니다. 소켓 누수를 디버깅하고 있다면, 열렸지만 닫히지 않은 파일 디스크립터를 찾고 있는 것입니다. lsof로 프로세스가 무엇을 하는지 볼 때도 사실 파일 디스크립터 목록을 보고 있는 셈입니다. 이 추상화를 이해하면 한 부류의 운영 문제가 갑자기 명확하게 보이기 시작합니다.

Fork와 Exec: 프로세스는 어떻게 태어나는가

Unix가 새 프로세스를 만드는 방식은 처음 보는 사람에게는 꽤 낯설게 느껴집니다. “이 프로그램으로 프로세스를 만들어라”라는 단일 호출 대신, Unix는 이를 두 단계로 나눕니다. fork()가 현재 프로세스를 복제하고, exec()가 복제본의 프로그램을 다른 프로그램으로 바꿉니다. 돌아가는 방식처럼 보이지만, 이 분리가 바로 Unix 프로세스 모델 전체를 가능하게 합니다.

#include <unistd.h>
#include <sys/wait.h>
#include <stdio.h>
#include <fcntl.h>
int main() {
pid_t pid = fork();
if (pid == 0) {
// Child process: redirect stdout to a file
// This happens BETWEEN fork and exec —
// that's the whole point of the split
int fd = open("output.log", O_WRONLY | O_CREAT | O_TRUNC, 0644);
dup2(fd, STDOUT_FILENO);  // stdout now goes to the file
close(fd);
// Replace this process with 'ls'
execlp("ls", "ls", "-la", NULL);
// If we get here, exec failed
perror("exec");
return 1;
}
// Parent: wait for child to finish
int status;
waitpid(pid, &status, 0);
printf("Child exited with status %d\n",
WEXITSTATUS(status));
return 0;
}

fork()와 exec() 사이의 틈에서 마법이 일어납니다. 이 짧은 구간에서 자식 프로세스는 파일 디스크립터를 리다이렉트하고, 환경 변수를 바꾸고, 리소스 제한을 설정하고, 권한을 낮추고, 다른 네임스페이스에 합류할 수 있습니다. 새 프로그램이 실행되기 전에 말이죠. 셸이 ls > output.txt를 구현하는 방식이 바로 이것이고, 컨테이너가 격리를 구성하는 방식도, sudo가 권한을 내려놓는 방식도 같습니다.

최신 리눅스에는 clone()(부모와 자식 사이에 무엇을 공유할지 세밀하게 제어), posix_spawn()(오버헤드 없이 흔히 쓰는 fork+exec 패턴 구현), vfork()(대부분 역사적인 최적화) 같은 것도 있습니다. 하지만 머릿속 모델은 여전히 fork+exec입니다. 리눅스의 모든 프로세스 관리자, init 시스템, 컨테이너 런타임은 이 패턴의 변형을 사용합니다.

시그널: 커널의 인터럽트 시스템

시그널은 Unix의 비동기 알림 메커니즘입니다. Ctrl+C를 누르면 커널이 포그라운드 프로세스에 SIGINT를 보냅니다. kill을 실행하면 시그널을 보내는 것입니다. 자식 프로세스가 종료되면 부모는 SIGCHLD를 받습니다. 본질적으로 소프트웨어 인터럽트입니다. 코드는 하던 일을 멈추고, 시그널 핸들러를 실행한 뒤 다시 재개합니다.

까다로운 부분은 시그널 핸들러가 특이한 컨텍스트에서 실행된다는 점입니다. 대부분의 라이브러리 함수는 재진입(reentrant)이 보장되지 않아서 시그널 핸들러 안에서 안전하게 호출할 수 없습니다. malloc(), printf(), 그리고 락을 잡는 모든 함수는 금지입니다. 안전한 방법은 핸들러에서 플래그만 설정하고, 메인 루프에서 그 플래그를 확인하는 것입니다:

#include <signal.h>
#include <stdio.h>
#include <unistd.h>
static volatile sig_atomic_t shutdown_requested = 0;
void handle_sigterm(int sig) {
// Only set a flag — don't do real work here
shutdown_requested = 1;
}
int main() {
struct sigaction sa = {0};
sa.sa_handler = handle_sigterm;
sigaction(SIGTERM, &sa, NULL);
sigaction(SIGINT, &sa, NULL);
printf("Server running (PID %d)...\n", getpid());
while (!shutdown_requested) {
// Do actual work here
sleep(1);
}
printf("Graceful shutdown complete.\n");
return 0;
}

SIGTERM을 처리해서 우아하게 종료하는 이 패턴은 컨테이너에서 도는 모든 프로세스에 사실상 필수입니다. Kubernetes는 파드를 죽이기 전에 SIGTERM을 보냅니다. Systemd도 서비스를 멈추기 전에 SIGTERM을 보냅니다. 애플리케이션이 이를 처리하지 않으면 타임아웃 후 강제로 죽게 되고, 그 결과는 연결 끊김, 부분 쓰기, 데이터 손상입니다. 일상적인 배포 중에 SIGTERM을 무시하고 비정상적으로 종료된 애플리케이션 때문에 발생한 운영 장애를 실제로 본 적이 있습니다.

소켓: 파일 디스크립터로서의 네트워크

1983년 4.2BSD에 도입된 버클리 소켓 API도 지금까지 세상을 돌리고 있는 또 하나의 설계입니다. 여러분이 만든 모든 TCP 연결, 모든 UDP 패킷, 모든 HTTP 요청은 결국 이 API를 거칩니다. 소켓은 파일 디스크립터이기 때문에 같은 도구들을 그대로 쓸 수 있습니다 — read(), write(), select(), close() 등이 모두 그대로 동작합니다.

각 호출이 무엇을 하는지 이해하고 나면, C로 작성한 최소한의 TCP 서버는 놀랄 만큼 읽기 쉽습니다:

#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
int main() {
// Create a socket (returns a file descriptor)
int server_fd = socket(AF_INET, SOCK_STREAM, 0);
// Allow address reuse (avoid "address already in use")
int opt = 1;
setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
// Bind to port 8080
struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_addr.s_addr = INADDR_ANY,
.sin_port = htons(8080)
};
bind(server_fd, (struct sockaddr*)&addr, sizeof(addr));
// Start listening (backlog of 128 pending connections)
listen(server_fd, 128);
printf("Listening on :8080\n");
while (1) {
// Accept a connection (returns a NEW file descriptor)
int client_fd = accept(server_fd, NULL, NULL);
const char *response =
"HTTP/1.1 200 OK\r\n"
"Content-Length: 13\r\n\r\n"
"Hello, world!";
write(client_fd, response, strlen(response));
close(client_fd);
}
}

약 30줄이면 완전한 HTTP 서버가 됩니다. 단일 스레드이고 한 번에 한 연결만 처리하므로 운영 환경에 바로 쓸 수 있는 수준은 아닙니다. 그래도 소켓의 전체 생명주기를 보여 줍니다: socket(), bind(), listen(), accept(), read()/write(), close(). 모든 웹 프레임워크, 데이터베이스 드라이버, 메시지 브로커는 내부적으로 정확히 이 순서를 사용합니다.

Epoll: 수천 개의 연결 처리하기

위의 단일 스레드 서버는 한 번에 한 연결만 처리합니다. 실제 환경에서는 서버가 수천 개의 동시 연결을 처리해야 합니다. 연결마다 스레드 하나를 두는 순진한 방식은 확장되지 않습니다. 연결이 10,000개라면 1만 개의 스레드 스택, 컨텍스트 스위칭, 스케줄링 비용을 치러야 합니다.

리눅스의 해법은 epoll입니다. 단일 스레드가 수천 개의 파일 디스크립터를 효율적으로 감시할 수 있게 해주는 이벤트 알림 메커니즘입니다. 1만 개의 소켓 각각에 대해 “이 소켓 준비됐어?”라고 묻는 대신, 커널에 “이 소켓들 중 하나라도 준비되면 깨워 줘”라고 말하고, 데이터가 있는 소켓만 처리하면 됩니다.

#include <sys/epoll.h>
// Create an epoll instance
int epfd = epoll_create1(0);
// Register the server socket
struct epoll_event ev = {
.events = EPOLLIN,
.data.fd = server_fd
};
epoll_ctl(epfd, EPOLL_CTL_ADD, server_fd, &ev);
// Event loop
struct epoll_event events[1024];
while (1) {
// Block until at least one fd is ready
int nfds = epoll_wait(epfd, events, 1024, -1);
for (int i = 0; i < nfds; i++) {
if (events[i].data.fd == server_fd) {
// New connection — accept and add to epoll
int client = accept(server_fd, NULL, NULL);
ev.events = EPOLLIN;
ev.data.fd = client;
epoll_ctl(epfd, EPOLL_CTL_ADD, client, &ev);
} else {
// Data ready on existing connection
handle_client(events[i].data.fd);
}
}
}

이것은 리눅스의 모든 고성능 서버의 기반입니다. Nginx는 epoll을 사용합니다. Node.js는 (libuv를 통해) epoll을 사용합니다. Go의 고루틴 스케줄러도 epoll을 사용합니다. Redis도 epoll을 사용합니다. 사람들이 서버가 “이벤트 기반 I/O”나 “논블로킹 I/O”를 쓴다고 말할 때, 대개는 epoll(또는 크로스 플랫폼 대응 기술인 macOS/BSD의 kqueue, 최신 리눅스 시스템의 io_uring)을 가리키는 것입니다.

고수준 개발자가 이것을 알아야 하는 이유

프로덕션에서 C를 직접 쓸 일은 없을지도 모릅니다. 괜찮습니다. 하지만 이 API들을 이해하면 당장 눈에 띄지 않는 여러 방면에서 이득을 봅니다:

• 운영 이슈 디버깅 — strace로 Python 앱이 accept()에서 막혀 있거나 파일 디스크립터를 누수하는 것이 보이면, 커널 수준에서 정확히 무슨 일이 일어나는지 바로 알 수 있습니다.
• 성능 이해하기 — 왜 Node.js는 I/O에는 빠른데 CPU 작업에는 느릴까요? epoll이 I/O 대기를 효율적으로 처리하지만, JavaScript는 연산에서 단일 스레드이기 때문입니다. 시스템 콜 모델이 런타임 모델을 설명해 줍니다.
• 컨테이너와 오케스트레이션 지식 — 네임스페이스, cgroups, seccomp 필터, 케이퍼빌리티는 모두 같은 개념 위에 세워진 리눅스 커널 기능입니다. 컨테이너는 마법이 아닙니다. 추가 플래그가 붙은 clone()일 뿐입니다.
• 더 나은 아키텍처 결정 내리기 — 스레드를 쓸까, 비동기 I/O를 쓸까? 요청마다 프로세스를 띄울까, 커넥션 풀링을 쓸까? 이것들은 근본적으로 커널이 자원을 어떻게 관리하는지에 관한 질문이며, 올바른 답은 시스템 콜 수준에서 트레이드오프를 이해해야 찾을 수 있습니다.

Thompson과 Ritchie는 컨테이너, 클라우드 컴퓨팅, 스마트폰을 예측하지 못했을 것입니다. 하지만 그들이 설계한 시스템 콜 인터페이스는 단순하면서도 조합 가능해서 이 모든 것을 떠받칠 수 있었습니다. 이것이 리눅스 시스템 프로그래밍이 주는 진짜 교훈입니다. 좋은 추상화는 오늘의 문제만 해결하는 것이 아니라, 아무도 상상하지 못한 문제에도 적응할 수 있는 기반을 만듭니다.

모든 시스템 콜을 외울 필요는 없습니다. 하지만 오후 한나절을 투자해 open(2), fork(2), socket(2), epoll(7)의 man 페이지를 읽어 보세요. 간단한 서버를 직접 작성하고, strace로 실행 중인 프로세스를 추적해 보세요. 여기서 쌓은 머릿속 모델은 어떤 언어나 프레임워크를 쓰든 여러분을 더 나은 엔지니어로 만들어 줄 것입니다.