Claude Code MCP 백그라운드 운영법: 2분 넘는 도구 호출을 안전하게 다루기

요약: Claude Code 최신 업데이트에서 MCP tool call이 2분을 넘으면 자동으로 background로 이동하는 기능이 들어왔습니다. 이 변화는 작은 UX 개선처럼 보이지만, 실제로는 긴 도구 호출을 어떻게 관찰하고, 승인하고, 실패 처리할지에 대한 운영 문제입니다. MCP를 GitHub, Jira, 데이터베이스, 내부 API와 연결한 팀이라면 기준 시간을 그냥 기본값으로 두지 말고 작업 유형별로 나눠야 합니다.

왜 긴 MCP 호출이 문제가 되나

MCP는 AI 도구가 외부 시스템을 호출하는 표준 인터페이스로 자리 잡고 있습니다. GitHub 이슈 조회, PR 목록 수집, 로그 검색, CRM 데이터 읽기, 사내 문서 검색 같은 작업을 모델 대화 안에서 실행할 수 있습니다. 편합니다. 하지만 호출 시간이 길어지면 문제가 생깁니다.

첫째, 세션이 멈춘 것처럼 보입니다. 사용자는 모델이 생각 중인지, 도구가 실행 중인지, 네트워크가 막힌 것인지 알기 어렵습니다.

둘째, 승인 흐름이 꼬일 수 있습니다. 긴 호출이 foreground를 잡고 있으면 다음 확인 요청이나 취소 판단을 하기 어렵습니다.

셋째, 실패 원인이 흐려집니다. MCP 서버가 느린 것인지, 인증이 만료된 것인지, 대상 API rate limit인지 구분해야 하는데, 긴 대기 하나로 보이면 디버깅이 늦어집니다.

Claude Code v2.1.207–v2.1.212 범위의 업데이트는 이 문제를 줄이기 위해 2분을 넘는 MCP tool call을 자동으로 background 처리합니다. 기준은 CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS로 조정하거나 비활성화할 수 있습니다.

기본 2분이 항상 맞지는 않다

2분은 합리적인 기본값이지만 모든 팀에 맞는 값은 아닙니다. 작업별로 생각해야 합니다.

GitHub PR 목록 조회나 Jira 티켓 검색은 보통 수 초 안에 끝나야 합니다. 이런 호출이 2분을 넘으면 background로 보내는 것보다 실패로 보는 편이 낫습니다. 반대로 대용량 로그 검색, 데이터 웨어하우스 쿼리, 보안 스캔 결과 수집은 2분 이상 걸릴 수 있습니다. 이 경우 background 전환이 자연스럽습니다.

따라서 MCP 서버별로 기대 시간을 정해야 합니다.

GitHub, Linear, Jira 조회: 10~30초 안에 실패 처리 권장.
문서 검색, 벡터 검색: 30~60초 기준 권장.
로그 검색, 분석 쿼리: 2~5분까지 background 허용.
배치성 리포트 생성: foreground가 아니라 처음부터 background 작업으로 설계.

기준 시간을 하나로만 두면 빠른 작업의 장애를 늦게 발견하거나, 느린 작업을 불필요하게 실패 처리할 수 있습니다.

운영 설계: foreground와 background 분리

실무에서 가장 좋은 패턴은 “사용자 판단이 필요한 작업은 foreground, 기다리기만 하면 되는 작업은 background”로 나누는 것입니다.

예를 들어 PR 리뷰 에이전트가 있다고 합시다. 다음 작업은 foreground가 적합합니다.

변경 파일 목록 조회
위험한 명령 실행 승인 요청
리뷰 범위 확인
배포 브랜치 선택

반면 다음 작업은 background가 적합합니다.

전체 테스트 로그 수집
대용량 dependency scan
여러 저장소의 PR 상태 집계
긴 문서 코퍼스 검색

이 구분이 없으면 AI 세션은 쉽게 “멈춘 화면”이 됩니다. background 전환은 UX 기능이 아니라 작업 모델링 문제입니다.

로그와 알림을 꼭 붙여야 한다

긴 MCP 호출을 background로 보내면 세션은 계속 쓸 수 있습니다. 하지만 그 작업이 성공했는지 실패했는지 놓치기 쉽습니다. 따라서 최소한 세 가지 이벤트를 남겨야 합니다.

background 전환 시점: 어떤 tool call이 왜 background로 갔는지.
완료 시점: 성공, 실패, timeout, 취소 중 무엇인지.
결과 요약: 다음 action이 필요한지 여부.

가능하다면 MCP 서버 자체도 correlation ID를 내려야 합니다. Claude Code 세션 로그, MCP 서버 로그, 대상 API 로그를 같은 ID로 묶을 수 있으면 장애 분석 시간이 줄어듭니다.

권한 승인과 background 작업의 경계

특히 조심할 부분은 쓰기 작업입니다. 읽기 작업은 background로 넘겨도 상대적으로 안전합니다. 그러나 쓰기 작업은 다릅니다. 예를 들어 이슈 닫기, PR merge, 배포 trigger, 결제 환불 같은 작업이 background로 넘어가면 사용자는 실행 타이밍을 놓칠 수 있습니다.

권장 원칙은 단순합니다.

읽기 작업은 background 허용.
쓰기 작업은 승인 직후 실행 상태를 명확히 보여준다.
irreversible action은 background 자동 전환을 피한다.
긴 쓰기 작업은 별도 job queue와 상태 페이지로 관리한다.

AI 도구에서 가장 무서운 장애는 실패가 아닙니다. 사용자가 모르는 사이에 성공하는 것입니다.

팀에 바로 적용할 설정 예시

팀 표준 문서에 다음 항목을 넣어두면 좋습니다.

MCP 서버별 기대 응답 시간
background 허용 여부
timeout 기준
실패 시 재시도 횟수
쓰기 작업 승인 규칙
결과 알림 위치
로그 correlation ID 규칙

예를 들어 “GitHub MCP: 읽기 30초 timeout, 쓰기 foreground만 허용, background 금지”, “Log MCP: 5분 background 허용, 완료 시 thread 댓글 알림”처럼 구체적으로 적어야 합니다.

실행 체크리스트

현재 연결된 MCP 서버 목록을 정리한다.
서버별 평균 응답 시간과 최악 응답 시간을 측정한다.
CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS 기본값이 팀 작업에 맞는지 검토한다.
읽기, 쓰기, irreversible action을 분류한다.
background 전환, 완료, 실패 이벤트가 로그에 남는지 확인한다.
긴 작업에는 correlation ID를 붙인다.
쓰기 작업은 background 자동 전환을 제한한다.
사용자에게 “진행 중”, “완료”, “실패” 상태가 보이게 만든다.

Claude Code의 MCP background 처리는 긴 작업을 다루는 좋은 기본 장치입니다. 하지만 기본값만 믿으면 운영 기준이 흐려집니다. 팀이 해야 할 일은 기능을 켜는 것이 아니라, 어떤 도구 호출을 기다리고 어떤 호출을 분리할지 정하는 것입니다. 그 기준이 있어야 AI 도구가 실제 개발 업무에서 믿을 수 있는 동료가 됩니다.