하나의 CLI, 다섯 가지 기능: 번들형 에이전트 런타임이 승리하는 이유

AI 코딩 에이전트는 똑똑합니다. 다단계 리팩토링을 계획하고, 아키텍처에 대해 추론하며, 프로덕션 수준의 코드를 생성할 수 있습니다. 하지만 텍스트 이상의 무언가(이미지, 비디오, 웹 검색 결과, 배포된 페이지)를 만들어야 할 때면 멈춰 버립니다.

능력이 없어서가 아닙니다. 도구가 없기 때문입니다.

기존의 해결책은 개별 서비스를 구성하는 것입니다. 이미지 API는 여기에, 비디오 API는 저기에, 검색 MCP 서버, 클라우드 스토리지 버킷, 배포 플랫폼. 각각 고유한 API 키, 고유한 구성, 고유한 유지 관리가 필요합니다. 에이전트가 코드 한 줄을 쓰기도 전에 인프라에 한 시간을 소비한 셈입니다.

더 나은 방법이 있습니다: 하나의 CLI, 하나의 인증 정보, 다섯 가지 기능.

모든 에이전트에 필요한 다섯 가지 기능

1. 이미지 생성

에이전트가 랜딩 페이지를 만듭니다. 히어로 이미지가 필요합니다. 이미지 생성 기능이 없으면 HTML을 작성하고 멈춥니다 — 사용자가 시각적 자산을 직접 구하거나 만들 때까지 기다립니다.

이미지 생성 기능이 있으면 에이전트가 스스로 이미지를 만듭니다:

anycap image generate --model nano-banana-2 --prompt "현대적인 SaaS 대시보드" -o hero.png

한 줄 명령어. CDN URL 반환. 모델 선택도, API 키 관리도, 형식 변환도 필요 없음 — 런타임이 모든 것을 처리합니다.

2. 비디오 생성

제품 데모. 기능 둘러보기. 소셜 미디어 콘텐츠. 에이전트는 스크립트를 작성할 수 있지만 비디오를 제작할 수는 없습니다. 그 기능을 제공하지 않는 한 말이죠.

비디오는 이미지보다 더 까다롭습니다 — 렌더 시간, 형식 제약, 모델 선택. 전용 비디오 기능은 이 모든 것을 하나의 명령어 뒤로 추상화합니다.

3. 근거 기반 웹 검색

에이전트는 React 20에서 무엇이 바뀌었는지, 경쟁사가 어떤 가격을 책정하는지, 최신 보안 권고 사항이 무엇인지 알아야 합니다. 검색 기능이 없으면 사용자가 에이전트와 인터넷 사이의 인간 다리 역할을 해야 합니다.

근거 기반 검색은 URL 목록이 아닌 인용되고 종합된 답변을 반환합니다. 에이전트는 파싱할 원시 HTML이 아닌 실행 가능한 정보를 얻습니다.

4. 클라우드 스토리지

에이전트가 파일을 생성합니다. 어디에 저장될까요? 클라우드 스토리지는 출력물을 공유 가능한 아티팩트로 전환합니다 — 이미지는 CDN URL이 되고, 빌드는 저장 및 버전 관리되며, 보고서는 어디서든 접근할 수 있게 됩니다.

스토리지가 없으면 에이전트는 모든 것을 로컬에 저장합니다. 사용자가 수동으로 업로드합니다.

5. 퍼블리싱

페이지를 만들 수 있지만 배포할 수 없는 에이전트는 절반만 완성된 것입니다. 퍼블리싱은 루프를 닫습니다 — 에이전트가 한 세션에서 빌드하고, 자산을 생성하고, 저장하고, 결과를 게시합니다.

하나의 CLI가 중요한 이유

대안인 각 기능별 개별 MCP 서버에는 숨겨진 비용이 따릅니다:

토큰 계산은 설득력 있습니다: 도구 설명에서 22,000개 적은 토큰은 200K 컨텍스트 창 중 11%를 실제 작업에 더 사용할 수 있음을 의미합니다. 50턴 에이전트 세션에서는 15턴의 추가 생산적 상호작용이 가능합니다.

"하나의 CLI"가 실제로 의미하는 것

에이전트의 워크플로가 다음과 같았던 것이:

에이전트: "히어로 이미지가 필요합니다."
사용자: API 키 구성, MCP 서버 설정, 연결 테스트.
에이전트: 이미지 도구 호출.
에이전트: "이제 경쟁사 가격이 필요합니다."
사용자: 또 다른 API 키 구성, 또 다른 MCP 서버.
에이전트: 검색 도구 호출.
에이전트: "이제 빌드를 저장하세요."
사용자: S3 인증 정보 구성, 세 번째 MCP 서버.

이렇게 바뀝니다:

에이전트: 이미지 도구 호출 → CDN URL 수신 ✅
에이전트: 검색 도구 호출 → 인용된 결과 수신 ✅
에이전트: 스토리지 도구 호출 → 자산 업로드 완료 ✅
에이전트: 게시 도구 호출 → 페이지 라이브 ✅

루프에 인간 없음. 인프라 관리 없음. 에이전트가 만든 것을 그대로 배포합니다.

아키텍처

번들형 기능 런타임은 에이전트와 서비스 사이에 위치합니다:

에이전트 (Claude Code, Cursor, Codex)
    │
    ▼
기능 런타임 (단일 CLI)
    │
    ├── 이미지 생성 (Nano Banana 2, Seedream 5)
    ├── 비디오 생성 (Veo 3.1, Kling 3.0, Seedance)
    ├── 웹 검색 (근거 기반, 인용)
    ├── 클라우드 스토리지 (Drive, CDN)
    └── 퍼블리싱 (정적 페이지 배포)

에이전트는 하나의 엔드포인트와 통신합니다. 런타임은 모델 선택, 인증, 속도 제한, 출력 형식을 처리합니다. 에이전트는 어떤 기능을 호출했든 매번 구조화된 JSON을 받습니다.

누구를 위한 것인가

번들형 런타임은 다음과 같은 경우에 가장 적합합니다:

• 개인 개발자로서 한 시간의 구성 끝이 아닌, 지금 당장 기능을 원할 때
• 소규모 팀에 속해 도구 인프라를 유지할 전담 DevOps가 없을 때
• 에이전트에 4개 이상의 기능이 필요하고 여러 MCP 서버로 인한 토큰 팽창이 실제 문제일 때
• 프로토타이핑 중이고 도구 설정이 추진력을 꺾지 않길 원할 때
• 일관성을 중시할 때 — 하나의 출력 형식, 하나의 오류 패턴, 한 가지만 배우면 됨

한두 개의 특수 도구(내부 데이터베이스, Slack 봇)만 필요하다면 개별 MCP 서버가 올바른 선택입니다. 하지만 모든 에이전트에 필요한 다섯 가지 기능(이미지, 비디오, 검색, 스토리지, 게시)에 대해서는 번들링이 구성 부담을 사라지게 만듭니다.

진정한 승리: 에이전트가 완성한다

결국 중요한 지표는 설정 시간이나 토큰 수가 아닙니다. 에이전트가 시작한 일을 끝내는지 여부입니다.

기능이 없으면 에이전트는 코드를 작성하고 당신에게 건넵니다. 마지막 단계 — 이미지, 자산, 배포 — 는 당신이 처리해야 합니다.

기능 런타임이 있으면 에이전트가 전체 파이프라인을 처리합니다: 코드, 자산, 스토리지, 배포. 중간 단계가 아닌 결과를 검토하게 됩니다.

이것이 작업을 도와주는 에이전트와 작업을 수행하는 에이전트의 차이입니다.

최종 업데이트: 2026년 5월