Mistral Vibe 서브에이전트 실전 가이드: 테스트·리뷰·배포 준비를 병렬화하는 법

AI 코딩 도구를 오래 쓰다 보면 묘한 병목이 생깁니다. 코드 생성은 빨라지는데 테스트는 비고, 리뷰는 얕아지고, 배포 직전에는 세션 맥락이 꼬입니다. 이럴 때 필요한 건 더 큰 만능 에이전트가 아니라, 테스트·리뷰·배포 준비를 따로 맡는 서브에이전트 구조입니다.

이번 글은 Mistral Vibe를 예시로 쓰지만, 핵심은 도구보다 운영 방식입니다. 하나의 메인 에이전트에 모든 일을 몰아주지 않고, 반복 가능하고 책임이 분명한 일을 별도 에이전트로 떼어내 병렬화하는 방법을 실전 기준으로 정리하겠습니다.

 

하나의 터미널 작업 공간에서 테스트, 코드 리뷰, 배포 준비를 맡은 세 개의 서브에이전트가 분기되어 동시에 동작하는 모습을 보여주는 일러스트

 

먼저 핵심부터: 서브에이전트는 "더 많은 AI"가 아니라 "더 좁은 책임"이다

서브에이전트를 도입할 때 가장 흔한 오해는 "에이전트를 많이 만들수록 더 강해진다"는 생각입니다. 실제로는 반대에 가깝습니다. 잘 작동하는 서브에이전트는 똑똑해서가 아니라, 해야 할 일이 좁고 실패 조건이 명확해서 잘 작동합니다.

하나의 메인 에이전트에 구현, 테스트, 리팩터링, 리뷰, 배포 판단을 전부 얹으면 세션이 길어질수록 우선순위가 흐려집니다. 방금 수정한 코드와 충돌하는 제안이 나오고, 이미 확인한 사실을 다시 흔드는 일도 늘어납니다. 이 병목은 제가 예전에 쓴 2026년 AI 시대 소프트웨어 개발 변화 정리: 코드는 쉬워지고 ‘코드 이해력’이 핵심이 된 이유와도 닿아 있습니다.

서브에이전트는 이 문제를 해결하기 위해 존재합니다. 테스트 전용은 테스트만, 리뷰 전용은 위험 징후만, 배포 준비 전용은 최종 점검만 보게 만드는 것이 핵심입니다. 즉, 본질은 병렬화 자체가 아니라 컨텍스트를 덜 섞이게 만드는 운영 분리입니다.

 

 

Mistral Vibe에서 지금 바로 시작할 최소 경로

현재 공식 설치 문서 기준으로 Mistral Vibe는 macOS/Linux에서 아래 한 줄로 설치할 수 있고, vibe 실행 후 테마와 API 키를 설정한 뒤 바로 프로젝트 맥락을 읽기 시작합니다. (docs.mistral.ai)

curl -LsSf https://mistral.ai/vibe/install.sh | bash
cd your-project
vibe

 

여기서 중요한 건 설치보다 실행 위치입니다. 빈 폴더에서 장난감처럼 돌리기보다, 최소한 Git 이력이 있고 구조가 잡힌 저장소에서 시작하는 편이 낫습니다. 공식 GitHub README도 Vibe가 프로젝트 파일 구조와 Git 상태를 스캔해 맥락을 잡는다고 설명합니다. (github.com)

그리고 한 가지 더 기억해야 합니다. Agents & Skills 문서에 따르면 서브에이전트는 독립적으로 실행되고, 사용자와 상호작용하지 않은 채 결과를 텍스트로 반환합니다. 그래서 애매한 업무보다 경계가 분명한 업무에 더 잘 맞습니다. (docs.mistral.ai)

 

 

어디에 저장할까: 전역 에이전트와 프로젝트 로컬 에이전트

여기서 한 번 헷갈립니다. 현재 공식 문서는 커스텀 에이전트 예시를 ~/.vibe/agents/ 아래에 두고 설명합니다. 반면 공식 GitHub README는 커스텀 에이전트 파일을 사용자 전역뿐 아니라 프로젝트의 .vibe/agents/ 디렉터리에서도 찾는다고 안내합니다. (docs.mistral.ai)

실전에서는 이렇게 정리하면 편합니다.

• 여러 프로젝트에서 계속 쓸 역할이면 ~/.vibe/agents/
• 팀 저장소와 함께 공유할 역할이면 프로젝트의 .vibe/agents/

 

영상에서 프로젝트 로컬 에이전트를 만든 이유도 여기에 가깝습니다. 팀 단위로 재사용하려면 저장소 안에 두는 편이 자연스럽습니다.

 

 

처음 만들 서브에이전트는 세 개면 충분하다

처음부터 프론트엔드 전용, 백엔드 전용, 보안 전용, 리팩터링 전용, 문서화 전용으로 무한 분화할 필요는 없습니다. 처음에는 아래 세 개가 가장 실용적입니다.

 

역할	맡길 일	굳이 맡기지 말 일
테스트 작성기	누락된 pytest 추가, 실패 케이스 재현, 인증/응답 테스트	배포 판단, 대규모 리팩터링
코드 리뷰어	보안, 성능, 예외 처리, 구조적 위험 탐지	파일 직접 수정, 배포 실행
배포 준비 담당	전체 테스트, 린트, 최종 체크리스트	새 기능 구현, 구조 개편

 

이 구성이 좋은 이유는 메인 에이전트가 "통합자" 역할에 집중할 수 있기 때문입니다. 요구사항 해석과 최종 의사결정은 메인 세션에 남기고, 반복적이고 경계가 분명한 일을 떼어내는 편이 전체 흐름이 덜 지저분해집니다.

 

메인 에이전트가 테스트 작성기, 코드 리뷰어, 배포 준비 서브에이전트로 역할을 나누어 위임하는 흐름을 보여주는 다이어그램

 

진짜 중요한 건 설명문이 아니라 권한 스코프다

서브에이전트를 만들 때 사람들이 설명문에만 공을 들이는데, 실제로 결과를 좌우하는 건 권한입니다. 공식 README에도 도구를 enabled_tools와 disabled_tools로 제어하고, 필요하면 [tools.bash] permission = "always"처럼 도구별 승인 정책을 따로 잡을 수 있다고 나옵니다. (github.com)

예를 들어 이런 식입니다.

# .vibe/agents/test-writer.toml
display_name = "Test Writer"
description = "Write backend pytest coverage only"
safety = "neutral"
agent_type = "subagent"
enabled_tools = ["read_file", "write_file", "search_replace", "grep", "bash"]

# .vibe/agents/code-review.toml
display_name = "Code Review"
description = "Review security, performance, and error handling without editing"
safety = "safe"
agent_type = "subagent"
enabled_tools = ["read_file", "grep"]

# .vibe/agents/deploy-prep.toml
display_name = "Deploy Prep"
description = "Run tests and lint, then report deploy blockers"
safety = "neutral"
agent_type = "subagent"
enabled_tools = ["read_file", "grep", "bash"]

 

이 설계가 중요한 이유는 단순한 안전성 때문만이 아닙니다. 권한이 넓을수록 에이전트가 더 유능해지는 것이 아니라, 쓸데없는 시도를 더 많이 하게 되는 경우가 많습니다. 코드 리뷰어에 bash를 주지 않는 것만으로도 리뷰가 훨씬 또렷해질 수 있습니다.

실전에서는 아래 네 가지 질문부터 던지면 됩니다.

• 이 역할은 파일을 수정해야 하나
• 읽기만 하면 충분한가
• 테스트나 린트를 실제로 돌려야 하나
• Git, 네트워크, 자동 승인까지 정말 필요한가

 

병렬화의 적은 모델 성능보다 승인 정책인 경우가 많습니다. 승인 팝업이 줄지 않으면, 에이전트를 여러 개 띄워도 사람이 병목이 됩니다.

 

 

실제 호출은 거창한 문법보다 "명확한 위임"이 더 중요하다

서브에이전트를 쓸 때는 특이한 문법을 외우는 것보다, 메인 에이전트에게 애매하지 않게 위임하는 편이 더 중요합니다. 영상에서도 결국 이런 흐름으로 갑니다.

Run the test-writer subagent in the background and add backend authentication tests.
Run the code-review subagent and report only security and performance issues.
Run the deploy-prep subagent after tests pass and tell me whether this repo is ready to deploy.

 

여기서 포인트는 세 가지입니다.

• 산출물을 좁게 말할 것
• 수정 범위를 한정할 것
• 최종 답변 형식을 지정할 것

 

서브에이전트는 질문을 되묻는 식으로 조율하기 어렵기 때문에, "전반적으로 봐줘"보다 "인증 테스트만 추가해", "보안과 성능만 리뷰해", "배포 차단 사유만 말해" 같은 요청이 훨씬 잘 맞습니다.

 

 

병렬화는 독립성이 있을 때만 빨라진다

병렬 실행이 멋져 보여도, 아무 작업이나 동시에 돌리면 오히려 느려집니다. 특히 여러 에이전트가 같은 파일을 동시에 만지거나, 같은 문제를 다른 말로 중복 검토하면 메인 에이전트가 나중에 충돌을 정리하느라 더 오래 걸립니다.

 

병렬화가 잘 맞는 경우는 아래처럼 독립성이 있을 때입니다.

• 테스트 추가와 코드 리뷰처럼 주요 산출물이 겹치지 않을 때
• 배포 준비처럼 자체 체크리스트가 분명할 때
• 메인 에이전트가 결과를 통합만 하면 될 때

 

반대로 아래 상황에서는 병렬화가 거의 소음이 됩니다.

• 여러 에이전트가 같은 파일을 수정할 때
• 책임 범위가 겹칠 때
• 승인 요청이 연달아 떠서 사람이 병목이 될 때

 

영상에서도 바로 이 장면이 나옵니다. 테스트 에이전트를 여러 개 띄우자 승인 요청이 계속 튀어나옵니다. 그래서 자동 승인을 쓸 때도 전체를 한 번에 열기보다, 정말 반복적이고 안전한 도구에만 국소적으로 여는 편이 낫습니다.

 

 

사람들이 자주 놓치는 숨은 마찰

 

메인 에이전트와 서브에이전트는 용도가 다르다

커스텀 메인 에이전트는 세션의 기본 성격을 바꾸는 데 가깝고, 서브에이전트는 특정 업무를 잠깐 떼어내는 데 가깝습니다. 둘을 혼동하면 "왜 전체 흐름을 이 에이전트가 대신 정하지 않지?" 같은 어색한 기대가 생깁니다.

 

 

로컬 실행 가능하다고 해서 가볍다는 뜻은 아니다

Offline / Local 문서는 Devstral Small 2를 로컬용으로 추천하지만, 긴 컨텍스트에서 효율적으로 돌리려면 H100/A100급 GPU가 필요할 수 있고, 설정을 낮춰도 32k 컨텍스트 기준 최소 RTX 4090 또는 24GB VRAM 정도를 예시로 듭니다. "로컬 가능"을 "노트북에서 바로 쾌적"으로 받아들이면 여기서 많이 틀어집니다. (docs.mistral.ai)

 

특정 도구에만 묶어 생각하면 오히려 활용 폭이 줄어든다

이 구조는 Mistral Vibe 전용 발상이 아닙니다. 다른 터미널형 코딩 도구에서도 충분히 응용할 수 있습니다. 비슷한 맥락은 Claude Code 잘 쓰는 법: 2026년 생산성 높이는 설정, 플러그인, MCP 서버 가이드와도 이어집니다.

 

처음 적용한다면 이렇게 시작하는 게 가장 덜 실패한다

처음부터 에이전트 군집을 설계하려 하지 말고, 지금 프로젝트에서 가장 반복적이고 가장 귀찮은 일 하나를 떼어내 보세요. 대부분은 테스트 추가가 첫 후보입니다. 그다음에 읽기 전용 코드 리뷰어를 붙이고, 마지막으로 배포 준비 담당을 붙이면 됩니다.

흐름은 대체로 이렇게 가면 됩니다.

1. 메인 에이전트가 기능 구현
2. 테스트 작성기가 누락 테스트 추가
3. 코드 리뷰어가 위험 지점 보고
4. 배포 준비 담당이 최종 점검
5. 메인 에이전트가 결과를 통합하고 마지막 수정

 

핵심은 "에이전트를 많이 쓰는 것"이 아니라, 메인 세션이 계속 들고 있으면 흐려지는 일을 얼마나 잘 떼어냈느냐입니다. Mistral Vibe는 그 구조를 실험하기 좋은 도구고, 진짜 차이는 어떤 일을 누구에게 맡길지 정하는 운영 감각에서 납니다.

 

 

FAQ

 

서브에이전트는 많이 만들수록 좋은가요?

아닙니다. 메인 에이전트가 다시 긴 설명을 붙이지 않아도 되는 역할만 살아남겨야 합니다. 처음에는 테스트 작성기, 코드 리뷰어, 배포 준비 담당 정도로 시작하는 편이 가장 안정적입니다.

 

에이전트 파일은 전역과 프로젝트 로컬 중 어디에 두는 게 좋나요?

여러 저장소에서 공통으로 쓸 역할이면 ~/.vibe/agents/가 편하고, 팀과 함께 공유할 역할이면 프로젝트의 .vibe/agents/가 낫습니다. 개인 취향이 강한 설정은 전역, 협업 자산은 프로젝트 로컬이라고 생각하면 보통 맞습니다.

 

 

마무리

서브에이전트의 가치는 화려한 멀티 에이전트 데모에 있지 않습니다. 테스트, 리뷰, 배포 준비처럼 책임이 뚜렷한 일을 따로 떼어낼 때 메인 세션이 덜 꼬이고, 병렬화도 그제야 의미가 생깁니다.

처음부터 거대한 체계를 만들 필요는 없습니다. 지금 쓰는 저장소에서 가장 반복적이고 가장 귀찮은 업무 하나를 고른 뒤, 그 일만 잘하는 서브에이전트 하나부터 만들어 보세요. 대부분의 경우 작업 흐름이 바뀌는 출발점은 거기입니다.