2026 DeepSeek Harness Agent Preset은 시스템급과 사용자급 중 어디에 둘까?

사용자급 프리셋을 고쳤는데 다른 계정의 실행 결과까지 바뀝니다.
개인 실험은 사용자급에 두고, 팀 기준은 시스템급 읽기 전용으로 배포하십시오. 공유 맥이라면 두 계층을 결합하되 동명 충돌과 변경 책임을 먼저 검증해야 합니다.

이 글은 개인 에이전트 조합을 보존하면서 다른 사용자의 환경을 건드리고 싶지 않은 개발자를 위한 글입니다. 팀에 같은 프리셋을 배포하는 플랫폼 관리자와 공유 또는 클라우드 맥의 쓰기 권한을 관리하는 보안 담당자도 대상입니다.

DeepSeek Harness는 기능을 여러 구성 요소로 조합하는 구조이며 Cordis를 기반으로 합니다. 현재 공식 저장소는 개발자 미리보기 상태로 안내되고 있으므로, 설정 경로와 우선순위는 오래된 게시물이 아니라 설치된 릴리스의 공식 선언과 소스로 확인해야 합니다. 공식 저장소의 현재 안내에서도 호환성 변경 가능성을 먼저 확인할 수 있습니다.

SECTION 01위치보다 먼저 출처 신뢰를 정해야 합니다

DeepSeek Harness 에이전트 프리셋을 시스템급에 둘지 사용자급에 둘지는 어느 폴더가 편한지로 결정하면 안 됩니다. 핵심은 누가 만들었고, 누가 검토했으며, 문제가 생겼을 때 누가 원래 상태로 되돌릴 것인지입니다.

사용자급 프리셋은 다음과 같은 작업에 적합합니다.

• 개인이 반복 작업을 빠르게 조합하는 실험용 흐름
• 특정 프로젝트에서만 사용하는 임시 도구 묶음
• 아직 팀 검토를 거치지 않은 지시문과 실행 순서
• 개인 작업 방식에 맞춘 출력 형식과 보조 에이전트 구성

반대로 시스템급은 다음 조건에서 선택해야 합니다.

• 여러 계정에서 같은 동작을 재현해야 합니다.
• 새 원격 맥이나 재설치 환경에 다시 배포해야 합니다.
• 변경 승인자와 운영 담당자가 정해져 있습니다.
• 이전 버전으로 되돌릴 증거가 필요합니다.
• 고객 프로젝트나 보안 경계를 동일하게 유지해야 합니다.

사용자가 직접 작성했거나 에이전트가 생성한 프리셋이 오류 없이 불러와졌다고 해서 신뢰된 기준이 되는 것은 아닙니다. 로드 성공은 문법과 발견 여부를 보여줄 뿐이며, 출처 검토와 실제 동작 검증을 대신하지 않습니다.

에이전트 프리셋은 권한 프리셋과 같은 개념도 아닙니다. 실행 허용 범위를 정하는 권한 설정, 작업 계획을 표현하는 플랜 모드, 기능을 발견하고 조합하는 스킬을 하나로 묶으면 책임 경계가 흐려집니다. 이 글에서 다루는 대상은 에이전트의 조합과 기본 동작을 배포하는 에이전트 프리셋입니다.

SECTION 02첫 단계: 스캔 순서와 동명 처리를 확인하십시오

공식 설정 선언에는 프리셋을 찾는 여러 스캔 루트, 기본 프리셋, 사용자 루트의 활성화 여부, 시스템과 사용자 신뢰 유형이 구분되어 있습니다. 따라서 “DeepSeek Harness 사용자 설정은 어느 디렉터리에 저장하는가”라는 질문에 예전 경로 하나만 답하는 방식은 위험합니다. 실제 내장 경로와 화면 진입점은 릴리스에 따라 달라질 수 있으므로, 사용 중인 버전의 선언과 소스를 함께 대조해야 합니다.

공식 릴리스 목록을 확인한 뒤, 팀 문서에는 경로만 적지 말고 확인한 릴리스와 날짜도 남기십시오. 설정 규칙이 바뀌면 경로 문서와 배포 스크립트를 함께 갱신해야 합니다.

같은 아이디의 에이전트 프리셋이 시스템급과 사용자급에 동시에 있으면 화면에는 이름만 보이고 실제 출처가 드러나지 않을 수 있습니다. 이때는 가장 작은 동명 테스트를 실행하십시오.

첫째, 시스템급에는 식별 가능한 출력 하나만 넣습니다.
둘째, 사용자급에는 같은 아이디와 다른 출력을 넣습니다.
셋째, 민감한 값과 외부 도구 연결은 모두 제거합니다.
넷째, 새 세션에서 프리셋을 다시 불러옵니다.
다섯째, 실제 결과와 실행 로그를 함께 기록합니다.
마지막으로 확인이 끝난 테스트용 아이디를 삭제합니다.

이 검증 없이 화면에 보이는 이름만 보고 시스템급이 우선인지 사용자급이 덮어쓰는지 단정하면 안 됩니다. 공식 소스의 스캔 순서와 중복 아이디 처리 결과가 확인되지 않았다면, 같은 아이디를 두 루트에 배치하지 않는 것이 안전합니다.

주의: 프리셋의 이름, 표시 순서, 설치 위치는 서로 다른 정보입니다. 동명 테스트에서 실제 적용 출처를 확인하지 못했다면 해당 아이디를 팀 표준으로 배포하지 마십시오.

SECTION 03시스템급은 다시 만들 수 있어야 의미가 있습니다

팀 배포에서 시스템급을 선택하는 이유는 모든 사용자가 같은 폴더를 보기 때문만은 아닙니다. 새 원격 맥을 만들거나 환경을 재설치할 때 동일한 버전을 다시 배포할 수 있어야 하기 때문입니다.

운영 기준은 다음처럼 잡으십시오.

• 원본은 검토 가능한 저장소나 릴리스 보관 위치에서 관리합니다.
• 프리셋 아이디와 버전을 배포 기록에 남깁니다.
• 일반 사용자는 파일을 읽을 수만 있고 직접 수정할 수 없게 합니다.
• 변경 요청은 복사본에서 검토한 뒤 새 버전으로 승격합니다.
• 이전 버전과 현재 버전을 함께 보관해 즉시 회수할 수 있게 합니다.
• 배포 후 동명 테스트와 대표 작업으로 적용 결과를 확인합니다.

시스템급 파일을 운영자가 알 수 없는 사용자 폴더에서 수동으로 복사하는 방식은 재현 가능한 배포가 아닙니다. 어떤 원본을 사용했는지, 누가 바꾸었는지, 어느 버전에서 문제가 시작되었는지 설명할 수 없기 때문입니다.

DeepSeek Harness가 개발자 미리보기 단계라면 프리셋을 애플리케이션 버전에 종속된 산출물로 취급해야 합니다. 공식 개발 문서에서 사용하는 릴리스의 변경 사항과 호환성 조건을 다시 확인하십시오. 구조가 달라지거나 신뢰 모델이 변경되면 기존 프리셋을 그대로 복사하지 말고 격리 환경에서 먼저 재검증해야 합니다.

설계 구조를 검토해야 한다면 공식 구조 문서도 함께 확인하십시오. 구조 설명은 배포 경로 자체를 확정하는 자료가 아니지만, 어떤 구성 요소가 실행 흐름에 관여하는지 확인하는 데 도움이 됩니다.

장면 사례: 새 원격 맥에서만 결과가 달라진 경우

플랫폼 관리자가 팀용 에이전트 프리셋을 사용자급 루트에만 복사하면 기존 계정에서는 정상적으로 보일 수 있습니다. 그러나 새 계정이나 재생성된 원격 맥에서는 사용자 루트가 비어 있어 기본 프리셋이 선택될 수 있습니다. 사용자는 “같은 프리셋을 배포했다”고 생각하지만 실제로는 서로 다른 출처를 사용한 상태입니다.

이 문제는 시스템급 읽기 전용 기준을 먼저 설치하고, 계정별 사용자급 확장을 별도로 생성할 때 줄어듭니다. 새 맥 검수에서는 파일 존재 여부보다 다음 항목을 확인하십시오.

• 기대한 시스템급 루트가 실제로 검색되는가
• 동명 사용자급 프리셋이 기준을 바꾸지 않는가
• 기준 버전으로 되돌렸을 때 대표 작업이 다시 재현되는가

SECTION 04사용자급은 개인 반복 작업에만 남겨야 합니다

사용자급을 없애면 개인 반복 작업의 개선 속도가 떨어집니다. 모든 작은 실험을 운영 승인 절차로 보내면 개발자는 우회 복사본을 만들고, 플랫폼팀이 모르는 설정이 늘어날 수 있습니다. 따라서 사용자급은 허용하되 범위를 좁혀야 합니다.

사용자급에 남겨도 되는 항목은 개인 도구 조합, 임시 실험, 프로젝트별 출력 선호, 아직 팀 기준으로 채택하지 않은 작업 흐름입니다. 반면 다음 항목은 사용자급에 두지 않는 편이 좋습니다.

• 팀이 반드시 동일하게 적용해야 하는 보안 경계
• 인증 정보, 접근 토큰, 고객별 비밀값
• 승인되지 않은 외부 도구 연결
• 배포 산출물에 포함되는 기본 실행 규칙
• 장애 발생 시 반드시 추적해야 하는 변경 기준

사용자급 프리셋을 쓰더라도 개인 계정의 홈 영역과 프로젝트 작업 영역을 구분하십시오. 프리셋 안에 비밀값을 직접 넣지 말고, 필요한 인증은 별도의 권한 관리 체계에 맡겨야 합니다. 에이전트 프리셋은 실행 조합을 설명하는 구성이지 권한과 비밀의 저장소가 아닙니다.

SECTION 05공유 맥에서는 어떤 운영 모델이 적합할까요?

공유 맥에서는 세 가지 운영 모델을 비교할 수 있습니다.

시스템급 읽기 전용 기준

팀 공통 작업이 중심이고, 계정별 변경을 허용하면 고객 작업이나 보안 기준이 흔들리는 경우에 적합합니다.

장점

• 기준 버전과 배포 책임이 분명합니다.
• 새 계정에서도 같은 동작을 재현하기 쉽습니다.
• 사고 후 시스템 기준을 다시 배포하기 쉽습니다.

단점

• 개인 실험을 별도 사용자급 영역에 남겨야 합니다.
• 빠른 수정에도 검토와 새 버전 발행이 필요합니다.

시스템급 기준과 사용자급 제한 확장

개인 실험은 허용하지만 팀 기준을 훼손하면 안 되는 공유 맥에 가장 적합합니다. 시스템급은 읽기 전용으로 잠그고, 사용자는 별도 아이디의 사용자급 프리셋만 만들게 합니다.

장점

• 팀 기준과 개인 생산성을 동시에 유지합니다.
• 동명 충돌을 정책으로 금지하거나 검수할 수 있습니다.
• 사용자 변경을 회수할 때 계정 단위로 처리할 수 있습니다.

단점

• 두 루트의 스캔 결과를 계속 검증해야 합니다.
• 사용자급 확장이 기준 프리셋과 혼동되지 않도록 이름 규칙이 필요합니다.

계정과 프리셋 루트를 완전히 분리

고객 프로젝트, 외부 협력자, 서로 다른 보안 등급의 작업이 한 맥에 섞이는 경우에는 이 모델을 선택해야 합니다. 계정만 나누고 같은 쓰기 가능한 프리셋 루트를 공유하면 완전한 격리가 아닙니다.

Cordis는 아직 개발 중이며 API가 안정되지 않았다고 공식 저장소에 안내되어 있습니다. 따라서 Cordis의 구조적 장점을 이유로 공유 맥의 권한 분리를 생략해서는 안 됩니다. Cordis 공식 저장소를 참고하되, 실제 배포 정책은 DeepSeek Harness의 현재 설정과 권한 모델을 기준으로 정하십시오.

조건별 선택

• 개인 실험이고 다른 계정에 영향을 주면 안 된다면 사용자급을 선택하십시오.
• 팀이 같은 버전을 반복 배포해야 한다면 시스템급 읽기 전용을 선택하십시오.
• 공유 맥에서 개인 확장이 필요하지만 기준 변경은 막아야 한다면 시스템급 기준과 사용자급 제한 확장을 결합하십시오.
• 고객 경계나 계정 격리가 불분명하다면 같은 프리셋 루트를 공유하지 말고 별도 계정 또는 별도 맥으로 되돌리십시오.
• 동명 우선순위를 확인하지 못했다면 시스템급과 사용자급에 같은 아이디를 배치하지 마십시오.

배치 방식 비교

배포 전 검수 항목

팀용 DeepSeek Harness Agent Preset을 운영할 때는 현재 릴리스의 변경 내역과 설정 선언을 함께 보관하십시오. 공식 문서에 표시된 기본 실행 방식이 프리셋의 신뢰 출처나 권한 분리를 보장하는 것은 아닙니다. 실행 방식과 구성 소유권은 별도로 검수해야 합니다.

FAQ에서 설명한 것처럼 실제 디렉터리는 설치 버전의 공식 설정 선언과 실행 로그로 확인해야 합니다. 팀 문서에는 경로만 적지 말고 릴리스, 확인 날짜, 권한, 동명 검증 결과, 회수 버전을 함께 적으십시오.

현재 직접 맥을 관리하거나 매번 환경을 다시 만들기 어렵다면, 개인 설정을 그대로 공유하는 방식보다 계정과 기준 프리셋을 분리할 수 있는 원격 환경이 유리합니다. 로컬 맥은 사용자가 임의로 파일을 바꾸기 쉽고, 공유 계정은 변경 주체가 불분명하며, 재설치 때 수동 복사에 의존하기 쉽습니다. MACNOX의 원격 맥 환경을 검토할 때도 시스템급 기준, 사용자급 확장, 계정별 접근 책임을 먼저 정한 뒤 필요한 환경만 선택하십시오. 장기적으로 고정된 고부하 작업이나 물리 장비 접근이 필요한 경우에는 직접 구매가 더 적합할 수 있지만, 임시 팀 테스트와 재현 가능한 배포 환경이 목적이라면 맥 렌탈 요금 안내와 실제 사용 기간을 함께 비교하는 편이 낫습니다. MACNOX에서 원격 맥을 사용할 때도 프리셋을 무조건 사용자급에 복사하기보다, 읽기 전용 기준과 개인 확장을 분리하는 운영 방식을 적용해야 합니다.