목차
컨설팅 개요
•
ExCorp는 기술 기반 스타트업으로, 버추얼 프로덕션·실시간 가상공간 합성·몰입형 미디어아트·소프트웨어 개발·콘텐츠 제작·솔루션 구축을 함께 수행하는 조직이다.
◦
조직 구성은 본부와 팀으로 나뉘어 있으나 실제 업무는 부서 경계를 넘나드는 프로젝트형 협업으로 진행됨
◦
대표와 실무진은 노션을 활용한 전사 업무 공유·프로젝트 관리·문서화 체계를 구축하고자 컨설팅을 요청함
•
핵심 문제는 “기술과 실행 역량은 높지만, 업무 흐름·문서화·공유 기준·DB 구조가 정리되지 않아 소통 오해와 관리 병목이 발생한다”는 점이다.
◦
기존 도구 흐름: 노션 → 두레이 → 팀즈 → 다시 노션
◦
기존 한계: 페이지 공유나 채팅 수준에 머물러 전사 프로젝트·팀 프로젝트·개인 업무·HR·결재·근태·솔루션 CS를 한 시스템으로 구분하는 기준 부재
•
컨설팅의 최종 방향은 노션을 전사 DB·대시보드·AI 질의 기반의 백오피스/지식 허브로 쓰고, 출결·결재·권한 분기처럼 입력 UX와 로직이 중요한 영역은 별도 프론트엔드 또는 중간 DB를 붙여 처리하는 하이브리드 구조로 정리되었다.
◦
이번 회차는 완성형 설계가 아니라 진단 회차에 가까움
◦
핵심 산출 방향은 ExCorp의 업무 흐름을 먼저 “프로젝트 단위 워크플로우”로 해부하는 것
◦
다음 컨설팅을 위한 사전 과제는 대표 주도 프로젝트별 업무 흐름 도식화
컨설팅 전체 흐름 분석
전체 진행 구조
•
컨설팅은 크게 여섯 흐름으로 전개되었다.
1.
초기 맥락 확인
•
ExCorp의 사업 성격, 조직 구조, 기존 협업 도구 사용 이력, 노션 도입 목적 확인
2.
전사 프로젝트 관리 방향 제시
•
부서별 시스템보다 프로젝트 중심의 전사 관리 구조가 적합하다는 판단 제시
3.
노션 DB 구조와 한계 진단
•
글로벌 DB, 마스터 DB, 관계형, 롤업, 권한, HR/CRM/ERP 적합성 설명
4.
하이브리드 아키텍처 제안
•
노션은 DB·대시보드·AI 검색/질의 허브로 두고, 직원용 입력 화면은 바이브 코딩 프론트엔드로 분리하는 방향 제안
5.
업무 워크플로우 분석 시연
•
헤드헌팅, 의류 제작, VP 촬영/제작 프로세스 예시를 통해 업무 흐름 도식화 방식 시연
6.
다음 단계 합의
•
대표가 주력 프로젝트를 선택하고, 각 프로젝트의 실제 업무 흐름을 순서도로 정리해 오면 이후 4회 컨설팅에서 DB 구조와 대시보드 설계 진행
고객 이해도 변화
•
컨설팅 초반에는 “노션 DB가 웹 DB처럼 동작할 것”이라는 기대가 강했음
•
중반 이후 관계형 과부하·권한 구조·노션 API 제한·프론트 분리 필요성을 이해함
•
최종적으로 “노션 백단 + 별도 프론트” 전략으로 수렴함
합의 도달 방식
•
단순 설명이 아니라 실제 구조 시연 중심으로 합의 형성
◦
디렉터의 실제 노션 프로젝트 매니저 구조 시연
◦
외부 사례 기반 업무 흐름 도식화 시연
◦
ExCorp의 VP 업무를 즉석에서 프로세스 맵으로 해부
•
고객은 “구조화가 먼저”라는 필요성을 직접 체감함
고객 성숙도 진단
•
문제 인식
◦
높음
◦
정리·공유·구조화가 핵심 병목이라는 점을 인지하고 있음
•
DB 개념 이해
◦
중간
◦
일반 RDB 개념은 있으나 노션 DB의 관계형·권한·성능 제약은 새롭게 학습 중
•
업무 프로세스 문서화 수준
◦
낮음
◦
대표와 실무진의 머릿속에는 있으나 공식 워크플로우로 정리된 적이 거의 없음
•
실행 가능성
◦
높음
◦
웹 개발자 출신 실무자가 있고, 프론트엔드 제작 역량이 있어 하이브리드 구조 실현 가능성이 높음
•
즉시 필요한 것
◦
DB 생성이 아니라, 대표 주도의 핵심 프로젝트별 업무 흐름 도식화
핵심 논의 사항
•
ExCorp는 부서별 독립 업무보다 전사 프로젝트 단위 관리가 더 적합함
•
노션은 HR·CRM·ERP 전체를 대체하기보다 프로젝트 관리·문서화·대시보드·AI 질의 허브로 쓰는 것이 적합함
•
근태·결재·권한 분기처럼 사용자별 화면·로직·중복 입력 방지가 필요한 기능은 노션 단독 구현보다 별도 프론트엔드가 적합함
•
관계형은 정보를 “보여주기 위해” 무분별하게 연결하면 성능 문제가 생기므로, 가공·집계 목적이 있는 관계형만 유지해야 함
•
ExCorp의 시스템 설계는 DB부터 만들면 실패하고, 대표 주력 프로젝트의 실제 업무 흐름을 먼저 순서도로 해부해야 함
•
VP 촬영/제작 업무는 현재 주력 비중이 20% 수준이므로, 전용 DB를 과도하게 만들기보다 프로젝트/태스크 템플릿 또는 상태값 중심으로 범용화하는 방향이 우선 적합함
•
솔루션 구축·교육·CS는 VP 촬영과 별도 프로젝트 템플릿으로 분리하는 것이 적합함
•
다음 컨설팅 전까지 대표가 주력 프로젝트 3개 내외를 선정하고, 각 프로젝트의 업무 순서·담당 팀·산출물·결정 포인트를 정리해야 함
구간별 심층 요약
1. 현장 세팅과 관계 형성
고객 현황
•
초반에는 HDMI, 무선 스위칭, 장비 연결, 자리 배치, 이동 동선, 간단한 안부 등 본격 컨설팅 전 현장 세팅과 라포 형성이 진행됨
•
ExCorp 측은 기술 기반 스타트업으로, 장비·공간·시연 환경을 직접 운영하는 조직임이 대화 분위기에서 드러남
•
컨설팅은 단순 온라인 미팅이 아니라 실제 현장 방문 형태였고, 이후 가상 스튜디오·버추얼 프로덕션 시연까지 이어짐
분석 및 진단
•
이 구간 자체는 본 컨설팅 내용은 아니지만, ExCorp가 “물리적 스튜디오·장비·실시간 시연”을 기반으로 하는 회사라는 점을 이해하는 데 중요함
•
이후 VP 업무 흐름을 분석할 때 “촬영 전 장비 세팅, 기술 테스트, 리허설, 본 촬영, 포스트 프로덕션”이 핵심 업무 단계로 등장하는데, 초반의 장비 세팅 대화가 그 맥락을 뒷받침함
제안 솔루션
•
직접적인 솔루션 제안은 없었음
•
다만 현장 기반 사업자는 문서 시스템에서도 단순 업무 관리가 아니라 장비·공간·촬영·리허설·결과물 전달까지 연결되는 프로젝트형 운영 구조가 필요하다는 전제가 형성됨
핵심 인사이트
컨설턴트: "그러면 지금 이게 조직도인 거잖아요. 근데 여기서 본부에서 본부까지 건너 뛰면서 업무가 프로젝트가 진행이 되는 건가요?"
2. ExCorp의 핵심 문제 정의: 기술은 강하지만 정리가 약한 조직
고객 현황
•
ExCorp는 영상·음성·소프트웨어·실시간 가상공간 합성·몰입형 미디어아트·언리얼 기반 콘텐츠 등 고난도 기술을 다루는 스타트업임
•
구성원들은 십몇 년 차 경력의 전문가들이며 기술 역량은 높지만, 문서화와 업무 공유가 약함
•
업무 내용이 파편화되어 있고, 부서별로 자세히 알 필요는 없더라도 서로 어떤 일을 하는지, 같이 일할 때 어떻게 진행해야 하는지에 대한 공유 체계가 부족함
•
기존 백오피스 구축 시도는 노션 → 두레이 → 팀즈 등으로 이어졌으나, 팀즈는 사실상 “전문적인 카톡”처럼 쓰이고 있으며 매뉴얼과 트래킹이 부족함
분석 및 진단
•
문제의 본질은 도구 선택이 아니라 업무 구조화와 공유 기준 부재임
•
고객은 “노션을 쓰면 해결될 것”으로 접근했지만, 실제로는 노션 자체보다 어떤 데이터를 어디에 모으고, 어떤 단위로 관계를 맺고, 어떤 뷰로 업무를 볼 것인가가 핵심임
•
컨설턴트는 ExCorp가 부서별로 완전히 분리된 대기업형 구조가 아니라, 부서 경계를 넘어 여러 사람이 동시에 일하는 언더백 기업형 프로젝트 조직에 가깝다고 판단함
제안 솔루션
•
부서별 시스템보다 전사 프로젝트 관리 구조로 설계하는 것이 적합함
•
모든 업무의 중심을 프로젝트로 두고, 프로젝트 하위에 산출물·참고자료·회의록·스크립트·일정·태스크를 연결해야 함
•
업무 흐름을 프로젝트 단위로 정규화하고, 대표와 팀장이 전체 진행 상황을 볼 수 있는 대시보드를 구성해야 함
핵심 인사이트
컨설턴트: "부서 형태보다는 프로젝트 단위가 가장 잘 어울리겠네요."
3. 전사 프로젝트 관리 구조 제안
고객 현황
•
ExCorp는 VP 사업본부, 콘텐츠 제작본부, 소프트웨어 개발, R&D 등으로 나뉘어 있으나 실제 업무는 협업형 프로젝트가 많음
•
고객은 노션 AI와 업로드 기능을 활용해 DB 구조화를 시도하고 있고, 글로벌 DB 3.0 구조도 적용 중임
•
전사 프로젝트와 팀 프로젝트를 나누고, 태스크와 관계를 맺는 구조를 만들어 보고 있지만 “맞는지 계속 체킹하는 중”이라고 말함
분석 및 진단
•
컨설턴트는 프로젝트 매니저 구조를 보여주며, 글로벌 DB의 Projects·Tasks·Resources·Script Vault·Summary·Schedule 등이 프로젝트 페이지 안에서 어떻게 모이는지 설명함
•
핵심은 “프로젝트 페이지 하나를 열면 그 프로젝트와 관련된 전사본, 요약, 일정, 태스크, 산출물, 참고자료, 회고가 모두 모이는 구조”임
•
회사 규모가 크지 않고 부서가 공조화되어 있다면, 부서별 독립 시스템보다 하나의 전사 프로젝트 DB를 중심으로 보는 것이 효율적임
제안 솔루션
•
ExCorp는 최소 3계층 구조가 필요함
1.
상위 프로젝트
2.
서브 프로젝트 또는 업무 묶음
3.
태스크
•
단, 모든 프로젝트에 전용 DB를 만들 필요는 없고, 주력 업무인지 여부에 따라 전용 템플릿·범용 태스크·상태값 방식 중 선택해야 함
•
프로젝트별 대시보드는 관리자용 전체 뷰와 담당자용 상세 뷰를 분리해야 함
핵심 인사이트
컨설턴트: "모든 회사들은 무조건 다 프로젝트 베이스로 돌아가잖아요."
4. 글로벌 DB·마스터 DB·로컬 DB 개념과 ExCorp 적용
고객 현황
•
고객은 글로벌 DB, 마스터 DB, 로컬 DB 개념을 문서로 정리하며 학습 중임
•
전사에서 다 쓰는 데이터베이스는 글로벌 DB로 두고, MasterDB 로컬은 자기들끼리 사용하는 구조를 고민하고 있음
•
대표는 글로벌 DB에 관리자만 수정 권한을 주고, 마스터 DB는 관계형을 단방향으로만 걸어 가져와 쓰는 거버넌스를 만들고 있음
분석 및 진단
•
고객의 방향성 자체는 맞지만, 아직 “어떤 업무를 글로벌로 둘지, 어떤 업무를 로컬/마스터로 둘지”는 실제 업무 흐름 분석 없이는 결정하기 어려움
•
컨설턴트는 먼저 조직도와 업무별 DB 리스트를 만들고, 관계 구조를 정리하는 단계가 필요하다고 설명함
•
DB 구조는 업무 흐름의 결과이지 출발점이 아님
제안 솔루션
•
전사 공통 객체는 글로벌 DB로 둠
◦
예: PROJECT, TASK, RESOURCE, SCRIPT VAULT, SUMMARY
•
특정 프로젝트나 업무 영역에서만 쓰는 독립 객체는 프로젝트 하위 마스터 DB로 둠
•
페이지 내부 임시 목록이나 체크리스트는 로컬 DB 또는 페이지 본문 체크리스트로 처리함
•
MASTER DB 원본과 직접 관계를 맺거나 원본 구조를 오염시키는 것은 피해야 함
핵심 인사이트
컨설턴트: "이 글로벌 DB는 모든 모션에서 다 끌고 가서 쓰는 애들인 거예요. 그러니까 전역 변수라고 보시면 돼요."
5. HR·결재·근태 시스템의 노션 적합성 진단
고객 현황
•
고객은 휴가 신청, 결재 라인, 팀장급 결재 업무, 출근·퇴근 체크, 개인 업무 등록, 멤버 정보 자동 연결 등을 노션으로 구현하려고 했음
•
웹 개발자 관점에서는 로그인 사용자 정보를 기준으로 멤버 정보·소속·전화번호 등을 자동으로 가져오는 테이블 조인 방식을 기대함
•
실제 노션에서는 관계형 멤버를 다시 선택해야 하거나, 버튼·수식·자동화를 써야 해서 불편하다고 느낌
분석 및 진단
•
노션은 기본 철학이 “공유”에 가깝기 때문에 사용자별 권한 분기, 같은 페이지에서 역할별로 다른 데이터를 보여주는 구조가 일반 웹 시스템보다 불편함
•
CRM·ERP·HR처럼 권한·금액·정밀 로직·입력 검증이 중요한 시스템은 노션으로 90%까지 구현 가능해도, 남은 10%가 실제 운영에서 치명적일 수 있음
•
멤버 DB와 출결 레코드를 관계형으로 매일 연결하면 한 사람에게 수백~수천 개 관계가 누적되어 속도 저하가 발생할 수 있음
제안 솔루션
•
HR·근태·결재는 노션 단독 구현보다 별도 프론트엔드와 노션 DB를 연결하는 방식이 적합함
•
출결처럼 매일 쌓이는 로그성 데이터는 멤버 DB와 깊은 관계형으로 묶기보다, 필요한 멤버 정보를 레코드에 스냅샷처럼 입력하는 방식이 나음
•
월간 리포트처럼 집계가 필요한 경우에만 월 단위 멤버 관계를 맺는 방식은 가능함
•
팀원이 노션을 충분히 잘 다루지 못한다면 직원용 화면은 단순 프론트로 만들고, 관리자와 AI 분석은 노션에서 수행하는 구조가 현실적임
흔히 하는 실수
•
직원별 권한 분기를 노션 페이지 하나에서 해결하려고 하는 것
•
멤버 DB에 모든 로그성 레코드를 관계형으로 계속 연결하는 것
•
HR·결재·CRM·ERP를 노션만으로 완전 대체하려고 하는 것
•
관계형을 “정보 가져오기” 용도로만 남발하는 것
핵심 인사이트
컨설턴트: "노션의 기본 정책이 공유예요. 모든 사람이 다 똑같이 본다라는 게 깔려있거든요."
6. 관계형·롤업·성능 이슈 진단
고객 현황
•
고객은 일반 RDB처럼 PK·FK·조인 개념을 기대하며 노션 DB를 이해하려 했음
•
노션에서 관계형을 통해 멤버 정보를 가져오고, 롤업으로 소속이나 개인 정보를 표시하는 구조를 만들고 있었음
•
테이블을 여러 개로 나누고 조인해 작은 뷰를 만드는 RDB식 설계에 익숙했기 때문에, 노션에서 컬럼을 많이 넣을지 DB를 쪼갤지 고민함
분석 및 진단
•
노션은 에어테이블이나 전통 RDB처럼 조인 중심으로 빠르게 데이터를 가져오는 도구가 아님
•
관계형은 가능하지만, 관계가 많아질수록 페이지 로딩·롤업 계산·뷰 렌더링에 부담을 줌
•
속도 문제의 핵심은 “로딩되는가”임
◦
마스터 DB에서 모든 속성과 관계를 한꺼번에 보면 느려짐
◦
대시보드에서 필요한 속성만 보여주면 상대적으로 괜찮음
제안 솔루션
•
관계형은 다음 목적일 때만 적극 사용함
◦
집계·가공이 필요한 경우
◦
프로젝트와 산출물·태스크처럼 맥락 연결이 중요한 경우
◦
AI가 관계 맥락을 읽어야 하는 경우
•
단순 정보 복사나 표시 목적이면 relation/rollup보다 텍스트·셀렉트·스냅샷 필드가 나음
•
뷰에서는 필요한 속성만 displayProperties에 노출하고, 무거운 관계형/롤업을 기본 보기에서 숨겨야 함
핵심 인사이트
컨설턴트: "로딩이 된다, 속도가 느려져요. 로딩이 안된다? 괜찮아요."
7. 노션 + 별도 프론트엔드 하이브리드 전략
고객 현황
•
고객은 홈페이지와 프론트엔드 제작을 클라우드 코딩/바이브 코딩으로 진행하고 있으며, 디자인과 기본 화면 제작 역량이 있음
•
노션을 백엔드 DB처럼 쓰고, 프론트에서 출결·HR·업무 입력을 처리할 수 있는지 궁금해함
•
노션 API가 실시간성이 약하고 요청 제한이 있다는 점을 새롭게 알게 됨
분석 및 진단
•
컨설턴트는 노션의 미래 사용 방향을 “대시보드 + DB”로 봄
•
직원이 직접 쓰는 화면은 노션보다 별도 프론트가 더 쉽고 안정적일 수 있음
•
노션 API는 직접 프론트에서 대량 호출하면 1초 3개 제한 같은 문제로 동시 입력이 막힐 수 있으므로, 중간에 Supabase 같은 안정화 계층을 두는 것이 좋음
제안 솔루션
•
관리자·대표·AI 분석용 백오피스는 노션으로 구성함
•
직원용 출결·결재·간단 입력 화면은 별도 웹 프론트로 구성함
•
데이터 동기화 구조는 다음 중 하나로 설계함
1.
프론트 → Supabase → 노션 동기화
2.
프론트 → 서버/API → 노션
3.
노션 DB → 대시보드/AI 질의
•
노션은 단순 DB가 아니라 페이지와 DB가 함께 존재하고, Notion AI가 전체 맥락을 읽을 수 있다는 점 때문에 백단으로 쓸 가치가 있음
시각적 표현
flowchart LR
A["직원용 프론트엔드<br>출결·결재·간단 입력"] --> B["중간 계층<br>Supabase/API/자동화"]
B --> C["Notion DB<br>Projects·Tasks·Resources·Logs"]
C --> D["관리자 대시보드"]
C --> E["Notion AI 질의·요약·분석"]
D --> F["대표/팀장 의사결정"]
E --> FMermaid
복사
핵심 인사이트
컨설턴트: "노션을 쓰는 이유는 노션에 AI를 같이 쓰는 거죠."
8. 노션과 옵시디언의 역할 구분
고객 현황
•
고객은 옵시디언으로 넘어가는 가능성도 들었고, 노션과 옵시디언의 차이를 궁금해함
•
데이터 축적 관점에서는 옵시디언이 로컬 기반이라 강력할 수 있다고 인식함
분석 및 진단
•
컨설턴트는 X축을 “글 작성 프로젝트”, Y축을 “개인 팀”으로 두고 도구 적합성을 설명함
프로젝트”, Y축을 “개인 팀”으로 두고 도구 적합성을 설명함•
개인이 글을 쓰는 용도는 옵시디언이 강력하지만, 팀이 함께 프로젝트를 관리하고 DB 기반으로 협업하는 영역은 노션이 더 적합함
•
ExCorp의 요청은 글쓰기 도구가 아니라 전사 프로젝트·업무 공유·팀 협업 시스템이므로 노션 우선이 맞음
제안 솔루션
•
개인 지식관리·장문 글쓰기·로컬 노트는 옵시디언을 선택지로 둘 수 있음
•
팀 프로젝트·업무 DB·대시보드·AI 질의는 노션을 중심으로 둠
•
ExCorp의 현재 문제는 개인 PKM이 아니라 전사 프로젝트 운영이므로, 노션 기반 구조화가 우선임
핵심 인사이트
컨설턴트: "팀이다? 그리고 프로젝트다? 그러면 저는 무조건 노션을 추천드리기는 해요."
9. 시스템 설계의 출발점: 업무 워크플로우 분석
고객 현황
•
고객은 DB와 화면을 먼저 만들고 있었지만, 실제 업무 흐름이 공식적으로 정리되어 있지 않았음
•
대표와 실무자는 머릿속으로는 알고 있으나, 순서도·파이프라인·담당 부서·분기 조건으로 정리한 적이 없었음
•
고객도 “머리에는 있는데 설계가 안 된다”, “요구사항은 있지만 어떻게 넣을지 모르겠다”고 말함
분석 및 진단
•
컨설턴트는 DB 설계의 8할은 스키마 디자인이며, 스키마 디자인은 업무 흐름 분석에서 나온다고 강조함
•
헤드헌팅 업무와 의류 제작 업체 사례를 보여주며, 한 명의 컨설턴트가 순차적으로 진행하는 업무와 여러 부서가 바통을 주고받는 업무를 구분함
•
ExCorp도 대표적인 프로젝트 몇 개를 골라서 이와 같은 프로세스 맵을 먼저 만들어야 함
제안 솔루션
•
다음 컨설팅 전까지 대표가 주력 프로젝트 3개 내외를 선정함
•
각 프로젝트마다 다음을 정리함
◦
인바운드/시작점
◦
담당 부서
◦
핵심 단계
◦
분기 조건
◦
산출물
◦
승인/컨펌 지점
◦
종료 조건
◦
CS 또는 후속 관리 여부
•
이 흐름을 바탕으로 DB를 만들지, 태스크 템플릿을 만들지, 상태값으로 관리할지 결정함
실행 체크리스트
대표가 주력 프로젝트 후보를 3개 선정
각 프로젝트의 업무 시작점을 정리
단계별 담당 팀/담당자를 표시
고객 컨펌·내부 승인·종료 조건을 표시
산출물과 저장 위치를 표시
반복 업무와 예외 업무를 분리
CS/후속관리 여부를 별도 표시
핵심 인사이트
컨설턴트: "DB 구조가 이렇게 짜야겠구나 그게 나와요."
10. VP 촬영·제작 업무 프로세스 해부
고객 현황
•
고객은 VP 업무를 예시로 제시함
•
VP 업무는 광고·기업 웨비나·강의 콘텐츠·온라인 웨비나·뮤직비디오 등 다양한 형태로 들어오며, 아웃풋은 비디오 결과물임
•
업무 유입은 대부분 메일과 전화이며, 1차 사전 미팅을 통해 요구사항을 파악함
•
가상공간은 기존 템플릿을 쓰거나, 고객 요구에 맞춰 새로 제작함
•
촬영은 스튜디오 내 진행 또는 출장 서비스로 나뉠 수 있으나, 이번 분석에서는 출장은 일단 제외함
분석 및 진단
•
VP 업무는 다음 흐름으로 정리됨
1.
인바운드 수신
2.
일정 조율
3.
1차 사전 미팅
4.
요구사항 확인
5.
견적 발송
6.
고객 결정
7.
가상공간 방식 선택
8.
템플릿 선택 또는 신규 제작
9.
공간 준비
10.
기술 테스트
11.
큐시트/촬영 시나리오 조율
12.
테크니컬 리허설
13.
본 촬영
14.
라이브 결과물 전달 또는 포스트 프로덕션
15.
파일 전달
16.
세금계산서 발행 및 정산
•
이 프로세스는 완전한 주력 업무가 아니라 현재 약 20% 비중이므로, 모든 단계별 전용 DB를 만드는 것은 과할 수 있음
제안 솔루션
•
VP 업무는 우선 범용 프로젝트/태스크 구조 안에서 처리함
•
“인바운드, 가상공간, 큐시트 제작, 기술 테스트, 리허설, 본 촬영, 후편집, 정산” 등을 태스크 템플릿으로 구성함
•
만약 VP 업무가 주력 상품으로 커지면 그때 전용 프로젝트 템플릿 또는 별도 마스터 DB를 만듦
시각적 표현
flowchart TD
A["메일/전화 인바운드"] --> B["일정 조율"]
B --> C["1차 사전 미팅"]
C --> D["요구사항·컨셉 확인"]
D --> E["견적 발송"]
E --> F{"고객 진행 결정"}
F -->|No| Z["종료/보류"]
F -->|Yes| G{"가상공간 방식"}
G -->|템플릿| H["DB 리스트 제공·고객 선택"]
G -->|신규 제작| I["콘텐츠 제작팀 협업·공간 제작"]
I --> J["1차 컨펌·피드백·수정"]
H --> K["공간 준비 완료"]
J --> K
K --> L["기술 테스트<br>카메라·트래킹·조명·신호"]
L --> M["큐시트/촬영 시나리오 조율"]
M --> N["테크니컬 리허설"]
N --> O["본 촬영"]
O --> P{"마무리 방식"}
P -->|라이브 결과물| Q["즉시 결과물 전달"]
P -->|후편집| R["포스트 프로덕션<br>합성·CG·스킨톤·로고"]
Q --> S["파일 전달"]
R --> S
S --> T["세금계산서 발행·정산"]Mermaid
복사
핵심 인사이트
고객: "아웃풋은 컨텐츠, 비디오 결과물로 나가는 거라서 고객 의뢰가 들어오면 미팅하고 제작일, 견적, 단가 이런 거 다 협의하고 컨셉, 미팅 이런 거 다 진행하고..."
11. VP 업무의 DB 설계 선택지
고객 현황
•
VP 촬영은 현재 전체 업무의 약 20% 비중임
•
솔루션 구축이 더 큰 비중을 차지하고 있음
•
VP 업무는 프로세스가 있지만, 모든 케이스가 같은 깊이로 진행되지는 않음
분석 및 진단
•
컨설턴트는 VP 업무를 DB로 설계하는 방법이 세 가지라고 설명함
1.
단독 전용 DB/전용 템플릿
•
VP가 주력 상품일 때 적합
2.
프로젝트 + 태스크 구조
•
VP 프로젝트 하나를 만들고 단계별 업무를 태스크로 생성
3.
단일 프로젝트 상태값 방식
•
인바운드, 가상공간, 큐시트 등 주요 단계를 상태값으로 넘김
•
현재 비중과 복잡도를 고려하면 2번 또는 3번이 적합함
제안 솔루션
•
현재는 VP 전용 DB를 만들기보다 프로젝트 템플릿 또는 태스크 템플릿으로 시작함
•
주요 단계는 상태값 또는 체크리스트로 관리하고, 반복이 충분히 많아졌을 때 전용 DB로 승격함
•
촬영 큐시트, 견적, 파일 전달, 정산 등은 RESOURCE 또는 프로젝트 페이지 내부 산출물로 연결함
템플릿/프레임워크
•
VP 업무 관리 방식 선택 기준
◦
업무 비중 50% 이상: 전용 프로젝트 템플릿 또는 전용 DB
◦
업무 비중 20~50%: 프로젝트 + 태스크 템플릿
◦
업무 비중 20% 이하: 상태값 + 체크리스트 중심
◦
예외 처리 많음: 태스크 템플릿
◦
반복 단계 고정: 상태값 칸반
◦
산출물 종류 많음: RESOURCE 연결 강화
핵심 인사이트
컨설턴트: "이게 만약에 메인이 아니라면, 이거에 대해서 프로젝트만 따로 놔두고 그 다음에 얘네 하위가 인바운드, 가상공간, 큐시트... 별도 태스크로 다 빠지는 거예요."
12. 솔루션 구축·교육·CS의 분리 필요성
고객 현황
•
ExCorp는 자체 스튜디오 시스템을 외부 방송국·기업·대학교 등에 구축해 주는 솔루션 사업도 수행함
•
이 업무는 카메라 장비, 네트워크 시스템, 서버, 소프트웨어, 컨텐츠, 컨설팅, 교육까지 포함함
•
솔루션에는 CS가 종종 발생하며, 교육까지 제공함
분석 및 진단
•
솔루션 구축은 VP 촬영과 업무 성격이 다름
•
VP 촬영은 “콘텐츠 결과물 제작”에 가깝고, 솔루션 구축은 “시스템 납품·교육·운영 지원”에 가까움
•
CS는 문의 접수와 해결이 핵심이므로 별도 CS 템플릿 또는 CS DB가 적합함
제안 솔루션
•
솔루션 구축 프로젝트와 VP 촬영 프로젝트를 분리함
•
솔루션 프로젝트 템플릿에는 다음 축을 포함함
◦
요구사항 분석
◦
장비/네트워크/서버/소프트웨어 구성
◦
구축 일정
◦
납품 산출물
◦
교육 일정
◦
CS/문의 관리
•
CS는 별도 프로젝트 템플릿이나 단순 CS DB로 관리함
핵심 인사이트
컨설턴트: "그거는 아예 별도의, 그러니까 지금 저 같은 경우는 템플릿은 프로젝트 안에 템플릿을 따로 만드니까 그걸 다 적용을 시키는데... CS 템플릿이 있겠죠."
13. 대시보드·뷰·색상 코드·캘린더 활용
고객 현황
•
고객은 대표가 한눈에 볼 수 있는 화면, 부서별로 필요한 정보만 보는 화면, 업무 공유가 잘 되는 화면을 원함
•
컨설턴트의 프로젝트 매니저 화면에서 타임라인, 캘린더, 상태별 뷰, 마감 지연 뷰, 색상 코드 등을 확인함
분석 및 진단
•
뷰와 대시보드는 DB 구조가 잡힌 뒤에는 비교적 빠르게 만들 수 있음
•
중요한 것은 “어떤 데이터를 어떤 단위로 볼지”이고, 이는 스키마 디자인에 의해 결정됨
•
캘린더 색상 코드는 프로젝트 구분을 돕지만, 노션 캘린더 자체는 시각적 구분이 약하므로 보조 장치로 보는 것이 맞음
제안 솔루션
•
관리자 뷰
◦
전체 프로젝트 상태
◦
마감 지연
◦
진행 중 태스크
◦
부서별 업무량
◦
프로젝트별 산출물
•
담당자 뷰
◦
내 태스크
◦
이번 주 일정
◦
관련 프로젝트
◦
필요한 산출물
•
대표 뷰
◦
병목 프로젝트
◦
지연 태스크
◦
주요 의사결정 대기
◦
부서 간 협업 현황
핵심 인사이트
컨설턴트: "중요한 것은 스키마 디자인이기 때문에 얘는."
14. 다음 컨설팅 운영 방식과 과제
고객 현황
•
이번 회차는 진단 형태로 진행되었고, 실제 계약된 4회 컨설팅은 아직 남아 있음
•
컨설턴트는 한 주 간격으로 4회를 빠르게 진행하는 것을 추천함
•
고객은 구조화·워크플로우·노션 DB + 프론트엔드 방향성에 대한 답을 얻었다고 말함
분석 및 진단
•
앞으로의 컨설팅은 DB 생성이 아니라, 고객이 가져오는 업무 흐름을 기반으로 설계하는 방식으로 진행되어야 함
•
대표가 먼저 프로젝트를 선택해야 하며, 부서별로 나눠서 한꺼번에 모든 업무를 다 보려고 하면 진행이 늘어짐
•
주력 프로젝트별 워크플로우가 나오면 이후 DB 스키마, 템플릿, 대시보드, 자동화, 프론트 분리 지점을 결정할 수 있음
제안 솔루션
•
다음 회차 전 고객 과제
◦
주력 프로젝트 3개 선정
◦
각 프로젝트의 업무 흐름 작성
◦
담당 부서·담당자 표시
◦
산출물·결정 지점 표시
◦
반복 업무와 예외 업무 구분
•
컨설턴트 과제
◦
고객이 가져온 흐름을 보고 DB 구조화 방향 제안
◦
전용 DB/태스크 템플릿/상태값 방식 중 선택지 제시
◦
프로젝트 매니저 구조와 ExCorp 업무 흐름을 연결
핵심 인사이트
컨설턴트: "일단은 이거를 프로젝트 단위로 이런 워크플로가 다 나와야 돼요."
의사결정 사항
•
ExCorp의 기본 방향은 부서별 독립 시스템이 아니라 전사 프로젝트 관리 구조로 잡음
◦
근거: 2번 안건, 3번 안건
•
HR·근태·결재 영역은 노션 단독 구현보다 노션 DB + 별도 프론트엔드/중간 계층 방식으로 검토함
◦
근거: 5번 안건, 7번 안건
•
노션은 전사 DB·대시보드·AI 질의 허브로 쓰고, 직원 입력 UX는 필요 시 별도 화면으로 분리함
◦
근거: 7번 안건
•
DB 설계는 지금 당장 만들기보다, 대표 주력 프로젝트의 실제 워크플로우를 먼저 정리한 뒤 진행함
◦
근거: 9번 안건
•
VP 촬영/제작 업무는 현재 주력 비중이 20% 수준이므로, 당장은 전용 DB보다 범용 프로젝트/태스크 템플릿 또는 상태값 방식으로 검토함
◦
근거: 10번 안건, 11번 안건
•
솔루션 구축·교육·CS는 VP 촬영 프로세스와 분리해 별도 프로젝트 템플릿 또는 CS 템플릿으로 다룸
◦
근거: 12번 안건
•
다음 컨설팅은 총 4회로 보고, 가능하면 1주 간격으로 빠르게 진행함
◦
근거: 14번 안건
•
이번 회차는 진단/서비스 회차로 처리하고, 이후 4회 컨설팅에서 본격 설계로 들어감
◦
근거: 14번 안건
액션 아이템
대표가 주력 프로젝트 3개 내외 선정
•
기한: 다음 컨설팅 전
•
우선순위: 매우 높음
각 프로젝트의 실제 업무 흐름을 순서도로 정리
•
기한: 다음 컨설팅 전
•
우선순위: 매우 높음
프로젝트별로 시작점, 담당 부서, 단계, 컨펌 지점, 산출물, 종료 조건 정리
•
기한: 다음 컨설팅 전
•
우선순위: 높음
후속 일정
•
확정된 날짜는 전사본에 명시되지 않음
•
컨설턴트는 1주 간격 진행을 가장 추천했고, 최대 2주 간격까지 가능하다고 안내함
•
이번 회차는 진단 회차로 처리되었으며, 이후 4회가 본 컨설팅으로 남아 있음
