[아이티데일리] 클라우드, 소셜 및 몰입형 컴퓨팅 기술의 개발은 애플리케이션 품질 및 서비스 제공에 대한 엔드 유저의 기대를 상당히 높였다. 이제 ‘품질’은 사용자 경험 서비스의 품질, 가용성, 성능 보안 및 비즈니스 영향력을 포함하는 개념이어야 한다. 실제 가트너의 2020년 디지털 비즈니스 플랫폼 관련 설문조사에 따르면, 응답자의 4분의 3 이상이 자신의 팀이 수익 창출 역할을 담당하고 있다고 답했다.

많은 애플리케이션 및 소프트웨어 엔지니어링 리더들은 고객의 기대를 충족시킬 수 있을 만큼 충분한 디바이스를 갖추고 있지 않다. 많은 이들이 시대에 뒤처진 개발 및 테스트 접근 방식에 의존하고 있기 때문이다. 이 경우 팀은 강력하고 탄력적인 애플리케이션을 구축하고, 예상치 못한 상황에 대처하며, 기술적 부채가 생기는 속도보다 빠르게 가치를 전달할 수 있는 기술이 부족해진다.

결과적으로 팀은 빠른 속도로 변화하는 기술에 적응하지 못하고, 시스템의 복잡성을 감당하지 못해 고객의 기대를 충족하지 못하게 된다. 이로 인해 애플리케이션과 서비스가 심각하게 손상되거나 완전히 중단될 수도 있으며 이럴 경우 조직은 운영 및 비즈니스상의 위험에 노출된다.

소프트웨어 엔지니어링 리더들은 팀원들이 이러한 위험을 완화하고 높은 수준의 비즈니스 영향력을 제공하기 위해 팀이 채택할 수 있는 새로운 관행과 접근 방식을 찾고 있다. ‘디지털 면역(digital immunity)’ 개념은 이를 해결할 수 있는 로드맵을 제공한다. 이 개념을 적용하기 위해서는 비전을 설정하고, 디지털 면역을 구축하며, 비효율적인 테스트를 제거하는 것부터 시작해야 한다.

분석

디지털 면역을 위한 비전을 설정하라

소프트웨어를 테스트했다는 사실은 때로 잘못된 보안 의식을 만들어낼 수 있다. 이는 ‘절차를 따랐으니 특별한 문제는 없을 것이며, 만약 문제가 생기더라도 프로토콜을 따랐을 뿐이기 때문에 책임이 없다’는 잘못된 사고방식으로 이어진다.

절차를 준수하고 제품 사양에 따른 검증을 위한 테스트를 실행한다고 해서 제품이 제대로 작동하거나, 그 자체로 인정받아 자주 사용되거나, 원하는 모든 결과를 달성한다는 보장은 없다. 이러한 절차는 제품이 고객에게 가치 있는 것인지와는 아무런 상관이 없다.

그 대신 소프트웨어 엔지니어링 리더는 매력적인 사용자 경험(UX)을 구성하는 요소에 집중해야 한다. 제품이 ‘작동하는지’에만 집중하기보다는 ‘어떻게 하면 더 잘 작동할 수 있을지’, ‘어떻게 하면 보다 향상된 회복력을 갖출 수 있을지’에 대해 생각해야 한다. 이를 위해서는 혁신적인 사고방식은 물론 제품 품질을 높이는 방향으로 비전을 전환할 필요가 있다. 또한 제품 결함이 생산 소프트웨어로 넘어가는 경우를 위한 대비책도 요구된다.

디지털 면역 구축을 위한 비전 성명의 예시는 다음과 같다.

● 우리는 품질 중심의 문화를 육성하고 결함이나 시스템 장애로 인해 손상되지 않는 우수한 UX를 반드시 만들어 낼 것이다. 이러한 비전은 어떤 장애가 언제 발생할지 모르는 상황에서도 우리는 실패를 자연 발생으로 받아들이는 시스템을 구축함으로써 이뤄질 것이다. 우리는 전체 시스템 상태를 유지하는데 집중하여 장애 발생의 영향을 최소화하는 기술을 지속적으로 개선하고 있다. 이처럼 강력한 비전 성명은 디지털 면역 구축을 위한 시행 전략을 정의하는 데 참고가 되는 틀을 만들어준다. 이는 조직을 정비하고 다음과 같은 비전을 구현하기 위한 행동 조치를 취하는 데 도움이 된다.
● 품질에 대한 생태계 중심의 관점을 채택함으로써 기존의 애플리케이션 또는 프로젝트 중심 품질 모델에서 전체적인 품질 접근 방식으로 조직을 전환할 것
● CX, 다중 경험, UX 및 직원 경험 간의 연결을 구축함으로써 아이디어의 시작부터 운영에 이르기까지 모든 단계에 품질 항목을 적용할 것
● 필요한 역할, 기술 및 사례를 파악함으로써 소유권을 할당하고 탄력적인 애플리케이션 구축에 필요한 기술을 갖춘 직원을 지정할 것

디지털 면역을 구축하라

소프트웨어 엔지니어링 리더는 디지털 면역을 발전시키기 위해서 팀이 다음과 같은 방식을 채택할 수 있도록 권한을 부여해야 한다.

● 자율 테스트
자율 테스트는 인간의 개입으로부터 독립적인 소프트웨어 테스트를 수행하기 위한 인공지능 및 머신러닝 기반 기술과 업무로 구성된다. 자율 테스트는 활동을 수행해 수집된 데이터를 학습함으로써 테스트 결과를 지속적으로 개선한다. 이를 통해 기존의 테스트 자동화를 테스트 사례의 자동 실행 이상으로 확장하여 테스트 계획, 생성, 유지 관리 및 분석을 완벽하게 자동화한다.

자율 테스트는 요건 품질, 설계 품질, 코드 품질, 배포 품질 및 운영 회복력과 관련된 모든 테스트 활동을 통합해 자동화 한 것이다. 이는 테스트 활동에 대한 독립성과 자율성은 물론 오케스트레이션(orchestration)을 제공해 자동화 그 이상의 이점을 제공한다.

● 카오스 엔지니어링
카오스 엔지니어링은 실험적이며 잠재적으로 피해를 줄 수 있는 고장 또는 결함을 주입한 테스트를 사용하여 복잡한 시스템 내의 취약성과 약점을 발견하는 것이다. 약화된 바이러스를 통제 하에 주입해 면역 체계를 공격하는 것과 같이, 카오스 엔지니어링을 사용하여 조직이 버그와 시스템 고장에 대처하도록 훈련할 수 있다.

카오스 엔지니어링은 비교적 최근에 실행되기 시작했지만, 높은 성과를 내는 팀에게는 중요한 무기가 된다. 가트너의 자동화, 지속적 품질 및 데브옵스(DevOps)를 통한 비즈니스 어질리티(agility) 달성에 관한 설문조사에서는 응답자의 18%가 카오스 엔지니어링을 사용 중이거나 사용할 계획인 것으로 나타났다.

소프트웨어 엔지니어링 리더는 팀이 사전 프로덕션 환경에서 카오스 엔지니어링을 함께 시작할 수 있도록 지원해야 하며, 이를 통해 비(非)간섭 및 테스트 우선 방식으로 업무를 안전하게 익힐 수 있도록 해야 한다. 그렇게 배운 내용은 평소 시스템 운영이나 생산 강화에 적용할 수 있다.

● 자동 복구(Autoremediation)
카오스 엔지니어링을 통해 소프트웨어 버그의 영향과 시스템의 잠재적인 장애에 대해 더 잘 알게 되었다면, 그 다음 단계는 상황에 맞는 모니터링 및 자동 복구 기능을 애플리케이션에 직접 구축하는 것이다. 이런 시스템은 자체적으로 모니터링할 뿐만 아니라 문제가 감지되면 운영진의 개입 없이 자동으로 수정해 정상 작동 상태로 복귀한다.

소프트웨어 엔지니어링 리더는 이상 징후가 감지되는 순간부터 문제가 해결되는 시점까지 전체 프로세스의 완전한 자동화를 권장해 사람이 개입할 필요가 없게 해야 한다. 애플리케이션에 영향을 미치는 문제가 발생하는 동안 시스템을 계속 사용할 수 있으며, 사람의 개입이 필요하지 않은 경우 부가가치를 쉽게 발견할 수 있을 것이다.

● 옵저버빌리티(Observability)
옵저버빌리티는 소프트웨어와 시스템이 ‘관찰’되고 동작에 대한 질문에 답할 수 있게 하는 특성을 의미한다. 현대 개발 방법론의 가능성을 완전히 실현하기 위해서는 애플리케이션이 ‘옵저버빌리티 기반 개발’로 구축되어야 한다.

옵저버빌리티 툴의 핵심은 현재 일어나고 있는 문제에 관한 이상 징후를 찾아낸 다음 관련됐을 가능성이 높은 로그 파일/메트릭스에서 다른 정보를 연결하는 것이다. 운영자는 관련 정보를 상황에 맞게 표시함으로써 문제의 잠재적인 원인을 보다 신속하게 분리해낼 수 있다.

소프트웨어 엔지니어링 리더는 옵저빌리티가 가능하도록 하기 위해 인프라 및 운영(I&O) 팀과 협력해 오픈텔레메트리(OpenTelemetry) 및 오픈메트릭스(OpenMetrics)와 같은 새로운 개방형 수집 표준을 활용하는 데 동의해야 한다. 또한 팀이 애플리케이션 및 지원 인프라에 대한 옵저버빌리티를 직접 설계하도록 교육하여 애플리케이션 가동 시간을 늘릴 수 있다.

● 지속적인 검증
자동 복구는 회복력이 높은 시스템을 구축하는 데 필수적인 요소이다. 그러나 이상 징후가 감지될 때만 작동한다는 점에서 여전히 사후반응적이다. 여기서 두 가지 질문 “이상 징후는 언제 감지되는가?”와 “사용자에게 영향을 미치는가?”가 제기된다.

일부 시나리오에서 사용자는 시스템에 버그가 있는 것 같다고 인식할 수 있다. 그러나 월말 또는 분기말 조정이 되기 전까지는 오류가 문제로 인식되지 않을 수 있는 수많은 다른 시나리오가 존재한다. 이때까지 시스템 및 데이터 손상이 매우 광범위하게 발생했을 수 있다.

지속적인 검증에는 실제 환경에서 데이터 및 시스템의 무결성을 지속적으로 모니터링하는 아주 강력한 서비스 구축이 요구된다. 여기서 핵심은 운 없는 사용자가 데이터 불일치나 비정상적인 시스템 동작을 발견하기를 기다리는 것이 아니라, 그것을 적극적으로 탐색하는 것이다.

휴면 또는 활성 상태의 버그, 데이터 불일치 또는 비정상적인 사건이 감지되면 해당 사고에 대해서만 응답해서는 안 된다. 앞서 설명한 자동 복구 절차를 활성화하여 버그가 더 이상 확산되는 것을 방지해 서비스를 복구하고 사용자에게 미치는 영향을 완화해야 한다. 요점은 문제점이 사전 예방적이고 지속적인 유효성 검사 메커니즘의 일부로 훨씬 일찍 드러났기 때문에 오류의 ‘폭발 반경’이 훨씬 작다는 것이다.

비효율적인 테스트 업무를 교체하라

프로덕션 환경에 배치된 소프트웨어의 지속적인 흐름을 통해 고객 가치를 신속하게 제공하는 것이 데브옵스의 핵심이다. 속도를 높이려면 데브옵스 팀이 가장 큰 제약을 식별하고 이를 제거해야 한다.

데브옵스 팀은 팀원들에게 간단한 질문 “항상 무엇을 기다리는지”를 물어봄으로써 종종 가장 큰 제약을 파악할 수 있다. 대부분의 조직에서는 수동 테스트의 높은 비율 때문에 테스트가 가장 큰 제약 조건이라고 답한다. 주요 애플리케이션의 소프트웨어 테스트 일정은 낮은 품질과 긴 테스트 간격으로 인해 원래 일정보다 약 25% 길어진다.

수동 테스트의 현재 상태를 평가하고 이러한 테스트 자산을 점점 더 자동화된 자율 테스트 수준으로 전환하기 위해 가장 효과적인 접근 방식을 결정해야 한다. 여기서 수동 테스트의 기존 구조는 자동화에 적합하지 않을 수 있다는 것에 주의해야 한다. 그러나 기존 수동 테스트에서 입력 값, 예상 결과, 탐색 경로 및 테스트 데이터와 같은 관련 구성요소는 자율 테스트를 위한 입력에 재사용될 수 있다.