시스템 프로그래밍

다른 프로그램이 딛고 설 바닥을 만드는 자리입니다. 사람이 화면에서 쓰는 프로그램과도 자리가 겹치지만 대개는 그 프로그램을 떠받치는 쪽을 짓습니다. 하드웨어와 운영체제가 무엇을 어떻게 내주는지가 그대로 손에 닿습니다. 무엇을 만드는 일이냐는 물음의 답이 한 문장이 아니라 목록으로 열립니다.

쉽고 빠른 이해

이 자리는 다른 프로그램이 올라설 바닥을 만드는 곳입니다. 운영체제와 하드웨어가 무엇을 내주는지가 그대로 손에 닿는 코드를 짜는 곳이라, 이 자리를 채우는 코드가 없으면 다른 프로그램마다 하드웨어와 운영체제를 직접 상대해야 합니다.

한 문장 정의가 안 서는 것은 여기서 마주치는 게 하나의 동작이 아니라 여러 자리의 모음이기 때문입니다. 표준이 정한 인터페이스 자리, 프로그램이 도는 곳과 운영체제 핵심이 갈리는 경계, 운영체제가 아예 없는 자리, 장치에 붙은 자리가 다 이 이름 아래 있습니다.

안에서는 이 범위를 어디까지 잡느냐로 갈립니다. 좁게 보면 드라이버와 커널처럼 하드웨어에 바로 붙은 코드만 여기 듭니다. 넓게 보면 대형 서버 프로그램이나 컴파일러까지 이 이름으로 부릅니다.

상세

시스템 프로그래밍은 무엇을 하는지가 아니라 어느 자리인지를 가리키는 이름입니다. 그 자리는 응용 프로그램이 시스템과 만나는 접점에 있습니다. 예를 들어 운영체제 핵심부를 짜는 일이나 하드웨어에 붙는 디바이스 드라이버를 만드는 일이 이 접점 위에 있습니다. 이 자리를 채우는 코드가 없으면 다른 프로그램마다 하드웨어와 운영체제를 직접 상대해야 합니다.

그래서 무엇을 만드는 일이냐고 물으면 답이 한 문장이 아니라 목록으로 열립니다 — 표준이 정한 접점, 운영체제 안과 밖이 갈리는 경계, 운영체제가 없는 경우, 장치에 붙은 경우로 나뉩니다. POSIX(Portable Operating System Interface, 이식 가능 운영체제 인터페이스)는 그 가운데 접점 쪽을 문서로 적어 둔 표준입니다. 그 표준의 판 가운데 하나인 POSIX.1-2017 은 자신이 표준 운영체제 인터페이스와 환경을 정의한다고 적습니다. 셸이라 불리는 명령 해석기와 공통 유틸리티 프로그램도 그 안에 듭니다. 같은 표준은 소스 코드 수준에서 응용 프로그램 이식성을 받치는 것을 목적으로 적습니다.

운영체제가 있는 자리에서는 사용자 공간(응용 프로그램이 도는 쪽)과 커널(운영체제의 핵심 부분) 공간의 갈림이 보입니다. Linux 커널 문서는 그 둘 사이의 상호작용 지점이 하나가 아니라고 적습니다. 그 가운데 시스템 콜(응용 프로그램과 커널이 만나는 근본적인 인터페이스)이 가장 전통적이고 가장 뚜렷한 지점이라고 적습니다. 다른 가능성도 있으니 인터페이스에 가장 맞는 것을 고르라고 덧붙입니다.

아래에 운영체제가 없을 수도 있습니다. ISO(International Organization for Standardization, 국제표준화기구)와 IEC(International Electrotechnical Commission, 국제전기기술위원회)가 함께 낸 표준인 ISO/IEC 9899 는 적합한 구현의 두 형태를 hosted 와 freestanding 으로 나눕니다. hosted 환경은 표준이 정한 라이브러리 기능을 제한 없이 다 받아들이는 보통의 실행 환경입니다. freestanding 환경은 운영체제의 도움 없이 C 프로그램 실행이 일어날 수 있는, 쓸 수 있는 라이브러리 기능이 좁혀진 환경이라고 적습니다.

같은 장치를 다루더라도 드라이버를 만드는 일과 그 장치에 접근하는 응용을 만드는 일은 문서가 갈라 다룹니다. Apple 의 디바이스 드라이버 설계 지침은 드라이버를 만드는 사람에게는 이 문서를 읽으라 하고, 장치에 접근하는 응용을 만드는 사람에게는 다른 문서로 보냅니다. 이 갈림이 장치에 붙은 자리를 이 이름 아래의 또 다른 자리로 세웁니다.

한 문장 정의가 안 서는 이유가 다시 드러납니다. 지금까지 본 네 자리 — 표준이 정한 접점, 커널과 사용자 공간이 갈리는 경계, 운영체제가 없는 경우, 장치에 붙은 경우 — 가 다 같은 이름 아래 있습니다.

경계

드라이버를 만드는 일과 그 드라이버가 다루는 장치에 접근하는 응용을 만드는 일은 같은 자리인가. 다릅니다. Apple 의 디바이스 드라이버 설계 지침이 서두에서 그렇게 가릅니다 — 드라이버를 만들 사람에게는 이 문서를 읽으라 하고, 장치에 접근하는 응용을 만들 사람에게는 다른 문서로 보냅니다. 같은 장치를 다루는 두 일을 서로 다른 문서로 갈라 보낸다는 것 자체가 둘을 같은 자리로 안 본다는 판정입니다. 이 판정은 드라이버와 그 드라이버를 쓰는 응용을 가르는 좁은 기준입니다. 범위를 이보다 넓게 잡는 문서도 있습니다 — 다음 절 「이견」이 그 갈래를 보여줍니다.

이견

이 이름의 범위를 어디까지로 잡느냐가 문서마다 갈립니다. 언어 쪽 문서는 이 범위를 「시스템 프로그래밍 언어」가 무엇을 짓는 데 쓰이는지로 잽니다. 그 언어로 무엇을 지을 수 있다고 보는지가 곧 이 이름의 범위이기도 합니다.

Microsoft 의 Lang.NEXT 2014 패널 「Panel: Systems Programming in 2014 and Beyond」 설명은 범위를 넓게 잡습니다. 이 패널에는 Bjarne Stroustrup 과 Andrei Alexandrescu 와 Rob Pike 와 Niko Matsakis 가 참여자로 적혀 있습니다. C++ 와 D 와 Go 와 Rust 를 모두 시스템 프로그래밍 언어로 세웁니다. 정의상 시스템 프로그래밍 언어는 밑에 있는 컴퓨터 하드웨어를 제어하는 소프트웨어 시스템을 짓는 데 쓰인다고 적습니다. 더 높은 수준의 응용 프로그래밍 언어가 응용과 서비스를 만들 때 쓰는 소프트웨어 플랫폼을 제공하는 데도 쓰인다고 적습니다. 흔히 운영체제와 컴파일러와 디바이스 드라이버를 만드는 데 쓰인다고 덧붙입니다. 공장 자동화와 로봇과 고성능 수학 소프트웨어와 게임, 심지어 컴퓨테이셔널 아트(코드로 만드는 예술 작품)를 만드는 데까지 쓰인다고 적습니다. 이 설명은 오늘날 응용과 시스템 사이에 상당한 겹침이 있다는 것은 말할 것도 없다고 적으면서도, 바로 다음 문장에서 정말 그런지 스스로 되묻습니다.

Google 의 Rob Pike 는 구글의 대형 프로그램 — 예컨대 웹 서버 — 을 짓기에 맞는 새 언어를 설계해 볼 만하다고 여겨졌다고 적습니다. 그는 Go 를 시스템 언어라 부릅니다. 시스템 언어에서 가비지 컬렉션(프로그램이 안 쓰는 메모리를 직접 안 돌려주고 실행 환경이 대신 찾아 회수하는 방식)은 논란이 될 수 있는 기능이라고 적습니다. 그런데도 Go 를 가비지 컬렉션 언어로 하기로 정하는 데는 시간을 거의 안 썼다고 적습니다.

Rust 프로젝트는 자기 언어를 안전성과 속도와 동시성에 초점을 둔 현대적 시스템 프로그래밍 언어라고 적습니다. 가비지 컬렉션을 쓰지 않고 메모리 안전을 이룸으로써 그 목표를 이룬다고 덧붙입니다. 같은 이름 아래에서 가비지 컬렉션이 한쪽에서는 논란거리로, 다른 쪽에서는 쓰지 않는 것으로 적혀 있습니다.

어느 범위가 옳은지는 여기서 적지 않습니다.

시스템 프로그래밍

상세

경계

이견

관련 항목

커널과 사용자 공간이 갈리는 자리에서 쓰는 개념

메모리를 직접 다루는 개념

실행 파일을 만들고 잇는 자리에서 쓰는 개념

장치를 다루는 자리에서 쓰는 개념

표준이 실행 환경을 정하는 자리에서 쓰는 개념

쓰는 언어

이것에서 자주 나는 오류·장애