전통적인 소프트웨어 개발에서는 보이지 않는 ‘벽’이 존재했습니다. 개발팀은 기능을 만들어 QA팀에게 던져주고, QA팀은 테스트가 끝난 제품을 운영팀에게 던져주는 방식이었습니다. 이 방식은 느리고, 각 팀 간의 갈등을 유발하기 쉬웠습니다.
이러한 벽을 허물고, ‘개발’과 ‘운영’이 하나의 팀처럼 협력하여 빠르고 안정적으로 서비스를 제공하자는 움직임이 바로 ‘DevOps(데브옵스)’입니다.
그렇다면 개발과 운영이 하나가 되는 이 거대한 흐름 속에서, QA는 어디에 서 있어야 할까요?
Q. DevOps(데브옵스), 정확히 무엇인가요?
DevOps는 ‘개발(Development)’과 ‘운영(Operations)’의 합성어입니다.
개발팀과 운영팀이 서로의 업무를 이해하고 긴밀하게 협력하며, CI/CD 파이프라인과 같은 도구를 통해 빌드, 테스트, 배포 과정을 자동화하는 것을 목표로 합니다. 이는 단순히 도구를 도입하는 것을 넘어, 조직의 ‘문화’이자 ‘철학’에 가깝습니다.
- 핵심 목표: 아이디어가 코드로 만들어져 실제 사용자에게 전달되기까지의 전체 시간을 최대한 단축하고, 이 과정을 안정적으로 만드는 것입니다.
Q. DevOps에서 QA의 역할은 어떻게 변하나요?
QA는 더 이상 개발과 운영 사이의 ‘품질 검사 단계’가 아닙니다. 개발 프로세스 전체에 ‘품질’을 심는 ‘품질 조력자(Quality Facilitator)’가 됩니다.
이러한 변화의 핵심 개념이 바로 ‘Shift Left Testing’입니다.
- Shift Left Testing이란?
- 테스트 활동을 개발 프로세스의 타임라인 상 오른쪽(후반)이 아닌, 왼쪽(초반)으로 최대한 옮기는 것을 의미합니다.
- 즉, 코드가 모두 완성된 후에 버그를 ‘발견’하는 데 집중하는 것이 아니라, 기획과 설계 단계부터 QA가 적극적으로 참여하여 결함이 애초에 만들어지는 것을 ‘예방’하는 데 집중하는 것입니다.
Q. ‘Shift Left Testing’을 실천하기 위해 QA는 무엇을 해야 하나요?
DevOps 문화 속의 QA는 다음과 같은 활동에 집중하며, 팀 전체의 품질 책임을 높이는 역할을 합니다.
- 1. 기획/설계 단계에 참여하기:
- 새로운 기능의 요구사항이 명확한지, 테스트하기 어려운 구조는 아닌지 초기 단계부터 검토하고 피드백을 제공합니다. “이 기능은 나중에 테스트하기 매우 어려울 것 같아요”라고 미리 알려주는 것이죠.
- 2. 테스트 자동화 고도화하기:
- 개발자가 코드를 커밋할 때마다 CI(지속적 통합) 과정에서 자동으로 실행될 수 있는 견고한 자동화 테스트를 구축하고 관리합니다. 이는 CI/CD 파이프라인의 핵심적인 품질 게이트 역할을 합니다.
- 3. 테스트 환경 관리(IaC)에 참여하기:
- 운영 환경과 동일한 테스트 환경을 코드(IaC, Infrastructure as Code)로 관리하는 데 참여하여, “제 PC에선 잘 되는데요?”와 같은 환경 문제를 원천적으로 차단합니다.
- 4. 운영 환경 모니터링 및 피드백:
- 배포 후, 실제 운영 환경에서 발생하는 사용자 데이터나 에러 로그를 함께 모니터링합니다. 그리고 이를 분석하여, 다음 개발 스프린트에 “실제 사용자들이 이 부분에서 가장 많이 이탈해요” 와 같은 데이터 기반의 피드백을 제공합니다.
결론: 품질은 모두의 책임
이 과정에서 QA의 역할은 버그를 찾아내는 ‘게이트키퍼’에서, 팀 전체가 품질을 높일 수 있도록 돕는 ‘코치’이자 ‘엔지니어’로 진화합니다. ‘Shift Left Testing’과 자동화를 통해, QA는 빠른 개발 속도에 제동을 거는 역할이 아닌, 오히려 속도를 더 높여주는 ‘가속 장치’가 될 수 있습니다.
DevOps 문화에서 품질은 더 이상 QA팀만의 책임이 아닙니다. 개발자, 운영자, 기획자 모두가 함께 책임지는, 팀 전체의 목표가 됩니다.