Rhetis의 전체 제작 흐름
자료 입력부터 인테이크, 스토리 설계, 스켈레톤 편집, 스타일 적용과 최종 덱까지 각 단계의 역할을 설명합니다.
Rhetis는 발표자료를 한 번에 완성본으로 생성하기보다, 논리와 구조를 먼저 합의하고 디자인을 나중에 적용하는 단계형 워크플로를 사용합니다. 이 방식은 수정 범위를 줄이고, 팀이 중요한 의사결정에 먼저 집중하도록 돕습니다.
단계별 목적
Rhetis가 나누는 작업
자료 입력
프롬프트, 문서, 기존 PPT, 메모, 이미지와 스타일 레퍼런스를 프로젝트에 모읍니다.
인테이크
청중, 발표 목적, 필요한 결정, 분량과 제약을 질문으로 확인합니다.
스토리 플랜
발표의 중심 논리, 추천 내러티브 구조, 필요한 근거와 부족한 정보를 정리합니다.
스토리라인
슬라이드별 제목, 핵심 메시지, 설명과 시각화 방향을 순서대로 구성합니다.
스켈레톤
각 슬라이드의 텍스트·데이터·이미지 블록과 레이아웃을 편집합니다.
최종 덱
승인된 구조에 선택한 스타일을 적용하고 발표 가능한 형태로 마감합니다.
검토와 공유
댓글, 링크와 권한을 이용해 팀 검토를 진행하고 PDF로 내보냅니다.
단계별로 무엇을 승인해야 하나요?
- 1
인테이크에서 범위를 승인합니다
누가 볼 자료인지, 어떤 결정을 이끌어야 하는지, 얼마만큼 자세해야 하는지를 확인합니다. 이 정보가 모호하면 이후 모든 단계가 흔들릴 수 있습니다.
- 2
스토리 플랜에서 논리를 승인합니다
추천 구조가 청중과 목적에 적합한지, 근거가 부족한 주장이나 빠진 질문이 없는지 확인합니다. 이 단계에서는 문구의 아름다움보다 설득 구조가 중요합니다.
- 3
스토리라인에서 슬라이드 순서를 승인합니다
각 슬라이드가 하나의 역할을 하고, 앞뒤 메시지가 자연스럽게 이어지는지 검토합니다. 필요 없는 장은 삭제하고, 결론이 너무 늦게 나오면 앞쪽으로 옮깁니다.
- 4
스켈레톤에서 내용과 정보 밀도를 승인합니다
제목, 본문, 표, 차트, 이미지 블록을 확인합니다. 숫자와 출처를 검증하고, 한 슬라이드에 너무 많은 메시지가 들어가지 않도록 조정합니다.
- 5
최종 덱에서 시각 품질을 승인합니다
스타일, 대비, 글자 크기, 잘림, 이미지 해상도와 페이지 간 일관성을 확인합니다. 구조 문제가 발견되면 최종 화면에서 억지로 고치기보다 스켈레톤으로 돌아가는 편이 좋습니다.
언제 이전 단계로 돌아가야 하나요?
- 청중이나 목적이 바뀌었다면 인테이크 또는 스토리 플랜으로 돌아갑니다.
- 슬라이드 순서와 논리가 어색하다면 스토리라인을 수정합니다.
- 한 장의 텍스트 길이, 차트 위치, 이미지 영역이 문제라면 스켈레톤에서 수정합니다.
- 색상, 폰트, 이미지 분위기만 문제라면 스타일 또는 최종 덱에서 수정합니다.
- 업로드한 근거가 부족하다면 Knowledge나 프로젝트 첨부에 자료를 추가한 뒤 해당 단계의 재검토를 요청합니다.
수정 범위를 가능한 한 앞 단계에서 해결하세요. 논리 문제를 최종 디자인 단계에서 해결하려 하면 슬라이드 여러 장을 다시 손봐야 할 수 있습니다.
작업 시간을 줄이는 운영 방식
- 팀 리뷰는 스토리 플랜과 스토리라인에서 한 번, 최종 덱에서 한 번 진행합니다.
- 각 단계에서 “반드시 지켜야 할 것”과 “Rhetis가 제안해도 되는 것”을 구분해 전달합니다.
- 수치가 바뀔 가능성이 높은 보고서는 원본 문서의 기준 날짜를 프롬프트에 적습니다.
- 스타일은 매 프로젝트마다 새로 만들기보다 승인된 워크스페이스 스타일을 재사용합니다.
- 변경 요청은 “전체적으로 더 좋게”보다 대상 슬라이드, 블록, 길이와 목적을 구체적으로 적습니다.