금요일 오후, 운영 PM에게 한 줄이 떨어집니다. "다음 점검 때 운영계 웹 구간 SSL 인증서 교체하고 OS 보안 패치도 같이 반영하세요. 일정이랑 고객 안내안 만들어 오세요."
신입 PM A는 빈 엑셀을 열고 막막해합니다. 어디서부터 쪼개야 할지, 어떤 순서인지, 무엇을 빠뜨릴지 감이 안 옵니다. 두 시간 동안 화면만 봅니다.
선임 PM B는 AI에게 맥락을 정리해 던집니다. "대상은 운영계 웹 2대·WAS 앞단, 무중단 어려워 점검창 필요, 변경은 CAB 승인 대상, 외부 고객 영향 있음." 30초 뒤 AI가 작업 분해·선후행·담당 조직 추정·일정 리스크 초안을 표로 뱉습니다.
하지만 B는 그걸 그대로 제출하지 않습니다. "인증서 폐기 단계가 빠졌네", "패치 후 재부팅이면 이 작업은 무중단 아니야", "보안팀 가용성은 내가 확인", "이 기간은 너무 낙관적"이라고 손으로 고칩니다. AI는 빈 화면을 채워줬고, B는 그 초안을 우리 현실로 끌어내렸습니다. 이 모듈은 그 협업 패턴 — AI로 펼치고 사람이 확정하기 — 를 다룹니다.
- 1요구·작업 설명을 AI에 줄 때 어떤 맥락(범위·제약·환경)을 함께 줘야 쓸 만한 WBS 초안이 나오는지 설명할 수 있다
- 2AI 초안에서 작업 분해·담당 조직 추정·선후행·마일스톤·일정 리스크가 각각 무엇을 뜻하는지 읽어낼 수 있다
- 3AI 초안을 100% 규칙(누락·중복)·현실적 기간·의존성 기준으로 사람이 검토해 확정하는 절차를 수행할 수 있다
- 4AI 초안의 한계(조직의 실제 R&R·가용성·내부 절차를 모름)를 알고, 무엇을 사람이 반드시 판단해야 하는지 구분할 수 있다
- 5운영계 SSL 인증서 교체·패치 같은 실제 변경 작업의 WBS·리스크·고객 안내 초안을 AI와 함께 만들고 검증할 수 있다
AI는 'WBS를 대신 짜는 도구'가 아니라 '초안을 펼치는 도구'다
왜 AI로 WBS를 펼치는가
WBS(작업분해구조)를 처음 짜는 일의 진짜 어려움은 표를 그리는 게 아니라 빈 화면을 마주하는 것입니다. "무엇무엇을 해야 하지?"에서 첫 항목이 안 떠오르면 30분이 그냥 갑니다. AI의 가장 큰 효용은 바로 이 출발 마찰을 없애주는 것입니다 — 요구 한 줄을 받아 그럴듯한 작업 목록·순서·표를 30초 만에 펼쳐 놓습니다.
하지만 여기서 역할을 분명히 해야 합니다. AI가 만드는 것은 완성된 계획이 아니라 검토를 시작할 초안입니다. AI는 텍스트 패턴으로 "SSL 교체라면 보통 이런 작업들"을 끌어오지만, 우리 조직의 점검창 정책·CAB 승인 리드타임·협력사 계약 범위·담당자 부하는 알지 못합니다.
| 단계 | AI가 잘하는 것 | 사람이 해야 하는 것 |
|---|---|---|
| 펼치기 | 요구 → 작업 목록·순서·표를 빠르게 생성 | 충분한 맥락(범위·제약·환경) 제공 |
| 분류 | 일반적 담당 조직·선후행 추정 | 실제 R&R·가용성으로 검증·조정 |
| 점검 | 형식적 빠짐없음(표 채우기) | 100% 규칙·우리만의 절차 누락 확인 |
| 확정 | 못 함 | 현실적 기간·리스크 수용 여부 결정 |
핵심 한 줄: AI는 초안의 속도를, 사람은 초안의 책임을 맡는다. 제출되는 계획의 정확성에 대한 책임은 끝까지 사람에게 있습니다.
AI에게 무엇을 주면 쓸 만한 초안이 나오는가
맥락 4종 — 범위·제약·환경·산출형식
같은 "SSL 인증서 교체"라도 어떤 맥락을 함께 주느냐에 따라 초안의 품질이 갈립니다. AI는 준 것 안에서만 추론하므로, 다음 네 가지를 명시할수록 우리 현실에 가까운 초안이 나옵니다.
| 맥락 종류 | 안 주면 생기는 일 | 줘야 할 정보 예 |
|---|---|---|
| 범위(Scope) | 대상이 모호해 일반론 나열 | "운영계 웹 2대·WAS 앞단, DB·내부망 제외" |
| 제약(Constraint) | 무중단 가정 등 비현실적 순서 | "무중단 불가, 점검창 02~04시, CAB 승인 필요" |
| 환경(Environment) | 우리 절차 통째로 누락 | "변경관리·고객 사전공지 의무, 협력사 작업 분담" |
| 산출 형식(Format) | 줄글로 나와 검토가 어려움 | "작업·담당·선후행·기간·리스크 열을 가진 표로" |
맥락을 줄 때의 요령은 '우리만 아는 것'을 우선 적는 것입니다. SSL 교체의 일반 절차는 AI가 이미 알고 있으니, 점검창 시간·승인 절차·고객 안내 의무처럼 우리 조직에 특수한 제약을 적어줘야 일반론이 우리 현실로 좁혀집니다.
AI 초안에 무엇이 담기는가 — 다섯 가지 출력
작업분해·담당추정·선후행·마일스톤·일정리스크
잘 짠 프롬프트로 받은 초안에는 보통 다섯 종류의 정보가 들어 있습니다. 각각이 무엇이고, 어디까지 믿을 수 있는지 구분해 둡니다.
| 출력 | 뜻 | 신뢰도와 주의 |
|---|---|---|
| 작업 분해 | 큰 일을 실행 가능한 작업 단위로 쪼갠 목록 | 출발점으로 유용. 마무리·폐기 작업 누락 잦음 |
| 담당 조직 추정 | 작업별로 추정한 수행 주체 | 가설로만. 실제 R&R로 반드시 검증 |
| 선후행 관계 | 작업 간 순서·의존성(A 끝나야 B) | 대체로 합리적. 우리 환경 특수 의존성은 빠질 수 있음 |
| 마일스톤 | 의미 있는 완료 지점(승인·점검·완료보고) | 제안 수준. 실제 일정 기준일과 맞춰야 함 |
| 일정 리스크 | 지연·실패 가능 지점과 영향 | 발상 촉진용. 우리만의 진짜 리스크 추가 필요 |
특히 담당 조직 추정과 일정 리스크는 'AI가 정답을 줬다'가 아니라 'AI가 검토 거리를 던졌다'로 받아들여야 합니다. AI가 "보안팀이 패치 검증"이라고 추정해도, 그 주에 보안팀이 다른 감사로 꽉 차 있는지는 사람만 압니다. 리스크도 마찬가지로, AI가 일반적 리스크를 나열하면 그걸 마중물 삼아 "우리 점검창이 2시간뿐이라 롤백 시간이 부족하다" 같은 현장 리스크를 사람이 더합니다.
위 판단을 한 장의 게이트로 묶으면 이렇게 됩니다. AI 초안은 그대로 일정이 되는 게 아니라 **누락·기간·의존성·담당·리스크 다섯 축을 사람이 통과시킨 뒤에야 "확정 WBS"**가 됩니다. 펼치는 일은 AI가 빠르게 하고, 통과시키는 책임은 사람이 집니다.
프롬프트 비교 — 한 줄 요구 vs 맥락·예시를 갖춘 요청
나쁜 프롬프트 → 좋은 프롬프트 — Few-shot으로 사내 WBS 포맷을 박는다
WBS 프롬프트가 '대충'이면 그럴듯한 일반론이 나오고, 사내 양식과도 어긋나 다시 손봐야 합니다. 두 프롬프트를 비교해 보세요.
❌ 나쁜 프롬프트 — 맥락도 형식도 없다
운영계 SSL 인증서 교체 WBS 짜줘.
→ AI는 "인증서 발급 → 적용 → 확인" 식의 교과서적 3~4단계 일반론을 줍니다. 우리 점검창이 2시간뿐인 것도, CAB 승인 리드타임도, 구 인증서 폐기·알람 갱신 같은 마무리 작업도 들어가지 않습니다. 표 모양도 매번 달라 사내 WBS 양식에 옮기기 번거롭습니다.
✅ 좋은 프롬프트 — 역할 + 맥락 4종 + Few-shot 예시 + 누락 방어
여기서 핵심 강화는 Few-shot(예시 한 줄을 보여주기) 입니다. AI에게 "이런 모양으로 채워라"를 글로 설명하는 것보다 사내 WBS 한 줄을 예시로 보여주는 것이 형식을 훨씬 정확히 따르게 만듭니다.
역할: 너는 SI/운영 변경 작업의 일정 계획을 돕는 PMO 보조자다.
[작업] 운영계 웹 구간 SSL 인증서 교체 + OS 보안 패치 반영
[범위] 운영계 웹서버 2대와 앞단. DB·내부 관리망 제외.
[제약] 무중단 불가, 점검창 새벽 02~04시(2시간), 변경은 CAB 승인 대상,
외부 고객 영향 있어 사전 공지 의무.
[환경] 사내 변경관리 절차 준수, 인프라팀·보안팀·협력사(현장) 분담, 롤백 가능해야 함.
[출력 예시 — 이 형식과 상세도를 그대로 따라라]
| WBS | 작업 항목 | 추정 담당 | 선행 | 예상 소요 | 비고(리스크) |
| 1.1 | 신규 인증서 발급·검증 | 보안팀 | 없음 | 1일 | 인증기관 발급 리드타임 |
[/예시]
[요청] 위 형식으로 전체 WBS를 만들고, 표 아래에 (1) 마일스톤 (2) 일정 리스크 Top 5를 적어라.
[누락 방어] 다음 영역이 빠지지 않았는지 스스로 확인하고, 빠졌으면 추가하라:
구 인증서 폐기, 모니터링/알람 인증서 갱신, 패치 후 정상성 확인,
롤백 절차·롤백 시간, 고객 사전공지·공지 해제, 변경 종료 보고.
확실하지 않은 가정은 '가정:', 빠질 수 있는 작업은 '확인 필요'로 표시하라.
[출력 예시] 한 줄(Few-shot)이 WBS 번호 체계·열 구성·상세도를 못박고, [누락 방어] 목록이 PMO가 경험으로 아는 "빠지기 쉬운 마무리 작업"을 AI에게 미리 주입합니다. 일반론이 우리 양식·우리 절차로 좁혀지는 지점입니다.
직접 해보기 — SSL 인증서 교체 WBS를 AI로 펼치고 검토하기
아래 프롬프트는 범위·제약·환경·산출 형식을 모두 채운 형태입니다. 이대로 AI에 넣으면 표 형태의 WBS 초안이 나옵니다. 여러분의 실제 상황에 맞게 대괄호 부분을 바꿔 쓰세요.
역할: 너는 IT 운영 변경 작업의 일정 계획을 돕는 보조자다.
[작업] 운영계 웹 구간 SSL 인증서 교체 + OS 보안 패치 반영
[범위] 운영계 웹서버 2대와 그 앞단 구성. DB·내부 관리망은 제외.
[제약] 무중단 불가, 점검창 새벽 02~04시(2시간), 변경은 CAB 승인 대상,
외부 고객 영향 있어 사전 공지 의무.
[환경] 사내 변경관리 절차 준수, 인프라팀·보안팀·협력사(현장 작업) 분담,
롤백 가능해야 함.
[요청] 위 작업을 WBS로 분해해, 다음 열을 가진 표로 만들어줘:
작업 항목 / 추정 담당 / 선행 작업 / 예상 소요 / 비고(리스크).
표 아래에 별도로 (1) 마일스톤 목록과 (2) 일정 리스크 Top 5를 적어줘.
확실하지 않은 가정은 '가정:'으로 표시하고, 빠질 수 있는 작업은 '확인 필요'로 표시해줘.
마지막 두 줄("가정 표시", "확인 필요 표시")이 검토를 쉽게 만드는 장치입니다. AI가 스스로 불확실한 부분을 드러내게 하면, 사람이 어디를 먼저 볼지 빨라집니다.
프롬프트 → AI → 표 형태 WBS 초안AI가 돌려준 초안을 그대로 제출하지 말고, 아래 세 축으로 손봅니다. 이게 이 작업의 핵심입니다.
1) 누락(100% 규칙): 상위 작업의 합이 범위를 빠짐없이 덮는가?
- 흔한 누락: 구 인증서 폐기, 모니터링/알람 인증서 갱신,
변경 종료 보고, 패치 후 서비스 정상성 확인, 고객 안내 발송·해제
2) 기간: 각 소요가 우리 현실에서 가능한가?
- 점검창 2시간 안에 교체+패치+재부팅+검증+롤백 여유가 다 들어가는가?
- AI 기간은 보통 낙관적 → 과거 작업 이력으로 재산정
3) 의존성: 선후행이 실제 환경과 맞는가?
- CAB 승인은 작업 며칠 전 마감(리드타임) → 선행에 반영됐는가?
- 패치 후 재부팅이면 '무중단' 표시는 틀림 → 점검창 안으로
초안 → 누락·기간·의존성 점검 → 확정본사람 검토(Step 2) 전에, AI에게 스스로 한 번 점검하게 하면 사람이 볼 곳이 줄어듭니다. Step 1 초안을 받은 같은 대화에 아래를 이어서 넣어 보세요.
[자기검증] 위 WBS를 사람에게 넘기기 전에 스스로 점검하라.
1) 100% 규칙: 빠진 마무리·폐기 작업(구 인증서 폐기, 알람 갱신,
롤백, 종료 보고, 고객 공지 해제)이 있으면 모두 찾아 추가하라.
2) 점검창 2시간 안에 모든 작업+롤백 여유가 들어가는지 합산해 검증하라.
안 들어가면 어떤 작업을 분할/사전작업으로 빼야 하는지 제안하라.
3) '당일 CAB 승인'처럼 비현실적 가정이 있으면 '가정:'으로 표시하라.
4) 위를 반영한 최종 WBS를 다시 출력하라.
AI가 "2) 점검창 2시간에 교체 40분 + 패치 30분 + 재부팅 15분 + 검증 30분 = 1시간 55분, 롤백 여유 5분뿐 → 위험"처럼 스스로 합산해 주면, 사람은 그 지점부터 검토를 시작하면 됩니다. 단, 자기검증의 결과도 초안입니다. 최종 기간·담당·리스크 수용 여부는 조직 사정을 아는 사람이 확정합니다.
자기검증 프롬프트 → 사람 최종 확정- 초안에 작업 분해·담당 추정·선후행·예상 소요·리스크 열이 모두 채워져 나오는가 — 빠진 열이 있으면 프롬프트의 산출 형식을 더 명시
- AI가 스스로 "가정:" 또는 "확인 필요"로 표시한 줄이 있는가 — 그 줄부터 검토 시작
- 100% 규칙 점검에서 마무리·폐기 작업(구 인증서 폐기, 알람 갱신, 종료 보고)이 빠져 있지 않은가
- 점검창 2시간 안에 교체+패치+재부팅+검증과 롤백 여유까지 들어가는가 — 안 들어가면 작업 분할·점검창 협의 필요
- CAB 승인 리드타임이 선행 작업으로 잡혀 있는가 — 당일 승인 가정은 거의 항상 비현실적
- 담당 조직 추정이 실제 R&R·가용성과 맞는가 — 협력사 작업 범위(계약)와 어긋난 배정이 없는가
- 고객 사전 공지·작업 후 공지 해제가 작업과 마일스톤에 모두 들어 있는가
현장에서 자주 보는 함정
증상: 보기 좋은 표가 30초 만에 나와서 그대로 일정으로 확정·공유했습니다. 그런데 점검 당일 (1) 2시간 점검창 안에 작업이 다 안 끝나고, (2) "구 인증서 폐기"와 "모니터링 알람 인증서 갱신"이 WBS에 없어 다음 날 알람 오탐이 쏟아졌으며, (3) CAB 승인이 당일에 안 떨어져 작업 자체가 한 번 밀렸습니다.
원인: AI 초안을 초안이 아니라 완성본으로 취급했습니다. AI는 (a) 우리 점검창이 2시간뿐이라는 현실적 시간 제약을 모르고 기간을 낙관적으로 잡았고, (b) 일반적 교체 절차만 알아 우리 운영의 마무리·폐기 작업을 빠뜨렸으며, (c) CAB 승인 리드타임 같은 내부 절차를 알 수 없었습니다. 전부 '조직의 실제 사정'이라 AI가 메울 수 없는 빈칸인데, 사람이 그 빈칸을 검토하지 않았습니다.
해결 방향:
- AI 초안은 항상 검토 체크리스트(누락·기간·의존성)를 한 번 통과시킨 뒤 확정합니다 — Step 2가 바로 그 절차.
- 기간은 AI 숫자를 믿지 말고 과거 동일 작업 이력으로 재산정하고, 점검창 안에 롤백 시간까지 포함되는지 봅니다.
- **내부 절차(CAB 승인 리드타임·고객 공지 의무)**는 프롬프트의 환경 맥락에 미리 적고, 그래도 빠지면 사람이 선행 작업으로 추가합니다.
- 담당·리스크는 AI 추정을 가설로만 받고, 실제 R&R과 현장 리스크로 채워 넣습니다.
요점은 AI를 버리는 게 아니라, AI가 못 메우는 빈칸(우리만의 현실)이 어디인지 알고 사람이 거기에 집중하는 것입니다.
국내 운영(SM)·SI 현장에서 변경 작업의 일정과 고객 안내안을 만드는 일은 PM·운영 담당의 거의 매주 업무입니다. 예전에는 빈 엑셀을 앞에 두고 한두 시간을 '무엇부터 적지'로 보냈다면, 지금은 AI에 범위·제약·환경을 정리해 던지고 30초 만에 초안을 받아 검토부터 시작합니다 — 출발 마찰이 사라지는 만큼 검토·확정에 시간을 더 쓸 수 있습니다.
다만 발주사·원청에 제출되는 WBS·일정·고객 안내안의 정확성에 대한 책임은 끝까지 사람(관리자)에게 있습니다. "AI가 그렇게 짰다"는 점검 당일 무너진 일정의 변명이 되지 못합니다. 그래서 현장에서 인정받는 PM은 AI를 안 쓰는 사람이 아니라, AI로 빠르게 펼치되 우리 조직의 점검창·승인 리드타임·협력사 분담·고객 의무를 아는 사람의 눈으로 끝까지 검토해 확정하는 사람입니다. CAB 승인 절차, 점검창 운영, 변경 종료 보고 같은 우리 회사의 실제 절차를 아는 것이 AI 초안을 진짜 계획으로 바꾸는 힘입니다. 이 검토 역량은 다음 트랙들(변경관리·고객 안내·산출물 표준)과 곧장 이어집니다.
관련 모듈로 더 깊이:
- WBS와 일정 관리 — AI가 펼친 초안을 검증할 기준이 되는 WBS·일정의 원리
- 변경계획서·롤백계획서·작업절차서 — AI가 자주 빠뜨리는 점검창·롤백 시간을 채워 넣는 변경 산출물
- AI로 장애 대응 보조 — 계획이 무너져 장애가 터졌을 때 AI로 대응을 보조하는 다음 단계
다음 모듈에서는 작업이 계획대로 안 되고 장애가 터졌을 때 — AI로 장애 대응·RCA(근본원인분석)를 보조하는 패턴, 즉 로그·증상을 정리해 가설을 빠르게 펼치고 사람이 원인을 확정하는 방법을 다룹니다.