Yoo HeehyeonYoo Heehyeon

SecOps에서 가장 소모적인 일 중 하나가 트리아지다. 쏟아지는 경고를 사람이 하나씩 선별해야 하기 때문이다. 최근에는 LLM이 이 영역에 많이 들어오고 있지만, 환각이라는 치명적인 문제도 같이 안고 있다. 그래서 여기서는 LLM을 자동 판단자가 아니라, 통제된 보조 도구로 쓰는 관점이 중요하다.

1. 가능성: 문맥 이해와 오탐 제거

기존 룰 기반 도구는 문맥 이해가 약하다. 변수명이 password라는 이유만으로 단순 출력문까지 경고를 띄우는 식이다. 반면 LLM은 코드 흐름을 읽고 의도를 해석하는 데 강점이 있다.

• 이것이 사용자 입력을 받는 곳인가, 아니면 단순 로그 출력인가?
• 이 변수가 검증 함수를 거쳐서 사용되는가?

이 문맥 이해 능력 덕분에 LLM은 기존 도구의 오탐을 줄이는 2차 필터로 쓸 수 있다. 또 "왜 위험한지", "어떻게 고칠지"를 개발자 눈높이로 풀어서 설명하는 데도 강하다.

2. 한계: 확률적 앵무새의 거짓말

문제는 LLM이 본질적으로 확률 모델이라는 점이다. 보안에서는 이 성질이 그대로 리스크가 된다.

• 최신성 부족: 학습에 없는 최신 취약점은 모를 수 있다.
• 비결정성: 같은 질문에도 답이 조금씩 달라져 진단 일관성이 흔들린다.
• 환각: 없는 라이브러리를 추천하거나, 안전하지 않은 코드를 안전하다고 판단할 수 있다.

3. 통제: 프롬프트 엔지니어링

그래서 LLM을 보안에 쓰려면 반드시 통제 장치가 필요하다. 핵심 수단은 프롬프트 설계다. 창의적으로 답하게 두는 순간, 보안 진단은 불안정해진다.

3.1. RAG(Retrieval-Augmented Generation)

LLM의 기억을 믿기보다, 독해력만 빌려 쓰는 쪽이 안전하다. 최신 CVE나 사내 보안 규정을 컨텍스트로 넣고, 그 자료만 근거로 답하게 제한해야 한다. 근거가 없으면 모른다고 답하게 만드는 편이 낫다.

3.2. 역할 부여와 제약(Role & Constraints)

행동 범위를 좁히는 것도 중요하다. 보안 진단에서는 창의성보다 일관성과 제약이 더 중요하다.

• Role: 너는 리눅스 커널 보안 전문가다.
• Constraint: 기능 변경 없이 오직 보안 취약점만 패치하라.
• Format: 설명은 제외하고 코드 블록만 출력하라.

3.3. 생각의 사슬(CoT: Chain of Thought)

"안전한가"를 바로 묻기보다, 단계별로 따져보게 만드는 편이 정확도가 높다.

1. 코드 기능을 파악한다.
2. 입력값 출처를 확인한다.
3. 검증 로직이 있는지 본다.
4. 그다음 결론을 낸다.

이 순서를 강제하면 논리적 비약을 줄이기 쉽다.

LLM은 최종 판단자가 되면 안 된다. 1차 분석과 설명을 보조하는 도구로는 유용하지만, 최종 결정은 사람이 맡아야 한다.