프로젝트 3: 사내 보고서 Skill 만들기
기술 블로그가 외부 독자에게 이해를 돕는 글이라면, 사내 보고서는 내부 의사결정을 움직이는 문서다. 겉으로 보기에는 둘 다 문서 작성처럼 보이지만, 실제 난이도는 꽤 다르다. 블로그는 잘 설명하면 된다. 그러나 보고서는 잘 설명하는 것만으로는 부족하다. 누가 읽는지에 따라 깊이를 바꿔야 하고, 무엇이 중요한지 우선순위를 정해야 하며, 마지막에는 누가 어떤 결정을 내려야 하는지까지 분명해야 한다.
그래서 사내 보고서야말로 Agent Skill로 만들 가치가 큰 업무다. 자료는 흩어져 있고, 문체는 조직마다 다르며, 애매한 표현 하나가 의사결정을 흐릴 수 있기 때문이다. 좋은 보고서 Skill은 예쁜 문장을 만드는 도구가 아니다. 원자료를 모으고, 신뢰도를 판별하고, 임원용 요약과 실무용 설명을 분리하고, 리스크와 다음 액션을 구조화한 뒤, 회사 문체에 맞게 정리하는 실행 시스템이다.
이 장에서는 바로 그 시스템을 만든다. 목표는 분명하다. 원자료 수집 규칙, 요약 기준, 임원용 1페이지 출력, 리스크 정리, 회사 문체, 최종 승인 절차까지 포함한 조직형 보고 Skill을 설계하는 것이다.
왜 사내 보고서는 별도의 Skill이 필요한가
많은 팀이 보고서를 여전히 긴 프롬프트 한 장으로 해결하려 한다. 예를 들어 이런 식이다. '지난달 사업 현황 정리해서 임원 보고용으로 써줘.' 이 요청만으로도 문서는 나온다. 문제는 그 문서가 정말 쓸 수 있는 문서인지다. 에이전트는 회의 메모에서 본 말을 핵심 사실처럼 올려버릴 수 있고, 숫자는 있는데 의미가 없는 보고서를 만들 수도 있다. 반대로 현장 이슈는 중요한데, 지표가 눈에 띈다는 이유로 작은 변동만 길게 설명할 수도 있다.
사내 보고서의 본질은 문장 생성이 아니라 압축이다. 더 정확히 말하면, 흩어진 사실을 조직의 의사결정 구조에 맞는 형태로 다시 배열하는 일이다. 이 과정에는 적어도 다섯 가지 규칙이 필요하다.
어떤 자료를 먼저 믿을 것인가
어떤 내용을 임원용과 실무용으로 나눌 것인가
리스크를 어떤 형식으로 드러낼 것인가
회사가 선호하는 문체와 금지 표현은 무엇인가
최종 발송 전에 누가 무엇을 확인할 것인가
이 다섯 가지가 정해져 있지 않으면 보고서는 늘 그럴듯하지만 애매한 문서가 된다. Skill은 바로 이 애매함을 줄이는 장치다.
이 프로젝트의 책임 범위를 먼저 정하자
이번 프로젝트에서 만들 Skill은 다음 역할을 책임진다. 여러 원자료를 수집하고, 보고 목적에 맞게 정리하고, 임원용 1페이지 요약과 실무용 상세 보고를 구분해 작성하고, 리스크와 의사결정 요청, 다음 액션을 표준 구조로 출력하는 것까지다. 여기에 회사 문체 적용과 최종 검토 체크리스트도 포함한다.
반대로 이 Skill이 직접 책임지지 않는 일도 있다. 확정되지 않은 숫자의 승인, 민감정보 공개 여부 판단, 대외 공시 성격의 법무 검토, 인사 평가나 재무 확정 수치의 최종 결재는 사람에게 남겨야 한다. 사내 보고서는 자동화 가치가 크지만, 동시에 잘못 요약했을 때의 비용도 크다. 따라서 이 Skill은 보고서를 자동 발송하는 기계가 아니라, 검토 가능한 초안을 빠르고 일관되게 만드는 시스템이어야 한다.
핵심은 이것이다. 보고서 Skill은 조직의 문체와 의사결정 구조를 패키징하는 대표 사례다. 단순한 글쓰기 Skill이 아니라, 회사가 정보를 정리하고 판단하는 방식을 설치하는 Skill이라고 보는 편이 맞다.
입력 규칙: 원자료를 어떻게 모으고 우선순위를 정할 것인가
사내 보고서가 흔들리는 가장 큰 이유는 대개 시작이 허술하기 때문이다. 보고서 초안이 이상한 것이 아니라, 초안이 기대고 있는 원자료가 뒤섞여 있는 경우가 많다. 같은 사안을 두고도 대시보드 수치, 팀 회의 메모, 메신저 대화, 실무자 구두 설명이 모두 다를 수 있다. 이런 상황에서 에이전트가 아무 기준 없이 자료를 섞으면 문장은 매끄러워도 문서는 불안해진다.
그래서 보고서 Skill은 시작부터 입력 규칙을 강하게 잡아야 한다. 가장 실용적인 방법은 원자료를 종류별로 나누고, 각 종류에 우선순위를 매기는 것이다.
우선 보고서에 들어오는 원자료는 보통 다음 부류로 정리할 수 있다.
공식 수치 자료: KPI 대시보드, 재무 집계표, CRM 추출값, 로그 분석 결과
공식 문서 자료: 프로젝트 문서, 주간 업무 보고, 회의록, 승인된 정책 문서
운영 맥락 자료: 이슈 트래커, 고객 문의 요약, 장애 보고, 영업 메모
비공식 보조 자료: 메신저 대화, 개인 메모, 구두 전달 내용
이 네 부류가 섞일 때 우선순위는 분명해야 한다. 숫자와 상태 판단은 공식 시스템 자료를 먼저 믿고, 배경 설명은 승인된 문서를 먼저 참고하며, 예외 상황이나 현장 맥락은 운영 자료로 보강하고, 비공식 자료는 확인이 필요한 힌트로만 취급하는 편이 안전하다. 쉽게 말해, 메신저에서 본 한 줄이 대시보드 수치를 이기면 안 된다.
보고서 Skill에 넣기 좋은 우선순위 규칙은 이렇다.
숫자와 사실은 시스템 원자료를 우선한다.
해석과 배경은 보고 책임자가 승인한 문서를 우선한다.
상충하는 내용이 있으면 낮은 신뢰도 자료를 버리는 대신 충돌을 표시한다.
핵심 의사결정에 필요한 정보가 없으면 추정으로 채우지 말고 추가 입력을 요청한다.
최신성이 중요한 자료는 작성 시점을 반드시 기록한다.
이 원칙은 단순해 보이지만 효과가 크다. 좋은 Skill은 자료를 많이 모으는 것보다, 어떤 자료를 어떤 순서로 믿을지를 먼저 정한다.
원자료 수집용 인테이크 폼을 만들어라
조직형 Skill은 매번 사람의 기억에 의존하면 금방 무너진다. 그래서 사내 보고서 Skill에는 아주 짧더라도 인테이크 폼이 있어야 한다. 이 폼은 에이전트가 무엇을 먼저 물어야 하는지 고정해준다.
## 보고서 인테이크
- 보고 목적:
- 주요 독자: 임원 / 본부장 / 팀장 / 실무자
- 보고 시점:
- 다루는 기간:
- 핵심 질문: 이번 보고서가 답해야 하는 질문은 무엇인가
- 원자료 목록:
- 대시보드 링크
- 회의록 링크
- 프로젝트 문서 링크
- 이슈/장애 내역
- 추가 메모
- 반드시 포함할 항목:
- 제외하거나 비공개 처리할 항목:
- 민감도 수준:
- 최종 승인자:이 인테이크 폼의 장점은 보고서의 방향을 초반에 고정한다는 점이다. 예를 들어 주요 독자가 임원인지 실무자인지만 알아도 문서 구조가 완전히 달라진다. 임원 보고는 선택과 영향이 먼저이고, 실무 보고는 맥락과 근거가 더 중요하다. 같은 자료라도 독자가 달라지면 같은 문장을 쓰면 안 된다.
또한 핵심 질문을 미리 적게 만드는 것도 중요하다. 좋은 보고서는 모든 것을 쓰는 문서가 아니라, 특정 질문에 답하는 문서다. 질문이 없으면 에이전트는 정보 나열로 도망가기 쉽다.
임원용 1페이지와 실무용 보고를 분리하라
사내 보고서 Skill의 가장 중요한 설계 원리 하나를 꼽자면, 단일 출력으로 끝내지 않는 것이다. 조직에서는 흔히 같은 사안을 두 층으로 봐야 한다. 위쪽에는 빠르게 판단할 요약이 필요하고, 아래쪽에는 근거와 세부 설명이 필요하다. 이를 분리하지 않으면 두 가지 실패가 번갈아 나타난다. 임원용 보고서가 너무 길어지거나, 실무 보고서가 너무 얇아진다.
임원용 1페이지의 목적은 설명이 아니라 판단 지원이다. 이 문서에서 가장 먼저 보여야 하는 것은 상세한 경과가 아니라, 지금 무슨 일이 벌어졌고 무엇을 결정해야 하는가다. 따라서 임원용 보고서는 압축 기준이 아주 강해야 한다.
반면 실무용 상세 보고는 맥락과 근거가 중요하다. 어떤 데이터에서 이런 결론이 나왔는지, 어떤 예외가 있었는지, 왜 특정 일정이 늦어졌는지 같은 내용은 여기서 설명해야 한다. 즉, 임원용 보고서가 방향을 제시한다면, 실무용 보고서는 설명 책임을 진다.
이 둘을 나누는 가장 쉬운 기준은 문서가 답해야 할 질문을 다르게 잡는 것이다.
임원용 1페이지는 '무슨 일이 있었고, 왜 중요하며, 무엇을 결정해야 하는가'에 답한다.
실무용 상세 보고는 '어떤 근거로 이런 판단을 했고, 세부적으로 무엇이 진행 중인가'에 답한다.
부록이나 첨부 자료는 '원자료를 어디서 확인할 수 있는가'를 제공한다.
보고서 Skill이 이 구조를 갖추면 같은 자료로도 서로 다른 독자에게 맞는 출력이 가능해진다. 그리고 바로 이 지점에서 조직형 Skill의 가치가 커진다. 한 번 정한 기준이 반복 가능한 자산이 되기 때문이다.
요약 기준: 무엇을 남기고 무엇을 버릴 것인가
보고서는 많이 담는 문서가 아니라, 덜어내는 문서다. 그런데 에이전트는 기본적으로 자료를 많이 읽을수록 안심하는 경향이 있다. 그래서 요약 기준을 따로 넣어주지 않으면, 중요하지 않은 배경 설명까지 성실하게 끌어온다. 읽는 사람은 친절하다고 느끼기보다 피곤하다고 느낀다.
사내 보고서 Skill에는 최소한 다음 기준이 있어야 한다.
먼저 남겨야 할 것은 의사결정에 영향을 주는 사실이다. 목표 대비 차이, 일정 지연의 원인, 고객 영향, 비용 변화, 법무나 보안 리스크, 부서 간 의존성처럼 선택을 바꿀 수 있는 정보는 남겨야 한다.
반대로 버려도 되는 것은 진행 경과의 세세한 나열이다. 이미 끝난 작업의 상세 과정, 결론을 바꾸지 않는 작은 수치 변동, 맥락 없이 붙는 배경 설명, 책임자 없는 희망사항은 과감히 줄여야 한다.
실전에서는 다음 규칙이 특히 유용하다.
숫자는 의미와 함께 쓴다. 수치만 나열하지 않는다.
문제는 현상과 원인을 나눈다. 둘을 섞지 않는다.
지연, 리스크, 이슈는 영향 범위와 대응 상태를 함께 쓴다.
좋아진 점도 쓰되, 판단에 중요한 변화만 남긴다.
아직 확인되지 않은 내용은 결론처럼 쓰지 않는다.
예를 들어 매출 전환율이 2퍼센트포인트 떨어졌다면, 그것만 쓰는 것으로는 부족하다. 어느 구간에서 하락했는지, 일시적인지 구조적인지, 고객 경험이나 캠페인 변경과 관계가 있는지까지 붙어야 한다. 반대로 단순한 트래픽 등락이 전체 결정을 바꾸지 않는다면 부록으로 보내는 편이 낫다.
임원용 1페이지 템플릿을 고정하라
임원용 보고는 자유롭게 쓰게 두지 않는 편이 좋다. 자유도가 높을수록 사람마다 문서 구조가 달라지고, 에이전트도 매번 다른 판단을 하게 된다. 한 장짜리 요약은 특히 형식이 곧 품질이다.
가장 실전적인 템플릿은 다음과 같은 구조다.
## 임원용 1페이지 보고
### 한 줄 결론
이번 보고에서 가장 먼저 알아야 할 사실을 한 문장으로 정리한다.
### 핵심 변화
목표 대비 변화, 중요한 지표, 고객 또는 운영 영향만 짧게 정리한다.
### 리스크
현재 가장 큰 리스크 1~3개와 영향 범위를 쓴다.
### 필요한 의사결정
지금 승인 또는 판단이 필요한 항목을 명시한다.
### 다음 액션
담당자, 기한, 기대 결과를 함께 적는다.
### 참고
세부 근거 문서는 별첨 또는 링크로 연결한다.이 템플릿이 좋은 이유는 아름다워서가 아니라, 읽는 사람이 문서 위에서 길을 잃지 않게 하기 때문이다. 임원은 대개 전체 과정을 알고 싶어 하기보다, 현재 상태와 선택지를 빠르게 파악하고 싶어 한다. 따라서 한 줄 결론, 리스크, 의사결정, 다음 액션의 순서를 고정해두면 문서가 훨씬 강해진다.
실전에서는 길이 제한도 함께 두는 편이 좋다. 예를 들어 한 줄 결론은 두 문장을 넘기지 않게 하고, 핵심 변화는 세 항목 안쪽으로 정리하고, 리스크는 우선순위가 높은 것부터 세 개 이내로 제한하면 보고가 훨씬 선명해진다.
실무용 상세 보고는 근거와 맥락을 책임진다
상세 보고는 임원용 요약을 풀어 쓰는 문서가 아니다. 더 정확히 말하면, 요약의 근거가 되는 작업 로그이자 설명 문서에 가깝다. 따라서 구조도 달라야 한다.
실무용 보고에는 보통 이런 요소가 필요하다.
배경과 목적
현재 상태와 진행률
세부 이슈와 원인
대응 현황과 대안
필요한 지원 사항
원자료 링크와 근거 표
이 문서에서는 세부 사항을 충분히 다뤄도 되지만, 그렇다고 무조건 길어야 하는 것은 아니다. 핵심은 모든 설명이 의사결정과 연결되어 있어야 한다는 점이다. 보고서 Skill은 실무용 문서에서도 단순한 일지처럼 흐르지 않게 해야 한다. 진행 상황을 적더라도, 왜 중요한지와 다음 판단에 어떤 영향을 주는지를 함께 적게 만드는 편이 좋다.
리스크, 의사결정, 다음 액션은 반드시 구조화하라
사내 보고서에서 가장 자주 빠지는 것은 사실 의외로 핵심이다. 문제가 있다는 말은 있는데 리스크가 정리되어 있지 않고, 검토가 필요하다고 쓰여 있는데 누가 무엇을 결정해야 하는지 빠져 있는 경우가 많다. 이런 문서는 읽고 나면 뭔가 알게 된 것 같지만, 정작 무엇을 해야 할지는 남지 않는다.
그래서 보고서 Skill에는 이 세 요소를 구조적으로 강제해야 한다. 특히 리스크는 감정 표현이 아니라 관리 가능한 단위로 써야 한다.
## 리스크 정리
- 리스크명:
- 현재 상태:
- 영향 범위:
- 발생 가능성:
- 대응 상태:
- 추가로 필요한 결정:
## 의사결정 요청
- 결정 주제:
- 선택지:
- 추천안:
- 추천 이유:
- 결정 지연 시 영향:
## 다음 액션
- 액션 항목:
- 담당자:
- 마감일:
- 완료 조건:이 구조가 중요한 이유는, 보고서를 읽는 사람이 '무엇이 문제인가'뿐 아니라 '어떻게 다뤄야 하는가'까지 한 번에 볼 수 있게 하기 때문이다. 좋은 조직형 Skill은 문제를 잘 설명하는 수준에서 멈추지 않는다. 문제를 관리 가능한 업무 단위로 변환한다.
또한 리스크는 상태 표현도 표준화하는 편이 좋다. 예를 들어 '관찰 중', '대응 중', '확대 위험', '해소됨'처럼 상태값을 제한하면 에이전트가 모호한 표현을 덜 쓰게 된다. '상황을 지켜보는 중' 같은 문장은 듣기에는 부드럽지만, 실제로 무엇을 하고 있는지 알기 어렵다.
회사 문체와 금지 표현을 Skill에 넣는 법
사내 보고서의 품질은 정보의 정확성만으로 결정되지 않는다. 조직이 익숙하게 받아들이는 문체도 중요하다. 어떤 회사는 단정하고 짧은 문장을 선호하고, 어떤 회사는 배경 설명을 먼저 쓰는 편을 좋아한다. 어떤 회사는 추정 표현을 매우 싫어하고, 어떤 회사는 불확실성을 명시하는 방식을 오히려 선호한다. 이 차이를 Skill에 넣지 않으면 문서는 매번 다른 사람 말투를 흉내 낸 것처럼 흔들린다.
문체 규칙은 거창할 필요가 없다. 다만 실제로 작동해야 한다. 예를 들어 다음과 같은 규칙이 유용하다.
결론을 먼저 쓰고 근거를 뒤에 붙인다.
한 문장에는 하나의 판단만 담는다.
책임 주체가 없는 수동형 표현을 줄인다.
모호한 긍정 표현보다 상태와 근거를 쓴다.
불확실한 내용은 추정, 확인 중, 가정으로 명시한다.
금지 표현 목록도 따로 두는 편이 좋다. 조직 보고에서 자주 문제를 만드는 표현은 대개 비슷하다.
문제없음
순조롭게 진행 중
검토 필요
빠른 시일 내
최대한 대응 예정
이 표현들의 공통점은 부드럽지만 정보가 없다는 점이다. 예를 들어 '검토 필요' 대신 '재무팀 확인 후 5월 8일까지 확정 필요'라고 쓰면 바로 행동 가능한 문장이 된다. Skill은 이런 변환을 자동으로 유도해야 한다.
폴더 구조는 보고 절차를 반영해야 한다
이 프로젝트도 SKILL.md 하나로 시작할 수는 있다. 그러나 실제 조직에서 쓰기 시작하면 곧 자료가 많아진다. 보고서 템플릿, 문체 규칙, 승인 체크리스트, 리스크 상태값, 요약 기준이 한 파일에 섞이면 관리하기 어렵다. 따라서 프로젝트용 Skill은 폴더 구조를 나누는 편이 훨씬 낫다.
internal-report-writer/
├── SKILL.md
├── references/
│ ├── source-priority-rules.md
│ ├── executive-summary-rules.md
│ ├── writing-style-guide.md
│ ├── risk-status-guide.md
│ └── final-review-checklist.md
├── assets/
│ ├── report-intake-form.md
│ ├── executive-one-page-template.md
│ ├── detailed-report-template.md
│ ├── risk-decision-action-template.md
│ └── forbidden-phrases.md
└── scripts/
├── merge_source_index.py
├── metric_normalizer.py
└── deadline_checker.py여기서 핵심은 역할 분리다. SKILL.md는 전체 작업 순서를 지휘하고, 기준 문서는 references에 둔다. 실제 출력 형식은 assets에 두고, 반복 계산은 scripts로 분리한다. 예를 들어 여러 부서가 보낸 숫자의 형식이 다를 때 metric_normalizer.py 같은 스크립트가 단위와 날짜 형식을 맞춰주면, 에이전트는 해석과 요약에 더 집중할 수 있다.
최종 검토와 승인 절차를 Skill 안에 넣어라
조직형 보고 Skill이 개인용 글쓰기 Skill과 다른 지점이 여기서 분명해진다. 보고서는 결과물을 잘 만드는 것만으로 끝나지 않는다. 누가 검토하고, 어떤 확인을 통과해야 하며, 언제 사람의 승인을 받아야 하는지가 포함되어야 한다.
가장 실전적인 승인 절차는 대개 네 단계면 충분하다.
사실 검토: 숫자, 일정, 상태값을 원자료 소유자가 확인한다.
문체 검토: 보고 책임자나 스태프가 조직 문체와 민감도 표현을 확인한다.
의사결정 검토: 요청 사항과 리스크 표현이 실제 경영 판단에 맞는지 확인한다.
최종 승인: 발송 권한을 가진 사람이 배포 또는 공유를 승인한다.
이 절차를 Skill에 넣어두면 에이전트가 스스로 멈춰야 할 순간도 분명해진다. 예를 들어 미확정 재무 수치가 포함되어 있거나, 특정 부서의 책임 소재가 민감하게 표현되어 있거나, 인사 관련 내용이 들어간 경우에는 자동으로 '사람 승인 필요' 상태를 표시하게 만들 수 있다.
좋은 보고서 Skill은 똑똑하게 쓰는 것만큼, 위험할 때 멈추는 법도 알아야 한다.
SKILL.md 초안 예시
이제 이번 프로젝트의 뼈대를 실제 문서 형태로 보자. 아래 초안은 조직형 보고 Skill의 출발점으로 쓰기 좋은 단순화 버전이다.
---
name: internal-report-writer
description: Create internal reports from raw materials such as dashboards, meeting notes, project updates, issue logs, and approved documents. Use when the user needs an executive one-page report, an internal status report, or a decision-ready summary.
---
## Purpose
Turn scattered internal materials into decision-ready reports that match company style and approval flow.
## Activation
Use this skill when the task involves:
- writing an executive summary for leadership
- producing a weekly, monthly, or project status report
- summarizing risks, decisions, and next actions from multiple inputs
- converting raw operational materials into a structured internal document
## Workflow
1. Collect missing inputs using `assets/report-intake-form.md`.
2. Identify the report audience, purpose, time range, and approval owner.
3. Gather raw materials and classify them by source type.
4. Apply source priority rules from `references/source-priority-rules.md`.
5. If important facts conflict, flag the conflict instead of guessing.
6. Separate outputs into executive one-page and detailed working report when needed.
7. Summarize only decision-relevant facts.
8. Structure the report into risk, decision, and next action using `assets/risk-decision-action-template.md`.
9. Apply company tone and remove forbidden expressions.
10. Run final checks using `references/final-review-checklist.md`.
11. If the report includes sensitive or unconfirmed information, stop and request human approval.
## Rules
- Never invent numbers, dates, owners, or completed actions.
- Do not merge unofficial comments into facts without marking them as unverified.
- Prefer explicit owners and deadlines over vague status language.
- Executive reports must start with conclusion and required decision.
- Detailed reports must include evidence or source links for major claims.
- If a point is uncertain, label it clearly.이 초안의 핵심은 보고서를 잘 쓰라는 주문이 아니라, 어떤 순서로 신뢰 가능한 문서를 만들 것인가를 고정한다는 데 있다. 사내 보고서는 특히 이 순서가 중요하다. 정보가 많을수록 문서가 좋아지는 것이 아니라, 정리 기준이 선명할수록 문서가 좋아진다.
실행 예시: 월간 사업 현황 보고를 만들어보자
이 Skill이 실제로 어떻게 움직이는지 간단한 예시로 보자. 사용자가 '이번 달 사업 현황을 임원 보고용 1페이지와 실무용 상세 보고로 정리해줘'라고 요청했다고 가정해보자.
좋은 Skill은 곧바로 초안을 쓰지 않는다. 먼저 인테이크 폼으로 주요 독자가 누구인지, 어떤 기간을 다루는지, 어떤 의사결정을 지원하려는 문서인지 확인한다. 이어서 대시보드 수치, 영업팀 주간 메모, 고객 이슈 목록, 프로젝트 진행 현황 문서를 원자료로 모은다.
그다음 자료를 같은 무게로 다루지 않는다. 매출과 전환율은 공식 대시보드 기준으로 정리하고, 일정 지연 배경은 프로젝트 문서와 회의록으로 보강한다. 메신저에서 나온 의견은 중요한 단서일 수는 있지만, 사실처럼 쓰지 않고 확인 필요 항목으로 표시한다.
이후 에이전트는 핵심 질문을 붙잡는다. 이번 보고서가 답해야 할 질문이 '이번 달 목표 달성 여부와 다음 달 우선순위'라면, 거기에 직접 연결되지 않는 설명은 과감히 줄인다. 그리고 임원용 1페이지에는 한 줄 결론, 핵심 변화, 주요 리스크, 필요한 의사결정, 다음 액션만 남긴다. 실무용 보고에는 지표 변동 배경, 채널별 성과 차이, 일정 지연 원인, 대응 계획, 원자료 링크를 붙인다.
마지막 단계에서는 회사 문체 규칙을 적용한다. 예를 들어 '순조롭게 진행 중' 같은 표현은 삭제하고, '2개 과제는 계획 대비 1주 지연, 원인은 외부 벤더 승인 지연'처럼 상태와 원인을 분리해 적는다. 승인 단계에서는 숫자 소유자와 보고 책임자가 각각 사실과 문체를 확인한 뒤 최종 배포 여부를 결정한다.
이렇게 만들어진 보고서는 단순히 보기 좋은 문서가 아니다. 조직이 정보를 모으고, 압축하고, 판단하는 방식이 그대로 들어 있는 문서다.
이 프로젝트에서 자주 생기는 실패
첫 번째 실패는 원자료를 충분히 모으지 않고 바로 쓰는 것이다. 특히 회의 메모만 가지고 보고서를 쓰면 맥락은 있지만 사실이 약해진다.
두 번째 실패는 모든 자료를 같은 비중으로 취급하는 것이다. 공식 수치와 개인 의견이 같은 무게로 들어가면 문서가 흔들린다.
세 번째 실패는 임원용과 실무용 출력을 나누지 않는 것이다. 그러면 위에는 너무 길고, 아래에는 너무 얕은 문서가 나온다.
네 번째 실패는 리스크를 설명만 하고 관리 단위로 바꾸지 않는 것이다. 문제를 적었는데 담당자와 마감일이 없으면, 문서는 읽혔을 뿐 움직이지 않는다.
다섯 번째 실패는 회사 문체를 무시하는 것이다. 내용이 맞아도 조직이 익숙하지 않은 말투와 표현은 신뢰를 떨어뜨린다.
여섯 번째 실패는 승인 절차를 빼먹는 것이다. 특히 민감하거나 미확정인 내용이 들어가는 보고서는 마지막 사람 검토가 필수다.
마무리
사내 보고서 Skill의 핵심은 문장을 잘 다듬는 데 있지 않다. 조직이 흩어진 정보를 어떻게 판단 가능한 문서로 바꾸는지를 절차로 고정하는 데 있다. 원자료를 수집하고, 신뢰도와 우선순위를 구분하고, 임원용 1페이지와 실무용 상세 보고를 분리하고, 리스크와 의사결정과 다음 액션을 구조화하고, 회사 문체와 승인 절차까지 포함하면 비로소 보고서가 재사용 가능한 Skill이 된다.
이 구조가 갖춰지면 에이전트는 더 이상 '보고서 좀 써주는 도우미'가 아니다. 조직의 사고방식과 실행 흐름을 재현하는 내부 보고 시스템이 된다. 그리고 바로 그 점이 Agent Skill 설계의 진짜 매력이다. 한 번 잘 만든 절차가, 다음 보고서부터는 팀의 기본 능력으로 남는다.
다음 장에서는 이 흐름을 코드 작업으로 옮겨간다. 문서형 Skill이 조직의 의사결정을 패키징했다면, 코드 리뷰 Skill은 개발 조직의 품질 기준을 패키징하는 사례가 될 것이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.