📄 2026.03.10 (Day 89) - WBS 작성 및 이번 주 수행 계획 확정
1. 핵심 개념 정리
WBS (Work Breakdown Structure) 개념 및 구조
| # | 핵심 개념 | 설명 | 실무/보안 관점 |
|---|---|---|---|
| 1 | WBS (작업분할구조도) | 프로젝트 전체 작업을 단계별로 분해하여 작업자·상태·진척율·시작일·종료일·작업기간을 명시하는 프로젝트 관리 문서 | 컨설팅 프로젝트에서 WBS는 수주 후 첫 번째 공식 산출물. 일정·인력·범위를 한눈에 파악하게 해주는 뼈대 |
| 2 | WBS 단계 구분 | 체계 수립 → 현황 조사 → 일정 수립 → 계획 착수 → 계획 실행 → 중간점검 수행 → 최종 산출물 제작 → 최종 발표 순으로 구성 | 단계별 상태(완료/진행/계획)와 진척율을 함께 관리해야 지연 항목을 즉시 식별 가능 |
| 3 | WBS 1 vs WBS 2 | WBS 1: 하랑항공(갑)과 리베로(을) 간 위수탁 관계 기준의 수행 WBS. WBS 2: 팀 전체 프로젝트 관리 WBS. 멘토님 권고에 따라 두 개를 통합하는 방향으로 정리 | 두 WBS를 분리 관리하면 중복 항목과 일정 충돌이 발생. 통합 구조가 실무에서도 일반적 |
| 4 | 간트 차트 (Gantt Chart) | WBS에 날짜 축을 붙여 각 작업의 시작·종료·기간을 시각화한 표. 행(작업)과 열(날짜)로 구성되며 작업 진행 현황을 색상·기호로 표시 | 발표 자리에서 심사위원이 일정 관리 능력을 확인하는 핵심 문서. 빈 셀이나 날짜 불일치가 있으면 신뢰도 하락 |
| 5 | M/M (Man-Month) | 작업에 투입된 인력×기간을 나타내는 단위. 예: 1명이 1개월 투입하면 1M/1M. WBS 기반으로 계산하여 수행계획서에 반영 | RFP 기술협상 단계에서 인력 투입 계획의 근거가 됨. 실무에서는 M/M을 기반으로 비용 산정도 이루어짐 |
컨설팅 프로젝트 산출물 체계
| # | 핵심 개념 | 설명 | 실무/보안 관점 |
|---|---|---|---|
| 6 | 수행계획서 | WBS를 포함하여 프로젝트 목표·범위·일정·인력·방법론·산출물 목록을 담은 문서. 고객사에 제출하는 공식 계획 문서 | 수행계획서가 명확하지 않으면 이후 범위 분쟁(Scope Creep)의 빌미가 됨 |
| 7 | 증적 자료 (Evidence) | 점검 항목의 이행 여부를 입증하는 문서·사진·로그·서명 등의 자료. 모든 항목의 증적을 만들 필요는 없으며, 핵심 항목 위주로 선별 구성 | 법적 분쟁 발생 시 증적 자료의 존재 여부가 책임 소재를 결정. 내부관리계획서·대표자 날인 등 법적 필수 포인트 우선 |
| 8 | 수탁자별 결과 보고서 | 각 수탁사에 대한 점검 결과(Y/P/N/NA 판정·개선 권고)를 담은 워드 형식의 개별 보고서. 수탁사마다 별도 작성 | 점검 결과보고서는 고객사에 제출하는 공식 문서이므로 판정 근거가 명확하게 기술되어야 함 |
| 9 | 이행점검 | 최초 점검 후 미흡 사항에 대해 수탁사가 개선 조치를 취했는지 확인하는 후속 점검 프로세스. 이행점검 계획서·결과보고서 별도 작성 | 1회 점검으로 끝나는 것이 아니라 이행 여부 확인까지가 컨설팅의 완전한 사이클 |
| 10 | 시연 동영상 | 프로젝트 결과물 및 점검 과정을 담은 5분 내외의 영상. 발표 보조 자료이자 독립적인 산출물 | 기술적 내용을 비전문가에게 전달하는 역량을 보여주는 자료. 흐름이 명확하고 핵심이 집약된 구성이 중요 |
프로젝트 현황 관리
| # | 핵심 개념 | 설명 | 실무/보안 관점 |
|---|---|---|---|
| 11 | 상태 분류 | 완료(100%) / 진행(진행 중, 진척율 일부) / 계획(0%, 착수 전)으로 구분. 상태와 진척율을 함께 표기하여 현황을 명확히 관리 | 진척율이 없는 “완료” 항목은 신뢰도 저하. 상태·진척율·날짜가 삼각 검증 가능해야 함 |
| 12 | 작업기간 산정 | 시작일과 종료일 기준으로 달력 기준 작업일수를 산정. 공휴일·휴일 제외 여부를 일관되게 적용해야 함 | 작업기간이 1일인 항목이 과도하게 많으면 일정의 신뢰성이 낮아 보임. 실제 소요 시간을 반영한 산정이 중요 |
| 13 | 크로스체킹 | 팀원 간 서로의 작업 결과물을 교차 검토하는 과정. 체크리스트 판정의 일관성·오류·누락을 발견하는 데 효과적 | 1인이 작성하면 놓치기 쉬운 기준 불일치를 크로스체킹으로 잡아낼 수 있음. 특히 N/P 경계 판정 항목에서 유효 |
| 14 | 트리플 체킹 | 체크리스트를 본인 감으로 1차 점검 → 이상 항목 메모장 기록 → 팀 전체 기준으로 2~3차 재검토하는 3단계 검증 방식 | AI 생성 현황에서 오류가 발생할 수 있으므로, 법령 기준과의 교차 확인이 트리플 체킹의 핵심 |
| 15 | 수탁자별 증적 자료 리스트 | 각 수탁사에 해당하는 증적 항목을 목록화한 문서. 어떤 증적을 수집·생성할 것인지 우선순위를 명시 | 증적 리스트를 먼저 만들어야 불필요한 작업을 줄이고 핵심 자료 확보에 집중 가능 |
2. 활동 내용 정리
활동 89-1: 팀 회의 - 이번 주 수행 계획 확정
목표: 체크리스트 트리플 체킹 결과 공유 및 이번 주 작업 우선순위 확정
회의 주요 결정 사항:
[ 이번 주 작업 우선순위 ]
1순위 ( 진행 중 또는 즉시 착수 )
- 수탁자별 시나리오 디테일 보완
- 금융 : AWS(S3) 항목 추가, 재위탁 시나리오 보완
- 키오스크 : 클라우드 항목 추가
- **WBS** 및 수탁사 프로젝트 수행계획서 작성
- 수탁자별 증적 자료 리스트 작성
2순위 ( 병행 진행 )
- 필수 증적 자료 생성
보류 항목 ( 일정 여유 시 )
- 크로스체킹 ( 완료 처리 )
- 각 수탁사별 워드 점검 보고서 완성 ( 완료 처리 )
- 개별 보고서
- 시연 동영상 5분 구성
WBS 관련 결정 사항:
[ WBS 통합 방향 ]
- **WBS 1** ( 하랑항공 & 리베로 ) : 위수탁 관계 기반의 실제 수행 일정
- **WBS 2** ( 팀 전체 ) : 프로젝트 5조 관리 일정
- 두 개를 하나로 통합하는 방향으로 확정
- 멘토링 1 ~ 5차를 WBS에 전부 녹일 필요 없음
- 핵심 단계 위주로 구성
활동 89-2: WBS 엑셀 작성
목표: 프로젝트 전체 일정을 단계별로 정리한 WBS 간트 차트 작성
WBS 구조 요약:
[ 단계 구분 및 주요 산출물 ]
[ 체계 수립 ]
- 팀 구성 및 역할 분담
- 일일보고서 및 회의록 작성
- Y / P / N / NA 기준 정의 / WBS 통합 확정
[ 현황 조사 / 일정 수립 ]
- ISMS-P 기반 항목 및 AWS 항목 추가
- 업종별 비율 확정
- WBS 작성 및 수정
[ 계획 착수 ]
- 제안요청서 양식 수립
- 계약서 양식 수립
- 현황관리 양식 수립
- 점검 계획서 양식 수립
- 수탁자 선정
- 진단결과보고서 양식 작성
[ 계획 실행 ]
- 체크리스트 작성 및 취합
- 계약서 · 협약서 수정
- 현황조사표 작성
- 교육계획서 작성
- 수행계획서 작성
- 인터뷰 항목 정리
- 수탁자 개별 결과보고서 작성
[ 중간점검 수행 ]
- 리허설 > 자료 수정 > 중간점검 실시
[ 계획 실행 ( 후반 ) ]
- 3차 멘토링 피드백 반영
- 체크리스트 최종 수정
- 종합 결과보고서 작성
- 이행점검 보고서 작성
- 증적 자료 마련
- 4차 멘토링 피드백 반영
[ 최종 산출물 제작 ]
- 5차 멘토링 피드백 반영
- 시연 동영상 제작
- 최종 발표 PPT 제작
- 최종 보고서 작성
[ 최종 발표 ]
- 산출물 최종 제출
- 최종 리허설
- 수료식 발표 및 Q & A
작성 시 주요 고려 사항:
[ 확인 항목 ]
- 작업자 필드 : 전원 / 개인별 담당자 구분 명시
- 상태 필드 : 완료 / 진행 / 계획 3단계로 통일
- 진척율 : 완료 ( 100% ) / 진행 ( 10 ~ 50% ) / 계획 ( 0% ) 기준 적용
- 날짜 형식 : YYYY - MM - DD 통일, **#VALUE!** 오류 항목 수정 필요
- 간트 차트 : 2월 2주 ~ 4월 3주 기간 커버, 날짜 축 M / W / D 3단계 표기
3. 비교·분석 표
WBS 상태별 항목 현황 (작성 기준일: 2026.03.10)
| 상태 | 주요 항목 | 비고 |
|---|---|---|
| 완료 | 팀 구성, RFP 양식, 계약서 양식, 체크리스트 작성, 중간점검, 3·4차 멘토링, 종합결과보고서 등 대부분 항목 | 일부 날짜 오류(#VALUE!) 수정 필요 |
| 진행 | 일일보고서 작성, 핵심 증적 자료 생성, 최종 발표 PPT, 최종 보고서 | 진척율 10~50% 수준 |
| 계획 | 5차 멘토링, 시연 동영상 제작, 이행점검 시나리오, 최종 산출물 제출, 최종 리허설, 수료식 | 4월 이후 일정 집중 |
이번 주 작업 항목 비교
| 항목 | 당초 계획 | 실제 진행 | 상태 변경 |
|---|---|---|---|
| 크로스체킹 | 진행 예정 | 완료 처리 | 완료로 전환 |
| 워드 점검 보고서 | 이번 주 완성 예정 | 완료 처리 | 완료로 전환 |
| 금융 AWS/재위탁 시나리오 | 이번 주 착수 | 진행 중 | 유지 |
| 키오스크 클라우드 항목 | 이번 주 착수 | 진행 중 | 유지 |
| WBS 작성 | 이번 주 착수 | 작성 완료 | 완료 |
| 증적 자료 리스트 | 이번 주 착수 | 착수 | 진행 |
4. 심화 분석
WBS 작성 원칙 및 실무 적용 기준
[ WBS 품질 기준 ]
1. 작업 단위 세분화
- 단일 작업이 5일을 초과하면 하위 작업으로 분해
- "양식 수립 > 내용 작성 > 수정" 등 단계를 명확히 구분
2. 날짜 일관성
- 종료일이 시작일보다 빠른 오류 ( **#VALUE!** ) 전수 확인 필요
- 작업기간 = 종료일 - 시작일 + 1 ( 달력 기준 )
3. 담당자 명시
- "전원"과 개인 담당 항목을 명확히 구분
- 개인 담당 항목은 책임자 이름 직접 기재
4. 진척율 현실성
- 착수했으면 최소 10% 이상 반영
- "완료" 표기 항목은 반드시 100%
- 진척율 0% 인 항목은 "계획" 상태 유지
5. 간트 차트 시각성
- 날짜 축 : M ( 월 ) / W ( 주 ) / D ( 일 ) 3단계 구성
- 완료 · 진행 · 계획을 색상으로 시각적 구분
- 중요 마일스톤 ( 중간점검, 최종발표 ) 별도 강조
프로젝트 전체 일정 구조
[ 리베로 프로젝트 타임라인 ]
- 2026.02.11 ~ 12 : 팀 구성 및 역할 분담
- 2026.02.23 ~ : 일일보고서 · 회의록 작성 시작
- 2026.02.28 ~ 03.01 : 1차 멘토링
- 2026.03.03 ~ 06 : 체크리스트 작성 및 양식 수립
- 2026.03.07 ~ 08 : 2차 멘토링 ( 수행계획서 피드백 )
- 2026.03.10 : **WBS** 작성 완료 ( 현재 )
- 2026.03.14 ~ 15 : 3차 멘토링 ( 체크리스트 · 협약서 피드백 )
- 2026.03.24 ~ 04.01 : 수행계획서 · 인터뷰 · 결과보고서 작성
- 2026.03.28 ~ 29 : 4차 멘토링 ( 발표자료 · 전체 산출물 )
- 2026.04.11 ~ 12 : 5차 멘토링 ( 최종 피드백 )
- 2026.04.13 : 최종 산출물 제출
- 2026.04.16 : 최종 리허설
- 2026.04.17 : 수료식 발표 및 Q & A
5. 실무/보안 적용
보안 전문가 관점 - WBS가 컨설팅에서 갖는 의미
| 관점 | 핵심 포인트 | 실무 적용 방안 |
|---|---|---|
| 일정 관리 | WBS의 완료·진행·계획 상태가 프로젝트 리스크를 선제적으로 드러냄 | 지연 항목을 주간 회의에서 즉시 식별하고 우선순위를 재조정 |
| 산출물 품질 | WBS에 명시된 산출물 항목이 실제 납품 기준이 됨. 빠진 항목은 고객사와의 분쟁 원인 | 산출물 목록을 WBS와 수행계획서에 동시 반영하여 이중 검증 |
| 책임 추적성 | 담당자가 명시된 WBS는 성과 평가와 책임 소재 파악의 기준 문서 | “전원” 항목은 팀 리더가, 개인 담당 항목은 해당 팀원이 진척 보고 |
| 고객 커뮤니케이션 | 고객사에 WBS를 정기적으로 공유하면 신뢰 관계 강화 및 추가 요구 사항 조기 파악 가능 | 주간 보고 시 간트 차트 기반으로 진척 현황 시각 보고 |
6. 배운 점 및 인사이트
새로 알게 된 점
-
WBS는 단순 일정표가 아니다: 직접 WBS를 작성해보니, 단계 구분·작업 분해·담당자 배정·날짜 산정이 서로 맞물려야 한다는 것을 실감했다. 하나라도 어긋나면 #VALUE! 같은 오류가 발생하거나, 작업기간이 현실과 맞지 않는 일정이 만들어진다.
-
통합 WBS의 효율성: WBS 1(위수탁 관계)과 WBS 2(팀 전체)를 처음에는 분리했지만, 중복 항목과 일정 충돌을 겪으면서 통합이 맞다는 멘토님 의견의 근거를 직접 이해했다.
-
“완료” 처리의 기준: 크로스체킹과 워드 점검 보고서가 완료 처리된 것을 보며, 컨설팅 프로젝트에서 완료 기준을 명확히 정의하지 않으면 팀 간 인식 차이가 생긴다는 점을 확인했다. 기준 없는 완료는 나중에 품질 문제로 돌아온다.
-
M/M 산정의 복잡성: WBS 기반으로 M/M을 계산하려면 각 작업의 실제 투입 시간을 역산해야 하는데, 작업기간이 짧은 항목이 많을수록 M/M이 과소 산정될 수 있다는 것을 처음 인식했다.
이전 학습과의 연결고리
-
Day 88 RFP 프로세스와 연결: 어제 학습한 RFP → 수주 → 기술협상 → WBS/수행계획서 흐름이 오늘 직접 WBS를 작성하는 활동으로 이어졌다. 개념이 실제 문서 작업으로 연결되는 경험이었다.
-
컨설팅 방법론 3단계와 연결: WBS의 단계 구분(체계 수립 → 현황 조사 → 계획 착수 → 실행 → 점검)이 현황 분석 → 평가 → 보호대책 수립의 컨설팅 방법론과 정확히 대응된다.
실무 적용 아이디어
보안 전문가 관점:
-
WBS 템플릿 재사용: 이번 프로젝트에서 작성한 WBS 구조는 향후 다른 수탁사 점검 프로젝트에서도 기본 템플릿으로 재활용 가능하다. 단계 구분과 산출물 목록은 거의 동일하기 때문이다.
-
#VALUE! 오류 관리: 날짜 미입력 항목을 방치하면 전체 기간 산정과 간트 차트가 무너진다. 작업 착수 전 날짜를 임시로라도 채워두는 습관이 필요하다.
-
증적 리스트 선제 작성: 증적 자료를 먼저 목록화하면 수집 범위를 명확히 하고 불필요한 작업을 줄일 수 있다. 이번 주 증적 리스트 작성이 다음 주 실제 증적 생성의 품질을 결정한다.
7. Quick Reference
WBS 필드 작성 기준
[ WBS 필드 작성 기준 ]
- 단계 구분 : 체계 수립 / 현황 조사 / 일정 수립 / 계획 착수 / 계획 실행 / 중간점검 수행 / 최종 산출물 제작 / 최종 발표
- 주요 업무 : 대분류 ( 예 : 체크리스트, 계약서, WBS )
- 세부 업무 : 소분류 ( 예 : 양식 수립, 항목 추가, 수정 )
- 작업자 : "전원" 또는 담당자 이름 직접 기재
- 상태 : 완료 / 진행 / 계획
- 진척율 : 완료 : 100% / 진행 : 10 ~ 50% / 계획 : 0%
- 시작일 : YYYY - MM - DD
- 종료일 : YYYY - MM - DD ( 시작일 이후여야 함 )
- 작업기간 : 종료일 - 시작일 ( 달력 기준 )
이번 주 핵심 산출물 체크리스트
시나리오 디테일 보완:
- 금융 수탁자: AWS(S3) 항목 추가
- 금융 수탁자: 재위탁 시나리오 보완
- 키오스크 수탁자: 클라우드 항목 추가
WBS 및 수행계획서:
- WBS 날짜 오류(#VALUE!) 전수 수정
- WBS 1+2 통합본 완성
- 수행계획서 작성 착수
증적 자료:
- 수탁자별 증적 자료 리스트 작성
- 핵심 증적 자료 생성 (법적 필수 포인트 우선)
8. 트러블슈팅
| 문제 | 원인 | 해결 방법 |
|---|---|---|
| WBS 날짜 필드에서 #VALUE! 오류 다수 발생 | 날짜 미입력 또는 날짜 형식 불일치로 인해 엑셀 수식 계산 오류 발생 | 날짜 미입력 항목 전수 조사 후 임시 날짜 입력. YYYY-MM-DD 형식으로 통일 |
| WBS 1과 WBS 2의 항목 중복으로 관리 비효율 발생 | 초기에 두 개의 WBS를 별도로 설계하여 중복 항목과 일정 충돌 발생 | 멘토님 권고대로 통합 방향으로 재구성. 핵심 단계 위주로 단일 WBS 유지 |
| “완료” 처리 기준이 팀원별로 달라 진척율 신뢰도 저하 | 완료 기준의 사전 정의 없이 각자 판단으로 처리 | 완료 기준 명확화: 산출물 생성 + 팀장 확인 + 최종 수정 반영 3단계 충족 시 완료 처리 |
Today’s Insight:
오늘 WBS를 직접 작성하면서, 컨설팅 프로젝트 관리가 단순한 할 일 목록이 아니라 작업·일정·인력·산출물이 유기적으로 연결된 구조임을 체감했다. #VALUE! 오류 하나가 전체 간트 차트를 흐트러뜨리는 것처럼, 실무에서도 WBS의 날짜·담당자·상태 필드가 하나라도 부정확하면 프로젝트 전체의 신뢰도가 무너진다. 또한 WBS 1과 WBS 2를 통합하는 과정에서, 컨설팅의 범위(Scope)를 처음부터 명확히 정의하는 것이 이후 중복 작업과 혼선을 얼마나 줄일 수 있는지를 직접 경험했다. 남은 프로젝트 기간 동안 WBS를 실제 진행 상황에 맞게 지속적으로 업데이트하는 습관이 최종 발표 품질을 결정한다.