보안진단은 외주 업무가 아니라 개발 공정이 된다

AI 시대의 보안진단은 외주 진단비를 줄이는 문제가 아니라, 개발 공정 안에 반복 가능한 검증 능력을 심는 문제다. 개발자와 공격자가 동시에 빨라진다면, 보안진단도 마지막 이벤트가 아니라 개발 과정의 일부가 되어야 한다.

이 글은 이전에 쓴 보안 진단 보고서는 발행되면 죽는다의 다음 단계다. 그 글이 진단 결과를 문서가 아니라 실행 가능한 코드와 절차로 남겨야 한다는 문제의식이었다면, 이 글은 그 생각을 AI 시대의 개발 공정 안으로 가져온다.

이 글은 CVE 이후의 보안 시리즈의 세 번째 글이다.

• 1편: CVE 이후 대응만으로는 늦다: AI 시대 취약점은 번호가 붙기 전에 움직인다
• 2편: AI Slop의 역설: 취약점을 더 잘 찾는 시대에 triage가 더 어려워지는 이유
• 3편: 보안진단은 외주 업무가 아니라 개발 공정이 된다
• 4편: 공급망 보안은 SBOM만으로 끝나지 않는다: AI 개발 도구와 자동화 연결 관리

첫 번째 글에서는 CVE/NVD 중심 대응의 한계를 다뤘고, 두 번째 글에서는 AI slop과 triage 비용의 증가를 다뤘다. 이번 글에서는 그 문제를 내부 운영 모델로 가져온다.

1. 질문이 잘못되었다

보안진단 AI를 이야기할 때 흔히 나오는 질문은 이렇다.

“AI 보안진단 솔루션을 도입하면 외주 진단비를 줄일 수 있는가?”

이 질문은 직관적이지만 충분하지 않다.

AI 시대에 더 중요한 질문은 이것이다.

개발 AI 활용과 공격자 AI 활용이 동시에 확산되는 상황에서, 보안진단 기능을 어떤 공정에, 어떤 구조로 내재화하여 대응 속도를 확보할 것인가?

즉, 핵심은 AI 솔루션을 살 것인가 말 것인가가 아니다.

보안진단을 계속 건별 수작업과 외주 중심 업무로 둘 것인가, 아니면 개발 프로세스 안에서 반복 가능한 통제로 바꿀 것인가가 핵심이다.

그림. 보안진단의 목표는 일회성 외주 이벤트를 줄이는 것이 아니라, 개발과 배포 흐름 안에 반복 가능한 검증 능력을 넣는 것이다.

2. 개발 속도는 빨라지고 있다

개발 영역에서 AI agent 활용은 빠르게 확산되고 있다.

코드 작성, 수정, 테스트, 문서화, 배포 준비가 이전보다 빨라질 가능성이 높다. 개발자가 직접 작성하던 반복 코드와 테스트 초안은 agent가 보조하고, 코드 변경량과 배포 주기는 늘어날 수 있다.

이 변화는 좋은 면만 있는 것이 아니다.

개발 속도가 빨라지면 보안 검토도 같이 빨라져야 한다. 그렇지 않으면 개발과 보안 사이의 시간 격차가 커진다.

개발 속도 증가
→ 코드 변경량 증가
→ 배포 빈도 증가
→ 보안 검토 대상 증가
→ 기존 수작업 진단 병목 증가

만약 보안진단이 기존처럼 건별 수작업과 외주 중심 구조에 머문다면, 보안은 개발의 마지막 단계에서 병목이 되거나, 반대로 충분히 검토하지 못한 채 우회되는 공백이 될 수 있다.

3. 공격자도 같은 속도를 얻는다

AI는 방어자만의 도구가 아니다.

공격자 역시 AI를 이용해 다음 작업을 빠르게 수행할 수 있다.

• 정찰
• 취약점 후보 탐색
• PoC 생성
• patch diff 분석
• 피싱 문구 작성
• 악성코드 변형
• 자동화된 공격 시나리오 구성
• 공개 write-up 기반 exploit 재현

즉, 보안진단 AI의 필요성은 단순히 내부 효율화에서만 나오지 않는다.

공격자와 개발자가 모두 빨라지는 상황에서, 방어자가 기존 속도에 머무르면 대응 공백이 생긴다.

보안진단 AI 활용은 비용 절감 과제가 아니라 운영 속도와 반복 검증 능력을 확보하기 위한 전환 과제다.

4. AI 비용은 구독료가 아니라 공정별 원가가 된다

초기에는 AI 도구 비용을 월 구독료처럼 생각하기 쉽다.

하지만 실제 운영 단계에서는 다르다.

AI 비용은 다음 요소에 따라 달라진다.

• 입력 토큰
• 출력 토큰
• 컨텍스트 길이
• agent 실행 횟수
• 도구 호출 횟수
• API 호출 비용
• 코드 실행 여부
• 재시도 횟수
• 캐시 사용 여부
• 배치 처리 여부
• 사람 검토 비율

이렇게 되면 AI 비용은 단순한 도구 구독료가 아니라 공정별 실행 원가에 가까워진다.

보안진단 공정에 AI를 넣는다는 것은, 각 공정마다 AI 사용량과 운영 비용이 발생한다는 뜻이다.

따라서 비교 방식도 바뀌어야 한다.

결국 AI 사용량 기반 비용이 커질수록 사람 인건비와 비교되는 것은 피하기 어렵다.

다만 이 비교는 “사람 1명 vs AI”가 아니다.

공정별 총원가 비교여야 한다.

5. 보안진단은 하나의 업무가 아니다

신규 서비스 진단 1건을 하나의 비용 단위로 보는 것은 편하다.

예를 들어 “1명 × 4주” 같은 기준선을 만들 수 있다. 하지만 이 금액을 곧바로 AI가 대체 가능한 금액으로 보면 비교가 왜곡된다.

보안진단은 하나의 단일 업무가 아니라 여러 공정의 묶음이기 때문이다.

• 사전 자산 식별
• API 목록 정리
• 정적 점검
• 동적 점검
• OSS 점검
• 체크리스트 작성
• 리포트 작성
• 이행확인
• 재검증
• 인증·인가 구조 검토
• 비즈니스 로직 판단
• 실제 악용 가능성 검증
• 최종 위험도 판단

이 공정들은 자동화 가능성이 다르다. 필요한 책임 수준도 다르다. AI 사용 비용도 다르다.

따라서 비용효율을 보려면 서비스 1건 전체가 아니라 공정별로 나눠야 한다.

6. 자동화 후보 공정

AI와 자동화의 효과가 비교적 큰 영역은 반복성, 형식화 가능성, 입력·출력 구조가 명확한 공정이다.

예를 들면 다음과 같다.

이 영역에서 AI는 사람의 반복 작업을 줄이고, 리드타임을 단축하며, 결과 형식을 표준화할 수 있다.

하지만 여기서 중요한 것은 AI가 최종 보안 판단을 한다는 뜻이 아니다.

AI는 반복 가능한 초안을 만들고, 사람은 그것을 검증한다.

7. 사람 판단이 남는 공정

반대로 다음 영역은 사람 판단이 계속 필요하다.

• 인증·인가 구조 검토
• 비즈니스 로직 취약점 판단
• 동시성 이슈 검토
• 실제 악용 가능성 검증
• 서비스 특성 기반 위험도 조정
• 고위험 예외 승인
• 운영 영향도 판단
• 침투테스트 성격의 수동 검증
• 최종 보안 판단과 책임 승인

이 영역은 단순 탐지보다 맥락 판단과 책임이 중요하다.

예를 들어 같은 인증 누락처럼 보여도 실제 위험도는 다를 수 있다. 외부 노출 API인지, 내부 관리망 API인지, 앞단 gateway가 강제되는지, 우회 경로가 있는지, 호출 결과가 단순 조회인지 상태 변경인지에 따라 판단이 달라진다.

AI는 이 판단을 보조할 수 있다. 그러나 최종 책임을 질 수는 없다.

그림. AI는 탐지, 요약, 중복 제거, 초안 작성 같은 반복 공정을 맡을 수 있지만, 맥락 판단과 위험 승인 책임은 사람에게 남는다.

결국 사람의 역할은 사라지는 것이 아니라 이동한다.

반복 점검 수행자
→ 진단 시스템 설계자
→ 결과 품질 검증자
→ 예외 승인자
→ 위험 판단 책임자

8. Tool을 AI로 대체하는 것이 아니다

AI 보안진단 논의에서 또 하나의 오해가 있다.

기존 보안 도구를 AI로 대체할 수 있느냐는 질문이다.

현실적인 방향은 대체가 아니라 결합이다.

SAST, DAST, SCA, ASM, API Discovery 같은 기존 도구는 여전히 중요하다. 이 도구들은 탐지 정확도와 검증 신뢰도의 기반을 제공한다.

AI는 이 도구들의 결과를 통합하고, 중복을 줄이고, 맥락을 붙이고, 반복 공정을 자동화하는 역할을 맡는 것이 더 현실적이다.

기존 Tool → 탐지와 증거 제공
AI → 통합, 요약, 분류, 초안, 반복 작업 자동화
사람 → 맥락 판단, 예외 승인, 악용 가능성 검증, 품질 통제

따라서 향후 보안진단 구조는 “Tool을 AI로 대체”하는 형태가 아니라 “Tool + AI + 사람 검증”이 결합된 구조로 봐야 한다.

9. 개발 프로세스 안으로 들어가야 한다

보안진단이 계속 별도 이벤트로만 존재하면 한계가 있다.

개발이 빨라질수록 별도 이벤트 방식은 점점 늦어진다.

앞으로의 보안진단은 개발 프로세스 안에 들어가야 한다.

바람직한 구조는 다음과 같다.

1. 개발 agent 또는 개발 파이프라인 안에 보안 skill을 삽입한다.
2. 반복 가능한 보안 점검은 CI/CD gate에서 자동 수행한다.
3. AI는 정적 분석 결과, OSS 결과, API 정보, 아키텍처 정보, 이슈 이력을 함께 참고한다.
4. 사람은 고위험 판단, 예외 승인, 실제 악용 가능성 검증, 품질 통제를 담당한다.
5. 비용은 구독료가 아니라 공정별 실행 비용으로 측정한다.
6. 결과는 리드타임, 품질, 재검증 비용, 개발팀 수용도 기준으로 평가한다.

장기적으로는 SAST, DAST, SCA, API Discovery, ASM, 아키텍처 분석, AI 분석을 결합한 Security Testing as Code 체계로 확장하는 것이 타당하다.

여기서 중요한 것은 “자동화”보다 “내재화”다.

보안진단을 외부에서 한 번 수행하는 활동이 아니라, 개발 과정 안에서 반복 실행되는 통제로 만드는 것이다.

10. 파일럿은 ROI를 증명하기보다 측정 구조를 만든다

현재 단계에서 바로 ROI를 확정하는 것은 위험하다. AI 사용량, 사람 검토 비율, 품질 저하 여부, 개발팀 수용도, 재검증 비용이 아직 충분히 측정되지 않았기 때문이다.

따라서 첫 번째 파일럿의 목표는 “AI가 싸다”를 증명하는 것이 아니라, 비교 가능한 측정 구조를 만드는 것이다. 최소한 다음 항목은 함께 봐야 한다.

지금 필요한 것은 결론이 아니라 측정이다. 파일럿은 ROI를 확정하는 자리가 아니라, 어떤 공정이 자동화되고 어떤 판단이 사람에게 남는지 확인하는 실험이어야 한다.

11. 이번 단계에서 결정할 것과 미룰 것

AI 보안진단 논의에서 가장 위험한 것은 너무 빨리 결론을 내리는 것이다.

이번 단계에서 결정할 것은 자동화 후보 공정, 효과 판단 지표, 파일럿 범위와 기준이다.

반대로 AI 도입 확정, 외주 절감액, 인력 감축, 특정 솔루션 선택, 전체 보안진단 무인화, ROI 확정은 뒤로 미뤄야 한다. 이 항목들은 파일럿 데이터가 나온 뒤 판단해야 한다.

12. 결론: 보안진단은 시스템이 된다

AI 시대의 보안진단은 단순히 도구를 하나 더 사는 문제가 아니다.

개발 속도와 공격 속도가 동시에 빨라지는 상황에서, 방어자가 반복 가능한 검증 구조를 갖출 수 있는가의 문제다.

최종 목표는 진단 인력이 계속 건별 수작업을 반복하는 조직이 아니다.

최종 목표는 보안진단 기능이 개발 프로세스 안에 재사용 가능한 통제로 내재화된 조직이다.

사람은 반복 점검을 직접 수행하기보다, 시스템이 놓친 영역의 판단, 검증, 예외 승인, 구조 개선에 집중해야 한다.

이 방향은 결국 내가 이전 글에서 다룬 Security Testing as Code와 만난다.

보안은 더 이상 마지막에 검사하는 활동이 아니다.

코드와 파이프라인, 공급망과 배포 경로 안에 반복 가능한 형태로 들어가야 한다.

이 글의 산출물은 보안진단을 하나의 외주 업무가 아니라 자동화 후보 공정, 사람 판단 공정, 비용 측정 공정으로 나눠 개발 프로세스 안에 배치하는 모델이다.

AI는 그 전환을 가능하게 하는 도구다. 하지만 전환의 책임은 여전히 인간에게 있다.

현실적으로는 세 단계부터 시작하면 된다.

1. 지금의 보안진단 공정을 자산 식별, 정적 점검, 동적 점검, 리포트 작성, 이행확인, 재검증처럼 작은 공정으로 쪼갠다.
2. 각 공정을 자동화 후보, 사람 판단 영역, 승인 책임 영역으로 나눈다.
3. 한 서비스나 한 팀을 대상으로 파일럿을 돌려 리드타임, 오탐 처리 시간, 사람 검토 비율, 개발팀 수용도를 측정한다.

이 세 단계가 있어야 “AI 보안진단을 도입할 것인가”라는 막연한 질문이 “어떤 공정을 어떤 품질 기준으로 반복 실행할 것인가”라는 운영 질문으로 바뀐다.

여기서 글을 닫으면 결론은 단순하다. AI 보안진단의 목적은 사람을 줄이는 것이 아니라, 보안진단을 매번 새로 시작하지 않게 만드는 것이다. 반복 가능한 공정은 시스템에 넣고, 맥락 판단과 책임 승인은 사람에게 남겨야 한다. 그래야 보안진단은 외주 이벤트가 아니라 개발 속도 안에서 계속 작동하는 검증 체계가 된다.

FAQ

Q1. AI 보안진단은 인력 감축을 의미하나?

아니다. 핵심은 사람을 없애는 것이 아니라 반복 공정을 시스템화하는 것이다. 사람의 역할은 직접 점검 반복에서 구조 검토, 예외 승인, 실제 악용 가능성 검증, 품질 통제로 이동한다.

Q2. AI가 보안진단 전체를 대체할 수 있나?

일부 공정은 자동화할 수 있지만 전체를 대체하기는 어렵다. 자산 식별, 정적 분석 결과 요약, 리포트 초안, Jira 등록 초안은 자동화 후보가 될 수 있다. 반면 인증·인가 구조 검토, 비즈니스 로직 판단, 실제 악용 가능성 검증은 사람 판단이 필요하다.

Q3. ROI는 바로 계산할 수 있나?

바로 계산하기 어렵다. AI 사용량, 사람 검토 비율, 오탐 처리 시간, 재검증 시간, 개발팀 수용도, 결과 품질을 파일럿으로 측정한 뒤 판단해야 한다.

다음 편: 공급망 보안은 SBOM만으로 끝나지 않는다: AI 개발 도구와 자동화 연결 관리