광고 이 사이트에는 광고와 제휴 링크가 포함되어 있으며, 링크를 통한 가입이나 구매 시 운영자가 수수료를 받습니다.

목록 · 가이드

회사 메일·보고서, 어떤 스킬로 쓰나요?

실전 비교 읽는 데 6분 2026-08-27 갱신

회사에서 쓰는 글은 세 종류로 갈립니다. 매주 같은 형식으로 반복되는 보고, 머릿속에는 있는데 정리가 안 되는 문서, 그리고 파일로 넘겨야 하는 산출물입니다. 각각에 맞는 스킬이 따로 있고, 잘못 고르면 오히려 손이 더 갑니다. 세 개를 실제로 돌려 보고 결과를 그대로 옮깁니다.

어떤 상황에 어떤 스킬을 쓰나요

한 문장으로 답하면 이렇습니다. 형식이 매번 같아야 하면 internal-comms, 내용이 아직 안 잡혔으면 doc-coauthoring, 파일로 내보내야 하면 docx입니다. 셋은 경쟁하는 도구가 아니라 순서가 다른 도구라, 실제로는 이어 붙여 씁니다.

이럴 때
주간 보고처럼 매번 형식이 같을 때
internal-comms. 보고 종류를 먼저 알아본 뒤 그 종류의 형식을 강제합니다. 매주 조금씩 형식이 달라지는 문제가 사라집니다.
이럴 때
할 말은 있는데 구조가 안 잡힐 때
doc-coauthoring. 바로 쓰지 않고 먼저 캐묻습니다. 제안서·기획서·의사결정 문서처럼 읽는 사람이 정해져 있는 글에 씁니다.
이럴 때
워드 파일로 넘겨야 할 때
docx. 실제 .docx 파일을 만듭니다. 표·목차·머리글이 들어간 문서를 메일에 첨부해야 할 때 씁니다.

internal-comms — 형식을 강제합니다

이 스킬의 핵심은 글을 대신 써 주는 것이 아니라 형식을 못 벗어나게 하는 것입니다. 요청을 받으면 먼저 어떤 종류의 보고인지 가려낸 뒤(주간 3P·뉴스레터·FAQ·그 외 넷 중 하나), 그 종류에 해당하는 형식 문서를 불러와 그대로 따릅니다.

직접 돌려 봤습니다
이번 주에 실제로 있었던 일을 사실만 적어 넣고 "리더십 대상 짧은 업데이트"로 요청했습니다. 스킬은 이것을 3P(Progress·Plans·Problems)로 분류하고, 각 항목을 1~3문장으로 제한하는 형식을 적용했습니다. 읽는 데 30~60초를 넘기지 않게 하는 것이 이 형식의 목적입니다.
📉 도도리 AI연구소 (8/21–8/27)
Progress: 애드센스 2차 반려 후 원인 4개를 측정으로 특정. 기계번역 582건 제거, 얇은 페이지 21장 색인 제외(사이트맵 113→92), 홈 제휴 카드 6장 제거.
Plans: 상황 기반 가이드 5편 추가. 수요는 있으나 재고가 0인 칸의 스킬 확보.
Problems: 반려 통보가 번역 제거 직후 도착해, 가장 큰 원인이 심사 창 밖에서 고쳐졌습니다.
눈여겨볼 것은 Problems 칸이 비워지지 않는다는 점입니다. 이 형식은 막힌 것을 반드시 적게 만들어서, 보고가 성과 나열로만 흐르는 것을 구조적으로 막습니다.

doc-coauthoring — 먼저 캐묻습니다

이 스킬은 요청을 받자마자 쓰기 시작하지 않습니다. 대신 세 단계를 제안하고 동의를 구합니다. 맥락 모으기, 다듬기, 그리고 독자 시험입니다. 곧장 쓰고 싶으면 거절할 수 있고, 그러면 평소대로 진행합니다.

3단계가 이 스킬을 고르는 이유입니다. 쓴 사람은 이미 다 알고 있어서 빠진 설명이 안 보입니다. 맥락이 없는 독자에게 먼저 읽혀 보는 것이 남에게 보내기 전에 그것을 잡는 가장 싼 방법입니다.

docx — 파일이 나옵니다

앞의 둘은 결과가 화면의 글이지만, 이 스킬은 실제 .docx 파일을 만듭니다. 표의 너비를 표와 각 셀 양쪽에 지정해야 한다거나, 셀 음영에 특정 값을 쓰면 검게 나온다거나, 줄바꿈 문자를 쓰지 말고 문단을 나눠야 한다는 식의 함정을 미리 일러 줍니다.

직접 돌려 봤습니다
위 3P와 같은 내용을 A4 워드 문서로 만들었습니다. 제목·구분선·4열 비교표·다음 주 계획이 들어간 9,315바이트 파일이 나왔고, 열어서 확인하니 표 1개에 셀 20개(5행 × 4열)와 글자가 모두 정상이었습니다.
걸린 곳이 두 군데 있었습니다. 첫째, 스킬 문서는 필요한 라이브러리가 미리 깔려 있다고 안내하는데 이 환경에는 없었습니다. 다만 문서가 "안 되면 설치하라"는 대비책을 함께 적어 둬서 그대로 하니 넘어갔습니다. 둘째, 이 스킬은 파일을 만든 뒤 PDF로 변환해 눈으로 확인하라고 시키는데, 이 환경에 자바가 없어 변환이 실패했습니다. 그래서 눈으로 본 확인은 못 했고, 파일 내부를 직접 열어 구조만 확인했습니다. 실제 업무 PC에서는 걸리지 않을 단계입니다.

셋을 이어 쓰면

가장 손이 덜 가는 순서는 doc-coauthoring으로 내용을 잡고 → docx로 파일을 만드는 것입니다. 반복되는 주간 보고라면 doc-coauthoring을 건너뛰고 internal-comms로 형식을 고정한 뒤 docx로 넘기면 됩니다. 위 사례가 그 경로를 그대로 따라간 것입니다 — 같은 내용이 3P 형식을 거쳐 워드 파일이 됐습니다.

이 글에서 확인한 것과 확인하지 못한 것.

세 스킬 모두 실제로 불러 돌렸고, 위에 실은 3P 본문과 워드 파일은 그 결과물입니다. 다만 워드 파일을 PDF로 변환해 눈으로 보는 단계는 이 환경의 제약으로 하지 못했습니다. 지어낸 사용 후기는 넣지 않았습니다.

자주 묻는 질문

세 개를 다 깔아야 하나요?
아닙니다. 하는 일이 다르니 필요한 것만 깔면 됩니다. 매주 같은 보고를 쓴다면 internal-comms 하나로 충분하고, 워드 파일을 넘길 일이 없다면 docx는 필요 없습니다.
doc-coauthoring이 자꾸 질문만 하는데요?
그것이 이 스킬의 동작입니다. 세 단계 진행을 제안할 때 거절하면 평소대로 바로 씁니다. 짧은 메일 한 통에는 과한 도구이니, 읽는 사람이 정해져 있는 긴 문서에만 쓰십시오.
워드 파일이 깨져 보입니다
표 너비를 표 쪽에만 지정하고 셀에는 빠뜨린 경우가 가장 흔합니다. 스킬 문서가 이 함정들을 미리 적어 두었으니, 만들고 나서 반드시 열어서 확인하십시오. 스킬 자체도 마지막에 확인 단계를 넣으라고 시킵니다.

이어서 보기