결론부터 말하자면, DeepSeek Harness의 플러그인은 목록에서 무작위로 선택하는 것이 아니라, 변경할 처리 과정과 합격 조건을 먼저 정한 후 하나씩 시도해야 합니다. 본 문서는 이미 Harness를 구동할 수 있는 개발자를 대상으로 합니다. 복구용 Git 히스토리나 백업을 준비할 수 없는 환경에는 적합하지 않습니다. 2026년 11월 13일에 12개의 리포지토리를 확인했으며, 로컬에서 실측한 것은 @changfenhuang/dsh-genui 뿐입니다. 나머지 11개 항목은 개발자 문서를 기반으로 정리된 것이며, 동작이 확인되었다고 간주하지 않습니다.
그렇다면 무엇을 '도입 성공'이라고 할 수 있을까요? 주제가 전환되면 성공인지, 위험한 명령어가 멈추면 성공인지, 긴 대화의 조건이 남아 있으면 성공인지. 플러그인마다 답이 다르기 때문에, 동일한 체크리스트를 그대로 적용하면 판단을 오해할 수 있습니다.
12개 항목을 기능명으로 나누는 것이 아니라, Harness의 어느 부분에 개입하는지로 나누면 첫 번째 검증 대상을 파악하기 쉽습니다.
| 변경 위치 | 플러그인 | 개발자 문서에서 읽은 역할 | 가장 먼저 확인할 것 |
|---|
| 컨텍스트 | billion-context | 긴 세션의 압축, 복원, 캐시 관리 | 필수 조건이 압축 후에도 남아 있는지 |
| 이미지 입력 | dsh-vision-router | OCR(광학 문자 인식), 잘라내기, 색상 추출, 픽셀 비교 등의 이미지 도구 | 비기밀 이미지로 추출 결과를 원본과 대조할 수 있는지 |
| 명령어 실행 | cc-safety-net | Git, 삭제, 기밀 파일 조작 등 위험한 명령어를 사전 검사 | 무해한 작업을 거쳐 파괴적인 테스트를 막는지 |
| 답변 렌더링 | @changfenhuang/dsh-genui | 표, 그래프, 폼, 슬라이더, 패널 등을 표시 | 로컬 작업과 모델 재호출을 구분할 수 있는지 |
| 구조 시각화 | archify | 계획이나 코드 관계를 인터랙티브한 구성도로 만듦 | 소규모 리포지토리의 주요 관계와 일치하는지 |
| 결과물 생성 | dsh-ppt | 자료에서 슬라이드 구성, 미리보기, PPTX 출력까지 진행 | 폰트, 줄 바꿈, 이미지, 사실을 출력 후 확인할 수 있는지 |
| 대화 구조 | dsh-synapse | 대화를 노드와 분기로 관리함 | 같은 부모로부터 나뉜 2가지 안이 혼선되지 않는지 |
| 태스크 진행 | dsh-pua | 역할, 진행 상태, 완료 루프를 추가함 | 상태 표시와 실제 완료 조건이 일치하는지 |
| 배경 표시 | dsh-wallpaper-engine | 정지 이미지, 애니메이션, 비디오 배경을 추가함 | 활성화와 비활성화가 안정적이고, 묘사 부하(描画負荷)가 허용 범위인지 |
| 데스크톱 표시 | dsh-pet | 투명한 데스크톱 캐릭터를 표시함 | 종료 후 프로세스나 표시가 남지 않는지 |
| 입력란 주변 | dsh-meme | 컴포저 근처에 이미지/밈 조작을 추가함 | 의도치 않은 이미지 전송이나 입력 방해가 없는지 |
| 테마 | dsh-claude-style | Claude Code Desktop 같은 색상 조합과 레이아웃으로 변경 | 외관만 바뀌고 모델 설정은 변하지 않는지 |
여기서 중요한 것은, 표시의 변화와 모델 능력의 변화를 분리하는 것입니다. 테마를 바꾼다고 추론 능력이 올라가지 않습니다. 구성도가 표시된다고 해도, 그 그림이 런타임의 동작을 완전히 나타낸다고 할 수는 없습니다.
도입 전 기록은 트러블 발생 시 비교 대상이 됩니다. 최소한 다음 항목을 남겨야 합니다.
- Harness의 버전과 실행 환경.
- 완전한 패키지명, 리포지토리 소유자, 확인한 README의 URL과 날짜.
- 읽기 대상, 쓰기 대상, 호출 가능한 도구.
- 합격으로 판단할 수 있는 관찰 가능한 변화.
- 비활성화, 삭제, 생성물 정리, 데이터 복구 절차.
모든 플러그인을 동일한 권한으로 시도해도 될까요? 답은 '아니요'입니다. 배경이나 테마의 첫 시험은 표시의 복원이 중심이지만, 명령어 후킹(command hook)이나 파일 생성은 일회용 작업 사본에서 시작하는 것이 안전합니다. 긴 대화를 다루는 플러그인에서는 중요한 수용 조건(acceptance condition)을 대화에만 두지 않고 프로젝트 파일에도 남겨야 합니다.
첫 시험은 '모든 기능을 보기'가 아니라, 결과를 하나 관찰할 수 있는 크기로 해야 합니다.
billion-context
압축 전에 고정된 제약이 후속 턴에서도 참조되는지 확인합니다. 압축률만으로는 합불을 결정할 수 없습니다. -
dsh-vision-router
이어서, 알려진 텍스트와 색상이 포함된 스크린샷을 사용하여 OCR과 색상 추출 결과를 원본과 비교합니다. - cc-safety-net
무해한 명령어와 사용 후 폐기되는 환경에서 중지해야 할 작업을 분리하여 테스트합니다. - archify
의존 관계를 파악하고 있는 작은 리포지토리를 사용하여, 주요 모듈 간의 관계를 코드로 대조합니다. - dsh-ppt
짧은 자료에서 몇 장만 출력하여, 내용뿐 아니라 글꼴, 줄 바꿈, 이미지 잘림 여부를 확인합니다. - dsh-synapse
하나의 메시지에서 두 가지 안으로 분기하며, 각 노드가 올바른 부모 조건을 계승하는지 확인합니다. - dsh-pua
상태 카드상의 '완료'와 실제 수용 조건이 일치하는지 확인합니다. 표시계 4개 항목의 경우, 활성화, 표시 확인, 비활성화, 원래 상태로 복귀까지를 하나의 세트로 구성합니다.
단순히 외관만 바뀌었다고 해서 해당 플러그인을 상시 사용해야 할까요? 작업 중 반복을 줄였는지, 특정 실패를 방지했는지, 종료 후 원래대로 되돌릴 수 있는지 설명할 수 없다면, 상시 사용 여부를 판단하기는 아직 이르다고 생각합니다.
GenUI는 이번에 로컬 환경에서 시도한 유일한 항목입니다. 첫 번째 오류는 렌더링 문제가 아니라 패키지 식별 과정에서 발생했습니다.
이전 참조에 있던 changfenhuang/dsh-genui
라는 리포지토리 경로는 404를 반환했습니다. 현재 소스는 omdsh-dev/dsh-genui이며, 실제로 사용한 패키지는 **@changfenhuang/dsh-genui**입니다.
스코프가 없는 dsh-genui도 존재하지만, 이는 다른 구현체입니다. @changfenhuang/를 생략하면 단축명이 되는 것이 아니라 설치 대상 자체가 변경됩니다.
이 이미지에서 확인할 수 있는 것은 2026년 11월 10일 로컬 환경에 완전한 스코프 패키지가 등록되었다는 것입니다. 모든 Harness 버전이나 다른 플러그인과의 조합을 보장하는 증거는 아닙니다.
실측에서는 모델 ID deepseek-v4.1-flash를 사용했으며, Base URL은 https://api.crazyrouter.com/v1이었습니다. 입력한 프롬프트는 중국어 "展示一下刚刚加入的ui的完整功能。"이며, 의미는 '방금 추가된 UI의 모든 기능을 보여줘'입니다. 일본어 프롬프트 품질을 측정한 시험은 아닙니다.
완벽한 데모를 생성하는 데 3분 58초가 걸렸습니다. 이는 다수의 컴포넌트를 한 번에 요청한 기록이며, 작은 표나 그래프의 표준 응답 시간이 아닙니다.
이번 실행에서 로컬로 확인된 작업은 표 정렬 및 필터링, Markdown/CSV 복사, 그래프 범례 전환, 함수 파라미터 슬라이더 조작입니다. 이들은 페이지 내 상태 변경으로 완료되었습니다.
반면, action을 가진 버튼이나 폼 제출은 이벤트를 모델로 되돌릴 수 있습니다. 즉, GenUI의 수용 시험에서는 '컴포넌트가 표시되었는지'뿐만 아니라, '어떤 조작이 브라우저 내에서 끝나고 어떤 조작이 다음 모델 턴을 생성하는지'를 확인해야 합니다.
도표의 수치는 데모용입니다. 여기서 검증한 것은 업무 데이터의 정확성이 아니라, 조작 후에 표시가 업데이트되는 것과 이벤트 경계입니다. 로컬 조작이 있다고 해서 총 토큰이 반드시 줄어든다고 단정할 수는 없습니다. 최초 UI 생성과 action 호출은 별도로 발생합니다.
테스트에 사용된 ID는 deepseek-v4.1-flash입니다. 현재 공개된 deepseek-v4-flash 페이지와 문자열이 다릅니다. 이용 가능한 ID를 추측으로 설정하지 않고, 현재 채팅 모델 목록에서 확인한 후 최종적인 렌더링은 Harness 내에서 검증합니다. 카탈로그상에 텍스트가 반환된다는 것이 GenUI 표시의 성공을 의미하지 않습니다.
남은 11개 항목에 대해 본고가 제시할 수 있는 것은 개발자 문서로부터 만든 검증 가설까지입니다. '설치 가능하다', '안전하게 사용할 수 있다', '다른 항목과 공존한다'는 결론을 내리지 않았습니다.
특히, 다음 경계들은 실제 장비에서 분리하여 확인해야 합니다.
- 컨텍스트 압축 후 남은 정보와 복원하지 못한 정보.
- 이미지 툴이 읽어낸 결과와 원본 이미지에 실제로 존재하는 내용.
- 안전 규칙이 막은 알려진 패턴과 규칙 외의 조작.
- 구성도, 슬라이드, 대화 노드가 보여주는 정보와 원본 파일 또는 실행 결과.
- 테마, 배경, 이모티콘(펫), 밈 표시로 인한 UI 변화와 모델 설정.
플러그인 간의 병용 사용 역시 별도의 테스트가 필요합니다. 단독으로 성공한 두 항목이라도, 동일한 DOM 영역, 단축키(Shortcut), 이벤트(Event), 파일 출력 위치를 공유한다면 조합에서 문제가 발생할 가능성이 있습니다. 처음부터 12개 항목을 동시에 활성화하면 원인을 분리하기 어려워집니다.
상용 여부를 판단하는 것이 더 쉬워지려면 다음 4가지 포인트를 간략하게 기록하는 것이 좋습니다.
| 기록 | 내용 |
|---|
| 기대 변화 | 어떤 반복 작업을 줄일 수 있는지, 어떤 실패를 막을 수 있는지 |
| ... | |
GenUI의 경우, 이번 증거는 스코프가 지정된 패키지 등록, 표와 그래프 표시, 로컬 조작(Local Operation), action 이벤트 경계에 국한됩니다. 모든 컴포넌트, 모든 Harness 버전, 총 토큰 감소를 증명하는 것은 아닙니다. | |
플러그인 이름이 긴 목록보다는 항목별로 작은 수용 기록을 남기는 것이 재사용성이 높습니다. 변경된 부분, 합격 조건, 미확인 범위, 되돌리는 방법(롤백) 등을 미리 결정해 놓으면 도입 후에 "무엇이 바뀌었는지 모르는" 상황을 피하기 쉽습니다.
billion-context
: https://github.com/ranxianglei/billion-context -
dsh-vision-router
: https://github.com/ysr666/dsh-vision-router -
cc-safety-net
: https://github.com/kenryu42/cc-safety-net -
@changfenhuang/dsh-genui
: https://github.com/omdsh-dev/dsh-genui -
archify
: https://github.com/tt-a1i/archify -
dsh-ppt
: https://github.com/STARDUSTLC666/dsh-ppt -
dsh-synapse
: https://github.com/liangmianya/dsh-synapse -
dsh-pua
: https://github.com/MichengAI/dsh-pua -
dsh-wallpaper-engine
: https://github.com/elysia395/dsh-wallpaper-engine -
dsh-pet
: https://github.com/PC2005-cloud/dsh-pet -
dsh-meme
: https://github.com/yyh-001/dsh-meme -
dsh-claude-style
: https://github.com/Nwflower/dsh-claude-style
