Software Engineering: 분야의 지형도를 그리다 (Pressman의 큰 그림)
들어가며
이 글은 Process-Essential 시리즈의 1단계입니다. 시리즈 전체 계획은 Process Essential Curriculum에서 확인할 수 있습니다.
특정 기법을 깊게 파기 전에, 먼저 분야의 지도를 그리는 일이 왜 중요할까요? 소프트웨어 공학은 코딩이라는 한 점이 아니라, 요구사항을 캐내고(elicitation), 설계로 옮기고, 품질을 검증하고, 일정과 위험을 관리하는 거대한 활동의 묶음입니다. 어느 한 기법(예: TDD, 유스케이스, CI)을 배울 때 “이게 전체에서 어디쯤인가?”를 모르면, 도구는 손에 쥐었지만 지도 없이 숲을 헤매는 것과 같습니다. 그래서 1단계는 의도적으로 survey(개관) 성격을 가집니다. 세부 기법은 2단계 이후에 하나씩 정복하되, 지금은 큰 그림을 머릿속에 박아 둡니다.
길잡이로 삼는 책은 Roger S. Pressman의 Software Engineering: A Practitioner’s Approach입니다. 이 책은 수십 년간 대학과 현업에서 표준 교과서로 쓰인 고전으로, 소프트웨어 공학을 프로세스(process) → 모델링(modeling) → 품질과 관리(quality & management)라는 층위로 나누어 체계적으로 다룹니다. “Practitioner’s Approach”라는 부제처럼, 이론을 위한 이론이 아니라 실무자가 매일 마주치는 활동을 정돈하는 데 초점이 있습니다. 우리는 이 책의 뼈대를 빌려 시리즈 전체의 좌표계를 세웁니다.
이 지도를 다 그리고 나면, 2단계: XP Explained: 변화를 끌어안는 애자일로 내려가 “변화를 적으로 보지 않고 끌어안는” 구체적인 프로세스 철학을 살펴봅니다. 즉 1단계가 대륙 전체의 지도라면, 2단계는 그 안의 한 도시를 확대해 들어가는 셈입니다.
📌 이 글에서 다루는 내용
🔍 핵심 주제
- 소프트웨어 프로세스: 프로세스 모델의 의미와 폭포수·반복·점진 모델 비교
- 요구사항 공학(Requirements Engineering): 도출·분석·명세·검증의 전체 흐름
- 설계와 품질: 설계 원칙과 품질 속성, 그리고 검증·확인(V&V)의 개념
- 프로세스와 프로젝트 관리: 추정·일정·위험 관리의 기본 어휘
- 분야의 지형도: 이후 단계(XP·스토리·유스케이스·CI)가 전체에서 차지하는 위치 파악
분야의 지형도: 전체 활동을 한 장으로
세부로 들어가기 전에 전체 그림부터 봅시다. Pressman은 소프트웨어 공학을 프로세스라는 토대 위에 모델링·관리·품질 활동이 얹히는 구조로 설명합니다. 아래 다이어그램은 이 시리즈가 다룰 영역을 한 장에 담은 것입니다.
flowchart TB
P["소프트웨어 프로세스<br/>(전체를 떠받치는 토대)"]
R["요구사항 공학<br/>도출·분석·명세·검증"]
D["설계와 품질<br/>설계 원칙·품질 속성·V&V"]
M["프로젝트 관리<br/>추정·일정·위험"]
P --> R
R --> D
D --> M
M -. "피드백" .-> R
subgraph FUTURE["이후 단계가 자리잡는 곳"]
XP["2단계: XP<br/>(프로세스 철학)"]
ST["스토리<br/>(요구사항 표현)"]
UC["유스케이스<br/>(요구사항 분석)"]
CI["CI<br/>(품질·통합 자동화)"]
end
P -.-> XP
R -.-> ST
R -.-> UC
D -.-> CI
이 지도에서 기억할 핵심은 두 가지입니다. 첫째, 모든 활동은 프로세스라는 토대 위에서 일어난다는 것. 둘째, 화살표는 한 방향이 아니라 피드백 루프를 그린다는 것입니다. 요구사항이 설계를 낳고, 설계가 관리 계획을 낳지만, 그 과정에서 발견된 사실이 다시 요구사항을 수정합니다. 이 “되먹임”이 폭포수와 반복형을 가르는 본질입니다.
이후 단계들의 위치도 미리 짚어 둡니다. 2단계 XP는 프로세스 영역의 한 학파이고, 사용자 스토리와 유스케이스는 요구사항 영역을 표현·분석하는 두 가지 도구이며, CI는 품질 영역을 자동화하는 실천입니다. 이렇게 좌표를 잡아 두면, 앞으로 배울 각 기법이 따로 노는 지식이 아니라 한 지도 위의 지명으로 연결됩니다.
소프트웨어 프로세스: 프로세스 모델이란 무엇인가
왜 중요한가. 같은 요구사항이라도 “어떤 순서와 리듬으로 일할 것인가”에 따라 결과의 위험과 속도가 완전히 달라집니다. 프로세스 모델은 바로 그 “일하는 방식의 설계도”입니다. 모델 없이 일하면 매번 즉흥적으로 순서를 정하게 되고, 무엇이 끝났는지·무엇이 남았는지 가늠하기 어렵습니다.
개념. 프로세스 모델은 소프트웨어를 만드는 활동(요구·설계·구현·테스트·배포)을 언제·어떤 순서로·얼마나 반복하며 수행할지 규정하는 틀입니다. 대표적인 세 모델을 비교해 봅니다.
| 모델 | 핵심 아이디어 | 강점 | 약점 | 잘 맞는 상황 |
|---|---|---|---|---|
| 폭포수(Waterfall) | 단계를 한 번씩 순차 진행 | 단순·문서화 명확 | 변경에 취약, 늦은 피드백 | 요구가 고정·명확할 때 |
| 반복(Iterative) | 전체를 여러 번 돌며 정제 | 위험을 일찍 노출 | 반복 관리 비용 | 요구 이해가 점차 깊어질 때 |
| 점진(Incremental) | 동작하는 일부를 조금씩 더함 | 조기 가치 전달 | 아키텍처 일관성 주의 | 빠른 출시·부분 인도가 필요할 때 |
구체적인 예. 결제 시스템을 만든다고 합시다. 폭포수라면 “모든 요구사항을 다 받고 → 전체를 설계하고 → 구현 → 테스트”를 한 번 거칩니다. 반면 반복형은 “기본 카드 결제만 먼저 한 바퀴 돌려 동작시키고, 다음 반복에서 환불·할부를 더하며 매번 요구·설계·테스트를 재검토”합니다. 점진형은 거기에 더해 매 반복의 산출물을 실제로 인도 가능한 조각으로 만들어 사용자에게 일찍 내보냅니다. 현대 애자일(2단계 XP 포함)은 본질적으로 반복+점진의 결합입니다.
요구사항 공학: 도출·분석·명세·검증의 흐름
왜 중요한가. 소프트웨어 실패의 가장 큰 원인은 “코드를 잘못 짜서”가 아니라 “틀린 것을 만들어서“인 경우가 많습니다. 요구사항 공학은 만들기 전에 “무엇을 만들 것인가”를 제대로 합의하는 활동이며, 여기서 생긴 오류는 뒤로 갈수록 수정 비용이 기하급수로 커집니다.
개념. 요구사항 공학은 보통 네 단계의 흐름으로 정리됩니다.
flowchart LR
E["도출<br/>Elicitation<br/>이해관계자에게서<br/>요구를 캐낸다"] --> A["분석<br/>Analysis<br/>모순·중복·우선순위<br/>를 정리한다"]
A --> S["명세<br/>Specification<br/>합의된 요구를<br/>문서/모델로 기록"]
S --> V["검증<br/>Validation<br/>'올바른 요구인가'<br/>를 확인"]
V -. "변경 발견 시 되돌아감" .-> E
- 도출(Elicitation): 인터뷰·관찰·워크숍으로 이해관계자의 진짜 필요를 끌어냅니다. “고객이 말한 것”과 “고객이 진짜 원하는 것”은 종종 다릅니다.
- 분석(Analysis): 끌어낸 요구들 사이의 충돌·중복을 걸러내고, 기능/비기능 요구를 구분하며 우선순위를 매깁니다.
- 명세(Specification): 합의 결과를 추적 가능한 형태(문서, 모델, 또는 뒤에서 배울 사용자 스토리·유스케이스)로 기록합니다.
- 검증(Validation): 명세된 요구가 실제로 이해관계자가 원하는 것인지 확인합니다. (이는 뒤의 V&V 중 Validation에 해당합니다.)
구체적인 예. “주문 내역을 보고 싶다”는 한 문장은 도출의 출발점일 뿐입니다. 분석을 거치면 “어떤 기간? 어떤 상태의 주문? 정렬 기준은?”이 드러나고, 명세 단계에서 이를 유스케이스나 스토리로 박제합니다. 검증 단계에서 실제 운영팀에게 보여 주면 “환불 진행 중 주문도 보여야 한다”는 누락이 발견되어 다시 도출로 돌아갑니다. 이 되먹임 화살표가 요구사항 공학의 심장입니다. 표현·분석 도구인 사용자 스토리와 유스케이스는 시리즈 후반 단계에서 깊게 다룹니다.
설계와 품질: 설계 원칙·품질 속성·V&V
왜 중요한가. 무엇을 만들지(요구) 정했다면, 이제 “어떻게 구조화할 것인가”가 남습니다. 설계는 요구사항을 구현 가능한 청사진으로 옮기는 다리이고, 품질은 그 다리가 오래 견딜지를 결정합니다.
설계 원칙. Pressman은 좋은 설계의 공통 원칙으로 추상화(abstraction), 모듈화(modularity), 정보 은닉(information hiding), 관심사 분리(separation of concerns), 응집도↑·결합도↓ 등을 듭니다. 핵심 직관은 “변경이 한 곳에 갇히도록 만든다”입니다. 결합이 느슨하고 응집이 높으면, 한 요구가 바뀌어도 흔들리는 코드의 범위가 작아집니다.
품질 속성. 품질은 기능이 “있느냐”가 아니라 “얼마나 잘 작동하느냐”의 문제입니다. 대표적인 비기능 속성을 정리하면 다음과 같습니다.
| 품질 속성 | 묻는 질문 |
|---|---|
| 정확성(Correctness) | 명세대로 정확히 동작하는가 |
| 신뢰성(Reliability) | 주어진 조건에서 꾸준히 동작하는가 |
| 성능(Performance) | 충분히 빠르고 자원을 아끼는가 |
| 유지보수성(Maintainability) | 고치고 확장하기 쉬운가 |
| 보안성(Security) | 위협에 견디는가 |
| 사용성(Usability) | 사용자가 쉽게 쓰는가 |
검증과 확인(V&V). 품질을 말할 때 빠지지 않는 짝이 Verification과 Validation입니다. 한 줄로 구분하면 이렇습니다.
Verification (검증): "Are we building the product right?"
→ 명세대로 올바르게 만들었는가 (산출물 ↔ 명세)
Validation (확인): "Are we building the right product?"
→ 애초에 올바른 것을 만들었는가 (산출물 ↔ 사용자 요구)
구체적인 예. 코드 리뷰·단위 테스트·정적 분석은 주로 Verification입니다. “명세에 적힌 대로 동작하는가”를 봅니다. 반면 사용자 시연·베타 테스트·인수 테스트는 Validation입니다. “이게 진짜 고객이 원한 것인가”를 봅니다. 둘 다 통과해야 품질이 보장됩니다. 명세대로 완벽히 만들었지만(Verification 통과) 애초에 틀린 것을 명세했다면(Validation 실패) 제품은 실패합니다. 이 V&V를 자동화·상시화하는 실천이 시리즈 뒤에서 다룰 CI(Continuous Integration)입니다.
프로세스와 프로젝트 관리: 추정·일정·위험의 어휘
왜 중요한가. 기술이 완벽해도 일정이 무너지거나 위험을 놓치면 프로젝트는 실패합니다. 관리는 “언제·얼마의 자원으로 끝낼 수 있는가, 무엇이 우리를 무너뜨릴 수 있는가”를 다루는 영역입니다. 실무 대화에 끼려면 최소한의 어휘가 필요합니다.
기본 어휘.
- 추정(Estimation): 규모(예: 기능점수, 스토리 포인트)와 노력(인-월, person-month), 비용을 가늠합니다. 추정은 예언이 아니라 불확실성을 명시한 추측임을 잊지 않는 것이 중요합니다.
- 일정(Scheduling): 작업을 분해(WBS)하고 의존성을 따져 순서를 잡습니다. 임계 경로(critical path)와 마일스톤(milestone)이 핵심 개념입니다.
- 위험 관리(Risk Management): 위험을 식별 → 분석(발생 확률 × 영향) → 우선순위 → 완화 계획의 순서로 다룹니다. “일어날지도 모르는 나쁜 일”을 미리 적어 두는 것만으로도 절반은 관리됩니다.
구체적인 예. “3개월 안에 출시”라는 일정이 있다면, 먼저 기능을 작업 단위로 쪼개 각 단위에 노력을 추정하고(추정), 의존성을 따져 임계 경로를 찾고(일정), “결제 PG사 API 문서가 부실해 연동이 늦어질 수 있음 — 확률 중·영향 상 → 1주차에 PoC로 검증”처럼 위험을 표로 관리합니다(위험 관리). 애자일(2단계 XP)은 이 관리를 짧은 반복과 지속적 추정 보정으로 녹여내는 방식이라는 점을, 지금은 좌표만 잡아 둡니다.
마무리
1단계에서 우리는 세부 기법 대신 분야 전체의 지도를 그렸습니다. 핵심을 다시 모으면 이렇습니다. (1) 모든 활동은 프로세스라는 토대 위에서 일어나고, 폭포수·반복·점진은 그 토대의 서로 다른 리듬이다. (2) 요구사항 공학은 도출·분석·명세·검증의 되먹임 루프로 “올바른 것”을 합의한다. (3) 설계와 품질은 요구를 견고한 구조로 옮기며, V&V로 “올바르게 / 올바른 것을” 만들었는지 점검한다. (4) 프로젝트 관리는 추정·일정·위험의 어휘로 이 모든 것이 제때 끝나도록 지킨다. 그리고 앞으로 배울 XP·스토리·유스케이스·CI가 이 지도 위 어디에 놓이는지도 미리 표시해 두었습니다.
이제 지도를 펼쳐 두었으니, 그 위의 한 학파를 확대해 볼 차례입니다. 다음 단계에서는 변화를 비용이 아니라 자연스러운 현실로 받아들이는 프로세스 철학, XP(eXtreme Programming)로 내려갑니다. 폭포수가 변화를 억누르려 했다면, XP는 짧은 반복과 피드백으로 변화를 끌어안습니다.
다음 학습
- Process Essential Curriculum — 시리즈 전체 로드맵과 진행 현황
- 2단계 → XP Explained: 변화를 끌어안는 애자일 — 프로세스 영역을 확대해, 변화를 환영하는 애자일 철학을 깊게 다룹니다