빠르고 안정적인 앱 배포의 노하우(1) - Smoke Testing

엔라이즈 개발팀이 2년간 운영하던 회귀 테스트를 접고 스모크 테스트로 바꾼 기록이다. 왜 회귀 테스트가 자기네 제품에 맞지 않는다고 판단했는지, 스모크 테스트를 어떤 절차로 도입했는지, 그 뒤 무엇이 달라졌는지를 순서대로 짚는다. 개발자 4명에 별도 QA 팀 없이 앱을 연 70회 이상 배포하는 팀의 이야기다.

핵심 포인트

회귀 테스트는 사례가 쌓일수록 시간이 늘어 빠른 출시 주기와 충돌한다.
테스트 시간이 길어지자 급할 때 절차를 건너뛰는 일이 생겼는데 이것 자체가 절차에 문제가 있다는 신호다.
회귀 테스트가 효력을 내려면 소프트웨어가 이미 안정적이고 기능 변경이 잦지 않아야 하는데 둘 다 해당하지 않았다.
그래서 모든 문제를 막는 대신 큰 문제만 막고 작은 문제는 빠르게 대응하는 쪽으로 방향을 바꿨다.
스모크 테스트의 조건은 누구나 할 수 있을 것, 10분 이내일 것, 핵심 기능을 골고루 검증할 것이다.
도입 후 체감 신뢰도가 평균 65%에서 85%로 올랐고 치명적 장애는 한 번도 없었다.

상세 정리

팀 상황: 개발자 4명 중 안드로이드와 iOS가 각각 한 명이고, 2019년 한 해 OS별로 70회 이상 배포해 주 1회를 넘겼다.
성과 지표: 90분 이상 초과 근무를 한 날이 연 10일 미만이고 최근 90일 기준 비정상 종료 미발생률이 평균 99.4%였으며 별도 QA 팀은 두지 않는다.
회귀 테스트의 문제 1: 사례가 축적될수록 시간이 오래 걸려 가설을 빠르게 시험하려는 움직임에 저항이 됐다.
회귀 테스트의 문제 2: 오류를 찾아내는 것이 오류를 막는 노력으로 이어지지 않아 불안정한 기능은 계속 불안정했다.
회귀 테스트의 문제 3: 작은 수정이나 급한 배포에서 절차를 생략하는 일이 생겼다.
회귀 테스트의 문제 4: 중요도가 낮은 오류 때문에 테스트하는 사람과 고치는 사람 모두 피로가 쌓였다.
이상적인 조건: 2시간 이내로 끝날 것, 가능하면 자동화될 것, 주중 아무 때나 배포할 수 있는 안정감을 줄 것, 양쪽 모두의 피로가 최소일 것으로 정리했다.
논의의 전환: 처음에는 회귀 테스트를 자동화하는 방향으로 시작했지만 외부 자문을 거치며 회귀 테스트의 필요성 자체를 검토하는 쪽으로 바뀌었다.
필요 조건 점검: 회귀 테스트가 제 효력을 내려면 이미 충분히 안정화돼 결함이 거의 없고 기능 추가나 수정이 잦지 않아야 하는데, 두 제품 모두 해당하지 않았다.
판단 근거: 사소한 오류가 치명적 문제로 이어지는 서비스가 아니라면 회귀 테스트가 오히려 팀의 기민함을 떨어뜨리는 원인일 수 있다고 봤다. 회귀 테스트가 이상적 환경과 많은 비용을 요구한다는 맨먼스 미신의 대목을 근거로 인용한다.
방향 전환: 어떤 문제도 없게 하기보다 큰 문제만 막고 작은 문제는 허용하되 기민하게 대응하는 편이 생애 주기 전체의 결함 경험을 줄인다는 결론에 이르렀다.
스모크 테스트의 유래: 하드웨어에 전원을 넣었을 때 연기가 나지 않으면 통과로 보던 데서 온 용어다.
도입 절차: 하루짜리 워크숍에서 서비스의 모든 기능을 나열하고, 동작하지 않을 때 치명적인지 여부를 함께 정한 뒤, 치명적인 것만 모아 테스트 방법을 정리하고 실습과 회고를 진행했다.
회고 항목: 소요 시간과 체감 신뢰도, 느낀 점을 이야기하고 가능하면 이후에도 지속 모니터링하기를 권한다.
달라진 점 1: 테스트가 빨라져 심리적 부담이 줄고 결과를 받을 때의 스트레스가 사라졌다.
달라진 점 2: 체감 신뢰도가 초기 평균 65%에서 반복될수록 올라 85% 수준이 됐다.
달라진 점 3: 각자 스스로 테스트하게 되면서 불필요한 업무 절차가 사라졌고 길어야 20분 내외라 부담이 거의 없어졌다.
남긴 단서: 팀 규모가 커지고 제품 복잡도가 올라가면 이 방법에도 한계가 올 수 있다고 스스로 밝힌다.