월간 보고 개선안을 검토하는 담당자를 가정해 볼게요. 작업시간을 조사하고 대안도 찾았지만 보고서에 숫자만 나열돼 있으면, 읽는 사람은 무엇을 승인해야 하는지 알기 어려워요. 이번에는 ‘어떤 도구가 가장 좋은가’ 대신 2주 안에 시험에 쓸 24시간을 배정할지를 결정하는 메모를 만들어요.
첨부 링크는 이 글의 예제 ZIP으로 연결돼요. 압축을 푼 뒤 링크에 표시된 파일을 열면 입력·코드·완성 자료를 함께 사용할 수 있어요.
예제의 시간은 모두 가상 계획 가정이에요. 실제 기업에서 측정한 절약 효과가 아니에요. Codex가 입력과 초안을 작성하고 2026년 10월 13일 Python 3.12.3으로 합계와 민감도를 계산했어요. 수정 전 메모 (ZIP: before-memo.txt), 가정 파일 (ZIP: assumptions.json), 완성 메모 (ZIP: decision-memo.md)를 함께 제공해요. 별도 사람의 사용성 검증은 아직 하지 않았어요.
질문을 좁히니 남길 숫자가 달라졌어요
수정 전 메모에는 ‘월 보고 40시간’, ‘전용 도구를 쓰면 월 12시간 가정’, ‘접수가 월초에 집중됨’, ‘문서 종류 8개’가 이어졌어요. 각각 사실이거나 가정일 수 있지만 이 문장들만으로는 요청할 행동이 정해지지 않아요.
이번 결정에는 세 가지 제약을 먼저 붙였어요. 준비할 수 있는 시간은 앞으로 2주 동안 32시간, 비교 기간은 2개월, 필수 숫자와 출처의 정확성은 유지해야 해요. 이 조건이면 월 반복시간만 비교해서는 안 되고 초기 준비시간을 더해야 해요. 접수 시간대나 문서 종류는 세부 실행 계획에는 필요하지만 이 승인에서 대안의 순위를 바꾸는 근거가 아니므로 본문에서 뺐어요.
NASA의 의사결정 분석 안내는 결정할 질문, 기준, 대안, 가정과 한계, 권고를 남기는 과정을 설명해요. 우리는 이를 작은 업무 결정에 맞춰 줄였어요. 모든 대안에 점수를 매기는 복잡한 표를 만드는 것보다, 지금 충족해야 할 조건을 먼저 확인하는 편이 이 예제에는 맞아요.
반복시간과 준비시간을 합쳐요
| 대안 | 준비시간 | 월 반복시간 | 2개월 전체 | 6개월 전체 |
|---|---|---|---|---|
| A. 현행 수작업 | 0시간 | 40시간 | 80시간 | 240시간 |
| B. 입력 규칙·보고 템플릿 | 24시간 | 20시간 | 64시간 | 144시간 |
| C. 전용 도구 도입 | 60시간 | 12시간 | 84시간 | 132시간 |
2개월 전체 시간은 준비시간+2×월 반복시간으로 계산했어요. B는 24+2×20=64시간이라 A보다 16시간 적다는 가정상 결과가 나와요. C는 월 작업이 가장 적지만 준비 60시간이 가용 32시간을 넘어요. 필요한 검토도 끝나지 않았다고 가정했으므로 지금 선택 가능한 대안으로 다루지 않아요.
6개월 결과도 숨기지 않았어요. 이 기간에는 C 132시간이 B 144시간보다 적어요. 그렇다고 이번 결정이 틀린 것은 아니에요. 짧은 준비기간에 실행할 수 있는지와 장기 누적시간은 다른 질문이에요. 장기 개선 검토를 다시 할 때 C를 후보로 올릴 수 있다는 반대 근거로 남겨요.
권고를 뒤집을 수 있는 가정을 바로 옆에 적어요
B의 월 반복시간 20시간이 낙관적이라면 어떻게 될까요? 월 24시간이면 2개월 전체가 72시간, 28시간이면 80시간, 32시간이면 88시간이에요. 월 28시간에서 A와 같아지므로, B의 시간이 그보다 적어야 이번 2개월 기준에서 시간상 이점이 생겨요.
이 때문에 최종 권고를 ‘B를 전면 도입하자’에서 ‘최대 24시간을 들여 B를 시험하자’로 낮췄어요. 예상 월 작업시간이 검토·수정까지 포함하는지 아직 측정하지 않았기 때문이에요. 첫 시험에서는 작성 속도만 비교하지 말고 제출 가능한 보고가 될 때까지의 시간을 기록해야 해요.
불확실성을 각주에 숨기지 않고 핵심 수치 가까이에 놓는 방식은 영국 Government Analysis Function의 품질·불확실성 안내와도 연결돼요. 이 예제에서 특히 중요한 불확실성은 소수점 자릿수가 아니라 ‘월 20시간이라는 가정이 실제로 성립하는가’예요.
완성 메모는 바로 결정할 수 있는 문장으로 써요
요청: 향후 2주 동안 입력 규칙·보고 템플릿 시험에 최대 24시간을 배정해 주세요. 전체 전환은 시험 결과 뒤에 판단해요.
근거: 가정상 2개월 전체 작업은 현행 80시간, 템플릿 64시간이에요. 전용 도구는 84시간이며 준비시간 60시간이 현재 가용 32시간을 넘어요.
조건과 반대 근거: 템플릿의 월 작업이 28시간이면 현행과 같아져요. 장기 6개월 가정에서는 전용 도구가 더 적은 시간이므로 추후 검토 후보로 남겨요. 숫자·출처·필수 항목의 정확성은 줄이지 않아요.
다음 행동: 가상 담당자인 운영분석팀이 2주 안에 동등 난도의 시험 보고를 만들고 작성·검토·수정 시간을 남겨요. 준비·시험 작업이 24시간 한도를 넘거나 숫자 대조에 실패하면 확대하지 않고 현행을 유지해요.
‘운영분석팀’은 설명을 위해 정한 가상 담당자예요. 실제 승인이나 일정 배정을 실행한 것은 아니에요. 메모 파일 (ZIP: decision-memo.md)에는 가정의 ID와 계산 파일을 연결해, 검토자가 숫자를 다시 찾을 수 있게 했어요.
assets 폴더에서 python3 calculate.py를 실행하면 위 합계와 민감도 표가 계산 결과 (ZIP: calculation.json)로 저장돼요. 자기 업무에 적용할 때는 대안 이름부터 바꾸기보다 결정 기간·필수 조건·가용 자원을 먼저 바꾸세요. 예를 들어 장기 반복업무라면 평가 기간이 달라지고 초기 준비에 투자할 이유도 달라질 수 있어요.
근거가 모자랄 때 메모의 결론은 ‘추가 조사’여도 괜찮아요. 다만 어느 정보를 알면 선택이 달라지는지, 얼마의 시간으로 확인할지까지 적어야 해요. 여기서는 월 반복시간 28시간이라는 경계가 그 역할을 해요. 한 장에 남길 숫자는 많은 숫자가 아니라 선택과 다음 행동을 바꿀 수 있는 숫자예요.
선택한 대안의 실행 범위를 잡을 때는 가용시간과 완료 기준을 맞추는 계획로 이어서 확인할 수 있어요.
예제 파일을 한 번에 받아 다시 확인해요
이 글의 입력·코드·완성 자료 ZIP을 새 폴더에 풀면 R19/README.txt, replay.py, assets 폴더가 함께 생겨요. 개별 코드 파일만 저장하면 보조 모듈이나 입력이 빠질 수 있으므로 처음에는 이 묶음을 사용하세요. R19 폴더에서 다음 명령을 실행하면 본문에 사용한 검사를 순서대로 수행해요.
python3 replay.py
확인할 결과는 2개월80/64/84시간, 6개월240/144/132시간, B 월28시간 경계예요. 명령이 성공해도 이 값과 본문의 적용 범위를 함께 대조하세요. 실행 안내 (ZIP: README.txt)에 필요한 파일과 개별 명령을 적었어요. 실행 코드는 calculate.py (ZIP: calculate.py)에서 직접 볼 수 있어요. Python3.12의 표준 라이브러리를 사용하며, 명령이 실패하면 ZIP의 폴더 구조와 오류에 나온 파일부터 확인해요. 실제 앱 실행에 필요한 프로그램은 원래 설명을 따르세요.
설명 삽화 2장은 GPT로 생성한 개념 설명이에요. 실제 예제의 작업 화면과 실행 결과는 기존 그림·첨부 자료에서 따로 확인할 수 있어요.