새 버튼을 계속 만드는 것보다 이미 있는 기능을 제대로 찾는 일이 먼저 필요했다. 그런데 보관함의 모든 이름을 그대로 보여 주면 수정된 코드와 꺼 둔 기능, 결과 확인이 남은 작업까지 같은 후보처럼 보인다. 나는 플러그인을 찾는 입구가 무엇을 포함하고 무엇을 빼는지 실제 카탈로그 함수부터 살폈다.
보관함 목록을 그대로 실행 후보로 보내지 않는다
ProgramLibrary.catalogue는 list의 각 항목을 다시 load한다. 이때 정의와 실제 코드의 일관성을 확인하지 못하면 해당 후보를 자동 발견에서 제외한다. 화면에 이름이 남아 있는 것과 지금 재사용할 수 있는 정의를 읽었다는 사실이 같지 않기 때문이다. 예외를 삼킨다는 이유로 손상된 프로그램이 고쳐졌다고 설명하지는 않는다.
기존 시험은 workflow 파일에 합성 수정 문장을 붙인 뒤 카탈로그에서 빠지는지 본다. 다른 프로필에서도 나타나지 않아야 한다. 이 글의 질문은 앞선 재사용 일반론보다 좁다. 실행 전에 후보를 만드는 자료가 얼마나 최신이며 어떤 상태를 전달하는지에 초점을 맞췄다.
검색어는 정렬에 쓰이며 적합성 판정은 아니다
검색 문자열을 소문자 단어로 나눠 이름·과거 의도·사이트·매개변수 라벨에 포함된 개수를 센다. 점수 다음에는 최근 사용 시각으로 정렬하고 상위20개를 돌려준다. 이 숫자는 현재 코드의 발견 범위이지 앞으로 글이나 기능을20개로 제한하자는 기준이 아니다.
중요한 점은 점수가0인 항목을 전부 거절하는 검색 필터가 아니라는 것이다. 정확히 맞지 않는 후보도 뒤에 올 수 있다. 이름이 비슷해도 현재 요청과 다르면 실행하면 안 된다. 과거 의도는 탐색 단서이고 현재 명령은 아니다. 검색 결과의 순위가 판단의 책임을 대신하지 않도록 설명에 남겼다.
목록에는 키를 주고 예전 값을 다시 쓰게 하지 않는다
카탈로그의 parameters는 키와 사람이 읽을 라벨로 만든다. 저장된 제목이나 본문 값을 새 작업의 입력처럼 제공하는 형태가 아니다. inspect도 매개변수 값을 키 배열로 바꾸고 requiresCurrentInputs=True를 돌려준다. 후보를 고르는 단계에서 필요한 입력의 모양을 알되 이번 자료는 따로 준비하도록 했다.
그래도 반환된 recipe에는 단계와 목적지가 있으므로 전체 자료가 비밀 값으로부터 무조건 안전하다고 말할 수는 없다. 정의 자체를 올바르게 작성하고 검토해야 한다. 실제 사용에는 현재 입력과 허용한 동작을 다시 비교한다. 검색이 과거의 본문을 편리하게 재전송하는 기능이 되지 않게 한 경계다.
확인 필요 상태를 모두 숨기는 것도 답은 아니었다
보통 needs_review인 항목은 자동 카탈로그에서 빠진다. 다만 기록을 읽어 원래 글 결과를 확인할 수 있는 일부 절차는 requiresReadOnlyReconciliation 표시를 붙여 남긴다. 미확정 작업을 다시 시작하라는 추천이 아니라 원래 결과를 읽을 경로를 찾기 위한 예외다.
기존 시험에는 해당 글 확인 후보만 남고 다른 프로필에는 나타나지 않는 조건이 있다. 표시가 있다는 이유로 모든 operation이 허용되는 것도 아니다. 실제 실행 진입점은 확인 필요 상태와 허용한 읽기 작업을 다시 구분한다. 발견 가능성과 변경 실행 가능성을 같은 boolean으로 만들지 않았다.
현재 외부 제어에서는 활성 등록도 따로 확인한다
현재 MCP 관리 조회는 플러그인의 ID·이름·설명·사용법·enabled·pinned·입력 메타데이터를 반환한다. 프로그램 inspect나 실행을 요청하면 현재 등록 항목을 찾아 enabled를 확인한다. UI에서 꺼 둔 기능을 단순히 프로그램 ID를 안다는 이유로 실행 후보로 삼지 않게 하는 별도 경계다.
예전 workflow broker에는 같은 요청 안에서 inspect를 했는지 추적하는 검사도 있다. 현재 외부 program API 전체가 그 이력을 똑같이 강제한다고 확대하지 않았다. 지금 외부 경로에서 확인한 것은 문맥·등록·활성 검사와 공통 pluginRun 연결이다. 같은 단어를 쓰는 서로 다른 진입점을 정확히 나눠 읽어야 한다.
없는 기능과 지금 쓸 수 없는 기능을 구분한다
찾지 못했다고 바로 새 플러그인을 만들면 검토가 필요한 기존 정의나 꺼 둔 기능을 복제할 수 있다. 반대로 이름이 보인다는 이유로 현재 쓸 수 있다고 말하면 상태를 놓친다. 이름·정의·사용 설정·미확정 실행을 차례로 확인하면 새로 만들지, 복원할지, 원래 결과를 읽을지 판단이 달라진다.
이번에는 실제 소스와 기존 시험을 대조했고 원래 앱의 카탈로그를 변경하지 않았다. 공유 모듈은 그중 자동 등록이 사용자의 off와 제거 선택을 존중하는 부분만 실제로 시험한다. 검색 순위나 MCP 전체를 복제한 모듈은 아니다. 필요한 기능을 새로 만드는 일만큼 이미 있는 기능의 상태를 정확히 읽는 일도 제작의 일부로 남긴다.