집현전 Agent: 웹 연구 흐름을 MCP 도구로 확장하기

논문을 읽는 일은 이제 브라우저 안에서만 끝나지 않는다. 검색은 웹에서 시작하지만, 정리는 Obsidian이나 Notion으로 넘어가고, 코드 실험은 로컬 터미널에서 이어지며, 초안 작성은 Claude Code나 데스크톱 에이전트와 함께 진행된다. 연구자의 작업 공간은 이미 여러 도구로 나뉘어 있다.

문제는 이 도구들이 같은 연구 맥락을 공유하지 못한다는 점이다. 집현전 안에는 검색한 논문, PDF 읽기 흐름, 북마크, 딥리뷰 결과, 커리큘럼, 추천 논문이 연결되어 있다. 그런데 외부 에이전트는 사용자가 지금 어떤 논문을 읽고 있는지, 어떤 논문을 저장했는지, 어떤 추천을 받았는지 알지 못한다.

집현전 Agent는 이 단절을 줄이기 위한 설계다. 이 글은 Agent Key 버튼 자체보다 그 버튼이 열어 주는 경계를 다룬다. 핵심은 세 가지다. 사용자가 로그인 맥락을 외부 실행 환경에 명시적으로 넘기는 인증 흐름, /api/version으로 서버 기능을 확인하는 기능 협상, 그리고 paper_id 중심의 작은 API 단위다. 여기서 말하는 Agent Key는 별도 발급된 장기 API Key가 아니라, 현재 로그인 세션의 JWT를 사용자가 명시적으로 복사해 로컬 MCP 실행 환경에 전달하는 최소 연결 방식이다.

---

왜 브라우저 밖에서도 집현전 맥락이 필요한가

집현전의 기존 흐름은 웹 앱 안에서는 자연스럽다.

1. 검색 탭에서 논문을 찾는다.
2. PDF를 열어 읽는다.
3. 딥리뷰나 오토하이라이트를 실행한다.
4. 북마크하거나 커리큘럼에 넣는다.
5. 추천 논문을 확인하고 다음 읽을 대상을 고른다.

하지만 실제 연구자의 하루는 여기서 끝나지 않는다. 논문을 읽은 뒤에는 관련 연구를 더 찾아야 하고, 코드 실험을 해야 하고, 리뷰 코멘트를 정리해야 하며, 때로는 블로그나 보고서 초안으로 바꿔야 한다. 이 단계에서는 웹 화면보다 에이전트가 호출할 수 있는 도구 인터페이스가 더 자연스럽다.

예를 들어 사용자가 Claude Code에게 이렇게 요청한다고 생각해보자.

“집현전에서 북마크한 논문 중 최근 추천 논문과 연결되는 것만 골라서 읽기 순서를 만들어줘.”

이 요청이 동작하려면 에이전트가 집현전의 사용자 맥락에 접근할 수 있어야 한다. 브라우저 화면을 흉내 내는 방식으로는 부족하다. 검색, 단일 논문 조회, 북마크, 추천, 딥리뷰 같은 기능이 외부 실행 환경에서도 작고 예측 가능한 도구 단위로 열려 있어야 한다.

현재 구현 범위 먼저 보기
이 글에서 말하는 집현전 Agent는 완성된 MCP 서버 전체가 아니다. 현재 구현된 것은 세 가지다.

1. Web UI에서 로그인 토큰을 Agent Key로 복사하는 UX
2. 서버가 /api/version으로 capability 목록을 제공하는 API 표면
3. 에이전트 후속 작업을 위한 /api/papers/{paper_id} 단일 논문 조회
   이 기반 위에서 별도 Jiphyeonjeon MCP Agent가 서버 capability를 읽고, 지원되는 기능만 MCP 도구로 등록하는 구조를 목표로 한다.

용어	이 글에서의 의미
Agent Key	현재 로그인 JWT를 로컬 Agent 환경에 전달하는 임시 연결 방식
capability	서버가 제공 가능한 기능군을 알리는 가벼운 신호
MCP Host	Claude Desktop, Claude Code 같은 외부 도구 실행 환경
MCP Agent	집현전 API를 MCP 도구로 감싸는 후속 어댑터
resolver	추천·북마크·검색 결과의 식별자를 논문 조회용 ID로 맞추는 계층

---

세 경계: Web UI, 서버 API, MCP Agent

집현전 Agent 연동은 “사람이 보는 화면”, “서버가 제공하는 API”, “외부 에이전트가 호출하는 도구”의 세 경계로 나눠 볼 수 있다. Figure 1이 이 세 실행 경계를 보여준다면, Figure 2는 그중 MCP Agent가 맡을 내부 책임을 목표 구조로 분해한다.

사용자
  │
  ├─ 집현전 Web UI
  │    ├─ 논문 검색 / PDF 보기 / 북마크 / 추천 논문
  │    └─ My Page의 Agent Key 버튼
  │
  ├─ MCP 호스트
  │    ├─ Claude Desktop
  │    ├─ Claude Code
  │    └─ 로컬 에이전트 실행 환경
  │
  └─ Jiphyeonjeon MCP Agent
       ├─ JIPHYEONJEON_TOKEN으로 사용자 맥락 전달
       ├─ GET /api/version으로 서버 기능 확인
       └─ 서버 capability에 맞춰 도구 등록
            ├─ search
            ├─ papers
            ├─ bookmarks
            ├─ recommendations
            ├─ deep_review
            └─ curriculum ...

위의 세 경계를 MCP Agent 내부로 당겨 보면, 에이전트는 하나의 거대한 자동화 함수가 아니라 여러 작은 책임을 가진 레이어로 나뉜다. 토큰과 서버 주소를 읽는 시작 설정, /api/version을 확인하는 기능 협상기, 실제로 노출할 도구를 고르는 도구 등록부, 사용자 맥락을 붙이는 인증 컨텍스트, paper_id 계열 식별자를 해석하는 resolver, 그리고 서버 API 호출과 오류를 정리하는 어댑터가 분리된다. 이 분해가 필요한 이유는 한 번의 자연어 요청이 기능 확인, 인증, 식별자 해석, API 호출, 오류 설명으로 나뉘기 때문이다.

Claude Desktop이나 Claude Code는 MCP 호스트다. 목표 구조에서 Jiphyeonjeon MCP Agent는 그 호스트 안에서 실행되어 집현전 API를 호출하는 중간 어댑터가 된다. 현재 구현된 것은 Web UI의 Agent Key 복사 흐름과 FastAPI 서버의 MCP-friendly API 표면이다. 실제 Jiphyeonjeon MCP Agent, 도구 스키마, 동적 도구 등록 로직은 별도 구현체 또는 후속 구성요소로 다뤄야 한다.

이 구분이 중요하다. 글의 목표는 “이미 완성된 에이전트 플랫폼”을 과장하는 것이 아니라, 외부 에이전트가 집현전 기능을 안전하게 발견하고 호출할 수 있는 서버/API/인증 경계를 먼저 마련하는 것이다.

---

한 번의 Agent 요청이 처리되는 흐름

작은 도구 단위가 왜 중요한지는 실제 요청 흐름으로 보면 더 분명하다.

사용자 요청:
“내 추천 논문 중 북마크한 논문과 연결되는 것만 골라 읽기 순서를 만들어줘.”

가능한 처리 흐름:
1. MCP Agent가 `/api/version`을 호출해 `recommendations`, `bookmarks`, `papers` capability를 확인한다.
2. 사용자가 전달한 `JIPHYEONJEON_TOKEN`으로 추천 논문 목록을 가져온다.
3. 북마크 목록을 가져와 추천 후보와 겹치는 논문을 찾는다.
4. MCP Agent 쪽 resolver가 후보의 `paper_id`, arXiv ID, DOI, `doc_id`, title/year를 가능한 범위에서 정규화한다. 현재 서버 조회는 `doc_id` 기반 exact lookup이므로 DOI/alias fallback은 후속 resolver 책임으로 남긴다.
5. `/api/papers/{paper_id}`로 메타데이터를 확인한다.
6. Claude가 논문 메타데이터와 사용자 맥락을 바탕으로 읽기 순서를 제안한다.

이 흐름에는 세 가지 설계 요소가 모두 들어 있다. /api/version은 호출 가능한 기능군을 좁히고, Agent Key는 사용자 맥락이 필요한 도구 호출에 권한을 전달하며, paper_id 계열 식별자는 추천·북마크·논문 조회를 같은 대상으로 연결한다.

실패 경로도 분리된다. 서버가 bookmarks capability를 제공하지 않으면 북마크 기반 계획을 만들 수 없다고 설명하면 된다. 추천 항목의 식별자를 논문 DB의 doc_id로 해석할 수 없으면 resolver 단계의 실패로 구분할 수 있다. 도구가 작을수록 모델은 실패한 부분을 더 정확히 설명할 수 있다.

---

기능 협상: 서버가 지원하는 도구만 연다

일반적인 API 클라이언트는 “이 엔드포인트가 있을 것”이라고 가정하고 호출한다. 에이전트 도구는 조금 다르다. 사용자가 자연어로 요청하면 모델은 등록된 도구 목록을 보고 어떤 도구를 쓸지 결정한다. 존재하지 않는 기능을 도구로 노출하면, 모델은 실패할 도구를 자신 있게 호출하게 된다.

그래서 집현전 MCP Agent의 첫 단계는 기능 협상이다. 여기서 capability는 MCP 도구 스키마가 아니라 서버가 제공할 수 있는 기능군을 알려주는 가벼운 availability signal이다. MCP Agent는 이 신호를 출발점으로 삼되, 실제 도구 이름, 입력 스키마, 인증 필요 여부, 실패 처리 규칙은 별도로 정의해야 한다.

1. MCP Agent가 시작된다.
2. 집현전 서버의 GET /api/version을 호출한다.
3. 응답의 capabilities를 읽는다.
4. 서버가 지원하는 기능만 도구로 등록한다.
5. 오래된 서버가 /api/version을 지원하지 않으면 baseline 도구 세트로 후퇴한다.

{
  "version": "1.1.0",
  "mcp_min_client": "0.1.0",
  "capabilities": [
    "search",
    "papers",
    "deep_review",
    "bookmarks",
    "curriculum",
    "explore",
    "autofigure",
    "blog",
    "recommendations"
  ]
}

현재 /api/version의 capability는 완전한 계약이 아니다. 도구 스키마나 권한 범위까지 설명하지 않고, 서버가 어떤 기능군을 제공할 수 있는지만 알려준다. 실제 도구 스키마, 인증 요구사항, 클라이언트 버전 강제, 실행 준비 상태 판단은 MCP Agent 쪽 책임이다.

여기서 말하는 안전함은 절대적인 보안 보장이 아니다. 서버가 지원하지 않는 기능을 모델이 도구로 호출하지 않도록, 시작 시점에 도구 목록을 실제 서버 능력에 맞추는 안전장치다.

---

도구 설계: 만능 자동화보다 작은 기능 단위

기능 협상이 “어떤 도구를 켤 것인가”의 문제라면, 도구 설계는 “각 도구가 얼마나 작고 예측 가능해야 하는가”의 문제다.

집현전 Agent의 방향은 “에이전트가 모든 연구 과정을 한 번에 처리한다”가 아니다. 더 정확히는, 집현전의 기존 기능을 작고 확인 가능한 도구 단위로 나누고, 서버가 지원한다고 확인한 기능만 외부 에이전트에 노출하는 것이다.

capability	에이전트 도구 관점의 의미	인증 필요 여부
search	자연어 주제를 논문 검색 요청으로 바꾼다.	public / optional
papers	특정 논문의 메타데이터를 가져온다.	public
bookmarks	사용자의 저장 논문 흐름과 연결한다.	required
recommendations	최신 추천 artifact를 다음 행동 후보로 사용한다.	required
deep_review	선택한 논문 묶음에 대해 구조화된 리뷰를 요청한다.	경로별 상이, 사용자 맥락 필요
curriculum	학습 순서나 읽기 계획과 연결한다.	public / optional / required 혼재
blog	연구 결과를 공개 글감으로 전환하는 흐름과 연결한다.	public / admin 경로 분리
autofigure	리뷰/포스터/블로그에 들어갈 그림 생성 흐름과 연결한다.	경로별 상이

이 표에서 중요한 것은 capability와 인증 요구사항이 1:1로 단순히 맞물리지 않는다는 점이다. 집현전 API는 public, optional-auth, required-auth 표면이 섞여 있다. MCP Agent는 capability 단위뿐 아니라 도구 단위로 인증 요구사항을 별도 선언해야 한다.

에이전트 설계에서 중요한 것은 거대한 만능 함수가 아니라, 잘 정의된 작은 도구들의 조합이다. 작은 도구는 실패 원인을 분리하기 쉽고, 모델이 다음 행동을 설명하기도 쉽다.

---

paper_id: 검색, 추천, 북마크를 잇는 연결점

MCP Agent에는 전체 논문 목록보다 더 자주 필요한 접근 패턴이 있다. 바로 “이 논문 하나를 정확히 가져오기”다.

추천 논문 목록에서 특정 논문을 북마크하거나, 검색 결과 중 하나를 딥리뷰로 넘기거나, 커리큘럼의 한 항목을 PDF 보기 흐름과 연결하려면 먼저 논문 메타데이터를 안정적으로 확인해야 한다. 전체 목록을 훑는 방식은 느리고 불필요하며, 에이전트 도구로도 좋지 않다.

그래서 GET /api/papers/{paper_id} 엔드포인트가 추가되었다. 현재 구현은 로컬 SQLite의 doc_id를 기준으로 단일 논문을 exact lookup한다. 논문이 없으면 404를 반환하고, 조회 중 서버 문제가 있으면 500으로 구분한다.

다만 추천/검색/북마크 사이의 paper_id는 아직 완전히 통일된 canonical identifier가 아니다. 추천 항목은 paper_id, arXiv ID, DOI, 내부 ID, doc_id, title/year 같은 여러 식별자 후보를 가질 수 있다. /api/papers/{paper_id}가 현재 SQLite doc_id exact lookup이라면, MCP Agent는 후속 도구 호출 전에 별도 resolver로 식별자를 정규화해야 한다.

웹 UI에서는 사용자가 카드를 클릭해 논문을 연다. 에이전트 세계에서는 같은 역할을 안정적인 식별자가 한다. /api/papers/{paper_id}는 그 연결점을 만들기 위한 시작점이고, 향후 DOI column fallback이나 alias lookup은 resolver 계층에서 확장해야 한다.

---

인증 경계: Agent Key는 전용 API Key가 아니다

MCP Agent가 사용자 맥락이 있는 집현전 API를 호출하려면 인증 정보가 필요하다. 브라우저 안에서는 로그인 세션이 localStorage에 있지만, Claude Desktop이나 Claude Code는 브라우저 탭이 아니다. 외부 에이전트가 브라우저의 localStorage를 직접 읽을 수도 없고, 그렇게 설계해서도 안 된다.

여기서 중요한 것은 토큰 복사 자체가 아니라 권한의 경계를 명시적으로 넘긴다는 점이다. 브라우저 안의 로그인 세션은 Web UI의 권한이고, MCP 호스트는 별도의 실행 환경이다. Agent Key는 이 둘을 자동으로 섞지 않고, 사용자가 의식적으로 연결하도록 만든 최소한의 권한 전달 장치다.

그래서 My Page에 Agent Key 버튼을 추가했다.

버튼의 역할은 제한적이고 명확하다. 현재 로그인 세션의 access_token을 클립보드에 복사해, 사용자가 MCP 호스트 설정의 JIPHYEONJEON_TOKEN 환경 변수로 직접 옮길 수 있게 한다. 별도 키 발급, 권한 범위 제한, revoke UI를 제공하는 단계는 아직 아니다.

집현전 로그인
  → My Page 이동
  → Agent Key 클릭
  → JIPHYEONJEON_TOKEN에 붙여넣기
  → MCP Agent가 인증된 사용자 맥락으로 집현전 API 호출

주의: 현재 Agent Key는 전용 API Key가 아니라 로그인 JWT다. MCP 호스트 설정, 터미널 로그, 모델 프롬프트, 도구 출력에 노출되면 사용자 권한이 그대로 노출될 수 있다. 권한 범위 제한, 클라이언트별 revoke, 감사 로그가 아직 없으므로 신뢰하는 로컬 환경에서만 사용해야 한다.

이 구분은 보안과 UX 양쪽에서 중요하다.

구분	현재 Agent Key	향후 전용 Agent Token
발급 방식	현재 로그인 토큰 복사	별도 토큰 발급
수명	로그인 토큰 수명에 따름	별도 만료 정책 가능
권한 범위	현재 사용자 권한	scope 기반 제한 가능
폐기	세션/토큰 정책에 의존	UI에서 revoke 가능
사용 이력	별도 추적 없음	클라이언트별 감사 로그 가능

Agent token이 필요한 것은 사용자 맥락이 있는 도구다. bookmarks, recommendations, curriculum progress/write, review status/report처럼 사용자 상태를 읽거나 쓰는 기능은 인증이 필요하다. 반대로 /api/version, 일부 search/papers/blog/autofigure 계열은 현재 공개 또는 선택 인증 API 표면이므로, MCP Agent는 도구별 인증 요구사항을 별도로 알아야 한다.

---

민감한 토큰을 복사할 때 지킨 원칙

Agent Key 버튼은 작지만 민감한 값을 다룬다. 그래서 구현에서는 편의보다 보수성을 우선했다.

AgentKeyButton은 먼저 navigator.clipboard.writeText()를 사용한다. 최신 브라우저에서는 이 경로가 가장 자연스럽다. 실패하거나 지원하지 않으면 임시 textarea를 만들고 document.execCommand('copy')로 대체 경로를 사용한다.

대체 경로에서는 JWT가 임시 DOM 노드에 들어가기 때문에, try/finally로 감싸서 실패하더라도 반드시 제거한다. 토큰 값을 콘솔에 출력하지 않고, 복사 성공 여부만 버튼 라벨로 보여준다.

클릭 직후에는 Copied! 또는 Copy failed 피드백이 잠시 표시된다. 이 피드백이 보이는 동안에는 busyRef로 중복 클릭을 막는다. 빠르게 여러 번 누른다고 복사 작업이 중첩되지 않는다.

UI 위치도 의도적으로 작게 잡았다. Agent Key는 My Page의 기존 mypage-nav-btn 톤을 따르지만, mypage-nav-btn-active는 쓰지 않는다. 추천 알림 버튼 옆에 놓되, 논문/커리큘럼/북마크처럼 화면을 전환하는 탭으로 보이지 않게 했다.

---

추천 논문을 다음 행동 후보로 바꾸기

최근 집현전에는 추천 논문 알림이 추가되었다. 처음에는 알림에서 추천 논문을 보여주는 데 집중했지만, 에이전트 관점에서는 추천이 “다음에 검토할 후보군”이 된다.

현재 recommendations capability는 on-demand 추천 생성이나 읽음 상태 관리가 아니라, 인증된 사용자의 최신 추천 artifact를 후보 목록으로 읽는 기능이다. UI에서는 추천 논문 후보를 보여주고, 가능한 경우 PDF 보기, 제목 기반 관련 검색, 원문 열기로 이어진다. 추천 artifact가 없거나 오래된 경우, MCP 도구는 즉석에서 추천을 생성했다고 가장하지 않고 “현재 사용할 추천 후보가 없다”는 상태를 반환해야 한다.

MCP Agent가 recommendations capability를 도구로 구현하면, 이 목록을 후속 papers, bookmarks, deep_review 호출의 후보로 사용할 수 있다. 다만 이 신호가 실제 읽기 계획, 북마크, 딥리뷰로 이어지려면 각 후속 기능이 별도 도구로 안정적으로 연결되어야 한다.

추천 논문은 단순 알림 목록이 아니라 에이전트가 다음 행동을 고를 때 참고할 수 있는 입력이다. 하지만 추천 자체가 곧 읽기 계획은 아니다. 읽기 계획은 추천, 북마크, 논문 메타데이터, 사용자 요청을 조합하는 별도 도구 흐름에서 만들어진다.

---

현재 구현 범위와 주장하지 않는 것

이번 단계에서 완성한 것은 MCP Agent 전체가 아니라, 그 Agent가 붙을 수 있는 서버/API/UX의 연결면이다.

구분	현재 구현	아직 아님
인증	로그인 JWT를 Agent Key로 복사	전용 Agent Token 발급
권한 관리	현재 사용자 권한 그대로 사용	scope 제한, rate limit, revoke UI
기능 발견	/api/version capability 목록	도구 스키마 자동 배포, 권한 범위 협상
논문 조회	doc_id 기반 /api/papers/{paper_id} exact lookup	DOI/alias fallback, 통합 resolver 완성
추천 논문	최신 추천 artifact 후보 목록 조회	on-demand 추천 생성, 읽음 상태 관리
MCP 연동	서버/API 표면과 Agent Key UX 준비	전체 Jiphyeonjeon MCP Agent 구현
운영 투명성	별도 사용 이력 없음	클라이언트별 감사 로그

따라서 현재 구현만으로 다음을 주장하면 안 된다.

• “집현전이 전용 API Key를 발급한다”
• “토큰 권한 범위를 제한한다”
• “토큰 사용 이력을 추적한다”
• “모든 집현전 기능이 이미 MCP 도구로 완전히 구현되어 있다”
• “/api/version이 도구 스키마, 권한 범위, version enforcement까지 제공한다”
• “/api/papers/{paper_id}가 DOI column이나 alias lookup까지 보장한다”

좋은 블로그 글은 구현보다 앞서 나가면 안 된다. 이번 글은 “완성된 에이전트 플랫폼”이 아니라 “집현전 기능을 에이전트 도구로 열기 위한 기반 구축”으로 설명하는 편이 정확하다.

---

앞으로의 구축 방향

다음 단계는 Agent Key 버튼을 더 예쁘게 만드는 것이 아니라, 에이전트 연동의 수명주기를 분리하는 것이다.

우선 전용 Agent Token이 필요하다. 현재는 로그인 JWT를 복사하지만, 장기적으로는 “Claude Desktop용 토큰”, “로컬 실험용 토큰”처럼 클라이언트별로 이름을 붙이고, 만료일과 권한 범위를 따로 관리해야 한다.

두 번째는 scope, 즉 권한 범위다. 에이전트가 모든 권한을 가질 필요는 없다. 어떤 토큰은 검색과 논문 조회만 허용하고, 어떤 토큰은 북마크 쓰기까지 허용할 수 있다. 딥리뷰처럼 비용이 발생하는 기능은 별도 권한 범위나 rate limit이 필요할 수 있다.

세 번째는 감사 로그다. 연구 에이전트가 언제 어떤 논문을 조회했고, 어떤 기능을 호출했는지 사용자가 볼 수 있어야 한다. 에이전트가 편해질수록, 사용자는 더 많은 투명성을 요구하게 된다.

마지막은 도구 UX다. 에이전트에게 좋은 API는 사람에게 좋은 UI와 다르다. 사람은 카드와 버튼을 보지만, 에이전트는 명확한 스키마, 안정적인 ID, 예측 가능한 에러 메시지, 작은 도구 단위를 필요로 한다. 집현전 Agent 구축은 이 두 인터페이스를 함께 다듬는 작업이다.

---

이번 설계에서 유지한 원칙

이번 Agent 설계는 세 가지 원칙을 따른다.

1. 서버가 지원하는 기능만 도구로 노출한다.
   /api/version의 capability 목록으로 모델이 존재하지 않는 기능을 호출하지 않게 한다. 다만 현재 capability는 coarse availability flag이며, 도구 스키마와 권한 범위는 별도 설계가 필요하다.

2. 에이전트 도구는 작고 검증 가능한 단위로 나눈다.
   검색, 단일 논문 조회, 북마크, 추천, 딥리뷰를 하나의 만능 함수로 묶지 않고 조합 가능한 도구로 둔다.

3. 권한 전달은 명시적으로 만든다.
   Agent Key는 브라우저 세션과 외부 MCP 호스트 사이의 경계를 사용자가 직접 넘기도록 하는 최소 연결면이다. 현재는 전용 API Key가 아니라 로그인 JWT라는 점을 숨기지 않는다.

---

집현전이 향하는 방향

집현전은 검색, PDF 보기, 딥리뷰, 북마크, 커리큘럼, 추천 논문을 하나의 연구 흐름으로 묶어 왔다. 이제 다음 단계는 그 흐름을 웹 밖에서도 참조하고 호출할 수 있게 만드는 것이다.

집현전 Agent의 목표는 모델을 더 화려하게 보이게 만드는 것이 아니다. 연구자가 이미 쌓아 둔 검색, 북마크, 추천, 딥리뷰의 맥락을 에이전트가 안전하게 이어받도록 만드는 것이다.

Agent Key, /api/version, /api/papers/{paper_id}는 작아 보이지만 같은 방향을 가리킨다. 현재 구현은 서버 API 표면과 인증 전달 경계를 다지는 단계이고, 그 위에 별도 MCP Agent가 도구 계층을 얹을 수 있다.

좋은 에이전트는 혼자 똑똑한 모델이 아니다. 좋은 도구에 안정적으로 연결된 모델이다. 이번 구현의 핵심은 Agent Key 버튼 하나가 아니라, 집현전의 연구 기능을 외부 에이전트가 발견하고 호출할 수 있는 도구 표면을 만들기 시작했다는 점이다.