가파르게 성장하는 서비스를 담당한, 한 품질담당자의 회고
안녕하세요. 품질개발팀 임선진입니다.
저는 우아한형제들의 프로덕트들을 효율적이고 효과적으로 품질을 높이기 위해 QA로서 업무를 수행하고 있습니다.
2019년 하반기~2021년 상반기.
조금 시간이 지난 과거의 이야기이지만, 저의 경험을 공유하고 회고하며 스스로 정리하고 싶어 글을 쓰기 시작했습니다. 그리고 빠른 배포 주기를 어떻게 하면 가져갈 수 있을지, QA 업무를 어떻게 운영하면 좋을지 등 QA, 테스트 업무와 관련해 고민하고 계신 분들께 조금이나마 도움이 되었으면 하는 바람으로 끝까지 마무리하게 되었습니다.
마주한 상황
배달의민족 서비스의 성장 속도는 정말 무서울 정도로 가팔랐습니다.
그에 맞춰 시스템도, 서비스도 매우 빠르게 대응하고 발전했어야만 했습니다.
2019년 배달의민족 시스템은 생존을 위해 마이크로 서비스 아키텍처로 변화를 했고, 결과는 매우 성공적이었습니다. 이후 시스템 별로 크게 플랫폼, 프론트서버, 앱/웹 클라이언트 팀들로 나누어지고 팀은 기획/개발/QA가 함께 있으며 시스템 안정화와의 잔여 작업들을 마무리하며 서비스 개발에 속도를 내기 시작했던 시기였습니다.
당시 팀의 상황과 업무들을 이해할 수 있을 만한 참고 링크
저는 프론트서버 군(전시(display), 리뷰 도메인 등 대 고객 서버군)들을 개발하는 배민프론트검색서비스 팀의 QA로 일을 하게 되었습니다.
이전까지는 일부 도메인을 제외한 프론트서버 군들은 웹/앱 클라이언트를 테스트하며 서버의 로직들도 같이 테스트하고 있었고, 서버만 전담하여 테스트한다는 것은 아직 조직이 겪어보지 못한 미지의 영역이었기에 저는 프론트검색서비스팀의 QA로서 해야 할 일들을 찾아가야 했습니다.
팀에서 QA로서 내가 해야 할 일
당시 배민 앱은 2주 주기의 배포 주기를 선택했습니다. 그리고 우리는 2주 보다 더욱더 빠르게 기능이 배포(고객에게 가치가 전달) 되길 바랐습니다.
위와 같은 상황에서 저에게 주어진 미션은 아래와 같다고 판단했습니다.
1. 클라이언트(배민 앱)가 안정적으로 테스트될 수 있도록, 테스트 환경(프론트서버군)이 안정적으로 되도록 지원한다.
앱이 2주마다 배포되려면 테스트를 끊임없이 수행해야 했습니다. 끊임없이 테스트를 수행하기 위해 테스트 환경에서 장애가 발생하는 일이 없어야 했습니다. 테스트 환경이 불안정해 앱 테스트를 하지 못하면 어쩔 수 없이 야근을 하게 되고 클라이언트(배민 앱) 결함 발견과 수정 시간이 부족하게 되고, 2주의 배포 주기를 맞추기 어렵다고 생각했습니다. 서버는 앱의 배포 주기를 방해하지 않고 안정적으로 개발/테스트할 수 있도록 지원하기로 결정했습니다.
서버 작업으로 클라이언트(배민 앱)의 테스트에 영향을 줄 수 있는 부분이 있다면 피할 수 있게 하거나 즉시 전파하고, 테스트를 진행하는 분들이 혼란스럽지 않도록 했습니다. 서버 개발자들께도 많은 분들이 혼란스러울 수 있으니 베타(테스트) 서버도 안정적인 상태를 유지해 달라 말씀드렸습니다.
서버 상황과 무관하게 클라이언트(배민 앱)를 끊임없이 테스트할 수 있도록, 클라이언트(배민 앱) QA 담당자분들도 Mock Server의 역할을 할 수 있는 Fiddler, Charlesproxy 등의 도구를 통해 테스트를 계획하고 수행하는 동시에, 저는 서버가 안정적으로 운영되도록 지원했습니다.
- Windows OS에서 모바일 클라이언트 테스트에 유용한 도구 – Fiddler Document:
https://docs.telerik.com/fiddler/modify-traffic/tasks/customizerequest - MAC OS에서 모바일 클라이언트 테스트에 유용한 도구 – Charlesproxy Document: https://www.charlesproxy.com/documentation/tools/
2. 클라이언트(배민 앱) 개발 이전에 서버 테스트를 진행한다.
클라이언트(배민 앱)의 개발 이전에 서버의 테스트를 어느 정도 진행해서 안정적인 환경을 만들어야 개발/테스트를 진행할 수 있고, 클라이언트(배민 앱)가 2주의 배포 주기를 가져갈 수 있다 생각했습니다. 개발자분들과 개발 문서들을 같이 확인하고, 클라이언트와 협의한 사항대로 API를 호출하고 데이터를 사용할 수 있는지 클라이언트(배민 앱)를 보지 않고도 서버에 저장된 데이터, kibana 로그, api 테스트 등을 통해 서버를 테스트했습니다.
또한 플랫폼 시스템의 작은 변경 사항도 프론트 서버 군을 통해 앱에서 반영되어야 했습니다. 간단한 기능 같아 보여도 앱에서 테스트하려면 정말 다양한 플랫폼의 기능들을 알아야 했고, 앱을 테스트하는 분들이 플랫폼과 프론트 서버의 세부적인 동작을 이해하고 테스트하기는 어려웠습니다.
그리고 서버와 클라이언트를 각각 테스트하면 대상을 바라보는 관점이 달라 효과가 다르게 나타날 것이라고 기대했습니다. 그래서 작은 부분이라도 될 수 있으면 일부 중복된 영역이라도 같이 테스트를 진행하도록 했습니다.
이렇게 함으로써 불확실성을 줄이고, 더욱 안정된 테스트를 할 수 있게 되었습니다.
3. 서버의 배포만으로 사용자에게 가치를 전달할 수 있는 방향으로 만들어질 수 있도록 지원한다.
배민 앱 배포와 무관하게 2주 주기보다 더 빠르게 사용자에게 개선된 기능을 전달할 수 있다면 그렇게 하는 것이 좋다고 판단했습니다. 소프트웨어 설계 시 서버 배포만으로 기능이 변경될 수 있도록 의견을 나누고, 개발/테스트 후 배포될 수 있도록 했습니다.
예를 들어 현재 배민 앱의 카테고리들과 정렬, 필터 기능은 앱 업데이트 없이도 추가, 변경, 삭제할 수 있도록 구현되어 있고, 서버의 설정, 배포만으로 사용자에게 가게 정보들(예: 쿠폰 배지, 포장/예약 여부, 위생등급 표시 등)을 노출할지 말지, 어떻게 노출할지를 결정할 수 있습니다.
이외에도 프론트 서버 군의 설정, 배포 만으로 사용자 A/B 테스트를 진행하고 결과를 통해 사용자에게 더 나은 방법들을 제시할 수도 있습니다.
4. (프론트검색서비스) 팀이 담당하고 있는 모든 프로덕트에 QA로서 관여한다.
팀의 모든 프로덕트가 좋은 품질의 서비스가 될 수 있도록 신경 썼습니다. 테스트를 진행하지 못하는 경우에도 의견을 주고받으며 우려 사항들을 보완했고, 개발자분들이 제가 작성한 테스트 케이스를 보고 단위 테스트를 작성하기도 하고, 기획/개발 간 서로 잘 이해 안 되는 것 같을 땐 제가 먼저 추가 문서를 작성하며 지원했습니다.
그리고 과거의 저는 QA는 항상 우선순위가 높고 중요한 과제들에만 참여할 수 있었기 때문에 여러 가지 시도들을 하기 어렵다고 생각했었습니다. 그래서 팀이 담당하고 있는 업무들 중 스펙이나 일정 등 협의의 여지가 있는 과제들도 진행할 수 있도록 하고, 프로젝트 경험이 많지 않은 다른 QA분들이 경험을 쌓고 여러 가지 시도를 할 수 있도록 지켜보고 지원하기도 했습니다.
팀의 구성과 미션에 따라 테스트 수행 전략도 대략 윤곽이 보였습니다. 테스트 계획, TC 작성 및 리뷰, 결함 관리는 기존과 동일하게 유지했고, 몇 가지 특징이 될 만한 것은 아래와 같았습니다.
테스트 업무 수행 전략
-
기획/개발 긴밀하게 협업할 수 있는 구조
- 프로젝트의 계획/개발 계획과 거의 동시에 테스트 계획 시작
- 프로젝트의 목표와 시스템을 정확히 이해하고, 적절하고 효율적인 테스트 수행
-
클라이언트 환경과 독립된 서버 사이드 테스트
- 서버 기능 단위의 테스트
- 클라이언트 하위 버전 호환 테스트
-
빠른 배포 주기
- 변경점을 정확히 이해하고 테스트 영역 최소화 수행
- 각 시스템, 기능 단위 분리 테스트 수행 후 통합 테스트 진행
위와 같은 업무 방식으로 테스트를 앞당겨 결함을 조기에 발견함으로써 결함의 수정 비용을 줄일 수 있다고 믿었고, 테스트는 플랫폼, (서비스) 프론트서버, (서비스) 앱 단계를 나누어 더욱더 견고해져야 하며 가치는 더욱더 빠르게 고객에게 전달될 수 있도록 해야 한다고 파트원들을 독려하고 협업했었습니다.
기획/개발자분들과 긴밀하게 협업하며 빠르게 서비스를 고민하고 배포하고 적용했던 경험은 정말 소중한 경험이었습니다. 각 시스템에 특화된 다른 팀의 QA분들도 숙원 과제였던 담당하고 있는 시스템의 테스트 자동화를 진행하거나, 각 시스템 특성에 따른 고민점들을 해결해 나가며 행복한 나날들을 보냈습니다.
당시 QA분들의 증적들
하지만… QA들이 각 팀에 있으며 발생하는 문제점들이 있었습니다.
1. 공통적인 QA의 업무를 일부 인원이 부담하고 있던 문제
누군가는 해야 하는 QA들의 공통적인 업무들이 있었습니다. 각 서비스팀에서 담당하지 않아도 되는 공통적인 업무들이 있었지요. 팀장님들은 QA들의 이런 업무들을 정확히 이해할 수도 도와줄 수도 평가할 수도 없었습니다. 일부 인원들이 부담하여 수행하고 있던 상황이었습니다.
- 테스트 협력업체 관리/운영 (실무 업무 외 계약, 증원 등)
- 테스트 장비, 도구 관리/운영
- QA 신규 인원(정직원) 인터뷰
2. QA 직군, QA 조직의 성장
가뜩이나 사람 적은 직군을 나누어 놓다 보니 각 팀에 많아야 2명, 없는 팀들도 많았습니다. 인터뷰를 보며 채용할 때에도 QA로서 정체성을 잃지 않고 오롯이 혼자서 업무를 잘 진행할 수 있는 사람인가도 중요한 부분이 되었고, 팀으로 도와주기 어렵다 보니 개인의 잠재 능력이 있는 분이지만 모시기 어려운 상황이 되기도 했습니다.
그리고 주니어분들을 케어하고 성장시키며 지식을 전파하고 시니어로 성장해야 할 인원들이 다소 정체되어 있었습니다. 물론 다른 방법으로 능력을 키워가는 분도 계셨지만, 분명 한계가 있었습니다. 또한, 다른 시스템이나 좋은 다른 사례들을 접할 기회가 부족해 시야를 넓히기도 어려웠습니다.
3. 신규 팀/신규 시스템의 담당자 부재로 인한 서비스 품질 저하
제가 있던 프론트검색서비스팀만 해도 기획/개발자분들은 계속 늘어나고 팀은 계속 변했습니다. 팀에서 담당하던 시스템들 중 검색 시스템과 광고노출 시스템은 시스템/서비스/조직 확장을 위해 다른 팀으로 분리되었고, QA 담당은 계속 프론트검색서비스팀의 QA인 채로 유지되었습니다.
이처럼 조직은 계속해서 변화하고 있었고, QA가 없던 조직에서 새롭게 생겨난 팀/서비스/시스템은 QA들의 확인과 테스트를 받지 못하고 개발/기획 담당자의 손을 거쳐 배포되고 있었습니다. 전체적인 관점에서 볼 때 각각의 서비스는 천차만별로, 품질을 보장받지 못하고 있었습니다.
4. 전사적 관점이 아닌 팀 관점에서의 QA 업무 진행
팀의 프로젝트들을 신경 쓰다 보니 전사적 관점에서 봤을 땐 B 프로젝트보다 A 프로젝트가 더 중요하지만 우리 팀에서 담당하지 않아서, 팀에서 담당하고 있는, 중요도가 떨어지는 B 프로젝트의 QA를 진행하고 있던 경우도 있었습니다. 무엇인가 잘못되고 있었습니다.
그리고 저에게 있어 중요 고객은 사용자도 있었지만 서버를 사용하는 클라이언트(배민 앱)였습니다. 서비스를 전체적인 사용자 관점에서 고려하지 못했던 부분이 분명 있었습니다.
이외에도 업무 재편을 통해 회사에서 더 중요한 프로덕트라 판단한 시스템을 담당하도록 하거나, 업무가 몰리는 영역에 지원을 하거나, 강점이 있는 영역을 강화하는 등의 리소스를 효율적으로 활용할 수 있는 방법이 있어 보였음에도 시도하기 어려웠습니다.
마무리
프론트검색서비스팀에서의 경험이 저에겐 정말 소중한 경험이었지만, 보살피지 못했던 여러 가지 문제점들을 해결해야만 하는 때가 왔고, 경험을 발판 삼아 또 한걸음 더 나아가야 할 때가 왔다고 생각합니다. 서비스의 속도는 빠르게, 테스트는 견고하게, 시야는 넓게 우리 프로덕트의 품질을 챙겨야 할 때라고 생각합니다.
우리의 일은 정답이 있는 것이 아니라 상황에 맞춰 최선을 선택하는 것이고, 그 선택이 최고의 선택이 될 수 있도록 노력하는 것일 겁니다. 우리는 앞으로도 계속 발전하며 성장하고 변화할 것이라고 믿습니다.
지금은 앞서 언급했던 문제점들을 보완하기 위해, 조직(팀) 차원에서 일을 잘 하면서도 일하기 좋은 팀이 되기 위해 고민하고 있습니다. 상세한 이야기를 블로그를 통해 할 수는 없지만, 언젠가 또 이렇게 회고할 수 있는 기회가 오길 바랍니다.
또 한 번의 큰 변화를 앞둔 지금, 또 한 번 최선을 다하기 위해선 잘 된 것과 아쉬운 것에 대한 정리가 필요할 것 같다는 생각이 들었고, 이렇게 기술블로그에 글을 쓰게 되었습니다.
여러분들은 어떤 상황에서 어떻게 일하고 계신가요?
어떤 선택들과 어떤 노력들을 하고 있나요?