시스템 콜(System Call)이란 무엇인가요?

시스템 콜은 애플리케이션이 운영체제 커널에게 파일, 네트워크, 프로세스, 메모리 같은 보호된 자원을 사용해 달라고 요청하는 공식 진입점입니다. 사용자 프로그램은 직접 디스크나 NIC를 제어하지 않고, 커널이 검증한 API를 통해 작업합니다.

왜 커널을 거쳐야 하나요?

CPU는 보통 사용자 모드와 커널 모드를 구분합니다. 사용자 모드에서는 하드웨어 접근, 페이지 테이블 변경, 프로세스 종료 같은 위험한 명령을 실행할 수 없습니다. 대신 read, write, open, socket, fork, mmap 같은 시스템 콜을 호출하면 CPU가 커널 모드로 전환되고, 커널이 권한과 인자를 검사한 뒤 작업을 수행합니다.

애플리케이션 코드
  -> 라이브러리 함수 호출(read, fetch 내부의 send 등)
  -> 시스템 콜 트랩
  -> 커널: 권한/FD/버퍼/상태 확인
  -> 디바이스 드라이버 또는 커널 자료구조 조작
  -> 결과와 errno 반환

예시로 보는 시스템 콜

int fd = open("/var/log/app.log", O_RDONLY);
if (fd < 0) {
    perror("open failed");
    return 1;
}

char buf[4096];
ssize_t n = read(fd, buf, sizeof(buf));
close(fd);

이 코드는 단순해 보이지만 open, read, close는 모두 시스템 콜입니다. 파일 권한이 없거나, FD 한도를 초과했거나, 디스크 I/O가 지연되면 애플리케이션 코드가 아니라 커널 경계에서 실패가 드러납니다.

비용과 성능 고려

시스템 콜은 일반 함수 호출보다 비쌉니다. 사용자 모드와 커널 모드 전환, 인자 복사, 보안 검사, 스케줄링 영향이 있기 때문입니다. 그래서 작은 데이터를 한 바이트씩 read()/write()하는 코드는 성능이 나빠질 수 있습니다.

나쁜 예: 1 byte write x 1,000,000
좋은 예: 사용자 공간 버퍼에 모은 뒤 4KB/64KB 단위 write

실무에서는 버퍼링, 배치 처리, sendfile, mmap, 비동기 I/O, 커넥션 재사용 같은 방식으로 시스템 콜 횟수와 블로킹 시간을 줄입니다.

자주 만나는 문제

• 반환값을 확인하지 않아 부분 쓰기(partial write), EINTR, EAGAIN을 놓칩니다.
• 컨테이너에서 seccomp 정책 때문에 특정 시스템 콜이 막힙니다.
• 파일 디스크립터 누수로 EMFILE: too many open files가 발생합니다.
• 네트워크 장애가 애플리케이션 예외가 아니라 connect, recv, send 실패로 나타납니다.

면접 답변 포인트

“시스템 콜은 사용자 프로그램이 커널의 보호된 기능을 요청하는 인터페이스입니다. 파일 I/O, 네트워크, 프로세스 생성 같은 작업이 대표 예이고, 권한 격리와 안정성을 제공하지만 모드 전환 비용이 있으므로 호출 횟수, 블로킹, 오류 처리를 신경 써야 합니다.”라고 답하면 좋습니다.