품질은 누구의 일인가 — 전담 테스터에서 모두의 품질로

「품질을 담보하는 것은 누구인가」 라는 물음에 대한 답은, 지난 수십 년 동안 크게 다시 쓰여왔다. 1980~90 년대의 「전담 테스터가 완성품을 수동으로 검사한다」 는 체제에서, 테스트 자동화와 SDET 의 대두를 거쳐, 2010 년대 이후에는 「개발자 스스로가 테스트를 소유한다」 는 문화로. 그리고 지금은, 그 「모두의 품질」 이 기능적 정확성뿐 아니라 성능과 보안까지 삼키고 있다. 이 글에서는 이 직능 변천의 궤적을 따라간다.

전담 테스터 · 수동 QA 의 시대

1970~90 년대의 전통적인 워터폴형 개발에서, 테스트는 개발의 최종 공정에 놓인 독립된 단계였다. 개발 팀이 코드를 다 작성한 후, 별도 부서의 QA 팀이 테스트 계획서 · 테스트 케이스 명세서에 기반해 수동으로 시스템을 검사하는 체제가 일반적이었다.

QA (품질 보증) 는 프로세스 전체의 품질을 담보하는 활동, QC/테스트는 산출물의 결함을 검출하는 활동으로 개념상 구분되는 경우가 많았지만, 실무에서는 둘을 합쳐 「QA 부서」 라고 부르는 경우가 많았다. 특히 항공우주 · 방위 분야에서는, 개발 팀으로부터 완전히 독립된 조직이 테스트를 수행하는 IV&V (Independent Verification and Validation) 가 제도화되었고, IEEE 829 로 대표되는 상세한 테스트 계획 · 테스트 케이스 · 테스트 보고서 작성이 중시되었다. 이 시대의 테스트는 개발 후공정에 놓인 「버그를 찾아내는 관문」 으로 자리매김했고, 테스터와 개발자 사이에는 뚜렷한 조직적 · 문화적 단절이 있었다.

테스트 자동화의 대두

1990 년대 후반부터 2000 년대에 걸쳐, GUI 자동화 도구 (Mercury Interactive 사의 WinRunner/QuickTest Professional 등) 와 xUnit 계열 (xUnit 의 탄생 과 그 확산 참조) 의 보급으로, 반복 실행되는 회귀 테스트를 자동화하려는 움직임이 확산되었다. 자동화의 보급은 동시에, 테스터에게 요구되는 역량을 「UI 를 수동으로 조작하는 능력」 에서 「테스트 코드를 작성하는 프로그래밍 능력」 으로 옮겨 놓았다. 이 변화가, 다음에 다룰 SDET 라는 직군을 낳는 토양이 되었다.

SDET 의 등장 — 테스터도 엔지니어다

2000 년대, 마이크로소프트 (Microsoft) 는 SDET (Software Development Engineer in Test) 라는 직함을 크게 내세웠다. SDET 는 단순히 테스트를 실행하는 것이 아니라, 테스트 자동화 프레임워크 · 도구 · 인프라를 코드로서 개발하는 소프트웨어 엔지니어로 자리매김했다. 이는 「테스터도 엔지니어다」 라는 인식 전환을 상징하는 움직임이었다.

구글 (Google) 도 비슷한 시기에 유사한 전문 직군을 두었지만, 명칭과 역할 분담이 다소 달랐다.

직군	주요 역할	주된 담당 기업
SDET	테스트 자동화 기반 · 도구 개발, 코드로서의 테스트 설계	Microsoft
SET (Software Engineer in Test)	개발 팀에 편입되어, 테스트 용이성이 높은 코드와 테스트 인프라를 구축	Google
TE (Test Engineer)	제품 횡단적인 품질 · 리스크 분석, 탐색적 테스트, 사용자 관점의 검증	Google

구글에서의 품질 엔지니어링 실태는, (전) 구글 소속의 James Whittaker 등이 쓴 저서 『How Google Tests Software』 (2012 년) 에 자세히 나와 있다. 이 책은 구글이 「전담 테스터」 를 최소화하고, 개발자 스스로에게 테스트의 1 차 책임을 지우면서, SET/TE 가 횡단적으로 품질을 지원하는 체제를 그리고 있다.

이후 마이크로소프트를 포함한 업계 전반에서 「전담 테스트 직군을 단계적으로 축소하고, 개발자에게 테스트를 통합한다」 는 흐름이 강해졌다. 마이크로소프트에서는 2014 년을 전후해, 독립된 직군으로 존재했던 테스트 디시플린 (SDET/STE) 을 대폭 축소하고, 개발 (Software Engineer) 과 테스트의 역할을 통합하는 조직 개편을 단행한 것이 당시 널리 보도되었다. 이는 「테스트 전문직의 소멸」 이라기보다, 「테스트 책임을 개발자 자신에게 통합하고, 전담 테스터는 횡단적 품질 전략 · 복잡한 자동화 기반의 설계에 특화한다」 는 역할의 재정의로 이해하는 것이 적절하다. 2010 년대 중반 이후, SDET/SET 라는 직함 자체는 각 회사에서 축소 · 재편되어 갔지만, 「테스트는 코드이며, 엔지니어링 역량을 요한다」 는 사고방식 자체는 정착했다.

개발자가 테스트를 소유하는 문화로

지금은 많은 조직에서 「테스트를 작성하는 것은 기능을 구현한 개발자 자신」 이라는 원칙이 일반화되어 있다. 이 배경에는 다음과 같은 요인이 있다.

1. TDD/BDD 의 보급 —— 개발과 동시에 테스트를 작성하는 실천이 확산됨 (TDD, BDD 참조)
2. CI/CD 파이프라인의 일반화 —— 자동 테스트가 병합 · 배포의 필수 게이트가 되어, 개발자가 테스트의 성패에 직접 책임을 지는 구조가 됨
3. 마이크로서비스 · 소규모 팀화 —— 기능 단위로 팀이 완결되면서, 품질도 팀 내에서 완결시켜야 한다는 압력이 작용함

이로써 「품질은 전담 QA 의 일」 에서 「품질은 팀 전원의 책임」 으로 가치관의 전환이 진행되었다. 다만 이것이 전담 품질 전문직이 불필요해졌음을 의미하지는 않는다. QA 엔지니어 · SDET 는 「품질 전략의 설계자」 「탐색적 테스트와 복잡한 E2E 시나리오의 전문가」 「품질 문화의 추진자」 로 역할을 재정의하며 존속하고 있다.

Shift-Left / Shift-Right

「시프트 레프트」 는 테스트 활동을 SDLC 의 더 이른 단계 (왼쪽) 로 옮기는 사고방식으로, Larry Smith 가 2001 년 Dr. Dobb’s Journal 지에 기고한 기사 「Shift-Left Testing」 에서 제창했다고 알려져 있다. 요구사항 정의 · 설계 단계부터 테스트 가능성을 검토하고, 코딩 중에 단위 테스트를 작성하여, 결함을 가능한 한 이르고 저렴한 단계에서 검출하는 것을 목표로 한다.

한편 「시프트 라이트」 는, 운영 환경 (오른쪽) 에서도 지속적으로 품질을 검증하는 사고방식으로, 2010 년대에 확산되었다. 카나리 릴리스, 피처 플래그, A/B 테스트, 그리고 넷플릭스 (Netflix) 가 2011 년경 공개한 카오스 몽키 (Chaos Monkey) (Simian Army) 로 대표되는 카오스 엔지니어링 등이 포함된다. 이는 「운영 전에 모든 결함을 없앤다」 는 것의 한계를 인정하고, 「운영 환경에서도 관측 · 실험하며 품질을 유지한다」 는 사고방식으로의 확장이다. 시프트 레프트와 시프트 라이트는 대립 개념이 아니라, 테스트를 개발 생애 주기 전체에 분산 배치하는 전략으로서 상호 보완적으로 파악된다.

탐색적 테스트와 context-driven testing 학파

탐색적 테스트 (Exploratory Testing) 는 테스트 설계 · 실행 · 학습을 동시 병행적으로 수행하는 기법으로, 사전에 상세한 테스트 케이스를 고정하지 않고, 테스터가 제품을 탐색하면서 다음 테스트를 고안해 나간다. 이 용어는 Cem Kaner 가 1988 년 저서 『Testing Computer Software』 에서 제창했다고 알려져 있다.

탐색적 테스트는 「비구조적이고 관리 불가능하다」 는 비판을 받기 쉬운데, 이에 대한 응답으로 James Bach 와 Jonathan Bach 가 2000 년 전후에 제창한 것이 세션 기반 테스트 관리 (Session-Based Test Management, SBTM) 다. 탐색적 테스트를 「세션」 이라는 시간 단위로 관리하고, 각 세션의 목적 (차터) 과 결과를 기록함으로써, 탐색적 테스트에 추적 가능성과 설명 책임을 부여하는 프레임워크다.

컨텍스트 주도 테스트 (Context-Driven Testing) 는 Cem Kaner, James Bach, Bret Pettichord 등이 중심이 되어 2000 년대 초에 확립한 학파로, 「테스트의 모범 사례는 컨텍스트 (프로젝트 상황) 에 의존하며, 만능의 정답은 존재하지 않는다」 는 입장을 취한다. 세 사람의 공저 『Lessons Learned in Software Testing』 (2001 년) 은 이 학파의 대표적 문헌이다. Michael Bolton 은 이후 James Bach 와 함께 「Rapid Software Testing (RST)」 방법론을 발전시켜, 컨텍스트 주도 학파의 중심적 논객 중 한 명이 되었다. 이 학파는 테스트를 「체킹 (checking: 사전에 정한 기대 결과와의 대조, 기계적으로 자동화 가능)」 과 「테스팅 (testing: 인간의 지식 · 판단에 의한 탐구적 활동)」 으로 구분하는 관점을 제시하여, 자동 테스트와 탐색적 테스트의 역할 차이를 명확히 했다.

ISO/IEC/IEEE 29119 를 둘러싼 논쟁

컨텍스트 주도 학파의 영향력을 이야기할 때 빼놓을 수 없는 것이, 2013 년에 발행된 국제 규격 ISO/IEC/IEEE 29119 를 둘러싼 논쟁이다. 이 규격은 테스트 프로세스 · 테스트 문서 · 테스트 기법을 표준화하려 한 것이었지만, 「테스트의 모범 사례는 컨텍스트에 의존하며, 단일한 표준 프로세스를 만능의 정답으로 강요해서는 안 된다」 고 생각하는 컨텍스트 주도 학파로부터 강한 반발을 초래했다.

2014 년, 테스트 전문가 James Christie 가 컨퍼런스 CAST 2014 에서 한 강연을 계기로, 참가자였던 Karen Nicole Johnson 이 청원 운동을 제안하면서, “Stop 29119” 라 불리는 반대 캠페인이 일어났다. James Bach 를 비롯한 컨텍스트 주도 학파의 논객들이 중심이 되어 이 규격의 제정 과정의 배타성과 단일 프로세스의 강요를 비판했고, 국제적인 논쟁으로 발전했다. 한편 이 논쟁과는 별개의 계보로, ISTQB (International Software Testing Qualifications Board) 가 2002 년에 설립되어, 테스트 기술자 자격 인증 제도 (ISTQB Certified Tester) 를 국제적으로 보급해 왔다. ISTQB 의 실라버스는 체계화된 테스트 프로세스 · 기법 (동치 분할, 경계값 분석 등) 을 교육하는 프레임워크로 널리 쓰이며, 컨텍스트 주도 학파와 종종 대비되어 논의된다.

애자일 QA 와 테스트 사분면

애자일 개발의 보급과 함께, QA 의 역할도 스프린트 안으로 통합되는 형태로 변화했다. 이 맥락의 대표적 문헌이 Lisa Crispin 과 Janet Gregory 의 『Agile Testing: A Practical Guide for Testers and Agile Teams』 (2009 년) 이며, 속편 『More Agile Testing』 (2014 년) 과 함께 애자일 QA 의 실천서로 널리 읽힌다.

Crispin & Gregory 의 책에서 소개되어 보급된 「테스트 사분면」 은, 원래 Brian Marick 이 고안한 모델로, 테스트를 두 축으로 4 개의 사분면으로 분류한다.

	비즈니스 (고객) 지향	기술 (팀) 지향
팀을 지원	Q2: 기능 인수 테스트, 스토리 테스트, 프로토타입	Q1: 단위 테스트, 컴포넌트 테스트
제품을 비평	Q3: 탐색적 테스트, 사용성 테스트, UAT	Q4: 성능 테스트, 보안 테스트, 비기능 테스트

이 도식은 자동화해야 할 영역 (Q1 · Q2 의 대부분) 과, 인간의 판단이 필요한 영역 (Q3 · Q4 의 일부) 을 정리하여, 애자일 팀이 테스트 활동 전체를 균형 있게 계획하기 위한 공통 언어가 되었다.

호칭의 변천 — QA 에서 Quality Engineer 로

역할의 실질적 변화는, 직군 명칭의 변화에도 나타난다. 최근 많은 기업에서 「QA 엔지니어」 대신 QE (Quality Engineer) 라는 호칭을 채택하는 경향이 강해지고 있다. 이는 단순한 명칭 변경이 아니라, 「결함을 찾아내 보고하는 (보증하는) 역할」 에서 「품질을 만들어 넣는 구조 자체를 설계하는 역할 (엔지니어링)」 로의 무게 중심 이동을 반영한다. QE 는 테스트 자동화 기반 설계, CI/CD 에서의 품질 게이트 설계, 관측 가능성 정비, 개발 팀에 대한 테스트 기법 코칭 등, 더 상류이자 횡단적인 역할을 맡는 경우가 많다.

Q4 가 실체를 갖다 — 성능 테스트라는 비기능의 보루

테스트 사분면의 Q4 에 놓인 성능 테스트와 보안 테스트는, 기능적 정확성과는 독립된 「비기능 요구사항」 을 검증하는 활동으로서, 「모두의 품질」 의 한 축을 차지하게 되었다. 성능 테스트 에는, 예상 부하에서의 응답을 확인하는 부하 테스트, 한계를 초과한 부하에서의 거동을 보는 스트레스 테스트, 급격한 트래픽 증가에 대한 내성을 보는 스파이크 테스트, 장시간 가동에서의 누수 · 열화를 보는 내구 테스트, 리소스 추가 시 성능 향상을 보는 확장성 테스트 가 있다.

대표적인 도구로는, 오래된 OSS 인 Apache JMeter, Scala DSL 로 시나리오를 작성하는 Gatling, JavaScript 로 스크립트를 작성하며 2021 년 Grafana Labs 가 인수한 k6, Python 으로 분산 부하를 생성하는 Locust, 경량 고처리량인 wrk · Vegeta 등이 있다. 중요한 것은 레이턴시를 평균값만으로 논하지 않는 것 —— p50 · p95 · p99 같은 백분위수로 테일 레이턴시를 파악하는 것이 필수로 여겨진다. 서비스 관점의 RED 법 (Rate · Errors · Duration, Tom Wilkie 제창) 과 리소스 관점의 USE 법 (Utilization · Saturation · Errors, Brendan Gregg 제창) 을 조합한 분석, 구글의 SRE 실천으로 체계화된 SLO 와 에러 버짓의 연동, 그리고 운영 트래픽을 복제해 검증하는 트래픽 미러링/다크 런치 같은 shift-right 적 기법이, 현대의 성능 테스트를 뒷받침하고 있다.

보안 테스트라는 또 하나의 비기능

DevSecOps 는 shift-left 의 사고방식을 보안 영역에 적용한 것으로, 보안 검증을 개발 생애 주기의 가능한 한 이른 단계에 통합한다. 자동화 도구는 소스 코드를 분석하는 SAST, 실행 중인 애플리케이션을 외부에서 검사하는 DAST, 실행 시 코드 내부를 계측하는 IAST, 의존 라이브러리를 검사하는 SCA 의 네 가지로 정리되며, 검출된 취약점은 CWE (취약점의 유형 분류) 와 CVSS (심각도 점수) 로 우선순위가 매겨진다.

보안 맥락의 퍼징에서는, 커버리지 유도형 퍼저의 선구자인 AFL (Michał Zalewski), LLVM 의 libFuzzer, 구글이 2016 년에 시작한 지속적 퍼징 서비스 OSS-Fuzz 가 중요한 역할을 해 왔다. 자동화 도구를 보완하는 것이, 화이트 해커에 의한 수동 중심의 침투 테스트 (penetration testing), 그리고 HackerOne 과 Bugcrowd 가 중개하는 버그 바운티 프로그램 — 기간 한정의 집중 점검과, 상시 가동의 지속적 점검이라는 상호 보완 관계에 있다. 설계 단계에서 공격 경로를 도출하는 위협 모델링 에서는, STRIDE (Loren Kohnfelder 와 Praerit Garg 가 1999 년에 고안) 와 Adam Shostack 의 저서 『Threat Modeling: Designing for Security』 (2014 년) 가 널리 참조된다. 운영 환경에서의 WAF · RASP 는, 테스트와 정적 분석을 빠져나간 취약점에 대한 마지막 방어선으로 기능하는 shift-right security 의 실례다.

업계 횡단의 공통 언어가 된 것이 OWASP Top 10 으로, 2021 년판 이후 약 8 년 만의 대개정인 OWASP Top 10:2025 는 17 만 5 천 건이 넘는 CVE 데이터 분석을 바탕으로 재구성되었다. 오랫동안 1 위였던 「접근 제어 미비」 (SSRF 를 통합) 는 계속 1 위를 유지했고, 「Software Supply Chain Failures」 와 「Mishandling of Exceptional Conditions」 가 신설되어, 공급망 공격과 예외 처리 미비라는 최근의 공격 경향이 반영되었다.

정리 — 모두의 품질은, 정확성뿐 아니라 비기능도 포함한다

QA 의 역사는 「독립된 검사 부서에 의한 관문」 에서 「개발 프로세스 전체에 스며든 품질 활동」 으로의 이행의 역사다. SDET/SET 라는 직군의 등장은 「테스트도 엔지니어링이다」 라는 인식을 확립했고, 탐색적 테스트와 컨텍스트 주도 학파는 「테스트는 기계적 체크만으로는 대체할 수 없는 지적 활동이다」 라는 것을 이론화했다. 그리고 테스트 사분면이 보여주듯, 지금의 「모두의 품질」 은 기능적 정확성뿐 아니라 성능과 보안이라는 비기능 요구사항까지 포함한다. 자동화된 체크와 인간에 의한 탐색적 테스팅을 조합하여, 개발 생애 주기 전체 (shift-left/shift-right) 에 품질 활동을 분산시키는 체제가, 지금의 주류가 되어 있다.

다음 글에서는, 이 「모두의 품질」 체제가 수백 · 수천 명 규모의 조직과 거대해진 코드베이스라는 스케일 속에서 어떻게 유지되고, 어디서 삐걱거림을 낳는지를 살펴본다. 테스트를 대규모로 운용하다 —— 품질의 분산 배치가 조직의 규모라는 또 하나의 변수와 만나는 지점으로.