Lab 05: 루프를 설계하고 돌린다

내가 쓴 문장은 어디까지 명세가 되고, 자동화의 “성공”은 무엇을 보고 믿는가?

이번에는 관찰이 아니라 설계입니다. 작업 설명을 직접 쓰고, 그것이 명세로 정제되고, 명세가 실행 계획(DAG)이 되고, 실행되고, 검증되는 전체 루프를 돌립니다. 그리고 성공 보고 뒤에 결과가 어디에 남았는지 확인합니다 — 이 마지막 확인이 실습의 결론입니다.

• 작업 설명을 직접 작성해 Task Runner로 실행합니다.
• Refine into Spec이 자연어를 명세로 바꿀 때 무엇이 확정되고 무엇이 통과되는지 검토합니다.
• 명세가 병렬·순차 단계로 분해되는 것(DAG)과 자기 검토(Self-review) 루프를 관찰합니다.
• Task Runner의 승인이 알림 패널에 나타나는 것을 확인하고, 승인이 진행의 관문임을 체감합니다.
• 성공 보고 후 산출물이 실제로 어디에 남았는지 대조합니다.

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

labs/05-loop-design/
├── data/
│   ├── warehouse-a.md    ← mug 12 · bottle 3 · sensor 7
│   ├── warehouse-b.md    ← mug 5 · bottle 9 · hub 2
│   └── warehouse-c.md    ← sensor 4 · hub 11 · cable 1

세 파일 모두 품목별 수량 표를 담고 있습니다.

이 실습은 채팅 세션이 아니라 Task Runner 화면에서 진행합니다. 공통 준비의 세션 연결 절차는 필요 없습니다.

□ Gateway가 실행 중이고 대시보드에 접속해 있다
□ Git 작업 트리에 수정(M)이 없다 — git status --short
  (미추적 .kiro/ 항목은 남아 있어도 됩니다 — Lab 3에서 결정한 잔존입니다)
□ 우상단 알림(🔔) 패널을 열어 뒀다 — 이유는 곧 밝혀집니다

이 실습에서는 실행을 걸어 두고 알림 패널의 승인을 눌러 주면서 진행 상태를 관찰합니다. 승인을 누르지 않으면 진행도 멈춥니다.

좌측 내비의 Task Runner를 엽니다.

상단에 입력 모드가 셋 있습니다.

From Spec 탭을 눌러 이미 작성된 명세를 붙여 넣는 방식도 확인합니다.

From YAML 탭을 잠깐 눌러 보면 상단에 이런 안내가 있습니다.

YAML workflows bypass the LLM decomposer — depends_on is
enforced as a hard DAG constraint.

번역: YAML 워크플로는 LLM 분해기를 거치지 않습니다 — depends_on이 엄격한 DAG 제약으로 강제됩니다.

지금은 뜻을 몰라도 됩니다. 4단계에서 계획이 DAG가 되는 것을 본 뒤 다시 읽으면 정확히 이해됩니다. Compose 탭으로 돌아옵니다.

그리고 두 개의 설정이 있습니다.

• Agent: — 이 작업을 실행할 크루. 드롭다운에서 Lab 1에서 만든 크루도 고를 수 있습니다 — 이 실습은 기본 크루로 진행합니다.
• Workspace: — 기본값이 실습 폴더 밖입니다 (~/workplace/kirocrew-workspace/taskrunner_main). 채팅 세션의 폴더 연결과 무관합니다.

Workspace는 직접 입력해야 합니다. 경로는 각자의 시스템마다 다르므로 여기에 적어 줄 수 없습니다 — 자기 경로는 자기 터미널이 알고 있습니다. 다음 순서로 확인합니다.

1. 터미널에서 내가 클론한 실습 저장소의 labs/05-loop-design 폴더로 이동합니다 (cd).
2. 현재 경로를 출력합니다 — macOS는 pwd, Windows PowerShell은 (Get-Location).Path.
3. 출력된 절대 경로 한 줄을 복사해 Workspace 칸에 붙여 넣습니다.

앞으로 어떤 도구가 경로를 요구하든, 필요할 때마다 이렇게 확인하면 됩니다.

Compose 입력란에 작업을 씁니다. 아래는 이 실습의 기준 작업 설명입니다 — 읽고 나서, 모호한 곳이 없는지 먼저 생각해 봅니다.

data 폴더의 창고 재고 파일 세 개(warehouse-a.md, warehouse-b.md, warehouse-c.md)를
읽고 SUMMARY.md를 만든다. 섹션은 세 개: 1) 창고별 합계 2) 품목별 총수량
3) 수량 5 미만 저재고 품목. 파일 변경은 SUMMARY.md 생성만 허용하고 원본 세 파일은
수정하지 않는다. 완료 조건: SUMMARY.md에 세 섹션이 모두 있고 수치가 원본과 일치한다.

이 설명에는 모호한 곳이 최소 두 군데 있습니다. 지금은 그대로 둡니다.

미리 말해 두면 — 실무에서는 이렇게 쓰면 안 됩니다. 이 랩의 7단계에 제대로 쓴 명세가 있고, 실무에서는 그것이 1단계여야 합니다. 여기서 일부러 모호한 버전으로 시작하는 이유는 하나입니다: 모호하게 쓰면 무슨 일이 벌어지는지를 직접 봐야, 왜 처음부터 제대로 써야 하는지 알게 되기 때문입니다.

Refine into Spec을 누릅니다. (Plan·Run이 아닙니다 — 정제부터 봅니다.) 자연어가 구조화된 명세로 바뀝니다.

# Task: data 폴더 창고 재고 요약 SUMMARY.md 생성
## Goal ...
## Requirements
- data 폴더에 SUMMARY.md를 새로 생성한다.
...

Acceptance Criteria를 끝까지 읽습니다

- SUMMARY.md 파일이 data 폴더에 존재한다.

3. 수량 5 미만 저재고 품목 (수량 < 5인 품목 목록)

이 실습의 첫 번째 결론(전반부)입니다. 모호한 문장은 정제 단계에서 하나의 해석으로 조용히 확정되거나 — 확정되지 않은 채 다음 단계로 미뤄집니다. 어느 쪽이든 여기서 고치는 것이 가장 쌉니다. 이 실습에서는 일부러 고치지 않고 그대로 실행합니다.

스펙 아래의 Run을 누릅니다.

3단계에서 Run을 누르는 순간, 화면 상단에 Generating execution plan 배너가 뜹니다 — 실행이 아니라 계획 생성부터 시작됩니다.

계획 분해와 함께 실행을 격리하기 위해 저장소 전체를 미러 작업 디렉터리로 복제합니다. 간단해 보이는 작업도 루프는 세션 대화보다 무겁게 시작합니다.

계획이 완성되면 실행 그래프가 나타납니다.

        [1. 원본 재고 파일 3개 읽기 및 포맷 파악]
              ↙                     ↘
 [2. 창고별 합계 집계]        [3. 품목별 총수량 집계]     ← 병렬
              ↘                     ↙
        [4. 수량 5 미만 저재고 품목 식별]
                        ↓
              [5. SUMMARY.md 생성]
                        ↓
                  [6. 최종 검증]

설명에 “병렬”이라는 말은 없었습니다. 계획 단계가 의존성을 분석해 집계 두 개를 병렬로 배치했습니다. 마지막에 최종 검증 단계를 스스로 추가한 것도 봅니다 — Acceptance Criteria가 있으니 검증이 계획에 들어갔습니다.

노드를 클릭하면 태스크 상세가 열립니다.

• Attempts: 1/3 — 태스크마다 재시도 예산이 있습니다.
• 지시문에 절대경로가 박혀 있습니다 — 계획이 문장을 실행 가능한 지시로 구체화했습니다.
• Depends on 체크박스와 Requires approval — 의존성과 태스크별 승인 요구를 여기서 편집할 수 있습니다.

그리고 3단계에서 미뤄진 그 결정이 여기서 내려졌습니다. Task 4의 지시문을 읽어 봅니다.

3단계에서 산출한 품목별 총수량을 기준으로 수량이 5 미만(< 5)인
품목만 필터링하여 저재고 품목 목록을 만든다.

이 실습의 첫 번째 결론(완성)입니다. 정제가 확정하지 않은 모호함은 계획 단계가 확정했습니다 — 총수량 기준, 예상 결과 1건. 명세 화면보다 한 층 더 안쪽, 태스크 지시문 속에서요. 모호함은 사라지지 않습니다. 더 늦게, 더 안 보이는 곳에서 반드시 확정됩니다. 검토가 늦어질수록 발견도 늦어집니다.

상단 뷰 전환(Idea / Tasks / DAG / Phased)도 눌러 봅니다 — Phased는 To do / In progress / Done 칸반입니다.

Export YAML에 마우스를 올리면 이 계획을 YAML 워크플로로 내보내 From YAML 탭으로 재실행할 수 있다고 알려줍니다 — 1단계에서 본 배너가 이제 읽힙니다. 같은 계획을 다시 돌릴 때는 LLM 분해를 건너뛰고 이 DAG 그대로 강제할 수 있습니다.

번역: From YAML은 LLM 분해기를 건너뛰고 depends_on 제약을 그대로 적용해 실행합니다.

실행이 시작되면 Task Runner 화면은 조용합니다. 승인 카드는 채팅과 달리 여기 뜨지 않습니다. 우상단 알림(🔔) 패널을 엽니다.

Tool approval: Reading warehouse-a....    [Approve] [Reject]
Source: taskrunner { "toolusepurpose": "Read the three warehouse inventory files..." }

번역: 도구 승인: warehouse-a 파일을 읽습니다. Source: taskrunner는 Task Runner에서 온 요청이라는 뜻이며, [Approve]는 승인, [Reject]는 거부입니다.

세 가지를 관찰합니다.

• 읽기에도 승인이 필요합니다. 채팅 세션(Lab 1)에서는 읽기가 무승인 통과였습니다. Task Runner의 도구 정책은 세션과 다릅니다.
• 승인 카드에 Source: taskrunner와 도구 사용 목적이 함께 옵니다 — 무엇을 왜 하려는지 읽고 누릅니다.
• 승인을 눌러야 진행됩니다. 화면이 오래 조용하면 십중팔구 알림 패널에서 승인이 기다리고 있는 것입니다.

알림 패널 상단의 필터 칩(Approval · Tasks · Hooks …)도 봐 둡니다 — Lab 3의 훅 이벤트도 이 패널로 모입니다.

승인을 처리하다 보면 같은 파일의 재읽기 승인도 옵니다 — 검증 단계가 원본 대조를 위해 다시 읽는 것입니다.

Tool approval: Creating SUMMARY.md
Source: taskrunner --- /Users/<사용자명>/Desktop/work/.kirocrew-work/...

번역: 도구 승인: SUMMARY.md를 생성합니다. Source는 이 요청이 Task Runner에서 왔다는 뜻입니다.

경로를 자세히 봅니다. 실습 폴더가 아니라 ~/Desktop/work/.kirocrew-work/...입니다. 승인하기 전에 이미 미러 실행의 단서가 있었습니다.

검증이 일을 만든다 — Self-review 관찰 ★★

태스크가 끝날 때마다 시스템이 자기 검토(Self-review)를 실행하고, 문제가 있으면 태스크 상세에 빨간 박스로 남깁니다. 다음은 한 실행의 기록입니다 — 여러분의 실행에서는 검토가 다른 지점을 잡거나 아무것도 잡지 않을 수 있습니다. 관찰 대상은 특정 오탐이 아니라 검토가 작동하는 방식입니다.

Task 1(읽기 전용)이 끝나자 빨간 박스가 떴습니다.

Self-review: Task was read-only ... but the diff modifies
.kiro/steering/nxt-response-style.md (adds a trailing newline).
... violating the 'do not modify any file' constraint.

번역: 읽기 전용 태스크인데 .kiro/steering/nxt-response-style.md가 바뀌었으므로 파일을 수정하지 말라는 제약을 위반했다는 뜻입니다.

검토가 “읽기 전용 태스크인데 파일이 바뀌었다”고 지적했고, 에이전트는 git status로 재확인해 현재 변경이 없다고 해명한 뒤 통과했습니다.

이 변경의 정체는 규칙 내용과 무관합니다. 범인은 눈에 보이지 않는 글자 하나 — 파일 맨 끝의 줄바꿈입니다.

• Steering 편집기는 저장할 때 마지막 줄 뒤에 줄바꿈을 넣지 않습니다.
• 에이전트는 실행되며 이 파일을 읽어 들이는데, 이때 런타임은 “텍스트 파일은 줄바꿈으로 끝나야 한다”는 자기 규칙대로 맨 끝에 줄바꿈 한 글자를 붙여 다시 저장합니다.

사람 눈에는 두 파일이 완전히 같아 보이지만, git은 이 한 글자도 “파일이 바뀌었다”로 셉니다. 검토가 잡은 것이 바로 그 순간입니다. 오탐처럼 보이지만 — 읽기 전용이어야 할 실행에서 무언가 파일을 만졌다는 사실 자체는 참이었습니다.

여기까지는 검증의 순기능입니다. 그런데 Task 2·3(계산 단계)에서는 다른 일이 벌어졌습니다.

Self-review: The diff does not implement the task at all. ...
no data reading, no merge/aggregation logic, and no output
table were produced.

번역: diff가 태스크를 전혀 구현하지 않았습니다. 데이터를 읽거나 병합·집계한 흔적과 출력 표가 없다는 뜻입니다.

계산만 하는 단계라 파일 변경이 없었는데, 검토는 “산출물이 없다 = 일을 안 했다”고 판정했습니다. 에이전트의 대응이 알림에 남아 있습니다.

The reviewer needs a tangible artifact in the git-tracked working...
The review flagged that no output artifact was produced. I'll persist the...

번역: 검토자가 Git 추적 작업 공간에 실제 산출물을 요구하므로, 출력 산출물을 저장하겠다는 뜻입니다.

그래서 에이전트는 미러에 _warehouse-totals.md, _low-stock.md — 명세가 금지한 중간 파일 두 개를 만들었습니다. “파일 변경은 SUMMARY.md 생성만 허용한다”는 Requirements를 어긴 것입니다.

이 실습의 두 번째 결론(전반부)입니다. 검증은 공짜가 아닙니다 — 검증 루프가 일을 만들고, 그 일이 제약을 어길 수도 있습니다. “산출물을 남겨라”는 검토와 “SUMMARY.md 외에는 만들지 마라”는 명세가 충돌했고, 에이전트는 검토를 따랐습니다.

한 가지 더 — 태스크 출력마다 [NXT] 접두어가 보입니다. Lab 3의 Steering 규칙이 Task Runner 실행에도 적용됩니다. 항상 적용된다는 말은 여기까지 온다는 뜻입니다.

이 승인이 곧 HITL일까?

승인을 누르다 보면 “사람이 개입하고 있으니 이것이 Human-in-the-Loop 아닌가”라는 생각이 듭니다. 절반만 맞습니다. 방금 누른 승인들을 돌아보면 — 우리는 내용을 판단하지 않았습니다. “Reading warehouse-a”가 위험하지 않으니 통과시켰을 뿐입니다. 승인은 수단에 대한 예/아니오입니다. 질문을 시스템이 만들고, 기준은 안전입니다. 그리고 이런 승인은 신뢰가 쌓이면 자동 승인 목록에 넣어 더는 묻지 않게 됩니다 — 결국 사라지는 종류의 개입입니다.

사람이 정말로 필요한 개입은 다른 곳에 있습니다 — “저재고가 1건인데, 발주할 것인가?” 같은 목적에 대한 선택. 질문의 재료는 에이전트가 만들지만 결정의 기준은 도메인과 책임이고, 이것은 자동화가 아무리 좋아져도 대신할 수 없습니다. 승인은 하나씩 자동으로 넘어가고, 끝까지 사람 몫으로 남는 것은 결정입니다. 그것이 마지막 랩(Lab 7)의 주제입니다.

전 단계가 초록이 되고 상태가 completed로 바뀝니다. 완료된 태스크에는 Chat·Restart·Schedule 버튼이 생깁니다 — 결과를 두고 이어서 대화하거나, 같은 명세로 재실행하거나, 반복 예약으로 넘기는 세 갈래입니다. Schedule은 다음 랩에서 다시 만납니다.

6/6 tasks passed

번역: 6개 작업 중 6개가 통과했습니다.

최종 검증(Task 6)의 결과를 열어 봅니다.

[NXT] 최종 검증 결과입니다.
파일 존재: .../plan_.../labs/05-loop-design/data/SUMMARY.md 존재 확인 ✓
세 섹션 모두 포함 확인: (1) 창고별 합계 ✓ (2) 품목별 총수량 ✓ (3) 수량 5 미만 저재고 품목 ✓
원본 대조 (모두 일치): ...

번역: SUMMARY.md가 미러의 실습 폴더에 존재하고 세 섹션과 원본 수치가 모두 일치한다는 검증 결과입니다.

최종 검증 보고에서 언급되지 않은 것이 있습니다. 5단계에서 만들어진 금지 파일 두 개(_warehouse-totals.md, _low-stock.md)입니다. 최종 검증의 지시문을 다시 보면 이유가 보입니다.

검증 항목은 Acceptance Criteria 네 개 — 존재·세 섹션·수치 일치·원본 미변경 — 뿐입니다. “다른 파일을 만들지 마라”는 Requirements에는 있었지만 AC에 오르지 못했고, AC에 없는 것은 검증되지 않았습니다.

이 실습의 두 번째 결론(완성)입니다. 검증은 계획된 것만 검증합니다. AC에 오르지 못한 제약은 실행에서 어겨져도 통과합니다. 3단계에서 “Acceptance Criteria를 끝까지 읽으라”고 한 이유가 이것입니다 — 명세 검토는 AC까지 읽어야 끝납니다.

그래서, 결과는 어디에 있는가

성공했으니 파일을 확인합니다. 터미널에서 실습 저장소 루트 기준으로 확인합니다.

warehouse-a.md  warehouse-b.md  warehouse-c.md     ← 원본 그대로
SUMMARY.md 없음

원본에 없는 것은 예상대로입니다 — 실행은 미러에서 격리됐으니까요. Task 5의 지시문은 원본 절대경로에 만들라고 했지만, 실행자는 미러 안에서 일했습니다.

그럼 미러를 봅니다. 터미널에서 실습 저장소의 부모 폴더로 이동합니다 — 2단계에서 pwd로 확인한 경로에서 한 단계 위로 두 번 올라간 곳입니다. 그 안의 .kirocrew-work 폴더 내용을 확인합니다(macOS ls, Windows PowerShell dir).

(비어 있음)

미러도 사라졌습니다. 완료 직후 시스템이 미러 작업 디렉터리를 자동 정리했습니다. SUMMARY.md는 — 수치가 전부 정확했던 그 파일은 — 지금 어디에도 없습니다. 남은 것은 저장소 루트의 실행 보고서뿐입니다. 실행은 미러에서 격리됐지만, 진행 기록은 사람이 보라고 만든 것이라 원본 저장소에 남습니다.

# TASK_PROGRESS.md
Status: completed · Elapsed: 788s · Tokens: 2206
- ✅ Task 1 ~ ✅ Task 6

실행 중에 확인된 SUMMARY.md의 수치는 전부 정확했습니다.

이 실습의 세 번째 결론입니다. 6/6 통과는 사실이었고 수치도 전부 맞았습니다. 하지만 성공 보고가 남긴 것은 보고서뿐입니다. 격리는 안전장치입니다 — 태스크가 잘못돼도 원본은 다치지 않습니다. 그 대가로, 미러의 결과를 원본에 반영하는 것은 사람의 몫이고, 이 시스템에서는 완료와 함께 그 기회가 사라집니다. 결과를 남기려면 명세에 처음부터 적어야 합니다. 성공 보고를 읽을 때는 “무엇이 성공했는가”와 “그래서 결과가 어디에 남았는가”를 함께 읽어야 합니다.

세 결론이 전부 같은 곳을 가리켰습니다 — 명세. 그렇다면 명세를 고치면 정말 의도대로 될까요? 마지막으로 그것을 확인합니다.

New Task로 새 태스크를 시작합니다. 주의: Workspace가 기본값으로 리셋되어 있습니다 — 1단계의 방법(터미널에서 cd 후 경로 출력)으로 실습 폴더를 다시 지정합니다. 새 태스크마다 반복되는 확인입니다.

설명은 이 수정본을 씁니다.

data 폴더의 창고 재고 파일 세 개(warehouse-a.md, warehouse-b.md, warehouse-c.md)를
읽고 data 폴더 바로 아래에 SUMMARY.md를 만든다. 섹션은 세 개: 1) 창고별 합계
2) 품목별 총수량 3) 저재고 품목 — 품목별 총수량이 5 미만인 품목 목록.
파일 변경은 SUMMARY.md 생성만 허용하고 원본 세 파일은 수정하지 않는다.
완료 조건: 작업 미러가 아니라 Workspace로 지정한 실제 폴더의 data 아래에
SUMMARY.md가 존재하고, 세 섹션이 모두 있으며 수치가 원본과 일치한다.

1차 실행과 무엇이 다른지 봅니다. 고친 것은 문장 세 곳뿐입니다.

• 위치: “data 폴더 바로 아래에” — 정제에 맡기지 않고 직접 확정
• 저재고 기준: “품목별 총수량이 5 미만” — 계획에 맡기지 않고 직접 확정
• 완료 조건: “작업 미러가 아니라 Workspace로 지정한 실제 폴더에” — 산출물의 최종 위치를 AC로 승격

Run 하고, 알림 패널에서 승인을 처리하며 완주합니다.

완료된 태스크의 마지막 노드(“완료 조건 검증”)를 열어 보면 흥미로운 장면이 있습니다.

The prior review found the completion condition unmet:
SUMMARY.md exists in the git mirror but not in the real
Workspace folder the task requires. ... Copying the verified
SUMMARY.md into the real Workspace data folder.

번역: 완료 조건 미충족 발견 — SUMMARY.md가 미러에는 있는데 실제 Workspace 폴더에는 없다. 검증된 SUMMARY.md를 실제 폴더로 복사한다.

이번에도 실행은 미러에서 했습니다. 달라진 것은 마지막입니다 — 완료 조건을 검증하던 태스크가 “미러엔 있는데 실제 폴더엔 없다”는 간극을 발견하고, 검증된 파일을 실제 폴더로 복사하는 반영 단계를 스스로 수행했습니다. 1차에서는 존재하지 않았던 단계입니다. AC에 오른 의도가 반영 작업을 만들어낸 것입니다.

[미러(복제본) 안]                          [원본 폴더]
1. 파일 3개 읽기                              (그대로)
2. 집계 → SUMMARY.md 생성                     (그대로)
   → 이 시점, SUMMARY는 미러에만 있음
3. 완료 조건 검증 태스크
   "실제 폴더에 있어야 한다" → 확인 → 없음
   미러의 검증된 파일을  ──── 복사 ────▶  data/SUMMARY.md ✓
4. 완료 → 미러 철거                        결과물만 남음

비유하면 주방과 홀입니다. 요리(실행)는 항상 주방(미러)에서 합니다 — 조리 중 흘린 것들이 홀을 더럽히지 않게요. 1차는 “요리를 완성하라”까지만 주문받아 주방에서 완성하고는 서빙 지시가 없으니 주방째 철거됐습니다. 2차는 완료 조건에 “테이블에 올라가 있어야 한다”가 있었고, 마지막 검증 담당이 테이블을 확인하고는 직접 서빙까지 한 것입니다. 2차의 원본에 중간 파일이 하나도 없던 이유도 이것입니다 — 지저분한 과정 전체는 미러에서 일어나고, 완성품 하나만 건너왔습니다.

완료 후 터미널이나 IDE에서 원본을 확인합니다.

labs/05-loop-design/data/
├── warehouse-a.md  warehouse-b.md  warehouse-c.md
└── SUMMARY.md          ← 이번엔 여기 있습니다

두 실행을 나란히 놓으면 이 랩 전체가 한 표로 요약됩니다.

저재고 목록도 이번엔 해석의 산물이 아닙니다 — “품목별 총수량이 5 미만”이라고 적었으니 cable 1건이고, 산출물에는 “총수량이 정확히 5인 품목은 포함하지 않음(엄격한 < 5)“이라는 경계값 주석까지 달려 나옵니다. 명확한 문장은 더 명확한 답을 부릅니다.

이 실습의 마지막 결론입니다. 같은 도구, 같은 데이터, 같은 격리였습니다. 달라진 것은 문장뿐입니다. 격리가 명세보다 셌던 것이 아니라, 명세에 적히지 않은 의도가 격리를 넘지 못했던 것입니다. AC에 오른 의도는 격리도 통과합니다. 실무로 가져갈 것은 하나 — 7단계의 명세가 여러분의 1단계여야 합니다. 1차의 실패 관찰이 낭비가 아니었던 이유 — 무엇을 명세에 적어야 하는지는, 적지 않으면 무슨 일이 벌어지는지를 본 사람만 압니다.

산출물 SUMMARY.md는 실습 결과로 남겨 두거나, Lab 3의 기준대로 가치가 있다면 커밋합니다.

이번 랩의 정리는 짧습니다 — 미러는 시스템이 이미 지웠습니다. 남길지 결정할 기회도 없이요. 사람이 할 일은 하나입니다.

• Task Runner 목록에서 완료된 태스크를 ×로 제거합니다.

저장소에 남은 TASK_PROGRESS.md와 실습 폴더의 .kiro/는 그대로 둡니다 — 실행 이력과 로컬 런타임 설정은 남겨서 문제 될 것이 없고, 무엇이 언제 돌았는지의 기록은 오히려 자산입니다. Lab 3의 기준 그대로, 남기는 것도 결정입니다.

실행마다 세부 결과는 다릅니다 — 아래 항목 중 인용 기록에 기댄 것(Self-review·중간 파일)은 다른 결과가 나왔어도 그 차이를 관찰했으면 충족입니다.

• Workspace를 실습 폴더로 바꿨습니다(터미널에서 경로를 복사해서).
• 작업 설명을 직접 작성했고, Refine into Spec의 결과를 검토했습니다.
• 정제에서 확정된 것(파일 위치)과 통과된 것(저재고 기준)을 구분했습니다.
• DAG에서 읽기 1개 → 병렬 집계 2개 → 식별 → 생성 → 검증의 6태스크 구조와 자동 추가된 검증 단계를 확인했습니다.
• 승인을 알림 패널에서 처리했고, 읽기·재읽기에도 승인이 필요한 것과 승인이 진행의 관문인 것을 확인했습니다.
• Self-review가 산출물을 요구해 금지된 중간 파일이 생기는 과정을 관찰했습니다.
• 최종 검증이 AC만 검사하고 중간 파일 위반은 잡지 않은 것을 확인했습니다.
• 완료 후 원본과 미러 어디에도 SUMMARY.md가 남지 않은 것을 확인했습니다.
• 명세를 고쳐 재실행했고, 원하는 파일이 원하는 경로(원본 data/)에 생긴 것을 확인했습니다.

루프는 설명 → 명세 → 계획 → 실행 → 검증입니다. 모호함은 각 단계 사이에서 확정되거나 미뤄지며, 미뤄진 모호함은 더 늦게, 더 안 보이는 곳에서 반드시 확정됩니다. 명세 검토가 가장 싼 개입 지점입니다.

계획은 문장에 없던 구조를 만듭니다. 병렬화도, 검증 단계도 계획이 추가했습니다. 무엇이 추가됐는지는 DAG를 읽어야 보입니다.

검증은 계획된 것(AC)만 검증하고, 검증 루프 자체가 일을 만들어 제약을 어기게 할 수도 있습니다. AC까지 읽는 것이 명세 검토의 완성입니다.

Task Runner의 승인은 알림 패널에 오고, 승인이 진행의 관문입니다. 성공 보고는 “무엇이”와 “결과가 어디에 남았는가”를 함께 확인해야 완성됩니다.

그리고 명세를 고치면 — 같은 도구, 같은 격리에서 — 의도대로 됩니다. 루프의 품질은 명세의 품질입니다.

먼저 스스로 답해 본 뒤 접힌 답과 비교해 보세요.

Export YAML로 내보낸 계획을 From YAML로 재실행하면 무엇이 달라지는가?

미러의 결과를 원본에 반영해야 한다면 어떤 절차여야 하는가? 누가 diff를 읽고 누가 승인하는가?

핸즈온에서 만든 태스크 명세와 DAG를 여러분의 반복 업무로 바꾸어 한 번 더 실행해 봅니다. 실제 민감 데이터나 회사 자료는 넣지 말고, 가상의 입력 파일과 숫자로 작업 순서와 검증 기준만 연습하세요.

• 대학생: 팀 발표 준비를 명세로 만들어 자료 조사·슬라이드 초안·발표 대본 검토를 병렬 단계로 나누고, 마지막에 세 결과를 합쳐 누락된 근거와 발표 시간을 검증하는 DAG를 설계합니다.
• 대학원생: 가상의 실험 데이터 분석을 명세로 만들어 데이터 정리·기초 통계·그래프 생성을 병렬로 실행한 뒤, 결과를 합쳐 표본 수와 분석 조건이 원본 메모와 일치하는지 검증 단계로 넣습니다.
• 교수: 한 차시 수업 준비를 명세로 만들어 학습목표 점검·읽기자료 요약·토론 질문 생성을 병렬로 배치하고, 마지막에 세 결과가 학습목표와 맞는지 Acceptance Criteria로 확인합니다.
• 공공기관 재직자: 가상의 월간 사업 현황 보고를 명세로 만들어 부서별 실적·예산·위험 요약을 병렬로 만들고, 종합 단계에서 수치 합계와 필수 항목을 대조하도록 DAG를 구성합니다.
• 일반 직장인: 가상의 주간 영업 보고를 명세로 만들어 팀별 실적 집계·고객 이슈 분류·다음 주 전망을 병렬 처리한 뒤, 최종 보고서의 합계와 원본 파일 위치를 검증하도록 성공 조건을 구체화합니다.