Home

발표 스크립트 — index.html (통합본)

boostStudy/index.html 기준 화면 카운터 1 ~ 22장입니다. data-slide는 0 ~ 21, 카운터 N = data-slide (N−1).

• 앞부분: 슬라이드별 짧은 대본 (현장용).
• 부록 B·C: 같은 슬라이드에 대응하는 긴 연습 대본 (스케줄링 57장, 페이지 교체 1416장).

---

슬라이드 1 — 표지

안녕하세요. 오늘은 운영체제에서 자주 나오는 세 가지 축—CPU 스케줄링, 가상 메모리, 파일 시스템—을 한 번에 잡아 보겠습니다.
세부 스펙보다는 각 파트가 어떤 문제를 풀기 위해 존재하는지, 문제와 해결 순서로 가져가겠습니다.

---

슬라이드 2 — Part 1 도입 · CPU를 누구에게?

첫 번째 주제는 누구에게 CPU를 줄 것인가입니다. CPU는 보통 한 코어당 한 순간에 하나의 일만 하니까, 여러 프로세스가 있을 때 줄을 어떻게 설 것인지가 전부예요.
여기서 동시에 챙기려는 건 응답이 빨라 보이게 할 것인가, 공평하게 돌릴 것인가 같은 정책 선택입니다.

---

슬라이드 3 — 스케줄링 큐와 우선순위

프로세스는 대기 상태에 따라 큐에 들어갑니다. CPU만 기다리면 준비 큐, 디스크 I/O처럼 CPU를 당장 못 쓰면 대기 큐에 가깝게 생각하시면 됩니다.
스케줄러는 이 큐들을 보면서 우선순위와 정책에 따라 “다음에 CPU 받을 사람”을 고릅니다. 화면의 흐름도처럼 준비 → CPU → 필요하면 대기가 반복된다고 보면 됩니다.
아래쪽 막대는 우선순위가 높을수록 앞에 선다는 느낌만 전달용으로 넣었습니다.

---

슬라이드 4 — 선점 vs 비선점

선점은 실행 중이어도 CPU를 뺏을 수 있다는 뜻입니다. 타임 슬라이스가 끝나면 다른 프로세스로 넘기는 식이죠. 대화형 작업의 체감 응답에 유리합니다.
비선점은 한 번 잡으면 스스로 내놓을 때까지—I/O나 종료까지—계속 갑니다. 구현은 단순한데, 앞에 긴 작업이 있으면 뒤 작업이 오래 굶을 수 있습니다.
타임라인 그림처럼, 선점은 조각조각 바뀌고, 비선점은 긴 덩어리로 보이는 게 포인트입니다.

---

슬라이드 5 — FCFS (한 장에 한 알고리즘)

전환 멘트(선택): “이제 대표 스케줄링만, 각각 어떤 문제를 풀고 어떤 규칙인지만 짚고 넘어가겠습니다.”

풀려는 문제: 스케줄러를 단순하게 만들고 싶다. “먼저 온 사람부터”라는 규칙 하나로도 공정해 보이게 설명하기 쉽다.
기법: 준비 큐에 도착한 순서대로 CPU를 넘긴다. 보통 비선점과 짝을 이룬다.
한계: 앞에 CPU를 오래 쓰는 작업이 서 있으면, 뒤의 짧은 작업까지 전부 늦어진다 → 콘보이 효과. 그림처럼 긴 회색 블록 뒤의 작은 초록 블록들이 같이 밀린다고 보면 된다.

(긴 연습 대본 → 부록 B · 1. FCFS)

---

슬라이드 6 — Round Robin (RR)

풀려는 문제: FCFS처럼 한 작업이 길게 독점하면, 다른 프로세스는 응답이 끊겨 보인다. 특히 대화형에 불리하다.
기법: 시간 할당량(양자 q) 만큼만 CPU를 쓰게 한 뒤, 안 끝났으면 다시 큐 뒤로 보낸다. 선점이다.
특징: 돌아가며 짧게 쓰기 때문에 공평하고, 터미널·UI에 유리하다. 반대로 q가 너무 작으면 문맥 교환만 잦아져 오버헤드가 커질 수 있다—한 줄만 덧붙이면 충분하다.

(긴 연습 대본 → 부록 B · 2. RR)

---

슬라이드 7 — MLFQ (다단계 피드백 큐)

풀려는 문제: 대화형은 빨리 응답해 주고, CPU만 오래 쓰는 배치는 덜 방해 받게—한 가지 규칙(FCFS만, RR만)으로는 둘 다 만족시키기 어렵다.
기법: 우선순위가 다른 준비 큐를 여러 단으로 두고, 보통 위쪽부터 짧은 양자로 돌리다가, CPU를 오래 쓰면 아래 큐로 내리는 식으로 조절한다. (실제 OS마다 승격·강등 규칙은 다르다고만 말해도 된다.)
특징: 유연하지만 튜닝이 어렵고, 규칙이 나쁘면 기아나 한쪽만 불리한 상황이 생길 수 있다.

(긴 연습 대본 → 부록 B · 3. MLFQ)

---

슬라이드 8 — 리눅스 CFS · vruntime

리눅스의 CFS는 “완전 공정”을 목표로 하는 스케줄러로, 각 태스크가 CPU를 얼마나 썼는지를 추적합니다. 개념적으로 vruntime, 가상 실행 시간이 덜 쌓인 쪽에게 기회를 더 주는 식으로 이해하시면 됩니다.
막대 그림처럼, 이미 많이 돌린 애보다 덜 돌린 애를 다음 후보로 고른다—이 한 문장만 기억해도 발표는 통과권입니다.

---

슬라이드 9 — Part 2 도입 · 가상 메모리

두 번째 축은 가상 메모리입니다. 프로그램 입장에서는 큰 연속 주소 공간을 다 갖고 있는 것처럼 보이지만, 실제 RAM은 더 작을 수 있어요.
주소 변환—논리 주소를 물리 주소로 바꾸는 장치—이 그 “마법”이고, 필요한 조각만 RAM에 올리고 나머지는 디스크 쪽과 왔다 갔다 할 수 있습니다.

---

슬라이드 10 — 논리 주소 vs 물리 주소 · MMU

CPU와 프로세스는 논리 주소, 즉 가상 주소만 봅니다. MMU가 페이지 테이블 등을 보고 물리 주소로 바꿔 주면, RAM의 실제 위치에 접근하게 됩니다.
아래 한 줄은 페이지 테이블이 “논리 페이지 번호 → 물리 프레임 번호” 같은 표 한 줄로 매핑한다는 뜻만 짚는 용도입니다.

---

슬라이드 11 — 연속 할당·세그멘테이션 한계 · 스와핑

연속 할당이나 가변 크기 세그멘테이션으로 메모리를 나누면, 할당과 해제가 반복되며 빈 공간이 조각조각 나뉩니다. 전체 여유는 있는데 큰 연속 구멍이 없어서 못 쓰는 경우—이게 외부 단편화입니다.
스와핑은 RAM이 빡빡할 때 일부를 디스크로 내렸다가 다시 올리는 건데, I/O 비용이 크다. 근본적으로는 고정 크기 블록 방식이 필요하다—이 흐름으로 페이징으로 넘깁니다.

---

슬라이드 12 — 페이징

연속 할당·세그멘테이션의 외부 단편화를 줄이려고 페이징이 나옵니다. 주소 공간을 고정 크기 페이지로 자르고, RAM도 같은 크기 프레임에 맞춥니다. 빈 프레임 어디에나 끼워 넣을 수 있어서 외부 단편화는 사라집니다.
트레이드오프는 내부 단편화입니다. 프로세스 크기가 페이지 배수가 아니면, 마지막 페이지 안에 쓰지 않는 공간이 남습니다. (그림에서 마지막 페이지 일부 “낭비” 표시)
페이지 테이블은 논리 페이지 → 물리 프레임 매핑을 담고, OS·하드웨어가 함께 관리한다고 정리하면 됩니다.

전환 멘트(선택): “방금 말한 외부와 내부를, 앞의 연속 할당이랑 페이징이랑 한 줄로만 맞춰 보겠습니다.”

---

슬라이드 13 — 외부 단편화 vs 내부 단편화 (정리 한 장)

구두 강조 포인트: 질문으로 끝내기 좋은 한 장입니다. “연속 할당·세그멘테이션은 외부 단편화, 페이징은 내부 단편화—어디서 낭비가 나는지가 다릅니다.”

왼쪽(연속·세그멘테이션): 빈 공간이 RAM 전체에 잘게 흩어집니다. 총 여유는 있어도 큰 연속 구멍이 없어 새 덩어리를 못 넣는 게 외부 단편화입니다.
오른쪽(페이징): 프레임 밖에서는 조각이 안 나서 외부 단편화는 없애는 대신, 한 프레임 안 마지막 페이지 끝에 안 쓰는 칸이 남을 수 있는 게 내부 단편화입니다.

한 줄로 닫기: “바깥에서 구멍이 쪼개지냐, 고정 칸 안에서만 남느냐—이 차이만 기억하면 됩니다.”

---

슬라이드 14 — FIFO 페이지 교체

전환 멘트(선택): “단편화 정리까지 했으면, RAM이 꽉 찼을 때 누굴 쫓아낼지 정하는 교체 알고리즘을 봅니다. 먼저 가장 단순한 FIFO부터요.”

풀려는 문제: 정책을 단순하게—먼저 메모리에 올라온 페이지부터보낸다는 규칙만으로 설명하기 쉽다.
기법: 가장 먼저 적재된 프레임을 희생 페이지로 삼는다(큐 앞쪽).
한계: 참조 패턴에 따라 성능이 들쭉날쭉하고, 프레임 수를 늘렸는데도 폴트가 늘 수 있는 Belady의 모순이 이론적으로 가능하다—한 줄로만 짚어도 된다.

(긴 연습 대본 → 부록 C · 1. FIFO)

---

슬라이드 15 — 최적(OPT) 페이지 교체

풀려는 문제: 교체할 때마다 미래 참조를 안다면, 페이지 폴트를 최소로 만들 수 있지 않을까—하는 이론적 기준.
기법: 앞으로 가장 늦게 다시 쓰이거나 다시 안 쓰이는 페이지를 희생 페이지로 고른다.
한계: 실행 중 프로그램의 미래 참조열을 알 수 없어 실제 OS에서는 구현 불가. 시뮬레이션·다른 알고리즘과의 비교용이다.

(긴 연습 대본 → 부록 C · 2. OPT)

---

슬라이드 16 — LRU 페이지 교체

풀려는 문제: OPT는 불가능하니, 과거 참조로 미래를 추정하고 싶다. 시간 지역성을 활용한다.
기법: 가장 오래 참조되지 않은(Least Recently Used) 페이지를 쫓아낸다.
특징·한계: 실무에서는 완전 LRU보다 근사 LRU 등으로 구현하는 경우가 많다—비용과의 타협.

(긴 연습 대본 → 부록 C · 3. LRU)

---

슬라이드 17 — Part 3 도입 · 파일 시스템

세 번째는 파일 시스템입니다. 사용자는 이름으로 부르지만, 디스크 위에서는 블록 주소로 읽고 씁니다. 그 사이를 디렉터리·아이노드·링크가 연결해 주는 장부 관리라고 보면 됩니다.

---

슬라이드 18 — 파일과 디렉터리

유닉스 계열에서 디렉터리는 “특수 파일”에 가깝고, 내용은 이름 → 아이노드 번호 같은 엔트리의 나열입니다.
큰 박스에서 inode로 화살표가 가는 그림과, /·home·doc 같은 작은 트리는 “폴더도 결국 이름표 목록”이라는 메시지용입니다.

---

슬라이드 19 — 아이노드와 블록 포인터

아이노드는 색인 할당 아이디어의 실전형입니다. 한 번에 잡아두면 좋은 비유는 파일 하나의 상세 장부입니다—크기·소유자·권한·시간 같은 메타데이터와, 실제 데이터가 들어 있는 디스크 블록 위치가 그 장부에 적혀 있습니다. 디렉터리는 이름표만 담고, 그 이름이 가리키는 장부가 inode이고, 실제 데이터 위치는 inode가 담당한다—이 분리가 핵심입니다.

---

슬라이드 20 — 하드 링크 vs 심볼릭 링크

하드 링크는 같은 inode를 서로 다른 이름이 가리키는 겁니다. 비유로는 쌍둥이 이름표—본체는 하나인데 표만 두 개.
심볼릭 링크는 경로 문자열을 담은 별도 파일입니다. 바탕화면 바로가기처럼, 원본 경로가 바뀌거나 지워지면 깨질 수 있다는 점이 차이입니다.

---

슬라이드 21 — 파티셔닝과 마운트

파티셔닝은 디스크를 /, home, swap 같은 구역으로 나누는 것이고, 마운트는 다른 파티션이나 USB 같은 별도 파일 시스템을 내 디렉터리 트리의 한 지점—예를 들어 /mnt/usb—에 붙여서 하나의 경로처럼 쓰게 하는 겁니다.
청중에게는 **“USB 꽂으면 이 폴더 아래에 보인다”**처럼 말하면 빨리 이해됩니다. (슬라이드 하단 팁 박스 내용을 그대로 말해도 됩니다.)

전환 멘트(선택): “본문은 여기까지이고, 마지막으로 한 장만 정리하고 마치겠습니다.”

---

슬라이드 22 — 최종 정리 · 마무리

가볍게 세 줄만 짚고 끝내면 됩니다.

• CPU — 코어 하나를 여러 프로세스가 쓸 때 누구에게 줄지, 줄 세우기·스케줄링이 핵심이었습니다.
• 메모리 — RAM은 작은데 주소 공간은 크게 쓰려면 페이징으로 나누고, 꽉 차면 교체 알고리즘으로 희생 페이지를 고릅니다.
• 파일 — 사용자는 이름으로 부르고, 실제 위치는 디렉터리 + inode가 연결합니다.

한 번 더 강조할 문장: 세부 암기보다 각 파트의 “무슨 문제를 어떻게 풀었는지” 흐름이면 충분합니다.
“질문 있으시면 말씀 주세요. 들어주셔서 감사합니다.” 로 끝내세요.

---

부록 A — 꿀팁 (슬라이드 밖·짧게 쓸 때)

시간이 촉박할 때 말로만 덧붙여도 되는 멘트입니다.

• 개념마다 그림 하나만 잡아도 청중은 따라옵니다.
• inode: 파일의 상세 장부(메타데이터 + 블록 위치), 디렉터리는 이름표.
• 하드 링크 / 심볼릭: 쌍둥이 이름표 vs 바로가기.
• 마운트: USB가 특정 폴더로 보이는 과정.

---

부록 B — 스케줄링 알고리즘 확장 (슬라이드 5 ~ 7)

data-slide 4 ~ 6. 각 알고리즘마다 어떤 문제를 두고, 어떤 규칙(기법)으로 푸는지, 무엇이 아쉬운지 순서로 말하면 청중이 따라오기 쉽습니다.

B-1. FCFS (First-Come, First-Served)

한 문장 요약: “먼저 온 프로세스부터 CPU를 준다. 규칙이 가장 단순하다.”

풀려는 문제 (왜 쓰는가)

• 스케줄러 구현을 최소한으로 두고 싶을 때.
• “공정함”을 도착 순서 하나로 설명하고 싶을 때—은행 창구처럼 번호 순이라고 비유해도 좋다.
• 교재·이론에서 다른 알고리즘과 비교하는 기준점으로 자주 나온다.

기법 (무엇을 하는가)

• 준비 큐에 들어온 선입선출(FIFO) 순서로 CPU를 할당한다.
• 보통 비선점과 함께 이야기된다. 즉, 한 번 CPU를 잡으면 스스로 I/O나 종료로 내놓을 때까지 계속 실행하는 그림으로 설명하면 된다.

생기는 문제 (한계)

• 앞에 실행 시간이 매우 긴 작업이 있으면, 뒤에 온 짧은 작업들이 전부 뒤로 밀린다.
• 이 현상을 콘보이 효과라고 부른다.
  비유: 앞차가 고속도로에서 천천히 가면, 뒤의 차들이 다 같이 느려지는 것과 비슷하다.

슬라이드와 짝짓기: 두 칸 카드(문제·기법), 아래 카드 콘보이, 그림은 긴 블록 뒤 짧은 블록 대기.

---

B-2. RR (Round Robin)

한 문장 요약: “정해진 시간(q)씩만 돌리고, 안 끝났으면 다시 줄의 맨 뒤로 보낸다.”

풀려는 문제 (왜 쓰는가)

• FCFS에서 생기는 한 작업의 장시간 독점을 끊고 싶을 때.
• 터미널 입력, UI 반응처럼 잠깐씩 자주 CPU가 필요한 작업이 기다리지 않게 하고 싶을 때.

기법 (무엇을 하는가)

• 각 프로세스에 시간 할당량(타임 슬라이스, 양자 q) 을 준다.
• q 안에 끝나지 않으면 선점당하고 준비 큐의 끝으로 간다.
• 큐가 한 바퀴 돌면서 순환하기 때문에 Round Robin이라 부른다.

특징·트레이드오프

• 장점: 공평함, 대화형 응답에 유리하다.
• 단점: q를 너무 작게 잡으면 문맥 교환이 너무 자주 일어나 오버헤드가 커진다. q를 너무 크게 잡으면 FCFS에 가까워진다—**“q가 설계 포인트”**라고만 말해도 된다.

슬라이드와 짝짓기: A, B, C가 원형으로 돌아가는 그림—할당량마다 순환.

---

B-3. MLFQ (다단계 피드백 큐)

한 문장 요약: “우선순위가 다른 준비 큐를 여러 층으로 두고, 행동(CPU 사용 패턴)에 따라 위아래로 옮긴다.”

풀려는 문제 (왜 쓰는가)

• 대화형은 빨리 한 번씩 CPU만 주면 체감이 좋고,
• CPU를 오래 쓰는 배치 작업은 조금씩 끊기지 않고 쓰는 편이 나을 수 있다.
• 단일 FCFS나 단일 RR만으로는 이 둘을 동시에 맞추기 어렵다.

기법 (무엇을 하는가)

• 여러 개의 준비 큐를 두고, 보통 위쪽 큐가 더 높은 우선순위다.
• 위쪽은 양자가 짧게, 아래로 내려갈수록 양자가 길게 같은 식으로 설계하는 경우가 많다.
• CPU를 오래 연속 사용하면 아래 큐로 강등시키고, I/O를 하면 위 큐로 올리는 등 피드백으로 조절한다. (실제 OS마다 승격·강등 규칙이 다르다고 말하면 정확하다.)

특징·트레이드오프

• 장점: RR·FCFS 단일 모델보다 현실 워크로드에 유연하게 맞출 수 있다.
• 단점: 큐 개수, 양자 길이, 승격 조건을 잘못 잡으면 기아(starvation) 가 생기거나, 반대로 특정 유형만 불리해질 수 있다. 튜닝이 중요하다고 정리하면 된다.

슬라이드와 짝짓기: Q0(대화형) → Q1 → Q2(배치) 가로 막대—위일수록 우선.

전환 멘트 예시 (5 → 6 → 7)

1. FCFS 끝난 뒤: “순서만으로는 짧은 작업이 불리할 수 있어서, 시간을 쪼개서 돌리는 방식이 RR입니다.”
2. RR 끝난 뒤: “그런데 실제로는 대화형이랑 배치를 한 덩어리 규칙으로만 처리하기 어렵습니다. 그래서 큐를 여러 단으로 나눈 MLFQ가 나옵니다.”

---

부록 C — 페이지 교체 알고리즘 확장 (슬라이드 14 ~ 16)

data-slide 13 ~ 15. 무슨 문제를 두고 · 어떤 규칙인지 · 한계는 무엇인지 순서로 말하면 정리하기 좋습니다.

공통 한 줄 (세 장 앞에 선택)

“물리 RAM의 프레임이 꽉 찼는데 새 페이지를 올려야 하면, 이미 있던 페이지 하나를 희생시켜야 합니다. 누구를 고를지가 페이지 교체 알고리즘입니다.”

---

C-1. FIFO (First-In, First-Out)

한 문장 요약: “가장 먼저 메모리에 들어온 페이지부터 쫓아낸다.”

풀려는 문제: 구현과 설명을 최소한으로 두고 싶을 때. “먼저 온 것부터 나간다”는 직관으로 청중에게 그림을 그리기 쉽다.

기법: 페이지가 프레임에 적재된 순서(또는 큐에 넣인 순서)를 기억해, 가장 오래전에 들어온 것을 교체한다. 도착 순서만 보므로, 최근에 많이 쓰였는지는 보지 않는다.

한계: 참조 패턴에 따라 페이지 폴트가 많이 날 수 있다. 프레임 수를 늘렸는데 오히려 폴트가 늘어나는 현상이 이론적으로 가능한데, 이를 Belady의 모순(anomaly) 이라고 한다(특정 참조열·FIFO 조합에서).

슬라이드와 짝짓기: A, B, C가 순서대로 들어온 뒤 D가 필요 → FIFO는 A를 희생하는 그림.

전환 멘트 예 (FIFO → OPT): “순서만 보면 단순한데, 앞으로 어떤 페이지를 쓸지까지 알 수 있다면 더 좋은 선택을 할 수 있지 않을까요? 그걸 이론적으로만 정의한 게 OPT입니다.”

---

C-2. OPT (최적, Optimal, MIN)

한 문장 요약: “앞으로 가장 오랫동안 쓰이지 않을 페이지를 쫓아낸다—미래를 안다는 가정 하에서.”

풀려는 문제: 페이지 폴트 수를 최소로 만드는 이상적인 기준이 무엇인지 정의하고 싶을 때. 다른 알고리즘(FIFO, LRU 등)의 성능을 비교·평가할 때 상한으로 쓴다.

기법: 앞으로의 참조열 전체를 안다고 가정하고, 현재 RAM에 있는 페이지 중 다음 참조가 가장 멀리 있거나, 이후에 전혀 참조되지 않는 페이지를 교체한다.

한계: 실제 실행 중에는 미래 참조를 모르므로 OS에서 구현할 수 없다. 오프라인 시뮬레이션, 교과서·과제에서의 벤치마크 용도로 쓰인다.

슬라이드와 짝짓기: “RAM: A B C, 새 D 요청” + 미래 참조에 따라 누가 희생인지 달라진다는 텍스트.

전환 멘트 예 (OPT → LRU): “미래는 모르니까, 대신 과거를 봅니다. 오래 안 쓴 페이지가 앞으로도 당분안 쓰일 가능성이 크다는 가정이 LRU입니다.”

---

C-3. LRU (Least Recently Used)

한 문장 요약: “가장 오래전에 참조된 페이지를 쫓아낸다.”

풀려는 문제: OPT는 불가능하므로, 시간 지역성(최근에 쓴 것은 곧 또 쓴다)으로 근사하고 싶을 때.

기법: 각 페이지마다 마지막 참조 시각(또는 순서)을 추적하고, 그중 가장 오래된 것을 희생 페이지로 선택한다.

특징·한계: 성능 면에서는 FIFO보다 참조 패턴에 잘 맞는 경우가 많다고 이야기할 수 있으나, 정확한 LRU는 리스트·해시 등으로 비용이 든다. 실제 OS·CPU는 근사 LRU(클럭, NFU 변형 등)를 쓰는 경우가 많다—한 줄로만 언급해도 충분하다.

슬라이드와 짝짓기: 참조열 A B C A D … 타일 + D 들어올 때 LRU 희생 표시.

---

부록 D — 발표 3요소 (연습 체크리스트)

1. 그림 한 장 — 개념 하나당 핵심 도식 하나.
2. 비유 한 줄 — 하드 링크/심볼릭, 마운트 등은 짧은 비유로 고정.
3. 실생활 예 — 마운트는 USB, 스케줄링은 “한 강의실에 발표 순서 정하기” 등.

index.html의 해당 슬라이드 그림과 짝지어 연습하면 시간 안에 끝내기 쉽습니다.