짬통 아카이브

FTL 상세 구조

로버트 E.O. 스피드왜건 — Tue, 20 Jan 2026 14:33:55 +0900

FTL의 개요

기존 HDD와 호환을 유지하면서 동작해야함

FTL의 정의

Block과 Page 기반의 SSD가 Sector 기반의 PC와 OS에 대응하기 위한 변환 계층

SSD와 파일시스템(OS) 사이에 위치

SSD를 HDD처럼 블럭(Block) 장치로 변환해주는 S/W

FTL의 구조 및 설명

SW	OS	File System, Block Device Driver	-
	FTL	STL(Sector Translation Layer)	Mapping, 가비지 컬렉션, 웨어 레벨링
	FTL	BML(Block Management Layer)	Bad Block 관리, Error Handling
	-	LLD(Low Level Driver)	Flash Interface
SSD		SSD, NAND Flash Device	컨트롤러, DRAM, I/O 인터페이스

FTL의 핵심 기술

1. Wear Leveling - 수명 연장

블럭당 기록 횟수를 균등하게 배분

웨어 레벨링

2. Garbage Collection - 삭제 효율화

미사용/사용 page 분류 ( == 디스크 조각모음 Hot/Cold Data 분류하여 Block 단위로 Erase)

가비지 컬렉션

3. Over provisioning - 여유 공간 제공

비어 있는 여유 공간이 부족시에 웨어레벨링, 가비지컬렉션이 제대로 수행되지 못함

여유 공간이 적어 특정 page들만 혹사당하는 문제를 극복하기 위한 여유공간 확보

4. NCQ(Native Command Queuing) - 여러 명령 동시 처리

한번에 여러 개의 Read/Write 명령 처리

5. TRIM - 선 삭제 동일

OS의 파일 삭제는 실제로 지우는 것이 아닌 파일 시스템과의 연결만 끊고 디스크에 파일은 그대로 존재함

OS에서 삭제한 파일들을 OS의 도움을 받아 파악 후 SSD 상에서 실제로 지우는 명령어

SSD 기록시 Erase할 필요가 없기 때문에 성능 향상 (미리 Erase해 둠으로써 Write 동작시 Erase 불필요로 성능 향상)

FTL (Flash Translation Layer) Section Mapping, Block Mapping

로버트 E.O. 스피드왜건 — Tue, 20 Jan 2026 11:23:02 +0900

FTL의 정의

Flash Memory와 File System 사이에 위치하여 Flash Memory를 Disk Device처럼 사용 가능하게 하는 계층

FTL의 필요성

1. File System 호환 - FAT16/32, NTFS, UDF등의 파일시스템 호환

2. I/O 동작 수행 - PC에서 Disk로 보내는 I/O명령을 수행

FTL의 위치 및 동작 구조의 설명

상위Layer	PC (Host System)	Flash Memory Read&Write
↕	File System	FAT/16/32, NTFS, UDF
	FTL	File System 호환
	Device Driver	Flash Memory 기능 제어
하위Layer	Flash Memory	NAND / NOR

Flash Memory를 저장장치로 사용할 경우 기존 파일 시스템 구조에서 FTL을 두어 파일시스템과 Flash Memory간 Mapping시켜주는 역할

Sector Mapping

1. Sector 6번 요청 (Logical Sector Number)

2. FTL Mapping Table 참조 (0번 Block, 2번 Page)

3. 논리주소 6의 위치 참조 -> 물리 주소 획득(Physical Sector Number)

4. Flash Memory의 해당 Block 및 Page주소 접근

5. Flash Memory에서의 Data 전송

Block Mapping

1. LPA(Logical Page Adress) 5번에 데이터 작성 -> LBN(Logical Block Number) 1과 Offset 1로 분리

2. FTL Block Mapping Table 참조 / but LBN 1번에 이미 PBN 0번이 매핑되어있는 상황

3. 새 물리 블록인 PBN 2번 할당 받음.

4. Offset이 1이므로 PBN2, 2번째 칸에 page 5' 작성

5. PBN 0에 있단 나머지 데이터(4, 6, 7)을 PBN 2 동일 위치로 그대로 Block copy (실제로는 RAM버퍼 활용으로 4번 카피, 5' 작성, 6, 7카피 순서로 적용)

6. FTL Table 갱신 (0->2)

Sector Mapping VS Block Mapping

구분	Sector Mapping	Block Mapping
개념	Read, Write 단위인 Sector단위	Erase단위인 Block으로 Mapping
장점	Sector Update시 매핑 table 정보만 변경, Erase 연산 최소화	Mapping Table의 크기가 작음
단점	Mapping table 크기가 커질 수 있음	Mapping 정보와 일치해야 되기 때문에 성능 저하 발생

캐시 (Write Back vs Write Through)

로버트 E.O. 스피드왜건 — Mon, 19 Jan 2026 16:16:09 +0900

1. 읽기(Read)는 평화롭지만, 쓰기(Write)는 전쟁이다

데이터를 읽는 건 간단합니다. 그냥 복사해 오면 끝이니까요. 하지만 데이터를 고치는(Write) 순간, 족보가 꼬이기 시작합니다.

상황: CPU(레지스터)가 A = 1을 A = 2로 바꿨습니다.
캐시: A = 2로 업데이트됨.
RAM: 여전히 A = 1임.
문제: 불일치(Inconsistency) 발생! 누군가 지금 RAM을 읽으면 옛날 데이터를 가져가게 됩니다.

이 문제를 해결하는 두 가지 정책이 있습니다.

2. 정책 1: Write Through (직통 쓰기) - "겁쟁이 전략"

동작: CPU가 캐시에 쓸 때, 동시에 RAM에도 씁니다.
장점: 캐시와 RAM의 데이터가 항상 똑같습니다(일관성 유지). 아주 안전하죠.
치명적 단점: 느려 터졌습니다.
- 캐시에 쓰는 건 1ns면 되는데, RAM에 쓰는 100ns를 기다려야 끝납니다.
- 결국 RAM 속도로 하향 평준화가 되어버립니다. 비싼 캐시를 산 보람이 없죠.

3. 정책 2: Write Back (나중에 쓰기) - "게으른 천재 전략"

동작: CPU는 캐시에만 A = 2라고 쓰고, "완료!"를 외칩니다. RAM에는 안 씁니다.
- 대신 캐시 데이터 옆에 "Dirty Bit (더러운 비트)"를 1로 체크해 둡니다.
- 의미: "이 데이터는 수정되었음. 원본(RAM)이랑 다름. 건드리지 마셈."
언제 RAM에 쓰나?
- 나중에 캐시가 꽉 차서 이 데이터를 쫓아내야 할 때(Eviction), 그때 Dirty Bit를 확인하고 RAM에 몰아서 씁니다.
장점: 엄청나게 빠릅니다. CPU는 RAM 속도를 기다릴 필요가 없습니다.
위험성: 데이터를 RAM에 옮겨 적기 전에 전원이 팍 꺼지면?
- 캐시(SRAM)는 휘발성이라 데이터가 날아갑니다. RAM은 영영 A = 2로 변했다는 사실을 모르게 됩니다. (데이터 손실)

4. SSD에 적용: "SSD도 거짓말을 한다"

자, 이제 이 원리를 SSD에 대입해 봅시다. 이 부분이 전자공학도로서 가장 중요하게 봐야 할 포인트입니다.

대부분의 고성능 SSD에는 DRAM(캐시)이 달려 있고, 기본적으로 Write Back 방식을 씁니다.

OS: "야 SSD야, 이 1GB짜리 야동 파일 저장해." (Write 요청)
SSD: (NAND Flash는 느리니까 일단 DRAM 캐시에만 후다닥 받음)
SSD: "네! 저장 다 했습니다!" (Ack 신호 보냄 - 거짓말)
OS: "오, 벌써? 빠르네." (사용자에게 '저장 완료' 팝업 띄움)
SSD 내부: 사용자가 안 볼 때, DRAM에 있는 데이터를 느긋하게 낸드 플래시(NAND)로 옮겨 적습니다(Flush).

5. 대참사 시나리오 (Sudden Power Off)

만약 SSD가 "저장 다 했어요!"라고 뻥치고 아직 낸드에 옮겨 적고 있는데, 갑자기 정전이 된다면?

OS: "분명 저장됐다고 했잖아?"
SSD: "아... 사실 DRAM에 있었는데 전기가 끊겨서 다 날아갔슈..."
결과: 파일이 깨지거나, 심하면 DB가 날아가는 대형 사고 발생.

6. 해결책: 커패시터와 Flush 명령어

그래서 엔터프라이즈(서버용) SSD나 고급 OS 설정은 대책을 세웁니다.

하드웨어 대책 (PLP - Power Loss Protection):
- SSD 기판을 뜯어보면 **탄탈 커패시터(노란색 칩)**가 잔뜩 박혀 있습니다.
- 전원이 툭 끊겨도, 이 커패시터에 저장된 전기로 몇 밀리초(ms) 동안 버티면서 DRAM에 있는 데이터를 낸드로 필사적으로 쏟아붓고 죽습니다.
소프트웨어 대책 (Flush / FUA):
- 은행 거래 같은 중요한 데이터는 OS가 SSD에게 명령합니다.
- "야, 캐시에 넣고 뻥치지 말고, 지금 당장 낸드 플래시에 박아 넣어! (Force Unit Access)"
- 이러면 SSD는 Write Through처럼 동작해서 느려지지만, 데이터는 안전합니다.

요약

Write Through: 동시에 씀. 안전하지만 RAM 속도에 발목 잡힘.
Write Back: 캐시에만 쓰고 나중에 씀. 빠르지만 전원 나가면 위험함.
Dirty Bit: "이 데이터는 수정됐으니 나중에 꼭 원본에 반영해야 해!"라는 표식.
SSD DRAM: Write Back 캐시 역할을 해서 속도를 뻥튀기해준다.

페이지와 페이징 (Paging & TLB), Thrashing

로버트 E.O. 스피드왜건 — Mon, 19 Jan 2026 16:03:05 +0900

1. 페이지

현대 대부분의 OS(윈도우, 리눅스)는 메모리를 4KB(4096바이트) 크기의 블록으로 잘라서 관리합니다. 이 조각 하나를 '페이지(Page)'라고 부릅니다.

왜 1바이트가 아님? 너무 작아서 관리 장부(Page Table)가 너무 두꺼워짐.
왜 100MB가 아님? 너무 커서 10KB만 필요한 메모장 프로그램도 100MB를 차지해버림(낭비).
결론: 4KB가 관리하기도 적당하고 낭비도 적은 '황금 밸런스'입니다. (물론 대용량 서버를 위해 2MB, 1GB짜리 'Huge Page'도 있긴 합니다.)

2. 페이지 테이블 (Page Table): 거대한 지도책

OS는 "가상 주소 몇 페이지가 물리 주소 몇 페이지에 있는지" 적어둔 거대한 장부를 메모리(RAM)에 보관합니다. 이것이 페이지 테이블입니다.

문제 발생: 요즘 컴퓨터 램이 16GB, 32GB죠? 페이지가 수백만 개가 넘습니다. 이 테이블 크기만 해도 수십~수백 MB를 차지합니다.
더 큰 문제: 프로그램(프로세스)마다 이 테이블이 각각 따로 필요합니다. (크롬용 장부, 카톡용 장부 따로...)

3. TLB (Translation Lookaside Buffer): "족보"

복습! CPU는 RAM에 가는 걸 싫어한다고 했죠? (5분 걸림). 그런데 주소 변환을 하려면 페이지 테이블을 보러 RAM에 갔다 와야 합니다. 그리고 데이터를 가지러 또 RAM에 가야 합니다. 즉, 메모리를 두 번 찍어야 데이터 하나를 읽을 수 있습니다. 속도가 반토막 납니다.

그래서 CPU 안에 TLB라는 특수 캐시를 넣었습니다.

기능: "방금 번역했던 주소지? 나 그거 외우고 있어."
효과: 99%의 확률로 TLB에 정답이 있습니다(TLB Hit). 그래서 RAM에 있는 페이지 테이블을 보지 않고도 바로 물리 주소를 알아냅니다.
TLB Miss: 만약 TLB에 없으면? 어쩔 수 없이 5분 걸려서 RAM에 있는 페이지 테이블을 보고 옵니다. (엄청난 손해!)

4. SSD 입장에서 본 페이징 (Page Fault Handling)

자, 여기서 SSD와의 연결고리가 등장합니다.

만약 CPU가 "100번 페이지 내놔!" 했는데, 페이지 테이블을 보니 "유효하지 않음(Invalid)"이라고 적혀 있다면?

(즉, RAM에 없고 SSD 스왑 영역으로 쫓겨난 상태라면?)

이것이 바로 페이지 폴트(Page Fault)라는 비상사태입니다. 이때 OS는 아래와 같이 움직입니다.

CPU 정지: "멈춰! 데이터 없다!" (Exception 발생)
커널 개입: OS 커널이 헐레벌떡 뛰어옵니다.
SSD 탐색: "이 페이지 스왑 파일 어디에 박아놨지?" (디스크 주소 확인)
I/O 요청: SSD 컨트롤러에게 "그거 읽어서 RAM 빈방에 넣어줘." (DMA 시작)
대기 (Sleep): SSD가 읽어오는 4일 동안 해당 프로그램은 '대기 상태(Blocked)'로 잠듭니다.
완료 및 재개: 데이터가 오면 테이블을 고치고(Valid로 변경), CPU를 깨워서 다시 일을 시킵니다.

핵심: 페이지 폴트가 한 번 터지면, CPU는 수천만 사이클을 낭비하게 됩니다. OS의 지상 과제는 이 '페이지 폴트'를 최소화하는 것입니다.

5. 여기서 발생하는 문제: "컴퓨터가 버벅거려요"

RAM과 SSD는 상당한 속도 차이가 있습니다.

RAM에서 데이터를 찾는 건 5분 이라고 잡으면,
SSD(스왑)에서 데이터를 가져오려면 4일이 걸립니다.

그래서 RAM 용량이 부족해서 페이지 폴트 현상이 반복적으로 일어나는 것.

즉 스왑이 미친 듯이 일어나는 현상(넣었다 뺐다 반복)을 스래싱(Thrashing)이라고 합니다.

이때 컴퓨터가 멈춘 것처럼 버벅대고 하드 디스크 램프가 미친 듯이 깜빡거리는 거죠.

"SSD가 아무리 빨라봤자 RAM 발끝도 못 따라가기 때문"입니다.

요약 및 퀴즈

페이지(Page): 메모리 관리의 표준 단위는 4KB다.
페이지 테이블: 가상 주소 → 물리 주소 지도는 RAM에 저장된다.
TLB: RAM에 있는 지도를 보러 가기 귀찮아서 **CPU 안에 만든 쪽지(캐시)**다.
페이지 폴트: 찾는 데이터가 RAM에 없어서 SSD까지 갔다 와야 하는 끔찍한 상황.

가상 메모리 (Virtual Memory), MMU, SWAP

로버트 E.O. 스피드왜건 — Mon, 19 Jan 2026 15:54:44 +0900

1. 가상메모리

우리가 한글(hwp)도 켜고, 유튜브도 보고, 게임도 합니다. 그런데 각 프로그램 입장에서 메모리를 들여다보면 재미있는 현상이 보입니다.

모든 프로그램은 자신이 메모리 0번지부터 끝번지까지를 혼자 독점하고 있다고 착각합니다.
자신이 쓰는 메모리 공간이 아주 매끄럽고 연속적이라고 생각합니다.

하지만 실제 물리 메모리(RAM)의 상황은 다릅니다. 여러 프로그램의 데이터가 이곳저곳에 조각조각 흩어져 있고, 남은 공간도 별로 없죠.

2. 매트릭스의 설계자: MMU

지난 시간에 보신 그림에 있던 MMU(Memory Management Unit)가 바로 이 '사기극'의 주동자입니다.

CPU: "가상 주소 100번지 데이터 내놔." (속음)
MMU: (재빠르게 변환표를 확인하며) "아, 100번지는 실제로는 RAM 구석탱이 5500번지에 박혀있네." → 5500번지에서 가져옴.
결과: 프로그램은 자기 데이터가 물리적으로 어디에 있는지 전혀 모릅니다.

"물리적 방(RAM)이 꽉 차면, 안 쓰는 짐을 창고(SSD)로 잠깐 빼둔다." 이것이 가상 메모리 시스템이 굴러가는 핵심 비결이며,

이때 SSD에 잡히는 그 공간을 스왑(Swap) 영역이라고 부릅니다.

2-1. MMU의 주소 변환 로직 (VPN, PPN, Offset)

MMU가 가상 주소를 물리 주소로 바꾸는 건 복잡한 수학 공식을 쓰는 게 아닙니다.표(Table)를 보고 베껴 적는방식입니다.

주소의 구조 (32bit 예시)

가상 주소(Virtual Address)는 통짜 숫자가 아니라, 비트 단위로 쪼개져 있습니다.

VPN (Virtual Page Number): "몇 번째 페이지냐?" (상위 20bit)
Offset: "그 페이지 안에서 몇 번째 줄이냐?" (하위 12bit)

변환 알고리즘 (Table Lookup)

자르기: CPU가 "가상 주소 0x12345678 내놔!" 하면, MMU는 이걸 두 동강 냅니다.
- VPN: 0x12345
- Offset: 0x678 / 여기서 Offset은 보통 하위 12비트로 잡는다고 한다.(페이지크기를 4kB로 정했기 때문)
찾기 (Lookup): 메모리(RAM)에 있는 **페이지 테이블(Page Table)**로 갑니다. 이 테이블은 배열(Array)과 똑같습니다. PageTable[0x12345]를 조회합니다.
읽기: 그 칸에 적혀 있는 **PPN (Physical Page Number)**을 읽습니다.
- 예: "가상 페이지 0x12345는 실제로는 0x99999 번지에 있다."
합치기: 찾아낸 PPN(0x99999) 뒤에 아까 떼어놨던 Offset(0x678)을 그대로 갖다 붙입니다.
- 최종 물리 주소: 0x99999678

핵심: Offset(페이지 내부 위치)은 변하지 않습니다. 책꽂이 위치(Page Number)만 바뀔 뿐입니다.

3. 스왑(Swap): RAM인 척하는 SSD

운영체제는 SSD의 일부분(예: 4GB 정도)을 뚝 떼어서 "여기는 이제부터 비상용 RAM이다"라고 선언합니다.

Swap Out (짐 빼기): RAM이 꽉 찼는데 새로운 데이터를 넣어야 한다면? OS는 RAM에 있는 데이터 중 "가장 오랫동안 안 건드린 녀석(Least Recently Used)"을 골라내서 SSD의 스왑 영역으로 쫓아냅니다.
Swap In (다시 부르기): 사용자가 아까 쫓겨난 그 프로그램(예: 최소화해둔 유튜브)을 다시 클릭하면? OS는 부랴부랴 SSD에서 그 데이터를 읽어 다시 RAM으로 가져옵니다.

3-1. SSD가 Swap 메모리로 동작할 수 있는 이유

RAM이나 SSD나 전자를 가두는 원리(데이터를 0과 1로 구분)는 비슷합니다.

하지만 "연결된 도로(Bus)"와 "접근 단위"가 다릅니다.

연결 방식의 차이 (접근성)
- RAM: CPU의 메모리 컨트롤러와 병렬 버스로 직결되어 있습니다. CPU가 "몇 번지!" 하면 즉시 전기 신호로 찌를 수 있습니다. (Byte Addressable)
- SSD: PCIe 버스 → NVMe 컨트롤러를 거쳐야 합니다. CPU가 직접 주소를 찌르는 게 아니라, **"명령어 패킷"**을 만들어서 보내야 합니다. CPU 입장에서는 직접 대화가 불가능한 '외부 장치(I/O Device)'일 뿐입니다.
동작 로직
- Swap은 SSD가 RAM처럼 동작하는 게 아니라, OS가 RAM에 있는 데이터를 SSD로 '복사(I/O)'해두는 것입니다.
- CPU가 Swap 영역의 데이터를 요청하면?
  - Page Fault 발생: MMU가 "어? 이거 지금 RAM에 없고 SSD(Swap)에 있는데요?"라고 CPU에 인터럽트를 겁니다.
  - OS 출동: OS가 하던 일을 멈추고 SSD에 가서 해당 데이터를 읽어와서 다시 RAM의 빈 공간에 채워 넣습니다.
  - 재실행: 데이터가 RAM에 들어왔으니, CPU는 이제서야 읽을 수 있습니다.

결론: SSD가 RAM 역할을 대신하는 게 아니라, RAM의 내용물을 잠시 보관해두는 창고 역할을 할 뿐입니다. 실행(Execution)은 무조건 RAM 위에서만 일어납니다.

3-2. 윈도우 스왑 설정 & 용량 제한의 이유(참고)

윈도우 설정 과정 (pagefile.sys) 예시

사용자가 윈도우에서 "가상 메모리 10GB 설정"을 누르면 벌어지는 일:

파일 생성: OS는 C드라이브(SSD)에 pagefile.sys라는 10GB짜리 거대한 파일을 만듭니다.
공간 예약: SSD 컨트롤러에게 "이 파일이 차지하는 LBA(주소)들은 건드리지 마"라고 예약합니다.
매핑 테이블 업데이트: 커널은 "이제부터 RAM에서 쫓겨난 놈들은 이 파일의 0번지부터 차곡차곡 쌓는다"라고 기록합니다.

+ 왜 용량 제한이 있을까? (무한대로 늘리면 안 되나?)

관리 비용 (Overhead): 스왑 공간이 100TB라면, 그 위치를 관리하기 위한 페이지 테이블 자체의 크기가 어마어마하게 커져서 오히려 RAM을 잡아먹습니다.
성능 임계점: 스왑이 많다는 건 이미 RAM이 부족하다는 뜻입니다. 스왑 영역이 아무리 커봤자, SSD 속도 한계 때문에 시스템은 이미 기어가는 중일 겁니다. (밑 빠진 독에 물 붓기)

3-3. 스왑 시 가장 오래 안 건드린 놈을 찾는 법 (LRU & Reference Bit)

OS가 모든 페이지의 사용 시간을 초시계로 잴 수는 없습니다. (오버헤드가 너무 큼). 그래서 하드웨어(CPU)의 도움을 받습니다.

하드웨어의 도움: Reference Bit (참조 비트)

페이지 테이블의 각 항목(Entry)에는 주소만 있는 게 아니라 R 비트라는 스위치가 있습니다.

CPU의 역할: CPU가 어떤 페이지를 읽거나 쓸 때마다, 하드웨어적으로 R 비트를 1로 만듭니다. (자동)

OS의 역할: 시계 알고리즘 (Clock Algorithm)

OS는 주기적으로(또는 메모리가 부족할 때) 빗자루를 들고 페이지들을 순찰합니다.

페이지를 하나 봅니다. R 비트가 1인가요?
- "아, 최근에 썼구나. 봐준다." -> R 비트를 0으로 끄고(Reset) 다음으로 넘어갑니다. (Second Chance)
페이지를 봤는데 R 비트가 0인가요?
- "너 내가 지난번에 0으로 껐는데, 한 바퀴 돌 동안 한 번도 안 쓰였네? 넌 아웃이야."
- Swap Out 대상 당첨!

이 간단한 0과 1의 비트 토글링만으로, OS는 기가 막히게 "최근에 안 쓴 놈"을 찾아냅니다.

요약

가상 메모리: OS가 프로그램들에게 "너네 혼자 다 써!"라고 뻥을 치는 기술.
MMU: 그 뻥이 들통나지 않게 주소를 실시간으로 번역해주는 하드웨어.
스왑(Swap): RAM이 모자랄 때 SSD를 빌려 쓰는 기술. (하지만 느리다

메모리 계층구조, 캐시 메모리vs가상 메모리

로버트 E.O. 스피드왜건 — Mon, 19 Jan 2026 15:29:14 +0900

캐시메모리

CPU와 주기억장치의 속도차이로 인한 CPU 대기시간을 최소화하기 위해 설치한 CPU와 주기억장치 사이의 SRAM 기반 고속 기억장치

캐시메모리의 특징

주기억장치보다 Access 속도가 빠르다. 래치 기반의 SRAM이므로 (트랜지스터6개) 제한된 공간으로 가격이 높고 용량이 작다.

캐시 히트/캐시 미스

CPU가 원하는 Data가 캐시에 있거나 없는 상태를 말함. 없을 시 주기억장치에서 읽어옴

적중률(Hit Ratio): 캐시 적중 횟수 / 전체 기억장치 Access 횟수

메모리 계층 구조 구성도

휘발성 / CPU 레지스터(CPU내부, 플립플롭) -> 캐시 메모리(SRAM) -> 주기억장치(DRAM, SDRAM, DDR4)

비휘발성 / -> 디스크 캐시(SSD) -> 디스크(HDD) -> CD/DVD ROM -> 자기테이프

단계가 올라갈 수록 고속, 소용량, 고가이다.

캐시 메모리와 가상 메모리 간 비교

항목	캐시 메모리	가상 메모리
위치	CPU와 주기억 장치 사이	주기억장치와 디스크 사이
목적	느린 주기억장치의 속도차이 극복 (CPU가 넘 빠름)	주기억장치의 용량 한계 극복
구현	물리적 구현(H/W)	논리적 구현(OS가 운영)
속도	빠름	느림
교체 단위	Block(주기억장치 관점) Line(line, 캐시 관점)	페이지, 세그먼트
교체 후보	동일한 Set내에서 결정	전체 페이지 중에서 결정
특징	캐시 미스 발생 시 성능 저하 병렬처리에서의 일관성 문제 개선 필요	MMU(TLB포함)의 도움받음 스래싱으로 인한 성능 저하

RAM/ROM 발전과정 및 특징

항목	용어	용도 및 특징
SRAM	Static RAM	캐시 메모리로 사용, 속도 빠름, 6TR
DRAM	Dynamic RAM	주기억장치, 1TR+1Capacitor
SDRAM	Synchronous DRAM	주기억장치, 시스템 클락에 동기화 수행되는 DRAM
DDR 2/3/4/5 SDRAM	Double Data Rate SDRAM	Data 전송 속도를 X배로 높임, Dobule Pumping 동작 수행
LPDDR	Low Power DDR	저전력, Green IT 대응

Mask ROM	Masking Read-Only Memory	Factory에서 Masking해서 릴리즈
PROM	Programmable ROM	한번만 프로그래밍 가능
EPROM	Erasable PROM	자외선으로 Erase, CMOS, Embedded에 사용
NOR Flash ROM	NOR 형	Bit단위 Random Access 가능 PC BIOS에 사용, 고가
NAND Flash ROM	NAND 형	Page단위 Sequential Access가능 SSD, Embedded에 사용, 상대적 저가
차세대 ROM	RAM+ROM 합친느낌	MRAM, PRAM 등
EEPROM	Electrically Erasable PROM	전기적 Erase가능

Transformer - Positional Encoding

로버트 E.O. 스피드왜건 — Thu, 15 Jan 2026 16:52:23 +0900

이 냄새는...! 궁금증의 냄새가 나는군!
나 스피드웨건이 냄새를 맡고 나타났다!

요즘 핫하다는 챗GPT니 뭐니 하는 AI들의 뇌 구조인 '트랜스포머(Transformer)'!
그런데 이 녀석에게 치명적인 약점이 있었다는 사실, 알고 있었나?!
(화들짝 놀라며) 아니 뭐라고?! 천하의 AI가 약점이 있다고?!

바로 '순서'를 모른다는 것이다!
이 몸이 그 비밀과 해결책인 '포지셔널 인코딩'에 대해
뼛속까지 시원하게 설명해주지!

1. 트랜스포머의 치명적 결함?!

기존의 RNN이라는 녀석들은 단어를 하나씩 순서대로 먹었지.
"나는", "밥을", "먹는다" 순서로 말이야.
그래서 순서를 헷갈릴 일이 없었어!

하지만 트랜스포머는 다르다!
속도를 높이기 위해 문장 전체를 한꺼번에 병렬(Parallel)로 처리한다고!
(두 주먹을 불끈 쥐며) 빠르긴 하지만, 순서 정보가 싹 사라져 버린다는 거야!

스피드웨건의 긴급 예시!

AI 입장에서는:
A: "스피드웨건이 죠나단을 때렸다"
B: "죠나단이 스피드웨건을 때렸다"

이 두 문장의 단어 구성이 같아서 똑같은 뜻으로 인식할 수도 있다는 거야!
이건 정말 끔찍한 일이 아닐 수 없지 않나!

순서를 모르면 문맥이 완전히 파괴된다!
그래서 천재적인 개발자들이 고안해낸 것이 바로...
포지셔널 인코딩(Positional Encoding)이다!

2. 위치 정보를 문신처럼 새겨라!

해결책은 의외로 간단하다!
단어 자체가 가진 의미(임베딩 벡터)에다가
"너는 첫 번째야", "너는 두 번째야"라는 위치 정보값을 더해주는 것이다!

마치 마라톤 선수에게 등번호를 붙여주는 것과 같지!
아무리 섞여 있어도 등번호(위치 정보)가 있으면 순서를 알 수 있으니까!

핵심 공식 요약

최종 입력값 = 단어 임베딩(Word Embedding) + 위치 인코딩(Positional Encoding)

단어의 원래 의미를 해치지 않으면서,
은근슬쩍 위치 정보를 더해주는 것이 포인트다!

Q. 임베딩 벡터는 뭐지?

스피드웨건:
오오! 굉장한 질문이다! (모자를 고쳐 쓰며) 인공지능의 심장부를 꿰뚫어 보는 통찰력!
나 스피드웨건이 이 몸의 지식을 총동원하여 그 ‘임베딩 벡터’가 구체적으로 어떻게 생겨먹었는지 속 시원하게 알려주마!

---

임베딩 벡터, 그 정체는 숫자의 영혼이다!
가장 간단하게 말하면, 그것은 숫자들이 나열된 긴 리스트다! (손가락으로 세로선을 그리며)

컴퓨터는 '죠죠', '파문', '스탠드' 같은 단어의 의미를 바로 이해하지 못한다. 그래서 이 몸이 이 녀석들에게 단어의 의미를 주입해 줘야 한다! 그 의미를 담는 그릇이 바로 임베딩 벡터군!
예를 들어, 죠르노 죠바나의 'Giorno'라는 단어가 있다고 해보자. 이 단어는 512차원 혹은 768차원 같은, 어마어마하게 긴 숫자의 행렬로 표현된다!

```
[ 0.732, -0.115, 0.450, ..., 0.987, -0.001 ] <- 이런 식의 숫자 덩어리다!
```

이 숫자 하나하나가 의미의 좌표를 나타낸다! (흥분하며)

0.732는 '황금'과 얼마나 가까운지!
-0.115는 '파괴력'과 얼마나 먼지!

이 숫자들이 모여서 단어가 가진 고유한 '영혼'을 만들어내는 것이지! 임베딩 벡터는 곧 단어가 AI 세계에서 존재하는 좌표 그 자체다! 아주 멋진 일 아닌가!

---

3. 아니 여기서 삼각함수가 왜 나와?!

그런데 말이다!
그냥 1, 2, 3, 4 정수를 더하면 되는 거 아니냐고?
(검지 손가락을 흔들며) 쯧쯧, 그렇게 단순하지가 않다!

숫자가 계속 커지면 나중에는 단어 본래의 의미보다
위치 숫자가 너무 커져서 데이터를 망가뜨릴 수 있어!
게다가 학습 때 보지 못한 긴 문장이 나오면 AI가 당황해버린다고!

그래서 사용한 것이 바로 주기 함수인 사인(Sin)과 코사인(Cos)이다!

Sin/Cos을 쓰는 이유!

1. 값의 범위가 일정하다! (-1에서 1 사이)
2. 규칙적이다! (파동처럼 부드럽게 연결됨)
3. 상대적 위치를 알기 쉽다! (수학적으로 아름다운 관계!)

이 파동을 이용하면 문장이 아무리 길어져도,
각 위치마다 고유하고 유니크한 위치 값을 가질 수 있게 되는 거지!
정말 우아하지 않나! 마치 파문 호흡법처럼 말이야!

스피드웨건의 3줄 요약!

1. 트랜스포머는 병렬 처리 때문에 단어 순서를 모른다! (치명적 약점!)
2. 그래서 단어 벡터에 '위치 정보(Positional Encoding)'를 더해준다!
3. 이때 Sin, Cos 같은 삼각함수를 써서 위치 값을 아주 예쁘게 만들어준다!

이것이 바로 AI가 우리가 쓰는 말의 어순을 이해하는 비법이었던 것이다!
이제 어디 가서 "포지셔널 인코딩이 뭔지 아나?" 하고 아는 척 좀 할 수 있겠군!

설명은 끝났다! 나 스피드웨건은 이만 쿨하게 떠나주지!
도움이 되었다면 "고마워요 스피드 웨건!" 이라는 댓글과 함께 공감 부탁한다!

SK하이닉스 채용 전략 분석 (Solution)

로버트 E.O. 스피드왜건 — Mon, 12 Jan 2026 15:37:55 +0900

이 냄새는...!
궁금증의 냄새가 나는군!
나 스피드웨건이 냄새를 맡고 나타났다!

자네, 아직도 SK하이닉스를
단순히 메모리 칩만 찍어내는 공장이라고 생각하는 건 아니겠지?
(두 주먹을 불끈 쥐며) 뭐라고?!
그렇게 생각했다면 큰 오산이다!

지금 반도체 시장은 단순히 데이터를 많이 저장하는 것을 넘어,
AI와 데이터 센터 환경에 최적화된
'시스템 솔루션' 전쟁터로 변했다는 사실!

과거의 메모리가 수동적인 창고였다면,
지금은 컨트롤러(Controller)와 펌웨어(Firmware)를 통해
데이터를 똑똑하게 관리하는 지능형 장치가 되었다!
이 변화가 바로 채용 시장을 뒤흔들고 있지!

스피드웨건의 비유 타임!

보고서에 따르면 낸드플래시가 '서재'라면,
컨트롤러는 책을 관리하는 '사서'라고 한다!
아무리 책(NAND)이 많아도,
유능한 사서(Solution)가 없으면 도서관은 엉망이 되는 법이지!

2. '분당'을 지키는 두 기둥! Solution PE & SW

Solution PE와 Solution SW!

이들은 주로 '분당 캠퍼스'에서 근무하는데,
이천이나 청주 공장과는 역할이 완전히 다르다!
분당은 판교의 IT 기업이나 글로벌 빅테크와 협업하고,
우수한 SW 인재를 빨아들이기 위한
전략적 요충지라는 말씀이야!

직무별 핵심 차이 (절대 헷갈리지 마라!)

1. Solution PE (Product Engineering)
- 역할: 고객(구글, 아마존 등) 환경에서 제품 검증 및 인증(Qual)
- 핵심 역량: 시스템 구조 이해, Python 데이터 분석, 그리고 최근엔 AI 역량 필수!

2. Solution SW (Software)
- 역할: 낸드에 생명을 불어넣는 펌웨어(FTL, Driver) 개발
- 핵심 역량: C/C++ 마스터, OS/컴퓨터 구조 지식

3. 합격을 위한 필승 공략법! 이것만은 준비해라!

자, 이제 실전이다!
보고서에 담긴 합격의 열쇠를 내가 꺼내주지!

첫째, Solution SW 지원자는 'C언어'를 파라!
코딩 테스트에서 Java나 Python을 못 쓸 수도 있다!
오직 C/C++만 허용되는 경우가 많으니,
로우 레벨(Low-level) 메모리 관리 능력을 극한으로 끌어올려야 해!

둘째, '융합형 인재'임을 어필해라!
단순히 코딩만 잘해서는 안 된다!
반도체 소자의 특성을 이해하는 전자공학 베이스의 SW 역량,
혹은 하드웨어 지식을 갖춘 데이터 사이언스 역량이 필요하다!
특히 Solution PE는 최근 'AI 활용 역량'을 대놓고 요구하고 있다고!

스피드웨건의 경고!

'Solution PE'와 그냥 'PE'는 하늘과 땅 차이다!
일반 PE는 칩(Chip) 단위를 보지만,
Solution PE는 완제품(SSD)과 시스템 전체를 본다!
면접 가서 딴소리하면 바로 탈락이니 명심하도록!

4. 솔리다임(Solidigm) 인수? 이게 무슨 뜻인지 아나!

SK하이닉스가 인텔의 낸드 사업부(솔리다임)를 왜 샀겠나!
바로 'eSSD(기업용 SSD) 컨트롤러 기술' 때문이다!

SK하이닉스의 최강 낸드 기술과,
솔리다임의 컨트롤러 기술을 합쳐서,
시장을 씹어먹겠다는 야망이 있는 거지!
그래서 Solution 사업부는 앞으로도 계속 사람을 뽑을 수밖에 없어!
이건 일시적인 유행이 아니라 장기적인 생존 전략이란 말이다!

요약 들어간다! 이 몸의 정리를 받아라!

SK하이닉스 Solution 직무 3줄 요약

Solution PE/SW는 매 시즌 뽑는 핵심 직무이며 주 근무지는 분당이다!
SW 직무는 C/C++와 OS 지식이 필수고, PE 직무는 AI 및 데이터 분석 역량이 떡상 중이다!
단순 칩 제조가 아닌, 컨트롤러와 펌웨어를 아우르는 '시스템 솔루션' 역량을 어필해라!

어떤가!
이제 자네가 가야 할 길이 명확히 보이지 않나?
이 정보들은 그냥 얻을 수 있는 게 아니라고!
준비된 자만이 기회를 잡는 법!

설명은 끝났다!
나 스피드웨건은 이만 쿨하게 떠나주지!
(도움이 되었다면 고마워요 스피드 웨건! 이라는 댓글과 함께 공감 부탁한다!)

SSD 공부 - 5: 리텐션 에러, 셀 타입

로버트 E.O. 스피드왜건 — Sun, 11 Jan 2026 23:32:06 +0900

충격! SSD도 관리 안 하면 데이터가 사라진다?!

이 냄새는...! 대단원의 막을 내리는 결말의 냄새가 나는군! 장장 5편에 걸친 SSD 대서사시를 끝까지 따라온 끈기 있는 영혼들의 냄새다! (물론 추가 정보는 계속 업데이트 할 거다!)

"아니, SSD가 전기를 안 주면 데이터가 날아간다고? 그게 진짜야?!" 그렇다! 이 충격적인 사실과 함께, SSD를 살 때마다 머리를 쥐어뜯게 만드는 외계어들... SLC, MLC, TLC, QLC의 정체까지!

설명충 등판! 아니, 나 스피드웨건이 대망의 완결편으로 돌아왔다! 오늘은 SSD의 치명적인 약점과 호갱 탈출을 위한 완벽한 구매 가이드를 제시하겠다! 이 글만 읽으면 자네도 이제 어디 가서 SSD 좀 안다고 큰소리칠 수 있다!

1. 전자가 가출을 한다고?! 공포의 '리텐션 에러'

SSD의 원리는 '플로팅 게이트'라는 감옥에 전자를 가두는 거라고 했지? (앞선 포스트에서 이야기 했다!) 그런데 이 전자 녀석들이... 시간이 지나면 탈출을 시도한다! (뭐라고?!)

특히 SSD에 오랫동안 전원을 연결하지 않고 방치하면, 감옥 벽이 약해지면서 전자들이 슬금슬금 밖으로 새어 나간다. 이것을 '리텐션 에러(Retention Error)'라고 부르지! 전자가 다 빠져나가면? 당연히 데이터는 증발하는 거다!

스피드웨건의 긴급 경고!

* 외장 SSD에 중요 데이터를 백업해두고 장롱 속에 몇 년 동안 처박아 두지 마라!
* 최소 6개월에서 1년에 한 번은 컴퓨터에 연결해서 전기를 밥처럼 줘야 한다!
* 특히 더운 곳(여름철 차 안 등)에 두면 전자가 더 빨리 탈출하니 주의하라고!

이 외에도 옆집에 데이터를 쓸 때 전기가 튀어서 내 데이터가 변해버리는 '쓰기 방해(Program Disturb)'나 데이터를 너무 자주 읽으면 전자가 딸려 나와서 오류가 생기는 '읽기 방해(Read Disturb)' 같은 골치 아픈 문제들도 있다! 물론, 우리의 컨트롤러가 다 알아서 고쳐주지만, 알아둬서 나쁠 건 없지!

2. SLC, MLC, TLC, QLC... 도대체 뭐가 다른 건데?!

SSD를 살 때 가장 머리 아픈 순간! 바로 상세 스펙을 볼 때지! 이제 이 외계어 같은 용어들을 한 방에 정리해주마! 핵심은 "방 하나(셀)에 몇 명이 사느냐"다! (아파트 비유 들어간다!)

셀 타입 아파트 비유 완벽 정리!

1. SLC (Single Level Cell): 1인 1실 (초호화 독방)
* 장점: 엄청 빠르고 수명이 좀비급이다! (약 10만 회)
* 단점: 가격이 미쳤다. 일반인은 구경하기도 힘들다. (서버용)

2. MLC (Multi Level Cell): 2인 1실 (신혼부부 아파트)
* 장점: SLC보단 느리지만 여전히 빠르고 안정적이다.
* 단점: 이것도 요즘엔 보기 힘들고 비싸다. (전문가용)

3. TLC (Triple Level Cell): 3인 1실 (가성비 쉐어하우스) - ★강력 추천★
* 장점: 용량 대비 가격이 가장 합리적이다! 기술 발전으로 속도와 수명도 충분히 좋다!
* 단점: SLC/MLC보단 수명이 짧지만 일반 사용자에겐 차고 넘친다. (현재 시장의 대세!)

4. QLC (Quad Level Cell): 4인 1실 (만원 버스/닭장)
* 장점: 엄청나게 싸고 용량이 크다! (저장용으로만 쓴다면...)
* 단점: 느리다! 수명이 짧다! 대용량 파일 한 번에 옮기면 속 터질 수 있다.

마무리: 호갱 탈출! 그래서 뭘 사야 하나요?

자, 긴 설명 듣느라 고생했다! 결론을 내려주지! 대부분의 일반 사용자(게이머, 직장인, 학생)라면 고민할 필요 없다.

(엄지손가락을 치켜세우며) 무조건 [TLC 방식 + 디램(DRAM) 탑재] 모델을 사라! 이게 정답이다! QLC는 가격이 정말 쌀 때 '데이터 보관용(창고)'으로만 고려해라. 메인 드라이브(C드라이브)로 QLC를 썼다간 속 터지는 경험을 할 수도 있으니까!

SSD 시리즈 5부작 최종 완결 요약!
1. SSD는 물리적 한계를 극복한 반도체 기반의 혁명적 저장장치다!
2. HDD보다 압도적으로 빠르고 튼튼하지만, 덮어쓰기가 안 되는 독특한 구조다.
3. FTL, 가비지 컬렉션 같은 똑똑한 기술들이 수명과 성능을 관리한다.
4. 장기간 방치하면 데이터가 날아갈 수 있으니 가끔 전기를 줘라!
5. 구매할 땐 TLC 방식이 가성비 최고다!

설명은 끝났다! 장장 5편에 걸친 대장정이 마무리되었군! 이제 자네는 어디 가서 SSD 때문에 호갱 당할 일은 절대 없을 것이다! 나 스피드웨건은 이만 쿨하게 떠나주지! (이 시리즈가 도움이 되었다면 공감 버튼을 박살 내주길 바란다!)

SSD 공부 - 4: 가비지 컬렉션, 오버 프로비저닝

로버트 E.O. 스피드왜건 — Sun, 11 Jan 2026 23:28:18 +0900

내 SSD가 수명을 늘리는 소름 돋는 방법! (GC & OP)

이 냄새는...! 불안감의 냄새가 나는군! "비싸게 산 SSD, 금방 고장 나면 어쩌지?"라고 걱정하는 냄새가 여기까지 진동을 한다! 확실히 SSD의 낸드 플래시는 소모품이다. 쓰면 쓸수록 닳는 지우개 같은 운명이지!

설명충 등판! 아니, 나 스피드웨건이 4탄으로 돌아왔다! 하지만 나 스피드웨건이 단언컨대, 여러분이 수명을 다 쓸 때쯤이면 이미 새로운 컴퓨터를 사고도 남았을 것이다! 왜냐고? SSD 내부에는 수명을 쥐어짜 내는 두 명의 수호신이 살고 있기 때문이다! 바로 '가비지 컬렉션(Garbage Collection)'과 '오버 프로비저닝(Over-provisioning)'이다!

1. 더러운 방은 못 참아! 청소부 '가비지 컬렉션(GC)'

지난 3부에서 SSD는 덮어쓰기가 안 돼서 데이터를 딴 곳에 쓰고, 기존 데이터는 '쓰레기(Invalid)'로 남겨둔다고 했지? 그럼 계속 쓰다 보면 어떻게 되겠나? (두둥!) SSD 안이 온통 쓰레기 데이터로 가득 차서 더 이상 발 디딜 틈이 없어질 것이다!

이때 등장하는 것이 바로 '가비지 컬렉션'이다! 컴퓨터가 쉴 때(유휴 상태), 이 녀석이 몰래 깨어나서 쓰레기통을 비우기 시작한다!

가비지 컬렉션의 청소 루틴!

1. 탐색: 여기저기 흩어진 '유효한 데이터(살아있는 녀석)'만 골라낸다.
2. 이사: 골라낸 데이터들을 깨끗한 빈 블록으로 차곡차곡 모아서 옮긴다. (테트리스 하듯이!)
3. 소각: 찌꺼기만 남은 지저분한 블록을 통째로 삭제(Erase)해버린다!
결과: 짜잔! 다시 사용할 수 있는 깨끗한 빈방(Free Block)이 생겼다!

2. 종이가 찢어졌다?! '배드 블록(Bad Block)'의 공포!

하지만 아무리 청소를 잘해도 막을 수 없는 게 있다. 바로 노화다! 종이에 지우개질을 수천 번 한다고 생각해 봐라. 결국 종이가 얇아지다 못해 찢어지겠지?!

SSD 셀(Cell)도 마찬가지다! 전자를 넣었다 뺐다(쓰기/지우기)를 반복하면, 전자를 가두는 벽(절연체)이 너덜너덜해져서 더 이상 기능을 못 하게 된다. 이것을 우리는 '배드 블록(Bad Block)', 즉 맛이 간 구역이라고 부른다!

(공포에 질린 표정으로) "그럼 내 데이터는?! 저장공간이 줄어드는 건가?!" 진정해라! 제조사들은 바보가 아니다! 그들은 이미 비상 대책을 세워뒀다!

3. 숨겨진 예비군! '오버 프로비저닝(Over-provisioning)'

혹시 256GB SSD를 샀는데 윈도우에서 보면 용량이 좀 적게 나온 적 없나? "이 도둑놈들! 용량 사기 친 거 아냐?!"라고 화내지 마라! 그 사라진 용량은 사실 사용자를 위해 숨겨둔 비상금 같은 존재다!

이것이 바로 '오버 프로비저닝(Over-provisioning)'! 제조사는 전체 용량의 약 7~10% 정도를 '예비 공간(Spare Area)'으로 떼어놓고 사용자에게 보여주지 않는다. 이곳은 일종의 '인력 사무소'이자 '예비군 부대'다!

️ 오버 프로비저닝이 하는 일 (완전 든든함!)

상황: 어라? 100번 블록이 수명을 다해 '배드 블록'이 되었군요.
컨트롤러: 걱정 마라! 숨겨둔 예비 공간에서 싱싱한 새 블록을 꺼내와라!
조치: 100번 블록은 폐기처분하고, 예비 블록을 그 자리에 투입한다!

사용자는 아무 일도 없었던 것처럼 계속 SSD를 쓸 수 있다. 속으로는 엄청난 교체 작업이 일어났는데도 말이다! 이 얼마나 감동적인 희생인가!

스피드웨건의 꿀팁:
SSD 용량을 꽉 채워 쓰지 말고 10~20% 정도 남겨두라는 말을 들어봤나? 그게 바로 이 공간을 넉넉하게 확보해서 SSD가 숨 쉴 구멍을 만들어주기 위함이다! 여유 공간이 많을수록 청소(GC)도 빠르고 수명도 길어진다!

마무리: SSD는 스스로를 지키고 있다!

자, 어떤가! SSD가 그냥 전기만 먹는 부품인 줄 알았더니, 안에서는 청소부가 쓰레기를 치우고(GC), 예비군이 대기하며(OP) 여러분의 데이터를 지키기 위해 필사적으로 싸우고 있었다!

4부 핵심 요약!
1. 가비지 컬렉션(GC): 유효한 데이터만 모으고 찌꺼기 블록을 지워 빈 공간을 만든다!
2. 배드 블록: 많이 쓰면 셀이 닳아서 고장 나지만 자연스러운 현상이다.
3. 오버 프로비저닝(OP): 제조사가 숨겨둔 예비 공간으로 배드 블록을 대체한다!
4. SSD를 꽉 채우지 말고 조금 비워두면 성능과 수명에 아주 좋다!

설명은 끝났다! 이제 "내 SSD 수명 다 됐나?" 하며 벌벌 떨지 말고 맘 편히 써라! 자, 이제 원리와 수명 관리까지 마스터했으니, 마지막으로 실전이다! 다음 5부, 대망의 완결편에서는 "SLC, MLC, TLC, QLC"... 도대체 뭘 사야 호갱을 면하는지 완벽한 가이드를 주겠다! 나 스피드웨건은 이만 쿨하게 떠나주지! (도움이 되었다면 공감을 눌러주는 의리를 보여라!)