DeepSeek을 사용한 주간 보고서가 2주가 지나도 불안정하다면, 먼저 이번 세션의 요청 사항을 명확히 하자

만약 DeepSeek에게 2주에 걸쳐 매주 금요일마다 주간 보고서를 부탁하고 있다고 가정해 봅시다. 어떤 주는 바로 제출할 수 있는 초안이 나옵니다. 다음 주는 아직 끝나지 않은 업무가 완료된 것처럼 작성되고, 메모에 남겨두었던 세부 사항들이 빠집니다. 같은 상대방에게, 같은 종류의 기록을 전달함에도 불구하고 완성도가 안정적이지 않습니다.

이럴 때 먼저 확인해야 할 것은 새로운 기능이 부족한지가 아닙니다. 이번 요청(prompt)이 읽는 사람과 형식, 그리고 경계까지 명확하게 작성되어 있는지 여부입니다. 다음 주에도 같은 방식을 다시 구두로 설명할 생각인지도요. 근거가 되는 파일은 이름만 봐도 찾아갈 수 있는 상태인지도 말입니다. 이 세 가지를 분리해서 다루면 주간 보고서의 불안정성을 개선하기 쉽습니다.

주간 보고서에는 매번 바뀌는 작업 기록과, 매주 바꾸고 싶지 않은 작성 방식이 공존합니다. 이 두 가지를 짧은 '주간 보고서를 써줘'라는 요청 하나에 욱여넣게 되면, 어떤 사실을 남길지, 무엇을 미완료로 처리할지까지 그 자리의 대화에 맡기게 됩니다. 금요일마다 달라지는 편차를 줄이려면, 먼저 판단 기준을 말로 정의해야 합니다.

이 경로는 자료를 작성하고, 파일을 정리하며, 반복적인 업무를 진행하는 사람에게 적합합니다. 모델 훈련(model training), 사설 배포(private deployment), 모델 비교가 목적이라면 이야기가 달라집니다. 첫 단계는 공식 화면에 입력할 수 있는 수준이면 충분합니다. 매주 사용하는 방식을 저장하는 단계부터는 자신의 PC에 DeepSeek Harness를 한 번 설치해야 합니다. Harness 사용법과 실행 명령어는 2026년 11월 기준의 공식 문서를 참고했습니다.

이 단계는 DeepSeek의 공식 채팅이나 공식 앱에서 시도해 볼 수 있습니다. 아직 로컬 도구는 필요하지 않습니다. 바꿀 것은 기능이 아니라, 이번 요청의 경계입니다.

변경 전

주간 보고서를 써줘.

변경 후: 그대로 복사하여 사용할 수 있는 요청

【나는 누구인가】 콘텐츠 운영 담당자입니다. 이 주간 보고서는 부서 책임자를 위한 것입니다.
【무엇이 필요한가】 아래 작업 기록을 '금주 진행 상황・직면한 문제점・다음 주 계획'의 3개 항목으로 정리해 주세요. 전체 분량은 400~600자입니다. 각 항목은 먼저 결론을 제시하고, 그 뒤에 근거가 되는 사실을 작성해 주세요.
【절대 하지 말아야 할 것】 미완료를 완료된 것처럼 쓰지 마세요. 공허한 슬로건을 사용하지 말고, 기록에 없는 숫자를 보충하지 마세요. 기록에 없는 것은 '기록에 없음'이라고 적어주세요.
...

여기에 있는 것은 특별한 정형 문구가 아닙니다. 읽는 사람(독자), 형식, 그리고 경계를 이번 요청으로 작성했을 뿐입니다. 지시사항과 자료의 구분은 이 예시처럼 한 가지로 충분합니다. 여러 개를 동시에 섞을 필요가 없습니다. 반복되는 요구 사항을 위에 두고, 매번 바뀌는 기록을 아래에 두면, 다음 주에 어디를 교체해야 할지 명확해집니다. 채팅에서 사고 모드(thinking mode)가 이미 켜져 있다면, '한 단계씩 생각해 주세요'라고 덧붙여 쓸 필요는 없습니다.

지난주 실제로 보냈던 문장을 이 형태로 다시 작성하여 공식 채팅에 한 번 보내보세요. 점수를 보는 것이 아닙니다. 예를 들어, 답변의 두 번째 단락에 기록에 근거한 구체적인 사실이 남아있는지 여부입니다. 한 번의 요청을 제대로 고치지 못한 채 매주 시스템으로 나아가도, 모호함만 저장될 뿐입니다.

같은 주의를 다음 주에도 계속 작성하고 있다면, 그 부분은 스킬(skill), 즉 저장된 방식에 적합합니다. 여기서 사용하는 DeepSeek Harness는 공식 채팅 화면의 숨겨진 버튼이 아닙니다. 공식적인 로컬에서 구동되는 오픈소스 도구입니다. 현재는 developer preview 상태이며, 나중에 호환성을 깨뜨리는 변경이 있을 수 있습니다.

먼저 Node.js를 설치해 주세요. 현재 요구 사항은 Node.js 24.9 이상입니다. Node 22는 더 이상 지원되지 않습니다. 설치한 후, 같은 터미널에서 node --version을 실행하여 확인합니다. 다음으로 다음 명령어를 실행합니다.

npx @deepseek-ai/dsh web

최초 실행 시에는 npx를 통해 @deepseek-ai/dsh를 설치할지 묻는 경우가 있습니다. 그럴 때는 '예'를 선택하세요. 그 후 다운로드와 초기화가 진행되며, 다소 시간이 걸릴 수 있습니다. 기본 대기 주소는 127.0.0.1:3080이지만, 열어야 하는 것은 터미널에 표시된, 원타임 토큰을 포함한 전체 URL입니다. 로컬 실행 시에는 브라우저가 자동으로 열리는 경우가 많습니다. 열리지 않는다면, 그 한 줄을 그대로 브라우저에 붙여넣으세요. 토큰이 없는 http://127.0.0.1:3080만 열면 401 에러가 나며 접속할 수 없습니다. 터미널은 닫지 않은 상태로 유지해 주세요. 닫으면 화면도 멈춥니다.

화면의 '설정 → 모델'로 이동하여 DeepSeek API 키 획득 페이지에서 얻은 키를 붙여넣고 저장합니다. 저장 후에는 재부팅이 필요 없습니다. 다음으로 '워크스페이스 선택'을 누르고, 자료를 보관할 폴더를 추가하여 선택합니다. 선택하기 전까지는 입력란을 사용할 수 없습니다. 선택한 후부터 에이전트는 해당 워크스페이스의 파일을 이미 읽고 쓰거나 명령을 실행할 수 있습니다. 파일만 읽기 위한 플러그인은 여기서는 필요하지 않습니다.

주간 보고서용 스킬 식별자는 zhoubao로 유지해도 무방합니다. 선택한 워크스페이스에 .dsh/skills/zhoubao/SKILL.md 파일을 만들고 다음 내용을 넣습니다. 선택한 워크스페이스가 Git 리포지토리의 서브 디렉터리라면, 스킬은 리포지토리 루트의 .dsh/skills에 위치시킵니다.

---
name: zhoubao
description: "작업 기록에서 주간 보고서를 작성하거나 정리하거나 확인해 달라고 요청받았을 때 사용합니다."
...

name과 description은 필수입니다. description은 성능을 자랑하는 칸이 아니라, 언제 사용할지 적는 칸입니다. Harness는 먼저 이름과 설명을 봅니다. 본문은 실제로 사용할 때 읽습니다. 필요하다면, 입력란에 /zhoubao라고 작성하여 호출할 수 있습니다. 저장 후 재부팅은 보통 필요하지 않습니다. 스킬 목록에 이름과 description이 표시되는지 확인하고, 실제 주간 보고서 작업을 세 번 시도해 보세요. 세 번 모두 발동되지 않으면, 본문보다 먼저 description을 수정합니다. 평소 요청하는 말투와 더 가깝게 만드는 것이 우선입니다.

처음에는 SKILL.md만으로 충분합니다. 스킬은 스킬용 루트 바로 아래에 있는 이름/SKILL.md 또는 평평한 구조의 이름.md로 배치할 수 있습니다. 그보다 깊은 중첩(nesting)은 만들지 않습니다. 나중에 scripts/나 references/가 필요하더라도, 그것들은 SKILL.md의 형제 디렉터리이며, 그 안에 있는 것은 아닙니다. .agents/skills도 스캔되지만, 우선순위가 낮으므로 이 첫 번째 예시에서는 사용하지 않습니다.

여기서 말하는 '지식 기반(Knowledge Base)'은 제품에 독립된 버튼이 아닙니다. 선택한 워크스페이스(작업 폴더)의 파일을 이름과 경로로 찾을 수 있도록 정리하는 것을 의미합니다. 이전 절에서 설명했듯이, 워크스페이스를 선택하는 순간 Harness 에이전트는 이미 파일을 읽을 수 있습니다. 읽기 전용 플러그인을 추가할 문제가 아닙니다.

예를 들어 폴더에 다음 네 개의 파일이 있다고 가정해 봅시다. 파일 내용과 업무 규칙 모두 설명을 위한 가짜입니다.

01-패키지 및 견적서.md
02-환불 정책.md
03-세금계산서 설명.md
...

위에서부터 순서대로, 요금과 견적, 환불 정책, 청구서, 그리고 '새 텍스트 문서 (2).md'와 같은 기본 이름입니다. "고객이 299 플랜을 구매했고, 5일째에 환불하고 싶어 합니다. 무엇을 처리해야 할까요?"라는 질문을 받았을 때, 마지막 파일은 이름만으로는 놓치기 쉽습니다.

실제로는 그 파일에 환불에는 추가 티켓이 필요하며, 관리 화면에서 먼저 제출해야 하고, 번호는 RF-로 시작하며, 번호가 없으면 거절된다고 적혀 있다는 설정입니다. 이름을 04-환불 작업 티켓 규칙.md (환불 티켓 규칙)으로 바꾸면, 폴더 목록 자체가 찾는 단서가 됩니다. 파일을 열어보지 않아도, 환불에 대한 질문이라면 어디를 봐야 할지 알 수 있습니다. 파일 이름과 경로가 그 단서입니다.

자주 사용하는 자료 폴더부터 손대세요. '새로'나 '최종본2' 같은 이름을 내용을 알 수 있는 이름으로 변경합니다. 하나의 파일에는 하나의 주제만 담습니다. 신구(新舊)를 구분해야 한다면, 날짜나 버전을 이름에 넣습니다. 지금 필요한 것은 찾을 수 있는 이름이지, 갑자기 벡터 검색 메커니즘을 구축하는 것이 아닙니다.

확인도 간단합니다. 자료 속에 확실히 답이 있는 질문 하나를 던지고, 이어서 "이 문장은 어느 파일의 몇 번째 단락인가요?"라고 물어봅니다. 답을 찾지 못했다면, 먼저 워크스페이스가 적절한지, 파일이 들어있는지, 이름이 명확한지를 확인합니다. 모델을 바꾸거나 파일 읽기 플러그인을 추가하는 것은 그 이후의 일입니다.

나중에 현재 게시된 DeepSeek 모델을 확인하고 싶을 때도 있습니다. 그럴 때는 DeepSeek 모델 카탈로그를 보면 됩니다. 페이지에서 현재 목록을 직접 확인하고 싶다면, Crazyrouter를 통해 현재 사용 가능한 DeepSeek 모델을 확인할 수 있습니다. 이는 이 경로를 시작하기 위한 필수 설정은 아닙니다. 지금까지의 기본 과정은 공식 채팅과 Harness에 공식 DeepSeek API 키를 입력하는 것입니다.

플러그인은 추가 기능입니다. 인터넷 검색이나 워크스페이스 외부 시스템과의 연결 등, 다음에 필요할 작업이 구체화된 후에 생각해도 늦지 않습니다. Git에서 설치할 경우의 명령어는 다음과 같은 형태입니다. #[커밋]

으로 특정 커밋에 고정합니다.

npx @deepseek-ai/dsh plugin --profile web add github:owner/repo#<commit>

전역 설치가 되어 있다면, dsh plugin --profile web add ...도 사용할 수 있습니다. 번들 플러그인을 추가한 후에는 dsh web을 한 번 재시작합니다. 빌드 스크립트가 거부되어 실패했다면, 터미널의 지침에 따라 빌드를 허용하고 다시 실행해야 합니다.

다음과 같은 경우에는 아직 추가할 수 없습니다.

• 다음에 요청할 구체적인 작업을 말할 수 없을 때.
• Git에서 추가하더라도 커밋을 고정하지 않고 내용이나 스크립트를 확인하지 않았을 때.
• 소스를 신뢰할 수 없거나, 확인 대화 상자의 소스를 읽지 않았을 때.

플러그인 인덱스에 공식 내장 소스가 포함되어 있는 것은 아닙니다. 내용은 스스로 추가한 제3자 소스에서 비롯됩니다. 프로그램이 검사하는 것은 파일 형식이지, 작성된 주장의 정확성이 아닙니다. 신뢰할 수 있는 소스만 추가하고, 넣기 전에 확인 대화 상자의 소스를 읽어보세요.

추가했다면, 하나의 작업으로 테스트해봅니다. 인터넷 검색이 필요하다면, 시간이 지남에 따라 변할 수 있는 소프트웨어 버전을 조사하여 출처와 대조하는 것이 적절합니다. '워크스페이스 파일 읽기' 기능만으로는 인터넷 검색 플러그인의 유효성을 확인할 수 없습니다.

요청문(依頼文), 스킬(skill), 파일명, 플러그인은 각각 다른 역할을 합니다. 이번 회차의 조건은 요청문에 두세요. 매주 지켜야 하는 작성 방식은 스킬에 두세요. 근거가 되는 자료는 찾을 수 있는 이름으로 워크스페이스에 두세요. 워크스페이스 외부의 작업이 필요할 때만 플러그인에 두세요. 이렇게 분리해 놓으면, 주간 보고서 내용이 흔들릴 때도 수정해야 할 부분을 좁힐 수 있습니다.

이 일련의 과정은 구식이 됩니다. 게다가 사용할수록 빨리 구식이 됩니다. 스킬의 description이 몇 달 전 작업 그대로라면 더 이상 작동하지 않습니다. 설령 작동하더라도, 현재 항목이나 기준과 벗어난 절차를 따르기도 합니다. 폴더에 '최종본2'나 '신규'가 늘어나면 다시 찾기 어려워집니다. 플러그인은 본체 업데이트 이후 호환되지 않을 수도 있습니다.

한 달에 한 번, 짧게 검토하면 충분합니다. 세 달 동안 작동하지 않은 스킬은 삭제하세요. 내용이 불분명한 파일명은 변경하세요. 플러그인은 본체에 맞추고 테스트 버전을 쫓지 마세요. 계속 늘리는 것보다 다음 주에도 다룰 수 있는 크기로 유지하는 것이 중요합니다.

우선 하나를 한다면, 매주 반복되는 작업을 가져와서 그 방법을 하나의 SKILL.md에 작성하세요. 다른 사람에게 보여줄 필요는 없습니다. 다음 주 자신이 사용할 수 있다면 그것으로 충분합니다.