블록 장치 - 하드 디스크, SSD (랜덤 액세스와 블록 I/O)

핵심 인사이트 (3줄 요약)

본질: 블록 장치(Block Device)는 데이터를 1바이트씩 쪼개지 않고, **512바이트나 4KB 단위의 고정된 크기인 '블록(Block)' 덩어리로만 묶어서 읽고 쓰는 저장장치(HDD, SSD)**를 의미하는 운영체제의 하드웨어 추상화 계층이다.

가치: 데이터에 고유한 '블록 번호(Address)'가 부여되어 있기 때문에, 테이프처럼 순서대로 감을 필요 없이 1번 블록을 읽다 곧바로 100만 번 블록으로 건너뛰기(랜덤 액세스, Random Access)가 가능하여 그 위에 웅장한 파일 시스템(EXT4, NTFS)을 건축할 수 있는 절대적 기반이 된다.

융합: 기계적 지연이 발생하는 디스크의 약점을 덮기 위해, 커널의 **버퍼 캐시(Buffer Cache) 및 엘리베이터 스케줄러(I/O 스케줄링)**와 완벽하게 융합되어, 수만 개의 흩어진 I/O 요청을 한 줄로 모아 쾌속 전송하는 배치(Batch) 처리의 정수를 보여준다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 운영체제가 관리하는 수많은 I/O 장치 중, 하드디스크, SSD, USB 메모리, 광학 드라이브(CD/DVD)처럼 대용량 데이터를 저장하는 기기들이다. OS는 이 장비들에게 "파일의 3번째 글자 줘"라고 명령하지 않는다. "디스크의 LBA(Logical Block Addressing) 4005번 블록(4KB) 통째로 줘!"라고 덩어리로 명령한다.
필요성: 만약 하드디스크가 키보드(문자 장치)처럼 1바이트씩 데이터를 토해낸다고 상상해 보자. 1GB짜리 영화를 복사하려면 디스크에 달린 물리적 바늘(Head)을 10억 번 까딱거려야(Interrupt) 한다. 바늘이 움직이는 물리적 시간(8ms)을 10억 번 곱하면 복사에만 1년이 걸린다. "이 미친 비효율을 막으려면 디스크 바늘이 한 번 움직였을 때 무조건 4096바이트(4KB)를 통째로 푹 퍼서 램(RAM)에 던져줘야 한다!"는 물리적 속도 한계의 극복이 블록 단위 전송이라는 무식하고도 든든한 규격을 강제했다.
💡 비유: 블록 장치는 대형 화물열차 시스템과 같다. 승용차(문자 장치)는 승객 1명(1바이트)이 원할 때 언제든 출발하지만, 화물열차(블록 장치)는 물건이 1개든 10개든 일단 **거대한 컨테이너 박스 1칸(블록 단위)**을 꽉 채울 때까지 기다렸다가 통째로 움직인다. 당장 내 물건 1개를 보내기엔 답답해 보이지만, 수만 톤의 화물(기가바이트 단위 파일)을 싣고 부산에서 서울로 갈 때는 컨테이너 규격화 시스템이 우주에서 가장 빠른 운송 수단이 된다.
등장 배경 및 저장장치 패러다임의 확립:
1. 순차 테이프(Magnetic Tape)의 지옥: 옛날 테이프 드라이브는 100번째 곡을 들으려면 1번부터 99번 곡을 다 감아야 하는 순차 접근(Sequential)만 가능했다.
2. 디스크(원판)의 발명: 레코드판처럼 바늘을 들어 100번째 곡 위치에 툭 떨어뜨리는 랜덤 액세스(Random Access)가 가능해졌다.
3. LBA (논리 블록 주소) 표준화: 실린더, 헤드, 섹터(CHS)라는 복잡한 물리적 3차원 위치를 OS가 다 계산하다 빡쳐서, 하드웨어 칩셋에 "네가 알아서 1차원 배열(LBA 0번~끝번)로 매핑해서 나한테 바쳐라!"라며 블록 장치의 추상화 인터페이스를 완성했다.

┌───────────────────────────────────────────────────────────────────────┐
│        블록 장치(Block Device)의 구조와 랜덤 액세스(Seek) 시각화      │
├───────────────────────────────────────────────────────────────────────┤
│                                                                       │
│ [ 하드디스크 / SSD 내부 논리 구조 (LBA: Logical Block Address) ]      │
│ ┌─────┬─────┬─────┬─────┬─────┬─── ... ──┬─────┐                      │
│ │ Blk │ Blk │ Blk │ Blk │ Blk │        │ Blk │                        │
│ │  0  │  1  │  2  │  3  │  4  │        │99999│                        │
│ └─────┴─────┴─────┴─────┴─────┴─── ... ──┴─────┘                      │
│                                                                       │
│ ▶ OS의 명령: "블록 2번 가져오고, 바로 블록 99999번 가져와!"           │
│                                                                       │
│ [ 기계적 움직임 (Random Access) ]                                     │
│   1. 디스크 헤드(바늘)가 블록 2번 위치로 쓱 이동 (Seek Time)          │
│   2. 디스크가 빙글 돌아서 2번 블록을 4KB 통째로 퍽! 떠서 RAM에 줌.    │
│   3. 바늘을 번쩍 들어 블록 99999번 위치로 휙 날아감! (건너뛰기 성공)  │
│   4. 99999번 블록 4KB를 퍽! 퍼서 RAM에 줌.                            │
│                                                                       │
│ ✅ 핵심: '주소(Block Number)'가 있기 때문에 원하는 곳으로 순간이동    │
│         (Seek)이 가능하며, 이 덕분에 디렉토리/파일 트리가 만들어짐.   │
└───────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "주소가 존재한다"는 것은 컴퓨터 공학에서 신의 권력을 뜻한다. 파일 시스템의 메타데이터(Inode)는 "사진.jpg 파일은 4번 블록, 10번 블록, 15번 블록에 쪼개져 저장되어 있다"는 보물지도를 갖고 있다. OS는 이 지도를 보고 블록 장치의 바늘을 4, 10, 15번으로 휙휙 점프(Seek)시켜 조각들을 램으로 모은 뒤 하나의 사진 파일로 조립해 낸다. 문자 장치(키보드)였다면 절대 불가능한 기적이다.

📢 섹션 요약 비유: 카세트테이프(문자 장치/순차 접근)로 영어 듣기 평가를 할 때는 "3번 문제 다시 들려주세요" 하면 선생님이 테이프를 지잉지잉 되감느라 속이 터집니다. 하지만 CD 플레이어(블록 장치/랜덤 액세스)는 리모컨으로 트랙 3번 버튼을 딱 누르면 레이저 바늘이 1초 만에 점프해서 재생을 시작하는 압도적인 편의성의 차이입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 버퍼 캐시 (Buffer Cache)라는 거대한 충격 흡수기

블록 장치의 치명적 단점은 "1바이트를 고치고 싶어도 무조건 4KB 블록을 통째로 엎어야 한다"는 것이다.

A라는 글자를 B로 바꾸고 싶다.
디스크에 다이렉트로 쓰면? 디스크는 1바이트 쓰기를 거부한다. 해당 4KB 블록 전체를 램으로 읽어와서(Read), 램 안에서 1바이트를 B로 고치고, 다시 4KB 통째로 디스크에 덮어써야(Write) 한다. (이른바 Read-Modify-Write 폭탄).
OS의 구원 (버퍼 캐시): OS는 이 미친 짓을 막기 위해 램에 **'버퍼 캐시'**라는 중간 저수지를 크게 파놨다. 앱이 1바이트씩 1만 번을 수정하면, 디스크를 1만 번 긁는 게 아니라 램에 있는 4KB 캐시 블록 1개 안에서만 조용히 1만 번 값을 바꾼다. 나중에 한가할 때(Flush) 변경된 4KB 블록 딱 1개만 디스크에 조용히 내려쓴다. 블록 장치는 이 램 캐시 없이는 아예 실사용이 불가능한 수준의 느린 깡통이다.

2. I/O 스케줄러 (엘리베이터 알고리즘)

수백 개의 프로세스가 동시에 하드디스크의 서로 다른 블록(1번, 9만 번, 50번, 8만 번)을 읽어달라고 I/O 요청을 마구 던진다. 디스크 바늘(Head)이 요청 들어온 순서대로 1 -> 90000 -> 50 -> 80000으로 널뛰기를 하면, 바늘이 왔다 갔다 하느라 시간을 다 허비해 디스크 I/O 속도가 바닥을 뚫고 지하로 간다. (디스크 스래싱).

I/O 스케줄러의 엘리베이터 정렬:
- 리눅스 커널 블록 레이어(Block Layer)에 있는 스케줄러는 요청이 들어오는 대로 바로 디스크에 던지지 않고 큐(Queue)에 잠시 모아둔다.
- 모인 요청들의 '블록 번호'를 오름차순으로 예쁘게 쫙 정렬(Sort)하고, 인접한 블록들은 하나의 거대한 덩어리로 병합(Merge)해버린다.
- 바늘은 이제 엘리베이터처럼 한 방향으로 쭉 올라가면서 1 -> 50 -> 80000 -> 90000 순서로 한 번에 부드럽게 훑고 지나가며(Sweep) 데이터를 퍼 담는다. 바늘의 동선(Seek Time) 낭비를 0으로 만드는 극강의 튜닝이다.
📢 섹션 요약 비유: 택배 기사(디스크 바늘)가 콜이 들어오는 순서대로 서울->부산->서울->부산으로 널뛰기 배달을 하면 하루에 4건밖에 배송을 못 합니다. 택배 회사 시스템(I/O 스케줄러)이 콜을 모아서 "오늘은 경부고속도로 타고 내려가면서 대전, 대구, 부산 순서로 한 방에 쫙 뿌리고 퇴근해라!"라고 엘리베이터식 동선을 짜주면 하루에 100건도 거뜬히 배달할 수 있습니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: HDD (하드 디스크) vs SSD (솔리드 스테이트 드라이브)

같은 블록 장치 카테고리 안에 있지만, 물리적 작동 원리는 구석기시대와 우주시대의 차이다.

비교 항목	하드디스크 (HDD)	솔리드 스테이트 드라이브 (SSD)
물리 구조	회전하는 쇠 원판과 움직이는 바늘 (모터)	낸드 플래시 반도체 (트랜지스터 칩)
블록 주소(LBA)	바늘이 그 위치까지 움직여야 함 (Seek Time 렉)	전기가 해당 셀에 즉시 꽂힘 (Seek Time = 0)
I/O 스케줄링	바늘 동선 아끼는 엘리베이터(CFQ) 스케줄러 필수	바늘이 없으니 동선 무시. `none/noop` 스케줄러로 직행
덮어쓰기(Write)	그 자리(섹터) 원판 위에 바로 자석으로 덮어씀	그 자리 덮어쓰기 불가. 다른 빈 블록에 새로 쓰고 옛날 건 버림 (Trim/Garbage Collection 렉 발생)

FTL (Flash Translation Layer)의 흑마술

SSD는 사실 OS를 속이고 있는 완벽한 사기꾼이다.

OS가 "3번 블록에 데이터 덮어써줘"라고 명령하면, SSD는 3번 칩셋에 덮어쓰지 못한다(플래시 메모리는 덮어쓰기가 물리적으로 불가능하고, 통째로 지우고 새로 써야 하기 때문).
SSD 내부에 있는 초소형 컴퓨터(ARM 컨트롤러)와 펌웨어인 FTL이 씩 웃으며, "응 3번에 쓸게"라고 OS에게 대답해 놓고는, 몰래 텅 빈 90번 블록에 데이터를 쓴 뒤, 자기 내부 비밀 장부(매핑 테이블)에 "앞으로 OS가 3번 달라고 하면 90번을 줘라"라고 화살표를 슬쩍 꺾어버린다(Wear Leveling).
OS는 SSD 내부에서 이런 엽기적인 주소 돌려막기와 블록 짬처리가 벌어지는 줄 1도 모른 채, "역시 내 LBA 지시는 완벽하게 통제되고 있어"라고 착각하며 살아간다. 하드웨어가 스스로 펌웨어를 달고 똑똑해져서 OS의 짐을 덜어준 하극상의 현장이다.

┌──────────┬────────────┬────────────┬────────────────────────────────┐
│ 저장 장치  │ I/O 병목 원인 │ 커널 튜닝 포인트 │ 수명 관리 주체      │
├──────────┼────────────┼────────────┼────────────────────────────────┤
│ HDD      │ 바늘의 물리적 이동│ I/O 스케줄러 정렬│ 모터 고장 전 무한 │
│ SSD      │ 덮어쓰기 지우기 렉│ TRIM 명령어 활성화│ FTL (마모도 분산)│
└──────────┴────────────┴────────────┴────────────────────────────────┘

[매트릭스 해설] 리눅스 서버 엔지니어가 랙에 HDD를 꽂았는지 SSD를 꽂았는지에 따라 커널 튜닝의 방향이 180도 달라지는 이유다. HDD에는 바늘 동선을 아끼는 무거운 큐(Queue)를 깔아줘야 살고, NVMe SSD에는 바늘이 없으니 무거운 큐를 다 박살 내고 멀티코어로 냅다 전기를 꽂아버리는 다중 큐(Multi-Queue Block Layer) 아키텍처를 세팅해야 100만 IOPS가 터진다.

📢 섹션 요약 비유: HDD가 물건을 찾으러 창고 복도를 일일이 뛰어다니는 지게차 알바생이라면, SSD는 손가락만 까딱하면 텔레포트로 물건이 눈앞에 뚝 떨어지는 초능력자입니다. 알바생에겐 동선을 짜주는 비서(엘리베이터 스케줄러)가 필수지만, 초능력자에겐 비서를 붙이는 것 자체가 시간을 갉아먹는 방해물(noop 스케줄러)이 됩니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오: NVMe 기술과 리눅스 `blk-mq` (멀티 큐) 혁명

과거의 병목 (Single Queue):
- 옛날 리눅스 블록 레이어는 64개의 CPU 코어가 하드디스크에 I/O를 요청할 때, 디스크 입구에 있는 **단 1개의 병목 큐(Single Request Queue)**에 락(Lock)을 걸고 줄을 서야 했다. 디스크가 HDD 시절엔 이 1개 줄로도 충분했다.
SSD의 반란 (수십만 IOPS):
- 괴물 같은 NVMe SSD가 등장해 1초에 100만 개의 블록(IOPS)을 쏠 수 있게 되었다.
- 그런데 리눅스 커널의 1개짜리 큐에서 스레드들이 락 경합(Spinlock)을 하느라 CPU가 100% 터져버려, 정작 SSD는 10%의 힘도 못 쓰고 놀고 있는 엽기적인 사태가 벌어졌다.
blk-mq (Multi-Queue Block IO) 패치:
- 커널 해커들이 분노하여 커널을 뜯어고쳤다.
- "코어가 64개야? 그럼 디스크로 가는 큐(Queue)도 코어별로 1개씩 64개를 뚫어!!"
- 각 코어는 남의 눈치(락 경합)를 볼 필요 없이 자기 전용 큐에 I/O 요청을 쏟아붓고, 최신 NVMe 컨트롤러는 이 64개의 큐에서 동시다발적으로 데이터를 빨아들여 플래시 칩셋에 벼락처럼 꽂아버린다.
- 이 아키텍처 혁신 덕분에 AWS 클라우드 스토리지(EBS)가 데이터베이스의 수백만 쿼리를 딜레이 없이 씹어먹는 전설이 시작되었다.

512B 섹터에서 4K(Advanced Format) 섹터로의 대이동

과거 모든 하드디스크의 물리적 블록(섹터) 크기는 512바이트였다. 하지만 용량이 테라바이트로 커지자 512바이트 단위로 관리 장부를 쓰려니 장부 용량이 하드를 다 파먹었다. 디스크 벤더들은 물리적 섹터 크기를 아예 **4096바이트 (4KB Advanced Format)**로 키워버렸다. 이 4KB는 놀랍게도 가상 메모리의 **'페이지(Page) 크기(4KB)'**와 완벽하게 1:1로 일치한다. 이 톱니바퀴의 일치 덕분에, 리눅스는 디스크에서 4KB 블록을 긁어오는 즉시 아무 변환이나 쪼개기 없이 램의 4KB 페이지 프레임에 블록처럼 딱 끼워 넣을 수 있게 되어(Zero-Copy I/O), 컴퓨터 시스템 전반의 대역폭이 비약적으로 상승했다.

📢 섹션 요약 비유: 햄버거집(SSD) 주방장이 1초에 100개를 만들 수 있는 초인이 되었는데, 카운터에 주문받는 알바(Single Queue)가 1명뿐이라 손님들이 주문하다 지쳐 쓰러집니다. 사장님(OS)이 키오스크(Multi-Queue)를 64대 설치해서 손님들이 동시에 결제하게 만들자, 그제야 주방장의 미친 제작 속도가 100% 뿜어져 나오기 시작한 혁신입니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

정량/정성 기대효과

구분	내용
랜덤 액세스(Random Access) 완성	데이터에 고유 주소(LBA)를 부여함으로써, 1TB 용량 어디든 트리(B-Tree) 탐색으로 수 밀리초 내에 찾아내는 파일 시스템 구축의 토대 마련
I/O 병합을 통한 스루풋 극대화	자잘한 1바이트 쓰기를 4KB 블록 단위로 램에 뭉쳐놨다가 디스크에 한 번에 때려 박는 배치(Batch) 처리로 I/O 효율 1만 배 이상 향상
OS 락(Lock) 프리 아키텍처 구현	NVMe와 Multi-Queue의 융합으로 CPU 코어 간 간섭 없이 초당 수백만 IOPS의 병렬 I/O 대역폭 달성

결론 및 미래 전망

블록 장치 (Block Device)는 "느려 터진 회전 모터와 바늘(HDD)"이라는 컴퓨터 공학 최악의 물리적 약점을, "블록(Block)이라는 고정된 덩어리"와 "LBA 주소 체계"라는 논리적 껍데기로 완벽하게 덮어버린 위대한 추상화의 상징이다. 1바이트의 융통성을 버린 대가로 4KB의 거대한 화물 운송 효율을 쟁취한 이 블록 인터페이스는, 훗날 램의 페이징(4KB) 시스템과 완벽한 짝짜꿍을 이루며 현대 운영체제의 VFS(가상 파일 시스템)를 떠받치는 척추가 되었다. 물리적 모터(HDD)가 사라지고 트랜지스터(SSD)가 그 자리를 차지한 오늘날에도, 운영체제는 여전히 하드웨어를 "4KB짜리 레고 블록들이 늘어선 1차원 배열"로 취급하며 평화롭게 데이터를 퍼 나르고 있다. 미래에 바이트 단위 직접 접근(Byte-addressable)이 가능한 CXL 기반 비휘발성 램(PMEM)이 디스크를 멸종시키는 날이 온다면 이 블록이라는 단위도 해체되겠지만, 대용량 데이터를 다루는 '일괄 처리(Batching)'의 위대한 철학만큼은 데이터베이스 엔진의 깊은 곳에 영원히 살아 숨 쉴 것이다.

📢 섹션 요약 비유: 물(데이터)을 숟가락(1바이트 문자 장치)으로 퍼 나르면 정밀하지만 하루가 다 갑니다. 규격화된 양동이(4KB 블록)로 퍼 나르면 물이 튀고 양 조절은 안 되지만 하루 만에 수영장(테라바이트)을 꽉 채울 수 있습니다. 블록 장치는 디스크라는 거대한 저수지에서 데이터를 가장 빠르고 안전하게 퍼 나르기 위해 인류가 합의한 '표준 양동이 규격'입니다.

📌 관련 개념 맵 (Knowledge Graph)

문자 장치 (Character Device) | 블록 장치와 세상을 양분하는 개념으로, 주소(Seek) 없이 1바이트씩 쫄쫄 흘려보내는 키보드나 마우스 같은 기기
LBA (Logical Block Address) | 1번 트랙 2번 실린더 같은 디스크 물리 위치를 깡그리 무시하고, "그냥 난 0번부터 1억 번 블록이야"라고 1차원 배열로 속여 파는 주소 체계
버퍼 캐시 (Buffer Cache) | 블록 장치의 느린 속도를 구원하기 위해, 디스크 블록들을 램에 임시로 쫙 깔아두고 뭉쳐서 통신하게 해주는 방파제
I/O 스케줄러 | 1번 9만 번 50번 뒤죽박죽 들어온 I/O 요청들을 엘리베이터처럼 순서대로 줄 세워 디스크 바늘의 노동을 줄여주는 커널의 두뇌
NVMe (Non-Volatile Memory Express) | 구식 SATA 블록 통신망의 좁은 병목을 박살 내고, PCIe 버스에 다이렉트로 꽂혀 수십만 IOPS를 뿜어내는 현대 SSD의 황제 규격

👶 어린이를 위한 3줄 비유 설명

블록 장치가 뭔가요? 책장(하드디스크)에 꽂힌 백과사전이에요. 내가 '우주'에 대해 알고 싶으면, 처음부터 안 읽고 목차(LBA)를 보고 500페이지로 한 방에 휙 넘겨서(랜덤 액세스) 읽을 수 있어요.
왜 1글자씩 안 읽나요? "별"이라는 글자 하나만 읽으러 책장에 다녀오고, "빛"이라는 글자 읽으러 또 다녀오면 다리 아프잖아요. 그래서 책을 한 번 펼치면 그 페이지 전체(4KB 블록)를 눈으로 다 찍어서 한꺼번에 뇌(램)로 가져오는 거랍니다.
만약 책 내용을 고치고 싶으면요? 책에 직접 연필로 안 쓰고, 내 연습장(버퍼 캐시)에 글을 다 쓴 다음에 밤에 자기 전에 책에 한꺼번에 풀로 쫙 붙여서(디스크 쓰기) 수정하는 엄청 빠른 방법이에요!