Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
VDI / 가상화ㆍ컨테이너 / 개발자

글로벌 칼럼 | 컨테이너 기반 통합 테스트의 이점

Matt Asay  | InfoWorld 2022.01.18
완벽한 소프트웨어를 가진 행성이 어딘가에 있을 수 있지만, 구글의 오픈소스 책임자 크리스 디보나의 말처럼 우리가 사는 행성은 그런 행성이 아니다.

따라서 개발자에게는 2가지 길이 있다. 소프트웨어를 신중하고 엄격하게 테스트해 발생할 수 있는 모든 문제를 배포 전에 찾아내거나, 테스트를 줄이고 배포 속도를 높여 프로덕션 환경에서의 오류를 감내하는 것이다.
 
ⓒ Getty Images Bank

전자는 의료 및 금융 같은 규제 산업에서 일하는 개발자가 주로 택하는 길이며, 후자는 “개발한 사람이 운영까지 한다(You build it, you run it)”라는 AWS CTO 베르너 보겔스의 유명한 격언에 동의하는 개발자가 선택하는 길이다. 

이처럼 소프트웨어 테스트와 배포 속도 사이의 균형은 개발자의 생산성과 관련한 대표적인 논쟁거리다.

테스트 어느 단계에 있든, 소프트웨어 테스트를 위한 단일화된 솔루션은 없다. 때문에 개발자는 변화하는 요구사항에 맞춰 올바른 테스트 방법을 지속해서 모색해야 한다. 동시에 개발자는 사용할 테스트 방법을 습관으로 만들기 위해 느리거나 복잡하지 않으면서 주요 문제를 해결하는 가장 효율적인 방식을 찾아야 한다.

최근 필자는 ‘유닛 테스트’에서 효율적인 방식을 발견했다. 유닛 테스트는 독립적으로 진행하는 가장 작은 단위의 소프트웨어 테스트다. 소프트웨어가 의도에 따라 동작하는지 확인할 수 있을 뿐 아니라 다른 개발자가 작성한 코드 베이스의 일부를 추론할 수도 있다. 유닛 테스트는 오래 전부터 사용하던 방법이지만, 최근 들어 자동화가 사용자 경험을 실제 사용성까지 단순화하면서 깊숙이 자리 잡았다.

유닛 테스트와 유사한 다른 형태의 테스트 방법도 있다. 수십 년 동안 개발 중인 방법이지만, 이제서야 본질적인 문제를 해결하고 단순화된 접근에 적절한 추상화 수준을 제공하며 효율적인 방식을 찾아가고 있는 ‘통합 테스트’다. 


개발자의 역할은 ‘조립’에 있다

전통적인 3계층 아키텍처 시스템은 데이터베이스 1개와 상호작용할 수 있는 API를 1개 혹은 2개 보유하는데, 이는 서드파티로 확장될 수 있는 요소다. 많은 개발자가 솔루션을 여러 가지 다른 구성요소 나누는 경향이 있다. 구성요소의 대부분은 개발자가 직접 작성하지 않았고, 소스코드를 보지 못했으며, 다른 프로그래밍 언어로 작성된 코드다. 개발자는 논리를 작성하는 작업보다 코드를 조합하는 데 더 많은 시간을 투입한다. 

오늘날의 프로덕션 시스템은 일반적으로 다수의 데이터베이스, API 및 기타 마이크로서비스 및 엔드포인트와 상호작용한다. 모든 데이터베이스, 메시지 대기열, 캐시, 프레임워크에는 동작을 결정하는 고유한 상태와 규칙, 조건이 있다. 따라서 개발자는 자신이 개발한 소프트웨어가 다른 소프트웨어와 상호작용할 때 시스템의 예상 동작을 예상하기 어렵다. 통합 테스트는 프로그램 배포 전에 소프트웨어의 상호작용을 테스트하는 방법이다.

1980년대에 통합 테스트를 처음 접한 마틴 파울러는 “통합 테스트는 독립적으로 개발된 소프트웨어 유닛이 서로 연결되었을 때 올바르게 작동하는지 판단한다”라고 설명했다. 

비교적 최근까지는 프로덕션 환경의 복제본에서 통합 테스트를 진행했다. 하지만 테스트 환경을 수작업으로 제작하는 것은 많은 시간을 투입해야 하고 실수할 위험이 큰 작업이다. 테스트와 프로덕션 간 불일치에 대한 불이익이 있었고, 프로덕션 환경을 변경할 때마다 테스트 환경을 변경해야 하는 것도 부담이었다. 이처럼 통합 테스트는 설정과 사용이 너무 어려웠고, 개발자에게 모호하고 접근할 수 없는 분야로 남아있었다.

그러나 지금은 상황이 달라졌다.


테스트컨테이너를 통한 통합 테스트 개선

리처드 노스는 2015년 딜로이트 디지털(Deloitte Digital)에서 수석 엔지니어로 근무할 때 테스트컨테이너(Testcontainer)를 고안했다. 노스는 개발팀이 통합 테스트에 어려움을 겪는 이유가 일관성 있는 로컬 설정 생성부터 데이터베이스 구성 및 기타 수많은 문제 관리에 이르기까지 설정이 복잡하기 때문이라고 봤다. 개발팀에는 실제 프로덕션 환경과 같은 의존성에서 코드를 테스트할 수 있는 믿을 만한 방법이 필요했다.

노스는 개발자가 데이터 스토어, 데이터베이스, 혹은 아파치 카프카 프레임워크처럼 도커 컨테이너에서 실행할 수 있는 모든 요소를 컨테이너로 테스트하도록 오픈소스 라이브러리로 테스트컨테이너를 구축했다. 인간 공학적인 코드 기반 방법으로 개발자는 컨테이너를 로컬 및 지속적인 통합 테스트에 활용할 수 있다. 

오늘날 테스트컨테이너는 구글, 오라클, 소프티파이(Spotify), 인스타나(Instana), 잘란도(Zalando)와 같은 수천 개의 기업에서 사용하는 가장 인기 있는 도커 기반 통합 테스트 라이브러리다. 테스트컨테이너가 인기를 끈 이유는 사전 지원하는 모듈 라이브러리에 알려진 모든 데이터베이스와 기술이 포함됐기 때문이다. 테스트컨테이너 프로젝트에 기여한 데이터베이스 및 기술 솔루션 업체가 직접 관리하기도 한다. 노스는 2021년 초 테스트컨테이터너 핵심 메인테이너인 세르게이 에고로프와 함께 400만 달러 투자를 유치해 아토믹자(AtomicJar)를 창업하고, 테스트컨테이너 모듈의 생태계를 계속 확장하고 있다.

소프트웨어의 배포 속도와 품질 유지 간의 균형을 적절하게 유지하는 방법에 대한 논쟁은 항상 치열하다. 자바 컴파일러와 유사 기술이 인기를 끄는 이유는 개발 시점이 얼마 남지 않은 상황에서 발견한 오류도 신속하게 해결할 수 있기 때문이다. 

테스트를 피해 가는 사악한 오류는 언제든지 존재한다. 하지만 소프트웨어의 유닛 테스트와 통합 테스트가 점점 쉬워지면서, 프로덕션 전에 코드 간 통합 테스트를 더 자주 진행해야 한다는 주장에 힘이 실리고 있다.

editor@itworld.co.kr
 Tags 컨테이너 도커 통합테스트 유닛테스트
IDG 설문조사

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.