Claude Code /code-review 백그라운드 실행, 대화창을 덜 어지럽게 쓰는 방법 | DAKER 커뮤니티

구현과 테스트, 리뷰가 한 대화 안에서 길게 이어지면 정작 다음 작업 지시가 어디에 있는지 찾기 어려워질 때가 있습니다. 특히 PR 전 리뷰처럼 읽을 범위가 넓은 작업은 대화창의 흐름을 오래 점유하기 쉽습니다.

Claude Code의 /code-review가 background subagent로 실행되도록 바뀌었다는 점은 그래서 실무적으로 의미가 있습니다. 리뷰를 자동화했다기보다, 직접 호출한 리뷰를 본대화와 분리해 다루기 쉬워졌다는 변화에 가깝습니다.

Claude Code /code-review 백그라운드 실행은 리뷰 작업을 별도 subagent로 보내 대화창의 맥락 오염을 줄이는 운영 방식입니다.

Claude Code /code-review란 변경사항을 별도 리뷰 관점으로 점검하는 수동 호출형 스킬입니다. 2026년 7월 24일 KST 기준 최신 공식 changelog는 리뷰가 background subagent로 실행되도록 바뀌었다고 확인됩니다.

왜 대화창 분리가 중요할까

작업 대화 안에서 구현, 테스트, 리뷰가 한꺼번에 이어지면 이후 수정 지시와 결정 사항이 묻히기 쉽습니다. 리뷰는 본질적으로 많은 파일과 코멘트를 다루기 때문에, 그대로 본문에 쌓이면 다음 액션을 정리하는 데 오히려 시간이 더 걸릴 수 있습니다.

이럴 때 리뷰를 별도 흐름으로 보내고 본대화에는 결정과 액션만 남기면, 이후 수정과 보고가 훨씬 단순해집니다. 결국 핵심은 리뷰 자체보다 리뷰 결과를 어떻게 남기느냐에 있습니다.

백그라운드 실행으로 무엇이 달라졌을까

한 줄로 정리하면, /code-review는 최신 버전에서 리뷰 작업을 background subagent로 실행해 대화창을 덜 채우는 방향으로 바뀌었습니다. 다만 이것이 리뷰가 자동으로 시작된다는 뜻은 아닙니다. 사용자가 직접 호출한 리뷰를 분리해 다루기 쉬워졌다는 의미입니다.

/code-review는 자동 실행이 아니라 사용자가 직접 호출하는 리뷰 스킬입니다.

검토 기준일은 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 직접 호출, 결과는 수정 결정 단위로 요약이라는 한 줄 규칙부터 추가하면 됩니다.

참고 자료

https://daker.ai/community/post-mrs89pu0-5fdd40cc
https://daker.ai/community/post-mrwisvw0-8b5cfcad

여러분의 팀에서는 리뷰 결과를 본대화에 얼마나 남기는 방식이 가장 잘 맞았나요?