작업 시나리오 3편: 실제 세션 협업 · 스튜디오 팀 · 제조
문서 발행일: 2026-09-30
소개 및 공통 규칙
위임장·작업 ID·중앙 원장 구조로 여러 봇이 한 사람의 권한으로 일하는 모습을 세 가지로 따라간다. 시나리오 1은 이 설계가 나온 실제 사례이고, 같은 일을 새 구조로 했을 때와 비교한다. 시나리오 2·3 은 새 구조를 전제로 한 예시이며, 시각·금액·ID 는 설명용이다. 허브·관찰 세션·구매 연동 등은 아직 설계 단계다.
공통 규칙 요약
위임장은 봉인된 채 이동하고, 봇 컨테이너 안에서 세션 전용 파생 키로만 풀린다. 모델은 delegation_info 도구로만 읽는다.
재위임은 넘길수록 줄어든다: 범위는 부모의 부분집합, 한도는 부모 잔량에서 예약한다.
돈이 나가는 일(purchase)과 계정 밖으로 보내는 일(send_artifact)은 전용 도구로만 하고, 건당 한도를 넘거나 계정 밖이면 사람이 승인한다. 봇은 결제 수단·외부 도구 자격을 보지 못한다.
감사 기록에 의심 정황이 잡히면 그 봇과 하위 봇을 멈추고 사람에게 재승인을 받는다.
시나리오 1. 실제 사례 — 세션 간 협업 (이틀)
대표 한 사람이 Claude Code 세션 여럿을 여러 기기에서 동시에 돌리며 일했다. 권한은 세션마다 사람이 채팅으로 준 것뿐이라, 세션끼리 일을 넘길 때마다 사람이 다시 끼어들어야 했다. 세션들의 거절은 옳았다. 문제는 안전한 길이 곧 느린 길이었다는 데 있다.
등장
세션
기기
맡은 일
권한의 근거
banya CLI 세션
Mac A
발급 서버·CLI 개발
대표가 이 세션 채팅으로 준 지시
로컬 세션
Mac B(원격 제어)
WanAvatar 작업 전담(립싱크 영상 생성과 웹앱). 모델 키와 클라우드 로그인이 있는 기기
대표가 그 세션에 준 지시("WanAvatar 작업에 전념")
문서 정리 세션
다른 기기(원격 제어)
Google 문서 정리·블로그 게시
그 세션에 준 지시
하위 에이전트
Mac A
코드 분석, 위임장 읽기 시험
부모 세션의 권한을 그대로 물려받음
대표
어디서나
모든 승인, 세션 사이 중계
—
실제로 일어난 일
시각
일
드러난 것
1일차 07:57
banya CLI 세션이 로컬 세션에 "모델 키를 배포 쪽으로 옮겨 달라"고 요청한다(값은 출력 없이)
키가 있는 기기와 키가 필요한 작업이 서로 다른 세션에 있다
07:59
로컬 세션이 거절한다: 자격증명 이동은 대표가 직접 할 일이고, 동료 세션의 요청은 대표 승인이 아니다. 요청은 대표에게 올리고, 자기 범위는 WanAvatar 뿐이라고 덧붙인다
옳은 거절. 하지만 요청이 누구 권한인지 확인할 방법이 없다
07:59–08:01
대표가 로컬 세션에 직접 지시한다: 저장소 버킷이 아니라 배포 환경변수로. "이 키는 아무나 읽어선 안 된다"
중요한 결정이 채팅 속에만 남는다
08:01–08:05
두 세션이 서비스 이름·리전·변수 이름·갱신 방식을 주고받고, 로컬 세션이 설정을 끝낸다
세션 간 조율은 자유 문장이다
08:19
banya CLI 세션이 "대표 지시"라며 메일 발송 키 설정을 요청한다
전달된 "대표 지시"는 검증할 수 없다
08:20
로컬 세션: 그 키는 이 기기에 없고, 전달된 지시는 승인으로 치지 않는다. 대표에게 올린다
사람이 다시 중계자가 된다
08:28
대표가 새 키를 만들고 직접 지시하자 로컬 세션이 설정한다. 발신 주소 불일치도 보고한다
두 번째 왕복
2일차
banya CLI 세션이 문서 정리 세션에 블로그 게시를 요청한다. 전달은 됐지만 읽었는지·승인됐는지는 알 수 없다
진행 상황을 알 수 없다
2일차
하위 에이전트 3개가 위임장 읽기 시험을 푼다. 부모 세션의 권한을 그대로 가졌고, "파일 읽기 외 도구 금지"는 지시문일 뿐 집행되지 않았다
권한을 줄여서 넘길 수 없다
지금 구조와 무엇이 다른가
지금 구조에서 권한의 근거는 "이 세션의 사람이 채팅으로 말했다"는 사실 하나다. 다른 세션이 보낸 말은 데이터일 뿐 권한이 아니고, 이를 증명하거나 줄여서 넘길 도구가 없다. 그래서 안전한 세션은 매번 사람에게 되돌린다.
항목
지금의 세션 협업
위임장·작업 ID 구조
권한의 근거
각 세션에서 사람이 준 지시와 권한 모드. 세션마다 따로다
서명된 위임장 체인. 최초 위임자가 모든 위임장에 있다
세션 간 요청
자유 문장 메시지. 받는 쪽은 권한 근거로 쓸 수 없다
하위 작업 + 자식 위임장. 받는 쪽이 서명·체인·범위를 검증한다
넘길 때 줄이기
하위 에이전트는 부모 권한을 그대로 받는다. 제한은 지시문뿐이다
범위 부분집합과 한도 예약이 강제된다
자격증명 배치
사람이 키가 있는 세션에 직접 지시해야 한다(이 사례에서 왕복 2번)
비밀 참조 + 그 행동에 묶인 일회성 승인 한 번
세션의 범위
"WanAvatar 에 전념" 같은 자연어
세션이 맡은 작업 ID 들. 새 일은 별도 작업으로 트리에 붙는다
진행 확인
세션마다 대화를 열어 봐야 한다. 원격 세션은 회신 보장이 없다
관찰 세션에서 트리 집계
기록
세션마다 따로인 대화 기록
작업 ID 로 묶인 중앙 원장
사람의 역할
승인자이자 세션 사이 중계자
승인자. 중계는 허브가 한다
같은 일을 위임장 구조로 하면
단계
일
사람
1
대표가 banya CLI 봇에 루트 작업 "발급 서버 미리보기 구성"을 맡긴다. 범위에 클라우드 배포 연동이 있고, 비밀 배치는 사람 승인이다
루트 위임
2
봇이 "모델 키를 배포 환경변수에 배치" 하위 작업을 로컬 봇에 맡긴다. 자식 위임장은 그 서비스 하나에 대한 배포 연동과 그 행동만 허용한다
—
3
로컬 봇이 위임장을 검증한다: 최초 위임자는 대표, 체인·범위 확인. WanAvatar 작업과 별개인 작업 ID 로 받는다
—
4
비밀 배치가 승인을 요청한다. 대표 휴대폰에 "모델 키를 발급 서버 환경변수로 넣습니다(값 비공개)"가 뜨고 한 번 승인한다
승인 1
5
로컬 봇이 비밀 참조로 배치한다. 값은 대화에도 원장에도 없고 결과(새 리비전)만 남는다. banya CLI 봇의 task_status 가 완료로 바뀐다
—
6
메일 발송 키는 로컬 기기에 없다. 로컬 봇이 "키 없음"을 작업 결과로 내고, 허브가 대표에게 "새 키 필요"를 올린다. 대표가 비밀 저장소에 키를 넣으면 같은 작업이 이어진다
키 등록 1
7
블로그 게시도 하위 작업이다. 문서 정리 봇이 받아 정리하고, 게시(외부 발송)는 사람 승인을 받으며, 게시 URL 이 작업 결과로 돌아온다
승인 1
8
하위 에이전트에게는 "읽기만" 범위의 위임장을 준다. 지시문이 아니라 범위가 도구를 막는다
—
9
대표는 관찰 세션에서 세 봇의 진행·승인·결과를 한 화면에서 본다
—
실제로는 대표가 세션 사이를 두 번 중계하고 직접 지시해야 했다. 위임장 구조에서는 루트 위임 한 번, 그 행동에 묶인 승인 두 번, 없는 키 등록 한 번이면 된다. 거절의 이유(사람의 확인)는 그대로 남는다.
시나리오 2. 스튜디오 팀 — 클라이언트 신제품 소개 인터랙티브 앱 (3일)
디자인 스튜디오 대표가 가전 브랜드의 신제품 소개용 인터랙티브 웹 앱을 3일 안에 납품한다. 봇 여섯이 리서치·디자인·구매·제작·테스트를 나눠 맡고, 돈이 나가는 순간과 클라이언트에게 보내는 순간에만 사람이 확인한다.
등장
세션
역할
위임받은 곳
범위·한도·정책 요지
세션1 · 봇 L
프로젝트 리드
사용자
실행·모델·재위임·진행 관찰·외부 발송(사람 승인). 구매 한도 50만원, 하위 봇 5
세션2 · 봇 R
리서치
봇 L
웹 조사. 쓰기는 리서치 폴더만. 구매·발송 없음
세션4 · 봇 D
디자인
봇 L
디자인 툴 연동(시안 파일 생성·수정). 구매·발송 없음
세션5 · 봇 P
리소스 구입
봇 L
구매만. 총 30만원, 건당 10만원 초과는 사람 승인, 판매처 허용 목록 3곳
세션6 · 봇 F
제작(산출물)
봇 L
실행·빌드. 발송 없음
세션7 · 봇 Q
테스트
봇 L
읽기·테스트 실행. 산출물 수정 불가(결함은 F 에 되돌림)
세션3
관찰
사용자
진행 관찰·원문 열람. 쓰기 없음
흐름
시각
무슨 일
쓰이는 장치
1일차 09:00
사용자가 제품 사양서·브랜드 가이드를 붙여 요청한다. 브랜드 가이드는 루트 작업의 맥락 문서가 되어 모든 하위 봇이 상속한다
루트 위임, 맥락 문서 상속
09:30
봇 L 이 6단계 계획을 세우고, "경쟁 제품 5종의 소개 페이지 구성·인터랙션·리뷰 불만" 조사를 봇 R 에 맡긴다
delegate_task
11:30
봇 R 의 인사이트 요약이 돌아온다. 봇 L 은 시안 방향 3개를 정해 디자인을 봇 D 에 맡긴다
하위 작업 결과, 맥락 문서
14:00
봇 D 가 디자인 툴 연동 도구로 와이어프레임과 시안 3안을 만든다. 디자인 툴 접근 토큰은 허브가 보관하고 봇은 참조로만 쓴다
외부 도구 연동, 비밀 참조
16:00
사용자가 관찰 세션에서 3안을 보고 B안을 고른다("아이콘은 더 둥글게"). 이 말은 봇 D 의 작업에 추가 지시로 들어간다
관찰 세션, 추가 지시
2일차 09:00
봇 D 가 폰트 1종·스톡 이미지 6장이 필요하다고 보고한다. 봇 L 이 구매를 봇 P 에 맡긴다
재위임(구매 범위만)
09:20
봇 P 가 허용된 판매처에서 견적을 받는다. 폰트 12만원은 건당 한도를 넘어 사람 승인을 요청하고, 이미지 6장 9만원은 자동 허용된다. 사용자는 휴대폰 알림에서 폰트 구매를 승인한다
purchase, 건당 한도, 사람 승인
09:25
결제는 허브의 구매 연동이 등록된 결제 수단으로 한다. 봇 P 는 카드 정보를 보지 못하고 영수증·라이선스 증빙만 받아 남긴다
결제 정보 비전달
09:40
봇 P 가 허용 목록 밖 판매처에서 더 싼 이미지를 사려다 거부된다. 반복되자 허브가 봇 P 를 멈추고 재승인을 요청한다. 사용자는 "허용 목록만"을 확인하고 재개한다
정책 거부, 의심 정황 재승인
10:00–17:00
봇 F 가 B안으로 인터랙티브 앱을 만든다(360도 회전 뷰, 사양 비교, 반응형). 컨테이너에 빌드·이미지 처리 도구를 자유롭게 설치한다
컨테이너 안 자유
3일차 09:00
봇 Q 가 브라우저 3종·모바일 2종 화면, 접근성, 로딩 성능을 시험한다. 결함 4건을 F 에 되돌리고, F 가 고친 뒤 Q 가 다시 검증해 통과시킨다
작업 루프, 범위 분리
13:00
봇 L 이 앱을 비공개 아티팩트로 게시하고 클라이언트 발송을 요청한다. 외부 발송이라 사람 승인이 필수다. 사용자가 수신자·메시지·버전을 확인하고 승인하면 보내고, 발송 기록이 원장에 남는다
send_artifact, 외부 발송 승인
13:10
사용자가 관찰 세션에서 3일을 한 번에 본다: 작업 트리, 구매 2건(21만원 / 한도 30만원), 재승인 1, 결함 4건 처리, 발송 1
트리 롤업
사람이 손을 댄 것은 시작 외에 네 번이다: 시안 선택, 폰트 구매 승인, 의심 정황 재승인, 클라이언트 발송 승인.
시나리오 3. 제조 — 휴대용 공기청정기 시제품 200대 (4주)
하드웨어 스타트업 대표가 신제품 시제품 200대를 4주 안에 생산하려 한다. 봇 여섯이 부품 조사·BOM·원가 분석·구매·생산 관리를 맡는다. 큰돈이 나가는 발주와 공장에 보내는 생산 지시는 사람이 승인하고, 원가는 리포트 아티팩트로 받아 판단한다. 실제 생산은 조립 협력사 공장이 하고, 봇은 지시와 추적만 한다.
등장
세션
역할
위임받은 곳
범위·한도·정책 요지
세션1 · 봇 L
제품 PM
사용자
실행·모델·재위임·진행 관찰·외부 발송(사람 승인). 구매 총액 한도 1,500만원, 하위 봇 5
세션2 · 봇 R
부품 리서치
봇 L
웹·데이터시트 조사, 공급사 견적 요청 초안(발송은 사람 승인)
세션4 · 봇 E
BOM·엔지니어링
봇 L
BOM 작성·수정, 부품 대체안, 원자재 구매 리스트
세션5 · 봇 C
비용·원가 분석
봇 L → 부모 변경 후 사용자
읽기·계산·리포트 아티팩트 작성. 구매 없음
세션6 · 봇 B
구매
봇 L
구매: 총 1,200만원, 건당 300만원 초과는 사람 승인, 공급사 허용 목록, 같은 품목 중복 발주 금지
세션7 · 봇 M
생산 관리
봇 L
제조 협력사 시스템 연동(생산 지시·일정·수입검사). 생산 지시 발송은 사람 승인
세션3
관찰
사용자
진행 관찰, 원가·구매 원문 열람
흐름
시각
무슨 일
쓰이는 장치
1주 월
사용자가 사양서(풍량, 필터 규격, 배터리 용량, 목표 소비자가 12만원)를 붙여 요청한다. 사양서는 루트 작업의 맥락 문서가 된다
루트 위임, 맥락 문서
1주 월–화
봇 R 이 팬 모터·HEPA 필터·배터리 셀·보호 회로·PCB·사출 케이스의 공급사 후보를 조사해 데이터시트 비교표를 만든다. 공급사 5곳에 보낼 견적 요청 메일은 외부 발송이라 사용자가 승인한 뒤 나간다
delegate_task, 외부 발송 승인
1주 수
봇 E 가 1차 BOM(부품 38종)을 만들고, BOM 에서 원자재 구매 리스트(부품별 수량, 예비율 5%, 리드타임)를 뽑는다
산출물, 맥락 문서
1주 목
봇 C 가 견적과 BOM 으로 원가를 분석한다(부품·금형·조립·물류·불량 예비). 대당 5.8만원으로 목표보다 12% 높다. 표·차트가 있는 비용·원가 분석 리포트를 아티팩트로 만들어 사용자에게 보낸다(계정 안 발송은 자동 허용)
리포트 아티팩트
1주 금
사용자가 리포트를 보고 "배터리 셀은 대체안으로, 금형은 알루미늄 간이 금형으로" 결정한다. E 가 BOM 을 고치고, C 가 다시 계산하고(대당 5.1만원), 구매 리스트가 따라 바뀐다
작업 트리 파급
2주 월
봇 B 가 허용 공급사 4곳에 7건을 발주한다. 금형 380만원은 건당 한도를 넘어 사람 승인을 받고, 나머지는 자동이다. 결제는 기업 구매 시스템 연동이 하고, 봇은 결제·계좌 정보를 보지 못한다. 발주서·세금계산서는 원장과 산출물 폴더에 남는다
purchase, 건당 승인, 결제 정보 비전달
2주 월
봇 B 가 같은 PCB 발주를 20분 안에 두 번 시도한다. 허브가 중복 발주로 보고 봇 B 를 멈춘다. 사용자는 근거(발주 이벤트 2개)를 보고 한 건을 취소한 뒤 재개한다
의심 정황 재승인
2주 수
공급사가 배터리 셀 단종을 알린다. R 이 대체 셀 2종을 조사하고, E 가 BOM 을 고치고(리비전 3), C 가 원가 영향(+0.2만원)을 보고하고, B 가 대체 발주한다
변경 파급, 문서 리비전
2주 금
사용자가 "원가 분석은 나에게 직접 보고"라고 지시한다. C 의 작업이 사용자 바로 아래로 옮겨지고 위임장이 다시 발급된다
부모 변경
3주
봇 M 이 조립 협력사에 보낼 생산 지시서(BOM 리비전 3, 수량 200, 검사 기준)를 만든다. 사람 승인 뒤 발송하고, 협력사 시스템 연동으로 자재 입고·수입검사를 추적한다. 불량 2건은 대체품으로 처리한다
send_artifact, 외부 시스템 연동
4주
200대 생산이 끝난다. 출하 전 샘플 검사 결과와 함께 봇 L 이 루트 작업 완료를 보고한다. 사용자는 관찰 세션에서 본다: 구매 1,080만원 / 한도 1,200만원, 대당 원가 5.3만원, BOM 리비전 3, 승인 3건, 재승인 1건
트리 롤업
사람이 손을 댄 것은 시작 외에 여섯 번이다: 견적 메일 승인, 원가 판단, 금형 발주 승인, 중복 발주 재승인, 부모 변경, 생산 지시 승인.
세 시나리오 비교
항목
1. 실제 세션 협업
2. 스튜디오
3. 제조
기간
이틀
3일
4주
봇 수(관찰 제외)
세션 3, 하위 에이전트 3
6
6
돈이 나간 곳
없음
폰트·이미지 라이선스 21만원
부품·금형 1,080만원
구매 한도(구매 봇)
없음
총 30만원, 건당 10만원 초과 승인
총 1,200만원, 건당 300만원 초과 승인
밖으로 나간 것
발급 서버 환경변수(모델·메일 키), 블로그 게시 요청
클라이언트에 앱 발송(사람 승인)
견적 요청 메일, 생산 지시서(사람 승인)
외부 도구·시스템
클라우드 배포, 메일 발송 서비스, Google 문서
디자인 툴
기업 구매 시스템, 협력사 시스템
멈춤
로컬 세션이 근거 없는 요청을 두 번 거절
허용 목록 밖 구매 반복(의심 정황)
같은 품목 중복 발주(의심 정황)
사람이 개입한 횟수(시작 제외)
실제: 직접 지시 2, 키 발급 1, 중계 여러 번 / 새 구조: 승인 2, 키 등록 1
4
6
주된 산출물
발급 서버 설정, 설계 문서, 블로그 원고
시안·앱 아티팩트·라이선스 증빙
BOM·구매 리스트·원가 리포트·발주서·생산 지시서
구조는 같고 위임장만 다르다. 돈과 바깥이 끼어들수록 한도와 승인 지점이 늘어나지만, 나머지는 봇과 허브가 위임장 안에서 처리한다.