dots에 업무를 위임할 때: '작업', '실행 장소', '결과' 세 가지로 분리하여 인계하기

오랫동안 지속되는 코딩 작업을 dots에 맡길 때, 대화 기록만을 인계의 중심으로 삼으면 현재 파일과 완료된 확인을 혼동하기 쉽습니다.

이 글의 결론은 업무 식별자(仕事の識別子), 실행 장소(実行場所), 결과(成果)를 별개로 관리하는 것입니다. 공식 기능 설명과 독자적인 상태 관리 방안을 나누어 정리했습니다. 본문은 제품의 비공개 API나 자동 게시 기능을 구현하는 글이 아닙니다.

작업의 연속성은 대화의 연속성만으로 결정되지 않는다

dots는 로컬의 Work/Codex 태스크나 준비된 클라우드 환경의 코드 작업을 위임할 수 있습니다. 기존 로컬 태스크를 계속 진행하려면, 해당 태스크와 원래 연결된 PC를 특정해야 합니다. 연결 대상을 변경해도 기존 태스크가 이동하는 것은 아닙니다. (공식 태스크 설명)

또한, dots 자체 클라우드 PC와 사용자의 PC는 파일이나 브라우저 세션이 별개입니다. 로컬 개인 스킬에도 연결 PC가 필요합니다. (컴퓨터와 앱의 공식 설명)

따라서 인계에는 '이전과 같은 것을 부탁해'만으로는 부족할 때가 있다고 생각합니다. 이는 기능의 결함이라기보다는, 실행 환경에 의존하는 작업을 위임하기 위한 설계상의 주의사항입니다.

세 가지 식별자를 혼합하지 않기

이 세 가지를 분리하면, '요청은 같지만, 태스크도 같고, 결과만 수정한 경우'와 '요건이 바뀌었으므로 다음 요청을 만드는 경우'와 같이 판단할 수 있습니다. 본문에서 사용하는 기록 형식은 독자적인 안이며, dots의 내장 스키마가 아닙니다.

인계를 작은 계약서처럼 작성하기

가상의 마법사 공방 연구소에서 메모 앱 검색 표시를 수정한다면, 인계는 다음과 같이 할 수 있습니다.

목적: 검색 결과가 비어 있어도 안내와 기존 조작을 읽기 쉽게 유지한다.
입력: 채택된 사양의 버전, 대상 리포지토리 및 현재 변경 상태.
실행 장소: 획득된 태스크의 원래 연결 PC/클라우드 환경.
...

긴 작업에서는 최신 지시 사항을 위에 쌓는 것뿐만 아니라, 채택 조건을 하나의 짧은 문서로 정리합니다. 중요한 제약 조건이 취소되었는지, 아니면 이전 조건에 추가된 것인지도 알 수 있는 형태로 만듭니다.

다만, 이 문서는 권한을 새로 부여하는 것이 아닙니다. 연결 앱의 접근 설정, 인증, 실행 환경의 제약은 별도로 성립되어야 합니다.

재개 시에는 전송 결과 불명(不明)을 저장하기

통신이 끊겼을 때 '실패했으니 다시'는 편리하지만, 수신자에게 업무가 이미 생성되어 있다면 중복 요청이 됩니다.

독자적인 장부에서는 다음의 전환을 고려합니다.

prepared → submitting → running → result-reported → verified
↓ 응답 없음
unknown → 기존 업무와의 대조

이들은 설명용 상태 이름일 뿐, 제품 화면 레이블은 아닙니다. 중요한 것은 unknown을 prepared로 자동 복귀시키지 않는 것입니다.

실 ID와 상태로부터 다음 행동을 결정하는 작은 함수는 다음과 같이 작성할 수 있습니다.

def next_action(record):
task_id = record.get(

## 관측과 보고의 차이를 복구 절차로 바꾸기

공식 자료에서도 실행이 종료되었다고 해서 요청한 결과가 달성되거나 납품된 것을 확인했다고 보지 않는다고 설명하고 있습니다. 결과 확인에 관한 공식 설명입니다.

복구할 때는 다음 순서대로 확인합니다.

- 동일한 실(實) 작업이 존재하는가? 아직 ID를 얻지 못했다면, 먼저 기존 작업을 대조한다.
- 원래의 실행 환경을 사용할 수 있는가? 연결 PC의 오프라인 상태를 작업 이동 완료로 간주하지 않는다.
- 현재 입력 버전과 성과를 만들었을 때의 입력이 일치하는가?
- 파일과 확인 결과가 존재하는가? 보고서와 실물을 대조한다.
- 미확인 사항을 다음에 할 확인할 내용으로 구체화할 수 있는가?

이 절차를 매번 다시 할 필요는 없습니다. 이미 확인된 것은 증거를 남기고, 변경된 입력이나 성과와 관련된 부분을 재확인합니다.

위임의 편리함을 유지하기 위해서는 AI의 보고를 늘리는 것뿐만 아니라, 사람이나 다음 담당 에이전트가 복구할 수 있는 기록을 만드는 것이 중요하다고 생각합니다.

## 참고 자료

2026년 10월 6일에 확인한 공개 1차 자료입니다. 상태 관리, 요청 예시, 로컬 코드는 자체적인 설계입니다.

## 관련 설명

### Discussion

![](https://static.zenn.studio/images/drawing/discussion.png)