문제는 AI가 나쁜 코드를 짜는 게 아니다
팀에 AI 코딩 어시스턴트를 도입한 지 얼마 지나지 않아, 대부분의 팀은 비슷한 시점에 같은 문제를 발견한다. 엔지니어가 10명을 넘어서는 순간부터다. Cursor, GitHub Copilot, Claude Code—각자 쓰는 도구가 달라도 결과는 같다. 레이어 경계가 흐릿해지고, 네이밍 컨벤션이 갈라지고, 아무도 의도하지 않은 의존성이 슬금슬금 생긴다. 그리고 그걸 발견하는 건 대부분 포스트모템 때다.
이건 'AI가 나쁜 코드를 생성한다'는 문제가 아니다. dev.to에 올라온 한 글은 이 문제를 정확하게 짚는다. 핵심은 지시 파일이 곧 아키텍처 거버넌스가 될 수 없다는 것이다. CLAUDE.md나 AGENTS.md에 레이어 경계와 네이밍 규칙을 아무리 잘 써놓아도, 그 파일은 '지시'일 뿐이다. 긴 세션, 모호한 프롬프트, 충분한 컨텍스트 압박이 쌓이면 모델은 그 파일을 조용히 무시한다. 그리고 그 판단을 독립적으로 검증하는 레이어가 없다.
스케일이 커지면 코드 리뷰는 고무도장이 된다
엔지니어가 5명일 때는 시니어 1~2명이 모든 PR을 직접 보면 된다. 경계 침범은 눈에 띈다. 그런데 팀이 30명, 50명, 100명을 넘어서면 그 모델은 무너진다. 리뷰는 두 방향 중 하나로 퇴화한다. 속도를 위해 고무도장이 되거나, 품질을 위해 병목이 되거나. 어느 쪽이든 아키텍처 드리프트는 막히지 않는다. 그냥 나중에 발견될 뿐이다.
여기서 두 번째 문제가 붙는다. 100명 이상의 엔지니어가 같은 레포를 대상으로 각자의 AI 코딩 세션을 돌리면, 매 세션마다 동일한 아키텍처 컨텍스트와 컨벤션이 모델에 반복 전달된다. 공유 메모리가 없으니 토큰 비용이 중복으로 쌓인다. 프롬프트 캐싱이 도움이 되지만, 프리픽스가 비결정적이면 캐시 히트 자체가 안 된다—대부분의 팀이 이 할인을 그냥 흘려보내고 있다.
진짜 필요한 건 'AI 생성 코드의 독립 검증 레이어'다
아직 완성된 솔루션은 없다. 앞서 언급한 글에서 소개하는 Arclask는 이 문제를 정면으로 겨냥한 아이디어다—AI 코딩 도구 옆에 붙어서 모든 AI 생성 변경사항을 실제 아키텍처 규칙에 따라 머지 전에 검증하는 레이어. 아직 초기 단계지만, 방향 자체는 옳다. 지시 파일이 아니라 독립된 검증 게이트가 필요하다는 것.
이 방향은 LLM 평가 파이프라인에서 이미 실증되고 있다. dev.to에 공개된 프로덕션 LLM 평가 파이프라인 구축 사례는 이 구조를 명확하게 보여준다. RAG 기반 고객 지원 어시스턴트를 운영하던 팀이 '봤을 때 괜찮아 보이면 OK' 방식으로 QA를 하다가 프로덕션에서 500명 이상의 사용자에게 할루시네이션 응답을 노출했다. 포스트모템 결과는 단순했다. 자동화 평가가 전혀 없었다.
LLM 평가 파이프라인이 아키텍처 거버넌스에 주는 교훈
이 팀이 구축한 평가 파이프라인의 핵심 구조는 세 가지다.
첫째, Golden Dataset. 1000개 케이스로 시작하지 않는다. 실제 프로덕션 케이스 50개로 시작한다. 기본 케이스 40%, 엣지 케이스 30%, 적대적 케이스 20%, 멀티링구얼/장문 컨텍스트 10%로 구성하고, 프로덕션 장애가 발생할 때마다 새 케이스를 추가한다. Git으로 버전 관리한다.
둘째, Judge Ensemble. Faithfulness(신뢰도), Instruction Following(지시 준수), JSON Schema 검증, Safety 체크를 각 임계값과 함께 자동화한다. 도메인별 커스텀 Judge도 few-shot 예제로 빠르게 구성할 수 있다.
셋째, CI/CD 통합. GitHub Actions에서 PR이 올라올 때마다 평가 스위트가 돌고, 회귀가 감지되면 머지가 블록된다. 결과는 PR 코멘트로 자동 게시된다. 이 구조 도입 후 할루시네이션 탐지율이 67%(인간 리뷰)에서 92%(자동화)로 올랐고, 프로덕션 인시던트는 월 3건에서 0.2건으로 줄었다.
아키텍처 거버넌스에 이 교훈을 그대로 적용할 수 있다. 아키텍처 규칙도 Golden Dataset처럼 관리해야 한다. 레이어 경계 위반, 허용되지 않은 의존성 패턴, 네이밍 컨벤션 이탈—이것들을 판별하는 Judge를 정의하고, PR마다 자동으로 돌리고, 통과하지 못하면 머지를 막는다. '봤을 때 문제없어 보이면 OK'가 LLM 응답 품질에 실패했듯, 'PR 리뷰어가 눈으로 보면 OK'는 대규모 AI-First 팀의 아키텍처 거버넌스에 실패한다.
두 다이얼을 동시에 돌려야 한다
세 번째 소스 아티클이 제시하는 'Content 다이얼 vs Control 다이얼' 프레임은 이 문제를 더 정밀하게 자른다. Content는 도메인 지식—레이어 설계 원칙, 의존성 규칙, 네이밍 컨벤션. Control은 증거 기반 게이트—'그 결정이 실제로 구현됐는가'를 검증하는 독립적 메커니즘.
CLAUDE.md는 Content 다이얼만 건드린다. 아무리 잘 써도 Control이 없으면, 그럴듯한 어휘로 쓰인 아키텍처 위반 코드가 통과한다. 반대로, 아키텍처 규칙 없이 프로세스 체크만 하는 CI는 Control만 있고 Content가 없는 상태다. 형식은 통과하는데 실질은 검증 못 한다.
실질적인 설계는 이렇다. 팀의 실제 아키텍처 결정 기준을 Judge로 인코딩하고(Content), 그것을 CI/CD에서 자동 실행되는 게이트로 연결한다(Control). 어느 컴포넌트가 Content를 담당하고, 어느 컴포넌트가 Control을 담당하는지 명시적으로 설계한다. 스택 어디에도 그 다이얼을 소유한 주체가 없다면, AI 코딩 어시스턴트가 많아질수록 위험은 조용히 쌓인다.
내일 당장 시작할 수 있는 것
완성된 아키텍처 거버넌스 시스템을 한 번에 구축할 필요는 없다. LLM 평가 파이프라인이 50개 케이스로 시작하듯, 아키텍처 거버넌스도 작게 시작할 수 있다.
- 가장 자주 위반되는 아키텍처 규칙 3개를 정적 분석 룰로 인코딩한다. 레이어 간 허용되지 않은 임포트, 특정 패턴의 의존성 역전, 네이밍 컨벤션 이탈. 린터나 커스텀 스크립트로 충분히 시작할 수 있다.
- 그것을 PR 체크로 CI에 넣는다. 위반이 감지되면 머지 블록. 예외는 명시적 오버라이드로 기록되게 한다.
- 실제 위반 케이스가 발생할 때마다 룰셋에 추가한다. 포스트모템을 테스트 케이스로 전환하는 것과 같은 원리다.
AI-First 팀의 아키텍처는 지시가 아니라 구조로 지킨다
AI 코딩 어시스턴트의 속도는 실재한다. 하지만 그 속도가 팀 전체에 적용될수록, 아키텍처 일관성을 '모델이 지시를 따를 것이라는 신뢰'에 기댈 수 없다. 신뢰는 구조로 증명해야 한다.
지시 파일은 Context다. 검증 게이트는 Guard다. 이 둘을 분리해서 설계하지 않으면, AI-First 팀의 개발 속도는 결국 아키텍처 부채 속도와 경쟁하게 된다. 그리고 아키텍처 부채는 언제나 조용히, 그리고 늦게 드러난다.