개요
이 영상은 영상 제작 및 컨설팅 업무를 Notion 기반으로 체계화하는 과정을 상세히 다루는 컨설팅 세션 기록입니다. 주요 내용은 여러 병원 클라이언트를 관리하며 발생하는 복잡한 영상 제작 워크플로우(기획, 촬영, 편집, 검토, 업로드, 성과 분석, 정산)를 Notion 데이터베이스와 자동화를 활용하여 효율화하는 방법을 논의합니다. 특히, 클라이언트별 요구사항 차이, 데이터 추적의 어려움, 팀원 및 클라이언트와의 소통 문제를 해결하기 위한 구체적인 Notion 구조 설계와 Oopy를 활용한 클라이언트 대시보드 구축 방안을 모색합니다. 최종 목표는 검색 가능하고 협업이 용이하며, 클라이언트에게 투명한 정보 제공이 가능한 맞춤형 업무 관리 시스템을 구축하는 것입니다.
주요 학습 포인트
•
Notion 데이터베이스 설계를 통한 복잡한 영상 제작 워크플로우 관리 방법
•
클라이언트별 요구사항 및 과금 체계 차이를 반영한 시스템 구축 전략
•
데이터 자동화(API 연동)와 수동 입력의 장단점 분석 및 적용 방안 결정
•
Notion과 Oopy를 연동하여 안전하고 전문적인 클라이언트 공유 대시보드 구축 방법
•
실제 업무 프로세스 분석을 기반으로 Notion 데이터베이스 구조(클라이언트, 비디오, 스케줄, 월간/분기 리포트, 주제 아이디어 등) 및 속성 정의
•
Notion 내 관계형 데이터베이스, 롤업, 수식, 버튼 등 고급 기능 활용 예시
•
내부 팀원 협업 효율 증대 및 클라이언트 커뮤니케이션 개선 방안
요약
1. Google AI Studio 활용 영상 요약 테스트 (0:00 ~ 4:30)
1.
Google AI Studio 소개
•
기존 Gemini 2.0에서 2.5 버전으로 업데이트되었으며, 3월 25일 모듈이 추가되었고 4월 17일에는 'Thinking Mode'가 포함된 버전이 나옴.
•
주로 개발자들이 사용하는 도구이며, 일반 사용자용은 아님.
2.
영상 링크 직접 요약 시도
•
영상 URL을 직접 입력하여 요약 기능을 테스트함. (예시: 특정 병원 영상)
•
스크립트를 별도로 추출하지 않고 링크만으로 요약 가능성을 확인. (예: 매진밀키트 스크립트 추출 언급)
•
미리 만들어둔 프롬프트를 사용하여 요약을 시도함.
3.
테스트 결과 및 한계점
•
링크를 통한 데이터 로딩(토큰 사용량 확인)은 되었으나, 프롬프트 기반의 상세 요약은 제대로 작동하지 않음.
•
요약 결과에서 정확한 시간 정보 추출이 어려움. (릴리스와 비교하며 언급)
•
짧은 영상(4분 12초)임에도 불구하고 결과가 일부 시간대(40초)만 나타나는 등 불안정함을 보임.
•
실무 팁: 간단한 내용 파악에는 유용할 수 있으나, 체계적인 분석 및 시간대별 요약에는 한계가 있어 보임.
2. 클라이언트 관리 시스템 구축 필요성 및 요구사항 정의 (4:30 ~ 9:00)
1.
현재 관리 방식의 문제점
•
기존에는 Notion의 기본 템플릿 또는 Excel, 문자 등으로 클라이언트 프로젝트를 관리했으나, 비효율적임.
•
클라이언트(병원)마다 영상 제작 요구사항(예: 쇼츠 개수, 포함 여부) 및 정산 방식(금액, 기준)이 달라 복잡성이 증가함.
•
핵심 문제: 월별 작업 내역 기반의 정확한 정산 금액 산출 및 청구 근거 마련의 어려움.
2.
시스템 구축 목표
•
클라이언트별 작업 내역(올라간 영상 종류 및 개수 등)을 명확히 파악.
•
작업 현황을 클라이언트와 투명하게 공유할 수 있는 시스템 필요. (단, 내부 소통 내용은 제외)
•
단순 작업 기록 외에, 클라이언트에게 채널 성과(구독자, 조회수 변화 등) 데이터를 보여줄 수 있어야 함.
3.
데이터 공유 및 자동화 고려사항
•
클라이언트에게 공유할 데이터와 내부 관리용 데이터를 구분해야 함.
•
구독자 수, 조회수 등의 데이터를 자동으로 가져오는 것의 편의성 vs. 수동 입력의 정확성 및 관리 용이성 비교.
•
자동화 한계점: 구독자 1000명 이상 시 마지막 자리 숫자가 정확히 표시되지 않는 문제 언급. (단, 현재 클라이언트 채널 규모 고려 시 큰 문제 아닐 수 있음)
•
데이터 업데이트 주기(매일 vs. 주간)에 따른 효과 및 관리 부담 고려. (매일 업데이트 시 그래프가 지루해 보일 수 있음)
3. Notion 데이터베이스 구조 설계: 단일 DB vs. 다중 DB (9:00 ~ 13:30)
1.
데이터베이스 설계의 중요성
•
클라이언트별로 데이터를 완전히 분리할지(다중 DB), 하나의 DB에서 관리할지(단일 DB) 결정 필요.
2.
다중 DB 방식의 장단점
•
장점: 클라이언트 간 데이터 공유 위험 원천 차단 (데이터 격리).
•
단점: 구축 및 유지보수가 복잡해짐. (컨설턴트 본인의 복잡한 다중 DB 시스템 예시 언급)
3.
단일 DB 방식의 장단점
•
장점: 구조가 상대적으로 단순하고 관리 용이. 관계형 데이터베이스를 활용하여 필요한 정보만 필터링하여 보여주기 용이.
•
단점: 설계 오류 시 클라이언트 간 데이터가 잘못 공유될 수 있는 잠재적 위험 존재.
4.
결정: 단일 DB 기반 설계
•
현재 클라이언트의 요구사항과 프로젝트 규모(병원당 월 영상 개수 등)를 고려했을 때, 단일 메인 DB를 사용하는 것이 더 적합하다고 판단.
•
하나의 DB 내에 모든 클라이언트의 영상 정보(레코드)를 저장하고, 각 레코드를 해당 클라이언트와 연결(관계형 속성).
•
클라이언트에게 공유 시에는 필터링된 뷰를 사용하여 해당 클라이언트의 데이터만 보여주는 방식 채택.
•
실무 팁: 레코드 수가 과도하게 많지 않다면(월별 클라이언트당 10개 내외), 단일 DB 방식이 효율적일 수 있음.
4. Oopy 연동 필요성 및 보안 강화 (13:30 ~ 17:00)
1.
Oopy 사용의 필수성 강조
•
Notion 데이터를 클라이언트에게 안전하고 깔끔하게 공유하기 위해 Oopy 사용이 필수적이라고 강조.
2.
Oopy 사용 이유
•
데이터 보안: Notion 페이지를 웹에 게시해야 Oopy 연동이 가능한데, Oopy는 Notion의 복잡한 내부 구조(DB 속성, 여러 탭 등)를 숨기고 선택한 정보만 노출시킴.
•
사용자 경험: 클라이언트에게는 정제되고 보기 좋은 인터페이스(예: 특정 탭 하나만 노출)를 제공하여 혼란을 줄임.
•
접근 제어: Oopy 페이지 URL에 난수값을 추가하여 추측하기 어려운 고유 주소를 생성함으로써, 링크를 아는 사람만 접근 가능하도록 보안 강화. (페이지 ID 뒤에 임의의 문자열 추가 방식 예시)
3.
클라이언트별 페이지 생성 방식
•
클라이언트가 신규로 추가될 때마다, Oopy를 통해 해당 클라이언트 전용 페이지(고유 URL 포함)를 생성하여 제공.
•
실무 팁: 각 클라이언트 페이지 URL에 예측 불가능한 식별자를 넣어 보안을 강화하는 것이 중요.
5. 상세 워크플로우 분석: 기획 및 촬영 단계 (17:00 ~ 23:00)
1.
워크플로우 분석의 중요성
•
최적화된 Notion 시스템 설계를 위해 현재 업무 프로세스를 상세히 파악하는 것이 중요함. (헤드헌팅 업체 워크플로우 분석 예시 언급)
2.
영상 제작 시작 프로세스
•
촬영 일정 협의: 클라이언트(원장님)와 직접 다음 촬영 일정을 조율.
•
영상 촬영: 정해진 날짜에 병원에 방문하여 한 번에 여러 편(예: 4개)의 영상을 촬영.
•
원본 업로드: 촬영한 원본 영상 파일을 NAS(네트워크 저장소)에 업로드.
3.
주제 아이디어 수집 및 대본 작성 (병행/선행)
•
자료 수집: 댓글, 타 채널 영상 등을 참고하여 영상 주제 아이디어를 수집. (수시로 진행)
•
주제 정리: 수집된 아이디어 중 괜찮은 것을 Notion 등에 정리.
•
대본 작성: 클라이언트에 따라 대본 작성 여부가 다름. 대본 작성이 필요한 경우, 자료 수집 후 대본 작성 단계 추가.
•
실무 팁: 대본 작성 안 하는 경우, 촬영 시 어떤 주제로 찍을지에 대한 사전 협의 필요.
6. 상세 워크플로우 분석: 편집 및 파일 관리 단계 (23:00 ~ 28:30)
1.
편집 프로세스
•
러프컷 편집: 직원이 NAS의 원본 영상을 기반으로 1차 편집(컷 편집) 진행. (어떤 직원이 할지는 병원별로 다를 수 있음)
•
자막 작업: Vrew 등의 도구를 사용하여 자막 생성 및 편집. (Final Cut Pro 사용 언급, Vrew는 보조적 사용 가능성)
•
최종 편집: 러프컷과 자막을 바탕으로 최종 영상 편집 (효과, 색보정 등). 이 단계에서 최종본 완성.
2.
파일 관리 방식 (Final Cut Pro 기준)
•
Final Cut Pro는 프로젝트 파일 내에 원본 미디어 파일 사본을 포함하는 방식(라이브러리/이벤트)으로 작동.
•
작업 완료 후, 최종 프로젝트 파일(라이브러리) 자체를 NAS에 업로드하고, 처음에 올렸던 개별 원본 영상 파일은 삭제 가능. (저장 공간 효율화)
•
중요 참고사항: Adobe Premiere Pro와 달리, Final Cut Pro는 원본 파일 경로가 사라져도 프로젝트 파일만 있으면 편집 가능 (단, 원본 화질 이슈 있을 수 있음). NAS 속도(업/다운로드 70MB/s 정도) 언급.
3.
영상 제목 결정
•
영상 제목은 주로 편집하는 사람(직원 또는 본인)이 영상 내용을 보고 결정. 초기 단계에서는 크게 중요하지 않으며, 내용 파악 가능한 수준으로 정함.
7. 상세 워크플로우 분석: 검토, 업로드, 썸네일 제작 단계 (28:30 ~ 33:00)
1.
검토 (컨펌) 프로세스
•
최종 편집본이 완성되면, 클라이언트에게 바로 보내지 않고 내부 검토(직원 -> 대표)를 먼저 거침.
•
대표가 컨펌하면, 클라이언트(원장님)에게 최종본을 보내 컨펌 요청. (현재는 카톡 등으로 진행되어 진행 상황 추적 어려움)
•
클라이언트 피드백이 있으면 재편집 후 다시 컨펌 요청.
•
핵심 문제: 현재 방식으로는 대표가 직원에게 받은 최종본을 확인했는지, 클라이언트에게 전달했는지 여부를 알기 어려움.
2.
썸네일 제작
•
최종본 컨펌이 완료되면 썸네일 제작. (영상 편집과 동시에 진행되기도 함)
•
대표가 카피라이팅(썸네일 문구 등)을 정해주는 경우가 많음 (직원의 병목 현상 방지).
•
썸네일은 영상당 1개를 기본으로 제작. (유튜브 3개 업로드 기능 언급)
3.
최종 업로드
•
클라이언트 컨펌 완료 및 썸네일 제작 후 유튜브에 영상 업로드.
•
최종 결과물(영상 파일 또는 프로젝트 파일)을 NAS에 업로드하여 보관.
8. 스케줄 관리: Google Calendar 활용 및 한계점 (33:00 ~ 41:00)
1.
현재 스케줄 관리 방식 (Google Calendar)
•
촬영 일정, 영상 업로드 예정일 등을 Google Calendar에 기록하여 직원과 공유.
•
캘린더 항목 이름에 규칙 사용 (예: 병원명 4-6 -> 4번째 촬영분의 6번째 영상). 색상으로 구분하기도 함.
•
파란색은 업로드 예정일 등을 표시.
2.
Google Calendar의 문제점
•
정보 업데이트 지연: 대표가 일정을 변경하거나 추가해도 즉시 반영/공유되지 않아 직원이 혼란스러워함 (예: 업로드 날짜 변경, 특이사항 미공유).
•
업무 파악의 어려움: 직원은 캘린더를 보고 주간/월간 업무량을 파악하는데, 정보가 누락되거나 갑자기 변경되면 예측 가능성이 떨어짐.
•
분산된 정보: 영상 제작 상태와 일정이 분리되어 관리됨.
3.
개선 방향: Notion Calendar 활용
•
Google Calendar 대신 **Notion Calendar (데이터베이스 캘린더 뷰)**로 전환 제안.
•
영상 상태 관리와 일정을 한 곳에서 연동하여 관리 가능.
•
모든 변경 사항이 실시간으로 반영되어 팀 내 투명성 및 예측 가능성 향상.
•
실무 팁: Notion으로 전환 시, 기존 캘린더 사용 습관을 바꾸는 것에 대한 초기 저항이 있을 수 있으나 장기적으로 효율적임.
9. Notion DB 설계: 프로젝트 vs. 스케줄 분리 및 관계 설정 (41:00 ~ 48:30)
1.
핵심 개념: 프로젝트와 스케줄 분리
•
하나의 영상 제작 건(비디오/프로젝트)과 관련된 개별 활동(스케줄/태스크 - 촬영, 업로드, 회의 등)을 구분하여 관리해야 함.
•
하나의 상태값만 바꾸는 방식(예: 촬영 -> 편집 중 -> 완료)은 과거 기록 추적이 어렵고 유연성이 떨어짐.
2.
데이터베이스 구조 제안
•
Clients DB: 클라이언트 정보 관리.
•
Videos DB: 개별 영상(프로젝트) 정보 관리 (상태, 유형, 담당자, 결과물 URL 등).
•
Schedule DB: 촬영, 업로드, 미팅, 휴가 등 날짜 기반 이벤트 관리.
3.
관계 설정
•
Videos DB는 Clients DB와 관계를 맺음.
•
Schedule DB는 Clients DB (어떤 클라이언트 관련 일정인지) 및 Videos DB (어떤 영상 관련 일정인지)와 모두 관계를 맺음. (단, 영상과 무관한 일정은 클라이언트만 연결)
•
중요 참고사항: 이 구조를 통해 특정 영상의 진행 상태와 관련 일정을 함께 추적하고, 클라이언트별 전체 일정을 관리할 수 있음.
4.
초기 속성 정의 (예시)
•
Videos DB: 상태(시작 전, 편집 중...), 구분(롱폼/쇼츠), 클라이언트(관계형), 업로드 예정일, 유튜브 URL 등.
•
Schedule DB: 날짜, 유형(촬영/업로드/미팅/휴가), 클라이언트(관계형), 비디오(관계형), 관련 메모 등.
10. Videos DB 상세 설계: 상태값 및 주요 속성 정의 (48:30 ~ 55:30)
1.
상태값 상세 정의 (워크플로우 기반)
•
서로 인지해야 하는 핵심 단계를 중심으로 상태값 정의:
◦
시작 전 (영상 편집 시작 전 모든 단계 포함)
◦
컷편집 중
◦
컷편집 완료
◦
최종본 완성 (내부 검토 대기 상태)
◦
컨펌 중 (클라이언트에게 발송 후 대기)
◦
(원장님) 피드백/재편집 필요
◦
컨펌 완료
◦
유튜브 업로드 완료
•
색상 구분: 각 상태별로 색상을 지정하여 시각적 구분 용이하게 설정.
2.
주요 속성 추가
•
구분 (선택 속성): 롱폼 / 쇼츠
•
카피라이팅 필요 (체크박스): 대표가 직접 카피라이팅(썸네일 문구 등)을 해야 하는지 여부 표시.
•
정산 확인 (체크박스): 해당 영상 건에 대한 정산 완료 여부 표시 (추후 위치 변경 논의됨).
3.
쇼츠 관리 방안
•
쇼츠 영상이 어떤 롱폼 영상에서 파생되었는지 연결하는 것은 관리 복잡성을 높일 수 있어, 별도 관리하기로 결정. (장기적인 추적 필요성 낮음)
•
쇼츠도 Videos DB에 별도 레코드로 생성하고 구분 속성으로 식별.
11. Schedule DB 상세 설계 및 캘린더 뷰 구현 (55:30 ~ 1:01:30)
1.
스케줄 유형 정의
•
업로드 (롱폼), 업로드 (쇼츠), 촬영, 미팅, 휴가 등 필요한 일정 유형 정의. (선택 속성 또는 태그 활용)
2.
스케줄 이름 규칙 정의
•
기존 Google Calendar 방식 개선 제안: 촬영날짜(YYMMDD) 클라이언트명 촬영 (N편) 형식 (예: 0501 뷰티렐라 촬영 (4편)) -> 직관성 및 검색 용이성 증대.
•
업로드 일정 이름도 유사한 규칙 적용 가능 (예: 0506 뷰티렐라 1/4 업로드).
3.
Notion 캘린더 뷰 활용
•
Schedule DB를 캘린더 레이아웃으로 보면 Google Calendar와 유사한 시각적 일정 관리 가능.
•
캘린더에 표시될 정보 선택 가능 (예: 스케줄 유형, 클라이언트명 등).
•
장점: Notion 내에서 모든 정보(상태, 일정)를 통합 관리 가능.
4.
관계 설정 활용
•
캘린더의 각 항목(스케줄)이 관련 Video 레코드와 연결되어 있어, 클릭 시 해당 영상의 상세 정보로 바로 이동 가능.
12. 성과 리포팅 DB 설계: 월간/분기 보고서 (1:01:30 ~ 1:15:30)
1.
리포팅 요구사항 재확인
•
클라이언트에게 월별 또는 분기별 채널 성과 요약 보고 필요.
•
주요 지표: 조회수, 평균 시청 지속 시간(%), 구독자 수, 노출수, 노출 클릭률 등.
•
중요: 월별 데이터를 분리해서 보는 것이 중요 (단순 누적 데이터 X).
2.
자동화의 한계 및 수동 입력 결정
•
Notion API나 연동 서비스(Make 등)는 주로 채널 전체의 누적 데이터를 가져오므로, 특정 월의 성과만 정확히 분리하기 어려움.
•
해결책: 유튜브 스튜디오에서 '게시 날짜' 필터를 사용하여 해당 월에 게시된 영상들의 성과 데이터를 수동으로 복사하여 Notion에 붙여넣기.
3.
리포팅 DB 구조 제안
•
Monthly Reports DB: 월별 성과 기록.
◦
속성: 보고 월(날짜 또는 텍스트), 클라이언트(관계형), 평균 조회율(%), 조회수, 시청 시간, 구독자 증감, 노출수, 노출 클릭률 등 (유튜브 스튜디오 컬럼과 일치).
•
Quarterly Reports DB: 분기별 성과 요약.
◦
Monthly Reports DB와 관계를 맺고, 롤업(Rollup) 기능을 사용하여 3개월치 데이터 합산 또는 평균 계산.
4.
데이터 입력 프로세스
•
매월 초(예: 6월 1일)에 지난달(5월) 데이터를 유튜브 스튜디오에서 복사하여 Monthly Reports DB 해당 월 레코드에 붙여넣기.
•
실무 팁: Notion DB 컬럼 순서와 이름을 유튜브 스튜디오와 동일하게 맞춰 놓으면 복사/붙여넣기가 용이함.
13. 정산 관리 방식 재정의 및 Monthly Reports DB 연동 (1:15:30 ~ 1:23:30)
1.
정산의 복잡성 재인식
•
영상 제작 완료 시점과 실제 정산(청구/입금) 시점이 다를 수 있음 (예: 월말 기준으로 일부 영상을 다음 달 정산에 포함시키는 경우).
•
영상별로 정산 여부를 추적해야 할 필요성 제기됨.
2.
정산 관리 방식 결정
•
Videos DB: 개별 영상 레코드에 정산 포함 여부 체크박스 유지. (이번 달 청구 대상인지 표시)
•
Monthly Reports DB: 실제 청구 및 입금 관리를 이 DB에서 수행.
◦
결제 금액 (숫자 속성): 해당 월에 청구할 총 금액 (VAT 포함/미포함 여부 명확히).
◦
입금 확인 (체크박스): 클라이언트로부터 입금 완료 여부.
◦
세금계산서 발행 (체크박스): 세금계산서 발행 완료 여부.
3.
워크플로우
•
매월 말 또는 초, Videos DB에서 이번 달 정산에 포함될 영상들의 정산 포함 여부 체크.
•
Monthly Reports DB에서 해당 월 레코드에 총 결제 금액 입력.
•
세금계산서 발행 및 입금 확인 시 해당 체크박스 업데이트.
•
이점: 제작 완료와 정산 주기의 불일치를 관리할 수 있으며, 월별 총 청구/수금 현황 파악 용이.
14. 주제 아이디어(타이틀) 관리 DB 설계 및 입력 방식 (1:23:30 ~ 1:32:00)
1.
Titles DB 설계
•
영상 주제 아이디어를 관리하기 위한 별도 DB 생성.
•
주요 속성:
◦
주제명 (텍스트)
◦
클라이언트 (관계형): 어떤 클라이언트와 관련된 주제인지 연결.
◦
구분 (선택 속성): 필요시 주제 카테고리 (예: 시술 종류, 질환 정보 등) 분류. 재생목록 개념으로 활용 가능.
◦
사용 여부 (상태 또는 필터링): 영상 제작에 사용되었는지 여부 표시. (별도 상태값 대신 그룹화/필터링으로 관리 가능)
2.
데이터 입력 방식 논의
•
개별 입력: 아이디어가 생길 때마다 DB에 직접 추가.
•
일괄 입력: 외부 소스(텍스트 파일, 엑셀, ChatGPT 출력 등)에서 아이디어 목록을 복사하여 Notion DB에 붙여넣기.
◦
중요: Notion DB에 텍스트 목록을 붙여넣으면 각 줄이 개별 레코드(페이지)로 생성됨. (엑셀에서 여러 셀 복사 시에도 동일)
◦
실무 팁: Notion 페이지에 불렛 포인트 등으로 정리한 목록을 페이지 전환 기능(Cmd/Ctrl + Option + 9)으로 DB 레코드로 변환 후, 한 번에 DB로 이동시키는 방법도 유용.
3.
활용 방안
•
클라이언트별 주제 아이디어 뱅크로 활용.
•
미사용 주제 목록을 필터링하여 다음 촬영 기획 시 참고.
•
필요시 클라이언트에게 공유하여 주제 선정 과정에 참여 유도 가능.
15. 내부 대시보드 설계 및 썸네일 자동화 구상 (1:32:00 ~ 1:46:00)
1.
내부 작업 현황 대시보드 구성
•
Videos DB 보드 뷰: 상태값(Status)을 기준으로 칸반 보드 형태로 시각화. 영상 제작 파이프라인 현황 파악 용이. 클라이언트별 그룹화 가능.
•
Schedule DB 캘린더 뷰: 월간/주간 일정 확인.
•
작업 완료 뷰 (Videos DB): 완료된 영상 목록 확인 (갤러리 뷰 활용 가능성).
•
정산 필요 뷰 (Videos DB): 정산 포함 여부가 체크되지 않은 완료 영상 필터링.
2.
데이터 입력 편의성 개선
•
템플릿 버튼 등을 활용하여 Schedule, Title 등 신규 레코드 생성 간소화.
•
데이터 입력 흐름 정의: 스케줄 생성 -> (촬영 후) 관련 비디오 레코드 생성 및 기본 정보 입력 -> 편집 진행하며 상태 업데이트 및 최종 제목 입력.
3.
썸네일 관리 및 자동화 방안
•
필요성: 클라이언트에게 공유하는 결과 리포트(갤러리 뷰 등)에서 썸네일을 보여주면 가독성 향상.
•
수동 방식: 썸네일 이미지를 Videos DB에 직접 업로드 (번거로움).
•
자동화 방식 제안:
1.
Videos DB에 확인 버튼(Notion 버튼 기능) 추가.
2.
이 버튼 클릭 시, 연결된 자동화 서비스(Make.com 등)가 트리거됨.
3.
자동화 시나리오: 해당 비디오의 유튜브 URL에서 썸네일 이미지 URL 추출 -> 썸네일 이미지 다운로드 -> Notion Videos DB 해당 레코드의 썸네일 속성(파일 타입)에 업로드 및 페이지 본문에 임베드.
4.
동시에 확인 체크박스도 체크되도록 설정.
•
결정: 자동화 방식이 장기적으로 효율적이므로 구현 고려. (API 연동 필요)
16. 최종 정리 및 다음 단계 (1:46:00 ~ End)
1.
구축될 시스템 요약
•
주요 DB: Clients, Videos, Schedule, Monthly Reports, Quarterly Reports, Titles.
•
핵심 기능: 워크플로우 관리, 일정 관리, 성과 리포팅, 정산 관리, 주제 관리.
•
클라이언트 공유: Oopy 연동을 통한 맞춤형 대시보드 제공.
•
자동화: 썸네일 자동 가져오기 등 구현 예정.
2.
데이터 마이그레이션 계획
•
과거 데이터 전체를 옮기는 것은 비효율적이므로, 최근 데이터부터 새로 입력하는 것을 권장 (예: 2025년 데이터부터).
•
특히 Schedule 데이터는 과거 기록 입력이 어려울 수 있음.
3.
다음 단계
•
컨설턴트가 설계된 Notion 구조 및 기본 자동화 설정을 준비.
•
다음 세션에서는 클라이언트가 보게 될 Oopy 페이지를 구체적으로 디자인하고 구축하는 작업 진행.
•
클라이언트는 시스템 사용을 위한 데이터 준비 (최근 프로젝트 정보 등).
