01보고서를 만드는 데 드는 진짜 비용
주간보고 하나가 만들어지는 과정을 되짚어 봅시다.
팀원들이 각자 한 주를 정리해 팀장에게 보냅니다. 팀장이 취합해 다듬습니다. 본부에서 다시 취합합니다. 임원 보고용으로 한 번 더 요약합니다. 이 과정에서 같은 내용이 네 번 쓰이고, 단계마다 조금씩 각색됩니다.
그리고 임원이 실제로 읽는 데 걸리는 시간은 5분입니다.
비용은 시간만이 아닙니다. 정보가 위로 갈수록 나빠진다는 게 더 큰 문제입니다. 각 단계에서 부정적인 내용이 완화되고, 숫자는 유리하게 반올림되며, 리스크는 "대응 중"으로 바뀝니다. 경영진에게 도달할 때쯤이면 이미 늦습니다.
02새벽에 벌어지는 일
컴키는 이 취합 과정을 배치 파이프라인으로 대체했습니다. 매일 새벽, 사람 손 없이 아래가 순서대로 돌아갑니다.
임원이 출근길에 메일을 열면, 전일 전사 활동이 이미 한 장으로 정리되어 있습니다. 아무도 취합하지 않았고, 아무도 각색하지 않았습니다.
03핵심 원칙 1. 수치는 LLM에게 시키지 않는다
자동 보고서 프로젝트가 실패하는 가장 흔한 이유입니다. "지난주 리스크 건수를 세서 보고서에 써 줘"라고 LLM에게 시키면, 대체로 맞고 가끔 틀립니다. 그리고 그 '가끔'이 경영 보고서에 들어가면 신뢰는 끝납니다.
컴키는 역할을 명확히 나눕니다.
| 담당 | 역할 |
|---|---|
| DB / 집계 배치 | 모든 숫자 — 건수, 비율, 증감, 순위 |
| LLM | 서술 — 맥락 설명, 요약, 시사점 정리 |
집계 배치가 먼저 정확한 수치를 계산하고, 그 값을 프롬프트에 사실로 주입합니다. LLM은 계산하지 않고 주어진 숫자로 문장을 만듭니다. 이 분업 하나로 보고서의 수치 오류가 사라집니다.
04핵심 원칙 2. 문장마다 근거를 단다
자동 생성 보고서에 대한 첫 반응은 언제나 "이거 진짜야?"입니다. 답은 링크로 해야 합니다.
브리핑의 각 문장에는 근거가 된 원본 기록의 ID가 붙습니다. 화면에서 문장을 클릭하면 우측에 원문이 뜹니다. 임원이 "이 건 자세히 보고 싶은데"라고 할 때, 담당자에게 묻지 않고 그 자리에서 원문까지 내려갑니다.
그리고 브리핑은 날짜별 버전 문서로 보존됩니다. 지난달 브리핑을 다시 열면 그 시점의 판단 근거가 그대로 남아 있습니다. 사후에 "그때 우리가 뭘 알고 있었나"를 확인할 수 있다는 것은, 의사결정 품질을 되짚는 데 생각보다 큰 자산입니다.
05핵심 원칙 3. 실패해도 원문은 안전하다
배치는 반드시 실패합니다. 외부 API가 죽고, 모델이 타임아웃 나고, 네트워크가 끊깁니다. 설계의 목표는 실패를 없애는 것이 아니라 실패가 번지지 않게 하는 것입니다.
- DB가 단일 진실원천 — 요약·임베딩·볼트 문서는 전부 DB에서 파생되는 결과물입니다. 파생물이 깨져도 원본은 무사합니다.
- 멱등 재처리 — 같은 배치를 다시 돌려도 중복이 생기지 않습니다. 내용 해시로 이미 처리된 항목은 건너뜁니다.
- 작성 경로와 분리 — 배치가 아무리 밀려도 직원의 기록 저장은 즉시 완료됩니다. AI 지연이 작성 5분을 막지 않는 것이 제1원칙입니다.
06원칙 4. 조직 리듬에 맞춘다
기술보다 운영이 중요한 부분입니다.
- 주말·공휴일 미발송 — 안 읽는 날 오는 메일은 알림 피로만 만듭니다. 공휴일 캘린더를 반영해 자동으로 건너뜁니다.
- 주기별 확장 — 월요일에는 주간 종합, 매월 1일에는 월간 보고가 함께 나갑니다.
- 수신자 동적 구성 — 리더·임원 목록은 조직 데이터에서 자동으로 산출됩니다. 인사이동 때마다 수신자 목록을 손보지 않습니다.
- 주간·월간 스냅샷 보존 — 발행 시점의 수치를 그대로 저장해, 나중에 다시 열어도 당시 숫자가 유지됩니다.
07무엇이 실제로 바뀌었나
- 팀장이 주간 취합에 쓰던 시간이 없어졌습니다. 기록이 곧 보고이기 때문입니다.
- 경영진이 보는 내용과 실무 기록 사이의 왜곡 단계가 사라졌습니다.
- 리스크가 늦게 올라오는 문제가 줄었습니다. 사람이 판단해서 올리는 게 아니라 신호가 자동으로 탐지되기 때문입니다.