Claude Code /code-review 백그라운드 실행: 대화창을 비우고 리뷰받는 법 | DAKER 커뮤니티
Claude Code /code-review 백그라운드 실행은 리뷰 작업을 별도 subagent로 보내 대화창의 맥락 오염을 줄이는 운영 방식입니다. Claude Code /code-review란 변경사항을 별도 리뷰 관점으로 점검하는 수동 호출형 스킬입니다. 2026년 7월 24일 KST 기준 최신 공식 changelog는 리뷰가 background subagent로 실행되도록 바뀌었다고 확인됩니다.

문제 상황: 리뷰 결과가 대화창을 너무 길게 만들 때 어떻게 줄일까?
작업 대화 안에서 구현, 테스트, 리뷰가 한꺼번에 이어지면 정작 다음 수정 지시가 어디에 붙었는지 흐려집니다. 특히 PR 전 리뷰는 많은 파일과 코멘트를 읽기 때문에 본문 맥락을 오래 차지합니다. 이제 리뷰를 별도 흐름으로 보내고, 본대화에는 결정과 액션만 남기는 습관이 더 중요합니다.
핵심 개념: /code-review 백그라운드 실행은 무엇이 달라졌을까?
한 줄 요약: /code-review는 최신 버전에서 리뷰 작업을 background subagent로 실행해 대화창을 덜 채우는 방향으로 바뀌었습니다. 이는 리뷰가 자동으로 시작된다는 뜻이 아니라, 사용자가 직접 호출한 리뷰를 분리해 다루기 쉬워졌다는 의미입니다. 검토 기준일은 2026년 7월 24일 KST이며, 팀별 설정과 실제 버전은 각자 확인해야 합니다.

단계별 사용법: PR 전 리뷰 흐름은 어떻게 잡을까?
- 현재 브랜치에서 테스트와 타입 검사를 먼저 실행해 명백한 실패를 정리합니다.
- 리뷰 대상 범위를 한 문장으로 적고 /code-review를 직접 호출합니다.
- 리뷰가 백그라운드로 돈 뒤 본대화에는 수정할 항목, 보류할 항목, 확인 못 한 항목만 옮깁니다.
- 수정한 항목은 다시 테스트하고, 필요하면 짧은 재리뷰를 요청합니다.
- 최종 보고에는 리뷰 실행 여부와 남은 위험을 분리해 남깁니다.
짧은 예시: 리뷰 명령 앞에 무엇을 붙이면 좋을까?
“현재 브랜치의 인증 변경만 대상으로 /code-review를 실행하고, P1 버그와 누락 테스트를 먼저 알려 주세요”처럼 리뷰 대상을 좁히면 좋습니다. 수동 호출 기준은 수동 검증 글과 함께 맞추고, 병렬 작업 예산은 subagent cap 글을 참고하면 팀 기준을 세우기 쉽습니다.
팀 적용 체크리스트: 리뷰 분리 운영에서 무엇을 확인할까?
- 리뷰 시작 전 대상 브랜치와 비교 기준을 명확히 적습니다.
- 리뷰 결과를 그대로 붙이지 말고 수정 결정 단위로 요약합니다.
- 긴 리뷰가 비용 한도와 subagent 제한에 걸릴 수 있음을 공유합니다.
- 자동 리뷰 완료라는 표현 대신 직접 호출한 리뷰라고 기록합니다.
- 테스트 실패가 있으면 리뷰보다 실패 재현을 먼저 처리합니다.
공식 출처 기준으로 무엇을 조심해야 할까?
공식 changelog와 공식 skills 문서를 비공개로 확인했고, 공개 본문에는 DAKER 내부 링크만 남겼습니다. 이 글은 특정 저장소의 리뷰 품질을 보장하지 않습니다. 팀의 Claude Code 버전, 예산 설정, subagent 제한을 함께 확인해야 합니다.
자주 묻는 질문
/code-review가 이제 자동으로 실행되나요?
아닙니다. 최신 문서 기준으로 /code-review는 사용자가 직접 호출해야 하는 리뷰 스킬입니다.
백그라운드로 돌면 리뷰 결과를 놓치지 않나요?
결과 확인과 요약 단계를 따로 두면 놓칠 가능성이 줄어듭니다. 최종 보고에 리뷰 실행 여부를 남기면 됩니다.
큰 PR에도 바로 쓰면 되나요?
큰 PR은 범위를 나눠 요청하는 편이 낫습니다. 파일 묶음이나 변경 목적별로 리뷰 단위를 줄이세요.
오늘 바로 바꿀 팀 규칙은 무엇인가요?
PR 전 “테스트 후 /code-review 직접 호출, 결과는 수정 결정 단위로 요약”이라는 한 줄 규칙부터 추가해 보세요.
오늘 리뷰가 필요한 브랜치 하나를 골라, 리뷰 대상을 한 문장으로 좁힌 뒤 직접 호출해 보세요.