막연한 ‘해야 할 일’을 ‘운영 가능한 문서’로 바꾸기
업무가 막히는 순간을 떠올려 보면, 대부분은 능력 부족이 아니라 “무엇을, 어떤 순서로, 누구가, 어느 수준까지” 해야 하는지 합의되지 않았을 때 발생합니다. 이 챕터의 목표는 그 합의를 문서로 고정하는 것입니다. 문서가 만들어지면 일정·역할·리스크·회의가 한 덩어리로 정렬되고, 그때부터 실행은 ‘의지’가 아니라 ‘절차’가 됩니다.
ChatGPT는 이 전환점에서 강력합니다. 사람들은 기획 문서를 쓰는 데 시간을 뺏기고, 막상 문서가 있어도 업데이트를 못 해 문서가 죽습니다. ChatGPT는 초안을 빠르게 만들고, 회의에서 나온 수정 사항을 즉시 반영하고, 누락을 점검하고, 형식을 표준화하는 데 적합합니다.
다만 기억해야 할 전제도 있습니다. 운영 문서는 “그럴듯한 문장”이 아니라 “실제로 따라 할 수 있는 지시”여야 합니다. 그래서 이 장에서는 입력(당신이 줘야 하는 정보)과 출력(문서의 필수 요소)을 명확히 고정하는 방식으로 진행합니다.
1) WBS: 일을 ‘관리 가능한 크기’로 쪼개는 기술
WBS(Work Breakdown Structure)는 프로젝트의 일을 계층 구조로 쪼개어, 일정·비용·범위를 관리 가능하게 만드는 도구입니다. 핵심은 ‘할 일 목록’이 아니라 전체 범위를 빠짐없이 포함하는 구조를 만드는 데 있습니다.
WBS를 만들기 전에 정리해야 할 6가지 입력
아래 여섯 가지가 비어 있으면 ChatGPT가 WBS를 그럴듯하게 채우면서도 실제와 어긋날 가능성이 큽니다.
목표(성공 기준): 무엇이 완료되면 “끝”인가
산출물(Deliverables): 결과물의 목록
범위: 포함/제외(특히 제외)
제약: 일정, 예산, 인력, 기술, 승인 절차
이해관계자: 누가 승인하고, 누가 사용하고, 누가 운영하는가
작업 방식: 애자일/워터폴/혼합, 주간 회의 리듬, 배포·검수 방식
ChatGPT로 WBS 초안 생성하기: 기본 프롬프트
아래 프롬프트는 “문서 생성”이 아니라 “계획 구조 설계”에 초점을 둔 템플릿입니다.
프롬프트 템플릿: WBS 생성
역할: 당신은 프로젝트 매니저(PM) 겸 운영 설계자다.
목표: 아래 프로젝트 정보를 바탕으로 WBS를 작성하라.
제약:
1~3레벨까지 작성하고, 3레벨은 ‘작업 패키지(Work Package)’ 수준으로 쪼갠다.
각 작업 패키지는 “완료 조건(검수 기준)”이 한 문장으로 명확해야 한다.
누락 가능성이 높은 항목(승인/커뮤니케이션/품질/운영인수/문서화)을 별도 영역으로 점검하라.
출력 형식:
① WBS 트리(번호 포함)
② WBS 표(열: WBS 코드, 작업명, 산출물, 담당 역할, 선행조건, 추정(시간/일), 완료 기준)
③ 누락 점검 질문 10개
프로젝트 정보
프로젝트명:
목표/성공 기준:
주요 산출물:
범위(포함/제외):
마감일/중요 마일스톤:
팀 구성(역할):
승인자/의사결정자:
운영 인수(누가 운영하는가):
다음은 가상 AI 커뮤니케이션 기기를 만드는 틸노트 전자를 예로 든 결과입니다.
WBS를 ‘실행 계획’으로 바꾸는 3가지 후속 작업
WBS가 생겼다고 실행이 되는 것은 아닙니다. 아래 3가지를 붙이면 WBS가 즉시 운영 문서가 됩니다.
첫째, 의존성(선행조건)을 박습니다. “A가 끝나야 B가 시작” 같은 관계가 들어가면 일정 논의가 쉬워집니다.
둘째, 완료 기준(검수 기준)을 문장으로 고정합니다. 완료 기준이 없으면 진행률이 감정이 됩니다. “테스트 통과”, “승인자 OK”, “문서 링크 포함” 같이 검증 가능한 표현으로 끝내야 합니다.
셋째, 작업 패키지의 크기를 통일합니다. 너무 큰 작업은 추정이 흔들리고, 너무 작은 작업은 관리 비용이 늘어납니다. 경험적으로는 ‘반나절~며칠’ 단위로 관리 가능한 크기가 좋습니다.
ChatGPT로 WBS 품질 점검하기(누락/중복/범위)
WBS가 어느 정도 나온 뒤에는 “이게 맞나요?” 대신 아래처럼 검토를 맡기는 편이 효율적입니다.
프롬프트 템플릿: WBS 리뷰(누락/중복/범위크립)
역할: 당신은 경험 많은 PMO 리뷰어다.
입력: 아래 WBS 초안과 프로젝트 정보를 읽고,
누락된 작업(특히 운영 인수/승인/법무·보안/품질/데이터·권한/커뮤니케이션)을 제안하고,
범위가 의도치 않게 커진 항목을 표시하고,
너무 큰 작업 패키지는 더 쪼개라.
출력:
(A) 수정 제안 리스트
(B) 위험한 가정 5개
(C) 이해관계자에게 확인해야 할 질문 8개
2) SOP: 반복 업무를 ‘사람’이 아니라 ‘시스템’이 하게 만들기
SOP(Standard Operating Procedure)는 반복 업무를 표준화한 문서입니다. SOP가 없으면 업무는 늘 숙련자에게 몰리고, 인수인계가 실패하고, 품질 편차가 커집니다. SOP의 목표는 화려한 문서가 아니라 다른 사람이 그대로 따라 해서 같은 결과가 나오게 하는 것입니다.
SOP가 특히 효과적인 업무
반복성이 높고 실수 비용이 큰 업무일수록 SOP의 투자 대비 효과가 큽니다.
고객 응대/민원 처리/환불
발행·정산·세금계산서·증빙
배포/릴리즈/권한 부여/계정 생성
신규 입사자 온보딩/장비 지급/접근 권한
콘텐츠 발행(기획–작성–검수–게시–모니터링)
SOP 형식은 4가지 중 고르면 된다
SOP는 복잡도를 낮추기 위해 형식을 먼저 선택하는 게 좋습니다.
체크리스트형: 빠르게 따라야 하는 반복 작업
단계형(순서형): 앞 단계가 끝나야 다음 단계로 가는 업무
계층형: 큰 단계 아래에 세부 단계가 달리는 복합 업무
흐름도형: 분기(예/아니오)가 많고 예외 처리가 중요한 업무
ChatGPT로 SOP 초안 만들기: 입력이 ‘현장 언어’여야 한다
SOP는 추상적이면 바로 무용지물이 됩니다. 그래서 ChatGPT에 줄 입력도 “원칙”이 아니라 “현장 표현”으로 적습니다.
누가(역할): CS 매니저, 회계 담당, 인프라 엔지니어
어떤 도구: 사용 시스템/URL/권한
언제 시작/끝: 트리거(요청 접수 시)와 종료 조건(처리 완료 통보 시)
예외/자주 깨지는 지점: 언제 문제가 나나
품질 기준: 무엇이 ‘정상 처리’인가
프롬프트 템플릿: SOP 생성(운영용 표준)
역할: 당신은 운영 프로세스 설계자다.
목표: 아래 업무를 표준절차(SOP)로 작성하라.
제약:
초보자가 읽어도 실행 가능해야 한다.
각 단계는 한 가지 행동으로 쪼개고, 동사로 시작한다.
예외 케이스(자주 발생하는 3가지)와 에스컬레이션 기준을 반드시 포함한다.
품질 점검(체크 포인트)과 기록(로그/티켓/문서 링크)을 포함한다.
문서 마지막에 ‘개정 이력’ 섹션을 둔다.
출력 형식(H2 포함):
개요(목적/범위)
역할과 책임(R&R)
준비물/권한/사전조건
절차(단계별)
예외 처리
에스컬레이션 기준
품질 체크 및 산출물
참고 링크
개정 이력
업무 정보
SOP 이름:
업무 목적:
적용 범위(포함/제외):
트리거(시작 조건):
종료 조건:
사용 도구/시스템:
담당 역할/승인자:
예외/실수 많이 나는 지점:
SOP를 ‘살아있는 문서’로 유지하는 운영 루틴
SOP는 작성보다 유지가 어렵습니다. 유지가 되는 팀은 SOP를 문서가 아니라 업무의 일부로 다룹니다.
첫째, SOP에 소유자(Owner)를 둡니다. 사람 이름이 아니라 역할로 지정하는 편이 교체에 강합니다.
둘째, SOP 마지막에 다음 리뷰 날짜를 적어 둡니다. 예를 들어 “다음 리뷰: 2026-06-30”처럼 달아두면 업데이트가 행사로 바뀝니다.
셋째, 변경 사항이 생길 때마다 “왜 바꿨는지”를 남깁니다. 개정 이력은 형식이 아니라 운영의 기억입니다.
3) 리스크 템플릿: 사고가 나기 전에 ‘불안’을 문서로 옮기기
프로젝트 리스크는 대체로 두 종류입니다. 이미 알고 있지만 말로만 떠도는 리스크, 그리고 아무도 생각하지 못했던 리스크입니다. 전자는 템플릿으로 잡아낼 수 있고, 후자는 질문으로 끌어낼 수 있습니다.
가장 실용적인 리스크 문서: Risk Register(리스크 등록부)
리스크 등록부는 “걱정 리스트”가 아니라 대응이 붙은 목록이어야 합니다. 아래 필드만으로도 운영이 됩니다.
ID
리스크 설명
트리거(발생 신호)
발생 가능성(낮/중/높)
영향도(낮/중/높)
점수/우선순위
오너
예방(완화) 전략
발생 시 대응(컨틴전시)
상태/다음 리뷰일
프롬프트 템플릿: 리스크 등록부 생성
역할: 당신은 리스크 매니저다.
목표: 아래 프로젝트 정보를 바탕으로 리스크 등록부를 만들어라.
제약:
최소 12개 리스크를 제안하되, 범주를 다양하게 포함하라(일정/범위/품질/인력/의존성/승인/법무·보안/데이터/운영인수/벤더).
각 리스크마다 트리거와 ‘예방’과 ‘발생 시 대응’을 분리해 작성하라.
출력: 표 형태
프로젝트 정보
목표/마감/산출물:
주요 이해관계자:
외부 의존성(벤더/타팀/승인):
기술/운영 제약:
“우리는 뭘 놓치고 있지?”를 뽑는 질문 프롬프트
리스크는 아이디어가 아니라 질문에서 나옵니다. 회의 전에 아래 질문 세트를 뽑아두면 리스크 토론의 질이 달라집니다.
프롬프트 템플릿: 리스크 발굴 질문 15개
역할: 당신은 냉정한 프로젝트 감사자다.
목표: 아래 계획을 읽고, 우리가 놓치기 쉬운 리스크를 드러내는 질문 15개를 작성하라.
제약: 질문은 “예/아니오”로 답하기 어렵게, 구체적 확인을 요구하는 형태로 쓰라.
4) 회의 준비: ‘회의를 위한 회의’를 없애는 질문과 안건
회의의 품질은 진행자의 말솜씨보다 안건의 형태로 결정됩니다. 안건이 ‘주제’로 쓰이면 토론은 흘러가고, 안건이 ‘질문/결정’으로 쓰이면 회의는 끝이 납니다.
회의 안건의 기본 구조(운영 문서 버전)
회의 안건은 최소한 아래 항목을 포함하면 됩니다.
회의 목적(한 문장)
오늘 결정해야 할 것(Decision)
공유해야 할 것(Info)
논의가 필요한 것(Discussion)
준비물/사전 읽을거리(링크)
시간 배분
퍼실리테이터/기록자
결과물: 결정 사항 + 액션 아이템(담당/기한)
프롬프트 템플릿: 회의 안건 생성(시간표 포함)
역할: 당신은 회의 퍼실리테이터다.
목표: 아래 회의 목적을 달성하도록 60분짜리 안건을 작성하라.
제약:
모든 안건은 ‘질문’ 또는 ‘결정 문장(…을 승인한다/선택한다)’ 형태로 써라.
각 항목에 시간(분)과 진행 담당을 배정하라.
마지막 10분은 반드시 액션 아이템 정리/리캡으로 확보하라.
출력: 표(시간, 안건, 목적, 담당, 준비물, 기대 산출물)
회의 정보
회의 종류(킥오프/주간/의사결정/회고 등):
목적:
참석자와 역할:
사전 자료 링크:
오늘 반드시 필요한 결정:
회의 질문 리스트: 상황별로 뽑아 쓰기
회의를 준비할 때마다 질문을 새로 만들면, 가장 중요한 질문이 매번 빠집니다. 그래서 “회의 유형별 질문 라이브러리”를 만들어 두는 편이 좋습니다.
아래는 ChatGPT로 바로 생성해 쓸 수 있는 질문 리스트 템플릿입니다.
프롬프트 템플릿: 킥오프 질문 20개
역할: 당신은 프로젝트 킥오프 진행자다.
목표: 아래 프로젝트를 시작하기 위한 킥오프 질문 20개를 작성하라.
제약: 질문을 범주별로 묶어라(목표/범위/역할/일정/의존성/리스크/커뮤니케이션/운영인수).
프롬프트 템플릿: 주간 운영 회의 질문 12개(15분 스탠드업)
역할: 당신은 운영 리듬을 만드는 팀 리드다.
목표: 15분 안에 상황을 파악하고 장애물을 제거하기 위한 질문 12개를 작성하라.
제약: 질문은 ‘진행률 보고’보다 ‘막힘 제거’에 초점을 맞춰라.
프롬프트 템플릿: 의사결정 회의 질문 10개(결정 품질)
역할: 당신은 의사결정 품질을 높이는 퍼실리테이터다.
목표: 아래 의사결정 안건에 대해, 결정을 망치는 함정(가정/편향/누락 데이터)을 찾는 질문 10개를 작성하라.
5) 의사결정 보조: “옵션을 비교 가능한 형태로” 만들기
결정이 어려운 이유는 옵션이 없어서가 아니라, 옵션이 같은 기준으로 비교되지 않아서입니다. ChatGPT는 이 비교 틀을 만드는 데 특히 유용합니다.
1페이지 의사결정 메모(Decision Memo)
회의에서 말로만 결정하면, 다음 주에 “왜 그렇게 했지?”가 시작됩니다. 그래서 결정은 한 페이지에 고정합니다.
프롬프트 템플릿: 1페이지 의사결정 메모 작성
역할: 당신은 전략/운영 PM이다.
목표: 아래 상황을 바탕으로 1페이지 의사결정 메모를 작성하라.
포함 섹션:
배경(문제 정의)
목표(성공 기준)
옵션 3개(각각 장단점, 비용/일정/리스크)
추천안과 이유
전제/가정
즉시 필요한 결정(누가, 언제까지)
후속 액션 아이템
제약: 모르는 정보는 ‘확인이 필요한 항목’으로 분리하고, 임의로 확정하지 마라.
옵션 비교표를 자동 생성하기(평가 기준 고정)
옵션 비교는 기준이 흔들리면 결과도 흔들립니다. 기준을 먼저 고정하고, 그 기준으로 옵션을 평가하게 하세요.
프롬프트 템플릿: 옵션 비교표(가중치 포함)
역할: 당신은 의사결정 분석가다.
목표: 아래 옵션들을 평가 기준 6개로 비교하고, 기준별 가중치를 제안한 뒤, 점수표를 작성하라.
제약:
기준은 팀이 동의하기 쉬운 운영 기준이어야 한다(예: 리드타임, 운영 복잡도, 장애 영향, 보안/컴플라이언스, 비용, 확장성).
점수는 ‘근거 문장’과 함께 제시하라.
출력:
(1) 평가 기준 및 가중치
(2) 옵션별 점수표
(3) 민감도: 가중치가 바뀌면 결론이 바뀌는 항목
6) 운영 문서 패키지: WBS–SOP–리스크–회의를 한 세트로 묶기
각 문서는 따로 존재하면 금방 죽습니다. 강한 운영은 문서를 “패키지”로 묶어서 서로 참조하게 만듭니다.
예를 들어, 프로젝트를 시작할 때 최소 패키지는 이 정도면 충분합니다.
WBS(작업 구조) + 담당/완료 기준
마일스톤 일정(대략이라도)
리스크 등록부(오너와 리뷰 리듬 포함)
커뮤니케이션 규칙(주간 회의/보고 방식)
운영 인수 체크리스트(릴리즈 후 누가, 무엇을, 어떻게 운영)
프롬프트 템플릿: ‘운영 문서 패키지’ 자동 생성
역할: 당신은 PMO다.
목표: 아래 프로젝트 정보를 바탕으로 운영 문서 패키지를 한 번에 생성하라.
출력:
1페이지 프로젝트 개요
WBS(3레벨)
리스크 등록부(최소 12개)
회의 체계(회의 종류, 주기, 목적, 산출물)
SOP 목록(필수 5개)과 각 SOP의 목적/오너
제약: 각 문서 사이 연결을 명시하라(예: WBS의 어떤 작업이 어떤 SOP로 운영되는지).
7) 실전 예시: “제품 랜딩페이지 출시”를 운영 문서로 바꾸는 대화 흐름
여기서는 ‘마케팅 랜딩페이지 출시’처럼 흔한 업무를 예로 들어, ChatGPT와의 대화가 어떻게 실행 가능한 계획으로 수렴하는지 보여줍니다.
먼저 당신이 주는 입력은 길 필요가 없습니다. 대신 핵심만 정확히 줍니다.
목표: 2026-04-15까지 랜딩페이지 공개, 전환율 3% 목표
산출물: 페이지 1종, FAQ, 문의 폼, GA4 이벤트, A/B 테스트 계획
제약: 디자인 리소스 주 1회만 가능, 법무 검토 필요
운영: 게시 후 2주간 지표 모니터링 및 개선
이 입력을 주고 WBS를 뽑으면, 다음 단계는 SOP로 연결됩니다. 예를 들어 “게시 절차”, “법무 검토 요청 절차”, “지표 모니터링 절차” 같은 SOP를 붙여야 운영이 됩니다. 마지막으로 회의 안건은 “진척 공유”가 아니라 “결정” 중심으로 바뀝니다. “A/B 테스트 가설 승인”, “카피 최종안 승인”, “출시 체크리스트 Go/No-Go” 같은 형태로 말이죠.
이 흐름이 자리 잡으면, ‘열심히 했다’가 아니라 ‘문서가 남았다’가 됩니다.
마무리: 실행력을 만드는 것은 ‘의욕’이 아니라 ‘형식’이다
기획이란 거창한 창의 작업처럼 보이지만, 실제로는 반복되는 질문을 반복되는 문서로 고정하는 일입니다. WBS는 일을 작게 만들고, SOP는 반복을 안전하게 만들고, 리스크 문서는 불안을 관리 가능하게 만들고, 회의 안건은 대화를 결정으로 바꿉니다.
ChatGPT는 이 네 가지 문서를 빠르게 만들고, 더 자주 업데이트하게 만들어 “계획이 실행을 따라가는” 상태를 가능하게 합니다. 이제부터는 막연한 할 일 목록을 붙들기보다, 이 장의 템플릿을 그대로 복사해 운영 문서 패키지를 먼저 만들어 보세요. 그 순간부터 프로젝트는 ‘해야 하는 일’이 아니라 ‘할 수 있는 일’이 됩니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.