L4 OS/Linux 입구
L4 OS/Linux 입구
섹션 제목: “L4 OS/Linux 입구”분류: Layer 4 - OS/Linux
1. 이 레이어는 무엇을 가능하게 하나
섹션 제목: “1. 이 레이어는 무엇을 가능하게 하나”L4는 “서버가 내 코드를 어떻게 실행하고, 보호하고, 제한하는가”를 보는 레이어다.
프론트엔드나 Node.js 개발을 하다 보면 이미 OS를 계속 만난다. dev server가 포트를 열고, 터미널에 로그가 찍히고, node 프로세스가 떠 있고, 파일 경로 하나가 틀려서 배포가 실패한다. Docker 컨테이너 안에서 앱이 죽거나, ECS 태스크가 OOMKilled로 재시작되는 일도 결국 OS가 프로세스와 자원을 다루는 방식과 연결된다.
이 레이어의 목표는 커널 구현자가 되는 것이 아니다. 장애나 성능 문제를 만났을 때 “이건 코드 버그인가, 프로세스 문제인가, 파일/권한 문제인가, 메모리 한도 문제인가, 스케줄링 문제인가, 격리 설정 문제인가”를 나눠서 볼 수 있게 되는 것이다.
2. 이미 알고 있는 것에서 출발하기
섹션 제목: “2. 이미 알고 있는 것에서 출발하기”React나 React Native 경험에서 가져와도 되는 직관이 있다.
- 컴포넌트는 자기 상태와 생명주기를 가진다. 프로세스도 실행 중인 프로그램의 생명주기와 자원 상태를 가진다.
- 이벤트 핸들러는 직접 모든 일을 하지 않고 런타임과 브라우저에 많은 일을 맡긴다. Node.js 앱도 파일 읽기, 네트워크 송수신, 타이머 처리를 커널과 libuv에 맡긴다.
- dev server가
localhost:3000을 점유하면 다른 서버가 같은 포트를 못 쓴다. 포트는 프로세스가 커널에서 빌려 쓰는 네트워크 자원이다. - 빌드 산출물 경로나 환경변수가 틀리면 앱은 시작하지 못한다. 서버에서도 파일 경로, 권한, 환경변수는 실행의 기본 조건이다.
- 배포 컨테이너는 “작은 서버”처럼 보이지만, 실제로는 Linux 커널이 프로세스의 시야와 자원 사용량을 제한한 결과다.
이 직관을 버릴 필요는 없다. 다만 L4에서는 관찰 대상을 앱 내부의 함수 호출에서 OS가 제공하는 실행 환경으로 한 단계 낮춘다.
3. 새로 배워야 하는 사고 모델
섹션 제목: “3. 새로 배워야 하는 사고 모델”이 레이어를 읽을 때는 명령어 목록보다 아래 렌즈를 먼저 잡는 편이 좋다.
| 렌즈 | 핵심 질문 | 실무에서 보이는 모습 |
|---|---|---|
| 프로세스 | 지금 무엇이 실행 중인가 | node dist/main.js, PM2 worker, ECS task |
| 파일 | 데이터와 설정은 어디에 놓였는가 | 로그, .env, 업로드 파일, /proc |
| 권한 | 누가 읽고 쓰고 실행할 수 있는가 | Permission denied, root 실행, SSH 접근 |
| 커널/유저 공간 | 앱이 직접 못 하는 일은 어디로 요청하는가 | fs.readFile, HTTP socket, Too many open files |
| 메모리 | 프로세스는 어디까지 메모리를 쓸 수 있는가 | Node heap 증가, Docker OOMKilled, Redis 메모리 정책 |
| 스케줄링 | 제한된 CPU를 누가 언제 쓰는가 | 이벤트 루프 지연, Worker 수, context switching |
| 격리 | 한 프로세스나 컨테이너의 문제가 어디까지 퍼지는가 | 컨테이너 limit, namespace, cgroups |
처음부터 task_struct, MMU, TLB, Ring 0 같은 용어를 완벽히 이해하려고 하면 진입이 무거워진다. 먼저 “OS는 실행 단위와 자원 경계를 관리한다”는 큰 그림을 잡고, 각 토픽에서 필요한 내부 구조를 하나씩 붙이면 된다.
4. 들어가기 전 최소 선수지식
섹션 제목: “4. 들어가기 전 최소 선수지식”- 터미널에서 현재 위치와 파일 경로를 읽을 수 있으면 충분하다. 절대경로와 상대경로가 헷갈리면
content/topics/L4/linux-basics.md의 파일 시스템과 경로 부분으로 돌아간다. - Node.js 서버가 하나의 실행 중인 프로세스라는 감각이 있으면 좋다. 이벤트 루프와 비동기 I/O가 낯설면
content/topics/L0/nodejs-event-loop.md를 먼저 본다. - HTTP 요청이 네트워크를 통해 서버 프로세스에 도착한다는 그림이 필요하다. TCP/UDP나 포트가 막히면
content/topics/L2/tcp-udp-internals.md를 참고한다. - 컨테이너나 ECS가 익숙하지 않다면 깊게 파고들기보다 “격리된 실행 환경” 정도로만 잡고 시작한다. 필요할 때
content/topics/L5/docker-basics.md와content/topics/L3/ecs-vs-ec2.md를 참고하면 된다.
5. 이 레이어를 듣는 순서
섹션 제목: “5. 이 레이어를 듣는 순서”content/topics/L4/linux-basics.md- 서버를 만질 때 보이는 파일, 로그, 권한, 프로세스, 환경변수의 표면을 잡는다.content/topics/L4/process-thread.md- Node 프로세스, worker, ECS task처럼 “실행 단위”가 어떻게 격리되고 병렬화되는지 본다.content/topics/L4/system-call-interrupt.md- 앱이 파일과 네트워크를 직접 만지는 것이 아니라 커널에 요청한다는 경계를 이해한다.content/topics/L4/memory-management.md- 프로세스 메모리, 가상 메모리, OOM, 캐시 정책을 연결한다.content/topics/L4/cpu-scheduling.md- CPU가 여러 작업 사이에서 어떻게 시간을 나누는지 보고 이벤트 루프 지연과 Worker 수 판단으로 연결한다.content/topics/L4/concurrency-sync.md- 여러 실행 흐름이 같은 자원을 건드릴 때 왜 race condition과 lock이 필요한지 본다.content/topics/L4/cgroups-namespace.md- Docker와 Kubernetes의 컨테이너 격리가 Linux 커널 기능 위에 있다는 사실을 정리한다.
처음 네 문서는 L4의 뼈대다. 뒤의 세 문서는 그 뼈대를 성능, 동시성, 컨테이너 운영으로 확장한다.
6. 어렵게 느껴지는 지점과 돌아갈 곳
섹션 제목: “6. 어렵게 느껴지는 지점과 돌아갈 곳”| 막히는 느낌 | 보통 부족한 전제 | 돌아갈 문서 |
|---|---|---|
ps, chmod, /var/log 같은 말이 한꺼번에 나온다 | 파일 경로, 권한, CLI 표면 | content/topics/L4/linux-basics.md |
| Node.js가 싱글 스레드라는데 worker와 cluster가 헷갈린다 | 이벤트 루프와 실행 단위 구분 | content/topics/L0/nodejs-event-loop.md, content/topics/L4/process-thread.md |
| 시스템 콜이 왜 필요한지 감이 안 온다 | 앱과 커널의 권한 경계 | content/topics/L4/system-call-interrupt.md |
| OOM, heap, RSS, swap이 섞여 보인다 | OS 메모리와 V8 힙의 층위 구분 | content/topics/L4/memory-management.md |
| CPU 사용률은 낮은데 응답이 느린 상황이 이해되지 않는다 | 대기, 스케줄링, I/O 지연 구분 | content/topics/L4/cpu-scheduling.md, content/topics/L6/logs-metrics-traces.md |
| 컨테이너가 왜 host와 다르게 보이는지 모르겠다 | Linux 격리와 자원 제한 | content/topics/L4/cgroups-namespace.md, content/topics/L5/docker-basics.md |
| 포트, 연결, 패킷 이야기가 OS 문서 안에서 튀어나온다 | TCP 연결과 소켓 감각 | content/topics/L2/tcp-udp-internals.md |
막히는 것은 정상이다. L4는 여러 레이어의 바닥을 받치는 영역이라 한 번에 매끈하게 지나가기 어렵다. 대신 막힐 때마다 “나는 지금 파일을 모르는가, 프로세스를 모르는가, 권한 경계를 모르는가, 메모리를 모르는가”처럼 부족한 전제를 좁히면 된다.
7. 들을 준비가 된 상태
섹션 제목: “7. 들을 준비가 된 상태”- 로컬 dev server도 OS 입장에서는 하나의 프로세스라고 설명할 수 있다.
- 포트 충돌이 “두 프로세스가 같은 네트워크 자원을 쓰려는 상황”이라는 것을 이해한다.
- 파일 경로, 권한, 환경변수 문제가 서버 실행 실패로 이어질 수 있음을 안다.
- 앱 코드가 파일, 네트워크, 메모리 같은 자원에 접근할 때 커널을 거친다는 그림을 받아들일 수 있다.
-
OOMKilled,Permission denied,Too many open files같은 에러를 보면 어느 L4 문서로 돌아갈지 고를 수 있다. - Docker 컨테이너가 별도 OS가 아니라 Linux 커널의 격리 기능 위에서 실행된다는 말을 낯설지만 받아들일 수 있다.
8. 이 레이어의 핵심 한 문장
섹션 제목: “8. 이 레이어의 핵심 한 문장”OS/Linux는 서버 코드 아래에서 프로세스, 파일, 권한, 메모리, CPU, 격리 경계를 제공하는 실행 기반이다.
L4를 지나고 나면 “서버가 죽었다”는 말을 더 작게 쪼갤 수 있다. 프로세스가 종료된 것인지, 포트나 파일 디스크립터가 부족한 것인지, 권한이 막힌 것인지, 메모리 한도를 넘은 것인지, CPU 스케줄링이나 동시성 문제가 생긴 것인지 구분하는 힘이 생긴다.