개요
•
패션/의류 브랜드의 프로젝트 관리 시스템(Notion 기반) 구축 컨설팅 미팅 기록
•
컨설턴트(Speaker 1)가 클라이언트 팀(디자인팀, 생산팀, 물류팀 등)에게 태스크 관리, 업체평가, 리오더/리스프레드 프로세스 포함 시스템 구현 현황 시연
•
실시간으로 업무 플로우 확정 및 세부 설정 조정 진행
•
미팅 핵심 가치: 실제 업무 프로세스를 디지털 시스템으로 전환하는 과정에서 발생하는 의사결정 과정 자체
◦
태스크 간 선행/후행 관계 설정
◦
자동화 시나리오 구축
◦
공휴일 반영 날짜 산정
◦
업체평가 차트화
◦
리오더 차수 관리
•
"자동화를 위해 먼저 프로세스를 정의해야 한다"는 원칙이 미팅 전반에 관통
•
도구(Notion + Make 자동화)보다 업무 흐름의 설계가 선행되어야 함을 실증적으로 제시
주요 학습 포인트
•
태스크 간 관계형(선행/후행) 설정이 공휴일 제외 날짜 산정의 전제 조건 — 단순 "기준일+N일" 방식으로는 공휴일 제외 로직 구현 불가
•
자동화 시나리오는 "보이는 상태"로 실행하는 것이 운영 안정성을 높임 — 버튼만 눌러도 동작하지만, 시나리오를 열어놓고 실행해야 가시성 확보
•
데이터베이스 설계에서 "순번(차수)" 개념은 자동 부여가 어려움 — Notion DB의 구조적 한계 인식 및 우회 방안(리오더 시 카운트 + 수동 차수 삽입) 설계 필요
•
필터/정렬 초기화 습관이 공유 데이터베이스 운용의 핵심 — 필터 걸어 분석하고, 반드시 초기화하여 다음 사용자에게 원본 뷰 유지
•
캘린더와 타임라인은 각각의 용도가 다름 — 캘린더는 단일 날짜 필드 기반이므로 복수 일정 비교에 부적합, 타임라인은 기간 기반 트래킹에 적합
요약
1. 태스크 관계형 설정과 공휴일 반영 로직
•
기존 방식의 한계와 변경 사항
◦
기존: "기준일로부터 N일 뒤에 M일간"으로 태스크 정의 → 태스크 간 연결 없어 공휴일 자동 제외 날짜 산정 불가능
◦
변경: 모든 태스크를 선행(Predecessor)과 후행(Successor)으로 관계형 연결
▪
리서치 → 두 개 병렬 태스크 → 패턴 작업 → 세 개 병렬(작업원가, 사전원가, 생산처 결정) → 샘플 QC → 2차 입고 순 전체 체인 연결
•
타임라인 뷰에서의 관계형 시각화
◦
타임라인 뷰에서 각 태스크의 끝과 다음 태스크의 시작이 화살표로 연결되어 전체 프로세스 흐름 한눈에 파악 가능
◦
관계형 연결 방법: 타임라인에서 태스크 끝의 화살표를 드래그하여 다음 태스크에 연결 → 자동 관계형 생성
•
공정 추가 시 관계형 재설정
◦
새로운 공정 추가 시 해당 공정을 기존 체인 사이에 관계형으로 "맺어야" 함
◦
맨 첫 태스크부터 맨 마지막 "종료"까지 끊김 없이 연결되어야만 공휴일 제외 전체 일정 산정 가능
핵심 원칙: 날짜 자동 산정은 "관계형 체인의 완전성"에 의존 — 하나라도 끊기면 공휴일 제외 로직 미작동
•
태스크 관계형 설정 체크리스트◦
모든 태스크가 최소 하나의 선행 또는 후행 태스크와 연결되어 있는가
◦
병렬 처리 태스크(동시 진행)는 동일 선행 태스크에서 분기하고, 완료 후 동일 후행 태스크로 합류하는가
◦
첫 태스크(시작)부터 마지막 태스크(종료)까지 경로가 끊기지 않는가
◦
타임라인 뷰에서 화살표 연결이 시각적으로 확인되는가
•
주의: 흔히 하는 실수◦
"기준일+N일" 방식과 관계형 방식 혼용 시 일부 태스크만 공휴일 반영되고 나머지는 반영되지 않는 혼재 상태 발생
◦
반드시 전체를 하나의 방식으로 통일 필요
2. Task Definition과 자동화 시나리오 시연
•
Task Definition 구조
◦
Task Definition DB에 모든 태스크 정의(태스크명, 소속 팀, PIC 담당자) 사전 등록
◦
PIC(Person In Charge) 담당자 지정 시 자동 생성 시 해당 이름으로 태스크 할당 및 Notion 멘션 알림 자동 발송
•
아이템 등록 → 태스크 자동 생성 프로세스
1.
프로젝트 페이지에서 신규 프로젝트 등록
2.
아이템 등록 (주차 + 품번 형태, 예: "10주차 5349")
3.
실행 순서대로 설정: 색상 → 품번 변경 → 사이즈 → 수량 입력
4.
Task 버튼 클릭 → Make 자동화 시나리오 동작 → Task Definition 기반 해당 아이템 태스크 일괄 생성
•
자동화 시나리오 실행의 가시성 확보
◦
버튼만 클릭해도 자동화 동작하지만, Make 시나리오 화면을 열어놓은 상태에서 실행 권장
◦
이유: 각 태스크 순차 생성 과정 실시간 확인 가능 → 디버깅과 모니터링 가능
◦
시연 내용: 3개 아이템 등록 → 시나리오 실행 → 첫 번째 아이템 태스크 일괄 생성 → 대기열 제거 → 두 번째 아이템 처리 → 제거 → 세 번째 처리 → 완료
•
품번 변경의 일괄 반영
◦
아이템 등록 시 임시 품번(예: "10주차 5349")으로 등록 후, 정식 품번 확정 시 아이템 등록 페이지에서 품번만 변경하면 연결된 모든 곳에 자동 반영
◦
Notion의 관계형 데이터베이스 특성으로, 원본 데이터 하나 수정 시 참조하는 모든 뷰 동시 업데이트
핵심 원칙: 자동화의 신뢰성은 "눈에 보이는 실행"에서 비롯 — 처음 몇 번은 반드시 시나리오를 열어놓고 실행하며 흐름 확인 필요
•
내 비즈니스에 적용하기◦
우리 팀에서 반복적으로 생성해야 하는 태스크 세트는 무엇인가? (예: 신규 고객 온보딩, 콘텐츠 발행, 제품 출시)
◦
태스크 자동 생성 시 담당자 지정 규칙은 어떻게 정의할 것인가?
◦
자동화 실행 후 결과를 확인하는 모니터링 프로세스가 있는가?
3. Task Definition 변경과 기존 데이터의 관계
•
변경 적용 범위의 이해
◦
Task Definition 내용(날짜 수, 태스크 순서 등) 변경 시 이미 생성된 태스크에는 영향 없음
◦
변경 사항은 변경 이후 새로 생성하는 태스크부터 적용
◦
Task Definition이 "템플릿" 역할을 하기 때문이며, 생성된 태스크는 독립적인 데이터 레코드로 존재
핵심 원칙: Task Definition은 "붕어빵 틀" — 틀을 바꿔도 이미 구워진 붕어빵은 변하지 않지만, 다음에 굽는 붕어빵은 새 틀을 따름
•
주의: 흔히 하는 실수◦
Task Definition 수정 후 기존 프로젝트 태스크도 자동으로 바뀔 것이라 기대하는 경우 많음
◦
기존 태스크 수정 시 직접 해당 태스크에 들어가서 수정 필요
4. 업체평가(Supplier Evaluation) 시스템 구축
•
업체평가 데이터 구조
◦
평가(전체 평가): 모든 공급업체의 전체 기간 평가를 표와 차트로 확인
◦
월간평가: 이번 달 / 지난달 / 전체 보기 탭으로 구분
◦
각 업체별로 10점 만점 기준의 평가 점수 매김, 점 그래프와 차트 두 가지 시각화 제공
•
거래 건수와 평점의 결합 분석
◦
평점만으로는 업체 역량 판단 어려움 → 거래 건수와 평점 함께 표시
◦
예: 어떤 업체의 평점이 5점이라면, 거래가 적어서 낮은 것인지 실제 품질이 낮은 것인지 거래 건수를 통해 맥락 파악 가능
◦
월별 리포트의 거래 건수 = 해당 월 거래 건수 / 상단 서플라이어 뷰의 거래 건수 = 전체 누적 거래 건수
•
필터와 정렬 활용법
◦
월간평가에서 특정 월 확인: 필터에서 "2026년 4월" 선택 → 해당 월 데이터만 표시 → 확인 후 반드시 초기화
◦
특정 업체만 확인: 서플라이어 필터에서 업체명 클릭 → 해당 업체 전체 이력 표시
◦
정렬 변경: 기본은 평점순(내림차순) → 이름순/월별 오름차순으로 변경 가능
◦
사용 완료 후 초기화 필수 — 다음 사용자가 필터 걸린 상태를 원본으로 오해 방지
•
거래 평점 차트 뷰
◦
월별 평가 차트: 기본적으로 필터 미지정 상태 → 보고 싶은 월 선택 시 해당 월의 모든 업체 점수 표시
◦
업체별 평가 차트: 특정 업체 선택 시 해당 업체의 전체 거래 이력과 점수 추세 표시 → 시간에 따른 품질 변화 추적 가능
핵심 원칙: 항상 필터를 걸고 사용하고, 사용 후 반드시 초기화 — 공유 데이터베이스에서 필터 잔류는 가장 흔한 운영 사고의 원인
•
업체 추가 등록
◦
프로젝트 페이지 내 업체 등록 섹션에서 "재료 만들기" 버튼 → 정보 입력 → 입력 완료
◦
삭제 시: 검색(Search) 기능을 통해 해당 업체를 찾아서 삭제
5. 데이터 삭제 및 수정 가이드
•
일반 사용자의 데이터 수정/삭제
◦
잘못 입력된 데이터: Search 기능에서 검색 → 해당 항목 삭제
◦
기존에는 "입력완료" 체크된 값만 Search에 노출되었으나, 이번 구축에서는 모든 값을 Search에서 볼 수 있도록 변경 → 잘못 들어간 데이터도 바로 발견 가능
•
관리자(대리급)의 데이터 수정/삭제
◦
데이터베이스에 직접 접근하여 수정 가능
◦
최상위 항목에서 삭제 시 하위 연결 데이터 모두 삭제
◦
일반 사용자는 Search → 삭제, 관리자는 DB 직접 접근 → 삭제/수정 모두 가능
핵심 원칙: 데이터 삭제는 항상 "검색 후 확인 → 삭제" 순서 준수 — 상위 항목 삭제는 연쇄 삭제 유발하므로 신중 필요
6. 리오더(Reorder) 프로세스 정의와 시스템 설계
•
리오더 진입 시점과 조건
◦
상품 등록 완료 후, 판매 추이 보면서 리오더 결정
◦
등록 당일 바로 결정 가능, 며칠 후에 결정도 가능
◦
리오더 횟수 제한 없음 (1번~N번 가능) → 리오더 차수 필드 필요
•
리오더 태스크 워크플로우 확정
◦
메인(신규) 프로세스에서 빠지는 태스크: 촬영 샘플, 판매가 산정
◦
리오더 태스크 순서와 소요 기간:
순서 | 태스크 | 소요 기간 | 비고 |
1 | 원단 발주 | 1일(당일) | 동시 진행 |
2 | 부자재 발주 | 1일(당일) | 동시 진행 |
3 | 메인 작지 투입 | 1일(당일) | 동시 진행 (리오더 폼 캡처 전송) |
4 | 메인 원단 컨펌 | 3일 | 공장에서 수행 |
5 | 원단 공장 입고 | 3일 | 메인 원단 컨펌과 동시 진행 |
6 | 생산 일정 확인 | 3일 | 원단 공장 입고와 동시 진행 |
7 | 메인입고 상품 확인 | 10일 | 원단 투입 후 생산 기간 포함 |
•
리오더와 메인의 차이점
◦
메인: 작업실에서 새로 작지를 꾸며서 제출 / 리오더: 기존 리오더 폼에 옵션별 수량을 캡처하여 전송
◦
메인: 원단 컨펌을 자체적으로 수행 / 리오더: 공장에서 메인 원단과 동일 여부 확인(시간 부족)
◦
메인: 수납 컨펌 있음 / 리오더: 수납 컨펌 없이 입고 즉시 확인
◦
리오더 시 메인입고 상품 확인에서는 "메인 때 미비했던 부분이 보완되었는지" 중점 확인
•
리오더 시작일 설정
◦
리오더 시작일 = 버튼 클릭 다음 날부터 프로세스 진행
◦
"리오더 생성일"이 아닌 "리오더 시작일"로 명명 확정
◦
시스템이 자동으로 날짜 산정해주지만, 실제 업무에서는 차이 발생 가능 → 담당자가 날짜 추적하고 필요 시 조정
핵심 원칙: 자동화가 제시하는 날짜는 "최선의 근접치" — 100% 정확하지 않더라도, 기준점이 있는 것과 없는 것의 차이는 큼
•
리오더 프로세스 설정 체크리스트◦
리오더 태스크에서 메인 전용 태스크(촬영 샘플, 판매가 산정)가 제외되었는가
◦
동시 진행 태스크(원단발주, 부자재발주, 작지투입)가 병렬로 설정되었는가
◦
각 태스크의 소요 기간이 실무 기준으로 설정되었는가
◦
리오더 차수 필드가 자동 카운트되도록 구현되었는가
◦
리오더 시작일이 버튼 클릭 다음 날로 설정되었는가
7. 리오더 시스템 구현과 아이템 내 관리
•
아이템 페이지 내 리오더 관리
◦
리오더는 아이템 단위로 관리 — 아이템 페이지 내에서 리오더 버튼 클릭 시 하위에 리오더 레코드 생성
◦
리오더 버튼 클릭 → 자동화 시나리오 동작 → 태스크 일괄 생성 → 상태 자동으로 "진행중"으로 변경
◦
진행중 → 완료 처리는 각 태스크별로 수동 전환
•
리오더 차수 관리
◦
리오더 생성 시마다 차수 자동 카운트 (1, 2, 3...)
◦
Notion DB에는 자동 순번(Auto-increment) 기능 없음 → 리오더 생성 시 기존 차수 카운트하여 다음 차수로 삽입하는 로직을 자동화에 포함
◦
표시 방식: 숫자만 표시 (1, 2, 3) — "리오더 1차수"가 아닌 단순 숫자
•
아이템 페이지 상단 표시 필드
◦
품번(제목), 매입처, 담당자, 등록일, 등록주차, 라인, 색상, 사이즈, 판매가
◦
수량은 제외, 원가는 제외하고 판매가만 표시
•
태스크 진행 상태 관리
◦
시작 전 → 진행중: 해당 태스크 시작 시 전환
◦
진행중 → 완료: 완료 시 전환하면 메인 뷰에서 사라지고 완료 영역으로 이동
◦
되돌리기: 완료 → 진행중으로 다시 전환 가능
•
주의: 흔히 하는 실수◦
리오더 차수가 캘린더에서 구분되지 않아 같은 아이템의 1차/2차 리오더가 혼동될 수 있음
◦
캘린더 표시 시 아이템명 + 차수 번호가 함께 표시되도록 설정 필요
8. 입고 일정 캘린더 구축
•
캘린더의 구조적 제한과 해결
◦
Notion 캘린더는 하나의 날짜 필드에 대해서만 생성 가능 → 메인 입고 날짜와 리오더 입고 날짜를 하나의 캘린더에 통합 불가
◦
해결: 메인 입고 캘린더와 리오더 입고 캘린더를 별도로 생성하여 같은 페이지에 배치
◦
이 캘린더는 프로젝트 메인 페이지 하단에 위치
•
캘린더 vs 타임라인 선택 기준
◦
타임라인: 태스크별 기간과 순서를 한눈에 파악할 때 적합 (아이템 내부 트래킹)
◦
캘린더: 특정 날짜에 어떤 이벤트가 있는지 확인할 때 적합 (입고 일정 확인, 팀 간 공유)
◦
캘린더가 태스크 전체를 표시하면 극도로 지저분해짐 → 특정 태스크(입고 확인 등)만 필터링하여 표시
•
캘린더의 활용 부서
◦
CS팀, 물류팀: 리오더된 상품의 입고 예정일 확인
◦
촬영팀: 메인 입고 일정 확인 (촬영 스케줄 조율)
◦
전체 팀: 프로젝트 페이지에서 스크롤하여 필요한 캘린더 확인
핵심 원칙: 캘린더는 "무엇이 보일지" 설계하는 것이 핵심 — 모든 것을 보여주면 아무것도 보이지 않음
9. 리스프레드(Re-spread) 프로세스 설계
•
리스프레드의 특성
◦
리오더와 달리 자동 태스크 생성 없음 — 리스프레드 레코드 생성 후 내부 페이지에서 템플릿 기반으로 운영
◦
매체(채널)별로 리스프레드 별도 생성: 상세페이지, 유튜브 숏폼, 유튜브 롱폼, 인스타그램 릴스, 큐레이션, 썸네일, 추가 코디, 스토리, 카카오톡, 라이브방송, 광고
•
리스프레드 실행 프로세스
1.
아이템 페이지에서 매체 선택
2.
리스프레드 버튼 클릭
3.
확인 메시지 표시 (예: "유튜브 롱폼 리스프레드 생성되었습니다")
4.
확인 후 해당 매체의 리스프레드 레코드가 아이템 하위에 생성
5.
생성 시 상태 = "시작 전" → 진행 시 "진행중"으로 전환
•
PIC(담당자) 지정
◦
리스프레드에도 PIC 필드 추가 — 담당자 변경 가능
◦
기본적으로 아이템 담당자를 따라가되, 리스프레드 생성 후 변경 가능
•
리스프레드 위치
◦
아이템 페이지 내에서 리오더보다 아래에 배치
◦
개인 대시보드에서도 자신이 담당하는 리스프레드 목록 확인 가능
•
주의: 흔히 하는 실수◦
같은 아이템에 대해 여러 매체의 리스프레드 생성 시 품번이 동일한 항목이 여러 개 나열되어 혼동 발생 가능
◦
제목에 매체명이 포함되도록 자동 설정 필요
10. 개인 대시보드와 프로젝트 통합 설계
•
개인 페이지 구성
◦
OKR 섹션(토글) + 프로젝트 섹션(토글) 두 개로 구성
◦
OKR 페이지는 기존 제작된 것을 그대로 가져와 통합
◦
프로젝트 섹션에서는 자신이 담당하는 태스크, 리오더, 리스프레드를 아이템별로 분류하여 표시
•
개인 페이지의 정렬 방식
◦
"나"를 중심으로 자동 필터링 — 내가 PIC인 항목만 표시
◦
표시 순서(태스크 → 리오더 → 리스프레드)는 고정이며, 이 형태로만 볼 수 있음
◦
비주얼/웹 비주얼팀 등 아이템 개발과 무관한 팀에게는 해당 섹션이 의미 없을 수 있으나, 구조상 동일 템플릿 적용
•
버튼 배치 전략
◦
리오더/리스프레드 생성 버튼: 프로젝트 페이지와 개인 페이지 양쪽 모두 배치
◦
어디서든 생성 가능하도록 하여 접근성 확보
핵심 원칙: 개인 대시보드는 "나에게 할당된 것만 보이는 필터링된 뷰" — 전체 현황은 프로젝트 페이지에서, 내 할 일은 개인 페이지에서 관리
11. 향후 일정과 데이터 테스트 계획
•
구현 완료 현황
◦
태스크 자동 생성, 관계형 설정, 업체평가, 리오더, 리스프레드 기본 구조 모두 구현 완료
◦
캘린더(메인 입고, 리오더 입고)는 추가 제작 예정
•
남은 작업
◦
실제 데이터 입력 테스트 (금요일 예정)
◦
데이터 입력 과정에서 발생하는 오류/꼬임 수정
◦
OKR과 프로젝트 개인 대시보드 통합
◦
디테일 조정 (필드 순서, 명칭, 뷰 설정 등)
•
일정 계획
◦
금요일: 실제 데이터 1차 테스트
◦
다음 주 2~3일 내 종료 예정
◦
최종일은 오프라인 미팅으로 마무리
