POSIX (Portable Operating System Interface)

POSIX는 유닉스 계열 운영체제의 공통 인터페이스 계약을 정리한 표준입니다. 이 문서는 POSIX의 역사, Issue 8 문서 구조, 시스템 인터페이스(System Interfaces)와 셸·유틸리티(Shell and Utilities)의 범위, Linux와 GNU 확장의 차이, 커널 개발자가 실제로 부딪히는 이식성 문제를 한 문서에서 연결해 설명합니다.

개요

POSIX는 Portable Operating System Interface의 약자이며, 서로 다른 유닉스 계열 시스템이 공통된 인터페이스를 제공하도록 정리한 표준 집합입니다. 이름만 보면 시스템 콜 표준처럼 느껴지지만, 실제 범위는 그보다 훨씬 넓습니다. 함수(Function), 헤더(Header), 시그널(Signal), 파일 시맨틱(File Semantics), 스레드(Thread), 셸 문법, 표준 유틸리티, 빌드 도구의 최소 동작까지 함께 다룹니다.

리눅스 커널 개발자에게 POSIX가 중요한 이유는 두 가지입니다. 첫째, 커널은 사용자 공간이 기대하는 파일·프로세스·시그널 시맨틱을 구현해야 합니다. 둘째, 커널 개발 과정에서 쓰는 테스트 프로그램, 재현 코드, 셸 스크립트, 이식성 있는 도구는 POSIX 계약 위에서 움직입니다. 따라서 POSIX를 모르면 커널 내부는 알아도 사용자 공간 기대치와 어긋난 설계를 하기 쉽습니다.

역사와 표준 계보

POSIX는 여러 유닉스 계열 시스템 사이의 인터페이스 차이를 줄이기 위해 등장했습니다. 오늘날 개발자가 보는 온라인 문서는 The Open Group이 게시하지만, 표준 자체는 IEEE와 The Open Group이 함께 관리하며, 실제 기술 작업은 Austin Group이 주도합니다.

Issue 8 rationale는 POSIX.1-2024가 Issue 8과 기술적으로 동일하며, Austin Group이 IEEE, The Open Group, ISO/IEC 협업 구조 안에서 작업했다는 점을 명확히 밝힙니다. 실무에서는 "POSIX", "Issue 8", "SUSv5"가 문맥에 따라 함께 언급될 수 있지만, 완전히 같은 범위로 느슨하게 써버리면 문서 참조가 흐려집니다.

Issue 8 문서 구조와 읽는 법

POSIX 문서는 처음 보면 방대해 보이지만, 실제로는 네 덩어리만 익히면 됩니다. 대부분의 커널 개발자는 함수 하나를 찾다가 문서 전체에 압도되는데, 먼저 "어느 권(volume)에 있는가"를 분리하면 탐색 비용이 크게 줄어듭니다.

커널 개발자에게 특히 중요한 읽기 순서는 다음과 같습니다. 함수 의미가 애매하면 먼저 XSH를 봅니다. 에러 코드나 타입 정의가 헷갈리면 XBD로 올라갑니다. 왜 Linux 구현과 다르게 보이는지 이해가 안 되면 XRAT를 확인합니다. 셸 스크립트 이식성 문제라면 XCU를 봅니다.

Feature Test Macro — POSIX 범위 제어

POSIX 함수를 사용하기 전에 반드시 이해해야 하는 것이 기능 테스트 매크로(Feature Test Macro)입니다. 이 매크로는 libc 헤더가 어느 수준의 인터페이스를 노출할지 컴파일러에게 알려줍니다. 매크로를 지정하지 않으면 glibc 기본값은 _DEFAULT_SOURCE로 GNU 확장 상당 부분이 노출되어, 이식성 문제가 있는 코드를 컴파일 오류 없이 작성해버리기 쉽습니다.

/* 이식성을 최우선으로 할 때 — POSIX.1-2008 범위만 사용 */
#define _POSIX_C_SOURCE 200809L
#include <unistd.h>
#include <fcntl.h>

/* epoll_create1()은 POSIX 범위 밖 → 이 설정에서는 선언이 보이지 않음 */

/* Linux 전용 API까지 허용할 때 — GNU/Linux 특화 코드에서만 사용 */
#define _GNU_SOURCE
#include <sys/epoll.h>
/* epoll_create1(), signalfd(), eventfd() 등 모두 보임 */

핵심 시스템 인터페이스

커널 개발자 입장에서 POSIX의 중심은 결국 시스템 인터페이스입니다. 다만 "시스템 인터페이스"가 곧 "시스템 콜"은 아닙니다. 어떤 함수는 libc 래퍼가 직접 시스템 콜에 연결되고, 어떤 함수는 사용자 공간에서 조합되며, 어떤 함수는 스레드 라이브러리와 커널 기능이 함께 구현합니다.

예를 들어 pthread_mutex_lock()은 POSIX 인터페이스이지만 Linux 커널 안에 동일 이름의 시스템 콜이 있는 것은 아닙니다. 반대로 epoll_wait()는 Linux에서 실무적으로 매우 중요하지만 POSIX 표준 함수는 아닙니다. 따라서 커널 문서나 코드 예제에서 "POSIX API"와 "Linux syscall"을 같은 말처럼 쓰면 설명이 무너집니다.

#define _POSIX_C_SOURCE 200809L
#include <fcntl.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

static volatile sig_atomic_t stop;

static void on_sigint(int sig)
{
    (void)sig;
    stop = 1;
}

int main(void)
{
    struct sigaction sa;
    int fd;
    char buf[64];
    ssize_t nr;

    memset(&sa, 0, sizeof(sa));
    sa.sa_handler = on_sigint;
    sigemptyset(&sa.sa_mask);
    sigaction(SIGINT, &sa, 0);

    fd = open("posix-demo.txt", O_RDONLY);
    if (fd < 0) {
        perror("open");
        return 1;
    }

    nr = read(fd, buf, sizeof(buf) - 1);
    if (nr >= 0) {
        buf[nr] = '\0';
        write(STDOUT_FILENO, buf, nr);
    }

    close(fd);
    return stop ? 130 : 0;
}

파일 디스크립터(File Descriptor)와 I/O 모델

POSIX I/O의 핵심은 파일 디스크립터(File Descriptor, FD)입니다. FD는 프로세스가 열린 파일·파이프·소켓·파일시스템(Filesystem) 디바이스를 참조하는 음수가 아닌 정수입니다. POSIX는 FD의 의미, 상속 규칙, 에러 시맨틱을 규정하지만 커널 내부 자료구조는 강제하지 않습니다.

POSIX FD vs. stdio 스트림

C 표준 라이브러리의 FILE * 스트림(stdio)과 POSIX FD는 다른 수준의 인터페이스입니다. stdio는 내부적으로 POSIX FD를 사용하지만 버퍼(Buffer) 계층을 추가합니다.

POSIX 에러 모델 — errno

POSIX 함수가 실패하면 일반적으로 -1을 반환하고 errno에 에러 코드를 설정합니다. errno는 스레드 로컬 변수이므로 멀티스레드 환경에서도 각 스레드가 독립적으로 확인합니다.

#define _POSIX_C_SOURCE 200809L
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

int main(void)
{
    int fd = open("/nonexistent", O_RDONLY);
    if (fd == -1) {
        /* errno는 open() 직후에 즉시 읽어야 합니다.
         * 다른 함수 호출 사이에 errno가 덮어써질 수 있습니다. */
        int saved_errno = errno;
        fprintf(stderr, "open 실패: %s (errno=%d)\n",
                strerror(saved_errno), saved_errno);
        return 1;
    }
    close(fd);
    return 0;
}

셸·유틸리티·빌드 도구

POSIX는 C API만 다루지 않습니다. 셸 명령어 언어와 표준 유틸리티도 큰 비중을 차지합니다. 커널 개발 환경에서 이 부분이 중요한 이유는 빌드 스크립트, 테스트 스크립트, initramfs 초기화 스크립트, 패키징 도구가 예상보다 자주 /bin/sh 이식성 문제를 일으키기 때문입니다.

# POSIX sh 호환 예시: /bin/sh에서 동작하는 형태
set -eu

file="${1:-Makefile}"
if [ ! -r "$file" ]; then
    printf '읽을 수 없는 파일: %s\n' "$file" >&2
    exit 1
fi

case "$file" in
    *.c|*.h) printf 'C 계열 파일: %s\n' "$file" ;;
    *)       printf '기타 파일: %s\n' "$file" ;;
esac

count=0
for line in $(wc -l < "$file"); do
    count="$line"
done
printf '줄 수: %s\n' "$count"

위 스크립트는 Bash에서는 너무 평범해 보이지만, 핵심은 Bash 전용 문법에 기대지 않는다는 점입니다. 커널 트리의 많은 보조 스크립트는 이 수준의 보수성을 전제로 작성됩니다. /bin/sh가 bash가 아닐 수 있다는 사실을 기준으로 보면, POSIX 셸 문법이 왜 여전히 중요한지 바로 이해됩니다.

Linux와 POSIX의 차이

Linux는 POSIX를 많이 구현하지만 POSIX 그 자체는 아닙니다. 또한 실무에서는 POSIX 코어, XSI 옵션, GNU 확장, Linux 전용 API가 겹쳐 쓰입니다. 이 층을 분리하지 않으면 문서 설명도, 코드 리뷰도, 버그 재현도 모두 흐려집니다.

대표적인 예로 ioctl()은 POSIX에서 구체적 시맨틱을 강하게 규정한 인터페이스가 아닙니다. 반면 open()과 read()는 규정이 비교적 강합니다. 또 epoll은 Linux에서 사실상 표준처럼 쓰이지만 POSIX poll()의 대체 확장으로 이해해야 합니다. 문서에서 이런 층을 명시하지 않으면 독자가 "휴대 가능한 계약"과 "Linux 최적화 인터페이스"를 섞어 받아들이게 됩니다.

이식성 실전 예제

이식성은 거창한 목표가 아니라, 문제가 생겼을 때 범위를 좁히기 쉽게 만드는 작업입니다. 커널 개발자 입장에서는 테스트 코드와 보조 스크립트만 POSIX 중심으로 작성해도 재현 환경이 훨씬 넓어집니다.

/* Linux 확장 대신 POSIX 우선 경로를 잡는 예시 */
#define _POSIX_C_SOURCE 200809L
#include <errno.h>
#include <poll.h>
#include <stdio.h>
#include <unistd.h>

int wait_for_input(int fd, int timeout_ms)
{
    struct pollfd pfd;

    pfd.fd = fd;
    pfd.events = POLLIN;
    pfd.revents = 0;

    for (;;) {
        int ret = poll(&pfd, 1, timeout_ms);
        if (ret >= 0)
            return ret;
        if (errno != EINTR)
            return -1;
    }
}

이 코드는 Linux에서 epoll보다 느릴 수 있지만, 인터페이스 계약은 단순하고 넓게 호환됩니다. 커널 버그 재현이나 최소 예제에서는 이런 코드가 훨씬 가치가 큽니다. 반대로 고성능 서버 경로에서는 Linux 전용 API를 적극 써도 되지만, 그 사실을 문서와 코드 주석에서 숨기지 말아야 합니다.

자주 틀리는 지점

POSIX.1-2024 (Issue 8) 핵심 변경 요약

IEEE Std 1003.1-2024 / The Open Group Base Specifications Issue 8은 2024년 6월 14일에 공식 발행되었습니다. 직전 버전인 Issue 7 (POSIX.1-2008, 2017년 수정판 포함)과 비교해 약 7년 만의 메이저 갱신이며, 이 7년 동안 glibc/musl/Linux syscall 생태계에 관습적으로 정착된 다수의 API가 표준에 편입되었습니다.

문서 구조와 공개 방식

• ISO/IEC/IEEE 9945:2024와 The Open Group Base Specifications Issue 8이 같은 본문을 공유합니다.
• Open Group 공개 URL: pubs.opengroup.org/onlinepubs/9799919799/ — 숫자 9799919799가 Issue 8을 의미합니다 (Issue 7은 9699919799).
• Corrigendum 1(P1003.1-2024/Cor 1)은 Austin Group 이슈 트래커에서 후속 정리 작업이 계속되고 있으므로, 정확한 반영 시점은 Austin Group 공개 상태를 다시 확인하는 편이 안전합니다.
• IEEE Xplore는 유료, Open Group 온라인판은 무료 HTML입니다.

표준화된 주요 신규 인터페이스

C 언어 정합성 갱신

• Issue 7은 C99, 이후 TC는 C11을 부분 반영. Issue 8은 C17 (ISO/IEC 9899:2018) 기반으로 용어/헤더를 통일했습니다.
• <stdnoreturn.h>, <threads.h>는 여전히 optional로 유지 — 커널이나 고성능 서버에서는 pthread 계열을 계속 사용.
• C23 도입은 차기 Issue(Issue 9, 시기 미정)에서 검토.

셸 · 유틸리티 주요 변경

• POSIX sh: type built-in이 권장 상태로 표준화, printf %q가 정식, local 키워드 논의 진행 중(Issue 8까지는 미포함).
• awk: getline var < cmd 용법 명확화, length(array)가 표준으로 확정.
• sed: -E ERE 옵션이 표준(이전엔 -r은 비표준).
• find: -print0, -delete는 여전히 비표준 — POSIX-pure 스크립트는 -exec rm {} +가 기준.

2026 시점 Linux와 POSIX의 간극

참고자료

• POSIX.1-2024 / The Open Group Base Specifications Issue 8 — 최신 공개 온라인 표준 본문입니다.
• Issue 8 Download — 개인용 HTML 묶음을 받을 수 있는 공식 다운로드 안내입니다.
• System Interfaces — 함수 규약, 에러, 헤더, 시맨틱을 확인할 때 보는 권입니다.
• POSIX Shell Command Language — POSIX sh 문법의 핵심 기준입니다.
• POSIX Utilities — 셸과 표준 유틸리티 전체 목록입니다.
• Issue 8 Rationale — 표준 배경과 변경 이유를 설명하는 권입니다.
• Linux man-pages project — POSIX 인터페이스가 Linux에서 실제로 어떻게 노출되는지 확인하는 데 유용합니다.
• 참고자료 - POSIX & ABI — 이 사이트의 관련 표준 허브입니다.
• 시스템 콜, 시그널 처리, IPC, VFS, Bash 셸 스크립팅, GNU Make — POSIX가 실제 구현과 만나는 지점을 상세히 다룹니다.