[아이티데일리] COVID-19(코로나19)가 현대사회를 황폐화시켜 세상이 혼란 속에 뒤흔들리고 있다. 그 누구도 4차 산업혁명의 시대, 기술 기반으로 연결된 진보된 세계에서 우리의 삶 속으로 전염병이 퍼져 나가 세계적인 위기를 맞게 될 것이라고 상상하기 어려웠을 것이다.

각 국가들은 전염병을 막기 위해 지역 사회에 수많은 노력을 기울이고 있다. 여기에 COVID-19 대처에 대한 평가와 SW 테스트로부터 얻을 수 있는 많은 유사점들이 있다. SW 개발자이자 테스터로서 COVID-19를 통해 얻게 된 몇 가지 교훈들에 대해 이야기하고자 한다.

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

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

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

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

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

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

비 패턴(해서는 안 되는 패턴)은 아이스크림콘처럼 거꾸로 된 피라미드 형태로, 더 많은 엔드-투-엔드 테스트가 있고 단위 테스트가 거의 또는 전혀 없다. 또 다른 비 패턴은 엔드-투-엔드 및 단위 테스트가 많지만 중간에 통합 테스트가 없는 모래시계 형태다.

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

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

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

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

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

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

결론
우리는 COVID-19가 어떻게 우리의 삶을 변화시킬 것인지 아직 다 알 수 없다. 바이러스는 계속 돌연변이를 일으킨다. 마찬가지로 SW 기술도 계속 발전하고 변화할 것이다. 매커니즘이 아무리 훌륭하더라도, 하루하루 실행하는 것은 개별 팀이나 개발자의 몫이다.

테스트 코드 작성에 대해 흔히 듣는 반론 중의 하나는 지속적인 유지관리가 필요하다는 것이다. 작성된 테스트 코드는 테스트 중인 코드가 변경되면 더 이상 쓸모없게 된다. 맞는 말이다. 매일 아침 세수를 하거나 양치를 하는 것과 같다. 다만 매일 유지해야 하는 일이기 때문에, 그것을 하지 않는다는 것은 상상하기 어렵다. 청결한 위생과 상식은 궁극적으로 건강한 삶을 영위하기 위해 필요하다. 마찬가지로 우수한 SW 테스트 프랙티스는 개발자에게 더 나은 품질의 제품과 더 많은 시간을 제공할 수 있다.