AI 코딩 에이전트가 생성한 코드를 그대로 프로덕션에 올리고 있다면, 지금 당장 세 가지를 점검해야 한다. CORS 설정, ARIA 속성, 그리고 배포 이후의 플랫폼 심사. 이 세 가지는 서로 달라 보이지만 하나의 공통된 실패 패턴을 가리킨다. AI는 '동작하는 코드'를 빠르게 만들어주지만, '올바른 맥락의 코드'를 보장하지는 않는다는 것.
첫 번째 함정: 와일드카드 CORS는 시한폭탄이다
dev.to에 게재된 한 분석에 따르면 Cursor, Claude Code, Copilot은 Express와 FastAPI 프로젝트에 CORS를 추가할 때 거의 예외 없이 Access-Control-Allow-Origin: *를 생성한다. 코드 자체는 틀리지 않았다. 2019년 스택오버플로우 답변, 공식 퀵스타트 문서, '10분 만에 REST API 만들기' 포스트—훈련 데이터에 쌓인 패턴을 충실히 재현한 결과다.
문제는 그 패턴이 로컬호스트를 전제로 쓰였다는 점이다. AI는 패턴을 학습했지만, '이건 개발 환경용이고 프로덕션에서는 위험하다'는 주석까지 학습하지 못했다. 특히 FastAPI에서 allow_origins=["*"]와 allow_credentials=True를 함께 쓰는 조합은 CWE-942에 해당하는 취약점이다. 일부 CORS 라이브러리는 크리덴셜이 포함된 요청에서 와일드카드를 허용하지 못하도록 한 스펙 제약을 우회하기 위해 요청자의 Origin 헤더를 그대로 반사시키는데, 이는 보호 장치를 사실상 무력화한다.
수정은 단 두 줄이다. 허용 오리진을 환경변수에서 읽어오는 명시적 허용 목록으로 교체하면 된다. 진짜 문제는 고치는 데 걸리는 시간이 아니라, 아무도 프롬프트에 '프로덕션용으로 작성해줘'라고 명시하지 않는다는 데 있다.
두 번째 함정: ARIA를 더하는 게 접근성이 아니다
AI가 생성하거나 개발자가 접근성 점수를 올리기 위해 덧붙이는 ARIA 속성도 유사한 패턴으로 오염된다. WAI-ARIA 명세의 첫 번째 규칙은 아이러니하게도 'ARIA를 쓰지 마라'다—네이티브 HTML 요소로 표현 가능하다면.
현실에서 자주 발견되는 코드를 보자. <button role="button" aria-label="Submit form">Submit form</button>. 여기서 ARIA 속성 전부가 불필요하다. <button>은 이미 암묵적으로 role이 button이고, 버튼 안의 텍스트가 이미 접근 가능한 이름을 제공한다. 더 나쁜 경우는 aria-label이 보이는 텍스트와 어긋날 때다. 화면에는 '요금제'가 보이는데 스크린리더가 '플랜 및 가격 안내 보기'를 읽으면, 시각 사용자와 스크린리더 사용자가 서로 다른 인터페이스를 경험하게 된다.
ARIA가 진짜 필요한 경우는 명확하다. 텍스트 없이 아이콘만 있는 버튼, JavaScript로 동적 주입되는 콘텐츠에 필요한 aria-live, 네이티브 HTML로 표현할 수 없는 커스텀 컴포넌트—이 세 가지가 거의 전부다. 자동화 접근성 검사 도구가 경고를 지워준다고 해서 aria-label을 붙이는 건 문제를 해결하는 게 아니라 숨기는 것이다. 오히려 더 복잡한 유지보수 부채를 남긴다.
세 번째 신호: 앱스토어가 품질 게이트를 닫고 있다
거시적인 생태계 관점에서도 경고등이 켜졌다. 지디넷코리아 보도에 따르면 2026년 1분기 글로벌 앱스토어 신규 앱 등록 건수는 전년 동기 대비 84% 증가했다. Claude Code, Codex 같은 도구들이 비전문가까지 앱 개발 시장에 진입시킨 결과다. '코딩의 민주화'가 현실이 되었다.
애플은 앱 심사 가이드라인 2.5.2를 근거로 심사 기준을 강화했다. AI 기반 앱 생성 도구의 실시간 코드 생성·실행 방식이 폐쇄적 심사 체계와 충돌한다는 게 표면적 이유지만, 실질적으로는 외부 AI 개발 도구가 자사 플랫폼 통제권을 우회하는 것을 막으려는 포석이다. 아이러니하게도 애플은 외부 도구에는 엄격한 기준을 적용하면서 자체 개발 환경인 Xcode에는 AI 기능을 적극 통합 중이다.
이는 단순한 품질 통제가 아니다. 앱 공급이 폭발적으로 늘어날수록 플랫폼의 품질 게이트는 더 촘촘해질 수밖에 없다. AI로 빠르게 만든 앱이 심사를 통과하지 못한다면, 속도의 이점은 심사 대기 시간 앞에서 상쇄된다.
시사점: 속도는 전략이 아니라 전술이다
세 가지 함정이 공유하는 본질은 같다. AI는 '가장 자주 등장한 패턴'을 재현하도록 훈련되었고, 그 패턴이 프로덕션 맥락에서 안전한지 여부는 개발자가 판단해야 한다. CORS 와일드카드는 튜토리얼 맥락에서 맞고, ARIA 남용은 접근성 도구 점수 맥락에서 맞으며, 최소 동작하는 앱은 스토어 등록 맥락에서 맞다. 그러나 세 가지 모두 프로덕션 맥락에서는 틀렸다.
실용적인 대응은 간단하다. CORS는 환경변수 기반 명시적 허용 목록으로, ARIA는 '추가'가 아닌 '제거' 관점으로 접근하고, 신규 앱이라면 플랫폼 심사 정책을 배포 전에 먼저 확인한다. semgrep CORS 규칙을 pre-commit 훅에 걸고, 브라우저 접근성 검사기로 ARIA 트리를 직접 확인하는 것—이 두 가지만으로도 AI가 만들어낸 함정의 대부분을 사전에 걸러낼 수 있다.
바이브 코딩의 속도는 진짜 이점이다. 하지만 속도는 전술이고, 품질과 보안은 전략이다. AI 에이전트를 쓸수록 개발자의 검증 역량이 더 중요해지는 역설—그것이 지금 우리가 적응해야 할 새로운 기준선이다.