뿡야의 IT 기록

PHP 취약점 두 개가 웹 인프라 전체의 문제가 된 이유

PHP 애플리케이션을 최신으로 유지해도 그 코드를 실행하는 PHP 런타임이 취약하면 위험은 남는다.

2026년 10월 20~21일, PHP 보안 업데이트를 앞두고 여러 국가의 보안기관과 서비스 운영사들이 긴급 대응에 나섰다.

이번 이슈는 PHP2Shell이라고 불리는 두 취약점이다.

• CVE-2026-109618: 메모리 부족 처리 과정에서 발생하는 메모리 손상
• CVE-2026-109619: 요청이 끝난 뒤 남은 내부 상태를 다음 요청에서 사용하는 문제

조건이 충족되면 인증되지 않은 공격자가 원격으로 코드를 실행할 수 있다. 두 취약점 모두 PHP 프로젝트 기준 CVSS v4.0 9.2, Critical로 평가됐다. PHP 공식 권고, NHS England 보안 공지

1. 언제 무슨 일이 있었을까?

먼저 사전 경고와 실제 패치 공개를 나눠 볼 필요가 있다.

ENISA 공동 성명에 따르면 PHP 보안 업데이트는 10월 21일 13:40 UTC, 한국 시간으로 10월 21일 오후 10시 40분에 공개됐다. ENISA 공동 성명

공개 전에는 운영 환경을 파악하고 업데이트를 준비하라는 경고가 중심이었다. 공개 이후에는 실제 수정 버전을 적용하는 단계로 넘어갔다.

따라서 ‘패치가 곧 나온다’는 초기 공지만 읽고 대응을 기다려서는 안 된다. 현재는 수정 버전과 배포판별 보안 패키지를 확인할 수 있다.

2. 왜 PHP 사이트 운영자들이 긴장했을까?

이번 문제는 특정 플러그인의 기능 하나에 한정된 취약점이 아니다. PHP 런타임의 요청 처리와 메모리 관리에 관련된 문제다.

구조를 단순화하면 다음과 같다.

외부 HTTP 요청
       ↓
웹 서버와 PHP 실행 환경
       ↓
PHP 내부의 요청 초기화·처리·정리
       ↓
애플리케이션 코드

특히 Apache의 mod_php에서 검증된 경로는 애플리케이션 코드가 시작되기 전에 공격이 발생할 수 있다.

로그인 검사나 프레임워크의 입력 검증이 실행되기 전 단계가 문제가 될 수 있다는 뜻이다.

PHP 공식 권고는 웹 요청을 처리하는 PHP 환경 전반을 점검 대상으로 안내하며 mod_php의 위험을 특히 높게 평가한다. PHP 공식 영향 범위

다만 모든 PHP 서비스에서 같은 요청 하나로 즉시 공격이 성공한다는 의미는 아니다. 실행 방식, 설정, 빌드, 확장 모듈, 애플리케이션 동작에 따라 구체적인 공격 조건이 달라진다.

3. CVE-2026-109618: 메모리가 부족해졌을 때

첫 번째 취약점의 공식 이름은 RCE via OOM corruption이다.

OOM은 Out of Memory, 메모리 부족을 뜻한다.

PHP는 요청을 처리하면서 필요한 메모리를 할당한다. 그런데 일부 내부 데이터는 완전히 초기화되기 전에도 다른 코드가 접근할 수 있는 상태가 된다.

이 시점에 메모리 부족으로 처리가 중단되면 다음 문제가 생길 수 있다.

내부 데이터 생성 시작
          ↓
초기화가 끝나기 전에 메모리 부족 발생
          ↓
현재 작업이 비정상적으로 중단
          ↓
요청 정리 코드가 불완전한 데이터를 정상 데이터처럼 사용
          ↓
메모리 손상

공식 권고는 PHP의 OOM 처리에 사용되던 longjmp()가 일부 문맥에서 안전하지 않은 조기 이탈을 일으키는 문제를 설명한다.

검증된 영향에는 웹 워커 계정 권한으로 실행되는 비인증 원격 코드 실행이 포함된다. mod_php에서는 기본 입력과 메모리 제한을 사용하는 환경에서도 HTTP를 통한 공격이 검증됐다. CVE-2026-109618 공식 기술 권고

메모리 부족이 왜 코드 실행으로 이어질까?

보통 메모리가 부족하면 요청이 실패하거나 프로세스가 종료될 것으로 예상한다.

하지만 불완전한 데이터를 정상적인 내부 구조로 해석하면 프로그램이 잘못된 메모리를 읽거나 그 값에 따라 동작할 수 있다. 즉, 공격자가 영향을 주는 입력과 메모리 배치가 결합하면 단순 장애를 넘어설 가능성이 생긴다.

이 취약점의 핵심은 요청 크기 자체보다 실패한 뒤에도 내부 상태를 안전하게 처리하는가에 있다.

4. CVE-2026-109619: 끝난 요청의 메모리를 다음 요청이 사용

두 번째 취약점은 RCE via stale global state다.

PHP 웹 워커는 하나의 요청을 처리한 뒤 다른 요청을 처리하도록 재사용될 수 있다. 각 요청의 메모리는 정리되더라도 워커 프로세스는 계속 살아 있는 구조다.

문제는 요청에 속한 데이터를 가리키는 내부 상태가 적절하게 초기화되지 않고 남는 경우다.

요청 A가 내부 상태 생성
          ↓
오류 등으로 정상적인 초기화, 정리 흐름 중단
          ↓
요청 A의 메모리는 해제
          ↓
워커에는 그 메모리를 가리키는 상태가 남음
          ↓
같은 워커가 요청 B를 처리
          ↓
이미 해제된 메모리를 사용

이런 문제를 Use-After-Free, 해제 후 사용이라고 부른다.

공식 권고에서는 메모리 노출과 원격 코드 실행을 확인했다. 공격을 일으키는 요청과 남은 상태를 사용하는 요청이 같은 워커에 도달해야 하는 등 조건이 존재한다. CVE-2026-109619 공식 기술 권고

이 문제는 두 사용자가 같은 애플리케이션 세션을 공유한다는 설명과 다르다. PHP 내부의 상태와 메모리 수명 관리가 요청 경계를 넘어 잘못 이어지는 문제다.

5. Apache와 PHP-FPM

공식 기술 권고는 실행 환경별 차이를 설명한다.

첫 번째 취약점에서 FPM은 요청 시작 실패 시 자식 프로세스를 종료하기 때문에 mod_php와 똑같은 경로가 유지되지 않는다. 다만 애플리케이션 실행 단계의 메모리 부족 경로 등은 별도로 고려해야 한다. OOM 취약점의 환경별 설명

두 번째 취약점에서는 FPM에서도 세션 생명주기와 관련된 RCE가 검증됐다. 해당 경로는 적절한 애플리케이션 동작에 의존한다. 상태 재사용 취약점의 검증 범위

따라서 ‘Nginx와 FPM을 쓰니까 괜찮다’고 판단하면 안 된다. 반대로 모든 실행 환경에서 공격 재현 조건이 동일하다고 설명하는 것도 부정확하다.

6. 공격이 실제로 발생하고 있을까?

여기서는 세 가지를 나눠야 한다.

Cloudflare는 공개 전후에 관련 공격 트래픽을 관측했고, 공격자가 방어를 우회하려고 입력을 변경하는 움직임도 확인했다고 밝혔다. Cloudflare 대응 보고

이것은 현실의 공격 시도가 있다는 근거다. 그러나 그 사실만으로 모든 시도가 성공했거나 특정 규모의 사이트가 침해됐다고 단정할 수는 없다.

취약점이 존재하는 것과 내 서버가 이미 침해됐는지는 별도의 조사 문제다.

7. 어떤 버전으로 업데이트해야 할까?

이번 두 취약점을 수정한 PHP 프로젝트의 버전은 다음과 같다.

해당 계열에서는 이 수정 버전 또는 이후의 적절한 보안 릴리스를 적용해야 한다. NHS England 수정 버전 안내

배포판 버전은 숫자만 비교하면 안 된다

Ubuntu와 Red Hat 같은 공급사는 기존 버전에 보안 수정만 가져오는 백포트를 제공할 수 있다.

예를 들어 Ubuntu는 이번 문제에 대해 Ubuntu 24.04 LTS용 8.3.6-0ubuntu0.24.04.13 패키지를 수정 패키지로 안내한다. 앞부분이 8.3.6이라고 해서 곧바로 미패치라고 판단하면 안 되는 이유다. Ubuntu USN-8948-1

판단 기준은 다음 두 가지다.

직접 설치한 PHP
→ PHP 프로젝트의 수정 버전 확인

배포판·제품 공급사가 관리하는 PHP
→ 해당 공급사의 보안 공지와 패키지 전체 버전 확인

PHP 8.1 이하를 사용한다면?

PHP 프로젝트의 정규 지원은 끝났지만, 일부 배포판과 LTS 공급사는 백포트 수정을 제공한다.

이번에는 심각성을 고려해 PHP 7.4, 8.0, 8.1의 최소 소스 백포트도 별도로 제공됐다. 이는 해당 계열의 정규 지원이 재개됐다는 뜻은 아니다. 공급사 패치 여부를 확인하고 지원 버전으로 이전할 계획이 필요하다. PHP 공식 업데이트 안내

8. 우리 서비스에서 PHP를 어디에 쓰는지부터 찾아야 한다

직접 작성한 PHP 사이트만 확인하면 빠뜨리는 자산이 생길 수 있다.

점검 대상에는 다음이 포함될 수 있다.

• 웹서비스와 CMS
• 관리 콘솔과 내부 도구
• 컨테이너 이미지
• 상용·오픈소스 제품에 포함된 PHP
• 호스팅 사업자가 관리하는 실행 환경
• 오래된 테스트·스테이징 서비스

ENISA도 PHP를 직접 사용하는 것처럼 보이지 않는 제품에 PHP가 포함될 수 있다고 지적하며 공급사와 영향 여부를 확인하도록 권고한다. ENISA 영향 확인 지침

php -v만 확인하면 충분할까?

다음 명령은 기본적인 확인에 도움이 된다.

php -v
php --ini

각각 명령줄 PHP의 버전과 설정 파일 정보를 보여준다. PHP 명령줄 공식 문서

하지만 명령줄에서 실행되는 PHP와 실제 웹 요청을 처리하는 PHP가 다를 수 있다.

여러 버전이 설치됐거나 컨테이너, FPM 풀, 웹 서버 모듈이 분리된 환경에서는 특히 주의해야 한다. 확인할 대상은 현재 사용자 요청을 처리하는 프로세스와 이미지다.

phpinfo()로 설정을 확인할 수도 있지만 환경정보와 경로 등이 출력되므로 점검 정보를 공개 페이지로 노출하지 않도록 해야 한다. PHP phpinfo() 문서

9. 패키지 설치가 끝나면 대응도 끝날까?

업데이트 파일이 설치됐다는 사실과 실행 중인 워커가 수정된 코드를 사용한다는 사실은 다르다.

다음은 대응을 정리하기 위한 운영 흐름이다.

PHP 사용 자산 파악
         ↓
공급사 수정 패키지·이미지 확인
         ↓
업데이트 및 필요한 재배포
         ↓
기존 워커 교체·재시작 확인
         ↓
실제 서비스 환경 재확인
         ↓
기능·오류율·보안 로그 확인

컨테이너 환경에서는 새 이미지를 만들었더라도 기존 파드가 계속 서비스할 수 있다. 로드밸런서 뒤에 서버가 여러 대 있다면 일부 인스턴스만 업데이트됐을 수도 있다.

운영 기록에는 적어도 다음 내용을 남기면 좋다.

롤백이 필요하더라도 취약한 이전 버전을 외부에 그대로 재노출하는 결과가 되지 않도록 계획해야 한다.

10. 바로 업데이트하기 어렵다면 어떻게 해야 할까?

PHP 공식 권고는 업데이트만이 완전한 해결책이라고 명시한다.

일부 설정 변경은 특정 경로의 위험을 줄일 수 있지만 전체 취약점을 제거하지 못한다. 예를 들어 세션 업로드 진행률 기능 비활성화는 확인된 일부 경로에 대한 조치이며 다른 내부 상태 문제까지 해결하지 않는다. PHP 공식 완화 지침

ENISA와 영국 NCSC는 즉시 수정이 어려운 경우 노출된 시스템의 격리나 일시적인 오프라인 전환을 검토하도록 안내한다. ENISA 권고, NCSC 권고

또한 이번 문제에서는 일반적인 설정 직관을 그대로 적용하기 어렵다.

• 메모리 제한을 더 낮추면 안전하다고 단정할 수 없다.
• 오류 메시지를 숨기는 것은 내부 상태 오류를 해결하지 않는다.
• 애플리케이션 코드에서 설정을 바꾸기 전에 취약한 처리가 시작될 수 있다.

특히 OOM 관련 임시 설정은 가용성과 자원 제한에도 영향을 준다. 공식 권고의 전제와 한계를 함께 읽어야 한다.

WAF가 있으면 업데이트를 미뤄도 될까?

Cloudflare는 WAF 보호를 배포했다고 발표하면서도 PHP 패치를 적용하라고 권고한다.

WAF는 추가 방어 계층이다. 공격 변형과 서비스 경로를 고려해야 하며, 요청이 WAF를 우회해 원본 서버에 직접 도달하는 구조라면 보호 범위도 달라진다. Cloudflare의 보호 범위와 패치 권고

11. 어떤 로그를 살펴봐야 할까?

공식 기술 권고는 오류와 설정 점검을 함께 수행하도록 설명한다.

살펴볼 자료의 예시는 다음과 같다.

• PHP·웹 서버·리버스 프록시 오류 로그
• 메모리 부족과 워커 비정상 종료
• 반복되는 치명적 오류와 실행시간 초과
• 초기화나 종료 과정의 경고
• 특정 경로·입력 유형에 집중되는 실패

다만 이런 증상은 정상적인 장애에서도 발생할 수 있다. 오류가 있다는 사실만으로 침해를 확정할 수 없고, 오류가 없다고 안전을 보장할 수도 없다. 기록되기 전에 실패하거나 관련 로그 수준이 비활성화돼 있을 수 있다. 공식 로깅·설정 감사 지침

침해 징후가 있다면 취약점 수정과 사고 대응을 나눠 진행해야 한다.

업데이트는 앞으로 같은 취약점이 악용되는 경로를 막지만, 이미 변경된 파일이나 탈취된 비밀정보를 원래 상태로 돌리지는 않는다. 이 경우 로그와 증거를 보존하고 관련 계정과 키, 서버 상태를 조사하는 절차가 필요하다.

12. AI가 발견했다는 점은 어떻게 봐야 할까?

이번 사건이 크게 주목받은 이유 중 하나는 AI를 활용한 취약점 발견이다.

OpenAI의 공개 설명에 따르면 Calif가 AI를 활용해 취약점을 발견했고, Wiz도 두 취약점을 독립적으로 발견하고 보고했다. PHP 유지보수자들이 수정과 릴리스를 주도했으며 여러 연구팀과 보안 조직이 대응에 참여했다. OpenAI의 공동 대응 설명

이 사례에서 확인되는 것은 AI 기반 탐색과 사람이 함께 검증했다는 사실이다.

이것만으로 AI가 모든 취약점을 찾을 수 있다거나 사람이 보안 검토를 할 필요가 없어졌다고 결론 내릴 수는 없다.

운영 관점에서는 다른 질문이 중요해진다.

취약점 발견이 빨라졌을 때 우리 조직은 노출된 자산을 찾고 수정하는 속도도 따라갈 수 있을까?

13. 이번 사건에서 남는 운영 과제

PHP2Shell은 애플리케이션 코드 바깥의 런타임도 보안 관리 대상이라는 사실을 보여준다.

대응력을 점검하려면 다음 질문에 답할 수 있어야 한다.

이번 사건의 우선순위는 실제로 웹 요청을 처리하는 PHP를 찾아 수정된 실행 환경으로 교체하는 것이다. 이후에는 패치가 모든 인스턴스에 반영됐는지 기존 노출 기간에 이상 징후가 있었는지까지 확인해야 한다.

참고 자료

• PHP — 2026년 10월 21일 공식 보안 권고
• PHP — CVE-2026-109618 기술 권고
• PHP — CVE-2026-109619 기술 권고
• ENISA — 공동 대응 성명
• Ubuntu — USN-8948-1
• Cloudflare — PHP2Shell 방어 보고
• NCSC-NL — 제품 영향 정보 저장소

개발과 인프라 관련 글을 읽다 보면 Ops로 끝나는 용어를 자주 만나게 된다.

DevOps를 이해했다고 생각하면 DevSecOps가 등장하고, AI 이야기를 따라가다 보면 AIOps와 AISecOps까지 나온다. 이름만 보면 기존 개념에 단어를 하나씩 붙인 것처럼 느껴진다.

하지만 구분하는 기준은 의외로 명확하다.

어떤 업무를 연결하는지, AI를 어디에 사용하는지, 무엇을 보호하려는지를 보면 된다.

이 글에서는 네 가지 용어를 비교하고, 하나의 서비스를 개발하고 운영하는 상황에서 각각 어떤 역할을 하는지 살펴본다.

1. 먼저 전체 그림부터 보기

여기서 AISecOps는 사용하는 조직과 자료에 따라 의미가 달라질 수 있다. 어떤 곳은 AI 기반 보안 분석을, 다른 곳은 AI 시스템과 에이전트를 안전하게 운영하는 활동을 강조한다.

따라서 이 용어를 접하면 먼저 “AI로 보안을 하는가, AI 자체를 보호하는가?”를 확인하는 편이 좋다. 실제로 AISecOps Interceptor 프로젝트는 실행하는 AI 시스템의 런타임 거버넌스에 초점을 맞춘다. 이는 해당 프로젝트의 정의로 이해해야 한다.

2. DevOps: 개발과 운영이 서비스의 전체 흐름을 함께 책임진다

개발팀이 기능을 완성해 운영팀에 전달했다고 가정해 보자.

개발 환경에서는 잘 동작했는데 실제 서버에서는 오류가 발생한다. 운영팀은 배포 정보를 충분히 전달받지 못했고, 개발팀은 운영 환경을 정확히 모른다.

이런 단절을 줄이기 위해 개발과 운영의 협업을 강조하는 접근이 DevOps다.

DevOps는 도구와 자동화뿐 아니라 팀이 책임을 공유하고 운영 결과를 개발에 반영하는 방식까지 포함한다. CI/CD는 이를 구현하는 대표적인 수단이다. IBM의 DevOps 설명

예를 들어 다음과 같은 흐름을 만들 수 있다.

코드 변경
   ↓
자동 빌드 및 테스트
   ↓
배포 준비
   ↓
서비스 배포
   ↓
운영 상태 확인
   ↓
다음 변경에 반영

이 글의 예시에서 중요한 변화는 “배포가 끝났다”의 기준이다.

파일을 서버에 올리는 것으로 끝내지 않고, 사용자 요청이 정상적으로 처리되는지까지 확인한다. 문제가 생기면 변경 사항을 추적하고 복구할 수 있어야 한다.

DevOps를 도입할 때는 다음 질문이 유용하다.

• 동일한 코드를 같은 방식으로 다시 배포할 수 있는가?
• 어떤 변경이 언제 배포됐는지 추적할 수 있는가?
• 장애가 생겼을 때 개발팀과 운영팀이 같은 정보를 보는가?
• 문제가 있는 배포를 되돌릴 수 있는가?

이 질문에 답하는 과정이 도구의 개수보다 중요하다.

3. DevSecOps: 개발과 운영의 흐름에 보안을 통합한다

배포가 빨라지면 보안 검토 방식도 달라져야 한다.

개발이 모두 끝난 뒤 보안팀이 한 번 검토하는 방식으로는, 자주 변경되는 서비스의 위험을 따라가기 어렵다.

DevSecOps는 설계·개발·테스트·배포·운영 전반에 보안을 통합하고, 개발팀·보안팀·운영팀이 책임을 공유하는 접근이다. IBM의 DevSecOps 설명

예시 파이프라인은 다음처럼 확장할 수 있다.

설계 및 위협 검토
   ↓
코드 작성
   ↓
테스트 + 코드·의존성·비밀정보 검사
   ↓
배포 구성 검토
   ↓
정책에 따른 배포
   ↓
운영 중 탐지 및 취약점 대응

여기서 각 검사는 서로 다른 문제를 찾는다.

이 표는 구현 활동을 이해하기 위한 예시다. 모든 조직이 동일한 도구나 순서로 구성해야 한다는 뜻은 아니다.

또한 스캐너를 연결했다고 보안 문제가 자동으로 해결되지는 않는다. 검사 결과를 누가 검토하고, 어떤 기준으로 수정하며, 예외를 언제 재검토할지까지 정해야 실제 업무가 된다.

예를 들어 취약점이 발견됐을 때 다음 정보가 있으면 판단하기 쉽다.

• 해당 서비스에서 문제가 되는 기능을 실제로 사용하는가?
• 외부에서 접근할 수 있는가?
• 수정된 버전이 있는가?
• 즉시 수정하기 어렵다면 적용할 완화 조치가 있는가?

DevSecOps는 이런 판단을 개발과 운영 흐름 안에서 지속하는 방식으로 이해하면 된다.

4. AIOps: AI를 활용해 IT 운영 데이터를 분석한다

AIOps는 일반적으로 Artificial Intelligence for IT Operations를 의미한다.

로그, 메트릭, 이벤트 등 운영 데이터를 분석해 중요한 이상 신호를 찾고, 연관된 문제를 묶거나 장애 원인 후보를 좁히는 데 AI와 머신러닝을 활용한다. 생성형 AI가 반드시 필요한 개념은 아니다. IBM의 AIOps 설명

여기서 자주 생기는 혼동이 있다.

AIOps의 기본 의미는 ‘AI 모델을 운영하는 일’이 아니라, ‘IT 운영에 AI를 활용하는 일’이다.

예를 들어 쇼핑몰에서 다음 알림이 동시에 발생했다고 하자.

상품 API 응답 지연
결제 API 타임아웃
DB 연결 대기 증가
일부 애플리케이션의 CPU 사용률 상승

담당자는 각각의 알림을 조사해야 한다. 하지만 모두 하나의 문제에서 파생됐을 수도 있다.

AIOps의 대표적인 활용은 이런 이벤트의 시간과 관계를 분석해, 같은 장애와 관련될 가능성이 높은 신호를 모으는 것이다. AIOps의 이벤트 연관 분석

이 사례에서 운영자가 받고 싶은 결과는 다음과 같다.

관측된 현상:
여러 API에서 같은 시간대에 지연 발생

우선 확인할 대상:
DB 연결 대기 증가

추가 확인:
최근 배포와 연결 설정 변경 여부

이 결과는 조사할 가설이다. AI가 원인을 확정했다고 받아들이기보다는 실제 지표와 변경 이력을 확인해야 한다.

실무에서 시도해 볼 만한 적용 범위는 다음과 같다.

• 반복되는 알림을 묶어 전달하기
• 장애 관련 로그를 찾아 요약하기
• 최근 배포와 이상 발생 시점을 비교하기
• 담당 팀에 조사 자료를 모아 전달하기

처음에는 분석과 추천부터 시작하고, 검증 결과에 따라 자동 조치 범위를 늘리는 구성을 고려할 수 있다.

5. AISecOps: AI로 보안을 운영하는가, AI를 안전하게 운영하는가?

AISecOps를 이해할 때는 두 가지 방향을 나눠 보면 편하다.

이 구분은 이 글에서 혼동을 줄이기 위해 사용하는 설명 방식이다.

5-1. AI를 활용한 보안 운영

첫 번째 방향은 보안 담당자의 분석과 대응에 AI를 활용하는 것이다.

예를 들어 여러 경보를 요약하거나, 의심스러운 활동의 조사 순서를 제안하고, 보안 로그를 조회할 쿼리 작성을 돕는 방식이다.

Microsoft Security Copilot도 사고 대응, 위협 헌팅, 정보 수집, 보안 상태 관리 등을 지원하는 생성형 AI 보안 솔루션으로 설명된다. Microsoft 공식 문서

가상의 계정 침해 조사에서는 다음과 같이 활용할 수 있다.

로그인 및 보안 이벤트 수집
   ↓
AI가 사건의 시간 순서 요약
   ↓
추가 조사 항목 제안
   ↓
담당자가 근거 확인
   ↓
계정 보호 및 대응

AIOps와 데이터 분석 방식이 겹칠 수 있지만, 이 예시의 목표는 보안 사고 조사다.

5-2. AI 시스템 자체의 보안 운영

두 번째 방향은 AI 서비스와 에이전트를 보호하고 통제하는 것이다.

AI 시스템도 일반 소프트웨어와 마찬가지로 접근 통제와 기반 인프라 보안이 필요하다. 여기에 모델, 데이터, 입력과 출력 등 AI와 관련된 위험을 함께 고려해야 한다. NIST도 일반적인 사이버보안 위험과 AI 고유의 위험이 겹친다고 설명한다. NIST의 AI 보안·복원력 설명

특히 에이전트가 외부 도구를 실행하면, 잘못된 판단이 실제 작업으로 이어질 수 있다.

예를 들어 운영 지원 에이전트가 로그를 읽는 권한과 서버 설정을 바꾸는 권한을 모두 가지고 있다고 하자. 외부 입력이나 도구 결과를 잘못 해석하면 의도하지 않은 변경을 시도할 수 있다.

OWASP는 과도한 기능, 권한, 자율성이 결합해 피해를 일으키는 위험을 Excessive Agency로 설명한다. OWASP: Excessive Agency

이런 시스템에서는 다음과 같은 운영 설계를 검토할 수 있다.

• 에이전트에 업무에 필요한 최소 권한만 부여하기
• 읽기 작업과 변경 작업의 권한을 구분하기
• 영향이 큰 작업에는 승인 절차 적용하기
• 도구 호출의 대상과 인자를 실행 전에 검증하기
• 실행 기록과 결과를 남기기
• 작업 횟수·시간·비용에 한도를 설정하기

핵심은 AI의 답변 품질과 함께 실제로 실행할 수 있는 행동의 범위를 관리하는 것이다.

6. 하나의 장애 상황에서 비교해 보기

이제 가상의 쇼핑몰에 결제 기능을 배포했다고 가정해 보자.

DevOps 관점

코드 변경이 테스트와 배포를 거쳐 서비스에 반영된다. 배포 후 결제 성공률과 오류율을 확인하고, 문제가 있으면 복구한다.

관심사는 변경을 전달하고 운영 결과를 반영하는 흐름이다.

DevSecOps 관점

결제 기능의 권한과 데이터 흐름을 검토한다. 코드와 의존성 등을 검사하고, 발견된 위험을 처리한 뒤 배포한다. 운영 중 발견된 취약점도 수정 흐름으로 연결한다.

관심사는 변경 과정과 운영 전반의 보안이다.

AIOps 관점

배포 이후 여러 서비스에서 발생한 알림을 분석한다. 결제 오류와 DB 대기 증가가 함께 발생했다면 관련성을 제시하고 조사할 대상을 좁힌다.

관심사는 운영 데이터에서 문제의 신호를 찾는 일이다.

AI 기반 보안 운영 관점

같은 시간대의 비정상 로그인과 권한 변경을 분석한다. 단순 장애 외에 침해 가능성도 조사한다.

관심사는 위협의 탐지와 조사다.

AI 시스템 보안 운영 관점

조사를 지원하는 에이전트가 어떤 로그를 읽고 어떤 명령을 실행할 수 있는지 통제한다. 결제 서비스 설정을 바꾸는 작업은 별도의 정책으로 검증한다.

관심사는 조사 도구로 사용되는 AI의 행동과 권한이다.

이처럼 하나의 서비스 안에서 여러 접근이 함께 적용될 수 있다.

7. MLOps와 LLMOps는 어디에 해당할까?

AIOps와 함께 자주 등장하는 용어가 MLOps와 LLMOps다.

MLOps는 머신러닝 모델을 실제 환경에서 개발·배포·관리하는 생애주기에 초점을 맞춘다. IBM도 AIOps와 MLOps를 이 기준으로 구분한다. IBM Developer의 Ops 비교

LLMOps는 보통 그중 LLM 기반 시스템의 평가와 운영을 강조할 때 사용한다.

대상을 기준으로 비교하면 이해하기 쉽다.

실제 조직에서는 이 업무들이 겹친다. 추천 모델을 배포하는 팀도 DevSecOps를 적용할 수 있고, LLM 서비스의 장애를 AIOps 도구로 분석할 수도 있다.

8. 우리 팀은 어디서부터 시작하면 좋을까?

도입 방향을 정할 때는 팀에서 반복되는 문제를 먼저 적어 보는 것을 권한다.

이 표는 도입을 위한 제안이다. AI를 적용하기 전에 데이터와 책임 범위가 정리돼 있는지도 함께 살펴봐야 한다.

서비스 이름이 시스템마다 다르고, 변경 이력이 남지 않으며, 담당자 정보도 없다면 AI 분석 결과를 검증하기 어렵다. 에이전트가 어떤 권한으로 작업하는지 모른다면 자동화 범위를 넓히기도 어렵다.

작게 시작하는 방법은 다음과 같다.

1. 반복되는 업무 하나를 선택한다.
2. 필요한 데이터와 담당자를 정한다.
3. 현재 걸리는 시간과 오류를 기록한다.
4. 자동화 또는 AI 보조를 적용한다.
5. 절약한 시간과 잘못된 결과를 함께 평가한다.
6. 검증된 범위부터 확대한다.

“AI를 도입했다”보다 “장애 조사에 필요한 자료를 모으는 시간이 줄었다”처럼 구체적인 결과를 확인하는 편이 유용하다.

9. 성과는 어떤 지표로 확인할까?

이 글에서 제안하는 평가 예시는 다음과 같다.

속도와 정확도를 함께 봐야 한다.

알림을 줄였지만 중요한 장애까지 숨겼다면 개선으로 보기 어렵다. 조사 보고서를 빨리 만들었어도 근거가 틀렸다면 검토 부담이 늘어난다. 에이전트의 작업 성공률이 높아도 허용 범위를 벗어났다면 통제를 다시 살펴봐야 한다.

팀이 원하는 결과를 먼저 정의해야 지표도 의미가 생긴다.

마치며

DevOps는 개발과 운영을 연결하고, DevSecOps는 그 흐름에 보안을 통합한다. AIOps는 운영 데이터를 분석하는 데 AI를 활용한다.

AISecOps는 자료마다 강조점이 다르므로 적용 범위를 확인해야 한다. 이 글에서는 AI를 활용한 보안 운영과 AI 시스템 자체의 보안 운영으로 나누어 살펴봤다.

앞으로 에이전트가 더 많은 도구를 실행하게 되면, 분석 결과를 검토하는 일과 실행 권한을 관리하는 일이 모두 중요해질 것이다.

새로운 용어를 도입할 때 우리 팀이 먼저 답해야 할 질문도 구체적이다.

어떤 업무를 개선하려는가? 어떤 근거로 효과를 확인할 것인가? 자동화에는 어디까지 권한을 줄 것인가?