개발 방법론 · 운영체제 · 기타 E16

답 — AJAX(Asynchronous JavaScript and XML). 페이지를 통째로 다시 받지 않고 자바스크립트가 뒤에서 서버와 데이터만 주고받아 화면 일부를 바꾸는 기법이다.

원리 — 옛 웹은 버튼 하나를 눌러도 브라우저가 서버에 새 페이지를 요청해 화면 전체를 다시 그렸다. AJAX 는 자바스크립트의 XMLHttpRequest(지금은 fetch) 객체로 서버에 "데이터만" 요청하고, 응답이 오면 DOM 의 필요한 부분만 바꾼다. "비동기"라는 것은 요청을 보내 놓고 응답을 기다리는 동안 사용자는 계속 화면을 쓸 수 있다는 뜻이다. 이름의 XML 은 초기에 데이터 형식으로 XML 을 썼기 때문이고 지금은 대부분 JSON 을 쓴다 — 이름만 남았다. 검색창 자동완성, 무한 스크롤이 전부 AJAX 다.

따라가기

1. "JavaScript 와 XML 을 이용" → 이름의 J · X
2. "전체를 새로고침하지 않고 비동기적으로 교환" → Asynchronous
3. 합치면 AJAX

헷갈리는 자리 — 영문 풀이를 쓸 때 Asynchronous 철자를 틀리는 것. 그리고 JSON 을 답으로 적는 실수 — JSON 은 데이터 "형식"이고 AJAX 는 데이터를 "주고받는 기법"이다. 같은 문제가 2025-2-08 에 다시 나왔다.

표준 · 교재 정의(운영체제 · 리눅스 명령 · 웹 · 클라우드 용어)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.

답 — ① chmod ② 751. 소유자 rwx(7) · 그룹 r-x(5) · 기타 --x(1)을 8진수 세 자리로 붙인 것이다.

원리 — 리눅스 파일 권한은 소유자 · 그룹 · 기타 세 묶음이고, 묶음마다 읽기 r · 쓰기 w · 실행 x 세 비트다. r = 4, w = 2, x = 1 로 두고 더하면 한 묶음이 0~7 한 자리 8진수가 된다 — rwx = 4+2+1 = 7, r-x = 4+1 = 5, --x = 1, rw- = 6, r-- = 4. 그래서 권한 전체는 세 자리 8진수 하나로 표현되고, chmod(change mode) 명령이 그 값을 파일에 붙인다. ls -l 에서 보이는 -rwxr-x--x 가 곧 751 이다.

따라가기

1. 소유자 읽기 · 쓰기 · 실행 → rwx → 4+2+1 = 7
2. 그룹 읽기 · 실행 → r-x → 4+1 = 5
3. 기타 실행만 → --x → 1
4. 명령은 권한을 바꾸는 chmod, 값은 751 → chmod 751 a.txt

헷갈리는 자리 — chown 을 적는 것. chown 은 소유자(owner)를 바꾸고, chmod 는 권한(mode)을 바꾼다. 그리고 순서를 "기타 · 그룹 · 소유자"로 거꾸로 읽어 157 로 적는 실수 — 항상 소유자가 맨 앞이다.

표준 · 교재 정의(운영체제 · 리눅스 명령 · 웹 · 클라우드 용어)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.

답 — ① IaaS ② PaaS ③ SaaS. 아래(인프라)부터 위(소프트웨어)까지 "어디까지 빌려주나"로 갈린다.

원리 — 클라우드는 남의 컴퓨터를 빌려 쓰는 것인데 빌리는 층이 다르다. IaaS(Infrastructure)는 서버 · 저장소 · 네트워크 같은 인프라만 빌린다 — OS 설치부터 내가 한다(AWS EC2). PaaS(Platform)는 OS · 런타임 · DB 까지 갖춰진 개발 · 실행 플랫폼을 빌린다 — 코드만 올리면 돈다(Heroku · App Engine). SaaS(Software)는 완성된 응용 프로그램을 서비스로 쓴다 — 설치도 개발도 없다(Gmail · 노션). 위로 갈수록 제공자가 관리하는 범위가 넓고 내 자유도는 줄어든다.

따라가기

1. "서버 · 스토리지 등 인프라 제공" → IaaS
2. "개발 · 실행 플랫폼 제공" → PaaS
3. "응용 소프트웨어를 서비스로 제공" → SaaS

헷갈리는 자리 — PaaS 와 SaaS 를 바꾸는 것. "개발자가 코드를 올리는 자리"면 PaaS, "최종 사용자가 그냥 쓰는 완성품"이면 SaaS 다. 영문 첫 글자 I · P · S 가 Infrastructure · Platform · Software 라는 것만 붙잡으면 된다.

표준 · 교재 정의(운영체제 · 리눅스 명령 · 웹 · 클라우드 용어)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.

답 — LRU 6회, LFU 6회. 프레임 3개에 1 · 2 · 3 을 채운 뒤 4 · 5 · 7 이 들어올 때마다 부재가 나 둘 다 6번이다.

원리 — 페이지 부재(page fault)는 필요한 페이지가 프레임에 없어 디스크에서 가져오는 일이다. 프레임이 꽉 찼을 때 누구를 내보내느냐가 교체 알고리즘이다. LRU(Least Recently Used)는 "가장 오래 안 쓴" 페이지를, LFU(Least Frequently Used)는 "가장 적게 쓴" 페이지를 내보낸다. 처음 세 개는 빈 프레임을 채우므로 무조건 부재 3번이다. 그다음부터 "이미 있나(적중)" 아니면 "없어서 교체(부재)"를 한 칸씩 표로 따라간다.

따라가기

1. 1 · 2 · 3 → 빈 프레임 채움, 부재 3 (프레임 [1 2 3])
2. 1 · 2 → 적중
3. 4 → 부재. LRU: 가장 오래 안 쓴 3 교체 / LFU: 1 · 2 는 2회, 3 은 1회라 3 교체 → [1 2 4], 부재 4
4. 1 · 2 → 적중
5. 5 → 부재. LRU: 4 가 가장 오래 / LFU: 4 는 1회 → 4 교체 → [1 2 5], 부재 5
6. 7 → 부재. LRU: 1 이 가장 오래(2 · 5 가 더 최근) / LFU: 5 가 1회 → 교체, 부재 6
7. 둘 다 6회

헷갈리는 자리 — LRU 에서 마지막 7 이 들어올 때 누가 나가는지는 답(부재 횟수)에 영향이 없다 — 횟수만 묻는 문제면 교체 대상을 따질 필요 없이 "없으면 부재"만 세면 된다. 그러나 최종 프레임 상태를 묻는 문제라면 LRU 는 [7 2 5], LFU 는 [1 2 7] 로 달라지니 구분해 둔다.

표를 손으로 한 칸씩 채우고 파이썬 시뮬레이션 스크립트로 같은 값을 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 6.5. 전부 시각 0 에 도착했으므로 SRT 는 SJF 와 같아 짧은 순서 P2 → P4 → P1 → P3 이고 대기 합 26 ÷ 4 = 6.5 다.

원리 — SRT(Shortest Remaining Time)는 "남은 실행 시간이 가장 짧은" 프로세스를 먼저 돌리는 선점 방식이다. 새 프로세스가 도착할 때마다 남은 시간을 비교해 더 짧으면 뺏는다. 그런데 이 문제는 모두 시각 0 에 도착해 도중에 새로 들어오는 프로세스가 없다 — 그러면 선점이 일어날 일이 없어 비선점 SJF 와 똑같이 짧은 것부터 차례로 돈다. 대기 시간은 "끝난 시각 − 도착 − 실행 시간"이고, 도착이 0 이면 "내 앞에서 돈 시간의 합"이다.

따라가기

1. 짧은 순 정렬 → P2(2) → P4(4) → P1(12) → P3(15)
2. P2: 0~2, 대기 0
3. P4: 2~6, 대기 2
4. P1: 6~18, 대기 6
5. P3: 18~33, 대기 18
6. 합 0+2+6+18 = 26, 평균 26 ÷ 4 = 6.5

헷갈리는 자리 — 반환 시간(turnaround)을 구하는 것. 반환은 "끝난 시각 − 도착"이라 실행 시간이 포함돼 (2+6+18+33) ÷ 4 = 14.75 가 된다. 문제는 "대기"를 물었다. 그리고 SRT 라고 해서 복잡한 선점 표를 그릴 필요가 없다 — 동시 도착이면 SJF 다.

표를 손으로 한 칸씩 채우고 파이썬 시뮬레이션 스크립트로 같은 값을 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 12회. 교과서의 대표 참조열로, 프레임 3개 LRU 는 20번 참조 중 12번 부재 · 8번 적중이다.

원리 — LRU 는 프레임이 꽉 찼을 때 "가장 오래전에 쓰인" 페이지를 내보낸다. 따라가는 요령은 각 프레임에 "마지막으로 쓰인 시각"을 적어 두는 것이다 — 적중이면 그 페이지의 시각만 갱신하고, 부재면 시각이 가장 옛날인 페이지를 빼고 새 페이지를 넣는다. 처음 3개는 빈 프레임을 채우는 부재다. 실수는 대개 "적중했을 때 시각 갱신을 안 해서" 생기니 적중도 표에 반드시 적는다.

따라가기

1. 7 · 0 · 1 → 부재 3, [7 0 1]
2. 2 → 부재(7 out) [2 0 1] · 0 적중 · 3 → 부재(1 out) [2 0 3] · 0 적중
3. 4 → 부재(2 out) [4 0 3] · 2 → 부재(3 out) [4 0 2] · 3 → 부재(0 out) [4 3 2] · 0 → 부재(4 out) [0 3 2]
4. 3 · 2 → 적중 · 1 → 부재(0 out) [1 3 2] · 2 적중 · 0 → 부재(3 out) [1 0 2] · 1 적중
5. 7 → 부재(2 out) [1 0 7] · 0 · 1 → 적중
6. 부재 3+2+4+2+1 = 12회

헷갈리는 자리 — 같은 참조열을 FIFO 로 돌리면 15회, OPT(최적)로 돌리면 9회다. 방식을 잘못 읽으면 숫자가 통째로 달라진다. 3단계에서 "0 이 최근에 쓰였는데 왜 나가나"가 걸린다 — 시각을 적어 보면 4(8번째) · 3(6번째) · 0(7번째) 중 3 이 먼저 나가고, 그다음 0(7번째)이 4(8번째) · 2(9번째)보다 오래돼 나간다.

표를 손으로 한 칸씩 채우고 파이썬 시뮬레이션 스크립트로 같은 값을 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — 스킴 → 권한(사용자정보 · 호스트 · 포트) → 경로 → 쿼리 스트링 → 프래그먼트. URI 를 왼쪽부터 오른쪽으로 읽는 순서 그대로다.

원리 — URI 는 "어떤 방법으로(스킴), 어느 서버의(권한), 어느 자원을(경로), 어떤 조건으로(쿼리), 그중 어디를(프래그먼트)" 가리키는 한 줄이다. 예로 https://user:pw@www.example.com:8080/board/list?page=2&sort=new#top 을 뜯으면 — https 가 스킴(프로토콜), user:pw@www.example.com:8080 이 권한(authority: 사용자정보@호스트:포트), /board/list 가 경로, ?page=2&sort=new 가 쿼리 스트링(키=값을 &로 연결), #top 이 프래그먼트(문서 안 위치, 서버에 안 보내고 브라우저만 쓴다)다. 구분 기호 :// · @ · : · / · ? · # 이 각 부분의 경계다.

따라가기

1. :// 앞 → 스킴(https)
2. :// 뒤 첫 / 앞 → 권한(사용자정보@호스트:포트)
3. / 부터 ? 앞 → 경로
4. ? 뒤 → 쿼리 스트링(key=value&key=value)
5. # 뒤 → 프래그먼트

헷갈리는 자리 — 프래그먼트를 서버로 보내는 것으로 아는 것. # 뒤는 브라우저가 페이지 안에서 스크롤할 위치라 HTTP 요청에 포함되지 않는다. 그리고 URL 과 URI 의 관계 — URL(위치)은 URI(식별자)의 부분집합이다. 시험은 "권한(authority)"이라는 이름을 낯설어해 틀린다 — 호스트 · 포트가 든 부분이 권한이다.

표준 · 교재 정의(운영체제 · 리눅스 명령 · 웹 · 클라우드 용어)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.

답 — ① SJF ② SRT. 같은 "짧은 것 먼저"인데 한 번 잡으면 안 뺏기는 것이 SJF, 더 짧은 것이 오면 뺏기는 것이 SRT 다.

원리 — CPU 스케줄링은 비선점(한 번 CPU 를 잡으면 끝날 때까지 안 뺏김)과 선점(더 급한 것이 오면 뺏김)으로 나뉜다. SJF(Shortest Job First)는 대기 중인 것 가운데 실행 시간이 가장 짧은 것을 고르고, 시작하면 끝까지 돈다 — 비선점. SRT(Shortest Remaining Time)는 SJF 의 선점판이다 — 실행 중에 "남은 시간"보다 짧은 프로세스가 도착하면 CPU 를 넘긴다. 둘 다 평균 대기 시간이 짧다는 장점이 있지만 긴 작업이 계속 밀리는 기아(starvation)가 생길 수 있다.

따라가기

1. "실행 시간이 가장 짧은 작업부터 · 비선점" → SJF
2. "남은 실행 시간이 가장 짧은 · 선점" → SRT

헷갈리는 자리 — 비선점 · 선점 묶음을 통째로 외운다. 비선점: FCFS · SJF · HRN. 선점: SRT · RR · 다단계 큐 · 다단계 피드백 큐. "남은(Remaining)"이라는 말이 붙으면 실행 도중에도 비교한다는 뜻이라 선점이다.

표준 · 교재 정의(운영체제 · 리눅스 명령 · 웹 · 클라우드 용어)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.

답 — AJAX. 2023-1-04 와 같은 문제다 — 페이지 전체 대신 필요한 데이터만 비동기로 받아 화면 일부를 갱신한다.

원리 — 브라우저가 서버에 문서를 요청하면 기본 동작은 "새 문서로 화면 전체 교체"다. AJAX 는 자바스크립트가 XMLHttpRequest 나 fetch 로 백그라운드 요청을 보내고, JSON · XML 로 온 응답을 받아 DOM 의 일부만 바꾼다. 비동기라서 응답을 기다리는 동안 화면이 멈추지 않는다. 결과로 페이지 깜빡임이 없고 전송량이 줄며, 한 페이지 안에서 앱처럼 움직이는 SPA(단일 페이지 애플리케이션)의 바탕이 됐다.

따라가기

1. "전체를 새로 고치지 않고" → 부분 갱신
2. "필요한 데이터만 비동기적으로" → Asynchronous + 데이터 교환
3. → AJAX

헷갈리는 자리 — 웹소켓(WebSocket)과 섞는 것. 웹소켓은 서버와 "항상 열린 양방향 통로"를 만들고, AJAX 는 필요할 때마다 "요청 – 응답"을 한 번씩 한다. 문제에 "비동기 · 부분 갱신 · XML" 이 나오면 AJAX 다.

표준 · 교재 정의(운영체제 · 리눅스 명령 · 웹 · 클라우드 용어)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.

답 — 11.75ms. 할당량 4 로 돌리면 P1 12 · P2 3 · P3 15 · P4 17, 합 47 ÷ 4 = 11.75 다.

원리 — 라운드로빈(RR)은 준비 큐를 순서대로 돌며 각 프로세스에 시간 할당량(quantum)만큼만 CPU 를 주고, 안 끝났으면 큐의 맨 뒤로 보낸다. 표를 그리는 규칙은 두 가지다 — ① 한 프로세스가 할당량을 다 쓴 시점에 새로 도착한 프로세스가 있으면 그것을 먼저 큐 뒤에 넣고, 그다음에 방금 돌던 프로세스를 넣는다. ② 대기 시간 = 끝난 시각 − 도착 시각 − 실행 시간. 즉 "큐에 들어와서 끝날 때까지 CPU 를 안 쓴 시간"이다.

따라가기

1. 0~4 P1(남 4). 이 사이 P2 · P3 · P4 도착 → 큐 [P2 P3 P4 P1]
2. 4~8 P2 끝 · 8~12 P3(남 5) · 12~16 P4(남 1) · 16~20 P1 끝
3. 20~24 P3(남 1) · 24~25 P4 끝 · 25~26 P3 끝
4. 대기: P1 = 20−0−8 = 12, P2 = 8−1−4 = 3, P3 = 26−2−9 = 15, P4 = 25−3−5 = 17
5. 합 47 ÷ 4 = 11.75ms

헷갈리는 자리 — 1단계에서 P1 을 도착한 P2 · P3 · P4 보다 앞에 다시 넣는 것. 할당량이 끝난 프로세스는 "그 시각까지 도착한 것들 뒤"로 간다. 이 순서를 바꾸면 평균이 달라진다. 그리고 문맥 교환 시간은 문제에서 무시한다고 했으니 더하지 않는다.

표를 손으로 한 칸씩 채우고 파이썬 시뮬레이션 스크립트로 같은 값을 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — ① pwd ② ls ③ cd ④ cp. 리눅스 기본 명령 네 개의 영문 약자를 풀면 답이 보인다.

원리 — 유닉스 명령은 대부분 영어 낱말의 약자다. pwd = print working directory, 지금 내가 있는 경로를 찍는다. ls = list, 현재 디렉터리의 파일 목록을 보여 준다(-l 자세히, -a 숨김 파일까지). cd = change directory, 다른 디렉터리로 옮긴다(cd .. 은 상위). cp = copy, 파일을 복사한다(cp 원본 사본, -r 로 디렉터리째). 짝으로 mv(move, 이동 · 이름 바꾸기) · rm(remove, 삭제) · mkdir(make directory) · cat(내용 출력) · chmod · chown 도 같이 나온다.

따라가기

1. "현재 작업 경로 표시" → print working directory → pwd
2. "파일 목록 보기" → list → ls
3. "디렉터리 이동" → change directory → cd
4. "파일 복사" → copy → cp

헷갈리는 자리 — cp 와 mv 를 바꾸는 것. cp 는 원본을 남기고 사본을 만들고, mv 는 원본을 옮긴다(이름 바꾸기도 mv). 그리고 윈도우 명령 dir · copy 를 적는 실수 — 문제는 UNIX/Linux 다.

표준 · 교재 정의(운영체제 · 리눅스 명령 · 웹 · 클라우드 용어)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.

답 — ① 운영 요구사항 ② 자원 요구사항 ③ 성능 요구사항. "어떤 환경에서 도나 · 무엇을 얼마나 쓰나 · 얼마나 빠르나"로 갈린다.

원리 — 요구사항은 "무엇을 하는가"(기능 요구사항)와 "어떤 조건에서 어떻게"(비기능 요구사항)로 나뉜다. 비기능 요구사항은 다시 여러 갈래다. 성능 요구사항은 응답 시간 · 처리량 · 동시 사용자 같은 속도와 양이다 — "1초 이내 응답". 자원 요구사항은 메모리 · 저장 공간 · CPU · 입력 장치처럼 시스템이 쓰는 자원에 대한 제약이다 — "메모리 적게, 터치스크린 지원". 운영 요구사항은 시스템이 놓일 운영 환경에 대한 것이다 — "여러 OS 에서 돌고 다양한 파일 포맷을 지원". 이 밖에 보안 · 신뢰성 · 사용성 · 이식성 · 유지보수성 요구사항이 같은 묶음에 든다.

따라가기

1. "여러 OS · 다양한 포맷 지원" → 운영 환경 → 운영 요구사항
2. "적은 메모리 · 터치스크린" → 쓰는 자원 → 자원 요구사항
3. "1초 이내 응답" → 속도 → 성능 요구사항

헷갈리는 자리 — ①을 이식성(portability) 요구사항으로 적는 것. 여러 OS 지원은 이식성으로도 읽히지만, 이 문제의 보기 구성(운영 · 자원 · 성능)에서는 운영 요구사항이 정답으로 복원돼 있다. 복원 문제라 실제 보기 문구가 달랐을 수 있으니 "OS · 포맷 = 운영 환경" 으로 묶어 기억한다.

표준 · 교재 정의(운영체제 · 리눅스 명령 · 웹 · 클라우드 용어)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.

답 — 6.5ms. SRT 로 돌리면 P1 9 · P2 0 · P3 15 · P4 2, 합 26 ÷ 4 = 6.5 다.

원리 — SRT 는 매 순간 "남은 실행 시간이 가장 짧은" 프로세스가 CPU 를 갖는다. 새 프로세스가 도착하는 시각마다 지금 도는 것의 남은 시간과 새로 온 것의 실행 시간을 비교해, 새것이 더 짧으면 선점한다. 도착이 끝난 뒤에는 남은 것들을 짧은 순으로 돌린다. 대기 시간 = 끝난 시각 − 도착 − 실행 시간이다. 2025-2-13 과 같은 표를 RR 대신 SRT 로 돌리는 문제라 두 결과(11.75 대 6.5)를 나란히 두면 선점 알고리즘의 효과가 보인다.

따라가기

1. 0~1 P1(남 7). 1 에 P2(4) 도착 → 4 < 7 이라 P2 선점
2. 1~5 P2. 2 에 P3(9) · 3 에 P4(5) 도착하지만 P2 남은 시간(3 · 2)이 더 짧아 계속. 5 에 P2 끝
3. 남은 것 P1 7 · P3 9 · P4 5 → 5~10 P4 끝 · 10~17 P1 끝 · 17~26 P3 끝
4. 대기: P1 = 17−0−8 = 9, P2 = 5−1−4 = 0, P3 = 26−2−9 = 15, P4 = 10−3−5 = 2
5. 합 26 ÷ 4 = 6.5ms

헷갈리는 자리 — 1단계에서 P1 이 1ms 만 돌고 뺏긴다는 것을 놓치고 P1 을 끝까지 돌리는 것(그러면 SJF 가 돼 값이 달라진다). 선점 뒤 P1 의 "남은 시간 7"을 표에 적어 두어야 3단계에서 P4(5)가 P1(7)보다 먼저라는 것이 보인다.

표를 손으로 한 칸씩 채우고 파이썬 시뮬레이션 스크립트로 같은 값을 확인했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 표 · 값이 실제와 다를 수 있다.

답 — ① 비선점 ② 환형 대기(순환 대기). 교착상태 4조건은 상호 배제 · 점유와 대기 · 비선점 · 환형 대기다.

원리 — 교착상태(deadlock)는 여러 프로세스가 서로가 가진 자원을 기다리며 영원히 멈추는 것이다. 네 조건이 "동시에" 성립해야 생긴다. 상호 배제 — 자원을 한 번에 하나만 쓸 수 있다(프린터). 점유와 대기 — 이미 가진 것을 쥔 채로 다른 것을 기다린다. 비선점 — 남이 가진 자원을 강제로 뺏을 수 없다. 환형 대기 — A 는 B 것을, B 는 A 것을 기다리는 식으로 대기가 원을 이룬다. 넷 중 하나라도 깨면 교착이 안 생기므로 "예방"은 조건 하나를 없애는 것이고, "회피"는 은행원 알고리즘으로 안전 상태만 허용하는 것이다.

따라가기

1. 주어진 둘: 상호 배제 · 점유와 대기
2. 빠진 둘: 뺏을 수 없다 → 비선점, 기다림이 원을 이룬다 → 환형 대기

헷갈리는 자리 — 비선점을 "선점"으로 적는 것. 자원을 뺏을 수 있으면(선점) 교착이 풀리므로 교착 조건은 "비선점"이다. 환형 대기는 "순환 대기 · 원형 대기"로도 쓴다.

이전 자료의 예상 문제다. 표준 정의 · 손 계산으로 확인했다.

답 — C → B → A. 우선순위는 A 2 · B 4 · C 5 로 C 가 가장 높다.

원리 — HRN(Highest Response-ratio Next)은 SJF 의 기아 문제를 고친 비선점 스케줄링이다. 우선순위 = (대기 시간 + 서비스 시간) ÷ 서비스 시간이다. 서비스 시간이 짧으면 분모가 작아 값이 커지고(SJF 처럼 짧은 것 우대), 오래 기다리면 분자가 커져 값이 올라간다(긴 작업도 언젠가 차례가 온다). 값이 큰 것부터 실행한다. 계산은 분수 하나씩이니 세 개를 구해 크기 순으로 세우면 끝이다.

따라가기

1. A: (5+5) ÷ 5 = 2
2. B: (6+2) ÷ 2 = 4
3. C: (12+3) ÷ 3 = 5
4. 큰 순 → C → B → A

헷갈리는 자리 — 값이 작은 것부터 세우는 것. HRN 은 응답 비율이 "높은(Highest)" 것이 먼저다. 그리고 대기 시간만 보고 C 를 고르는 것은 우연히 맞지만, B 와 A 는 대기만 보면 순서가 같아도 근거가 다르다 — 반드시 비율로 계산한다.

이전 자료의 예상 문제다. 표준 정의 · 손 계산으로 확인했다.

답 — 15회. 같은 참조열을 LRU 로 돌린 12회(2024-3-04)보다 3번 많다.

원리 — FIFO 는 "가장 먼저 들어온" 페이지를 내보낸다. 언제 마지막으로 쓰였는지는 보지 않고 들어온 순서만 본다. 그래서 자주 쓰는 페이지도 오래됐다는 이유로 나가 부재가 늘어난다. 따라가는 요령은 프레임을 큐로 그리고 부재마다 맨 앞을 빼고 맨 뒤에 넣는 것이다. 적중이면 아무것도 안 바꾼다(LRU 와의 결정적 차이 — LRU 는 적중 때 순서를 갱신한다).

따라가기

1. 7 · 0 · 1 → 부재 3 [7 0 1]
2. 2 부재 [0 1 2] · 0 적중 · 3 부재 [1 2 3] · 0 부재 [2 3 0] · 4 부재 [3 0 4] · 2 부재 [0 4 2] · 3 부재 [4 2 3] · 0 부재 [2 3 0]
3. 3 · 2 적중 · 1 부재 [3 0 1] · 2 부재 [0 1 2] · 0 · 1 적중 · 7 부재 [1 2 7] · 0 부재 [2 7 0] · 1 부재 [7 0 1]
4. 부재 3+7+5 = 15회

이 노트에서 만든 변형 문제다. 표준 정의와 대조했고 계산은 파이썬 시뮬레이션으로 확인했다.

답 — 선점: SRT · RR · 다단계 큐 / 비선점: FCFS · SJF · HRN. ① FCFS ② HRN.

원리 — 비선점은 한 번 CPU 를 잡으면 끝나거나 스스로 내놓을 때까지 안 뺏긴다 — FCFS(도착 순), SJF(짧은 순), HRN(응답 비율 순). 선점은 더 급한 것이 오면 뺏는다 — SRT(남은 시간 짧은 것), RR(할당량마다 교대), 다단계 큐 · 다단계 피드백 큐(우선순위 큐 사이 이동). FCFS 는 줄 선 순서라 공평하지만 긴 작업 뒤의 짧은 작업이 오래 기다리고(호위 효과), HRN 은 (대기 + 서비스) ÷ 서비스로 오래 기다린 작업의 순위를 올려 SJF 의 기아를 막는다.

따라가기

1. 뺏김 없음 → FCFS · SJF · HRN = 비선점, 뺏김 있음 → SRT · RR · MLQ = 선점
2. "도착 순서대로" → FCFS
3. "대기 시간이 길수록 우선순위 상승 · 기아 방지" → HRN

이 노트에서 만든 변형 문제다. 표준 정의와 대조했고 계산은 파이썬 시뮬레이션으로 확인했다.

답 — ① 상호 배제 · 점유와 대기 · 비선점 · 환형(순환) 대기 ② 은행원 알고리즘(Banker's Algorithm).

원리 — 교착은 네 조건이 동시에 성립할 때만 생긴다. 상호 배제(자원을 한 번에 하나만) · 점유와 대기(쥔 채로 더 기다림) · 비선점(못 뺏음) · 환형 대기(기다림이 원). 다루는 방법은 네 가지다 — 예방(조건 하나를 아예 없앰) · 회피(위험한 할당을 미리 피함) · 발견(생긴 뒤 찾음) · 회복(프로세스를 죽여 풂). 회피의 대표가 은행원 알고리즘이다 — 은행이 대출해 줘도 모든 고객이 결국 갚을 수 있는 "안전 상태"일 때만 빌려주듯, 자원을 주기 전에 안전 순서가 존재하는지 검사한다.

따라가기

1. 4조건 → 상호 배제 · 점유와 대기 · 비선점 · 환형 대기
2. "할당 전에 안전 상태 검사 · 회피" → 은행원 알고리즘

이 노트에서 만든 변형 문제다. 표준 정의와 대조했고 계산은 파이썬 시뮬레이션으로 확인했다.

답 — ① 폭포수 모델 ② 나선형 모델 ③ 스프린트 ④ 제품 백로그.

원리 — 폭포수는 단계를 위에서 아래로 한 번만 흘러가는 모델이다 — 요구 분석 → 설계 → 구현 → 테스트 → 유지보수. 문서가 명확하지만 앞 단계로 되돌아가기 어렵다. 나선형은 계획 → 위험 분석 → 개발 → 고객 평가를 나선처럼 여러 바퀴 돌며 점점 완성한다 — 위험 분석이 들어 있는 것이 표지다. 스크럼은 애자일의 한 방법으로, 제품 백로그(우선순위로 정렬한 요구사항 목록)에서 일을 꺼내 스프린트(2~4주 고정 주기) 안에 끝내고, 매일 짧은 회의(데일리 스크럼)로 진행을 맞춘다.

따라가기

1. "순서대로 · 되돌아가기 어렵다" → 폭포수
2. "위험 분석 반복" → 나선형
3. "2~4주 반복 주기" → 스프린트, "우선순위 요구 목록" → 제품 백로그

이 노트에서 만든 변형 문제다. 표준 정의와 대조했고 계산은 파이썬 시뮬레이션으로 확인했다.

답 — ① 644 ② 750 ③ chown.

원리 — 권한 문자 rwx 를 4 · 2 · 1 로 바꿔 소유자 · 그룹 · 기타 세 묶음을 각각 더한다. rw- = 4+2 = 6, r-- = 4, r-x = 4+1 = 5, rwx = 7, --- = 0. 644 는 "나만 쓰고 남은 읽기만"이라 일반 파일의 기본값이고, 750 은 "그룹까지만 실행, 남은 아예 못 봄"이다. chmod 는 이 숫자(mode)를 바꾸고, chown 은 소유자(owner)를 바꾼다 — chown 사용자:그룹 파일.

따라가기

1. rw- · r-- · r-- → 6 · 4 · 4 → 644
2. rwx · r-x · --- → 7 · 5 · 0 → 750
3. 소유자 변경 → chown

이 노트에서 만든 변형 문제다. 표준 정의와 대조했고 계산은 파이썬 시뮬레이션으로 확인했다.