[식당 개업으로 이해하는 OS의 원리 1/4] SSD의 프로그램이 프로세스가 되기까지

들어가는 글: 면접장 밖에서 다시 만난 CS 전공 지식

우리는 면접을 위해 '프로세스'와 '스레드', '시스템 콜'의 정의를 달달 외웠습니다. 하지만 실무에 치여 살다 보면 이 지식들은 자연스럽게 흐릿해지곤 합니다. "그냥 실행하면 되는 거 아니야?"라고 생각하기 쉽지만, 서버의 초기 응답 속도(Latency) 문제나 간헐적인 I/O 병목 현상을 해결하려면 결국 이 '기초 체력'이 다시 필요해지는 순간이 반드시 옵니다.

이 글에서는 복잡한 전공 서적의 용어 대신, '식당 개업'에 비유하여 SSD에 잠들어 있던 정적인 프로그램(Program)이 어떻게 메모리 위에서 살아 움직이는 프로세스(Process)로 변신하는지 그 여정을 시니어의 관점에서 다시 정리해 봅니다.

개념 잡기: Program(레시피) vs Process(영업 중인 식당)

분주한 식당 주방 내부와 요리사들, 운영체제의 프로세스와 스레드 구조 비유 (Photo by Khachik Simonian on Unsplash) — Process는 가게이고, Thread는 직원을 위한 작업지시서이다. (Photo by Khachik Simonian on Unsplash)

본격적인 이야기 전에, 용어부터 정리해 봅시다. 여러분이 대형 마트(SSD)에서 '식당 창업 키트'를 발견했다고 상상해 보세요. 이 상자 안에는 인테리어 도면, 레시피 북, 식기 세트가 들어 있습니다.

Program (창업 키트): SSD에 저장된 코드 덩어리입니다. 설계도와 레시피는 있지만, 스스로 요리를 하거나 움직일 수는 없는 수동적인 존재(Passive Entity)입니다.

Process (영업 중인 식당): 이 키트를 가져와서 실제로 건물을 빌리고(메모리 할당), 셰프(CPU)를 고용해서 요리를 시작한 능동적인 상태(Active Entity)입니다.

우리가 "프로그램을 실행한다"는 것은, 마트 진열대에 있는 창업 키트(Program)를 가져와 실제 매장(Process)을 차리는 과정을 의미합니다. 이 과정은 절대 혼자서 할 수 없으며, 건물주이자 관리자인 OS(운영체제)의 허락과 도움이 절대적으로 필요합니다.(리눅스 OS 를 기준으로 설명했습니다)

Step 1: 실행 요청과 시스템 콜 (User Space -> Kernel Space)

사용자가 아이콘을 더블 클릭하거나 쉘에서 명령어를 입력하는 순간, OS에게 "식당 하나 차려주세요!"라는 요청이 전달됩니다. 이때 가장 먼저 일어나는 일이 바로 fork()와 exec()입니다.

"새로 식당을 여는데, 왜 옆집 사장님을 복제(fork)하나요?"

맨땅에 헤딩하며 식당을 차리는 건 너무 힘듭니다. 수도는 어디에 연결하고, 가스 배관은 어떻게 뚫어야 하는지 처음부터 다시 배우는 것보다, 이미 영업 중인 옆집 식당(부모 프로세스, 예: Shell)의 구조를 그대로 본떠서 2호점을 내는 게 훨씬 빠르기 때문입니다.

Fork (복제): 기존 사장님(부모)이 관리자(OS/Kernel)에게 요청합니다. "제 가게랑 똑같은 구조로 2호점 하나 내주세요." 관리자는 부모의 정보(환경변수, 권한 등)를 복사해 새로운 사업자 등록증(PID)과 장부(PCB)를 만들어 줍니다.

Exec (변신): 이제 2호점이 생겼습니다. 하지만 메뉴까지 본점과 똑같으면 안 되겠죠? execve() 시스템 콜을 통해 2호점의 인테리어를 싹 뜯어고치고, 우리가 마트에서 사 온 '창업 키트(새로운 프로그램)'로 내용을 채워 넣습니다.

이 방식(fork 후 exec)은 다음과 같은 이점이 있습니다.
Isolation (격리): 2호점이 망한다고 본점이 망하지 않습니다. 각자 독립된 공간을 가집니다.
Inheritance (상속): 권한이나 환경 설정 등 복잡한 세팅을 부모로부터 쉽게 물려받습니다.

💡 Tech Insight: 브라우저는 왜 메모리를 미친 듯이 잡아먹을까?

(부제: 멀티 스레드 대신 멀티 프로세스를 택한 이유)

Chrome이나 Safari 같은 현대 브라우저들이 "메모리 괴물"이 된 이유는 개발자들이 최적화를 못 해서가 아닙니다. 사용자의 안전과 경험을 위해 의도적으로 '멀티 프로세스 아키텍처(Multi-process Architecture)'를 채택했기 때문입니다.

스레드(Thread)를 사용하면 메모리를 공유하여 훨씬 가볍게 만들 수 있지만, 브라우저는 비용(RAM)을 지불하고 다음과 같은 강력한 이점을 얻었습니다.

1. 안정성 (Fault Tolerance) 브라우저는 탭마다 별도의 Renderer Process를 생성합니다. 만약 멀티 스레드 방식이었다면, 하나의 탭에서 스크립트 오류가 발생했을 때 프로세스 전체가 종료되어 모든 탭이 꺼졌을 것입니다. 반면 멀티 프로세스 구조에서는 오류가 발생한 해당 탭의 프로세스만 종료되므로, 브라우저 전체나 다른 탭에는 영향을 주지 않습니다.

2. 보안 (Security & Sandboxing) 프로세스는 운영체제로부터 독립된 가상 메모리 공간(Virtual Address Space)을 할당받습니다. 이를 통해 철저한 샌드박스(Sandbox) 환경을 구축할 수 있습니다. 예를 들어, 악성 코드가 포함된 사이트에 접속하더라도 해당 프로세스는 물리적으로 격리되어 있으므로, 옆 탭에 열려 있는 이메일이나 금융 사이트의 메모리 영역을 훔쳐보는 것(Memory Scraping)이 불가능합니다.

3. 반응성 (Responsiveness & UX) 브라우저의 UI(주소창, 뒤로 가기 등)를 담당하는 Browser Process와 실제 웹페이지를 그리는 Renderer Process가 분리되어 있습니다. 특정 사이트에서 고사양 3D 게임이나 복잡한 연산을 수행하느라 렌더링 엔진이 멈추더라도(Blocking), UI 프로세스는 별개로 작동하기 때문에 사용자는 탭을 닫거나 다른 주소를 입력하는 등 브라우저를 계속 제어할 수 있습니다.

결론: 우리가 잃어버린 RAM은 "절대 꺼지지 않는 안정성"과 "해킹 당하지 않는 보안"을 구매하는 데 사용된 셈입니다.

Step 2: 파일 시스템과 I/O 요청 (Kernel -> Storage Hardware)

파일 시스템과 I/O 요청 과정 다이어그램: 셰프(CPU)가 재고장부(VFS)를 확인하고 호출벨(Doorbell)을 눌러 창고관리인(SSD 컨트롤러)에게 주문서(NVMe Command)를 전달하는 모습 — Step 2: 파일 시스템과 I/O 요청 (Kernel -> Storage Hardware)

이제 execve()가 호출되어 커널 모드로 진입했습니다. 셰프(CPU)가 직접 마트(SSD)로 뛰어가서 재료를 사올까요? 아닙니다. 시급 비싼 셰프는 주방을 비우면 안 됩니다. 대신 관리 시스템을 통해 '발주'를 넣습니다.

VFS(Virtual File System) & Inode (재고 파악): 커널은 먼저 파일 시스템이라는 '재고 장부'를 확인합니다. 파일의 메타데이터인 Inode를 통해 권한을 체크하고, 이 재료가 창고의 어느 구역(LBA, 논리 블록 주소)에 있는지 확인합니다.

지금 가입하고, 시니어 개발자로 도약하기 위한 깊이 있는 인사이트를 놓치지 마세요.

🛠️ 깊이 있는 기술 Deep Dive: 겉핥기식이 아닌, 원리부터 파고드는 수준 높은 아티클을 제공합니다. (OS, 네트워크, DB 등)

💡 실무 인사이트: 교과서엔 없는 현장 경험과 실제 트러블슈팅 사례를 통한 난제 해결 팁을 공유합니다.

🚀 커리어 성장 치트키: 아키텍처 설계, 성능 최적화 등 필수 역량을 키울 수 있는 콘텐츠를 받아보세요.

📮 가장 빠른 새 글 알림: 새로운 인사이트가 담긴 글이 발행되면 이메일로 편하게 받아보실 수 있습니다.

이미 회원이신가요?

Block Layer (주문서 작성): 커널은 바쁩니다. 그래서 재료를 갖고 오는 것은 창고 관리인에게 위임합니다. 커널은 창고 관리인(SSD 컨트롤러)이 알아볼 수 있는 표준 주문서(NVMe Command)를 작성합니다. 이때 I/O 스케줄러가 개입하여 여러 주문을 효율적인 순서로 정렬하기도 합니다.

Submission Queue & Doorbell (벨 누르기): 커널은 작성된 주문서를 창고로 연결된 '주문 레일(Submission Queue)'에 꽂아두고, '호출 벨(Doorbell Register)'을 띵동! 하고 누릅니다. "자, 주문 들어갔으니 확인하세요!"라고 SSD에게 알리는 것입니다.

Step 3: 데이터 전송과 DMA (Hardware -> Memory)

벨 소리를 들은 창고(SSD) 내부에서는 어떤 일이 벌어질까요?

FTL (똑똑한 창고지기): SSD에는 FTL(Flash Translation Layer)이라는 천재적인 창고지기가 있습니다. 이 친구는 "LBA 100번 가져와"라는 주문을 보고, 자기만 아는 비밀 지도를 통해 실제 낸드 플래시의 물리적 위치(PBA)를 찾아냅니다.

DMA (직통 컨베이어 벨트): 재료를 찾았다고 해서 셰프(CPU)를 오라고 하지 않습니다. 창고지기는 DMA(Direct Memory Access)라는 직통 컨베이어 벨트를 통해 주방의 지정된 선반(RAM의 Page Cache)으로 재료를 쏩니다. 셰프(CPU)의 손을 전혀 빌리지 않고 말이죠.

Interrupt (배달 완료 알림): 배달이 끝나면 창고지기는 완료 장부(Completion Queue)에 서명하고, 인터럽트(MSI-X)를 통해 셰프에게 알립니다. "셰프님! 주문하신 재료 주방 선반에 도착했습니다!"

Step 4: 메모리 매핑과 실행 (Memory Management & Execution)

재료가 도착했으니 이제 요리를 시작할 수 있을까요? 아직 마지막 단계, '오픈 준비'가 남았습니다.

Release Resources (청소): exec을 했으니, 기존에 복제했던 부모의 기억(메모리 맵)을 깨끗이 지웁니다. 이제 프로세스는 PID(간판)만 남고 내부는 텅 빈 상태가 됩니다.

Load Binary (설계도 확인): 리눅스 실행 파일 형식인 ELF(Executable and Linkable Format) 헤더를 읽습니다. "주방은 어디에 배치하고, 식자재는 어디에 둬라"는 설계도를 확인합니다.

Memory Mapping (Lazy Loading - 핵심!): 여기서 중요한 점은, 설계도를 보자마자 모든 짐을 다 풀지 않는다는 것입니다.

커널은 "필요하면 창고(SSD) 어디에서 가져오면 된다" 라는 연결 고리(Mapping)만 페이지 테이블에 적어둡니다.

실제 데이터 로딩은 나중에 셰프가 그 재료를 찾을 때(Page Fault 발생 시) 그때그때 가져옵니다. 이를 Lazy Loading(지연 로딩)이라고 하며, 덕분에 거대한 프로그램도 빠르게 실행될 수 있습니다.

PC 갱신 (영업 개시): 모든 준비가 끝났습니다. 커널은 셰프(CPU)의 작업 지시표(Program Counter)를 새로운 프로그램의 시작점(Entry Point, _start)으로 바꿔치기합니다.

이제 셰프가 눈을 뜨면, 완전히 새로운 레시피로 요리를 시작하게 됩니다. 이것이 바로 프로세스의 탄생입니다.

💡 Tech Insight: execve()를 해도 살아남는 것들 (feat. 쉘의 마법)

execve()가 호출되면 프로세스의 메모리(Text, Data, Heap, Stack)는 완전히 새로운 프로그램으로 덮어씌워지며 '환골탈태'합니다. 하지만, 운영체제 커널이 관리하는 PCB(Process Control Block)의 일부 핵심 정보는 의도적으로 유지됩니다.

이 "유지되는 정보"들이 유닉스(Unix) 철학이 담긴 파이프라인(|)과 리다이렉션(>)이 작동하는 원리이자, 서버 개발자가 주의해야 할 포인트입니다.

1. 파일 디스크립터 (File Descriptors) - 가장 중요! 부모 프로세스가 열어둔 파일, 소켓, 파이프는 exec 이후에도 그대로 유지됩니다.

Why? 쉘이 ls > log.txt를 실행할 때, fork() 후 자식 프로세스에서 log.txt를 열어 표준 출력(fd 1)으로 연결(dup2)해둡니다. 그 후 exec("ls")를 하면, ls 프로그램은 자기가 화면에 출력하는지 파일에 쓰는지 모른 채 그냥 fd 1에 데이터를 씁니다. 만약 exec 시 fd가 초기화된다면 이런 리다이렉션은 불가능했을 것입니다.

Caution: 의도치 않게 부모의 DB 커넥션이나 소켓이 자식에게 상속되어, "자식 프로세스가 죽지 않아서 포트가 안 닫히는 좀비 소켓 문제"가 발생할 수 있습니다. 이를 막기 위해 open() 시 O_CLOEXEC (Close-on-Exec) 플래그를 사용하는 것이 시니어의 기본 소양입니다.

2. 시그널 마스크와 무시된 시그널 (Signal Mask & Ignored Signals)

Reset: 커스텀하게 등록한 시그널 핸들러(Handler)는 당연히 초기화됩니다. (핸들러 함수 코드가 메모리에서 사라졌으니까요.)
❓ "커스텀 시그널 핸들러"란, 운영체제가 보내는 특정 신호(Signal)를 받았을 때, 기본적으로 정해진 행동(Default Action)을 하지 않고 개발자가 미리 짜놓은 특정 함수(코드)를 실행하도록 가로채는 것

Preserve: 하지만 "이 시그널은 무시해(SIG_IGN)"라는 설정과 "잠시 막아둬(Signal Mask)"라는 상태는 유지됩니다. 이를 통해 데몬 프로세스 등을 띄울 때 초기 시그널 정책을 제어할 수 있습니다.

3. 프로세스 식별자와 그룹 정보 (PID, PPID, UID, GID) 주민등록번호(PID)와 부모가 누구인지(PPID), 그리고 이 프로세스를 실행한 유저(Real UID)가 누구인지는 변하지 않습니다.

단, SetUID 비트가 설정된 파일(예: passwd)을 exec 할 경우, Effective UID가 파일 소유자(root)로 격상되어 권한 상승이 일어납니다. 이것이 sudo가 작동하는 기본 원리입니다.

4. 현재 작업 디렉토리 (CWD) exec을 해도 "현재 어느 폴더에 있는지"는 변하지 않습니다. 그래서 쉘에서 cd로 이동한 뒤 프로그램을 실행하면 그 폴더 기준으로 동작하는 것입니다.

요약: execve()는 건물을 부수고 다시 짓는 것이 아니라, "건물 주소(PID)와 수도/가스 배관(File Descriptor)은 그대로 둔 채, 내부 인테리어(Memory)만 싹 바꾸는 리모델링"입니다.

[실전] 이론을 실무에 적용하기

우리가 지금까지 커널과 하드웨어의 깊은 곳을 들여다본 이유는 단순히 지적 호기심 때문만이 아닙니다. 이 지식들은 서버에서 발생하는 원인 불명의 성능 저하를 진단하는 강력한 도구가 되기 때문입니다.

1. 배포 직후 첫 API 응답 속도가 튀는 현상 (Latency Spike)

증상: 서버를 새로 띄우고 첫 요청을 보내면 2~3초가 걸리는데, 두 번째부터는 50ms로 빨라집니다.
원인: execve()는 메모리에 코드를 다 올리지 않습니다(Lazy Loading). 첫 요청이 들어와서 코드를 실행하려는 순간, CPU가 "어? 메모리에 없네?" 하고 Page Fault를 일으키며 SSD에서 데이터를 가져오는 I/O 시간이 포함된 것입니다.
해결: 로드 밸런서 연결 전, API를 몇 번 호출해 주는 Warm-up Script를 실행해 미리 물리 메모리(Page Cache)에 코드를 적재하면 어느정도 해결할 수 있습니다.

2. 컨테이너 메모리 사용량이 계속 늘어나는 현상 (Memory Leak 의심)

증상: 프로세스당 100MB로 계산했는데, 운영하다 보니 메모리가 계속 늘어나 OOM(Out Of Memory)이 발생합니다.
원인: 초기에는 부모-자식 프로세스가 메모리를 공유(Copy-on-Write)하지만, 앱이 실행되면서 데이터를 쓰기(Write) 시작하면 공유가 깨지고 각자 메모리를 차지하게 됩니다.
해결: 단순 가상 메모리가 아닌 pmap -x 명령어로 RSS(실사용 물리 메모리)와 Shared Memory 비율을 확인하고, Gunicorn 등에서는 앱 로딩을 부모 단계에서 미리 하도록 설정(preload)하여 CoW 효과를 극대화해야 합니다.

3. 대용량 트래픽 상황에서 I/O 병목이 발생하는 이유 (High Load Average)

증상: top을 보면 CPU 사용률(User%)은 10% 미만인데, 가끔씩 Load Average는 50 이상으로 치솟습니다.
원인: 범인은 Block Layer입니다. 디스크 처리 속도가 요청을 따라가지 못해, 수많은 프로세스가 "SSD가 응답 줄 때까지 꼼짝 안 해(D state)"라며 누워버린 상태입니다.
해결: CPU를 늘릴 게 아니라 iostat으로 Disk IOPS를 확인하세요. 동기식 파일 쓰기를 비동기(Async)로 바꾸거나, 로그를 모아서 한 번에 쓰는(Batch) 방식으로 I/O 패턴을 튜닝해야 합니다.

마치며: 코드를 넘어 시스템을 보는 눈

우리는 지금까지 SSD에 잠들어 있던 '창업 키트(Program)'가, 커널이라는 관리자의 도움을 받아 뜨거운 열기가 가득한 '영업 중인 식당(Process)'으로 변모하는 과정을 살펴봤습니다.

우리가 단순히 IDE에서 'Run' 버튼을 누르거나 터미널에 명령어를 입력하는 그 짧은 찰나의 순간에, 운영체제는 VFS로 장부를 확인하고, NVMe로 발주를 넣고, DMA로 배달을 시키며, Lazy Loading으로 효율을 극대화하고 있었습니다.

이 복잡한 과정을 이해하는 것은 단순히 CS 지식을 뽐내기 위함이 아닙니다. 서버의 초기 응답 속도(Latency)가 왜 튀는지, 왜 컨테이너(Container)의 메모리 사용량이 예상과 다른지, 혹은 대용량 트래픽 상황에서 왜 I/O 병목이 발생하는지를 파악하기 위한 '진단 도구'를 갖추기 위함입니다.

이제 여러분의 눈에는 execve()가 단순한 함수 호출이 아닌, 시스템의 자원을 재배치하고 새로운 생명을 불어넣는 거대한 오케스트라의 지휘로 보일 것입니다. 이 글이 여러분이 마주할 난해한 성능 이슈들을 해결하는 데 있어 든든한 나침반이 되기를 바랍니다.