[카테고리:] AI에이전트

USB-C 케이블이 등장하기 전까지, 노트북마다 충전 포트가 다 달랐다. 어댑터 가방을 챙겨 다녀야 했고 새 기기를 살 때마다 케이블도 같이 사야 했다. 어느 시점부터 그게 사라졌다. 표준 하나가 자리를 잡으면 산업 전체의 비용이 한 번에 떨어지는 일이 일어난다. AI 에이전트 영역에서 지금 그 일이 진행 중이다. 이름은 MCP — Model Context Protocol.

숫자로 보면 더 분명해진다. SDK 누적 다운로드 9,700만 건. React가 npm 1억 건에 도달하는 데 3년이 걸렸는데 MCP는 16개월이었다. OpenAI, Google, Microsoft, AWS가 모두 채택했고 운영은 Linux Foundation으로 넘어갔다. “AI 인프라의 HTTP”라는 말이 더 이상 마케팅 멘트가 아닌 단계다.

그래서 정확히 뭘 하는 표준인가

MCP는 Anthropic이 2024년 말 오픈소스로 푼 인터페이스 규약이다. AI 모델이 외부 툴이나 데이터(파일시스템, DB, API, SaaS 서비스)에 접근하는 방법을 통일했다. 핵심 아이디어가 USB-C와 같다. 한 번 표준에 맞춰 만든 어댑터(MCP 서버)는 어떤 AI(MCP 클라이언트)에서도 그대로 동작한다.

구조 자체는 단순하다. 한쪽은 MCP 서버 — 특정 데이터나 툴을 AI가 쓸 수 있게 노출하는 작은 프로그램(GitHub 서버, Slack 서버, PostgreSQL 서버 같은 식). 다른 한쪽은 MCP 클라이언트 — 그 서버를 호출해 쓰는 AI 애플리케이션(Claude Code, Cursor, Claude Desktop). GitHub 위에 공개돼 있는 MCP 서버가 이미 1만 3천 개를 넘었다. Slack, Figma, Linear, Notion, Postgres, Google Drive — 자주 쓰는 거의 모든 서비스에 누군가가 이미 만들어 놨다.

Claude Code에서 5분 만에 붙여 보기

가장 쉬운 진입은 Claude Code다. 프로젝트 루트의 .claude/settings.json에 MCP 서버 정의를 추가한다.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxx"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://localhost/mydb"]
    }
  }
}

저장하고 Claude Code를 재시작하면 끝이다. 이제 자연어로 “내 GitHub 이슈 중 라벨이 bug인 것만 보여 줘”나 “users 테이블에서 최근 가입자 10명 뽑아줘”라고 시킬 수 있다. 코드 한 줄 안 써도 된다.

사내 시스템을 직접 노출하고 싶다면

유명 서비스는 이미 다 있지만, 진짜 효과가 큰 건 사내 전용 시스템을 MCP로 만드는 쪽이다. TypeScript SDK가 가장 손쉽다.

npm install @modelcontextprotocol/sdk

// my-mcp-server.ts
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server({ name: "my-server", version: "1.0.0" });

server.setRequestHandler("tools/list", async () => ({
  tools: [{
    name: "get_user_info",
    description: "사용자 정보 조회",
    inputSchema: {
      type: "object",
      properties: { userId: { type: "string" } }
    }
  }]
}));

server.setRequestHandler("tools/call", async (req) => {
  if (req.params.name === "get_user_info") {
    // 내부 API 호출 로직
    return { content: [{ type: "text", text: JSON.stringify(userData) }] };
  }
});

const transport = new StdioServerTransport();
await server.connect(transport);

이렇게 만든 서버를 settings.json에 등록하면 Claude Code가 즉시 그 도구를 인식한다. 사내 API에 추가 코드를 넣을 필요도 없다. MCP 서버가 wrapper 역할만 해 준다.

진짜 의미 — 한 번 만들면 모든 AI에서 동작

가장 큰 변화는 재활용성이다. 사내 시스템 위에 MCP 서버 하나를 올려 두면 그게 Claude뿐 아니라 ChatGPT, Cursor, 그리고 1년 뒤에 나올 새 에이전트에서도 그대로 동작한다. 특정 벤더에 종속되는 코드를 짤 필요가 사라진다는 뜻이다. 반대로 외부 서비스 쪽도 마찬가지다. Jira나 Confluence를 AI에게 읽히고 싶다면 직접 통합 코드를 짤 게 아니라 이미 공개된 MCP 서버를 그냥 가져다 꽂으면 된다.

지금 할 일

가장 빠른 진입은 github.com/modelcontextprotocol/servers에 들어가 공식 서버 목록을 한 번 훑는 것이다. 이미 본인이 자주 쓰는 서비스(GitHub, Notion, Slack 등)가 있을 가능성이 높다. 그중 하나를 골라 위 settings.json 예시처럼 Claude Code에 붙여 보고, 가장 자주 묻고 싶었던 질문을 한 번 던져 보자. 그 다음 단계는 사내 시스템 차례다. 회사 동료가 AI에게 가장 자주 묻는 정보가 무엇인지 떠올려 보고, 그걸 노출하는 작은 MCP 서버를 만들어 보면 사내 도입의 첫 사례가 된다.

관련 글

• Claude Code 처음 시작하는 법: 설치부터 실전까지 2026 완전 가이드
• Google Scion: 여러 AI 에이전트를 동시에 돌리는 멀티 에이전트 오케스트레이션
• 코딩 에이전트 샌드박스란 무엇인가: Freestyle로 보는 AI 개발 환경의 진화

출처

• Anthropic 공식 — Model Context Protocol
• GitHub — modelcontextprotocol/servers
• Digital Applied — MCP Hits 97M Downloads

퇴근 후 소파에 앉아 휴대폰을 켠다. ChatGPT를 열고 한 줄을 친다. “@Tubi 오늘 밤 볼 만한 90분짜리 스릴러 있을까?” 답이 돌아온다. 추천 목록 세 편, 그 자리에서 재생 버튼. 다른 앱을 열 필요는 없다. 4월 8일, 무료 스트리밍 서비스 Tubi가 ChatGPT 앱스토어 최초의 스트리밍 네이티브 앱을 띄운 날이 만들어 낸 풍경이다.

이게 단순한 신기능 발표가 아닌 이유가 있다. ChatGPT가 운영체제처럼 작동하기 시작했다는 신호다.

‘챗봇 안의 챗봇’에서 ‘챗봇 안의 진짜 앱’으로

OpenAI는 2024년 말 GPT 스토어를 열었지만, 그건 사실상 프롬프트 컬렉션에 가까웠다. 누가 만든 GPT를 골라 들어가도 결국 텍스트 응답이 전부였다. 2025년 말 등장한 네이티브 앱(Native Apps) 개념부터 분위기가 달라졌다. 핵심 차이는 액션(Actions)에 있다. 이전 GPT는 말을 만들어 냈고, 네이티브 앱은 행동을 한다. 예약, 결제, 재생, 구매 같은 실제 동작이 ChatGPT 창 안에서 끝난다.

왜 하필 Tubi가 첫 타자였나

흥미로운 건 Netflix도, Disney+도 아니고 Tubi였다는 점이다. Fox Corporation 산하의 무료 광고 기반 스트리밍 서비스. 30만 편 넘는 영화와 TV 프로그램을 무료로 푼다. 유료 구독 모델인 거대 OTT들은 ChatGPT를 통한 재생이 자기 앱 수익 구조를 위협한다고 본다. 반대로 Tubi는 광고 모델이라 노출이 늘어날수록 이득이다. 이해관계가 정확히 일치하는 첫 후보가 Tubi였던 셈이다.

사용자 흐름은 단순하다. ChatGPT 대화창에서 @Tubi를 멘션하고 자연어로 요청하면, 모델이 Tubi 콘텐츠 DB를 조회하고 추천 목록을 보여 준다. 마음에 드는 작품을 누르면 그대로 Tubi 플레이어가 열린다. 이 한 사이클이 ChatGPT 한 화면에서 끝난다는 게 핵심이다.

개발자 입장에서 본 진입 장벽

네이티브 앱은 OpenAI의 Actions와 Plugin Manifest 구조 위에서 돌아간다. 기술적으로 보면 OpenAPI 스펙(openapi.yaml)을 따르는 REST API만 있으면 된다. 이 스펙을 OpenAI Developer Portal에 등록해 두면, ChatGPT가 사용자의 요청을 보고 언제 어떤 API를 호출할지 스스로 판단한다. 서버 쪽 코드는 일반적인 REST API 개발과 다를 게 없다.

현재는 OpenAI 심사를 거쳐야 등록이 가능하고, 노출 대상은 ChatGPT Plus·Team·Enterprise 구독자다. Free 플랜으로의 확대는 예정 단계다. 진입 장벽이 그렇게 높지 않다는 점이 의미 있다. 이미 외부 서비스 API를 운영 중인 팀이라면 며칠이면 프로토타입을 띄울 수 있다.

한국 사용자에게 진짜 의미

지금 당장 한국 서비스의 ChatGPT 앱이 있는 건 아니다. 하지만 Tubi가 만든 선례 위에서 두 가지 길이 보인다. 하나는 글로벌을 노리는 한국 스타트업에게 새로 열린 배포 채널이다. App Store와 Play Store 외에 ChatGPT 안이 또 다른 진입점이 됐다. 다른 하나는 사내 도구 쪽이다. 사내 GPT를 따로 만들 필요 없이 회사 시스템 API를 ChatGPT 앱으로 등록하면, 직원들이 평소 쓰는 ChatGPT 안에서 그대로 사내 시스템에 접근할 수 있다. 두 시나리오 모두 지금 시점에 실험할 가치가 있는 영역이다.

지금 할 일

ChatGPT Plus 구독이 있다면 사이드바의 Explore GPTs에서 현재 어떤 앱이 올라와 있는지 한 번 둘러보는 게 첫 단계다. 개발자라면 platform.openai.com/docs/actions에서 Actions 개발 가이드를 훑어 두자. 자기 서비스에 맞는 연동 방식을 결정하려면 OpenAI Actions와 Anthropic 진영의 MCP가 어떻게 다른지 비교해 두는 것이 도움이 된다.

관련 글

• OpenAI 슈퍼앱: ChatGPT·Codex·Atlas 통합
• Shopify Agentic Storefronts: ChatGPT 안에서 판매
• MCP 완전 입문 가이드: 9,700만 다운로드 AI 에이전트 표준

출처

• TechCrunch — Tubi is the first streamer to launch a native app within ChatGPT
• OpenAI 공식 — Actions Documentation

4월 7일, Anthropic이 보기 드문 발표를 했다. 자사 역사상 가장 강력한 모델을 만들었는데, 일반 사용자에게는 풀지 않겠다는 결정. 이름은 Claude Mythos. 그리고 그 모델에 접근할 수 있는 좁은 문의 이름은 Project Glasswing이다. AI 회사가 자기 모델 출시를 스스로 막은 사례는 업계에서 이례적이다.

이번 결정을 어떻게 봐야 하는지, 경쟁 구도 안에서 어떤 의미인지 정리한다.

Mythos가 어떤 모델인가

공식 파라미터 수는 공개되지 않았다. 업계에서는 10조(10T) 파라미터 수준으로 추정한다. 단, 숫자 자체보다 중요한 건 포지셔닝이다. 기존 Claude 라인업은 글쓰기·코딩·분석을 두루 잘하는 범용 모델이었지만, Mythos는 다르게 설계됐다. 특정 영역의 추론 능력을 극단까지 끌어올린 전문 모델이다. Anthropic 내부 평가로는 같은 분야에서 GPT-5.4, Gemini Ultra를 앞선다.

이 능력이 양날의 검이라는 게 출시 거부 결정의 핵심 근거다. 같은 추론 능력이 방어에도, 공격에도 쓰일 수 있기 때문이다. Anthropic은 이 모델을 무제한으로 풀면 의도와 정반대의 결과로 이어질 수 있다고 판단했다.

Project Glasswing — 좁고 명확한 문

대신 선택한 게 Glasswing이라는 제한 배포 프레임워크다. Apple, Microsoft, Amazon, Google을 포함한 40개 파트너사에만 접근권을 주고, 사용 목적과 범위를 사전에 심사한다. 단순한 API 키 발급 프로그램이 아니다. 참여 기업은 다음과 같은 조건을 충족해야 한다.

• 해당 분야 전문 인력 보유 인증
• 모델 출력물의 사용 목적 사전 신고
• 발견 결과의 책임 있는 공개 절차 서약
• Anthropic의 정기 감사 수용

특히 Apple과의 협력이 주목할 만하다. WWDC 2026에서 발표된 시리 2.0의 일부 기능이 Mythos 기반으로 알려졌다. 아이폰·맥에 들어가는 온디바이스 모델이 아니라, 클라우드 측 추론 레이어에서 Mythos가 활용되는 구조다.

경쟁 구도 안에서 본 의미

가장 흥미로운 해석은 “안전성을 경쟁 우위로 만들 수 있다”는 점이다. OpenAI는 GPT-5.4를 가능한 한 빠르게 풀어 시장 점유율을 가져가는 전략을 쓴다. Anthropic은 정반대 카드를 꺼냈다. “우리는 너무 강력한 모델은 일부러 안 푼다”는 메시지를 던지면서 신뢰를 차별점으로 만든다. 규제 리스크가 큰 산업이나 정부 계약 시장에서는 이게 결정적인 차이가 될 수 있다.

또 다른 해석은 영업 차원이다. Glasswing 파트너십에 들어가는 40개사는 모두 Anthropic의 가장 큰 잠재 고객이다. 일반 API로 풀었다면 누구나 쓸 수 있었을 모델을 한정 공급으로 만들면서 가치가 더 올라갔다. 선택지를 줄이는 게 오히려 협상력을 키우는 사례다.

한국 사용자에게 의미

당장 일반 사용자가 Mythos를 직접 쓸 수는 없다. 다만 두 가지 변화는 곧 체감될 가능성이 높다. 먼저 Glasswing 파트너로 들어간 글로벌 대기업들의 제품에 Mythos 기반 추론이 점점 들어간다. Apple, Microsoft 제품을 한국에서도 쓰는 만큼 간접적인 영향을 받는다. 두 번째는 한국 대기업의 파트너십 신청 가능성이다. 현재는 글로벌 40개사 제한이지만 점차 확대될 가능성이 있다. 보안과 컴플라이언스가 핵심인 금융, 통신, 공공 부문이라면 검토해 볼 카드다.

지금 할 일

일반 사용자라면 우선 anthropic.com/glasswing에서 공식 발표 내용을 직접 확인해 보는 게 시작이다. Anthropic의 안전 정책 방향성이 다른 AI 회사와 어떻게 다른지 비교해 보면 모델 선택 기준 자체가 명확해진다. 기업 보안·컴플라이언스 담당자라면 Glasswing 파트너십 조건이 자기 조직과 맞는지 검토하고, 향후 확대 시점을 대비해 사전 협의 채널을 열어 두는 것도 의미 있다.

관련 글

• Claude Opus 4.6 완전 분석 / Cowork 출시
• Anthropic vs 국방부 소송 / Jeff Dean Microsoft 지지
• Claude Mythos 유출·DeepSeek V4·AI 모델 대전

출처

• TechCrunch — Anthropic debuts Mythos in cybersecurity initiative
• Anthropic 공식 — Project Glasswing

코딩 에이전트는 이미 충분히 많다. Claude Code, Cursor, Codex, Aider, Windsurf — 손가락 두 손으로도 다 안 꼽힌다. 그런데 JetBrains가 3월 베타로 푼 Junie CLI는 그 사이에 또 하나의 자리를 만들었다. 이유는 단순하다. 모델을 묶지 않는다.

Claude Code는 Anthropic 모델만 돈다. Cursor는 IDE 안에서만 살아 있다. Junie는 두 제약을 동시에 푼다. BYOK(Bring Your Own Key) 방식으로 OpenAI, Anthropic, Google, xAI, 로컬 Ollama까지 — 어떤 모델이든 갈아 끼우면서 터미널·IDE·CI/CD 어디서든 굴린다.

Claude Code와의 차이를 한 표로

설치는 한 줄

npm 한 줄이면 설치가 끝난다.

npm install -g @jetbrains/junie-cli

처음 한 번은 어떤 LLM 제공자를 쓸지 정해 줘야 한다.

junie init
# 제공자 선택: OpenAI / Anthropic / Google / xAI / Ollama(로컬) 등
# API 키 입력
# 기본 모델 설정

이후엔 프로젝트 디렉토리 안에서 자연어 한 줄로 작업을 던진다.

cd my-project
junie "로그인 API에 JWT 갱신 로직 추가해줘"

실전에서 빛나는 세 가지 시나리오

Junie의 진가는 모델 교체 자유도에서 나온다. 첫 번째 시나리오는 비용 최적화다. 복잡한 아키텍처 설계는 Claude Opus 4.6에 맡기고, 단순 반복 코드 생성은 GLM-5.1 API나 로컬 Ollama로 돌리도록 작업 종류별로 모델을 분리할 수 있다. 같은 한 달 동안 비용을 절반 이하로 줄이는 게 어렵지 않다.

두 번째는 CI/CD 파이프라인 통합이다. GitHub Actions에서 Junie를 트리거하면 PR이 올라올 때마다 자동으로 코드 리뷰, 테스트 보완, 문서 업데이트를 실행할 수 있다.

# .github/workflows/junie-review.yml
- name: Junie Code Review
  run: junie review --model claude-opus-4-6 --pr ${{ github.event.pull_request.number }}

세 번째 시나리오가 가장 중요할 수 있다. 회사 보안 정책으로 외부 API 사용이 막힌 환경. Ollama와 연결해 완전히 오프라인 상태에서 에이전트 코딩이 가능하다. 코드를 사외로 보낼 일이 0이 된다. 이게 한국 대기업·금융권에서 의미가 큰 이유다.

아직 베타라는 점은 잊지 말 것

장점만 있는 도구는 없다. 복잡한 멀티파일 리팩토링에서는 Claude Code 대비 컨텍스트 유지력이 떨어진다는 사용자 피드백이 있다. JetBrains IDE(IntelliJ, PyCharm 등)와의 통합은 매끄럽지만 VS Code 쪽은 별도 설정이 필요하다. 베타 단계임을 감안하고 작은 작업부터 시작하는 게 안전하다.

한국 개발자에게 의미

Anthropic 모델에 종속되고 싶지 않거나, 모델별로 비용·성능을 직접 조정하고 싶은 개발자에게 Junie CLI는 실질적인 카드다. 특히 Java·Kotlin·Python을 주로 쓰면서 JetBrains IDE를 일상으로 쓰는 환경이라면 통합 완성도가 가장 높다. 비용에 민감한 스타트업·프리랜서, 그리고 외부 API가 막힌 보안 조직 — 이 세 그룹이 가장 빠르게 효과를 본다.

지금 할 일

일단 설치한 다음 평소에 자주 하던 작업 하나를 던져 본다. 같은 작업을 OpenAI 모델, Anthropic 모델, 그리고 GLM-5.1 같은 저가 모델로 차례차례 돌려 보면 자기 워크플로에 어떤 모델 조합이 맞는지 한 시간이면 감이 잡힌다. 그 다음 단계는 GitHub Actions에 PR 리뷰 자동화 한 줄을 붙여 보는 것. 이게 Junie가 다른 도구들과 가장 크게 차이 나는 지점이다.

관련 글

• Claude Code 처음 시작하는 법: 설치부터 실전까지 2026 완전 가이드
• Kiro vs Cursor vs Claude Code 2026 AI 코딩툴 3파전 비교
• 코딩 에이전트 샌드박스란 무엇인가: Freestyle로 보는 AI 개발 환경의 진화

출처

• JetBrains 공식 — Junie CLI: The LLM-Agnostic Coding Agent
• GitHub — JetBrains/junie

지난 1년의 코딩 에이전트 발전사는 한 줄로 요약된다. “한 명의 슈퍼 에이전트를 어떻게 더 똑똑하게 만들까.” Claude Code, Cursor, Codex가 그 방향이었다. 그런데 4월에 Google이 오픈소스로 푼 Scion은 다른 질문을 던진다. “왜 한 명만 써야 하지?”

Scion은 Google Cloud Platform이 GitHub에 공개한 멀티 에이전트 테스트베드다. 핵심 개념은 단순하다. Claude Code, Gemini CLI, OpenAI Codex 같은 서로 다른 코딩 에이전트를 각자의 컨테이너에서 동시에 띄우고, 그 결과물을 위에서 조율하는 레이어를 제공한다. 일부 개발자가 “에이전트의 하이퍼바이저”라고 부르기 시작한 이유가 여기에 있다.

왜 굳이 여러 명을 쓰나

단일 에이전트의 한계는 두 가지다. 첫째, 한 명이 백엔드 API 수정 → 프론트엔드 컴포넌트 업데이트 → 테스트 코드 작성을 순차로 처리하면 시간이 그대로 누적된다. 둘째, 각 작업에 가장 잘 맞는 모델이 다르다. 코드 리뷰는 Claude Opus 4.6의 추론 깊이가 좋고, 단순 코드 생성은 GLM-5.1이 비용 대비 효율적이고, 테스트 작성은 Gemini Flash로도 충분하다. 한 모델이 모든 영역에서 최적인 경우는 거의 없다.

멀티 에이전트는 이 두 한계를 동시에 푼다. 작업을 나눠 병렬로 돌리고, 작업별로 최적 모델을 매칭한다. 시간도 비용도 줄어든다.

구조 — 컨테이너 단위 격리

Scion Orchestrator
├── Agent Container A (Claude Code)
│     └── 담당: 백엔드 API 설계 + 구현
├── Agent Container B (Gemini CLI)
│     └── 담당: 테스트 코드 + 문서화
└── Agent Container C (Codex)
      └── 담당: 프론트엔드 컴포넌트

각 컨테이너는 독립된 파일시스템과 환경변수를 갖는다. 같은 코드베이스를 동시에 수정하면서도 충돌이 안 나는 이유는 Scion이 내부적으로 git 브랜치 전략을 관리하기 때문이다. 작업이 끝나면 머지 충돌을 해결하고 통합한다.

실제 실행

설치는 GitHub 클론 + Docker Compose다.

git clone https://github.com/GoogleCloudPlatform/scion
cd scion
cp .env.example .env
# .env에 각 에이전트 API 키 설정
docker compose up

워크플로는 YAML로 선언한다. 어떤 에이전트가 무엇을 담당하고, 어떤 작업이 어떤 작업에 의존하는지 단순한 문법으로 적어 두면 된다.

workflow:
  - agent: claude-code
    task: "백엔드 /api/users 엔드포인트 구현"
    branch: feat/backend
  - agent: gemini-cli
    task: "위 엔드포인트 단위테스트 작성"
    depends_on: claude-code
    branch: feat/tests

아직 실험 단계라는 점

Google 스스로 “experimental”이라고 표시해 둔 프로젝트다. 에이전트 간 컨텍스트 공유는 아직 제한적이고, 대형 코드베이스에서는 머지 충돌 해결 품질이 들쑥날쑥하다. 프로덕션 도입보다는 실험과 학습 목적으로 보는 게 정확하다. 단, 멀티 에이전트 협업이 1~2년 안에 표준이 될 가능성이 높은 만큼, 지금 손에 익혀 두는 가치는 크다.

한국 개발자에게 의미

Scion 자체를 당장 회사 인프라에 올리기는 이르다. 하지만 이 방향성은 분명하다. 머지않아 여러 에이전트를 조율하는 오케스트레이션 레이어가 개발 워크플로의 기본 인프라가 된다. 지금 Scion을 손으로 굴려 보는 건 그 흐름을 미리 익히는 작업이다. 비교 학습 대상으로 Paperclip AI나 LangGraph 같은 다른 오케스트레이션 프레임워크를 같이 봐 두면 멀티 에이전트 아키텍처에 대한 감이 더 빠르게 잡힌다.

지금 할 일

가장 가벼운 시작은 GitHub에서 Scion 레포를 클론해 Docker Compose 데모를 한 번 띄워 보는 것이다. 처음부터 4개 에이전트를 동시에 굴리지 말고 Claude Code + Gemini CLI 두 명만으로 단순한 분리 작업(예: 백엔드 함수 + 그 함수의 단위 테스트)을 돌려 보면 멀티 에이전트의 감이 가장 빠르게 잡힌다. 그 다음 단계로 Paperclip이나 LangGraph 같은 대안과 어떤 차이가 있는지 비교해 두면 자기 워크플로에 맞는 도구를 고르는 기준이 생긴다.

관련 글

• Paperclip AI 에이전트 오케스트레이션 오픈소스 플랫폼
• 코딩 에이전트 샌드박스란 무엇인가: Freestyle로 보는 AI 개발 환경의 진화
• AI 에이전트 기업 도입 전 체크리스트 7가지

출처

• InfoQ — Google open-sources Scion agent testbed
• GitHub — GoogleCloudPlatform/scion