개발된 단위 모듈 소프트웨어들을 통합 계획에 따라 통합하여 완전한 소프트웨어 구조를 개발하는 활동
통합 방식 3종
| 방식 | 절차 | 특징 |
|---|---|---|
| 빅뱅 (Big Bang) | 모듈을 한꺼번에 통합 후 테스트 | 오류 발생 시 원인 파악 어려움 |
| 하향식 (Top-Down) | 가장 상위 모듈 → 하위 모듈로 점진적 통합 | 하위 모듈 대신 스텁(Stub) 사용 |
| 상향식 (Bottom-Up) | 하위 모듈부터 테스트 후 상위로 통합 | 상위 모듈 대신 드라이버(Driver) 사용 |
지속적 통합 (Continuous Integration, CI)
SW 통합 오류를 개발 초기부터 예방하는 것
기존 방법의 문제점
소프트웨어 구현 후반부에 빌드 오류, 정적분석 위반, 복잡도 위반 등을 한꺼번에 확인하면:
- 수정 노력이 기하급수적으로 증가
- 재개발 수준에 도달할 가능성
CI 적용 효과
- SW 구현 시작부터 작은 단위로 지속적 통합 → 작은 크기의 문제를 조기에 해결
- 도구가 자동 검사·보고 → 품질과 안정성 조기 확보
- SW 구현 종료 시점에 결함 그래프가 완만한 감소를 보임
- 회귀 테스트 자동화 연계 — 커밋 시마다 또는 일·주 단위로 이전 TC를 재실행하여 회귀 결함 조기 검출
- TDD와 철학 공유 — “문제가 작을 때 빠르게 해결, 지속 검증” 목적을 TDD는 작성 단위, CI는 통합 단위에서 실현. TDD로 축적된 단위 테스트가 CI Continuous Testing 단계의 기반이 된다.
CI 환경 구성 예시
Jenkins 기반 CI
오픈소스 CI 도구. SVN/Git에서 Checkout → 빌드 관리 / 순환 복잡도 / 중복 코드 / 정적 분석 / 테스트 / 시맨틱 분석 → 빌드/게시.
대표 측정 지표:
- MISRA-C 위반사항 수
- 순환 복잡도 위반
- 커버리지 불만족 비율
- 함수, 모듈 크기 위반율
→ SW 구현 시작 ~ 종료에 걸쳐 결함이 점진적으로 감소하는 그래프로 시각화.
지속적 배포 (Continuous Deployment, CD)
빌드된 실행 파일(Artifact)을 언제나 즉시 배포 가능한 상태로 유지하는 자동화 파이프라인.
CD 파이프라인 4단계
CD는 테스트 → 배포 → 운영 → 모니터링 4단계를 자동화한다. CI가 Plan / Code / Build까지를 자동화한다면, CD는 Release / Deploy / Operate / Monitor를 자동화하여 최종 사용자까지의 전달 주기를 단축한다.
CI/CD 도구 생태계
| 단계 | 대표 도구 |
|---|---|
| Plan / Code / Build (CI) | Git · GitHub · JIRA · Eclipse · Maven · Apache Ant · Gradle |
| Continuous Testing | Google Test · JUnit |
| Release / Deploy (CD) | Jenkins · Bamboo |
| Infrastructure as Code (IaC) | Ansible · Terraform · Puppet · CHEF · Saltstack |
| Monitor | Nagios · Splunk · Sensu · New Relic · Elasticsearch (ELK) |
Jenkins 파이프라인 동작 예시
- 개발자가 코드를 Git에 Push.
- Jenkins가 Git을 감지하여 빌드 요청.
- Jenkins가 테스트 컨테이너(Docker)를 띄워 테스트 수행.
- 테스트 통과 시 웹서버 컨테이너(Docker)에 배포.
ELK 기반 운영 모니터링
운영 로그는 log file → BEATS(Filebeat 수집) → Kafka(buffering) → Logstash(processing) → Elasticsearch(storage) → Kibana(visualize) 파이프라인으로 흐른다.
CI/CD 파이프라인 보안 위협
CI/CD 파이프라인 자체가 공격 대상. 2023 CISA 권고 — “How Malicious Cyber Actors Threaten the CI/CD Pipeline”.
Continuous Integration 단계 위협
| 경로 | 위협 |
|---|---|
| Developers → Source Code Repository | 환경 변수 덤프로 자격증명 탈취 · 탈취한 키/토큰으로 Git 저장소 무단 접근 |
| Source Code Repository → Build/Test | CI/CD 설정 또는 애플리케이션 소스 변조 · 소스 코드나 IaC 설정에 악성 코드 주입 |
Continuous Delivery 단계 위협
| 경로 | 위협 |
|---|---|
| Build/Test → Deploy → Production | 악성 의존성(Bad Dependency) 주입 · CI/CD Runner 이미지·컨테이너 변조 · CI/CD 서버 탈취 · 관리자 권한으로 승인자 추가하여 리뷰 우회 |
클라우드 파이프라인 공격 벡터 (AWS 예시)
AWS CodePipeline · CodeBuild · S3 · ECR 등 클라우드 인프라 자원이 타깃. 파이프라인 구성요소 간 IAM 권한이 광범위할수록 공격 표면 확대.
대응 — DevSecOps 통합
CI/CD 보안 위협은 DevSecOps 접근법으로 완화 — SAST/DAST, Dependency Management, Pre-commit hooks, Secure Pipelines 등을 SDLC 단계별로 통합.
Gate 단계별 정적/동적 테스트 기준 예시
| 대분류 | 항목 | G1 | G2 | G3 | G4 |
|---|---|---|---|---|---|
| 정적 테스트 | MISRA-Rule 체크 | 50% | 80% | 100% | 100% |
| 정적 테스트 | 구문/분기 커버리지 | 100% | 100% | 100% | 100% |
| 동적 테스트 | 메모리 오류 | 50% | 80% | 100% | 100% |
| 동적 테스트 | CPU 부하 분석 | 50% | 80% | 100% | 100% |
A-SPICE SWE.5
A-SPICE 4.0에서 프로세스 이름이 Software Integration and Integration Test → Software Component Verification and Integration Verification으로 변경. 컴포넌트 검증과 통합 검증을 하나의 프로세스로 다룬다.
Test Basis는 SWE.2 Software Architectural Design — 아키텍처 설계가 좌측 베이시스, SWE.5가 우측 검증.
→ 3.1/4.0 BP 상세 비교는 A-SPICE SWE.5 참조.