필요 없는 버튼을 치우려는데 프로그램 파일까지 사라질까 봐 망설이게 만들고 싶지 않았다. 북극성의 제거는 우선 현재 프로젝트의 연결을 정리하는 동작으로 만들었다. 다만 다음 초기화 때 같은 버튼이 저절로 돌아오면 정리의 의미가 없으므로 제거했다는 선택도 남겨야 했다.
무엇을 지우는지 확인 문구에 먼저 쓴다
UI의 제거 확인은 플러그인을 목록에서 빼며 원본 작업 프로그램을 보관한다고 설명한다. 실제 changePlugin의 remove는 preferences에서 해당 programId만 걸러낸다. 프로그램 보관함의 코드나 노트북을 삭제하는 호출은 이 함수에 없다. 버튼의 대상과 파일의 수명을 구분한 것이다.
삭제라는 한 단어는 범위가 너무 넓다. 메뉴에서 안 보이게 하기, 사용 중지, 정의 삭제, 결과 삭제는 사용자가 기대하는 복구 비용이 다르다. 나는 목록 정리에 필요한 가장 좁은 변경을 구현하고 그 범위를 문구에 담았다. 원본 프로그램을 남긴다는 말을 전체 시스템의 백업 보장으로 넓히지는 않는다.
제거 표시가 없으면 초기화가 사용자를 이긴다
일부 기본 기능은 시작 과정에서 자동 등록된다. 등록만 지우면 다음 발견 과정이 새 항목으로 보고 다시 추가할 수 있다. 실제 pluginAction은 remove 뒤 dismissedTaskPlugins에 식별자를 남긴다. 자동 register는 그 목록을 확인하면 registered=False로 끝나고 등록을 복원하지 않는다.
이 표시는 프로그램이 잘못됐다는 판정이 아니다. 사용자가 이 프로젝트의 메뉴에서 쓰지 않겠다는 선택이다. 오류 상태와 제거 선호를 섞으면 원인을 찾기도 어려워진다. 나는 실행 실패 기록이 아닌 별도 설정으로 남겨 자동 연결 과정이 존중할 수 있게 했다. 같은 ID를 계속 쓰는 것도 이 연결을 끊지 않기 위한 조건이다.
다시 추가하겠다는 명시적 선택은 허용한다
자동 발견과 사용자의 재등록은 다르게 취급한다. 명시적 register는 제거 표시를 지우고 정의를 현재 사용 설정에 연결한다. 기존 시험은 자동 등록이 막힌 상태에서 같은 programId를 지정한 create가 연결을 되살리는지 확인한다. 영구 차단 목록으로 만들어 복원을 어렵게 하지 않았다.
제거한 등록 자료를 모두 보관하는 휴지통은 아니다. 새 연결의 기본 enabled와 pinned가 적용될 수 있고, 과거 고정을 반드시 되살린다고 말하지 않는다. 이전 자료를 그대로 복원할지 새 기본값으로 연결할지는 별도 계약이다. 공유 예제는 고정 해제 기본값을 기록으로 보여 주어 이 차이를 숨기지 않는다.
원본 보관과 진행 중 작업의 중단을 함께 설명한다
목록에서 제거하면 현재 선택도 지운다. 같은 프로필에서 같은 프로그램이 active라면 runner.cancel을 요청하는 코드가 이어진다. 원본이 남는다는 이유로 진행 중 업무도 아무 영향 없이 계속된다고 설명하면 틀린다. 남기는 것은 정의이며 중단 요청은 별도 실행 상태에 작용한다.
취소를 요청했다고 이미 외부에서 끝난 행동이 취소됐다는 뜻도 아니다. 게시나 업로드가 있었다면 원래 결과와 기록을 확인해야 한다. 이 콘텐츠 작업에서는 실제 업무를 끄거나 제거하지 않았다. 코드에서 보이는 제어 경계를 설명하고, 공유 예제에서는 실제 중단 대신 의도 값만 돌려준다.
보존 시험은 설정 밖의 자료가 같은지 비교한다
기존 task-plugins 시험은 remove 전 프로그램 자료를 직렬화하고 설정을 제거한 뒤에도 같은지 비교한다. plugin-creation 시험은 제거 표시가 자동 재등록을 막고 명시적 등록에서 지워지는지를 확인한다. 이 두 확인이 함께 있어야 파일 보존과 사용자 선택 보존을 다른 근거로 설명할 수 있다.
원래 시험을 이번에 다시 실행하거나 전체 사용자 저장소를 검사한 것은 아니다. 독립 합성 모듈에서는 정의 사본의 동일성, 제거 표시, 자동 차단, 명시적 복원을 실제로 시험했다. 인증·파일 정리·원래 UI 검수는 포함하지 않는다. 작은 단위 시험의 결과를 전체 삭제 안전성 인증처럼 사용하지 않는다.
커지는 관리 화면에는 되돌릴 범위가 보여야 한다
기능이 늘어나면 쓰지 않는 항목을 정리하는 일도 자주 생긴다. 모든 정리를 파일 삭제로 연결하면 관리가 무거워지고, 아무것도 기억하지 않는 숨김은 다음 실행에서 되돌아온다. 정의·등록·제거 선호를 나누면 어떤 자료가 남고 어떤 연결이 사라지는지 설명할 수 있다.
나는 회사 맞춤 관리자에서도 이런 작은 차이가 오래 쓰는 편의가 된다고 본다. 복원이 필요한 자료를 먼저 정하고 확인 문구와 API 결과를 그 범위에 맞춰야 한다. 아래 예제는 그 판단을 메모리 상태로 따라 볼 수 있다. 실제 저장과 권한을 붙이는 책임까지 없애 주는 완제품으로 소개하지는 않는다.