솔직하게 말하자. 지금 대부분의 팀은 AI로 코드를 생성하는 속도는 폭발적으로 빨라졌는데, 그걸 안전하게 프로덕션에 올리는 능력은 아직 거기 못 따라가고 있다. "내 로컬에서는 된다"와 "실사용자 트래픽에서도 된다" 사이의 간극은 AI 코딩 시대에 오히려 더 벌어졌다. Vibe coding으로 REST API 하나 뚝딱 만드는 건 이제 누구나 한다. 문제는 그다음이다.
이 글은 세 개의 소스를 하나의 프레임으로 엮는다. dev.to에 올라온 AI 생성 코드 프로덕션 배포 가이드, DProvenanceKit의 에이전트 회귀 테스트 접근법, 그리고 보이지 않는 Unicode 문자를 이용한 프롬프트 인젝션 취약점 분석. 각각 따로 읽으면 흥미로운 기술 아티클이지만, 함께 보면 하나의 메시지가 된다. AI가 만든 코드를 배포하기 전에 반드시 통과해야 할 게이트가 세 개 있다.
게이트 1: AI 출력물을 '1차 초안'으로 다루는 구조적 검토
AI 코딩 어시스턴트가 생성한 코드는 "그럴듯하게 보이도록" 최적화되어 있다. 실제 트래픽을 견디도록 최적화된 게 아니다. dev.to의 배포 가이드가 든 예시는 직관적이다. AI가 생성한 로그인 핸들러에 SQL 인젝션 벡터가 그대로 열려 있고, 비밀번호 평문 비교가 들어가 있고, 로그인 실패 시 응답이 없다. 모델 입장에서는 "동작하는 코드"를 썼다. 개발자 입장에서는 보안 사고의 씨앗이다.
실용적인 1차 검토 체크리스트는 간단하다. 하드코딩된 시크릿이나 플레이스홀더 API 키가 있는지, 문자열 연결 쿼리가 파라미터화 쿼리 대신 쓰였는지, 실패 분기(else, fallback)가 빠져 있는지, CVE가 있는 의존성이 딸려왔는지. 이 네 가지만 5분 안에 훑어도 나중에 몇 시간의 디버깅을 막는다. 테스트도 마찬가지다. AI가 기본으로 뱉는 테스트는 "200 응답 확인" 수준에 머문다. 만료된 토큰, 누락된 자격증명, 존재하지 않는 사용자—프로덕션을 실제로 깨는 케이스들은 직접 지정해서 생성시켜야 한다. AI에게 "실패 케이스와 엣지 케이스 중심으로 테스트를 작성해줘"라고 명시적으로 요청하는 것과 기본 프롬프트로 맡기는 것은 결과물이 완전히 다르다.
관찰 가능성(observability) 설정은 코드 검토와 같은 시점에 해야 한다. 나중에 붙이면 항상 사고가 먼저 터진다. 서비스 경계마다 구조화된 로그, 에러 트래킹, AI/에이전트 호출의 레이턴시 분리 측정—이 세 가지는 선택이 아니라 배포 전제조건으로 취급해야 한다.
게이트 2: 에이전트 회귀 탐지를 CI에 심기
단순한 함수 수준의 테스트는 에이전트 워크플로우에서 한계가 있다. 에이전트는 매 실행마다 다른 경로를 탈 수 있고, 특정 스텝을 조용히 건너뛰거나 루프에 빠질 수 있다. 이걸 기존 단위 테스트로 잡기는 어렵다. DProvenanceKit이 흥미로운 이유가 여기 있다. 이 라이브러리는 에이전트의 각 실행을 "실행 경로의 지문(fingerprint)"으로 변환하고, 두 실행 간의 구조적 차이를 비교한다.
예를 들어 정상 실행이 plan → search → rank → verify → decide 순서라면, PR 이후 실행이 plan → search → search → search → search → decide로 바뀐 경우—verify가 빠지고 search가 루프를 탄다—이걸 DProvenanceKit은 REGRESSION (severity: high, strength: 0.95)로 판정하고 CI를 빨간 불로 막는다. "에이전트가 소스 검증 단계를 조용히 빼먹기 시작했다"는 사실이 고객 티켓이 아니라 PR 코멘트로 올라오는 구조다. 서버 없이 SQLite 트레이스 DB와 CLI 하나로 동작하고, GitHub Actions 템플릿도 제공한다. 제로 외부 의존성이라 팀에 붙이는 허들이 낮다.
AI 에이전트를 프로덕션에서 돌리는 팀이라면 이런 회귀 탐지 레이어를 CI에 심는 걸 진지하게 고려해야 한다. 에이전트의 "동작"은 출력 텍스트만으로 판단할 수 없다. 어떤 스텝을 어떤 순서로 밟았는지, 어떤 툴을 얼마나 호출했는지—실행 경로 자체가 품질 신호다.
게이트 3: 보이지 않는 문자 인젝션 차단
세 번째 게이트는 가장 덜 알려졌지만, AI 파이프라인에서 가장 과소평가된 위협이다. dev.to의 보안 분석 아티클은 Claude Code에서 발견된 보이지 않는 Unicode 문자 삽입 사례를 출발점으로, 훨씬 본질적인 문제를 짚는다. 제로 폭 스페이스(U+200B), 변형 선택자(U+FE00~FE0F, U+E0100~E01EF), 태그 블록 문자(U+E0000~U+E007F) 같은 문자들은 사람 눈에는 보이지 않지만 바이트 레벨에서는 엄연히 존재한다.
공격 시나리오는 구체적이다. ignore previous instructions라는 문자열을 차단하는 필터가 있다고 하자. 각 문자 사이에 U+200B를 삽입하면 ignore가 된다—화면에는 동일하게 보이지만, 정규식 필터는 통과한다. 사용자가 올린 문서, 크롤링한 웹페이지, RAG 시스템이 인덱싱한 GitHub 이슈—이 모든 경로가 잠재적인 인젝션 경로다. 아티클이 제시하는 핵심 원칙은 명확하다. "보이는 텍스트"와 "받은 텍스트"가 같다고 가정하는 시스템은 구멍이 있다.
수정은 생각보다 간단하다. 프롬프트 경계에서 NFKC 정규화를 실행하고, Cf(포맷 문자), Cc(제어 문자), Co(사용자 정의 영역) 카테고리를 스트립하되, 변형 선택자(Mn 카테고리)는 별도 범위 체크로 잡아야 한다—카테고리 필터만으로는 통과된다. 그리고 조용히 버리지 말고 로그를 남겨야 한다. 신뢰할 수 있는 문서에서 태그 문자가 발견된다면 그건 alert 트리거다.
팀에 당장 적용할 수 있는 것
세 게이트를 하나의 파이프라인으로 정리하면 이렇다. 게이트 1: AI 출력물을 PR에 올리기 전 구조적 검토 체크리스트를 통과시킨다—SQL 인젝션, 시크릿 노출, 실패 분기 누락, 의존성 CVE. 게이트 2: AI 에이전트를 쓴다면 DProvenanceKit 같은 실행 경로 기반 회귀 탐지를 CI에 붙인다. 게이트 3: 외부 텍스트가 프롬프트에 들어가는 모든 경로에 Unicode 정규화와 보이지 않는 문자 스트리핑을 심는다.
이 세 가지 중 내일 당장 시작할 수 있는 건 게이트 1과 게이트 3이다. 체크리스트는 팀 PR 템플릿에 추가하면 되고, clean_for_prompt() 함수 하나는 오늘 오후에 붙일 수 있다. 게이트 2는 에이전트 워크플로우가 있는 팀이 우선 대상이다. AI가 코드를 생성하는 속도가 빨라질수록, 이 검증 레이어의 가치는 비례해서 올라간다. 빠르게 만드는 능력은 이미 누구나 갖췄다. 안전하게 배포하는 능력이 지금 팀의 진짜 경쟁력이다.