2020년 3월30일

COVID-19 가 현대사회를 황폐화 시키며 세상은 혼란속에 뒤흔들리고 있다. 4차산업혁명의 시대, 기술 기반으로 연결된 진보된 세계에서 우리의 삶 속으로 전염병이 퍼져 나가 세계적인 위기를 맞게 될 것이라고 그 누구도 상상하기 어려웠을 것이다. 각 국가들은 전염병을 막기 위해 지역 사회에 수많은 노력을 기울이고 있다. 여기에 COVID-19 평가와 소프트웨어 테스트로부터 얻을 수 있는 많은 유사점들이 있다. 소프트웨어 개발자이자 테스터로서 COVID-19를 통해 얻게 된 몇 가지 교훈들에 대해 이야기하고자 한다.

1. 조기에 자주 테스트 진행

소프트웨어 테스트의 진언 중 하나는 소프트웨어 개발 수명주기에서 조기에 테스트하고 자주 테스트하라는 것이다. 요구사항 수집, 사양 작성, 코딩, 테스트 및 릴리스에서 요구사항의 변화에 따라 버그 수정 비용이 기하급수적으로 증가하기 때문이다. 버그가 사용자에게 릴리스 되고 나면, 디버깅, 근본 원인 및 수정이 매우 어려워지고 비용 또한 많이 든다. 더 중요한 것은 사용자의 신뢰를 잃게 되어 이를 다시 되돌리는 것이 매우 어렵다는 점이다.

여러 국가에서 유행성 질병에 대해 어떻게 대처하고 있는지 살펴보면, 조기에 행동하고 테스트한 국가들이 상대적으로 바이러스에 잘 대처하고 있다는 것을 알 수 있다. 예를 들어, 대만은 중국에서 새로운 바이러스가 발견되기 전인 2019 년 12 월 31 일부터 우한에서 도착하는 승객을 모니터링하기 시작했다. 2020 년 3 월 27 일 현재 대만은 252 건의 코로나19 확정 건과 2 건의 사망 기록을 가지고 있다.

한국은 2 월에 조기 발병이 진행되었지만, 곧 광범위한 테스트 시스템을 시행했다. 현재는 지역별 조치 아래 9,000 건을 넘어 조금씩 감소세를 보이고 있다. 지금까지 한국은316,664 건의 테스트를 수행하여 세계 어느 나라보다 많은 테스트를 진행했다.

2. 격리

검역소, 보호소, 셧다운, 잠금, 금지또는 제한된 항목들은 모두 바이러스의 영향을 받는 국가들이 바이러스를 차단하기 위해 사용하는조치들이다. 소프트웨어 개발측면에서 보면, 이는 소규모 테스트를 수행하는 것에서, 단위 테스트를 시작하여, 다른 구성 요소를 통합한 다음, 릴리스 전에 엔드-투-엔드 테스트를 수행하는 것에 해당한다. 단위 테스트를 시작하면 문제를 조기에 발견하고 해결할 수 있다. 만약, 엔드-투-엔드테스트 단계에서 문제를 찾을 때까지 테스트하며 기다린다면 버그의 위치를 ​​찾아내 결정하기가 더욱 어려워질 것이다.

최적의 단위 테스트를 작성하려면 전체 제어가 가능한 환경을 포함시켜야 한다. 데이터베이스나 인터넷 연결과 같은 다른구성 요소 및 종속성에 의존하는 기능 테스트를 하는데 사용할 수 있는 많은 mocking 프레임워크가 있다. 예를 들어, Mockito는 Java 용으로 널리 사용되는 mocking 프레임 워크이다. 다른 언어들도 비슷한 mocking 솔루션을 가지고 있다. 실제로 의존하는 요소를 불러오는 대신 모의를 사용하면 테스트가 빠르고 안정적으로 실행되므로 개발자는 보다 민첩한 방식으로 문제를 추적할 수 있다.

나중에 개발주기를 진행하면서 더 많은 구성 요소가 통합될수록 테스트는 취약하고느리고 신뢰할 수 없게 된다. 이러한 이유로, 최상의 테스트 전략은 다른 유형의 테스트보다 훨씬 더 많은 단위 테스트를 만드는 것이다. 이것은 테스트 피라미드를 보여준다.

비 패턴(해서는 안 되는 패턴)은 아이스크림 콘처럼 거꾸로 된 피라미드로, 더 많은 엔드-투-엔드 테스트가 있고 단위 테스트가 거의 또는 전혀 없다.

또 다른 비 패턴은 엔드-투-엔드 및 단위 테스트가 많지만 중간에 통합 테스트가 없는 모래 시계이다.

3. 추적가능성

한국이 확진자 곡선의 증가세를 점점 안정화시킬 수 있었던 이유 중 하나는 감염된 모든 환자들의 움직임을 정부가 공개했기 때문이다. 이를 통해 질병 관리 센터는 감염 가능성이 있는 사람들을 추적하고 테스트할 수 있었다. 예를 들어, 새로운 사례가 발생되면 해당 지역의 모든 모바일 사용자는 자동 알림을 받게 된다. 이러한 방법은 개인 정보 보호 문제를 일으킬 수 있는 다른 국가에서는 적용하기가 어렵다.

소프트웨어 세계에서 추적 가능성은 소프트웨어 개발 및 서비스에 매우 중요하다. 예를 들어, 회사는 사용자의 클릭 스트림 데이터를 분석하여 제품을 개발하거나 마케팅 방법을 결정할 수 있다. 적절한 로깅 메커니즘을 갖추면 자동 경고를 모니터링 및 설정하고 나중에 어려운 버그 재현을 하는데 용이하다.

4. 방법과 정책

위에서 언급한 요점들은 개발자와 테스터 간의 모범 사례이며 공통 지식이지만, 많은 회사들이(대형이든 소규모이든) 이러한 지침을 따르지 않는다. 그 이유는 매우 간단하다. 시간과 압박 때문이다. 개발자들은 정해진 짧은 일정으로 인한 압박을 받는다. 그들은 종종 코딩을 끝마치는 것이 어려워 “보유하면 좋은 기능”은 희생해 버리는 경향이 있다. 불행히도, 테스트는 속일 수 있는 것으로 간주된다. 이러한 근시안적인 시각은 나중에 엄청난 버그 사냥을 해야 하는 결과를 낳게 된다.

그러나 어떤 개발자도 버그가 있는 코드를 작성하는 것을 원하지 않을 것이다. 저 품질 제품을 생산하려는 임원이나 관리자는 없다. 문제는 ‘의도’가 아니다. ‘방법’과 ‘정책’이 문제의 핵심이다. 회사나 부서에서 소프트웨어 개발 프로세스 및 테스트에 관한 특정 정책을 설정하지 않는 한, 관리자와 개발자는 본능에 따른 관점에서 작업을 수행하게 된다. 이것은 아마존 최고 경영자 제프 베조스(Jeff Bezos)의 유명한 인용문으로 가장 잘 표현된다.

“좋은 의도는 결코 효과가 없으며, 어떤 일이 일어나기 위해서는 좋은 메카니즘이 필요하다” 제프 베조스

워싱턴주 주지사인 제이 인슬리(Jay Inslee)는 뉴욕 주와 캘리포니아 주와 같은 다른 주들의 지시를 따르지 않고, 주 전체의 폐쇄 명령을 천천히 진행했다. 대신에 그는 시민들에게 불필요한 외출을 제한하자고 탄원했다. 모두 아는 바처럼, 그의 좋은 의도는 효과가 없었으며, 나중에는 주 전체의 셧다운을 발표해야 했다.

최적의 코드 체크인 정책에는 코드 검토, 단위 테스트 작성 및 코드 적용 범위가 포함되어야 한다. 물론, 이러한 정책은 자동화되고 우수한 모니터링 및 시행 방안이 마련된 경우에 가장 효과적이다. 따라서 개발 수명주기 초기 단계에서 CI/CD (Continuous Integration/Continuous Deployment)를 배치하는 것이 중요하다.

결론

우리는 COVID-19가 어떻게 우리의 삶을 변화시킬 것인지 아직은 다 알 수 없다. 바이러스는 계속 돌연변이를 일으킨다. 마찬가지로 소프트웨어 기술도 계속 발전할 것이다. 매커니즘이 아무리 훌륭하더라도, 하루하루 실행하는 것은 개별 팀이나 개발자의 몫이다. 작성된 테스트 코드는 테스트 중인 코드가 변경되면 더 이상 쓸모 없게 된다. 테스트 코드 작성에 대해 흔히 듣는 반론 중의 하나는 지속적인 유지관리가 필요하다는 것이다. 물론 맞는 말이다. 매일 아침 세수를 하거나 양치를 하는 것과 같다. 다만 매일 유지해야 하는 일이기 때문에, 그것을 하지 않는다는 것은 상상하기 어렵다. 궁극적으로, 청결한 위생과 상식은 건강한 삶을 영위하기 위해 필요하다. 마찬가지로 우수한 소프트웨어 테스트 프랙티스는 개발자에게 더 나은 품질의 제품과 더 많은 시간을 제공할 수 있다.

Written by 테스트웍스 CTO 이창신 소장(changsin@testworks.co.kr)

Testworks Inc., Seoul, Korea, CTO, Research & Development

Amazon Corporation (2014-2019), Seattle, WA, Sr. Software Development Engineer

Microsoft Corporation (1999-2014), Redmond, WA, Software Engineer