최종프로젝트 일일 미팅 및 매니저 가이드 배포

This commit is contained in:
mcchae committed 2026-11-12 10:22:50 +09:00
1 parent 8892598525
commit daa08f2a69
2 files changed
+195

No files matched your search

+82
View File
@@ -0,0 +1,82 @@
# 팀 대시보드 작성과 강사 미팅 안내
**팀원은 돌아가며 팀의 진행 상황을 기록하고, 강사와는 결과·막힌 점·오늘의 실행 계획을 이야기합니다.** 아래 대시보드 작성은 매니저 가이드 기준, 미팅 질문은 강사와 함께 확인할 내용입니다.
## 1. 팀 대시보드는 이렇게 작성해 주세요
### 처음 시작할 때와 팀 정보가 바뀔 때
- `0팀(작성예시)`을 먼저 읽고 자기 팀 입력칸을 작성해 주세요.
- **팀 정보:** 팀명·프로젝트 주제·세부 주제·기술 스택·멘토·GitHub·협업툴·팀 드라이브를 입력해 주세요.
- **팀원 및 역할:** 이름·팀장/팀원·담당 업무·GitHub ID를 정확히 적어 주세요. 이 이름이 일지 작성자 선택과 작성 횟수 집계에 사용됩니다.
- 팀의 소통·협업 약속인 **그라운드 룰**을 함께 정해 주세요. 팀장은 일정·제출·지원 요청을 운영 매니저와 연결합니다.
### 한 주의 작성 순서
| 언제 | 무엇을 하나요? |
|---|---|
| 월요일 | 이번 주 마감 산출물을 확인하고 **목표·완료 기준·요일별 계획·담당자**를 적습니다. |
| 매일 수업 종료 전 | 오늘 날짜 행에 **진행 단계·오늘 진행 내용·작성자**를 입력합니다. |
| 다음 날 아침 | 강사 피드백을 읽고 **피드백 확인**에 체크합니다. 반영한 내용은 다음 일지에 남깁니다. |
| 금요일 | **잘한 점·아쉬운 점·개선할 점·다음 주 작업·지원 요청**을 주간 회고에 적습니다. |
### 일지는 돌아가며, 팀 전체의 결과를 적어 주세요
팀에서 순번을 정하고 **팀원 각자 주 1회 이상** 작성해 주세요. `이번 주 작성` 횟수를 확인해 빠진 사람이 없도록 합니다. 작성자는 다른 팀원의 결과도 모아 적고, 팀원들은 자기 작업 내용과 링크를 전달해 주세요.
인원수·휴강 등으로 순번 운영이 어려우면 강사·매니저에게 작성 방법을 확인해 주세요. 작성 횟수를 맞추려고 임의로 행을 늘리거나 작성자 이름을 다르게 적지 마세요.
아래 세 가지면 됩니다. 이슈가 없으면 이슈 항목은 생략해도 됩니다.
```text
[한 일]
- 실제로 끝낸 작업·결정한 내용과 확인할 링크
[이슈]
- 막힌 점·시도한 방법·필요한 도움
[내일]
- 누가 무엇을 어디까지 할지
```
“회의함·개발 중” 대신 “상담 조회 화면 초안 작성, 예약 기능은 다음 작업”처럼 적어 주세요. 문서·PR·화면·테스트 결과로 확인할 수 있으면 좋습니다. 아직 하지 않은 일을 완료라고 쓰지 마세요.
### 산출물 제출과 보완은 일지와 별도로 처리해 주세요
1. 팀 Drive 또는 GitHub에 산출물을 올리고, **강사·매니저가 열 수 있는 공유 권한**을 확인합니다.
2. 산출물 제출 표에 링크를 넣고 상태를 **제출완료**로 바꿉니다. 작업 중에는 **작성중**으로 표시하고 초안 링크를 미리 공유해도 됩니다.
3. 강사의 **1차 의견·보완요청**을 확인해 수정합니다.
4. 수정본과 **최종 수정일**을 반영하고 **보완완료**로 바꿉니다. 이후 강사가 **2차 의견**을 남깁니다.
일지의 피드백 확인 체크, 산출물 보완완료, 매니저 제출 확인은 서로 다릅니다. 읽었다고 수정까지 끝난 것은 아니며, 강사 의견과 매니저 확인칸은 직접 작성하지 마세요. 마감 변경이 필요하면 강사·매니저와 상의해 주세요.
## 2. 강사가 팀에 오기 전에 다섯 가지를 준비해 주세요
팀장만 이야기하지 말고 **해당 작업을 맡은 팀원도 직접 설명**해 주세요. 문서·코드·화면·로그를 열어 두고, 아래 질문에 짧게 답할 준비를 하면 됩니다. 별도 문서를 매일 새로 만들 필요는 없고 팀 메모나 일지를 활용해도 됩니다.
- [ ] **어제 하기로 한 일 중 실제로 끝난 것은 무엇이고 어디에서 볼 수 있나요?**
- 답변·결과 링크:
- [ ] **지금 가장 막힌 것은 무엇이며, 어떤 방법을 시험했나요?**
- 막힌 점·시도 결과·필요한 도움:
- [ ] **다음 산출물 마감까지 꼭 끝낼 기능과 나중으로 미룰 기능은 무엇인가요?**
- 이번 마감까지 할 것 / 이후로 미룰 것:
- [ ] **누구의 작업을 기다리고 있고, 주고받을 입력·출력은 합의했나요?**
- 협업 상대·의존 작업·입출력 합의 여부:
- [ ] **오늘 누가 무엇을 어디까지 하고, 무엇을 보여 주면 완료라고 볼까요?**
- 담당자·오늘 작업·완료 기준:
미팅이 끝나면 **다음 행동·담당자·완료 기준·다시 확인할 시점**을 팀이 함께 확인해 주세요. 합의한 내용을 일지와 필요한 기획서·WBS에 반영하고, 다음 미팅에서 실제 결과를 보여 주세요.
## 3. 멘토링과 대시보드 사용 시 기억할 것
- 팀장이 멘토와 일정을 정해 **Discord 팀 채널**에 공유하고, 질문·자료를 미리 올려 주세요. 멘토 피드백의 반영 내용도 일지에 남겨 주세요.
- 멘토링은 팀당 온·오프라인 합산 최대 20시간이며, 인정 온라인 시간은 오프라인 시간을 넘을 수 없습니다. 시작·종료 때 날짜·시간이 보이는 사진이나 화면 캡처를 남기고, 개인 멘토링은 사람별로 증빙해 주세요.
- 주요 소통·지원 요청은 매니저가 확인할 수 있는 Discord에서 진행해 주세요. 개인정보가 담긴 문서는 공개 채널에 올리지 말고 개별 전달합니다. 교육 범위 밖 기술이 필요하면 강사·매니저와 먼저 상의해 주세요.
- **자기 팀 노란 입력칸만** 작성해 주세요. 회색 자동 계산칸·파란 강사 의견칸·다른 팀 시트는 수정하지 않습니다. 행을 추가·삭제하거나 순서를 바꾸지 마세요.
- 회색 날짜 행은 수업이 없는 날, 초록은 오늘·이번 주, 빨간 칸은 미작성 등 확인이 필요한 표시입니다. 경고가 뜨면 수정할 입력칸이 맞는지 먼저 확인해 주세요.
세부 운영 기준은 [매니저 공통 가이드](MANAGER-GUIDE.md), 강사와의 순회 진행 방식은 [강사 일일 지도 운영안](INSTRUCTOR-DAILY-GUIDE.md)을 참고해 주세요.
+113
View File
@@ -0,0 +1,113 @@
# 최종 프로젝트 매니저 공통 가이드
> 원문 확인: 2026-11-11 / 문서 정리: 2026-11-12.
>
> 이 문서는 매니저의 프로젝트 가이드와 대시보드 사용 규칙을 정리한다. 날짜별 팀 진행·제출 상태·강사 피드백·팀별 코칭 예시는 일차별 DONE 문서로 분리한다. Notion 원문을 이번 작업에서 다시 조회한 것은 아니다.
## 0. 기준 자료와 문서 구분
| 자료 | 용도 | 원문 |
|---|---|---|
| AIO 1기 최종 프로젝트 가이드 | 수행 단계·산출물·평가·협업·멘토링 | [Notion 프로젝트 가이드](https://app.notion.com/p/playdatacademy/AIO-1-408d943bcac28056b330c79bee04b3f2) |
| AIO 1기 프로젝트 대시보드 사용법 | 역할별 입력·제출·피드백·보완 규칙 | [Notion 대시보드 사용법](https://app.notion.com/p/playdatacademy/AIO-1-408d943bcac280189f96f5842fad9159) |
| AIO 1기 최종 대시보드 | 실제 일정·팀 정보·산출물·일일 기록의 운영 위치 | [Google Sheets](https://docs.google.com/spreadsheets/d/1RFsH16KL2Fxsciq0NaXLmYzVnqb2alsl81sthWRUA8U/edit) |
공통 수행·평가 기준은 매니저 가이드에서 확인하고, 실제 팀 편성·주제·마감은 대시보드에서 확인한다. 원문의 팀 번호별 예시를 실제 팀 주제로 그대로 대입하지 않는다. 불일치·변경은 매니저와 협의한다.
강사의 순회 질문·피드백 템플릿 등 별도 운영 제안은 [강사 일일 지도 운영안](INSTRUCTOR-DAILY-GUIDE.md)에서 관리한다. 해당 제안을 매니저의 추가 의무나 평가 배점으로 해석하지 않는다.
## 1. 자료 ① — 최종 프로젝트 가이드
출처: [프로젝트 가이드](https://app.notion.com/p/playdatacademy/AIO-1-408d943bcac28056b330c79bee04b3f2)의 프로젝트 개요·멘토링·단계별 가이드·발표 평가 항목.
### 1.1 프로젝트를 이끄는 원칙
- 프로젝트 리드·종합 관리·평가는 강사가 담당하고, 멘토는 동일 방향에서 산출물 완성을 지원한다.
- 교육에서 배운 기술 범위를 기준으로 지도한다. 범위 밖 기술이 필요하면 강사·매니저와 먼저 협의한다.
- 시작 시 소통·행동·약속에 관한 실천 가능한 팀 그라운드 룰을 만든다. 팀장은 일정·제출·지원 요청의 운영 창구다.
- 아래 필수 산출물 외의 추가 산출물은 운영 매니저와 소통해 진행한다.
### 1.2 단계별 수행과 필수 산출물
| 단계 | 공통 수행 방향 | 주요 산출물 |
|---|---|---|
| STEP 1 기획·설계 | 문제·요구사항·범위·구조·스택·일정 정의 | 기획서(요구사항 명세 포함), WBS |
| STEP 2 API·Function Calling | 비동기 API·입력 검증·저장·인증·함수 호출·협업 개발 | API 설계 문서, DB 스키마 설계서 |
| STEP 3 단일 에이전트 | LangGraph 상태 전이·도구·메모리·자기 성찰·종료 조건 | 상태 전이 그래프 설계서, 자기 성찰 로직 테스트 결과서 |
| STEP 4 협업·Auto-Healing | 역할·인계·상태 공유·보안·장애 감지·자동 복구 | 협업 아키텍처 설계서, AI 보안 가드레일 설계 문서, Auto-Healing 구현 결과서 |
| STEP 5 최적화·배포 | 스트리밍 UI·처리 흐름 가시화·사용자 피드백·클라우드 배포·E2E | 대화형 AI 웹 앱, 통합 테스트 결과서, 배포 아키텍처 설계도 |
평가는 문서 존재만이 아니라 설계·구현·검증의 연결을 본다. 특히 협업 예외 처리, 보안 통제, 복구 시연과 수치·로그, 배포 안정성·확장성, E2E와 결함 재검증이 포함된다.
### 1.3 발표 평가
중간·최종 모두 기획·구현·기술·발표역량을 본다. 중간에는 현실적인 계획과 핵심 기능 1개 이상의 안정적인 시연, 최종에는 전체 통합·예외 대응·운영 자동화·사용자 피드백 반영·한계와 개인 기여 설명이 중요하다. 원문에 없는 배점·발표 시간을 임의로 추가하지 않는다.
### 1.4 멘토링·협업 운영
- 팀당 온·오프라인 합산 최대 20시간이며 오프라인을 권장한다. 인정 온라인 시간은 오프라인 시간을 초과할 수 없다.
- 시작·종료마다 날짜·시간이 보이는 사진 또는 화면을 남긴다. 개인 멘토링은 사람별 증빙이 필요하다.
- 팀장이 일정 협의 후 Discord 팀 채널에 공유하고, 질문·자료를 미리 올린다. 반영 내용은 일일 기록에 남긴다.
- 주요 소통은 매니저가 확인 가능한 Discord에서 진행한다. 개인정보 문서는 공개 채널 대신 개별 전달한다.
- 문제는 매니저에게 공유한다. 리워드는 최종 1등 팀 100만 원, 팀장 우선 지급 예정으로 안내되어 있다.
## 2. 자료 ② — 프로젝트 대시보드 사용법
출처: [대시보드 사용법](https://app.notion.com/p/playdatacademy/AIO-1-408d943bcac280189f96f5842fad9159)의 수강생·강사·운영 매니저 항목.
### 2.1 작성 주체와 구조
| 구분 | 역할 |
|---|---|
| 수강생·팀 | 자기 팀의 노란 입력칸: 정보·역할·계획·일일 기록·제출 링크·팀 상태 |
| 강사 | 파란 의견칸: 일일 피드백·산출물 1·2차 의견. 보완이 필요하면 보완요청 상태 지정 |
| 매니저 | 일정·수업일·클라우드 비고·지원 요청·제출 확인 관리 |
| 자동 영역 | 회색 계산칸. 행 추가·삭제·순서 변경도 피해야 연결이 유지됨 |
잠금 표시는 수정 경고 장치이며 자동 계산칸을 고쳐도 된다는 뜻이 아니다. 주제·이름 오류는 통합 표시값 대신 팀 정보·역할의 원본 입력을 확인한다.
### 2.2 주간·일일 작성 주기
| 시점 | 수강생 | 강사·매니저 |
|---|---|---|
| 첫날 | 팀 정보·주제·멤버·역할 등록, 작성 예시 확인 | 구성·일정 확인 |
| 월요일 | 목표·완료 기준·요일별 계획·담당 작성 | 이번 주 마감과 계획 정합성 확인 |
| 매일 종료 전 | 단계·진행 내용·작성자 기록. 결과·이슈·다음 행동 중심 | 필요한 날 일일 피드백, 기록 누락 확인 |
| 다음 날 | 피드백 읽고 확인 체크 | 미확인 건 후속 확인 |
| 금요일 | 잘한 점·아쉬운 점·개선·다음 주·지원 요청 회고 | 방향 코멘트·지원 처리 |
팀원은 각자 주 1회 이상 일일 기록을 작성한다. 피드백은 모든 행에 의무적으로 쓰기보다 이슈·방향 조정에 집중하며, 잘한 점과 실행 가능한 개선을 짧게 제시한다.
### 2.3 제출·보완 흐름
팀은 공유 가능한 Drive/GitHub 링크를 등록해 제출완료로 전환한다. 강사는 링크를 열고 1차 의견을 남긴다. 보완요청 후 팀이 수정본·최종 수정일·보완완료를 반영하면 강사가 2차 의견을 작성한다. 매니저 제출 확인은 별도다.
상태는 **미착수 → 작성중 → 제출완료 → 보완요청 → 보완완료**로 구분한다. 뒤의 두 상태는 보완이 필요한 경우에 사용한다. 일일 피드백 확인 체크가 산출물 보완 완료를 대신하지 않는다.
일정 변경은 매니저와 협의하며 연동된 통합 일정을 기준으로 반영한다. 다른 팀 시트나 자동 계산·행 구조는 임의로 바꾸지 않는다.
## 3. 대시보드 확인 위치
아래는 필드 탐색을 위한 참고 구조다. 행·열이 바뀌었을 수 있으므로 항상 실제 헤더와 날짜를 먼저 확인한다. 특정 날짜의 상태값은 이 문서에 누적하지 않는다.
| 확인 목적 | 필드·위치 |
|---|---|
| 전체 우선순위 | 통합 대시보드의 팀별 진행 요약·산출물 일정 |
| 산출물 검토 | 각 팀 산출물 제출 표의 링크·최종 수정일·강사 1차/2차 의견·매니저 확인 |
| 주간 계획 | 주차별 목표·세부 계획·이번 주 마감 |
| 일일 수행 | 해당 날짜의 진행 단계·오늘 진행 내용·작성자 |
| 일일 강사 피드백 | 해당 날짜의 강사 피드백과 피드백 확인 체크 |
| 지원·회고 | 주간 회고·지원 요청 |
현재 구조의 산출물 의견은 L~M열(1차), N~O열(2차), 매니저 확인은 P열이다. 일일 기록은 E열의 날짜를 찾아 G~I열의 수행 내용, J~K열의 작성자, L~M열의 강사 피드백, N열의 확인 체크를 함께 읽는다. 이 위치 정보가 실제 헤더보다 우선하지 않는다.
## 4. 날짜별 기록과 유지 원칙
| 기록 | 별도 문서 |
|---|---|
| 83일차·최종 프로젝트 첫날, 2026-11-10 | [83/DONE-83.md](83/DONE-83.md) |
| 84일차·2026-11-11 | [84/DONE-84.md](84/DONE-84.md) |
이후에도 해당 일차의 DONE 문서에 실제 진행·기존 강사 피드백·미해결 사항을 기록한다. 현재 팀 정보나 현재 제출 상태를 과거 날짜의 사실로 소급하지 않는다. 피드백 확인 체크와 실제 반영 완료도 구분한다.
원본 Notion·대시보드는 별도 명시적 요청 없이 Codex가 수정하지 않는다. 날짜별 피드백은 강사가 대시보드에 작성한 내용을 근거로 정리한다. 최종 프로젝트 120일차 종료까지 로컬 작업·기록은 `Lecture/FinalProject` 내부에서 관리한다.