2026년 5월 10일 KST 기준, AgentScope는 ReAct agent, tools, skills, human-in-the-loop, memory, planning, realtime voice, evaluation, MCP, A2A, OpenTelemetry 지원을 전면에 내세우는 오픈소스 AI 에이전트 프레임워크다.
이 문장만 보면 꽤 멋지다. 그런데 회사 업무에 붙일 때 먼저 봐야 할 것은 멋짐이 아니라 손실 반경이다.
AgentScope README의 예제는 Toolkit에 execute_python_code와 execute_shell_command를 등록해 ReAct agent가 코드를 실행하고 shell command를 호출할 수 있게 만든다. 기능적으로는 매력적이지만, 운영자 눈에는 바로 빨간펜이 들어간다.
도구 실행, MCP 서버, 장기 메모리, 외부 모델 키, 브라우저 자동화가 한 시스템 안에 섞이면 사고 지점도 같이 늘어난다. 그래서 이 글은 AgentScope를 써도 되는지 묻기보다, 회사 업무에 붙이기 전에 무엇을 잠가야 하는지부터 정리한다.
먼저 정할 답
AgentScope 같은 오픈소스 AI 에이전트 프레임워크는 사내 업무에 붙일 수 있다. 다만 read-only 조사, sandboxed 실행, 사람 승인, 관측 로그, 메모리 삭제 규칙이 먼저 정리되어야 한다.
처음부터 GitHub token, 사내 DB, 고객 문서, 결제 API, 프로덕션 shell을 한 번에 붙이면 안 된다. 에이전트가 똑똑해서 괜찮은 게 아니라, 에이전트가 똑똑할수록 더 넓은 일을 해치울 수 있어서 더 위험하다.
내가 이번에 확인한 최소 감사는 세 가지였다. 공식 README와 docs를 보고, /tmp/agentscope-audit에 저장소를 얕게 클론해서 파일 구조와 테스트 이름을 훑고, 어떤 기능이 권한 경계로 번질 수 있는지 표시했다.
그 결과 핵심은 간단했다. AgentScope의 문제라기보다, 오픈소스 에이전트 프레임워크를 회사 업무에 붙일 때 생기는 공통 운영 문제다.
왜 이 글감이 지금 맞나
AgentScope GitHub README는 2026년 4월에 AgentScope 2.0이 오고 있다고 적고, 2026년 1월에는 database support와 memory compression이 memory module에 들어갔다고 안내한다. 2025년 말에는 A2A, Anthropic Agent Skill, ReMe long-term memory 같은 통합도 이어졌다.
공식 사이트도 AgentScope를 core framework, runtime, memory, evaluation, finetuning, ready-to-use applications까지 이어지는 open stack으로 설명한다. 즉 단순한 toy agent 예제가 아니라 agent lifecycle 전체를 잡으려는 프로젝트에 가깝다.
문제는 그 범위가 넓다는 점이다. 범위가 넓으면 팀에서는 “이거 하나로 다 되나?”라는 기대가 생기고, 기대가 커질수록 처음 붙이는 권한도 커진다.
나는 여기서 브레이크를 먼저 밟아야 한다고 본다. AgentScope가 나빠서가 아니라, tool execution과 memory와 MCP를 가진 에이전트는 작은 자동완성 도구가 아니라 작은 운영자에 가깝기 때문이다.
내가 확인한 표면 감사
로컬에 저장소를 얕게 클론해보니 src/agentscope 아래에 agent, mcp, memory, model, rag, session, tool, tracing 같은 모듈이 나뉘어 있었다. 테스트 파일도 toolkit_middleware_test.py, mcp_streamable_http_client_test.py, memory_test.py, tracing_test.py처럼 운영 경계와 직접 연결되는 축이 보였다.
pyproject.toml 기준으로 Python 요구 버전은 3.10 이상이고, 라이선스는 Apache-2.0이다. 핵심 dependency에는 mcp>=1.13, openai, anthropic, dashscope, opentelemetry-*, sqlalchemy, python-socketio 등이 들어간다.
이 조합은 실무 관점에서 신호가 선명하다. 모델 API, MCP, tracing, session, memory, tool execution을 한 번에 다룰 수 있다는 뜻이고, 동시에 secret 관리와 로그 정책을 대충 두면 한 번에 여러 층이 새어 나갈 수 있다는 뜻이다.
테스트 목록에서 특히 눈에 들어온 것은 middleware, MCP client, memory, tracing이었다. 이 네 가지는 기능 체크가 아니라 운영 체크의 출발점이다.
1단계: 도구 실행 권한을 먼저 쪼갠다
AgentScope tool docs는 Toolkit이 Python tool function, middleware, MCP integration, agent skills를 관리한다고 설명한다. 같은 문서에는 built-in tool function으로 execute_python_code, execute_shell_command, text file read/write utilities가 언급된다.
이 말은 에이전트가 단순히 답변하는 게 아니라 실제 작업을 할 수 있다는 뜻이다. 회사 업무에 붙이면 가장 먼저 물어야 할 질문은 “어떤 도구를 쓸 수 있나”가 아니라 “이 도구가 틀렸을 때 무엇까지 바꿀 수 있나”다.
권한표는 최소 4칸으로 나누는 편이 좋다. 읽기 전용 도구, 임시 파일 쓰기 도구, 외부 API 호출 도구, shell/code execution 도구다.
처음 PoC에서는 shell command와 파일 쓰기 도구를 기본 OFF로 두는 게 낫다. 꼭 필요하면 테스트용 repo, 테스트용 workspace, 테스트용 API key 안에서만 켜야 한다.
| 권한 구간 | 허용 예시 | 기본값 | 이유 |
|---|---|---|---|
| 읽기 전용 | 문서 검색, README 요약, issue 조회 | ON | 실패해도 side effect가 작다 |
| 제한 쓰기 | 임시 폴더에 결과 저장, PR branch 수정 | 조건부 | diff와 reviewer가 필요하다 |
| 외부 API | Slack, Jira, GitHub, CRM 호출 | OFF | 데이터 유출과 상태 변경 위험이 있다 |
| code/shell 실행 | Python 실행, shell command, 파일 삭제 | OFF | host 권한과 secret 노출로 번지기 쉽다 |
이 표 없이 프레임워크부터 붙이면 운영이 금방 흐려진다. 에이전트가 잘못한 게 아니라, 사람이 문을 너무 많이 열어둔 것이다.
2단계: MCP는 연결 수보다 출처가 먼저다
AgentScope docs는 MCP 통합을 지원하고, HTTP stateful/stateless client와 StdIO stateful client를 설명한다. 특히 StdIO stateful client는 connect() 시 로컬 MCP 서버를 시작한다고 되어 있다.
이 지점은 회사 보안팀이 싫어할 만하다. 로컬 프로세스를 띄우고, 외부 도구를 붙이고, session state를 유지할 수 있다는 뜻이기 때문이다.
MCP를 붙일 때는 서버별로 세 가지를 기록해야 한다. 누가 만든 서버인지, 어떤 command로 실행되는지, 어떤 secret과 network 목적지를 쓰는지다.
예를 들어 GitHub MCP 서버를 붙이면 repo 읽기만 하는지 issue 생성도 하는지, PR comment만 남기는지 branch push까지 하는지 분리해야 한다. Google Drive나 Slack MCP를 붙이면 개인 문서와 회사 문서 경계도 같이 봐야 한다.
MCP 서버는 “도구 하나 추가”가 아니다. 에이전트에게 손과 발을 더 달아주는 것이다. 손발이 늘면 장갑도 늘려야 한다.
3단계: 메모리는 편의 기능이 아니라 데이터 저장소다
AgentScope memory docs는 short-term memory와 long-term memory를 나눈다. short-term memory에는 InMemoryMemory, AsyncSQLAlchemyMemory, RedisMemory가 있고, long-term memory에는 Mem0LongTermMemory, ReMePersonalLongTermMemory 같은 선택지가 있다.
문서에는 message에 mark를 붙여 hint, summary, tool_result 같은 용도로 관리할 수 있다고 되어 있다. 이건 운영에 꽤 좋지만, 동시에 데이터 분류 규칙이 없으면 민감 정보가 오래 남을 수 있다.
회사 업무에서는 memory를 “대화 편의 기능”으로 보면 안 된다. 고객명, 계약 조건, 장애 로그, API 응답, 내부 문서 일부가 들어갈 수 있는 저장소로 봐야 한다.
그래서 memory 정책은 처음부터 정해야 한다. 저장해도 되는 mark, 저장하면 안 되는 mark, 삭제 주기, 사용자별 분리, session별 분리, 압축 summary에 들어가면 안 되는 정보까지 정해야 한다.
| 메모리 항목 | 저장 가능 여부 | 운영 기준 |
|---|---|---|
| 공개 문서 요약 | 가능 | source URL과 날짜를 같이 보관 |
| 내부 runbook 요약 | 조건부 | 접근권한 있는 사용자 session에만 저장 |
| 고객 데이터 | 기본 금지 | 필요 시 마스킹 후 짧은 TTL |
| API key, token, cookie | 금지 | memory와 trace 양쪽에서 차단 |
| tool result 원문 | 조건부 | 길이 제한, 민감 필드 제거, 만료 설정 |
특히 long-term memory를 agent_control 모드로 둘 때는 조심해야 한다. AgentScope docs도 명확한 instruction이 없으면 memory tool을 최적으로 쓰지 못할 수 있다고 적는다.
4단계: sandbox를 “있다”가 아니라 “어디서 도는가”로 본다
AgentScope Runtime docs는 sandbox가 tool execution, browser automation, file system operations를 위한 secure and isolated environment라고 설명한다. 로컬에서는 Docker, gVisor, BoxLite를 쓸 수 있고, 대규모 원격/프로덕션에서는 Kubernetes, Function Compute, ACK 같은 선택지도 언급한다.
이건 좋은 방향이다. 다만 회사 업무에서는 “sandbox 지원”이라는 단어만 보고 안심하면 안 된다.
봐야 할 것은 sandbox backend, network egress, volume mount, secret 주입 방식, 로그 저장 위치다. sandbox가 있어도 host filesystem을 넓게 mount하거나, production secret을 환경변수로 넣거나, network가 모두 열려 있으면 격리 효과가 크게 줄어든다.
샌드박스는 냉장고가 아니라 금고처럼 봐야 한다. 안에 넣었다고 다 안전한 게 아니라, 열쇠와 벽 두께와 출입 기록이 같이 중요하다.
PoC 단계에서는 browser sandbox와 filesystem sandbox를 분리하고, base sandbox의 shell 실행은 demo command만 허용하는 방식이 낫다. “일단 다 열고 나중에 막자”는 보안의 오래된 사망 플래그다.
5단계: 관측성은 비용이 아니라 보험이다
AgentScope observability docs는 OpenTelemetry 기반 tracing을 제공한다고 설명한다. LLM call, tool invocation, agent reply, formatter, embedding call을 trace로 볼 수 있고, AgentScope Studio나 OTLP-compatible backend로 보낼 수 있다.
이건 TECHTAEK 관점에서 꽤 중요한 장점이다. 에이전트가 왜 특정 tool을 불렀는지, 어떤 입력으로 호출했는지, latency와 token usage가 어땠는지 보지 못하면 운영은 금방 감으로 흘러간다.
다만 trace에도 민감 정보가 남을 수 있다. tool input, tool output, model message, error stack에 고객 데이터나 token이 들어갈 수 있기 때문이다.
그래서 tracing을 켜기 전에 로그 마스킹부터 정해야 한다. trace를 켜지 않으면 장애 분석이 어렵고, trace를 대충 켜면 개인정보 저장소가 하나 더 생긴다.
운영 기준은 단순하다. trace는 켜되, secret redaction과 retention을 같이 켠다. 그리고 외부 SaaS tracing으로 보낼 때는 어떤 데이터가 나가는지 보안팀과 먼저 합의한다.
6단계: privacy flow를 output만 보지 않는다
2026년 3월 arXiv에 올라온 AgentSCOPE privacy 논문은 agentic workflow의 privacy를 최종 output만 보고 평가하면 위험하다고 지적한다. 논문 초록은 agent query, tool response 같은 중간 정보 흐름도 각각 평가해야 한다고 말한다.
이 관점은 AgentScope 같은 프레임워크를 회사 업무에 붙일 때 그대로 적용된다. 최종 답변이 깨끗해도, 중간 tool response에서 민감 정보가 모델 context로 들어갔으면 이미 사고가 시작된 것이다.
예를 들어 에이전트가 “고객 A의 최근 계약만 요약해줘”라는 요청을 처리한다고 하자. 최종 답변은 마스킹되어 나왔더라도, tool response가 전체 고객 DB를 반환했고 그 일부가 memory나 trace에 남았다면 출력만 보고는 잡기 어렵다.
그래서 보안 체크는 input/output filter만으로 끝나면 안 된다. tool argument, tool response, memory write, trace export, external API call을 각각 별도 boundary로 봐야 한다.
회사 업무에 붙이기 전 10문항 체크리스트
아래 10개 중 3개 이상 답을 못 하면 바로 production 연결은 멈추는 편이 좋다. PoC는 할 수 있지만, 사내 업무 자동화라고 부르기엔 아직 이르다.
| 질문 | 통과 기준 |
|---|---|
| 어떤 tool이 read-only이고 어떤 tool이 write 가능한가 | tool registry에 권한 등급이 있다 |
| shell/code 실행은 어디서 도는가 | sandbox backend와 network egress가 문서화되어 있다 |
| MCP 서버는 누가 관리하는가 | source, command, secret, 목적지가 기록되어 있다 |
| memory에 무엇을 저장하는가 | mark별 저장/삭제 정책이 있다 |
| tool result 원문은 저장되는가 | 저장 여부와 redaction 규칙이 있다 |
| trace에는 어떤 payload가 남는가 | secret redaction과 retention이 있다 |
| 사람이 승인해야 하는 작업은 무엇인가 | 결제, 배포, 삭제, 외부 발송은 approval gate가 있다 |
| API key는 어떻게 주입되는가 | 장기 키를 agent prompt나 memory에 노출하지 않는다 |
| 실패 시 롤백은 어떻게 하나 | branch, job, sandbox session 단위로 되돌릴 수 있다 |
| 누가 감사 로그를 볼 수 있나 | 운영자와 보안 담당자 접근권한이 분리되어 있다 |
이 표는 AgentScope만의 표가 아니다. LangGraph, AutoGen, OpenHands, 사내 자체 에이전트에도 거의 그대로 적용된다.
오픈소스 프레임워크 선택은 별점 싸움으로 시작하기 쉽다. 하지만 회사 업무에 붙이는 순간 별보다 중요한 것은 권한표, 로그, 삭제 규칙이다.
바로 붙여도 되는 경우와 아직 기다릴 경우
AgentScope를 바로 검토해도 되는 경우는 있다. 사내 문서 요약, 공개 문서 리서치, 내부 runbook 초안 생성, 테스트 repo 안에서의 코드 실험처럼 side effect가 작고 rollback이 쉬운 업무다.
반대로 고객 데이터, 결제, 환불, production DB, production deployment, 사내 메신저 대량 발송은 바로 붙이면 안 된다. 이런 업무는 framework보다 policy가 먼저다.
첫 주 실험은 작게 잡는 것이 좋다. read-only 문서 검색 agent 하나, sandboxed code runner 하나, MCP 서버 하나만 붙이고 trace를 켠 뒤, 실제 tool call 로그를 20개 정도 리뷰한다.
그 로그에서 “이 입력은 너무 넓다”, “이 응답은 저장하면 안 된다”, “이 도구는 사람 승인이 필요하다”가 보이면 정상이다. 그게 안 보이면 시스템이 안전한 게 아니라 아직 제대로 본 적이 없는 것이다.
FAQ
AgentScope는 회사 업무에 써도 되나?
쓸 수는 있지만 바로 production 권한을 주면 안 된다. read-only PoC, sandboxed execution, tool approval, memory policy, trace redaction을 먼저 정한 뒤 업무 범위를 넓히는 게 안전하다.
AgentScope가 sandbox를 지원하면 shell 실행을 켜도 괜찮나?
sandbox 지원은 좋은 출발점이지만 면허증은 아니다. backend, mounted volume, network egress, secret injection, log retention을 확인하지 않은 shell execution은 여전히 위험하다.
MCP 서버는 몇 개까지 붙여도 괜찮나?
개수보다 출처와 권한이 먼저다. 각 MCP 서버의 실행 command, 관리 주체, secret, network 목적지, 가능한 side effect를 기록할 수 없다면 추가하지 않는 편이 낫다.
memory 기능은 왜 위험한가?
memory는 에이전트의 편의 기능이면서 동시에 데이터 저장소다. 고객 정보, 내부 문서, tool result, 오류 stack이 장기 memory나 summary에 남을 수 있어서 저장 대상과 삭제 주기를 먼저 정해야 한다.
AgentScope와 LangGraph, AutoGen 비교는 어디서 시작해야 하나?
다음 단계에서는 기능표보다 운영표로 비교하는 게 좋다. tool 권한 모델, human approval, memory 저장 방식, trace export, sandbox strategy, deployment path를 나란히 놓고 봐야 실무 선택이 된다.
공식 출처
- AgentScope GitHub README
- AgentScope official site
- AgentScope Tool Capabilities docs
- AgentScope Memory docs
- AgentScope Sandbox and Tool docs
- AgentScope Observability docs
- AgentScope 1.0 arXiv paper
- AgentSCOPE privacy paper
함께 보면 좋은 글
- AI 코딩 에이전트에 결제키와 배포권한을 어디까지 맡길까 2026
- AI 에이전트 자동화가 덜 깨지게 만드는 CLI 설계 2026
- 에이전트 스킬은 만들기보다 검증이 더 중요하다 2026
정리하면 AgentScope는 “재밌는 오픈소스 에이전트 프레임워크”로만 보면 아깝다. 회사 업무에 붙일 때는 tool, MCP, memory, sandbox, tracing을 각각의 보안 경계로 보고, 그 경계를 통과한 뒤에야 production workflow로 올리는 게 맞다.