Claude Code 팀의 코드 리뷰 방식: 위험도별 승인 0~2명과 우리 팀 도입법

2026년 10월 15일 claude.dev에 실린 Anthropic 엔지니어링 글 "How the Claude Code team does code review"에 따르면, Claude Code 팀은 코드 리뷰를 없애지 않고 읽는 일의 대부분을 기계로 옮겼습니다. Claude가 Claude Code 코드의 약 90%를 쓰는 상황에서 변경 하나는 작성자 PC의 검증, 모든 PR에 붙는 AI 리뷰와 보안 리뷰, CI, 위험도별 사람 승인, 머지 큐와 단계적 배포, 빠른 롤백까지 7개 층을 거칩니다. 사람 승인은 작성자가 아니라 변경의 위험도에 따라 0명·1명·2명으로 갈립니다.

자기 팀에 옮길 때 출발점은 플랜과 관계없이 쓸 수 있는 로컬 /code-review 명령과, 그 리뷰가 따르는 CLAUDE.md입니다. 2026년 10월 23일 데모 저장소에서 실행해 보면 /code-review는 REVIEW.md에만 적은 규칙을 지나쳤고, 같은 규칙을 CLAUDE.md에 넣자 Important로 지적했습니다. 여기에 PR 템플릿의 세 항목(테스트 방법, 위험도, 되돌리는 방법)과 CODEOWNERS·브랜치 보호를 더하면 위험도 등급의 골격이 생깁니다.

Team·Enterprise 조직은 GitHub에서 PR마다 도는 관리형 제품 Code Review와 REVIEW.md를 더할 수 있습니다. 다만 Code Review는 PR을 승인하지도 막지도 않습니다. Anthropic 내부의 "미해결 지적이 있으면 병합 불가"는 자기 저장소에 건 설정이므로, 같은 효과를 원하면 브랜치 보호 규칙이나 CI 스크립트로 직접 걸어야 합니다. 아래에서 Code Review는 이 관리형 제품을, 코드 리뷰는 행위를, /code-review는 내 세션에서 입력하는 명령을 가리킵니다.

변경 하나가 거치는 7개 층: 작성자 PC에서 stable 채널까지

Claude Code 저장소(CLI, 데스크톱·웹 앱, 모바일 앱)에서 변경 하나가 사용자에게 닿기까지의 경로는 대부분 자동이고, 사람의 주의는 위험이 있는 곳에만 들어갑니다. 각 층은 일부 문제를 잡고 일부를 놓치며, 모든 층을 빠져나간 문제는 롤백으로 처리한다는 것이 설계의 전제입니다. 아래 표의 왼쪽 두 열은 Anthropic의 원문을, 오른쪽 열은 외부 팀이 지금 쓸 수 있는 공개 도구를 정리한 것입니다.

첫 층에서 가장 큰 효과를 내는 것은 Claude에게 직접 돌려 볼 수 있는 검사를 주고 "끝났다"는 말 대신 출력을 보여 달라고 하는 습관입니다. Claude Code를 만든 Boris Cherny는 이렇게 하면 최종 결과가 두세 배 좋아진다고 했는데, 측정한 값이 아니라 본인의 어림입니다. 리뷰어가 같은 지적을 반복하면 팀은 그 원인을 스킬, 린트 규칙, 지침 파일 중 한 곳에서 고칩니다. CLAUDE.md는 모든 리뷰가 불러오기 때문에 짧게 유지하고 다른 문서를 가리키게 하며, REVIEW.md는 각 영역의 코드 오너가 "이 저장소에서 실패란 무엇인가"(문서라면 "거짓말을 한다", 설정이라면 "잘못 라우팅한다")를 적는 파일입니다.

두 번째 층의 AI 리뷰는 여러 에이전트가 동시에 버그를 찾고, 별도의 에이전트 묶음이 지적마다 투표해 충분히 동의한 것만 게시합니다. 스타일·진단·정리에 그치는 지적은 버립니다. 게시된 지적은 심각도 순으로 정렬되고 세 가지 라벨이 붙습니다. Important는 병합 전에 고쳐야 할 버그, Nit은 고치면 좋지만 막지는 않는 사소한 문제, Pre-existing은 이 PR이 만든 것이 아닌 기존 버그라는 뜻이어서, 오래된 버그가 작성자 탓처럼 보이지 않습니다.

위험도 기반 차등 리뷰: 사람 승인 0명·1명·2명의 기준

Claude Code 팀에서 사람 승인 인원은 작성자가 아니라 변경 자체가 정합니다. 분류기가 변경을 읽고 위험 등급을 고르며, 문서 수정은 자동 리뷰와 보안 검사만 통과하면 사람 승인 없이 병합되고, 자동 업데이트 코드는 한 명, 가장 위험한 경로는 두 명이 승인해야 합니다.

표만 보고 "문서는 사람이 안 봐도 된다"고 옮기면 빠지는 조건이 있습니다. 가벼운 경로는 저장소의 신뢰 목록에 오른 작성자, 대개 그 코드를 소유한 팀에게만 열리고, 그 밖의 작성자는 두 번째 사람의 승인이 필요합니다. 두 번째 분류기는 등급이 낮더라도 이 변경에 사람이 더 필요한지를 다시 묻고, 오너가 민감하다고 지정한 경로와 모든 CI 워크플로 파일은 등급과 관계없이 사람 승인을 받습니다.

에이전트의 승인은 사람의 승인으로 치지 않습니다. 에이전트가 쓴 PR에서는 그 에이전트를 지시한 사람이 필수 리뷰어 한 명으로 계산되므로, 직접 타이핑한 코드와 똑같이 책임을 집니다. 승인은 특정 커밋 하나에만 유효해서, 에이전트의 푸시나 손으로 해결한 머지처럼 시스템이 보증할 수 없는 커밋이 올라오면 다시 승인을 받아야 합니다. Hacker News 토론에서는 LLM이 쓴 문서를 아무도 읽지 않고 병합한다는 데 대한 반발이 컸는데, 외부 팀이라면 원문의 권고대로 엄격하게 시작해 근거가 쌓일 때 등급을 완화하는 편이 안전합니다.

90%, PR 두 배, 되돌림 40% 감소: 각 숫자가 재는 것

이 주제에서 인용되는 숫자는 모두 Anthropic의 자기 보고이고, 각자 재는 대상이 다릅니다. 특히 "되돌림 40% 이상 감소"는 되돌려야 했던 PR의 비율이지 건수가 아니며, "하루 3만 건"은 Claude Code 저장소가 아니라 Anthropic 모노레포의 수치입니다.

되돌림 수치는 건수로 바꾸면 해석이 달라집니다. PR이 정확히 두 배가 되고 되돌림 비율이 정확히 40% 줄었다면 되돌린 건수는 2 × 0.6 = 1.2배로 오히려 늘어납니다. 원문의 두 숫자가 모두 "이상"으로 표현된 하한이라 실제 건수의 방향은 알 수 없고, 비율이 줄었다는 사실은 그대로입니다. Hacker News에서는 되돌림 비율을 목표로 삼으면 지표 자체가 왜곡된다는 굿하트 법칙 우려도 나왔습니다. 원문에서 최적화 대상은 사람의 시간(PR당 사람 승인 수의 중앙값과 95백분위, 사람 코멘트 수, PR이 사람을 기다린 시간)이고 되돌림·장애 비율은 넘지 말아야 할 가드레일로 쓰입니다. 또 이 수치가 움직일 때 승인 기준을 자동으로 조이는 장치는 아직 없다고 원문 스스로 밝히고 있습니다.

내 플랜으로 따라 할 수 있는 것: /code-review·ultrareview·Code Review

어떤 플랜이든 로컬 /code-review로 PR을 열기 전 리뷰를 따라 할 수 있고, Pro·Max는 클라우드에서 더 깊게 보는 ultrareview를, Team·Enterprise는 PR마다 자동으로 도는 Code Review와 REVIEW.md를 더할 수 있습니다. 2026년 10월 23일 기준 공식 문서로 보면 이 도구들은 기본 상태로는 병합을 막지 않으며, 규칙 파일을 읽는 범위도 서로 다릅니다.

로컬 /code-review는 현재 브랜치(업스트림보다 앞선 커밋과 커밋하지 않은 변경)를 기본으로 보고, PR 번호·브랜치 범위·경로를 대상으로 줄 수도 있습니다. --fix는 지적을 작업 트리에 적용하고, low부터 max까지의 effort 값은 넓이와 확신도를 맞바꿉니다. low는 가장 확신하는 지적만 보고합니다. 정리 전용인 /simplify와의 차이, 다른 스킬과의 조합은 Claude Code 스킬 추천: 작업별 첫 선택과 설치·확인 방법에서 다룹니다.

/code-review는 REVIEW.md를 읽지 않습니다: 두 번 실행한 결과

로컬 /code-review는 CLAUDE.md를 따르고 REVIEW.md는 읽지 않습니다. /code-review 공식 문서는 -p로 실행하는 비대화형 모드에서도 CLAUDE.md를 따른다고 적고 있고, REVIEW.md는 관리형 Code Review의 설정 파일이라고 구분합니다. 2026년 10월 23일 같은 데모 저장소에서 규칙 위치만 바꿔 두 번 실행한 결과도 문서와 같았습니다.

실행 조건은 macOS 컴퓨터 한 대, Claude Code 2.1.309, Pro 플랜 계정 하나입니다. main 브랜치에 장바구니 소계 함수를 두고, add-discount 브랜치에서 앞쪽 limit개 상품만 할인하는 함수를 추가하면서 문제 네 개를 일부러 심었습니다.

// Apply a percentage discount to the first `limit` items only.
// TODO: support coupon codes
function discountedTotal(items, percent, limit) {
  let total = 0;
  for (let i = 0; i <= limit; i++) {
    const line = items[i].priceCents * items[i].qty;
    total += line * (1 - percent / 100);
  }
  for (let i = limit; i < items.length; i++) {
    total += items[i].priceCents * items[i].qty;
  }
  return total;
}

CLAUDE.md에는 "Money is always stored and computed as integer cents"라는 금액 규칙을, REVIEW.md에는 "변경한 줄에 TODO가 있으면 Important"라는 규칙을 두었습니다. 1회차는 이 상태로, 2회차는 같은 TODO 규칙을 CLAUDE.md에도 추가한 커밋을 main에 올리고 브랜치를 리베이스한 뒤 실행했습니다. 명령은 claude -p "/code-review low" --output-format json이고, 파일 수정 도구는 빼고 Read·Grep·Glob과 git·node 명령만 허용했으며 예산 상한을 $3로 두었습니다.

비용은 CLI가 JSON 출력의 total_cost_usd에 표시한 API 가격 기준 추정값이고 청구서 금액이 아닙니다. 리뷰 결과는 이 컴퓨터의 Claude Code 응답 언어가 중국어로 설정되어 있어 중국어로 나왔고, 위 표는 그 요지를 한국어로 옮긴 것입니다. 조건마다 한 번씩만 돌렸고 effort는 low였으며 모델 출력은 실행마다 달라질 수 있으므로, 2회차가 더 빠르고 쌌던 차이에는 의미를 두기 어렵습니다. 관리형 Code Review, ultrareview, /security-review는 이 실행에 포함되지 않았습니다.

정리하면 로컬 리뷰와 Code Review 양쪽에 적용할 규칙은 CLAUDE.md에 두고, PR 리뷰에만 쓸 심각도 조정·제외 경로·Nit 상한은 REVIEW.md에 두는 것이 공식 문서가 권하는 분담입니다. CLAUDE.md가 언제 어떤 범위로 로드되는지는 Claude Code Memory 가이드 (2026): CLAUDE.md, auto memory, 플러그인 경계에서 설명합니다.

Code Review는 PR을 막지 않습니다: 병합 차단은 저장소 규칙으로

관리형 Code Review는 PR을 승인하지도 막지도 않으며, "Claude Code Review"라는 체크 런은 실패로 끝나는 일이 없습니다. Code Review 공식 문서는 병합 결정을 팀에 남겨 두기 위한 설계라고 설명하고, 체크 런은 neutral 또는 skipped로 끝나므로 필수 체크로 지정해도 병합을 막지 못합니다. Anthropic 내부에서 버그 리뷰나 보안 리뷰의 미해결 지적이 병합을 막는 것은 자체 저장소 설정입니다.

가장 간단하게 비슷한 효과를 내는 방법은 GitHub 브랜치 보호의 Require conversation resolution before merging을 켜는 것입니다. PR에서 지적을 읽는 방법을 다룬 Code Review 문서는 이 설정이 켜져 있으면 지적마다 스레드를 해결해야 병합할 수 있다고 적고 있습니다. 이렇게 하면 Anthropic 방식대로 작성자가 고치거나 사유를 달고 스레드를 닫아야 하며, 오탐도 이 방법으로 정리됩니다. Hacker News에서 지적됐듯 심각한 보안 지적을 오탐으로 닫는 일은 보안 담당자가 함께 보도록 규칙을 정해 두는 편이 안전합니다.

Important 개수로 병합을 막고 싶다면 CI에서 체크 런 상세 텍스트의 마지막 줄을 읽는 방법이 문서에 나와 있습니다. 마지막 줄은 <!-- bughunter-severity: {"nit":1,"normal":2,"pre_existing":0} --> 형식의 HTML 주석이고 normal이 Important 개수입니다. 아래 명령은 문서 예시를 그대로 옮긴 것으로, 앞의 데모 저장소 실행에는 포함되지 않았습니다.

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID --jq '
  (.output.text | split("\n") | last
    | scan("^<!-- bughunter-severity: (.*) -->$")[0] | fromjson)?
  // error("no severity line")'

이 줄이 없으면 개수가 0이라는 뜻이 아니라 판정이 없다는 뜻입니다. 또 제목이 "Code review not repeated"로 시작하는 체크 런은 이전 리뷰의 Important 지적이 아직 열려 있는데도 개수 줄이 없으므로, 스크립트는 개수보다 제목을 먼저 확인해야 합니다.

비용: Code Review는 정액이 없고 ultrareview는 무료 3회 뒤 $5~25

2026년 10월 23일 기준 Code Review에는 리뷰 1회당 정액 요금이 없습니다. Code Review 비용 문서에 따르면 토큰 사용량만큼 사용 크레딧으로 플랜 포함 사용량과 별도로 청구되고, 청구 대상은 PR을 연 개발자가 아니라 조직입니다. 1회 비용은 리뷰 수준(Quick·Standard·Deep), 변경 크기, 주변 코드의 복잡도, 검증할 후보 지적 수에 따라 달라지며, 관리자 페이지에서 추가한 저장소의 기본값인 After every push는 푸시 횟수만큼 비용을 곱합니다. 리서치 프리뷰 시기에 돌던 "1회 $15~25"는 정식 출시 문서에 없는 수치이므로 현재 가격으로 쓰면 안 됩니다.

예산을 잡으려면 문서가 권하는 대로 월 지출 한도를 먼저 걸고, 대표 저장소 몇 개만 Once after PR creation이나 Manual(@claude review)로 켠 뒤, Admin settings > Claude Code의 저장소별 Average cost에 월간 PR 수를 곱합니다. After every push를 쓸 계획이면 PR당 평균 푸시 수를 한 번 더 곱합니다. 한도나 크레딧 잔액이 바닥나면 리뷰는 건너뛰어지고 PR에 그 이유가 코멘트로 남습니다. Code Review 정식 출시 공지에 따르면 자격을 갖춘 Enterprise 조직은 2027년 1월 15일까지 최소 $10,000의 Code Review 크레딧을 신청할 수 있고, 크레딧은 신청 후 30일이 지나면 만료됩니다.

ultrareview는 별개 제품입니다. ultrareview 공식 문서 기준 Pro·Max는 계정당 한 번 무료 3회가 주어지고 다시 채워지지 않으며, 그 뒤로는 변경 크기에 따라 보통 1회 $5~25의 사용 크레딧이 들고 실행 전 대화상자에 예상 비용이 표시됩니다. 로컬 /code-review는 따로 과금되지 않고 세션 사용량에 포함되며, 앞의 데모 실행에서 CLI가 표시한 추정값은 1회 $0.09~0.19였습니다. 사용 크레딧이 어떻게 계산되고 언제 상위 플랜이 나은지는 Claude 추가 사용량 요금: 사용 크레딧 계산, 월 $80 넘으면 Max 5x를 참고하세요.

우리 팀에 도입하는 6단계: CLAUDE.md부터 CODEOWNERS까지

도입은 PR을 열기 전 단계부터 시작해 병합 뒤 단계로 넓혀 가는 순서가 무리가 없습니다. 아래 순서는 Anthropic 글 끝의 도입 체크리스트를 플랜별 도구에 맞춰 묶은 것이고, 1~3단계와 5단계는 어떤 플랜에서도 할 수 있습니다.

1. 저장소 루트의 CLAUDE.md에 Claude가 직접 돌릴 검사 명령과 팀 규칙을 짧게 적습니다. 자세한 설명은 다른 문서로 넘기고 링크만 둡니다. 포매터와 린터는 매번 지시하기보다 hook으로 자동 실행하게 하는 편이 확실하며, 설정 방법은 Claude Code Hooks·Skills·슬래시 명령어 차이와 사용 예제에 있습니다.

# Project rules
- 변경 후 `npm test`와 `npm run build`를 실행하고 출력을 그대로 보여 준다.
- 금액은 항상 정수 센트로 저장하고 계산한다.
- 변경한 줄에 TODO 주석이 있으면 Important로 지적한다.
- 아키텍처 설명은 docs/architecture.md를 따른다.

2. PR을 열기 전에 로컬에서 /code-review를 돌리고, 보안이 걸린 변경이면 /security-review도 돌립니다. 지적을 바로 고치게 하려면 /code-review --fix를 쓰되, 결과만 먼저 보고 싶다면 --fix 없이 실행합니다.

3. .github/pull_request_template.md에 Testing, Risk, How to revert 세 항목을 넣습니다. Claude가 채워도 되지만 변경을 요청한 사람이 내용을 확인하고 책임진다는 것이 Claude Code 팀의 규칙입니다.

## Testing
<!-- 실행한 명령과 결과, 스크린샷 -->

## Risk
<!-- 낮음 / 중간 / 높음, 그렇게 판단한 이유와 영향 범위 -->

## How to revert
<!-- 되돌릴 커밋, 끌 수 있는 플래그 -->

4. 저장소 하나에만 AI 리뷰어를 붙이고 몇 주 동안 REVIEW.md를 다듬은 뒤 넓힙니다. Team·Enterprise라면 Owner가 Admin settings > Claude Code에서 Code Review를 켜고 Claude GitHub App을 설치한 뒤 저장소를 고르며, 그 밖에는 Claude API 키로 Claude Code GitHub Action을 붙입니다. REVIEW.md는 PR 자신의 변경이 아니라 기준 브랜치나 기본 브랜치에서 읽히므로 먼저 병합해야 하고, 심각도 낮추기·경로 제외·Nit 상한은 보호된 기본 브랜치의 루트 파일에 있을 때만 적용됩니다.

# Review instructions

## What Important means here
Important는 동작을 깨거나 데이터를 유출하거나 롤백을 막는 문제에만 쓴다.
스타일과 이름 짓기는 많아야 Nit이다.

## Cap the nits
리뷰 한 번에 Nit은 최대 세 개까지 보고한다.

## Do not report
- CI가 이미 검사하는 린트, 포맷, 타입 오류
- `src/gen/` 아래 생성 파일과 `*.lock` 파일

## Evidence and summary
동작에 관한 주장은 이름으로 추측하지 말고 `file:line`을 근거로 든다.
요약은 지적 개수로 시작하고, 고칠 것이 없으면 없다고 분명히 쓴다.

5. 위험도 등급을 문서로 적고 CODEOWNERS와 브랜치 보호로 구현합니다. 인증, 결제, CI·릴리스 워크플로, 설치 스크립트처럼 항상 사람이 봐야 하는 경로에 오너를 지정한 뒤, 브랜치 보호에서 Require review from Code Owners를 켜면 오너 팀에 봇 계정을 넣지 않는 한 사람 승인 자리를 봇이 채울 수 없고, Dismiss stale pull request approvals when new commits are pushed를 켜면 새 커밋이 올라올 때 승인을 다시 받아야 합니다. 여기에 Require conversation resolution before merging까지 켜면 리뷰 지적에 답하지 않은 PR은 병합되지 않습니다. 처음에는 엄격하게 두고, 낮은 등급 경로는 신뢰하는 작성자에게만 엽니다.

# .github/CODEOWNERS
/src/auth/           @your-org/security
/src/billing/        @your-org/billing-owners
/.github/workflows/  @your-org/release-owners
/scripts/install*    @your-org/release-owners

6. 병합 뒤 단계로 머지 큐, 기능 플래그, 사내 사용 우선, 단계적 릴리스, 한 단계 롤백을 갖춥니다. 장애와 되돌림이 생기면 그 PR을 리뷰어 평가 세트에 넣고, 리뷰 프롬프트나 도구나 모델이 바뀔 때마다 다시 채점합니다. 성과는 PR당 사람이 쓴 시간으로 재고, 되돌림·장애 비율을 넘지 말아야 할 선으로 둡니다.

AI 작성자와 AI 리뷰어의 무한 왕복을 끊는 규칙 4가지

작성자도 리뷰어도 에이전트이면 서로를 끝없이 바쁘게 만들 수 있습니다. Claude Code 팀의 CLI PR 하나는 작성자가 멈출 때까지 하룻밤 사이 50회 넘게 리뷰와 수정을 오갔고, 리뷰어가 반복해서 지적한 코드를 git blame으로 보니 약 59%가 첫 리뷰 때부터 있던 코드였습니다. 새 버그를 찾은 것이 아니라 매 라운드 오래된 버그를 몇 개씩 더 찾고 있었던 셈이어서, 팀은 아래 네 가지로 재리뷰 방식을 바꿨습니다.

• 세 번째 라운드가 끝나면 리뷰어가 더 지적하는 대신 작성자에게 접근 방식을 다시 생각해 보라고 요청합니다.
• 처음 몇 번의 리뷰 뒤에는 새로 바뀐 diff만 다시 봅니다.
• 한 줄이 아니라 버그의 유형을 지적해서 작성자가 같은 유형을 한 번에 모두 고치게 합니다.
• 이미 게시한 지적은 반복하지 않습니다.

에이전트에게 Nit은 사람보다 비쌉니다. 사람은 Nit을 몇 초 만에 넘기지만 에이전트는 고치려 들고, 그때마다 커밋과 리뷰 라운드가 하나씩 늘기 때문입니다. 직접 만든 리뷰 에이전트나 CI 스크립트를 쓴다면 네 규칙을 리뷰 지침에 그대로 넣을 수 있고, Code Review를 쓴다면 Review runs를 Once after PR creation으로 두고 필요할 때만 @claude review를 다는 것이 푸시마다 리뷰가 도는 구조를 피하는 가장 가까운 장치입니다.

사람은 이제 코드를 안 읽나: Claude Code 팀에 남은 사람의 판단

Claude Code 팀에서도 사람은 여전히 코드를 읽지만, 모든 줄을 읽는 대신 기계가 대신할 수 없는 판단에 시간을 씁니다. 무엇을 만들지 정하는 일, 결제·자동 업데이트·CI 워크플로 같은 위험한 코드, 다른 사람이 따라 할 패턴을 정하는 설계, 그리고 증거를 읽고 결과를 책임지는 일입니다. 리뷰 병목을 해결했다고 선언한 한 팀도 팀 밖에서 들어오는 변경에는 사람 리뷰를 남겨 "이걸 정말 해야 하나"를 묻게 했습니다.

증거를 읽는다는 것은 테스트 출력, 실행한 명령과 그 결과, 스크린샷, 리뷰어의 지적을 직접 확인한다는 뜻입니다. 원문은 검사가 무엇을 놓칠지 말할 수 없다면 빠른 승인 대신 제대로 된 리뷰를 요청하라고 권합니다. 누가 타이핑했든 배포되는 모든 변경에는 책임지는 사람이 한 명 있고, 작거나 중간 크기 변경이 문제를 일으키면 대개 그 변경을 병합한 사람이 고칩니다. 이 규범이 비난으로 흐르지 않는 것은 변경이 작고, 플래그·되돌림·단계적 릴리스로 대부분 몇 분 안에 되돌릴 수 있으며, 장애 회고가 사람이 아니라 시스템을 보기 때문입니다.

코드 리뷰의 또 다른 역할이던 코드베이스 이해의 공유는 형식 없이 처리합니다. 고칠 부분을 이해해야 할 때 Claude에게 그 부분만의 설명서를 써 달라고 하거나 작은 시각화를 만들게 하고, 공개 Slack 채널에서 일하는 습관이 서로 무엇을 만드는지 보여 줍니다. 방향을 바꿔야 할 것 같으면 다 끝난 PR에 막는 코멘트를 다는 대신 스레드 초기에 말하는 것이 이 팀의 방식입니다.