Claude Code 바이브코딩 표준화, 프롬프트보다 검증을 고정하라

같은 모델과 프롬프트를 쓰면 바이브코딩 결과도 같아질까.

Claude Code를 팀에 넓히려는 조직이 지금 부딪히는 질문이다. 답은 산출물 복제가 아니라, 달라진 산출물을 같은 기준으로 걸러내는 데 있다.

같은 입력이 같은 패치를 보장하지 않는다

현장에서는 모델 버전과 effort, 하네스를 맞춰도 두 번째 요청부터 구현이 갈렸다는 경험이 이어졌다. 앞선 도구 호출과 파일 상태가 다음 문맥에 들어가므로 대화가 길어질수록 선택지가 달라진다는 의견이 많았다.

이 현상은 단순한 체감으로만 치부하기 어렵다. UCL 연구진이 2024년 발표한 ACM 논문은 코드 생성 문제 829개를 반복 시험했다. 기본 설정에서 동일한 테스트 출력이 한 번도 겹치지 않은 과제가 데이터셋별로 47.56~75.76%였다. 온도를 0으로 낮춰도 결정론은 보장되지 않았다.

2026년 ICLR 워크숍 논문은 SWE-bench Verified에서 6만 개 에이전트 궤적을 분석했다. 세 모델과 두 스캐폴드를 반복 실행하자 단일 실행 pass@1이 2.2~6.0%포인트 흔들렸다. 온도 0에서도 표준편차는 1.5%포인트를 넘었다. 초기의 작은 차이가 다른 해결 전략으로 번졌다. 두 연구는 Claude Code 자체의 결함을 입증하지 않는다. 다만 코딩 에이전트의 한 번짜리 결과를 표준으로 삼기 어렵다는 근거는 된다.

프롬프트 고정은 출발선만 맞춘다

Claude Code 공식 문서는 모델과 effort를 설정으로 지정할 수 있다고 설명한다. 팀은 `.claude/settings.json`을 저장소에 넣는다. 관리자는 모델 선택과 권한, 샌드박스, MCP, 훅을 제한할 수 있고, `CLAUDE.md`에는 아키텍처와 빌드 명령, 코딩 규칙을 공유한다.

이 장치들은 실행 조건의 차이를 줄인다. 그러나 자연어 규칙은 모델이 해석하는 입력이다. 규칙을 적었다고 테스트 통과나 금지 파일 보호가 자동으로 보장되지는 않는다.

GitHub Copilot도 저장소·경로별 지시 파일과 `AGENTS.md`를 지원한다. 공식 안내는 여기에 빌드, 테스트, 검증 방법을 적으라고 권한다. 제품이 달라도 제어면이 좋은 답안 양식보다 저장소 문맥과 검증 절차에 모이는 이유다. DORA의 2025년 연구도 AI를 조직의 강점과 약점을 키우는 증폭기로 규정했다.

표준화할 것은 기획부터 개선까지의 증거다

작업 흐름은 요구사항, 설계, 구현, 검토, 개선으로 나누되 각 단계의 산출물을 명시해야 한다. 입력은 이슈와 수용 조건이다. 출력은 설계 결정, 코드 변경, 테스트 결과, 리뷰 기록이다. 다음 단계는 앞 단계의 문서가 아니라 통과 증거를 받는다.

NIST의 SSDF 1.1은 보안 개발 관행을 결과 중심으로 제시한다. 조직의 위험과 비용에 맞게 조정하고 계속 개선하라는 방식이다. 고정된 체크리스트를 모든 팀에 복사하라는 표준이 아니다.

Anthropic이 공개한 에이전트 설계 지침도 명확한 평가 기준이 있을 때 evaluator-optimizer 루프를 권한다. 한 모델이 만들고 다른 평가 단계가 피드백한다. 기준을 충족할 때까지 수정한다. 바이브코딩 표준화도 같은 구조가 맞다. 생성 경로는 열어둔다. 합격 조건은 코드와 자동화로 좁힌다.

Claude Code에는 네 개의 파일과 한 개의 CI로 옮긴다

먼저 저장소 루트의 `CLAUDE.md`를 짧게 만든다. 아키텍처 경계, 패키지 관리자, 필수 명령, 수정 금지 영역, 완료 조건만 둔다. 긴 작업별 절차는 별도 스킬이나 명령으로 분리한다.

다음으로 `.claude/settings.json`에 팀 공통 권한과 훅을 커밋한다. `PreToolUse` 훅은 비밀 파일이나 배포 경로 수정을 막는다. `PostToolUse` 훅은 `Edit|Write` 뒤 포매터나 정적 분석을 실행한다. 공식 훅 문서에 따르면 종료 코드 2는 작업을 차단하고 이유를 Claude에 돌려준다.

검증 명령은 `scripts/verify.sh`처럼 하나로 모은다. 포맷, 린트, 타입 검사, 단위·통합 테스트를 정해진 순서로 실행한다. 하나라도 실패하면 0이 아닌 코드로 끝낸다. `Stop` command 훅이 이 스크립트를 호출하면 검증 실패 상태에서 세션 종료를 막을 수 있다. command 훅이 agent 훅보다 운영 기준에 더 적합하다고 공식 문서는 권고한다.

CI는 같은 스크립트를 에이전트 밖에서 다시 실행해야 한다. 자동 작업에는 `claude --bare -p`와 명시적인 `--settings`, 모델, effort, 도구 허용 목록을 넘긴다. `--bare`는 개인 훅과 `CLAUDE.md`, MCP 자동 탐색을 생략하므로 필요한 지침은 `--append-system-prompt-file` 등으로 직접 지정해야 한다. 결과는 JSON으로 받고 커밋 SHA, 모델, effort, 프롬프트 버전, 테스트 로그를 함께 남긴다.

편차는 없애지 말고 측정한다

평가는 두 패치의 문자 일치율이 아니라 수용 조건 통과율로 한다. 대표 과제를 반복 실행해 기능 테스트, 보안 검사, 재작업 여부, 시간과 비용을 기록한다. 모델이나 하네스를 바꿀 때는 같은 과제 묶음으로 전후 분포를 비교해야 한다. 한 번 성공한 데모는 운영 표준의 증거가 아니다.

써본 사람들 사이에서는 긴 `CLAUDE.md`가 중요한 규칙을 희석한다는 불만도 있다. 짧은 불변 규칙은 문서에 둔다. 반드시 지킬 조건은 훅과 CI로 옮겼더니 관리가 쉬워졌다는 반응이 함께 나온다. 테스트를 먼저 실패시킨다. AI가 만든 테스트도 코드처럼 검토해야 한다는 팁도 반복된다.

개인 개발자와 소규모 팀에도 이 구분은 실용적이다. 하네스를 전사 제품처럼 만들 필요는 없다. 하나의 검증 스크립트와 보호 훅, 독립 CI만 있어도 모델 교체 비용이 줄어든다. 바이브코딩의 표준은 같은 답을 복제하는 문서가 아니라, 다른 답이 나와도 같은 품질선을 통과하게 만드는 실행 체계다.