🤖 LLM SAST vs DAST: 코드를 '읽는' AI와 '두드리는' AI, 무엇이 다른가?

정적이냐 동적이냐, 그것이 문제로다
— 그리고 LLM이 그 답을 다시 쓰고 있다.

🎯 이 글에서 다루는 것

• SAST와 DAST의 본질적 차이를 5분 만에 정리
• LLM이 두 진영에 가져온 게임체인저 변화
• LLM SAST와 LLM DAST의 강점·한계 비교
• 실무 도입 시 마주칠 함정과 비용 구조
• DevSecOps 파이프라인에 녹이는 단계별 가이드

📌 도입: 보안 테스팅, 다시 뜨거워진 이유

요즘 코드는 사람보다 빠르게 만들어진다. Copilot, Cursor, Claude Code 같은 AI 도우미가 매일 수만 줄을 토해내고, 개발자는 검토할 새도 없이 PR을 머지한다. 문제는 — 그렇게 빠르게 늘어난 코드가 빠르게 안전해지지는 않는다는 것이다.

 

전통적인 SAST와 DAST는 이 시대의 속도를 따라가기 버겁다. 룰 기반 스캐너는 false positive(오탐)를 폭탄처럼 쏟아내고, 개발자는 결국 알람 자체를 무시하게 된다. 이걸 업계에서는 alert fatigue라 부른다. "양치기 소년이 너무 많이 외치면 늑대가 와도 안 믿는다"는 그 현상이다.

 

여기에 LLM이라는 변수가 끼어들었다. 코드의 의미를 이해하는 AI가 등장하면서, 보안 테스팅의 지형이 다시 흔들리고 있다.

🔍 SAST와 DAST, 무엇이 다른가?

먼저 기본기부터 짚고 가자.

SAST (Static Application Security Testing)

• 한 줄 요약: "코드를 펼쳐놓고 읽는다"
• 분석 대상: 소스코드, 바이트코드, 바이너리
• 시점: 빌드 단계 (실행하지 않음)
• 시야: 화이트박스 — 내부 구조를 안다
• 잡는 것: SQL Injection 패턴, 하드코딩된 비밀번호, 안전하지 않은 함수 호출, 데이터 흐름 취약점

DAST (Dynamic Application Security Testing)

• 한 줄 요약: "앱을 실제로 두드려본다"
• 분석 대상: 실행 중인 애플리케이션 (HTTP 요청·응답)
• 시점: 스테이징 또는 운영 환경
• 시야: 블랙박스 — 내부를 모른 채 외부에서 공격
• 잡는 것: 인증·인가 우회, 세션 관리 결함, 서버 설정 오류, 실제로 터지는 XSS

쉬운 비유로 정리하면 이렇다.

SAST는 건물 도면을 펼쳐놓고 "이 벽 너무 얇네, 무너질 위험이 있어"라고 짚어내는 건축 검토관이다.
DAST는 실제 건물에 망치를 들고 가서 "여기 진짜 무너지네"를 확인하는 안전 점검관이다.

 

둘 다 필요하다. 도면만 봐서는 시공의 부실을 못 잡고, 두드려만 봐서는 설계의 결함을 못 잡는다.

🧠 LLM이 가져온 변화: 패턴 매칭에서 의미 이해로

전통 SAST의 고질병

기존 SAST 도구의 핵심은 결국 패턴 매칭이다. AST(추상 구문 트리)를 파싱해서 미리 정의된 규칙에 매칭한다. 그래서 한계가 분명하다.

• 컨텍스트를 모른다 → "이 입력값은 이미 저 위 미들웨어에서 검증됐어"를 인지 못한다
• 의도를 모른다 → 안전한 코드를 위험하다고 우긴다
• 결과는? false positive 폭주, 개발자 신뢰 상실

전통 DAST의 고질병

DAST는 정해진 페이로드를 기계적으로 던진다. SQL Injection 페이로드 1번부터 100번까지, XSS 페이로드 1번부터 50번까지... 그래서 다음을 못 잡는다.

• 비즈니스 로직 결함: "포인트 1만 사용 → 환불 시 1만 5천 환불" 같은 논리 결함은 그냥 통과
• 다단계 시나리오: 로그인 → 주문 → 결제 흐름의 미묘한 결함을 추적 못함
• 워크플로우 이해 부재: 그냥 단발성 페이로드만 던지고 끝

LLM이 들어왔을 때

LLM은 코드와 HTTP 트래픽을 언어로 본다. 패턴이 아니라 의미를. 그래서 두 진영 모두에 큰 변화가 일어났다.

 

LLM SAST 진영의 변화

• 데이터 흐름 추적 시 의미를 이해 → "이 변수는 사용자 입력이고, 검증 없이 SQL에 들어간다"를 자연어로 추론
• 자동 수정 코드 제안 — 단순 경고가 아니라 "이렇게 고치면 됩니다"의 PR을 자동 생성
• 취약점 설명을 자연어로 → 주니어 개발자도 즉시 이해
• 대표 도구: GitHub Copilot Autofix, Snyk DeepCode AI, Amazon CodeGuru Security, Checkmarx One AI Security Champion

LLM DAST 진영의 변화

• 페이로드를 LLM이 상황에 맞게 생성 → 응답을 보고 다음 공격을 조정
• 비즈니스 로직 취약점 탐지 → 다단계 시나리오 자동 생성
• 응답을 의미적으로 해석 → "에러 메시지에 DB 스택트레이스가 노출됐다"를 LLM이 인지
• 대표 도구: PortSwigger Burp Suite AI, ZAP AI, StackHawk AI

💻 같은 취약점, 다른 시선

같은 SQL Injection을 두 진영이 어떻게 다르게 보는지 살펴보자.

# 취약한 코드
def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    return db.execute(query)

 

LLM SAST의 시선

"user_id가 함수 파라미터로 들어와서, 검증이나 이스케이프 없이 f-string으로 SQL 쿼리에 직접 삽입됩니다. 이는 SQL Injection 취약점이며, 파라미터화 쿼리(prepared statement)로 변경해야 합니다. 다음과 같이 수정하세요."

# 자동 제안된 패치
def get_user(user_id):
    query = "SELECT * FROM users WHERE id = %s"
    return db.execute(query, (user_id,))

 

LLM DAST의 시선

1. /users?id=1 요청 → 정상 응답 확인
2. /users?id=1' OR '1'='1 요청 → 모든 사용자 데이터 응답 확인
3. 응답에서 PostgreSQL 에러 메시지 노출 발견
4. 추가 페이로드로 데이터 추출 가능성 확인 → 취약점 확정 보고

같은 결론에 다른 길로 도착한다. 그래서 둘은 보완재다. SAST는 "왜 위험한가"를, DAST는 "정말 터지는가"를 증명한다.

⚠️ LLM 보안 테스팅의 함정 구간

빛이 있으면 그림자가 있다. LLM 기반 보안 테스팅에도 조심할 부분들이 분명히 있다.

1. Hallucination 위험

LLM은 그럴듯한 거짓말을 한다. 존재하지 않는 함수를 "여기서 호출되고 있다"고 우길 수 있고, 실제로 안전한 코드를 취약하다고 보고할 수 있다. 검증 없이 신뢰하면 안 된다.

2. False Negative 함정

오히려 더 위험한 건 false negative(미탐)다. LLM이 "이 코드는 안전합니다"라고 단언했는데 실제로는 취약했다면? false positive 1만 개보다 false negative 1개가 치명적이다.

3. 코드 외부 유출 리스크

SaaS형 LLM SAST를 쓰면 사내 소스코드가 외부 LLM API로 전송된다. 금융권, 공공기관, 군 환경에서는 이게 곧 컴플라이언스 위반이다. 온프레미스 LLM(자체 호스팅된 오픈소스 모델 등) 옵션을 반드시 검토해야 한다.

4. 비용과 응답 시간

모든 PR마다 LLM SAST를 돌리면 토큰 비용이 빠르게 누적된다. 또한 LLM 응답 시간 때문에 CI 파이프라인이 느려질 수 있다. 어느 단계에 어느 깊이로 적용할지 설계가 필요하다.

5. 프롬프트 인젝션 — 새로운 공격면

LLM DAST가 페이로드를 생성한다는 건, 거꾸로 LLM 자체가 공격 대상이 될 수도 있다는 뜻이다. 분석 대상 앱이 LLM과 연동돼 있다면, 보안 스캐너의 LLM이 거꾸로 조종당하는 시나리오까지 고려해야 한다.

🛠️ DevSecOps 파이프라인에 녹이는 5단계

이상적인 적용 단계는 이렇게 설계할 수 있다.

1. IDE 단계 — 가벼운 LLM SAST 보조. 개발자 코딩 중 실시간 힌트
2. PR 단계 — 정밀 LLM SAST. 변경된 파일 위주, 자동 수정 PR 생성
3. 빌드 단계 — 전통 SAST + LLM SAST 병행. 속도와 정확도의 균형
4. 스테이징 단계 — LLM DAST 실행. 시나리오 기반, 비즈니스 로직 점검
5. 운영 단계 — 가벼운 DAST 모니터링 + RASP(Runtime Application Self-Protection)

핵심은 "어디에 무엇을 둘 것인가"다. 모든 단계에 모든 도구를 넣으면 비용도, 알람 피로도도 감당이 안 된다.

 

✅ 정리: 경쟁이 아니라 듀엣이다

LLM SAST와 LLM DAST는 서로 대체재가 아니다. 같은 문제를 다른 각도에서 보는 듀엣 파트너다. 코드를 읽는 시선과 코드를 두드리는 시선이 만나야 진짜 보안 테스팅이 완성된다.

LLM은 두 진영 모두를 "패턴 매칭"에서 "의미 이해"로 끌어올렸다. 그러나 LLM도 만능이 아니며, 인간 보안 엔지니어의 검증과 조합될 때 가장 강력하다.

다음 단계로 학습할 만한 키워드를 던져둔다.

• IAST (Interactive Application Security Testing) — SAST와 DAST의 하이브리드
• SCA (Software Composition Analysis) — 오픈소스 의존성 취약점
• RASP (Runtime Application Self-Protection) — 운영 단계 자체 방어
• AI Red Teaming — LLM 자체에 대한 보안 테스팅

---