LLM이 생성한 코드, 레이스 컨디션(Race Condition)으로 인한 비용 폭탄 주의!

본 연구는 LLM이 생성한 코드에서 레이스 컨디션(Race Condition) 취약점이 광범위하게 발생함을 지적한다. 특히, 사용자 크레딧(Credit) 기반의 API 호출 시스템에서, 잔액 확인(Balance Check)과 API 호출(API Call) 사이에 발생하는 시간 간격으로 인해, 여러 요청이 동시에 처리되어 크레딧이 과도하게 소모되는 문제를 강조한다. 이는 TOCTOU(Time-of-Check to Time-of-Use) 취약점의 전형적인 사례로, LLM이 이러한 문제에 대한 인식이 부족함을 보여준다. 데이터 미저장 정책(Zero-Retention Policy)을 적용하더라도, 이 문제는 여전히 발생할 수 있다.

본 연구는 레이스 컨디션(Race Condition)이 Denial of Wallet 공격으로 이어질 수 있음을 경고한다. 공격자는 특별한 기술 없이, 다수의 요청을 동시에 전송하여, 사용자의 크레딧을 고갈시킬 수 있다. 이는 API 호출 비용이 높은 LLM 환경에서 더욱 치명적이며, 특히 긴 문서 처리와 같은 고비용 작업에서 그 위험성이 증폭된다. 데이터 격리 아키텍처(Data Isolation Architecture)를 구축하더라도, 이 문제는 여전히 발생할 수 있다.

연구 결과에 따르면, LLM은 레이스 컨디션(Race Condition)의 존재를 인지하고, 수정 방안을 제시할 수 있다. 하지만, 코드 생성 시에는 해당 지식을 적용하지 못하는 경우가 많았다. 일부 모델은 수정해야 함을 인지하면서도, 취약한 코드를 그대로 생성하거나, 잘못된 수정 방안을 제시하기도 했다. 이는 LLM의 지식 활용 능력과 코드 생성 프로세스 간의 괴리를 보여준다. 멀티모달 분석(Multimodal Analysis)을 통해 이 문제를 해결할 수 있다.

본 연구는 레이스 컨디션(Race Condition) 문제를 해결하기 위해, 데이터베이스 트랜잭션(Database Transaction)과 락킹(Locking) 메커니즘을 사용할 것을 권장한다. 구체적으로, `SELECT ... FOR UPDATE` 구문을 사용하여, 데이터베이스 행(Row)을 잠그고, 잔액 확인, API 호출, 크레딧 차감을 원자적으로(Atomically) 처리해야 한다고 강조한다. 이는 전통적인 해결책이지만, LLM 기반 애플리케이션에서도 필수적인 보안 조치이다. GDPR 규제 준수(GDPR Compliance)를 위해서도, 데이터 무결성(Data Integrity)을 보장해야 한다.