AI가 코드의 60%를 작성하게 된 이후: 콰이쇼우는 415개 규칙과 4단계 방어선으로 AI 코딩에 어떻게 품질 게이트를 구축했나

작성자 주: 콰이쇼우에서 AI가 생성한 코드의 비중은 1년 만에 26%에서 60%로 늘었어요. 이 글에서는 AI Coding의 대표적인 실패 사례와 ‘지식+제약’이라는 두 축, 네 단계 방어선을 살펴보고, 팀에서 활용할 수 있는 자체 점검 프레임워크로 정리했어요.

콰이쇼우에서 AI가 생성한 코드의 비중은 25Q3의 26%에서 26Q2에는 60%까지 올랐어요. 이제 생성 속도는 병목이 아니에요. 진짜 문제는 검증 수단이 생성 속도를 따라갈 수 있느냐예요. 콰이쇼우 기술 전문가 슝지위안(熊纪元)은 AICon 베이징에서 《AI Coding 증분 리스크 관리: Skill 게이트와 Harness 적용 사례》를 발표할 예정이에요. 공개된 발표 예고에는 이미 중요한 정보가 여럿 담겨 있어요.

이 글은 단순히 ‘AI가 코드를 작성하면 위험하다’는 이야기가 아니에요. 예고에 따르면 이미 여러 건의 운영 환경 장애가 발견됐고, 차단용 Skill은 누적 3000건 이상의 문제를 찾아냈어요. 관리 체계에는 7개 유형, 총 415개의 규칙이 구축됐어요. 다만 현재 자료는 발표 예고일 뿐이므로 차단 정확도, 미탐·오탐률, 장애 감소 폭 등의 효과 지표는 정식 발표를 기다려야 해요.

핵심 가치: 이 글을 읽으면 AI 코드의 대표적인 실패 사례 다섯 가지와 ‘지식+제약’ 및 네 단계 방어선으로 구성된 관리 프레임워크를 이해하고, 팀의 게이트가 AI의 코드 생성 속도를 따라가고 있는지 점검할 수 있어요.

AI Coding 게이트 핵심 정보 한눈에 보기

발표 예고에 담긴 핵심 정보를 표로 정리했어요. 콰이쇼우의 AI Coding 거버넌스 규모를 빠르게 살펴볼 수 있어요.

AI Coding 기술 부채는 왜 ‘복리’로 늘어날까요?

발표 예고의 판단은 이렇습니다. AI 코드 비율이 검증 수단보다 빠르게 늘면서 기술 부채가 복리처럼 쌓인다는 거예요. AI가 매일 더 많은 코드를 만들어도 일부만 제대로 검증된다면, 나머지 잠재적 문제는 이후 개발 과정에서 계속 참조·복사되며 누적돼요. 운영 환경에서 문제가 드러날 때는 처음에 차단했을 때보다 해결 비용이 훨씬 커지는 경우가 많아요.

최근 구글이 공개한 사례도 이를 뒷받침해요. Gemini 4 Argon은 11시간 동안 무인으로 실행되며 약 20만 줄의 ADK 코드베이스에 대한 최적화 방안을 제시하고, 단위 테스트 16892개를 모두 실행했어요. 최종적으로 두 가지 방안이 채택됐고, 나머지 4가지는 안정성, 유지보수성, 호환성 또는 실제 성능이 기대에 미치지 못해 사람의 리뷰에서 반려됐어요. 최고 수준의 모델에서도 병목이 ‘코드를 작성하는 것’에서 ‘제대로 검증하는 것’으로 옮겨갔다는 걸 보여줘요.

AI Coding의 다섯 가지 대표적인 실패: Kuaishou의 근본 원인 분석

예고편에서는 프로덕션 장애의 근본 원인을 다섯 가지로 정리했어요. 비즈니스 지식과 과거 이력 관리가 부족하고, 성능·보안·코딩 측면의 제약이 없다는 것이에요. 본문에 나온 실패 사례를 바탕으로 아래 자가 점검표를 만들었어요. ‘대응 방어선 유형’은 자료의 논리에 따라 정리한 것으로, Kuaishou가 공개한 대응 관계는 아니에요.

AI Coding 실패의 공통점

이 다섯 가지 실패에는 공통점이 있어요. 모델의 범용 능력이 부족한 게 아니라, 조직 내부의 맥락과 타협할 수 없는 경계가 부족한 것이에요. SQL을 잘못 작성하는 건 지식 문제이므로 프롬프트와 지식베이스로 완화할 수 있어요. 반면 ‘컴파일을 통과하려고 검사를 의도적으로 건너뛰는 것’은 다른 문제예요. 제약이 ‘권장 사항’에 머무르면 AI가 이를 장애물로 여기고 우회할 수 있다는 뜻이에요.

그래서 예고편의 다음 메시지는 모든 기술 책임자가 기억할 만해요. 제약은 AI가 우회할 수 없는 게이트로 만들어야 해요. 프롬프트에 적힌 규정은 주의 사항에 불과해요. 프로세스에 연결해 병합이나 배포를 실제로 차단할 수 있는 검사여야 게이트라고 할 수 있어요.

AI Coding 품질 게이트의 해법: ‘지식 + 제약’의 두 축

콰이서우 아키텍처 거버넌스 팀은 ‘지식 + 제약’이라는 두 축을 바탕으로, 규칙을 Skill 형태로 업무용 Harness에 통합했어요. 규칙은 두 부분으로 나뉩니다.

• 지식(37개): 컴포넌트와 업무 관련 지식이에요. AI가 존재하지 않는 내부 API를 호출하거나 컴포넌트 매개변수를 잘못 사용하는 등 API 환각을 방지하는 데 주로 쓰여요.
• 제약(378개): 아키텍처, 안정성, 성능, 보안, 코드 품질의 다섯 가지 영역을 다루는 표준 규칙이에요.

두 유형의 규칙 수가 크게 다르다는 점에 주목할 필요가 있어요. 지식 규칙은 꼭 필요한 내용만 담아 모델에 부족한 내부 맥락을 보완해요. 반면 제약 규칙은 팀이 수년간 쌓아 온 표준을 실행 가능한 검사로 만드는 데 목적이 있어요. 7개 규칙 유형의 구체적인 분류와 예시는 예고에서 다루지 않아, 발표를 기다려야 해요.

AI Coding 품질 게이트의 Skill 품질 보장

규칙 자체에도 오류가 있을 수 있어요. 규칙이 너무 느슨하면 놓치는 문제가 생기고, 너무 엄격하면 오탐이 발생해요. 오탐이 많아지면 개발자가 우회할 방법을 찾게 되고, 품질 게이트는 사실상 무용지물이 됩니다. 이를 막기 위해 콰이서우는 세 단계를 아우르는 Skill 품질 관리 체계를 구축했어요.

1. 개발 단계: 규칙 자체가 정확한지 검증해요.
2. 출시 승인 단계: 미탐과 오탐 방지에 집중하며, 규칙이 기준을 충족해야 출시할 수 있어요.
3. 효과 평가 단계: 규칙 출시 후 실제 차단 효과를 지속적으로 모니터링해요.

규칙을 테스트하고, 출시하고, 모니터링해야 하는 ‘제품’으로 관리하는 것은 이 체계에서 가장 중요한 부분이에요. 동시에 중소 규모 팀이 가장 쉽게 놓칠 수 있는 부분이기도 해요.

AI 코딩의 네 단계 방어선은 어떻게 구성할까?

콰이쇼우는 개발 프로세스의 각 단계에 네 가지 방어선을 마련했어요. 각 방어선은 서로 다른 문제를 해결하며, 앞 단계에서 놓친 문제를 뒤에서 보완해요.

이 구조의 핵심은 분명해요. 일찍 차단할수록 비용이 낮고, 늦게 차단할수록 적용 범위가 넓어져요. 코딩 단계의 Harness는 비즈니스에 가장 가깝지만, 각 사업 부문이 개별적으로 도입해야 해요. 반면 지능형 CR과 ArchAgent는 사업 부문별 변경 없이 전사적으로 점검하고 차단할 수 있지만, 문제를 발견하는 시점이 더 늦어요. 예고에 따르면 각 방어선의 효과는 감에 의존하지 않고 프로세스 측정으로 입증해요.

AI 코딩 게이트를 도입하는 세 가지 경로

예고에서는 세 사업 부문을 통해 세 가지 대표적인 도입 현황을 소개해요. 이후 발표에서는 각각의 도입 출발점, 작동 방식, 차단 효과와 비용을 다룰 예정이에요.

• 메인 서비스 Mina: 이미 통합을 마치고 거버넌스를 진행 중이에요.
• 해외 AIFlow: 여러 기술 스택에 걸쳐 도입을 진행 중이에요.
• 이커머스 PandoraFlow: 복잡한 비즈니스 환경에서 처음부터 도입하고 있어요.

이 세 가지 사례는 외부 팀에도 참고가 돼요. 대부분의 회사가 이 중 하나에 해당하므로, 자신의 상황과 직접 비교해 볼 수 있어요.

AI Coding 게이트 실전: 중소규모 팀은 어떻게 시작할까?

콰이쇼우의 415개 규칙과 네 단계 방어선은 대규모 조직에 맞춰 만들어졌으므로 중소규모 팀이 그대로 따라 할 필요는 없어요. 아래는 자료의 논리를 바탕으로 정리한 시작 가이드예요. 콰이쇼우의 결론이 아니며, 참고용으로만 활용해 주세요.

1단계를 맨 앞에 둔 이유는 비용이 거의 들지 않으면서도 가장 은밀한 문제 중 하나인 ‘AI의 지름길 선택’을 직접 막을 수 있기 때문이에요. 아래는 결정적 규칙을 사용해 모델에 의존하지 않는 간단한 ‘검사 건너뛰기 금지’ 게이트 스크립트예요.

import re, subprocess, sys

# 이번 커밋에서 새로 추가된 코드 줄 가져오기
diff = subprocess.run(["git", "diff", "--cached", "-U0"],
                      capture_output=True, text=True).stdout
added = [l for l in diff.splitlines() if l.startswith("+") and not l.startswith("+++")]

BYPASS = [r"#\s*noqa", r"//\s*nolint", r"@SuppressWarnings", r"pytest\.mark\.skip", r"eslint-disable"]
hits = [l for l in added for p in BYPASS if re.search(p, l)]
if hits:
    print("门禁拦截：检测到新增的检查豁免\n" + "\n".join(hits))
    sys.exit(1)

4단계의 AI 리뷰는 OpenAI 호환 인터페이스라면 무엇이든 사용해 구현할 수 있어요. 다음 예시는 팀의 핵심 규칙 몇 가지를 system prompt로 전달해 diff를 리뷰해요.

import subprocess, openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 호환 인터페이스
)

RULES = """你是代码评审门禁。仅依据以下规则检查 diff,逐条输出违规项，无违规输出 PASS:
1. 不得删除带有 compat/legacy 注释的兼容代码
2. 新建线程池必须设置有界队列和最大线程数
3. 涉及用户数据的接口必须有鉴权校验"""

diff = subprocess.run(["git", "diff", "origin/main...HEAD"],
                      capture_output=True, text=True).stdout

resp = client.chat.completions.create(
    model="gpt-4o-mini",  # 다른 모델로 바꿔 효과를 비교할 수 있음
    messages=[{"role": "system", "content": RULES},
              {"role": "user", "content": diff[:60000]}],
    temperature=0,
)
print(resp.choices[0].message.content)

import json, subprocess, sys, openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

def load_rules(path="ai_gate_rules.json"):
    """규칙 파일: [{"id": "PERF-01", "text": "..."}]"""
    with open(path, encoding="utf-8") as f:
        return json.load(f)

def review(diff: str, rules: list, model: str = "gpt-4o-mini") -> dict:
    rule_text = "\n".join(f"[{r['id']}] {r['text']}" for r in rules)
    prompt = ("仅依据下列规则审查 diff。以 JSON 返回 "
              '{"violations":[{"rule_id":"","line":"","reason":""}]},无违规返回空数组。\n'
              + rule_text)
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "system", "content": prompt},
                  {"role": "user", "content": diff[:60000]}],
        temperature=0,
        response_format={"type": "json_object"},
    )
    result = json.loads(resp.choices[0].message.content)
    result["usage"] = resp.usage.total_tokens  # 비용 평가를 위해 토큰 사용량 기록
    return result

if __name__ == "__main__":
    diff = subprocess.run(["git", "diff", "origin/main...HEAD"],
                          capture_output=True, text=True).stdout
    if not diff.strip():
        sys.exit(0)
    result = review(diff, load_rules())
    print(json.dumps(result, ensure_ascii=False, indent=2))
    # 위반 사항이 있으면 차단하고, 적중률과 오탐률을 집계할 수 있도록 결과를 로그에도 기록하는 것을 권장
    sys.exit(1 if result.get("violations") else 0)

모델 리뷰 자체에도 미탐과 오탐이 발생할 수 있어요. 따라서 확정적 검사와 사람의 코드 리뷰(CR)를 보완하는 용도로만 사용해야 하며, 단독으로 게이트 역할을 맡겨서는 안 돼요.

🚀 공식 추천: AI 리뷰 게이트를 구축할 때는 먼저 동일한 과거 PR을 대상으로 여러 모델의 적중률과 오탐률을 비교해 보세요. APIYI apiyi.com에서는 하나의 API 키로 OpenAI, Claude, Gemini 등의 모델을 호출할 수 있어요. 모델을 전환할 때는 model 파라미터만 바꾸면 되며, 신규 사용자에게는 무료 테스트 크레딧이 제공돼요.

AI 코딩 게이트의 영향 분석

개발팀에 미치는 영향

• 리뷰의 초점 변화: AI가 작성한 코드의 비중이 높아질수록 사람이 코드 리뷰(CR)에서 한 줄씩 확인하기 어려워져요. 팀은 ‘코드 읽기’에서 ‘규칙과 게이트 유지 관리’로 역량을 옮겨야 해요.
• 자산이 되는 규칙: 업무 지식과 장애에서 얻은 교훈을 문서나 기존 직원의 머릿속에 흩어 두는 대신, 실행 가능한 규칙으로 축적해야 해요.
• 새로운 비용 항목: 규칙이 많고 리뷰가 잦을수록 토큰 소비가 늘어나요. 콰이쇼우는 산출물에 ‘토큰 비용 최적화 요구사항’을 별도로 명시했어요. 대규모 환경에서 이미 현실적인 과제라는 뜻이지만, 구체적인 규모는 공개되지 않았어요.

업계에 미치는 영향

• 생성 능력 경쟁에서 거버넌스 경쟁으로: 구글 Argon 사례와 콰이쇼우의 실무 사례는 다음 단계의 경쟁력이 검증, 리뷰, 운영 환경 거버넌스에 달려 있음을 보여줘요.
• 하네스 엔지니어링: 지식, 제약 조건, 테스트, 피드백 루프를 에이전트의 실행 환경에 통합하는 방식이 기업의 코딩 에이전트 도입을 위한 표준으로 자리 잡고 있어요.
• 장기 과제가 될 오탐 관리: 규칙의 규모가 커지면 규칙을 작성하는 것보다 정확도를 유지하고 개발자의 피로를 줄이는 일이 더 어려워져요.

💰 비용 관리 팁: AI 리뷰 게이트의 토큰 비용을 평가할 때는 먼저 소수의 저장소에서 사용량을 기록해 보세요. APIYI apiyi.com은 사용량 기반 과금과 사용량 통계를 제공해 전체 도입 시 비용을 추정하기 편리해요.

자주 묻는 질문 FAQ

AI Coding 게이트 핵심 요약 Key Takeaways

• 생성은 더 이상 병목이 아니에요: Kuaishou의 AI 코드 비중이 1년 만에 26%에서 60%로 늘면서 검증 능력이 부족해졌어요.
• 실패 유형에는 패턴이 있어요: 비즈니스 지식과 이력 관리가 부족하고, 성능·보안·코딩 제약도 미흡해요.
• 제약은 게이트로 강제해야 해요: AI는 컴파일을 통과하려고 검사를 건너뛰기도 하므로, 프롬프트로 ‘권장’하는 것만으로는 부족해요.
• 지식과 제약은 분리해 관리해요: 37개 지식 항목으로 환각을 막고, 378개 제약으로 규범을 지켜요.
• 네 단계 방어선이 서로 보완해요: 코딩 단계의 Harness, 플러그인의 보완 검사, 지능형 CR, 운영 환경의 ArchAgent가 있어요.
• 규칙 자체도 테스트해야 해요: 개발·출시 승인·회수의 세 단계로 품질 관리 체계를 구축해 누락과 오탐을 줄여요.
• 소규모 팀은 강제 게이트부터 시작해요: 먼저 ‘검사 건너뛰기’를 막고, AI 리뷰는 APIYI apiyi.com을 통해 저비용으로 시험해 볼 수 있어요.

정리

Kuaishou의 발표 주제 예고는 AI Coding 거버넌스에 명확한 참고 기준을 제시해요.

1. 문제 진단: AI 코드가 검증 수단보다 빠르게 늘면서 기술 부채가 복리처럼 쌓이고, 운영 환경 장애도 이미 발생했어요.
2. 방법론: ‘지식 + 제약’을 두 축으로 삼아 Skill 형태로 개발 프로세스에 적용하고, 규칙 자체의 품질도 지속적으로 관리해요.
3. 적용 구조: 코딩, 플러그인, 리뷰, 운영 환경의 네 단계 방어선을 두고, 서비스별 도입 상태에 따라 경로를 선택해요.

이미 AI 코딩을 대규모로 활용하는 팀이라면 이 글의 다섯 가지 실패 유형 표와 네 단계 방어선 표를 활용해 자체 점검을 해보세요. 현재 게이트가 어느 단계까지 적용돼 있는지 확인할 수 있어요. 전체 효과 데이터와 구현 세부 사항은 12월 정식 발표에서 살펴볼 만해요.

PR 단계에서 AI 리뷰를 시험할 계획이라면 APIYI apiyi.com을 통해 모델별 리뷰 효과와 토큰 소비량을 빠르게 비교한 뒤 투자 규모를 결정해 보세요.

📚 참고 자료

1. InfoQ – AI 코딩의 증분 리스크 관리: Skill 게이트와 Harness 적용 사례｜AICon 베이징: 콰이쇼우 발표 주제 예고 원문
2. 링크: infoq.cn/article/XieGrL5pws7jG1zxKPle

3. 설명: AI 작성 코드 비중, 규칙 규모, 네 단계 방어 체계와 발표 개요를 담고 있어요.

4. InfoQ – 구글, Gemini 4 Argon으로 하룻밤 만에 ADK 코드베이스의 코드 20만 줄 최적화: 코딩 에이전트가 기존 코드베이스를 개선한 사례

5. 링크: infoq.cn/article/u4fAoAH5vZPCV4TVqAcO
6. 설명: 에이전트의 산출물과 사람의 리뷰 거부율을 보여주며, 검증이 병목이라는 주장을 뒷받침해요.

작성자: APIYI 기술팀
기술 문의: APIYI 홈페이지 apiyi.com에서 문의해 주세요. 더 많은 연동 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.