Subscribe
Share
Share
Embed
Go 팀은 LLM 앱이 결국 클라우드 서비스라서 Go가 맞는다고 말하지만, 2025 Go 개발자 설문에서는 AI 기능을 만드는 응답자가 오히려 줄었습니다. RAG 데모, Ollama·Weaviate·Milvus 같은 Go 기반 인프라, MCP Go SDK와 Genkit Go의 1.0 호환성 약속, ByteDance Eino, 설문의 한계와 '14포인트' 수치를 살펴보고 Go가 AI 스택의 어느 층에 서야 하는지 따져 봅니다. 근거 상당수가 Google 계열 자료와 ByteDance 자기 보고라 독립 증거가 아니라는 점도 밝혀 둡니다.
kalee 가 공부하고자 하는 내용들을 두서없이 업로드하는 팟캐스트
진행자: 안녕하세요. 오늘은 Go 얘기를 해 볼게요. 질문은 하나예요. Go는 AI 인프라의 언어인가.
전문가: 네. 이 질문이 재미있는 건 공식 서사와 설문 숫자가 서로 다른 방향을 가리키기 때문이에요.
진행자: 어떻게 엇갈리는데요?
전문가: 한쪽에는 Go 팀의 블로그 글이 있어요. 2024년 9월에 Eli Bendersky가 쓴 글인데, LLM 기반 애플리케이션은 다른 현대 클라우드 네이티브 애플리케이션과 아주 비슷하다고 말해요. 그러니 Go가 잘 맞는다는 거죠.
전문가: 다른 쪽에는 2026년 1월에 나온 2025 Go 개발자 설문 결과가 있어요. 응답자의 78%가 자기가 일하는 Go 소프트웨어에 AI 기능을 만들고 있지 않다고 답했어요. 그리고 Go 팀은 이걸 2024년보다 AI 기능 구축에서 멀어진 변화로 읽었어요.
진행자: 공식 블로그는 Go가 딱 맞는다고 하는데, 정작 Go 개발자들은 AI 기능을 덜 만들고 있다. 그게 오늘의 엇갈림이네요.
전문가: 맞아요. 타이밍도 묘해요. Google의 AI 프레임워크 Genkit의 Go 버전 1.0이 2025년 9월 10일에, 공식 MCP Go SDK v1.0.0이 9월 30일에 나왔어요. 그런데 이 설문은 9월 9일부터 30일까지 진행됐거든요.
진행자: 안정 버전 두 개가 나오던 바로 그 기간에 설문이 돌았다는 거군요.
전문가: 네. 그래서 오늘은 두 사실이 정말 충돌하는지, 아니면 서로 다른 걸 재고 있는지를 따져 보고, 결국 Go가 AI 스택의 어느 층에 서는 게 맞는지까지 가 볼게요.
진행자: 시작하기 전에 짚고 갈 게 있죠. 오늘 근거로 쓰는 자료들의 성격이요.
전문가: 네, 이건 먼저 밝혀 둘게요. Go 블로그 글 두 편은 Go 팀, 즉 Google 쪽 사람들이 쓴 글이에요. MCP Go SDK는 Google과 협업해 유지된다고 저장소에 적혀 있고, Genkit은 Google이 만든 프레임워크예요.
전문가: 그리고 ByteDance의 Eino라는 프레임워크 얘기도 할 텐데, 그 근거는 ByteDance가 직접 쓴 문서예요.
전문가: 그러니까 자료가 여러 개라고 해서 서로 독립된 증거가 쌓이는 건 아니에요. Go를 밀어 주는 쪽의 이야기, 자기 프레임워크를 소개하는 쪽의 이야기로 들어 주시면 좋겠어요.
진행자: 그리고 뒤에서 분업 논쟁을 다룰 때 인용할 DEV Community 글은 개인 의견 글이고요.
전문가: 맞아요. 그 글에 나오는 지연 시간이나 메모리 수치에는 출처가 붙어 있지 않아서 오늘은 쓰지 않을게요.
진행자: 그럼 용어부터 정리하고 갈게요. LLM은 다들 아실 테지만 한 번만 풀어 주세요.
전문가: Large Language Model, 대규모 언어 모델이에요. 오늘은 모델 자체보다 그 모델을 불러 쓰는 애플리케이션 쪽 얘기가 중심이에요.
진행자: RAG도 계속 나올 텐데요.
전문가: Retrieval-Augmented Generation, 검색 증강 생성이에요. 질문과 관련된 문서를 먼저 찾고, 그 문서를 문맥으로 같이 넣어서 LLM에게 묻는 방식이에요.
진행자: MCP는요?
전문가: Model Context Protocol, 모델 컨텍스트 프로토콜이에요. 서버와 클라이언트로 나뉘어 동작하는 규약인데, 오늘은 이걸 Go로 구현하는 공식 SDK, 그러니까 Software Development Kit가 나와요.
진행자: RPC랑 DAG도 나오죠.
전문가: RPC는 Remote Procedure Call, 원격 프로시저 호출이고요. DAG는 Directed Acyclic Graph, 방향 비순환 그래프예요. 화살표가 한쪽으로만 흐르고 다시 돌아오는 고리가 없는 그래프라고 생각하시면 돼요.
진행자: 마지막으로 ADK랑 ML이요.
전문가: ADK는 Agent Development Kit, Google의 에이전트 개발 키트고요. ML은 Machine Learning, 기계 학습이에요. 설문 문항에 나와요.
진행자: 좋아요. 그럼 본론으로 가죠. Go 팀의 논증부터요. LLM 앱이 왜 클라우드 서비스라는 거예요?
전문가: 글의 관점은 이래요. LLM 앱이 하는 일은 모델을 직접 계산하는 게 아니라, 모델 API, 임베딩, 벡터 DB 같은 여러 네트워크 서비스를 엮는 일이라는 거예요.
전문가: 그래서 LLM 앱에 필요한 건 REST와 RPC 지원, 동시성, 성능인데, 글은 이게 마침 Go가 뛰어난 영역이라고 말해요.
진행자: 동시성은 구체적으로 어떤 얘기예요?
전문가: 글에 나오는 설명은 간단해요. Go의 HTTP 핸들러는 요청마다 자기 goroutine에서 돌아요. 그래서 한 핸들러가 원격 서비스 응답을 기다리고 있어도 다른 요청을 막지 않는다는 거예요.
전문가: 비유하자면 주방에 주문을 넣고 기다리는 직원이 테이블마다 따로 있는 식당이에요. 한 테이블 음식이 늦게 나와도 다른 테이블 주문은 계속 받죠.
진행자: LLM 앱은 결국 남의 서비스 응답을 기다리는 일이 많으니까, 그 기다림을 잘 다루는 게 핵심이라는 거네요.
전문가: 그게 논증의 뼈대예요. 그리고 글은 이걸 보여 주려고 RAG 서버 데모를 만들어요.
진행자: 어떤 서버예요?
전문가: 엔드포인트가 두 개인 HTTP 서버예요. /add/는 문서를 받아서 임베딩을 계산하고 벡터 DB에 넣어요. /query/는 질문을 임베딩해서 비슷한 문서를 찾고, 그 문서를 문맥으로 붙여 LLM에게 물어요.
전문가: 모델과 임베딩은 Google Gemini API를 쓰고, 벡터 DB는 로컬에서 띄운 Weaviate를 써요.
진행자: 같은 서버를 세 가지 방식으로 만들었다고요?
전문가: 네. 첫째는 Gemini와 Weaviate의 Go 클라이언트 라이브러리를 직접 쓰는 방식이에요.
전문가: 둘째는 LangChainGo예요. Python 프레임워크 LangChain의 Go 대응물인데, 여러 모델 공급자와 벡터 DB에 공통 인터페이스를 줘요. 그래서 코드가 조금 짧아지고 공급자를 바꾸기가 쉬워져요.
진행자: 공급자를 쉽게 바꾼다는 건 무조건 장점이에요?
전문가: 조건이 붙어요. 글에서도 LangChainGo가 지원하는 벡터 DB로만 바꿀 수 있다고 해요. 공통 인터페이스는 그 프레임워크가 품고 있는 범위 안에서만 공통인 거죠.
전문가: 셋째는 Google의 오픈소스 프레임워크 Genkit for Go예요. 이것도 플러그인 형태의 공통 인터페이스를 쓰는데, 운영 기능 쪽에 초점을 둬요. 다만 데모에서는 배포 부분을 구현하지 않았어요.
진행자: 그럼 이 데모가 Go가 LLM 앱에서 빠르다는 걸 보여 준 거예요?
전문가: 아니요, 그건 아니에요. 이 글은 구현 예시이지 벤치마크가 아니에요. 성능을 측정한 숫자는 없어요.
전문가: 그러니까 이 글이 보여 주는 건 Go로 이런 서버를 자연스럽게 짤 수 있다는 거고, Go가 다른 언어보다 낫다는 측정 결과는 아니에요.
진행자: 그 구분은 기억해 둘게요. 글 끝에는 Go로 만든 AI 인프라 프로젝트도 예로 든다고 하셨죠.
전문가: 네. Ollama, LocalAI, Weaviate, Milvus를 LLM 생태계의 구성 요소를 구현한 프로젝트로 들면서, Go의 성능과 신뢰성 덕분에 이런 일에 자연스러운 선택이라고 말해요.
전문가: 그런데 꼼꼼히 보면, 글이 Go로 구현됐다고 명시한 건 Weaviate 하나예요. 나머지는 예시 목록으로만 나와요.
진행자: 그래서 저장소를 직접 확인해 보셨다고요.
전문가: GitHub 언어 통계로 봤어요. 네 저장소 모두 주 언어는 Go예요. Weaviate는 코드 대부분이 Go고요.
전문가: 다만 Ollama에는 C 코드가 상당량 들어 있고 C++ 코드도 일부 있어요. Milvus는 C++와 Python 비중도 커요.
진행자: 연산이 무거운 부분은 C나 C++로 짰다는 얘기인가요?
전문가: 그렇게 짐작하기 쉬운데, 저희가 확인한 건 언어 통계까지예요. 어느 부분이 어느 언어인지는 이번에 들여다보지 않았어요. 그러니 여기서는 Go만으로 된 프로젝트는 아니다, 거기까지만 말할게요.
진행자: 이 네 프로젝트의 공통점은 뭐예요?
전문가: 모두 모델을 학습시키는 쪽이 아니에요. Ollama와 LocalAI는 모델을 띄워서 돌리는 쪽이고, Weaviate와 Milvus는 벡터를 저장하고 검색하는 데이터베이스예요. 인프라 층이죠.
진행자: 이게 오늘 질문의 첫 번째 힌트 같네요. Go가 서 있는 자리가 모델 안쪽이 아니라 모델 주변이라는.
전문가: 네, 그 표현이 좋아요. 뒤에서 다시 꺼낼게요.
진행자: 이번엔 Go로 AI 앱을 만드는 도구 쪽을 보죠. 공식 MCP Go SDK부터요.
전문가: modelcontextprotocol 조직 아래 있는 go-sdk 저장소예요. MCP 서버와 클라이언트를 만드는 공식 Go SDK이고, 앞서 말씀드린 대로 Google과 협업해 유지된다고 적혀 있어요.
전문가: 패키지 구성을 보면 성격이 보여요. 클라이언트와 서버 API를 담은 mcp 패키지, 전송 계층을 직접 구현하는 사람을 위한 jsonrpc 패키지, 그리고 OAuth를 지원하는 auth와 그 확장인 oauthex가 있어요.
진행자: 이 SDK에서 오늘 주목하는 건 v1 호환성 보장이죠?
전문가: 맞아요. v1.0.0이 2025년 9월 30일에 나왔는데, 릴리스 노트가 스스로를 안정 릴리스라고 불러요. 기능은 직전 v0.8.0과 같고, 달라진 건 호환성 약속을 공식화했다는 점이에요.
전문가: 약속 내용은 이래요. 앞으로 API를 깨는 변경은 하지 않는다. 개선이 필요하면 기존 것에 폐기 표시를 하고 새 함수를 추가하는 식으로 하위 호환을 지킨다.
진행자: Go 쪽 사람들한테는 익숙한 문화네요.
전문가: 네. 흥미로운 건 같은 노트에 솔직한 문장도 있다는 거예요. MCP 스펙이 바뀌는 속도를 보면 언젠가 v2로 갈 가능성이 높지만, 최대한 늦추겠다고요.
진행자: 스펙은 실제로 계속 바뀌었나요?
전문가: README의 대응표를 보면 그래요. 지금 v1.7.0 이상은 MCP 스펙 2026-07-28을 지원하고, 그 전의 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05 스펙도 SDK 버전별로 정리돼 있어요.
전문가: 그리고 2026-07-28 스펙에서 roots, sampling, logging 기능이 폐기 예정이 됐는데, SDK는 이 기능들을 적어도 12개월은 계속 지원하겠다고 밝혀요.
진행자: 스펙이 움직여도 SDK 사용자를 바로 깨뜨리지는 않겠다는 거네요. 성숙도 근거는 뭐가 있어요?
전문가: v1.0.0 노트 기준으로, 보고된 버그 61건 중 60건을 고쳤고 58명의 기여자에게서 PR을 받았다고 했어요. 클라이언트 쪽 OAuth만 빼면 당시 스펙 2025-06-18의 거의 모든 동작을 구현할 수 있다고도 했고요.
진행자: 실제로 쓰는 곳은요?
전문가: 노트에는 Google 내부와 더 넓은 Go 커뮤니티에서 실제로 쓰이고 있다고 적혀 있어요. 다만 대부분은 stdio, 그러니까 표준 입출력 같은 단순한 전송 방식을 쓰는 것으로 보이고, 대규모 분산 서버에서는 버그 보고가 더 나올 거라고 스스로 예상했어요.
진행자: 이건 어떻게 읽어야 해요?
전문가: SDK가 있고 꽤 성숙했다는 근거로는 충분해요. 그런데 운영에서 얼마나 널리 쓰이는지를 보여 주는 독립 자료는 아니에요. 저장소를 유지하는 쪽의 자기 설명이니까요.
진행자: 다음은 Genkit for Go요.
전문가: Genkit은 Google의 오픈소스 AI 앱 프레임워크예요. TypeScript, Go, Python, Dart를 지원하고, 문서에는 Google이 만들고 운영에서 쓴다고 적혀 있어요. Go 버전은 Go 1.25 이상이 필요하고요.
전문가: Go 쪽에서 눈에 띄는 건 flow라는 개념이에요. flow는 평범한 Go 함수인데, 선언한 입력과 출력 타입으로 Genkit이 검증하고 추적해서 개발자 UI와 HTTP로 노출해 줘요.
전문가: 테스트 쪽 설명도 있어요. 가짜 모델로 flow를 프로세스 안에서 돌릴 수 있어서 CI에 API 키가 필요 없다고 해요.
진행자: 1.0은 언제 나왔어요?
전문가: 2025년 9월 10일 Google Developers Blog에서 첫 안정 버전으로 발표됐어요. 약속 방식이 Go 자체의 호환성 정책을 닮았어요. Genkit 1점대로 쓴 프로그램은 1.1, 1.2 같은 이후 릴리스에서도 고치지 않고 컴파일되고 실행된다는 거예요.
전문가: 주요 기능으로는 Go 구조체와 JSON 스키마 검증으로 만드는 타입 안전 flow, Google AI, Vertex AI, OpenAI, Anthropic, Ollama를 하나로 묶는 모델 인터페이스, 그리고 tool 호출, RAG, 멀티모달을 들어요.
진행자: 발표문에 운영 준비 완료라는 말도 있죠.
전문가: 있어요. 그런데 그건 발표한 쪽의 주장이에요. 그 글에 독립 벤치마크나 고객 사례는 없어요.
진행자: MCP SDK와 Genkit 둘 다 1.0을 내면서 깨뜨리지 않겠다는 약속을 앞세운 거네요.
전문가: 네. Go 개발자들이 가장 중요하게 여기는 가치로 말을 건 셈이죠. 안정성 약속이요.
진행자: LangChainGo는 데모에서 나왔는데, 이건 누가 만드는 거예요?
전문가: tmc라는 개인 계정 아래 있는 커뮤니티 프로젝트예요. 스스로를 LangChain for Go, Go로 LLM 프로그램을 쓰는 가장 쉬운 방법이라고 소개해요. Go 팀 데모에 쓰였다고 해서 Google 프로젝트인 건 아니에요.
진행자: 그리고 ByteDance의 Eino요. 이건 출처가 ByteDance 자체 문서라는 걸 다시 한번 짚고 갈게요.
전문가: 네. Eino는 ByteDance가 공개한 LLM 애플리케이션 개발용 Go 프레임워크예요. 문서에서는 Go-first, Go 우선 LLM 프레임워크라고 불러요.
전문가: 오픈소스 공지에 따르면 ByteDance 내부에서 반년 넘게 쓰면서 다듬었고, 내부 LLM 앱의 선호 풀코드 개발 프레임워크가 됐다고 해요. Doubao, TikTok, Coze 같은 사업 라인과 수백 개 서비스가 이미 통합됐다고 적었어요.
진행자: 수백 개면 꽤 큰 숫자인데요.
전문가: 그런데 정확한 수가 아니고, 밖에서 검증할 방법이 없는 자기 보고예요. 문서 어디에도 사용자 수나 요청량 같은 규모나 성능 수치는 없어요.
진행자: 왜 Go를 골랐다고 해요?
전문가: 강한 타입이요. 공지는 LangChain 같은 주류 프레임워크가 Python 기반이라 동적 언어의 약한 타입 검사와 높은 장기 유지보수 비용을 물려받는다고 보고, 강한 타입 언어인 Go로 읽기 쉽고 유지보수하기 쉬운 코드를 얻는다고 말해요.
전문가: 실제로 그래프를 컴파일할 때 이웃한 노드끼리 타입이 맞는지 검사한다고 설명해요.
진행자: 구조는 어떻게 돼 있어요?
전문가: 부품이 있고, 그 부품을 엮는 방식이 있어요. 부품은 ChatModel, Tool, Retriever, ChatTemplate, Document Loader와 Transformer, Indexer, Embedding, 그리고 사용자 함수를 넣는 Lambda예요.
전문가: 엮는 방식은 세 가지예요. 앞으로만 흐르는 DAG인 Chain, 순환도 허용하는 방향 그래프인 Graph, 그리고 필드 매핑 기능이 있는 DAG인 Workflow예요.
전문가: LLM 출력이 스트리밍이라는 점도 프레임워크가 맡아요. 스트림을 이어 붙이거나, 단일 값을 스트림으로 감싸거나, 스트림을 합치고 복사하는 일을 자동으로 처리한다고 해요.
전문가: ChatModel 공식 구현으로는 OpenAI, Claude, Gemini, Ark, Ollama가 있고, 콜백으로 노드의 시작과 끝을 잡아서 로깅, 추적, 지표를 남겨요. 예제에서는 APMPlus와 Langfuse 연동을 보여 줘요.
전문가: 예제 앱 Eino Assistant는 지식 베이스를 검색하고 tool을 부르는 RAG 에이전트인데, 벡터 저장소로 Redis Stack을, 모델로 Volcengine Ark의 Doubao를 써요.
진행자: 들어 보면 이것도 결국 모델 주변을 엮는 프레임워크네요.
전문가: 네. 부품 목록에 모델 자체는 없어요. 모델은 ChatModel 인터페이스 뒤에 있는 OpenAI나 Gemini 같은 외부 구현이고, Eino가 하는 일은 검색, 템플릿, tool, 스트림을 엮는 거예요. Go 팀 논증과 같은 그림이죠.
진행자: 이제 반대편 숫자로 가 보죠. 2025 Go 개발자 설문이요.
전문가: Todd Kulesza가 Go 팀을 대표해서 2026년 1월 21일에 결과를 발표했어요. 조사는 2025년 9월 9일부터 30일까지였고요.
전문가: 응답은 7,070건이 들어왔고, 봇과 품질이 아주 낮은 응답을 걸러서 5,379건을 분석했어요.
진행자: 응답자는 어떻게 모았어요?
전문가: Go 블로그, Bluesky, Mastodon, Reddit, X 같은 소셜 미디어, 그리고 VS Code와 GoLand 사용자에게 제품 안에서 무작위로 띄운 초대예요.
전문가: 참고로 Go 자체에 대한 만족도는 91%예요. 가장 높은 단계인 매우 만족이 62%고, 2019년부터 안정적이에요. Go를 쓰는 사람들은 여전히 Go를 좋아한다는 거죠.
진행자: 그럼 AI 쪽 숫자는요?
전문가: 응답자의 78%가 자기가 일하는 Go 소프트웨어에 AI 기능을 만들고 있지 않다고 답했어요. 66%는 자기 소프트웨어가 AI 기능을 전혀 쓰지 않는다고 했고요.
전문가: 2024년에는 59%가 AI 기능 작업에 관여하지 않았고, 39%가 어느 정도 관여했어요. Go 팀은 이걸 두고 AI 시스템을 만드는 쪽에서 14포인트 멀어진 변화라고 썼어요.
진행자: 14포인트요. 그런데 이 숫자에 대해서 짚을 게 있다고 하셨죠.
전문가: 네, 조심스럽게 말씀드릴게요. 글에 나온 숫자만으로 빼 보면, 관여하지 않는다는 응답은 59%에서 78%로 19포인트 늘었어요. 어느 정도 관여한다는 응답은 39%였는데, 올해 값을 78%의 나머지인 22%로 놓으면 17포인트 줄어요.
진행자: 어느 쪽으로 계산해도 14가 바로 나오지는 않네요.
전문가: 맞아요. 그런데 이걸 Go 팀의 계산 실수라고 단정하면 안 돼요. 글은 14를 어떻게 계산했는지 보여 주지 않아요. 두 해의 응답을 설명하는 표현도 2024년은 AI 기능 작업에 관여하지 않음, 2025년은 AI 기능을 만들고 있지 않음으로 서로 달라요.
전문가: 저희가 모르는 기준으로 계산했을 수도 있어요. 그래서 정확한 표현은 공개된 숫자로는 14를 재현할 수 없다, 여기까지예요. 다만 2024년보다 AI 기능을 만든다는 응답이 줄었다는 방향은 어느 계산으로 봐도 같아요.
진행자: 다른 AI 관련 수치도 있어요?
전문가: 11%가 ML 모델, 도구, 에이전트를 다룬다고 답했어요. 다만 이 항목은 올해 범위를 넓힌 범주예요.
전문가: AI 기능을 만드는 응답자 사이에서는 기존 콘텐츠 요약이 45%로 가장 흔했고, 분류, 생성, 해결책 찾기, 챗봇, 소프트웨어 개발은 각각 28에서 33% 사이였어요.
진행자: 그런데 요즘 Go 개발자들도 AI 코딩 도구는 많이 쓰잖아요. 그 숫자랑 헷갈리면 안 되겠네요.
전문가: 네, 둘은 다른 질문이에요. 같은 설문에서 AI 개발 도구를 매일 쓴다는 응답은 53%였어요. 그러니까 AI로 Go 코드를 짜는 사람은 많아도, Go 코드 안에 AI 기능을 넣는 사람은 적은 거예요. 78%는 뒤쪽에 대한 숫자예요.
진행자: 이 설문의 한계도 정리해 주세요.
전문가: 네 가지예요. 첫째, 2024년과 조건이 같지 않아요. Go 팀은 무엇을 만드느냐는 선택지 목록을 2024년보다 손봤다고 밝혔고, AI 도구 사용 비교에 대해서는 방법론이 바뀌어 동일 조건 비교가 아니라고 직접 적었어요.
전문가: 둘째, 표본이에요. 공개 초대로 모은 응답이라 Go 개발자 전체를 대표한다고 보기는 어려워요. 이건 모집 방식에서 나온 저희 해석이고, 글이 대표성을 따로 논하지는 않아요.
전문가: 셋째, 원자료는 공유에 동의한 응답자, 그러니까 전체의 82% 분만 공개할 계획이라서 글에 나온 수치와 조금 다를 수 있다고 글이 직접 밝혔어요.
전문가: 넷째가 오늘 주제에서 제일 중요해요. 이 설문은 Go 개발자가 자기 소프트웨어에 AI 기능을 넣는지를 물어요. Ollama나 Milvus 같은 AI 인프라를 Go로 만드는 사람이 몇 명인지는 따로 재지 않아요. 가장 가까운 게 아까 말한 11%의 ML 모델, 도구, 에이전트 범주인데, 이것도 AI 인프라를 만드는 사람만 떼어 낸 숫자는 아니에요.
진행자: Python이랑 같이 쓰는 경우는요?
전문가: 그것도 빠져 있어요. Go와 Python 같은 다른 언어를 AI 작업에 함께 쓰는 비율은 묻지도 보고하지도 않아요. 모델 쪽은 Python 서비스가 맡고 Go 서비스는 그걸 부르기만 하는 팀이 이 설문에 어떻게 답했을지는 알 수 없어요.
진행자: 여기서 자연스럽게 분업 얘기가 나오죠. 모델 층은 Python, 인프라와 오케스트레이션 층은 Go.
전문가: 이 논쟁을 정리한 글로 DEV Community에 Valerii Vainkop이 2026년 3월 5일에 쓴 Go for AI Agents가 있어요. Google이 ADK의 Go 포트인 adk-go를 공개한 걸 계기로 쓴 글이에요. 다시 말씀드리지만 개인 의견 글이에요.
전문가: 첫 번째 찬성 논거가 타입 있는 tool 입력이에요. tool 입력을 타입 있는 구조체로 받으면, 정수 자리에 문자열이 오는 식의 잘못된 LLM 출력이 역직렬화 단계에서 실패해요. tool 로직이 돌기 전에, 부수 효과가 생기기 전에 멈추는 거죠.
진행자: 그게 왜 에이전트에서 특히 중요해요?
전문가: 글은 상태와 기억을 가진 장시간 워크플로를 예로 들어요. 몇 시간째 도는 에이전트가 중간에 실패하면 이미 호출한 tool과 이미 생긴 부수 효과가 남아 있어서, 처음부터 다시 돌리면 같은 행동이 반복될 수 있다는 거예요.
전문가: 두 번째 논거는 동시성이에요. 메트릭 조회, Kubernetes API 호출, 최근 알림 조회 같은 tool 호출을 순서대로가 아니라 goroutine으로 한꺼번에 팬아웃하기 쉽다는 거예요.
전문가: 세 번째로는 메모리 이야기를 해요. 같은 수의 동시 작업을 돌릴 때 Python 비동기 워커와 Go 서비스는 자원 사용 모습이 크게 다르고, GPU 예산이 따로 없는 팀에게는 이게 인프라 비용 문제라고 주장해요. 이 부분은 측정 근거가 없으니 주장으로만 들어 주세요.
진행자: 반론도 그 글이 직접 인정한다고요.
전문가: 네, 이 글을 고른 이유예요. 첫째, Python 생태계가 훨씬 크고, LLM 공급자 SDK, 평가 도구, 각종 통합이 거의 다 Python에 먼저 나온다.
전문가: 둘째, 구조화된 출력 검증은 Python의 Pydantic이 개발자 편의에서 앞서고, Go의 타입 구조체 방식은 같은 수준으로 검증하려면 보일러플레이트가 더 든다.
전문가: 셋째, 팀이 이미 Python에 익숙하면 전환 비용이 실제로 있다. 그리고 tool 구성이 한 달 뒤에 어떻게 될지 모르는 탐색 단계 에이전트에는 Python의 빠른 반복이 맞다.
전문가: 넷째가 제일 중요해요. 타입은 추론 오류를 막지 못한다. LLM이 어떤 tool을, 어떤 순서로, 무슨 의도로 부를지는 여전히 실행 시점의 문제라는 거예요.
진행자: 타입은 인자 모양을 지켜 주지만, 판단이 맞는지는 지켜 주지 않는다.
전문가: 정확해요. 글도 에이전트 신뢰성에서 어려운 건 인자 타입이 아니라 추론 품질이라고 말해요.
진행자: 그럼 글의 결론은요?
전문가: 도구 세트가 고정된 작은 운영 에이전트, 예를 들어 인프라 모니터링이나 장애 분류, 사내 자동화라면 Go를 진지하게 검토하겠다. 반대로 탐색적인 에이전트나 LangChain 생태계와 폭넓게 붙어야 하는 일이라면 여전히 Python이 빠른 길이다. 이렇게 갈라요.
전문가: 같은 타입 논거를 ByteDance도 Eino의 Go 선택 이유로 들었죠. 그런데 두 출처 모두 측정 근거 없이 주장만 해요. 같은 말을 하는 출처가 둘이라고 해서 측정이 되는 건 아니에요.
진행자: 이제 처음 질문으로 돌아가 볼게요. 공식 서사와 설문, 정말 충돌하는 건가요?
전문가: 제 해석으로는 두 사실이 서로 다른 걸 재고 있어요. 블로그와 SDK는 Go로 만들 수 있는 길을 보여 주고, 설문은 지금 응답자들이 실제로 하는 일을 보여 줘요.
전문가: 그리고 Ollama나 Milvus 같은 AI 인프라를 Go로 만드는 소수와, 일반 서비스를 만드는 Go 개발자 다수는 서로 다른 집단일 수 있어요. 설문의 78%는 주로 뒤쪽 집단의 모습일 가능성이 있고요.
진행자: 그렇다고 설문이 틀렸고 사실은 Go가 AI에서 이기고 있다, 이런 얘기도 아니죠.
전문가: 그건 아니에요. 2024년보다 AI 기능을 만든다는 응답이 줄었다는 방향은 분명하고, Go 팀도 그렇게 읽었어요. 공식 서사가 그리는 만큼 Go 개발자들이 AI 기능을 만들고 있지는 않다는 건 받아들여야 해요.
진행자: 그럼 Go는 AI 스택의 어느 층에 서야 할까요?
전문가: 오늘 본 근거로만 말하면, 모델 층보다는 그 주변이에요. 모델을 띄워 돌리는 Ollama와 LocalAI, 벡터를 저장하는 Weaviate와 Milvus, 그리고 모델 API와 벡터 DB와 tool을 엮는 오케스트레이션 층이요.
전문가: 다만 조건이 있어요. 인프라 프로젝트에도 C나 C++ 코드가 함께 들어 있었고, 오케스트레이션 층에서도 Python 생태계가 먼저 움직인다는 반론이 있었죠. 모델은 Python, 나머지는 전부 Go처럼 깔끔하게 나뉘는 그림은 아니에요.
진행자: 실무자는 그럼 뭘 기준으로 고르면 될까요?
전문가: 오늘 근거에서 뽑을 수 있는 질문은 세 가지 정도예요. 도구 세트가 고정돼 있는가, 오래 돌면서 상태를 가지는가, 팀이 이미 Go 서비스를 운영하고 있는가.
전문가: 여기에 그렇다는 답이 많으면 Go를 검토할 만하고, 아직 탐색 중이고 Python 생태계의 통합이 많이 필요하면 Python이 빠른 길이에요. 어느 쪽이든 정답은 프로젝트마다 다시 따져야 해요.
전문가: 그리고 Go를 고르더라도 기대치는 정확히 잡아야 해요. 타입은 tool 인자의 모양을 지켜 줄 뿐, LLM의 판단을 지켜 주지는 않아요.
진행자: 마지막으로 자료 성격도 다시 한번 짚어 주세요.
전문가: 네. Go에 우호적인 근거 대부분은 Google 쪽 글과 Google이 관여한 SDK와 프레임워크 문서였고, Eino 쪽은 ByteDance의 자기 보고였어요. 서로 독립된 증거가 아니에요.
전문가: 반대로 설문은 Go 팀이 낸 자료인데도 AI 기능을 만든다는 응답이 줄었다는 결과를 그대로 실었어요. 그 점은 공정하게 기억해 둘 만해요.
진행자: 정리해 볼게요. 첫째, Go 팀의 논증은 LLM 앱이 결국 네트워크 서비스를 엮는 클라우드 서비스라는 거고, 데모는 그걸 보여 주지만 성능을 측정하지는 않았어요.
진행자: 둘째, 2025 설문에서 78%가 AI 기능을 만들고 있지 않다고 답했고, 2024년보다 줄었어요. 다만 14포인트라는 수치는 공개된 숫자로 재현되지 않고, 비교 조건과 표본에도 한계가 있어요. 무엇보다 이 설문은 AI 인프라를 Go로 만드는 사람을 따로 재지 않아요.
진행자: 셋째, Go가 설 자리는 모델 층보다 서빙, 벡터 저장, 오케스트레이션 같은 주변 층에 가까워요. 그것도 도구 세트가 고정되고 오래 도는 운영 에이전트 같은 조건에서 강점이 있다는 정도고, Go가 이겼다는 얘기는 아니에요.
전문가: 네. 하나만 덧붙이면, 이 엇갈림은 다음 설문에서 다시 볼 만해요. Go와 Python을 함께 쓰는 비율을 묻는 문항이 생긴다면 오늘 질문에 훨씬 직접적인 답이 나올 거예요.
진행자: 오늘 다룬 Go 블로그 글 두 편, MCP Go SDK 저장소와 릴리스 노트, Genkit 문서와 발표문, Eino 문서, 그리고 DEV Community 글은 모두 설명란에 링크해 뒀어요. 들어 주셔서 감사합니다.
전문가: 감사합니다.