[SW Engineering] 03. 소프트웨어 프로세스(The Software Process)

소프트웨어 개발은 단순히 코드를 작성하는 행위가 아닙니다. 거대한 건물을 지을 때 설계도와 공사 순서가 필요하듯, 소프트웨어 역시 체계적인 활동의 집합이 필요합니다.

이번 포스팅에서는 소프트웨어 공학의 핵심인 '소프트웨어 프로세스(Software Processes)'를 정리합니다. 고전적인 폭포수 모델부터 최신 트렌드인 LLM(거대언어모델)을 활용한 개발 방식까지, 개발자라면 꼭 알아야 할 개발의 뼈대를 잡아봅시다.

1. 소프트웨어 프로세스란? (The Software Process)

소프트웨어 프로세스는 소프트웨어 시스템을 개발하기 위해 요구되는 구조화된 활동들의 집합입니다. 모든 프로세스는 다음 4가지 핵심 활동을 포함합니다

1. 명세 (Specification): 시스템이 무엇을 해야 하는지 정의합니다 (요구사항)
2. 설계 및 구현 (Design and implementation): 시스템의 구조를 정의하고 실제로 개발합니다
3. 검증 (Validation): 고객이 원하는 대로 작동하는지 확인합니다
4. 진화 (Evolution): 고객의 요구 변화에 따라 시스템을 변경합니다

계획 주도(Plan-driven) vs 애자일(Agile)

• 계획 주도 프로세스: 모든 활동을 미리 계획하고, 그 계획에 따라 진행 상황을 측정합니다
• 애자일 프로세스: 계획은 점진적으로 수립되며, 변화하는 고객 요구사항을 반영하기 쉽습니다
• 참고: 실무에서는 대부분 이 두 가지 요소를 혼합하여 사용합니다

---

2. 소프트웨어 프로세스 모델 (Process Models)

1) 폭포수 모델 (The Waterfall Model)

가장 고전적인 계획 주도형 모델입니다. 물이 위에서 아래로 떨어지듯, 각 단계가 순차적으로 진행됩니다.

• 특징: 각 단계(명세, 설계, 구현, 테스트 등)가 완전히 끝나야 다음 단계로 넘어갑니다. 각 단계의 결과물(문서)이 다음 단계의 입력이 됩니다
• 문제점: 프로젝트를 엄격하게 구분하므로, 진행 도중 고객의 요구사항 변화에 대응하기 어렵습니다
• 적합한 경우: 요구사항이 명확하고 변화가 적은 대규모 시스템 엔지니어링 프로젝트에 적합합니다

2) 점진적 개발 (Incremental Development)

명세, 개발, 검증 단계를 명확히 나누지 않고 서로 맞물려(interleaved) 진행됩니다

• 장점:
  • 요구사항 변경 비용이 적습니다
  • 고객 피드백을 받기 쉽고, 소프트웨어를 더 빨리 인도할 수 있습니다
• 문제점:
  • 진행 과정이 보이지 않습니다 (Process is not visible): 모든 버전에 대해 문서를 남기기 비효율적이므로 관리자가 진행 상황을 파악하기 어렵습니다
  • 시스템 구조의 노후화: 새로운 기능을 계속 추가하다 보면 구조가 엉망이 되기 쉽습니다(Refactoring 비용 발생)

3) 통합 및 구성 (Integration and Configuration)

밑바닥부터 개발하는 것이 아니라, 기존의 재사용 가능한 컴포넌트나 시스템(COTS, Commercial-off-the-shelf)을 조립하여 개발하는 방식입니다

• 구성 요소: 독립형 애플리케이션, 객체 패키지(예: PyGame), 웹 서비스, 클라우드 서비스(AWS) 등이 포함됩니다
• 장점: 개발 비용과 리스크가 줄어들고, 배포가 빠릅니다.
• 단점: 사용자의 실제 요구사항과 타협해야 할 수 있으며, 재사용 시스템의 진화에 대한 통제권을 잃을 수 있습니다

---

3. 프로세스 활동 상세 (Process Activities)

프로세스 안에서 구체적으로 어떤 일이 일어나는지 살펴봅시다.

1) 소프트웨어 명세 (Specification)

시스템이 제공해야 할 서비스와 제약 조건을 확립하는 과정입니다

• 요구사항 도출 및 분석 (Elicitation and analysis)
• 요구사항 명세 (Specification - 상세 정의)
• 요구사항 검증 (Validation)

2) 설계 및 구현 (Design and Implementation)

명세를 실행 가능한 프로그램으로 변환하는 과정입니다

• 설계 활동: 아키텍처 설계, 데이터베이스 설계, 인터페이스 설계, 컴포넌트 선택 및 설계
• 구현: 프로그래밍은 개인적인 활동이지만, 디버깅(오류 수정)을 포함합니다

3) 소프트웨어 검증 (Validation)

시스템이 명세를 준수하고(Verification), 고객의 기대를 충족하는지(Validation) 확인합니다

• Verification (검증): "제품을 올바르게 만들고 있는가?" (Is it correctly implemented?)
• Validation (확인): "올바른 제품을 만들고 있는가?" (Does it satisfy customers?)
• 테스트 단계: 컴포넌트 테스트 → 시스템 테스트 → 인수 테스트(사용자 테스트)

여기서 Verification과 Validation을 구분해야 합니다. 이를 V & V라고 합니다.

Verification이란 제품이 요구 사항 명세(Requirement)대로 작동하는지 검증하는 것이고 Validation이란 사용자 기대를 만족하는지 검증하는 것입니다. 이때 Verification을 만족한다고 해서 반드시 사용자 기대에 충족하는 것은 아닙니다. 이는 실제 현업에서도 중요한 내용인 만큼 구체적인 예시를 들어 살표볼까요?

🎮 예시 1: 라스트 오브 어스 파트 2 (The Last of Us Part II)

이 게임은 기술적으로는 완벽에 가까웠습니다. 게임을 좀 안다 하시는 분들은 알만한 유명한 사건이기도 합니다.

• Verification (성공): 그래픽은 실사처럼 뛰어났고, 로딩 속도나 버그, 전투 시스템 등 기술적인 완성도는 매우 높았습니다. 즉, 개발팀은 명세서대로 '완벽하게 구현'해냈습니다.
• Validation (실패/논란): 하지만 출시 직후 수많은 팬들에게 엄청난 비난을 받았습니다. 전작의 주인공에 대한 스토리 처리가 팬들이 '기대했던(Want)' 방향과 정반대였기 때문입니다.
• 결론: "버그 없이 잘 돌아가지만(Verification O), 내가 원하던 게임은 아냐(Validation X)."

반대의 경우도 있습니다. 다음 예시를 볼까요?

🎮 예시 2: 사이버펑크 2077 (Cyberpunk 2077 - 초기 출시 버전)

• Verification (실패): 출시 초기, 수많은 버그와 튕김 현상(Crash)으로 인해 게임 진행 자체가 불가능한 경우가 많았습니다. 명세된 기능들이 제대로 작동하지 않은 것이죠.
• Validation (실패): 마케팅에서 약속했던 자유도 높은 오픈월드와도 거리가 멀어, 유저들의 기대치도 충족시키지 못했습니다.

두 게임의 예시 대신 일상생활의 비유를 통해 살펴볼까요?

요약: 짜장면 배달의 비유

• 상황: 여러분이 중국집에 "짜장면 하나, 단무지 많이"를 주문했습니다.
• Verification (검증): 주방장이 레시피를 완벽하게 지켜서 면을 삶고 춘장을 볶았습니다. 요리에 아무런 화학적/물리적 결함이 없습니다.
• Validation (확인): 배달이 왔는데 짬뽕이 왔습니다. 혹은 짜장면은 맞는데 오이가 잔뜩 올라가 있습니다. (손님은 오이 알러지가 있음)

주방장(개발자) 입장: "레시피대로 완벽하게(Right) 만들었어!" (Verification OK)

손님(사용자) 입장: "근데 내가 시킨 건 이게 아니야(Right Product)!" (Validation Fail)

여기서 핵심적인 내용은 아무리 코드를 잘 짜고 버그가 없더라도(Verification), 고객이 진정으로 원하는 것(Validation)을 놓치면 그 프로젝트는 실패한 프로젝트라는 것입니다. 따라서 소프트웨어 검증 단계가 매우 중요하며 이 과정에서 고객 요구사항을 끊임없이 분석하며 검증해야 합니다.

4) 소프트웨어 진화 (Evolution)

소프트웨어는 본질적으로 유연하며, 비즈니스 환경 변화에 따라 반드시 변경되어야 합니다. 최근에는 개발(Dev)과 운영(Ops)의 경계가 모호해지는 DevOps가 대두되고 있습니다

 

4. 변화에 대처하기 (Coping with Change)

대규모 프로젝트에서 변화는 필연적이며, 이는 재작업(Rework) 비용을 발생시킵니다. 이를 줄이기 위한 두 가지 접근법이 있습니다.

1. 변화 예측 (Change anticipation): 프로토타입을 만들어 미리 변경을 예측합니다
2. 변화 내성 (Change tolerance): 점진적 개발을 통해 변경을 쉽게 수용하도록 프로세스를 설계합니다

1) 프로토타이핑 (Prototyping)

요구사항을 확인하고 디자인 옵션을 탐색하기 위해 초기 버전을 빠르게 개발하는 것입니다.

• 주의사항: 신뢰성, 보안성 같은 비기능 요구사항은 무시될 수 있으며, 엉성한 코드가 그대로 최종 시스템에 남지 않도록 주의해야 합니다

2) 점진적 인도 (Incremental Delivery)

시스템을 한 번에 배포하는 대신, 기능별로 나누어(Increment) 배포합니다.

• 특징: 가장 우선순위가 높은 요구사항을 먼저 개발하고 배포합니다.
• 장점: 고객이 가치를 빨리 얻을 수 있고, 초기 인크리먼트가 프로토타입 역할을 하여 요구사항을 명확히 할 수 있습니다.
• 단점: 공통 기능을 식별하기 어렵고, 계약 모델과 충돌할 수 있습니다

---

5. LLM을 활용한 소프트웨어 개발 (SW Development with LLM)

최근에는 Copilot, Claude, Gemini와 같은 LLM을 활용해 코드를 생성하고 개발 활동을 보조받는 것이 새로운 트렌드입니다

1) 장점과 이슈

• 장점: '어떻게(How)'보다 '무엇을(What)' 할지에 집중할 수 있게 해주며, 보일러 플레이트 코드 작성 시간을 획기적으로 줄여줍니다. 이는 넓은 의미의 '재사용(Reuse)'으로 볼 수 있습니다
• 이슈: LLM은 확률에 기반해 텍스트를 생성할 뿐 실제로 '생각'하는 것이 아니므로, 결과물이 부정확할 가능성을 항상 염두에 두어야 합니다. 또한 민감한 데이터를 프롬프트에 입력하면 보안 문제가 발생할 수 있습니다

2) 활용 접근법

1. 예제로부터 학습 (Learning from Examples): 요구사항에 맞는 예제를 요청하고, 이를 보고 직접 작성합니다
2. 설명하고 검증하기 (Describe and Validate): 코드를 생성해달라고 요청한 뒤, 반드시 검증하여 사용합니다

LLM은 단순히 구현뿐만 아니라 요구사항 공학, 아키텍처 설계, 테스트 등 모든 활동에 활용될 수 있습니다. 하지만 이를 자신의 책임을 회피하는 용도로 사용해서는 안 됩니다

 

정리

소프트웨어 프로세스는 명세, 설계/구현, 검증, 진화의 반복입니다. 특히 검증 과정에서 아무리 코드를 잘 짜고 버그를 0개로 만들어도(Verification), 고객이 진정으로 원하는 것(Validation)을 놓치면 그 프로젝트는 실패합니다.

변화는 피할 수 없으므로 프로토타이핑이나 점진적 개발을 통해 현명하게 대처해야 하며, 최근에는 LLM이라는 강력한 도구를 검증 기반으로 활용하는 능력이 요구됩니다.