<7> 자동화의 현재와 미래
QA for Beginners
자동화란 무엇일까?
QA에 몸담고 있다면 자동화(Automation)에 대해 들어보지 못한 사람은 없을 것이다. 자동화라는 개념은 말 그대로 기계가 사람 대신 반복적인 일을 수행하듯, 사람이 직접 테스트를 수행하지 않아도 테스트 빌드가 알아서 동작하여 테스트가 수행되게끔 테스트 활동을 고도화하는 것을 말한다.
앱을 켜고 끄고 로그인을 했다 로그아웃을 하고 이런 것들을 왜 내가 하고 있지?
기계로 물건을 찍어내는 세상에 테스트 활동도 자동화시킬 수 없을까?
사람은 늘 효율성을 추구하므로 자동화의 개념은 필연적으로 생겨날 수밖에 없었고, 특히 반복적인 업무가 많은 QA에서는 다른 직무보다 높은 관심을 갖게 되었다.
그럼에도 막상 자동화라는 말을 들으면 다소 낯설게 느껴질 것이다. 그 이유는 QA를 한다고 하더라도 QA 또한 F/E, B/E 등으로 검증 영역이 나뉘기 때문에 모든 팀에서 자동화를 구현하지는 않으며, 자동화를 적극적으로 도입하는 팀에 속해있거나 자동화에 평소 관심이 많았던 경우가 아니라면 자동화 교육이나 적용 방법에 대한 정보를 흔하게 접하기는 쉽지 않기 때문이다. 만약 개인적으로 개발 공부를 했더라도 프로그램을 어떻게 만들지에 초점을 맞출 뿐, 내가 만든 프로그램을 단위별로 어떻게 테스트할지(e.g., Unit Test)에 대해선 많이 다뤄보지 않았을 것이다.
낯설다는 것은 잘 모른다는 것을 뜻하고, 이러한 무지는 자동화에 대한 환상을 갖게 한다. 시작 버튼 하나만 누르면 TC의 A부터 Z까지 알아서 테스트를 수행하며 Status를 체크하고, 실패한 경우에 대해서는 Bug report까지 생성해 주는 환상 말이다.
하지만 현실은 아무 서비스나 쉽게 도입하기에는 다소 애로사항이 있다. 생각보다 자동화를 도입하는 조건이 까다롭기 때문이다. 우선 자동화를 구현하는 방법에는 어떤 것들이 있는지 알아보자.
자동화를 구현하는 방법
자동화를 구현하는 방법에는 자동화 툴을 이용하거나, 직접 코드를 짜서 구현하는 두 가지 방법이 있다.
자동화 툴의 예로는 Katalon Studio가 있다. 이런 툴은 보통 B2B(Business to Business, 기업 대 기업으로 서비스를 제공하는 비즈니스)이기 때문에, 툴을 제공하는 회사에 이용료를 지불하고 사용하게 된다. 자동화 툴의 장점은 코드를 몰라도 Test Procedure(테스트 절차)만 구성해서 실행하면 되기 때문에, 서비스에 쉽게 자동화를 도입할 수 있다는 것이다. 이것으로 부족하다면 직접 코드를 추가하여 커스터마이징 할 수도 있다.
또는 코드를 짤 줄 안다면 직접 구현하기도 한다. 대부분의 회사에서는 이 방법을 많이 채택한다. 왜냐하면 회사마다 제공하는 서비스는 천차만별인데, 비용은 비용대로 들면서 자동화 툴로 procedure를 작성하고 또 일부를 코드로도 구현하며 리소스는 리소스대로 소요하는 것보다는, 원하는 만큼만 구현하여 서비스의 코드에 바로 적용시킬 수 있고 비용도 줄이는 것이 훨씬 효율적이기 때문이다. 이렇게 직접 구현하는 경우, 보통은 Python의 Selenium 라이브러리나 Appium을 이용하여 구현하는 방법을 많이 사용한다(전자는 웹 서비스에, 후자는 모바일 서비스에 도입한다).
자동화 도입 조건 세 가지
그런데 앞서 말했듯 자동화를 무턱대고 적용하긴 어렵다. 미래에는 모르겠지만 현재 채용 시장에서 100% 자동화 도입을 한다며 소개하는 회사가 있다면 곧장 뒤로 가기를 눌러라. 신규 기능이 거의 릴리스 되지 않는 고인 서비스이거나 자동화를 전혀 모르는 회사일 가능성이 매우 높다.
자동화를 도입하기 위한 조건에는 세 가지가 있다.
첫째, 기능의 변동성이 적어야 한다. 즉, 어느 정도 안정화된 서비스여야 한다. 예를 들어 워킹 데이(Working Day) 기준 7일로 산정한 QA 기간 중 자동화 도입을 위해 로그인하고 클라우드 드라이브에 진입하는 자동화를 코드 리뷰까지 완료하여 사흘 만에 구현했다고 하자. 그런데 갑자기 긴급하게 보안 상의 문제로, 로그인 시 이중인증을 도입하고 클라우드 드라이브 대신 이메일 수신을 확인하는 것으로 기획이 변경되었다면? 남은 5일 동안 코드만 짜다 QA 기간을 날릴 것이다. 어찌 일정에 맞춰 자동화를 구현했더라도, 이런 경우가 매 릴리스마다 발생한다면.. 적어도 개발자의 꿈을 키우는 데는 도움이 될 것이다.
둘째, 자동화로 유의미한 리소스 단축이 가능해야 한다. 개인적으로는 적어도 20% 이상의 효율이 발생해야 한다고 본다. 왜냐하면 직접 구현을 하든 Katalon Studio와 같은 전문 자동화 툴을 사용하든 TC만 작성하면 되던 기존 프로세스에서 자동화를 관리해야 하는 추가 리소스가 발생하게 되는데, 이들은 일회성이 아니라 꾸준한 유지보수를 해주어야 한다. Selenium 또는 자동화 툴에서 업데이트로 인해 deprecated 되고, method가 바뀌고, parameter가 달라진다면? 여기에 디바이스 환경도 고려해야 한다! 하루를 꼬박 투자하여 야근까지 해가며 최신화에 성공했다고 하자. 그런데 이렇게 고생하며 자동화를 도입했음에도 5일의 수행 시간이 소요되던 QA 일정이 자동화 도입 후 10% 단축되어 4.5일, 즉 반나절이 단축된 수행 시간을 확보했다면, 배보다 배꼽이 더 큰 공사를 한 셈이다.
셋째, 유지보수가 쉬워야 한다. 위에서 든 예시와 같은 맥락으로, 코드를 짤 때 이식성을 고려하지 않고 자동화를 구현한 바람에 어떤 신규 기능을 테스트하던 method를 하나 이상은 새롭게 만들어야 한다면 이 역시 개발자의 꿈을 하루하루 키워가는 데 도움이 될 것이다. 반면에 기존에 구현해 두었던 method의 parameter 한 두 개만 살짝 손보면 자동화가 돌아가게끔 구현해 두었다면 30분 투자로 3시간짜리 수동 테스트를 면할 수 있을 것이다.
자동화의 가치와 미래
이렇게 조건이 까다로움에도 자동화가 QA의 뜨거운 감자인 이유는, 어쨌든 성공적으로 도입을 한다면 훨씬 효율적으로 리소스를 사용할 수 있기 때문이다. 수제 제작이 쏟아지는 공산품 속에서 살아남은 이유는 희소성으로 인한 가치 때문이다. 하지만 소프트웨어는 수제로 테스트를 한다고 해서 달라지는 것은 없다. Youtube의 알고리즘이 사실 직원들이 수많은 영상들 중 괜찮은 영상들만을 하나하나 직접 보고 선별하는 과정을 거치는 것이라고 해서 그만큼의 가치를 제공하거나 남다른 시청 경험을 제공하는 것은 아니지 않은가. 즉, 효과적으로만 자동화를 도입할 수 있다면 어떤 방식으로든 이득인 것이다.
예를 들어 Sanity Test나 Regression Test와 같은 테스트에 자동화를 도입한다고 해보자.
Sanity Test를 자동화로 돌릴 수 있다면 그 외의 영역은 직접 AD-HOC Test를 수행하는 등의 병렬 테스트가 가능할 수도 있고, 유관 부서와의 미팅을 하거나 Sign off를 준비할 시간을 벌 수도 있다. 다양한 방식으로 생산성을 높일 수 있을 것이다.
비록 지금은 우리가 생각하는 모습의 자동화가 아닐지라도, 미래에는 우리가 상상했던 것처럼 Test Scenario만 작성해서 넣어주면 알아서 테스트 수행해 주는 자동화 툴을 볼 수 있을지도 모른다. Test Scenario 자체도 작성해 줄지 모른다!
2022년 12월에 openAI에서 텍스트 정보를 기반으로 학습을 하는 거대 언어 모델(LLM, a Large Language Model)인 chatGPT가 처음 출시된 후, 2023년 1분기에 이를 활용하는 열풍이 불기 시작했다. 그런데 2분기가 지나기도 전에 5개월 만인 2023년 4월에 Meta에서 텍스트뿐 아니라 이미지·비디오, 오디오, 심도(3D), 열화상(적외선), 동작과 위치를 계산하는 관성 측정 장치(IMU) 센서 데이터까지 총 6개의 정보를 기반으로 학습을 하는 멀티 모달 모델(Multi Modal Model)인 ImageBind를 출시했다. 기술의 발전 속도를 생각하면 7년 내에는 진정한 의미의 자동화가 가능해질지도 모른다.
그렇기에 많은 회사들이 구직자들에게 자동화 경험을 요구하고, 자동화를 추구한다. 실제로 해외 기업 중에는 어느 정도 Test Procedure를 짜고 실행하면 작성한 대로 테스트를 수행하는 자동화 툴을 이미 서비스하고 있다. 이 추세라면 미래에는 대다수의 Test Engineer들은 설 자리를 잃을 것이고, 자동화 툴을 다뤄봤으며 이를 코딩으로도 커스터마이징 할 수 있고, 프로세스를 계획하고 관리할 줄 아는 QA만 살아남게 될 것이다. 개발자들이 코더들은 자리를 잃고, 프로그래머만 살아남을 것이라고 예상하듯 말이다.
자동화에 대한 사견
IT 기업들이 github, Slack, Jira 등의 툴을 도입했듯, 개인적으로 미래에는 직접 자동화를 구현하는 추세에서 자동화 툴을 도입하는 흐름으로 바뀔 것이라고 생각한다.
사내 코드 관리용 프로그램을 직접 만들어서 관리하는 것보다 github를 이용하는 것이 편리하고 비용 절감이 되듯, 자체 개발한 자동화 툴을 유지보수하는 것보다 잘 완성된 툴을 도입하는 것이 훨씬 유리할 것이기 때문이다.
하지만 아직은 그런 세상이 오지 않았다. 지금은 현존하는 자동화 툴을 많이 사용해 본 사람보다는, 자동화를 직접 구현해 본 사람을 원한다. 상상하던 자동화를 현실로 이뤄낼 팀을 꾸리기 위해 말이다. 어쩌면 그 팀의 멤버 중 한 명이 이 글을 읽는 독자가 될지도 모르겠다. 당신이 현재에 살든 미래에 살든, 자동화에 관심이 있다면 간단한 자동화를 구현하는 것부터 시작해 보는 게 좋다.
Selenium을 이용해 Chrome을 실행하여 Naver에 진입한 뒤 로그인하는 과정을 자동화해 보는 건 어떨까?
현재 자동화의 장단점에 대한 명확히 이해를 바탕으로 조만간 찾아올 미래에서 살아남는 QA로 성장하길 바란다.
