보안이 소프트웨어 팩토리 도입을 가속한다

“AI는 휴식이 필요없고, 수면도 취하지 않으며, 명절도, 휴가도 없다.” – 박문범, 78ResearchLab CPO¹

2026년 9월 30일, 신한은행이 고객 정보 유출을 금융당국에 보고했다. 2주 뒤인 10월 14일, 금융당국이 집계한 피해 범위는 은행·저축은행·캐피탈·가상자산사업자를 포함한 16개사, 약 10만 건으로 늘어 있었다.² 같은 달 6일에는 여의도순복음교회와 사랑의교회가 해킹으로 교인 정보가 유출된 정황을 밝혔다.³ 그보다 앞선 9월 3일에는 정부 조사단이 티빙(TVING)에서 약 3,954만 개 계정이 유출되었다고 발표했다.⁴

이번 금융권 사고에는 AI가 쓰였다는 이야기가 따라붙는다. 그러나 2026년 10월 15일 기준으로 이것은 확정된 사실이 아니다. 금융당국은 AI 사용 여부를 아직 조사하고 있다.² 확인된 것은 여러 보안업체가 공격 인프라에서 LLM 기반 자동 침투 도구의 흔적을 보고했다는 것까지다.⁵ 그래도 나는 이 정황을 가볍게 넘길 수 없다고 본다. 공격 쪽이 이미 에이전트로 일하기 시작했다면, 방어 쪽이 사람의 속도로 일하는 체계는 오래 버티기 어렵기 때문이다.

이 글의 주장은 하나다. 나는 보안 압력이 소프트웨어 팩토리 도입을 앞당길 것으로 본다. 공격은 빨라지고 있고, AI로 취약점을 찾는 업체들은 이제 수정 역량을 병목으로 지목하며, 규제는 수정 기한을 줄이고 있다. 나는 이 압력들이 발견에서 수정·배포까지 사람이 병목이 되지 않는 개발 체계, 즉 소프트웨어 팩토리 쪽을 가리킨다고 본다. 다만 이것은 “사람 없이 돌아가는 공장"을 뜻하지 않는다. 사람은 규칙을 정하고, 기계는 그 규칙 안에서 쉬지 않고 실행한다.

TL;DR

• 최근 국내 사고에서 조사로 확인되었거나 여러 매체가 보도한 원인은 새로운 공격 기법이 아니었다. 소스코드에 남은 접속키, 우회된 인증 절차, 적용되지 않은 보안 패치처럼 기본 통제가 빠진 곳이었다.
• AI가 바꾸는 것은 공격의 종류보다 속도와 규모다. 공격자가 기본 통제의 빈틈을 찾는 속도가 빨라지면, 빈틈을 발견하고 메우는 데 걸리는 시간이 방어의 핵심 지표가 된다.
• 압력은 이미 움직이고 있다. AI가 취약점을 찾는 속도에 수정이 따라가지 못하고, 미국·EU·한국의 규제는 수정 기한을 줄이거나 빠른 패치의 장벽을 낮추고 있으며, 수정까지 하는 AI 도구도 나와 있다. 다만 도입은 아직 초기이고, 자동 수정에 대한 신뢰도 장벽 중 하나로 꼽힌다.
• 나는 소프트웨어 팩토리가 그 시간을 줄이는 유력한 체계라고 본다. 발견된 문제를 작업으로 만들고, 에이전트가 수정하고, 증거로 검증하고, 실패를 규칙으로 바꾼다.
• 단, 팩토리 자체가 새로운 공격면이 된다. 위험 등급, 쓰기 권한 분리, 사람의 중지 명령 같은 장치 없이 만든 팩토리는 보안을 높이는 대신 위협을 늘린다.

1. 국내에서 무슨 일이 일어나고 있나

아래 표는 2026년 10월 15일까지 공개된 주요 사고를 정리한 것이다. 정부 조사나 피해 기관이 밝힌 원인과, 언론이나 보안업체가 보도·주장한 원인을 구분해 적었다.

통계도 같은 방향을 가리킨다. 과기정통부와 KISA에 따르면 2026년 상반기 침해사고 신고는 1,236건으로 전년보다 19.5% 늘었고, 그중 랜섬웨어 신고는 76.8% 늘었다.⁸

AI가 관여했다는 주장은 어디까지 확인되었나

이 부분은 사실과 추측을 나눠서 봐야 한다.

• 보안업체 분석(복수): 지니언스, 오아시스시큐리티, S2W는 공격에 쓰인 것으로 추정되는 서버에서 중국어 기반 자율 침투 테스트 도구 ARTEX의 흔적을 보고했다. S2W는 ARTEX와 AI 모델을 잇는 중계 프로그램도 발견했다고 밝혔다. 다만 S2W는 데이터 탈취의 어느 부분을 AI가 수행했는지는 당국이 조사해야 한다고 밝혔다.⁵
• CrowdStrike(중간 신뢰도): Reuters 보도에 따르면 CrowdStrike는 공격자가 ARTEX와 Anthropic의 Claude Code를 썼다고 주장했다. 이 평가는 “moderate confidence"이며, 특정 공격 그룹으로 귀속하지 않았다고 스스로 밝혔다.⁹
• 정부: 금융위원회의 10월 2일 보도자료는 사고를 “사이버 공격"과 “침해 시도"로만 서술했다. 10월 14일에도 당국은 AI 해킹 여부를 조사 중이었다.²

정리하면, “LLM 기반 공격 자동화 도구의 흔적이 공격 인프라에서 발견되었다"는 것은 여러 업체가 보고한 내용이다. “AI가 이 공격을 수행했다"는 것은 아직 확인되지 않았다.

해외에는 더 분명한 기록이 있다. Anthropic은 2025년 11월, 중국 국가 배후로 판단한 그룹이 Claude Code를 자율 침투 에이전트로 구성해 약 30개 조직을 노렸고, 전술 작업의 80-90%를 AI가 수행했다고 보고했다. 이 수치는 Anthropic 자체 분석이다.¹⁰

2. 달라진 것은 공격의 종류가 아니라 속도다

78ResearchLab의 CPO이자 보안 전문가인 박문범 님은 이번 사고를 두고 이렇게 썼다. 이 공격은 “기존 공격 기법에 AI라는 ‘터보 엔진’을 달아 효율성과 규모를 극대화한 것"이며, 현장 전문가들이 느끼는 위기감의 실체는 방어 패러다임이 시간을 두고 무너지지 않고 “순식간에 무너졌다는” 데 있다.¹

그가 든 예가 인상적이다. 과거에는 중국의 춘절이나 중추절이 되면 중국발 사이버 공격이 눈에 띄게 줄었다. 사람 공격자에게는 쉬는 날이 있었고, 그 사이에 방어자는 분석하고 대응할 시간을 벌었다. AI에게는 그런 날이 없다.

1절의 표와 이 관찰을 겹쳐 보면 하나의 그림이 나온다. 정부 조사로 확인되었거나 여러 매체가 보도한 원인은 모두 오래된 문제였다. 소스코드에 들어간 비밀키(티빙, 쿠팡), 직원이 퇴사한 뒤에도 바뀌지 않은 키(쿠팡), 인증 우회가 보도된 부속 조회 서비스(신한은행), 적용되지 않은 패치(금융당국 점검)가 그것이다. 금융당국이 10월에 555개 금융회사를 점검한 결과에서도 130곳에서 보안패치 미적용, 24시간 관제 부재, 다중인증 미도입 같은 기본 통제 미흡이 나왔다.¹¹ 실제로 일부 분석은 이번 사고의 핵심 원인이 AI가 아니라 외부에 노출된 API의 권한 검증 결함이라고 본다.¹²

나는 이 두 해석이 충돌하지 않는다고 본다. AI는 새로운 구멍을 만들기보다, 원래 있던 구멍을 사람보다 훨씬 빨리 찾아낼 수 있다. Anthropic이 보고한 사례처럼 AI 에이전트가 정찰과 침투 작업의 대부분을 맡으면, 공격자 한 명이 동시에 시도할 수 있는 대상과 횟수가 늘어난다.¹⁰

공격이 빨라지고 있다는 것은 AI와 별개로 취약점 통계에서도 보인다. Google Mandiant는 M-Trends 2026에서 평균 time-to-exploit(취약점 공개부터 실제 악용까지의 시간)을 약 -7일로 추정했다. 평균이 음수라는 것은 집계에 공개 전에 악용된 사례가 포함되어 있다는 뜻이다.¹³ VulnCheck는 2025년에 악용된 취약점의 28.96%가 공개 당일이나 그 전에 악용되었다고 집계했다. 2024년에는 23.6%였다.¹⁴ 이 두 통계는 AI가 그 원인이라는 것을 보여 주지 않고, 나는 Mandiant의 산출 방법도 확인하지 못했다. 다만 방어자가 취약점 공개 뒤에 대응을 시작할 수 있는 여유가 줄고 있다는 방향은 두 자료가 같다.

공격자가 빈틈을 찾는 데 걸리는 시간이 며칠에서 몇 시간으로 줄면, 방어자에게 중요한 지표도 바뀐다. 빈틈을 발견한 뒤 메우기까지 걸리는 시간 이 그것이다. 티빙은 2024년 모의해킹에서 취약점을 발견했지만 고치지 않았고, 그 취약점이 2026년 사고로 이어졌다.⁴ 발견은 했지만 수정이 따라가지 못한 것이다.

3. 사람의 순서에 묶인 대응은 이 속도를 따라가기 어렵다

전통적인 보안 대응은 대체로 사람의 순서를 따른다. 취약점 보고가 들어오면 담당자가 확인하고, 개발팀에 작업을 요청하고, 개발자가 일정을 잡아 수정하고, 리뷰를 거쳐 정기 배포 일정에 실린다. 각 단계는 합리적이다. 문제는 각 단계 사이의 대기 시간이다. 담당자가 휴가 중이거나, 개발팀이 다른 일정에 묶여 있거나, 배포가 다음 달로 잡혀 있으면 빈틈은 그동안 열려 있다.

이것은 개인의 성실함으로 해결되지 않는다. 박문범 님의 말처럼 공격은 명절에도 쉬지 않는데, 방어 체계의 각 단계는 사람의 근무 시간에 묶여 있다. 그는 더 많은 인력과 장비의 투입을 결론으로 들었다.¹ 나도 그 필요에 동의한다. 다만 사람을 늘리는 것만으로는 대기 시간이라는 구조적 문제가 사라지지 않는다. 사람이 늘어도 각 단계는 여전히 사람의 근무 시간과 승인 순서에 묶이기 때문이다.

기존 CI/CD와 긴급 변경 절차로 충분하지 않느냐는 반론도 있을 수 있다. CI/CD는 사람이 작성한 코드를 빌드하고 배포하는 단계를 자동화한다. 긴급 변경 절차는 승인 단계를 줄인다. 그러나 수정 작업이 대부분 수작업인 조직에서는 문제를 분류하고, 원인을 찾고, 수정 코드를 쓰고, 그 수정이 맞다는 증거를 만드는 일을 여전히 사람이 한다. 나는 그런 조직에서는 이 앞단의 대기 시간이 가장 큰 공백이라고 본다. 반대로 패치 자동화와 긴급 대응 체계가 이미 잘 갖춰진 조직이라면, 팩토리가 더할 수 있는 몫은 그만큼 작을 것이다.

4. 압력은 이미 움직이고 있다

공격 속도만이 아니다. 2026년에는 팩토리 쪽으로 미는 압력이 세 방향에서 동시에 관찰된다. 아래는 사실, 업체 주장, 전망을 구분해 정리한 것이다.

4.1 발견을 자동화한 쪽에서 수정을 병목으로 지목한다

Anthropic은 2026년 5월 Project Glasswing 중간 보고에서, AI로 오픈소스 프로젝트의 취약점을 찾아 유지보수자에게 약 530건을 보고했지만 그중 75건만 패치되었다고 밝혔다. 그리고 이렇게 진단했다. “the bottleneck in fixing bugs like these is the human capacity to triage, report, and design and deploy patches for them.”¹⁵ 10월에는 분류와 패치가 “still mostly manual"이라며, 이를 자동화하는 것을 다음 목표로 내걸었다.¹⁶ 이것은 업체 자체 발표다. 그러나 Forrester도 같은 방향을 전망했다. “Discovery is now cheap. Remediation is where the value lives.”¹⁷

이것은 한 업체의 관찰이고, 530건 중 75건이라는 수치만으로 업계 전체의 병목이 옮겨 갔다고 말할 수는 없다. 그러나 나는 AI가 취약점을 찾는 속도가 공격자와 방어자에게 똑같이 빨라진다면, 방어자가 앞설 수 있는 곳은 찾은 것을 더 빨리 고치는 쪽이라고 본다. 그리고 이 지점이 소프트웨어 팩토리가 들어설 자리라고 본다.

4.2 규제가 수정 기한을 줄이고, 빠른 패치의 장벽을 낮추고 있다

• 미국(사실): CISA는 2026년 6월 BOD 26-04를 발령해, 연방 민간기관이 가장 위험한 취약점을 최단 3일 안에 조치하도록 했다. 우선순위 기준에는 “대규모 자동화 공격 가능 여부"가 들어 있다.¹⁸
• EU(사실): 2026년 9월 11일부터 사이버복원력법(CRA)에 따라 제조사는 실제 악용 중인 취약점을 24시간 안에 조기 보고해야 한다. 이것은 패치 기한이 아니라 보고 기한이다.¹⁹ 유럽중앙은행(ECB)은 직접 감독하는 약 110개 은행에 AI 기반 사이버 위협 대응 실행계획을 10월 31일까지 내라고 요구했고, 중점 영역에 패치 관리가 들어 있다.²⁰
• 한국(사실): 금융위원회는 2026년 5월 보안 목적 AI에 한해 대형 금융회사 49곳의 망분리 규제를 1년간 한시 완화하는 방안을 내놓았다.²¹ 6월에는 AI 보안 테스트와, 당국이 전파한 취약점에 대한 긴급 보안 패치 과정에서 생긴 경미한 전산장애를 제재에서 면책하기로 의결했다.²² 빠르게 패치하다가 생기는 장애의 제재 위험을 줄인 것이다. 다만 면책 범위는 좁다.
• 한국(사실): 이번 금융권 사고 뒤인 10월 14일, 신진창 금융위 사무처장은 “‘AI 공격은 AI로 방어’하는 보안체계를 확립하기 위한 망분리 규제 완화 등 제도개선도 보다 면밀하고 속도감 있게 추진해 나가겠다"고 말했다.²³ 이번 사고를 망분리 개편과 직접 연결하는 것은 적절하지 않다는 전문가 반론도 같은 기사에 실렸다.
• 한국(계획): 과기정통부는 5월 민간 정보보호 추진계획(안)에서 고성능 AI 모델을 취약점 자동 분석과 패치 생성에 시범 적용하겠다고 밝혔다. 집행 시점과 예산은 확인하지 못했다.²⁴

이 조치들 중 어느 것도 “에이전트가 코드를 고쳐 배포하라"고 요구하지 않는다. 그러나 수정 기한은 짧아지고, 빠른 패치와 보안 목적 AI를 가로막던 제도적 장벽은 낮아지고 있다. 나는 이것이 사람의 근무 시간에 묶인 수정 절차로는 맞추기 어려운 방향이라고 본다.

4.3 도구는 이미 수정까지 한다

• DARPA AI Cyber Challenge(사실): 2025년 8월 결선에서 참가 팀의 자율 시스템들은 합성 취약점 54건을 찾아 43건을 패치했다. 과제당 평균 패치 시간은 약 45분, 비용은 약 152달러였다.²⁵
• GitHub Copilot Autofix(업체 주장): 공개 베타 데이터에서 PR 시점 보안 경고의 수정 시간 중앙값이 수동 1.5시간에서 28분으로 줄었다.²⁶
• Google DeepMind CodeMender(업체 주장): 6개월 동안 오픈소스 프로젝트에 보안 수정 72건을 반영했다. 모든 패치는 제출 전에 사람이 검토했다.²⁷

4.4 도입은 아직 초기다

도입은 아직 초기다. Ivanti가 2026년 2월 보안 실무자 1,200여 명을 조사한 결과, 87%가 에이전틱 AI 통합을 우선순위로 꼽았지만 취약점 조치에 AI를 쓰는 비율은 42%였다.²⁸ 국내에서 확인된 사례도 KB금융의 AI 모의해킹 에이전트처럼 점검과 탐지 중심이며,²⁹ “보안 때문에 코딩 에이전트 기반 개발 체계를 도입했다"고 밝힌 국내 기업은 이번 조사에서 찾지 못했다. Forrester는 규제기관과 보험사가 AI의 발견과 실제 조치 사이에 사람의 검증과 승인 단계를 요구할 것으로 전망했다.¹⁷

이 조사들이 도입이 더딘 원인을 밝혀 주지는 않는다. 다만 Kai의 CISO 조사(2차 보도)에서는 응답자의 52%가 자동 결정에 대한 신뢰 부족을 가장 큰 장벽으로 꼽았다.³⁰ 나는 이 신뢰 문제가 오히려 소프트웨어 팩토리의 설계 과제를 정확히 가리킨다고 본다. 자동으로 고치되, 그 수정이 맞다는 증거를 남기고, 위험한 변경은 사람이 승인하는 구조다. 다음 절부터 그 구조를 다룬다.

5. 소프트웨어 팩토리는 무엇을 줄이는가

소프트웨어 팩토리는 AI 에이전트가 작업 유입부터 구현, 검증, 보고, 개선까지 반복적으로 돌리는 개발 체계다. 이 블로그는 9월 글에서 이 개념을 소개했고,³¹ 최근 4편 연재에서 공개 저장소 12곳을 리버스 엔지니어링해 실제로 팩토리가 돌아가는 곳 8곳을 확인했다.³²

연재에서 관찰한 장치들을 보안의 언어로 옮기면 다음과 같다.

• 유입: 이슈, 실패한 CI, 사용자 보고가 자동으로 작업이 된다. 보안에 적용하면 취약점 스캐너의 결과, 모의해킹 보고서, 보안 권고가 담당자의 일정을 기다리지 않고 작업이 된다. 다만 스캐너 결과에는 오탐이 섞여 있으므로, 영향 범위와 심각도를 먼저 분류하고 우선순위를 정하는 단계가 앞에 있어야 한다.
• 게이트와 증거: 3편에서 본 것처럼, 성숙한 팩토리는 “수정 전 코드에서는 실패하고 수정 후에는 통과하는 테스트"를 증거로 요구한다.³³ 보안 수정에 적용하면, 인증 우회가 수정 전에는 성공하고 수정 후에는 막힌다는 것을 테스트로 남기게 된다. 그 테스트는 이후의 모든 변경에서 같은 구멍이 다시 열리지 않는지 계속 확인한다.
• 자기 개선: 4편의 “실패를 규칙으로” 루프는 한 번 일어난 실패를 지시문이나 검사 장치로 바꾼다.³⁴ 보안에 적용한다면, 소스코드에 키가 들어간 사고가 한 번 일어난 뒤에는 키가 들어간 커밋을 게이트에서 막는 검사를 추가하는 식이다. 그러나 4편에서 보았듯 새 규칙이 실제로 효과가 있었는지 확인한 공개 기록은 드물었다. 보안 규칙이라면 그 검사가 실제로 막는지를 주기적으로 시험하는 단계까지 있어야 루프가 완성된다.

자동 수정에도 위험이 있다. 3편에는 메인테이너가 동작을 확인하고 병합한 수정이, 의도된 동작을 바꾼 것으로 밝혀져 릴리스 전에 되돌려진 사례가 있었다(Astro).³³ 보안 수정은 업무 기능을 깨뜨릴 수 있으므로, 수정을 만든 에이전트와 별개인 검증 단계, 그리고 문제가 생겼을 때 되돌리는 조건을 미리 정해 두어야 한다.

여기서 중요한 것은 범위다. 팩토리가 줄이는 것은 소프트웨어의 결함을 발견해서 고치고 배포하기까지의 시간 이다. 피싱으로 탈취된 계정, 관제 인력의 부족, 망 설계의 문제까지 팩토리가 해결하지는 않는다. 노출된 키를 폐기하고 새로 발급하는 운영 작업도 코드 수정과는 별개이고, 코드를 고친다고 이미 노출된 키의 위험이 사라지지는 않는다. 그러나 1절의 원인 중 상당수, 즉 코드에 비밀키를 넣는 습관, 인증 검증 결함, 고치지 않은 취약점은 코드를 고쳐야 재발을 막을 수 있는 문제이고, 이 범위 안에 있다.

효과도 측정해야 한다. 4편에서 본 OpenClaw의 자동 구현 워커는 1주일 동안 52번 성공하고 256번 실패했고, 프로젝트는 실패율이 높으면 자동 구현을 멈추는 장치를 추가했다.³⁴ 자동화가 늘린 검증과 리뷰 부담까지 포함해, 수정에 걸린 시간이 실제로 줄었는지를 재야 한다.

6. 사람은 규칙을 정하고, 기계는 실행한다

“사람의 개입 없이 대응한다"는 표현은 오해를 부르기 쉽다. 연재에서 확인한 사실은 반대에 가까웠다. 팩토리 8곳 중 봇이 main 브랜치 병합을 대량으로 하는 곳은 OpenClaw 하나였고, 나머지에서는 사람의 최종 병합이 주로 관찰되었다.³² 봇에게 병합을 맡긴 OpenClaw조차 변경 종류별 위험 등급을 정의하고, 보안 정책과 릴리스는 사람이 승인하게 했다.³⁵

그래서 나는 필요한 것을 이렇게 정의한다. 사람이 병목이 되지 않는 체계. 사람은 무엇을 자동으로 처리해도 되는지 규칙으로 정한다. 기계는 그 규칙 안에서 밤에도, 명절에도 실행한다. 규칙 밖의 일, 예를 들어 보안 정책 변경이나 되돌리기 어려운 배포는 사람에게 넘긴다.

이때 사람의 승인이 남는다고 해서 대기 시간이 그대로 남는 것은 아니다. 사람이 승인 버튼을 누를 때 이미 문제 분류, 수정 코드, 수정 전 실패와 수정 후 통과를 보여 주는 증거가 준비되어 있다면, 사람의 일은 수정 작업 전체에서 준비된 증거를 검토하는 판단으로 줄어들 수 있다. 얼마나 줄어드는지는 조직마다 측정해 봐야 한다. 긴급한 보안 수정이라면 이 판단을 맡을 당번과 연락 경로를 미리 정해 두는 것이 팩토리 설계의 일부다.

이 구조는 박문범 님이 강조한 “현장 전문가의 경험을 시스템에 반영해야 한다"는 결론과도 이어진다.¹ 현장 전문가는 AI가 만드는 우회 패턴과 침해 징후를 가장 먼저 알아차리는 사람이다. 그 판단이 보고서나 회의록에만 남으면 다음 공격 때 다시 사람의 속도로 처리된다. 반대로 그 판단이 팩토리의 규칙과 검사 장치가 되면, 전문가가 자는 동안에도 그 판단이 실행된다. 팩토리는 현장 전문가를 대체하지 않는다. 전문가의 판단을 쉬지 않고 실행되는 형태로 바꾼다.

7. 팩토리 자체를 지키지 않으면 위협이 늘어난다

팩토리를 보안의 이유로 주장하려면 반대편 위험도 말해야 한다. 쓰기 권한을 가진 에이전트는 그 자체가 공격 대상이다. 공격자가 이슈나 PR 본문에 지시문을 숨겨 에이전트를 조종하는 프롬프트 인젝션, 에이전트가 쓰는 토큰의 탈취가 대표적이다. CrowdStrike의 평가가 맞다면, 이번 금융권 공격자도 개발자들이 쓰는 것과 같은 코딩 에이전트를 썼다.⁹ 도구는 중립적이고, 그 도구를 둘러싼 장치가 결과를 정한다.

연재에서 관찰한 프로젝트들은 이 위험에 대해 구체적인 장치를 두고 있었다.³⁵

• 위험 등급을 파일로 정의한다. 문서 변경, 일반 코드, 민감 경로, 보안 정책, 릴리스를 나누고, 위험이 큰 등급은 CODEOWNERS와 보안 가드로 사람의 승인을 강제한다. (OpenClaw)
• 에이전트에게 쓰기 토큰을 주지 않는다. 분석과 리뷰를 하는 에이전트는 읽기 전용으로 실행하고, 쓰기는 좁은 전용 단계의 워크플로 코드에서만 한다. 리뷰 규칙은 PR의 브랜치가 아니라 대상 브랜치에서 읽어서, PR이 자기 리뷰 규칙을 바꾸지 못하게 한다. (Astro)
• 사람이 언제든 멈출 수 있게 한다. 자동 병합은 옵트인으로 시작하고, 쓰기 권한자가 쓸 수 있는 중지 명령을 둔다. (OpenClaw)

금융권처럼 변경 승인 절차와 직무 분리를 엄격하게 요구받는 조직이라면, 이 장치들이 오히려 출발점이 된다. 위험 등급을 나누면 사람의 승인이 꼭 필요한 변경과 그렇지 않은 변경을 명시적으로 구분할 수 있다. 사람의 승인은 정말 필요한 곳에 남기고, 나머지 단계의 대기 시간을 줄이는 것이 목표다. 구체적인 규정과의 적합성은 각 조직이 감독 규정을 기준으로 따로 검토해야 한다.

결론

박문범 님의 관찰처럼, 과거에는 공격자에게도 쉬는 날이 있었고 방어자는 그 틈에 분석하고 고칠 시간을 벌었다. 나는 사람의 대응 속도에 의존하는 체계의 한계가 점점 커지고 있다고 본다. 국내 사고에 AI가 쓰였는지는 아직 조사 중이지만, 해외에서는 AI 에이전트가 공격 작업의 대부분을 수행했다는 보고가 이미 나왔고, VulnCheck 집계로는 공개 당일이나 그 전에 악용되는 취약점의 비율이 2024년보다 2025년에 늘었다.

이런 환경에서 “우리는 사고가 없었다"는 것은 안전의 근거가 되지 못한다. 기존 방식이 앞으로도 안전을 보장한다는 근거가 없기 때문이다. 우리는 적응해야 하는 시대를 살고 있다.

나는 적응의 방향이 이쪽이라고 본다. 빈틈을 발견한 순간부터 메우기까지의 시간을 사람의 근무 시간에서 떼어내야 한다. 사람은 규칙을 정하고, 기계는 그 규칙 안에서 쉬지 않고 실행하고, 실패는 다시 규칙이 된다. 그리고 그 기계를 둘러싼 장치를 사람이 설계하고 감독한다. 이것이 소프트웨어 팩토리다. 수정 기한은 짧아지고 공격은 쉬지 않는다. 나는 보안이 소프트웨어 팩토리 도입을 가속하는 주요한 이유가 될 것이라고 본다.