Claude Code에 organization default model과 role default 표시가 들어오면서, 팀 단위 모델 운영이 훨씬 현실적인 주제가 됐습니다. 관리자가 조직 콘솔에서 기본 모델을 정하고, 사용자가 직접 선택하지 않았을 때 /model에 “Org default” 또는 “Role default”로 보이는 구조입니다. 작아 보이지만 팀 비용과 품질을 동시에 잡는 데 중요한 장치입니다.
많은 개발팀이 AI 코딩 도구를 도입할 때 처음에는 개인 생산성만 봅니다. “누가 더 빨리 PR을 만들었나”, “테스트 작성이 얼마나 쉬워졌나” 같은 지표입니다. 하지만 사용자가 늘어나면 문제가 바뀝니다. 같은 저장소에서도 어떤 사람은 가장 비싼 모델로 간단한 grep성 질문을 하고, 어떤 사람은 약한 모델로 보안 리뷰를 맡깁니다. 결과는 비용은 예측하기 어렵고, 품질은 일관되지 않은 상태입니다.
모델 선택은 생각보다 자주 잘못됩니다. 개발자는 지금 해결해야 할 버그에 집중하지, 모델별 비용과 latency 표를 매번 떠올리지 않습니다. 그래서 UI에서 보이는 첫 번째 옵션이나 예전에 성공했던 옵션을 반복해서 씁니다.
조직 기본 모델은 이 기본 행동을 정책으로 바꿉니다. 좋은 기본값을 정하면 대부분의 요청이 합리적인 비용과 품질 범위 안에 들어옵니다. 반대로 기본값을 방치하면 모델 운영은 개인 취향의 합이 됩니다.
특히 Claude Code처럼 코드 수정, 터미널 실행, MCP 호출, 백그라운드 에이전트까지 연결되는 도구에서는 모델 선택이 단순 응답 품질을 넘어섭니다. 모델이 너무 약하면 잘못된 수정이나 불필요한 도구 호출이 늘고, 너무 강하면 모든 작업의 단가가 올라갑니다. 둘 다 운영 비용입니다.
모델 정책을 세울 때 “우리 팀은 어떤 모델을 기본으로 쓸까?”부터 묻는 것은 순서가 틀렸습니다. 먼저 작업 유형을 나눠야 합니다.
실무에서는 대략 다섯 가지로 나눌 수 있습니다. 첫째, 코드 검색과 설명입니다. 기존 코드 구조를 읽고 파일 위치를 찾는 작업입니다. 둘째, 작은 수정입니다. 타입 오류, UI 문구, 간단한 조건 분기 수정처럼 범위가 좁습니다. 셋째, 테스트와 리팩터링입니다. 여러 파일을 건드리고 회귀 위험이 있습니다. 넷째, 보안·권한·결제 관련 작업입니다. 실패 비용이 큽니다. 다섯째, 장기 백그라운드 작업입니다. 오래 걸리고 중간 복구가 중요합니다.
이렇게 나눈 뒤에야 모델 기본값을 정할 수 있습니다. 모든 작업을 최고 모델에 태우는 것은 쉽지만 비쌉니다. 모든 작업을 저렴한 모델에 태우는 것은 싸지만 검수 비용이 늘어납니다.
가장 단순한 정책은 역할별 3단계입니다. 일반 개발자는 균형형 모델을 기본값으로 둡니다. 코드 검색, 작은 수정, 문서화에 충분한 모델입니다. 시니어 리뷰어나 보안 담당 역할은 더 높은 추론 모델을 기본값으로 둡니다. 아키텍처 변경, 권한 로직, 결제 경로, 마이그레이션 검토에 품질을 더 씁니다. 자동화나 백그라운드 작업 역할은 latency와 안정성을 우선한 모델을 둡니다.
여기서 중요한 건 “사용자가 바꿀 수 있는지”입니다. 기본값은 정책이지만 예외는 필요합니다. 다만 예외를 허용한다면 이유를 남기게 해야 합니다. 예를 들어 큰 리팩터링 작업에서 고성능 모델을 선택했다면 PR 설명이나 작업 로그에 “모델 변경 이유: 인증 경로 리팩터링” 정도를 남기는 방식입니다.
이런 기록은 비용 통제보다 학습에 더 유용합니다. 한 달 뒤 보면 어떤 작업에서 좋은 모델이 실제로 도움이 됐는지, 어떤 작업은 기본 모델로 충분했는지 알 수 있습니다.
모델 비용을 볼 때 입력/출력 토큰 단가만 비교하면 반쪽짜리입니다. 약한 모델로 작업해서 PR 수정이 3번 반복되면 사람 검수 시간과 CI 비용이 늘어납니다. 반대로 강한 모델을 쓰면 한 번에 통과할 수 있지만 모든 요청에 쓰면 예산이 빠르게 소진됩니다.
그래서 모델 정책의 지표는 세 가지를 같이 봐야 합니다. 첫째, 요청당 비용입니다. 둘째, 작업 완료까지 걸린 총 시간입니다. 셋째, 재작업률입니다. 재작업률은 “같은 이슈에서 에이전트가 다시 호출된 횟수”, “리뷰에서 수정 요청을 받은 횟수”, “CI 실패 후 재시도 횟수”로 볼 수 있습니다.
좋은 기본 모델은 가장 싼 모델이 아니라 총비용이 낮은 모델입니다. 총비용에는 모델 비용, 개발자 대기 시간, 리뷰 시간, 실패 복구 시간이 모두 들어갑니다.
모델만 정책화하면 부족합니다. 같은 모델이라도 프롬프트와 권한에 따라 결과가 달라집니다. 예를 들어 작은 수정 역할은 파일 수정 권한을 제한하고, 테스트 실행은 허용하되 배포 명령은 막아야 합니다. 보안 리뷰 역할은 읽기 중심으로 두고, 수정은 별도 승인 후 진행하게 할 수 있습니다.
MCP 서버도 역할별로 나누는 편이 좋습니다. 모든 역할이 모든 MCP에 접근할 필요는 없습니다. 코드 검색 역할은 파일 시스템과 Git 정도면 충분합니다. 배포 역할은 CI/CD MCP가 필요할 수 있지만, 그만큼 승인과 감사 로그가 필요합니다.
Role default는 모델만의 문제가 아니라 “모델 + 권한 + 프롬프트 + 로그” 묶음으로 운영해야 효과가 납니다.
조직 기본 모델을 바꾸는 순간 팀 전체 출력 스타일이 달라질 수 있습니다. 따라서 전사 적용 전에 파일럿 그룹을 둬야 합니다. 추천 방식은 1주일 동안 2~3개 팀만 적용하고, 기존 기본값을 쓰는 팀과 비교하는 것입니다.
비교 항목은 간단합니다. 요청 수, 총 토큰, 평균 비용, PR당 에이전트 호출 수, CI 실패율, 리뷰 수정 요청 수, 작업 완료 시간입니다. 정성 평가도 필요합니다. 개발자에게 “모델이 과하게 조심스러웠는지”, “불필요한 설명이 늘었는지”, “코드 수정이 공격적이었는지”를 물어보면 숫자로 안 보이는 문제가 나옵니다.
파일럿에서 문제가 없으면 역할별 기본값을 확대합니다. 그 다음에는 월 1회 정도 정책을 리뷰하면 됩니다. 모델 제품은 빠르게 바뀌기 때문에 한 번 정한 기본값을 오래 방치하면 다시 비효율이 생깁니다.
Claude Code의 org default는 단순한 UI 표시가 아닙니다. 팀이 AI 코딩 도구를 개인 장난감이 아니라 운영 가능한 개발 인프라로 다루기 시작했다는 신호입니다. 기본값을 잡으면 비용은 예측 가능해지고, 품질은 덜 흔들립니다.