대화 기억이 코드 감시자로 변했다: LLM 메모리와 정적 분석의 만남

LLM의 기억 기능은 단순한 대화 저장소를 넘어 코드 분석에도 쓰이고 있습니다. 이전에 분석한 내용과 함수 사이의 관계를 기억해 두면 수십만 줄짜리 프로그램에서도 데이터가 들어오는 곳부터 흘러가는 곳까지 추적할 수 있기 때문입니다. 다만 최근 30일 동안 새롭게 확인된 커뮤니티 논의가 없어, 이번 글에서는 공개적으로 알려진 정적 분석 원리와 LLM 메모리의 결합 가능성을 중심으로 살펴보겠습니다.

LLM의 기억은 채팅 기록과 다릅니다

대화형 AI의 메모리는 보통 사용자의 선호나 이전 질문을 저장하는 기능으로 알려져 있습니다. 하지만 프로그램을 분석할 때는 기억해야 할 대상이 다릅니다.

사용자 입력을 받는 함수가 있다고 가정해 보겠습니다. 이 값이 데이터베이스 쿼리까지 전달되면 SQL 인젝션 위험이 생길 수 있습니다. 분석기는 입력값이 지나간 변수와 함수, 조건문을 순서대로 기록해야 합니다.

이때 핵심이 되는 개념은 데이터 흐름입니다. 데이터가 만들어진 곳에서 실제로 쓰이는 곳까지 어떤 경로로 움직이는지 살펴보는 방식입니다. 외부 입력처럼 위험할 수 있는 값을 따로 표시해 추적하는 기법은 오염 분석, 영어로는 타인트 분석이라고 부릅니다.

기존 정적 분석기는 미리 정해진 규칙에 따라 이 경로를 계산합니다. LLM 메모리는 여기에 코드의 의미와 이전 분석에서 얻은 맥락을 보탭니다. 함수 이름이 같더라도 프로젝트마다 맡은 역할이 다를 수 있다는 점을 기억해 두는 것입니다.

코드를 읽는 LLM에서 프로그램을 추적하는 LLM으로

LLM에 코드 한 파일을 보여주고 취약점을 찾아달라고 하면 그럴듯한 답을 곧잘 내놓습니다. 문제는 그 파일 밖에 있는 정보입니다. 실제 서비스에서는 취약점이 여러 모듈과 호출 단계를 거쳐 드러나는 경우가 많습니다.

예를 들면 이런 흐름입니다.

HTTP 요청 → 입력 정제 함수 → 서비스 로직 → 쿼리 생성기 → 데이터베이스

입력 정제 함수만 떼어 보면 안전해 보일 수 있습니다. 하지만 특정 조건에서 정제 과정을 건너뛴다면 이야기가 달라집니다. LLM은 각 단계를 따로 요약하는 데 그치지 않고, 어떤 조건에서 어느 경로가 열리는지 연결해서 봐야 합니다.

이럴 때 메모리는 일종의 분석 장부가 됩니다. 이미 확인한 함수의 역할과 호출 관계, 검증을 마친 조건, 아직 풀지 못한 의문을 구조화해 저장합니다. 새 파일을 읽을 때마다 이 장부를 갱신하면 입력 길이에 한계가 있어도 큰 코드베이스를 단계적으로 분석할 수 있습니다.

LLM의 역할이 코드를 “읽는” 데서 그치지 않고 프로그램의 상태와 관계를 “추적하는” 단계로 넘어가는 셈입니다.

정적 분석의 그래프가 LLM의 장기 기억이 됩니다

정적 분석기는 코드를 여러 종류의 그래프로 바꿉니다. 함수 호출 관계는 호출 그래프로, 실행 순서는 제어 흐름 그래프로, 변수 사이의 이동은 데이터 흐름 그래프로 나타냅니다.

LLM 메모리는 이런 그래프에서 지금 필요한 부분을 찾아오는 검색 계층으로 활용할 수 있습니다. 분석할 함수와 관계있는 노드만 불러오면 전체 저장소를 매번 프롬프트에 넣지 않아도 됩니다.

취약점 탐지는 크게 3단계로 나눌 수 있습니다.

1. 외부 입력이나 파일처럼 데이터가 처음 들어오는 지점을 찾습니다.
2. 그 값이 어떤 함수와 조건문을 거쳐 이동하는지 따라갑니다.
3. 데이터베이스 실행이나 시스템 명령처럼 위험한 도착점에 닿는지 확인합니다.

전통적인 분석기는 이 과정을 빠르고 일관되게 처리합니다. 다만 낯선 프레임워크나 프로젝트에서만 쓰는 래퍼 함수는 놓칠 수 있습니다. LLM은 함수 이름과 주석, 주변 코드를 보고 의미를 짐작해 이런 빈틈을 메울 수 있습니다.

둘은 경쟁하기보다 일을 나눠 맡는 관계에 가깝습니다. 정적 분석기는 경로를 계산하고, LLM은 그 경로의 의미와 우선순위를 설명합니다. 메모리는 두 작업의 결과가 끊어지지 않도록 이어줍니다.

가장 큰 위험은 그럴듯하게 틀리는 분석입니다

LLM이 코드를 이해하더라도 계산 결과가 늘 정확한 것은 아닙니다. 존재하지 않는 호출 관계를 만들어내거나, 실제로 가능한 실행 경로를 불가능하다고 판단할 수 있습니다. 보안 분석에서는 이런 오류 하나만으로도 취약점을 놓칠 수 있습니다.

저장한 기억이 오래되면 문제는 더 커집니다. 함수가 수정됐는데도 이전 요약을 계속 사용하면 분석 전체가 잘못된 전제 위에 놓입니다. 코드의 커밋이나 파일 해시를 분석 결과와 연결하고, 변경된 부분에 해당하는 기억만 무효화하는 장치가 필요한 이유입니다.

무엇을 메모리에 저장할지도 따져봐야 합니다. 소스 코드와 분석 기록에는 인증 로직이나 내부 시스템 구조가 담길 수 있습니다. 저장 범위와 보존 기간, 접근 권한을 정하지 않은 채 장기 기억을 도입하면 분석의 편의성이 오히려 새로운 정보 유출 경로를 만들 수 있습니다.

따라서 최종 판단에는 확인할 수 있는 근거가 따라야 합니다. 의심스러운 코드 위치와 호출 경로, 위험한 입력이 통과한 조건을 함께 보여줘야 합니다. “취약해 보입니다”라는 설명만으로는 정적 분석기라고 부르기 어렵습니다.

당장은 탐정이 아니라 유능한 조사관에 가깝습니다

LLM 메모리와 정적 분석을 결합하면 대규모 코드베이스를 이해하는 데 드는 비용을 낮출 가능성이 큽니다. 특히 분석 결과를 쌓아 두고 변경된 코드만 다시 살피는 방식은 보안 검토와 코드 리뷰에 실용적입니다.

하지만 LLM이 설명을 잘한다는 이유로 프로그램 분석도 정확하다고 여겨서는 안 됩니다. 앞으로의 경쟁력은 얼마나 오래 기억하느냐보다, 그 기억을 코드 근거와 얼마나 제대로 연결하는지, 잘못됐을 때 즉시 폐기할 수 있는지에 따라 갈릴 것입니다. 코드 리뷰 AI가 내놓은 한 줄의 경고를 그대로 믿기보다, 그 경고가 따라온 전체 경로부터 확인해야 합니다.