AI Agent에 얼마나 많은 인프라가 필요할까?

지난 반년간 수십 개 팀의 「Agent 도입」 상담을 하며 가장 자주 듣는 두 극단이 있습니다. 모델 API 하나만 사서 프로덕션을 스스로 고치길 바라는 경우, 그리고 Kubernetes + 벡터 DB + MCP 세 벌 + 자율 Agent 플랫폼을 한꺼번에 올렸다가 3개월 뒤 아무도 유지보수하지 않는 경우입니다. 실제로 납기를 막는 것은 「모델이 똑똑하지 않다」가 아니라 실행 환경, 검증 체인, 컨텍스트 게이트웨이 세 축이 맞지 않는 경우가 대부분입니다. 이 글은 Cloud Mac AI Stack의 계층 언어로 「AI Agent에 얼마나 많은 인프라가 필요한가」를 의사결정 가능한 표로 쪼갭니다. 팀 규모에 맞춰 대입할 수 있고, 아키텍처 홍보 글의 풀세트를 그대로 베낄 필요는 없습니다.

1. 문제가 생기는 이유: 「채팅 가능」≠「납품 가능」

Agent라는 말이 남용되면서 대화 인터페이스와 엔지니어링 Agent가 뒤섞입니다. 대화 인터페이스는 모델 API만 있으면 됩니다. 엔지니어링 Agent는 최소한 저장소 읽기, 파일 수정, 명령 실행, 객관적 검증 신호 확보가 되어야 합니다. 한 고리라도 빠지면 전형적인 증상이 나타납니다.

• Agent가 코드를 고쳤는데 테스트했는지 아무도 모른다 — L1 Fact 부재(Runner 실행 엔진).
• 열려 있는 파일만 고칠 수 있고 모듈 간 리팩터는 추측에 의존 — L4 Context 부재(MCP 삼연결).
• 도구마다는 괜찮은데 issue 하나를 사람이 40분씩 지켜봐야 한다 — L5 Workflow 부재(OpenHands 플랫폼).
• Windows 노트북에서 Xcode 빌드를 돌리려 하는데 Agent에 합법적인 실행면이 없다 — L0 실제 macOS 부재(Cloud Mac vs 로컬 Mac).

옛 접근은 「더 강한 모델을 산다」였습니다. 새 접근은 계층별로 실행·검증 능력을 채운다는 것입니다. ZavCloud 고객이 Cloud Mac을 빌릴 때 가장 자주 묻는 것도 Ollama에 메모리가 충분한지가 아니라, 이 노드가 스택에서 어떤 역할을 맡는지입니다.

2. Agent 인프라 분류: 6계층, 6개 제품이 아님

아래는 L0–L5 표기(Stack 연재와 동일). 계층은 책임이지 필수 구매 목록이 아닙니다. 개인 개발자는 L3에서 멈출 수 있고, L2 추론 계층(Ollama)은 전 과정에서 선택 사항입니다.

갈등 구조가 여기서 분명해집니다. 채팅형 Agent는 L3 이전에서 멈추고, 엔지니어링형 Agent는 최소 L0+L3, 머지 가능한 Agent는 L1까지, 규모화 가능한 Agent만 L4+L5를 논합니다. 많은 팀이 Runner 없이 OpenHands부터 올려, 자율 작업이 코드는 고쳤는데 build 증명은 없는 상태로 끝나는 이유가 바로 계층 건너뛰기입니다.

3. 핵심 비교: 개인 / 소규모 팀 / 엔지니어링 3단계

통일 필드(도구 비교 글과 동일): 진입점, 실행 능력, 컨텍스트, 월 비용 규모, 적합 대상.

하드웨어 스펙은 L0와 L1을 동일 머신에 두는 경우(흔한 구성) 아래 표를 참고하세요. CPU 모델보다 메모리가 먼저 한계에 닿습니다. Agent, Runner, 선택적 Ollama가 통합 메모리를 나눠 쓰기 때문입니다.

4. 시나리오별 선택: 의사결정 매트릭스

「당신이 X라면 Y를 선택」으로 빠르게 분기합니다.

5. 추천 조합: 바로 쓸 수 있는 3가지 스택

조합 A · 개인 최단 가동(1일 이내)

L0  로컬 MacBook 또는 일 단위 Cloud Mac
L3  Claude Code(설치 매뉴얼)
모델  Anthropic API 구독

하지 않을 것: Runner, MCP, 벡터 DB, K8s

조합 B · 소규모 팀 머지 가능(1–2주)

L0  Cloud Mac M4 16GB 상시 노드
L1  GitHub Actions self-hosted Runner(투자 가치)
L3  Claude Code + CLAUDE.md 팀 규칙
L4  GitHub MCP 읽기 전용(issue 기반)

선택 L2: Ollama 7B로 비공개 초안, 메인 경로는 막지 않음

조합 C · 엔지니어링 자율 납품(1개월+)

L0  Cloud Mac M4 24GB+
L1  Runner · job당 workspace
L3  Claude Code
L4  MCP 삼연결 + CodeGraph
L5  OpenHands(샌드박스 저장소에서 먼저 시험)
오케스트레이션  OpenClaw로 트리거·감사(선택)

레드라인: 프로덕션 API / Runner 자격증명은 MCP에 넣지 않음(권한 가이드)

6. 흔한 오해: 하지 말아야 할 다섯 가지

1. 모델 API를 완전한 인프라로 본다. API는 「생각」만 해결하고 「실행」과 「검증」은 해결하지 못합니다.
2. Runner 없이 L5로 저장소 쓰기를 연다. Fact 계층 없는 자율 Agent는 맹목적 쓰기이며 롤백 비용이 큽니다.
3. 처음부터 벡터 DB + RAG 플랫폼을 만든다. 대부분 코드 Agent 병목은 임베딩 검색이 아니라 심볼 수준 컨텍스트(CodeGraph)입니다.
4. Windows에서 VM으로 macOS CI를 흉내 낸다. 서명, 공증, 실기기 테스트는 Apple Silicon 실제 환경이 필요합니다.
5. 「남의 풀세트」를 그대로 조달한다. 실행 경계를 먼저 적고 계층별로 추가하세요. 스택 깊이와 팀 인원은 선형 관계가 아닙니다.

7. 로드맵: 7단계 체크리스트

1. 실행 경계 정의 — Agent가 허용되는 작업: 어떤 디렉터리 수정, shell 실행 여부, 프로덕션 트리거 여부.
2. L0 확인 — Xcode / 공증이 필요하면 반드시 macOS. 임대 vs 구매 평가.
3. L3 코딩 Agent 연결 — 단일 파일·단일 저장소부터 통과. CLAUDE.md / 팀 Prompt 규칙 작성.
4. L1 Runner 구축 — macOS job과 Linux job 분리. 비밀과 Agent token 분리.
5. 필요 시 L4 MCP — 기본 읽기 전용. 쓰기 권한은 단기 token 전용 서비스.
6. L5 평가 — 2주 연속 수동으로 도구를 이어 붙이면 OpenHands류 Workflow 도입.
7. 감사·레드라인 — 자율 작업마다 PR + CI run ID로 매핑. 분기별 권한 매트릭스 점검.

자주 묻는 질문

정리

AI Agent에 필요한 인프라는 실행 경계가 어느 계층에서 멈추는지에 달려 있지, 모델 랭킹에 달려 있지 않습니다. 개인은 L3까지로 시작하고, 조직이 머지를 신뢰하려면 L1까지, 대형 저장소에서 길을 잃지 않으려면 L4, 무인 납품을 원하면 그때 L5를 논하세요. Cloud Mac이나 Mac mini를 살 때 이 머신이 스택에서 「실행면」「검증면」「추론면」 중 무엇인지 먼저 묻는 편이 TOPS 숫자만 보는 것보다 실용적입니다.