812줄짜리 PR이 8분 만에 승인됐다
테스트는 전부 그린이었다. 11개 파일, 812줄. Cursor와 Claude Sonnet이 생성하고, 미드레벨 엔지니어가 가볍게 손본 뒤, 시니어가 8분 만에 승인 버튼을 눌렀다. 그 시니어 뒤에는 리뷰 대기 PR이 네 개 더 쌓여 있었다.
문제는 41번째 줄에 있었다. from langchain.chains import LLMChain. 팀이 6주 전에 langchain을 전면 제거했다는 사실—ADR 문서, Slack 스레드, 태그된 릴리스—은 코드를 생성한 시스템 어디에도, 리뷰한 사람 눈앞 어디에도 없었다. 2주 후 의존성 감사가 버전 충돌을 잡아냈을 때, 이미 세 개 모듈이 해당 라이브러리를 import하고 있었다.
모델이 틀린 게 아니다. 거버넌스 레이어가 없었던 거다
dev.to에 이 사례를 공유한 엔지니어의 진단은 명확하다. "모델은 실패하지 않았다. 거버넌스 레이어가 실패했다." 모델은 주어진 프롬프트에 대해 충분히 타당한 코드를 생성했다. 프롬프트에 "이 팀은 5월에 langchain을 제거했다"는 정보가 없었을 뿐이다. 왜 없었을까? 그 사실이 모델의 컨텍스트 어디에도 주입되지 않았기 때문이다.
아키텍처 결정은 실제로 어디에 살고 있었나. /docs/adr/ 폴더, Slack 스레드, 두 명의 베테랑 엔지니어 머릿속, git 태그. 그리고 어디에 없었나. 모델 프롬프트, IDE 컨텍스트, pre-commit 훅, CI 단계, PR 리뷰 체크리스트. 인간 리뷰어가 유일한 체크포인트였는데, 그 리뷰어에게는 8분이 주어졌다.
처리량 수학: AI 도입 후 리뷰 부하가 4~6배 뛰었다
AI 도입 전후의 숫자를 직접 따져보면 문제가 구조적임을 알 수 있다. AI 이전에는 엔지니어 한 명이 하루 실질적인 PR 1개를 만들고, 리뷰어는 하루 5개 정도를 충분한 깊이로 소화했다. 시스템에 여유가 있었고, 리뷰어는 "잠깐, 이거 2분기에 우리가 결정한 것과 다른 방향 아닌가?"를 생각할 시간이 있었다.
Cursor, Copilot, Claude Code를 실제로 도입한 팀의 현실은 다르다. 엔지니어 한 명이 하루 4~6개 PR을 만든다. 리뷰어는 같은 '리뷰' 단계에서 20~30개를 처리해야 한다. PR당 집중도가 4~6배 떨어진다. "6주 전 결정과 모순되는데?"를 잡아낼 인지 자원이 구조적으로 없다. 이건 실력 문제가 아니다. 어떤 시니어도 하루 30개 PR을 그 깊이로 리뷰할 수 없다.
.cursorrules는 정책이 아니라 바이브다
"우리는 rules 파일 써"라는 반론이 나올 것이다. .cursorrules, CLAUDE.md, 각 도구별 설정 파일. 도움이 되는 건 맞다. 하지만 그것들이 실제로 무엇인지를 냉정하게 봐야 한다.
강제성이 없다. 모델이 rules를 무시해도 테스트가 깨지지 않고, CI가 블로킹하지 않는다. 결과가 없는 규칙은 규칙이 아니라 제안이다. 도구마다 파편화된다. Cursor는 .cursorrules를 읽고, Claude Code는 CLAUDE.md를 읽고, Copilot은 둘 다 읽지 않는다. 두 개 이상 AI 도구를 쓰는 팀—지금 대부분의 팀—에서 아키텍처 거버넌스는 "개발자가 어떤 IDE를 열었느냐"에 따라 달라진다. 텍스트 블롭이라 우선순위가 없다. "langchain 금지"와 "탭 vs 스페이스 선호"가 모델의 어텐션 예산에서 동등한 무게를 차지한다.
결론: rules 파일은 바이브다. 진짜 거버넌스는 정의, 집행 지점, 감사 추적이 있어야 한다.
월 $47짜리 자율 에이전트가 보여주는 두 번째 역설
dev.to에 소개된 또 다른 사례가 이 문제를 다른 각도에서 조명한다. LangGraph 기반 오케스트레이터에 Claude, GPT-4o, Gemini를 멀티모델로 연결해 월 $47로 완전 자율 코딩 에이전트를 구축한 케이스다. 버그 수정, 코드 생성, 테스트, 문서화를 24/7 처리하고, 커피 한 잔 내리는 동안 마이크로서비스를 통째로 배포한다.
이 에이전트는 태스크 유형에 따라 모델을 라우팅하고, 테스트가 실패하면 반복 생성한다. 도구 레이어에서 터미널, 파일 시스템, git, Docker까지 직접 건드린다. 정교하고 인상적인 셋업이다. 그런데 딱 하나, 이 아키텍처 어디에도 "이 프로젝트가 langchain을 금지했다"는 사실을 에이전트에게 알려주는 구조가 없다. 지식 베이스는 README, config 파일, 기존 코드 스타일을 읽는다. ADR은 읽지 않는다.
비개발자의 프로덕션 배포가 보여주는 세 번째 역설
코드를 한 줄도 모르는 사람이 Claude Code로 2,053페이지짜리 Next.js 사이트를 프로덕션에 배포했다는 사례도 있다. 1.9년에 걸쳐 솔로로, 월 $25 도구비용으로. 이 사람은 FAQPage 스키마가 두 컴포넌트에서 중복 발화되는 버그를 336개 페이지에 걸쳐 Claude Code로 40분 만에 수정했다.
이것은 명백히 AI 도구의 민주화다. 그리고 동시에, 거버넌스 부재의 민주화이기도 하다. 아키텍처 결정이 무엇인지 모르는 사람이 아키텍처 결정을 내리고 있다. 나쁜 의도가 아니라 맥락이 없어서. 모델이 틀려서가 아니라 제약이 없어서.
실제 집행 레이어는 어떻게 생겨야 하나
원글 필자가 제안하는 구조는 세 가지다.
첫째, 타입이 있는 정책 셋. 산문 블롭이 아니라 기계가 파싱할 수 있는 형태로. 금지 의존성과 아키텍처 규칙이 각각 anti_pattern과 rule 타입을 갖고, 우선순위와 태그와 rationale을 포함한다. ESLint 설정이 문법 규칙의 소스오브트루스인 것처럼, 이 JSON이 아키텍처 결정의 소스오브트루스가 된다. 버전 컨트롤 안에 살고, PR마다 diff가 찍힌다.
둘째, 생성 전 주입. 동일한 정책 셋이 Cursor든 Claude Code든 Aider든 내부 RAG 파이프라인이든, 모든 모델 호출에 주입된다. 규칙이 도구가 아니라 프로젝트에 귀속된다. IDE를 바꿔도 에이전트가 아키텍처 결정을 알고 있다.
셋째, 생성 후 검증. 정책 셋을 기준으로 에이전트 출력을 실제로 검사하는 단계. 리뷰어의 기억이 아니라 자동화된 체크가 "이 PR은 anti-001 정책을 위반한다"를 잡아낸다.
팀 리드가 지금 당장 해야 할 판단
현실적으로 이 세 레이어를 내일 당장 완성할 팀은 없다. 하지만 지금 당장 할 수 있는 것은 있다.
ADR을 인간이 읽는 문서가 아니라 에이전트 컨텍스트에 주입되는 데이터로 다시 생각해야 한다. 기존 CI 파이프라인에 금지 의존성 스캔을 추가하는 건 오늘 오후에 할 수 있다. PR 리뷰 체크리스트에 "이 변경이 최근 3개월 ADR과 충돌하지 않는가"를 추가하는 것도 마찬가지다.
더 중요한 것은 인식의 전환이다. AI 도구 도입으로 PR 처리량이 올라갔다는 것은 거버넌스 레이어의 부하가 동일 비율로 올라갔다는 뜻이다. 속도 향상의 이면에 검증 비용이 숨어 있고, 그 비용을 리뷰어의 집중도로 메우는 것은 구조적으로 불가능하다. 에이전트가 빠를수록 거버넌스가 더 필요하다는 역설을 팀 리드가 먼저 인정하지 않으면, 다음 번 langchain은 훨씬 조용하게 다시 들어온다.