"AI는 좋은 관행을 증폭시킨다. 그리고 나쁜 관행도 똑같은 속도로 증폭시킨다."
HiPay의 리드 엔지니어가 dev.to에 올린 문장인데, 이보다 AI-First 팀의 현실을 정확하게 요약한 말을 본 적이 없다. AI 코딩 어시스턴트를 팀에 도입한 이후 생산성이 올랐는가? 아마 그렇다. 그런데 코드 품질 편차도 동시에 커졌는가? 역시 그렇다면, 당신 팀엔 아직 AI 규칙이 없는 것이다.
핵심 이슈: 규칙 없는 AI는 혼돈을 400% 속도로 생산한다
최근 세 가지 실증 사례가 거의 동시에 등장했다. 각각 독립된 실험이지만, 묶어서 읽으면 하나의 강력한 메시지가 보인다—AI 도구는 팀의 규칙 설계 수준을 그대로 반영한다.
첫 번째는 LogiFlow라는 회사의 Black Friday 프로덕션 장애 사례다. AI 에이전트가 자율적으로 생성한 라우팅 마이크로서비스가 대규모 부하 테스트에서 완전히 무너졌다. 코드는 완벽해 보였다. 변수명, JSDoc 주석, ESLint—흠잡을 데 없었다. 문제는 Promise.all로 트럭 5만 대의 DB 쓰기를 동시에 때렸을 때 PostgreSQL 커넥션 풀이 50개짜리라는 사실을 AI가 전혀 고려하지 않았다는 것이다. 데드락이 발생했고, 4시간 장애가 났다. 개발 속도는 400% 올랐지만, 기술 부채도 400% 속도로 쌓인 셈이다.
두 번째는 HiPay 팀의 대응 방식이다. 이 팀도 같은 문제를 겪었다—개발자마다 AI 어시스턴트 설정이 달랐고, 하드코딩된 API 키가 커밋됐으며, 아키텍처 패턴이 같은 사무실에 앉은 사람들 사이에서도 제각각이었다. 이들이 내린 결론은 명확하다: AI 설정은 개인 취향이 아니라 팀 계약이다. 해법으로 CLAUDE.md 기반의 계층형 규칙 리포지토리를 구축했다—전체 조직에 적용되는 보편 규칙(시크릿 금지, git 컨벤션 강제), 기술 스택별 규칙(NestJS 헥사고날 아키텍처, React 훅 규칙), 그리고 프로젝트별 맥락(취약 모듈, 도메인 모델)의 3계층이다. 이 규칙 패키지는 버전 관리되고, 팀이 명시적으로 pull하는 방식으로 배포된다. 푸시 방식이 아닌 이유—스프린트 중간에 규칙이 바뀌는 걸 막기 위해서다.
세 번째는 instruction 압축 실험이다. AI 에이전트에게 세션마다 로드되는 규칙 파일이 61KB, 약 18,000토큰에 달한다면 어떻게 최적화할까? dev.to에 공개된 A/B 테스트 결과는 꽤 충격적이다. 55% 압축한 버전은 두 가지 테스트에서 실패했다—python=venv처럼 너무 짧게 줄인 선호 설정은 모델이 무시했고, "허가 없이 행동하지 말 것"이라는 안전 규칙은 3번 중 1번만 지켜졌다. 반면 47% 압축한 버전은 완전한 문장을 유지하면서도 행동 품질 저하가 없었다.
핵심 발견은 이것이다: 안전 규칙의 반복(redundancy)은 낭비가 아니라 강화다. 동일한 제약을 여러 표현으로 반복해야 모델이 신뢰할 수 있게 따른다. 규칙을 너무 압축하면 compliance가 확률적이 된다—같은 프롬프트를 3번 실행했을 때 매번 다른 행동이 나온다.
맥락 해석: 우리가 놓치고 있는 설계 레이어
세 사례를 관통하는 구조적 문제는 하나다. AI 도입 논의는 항상 도구 선택(Cursor냐, Claude Code냐, Copilot이냐)에서 시작하는데, 정작 결과를 결정하는 건 그 도구에 무엇을 먹이느냐다.
LogiFlow는 AI에게 코드 생성을 맡기면서 시스템의 물리적 제약(DB 커넥션 풀, MVCC 아키텍처, 트랜잭션 경계)을 가르치지 않았다. HiPay는 개발자마다 다른 context 파일을 허용함으로써 AI를 개인 취향 도구로 방치했다. instruction 압축 실험은 규칙 파일의 형식이 모델 행동에 직접적으로 영향을 준다는 것을 수치로 증명했다.
결국 AI-First 팀에서 진짜 엔지니어링 작업은 AI가 일하는 환경을 설계하는 것이다. 코드를 짜는 게 아니라, AI가 올바른 코드를 짜도록 제약과 맥락을 설계하는 것.
시사점: 내일 당장 할 수 있는 것
팀에 AI 코딩 어시스턴트를 쓰고 있다면, 지금 당장 확인해야 할 것 세 가지다.
첫째, 팀원마다 AI 설정이 다른가? 다르다면 그게 바로 품질 편차의 원인이다. CLAUDE.md든 .cursorrules든 팀 공용 규칙 파일을 버전 관리 리포지토리에 올려야 한다. HiPay 방식대로 3계층(보편/스택별/프로젝트별)으로 나누면 노이즈 없이 관련 규칙만 전달할 수 있다.
둘째, AI가 생성한 코드에 동시성 처리가 있는가? 비동기 코드에서 Promise.all이나 대량 병렬 DB 쓰기가 보이면 반드시 사람이 직접 검토해야 한다. AI는 happy path에 최적화되어 있고, 커넥션 풀 한계나 데드락 가능성은 코드 문법에서 드러나지 않는다. 트랜잭션 경계(BEGIN, COMMIT, SELECT ... FOR UPDATE)는 사람이 명시적으로 설계해야 할 영역이다.
셋째, 안전 규칙을 너무 짧게 줄이지 마라. instruction 파일 토큰을 아끼고 싶다면, 압축은 style 규칙과 파일 경로에만 적용하고 안전 규칙은 완전한 문장으로 유지해야 한다. "git push 전 확인"이 아니라 "Never execute git commits or pushes without explicit user approval"처럼 써야 모델이 일관되게 따른다.
전망: 규칙 설계는 곧 팀 아키텍처다
HiPay 팀이 /plan과 /review라는 두 개의 워크플로우 게이트를 도입한 것은 단순한 프롬프트 트릭이 아니다. 이건 피드백 루프를 코드 작성 이전으로 당기는 아키텍처 결정이다. 코드를 다 쓴 다음 리뷰에서 문제를 발견하면 비용이 크다. AI가 코딩 시작 전에 영향 범위를 분석하고 리스크를 먼저 리포트하도록 설계하면, 같은 검토 비용으로 훨씬 앞단에서 문제를 잡을 수 있다.
instruction 압축 실험이 제시한 3계층 전략도 같은 맥락이다—항상 로드할 것과 필요할 때만 로드할 것을 나누고, 로드 순서를 캐시 구조에 맞게 배치하고, 남은 것만 압축하는 방식. 이건 토큰 절약 팁이 아니라 AI 워크플로우 아키텍처 설계다.
AI-First 팀 리빌딩에서 내가 계속 강조하는 것은 이것이다: AI 도구의 ROI는 도구 자체의 성능이 아니라 그 도구를 어떤 규칙과 맥락 안에서 작동시키느냐에 달려 있다. 도구를 도입하는 데 하루가 걸린다면, 규칙을 설계하는 데는 일주일을 써야 한다. 그 비율이 역전되는 순간, AI는 팀의 가장 빠른 기술 부채 생성 도구가 된다.