mic-lock으로 AI 에이전트 테스트 충돌 해결하기

코딩 에이전트(Coding agents)가 이제 실제 기기에서 테스트를 수행할 수 있습니다. 하지만 이들을 한꺼번에 여러 개 실행하면 충돌이 발생합니다. 여기 에이전트들이 차례를 지키게 만드는 작은 오픈 소스(open-source) 도구가 있습니다.

Claude는 이제 모바일 앱의 전체 테스트 루프(testing loop)를 스스로 처리할 수 있습니다. 코드를 작성하고, 빌드하고, 에뮬레이터(emulator)나 실제 기기에 설치하고, 실행한 뒤, UI를 조작하여 자신의 작업물을 확인하는 과정까지 말이죠. 이제 테스트는 사람이 다시 돌아와 수동으로 마무리해야 하는 단계가 아닙니다.

에이전트가 스스로 테스트할 수 있게 되면, 한 번에 하나씩만 실행하는 단계는 지나게 됩니다. 하나의 Git 워크트리(worktree)에는 Claude에게 첫 번째 티켓을 주고, 두 번째 워크트리에는 다른 티켓을, 세 번째에는 또 다른 티켓을 넘겨주면, 이제 여러 에이전트가 동일한 노트북에서 병렬로(in parallel) 서로 다른 작업을 수행하게 됩니다. 이것이 현재의 빠른 작업 방식이며 매우 훌륭하지만, 두 에이전트가 동일한 기기를 원하게 되는 순간 문제가 발생합니다.

문제: 왜 병렬로 실행되는 Claude 에이전트들이 공유 에뮬레이터에서 충돌하는가

사용자의 기기는 오직 몇 개의 에뮬레이터만 실행할 수 있습니다. 다음과 같은 상황을 가정해 봅시다.

에이전트 A가 자신의 기능을 완료하고, emulator-5554에 빌드를 설치한 뒤, 앱을 실행하고 흐름을 확인하기 위해 탭(tap) 동작을 시작합니다.

테스트 도중, 완전히 다른 티켓에 집중하고 있던 에이전트 B가 동일한 에뮬레이터에 자신의 빌드를 설치하고 UI 조작을 시작합니다.

이제 에이전트 A는 거울의 방(hall of mirrors)에 갇힌 것과 같은 상태가 됩니다. 실행 중인 앱에서 자신의 변경 사항이 사라진 것을 보고, 존재하지 않는 회귀(regression) 현상을 추적하기 시작합니다. 화면은 갑자기 튀고, 자신이 명령하지 않은 탭(tap)이 발생합니다(이것은 에이전트 B의 자동화 동작입니다). 에이전트 A는 유령 내비게이션과 "플래키(flaky)"한 동작을 조사하기 시작합니다.

두 테스트 실행 모두 오염되었으며, 어떤 에이전트도 실제로 잘못을 저지른 것은 아닙니다. 단지 서로를 볼 수 없을 뿐이며, 기기 상의 그 무엇도 그들에게 차례를 기다리라고 말해주지 않았을 뿐입니다.

이 모든 사실은 혼란에 빠진 두 개의 트랜스크립트(transcripts)와 낭비된 토큰(tokens) 더미를 검토하기 위해 자리에 앉았을 때야 알게 됩니다.

해결책은 락(Lock)입니다

이것은 새로운 옷을 입은 오래되고 해결된 문제입니다. 두 가지가 하나의 공유 자원(shared resource)을 원할 때, 그 자원에 락(Lock)을 거는 것이죠. Mic-lock은 각 장치를 에이전트가 무언가를 설치하거나 테스트를 실행하기 전에 반드시 쥐어야 하는 락으로 변환합니다.

• 장치가 비어 있다면, 에이전트가 이를 점유하여 작업을 시작합니다.
• 장치가 사용 중이라면, 에이전트는 무엇도 짓밟지(clobber) 않습니다. 대신 **공정하고 선착순인 대기열(fair, first-come queue)**에 합류하며, 장치가 해제되는 즉시 장치를 넘겨받습니다.

신뢰할 만한 가치가 있는 이유인, 내부에서 일어나는 일의 일부를 설명하자면 다음과 같습니다:

• 두 개의 계층 (Two layers). 마이크로초 단위로 유지되는 아주 작은 게이트가 모든 결정을 직렬화(serialize)하므로, 두 에이전트가 동시에 빈 장치를 "획득"하는 일은 결코 발생할 수 없습니다. 장치에 대한 실제 점유는 하트비트(heartbeat)가 포함된 임대(lease) 방식입니다.
• 충돌 안전 (Crash-safe). 임대가 하트비트 방식으로 작동하기 때문에, 테스트 도중 종료된 에이전트가 에뮬레이터를 영원히 고착(wedge)시키지 않습니다. 해당 점유는 단순히 만료되며, 대기열의 다음 에이전트가 장치를 회수합니다.
• 좀비 없음 (No zombies). 모든 점유에는 **펜싱 토큰(fencing token)**이 포함되어 있어, 속도가 느렸거나 밀려난 에이전트가 나중에 다시 돌아와 이미 다른 사람에게 넘어간 장치를 해제하거나 짓밟는 일을 방지합니다.
• 인프라 불필요 (No infrastructure). 이 모든 것은 ~/.mic-lock 아래에서 이루어지는 원자적 파일 시스템 작업(atomic filesystem operations)입니다. 서버도, 데몬(daemon)도, Redis도 필요 없습니다. 그냥 바로 작동합니다.

이 중 어느 것도 이론적인 것이 아닙니다. 장치의 슬롯 수보다 많은 점유자가 존재하지 않아야 하며, 조용한 이중 설치(silent double-install)가 없어야 한다는 핵심 안전 속성은 구조적으로 유지되며, 스트레스 테스트가 이를 뒷받침합니다: 10개의 경합 프로세스, 종료된 점유자의 회수, 용량 초과 없음.

한 번만 설정하면 됩니다; 나머지는 에이전트가 합니다

핵심은 이 명령들을 아무도 수동으로 실행하지 않는다는 점입니다. 당신은 단 한 번만 명령어를 실행하면 됩니다:

mic-lock setup            # 이 머신에 설정

# 또는: mic-lock setup --project   # 리포지토리(repo)에 커밋되어 함께 이동함

이렇게 하면 당신의 Claude 설정에 세 가지가 설치됩니다:

1. 스킬 (skill): 에이전트가 한 번에 장치를 점유하여 작업 전체 동안 유지한 다음, 이를 해제하도록 가르치는 스킬입니다.
2. 가드 훅 (guard hook): 에이전트가 잠금(lock)을 보유하지 않은 상태에서 실행하려는 모든 장치 명령을 차단하고, 이를 어떻게 해결해야 하는지 정확히 알려주는 가드 훅입니다. 이 부분은 결정론적(deterministic)이므로, 모델이 예의 바르게 행동하는 것을 기억하는지에 의존하지 않습니다.
3. 명명 규칙 (naming rule): 모든 에이전트가 동일한 ID로 동일한 장치를 잠그도록 하는 명명 규칙입니다.

그 이후에는 에이전트들이 스스로 협력합니다. 내부적으로는 단순히 다음을 실행합니다:

mic-lock acquire emulator-5554 --owner "checkout smoke" --wait   # 자신의 차례를 기다림

# …설치, 실행, 테스트…
...

또는 일회성 명령을 래핑(wrapping)하여, 충돌(crash)이 발생하더라도 자동으로 해제되도록 할 수 있습니다:

mic-lock with emulator-5554 -- <build-install-test command>

그리고 군집(swarm)이 무엇을 하고 있는지 궁금할 때는, mic-lock status를 통해 누가 무엇을 보유하고 있고 누가 줄을 서서 기다리고 있는지 확인할 수 있습니다. 세 개의 별도 트랜스크립트(transcript)를 읽는 대신 한눈에 파악할 수 있습니다.

사용해 보기

npm install -g mic-lock  

mic-lock setup  
...

Node 18 이상이 필요합니다. Android 탐색에는 adb를 사용하고, iOS에는 xcrun simctl을 사용하며, 잠금(lock) 자체에는 둘 다 필요하지 않습니다. MIT 라이선스이며 오픈 소스입니다.

GitHub: github.com/Michael23Magdy/mic-lock · npm: mic-lock

한 대의 머신에서 Claude 에이전트를 병렬로 실행하기 시작했다면, 이것은 에이전트들이 서로의 장치를 짓밟지(clobbering) 않도록 유지해 주는 핵심 요소입니다. 한 번 설정해 두면 신경 쓸 필요가 없습니다.