같은 결제 모듈 v2 배포, 두 운영팀.
A팀은 새벽 2시에 모여 "일단 배포하고 보자"로 시작합니다. 배포 도중 마이그레이션이 절반에서 멈췄고, 누가 무엇을 먼저 했는지 메모가 없어 되돌리지도 못합니다. 4시가 넘어도 결제가 죽어 있고, 고객 공지도 안 나가 콜센터가 폭주합니다. 아침 보고는 "원인 파악 중"입니다.
B팀은 같은 작업을 합니다. 다만 사흘 전에 변경계획서로 승인을 받았고(무엇을·왜·언제·영향), 당일에는 작업절차서의 단계표를 그대로 따라 한 줄씩 체크하며 진행합니다. 2시 40분, 헬스체크가 빨간불을 띄우자 미리 써 둔 롤백계획서의 조건("3시까지 핵심 거래 정상화 실패 시 원복")에 따라 즉시 되돌립니다. 고객에게는 전날 점검 공지가 나갔고, 아침 보고서에는 "예정대로 점검·이상 감지·롤백·정상 운영 복귀, 원인 분석 후 재시도 예정"이 한 장으로 정리돼 있습니다.
두 팀의 차이는 손이 빠른 게 아니라 반영 전에 무엇을 종이에 적어 두었느냐입니다. 이 모듈은 운영계 반영을 통제하는 문서 3종 세트 — 변경계획서·작업절차서·롤백계획서 — 와 공지·점검 체크리스트를 실제 템플릿으로 작성하는 법을 다룹니다.
- 1변경계획서·작업절차서·롤백계획서 세 문서의 역할 분담과 서로의 관계를 설명할 수 있다
- 2변경계획서에 들어가는 변경내용·사유·일정·영향·승인 항목을 자기 손으로 채울 수 있다
- 3작업절차서를 단계·명령·담당·예상시간·확인사항이 있는 단계표로 작성할 수 있다
- 4롤백계획서에서 원복 조건·절차·데이터 복구·롤백 불가 대비를 구분해 설계할 수 있다
- 5한국 SI/SM의 야간 운영 반영 흐름(공지 → 점검 → 반영 → 점검 체크 → 결과보고)에 문서를 배치할 수 있다
왜 세 개의 문서인가 — 독자와 목적이 다르다
하나의 변경, 세 개의 시선
운영계(실서비스) 반영은 "잘되면 본전, 잘못되면 장애"인 작업입니다. 그래서 반영 전에 세 명의 다른 독자를 위해 세 문서를 씁니다. 같은 변경을 세 번 쓰는 게 아니라, 각자 다른 질문에 답하는 것입니다.
- 변경계획서는 승인권자·이해관계자가 읽습니다. 질문은 "이 변경을 해도 되는가?" 무엇을·왜·언제·무엇에 영향을·누가 승인했는가를 봅니다.
- 작업절차서는 *작업자(때로는 협력사 엔지니어)*가 읽습니다. 질문은 "나는 무엇을 어떤 순서로 하면 되는가?" 단계·명령·담당·예상시간·확인사항을 봅니다.
- 롤백계획서는 장애 직전의 작업자·관리자가 읽습니다. 질문은 "이게 잘못되면 어떻게 되돌리는가?" 원복 조건·절차·데이터 복구·되돌릴 수 없을 때의 대비를 봅니다.
| 문서 | 주 독자 | 답하는 질문 | 작성 시점 |
|---|---|---|---|
| 변경계획서 | 승인권자·이해관계자 | 해도 되는가 (무엇을·왜·언제·영향) | 반영 며칠 전, 승인용 |
| 작업절차서 | 작업자·협력사 | 어떻게 단계별로 하는가 | 반영 전, 리허설과 함께 |
| 롤백계획서 | 작업자·관리자 | 실패 시 어떻게 원복하는가 | 반영 전, 작업절차서와 한 쌍 |
| (작업 공지문) | 고객·사용자 | 언제·무엇이·얼마나 영향받는가 | 반영 전, 공지 채널로 |
| (점검 체크리스트) | 작업자·검증자 | 정상 동작·부작용 없음 확인 | 반영 직후 |
핵심 감각: 롤백계획서는 사후 문서가 아닙니다. 작업이 실패한 뒤 쓰는 게 아니라, 반영 전에 작업절차서와 한 쌍으로 미리 써 두는 '보험증서'입니다. 보험은 사고 나기 전에 드는 것입니다.
확대
그림: 같은 변경을 승인권자·작업자·관리자 세 시선으로 나눠 쓰며, 작업절차서와 롤백계획서는 항상 한 쌍이다.
운영 반영 3종 세트 — 빈 양식 다운로드
변경계획서 — 무엇을·왜·언제·영향·승인
승인을 받기 위한 문서
변경계획서는 "이 변경을 운영계에 반영하겠다"는 신청서이자 통제 기록입니다. 핵심은 승인권자가 리스크를 판단할 수 있을 만큼의 정보를 담는 것입니다. 아래는 그대로 복사해 채울 수 있는 템플릿입니다.
[ 변경계획서 ]
1. 변경 개요
- 변경 ID : CHG-2026-0612-01
- 변경 제목 : 결제 모듈 v2 배포 (PG 연동 라이브러리 교체)
- 변경 유형 : 일반 변경(Normal) / 표준(Standard) / 긴급(Emergency) 중 택1
- 작성자/요청부서 : 홍길동 / 결제플랫폼팀
2. 변경 내용 (무엇을)
- 결제 API 서버 payment-svc 를 v1.8 → v2.0 으로 배포
- DB 스키마 변경: payment 테이블에 컬럼 2개 추가(마이그레이션 030)
- 설정 변경: PG사 엔드포인트 URL 교체
3. 변경 사유 (왜)
- 기존 PG 라이브러리 EOL(지원 종료)로 보안 패치 불가
- 해외 카드 결제 실패율 개선(현 4.1% → 목표 1% 이하)
4. 일정 (언제)
- 점검창(작업 시간) : 2026-06-15(일) 02:00 ~ 04:00 (KST)
- 결정 시한 : 03:00 까지 정상화 실패 시 롤백
- 사전 공지 발송 : 2026-06-13(금) 10:00
5. 영향 분석 (무엇에)
- 영향 서비스 : 결제 서비스(전 고객), 주문 서비스(결제 호출부)
- 영향 범위 : 점검 시간 동안 결제 불가(주문 접수는 가능, 결제만 대기)
- 다운타임 : 예상 10분(배포·마이그레이션), 최대 30분
- 연관 변경/의존성 : 없음 (인벤토리 서비스 무관)
6. 리스크 및 대응
- 리스크 : 마이그레이션 실패 시 결제 테이블 불일치
- 대응 : 롤백계획서(RB-2026-0612-01) 별첨, 사전 DB 백업 수행
7. 승인
- 작업 승인(CAB/변경관리자) : __________ (서명/일시)
- 서비스 책임자(운영) : __________ (서명/일시)
- 고객/발주사 통보 확인 : __________ (담당/일시)
8. 별첨
- 작업절차서 WP-2026-0612-01
- 롤백계획서 RB-2026-0612-01
여기서 자주 비는 칸이 결정 시한과 승인입니다. 결정 시한이 없으면 현장에서 "조금만 더"를 반복하다 점검창을 넘기고, 승인 칸이 비면 "누가 시켰나"가 사라져 사고 시 책임 추적이 안 됩니다.
작업절차서 — 한 줄씩 따라 하는 단계표
작업자가 그대로 실행하는 문서
작업절차서의 목적은 단 하나, 누가 해도 같은 순서로 같은 결과가 나오게 하는 것입니다. 그래서 줄글이 아니라 단계표로 씁니다. 각 단계에는 (1) 무엇을(작업), (2) 어떻게(명령/동작), (3) 누가(담당), (4) 얼마나(예상시간), (5) 어떻게 확인(확인사항)이 들어갑니다.
[ 작업절차서 WP-2026-0612-01 — 결제 모듈 v2 배포 ]
작업창: 2026-06-15 02:00 ~ 04:00 / 결정 시한 03:00
참여: 배포 담당(김), DBA(이), 검증(박), 총괄(홍)
| 단계 | 작업 | 명령/동작 | 담당 | 예상시간 | 확인사항 |
|---|---|---|---|---|---|
| 0 | 점검 모드 전환 | LB에서 결제 트래픽 점검 페이지로 전환 | 김 | 2분 | 사용자에게 점검 안내 노출됨 |
| 1 | 사전 백업 | payment DB 풀백업 + 스키마 스냅샷 | 이 | 10분 | 백업 파일 크기·해시 확인, 복구 테스트 1건 |
| 2 | 현 버전 태깅 | payment-svc v1.8 이미지 태그 보존 | 김 | 2분 | rollback용 이미지 레지스트리에 존재 |
| 3 | 마이그레이션 | migration 030 실행(컬럼 추가) | 이 | 5분 | 마이그레이션 로그 성공, 신규 컬럼 2개 존재 |
| 4 | 신버전 배포 | payment-svc v2.0 롤링 배포 | 김 | 5분 | 파드 전부 Running, 구버전 종료 |
| 5 | 설정 반영 | PG 엔드포인트 URL 교체 후 재기동 | 김 | 3분 | 설정값 v2 PG로 적용됨 |
| 6 | 스모크 테스트 | 헬스체크 + 테스트 카드 결제 1건 | 박 | 5분 | 200 응답, 테스트 결제 승인·취소 정상 |
| 7 | 점검 해제 | LB 트래픽 정상 라우팅으로 복귀 | 김 | 2분 | 실제 사용자 결제 표본 정상 |
| 8 | 반영 후 점검 | 점검 체크리스트 전 항목 확인 | 박·홍 | 10분 | 체크리스트 전 항목 통과 |
표로 쓰면 좋은 점: 작업 중 "지금 몇 단계인가"를 한 손가락으로 가리킬 수 있고, 예상시간 합계로 점검창 안에 끝나는지를 미리 계산할 수 있습니다(위 합계 약 44분 + 여유 = 1시간 내). 또 각 단계의 확인사항이 통과해야 다음으로 넘어가므로, 절반에서 멈춘 채 다음을 진행하는 사고가 줄어듭니다.
롤백계획서 — 실패를 가정하고 미리 쓴다
조건 → 절차 → 데이터 복구 → 롤백 불가 대비
롤백계획서는 조건이 절차보다 먼저입니다. "어떻게 되돌리나"보다 "언제 되돌리기로 정했나"가 핵심입니다. 네 부분으로 구성합니다.
[ 롤백계획서 RB-2026-0612-01 — 결제 모듈 v2 배포 ]
A. 롤백 발동 조건 (언제 되돌리는가)
- 헬스체크가 3회 연속 실패
- 테스트 결제(스모크) 승인 실패 또는 응답 5초 초과
- 결정 시한 03:00 까지 핵심 거래 정상화 미달성
- 위 중 하나라도 해당 시 즉시 롤백 (총괄 홍 판단·선언)
B. 롤백 절차 (어떻게 되돌리는가) — 작업절차서의 역순
1) LB 결제 트래픽을 다시 점검 페이지로 전환
2) payment-svc 를 보존해 둔 v1.8 이미지로 재배포
3) PG 엔드포인트 설정을 v1 값으로 원복
4) (필요 시) DB 마이그레이션 030 다운 스크립트 실행 또는 백업 복구
5) 헬스체크·테스트 결제로 v1.8 정상 확인 후 트래픽 복귀
C. 데이터 복구 (되돌릴 때 데이터는)
- 컬럼 추가만 한 경우: 신규 컬럼은 미사용 상태이므로 데이터 손실 없음,
다운 스크립트로 컬럼 제거 또는 그대로 보존(무해)
- 점검 중 실제 거래가 발생했다면: 점검창 내 트랜잭션 로그 보존,
v1 복구 후 정합성 점검(중복 결제·미정산 건 수동 확인)
- 백업 복구가 필요한 경우: 1단계에서 받은 풀백업으로 시점 복구(PITR)
D. 롤백 불가 대비 (되돌릴 수 없을 때)
- 마이그레이션이 비가역적이거나 외부 PG에 이미 결제가 일어난 경우
단순 원복이 불가능 → '전진 복구(fix-forward)'로 전환
- 트리거 기준: 롤백 시도 자체가 30분 내 실패하면 War Room 소집
- 비상 연락: 변경관리자, 서비스책임자, PG사 장애 핫라인
- 최악의 경우 결제만 일시 차단하고 주문은 받는 '부분 축퇴 운영' 결정
가장 자주 빠지는 부분이 **D(롤백 불가 대비)**입니다. 대부분 "되돌리면 되지"라고 가정하지만, 외부 결제망에 이미 거래가 일어났거나 마이그레이션이 비가역이면 되돌릴 수 없습니다. 이때 무작정 원복을 시도하다 더 망가뜨리는 대신, 앞으로 고쳐 나가는(fix-forward) 길과 그 트리거를 미리 정해 둬야 합니다.
확대
위 표를 한 장의 흐름으로 묶으면 이렇게 됩니다. 핵심은 갈림길의 기준(롤백 발동 조건)을 미리 종이에 적어 두는 것입니다. 새벽 작업 중 "조금만 더 해보자"는 즉흥 판단이 가장 위험하므로, 발동 조건과 롤백 한계 시각을 롤백계획서에 박아 두면 현장에서 망설이지 않고 셋 중 하나를 고를 수 있습니다.
직접 해보기 — 작업절차서와 롤백을 한 쌍으로
가상의 작은 변경 하나를 잡고, 위 템플릿을 줄여 작업절차서 단계표와 롤백계획서 A·B를 직접 채워 보세요. 거창할 필요 없이, 다음 변경이면 충분합니다.
변경: 운영 웹서버 nginx proxy_read_timeout 30s → 60s 로 상향
사유: 외부 PG 응답 지연 시 게이트웨이 타임아웃(504) 발생
점검창: 23:00 ~ 23:30 / 결정 시한 23:20
채워야 할 것:
- 작업절차서: 백업 → 설정 변경 → 문법검사 → 리로드 → 확인 (단계·명령·담당·예상시간·확인사항)
- 롤백계획서 A(조건): 어떤 증상이면 되돌릴지 2개 이상
- 롤백계획서 B(절차): 원래 설정으로 되돌리는 순서
힌트가 필요하면 nginx는 nginx -t(문법검사)와 nginx -s reload(무중단 리로드)가 있고, 설정 파일을 바꾸기 전 cp로 백업해 두면 원복이 파일 교체 한 번으로 끝납니다.
대상: nginx 설정 변경(타임아웃 30s → 60s) 운영 반영- 작업절차서에 "백업" 단계가 0~1번에 있는가 — 백업이 없으면 롤백 B의 "원래 설정으로 복귀"가 불가능하다
- 각 단계에 확인사항이 있는가 — 예: 설정 변경 후 "nginx -t 가 syntax is ok 출력" 같은 통과 기준
- 롤백 조건(A)이 측정 가능한가 — "느리면"이 아니라 "504 발생" 또는 "헬스체크 3회 실패"처럼 객관적 신호
- 롤백 절차(B)가 작업절차서의 역순으로 대응되는가 — 바꾼 것을 정확히 되돌리는 짝이 있는가
- 예상시간 합계가 점검창 안에 들어오는가 — 합계 + 여유가 30분(23:00~23:30)을 넘지 않는가
- 핵심 감각: 절차서와 롤백계획서는 항상 한 쌍 — 절차서만 있고 롤백이 없으면 "돌이킬 수 없는 작업"을 하는 것
현장에서 자주 보는 함정
증상: 변경계획서·작업절차서·롤백계획서를 다 갖춰 새벽 점검에 들어갔는데, 정작 결제가 안 되자 "원인을 조금만 더 보자"가 반복됐습니다. 02:00 점검창이 05:00을 넘겼고, 아침 출근 트래픽까지 결제가 죽어 장애로 확대됐습니다. 롤백계획서는 책상 위에 펼쳐져 있었지만 아무도 발동하지 않았습니다.
원인: 문서가 있는 것과 발동 기준이 합의된 것은 다릅니다. (1) 롤백 조건이 "정상화 안 되면"처럼 모호했고, (2) **결정 시한(point of no return)**이 없었으며, (3) "누가 롤백을 선언하는가"가 정해지지 않아 아무도 책임지고 멈추지 못했습니다. 엔지니어 본능은 "고치고 싶다"이고, 그 본능이 시한 없는 현장에서 점검창을 잡아먹습니다.
해결 방향:
- 롤백 조건을 측정 가능한 신호로: "헬스체크 3회 실패", "스모크 결제 승인 실패", "03:00까지 핵심 거래 미정상".
- 결정 시한을 변경계획서·롤백계획서·공지에 동일하게 박아 둔다(예: 03:00).
- 롤백 선언 권한자를 단 한 명 지정(총괄). 그 사람이 시계를 본다.
- 점검 공지에 "최대 04:00까지, 롤백 시 연장 가능"을 적어 두면, 현장도 고객도 시한을 공유한다.
ITSM에서 롤백은 패배가 아니라 계획된 안전장치의 정상 작동입니다. 시한 안에 깔끔하게 되돌린 팀이, 시한을 넘겨 끝까지 고친 팀보다 좋은 운영을 한 것입니다.
심화 — 리허설 없는 롤백계획서는 소설이다
심화: 제출용 문서와 실행 가능한 문서 — 롤백계획서가 형식화되는 신호
한국 SI/SM 현장에서 롤백계획서는 승인·감리의 필수 첨부물입니다. 문서가 없으면 변경이 승인되지 않으니, 문서는 반드시 존재합니다. 문제는 존재의 목적이 '실행'이 아니라 '제출'이 되는 순간입니다. 감리와 CAB는 문서가 첨부됐는지를 보지, 그 절차가 실제로 작동하는지는 보지 않습니다 — 그리고 그 틈에서 롤백계획서는 조용히 소설이 되어 갑니다.
- 복붙의 유혹: 롤백계획서는 변경마다 새로 검증해야 할 문서인데, 양식이 비슷하다 보니 지난 변경 건의 문서를 복사해 시스템 이름만 바꾸는 관행이 생깁니다. "이전 버전 재배포"라는 문구는 어떤 변경에나 그럴듯하게 들어맞기 때문에, 정작 그 변경 고유의 함정(비가역 마이그레이션·외부 연동)은 문서에 없습니다.
- 다운 스크립트는 아무도 실행해 본 적이 없습니다: 업 스크립트(적용)는 개발·스테이징·운영에서 여러 번 돌지만, 다운 스크립트(원복)는 대개 작성만 되고 한 번도 실행되지 않은 코드입니다. 실행된 적 없는 코드는 처음 실행되는 순간 — 하필 새벽 장애 상황에서 — 처음으로 검증됩니다.
- 형식화가 진행 중이라는 신호: ① 롤백 절차의 단계 수가 작업절차서의 절반도 안 된다(적용은 9단계, 원복은 '역순 수행' 한 줄) ② 롤백 예상 소요시간이 비어 있거나 근거 없는 '10분'이다 ③ 조직의 롤백 발동 이력이 수년째 0건이다 — 변경이 전부 성공해서가 아니라, 문서가 못 미더워 현장이 매번 fix-forward로 버텨 온 결과일 수 있습니다.
- 처방은 리허설의 제도화: (1) 고위험 변경은 스테이징에서 롤백 리허설을 승인 조건으로 겁니다 — 다운 스크립트를 실제로 돌려 보고, 걸린 시간을 실측해 계획서에 적습니다. (2) 롤백계획서 양식에 리허설 일시·수행자·결과 칸을 신설합니다 — 빈칸이면 CAB에서 반려되므로 복붙이 원천 차단됩니다. (3) 롤백 발동 건수·성공률을 분기 지표로 봅니다 — 0건이 계속되면 칭찬할 일이 아니라 조사할 일입니다.
작업절차서는 성공 경로라서 자주 검증되지만, 롤백계획서는 실패 경로라서 검증을 피해 갑니다. 보험 증서는 사고 전에 약관을 읽어야 합니다 — 새벽 3시에 처음 펼쳐 보는 롤백계획서는 이미 늦은 것입니다.
상황: 정산 시스템 개편 배포의 새벽 점검창. 스모크 테스트가 실패하자 총괄은 미리 정한 결정 시한 03:00에 맞춰 망설임 없이 롤백을 선언했습니다 — 여기까지는 모범적이었습니다. 그런데 롤백 절차 4단계, 마이그레이션 다운 스크립트가 에러를 내며 중단됩니다. 5단계의 원복용 이미지 경로도 실제 레지스트리에 없는 태그였습니다. 결국 DBA가 수동 SQL로 스키마를 되돌리며 아침 7시까지 복구 작업이 이어졌고, "롤백만 하면 20분"이라던 계획은 4시간이 됐습니다.
원인: 조사해 보니 이 롤백계획서는 지난 분기 다른 시스템 배포 건의 문서를 복사해 제목과 시스템명만 바꾼 것이었습니다. 이미지 태그 경로는 이전 시스템 것이 그대로 남아 있었고, 다운 스크립트는 이번 변경용으로 새로 작성되긴 했지만 개발 이후 어떤 환경에서도 실행된 적이 없었습니다 — 적용 후 이미 신규 컬럼에 데이터가 쌓인 상태를 고려하지 않아 제약 조건 위반으로 실패한 것입니다. 문서는 CAB와 발주사 감리를 모두 통과했습니다. 둘 다 첨부 여부만 확인했지, 실행 가능성은 누구의 점검 항목도 아니었기 때문입니다.
진단: 사후 검토에서 최근 1년치 롤백계획서를 전수 대조하자 패턴이 드러났습니다. 문서 대부분의 B 절차 문구가 서로 동일했고(복사 계보가 그려질 정도), 롤백 소요시간은 전부 '10분' 아니면 공란이었으며, 스테이징 배포 이력에 다운 스크립트 실행 기록은 단 한 건도 없었습니다. 같은 기간 롤백 발동은 0건 — 현장은 문서를 믿지 않아 매번 밤을 새워 fix-forward로 버텨 왔다는 뜻이었습니다.
해결: (1) 고위험 변경은 스테이징에서 적용→롤백→재적용을 한 사이클 돌려 보는 롤백 리허설을 승인 조건으로 만들고, 실측 소요시간과 실행 로그를 계획서에 첨부하게 했습니다. (2) 롤백계획서 양식에 '리허설 일시·수행자·결과' 칸을 신설해, 빈칸이면 CAB가 기계적으로 반려합니다. (3) 발주사 감리 체크리스트에도 '롤백 검증 증적 확인' 항목을 넣도록 협의했습니다 — 감리가 실행 가능성을 묻기 시작하자 복붙 문서가 사라졌습니다. 반년 뒤 실제 롤백이 두 건 발동됐고, 각각 18분·25분에 끝났습니다. 롤백이 실측된 조직만이 롤백을 두려워하지 않고 선언할 수 있습니다 — 그리고 그것이 결정 시한을 지키는 진짜 전제 조건입니다.
한국 SI/SM 현장에서 운영계 반영은 거의 야간·주말 점검창에서 일어납니다. 낮에 결제를 멈출 수 없으니, 트래픽이 적은 새벽에 모여 반영합니다. 이때 관리자(운영 담당·PM)는 직접 명령을 치기보다 문서로 통제합니다 — 변경계획서로 발주사·내부 승인을 받고, 협력사(하도급) 엔지니어가 작업절차서를 그대로 따르게 하며, 롤백계획서로 실패의 출구를 미리 확보합니다.
문서는 안에서만 도는 게 아닙니다. 반영 전날에는 고객 점검 공지(또는 발주사·이용기관 통보)를 정해진 채널로 보냅니다 — "○월 ○일 02:00~04:00 결제 서비스 점검, 해당 시간 결제 일시 중단, 문의 ☎ ...". 야간 작업이 끝나면 아침에 결과보고를 올립니다 — 예정대로 반영했는지, 이상은 없었는지, 롤백을 했다면 왜 했고 다음 계획은 무엇인지. 발주사는 이 세 가지(사전 승인 문서·사전 공지·사후 결과보고)로 "통제된 운영"인지를 판단하고, 그게 곧 SLA·재계약의 신뢰가 됩니다.
그래서 이 자리에서 당신의 실력은 "배포를 빨리 하는 것"이 아니라 **"반영 전에 무엇을 종이에 적어 승인받고, 무엇을 고객에게 알리고, 실패를 어떻게 미리 설계해 두는가"**로 드러납니다. 협력사가 실제 손을 움직여도, 이 세 문서와 공지·보고에 대한 책임은 관리자에게 있습니다.
관련 모듈로 더 깊이:
- 변경 관리(변경 활성화) — 변경계획서가 통과하는 변경관리·승인 프로세스 전체
- 작업계획서·롤백계획서·점검계획 — 롤백계획서를 실제 점검창에서 실행하는 체크리스트
- 릴리스와 배포 관리 — 작업절차서가 적용되는 릴리즈·배포 흐름
다음 모듈에서는 이렇게 반영한 작업의 결과를 한 장으로 정리해 위로 올리는 보고 문서 — 주간 운영 보고서와 경영 보고를 다룹니다.