왜 AI 생성 코드는 위험한가 — 스캐너를 만들며 목격한 현실

이 기사에서 전하고 싶은 것

AI (Copilot, Cursor, Claude, ChatGPT)가 내뱉는 코드는 빠르다. 하지만 그 속도와 맞바꾸어, 아무도 리뷰하지 않은 채 운영 환경(Production)으로 흘러 들어가는 코드가 늘어나고 있다.

나는 보안 스캐너(Security Scanner)를 만드는 과정에서 AI가 작성한 코드를 낱낱이 스캔해 왔다. 그곳에서 본 것은 상상보다 훨씬 나빴다. 이 기사는 그때 무엇을 보았고, 왜 전용 도구가 필요하다고 판단했는지에 대한 경험의 공유다.

각 취약점의 탐지 로직이나 수정 방법에 대한 상세한 설명은 여기에서 다루지 않겠다. 우선은 "왜 위험한가"를 가능한 한 생생하게 쓰고자 한다.

계기: "거의 모든 샘플에 열쇠가 꽂혀 있다"

처음으로 손이 멈춘 것은 API 호출 샘플을 낱낱이 스캔하고 있었을 때였다.

AI에게 "이 API를 사용하는 코드를 작성해줘"라고 부탁하면, 대개 동작하는 코드가 돌아온다. 문제는 그중 상당수가 다음과 같은 형태를 띠고 있다는 점이다.

• API 키나 토큰이 코드에 직접 작성(Hard-coded)되어 있다
• 사용자 입력을 거의 그대로 쉘 커맨드(Shell Command)로 전달한다
• "동작하지 않으니 고쳐줘"라고 하면, SSL 인증서 검증을 무효화한다
• 에러를 묵인한다. 빈 catch 문이 도처에 깔려 있다

예를 들어, "이 API를 호출하는 샘플을 작성해줘"에 대한 응답이 다음과 같은 몇 줄이었던 적이 있다 (키 값은 가려둠).

API_KEY = "sk-************************"
resp = requests.post(url, data=payload, verify=False) # 인증서 체크를 무효화

단 두 줄에 직접 작성된 키와 SSL 검증 무효화가 공존하고 있다. 이런 코드가 쌓이면 스캐너를 돌렸을 때 DANGEROUS나 CRITICAL이 수없이 나열된다. "동작하는 샘플"의 얼굴을 하고 이런 코드가 양산되고 있다.

하나하나를 뜯어보면 경험자라면 "해서는 안 될" 패턴이라는 것을 알고 있다. 하지만 문제는 양이었다. AI는 똑같은 실수를 인간보다 훨씬 빠르게, 대량으로 생산한다. 게다가 아주 그럴듯한 태세로 말이다.

"동작했다"라는 사실이 위험을 보이지 않게 만든다. 이것이 AI 생성 코드의 가장 무서운 점이라는 것을 이때 뼈저리게 느꼈다.

왜 기존 도구만으로는 부족한가

"그렇다면 Snyk나 SonarQube를 사용하면 되지 않을까"라고 생각할지도 모른다. 실제로 이들은 뛰어난 도구이며, 나 또한 존경한다.

다만, 이들은 기본적으로 "인간이 작성하는 코드"를 전제로 설계되어 있다. 인간은 적어도 자신이 작성한 행의 의도를 기억한다. 리뷰도 한다. 반면 AI 생성 코드는,

• 작성한 본인(=AI)에게 의도가 없다
• 받은 사람도 내용을 읽지 않고 복사해서 붙여넣기(Copy-paste)하는 경우가 많다
• "그럴듯함"이 위험한 코드일수록 높다

라는, 완전히 다른 생태계를 가지고 있다. 따라서 AI 특유의 패턴——대량 생성, 무비판적 복사 붙여넣기, 자신만만한 오류——에 초점을 맞춘 관점이 한 단계 더 필요하다. 이 격차가 전용 도구를 만드는 이유가 되었다.

"그럴듯하지만 틀렸다"가 가장 무섭다

AI의 출력은 틀렸을 때일수록 자신만만해 보인다. 이는 보안상 치명적인 성질이다.

예를 들어, 인증 관련 코드를 요청하면 토큰 검증을 스킵한 "동작하는 코드"가 돌아올 때가 있다. 테스트는 통과한다. 데모도 돌아간다. 그래서 리뷰의 눈을 피한다. 문제가 표면화되는 것은 운영 환경에서 누군가에게 악용된 후다.

내가 정적 분석 (Static Analysis, 패턴 기반 검사)에 집착한 것도 여기에 이유가 있다. 처음에는 LLM에게 코드를 분석하게 하는 방향도 시도했다. 하지만 같은 코드를 5번 스캔했는데, 5번 모두 다른 점수가 돌아왔다. 판정이 흔들리는 보안 도구는 CI(지속적 통합)에도 컴플라이언스(Compliance)에도 사용할 수 없다. "그럴듯하지만 안정적이지 않다"는 AI의 약점은 검사하는 입장이 되어도 마찬가지였다.

결국, 동일한 입력에는 항상 동일한 결과를 반환하는——결정적인 정적 분석에 집중하기로 했다. 수수하지만 도구로서는 이것이 정답이었다.

이것은 "이론상의 위험"이 아니다

AI 생성 코드의 리스크는 교과서 속 이야기가 아니다. AI나 확장 기능의 배포 경로를 타고 이미 현실의 공격으로 보고되고 있다. 수법의 "형태"로서 몇 가지를 꼽아보겠다.

• 대량의 사칭 배포: 인기 도구의 이름을 아주 미세하게 바꾼 가짜를 대량으로 공개한다. 설치하면 외부 C2 (Command and Control, 원격 제어) 서버로 연결된다. 목표는 "정품과 구별할 수 없는 이름"으로 신뢰 속에 숨어드는 것이다.
• 자산 탈취: "편리해 보이는 이름"으로 배포되어 지갑 정보나 인증 정보를 빼낸다. 혹은 머신의 리소스를 마음대로 마이닝 (Mining)에 사용한다.
• 저장할 때마다 발화하는 랜섬웨어 (Ransomware): 도구의 훅 (Hook, 저장 시 등에 실행되는 처리)에 암호화 로직을 심어두어, 파일을 쓸 때마다 인질로 잡는다.

공통점은 "편리해 보인다", "정품 같다"라는 외형적 신뢰를 악용하고 있다는 점이다. AI나 배포 에코시스템 (Ecosystem)은 그 신뢰를 양산해 버릴 수 있다. 그렇기에 받는 쪽에서 기계적으로 체크할 수 있는 수단을 갖춰두는 것이 가치 있다.

우선 자신의 코드를 측정해 보기

이론을 읽는 것보다, 한 번 자신의 코드를 스캔해 보는 것이 빠르다. 무료 커맨드 라인 도구 (CLI Tool)를 준비했다. 설치가 필요 없는 (Node.js 18+) 방식으로 시도할 수 있다.

npx -y github:ayame0328/codeheal-scan ./src

14개 카테고리, 93개 규칙의 패턴으로 하드코딩된 시크릿 (Secret), 셸 인젝션 (Shell Injection), 외부 전송, 파괴적인 파일 조작 등을 찾아낸다. LLM을 사용하지 않으므로, 동일한 코드에는 항상 동일한 결과가 반환된다. 검출된 해당 행을 그대로 표시하므로, 실제 키를 포함한 코드를 테스트할 때는 출력 대상에 주의해 주길 바란다.

"생각보다 빨갛다"라고 느낀다면, 그것이 다음 단계로 나아갈 이유가 된다.

향후 (유료 가이드 · 곧 공개 예정)에서 다룰 내용

이 기사는 "왜 위험한가"까지를 다룬다. 후속 내용은 직접 손을 움직여 "어떻게 고치는가"로 파고드는 실전 가이드로 정리되어 있다 (곧 공개 예정).

• AI 생성 코드에서 나타나기 쉬운 취약성을 14개 카테고리로 분류하여 "왜 위험한가 $\rightarrow$ 어떻게 고치는가"를 구체적인 사례와 함께
• 검출 결과의 "중요도"와 "신뢰도"를 어떻게 측정할 것인가 (오탐 (False Positive)에 휘둘리지 않는 리스크를 보는 법)
• 실제로 존재했던 멀웨어 (Malware) 캠페인의 케이스 스터디와, 거기서 얻을 수 있는 방어의 교훈
• LLM을 사용하지 않고, 동일한 입력에 동일한 결과를 반환하는 정적 스캐너 (Static Scanner)를 어떻게 설계했는가
• 개인 개발의 지식을 어떻게 상품 (도구)으로 변환했는가

공개 알림은 프로필을 통해 받을 수 있다.

우선 위의 CLI로 자신의 리포지토리 (Repository)를 한 번 돌려보길 바란다. 다음 이야기는 그 "빨간색"을 하나씩 지워나가는 이야기가 될 것이다.

Discussion