단위 프로젝트(80~82일차): 시간표 AIO-P4-TIMELINE, 팀 VM · 산출물 점검과 발표 · 81일차 동결 · 14:50 제출 · 평가 시험 25문항(재시험 15), 입구 · 뒷단 조합 A · B · C와 어댑터

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Lecture/80-82-Project/AIO-P4-TIMELINE.md

@@ -0,0 +1,34 @@
+# 노코드 멀티 에이전트 워크플로우 설계 및 운영 프로젝트 시간표
+
+**80일차 · 11/05 (목) 설계와 골격**
+- 1교시 (09:00) : 팀 발표·역할 정하기, 팀 VM 접속 확인 - 강사: 킥오프 (안내서·평가 기준·공통 계약·VM 배정 안내) - 끝 표시: 팀 명단·VM 접속
+- 2교시 (10:00) : 주제·조합(A/B/C) 정하기, 주제 제안서·팀 헌장·저장소 - 강사: 주제 제안서 승인 (10:50까지) - 끝 표시: 헌장·주제 커밋
+- 3교시 (11:00) : 범위 정하기 (문의 유형·지식 문서·권한·팀 시나리오 5개), 팀장은 VM에 n8n·data-api·Credential 준비 - 강사: 팀 순회 - 끝 표시: cases/team.json 초안
+- 4교시 (12:00) : 워크플로우 설계서 1~4절 (업무 시나리오·흐름도·역할 카드·분기 기준) - 강사: 팀 순회 - 끝 표시: 설계서 1~4절 초안
+- 5교시 (14:00) : 확인받는 팀 외에는 골격 워크플로우 (웹훅 → 입력 검사 → 응답) - 강사: 산출물 1차 점검 (팀별 10분, 설계서 1~4절·공통 계약) - 끝 표시: 점검 피드백
+- 6교시 (15:00) : 피드백 반영 + RAG 색인 워크플로우, 청크 길이 분포 재기 - 강사: 팀 순회 - 끝 표시: RAG 설계서 1~2절
+- 7교시 (16:00) : 도구 노드 연결 (접수·티켓·알림) → 팀장이 VM에 첫 배포 - 강사: 팀 순회 - 끝 표시: VM에서 WF-08·13 통과
+- 8교시 (17:00) : 산출물 발표 ① (팀별 10분)·데일리 기록 - 강사: 발표 진행·피드백 (설계서 2종 초안·VM 동작) - 끝 표시: 발표 피드백·데일리
+
+**81일차 · 11/06 (금) 구현과 예외 처리**
+- 1교시 (09:00) : 스탠드업·어제 피드백 반영 계획, VM에서 공통 시나리오 출발점 기록 - 강사: 팀별 VM 상태·출발점 확인 - 끝 표시: 통과 수 (출발점)
+- 2교시 (10:00) : 분류·검색·답변 Agent - 강사: 팀 순회 - 끝 표시: WF-01 통과
+- 3교시 (11:00) : 검증 Agent·신뢰도 분기·담당자 이관 (티켓 생성) - 강사: 팀 순회 - 끝 표시: WF-03 통과
+- 4교시 (12:00) : 루프·병렬·복합 문의, B·C 팀은 입구·뒷단 어댑터, 팀장은 VM 배포 1회 - 강사: 산출물 중간점검 (팀별 10분, 페이로드 표·RAG 3~5절·연동 표) - 끝 표시: WF-02·11·12
+- 5교시 (14:00) : 보안: 주입 차단·본인 건만·개인정보 가림 - 강사: 팀 순회 - 끝 표시: WF-05~08
+- 6교시 (15:00) : 외부 장애: 시간 제한·재시도·DLQ·알림·중복 방지 - 강사: 팀 순회 - 끝 표시: WF-04·09·10
+- 7교시 (16:00) : Error Workflow 게시·설계서 5~7절·실행 결과서 1절 시작, 팀장은 VM 배포 2회 + 전체 회귀 - 강사: 팀 순회 - 끝 표시: 설계서 2종 완성
+- 8교시 (17:00) : 산출물 발표 ② (팀별 10분)·데일리 기록 - 강사: 발표 진행 후 기능 동결 (설계서 2종 완성·결과서 초안) - 끝 표시: 통과 수·동결 선언
+
+**82일차 · 11/09 (월) 시연·제출·발표**
+- 1교시 (09:00) : 데일리 점검, VM에서 시연 순서 한 번 돌려 보기 - 강사: 전체 시연·발표 상황 점검 - 끝 표시: 팀별 남은 일 목록
+- 2교시 (10:00) : 발표 자료 만들기 + 산출물 3종 숫자를 runs/에서 맞추기 - 강사: 발표 자료·산출물 3종 점검 - 끝 표시: 발표 자료 초안
+- 3교시 (11:00) : 1·2팀은 VM 시연 리허설, 3·4팀은 결과서 숫자·LLM 3회 반복 - 강사: 1·2팀 시연 발표 상황 확인 - 끝 표시: 리허설 통과
+- 4교시 (12:00) : 3·4팀은 VM 시연 리허설, 1·2팀은 결과서·실패 사례 정리 - 강사: 3·4팀 시연 발표 상황 확인 - 끝 표시: 리허설 통과
+- 5교시 (14:00) : 산출물 3종 마무리·tscan 비밀 검사·저장소 제출 - 강사: 산출물 3종 제출 확인 - 끝 표시: 마지막 커밋 (14:50)
+- 6교시 (15:00) : 1·2팀 최종 발표 (산출물 3종 + 시연, 20분 + 질의 5분) - 강사: 발표 진행·질의 - 끝 표시: 동료 평가지
+- 7교시 (16:00) : 3·4팀 최종 발표 (산출물 3종 + 시연, 20분 + 질의 5분) - 강사: 발표 진행·질의 - 끝 표시: 동료 평가지
+- 8교시 (17:00) : 평가 시험 - 강사: 시험 진행·총평 - 끝 표시: 답안 제출
+
+> 1,2,3,4 팀의 발표순서는 별도 정함 
+> 재시험은 83일차 점심 시간에 봄

Lecture/80-82-Project/student/00-PROJECT-GUIDE.md

@@ -1,7 +1,7 @@
 # 단위 프로젝트 안내서 · 지능형 기술 지원 자동화(Tech Support) 워크플로우
 
 - 기간: 80~82일차 (2026-11-05 목, 11-06 금, 11-09 월), 하루 8교시 · 모두 24시간
-- **82일차 8교시(17:00~17:50)는 평가 시험 40문제**입니다. 프로젝트 제출(13:50) · 발표(5~6교시) · 총평(7교시) 뒤에 봅니다.
+- **82일차 8교시(17:00~17:50)는 평가 시험 25문항**입니다. 통과하지 못한 사람은 재시험(15문항)을 봅니다. 프로젝트 제출(14:50) · 최종 발표(6~7교시) 뒤에 보고, 총평은 시험과 함께 합니다.
 - 교과목: 노코드 멀티 에이전트 워크플로우 설계 및 운영
 - 주제: 노코드·로코드 기반 기업형 '지능형 기술 지원 자동화(Tech Support)' 워크플로우 구축 — **이 큰 틀 안에서 팀마다 주제를 정합니다** ([11-TOPIC-GUIDE](11-TOPIC-GUIDE.md))
 - 원본 요구: [Req/KSM-REQ.md](../Req/KSM-REQ.md) (교과목 프로젝트 진행 가이드), 평가 기준표 `Req/*.xlsx`
@@ -88,6 +88,7 @@ flowchart LR
 
 ### 가산 (선택)
 
+- 입구 · 뒷단 조합 B(텔레그램 · Zammad) · C(웹 화면 · FastAPI) — 80일차 2교시에 주제와 함께 정함 ([11-TOPIC-GUIDE](11-TOPIC-GUIDE.md) 7절). A로 공통 시나리오를 먼저 통과시킨 뒤 어댑터를 붙임
 - 실제 외부 서비스(Slack · Email · Jira · Notion) 연동 — 팀 계정이 있을 때만, **회사 · 개인 실서비스 계정의 키를 저장소에 올리지 않음**
 - 지속형 벡터 저장소(PGVector · Qdrant 등)로 색인을 보존하고 백업 · 복구를 실제로 시연
 - 74일차 배포 관문(`flow.py gate`), 75일차 사용량 · 비용 기록, 77일차 운영 지표, 79일차 Ops Assistant에 프로젝트 로그 연결
@@ -118,8 +119,8 @@ flowchart LR
 | 문서 | 내용 |
 | --- | --- |
 | [11-TOPIC-GUIDE](11-TOPIC-GUIDE.md) | **주제 정하기**: 큰 틀의 조건 5가지 · 주제 예 8개 · 기본 주제와의 차이 · 공통 시나리오 옮기기 |
-| [01-SCHEDULE-AND-TEAMS](01-SCHEDULE-AND-TEAMS.md) | 3일 시간표 · 마감 · 팀 역할 · 매일 점검 |
-| [02-ENVIRONMENT-AND-SERVICES](02-ENVIRONMENT-AND-SERVICES.md) | 환경, 외부 서비스를 무엇으로 대신하나, 인증 · 키 · 비용 |
+| [01-SCHEDULE-AND-TEAMS](01-SCHEDULE-AND-TEAMS.md) | 3일 시간표 · 산출물 점검 · 발표 · 마감 · 팀 역할 |
+| [02-ENVIRONMENT-AND-SERVICES](02-ENVIRONMENT-AND-SERVICES.md) | 환경 · 팀 VM, 외부 서비스를 무엇으로 대신하나, 인증 · 키 · 비용 |
 | [03-SCENARIOS-AND-DATA](03-SCENARIOS-AND-DATA.md) | 공통 데이터 · 문의 유형 · 권한 · 공통 시나리오 14개 · 팀 시나리오 |
 | [04-REFERENCE-ARCHITECTURE](04-REFERENCE-ARCHITECTURE.md) | 역할 · 노드 · 페이로드 · 분기 · 병렬 · 루프 · 64~79일차 매핑 |
 | [05-RAG-DESIGN-GUIDE](05-RAG-DESIGN-GUIDE.md) | 청킹 · 임베딩 · 저장소 · 메타데이터 · 백업 · 확장 |

Lecture/80-82-Project/student/01-SCHEDULE-AND-TEAMS.md

@@ -1,7 +1,8 @@
 # 일정 · 팀 · 역할
 
 - 하루 8교시: 1교시 09:00 · 2교시 10:00 · 3교시 11:00 · 4교시 12:00~12:50 · 점심 13:00~14:00 · 5교시 14:00 · 6교시 15:00 · 7교시 16:00 · 8교시 17:00~17:50
-- 원본 요구의 권장 진행 순서(1~4단계)를 3일에 나눴습니다. 날마다 **끝났다는 표시**가 있고, 8교시에 강사가 그것을 확인합니다.
+- 원본 요구의 권장 진행 순서(1~4단계)를 3일에 나눴습니다. 교시마다 **끝났다는 표시**가 있습니다.
+- 팀마다 인터넷으로 접속할 수 있는 **팀 VM**이 하나 있습니다. 개발은 각자 노트북에서 하고, 팀장이 VM에 배포합니다. 산출물 발표 · 리허설 · 최종 시연은 VM에서 합니다 ([02-ENVIRONMENT-AND-SERVICES](02-ENVIRONMENT-AND-SERVICES.md) 1절).
 
 ```mermaid
 gantt
@@ -9,62 +10,68 @@ gantt
   dateFormat  YYYY-MM-DD HH:mm
   axisFormat  %m/%d %H시
   section 80일차 (목) 설계 · 골격
-  킥오프 · 팀 · 헌장          :a1, 2026-11-05 09:00, 2h
-  범위 · 시나리오 · 설계 초안  :a2, after a1, 2h
-  골격 워크플로우 · RAG 색인   :a3, 2026-11-05 14:00, 3h
-  설계 리뷰                    :crit, a4, after a3, 1h
+  킥오프 · 주제 · 범위 · 설계     :a1, 2026-11-05 09:00, 4h
+  산출물 1차 점검 · 골격          :crit, a2, 2026-11-05 14:00, 1h
+  RAG 색인 · 도구 · VM 첫 배포    :a3, after a2, 2h
+  산출물 발표 ①                  :crit, a4, after a3, 1h
   section 81일차 (금) 구현 · 예외
-  RAG 검색 · 도구 · 에이전트   :b1, 2026-11-06 09:00, 4h
-  예외 처리 · 보안             :b2, 2026-11-06 14:00, 3h
-  중간 점검                    :crit, b3, after b2, 1h
-  section 82일차 (월) 시나리오 시험 · 제출 · 발표 · 평가 시험
-  시험 · 고치기 · 결과서       :c1, 2026-11-09 09:00, 4h
-  제출 마감 13:50              :milestone, c2, 2026-11-09 13:50, 0h
-  발표 · 동료 평가 · 총평      :c3, 2026-11-09 14:00, 3h
-  평가 시험 40문제             :crit, c4, 2026-11-09 17:00, 50m
+  에이전트 · 검증 · 이관          :b1, 2026-11-06 09:00, 3h
+  산출물 중간점검 · VM 배포 1     :crit, b2, 2026-11-06 12:00, 1h
+  보안 · 장애 · VM 배포 2         :b3, 2026-11-06 14:00, 3h
+  산출물 발표 ② · 기능 동결       :crit, b4, after b3, 1h
+  section 82일차 (월) 시연 · 제출 · 발표 · 평가 시험
+  점검 · 발표 자료 · 리허설       :c1, 2026-11-09 09:00, 4h
+  산출물 마무리 · 제출            :c2, 2026-11-09 14:00, 1h
+  제출 마감 14:50                 :milestone, c3, 2026-11-09 14:50, 0h
+  최종 발표 (1·2팀 → 3·4팀)       :c4, 2026-11-09 15:00, 2h
+  평가 시험 25문항                :crit, c5, 2026-11-09 17:00, 50m
 ```
 
 ## 1. 80일차 (11/05 목) · 설계와 골격
 
-| 교시 | 할 일 | 원본 단계 | 끝났다는 표시 |
+| 교시 | 할 일 | 강사 | 끝났다는 표시 |
 | --- | --- | --- | --- |
-| 1 | 킥오프: 안내서 · 평가 기준 · 공통 계약 설명 (강사), 팀 발표, 후반 15분 **주제 후보** 고르기 | — | 팀 명단, 주제 후보 2~3개 |
-| 2 | **주제 제안서 → 강사 승인 (10:30까지)**, 팀 헌장 (역할 · 규칙 · 저장소), 저장소 만들기, 환경 점검 (`flow.py doctor`) | — | `docs/TOPIC.md` · `docs/TEAM-CHARTER.md`, 팀원 모두 `ready` |
-| 3 | 범위 정하기: 처리할 문의 유형 · 지식 문서 · 권한 · 우리 팀 시나리오 5개. 다른 주제 팀은 데이터 · 문서 만들기 시작 | 1단계 | [03-SCENARIOS-AND-DATA](03-SCENARIOS-AND-DATA.md)의 표를 채움 |
-| 4 | 워크플로우 설계서 초안: 업무 시나리오 · 전체 흐름 · 흐름도 · 역할 표 | 1 · 2단계 | 설계서 1~3절 |
-| 5 | 골격 워크플로우: Webhook → 입력 검사 → (가짜) 분류 → Respond, 계약 모양만 맞추기 | 1단계 | 공통 시나리오 중 400 · 차단이 통과 |
-| 6 | RAG 색인 워크플로우: 문서 가져오기 · 청킹 · 임베딩 · 저장, 청크 길이 분포 재기 | 1단계 | 색인 개수, RAG 설계서 1~2절 초안 |
-| 7 | 도구 노드 연결: 접수 조회 · 티켓 생성 · 알림, 노드마다 입력 · 출력 · 인증 확인 | 1단계 | 도구 노드를 한 번씩 `call`로 확인 |
-| 8 | **설계 리뷰** (팀별 5분, 강사): 다른 주제 팀은 옮긴 `cases/common.json` 확인, 데일리 기록 | — | 강사 피드백 칸 |
+| 1 (09:00) | 팀 발표 · 역할 정하기, 팀 VM 접속 확인, 후반 15분 **주제 후보** 고르기 | 킥오프 (안내서 · 평가 기준 · 공통 계약 · VM 배정 안내) | 팀 명단 · VM 접속 |
+| 2 (10:00) | 주제 · 입구 · 뒷단 조합(A/B/C, [11-TOPIC-GUIDE](11-TOPIC-GUIDE.md) 7절) 정하기, [주제 제안서](templates/TOPIC-PROPOSAL-TEMPLATE.md) · [팀 헌장](templates/TEAM-CHARTER-TEMPLATE.md) · 저장소, 각자 환경 점검 (`flow.py doctor`) | **주제 제안서 승인 (10:50까지)** | `docs/TOPIC.md` · `docs/TEAM-CHARTER.md` 커밋 |
+| 3 (11:00) | 범위 정하기: 문의 유형 · 지식 문서 · 권한 · 팀 시나리오 5개 (1단계). 팀장은 VM에 n8n · 데이터 API · Credential 준비. 다른 주제 팀은 데이터 · 문서 만들기 시작 | 팀 순회 | `cases/team.json` 초안, [03-SCENARIOS-AND-DATA](03-SCENARIOS-AND-DATA.md)의 표 |
+| 4 (12:00) | 워크플로우 설계서 1~4절: 업무 시나리오 · 흐름도 · 역할 카드 · 분기 기준 (1 · 2단계) | 팀 순회 | 설계서 1~4절 초안 |
+| 5 (14:00) | **산출물 1차 점검** (팀별 10분). 점검받는 팀 외에는 골격 워크플로우: Webhook → 입력 검사 → (가짜) 분류 → Respond, 계약 모양만 맞추기 | 1차 점검 (설계서 1~4절 · 공통 계약, 다른 주제 팀은 옮긴 `cases/common.json`) | 점검 피드백, 공통 시나리오 중 400 · 차단 통과 |
+| 6 (15:00) | 피드백 반영 + RAG 색인 워크플로우: 문서 가져오기 · 청킹 · 임베딩 · 저장, 청크 길이 분포 재기 | 팀 순회 | 색인 개수, RAG 설계서 1~2절 |
+| 7 (16:00) | 도구 노드 연결 (접수 조회 · 티켓 생성 · 알림, 노드마다 입력 · 출력 · 인증 확인) → 팀장이 **VM에 첫 배포** | 팀 순회 | VM에서 WF-08 · WF-13 통과 |
+| 8 (17:00) | **산출물 발표 ①** (팀별 10분), 데일리 기록 | 발표 진행 · 피드백 (설계서 2종 초안 · VM 동작) | 발표 피드백 · `docs/daily/DAY80.md` |
 
 ## 2. 81일차 (11/06 금) · 구현과 예외 처리
 
-| 교시 | 할 일 | 원본 단계 | 끝났다는 표시 |
+| 교시 | 할 일 | 강사 | 끝났다는 표시 |
 | --- | --- | --- | --- |
-| 1 | 데일리 점검 (어제 피드백 · 오늘 목표 숫자), 공통 시나리오 한 번 돌려 출발점 기록 | — | 공통 시나리오 통과 수 (출발점) |
-| 2 | 분류 Agent · 검색 · 답변 Agent: 정상 FAQ 답 + 근거 | 2단계 | WF-01 통과 |
-| 3 | 검증 Agent · 신뢰도 분기 · 이관 (티켓 생성) | 2단계 | WF-03 통과 |
-| 4 | 루프(보완 질문) · 병렬(두 검색) · 복합 문의 | 2단계 | WF-02 · WF-11 통과 |
-| 5 | 입력 · 출력 보안: 주입 차단 · 본인 건 · 개인정보 가림 | 3단계 | WF-05 · WF-06 · WF-07 |
-| 6 | 외부 장애: timeout · 재시도 · DLQ · 알림, 중복 요청 | 3단계 | WF-04 · WF-08 · WF-09 · WF-10 |
-| 7 | Error Workflow 게시, 실행 기록 남기기, 설계서 페이로드 표 채우기 | 3단계 | 설계서 5~7절 |
-| 8 | **중간 점검** (강사, 팀별 7분: 공통 시나리오 실행 화면 + 남은 것), 데일리 기록 | — | 중간 점검표 |
+| 1 (09:00) | 스탠드업 · 어제 피드백 반영 계획, VM에서 공통 시나리오를 돌려 출발점 기록 | 팀별 VM 상태 · 출발점 확인 | 공통 시나리오 통과 수 (출발점) |
+| 2 (10:00) | 분류 Agent · 검색 · 답변 Agent: 정상 FAQ 답 + 근거 (2단계) | 팀 순회 | WF-01 통과 |
+| 3 (11:00) | 검증 Agent · 신뢰도 분기 · 담당자 이관 (티켓 생성) (2단계) | 팀 순회 | WF-03 통과 |
+| 4 (12:00) | 루프(보완 질문) · 병렬(두 검색) · 복합 문의, B · C 팀은 입구 · 뒷단 어댑터 (A 팀은 루프 · 병렬 · 복합만), 팀장은 **VM 배포 1회** | **산출물 중간점검** (팀별 10분, 페이로드 표 · RAG 3~5절 · 연동 표) | WF-02 · WF-11 · WF-12 |
+| 5 (14:00) | 보안: 주입 차단 · 본인 건만 · 개인정보 가림 (3단계) | 팀 순회 | WF-05 ~ WF-08 |
+| 6 (15:00) | 외부 장애: 시간 제한 · 재시도 · DLQ · 알림 · 중복 방지 (3단계) | 팀 순회 | WF-04 · WF-09 · WF-10 |
+| 7 (16:00) | Error Workflow 게시 · 설계서 5~7절 · 실행 결과서 1절 시작, 팀장은 **VM 배포 2회 + 전체 회귀** | 팀 순회 | 설계서 2종 완성 |
+| 8 (17:00) | **산출물 발표 ②** (팀별 10분), 데일리 기록 | 발표 진행 후 **기능 동결** (설계서 2종 완성 · 결과서 초안) | 통과 수 · 동결 선언 · `docs/daily/DAY81.md` |
 
-## 3. 82일차 (11/09 월) · 시나리오 시험 · 제출 · 발표 · 평가 시험
+> **81일차 8교시에 기능을 동결합니다.** 82일차에는 새 기능을 붙이지 않고 시험 · 고치기 · 문서 · 발표 준비만 합니다. 늦게 붙인 기능이 앞의 것을 깨뜨리는 일이 3일 프로젝트에서 가장 흔한 실패입니다. 발표 ②에서 공통 시나리오가 절반도 통과하지 않으면, 가산 기능은 버리고 필수만 고칩니다.
 
-| 교시 | 할 일 | 원본 단계 | 끝났다는 표시 |
+## 3. 82일차 (11/09 월) · 시연 · 제출 · 발표
+
+| 교시 | 할 일 | 강사 | 끝났다는 표시 |
 | --- | --- | --- | --- |
-| 1 | 데일리 점검, 동결 기준 정하기 (11시 뒤로는 고치지 않고 시험 · 문서만) | — | |
-| 2 | 공통 · 장애 · 팀 시나리오 전부, LLM이 들어간 것 3회 반복 | 4단계 | `runs/` 보고서 |
-| 3 | 실패 원인 · 조치 · 재시험, 결과서 숫자 채우기 | 4단계 | 결과서 1~4절 |
-| 4 | 문서 마무리 (설계서 둘 · 결과서 · README), 비밀 검사(`tscan`), **13:50 제출** | — | 마지막 커밋 시각 |
-| 5~6 | **팀 발표** (4팀, 팀당 15분 발표 · 시연 + 5분 질문), 동료 평가 | — | 동료 평가지 |
-| 7 | 발표 보충 · 강사 재실행 확인 (공통 시나리오를 팀 저장소대로 다시 돌림), **총평** · 최종 프로젝트(83일차~) 안내 | — | |
-| 8 | **평가 시험 (40문제, 17:00~17:50)** | — | 답안 제출 |
+| 1 (09:00) | 데일리 점검, VM에서 시연 순서를 한 번 돌려 보기 | 전체 시연 · 발표 상황 점검 | 팀별 남은 일 목록 |
+| 2 (10:00) | 발표 자료 만들기 + 산출물 3종의 숫자를 `runs/`에서 맞추기 (4단계) | 발표 자료 · 산출물 3종 점검 | 발표 자료 초안 |
+| 3 (11:00) | 1 · 2팀은 VM 시연 리허설, 3 · 4팀은 결과서 숫자 · LLM 3회 반복 | 1 · 2팀 시연 · 발표 상황 확인 | 리허설 통과 |
+| 4 (12:00) | 3 · 4팀은 VM 시연 리허설, 1 · 2팀은 결과서 · 실패 사례 정리 | 3 · 4팀 시연 · 발표 상황 확인 | 리허설 통과 |
+| 5 (14:00) | 산출물 3종 마무리 · 데일리 기록 · `tscan` 비밀 검사 · 저장소 제출 | 산출물 3종 제출 확인 | **마지막 커밋 (14:50)** |
+| 6 (15:00) | 1 · 2팀 최종 발표 (산출물 3종 + 시연, 팀당 20분 + 질의 5분), 동료 평가 | 발표 진행 · 질의 | 동료 평가지 |
+| 7 (16:00) | 3 · 4팀 최종 발표 (산출물 3종 + 시연, 팀당 20분 + 질의 5분), 동료 평가 | 발표 진행 · 질의 | 동료 평가지 |
+| 8 (17:00) | **평가 시험 (25문항, 17:00~17:50)** | 시험 진행 · 총평 | 답안 제출 |
 
-> **82일차 8교시는 평가 시험(40문제)입니다.** 프로젝트 일은 7교시까지 끝냅니다. 발표 · 시연을 하며 팀원 모두가 워크플로우 · RAG · 예외 처리를 설명할 수 있게 준비하면 시험 준비도 됩니다.
+- 위 표의 1 · 2 · 3 · 4팀은 **발표 순서**입니다. 순서는 따로 정해 알립니다.
+- 82일차 데일리 기록(`docs/daily/DAY82.md`)은 5교시 제출 전에 씁니다.
 
-> 81일차 8교시 중간 점검에서 공통 시나리오가 절반도 통과하지 않으면, 82일차에는 **가산 기능을 멈추고 필수만** 끝냅니다. 늦게 붙인 기능이 앞의 것을 깨뜨리는 일이 3일 프로젝트에서 가장 흔한 실패입니다.
+> **82일차 8교시는 평가 시험(25문항)입니다.** 통과하지 못하면 재시험(15문항)을 봅니다. 프로젝트 일은 5교시 제출로 끝납니다. 발표 · 시연을 하며 팀원 모두가 워크플로우 · RAG · 예외 처리를 설명할 수 있게 준비하면 시험 준비도 됩니다.
 
 ## 4. 팀과 역할 (4팀 · 5~6명)
 
@@ -72,7 +79,7 @@ gantt
 
 | 역할 | 주로 하는 일 | 주로 쓰는 산출물 절 | 64~79일차 |
 | --- | --- | --- | --- |
-| 리드 · 통합 | 범위 · 계약 지키기, 하루 목표 숫자, 병합 · 동결, 발표 | 헌장, 데일리, README | 70 모듈 · 74 버전 |
+| 팀장 (리드 · 통합) | 범위 · 계약 지키기, 하루 목표 숫자, 병합 · 동결, **팀 VM 준비 · 배포**, 발표 | 헌장, 데일리, README | 70 모듈 · 74 버전 |
 | 오케스트레이션 | 분류 · 답변 · 검증 Agent, 분기 · 병렬 · 루프 | 워크플로우 설계서 2~4절 | 68 · 69 |
 | RAG | 문서 · 청킹 · 임베딩 · 검색 품질 | RAG 설계서 전부 | 71 |
 | 연동 · 안정성 | 도구 노드 · 인증 · 오류 처리 · DLQ · 알림 · 보안 | 워크플로우 설계서 5~7절 | 67 · 72 · 73 · 76 |
@@ -81,8 +88,9 @@ gantt
 **팀 규칙 (헌장에 적을 것)**
 
 - 워크플로우 JSON은 **한 사람이 한 파일**을 맡습니다. 같은 파일을 둘이 동시에 고치면 n8n import에서 한쪽이 사라집니다. 큰 워크플로우는 70일차처럼 **모듈(하위 워크플로우)**로 나눠 사람마다 맡습니다.
-- 공통 계약(요청 · 응답 칸)은 리드의 허락 없이 바꾸지 않습니다.
+- 공통 계약(요청 · 응답 칸)은 팀장의 허락 없이 바꾸지 않습니다.
 - 고칠 때마다 공통 시나리오를 다시 돌립니다 (회귀). 깨뜨린 사람이 고칩니다.
+- VM에는 팀장만 배포합니다. 배포는 저장소의 기본 브랜치에서 하고, 배포 뒤 VM에서 공통 시나리오를 돌립니다.
 - 하루 끝에 데일리 기록 한 장: 한 일 · 숫자 · 막힌 것 · 내일.
 
 ## 5. 매일 점검
@@ -90,7 +98,10 @@ gantt
 | 언제 | 누가 | 무엇을 보나 |
 | --- | --- | --- |
 | 매일 1교시 | 팀 (10분 스탠드업) | 어제 한 일 · 오늘 목표 숫자 · 막힌 것 |
-| 80일차 8교시 | 강사 · 설계 리뷰 | 범위가 3일에 맞나, 흐름도 · 역할 · 계약, 시나리오 기대값 |
-| 81일차 8교시 | 강사 · 중간 점검 | 공통 시나리오 통과 수, 예외 처리 동작, 남은 것과 버릴 것 |
-| 82일차 13:50 | 강사 · 제출 확인 | 마지막 커밋, 필수 파일, 비밀 검사 |
-| 82일차 8교시 | 평가 시험 | 40문제 |
+| 80일차 5교시 | 강사 · 산출물 1차 점검 (팀별 10분) | 범위가 3일에 맞나, 설계서 1~4절 · 공통 계약, 시나리오 기대값 |
+| 80일차 8교시 | 강사 · 산출물 발표 ① (팀별 10분) | 설계서 2종 초안, VM에서 도는가 |
+| 81일차 4교시 | 강사 · 산출물 중간점검 (팀별 10분) | 페이로드 표 · RAG 설계서 3~5절 · 연동 표 |
+| 81일차 8교시 | 강사 · 산출물 발표 ② (팀별 10분) | 설계서 2종 완성 · 결과서 초안 · 공통 시나리오 통과 수, **기능 동결** |
+| 82일차 3 · 4교시 | 강사 · 리허설 확인 | VM 시연 순서, 발표 자료 |
+| 82일차 14:50 | 강사 · 제출 확인 | 마지막 커밋, 필수 파일, 비밀 검사 |
+| 82일차 8교시 | 평가 시험 | 25문항 (통과하지 못하면 재시험 15문항) |

Lecture/80-82-Project/student/02-ENVIRONMENT-AND-SERVICES.md

@@ -13,6 +13,7 @@
 | 도구 | `tools/flow.py` (check · push · call · test · bench · fault · llm · ops · doctor, 모두 `-v`) |
 | 코드 작성 | CLI 코딩 에이전트 (codex · claude · agy), 팀 저장소의 `AGENTS.md`를 따름 ([09-AGENT-WORKING-RULES](09-AGENT-WORKING-RULES.md)) |
 | 실습 키트 | `~/aio-01d4-stu/Last3Mon/80` (공통 시나리오 · 템플릿 · 도구, 80일차 전에 `git pull`) |
+| 팀 VM | 팀마다 하나, 인터넷으로 접속 (주소 · 계정은 80일차 1교시 안내). 팀장이 n8n · 데이터 API · Credential을 올리고 배포 · 시연에 씀 |
 
 **첫날 확인**
 
@@ -25,14 +26,19 @@ cd ~/aio-01d4-stu/Last3Mon/80 && uv run tools/flow.py doctor        # 마지막
 
 ### 팀 안에서 n8n을 어떻게 나누나
 
-각자 노트북의 n8n은 따로입니다. 다른 사람의 n8n에서 내 워크플로우는 보이지 않습니다.
+각자 노트북의 n8n은 따로입니다. 다른 사람의 n8n에서 내 워크플로우는 보이지 않습니다. 팀이 함께 보는 기준은 **팀 VM의 n8n**입니다.
 
 | 방식 | 하는 법 | 언제 |
 | --- | --- | --- |
-| **저장소로 나누기 (기본)** | 워크플로우 JSON을 팀 저장소에 두고, 각자 `git pull` → `flow.py push`로 자기 n8n에 올림 | 늘 |
-| 시연용 한 대 | 발표 · 최종 시험은 리드의 노트북 한 대에서 | 82일차 |
+| **저장소로 나누기 (기본)** | 워크플로우 JSON을 팀 저장소에 두고, 각자 `git pull` → `flow.py push`로 자기 노트북 n8n에 올려 개발 · 시험 | 늘 |
+| **팀 VM에 배포** | 팀장이 VM에서 기본 브랜치를 `git pull` → `flow.py push` → 공통 시나리오 `flow.py test` | 80일차 7교시 첫 배포, 81일차 4 · 7교시 |
+| 시연 · 발표 | 산출물 발표 · 리허설 · 최종 발표는 팀 VM에서 | 80 · 81일차 8교시, 82일차 |
 | 모듈 나누기 | 70일차처럼 하위 워크플로우(웹훅 또는 Execute Workflow)로 나눠 사람마다 한 파일 | 큰 워크플로우 |
 
+**팀 VM 준비 (80일차 3교시, 팀장)**: 노트북과 같은 순서로 n8n · 데이터 API를 켜고 `flow.py doctor`가 `ready`인지 봅니다. OpenAI · 웹훅 Header Auth · 데이터 API 키는 VM n8n의 Credential에만 넣습니다.
+
+> 팀 VM은 **인터넷에서 열립니다.** n8n 로그인 비밀번호를 기본값으로 두지 않고, 팀 웹훅에는 Header Auth를 겁니다. VM 주소 · 비밀번호 · 키를 저장소 · 문서 · 발표 자료에 쓰지 않습니다 (팀 헌장 5절에는 "팀장에게 물을 것"으로).
+
 워크플로우 이름 · 웹훅 경로 앞에 팀 이름을 붙입니다 (`team1-support`, `team1-index`). 같은 n8n에 여러 팀 것이 올라가도 겹치지 않습니다.
 
 ## 2. 외부 서비스를 무엇으로 대신하나
@@ -49,6 +55,20 @@ cd ~/aio-01d4-stu/Last3Mon/80 && uv run tools/flow.py doctor        # 마지막
 
 설계서의 "외부 연동 노드" 표에는 **연습용과 실제 운영용을 둘 다** 적습니다 (인증 방식 · 오류 코드 · 한도가 다르기 때문). 연습용에서 정상 동작을 보이고, 실제 서비스로 바꿀 때 바뀌는 곳을 표시하면 됩니다.
 
+### 조합 B · C의 어댑터 (81일차 4교시)
+
+입구 · 뒷단 조합([11-TOPIC-GUIDE](11-TOPIC-GUIDE.md) 7절)에서 A는 위 표의 연습용 그대로라 어댑터가 없습니다. B · C는 바깥 부품을 공통 계약 모양으로 바꾸는 **어댑터**를 더합니다. 두뇌(본체 워크플로우 `<팀>-support`)는 바꾸지 않습니다.
+
+| 조합 | 입구 어댑터 | 뒷단 어댑터 |
+| --- | --- | --- |
+| **B** | Telegram Trigger로 메시지를 받고, 변환 Code에서 `message.text` → `question`, `chat.id` → `user`로 바꿔 본체에 넘김. 답은 Telegram 노드로 같은 채팅방에 | 이관할 때 data-api `POST /tickets` 대신 Zammad 노드로 티켓 생성, 처리가 끝나면 Zammad 웹훅으로 n8n에 알림 |
+| **C** | FastAPI가 웹 화면의 질문을 계약 모양으로 바꿔 n8n 팀 웹훅을 호출 | FastAPI가 data-api와 같은 모양의 `/tickets` · `/alerts`를 직접 제공 (관리자 화면이 읽음) |
+
+- 순서: **A로 공통 시나리오 통과 → 어댑터.** 공통 시나리오는 어떤 조합이든 팀 웹훅으로 돌립니다.
+- Telegram Trigger · Zammad 웹훅은 바깥에서 n8n을 불러야 하므로 **팀 VM**의 n8n에 둡니다 (노트북 n8n은 바깥에서 닿지 않음).
+- 봇 토큰 · Zammad 토큰은 n8n Credential에만, FastAPI의 키는 `.env`에만 둡니다 (아래 규칙과 같음).
+- 설계서의 "외부 연동 노드" 표 · 연결선 페이로드 표에 어댑터를 **한 연결선**으로 적습니다 (바깥 모양 → 계약 모양).
+
 ### 실제 서비스를 쓰고 싶은 팀 (가산)
 
 - 팀 공용 **무료 · 연습용 계정**만 씁니다 (회사 · 개인 업무 계정 금지).

Lecture/80-82-Project/student/03-SCENARIOS-AND-DATA.md

@@ -67,7 +67,7 @@
 
 - 기대 결과는 **계약의 칸**으로 판정합니다 (`route` · `sources` · `ticket` · `security`). 답 문장은 팀마다 달라도 됩니다.
 - WF-04 · WF-10 · WF-11은 시나리오 파일의 `before` · `after`가 고장을 켜고 **반드시 끕니다**.
-- 공통 시나리오의 유형 · 판정은 **팀이 바꾸지 않습니다** (다른 주제 팀이 옮긴 파일도 80일차 설계 리뷰에서 확인받은 뒤에는 그대로). 팀의 판단이 다르다고 생각하면 (예: WF-05를 `권한 없음`과 `담당자 이관` 중 무엇으로) 설계서에 근거를 적고, 둘 다 허용된 칸 안에서 고릅니다.
+- 공통 시나리오의 유형 · 판정은 **팀이 바꾸지 않습니다** (다른 주제 팀이 옮긴 파일도 80일차 5교시 산출물 1차 점검에서 확인받은 뒤에는 그대로). 팀의 판단이 다르다고 생각하면 (예: WF-05를 `권한 없음`과 `담당자 이관` 중 무엇으로) 설계서에 근거를 적고, 둘 다 허용된 칸 안에서 고릅니다.
 
 ## 5. 팀 시나리오 (5개 이상)
 

Lecture/80-82-Project/student/07-TESTING-GUIDE.md

@@ -49,8 +49,9 @@ uv run tools/flow.py ops
 | --- | --- | --- |
 | 80일차 골격 직후 | 공통 시나리오 한 번 | 출발점 (몇 개가 그냥 통과하나) |
 | 기능 하나를 붙일 때마다 | 그 기능의 시나리오 + 공통 전부 | 회귀 (새 기능이 앞의 것을 깨지 않았나) |
-| 81일차 중간 점검 | 공통 + 장애 | 통과 수를 숫자로 |
-| 82일차 동결 뒤 | 전부 + LLM 3회 반복 + `bench` | 결과서의 최종 숫자 |
+| 팀장이 VM에 배포할 때마다 | VM에서 공통 시나리오 전부 | 노트북에서 된 것이 VM에서도 되나 |
+| 81일차 8교시 산출물 발표 ② | 공통 + 장애 | 통과 수를 숫자로, 기능 동결 |
+| 82일차 오전 (동결 뒤) | VM에서 전부 + LLM 3회 반복 + `bench` | 결과서의 최종 숫자 |
 
 ## 4. 결과서 숫자 (원본 결과서 3절 "결과 요약")
 

Lecture/80-82-Project/student/08-SUBMISSION.md

@@ -32,11 +32,11 @@
 
 | 항목 | 기준 |
 | --- | --- |
-| 마감 | **82일차(11/09 월) 13:50**, 기본 브랜치의 마지막 커밋 시각 |
+| 마감 | **82일차(11/09 월) 14:50**, 기본 브랜치의 마지막 커밋 시각 |
 | 마감 뒤 | 고치지 않음 (발표는 마감 시점의 저장소로) |
 | 필수 파일 | `README.md`, `docs/` 세 산출물 + 헌장 + 데일리 3장, `workflows/`, `cases/team.json`, `runs/` |
 | 비밀 검사 | 제출 전 `tscan scan .` (73일차) → 키 · 실제 연락처 0건. 가짜 데이터의 연락처도 **문서 · 로그에서는 가림** |
-| 실행 가능 | 강사가 `README.md`대로 `flow.py push workflows/*.json` → `flow.py test cases/team.json`을 돌려 같은 결과가 나와야 함 |
+| 실행 가능 | 강사가 팀 VM이나 강사 n8n에서 `README.md`대로 `flow.py push workflows/*.json` → `flow.py test cases/team.json`을 돌려 같은 결과가 나와야 함 |
 
 ### 제출 전 점검 (원본 요구 6절과 같음)
 
@@ -46,27 +46,30 @@
 - [ ] 예시 수치를 팀의 실제 측정값으로 교체했다 (`runs/` 보고서에서).
 - [ ] 인증정보와 개인정보가 문서 · 로그 · 저장소에 노출되지 않았다.
 
-## 3. 발표 (82일차 5~6교시, 4팀)
+## 3. 최종 발표 (82일차 6~7교시, 4팀)
+
+80 · 81일차 8교시의 산출물 발표 ① · ②(팀별 10분)는 그날까지의 산출물과 VM 동작을 보이는 중간 발표입니다. 아래는 82일차 최종 발표입니다.
 
 | 항목 | 기준 |
 | --- | --- |
-| 시간 | 팀당 15분 (발표 · 시연) + 질문 5분 |
-| 순서 | 제출 순서의 반대 또는 추첨 (강사 안내) |
-| 시연 기계 | 팀 노트북 한 대, 시작 전 `doctor` `ready` · `fault all ok` · `llm up` |
+| 시간 | 팀당 20분 (산출물 3종 + 시연) + 질의 5분. 6교시 1 · 2팀, 7교시 3 · 4팀 |
+| 순서 | 따로 정해 알림 |
+| 리허설 | 82일차 3교시(1 · 2팀) · 4교시(3 · 4팀), VM에서 시연 순서 그대로 |
+| 시연 기계 | **팀 VM**, 시작 전 `doctor` `ready` · `fault all ok` · `llm up` |
 
-**15분 구성 (권장)**
+**20분 구성 (권장)**
 
 | 분 | 내용 | 산출물 |
 | --- | --- | --- |
-| 2 | 업무 시나리오 · 범위 · 팀 역할 | 설계서 1절, 헌장 |
-| 4 | 흐름도 · 에이전트 역할 · 분기 · 병렬 · 루프 · 페이로드 한 연결선 | 설계서 2~6절 |
-| 3 | RAG: 청킹 비교 숫자 · 임베딩 · 권한 필터 · 재색인 | RAG 설계서 |
-| 4 | 시연: 원본 요구 시연 순서 (정상 → 보완 질문 → 장애 → 이관 · 로그) | 실행 결과서 5절 |
-| 2 | 결과 숫자 · 실패 사례 하나 · 남은 위험 | 실행 결과서 3 · 4절 |
+| 3 | 업무 시나리오 · 범위 · 팀 역할 | 설계서 1절, 헌장 |
+| 5 | 흐름도 · 에이전트 역할 · 분기 · 병렬 · 루프 · 페이로드 한 연결선 | 설계서 2~6절 |
+| 4 | RAG: 청킹 비교 숫자 · 임베딩 · 권한 필터 · 재색인 | RAG 설계서 |
+| 5 | 시연 (팀 VM): 원본 요구 시연 순서 (정상 → 보완 질문 → 장애 → 이관 · 로그) | 실행 결과서 5절 |
+| 3 | 결과 숫자 · 실패 사례 하나 · 남은 위험 | 실행 결과서 3 · 4절 |
 
 ## 4. 평가 시험 (82일차 8교시)
 
-발표 · 총평 뒤 17:00~17:50에 **40문제 평가 시험**을 봅니다. 시연 노트북은 7교시 안에 정리합니다.
+최종 발표 뒤 17:00~17:50에 **25문항 평가 시험**을 봅니다. 통과하지 못한 사람은 따로 **재시험 15문항**을 봅니다. 총평은 시험과 함께 8교시에 합니다.
 
 ## 5. 동료 평가
 

Lecture/80-82-Project/student/09-AGENT-WORKING-RULES.md

@@ -4,7 +4,7 @@
 
 ## 1. 팀 저장소의 `AGENTS.md`
 
-에이전트는 저장소 뿌리의 `AGENTS.md`(claude는 `CLAUDE.md`에 `@AGENTS.md` 한 줄)를 읽습니다. 64~79일차의 `AGENTS.md`를 바탕으로 팀 것을 만듭니다. **첫날 리드가 만들고 팀이 함께 고칩니다.**
+에이전트는 저장소 뿌리의 `AGENTS.md`(claude는 `CLAUDE.md`에 `@AGENTS.md` 한 줄)를 읽습니다. 64~79일차의 `AGENTS.md`를 바탕으로 팀 것을 만듭니다. **첫날 팀장이 만들고 팀이 함께 고칩니다.**
 
 ```markdown
 # AGENTS.md · <팀이름> Tech Support 워크플로우
@@ -50,7 +50,7 @@ workflows/team1-support.json 의 Classify 노드와 Parse class(Code)를 그 표
 | 파일 나누기 | 한 사람 = 한 워크플로우 파일 (04 문서 5절의 하위 워크플로우) |
 | 바꾸기 전 | `git pull` → 내 파일만 에이전트에게 |
 | 바꾼 뒤 | `flow.py check` → `push` → 공통 시나리오 → `git commit` (메시지에 통과 수: "분류 Agent · common 7/14") |
-| 계약을 바꿔야 할 때 | 리드에게 → 설계서 3절을 먼저 고치고 → 그다음 코드 |
+| 계약을 바꿔야 할 때 | 팀장에게 → 설계서 3절을 먼저 고치고 → 그다음 코드 |
 | 다른 사람 n8n에서 확인 | 상대가 `git pull` → `flow.py push workflows/*.json` |
 
 ## 4. 하루짜리 실습과 다른 점

Lecture/80-82-Project/student/10-FAQ-TROUBLESHOOTING.md

@@ -34,7 +34,7 @@ n8n v1 실행 순서는 갈래를 차례로 실행합니다 (66일차). 구조
 
 <details><summary>팀원 노트북마다 결과가 달라요.</summary>
 
-같은 `workflows/*.json`을 push했는지(`git pull`), 데이터 API가 단위 프로젝트 판인지(`doctor`), 고장 스위치가 꺼져 있는지(`fault all ok`), 색인을 다시 만들었는지(In-Memory는 n8n을 다시 켜면 비어 있음)를 봅니다.
+같은 `workflows/*.json`을 push했는지(`git pull`), 데이터 API가 단위 프로젝트 판인지(`doctor`), 고장 스위치가 꺼져 있는지(`fault all ok`), 색인을 다시 만들었는지(In-Memory는 n8n을 다시 켜면 비어 있음)를 봅니다. 노트북에서는 되는데 팀 VM에서만 다르면, VM의 Credential(OpenAI · 웹훅 키 · 데이터 API 키)과 VM에 배포한 커밋이 기본 브랜치의 마지막 커밋인지 봅니다.
 </details>
 
 ## 막혔을 때

Lecture/80-82-Project/student/11-TOPIC-GUIDE.md

@@ -82,7 +82,7 @@ flowchart TD
 | WF-12 | 복합 · 긴급 | 긴급 이관 + 알림 + 근거 + 접수 상태 | "전사 로그인 장애 같아요, 제 건(C-2002)도 확인해 주세요" |
 | WF-13 | 잘못된 입력 | 400 `codes` | (같음) |
 
-- 옮긴 `cases/common.json`은 **80일차 8교시 설계 리뷰에서 강사가 확인**합니다. 판정 칸을 약하게 바꾸지 않았는지(예: `equals`를 지움) 봅니다.
+- 옮긴 `cases/common.json`은 **80일차 5교시 산출물 1차 점검에서 강사가 확인**합니다. 판정 칸을 약하게 바꾸지 않았는지(예: `equals`를 지움) 봅니다.
 - 확인받은 뒤에는 공통 시나리오처럼 **바꾸지 않습니다.**
 
 ## 5. 주제 정하는 순서 (80일차 1~2교시)
@@ -90,8 +90,8 @@ flowchart TD
 | 시각 | 할 일 |
 | --- | --- |
 | 1교시 후반 (15분) | 팀이 후보 2~3개를 고르고, 1절 조건 5가지를 하나씩 확인 |
-| 2교시 처음 (20분) | [주제 제안서](templates/TOPIC-PROPOSAL-TEMPLATE.md) 한 장 → 강사에게 (같은 주제가 겹치면 조정) |
-| 2교시 10:30까지 | 강사 승인 → 팀 헌장 2절 "목표 한 문장"에 주제를 적음 |
+| 2교시 처음 (20분) | [주제 제안서](templates/TOPIC-PROPOSAL-TEMPLATE.md) 한 장 (주제 + 입구 · 뒷단 조합 A · B · C, 7절) → 강사에게 (같은 주제가 겹치면 조정) |
+| 2교시 10:50까지 | 강사 승인 → 팀 헌장 2절 "목표 한 문장"에 주제를 적음 |
 | 3교시 | 범위 정하기 ([03-SCENARIOS-AND-DATA](03-SCENARIOS-AND-DATA.md) 3절), 다른 주제 팀은 데이터 만들기 시작 |
 
 ## 6. 좋은 주제 · 피할 주제
@@ -105,3 +105,25 @@ flowchart TD
 | 3일 안에 데이터 · 문서를 만들 수 있다 | 실제 데이터 · 계정이 꼭 있어야 한다 |
 
 > 주제는 **최종 프로젝트(83일차~)와 따로** 정합니다. 단위 프로젝트에서 해 본 주제를 최종 프로젝트 주제 선호도에 참고로 쓸 수 있습니다.
+
+## 7. 입구 · 뒷단 조합 (A · B · C)
+
+시스템은 세 덩어리입니다: **입구**(문의를 받는 곳) · **두뇌**(n8n 워크플로우) · **뒷단**(티켓 · 알림을 남기는 곳). 두뇌는 모든 팀이 같은 공통 계약으로 만들고, 입구와 뒷단을 무엇으로 붙일지를 팀이 고릅니다. 이 선택이 **조합**입니다. 80일차 2교시에 주제와 함께 정해 주제 제안서 1절에 적고 승인받습니다.
+
+```mermaid
+flowchart LR
+  I["입구<br/>A 팀 웹훅 · B 텔레그램 봇 · C 직원용 웹 화면"] -->|"어댑터 (B · C)<br/>계약 모양으로"| N{{"두뇌 · n8n<br/>공통 계약 (모든 팀 같음)"}}
+  N -->|"어댑터 (B · C)"| O["뒷단<br/>A data-api · B Zammad · C 관리자 화면 + FastAPI"]
+```
+
+| 조합 | 입구 | 뒷단 | 좋은 점 | 더 할 일 |
+| --- | --- | --- | --- | --- |
+| **A 기본형** | 팀 웹훅 (`flow.py`로 호출) | data-api (연습용 가짜 회사) | 준비할 것이 거의 없고 평가 기준 그대로 | 없음 (어댑터 불필요) |
+| **B 메신저 + 헬프데스크형** | 텔레그램 봇 | Zammad 같은 오픈소스 헬프데스크 | 휴대폰으로 실제 회사처럼 시연 | 입구 · 뒷단 어댑터, 봇 · 헬프데스크 준비 |
+| **C 자체 웹앱형** | 직원용 웹 화면 (Next.js) | 관리자 화면 + FastAPI | 우리 서비스처럼 보이고 최종 프로젝트로 이어짐 | 웹 화면 · FastAPI, 계약 변환 |
+
+**어댑터**는 두뇌(n8n)를 바깥 부품(텔레그램 · Zammad · 웹 화면)에 연결하는 노드나 코드입니다. 두뇌는 공통 계약 모양(`request_id` · `user` · `question` → `route` · `answer` · `ticket` …)으로만 주고받으므로, 바깥 부품의 모양을 계약 모양으로 바꾸는 부분이 따로 있어야 합니다. 자세한 연결은 [02-ENVIRONMENT-AND-SERVICES](02-ENVIRONMENT-AND-SERVICES.md) 2절.
+
+- **B · C 팀도 먼저 A로 공통 시나리오를 통과시킨 뒤** 어댑터를 붙입니다. 공통 시나리오(`flow.py test`)는 모든 조합에서 **팀 웹훅으로** 돌리므로, 어댑터를 붙여도 팀 웹훅은 그대로 둡니다.
+- 81일차 4교시에 A 팀은 루프 · 병렬 · 복합 문의만 하고, B · C 팀은 그 시간에 어댑터 작업을 더 합니다.
+- 어댑터가 시연 전까지 되지 않으면 A로 시연합니다. 조합은 평가 기준을 바꾸지 않습니다.

Lecture/80-82-Project/student/templates/DAILY-LOG-TEMPLATE.md

@@ -1,6 +1,6 @@
 # 데일리 기록 · <팀이름> · <80 · 81 · 82>일차
 
-> 하루 끝(8교시)에 `docs/daily/DAY<NN>.md`로. 숫자는 `runs/` 보고서에서.
+> 80 · 81일차는 8교시, 82일차는 5교시 제출 전에 `docs/daily/DAY<NN>.md`로. 숫자는 `runs/` 보고서에서.
 
 ## 1. 오늘의 숫자
 

Lecture/80-82-Project/student/templates/TEAM-CHARTER-TEMPLATE.md

@@ -6,7 +6,7 @@
 
 | 이름 | 역할 (주 담당) | 함께 보는 역할 | 맡는 워크플로우 파일 |
 | --- | --- | --- | --- |
-| | 리드 · 통합 | | `<팀>-support.json` (병합) |
+| | 팀장 (리드 · 통합) | | `<팀>-support.json` (병합) |
 | | 오케스트레이션 | | |
 | | RAG | | `<팀>-index.json`, `<팀>-search.json` |
 | | 연동 · 안정성 | | `<팀>-handoff.json`, `<팀>-errors.json` |
@@ -26,11 +26,12 @@
 
 ## 4. 규칙
 
-- 공통 계약은 리드의 허락 없이 바꾸지 않는다.
+- 공통 계약은 팀장의 허락 없이 바꾸지 않는다.
 - 한 사람 = 한 워크플로우 파일. 남의 파일은 말하고 고친다.
 - 고칠 때마다 공통 시나리오를 다시 돌리고, 커밋 메시지에 통과 수를 쓴다.
 - 키 · 토큰은 Credential에만. 커밋 전 `tscan staged`.
-- 82일차 11:00 동결: 그 뒤로는 시험 · 문서만.
+- 81일차 8교시 기능 동결: 그 뒤로는 시험 · 고치기 · 문서 · 발표 준비만.
+- VM에는 팀장만 배포한다 (기본 브랜치에서, 배포 뒤 공통 시나리오).
 - 막히면 30분 안에 팀에, 1시간이면 강사에게.
 
 ## 5. 저장소 · 연락
@@ -39,7 +40,7 @@
 | --- | --- |
 | 저장소 | |
 | 웹훅 경로 | `<팀>-support` |
-| 시연 노트북 | |
+| 팀 VM | 팀장이 관리 (주소 · 비밀번호는 여기에 쓰지 않음) |
 | 회의 시각 | 매일 1교시 처음 10분 |
 
 ## 6. 바뀐 것

Lecture/80-82-Project/student/templates/TOPIC-PROPOSAL-TEMPLATE.md

@@ -8,6 +8,10 @@
 
 예: "B2B 협업 SaaS 회사의 고객사 관리자를 위한 제품 기술지원 자동화"
 
+**입구 · 뒷단 조합** ([11-TOPIC-GUIDE](../11-TOPIC-GUIDE.md) 7절): ☐ A 기본형 (팀 웹훅 · data-api) ☐ B 메신저 + 헬프데스크형 (텔레그램 · Zammad) ☐ C 자체 웹앱형 (웹 화면 · FastAPI)
+
+B · C를 고르면: 어댑터 담당 · A로 공통 시나리오를 먼저 통과시킬 시각 · 어댑터가 안 될 때 A로 시연한다는 것을 한 줄씩.
+
 ## 2. 큰 틀 조건 (모두 ✔여야 함)
 
 | # | 조건 | 우리 주제에서 | ✔ |
@@ -46,4 +50,5 @@
 - [ ] 조건 5가지
 - [ ] 범위가 3일에 맞음
 - [ ] 다른 팀과 겹치지 않음 (또는 겹쳐도 됨)
+- [ ] 조합 (A · B · C)과 B · C의 어댑터 계획
 - 메모: