문서 작성 Skill

문서 업무는 AI가 가장 그럴듯하게 해내는 분야처럼 보인다. 몇 줄만 지시해도 보고서 초안이 나오고, 이메일 문장이 정리되며, 회의록도 순식간에 만들어진다. 하지만 실무자는 금방 안다. "문장은 괜찮은데 우리 회사 스타일이 아니다", "형식은 맞는 것 같은데 임원이 원하는 밀도가 아니다", "액션 아이템이 빠졌다" 같은 문제가 반복된다는 것을 말이다.

그래서 문서 작성 Skill의 목적은 단순히 글을 잘 쓰게 만드는 데 있지 않다. 진짜 목적은 같은 기준의 문서를 반복해서 생산하게 만드는 것이다. 한 번 잘 나온 초안이 아니라, 누가 요청해도 비슷한 품질과 형식으로 결과가 나오게 하는 것. 문서 Skill은 바로 그 반복 가능성을 만드는 장치다.

문서 작성 Skill은 글쓰기 도우미가 아니라 업무 시스템이다

문서 작성 업무를 Skill로 만들 때 가장 먼저 버려야 할 생각이 있다. "AI에게 잘 써 달라고 하면 되지 않을까?"라는 기대다. 이 방식은 초안 생성에는 유용하지만, 운영 가능한 업무 절차로는 약하다. 같은 요청이라도 매번 다른 톤이 나오고, 중요한 항목이 빠지며, 조직의 금지 표현을 어기기 쉽기 때문이다.

문서 Skill은 글쓰기 재능을 흉내 내는 도구가 아니라, 문서 생산 과정을 업무 시스템으로 바꾸는 방식에 가깝다. 입력을 받고, 목적을 파악하고, 독자를 구분하고, 정해진 형식으로 정리하고, 마지막에 스스로 점검하는 흐름을 만들어야 한다. 이렇게 설계하면 AI는 "알아서 써 주는 존재"가 아니라 "정해진 매뉴얼에 따라 문서를 조립하는 실행자"로 바뀐다.

이 차이는 아주 크다. 글을 잘 쓰는 AI는 인상적이지만, 항상 같은 규격으로 쓰는 AI는 실제로 팀의 생산성을 바꾼다.

어떤 문서는 하나의 Skill로 묶고, 어떤 문서는 나눠야 하는가

문서 작성 Skill을 설계할 때 가장 흔한 실수는 모든 문서를 하나의 범용 Skill 안에 넣는 것이다. 예를 들어 "회사 문서 작성 Skill"처럼 넓게 만들면 처음에는 편해 보인다. 하지만 곧 문제가 생긴다. 보고서와 이메일은 문체도 다르고, 출판 기획서와 회의록은 구조도 다르며, 검토 기준도 다르기 때문이다.

문서를 나눌지 묶을지 판단할 때는 문서의 이름보다 절차의 차이를 봐야 한다. 다음 세 가지가 다르면 분리하는 편이 좋다.

• 입력 정보의 종류가 다르다

• 문서 구조와 필수 섹션이 다르다

• 검토 기준과 금지사항이 다르다

예를 들어 보고서 작성 Skill은 배경, 핵심 요약, 근거, 리스크, 다음 액션을 구조적으로 정리해야 한다. 반면 이메일 작성 Skill은 상대방, 목적, 요청 강도, 예의 수준, 답장 유도 문장을 더 중요하게 다룬다. 회의록 작성 Skill은 발언 내용을 멋지게 다듬는 것보다 의사결정, 담당자, 기한을 정확히 남기는 일이 핵심이다. 출판 기획서는 시장성, 독자 페르소나, 차별점, 예상 목차, 판매 포인트가 빠지면 안 된다.

즉, 문서의 외형이 아니라 실패했을 때 무엇이 문제로 간주되는가를 기준으로 Skill을 나누어야 한다.

보고서, 출판 기획서, 이메일, 회의록은 왜 다른 Skill이어야 하는가

이 네 가지 문서는 모두 "글"이지만, 사실상 서로 다른 작업이다.

보고서는 판단을 돕는 문서다. 그래서 핵심은 아름다운 문장이 아니라 의사결정에 필요한 정보의 배치다. 먼저 결론을 보여 줄지, 배경부터 설명할지, 수치와 해석을 어떻게 구분할지 같은 규칙이 중요하다.

출판 기획서는 설득 문서다. 아이디어가 좋다는 느낌만으로는 부족하다. 독자가 누구인지, 왜 지금 이 주제가 필요한지, 유사 도서와 무엇이 다른지, 실제로 어떤 목차로 전개할지까지 논리적으로 제시해야 한다. 같은 "요약"이라도 보고서의 요약과 출판 기획서의 요약은 역할이 다르다.

이메일은 관계 문서다. 짧지만 함정이 많다. 지나치게 차갑거나, 너무 장황하거나, 요청이 모호하면 실무에서 곧바로 비용이 발생한다. 이메일 Skill은 문장력보다 상대와 맥락에 따른 어조 조절이 중요하다.

회의록은 기록 문서다. 여기서 가장 위험한 것은 그럴듯한 문장이 아니라 잘못된 확정 표현이다. 누가 무엇을 결정했는지, 누가 언제까지 무엇을 하기로 했는지, 미결 이슈가 무엇인지가 핵심이다. 회의록 Skill은 요약 능력보다 사실 보존 능력을 우선해야 한다.

따라서 네 문서를 하나의 범용 Skill로 만들면, 에이전트는 매번 너무 많은 규칙 중에서 적당한 것을 추측해야 한다. 반대로 문서별 Skill로 분리하면 활성화 조건이 선명해지고, 결과의 일관성도 높아진다.

회사 문체와 톤은 지침이 아니라 자료로 관리하라

많은 팀이 문서 Skill에 이런 문장을 넣는다. "우리 회사 스타일로 전문적이고 간결하게 작성하라." 문제는 이 문장이 거의 아무것도 규정하지 못한다는 점이다. 전문적이라는 말은 사람마다 다르게 이해하고, 간결하다는 기준도 문서 종류에 따라 달라진다.

회사 스타일을 Skill에 반영하려면 추상적인 수식어보다 실제 판단 기준을 넣어야 한다. 이때 가장 유용한 방법이 references/와 examples/를 활용하는 것이다.

references/에는 조직의 문체 기준을 담는다. 예를 들어 다음과 같은 자료가 들어갈 수 있다.

• 자주 쓰는 표현과 피해야 할 표현

• 직급별 호칭 규칙

• 숫자, 날짜, 단위 표기 방식

• 제품명, 서비스명, 브랜드명 표기 규칙

• 공식 문서에서 금지하는 과장 표현

examples/에는 좋은 예시와 나쁜 예시를 함께 넣는 것이 좋다. 좋은 예시만 있으면 에이전트가 겉모양만 따라 할 수 있다. 반대로 나쁜 예시와 수정 이유를 함께 두면, 어떤 문장을 피해야 하는지 더 분명해진다.

예를 들어 "혁신적인", "압도적인", "완벽한" 같은 과장 표현을 금지한다면, 금지 목록만 적지 말고 왜 금지하는지도 설명해야 한다. 회사가 사실 중심의 톤을 선호하는지, 법무 리스크 때문에 확정 표현을 피하는지, 고객 커뮤니케이션에서 기대 관리가 중요한지까지 연결해 주면 Skill의 판단력이 올라간다.

문체는 감각의 문제가 아니라 데이터의 문제다. 감으로 넣지 말고, 자료로 넣어야 한다.

출력 포맷은 부탁이 아니라 계약이어야 한다

문서 작성 Skill에서 가장 자주 무너지는 부분은 출력 형식이다. 사용자는 "표로 정리해 달라", "액션 아이템을 마지막에 넣어 달라", "3줄 요약을 앞에 써 달라"고 요청하지만, 에이전트는 초안이 길어질수록 이런 조건을 자주 놓친다. 그래서 출력 포맷은 단순 지시가 아니라 반드시 따라야 하는 계약으로 설계해야 한다.

포맷 강제는 보통 세 층으로 나누어 설계하면 안정적이다.

첫째, 문서 뼈대를 고정한다. 예를 들어 보고서라면 핵심 요약 → 배경 → 주요 분석 → 리스크 → 다음 액션처럼 순서를 고정한다. 순서가 정해져 있으면 내용이 흔들려도 구조는 유지된다.

둘째, 섹션별 필수 요소를 명시한다. "핵심 요약은 3문장 이내", "액션 아이템에는 담당자와 기한 포함", "회의록의 결정사항은 추정이 아닌 확정된 내용만 기재"처럼 조건을 박아 둔다.

셋째, 출력 후 자체 검사를 하게 만든다. "표가 있는가?", "요약이 맨 앞에 있는가?", "액션 아이템에 담당자와 기한이 있는가?"를 확인하도록 지시하면 형식 붕괴를 크게 줄일 수 있다.

문서 Skill은 자유롭게 잘 쓰는 것보다, 정해진 형태를 무너지지 않게 유지하는 것이 더 중요하다. 실무에서는 이쪽이 훨씬 값지다.

표, 요약, 액션 아이템은 각각 다른 설계가 필요하다

문서에서 자주 요구되는 출력 요소는 비슷해 보여도 역할이 다르다.

요약은 독자의 시간을 아끼기 위한 장치다. 그래서 길이 제한과 우선순위 규칙이 중요하다. 예를 들어 임원용 보고서의 요약은 세부 설명보다 결론, 수치, 리스크를 먼저 담아야 한다.

표는 비교를 쉽게 하기 위한 장치다. 따라서 표를 넣으라고만 하지 말고, 어떤 열을 가져야 하는지를 지정해야 한다. 예를 들어 출판 기획서라면 경쟁 도서 / 핵심 주제 / 차별점 / 예상 독자 같은 열이 필요할 수 있다.

액션 아이템은 실행을 위한 장치다. 이 항목은 특히 많이 흐려진다. "추가 검토 필요", "후속 논의 예정" 같은 문장은 액션 아이템이 아니다. 누가, 무엇을, 언제까지 할지 들어가야 한다.

이 세 요소를 모두 "잘 정리해 달라"는 한 문장으로 처리하면 결과는 매번 달라진다. 반대로 각 요소의 역할을 분리해서 설계하면 문서가 읽히는 방식 자체가 달라진다.

초안 생성 다음에 반드시 자체 검토 단계를 넣어라

문서 Skill은 초안 생성으로 끝나지 않는다. 오히려 초안은 중간 결과에 가깝다. 실무에서 필요한 것은 "한 번에 완성된 글"보다 "검토를 통과하는 문서"이기 때문이다.

그래서 좋은 문서 Skill에는 항상 자체 검토 체크리스트가 들어간다. 이 체크리스트는 사람 검토를 완전히 대체하지는 못하지만, 초안의 품질을 안정화하는 데 매우 효과적이다.

예를 들어 보고서 작성 Skill의 자체 검토 항목은 다음처럼 설계할 수 있다.

• 핵심 결론이 문서 앞부분에 제시되었는가

• 주장마다 근거 또는 출처 정보가 연결되어 있는가

• 수치, 날짜, 단위 표기가 일관적인가

• 리스크와 가정이 분리되어 있는가

• 다음 액션이 실행 가능한 수준으로 구체적인가

이메일 Skill이라면 체크리스트가 달라져야 한다. 상대방이 누구인지에 맞는 호칭을 썼는지, 요청이 한 문장으로 명확히 드러나는지, 지나치게 공격적이거나 모호한 표현이 없는지, 회신이 필요한 경우 답변 요청이 분명한지 등을 확인하게 해야 한다.

중요한 점은 체크리스트가 "예쁘게 썼는가"를 묻지 않아야 한다는 것이다. 대신 빠질 수 있는 항목, 오해를 부르는 표현, 형식 위반을 잡아내는 데 집중해야 한다. 문서 Skill의 검토는 문학 평가가 아니라 운영 검수에 가깝다.

독자 수준과 정보 밀도는 문서 목적에 따라 달라져야 한다

같은 사실도 누구에게 쓰느냐에 따라 문서의 모양이 완전히 달라진다. 실무자가 흔히 하는 실수는 이 차이를 "문체 조정" 정도로만 생각하는 것이다. 하지만 실제로는 설명 깊이, 배경 정보, 용어 사용, 문장 길이, 요약 위치까지 모두 달라져야 한다.

예를 들어 임원용 문서는 정보 밀도가 낮아 보일 정도로 압축되어야 할 때가 많다. 대신 판단에 필요한 핵심 신호가 앞에 와야 한다. 배경 설명은 최소화하고, 숫자와 리스크를 전면에 배치하는 편이 낫다.

실무자용 문서는 다르다. 왜 이런 판단이 나왔는지, 어떤 예외가 있는지, 실행 순서가 무엇인지 더 자세한 설명이 필요하다. 교육용 문서는 더 다르다. 용어 정의, 맥락 설명, 예시와 비유가 충분히 들어가야 한다.

그래서 문서 Skill에는 "누구를 위한 문서인가"만 묻지 말고, 최소한 다음 항목을 입력으로 받는 것이 좋다.

• 예상 독자

• 독자의 배경지식 수준

• 문서의 목적

• 허용 가능한 길이

• 의사결정용인지, 기록용인지, 설득용인지

이 정보가 없으면 에이전트는 대체로 무난한 중간값을 고른다. 그런데 실무에서 중간값은 종종 가장 쓸모없는 결과가 된다.

문서 Skill은 입력 설계가 절반이다

문서 품질이 들쭉날쭉한 이유를 에이전트 탓으로만 돌리기 쉽지만, 실제로는 입력이 부실한 경우가 많다. "회의 내용 정리해 줘", "보고서 써 줘"처럼 요청하면 에이전트는 부족한 정보를 상상으로 메우게 된다. 바로 이 지점에서 조직 문서의 신뢰도가 흔들린다.

좋은 문서 Skill은 입력 단계에서 필요한 정보를 구조화해서 받는다. 예를 들어 회의록 Skill이라면 참석자, 회의 목적, 논의 안건, 확정된 결정, 미결 이슈, 후속 작업을 입력받도록 할 수 있다. 보고서 Skill이라면 문서 목적, 대상 독자, 포함해야 할 수치, 제외해야 할 주장, 결론 방향, 근거 자료를 먼저 받는 편이 좋다.

입력이 정리되면 문장 생성은 오히려 쉬워진다. 반대로 입력이 흐리면 아무리 좋은 모델을 써도 결과는 흔들린다. 문서 Skill은 문장을 잘 쓰는 기술이기 전에, 필요한 정보를 빠짐없이 받는 기술이다.

실전에서는 하나의 큰 문서 Skill보다 작은 전문 Skill 묶음이 강하다

현업에서 잘 작동하는 방식은 대개 하나의 거대한 "문서 작성 마스터 Skill"이 아니다. 대신 여러 개의 작은 전문 Skill을 묶어 운영하는 구조에 가깝다.

예를 들어 팀에서 다음과 같이 나눌 수 있다.

• 임원 보고서 Skill

• 외부 제안서 Skill

• 고객 응대 이메일 Skill

• 내부 공지문 Skill

• 회의록 정리 Skill

이렇게 나누면 각 Skill의 활성화 조건이 선명해지고, 문체 규칙과 포맷 규칙도 간결하게 유지된다. 물론 공통 자산은 따로 뺄 수 있다. 회사 톤 가이드, 금지 표현 목록, 브랜드 표기 규칙, 표 템플릿 같은 것은 공용 references/나 공통 템플릿으로 재사용하면 된다.

핵심은 "모든 문서를 다 잘 쓰는 하나의 Skill"을 만들려 하지 않는 것이다. 그런 Skill은 대체로 아무 문서도 완벽하게 처리하지 못한다. 반대로 범위를 줄이면 Skill은 훨씬 똑똑해 보인다. 사실은 똑똑해진 것이 아니라, 할 일을 더 정확히 배운 것이다.

문서 작성 Skill의 설계 예시

문서 작성 Skill은 대체로 다음 흐름으로 설계하면 안정적이다.

먼저 문서 종류를 식별한다. 보고서인지, 이메일인지, 회의록인지에 따라 활성화 조건을 분명히 한다. 그다음 입력 정보를 수집한다. 독자, 목적, 길이, 필수 포함 항목, 금지사항을 확인한다. এরপর 회사 스타일 자료와 예시를 참조해 초안을 작성한다. 마지막으로 출력 포맷과 체크리스트에 따라 자체 검토를 수행한다.

이 흐름을 SKILL.md에 옮기면, 에이전트는 단지 "문장을 생성"하는 것이 아니라 "문서 작업 절차를 실행"하게 된다. 바로 이 전환이 문서 Skill의 핵심이다.

좋은 문서 Skill은 글의 개성을 줄이는 대신 결과의 신뢰도를 높인다

문서 작성 Skill을 도입하면 때로는 문장이 조금 덜 화려해질 수 있다. 표현이 더 안정적이고, 구조가 더 예측 가능해지며, 과감한 비유나 장식은 줄어든다. 그런데 실무 문서에서는 이것이 오히려 장점이다.

조직이 원하는 것은 대개 "이번에는 유난히 잘 쓴 문서"가 아니다. 누가 요청하든, 어떤 날 실행하든, 기본 품질을 지키는 문서다. 형식이 맞고, 톤이 맞고, 빠질 항목이 없고, 검토 포인트가 살아 있는 문서 말이다.

문서 작성 Skill은 바로 그 안정성을 만든다. 한 사람의 글재주를 복제하는 것이 아니라, 팀의 문서 기준을 패키지로 만드는 것이다. 그래서 문서 Skill은 단순한 프롬프트 모음이 아니다. 그것은 조직의 문서 문화를 에이전트가 재현하도록 만드는 작동 규칙이다.

다음 장에서는 이런 원리를 리서치 업무로 확장해 보려 한다. 문서가 결과물을 안정화하는 Skill이라면, 리서치 Skill은 그 결과물의 근거를 안정화하는 Skill이다. 잘 쓴 문서보다 더 중요한 것은, 믿을 수 있는 재료로 쓴 문서이기 때문이다.