프런트엔드 AX 설계기 2편 — 에이전트를 '자율 실행'에서 '명시적 동의'로
1. 도입부 (Why This Matters)
에이전트 도구를 처음 세팅하면 거의 모두 "자동"에 끌린다. 리뷰 에이전트, 문서 에이전트, 비평 에이전트를 만들어 두면 알아서 끼어들어 일을 거든다 — 적어도 그럴 거라 기대한다. 나도 그렇게 시작했다. 역할별 커스텀 에이전트 6개를 만들고, 요청이 들어오면 시스템이 알아서 적절한 에이전트를 골라 활성화하도록 했다.
그리고 몇 주 뒤, 그 자동 활성화를 전부 껐다. 모든 에이전트를 명시적으로 호출할 때만 실행되는 '기본 OFF' 정책으로 되돌렸다.
이 글은 그 회귀의 기록이다. 왜 자율성을 포기했는지, 그 대가로 무엇을 잃었는지, 그리고 "수백 개 에이전트를 상시 돌린다"는 마케팅을 최신 논문·토큰 데이터로 걸러낸 뒤 내린 절충안까지 다룬다. 도입을 고민하는 리드라면, 똑같은 시행착오를 건너뛰고 활성화 모델을 처음부터 의사결정 문제로 바라볼 수 있을 것이다. (약 8분)
AX(Agent Experience): 사람을 위한 UI를 설계하듯, 에이전트가 관여하는 인터페이스를 설계하는 일. 이 글에서 다루는 "에이전트를 어떻게 활성화할 것인가"는 결국 개발자와 시스템 사이의 인터페이스 설계 문제다.
2. 핵심 개념 (What & Why)
자동 활성화(autonomous activation)는 사용자가 요청만 하면 시스템이 스스로 판단해 에이전트를 호출하는 방식이다. 명시적 호출(explicit invocation) 은 사용자가 어떤 에이전트를 쓸지 직접 지정해야만 실행되는 방식이다. 그 사이의 정책 스위치가 바로 기본 OFF(default OFF) — 자동으로는 어떤 에이전트도 부르지 않는다 는 규칙이다.
일상적인 비유를 들면 이렇다. 자동 활성화는 자동문이다. 다가가면 알아서 열린다. 편하지만, 지나가던 사람에게도, 바람에도 열린다. 명시적 호출은 손잡이가 달린 문이다. 열려면 한 번 잡아당겨야 한다. 그 작은 마찰이 "지금 내가 이 문을 연다"는 사실을 분명하게 만든다.
자동이 매력적인 이유는 분명하다. 마찰이 없다. 하지만 자동문은 언제 열릴지를 사용자가 통제하지 못한다. 에이전트에서 이 "통제 불가"는 세 가지 비용으로 돌아온다 — 예측 불가능성, 토큰 비용, 그리고 사용자 신뢰의 하락. 다음 절에서 이 셋을 데이터로 풀어본다.
3. 동작 원리 (How It Works)
두 모델의 실행 경로를 그림으로 비교하면 차이가 분명해진다.
왼쪽(Before)에서는 요청 하나가 라우터를 거쳐 6개 에이전트로 자동 분기한다. 문제는 두 가지다.
첫째, 토큰 비용. Anthropic이 자사 멀티 에이전트 리서치 시스템을 공개하며 밝힌 측정치에 따르면, 멀티 에이전트는 일반 대화 대비 약 15배의 토큰을 쓰고, 토큰 사용량만으로 성능 분산의 약 80%가 설명된다. 즉 멀티 에이전트의 이득은 대부분 "더 많은 연산을 병렬로 쏟아부은" 결과지, 마법 같은 아키텍처 덕분이 아니다. 자동으로 6개를 띄우면 이 15배가 매 요청마다 곱해진다.
둘째, 예측 불가능성과 실패 누적. 멀티 에이전트가 왜 실패하는지를 분석한 연구 MAST("Why Do Multi-Agent LLM Systems Fail?")는 14개 실패 모드를 시스템 설계, 에이전트 간 정렬 오류, 작업 검증 실패의 3개 범주로 정리했다. 자동 활성화는 이 실패 표면을 사용자가 모르는 사이에 넓힌다. "내가 시키지 않은 에이전트가 끼어들어 무언가를 했다"는 경험이 쌓이면, 도구에 대한 신뢰가 무너진다.
오른쪽(After)은 게이트를 하나 둔다. 명시적으로 호출한 에이전트만 통과하고, 나머지는 대기 상태로 둔다. 실행 경로가 단일해지므로 토큰과 결과를 모두 예측·통제할 수 있다. 대가는 단 하나, 매번 호출을 입력하는 마찰이다.
"수백 개 에이전트 상시 활성"은 사실인가? 결론부터 — 현재로선 production 표준이 아니다. 일부 사례에서 부각된 "초다수 에이전트 상시 가동"은 일회성 실험이나 데모 성격이 강하다. 18개 에이전트 아키텍처를 6개 모델에 걸쳐 평가한 벤치마크 AgentArch는, 복잡한 엔터프라이즈 과제에서 최고 성능 모델조차 35.3% 성공에 그쳤고 "더 많이 = 더 좋음"이라는 만능 공식은 성립하지 않으며 모델마다 선호 아키텍처가 다르다고 보고했다. 즉 on-demand로 띄우고(spawn) 콘텍스트를 격리하는 쪽이 2025–26년의 현실적 컨센서스에 가깝다.
4. 실무 적용 (Practical Examples)
✅ 권장 패턴 (Good Practice) — 기본 OFF + 명시적 호출
활성화 정책을 설정 파일(예: AGENTS.md / CLAUDE.md)에 글로 명시해 둔다. 정책이 코드 옆에 있어야 팀이 재현할 수 있다.
# AGENTS.md (발췌) — 에이전트 활성화 정책
## 기본 규칙
- 기본값은 OFF다. 에이전트로의 "자동" 호출(invocation)을 금지한다.
- 커스텀 에이전트는 사용자가 명시적으로 지정할 때만 실행한다.
## 호출 방법
- 명시 호출: `--agent reviewer` 처럼 에이전트 이름을 지정한다.
- 미지정 시: 메인 에이전트가 단일 컨텍스트로 처리한다(추가 spawn 없음).
## 예외: 읽기 전용 fan-out (좁게 허용)
- 상태를 바꾸지 않는 '조회성' 작업에 한해 병렬 spawn 허용.
- 예) 변경 영향 범위 스캔, 규칙 스캔
- 쓰기(수정·생성) 작업은 절대 병렬화하지 않는다.실제 사용 시 차이는 이렇게 드러난다.
# ❌ Before — 요청만 하면 에이전트 6개가 자동으로 끼어든다
> 이 변경분 리뷰해줘
# auditor, librarian, oracle, critic, reviewer, builder 가 제각기 활성화
# → 토큰 폭증 + 무엇이 돌았는지 사후에야 파악
# ✅ After — 필요한 에이전트만 명시적으로 부른다
> --agent reviewer 이 변경분 리뷰해줘
# reviewer 만 실행. 나머지는 대기.
# → 토큰·결과 예측 가능❌ 안티패턴 (Anti-Pattern) — "알아서 다 해주는" 자동 분기
흔한 실수는 "똑똑하게 자동 라우팅하면 사용자가 더 편하다"는 가정이다. 문제는 쓰기 작업까지 자동·병렬로 분기할 때 터진다. Cognition은 "Don't Build Multi-Agents"에서 이를 한 문장으로 못 박았다 — "Actions carry implicit decisions"(행위에는 암묵적 결정이 따라온다). 병렬 에이전트가 각자 코드 스타일·엣지 케이스 처리를 암묵적으로 결정하면, 그 결정들이 서로 충돌해 합쳐지지 않는다.
그래서 나는 멀티 에이전트를 통째로 폐기하지 않았다. 대신 읽기는 병렬화하되, 쓰기는 병렬화하지 않는다는 경계를 그었다(그림 2). 상태를 바꾸지 않는 조회성 작업(영향 범위·규칙·참조처 스캔)에 한해서만 좁게 fan-out을 허용한다. 읽기는 충돌하지 않으니까.
🔍 실행 결과
전환 이후 체감 변화는 분명했다. "지금 무엇이 돌고 있는가"가 항상 명확해졌고, 토큰 사용도 통제 가능해졌다. 다만 정직하게 적자면, 내 환경에서의 토큰 절감 폭은 정밀 측정한 수치가 아니라 체감·추정이다. 신뢰할 수 있는 숫자는 앞서 인용한 Anthropic의 "15배 / 분산의 80%"이며, 자동으로 6개를 띄울 때 이 비용이 곱해진다는 방향성이 내 결정의 근거였다.
5. 장단점 및 고려사항
| 장점 (기본 OFF + 명시적 호출) | 단점 |
|---|---|
| ✓ 실행 경로가 단일 → 예측 가능 | ✗ 매번 --agent 입력하는 마찰 |
| ✓ 토큰·비용을 사용자가 통제 | ✗ 자동 최적화 기회 일부 포기 |
| ✓ "내가 부른 것만 돈다" → 신뢰 ↑ | ✗ 신규 팀원은 어떤 에이전트가 있는지 학습 필요 |
| ✓ 실패 표면이 좁아 디버깅 쉬움 | ✗ 반복 작업의 자동화 이득은 줄어듦 |
도입 체크리스트
- 활성화 기본값을 OFF로 두었는가? (자동 호출 금지를 설정 파일에 명문화)
- 에이전트 호출 방법(이름 지정)이 팀에 공유되어 있는가?
- 병렬 fan-out을 읽기 전용으로만 좁혔는가? 쓰기 병렬화는 막았는가?
- 멀티 에이전트를 켤 때 "과제 가치 > 토큰 비용"인지 한 번 따졌는가?
- 어떤 에이전트가 언제 실행됐는지 사용자가 사후에 확인할 수 있는가?
흔한 함정 — "기본 OFF면 너무 불편하지 않나?"라는 반론. 핵심은 기본값을 보수적으로 두는 것이지 자동화를 금지하는 게 아니다. 안전하고 충돌하지 않는 읽기 작업은 자동·병렬로 열어 두면 마찰과 통제의 균형이 맞는다.
6. 핵심 세 줄 요약
- 에이전트 활성화 모델은 기능이 아니라 인터페이스 설계 문제다 — 자동문이냐, 손잡이 달린 문이냐.
- 자율성의 대가(예측 불가·토큰 15배·신뢰 하락)가 마찰의 대가(매번 호출 입력) 보다 컸기에 기본 OFF로 회귀했다.
- 그렇다고 멀티 에이전트를 버리진 않았다. 읽기 전용 fan-out만 좁게 열어 둔 절충이 현재의 답이다.
지금 쓰는 에이전트 설정에서 "자동으로 실행되는 것"의 목록을 적어 보라. 그중 쓰기를 하는 것이 있다면, 먼저 그것부터 명시적 호출로 바꿔라.
활성화 모델은 결국 사람과 시스템 사이의 동의(consent) 인터페이스다. 버튼의 affordance를 설계하고, 파괴적 동작 앞에 확인 단계를 두는 craft — 그 인터페이스의 한쪽 끝에 이제 에이전트가 들어왔을 뿐이다.
관련 글 제안
2026.06.19 - [AI 엔지니어링] - 프런트엔드 AX 설계기 1편 — AI 에이전트 설정을 4개 레이어로 쪼갠 이유
참고 자료(검증 출처)
- Anthropic, How we built our multi-agent research system (토큰 15배 / 성능 분산의 약 80%가 토큰량으로 설명 / 단일 대비 90.2% 개선)
- Cemri et al., Why Do Multi-Agent LLM Systems Fail? (MAST), arXiv:2503.13657 — 14개 실패 모드, 3개 범주
- Bogavelli et al., AgentArch: A Comprehensive Benchmark to Evaluate Agent Architectures in Enterprise, arXiv:2509.10769 — 복잡 과제 최고 35.3% 성공
- Cognition, Don't Build Multi-Agents — "Actions carry implicit decisions"
성능·토큰 수치는 인용 출처의 측정 환경 기준이며 실제 환경에 따라 다를 수 있습니다. 베스트 프랙티스는 일반적 권장이며 상황에 따라 달라질 수 있습니다.