Python 없이도 에이전트를 만들 수 있을까? 이 질문은 2025년까지만 해도 사치였다. ADK, CrewAI, LangChain, AutoGen — 진지한 에이전트 프레임워크라고 불리는 것들은 전부 Python 생태계 안에 있었다. Go 개발자가 에이전트를 만들고 싶으면, 결국 Python 서비스를 하나 더 띄워야 했다.

그런데 Tencent가 그걸 Go로 만들었다. 1,720 커밋, 1.5K 스타, enterprise 검증 완료된 진짜 production framework. 이름은 tRPC-Agent-Go. 이번 주 AI Tool of the Week로 이걸 골랐다.

tRPC-Agent-Go가 뭘 하는 놈인가

한 줄로 말하면 Go-native multi-agent framework다. LLM 호출부터 멀티 에이전트 오케스트레이션, 그래프 워크플로우, 도구 호출, 세션·메모리 상태, 지식 검색(RAG), 에이전트 자기 진화, 평가, OpenTelemetry 관측성까지 — 에이전트 시스템을 만드는 데 필요한 걸 전부 내장하고 있다.

용도는 뻔하다. 고객 지원 봇, 데이터 분석 에이전트, DevOps 자동화, 비즈니스 프로세스 자동화, RAG 기반 연구 도구. 요즘 스타트업이 Python으로 만드는 걸 Go로 하는 거다.

그런데 이게 단순한 Go 래퍼가 아니라는 게 포인트. 내부 아키텍처를 들여다보면 생각보다 훨씬 잘 짜여 있다.

아키텍처: Runner가 Agent를 감싸고, Agent가 모든 걸 호출한다

tRPC-Agent-Go의 구조는 명확하다. Runner → Agent → Model/Tool/Planner라는 세 계층으로 되어 있다. Runner는 전체 실행 파이프라인을 관리하고, Agent는 실제 추론과 도구 호출을 수행하고, 하위 모듈들은 각자 자기 역할만 한다.

Runner (세션·메모리·이벤트 흐름) └─ Agent ├─ Model (LLM 호출, OpenAI 호환) ├─ Tool (함수, MCP, 웹 검색, 코드 실행) ├─ Planner (React, Builtin, Custom) ├─ Memory (장기 기억, CRUD + 검색) ├─ Knowledge (RAG, 벡터 검색) ├─ Skill (SKILL.md 워크플로우) └─ Evolution (세션 리뷰 → SKILL.md 추출)

여기서 중요한 건 모든 모듈이 플러그인처럼 교체 가능하다는 점이다. Model은 OpenAI, DeepSeek, Hunyuan 등 OpenAI 호환 인터페이스만 있으면 뭐든 붙는다. Memory는 in-memory와 Redis를 지원한다. Knowledge는 pgvector + Elasticsearch 백엔드를 쓴다. 스토리지는 S3와 COS까지.

내가 특히 주목한 건 Event 모듈이다. 모든 Agent는 Run(ctx, invocation) → (<-chan *event.Event, error) 인터페이스를 따른다. 리턴 타입이 Go 채널이다. 이 말은 모든 에이전트 실행이 스트리밍 기반이고, context 취소로 중단할 수 있으며, 동시성 제어가 언어 레벨에서 보장된다는 뜻이다. Python의 asyncio 이벤트 루프를 다루는 것과는 완전히 다른 세계다.

GraphAgent: Go 버전의 LangGraph

tRPC-Agent-Go가 자랑하는 기능 중 하나가 GraphAgent다. 상태 머신 기반 워크플로우 엔진으로, 노드와 조건부 라우팅으로 복잡한 실행 그래프를 만든다. 기능적으로는 LangGraph의 Go 포트라고 봐도 된다.

흥미로운 건 이걸 만든 이유다. README에 따르면 Tencent 내부에 이미 그래프 오케스트레이션으로 AI 애플리케이션을 만드는 팀이 많았고, 기존 자산의 호환성을 유지하면서 multi-agent로 올라타기 위해 GraphAgent를 제공했다고 한다. “이미 있는 걸 버리지 말고, 그 위에 얹어라” — 이건 Drewgent의 contraction 원칙과 정확히 같은 철학이다.

그래프는 이렇게 만든다:

sg := graph.NewStateGraph(schema) sg.AddNode(“preprocess”, preprocess) sg.AddLLMNode(“analyze”, model, “analyze…”, tools) sg.AddToolsNode(“tools”, tools) sg.AddConditionalEdges(“router”, conditionFn, pathMap) sg.SetEntryPoint(“preprocess”) sg.SetFinishPoint(“format_output”) g, _ := sg.Compile()

graphAgent, _ := graphagent.New(“processor”, g) runner := runner.NewRunner(“app”, graphAgent)

특히 AddMultiConditionalEdges가 눈에 띄었다. 하나의 노드에서 여러 브랜치로 동시에 팬아웃해서 병렬 실행할 수 있다. Go의 고루틴을 언어 레벨에서 활용하는, Python보다 자연스러운 설계다.

Agent Self-Evolution: 세션 리뷰 → SKILL.md 추출

이 부분은 Drewgent를 만드는 입장에서 특히 반가웠다. tRPC-Agent-Go는 Agent Self-Evolution이라는 기능을 제공한다. 완료된 세션을 백그라운드에서 리뷰하고, 재사용 가능한 SKILL.md 워크플로우를 추출해서 다음 세션에서 쓸 수 있게 만드는 구조다.

evo := evolution.NewService(reviewerModel, evolution.WithManagedSkillsDir(“./managed_skills”), evolution.WithSkillRepository(repo))

runner := runner.NewRunner(“app”, agent, runner.WithEvolutionService(evo))

작동 방식은 이렇다:

세션 완료 → Evolution Service가 백그라운드에서 리뷰 의미 있는 워크플로우를 SKILL.md로 추출 Quality gate 통과 → managed skills 디렉토리에 저장 다음 세션에서 skill_load, skill_run으로 호출 가능

이건 내가 Drewgent에서 생각했던 “taste feedback loop”와 거의 같은 패턴이다. 콘텐츠 파이프라인이 에디터의 QA 피드백을 받아서 다음 draft에 반영하는 것처럼, tRPC-Agent-Go는 세션 결과를 받아서 다음 실행에 반영한다. 차이가 있다면 Drewgent는 이걸 사람의 taste 신호 기반으로 하고, tRPC-Agent-Go는 LLM reviewer 기반으로 자동화했다는 점이다.

MCP, A2A, AG-UI — 에이전트 연결의 삼위일체

tRPC-Agent-Go는 프로토콜 통합이 정말 잘 되어 있다. MCP(stdio, SSE, Streamable HTTP 지원), A2A(에이전트 간 통신, ADK Python 서버와 interop까지 증명됨), AG-UI(CopilotKit, TDesign Chat 같은 프론트엔드와 SSE로 연결).

MCP 연동 코드가 이렇게 짧다:

mcpToolSet := mcp.NewMCPToolSet( mcp.ConnectionConfig{ Transport: “sse”, ServerURL: “http://localhost:8080/sse”, Timeout: 10 * time.Second, }, ) agent := llmagent.New(“mcp-assistant”, llmagent.WithModel(model), llmagent.WithToolSets([]tool.ToolSet{mcpToolSet}))

Drewgent도 MCP 서버 5개(codebase, discord, gjc, wordpress, astryx)를 쓰고 있고, ARD 카탈로그로 에이전트 검색까지 하고 있지만, tRPC-Agent-Go는 이걸 Go 코드 레벨에서 타입 세이프하게 통합했다는 게 차이점이다. Python에서는 MCP 연결이 대부분 dict 기반이라 런타임 에러가 나기 쉬운데, Go는 struct로 정의해서 컴파일 타임에 잡아낸다.

Tencent 내부에서 이미 검증됐다

README Acknowledgements를 보면 Tencent Yuanbao(元宝), Tencent Video, Tencent News, IMA, QQ Music에서 이미 production에 쓰고 있다고 밝히고 있다. tRPC 자체가 Tencent 내부에서 2백만 개 노드와 5만 개 이상 서비스에 사용되는 RPC 프레임워크니까, 그 위에 올라간 에이전트 프레임워크가 production에 안정적이라는 건 당연한 결과이긴 하다.

하지만 이건 오픈소스 관점에서 중요한 의미가 있다. 스타 수나 Github trending만 보고 판단하는 게 아니라, 실제 얼마나 큰 규모에서 검증됐는지가 진짜 신뢰도다. 1.5K 스타가 작아 보일 수 있지만, 2M+ 노드 인프라에서 쓰인 프레임워크라면 이야기가 다르다.

Drewgent랑 비교하면?

당원, 이제 진짜 질문으로 들어가자. tRPC-Agent-Go가 Drewgent의 대체재인가?

아니. 전혀 다른 축에서 노는 도구다. 이렇게 정리할 수 있다:

차원tRPC-Agent-GoDrewgent

언어Go (컴파일, 타입 세이프)Python + Bash + MCP 규모Enterprise (2M+ 노드 검증)Personal (1인 오케스트레이션) 지식 저장Redis, pgvector, S3, COSFilesystem + Obsidian + gbrain 에이전트 진화LLM reviewer 자동화Human taste feedback loop 에이전트 발견A2A interopARD catalog (.well-known) 핵심 철학”모든 걸 프레임워크 안에””덜어낼수록 강해진다”

tRPC-Agent-Go는 “풀스택 프레임워크” 접근이다. Agent, Runner, Model, Tool, Memory, Knowledge, Planner, CodeExecutor, Evolution — 모든 걸 하나의 의존성 그래프 안에 넣었다. Go 1.21만 있으면 된다.

Drewgent는 “컴포지션” 접근이다. Obsidian이 파일 시스템을 관리하고, opencode가 모델을 호출하고, MCP 서버들이 도구를 제공하고, gbrain이 지식을 색인하고, launchd가 cron을 돌린다. 각 컴포넌트가 독립적이고 교체 가능하다.

어느 쪽이 더 나은가? 규모에 따라 다르다. 팀 단위로 에이전트 시스템을 구축한다면 tRPC-Agent-Go가 압도적으로 생산성이 높을 거다. 혼자서 개인 인프라를 유지보수한다면 Drewgent처럼 느슨한 결합이 더 유연하다.

하지만 서로 배울 점은 분명히 있다:

Go의 타입 시스템 — Drewgent의 MCP 연결이나 config 구조에 타입 검증 계층을 추가하는 걸 고려해볼 만하다. Python은 런타임에서야 깨지는 경우가 너무 많다. Event + Context 기반 중단 — Drewgent의 GJC worktree 격리는 강력하지만, 실행 중단은 OS 시그널에 의존한다. tRPC-Agent-Go의 context.WithCancel + 채널 drain 패턴이 더 우아하다. SKILL.md + Evolution 루프 — tRPC-Agent-Go의 방식은 LLM reviewer로 자동화했지만, Drewgent의 human taste feedback이 품질 면에서는 더 높은 천장을 가질 수 있다. 둘을 합치는 게 가장 이상적인데, 아직 해결되지 않은 문제다.

이걸 써야 하는 사람

누가 tRPC-Agent-Go를 쓰면 좋을까?

Go로 서비스를 만들고 있는 팀 — 에이전트를 붙이려고 Python 마이크로서비스를 하나 더 띄우는 건 미친 짓이다. tRPC-Agent-Go면 같은 바이너리 안에서 다 된다. MCP 도구를 Go로 만들고 싶은 사람 — Python MCP 서버는 진입 장벽이 낮지만, Go MCP 서버는 성능과 배포가 훨씬 낫다. tRPC-Agent-Go는 MCP 클라이언트와 서버 양쪽을 다 지원한다. Enterprise 환경에서 에이전트를 운영해야 하는 팀 — Tencent 규모에서 검증됐다는 건, 당신 회사 규모에서도 충분히 안정적이라는 뜻이다. Python 생태계에 지친 사람 — LangChain의 추상화 지옥, asyncio 이벤트 루프 디버깅, 의존성 충돌. Go는 이 모든 게 훨씬 단순하다.

반대로 이럴 땐 굳이 안 써도 된다:

혼자 실험하는 단계면 Python이 더 빠르다. Go의 타입 시스템은 production에서 빛을 발하지, 프로토타이핑에선 오히려 속도를 늦춘다. 이미 Python 기반 에이전트 파이프라인이 잘 돌고 있다면, 갈아탈 이유가 없다. Ponytail 원칙: “이미 있는 걸로 되나?”

프롬프트 캐싱으로 90% 비용 절감 — 디테일이 좋다

하나 더 언급할 게 있다. tRPC-Agent-Go는 프롬프트 캐싱을 자동으로 해준다. 시스템 프롬프트나 SKILL.md 같은 정적 컨텐츠를 자동 감지해서 캐시 태그를 붙이고, 같은 내용이 반복되면 토큰을 다시 소비하지 않는다. README에 따르면 90% 비용 절감.

이건 작아 보이지만 실제로는 엄청난 차이다. Drewgent의 model routing 최적화(65% 절감)와 비슷한 결의 taste 결정이다. 비용 최적화는 afterthought이 아니라 아키텍처의 일부여야 한다는 걸 보여주는 사례다.

마무리: Go 에이전트 시대의 시작

tRPC-Agent-Go를 보면서 든 생각은 하나다. 에이전트 프레임워크의 Python 독점이 깨지고 있다. 2025년에는 “에이전트 = Python”이었지만, 2026년 중반이 된 지금 Go, Rust, TypeScript에서도 production급 프레임워크가 나오고 있다. 선택지가 늘어난다는 건 생태계 전체에 좋은 일이다.

Drewgent는 Python/MCP/GJC 스택을 계속 쓸 거다. 개인 인프라에선 컴파일 타임 타입 검사보다 배포 속도와 실험 유연성이 더 중요하기 때문이다. 하지만 tRPC-Agent-Go가 보여준 Event-driven Runner 설계와 Self-Evolution 루프는 Drewgent의 다음 아키텍처 개선에 참고할 가치가 충분히 있다.

Github 1.5K 스타. Apache 2.0 라이선스. Go 1.21+. trpc-group/trpc-agent-go에서 직접 확인해보시길.

Thanks for reading.