출처 : allvpv's space - Environment variables are a legacy mess: Let's dive deep into them (2025.10.13)

✼✼ disclaimer ✼✼ 본 글은 AI 번역 후 직접 검수하여 작성했습니다. 효율적인 정보 전달을 위해 AI 번역을 활용하되, 부자연스러운 표현은 수정했습니다. 번역 오류가 있을 수 있으니 정확한 내용은 원문을 확인하시기 바랍니다.

프로그래밍 언어는 최근 몇 년 사이 급격히 진화했다. 하지만 소프트웨어 개발 현장에서는 최신 기술과 구형 시스템이 늘 공존하기 마련이고, OS가 프로세스를 돌리는 기본 방식은 Unix 시절 이후 별반 달라진 게 없다.

런타임에 몇 가지 변수를 즉석으로 넘겨서 앱을 설정해야 하는데, 별도 파일이나 IPC, 네트워킹 같은 복잡한 방법을 쓰고 싶지 않다면? 그럼 어쩔 수 없이 꽤 불편하고 낡은 인터페이스를 써야 한다:

환경 변수 말이다.

export SECRET_API_KEY=2u845102348u234

네임스페이스도 없고 타입도 없다. 그냥 납작하고 민망할 정도로 전역인 문자열 사전 하나뿐이다.

그런데 환경 변수가 정확히 뭘까? OS 내부 어딘가에 있는 특별한 딕셔너리? 아니라면 누가 관리하고 어떻게 퍼져나가는 걸까?

대체 어디서 오는 거지?

간단히 말하자면: 부모 프로세스에서 자식 프로세스로 넘어간다.

 841 ?     00:00:00 sshd
1520 ?     00:00:00  \_ sshd-session
1616 ?     00:00:00      \_ sshd-session
5521 pts/0 00:00:00          \_ bash
5545 pts/0 00:00:00              \_ nu
5549 pts/0 00:00:00                  \_ bash
5560 pts/0 00:00:00                      \_ ps

Linux에서는 프로그램이 다른 프로그램을 실행할 때 반드시 execve 시스템 콜을 써야 한다. Bash에서 ls를 치든, Python에서 subprocess.run을 부르든, 코드 에디터를 열든, 결국 모두 execve로 이어진다(그 전에 clone/fork가 먼저 일어나지만). C의 exec* 계열 함수들도 마찬가지로 execve에 기대고 있다.

SYSCALL_DEFINE3(execve,
		const char __user *, filename,
		const char __user *const __user *, argv,
		const char __user *const __user *, envp)

이 시스템 콜은 세 가지 인자를 받는다: filename, argv, envp. 예를 들어 ls -lah를 실행한다면:

/usr/bin/ls가 filename(실행 파일 경로)
['ls', '-lah']가 argv 배열(명령줄 인자들) : 첫 번째("0번") 인자는 관례상 실행 파일명
['PATH=/bin:/usr/bin', 'USER=allvpv']가 envp 배열(환경 변수들, 실제론 훨씬 김)

기본적으로 모든 환경 변수가 부모에서 자식으로 넘어간다. 하지만 부모 프로세스가 execve를 호출할 때 완전히 다른 환경이나 아예 빈 환경을 넘기는 것도 가능하다! 실제로는 대부분의 도구가 환경을 그대로 물려준다: Bash, Python의 subprocess.run, C 라이브러리 execl 등 모두 마찬가지다.

이게 바로 우리가 원하는 동작이다 : 변수들이 자식 프로세스로 상속되는 것. 애초에 환경을 추적하자고 만든 게 이거니까.

그럼 부모 환경을 전달하지 않는 도구는 뭐가 있을까? 예를 들어 시스템 로그인에 쓰이는 login 실행 파일은 자식들을 위해 깨끗한 환경을 새로 구성한다.

어디로 가는가?

새 프로그램을 실행한 후, 커널은 변수들을 스택에 덤프한다. null로 끝나는 문자열 시퀀스 형태로, 환경 변수 정의들을 담아서. 16진수로 보면 이렇다:

    484f 4d45 3d2f 0069 6e69 743d 2f73 6269  HOME=/ init=/sbi
    6e2f 696e 6974 004e 4554 574f 524b 5f53  n/init NETWORK_S
    4b49 505f 454e 534c 4156 4544 3d00 5445  KIP_ENSLAVED= TE
    524d 3d6c 696e 7578 0042 4f4f 545f 494d  RM=linux BOOT_IM
    4147 453d 2f76 6d6c 696e 757a 2d36 2e31  AGE=/vmlinuz-6.1
    342e 302d 3333 2d67 656e 6572 6963 0064  4.0-33-generic.d
    726f 705f 6361 7073 3d00 5041 5448 3d2f  rop_caps= PATH=/
    7573 722f 6c6f 6361 6c2f 7362 696e 3a2f  usr/local/sbin:/
    7573 722f 6c6f 6361 6c2f 6269 6e3a 2f75  usr/local/bin:/u
    7372 2f73 6269 6e3a 2f75 7372 2f62 696e  sr/sbin:/usr/bin
    3a2f 7362 696e 3a2f 6269 6e00 5057 443d  :/sbin:/bin PWD=
    2f00 726f 6f74 6d6e 743d 2f72 6f6f 7400  / rootmnt=/root

이 정적 레이아웃은 수정이나 확장이 쉽지 않다. 프로그램은 이 변수들을 자기 데이터 구조로 복사해야 한다. Bash, C, Python이 내부적으로 환경 변수를 어떻게 저장하는지 한번 보자. 소스 코드를 분석해봤고, 요약하면 이렇다.

Bash

해시맵에 변수를 저장한다. 좀 더 정확히 말하자면, 해시맵 스택 구조로 관리한다.

Bash로 새 프로세스를 띄우면, 해시맵 스택을 순회하면서 export 표시가 된 변수들을 찾아서 자식 프로세스에 넘길 환경 배열로 복사한다.

참고: 스택 순회가 왜 필요할까?
Bash에서 함수를 호출할 때마다 새로운 로컬 스코프가 만들어진다. 스택에 새 항목이 쌓이는 것이다. local로 변수를 선언하면 이 로컬 스코프 해시맵에 담긴다.
재미있는 건 local 변수도 export할 수 있다는 점이다!
function locallyScoped() {
    local PATH="$PATH:/opt/secret/bin"
    export PATH
    env           # <- /opt/secret/bin이 추가된 PATH를 본다
}


locallyScoped
env               # <- 원래 PATH를 본다
Bash 소스를 파헤치지 않았다면 몰랐을 것이다. 내 직관(틀렸지만)은 export가 변수를 자동으로 전역으로 만든다는 거였다, declare -g처럼! 꽤 흥미롭다.

Linux의 기본 C 라이브러리: `glibc`

glibc는 동적 environ 배열을 제공하고, putenv와 getenv 함수로 관리한다. 배열 구조라서 getenv와 putenv의 시간 복잡도는 환경 변수 개수에 선형이다. 기억하라, 환경 변수는 고성능 딕셔너리가 아니니 남용하지 마라.

Python

Python은 환경을 C 라이브러리에 연결해서 사용하는데, 이 때문에 예상치 못한 불일치가 생길 수 있다.

Python을 좀 해봤다면 os.environ 딕셔너리를 써봤을 것이다. 시작할 때 os.environ은 C 라이브러리의 environ 배열로부터 만들어진다.

하지만 이 딕셔너리 값들이 자식 프로세스의 "실제 원본(ground truth)"은 아니다. 실제로는 os.environ을 변경할 때마다 네이티브 os.putenv 함수가 호출되고, 이게 다시 C 라이브러리의 putenv를 호출한다.

전파는 단방향이다: os.environ 수정은 os.putenv를 호출하지만, 반대는 아니다. os.putenv를 호출해도 os.environ은 업데이트되지 않는다.

자유로운 형식

Linux 커널은 환경 변수 형식에 매우 관대하고, glibc도 마찬가지다.

예를 들어 C 프로그램이 환경(전역 environ 배열)을 조작해서 같은 이름에 다른 값을 가진 변수 여러 개를 만들 수 있다. 자식 프로세스를 실행하면 이 "깨진" 구성을 그대로 상속한다.

이름과 값을 구분하는 등호조차 필요 없다! 일반적인 항목은 NAME=VALUE지만, 배열에 NONSENSE_WITH_EMOJI 😀를 추가하는 것도 막을 수 없다.

커널은 null로 끝나는 어떤 문자열이든 "환경 변수" 정의로 기꺼이 받아들인다. 단지 크기 제한만 둘 뿐이다:

단일 변수: 일반적인 x64 Intel CPU에서 128 KiB다. 전체 정의(이름 + 등호 + 값)에 대한 크기다. PAGE_SIZE * 32로 계산된다. 최신 하드웨어는 4 KiB보다 작은 페이지를 쓰지 않으므로, 레거시 임베디드 시스템을 다뤄야 하는 게 아니라면 하한선으로 봐도 된다.
전체 용량: 일반적인 머신에서 2 MiB다. 이 제한은 환경 변수와 커맨드라인 인자가 함께 쓴다. 계산은 좀 더 복잡하다 (execve(2) man 페이지 참조):
max(32 * PAGE_SIZE, min(MAX_STACK_SIZE / 4, 6 MB))
일반적인 시스템에선 MAX_STACK_SIZE가 제한 요소다. 초기에 환경 변수들이 스택에 덤프된다는 걸 기억하라! 예측 불가능한 크래시를 막기 위해 시스템은 스택의 1/4만 환경 변수에 허용한다.

특이사항들

무언가를 할 수 있다는 사실이 그것을 해야 한다는 의미는 아니다. 예를 들어 "깨진" 환경(중복 이름과 = 없는 항목들)으로 Bash를 시작하면, Bash는 중복 변수를 정리하고 형식이 맞지 않는 항목을 걸러낸다.

흥미로운 엣지 케이스 하나는 변수명 안에 공백이 있는 경우다. 내가 사랑하는 쉘 Nushell은 다음 할당에 아무 문제가 없다:

$env."Deployment Environment" = "prod"

Python도 괜찮다. 반면 Bash는 변수명에 공백이 허용되지 않아 참조할 수 없다. 다행히 변수가 사라지진 않는다. Bash는 이런 항목들을 invalid_env라는 특수 해시맵에 보관하고 자식 프로세스에 여전히 전달한다.

표준 형식

그럼 환경 변수에 어떤 이름과 값을 안전하게 쓸 수 있을까? StackOverflow와 ChatGPT가 되풀이하는 흔한 오해가 있다: POSIX는 대문자 환경 변수만 허용하고 나머지는 표준 밖이라는 것.

하지만 표준의 실제 내용은 전혀 다르다:

이 문자열들은 name=value 형식을 가진다. name에는 '=' 문자가 포함되면 안 된다. POSIX.1-2017을 준수하는 시스템 간 이식성을 위해서는, 값은 portable character set의 문자로 구성되어야 한다(NUL과 아래 표시된 것 제외). 환경 내 문자열 순서에 특별한 의미는 없다. 프로세스 환경에서 같은 이름을 가진 문자열이 둘 이상이면, 결과는 미정의다.
POSIX.1-2017의 Shell and Utilities volume에서 유틸리티들이 사용하는 환경 변수 이름은 Portable Character Set에 정의된 대문자, 숫자, 밑줄('_')로만 구성되며 숫자로 시작하지 않는다. 구현체가 다른 문자를 허용할 수도 있다. 애플리케이션은 그런 이름의 존재를 허용해야 한다. 대소문자는 구별되며 섞이지 않는다. 소문자를 포함한 환경 변수명 공간은 애플리케이션용으로 예약되어 있다. 애플리케이션은 이 네임스페이스로 환경 변수를 자유롭게 정의할 수 있으며, 표준 유틸리티 동작에 영향을 주지 않는다.

맞다, POSIX가 명시한 유틸리티들은 대문자 환경 변수를 쓴다. 하지만 이건 당신 프로그램에 대한 규정이 아니다. 오히려 반대다: 표준 도구들과 충돌하지 않도록 소문자를 쓰는 게 권장된다.

엄격한 규칙은 단 하나: 변수 이름에 등호를 포함할 수 없다. POSIX 호환 애플리케이션은 이 규칙에 맞는 모든 변수를 보존해야 한다.

하지만 실제로는 소문자를 쓰는 애플리케이션이 많지 않다. 소프트웨어 개발의 올바른 에티켓은 ALL_UPPERCASE를 쓰는 것이다.

내 실용적인 권장사항은…

이름에는 ^[A-Z_][A-Z0-9_]*$ 패턴을, 값에는 UTF-8을 쓰는 것이다. Linux에선 문제없을 것이다. 극도로 안전하게 가려면: UTF-8 대신 POSIX가 요구하는 Portable Character Set(PCS)을 써라. 제어 문자를 뺀 ASCII라고 보면 된다.

내 RSS 피드를 구독해주세요! 😇

독립 블로깅은 RSS 없이는 불가능합니다. 오늘부터 RSS를 사용하세요.

와, 이거 정말 재밌게 썼는데…

…지루한 글은 아니었길 바랍니다.

[CODE/env] 환경 변수는 레거시 난장판이다: 깊이 파헤쳐보자