개요
•
이 영상의 주제
◦
의류/패션 회사의 프로젝트 관리 시스템을 노션(Notion)으로 구축하는 실제 컨설팅 세션
◦
프로젝트 → 아이템 → 태스크의 3단계 계층 구조 기반 설계
•
다루는 핵심 내용
◦
각 단계에서의 데이터 입력 방식 설계
◦
자동화 로직 및 버튼 기반 상태 전환 설계
◦
개인/팀/전사 등 다양한 이해관계자를 위한 뷰 구성 방식
•
핵심 설계 원칙
◦
기준일 기반 상대적 날짜 계산 방식
▪
절대 날짜(1월 6일, 1월 10일 등)가 아닌, 기준일로부터 며칠 후에 시작, 며칠간 진행 방식으로 일정 정의
▪
기준일 변경 시 전체 일정 자동 재계산이 가능하도록 하는 유지보수 친화적 구조
◦
버튼 기반 상태 전환 시스템
▪
복잡한 워크플로우를 단일 버튼 클릭으로 단순화하는 구조
◦
링크드 데이터베이스 활용
▪
하나의 원본 데이터베이스를 여러 페이지에서 필터/정렬 조건만 달리하여 재사용하는 구조
•
실무 설계 포인트
◦
입력 섹션 분리 설계
▪
신규 등록 섹션 vs 아이템 등록 섹션 분리
◦
필터를 활용한 데이터 노출 제어 방식
◦
그룹화를 통한 정보 구조화 방식
◦
개인/팀/전사 레벨의 대시보드 설계 방안
주요 학습 포인트
•
기준일 기반 상대적 날짜 계산
◦
절대 날짜 대신 시작일 + N일 방식으로 태스크 일정 정의
◦
프로젝트 변경 시 유지보수성을 크게 높이는 설계
•
상태값 기반 데이터 흐름 제어
◦
가등록 → 진행 중 → 완료의 단계적 상태 전환 구조
◦
입력 섹션과 트래킹 섹션 간 데이터 이동을 상태값으로 제어하는 구조
•
링크드 데이터베이스의 전략적 활용
◦
하나의 원본 데이터베이스를 여러 페이지에서 재사용하는 구조
◦
각 페이지에서 서로 다른 필터, 정렬, 그룹 조건 적용
•
계층별 뷰 설계
◦
개인(담당자), 팀(부서), 전사(프로젝트) 관점으로 동일 데이터를 다르게 조회하는 구조
•
버튼 기반 워크플로우 자동화
◦
복잡한 상태 변경과 데이터 생성을 버튼 한 번으로 처리하는 경험 설계
요약
1. 병렬 작업 로직의 재설계: 절대 날짜에서 상대 날짜로
•
문제 인식: 절대 날짜 기반 설계의 한계
◦
각 태스크에 1월 1일, 1월 6일 같은 절대 날짜를 직접 지정하는 방식
◦
병렬 분기 태스크가 많을수록 모든 가능성을 변수로 열어두어야 하는 복잡성 발생
◦
타임라인 뷰에서 리서치 완료 후 여러 태스크가 동시에 진행되고, 이후 재분기되는 구조로 인한 유지보수 난이도 증가
•
해결 방향: 기준일 기반 상대 일정 계산
◦
태스크 시작일을 기준으로 "며칠 뒤 시작" + "며칠간 진행" 형태로 일정 정의
◦
예시
▪
리서치 태스크: 0일차 시작(킥오프 당일 시작)
▪
후속 태스크: 기준일로부터 6일 뒤 시작, 3일간 진행
◦
워킹데이 기준
▪
주말을 제외한 평일 기준 일정 계산 방식
▪
공휴일 처리는 Google Calendar API 연동을 통한 추후 확장 과제
•
핵심 원칙
◦
유지보수가 쉬운 시스템은 절대값이 아닌 상대값 기반 설계 지향
◦
기준점 하나만 변경해도 전체 일정이 자동 재계산되는 구조 지향
•
실무 적용 시 고려사항
◦
병렬 작업이 많은 프로젝트일수록 상대 날짜 방식의 필요성 증가
◦
버튼 한 번으로 특정 아이템의 모든 태스크를 일괄 생성하는 구조 설계
◦
각 태스크의 시작 오프셋과 기간을 별도 정의 테이블(Task Definition)에서 관리하는 구조
•
일정 계산 로직 설계 체크리스트
기준일(킥오프 날짜) 속성 정의 여부
태스크별 시작 오프셋(+N일) 정의 여부
태스크별 기간(N일) 정의 여부
워킹데이(주말 제외) 계산 로직 구현 여부
공휴일 데이터 연동 방안 검토 여부
2. 계층적 데이터 구조와 입력 프로세스 설계
•
3단계 계층 구조
◦
프로젝트 계층
▪
월별/시즌별 단위 프로젝트
▪
예시: 4월 에센셜 워드로브 프로젝트
◦
아이템 계층
▪
개별 상품 단위
▪
품번을 주요 식별자로 사용하는 구조
◦
태스크 계층
▪
아이템별로 수행해야 할 업무 단위
•
입력 섹션 분리 전략
◦
신규 등록 섹션
▪
최초 품번 등록만 담당하는 섹션
▪
최소 정보 입력 후 다음 단계로 넘기는 역할
◦
아이템 등록 섹션
▪
품번 변경, 색상, 사이즈, 수량, 태스크 시작일 등 상세 정보 입력 담당
◦
분리 효과
▪
정보의 점진적 완성 구조 확보
▪
입력 단계별 데이터 품질 관리 용이성 확보
•
입력완료 버튼 역할
◦
버튼 클릭 시 동작
▪
입력완료 체크박스 자동 체크
▪
상태값 변경
•
데이터 섹션 이동 트리거
◦
입력 섹션 동작 원리
▪
입력완료 = false인 데이터만 노출
▪
버튼 클릭 시 필터 조건 불일치 상태로 전환되어, 입력 섹션에서 자연스럽게 제외되는 흐름
•
입력 흐름 개념
◦
신규 등록 섹션에서 품번 등록
◦
입력완료 버튼 클릭으로 아이템 등록 섹션으로 이동
◦
아이템 등록 섹션에서 상세 정보 입력 후 태스크 생성 버튼 클릭
◦
태스크 자동 생성 후 트래킹 섹션에서 관리하는 구조
•
주의사항
◦
새로 만들기 버튼 직접 사용 지양
▪
관계형 자동 연결이 이루어지지 않아 데이터 정합성 붕괴 가능성
◦
설계된 버튼을 통한 데이터 생성 강제
▪
새로 만들기 버튼은 숨김 불가이므로, 매뉴얼에서 사용 금지 규정 명시 필요
3. 상태값 설계: 4단계 상태 전환 시스템
•
상태값 정의
◦
시작 전
▪
최초 등록 및 미입력 상태
▪
노출 위치: 신규 등록 섹션
◦
가등록
▪
기본 정보 입력 완료 상태, 태스크 생성 전 상태
▪
노출 위치: 아이템 등록 섹션
◦
진행 중
▪
태스크 생성 완료 후 실제 작업 진행 상태
▪
노출 위치: 트래킹 섹션
◦
완료
▪
모든 태스크 완료 상태
▪
노출 위치: 완료 아카이브
•
상태 전환 트리거
◦
시작 전 → 가등록
▪
입력완료 버튼 클릭
◦
가등록 → 진행 중
▪
태스크 생성 버튼 클릭
◦
진행 중 → 완료
▪
마지막 태스크(등록 태스크) 완료 시 자동 전환 예정
•
필터 기반 데이터 노출 제어
◦
아이템 등록 섹션
▪
상태 = 가등록 조건의 아이템만 노출
◦
버튼 클릭 후 동작
▪
상태값을 진행 중으로 변경
▪
필터 조건 불일치로 해당 섹션에서 자동 제외되는 구조
•
상태 전환 설계 템플릿 개념
◦
[현재 상태] + [트리거 액션] → [다음 상태] + [부가 작업] 패턴 활용
◦
예시
▪
[가등록] + [태스크 생성 버튼] → [진행 중] + [Task Definition 기반 태스크 일괄 생성] 패턴
4. 아이템 페이지 내 태스크 뷰 구성
•
레이아웃 선택 기준
◦
표(Table) 뷰
▪
상세 정보 확인 및 직접 수정에 적합한 뷰
◦
타임라인 뷰
▪
일정 조정 시 드래그앤드롭으로 직관적 변경이 가능한 뷰
◦
캘린더 뷰
▪
데이터가 많을수록 복잡성이 커지는 뷰
▪
본 시나리오에서는 비추천 대상
◦
권장 구성
▪
아이템 페이지 내에서 표 뷰와 타임라인 뷰를 함께 제공하는 구성
•
타임라인 뷰의 한계와 보완 전략
◦
한계
▪
타임라인 상에서 날짜 세부 정보 가시성이 떨어지는 문제
◦
보완 방식
▪
표 뷰에 날짜 + 요일 형식 표기
•
예시: 1월 6일 월요일 형식
▪
마감일까지 남은 일수를 보여주는 D-day 수식 활용
•
미완료 상태: 남은 일수 표시
•
완료 상태: D-day 대신 "완료" 텍스트 표시
•
태스크 뷰에서 표시할 핵심 속성
◦
PIC(담당자)
▪
가장 중요한 속성으로, 맨 앞에 배치
◦
팀
◦
태스크명
◦
날짜
▪
시작일 ~ 종료일 + 요일 표기
◦
상태
◦
D-day
5. 주차별 필터링과 슬라이서 기능 구현
•
요구사항: 특정 주차 아이템만 조회하는 기능
◦
예시
▪
9주차, 10주차 등 특정 주차 기준 아이템 진행 상황 확인 필요
◦
단순 날짜 기준 필터링의 한계
▪
다른 주차 아이템과 뒤섞여 표시되는 문제
•
해결 방향: 등록주차 속성 활용
◦
아이템에 등록주차 속성 존재
◦
태스크에서 아이템의 등록주차를 롤업으로 가져오는 구조
◦
뷰 필터에 등록주차 조건 추가
•
Excel 슬라이서 유사 방식 구현
◦
개념
▪
필터 조건을 데이터베이스 외부 입력 값으로 분리
◦
동작 구조
▪
필터 입력 필드에 "9주차", "10주차" 등 텍스트 입력
▪
링크드 DB 필터 조건에서 등록주차 = 입력값 비교
▪
데이터베이스 잠금 기능을 활용하여 필터만 조작 가능하도록 설정
6. 태스크 트래킹: 버튼 기반 상태 변경 시스템
•
기본 트래킹 방식: 순환 버튼 구조
◦
버튼 1회 클릭
▪
상태: 시작 전 → 진행 중 전환
◦
버튼 2회 클릭
▪
상태: 진행 중 → 완료 전환
◦
완료 처리 시
▪
종료일 자동 기록 동작
•
개인 페이지에서의 트래킹 동작
◦
담당자별 대시보드에서 자신의 태스크만 확인하는 구조
◦
개별 태스크의 상태를 개인 페이지에서 직접 변경하는 동작
◦
프로젝트 페이지로 깊게 진입하지 않고도 작업 가능
•
실수 복구 메커니즘
◦
완료 탭 별도 구성
▪
실수로 완료 처리한 항목을 확인할 수 있는 영역
◦
복구 흐름
▪
완료 탭에서 항목 클릭
▪
상태를 다시 시작 전으로 변경
▪
미완료 탭으로 복귀
▪
종료일 속성은 수동 삭제 필요
•
설계 원칙
◦
실수는 필연적으로 발생하는 전제
◦
되돌리기 경로를 워크플로우 설계에 반드시 포함하는 원칙
7. 프로젝트 메인 페이지 구성
•
탭 구조: 시간 기반 분류
◦
올해 탭
▪
올해 프로젝트만 표시
▪
기간 오름차순 정렬(1월 → 12월)
◦
지난해 탭
▪
작년 프로젝트만 표시
▪
기간 오름차순 정렬
◦
전체 보기(View All) 탭
▪
모든 프로젝트 표시
▪
기간 내림차순 정렬(최신 프로젝트 상단)
•
아이템 목록 뷰 설계
◦
정렬 기준
▪
등록일 기준 내림차순 정렬(최근 등록 아이템 상단)
◦
필터링 기준
▪
등록일이 비어있는 항목은 표시 제외
•
아직 등록 완료되지 않은 아이템 제외 목적
◦
로딩 개수 정책
▪
기본 50개 로드
▪
필요 시 100개까지 확장 로드
◦
시각적 목적
▪
주차/월 상관없이 전체 아이템을 한눈에 파악하는 구조
•
표에서 표시할 주요 속성
◦
품번
◦
상품명
◦
라인
◦
등록일
◦
등록주차
◦
색상, 사이즈
◦
수량
◦
원가, 판매가
◦
담당자(PIC)
◦
상태
◦
진척률
8. 리스프레드(재확산) 관리 시스템
•
리스프레드 개념
◦
기존 등록 상품을 다른 매체에 재노출하는 마케팅 활동
◦
예시
▪
유튜브, 릴스, 네이버 라이브 등으로의 재확산
◦
위치
▪
아이템 태스크 완료 이후 별도로 진행되는 후속 프로세스
•
시스템 구조
◦
트리거 섹션
▪
리스프레드 대상 선정 및 생성용 섹션
▪
시각적 구분을 위한 노란색 영역 구성
◦
메인 섹션
▪
실제 리스프레드 진행 및 트래킹 담당 섹션
•
리스프레드 생성 프로세스
◦
1단계
▪
트리거 섹션에서 리스프레드 대상 아이템 선택
◦
2단계
▪
매체(유튜브, 릴스, 네이버 라이브 등) 지정
◦
3단계
▪
생성 버튼 클릭으로 관계형 자동 연결
◦
4단계
▪
메인 섹션에 리스프레드 항목 자동 생성
◦
5단계
▪
각 항목에 URL 입력 후 진행 상태 트래킹
•
그룹화 전략
◦
아이템별 그룹화 적용
▪
동일 상품의 여러 매체 리스프레드를 묶어서 표시
◦
시인성 향상을 위한 설정
▪
제목 열 숨김
▪
그룹 헤더를 아이템 기준으로 사용
▪
매체 속성을 앞쪽에 배치하여 한눈에 구분 가능한 구조
9. 개인 페이지 설계: 담당자 중심 뷰
•
핵심 원칙: "나" 필터
◦
모든 관련 데이터베이스에 PIC = 나 조건 필터 적용
◦
로그인한 사용자 기준 자동 필터링 구조
◦
동일 페이지를 사용하면서 사용자별 개인화된 뷰 제공
•
개인 페이지 구성 요소
◦
아이템 섹션
▪
담당자가 본인인 진행 중 아이템 목록 노출
◦
태스크 섹션
▪
미완료 탭과 완료 탭 분리 구성
▪
아이템별 그룹화 적용
◦
타임라인 섹션
▪
내 태스크 일정 시각화용 뷰
•
보기 전용 뷰로 활용
•
태스크 뷰 상세 설정
◦
미완료 탭
▪
날짜 오름차순 정렬
•
마감이 임박한 태스크 상단 노출
▪
아이템별 그룹화 적용
◦
완료 탭
▪
날짜 내림차순 정렬
•
최근 완료 태스크 상단 노출
▪
그룹화 미적용
◦
그룹 자동 숨김 조건
▪
그룹 내 모든 태스크 완료 시 그룹 전체 자동 숨김
•
아이템 뷰 제한 설정
◦
진행 중인 아이템만 표시
◦
완료된 아이템은 자동 제외
◦
아이템 뷰에서는 상태 변경 버튼 미노출
▪
상태 변경은 태스크에서만 가능하도록 제한
▪
잘못된 조작으로 인한 데이터 오류 방지 목적
•
개인 페이지 설계 체크리스트
PIC = "나" 필터 적용 여부
아이템/태스크/타임라인 뷰 구성 여부
미완료/완료 탭 분리 여부
아이템별 그룹화 적용 여부
상태 변경을 태스크 뷰로만 제한했는지 여부
아이템 수준 진척률 표시 여부
10. 팀별 페이지 설계: 부서 관점의 현황 파악
•
팀 페이지 목적
◦
팀장이 소속 팀원 전체 진행 상황을 한눈에 파악하는 용도
◦
팀 미팅 시 현황 공유 자료로 활용
◦
팀 단위 병목 구간 식별 목적
•
설계 기준: 아이템 vs 태스크
◦
아이템 단위
▪
여러 팀이 공동 참여하는 경우가 많아 팀별 구분 의미가 낮은 단위
◦
태스크 단위
▪
팀별 업무 분류와 모니터링에 적합한 단위
◦
결론
▪
팀 페이지는 태스크 중심 구조로 설계
•
팀 페이지 구성
◦
아이템 영역
▪
전체 아이템 노출
▪
팀 필터 미적용
▪
완료되지 않은 아이템만 표시
◦
태스크 영역
▪
해당 팀 태스크만 필터링
▪
담당자, 상태, 날짜 등 핵심 정보를 함께 표기
◦
타임라인 영역
▪
팀 태스크 일정 시각화 뷰
•
기술적 한계와 우회 전략
◦
관계형 팀 DB 사용 시 문제
▪
아이템당 40개 태스크 × 10개 프로젝트 등의 구조에서 관계형 속성 수가 폭증
▪
속도 저하와 성능 문제 발생
◦
대안
▪
팀별 별도 페이지를 수동으로 생성
▪
각 페이지에 팀 필터를 하드코딩
▪
팀 추가/변경 시 페이지 수동 업데이트 필요
◦
의사결정 원칙
▪
자동화 비용(속도 저하)이 수동 작업 비용보다 클 경우 수동 방식 선택
▪
단, 변경 빈도가 낮은 항목에 한정하여 적용
•
진행 버튼 노출 정책
◦
팀 페이지에서는 상태 변경 버튼 미노출
◦
개인이 자신의 페이지에서만 상태를 변경하도록 제한
◦
책임 소재를 명확화하고 중복 변경을 방지하는 목적
11. 완료 기준과 자동 상태 전환
•
아이템 완료 시점 정의
◦
마지막 태스크인 "등록" 태스크 완료 시 아이템을 완료 처리하는 기준
◦
입고 시점이 아닌 등록 완료 시점을 최종 완료 기준으로 채택
◦
이후 프로모션/리스프레드는 별도 프로세스로 트래킹
•
자동화 구현 방향
◦
마지막 태스크 완료 버튼 클릭 시
▪
해당 아이템 상태값을 "완료"로 자동 변경
◦
구현 우선순위
▪
공수가 많이 드는 작업으로, 추후 개발 항목으로 분류
•
완료 후 노출 정책
◦
프로젝트 페이지
▪
완료 아이템도 계속 표시
•
히스토리 조회 및 분석 목적
◦
개인 페이지
▪
아이템 완료 시 개인 아이템 목록에서 제외
•
진행 중 작업에 집중하기 위한 뷰 설계
•
비즈니스 적용 자가 점검 질문
◦
우리 프로젝트에서 "완료"의 정확한 기준 정의 여부
◦
완료된 데이터를 어디까지 보존하고, 어디에서는 숨길지에 대한 정책 정의 여부
◦
자동 완료 처리가 필요한 영역과 수동 확인이 필요한 영역 구분 여부
12. 매뉴얼과 사용자 가이드 필요성
•
문서화 필수 항목
◦
버튼 클릭 순서와 각 버튼 역할
◦
입력 → 입력완료 → 태스크 생성의 단계별 흐름
◦
실수 발생 시 복구 방법
▪
완료 탭 활용 방식
◦
새로 만들기 버튼 사용 금지 안내
•
권장 매뉴얼 형식
◦
페이지 내 설명서 박스 형태 구성
◦
아이콘 + 번호 + 짧은 설명 조합
▪
예시
•
이 버튼 클릭 → 이 섹션에서 값 입력 → 입력완료 버튼 클릭 형식•
예상 사용자 질문 및 대응
◦
"눌렀는데 다 없어졌어요" 유형
▪
완료 탭 위치 및 복구 방법 안내 필요
◦
"새로 만들기 눌렀는데 연결이 안 돼요" 유형
▪
지정된 버튼을 사용해야 관계형이 연결된다는 점 설명 필요
◦
"다른 사람 것도 보여요" 유형
▪
필터 조건 및 로그인 계정 확인 가이드 필요
•
설계 원칙
◦
시스템 설계 완성도와 별개로, 사용자 사용법 이해도 미흡 시 시스템 효용 저하
◦
직관적이지 않은 부분은 반드시 문서화 대상
13. 향후 개발 로드맵
•
다음 단계 작업 목록
◦
Task Definition 기반 태스크 자동 생성 로직 완성
◦
워킹데이 계산 로직 고도화
▪
공휴일 반영 포함
◦
마지막 태스크 완료 시 아이템 자동 완료 처리 구현
◦
리스프레드 조회수 자동 수집
▪
유튜브 API 연동 중심
◦
OKR 관리 시스템 구축
◦
이슈 기반 워크플로우 설계
▪
클레임 처리 프로세스 등
•
자동화 우선순위 기준
◦
반복 빈도가 높은 작업
◦
수동 처리 시 오류 가능성이 높은 작업
◦
API 연동이 안정적인 서비스
▪
예시: 유튜브 우선, 인스타그램 릴스 후순위
•
테스트 일정 개념
◦
태스크 자동 생성 기능
▪
다음 주 중반 이후 테스트 가능
◦
충분한 테스트 이후 실제 운영 적용 예정
•
추가 학습 리소스 방향
◦
노션 관계형 데이터베이스
▪
관계형과 수식을 활용한 데이터 구조 설계 기초
◦
노션 버튼 자동화
▪
버튼 기반 워크플로우 자동화 심화
◦
프로젝트 관리 방법론
▪
WBS(Work Breakdown Structure)를 노션에 적용하는 방식
