2026 딥시크 하네스 작업 패널 자식 에이전트 분업

2026년 8월 18일 기준

코덱스 공식 안내에서 단일 작업은 일반적으로 1분에서 30분이 걸릴 수 있다고 설명합니다. 코덱스 작업 방식 공식 안내처럼 작업 시간이 길어질수록 “누가 무엇을 끝냈는가”를 화면만 보고 판단하기 어려워집니다.

증상: 작업 패널에는 여러 자식 에이전트가 보이지만 같은 파일을 고치고, 실패 뒤 누가 다시 실행할지 정해져 있지 않습니다.
가장 빠른 해결: 코덱스나 클로드 코드라는 이름으로 분업하지 말고, 목표·입력·작업 공간·권한·검수 결과물·실패 담당자를 적은 작업 계약으로 나누세요.

이 글은 다음 독자를 위한 운영 안내입니다.

• 큰 작업을 여러 자식 에이전트에게 나누려는 개인 개발자
• 병렬 코드 작업과 저장소 쓰기 범위를 관리하는 작은 개발팀
• 원격 실행 환경, 권한, 작업 복구를 담당하는 플랫폼 엔지니어

마지막 업데이트: 2026년 8월 18일. 최신 릴리스, 구조 문서와 관련 코드 변경을 확인하는 기준으로 작성했습니다. 딥시크 하네스의 공개 저장소와 작업 실행 구조는 릴리스마다 달라질 수 있으므로, 실제 운영 전에는 현재 버전에서 다시 검증해야 합니다. 딥시크 하네스 공개 저장소

집중 관찰과 자동 격리는 서로 다릅니다

딥시크 하네스 작업 패널의 역할은 여러 작업을 한 화면에서 관찰하고, 입력이 필요한 지점을 찾고, 결과를 비교하는 데 있습니다. 이것만으로 다음 문제가 해결되지는 않습니다.

첫째, 작업 소유권 문제가 있습니다. 주 에이전트가 설정 파일을 고치고 자식 에이전트도 같은 설정 파일을 고치면, 두 결과 중 어느 것이 최종본인지 알 수 없습니다. 작업마다 고유한 식별자, 담당자, 변경 범위를 남겨야 합니다.

둘째, 작업 종류와 도구 능력의 불일치가 있습니다. 읽기 전용 조사에는 저장소 쓰기 권한이 필요하지 않습니다. 반대로 빌드와 테스트 작업에는 명령 실행 권한과 결과 로그가 필요합니다. 제품 이름만 보고 실제 기능이나 권한을 추정하면 안 됩니다.

셋째, 공유 작업 공간의 숨은 비용이 있습니다. 여러 에이전트가 같은 폴더에서 동시에 쓰면 파일 충돌뿐 아니라 생성된 임시 파일, 잠금 파일, 브랜치 기준점까지 섞입니다. 병렬 수를 늘리는 것이 항상 처리 시간을 줄이지는 않습니다.

넷째, 패널 권한과 운영체제 격리의 차이가 있습니다. 패널에서 작업을 숨기거나 분류해도 운영체제 수준에서 파일, 셸, 네트워크, 비밀 키가 격리되는 것은 아닙니다. 하네스의 권한 모델은 도구 목록, 환경 변수, 승인 정책과 함께 확인해야 합니다. 하네스 구조와 권한 모델 문서도 작업 지침과 권한을 별도 구성 요소로 설명합니다.

코덱스와 클로드 코드는 이름보다 작업 계약으로 나눕니다

코덱스는 공식 소개에서 독립 환경에서 저장소를 읽고 수정하며, 명령·테스트 결과와 함께 결과를 검토할 수 있는 흐름을 설명합니다. 코덱스의 독립 실행과 결과 검증은 코드 수정 담당을 설계할 때 참고할 수 있습니다.

클로드 코드는 동적 작업 흐름과 여러 에이전트 구성을 제공하지만, 앤트로픽도 복잡하고 장시간 이어지는 병렬 작업에서는 별도 흐름이 필요할 수 있다고 설명합니다. 클로드 코드의 동적 작업 흐름 안내 역시 도구 이름보다 작업 구조를 먼저 설계해야 한다는 근거가 됩니다.

따라서 다음처럼 나누는 편이 안전합니다.

1. 읽기 전용 조사: 저장소 구조, 오류 로그, 의존성, 테스트 위치를 파악합니다. 쓰기 권한과 배포 권한은 주지 않습니다.
2. 수정 작업: 한정된 경로만 쓰게 합니다. 수정 전 기준 커밋과 수정 후 차이 파일을 반드시 남깁니다.
3. 빌드와 테스트: 소스 변경보다 검증 명령 실행에 집중합니다. 실행 명령, 종료 결과, 실패 로그를 결과물로 요구합니다.
4. 외부 도구 작업: 네트워크, 계정, 비밀 값이 필요한 작업입니다. 승인 지점을 두고 기본값은 읽기 전용으로 설정합니다.
5. 최종 검토: 다른 에이전트가 만든 결과를 독립적으로 확인합니다. 직접 같은 파일을 다시 고치게 하지 말고, 승인·반려·재작업 중 하나만 결정하게 합니다.

클로드 코드의 최신 변경 기록에도 백그라운드 작업, 재연결, 권한과 작업 트리 관련 수정이 계속 나타납니다. 그러므로 현재 버전에서 보이는 상태 이름이나 재개 동작을 다른 도구에 그대로 적용하면 안 됩니다. 클로드 코드 변경 기록

공유 작업 공간과 격리 작업 공간은 쓰기 범위로 선택합니다

여러 자식 에이전트가 같은 저장소를 동시에 수정하는 방식은 읽기 작업에는 쓸 수 있지만, 쓰기 작업의 기본 전략으로 삼으면 안 됩니다.

공유 공간은 모든 에이전트가 같은 기준 파일을 읽어야 하고, 실제 수정은 한 담당자만 수행할 때 적합합니다. 예를 들어 조사 에이전트 여러 개가 같은 저장소를 읽고 각각 보고서만 만드는 경우입니다.

독립 공간은 두 작업이 서로 다른 경로를 수정하거나, 결과를 비교한 뒤 사람이 선택해야 할 때 적합합니다. 각 작업은 별도의 브랜치나 작업 트리에서 실행하고, 주 에이전트가 차이를 검토한 뒤 합칩니다.

순차 합치기는 같은 파일을 수정해야 할 때 사용합니다. 먼저 구조 변경을 끝내고 테스트한 뒤, 다음 에이전트가 그 결과를 기준으로 작은 수정을 수행합니다. 이 방식은 병렬성은 낮지만 실패 책임과 회귀 원인을 추적하기 쉽습니다.

작업을 시작하기 전에는 다음 5단계를 실행하세요.

1. 저장소 기준 커밋 또는 복사본을 고정합니다.
2. 작업 식별자와 담당자를 기록합니다.
3. 자식 에이전트별 읽기·쓰기 경로를 적습니다.
4. 실행 가능한 명령과 금지 명령을 분리합니다.
5. 종료 뒤 차이 파일, 테스트 결과, 로그 요약, 미완료 항목을 수집합니다.

실패 책임과 상태 복구를 분리해 기록합니다

작업이 취소되었거나 시간 초과가 발생했거나 주 프로세스가 종료된 경우, 패널에 남은 카드만 보고 실제 실행 상태를 판단하면 안 됩니다. 프로세스가 살아 있는지, 작업 기록이 저장됐는지, 마지막 명령이 성공했는지, 같은 입력으로 재실행해도 중복 수정이 없는지를 각각 확인해야 합니다.

실패 담당자는 다음 순서로 처리하는 것이 좋습니다.

• 자식 에이전트의 마지막 로그와 종료 원인을 확보합니다.
• 변경된 파일과 기준 커밋의 차이를 계산합니다.
• 테스트가 실행되었는지, 실행되었다면 어느 단계에서 멈췄는지 확인합니다.
• 재시작 가능한 작업과 처음부터 다시 해야 하는 작업을 나눕니다.
• 재실행 전 기존 작업 식별자를 잠그고, 새 실행에는 부모 작업과 재시도 번호를 붙입니다.
• 고위험 명령, 외부 네트워크, 배포와 비밀 값 접근은 사람의 승인 뒤에만 재개합니다.

하네스 기반 도구의 공개 문서가 작업 상태 저장이나 재개 명령을 제공하더라도, 그것이 모든 외부 자식 프로세스의 복구를 보장한다는 뜻은 아닙니다. 공개 하네스 실행 구조의 상태 저장과 승인 기록 예시처럼 저장소, 승인, 비용 기록이 분리되어 있는지 확인하고, 실제 Job Panel 연결 상태는 별도로 시험해야 합니다.

자주 묻는 운영 판단

딥시크 하네스 작업 패널을 어떻게 운영해야 하나요?

패널을 작업 목록으로만 쓰지 말고, 각 카드에 작업 계약의 핵심만 표시하세요. 목표, 담당자, 작업 공간, 쓰기 여부, 승인 필요 여부, 예상 결과물과 실패 담당자를 한 줄씩 기록합니다. 작업이 끝나면 상태 표시보다 실제 차이 파일과 검수 로그를 기준으로 완료를 확정해야 합니다.

여러 작업을 동시에 실행하면 항상 빠른가요?

아닙니다. 서로 다른 파일을 수정하고 각각 독립적으로 검수할 수 있을 때만 병렬 실행의 이점이 생깁니다. 같은 구성 파일, 데이터베이스 스키마, 패키지 잠금 파일을 건드리면 병렬 실행이 오히려 충돌 조사와 재검증 시간을 늘립니다.

작업 계약으로 고르는 3가지 실행 방식

아래 조건은 제품 선택표가 아니라 책임 분배표입니다.

• 목표가 하나이고, 수정 범위가 좁으며, 사람이 즉시 검토할 수 있으면 단일 자식 에이전트를 선택합니다.
• 조사, 수정, 테스트가 서로 다른 단계이고 앞 단계 결과를 다음 단계가 받아야 하면 순차 다중 자식 에이전트를 선택합니다.
• 작업 공간과 쓰기 범위가 완전히 분리되고, 각 결과를 독립적으로 검수할 수 있으면 격리 병렬 실행을 선택합니다.
• 같은 파일을 두 작업이 고쳐야 하면 병렬을 취소하고 순차 합치기로 되돌립니다.
• 비밀 값, 배포 명령, 데이터 삭제가 포함되면 어떤 방식이든 사람 승인과 수동 인수를 추가합니다.
• 상태 저장과 재개 동작을 공식 문서나 실제 시험으로 확인하지 못했다면 주 프로세스 종료 시 실패 처리를 기본값으로 둡니다.

Mac 실행 환경을 붙일 때 확인할 기준

로컬 장비에서 여러 작업을 돌리면 권한과 파일 충돌을 직접 관리해야 합니다. 반면 원격 Mac 환경을 쓰면 작업별 실행 공간, 연결 방식, 용량 계획을 별도로 설계할 수 있습니다. 다만 원격 환경도 자동으로 안전해지는 것은 아니며, 각 작업의 계정·키·네트워크 범위를 제한해야 합니다.

운영 환경의 격리가 중요한 경우에는 베어메탈과 가상화 Mac 환경 비교를 먼저 확인하세요. 여러 작업을 장기간 유지해야 한다면 서울 Mac 연산 노드 구성처럼 지역과 노드 배치를 함께 검토하는 편이 낫습니다.

현재 방식이 한 대의 Mac에서 모든 자식 에이전트를 같은 폴더와 계정으로 실행하는 구조라면, 파일 충돌뿐 아니라 비밀 값 공유, 프로세스 종료 뒤 상태 확인, 작업별 비용 추적도 어려워집니다. 장기 병렬 운영에서는 이런 문제가 누적되어 단순한 패널 사용보다 격리된 원격 Mac 환경이 관리하기 쉬운 경우가 많습니다. 다만 장기간 고정된 고부하 작업이나 물리 장치 연결이 필수라면 직접 장비를 운영하는 편이 더 적합합니다.

먼저 서로 영향을 주지 않는 저위험 작업 2개를 Job Panel에 등록해 읽기 전용 조사와 제한된 코드 수정을 각각 시험하세요. 결과물과 실패 복구가 확인된 뒤에만 병렬 수를 늘리는 순서가 안전합니다. 일시적인 테스트 환경이나 팀별 격리 실행이 필요하다면 MacDate의 원격 Mac 구성을 비교해 보고, 장기 운영에 필요한 저장 공간과 접속 정책까지 함께 계산하는 것이 좋습니다.