Hacker News 2026.05.31 29

사라지는 서비스 프로세서: Oxide가 서버 보안 모델을 다시 설계하는 방식

서비스 프로세서가 뭔지부터 알아야 해요

서버 한 대를 운영해보신 분들은 BMC(Baseboard Management Controller)나 iDRAC, iLO 같은 이름을 들어보셨을 거예요. 서버 메인보드 한구석에 작은 보조 컴퓨터가 또 하나 들어있는 거거든요. 이 작은 컴퓨터의 역할은 "메인 CPU가 꺼져 있어도 원격으로 전원을 켜고, 펌웨어를 업데이트하고, 화면을 띄워주는 것"이에요. 데이터센터에서 사람이 직접 가지 않고도 서버를 관리할 수 있게 해주는 핵심 부품이죠.

그런데 이게 보안 관점에선 골치예요. BMC가 자체 OS(보통 리눅스)를 돌리고, 자체 네트워크 스택을 가지고, 메인 서버와 별개로 인터넷에 노출돼 있는 경우가 많거든요. BMC가 뚫리면 서버 전체가 뚫리는 거예요. 메인 CPU가 모르는 사이에 디스크를 읽고, 메모리를 덤프하고, 펌웨어를 갈아끼울 수 있으니까요. 2018년에 발견된 "Cloudborne" 같은 취약점이 대표적이에요.

Oxide가 시도한 건 좀 과격해요

Oxide Computer는 BMC 자체를 다시 설계한 회사예요. 창업자 Bryan Cantrill은 옛 Sun Microsystems와 Joyent에서 활약했던 시스템 엔지니어링계의 전설 같은 분이고요. 이들이 만드는 서버는 처음부터 "하드웨어와 소프트웨어를 한 회사가 통째로 설계한다"는 철학으로 만들어졌어요. 마치 애플이 칩부터 OS까지 다 만드는 것처럼요.

이번 글에서 다루는 건 그들의 새 서비스 프로세서 "Cosmo SP"예요. 글 제목이 "A disappearing Service Processor"인데, "사라지는 서비스 프로세서"라는 표현이 절묘해요. 기존 BMC는 메인 시스템과 거의 동등한 권한을 가진 또 하나의 컴퓨터였다면, Oxide의 방향은 "필요한 일만 하고 그 외엔 존재감을 지우는" 최소주의 설계예요.

어떻게 "사라지게" 만드는가

핵심 아이디어는 몇 가지로 정리할 수 있어요. 첫째, 공격 표면 최소화예요. 일반 BMC는 풀스택 리눅스를 돌리지만 Oxide는 Hubris라는 자체 마이크로커널 RTOS(실시간 운영체제)를 써요. Rust로 작성됐고, 태스크 간 격리가 엄격해서 한 컴포넌트가 뚫려도 다른 데로 번지기 어려운 구조예요.

둘째, 검증 가능한 부팅 체인이에요. 칩이 켜지는 순간부터 모든 펌웨어가 서명 검증을 거쳐요. 이걸 보통 "measured boot" 또는 "root of trust"라고 부르는데, Apple의 Secure Enclave나 Google의 Titan 칩, AWS의 Nitro System과 비슷한 철학이에요. 다만 Oxide는 이걸 오픈 펌웨어와 오픈 사양으로 풀어내려 한다는 게 차별점이고요.

셋째, 최소 권한 원칙이에요. 서비스 프로세서가 메인 CPU의 메모리에 마음대로 접근하거나, 디스크를 임의로 읽는 걸 하드웨어 단에서 막아요. 옛날엔 "관리 편의"라는 이유로 BMC에 너무 많은 권한이 주어졌는데, 그게 곧 공격자에게도 너무 많은 권한이 된다는 걸 깨달은 결과죠.

업계 흐름 속에서 보면

이 방향성은 Oxide만 가는 길은 아니에요. AWS가 Nitro System으로 가상화·보안 기능을 별도의 카드로 분리하면서 호스트 CPU의 부담과 공격면을 줄였고요, Microsoft Azure는 Cerberus라는 자체 루트 오브 트러스트 칩을 발표했어요. Google도 OpenTitan이라는 오픈소스 보안 칩 프로젝트를 주도하고 있고요.

공통된 흐름은 "신뢰의 시작점을 명확하고 작게 만들자"는 거예요. 거대한 펌웨어 덩어리에 신뢰를 거는 대신, 검증 가능한 작은 하드웨어 모듈에서 출발해 한 계단씩 신뢰를 확장하는 거죠. 일종의 보안판 미니멀리즘이라고 볼 수 있어요.

Oxide가 다른 점은 수직 통합이에요. 보드, 칩 선택, 펌웨어, 호스트 OS(Helios — illumos 기반), 컨트롤 플레인까지 다 자기네가 만들거든요. 일반 서버는 Supermicro 보드 + AMI BMC 펌웨어 + 별도 OS + 별도 관리툴이 복잡하게 얽혀있는데, Oxide는 "누가 무엇을 만들었는지"가 명확해서 책임 추적과 보안 검증이 훨씬 쉬워요.

한국 개발자에게 어떤 시사점이 있을까

한국에서 직접 서버 하드웨어를 설계할 일은 많지 않지만, 이 글이 던지는 메시지는 소프트웨어 설계 전반에 적용 가능해요. 우리가 만드는 마이크로서비스도 "관리 편의성"이라는 이유로 너무 많은 권한을 한곳에 몰아주고 있지는 않은지, 관리용 API가 사실상 백도어처럼 동작하고 있지는 않은지 점검해볼 가치가 있거든요.

또 클라우드를 운영하는 분들이라면 자신이 쓰는 서버의 BMC가 인터넷에 노출돼 있는지 꼭 확인하셨으면 해요. Shodan 같은 검색엔진으로 보면 IPMI 포트가 열린 서버가 한국에도 수천 대씩 있거든요. 이건 정말 위험한 상태예요. 최소한 BMC 네트워크는 별도 VLAN으로 분리하고, 기본 비밀번호를 바꾸고, 펌웨어 업데이트를 챙기는 게 기본이에요.

그리고 Rust + 마이크로커널이라는 조합이 임베디드와 시스템 프로그래밍 영역에서 점점 표준이 되어가고 있다는 점도 주목할 만해요. 안전한 시스템을 만들고 싶은 분들에게는 Hubris 코드를 읽어보는 것 자체가 좋은 공부거리예요. GitHub에 다 공개돼 있고요.