오픈소스 AI 에이전트 프로젝트에 대한 실측 기반 기술 검토 후 Awesome Agent로 정리했습니다. Agent의 난립으로 인해 보안 취약점과 도리어 성능이 하락하는 일, 너무 무거워 도입 후 효과를 발휘하지 못하는 일들이 생겨남에 따라 내게 맞는 Agent를 고르기 위한 큐레이션입니다. 더구나 다양한 오픈소스 도구들이 상호 참조를 하여 공격의 한 포인트가 될 수 있다. 나라면 Agent에 들어가는 필수 도구 한 두개를 기여하면서 잠재된 취약점을 통해 대량의 판데믹 공격을 만들 것이다.
지금 인공지능 기반의 오픈소스들은 무절제한 상호 참조를 거치고 있다. 서로 격리되어 있지 않기 때문에 큰 사고를 낼 가능성이 높다.
언어. 각 리뷰와 이 허브 문서는 한국어·영어·일본어로 제공됩니다 (readme.md / readme_EN.md / readme_JA.md).
0. 이 문서를 만든 이유
2026년 상반기, 오픈소스 AI 에이전트 프로젝트가 폭발적으로 늘었다. 문제는 숫자가 아니라 정보의 부패 속도로 정의할 수 있다. 매일 경쟁 Agent와 업데이트가 LLM 기반으로 발생하여 수렴 진화가 정보의 오류라는 면에서 일어나고 있다.
1. 수록 문서
| 문서 | 프로젝트 | 핵심 포지션 | 한국어 | English | 日本語 |
|---|---|---|---|---|---|
| OpenWorker | OpenWorker (Andrew Ng, Rohit Prasad) | 지식노동자용 로컬 데스크톱 에이전트. 산출물 지향 | KO | EN | JA |
| goose | goose (Agentic AI Foundation) | 범용 로컬 에이전트 런타임. 거버넌스 중립 | KO | EN | JA |
| OpenHands | OpenHands (All Hands AI) | 에이전트 오케스트레이션 컨트롤 센터 | KO | EN | JA |
각 문서는 동일 포맷을 따른다. 메타데이터 표, 컨셉, 장점, 단점 및 유의점, 유사 경쟁 프로젝트, Getting Started, 도입 전 점검 항목.
2. 한눈에 보는 비교
| 항목 | OpenWorker | goose | OpenHands |
|---|---|---|---|
| 개발 주체 | Andrew Ng, Rohit Prasad | Block 출신, 현 Linux Foundation AAIF | All Hands AI (영리기업) |
| 라이선스 | MIT | Apache 2.0 | MIT + enterprise/ 별도 |
| 거버넌스 | 개인 주도, 내부 로드맵 우선 | 재단, 벤더 중립 | 단일 기업, 오픈코어 |
| 저장소 | andrewyng/openworker | aaif-goose/goose | OpenHands/OpenHands |
| 스타 | 46 | 51.7k | 82.2k |
| 포크 | 3 | 5.7k | 10.5k |
| 커밋 | 45 | 5,130 | 7,082 |
| 구현 언어 | Python + TypeScript + Rust | Rust | Python + TypeScript |
| 지원 OS | macOS, Windows(미서명) | macOS, Linux, Windows | 플랫폼 무관(컨테이너/서버) |
| 제공 형태 | 데스크톱 앱 | 데스크톱, CLI, API | 웹 컨트롤 센터, API |
| 기본 실행 격리 | 로컬 프로세스 | 로컬 프로세스 | 없음(Docker는 선택) |
| 승인 게이트 | 4단계 타입 분류, 기본 활성 | 4개 모드, 기본 자율 | 정책 기반, 구성 의존 |
| 네이티브 커넥터 | 25+ | 없음(MCP 위임) | GitHub/Slack/Jira 등 |
| MCP 지원 | 있음 | 있음(70+ 확장) | 있음 |
| ACP 지원 | 없음 | 있음 | 있음(핵심 기능) |
| 타 에이전트 구동 | 불가 | 프로바이더로 활용 | 1급 기능 |
| 모델 프로바이더 | 11+ 및 Ollama | 15+ 및 Ollama | LiteLLM 컨벤션 |
| 스케줄 실행 | 있음 | 있음 | 있음(별도 서버) |
| 서브에이전트 | 없음 | 있음(자율 모드 한정) | 있음 |
| 엔터프라이즈 관리 | 없음 | Custom Distros | RBAC, SSO, Budgets(엔터프라이즈) |
| 성숙도 | 오픈 베타 | 프로덕션 | 베타(전환 중) |
축약 판단
| 상황 | 선택 |
|---|---|
| 문서·일정·메일 등 업무 산출물 자동화 | OpenWorker |
| 코드와 비코드를 아우르는 범용 로컬 에이전트 | goose |
| 여러 에이전트를 조직 단위로 관리 | OpenHands |
| 라이선스 리스크를 최소화해야 하는 상용 임베드 | goose |
| 격리 실행이 필수 요건 | OpenHands + Docker 백엔드 |
| 완전 오프라인 | goose + Ollama |
3. 3개 프로젝트 요약
3.1 OpenWorker
배경.2026년 7월 23일 공개. Andrew Ng와 Rohit Prasad가 자신들이 만든 aisuite 라이브러리 위에 올린 데스크톱 에이전트다. aisuite 저장소 내부에서 개발되다 독립 저장소로 분리됐다.컨셉."대화가 아니라 결과물". 프롬프트가 아니라 원하는 결과를 지시하면 단계로 분해해 파일 형태의 산출물을 반환한다. Tauri 2 셸이 로컬 Python FastAPI 서버(127.0.0.1:8765)를 감독하는 구조.장점.25개 이상 네이티브 커넥터가 즉시 동작한다. 승인 게이트를 UI 부가 기능이 아니라 타입 시스템 수준에서 정의해 read / write_local / exec / external 네 등급으로 분류하고, 무인 실행 시 승인 요청을 인박스에 적체시킨다. 세 프로젝트 중 안전 기본값이 가장 보수적이다.단점.커밋 45건, 스타 46개의 초기 프로젝트다. Linux 미지원, Windows 미서명. 내부 로드맵과 다른 PR은 반려한다고 명시돼 있어 오픈소스이되 거버넌스는 중앙집중적이다.유의점. "프라이버시 보호"라는 홍보 문구를 그대로 받아들이면 안 된다. 에이전트 루프가 로컬이라는 것과 데이터가 로컬에 남는다는 것은 다르다. 클라우드 API 키를 꽂는 순간 파일 내용은 외부로 나간다. 실질적 로컬성은 Ollama 경로에서만 성립한다.
3.2 goose
배경.Block 내부 도구로 출발해 오픈소스화됐고, 2026년 4월 7일 Linux Foundation의 Agentic AI Foundation에 기증됐다. MCP, AGENTS.md와 같은 재단 소속이다. 저장소와 문서 도메인이 모두 이전됐다.컨셉."코드 제안을 넘어서는 범용 로컬 에이전트". Rust 구현, Cargo 워크스페이스로 코어·CLI·서버·MCP 크레이트 분리. 데스크톱 앱, CLI, 임베더블 API가 동일 코어를 공유하고 설정 파일도 공용한다.장점.세 프로젝트 중 유일하게 벤더 중립 거버넌스를 갖췄고 Apache 2.0이라 상용 임베드 제약이 없다. 3개 OS 전면 지원, 70개 이상 MCP 확장, ACP로 기존 Claude Code·Codex 구독 재활용 가능. Custom Distros로 사내 전용 배포판을 공식 지원한다.단점.업무 도구는 전부 별도 MCP 서버 설치와 개별 인증을 요구한다. 70개 확장은 생태계 규모이지 즉시 사용 가능한 커넥터 수가 아니다. 문서와 예제가 코딩 시나리오에 편중돼 비개발자 온보딩 경로가 약하다.유의점.기본 권한 모드가 완전 자율이다. 그리고 서브에이전트는 자율 모드에서만 동작한다. 즉병렬 처리 성능을 쓰려면 승인 게이트를 전부 꺼야 한다. 사용자를 안전 장치 해제 쪽으로 미는 설계이며, 이 문서 전체에서 가장 심각한 구조적 문제로 판단한다.
3.3 OpenHands
배경.2024년 말 OpenDevin으로 시작해 Devin의 오픈소스 대안으로 주목받았고, 2025년 개명했다. 2026년 현재 저장소 조직이 OpenHands/OpenHands로 이전되고 제품 정체성이 Agent Canvas 중심으로 전환되는 중이다.컨셉."코딩 에이전트와 자동화를 위한 셀프호스팅 개발자 컨트롤 센터". 자체 에이전트만 돌리는 게 아니라 Claude Code, Codex, Gemini 등 ACP 호환 에이전트를 함께 구동한다. Agent Canvas 프런트엔드가 여러 Agent Server에 연결하고, 별도 Automation Server가 스케줄과 웹훅 트리거를 담당한다.장점.규모가 가장 크다. 백엔드를 노트북·전용 머신·VM·사내 인프라·클라우드 중에서 고르고 같은 화면에서 전환할 수 있다. 엔터프라이즈 관리 기능(Agent Profiles, Budgets, Usage 대시보드, SAML/SSO, RBAC)이 실제 코드로 존재하며 Kubernetes 자체 호스팅 경로가 있다.단점.순수 오픈소스가 아니다. enterprise/ 디렉터리는 별도 라이선스이고, 조직 도입에 실제로 필요한 기능 상당수가 그 안에 있다. 저장소 분리가 진행 중이라 기존 문서와 튜토리얼 상당수가 이미 동작하지 않는다.유의점. 대표적 차별점이던 Docker 샌드박스가 기본 경로에서 빠졌다. 현행 1순위 설치법은 호스트 직접 실행이며 README에 파일시스템 전체 접근 경고가 붙어 있다. 여기에 Slack·GitHub 웹훅 트리거를 결합하면 외부 텍스트가 곧바로 지시문 경로가 된다. 세 프로젝트 중 공격 표면이 가장 넓은 구성이다.
4. 그 외 프로젝트 지형도
4.1 코딩 특화 에이전트
| 프로젝트 | 라이선스 | 표면 | 비고 |
|---|---|---|---|
| Claude Code | 상용 | CLI, 데스크톱, IDE | 단일 모델 최적화. goose·OpenHands에서 ACP 프로바이더로 역이용 가능 |
| Codex | 상용 | CLI, 클라우드 | ACP 경유 편입 가능 |
| Cline | 오픈소스 | VS Code | IDE 내장 최강. Plan-and-Act 모드, MCP 마켓플레이스 |
| Kilo Code | 오픈소스 | VS Code, JetBrains, CLI, Slack | Cline 계열 포크. 다중 모드 |
| Aider | Apache 2.0 | 터미널 | Git 커밋 직결. 가장 성숙한 터미널 도구 |
| OpenCode | 오픈소스 | 터미널 | 기존 구독 재활용 |
| Open Interpreter | Apache 2.0 | CLI | 원시적·범용. 네이티브 샌드박싱 |
| Tabby | 오픈소스 | 자체 호스팅 서버 | 코드 완성 특화. 데이터 레지던시 요구 환경용 |
| Devin | 상용 | 클라우드 | 이 카테고리의 원형 |
4.2 범용 및 업무 에이전트
| 프로젝트 | 라이선스 | 성격 |
|---|---|---|
| Manus | 상용 | 크레딧 기반 자율 태스크. 완성된 제품 경험 |
| Claude Cowork | 상용 | 관리형 지식노동 에이전트 |
| AutoGPT | 오픈소스 | 초기 자율 에이전트 프레임워크. 샌드박스 부재 |
| 메시징 네이티브 에이전트 | 상용 | 문자·채팅 안에서 동작. 파일 산출물이 아닌 대화 흐름 중심 |
4.3 워크플로 오케스트레이션
| 프로젝트 | 라이선스 | 차이 |
|---|---|---|
| n8n | 제한적 라이선스 | 시각적 편집 강점. 사전 정의 플로우 실행 |
| Dify | 오픈소스 | LLM 앱 빌더. 목표 기반 자율 분해가 아님 |
| Zapier Agents | 상용 | SaaS 연동 폭 최대 |
4.4 프로토콜 및 기반 계층
| 항목 | 역할 | 비고 |
|---|---|---|
| MCP (Model Context Protocol) | 도구 연결 표준 | 세 프로젝트 모두 채택. AAIF 소속 |
| ACP (Agent Client Protocol) | 에이전트 상호 구동 표준 | goose, OpenHands 채택 |
| AGENTS.md | 에이전트 지시문 표준 | AAIF 소속 |
| aisuite | 프로바이더 추상화 | OpenWorker의 기반 |
| LiteLLM | 프로바이더 추상화 | OpenHands의 기반 |
5. 도구 난립의 문제
이 분야의 문제는 선택지가 많다는 것이 아니라, 선택지들이 서로를 감싸기 시작했다는 것이다.
5.1 중첩 구조
2026년 현재 다음 구성이 실제로 가능하다.
OpenHands Agent Canvas
└─ ACP 프로바이더로 Claude Code 구동
└─ MCP 서버 12개 연결
└─ 그중 하나가 goose를 서브에이전트로 호출
└─ goose가 Ollama 로컬 모델로 라우팅
각 계층은 독립적으로 합리적이다. 합쳐 놓으면 어느 계층이 어떤 권한으로 무엇을 실행했는지 추적할 수 있는 사람이 조직에 없다. 계층마다 로그 포맷이 다르고, 권한 모델이 다르고, 실패 모드가 다르다.
5.2 표준의 역설
MCP와 ACP는 파편화를 해결하려고 만들어졌다. 실제로는 연결 비용을 낮춰 연결 개수를 폭증시켰다. 신뢰 검증 비용은 그대로인데 연결 수만 늘면 총 리스크는 증가한다. 표준화가 보안을 개선한다는 통념은 이 경우 성립하지 않는다.
5.3 정보 부패
저장소가 이전되고, 라이선스가 분화되고, 기본 설치 경로가 바뀌는 속도를 문서화가 따라가지 못한다. 그 공백을 AI가 생성한 리뷰 콘텐츠가 메우고, 그 콘텐츠가 다시 학습 데이터가 되고 있다. 누군가의 오류 포스팅, LLM이 오독한 정보가 유통되면서 정보가 오염되고 증폭되어 재인용되는 현상이 발견되고 있다. 의도된 오류, 경쟁자의 의도적 오염, 사람의 실수, LLM의 재학습 인용까지 다양한 케이스가 만들어질 수 있다. 정보의 유통에서 LLM의 개입은 앞으로 인공지능이 만든 문서, 포스팅으로 피로감을 증폭시키고 있다.
실무 규칙 하나면 충분하다. README와 LICENSE를 직접 열어라. 이 문서가 실측 기준일을 명시하는 이유도 같다.
5.4 도입 피로
세 프로젝트 모두 "설치는 5분"이라고 홍보한다. 실제 도입 비용은 다음과 같다.
| 항목 | 실소요 |
|---|---|
| 설치와 모델 키 설정 | 10분 |
| 커넥터 인증 | 도구당 5~15분 |
| 권한 정책 수립 | 수 시간 |
| 조직 배포 표준화 | 수 일 |
| 로그·감사 체계 설계 | 수 주 |
| 사고 대응 절차 정립 | 미착수인 조직이 대부분 |
아래로 갈수록 아무도 하지 않는다. 그리고 사고는 아래에서 난다.
6. CTI 관점: 에이전트라는 새로운 블랙박스
6.1 이중 블랙박스
LLM이 블랙박스라는 지적은 오래됐다. 에이전트는 여기에 두 번째 층을 얹는다.
| 계층 | 불투명성의 성격 |
|---|---|
| 모델 | 왜 그 출력을 냈는지 설명 불가 |
| 오케스트레이션 | 어떤 도구를, 어떤 순서로, 어떤 권한으로 호출했는지 사후 재구성 곤란 |
두 번째 레이어가 더 위험하다. 첫 번째 층의 오류는 잘못된 문장을 낳지만, 두 번째 층의 오류는 실행된 명령을 낳는다. 그리고 실행은 되돌릴 수 없다.
6.2 LLM은 엑셀이지 오라클이 아니다
이 프레이밍이 가장 정확히 들어맞는 지점이 에이전트의 방어 계층이다.
goose의 Smart Approval은 PermissionJudge라는 LLM 분류기가 도구 호출의 위험도를 판정한다. AdversaryInspector도 자연어 규칙을 LLM이 해석해 셸 명령을 차단할지 결정한다. 즉 프롬프트 인젝션으로 우회 가능한 판정 주체를, 프롬프트 인젝션 대응책으로 쓰고 있다.
LLM은 계산 도구다. 입력에 따라 출력이 흔들리는 것이 정상이다. 그 도구에 최종 판정을 맡기면 방어는 확률적이 되고, 확률적 방어는 감사 대상 통제로 제출할 수 없다. 결정론적 통제(경로 화이트리스트, 네트워크 이그레스 차단, 마운트 범위 제한, 자격증명 스코프)가 반드시 하위 계층에 있어야 한다.
6.3 신뢰 위임의 자기신고 문제
goose의 Smart Approval은 MCP 표준의 read_only_hint 필드를 읽어 자동 승인 여부를 결정한다. 이 값은 MCP 서버가 자기 자신에 대해 선언하는 값이다.
악성 MCP 서버가 쓰기 도구를 read_only: true로 선언
→ Smart Approval이 자동 승인 목록에 편입
→ 사용자 확인 없이 실행
검증 주체 없이 선언을 신뢰하는 구조는 인증서 없는 TLS와 같다. MCP 구조적 취약점 분석(CTI-2026-0422-MCP)에서 다룬 신뢰 위임 문제가 그대로 재현된다.
6.4 치명적 사고 가능성
에이전트 사고의 전제 조건은 세 가지가 동시에 성립할 때 나타난다.
| 조건 | 세 프로젝트에서의 구현 |
|---|---|
| 민감 데이터 접근 | 로컬 파일, 저장소, 메일, 채널 로그 |
| 신뢰할 수 없는 입력 노출 | 웹 문서, 이슈 본문, 메일, Slack 메시지, MCP 응답 |
| 외부 통신 능력 | 모델 API 호출, 커넥터 쓰기, 셸 네트워크 명령 |
세 프로젝트 모두 기본 구성에서 세 조건을 충족한다. 특히 OpenHands의 웹훅 트리거 자동화는 두 번째 조건을 상시화한다. 외부인이 이슈를 열 수 있는 공개 저장소에 자동 분해 자동화를 걸어두면, 이슈 본문이 곧 원격 지시문이 된다.
6.5 승인 피로
승인 게이트는 세 프로젝트의 공통 방어선이다. 그리고 공통 약점으로 보인다.
| 단계 | 사용자 행동 |
|---|---|
| 1주차 | 모든 승인 요청을 읽고 판단 |
| 2주차 | 익숙한 패턴은 훑고 승인 |
| 4주차 | 반사적으로 승인 |
| 6주차 | 자율 모드로 전환 |
goose는 이 경로를 설계로 촉진한다. 서브에이전트를 쓰려면 승인 모드를 꺼야 하기 때문이다. 승인 게이트를 최종 방어선으로 상정한 위협 모델은 현실에서 성립하지 않는다.
6.6 공급망
| 경로 | 위험 |
|---|---|
| 파이프-투-셸 설치 | goose CLI 공식 설치법. 스크립트 무결성 검증 없이 실행 |
| npm 전역 설치 | OpenHands 권장 1순위. 의존성 트리 전체가 신뢰 대상 |
| MCP 서버 임의 연결 | 세 프로젝트 공통. 레지스트리 검증 부재 |
| 자동 업데이트 | OpenWorker 기본 활성. 배포 채널 침해 시 전 사용자 즉시 영향 |
| 컨테이너 이미지 | 태그 고정 없이 사용 시 이미지 교체 리스크 |
GitHub 공급망 공격 분석(TeamPCP, Mini Shai-Hulud)에서 확인한 패턴이 그대로 적용된다. 차이는 침해된 패키지가 이번에는 셸 접근 권한을 가진 상태로 상시 구동된다는 점이다.
6.7 자격증명 집중
에이전트 도입의 실질은 자격증명 집중이다. 모델 API 키, GitHub 토큰, Slack 토큰, Jira 자격증명, Gmail OAuth 토큰이 한 프로세스의 접근 범위에 모인다. 로컬 시크릿 스토어에 보관된다는 것은 유출 시 단일 지점에서 전부 유출된다는 뜻이기도 하다.
6.8 위협 매핑
| 시나리오 | ATT&CK 기법 | 진입점 |
|---|---|---|
| 이슈 본문 인젝션으로 셸 명령 유도 | T1059 Command and Scripting Interpreter | 웹훅 자동화 |
| 악성 MCP 서버 연결 | T1195.002 Compromise Software Supply Chain | 확장 설치 |
| 로컬 시크릿 스토어 탈취 | T1555 Credentials from Password Stores | 로컬 침해 |
| 설정 파일 내 API 키 수집 | T1552.001 Credentials In Files | 파일 접근 도구 |
| 모델 API 트래픽에 데이터 은닉 | T1071.001 Application Layer Protocol | 정상 이그레스 |
| 커넥터 경유 데이터 반출 | T1567.002 Exfiltration Over Web Service | 쓰기 권한 커넥터 |
| 스케줄 자동화에 지속성 확보 | T1053.003 Scheduled Task/Job: Cron | 레시피, 자동화 서버 |
| 승인 피로 악용 | T1204.002 User Execution | 승인 UI |
| OAuth 토큰 재사용 | T1078 Valid Accounts | 커넥터 인증 |
6.9 탐지가 어려운 이유
| 요인 | 설명 |
|---|---|
| 정상 트래픽과 구분 불가 | 에이전트의 모델 API 호출은 정상 동작이다. 그 안에 무엇이 실려 나가는지는 페이로드를 봐야 안다 |
| 비결정성 | 같은 입력에 같은 도구 호출이 나오지 않는다. 베이스라인 수립이 어렵다 |
| 로그 파편화 | 프런트엔드, 에이전트 서버, MCP 서버, 모델 프로바이더가 각각 다른 로그를 남긴다 |
| 사용자 귀속 | 에이전트가 실행한 명령은 사용자 계정으로 기록된다. 주체 구분이 로그에 남지 않는다 |
| 세션 휘발 | 대화 컨텍스트가 보존되지 않으면 사후 재구성이 불가능하다 |
6.10 최소 통제 항목
승인 게이트와 LLM 판정에 의존하지 않는, 결정론적 통제만 추린 목록이다.
| 계층 | 통제 |
|---|---|
| 실행 | 컨테이너 격리를 기본값으로. 호스트 직접 실행 금지 |
| 파일 | 마운트 범위를 프로젝트 디렉터리로 제한. 홈 디렉터리 전체 마운트 금지 |
| 네트워크 | 이그레스 허용 목록 운영. 모델 엔드포인트와 필요한 커넥터만 |
| 자격증명 | 최소 권한 스코프. 조직 전체 토큰 사용 금지. 에이전트 전용 계정 분리 |
| 확장 | MCP 서버 화이트리스트. read_only_hint를 신뢰 근거로 삼지 않음 |
| 버전 | 자동 업데이트 비활성, 이미지 태그 고정, 락파일 커밋 |
| 권한 모드 | 자율 모드를 배포 이미지에서 차단. Custom Distros 등으로 강제 |
| 감사 | 세션 트랜스크립트 중앙 수집. 에이전트 주체 식별자 부여 |
| 트리거 | 외부인이 작성 가능한 텍스트를 지시문 경로로 연결하지 않음 |
| 비용 | 프로바이더 콘솔 한도를 이상 탐지 신호로 병용 |
6.11 결론
에이전트는 생산성 도구인 동시에 셸 접근 권한을 가진 상시 구동 프로세스이며, 신뢰할 수 없는 외부 텍스트를 지시문으로 받아들이고, 조직의 자격증명을 한곳에 모아 보관한다.
이 서술의 어느 부분도 과장이 아니다. 세 프로젝트의 공식 문서에서 그대로 확인되는 사실이다. 문제는 이 사실이 도입 검토 단계에서 거의 논의되지 않는다는 점이다.
도입하지 말라는 뜻이 아니다. 도입 문서에 위 문장을 그대로 적고 시작하라는 뜻이다.
7. 도입 체크리스트
| # | 항목 | 확인 |
|---|---|---|
| 1 | LICENSE 원문을 열어봤는가. 오픈코어 여부와 분리 구간을 특정했는가 | |
| 2 | 저장소 URL과 조직명이 현재도 유효한가 | |
| 3 | 기본 설치 경로에 실행 격리가 있는가. 없다면 격리 경로를 표준으로 채택했는가 | |
| 4 | 기본 권한 모드를 확인하고 조직 표준으로 재설정했는가 | |
| 5 | 승인 게이트를 우회하게 만드는 기능 제약이 있는가 (예: 서브에이전트) | |
| 6 | 클라우드 모델을 쓴다면 어떤 데이터가 나가는지 목록화했는가 | |
| 7 | MCP 서버 화이트리스트를 정의했는가 | |
| 8 | 자격증명 스코프를 최소화하고 전용 계정을 분리했는가 | |
| 9 | 외부인이 작성 가능한 텍스트가 지시문 경로로 들어오는 지점을 식별했는가 | |
| 10 | 네트워크 이그레스 허용 목록을 운영하는가 | |
| 11 | 세션 로그 보관과 민감정보 마스킹 방안이 있는가 | |
| 12 | 모델 비용 한도를 설정했는가 | |
| 13 | 자동 업데이트 정책과 버전 고정 방침을 정했는가 | |
| 14 | 에이전트 관련 사고 대응 절차가 문서화돼 있는가 | |
| 15 | 6개월 뒤 프로젝트 구조가 바뀔 가능성을 전제한 이탈 계획이 있는가 |
8. 문서 규약
- 모든 수치는 저장소 페이지 직접 조회 기준이며 측정일을 명시한다. 2차 출처 인용 시 출처와 편차를 함께 기록한다.
- 설치 절차는 공식 README 기준으로만 기록한다. 블로그와 튜토리얼은 참조하지 않는다.
- 라이선스는 LICENSE 파일 원문 확인을 원칙으로 한다.
- 벤더 홍보 문구는 그대로 옮기지 않는다. 특히 프라이버시와 보안 관련 주장은 구현 수준에서 검증한다.
- 이모지를 사용하지 않는다.
9. 참고
| 프로젝트 | 저장소 | 문서 |
|---|---|---|
| OpenWorker | github.com/andrewyng/openworker | openworker.com |
| aisuite | github.com/andrewyng/aisuite | — |
| goose | github.com/aaif-goose/goose | goose-docs.ai |
| Agentic AI Foundation | — | aaif.io |
| OpenHands | github.com/OpenHands/OpenHands | docs.openhands.dev |
| Agent Canvas | github.com/OpenHands/agent-canvas | — |
| software-agent-sdk | github.com/OpenHands/software-agent-sdk | — |
| Model Context Protocol | — | modelcontextprotocol.io |
본 문서는 특정 벤더와 이해관계 없이 작성됐다. 도입 판단은 각 조직의 위협 모델과 규제 요건에 따라 달라진다.