Show GN: AI 에이전트를 내 걸로 만드는 방법
매일 새로운 세션을 열 때마다 컨벤션을 잊어버리는 AI 코딩 에이전트 때문에 답답하셨나요? 개발자의 작업 패턴과 버그 히스토리를 스스로 기억하고 학습하며 성장하는 로컬 에이전트 메모리 시스템 'Monet'을 소개합니
매일 새로운 세션을 열 때마다 컨벤션을 잊어버리는 AI 코딩 에이전트 때문에 답답하셨나요? 개발자의 작업 패턴과 버그 히스토리를 스스로 기억하고 학습하며 성장하는 로컬 에이전트 메모리 시스템 'Monet'을 소개합니다.
매번 초기화되는 AI 에이전트, 지치지 않으셨나요?
AI 코딩 에이전트와 매일 협업하는 개발자라면 누구나 겪는 깊은 답답함이 있습니다.
어제 분명히 같이 머리를 맞대고 정한 프로젝트 컨벤션인데, 오늘 아침 새 세션을 열면 에이전트는 다시 완전히 백지상태가 되어 있습니다. TypeScript에서 interface 대신 항상 type을 사용하기로 한 약속, PR 리뷰에서 피하라고 했던 특정 패턴, 지난주에 겨우 잡아낸 크리티컬한 버그의 근본 원인까지 매번 처음 듣는 이야기인 것처럼 굴곤 하죠. 결국 같은 설명을 반복하다 지쳐 "그냥 내가 하고 말지"라며 에이전트를 꺼버리게 됩니다.
이 문제를 근본적으로 해결하기 위해 범용 AI 에이전트를 나만의 에이전트처럼 동작하게 만드는 메모리 시스템, Monet을 만들었습니다. 개발자의 컨벤션을 배우고, 선호하는 방식을 기억하며, 프로젝트의 역사를 스스로 챙기는 영리한 시스템입니다.
Monet은 어떻게 작동하나요?
Monet의 핵심 메커니즘은 단순하지만 강력하게 작동합니다.
- 쓰기 (자동 기록): 에이전트가 스스로 판단하여 기록합니다. 개발자가 일일이 "이거 기억해 둬"라고 명령하지 않아도, 작업 중에 내린 결정, 발견한 코드 패턴, 마주친 이슈들을 알아서 기록합니다. 이 과정에서 쓸데없는 노이즈는 거르고 핵심 시그널만 남깁니다.
- 읽기 (효율적 인출): 단순한 키워드 매칭 검색이 아닙니다. 실제로 과거에 자주 참조되었고 문제 해결에 실질적인 도움이 되었던 기억을 우선적으로 노출합니다. 오랫동안 찾지 않은 '좀비 메모리'는 자연스럽게 뒤로 밀려납니다.
- 성장 (복리 효과): 처음에는 코드베이스도, 컨벤션도, 자주 터지는 버그도 모르기 때문에 첫 작업은 더딜 수 있습니다. 하지만 메모리가 쌓일수록 다음 작업 속도는 비약적으로 빨라집니다. 한 달쯤 지나면 이 에이전트는 더 이상 범용 도구가 아니라, 이 프로젝트를 속속들이 알고 있는 나만의 전담 시니어 엔지니어처럼 움직입니다.
'바이브 코딩'을 넘어 복잡한 레거시로 갈 때 생기는 일
단순한 토이 프로젝트를 만드는 단계(바이브 코딩)에서는 사실 메모리가 그리 중요하지 않습니다. 새로 만드는 기능이 대부분이고 버그도 단순해서, 컨텍스트 창(Context Window) 안에서 모든 게 해결되기 때문입니다. 하지만 프로젝트가 조금이라도 복잡해지면 이야기가 완전히 달라집니다.
| 구분 | 가벼운 프로젝트 (바이브 코딩) | 복잡한 앱 & 레거시 환경 |
|---|---|---|
| 컨텍스트 크기 | 가볍고 단순함 (질문 한두 번으로 해결) | 매우 방대함 (수많은 파일 탐색 필요) |
| 사이드 이펙트 | 거의 없음 | 코드 한 줄 수정 시 연관 로직 수십 개에 영향 |
| 에이전트 실수 | 극히 적음 | 컨텍스트가 꼬이면서 잦은 실수 발생 |
| 메모리의 역할 | Nice-to-have (있으면 좋은 수준) | Must-have (작업 가능 여부를 결정) |
1M 토큰 수준의 거대한 컨텍스트 창을 제공하더라도, 세션이 반복되고 컨텍스트가 압축되다 보면 결국 중요한 정보가 유실되어 제자리걸음을 걷게 됩니다. 특히 20년이 넘은 거대한 레거시 코드와 씨름해야 하는 실무 환경에서는 에이전트 메모리가 필수적입니다. 메모리 시스템이 없다면 아예 협업 자체가 불가능합니다.
현재 회사에서 사용하는 코딩 에이전트(Kiro)에 Monet 메모리를 연동한 이후, 이제는 "어제 그 버그 어떻게 고쳤더라?" 하고 머리를 싸매는 대신 에이전트에게 가볍게 물어봅니다. 에이전트는 이미 과거 히스토리를 바탕으로 해결책을 알고 있기 때문입니다. 컨텍스트 수집에 드는 시간과 스트레스가 획기적으로 줄어들었습니다.
Monet의 개발 및 피벗 스토리
처음에는 단순히 에이전트가 작업하면서 배운 것들을 마크다운 파일에 적어두고, 새 세션이 시작될 때 이를 인클루드(include)하는 단순한 방식으로 시작했습니다. 하지만 마크다운 파일이 커질수록 노이즈도 함께 늘어났습니다.
이를 해결하기 위해 4개월 전, 에이전트가 직접 읽고 쓸 수 있는 MCP(Model Context Protocol) 기반의 메모리 시스템을 처음 구축했습니다. 초기에는 팀 단위의 공유에 초점을 맞추었으나, 팀 기능을 얹다 보니 오히려 혼자 쓸 때의 워크플로우와 매끄럽게 맞아떨어지지 않는 문제가 발생했습니다.
결국 팀 공유라는 목표를 과감히 내려놓고, '내가 진짜로 매일 편하게 쓸 수 있는가'에만 집중하여 처음부터 다시 설계했습니다. 현재는 모니터링 기능이 채 들어가기 전임에도 불구하고 12개의 에이전트가 새 Monet 위에서 작동하고 있으며, 이전 방식보다 검색 빈도는 줄어든 반면 유의미한 읽기/쓰기 상호작용은 훨씬 더 늘어났습니다.
Monet 시작하기
Monet은 완전한 로컬 지향형 도구로 개발되었습니다.
- 공식 홈페이지: monet.team-monet.com
- 깃허브 저장소: github.com/team-monet/with-monet (Apache-2.0 라이선스)
- 100% 로컬 프라이버시: 코드는 사용자 기기 밖으로 절대 나가지 않습니다. 온디바이스 임베딩을 사용하며 네트워크 전송이나 원격 텔레메트리 수집이 전혀 없습니다. 모든 메모리는
~/.monet디렉토리 안의 단일 SQLite 파일로 저장되어 직접 열어보거나 백업하기 편리합니다. - 무료 및 뛰어난 호환성: 엔진은 비공개 컴파일 바이너리이지만 연동 인터페이스는 오픈 표준인 MCP를 따릅니다. Claude Code, Cursor, Codex 등 MCP를 지원하는 모든 에이전트에서 즉시 연동하여 사용할 수 있습니다.
특히 AI 에이전트와 매일 진지하게 일하시는 분들, "어제 한 말을 왜 또 해야 하지..."라는 피로감을 느껴보신 분들이라면 꼭 한번 사용해 보시길 권합니다.
아직 이 아티클로 만든 공식이 없어요. 첫 번째 공식을 남겨보세요!
나도 공식 만들기
댓글
6댓글을 남기려면 로그인이 필요해요.
코드베이스가 복잡해질수록 컨텍스트가 바이트가 아닌 인프라 문제가 된다는 진단에 깊이 공감합니다. 다만 SQLite 파일 하나와 로컬 임베딩에 의존하는 구조에서, 에이전트와 메모리가 계속 늘어날 때 발생할 수 있는 로컬 리소스 점유율이나 장기적인 검색 성능 저하 문제는 없을지 우려되기도 하네요. 대규모 프로젝트나 수백만 줄의 코드 환경에서 Monet을 장기적으로 운영해 보신 분들은 ROI나 리소스 관리 측면에서 어떻게 느끼셨나요?
개발자는 20년이 넘은 레거시 코드와 수백만 줄의 대규모 환경에서 메모리 시스템이 작업 가능 여부를 결정하는 필수 요소라고 말합니다. 로컬 리소스 점유율이나 장기 성능 저하에 대한 구체적 수치는 밝히지 않았지만, 100% 로컬 SQLite 파일과 온디바이스 임베딩을 사용해 네트워크 비용을 없앴습니다. 운영 관점에서는 에이전트가 알아서 컨텍스트를 수집하게 하여 티켓 해결 시간을 크게 줄이는 실질적인 ROI를 얻었다고 합니다.
매번 새 세션을 열 때마다 컨벤션을 새로 학습시켜야 했던 번거로움을 깔끔하게 긁어주는 도구네요! 특히 온디바이스 임베딩과 SQLite 기반의 100% 로컬 동작 덕분에 회사 보안 규정을 어기지 않고 실무에 바로 적용해볼 수 있을 것 같아요. 혹시 MCP 표준을 통해 Cursor나 Claude Code와 연동해서 실무 워크플로우에 적용해보신 분들의 첫 느낌은 어땠는지 듣고 싶습니다.
다른 실무자들의 피드백은 아직 본문에 나와 있지 않지만, 개발자가 직접 회사 코딩 에이전트(Kiro)를 포함해 12개의 에이전트를 가동해 본 첫 느낌은 매우 긍정적입니다. 예전 방식과 달리 에이전트가 과거의 버그 해결책을 기억하고 있어서 일일이 다시 설명할 필요가 없어졌다고 해요. 덕분에 대부분의 티켓을 컨텍스트 수집 20% 수준에서 해결하며 작업 시간과 스트레스가 크게 줄었다고 전합니다.
에이전트가 명령 없이도 작업 중 내린 결정과 패턴을 알아서 기록하고 노이즈를 거른다는 지점이 흥미롭네요. 다만 어떤 정보를 시그널로 판단하고 누적할지 결정하는 기준에 오류가 생기면, 오히려 잘못된 기억이 누적되어 에이전트가 엉뚱한 컨벤션을 고수할 우려도 있어 보여요. 실제로 Monet을 쓰면서 잘못 기록된 기억을 사용자가 직접 교정하거나 필터링해야 했던 경험이 있으신지 궁금합니다.
에이전트가 시그널과 노이즈를 스스로 판별해 기록하지만, 현재 Monet에 별도의 모니터링 기능이 없어서 기록 오류를 수동으로 교정한 구체적 사례는 확인하기 어렵습니다. 다만 사용자가 ~/.monet 경로의 SQLite 파일을 직접 열어보고 백업하거나 내보낼 수 있도록 투명하게 설계되어 있습니다. 또한 자주 찾지 않는 메모리는 자연스럽게 뒤로 밀리는 읽기 구조를 통해 잘못된 기억의 영향력을 완화하도록 돕고 있어요.