Software Engineering Overview — 소프트웨어 공학 및 개발론 개요

소프트웨어 개발의 복잡성이 증가하면서, 체계적으로 개발하기 위한 공학적 접근이 필수가 되었다. 소프트웨어 공학은 사용자의 요구사항을 충족시키는 품질 좋은 소프트웨어를 개발하기 위한 학문이다.

소프트웨어 공학의 목표

소프트웨어 개발을 위한 다양한 공학적 기법이 탄생하면서, 세 가지 핵심 목표가 정립되었다:

• 개발 대상의 명확화: 무엇을 만들 것인지 정확히 정의
• 개발 과정의 체계화: 어떻게 만들 것인지 절차와 방법 수립
• 개발 수명주기 지원: 개발부터 유지보수까지 전체 생명주기 관리

최종 목표는 사용자의 요구사항을 충족시키는 품질 좋은 소프트웨어 개발이다.

소프트웨어 공학의 원리

엄격성과 정형성

소프트웨어는 개발자의 경험과 지식에 의존적인 창의적, 공학적 활동의 산출물이다. 소프트웨어 개발은 주어진 시간과 비용에서 명확하게 개발되어야 하는 엄격성이 요구된다.

관심사의 분할

복잡한 문제를 단순한 문제로 분리하여 적용하는 소프트웨어 개발 활동이다.

• 소프트웨어 개발 과정의 분할: 요구사항 분석 → 설계 → 구현 → 테스팅 등의 단계로 분할
• 소프트웨어 테스트 과정의 분할: 단위 테스트 → 통합 테스트 → 시스템 테스트 등으로 분할

모듈화

독립적인 기능을 갖는 프로그램의 조각이다. 높은 응집력(Cohesion)과 낮은 결합력(Coupling)을 갖는 소프트웨어 구조를 설계하는 것이 핵심이다. 이해도를 높이고 변경 영향을 최소화하기 위한 공학적 원리이다.

추상화

세부사항은 감추고 대표적인 속성으로 대상물을 정의하는 공학적 원리이다. 대상물에 대한 직관적인 이해를 높이고 관심사를 잘 표현할 수 있다. 예: 함수 정의, 매크로 함수, 객체, 추상 데이터 타입 등

추상화 방법은 문제를 단순화하기 위해 관련 없는 세부 사항을 제외하고, 단순화된 문제가 해결되면 그 다음 더 낮은 수준의 추상화를 해결하기 위해 제외된 세부 사항을 고려하는 과정을 반복한다.

변경의 예측

소프트웨어 개발과정에서 변경 발생은 피할 수 없는 사건이다. 변경을 대처하기 위한 공학적 방법의 적용이 요구되며, 변경이 발생할 것으로 예상되는 부분을 모듈화 구조로 분리한다.

일반화

다양한 플랫폼, 다양한 환경, 다양한 사용자를 지원하기 위한 원리이다. 하드웨어 성능이나 사양에 의존적이지 않는 소프트웨어 개발을 지향한다.

점진성

단계적이며 순차적으로 소프트웨어를 개발하고자 하는 공학적 원리이다. 작은 단위의 소프트웨어를 반복 개발하면서 전체 시스템을 완성하며, 단계적인 개발과 배포를 통한 사용자 피드백의 수집과 반영이 가능하다.

명세화

소프트웨어 개발 과정 및 대상물에 대한 정보를 체계적으로 기술하는 원리이다. 팀 기반의 개발 활동을 지원하기 위한 정보의 공유를 지원한다.

핵심 원리 요약

여러 원리 중 가장 중요한 개념은 다음과 같다:

• 추상화(Abstraction): 추상화 없이 일반화를 할 수 없다
• 분할(Decomposition) 및 모듈화(Modularity): 모듈화와 추상화 없이 명세화가 불가능하며, 모듈화가 있다면 점진성도 가능하다

소프트웨어 개발 수명 주기(SDLC)

소프트웨어 개발 수명 주기(Software Development Life Cycle, SDLC)란 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다. 소프트웨어 개발자가 전체 프로세스에 참여하지는 않더라도 이러한 소프트웨어 개발 프로세스에 대한 사전 지식을 갖는 것이 매우 중요하다.

1. 요구사항 분석

• 입력값: 고객 제안서 또는 요구사항
• SDLC에서 가장 중요하고 근본적인 단계이다
• 제품 요구사항을 명확하게 정의하고 문서화하며, 고객이나 시장 분석가로부터 승인을 받는다
• 출력값: 소프트웨어 요구사항 명세서(SRS) — 프로젝트 생명 주기 동안 설계하고 개발할 모든 제품들에 대한 요구사항으로 구성

2. 설계

• 입력값: 소프트웨어 요구사항 명세서(SRS)
• 디자인 문서 사양(Design Document Specification, DDS)을 작성한다
• 제품의 모든 아키텍처 모듈을 정의하며, 하위 모듈 및 제3자 간의 통신과 데이터 흐름을 정의
• DDS를 기반으로 고수준 디자인(HLD) / 상세 디자인(DDD)을 작성
• 출력값: DDS, HLD and/or DDD

3. 구현

• 입력값: DDD(Detail Design Document)
• 실제 개발이 시작되고 제품은 DDD를 기반으로 구축
• 디자인이 상세하고 체계적으로 수행된다면, 코드 생성은 큰 어려움 없이 수행될 수 있다
• 개발자들은 프로그래밍 스타일 가이드라인(예: Google C++ styleguide)을 따라야 한다
• 출력값: 프로그램/소프트웨어

4. 테스트

• 입력값: 테스트 수행 전 프로그램 및 테스트 계획 문서
• SRS를 기반으로 테스트를 수행한다
• 제품 결함이 보고되고 추적되며 수정되고 재 테스트되는 유일한 단계인 테스트를 진행
• 결과가 SRS에서 정의된 품질 기준에 도달할 때까지 이를 지속적으로 수행
• 출력값: 테스트 완료된 프로그램

5. 유지 보수

• 입력값: 테스트 완료 된 프로그램
• 시스템이 인수되고 설치된 후 일어나는 모든 활동
• 예방, 완전, 교정, 적응 유지보수로 구분
• 출력값: 새로운 요구 사항

소프트웨어 개발 수명 주기 종류

전통 모델

폭포수 모델(Waterfall Model)

요구사항 분석 → 시스템 설계 → 구현/코딩 → 테스트 → 유지보수 순서로 진행한다.

장점	단점
이해하기 쉬움	변경에 취약
체계적인 문서	늦은 피드백
명확한 관리	고객 참여의 어려움

V형 모델(V-shape Model)

테스팅을 강조한 모델이다. 각 개발 단계에 대응하는 테스트 단계가 존재한다 (요구사항↔인수 테스트, 분석↔시스템 테스트, 설계↔통합 테스트, 구현↔단위 테스트). 높은 품질 보장과 명확한 관리가 장점이나, 유연성 부족과 초기 프로젝트 부적합이 단점이다.

반복 모델(Iterative Model)

전체 프로젝트를 반복(iteration)이라는 작은 단계로 나눈다. 각 반복에서 계획 및 요구사항 정의 → 분석 및 설계 → 구현 → 테스트 → 평가/피드백 과정을 거친다. 초기 피드백 가능, 요구사항 변경에 유연, 위험 감소가 장점이나, 전체 구조 설계의 곤란함과 관리의 복잡성이 단점이다.

나선형 모델(Spiral Model)

목표 정의, 대안 분석, 제한 사항 식별 → 대안 평가, 리스크 식별 및 해결 → 개발 및 검증 → 검토 및 평가, 다음 활동 계획 순환 구조이다. 위험 관리 중심이며 요구사항 변경에 유연하지만, 복잡하고 높은 작업 숙련도를 요구하며 긴 개발 시간 및 높은 비용이 단점이다.

애자일 모델(Agile Model)

• 반복적이고 점진적인 개발
• 고객과의 지속적인 소통
• 변화에 대한 유연한 대응
• 팀 중심의 협업

DevOps

DevOps란?

고객 서비스를 365일 24시간 내내 제공해야 하는 IT 조직에서 도입하고 있는 소프트웨어 시스템의 개발 및 운영 전략이다. 아마존, 구글, 넷플릭스 등이 대표적이다.

회사	배포주기	배포 소요 시간	신뢰성
아마존	23,000 / day	minutes	high
구글	5,500 / day	minutes	high
넷플릭스	500 / day	minutes	high
페이스북	1 / day	hours	high
일반 회사	1 / 9 months	months / quarters	low / medium

DevOps는 소프트웨어 개발자(Developer)와 운영자(Operator) 간의 소통과 협업, 통합을 강조하는 소프트웨어 개발 방법이다. 개발과 운영의 상호 의존성을 명확히 함으로써 제품 혹은 서비스의 신속한 개발을 목표로 한다.

DevOps는 개발(Software Engineering), 운영(Operations), 그리고 품질 보증(QA, Quality Assurance)의 교집합이다.

DevOps의 핵심 원리

• 자동화: 개발 환경에서 나타나는 소프트웨어 동작이 배포 및 운영 환경에서도 동일하게 보장될 수 있도록 한다. 자동화된 환경을 전체 수명주기에 구축한다.
• 반복: 개발과 운영을 순환 구조로 연결함으로써, 유지보수라는 기존 개념보다는 운영 과정에서 모니터링된 요구사항을 시스템에 반영해 개발하는 반복 개발 형식으로 진행한다.
• 자기 서비스: DevOps 조직은 협업 및 자동화 환경 구축을 통해 개발자와 운영자가 서로 방해하지 않고 독립적으로 일할 수 있도록 지원한다.
• 지속적 개선(CI/CD): 사용자의 피드백을 소프트웨어 및 운영 환경을 개선하기 위해 활용한다.
• 협업: 신속하고 신뢰성 있는 소프트웨어의 개발과 배포를 보장하기 위해 개발 팀과 운영 팀 간의 성공적이고 지속적인 협업 능력이 요구된다.
• 지속적 테스트: 개발자는 개발 혹은 수정된 코드에 대해 단위 테스트를 수행하고, 이 코드를 서버에 전달하여 통합 테스트를 수행한다.
• 지속적 통합과 지속적 배포(CI/CD): 다수 팀이 큰 규모의 소프트웨어를 개발할 때, 각 팀은 개발한 결과물은 서버로 전달하고, 서버에서는 전달한 소프트웨어 컴포넌트를 주기적으로 가능하면 매일 통합한다. 통합이 주기적으로 이루어지듯 배포도 문제가 없는 한 지속적으로 이루어진다.

DevOps 프로세스

DevOps 프로세스는 8단계로 구성된다:

1. 계획(Plan): 애플리케이션에 대한 비즈니스 가치와 사용자 요구사항 정의
2. 코딩(Code): 소프트웨어 설계(알고리즘 개발), 소스 코드 작성, 단위 테스트 수행
3. 빌드(Build): 작성된 코드의 통합, 통합 테스트, 제품 형상 구성
4. 테스트(Test): 요구사항 만족도 테스트, 보안 및 취약성 분석, 성능 테스트
5. 릴리즈(Release): 배포 승인, 명세된 형상에 따른 패키징, 애플리케이션 배포
6. 설치(Deploy): 배포된 애플리케이션 사용자 환경에 설치, 인프라 구축
7. 운영 및 모니터링(Operate & Monitor): 인프라 구성요소 성능에 대한 지속적인 모니터링, 사용자 반응 및 경험 추적
8. 피드백 → 다시 계획: 모니터링 결과를 개발팀에 제공하여 새로운 사이클 시작

DevOps의 이점

• 제품 출시 기간 단축: 운영팀의 피드백을 전달받기 위해 많은 시간을 요구하는 처리 과정을 거치지 않고, 즉시 새로운 요구사항으로 합병 가능
• 낮은 위험과 유연한 배포: 개발 환경을 고려한 자동화된 플랫폼상에서 지속적으로 문제의 원인을 분석하고 대처
• 신속한 복구: 코드 생성 과정에서 이상이 발생하거나 작업이 중단될 경우, 자동화된 진단 기능을 통해 문제를 복구
• 고객 만족도 및 시장 적합도 향상: 소프트웨어 기능을 신속 정확하게 배포하고 피드백 받은 버그를 수정함으로써 시스템에 대한 가용성을 높임

DevOps와 기술 부채

기술 부채(Technical Debt)란 시간이 더 오래 걸리는 더 나은 접근 방식을 사용하는 대신 지금 쉬운(제한된) 솔루션을 선택함으로써 발생하는 추가 재작업의 내재된 비용이다.

기술 부채 절감을 위한 DevOps 전략:

• DevOps 자동화 활용
• 마이크로서비스 모델 채택: 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성
• 컨테이너화된 배포