나무모에 미러 (일반/밝은 화면)
최근 수정 시각 : 2026-08-05 11:12:46

ACPI


[[컴퓨터공학|'''컴퓨터 과학 및 공학
{{{#!wiki style="font-family: Times New Roman, serif; display: inline;"
]]
{{{#!wiki style="margin: 0 -10px -5px; min-height:calc(1lh + 5px)"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin: -5px -1px -11px; word-break: keep-all"
<colbgcolor=#1282d7,#1282d7><colcolor=#fff,#fff> 기반 학문 수학(이산수학 · 수리논리학 · 선형대수학 · 대수학(환론 · 범주론) · 정수론 · 해석학 · 미적분학 · 미분방정식) · 이론 컴퓨터 과학(튜링 머신 · 정보이론 · 재귀 이론) · 암호학 · 전자공학 · 언어학(음운론 · 형태론 · 통사론 · 의미론 · 화용론) · 인지과학
하드웨어 SoC · CPU · GPU(그래픽 카드 · GPGPU) · ROM · RAM · SSD · HDD · 참조: 틀:컴퓨터 부품
시스템 컴퓨터 구조론 · 폰노이만 구조 · 마이크로아키텍처 · 논리 회로(논리 연산 · 카르노 맵 · 가산기 · 보수기 · 플립플롭) · FPGA · 하드웨어 가속 · 바이오스 · UEFI · ACPI · LinuxBoot · 운영체제(인터럽트 · 멀티태스킹 · 프로세스 스케줄링 · 뮤텍스 · 세마포어 · 데드락 · 식사하는 철학자 문제) · 네트워크(네트워크 포트) · 대역폭 · 와이파이 · gRPC · GPS · 임베디드 시스템 · 사물인터넷 · 슈퍼컴퓨터 · 양자 컴퓨터
소프트웨어 시간 복잡도(최적화) · 이진 탐색 · 난수생성 · 컴퓨터 언어 · 기계어 · 어셈블리어 · 프로그래밍 언어(타입 이론 · 어휘 분석 · 파싱 · 컴파일러(어셈블러 · JIT) · 인터프리터 · 링커 · 난해한 프로그래밍 언어) · 마크업 언어 · 프로그래밍 패러다임(절차적 프로그래밍 · 객체 지향 프로그래밍 · 함수형 프로그래밍) · 데이터베이스(DBMS · NoSQL) · 메타데이터 · 인코딩(유니코드 · MBCS) · 소프트웨어 개발 방법론(애자일 · 워터폴) · 디자인 패턴 · 행위자 모델 · 놀람 최소화 원칙 · 버전(버전 관리 시스템) · 프레임워크 · 라이브러리 · 모듈 · API · ABI
응용 인공지능 · 기계학습 · 인공신경망 · 딥러닝 · 자연어 처리(기계 번역 · 음성인식) · 컴퓨터 비전 · OCR · 빅데이터 · 컴퓨터 그래픽스 · OpenGL · EXIF · HCI · UI · UX · 컴퓨터 보안 · 해킹 · 리버스 엔지니어링 · 해시(SHA · salt · 브루트 포스 · 레인보우 테이블 · 암호화폐) · 디피-헬만 키 교환 · RSA 암호화 · ROT13 · 일회용 비밀번호
}}}}}}}}} ||
1. 개요2. 배경3. 상세
3.1. 전역 상태(G-state)3.2. 수면 상태(S-state)
3.2.1. 모던 스탠바이(S0ix)
3.3. 프로세서 상태(C-state)3.4. 성능 상태(P-state)
4. 여담

1. 개요

Advanced Configuration and Power Interface, ACPI

고급 환경설정 및 전원 인터페이스.

하드웨어 감지, 메인보드 및 장치 구성, 전원 관리를 담당하는 일반적인 인터페이스를 정의한다. 1996년 휴렛 팩커드, 인텔, Microsoft, 피닉스, 도시바가 공동으로 개발하였다.

2013년 10월, ACPI 규격을 관리하던 ACPI SIG는 UEFI 포럼에 규격 관리 권한을 넘기면서, UEFI 규격과 통합 관리되고 있다. 현재 버전 6.4 규격까지 나와 있다.

2. 배경

1992년 인텔과 마이크로소프트는 PC의 소비 전력을 관리하기 위해 고급 전원 관리(Advanced Power Management, APM) 규격을 만들었다. 고급 전원 관리 기능을 지원하는 장치의 경우 디바이스 드라이버BIOS 인터럽트를 호출하는 방법으로 전력 관리 기능을 사용할 수 있었는데, 시간이 지나면서 BIOS가 모든 장치를 관리하기 어려워졌다. BIOS가 부팅 작업을 끝내고 운영 체제가 실행 중일 때, 실질적으로 전원을 관리하는 주체는 운영 체제이지 BIOS가 아니기 때문이며, 더군다나 BIOS가 16비트 코드라 관리할 수 있는 상태 정보도 적었다는 점도 문제였다. 더군다나 일부 BIOS는 버그가 있어 고급 전원 관리 기능이 제대로 동작하지 않는 경우도 있었다.

이러한 배경으로 ACPI 규격이 탄생하게 되었으며, BIOS가 아닌 운영 체제가 주체가 되어 관리한다.(Operating System-directed configuration and Power Management, OSPM) 고급 전원 관리, Multiprocessor Specification, Plug and Play BIOS API 등은 모두 ACPI 규격에 흡수되었다. 고급 전원 관리의 경우 반 정도는 이미 죽은 듯하고, Multiprocessor Specification도 마찬가지이다. 지원되기는 하나 ACPI를 사용하는 것에 비하여 정확한 결과를 얻는다고 할 수 없다.

Windows의 경우 Windows 98부터 지원하기 시작했으며[1], 현재 대부분의 운영 체제가 ACPI를 지원하고 있기에, 기존의 전원 관리와 연관된 것들은 더욱 빠르게 버려질 것으로 보인다.

3. 상세

ACPI는 전원 관리를 위해 컴퓨터의 상태를 계층적으로 정의한다. 시스템 전체를 나타내는 전역 상태(G-state)와 수면 상태(S-state), 개별 장치의 전원 상태(D-state), 프로세서의 유휴 상태(C-state)와 성능 상태(P-state)로 나뉜다.

숫자가 클수록 더 깊이 잠들어 전력 소비가 줄어들지만, 깨어나는 데 걸리는 시간은 길어진다는 공통 원리가 있다.

3.1. 전역 상태(G-state)

3.2. 수면 상태(S-state)

상태 통칭 내용
S0 동작 정상 동작 상태
S1 Power on Suspend CPU·칩셋의 컨텍스트를 모두 유지한 채 클럭만 정지. 복귀가 가장 빠른 얕은 잠
S2 - CPU 전원을 차단해 CPU 컨텍스트와 캐시가 손실됨. 실제 구현된 하드웨어가 거의 없음
S3 Suspend to RAM 절전 모드. 메모리만 셀프 리프레시로 내용을 유지하고 나머지는 전원 차단
S4 Suspend to Disk 최대 절전 모드. 메모리 이미지를 디스크에 기록[2] 후 전원 차단. 전원이 완전히 끊겨도 복원 가능
S5 Soft Off 시스템 종료. 아무 컨텍스트도 저장하지 않으며 복귀하려면 재부팅해야 함
S3~S5 상태에서도 대기 전력은 살아 있으므로 전원 버튼 외에 Wake-on-LAN, RTC 알람(메인보드 설정의 Resume by Alarm), USB 장치 등으로 시스템을 깨울 수 있다. Windows에서 현재 시스템이 지원하는 수면 상태는 powercfg /a 명령으로 확인할 수 있다.

3.2.1. 모던 스탠바이(S0ix)

S3의 대안으로 등장한 대기 방식. 시스템을 S3로 깊이 재우는 대신 S0 상태에서의 저전력 유휴(S0 low power idle)로 두는 모델로, 인텔의 하드웨어 상태 이름을 따 S0ix라고도 부른다.[3] 화면은 꺼져 있지만 시스템은 아주 얕게 잠들어 있다가 필요할 때 순간적으로 깨어나 네트워크 이벤트를 처리하는, 즉 스마트폰의 대기 방식과 같은 개념이다. Microsoft는 대기 중에도 네트워크 연결이 유지되고 전원 버튼을 누른 뒤 1초 안에 화면이 켜지는 것을 목표로 내세웠다.

Windows 8(2012)에서 'Connected Standby'라는 이름으로 도입되어 Windows 8.1에서 'InstantGo'로, Windows 10에서 '모던 스탠바이(Modern Standby)'로 개칭·확장되었으며, 하드웨어 쪽에서는 인텔이 클로버 트레일 아톰과 하스웰(2013)부터 S0ix 상태를 지원하기 시작했다.

2021년경부터 출시되는 노트북은 대부분 S3 지원을 아예 삭제하고 모던 스탠바이만 지원한다.[4] 다만 대기 중 배터리 소모와 발열 문제가 존재한다.

리눅스는 이와 별개로 순수 소프트웨어 방식의 suspend-to-idle(s2idle)을 제공하며, ACPI 시스템에서 standby는 S1, suspend-to-RAM은 S3에 매핑된다.

3.3. 프로세서 상태(C-state)

CPU의 유휴(idle) 상태. 명령을 실행하는 상태는 C0뿐이며, 할 일이 없을 때 OS가 CPU를 C1 이상의 유휴 상태로 보내 전력을 아낀다. ACPI 규격 자체가 정의하는 것은 C0~C3까지이고, 그보다 깊은 상태는 펌웨어가 _CST 객체로 OS에 알려주는 확장 영역이다.
상태 명칭 내용
C0 Operating 명령 실행 중
C1 Halt HLT 명령으로 진입. 사실상 즉시 복귀 가능하며 모든 ACPI 프로세서가 필수 지원
C1E Enhanced Halt 인텔 확장. 정지에 더해 전압과 배수까지 낮춰 발열·전력을 추가로 절감
C2 Stop-Clock 클럭 정지. 캐시 스누핑은 유지됨. 선택 사항
C3 Sleep 캐시 일관성이 유지되지 않는 깊은 수면. 진입 전 캐시를 플러시하거나 DMA 발생 시 C0으로 복귀시켜야 함
C6 이상 Deep Power Down 등 제조사 확장. 코어 상태를 전용 SRAM에 저장한 뒤 코어 전압을 0으로 낮추는 파워 게이팅 적용
깊은 상태일수록 절전 효과가 크지만 진입/복귀 지연도 길어지므로, OS는 _CST로 전달받은 각 상태의 지연 시간 정보를 보고 상황에 맞는 깊이를 고른다. 인텔은 하스웰 세대(2013)부터 C8~C10 같은 초저전력 패키지 상태까지 도입했는데, 이때 베이스 클럭을 24MHz까지 낮춘다. 참고로 개별 코어에 적용되는 코어 C-state와 별개로, L3 캐시·메모리 컨트롤러까지 포함하는 패키지 C-state는 모든 코어가 해당 깊이 이상으로 잠들었을 때만 하드웨어가 알아서 진입한다.

오버클럭 시 BIOS에서 C1E와 C-state를 끄는 것이 정석으로 통했는데, 유휴↔부하 사이를 오가며 전압·클럭이 계속 출렁이는 것이 오버클럭 상태에서는 불안정의 원인이 되기 때문이다. 딥 C-state가 실제 사고를 친 사례도 있다. 초기 라이젠(Zen 1)은 리눅스에서 유휴 상태에 방치하면 랜덤 프리징이 발생하는 문제가 있었는데, C6 진입 시의 초저전류 유휴를 일부 전원부가 제대로 처리하지 못한 것과 관련되어 BIOS에 'Power Supply Idle Control(Typical Current Idle)' 옵션이 추가되는 것으로 정리되었다.

3.4. 성능 상태(P-state)

P0이 최대 성능이고 P1, P2, …로 갈수록 전압과 주파수가 내려간다. 인텔 SpeedStep(EIST), AMD PowerNow!/Cool'n'Quiet가 이를 구현한 기술이다.

다만 OS가 일일이 P-state를 골라 주는 방식은 반응이 굼떠서, 인텔은 스카이레이크(2015)부터 OS는 힌트만 주고 하드웨어가 스스로 성능 상태를 고르는 Speed Shift(HWP)로 전환했다.

ACPI 차원에서도 5.0부터 고정된 주파수 단계 대신 연속적인 추상 성능 스케일을 쓰는 CPPC(Collaborative Processor Performance Control)가 도입되어 P-state 테이블을 대체하고 있으며, 현대 라이젠의 선호 코어(preferred core) 스케줄링이나 리눅스 amd-pstate 드라이버가 이를 기반으로 동작한다.

4. 여담


[1] Windows Vista(2008) 부터는 더 나아가서 ACPI 사용을 의무화 했고, 펌웨어 설정에 들어가서 ACPI를 사용하도록 활성화시키지 않거나 애당초 메인보드 자체가 펌웨어 바이너리 코드를 수정하는 것 만으로 ACPI 지원 자체가 불가능할 정도의 구형 보드라면 설치 시 ACPI와 관련된 오류를 블루스크린 형태로 띄우면서 설치하는 걸 거부하기에 말이 의무화지, 사실상 ACPI 사용을 강제하기 시작했다. 특정 CPU 명령어 집합(예:SSE4.1, Nx-Bit 등)을 요구하는 것 정도는 여타 등장한 꼼수로 어느 정도 우회할 순 있어도 ACPI 문제는 작정하고 강제하고 있는지라 우회 자체가 불가능하다.[2] Windows에서는 hiberfil.sys 파일.[3] 하위 상태로 S0i1, S0i2, S0i3 등이 있다.[4] powercfg /a를 쳤을 때 'Standby (S0 Low Power Idle)'이 표시되는 기기가 이에 해당한다.[5] 원문: "One thing I find myself wondering about is whether we shouldn't try and make the 'ACPI' extensions somehow Windows specific." / "It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work." / "Maybe we could define the APIs so that they work well with NT and not the others even if they are open.", 증거물 번호 PX03020.

분류