들어가며

엔라이즈의 개발 팀은 총 4명으로 구성되어 있으며, 그 중 한 명이 Android, 한 명이 iOS 클라이언트를 담당합니다. 우리는 2019년 한 해 WIPPY 를 OS 별로 70여회 이상 성공적으로 배포 할 수 있었습니다. 기간으로 나누어 본다면 1주일에 1회 이상 배포를 한 셈입니다.

WIPPY 는 Swift, Kotlin 으로 작성된 완전한 네이티브 앱¹이며, 지난 1년 중 90분 이상 초과 근무를 한 날은 10일 미만입니다. 안정성 측면에서 보자면 최근 90일 기준 비정상 종료 미발생 통계 평균 99.4% 를 유지하고 있습니다. 또한 엔라이즈는 제품의 품질을 측정/분석 하는 QA 팀을 별도로 두고 있지 않습니다.

오늘은 우리가 이렇게 움직일 수 있는 노하우들 중 하나인 Smoke Testing 에 대해 이야기 하려 합니다.

Smoke Testing 이란

Smoke Testing 은 예비 테스트라고도 하며, 제품의 핵심 기능에 대한 동작 여부를 체크하는 것을 주 목적으로 합니다. 하드웨어의 전원을 연결 하였을 때 하드웨어에서 연기가 발생하지 않으면 테스트를 통과했다고 보는 데서 유래한 용어입니다². Smoke Testing 에 대한 자세한 내용은 이곳을 참고하시기 바랍니다.

기존 테스트의 문제점

Smoke Testing 을 도입하기 이전 엔라이즈의 제품 팀은 2014년 말부터 약 2년간 회귀 테스팅(Regression Testing) 을 도입하여 운용 중이었습니다. 회귀 테스팅을 진행하며 발생하던 문제점은 여러 가지가 있었는데, 다음과 같았습니다.

• 회귀 오류 사례가 축적될 수록 테스트에 오랜 시간이 걸렸습니다. 이는 더욱 빠른 제품 출시 주기를 통해 다양한 가설을 시험하고자 하는 우리의 행동에 큰 저항을 만들게 되었습니다.
• 테스트 자체가 서비스의 안정성을 만족 시켜주지 않았습니다. 즉 회귀 오류의 검출이 회귀 오류 방지를 위한 노력으로 이어지지 않고 불안정한 기능은 계속 불안정한 상황이 이어졌습니다.
• 테스트 시간이 오래 걸리게 되자 작은 기능의 수정이 있거나 빠른 배포가 필요할 때 회귀 테스팅을 생략하는 경우가 발생 하였습니다. 배포 절차(Distributed processing) 를 무시하는 경우가 발생한다는 것 자체가 현재 배포 절차에 큰 문제가 있다는 것은 암시하는 것이기도 합니다.
• 상대적으로 중요도가 떨어지는 사소한 회귀 오류로 인해 테스트를 진행하는 사람과 이것을 수정해야 하는 사람 모두 높은 피로감을 느끼게 되었습니다.

제품에 대한 테스트가 제품 출시에 큰 영향을 끼칠 뿐 아니라, 제품 안정성 측면에도 큰 도움이 되지 않는다면 수행하는 방법이 잘못 되었거나, 방법을 수행하는 사람의 문제로 귀결될 것입니다. 저는 이 문제를 수행 방법의 문제로 판단하고 어떤 부분을 개선해야 할지 고민을 하게 되었습니다. 제가 생각하는 이상적인 테스트는 다음과 같은 조건을 충족할 수 있어야 합니다.

• 테스트 소요 시간이 짧아야 한다. 길어도 2시간 이내에 완료되어야 한다.
• 가능하면 자동화 되어 사람의 개입이 최소화 되어야 한다.
• 월요일에서 금요일 사이 어느 시기라도 개발자가 원하는 시간에 배포를 할 수 있는 안정감을 줄 수 있어야 한다.
• 테스트를 진행하는 사람과 테스트 결과를 받는 사람 모두가 받는 피로도가 최소화 되어야 한다.

테스트에 대한 고민

많은 고민을 하다 이콜레모의 박영록 대표님께 자문을 구하기로 결정 하였습니다. 처음에는 회귀 테스팅을 자동화 하는 방법에 대한 고민으로 시작 하였으나 논의를 하다 보니 회귀 테스팅의 필요성 자체에 대한 검토로 변하게 되었습니다. 이유는 다음과 같습니다.

1. 회귀 테스팅은 케이스가 수집될 수록 생산성 저하를 피할 수 없다.

어찌 보면 당연한 것입니다. 만일 그럼에도 불구하고 회귀 테스팅을 도입해야 한다면 어떻게 해야 할까요? 그에 맞추어 테스트 인력이 늘어나거나 테스트 자동화 등의 작업을 필요로 하게 될 것입니다. 여기까지 생각이 미친다면 우리가 서비스 하는 제품이 과연 회귀 테스팅을 필요로 하는 것인가? 에 대한 질문까지 던져보게 됩니다. 일반적으로 회귀 테스팅이 효력을 제대로 발휘하기 위해서는 다음과 같은 조건이 충족되어야 합니다.

1. 현재의 소프트웨어가 이미 충분히 안정화 되어 결함이 거의 없는 상태일 것
2. 기능 추가나 개선, 수정 작업이 자주 일어나지 않을 것

우리가 서비스 하는 WIPPY 와 MOCI 는 1, 2 두 가지 모두 충족하지 못하는 제품입니다. 제품은 여전히 기능 추가와 개선 작업을 필요로 하고 있으며, 이로 인해 야기되는 서비스의 불안정함은 어찌 보면 필연적 결과일 수 있습니다. WIPPY 와 MOCI 가 사소한 오류나 장애로 인해 치명적인 문제를 일으키는 것이 아니라면 - 예를 들어 인터넷 뱅킹 앱은 사소한 오류가 치명적인 문제를 야기할 수 있을 것입니다 - 회귀 테스팅 그 자체가 엔라이즈 제품 팀의 기민함을 떨어트리는 원인일 수 있습니다.

실제로 1975년에 출간된 명저 “맨먼스 미신” 에서 프레더릭 브룩스는 테스트에 대해 다음과 같이 이야기 하며 회귀 테스팅은 “이상적 환경” 과 “많은 비용"을 필요로 할 것이라 하였습니다.

“새로운 버그를 발견한 결과로, 프로그램 유지 관리는 다른 어떤 프로그램보다도 작성된 구문 당 훨씬 많은 시스템 테스트를 거쳐야 한다. 이론적으로는 수정할 때 마다 이전에 시스템 시험에 사용되었던 모든 테스트를 해봐야 눈에 잘 보이지 않는 곳에 다른 손상이 가해지는 것을 막을 수 있다. 실제로 이러한 회귀 테스트(regression testing)는 이론적으로 이상에 거의 근접해야 하고, 당연히 비용도 많이 든다."³

2. 큰 문제는 발생하지 않게 하자, 작은 문제가 발생하면 빨리 알아차릴 수 있게 하자.

만일 어느 정도 사소한 제품의 결함이 치명적인 사용자 경험 저하로 이어지지 않는 서비스라면

“어떤 문제도 발생하지 않게 하는 것”

이라는 관점 보다는

“큰 문제만 일어나지 않게 하되, 작은 문제는 적당한 수준에서 허용하되 기민하게 대응하는 것”

이 사용자의 제품 생애 주기 동안 경험하는 결함을 낮출 수 있을 것이라는 결론에 이르게 되었습니다. 여기까지 논의가 되었을 때, 우리가 서비스하는 제품에 회귀 테스팅은 유용하지 않다는 판단을 하게 되었고 Smoke Testing 을 도입해 보는 것으로 최종적인 결정을 하게 됩니다.

Smoke Testing 의 도입

Smoke Testing 을 도입하기로 결정한 이후 박영록 대표님의 주도 하에 하루 정도의 시간이 소요되는 워크숍을 진행 하였습니다. Smoke Testing 의 기본 요소는 다음 조건을 충족할 수 있어야 합니다.

• 어떤 구성원이라도 Smoke Testing 을 할 수 있어야 한다.
• 테스트에 소요되는 시간은 10분 이내어야 한다.
• 테스트는 팀 구성원이 생각하는 핵심 기능들을 골고루 검증할 수 있어야 한다.

위와 같은 원칙 하에 MOCI 에 대한 Smoke Testing 을 위한 준비를 진행 하였습니다. 다음 과정으로 진행 되었습니다.

1. 팀원들과 함께 서비스의 모든 기능들을 나열 합니다.
2. 이번엔 나열된 기능들을 하나씩 다 체크하며 해당 기능이 정상 동작하지 않을 때 치명적인지, 아닌지 여부를 함께 정합니다.
3. 동작하지 않을 때 치명적일 수 있는 기능들만 모아서 테스트 할 방법을 정리합니다.
4. 테스트 방법까지 구성이 되면 팀원들과 함께 실습을 진행 합니다.
5. 실습이 끝나면 팀원들과 회고를 진행합니다. 회고 때 소요시간과, 체감 신뢰도 및 느낀 점에 대해 이야기를 합니다. 가능하다면 이 부분은 추후 지속적으로 모니터링 할 수 있으면 좋습니다.

MOCI 의 Smoke Testing 실습을 통한 팀원들의 느낌이 전체적으로 나쁘지 않았으며, 우리는 회귀 테스팅을 중단하고 Smoke Testing 으로 테스트 방법을 완전히 바꾸어 배포를 하기로 결정 하였습니다.

도입 후 달라진 점

Smoke Testing 후 팀원들이 느낀 달라진 점은 다음과 같았습니다.

• 회귀 테스팅을 진행할 때 보다 훨씬 빠른 시간 안에 테스트가 가능해져 심리적 부담감이 줄어 들었습니다.
• 회귀 테스팅의 결과물을 받을 때의 스트레스가 사라졌습니다.
• 테스트 초기의 체감 신뢰도는 평균 65% 정도였습니다. 이는 테스트가 반복될 수록 조금씩 향상되어 현재 팀원들이 느끼는 신뢰도는 85% 정도입니다.
• 팀원 개개인이 스스로 테스트를 진행하게 되면서 불필요한 업무 절차가 사라졌습니다.
• 길어야 20 분 내외가 소요되기에 테스트 자체에 대한 부담감이 거의 사라졌습니다.

결과적으로 더욱 빠른 개발과, 기민한 대응이 가능해졌습니다. 재미있는 점은 Smoke Testing 을 도입한 후 지금까지 치명적인 장애가 단 한 번도 발생하지 않았다는 것입니다. 이는 이후 출시한 WIPPY 에도 마찬가지로 적용되어 있으며, 같은 방법으로 테스트를 진행하고 있습니다. 이는 우리가 개선한 것들 중 하나라고 생각하며, 우리는 더욱 기민해졌다고 생각합니다.

결론

테스트라는 주제에 대해 우리가 경험한 사례는 이 정도입니다. 당연하지만 우리는 완전한 테스트 절차를 구축하였다고 생각하지 않습니다. 다만 현재 규모에서 기민하게 개발을 진행하면서도 제품의 안정성을 유지하는 방법 으로써 나쁘지 않은 선택이라고 생각합니다. 만일 팀의 규모가 더 커지고, 제품의 복잡도가 더욱 증가할 경우 이 방법으로 한계가 올 수도 있다고 생각하며, 그 때가 되면 우리는 더 흥미로운 방법으로 테스트 절차를 개선하게 될 것이라 생각합니다. 우리는 우리가 개선하는 능력을 개선할 수 있는⁴ 팀이라고 생각합니다.

우리의 테스트에 관한 이야기가 흥미롭다면, 그리고 테스트를 개선할 수 있는 의견이 있다면 경청 하겠습니다. 또한 우리는 우리 팀에 흥미를 가진 개발자를 찾고 있습니다! 관심 있는 분들의 지원을 기다립니다. :)

감사합니다.