AI 코딩 사고 실증 — 운영에 박히는 7가지 패턴

AI 코딩 도구가 만든 코드는 빠르고 예쁜데, 같은 결함을 반복해서 만든다.

SENTRIX 레드팀이 최근 12개월간 SaaS·B2B 서비스를 진단하면서 7개 패턴이 반복적으로 운영에 박힌 채 살아남는 걸 확인했다.

이 글은 도구 비방이 아니다.

"AI가 만든 코드"는 잘못이 아니지만, "검증 없이 운영에 올린 AI 코드"는 사고로 직결된다.

보안담당자·시니어 개발자가 코드 리뷰에서 우선적으로 봐야 할 7가지를 실증 사례 기반으로 정리한다.

한눈에 보는 7가지 패턴

Q. AI 코딩 사고가 일반 코드 사고와 무엇이 다른가요?

A. 결함의 종류는 같지만 분포와 빈도가 다릅니다. AI는 같은 안전한 패턴을 반복하는 만큼, 같은 위험한 패턴도 반복합니다. 결과적으로 동일 결함이 코드베이스 전체에 균일하게 퍼지는 경향이 있습니다.

Q. 어떤 도구가 더 위험한가요?

A. 도구 자체보다 검증 단계 유무가 더 큰 변수입니다. 사람이 PR 리뷰·정적 분석·동적 점검을 거친 코드와, AI 출력 그대로 머지된 코드는 사고율이 크게 다릅니다.

Q. AI 코드를 빠르게 검증하는 방법이 있나요?

A. 외부 노출 자산 자동 스캔 + 핵심 라우터 수동 리뷰 + 정적 분석 3단을 결합하면 가장 효율적입니다. 외부 자동 스캔은 [CodeScan 무료 스캔](https://codescan.kr)으로 30초에 1차 점검할 수 있습니다.

패턴 1 — SQL 파라미터 처리 누락

AI는 ORM 쿼리는 안전하게 짠다.

문제는 검색 필터·정렬·로우레벨 raw query다. 사용자 입력을 그대로 문자열에 끼워 넣는 패턴이 반복적으로 발견된다.

# 위험한 패턴 (AI가 자주 만들어내는 형태)
order = request.GET.get('order', 'created_at')
queryset = Item.objects.raw(f"SELECT * FROM items ORDER BY {order}")

# 안전한 패턴
ALLOWED = {'created_at', 'price', 'name'}
order = request.GET.get('order', 'created_at')
if order not in ALLOWED:
    order = 'created_at'
queryset = Item.objects.order_by(order)

점검 포인트: raw(, extra(, executescript(, f-string SQL 검색

패턴 2 — 인증 있는데 권한 검증 없는 라우터 (IDOR)

/orders/1234를 /orders/1235로 바꾸면 다른 사람 주문이 보이는 패턴.

AI는 "로그인 필요" 데코레이터는 잘 붙이지만, "이 사용자가 이 리소스의 소유자인가" 검증은 빠뜨린다.

• 점검 포인트: 모든 pk/id/uuid 파라미터 라우터에 소유자 매칭 로직이 있는가
• 빠른 진단: 자동 스캔으로 잘 안 잡힌다. 수동 진단 필수.

패턴 3 — 약한 JWT 시크릿·기본값 미변경

AI 템플릿 코드는 종종 secret_key = "your-secret-key-here" 같은 자리표시자를 그대로 둔다.

배포 후에도 이 값이 살아 있으면 토큰 위조가 가능하다.

• 점검 포인트: 코드베이스에서 your-secret, change-me, default-secret, placeholder 검색
• 환경변수 미설정 시 fallback 값이 무엇인지 확인 (없거나 명시적 에러여야 안전)

패턴 4 — 취약 버전 의존성 픽스 누락

AI는 학습 시점 기준으로 자주 쓰이던 버전을 추천한다.

그 사이 CVE가 발표된 버전이 그대로 운영에 들어가는 경우가 흔하다.

• 점검 포인트: requirements.txt/package.json/go.mod의 핀 버전을 CVE 데이터베이스와 매칭
• 자동화: GitHub Dependabot, pip-audit, npm audit, osv-scanner

패턴 5 — 사용자 입력 검증 부재 (XSS·서버 측 검증 누락)

클라이언트 검증만 있고 서버 측 검증이 없는 패턴.

프론트가 React라서 XSS 방어된다는 오해도 흔하다.

• 점검 포인트: 사용자 입력을 DB 저장 → 다른 사용자에게 노출하는 경로 (게시글·댓글·프로필)
• 서버 측 escape, Content Security Policy 헤더, dangerouslySetInnerHTML 사용 위치 추적

패턴 6 — .env git 히스토리 시크릿 유출

가장 자주 발견되고 가장 빠르게 악용된다.

실수로 한 번 커밋된 .env는 .gitignore에 다시 추가해도 히스토리에 영구 박힌다.

• 점검 포인트: git log --all --full-history -- .env, trufflehog/gitleaks 스캔
• 발견 시: BFG/git filter-repo로 히스토리 삭제 + 강제 푸시 + 유출된 모든 키 즉시 회전

키 회전 없이 히스토리만 정리하면 사고는 그대로 진행 중인 상태다.

패턴 7 — Rate Limit 부재 → 자격증명 스터핑·DoS

AI가 만든 로그인 라우터에 시도 횟수 제한이 없는 경우가 표준이다시피 하다.

미토스급 자동 공격 환경에서는 이 결함 하나로 계정 다수가 며칠 내 탈취된다.

• 점검 포인트: 로그인·OTP·비밀번호 재설정·결제 라우터에 IP 또는 계정 단위 Rate Limit
• 권장: Django django-axes, FastAPI slowapi, 클라우드 측 WAF Rate Limit

7가지를 한 번에 잡는 운영 체크리스트

자동화로 4개, 수동으로 3개. 둘 다 없으면 절반만 본 셈이다.

SENTRIX 진단에서 실제로 본 분포

레드팀이 12개월간 진단한 SaaS·웹서비스 58건 기준 발견 분포다.

7개 중 0개가 발견된 진단은 0건이었다. AI 코딩 도입 여부와 무관하게, 어떤 코드베이스든 1개 이상은 박혀 있었다.

오늘 시작할 5단계

1. [ ] git log -p -S 'SECRET\|API_KEY\|PASSWORD' 또는 gitleaks 1회 스캔
2. [ ] 로그인·결제·OTP 라우터에 Rate Limit 적용 여부 확인
3. [ ] 모든 id/pk 파라미터 라우터에 소유자 매칭 로직 명시
4. [ ] pip-audit 또는 npm audit 결과 high 이상 0건 유지
5. [ ] CodeScan 30초 무료 스캔으로 외부 노출 자산·헤더·민감 파일 1차 점검

SENTRIX의 AI 코딩 진단 패키지

• AI 코딩 보안 진단 — 위 7개 패턴을 자동 + 수동 + 동적으로 결합 진단. PoC + 우선순위 개선 리포트
• AI 레드티밍 — 공격자가 AI 자동화로 같은 코드를 어디까지 뚫는지 실제 시나리오로 검증

가격·범위는 기업 보안 진단 페이지 참고.

다음에 해야 할 한 가지

AI 코딩으로 빨리 만든 만큼, 검증도 빠르게 시작해야 한다.

• 👉 개발자: CodeScan 30초 무료 스캔 — 위 7개 중 4개를 자동 검출
• 👉 임원·CISO: 30분 1:1 보안 진단 신청 — 자동으로 안 잡히는 IDOR·입력 검증·시크릿 회전 우선순위 진단

관련 글
- AI 미토스 취약점, 1시간 자가점검 가이드 [2026]
- CISO를 위한 침해사고 1시간 골든타임 액션북 [2026]