표준 라이브러리

표준 라이브러리는 언어를 깔기만 해도 쓸 수 있는 기능을 미리 갖춰 둡니다. 파일을 읽는 일처럼 어느 프로그램에나 나오는 코드를 따로 받지 않고 부를 수 있습니다. 무엇까지 갖춰 두고 무엇을 바깥에 맡길지는 언어마다 다릅니다.

쉽고 빠른 이해

표준 라이브러리는 언어를 설치하면 같이 깔려 오는 기능 묶음입니다. 글자를 자르는 함수, 파일을 열고 쓰는 함수, 지금 시각을 얻는 함수가 여기 들어 있습니다.

이게 없으면 줄 바꿈을 기준으로 글을 나누는 코드까지 사람마다 다시 짜야 합니다. 남이 만든 것을 받아 쓰더라도 어디서 받을지부터 정해야 합니다.

쓰는 순서는 셋입니다.

언어를 설치합니다. 표준 라이브러리도 같이 깔립니다
쓰려는 모듈의 이름을 코드에서 불러옵니다
그 안의 함수를 부릅니다

대가도 있습니다. 한번 들어간 기능은 부르는 코드가 쌓여서 함부로 못 뺍니다. 더 나은 방법이 나와도 옛 기능이 남습니다. 고치는 속도는 언어를 따라갑니다.

고를 때는 안에 있는 것부터 봅니다. 안에 있는 것으로 되면 그것을 쓰고, 다루는 규격이 자주 바뀌거나 안의 것이 낡았을 때만 바깥 라이브러리를 받습니다.

상세

이사 갈 집을 보러 가면 싱크대와 조명은 이미 달려 있습니다. 냉장고와 책상은 들어가면서 내가 들여야 합니다. 붙박이로 달린 쪽은 집을 고를 때 같이 딸려 옵니다.

표준 라이브러리는 붙박이 쪽입니다. 언어를 설치하면 그 언어로 짠 프로그램이 곧바로 부를 수 있는 함수와 타입이 함께 깔립니다. 파일을 한 줄씩 읽는 함수, 글자를 잘라 내는 함수, 지금 시각을 얻는 함수가 그런 것들입니다.

안은 모듈이라고 부르는 덩이로 나뉘어 있습니다. 모듈은 관련 있는 함수와 타입을 이름 하나 아래 묶어 둔 단위입니다. 통째로 다 쓰는 것이 아니라 필요한 모듈만 이름으로 불러다 씁니다.

flowchart TD
    subgraph SL["표준 라이브러리"]
        subgraph M1["글자 모듈"]
            F1["글자를 잘라 내는 함수"]
        end
        subgraph M2["파일 모듈"]
            F2["파일을 한 줄씩 읽는 함수"]
        end
        subgraph M3["시각 모듈"]
            F3["지금 시각을 얻는 함수"]
        end
        M4["나머지 모듈"]
    end

층이 셋입니다. 표준 라이브러리 안에 모듈이 있고, 모듈 안에 함수와 타입이 있습니다. 코드에서 불러오는 이름은 가운데 층인 모듈입니다.

문법이 아니라 미리 짜인 코드

언어를 둘로 갈라 보면 표준 라이브러리가 어디쯤 있는지 보입니다. 하나는 문법입니다. 조건문과 반복문, 함수를 정의하는 방법처럼 컴파일러나 인터프리터가 직접 알아듣는 규칙입니다.

다른 하나가 표준 라이브러리입니다. 그 문법으로 미리 짜 둔 코드라, 언어가 알아듣는 것이 아니라 불러다 쓰는 것입니다. 그래서 기능 하나를 여기 더하는 일은 문법을 고치는 일보다 훨씬 적게 건드립니다.

둘은 쓰기 전에 이름을 불러와야 하느냐로 나뉩니다. 불러와야 쓸 수 있으면 라이브러리이고, 아무것도 안 불러와도 되면 문법입니다. 자주 쓰는 몇몇은 안 불러와도 되게 열어 두기도 합니다.

불러와 쓰는 모양은 아래와 같습니다. 파이썬 표기를 빌렸습니다.

Python

import json                 # 따로 받을 것이 없다
json.dumps({"id": 7})       # '{"id": 7}'

첫 줄이 이름을 불러오는 줄이고, 둘째 줄이 그 안의 함수를 부르는 줄입니다. 값을 주고받을 수 있는 글이나 바이트로 바꾸는 일을 직렬화라고 합니다. 그 코드가 언어에 이미 들어 있는 겁니다. 부르는 낱말은 언어마다 import·include·use 처럼 다르고 하는 일은 같습니다.

언어와 함께 배포된다

이름에 「표준」이 붙은 것은 언어 배포판에 이 코드가 들어 있기 때문입니다. 언어 배포판은 코드를 짜고 돌리는 데 필요한 것을 한 벌로 묶어 내놓는 꾸러미입니다. 코드를 돌리는 런타임도 같은 꾸러미에 들어 있습니다.

내가 짠 코드가 부르는 라이브러리는 두 갈래입니다. 하나는 배포판에 들어 있는 표준 라이브러리이고, 다른 하나는 따로 받아야 하는 바깥 라이브러리입니다.

바깥 라이브러리가 쌓여 있는 곳을 패키지 저장소라고 합니다. 저장소에서 그것을 받아다 깔아 주는 도구는 패키지 관리자입니다.

flowchart TD
    subgraph 배포판["언어 배포판 · 한 번에 깔린다"]
        C["컴파일러 · 런타임"]
        S["표준 라이브러리"]
    end
    M["내가 짠 코드"] -->|부른다| S
    M -->|부른다| E["바깥 라이브러리"]
    R["패키지 저장소"] -->|따로 받아 온다| E

설치 한 번으로 위쪽 상자가 함께 들어옵니다. 언어가 깔린 기계면 표준 라이브러리도 있다고 봐도 됩니다. 바깥 라이브러리는 저장소에서 받아 오기 전까지 그 기계에 없습니다.

판올림도 함께 움직입니다. 언어를 새 판으로 올리면 표준 라이브러리도 같이 올라갑니다. 이것만 따로 최신으로 갈아 끼우지는 않습니다. 언어 판을 올린다는 말에는 라이브러리가 바뀐다는 뜻이 들어 있습니다.

바깥 라이브러리와 나뉘는 네 축

둘의 차이는 기능의 종류가 아니라 손에 들어오는 길입니다. 같은 일을 하는 코드가 양쪽에 다 있을 수 있습니다.

축	표준 라이브러리	바깥 라이브러리
손에 넣는 방법	언어를 설치하면 들어 있습니다	패키지 관리자로 따로 받습니다
판올림	언어 판과 함께 움직입니다	만든 쪽 일정대로 따로 올라갑니다
고르는 몫	고를 것이 없습니다	비슷한 것 여럿 중에 골라야 합니다
없을 때	그 언어가 도는 기계면 있습니다	못 받아 오면 코드가 안 돕니다

이 차이가 제일 크게 드러나는 곳은 배포입니다. 표준 라이브러리만 쓴 코드는 언어만 깔려 있으면 그 기계에서 돕니다. 바깥 라이브러리를 쓰면 그것이 또 부르는 라이브러리까지 따라와야 합니다. 이렇게 물린 사슬을 의존성이라고 부릅니다.

flowchart TD
    subgraph 안["표준만 쓴 코드"]
        A1["내가 짠 코드"] --> A2["표준 라이브러리"]
    end
    subgraph 밖["바깥을 쓴 코드"]
        B1["내가 짠 코드"] --> B2["바깥 라이브러리 A"]
        B2 --> B3["바깥 라이브러리 B"]
        B3 --> B4["바깥 라이브러리 C"]
        B4 --> B5["나머지 …"]
    end

표준 라이브러리만 쓴 코드는 배포할 때 따라올 것이 없습니다. 바깥 라이브러리를 쓴 코드는 그것이 부르는 것, 또 그것이 부르는 것까지 한 벌로 따라옵니다. 사슬이 깊어질수록 배포할 때 챙길 것이 늘어납니다.

인터넷이 막힌 폐쇄망이나 깔리는 용량을 줄여야 하는 배포에서 이 사슬이 짐이 됩니다. 그래서 표준 라이브러리만으로 되는 코드가 그런 곳에서 특히 유리합니다.

거의 모든 언어가 갖춰 두는 갈래

목록은 언어마다 다르지만 겹치는 갈래가 있습니다. 어느 분야를 짜든 필요한 일들입니다.

갈래	하는 일
글자와 텍스트	자르고 붙이고 찾고 바꿉니다
담는 그릇	목록·해시테이블 같은 자료구조를 내놓습니다
파일과 입출력	파일을 열어 읽고 씁니다
시각과 날짜	지금 시각을 얻고 날짜를 셈합니다
수와 난수	반올림·제곱근·무작위 값을 냅니다
직렬화	값을 글이나 바이트로 바꾸고 되돌립니다
네트워크	다른 기계에 연결해 값을 주고받습니다
동시성	여러 일을 같이 돌립니다

이 갈래들의 공통점은 한 분야에 매이지 않는다는 것입니다. 웹을 짜든 데이터를 다루든 필요합니다. 언어가 안 갖춰 두면 사람마다 같은 코드를 다시 짭니다.

바로 그것이 표준 라이브러리를 두는 까닭입니다. 모두가 필요한 것을 한 번 짜서 언어에 붙여 두면, 짜는 사람은 그 일에 시간을 안 쓰고 읽는 사람은 처음 보는 코드에서도 낯익은 이름을 만납니다.

크기를 정하는 두 방향

무엇까지 안에 넣을지는 언어를 만드는 쪽이 정합니다. 방향은 둘로 나뉩니다.

한쪽은 많이 넣습니다. 파이썬은 웹 서버·압축·단위 테스트 도구까지 안에 갖춰 두어, 받을 것 없이 웬만한 프로그램을 짜게 합니다. 처음 배우는 사람이 설치 없이 바로 무언가를 만들 수 있습니다.

다른 한쪽은 적게 넣습니다. C 는 글자·입출력·수학 정도만 남기고 나머지를 바깥 라이브러리에 맡깁니다. 언어가 작게 유지됩니다. 모양이 자주 바뀌는 분야는 바깥에서 더 자주 고쳐집니다.

안에 넣을지 말지는 그 기능이 얼마나 오래 안 바뀌는가를 보고 정합니다. 십 년이 지나도 같은 모양일 것은 안에 넣어도 됩니다. 해마다 모양이 바뀌는 것은 넣어 두면 낡은 채로 남습니다.

한번 들어간 기능을 못 빼는 대가

기능 하나가 표준 라이브러리에 들어가면 그것을 부르는 코드가 세상에 쌓입니다. 그 기능을 빼거나 모양을 바꾸면 쌓인 코드가 한꺼번에 깨집니다.

그래서 언어를 만드는 쪽은 잘 안 뺍니다. 더 나은 방법이 나와도 옛 기능을 남겨 둔 채 새것을 옆에 붙입니다. 옛 약속을 계속 지켜 주는 이 성질을 하위 호환이라고 합니다.

읽는 사람 쪽에서 보면 같은 일을 하는 방법이 둘 이상 남은 모양이 됩니다. 어느 쪽이 요즘 쓰는 것인지는 공식 문서가 적어 둡니다. 쓰지 말라고 표시해 둔 옛 기능을 사용 중단이라고 합니다.

기능 하나가 걷는 길을 늘어놓으면 이렇게 됩니다.

stateDiagram-v2
    state "표준 라이브러리에 들어감" as S1
    state "부르는 코드가 쌓임" as S2
    state "사용 중단 표시된 채 남음" as S3
    state "새 기능이 옆에 붙음" as S4
    [*] --> S1
    S1 --> S2
    S2 --> S3: 더 나은 방법이 나옴
    S3 --> S4: 옛것을 남긴 채
    note right of S3
        빼는 길은 없다
        빼면 쌓인 코드가 깨진다
    end note

안에 있는 것을 먼저 보는 까닭

같은 일을 하는 바깥 라이브러리가 있을 때 무엇을 고를지는 이렇게 나뉩니다. 여기서 「안」은 표준 라이브러리이고 「바깥」은 따로 받아 오는 라이브러리입니다.

flowchart TD
    Q{"안의 것으로 되나"}
    Q -->|된다| Y["안의 것을 쓴다"]
    Q -->|안 된다| N["바깥을 본다"]
    N --> C1["다루는 규격이 자주 바뀐다"]
    N --> C2["처리 속도를 많이 따진다"]
    N --> C3["안의 것이 오래전 모양이다"]

안에 있는 것으로 되는 일이면 안의 것을 씁니다. 받아 올 것이 없습니다. 언어가 사는 동안 같이 삽니다. 코드를 읽는 동료도 따로 찾아보지 않고 압니다.

안의 것으로는 손이 많이 가거나 아예 없는 일이면 바깥으로 갑니다. 다루는 규격이 자주 바뀌는 분야, 처리 속도를 많이 따지는 분야, 안의 것이 아주 오래전 모양으로 남은 분야가 그렇습니다.

바깥 라이브러리를 하나 들일 때마다 받아 올 것이 늘고 판올림도 따라가야 합니다. 그래서 고르는 순서는 안을 먼저 보고 모자랄 때 바깥을 보는 쪽입니다.