모두가 어느 모델이 코드를 가장 잘 작성하는지를 두고 논쟁하는 동안, 훨씬 더 오래됐고 훨씬 덜 화려한 문제가 새로운 AI 데이터센터마다 조용히 함께 커지고 있다. 바로 베이스보드 관리 컨트롤러, 즉 BMC다. 이번 주 보안 연구자들은 주요 제조업체의 인터넷 연결 서버 수천 대가 이러한 컨트롤러의 버그를 통해 원격으로 백도어될 수 있다는 연구 결과를 발표했다. 그중 일부 결함은 10년도 더 된 것이다. 이는 AI에 관한 이야기가 전혀 아니다. AI가 구동되는 하드웨어에 관한 이야기이며, 다음 AI 인접 보안 일자리가 어디에서 생겨날지 생각하고 있다면 이해해 둘 만한 내용이다.

BMC란 실제로 무엇이며, 왜 무서운가

BMC는 거의 모든 엔터프라이즈 서버 마더보드에 납땜되어 있는 작고 별도의 컴퓨터다. 자체 운영체제와 자체 네트워크 스택으로 실행되며, 메인 서버에서 실행되는 운영체제와 애플리케이션과는 완전히 독립적인 자체 IP 주소를 갖는다. 관리자는 BMC를 사용해 "라이트 아웃" 또는 "대역 외" 관리를 수행한다. 즉 시스템을 재부팅하고, 펌웨어를 다시 플래시하고, 운영체제를 재설치하는 작업을 모두 원격으로 수행하며, 무엇보다 메인 서버의 전원이 꺼져 있거나 완전히 응답하지 않는 동안에도 할 수 있다.

바로 그 점 때문에 BMC가 침해되면 매우 위험해진다. BMC에 침입한 공격자는 호스트 운영체제가 실행 중일 필요가 없고, 호스트에 설치된 엔드포인트 보안을 우회할 필요도 없으며, BMC가 일반적인 IT 보안 도구가 감시하는 계층의 아래이자 바깥에 존재하기 때문에 운영체제를 재설치해도 지속성을 유지할 수 있다. 이번 주 다뤄진 연구에 따르면 가장 흔히 연루된 프로토콜은 IPMI이며, 보안 연구자들은 적어도 2013년부터 이런 유형의 위험을 지적해 왔다. 다시 말해 이는 새로운 버그가 아니라, 업계가 10년 넘게 용인해 온 오래되고 알려진, 구조적으로 수정하기 어려운 버그 유형이다.

왜 지금은 덜 중요해지는 것이 아니라 더 중요해지는가

AI 구축은 물리적으로 역사상 가장 큰 서버 조달 물결 중 하나다. 공급업체가 배송할 수 있는 속도만큼 빠르게 새로운 데이터센터와 확장된 데이터센터에 GPU 서버가 랙 단위로 들어가고 있다. 이 서버 하나하나에는 BMC가 탑재된다. 데이터센터 운영자가 대규모 서버 집단을 관리하는 방법이 BMC이기 때문이다. 창고만 한 건물에 들어가 손으로 만 대의 장비를 일일이 재부팅할 수는 없다. 따라서 AI 붐은 단순히 컴퓨팅 자원을 구매하는 것이 아니다. 필연적으로, 중요 취약점이 10년 넘게 존재해 왔다는 기록이 있고 모니터링이 제대로 되지 않는 대역 외 소형 컴퓨터들로 이루어진, 그에 상응하는 규모의 집단도 함께 구매하는 것이다.

이것이 바로 기술 부채다. 구축 속도는 모든 마더보드 아래에 내장된 관리 펌웨어를 감사하는 것보다 GPU를 랙에 장착하고 학습을 시작하는 데 최적화되어 있다. 이번 주 공개를 주도한 연구자들은 BMC를 "널리 퍼져 있고, 모니터링이 부족하며, 패치가 제대로 적용되지 않은 병렬 공격 표면"이라고 표현한 것으로 알려졌다. 이 설명은 AI 데이터센터 붐보다 앞선 것이지만, 현재 운영 환경에 있는 BMC의 수를 배가하고 있는 것은 바로 그 붐이다.

이로 인해 열리는 틈새 분야

AI 인프라와 함께 보안 커리어가 어디로 향하고 있는지 지도를 그려 본다면, 대부분의 뻔한 분야인 모델 레드팀, 프롬프트 인젝션 방어, 에이전트 거버넌스는 이미 경쟁이 치열하고 다른 곳에서도 충분히 다뤄지고 있다. 하드웨어 및 대역 외 보안 감사는 그렇지 않다. 이는 AI 기조연설에는 등장하지 않는 인프라 보안의 수수하고 매력 없는 한구석이며, 바로 그 점이 기회다. 새로운 데이터센터가 생길 때마다 수요는 커지고 있지만, 펌웨어 수준과 대역 외 공격 표면을 이해하는 사람의 공급은 적다. 애플리케이션 보안이나 클라우드 보안과는 정말 다른 기술 집합이기 때문이다.

구체적으로 실제 업무는 다음과 같다:

  • 펌웨어 및 프로토콜 이해도. IPMI와 그 알려진 취약 지점, 예를 들어 오래전에 폐기 권고가 내려졌지만 일부 장치에서는 여전히 활성화된 암호 스위트 0 등을 충분히 이해해, 특정 서버 집단이 실제로 노출되어 있는지 평가하는 능력이다. 단순히 이론적으로 취약한지를 보는 것이 아니다.
  • 네트워크 세분화 감사. BMC/관리 인터페이스가 실제로 전용 관리 네트워크에 격리되어 있는지, 아니면 운영 환경이나 일반 인터넷에서 접근 가능한지 확인하는 일이다. 이는 기본적인 통제이지만 실제 환경에서는 반복적으로 빠져 있는 것으로 드러난다.
  • 자격 증명 및 패치 관리 상태 검토. BMC는 기본 자격 증명이나 공급업체가 설정한 자격 증명, 그리고 데이터센터의 일반적인 운영체제 패치 주기에 포함되지 않는 펌웨어와 함께 제공되는 경우가 많다. 운영체제가 아니기 때문에 "패치"를 책임지는 담당자의 업무 범위에서 빠지기 쉽다.
  • 공급업체 및 공급망 인식. BMC 펌웨어는 대개 소수의 전문 공급업체가 작성하고 서버 제조업체에 라이선스로 제공한다. 따라서 한 공급업체의 코드에 있는 결함이 여러 하드웨어 브랜드로 동시에 확산될 수 있다. 이번 주 공개 내용이 바로 이런 패턴이다. 어떤 서버 브랜드 아래에 어떤 펌웨어 스택이 있는지 아는 것도 업무의 일부다.

이 분야에 실제로 진입하는 방법

이는 진정한 틈새 분야이며, 전담 인력이 얼마나 많이 생길지, 아니면 기존 인프라 또는 보안 팀 내부의 전문 분야로 남을지 회의적인 것은 당연하다. "BMC 보안 감사자"가 독립적인 직책이 되기보다는 더 폭넓은 하드웨어/데이터센터 보안 역할에 추가하는 기술이 될 수 있다는 점을 스스로 솔직하게 인정해야 한다. 그러나 어쨌든 몇 가지 구체적이고 확인 가능한 행동은 의미가 있다. 엔터프라이즈 서버를 사용할 수 있거나 실습용으로 중고 하드웨어라도 구할 수 있다면 IPMI와 대역 외 관리 도구를 직접 다뤄 보라. 주요 서버 및 BMC 펌웨어 제조업체가 공개하는 BMC 펌웨어 보안 권고문을 읽어 보라. 실제 취약점 공개 사례를 제공하므로 공부할 수 있다. 이미 클라우드 또는 인프라 보안 분야에서 일하고 있다면, 소속 조직의 데이터센터 또는 하드웨어 조달 팀에 간단하고 검증 가능한 질문을 해 보기 시작하라. 우리 BMC/IPMI 관리 영역은 격리된 네트워크에 있는가? 그리고 이에 대한 패치는 누가 담당하는가? 아무도 자신 있게 대답하지 못한다면, 그것은 단순한 발견 사항이 아니라 이 틈새 분야에 정확히 필요한 전문성을 보여 주는 시연이다.