Gemini in Google Docs 글쓰기 스타일 맞추기: 회사 문체로 프로젝트 제안서 검토본 만드는 법
TL;DR
Match writing style은 Drive의 기존 문서에서 어조, 문장 구조, 어휘 복잡도 같은 글쓰기 특징을 참고해 새 Google Docs 문서에 적용하는 기능입니다. 먼저 회사 문체를 대표하는 승인 문서를 스타일 기준으로 고릅니다. 프로젝트 사실이 담긴 자료는 별도 Sources로 추가합니다. 스타일 요약과 제안서의 주장·수치·날짜를 각각 대조한 내부 검토본에서 작업을 끝내야 합니다.
핵심 3줄 요약
핵심 1
스타일 기준 문서와 사실 근거 문서를 같은 용도로 취급하지 않습니다.
핵심 2
하단 Gemini 바에서 Tools > Writing style > Add doc from Drive를 열어 Gemini가 만든 스타일 요약부터 검토합니다.
핵심 3
문체가 비슷해도 내용이 정확해진 것은 아니므로 Sources와 원문을 대조한 뒤 사람이 승인합니다.
이 글에서 다룰 내용
- Match writing style의 역할과 Match doc format과의 차이
- 회사 문체를 대표할 기준 문서를 고르는 방법
- 스타일 문서와 프로젝트 근거 자료를 분리하는 방법
- 프로젝트 제안서 내부 검토본을 완성하는 6단계
- 그대로 복사해 쓸 수 있는 7필드 프롬프트
- 제공 조건, 개인정보 보호, 사람 승인 경계
Match writing style이란
Google 공식 도움말은 Match writing style을 Drive 문서의 어조, 문장 구조, 어휘 복잡도 같은 글쓰기 스타일을 참고하는 기능으로 설명합니다. 한 문장으로 정의하면, 기존 문서의 내용을 복사하는 기능이 아니라 그 문서가 쓰인 방식을 현재 문서에 참고하는 기능입니다.
Match doc format과도 구분해야 합니다. Match writing style은 표현 방식에 초점을 둡니다.
Match doc format은 레이아웃, 스타일, 구조를 기준 문서에 맞추는 별도 흐름입니다. 이번 글은 표 모양이나 색상을 복제하지 않습니다. 회사 문체를 적용한 프로젝트 제안서의 내부 검토본 한 건을 만드는 데만 집중합니다.
글쓰기 스타일이 비슷해졌다고 제안서의 사실까지 검증되는 것은 아닙니다. 문체 기준 문서와 내용 근거 문서를 분리한 다음 결과를 각 원문에 다시 대조해야 합니다.
언제 이 흐름이 맞는가
이 흐름은 내용 초안은 있지만 회사 문체가 들쭉날쭉할 때 적합합니다. 여러 사람이 쓴 프로젝트 제안서를 하나의 어조로 정리하거나, 새 제안서를 최근 승인된 내부 문서와 비슷한 문장 수준으로 맞출 때 쓸 수 있습니다.
반대로 제목 체계, 글꼴, 색상, 표 열까지 재현해야 한다면 Match doc format을 검토해야 합니다. 조직 전체에 반복 적용할 영구 응답 규칙이 필요하다면 Gemini in Workspace의 맞춤 지침이 더 가까운 기능입니다. 이번 작업은 특정 Drive 문서 한 건의 문체를 특정 제안서 한 건에 참고하는 일회성 검토 흐름입니다.
여기서 완성할 것은 외부 발송본이 아닙니다. 승인된 근거와 대조한 내부 검토본, 그리고 사람이 확인해야 할 항목을 적은 검수 메모까지가 첫 완료 경계입니다.
시작 전에 자료를 나누는 법
스타일 기준 문서에는 최근 승인됐고 현재 조직 용어를 쓰는 비민감 문서를 고릅니다. 이번 제안서와 독자와 목적이 비슷하면 더 쉽게 비교할 수 있습니다. 다만 이 선택 기준은 실무 검토 규칙이지, Google Docs가 자동으로 대표 문서를 판정한다는 뜻은 아닙니다.
프로젝트 사실 근거는 별도 문서로 준비합니다. 목표, 범위, 일정, 예산, 담당자, 의사결정 상태를 출처 위치와 함께 정리합니다. 오래된 버전, 개인정보가 포함된 원본, 확정되지 않은 숫자는 제외하거나
확인 필요
로 남깁니다.
원본은 그대로 보존하고 필요한 내용만 담은 검토용 사본을 쓰는 것이 안전합니다. 이 절차는 제품 기능이 아니라 내부 운영 규칙입니다. Gemini가 원본을 자동 백업하거나 민감정보를 알아서 제거한다고 오해하면 안 됩니다.
프로젝트 제안서 검토본 만드는 6단계
1단계. 문체 기준 문서와 사실 근거 문서를 구분합니다
문체 기준 문서에는
STYLE-01
, 프로젝트 근거 문서에는
SRC-01
같은 내부 식별자를 붙입니다. 스타일 문서는 표현을 참고할 자료입니다.
근거 문서는 주장과 숫자를 확인할 자료입니다. 스타일 문서에 등장한 과거 수치나 고객명을 새 제안서의 사실로 가져오지 않습니다.
두 문서 모두 필요한 내용만 남긴 비민감 검토용 사본을 사용합니다. 외부 공유 링크, 개인 이메일, 계정 번호, 미공개 계약 조건은 첫 시험에서 제외합니다.
2단계. Google Docs에서 Writing style 기준 문서를 추가합니다
컴퓨터에서 Google Docs 문서를 엽니다. 하단 Gemini 바에서 Tools > Writing style > Add doc from Drive를 선택합니다. 팝업에서 Add document를 누르고
STYLE-01
문서를 고른 뒤 Add를 선택합니다.
공식 도움말은 이 기능을 데스크톱에서 안내합니다. 메뉴가 보이지 않으면 지원 플랜, 언어, 현재 계정의 기능 제공 여부를 먼저 확인합니다. 모바일이나 다른 화면의 경로를 같은 방식이라고 추정하지 않습니다.
3단계. Gemini가 만든 스타일 요약을 먼저 검토합니다
Gemini는 적용할 글쓰기 스타일을 요약해 보여줍니다.
예를 들어 공식 도움말에는 “Formal, objective, and direct. Concise phrasing but avoid acronyms.” 같은 형태가 제시됩니다.
이 요약을
STYLE-01
과 비교합니다. 결론을 먼저 쓰는지, 문장이 짧은지, 약어를 피하는지, 확정과 검토 중 상태를 어떻게 구분하는지 확인합니다.
실제 문체와 맞지 않으면 다른 파일을 선택합니다. 맞을 때만 Confirm을 누릅니다.
4단계. Sources에 승인된 프로젝트 근거만 추가합니다
하단 Gemini 바에서 Sources > Add from Drive를 선택하거나
@
를 입력해
SRC-01
을 추가합니다. Google 공식 도움말은 특정 파일을 사용해 내용을 쓰거나 다듬을 수 있다고 설명합니다.
여기서는 Drive, Chat, Gmail, 웹 전체를 한꺼번에 검색하지 않습니다. 첫 시험에는 승인된 근거 문서만 넣습니다. 출처가 많아지면 주장별 원문을 다시 찾기 어려워질 수 있습니다.
5단계. 범위가 고정된 프롬프트로 제안서 초안을 만듭니다
독자, 목적, 허용 입력, 제외 입력, 결과 형식, 완료 기준을 한 요청에 적습니다. 문체 기준은
STYLE-01
, 사실 근거는
SRC-01
이라는 역할도 명시합니다.
초안에는 각 주장 옆에 근거 ID를 남깁니다. 근거가 없는 숫자나 일정은
확인 필요
로 표시하게 합니다. 외부 발송, 링크 공유, 승인 완료 선언은 요청하지 않습니다.
6단계. 스타일과 사실을 따로 대조하고 사람이 승인합니다
먼저 스타일 요약과 결과 문장을 비교합니다. 이어서 제안서의 목표, 범위, 숫자, 날짜, 담당자, 요청 사항을
SRC-01
의 실제 위치와 대조합니다. 문체가 회사와 비슷하더라도 근거가 맞지 않으면 통과가 아닙니다.
기존 문서에 새 문단을 붙여 넣은 경우에는 공식 도움말의 안내대로 Match writing style을 선택해 해당 내용을 맞출 수 있습니다. 적용 뒤에도 원문과 변경 문장을 다시 비교합니다. 작업은
확인 완료
,
상충
,
확인 필요
상태가 붙은 내부 검토본과 사람의 승인 기록에서 멈춥니다.
복사해서 쓰는 프롬프트
아래 프롬프트는 스타일 적용과 사실 검토를 한 번에 섞지 않도록 설계했습니다.
목표: STYLE-01의 글쓰기 스타일을 참고해 SRC-01의 승인된 사실만으로 내부 프로젝트 제안서 검토본을 만든다.
허용 입력: STYLE-01의 어조·문장 구조·어휘 수준과 SRC-01의 목표·범위·일정·예산·담당자·의사결정 상태.
제외 입력·금지 작업: STYLE-01의 과거 사실, 승인되지 않은 Drive·Chat·Gmail·웹 자료, 개인정보, 외부 공유, 발송, 최종 승인 선언은 제외한다.
출력 형식: 결론, 배경, 제안 범위, 일정, 예산, 리스크, 승인 요청 순서로 작성하고 각 사실 문장 끝에 SRC-01의 위치를 표시한다.
완료 기준: 모든 주장·수치·날짜에 출처 위치와 확인 완료·상충·확인 필요 상태가 있어야 한다. STYLE-01과 다른 문체 특징은 검수 메모에 적는다.
지어내기 금지: 근거에 없는 숫자·날짜·담당자·성과를 만들지 말고 알 수 없는 내용은 확인 필요로 남긴다.
승인 지점: 결과는 내부 검토본으로만 저장하고 작성자와 실무 책임자가 원문 대조 후 승인하기 전에는 외부 공유하거나 발송하지 않는다.
먼저 초안을 읽으며 문체 차이를 확인합니다. 그다음 사실 대조표에서 상충과 확인 필요 항목을 해결합니다. 두 검토를 한 번에 통과한 것처럼 처리하지 않습니다.
실전 활용 팁
스타일 요약을 별도 검수 항목으로 남기면 결과를 설명하기 쉬워집니다.
STYLE-01에서 확인한 특징
,
Gemini가 요약한 특징
,
사람의 판단
을 나눠 적습니다. Gemini가 만든 스타일 설명은 편집 기준 후보이지 회사 규정의 자동 확정본이 아닙니다.
문서 전체를 다시 쓰게 하기보다 결론, 리스크, 승인 요청처럼 성격이 다른 구역을 한 번씩 검토합니다. 변경 범위가 작아야 뜻이 달라진 문장을 찾기 쉽습니다.
같은 팀에서 반복할 때도 스타일 문서를 무조건 고정하지 않습니다. 문서 독자와 목적이 바뀌면 승인된 기준 문서를 다시 고릅니다. 외부 고객 제안서와 내부 경영 보고서가 같은 문체를 써야 한다고 가정하지 않습니다.
주의할 점
공식 도움말은 이 기능에 적격 Google Workspace 또는 Google AI 플랜이 필요하며 현재 데스크톱에서 제공된다고 안내합니다. Google AI Pro와 Ultra, 개인 계정의 Workspace Experiments도 별도로 언급됩니다.
2026년 4월 Workspace 공지는 Business Standard·Plus, Enterprise Standard·Plus, Education Plus와 일부 소비자·부가 플랜을 안내했습니다. 실제 메뉴와 사용 한도는 현재 계정에서 다시 확인합니다.
지원 언어도 확인해야 합니다. 2026년 4월 공지는 영어를 먼저 출시하고 한국어를 포함한 다른 언어를 뒤이어 지원한다고 설명했습니다. 현재 도움말은 별도 지원 언어 페이지를 확인하도록 안내하므로, 한국어 결과를 모든 계정에서 동일하게 보장한다고 쓰면 안 됩니다.
Workspace 데이터와 개인 계정에서 Gemini Apps 또는 Search에 공유한 데이터는 같은 범위가 아닙니다. Google의 Workspace 개인정보 도움말은 Workspace 안의 Gemini 기능과 개인 계정의 외부 공유 상황을 구분합니다. Workspace Experiments에는 별도 개인정보 고지가 적용됩니다.
문체 일관성은 정확성 증거가 아닙니다. 스타일 문서의 오래된 수치가 새 제안서로 섞이지 않았는지,
SRC-01
의 확정 상태가 과장되지 않았는지 사람이 확인합니다. 외부 공유, 발송, 게시, 계약 승인, 예산 집행은 이 흐름에서 다루지 않습니다.
자주 묻는 질문
Q1. Match writing style과 Match doc format은 같은 기능인가요?
아닙니다. 공식 도움말은 글쓰기 스타일 참조와 문서 형식 참조를 별도 흐름으로 설명합니다. 이번 작업은 어조, 문장 구조, 어휘 복잡도를 맞추는 Match writing style에 한정합니다.
Q2. 스타일 기준 문서 한 건만으로 회사 문체가 확정되나요?
아닙니다. Gemini는 선택한 문서에서 스타일 요약을 만듭니다.
해당 문서가 조직 전체를 대표하는지는 사람이 판단해야 합니다. 최신 승인본인지 확인하고 요약이 맞지 않으면 다른 파일을 선택합니다.
Q3. 스타일 문서를 추가하면 그 안의 사실도 새 제안서 근거가 되나요?
그렇게 취급하면 안 됩니다. 스타일 문서는 표현 기준이고
SRC-01
은 내용 근거입니다. 과거 프로젝트의 숫자, 고객명, 일정이 새 제안서로 넘어오지 않았는지 따로 확인합니다.
Q4. 만든 제안서를 바로 공유해도 되나요?
이 글의 완료 지점은 내부 검토본입니다. Sources에서 실제 근거를 확인하고 작성자와 실무 책임자가 승인하기 전에는 외부 공유나 발송을 진행하지 않습니다.
출처
마무리
Match writing style을 잘 쓰려면 문체와 사실부터 분리해야 합니다.
STYLE-01
은 쓰는 방식을 참고합니다.
SRC-01
은 제안서 내용을 검증합니다. Gemini가 만든 스타일 요약을 확인한 뒤 근거 위치와 상태를 대조하면 그럴듯한 초안을 검토 가능한 내부 문서로 바꿀 수 있습니다.
오늘 한 번 시험한다면 비민감 승인 문서와 작은 프로젝트 근거 문서만 준비합니다. 한 제안서의 결론과 승인 요청까지 검토한 뒤, 사람이 원문을 확인한 경우에만 완료로 표시합니다.
