안녕하세요. LINE에서 다양한 서비스의 QA 역할을 수행하고 있는 채수광입니다. LINE뿐 아니라 LINE 외부의 다른 QA 분들과도 소통을 넓히기 위해 다양한 채널로 찾아뵙고 있으며, 앞으로 LINE Engineering 블로그를 통해서도 많은 분들과 다양한 QA 관련 주제로 소통할 수 있기를 희망합니다. 이번 글에서는 QA가 'Quality Assurance'에서 'Quality Assistance', 'Quality Advocator'로 변화하게 된 과정을 살펴보면서, 'Shift-left'와 'Shift-right' 접근 방법을 통해 어떻게 더 나은 품질을 확보할 수 있는지 공유하겠습니다.

QA(Quality Assurance)는 왜 품질을 보증할 수 없을까?

전통적으로는 품질의 기준을 만들고 그 기준을 충족하는 제품만 릴리스하는 방식으로 품질을 보증했습니다. 하지만 시대의 흐름에 따라 제품을 더 자주, 더 높은 수준으로 제공해야 하는 상황에 직면했고 이와 같은 모순적인 목표를 이전과 같은 방식으로는 달성하기 어려웠습니다.  실제로 수많은 기기가 활성화 상태이고 거의 1만 8천 개에 달하는 다양한 기기 모델을 지원하고 있는 LINE의 릴리스 주기는 2주입니다. 

이와 같은 상황에서는 테스트 케이스를 통과한 제품일지라도 언제든지 사용자가 실제 사용하는 프로덕션 환경에서 기본 기능과 관련된 버그가 발생할 수 있으며, 신규 기능에 대한 사용자의 불만에 대응하는 것도 어렵습니다. 아래는 2022년 상반기에 LINE Android 사용자가 남긴 리뷰를 분석해 산출한 부정적인 키워드 중 상위 6개를 가져온 것입니다.

이제 전통적인 품질 보증 방식으로는 더 이상 대응하기 어려워졌습니다. 더 자주 릴리스하면서 더 높은 품질을 달성하려면 개발 조직이 보다 민첩하게 움직일 수 밖에 없으며, QA 역시 이와 같은 개발 프로세스 변화에 맞춰 보다 민첩하게 움직이기 위해서 여러 가지 방안을 고안해 내기 시작했습니다. 이런 움직임 속에서 품질 보증의 문제는 더 이상 QA만의 문제가 아니라 개발 팀 전체, 더 나아가 프로젝트 전체의 문제로 인식됐고, 이에 따라 QA의 역할도 품질을 보증(assurance)하는 것에서 지원(assistance)하는 역할로 변화했습니다. 

QA(Quality Assurance)가 아닌 QA(Quality Assistance)로서 새롭게 시도해 볼 만한 것들

QA가 품질을 지원하는 역할로 변화하면 개발 프로세스에도 많은 변화가 발생합니다. 이 글에서는 이런 변화 중 전체 프로세스 관점에서의 접근 방법 위주로 설명하겠습니다.

그동안 QA(Quality Assurance)가 수행해 왔던 역할

먼저 그동안 QA(Quality Assurance)가 어떤 역할을 수행해 왔는지 알아보겠습니다. 아래는 많은 분들에게 익숙할 소프트웨어 개발 프로세스를 나타낸 그림입니다. 아주 단순하게 표현한 것으로 실제 현업에서는 필요에 따라 더 세분화하거나 좀 더 복잡한 형태로 구성할 수도 있습니다.

여기서 주의해야 할 점은, 흔히 QA 활동을 테스트 활동과 동일시해서 'QA 단계 = 테스트 단계'로 정의하지만 '테스트는 QA 활동 중의 하나'라는 것이 올바른 정의라는 것입니다. 

이 단계에서 QA는 기본적으로 매뉴얼 테스트와 함께 기능 테스트와 비기능 테스트를 수행합니다.

만약 QA의 역량이 받쳐준다면 탐색적(exploratory) 테스트나 자동화된 테스트 방법도 적용해 볼 수 있습니다. 물론 자동화된 테스트가 매뉴얼 테스트보다 항상 나은 것은 아닙니다. 역량을 갖춘 QA는 프로젝트와 제품의 상황에 맞게 정확하게 판단해 효율적인 테스트 방안을 제시할 수 있어야 합니다. 

이제 QA를 조금 더 넓은 의미인 QA(Quality Assistance)로 확장하기 위해서 'Shift-left'와 'Shift-right', 두 가지 접근 방법을 적용 사례와 함께 살펴보겠습니다.

Shift-left 접근 방법

Shift-left는 말 그대로 QA의 역할을 개발 프로세스에서 '왼쪽으로 이동'하는 것입니다. 아래는 결함이 발생한 단계와 발생한 결함을 수정하기 위한 비용을 나타낸 그래프입니다. 이 그래프를 보면 많은 결함이 코딩 단계에서 주입되고, 발견이 늦으면 늦을수록 결함을 수정하기 위한 비용이 크게 증가한다는 것을 알 수 있습니다. 이는 왼쪽으로 이동해야 하는 배경을 보다 명확히 나타냅니다. 

Shift-left는 테스트를 가능한 한 빨리 진행해 조기에 결함을 찾아내는 것이 목적입니다. 결함을 조기에 발견하는 데에는 단위 테스트와 컴포넌트 테스트, API 테스트, 성능 테스트가 효과적이며 이를 가능하게 만드는 핵심 요소는 자동화된 테스트입니다. QA는 자동화된 테스트를 통해서 조기에 개발 단계에 참여해 개발 과정에서 지속적인 테스트가 가능하게 만듭니다.

이를 통해 QA의 활동 범위를 아래와 같이 왼쪽으로 더 넓힐 수 있습니다.

Shift-left 접근 방법은 단순히 테스트 관점에서의 접근 방법만을 의미하지는 않습니다. 아래 그래프는 Shift-left 모델과 전통적인 품질 모델을 비교한 그래프입니다. 

이 그래프에서 우리가 주목해야 할 점은 Shift-left 모델에서는 개발 및 빌드 영역도 중요하지만 그에 못지않게 기획 및 설계 영역도 중요하다는 점입니다. 따라서 품질 관점에서의 Shift-left는 아래 그림과 같이 개발 단계를 넘어 보다 더 왼쪽으로 이동해야 합니다.

이제 QA의 역할을 기획 단계까지 확대했습니다. 드디어 진정한 의미의 Shift-left에 대해서 이야기해 볼 수 있게 된 것입니다. 기획 단계까지 QA 역할을 확장한다는 것은 단순하게 기획 사양을 확인하는 수준을 의미하지 않습니다. 비즈니스 관점에서 프로젝트 초기부터 프로젝트의 목적과 방향을 함께 검토하며, 제품의 기능과 설계를 각 단계별로 검증하는 것을 의미합니다. QA는 기획 단계에서 중요한 의사 결정에 참여해 프로젝트와 제품에 기여할 수 있어야 하고, 개발 팀과 밀접하게 협업하면서 제품의 품질을 높이는 촉매제가 돼야 합니다. 또한 가능한 한 빨리 프로젝트에서 벌어지는 여러 토론에 참여해 프로젝트의 각 단계에서 위험을 식별하고 사전에 그 영향을 완화할 수 있어야 합니다. 

LINE 적용 사례

그렇다면 실제로 어떻게 업무에 적용해 볼 수 있을까요? LINE에서는 먼저 기획 단계에서의 동료 검토 프로세스를 개선해 QA가 적극적으로 참여할 수 있도록 만들었습니다. 이때 QA의 역할은 단순히 사양을 확인하는 것이 아닙니다. 중요한 의사결정의 순간에 품질 관점에서 좋은 질문을 할 수 있어야 합니다. 

AS-IS: 기획 단계 이후에 참여하는 QA 형태
TO-BE: 프로젝트 초기부터 활동하는 QA 형태

개발 단계에서는 테스트를 같이 리뷰하고 설계함으로써 예측 가능한 테스트를 제공하고 테스트의 투명성을 높였습니다. 이를 통해 개발자는 테스트가 앞으로 어떻게 진행될 것인지 알 수 있으며, 코딩 전에 누락된 케이스를 파악하고 예외 처리하는 부분에 조금 더 신경을 쓸 수 있습니다. QA 역시 개발 설계를 잘 이해하게 되면서 테스트 커버리지를 실질적으로 높일 수 있는 테스트 케이스를 확보할 수 있습니다. 아래는 공유 모듈 리팩토링 개발 단계에서 개발자와 함께 리뷰하고 설계했던 테스트 계획의 일부입니다. 

테스트 단계에서는 작은 규모의 단위 테스트에서 큰 규모의 통합 테스트로 점차 규모를 키워가며 테스트를 진행합니다. 여기서 작은 규모의 단위 테스트는 개발자가 가장 잘할 수 있는 테스트 중 하나이며, 모든 자동화 테스트의 기본이 됩니다. LINE에서는 개발 프로세스 컴플라이언스에서 이 테스트의 작성 책임을 개발자로 규정하고 있습니다. QA는 이 가이드에 따라 개발자들이 좀 더 높은 품질 인식을 바탕으로 단위 테스트를 작성할 수 있도록 권고하면서 개발자가 작성한 테스트를 확인합니다. 또한 통합 테스트 과정에서 API 테스트와 성능 테스트, UI 자동화 테스트 등이 포함된 자동화된 테스트를 이용해서 지속적인 테스트가 가능하게 만듭니다. 아래는 LINE Keep 통합 테스트 과정에서 수행한 자동화된 성능 테스트 결과를 보여주는 대시보드입니다. 

앞서 언급한 대부분의 테스트는 자동화된 테스트를 기반으로 수행하지만 자동화된 테스트만으로는 수많은 예외 케이스를 처리할 수 없고 다양한 비기능 테스트도 수행할 수 없습니다. 이를 보완하기 위한 방안으로 휴리스틱 방식을 최대한 활용하는 탐색적 테스트를 수행합니다. 탐색적 테스트는 페어 리뷰와 페어 테스트, 테스트 노트, 디브리핑(debriefing) 같은 요소들을 적절히 활용해서 결함을 찾아내는 것이 목적입니다. 자동화된 테스트는 좋은 도구이지만 그 자체가 목적이 되어서는 안됩니다. 때로는 자동화 테스트를 유지 보수하는 작업에 더 많은 자원을 낭비하게 될 수도 있습니다. 자동화의 함정에 빠지지 않도록 늘 효율적인 자동화 테스트 방법을 고민해야 하며 수동 테스트와 자동 테스트의 균형을 맞추도록 노력해야 합니다. 아래는 LINE에서 진행했던 실제 탐색적 테스트의 예시입니다. 

하지만 이와 같은 다양한 시도와 노력에도 불구하고 더 자주, 더 높은 품질의 서비스를 제공하는 것은 여전히 매우 어렵습니다. Shift-left 접근 방법이 아무리 뛰어나더라도 결국 Shift-left 접근 방법에서는 고립된 환경에서만 존재하는 테스트 데이터를 사용하기 때문입니다. 우리가 하는 모든 작업은 결국 사용자를 위해서입니다. 따라서 QA는 사용자를 잘 이해할 수 있는 살아 있는 데이터를 연구해야 하며, 이때 시도해 볼 만한 다른 접근 방법은 Shift-right입니다.

Shift-right 접근 방법

이제 오른쪽으로 확장해 봅시다. Shift-right는 프로덕션 환경에서 진행하는 테스트 활동입니다. 

Shift-left는 테스트를 일찍 수행하는 방법이었지만 그렇다고 Shift-right가 테스트를 늦게 수행하겠다는 것을 의미하진 않습니다. Shift-left와 같이 Shift-right 또한 테스트 방법만을 의미하는 것이 아니기 때문입니다. Shift-right 접근 방법에서는 실제 환경에서의 사용자의 피드백을 수집하고, 그 데이터를 분석해 어떤 것을 개선해야 하는지 알려주는 지침으로 만듭니다. 실제 환경에서 테스트를 수행함으로써 시뮬레이션 환경과는 달리 비기능 요소에 더 집중할 수 있습니다. 이미 아래와 같은 여러 보고서를 통해 많은 사람들이 프로덕션 환경의 테스트에 관심을 갖고 있다는 것을 알 수 있습니다.

Shift-left와 Shift-right를 비교해 보겠습니다. 

Shift-left	Shift-right
예방 활동에 가까움	탐지 활동에 가까움
각 단계에서 바로 테스트를 수행	개발 이후에 사용자의 피드백을 받을 수 있는 형태로 테스트를 수행
조기에 테스트를 수행하는 게 목적	핵심 기능들이 프로덕션 환경에서 잘 작동하는지 확인하는 게 목적

그렇다면 프로덕션 환경에서 테스트를 수행하기 위해서는 어떤 기술이 필요할까요? CX 테스팅과 분석 기술, 이렇게 두 가지로 간단히 정의해 볼 수 있는데요. 이를 우리에게 익숙한 용어나 행동으로 풀어보면 A/B 테스트나 카나리아(canary) 테스트, 단계적 릴리스, 성능 테스트 등으로 표현할 수 있습니다. 결국 실제 사용자의 행동 및 피드백을 기반으로 요구사항을 검증하고, 이를 바탕으로 기능 및 성능 테스트 시나리오를 도출해서, 사용자가 변화를 얼마나 좋아하는지 싫어하는지 테스트하기도 하면서 다양한 환경에서 발생하는 결함을 탐지해 나가는 것입니다(보통 이런 테스트는 기본적으로 군중 테스트(Crowd test 혹은 Cluster test) 형태로 수행합니다). 

LINE 적용 사례

그렇다면 실제로 어떻게 업무에 적용해 볼 수 있을까요? 새로운 기능을 출시하거나 데이터를 분석할 때는 내부 테스트만으로는 충분하지 않기 때문에 A/B 테스트 전략이 필요합니다. LINE에는 이미 다양한 형태의 A/B 테스트 전략이 수립돼 있습니다. QA는 이런 테스트 방식과 관련된 충분한 지식을 갖고 있어야 하고, 프로젝트에서 시기적절하게 조언할 수 있어야 합니다. A/B 테스트가 필요한 이유와 목적은 물론 이후 수행해야 할 액션 아이템까지 잘 정리해서 주어진 리소스 안에서 최대의 효과를 볼 수 있도록 확인할 필요가 있습니다. 아래는 LINE에서 제공하는 A/B 테스트 가이드입니다. 

카나리아 릴리스는 이미 구현된 기능을 특정 대상에게만 배포하고 제어하는 방식입니다. 대표적으로 서비스 설정(service configuration)과 피처 플래그(feature flag), DFM(dog fooding management)과 같은 방법들이 있으며, 테스트의 목적에 맞게 각 방법을 활용합니다. 아래는 LINE에서 카나리아 릴리스를 활용한 모습입니다.

이와 같이 QA는 기능 및 비기능 테스트 이후에 프로덕션 환경에서 테스트 전략을 어떻게 세울 것인지 제안할 수 있습니다. 예를 들어 리스크 관리 차원에서 DFM와 같은 내부 테스트 수행 기간을 늘려서 제품의 안정성을 높일 수 있습니다. 이런 활동은 릴리스 후에 발생할 수 있는, 아직 예상치 못한 이슈를 감지할 수 있도록 도와줍니다. 또한 사용자 패턴 분석과 CS(customer service) 이슈 확인, 앱 스토어 리뷰 분석 등의 활동을 통해 오픈 모니터링을 한층 더 강화할 수도 있습니다. 이런 활동에서 수집하고 분석한 데이터는 프로젝트의 주요 데이터로 활용되면서 보다 높은 품질의 제품을 만들 수 있도록 도와주는 밑거름이 됩니다.

이제 소프트웨어 개발 프로세스를 다시 한 번 확인해 봅니다. QA가 릴리스 단계와 유지 보수 단계로 품질 활동 영역을 더 넓힐 수 있게 되었습니다.

Quality Assistance를 넘어 Quality Advocator로

이와 같이 QA는 개발 프로세스 패러다임의 변화에 따라 Quality Assurance에서 Quality Assistance로 그 역할이 변해 왔으며, 지금도 끊임없이 역할이 확대되면서 지속적으로 변화를 요구받고 있습니다. 앞서 설명한 것과 같이 QA 활동은 모든 프로세스에 영향을 미치며, QA의 역량에 따라 제품의 품질 역시 크게 달라집니다. QA의 역할이 확장되면서 이제 QA는 자동화 테스트 엔지니어와 데이터 과학자, AI/ML 엔지니어, CX 디자이너, DevOps 엔지니어, SRE 엔지니어 등 프로젝트 전반에 걸쳐 다양한 직군의 동료들과 협업하고 있습니다. 이와 같이 커버해야 할 프로젝트가 커지고 복잡해지면서 QA 한 명의 힘만으로 모든 품질 관련 업무를 지원하는 것은 한계에 부딪쳤습니다.

이제 QA(Quality Assistance)는 QA(Qualilty Advocator)로 변화해야 합니다. 프로젝트뿐 아니라 전사적인 차원에서 품질 전파자 및 옹호자가 돼야 하고, 모든 멤버들이 품질에 관심을 기울이면서 스스로 책임을 지는 문화를 만들도록 힘써야 합니다. 그와 같은 QA의 역할을 Quality Advocator라고 부릅니다. 

더 이상 혼자서는 모든 것을 'QA'할 수 없습니다. 혼자서 품질을 높이는 것은 불가능합니다. 모든 것을 혼자서 하려고 하지 마세요. 그것이 테스트일지라도 모두가 함께 해야 합니다. 같이 협업함으로써 QA는 지금보다 더 높은 품질을 만들어 낼 수 있습니다. 이를 위해 Quality Advocator는 동료들에게 끊임없이 좋은 질문을 해야 합니다. 동료들과 함께 품질을 높일 수 있도록 새로운 아이디어를 제공해야 합니다. 물론 이는 쉽지 않은 일입니다. 하지만 그렇기에 스스로의 역량을 높일 수 있는 동기 부여가 될 수 있다고 생각합니다.

우리는 언제까지 이런 활동을 계속해야 할까요? 역설적으로, '동료들이 QA 없이도 스스로 품질에 대한 관심을 지속적으로 유지하며 높은 인식 수준에 닿을 때까지'라고 생각합니다. 저는 이 목표를 이뤄가는 것이 바로 바람직한 Quality Advocator의 역할이라고 생각합니다.