01. 보고하기 — 상황을 상대의 머릿속에 정확히 옮겨 담기
“보고는 ‘내가 한 일 나열’이 아니라 ‘상대가 궁금할 것의 답’이다.”
📍 어떤 상황인가
이 매뉴얼은 다음 순간에 꺼냅니다.
🗣 상사: "지금 어떻게 돼가?"
🗣 동료: "그거 진행 상황 좀 공유해줄래?"
🗣 팀: "주간 보고 준비해서 올려줘"
🗣 고객: "저번에 말씀드린 건 어떻게 됐나요?"모든 문장의 본질은 하나입니다.
“내가 모르는 걸 네가 아는 것 같으니, 알려줘.”
보고는 “내가 한 일을 증명”하는 자리가 아니라, 상대의 빈 칸(불확실성)을 내가 가진 정보로 채워주는 행위입니다. 이 관점을 놓치면 “일 많이 했는데 보고는 별로다”라는 평가를 받게 됩니다.
🧩 먼저 알아둘 용어
이 문서에서 반복해서 쓰는 용어를 먼저 정리합니다.
수신자(Receiver) = 내 보고를 듣는/읽는 사람. 상사·동료·고객 등. 이 단어를 쓰는 이유: 보고는 “말하는 사람”이 아니라 듣는 사람을 중심으로 설계해야 하기 때문입니다.
Lead (리드) = “앞에 내보이다”라는 영어 단어. 신문 기사 첫 문단을 “Lead”라고 부릅니다. 이 매뉴얼에서 “Lead 문장”은 보고의 첫 한 줄을 뜻합니다. 이 첫 줄이 90%를 결정합니다.
Context (컨텍스트) = “함께 엮인 것”이라는 영어 단어 (con = 함께, text = 짜인 것). 상황 배경, 전제, 지금까지 있었던 일처럼 **“그 사실을 이해하는 데 필요한 주변 정보”**를 뜻합니다.
🧠 생각의 흐름 — 보고 5단계
보고는 말을 꺼내기 전에 머릿속에서 이 5단계를 거쳐야 합니다. 말이 꼬이는 사람은 이 순서를 건너뛰고 바로 입부터 엽니다.
┌──────────────────────────────────────────────────┐
│ │
│ ① 수신자 파악 — 누가, 왜 궁금한가? │
│ ↓ │
│ ② 결론 선정치 — 한 줄로 요약 (Lead) │
│ ↓ │
│ ③ 근거 세우기 — 결론을 받치는 2~3개 사실 │
│ ↓ │
│ ④ 다음 행동 — 그래서 뭘 어떻게? │
│ ↓ │
│ ⑤ 리스크 밝힘 — 모르는/불확실한 것 │
│ │
└──────────────────────────────────────────────────┘각 단계를 자세히 봅니다.
① 수신자 파악 — 누가, 왜 궁금한가?
왜 이 단계가 먼저인가: 같은 사실도 듣는 사람에 따라 필요한 깊이가 다릅니다. CEO에게는 “매출에 어떤 영향?”이 먼저고, 개발자에게는 “어느 파일에서 깨졌는가?”가 먼저입니다. 수신자를 생각하지 않으면 **“자기가 하고 싶은 얘기”**만 하게 됩니다.
체크 질문
✓ 이 사람이 이 보고를 받는 목적은?
- 상태 확인? 의사결정? 문제 해결?
✓ 이 사람이 이미 아는 것은?
- 배경 설명을 어디까지 생략해도 되나?
✓ 이 사람이 하고 싶은 "다음 행동"은?
- 보고 받은 뒤 바로 뭘 해야 하는가?예시
같은 사실 "서버가 3시간 다운됐음"
→ 엔지니어 팀장에게:
"어느 컴포넌트에서 언제부터 다운됐고, 재발 방지는?"이 관심사
→ 영업 담당에게:
"고객 피해 규모는 얼마고, 어떻게 안내해야 하나?"가 관심사
→ CEO에게:
"손실 규모와 외부 노출 여부"가 관심사즉 동일 사실에 대해 3종류의 보고가 필요합니다.
② 결론 선정치 (Lead) — 한 줄로 요약
왜 결론부터 오는가: 수신자는 바쁩니다. 첫 문장에서 “들을지 말지”를 판단합니다. 배경부터 장황하게 깔면 수신자는 중간에 “그래서 결론이 뭐야?”를 속으로 외치고 있습니다.
Lead 한 줄의 구조
[대상] 이 [어떤 상태] 이다. (+ 핵심 수치 또는 기한)❌ 나쁜 Lead
❌ "어제부터 오늘까지 여러 가지를 해봤는데요..."
→ 이게 시작되면 수신자는 "3분 날아간다" 직감.
❌ "좀 복잡한데요, 일단 말씀드리면..."
→ 복잡함을 전가당하는 느낌. 결론이 어디 있는지 모름.
❌ "결론부터 말씀드리면 애매한데..."
→ 결론이라고 해놓고 애매 → 최악.✅ 좋은 Lead
✅ "A 기능 출시는 예정대로 3/20 가능합니다. 단 B 기능은 1주 지연 필요합니다."
→ 결론 + 범위 + 변경 사항이 한 줄에.
✅ "서버는 오전 10시부터 정상 복구됐고, 원인은 X였습니다. 재발 방지 조치 중입니다."
→ 현재 상태 + 원인 + 다음 행동이 한 줄에.
✅ "계약 검토 중 3가지 리스크를 발견했습니다. 2가지는 해결, 1가지는 결정 필요합니다."
→ 규모 + 결과 + 수신자가 할 일이 한 줄에.💡 Lead를 쓰는 훈련
입 열기 전에 “이걸 트위터 140자로 줄이면?” 이라고 자문해보세요. 이게 안 되면 본인도 정리가 안 된 상태입니다. 이때 바로 말하지 말고 30초만 생각을 더 하세요.
③ 근거 세우기 — 결론을 받치는 2~3개 사실
왜 “2~3개”인가: 근거가 1개면 약하고, 4개 이상이면 듣는 사람이 못 따라옵니다. 인간의 작업기억은 한 번에 3~4개가 한계입니다. 이를 넘기면 앞부분이 휘발됩니다.
근거의 품질 기준
✓ 사실인가? (추측·의견·감정이 섞여 있지 않은가)
✓ 검증 가능한가? (숫자·로그·기록·증거가 있는가)
✓ 결론과 직접 연결되는가? (관련 없는 정보는 혼란만 줌)예시 — 결론: “출시는 예정대로 가능”
근거 ①: 핵심 기능 개발 100% 완료 (PR 머지 완료)
근거 ②: QA 라운드 2회 완료, 치명 버그 0건
근거 ③: 인프라 배포 스크립트 리허설 성공각 근거는 한 줄로 읽히고, 수치 또는 사실이 달려 있어야 합니다.
⚠️ 흔한 함정: 근거 가장한 감정
❌ "저희 팀이 엄청 고생했어요" → 근거 아님 (감정)
❌ "아마 잘 될 거예요" → 근거 아님 (추측)
✅ "테스트 100건 중 98건 통과, 실패 2건은 재현 안 됨" → 근거 (사실)④ 다음 행동 — 그래서 뭘 어떻게?
왜 이 단계가 있나: 보고를 받은 수신자는 반드시 “그래서 내가 뭘 해야 하지?”를 묻습니다. 이 질문에 답을 주지 않으면 보고의 쓸모가 없습니다.
다음 행동은 누구의 것인가?
- 내가 할 일 → 언제까지 무엇을 하겠다고 선언
- 상대가 할 일 → 결정·확인·승인이 필요한 것
- 누군가 해야 할 일 → 담당이 정해지지 않은 것 (상대에게 할당 요청)예시
"다음 행동입니다:
- (제가) 3/18까지 최종 QA 리포트 공유
- (팀장님) 3/19 오전까지 릴리즈 승인 확인 필요
- (담당 미정) 출시 후 사용자 안내문 — 마케팅팀에 요청 가능할까요?"수신자 입장에서 “읽고 나면 바로 움직일 수 있는” 상태가 되어야 합니다.
⑤ 리스크 밝힘 — 모르는 것, 불확실한 것
왜 약점을 굳이 밝히나: 감추면 나중에 더 크게 터집니다. 프로의 보고는 “내가 확신하는 것”과 “확신 못 하는 것”을 명시적으로 분리합니다.
리스크 표기의 3가지 유형
🟢 확정 — 이미 사실인 것 (일어났거나 확실한 것)
🟡 예상 — 현재 추세로 보면 ~일 것 (아직 일어나지 않음)
🔴 불확실 — 데이터 부족으로 판단 유보 (검증 필요)예시
🟢 핵심 기능 A는 개발 완료, QA 통과.
🟡 3rd-party API 응답 속도가 예상보다 느림 — 출시 영향은 경미할 것으로 예상.
🔴 트래픽 피크 시간대 부하 테스트 미완료 — 3/19까지 확인 후 공유 예정.수신자는 🔴 표시를 보고 “이건 내가 주시해야겠다” 라고 자동 분류합니다. 감추지 않고 밝히면 오히려 신뢰가 올라갑니다.
📋 체크리스트 — 보고 전에 30초
입 열기 전, 키보드 치기 전에 이 항목을 점검하세요.
┌─────────────────────────────────────────────────┐
│ 🧠 보고 전 30초 체크리스트 │
├─────────────────────────────────────────────────┤
│ │
│ □ 수신자가 지금 가장 궁금한 게 뭔지 아는가? │
│ □ 첫 한 줄(Lead)로 결론을 말할 수 있는가? │
│ □ 결론을 받치는 근거가 2~3개 준비됐는가? │
│ □ 수신자가 읽고 바로 할 행동이 명시됐는가? │
│ □ 불확실한 부분을 🔴로 표시할 수 있는가? │
│ │
│ (5개 중 하나라도 NO이면 아직 보고하지 마세요) │
│ │
└─────────────────────────────────────────────────┘💬 스크립트 예시
예시 1: 구두 보고 (회의에서 즉석으로)
"[Lead]
A 기능 출시는 3/20 예정대로 가능합니다. B 기능은 1주 지연이 필요합니다.
[근거]
1) A는 QA 2라운드 통과, 치명 버그 0건
2) B는 3rd-party API 이슈로 일부 시나리오 실패 2건 남음
3) B 수정에 2~3일, 재검증에 3~4일 예상
[다음 행동]
- 제가 3/18까지 A 릴리즈 체크리스트 공유
- B는 3/27 출시로 일정 변경을 제안드리는데, 오늘 중 결정 부탁드립니다
[리스크]
🔴 3rd-party 응답 시간이 피크 시간대에 어떤지는 아직 측정 못 했습니다.
3/19까지 확인해서 다시 공유하겠습니다."예시 2: 메신저 보고 (Slack 등 짧은 글)
📌 A 기능 출시 예정대로(3/20) 가능 / B 기능은 1주 지연 필요
▫️ 현황
• A: QA 2라운드 통과, 치명 버그 0
• B: 3rd-party API 이슈로 실패 2건 (수정+재검증 1주)
▫️ 요청
• B 출시일 3/27로 변경 가능한지 오늘 중 결정 요청드립니다.
▫️ 리스크
• 피크 타임 부하 테스트 미완료 (3/19까지 확인 예정)예시 3: 주간 보고 (문서 양식)
# 주간 보고 — 2026 W16
## 한 줄 요약
A 기능 출시 예정대로. B 기능 1주 지연 필요.
## 이번 주 완료
- A 기능 QA 2라운드 통과 (치명 0 / 경미 3건 수정 완료)
- 인프라 리허설 성공
- 고객 안내문 초안 작성
## 다음 주 계획
- A 기능 릴리즈 (3/20)
- B 기능 API 이슈 수정 및 재검증
- 고객 안내 전달 (마케팅팀 연계)
## 의사결정 요청
- B 출시일 3/27 변경안 승인 — 기한 3/19 오전
## 리스크 / 이슈
- 🔴 피크 타임 부하 테스트 미완료 → 3/19까지 완료 예정
- 🟡 3rd-party API 응답 지연 추세 → 경미, 모니터링 중⚠️ 흔한 실수 5가지
실수 1: “일기형 보고”
증상: “월요일에는 A를 했고, 화요일에는 B를 했고…” 식의 시간순 나열. 왜 나쁜가: 수신자는 시간순이 아니라 중요도순으로 듣고 싶어합니다. 교정: 결론 → 근거 → 다음 행동 순서로 재배열.
실수 2: “증빙형 보고”
증상: “저희는 ~했고, ~도 했고, ~까지 해냈습니다” 식의 활동량 증명. 왜 나쁜가: 수신자는 당신이 얼마나 고생했는지를 듣고 싶은 게 아닙니다. 교정: “고생”은 빼고, “결과”와 “수치”만 남긴다.
실수 3: “추상형 보고”
증상: “대체로 괜찮은 것 같고, 이슈는 일부 있는데 곧 해결될 것 같습니다.” 왜 나쁜가: “대체로”, “일부”, “곧”이 전부 측정 불가능한 단어입니다. 교정: 숫자·기한·구체 대상으로 바꾼다.
❌ "대체로 괜찮고 곧 해결"
✅ "3건 중 2건 해결 / 남은 1건은 3/22까지 해결 예정"실수 4: “과잉 배경설명형 보고”
증상: 3분 배경 설명 후에야 본론 등장. 수신자는 이미 멀리 떠남. 왜 나쁜가: 배경은 수신자가 모를 때만 필요합니다. 이미 아는 사람에게 되풀이하면 시간 낭비. 교정: “이거 말씀드리기 전에 배경 아시죠?”로 확인 → 모르는 부분만 추가.
실수 5: “리스크 숨기기”
증상: 안 좋은 부분을 말 안 하고 넘어감. 나중에 터짐. 왜 나쁜가: 보고의 신뢰도는 “나쁜 소식을 먼저 말하는가” 로 결정됩니다. 교정: 🔴를 먼저 말한다. 감추지 않는 사람이 장기적으로 신뢰받는다.
🧩 미니 연습
다음 상황을 5단계 구조로 30초 안에 정리해보세요. 머릿속이 아니라 종이에 직접 써보는 것을 권장합니다.
연습 1
상황: 프로젝트 중간에 예상치 못한 버그가 발견됐고,
해결에 2일 더 필요. 전체 일정은 그대로 지킬 수 있음.
팀장에게 구두 보고.풀이 힌트 보기
Lead "일정은 유지, 중간 버그 때문에 2일 재할당 필요합니다."
근거 ① 버그 재현·원인 파악 완료
② 수정에 2일 소요 예상
③ 버퍼 3일 있어서 마감 영향 없음
다음 (제가) 수정 진행 → (팀장님) 특별한 액션 없음, 공유 목적
리스크 🟡 수정 중 다른 이슈 발견 가능성 — 발견 시 즉시 재공유연습 2
상황: 고객이 지난주에 문의한 건에 대해 아직 답변 못 함.
실은 담당자가 휴가였고, 복귀 후 처리 중. 고객에게 메신저로 공유.풀이 힌트 보기
Lead "지난 문의 건 처리 중이며 3/22까지 답변 드리겠습니다."
근거 ① 담당자 휴가로 지연됐음을 설명 (사실만, 변명 톤 금지)
② 현재 처리 단계 명시 (확인 중 / 해결안 준비 중 / 검토 중)
다음 "3/22 오전 중 상세 답변 드리겠습니다." + "그전에 급한 질문 있으시면 바로 답변"
리스크 없음 (혹은 추가 자료 필요 시 미리 요청)포인트: 사과로 시작하지 말 것. 사과는 마지막 한 줄로 짧게.
❌ "정말 죄송합니다 죄송합니다 저희가..." (3줄 사과 후 본론)
✅ "처리 중입니다 [본론]. 지연드려 죄송합니다." (본론이 앞)📌 핵심 요약
- 보고는 “내 활동 증명”이 아니라 “수신자의 빈칸 채우기” 이다.
- 순서는 수신자 파악 → Lead(결론) → 근거 → 다음 행동 → 리스크.
- 첫 한 줄(Lead)에 결론이 안 들어가면 다시 정리하고 말해라.
- 근거는 2~3개의 사실만. 4개 이상은 수신자가 놓친다.
- 나쁜 소식은 먼저 밝혀라. 감추면 신뢰가 깎이고, 밝히면 신뢰가 쌓인다.
- “대체로 / 일부 / 곧” 을 숫자와 기한으로 바꿔라.
- 보고 전 30초 체크리스트를 지나치지 말 것. 습관이 되면 무의식으로 통과된다.
보고를 잘하는 사람은 “말을 잘하는 사람”이 아니라 “듣는 사람 입장에서 1초 먼저 생각해본 사람”이다.
Comments
// admin login