안녕하세요. 저는 가이 키셀(Guy Kisel)이라고 합니다.
저는 리그오브레전드 클라이언트 업데이트 테스트, 제작, 그리고 배포를 맡고 있는 팀에 있고, 
지금부터 설명드릴 자동화된 테스트 프로젝트를 맡고 있기도 합니다.

 

현재 리그오레전드 클라이언트(구:어도비 에어기반 클라이언트)를 사용해본 경험이 있다면, 아마 이상한 버그들을 한번쯤 겪으신적이있을겁니다.
이런 버그들이 흔한일은 아니지만, "X발 어떻게 이딴 버그가 라이브버전으로 나온단 말야?"라고 생각하신적은 있겠죠.
그리고 아마도 여러분들은 저희들이 소환사들에게 전달코자 하는 품질 수준과 기대에 못미친다고 생각하신적 있으실겁니다.
앞서 전해드렸던 클라이언트 업데이트 아키텍처에 관한 글에서처럼, 처음엔 우리가 에어를 그대로 사용할 계획에 있었다고 말씀드린적이 있을겁니다.
당시의 HTML에선 불가능했던 풍부한 멀티미디어 효과들을 지원했지만 그 이면엔, 에어클라이언트는 제한된 테스팅 커버리지(범위)를 가지고 있었습니다.
업데이트를 개발하고 배포하는데 상당한 시간을 들여야했고 무엇보다 까다로운 작업이었던 이유는 모든 변경사항들을 수동으로 테스트를 해야했기 때문입니다.

시간소모이자 일관성없는 과정이었죠...

우리가 생각한 이상적인 테스트 환경은 기계가 지루하고 반복적인것들을 테스트하게끔 하고, 사람이 더욱 창조성을 요하는 테스트를 하게 하는것이었습니다.

 

리그오브레전드 클라이언트를 업데이트 할때 가장 핵심목표중 하나는 견고한 자동화 테스트를 구현시키는것이었고, 그렇게함으로써 소환사들에게 고품질의 경험을 제공하는 것이었습니다.

클라이언트 업데이트 아키텍처에서는 크로미늄 기반 프론트엔드, 그리고 통신을 위한 REST API와 웹소켓을 제공하고있는 C++백엔드를 포함합니다.

이 아키텍처는 크게 두가지 편리한 자동화 인터페이스를 제공하고있습니다. 
프론트엔드에서는 업계 표준인 Selenium WebDriver 프로토콜을 충족하는 Chrome Driver를 사용할 수 있습니다.
백엔드에선, 오픈소스 HTTP 요청과 웹소켓 라이브러리를 사용하죠.

이것들은 현존하는 가장 일반적인 자동화 인터페이스 중 하나이므로, 맞춤형 자동화 테스트 드라이버를 구현할 필요가 없습니다.

 

저희의 기능 테스트들은 Cucumber.JS를 이용하고 있고 이것들은 모두 일반적인 툴이면서도 풍부한 도큐멘테이션이기 때문에,
이 글에서 저는 툴에 관해서보다 우리의 과정과 파이프라인에 대해 집중하도록 하겠습니다.
저는 그래서 비슷한 자동화 문제에 접근하는 모든이들에게 도움이 되길 바라면서..

 

<영상 하나 있는데 안올라감>

 

 

 

 

문화

성공적인 테스트 자동화는 크게는 문화와 심리학의 문제입니다. 기술적인것은 부차적인 문제죠.

 

제 아무리 많은 기술을 우리가 갖고 있더라도 성공적인 테스트 자동화를 위해선 우리의 인간행동을 다듬을 필요가 있습니다.
테스트된 프로젝트 자체의 실패인지, 테스트 조건이 잘못된것인지, 다른 외적인 요인인지, 혹은 네트워크 결함과도 같은 인프라에서 생긴 요인인지를 테스트가 실패할 때마다 사람이 그것을보고 판단하니까요. 

 

과거 테스트 자동화전략은 품질및 보증팀에서 개발하고 테스트를 돌리는것을 맡는것이었습니다.  
이러한 접근법의 장점으로는,

테스트를 전적으로 맡고있는 전문가들이 해결하기 때문에 개발팀이 일주일에 한번만 새 빌드를 테스트하고 즉각적인 피드백이 필요없이 배포까지 긴시간이 소요되는 장기 프로젝트일 경우에 적합합니다.

또 다른 이점으론 전문가들, 각각의 빌드를 철저히 테스트하는 복잡한 테스트 조건들을 설계하는데 모든 업무시간을 쏟아붓는 테스트 전문가들에도 좋을 수 있습니다.

스플래시 아트를 그리시는 분께 이 과정을 시각화 해달라고 요청했습니다.

 

 

하지만 치명적인 단점도 있습니다. 

개발팀에서 테스트를 돌리지 않거나, 도출된 결과에 주의를 기울이지 않고 "아 몰랑, 문제 생기면 다른 부서가 알아서 하겠지"라고 생각하는 경우도 더러 생기게 됩니다.

또 개발자들이 실패한 코드를 피드백 받는 과정이 느려질 수 있습니다.

이는 엄청나게 빠른 속도로 진행되는 리그오브레전드 클라이언트 업데이트에선 받아들일 수 없죠.

하루 15분마다 새로운 빌드를 만드는데, 이 속도라면 즉각적인 피드백은 중요합니다.

테스트 자체가 빠르게 처리되더라도, 테스트 기술자가 결과를 해석하기까지 개발자가 기다릴 수 없었습니다.

팀 효율서도 우리의 목표중 하나인데 이러한 효율성 측면에서도 전통적인 자동화 테스트는 맞지 않았습니다. 
저희의 접근법은 다음과 같습니다.

 

 

우리의 철학중 하나는 라이엇 전체 모든 팀이 테스트와 자동화에 대해 지대한 관심을 갖게 하는 것이기 때문에 모든 개발자들이 참여해야합니다.

우리 온보딩 과정(신입교육인듯)에서도 어떻게 테스트를 작성해야하고 실행해야하는지 구체적인 문서로 알리고 있으며,

개발자들이 자신의 코드의 자체적인 테스트를 아울러 기능테스트, 성능테스트, 성능테스트 그리고 로딩테스트까지 전적인 책임을 갖게끔 명확하게 알리고 있습니다.

테스트, 제작, 그리고 배포팀은 테스트 도구와 인프라구축 및 유지 관리에 중점을 두고 있지만 이 팀들은 자체적인 테스트를 작성하지는 않죠. 이건 개별 기능팀의 책무니까요.

 

지금이야(새 클라이언트를 넣은 시점) 업데이트를 진행중인 팀이 테스트 실패시 신속히 대응해 조치할 수 있다지만 이 시점까지 오기까지 애로사항이 있었습니다. 특히나 무작위로 나타나는 테스트 실패(Flaky Test)를 해결하는데 버둥거렸죠. 

 

우리의 기존 작업흐름은 다음과 같았습니다.

 

 1.테스트는 가끔 실패한다.

 2.아주 "가끔"실패하니까 다른 고장난 부분을 고치는것보다 덜 시급하다. 그러니 나중에 하지 뭐. (몇시간, 몇일동안 방치)

 3.드디어 조사 시작 및 수정해 조치. 테스트 돌려서 문제있으면 그때가서.

 

나타난 결과: 이제 팀들은 모든 테스트 실패가 그저 단순한 실패일 뿐이라 가정하게 되고 결과에 대해서 무시하기 시작했습니다.

팀들이 테스트 시스템에 신뢰가 없다면 있을 필요도 없죠.

자동차 계기판에 엔진문제 표시가 나타났는데 나타날때도 있고, 안 나타날때도 있다고 생각해보세요. 아마 여러분들도 무시하기 시작할겁니다.

이런 유형의 습관화를 막기 위해 지금의 작업흐름은 즉시 실패한 테스트를 조사해서 테스트 조건의 불량인지 실제 버그인지를 알아냅니다.

 

문제된 테스트는 알기 쉽도록 전체 테스트군에서도 최상위 스테이징 테스트 스위트로 올라갑니다.

스테이징 스위트는 테스트를 테스트하기 위하여 일반 빌드 파이프 라인 외부에서 시행합니다.

개발자들에게 오류를 알리고 배포를 차단하게끔 하는 풀 스위트로 내려오기 전까지 새로 만들거나, 리팩토링된 테스트도 몇일간 스테이징되어 문제가 없는지 확인합니다.

 

저희는 상호간의 토론들과 발표, 그리고 팀간의 이메일들을 통해서 강건한 테스트와 강건한 빌드의 중요성을 지속적으로 강화하고 있습니다. 버그나 테스트에 관한 어떤 논의는 자동화를 널리 알리는 좋은 기회이고, 모든 팀에게 주기적으로 상기시켜 "반드시 지녀야할 자질" 로써의 정신을 갖게 합니다.

물론, 지속적으로 알리는것도 좋지만 올바른 균형을 유지해야합니다.

양 극단적으로 말하자면 아무도 메세지를 받지 않는 문제가 있다하면 원격 팀이 토론에 참가했을때 특별히 주의를 기울여야 하는것이죠.

 

이러한 문화적 자세는 모든 사람에게 천편일률적으로 맞는것은 아니기 때문에 각각의 팀들과 구성원들에게 맞춰 재단해 신중하게 해야합니다. 가장 중요한점은 어떠한 가정도, 어떠한 것도 당연하게 받아들여선 안된다는것입니다. 언제나 개선의 여지는 있기에, 저희는 이러한 시스템이 얼마나 매끄럽게 돌아가는지 지속적으로 확인하고 필요시에 조정하고 있습니다.

 

기술

대부분의 테스트 프레임워크나 테스트 툴은 상호교환이 가능하지만 더 중요한것은 파이프라인의 디자인 자체죠.

 

시간이 지나면서, 우리의 지속적인 딜리버리 파이프라인은 점점 더 광범위한 테스트 커버리지를 적용하는 다단계 프로세스로 진화했습니다. 초창기 테스트는 협소하게 맞춰져서, 한팀이 만들어낸 실수는 로컬라이즈 된 채로 남아있었죠. 다른팀들이 그들의 자체 개발을 할 수 있게요. 전체 프로젝트에 영향을 주거나 가로막는 단계는 한 팀의 자그마한 문제가 다른 팀들의 생산성을 해하지 못하도록  파이프라인의 뒤쪽에 있습니다. 저희는 클라이언트의 기능을 위해서 플러그인 기반의 아키텍처를 사용하는데 플러그인을 만들때에도 플러그인의 각각의 유닛들을 테스트하죠. 그 후, 따로 플러그인만 엔드-투-엔드(End-to end)테스트를 시행합니다. 마지막단계로, 배포하기전 클라이언트에서 잘 작동 되는지 포괄적인 테스트를 다시 시행합니다.

챔피언 선택을 예로 든다면, 가장 기초적인 테스트인 "챔피언아이콘이 있는지"부터 시작해 챔피언 교환, 와드스킨 선택과 같은 복잡한 테스트도 합니다.

 

부족한 테스트 파이프라인으로 인해서 일어나는 문제들이 있지만 여기에서 모두 나열 할 순 없고 아래와 같은것들을 저희가 다루었습니다.

 

  *테스트가 너무 느리다.

  *테스트가 릴리즈 프로세스에 어떤 직접적인 영향도 주지 못한다. 

  *실제 환경에선 테스트가 실행되지 않는다.

  *수동으로 제작되고 유지된 테스트 작업들은 버전제어가 되지 않아(Arn't version controlled) 유지관리에 있어 엄청난 부담이 된다.

  *기능에 변경사항이 있을때 테스트를 최신으로 유지하기가 어렵다.

 

리그오브레전드 클라이언트 업데이트의 아키텍처 덕택에 플러그인들을 각각 제작 할 수 있었습니다.

플러그인을 만드는 과정에는 그안에 들어있는 각각의 유닛의 테스트와 정적분석이 모두 포함되어 있스빈다.

오직 성공적으로 만들어진 플러그인들만이 통합클라이언트에 탑재될 후보가 되고 새 플러그인 빌드가 출시되면 LKG(Last Known Good)단계로 들어가게 됩니다.

이 단계에서 다른 플러그인들의 LKG버전을 확인해 새로 출시된 플러그인을 추가 한뒤, 임시 빌드를 만듭니다.

이 임시 빌드는 이제 기존의 플러그인들과 조화롭게 잘 운용 되고 있는지 확인을 위해 제한된 기능 테스트를 합니다.

플러그인이 LKG 테스트를 통과 하면 새 플러그인 버전이 LKG manifest(목록)에 업데이트 되고 새 LKG manifest가 완벽히 작동하는지 테스트합니다.

이러한 테스트는 스모크테스트와 전체 기능테스트 두가지로 나뉩니다.

스모크테스트는 최소 수준의 기능만을 확인하는것인 반면, 전체테스트는 자동적인 테스트내의 범위 안에서 많은 기능들을 테스트합니다.

각각의 테스트를 통과한 빌드들은 빌드 추적 데이터베이스에 등록됩니다.

 

도표:

빠른 처리와 편의를 위해

컨테이너된 Jenkins farm(https://www.youtube.com/watch?v=YViFZBoKqjg)을 이용해 (유닛테스트를 포함한) 프론트엔드 빌드 작업을 Docker(오픈소스 프로젝트)에서 시행합니다

클라이언트 자체는 윈도우즈나 OSX에서만 구동 되므로 다시말해 Docker에서 실제 기능 테스트를 시행할 수 없으므로 가상머신에서 윈도우즈와 OSX기능을 시험합니다.

즉 다시말해, 우리가 사용하는 모든 툴들이 크로스-플랫폼이어야 하고 우리의 모든 작업들은 윈도우즈와 OSX 버전 모두 필요 합니다.

비슷한 작업들을 쉽게 해결하기 위해 Jenkins Job DSL을 이용해 파이프라인을 계획적으로 정의했습니다.

우리 작업은 하기의 자료처럼 JSON(JavaScript Object Notification)과 같습니다.

 

 

초창기엔 기능적인 테스트를 하면서 책임의식에 관해 어려움이 있었습니다.

기능테스트가 완전히 별도의 저장소에 저장하는 동안, 팀들은 대부분 플러그인 저장소에서 개발에 착수하다보니 팀들이 그들의 플러그인의 기능을 변경하다 테스트를 업데이트 하는것을 까쳐먹었습니다.

그래서 개발 도중 테스트에 접근 할 수 있도록 거대한 한덩어리와 같은 모놀리식 저장소를 잘게 나눠 각각의 플러그인 저장소들로 만들었습니다.

이제 테스트 장치로 "테스트 가능"기능이 생겨서 플러그인 manifest라는 거대한 나무속에서 주어진 플러그인들을 위한 적절한 테스트들을 다운로드 합니다.

 

단순히 문제를 파악하고 해결하려는 시도는 좋은 파이프라인을 설계 하는데 많은 도움이 됩니다.

첫술에 배부를 수 없듯, 모든 기능을 갖춘 파이프라인을 처음부터 구축하기란 거의 불가능합니다.   

-초창기 시스템은 많은 작업을 요하지 않는 수동으로 만든 간단한 작업들 뿐이었지만, 두가지 원칙을 가지고 파이프라인을 반복하고 개선하다보니 현재의 상태에 오르게 되었습니다. 첫번째는 Job DSL을 초기부터 사용했고, 두번째는 모든 작업을 모듈식으로 처리했습니다. 대개 모든 작업을 할 때 동일한 매개 변수를 사용하기 때문에 필요하다면 변환 할 수 있습니다.

작업들을 다시 고치는것(Rewiring)이 쉽다면 한 설계에 종속되어 우물안 개구리가 되기 보다 지속적으로 발전 할 수 있는 힘을 가질 수 있습니다.

 

개선계획

팀들과 파이프라인은 계속해 진화합니다. 다음은 저희가 해야하는 업무 리스트입니다.

 

테스트 속도 향상

현재 저희는 다중 큐크(Multi-Cuke)를 사용해 주어진 테스트 작업을 병렬화 하고 있습니다.

여전히 단일 빌드 노드 능력으로만 제한하고있고 현재까지는 수직적인 변경만 하고 있습니다.

-그 다음 단계는 여러 노드들로 테스트 스위트를 병렬화 하는것입니다.

이러한 방법은 테스트 수행 시간을 우리가 가진 가장 느린 테스트 시나리오에 좌우되게 할 수 있습니다.

종속적인 설치와 결과물 획득 및 추출단계의 속도면에서 개선의 여지도 충분히 있습니다.  

 

배포하고 난뒤 테스트

리그오브레전드 릴리싱 팀이 라이브서버에 새 빌드를 배포할 때마다, 먼저 배포 해버리고 몇년동안 수작업으로 스모크 테스트를 해왔습니다. 클라이언트 테스트를 위한 완벽한 자동화가 구현 되면서 배포 후, 자동화가 이론적으로 가능해졌습니다.

이것은 일관성을 향상시키고 릴리스 팀을 지루한 작업으로부터 구할 수 있단 점에서 고무적인 일이죠. 

해결해야 할 몇가지 작은 기술적인 세부사항이 있습니다. 예를 들면 라이브서버에서 소환사들에게 영향을 주지 않으면서 안전하게 테스트 계정을 만들 수 있을까하는거요.

 

로컬 테스트를 맡기기

자동화 테스트 일부는 많은 클라이언트들을 병렬로 실행시키고 많은 데이터와 시간등을 소비해야하는 자원 집약적인 작업입니다.

현재 우리는 개발자들에게 변경사항들을 적용하기 앞서 테스트를 국지적으로 따로 실행시키라고 요청하고 있으나, 이말인 즉슨 테스트 동안엔 개발자들이 본인들 워크스테이션을 거의 사용을 못한다는것입니다. 그래서 우리는 탄력적으로 로컬 테스트를 맡기게 하려고 합니다.  

개발자가 로컬 변경사항을 테스트 하려하면, 우리가 AWS(클라우드)나 데이터센터에 있는 테스트 기계로 변경점들을 보낼 수 있습니다. 개발자 대신해 테스트를 돌려보고 결과를 알려주는 것이죠. 

 

결론

지금까지 이 글에서 설명한 시스템을 구축하기까지 약 1년이 넘는 시간이 걸렸고, 여전히 진화 중입니다.

수많은 시행착오를 겪으며 막다른 길이 보일때마다 다른길을 찾아 가야했습니다. 확실히 쉬운 일은 아니었죠.

LKG시스템을 처음 시작 할 때만 해도 혼돈, 파괴, 망가였지만, 실패는 다른말로 포기해가 아닙니다. 

실패하면 언제나 되짚어보고, 다른것들을 건드려보고, 다시 시도하면 되는 일입니다.

특히 가장 중요한것은, 단일 솔루션이 모든것을 해결해주진 않습니다. 어떤 한 작업에서 제대로 해결했다고 다른 작업에서도 똑같으리라는 보장이 없죠. 그러나 끈기있게 효과적인 테스트 파이프라인과 문화를 갖는 노력은 중요하며 오랜시간이 걸리는 프로젝트에서도 달성 가능한 요소중 하나입니다.

저는 이러한 저희의 여정이 비슷한 문제에 매달려 있는 분들에게 도움이 되었으면 하고, 이에 관해 더 깊은 대화를 나눴으면 좋겠네요.

 

 

발로 번역해서 의역 심하고 오역도 좀 있습니다. 생각보다 머리로는 무슨 말 하는지는 대강 알겠는데 다시 풀어 쓰자니 어렵군요.

병목현상인가..