여러분, 최근 에이전트 도구(Cursor, Claude Code, Cline, Continue, Open Interpreter 등)를 여럿 사용하면서 똑같은 불편을 반복적으로 겪고 있다. 모든 도구는 제로부터 시작하는 자체 에이전트를 두고 있으며 컨텍스트는 사용자를 따라가지 않는다. Cursor에서 터미널이나 휴대폰으로 전환하면 에이전트는 5분 전에 작업하던 내용을 전혀 기억하지 못한다. '나의 리서치 에이전트'나 '나의 코딩 에이전트'를 패키징해 다른 곳에서 그대로 실행하는 깔끔한 방법도 없고 모든 것이 특정 앱이나 특정 벤더에 종속된다. 대부분의 로컬 설정은 여전히 불안정하거나 유용한 결과가 나오기 전까지 수많은 Docker와 설정 작업을 요구한다. 에이전트가 실제로 무언가를 만들어도 검증이나 출처(provenance)는 거의 전무해 사용자는 출력을 그저 믿어야 한다. 요컨대 도구는 MCP로 표준화됐지만 에이전트 자체는 여전히 완전히 이동 불가능하고 기억 없는 상태다.

이에 대해 또 하나의 챗 UI를 추가하는 대신 에이전트 계층을 고치려는 프로젝트(가칭 Loomwork)를 구상 중이다. 페르소나, 스킬, 도구, 메모리 스키마를 묶어 전부 재작성 없이 다양한 환경에서 실행할 수 있는 단순한 이동 가능 에이전트 포맷, 에이전트끼리 대화하고 작업을 인계하는 경량 방식, 벤더가 아닌 사용자를 실제로 따라다니며 언제 무엇이 기록됐는지 출처를 명확히 보여 주는 로컬 우선 메모리를 제안한다. 전체는 기본적으로 로컬(Ollama 등)로 유지하고 클라우드 모델은 명시적으로 원할 때만 사용한다. 여기에 기본적인 검증을 더해 코드나 앱 생성 시 '파일 여기 있습니다, 잘 되길' 이상의 결과를 제공하려 한다.

목표는 또 하나의 폐쇄적 에이전트 제품이 아니다. MCP가 도구를 이동 가능하게 만든 것처럼 에이전트 자체를 이동 가능하고 조합 가능한 단위로 만들려는 시도에 가깝다. 아직 초기 단계라 첫날부터 모든 것을 하려 하지는 않는다. 이에 많은 시간을 쏟기 전에 이런 도구를 실제로 매일 쓰는 사람들에게 현실 점검을 받고 싶다.

'에이전트는 이동 가능해야 하고 도구와 기기를 넘나들며 메모리를 가져야 한다'는 문제가 실감되는가, 아니면 내 워크플로에만 지나치게 치우친 생각인가. 어떤 요소가 이런 프로젝트를 또 하나의 미완성 로컬 에이전트가 아니라 실제로 유용한 것으로 만들까. 이 분야의 무언가를 무시하거나 불신하게 되는 가장 큰 이유는 무엇일까. 냉정한 의견, 참고할 기존 프로젝트, 이것이 엉터리 아이디어라는 이유 등 어떤 답변이든 환영하며 감사한다.