에이전트 데모는 멋진데, 무엇부터 붙여야 할까요?
고객 문의 에이전트를 만든다고 해볼게요. 역할별 에이전트가 조사와 답변을 나눌 수도 있고, 브라우저에서 주문 정보를 찾을 수도 있고, 고객의 선호를 다음 대화까지 기억할 수도 있습니다. 데모에서는 모두 유용해 보이지만 한꺼번에 붙이면 어디서 실패했는지 찾기 어려워져요.
Google이 소개한 Gemini 3 사례도 ADK, Agno, Browser Use, Eigent, Letta, mem0까지 여섯 가지입니다. 다만 같은 과제와 조건으로 성능을 겨룬 비교표는 아닙니다. 각 사례의 업무와 구성 요소가 서로 달라요.
프레임워크 이름보다 업무가 처음 멈추는 지점을 보세요. 결과를 나누고 합치는 오케스트레이션, 웹 화면에서 작업하는 행동, 다음 실행까지 상태를 잇는 기억이라는 세 축으로 읽으면 첫 검증 범위가 선명해집니다.
세 층은 제품 분류가 아니라 실패 진단표입니다
오케스트레이션·행동·기억은 Google이 제시한 공식 제품군이 아니라, 여섯 사례를 실무에 옮기기 위한 진단 축입니다. 하나의 도구가 여러 축에 걸릴 수도 있어요. ADK 사례는 전문 에이전트와 Google Search·Maps·코드 실행을 조합하고, Agno는 멀티 에이전트에 기억·지식·도구를 결합합니다. Eigent도 여러 전문 에이전트를 조율하면서 브라우저에서 Salesforce 작업을 수행합니다.
| 처음 관찰된 실패 | 먼저 볼 축 | 최소 검증 |
|---|---|---|
| 조사·계산·작성 결과가 서로 어긋남 | 오케스트레이션 | 역할 둘과 결과 전달 형식 하나만 정의 |
| 입력·업로드 같은 화면 작업에서 멈춤 | 행동 | 직접 관리하는 테스트 폼 하나만 조작 |
| 다음 대화에서 사용자 조건을 잊음 | 기억 | 비민감 정보 하나를 저장하고 새 대화에서 재조회 |
최근 실패가 결과 통합에서 발생했다면 에이전트 수와 전달 형식을 먼저 줄여 살펴보고, 화면 조작에서 발생했다면 기억 저장소를 추가하기 전에 행동 흐름부터 재현하세요. 세 축은 보안·평가·관찰 가능성·권한 통제를 대신하는 전체 아키텍처가 아니라, 첫 실험의 출발점을 고르는 도구입니다.
Browser Use 예제는 그대로 실행할 실습이 아닙니다
Browser Use 사례는 구조화된 지원자 정보와 PDF를 웹 폼에 입력하고, 신청서를 제출한 뒤 성공 여부까지 확인하는 흐름입니다. 필드 식별, JSON 값 매핑, 파일 업로드, 다단계 폼 처리가 행동 계층에 어떻게 묶이는지 보여줘요.
하지만 저장소 설명의 ‘mock application form’만 보고 안전한 샌드박스라고 판단하면 안 됩니다. 현재 main.py는 고정된 외부 Appcast URL로 이동하며, 작업 지시에는 누락된 선택 항목을 판단하고 제출 버튼을 누른 뒤 성공 화면을 확인하라는 내용이 들어 있습니다.
실제 개인정보로 이 예제를 그대로 실행하지 마세요.
현재 저장소는 JSON을 화면 필드에 연결하고 PDF를 업로드하는 코드 구조를 읽는 자료로만 보는 편이 안전합니다. 실행 검증이 필요하다면 직접 관리하는 로컬·테스트 폼으로 대상 URL을 바꾸고, 외부 제출 지시를 제거한 뒤 입력값과 첨부 파일이 올바르게 표시되는 지점에서 멈추세요.
기억이 필요해도 Letta와 mem0의 출발점은 다릅니다
Letta 사례는 오래 유지되는 페르소나와 사용자별 관계 상태를 관리하는 쪽에 가깝습니다. Letta 공개 저장소에는 Core·Recall·Archival 메모리와 사용자별 동적 메모리 블록이 등장하며, 저장소를 실행하려면 Letta와 Bluesky 설정이 필요합니다.
mem0 MCP는 기존 AI 클라이언트가 호출할 수 있도록 add_memory, search_memories, get_memory, update_memory, delete_memory 같은 기억 작업을 도구로 노출합니다. 두 제품의 동일 조건 비교 결과는 없지만, 필요한 상태의 모양으로 첫 후보를 좁힐 수는 있어요.
선택 질문은 “기억이 필요한가?”보다 구체적이어야 합니다.
기존 클라이언트에 저장·검색 가능한 기억 도구를 연결하려면 mem0의 왕복부터 확인하세요. 에이전트가 페르소나와 사용자별 관계 상태를 지속적으로 관리해야 한다면 Letta 사례의 메모리 구조가 더 가까운 출발점입니다.
첫 실행은 기억 하나의 저장·재조회·삭제로 좁혀보세요
외부 사이트에 행동을 일으키지 않고 연결 성공을 확인하려면 Mem0 MCP의 기억 왕복이 작은 첫 실습이 됩니다. Mem0 Platform 계정, MCP 호환 클라이언트, 삭제 가능한 비민감 테스트 정보를 준비하세요. 빠른 설정 명령인 npx mcp-add 경로를 선택할 때만 Node.js 18 이상이 필요하며, 클라이언트의 수동 설정 경로를 사용하면 요구사항이 달라질 수 있습니다.
- 공식 문서에서 사용하는 클라이언트의 설정 경로를 고릅니다.
npx지원 클라이언트에서는 Mem0 MCP 서버 주소https://mcp.mem0.ai/mcp를mcp-add로 등록합니다. Claude Desktop을 쓴다면Settings > Connectors > Add custom connector에서 같은 주소를 추가하는 수동 경로를 선택할 수 있습니다. - 설정을 저장하고 클라이언트를 재시작합니다.
새 서버가 반영되도록 앱을 완전히 재시작하세요. 첫 도구 호출에서 브라우저 인증이 열리면 사용할 Mem0 계정의 접근을 승인합니다. 클라이언트가 API 키 방식을 요구한다면 공식 형식에 따라 연결하고, 키를 코드나 커밋할 파일에 넣지 마세요. - 기억 도구가 노출됐는지 확인합니다.
클라이언트의 MCP 또는 도구 목록에서 Mem0의 기억 추가·검색 도구를 찾습니다. 도구가 보이지 않으면 서버 주소와 재시작 여부부터 다시 확인하세요. - 삭제 가능한 선호 하나를 저장합니다.
예시 입력으로 “새 프로젝트의 예제 코드는 JavaScript보다 TypeScript를 선호한다고 기억해줘”라고 요청합니다. 이는 연결 확인용 예시일 뿐이며 실제 개인정보나 운영 비밀은 사용하지 않습니다. 호출 내역에서add_memory가 실행됐는지 확인하고, 반환된memory_id또는 Mem0 대시보드의 저장 항목을 기록하세요. - 새 대화에서 저장된 정보를 다시 찾습니다.
현재 대화 문맥만으로 답하지 못하도록 새 대화를 열거나 문맥이 초기화된 세션에서 “새 프로젝트에서 내가 선호하는 언어는 무엇이지?”라고 질문하세요. 호출 내역에서search_memories또는get_memory가 실행됐는지 확인하고, 반환 결과의memory_id나 저장 내용이 앞 단계의 항목과 일치하며 답변에 반영됐는지 살펴봅니다. - 테스트 기억을 삭제합니다.
확인한memory_id를 사용해delete_memory로 지운 뒤 대시보드에서도 사라졌는지 확인합니다.
성공 기준은 답변이 우연히 TypeScript를 맞히는 것이 아닙니다. Mem0 도구 노출, 계정 인증, add_memory 호출과 저장 항목 확인, 새 대화에서 search_memories 또는 get_memory 호출, 반환된 memory_id나 저장 내용의 일치, 답변 반영, 마지막 삭제까지 확인돼야 합니다. 이 왕복은 연결 상태를 검증할 뿐 실제 서비스의 사용자 식별, 접근 권한, 보존 기간과 삭제 정책까지 증명하지는 않습니다.
예제의 모델명은 현재 가이드와 함께 다시 확인하세요
Browser Use와 Letta 예제에는 gemini-3-pro-preview가 남아 있지만, 2026년 9월 7일 기준 최신 공식 모델 가이드의 GA 빠른 시작 모델은 gemini-3.8-flash입니다. 그렇다고 저장소의 모델 문자열만 바꾸면 실행된다고 단정할 수는 없어요.
최신 가이드의 마이그레이션 항목에는 기존 샘플링 매개변수 제거, thinking_level 전환, previous_interaction_id 사용, 함수 호출 형식 점검 등이 포함됩니다. 실제 적용 전에는 선택한 프레임워크의 provider가 gemini-3.8-flash와 해당 API 방식을 지원하는지 확인하고, 입력 형식과 도구 호출 처리도 함께 점검하세요. 이번 조사 자료만으로 Browser Use와 Letta의 현재 지원 여부까지는 확인되지 않았습니다.
