AI 코딩 에이전트가 수상한 코드를 분석했지만 취약점을 발견하지 못했다면, 그 결과는 “문제없음”일까요?
보안 실무에서는 그렇지 않습니다. 특히 Linux kernel처럼 복잡한 코드베이스에서는 취약점이 없어서 놓친 것인지, 분석 절차가 부족해서 놓친 것인지 구분해야 합니다. SKILL-SIF(Self-improving Security Skill Framework)는 바로 이 지점에서 출발합니다. AI의 실패를 분석 종료 신호가 아니라, 다음 Software Security 감사를 더 정교하게 만드는 학습 데이터로 활용합니다.
기존 AI 보안 분석은 대체로 다음과 같은 흐름에 머물렀습니다.
코드 입력 → AI 분석 → 취약점 후보 보고 → 종료
하지만 이 방식에는 중요한 공백이 있습니다. AI가 어떤 취약점을 놓쳤는지, 왜 놓쳤는지, 다음 분석에서 같은 실수를 피하려면 어떤 절차를 추가해야 하는지가 체계적으로 남지 않습니다. 결과적으로 에이전트는 매번 비슷한 실수를 반복할 수 있습니다.
SKILL-SIF는 이 흐름을 실패 기반의 개선 루프로 바꿉니다.
보안 분석 skill 적용
↓
AI 코딩 에이전트의 취약점 분석
↓
정답과 비교해 누락·오탐·오분류 확인
↓
실패 원인 분류
↓
분석 절차와 검증 규칙 보강
↓
새로운 취약점에서 재평가
핵심은 모델을 다시 학습시키는 데 있지 않습니다. SKILL-SIF는 모델의 가중치를 바꾸는 fine-tuning 대신, 에이전트가 따르는 보안 분석 절차 자체, 즉 security skill을 개선합니다.
예를 들어 AI가 use-after-free 취약점을 놓쳤다면 단순히 “메모리 안전성을 더 주의하라”는 지시를 추가하는 방식이 아닙니다. 다음과 같은 구체적 절차를 skill에 반영할 수 있습니다.
- 객체 해제 이후 실행될 수 있는 callback 경로를 반드시 추적한다.
- reference count 감소와 lock 해제 순서를 함께 검토한다.
- 정상 경로뿐 아니라 error path와 cleanup path를 별도로 확인한다.
- 취약점 후보를 찾은 뒤, 반대로 안전성을 증명하려는 반증 단계를 수행한다.
- 함수 수준의 의심만 보고하지 않고, 실제 문제가 발생하는 statement까지 특정한다.
이 차이는 매우 중요합니다. “이 파일에 메모리 문제가 있을 수 있다”는 답변은 보안 감사에서 실무 가치가 제한적입니다. 반면 특정 함수의 특정 포인터 역참조가 해제된 객체에 접근하며, 어떤 비동기 경로에서 그 상태가 만들어지는지 설명할 수 있어야 검증과 수정이 가능합니다.
연구 결과도 이 접근의 필요성을 보여줍니다. 37개의 공개 보안 skill과 여러 LLM 구성을 사용해 실제 Linux kernel 취약점 100개를 평가한 총 14,800회 실험에서, 취약 함수·정확한 취약 statement·취약점 유형을 모두 맞힌 완전 탐지율은 11.1%에 그쳤습니다. AI가 보안 개념을 알고 있다는 사실만으로는 실제 코드에서 정확한 결함 위치와 원인을 짚어내기 어렵다는 뜻입니다.
반대로 실패 패턴을 바탕으로 상위 skill을 개선한 뒤, 기존 개선 과정에 사용하지 않은 취약점 100개에서 재평가했을 때 완전 탐지율은 2%에서 16%로 높아졌습니다. 절대 수치만 보면 아직 갈 길이 멉니다. 그러나 실패를 기록하고 절차를 개선하는 구조가 일반화 성능을 최대 8배까지 끌어올릴 수 있다는 점은 Software Security 자동화에 중요한 메시지를 던집니다.
결국 SKILL-SIF가 제안하는 관점은 단순합니다.
AI가 취약점을 놓친 순간은 감사의 실패가 아니라, 다음 감사가 더 나아질 수 있는 가장 구체적인 출발점이다.
이 접근은 AI를 독립적인 보안 판단자로 만들기보다, 실패를 축적하며 점차 정교해지는 보안 분석 인프라로 바라봅니다. 그리고 그 변화는 “더 강한 모델”만 기다리는 것보다, 오늘의 보안 감사 프로세스를 더 신뢰할 수 있게 만드는 현실적인 방법이 될 수 있습니다.
Software Security: ‘취약점이 있다’만으로는 부족하다
“이 파일은 위험해 보입니다”라는 답변은 얼핏 유용해 보입니다. 하지만 실제 Software Security 감사에서는 출발점일 뿐입니다. 보안 담당자가 수정 여부를 판단하고, 재현 테스트를 만들고, 패치를 검증하려면 AI는 훨씬 더 구체적인 답을 제시해야 합니다.
- 어느 함수가 취약한가
- 정확히 어떤 코드 구문(statement)이 문제인가
- 취약점 유형은 무엇인가
- 어떤 입력·제어 흐름으로 문제가 발생하는가
- 실제로 악용 가능한 조건이 충족되는가
예를 들어 AI가 “메모리 안전성 문제가 있을 수 있다”고 말하는 것과, foo() 함수의 특정 포인터 역참조가 이미 해제된 객체를 참조하는 use-after-free라고 지목하는 것은 전혀 다른 수준의 결과입니다. 후자는 개발자와 보안 연구자가 즉시 검증할 수 있는 증거가 되지만, 전자는 넓은 범위의 수작업 조사를 남깁니다.
SKILL-SIF 연구진은 이 차이를 엄격한 기준으로 측정했습니다. 평가에서 정답으로 인정받으려면 단순히 취약점 존재를 언급하는 수준을 넘어, 취약 함수·정확한 취약 구문·취약점 class를 모두 맞혀야 했습니다.
그 결과는 냉정했습니다. 공개된 보안 skill 37개를 실제 Linux kernel 취약점 100개에 적용하고, Claude Code와 4개 기반 LLM으로 총 14,800회 실행한 결과, 완전 정확 탐지율은 11.1%에 그쳤습니다.
| 판정 수준 | 실무적 의미 |
|---|---|
| 파일 또는 모듈 지목 | 조사 범위를 좁히는 단서 |
| 함수 지목 | 코드 리뷰의 시작점 |
| 코드 구문 지목 | 재현·수정 가능한 기술적 근거 |
| 함수·구문·유형을 모두 정확히 지목 | 신뢰할 수 있는 취약점 보고에 가까운 결과 |
이 수치는 LLM 기반 보안 도구가 무가치하다는 뜻이 아닙니다. 오히려 평가 기준을 낮추면 “발견했다”는 인상은 쉽게 만들 수 있다는 점을 보여줍니다. 그러나 Software Security 현장에서는 모호한 경고보다 검증 가능한 위치와 원인이 중요합니다.
특히 Linux kernel처럼 함수 호출 관계, 예외 처리 경로, 동시성 조건이 복잡한 코드베이스에서는 문제를 찾는 것만으로 충분하지 않습니다. AI가 정확한 statement를 특정하지 못하면, 분석자는 넓은 코드 범위를 다시 추적해야 합니다. 취약점 유형까지 잘못 분류하면 우선순위 판단, 패치 전략, 회귀 테스트 설계도 모두 흔들릴 수 있습니다.
그래서 SKILL-SIF의 핵심은 탐지 건수를 부풀리는 데 있지 않습니다. “무엇을 놓쳤는지, 왜 틀렸는지”를 기록하고 다음 분석 절차에 반영하는 것입니다. 보안 감사에서 중요한 것은 위험 신호를 많이 내는 AI가 아니라, 사람이 검증하고 조치할 수 있는 정확한 근거를 점점 더 잘 제시하는 AI입니다.
실패를 skill로 되돌리는 Software Security 피드백 루프
AI 에이전트가 취약점을 놓쳤을 때 가장 쉬운 대응은 정답을 보여주고 “다음에는 더 잘 찾아라”라고 지시하는 것이다. 하지만 이 방식은 재현성이 낮습니다. 왜 놓쳤는지, 어느 단계에서 분석이 끊겼는지, 어떤 검증 규칙이 부재했는지를 남기지 않으면 다음 감사에서도 비슷한 실패가 반복됩니다.
SKILL-SIF의 핵심은 바로 이 지점에 있습니다. 에이전트의 실패를 단순한 오답으로 처리하지 않고, 재사용 가능한 Software Security 절차를 개선할 근거로 분해합니다.
정답 비교가 아니라 실패 원인을 분류한다
취약점 분석 결과는 보통 “발견” 또는 “미발견”으로만 평가되기 쉽습니다. 그러나 실제 보안 감사에서는 실패의 형태가 서로 다릅니다.
예를 들어 에이전트가 특정 Linux kernel 취약점을 분석했을 때 다음과 같은 상황이 발생할 수 있습니다.
- 취약 함수는 찾았지만 실제 문제가 되는 statement를 잘못 지목했다.
- 위험한 포인터 사용을 발견했지만 use-after-free가 아닌 null dereference로 분류했다.
- 입력 함수는 확인했지만 error path 또는 callback 경로를 따라가지 못했다.
- race condition 후보를 제시했지만, 필요한 lock 해제와 재진입 조건을 검증하지 않았다.
- 취약점은 언급했지만 실제로 도달 가능한 실행 경로와 영향을 제시하지 못했다.
SKILL-SIF는 이런 결과를 하나의 “실패”로 뭉뚱그리지 않습니다. 대신 정답 데이터와 비교해 함수 위치, 정확한 취약 statement, 취약점 class 가운데 무엇이 틀렸는지를 구분합니다.
| 실패 유형 | 의미 | skill에 반영할 개선 방향 |
|---|---|---|
| 함수 누락 | 분석 범위 자체가 잘못됨 | 진입점·호출 그래프·관련 서브시스템 탐색 강화 |
| statement 오판 | 위험은 감지했지만 정확한 지점을 못 찾음 | 데이터 흐름, 수명, 조건문, error path 검증 추가 |
| class 오분류 | 코드 증상은 봤지만 원인을 잘못 해석함 | 취약점 유형별 판별 기준과 반증 규칙 보강 |
| 경로 누락 | 특정 분기·callback·동시성 조건을 놓침 | control-flow 및 interleaving 점검 절차 추가 |
| 근거 부족 | 후보는 제시했지만 재현·영향을 뒷받침하지 못함 | 입력 경로, 전제조건, 영향 증명 형식 강제 |
이 분해 과정은 중요합니다. “더 신중하게 분석하라”는 지시는 추상적이지만, “reference count가 감소한 뒤 callback이 실행되는 모든 경로에서 객체 수명을 재검증하라”는 규칙은 다음 분석에도 적용할 수 있기 때문입니다.
실패는 절차적 지식으로 변환된다
SKILL-SIF는 모델 가중치를 다시 학습시키는 방식이 아닙니다. 대신 에이전트가 따르는 security skill, 즉 분석 순서·검증 항목·출력 형식을 개선합니다.
기본 흐름은 다음과 같습니다.
초기 security skill 실행
↓
취약점 후보와 분석 근거 생성
↓
정답과 비교해 누락·오판 지점 식별
↓
실패 패턴을 일반화 가능한 규칙으로 변환
↓
skill의 탐색 순서·검증 단계·반증 규칙 수정
↓
미관측 취약점으로 재평가
여기서 핵심은 실패 사례를 그대로 프롬프트에 누적하지 않는다는 점입니다. 사례를 계속 나열하면 context window를 소모하고, 특정 benchmark에만 맞춘 과적합된 지침이 될 수 있습니다. 따라서 실패는 가능한 한 일반화된 행동 규칙으로 바뀌어야 합니다.
가령 특정 결함에서 에이전트가 해제된 객체를 다시 참조하는 callback 경로를 놓쳤다면, 개선된 skill은 다음과 같은 형태를 가질 수 있습니다.
객체 해제 또는 참조 카운트 감소가 발생한 뒤에는, 등록된 callback·workqueue·timer·deferred execution 경로를 확인한다. 각 경로에서 객체가 재참조되기 전 수명 보장 수단(reference count, lock, cancellation, ownership transfer)이 존재하는지 검증한다.
이 규칙은 하나의 CVE만을 설명하지 않습니다. 비동기 실행과 객체 수명 관리가 결합된 다양한 메모리 안전성 문제에 적용할 수 있습니다.
개선된 skill은 탐색·검증·반증을 함께 강화한다
좋은 Software Security skill은 단순 체크리스트가 아닙니다. SKILL-SIF 관점에서 skill은 최소한 세 가지 층으로 구성됩니다.
탐색 규칙
어디부터 살펴볼지 결정합니다. 입력 경계, 권한 경계, 메모리 소유권 변경, lock 획득·해제, error path, 비동기 callback 등이 대상입니다.검증 규칙
의심스러운 코드가 실제 취약점 조건을 만족하는지 확인합니다. 예를 들어 use-after-free라면 해제, 재참조, 수명 보장 부재라는 조건이 모두 확인돼야 합니다.반증 규칙
에이전트 자신이 만든 후보를 다시 의심하게 합니다. lock이 실제로 전 경로를 보호하는지, 참조 카운트가 유지되는지, 입력이 해당 코드까지 도달 가능한지 확인하는 단계입니다.
이 구조가 없으면 에이전트는 위험해 보이는 코드를 빠르게 많이 제시할 수는 있어도, 실무자가 검토 가능한 수준의 결과를 만들기 어렵습니다. 반대로 탐색과 반증이 결합되면 후보 수는 줄어들 수 있지만, 각 보고서의 증거 밀도는 높아집니다.
“다음 분석”에서 통하는지 별도로 검증한다
실패 기반 개선의 가장 큰 함정은 과거 문제만 잘 푸는 skill을 만드는 것입니다. 특정 취약점의 함수명, 패치 구조, 코드 관례를 지나치게 반영하면 benchmark 성능은 올라가도 새로운 코드베이스에서는 도움이 되지 않을 수 있습니다.
그래서 SKILL-SIF는 skill 개선에 사용하지 않은 미관측 취약점으로 다시 성능을 평가합니다. 연구에서는 상위 5개 skill을 개선한 뒤, 별도의 취약점 100개에서 완전 탐지율이 2%에서 16%로 상승했습니다. 완전 탐지는 취약 함수, 정확한 statement, 취약점 유형을 모두 맞힌 경우만 인정하는 엄격한 기준입니다.
다만 16%는 자동화된 보안 감사를 단독으로 운영하기에 충분한 수치가 아닙니다. 이 결과가 보여주는 가치는 “AI가 보안 전문가를 대체한다”는 데 있지 않습니다. 실패를 수집하고, 원인을 구조화하고, 검증 절차에 반영하는 루프가 AI 에이전트의 보안 분석 품질을 실제로 높일 수 있다는 데 있습니다.
결국 SKILL-SIF의 기술적 차별점은 정답을 더 많이 주입하는 데 있지 않습니다. 실패를 분석 가능한 데이터로 만들고, 그 데이터를 다음 감사에 재사용할 수 있는 보안 절차로 바꾸는 것입니다.
Software Security 성과 분석: 2%에서 16%로, 숫자가 말하지 않는 것
미관측 Linux kernel 취약점에서 완전 탐지율이 2%에서 16%로 상승했습니다. 최대 8배 개선이라는 결과는 분명 인상적입니다. 특히 이미 알려진 취약점이나 학습에 사용된 사례가 아니라, skill 개선 과정에서 보지 않은 취약점 100개를 대상으로 얻은 결과라는 점에서 의미가 있습니다.
하지만 Software Security 관점에서 더 중요한 질문은 남습니다.
16%를 찾았다는 사실보다, 왜 나머지 84%를 놓쳤는가?
“완전 탐지”의 기준은 생각보다 엄격하다
이 연구에서 탐지 성공은 단순히 “이 코드에 문제가 있어 보인다”는 수준이 아닙니다. 다음 세 가지를 모두 정확히 맞혀야 합니다.
- 취약점이 있는 함수
- 문제가 발생하는 정확한 statement 또는 코드 위치
- 취약점의 유형(vulnerability class)
예를 들어 에이전트가 use-after-free 가능성이 있는 파일을 찾아도, 실제 취약 함수가 다르거나 정확한 dereference 지점을 특정하지 못하면 완전 탐지로 인정되지 않습니다. 실무 보안 감사에서 이는 합리적인 기준입니다. 개발자와 보안 담당자가 조치하려면 “위험해 보인다”가 아니라 어디서, 어떤 조건으로, 왜 위험한지가 필요하기 때문입니다.
| 지표 | 개선 전 | SKILL-SIF 적용 후 | 의미 |
|---|---|---|---|
| 미관측 취약점 완전 탐지율 | 2% | 16% | 최대 8배 개선 |
| 4개 LLM 종합 accuracy | 6.05% | 11.20% | 약 1.85배 개선 |
| 미완전 또는 미탐지 비율 | 98% | 84% | 여전히 큰 검증 공백 |
이 숫자는 SKILL-SIF가 효과 없다는 뜻이 아닙니다. 오히려 절차를 개선하는 것만으로 일반화 성능을 의미 있게 올릴 수 있다는 신호입니다. 다만 이를 곧바로 “AI가 kernel 보안 감사를 자동화했다”는 결론으로 확대해서는 안 됩니다.
8배 개선은 출발점이 낮았다는 뜻이기도 하다
2%에서 16%로의 상승은 상대 개선율로 보면 매우 큽니다. 그러나 절대 수치로 보면 100개의 취약점 중 완전히 정확히 찾아낸 사례가 약 2개에서 16개로 늘어난 것입니다.
보안 운영에서는 상대 개선율과 절대 성능을 분리해서 봐야 합니다.
- 연구 성과로서의 의미: 실패 피드백을 skill에 반영하면 탐지 절차가 실제로 개선된다.
- 운영 도구로서의 의미: 여전히 AI 결과만으로 취약점 부재를 선언할 수는 없다.
- 보안 책임 관점의 의미: 탐지하지 못한 84% 안에 고위험 권한 상승, 메모리 손상, race condition이 포함될 수 있다.
특히 Linux kernel처럼 권한 경계와 메모리 안전성이 핵심인 환경에서는 false negative의 비용이 큽니다. 하나의 누락이 시스템 전체의 신뢰 경계를 무너뜨릴 수 있기 때문입니다.
나머지 84%가 남기는 기술적 질문
미탐지는 단일 원인으로 설명되지 않습니다. LLM coding agent는 코드 문맥을 이해할 수 있어도, 실제 취약점 분석에는 여러 종류의 추론이 동시에 요구됩니다.
- 여러 함수와 callback을 넘나드는 제어 흐름 추적
- reference count, lock, 객체 상태를 따라가는 데이터 흐름 분석
- 오류 처리와 예외 경로를 포함하는 error path 검증
- 여러 스레드 실행 순서를 가정하는 race condition 추론
- 패치 이전 코드와 이후 코드를 비교하는 취약 경로 재구성
- 위험한 코드 패턴과 실제 공격 가능성을 구분하는 exploitability 판단
따라서 SKILL-SIF의 성과는 “프롬프트를 더 길게 쓰면 된다”는 메시지가 아닙니다. 핵심은 에이전트가 실패한 이유를 구조적으로 남기고, 다음 실행에서 분석 순서·검증 조건·반증 절차를 바꾸도록 만드는 데 있습니다.
예를 들어 어떤 agent가 반복적으로 error path를 놓친다면, skill에는 단순히 “오류 처리를 확인하라”는 문장보다 더 구체적인 절차가 필요합니다.
- 리소스 획득 이후의 모든 반환 경로를 열거한다.
- 각 반환 경로에서 해제·참조 카운트·lock 상태를 기록한다.
- 정상 경로와 오류 경로의 상태 전이를 비교한다.
- 해제 후 접근, 이중 해제, unlock 누락 여부를 반증한다.
이런 절차적 보강이 바로 실패 기반 skill 진화의 실질적인 가치입니다.
Software Security에서 숫자를 읽는 올바른 방식
SKILL-SIF의 16%는 낮은 최종점이 아니라, 개선 가능한 시스템의 중간 측정값으로 보는 편이 적절합니다. 기존 보안 skill을 그대로 적용했을 때보다 성능이 올랐고, 그 개선이 미관측 취약점에서도 확인됐다는 점은 중요합니다.
그러나 안전한 도입 방식은 명확합니다. AI가 탐지한 결과를 보안 검토의 우선순위 큐로 사용하되, AI가 찾지 못한 영역을 안전하다고 간주해서는 안 됩니다. SAST, fuzzing, symbolic execution, 회귀 테스트, 그리고 사람의 코드 리뷰가 계속 필요한 이유입니다.
결국 이 8배 개선이 보여주는 것은 AI가 보안 전문가를 대체했다는 사실이 아닙니다. 실패를 기록하고 검증 절차를 개선하는 Software Security 체계가, 단발성 AI 분석보다 훨씬 강력할 수 있다는 사실입니다.
Software Security: 자동 보안 감사의 미래는 ‘혼자 하는 AI’가 아니다
취약점을 더 잘 찾는 AI 에이전트가 등장했다고 해서, 그 에이전트에게 곧바로 코드 수정과 배포 권한까지 맡겨도 될까요?
답은 아직 아니오에 가깝습니다. 취약점 탐지는 보안 업무의 시작일 뿐입니다. 후보 취약점이 실제로 악용 가능한지, 수정안이 기존 기능을 깨뜨리지 않는지, 패치가 새로운 권한 상승이나 우회 경로를 만들지 않는지까지 검증해야 합니다.
SKILL-SIF의 현실적인 가치는 완전 자동화가 아니라, AI가 실패한 경험을 기록하고 다음 감사 절차를 더 정교하게 만드는 데 있습니다. 즉, 핵심은 “더 똑똑한 단일 에이전트”가 아니라 실패를 학습하는 다층 검증 체계입니다.
탐지와 수정은 분리해야 한다
AI가 취약점을 발견한 뒤 직접 패치를 생성하면 속도는 빨라질 수 있습니다. 하지만 보안에서는 속도보다 검증 가능성이 중요합니다.
예를 들어 에이전트가 use-after-free 가능성을 보고하며 참조 카운트 처리 코드를 수정했다고 가정해 보겠습니다. 이 변경은 문제를 막을 수도 있지만, 동시에 다음과 같은 부작용을 만들 수 있습니다.
- 객체 해제가 지연되어 메모리 누수가 발생
- lock 획득 순서가 바뀌어 deadlock 유발
- 예외 경로에서 자원이 해제되지 않음
- 성능 최적화 경로가 무력화됨
- 기존 테스트가 다루지 못한 경쟁 조건이 새로 생성됨
따라서 안전한 Software Security 운영에서는 역할을 분리하는 편이 바람직합니다.
- 탐지 에이전트가 취약점 후보와 근거를 제출합니다.
- 검증 에이전트가 반증 가능한 경로와 오탐 가능성을 찾습니다.
- SAST, fuzzing, 테스트 도구가 코드와 실행 결과를 독립적으로 확인합니다.
- 보안 담당자와 개발자가 영향도와 수정 방향을 최종 결정합니다.
- 승인된 패치만 제한된 환경에서 검증한 뒤 배포합니다.
이 구조에서 AI는 보안 전문가를 대체하는 자동 해커가 아니라, 반복적인 조사와 증거 수집을 가속하는 분석 파트너가 됩니다.
중요한 것은 “정답”보다 실패 기록이다
SKILL-SIF는 에이전트가 무엇을 맞혔는지뿐 아니라, 무엇을 놓쳤는지를 자산으로 만듭니다. 이 차이는 큽니다.
단순한 보안 프롬프트는 “입력 검증을 확인하라”, “메모리 수명을 추적하라”는 지침을 제공합니다. 반면 실패 기반 접근은 실제 감사 결과를 바탕으로 더 구체적인 질문을 추가합니다.
- 어떤 error path를 추적하지 않아 취약점을 놓쳤는가?
- 함수는 찾았지만 정확한 취약 statement를 왜 특정하지 못했는가?
- race condition의 어떤 interleaving을 고려하지 않았는가?
- 패치 이후 코드만 보고, 취약했던 이전 실행 경로를 재구성하지 못했는가?
- 위험한 코드 패턴을 실제 exploitability와 혼동했는가?
이런 실패 기록은 다음 분석의 체크리스트가 됩니다. 다만 무작정 지침을 누적해서는 안 됩니다. skill이 지나치게 길어지면 분석 비용이 증가하고, 서로 충돌하는 규칙이 생기며, 특정 benchmark에만 맞춘 과적합이 발생할 수 있습니다.
그래서 skill도 코드처럼 관리해야 합니다.
버전 관리하고, 변경 이력을 남기고, 회귀 테스트와 미관측 테스트 세트로 검증해야 합니다.
자동화의 목표는 무인 배포가 아니라 검증 가능한 속도다
현실적인 자동 보안 감사 파이프라인은 다음과 같은 형태에 가깝습니다.
저장소 및 아키텍처 분석
↓
신뢰 경계·입력 경로 식별
↓
AI 에이전트의 취약점 후보 탐색
↓
증거 기반 보고서 생성
↓
독립 에이전트의 반증 및 재검토
↓
SAST · fuzzing · 테스트 결과 결합
↓
보안 담당자 승인
↓
제한된 범위의 패치 적용 및 재검증
여기서 각 취약점 보고서는 단순한 경고가 아니라 최소한 다음 정보를 포함해야 합니다.
- 취약 함수와 정확한 코드 위치
- 취약점 유형과 예상 영향
- 입력 또는 공격 표면에서 해당 코드까지의 경로
- 재현 조건 또는 반증 가능한 가설
- 관련 로그, 정적 분석 결과, 테스트 근거
- 수정 시 예상되는 부작용과 검증 항목
이처럼 증거를 구조화하면 사람이 AI 결과를 빠르게 검토할 수 있고, 오탐을 줄이며, 향후 skill 개선에도 필요한 데이터를 확보할 수 있습니다.
SKILL-SIF가 보여주는 방향은 명확합니다. 자동 보안 감사의 미래는 한 명의 강력한 AI가 모든 판단과 배포를 수행하는 모습이 아닙니다. AI의 탐색 능력, 기존 보안 도구의 재현성, 그리고 사람의 맥락 판단이 실패 데이터를 중심으로 연결되는 운영 체계가 더 안전하고 실용적인 미래에 가깝습니다.
