현재 탭을 쓰면 편하지만 사용자가 다른 곳을 명시했는데도 고집하면 잘못된 기본값이다. 반대로 본문에 사이트 이름이 한 번 나왔다고 목적지를 바꿔도 안 된다. 나는 무엇이 명시한 선택이고 무엇이 자료 속 단어인지부터 구별했다.
아무 선택이 없을 때의 기준을 정한다
일반 작성 요청에 별도 목적지가 없으면 요청 당시 탭을 기본으로 삼는 설계를 만들었다. 이후 자료를 읽으러 이동한 탭과 요청 시점의 기본값은 다르다. 다음 새 요청에서는 그때의 현재 탭을 다시 기준으로 정해야 한다.
이것은 현재 화면만 영원히 허용한다는 정책이 아니다. 명시한 사이트와 탭, 여러 목적지를 다루는 경로도 남긴다. 기본값은 생략된 선택을 돕는 장치이며 사용자가 구체적으로 고른 값을 덮어쓰는 지시가 아니다. 나는 기본값의 편의와 선택의 우선순위를 함께 설명하려 했다.
정확한 탭 선택과 사이트 이름을 구분한다
planTaskTabs에는 허용 범위의 명시한 탭 ID와 인용한 탭 제목을 다루는 경로가 있다. 정확한 ID가 있으면 보낼 프롬프트 속 다른 사이트 이름보다 우선한다. 다만 참고 탭으로 지정한 ID는 작성 선택으로 올리지 않는다.
닫힌 탭이나 다른 프로젝트, 허용되지 않은 프로필의 ID를 비슷한 탭으로 바꾸지 않는 시험도 있다. 번호를 찾지 못했다는 부족함은 그대로 남긴다. 정밀한 선택을 받았다는 이유로 소속 검사를 생략하지 않는다. 사용자의 선택과 실제 사용 가능한 대상을 같이 만족해야 한다.
플랫폼 이름과 구체 주소는 같은 정밀도가 아니다
사이트 홈 이름은 그 서비스의 기존 페이지를 재사용할 수 있지만 계정 경로나 구체 리소스를 지정한 주소는 더 좁게 맞춰야 한다. 같은 블로그 플랫폼이라고 다른 소유자의 편집기를 고르지 않는 조건이 필요하다. 로그인 표시명과 글 주소의 소유 식별도 구별한다.
후보의 우선순위에는 현재 탭과 프로젝트의 선호 계정, 편집기 여부가 쓰인다. 이것은 모든 후보 중 유일성을 증명하는 알고리즘과는 다르다. 계정 충돌과 없는 이름 같은 모호한 경우는 별도로 표시한다. 합성 문맥 모듈의 더 엄격한 단일 후보 규칙과 원래 제품의 순위 정책도 같은 구현으로 소개하지 않는다.
원고의 단어가 지시로 올라오지 않게 한다
requestRoutingInstructions는 명시된 제목·본문 원고 구간과 그 앞의 라우팅 지시를 나누는 처리다. “블로그용 이미지”처럼 결과의 사용처를 말하는 표현도 지금 생성할 서비스와 구별한다. 블로그에 쓸 이미지를 Gemini에서 만드는 요청은 생성 위치가 Gemini다.
알려진 한국어·영어 표현을 다루는 규칙이지 모든 문장의 의미를 완벽히 판정하지 않는다. 나는 예외를 늘리는 것보다 어떤 표현을 근거로 선택했는지 시험으로 남기는 편을 택했다. 목적지로 보기 어려운 자료를 사용자의 실제 지시처럼 취급하지 않는 것이 우선이었다.
과거 라우팅과 현재 MCP의 책임을 나눈다
옛 내장 CLI는 작업 시작 전에 이런 계획을 사용했다. 현재 외부 MCP의 수동 begin은 명시한 context를 받는 다른 입구다. 현재 브라우저가 내부 모델로 모든 자연어의 탭을 자동 선택한다고 설명하지 않는다. 외부 호출자는 현재 탭과 실제 목적지를 읽어 연결해야 한다.
이 글은 현재 남은 함수와 시험, 역사 문서를 대조했다. 새 실제 계정 전환이나 외부 작성을 수행한 보고서는 아니다. 계정 표시가 저장돼 있다는 것과 실제 로그인 상태도 다르다. 좋은 기본값은 확인을 줄일 수 있어도 현재 인증과 요청 범위의 검사를 없애지는 않는다.
선택의 순서를 보이면 자동화도 고치기 쉽다
회사에 맞는 프로그램은 자주 쓰는 기본값과 예외 요청이 함께 있다. 어떤 값이 우선하는지 정하지 않으면 기본값이 편한 순간과 위험한 순간을 구별하기 어렵다. 나는 탭 선택에서도 요청·명시 선택·범위·후보 기준의 순서를 남겼다.
이 기준은 사용자의 말을 매번 길게 되묻기 위한 것이 아니다. 이미 분명한 선택은 그대로 쓰고 실제로 없는 정보만 드러내려는 것이다. 무엇을 근거로 골랐는지 알 수 있어야 잘못된 선택을 고칠 때 계정이나 원고를 임의로 바꾸지 않고 필요한 조건만 보완할 수 있다.