무슨 일이 있었나
구글이 에이전트 오케스트레이터를 오픈소스로 공개했어요. 이름 그대로 여러 AI 에이전트를 한데 묶어서 지휘하는 도구인데요. 요즘 '에이전트'라는 말을 정말 많이 듣죠. 그런데 에이전트 하나를 만드는 것과, 여러 에이전트가 협업해서 큰 일을 해내게 만드는 건 완전히 다른 난이도의 문제거든요. 구글이 이 '협업시키는 층'을 오픈소스로 풀었다는 건, 에이전트 개발의 격전지가 모델 자체에서 '조율'로 옮겨가고 있다는 신호로 볼 수 있어요.
오케스트레이터가 뭐냐면
오케스트라를 떠올려 보세요. 바이올린, 첼로, 트럼펫 연주자가 각자 아무리 잘해도 지휘자가 없으면 합주가 안 되잖아요. 에이전트 오케스트레이터가 딱 그 지휘자 역할이에요.
보통 이런 도구가 맡는 일은 크게 네 가지예요. 첫째, 계획(planning). 사용자가 '이번 분기 매출 데이터 분석해서 보고서 만들어 줘'라고 하면, 이걸 데이터 가져오기, 정제, 분석, 차트 그리기, 문서 작성 같은 하위 작업으로 쪼개요. 둘째, 분배(routing). 각 작업을 가장 잘하는 에이전트나 도구에 넘겨요. 셋째, 상태 관리(state). 어디까지 했는지, 중간 결과가 뭔지, 실패하면 어디서부터 다시 할지 기억해요. 넷째, 실행 제어. 도구 호출을 실제로 수행하고, 권한을 체크하고, 무한 루프에 빠지지 않게 막아요.
이 중에서 특히 어려운 게 상태 관리와 실행 제어예요. LLM은 기본적으로 '한 번 호출하면 답 하나'를 주는 함수에 가까운데, 에이전트는 몇 분, 몇 시간씩 돌면서 수십 번 도구를 호출하거든요. 중간에 API가 죽거나 모델이 엉뚱한 판단을 하면 처음부터 다시 해야 하는 상황이 생겨요. 그래서 오케스트레이터는 각 단계를 체크포인트로 저장하고, 실패한 지점에서 재개하는 기능을 핵심으로 갖춰요. 이걸 내구성 있는 실행(durable execution)이라고 부르는데, Temporal 같은 워크플로 엔진이 오래전부터 하던 일을 에이전트 세계로 가져온 거라고 보면 돼요.
구글의 기존 스택과 어떻게 맞물리나
구글은 이미 에이전트 관련 조각을 여러 개 갖고 있어요. 2025년에 공개한 ADK(Agent Development Kit)는 에이전트 하나하나를 만드는 프레임워크고, A2A(Agent2Agent) 프로토콜은 서로 다른 회사가 만든 에이전트끼리 대화하는 표준이에요. 여기에 Anthropic이 시작한 MCP(Model Context Protocol)는 에이전트가 외부 도구에 접속하는 규격이고요.
비유하자면 ADK는 '연주자를 키우는 학교', A2A는 '연주자끼리 쓰는 악보 표기법', MCP는 '악기 규격'이에요. 그런데 정작 무대 위에서 곡 전체를 지휘하는 '지휘자'는 각자 알아서 만들어야 했거든요. 이번 오케스트레이터는 그 빈자리를 채우는 조각이에요. 실제로 어떤 프로토콜을 지원하고, 어떤 언어로 짜여 있고, 구글 클라우드에 얼마나 종속적인지는 저장소를 직접 열어서 확인해 보셔야 해요. '오픈'이라는 이름이 붙었더라도 배포 환경이 특정 클라우드에 묶여 있는 경우가 종종 있으니까요.
경쟁 구도는 어떤가
이 영역은 이미 붐비고 있어요. LangChain 진영의 LangGraph는 그래프 형태로 에이전트 흐름을 정의하고 체크포인트를 지원해서 사실상 표준처럼 쓰이고 있고요. 마이크로소프트는 AutoGen과 Semantic Kernel을 합쳐서 Microsoft Agent Framework로 정리했어요. OpenAI는 Agents SDK로 핸드오프(handoff)라는 개념, 그러니까 에이전트가 다른 에이전트에게 대화를 넘기는 패턴을 밀고 있고, CrewAI는 역할 기반으로 에이전트 팀을 짜는 접근이에요.
각각 철학이 조금씩 달라요. LangGraph는 '개발자가 흐름을 명시적으로 그려라'에 가깝고, OpenAI Agents SDK는 '모델이 알아서 넘기게 하라'에 가까워요. 구글이 어느 쪽 철학을 택했는지가 이 프로젝트의 성격을 결정할 거예요. 구글이 A2A를 만든 회사라는 점을 생각하면, 여러 회사의 에이전트를 섞어 쓰는 시나리오에 강점이 있을 가능성이 높다고 봐요.
한국 개발자에게 주는 시사점
당장 프로덕션에 넣을 도구를 고르는 상황이라면, 새 프로젝트를 1순위로 두기보다는 '우리가 이미 쓰는 스택과 얼마나 잘 붙는가'를 먼저 보세요. 오케스트레이터는 한번 정하면 갈아타기 어려운 층이거든요. 그래도 배워둘 가치는 충분해요. 어떤 프레임워크를 쓰든 계획, 분배, 상태, 실행 제어라는 네 가지 개념은 똑같이 등장하니까, 이 프로젝트의 구조를 뜯어보면서 개념을 익히면 다른 도구로 옮겨가도 그대로 써먹을 수 있어요.
특히 국내 기업에서 많이 하는 '사내 문서 검색 + 결재 시스템 연동 + 알림' 같은 업무 자동화는 에이전트 하나로는 안 되고 여러 개를 엮어야 하는 전형적인 케이스라, 이런 오케스트레이터가 정확히 겨냥하는 시나리오예요.
정리
한 줄 요약: 에이전트 경쟁의 중심이 '똑똑한 모델'에서 '여러 에이전트를 안정적으로 굴리는 지휘 체계'로 옮겨가고 있고, 구글이 그 층을 오픈소스로 내놨어요.
여러분은 지금 에이전트 흐름을 어떻게 관리하고 계세요? LangGraph처럼 직접 그래프를 그리는 방식이 편한지, 아니면 모델에게 판단을 맡기는 방식이 편한지 경험을 나눠주세요.
🔗 출처: Hacker News