리바이스 매장 앱, AI 에이전트 17개가 9개월 일을 2.5개월로

여러 AI 에이전트가 같은 코드를 동시에 고치면 서로 부딪혀 난장판이 되지 않을까요? 기업들이 이 시스템을 안전하게 도입할 수 있는 이유는 에이전트의 '지능'이 아니라, 충돌을 막는 '구조'에 있습니다. 실제 리바이 스트라우스(Levi Strauss & Co.)는 매장 앱 개발에 17개의 전문화된 AI 에이전트를 투입해 기존 9개월이 걸리던 개발 기간을 약 2.5개월로 단축했습니다. 모든 풀 리퀘스트(PR)를 5~11개의 독립 에이전트가 검토하고 수정 사항을 자동 커밋하면서도, 최종 병합은 사람이 승인하도록 통제했습니다.

여러 에이전트를 동시에 안전하게 운용하려면 격리, 권한 분리, 인간 승인이라는 세 겹의 안전장치가 필요합니다. 깃허브는 이 원칙을 코파일럿 앱 병렬 세션에 '깃 워크트리(Git Worktree)'로, 에이전틱 워크플로에 'Safe Outputs'로 구현하고 있습니다. 이 세 가지가 어떻게 혼란을 방지하고 병렬 작업의 신뢰성을 확보하는지 구체적으로 살펴보겠습니다.

에이전트는 서버가 아닌 '텍스트 지시문'

흔히 AI 에이전트라고 하면 고사양 서버에서 독립적으로 돌아가는 복잡한 프로그램을 상상하기 쉽습니다. 하지만 제니 패첸(Jenny Patchen) 리바이 스트라우스 시니어 디렉터가 2026년 10월 깃허브 유니버스(GitHub Universe 2026)에서 공개한 실제 사례는 이보다 훨씬 단순하고 투명했습니다 ¹, ². 리바이의 개발 환경에서 에이전트는 실행 파일이 아니라, 깃(Git) 저장소 안의 특정 폴더에 존재하는 마크다운(.md) 텍스트 파일이었습니다.

이 마크다운 파일에는 에이전트가 무엇을 해야 하는지를 알려주는 지시문이 담겨 있습니다. 개발자는 이 텍스트 파일을 직접 수정해 에이전트의 행동을 바꿉니다. 일반적인 애플리케이션 코드를 수정하듯 에이전트의 성격을 조정하고, 변경 사항은 기존 코드와 동일하게 PR을 통해 동료의 검토를 거쳐 버전 관리됩니다 ². 즉, 에이전트는 블랙박스가 아니라 텍스트로 통제 가능한 개발 도구이며, 이를 통해 기업은 AI의 행동을 세밀하게 관리할 수 있습니다.

첫 번째 장치: 워크트리로 물리적 충돌 차단

여러 에이전트가 움직이기 시작하면 가장 먼저 우려되는 것은 파일 충돌입니다. 에이전트 A가 파일을 수정한 직후 에이전트 B가 같은 파일을 덮어쓴다면 코드는 엉망이 될 수밖에 없습니다. 깃허브는 이 문제를 해결하기 위해 코파일럿 앱의 병렬 세션에 '깃 워크트리(Git Worktree)' 기능을 적용했습니다.

깃허브 공식 블로그에서 소개된 '테일스핀 토이즈(tailspin-toys)' 예시에서는 이 방식을 "빨래방에서 세탁기 여러 대를 동시에 돌리는 것"에 비유했습니다 ³. 각 세탁기(세션)를 원하는 설정으로 따로 돌릴 수 있고, 한 세탁기가 끝나기를 기다리지 않고 다른 세탁기를 바로 돌릴 수 있다는 뜻입니다 ³.

여러 대의 세탁기가 동시에 빨래를 돌리더라도 각 세탁기는 자기만의 독립된 공간을 사용하므로 서로 간섭하지 않습니다. 에이전트들이 기능 개발, 코드 검토, 테스트 실행을 동시에 수행하더라도 물리적 파일 충돌이 발생하지 않으며, 개발자는 컨텍스트를 전환할 때 각 세션이 유지하는 마지막 상태를 그대로 이어갈 수 있어 대기 시간을 줄일 수 있습니다 ³.

두 번째 장치: Safe Outputs로 권한 분리

작업 공간이 분리되어 물리적 충돌이 없더라도, 여러 에이전트가 저장소에 직접 파일을 마음대로 쓰고 수정할 수 있다면 저장소는 곧 아수라장이 될 수 있습니다. AI가 폭주하여 무의미한 파일만 잔뜩 만들어낼 위험이 있기 때문입니다. 이를 막기 위해 깃허브는 'Safe Outputs(안전한 출력)'라는 정교한 권한 분리 구조를 도입했습니다.

Safe Outputs 구조에서 에이전트 자체는 깃 저장소에 파일을 직접 쓰거나 명령어를 실행할 수 있는 '쓰기 권한'을 가질 수 없습니다 ⁴. 에이전트는 작업 중 문제를 발견하거나 코드를 수정해야 할 때, 시스템에게 "이런 내용을 이슈로 등록해 주세요" 또는 "이 코드를 수정해 주세요"라는 형태의 '요청'만 구조화된 출력으로 남깁니다 ⁴. 실제 파일 생성이나 코드 수정과 같은 '실행'은 별도의 엄격한 권한을 부여받은 백그라운드 작업이 대행합니다 ⁴.

이 체계는 통제 불가능한 AI의 돌발을 막는 안전장치 역할을 합니다. 기본 설정에서 에이전트가 자동으로 'create-issue(이슈 생성)' 기능에 접근할 수 있더라도, 실행 횟수 상한선(max: 1)이 엄격하게 설정되어 있어 무한 루프에 빠지는 것을 방지합니다 ⁴. 또한 'depends-on' 조건을 활용해 이전 작업이 완료되지 않으면 후속 작업을 대기시키는 순서 제어까지 수행할 수 있습니다 ⁴.

세 번째 장치: 사람의 결정권 유지

기술적인 격리와 권한 통제로 안전함을 구축했다 해도, 최종 결과물에 대한 책임은 사람에게 있어야 합니다. 리바이 스트라우스는 매장 앱 리뉴얼을 진행하면서 요구 사항 작성, 테스트 실행, 보안 스캔 등 17개의 전문화된 에이전트를 배치했습니다 ². 이들은 개발 수명 주기의 전반적인 '실행'을 맡았습니다.

하지만 이 프로세스의 핵심 원칙은 "에이전트는 실행하고, 인간은 결정한다"였습니다 ². 17개 에이전트가 외부 도구와 연동해 코드를 고치고 커밋까지 수행했지만, 실제 라이브 환경에 적용되기 위한 최종 '병합(Merge)' 단계에서는 반드시 사람의 확인과 승인을 거치도록 설계했습니다 ².

기존 프로세스에서 발생했던 6개 역할 간의 12번에 달하는 업무 이관과 대기 시간을 없애 개발 속도를 높이는 동시에, 프로젝트의 최종 승인이라는 결정권과 책임 소재는 명확하게 개발자에게 남겨 두었습니다 ².

실제 작동 흐름을 따라가 보면

이러한 세 가지 장치가 하나로 결합되어 실제 개발 환경에서 어떻게 작동하는지 하나의 기능 추가 과정을 통해 살펴볼 수 있습니다. 이 과정을 보면 AI가 단순히 코드를 빠르게 타이핑해서 시간을 절약하는 것이 아님을 알 수 있습니다.

가장 먼저 요구 사항 에이전트가 새로운 기능 요청을 확인하고, 개발자가 검토할 수 있는 스펙 초안을 마크다운 형식으로 작성합니다. 사람이 이 스펙의 우선순위를 확정하고 승인을 내리면 빌드 에이전트가 이를 기반으로 실제 코드를 작성하여 PR을 생성합니다 ².

생성된 PR을 향해 5~11개의 독립적인 리뷰 에이전트가 동시에 접근하며, 문제점을 발견하면 코드 라인에 직접 코멘트를 남기거나 코드를 수정하여 브랜치에 커밋합니다 ². 마지막 단계에서 개발자는 여러 에이전트가 남긴 코멘트와 자동 수정된 결과를 한눈에 살펴본 뒤, 최종적으로 병합 버튼을 누릅니다.

결과적으로 리바이 스트라우스의 백 포켓 앱 개발 기간은 약 9개월에서 2.5개월로 줄었습니다 ². 이는 AI가 인간의 코딩 속도 자체를 끌어올려서가 아닙니다. 대신 각 전문 에이전트가 대기 시간을 제거하고 병렬로 과제를 처리하게 함으로써, 프로세스 자체에 걸리는 시간을 구조적으로 압축한 결과입니다. 복잡한 멀티 에이전트 협업 시대에는 AI의 자율성만 믿기보다, 통제된 레일을 깔아주는 것이 기업 환경을 안전하게 보호하는 실질적인 방법입니다.