파이프라인 전체를 AI로 묶는다는 것의 의미
AI 코딩 도구를 '개별 기능'으로 쓰는 팀과, '파이프라인'으로 묶는 팀의 차이는 생각보다 크다. 전자는 개발자가 Claude Code에 질문을 던지고 코드를 받아 붙여 넣는다. 후자는 Claude가 어떤 파일을 건드릴 수 있고 어떤 규칙을 따라야 하는지를 설정으로 강제하고, 생성된 코드의 품질을 LLM이 자동으로 심사하며, 그 결과가 CI/CD 게이트를 통과해야만 배포된다. 두 접근의 차이는 '도구'와 '시스템'의 차이다.
1단계: Claude Code 팀 설정 표준화
dev.to에 공개된 Claude Code 프로덕션 설정 가이드는 이 시스템의 첫 번째 레이어를 명확하게 정의한다. 핵심은 레이어 분리다.
~/.claude/settings.json— 개인 보안 전역 설정 (모든 프로젝트에 적용).claude/settings.json— 팀 공유 프로젝트 권한 (git에 커밋).claude/settings.local.json— 개인 오버라이드 (gitignore)
권한 체계는 단순하다: Deny → Ask → Allow 순으로 우선순위가 정해지며, Deny는 항상 이긴다. 실용적인 전역 deny 목록은 rm -rf, sudo, git push --force, 그리고 .env, ~/.ssh/**, ~/.aws/** 같은 시크릿 경로를 포함한다. 팀원이 이 설정 없이 Claude Code를 쓰면 크리덴셜이 노출될 수 있다. 설정이 있으면 Claude는 그 파일을 읽을 수 없다.
CLAUDE.md의 '인스트럭션 예산' 문제는 팀이 흔히 놓친다. 프론티어 LLM이 신뢰할 수 있게 따르는 지시 사항은 총 150~200개 수준이다. Claude Code의 시스템 프롬프트가 이미 50개 슬롯을 소비한다. 팀 표준을 CLAUDE.md에 100줄 넘게 쏟아붓는 순간, 정작 중요한 규칙이 무시될 확률이 올라간다. 짧고 핵심적인 것만 남기는 게 코딩 스타일이 아니라 LLM 준수율을 높이는 전략이다. 코딩 스타일 강제는 CLAUDE.md가 아니라 linter와 git hook에 맡겨야 한다.
팀 레벨에서 이 설정을 표준화하면 두 가지가 생긴다. 첫째, Claude는 프로젝트 아키텍처, 금지 패턴, PR 리뷰 기준을 '매 세션마다' 알고 있다. 둘째, 신규 팀원의 온보딩 시간이 줄어든다. CLAUDE.md가 팀 플레이북 역할을 하기 때문이다. 개인 전역 파일(~/.claude/)은 개인 툴킷이고, 프로젝트 파일(.claude/)은 팀 표준이다. 이 구분을 지키지 않으면 팀원마다 다른 Claude가 작동한다.
2단계: LLM-as-a-Judge로 코드 품질 자동 심사
Claude가 코드를 생성했다면, 그 코드를 누가 검증하는가? 인간 리뷰어가 병목이 되는 구간이 바로 여기다. dev.to의 LLM-as-a-Judge 구현 가이드가 제시하는 수치는 냉정하다. 숙련된 인간 리뷰어 두 명이 동일한 태스크를 평가할 때 일치율은 81% 수준이다. 잘 설정된 LLM 심사관은 인간 리뷰어 대비 약 85% 일치율을 달성한다. 완벽하지 않지만, 1,000개 테스트 케이스를 10~20시간이 아니라 수 분 안에 처리한다.
구현 패턴은 세 단계로 진화한다. 첫째는 OpenAI SDK 기반 Raw Judge다. 구조화된 프롬프트, Pydantic 스키마, 체인-오브-쏘트 추론을 조합해 1~10점 점수와 근거를 반환한다. 가장 단순하지만 모든 프레임워크의 기반이다. 둘째는 DeepEval의 GEval로, 자연어 기준을 평가 스텝으로 자동 변환하고 0~1 정규화 점수를 낸다. threshold=0.7 같은 파라미터로 CI에서 하드 패스/페일 게이트를 만들 수 있다. 셋째는 Pairwise Comparison으로, '이 코드가 몇 점인가'가 아니라 '두 버전 중 어느 쪽이 더 나은가'를 묻는다. 점수 드리프트 문제를 우회하고, 모델 업그레이드 평가나 리팩토링 비교에 유용하다.
세 패턴의 실전 선택 기준은 간단하다. 빠른 프로토타입이면 Raw Judge, 팀 표준 메트릭 관리가 필요하면 DeepEval, 모델/코드 버전 비교가 목적이면 Pairwise. 이 세 개를 다 쓸 필요는 없다. 지금 팀의 병목이 어디인지에 따라 하나씩 붙이면 된다.
3단계: CI/CD에 AI 평가 게이트 연결
설정 표준화와 LLM 심사가 있어도, 게이트가 없으면 품질은 여전히 사람의 기억에 의존한다. AI 개발 워크플로우 실전 가이드(dev.to)가 강조하는 지점이 바로 여기다. AI가 생성한 코드에 대해 'Never Deploy Blindly' 원칙을 지키려면, 이를 사람의 의지가 아니라 파이프라인 구조로 강제해야 한다.
실행 방법은 구체적이다. DeepEval을 예로 들면 deepeval test run test_eval.py를 CI 스텝에 추가하면 된다. 임계값 미달 시 커밋이 블록된다. Claude Code의 CLAUDE.md에 PR 리뷰 규칙(타입 안전성, 데드코드, 에러 핸들링)을 정의하고, 이를 LLM 심사 기준과 동기화하면 '사람이 작성한 기준'과 'AI가 검증하는 기준'이 일치하는 상태가 된다.
시사점: 설정이 문화다
세 단계를 연결해서 보면 공통된 원칙이 보인다. AI-First 워크플로우의 품질은 도구의 성능이 아니라 설정의 품질에 달려 있다. Claude Code 설정이 허술하면 Claude는 팀 기준을 무시한다. LLM 심사 기준이 모호하면 점수는 의미 없는 숫자가 된다. CI 게이트가 없으면 리뷰는 선택 사항으로 전락한다.
반대로, 이 세 레이어가 잘 맞물리면 팀원이 AI 코딩 도구를 쓸 때마다 팀 표준이 자동으로 적용되고, 생성된 코드는 자동으로 심사되며, 기준 미달 코드는 배포 전에 걸러진다. 이것이 '내일 당장 팀에 적용 가능한 AI-First 워크플로우'의 실체다.
전망: 설정을 관리하는 사람이 팀의 AI 품질을 결정한다
도구는 이미 충분히 강력하다. 지금 AI-First 팀에서 실제로 격차가 벌어지는 지점은 '누가 더 좋은 AI 도구를 쓰는가'가 아니라 '누가 더 잘 설정된 AI 환경을 운영하는가'다. CLAUDE.md를 팀 플레이북으로 유지 관리하고, LLM 심사 메트릭을 실제 PR 리뷰 기준과 동기화하며, CI 게이트의 임계값을 주기적으로 재보정하는 역할—이것이 AI-First 팀에서 테크 리드의 핵심 업무가 되고 있다. 코드를 직접 짜는 시간보다 AI가 좋은 코드를 짜도록 환경을 설계하는 시간이 더 높은 레버리지를 갖는 시대다.