최종프로젝트 일일 미팅 및 매니저 가이드 배포
This commit is contained in:
1 parent
8892598525
commit
daa08f2a69
2 files changed
+195
No files matched your search
@@ -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)을 참고해 주세요.
|
||||
@@ -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` 내부에서 관리한다.
|
||||
Reference in new issue
Block a user