탭이 많다고 모든 본문을 대화에 넣어야 하는 것은 아니다. 글을 쓸 위치를 찾는 데는 탭의 제목과 주소, 프로젝트와 계정 단서면 충분할 때가 있다. 나는 메타데이터로 먼저 대상을 연결하고 실제 내용은 필요한 탭에서 읽는 구조를 택했다.
탭의 위치를 찾는 질문부터 좁힌다
어느 탭이 블로그 편집기인지 찾는 일과 그 원고가 어떤 내용인지 읽는 일은 다르다. 처음부터 본문을 모두 모으면 대화가 커지고 관련 없는 문서도 섞인다. 탭 식별에 필요한 자료와 작업을 판단할 자료를 나누면 다음 조회의 이유가 명확해진다.
라우팅 자료는 탭 ID와 제목, 프로필과 정리된 주소 같은 필드를 쓴다. 현재 MCP context의 탭 목록도 본문 관찰과 다른 입구다. 목록을 봤다고 페이지의 실제 계정과 편집 상태를 확인했다고 보고하지 않는다. 메타데이터는 대상을 찾는 단서이며 본문 이해의 대체물이 아니다.
실행 비교와 대화용 설명은 다른 주소를 쓴다
routeTab은 전체 주소를 로컬 비교에 쓰지만 역할 자료에는 origin과 pathname을 중심으로 남긴다. 세션 쿼리와 hash를 그대로 넘기지 않도록 한 좁은 처리다. 제목도 길이를 제한한다. 필요한 식별 정보와 부수적인 값을 나누려는 선택이었다.
이 함수의 정제를 모든 API의 주소 출력 정책이라고 확대하지 않는다. context 목록과 다른 도구는 자신의 계약을 확인해야 한다. 주소 경로와 제목 자체에도 민감한 단서가 있을 수 있어 공개 자료는 별도 검토한다. 쿼리를 뺐으니 완전 익명이라는 설명을 붙이지 않는다.
필요할 때는 실제 페이지를 읽는다
메타데이터만으로 여러 카페 게시판이나 같은 제목의 문서를 구별하지 못할 수 있다. 그때는 해당 탭의 현재 구조와 계정, 필요한 본문을 읽어 선택을 구체화한다. 처음 자료를 작게 준다는 이유로 불확실한 상태에서 바로 입력하지 않는다.
큰 페이지는 검색과 추출, 관찰 한도를 사용해 필요한 부분을 더 읽는다. 돌아온 부분 자료가 전체 내용이라는 보장도 없다. 나는 적게 읽는 것 자체보다 무엇이 부족해 추가로 읽는지 설명할 수 있어야 한다고 봤다. 메타데이터 우선은 읽기를 생략하는 정책이 아니라 읽는 순서를 정하는 정책이다.
자동 준비와 모든 탭 본문 수집을 구별한다
PagePreparation은 활성·참고 탭의 자동 읽기 준비와 명시한 읽기를 구별하며 휴면과 로딩 상태, 창의 가시성 같은 조건을 쓴다. 캐시의 항목 수와 바이트, 수명도 제한한다. 모든 열린 탭을 끊임없이 읽어 대화로 보내는 기능으로 소개하지 않는다.
로컬 원고 복구를 위한 수집은 또 다른 책임이다. 정상 종료에 필요한 초안을 모으는 일과 AI에 참고 본문을 제공하는 일은 목적과 공개 범위가 다르다. 두 기능이 같은 앱에 있다고 모든 로컬 저장 내용이 모델 문맥에 자동 들어간다는 뜻은 아니다. 각각의 실제 반환 경로를 읽어야 한다.
옛 문맥 전달과 현재 외부 호출도 구별한다
과거 내장 CLI 문서는 첫 탭의 본문과 제한된 참조를 모델 문맥에 넣는 방식을 설명한다. 현재 외부 MCP는 내장 모델 없이 호출자에게 필요한 목록과 도구 결과를 돌려준다. 과거의 자동 첨부 설명을 현재의 모든 외부 대화에 같은 방식으로 적용하지 않는다.
이 글은 탭 역할 생성과 현재 context 응답, 준비 계층 코드를 읽었다. 현재 브라우저의 모든 탭 본문을 새로 수집한 검수는 아니다. 전체 토큰 절감률도 여기서 측정하지 않았다. 바이트를 줄인 구조와 실제 모델 비용을 같은 숫자로 단정하지 않고 각각의 측정 근거를 남긴다.
필요한 자료만 여는 업무 경험을 만든다
고객의 회사 자료도 한 번에 모두 펼치는 것이 항상 편한 것은 아니다. 먼저 필요한 거래처와 문서 위치를 찾고 그 자료만 자세히 확인하는 흐름이 더 직관적일 수 있다. 에이전트에게도 탐색과 정독의 단계를 나누는 인터페이스가 필요했다.
나는 메타데이터를 사용자의 현재 업무를 잇는 얇은 길잡이로 만들려 했다. 자료를 많이 모았다는 성과보다 올바른 탭을 찾고 필요한 내용만 정확히 읽었다는 근거가 중요하다. 그 구분이 있어야 탭이 늘어나도 대화의 크기와 관련 없는 자료 노출을 함께 관리할 수 있다.