IT PROJECT · GLOSSARY & FIELD NOTES
용어를 알면
프로젝트가 보인다.
WBS·PMBOK·CBD부터 요구사항·아키텍처·인도까지,
프로젝트 단계별 필수 용어를 소개하고, 교과서엔 없는 현장 통찰을 함께 담았습니다.
프로젝트는
이 순서로 흘러간다
착수에서 인도까지 6단계. 각 단계에 어떤 용어가 살아 있는지 흐름 위에서 한눈에 보고, 칩을 눌러 바로 펼쳐보세요.
- 01
- 02
- 03STEP 3 / 6
분석·설계
Analysis & Design요구사항을 식별·분석·명세하고 아키텍처를 설계한다. 실패의 50%가 여기 요구사항에서 갈린다.
이 단계의 용어 34요구사항 식별검증(Validation)변경관리CCBRisk(위험)요구사항 분석확인(Verification)요구사항 명세서SRS비기능 요구사항NFRFURPSTrade-OffIssue(이슈)UseCase 모델BaselineOO 모델링OOMSWEBOKISO/IEC 2501025010Risk vs IssueValidation vs VerificationNeeds vs Requirements기능 vs 비기능UML클래스 다이어그램시퀀스 다이어그램상태 다이어그램활동 다이어그램개체관계도ERD데이터 모델링정규화프로토타이핑CRUDBABOKSFIACMMITOGAF분석·설계 단계 전체 보기 → - 04STEP 4 / 6
구현
Implementation컴포넌트를 조립해 시스템을 만든다. 재사용 자산·패턴·프레임워크의 이해가 생산성을 가른다.
- 05
- 06STEP 6 / 6
인도·운영
Delivery & Operation안정화·하자담보·인수인계로 끝맺는다. 점진개발보다 인도단계가 더 중요한 이유가 여기 있다.
아키텍트로 가는 길
무엇을, 어떤 순서로, 어디까지 공부해야 하는가. PMBOK·아키텍처·모델링·대용량 DB로 이어지는 4단계 학습 로드맵.
현장에서 갈리는
결정적 용어들
‘Risk는 예견, Issue는 발생’, ‘요구는 일정 폭까지 늘지만 임계점을 넘기면 실패’, ‘Validation은 고객 확정’. 주니어와 시니어를 가르는 건 이 용어들을 알고 일하느냐다.
Risk vs Issue
아직 오지 않은 예견(Risk)과 이미 발생한 문제(Issue). 현장 우선순위는 Issue가 앞선다.
Risk는 발생 확률과 영향으로 다루고 Issue는 이미 발생했으니 복구 속도와 영향 최소화로 다룬다. 현장 자원은 늘 부족해 Issue가 먼저지만, Risk가 Issue로 전환되는 순간을 누가 책임지고 변경관리로 넘기느냐가 분쟁의 갈림길이다.
분석·설계 · 비교Validation vs Verification
고객이 확인하는 Validation, 엔지니어가 검토하는 Verification. 검수 분쟁의 핵심 구분.
Verification은 명세대로 만들었는지를 엔지니어가 검토하고, Validation은 실제 요구를 충족하는지를 고객이 확인한다. 검수 분쟁의 대부분은 이 둘의 혼동에서 비롯되므로, 요구사항마다 측정 가능한 수용 기준을 명세서에 미리 박아 두는 것이 가장 확실한 예방책이다.
테스트 · 품질QA vs QC
QA는 과정과 산출물을 보증하고, QC는 완성된 결과물을 검사한다.
QA는 만들면서 보증하고(과정과 결과), QC는 완성품을 받아 검사한다. PM의 역할은 직접 테스트가 아니라 누가·어떤 기법·어느 커버리지로 검증할지 지침을 세우는 것이다.
구현 · 비교워터폴 vs 애자일
순차의 워터폴과 반복의 애자일. 조직 성숙도와 요구 변동성으로 가른다.
워터폴이냐 애자일이냐는 일정표 모양이 아니라 변경을 어느 시점·어떤 절차로 흡수하느냐의 문제다. 순수한 한쪽보다 단계는 순차로 묶고 내부는 반복으로 도는 혼합형이 현실적 기본값이며, 조직 성숙도와 권한 구조가 받쳐주지 않으면 애자일은 통제 잃은 워터폴로 변질된다.
분석·설계 · 비교Needs vs Requirements
잠재 요구(Needs)와 확정 요구(Requirements). 추가 요구는 대개 비기능에서 드러난다.
이해관계자의 말은 Needs일 뿐 Requirements가 아니다. 그 말 뒤의 의도를 검증 가능한 조건으로 다듬는 것이 분석의 본질이며, 명세에서 빠지기 쉬운 성능·보안·가용성 같은 비기능 Needs를 초기에 수치로 합의해 두는 것이 검수 분쟁을 막는 가장 확실한 장치다.
분석·설계 · 비교기능 vs 비기능
동작을 정의하는 기능과 품질을 정의하는 비기능. 검수 분쟁은 대개 비기능에서 난다.
기능은 되느냐 안 되느냐로 판정되지만 비기능은 측정 기준이 없으면 영원히 합의되지 않는다. 빠르게·안전하게 같은 막연한 표현을 응답 시간·동시 처리량·복구 시간 같은 수치로 못 박아 두는 것이, 검수 막바지에 쏟아지는 추가 요구와 분쟁을 막는 가장 확실한 방법이다.