UFS 저장장치, eMMC의 병렬 한계를 직렬로 푼 구조
갯벌에 난 좁은 물길 하나로 밀물과 썰물이 번갈아 드나든다고 상상해 보세요. 물이 들어오는 동안에는 나갈 물이 기다려야 하고, 방향이 바뀔 때마다 흐름이 한 번 멈춥니다.
스마트폰 안의 저장장치에서도 비슷한 일이 있었습니다. 이 글에서 다룰 UFS 저장장치는 그 좁은 물길을 두 갈래로 나눠, 들어오는 길과 나가는 길을 따로 둔 구조입니다.
갯벌과 다른 점도 있습니다. 물길은 지형이 정해 주지만 저장장치의 길은 설계로 정해지고, 길을 아무리 넓혀도 물을 대 주는 낸드와 컨트롤러가 못 따라오면 그 넓이를 다 쓰지 못합니다. 이 부분은 뒤에서 가상 계산으로 확인해 보겠습니다.
UFS 저장장치가 eMMC 다음 자리를 차지하게 된 배경
UFS(Universal Flash Storage)는 JEDEC에서 정한 플래시 저장장치 규격으로, 스마트폰과 태블릿, 차량용 기기처럼 크기와 전력이 제한된 기기를 겨냥합니다. 이전 세대 격인 eMMC(embedded MultiMediaCard)를 이어받는 규격으로 자리 잡아 왔습니다.
두 규격 모두 낸드 플래시와 컨트롤러를 하나의 패키지에 담은 관리형 낸드입니다. 컨트롤러가 주소 변환과 오류 정정, 불량 블록 관리를 맡기 때문에, 메인 프로세서는 낸드의 세부 사정을 몰라도 저장장치를 쓸 수 있습니다.
그렇다면 무엇이 달라졌을까요. 낸드 자체가 아니라 컨트롤러와 메인 프로세서 사이를 잇는 인터페이스가 바뀌었습니다. 카메라 해상도와 앱 크기가 커지면서, 이 인터페이스가 전체 속도를 가로막는 구간이 되었기 때문입니다.
eMMC의 병렬 반이중 구조가 부딪힌 한계
eMMC는 클럭 신호와 함께 최대 여덟 가닥의 데이터 선이 나란히 달리는 병렬 인터페이스입니다. 병렬 방식은 속도를 올리려 하면 선들 사이의 타이밍을 맞추기가 어려워지고, 선이 많아 배선과 핀 수도 부담이 됩니다.
또 하나의 제약은 반이중(Half Duplex)입니다. 데이터 선을 읽기와 쓰기가 번갈아 공유하므로, 읽는 동안에는 쓸 수 없고 쓰는 동안에는 읽을 수 없습니다. 앱을 실행하면서 사진을 저장하는 것처럼 두 일이 겹치는 상황에서는 서로 차례를 기다려야 합니다.
이런 한계는 직렬 고속 인터페이스로 넘어가는 흐름과도 이어집니다. 선을 여러 개 나란히 놓고 한꺼번에 흔드는 대신, 선 한 쌍으로 훨씬 빠르게 신호를 보내는 쪽으로 업계 전반이 이동한 흐름입니다.
UFS의 계층 구조와 직렬 레인, 명령 큐
UFS 저장장치는 하나의 레인(Lane)을 차동 신호로 보내는 직렬 쌍 두 개로 구성합니다. 하나는 호스트에서 저장장치로 가는 방향, 다른 하나는 저장장치에서 호스트로 오는 방향이라서, 읽기와 쓰기 신호가 서로 다른 선을 타고 동시에 오갈 수 있습니다. 이런 구조를 전이중(Full Duplex)이라고 합니다.
명령 처리도 달라졌습니다. UFS는 SCSI 구조를 바탕으로 명령에 번호표를 붙여 여러 개를 줄 세워 두는 방식(태그 큐잉)을 지원하므로, 앞선 명령이 끝나기 전에 다음 명령을 보내 낸드를 쉬지 않게 만들 수 있습니다.
UFS의 계층과 명령이 거치는 길
- 호스트의 애플리케이션이 읽기나 쓰기 요청을 만듭니다. 이 요청은 SCSI 계열의 명령으로 표현됩니다.
- UFS 전송 계층(UTP)이 명령을 패킷으로 감싸 번호표를 붙입니다.
- 링크 계층인 UniPro가 패킷을 오류 없이 순서대로 전달하도록 관리합니다.
- 물리 계층인 M-PHY가 직렬 레인으로 전기 신호를 내보냅니다.
- 저장장치 안의 컨트롤러가 명령을 받아 주소 변환을 거쳐 낸드에 접근하고, 결과를 반대 방향 레인으로 돌려보냅니다.
UniPro와 M-PHY는 MIPI 얼라이언스가 모바일 기기용으로 정한 규격입니다. 스마트폰 안에서 이미지 센서나 디스플레이도 MIPI 계열 인터페이스를 쓰므로, 같은 계열의 직렬 기술이 저장장치에도 적용된 것으로 볼 수 있습니다.
전력도 설계에서 중요한 요소였습니다. 쓰지 않을 때는 링크를 저전력 상태로 내렸다가 필요할 때 깨우는 구조를 갖춰, 배터리로 동작하는 기기에서 대기 중 소모를 줄이도록 만들었습니다.
반이중과 전이중을 가상 계산으로 비교
전이중이 도움이 되는 정도를 단순한 숫자로 가늠해 보겠습니다. 읽기와 쓰기를 동시에 처리하는 상황에서 한쪽 방향 링크 속도가 같다고 두면 됩니다.
가상 계산 예시, 읽기와 쓰기가 겹칠 때실제 제품 값이 아니라 설명을 위한 가정입니다. 한 방향 링크 속도를 1 GB/s, 읽을 데이터 1 GB와 쓸 데이터 1 GB가 동시에 몰렸다고 두고, 방향 전환 오버헤드는 무시합니다.
반이중에서는 두 일이 같은 길을 번갈아 쓰므로 (1 + 1) GB ÷ 1 GB/s = 2초가 걸립니다. 전이중에서는 읽기와 쓰기가 각자의 길로 동시에 진행되어 max(1, 1) = 1초면 끝납니다.
물론 이 계산은 낸드가 읽기와 쓰기를 동시에 소화할 수 있다는 전제가 있습니다. 실제로는 컨트롤러와 낸드 쪽이 먼저 한계가 되는 일이 많아서, 전이중의 이점은 두 일이 실제로 겹치는 일부 상황에서 주로 나타납니다.
그래서 링크 속도가 곧 체감 속도라는 생각은 정확하지 않습니다. 인터페이스가 2 GB/s까지 열려 있어도 낸드 쪽이 1.5 GB/s만 내놓는다면 실제 속도는 1.5 GB/s로 막히며, 전체 속도는 가장 느린 구간이 정합니다.
세대가 올라가며 확장된 방향
UFS 저장장치는 규격이 개정될 때마다 크게 세 방향으로 확장되어 왔습니다. 첫째는 레인당 속도를 올리는 것이고, 둘째는 레인을 한 개에서 두 개로 늘려 대역폭을 곱하는 것입니다. 세대별 구체 속도는 계속 갱신되므로 최신 규격 문서에서 확인하는 것이 안전합니다.
셋째는 기능 추가입니다. 쓰기를 빠르게 받아 두는 임시 영역을 활용하는 기능, 컨트롤러가 가진 주소 변환 정보의 일부를 호스트 메모리에 두어 읽기를 줄이는 기능, 저전력 상태 확대, NVMe처럼 여러 큐를 쓰는 방향의 개선이 규격 개선판에 단계적으로 더해져 왔습니다.
이 방향은 SSD 쪽 변화와 닮았습니다. 모바일에서도 큐를 늘리고 호스트와 저장장치가 일을 나누는 쪽으로 가는데, 다만 배터리와 발열 제약이 훨씬 엄격해서 같은 방식을 그대로 가져오지는 못합니다.
eMMC와 UFS 비교 표
| 구분 | eMMC | UFS |
|---|---|---|
| 신호 방식 | 클럭과 병렬 데이터 선(최대 8비트) | 차동 직렬 레인(MIPI M-PHY) |
| 방향 | 반이중, 읽기와 쓰기가 같은 선을 번갈아 사용 | 전이중, 읽기와 쓰기 방향의 레인이 따로 존재 |
| 명령 체계 | MMC 계열 명령 | SCSI 기반 명령, 태그 큐잉 |
| 확장 방법 | 클럭 상승과 버스 폭에 의존 | 레인당 속도 상승과 레인 수 증가 |
| 구성 | 낸드와 컨트롤러를 한 패키지에 담은 관리형 낸드 | 낸드와 컨트롤러를 한 패키지에 담은 관리형 낸드 |
| 놓치기 쉬운 점 | 링크 속도가 곧 체감 속도라는 생각에 주의합니다. 낸드와 컨트롤러가 먼저 한계가 될 수 있습니다. | |
핵심 정리
UFS 저장장치는 병렬이면서 반이중이던 eMMC의 인터페이스를 직렬 전이중으로 바꾸고, SCSI 기반 명령 큐를 얹어 모바일 기기의 속도 한계를 넓힌 규격입니다. 낸드와 컨트롤러를 한 패키지에 담는 점은 같지만, 둘을 잇는 길이 달라졌습니다.
갯벌의 물길을 들어오는 쪽과 나가는 쪽으로 가른 것이 UFS이고, 규격이 개정될 때마다 길의 폭과 속도, 부가 기능이 차례로 늘어 왔습니다. 다만 물을 대 주는 낸드와 컨트롤러가 따라오지 못하면 길은 비어 있게 되므로, 인터페이스 숫자 하나만으로 성능을 판단하지는 않습니다.
면접 대비 질문
면접 대비 질문모바일 저장장치가 eMMC에서 UFS로 옮겨 간 기술적 이유를 인터페이스 구조 관점에서 설명해 보세요.
[답변 포인트] eMMC가 병렬 버스에 반이중이라 속도를 올릴수록 타이밍과 배선 부담이 크고 읽기와 쓰기가 같은 길을 번갈아 써야 한다는 점으로 시작합니다. UFS는 M-PHY 직렬 레인을 읽기와 쓰기 방향으로 나눈 전이중이고, SCSI 기반 태그 큐잉으로 여러 명령을 동시에 걸어 둘 수 있다고 연결합니다. 세대가 올라가며 레인당 속도와 레인 수, 기능이 확장되었다는 점, 컨트롤러와 낸드가 병목이 되면 링크 속도만큼 체감 속도가 나오지 않는다는 점, 모바일이라 저전력 설계가 함께 중요하다는 점까지 덧붙이면 좋습니다.









