66일차 교안/실습 추가

Last3Mon/66/LAB-01-DESIGN-DATA-FLOW.md

@@ -0,0 +1,108 @@
+# Lab 01 · 회의록 자동 정리 워크플로우 설계하기
+
+- 관련 강의: [1단계 · 단일 업무 자동화 설계와 데이터 흐름](../../Lecture/66/01-STAGE1-DESIGN-AND-DATA-FLOW.md)
+- 소요 시간: 약 22분 (예제 1 5분 · 예제 2 7분 · 과제 10분)
+- 목표: 노드를 만들기 전에 **연결선마다 몇 개의 항목이 흐르는지** 읽고 쓸 수 있다.
+- 결과물: `my-work/LAB-01-DESIGN.md`
+
+```mermaid
+flowchart LR
+  E1["예제 1<br/>어제 만든 흐름 읽기"] --> E2["예제 2<br/>오늘 흐름의 빈칸 채우기"] --> T["과제<br/>요청이 바뀌면<br/>어디를 고치나?"]
+```
+
+먼저 활동지를 복사합니다.
+
+```bash
+cd ~/aio-01d4-stu/Last3Mon/66
+mkdir -p my-work
+cp templates/LAB-01-WORKSHEET.md my-work/LAB-01-DESIGN.md
+```
+
+## 예제 1 · 어제 만든 흐름 읽기 (5분)
+
+65일차 Lab 02A에서 직접 만든 `65-00 My first workflow`입니다.
+
+```mermaid
+flowchart LR
+  T(["Start<br/>Manual Trigger"]) --> S["Sample request<br/>Edit Fields"] --> I{"Is urgent?<br/>If"}
+  I -->|true| U["Urgent route"]
+  I -->|false| N["Normal route"]
+```
+
+활동지 1절의 표를 채웁니다. 항목(item)은 노드 사이를 지나가는 **데이터 한 덩어리**입니다.
+
+| 연결 | 항목 수 | 지나가는 필드 |
+| --- | --- | --- |
+| Start → Sample request | 1 | (없음) |
+| Sample request → Is urgent? | ( ? ) | `user`, `text` |
+| Is urgent? → Urgent route | ( ? ) | `user`, `text` |
+
+<details><summary>답 보기</summary>
+
+모두 **1개**입니다. If 노드는 항목을 **나누어 보낼 뿐** 개수를 늘리지 않습니다. 요청 1건은 true나 false 중 **한쪽 길로만** 갑니다.
+</details>
+
+## 예제 2 · 오늘 흐름의 빈칸 채우기 (7분)
+
+오늘 만들 회의록 워크플로우입니다. 회의록 1건에서 할 일 4건이 나옵니다 (예시: `n8n/requests/weekly.json`).
+
+```mermaid
+flowchart LR
+  W(["Meeting webhook"]) --> S["Settings"] --> H{"Has notes?"}
+  H -->|false| R0["Reject empty"]
+  H -->|true| L1{{"LLM extract actions"}} --> P["Parse actions"] --> J["Join results"]
+  H -->|true| L2{{"LLM summarize"}} --> K["Keep summary"] --> J
+  J --> A{"Any actions?"}
+  A -->|true| SO["One item per action<br/>Split Out"] --> N["Normalize action"] --> AG["Collect actions<br/>Aggregate"] --> B["Build report"] --> R["Send result"]
+  A -->|false| NA["No actions"] --> R
+```
+
+활동지 2절의 빈칸 다섯 개를 채웁니다.
+
+| 번호 | 질문 | 답 |
+| --- | --- | --- |
+| ① | `Parse actions` → `Join results` 의 항목 수 | ( ? ) |
+| ② | `One item per action` → `Normalize action` 의 항목 수 | ( ? ) |
+| ③ | `Collect actions` → `Build report` 의 항목 수 | ( ? ) |
+| ④ | `LLM extract actions`와 `LLM summarize`를 **동시에** 돌려도 되는 이유 | ( ? ) |
+| ⑤ | 할 일 찾기·요약·`미정` 채우기·우선순위 정하기 중 **LLM이 하는 일** 두 가지 | ( ? ) |
+
+<details><summary>답 보기</summary>
+
+| 번호 | 답 |
+| --- | --- |
+| ① | 1 (할 일 4건이 `actions` **목록 하나**에 들어 있음) |
+| ② | **4** (Split Out이 목록을 할 일 하나씩으로 펼침, 1 → 4) |
+| ③ | **1** (Aggregate가 다시 목록 하나로 모음, 4 → 1) |
+| ④ | 할 일 찾기와 요약은 **서로의 결과가 필요 없기** 때문 |
+| ⑤ | 할 일 찾기, 요약. `미정` 채우기와 우선순위는 **규칙**(항상 같은 답) |
+</details>
+
+## 과제 · 요청이 바뀌면 어디를 고치나? (10분)
+
+팀장이 새로 요청했습니다.
+
+> "담당자나 기한이 정해지지 않은 할 일은 **확인 필요**로 표시해 주세요. 그리고 확인이 필요한 할 일이 **몇 건인지**도 결과에 넣어 주세요."
+
+예제 2의 그림을 보면서 활동지 3절의 질문에 답합니다. 노드를 새로 만들 필요가 있는지, 있던 노드를 고치면 되는지 생각해 보세요.
+
+1. 이 판단은 LLM이 할 일인가요, 규칙이 할 일인가요? 왜 그런가요?
+2. "이 할 일은 확인 필요인가?"는 할 일 **하나마다** 정하는 일입니다. 그림에서 할 일이 하나씩 흐르는 노드는 어디인가요? 거기에 어떤 필드를 더하나요?
+3. "몇 건인지"는 할 일을 **모두 모은 뒤**에야 셀 수 있습니다. 어느 노드에서 세나요?
+4. 할 일이 하나도 없는 회의(`No actions` 길)의 결과에는 무엇을 넣어야 하나요?
+5. 이 변경으로 연결선의 항목 수가 바뀌는 곳이 있나요?
+
+> 정답은 하나가 아닙니다. 위치와 이유를 한 줄씩 적으면 됩니다. 이 설계는 **Lab 03 과제**에서 실제로 만듭니다.
+
+<details><summary>힌트</summary>
+
+- 규칙으로 쓸 수 있는지 문장으로 적어 보세요: "담당자가 `미정`이거나 기한이 `미정`이면 확인 필요".
+- 할 일 하나마다 우선순위(`priority`)를 정하던 노드를 떠올려 보세요.
+- 결과 형식은 두 길이 **같은 필드**로 끝나야 합니다 (1단계 2.1절).
+</details>
+
+## 확인
+
+- [ ] 예제 1의 표를 채우고, If가 항목 수를 바꾸지 않는다는 것을 설명할 수 있다.
+- [ ] 예제 2의 ①~⑤를 채웠다 (1 → 4 → 1).
+- [ ] 과제 1~5에 위치와 이유를 한 줄씩 적었다.