개요

이번 포스팅은 제목에서 언급한 Fit Test Framework에 대해 얘기하고자 합니다.

하지만 기술 그 자체에 대한 심도있는 이야기는 아니고 멜론에서 당면한 문제와 이에 대한 해결방법에서 기술을 어떻게 접목했는지가 오히려 하고 싶은 주제인듯 합니다.

편의상 존칭은 생략합니다.

결론 요약

  • Fit Test Framework는 기획자 <-> 개발자간 테스트 자동화를 함께 수행하기 위한 좋은 방법이다.
  • 멜론의 Case 뿐만 아니라 어떤 회사든 TDD관점에서 활용될 수 있을것 같아 공유한다.
  • 문제를 정의하고, 해결 가능한 기술을 선정하고, 적용하는 과정이 중요한것 같다는 의견이다.

===============================================================================

사건의 발단 : 멜론 스마트-i 서비스 런칭

아래의 그림에서 보듯이 멜론에서 AI를 이용하여 음성이나 채팅으로 노래를 검색하거나 재생할 수 있는 서비스가 런칭되었다.

UI/UX가 명확한 서비스가 아닌 자연어를 입력받아 처리하는 것이다 보니 테스트 커버리지가 매우 넓은게 특징이다.

이슈발생 : 멜론 AI의 회귀 테스트 방법 고민

여기서 이슈가 발생한 것은 아래와 같은 상황이다.

  • 서비스 오픈을 준비하면서도 다양한 “자연어 쿼리”에 대해 테스트를 수행하는게 기획자들에게는 고통이었다.
    하지만 기획자들에게 품질에 대한 확보의 Role이 있다.

  • 품질을 튜닝하는 과정에서 각각의 케이스를 해결하는 과정에서 Side Effect가 종종 발생하였다.
    예를 들어 “지디&탑 노래 틀어줘”를 맞추는 과정에서 “지디 노래 틀어줘”의 품질이 이상해지는 케이스가 발생하였다.

  • 개발자들은 오픈을 준비하며 위의 이슈들에 대한 경험이 쌓이다 보니 중요한 몇몇 케이스에 대해서는 유닛테스트를 만들어두었다.
    하지만 Coverage가 낮아 서비스 오픈에 큰 도움이 되지는 못했다.

여기서 해결방안에 대한 단초가 된 것은 아래의 대화이다.

여기서 중요한 점은 Fit Test Framework를 도입하자는 결정을 바로 한것이 아니라는 점이다.

지금의 이슈와 해결책이 Fit Test Framework가 얘기하는것과 닮아 있다는 것을 제시하였다는 점이다.

Fit Test를 몰랐을 때는 막연히 위의 대화의 흐름으로 생각 하였을 때 TC 자동화를 구현하고 이를 기획자에게 좋은 방식으로 제공해 주면 좋겠다는데 그쳐있었는데 Fit Test에 대해 알아볼 기회가 생겼다.

해결방안 고민 : Fit Test Framework에 공부

Fit Test 책을 한번 빠르게 살펴보았다.
(들은 것에 의하면 예전에 한번 유행했던 기술이라는데 그 시대가 아니라 사실 경험해보진 못했다.)

살펴본 이후 결국 Fit Test Framework가 이야기 하는 기본 개념은 아래와 같았다.
Excel Sheet로 TC를 정의하고 하나의 Row가 하나의 TC로 동작하게 기획자에게 제공해주는 것이 핵심인듯 하다.

즉, 두 담당자의 역할을 명확하게 분리하여 정의하는데 장점이 있는듯 하다.

바꿔 얘기하면 각자가 잘할수 있고 하고싶은 것만 아래와 같이 수행할 수 있다는 뜻이다.

따라서 이 시점에서 현재의 이슈와 해결 방안으로 매우 적절해 보인다고 판단하였다.

기술도입 결정 : Fit Test Framework 적용 아키텍쳐 설계

Fit Test에서는 Conecept만 취하고 실제 기술의 조합은 직접 설계하였다.
왜냐하면 Fit Test의 장점인 Concept에 대해서는 명확하게 이해했다고 판단했고 이후 기술 조합은 내부 조직의 실정을 고려하여 현실적으로 가장 효율적인 방향이 좋다고 생각했기 때문이다.

세부 기술 Stack은 아래와 같다.

  • 구글 시트
    • 기획자들이 가장 손쉽게 접근/편집 할 수 있다.
    • 자동 저장되는 개념이니 형상관리 면에서도 수월함이 있다.
    • 파일을 주고받아 여러 사본을 생성하는 것 보다 원본이 1벌인 것이 관리상 수월하다.
  • 젠킨스
    • CI를 활용하여 빌드도 많이하지만 TC도 수행을 많이 할 수 있고 Job실행/Tracking/Cron이 가능하여 도입하였다.
    • 이미 내부 인프라가 다 갖추어져 있는것도 장점이다.
    • 기획자에게 웹에서 접속해서 “Build Now”만 누르면 된다는 커뮤니케이션이 어렵지 않아보였다.
  • TC 자동화 플랫폼
    • 내부에서 가장 익숙한 기술인 Java를 활용하여 구현하였다.

기술구현 : 스마트-i 서비스를 Fit Test Framework로 돌려보자.

멜론에서는 실제 어떻게 구현되어 사용하는지 한번 살펴보자.

먼저 구글시트로 TC를 정의한다. 세부적인 조건은 아래와 같다.

  • 하나의 행이 하나의 TC로 동작한다.
  • 스마트-i서비스에서 회귀 테스트를 하고 싶은 query를 행별로 입력한다.
  • 세부적으로 각각의 TC의 세부조건을 설정한다.
    • 카드가 몇장 나와야 하는지
    • 특정 아티스트는 꼭 포함이 되어야 하는지
    • 특정 아티스트는 나오면 안되는지

기획자는 이후 젠킨스에서 Build Now버튼으로 TC를 실행한다.

조금 불편할 수 있지만 최신 콘솔창을 열어달라고 기획자분께 부탁을 했다.

콘솔에 포함된 레포트 링크를 클릭한다.

아래와 같이 세부 결과 요약과 품질 Tracking용 세부 정보들이 노출된다.

도입결과 : 이제 쓰기 시작하려 하고 있음

포스팅을 하는 시점에서야 쓰기 시작해서 아직까지는 효과에 대해 공유를 못하는게 솔직한 공유이다.

하지만 아마도 수천개에 달하는 이미 확보하고 있는 기획자들의 예비 TC를 고려했을때 각 담당자들이 만족하는 결과가 나올듯 하다.

개선 포인트

  • 알람기능
    현재의 TC 리포트 기능만으로는 눈으로 봐야만 실패여부를 알 수 있다. 이부분을 CI와 연동해도 실패시 알람이 발생하는 기능이 개발되면 좋을 듯 하다.

  • 사용자 로그 반자동 Regression 추가
    아래 그림과 같이 기획자들이 확보한 TC로만 Regression하는 것이 아니라 사용자가 입력한 쿼리 중 실패한 내역이라든지 성공 쿼리 중에서도 일부 쿼리라든지 이런 내용을 반자동으로 추가할수 있게 제공이 되면 좋을듯 하다.
    (반자동인 이유는 무분별한 쿼리 추가로 Regression Test가 망가지는것을 대비하기위해)