시프트-레프트로 CI/CD 문제 해결하기

InfoWorld
과거 애플리케이션 테스트는 애플리케이션 출시 수 일에서 수 주 전부터 실행되는, 기술적으로 어렵고 시간도 많이 드는 작업이었다. 개발 부서에는 마감에 임박한 시점까지 코딩할 재량이 부여됐고 대부분의 작업을 수작업으로 하는 테스터의 경우 주어진 잠깐의 시간을 활용해야 했다. 결과적으로 많은 애플리케이션이 불충분한 테스트를 거쳤고, 기술 부서는 최종 사용자와 애플리케이션 모니터링 시스템을 거쳐 오는 프로덕션 문제와 결함에 대응할 수밖에 없었다.
 
데브옵스 지속적 통합과 단위 테스트 프레임워크, 테스트 자동화는 이 패러다임을 뒤집었다. 품질 보증을 개발 프로세스의 끝에 수행하는 대신 이제 많은 테스트가 코딩, 통합, 배포 중에 시작되어 완전히 실행된다. 데브옵스와 애자일 부서는 테스트 스크립트를 자동화하며 CI/CD 파이프라인은 코드 통합 또는 전달 단계에서 테스트를 실행해야 한다. 그 결과 개발자는 코드 변경으로 인해 빌드의 작동이 멈추는 경우 알림을 받고 즉각 조치를 취해 보고된 문제에 대처할 수 있다.

테스트를 자동화하고 CI/CD 파이프라인에 테스트 스크립트를 통합하는 것을 시프트-레프트(shift-left) 테스트라고 한다. 이 작업은 개발 단계에서 더 많은 품질 보증 작업을 실행해 릴리즈 타임라인에서 더 조기에 문제를 포착할 수 있다. 테스트 자동화는 배포 빈도를 높이고자 하는 애자일 및 데브옵스 부서가 배포 전에 우선 고려해야 할 사항 중 하나다.

새로운 기능이 도입되면 테스트 스크립트가 새로운 기능을 검증한다. 이 테스트를 자동화해서 빌드 또는 배포 단계에 포함할 수 있다. QA(Quality Assurance) 엔지니어가 릴리즈 프로세스의 끝에 회귀 테스트를 실행하는 대신, 이러한 테스트의 상당 부분을 배포의 일부분으로 실행하고 검증할 수 있다. 즉, 릴리즈 프로세스의 끝에 있던 테스트를 개발 및 코딩 단계의 앞부분으로 옮기는 것(시프트-레프트)이다.
 

품질에 전념하게 된 애자일 부서

시프트-레프트 테스트는 효율성을 높이고 품질을 개선할 뿐만 아니라 애자일 개발 프로세스에서 중대한 문화적 변화도 이끈다.
 
품질 보증과 테스트를 프로덕션으로 코드를 전달하는 과정의 장애물로 인식하는 일부 개발 부서가 있다. 힘든 과정을 거쳐 애자일 제품 소유자를 만족시키고 코드를 완성하고 나면 QA 부서원이 수정해야 할 버그 목록을 만든다. QA에서 발견하는 버그가 많은 경우 수정하느라 릴리즈 타임라인이 지연될 수 있다. 더욱 나쁜 상황은 결함 때문에 로직, 보안, 성능 문제가 발생해 코드의 상당 부분을 리엔지니어링해야 하는 경우다. 이 시나리오에서 개발자와 QA 엔지니어는 같은 애자일 부서 소속일 수 있지만 하나의 부서로 움직이지는 않는다.

시프트-레프트 테스트를 통해 애자일 부서는 품질 책임을 개발자와 테스터, 전체 부서로 확대할 수 있다. 테스트가 CI/CD 파이프라인의 일부로 실행되면 개발자는 관련된 코드 작업을 할 때, 즉 적시에 품질 문제에 대처할 수 있게 된다. CI/CD 파이프라인은 빌드가 잘못될 경우 개발자에게 알림을 보내고 자율적으로 조직되는 개발 부서는 이러한 문제를 즉시 수정해야 한다.

시프트 레프트 테스트는 개발자와 QA 엔지니어에게 테스트의 더 많은 부분을 자동화할 수 있는 기회를 제공한다. 최선은 개발하는 기능에 필요한 테스트의 유형에 따라 자동화를 구현할 사람을 결정하는 것이다. 예를 들어 개발자는 자동화 유닛과 API 테스트를 책임지는 경우가 많지만, QA 자동화 엔지니어는 여러 서비스에 대한 다중 단계 API 호출을 시뮬레이션하는 엔드 투 엔드 사용자 경험 테스트와 트랜잭션 테스트를 개발하는 경우가 많다. 
 

언제 시프트-레프트 테스트를 적용해야 하나

시프트-레프트 테스트는 실행 시간이 짧은 유닛 수준의 원자 테스트에 가장 적합하다. 테스트는 CI/CD 파이프라인에서 자동화되고 개발자가 빌드를 트리거할 때마다 실행되어야 하며, 빌드 프로세스를 늦추지 않도록 신속하게 실행되어야 한다.

엔드 투 엔드 사용자 경험 테스트, 트랜잭션 테스트, 정적 코드 분석, 보안 테스트 같은 더 복잡하고 시간이 많이 걸리는 테스트는 CI/CD 파이프라인 외부에서, 하루 1회 이상의 빈도로 실행되는 편이 더 나은 경우가 많다. 이러한 테스트도 개발자에게 조기에 피드백을 제공하지만 빌드 속도를 늦추거나 병목 지점이 되지 않도록 CI/CD 외부에서 자동화된다.
 
GM 파이낸셜의 IT 서비스 부문 부사장인 토머스 J. 스위트는 시프트-레프트 테스트 전략의 제약에 대해 언급하며 “써드파티 업체 배포를 대상으로 통합 테스트를 수행하는 경우는 시프트 레프트 전략의 예외에 해당한다. 이 경우 해당 업체의 소스 코드에 액세스할 수 없는 경우가 많기 때문이다. 레거시 모놀리식 아키텍처를 사용하는 내부 앱이 있는 경우에도 코드 리뷰와 보안 스캔이 필요한 기본적인 체크인 정책을 실행하는 방법으로 시작할 수 있다. 스캔에 중요한 경고나 실패가 포함되는 경우 체크인이 거부되어야 한다”고 말했다.
 
통합 파트너와 함께 다운스트림 테스트를 위한 한 가지 솔루션은 서비스 가상화를 구현하는 것이다. 이렇게 하면 개발 부서는 다양한 입력에 대한 다운스트림 시스템의 응답을 시뮬레이션할 수 있다. 이 방법은 다운스트림 시스템이 잘 정의된 경우 효과적이다. 마이크로 포커스(Micro Focus), 트라이센티스(Tricentis) 및 기타 업체의 툴을 통해 이 기능을 사용할 수 있다.
 
경험이 풍부한 품질 보증 관리자인 롭 포실루크는 애자일 개발에서 시프트-레프트 테스트를 적극적으로 지지한다. 포실루크는 “준비성을 갖추고 코드의 작은 부분을 테스트할 수 있게 되면 QA는 스프린트 진행 중에 유연함과 초점을 유지할 수 있다. 단, 코드 자체의 목적이 희석될 수 있으므로 과도한 시프트-레프트를 하지 않도록 해야 한다”고 말했다.
 
따라서 부서가 시프트-레프트 테스트를 전적으로 도입한다 해도 릴리즈를 목표로 하는 코드 완료 빌드에 대한 테스트 일정을 잡아야 한다. 이렇게 하면 최종 빌드에서 모든 자동화된 테스트가 수행된다는 점이 보장될 뿐만 아니라, 완전히 기능하는 시스템이 있어야 진행 가능한, 부가적인 테스트도 예약할 수 있게 된다.
 
이러한 테스트 중 하나는 선별된 최종 사용자와 주제 전문가가 검증하고 피드백을 제공하는 사용자 수용 테스트(User Acceptance Testing, UAT)다. 일부 UAT는 개발 중에도 할 수 있지만 기능이 완전히 준비가 되지 않았을 때 테스트를 수행하거나 자주 테스트를 하도록 사람을 유도하는 일은 쉽지 않다.
 

시프트-레프트 테스트 전략을 위한 사전 요건

-    시프트-레프트 테스트는 뜨는 데브옵스 실천 방안이지만 사전 요건이 있고 선행 투자도 필요하다. 다음과 같은 몇몇 기능과 실천 방안은 필수다.

-    동시에 실행되는 여러 빌드 및 테스트를 지원하려면 충분한 테스트 역량과 환경이 필요하다.

-    애자일 부서에는 CI/CD 파이프라인과 작업 스케줄링 툴과 손쉽게 통합되고 기능, 코드 품질, 보안, 성능을 검증할 수 있는 제품 테스트 툴킷이 필요하다.

-    설계자, 정보보안 전문가, QA 리드를 비롯한 조직의 선임 구성원은 기본 수용 기준을 구성하는 테스트 표준과 서비스 수준 목표를 설정해야 한다. 

-    애플리케이션에 사용자 입력이 필요한 경우 테스트 부서에는 충분한 페르소나, 사용 사례, 입력 패턴을 검증하기 위한 충분한 테스트 데이터와 패턴이 필요하다.

-    스프린트 약속 시점 또는 그 전에 QA 테스트 자동화 엔지니어가 포함된 스크럼 부서가 테스트 대상 기능, 구현하는 테스트의 유형, 업데이트할 자동화 프로세스, 테스트를 개발하는 사람에 대한 테스트 전략을 수립해야 한다.

-    데브옵스 부서는 CI/CD 파이프라인 실행 기간을 측정하고 자동화된 테스트 단계가 생산성에 영향을 미치는 경우 이를 알려야 한다. 데브옵스 부서는 장기간 테스트를 실행하기 위해CI/CD 파이프라인 외부의 부가적인 테스트 일정이 필요한 경우가 많다.

-    부서는 자동화된 테스트에 존재하는 간극, 특히 주제 전문가, UAT 또는 파트너와의 테스트가 필요한 검증을 정기적으로 논의해야 한다. 애자일 부서가 자동화를 통해 이러한 간극을 해소하지 못하는 경우 위험을 낮추고 테스트를 완료하기 위한 오버헤드를 릴리즈 주기에 반영해야 한다.

마지막으로, 애자일 부서와 데브옵스 조직은 테스트 커버리지를 정기적으로 측정하고 논의해야 한다. 개발 부서와 품질 자동화 엔지니어가 문제를 포착하고 위험에 대처하기 위해 실제로 테스트를 구현, 자동화, 통합하지 않으면 시프트-레프트 전략을 도입해도 무용지물이다.
 
충분한 테스트 자동화 없이 릴리즈 주기 속도를 높이거나 지속적 제공을 구현할 경우 최종 사용자 경험의 질을 떨어트리는 심각한 품질 문제가 발생할 수 있다. 릴리즈를 너무 빈번하게 푸시하는 애자일 개발 부서는 결국 더 많은, 더 나은 자동화에 투자하는 것이 아니라 프로덕션 문제와 결함에 대처하는 데 급급하게 된다. editor@itworld.co.kr