데이터 출처: CodeRabbit 2025.12 / New Relic 2026 보고서, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms 발표, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. 사례는 대표적인 시나리오를 요약한 것으로, 특정 기업을 지칭하지 않음.

당신의 가장 큰 실수는 도구를 사지 않은 게 아니라, CLAUDE.md를 쓰지 않은 것이다

한 시중은행의 CIO가 저에게 이렇게 털어놓았습니다. AI 도구도 사고, 모델도 배포하고, 인력 교육도 마쳤는데, 2026년 상반기 내내 납기(交付周期)가 거의 줄지 않았다고요. 핵심 시스템 담당 팀장은 더 직설적이었습니다. “AI가 작성한 코드는 쓸 만한데, 매번 처음부터 다시 고쳐야 합니다. AI가 우리 은행의 규칙을 모르고, 규제 요건을 모르고, 30년 묵은 레거시 시스템과 어떻게 연동해야 하는지도 모릅니다.”

문제는 AI가 충분히 강력하지 않다는 것이 아니라, 규칙을 코드로 명시하지 않았다는 데 있다. CodeRabbit이 2025년 12월 470개 오픈소스 PR을 분석해 발표한 수치는 업계에서 널리 인용된다. AI가 협업한 PR에는 평균 10.83개의 문제가 있었고, 순수 인간이 작성한 PR에는 6.45개가 있었다. 약 1.7배, 즉 인간보다 버그가 70% 더 많았다. 2026년이 되어도 상황은 반전되지 않았다. New Relic의 《2026 State of AI Coding Report》에 따르면, 78%의 팀이 AI 코드를 배포한 이후 더 많은 장애를 보고했고, 62%의 기술 리더는 팀이 “자신감 있게, 그러나 라인별 리뷰 없이 AI 코드를 바로 배포한다”고 인정했다(New Relic 공식 보고서 2026, 0.866 score, 1차 출처). 두 데이터는 같은 사실을 말한다. AI에게 부족한 것은 능력이 아니라 맥락이다.

2026년 8월 현재, 모든 “AI 전환 가속화” 서사는 다음 대비 속에서 읽혀야 한다.

| 진영 | 진행 상황 (2026 H1) | 반례 (2026 H1) |
|—|—|—|—|
| EY | Microsoft 365 Copilot을 150,000명의 임직원에게 확대 배포, 250만 시간 / 2.5억 달러 절감; 글로벌 40만 임직원으로 확장 예정 | 다만 95% 업무 속도 향상, 37% 재무 운영 비용 절감의 전제가 “규범 선행”임을 동시에 인정 |
| Atos | 54개국 / 56,000명 임직원 대상 배포 완료; 19,000개 AI 에이전트 동시 운영, 통합 ID/보안/컴플라이언스/거버넌스 컨트롤 플레인 구축 | “Agent 365 거버넌스 역량을 먼저 구축한 뒤 확장한다”는 원칙을 고수 |
| Microsoft 자체 | 2026 Work Trend Index: 리더의 82%가 12~18개월 내 AI 에이전트로 노동력 확장 계획 | 동시에 “개인 사용 대비 조직 변화의 속도가 뒤처지고 있다”고 인정 — Frontier Firm 개념의 핵심 모순 |

출처: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

이 두 그룹의 대조가 보여주는 것은 단 하나다. 규범 없이 규모를 키우는 것은 리스크에 N을 곱하는 것과 같다. EY/Atos/Microsoft의 “빠름”은 모델이 빠른 것이 아니라, “조직이 AI를 어떻게 쓸지에 대한 답을 먼저 끝냈다”는 뜻이다. 이것이 Spec-Driven Development(SDD, 스펙 기반 개발)가 2026년 상반기에 진짜 주류가 된 배경이다. 엔지니어가 문서를 좋아해서가 아니라, 스펙을 쓰지 않으면 19,000개 에이전트가 존재하는 환경에서 살아남을 수 없기 때문이다.

이 글은 세 가지를 명확히 다룬다: 1) AI 코드의 결함이 왜 사람이 작성한 코드보다 1.7배 이상 심각한가; 2) GitHub, AWS, OpenAI, Anthropic, Alibaba 다섯 개 플랫폼이 2026년 상반기에 어떻게 같은 패러다임, 즉 문서로 AI의 행동을 제약하는 방식으로 수렴했는가; 3) 스펙 기반 개발이 왜 도구 선택이 아닌 조직 역량인가, 그리고 2026년 상반기 적용의 3단계는 무엇인가.

막대 길이 = AI 결함이 인간의 배수; 기준선 1.0× = 인간 수준

기준 1.0×

전체 문제 수

1.7×
AI 10.83 vs 인간 6.45 / PR

로직/정확성 오류

1.75×

코드 품질/유지보수성

1.64×

보안 발견 (종합)

1.57×

비밀번호 처리 부적절

1.88×

XSS 취약점

2.74×
↑ 최고

규범 제약 없는 AI 코드, 모든 차원에서 인간보다 높음
금융/통신 = 규정 준수 대사, 비밀번호 관리, 민감 필드 암호화, AI 모두 놓침

AI 부족한 로컬 비즈니스 로직: 모델은 통계적 추론으로 코드 패턴을 처리하지, 의미를 이해하지 못한다

“AI는 로컬 비즈니스 로직이 부족하다. 모델은 코드 패턴을 통계적으로 추론할 뿐, 의미적으로 이해하지 못한다. 엄격한 제약이 없으면, 시니어 엔지니어가 내면화한 시스템 규칙을 놓친다.”

이 문장은 CodeRabbit이 자체 AI 코딩 플랫폼(AI 코드 리뷰 전문 기업)에서 왜 다른 회사보다 먼저 이 데이터를 볼 수 있었는지를 설명한다. 그들은 매일 수천 개의 PR을 검토하고, AI가 작성한 코드가 어떤 모습인지 매일 확인한다. 가장 중요한 발견은 총계가 아니라 분포다:

로직/정확성 +75%: 비즈니스 로직 오류, 의존성 오류, 제어 흐름 오류, 설정 오류 — 이런 문제는 테스트에서 드러나지 않을 수 있지만, 프로덕션 환경에서는 장애로 이어진다.
코드 품질 +64%: 네이밍 불일치, 구조 불명확, 프로젝트 패턴 위반 — 이것이 “가장 큰 차이를 만드는 카테고리”다. 시니어 엔지니어는 한눈에 “이건 우리 팀 스타일이 아니다”를 알아본다.
보안 +57%(XSS 계열이 가장 높아 2.74×): 비밀번호 처리 부적절(1.88×), 안전하지 않은 객체 참조(1.91×), 민감 정보 노출, 안전하지 않은 역직렬화(1.82×) — 금융 업계에서 이건 “쓸 수 있느냐”의 문제가 아니라 “출시할 수 있느냐”의 문제다.

문제는 AI가 충분히 강력하지 않다는 게 아니다. AI가 보지 못한다는 거다.

그 CIO가 실제로 부딪힌 지점으로 돌아가 보자. AI가 금융 코어 시스템에서 만들어낸 세 가지 구체적 실패 사례다.

첫째, AI는 30년 된 대사(對査) 로직을 보지 못한다. 은행의 리스크 관리 규칙은 코어 시스템의 스토어드 프로시저에 박혀 있다. 30년 전에 작성됐고, 지금은 아무도 전부 기억하지 못한다. AI가 생성한 코드 로직은 겉보기에 문제없어 보이지만, 프로덕션 환경에서 아무도 기억하지 못하는 대사 점검 로직에 걸려 거래 배치 전체가 실패한다.

둘째, AI는 컴플라이언스 제약을 보지 못한다. 비밀번호는 반드시 키 관리 시스템을 거쳐야 하고, 민감 필드는 암호화 저장이 필수이며, 로그에 고객 정보를 출력해서는 안 된다. 이는 규제상의 하드 제약으로, 내부 제도에 명문화되어 있다. AI는 이걸 모르기 때문에, 작성한 코드는 실행은 되지만 컴플라이언스 심사를 통과하지 못한다.

셋째, AI는 당신의 기술 부채를 보지 못한다. 30년 된 레거시 시스템은 자체적인 인터페이스 프로토콜을 사용하는데, 문서는 이미 오래전에 유실됐다. AI는 표준 RESTful 규약에 맞춰 코드를 작성하고, 배포 후에야 인터페이스가 맞지 않는다는 걸 발견한다. 재작업에 2주가 걸린다.

New Relic의 또 다른 수치로 돌아가 보자. 62%의 팀이 “자신 있게 검토 없이” AI 코드를 배포하고, 78%는 배포 후 더 많은 장애를 보고했다. 이 두 숫자를 합치면 결국 이렇게 읽힌다. AI 코드의 결함률 자체는 문제가 아니다. “AI 코드에 어떤 결함이 있는지 내가 모른다”는 것이 진짜 문제다.

일반적인 시나리오: 한 주식회사 은행이 AI를 도입해 핵심 시스템의 리스크 관리 모듈을 개발한 결과, 3개월 만에 컴플라이언스 심사 반려율이 눈에 띄게 상승했다. 주요 문제는 비밀번호 관리, 민감 필드 암호화, 로그 컴플라이언스 등 내부 규칙이었다. 이 규칙들은 모두 내부 문서에 적혀 있었지만, AI는 이를 볼 수 없었다. 이후 팀이 핵심 규칙을 CLAUDE.md로 작성하자 반려율이 크게 떨어졌다.

2. 5대 플랫폼의 2026 H1: 같은 결말을 향한 “규범 주도”

2025년 7월 GitHub가 Spec Kit을 출시했고, 2026년 초 AWS Kiro, OpenAI Codex, Anthropic Claude Code가 모두 이를 갖췄다. 2026년 5월, Alibaba Qoder는 “Spec-Driven Workflow”를 제품 포지셔닝에 포함시켰다. 5대 플랫폼은 2026 H1에 동일한 패러다임에 도달했다 — 문서로 AI의 행동을 제약하는 것. 이는 어느 한 회사의 발명이 아니라, “AI 코드 품질 위기”에 대한 업계의 집단적 대응이다.

각 플랫폼의 2026 H1 최신 움직임을 하나씩 살펴보자.

**GitHub Spec Kit: 레퍼런스 구현체이자 5단계 게이트웨이 구조다. 2025년 9월에 오픈소스로 공개된 이후 2026년 상반기까지 벌써 산업계 레퍼런스 구현체로 자리 잡았다. 핵심은 5개+2개 구조다. /speckit.constitution(불가역적 원칙), /speckit.specify(무엇을 왜 하는가), /speckit.plan(어떻게 바꿀 것인가), /speckit.tasks(작업 쪼개기), /speckit.implement(실행 그리고 /clarify과 /analyze이 뒤를 따른다. 이 설계의 핵심은 모델 비종속성이다. 즉, 동일한 spec/plan/tasks 파일이 특정 실행 에이전트에 묶이지 않는다는 뜻이다. Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI,

AWS Kiro: 규범 주도 개발을 IDE에 내장하다. 2025년 7월 출시, 2026년 상반기에는 완전한 Agent IDE로 진화. 3단계 워크플로우: 요구사항 → 설계 → 태스크. Spec Kit과의 차이는 “훅(Hook)”에 있다. Kiro의 spec 파일은 사전 정의된 에이전트 액션을 트리거하여, 컴플라이언스/감사/배포처럼 외부 시스템이 필요한 단계를 워크플로우에 미리 심어둘 수 있다. 팀에 규범 작성을 강제하고 싶다면 Kiro를 선택하라 — spec을 작성하지 않으면 Kiro가 시작되지 않기 때문이다 (AWS Kiro 공식 문서 2025.7; Kiro.dev 문서 2026).

OpenAI Codex: AGENTS.md + 조합형 Skills. 2025-2026년, AGENTS.md가 에코시스템의 중심으로 부상했다. Skills는 2026년 상반기의 핵심 확장 기능이다. “엑셀 읽기”, “SQL 생성”, “데이터 마이그레이션 실행” 같은 작업들을 미리 조립해 두고, 레고 블록처럼 호출하는 방식이다. Codex의 주간 활성 사용자는 2026년 6월 기준 500만 명을 돌파했으며, 그중 20%는 비개발자다. 이는 간과하기 쉬운 신호다. 규격 기반(Spec-driven) 접근은 더 이상 엔지니어링 팀만의 전유물이 아니라, 제품, 운영, 리스크 관리 등 전 구성원의 과제가 되었다는 뜻이다. 모두가 AGENTS.md를 작성하고 있다 (OpenAI 2026.6.2 공지; thebcms.com 리뷰 2026, 0.801 score).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic은 프로젝트 지침 문서를 CLAUDE.md(2026년 2월 공식 마켓플레이스 등록), .claude/rules/(디렉터리별 계층형 규칙), Skills(공유 가능한 워크플로우)로 구분한다. Claude Code는 2026년 상반기 개발자 만족도 1위 도구다 — JetBrains 2026.1 설문조사에서 CSAT 91%, NPS 54를 기록했고, 두 개의 독립 조사(Pragmatic Engineer 2026.2)에서도 동일한 결과가 나왔다. 이는 현재 AI 코딩 도구 시장에서 최고 점수다(uvik.net 2026.5, 0.956 score, 1차 소스 종합). Claude Code는 9개월 만에 연환산 매출 25억 달러를 돌파했고(2026.2 Anthropic G 라운드 기준), GitHub에서 11.2만 stars(Skills 저장소)를 확보했다 — 개발자들의 선택이 규칙 기반 접근의 실질적 가치를 증명하고 있다.

Alibaba Qoder: 중국 시장의 규제 주도형 접근. 2025년 8월에 처음 출시된 Qoder는 2026년 5월 15일 1.0 버전으로 업그레이드되면서, 기존의 ‘AI IDE’에서 ‘Autonomous Agent Development Workbench’로 공식적으로 재탄생했다. 이때 Spec-Driven Workflow도 함께 공개됐는데, Quest Mode(자율적 다중 파일 작업), Expert Mode(전문가 팀 병렬 작업), RepoWiki(저장소 지식 그래프)가 그 구성 요소다. 2026년 5월 28일에는 완전 관리형 에이전트 런타임인 Cloud Agents가, 7월 21일에는 규정 준수 및 보안 기능을 담은 Qoder Security가 출시됐고, 같은 달에 모바일 버전(Android/iOS/鸿蒙)도 선보였다. 2026년 5월 기준 전 세계 사용자 수는 500만 명을 돌파했으며, DingTalk CLI는 Qoder를 지원되는 에이전트 실행 환경 중 하나로 공식 등재했다(Yahoo Finance 2025; Alibaba Cloud 공식 자료 2026; Baidu Baike 2026.7).

공통 패러다임: “우리가 AI와 어떻게 협업할 것인가”를 명시적인 문서로 작성해 저장소(repository)에 넣고, 모든 사람과 모든 AI 에이전트가 동일한 규범을 기준으로 작업하게 하는 것. 다섯 개 플랫폼의 구현 세부 사항은 다르지만(파일명/단계 수/훅 메커니즘), 목표는 완전히 동일하다.

왜 이런 일이 2026년 상반기에 집중적으로 발생했을까? AI 역량의 문턱이 이미 지나갔기 때문이다. Claude Code의 자율 에이전트, Codex의 멀티 에이전트 병렬 처리, Cursor의 다중 파일 리팩토링까지, AI는 더 이상 “자동완성 도구”가 아니라 “동료”다. 새 동료에게 줄 온보딩 문서는 AI에게도 반드시 제공해야 한다.

3. 규범 주도는 도구 선택이 아닌 조직 역량이다

이것이 의사결정권자에게 가장 중요한 부분이다. 규범 주도는 도구를 선택하는 것이 아니라 “우리 조직이 AI와 어떻게 협업할지”를 정의하는 것이다. GitHub Spec Kit를 선택하든 Claude Code를 선택하든 중요하지 않다. 중요한 것은 규범을 문서로 작성해 저장소에 넣고, 모든 사람과 AI가 그 규범에 따라 작업하게 했는지 여부다.

이것이 없다면 아무리 좋은 도구라도 팀이 더 빠른 속도로 더 많은 기술 부채를 쌓게 할 뿐이다.

이 내용을 2026년 상반기 대규모 배포 관점에서 보면 근거가 더 확실해진다. Microsoft는 2026년 7월 FY26 회고록에서 EY와 Atos 사례를 “Frontier Firm” 템플릿으로 정리했다. 모델이 새로워서가 아니라, 두 기업 모두 “AI를 어떻게 쓸 것인가”라는 질문에 먼저 답을 했기 때문이다.

EY: 거버넌스 선행, 규모화로 성과 실현. EY는 2024~2025년에 Microsoft 365 Copilot을 15만 명에게 배포했고, 250만 시간과 약 2억 5천만 달러를 절감했다. 전제는 “AI 거버넌스 프레임워크를 먼저 구축”한 것이다. EY는 Power Platform, Copilot Studio, Azure, Foundry, Fabric을 활용해 통합 툴체인을 만들고, 규범·컴플라이언스·감사를 단일 기반 위에 올렸다. 그 덕분에 이후 95%의 속도 향상, 37%의 재무 운영 비용 절감, 최대 90%의 수작업 워크플로우 감소가 가능했다. EY 부사장은 2026 AI Tour에서 아주 직접적으로 말했다. “우리는 AI를 먼저 깔고 거버넌스를 나중에 보강한 게 아니다. 거버넌스를 먼저 갖추고 AI를 배포했다.”

Atos: 19,000개 에이전트를 위한 단일 제어 평면. Atos는 Microsoft 365 E7(Frontier Suite)을 도입한 세계 최초의 조직 중 하나로, 54개국 56,000명의 직원에게 Copilot을 배포했습니다. 현재 19,000개의 AI 에이전트를 동시에 운영 중이며, 내부 IT, 비즈니스 부서, 고객 프로젝트 전반에 걸쳐 Foundry와 Copilot Studio를 활용해 에이전트를 구축하고 있습니다. Atos가 이를 성공시킨 핵심은 “단일 제어 평면”입니다. Entra(아이덴티티) + Defender(보안) + Intune(디바이스) + Purview(컴플라이언스) + Agent 365(에이전트 거버넌스)라는 다섯 가지 요소를 하나로 묶은 구조입니다. 이러한 결합 방식은 금융 업계의 관점에서 보면 “ISMS-P 인증 + PIPA 국외이전 통지(PIPC 신고) + AI Basic Act 고위험 AI 등급 등록 + 감사 + 모델 거버넌스”에 해당하는, 단순한 AI 도구가 아닌 거버넌스 아키텍처입니다.

Microsoft의 ‘조직 변화 패러독스’. Microsoft는 2026 Work Trend Index 보고서에서 스스로 인정했습니다. **”조직 변화의 속도가 개인 사용을 따라가지 못하고 있다”**는 사실입니다. 이들이 조사한 20,000명의 AI 사용자 중 82%의 리더가 12~18개월 내에 AI 에이전트로 노동력을 확장할 계획이라고 답했지만, 실제로 기업 차원의 배포를 완료한 곳은 24%에 불과했습니다. 81%의 리더가 AI 에이전트가 AI 전략에 중간~대규모로 통합될 것이라고 예상했지만, 역시 실제로 실행에 옮긴 기업은 24%에 그쳤습니다. 즉, 대다수 기업이 ‘준비’와 ‘실행’ 사이에 12~18개월의 간극을 안고 있으며, 이 간극을 어떻게 메우느냐가 관건입니다. 그 중심에는 규범(governance) 주도 접근법이 자리잡고 있습니다.

출처: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, PDF 1차 소스); Futurum Group 2026.1.26 분석 (2차 소스).

시사점 1: 규범에 대한 투자는 ROI가 높다.

CodeRabbit의 데이터는 ROI 계산의 명확한 근거를 제시한다. AI 코드 문제 발생률이 약 1.7배, 보안 취약점이 2.74배 감소한다는 것이다. 이는 다음을 의미한다:

더 적은 재작업(금융업에서 컴플라이언스 심사 재작업은 2~4주 소요)
더 적은 보안 사고(데이터 유출 사고 시 규제 벌금, 평판 손실)
더 낮은 유지보수 비용(기술 부채 40% 감소는 흔한 수치)

CLAUDE.md/AGENTS.md 프로젝트 규범을 작성하는 것은 AI 시대에 ROI가 가장 높은 엔지니어링 행동이다. EY의 사례는 실제 수치로 환산된 결과를 보여준다 — 15만 명에게 Copilot을 배포하여 2억 5천만 달러를 절감했다. 주목할 점은 EY가 “도구가 뛰어나서” 절감한 것이 아니라, “규범이 도구의 가치를 실제 성과로 전환시켰기 때문”이라는 것이다.

시사점 2: 규범을 개인 의존이 아닌 조직 프로세스로 내재화하라.

규범이 특정 시니어 엔지니어의 머릿속에만 존재하면, 인력이 이동하는 순간 사라진다. 반드시 다음에 체계화해야 한다:

저장소 문서(AGENTS.md / CLAUDE.md / constitution.md)
CI 게이트(규범 준수 여부 자동 검증)
팀 공유 설정(Skills 시스템을 통해 전 팀이 활용 가능)

규범을 개인의 스킬이 아닌 조직의 자산으로

이것은 금융 업계에서 특히 중요합니다——컴플라이언스 요구사항, 보안 규칙, 업무 규칙은 모두 조직 차원의 자산이지, 특정 엔지니어의 ‘경험’이 아닙니다. Atos의 19,000개 에이전트가 54개국에서 운영될 수 있는 이유는 거버넌스가 ‘누군가 알고 있는 것’이 아니라 ‘시스템이 강제하는 것’이기 때문입니다.

세 번째 교훈: 게이팅(gating)이 속도보다 중요하다.

GitHub Spec Kit의 5단계 게이팅(constitution → specify → plan → tasks → implement), Claude Code의 ‘테스트 실패 전에는 코드를 작성하지 않는다’는 원칙, Kiro의 ‘spec 없이는 시작 불가’ 정책——이 모든 것은 AI와 최종 산출물 사이에 ‘브레이크’를 설치하는 동일한 작업을 하고 있습니다. 각 단계마다 검토 가능한 산출물(spec.md, plan.md, tasks.md)이 존재하며, 코드 생성 전에 거부하거나 수정할 수 있습니다.

자율성이 높은 AI일수록 게이팅이 더 필요하다. 금융 업계의 변경 승인 위원회(Change Advisory Board, CAB), AI Basic Act 고위험 AI 등급 등록 절차, ISMS-P 인증 평가(KISA 심사)는 본질적으로 프로덕션 배포 전에 게이팅을 추가하는 것입니다. AI 코드에도 유사한 게이팅이 필요하지만, 형태는 다를 뿐입니다. New Relic 2026 보고서에서 ‘자신 있게 검토 없이 배포한다’고 답한 62%의 팀은 더 높은 장애율(78%)로 이 같은 자신감에 대가를 치르고 있습니다.

1단계가 가장 시간이 걸리지만 ROI가 가장 높음
대부분 금융 조직의 규칙은 문서/이메일/머릿속에 흩어져 있으며, 첫 정리는 3-8주 투자

4. 2026년 상반기, 실제 도입을 위한 3단계 접근법

금융업을 기준으로 한 3단계 로드맵이며, 규제가 엄격한 다른 업종에서도 동일하게 적용할 수 있다. EY와 Atos가 2026년 상반기에 실제로 수행한 방식도 정확히 이 3단계와 맞아떨어진다.

1단계: 규칙 인벤토리 구축 (2~4주)

가장 시간이 걸리지만 ROI가 가장 높은 단계다. 여기저기 흩어져 있는 규칙들을 발굴한다:

컴플라이언스 요건: 금융업의 최소 기준 = ISMS-P 인증(정보보호 및 개인정보보호 관리체계, KISA 심사) + PIPA 국외이전 통지(PIPC 신고 필요) + AI Basic Act 고위험 AI 등급 등록(2026.1 시행) (세 가지 중 하나라도 빠지면 AI 도입을 논할 수 없다). 여기에 더해 규제 보고 규칙, 고객 정보 보호, 데이터의 역외 이전 제한, AI에 어떤 데이터를 노출할 수 있는지에 대한 기준까지 포함된다.
보안 규칙: 비밀번호 관리, 암호화 표준, 민감 필드 처리, 로그 요건
비즈니스 규칙: 리스크 관리 임계값, 보험금 지급 조건, 거래 한도, 과금 로직
기술 제약: 레거시 시스템 인터페이스, 데이터베이스 네이밍 규칙, 프레임워크 버전 제한
공급업체 거버넌스: 계약서에 공급업체가 우리 표준을 따르도록 요구하는 방법, 공급업체의 AI 사용을 감사하는 방법

일반적인 시나리오: 한 증권사가 정리 단계에서 규칙이 수많은 Word 문서, JIRA wiki, 개인 이메일, Excel 표에 흩어져 있다는 것을 발견했다—정리한 후에야 구조화된 규칙 목록을 얻을 수 있었다. Atos의 접근 방식은 더 체계적이다—그들은 규칙을 “컴플라이언스, 보안, 비즈니스, 기술, 공급업체” 다섯 가지로 분류하고, 각각 하나의 거버넌스 워크플로우로 만들어 Agent 365의 컨트롤 플레인에 통합했다.

이것은 기술적인 작업이 아니라 조직적인 작업이다—컴플라이언스 부서, 보안 부서, 비즈니스 부서를 한자리에 모아 모두가 동의하는 규칙을 문서로 작성해야 한다. 처음 이 작업을 수행할 때 금융 조직은 보통 3-8주가 걸린다—하지만 이것은 영구적인 조직 자산이다.

2단계: 저장소에 반영 (1-2주).

1단계에서 정리한 규칙을 문서로 작성하여 저장소에 넣는다. GitHub Spec Kit는 constitution.md를 사용하고, Claude Code는 CLAUDE.md를, OpenAI Codex는 AGENTS.md를, Alibaba Qoder는 Spec Workflow를 사용한다. 파일 이름은 다르지만 목표는 동일하다—AI가 저장소를 여는 순간 규칙을 로드하도록 하는 것이다.

구조 제안 (2026 H1 기준 주류 형태)

프로젝트 개요: 이 시스템이 무엇을 하는지, 누구를 위한 것인지
불가침 원칙: 보안 레드라인, 컴플라이언스 레드라인, 비즈니스 레드라인
기술 스택 및 제약 조건: 어떤 프레임워크, 어떤 데이터베이스, 어떤 인터페이스 규격을 사용하는지
코드 규범: 네이밍 컨벤션, 디렉터리 구조, 테스트 최소 커버리지 요건 (TDD 리듬을 강제하지 않음 — 테스트 커버리지, 필수 테스트 경로, 금지 경로만 명확히 기술하면 됨. TDD는 조직이 선택할 수 있는 리듬이지, 규범으로 강제할 사항이 아님)
비즈니스 규칙: 리스크 관리 로직, 거래 규칙, 과금 규칙
컴플라이언스 요구사항: 정보보호 등급 평가, 데이터 해외 이전, 규제 보고, AI 생성 알고리즘의 사전 등록 필요 여부
AI 사용 규범: 어떤 시나리오에서 AI를 쓸 수 있고, 어떤 시나리오에서 반드시 사람의 검토가 필요한지, 데이터 해외 이전 규칙
공급업체 거버넌스: 계약 조건, 감사 메커니즘, 책임 소재 구분

부록: CLAUDE.md 금융 버전 스켈레톤 (약 200줄, 바로 fork해서 커스터마이징 가능)

다음은 주식회사형 은행의 코어 시스템 개편을 위한 CLAUDE.md 스켈레톤으로, “불가침 원칙 → 컴플라이언스 요구사항 → AI 사용 규범 → 비즈니스 규칙 → 엔지니어링 제약 조건” 순서로 구성되어 있습니다. 여러분 회사는 처음부터 시작할 필요가 없습니다 — 빈 칸에 여러분의 구체적인 규칙만 채워 넣으면 됩니다.

# CLAUDE.md — <시스템명> AI 협업 규범

> 적용 범위: <시스템명> v<버전>, 모든 AI 에이전트(Claude Code / Cursor / Copilot / Codex)
> 본 저장소에서 작업할 때 반드시 본 규범을 준수해야 합니다. 본 문서는 <거버넌스 위원회>에서 유지·관리하며, 분기별 심의를 거칩니다.
> 최종 업데이트: YYYY-MM-DD

## 1. 프로젝트 개요
- **업무 포지셔닝**: 코어 시스템명 / 서비스 고객군 / 주요 거래 유형
- **핵심 링크**: 거래 → 리스크 관리 → 청산 → 대사(對帳) → 보고
- **사용 불가 윈도우**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (어떤 변경도 진입 금지)
- **핵심 의존성**: 업스트림 <시스템>, 다운스트림 <시스템>, 규제 보고 플랫폼

## 2. 비협상 원칙 (레드라인, 위반 시 병합 거부)

### 2.1 보안 레드라인
- 비밀번호, 키, Token은 일률적으로 KMS(키 관리 서비스)를 경유, **하드코딩 금지**, **로그 인쇄 금지**
- 고객 민감 필드(신분증 / 카드번호 / CVV / 휴대폰번호) **반드시 암호화 저장**, 평문은 데이터베이스 저장 금지
- 로그에 등재 금지 항목: 완전한 신분증, 완전한 카드번호, 평문 비밀번호, 고객 이름+휴대폰번호 조합
- 외부 인터페이스 호출은 반드시 API 게이트웨이를 경유, 직접 연결 금지

### 2.2 컴플라이언스 레드라인
- AI 생성 코드가 고객 데이터 접근을 수반할 경우, 반드시 PR 설명에 "데이터 접근: <필드>" 명기
- 국경 간 데이터 전송(跨境数据传输) 금지, **모든 데이터出境은 데이터出境 평가 프로세스(국경 간 데이터 전송 평가)를 거쳐야 함** (컴플라이언스 부서 연락)
- 알고리즘 의사결정(신용 대출 / 보험 가격 산정 / 부정 결제 방지)은 반드시人工复核(인간 재검토) 입구 유지
- 모델 변경은 알고리즘 등록(알고리즘 등록) 절차를 거쳐야 하며, 등록 번호는 반드시 PR 설명에 인용

### 2.3 업무 레드라인
- 리스크 관리 임계값 변경은 리스크 관리 책임자 + 업무 책임자 이중 서명 필요
- 고객 자금 관련 작업은 반드시 멱등성 설계 + 실패 롤백 필수
- 거래 한도, 요율, 제품 파라미터 변경은 파라미터 관리 플랫폼을 거치며, 코드 내 하드코딩 금지

## 3. 기술 스택 및 제약
- **언어**: Java 17(코어) / Kotlin(신규 모듈) / SQL(데이터베이스)
- **프레임워크**: Spring Boot 3.x + Spring Cloud Alibaba
- **데이터베이스**: OceanBase 4.x(MySQL 호환 모드), **외래 키 사용 금지**
- **인터페이스 규범**: 내부 일률적으로 gRPC; 외부 인터페이스 OpenAPI 3.0; RESTful은 관리 클래스 인터페이스에 한정
- **명명 규약**: Java 클래스 PascalCase, 메서드 camelCase, 상수 UPPER_SNAKE; 테이블명 `t_<업무 도메인>_<엔티티>`; 인덱스 `idx_<테이블>_<필드>_<순서>`
- **패키지 구조**: `com.<회사>.<업무 도메인>.<서브 도메인>.<레이어>` (예: `com.bank.pay.tx.core.service`)

## 4. 코드 표준
- **최소 테스트 커버리지**: 핵심 링크 ≥ 80%, 유틸리티 클래스 ≥ 60%, 신규 코드 PR은 반드시 테스트 포함
- **필수 테스트 경로**: 모든 controller는 반드시 통합 테스트 필요(실패 경로 포함); 모든 enum 분기는 반드시 단위 테스트 필요
- **금지 경로**: `<역사包袱 모듈>` 디렉터리 수정 금지 — 먼저 어댑터 레이어 구축 필요
- **의존성 관리**: 신규 제3자 의존성은 SCA 스캔 + 보안 승인 필수

## 5. 업무 규칙 (도메인별)
### 5.1 거래
- 1회 한도: <금액>; 1일 한도: <금액>; 한도 초과 시人工 승인(人工审批) 필요
- 거래 시간 윈도우: <HH:MM> ~ <HH:MM>
- 중복 거래 판정: <시간 윈도우> 내 동일 <필드>는 중복으로 간주

### 5.2 리스크 관리
- 블랙리스트 매칭 우선순위: 내부 블랙리스트 → 규제 하달 명단 → 사법 동결
- 부정 결제 방지 모델 출력 임계값: <점수>; 초과 시 반드시人工 이차 심사(人工二审) 필요

### 5.3 과금
- 요율 변경은 반드시 버전 번호 +生效 시간(발효 시간) 필요
- 과거 주문은 발효 시점의 요율로 계산, 소급 적용 안 함

## 6. 컴플라이언스 요구사항
- 등보三级(MLPS 레벨 3): <평가 기관>, <차기 평가 일자>
- 데이터出境 평가(국경 간 데이터 전송 평가): 적용 범위(국경 간 업무 모듈에 한정)
- 알고리즘 등록(알고리즘 등록): 적용 범위(신용 대출 / 보험 가격 산정 등 핵심 알고리즘), 등록 번호 `<번호>`
- 규제 보고(규제 보고): <CBIRC / 중국 인민은행> 필드 매핑 테이블은 `<경로>`에 위치

## 7. AI 사용 규범
- **AI 사용 가능 시나리오**: CRUD 보일러플레이트, 단위 테스트 생성, 문서 초안, SQL 최적화 제안
- **人工 심사(人工审查) 필수 시나리오**: 리스크 관리 로직, 과금 규칙, 권한 제어, 암복호화, 국경 간 데이터
- **AI 단독 수행 금지 시나리오**: CAB(변경 자문 위원회) 심사 자료, 생산 변경 실행, 응급 대응
- **데이터出境 규칙**: 학습 데이터 / 프롬프트 / 출력 로그 일체出境 불가; 현지화 배포 버전(<벤더>) 우선
- **감사 요구사항**: 모든 AI 생성 코드는 PR 설명에 "AI 보조: <도구명>" 표시 필수

## 8. 공급업체 거버넌스
- **공급업체 진입**: SOC 2 / ISO 27001 보고서 제공 필수; AI 모델은 모델 카드 제공 필수
- **계약 조항**: 데이터 귀속, 모델 해석 가능성, 탈퇴 조항, 감사권
- **감사 메커니즘**: 분기별 공급업체 AI 사용 감사; 고위험 공급업체는 월간 감사

## 9. 거버넌스 및 업데이트
- **소유자**: <거버넌스 위원회>(컴플라이언스 + 보안 + 아키텍처 + 업무)
- **업데이트 빈도**: 분기 심의; 긴급 변경은快速 통로(双签 + 24h 공시) 경유
- **변경 로그**: `CLAUDE_CHANGELOG.md` 참조
- **위반 처리**: 첫 위반 = 경고 +强制培训(강제 교육); 2차 위반 = AI 도구 사용 정지; 3차 = 권한 취소

이 뼈대는 “정답”이 아니라 “빈칸 채우기 템플릿”입니다. 각 빈칸에 무엇을 넣을지가 분량보다 중요합니다——빈칸이 드러내는 것은, 바로 우리 회사가 “아직 제대로 정리하지 못한” 부분입니다.

전형적인 사례: 한 주식회사형 은행(중국 상업은행)의 CLAUDE.md에는 비밀번호 처리 규칙이 명시되어 있습니다——AI가 생성한 코드에 비밀번호가 포함될 경우 반드시 내부 키 관리 API를 호출해야 하며, 하드코딩을 금지합니다. 이런 유형의 규칙은 컴플라이언스 심사에서 반려되는 사유 중 상당한 비중을 차지합니다.

2026년 상반기의 중요한 새 필드는 Skills/워크플로 정의입니다——단순한 문서가 아니라, AI가 호출할 수 있는 도구 체인입니다. Claude Code의 Skills 시스템(2026년 2월 Anthropic 공식 마켓에 등록, GitHub 11.2만 stars)은 “Excel 읽기”, “SQL 생성”, “데이터 마이그레이션 실행” 같은 작업들을 공유 가능한 워크플로로 전환합니다. 이것이 2026년 상반기 규범 기반 접근법의 핵심 진화입니다: 규범은 단순한 제약이 아니라, 실행 가능한 워크플로입니다.

3단계: 제도화(지속).

规范 작성이 끝이 아니라 시작이다. 이를 조직의 프로세스로 만들어야 한다:

CI 게이트 통합: 코드가 규범을 준수하는지 자동 검사(예: 하드코딩된 비밀번호, 민감 필드 미암호화 탐지)
팀 공유 설정: Skills 시스템을 활용해 전 팀이 동일한 규범을 사용
정기 업데이트 메커니즘: 규칙이 바뀌면 규범도 따라 바뀌어야 함(분기별 검토)
측정 및 피드백: AI 코드의 결함률, 컴플라이언스 심사 통과율, 재작업률 추적
에이전트 거버넌스: 사람에 대한 거버넌스를 AI 에이전트로 확장 — Atos가 Agent 365에서 한 것은 이를 “개인 수준”이 아닌 “시스템 수준”으로 만든 것이다

EY와 Atos는 2026년 상반기에 모두 3단계를 “조직 역량”으로 규정했다. EY의 250만 시간 절감은 1단계와 3단계를 제대로 수행했기 때문이다 — 2단계는 단지 규칙을 AI가 읽을 수 있는 문서로 번역한 것에 불과하다.

5. 강규제 변형: 컴플라이언스를 내장하는 세 가지 엔지니어링 방식

금융, 통신, 의료 등 강규제 산업에서는 규범 기반 도입이 일반 산업보다 한 단계 더 까다롭다 — 컴플라이언스는 프로세스의 부가 기능이 아니라 코드에 내장되어야 한다. 아래 세 가지 방식은 2026년 상반기에 검증된 컴플라이언스 내장 방법으로, CIO/디지털 책임자가 조직 설계 시 바로 참고할 수 있다.

5.1 스트림 팀 내 컴플라이언스 담당자 임베드: ‘사후 승인’이 아닌 ‘현장 상주’로

기존 방식은 비즈니스 팀이 코드를 작성하고 컴플라이언스 팀이 사후에 검토하는 구조였다. 문제는 검토에서 이슈가 발견됐을 때 이미 코드가 배포된 지 2주가 지났고, 재작업에 2~4주가 추가로 소요된다는 점이다. 핵심 문제는 컴플라이언스가 프로세스의 맨 끝에 위치한다는 것이다.

새로운 접근법은 각 스트림 정렬 팀(stream-aligned team)에 컴플라이언스 담당자를 상주시키는 것이다. 보고 체계는 ‘실선은 컴플라이언스 부서, 점선은 비즈니스 팀’으로 하는 이중 보고 구조를 따른다. 구체적인 설계는 다음과 같다.

인력 배치: 컴플라이언스 담당자 1명당 스트림 팀 6~8개를 담당한다. 소속은 컴플라이언스 부서이되, 물리적 자리는 비즈니스 팀에 둔다. 출장식 ‘파견’이 아니라 상주가 원칙이다.
점선 KPI: 컴플라이언스 담당자의 KPI 중 50%는 비즈니스 팀의 ‘컴플라이언스 결함률’과 ‘검토 1회 통과율’에 연동된다. 단순히 컴플라이언스 부서의 ‘감사 커버리지’만 보는 것이 아니다.
조기 개입: 컴플라이언스 담당자는 데일리 스탠드업(주 1회면 충분), PR 검토에 참여하며, AI가 생성한 코드는 병합(merge) 전에 반드시 컴플라이언스 담당자의 확인을 거쳐야 한다. 병합 후에 문제가 발견되어 뒤늦게 보완하는 구조가 아니다.
도구 지원: 컴플라이언스 담당자는 컴플라이언스 체크리스트를 Skills로 호출해 활용하며, 수작업으로 항목을 일일이 대조하지 않는다.

5.2 컴플라이언스를 enabling team으로: 제약을 affordance로 바꾸기

전통적인 방식에서는 컴플라이언스 팀이 ‘게이트키퍼’ 역할을 하고, 비즈니스 팀은 컴플라이언스를 ‘문제를 만드는 존재’로 여긴다. 양측은 제로섬 게임을 하게 된다.

새로운 접근법은 이렇다. 컴플라이언스 팀을 Team Topologies의 enabling team 모델로 재구성하는 것이다. 코드를 직접 작성하지도 않고, PR을 직접 리뷰하지도 않지만, 비즈니스 팀이 ‘셀프 컴플라이언스’를 할 수 있도록 세 가지를 제공한다.

5.3 이중 속도 컴플라이언스: 비즈니스 템포에 맞춘 계층화 전략

CI 파이프라인 내 컴플라이언스 게이트: 하드코딩된 비밀번호, 민감 필드 평문 저장,跨境 데이터 전송, 알고리즘 의사결정 지점 등 고빈도 컴플라이언스 이슈를 GitHub Actions / GitLab CI의 강제 게이트로 구현한다. 비즈니스 팀의 PR이 트리거되면 자동 검사가 실행되고, 미준수 시 즉시 fail 처리된다 — 컴플라이언스 담당자가 수동으로 검토할 필요가 없다.
규제 요구사항을 affordance(환경 반응형 제약)로 전환: 예를 들어, 고객 데이터를 다루는 기능을 개발할 때 IDE 플러그인이 “이 필드는 KMS 호출을 권장합니다”라는 힌트를 띄우고, 로그 작성 시 민감 정보 포함 여부를 자동 감지하여 경고를 발생시킨다. 컴플라이언스 요구사항이 “개발 중 자연스럽게 발생하는 동작”이 되는 것이지, “배포 직전에 무엇을 위반했는지 통보받는 것”이 아니다.
공유 Skills 라이브러리 + 컴플라이언스 교육: 컴플라이언스 팀이 “컴플라이언스 Skills” 집합을 유지 관리하고, 신규 입사자나 크로스 팀 전환 시 바로 활용할 수 있게 한다 — 컴플라이언스 지식을 “문서”에서 “실행 가능한 도구”로 전환하는 것이다.

대표 사례: 한 지방은행이 2026년 상반기에 CI 컴플라이언스 게이트 + IDE 컴플라이언스 힌트를 도입하여, AI 코드 컴플라이언스 검토의 1인당 소요 시간을 건당 45분에서 8분으로 단축했다. **핵심은 컴플라이언스 “검토가 빨라진 것”이 아니라, AI가 생성할 때부터 “실수를 하지 않는 것”**이다.

마지막으로 짚을 디테일 하나: 컴플라이언스를 “무조건 일괄 적용”하면 안 된다. 규칙을 위험 등급에 따라 두 단계로 나누자.

고위험 규칙(고객 자금 / 알고리즘 의사결정 / 역외 데이터 이동 / ISMS-P 인증 + PIPA 국외이전 통지 기준)은 엄격한 게이트를 적용한다: 반드시 인간 검토 + AI 2차 확인 + CAB(Change Advisory Board) 등록
저위험 규칙(CRUD 템플릿 / 도구성 코드 / 문서 생성)은 셀프서비스 게이트를 적용한다: CI 자동 검사만으로 충분, 인간 검토 불필요

Atos의 Agent 365 컨트롤 플레인도 본질적으로 이렇게 계층화되어 있다 — 에이전트 등급에 따라 서로 다른 거버넌스 요구사항을 바인딩한다. 컴플라이언스 규칙을 위험도에 따라 계층화하면, 비즈니스 팀이 “컴플라이언스가 우리를 여기저기서 옥죄는구나”라는 느낌을 덜 받게 된다.

이 세 가지를 종합하면: 컴플라이언스 임베딩은 단순히 프로세스 하나를 추가하는 것이 아니라, 팀의 구조와 인센티브를 재설계하는 일이다. 컴플라이언스 부서가 여전히 “사후 심사” 모드에 머물러 있다면, 규범 기반 적용은 가장 어려운 “제도화” 단계에서 막힐 수밖에 없다 — 컴플라이언스 부서가 먼저 전환해야, 비즈니스 팀의 규범 기반 적용이 순조롭게 돌아간다.

6. 궁금할 법한 질문들

“우리도 이미 코딩 규범이 있는데, 이거랑 뭐가 다른가요?”

코딩 규범은 “코드를 어떻게 작성할지”를 다루고, 규범 기반 적용은 “AI와 어떻게 협업할지”를 다룬다. 코딩 규범에는 다음이 포함되지 않는다: 비즈니스 규칙, 컴플라이언스 요구사항, AI 사용 전략. 규범 기반 적용은 “인간과 AI의 협업 전체 프로세스”를 명시화하는 것이지, 코드 스타일 가이드가 아니다.

“규범을 작성하면 개발 속도가 떨어지지 않나요?”

단기적으로는 그렇습니다. 하지만 장기적으로는 오히려 빨라집니다. CodeRabbit의 데이터가 명확한 답을 줍니다. 제약 없는 AI 코드는 결함 위험이 약 1.7배, 보안 취약점 위험이 2.74배 높습니다. 금융 업계에서 컴플라이언스 심사 한 번에 따른 재작업은 2~4주가 걸립니다. 재작업 한 번을 줄이면 한 달 치 규범을 작성할 시간이 생깁니다. EY가 2억 5천만 달러를 절감한 사례는 이걸 조직 역량으로 만든 실제 증거입니다.

“우리 팀에 규범을 작성할 사람이 없으면 어떻게 하나요?”

처음부터 시작할 필요가 없습니다. GitHub Spec Kit, Claude Code Superpowers, AWS Kiro에는 이미 템플릿이 있습니다. 조직 고유의 규칙만 채워 넣으면 됩니다. 대부분은 컴플라이언스와 보안 규칙인데, 이런 건 규정 준수 부서와 보안 부서가 이미 작성해 두었습니다. 단지 AI가 접근할 수 있는 곳에 두지 않았을 뿐입니다.

“AI 도구가 너무 많은데 어떤 걸 선택해야 하나요?”

중요하지 않습니다. 이미 쓰고 있는 걸 선택하세요. 규범 중심이라 도구에 얽매일 필요가 없습니다. CLAUDE.md는 Claude Code, Cursor, Codex에서 모두 동작하고, AGENTS.md는 OpenAI 생태계에서 실행되며, constitution.md는 모델과 무관합니다. 핵심은 도구를 바꾸는 게 아니라 규범을 작성하는 겁니다. EY도 Atos도 Microsoft 생태계에서 확산하고 있습니다. 도구 선택의 차이는 표면적일 뿐이고, 거버넌스 구조의 통일성이야말로 본질입니다.

“2026년 8월에 EU AI Act가 전면 시행되는데, 우리에게도 영향이 있을까요?”

있습니다. EU AI Act는 2026년 8월 2일부터 전면 시행 단계에 돌입하며, 고위험 AI 시스템(신용·보험 가격 산정, 채용 심사, 핵심 인프라 포함)에 대해 강제적 준수 요건을 부과합니다 — 위험 관리(Art. 9), 데이터 거버넌스(Art. 10), 문서 투명성(Art. 11–13), 인간 감독(Art. 14), 정확성·견고성(Art. 15)이 그것입니다. 위반 시 과징금은 최대 3,500만 유로 또는 글로벌 매출의 7%에 달합니다. 중국에서 해외로 진출하는 기업에게 EU 시장은 반드시 풀어야 할 과제이고, 국내 기업에게도 EU AI Act의 프레임워크는 전 세계에서 가장 많이 참조되는 기준입니다. 직접 적용 대상이 아니더라도 공급업체, 파트너, 해외 사업을 통해 전이되는 영향(transmission effect)을 피해가기는 어렵습니다 (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“국내 대조: EU는 AI를 규제하는데, 우리는 무엇을 규제하나?”

국내의 생성형 AI 규제는 ‘알고리즘 등록 + 말뭉치 검토 + 안전성 평가’라는 세 가지 축으로 운영되며, 2023년 8월 시행된 《생성형 인공지능 서비스 관리 잠정 조치》가 핵심 근거입니다. 양측의 가장 큰 차이는 조문의 세밀함이 아니라 입법 철학에 있습니다.

차원	EU AI Act	중국 <생성형 AI 서비스 관리 방법>
법적 성격	수평 규제(모든 AI 시스템에 적용)	수직 규칙(생성형 AI 서비스에 초점)
위험 등급	4단계(허용 불가 / 고위험 / 제한적 / 최소)	2단계(여론 안전 관련 / 일반 상업용)
규제 시점	사전 규제(개발 단계에서 등록)	사후 규제(서비스 출시 후 등록 + 알고리즘 등록)
투명성	높음(학습 데이터 출처 요약, 모델 카드 공개 의무)	중간(데이터 컴플라이언스 요구하되 출처 공개는 강제하지 않음)
벌칙 상한	글로벌 매출의 7% 또는 3,500만 유로	서비스 중단 / 벌금(일반적으로 위법 소득의 배수)
적용 범위	글로벌 매출 기준을 충족하는 모든 기업	중국 내에서 서비스를 제공하는 모든 주체

실무적으로 국내 금융기관의 AI 시스템은 대개 세 가지 규제 체계를 동시에 적용받는다—— 「AI Basic Act(인공지능기본법, 2026.1 시행)」(기반 계층) + 「상업은행 인터넷 대출 관리 잠정 조치」(업무 계층) + 「ISMS-P 인증 + PIPA 국외이전 통지 + PIPC 신고」(컴플라이언스 계층). 이는 국내에서 규범 기반 개발을 할 때 EU AI Act의 프레임워크를 그대로 가져올 수 없음을 의미한다. 국내의 “코퍼스 컴플라이언스 + 알고리즘 등록 + 규제 보고”라는 세 가지 축을 전부 CLAUDE.md에 반영해야 한다.

해외 진출 기업의 관점에서 보면: EU AI Act의 “위험 관리 + 데이터 거버넌스 + 문서 투명성 + 인간 감독”이라는 네 가지 축은 중국 규제도 점진적으로 정렬하고 있는 방향이다——2025년 중국 인터넷정보판공실(CAC)의 생성형 AI 등록 피드백을 보면 이미 EU 수준의 세분화(granularity)를 상당 부분 참조했다. 오늘 EU AI Act 호환 규범을 작성해 두면, 향후 3년간 중국의 규제 강화 기조와도 대체로 호환될 가능성이 높다(CAC 등록 공고 2025-2026; EU AI Act compliance 2026.6).

7. 의사결정자를 위한 시사점

시사점 1: CLAUDE.md/AGENTS.md 프로젝트 규범을 작성하는 것은 AI 시대에 ROI가 가장 높은 엔지니어링 조치다.

교훈 2: 규범 주도는 조직 역량이지, 도구 선택의 문제가 아니다.

GitHub Spec Kit을 쓰든 Claude Code를 쓰든 중요한 건 아니다. 중요한 건 “우리 조직이 AI와 어떻게 협업할 것인가”를 정의했는지다. 이게 없으면 아무리 좋은 도구도 팀이 더 빠른 속도로 더 많은 기술 부채를 쌓게 만들 뿐이다.

교훈 3: 규범을 개인에게 의존하지 말고 조직 프로세스로 제도화하라.

규범이 시니어 엔지니어 한 명의 머릿속에만 존재하면, 인력이 이동하는 순간 사라진다. 반드시 리포지토리 문서, CI 게이트, 팀 공유 설정, 에이전트 거버넌스 플랫폼에 체화시켜야 한다. 규범을 개인의 스킬이 아닌 조직의 자산으로 만들어라. Atos의 19,000개 에이전트가 54개국에서 문제없이 작동하는 이유는 거버넌스가 “누군가 알고 있는 것”이 아니라 “시스템이 강제하는 것”이기 때문이다.

교훈 4: 속도보다 게이트가 우선이다.

GitHub Spec Kit의 5단계 게이트(gate), Superpowers의 “테스트가 실패하기 전에는 코드를 쓰지 않는다”는 원칙, Kiro의 “스펙 없이는 시작할 수 없다”는 규칙 — 이 모든 것은 AI와 최종 산출물 사이에 ‘브레이크’를 걸어두는 장치다. AI의 역량이 강해질수록 거버넌스가 더 앞서야 한다. New Relic 2026 보고서의 78% 장애율은, 62%의 팀이 “검토 없이 배포”한 대가다. 금융 업계의 CIO라면 이걸 가장 잘 이해할 것이다. 여러분의 변경 자문 위원회(Change Advisory Board), AI Basic Act 고위험 AI 등급 등록 절차, ISMS-P 인증(KISA 심사) 평가는 모두 프로덕션 배포 전에 게이트를 거는 장치다. AI 코드에도 동일한 게이트가 필요하며, 더욱이 더 앞단에 배치되어야 한다.

역방향 자가 점검(미화하지 말 것): AI가 생성한 코드에 대한 컴플라이언스 검토가 자주 반복되고 있는가? 최근 AI 코드로 인해 발생한 장애는 무엇인가? 기술 책임자에게 “우리는 AI와 어떻게 협업하는가”라고 물었을 때, 그가 문서 하나를 꺼내 보여줄 수 있는가? 세 가지 중 하나라도 답이 막힌다면, 규범 주도 개발이 아직 정착되지 않았다는 뜻이다 — 규범을 먼저 쓰고, 그다음 도구를 도입하라.

의사결정자를 위한 세 가지 코칭 질문

마지막으로 세 가지 질문을 남긴다. 체크리스트가 아니라, 팀과 논의할 때 바로 활용할 수 있는 질문이다.

“만약 내일 모든 AI 도구가 사라진다면, 우리 팀의 코드 품질은 얼마나 떨어질까?” — 이 질문이 드러내는 것은 규범(規範) 기반 접근법의 실제 가치입니다. 만약 답이 “크게 떨어진다”라면, 아직 규범이 팀에 제대로 내재화되지 않았다는 뜻입니다. 반대로 “거의 변함없다”면, 규범 기반 개발이 이미 자리 잡았다는 방증입니다.
“컴플라이언스 부서는 우리의 규범 기반 프로젝트에서 ‘게이트키퍼’인가, 아니면 ‘조력자(enabler)’인가?” — “게이트키퍼”라는 답이 나온다면, 검토 병목으로 인해 실행 속도가 막히게 됩니다. “조력자”라는 답이 나온다면, 5.2절에서 제시한 방향으로 이미 올바르게 나아가고 있는 것입니다.
“12~18개월 후, 우리 팀 규모는 어떻게 변할까?” — Microsoft WTI 2026 보고서에 따르면, 리더의 82%가 AI 에이전트를 통해 인력을 ‘확장’할 것이라고 답했습니다. 만약 “변함없다”는 답이 나온다면, 사업이 성장하지 않고 있거나, 조직 설계가 규범 기반 접근법이 가져다주는 이점을 따라가지 못하고 있다는 신호입니다.

이 세 가지 질문에 정답은 없습니다. 하지만 답의 방향성은 답 자체보다 더 중요합니다.

다음 단계

이 글은 “AI 시대 소프트웨어 엔지니어링의 변화” 시리즈의 여섯 번째 편입니다. Conway의 법칙(조직이 아키텍처를 결정한다)에서 시작해 Team Topologies(조직을 어떻게 설계할 것인가), 병목의 이동(병목은 코딩이 아닌 검증에 있다)을 거쳐, 오늘은 규범 기반 접근법(문서로 AI의 행동을 제약하기)까지 다루었습니다.

다음 편(일곱 번째)에서는 이 모든 것을 뒷받침하는 기반 인프라——**MCP 프로토콜(Model Context Protocol)**을 살펴봅니다. Anthropic이 오픈소스로 공개한 이 프로토콜이 왜 “AI의 USB-C”라고 불리는지, OpenAI·Google·Microsoft가 왜 모두 동참했는지, 그리고 이 프로토콜이 어떻게 다중 도구·다중 에이전트 간 상호운용성을 가능하게 하는지 다룹니다.

이 판단 체계를 실제로 도입하려면?

규범 기반 개발이 기업에 들어오면 실제로 풀어야 할 문제는 대개 몇 가지로 좁혀집니다. 핵심 규칙을 CLAUDE.md / AGENTS.md로 어떻게 정형화할 것인지, 기존 코드에 규범을 어떻게 보강할 것인지, 컴플라이언스 임베딩을 어떻게 설계할 것인지, 그리고 파일럿을 어떤 지표로 검증할 것인지가 그것입니다.

현재 세 가지 형태로 협업을 제공합니다.

기업 내 교육(Enterprise Training): 고객사의 실제 프로젝트를 기반으로 규범 문서 정리, CI 게이트 설계, 컴플라이언스 임베딩 경로, 거버넌스 체계 구축까지 완결합니다.
전문 자문(Advisory): “우리 회사가 먼저 CLAUDE.md / AGENTS.md를 작성해야 하는가” 또는 기존 코드의 컴플라이언스 개선 우선순위 같은 명확한 의사결정 하나에 집중합니다.
경영진 세미나 및 산업 강연: AI 코딩 도구, 규범 기반 개발, 조직 거버넌스, Frontier Firms를 주제로 진행합니다.

이 글은 일반적인 프레임워크를 제시하지만, 실제 도입은 기업의 컴플라이언스 요건, 규제 경계, 엔지니어링 성숙도, 기존 딜리버리 프로세스를 고려해 재설계해야 합니다. 협업 문의는 coach@iaiuse.com으로 연락 주시기 바랍니다.

추가 자료: 《간판 방법론 v1.0》(천천히 배우는 AI 187) — 기업 AI 전환을 위한 7단계 프레임워크를 체계적으로 소개합니다.

시리즈 소개

“AI 시대 소프트웨어 엔지니어링 혁신”은 통신, 금융, 제조, 이커머스 업계의 CIO, CDO, CTO 및 디지털 전환 책임자를 대상으로 한 연구 시리즈로, 총 18편으로 구성되어 있습니다. AI 코딩 도구, 규범 기반 개발, 조직 거버넌스가 소프트웨어 딜리버리 프로세스, 조직 구조, 엔지니어링 성숙도에 어떤 영향을 미치는지 중점적으로 다룹니다.

이 시리즈는 학술 논문, 벤더 자료, 업계 보고서를 지속적으로 추적하며, 연구 자료는 누적 200건 이상입니다. 주요 판단에는 근거 수준을 표기하여 검증된 사실, 벤더 주장, 업계 관찰, 저자 추론을 최대한 구분하려 했습니다.

저는 대기업 컨설팅 및 비즈니스 분석 분야에서 약 8년간 근무했으며, IBM 재직 시절 통신, 금융, 보험, 제조 프로젝트에 참여한 바 있습니다. 이후 통신사 프로덕트, 인터넷 프로덕트, AI 애플리케이션 개발 현장에서 요구사항 분석, 제품 설계, 크로스 팀 협업을 주도해 왔습니다.

참고 출처 (모두 검증 완료, 항목별 증거 수준 표기)

본 시리즈의 규범 주도, 조직 거버넌스, 엔지니어링 관점에서의 판단은 이러한 실무 경험을 바탕으로 하되, 공개 연구 및 업계 사례와 교차 검증을 거쳤습니다. 특정 프로젝트와 관련된 내용은 모두 비식별화되었으며, 일부 업계 시나리오는 전형적인 문제를 추론한 사례이므로 관련 근거는 본문 말미의 참고 출처를 참조하시기 바랍니다.

이 블로그는 사실 소규모 팀이 운영하고 있습니다. 저와 1-2명의 장기 협업 동료가 각각 AI 코딩 도구 연구, 조직 거버넌스 사례 정리, 코칭 대화 분야를 나누어 담당하고 있습니다. 본문에서 “우리가 기업과 함께 헤쳐 나온” 프로젝트의 대부분은 저희가 공동으로 수행한 것입니다. 고객의 컴플라이언스 경계와 개인 정보는 여전히 공개하지 않으며, 익명성은 향후 협업할 동료들을 위해 유지합니다.

참고 출처 (모두 검증 완료, 항목별 증거 수준 표기)

CodeRabbit (2025.12). State of AI vs Human Code Generation Report. AI가 생성한 코드의 문제 발생률이 인간 개발자 대비 1.7배(PR당 10.83건 vs 6.45건)로 나타났다. 세부적으로 로직/정확성 1.75배, 코드 품질 1.64배, 보안 1.57배, 비밀번호 처리 1.88배, XSS 2.74배로 집계됐다. 근거 수준: 1차. 출처: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263
The Register (2025.12.17). CodeRabbit 보고서 전문 보도: 오픈소스 PR 470건을 분석한 결과, AI 협업 PR에는 평균 10.83건의 문제가 발견된 반면 순수 인간 개발 PR에는 6.45건에 그쳤다. 근거 수준: 2차. 출처: 위와 동일한 URL
CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026년은 ‘코드 생성 속도’에서 ‘코드 품질과 거버넌스’로 초점이 이동하는 전환점이 될 것이다. 증거 수준: 2차. 출처: https://tfir.io/ai-code-quality-2026-guardrails
New Relic (2026). The 2026 State of AI Coding Report. 팀의 78%가 AI 코드 배포 이후 장애가 더 빈번해졌다고 응답했으며, 62%의 기술 리더는 팀이 “자신감 있게 검토 없이 배포”하는 상황을 인정했다. 96%는 옵저버빌리티가 필수라고 답했다. 증거 수준: 1차(벤더 보고서). 출처: https://newrelic.com/resources/report/2026-state-of-ai-coding
Microsoft 2026 Work Trend Index 연례 보고서 (2026.5.5). AI 작업자 20,000명 대상 조사, 10개국 포함. 리더의 82%가 12~~18개월 내 AI 에이전트로 인력 확장을 계획 중이며, 81%는 AI 에이전트가 중간~~대규모로 통합될 것으로 예상. 24%는 이미 엔터프라이즈 수준에서 배포 완료. Copilot 대화의 49%가 인지 업무를 지원하며, AI 사용자의 58%가 “1년 전에는 불가능했던 일”을 해내고 있고, Frontier Professionals의 경우 이 비율이 80%까지 상승. 근거 수준: 1급. 출처: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf
Microsoft FY26 회고: AI 실험에서 프런티어 트랜스포메이션으로 (2026.7.28). EY는 Microsoft 365 Copilot을 150,000명의 임직원에게 배포하여 250만 시간, 약 2억 5천만 달러를 절감했습니다. 이후 40만 글로벌 임직원으로 확장하여 업무 속도 95% 향상, 재무 운영 비용 37% 절감, 최대 90%의 수작업 워크플로우 감소를 달성했습니다. Atos는 Copilot을 56개국 56,000명의 임직원과 19,000개의 AI 에이전트에 배포하고, 통합 ID/보안/컴플라이언스/거버넌스 컨트롤 플레인을 구축했습니다. 근거 수준: 1급(마이크로소프트 공식 회고). 출처: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Atos Group와 Microsoft의 전략적 협업 (2026.6.9). Atos는 56개국 56,000명의 임직원과 19,000개의 AI 에이전트에 Microsoft 365 E7(Frontier Suite)을 배포했습니다. Entra/Defender/Intune/Purview/Agent 365 제어 플레인을 단일화했습니다. 근거 수준: 1급(양사 공동 보도자료). 출처: https://news.microsoft.com/source/2026/06/09/atos-group-and-microsoft-expand-strategic-collaboration-to-scale-secure-agentic-ai-across-atos-group-workforce-and-clients
GitHub Spec Kit (2025.9 오픈소스 공개, 2026년 상반기까지 지속 진화 중). 5단계 게이트 방식 /speckit.constitution → /specify → /plan → /tasks → /implement에 /clarify /analyze을 결합하며, 모델에 구애받지 않는다는 점이 특징입니다. Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / — 모두에서 동일하게 활용됩니다. 증거 수준: 1급(최상위 신뢰도). 출처: https://github.com/github/spec-kit
AWS Kiro (2025.7 출시, 2026년 상반기까지 진화 중). 3단계 워크플로우(요구사항 정의 → 설계 → 태스크 분해 및 실행)를 채택하며, spec이 미리 정의된 에이전트 동작을 트리거합니다. 즉 spec을 작성하지 않으면 프로젝트를 시작할 수 없습니다. 증거 수준: 1급(최상위 신뢰도). 출처: https://kiro.dev/ (역자 주: 현재는 AWS Kiro 공식 페이지로 리다이렉트됨)
OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex는 2026년 6월 기준 주간 활성 사용자 500만 명을 돌파했으며, 이 중 비개발자가 20%를 차지한다. AGENTS.md와 Skills는 조합 가능한 명령어 집합을 제공한다. 근거 등급: 1급(OpenAI 공식 발표). 출처: https://developers.openai.com/codex/skills
Claude Code (Anthropic, 2026 상반기). CLAUDE.md + .claude/rules/ + Skills 시스템을 갖추고 있으며, 2026년 2월 Anthropic 공식 마켓플레이스에 등록되었다. Skills 저장소는 GitHub에서 11.2만 스타를 기록했다. 2026년 2월 G 시리즈 투자 라운드에서 연환산 매출 25억 달러를 공개했다. 근거 등급: 1급. 출처: https://code.claude.com/docs/en/claude-directory
JetBrains AI Pulse Survey (2026.1). 전 세계 10,000명 이상의 전문 개발자를 대상으로 한 설문 조사로, 8개 언어로 현지화되었습니다. Claude Code의 CSAT(고객 만족도)는 91%, NPS(순추천지수)는 54로 업계 최고 수준입니다. Claude Code의 업무 현장 채택률은 18%로, 9개월 만에 3%에서 6배 성장했으며, 북미에서는 24%를 기록했습니다. Copilot은 업무 현장 채택률 29%를 기록했지만 성장세는 정체되었고, Cursor는 18%를 기록했습니다. 증거 수준: 1급. 출처: https://www.jetbrains.com/lp/tools/ai-tools/
Pragmatic Engineer Newsletter (2026.2). 15,000명의 개발자를 대상으로 한 설문 조사에서, 46%가 Claude Code를 “가장 선호하는 도구”로 꼽았으며, Cursor는 19%, Copilot은 9%를 기록했습니다. 증거 수준: 1급. 출처: https://newsletter.pragmaticengineer.com/
Alibaba Qoder (2025.8 → 2026.7). 2025년 8월 알리바바가 출시했으며, 2026년 5월 15일 Qoder 1.0이 Autonomous Agent Development Workbench로 업그레이드되었다. Spec-Driven Workflow, Quest Mode, Expert Mode, RepoWiki를 갖췄다. 2026년 5월 28일에는 Cloud Agents(관리형 에이전트 런타임)를, 2026년 7월 21일에는 Qoder Security를 발표했다. 2026년 5월 기준 글로벌 사용자 수는 500만 명을 돌파했으며, DingTalk CLI와 통합되었다. 2026년 5월 20일, Tongyi Lingma(通义灵码)가 Qoder CN으로 명칭을 변경했다. 근거 수준: 1급. 출처: https://www.alibabacloud.com/en/marketplace/qoder ; https://baike.baidu.com/en/item/Qoder/1427525
vibecoding.app / thebcms.com / tfir.io (2026년 상반기). Spec Kit 5단계 명령어, SDD 도구 평가 비교, EARS 표기법. 근거 수준: 2차(제3자 평가). 출처: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development
EU AI Act / Code of Practice (2026.8.2 전면 시행). 고위험 AI 시스템 규제 준수 기한은 2026.8.2까지이며, 기존 GPAI 모델은 2027.8.2까지 유예됩니다. 위반 시 최대 3,500만 유로 또는 글로벌 매출의 7%에 해당하는 벌금이 부과됩니다. Art. 9-15는 위험 관리, 데이터 거버넌스, 문서 투명성, 인간 감독, 정확성 및 견고성 요건을 규정합니다. 증거 등급: 1급(법령 + 2차 규제 준수 분석). 출처: https://artificialintelligenceact.eu/code-of-practice-overview ; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide
Qodo State of AI Code Quality Report (2025). 결함의 44%가 컨텍스트 부족에서 비롯됩니다. 증거 등급: 2급(벤더 보고서). 출처: https://www.qodo.ai/reports/state-of-ai-code-quality/

#慢慢学AI001: IAIUSE 연구형 자문 블로그

중국의 AI 기술 블로그

이 블로그는 IAIUSE 연구형 자문 블로그입니다. 중국의 전기통신, 금융, 제조, 전자상거래 업계의 CIO와 의사결정자들을 위한 자문 블로그입니다.

중국의 AI 기술 개발과 규제

중국은 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 AI 기술 개발을 지원하고 규제를 강화하고 있습니다. 중국의 AI 기술 개발은 중국의 전기통신, 금융, 제조, 전자상거래 업계에 큰 영향을 미치고 있습니다.

중국의 AI 기술 개발과 규제의 특징

중국의 AI 기술 개발은 중국의 전기통신, 금융, 제조, 전자상거래 업계에 큰 영향을 미치고 있습니다.
중국 정부는 AI 기술 개발을 지원하고 규제를 강화하고 있습니다.
중국의 AI 기술 개발은 중국의 전기통신, 금융, 제조, 전자상거래 업계에 큰 영향을 미치고 있습니다.

중국의 AI 기술 개발과 규제의 사례

중국의 전기통신 업계의 사례: 중국의 전기통신 업계는 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 전기통신 업계의 AI 기술 개발을 지원하고 규제를 강화하고 있습니다.
중국의 금융 업계의 사례: 중국의 금융 업계는 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 금융 업계의 AI 기술 개발을 지원하고 규제를 강화하고 있습니다.
중국의 제조 업계의 사례: 중국의 제조 업계는 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 제조 업계의 AI 기술 개발을 지원하고 규제를 강화하고 있습니다.
중국의 전자상거래 업계의 사례: 중국의 전자상거래 업계는 AI 기술 개발을 적극적으로推진하고 있습니다. 중국 정부는 전자상거래 업계의 AI 기술 개발을 지원하고 규제를 강화하고 있습니다.