aio-01d4-stu/Lecture/80-82-Project/student/11-TOPIC-GUIDE.md

주제 정하기 · 큰 틀 안에서 팀 주제를 고른다

단위 프로젝트의 큰 틀은 하나입니다.

노코드·로코드 기반 기업형 '지능형 기술 지원 자동화(Tech Support)' 워크플로우 구축

이 틀 안에서 팀마다 주제(어느 회사의, 누구를 위한, 어떤 기술 지원인가)를 정합니다. 만드는 방식(공통 계약 · 세 산출물 · 평가 기준)은 모든 팀이 같고, 업무 영역 · 지식 문서 · 문의 유형 · 데이터가 팀마다 다릅니다.

flowchart TD
  F["큰 틀 (모든 팀 같음)<br/>기업형 지능형 기술 지원 자동화"] --> C["같은 것<br/>공통 계약 · 시나리오 14유형 · 세 산출물 · 평가 기준 · 환경"]
  F --> T["팀이 정하는 것<br/>업무 영역 · 사용자 · 지식 문서 · 문의 유형 · 이관 대상 · 권한 · 긴급 기준"]
  T --> D["기본 주제: 사내 IT 헬프데스크<br/>데이터가 다 준비됨 (03 문서)"]
  T --> O["다른 주제<br/>지식 문서 · 사용자 · 접수 데이터를 팀이 만듦"]

1. 주제가 큰 틀에 들어오는지 (조건 5가지)

아래 다섯을 모두 만족해야 합니다. 하나라도 빠지면 평가 기준(RAG · 연동 · 예외 처리)을 채울 수 없습니다.

#	조건	왜	안 되는 예
1	기업의 기술 지원 업무다 (사내 직원 대상이든 기업 고객 대상이든)	큰 틀 "기업형 기술 지원"	맛집 추천, 여행 일정, 개인 공부 도우미
2	지식 문서로 답할 수 있는 문의가 있다 (매뉴얼 · FAQ · 정책 · 장애 이력)	RAG 아키텍처 설계서	답이 늘 실시간 계산뿐인 업무
3	사람에게 넘겨야 하는 경우가 있다 (티켓 · 담당자 배정)	이관 · 티켓 생성 · 알림 (Jira · Slack 역할)	모든 답을 자동으로 끝내는 업무
4	권한 · 개인정보 문제가 하나 이상 있다 (남의 건 · 관리자 문서 · 연락처)	보안 · 권한 시나리오 (WF-05~07)	모두가 모든 것을 봐도 되는 업무
5	외부 시스템이 멈출 수 있다 (접수 시스템 · 재고 · 설비 API)	예외 처리 시나리오 (WF-04 · 10 · 11)	외부 연동이 하나도 없는 업무

2. 주제 예 (고르거나 바꿔 써도 됨)

주제	사용자	지식 문서 예	문의 유형 예	이관 · 티켓	권한 · 개인정보	긴급 · 외부 장애
사내 IT 헬프데스크 (기본)	사내 직원	데이터 API 규정 8개 (+ 관리자 문서)	계정 · VPN · 메일 · 장비 · 소프트웨어 · 보안 사고	IT팀 티켓	남의 접수 건, 관리자 문서, 연락처	피싱 · 감염 의심, 접수 시스템 장애
B2B SaaS 고객 기술지원	고객사 관리자 · 사용자	제품 매뉴얼, 릴리스 노트, 알려진 문제	설정 · 연동 오류 · 권한 · 요금제 기능	2차 기술지원 · 버그 티켓	다른 고객사의 데이터, 고객사 관리자 전용 설정	서비스 장애 공지, 상태 API 장애
개발자 플랫폼 · API 기술지원	외부 개발자	API 문서, 오류 코드표, 한도 · 인증 가이드	인증 실패 · 429 · 웹훅 · SDK 오류	플랫폼팀 티켓	API 키 노출(답 · 로그에서 가림), 다른 계정의 사용량	전면 장애, 상태 페이지 API 장애
제조 설비 유지보수 지원	현장 작업자 · 설비 담당	설비 매뉴얼, 오류 코드, 안전 수칙, 정비 이력	오류 코드 · 부품 교체 · 점검 주기	정비 기사 배정 티켓	다른 공장 설비 정보, 안전 관련은 자동 답변 금지	안전 사고 = 긴급, 설비 데이터 API 장애
통신 · 네트워크 장애 접수	기업 회선 고객	장애 대응 절차, 장비 설정 가이드, 장애 이력	회선 끊김 · 속도 · 장비 재시작 · 공지	현장 출동 · NOC 티켓	다른 고객 회선 정보, 고객 연락처	광역 장애, 회선 조회 API 장애
사내 보안 문의 · 사고 접수	사내 직원	보안 규정, 사고 대응 절차, 신고 FAQ	피싱 신고 · 계정 잠금 · 기기 분실 · 정책 문의	보안팀 티켓	신고자 정보 · 사고 상세는 보안팀만	감염 · 유출 = 긴급, 탐지 시스템 장애
전자제품 A/S 기술지원	일반 고객 (기업의 고객 센터)	제품 설명서, 자가 진단 가이드, 보증 정책	증상 진단 · 보증 기간 · 수리 접수	수리 접수 · 방문 기사 배정	다른 고객의 수리 이력, 주소 · 연락처	발화 · 감전 = 긴급, 수리 접수 API 장애
사내 업무 시스템(ERP · 그룹웨어) 지원	사내 직원	사용 매뉴얼, 권한 신청 절차, 마감 일정	화면 오류 · 권한 신청 · 결재 · 마감	시스템 운영팀 티켓	다른 부서 데이터, 결재 권한	월말 마감 중 장애 = 긴급, ERP API 장애

• 같은 주제를 두 팀이 고를 수 있는지는 강사가 첫날 정합니다 (기본은 팀마다 다른 주제, 기본 주제는 여러 팀이 골라도 됨).
• 의료 · 금융처럼 규제가 큰 분야는 가짜 데이터로만, 진단 · 투자 같은 판단은 자동 답변하지 않고 이관하는 설계를 권합니다.

3. 기본 주제와 다른 주제의 차이 (해야 할 일의 양)

할 일	기본 주제 (사내 IT 헬프데스크)	다른 주제
지식 문서	데이터 API /docs 8개 그대로 (+ 팀이 더해도 됨)	팀이 6개 이상 씀 (knowledge/, 문서마다 ## 절 3개 이상)
사용자 · 권한 데이터	데이터 API 직원 6명	팀이 data/users.json에 5명 이상 (권한이 다른 사람 포함)
접수 · 업무 데이터	데이터 API 접수 건 T-1001~T-1004	팀이 data/records.json에 4건 이상 (사람마다 주인이 다르게, 연락처 포함)
티켓 · 알림 · DLQ · 고장 스위치	데이터 API 그대로	같음 (데이터 API 그대로)
공통 시나리오	키트 cases/common.json 그대로	같은 14유형을 우리 주제의 질문으로 팀 저장소 cases/common.json에 (4절)
평가	같은 기준	같은 기준 (주제가 어렵다고 가산 · 감점하지 않음)

다른 주제를 고르면 첫날 **데이터를 만드는 시간(약 2교시)**이 더 듭니다. 3일 안에 끝낼 자신이 없으면 기본 주제를 고르고, 범위 · 팀 시나리오 · 가산으로 차이를 내는 것도 좋은 선택입니다.

다른 주제의 데이터 만들기

• 가짜 데이터만 씁니다. 실제 회사 · 고객 · 직원 정보, 실제 연락처를 쓰지 않습니다 (연락처는 010-0000-xxxx, @example.com).
• 지식 문서는 팀이 직접 씁니다. 실제 회사의 매뉴얼을 그대로 복사하지 않습니다 (저작권). 공개 라이선스 문서를 쓴다면 출처와 라이선스를 RAG 설계서 1절에 적습니다.
• LLM으로 초안을 만들어도 되지만, 사람이 읽고 고칩니다. 서로 모순되는 문서, 근거가 없는 숫자가 섞이면 RAG 시험이 흔들립니다.
• 사용자 · 접수 데이터는 실습 키트의 데이터 API 단위 프로젝트 판이 팀 데이터 폴더를 읽게 해 둡니다 (키트 안내 참고). 접수 조회의 "남의 건이면 403"도 같은 규칙으로 동작합니다.

4. 공통 시나리오 14유형을 우리 주제로 옮기기

공통 시나리오(03-SCENARIOS-AND-DATA 4절)는 유형 · 조건 · 판정 칸이 모든 팀 같고, 다른 주제의 팀은 질문만 자기 주제로 바꿉니다. ID는 그대로 씁니다.

ID	유형 (바꾸지 않음)	판정 (바꾸지 않음)	예: B2B SaaS 고객 기술지원으로 옮기면
WF-01	정상 문의	자동 답변, sources에 기대 문서	"SSO 연동 후 로그인이 반복돼요" → sso-setup 문서
WF-02 · 02b	정보 부족 · 한도	보완 질문 → 3회째 담당자 이관	"연동이 안 돼요"
WF-03	지식에 없음	담당자 이관, ticket, sources 빈 목록	매뉴얼에 없는 기능 문의
WF-04	티켓 API 장애	200 · 담당자 이관 · ticket: null · DLQ · 알림	(조건 같음)
WF-05	권한 없는 문서	그 문서를 근거로 쓰지 않음	일반 사용자가 고객사 관리자 전용 설정 문의
WF-06	남의 건	권한 없음	다른 고객사의 접수 건 번호
WF-07	개인정보	가려짐, masked ≥ 1	내 접수 건의 담당자 연락처
WF-08	주입	차단	(같음)
WF-09	중복 요청	티켓 1건	(조건 같음)
WF-10	LLM 멈춤	500 아님	(조건 같음)
WF-11	느린 외부 API	정해진 시간 안	(조건 같음)
WF-12	복합 · 긴급	긴급 이관 + 알림 + 근거 + 접수 상태	"전사 로그인 장애 같아요, 제 건(C-2002)도 확인해 주세요"
WF-13	잘못된 입력	400 codes	(같음)

• 옮긴 cases/common.json은 80일차 5교시 산출물 1차 점검에서 강사가 확인합니다. 판정 칸을 약하게 바꾸지 않았는지(예: equals를 지움) 봅니다.
• 확인받은 뒤에는 공통 시나리오처럼 바꾸지 않습니다.

5. 주제 정하는 순서 (80일차 1~2교시)

시각	할 일
1교시 후반 (15분)	팀이 후보 2~3개를 고르고, 1절 조건 5가지를 하나씩 확인
2교시 처음 (20분)	주제 제안서 한 장 (주제 + 입구 · 뒷단 조합 A · B · C, 7절) → 강사에게 (같은 주제가 겹치면 조정)
2교시 10:50까지	강사 승인 → 팀 헌장 2절 "목표 한 문장"에 주제를 적음
3교시	범위 정하기 (03-SCENARIOS-AND-DATA 3절), 다른 주제 팀은 데이터 만들기 시작

6. 좋은 주제 · 피할 주제

좋은 주제	피할 주제
문의 유형을 4~6개로 말할 수 있다	"모든 고객 문의"처럼 끝이 없다
지식 문서가 서로 다른 절차를 담고 있어 검색이 의미 있다	문서 하나로 다 답이 된다 (RAG가 필요 없음)
자동 답변하면 안 되는 경우를 분명히 말할 수 있다 (안전 · 보안 · 돈)	무엇이든 자동으로 답해도 된다
팀원이 그 업무를 상상할 수 있다 (경험 · 관심)	팀 누구도 업무를 모른다
3일 안에 데이터 · 문서를 만들 수 있다	실제 데이터 · 계정이 꼭 있어야 한다

주제는 최종 프로젝트(83일차~)와 따로 정합니다. 단위 프로젝트에서 해 본 주제를 최종 프로젝트 주제 선호도에 참고로 쓸 수 있습니다.

7. 입구 · 뒷단 조합 (A · B · C)

시스템은 세 덩어리입니다: 입구(문의를 받는 곳) · 두뇌(n8n 워크플로우) · 뒷단(티켓 · 알림을 남기는 곳). 두뇌는 모든 팀이 같은 공통 계약으로 만들고, 입구와 뒷단을 무엇으로 붙일지를 팀이 고릅니다. 이 선택이 조합입니다. 80일차 2교시에 주제와 함께 정해 주제 제안서 1절에 적고 승인받습니다.

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 2절.

• B · C 팀도 먼저 A로 공통 시나리오를 통과시킨 뒤 어댑터를 붙입니다. 공통 시나리오(flow.py test)는 모든 조합에서 팀 웹훅으로 돌리므로, 어댑터를 붙여도 팀 웹훅은 그대로 둡니다.
• 81일차 4교시에 A 팀은 루프 · 병렬 · 복합 문의만 하고, B · C 팀은 그 시간에 어댑터 작업을 더 합니다.
• 어댑터가 시연 전까지 되지 않으면 A로 시연합니다. 조합은 평가 기준을 바꾸지 않습니다.