Lecture/FinalProject/MANAGER-GUIDE.md

# 최종 프로젝트 매니저 공통 가이드

> 원문 확인: 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` 내부에서 관리한다.
최종프로젝트 일일 미팅 및 매니저 가이드 배포 2026-11-12 10:22:50 +09:00			`# 최종 프로젝트 매니저 공통 가이드`

			`> 원문 확인: 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` 내부에서 관리한다.