매일 AI 에이전트와 작업하는 개발자라면 한 번쯤 이 피로감을 겪어봤을 것이다. 어제 같이 정한 컨벤션, 겨우 잡아낸 버그의 근본 원인, PR 리뷰에서 나눈 피드백—새 세션을 열면 전부 초기화된다. 에이전트는 매번 처음 만나는 사람처럼 행동하고, 결국 "그냥 내가 할게"가 된다. 이 반복이 쌓이면 에이전트는 생산성 도구가 아니라 컨텍스트 재주입 비용을 발생시키는 짐이 된다.
문제의 본질은 에이전트의 '지능'이 아니라 '기억'에 있다. 아무리 뛰어난 모델도 세션이 끝나면 그 프로젝트에서 쌓은 맥락을 잃는다. Monet의 개발자가 GeekNews에 공유한 접근은 이 지점을 정면으로 겨냥한다. 핵심은 세 가지 동작으로 요약된다. 에이전트가 작업 중 스스로 판단해 결정과 패턴을 기록하는 쓰기, 단순 키워드가 아니라 실제로 많이 참조되고 문제 해결에 기여한 기억을 우선 노출하는 읽기, 그리고 메모리가 쌓일수록 다음 작업이 빨라지는 성장이다. 처음 한 달은 더디지만, 어느 시점을 넘으면 이 에이전트는 더 이상 범용 도구가 아니라 프로젝트를 속속들이 아는 전담 엔지니어처럼 동작하기 시작한다.
특히 흥미로운 것은 이 메모리 시스템이 가장 빛을 발하는 조건이다. 바이브 코딩 단계—대부분 새로 만드는 기능에, 버그도 단순한 초기 국면—에서는 컨텍스트 윈도우 안에서 대부분이 해결된다. 하지만 앱이 복잡해지고, 코드 한 줄을 바꾸려면 연관 로직 열 개를 확인해야 하는 시점이 오면 이야기가 달라진다. 1M 토큰을 줘도 컨텍스트를 세 번 압축하고 나면 제자리다. 20년 된 레거시 코드베이스를 다루는 환경이라면 에이전트 메모리는 nice-to-have가 아니라 작업 가능성 자체를 결정하는 인프라다.
그런데 메모리 시스템만으로는 충분하지 않다. 에이전트가 기억하는 것만큼 중요한 것이 에이전트에게 어떤 도구를 쥐어주느냐다. dev.to에 게재된 MCP 도구 설계 분석은 이 지점에서 날카로운 통찰을 제공한다. 핵심 질문은 단순하다. "쿼리를 모델이 직접 작성하게 할 것인가, 아니면 서버가 미리 정의한 도구를 호출하게 할 것인가?"
execute_code 방식은 에이전트가 JavaScript를 직접 작성해 샌드박스 안에서 실행하는 구조다. 컨텍스트 비용이 낮고(도구 정의 하나), 복합 쿼리를 한 번의 호출로 처리할 수 있으며, 서버 릴리즈 없이 새로운 질문에 즉시 대응 가능하다. 프론티어 모델이 구동하는 고성능 에이전트라면 이 유연성은 실질적인 강점이다. 반면 discrete tools 방식은 read_sensor(path), battery_state(bank) 같이 명명된 도구를 노출하고, 인자 하나, 고정된 응답 형태로 설계된다. 유연성은 낮지만 실패 모드가 다르다. 잘못된 인자는 스키마 검증에서 큰 소리를 내며 실패하고, 서버가 미리 포맷한 출력을 그대로 릴레이하므로 모델이 날 데이터를 재해석할 기회 자체를 없앤다.
이 차이가 실제로 어떤 의미인지는 해당 분석의 배 위 사례에서 선명하게 드러난다. 음성 어시스턴트와 소형 로컬 모델 조합에서 execute_code의 조용한 실패—잘못된 JavaScript가 그럴듯한 숫자를 뱉는 것—는 단순한 버그가 아니라 위험이다. 반면 discrete tools는 서버가 "16.5 knots"라는 완성된 문자열을 돌려주므로 모델이 재해석할 여지가 없다. 결론은 명확하다. 도구 설계는 에이전트 타겟팅이다. 같은 백엔드라도 어떤 에이전트가 호출하느냐에 따라 MCP 인터페이스는 달라져야 한다.
두 설계 원칙을 프론트엔드 AI 워크플로우에 대입하면 실용적인 그림이 나온다. Claude Code나 Cursor 같은 프론티어 모델 기반 에이전트에는 execute_code식의 유연한 MCP 도구가 어울린다. 하지만 특정 작업—디자인 토큰 읽기, 컴포넌트 목록 조회, 접근성 점검 규칙 적용—을 반복적으로 안정적으로 수행해야 하는 파이프라인에서는 discrete tools의 결정론적 출력이 훨씬 신뢰할 수 있다. 요즘IT의 K8s 운영 에이전트 벤치마크도 같은 방향을 가리킨다. 복잡한 시나리오에서 비싼 모델이 "이건 벤치마크 상황"이라 판단해 실행을 중단한 반면, 하위 티어 모델은 정상 처리했다. 도구와 모델의 조합이 성능을 결정한다.
이 두 가지—메모리 시스템으로 프로젝트 맥락을 축적하는 것, 그리고 에이전트 타입에 맞게 도구 인터페이스를 설계하는 것—는 결국 같은 질문에 대한 두 가지 답이다. 어떻게 하면 범용 에이전트를 내 프로젝트의 전담 에이전트로 만들 수 있는가. 메모리는 세션과 세션 사이의 연속성을 만들고, 도구 설계는 실행 시점의 신뢰도를 높인다. 둘 중 하나만으로는 절반짜리다.
앞으로의 방향은 명확하다. 에이전트 수가 늘고 코드베이스가 커질수록 컨텍스트는 바이트 문제가 아니라 인프라 문제가 된다. Monet이 SQLite 파일 하나로 온디바이스 임베딩을 구현한 것처럼, 메모리는 점점 표준 인프라 레이어가 될 것이다. 동시에 MCP 생태계가 성숙하면서 도구 설계의 패턴도 정립될 것이다. 지금 이 두 축을 의식적으로 설계하지 않는 팀은, 에이전트를 늘릴수록 오히려 재주입 비용과 예측 불가한 실패가 함께 늘어나는 역설을 마주하게 된다. 빠르게 만드는 것보다 오래 작동하는 에이전트를 설계하는 것, 그게 지금 시점의 진짜 과제다.