MAC OS vs Window

msgo·2025년 12월 22일

스터디 운영체제

맥북은 16GB 메모리 환경에서도 비교적 많은 작업을 동시에 수행할 수 있다는 인상을 준다.
반면 동일한 작업을 Windows 환경에서 수행할 경우 메모리 부족이나 성능 저하를 체감하는 경우가 많다.

이 차이는 단순한 메모리 용량의 문제가 아니다.
운영체제가 메모리를 어떤 자원으로 인식하고, 어떤 우선순위로 관리하는지에 대한 설계 철학과 구현 전략의 차이에서 비롯된다.

이 글에서는 Windows와 macOS의 커널 구조, 메모리 관리 방식, 스왑 전략, 그리고 Apple Silicon 기반의 유니파이드 메모리 구조를 중심으로 이러한 차이를 정리한다.

핵심 용어 정리

본격적인 비교에 앞서, 운영체제 메모리 관리의 핵심 개념들을 정리.

커널

커널은 운영체제의 핵심 구성 요소다.
하드웨어와 사용자 공간 사이에서 자원 관리와 제어를 담당한다.

주요 역할은 다음과 같다.

프로세스 및 스레드 관리
메모리 할당과 회수
파일 시스템 관리
디바이스 드라이버 관리

커널은 일반적으로 두 가지 실행 모드를 가진다.

커널 모드: 하드웨어 직접 접근 가능
사용자 모드: 제한된 명령만 실행 가능

가상 메모리

가상 메모리는 물리 메모리보다 큰 주소 공간을 프로세스에 제공하는 메모리 관리 기법이다.

프로세스는 연속적인 논리 주소 공간을 사용하지만, 실제 물리 메모리는 불연속적으로 배치된다.
이 변환 과정은 MMU와 페이지 테이블을 통해 수행된다.

가상 메모리의 목적은 다음과 같다.

프로세스 간 메모리 격리
물리 메모리보다 큰 프로그램 실행
메모리 보호와 공유

페이징과 스와핑

페이징은 메모리를 고정 크기의 페이지 단위로 나누는 기법이다.
논리 주소 공간은 페이지로, 물리 메모리는 프레임으로 나뉜다.

스와핑은 메모리가 부족할 때 일부 페이지를 보조기억장치로 이동시키는 동작이다.
디스크 I/O는 메모리 접근보다 현저히 느리기 때문에 성능 저하의 주요 원인이 된다.
성능 저하의 주요 원인 (디스크 I/O는 메모리보다 100~1000배 느림)

메모리 압축

메모리 압축은 사용 빈도가 낮은 페이지를 압축하여 RAM 내부에 유지하는 기법이다.
디스크로 스왑하기 이전 단계에서 메모리 공간을 확보하는 방식이다.

CPU 연산을 사용하지만, 디스크 접근을 피할 수 있다는 점에서 비용 대비 효율이 높다.

압축 전: 100MB 데이터 → 100MB RAM 사용
압축 후: 100MB 데이터 → 30MB RAM 사용 (압축률 70%)

트레이드오프:

장점: 디스크 I/O 제거, 빠른 접근
단점: CPU 연산 필요, 압축/해제 오버헤드

커널 구조의 차이

Windows NT 커널

Windows는 하이브리드 커널 구조를 사용한다.
범용성과 하위 호환성을 중시한 설계다.

HAL 계층을 통해 광범위한 하드웨어를 지원하며, 메모리 관리자와 프로세스 관리자가 커널 내부에 포함된다.

특징은 다음과 같다.

다양한 벤더와 장치 지원
추상화 계층이 두꺼움
특정 하드웨어에 대한 공격적 최적화는 제한적

macOS XNU 커널

macOS는 Mach 마이크로커널과 BSD 계열 커널을 결합한 XNU 커널을 사용한다.

Mach는 가상 메모리와 스레드 관리를 담당하고, BSD 계층은 파일 시스템과 네트워크 스택을 담당한다.

특징은 다음과 같다.

하드웨어 통합: Apple이 커널과 하드웨어를 함께 설계
I/O Kit: 객체 지향 드라이버 프레임워크
최적화 우선: 제한된 하드웨어 환경에서의 극한 최적화

커널 구조 비교 요약

항목	Windows	macOS
설계 목표	범용성	통합 최적화
하드웨어 지원	광범위	제한적
추상화 수준	높음	상대적으로 낮음
최적화 방식	보수적	공격적

핵심 차이점: Windows는 다양한 환경을 지원하기 위해 추상화 계층을 두텁게 설계했고, macOS는 제한된 하드웨어를 전제로 최적화에 집중.

메모리 관리 철학

Windows 메모리 관리

Windows는 안정성을 우선시한다.
비교적 이른 시점에 페이지 파일을 활용하며, 워킹 셋 크기를 적극적으로 조절한다.

주요 개념은 다음과 같다.

Working Set: 프로세스가 현재 사용하는 페이지 집합
Standby List: 재사용 가능한 페이지
Modified List: 변경되었지만 디스크에 기록되지 않은 페이지
Free List: 즉시 할당 가능한 빈 페이지

메모리 부족 시 스왑이 빠르게 발생하는 구조다.

macOS 메모리 관리

macOS는 응답성을 우선시한다.
메모리 부족 상황에서 디스크 스왑보다 메모리 압축을 먼저 사용한다.

메모리는 다음과 같은 상태로 관리된다.

Wired Memory : 절대 스왑되지 않는 메모리 (커널, 드라이버)
Active Memory : 현재 사용 중인 메모리
Inactive Memory : 최근 사용되었지만 현재는 비활성
Compressed Memory : 즉시 사용 가능한 메모리
Free Memory : 압축된 메모리

메모리 압력 상태에 따라 단계적으로 대응한다.

Physical Memory: 16 GB
Memory Used: 12.5 GB
Wired Memory: 2.1 GB
Compressed: 2.3 GB (실제로는 4.5 GB가 압축됨)
Cached Files: 3.2 GB
Swap Used: 1.2 GB

# 기본 메모리 통계
vm_stat

# 1초마다 실시간 업데이트
vm_stat 1

# 메모리 압력 확인
memory_pressure

# 스왑 사용량 확인
sysctl vm.swapusage
# 출력: vm.swapusage: total = 2048.00M  used = 512.50M  free = 1535.50M

macOS의 메모리 압축

macOS 메모리 관리의 핵심은 메모리 압축이다.

압축은 다음 흐름으로 수행된다.

메모리 압박 감지
비활성 페이지 선택
압축 알고리즘 적용
압축된 데이터 유지
원본 페이지 공간 회수

압축 해제는 페이지 접근 시 수 마이크로초 내에 수행된다.

디스크 스왑 대비 압도적으로 빠르다.

압축 알고리즘: WKdm
WKdm (Wilson-Kaplan-direct-mapped)은 Apple이 개발한 빠른 압축 알고리즘.

평균 압축률: 50~70%
압축/해제 속도: 매우 빠름 (하드웨어 가속)
특징: 메모리 데이터에 최적화

물리 메모리: 16GB
사용 중: 20GB (압축 전 기준)

[압축 미사용 시]
→ 4GB를 디스크로 스왑
→ 디스크 I/O 발생 (수십~수백 ms)
→ 체감 성능 급격히 저하

[압축 사용 시]
→ 10GB를 3GB로 압축 (압축률 70%)
→ CPU 연산 사용 (수십 μs)
→ 물리 메모리 사용: 13GB (여유 있음)
→ 스왑 불필요
→ 응답성 유지

압축의 한계
압축이 효과적이지 않은 경우:

이미 압축된 데이터 (이미지, 비디오, ZIP 파일)
암호화된 데이터
랜덤 데이터

압축으로 인한 부작용:

메모리 압박 상황에서 CPU 사용률 10~30% 증가 가능
Apple Silicon: 효율 코어가 압축 작업 주로 담당
발열 및 배터리 소모 증가 가능

# Python으로 메모리를 점진적으로 할당
python3 << 'EOF'
import time

data = []
try:
    for i in range(100):
        # 100MB씩 할당
        data.append(' ' * (100 * 1024 * 1024))
        print(f"Allocated {(i+1) * 100} MB")
        time.sleep(1)
except MemoryError:
    print("Memory exhausted")
EOF

Activity Monitor에서 Compressed Memory 증가 확인
Memory Pressure 그래프 색상 변화 (녹색 → 노란색 → 빨간색)
CPU 사용률 증가 (kernel_task 프로세스)

스왑 전략의 차이

macOS는 메모리 압축 이후에도 부족할 경우에만 스왑을 수행한다.
스왑 파일은 동적으로 생성되며 필요가 없어지면 제거된다.

파일 위치 및 특성:

위치: /private/var/vm/swapfile*
동적 생성: 필요에 따라 여러 파일 생성
파일 크기: 각 1GB, 최대 64GB까지 확장 가능

# 스왑 파일 목록 및 크기 확인
ls -lh /private/var/vm/swapfile*

# 스왑 사용량 상세 확인
sysctl vm.swapusage

# 출력 예시:
# vm.swapusage: total = 2048.00M  used = 512.50M  free = 1535.50M

Windows는 페이지 파일을 보다 적극적으로 사용한다.
이로 인해 메모리 부족 상황에서 체감 성능 저하가 빠르게 발생할 수 있다.

유니파이드 메모리 구조

Apple Silicon은 CPU, GPU, Neural Engine이 동일한 메모리 공간을 공유한다.
이를 유니파이드 메모리 아키텍처라 한다.

이 구조의 특징은 다음과 같다.

데이터 복사 제거 : CPU와 GPU가 같은 메모리 주소 참조
메모리 중복 사용 감소
대역폭 증가
전력 효율 향상 : 복사 오버헤드 제거

운영체제 입장에서는 메모리 관리 정책을 단순화할 수 있다.

운영체제 입장에서의 이점:

압축 대상이 명확 (CPU/GPU 구분 불필요)
압축 해제도 모든 프로세서가 동일하게 접근
메모리 관리 정책 단순화

실제 효과:

16GB 유니파이드 메모리 ≈ 전통적 시스템의 20~24GB
메모리 압박 상황 발생 빈도 감소
더 많은 프로그램 동시 실행 가능

한계점
고정된 메모리 용량:

구매 시 결정, 추후 확장 불가
신중한 용량 선택 필요

비용:

메모리 업그레이드 비용이 높음
예: 16GB → 32GB 업그레이드 약 $400

macOS가 프로세스를 유지하는 이유

macOS는 단일 대응 방식이 아니라 다단계 방어 전략을 사용한다.

파일 캐시 회수
비활성 메모리 회수
메모리 압축
압축 페이지 스왑
활성 페이지 스왑
프로세스 종료

프로세스 종료는 최후의 수단이다.

핵심 요인 정리
macOS가 메모리 초과 상황에서도 프로세스를 유지하는 이유는 단일 요인이 아닙니다.

하드웨어와 운영체제의 강한 결합: Apple이 모든 것을 제어
메모리 압축이라는 중간 단계: 스왑 전에 압축 시도
디스크 스왑을 최후의 수단으로 사용: 응답성 우선
SSD 및 유니파이드 메모리 전제 설계: 최적화 극대화

정리

Windows와 macOS의 차이는 성능의 문제가 아니다.
자원 관리에 대한 철학의 차이다.

Windows는 다양한 환경에서의 안정성을 목표로 한다.
macOS는 통합된 하드웨어 환경에서의 최적화를 목표로 한다.

macOS가 16GB 환경에서도 많은 작업을 유지할 수 있는 이유는 다음과 같다.

메모리 압축 중심 설계
스왑을 최후의 수단으로 사용하는 정책
하드웨어와 운영체제의 강한 결합
유니파이드 메모리 구조

운영체제의 내부 동작을 이해하는 것은 단순한 이론 학습을 넘어, 시스템을 해석하는 관점을 제공한다.

설계 철학 비교

Windows: "다양한 환경에서 안정적으로"
macOS: "우리 하드웨어에서 최고의 경험을"
목표가 다를 뿐.

마치며

메모리는 단순히 부족하거나 남는 자원이 아니다.
어떻게 관리하느냐에 따라 체감 성능은 크게 달라진다.

운영체제는 메모리를 비워두기보다 적극적으로 사용한다.
그 차이를 이해하는 것이 시스템을 이해하는 출발점이다.

msgo

이전 포스트

가상 메모리

다음 포스트

MAC OS vs Window

핵심 용어 정리

커널

가상 메모리

페이징과 스와핑

메모리 압축

커널 구조의 차이

Windows NT 커널

macOS XNU 커널

커널 구조 비교 요약

메모리 관리 철학

Windows 메모리 관리

macOS 메모리 관리

macOS의 메모리 압축

스왑 전략의 차이

유니파이드 메모리 구조

macOS가 프로세스를 유지하는 이유

정리

마치며

가상 메모리

파일 시스템

0개의 댓글