개요

결론부터

• 이 덱의 공통 질문은 “AI가 답은 잘하는데, 왜 실제 일은 여전히 사람이 챙겨야 할까?”다.
• Jev는 프로그램이 바로 쓸 수 있는 작은 판단을, Muse는 개인의 일을 계속 이어 가는 과정을 맡으려 한다.
• Google AX는 많은 에이전트가 일할 실행 환경을 준비하고, 격리·중단·재개를 관리한다.
• 세 주제는 판단 모델·사용자 제품·실행 플랫폼이라는 서로 다른 문제를 다룬다.

새 모델과 도구가 매주 나온다. 발표 글을 읽은 직후에는 알 것 같다가, 몇 주 뒤 “그게 왜 나왔더라”부터 막힌다. 기능과 수치는 금방 바뀌지만 그 제품이 겨냥한 문제와 핵심 개념은 오래 남는다. 이 덱은 그 부분만 골라 남기는 노트다.

큰 그림: 좋은 답변에서 실제 업무까지

예를 들어 “고객 문의를 처리해 줘”라는 요청을 생각해 보자. 답변 초안을 쓰는 것만으로는 일이 끝나지 않는다. 담당 팀을 정해야 하고, 추가 답변을 기다렸다가 후속 처리해야 하며, 이런 작업 수천 개를 서로 섞이지 않게 실행해야 한다.

남는 문제	이 덱에서 보는 접근	기억할 질문
문장을 받았지만 코드가 바로 쓸 판단 값이 필요하다	Jev — 선택·점수·확률을 돌려주는 모델	“무엇을 선택하고, 애매하면 어떻게 처리할까?”
한 번 답한 뒤에도 기억·추적·후속 행동이 필요하다	Meta Muse — 개인 업무를 이어 가는 에이전트 제품	“누가 다음 단계까지 챙길까?”
실행할 에이전트가 많아지면 환경·자원 관리가 필요하다	Google AX — 에이전트 작업을 운영하는 플랫폼	“각 작업을 어디서 실행하고, 기다릴 때는 어떻게 멈출까?”

이 표는 역할을 이해하기 위한 비교다. Muse가 Jev나 AX를 사용한다는 뜻도, 세 제품을 반드시 함께 써야 한다는 뜻도 아니다. 한 제품을 볼 때 “더 똑똑한 모델인가, 일을 맡기는 제품인가, 실행을 받쳐 주는 플랫폼인가”를 구별하면 기능 이름이 많아져도 자리를 찾을 수 있다.

각 본문은 기존 방식의 불편 → 바꾸려는 방식 → 예제로 보는 핵심 개념 → 맡길 수 있는 범위와 한계로 읽는다. 설치·SDK 사용법·성능 측정·도입 결정은 다루지 않는다. 성능 수치는 벤더의 주장과 직접 확인한 결과를 구분한다.

Jev부터 읽기

구성

1. 모델Jev — 문장을 만들지 않는 결정 모델

   고객 문의로 이해하는 선택·점수·확률 · 판단 뒤의 행동은 코드가 결정

   작은 판단마다 긴 답변을 받아야 할까?

2. 에이전트Meta Muse — 일상 업무를 이어서 수행하는 개인 에이전트

   여행 준비로 이해하는 기억·후속 작업·실행 권한 · 모델과 제품의 차이

   추천을 받은 뒤의 실행과 변경 사항은 누가 챙길까?

3. 플랫폼Google AX — 에이전트를 위한 실행 오케스트레이터

   많은 에이전트의 작업 환경 준비 · Task·Workspace·Model · 파일 복원과 업무 복구의 차이

   작업이 많아지고 대기가 길어지면 실행 환경을 어떻게 관리할까?

다른 덱에 있는 관련 페이지

같은 주제를 사내 Agent 플랫폼 설계 문맥에서 비교한 페이지는 그 덱에 둔다. 이 덱의 페이지가 문제의식과 개념을 맡고, 아래 페이지가 사내 runtime 후보와의 책임 비교를 맡는다.

Google AX — kagent·AgentCore·Temporal과의 책임 비교에이전트 실행 환경을 관리하는 일과, 실패한 업무를 복구하는 일을 나눠 플랫폼 후보를 비교한다.

기준 시점과 확인 범위

이 개요는 각 페이지의 문제의식을 연결한 학습용 지도다. 제품 간 연동을 시험한 결과가 아니며, 버전·공식 근거의 확인일·실행하지 않은 항목은 각 본문의 같은 이름 절에 둔다.