Anthropic, 발전소 보안에 현장 지원…검증은 사람 몫

Anthropic은 2026년 10월 8일 Cyber Mission 발표에서 전력망·수도·교통의 운영기술을 보호하는 공급사에 Claude 모델, 현장 엔지니어, 위협 연구를 제공하는 Critical Infrastructure Defense Program을 공개하고 Accenture, Dragos, Hitachi, Rockwell Automation 등을 포함한 11곳을 창립 파트너로 소개했다. 오픈소스 프로젝트를 위한 무료 OSS Scanner도 같은 날 시작했다.

현장 지원의 대상은 설비 보안을 이미 맡고 있는 전문 업체다. Axios의 프로그램 취재에 따르면 일부 파트너는 Claude로 취약점 수정 작업을 시작했지만, 가동 중인 설비에 패치를 안전하게 시험·배포할 방식과 모델 사용 비용의 부담 주체는 공개되지 않았다. AI가 결함을 지목하는 일과 설비 변경을 승인하는 일은 다른 단계다.

현장 엔지니어는 보안 공급사를 지원한다

교통 설비의 제어 장비와 계속 운행해야 하는 현장을 통해 운영기술 보안의 제약을 보여 준다.

전력이나 수처리 설비를 지키는 일에는 보안 소프트웨어 업체뿐 아니라 제어 장비 제조사와 시스템 통합업체가 관여한다. 이번 프로그램은 이들이 이미 운영사와 맺은 관계를 통해 모델 분석을 실제 장비의 조건에 연결하려는 시도다. 취약점 후보를 찾는 능력만으로 제어 장치의 교체 가능 여부나 운전 중 작업 가능 시간을 판단할 수는 없다.

창립 파트너의 구성이 그 접근을 보여 준다. Dragos와 Nozomi Networks는 산업 제어망 보안에 특화돼 있고, Hitachi와 Rockwell Automation은 설비와 관련된 제품을 만든다. Accenture와 Deloitte 같은 기업은 운영사의 보안 체계 구축에 참여한다. 서로 맡는 업무가 다르므로 같은 모델의 발견이라도 어느 회사가 장비 지원 범위를 확인하고 누가 운영사에 조치를 권고할지 구분해야 한다.

운영기술은 제어 장치, 제어 소프트웨어, 산업용 네트워크로 이뤄진다. 오래 쓰도록 설계된 장비는 알려진 결함이 있어도 즉시 멈춰 패치하기 어렵다. 설비를 끄면 전력이나 물의 공급에 영향이 갈 수 있고, 잘못된 변경은 보안 문제와 별개의 운전 위험을 만든다. 이 때문에 코드에서 발견한 결함의 심각도와 현장에서 적용 가능한 수정의 우선순위가 항상 일치하지는 않는다.

현장 엔지니어가 참여한다는 약속은 바로 이 간격에 걸쳐 있다. 모델이 낸 결과를 장비의 구성, 공급사의 지원 상태, 실제 운전 조건과 대조해야 수정 제안이 현실적인 조치가 된다. 여러 파트너가 이미 작업 중이라는 사실은 확인되지만, 개별 발전소에 엔지니어가 배치됐거나 특정 설비에서 패치가 안전하게 끝났다는 공개 사례는 아직 제시되지 않았다.

OSS Scanner는 검토 전 보고서를 보낸다

OSS Scanner가 제시한 오픈소스 취약점 후보와 유지관리자가 검증해야 할 수정안을 구분한다.

오픈소스 쪽에서는 속도를 위해 다른 선택을 했다. OSS Scanner 운영 안내에 따르면 핵심 유지관리자가 신청한 프로젝트를 모델이 정기적으로 검사하고, 취약점의 재현 자료와 원인 설명, 가능한 경우 수정 제안을 이메일로 보낸다. 서비스 비용은 Anthropic이 부담한다. 보고서는 유지관리자에게 전달되기 전에 사람이 개별 발견의 정확성을 검토하지 않는다.

사전 검토가 빠진 만큼 보고서에는 오탐이나 잘못 매긴 심각도가 섞일 수 있다. 검사 과정에서 다른 에이전트가 버그를 재확인하고 패치를 제안하더라도 그것은 자동화된 내부 절차다. 유지관리자가 재현 조건을 확인하고 프로젝트의 테스트를 통과시켜야 발견이 실제 수정으로 이어진다. 빠른 통지를 얻는 대신 검증 업무의 일부가 보고서를 받는 팀에 옮겨가는 셈이다.

참여 범위는 모든 저장소로 열려 있지 않다. 인프라와 사용자 보안에 중요한 영향을 주는 성숙한 프로젝트를 대상으로 삼고, 기존의 검증된 중대한 취약점 보고도 처리할 수 있는 역량을 고려한다. 신청은 핵심 유지관리자가 하며, 등록 요청과 보안 연락처는 사람이 확인한다. 이는 보고서가 적절한 수신자에게 도착하도록 하는 통제로, 취약점 자체의 진위를 판정하는 검토와는 역할이 다르다.

프로젝트는 보고서 수신을 일시 중단하거나 참여를 철회할 수 있다. 자동 보고를 멈춘 뒤에는 사람이 검증하는 기존의 취약점 공개 절차만 적용된다. 미검증 보고에는 곧바로 공개 기한을 강제하지 않는다는 운영 원칙도 있다. 확실하지 않은 발견을 받은 유지관리자에게 정해진 시한 안에 수정하라고 요구하면 오탐을 가리는 데에도 부담이 생길 수 있다.

AI의 발견과 설비 변경 승인 사이

수도 설비의 가동을 유지하면서 수정 사항을 검증하고 승인해야 하는 과정을 보여 준다.

두 프로그램이 보안 담당자의 일을 바꾸는 지점은 발견 이후다. 모델은 취약한 코드 경로나 수정 후보를 넓게 찾아낼 수 있지만, 운영사는 해당 경로가 자신의 장비 구성에서 실행되는지 먼저 확인해야 한다. 이어 제조사가 수정 버전을 지원하는지, 시험 환경이 실제 제어망의 동작을 재현하는지, 변경 중 서비스를 유지할 방법이 있는지 검토해야 한다.

가령 제어 소프트웨어의 한 함수가 위험하다는 보고가 왔다고 가정하자. 보안 공급사는 근거를 재현하고 영향받는 버전을 특정할 수 있다. 장비 제조사는 수정안이 지원되는 조합인지 판단하고, 운영사는 정비 일정과 대체 운전 방안을 검토해 적용을 승인한다. 이는 실제 파트너 현장의 사례가 아니라 발견·검증·배포 권한이 왜 분리돼야 하는지 설명하는 예시다.

책임의 경계가 흐리면 모델이 낸 높은 심각도 표시가 곧바로 긴급 변경 명령처럼 취급될 수 있다. 반대로 공급사가 후보만 전달하고 재현 근거를 남기지 않으면 운영사는 현장 영향도를 판단하기 어렵다. 제어망에 닿는 변경에는 영향받는 장비와 버전, 검증 결과, 되돌릴 수 있는 조건을 함께 인계해야 한다. 최종 변경 승인은 실제 가동 위험을 떠안는 조직의 절차 안에서 이뤄져야 한다.

오픈소스 프로젝트에서도 역할은 나뉜다. 자동 보고는 의심 지점을 빠르게 알려 주지만, 유지관리자가 영향 범위를 확인하고 수정안을 코드에 반영해야 한다. 같은 라이브러리를 쓰는 인프라 업체라면 상위 프로젝트의 수정이 나왔다고 즉시 제어 시스템에 넣을 수도 없다. 자체 테스트와 장비 공급사의 호환성 판단을 거쳐야 소프트웨어 업데이트가 운영 중인 설비의 변경으로 넘어간다.

국내 운영사에는 승인 주체가 핵심이다

한국의 전력·수도·교통 조직이 이번 프로그램의 파트너 제품이나 서비스를 접한다면, 우선 확인할 것은 모델이 몇 건을 찾아냈는지가 아니다. 공급사가 어떤 근거로 발견을 재현하고, 장비 제조사가 어느 범위까지 수정안을 지원하며, 운영사 안에서 누가 최종 가동 변경을 승인할지 정하는지가 핵심이다. 공급 계약과 유지보수 계약의 경계에 이 업무가 걸릴 수 있다.

현장 엔지니어의 참여도 운영사 내부의 권한을 대신하지 않는다. 외부 전문가는 모델 분석을 설비의 언어로 해석하고 적용 가능한 방안을 좁힐 수 있지만, 정지 가능 시간과 우회 운전의 안전성을 아는 쪽은 운영사다. 발전소 보안에서 사람의 검증이 중요하다는 말은 단순한 수동 확인이 아니라 기술적 재현과 운전상 승인이라는 서로 다른 판단을 연결한다는 뜻이다.

오픈소스 유지관리자에게는 보고서가 많아질 때 우선순위를 정할 인력이 문제다. 자동 보고의 재현 자료가 충분한지, 중복 발견인지, 실제 사용 환경에서 악용 가능한지를 가려야 한다. 무료 검사라는 가격 조건만으로 그 작업 비용이 사라지는 것은 아니다. 유지관리자가 검증 역량을 갖춘 프로젝트를 참여 대상으로 삼는 이유도 여기에 있다.

향후 파트너와 적용 분야가 넓어지면서 효과와 실패 사례가 공개되면, 취약점 후보의 총량보다 검증된 수정이 실제 설비에 어떤 절차로 반영됐는지가 더 중요한 결과가 될 것이다. 그 과정이 드러나야 현장 엔지니어와 모델의 기여, 운영사의 최종 책임을 각각 평가할 수 있다.

함께 읽기: