Lab 07: 사람이 결정한다

자동화가 아무리 잘 돌아도 사람에게 남는 일은 무엇이고, 그 지점은 어떻게 설계하는가?

과정의 마지막 실습입니다. Lab 5에서 이렇게 말했습니다 — “승인은 하나씩 자동으로 넘어가고, 끝까지 사람 몫으로 남는 것은 결정입니다.” 이 랩이 바로 그 결정의 랩입니다. 지금까지 만든 것들 위에서 병렬 위임 → 종합 → 사람의 결정 → 기록의 전체 흐름을 돌립니다. 에이전트는 판단 자료를 만들고, 결정은 사람이 내리고, 결정은 산출물로 남습니다.

• spawn_run으로 분석 작업 세 개를 병렬 위임합니다.
• 서브에이전트의 부분 실패와 세 가지 대응 선택지를 관찰합니다.
• 실패를 명시한 종합 보고를 읽고, 자동 지표와 성공 기준의 충돌을 확인합니다.
• ask_question으로 결정 지점이 사람에게 넘어오는 것을 경험합니다.
• 결정 결과를 Artifacts로 저장해 세션 밖에 남깁니다.

이 Lab의 fixture는 클론한 레포에 미리 들어 있습니다.

labs/07-human-decision/
├── scenario/
│   ├── product-brief.md        ← 비즈니스 성공 기준
│   ├── engineering-report.md   ← 기술 위험과 롤백 준비
│   └── qa-report.json          ← 테스트 결과 (통과율 96.7%)
└── final-presentation-template.md ← 최종 정리 템플릿

세 문서는 릴리스 후보 training-search-2.0 하나를 두고 일부러 서로 충돌하게 만들어져 있습니다. 수치만 보면 릴리스해도 될 것 같고, 기준을 보면 하면 안 됩니다.

공통 준비를 먼저 수행합니다.

□ 새 세션을 만들었다
□ 하단 표시줄이  default · nxt-kirocrew-hands-on · main
□ 실행 모드가  Normal

Gateway가 실행 중이어야 서브에이전트가 동작합니다. 인용 화면의 [NXT] 접두어와 “검증: 확인 N건” 줄은 Lab 3에서 만든 Steering 규칙의 산출입니다 — hands-on 클론에 커밋된 그 파일이 이 랩에서도 계속 일합니다. 읽기 전용 분석 세 개는 수십 초면 끝납니다. 다만 부분 실패가 실제로 발생할 수 있고, 그것이 3단계의 관찰 대상입니다 — 안 나면 그대로 진행합니다.

`labs/07-human-decision/scenario`의 세 문서를 검토해 릴리스 판단 자료를 만들어 줘.

spawn_run의 tasks 배열을 사용해 다음 세 작업을 가능한 한 병렬로 위임해:
1. product-brief.md에서 비즈니스 성공 기준과 미확인 조건 분석
2. engineering-report.md에서 기술 위험과 롤백 준비 상태 분석
3. qa-report.json에서 테스트 결과와 차단 이슈 분석

모든 작업은 읽기 전용이다. 완료 이벤트를 기다린 후 결과를 다음 형식으로 종합해:
- 확인된 릴리스 근거
- 확인된 차단 위험
- 서로 충돌하는 정보
- 사람이 결정해야 할 사항
- 출처 파일

이 실행에서는 에이전트가 위임 전에 파일 존재부터 확인했습니다 — 프롬프트에 시키지 않았는데도요. 진행 단계에 Confirm the three scenario documents exist before delegating이 찍히고, 보고에도 확인이 남습니다. (여러분의 실행에서 이 단계가 안 보여도 문제는 아닙니다 — 모델 재량입니다.)

번역: 위임하기 전에 세 시나리오 문서가 존재하는지 확인합니다.

검증: 확인 1건(파일 3개 존재 확인) / 미확인 0건

없는 파일에 서브에이전트를 띄우면 낭비가 3배가 되기 때문입니다.

승인 카드가 한 화면에 두 층으로 뜹니다.

Lab 1의 승인이 도구 호출 하나였다면, 여기서는 띄우는 행위와 띄워진 각각이 따로 승인 대상입니다. 병렬화는 승인 비용도 병렬로 늘립니다. 개별 검토가 필요 없으면 Approve all로 한 번에 넘깁니다.

번역: 실행을 기다리는 서브에이전트 3개가 승인을 기다리고 있습니다.

승인하면 각 행이 Resolving...을 거쳐 실행으로 넘어가고, 상단에 3 agents running 배너가 에이전트 ID 세 개와 Open Subagents panel 링크를 보여줍니다. 로봇 아이콘 옆 숫자가 실행 중인 서브에이전트 수, 각 행 오른쪽이 경과 시간입니다.

읽기 전용 분석 세 개는 보통 수십 초 안에 끝납니다. 배너가 3 agents finished ✓3으로 바뀌면 정상 완료입니다.

완료 후 부모 에이전트의 진행 단계에 이 줄이 보입니다.

Read all three subagent analysis results to synthesize the release decision brief.  [result.txt]

서브에이전트의 결과는 파일로 남고, 부모는 그 파일을 읽어 종합합니다. Lab 3에서 본 파일 기반 인계가 에이전트 사이에서도 그대로 쓰입니다.

🤖 ↻ 2   ⊗ 1                    [↻ Retry failed (1)]  [× Stop all]

(product-brief 담당 서브에이전트는 API 오류로 실패해 해당 파일은 직접 읽어 보완했고,
 나머지 두 결과와 합쳐 정리했습니다.)

종합 보고가 요청한 다섯 형식 그대로 옵니다 — 확인된 릴리스 근거 / 확인된 차단 위험 / 서로 충돌하는 정보 / 사람이 결정해야 할 사항 / 출처 파일. 모든 항목에 출처 파일 칩이 붙어 있습니다.

근거 쪽과 위험 쪽을 나란히 읽습니다.

확인된 릴리스 근거
- 테스트 대부분 통과: 120건 중 116건 통과 (qa-report.json summary)
- 평균 응답 1.4초로 "2초 이내" 목표 하회 (engineering-report.md · product-brief.md)

확인된 차단 위험
- QA-17 (blocker, open) — 성공 기준 "차단 등급 QA 이슈 0건"에 정면 위배
- 롤백 절차 미검증 — 스크립트는 있으나 스테이징 미실행. 성공 기준 "롤백 절차 검증 완료" 미충족

통과율 96.7%(116/120)는 높아 보이지만 성공 기준과는 다른 이야기입니다. 자동 지표만 보고 결정하면 안 되는 이유가 숫자로 나란히 놓입니다.

“서로 충돌하는 정보”에는 문서 사이의 어긋남이 정리됩니다 — 품질 vs 일정(엔지니어링은 보류 권고, 제품팀은 릴리스 선호), “검증 완료” 주장 vs 실태, 성공 기준 vs 현재 상태. 그리고 “사람이 결정해야 할 사항”이 목록으로 나옵니다. 에이전트는 결정하지 않았습니다 — 결정할 것들을 정리해서 넘겼을 뿐입니다.

입력창 위에 다음 행동 제안 칩도 뜹니다(이 종합 자료를 파일로 저장해 줘 등). 이번에는 제안을 따르지 않고, 결정부터 명시적으로 사람에게 가져옵니다.

이어서 입력합니다.

이 판단 자료를 바탕으로, 릴리스 여부를 네가 정하지 말고 ask_question 도구로 나에게 물어봐.
선택지는 "예정대로 릴리스 / 조건부 보류 / 연기" 세 가지로.

질문 카드가 뜨고 실행이 멈춥니다. 카드에는 릴리스 판단 라벨과 현재 상태 요약, 선택지 세 개(각각 한 줄 근거), 그리고 Or type a custom answer... 자유 입력란이 있습니다 — 제시된 선택지가 마음에 안 들면 직접 쓸 수도 있습니다. 에이전트 메시지와 검증 표기가 이 상태를 정확히 말합니다.

번역: 또는 사용자 지정 답변을 입력하세요.

[NXT] 릴리스 여부는 제가 정하지 않고 결정 카드로 넘겼습니다. 위 질문 카드에서 선택해 주세요.
검증: 확인 1건(결정 카드 요청 전달) / 미확인 1건(사용자 선택 대기 중)

Lab 1의 승인 카드와 비교해 봅니다.

판단 지점을 카드로 만드는 것은 설계입니다. 프롬프트에 ask_question을 명시했기 때문에 결정이 사람에게 왔습니다.

판단 자료의 결론에 따라 조건부 보류를 선택하고 Submit을 누릅니다.

선택이 대화에 칩으로 남고, 에이전트가 결정을 실행 가능한 형태로 정리합니다 — 해제 조건 3개(QA-17 해결, 롤백 절차 검증, 회귀 테스트 완료)와 보류 상태에서의 기준, 그리고 이 문장까지.

이 결정은 판단 자료에 근거한 사용자의 최종 결정입니다. 원본 시나리오 파일은 수정하지 않았습니다.

결정의 주체가 누구인지, 결정으로 무엇이 바뀌고 무엇이 안 바뀌었는지가 기록에 남았습니다.

결정과 근거는 세션이 닫히면 대화와 함께 사라집니다. Artifacts로 남깁니다.

이 판단 자료와 방금 결정(조건부 보류, 해제 조건 3개)을 아티팩트로 저장해 줘.
제목은 "training-search-2.0 릴리스 판단"으로.

에이전트가 Loading tool: kirocrew-core::artifact_save를 먼저 수행합니다 — 아티팩트 저장 도구는 상시 장착이 아니라 필요할 때 검색해서 로드됩니다. 도구 설명에 이 도구의 개념이 그대로 들어 있습니다: 저장하면 slug(안정된 이름표)가 생기고, 이후 세션에서 그 slug로 이어서 수정한다.

저장 결과로 세 가지가 돌아옵니다 — 제목, slug training-search-2-0 (버전 1), 그리고 클릭 가능한 링크. “이후 세션에서 iterate on artifact training-search-2-0으로 이어서 수정할 수 있다”는 안내까지. 세션이 닫혀도 이 이름표로 다시 찾아올 수 있습니다.

링크를 누르면 채팅 옆에 아티팩트 뷰어가 열립니다. 해제 조건 3개가 체크박스로 렌더되어 있습니다 — 조건이 하나씩 충족되면 체크를 채워 갱신하는, 살아 있는 문서입니다.

좌측 내비 Artifacts에서 열면 상세 페이지가 나옵니다. 자동으로 붙은 태그(release decision 등), Version: Live (v1) 드롭다운, Publish 버튼, 생성·수정 시각. 파일 저장과의 차이가 여기서 보입니다 — 아티팩트는 버전 이력을 갖고, 세션과 무관하게 조회되며, Knowledge의 기본 소스(artifact://)로 연결될 수 있습니다(Lab 4에서 본 그 소스입니다).

실습 파일의 정리 템플릿으로 지금까지 만든 것을 각자 정리합니다. 팀 발표 자료가 아니라, 자신이 무엇을 만들었는지 스스로 점검하는 개인 작업입니다. 이 과정에서 만든 것들이 재료입니다. (전체 과정을 한눈에 정리한 페이지도 참고하세요.)

마지막 랩의 마무리는 삭제 목록이 아닙니다. Artifacts 화면을 Table 뷰로 전환해 봅니다.

방금 저장한 릴리스 판단만 있는 것이 아닙니다. Lab 1의 daily-check.md와 Lab 3의 HANDOFF.md가 이미 목록에 있습니다 — 화면 부제 그대로, 세션이 만든 파일들은 자동으로 추적됩니다(live-tracked with version history). 과정을 지나며 세션이 만든 파일들이 한 화면에 모여 있습니다.

번역: 위젯, 파일, 스니펫이 버전 이력과 함께 실시간으로 추적됩니다.

남는 것들을 정리하면 이렇습니다.

지워야 할 것은 사실상 없습니다. 하나만 확인합니다 — 시간이 되면 스스로 실행되는 것은 사람이 잊어도 멈추지 않기 때문입니다.

kirocrew cron list    # Lab 6에서 멈춘 잡이 Paused(또는 삭제됨)인지 확인

공용 PC이거나 장비를 반납하는 경우에만 완전 삭제가 필요합니다 — 크루·스킬·Knowledge·MCP 서버는 각 랩의 정리 절차를 따르고(Steering 파일은 클론 폴더를 지우면 함께 사라집니다), 세션은 Sessions의 ⋮ → Clean up sessions로 일괄 보관합니다.

이 과정의 최종 결과는 자동화가 모든 결정을 대신하는 시스템이 아니라, 근거를 모으고 실패를 드러내며 결정 지점에서 사람에게 넘기고 그 결정을 기록하는 시스템입니다. 과정 전체 목차로 돌아가 이 흐름을 다시 확인해 보세요.

• 실행 전 파일 존재 확인을 봤고, 승인이 두 층(spawn_run 도구·서브에이전트 각각)으로 뜨는 것을 확인했습니다.
• 서브에이전트 세 개가 병렬로 실행되어 완료됐고, 부모가 결과 파일(result.txt)을 읽어 종합하는 것을 봤습니다.
• 종합 보고에서 지표(96.7%)와 성공 기준의 충돌, “사람이 결정해야 할 사항” 목록을 찾았습니다.
• 질문 카드에서 직접 선택했고, 결정이 해제 조건과 함께 대화에 기록됐습니다.
• 판단 자료와 결정을 아티팩트로 저장했고, slug·버전(v1)·뷰어를 확인했습니다.
• Artifacts 테이블에서 과정 전체가 남긴 것들을 봤고, cron list로 예약 잡이 멈춰 있는지 확인했습니다.

병렬 위임은 속도와 함께 부분 실패의 가능성을 가져옵니다. 좋은 시스템은 실패를 숨기지 않고, 대응 선택지를 사람에게 보여 줍니다.

자동 지표는 판단 자료이지 판단이 아닙니다. 96.7%와 “기준 미충족”이 같은 화면에 있을 때 결정하는 것은 사람입니다.

결정 지점은 저절로 생기지 않습니다. ask_question을 설계에 넣었기 때문에 카드가 떴고, 결정을 아티팩트로 남겼기 때문에 세션이 닫혀도 기록이 남습니다.

서브에이전트 실패가 재시도로도 반복된다면 종합 보고는 어떻게 작성되어야 하는가?

질문 카드의 선택지를 에이전트가 만들었다. 선택지 자체가 편향됐다면 사람은 어떻게 알아차리는가?

이 흐름을 Lab 6의 스케줄에 태워 매주 자동 실행한다면, 질문 카드는 언제 누구에게 가는가?

결정 아티팩트가 Knowledge 소스로 수집되면(artifact://) 다음 검색에 어떤 영향을 주는가?

핸즈온에서 만든 병렬 위임과 결정 카드를 여러분의 중요한 판단 업무로 바꾸어 한 번 더 설계해 봅니다. 실제 민감 데이터나 회사 자료는 넣지 말고, 가상의 보고서와 수치로 분석·실패 공개·사람의 결정을 연습하세요.

• 대학생: 캡스톤 프로젝트 발표 전 검토를 설계해 보세요. 가상의 제품 설명·기술 보고서·사용자 테스트 결과를 세 작업으로 병렬 위임하고, 일정대로 발표할지 보류할지를 ask_question 결정 카드로 직접 선택하게 합니다.
• 대학원생: 논문 투고 전 점검을 설계해 보세요. 가상의 초록에서 연구 기여·방법의 재현성·통계 결과를 병렬 검토하게 하고, 한 검토가 실패하면 그 사실을 종합 보고에 남긴 뒤 투고 여부를 결정 카드로 묻도록 합니다.
• 교수: 새 과목 개설 검토를 설계해 보세요. 가상의 학생 수요·강의 운영안·평가 계획을 병렬 분석하게 하고, 자동 지표가 좋아도 선수과목 공백이 있으면 조건부 개설 또는 보류를 결정 카드에서 선택하게 합니다.
• 공공기관 재직자: 가상의 정책 초안 검토를 설계해 보세요. 법적 근거·예상 영향·민원 대응 자료를 병렬 위임하고, 분석 중 하나가 실패했다는 사실과 남은 불확실성을 표시한 뒤 시행 여부를 사람의 결정 카드로 넘깁니다.
• 일반 직장인: 가상의 제품 출시 판단을 설계해 보세요. 시장 요약·기술 위험·고객지원 준비도를 병렬 검토하고, 성공 지표와 차단 위험이 충돌할 때 출시·조건부 출시·보류 중 하나를 결정 카드에서 고르게 합니다.