출시: 여러 Claude Code 에이전트를 하나의 레포에서 돌려봤는데, 각각은 성공했지만 병합된 앱은 매번 망가졌습니다. 해결책을 공유합니다 (오픈 소스)

그럴 수도 있겠네요. 하지만 가정하기보다는 직접 측정해보는 게 중요합니다. worktree와 병합 단계를 사용하는 건 제 브랜치 모드와 비슷합니다. 각 작업은 독립된 클론을 가지므로 worktree처럼 격리되고, 에이전트가 병합 시점에 충돌을 해결하죠. 하지만 5번의 실행 모두 git이 표시한 텍스트 충돌 2개는 해결했지만 실제 충돌은 놓쳤습니다. 텍스트상으로는 충돌이 없었으니까요. 오케스트레이터가 diff의 의미를 검토하거나 병합 후 전체 테스트를 돌린다면 더 나을 수도 있겠지만, 그건 두 에이전트가 작업을 끝낸 뒤에야 오류를 잡아내는 방식이라 누군가는 한쪽 작업을 다시 해야 합니다. 공유 디렉토리는 잘못된 코드가 작성되기 전에 오류를 잡아냈죠. 혹시 선호하는 오케스트레이터 설정이 있다면, 제 랩에서 새로운 모드를 지원하니 같은 충돌 상황에서 테스트해보고 싶네요.

작업 간 테스트(cross-task test) 포인트가 실제 복잡한 시스템이 어떻게 망가지는지를 가장 잘 보여주네. 한쪽 변경이 다른 작업이 의존하던 가정을 뒤흔들 때, 각각의 green check는 별 의미가 없지. 공유 작업 공간(shared workspace)을 쓰는 거랑 contract-style integration test 몇 개를 추가하는 거랑, 각각 실패율을 얼마나 낮춰줄지 궁금하네.

그 부분까지는 측정 안 해봤는데, 실험 결과를 보면 둘이 경쟁하는 게 아니라 서로 다른 역할을 하는 것 같아. 내 37개 acceptance test는 사실상 contract-style integration test인데, 에이전트들은 이걸 본 적이 없어. 그냥 마지막에 판정만 내리는 용도였거든. 만약 브랜치에서 작업하는 에이전트들한테 그 테스트를 줬더라도, export 에이전트 브랜치에는 여전히 새 로그인이 없으니까 contract test는 거기서 통과하고 merge 후에야 실패하겠지. Contract test는 오류를 감지하는 거고, 격리(isolation)는 언제 오류를 발견하느냐의 문제인 거야. 공유 작업 공간에서는 export 에이전트가 작업하는 도중에 같은 테스트가 실패할 거야. 새 로그인이 이미 디스크에 있으니까 그 자리에서 바로 수정할 수 있거든. 그래서 내 생각엔 contract test랑 브랜치를 쓰면 merge 시점에 다 잡아낼 수 있고, 공유 작업 공간을 쓰면 코드가 완성되기 전에 미리 잡아낼 수 있는 것 같아. 두 방식 다 에이전트한테 테스트를 제공해서 실험해보면 확실히 알 수 있겠지. 실험실에 추가하기엔 저렴한 실험이니까.

두 사람한테 같은 영역에서 일하라고 하면, 한 명은 머지 컨플릭트를 처리해야 할 거야. 그리고 가끔은 머지했을 때 기능이 고장 나기도 하지. 그래서 우리가 작업을 분리하려고 하는 거고, 두 사람이 같은 파일을 건드리지 않게 하는 거야. 그리고 그게 우리가 피처 브랜치를 머지할 dev 브랜치를 따로 두는 이유이기도 하고.

맞아, 그리고 그게 대부분의 팀이 일하는 방식이지. 내 실험에서 문제가 됐던 건, 앱을 고장 낸 두 가지 충돌이 이미 서로 다른 파일에 있었다는 거야. 한 에이전트는 로그인을 수정했고, 다른 에이전트는 별도의 파일에서 그 구식 로그인을 호출하는 내보내기 기능을 만들었거든. 파일별로 분리해놔도 서로 방해하지 않으면서 여전히 고장이 발생했어. 왜냐하면 의존성은 코드가 어디에 있느냐가 아니라 코드가 무엇을 의미하느냐에 있었으니까. dev 브랜치는 그걸 잡아내기에 적절한 곳이지만, '새로운 로그인으로 내보내기가 잘 작동하는지'처럼 기능을 통합해서 테스트하는 무언가가 있어야 해. 또 다른 차이점은 팀원들은 스탠드업 미팅이나 채팅에서 '나 로그인 수정 중이야'라고 말하는데, 에이전트들은 기본적으로 그러지 않는다는 거지. 내 에이전트들에게 서로 메시지를 보낼 수 있는 툴을 줬더니, 알아서 딱 그렇게 하기 시작하더라.

네가 말한 포인트들은 사실이지만, AI 에이전트 이전에도 존재하던 문제들이야. 인간들이 하는 해결책은 이거지:

1. 머지 전에 모든 애플리케이션 테스트를 실행하는 자동화된 테스트가 포함된 CI.

2. 이건 설계 문제인 것 같아. 만약 내보내기 기능이 로그인에 의존해야 한다면, 의존성 역전 원칙을 사용해야 할 거야 (내보내기 기능이 필요한 것을 요청하게 하고, 로그인이 데이터를 제공하게 하는 방식).

3. 이게 아마 가장 까다로운 부분일 텐데, 브레이킹 체인지를 어떻게 피할까? 가능하다면 설계 단계에서 피하고, 안 된다면 다른 사람들에게 알리는 게 최선이지. 아니면 순차적으로 하거나 피처 플래그를 쓰거나. 내 생각엔 그게 네 이야기의 핵심인 것 같아!

그래서 결론적으로 너는 뭘 하는 거야? 다른 에이전트들을 멈추는 거야?

완전 동의해. 이건 새로운 게 아니고 팀들이 항상 겪어온 문제들이며, 네가 말한 세 가지 답변이 정답이야. 머지 결과물에 대한 CI가 내 모든 실행에서 고장을 잡아냈지. 더 나은 설계라면 이런 의존성들을 제거했겠지만, 난 실제 코드베이스에 브레이킹 체인지가 존재한다는 걸 보여주려고 일부러 그렇게 실험을 설계했어. 그리고 네 세 번째 포인트가 바로 내 이야기의 핵심이야: 다른 사람들에게 알리거나, 순차적으로 처리하거나.

솔직히 말해서, 머지하고 나서 초록불 떴다가 고장 나는 일을 겪은 뒤로는, 로그인+내보내기를 한꺼번에 확인하는 cross-tasks.spec.ts 파일을 4개 체크해서 유지하고 있어. 그 파일 하나만 통과 안 되면 머지 안 해. 구식 로그인 호출하는 거 두 번이나 잡아냈음.