29장: 통합

29장: 통합

• 통합(integration)은 분리된 컴포넌트를 하나의 시스템으로 결합하는 활동임.
• 구현 순서와 통합 순서는 서로 영향을 준다. 아직 만들어지지 않은 구성 요소는 통합할 수 없으므로, 통합 전략은 처음부터 계획해야 함.

29.1 통합 접근법의 중요성

통합 순서가 중요한 이유

잘못된 순서로 통합하면 시스템이 구현 중에 무너질 수 있음

• 완성됐을 때는 문제없이 동작할 구조라도, 구현 과정의 각 단계에서 버틸 수 있는 순서로 만들어야 함.
• 소프트웨어도 잘못된 순서로 구현·통합하면 코드 작성, 테스트, 디버깅이 어려워지고, 결함 수와 복잡도가 감당하기 어렵게 보이며 진척도 보이지 않게 됨.

통합은 독립적인 활동임

• 통합은 개발자 테스트 뒤에 시스템 테스트와 함께 이뤄지므로 단순 테스트 활동으로 여겨지기 쉬움.
• 하지만 구현 순서와 통합 순서를 결정하고 결함을 통제해야 하므로, 별도로 계획하고 관리할 활동임.

신중한 통합의 효과

개발 효율과 품질 향상

• 결함 진단이 쉬워지고 결함과 보조 코드(scaffolding)가 줄어듦.
• 첫 동작 제품을 더 빨리 만들고, 전체 개발 일정·코드 품질·문서화 부담을 개선함.

프로젝트 운영 개선

• 고객과의 관계, 팀 사기, 프로젝트 완료 가능성을 높임.
• 일정 예측과 상태 보고가 더 신뢰할 수 있게 됨.

나머지 나열된 장점은 번역본 참고

29.2 단계적 통합과 점진적 통합

단계적 통합(Big Bang)

• 각 클래스를 개별적으로 구현·테스트한 뒤, 마지막에 전체를 한꺼번에 합치는 방식임.
• 통합 시점에 수많은 인터페이스·상호작용 문제가 동시에 나타나므로 원인을 찾기 어려움.
• 아주 작은 프로그램이 아니라면 통합이 늦고, 디버깅이 공황 상태로 변하기 쉬움.

점진적 통합

• 작동하는 작은 골격을 먼저 만들고, 클래스나 작은 컴포넌트를 하나씩 추가한 뒤 매번 결합 결과를 테스트함.
• 새 결함이 생기면 방금 추가한 구성 요소와 기존 시스템의 접점이 우선 의심 대상이므로 진단 범위가 작아짐.
• 점진적 통합은 전체 개발 기간을 늘리는 중복 작업이 아니라, 통합 문제를 일찍 나누어 처리하는 방식임.

책에서 제시하는 점진적 통합의 이점

다음은 저자가 단계적 통합과 비교해 제시한 효과이며, 프로젝트 특성에 따라 정도는 달라질 수 있음.

• 오류의 위치를 찾기 쉬움.
• 프로젝트 초기에 동작하는 시스템을 볼 수 있어 팀 사기와 진척 확인에 도움이 됨.
• 고객에게도 진행 상황을 더 자주 보여 줄 수 있음.
• 각 단위를 시스템 안에서 더 자주 테스트하게 됨.
• 통합을 미리 계획하면 설계와 구현 일부를 병렬로 진행해 일정을 단축할 수 있음.

29.3 점진적 통합 전략

• 단일 전략이 모든 프로젝트에 최선은 아님. 위험, 구조, 사용자 피드백, 필요한 보조 코드의 양을 기준으로 조합함.

Top-down 통합

하향식 통합

• 애플리케이션 제어 흐름이나 UI처럼 계층 상단부터 통합하고, 아직 없는 하위 요소는 stub으로 대체함.

장점

• 시스템의 제어 흐름과 상위 수준의 개념 설계 문제를 일찍 검증할 수 있음.
• UI가 상위 계층에 있다면 부분적으로 동작하는 화면을 초기에 보여 주고, 사용자와 팀의 피드백을 받을 수 있음.
• 하위 수준의 상세 설계가 모두 끝나기 전에도 상위 클래스를 구현·통합하기 시작할 수 있음.

단점

• 까다로운 시스템 인터페이스와 성능 문제를 마지막에 발견할 수 있음. 하위 문제는 상위 계층까지 영향을 전파해 앞선 통합 작업을 무효화할 수 있음.
• 미구현 하위 요소를 대신할 stub이 많이 필요하며, 이 테스트용 코드의 결함이 새 문제를 만들 수 있음.
• 계층의 최상단이 뚜렷하지 않은 대화형 시스템에는 적용하기 어려움.

현실적인 적용

• 순수하게 위에서 아래로 한 계층씩 진행하기보다, 기능별 세로 조각(vertical slice)을 완성하며 내려가는 혼합 방식이 현실적임.

Bottom-up 통합

• 공통 유틸리티와 시스템 인터페이스 같은 하위 계층부터 통합하고, 상위 호출부는 test driver로 대체함.

장점

• 새로 통합한 클래스가 결함 원인일 가능성이 높아 결함 위치를 좁히기 쉬움.
• 프로젝트 초기에 통합을 시작할 수 있고, 까다로운 시스템 인터페이스를 일찍 검증할 수 있음.

단점

• 주요 상위 인터페이스와 개념 설계의 문제를 마지막에 발견할 수 있어, 이미 만든 하위 구현을 버려야 할 수 있음.
• 통합을 시작하기 전에 시스템 전체의 상위 설계를 충분히 끝내야 함. 그렇지 않으면 하위 구현의 가정이 상위 설계를 끌고 가 정보 은닉과 객체지향 설계 원칙을 해칠 수 있음.

현실적인 적용

• 순수한 Bottom-up 방식도 드물며, 하위에서 위로 기능 조각을 완성하는 방식으로 적용하면 기능 중심 통합과 경계가 흐려짐.

Sandwich 통합

• Sandwich 통합은 상위 비즈니스 객체와 널리 쓰이는 하위 요소를 먼저 통합하고 중간 계층을 나중에 연결함.
• 순수한 Top-down·Bottom-up의 경직성을 피하고, 문제 가능성이 높은 요소를 먼저 검증하며 보조 코드를 줄이는 실용적 방식임.

위험 중심 통합

• 위험 중심 통합은 기술적으로 불확실하거나 성능 목표가 높고 외부 의존성이 큰 요소를 먼저 통합함.
• 상위 인터페이스와 하위 시스템 인터페이스는 흔히 위험도가 높고, 중간 계층에서도 이해가 부족한 알고리즘이나 높은 성능 목표가 있으면 먼저 검증함.
• 나머지 비교적 쉬운 부분은 나중에 통합함. 실제 프로젝트에서는 Sandwich 통합과 비슷한 순서가 나올 수 있지만, 선택 기준은 계층 위치가 아니라 위험도임.

기능 중심 통합

• 하나의 식별 가능한 기능을 이루는 클래스 묶음을 함께 통합함. 기능 내부에서는 작은 단위로 먼저 통합한 뒤, 기능들을 다시 점진적으로 통합할 수 있음.
• 각 기능이 비교적 독립적이면 보조 코드가 거의 필요하지 않고, 새 기능이 통합될 때마다 사용자가 확인할 수 있는 동작이 늘어남.
• 고객 평가를 일찍 받고, 필요하면 기능 수를 줄인 제품을 먼저 제공할 수 있으며, 객체지향 설계의 객체 구조와도 잘 맞음.

T자형 통합

• T자형 통합은 시스템을 끝까지 관통하는 깊은 세로 조각을 먼저 구현해 아키텍처 가정을 검증한 뒤, 시스템의 폭을 넓혀 감.
• 먼저 선택하는 세로 조각은 시스템 전체를 통과하고 주요 설계 가정의 문제를 드러낼 수 있어야 함.
• 이후 메뉴 시스템 같은 시스템의 넓은 골격을 만들며 확장함. 위험 중심·기능 중심 접근과 함께 사용할 수 있음.

29.4 일일 빌드와 스모크 테스트

일일 빌드와 스모크 테스트 운영

• 일일 빌드는 팀의 코드가 짧은 주기로 다시 동기화되게 하는 기준점임.
• 좋은 빌드는 모든 구성 요소가 컴파일·링크되고, 실행을 막거나 위험하게 만드는 심각한 결함 없이 스모크 테스트를 통과한 빌드임.

매일 빌드함

• 일일 빌드는 팀 코드가 하루 안에 다시 맞춰지게 해 개발자가 장기간 서로 다른 상태로 작업하지 않게 함.

깨진 빌드를 확인하고 복구함

• 빌드가 사용 불가능하면 깨진 빌드로 간주하고 복구를 최우선으로 처리함.
• 사소한 결함까지 모두 막아 개발을 멈추게 하지 않으면서도, 실행과 안전을 막는 심각한 결함은 허용하지 않는 기준이 필요함.

매일 스모크 테스트함

• 스모크 테스트는 모든 테스트를 대신하지 않지만, 시스템을 처음부터 끝까지 빠르게 지나가며 큰 통합 문제를 발견해야 함.
• 통과한 빌드는 더 깊은 테스트를 진행할 수 있을 만큼 안정적이라는 최소한의 신호가 됨.

스모크 테스트를 최신 상태로 유지함

• 제품이 성장하면 스모크 테스트도 범위와 깊이를 함께 늘림.
• 갱신하지 않으면 일부 테스트만 통과한 결과로 품질을 과신하게 됨.

일일 빌드와 스모크 테스트를 자동화함

• 반복적인 빌드·테스트 작업을 자동화해 빠뜨리지 않고 지속적으로 실행함.

빌드 담당 그룹을 둠

• 빌드 관리와 스모크 테스트 갱신은 명시적인 책임이 필요하며, 큰 프로젝트에서는 전담 인력이 필요할 수 있음.

의미 있는 단위가 될 때 변경을 추가함

• 개발자는 일관된 상태의 코드 묶음이 되었을 때 빌드에 통합함.

변경을 너무 오래 쌓아 두지 않음

• 며칠 이상 통합하지 못할 만큼 변경이 커지면 해당 작업의 통합 위험이 커짐.
• 큰 기능도 여러 번의 통합 가능한 작은 작업으로 나누는 비용을 감수함.

통합 전에 개발자가 스모크 테스트함

• 빌드에 영향을 주기 전 개인 빌드나 테스트 담당자와의 검증으로 변경 코드가 스모크 테스트를 통과하는지 확인함.

빌드에 넣을 코드를 위한 대기 영역을 둠

• 개발자가 준비됐다고 판단한 코드를 먼저 대기 영역에서 빌드·검증하고, 통과한 변경만 기준 소스에 반영함.
• 소·중규모 프로젝트에서는 버전 관리 시스템에서 마지막으로 정상 확인된 빌드 시점의 소스를 가져오는 방식으로 같은 목적을 달성할 수 있음.

빌드를 깨뜨리는 일에 책임을 부여함

• 깨진 빌드는 예외여야 하며, 원인을 만든 개발자는 다른 작업보다 복구를 우선함. (벌칙)
• 가벼운 규칙이나 관례로도 빌드 건강이 팀의 우선순위라는 점을 분명히 할 수 있음.

아침에 빌드를 배포함

• 밤에 빌드·스모크 테스트를 마치고 아침에 배포하면, 테스터가 당일 새 빌드를 검증하고 문제가 생겨도 개발자와 빠르게 협업할 수 있음.

일정 압박 속에서도 빌드와 스모크 테스트를 유지함

• 압박이 클수록 검토와 테스트를 생략해 코드가 더 빨리 불안정해지기 쉬움.
• 일일 빌드는 이때 필요한 규율을 강제해 통합 문제의 누적을 막음.

큰 프로젝트도 일일 빌드를 적용할 수 있음

• 저자는 “프로젝트가 너무 커서 매일 빌드할 수 없다”는 반론을 부정함.
• 수천만 줄 규모의 Windows 2000도 매일 빌드한 사례를 들어, 프로젝트가 클수록 일일 빌드와 점진적 통합이 오히려 더 중요하다고 설명함.

지속적 통합

• 오늘날 CI는 일일 빌드를 더 자주 자동 실행할 수 있게 함.
• 저자는 대부분의 중·대규모 프로젝트에서는 모든 변경을 즉시 통합하기보다, 하루 단위로 다시 동기화해도 충분하다고 봄.