diff --git a/Lecture/80-82-Project/AIO-P4-TIMELINE.md b/Lecture/80-82-Project/AIO-P4-TIMELINE.md new file mode 100644 index 0000000..3bb4df1 --- /dev/null +++ b/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일차 점심 시간에 봄 diff --git a/Lecture/80-82-Project/student/00-PROJECT-GUIDE.md b/Lecture/80-82-Project/student/00-PROJECT-GUIDE.md index efa676a..ed45d88 100644 --- a/Lecture/80-82-Project/student/00-PROJECT-GUIDE.md +++ b/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) | 청킹 · 임베딩 · 저장소 · 메타데이터 · 백업 · 확장 | diff --git a/Lecture/80-82-Project/student/01-SCHEDULE-AND-TEAMS.md b/Lecture/80-82-Project/student/01-SCHEDULE-AND-TEAMS.md index 7bf7d60..014d88e 100644 --- a/Lecture/80-82-Project/student/01-SCHEDULE-AND-TEAMS.md +++ b/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문항) | diff --git a/Lecture/80-82-Project/student/02-ENVIRONMENT-AND-SERVICES.md b/Lecture/80-82-Project/student/02-ENVIRONMENT-AND-SERVICES.md index d7b4eaa..d4fd864 100644 --- a/Lecture/80-82-Project/student/02-ENVIRONMENT-AND-SERVICES.md +++ b/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`에만 둡니다 (아래 규칙과 같음). +- 설계서의 "외부 연동 노드" 표 · 연결선 페이로드 표에 어댑터를 **한 연결선**으로 적습니다 (바깥 모양 → 계약 모양). + ### 실제 서비스를 쓰고 싶은 팀 (가산) - 팀 공용 **무료 · 연습용 계정**만 씁니다 (회사 · 개인 업무 계정 금지). diff --git a/Lecture/80-82-Project/student/03-SCENARIOS-AND-DATA.md b/Lecture/80-82-Project/student/03-SCENARIOS-AND-DATA.md index 9812a6d..914fac0 100644 --- a/Lecture/80-82-Project/student/03-SCENARIOS-AND-DATA.md +++ b/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개 이상) diff --git a/Lecture/80-82-Project/student/07-TESTING-GUIDE.md b/Lecture/80-82-Project/student/07-TESTING-GUIDE.md index c9b2676..c2f56d6 100644 --- a/Lecture/80-82-Project/student/07-TESTING-GUIDE.md +++ b/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절 "결과 요약") diff --git a/Lecture/80-82-Project/student/08-SUBMISSION.md b/Lecture/80-82-Project/student/08-SUBMISSION.md index 1683cb1..ca03fac 100644 --- a/Lecture/80-82-Project/student/08-SUBMISSION.md +++ b/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. 동료 평가 diff --git a/Lecture/80-82-Project/student/09-AGENT-WORKING-RULES.md b/Lecture/80-82-Project/student/09-AGENT-WORKING-RULES.md index dbdc6da..002636b 100644 --- a/Lecture/80-82-Project/student/09-AGENT-WORKING-RULES.md +++ b/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. 하루짜리 실습과 다른 점 diff --git a/Lecture/80-82-Project/student/10-FAQ-TROUBLESHOOTING.md b/Lecture/80-82-Project/student/10-FAQ-TROUBLESHOOTING.md index f04f402..54267d6 100644 --- a/Lecture/80-82-Project/student/10-FAQ-TROUBLESHOOTING.md +++ b/Lecture/80-82-Project/student/10-FAQ-TROUBLESHOOTING.md @@ -34,7 +34,7 @@ n8n v1 실행 순서는 갈래를 차례로 실행합니다 (66일차). 구조
팀원 노트북마다 결과가 달라요. -같은 `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에 배포한 커밋이 기본 브랜치의 마지막 커밋인지 봅니다.
## 막혔을 때 diff --git a/Lecture/80-82-Project/student/11-TOPIC-GUIDE.md b/Lecture/80-82-Project/student/11-TOPIC-GUIDE.md index 06720ec..a4a23a9 100644 --- a/Lecture/80-82-Project/student/11-TOPIC-GUIDE.md +++ b/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["입구
A 팀 웹훅 · B 텔레그램 봇 · C 직원용 웹 화면"] -->|"어댑터 (B · C)
계약 모양으로"| N{{"두뇌 · n8n
공통 계약 (모든 팀 같음)"}} + N -->|"어댑터 (B · C)"| O["뒷단
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로 시연합니다. 조합은 평가 기준을 바꾸지 않습니다. diff --git a/Lecture/80-82-Project/student/templates/DAILY-LOG-TEMPLATE.md b/Lecture/80-82-Project/student/templates/DAILY-LOG-TEMPLATE.md index 5622754..1ac3fc5 100644 --- a/Lecture/80-82-Project/student/templates/DAILY-LOG-TEMPLATE.md +++ b/Lecture/80-82-Project/student/templates/DAILY-LOG-TEMPLATE.md @@ -1,6 +1,6 @@ # 데일리 기록 · <팀이름> · <80 · 81 · 82>일차 -> 하루 끝(8교시)에 `docs/daily/DAY.md`로. 숫자는 `runs/` 보고서에서. +> 80 · 81일차는 8교시, 82일차는 5교시 제출 전에 `docs/daily/DAY.md`로. 숫자는 `runs/` 보고서에서. ## 1. 오늘의 숫자 diff --git a/Lecture/80-82-Project/student/templates/TEAM-CHARTER-TEMPLATE.md b/Lecture/80-82-Project/student/templates/TEAM-CHARTER-TEMPLATE.md index 022e85a..bf9e778 100644 --- a/Lecture/80-82-Project/student/templates/TEAM-CHARTER-TEMPLATE.md +++ b/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. 바뀐 것 diff --git a/Lecture/80-82-Project/student/templates/TOPIC-PROPOSAL-TEMPLATE.md b/Lecture/80-82-Project/student/templates/TOPIC-PROPOSAL-TEMPLATE.md index 2b9c15a..9831b42 100644 --- a/Lecture/80-82-Project/student/templates/TOPIC-PROPOSAL-TEMPLATE.md +++ b/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의 어댑터 계획 - 메모: