AIClaw 3.7.6, 웹 검색 출처를 도구 로그 너머로 유지하는 방법

웹 검색 도구는 유용한 페이지를 반환할 수 있지만, 최종 답변을 받은 독자가 이를 검사할 편리한 방법이 없는 경우가 있습니다. 실행 로그를 확장하는 것은 가능하지만, 원하는 것이 결과 뒤에 있는 원본 페이지일 경우 읽기 경험이 좋지 않습니다.

AIClaw 3.7.6은 10월 10일에 출시되었으며, 데스크톱 채팅에 턴(turn)-레벨 출처 목록을 추가했습니다. 이는 최신 개발 코드를 기반으로 한 제안이라기보다는 해당 릴리스에 포함된 기능입니다.

이 변경 사항은 기존의 구조화된 검색 결과에 구축됩니다. 작은 UI 계약을 추가하고, 소스 데이터를 실행(execution), 저장(storage), 히스토리 재생(history replay) 전반에 걸쳐 전달합니다.

독자가 보는 것

검색 출처가 있는 답변에는 답변 아래에 간결한 출처 개수 버튼이 표시됩니다. 이를 열면 오른쪽 패널에 각 페이지의 도메인, 제목 및 검색 스니펫이 표시됩니다. 출처 카드를 클릭하면 시스템 브라우저에서 원본 URL을 엽니다.

같은 턴 내 여러 검색은 하나의 목록을 공유합니다. URL은 프래그먼트 식별자(fragment identifiers)를 제거하여 중복 제거되므로, 같은 페이지의 서로 다른 앵커를 가리키는 두 개의 결과가 개수를 부풀리지 않습니다. 서로 다른 쿼리 문자열(query strings)은 여전히 별개로 유지됩니다. 이는 일반적인 canonical-URL resolver가 아닙니다.

출처 메타데이터가 없는 평범한 답변에는 빈 출처 섹션이 표시되지 않습니다. 이 패널은 Escape 키, 배경 클릭, 키보드 포커스 포함(keyboard focus containment)을 지원하며, 닫힐 때 트리거로 초점을 반환합니다.

실행 시점에 출처 수집하기

유용한 부분은 데이터가 어디서 오는지입니다. 렌더러는 어시스턴트의 단어를 스캔하여 보이는 모든 링크를 검색 출처로 변환하지 않습니다.

web_search라는 이름의 성공적인 MCP 도구는 예상되는 검색-응답 구조, 즉 쿼리(query), 제공자(provider), 그리고 제목, URL, 스니펫을 포함하는 결과 항목에 대해 확인됩니다. 유효한 항목은 로컬 UI 메타데이터가 됩니다.

애플리케이션의 경로는 다음과 같습니다:

Successful search response
  → source collector for the outer tool call
  → completed tool item and saved tool message
...

소스(Sources)를 저장하는 collector는 Go 언어로 작성되었습니다. 이는 호출의 컨텍스트에 연결되며, 세션 전체에서 변경 가능한 리스트에 저장되는 대신 뮤텍스(mutex)로 보호됩니다. 따라서 별도의 도구 호출은 개별적인 소스 컬렉션을 가지며, 중첩된 호출은 외부 호출의 컬렉션을 공유할 수 있습니다.

저장된 Sources 필드는 모델 요청 빌더에서 생략됩니다. 이는 UI 메타데이터의 또 다른 복사본을 모델 요청에 추가하는 것을 방지합니다. 이로 인해 모델이 일반적인 도구 실행에서 받는 기존 검색 도구 출력에는 변화가 없습니다.

코드 모드(Code Mode)가 경계가 필요한 이유

코드 모드에서는 모델이 exec 도구를 통해 JavaScript를 실행하고 스크립트 내에서 다른 도구를 호출합니다. 이 스크립트는 전체 검색 결과 대신 짧은 요약만 출력할 수 있습니다.

출력된 내용만을 가지고 소스를 복구하려 하면, 결과가 절대 출력되지 않은 성공적인 검색을 놓치게 됩니다. AIClaw는 스크립트가 무엇을 출력할지 결정하기 전에 검색 핸들러 내부에 소스 메타데이터를 기록합니다. 중첩 도구는 소스 컬렉터를 담고 있는 컨텍스트를 상속받습니다.

MCP 및 영속성 테스트는 이러한 구분을 보여줍니다: 이 코드 모드 스크립트는 검색을 기다리지만 finished만 출력합니다. 그럼에도 불구하고 소스는 세션을 저장하고 로드하는 과정에서 살아남습니다.

이전 대화 기록은 더 좁은 복구 경로를 가집니다

새로운 도구 메시지는 구조화된 소스를 직접 저장합니다. 반면, 이전 메시지에는 검색 도구의 텍스트 응답만 포함되어 있을 수 있습니다.

히스토리 호환성 코드는 적절한 exec 출력과 JSON 인코딩된 문자열을 포함하여 저장된 검색 출력으로부터 완전한 구조화된 응답을 복구할 수 있습니다. 사용 가능한 경우 기존 메타데이터를 보존합니다.

결과가 누락되거나 잘린 경우 신뢰성 있게 재구성할 수 없습니다. 따라서 이 구현은 어시스턴트의 답변이나 관련 없는 도구에서 출처를 지어내기보다는 그대로 둡니다.

검색 출처는 검증된 인용문이 아닙니다

패널에는 검색 도구가 반환한 페이지가 표시됩니다. 이는 모델이 모든 페이지를 사용했거나, 특정 문장이 특정 결과에 의해 뒷받침된다는 것을 증명하지 않습니다. 문장 수준의 인용 매핑과 사실 검증은 별도의 작업으로 남아 있습니다.

탐색 대상(Navigation targets)은 임베디드 자격 증명이 없는 HTTP 및 HTTPS URL로 제한됩니다. 제목과 스니펫은 텍스트로 렌더링되며, 도메인 아이콘은 원격 파비콘을 요청하는 대신 로컬 문자를 사용합니다. 이러한 확인 절차는 표시와 탐색에 제약을 가할 뿐, 웹사이트의 신뢰성을 인증하거나 그 주장을 검증하지는 않습니다.

이 구현은 AIClaw 검색 서비스가 사용하는 구조화된 응답을 예상합니다. 임의의 제공업체 네이티브 검색 출력이나 모든 서드파티 MCP(Multi-Cloud Platform) 응답에 대한 범용 파서가 아닙니다.

이번 릴리스 증거가 다루는 내용

릴리스 노트에는 250개의 렌더러 테스트, 14개의 기본 데스크톱 스모크 체크(smoke checks), 그리고 75개의 작업 인터페이스 체크를 포함한 전체 로컬 검사 통과 기록이 보고되어 있습니다. 이들은 전반적인 수치일 뿐, 출처에만 전념하는 테스트 개수는 아닙니다.

출처별 커버리지에는 직접적인 MCP 호출 및 Code Mode, 성공 및 실패 검색, 저장/로드 영속성(persistence), 레거시 복구, URL 필터링, 중복 제거(deduplication), 실시간 이벤트, 패널 상호 작용이 포함됩니다. 픽스처 기반 UI 체크는 또한 일반 텍스트 렌더링, 링크 열기, 키보드 제어 기능을 테스트합니다.

릴리스에서는 일반 모드와 Code Mode에서의 실제 검색 검증을 별도로 기록하며, 복원된 히스토리는 실시간 출처와 일치합니다. 릴리스 CI 실행은 성공적으로 완료되었습니다. 픽스처 체크나 성공적인 검색 자체가 답변의 사실적 주장이 정확하다는 것을 입증하지는 않습니다.

UI 구현은 SearchSources.vue와 턴 레벨 출처 선택(turn-level source selection)를 참고하세요.

출처 목록은 에이전트가 검색한 결과를 검토하기 쉽게 만듭니다. 이 목록을 구조화된 메타데이터로 저장하면, 사용자가 나중에 대화로 돌아왔을 때 다시 유용하게 활용할 수 있습니다.

본 기사는 AI 에이전트에 의해 생성되었으며, 공개된 AIClaw 3.7.6 소스, 릴리스 노트 및 CI 결과를 통해 검토되었습니다.