하드웨어 고급 #7 펌웨어, BMC, 수명주기 — 서버 안의 또 다른 컴퓨터

2026년 6월 18일 목요일

8 분 소요

전원 케이블만 꽂혀 있으면, 서버 본체가 꺼져 있어도 그 안에서 켜져 있는 컴퓨터가 하나 있습니다. BMC(Baseboard Management Controller)입니다. 6편까지 시선을 데이터센터의 전력과 냉각으로 넓혔다면, 마지막 편은 다시 서버 안으로 돌아옵니다. 이번 글에서는 BMC와 펌웨어 스택, 고장 예측 신호, 그리고 하드웨어가 들어와서 나가기까지의 수명주기를 정리하고 시리즈 전체를 닫겠습니다.

BMC: 전원이 꺼져도 살아 있는 컴퓨터 #

BMC는 서버 메인보드 위에 붙어 있는 작은 독립 컴퓨터입니다. 자체 프로세서(보통 ARM 계열)와 자체 메모리, 자체 OS(대개 임베디드 리눅스), 자체 네트워크 포트를 가집니다. 메인 CPU와는 완전히 별개로 동작하기 때문에, OS가 패닉으로 멈춰도, 부팅이 안 돼도, 심지어 전원 버튼으로 서버를 꺼 두어도 BMC는 살아서 응답합니다. 전원 케이블이 공급하는 대기 전력만으로 도는 컴퓨터이기 때문입니다.

이 독립성이 BMC의 존재 이유입니다. 운영하는 서버가 한 대라면 모니터와 키보드를 들고 가면 되지만, 다른 도시의 데이터센터에 수백 대가 있다면 “고장 난 서버를 고치러 들어가는 길"이 OS 바깥에 따로 있어야 합니다. 벤더마다 이름이 다릅니다. 델은 iDRAC, HPE는 iLO, 슈퍼마이크로는 단순히 IPMI 또는 BMC라고 부르지만 하는 일은 같습니다.

BMC가 할 수 있는 일 #

원격 콘솔: 부팅 화면부터 BIOS 설정 화면까지, 모니터를 직접 연결한 것과 같은 화면을 브라우저로 봅니다. OS가 죽어 SSH가 안 될 때 마지막으로 남는 접속 경로입니다.
전원 제어: 원격에서 전원을 켜고 끄고, 강제 리셋을 겁니다. 커널이 완전히 굳은 서버를 살리는 유일한 수단입니다.
센서 읽기: 온도, 팬 속도, 전압, 전원 공급 장치 상태를 OS와 무관하게 수집합니다. 5편의 전력 측정과 6편의 온도 관리가 실제로 읽는 값의 출처가 대부분 BMC입니다.
가상 미디어: 내 PC의 ISO 파일을 서버에 USB 드라이브처럼 원격으로 마운트합니다. OS 재설치를 위해 데이터센터에 갈 필요가 없어집니다.

센서는 명령 한 줄로 확인할 수 있습니다.

ipmitool sensor (발췌)

CPU1 Temp        | 54.000    | degrees C  | ok
System Temp      | 31.000    | degrees C  | ok
FAN1             | 6800.000  | RPM        | ok
12V              | 12.190    | Volts      | ok
PS1 Status       | 0x01      | discrete   | ok

IPMI와 Redfish #

BMC와 대화하는 프로토콜은 두 세대가 공존합니다.

IPMI(Intelligent Platform Management Interface)는 1998년에 나온 레거시 표준입니다. ipmitool 명령으로 전원 제어, 센서 조회, 이벤트 로그 열람을 합니다. 거의 모든 서버가 지원하기 때문에 현장에서 여전히 많이 쓰이지만, 바이너리 프로토콜이라 다루기 불편하고 설계가 오래되어 보안 취약점이 누적되어 왔습니다.

Redfish는 그 후속으로 만들어진 REST 기반 표준입니다. HTTPS 위에서 JSON으로 대화하기 때문에 curl과 jq만으로 자동화가 됩니다.

Redfish로 전원 상태 조회

curl -sk -u admin:PASSWORD https://bmc.example.com/redfish/v1/Systems/1 | jq '.PowerState'
"On"

수백 대의 펌웨어 버전을 수집하거나 전원을 일괄 제어하는 작업이라면 Redfish 쪽이 압도적으로 다루기 쉽습니다. 새로 자동화를 만든다면 Redfish를 기본으로 잡고, IPMI는 오래된 장비의 호환용으로만 남기는 것이 현재의 방향입니다.

펌웨어 스택 지도 #

서버 한 대에는 펌웨어가 생각보다 많이 들어 있습니다.

펌웨어	위치	하는 일
BIOS/UEFI	메인보드	하드웨어 초기화, 부트로더 호출, 메모리·전력 설정
BMC 펌웨어	BMC 칩	위에서 본 원격 관리 기능 전부
NIC 펌웨어	네트워크 카드	패킷 처리, 오프로드 기능
SSD 펌웨어	각 드라이브	웨어 레벨링, 가비지 컬렉션, 캐시 정책
RAID 카드 펌웨어	RAID 컨트롤러	어레이 관리, 캐시와 배터리 제어

이 중 어느 하나의 버그가 OS에서는 설명되지 않는 증상을 만듭니다. 특정 펌웨어 버전의 SSD가 누적 가동 시간이 일정 값을 넘으면 통째로 죽는 사고, NIC 펌웨어 버그로 특정 패턴의 패킷에서 카드가 멈추는 사고는 실제로 반복되어 온 유형입니다. OS와 애플리케이션을 아무리 들여다봐도 원인이 안 나올 때, 한 층 아래에 용의자가 더 있다는 사실을 기억해 둘 필요가 있습니다.

문제는 업데이트가 미뤄지기 쉽다는 점입니다. 재부팅이 필요한 경우가 많고, 잘못되면 부팅 불능이 될 수 있다는 두려움이 있고, 당장 눈에 보이는 이득이 없기 때문입니다. 그래서 잘 운영하는 조직은 펌웨어를 개별 파일이 아니라 검증된 묶음 단위로 관리합니다. 벤더가 호환성을 검증해 배포하는 번들 버전을 분기에 한 번 정도의 주기로 정하고, 한두 대의 카나리아 서버에 먼저 적용해 일정 기간 관찰한 뒤, 재부팅이 어차피 필요한 커널 업데이트나 정기 점검 일정에 얹어 순차 배포합니다. “문제가 생기면 그때 올린다"는 방식은 문제가 생긴 시점에 몇 년 치 변경을 한 번에 건너뛰게 만들어 오히려 위험합니다.

고장은 예고하고 옵니다 #

하드웨어는 어느 날 갑자기 죽는 것처럼 보이지만, 신호를 먼저 보내는 경우가 많습니다. 볼 곳은 세 군데입니다.

SMART는 드라이브가 스스로 기록하는 건강 지표입니다. 재할당 섹터 수, 복구 불가 에러, NVMe라면 잔여 수명 퍼센트를 봅니다. 특히 재할당 섹터가 0에서 움직이기 시작한 디스크는 통계적으로 고장 확률이 크게 뛰므로, 죽기 전에 교체를 계획할 수 있습니다.

ECC 에러 카운터는 메모리의 신호입니다. ECC 메모리는 1비트 오류를 조용히 정정하는데, 리눅스는 그 정정 횟수를 EDAC 서브시스템으로 집계합니다.

정정된 메모리 에러 카운트 확인

grep . /sys/devices/system/edac/mc/mc*/ce_count
/sys/devices/system/edac/mc/mc0/ce_count:0
/sys/devices/system/edac/mc/mc1/ce_count:142

정정 가능 에러(CE)는 당장 장애가 아니지만, 특정 DIMM에서 카운트가 꾸준히 오르면 그 모듈이 정정 불가 에러(UE)로 발전해 시스템을 세우기 전에 갈아 끼우라는 신호입니다.

BMC의 센서 이벤트 로그(SEL)는 OS가 기록하지 못하는 사건을 담습니다. 전원 공급 장치 한쪽이 순간적으로 죽었다 살아난 기록, 온도 임계 초과, 팬 정지가 시간순으로 남습니다. 서버가 갑자기 꺼졌는데 OS 로그에 아무것도 없다면, 답은 대개 ipmitool sel list에 있습니다.

BMC 보안: 가장 강력한 문은 가장 위험한 문 #

BMC는 OS 아래에서 전원과 콘솔을 쥐고 있는 컴퓨터이므로, 침해당하면 그 서버의 전부를 내주는 것과 같습니다. 그런데 BMC 펌웨어는 오래된 임베디드 소프트웨어라 취약점이 잦고, 업데이트는 본체보다도 더 미뤄지기 마련입니다. 그래서 원칙이 둘 있습니다.

첫째, BMC 포트는 관리망으로 분리합니다. 서비스 트래픽이 다니는 네트워크와 물리적으로 또는 VLAN으로 격리된 별도 네트워크에만 연결하고, 인터넷에서 절대 닿지 않게 합니다. 검색엔진에 노출된 BMC 로그인 화면은 지금도 수만 대 단위로 발견됩니다.

둘째, 기본 계정을 반드시 바꿉니다. admin/admin 같은 공장 출하 계정은 목록이 공개되어 있습니다. 최근 장비는 출하 시 개체별 무작위 비밀번호를 부여하는 방향으로 바뀌었지만, 몇 년 된 장비라면 직접 확인해야 합니다.

하드웨어 수명주기: 들어와서 나가기까지 #

서버는 보통 3〜5년의 보증 기간과 함께 들어옵니다. 보증이 살아 있는 동안은 부품 고장이 벤더의 문제이지만, 만료 후에는 부품 수급과 수리 비용이 모두 내 문제가 됩니다. 그래서 보증 만료 시점이 교체 검토의 자연스러운 기준선이 됩니다.

다만 교체 판단은 “아직 돌아가는데 왜 버리는가"라는 직관과 자주 부딪힙니다. 여기서 5편의 전력 이야기가 돌아옵니다. CPU의 전력 대비 성능은 세대마다 개선되어 왔기 때문에, 5년 전 서버 여러 대가 하던 일을 새 서버 한 대가 더 적은 전력으로 처리하는 경우가 많습니다. 전기 요금과 상면 비용, 구형 장비의 장애 대응 인력 비용까지 합산하면, 멀쩡히 돌아가는 서버를 교체하는 쪽이 총비용에서 이기는 시점이 옵니다. 교체 판단은 감가상각 장부가 아니라 이 총비용 계산 위에서 하는 것입니다.

마지막은 폐기입니다. 서버는 버려도 디스크는 데이터를 들고 나갑니다. 파일 삭제나 포맷은 데이터를 지우지 않으므로, 폐기 절차에 디스크 처리가 명시되어 있어야 합니다. 전체 덮어쓰기, SSD라면 암호 키를 파기하는 방식의 보안 삭제(Secure Erase), 규정이 엄격한 환경이라면 물리 파쇄까지 단계가 있고, 어느 단계든 처리 기록을 남기는 것까지가 절차입니다. 보안 사고 사례 중에는 중고로 팔린 디스크에서 고객 데이터가 복구된 유형이 꾸준히 있습니다.

정리: 시리즈를 닫으며 #

일곱 편을 한 줄씩 돌아보면 이렇습니다.

1편은 CPU 마이크로아키텍처를 열고, 사이클이 코어 안 어디에서 새는지를 perf로 읽었습니다.
2편은 eBPF로 커널을 재컴파일하지 않고 커널 내부를 관측하는 길을 다뤘습니다.
3편은 메모리를 더 깊이 파고들어, 페이지 너머의 동작을 좇았습니다.
4편은 ZFS가 데이터 무결성을 파일시스템 차원에서 책임지는 설계를 보았습니다.
5편은 시선을 서버 밖으로 돌려, 전기가 서버까지 오는 길과 전력의 비용을 따라갔습니다.
6편은 그 전기가 열이 되어 나가는 길, 냉각과 랙 단위의 사고법을 다뤘습니다.
그리고 7편은 서버 안의 또 다른 컴퓨터와 하드웨어의 생애 전체를 정리했습니다.

하드웨어 기초는 부품과 지표의 개념을 잡는 시리즈였고, 하드웨어 중급은 그 개념으로 실제 서버를 진단하는 시리즈였습니다. 고급은 거기서 두 방향으로 더 나아가, 커널 아래의 마이크로아키텍처와 데이터센터 위의 설비까지를 한 시야에 넣었습니다. 이제 “서버가 느리다"는 한마디 앞에서 명령 파이프라인부터 냉각수 배관까지를 같은 지도 위에 놓고 생각할 수 있습니다. 그 지도가 이 시리즈가 남기려던 것의 전부입니다.