개요
•
노션 프로젝트 관리 시스템 3회차 세션 영상
•
기존 구글 시트 기반 생산 현황 관리 시스템의 노션 전환 설계
•
리오더(재생산), 리스프레드(재확산), 매입처 평가 시스템 추가 설계
•
AI 오케스트레이션 시스템 실무 활용 가능성 시연 및 업무 자동화 방향성 제시
•
핵심 원칙: 목적에 맞는 데이터 구조 재정의를 통한 실질 비즈니스 가치 집중
•
리스프레드: 매체별 조회수 트래킹 구조에서 매출 기반 분석 구조로 전환
•
매입처 평가: 월별 평가를 위한 Monthly Report 중간 DB 도입으로 시간 기반 집계 구조 설계
주요 학습 포인트
•
AI 오케스트레이션 실무 활용: 스킬 호출을 통한 마크다운 계층 구조 자동 변환 및 데이터 자동 입력
•
리오더 전용 DB 필요성: 기존 프로젝트 태스크 DB와 분리된 재생산 전용 구조 설계
•
리스프레드 목적 재정의: 조회수 중심이 아닌 매출 중심의 성과 판단 구조 설계
•
월간 리포트용 중간 DB 설계: Item → Monthly Report → Supply 3계층 관계형 구조 설계
•
범용 스프린트 템플릿 설계 원칙: 다양한 부서 프로세스를 수용하는 표준 워크플로우 구조 설계
요약
1. AI 오케스트레이션 시스템 실무 시연
•
스킬 기반 마크다운 계층 구조 정리
◦
클로드에서 작성한 마크다운 파일의 계층 구조 깨짐 이슈
◦
기존 수동 방식: 사람 손으로 마이너스(-) 입력 및 들여쓰기 조정 반복
◦
스킬 호출 시 약 5분 내 자동 계층 구조 정리
•
스킬 동작 원리
◦
지침 파일에 문장 설계 규칙 및 변환 규칙 사전 정의
◦
입력 마크다운의 헤더를 1, 2, 3 레벨 기준으로 자동 변환
◦
자가 점검 로직 내장으로 오류 발생 시 자동 재시도 구조
•
실무 적용 시나리오
◦
강의 커리큘럼 자동 입력: 파트 → 챕터 → 클립 3단계 계층 구조 자동 생성
◦
OKR 입력 자동화: 계층 구조 명확성 확보 후 타이핑 기반 전체 데이터 자동 입력 구조
◦
회의 내용 기반 태스크 자동 생성: 멤버 DB 연동을 통한 담당자 자동 멘션 구조
•
스킬 수정 사례: 저해상도 이미지 처리
◦
커리큘럼 이미지 해상도 저하로 인한 할루시네이션 발생 이슈
◦
스킬 정의에 저해상도 이미지 처리 로직 추가
◦
수정 이후 동일 워크플로우에서 정상 데이터 입력 완료
•
핵심 인식 전환
◦
AI를 인공 지능이 아닌 외계 지능(Alien Intelligence)으로 바라보는 관점
◦
사람이 직접 통제 가능한 지능 범위를 넘어선 보조자 전제
2. 생산 현황 관리: 구글 시트에서 노션으로 전환
•
현재 생산팀 작업 방식
◦
구글 시트 기반 생산 현황 입력 및 진행 상황 트래킹
◦
아이템별 원단 투입, QC, 그레이딩 등 프로젝트 태스크를 시트 단위로 관리
◦
복종(티셔츠, 바지 등)별 시트 분리 후 신상품 등록 및 진행 관리
•
기존 시트 구조의 한계
◦
입고 스케줄이 구조화된 데이터가 아닌 수동 입력 텍스트
◦
생산 담당자의 지속적인 수동 입력 의존 구조
◦
피벗 테이블로 자동 산출되어야 할 데이터를 사람이 직접 작성하는 구조
•
노션 전환 방향성
◦
프로젝트 전체가 아닌 생산 관련 태스크만 별도 추출하여 구조 재설계
◦
메인 원단 투입부터 수납 확정까지 구간 분리 및 단계별 트래킹 구조 설계
◦
담당자 지정 및 개인 페이지 연동을 통한 책임 범위 명확화
◦
서브 아이템 단위 세분화 대신 아이템 단위 트래킹으로 복잡도 축소
3. 리오더(재생산) 시스템 설계
•
리오더 특성 정리
◦
첫 생산 이후 판매 추이가 좋은 아이템의 추가 생산 이벤트
◦
다품종 소량 생산 특성으로 옵션(색상, 사이즈)별 리오더 발생 구조
◦
색상·사이즈 묶음 단위 리오더 진행 및 아이템 단위 "리오더 진행 여부" 트래킹 필요
•
리오더 트리거
◦
디자이너의 판매 데이터 추이 모니터링 기반 리오더 의사 결정
◦
다음 주 신규 출시 상품과의 경쟁력 비교를 통한 우선순위 판단
◦
확정된 리오더 리스트의 생산 부서 전달 프로세스
•
필요 데이터베이스 구조
◦
기존 프로젝트 태스크 DB는 전체 생산 공정용 DB이므로 리오더 전용으로 사용 부적합
◦
신규 필요 DB 구조
▪
리오더 DB: 아이템과의 관계형 연결 및 리오더 단위 관리용 DB
▪
리오더 태스크 DB: 리오더 실행 단계별 태스크 관리용 DB
▪
리오더 Task Definition DB: 리오더 태스크 표준 정의용 DB
•
리오더 태스크 범위
◦
원단 발주 단계부터 수납 확정 단계까지 전 구간 포함 구조
•
관계형 구조 개요
◦
아이템 
리오더 1:N 관계형 구조
리오더 1:N 관계형 구조◦
리오더 → 리오더 태스크 N:1 관계형 구조
◦
리오더 태스크 → 리오더 Task Definition 참조 구조
•
리오더 생성 방식 설계
◦
아이템 페이지 내 "리오더 생성" 버튼 배치
◦
버튼 클릭 시 해당 아이템과 연결된 리오더 데이터 자동 생성
◦
아이템 기준 리오더 횟수 관계형 집계
•
자주 발생하는 설계 실수
◦
기존 프로젝트 DB 복제 후 리오더용으로 재사용 시도 → 기존 관계형 속성까지 복제되어 데이터 정합성 붕괴 리스크
◦
아이템 필드에 "리오더 횟수" 숫자 속성 추가 후 수동 입력 → 자동 집계 불가 및 입력 누락·오류 가능성 증가
4. 리스프레드(재확산) 시스템 재설계
•
기존 리스프레드 설계 문제점
◦
인스타 릴스, 유튜브 쇼츠, 네이버 라이브 등 매체별 조회수 중심 트래킹 구조
◦
하나의 아이템에 대해 매체별 데이터가 개별로 생성되는 분산 구조
◦
실제 비즈니스 판단 기준이 조회수가 아닌 매출 지표임에도 조회수 중심 설계 유지
•
리스프레드 프로세스 분석
◦
발견 단계: 등록 당일 11시, 14시 두 차례 주문율 체크 후 3.0 이상 시 확산 신호 감지
◦
분석 단계: 기능·실용·스타일 중 어떤 요인이 히트 포인트인지 분류
◦
공략 단계: 전체 콘텐츠 사용 vs 일부 요소만 활용 여부 결정
◦
시행 단계: 각 매체별 콘텐츠 배포 실행
◦
피드백 단계: 2주 후 매출 추이 확인 및 지속 여부 판단
•
재설계 방향: 매출 중심 구조 전환
◦
매체별 조회수 레벨 데이터 제거 후 아이템 단위 리스프레드 데이터 통합
◦
리스프레드 페이지 내 분석 내용, 전략, 결과를 템플릿 형식으로 구조화
◦
버튼 클릭 시 분석·전략·결과 입력용 템플릿 자동 생성 구조 설계
•
재설계 기대 효과
◦
"왜 잘 팔렸는가"에 대한 분석 내용 축적
◦
충분한 데이터 축적 후 AI 기반 패턴 분석 및 히트 예측 가능성 확보
◦
기간, 상품 특성 등 다양한 변수를 조합한 심층 분석 가능성 확보
•
핵심 설계 원칙
◦
데이터 구조는 최종 의사결정 기준(KPI)에 맞춘 설계 필요
◦
기준이 매출일 경우 조회수 트래킹에 과도한 리소스 투입 불필요
•
자기 비즈니스 적용 질문
◦
우리 회사에서 수집 중인 데이터 중 실제 의사결정에 사용되지 않는 데이터 목록화 필요
◦
최종 KPI 기준에 맞춰 데이터 구조 재설계가 필요한 영역 식별 필요
5. CS 이슈 처리 프로세스와 범용 스프린트 템플릿
•
CS 이슈 처리 워크플로우
◦
고객 불량 클레임 접수 단계 정의
◦
관련자 즉시 공유 및 정보 전달 구조
◦
출고 대기 상품 전량 확인 필요 여부 판단
◦
영향 범위 결정: 단일 고객 이슈 vs 전체 배송 고객 이슈 구분
◦
원자재·생산업체와의 소통을 통한 원인 규명 및 처리 방안 수립
◦
재발 방지 대책 수립 및 매뉴얼 업데이트 반영
•
관여 부서 역할
◦
CS 부서: 이슈 접수 및 고객 커뮤니케이션 담당
◦
물류 부서: 출고 정지, 입고 일정 관리 담당
◦
생산 부서: 생산업체와의 소통 및 원인 규명 담당
•
범용 스프린트 템플릿 필요성
◦
비주얼팀 복종별 페이지 작성, 디자인 작업 등 다양한 프로젝트 공존 상황
◦
진행 상황 공유 부재로 인한 협업 가시성 부족 이슈
◦
표준화된 템플릿과 개인 페이지 연동을 통한 진행 현황 공유 필요성
•
범용 템플릿 설계 난이도
◦
모든 부서 프로세스가 동일해야 완전 범용 구조 가능
◦
발견 → 분석 → 공략 → 점검 → 피드백 5단계 구조가 모든 업무에 동일하게 적용되지 않는 현실
◦
변수 발생 시 템플릿과 실제 업무 흐름 불일치로 인한 사용 중단 리스크
•
설계 원칙 정리
◦
여러 스프린트 워크플로우의 공통점을 추출하여 기본 골격 설계
◦
3개, 7개, 10개 태스크 등 다양한 규모를 수용하는 유연한 구조 설계
◦
중간에 다른 부서 업무가 삽입되는 케이스까지 고려한 관계 설계 필요
6. 매입처(공급업체) 평가 시스템 설계
•
평가 항목 구성
◦
촬영 샘플 품질 평가 항목
◦
메인 입고 품질 평가 항목
◦
수납 품질 평가 항목
◦
QC 점수 평가 항목
•
현재 관리 방식 한계
◦
구글 시트 내 숨겨진 열에 평가 점수 분산 입력 구조
◦
생산 단계별로 평가 열이 사이사이에 흩어져 있는 구조
◦
평가 점수 취합 및 분석 과정의 높은 난이도
•
평가 목적 정리
◦
아이템별 평가 점수를 모아 업체별 분기 피드백 자료 생성
◦
"촬영 샘플 점수 저조", "수납 점수 저조" 등 구체적 개선 포인트 제공
◦
신규 업체는 10점 기준, 기존 업체는 절대 평가 방식으로 수준 향상 유도 구조
•
데이터베이스 관계 구조
◦
Supply(매입처) ← 롤업 → Monthly Report ← 롤업 → Item(아이템) 구조
◦
Supply 단위 전체 평균, Monthly Report 단위 월별 평균 구조
•
Monthly Report DB 필요성
◦
월별 평가 분리를 위한 중간 계층 필수 구조
◦
아이템 → 매입처 직접 연결 시 기간별 구분 불가 이슈
◦
1월 부진, 2월 호조 상황이 평균 5점으로 상쇄되는 문제를 월별 분리로 해소 필요
•
평점 계산 로직
◦
아이템 레벨: 4개 평가 항목 점수 입력 구조
◦
Monthly Report 레벨: 해당 월 아이템들의 평균 점수 계산 구조
◦
Supply 레벨: 전체 Monthly Report 평균 점수 기반 전체 평점 산출 구조
•
등록일 기준 월 배정
◦
입고일 데이터 부재 상황
◦
등록일과 입고일의 차이가 미미하다는 가정하에 등록일 기준 월 배정 구조 적용
7. 매입처 평가 입력 시스템 설계
•
입력 방식 비교
◦
방식 1: 각 아이템 페이지에서 개별 입력 → 대량 작업 시 비효율 구조
◦
방식 2: 인풋 섹션에서 평가 대상 아이템 일괄 입력 → 권장 방식
•
인풋 섹션 설계 원칙
◦
아직 평가가 완료되지 않은 아이템만 필터링하여 표시
◦
표시 컬럼: 아이템명, 업체명, 4개 평가 점수, 입력완료 체크박스
◦
키보드 중심 조작을 통한 빠른 입력 경험 설계
•
체크박스 vs 버튼 비교
◦
체크박스: 탭 + 엔터만으로 조작 가능하여 대량 입력 효율성 높음
◦
버튼: 마우스 클릭 의존 구조로 대량 작업 시 피로도 증가
•
정렬 및 처리 순서
◦
등록일 기준 오름차순 정렬로 오래된 아이템부터 순차 평가
◦
평가 완료 시 체크박스 체크 후 목록에서 자동 제거 구조
8. 자동화를 통한 관계형 일괄 생성
•
문제 상황 정리
◦
아이템 등록 시점에 매입처가 확정되는 워크플로우 구조
◦
매입처 확정 시 Monthly Report와의 관계형도 동시에 생성되어야 하는 요구사항
◦
노션 단독 기능으로는 중간 계층(Monthly Report) 관계형 자동 생성 불가 제약
•
외부 자동화 도입 방향
◦
매입처 등록 버튼 클릭 시 외부 자동화 시나리오 실행 구조
◦
자동화 시나리오 단계
▪
해당 월 Monthly Report 존재 여부 확인 단계
▪
미존재 시 "YYYY년 M월 업체명" 형식 Monthly Report 신규 생성
▪
아이템 Monthly Report 관계형 자동 연결
Monthly Report 관계형 자동 연결▪
Monthly Report Supply 관계형 자동 연결
Supply 관계형 자동 연결▪
생성 완료 상태 플래그 업데이트
•
입력 위치 제약 설계
◦
프로젝트 하위 아이템 등록 섹션에서만 매입처 입력 허용
◦
다른 위치에서 매입처 입력 시 관계형 자동 연결 누락 리스크
◦
"이 위치에서는 절대 입력 금지" 표시를 통한 사용 가이드 필요성
9. 범용 템플릿과 발주서 시스템
•
노션 발주서/견적서 한계
◦
노션이 DB 중심 구조라 가로·세로 표 형태의 정형 견적서 출력에 한계 존재
◦
순수 노션만으로는 전통적인 문서형 발주서/견적서 구현 난이도 높음
•
하이브리드 아키텍처 제안
◦
백엔드: 노션 DB 기반 데이터 관리 및 이력 보관
◦
프론트엔드: 별도 웹 앱에서 견적서 UI 렌더링 구조
◦
데이터 흐름: 노션에서 JSON 추출 → 웹 앱으로 전달 → 견적서 형태 렌더링
•
SaaS 시나리오 예시
◦
견적서 작성 → 미리보기 → 전송 플로우
◦
노션 DB와 연동하여 데이터 일관성 유지 구조
◦
AI 연동은 별도 기능으로 추가 개발 영역
10. 프로젝트 일정 및 향후 계획
•
이번 주 운영 일정
◦
화·수·금 온라인 진행 일정
◦
목요일 휴무 일정
◦
금요일 컨설턴트 개인 일정으로 인한 불참 가능성
•
프로젝트 완료 목표
◦
이번 주 또는 다음 주 월요일까지 프로젝트 마무리 목표
◦
태스크 일괄 생성 자동화 워크플로우 수요일 테스트 예정
•
추가 개발 항목
◦
리오더 시스템: DB 3개 추가 구축 필요 및 추가 비용 발생 요소
◦
범용 스프린트 템플릿: 워크플로우 확정 이후 제작 단계 진입
◦
리스프레드 템플릿: 분석 프로세스 자료 제공 시 템플릿 제작 가능
•
컨설턴트 일정 제약
◦
2월~3월 중반 커뮤니티 운영 집중 구간으로 여유 시간 제한
◦
3월 중반 이후 신규 프로젝트 착수 가능 구간
◦
대안: 하루 2시간 분할 투입 방식 진행 가능성
11. 추가 참고 주제
•
AI 오케스트레이션: 스킬 기반 AI 작업 자동화 원리 및 실무 적용 사례 모음
•
노션 관계형 심화: 중간 테이블을 활용한 다대다 관계 설계 패턴
•
