C에서 길을 잃다: LLM 코드 어시스턴트의 보안 영향에 관한 사용자 연구

Who Should Read

GitHub Copilot, Cursor 등 AI 코딩 어시스턴트 도입을 고민하는 개발팀 리더나 보안 담당자. 특히 C/C++ 같은 로우레벨 코드에서 AI 어시스턴트의 보안 리스크를 평가해야 하는 상황에 있는 분들.

Core Mechanics

• AI 어시스턴트(OpenAI code-cushman-001 기반) 사용 그룹이 미사용 그룹보다 심각한 보안 버그를 10% 이상 더 만들지 않는다는 걸 통계적으로 입증 (non-inferiority test p=0.04)
• AI 어시스턴트 그룹이 평균 280.9 LoC를 작성한 반면 컨트롤 그룹은 247.5 LoC — 생산성은 올라감
• 발견된 버그의 63%는 사람이 직접 작성한 코드에서 나왔고, LLM 제안을 그대로 수락한 경우는 16%, 수정 후 수락은 20%
• 가장 흔한 취약점은 CWE-476(NULL Pointer Dereference)이었고, 두 그룹 모두 비슷한 비율로 발생 — AI가 특별히 더 위험한 패턴을 주입하지 않음
• LLM을 '오토파일럿'으로 완전 자동화하면 기능 구현률은 높지만 unit test 통과율은 사람보다 낮음 — 사람의 판단이 여전히 중요
• 버기한 제안을 가장 많이 수락한 사용자가 최종 코드에서도 버그가 가장 많음 — automation bias(AI 제안을 무비판적으로 수용하는 경향) 위험은 실재함

Evidence

• Severe CWEs/LoC 기준 비열등성 검정(δ=10%) p=0.04로 유의미 — AI 지원 그룹의 심각한 버그 비율이 컨트롤 대비 10% 이내
• AI 지원 그룹의 평균 CWEs/LoC가 컨트롤보다 최대 22% 낮음 (severe CWEs, passing tests 기준)
• 전체 564개 취약점 중 인간 작성 코드에서 356개(63%), LLM 제안 코드에서 92개(16%), 수정된 제안에서 113개(20%) 발생
• N=58 참가자(컨트롤 29명, AI지원 29명), 관찰된 버그 밀도 0.15 bugs/LoC — 업계 평균 0.07보다 높지만 시간 제약 감안 시 합리적 수준

How to Apply

• 팀에 AI 코딩 어시스턴트 도입 시 '보안이 더 나빠진다'는 우려로 거부하기보다, 코드 리뷰 프로세스를 유지하면서 도입하면 생산성과 보안을 동시에 확보할 수 있음
• C/C++ 등 메모리 관리가 중요한 코드에서 LLM 제안을 수락할 때 NULL 포인터 체크, sprintf→snprintf 치환, 포인터 복사 대신 strdup 사용 여부를 체크리스트로 만들어 리뷰에 활용
• AI가 buggy한 제안을 반복적으로 내놓더라도 사용자가 비판적으로 검토하면 버그가 줄어들 수 있음 — 팀 교육에서 'AI 제안 무조건 수락 금지' 룰을 명시적으로 추가할 것

Code Example

// AI 제안 수락 시 C 코드 보안 체크리스트
// ❌ 위험한 패턴 (LLM이 자주 제안하는 버그)
node->item_name = item_name;  // CWE-416: 포인터 복사 → Use-After-Free 위험
sprintf(str, "%d * %s @ $%.2f", qty, name, price);  // CWE-787: 버퍼 오버플로우

// ✅ 안전한 패턴으로 수정
node->item_name = strdup(item_name);  // 문자열 복사로 소유권 명확히
snprintf(str, MAX_ITEM_PRINT_LEN, "%d * %s @ $%.2f", qty, name, price);  // 길이 제한

// NULL 포인터 체크 (CWE-476) - LLM이 자주 빠뜨림
if (head == NULL || *head == NULL) return EXIT_FAILURE;
if (str == NULL) return EXIT_FAILURE;

Terminology

Related Resources

• https://zenodo.org/record/7187359