2026년 8월 17일 공개된 v0.1.0-rc.7 릴리스에는 플러그인이 자체 설정 카드를 등록할 수 있다는 내용이 포함됐습니다. 공식 릴리스 설명이 확인하는 범위는 여기까지입니다. 따라서 이번 주에는 기존 플러그인을 전면 개편하지 말고, 첫날 영향 점검과 첫 주 최소 검증만 진행하는 편이 맞습니다. 새 설정 진입점은 생겼지만 설정 계약이 안정됐다는 뜻은 아닙니다.
이 글은 기존 플러그인 적응 여부를 판단하는 개발자, 여러 플러그인의 설정을 관리하는 팀 유지 담당자, 플러그인 중심 에이전트 도구의 제품화를 검토하는 기술 책임자를 위한 내용입니다.
핵심 주의: 설정 카드가 보인다는 사실과 설정값이 안전하게 저장되고 다음 버전에서도 그대로 읽힌다는 사실은 서로 다릅니다.
마지막 업데이트: 2026년 8월 18일. 데이터는 2026년 8월 17일 공개된 rc.7 릴리스와 공식 저장소의 개발 문서, 구조 문서를 대조해 확인했습니다.
공개된 변화와 아직 비어 있는 약속
공식 릴리스에서 확인되는 변화는 “각 플러그인이 자신의 설정 카드를 등록할 수 있다”는 점입니다. 릴리스는 동시에 Cordis 동적 플러그인 패널을 다듬었다고 설명합니다. 공식 저장소의 구조 설명처럼 DeepSeek Harness는 모든 기능을 플러그인으로 구성하는 방향을 취하고 있으므로, 설정 카드는 기능 자체보다 관리 화면의 진입점을 정리하는 변화로 보는 것이 정확합니다.
다음 항목은 현재 릴리스 설명만으로 확정할 수 없습니다.
- 설정 카드 등록에 사용하는 장기 안정 API
- 카드에서 저장한 값의 실제 보관 위치
- 버전이 바뀌었을 때 설정값을 자동으로 옮기는 규칙
- 플러그인별 설정의 권한 범위
- 기존 배포 설정 파일을 완전히 대체하는지 여부
- 카드 오류가 다른 플러그인 로딩에 미치는 영향
DeepSeek Harness 공식 읽기 자료에는 개발 프리뷰 단계이며 호환성을 깨는 변경이 있을 수 있다고 명시되어 있습니다. 그러므로 이번 기능을 정식 설정 플랫폼의 출발점으로 단정하기보다, 사용자 경험을 검증할 수 있는 실험용 표면으로 보는 편이 좋습니다. 공식 읽기 자료의 개발 프리뷰 안내도 이 판단을 뒷받침합니다.
첫날에는 새 카드보다 기존 진입점을 먼저 확인합니다
현재 dsh-plugin이 영향을 받는지는 설정 카드가 보이는지보다 기존 설정 흐름에 달려 있습니다. 다음 세 가지를 먼저 분리해서 점검해야 합니다.
첫째, 플러그인이 예전 호스트 화면의 특정 위치나 이름을 직접 가정하는지 확인합니다. 화면 구조를 선택자로 찾아 값을 주입하는 방식이라면 새 카드와 충돌할 가능성이 있습니다. 반대로 플러그인이 호스트가 제공하는 설정 읽기와 저장 흐름만 사용한다면 즉시 문제가 생기지 않을 수 있습니다.
둘째, 플러그인이 cordis.yml만 읽는지 확인합니다. 이 파일을 배포 기본값의 원천으로 사용하면서 카드에서 같은 값을 다시 쓰면 두 개의 설정 소유자가 생깁니다. 사용자가 화면에서 변경한 값이 다음 실행 때 파일값으로 덮어써지는 현상이 대표적인 실패 형태입니다.
셋째, 현재 버전에서 정상적으로 로드되고 저장되는지 확인합니다. 설정 카드가 없다는 이유만으로 이미 안정적인 플러그인을 다시 설계하면, 검증되지 않은 API에 팀의 유지 비용을 먼저 묶게 됩니다. 공식 개발 안내는 저장소가 빠르게 바뀌는 개발 프리뷰 구조와 빌드 검증 절차를 함께 설명하므로, 대규모 수정 전 기준점으로 활용할 수 있습니다.
첫 주는 작은 설정 하나로 닫힌 흐름을 검증합니다
플러그인 설정 카드의 가치는 카드가 화면에 나타나는 데서 끝나지 않습니다. 등록부터 실패 처리까지 하나의 흐름이 닫혀야 팀 적용을 검토할 수 있습니다. 처음부터 모델 선택, 작업 경로, 인증 정보처럼 영향이 큰 설정을 넣지 말고 민감하지 않은 문자열이나 단순 선택값 하나를 사용하십시오.
권장 순서는 다음과 같습니다.
- rc.7 전용 시험 복사본을 만들고 운영 플러그인과 분리합니다.
- 민감하지 않은 설정값 하나와 명확한 기본값을 정의합니다.
- 플러그인이 설정 카드를 등록하는 실제 코드 위치를 공식 저장소나 재현 가능한 시험 결과로 확인합니다.
- 화면에 카드가 나타나는지 확인하고 초기값이 예상과 같은지 기록합니다.
- 값을 변경한 뒤 저장하고, 화면 새로 고침 후 같은 값이 다시 나타나는지 확인합니다.
- 잘못된 형식이나 빈 값을 입력해 오류가 사용자에게 표시되는지 확인합니다.
- 프로그램을 다시 시작한 뒤 값이 유지되는지 확인하고, 유지되지 않으면 저장 성공으로 판정하지 않습니다.
- rc.7에서 실패한 경우 플러그인 로딩 복구 절차와 현재 설정 파일을 함께 보존합니다.
이 과정에서 함수명이나 생명주기 이름을 추측해 문서화하면 안 됩니다. 현재 공개 문서가 설명하지 않은 호출 규약은 소스 확인이나 실제 재현 전까지 “미확인”으로 남겨야 합니다. 설정 카드가 나타났다는 한 번의 화면 확인만으로 호환성을 선언하면, 다음 업데이트에서 저장 위치나 초기화 순서가 달라질 때 원인을 찾기 어렵습니다.
플러그인의 최소 구조 자체가 아직 정리되지 않았다면 DeepSeek Harness 플러그인 개발과 최소 구조 안내를 먼저 참고하십시오. 설정 카드 시험보다 플러그인의 로딩 순서, 기본 설정값, 오류 처리 위치를 고정하는 일이 우선입니다.
팀 적용에서는 카드 소유자와 배포 소유자를 나눠 봅니다
설정 화면이 생기면 팀은 곧바로 “모든 설정을 카드로 옮기자”고 생각하기 쉽습니다. 그러나 실제 운영에서는 값의 종류에 따라 관리 주체가 달라집니다.
- 플러그인 소유: 표시 방식, 기능 켜기와 끄기, 사용자별 선호값
- 호스트 소유: 계정, 작업 공간, 공통 실행 정책
- 배포 소유: 기본값, 환경별 강제값, 자동 설치와 회수 정책
- 비밀 저장소 소유: 인증 토큰, 개인 키, 외부 서비스 비밀값
한 필드에 두 개 이상의 쓰기 경로를 허용하지 않는 것이 핵심입니다. 예를 들어 카드에서 작업 경로를 바꾸고 배포 파일이 시작 때마다 같은 경로를 덮어쓴다면, 사용자 화면은 저장된 것처럼 보여도 실제 실행값은 달라질 수 있습니다.
팀 플러그인 기록에는 최소한 다음 항목을 남기십시오.
- 현재 호환 대상으로 삼은 버전
- 설정 항목별 소유자
- 기본값과 허용값
- 잘못된 값의 거부 방식
- 설정 파일로 되돌리는 방법
- 인증 정보와 일반 설정의 분리 방식
- 다음 버전에서 확인할 변경 지점
Cordis는 동적 구성과 플러그인 조합을 목표로 하지만, 그 설계가 곧 DeepSeek Harness의 모든 설정 화면 계약을 보장하는 것은 아닙니다. Cordis 설계 자료는 동적 구성과 구성 조정 개념을 설명하는 참고 자료이며, rc.7의 사용자 설정 카드 API 문서로 읽어서는 안 됩니다.
자주 묻는 판단
딥시크 하네스 플러그인 설정 카드는 어떤 기능인가요?
플러그인이 자신의 설정 항목을 호스트 설정 화면에 카드 형태로 등록할 수 있게 하는 기능입니다. 사용자는 플러그인별 진입점을 따로 찾지 않고 관련 값을 확인하고 수정할 수 있습니다. 다만 공식 릴리스 설명은 카드 등록 가능 여부만 확인하며, 저장 위치와 권한 처리, 버전 간 이전 규칙까지 확정하지는 않습니다.
기존 dsh-plugin은 rc.7에 맞춰 바로 고쳐야 하나요?
정상적으로 로드되고 기존 설정을 읽고 저장한다면 즉시 대규모 수정할 필요는 없습니다. 오래된 설정 진입점이나 화면 구조를 직접 가정하는지 먼저 확인해야 합니다. 오류가 없다면 현재 경로를 유지하고 시험 브랜치에서 카드 등록 가능성만 검증하는 방식이 안전합니다.
플러그인 설정 카드가 cordis.yml을 대신하게 되나요?
현재 공개된 rc.7 설명만으로는 cordis.yml을 대체한다고 볼 수 없습니다. 카드는 사용자 화면의 관리 진입점을 추가한 기능에 가깝습니다. 배포 기본값과 환경별 값, 자동화 설정은 파일이나 환경 변수에서 계속 관리해야 할 수 있습니다. 동일한 필드에 여러 쓰기 경로를 만들지 않는 것이 중요합니다.
딥시크 하네스 플러그인은 설정 화면을 어떻게 시험해야 하나요?
민감하지 않은 문자열이나 선택값 하나부터 시작하십시오. 카드 등록, 초기값 표시, 수정, 저장, 새로 고침 뒤 재표시, 재시작 뒤 유지, 잘못된 값의 오류 처리를 순서대로 확인합니다. 공식 코드에 없는 함수명이나 생명주기 이름은 추측하지 말고, 소스와 실제 재현이 확인된 범위에서만 사용해야 합니다.
첫 주 판단을 위한 확인 목록
아래 항목을 모두 확인한 뒤에만 팀 플러그인 전체로 확대하는 편이 좋습니다.
- [ ] rc.7에서 현재 플러그인이 정상적으로 로드됩니다.
- [ ] 기존 설정값이 정상적으로 읽힙니다.
- [ ] 기존 설정값이 정상적으로 저장됩니다.
- [ ] 오래된 화면 구조나 선택자에 직접 의존하지 않습니다.
- [ ] cordis.yml과 카드가 같은 필드를 동시에 소유하지 않습니다.
- [ ] 민감하지 않은 설정 하나로 카드 등록을 시험했습니다.
- [ ] 카드의 초기값과 기본값이 일치합니다.
- [ ] 저장 뒤 새로 고침에서 값이 유지됩니다.
- [ ] 프로그램 재시작 뒤 값이 유지되는지 확인했습니다.
- [ ] 잘못된 값에 대한 오류와 복구 경로가 있습니다.
- [ ] 설정의 소유자와 배포 담당자가 기록되어 있습니다.
- [ ] 다음 릴리스에서 다시 확인할 API와 저장 동작을 정리했습니다.
원격 환경에서는 화면 성공과 저장 성공을 분리합니다
원격 클라우드 맥이나 여러 계정이 접속하는 개발 환경에서는 브라우저에 값이 보였다는 사실만으로 검증을 끝내면 안 됩니다. 세션이 유지되는 동안에는 임시 상태가 보일 수 있고, 재시작이나 업그레이드 뒤에는 다른 결과가 나올 수 있습니다.
최소한 다음 조건을 나눠 확인해야 합니다.
- 같은 계정으로 새로 고침했을 때 값이 유지되는가
- 프로그램을 완전히 종료한 뒤 다시 실행해도 값이 남는가
- 플러그인 업데이트 뒤 기본값으로 되돌아가지 않는가
- 다른 계정에서 같은 설정이 노출되지 않는가
- 원격 접속이 끊겼다가 다시 연결돼도 상태가 일관적인가
- 비밀값이 일반 화면이나 로그에 표시되지 않는가
인증 정보는 카드에 직접 노출하기보다 안전한 비밀 저장 원칙을 적용해야 합니다. 실제 키나 토큰을 시험 데이터로 사용하지 마십시오. 원격 환경에서는 설치 경로와 재시작 조건을 별도로 기록하고, 동일한 플러그인을 새 세션에서 다시 불러 설정값이 유지되는지 확인해야 합니다. 실제 원격 맥 환경의 접속 조건과 운영 범위를 비교할 때는 VMSPIN의 한국어 원격 맥 환경 안내를 참고할 수 있습니다.
확대 투자는 다음 안정성 신호 뒤로 미룹니다
첫 주에 확인할 공식 신호는 기능 소개보다 계약의 구체성입니다. 다음 항목이 공개되기 전까지는 소수 플러그인 시험을 유지하십시오.
- 설정 카드 등록 예제가 공식 문서에 추가되는가
- 설정값의 저장 위치와 초기화 순서가 설명되는가
- 호환 가능한 버전 범위가 릴리스 노트에 반복해서 명시되는가
- 설정값 이전 또는 기본값 변경 규칙이 제공되는가
- 잘못된 플러그인 설정이 다른 플러그인에 미치는 영향이 설명되는가
- 다음 후보판과 정식판에서 같은 인터페이스가 유지되는가
현재 공식 저장소의 개발 문서는 Node.js 22.19 이상과 24 계열을 지원 대상으로 설명하고, 저장소 검증에는 pnpm run typecheck를 사용합니다. 개발 환경 요구 사항은 플러그인 시험 환경을 고정할 때 참고할 수 있습니다. 다만 이 빌드 조건이 설정 카드 API의 안정성을 의미하지는 않습니다.
기존 방식은 설정 파일과 배포 스크립트를 직접 관리해야 하고, 카드가 없으면 사용자별 진입점도 분산됩니다. 반대로 새 카드만 믿으면 저장 위치, 권한, 버전 이전을 팀이 직접 추적해야 하는 부담이 생깁니다. 그래서 현재는 전면 전환보다 작은 플러그인 시험이 합리적입니다. 반복 설치와 원격 재시작이 필요한 경우에는 물리 장비를 직접 준비하기보다 원격 맥 환경에서 설치 흐름을 확인한 뒤, 안정적인 계약이 공개되었을 때 팀 공용 설정 패널로 넓히는 순서가 현실적입니다.
시험용 플러그인을 최소 구조로 구성한 뒤 로딩 오류가 발생하면 현재 설정 파일과 로그를 보존하십시오. 특히 설정 카드 추가 직후 플러그인이 보이지 않거나 시작 단계에서 멈춘다면 로딩 순서와 설정 파일을 분리해 확인하는 방식이 필요합니다. 원격 환경에서 실제 설치와 재시작을 수행할 때는 한국어 원격 맥 신청 안내의 접속 조건도 함께 확인할 수 있습니다. 설정 카드의 재시작과 원격 접속 상태까지 확인한 다음에야 팀 전체의 설정 화면을 통합하는 판단을 내리는 편이 안전합니다.