지금 AI와 일자리를 둘러싼 대화의 대부분은 눈에 보이는 층위에 관한 것이다. 누가 코드를 작성하는지, 누가 모델에 프롬프트를 입력하는지, 챗봇이 초안을 작성할 수 있게 되었을 때 누가 잘리는지 말이다. 이번 주 뉴스에 묻혀 있는 이야기 하나는 그 대화에 참여하는 누구도 들여다보지 않는 층위에 관한 것이다. 그리고 바로 그 점 때문에 주목할 가치가 있다. 그 층위가 요구하는 기술을 두고 경쟁하는 사람은 거의 아무도 없기 때문이다.
2013년부터 그곳에 방치되어 있던 버그
이번 주 보안 연구진은 주요 제조업체의 인터넷 연결 서버 수천 대가 베이스보드 관리 컨트롤러, 즉 BMC를 통해 원격으로 백도어 공격을 받을 수 있는 방식을 상세히 공개했다. BMC는 거의 모든 엔터프라이즈 서버 마더보드에 내장된 작고 별도의 컴퓨터로, 메인 장비에서 무슨 일이 일어나고 있는지와 무관하게 자체 운영체제와 네트워크 스택, IP 주소를 사용해 작동한다(Ars Technica). 서버의 전원이 꺼져 있거나 완전히 응답하지 않는 상황에서도 IT 담당자가 원격으로 서버를 재부팅하거나 이미지를 다시 설치하거나 모니터링할 수 있게 해주는 것이 BMC다. 진정으로 유용한 ‘불 꺼진 상태’ 관리 기능이다. 하지만 연구진에 따르면, 그 기반 프로토콜은 적어도 2013년부터 만만한 공격 대상으로 지목되어 왔으며, 현재 악용되고 있는 일부 취약점은 10년도 더 된 것이다. Ars는 이를 ‘널리 퍼져 있지만 모니터링이 부족하고 패치도 제대로 되지 않은 병렬 공격 표면’이라고 표현한다. 새로운 구멍이 아니라, 대부분의 소프트웨어 및 보안 관심이 머무는 지점보다 아래에 있다는 이유로 조용히 무시되어 온 오래된 구멍인 셈이다.
에이전트형 코딩은 이런 일을 더 빠르게, 더 많이 만들어낼 것이다
같은 주에 Meta는 Claude Code, Codex와 함께, 최소한의 인간 개입으로 소프트웨어를 작성하고 배포하는 도구 생태계에 합류하는 터미널 기반 코딩 에이전트 Muse Code를 출시했다(TechCrunch). Zuckerberg가 직접 설명한 방식은 시사하는 바가 크다. 충분히 큰 작업을 맡으면 여러 하위 에이전트로 분산해 병렬로 작업시키고, 격리된 워크트리에서 여러 기능을 동시에 구축한다는 것이다. 이는 실제 생산성 향상이다. 동시에 구조적으로 보면, 인간의 관심 한 단위당 그 어느 때보다 많은 인프라가 구축되고 구성되며 배포된다는 뜻이기도 하다. 더 많은 클라우드 인스턴스, 더 많은 테스트 환경, 더 많은 서버가 신속하게 프로비저닝되는 것이다. 그 작업을 하는 사람들은 BMC 설정을 건드리거나 펌웨어 변경 로그를 읽어보지 않을 수도 있다. 에이전트형 도구는 애플리케이션을 작성하는 데는 매우 뛰어나다. 하지만 그 애플리케이션 아래의 대역 외 관리 칩이 6년 된 펌웨어로 작동하고 있는지에 대해서는 아무런 판단도 내리지 않는다.
이 모든 것이 에이전트형 코딩 도구가 설계상 안전하지 않다는 뜻은 아니다. 이는 Ars Technica 기사에서 다룬 문제와는 별개의 질문이다. 요점은 더 좁다. 생성되는 인프라의 규모가 그 아래 물리적 계층을 패치하는, 화려하지 않은 규율보다 빠르게 커지고 있으며, 위에 놓인 코드가 더 똑똑해졌다고 해서 그 격차가 저절로 줄어들지는 않는다는 것이다.
이것이 단순한 보안 이야기가 아니라 커리어 신호인 이유
여기에 업계 전반에서 여전히 진행 중인 해고를 겹쳐 보자. 이번 주 Monday.com의 인력 약 20% 감축은 AI 기반 구조조정과 명시적으로 연결되어 있으며, AI를 감원 사유로 언급하는 기업 목록에 합류했다(TechCrunch). 여기서 우리가 모르는 것을 솔직히 인정할 필요가 있다. 이들 발표 자료 중 어느 것도 직무별 해고 내역을 구분해 제시하지 않으므로, ‘보안 및 인프라 직무는 보호받는다’고 말할 수 있는 깔끔한 데이터는 없다. 그렇게 말한다면 과장이다. 더 자신 있게 말할 수 있는 것은 통계적 사실이 아니라 구조적 사실이다. 가장 빠르게 자동화되는 직무는 결과물이 텍스트나 코드이거나 LLM이 근사할 수 있는 고객 상호작용인 직무다. 물리적 계층과 펌웨어 수준의 보안, 즉 BMC가 무엇인지, IPMI와 그 후속 기술이 어떻게 작동하는지, 대역 외 관리 접근을 어떻게 감사하는지, 장비 절반을 망가뜨리지 않고 전체 서버군에 펌웨어 패치를 어떻게 배포하는지를 아는 일은 모델보다 기계에 더 가깝다. 현재 AI 에이전트가 분명히 손을 뻗고 있는 작업은 아니며, 그 위의 소프트웨어 계층이 자동화된다고 해서 자동화하기 쉬워지는 일도 아니다.
이 정보를 실제로 어떻게 활용할 것인가
이 문제에 대응하기 위해 펌웨어 엔지니어가 될 필요는 없다. 확인해볼 만한 몇 가지 행동은 다음과 같다.
- 가정하지 말고 물어보라. 자체 서버를 운영하는 회사(순수 클라우드가 아닌)에서 IT, 플랫폼 또는 보안 업무를 맡고 있다면 BMC 펌웨어가 애초에 패치 주기에 포함되어 있는지 물어보라. 많은 조직이 정말로 그 답을 모른다.
- 헤드라인만이 아니라 용어를 배워라. BMC, IPMI, Redfish, 대역 외 관리. 이 용어들은 검색할 수 있고 문서도 잘 갖춰진 개념들이다. 이를 이해하면 AI 시대의 기술 습득이 전적으로 프롬프트와 에이전트에만 향해 있는 대부분의 사람보다 앞서갈 수 있다.
- 에이전트형 코딩 도구가 다루지 않는 것을 살펴보라. 여러분이나 여러분의 팀이 인프라와 인접한 작업에 Muse Code나 Claude Code 같은 도구를 도입할 때, 무엇이 범위 밖에 있는지(배포 대상, 펌웨어, 물리적 접근 통제) 명시적으로 물어보라. 그리고 그 공백을 무시할 누락이 아니라 전문성을 쌓을 영역으로 다뤄라.
- 지나치게 한쪽으로 쏠리지 마라. 이는 여러 가능성 있는 틈새 분야 중 하나일 뿐, 안전이 보장된 피난처는 아니다. 한 편의 Ars Technica 기사만을 근거로 커리어를 전환할 일이 아니라, 조사해볼 만한 헤지 수단으로 받아들여라.
더 넓은 교훈은 BMC에만 국한되지 않는다. AI가 사람들이 볼 수 있는 소프트웨어를 더 잘 다루게 될수록, 자동화하기 어려운 가치는 그 아래의 물리적·운영적 계층에 점점 더 많이 자리 잡는다. 시연에는 나타나지 않는 부분들이다. 이는 ‘프롬프트 작성법을 배워라’보다 더 좁은 베팅이지만, 현재 그 베팅을 하는 사람은 더 적다.
