Prepare → Plan → Design → Implement → Operate → Optimize
🎯 PPDIOO란?
PPDIOO: Cisco가 제안한 네트워크/인프라 라이프사이클 방법론. 6단계로 구성되며, 설계부터 운영 최적화까지 기술 관점의 전체 수명주기를 다룸.
| 항목 | 설명 |
|---|
| 출처 | Cisco Lifecycle Services |
| 성격 | 인프라/네트워크 도메인 특화 방법론 |
| 범위 | 설계 → 구축 → 운영 → 최적화 (반복) |
| 대상 | 네트워크, 서버, 보안, UC 등 인프라 전반 |
PMBOK, SI 라이프사이클과의 차이
| 구분 | PMBOK | SI 라이프사이클 | PPDIOO |
|---|
| 관점 | 프로젝트 관리 | 프로젝트 수행 절차 | 기술 수명주기 |
| 범위 | 범용 (산업 무관) | 한국 공공 SI 특화 | 인프라 도메인 특화 |
| 초점 | 범위/일정/비용/리스크 | 단계별 산출물, 감리 | 기술 설계/구현/운영 |
| 운영 포함 | ✕ (프로젝트 종료까지) | △ (안정화/하자보수) | ◎ (Operate/Optimize) |
| 반복 | 프로세스 그룹 반복 | 선형 (착수→완료) | 순환 (Optimize→Plan) |
💡 세 가지는 대체가 아니라 보완 관계. PMBOK으로 관리하고, SI 라이프사이클로 절차를 따르고, PPDIOO로 기술적 판단을 함.
전체 흐름
핵심: Optimize에서 발견된 개선 사항이 다시 Plan으로 돌아가는 순환 구조. 인프라는 한번 구축하고 끝이 아니라, 지속적으로 개선함.
📋 Phase 1: Prepare (준비)
비즈니스 요구사항을 파악하고, 기술 전략을 수립하는 단계임. SI에서는 제안/착수 단계와 겹침.
주요 활동
| 활동 | 설명 |
|---|
| 비즈니스 요구사항 파악 | 조직의 목표, IT 전략, 예산 |
| 기술 전략 수립 | 어떤 기술 방향으로 갈 것인가 |
| ROI/비즈니스 케이스 | 투자 대비 효과 분석 |
| 범위 정의 | 프로젝트 대상 범위 확정 |
| 조직/인력 계획 | 필요 역량, 팀 구성 |
비즈니스 요구사항 → 기술 요구사항
비즈니스 언어를 기술 언어로 변환하는 것이 Prepare의 핵심임. "서비스가 안 끊겼으면 좋겠어"를 "가용성 99.99%, RTO 15분"으로 바꾸는 것임.
공공 SI에서의 Prepare
| PPDIOO | SI 대응 | 설명 |
|---|
| 비즈니스 요구사항 | RFP 분석 | 발주처가 이미 요구사항을 정리해둠 |
| 기술 전략 | 제안 전략 | 어떤 기술로 차별화할 것인가 |
| ROI 분석 | 제안서 기대효과 | 도입 효과, TCO 절감 |
| 범위 정의 | 사업 범위 확인 | 계약 범위 = 프로젝트 범위 |
💡 공공 SI에서는 발주처가 RFP로 상당 부분을 정의해주기 때문에 Prepare가 간소화되는 경향이 있음. 하지만 RFP에 없는 것을 제안하는 게 차별화 포인트임.
📋 Phase 2: Plan (계획)
현재 상태를 분석하고, 인프라 설계의 기준이 되는 요구사항을 구체화하는 단계임.
주요 활동
| 활동 | 설명 |
|---|
| 현황 조사 (AS-IS) | 기존 인프라 인벤토리, 토폴로지, 성능 |
| Gap 분석 | 현재 vs 목표 간 차이 식별 |
| 요구사항 상세화 | 성능, 가용성, 보안, 확장성 수치화 |
| 제약 조건 식별 | 예산, 기존 장비, 물리적 제약 |
| 마이그레이션 전략 | 전환 방식 결정 (빅뱅/단계/병행) |
AS-IS 조사 항목
| 영역 | 조사 내용 |
|---|
| 네트워크 | 토폴로지, 장비, VLAN, 라우팅, 대역폭 사용률 |
| 서버 | 인벤토리, 사양, 리소스 사용률, OS/패치 |
| 스토리지 | 용량/사용률, IOPS, 레이턴시 |
| 보안 | 방화벽 룰 수, IPS 이벤트, 취약점 |
| 운영 | 장애 이력, SLA 달성률, 모니터링 현황 |
Gap 분석
요구사항 수치화
Plan 단계에서 가장 중요한 것은 애매한 요구사항을 측정 가능한 수치로 바꾸는 것.
| 애매한 요구사항 | 수치화 |
|---|
| "빨라야 함" | 응답시간 ≤ 3초 (95 percentile) |
| "안 끊겨야 함" | 가용성 99.99% (연 52분 이하 중단) |
| "충분한 용량" | 현재 대비 3년 150% 증가 수용 |
| "안전해야 함" | ISMS-P 인증 기준, CC EAL4 이상 |
| "확장 가능" | 서버 50% 증설 시 네트워크 변경 없음 |
가용성 등급
| 등급 | 가용성 | 연간 중단 | 일반 적용 |
|---|
| 2 Nines | 99% | 3.65일 | 개발/테스트 |
| 3 Nines | 99.9% | 8.76시간 | 일반 업무 |
| 4 Nines | 99.99% | 52.6분 | 핵심 서비스 |
| 5 Nines | 99.999% | 5.26분 | 금융/통신 |
📋 Phase 3: Design (설계)
Plan의 요구사항을 바탕으로 구체적인 인프라 설계를 수행하는 단계임. PPDIOO의 핵심.
설계 계층
Cisco는 설계를 두 단계로 나눔:
| 단계 | 설명 | 산출물 |
|---|
| High-Level Design (HLD) | 전체 아키텍처, 기술 선정 | 아키텍처 구성도, 기술 선정서 |
| Low-Level Design (LLD) | 상세 구성, 파라미터 | IP/VLAN 설계, 장비 설정값 |
High-Level Design (HLD)
| 항목 | 내용 |
|---|
| 네트워크 토폴로지 | Spine-Leaf vs 3-Tier, L2/L3 경계 |
| 서버 아키텍처 | 가상화 vs 물리, 클러스터 구성 |
| 스토리지 아키텍처 | SAN vs HCI vs NAS, 티어링 |
| 보안 아키텍처 | Zone 구분, 보안 장비 배치 |
| 이중화/DR | HA 방식, DR 구성, RTO/RPO |
| 관리 체계 | 모니터링, 백업, 자동화 |
HLD 검증 포인트:
| 검증 | 질문 |
|---|
| 확장성 | 서버가 50% 늘어나면 이 설계가 수용 가능한가? |
| 가용성 | 단일 장애점(SPOF)이 없는가? |
| 성능 | 병목이 어디에서 발생할 수 있는가? |
| 보안 | 각 Zone 간 접근 통제가 명확한가? |
| 운영성 | 운영 팀이 관리할 수 있는 복잡도인가? |
Low-Level Design (LLD)
HLD를 구현 가능한 수준으로 상세화. 엔지니어가 이걸 보고 바로 설치/설정할 수 있어야 함.
네트워크 LLD 예시:
| 항목 | 상세 |
|---|
| VLAN 설계 | VLAN 10: 서버관리(10.1.10.0/24), VLAN 20: 서비스(10.1.20.0/24) |
| IP 설계 | 대역별 할당, Gateway, 예약 IP |
| 라우팅 | BGP ASN 설계, OSPF Area |
| 스위치 설정 | 포트별 VLAN, Trunk, LACP |
| 방화벽 룰 | Source, Destination, Port, Action |
서버 LLD 예시:
| 항목 | 상세 |
|---|
| OS 파티션 | /, /boot, /var, /opt, swap 크기 |
| NIC 설정 | Bond 구성, VLAN 태깅 |
| 보안 설정 | SELinux, sshd 설정, 불필요 서비스 비활성화 |
| 에이전트 | 모니터링, 백업, 보안 에이전트 |
설계 리뷰 (Design Review)
| 리뷰 | 중점 |
|---|
| 내부 | 기술적 정합성, 표준 준수 |
| 벤더 | 제품 호환성, 권장 구성, 지원 가능 여부 |
| 고객 | 요구사항 반영 여부, 운영 가능성 |
Pilot/PoC
중요한 설계 결정에 대해서는 실제 검증을 수행.
| 유형 | 목적 | 규모 |
|---|
| PoC (Proof of Concept) | 기술/제품이 동작하는지 검증 | 소규모, 핵심 기능만 |
| Pilot | 실 환경과 유사한 조건에서 검증 | 중규모, 일부 사용자 |
💡 공공 SI에서 PoC는 제안 단계에서 수행하기도 하고(벤더 지원), 착수 후 분석 단계에서 수행하기도 함.
📋 Phase 4: Implement (구현)
설계를 바탕으로 실제 구축하는 단계임.
주요 활동
| 활동 | 설명 |
|---|
| 설치 계획 | 설치 순서, 일정, 체크리스트 |
| 장비 설치 | 랙 마운트, 케이블링, 전원 |
| 시스템 구성 | OS, 네트워크, 스토리지 설정 |
| 검증 (Verification) | 설계 대비 구현 확인 |
| 마이그레이션 | 기존 시스템에서 전환 |
구현 순서
검증 (Verification & Validation)
| 구분 | Verification | Validation |
|---|
| 질문 | "설계대로 만들었나?" | "요구사항을 충족하나?" |
| 방법 | LLD 대비 설정값 확인 | 시험 시나리오 수행 |
| 시점 | 구성 직후 | 시험 단계 |
Verification 체크리스트 예시:
| 항목 | 확인 |
|---|
| IP/VLAN이 LLD와 일치하는가 | □ |
| 방화벽 룰이 설계서와 일치하는가 | □ |
| 이중화가 설계대로 동작하는가 | □ |
| 스토리지 LUN 매핑이 맞는가 | □ |
| 백업이 스케줄대로 수행되는가 | □ |
마이그레이션 전략
| 방식 | 적합한 경우 |
|---|
| 빅뱅 | 규모가 작거나, 다운타임이 허용되는 경우 |
| 단계적 | 시스템/서비스별로 순차 전환 가능한 경우 |
| 병행 | 리스크가 높고, 검증 기간이 필요한 경우 |
롤백 계획
모든 구현에는 **"실패하면 어떻게 하나"**가 있어야 함.
| 항목 | 내용 |
|---|
| 롤백 기준 | 어떤 상황에서 원복하는가 |
| 롤백 시간 | 원복에 걸리는 시간 |
| 롤백 절차 | 단계별 원복 순서 |
| 판단 주체 | 누가 롤백을 결정하는가 |
| 테스트 | 롤백 절차가 실제로 동작하는지 검증 |
📋 Phase 5: Operate (운영)
시스템을 안정적으로 운영하는 단계. PMBOK/SI 라이프사이클에서는 프로젝트 범위 밖이지만, PPDIOO에서는 핵심 단계임.
주요 활동
| 활동 | 설명 |
|---|
| 모니터링 | 성능, 가용성, 보안 실시간 감시 |
| 인시던트 관리 | 장애 감지 → 대응 → 복구 → 분석 |
| 변경 관리 | 설정 변경, 패치, 업그레이드 통제 |
| 용량 관리 | 리소스 사용 추이 추적, 증설 계획 |
| 백업/복구 | 정기 백업, 복구 테스트 |
| 보안 운영 | 취약점 패치, 보안 이벤트 모니터링 |
| 문서 관리 | 구성 변경 시 문서 업데이트 |
인시던트 관리 프로세스
심각도 분류:
| 등급 | 기준 | 대응 시간 |
|---|
| P1 (Critical) | 서비스 전면 중단 | 15분 이내 |
| P2 (High) | 주요 기능 장애 | 30분 이내 |
| P3 (Medium) | 일부 기능 저하 | 4시간 이내 |
| P4 (Low) | 경미한 이슈 | 익영업일 |
변경 관리
운영 중 설정 변경은 장애의 주요 원인. 체계적인 변경 관리가 필수임.
| 변경 유형 | 예시 | 리스크 |
|---|
| 표준 변경 | 사용자 계정 생성 | 낮음 |
| 일반 변경 | 방화벽 룰 추가, 서버 증설 | 중간 |
| 긴급 변경 | 보안 패치, 장애 대응 | 높음 |
운영 문서
| 문서 | 내용 |
|---|
| 운영 매뉴얼 | 일상 점검, 장애 대응 절차 |
| 구성 관리 DB (CMDB) | 장비, IP, 연결 관계, 변경 이력 |
| SOP (표준운영절차) | 반복 작업의 절차서 |
| 장애 대응 매뉴얼 | 시나리오별 복구 절차 |
📋 Phase 6: Optimize (최적화)
운영 데이터를 분석하여 개선점을 찾고, 다음 사이클로 연결하는 단계임.
주요 활동
| 활동 | 설명 |
|---|
| 성능 분석 | 병목 식별, 트렌드 분석 |
| 용량 예측 | 향후 리소스 소요 예측 |
| 비용 최적화 | 불필요 리소스 정리, 라이선스 최적화 |
| 기술 평가 | 신기술 도입 검토, EOL 장비 교체 계획 |
| 아키텍처 개선 | 설계 변경이 필요한 부분 식별 |
최적화 사이클
최적화 영역별 예시
| 영역 | 현상 | 최적화 |
|---|
| 성능 | DB 응답 지연 증가 | 인덱스 튜닝, 스토리지 티어 변경 |
| 용량 | 스토리지 80% 사용 | 증설 또는 아카이빙 정책 |
| 비용 | 유휴 VM 다수 | VM 통합, 리소스 재할당 |
| 보안 | 구형 장비 취약점 | 장비 교체, 패치 |
| 아키텍처 | 3-Tier 병목 | Spine-Leaf 전환 검토 |
| 운영 | 반복 수작업 많음 | 자동화 (Ansible, Terraform) |
EOL/EOS 관리
장비와 소프트웨어의 수명주기를 추적하여 교체 시점을 계획함.
| 단계 | 의미 | 대응 |
|---|
| GA | General Availability | 도입 가능 |
| EOS | End of Sale | 신규 구매 불가, 대체 제품 검토 |
| EOSS | End of SW Support | SW 업데이트 종료, 교체 계획 |
| EOL | End of Life | 전체 지원 종료, 교체 필수 |
🔄 PPDIOO ↔ 다른 프레임워크 매핑
PPDIOO ↔ SI 라이프사이클
| PPDIOO | SI 라이프사이클 | 비고 |
|---|
| Prepare | 제안, 착수 | 비즈니스 요구 → RFP 분석 |
| Plan | 분석 | AS-IS 분석, 요구사항 |
| Design | 설계 | HLD = 아키텍처 설계, LLD = 상세 설계 |
| Implement | 구축, 시험, 이관 | 설치 + 검증 + 전환 |
| Operate | 안정화, (운영) | SI는 안정화까지, PPDIOO는 계속 |
| Optimize | (해당 없음) | SI 프로젝트 범위 밖 |
PPDIOO ↔ PMBOK
| PPDIOO | PMBOK 프로세스 그룹 | 비고 |
|---|
| Prepare | 착수 (Initiating) | 헌장, 이해관계자 식별 |
| Plan | 기획 (Planning) | 범위, 일정, 비용 계획 |
| Design | 기획 (Planning) | PMBOK에서는 기획에 포함 |
| Implement | 실행 (Executing) | 작업 수행 |
| Operate | - | PMBOK 범위 밖 |
| Optimize | - | PMBOK 범위 밖 |
| (전체) | 감시/통제 (M&C) | 전 단계에 걸침 |
삼각 관계 정리
| 질문 | 답을 주는 프레임워크 |
|---|
| "일정이 지연되면 어떻게 하나?" | PMBOK (일정 관리) |
| "이번 주에 어떤 산출물을 내야 하나?" | SI 라이프사이클 |
| "이 설계가 확장 가능한가?" | PPDIOO (Design) |
| "운영 중 장애가 나면?" | PPDIOO (Operate) |
| "예산 초과 위험은?" | PMBOK (비용/리스크 관리) |
| "감리에서 뭘 점검하나?" | SI 라이프사이클 |
💡 실무 적용 팁
제안서에서의 활용
제안서에 "PPDIOO 기반 인프라 구축 방법론 적용"이라고 쓰는 경우가 있음.
[제안서 문구 예시]
본 사업은 Cisco PPDIOO 방법론을 기반으로 체계적인 인프라 구축을 수행합니다.
- Prepare/Plan: 현황 분석 및 요구사항 상세화
- Design: HLD/LLD 기반 단계적 설계
- Implement: 검증(Verification) 포함 구축
- Operate/Optimize: 안정화 및 운영 최적화 지원
엔지니어 관점에서 중요한 것
| Phase | 엔지니어 핵심 역할 |
|---|
| Plan | AS-IS를 정확히 파악. 현장 조사 꼼꼼히 |
| Design | HLD→LLD 사이에 빠지는 것 없도록. LLD는 "보고 따라하면 되는 수준" |
| Implement | 설치 후 반드시 Verification. 설정 즉시 문서화 |
| Operate | 변경 관리 철저. 문서 없는 변경은 장애의 원인 |
| Optimize | 모니터링 데이터로 말하기. 감으로 판단하지 않기 |
🔗 관련 문서
🔗 참고 자료