KMP 프로젝트에서 안드로이드 인스트루먼트 테스트나 iOS 시뮬레이터 빌드는 오래 걸립니다. ./gradlew connectedDebugAndroidTest 한 번 돌리면 에뮬레이터 부팅부터 테스트 실행까지 5분 넘게 걸리는 경우가 흔한데, 이 시간 동안 터미널 앞에서 기다리는 것 말고는 할 게 없었습니다. Claude Code 세션에서도 마찬가지였습니다 — Bash 도구로 빌드 명령을 실행시키면 결과가 나올 때까지 다음 지시를 내릴 수 없었습니다.
이 문제를 Claude Code의 백그라운드 실행 옵션으로 풀었습니다. Bash 도구 호출에 run_in_background: true를 넘기면 명령이 완료를 기다리지 않고 바로 다음 턴으로 넘어갑니다. 예를 들어 다음처럼 지시했습니다.
"./gradlew connectedDebugAndroidTest를 백그라운드로 돌리고, 끝나면 알려줘. 기다리는 동안 LoginViewModel 리팩터링을 먼저 진행해줘."
이렇게 하면 테스트가 에뮬레이터에서 돌아가는 동안 Claude Code는 곧바로 LoginViewModel 파일을 열어 리팩터링을 시작합니다. 백그라운드 프로세스가 끝나면 별도 알림이 세션에 도착하고, 그 시점에 테스트 로그를 확인해서 통과 여부를 판단하는 식으로 작업 순서를 짰습니다.
처음에는 백그라운드로 넘긴 작업 상태를 계속 물어봐야 하는 줄 알고 "테스트 아직 안 끝났어?"를 반복해서 물었는데, 이러면 오히려 대화 턴만 소모됩니다. Claude Code는 백그라운드 작업이 끝나면 알아서 알림을 큐에 넣고 다음 턴에 전달하기 때문에, 폴링하듯 물어보는 대신 다른 작업을 계속 시키고 알림이 올 때까지 놔두는 편이 더 빨랐습니다.
또 하나 헷갈렸던 부분은 여러 개를 동시에 백그라운드로 돌릴 때였습니다. 안드로이드 테스트와 iOS 시뮬레이터 빌드를 각각 run_in_background: true로 따로 실행시키면 두 결과가 도착하는 순서가 뒤섞여서, 어떤 알림이 어떤 명령의 결과인지 헷갈리는 경우가 있었습니다. 이후로는 지시할 때 "안드로이드 테스트 결과"와 "iOS 빌드 결과"처럼 알림 메시지에 구분자를 명시적으로 넣어달라고 요청해서 헷갈림을 줄였습니다.
결과적으로 긴 빌드나 테스트를 기다리는 동안 손 놓고 있는 시간이 줄었습니다. 다만 백그라운드 작업이 실패했을 때 원인을 바로 확인하지 못하고 다른 작업을 이어가다가 뒤늦게 실패를 알아채는 경우도 있어서, 실패 가능성이 높은 명령(설정을 막 바꾼 직후의 빌드 등)은 여전히 포그라운드로 먼저 한 번 돌려서 성공을 확인한 다음에만 백그라운드로 반복 실행하는 편이 안전합니다.