Mole, 터미널 리서치 에이전트가 예산과 근거를 먼저 묻다

딥리서치 에이전트가 CLI로 내려왔다

GitHub에 공개된 Mole는 터미널에서 쓰는 딥리서치 에이전트다. README는 이 도구를 enforced budget, verified quotes, local data privacy boundary를 가진 Go 단일 바이너리로 설명한다. 사용자가 질문을 던지면 Mole은 질문을 분해하고, 검색하고, 출처를 읽고, claim을 뽑고, 각 claim이 원문 quote로 뒷받침되는지 확인하고, 출처 간 모순을 찾은 뒤 인용이 붙은 답을 쓴다.

이 설명에서 중요한 단어는 답변이 아니라 경계다. 대부분의 웹 리서치 챗봇은 좋은 답을 내놓아도 비용, 근거, 검색 과정, 로컬 데이터 반출이 불투명하다. Mole은 --usd 0.50처럼 달러 예산을 걸면 그 한도를 넘지 않도록 모델 호출 전에 예약하고 호출 후 정산한다. README는 테스트 코퍼스에서 overshoot가 0%였다고 주장한다.

AI 탐지기 불신, 출처 증명의 시장이 열린다가 결과물의 출처 문제를 다뤘다면, Mole은 리서치 과정의 출처 문제를 다룬다. HyperProbe, 온콜 에이전트가 증거를 잡는 방식, Prime Agent, 스스로 고치는 하네스의 등장와 함께 보면 에이전트 도구의 경쟁 축이 대화 능력에서 실행 증거로 옮겨가고 있다.

예산은 추정값이 아니라 제약이어야 한다

Mole의 첫 번째 차별점은 비용을 사후 리포트가 아니라 실행 제약으로 다룬다는 점이다. 모델 호출은 토큰과 검색 API 비용을 만들고, 리서치 에이전트는 중간 탐색이 길어질수록 비용이 커진다. 일반 챗 UI에서는 사용자가 그 흐름을 거의 통제하지 못한다. Mole은 SQLite ledger와 non-negative constraint로 예산을 데이터베이스 수준에서 강제한다고 설명한다.

두 번째는 quote 검증이다. Mole은 claim이 원문에서 verbatim quote를 갖지 못하면 extraction 단계에서 버린다. 살아남은 claim도 이후 다시 소스와 대조할 수 있고, 지원되지 않는 claim은 조용히 사라지지 않고 report에 표시된다. 이는 LLM이 그럴듯한 요약을 만드는 문제를 완전히 없애지는 못하지만, 적어도 주장의 단위와 근거를 분리한다.

MCP와 toolkit mode가 말하는 에이전트 생태계

Mole은 MCP 서버로도 동작한다. Model Context Protocol은 외부 도구와 데이터를 모델 클라이언트에 연결하는 표준으로 자리 잡고 있고, Mole은 mole serve와 mole-mcp를 통해 코딩 에이전트가 리서치 기능을 호출하게 한다. 기본 모드는 Mole이 모델을 소유하지만, toolkit mode에서는 사용 중인 코딩 에이전트의 모델이 reasoning을 맡고 Mole은 검색, fetch, quote 검증, claim 관리, local aggregate 같은 결정적 도구를 제공한다.

이 구조는 실용적이다. 많은 개발자는 이미 Claude Code, Codex, Qwen Code 같은 구독형 도구를 쓰고 있다. 리서치 에이전트가 또 다른 모델 비용을 요구하면 도입 장벽이 생긴다. 반대로 Mole이 검증과 데이터 경계 기능을 툴로 제공하면, 기존 에이전트의 reasoning과 결합하기 쉽다. 검색 제공자는 Tavily나 Brave Search API를 쓸 수 있고, LLM은 Anthropic 또는 OpenAI-compatible endpoint를 지원한다.

로컬 데이터 경계는 기업 리서치의 핵심이다

Mole의 로컬 데이터 모드는 흥미롭다. CSV나 폴더를 연결하면 모델이 원본 행을 보지 않고 hypothesis template과 column name을 고른다. Mole이 SQL을 렌더링해 실행하고, 모델에는 count, mean, test result, 최소 다섯 레코드 이상을 덮는 bucket 같은 집계만 돌아간다. mole crossings는 무엇이 머신 밖으로 나갔는지 보여준다.

이 방식은 완벽한 개인정보 보호는 아니지만 좋은 방향이다. 기업의 사내 분석 에이전트가 원본 고객 행을 외부 모델로 보내지 않고도 질문에 답하려면 이런 데이터 경계가 필요하다. Nine PBS 소송, AI 시대 데이터 보관권의 경고가 데이터 접근권을 다뤘다면, Mole은 데이터 반출권을 작게 쪼갠 사례다.

한국 기업은 Mole을 제품 자체보다 설계 패턴으로 볼 필요가 있다. 에이전트에는 예산, 근거, 반출 내역, 재현 가능한 세션, 실패 기록이 필요하다. 이 요소가 없으면 사내 AI 리서치는 빠르지만 감사하기 어려운 그림자 업무가 된다.

자주 묻는 질문

Q1: Mole은 웹 검색 챗봇과 무엇이 다른가요?

A: 답변을 만드는 것보다 예산, quote 검증, claim 관리, 로컬 데이터 경계를 명시적으로 다룬다는 점이 다르다.

Q2: MCP가 왜 중요한가요?

A: 코딩 에이전트가 Mole의 검색과 검증 도구를 자기 워크플로 안에서 호출할 수 있어 리서치가 개발 루프에 들어온다.

Q3: 로컬 데이터가 완전히 안전한가요?

A: 원본 행을 모델에 보내지 않는 구조는 큰 개선이다. 다만 집계 결과도 민감할 수 있으므로 최소 bucket, 로그, 접근권한을 함께 관리해야 한다.

Q4: 기업에서 바로 쓸 수 있나요?

A: 파일 기반 리서치나 개발팀 조사에는 빠르게 실험할 수 있다. 전사 도입에는 검색 제공자, 모델 제공자, 보안 감사 절차 검토가 필요하다.

Q5: 가장 배워야 할 설계 원칙은 무엇인가요?

A: 에이전트 결과보다 에이전트가 무엇을 읽고 얼마를 쓰고 어떤 근거로 주장했는지를 먼저 기록해야 한다.