메모리 우선 코딩 에이전트, Leta Code

Letta 구독자 3,400명

요약

Leta Code는 세션 기반 방식을 넘어 에이전트가 지속적 메모리를 통해 사용하면서 성능이 개선되는 '메모리 퍼스트' 철학을 구현한 오픈소스 코딩 에이전트입니다. npm 설치부터 API 키 설정, 에이전트 자동 연결·생성, 권한 관리, 메모리 초기화(init)·기억(remember)·고정(pin)·스킬(skill) 명령어 등 다양한 기능을 제공해 협업 효율을 높입니다. 또한 모델에 최적화된 도구 집합(tool set) 자동 전환과 원격 에이전트의 터미널 접근을 지원해 개인 비서부터 전문 코딩 도우미까지 활용 범위가 넓습니다.

주요 키워드

메모리 퍼스트 Stateful Agent 하니스(Harness) 스킬(Skill) 도구 집합(Tool Set) init 명령어 remember 명령어 pin 명령어 YOLO 모드 모델 독립성

하이라이트

🚀 메모리 퍼스트 철학: 반복 세션마다 동일 에이전트를 사용해 지속적 학습과 성능 향상을 이끌어낸다.
🌐 모델 독립적 오픈소스: 특정 모델에 종속되지 않아 원하는 AI 모델과 레버리지가 가능하며 깃허브에서 소스 설치도 자유롭다.
🔑 주요 명령어:init으로 초기 메모리 부트스트랩, remember로 사용자 의도 저장, pin으로 주력 에이전트 고정, skill로 경험을 재사용 가능한 스킬로 변환.
⚡️ 에이전트 대시보드(AD) 통합: REST API로 완전한 서버형 에이전트를 관리하고 웹 UI에서 메시지·메모리·도구 현황을 확인할 수 있다.
📌 권한 시스템: 편집 승인·계획 모드·위험 모드(YOLO)를 전환해 안전하게 에이전트 권한을 제어한다.
✨ 터미널 하니스: link 명령어로 원격 에이전트에 터미널 도구를 연결해 로컬 파일·쉘 작업을 수행하도록 확장 가능하다.
🔄 도구 집합 자동 전환: 모델 변경 시 사전 훈련된 최적 도구 세트를 자동으로 매핑해 일관된 코딩 성능을 보장한다.
🌱 스킬 학습 기능: 에이전트 경험을 스킬 파일로 저장해 새로운 에이전트나 향후 작업에서 재사용할 수 있다.

용어 설명

메모리 퍼스트(Memory-First)

에이전트가 각 세션 간에 지속적 상태(state)를 유지하며 경험을 쌓아 성능이 향상되는 접근 방식.

Stateful Agent

동일 에이전트를 여러 세션에 걸쳐 사용하면서 메모리를 활용해 점진적으로 개선되는 에이전트 모델.

하니스(Harness)

로컬 터미널과 원격 에이전트 사이를 연결해 파일 수정·쉘 명령 같은 도구를 제공하는 실행 환경.

스킬(Skill)

에이전트 경험을 기능 단위로 패키징해 다른 에이전트나 협업자가 재사용 가능한 절차 정보로 저장한 모듈.

도구 집합(Tool Set)

특정 AI 모델에 최적화된 파일 수정·쉘 실행 같은 도구들의 모음으로, 모델 전환 시 자동 매핑되어 일관된 성능을 유지.

Leta Code를 발표하며 메모리 퍼스트 코딩 에이전트의 개념과 오픈소스·모델 독립성을 간략히 소개한다.

[00:02] 레타의 찰스가 레타 코드를 소개합니다. 이는 최초의 메모리 우선 코딩 에이전트로, 완전 오픈소스이며 모델에 구애받지 않습니다.

기존 세션 기반 코딩 에이전트와 달리 동일 에이전트를 반복 사용해 메모리를 쌓고 지속적 개선을 이뤄내는 철학을 설명한다.

[00:20] 메모리 우선 코딩 에이전트의 개념을 설명합니다. 레타 코드는 상태를 유지하는 에이전트 철학을 기반으로 하여, 동일한 에이전트를 더 오래 사용할수록 시간이 지날수록 더 나아집니다.

[00:32] 기존 코딩 에이전트들(클로드 코드, 코드사이, 제미나이 CLI)과의 차이점을 설명합니다. 기존 에이전트들은 세션 기반으로 독립적이며, 세션 간 학습이 제한적입니다.

[00:59] 레타 코드의 핵심 특징을 설명합니다. 완전히 에이전트 기반으로, 여러 세션에서 동일한 에이전트를 사용하며 지속적인 메모리를 가집니다.

[01:37] 전통적인 코딩 에이전트와 레타 코드의 관계를 비교합니다. 전통적인 에이전트는 매번 새로운 계약자를 투입하는 것과 같고, 레타 코드는 시간이 지날수록 학습하는 실제 동료나 후배를 두는 것과 같습니다.

[02:00] 레타 코드 사용 방법을 설명합니다. npm install로 설치하거나 깃허브 저장소에서 소스로 설치할 수 있으며, 원하는 디렉터리에서 letcode를 타이핑하면 시작됩니다.

npm 설치, API 키 발급(OAuth 또는 환경 변수), 자체 호스팅 서버 설정 등 Leta Code 사용 준비 과정을 안내한다.

[02:18] Letta Code의 첫 실행 시 OAuth 인증 과정을 설명합니다. 사용자는 링크를 통한 자동 키 생성이나 수동으로 Letta API 키를 생성하여 환경 변수로 설정할 수 있습니다.

[02:38] 부팅 과정에서 Letta Code는 현재 디렉터리에서 이전에 사용된 에이전트를 스캔하고, 발견되면 가장 최근 에이전트를 자동으로 재개하며, 없으면 새 에이전트를 생성합니다.

디렉토리 내 최근 사용 에이전트를 자동 연결하거나 let new 명령으로 신규 에이전트를 생성하는 방식과 설정 옵션을 설명한다.

[03:07] 사용자는 resume 명령을 통해 마지막 실행 날짜순으로 정렬된 모든 에이전트를 탐색하고 원하는 에이전트로 쉽게 전환할 수 있습니다. 새 에이전트 생성은 letta-new 명령으로 가능합니다.

[03:30] Letta Code는 모델에 구애받지 않아 언제든지 모델을 변경할 수 있으며, 인기 있는 모델들의 기본 세트를 제공하고 Letta와 호환되는 모든 모델을 지원합니다.

편집 승인·계획 읽기 전용·위험 허용(YOLO) 모드를 제공하는 권한 관리 방식을 통해 코드 변경 안전성을 제어한다.

[03:53] Claude Code와 유사한 권한 시스템을 제공합니다. Shift+Tab으로 모든 편집 수락, 계획 읽기 전용 모드, 위험한 YOLO 모든 허용 모드 간 전환이 가능하며, YOLO 모드는 샌드박스 환경에서만 권장됩니다.

[04:32] Letta Code에서 생성된 모든 에이전트는 완전한 Letta 에이전트로서 안정적이고 서버에서 실행되며 완전한 REST API를 통해 주소 지정이 가능합니다.

Leta 서버에 등록된 에이전트를 REST API·웹 UI에서 모니터링하고 대화·메모리·도구 현황을 확인하는 방법을 소개한다.

[04:45] Letta Code 에이전트는 서버에서 실행되어 완전한 REST API를 통해 접근 가능하며, 브라우저의 ADE에서도 볼 수 있습니다. 이는 로컬 컴퓨터뿐만 아니라 다양한 기기에서 에이전트와 소통할 수 있음을 의미합니다.

[05:14] 다른 코딩 에이전트들이 세션 기반인 반면, Letta Code는 메모리 중심적 접근을 취합니다. 새로 생성된 에이전트는 아직 아무것도 학습하지 않았으므로 학습을 시작하는 방법이 필요합니다.

init 명령으로 프로젝트 파일·Git 히스토리를 스캔해 에이전트 메모리를 초기화하고 개인·팀 정보, 성향을 자동 설정하는 절차를 시연한다.

[06:00] 에이전트를 초기화하는 여러 방법이 있습니다. ADE에서 수동으로 프로필을 편집하거나, init 명령어를 사용하여 메모리 초기화 시퀀스를 실행할 수 있습니다.

[06:15] init 명령어는 에이전트가 프로젝트를 살펴보고 가이드된 질문을 통해 자체 메모리 시스템을 부트스트랩할 수 있게 합니다. 이는 에이전트의 학습 과정을 시작하는 매우 효과적인 방법입니다.

에이전트의 실수 수정·절차 정보 저장 등을 위해 remember 명령으로 사용자의 구체적 의도를 메모리에 반영하는 방법을 설명한다.

[06:38] init 실행 시 에이전트는 깊이 있는 연구 세션과 빠른 세션 중 선택을 요청합니다. 빠른 버전은 5-20번의 도구 호출로 신속하게 진행되며, 깊이 있는 연구는 git 히스토리와 로그를 분석하여 사용자의 코딩 선호도에 대한 상세한 프로필을 구축합니다.

[07:09] 에이전트가 코딩 선호도와 팀원 정보를 수집하며, 데모를 위해 표준 설정을 선택합니다.

[07:19] 에이전트는 사용자의 코딩 에이전트 동작 방식과 커뮤니케이션 스타일에 대한 선호도를 질문하며, 중간 정도의 자율성과 간결한 스타일을 선택합니다.

다수 에이전트 중 중요 에이전트를 pin해 즐겨찾기처럼 관리하고, 나중에 쉽게 불러오는 관리 방식을 안내한다.

[07:42] 에이전트는 초기 메모리 시스템 설정을 위해 관련 저장소들을 조사하며, 현재 저장소뿐만 아니라 관련된 다른 저장소들까지 광범위하게 검색할 수 있습니다.

skill 명령으로 에이전트 경험을 스킬 파일로 패키징해 다른 에이전트가 즉시 활용할 수 있는 프로세스를 데모한다.

[08:21] 초기 질문에 답한 후 에이전트가 1-2분 만에 메모리 시스템을 부트스트랩하며, 심화 연구 옵션 선택 시 더 오랜 시간이 소요됩니다.

[08:42] ADE(Agent Development Environment)에서 에이전트의 모든 활동을 확인할 수 있으며, 명령 센터 역할을 합니다.

[08:58] 에이전트가 프로젝트, 휴먼, 페르소나 블록을 초기화했으며, README.md 파일 내용과 사용자 선호도가 각각 해당 블록에 기록되었습니다.

[09:31] 페르소나 블록이 에이전트의 행동 패턴을 설명하는 방식에 대해 설명하며, Q&A에서 지시한 '간결하고 요점만 말하기' 설정이 반영되었음을 확인합니다.

[09:46] init 명령어를 Claude.md보다 강력한 메모리 부트스트래핑 도구로 소개하며, 여러 관련 리포지토리에 대한 공유 컨텍스트를 가진 단일 에이전트 사용의 장점을 설명합니다.

[10:23] remember 명령어의 사용법을 설명합니다. 에이전트가 실수했을 때나 메모리 업데이트가 필요할 때 사용하며, 구체적 지시 없이도 상황을 추론할 수 있다고 설명합니다.

[11:07] 구체적인 선호도 설정 예시를 보여줍니다. 'git add all' 사용 시 실수로 잘못된 파일을 커밋할 위험을 경고하고, 안전을 위해 수동으로 추가하라는 규칙을 에이전트에게 기억시킵니다.

[11:30] init과 remember를 시간이 지남에 따라 에이전트 학습을 최대화하는 강력한 메모리 도구로 정리하고, 작업 후 다른 에이전트들과 구별하기 위한 핀(pin) 기능의 필요성을 설명합니다.

[11:53] 핀닝 기능에 대한 설명으로, 서버에 있는 수많은 에이전트 중에서 사용자가 중요하게 생각하는 것들을 북마크처럼 관리할 수 있다고 소개합니다.

[12:15] 스킬 학습 기능을 소개하며, Letta Code가 Claude Code의 스킬을 지원할 뿐만 아니라 실시간으로 새로운 스킬을 학습할 수 있는 독특한 기능을 가지고 있다고 설명합니다.

[13:00] 스킬의 개념을 설명하며, 여러 에이전트와 인간 사용자가 공유할 수 있는 절차적 정보라고 정의합니다.

[13:15] 실제 데모를 위해 Letta Code를 사용해서 Letta Code 자체에 새로운 기능을 구축하는 과정을 보여주겠다고 말하며, 실제로 회사에서도 Letta Code로 개발을 하고 있다고 소개합니다.

[13:52] 'yolo'라는 새로운 명령어를 만드는 데모를 시작하며, 이것이 Shift+Tab 키보드 단축키를 대체하는 간단한 기능이지만 에이전트가 학습할 내용을 스킬로 변환하는 좋은 예시가 될 것이라고 설명합니다.

[14:15] 에이전트에게 새로운 /yolo 명령어를 추가하도록 지시하고, 작업 완료 후 bun rundev로 테스트하여 yolo 모드가 정상적으로 작동함을 확인했습니다.

[15:18] 구현한 기능이 미래에 다른 사람들도 필요로 할 것이라 예상되어, 스킬 명령어를 사용해 에이전트의 학습 내용을 재사용 가능한 스킬로 변환하기로 결정했습니다.

[15:48] 미래 에이전트들이 새로운 명령어 추가 방법을 처음부터 배우지 않고도 빠르게 작업할 수 있도록 가르치는 스킬 생성을 요청했습니다.

[15:58] 스킬 생성자 스킬이 로드되어 새로운 스킬 생성을 위한 모범 사례를 설명하고 명확한 질문을 통해 올바른 생성을 도와줍니다.

[16:16] 기본 질문에 답변한 후 에이전트가 새로운 add command 스킬을 생성하여 로컬 스킬 디렉토리에 저장했습니다.

[16:39] 에이전트가 CLI 명령어 추가에 대한 체크리스트를 담은 'add command' 스킬 파일을 생성했습니다. 이제 다른 에이전트가 이 리포지토리에서 작업할 때, 새로운 CLI 명령어 추가 요청을 받으면 기존 스킬을 바로 로드하여 활용할 수 있습니다.

[16:58] 실제 예시로 새 디렉토리에 새로운 에이전트를 생성하여 테스트해봅니다. 이 에이전트는 빈 메시지 히스토리를 가지고 있지만, 스킬 블록에는 자동으로 스킬 생성자 스킬과 add command 스킬이 포함되어 있습니다.

[17:16] ping 명령어 추가 요청을 받은 에이전트는 전체 리포지토리를 분석하는 대신, 이미 만들어진 add command 스킬을 즉시 로드합니다. 에이전트는 'app.tsx에서 특별한 처리 필요', 'registry.ts 수정 필요' 등의 패턴을 바로 인식합니다.

link 명령으로 원격 에이전트를 터미널에 연결해 로컬 파일·쉘 도구에 접근시키는 과정을 설명한다.

[18:02] 스킬의 장점은 리포지토리에 체크인할 수 있다는 점입니다. 스킬 생성 과정을 정리하면: 가치 있는 순간을 식별했을 때 스킬 명령어를 사용하여 스킬 생성자 모드를 실행하고, 얻은 경험을 합리적인 스킬로 패키징합니다.

[18:34] 학습에 중요한 두 가지 명령어가 있습니다. init 명령어는 에이전트 초기화나 메모리 시스템 대대적 개편 시 사용하며, remember 명령어는 특정 내용을 명시적으로 기억하도록 가이드할 때 사용합니다.

[18:52] 에이전트에게 명시적으로 기억하도록 안내하는 방법과 remember 명령어의 활용법을 설명하고 있습니다.

[19:10] Letta Code는 단순한 코딩 도구가 아닌 하네스로서, 다양한 에이전트에 툴과 프롬프트를 연결할 수 있는 플랫폼임을 강조합니다.

모델 전환 시 해당 모델에 사전 훈련된 도구 집합을 자동 매핑해 일관된 코딩 성능을 확보하는 기능을 다룬다.

[19:35] 개인 비서나 동반자 에이전트 같은 실제 사용 사례를 들어 설명하며, 데모를 위한 새로운 에이전트를 생성합니다.

[20:30] 터미널에서 다른 서버의 에이전트에 연결하는 방법을 시연하며, 대화 상태가 서버에 저장되어 다양한 인터페이스에서 접근 가능함을 보여줍니다.

[21:18] Letta Code는 에이전트와 다양한 인터페이스를 연결하는 하네스 역할을 합니다. 이전에 단순한 챗봇이었던 에이전트도 link 명령어를 통해 터미널 도구들과 연결되어 컴퓨터 사용 에이전트로 변화할 수 있습니다.

[21:39] link 명령어 실행 후 ADE(Agent Development Environment)에서 확인하면 이전의 기본 도구들(대화 검색, 메모리 관리 등) 외에 코딩 전용 도구들이 대폭 추가된 것을 볼 수 있습니다.

[22:07] 에이전트에게 연결되었음을 알리고 현재 프로젝트를 살펴보라고 지시하면, Letta 서버에서 실행되던 단순 채팅 에이전트가 이제 Letta Code를 통해 사용자의 컴퓨터에 완전한 접근권한을 가지게 됩니다.

[22:27] Letta Code는 코딩뿐만 아니라 범용 CLI 하네스로도 활용 가능합니다. 개인 비서나 동반자 에이전트들이 컴퓨터에 내장되면 로컬 파일 편집, 폴더 탐색 등 사용자가 가진 모든 컴퓨터 기능을 활용할 수 있어 훨씬 강력해집니다.

[23:14] 툴셋 개념에 대해 설명하며, Letta Code가 완전히 모델에 독립적이라는 점을 강조합니다. 모델 간 전환이 매우 쉬우며, OpenAI의 코덱 시리즈나 Sonnet 같은 코딩 특화 모델들은 각각 특정 컴퓨터 사용 도구들에 대해 훈련되었다는 중요한 특징이 있습니다.

[23:44] Sonnet과 CodeX는 다른 파일 편집 방식을 사용한다고 설명합니다. Sonnet은 문자열 교체 도구를 사용하는 반면, CodeX는 더 복잡한 패치 도구를 사용하도록 훈련되었습니다.

[24:04] 성능 최적화를 위해서는 모델과 도구 세트의 최적 조합을 고려해야 한다고 강조하며, Sonnet에서 Opus로 모델을 전환하는 과정을 보여줍니다.

[24:29] Opus에서 GPT 4o1 CodeX로 전환할 때 자동으로 도구 세트도 함께 바뀌는 기능을 설명합니다. 이는 코딩 성능을 위해 모델에 최적화된 도구를 사용하기 위함입니다.

메모리 퍼스트 디자인이 가져올 협업·효율성 향상, 완전한 오픈소스·모델 독립성의 의미와 향후 발전 방향을 제언한다.

[25:05] ADE에서 실제 도구 세트를 확인해보며 apply patch와 shell 도구에 주목하라고 안내합니다. CodeX에서 Sonnet으로 바꿀 때 이 도구들이 어떻게 변화하는지 보여줍니다.

[25:34] CodeX에서 Anthropic 모델로 다시 전환하면서 Claude 도구 세트와 CodeX 도구 세트의 차이점을 설명합니다. patch 도구 대신 edit 도구, shell 대신 bash 도구가 사용됩니다.

[26:03] 시스템 프롬프트 교체 기능을 언급하며 모든 것이 설정 가능하고 완전히 화이트박스라고 강조합니다. CodeX 시스템 프롬프트 지원에 대해서도 언급합니다.

[26:18] Gemini를 포함한 다양한 모델에서 툴셋 교체 기능이 작동하며, 이는 최적화의 한 단계로 볼 수 있습니다.

[26:25] 기본적으로 시스템 프롬프트를 자동으로 교체하지 않는데, 원격 에이전트의 경우 많은 시간을 들여 구축한 시스템 프롬프트를 보호하기 위해서입니다.

[26:40] 성능 최적화를 원하고 시스템 프롬프트 수정에 신경 쓰지 않는다면 시스템 사용을 고려해볼 수 있습니다.

[26:54] 툴셋 개념을 도입한 이유는 모델들이 특정 도구에 대해 후처리 훈련되었기 때문이며, 훈련된 것과 다른 도구를 사용하면 성능이 떨어질 수 있기 때문입니다.

[27:07] Leta에서는 다양한 툴셋으로 모델들을 벤치마킹하여 GPT-4o, Codex, 최신 오픈 모델, Anthropic 모델 등을 사용할 때 최적의 성능을 보장합니다.

[27:26] Leta 코드의 간단한 투어를 마치며, 더 자세한 내용은 공식 문서에서 확인할 수 있고 완전히 오픈 소스로 제공됩니다.

[27:33] 기존의 세션 기반 코딩 에이전트와는 근본적으로 다른 설계로, 인간과의 상호작용에 더 가깝습니다.

[00:02] 안녕하세요, 레타의 찰스입니다.

[00:04] 오늘 저희는 레타 코드를 발표하게 되어

[00:05] 매우 기쁩니다. 이것은 최초의

[00:07] 메모리 우선 코딩 에이전트입니다. 또한

[00:09] 완전 오픈소스이고 모델에

[00:11] 구애받지 않기 때문에 어떤

[00:12] 모델과도 함께 사용할 수 있습니다. 이번 릴리즈는 꽤 중요한 것이어서

[00:14] 가장 중요한 내용을

[00:15] 앞쪽에 먼저 다루려고 하지만, 물론

[00:16] 설명란의 타임스탬프를 사용해서

[00:18] 원하는 부분으로 이동하셔도 됩니다. 자, 그럼

[00:20] 메모리 우선 코딩 에이전트가

[00:21] 실제로 무엇을 의미하는지, 메모리

[00:22] 우선 코딩 하네스가 무엇인지 알아보겠습니다. 레타 코드는

[00:24] 상태를 유지하는 에이전트라는

[00:25] 철학을 중심으로 구축되었습니다. 즉, 동일한

[00:27] 코딩 에이전트를 더 오래, 더 자주

[00:29] 사용할수록 실제로 시간이

[00:31] 지날수록 더 나아진다는 것입니다. 아마도

[00:32] 클로드 코드, 코드사이, 제미나이

[00:33] CLI와 같은 다른 코딩

[00:36] 에이전트들에 익숙하실 겁니다. 이들은 모두 세션 기반입니다.

[00:39] 효과적으로 세션들은

[00:40] 독립적입니다. 클로드 코드의

[00:42] 새로운 세션을 시작할 때마다

[00:44] 세션 간에 실제 학습이

[00:45] 일어나지는 않습니다

[00:47] 클로드.MD나

[00:49] 에이전트.MD와 같은 마크다운 파일에 쓰여진 것 외에는요. 그리고 에이전트의

[00:51] 컨텍스트 윈도우는 실제로

[00:53] 현재 세션의 메시지와

[00:55] 에이전트.MD 파일이나

[00:57] 클로드.MD 파일 내부의 내용만 포함합니다. 반면에 레타

[00:59] 코드는 완전히 에이전트 기반입니다. 아이디어는

[01:02] 여러 다른 세션에서

[01:04] 동일한 에이전트를 사용하게 된다는 것입니다.

[01:06] 이러한 에이전트들은 지속적인

[01:08] 메모리를 가져야 합니다. 시간이

[01:09] 지날수록 실제로 학습해야 하고요. 그리고 에이전트를

[01:11] 더 많이 사용할수록, 일종의 보상을

[01:13] 받게 되어야 하고

[01:15] 에이전트가 시간이 지날수록 점점 더 나아져야 합니다. 여전히

[01:16] 세션을 지우거나

[01:18] 리셋하는 개념은 있습니다

[01:20] 컨텍스트 윈도우를 지우고 싶을 때를 대비해서요

[01:22] 작업을 바꿀 때 이전 작업이

[01:24] 현재 컨텍스트를 오염시키는 것을

[01:26] 원하지 않는 경우 말이죠. 하지만 그런 경우에도

[01:27] 레타 코드에서 클리어를 사용하면

[01:29] 에이전트의 메모리는 여전히

[01:31] 지속될 것입니다

[01:33] 리셋되는 것은

[01:34] 메시지 히스토리뿐입니다. 전통적인

[01:37] 코딩 에이전트와

[01:38] 레타 코드 간의 관계는

[01:40] 상당히 다릅니다. 전통적인

[01:41] 코딩 에이전트의 경우, 응용프로그램을

[01:43] 시작할 때마다

[01:44] 새로운 계약자를

[01:45] 저장소에 투입하는 것과 같습니다.

[01:47] 그리고 레타 코드의 경우, 시간이 지날수록

[01:50] 학습할 실제 동료나

[01:52] 후배를 두는 것과 훨씬 더 비슷합니다.

[01:54] 더 많이 사용할수록 투자가

[01:56] 에이전트가 시간이 지날수록

[01:58] 점점 더 나아지는 것으로 보상받을 것입니다. 그럼

[02:00] 실제로 레타 코드를 어떻게 사용할까요?

[02:01] 아주 간단합니다. npm install을 사용해서

[02:04] 노드 패키지

[02:05] 매니저에서 가져오면 됩니다. 레타 코드는 또한 완전히

[02:07] 오픈소스입니다. 레타

[02:08] 코드 깃허브 저장소에 가면

[02:10] 원한다면 소스에서 설치할 수도 있습니다. 간단히

[02:12] 작업하고 싶은 디렉터리로

[02:13] 이동해서 letcode를 타이핑하고 엔터를 치면 됩니다.

[02:16] 이전에 레타 코드를 실행해본 적이 없다면

[02:18] 첫 실행 시 일어나는 일은

[02:19] OAuth 인증을 요청받게 됩니다.

[02:21] OAuth로 인증하거나, 링크를 클릭해서

[02:23] 키를 자동 생성할 수 있습니다.

[02:24] 다른 방법으로는 Letta API 키를

[02:27] 수동으로 생성해서 환경 변수로

[02:28] 내보내거나 설정하는 방법이 있습니다.

[02:31] Letta Code를 실행하기 전에 말이죠.

[02:32] Letta Code는 Letta 위에 구축되었습니다.

[02:34] 물론 Letta 서버를 직접 호스팅할 수도 있고

[02:36] 그 경우 Letta 기본 URL을

[02:37] 설정하면 됩니다.

[02:38] 실제로 부팅 시 무슨 일이 일어나는지 보죠.

[02:40] 기본적으로 Letta를 실행하면

[02:42] 현재 디렉터리에서 Letta Code 에이전트가

[02:45] 사용된 적이 있는지 스캔합니다.

[02:47] 에이전트가 사용된 적이 있다면

[02:49] 이 디렉터리에서 가장 최근에 사용된

[02:51] 에이전트를 가져와서

[02:53] 자동으로 해당 에이전트를 재개합니다.

[02:55] 그렇지 않으면 처음부터

[02:57] 새 에이전트를 생성합니다.

[02:59] 이 모든 것은 매우 설정 가능합니다.

[03:02] 이 경우에는 현재 디렉터리에서

[03:04] Letta Code를 전에 실행했었기 때문에

[03:06] 이전 에이전트에 자동 연결됩니다.

[03:07] 하지만 다른 에이전트를 사용하고 싶다면

[03:08] 언제든 resume을 입력하고 엔터를 누르면

[03:12] 마지막 실행 날짜순으로 정렬된

[03:13] 모든 다른 에이전트들을 볼 수 있습니다.

[03:15] 접근하기 매우 쉽죠. 원하는 것으로 가서

[03:17] 엔터를 누르면 에이전트가 바뀝니다.

[03:19] 앞서 말했듯이 Letta Code는

[03:21] 모델에 구애받지 않습니다. 언제든지

[03:23] 에이전트를 처음 생성할 때나

[03:25] 대화 중간에도

[03:26] 기본적으로 원할 때마다

[03:28] 모델을 바꿀 수 있습니다.

[03:30] 여기에 가장 인기 있는 모델들의

[03:32] 기본 세트가 있지만

[03:34] 기본적으로 Letta와 호환되는

[03:36] 모든 모델이 완전히 지원되며

[03:37] 에이전트와 함께 사용할 수 있습니다.

[03:39] 앞서 말했듯이 기본적으로 Letta Code를

[03:40] 실행하면 가장 최근에 사용된 에이전트를

[03:42] 찾아서 연결을 시도합니다.

[03:44] 처음부터 새 에이전트를 시작하려면

[03:46] 그냥 letta-new만 하면 됩니다.

[03:48]

[03:53] Claude Code를 사용해 보셨다면

[03:54] 권한 시스템에 익숙할 것입니다.

[03:55] Letta Code의 권한 시스템은

[03:57] 기본적으로 동일합니다. 탭 형식도 있어서

[03:59] Shift+Tab을 누르면

[04:01] 모든 편집 수락에서 계획 읽기 전용 모드로

[04:04] 전환할 수 있습니다. 이 모드에서는

[04:06] 에이전트가 계획을 만들라는 요청을 받고

[04:07] 계획 파일만 편집할 수 있고

[04:08] 다른 것은 편집할 수 없습니다.

[04:09] 마지막으로 위험한

[04:11] YOLO 모든 허용 모드가 있습니다.

[04:12] 모든 권한을 우회하는 모드죠.

[04:15] 이는 샌드박스 내에서 배포할 때

[04:17] 매우 유용합니다. 샌드박스 안에서

[04:18] 무슨 일이 일어나든 상관없고

[04:20] 권한을 승인하는 것을 귀찮아할 때

[04:22] 사용하면 됩니다.

[04:24] 하지만 일반적으로 샌드박스 밖에서는

[04:26] YOLO 모드 사용을 권장하지 않습니다.

[04:28]

[04:32] 다음으로 빠르게 지적하고 싶은 것은

[04:33] Letta Code에서 생성된 모든 에이전트들이

[04:35] 완전한 Letta 에이전트라는 점입니다.

[04:37] 완전히 안정적이고

[04:39] 서버에서 실행되며

[04:41] 완전한 REST API를 통해 주소 지정이 가능합니다.

[04:45] 즉, 이러한 에이전트들을

[04:46] ADE에서도 볼 수 있습니다. 명령어 바를 열면

[04:49] ADE에서 이 에이전트를 열 수 있는 링크를 볼 수 있어요.

[04:50] 이 에이전트는

[04:52] 브라우저의 ADE를 통해 완전히 접근할 수 있습니다.

[04:54] 왜냐하면

[04:56] 에이전트가 반드시 여러분의

[04:58] 로컬 컴퓨터에서 실행되지 않기 때문이죠.

[04:59] 여러분의 로컬에서

[05:00] 실행되는 것은 에이전트가

[05:02] 컴퓨터와 상호작용할 수 있게 하는 하네스입니다.

[05:04] 하지만 에이전트는

[05:05] 서버에서 별도로 실행되고 있어서

[05:07] 어떤 기기에서든 그 에이전트와

[05:08] 소통할 수 있습니다.

[05:11] 에이전트는 완전한

[05:12] REST API를 통해 접근할 수 있어요. 즉,

[05:15] 여러분이 에이전트와 대화하는 설정에서

[05:16] 여러분의

[05:18] 컴퓨터에 접근하는 많은 코드 대신

[05:19] 그 동일한 에이전트에게

[05:21] iMessage나 WhatsApp, 사용자 정의 웹 앱을 통해

[05:24] 메시지를 보낼 수도 있어요.

[05:27] 기본적으로 여러분이

[05:28] 원하는 무엇이든 가능합니다. 앞서 얘기한 것처럼

[05:30] Letta Code는 매우 메모리 중심적이라고 했죠. 반면

[05:32] Claude Code나 Cli 같은

[05:35] 다른 코딩 에이전트들은

[05:37] 매우 세션 기반적이죠. 이 경우

[05:40] 새로운 에이전트 Letta Code를 만들었는데

[05:42] 실제로 어떻게

[05:44] 학습하기 시작하게 할까요?

[05:46] 왜냐하면 이 시점에서

[05:49] 새로운 에이전트를 만들었지만

[05:50] 아직 아무것도 학습하지 않았거든요.

[05:52] 현재로서는

[05:54] Claude Code나 Codec CLI의

[05:56] 새로운 세션만큼이나 유용한 정도입니다. 이를 위한

[05:59] 여러 가지 방법이 있습니다.

[06:00] 방금 보여드린

[06:01] ADE를 사용할 수 있어요. 예를 들어

[06:03] ADE를 열어서 수동으로 에이전트의 프로필이나

[06:07] 페르소나를 원하는 대로

[06:08] 편집할 수 있어요.

[06:10] 자신에 대한 정보를

[06:11] 많이 입력할 수도 있죠. 하지만

[06:13] init이라는 내장 명령어도 있습니다.

[06:15] 이는 실제로 메모리 초기화 시퀀스를 실행하도록

[06:17] 설계되었는데, 에이전트가

[06:19] 여러분의 프로젝트를 둘러보고

[06:20] 가이드된 질문들을 하고

[06:23] 찾은 정보를 사용해서 자체

[06:25] 메모리 시스템을 부트스트랩할 수 있어요.

[06:27] 이것이 실제로 에이전트의

[06:29] 학습 과정을 시작하는

[06:31] 매우 좋은 방법이라는 것을 발견했습니다.

[06:33] 좋아요, init 명령어를 실행해서

[06:34] 어떤 모습인지 보여드리겠습니다.

[06:38] 바로 처음에 에이전트가

[06:39] 이것이 매우 깊이 있는 연구

[06:41] 세션이어야 하는지, 아니면

[06:43] 빠른 세션이어야 하는지 묻고 있어요.

[06:45] 둘의 차이점은

[06:47] 빠른 버전은 아마 5~10, 혹은

[06:49] 20번의 도구 호출만 필요할 것이고,

[06:50] 급하실 때

[06:52] 매우 빠르게 진행되는 것이어야 합니다. 반면

[06:53] 깊이 있는 연구는

[06:56] 훨씬 더 풍부할 것이에요. 에이전트가

[06:59] 기본적으로 가능한 한 많은 정보를 살펴보고

[07:00] git 히스토리나

[07:02] git 로그를 살펴봐서

[07:04] 여러분 자신과 여러분의

[07:06] 코딩 선호도에 대한 매우 좋은 초기 프로필을 구축하려고 할 겁니다.

[07:09] 당신의 코딩 선호도와

[07:10] 그리고 팀에서 함께 작업하는

[07:12] 다른 동료들에 대한 정보도 포함됩니다.

[07:14] 이번 경우에는 데모를 위해

[07:15] 빠르게 진행하고 싶어서

[07:16] 표준 옵션을 선택하겠습니다.

[07:19] 여기서 보시면 에이전트가

[07:20] 미리 몇 가지 질문을 하고 있네요

[07:22] 제가 코딩 에이전트가

[07:24] 어떻게 동작하기를 원하는지에 대해서요.

[07:26] 먼저 질문을 해야 하는지,

[07:28] 자율적으로 동작해야 하는지

[07:30] 아니면 중간 정도인지 묻고 있습니다.

[07:31] 저는 중간 정도를 선호하는 것 같네요.

[07:33] 그리고 어떤 커뮤니케이션 스타일을

[07:36] 좋아하는지도 묻고 있습니다. 제 경우에는

[07:40] 좀 더 간결한 에이전트를 선호합니다.

[07:42] 이 에이전트가 하는 또 다른 일은

[07:44] 처음부터 시작하기 때문에

[07:46] 이 프로젝트와 관련된 다른 저장소가

[07:49] 있는지 묻습니다.

[07:51] 초기 메모리 시스템을 설정하기 위한

[07:52] 조사를 할 때, 현재 작업 중인 저장소뿐만

[07:55] 아니라... 예를 들어

[07:57] 모노레포가 아니더라도

[07:58] 마이크로서비스 같은 하나의 저장소에서

[08:00] 작업하고 있고, 관련된

[08:02] 다른 저장소들이 많이 있어서

[08:03] 모두 컨텍스트나 코딩 패턴을

[08:04] 공유하는 상황이라면

[08:06] 에이전트는 특정 저장소만 보는 것이 아니라

[08:08] 여러 저장소를 돌아다니면서

[08:10] 초기 메모리 설정을 할 때 매우 광범위한

[08:12] 검색을 할 수 있습니다.

[08:14] 이번 경우에는 실제로

[08:15] 관련된 다른 저장소들이 있긴 하지만

[08:16] 시간상 이유로

[08:18] 이 저장소 하나만 있다고 하겠습니다.

[08:21] 이제 몇 가지 초기 질문에 답을 했고

[08:22] 에이전트가 저장소를 살펴보면서

[08:24] 메모리 시스템을 부트스트랩할

[08:26] 준비를 하고 있습니다.

[08:30] 초기 메모리 시퀀스를

[08:31] 완료했다고 보고하고 있습니다.

[08:33] 약 1-2분 정도밖에

[08:34] 걸리지 않았네요. 만약 심화 연구

[08:36] 버전을 선택했다면

[08:37] 훨씬 더 오래 걸렸을 겁니다.

[08:39] 얼마나 깊이 들어갈지는

[08:40] 여러분이 결정하시면 됩니다.

[08:42] 이제 ADE로 다시 돌아가서

[08:44] 좀 더 보기 쉽게 살펴보겠습니다.

[08:47] 기존 대화를 볼 수 있습니다.

[08:48] 기본적으로 이 에이전트에서

[08:50] 일어나는 모든 일을

[08:51] ADE 내에서도 볼 수 있습니다.

[08:53] 일종의 명령 센터 같은 역할이죠.

[08:55] 로드된 메모리 블록을 살펴볼 수 있습니다.

[08:58] 에이전트가 프로젝트 블록,

[09:00] 휴먼 블록, 그리고

[09:01] 페르소나 블록을 초기화하기로 결정했네요.

[09:04] 프로젝트 블록을 보시면

[09:06] 프로젝트 사용법에 대한

[09:07] 몇 가지 내용을 추가했습니다.

[09:09] 이 중 많은 부분이 실제로

[09:11] README.md 파일에서 동기화되었습니다.

[09:14] 제가 답한 선호도에 대한 질문들이

[09:16] 휴먼 블록에 기록된 것도

[09:17] 확인할 수 있습니다. 제 워크플로우에서

[09:20] 중간 정도를 좋아한다고, 중요한 결정은

[09:22] 질문하고 일상적인 작업은

[09:24] 자율적으로 처리한다고 기록되었습니다.

[09:26] 그리고 에이전트 자체에 대해 제가 언급한

[09:29] 선호도가 페르소나 블록에 기록된 것도 볼 수 있습니다.

[09:31] 페르소나 블록은 제 자신이 아닌

[09:33] 에이전트 자체의 행동 패턴을

[09:35] 설명하는 것입니다. 보시다시피

[09:38] 응답을 간결하고 요점만

[09:40] 말하라고 되어 있는데,

[09:41] 이건 제가 Q&A에서 정확히

[09:43] 지시한 내용입니다. init 명령어는

[09:46] 에이전트를 처음 생성할 때

[09:48] 메모리 시스템을

[09:50] 부트스트래핑하는 매우 유용한

[09:52] 방법입니다. 이건 Claude.md를

[09:53] 조립하는 것보다 훨씬 더 강력한

[09:55] 버전이라고 생각하시면 됩니다.

[09:57] Claude.md는 코드베이스에 한정되지만

[09:59] 여러분이 만드는 이 에이전트는

[10:02] 다시 한번 말하지만, 여러 개의

[10:04] 다른 리포지토리가 있지만

[10:06] 모두 서로 밀접하게 관련된

[10:07] 경우라면, 각 리포지토리마다

[10:08] 다른 코딩 에이전트를 사용할

[10:10] 필요가 없다고 생각합니다.

[10:12] 다른 세션처럼 말이죠.

[10:14] 모든 리포지토리에 대한

[10:15] 공유된 컨텍스트를 가진

[10:17] 하나의 에이전트를 사용하는 것이

[10:19] 좋겠죠. 이 메모리 시스템은

[10:20] 초기 부트스트래핑 과정을 위한

[10:22] 매우 좋은 방법입니다.

[10:23] 에이전트를 가르치는데 매우 유용한

[10:26] 또 다른 명령어는 remember

[10:27] 명령어입니다. 이 경우에는

[10:29] 에이전트에게 명시적으로 무언가를

[10:31] 기억하라고 말할 수 있습니다.

[10:33] remember 뒤에 아무것도 쓰지 않고

[10:34] 엔터를 치면, 에이전트가

[10:37] 상황을 추론해야 합니다.

[10:38] 에이전트가 명백한 실수를 했을 때

[10:39] 다시는 그런 실수를 하지 않게

[10:41] 하고 싶을 때 더 유용합니다.

[10:42] 그리고 에이전트가 메모리를

[10:45] 적극적으로 업데이트하지 않아서

[10:47] 이런 절차적 정보를 로그하지

[10:49] 않았다고 느끼는 경우에도

[10:52] remember 명령어를 실행하는 것이

[10:53] 좋은 아이디어입니다.

[10:54] 엔터만 치면 됩니다.

[10:56] 더 구체적인 내용을 추가할

[10:58] 필요는 없다고 생각합니다.

[10:59] 에이전트나 모델들은 행간을 읽고

[11:01] 여러분이 원하는 것을 이해하는데

[11:02] 꽤 뛰어납니다. 명확하지 않으면

[11:05] 후속 설명을 요청할 것입니다.

[11:07] 모델이 기억했으면 하는 것을

[11:10] 구체적으로 말할 수도 있습니다.

[11:11] 이 경우에는 매우 구체적인

[11:13] 선호도를 작성하겠습니다.

[11:15] 다른 에이전트들이 종종 git add all을

[11:17] 사용하는데 여기서 타이핑하지만

[11:19] 실수로 안좋은 것들을 커밋한다는

[11:21] 것을 알았으니, 안전을 위해

[11:23] 항상 수동으로 추가하라고

[11:24] 기억하라고 했습니다.

[11:26] 에이전트가 그 정보를 메모리에

[11:28] 기록했습니다. init과 remember는

[11:30] 시간이 지남에 따라 에이전트가

[11:33] 최대한 학습할 수 있도록 하는

[11:34] 매우 강력한 메모리 관련

[11:35] 도구들입니다. 에이전트와 함께

[11:38] 작업하는 시간을 보낸 후에는

[11:39] Letta 서버에 있을 수 있는

[11:41] 다른 모든 에이전트들과

[11:43] 구별할 수 있도록 에이전트를

[11:45] 핀하고 싶을 것입니다. 나중에 쉽게

[11:48] 찾을 수 있도록 말이죠. 그 방법은

[11:51] pin을 실행하는 것입니다. 에이전트를 핀했습니다.

[11:53] 제 서버에 존재하는 다양한 에이전트들 중에서

[11:55] 제가 가장 중요하게 생각하는 것들에 집중한

[11:57] 특정 부분을 볼 수 있어요. 핀닝이라는 것은

[11:58] 기본적으로 북마크와

[11:59] 같은 개념이라고 생각하시면 됩니다. Letta 서버

[12:02] 자체에는 수백, 수천 개,

[12:03] 심지어는 수백만 개의 에이전트가

[12:05] 있을 수 있어요. 에이전트를 핀하는 것은

[12:07] Letta Code 사용자인 여러분이

[12:10] 특별히 지정하고 싶은 에이전트를

[12:12] 구분할 때 훨씬 쉽게 만들어줘요.

[12:13] 여러 번 반복해서 돌아가고 싶은

[12:15] 에이전트들을 잃어버리지 않도록 해주죠.

[12:17] 자, 마지막으로 다룰 내용은

[12:18] 스킬 학습입니다. 기본적으로 Letta Code는

[12:22] 스킬을 완벽하게 지원합니다. 만약

[12:24] 여러분이 Claude Code와 함께

[12:25] 사용해왔던 스킬들이 있고

[12:27] 그것들을 Letta와 함께 사용하고 싶다면

[12:29] 아주 비슷한 개념입니다. 스킬들을

[12:31] 디렉토리의 skills 폴더에 넣기만 하면

[12:33] Letta Code가 자동으로 인식해요. 하지만

[12:35] Claude Code와 달리 Letta Code는

[12:36] 실제로 실시간으로 스킬을

[12:39] 학습할 수 있는 내장 기능이 있어요.

[12:41] 그래서 Letta 에이전트가 학습할 때

[12:43] 배운 모든 것을 메모리 시스템인

[12:45] 메모리 블록에 통합할 수 있습니다. 하지만

[12:48] 배운 내용을 스킬로도

[12:49] 통합할 수 있어요. 이것에 대해 생각해보는

[12:52] 방법은 어떤 것들은 아마도

[12:54] 여러 다른 에이전트들 사이에서

[12:57] 공유되어야 할 것들이고,

[12:57] 리포지토리를 사용하거나

[13:00] 다른 에이전트와 인간들이 사용할 내용일 거예요.

[13:02] 이런 것들은 더 절차적인

[13:04] 정보에 가깝죠. 예를 들어

[13:06] 이 리포지토리에서 특정한 작업을

[13:08] 하고 싶다면 이렇게 하는 방법 같은 거요.

[13:10] 네, 그래서 아주 간단한 예시를

[13:11] 보여드리고 싶어요. 제가 할 방법은

[13:13] 실제로 Letta Code를 사용하는 방법을

[13:15] 보여드리는 거예요. Letta Code를 사용해서

[13:16] Letta Code 내부에 더미 기능을

[13:18] 구축해보겠습니다. 실제로 저희는

[13:20] Letta Code 자체를 구축하는 데

[13:22] Letta Code를 아주 많이 활용해요.

[13:24] GitHub 리포지토리에 가보시면

[13:25] 많은 PR들이 실제로

[13:26] Letta Code와 공동 작성된 것을

[13:28] 볼 수 있을 거예요. 저는 Letta Code를 사용해서

[13:30] 새로운 명령어를 위한 새로운 기능을 만들고,

[13:33] 그 다음에 에이전트가 겪은 경험을

[13:36] 처음으로 새로운 명령어를

[13:37] 구축하는 과정에서 얻은 것을

[13:39] Letta Code의 스킬로 바꿔볼 거예요.

[13:41] 이것은 한 번 해보면

[13:42] 아마도 어떻게 했는지 기억해야 하고

[13:44] 나중을 위해 저장해야 할

[13:46] 내용의 예시라고 할 수 있어요.

[13:48] 메모리 블록에 쓸 수도 있지만

[13:50] 스킬로도 쓸 수 있어요.

[13:51] 어떻게 작동하는지 보여드리겠습니다.

[13:52] yolo라는 새로운 명령어를 만들 예정인데

[13:55] 이것은 실제로는 키보드에서

[13:57] Shift+Tab을 누르는 것의 단축어가 될 거예요.

[14:00] YOLO 모드로 전환하기 위해서요.

[14:02] 네, 꽤 간단할 것 같아요.

[14:04] 하지만 이 과정에서 에이전트가

[14:06] 많은 것들을 배울 것이고

[14:08] 그것들을 미래의 에이전트들이나

[14:09] 미래의 Letta Code 에이전트가 아닌

[14:11] 다른 에이전트들, 심지어는

[14:13] 이 리포지토리를 보는 모든 인간이

[14:15] 다른 사람들도 활용할 수 있습니다. 좋아요, 지금

[14:18] 제가 준비한 지시사항이 있어요. 이 레포에

[14:18] 새로운 명령어를 추가하려고 합니다. /yolo 명령어인데,

[14:20] 이건 yolo 모드를 활성화하는 기능이에요.

[14:25] 자, 에이전트가 작업을 하도록 둬볼게요.

[14:25] 시간이 많이 걸리지는 않을 거예요.

[14:27] 작업이 끝나면 다시 돌아오겠습니다.

[14:28] 네, 에이전트가 작업을 완료했다고 말하네요.

[14:30] 그리고 bun rundev로 테스트하는 방법도

[14:33] 알려주고 있어요. 터미널에서 새 탭을 열어서

[14:35] 테스트해보겠습니다. 네,

[14:37] bun rundev로 시작해보겠습니다.

[14:39] 먼저 bun install을 실행해야 했어요.

[14:40] bun rundev를 실행했을 때

[14:42] 실제로 보실 수 있는데, Letta Code가 실행되면서

[14:44] 해당 레포나 프로젝트에서 가장 최근에 사용된

[14:46] 에이전트가

[14:48] 제가 작업했던 다른 에이전트였어요.

[14:51] 그래서 자동으로 해당 에이전트에

[14:52] 연결되었습니다. 이전 메시지 히스토리를

[14:54] 볼 수 있네요. yolo 명령어가 있는지

[14:56] 확인해보겠습니다.

[14:58] 좋네요, yolo 모드

[15:01] 명령어가 추가된 것을 볼 수 있어요.

[15:03] 엔터를 누르면 완벽하게 작동하네요.

[15:06] 엔터를 누르니 평소에 Shift+Tab으로

[15:07] 하던 동작을 수행합니다.

[15:10] 한 번 더 시도해볼게요. 아름답네요!

[15:13] 네, 아주 잘 작동했어요. 기능을 구현했는데,

[15:15] 제가 보여드리고 싶었던 것은

[15:17] 방금 구현한 이런 종류의 기능,

[15:19] Letta Code에 새로운 플래그를 추가하는

[15:20] 이런 작업은 아마 미래에 다른 사람들도

[15:24] 하고 싶어할 거라는 점이에요.

[15:25] 시간이 지나면서 기능을 확장하고

[15:26] 더 많은 플래그를 추가하게 될 테니까요.

[15:28] 스킬 명령어로 에이전트에게

[15:29] 방금 전 코딩을 통해 학습한 것을

[15:31] 나중에 재사용할 수 있는 스킬로 변환하도록

[15:32] 지시할 수 있어요. 그래서 여기서

[15:35] 스킬을 입력할 수 있어요.

[15:37] remember와 비슷하게 에이전트가 제가 원하는 것을

[15:38] 추론하도록 할 수도 있지만,

[15:40] 좀 더 구체적인 정보를

[15:42] 제공하겠습니다. 네, 저는

[15:45] 미래의 에이전트들에게 새로운 명령어 추가에

[15:48] 관련된 내용을 가르치는 스킬을 만들어서

[15:49] 처음부터 배우지 않고도 빠르게

[15:52] 더 많은 명령어를 추가할 수 있도록

[15:53] 할 수 있냐고 물었어요.

[15:54] 이런 식으로 작동하는 원리는

[15:58] 실제로 스킬 생성자 스킬이 있어서

[16:00] 에이전트가 새로운 스킬을 만드는 데

[16:01] 도움을 줍니다. 지금 하고 있는 일은

[16:03] 먼저 스킬 생성자 스킬을 로드하는 것이에요.

[16:05] 스킬 생성자 스킬은 실제로

[16:06] 스킬 생성을 위한 모범 사례가

[16:09] 무엇인지 설명해줍니다.

[16:10] 이 경우에는 올바르게 수행할 수 있도록

[16:12] 몇 가지 명확한 질문을 하고 있어요.

[16:14] 네, 몇 가지 기본 질문에 답했어요.

[16:16] 이제 에이전트가 새로운 스킬을

[16:18] 생성할 거예요. 네, 에이전트에게

[16:20] 로컬 스킬 디렉토리를 확인하라고 하면

[16:21] 이제 스킬 생성자 스킬뿐만 아니라

[16:22] add command 스킬도 생겼다는 것을

[16:24] 볼 수 있어요.

[16:26] 내부를 한번 살펴보겠습니다.

[16:29] 네, 기본적으로 에이전트가

[16:32] 스킬 파일을 생성했네요.

[16:37] 네, 기본적으로 에이전트가 생성한 것은

[16:39] add command라는 스킬 파일을 만들었는데, 이 파일에는

[16:41] Letta Code에 새로운 CLI 명령어를 추가하는 체크리스트가 담겨있습니다.

[16:43] 이제 다른 에이전트가 이 리포지토리에서 작업할 때,

[16:46] 특히 Letta Code 리포지토리의

[16:47] 소스 코드에서 작업할 때

[16:49] 사용자가 에이전트에게

[16:51] 새로운 CLI 명령어를 추가해달라고 요청하면,

[16:52] 에이전트가 즉시

[16:54] 이미 만들어진 스킬이 있다는 걸 깨닫고

[16:55] 해당 스킬을 바로 로드할 것입니다.

[16:56] 구체적인 예시를 보여드리기 위해

[16:58] 이 디렉토리 안에

[16:59] 새로운 에이전트를 만들어보겠습니다.

[17:00]

[17:02] 이 에이전트를 열어보면

[17:04] 아직 메시지가 없는 것을 볼 수 있습니다. 빈 메시지 히스토리죠.

[17:06] 하지만 스킬 블록으로 가보면

[17:07] 스킬 블록이 자동으로

[17:10] 스킬 생성자 스킬과

[17:12] add command 스킬로 채워져 있습니다.

[17:14] 이 에이전트에게

[17:16] ping이라는 새로운 명령어를 추가하고 싶은데

[17:18] 실행하면 pong을 반환하도록 해달라고 질문한다면,

[17:20] 에이전트가 명령어가 어떻게 작동하는지

[17:23] 전체 리포지토리를 읽어야 하는 대신

[17:25] 명령어 추가에 관련된 모든 파일이 무엇인지

[17:28] 파악해야 하는 대신

[17:29] 명령어를 추가하는 데 필요한 파일들을

[17:31] 이미 만들어진 add command 스킬이 있기 때문에

[17:33] 다른 에이전트가 만든 스킬을

[17:35] 이 에이전트가 즉시 로드할 수 있습니다.

[17:37] add command 스킬을 찾아서

[17:40] 해당 스킬을 컨텍스트에 로드하고

[17:41] 이제 이 에이전트는

[17:44] 무엇을 해야 하는지 바로 알 수 있습니다.

[17:47] 에이전트의 추론 과정을 보면 '좋다.

[17:48] 스킬이 로드되었다. 로드된 스킬 지침을 보니

[17:50] pong을 반환하는 간단한 ping 명령어는

[17:52] 매우 간단할 것 같다.

[17:53] 패턴을 보니 간단한 명령어라도

[17:55] app.tsx에서 특별한 처리가 필요하고

[17:56] registry.ts도 수정해야 한다'고 합니다.

[17:58] 이렇게 코드베이스 탐색을

[18:00] 단축할 수 있는 매우 편리한 방법이고

[18:02] 지식을 공유하는 아주 좋은 방법입니다.

[18:03] 스킬의 장점은 이런 것들을 리포지토리에 체크인할 수 있다는 점입니다.

[18:06] 다른 에이전트로 돌아가서 정리해보면,

[18:09] 우리가 해야 할 일은 스킬로 만들 가치가 있는 순간이나

[18:12] 사건을 식별했을 때

[18:14] 기본적으로 스킬 명령어를

[18:16] 인수 없이 사용하거나

[18:18] 가이드 역할을 하는 인수와 함께 사용하는 것입니다.

[18:20] 이렇게 하면 기본적으로

[18:22] 스킬 생성자 모드가 실행됩니다.

[18:24] 계획 모드와 비슷하지만

[18:25] 스킬 생성자 모드에서는 에이전트의 목표가

[18:27] 방금 얻은 모든 정보나

[18:28] 경험을 합리적인 스킬로 패키징하는 것입니다.

[18:31] 학습에 중요한 다른 두 명령어는

[18:34] init 명령어입니다. 이는 에이전트를 초기화할 때

[18:38] 실행해야 하는 명령어이거나

[18:40] 에이전트를 한동안 사용했는데

[18:41] 메모리 시스템을 대대적으로

[18:42] 개편하고 싶을 때 사용합니다.

[18:44] 에이전트를 다른 용도로

[18:46] 전환할 때 말이죠.

[18:48] 그리고 물론 remember 명령어도 있습니다.

[18:50] 만약 당신이

[18:52] 에이전트가 명시적으로 무언가를 기억하도록 안내하고 싶다면,

[18:54] 물론 에이전트는 메모리 도구에

[18:55] 접근할 수 있고 자신의 메모리를 편집할 수 있습니다.

[18:57] 많은 경우 에이전트가 자동으로

[18:59] 자신의 메모리를 업데이트하겠지만,

[19:01] remember 명령어는 에이전트가

[19:02] 메모리를 특정한 방식으로

[19:05] 업데이트하도록 안내하는 편리한 방법입니다.

[19:07] 자, 마지막으로 살펴볼 것은

[19:10] Letta Code 자체가

[19:12] 단순히 코딩용으로만 사용되는 프로그램이 아니라는 점입니다.

[19:13] Letta를 하나의 하네스로 생각하는 것이 좋겠습니다.

[19:17] 툴과 프롬프트의 모음이라고 할 수 있고,

[19:18] 어떤 에이전트에든 연결할 수 있습니다.

[19:21] 코딩 에이전트일 수도 있고,

[19:22] 터미널이나 컴퓨터에 접근할 수 있게 하고 싶은

[19:25] 어떤 종류의 에이전트든 될 수 있습니다.

[19:27] 예를 들어 개인 비서나

[19:29] 동반자 에이전트가 있다면 말이죠.

[19:30] 여기서 데모 에이전트를 만들어보겠습니다.

[19:32] 이 예시에서는

[19:35] 신선한 스타터 키트로

[19:37] 새로운 에이전트를 만들었지만,

[19:40] 텔레그램이나 아이메시지에

[19:41] 연결해서 오랫동안

[19:43] 사용해온 에이전트라고

[19:44] 상상해 보실 수 있습니다.

[19:46] 이제 여러분이 원하는 것은

[19:48] 바로 그 에이전트와

[19:49] 터미널에서 소통하는 것이고,

[19:51] 터미널을 통해

[19:53] 컴퓨터에서 작업을 할 수 있게 하는 것입니다.

[19:55] Letta Code로 이 모든 것을 할 수 있습니다.

[19:57] 완전히 새로운 에이전트가

[19:58] 아니도록 에이전트 시뮬레이터에서

[20:00] 몇 가지 메시지를 실행해서

[20:02] 어느 정도 히스토리를 만들어보겠습니다.

[20:04] 제 이름이 Charles라고 말할 수 있습니다.

[20:07] 만나서 반갑습니다.

[20:09] 메모리 블록을 조금

[20:11] 미리 채워넣고 싶습니다.

[20:12] 좋습니다. 이제 이 에이전트 ID를 가져올 수 있네요.

[20:16] Letta Code로 돌아가서

[20:18] d-agent로 Letta Code를 시작하고

[20:19] 에이전트 ID를 복사 붙여넣기하면,

[20:20] 엔터를 눌렀을 때

[20:22] 터미널에서 다른 서버에서

[20:25] 실행되고 있는 이 에이전트로의 연결을 로드했습니다.

[20:28] 기본적으로는 이 에이전트에 대해

[20:32] 실제로 변경된 것은 없습니다.

[20:34] 이 에이전트는 제가 터미널을 통해

[20:37] 소통하고 있다는 것을 반드시 알지는 못합니다.

[20:40] 대화를 계속해보겠습니다.

[20:42] 여기서 잠깐 대화를 계속할 수 있습니다.

[20:45] UI로 돌아가 보시면

[20:48] 터미널에서 일어났던 모든 대화가

[20:50] UI에 완전히 표시되는 것을 볼 수 있습니다.

[20:51] 대화 상태가 특정 기기에

[20:52] 저장되는 것이 아니라

[20:54] 서버 내부에 저장되기 때문입니다.

[20:57] 터미널이나 Letta Code를

[20:58] 에이전트와 상호작용하는

[21:00] 하나의 인터페이스로

[21:01] 생각하시면 됩니다.

[21:03] 여러 인터페이스 중 하나로 말이죠.

[21:05] 하지만 여기서 흥미로운 점은

[21:06] Letta Code가 하네스이기 때문에

[21:09] 기본적으로 이것을

[21:10] 가져다가 사용할 수 있다는 것입니다.

[21:12] 그리고 이를 통해

[21:14] 여러분의 에이전트와

[21:16] 상호작용할 수 있습니다.

[21:18] 여러 다른 인터페이스 중 하나입니다. 하지만

[21:20] 여기서 정말 멋진 점은 Letta Code가

[21:23] 하나의 하네스이기 때문에 기본적으로

[21:24] 컴퓨터 사용 에이전트가 아니었던

[21:26] 더 챗봇 같았던 에이전트를 가져와서

[21:28] Letta Code 내부의 도구들을

[21:31] 이 에이전트에 연결할 수 있어서

[21:33] 터미널을 사용할 수 있게 됩니다.

[21:35] 방법은 link 명령어를 사용하는 것입니다.

[21:37] link를 실행하면

[21:39] link가 Letta Code 하네스 내에서

[21:41] 사용 가능한 도구들을 에이전트와

[21:43] 동기화했습니다. 다시 ADE로 돌아가서

[21:45] 도구 섹션을 보고 싶다면

[21:47] 이제 이전에 없던 많은

[21:49] 추가 도구들을 볼 수 있습니다.

[21:50] 이전에는 이 세 개의 도구만 있었던 것 같습니다.

[21:53] 대화 검색, 메모리 삽입, 메모리 교체였죠.

[21:55] 이제는 코딩 전용 도구들의

[21:56] 큰 세트가 에이전트에게

[21:58] 제공됩니다.

[22:00] 에이전트로 다시 돌아가서

[22:03] 이제 "안녕, 방금 너를

[22:05] Letta CLI 도구로 연결했어.

[22:07] 현재 프로젝트를 한번

[22:08] 살펴봐"라고 말할 수 있습니다.

[22:10] Letta Code CLI 도구를 시도해봐."

[22:12] 현재 프로젝트를 살펴봐."

[22:15] 이제 이전에는 그냥 채팅

[22:17] 에이전트 같았던 이 에이전트가

[22:19] Letta 서버에서 살고 있었던 것이

[22:20] 이제 완전한 접근권한을, 적어도

[22:23] 강력한 권한 시스템을 통해

[22:25] Letta Code를 통해 제 컴퓨터에

[22:27] 접근할 수 있게 됐습니다. Letta Code는

[22:29] 코딩에 매우 특화되어 사용할 수 있습니다만,

[22:31] 또한 Letta Code를 일종의

[22:33] 범용 CLI 하네스로도 사용할 수 있어서

[22:35] Letta 서버 어딘가에서

[22:37] 실행 중인 에이전트를 가져와서

[22:38] 그 에이전트를 터미널로 전송하고

[22:41] 컴퓨터에 대한 완전한 접근권한을

[22:43] 제공하는 매우 강력한 방법입니다.

[22:45] 이것이 정말 유용한 이유는

[22:46] 개인 비서나 동반자 같은

[22:47] 이런 많은 에이전트들이

[22:50] 컴퓨터에 내장되면 실제로

[22:52] 훨씬 더 많은 일을 할 수 있기 때문입니다.

[22:53] 사용자가 자신의 컴퓨터에서

[22:55] 가지고 있는 모든 어포던스를

[22:56] 얻게 되거든요. 로컬 파일들을

[22:58] 편집하고, 다운로드 폴더를 탐색하고,

[23:00] 문서들을 탐색하는 등의 일들이요.

[23:01] Letta Code를 통해 연결하면

[23:04] 에이전트가 이런 일들을 할 수 있습니다.

[23:06] 그리고 다시 말하지만, 꼭 코딩

[23:07] 에이전트일 필요는 없습니다.

[23:09] Letta Code를 통해 컴퓨터에

[23:11] 접근권한을 주는 비코딩 에이전트일 수도 있어요.

[23:14] 좋습니다. 다루고 싶은 또 다른 개념은

[23:15] 툴셋의 개념입니다. 앞서 말했듯이

[23:17] Letta Code는 완전히 모델에 독립적입니다.

[23:19] 따라서 어떤 모델 간에도 전환할 수 있고

[23:22] 매우 쉽게 할 수 있습니다. Letta 자체가

[23:24] 모델에 독립적이니까 Letta Code가

[23:26] 완전히 모델에 독립적인 것은 당연합니다.

[23:27] 중요하게 주목할 점은

[23:29] 특히 OpenAI의 코덱 시리즈처럼

[23:30] 코딩에 더 집중된 모델들은

[23:32] 일반적으로 특정 종류의

[23:34] 컴퓨터 사용 도구들에 대해 훈련되었다는 것입니다.

[23:36] 예를 들어 Sonnet은 특정 도구를

[23:38] 사용하도록 훈련되었습니다.

[23:41] 예를 들어 Sonnet은

[23:44] 문자열 교체 도구들을 사용합니다.

[23:47] 파일을 편집할 때는

[23:49] 기존 문자열과 새로운 문자열을

[23:51] 지정해서

[23:52] 교체 작업을 수행하는 방식으로 편집합니다.

[23:54] 반면 CodeX는 실제로

[23:57] 더 복잡하고 특별한

[23:59] 패치 도구를 사용하도록 훈련되었습니다.

[24:02] 이는 문자열 교체와는 완전히 다릅니다.

[24:04] 성능 최적화를 원한다면,

[24:06] 정말로 코딩에 집중하고

[24:07] 최고의 코딩 에이전트를

[24:09] 갖고 싶다면

[24:12] 최적의 모델과

[24:14] 하니스 조합을 사용해야 합니다.

[24:16] 이 경우 도구 세트를 정말로 고려해야 합니다.

[24:17] 자, 그럼 Sonnet에서

[24:20] Opus로 바꿔보겠습니다.

[24:22] 아주 간단한 모델 스위처를 볼 수 있습니다.

[24:24] 우측 하단에서

[24:26] 모델이 바뀐 것을 확인할 수 있습니다.

[24:29] 하지만 Opus에서 GPT 4o1 CodeX로 바꾸면

[24:33] 완전히 다른

[24:34] 도구 세트로 훈련되었습니다.

[24:36] 이 경우에는

[24:37] 단순히 모델을

[24:38] Opus로 성공적으로 전환했다고 말하는 대신

[24:42] 자동으로 도구 세트도

[24:44] CodeX 도구 세트로 전환했다고 알려줍니다.

[24:47] 이렇게 자동으로 하는 이유는

[24:50] 코딩 성능을 중시한다면

[24:52] 모델에 가장 최적화된

[24:54] 도구 세트를

[24:56] 사용하고 싶어하기 때문입니다.

[24:57] 물론 이것은 완전히 설정 가능합니다.

[24:59] 하나의 도구 세트를 계속 사용할 수도 있지만

[25:01] Letta Code에서는 모델을 바꿀 때

[25:03] 자동으로 도구 세트도 함께 바뀝니다.

[25:05] 제가 말하는 도구 세트가

[25:06] 무엇인지 명확히 하기 위해

[25:08] ADE에서 이 에이전트로 이동해보겠습니다.

[25:11] 이 에이전트에

[25:12] 연결된 도구들을 보면

[25:14] apply patch 도구, grep, list, read 등이 있습니다.

[25:17] 여기서 주목할 두 가지는

[25:19] apply patch와 shell입니다.

[25:22] CodeX에서 Sonnet으로 바꾸면

[25:24] apply patch와 shell이 사라지고

[25:26] 일반적으로 이 도구 세트가

[25:28] 조금 다르게 보일 것입니다.

[25:29] 그럼 해보겠습니다.

[25:31] 여기서 Opus로 다시 바꿔보겠습니다.

[25:34] 이번에도 CodeX에서

[25:36] Anthropic 모델로 바꾸기 때문에

[25:38] 도구 세트도 자동으로 바뀝니다.

[25:41] ADE로 다시 돌아가면

[25:43] 이제 실제로

[25:44] 다른 도구 세트임을

[25:46] 확인할 수 있습니다.

[25:49] Claude 도구 세트는 CodeX 도구 세트보다

[25:51] 더 많은 도구를 가지고 있습니다.

[25:54] 하지만 더 이상 patch 도구는 없습니다.

[25:57] 대신 edit 도구들이 있고

[25:58] 마찬가지로 shell 도구도 없습니다.

[26:01] 대신 bash 도구가 있습니다.

[26:03] 실제로 이것보다 더 나아갈 수도 있습니다.

[26:06] 시스템 프롬프트를

[26:07] 바꿀 수 있는 기능도 있습니다.

[26:09] 모든 것이 설정 가능하고

[26:12] 완전히 화이트박스입니다.

[26:15] 시스템 프롬프트를

[26:17] CodeX 시스템 프롬프트처럼

[26:18] Gemini에 대해서도 마찬가지입니다. 같은 툴셋

[26:20] 교체 기능이 Gemini에서도 작동합니다.

[26:21] 이건 최적화 관점에서 더 나아간 단계라고 생각합니다.

[26:25] 기본적으로는 시스템 프롬프트를

[26:26] 자동으로 교체하지 않습니다.

[26:29] 일부 이유는 우리가 상상하기로는

[26:31] 원격 에이전트에 연결하는 경우처럼

[26:32] 해당 에이전트가 실제로

[26:33] 많은 시간을 들여 구축한

[26:35] 시스템 프롬프트를 가지고 있을 수 있고

[26:36] 우리는 그 시스템 프롬프트를

[26:39] 자동으로 덮어쓰고 싶지 않습니다.

[26:40] 하지만 항상 성능을 위해

[26:41] 최적화하고 싶고

[26:45] 시스템 프롬프트 수정에 대해

[26:47] 별로 신경 쓰지 않거나

[26:48] 시스템 프롬프트에 저장된

[26:50] 중요한 내용이 없다면

[26:51] 시스템 사용을 고려해보셔야 합니다.

[26:52] 네, 다시 말해서 우리가 이것들을 넣은 이유는

[26:54] 실제로 교체되는

[26:55] 툴셋이라는 개념을 가지고 있는 이유는

[26:57] 이런 모델들이 실제로

[26:59] 특정 도구들에 대해 후처리 훈련되었고

[27:00] 모델이 훈련된 것과 유사해 보이는

[27:02] 도구를 사용하지 않으면

[27:04] 문제가 될 수 있고

[27:06] 성능이 떨어질 것이기 때문입니다.

[27:07] 그리고 Leta에서는 다양한 툴셋으로

[27:09] Leta 코드 내에서 이런 모델들을

[27:12] 벤치마킹하는데 많은 시간을 투자해서

[27:14] GPT-4o 또는 Codex를 사용하든

[27:17] 최신 오픈 모델이나

[27:19] 최신 Anthropic 모델을 사용하든

[27:20] 툴셋이나 하네스가

[27:22] 원래와 조금 다르게 보인다고 해서

[27:23] 성능이 제한되지 않도록

[27:24] 확실히 할 수 있습니다.

[27:26] 네, 그래서 이것이 Leta 코드의 간단한 투어였습니다.

[27:28] 공식 문서에는 훨씬 더 많은 내용이 있습니다.

[27:30] 여러분이 이것으로 무엇을 만들지

[27:31] 정말 기대됩니다. 완전히 오픈 소스이고

[27:33] 네, 근본적으로 이것은

[27:34] 세션 기반인 기존의

[27:36] 표준 코딩 에이전트와는

[27:37] 상당히 다른 설계라고 생각합니다.

[27:39] 인간과 상호작용하는 것과

[27:40] 훨씬 더 유사한 방향으로 나아가고 있습니다.

[27:42] 에이전트를 가르치는데 많은 시간을 투자하고

[27:44] 실제로 점점 더 많이 학습하게 하고

[27:46] 실수로부터 배우게 하고

[27:48] 경험으로부터 스킬을 만들고

[27:50] 시간이 지남에 따라 메모리를 업데이트하게 합니다.

[27:52] 그래서 여러분의 피드백을 듣게 되어 기쁘고

[27:53] 네, Discord에서 만나요. 나중에 뵙겠습니다.