개발 방법론과 테스트: 워터폴부터 스크럼·칸반까지

개념

같은 음식을 코스로 내느냐 뷔페로 내느냐에 따라 주방의 일하는 방식이 완전히 달라진다. 코스는 순서가 정해져 있어 앞 접시가 나가야 다음을 준비하고, 뷔페는 계속 조금씩 채운다. 요리의 내용이 같아도 리듬이 다르다.

방법론이 그 리듬이다. 테스트 기법(모듈 3)이나 결함 관리(모듈 6)는 어느 방법론에서나 같지만, 언제 어떤 단위로 하는지가 달라진다. 그리고 리듬을 잘못 맞추면 QA는 팀의 병목이 된다.

방법론이 테스트 시점을 결정한다

같은 "테스트"라는 활동도, 팀이 어떤 개발 방법론을 따르느냐에 따라 언제, 얼마나 자주, 누가 하는지가 완전히 달라진다.

구체적으로 네 가지가 바뀐다.

마지막 줄이 가장 큰 차이다. 2주마다 배포하면 1년에 26번 회귀 테스트를 해야 하고, 그 부담이 자동화 투자의 직접적인 이유가 된다 (스테이지 4). 워터폴에서는 회귀를 한두 번만 하므로 수동으로 버틸 수 있다.

워터폴(Waterfall)

요구사항 → 설계 → 구현 → 테스트 → 배포 순서로, 각 단계가 끝나야 다음 단계로 넘어간다. 테스트는 구현이 다 끝난 뒤 한 번에 몰아서 진행되는 별도의 단계다.

• 장점: 테스트할 범위가 명확하고, 무엇을 검증해야 하는지 문서(모듈 2에서 배운 요구사항 명세)가 안정적이다
• 단점: 테스트 단계에서 큰 결함이 나오면 앞 단계로 되돌아가기 비용이 크다. 사용자 피드백을 반영하기까지 시간이 오래 걸린다

V-모델 — 워터폴을 테스트 관점으로 다시 그린 것

워터폴을 테스트 쪽에서 보면 V자가 된다. 왼쪽은 점점 구체화되는 설계이고, 오른쪽은 각 설계에 대응하는 검증 단계다.

요구사항 정의 ─────────────────▶ 인수 테스트
    └ 시스템 설계 ───────────▶ 시스템 테스트
         └ 상세 설계 ──────▶ 통합 테스트
              └ 구현 ───▶ 단위 테스트

이 그림이 주는 통찰이 둘 있다.

• 각 설계 단계에 대응하는 테스트가 있다 — 요구사항은 인수 테스트로, 시스템 설계는 시스템 테스트로 검증된다. 짝이 없으면 공백이다
• 테스트 설계를 왼쪽에서 시작한다 — 요구사항을 쓸 때 인수 테스트를 함께 설계하면, 그 과정에서 요구사항의 모호함이 드러난다

두 번째가 실무적으로 중요하다. 모듈 2 레슨 6에서 본 "요구사항 리뷰에 QA가 참여한다" 가 V-모델에서는 구조적으로 정해진 활동이다. 애자일에서 같은 일을 하는 것이 인수기준 작성이고(레슨 8), 이름만 다르다.

V-모델은 ISTQB 시험과 면접에 자주 나온다. "워터폴은 뒤에서 테스트하니 나쁘다" 가 아니라, 테스트 설계는 앞에서 하고 실행은 뒤에서 한다는 것이 정확한 이해다.

워터폴이 아직 쓰이는 곳

"요즘 다 애자일 아닌가" 라고 생각하기 쉽지만, 워터폴이 합리적인 선택인 영역이 분명히 있다.

두 번째 줄이 국내에서 특히 많다. 발주처와 수행사가 계약으로 범위를 고정하면, 중간에 요구가 바뀌는 것이 계약 변경이 되므로 애자일처럼 움직일 수 없다. 이때 QA의 일은 합의된 범위를 증명하는 것에 가까워지고, 문서가 산출물로서 중요해진다.

애자일(Agile) — 스크럼(Scrum)

2~4주 단위의 짧은 반복(스프린트)마다 요구사항 정의부터 테스트까지 전체 사이클을 돈다. 테스트는 스프린트 안에서, 개발과 거의 동시에 진행된다.

• QA는 스프린트 계획 회의에 참여해 미리 테스트 관점에서 질문하고 (모듈 2 레슨 6과 연결), 기능이 완성되는 대로 바로 테스트한다
• 회귀 테스트(전에 잘 되던 기능이 새 변경으로 깨지지 않았는지 확인)의 비중이 워터폴보다 훨씬 커진다 — 매 스프린트마다 반복해야 하기 때문

스크럼에서 가장 흔한 실패 — 미니 워터폴

스크럼을 도입했는데 스프린트 안에서 워터폴을 반복하는 경우가 매우 많다.

2주 스프린트
├────────── 개발 ──────────┬── QA ──┐
월  화  수  목  금  월  화  수   목  금
                           ↑
                  여기서 개발이 끝난다

이러면 세 가지가 생긴다.

• QA가 앞 1주는 할 일이 없고 뒤 3일에 몰린다
• 결함이 나와도 고칠 시간이 없다 → 다음 스프린트로 밀린다
• 스프린트 마지막 날 "완료" 를 선언하지 못한다

이름은 스크럼인데 리듬은 워터폴이다. 해결은 QA가 더 빨리 일하는 것이 아니라 일의 단위를 쪼개는 것이다.

마지막 줄이 실질적인 답이다. 스프린트 앞부분에 QA가 할 일이 없는 것이 아니다 — 테스트 설계와 인수기준은 개발보다 먼저 하는 일이다. 레슨 8에서 이 활동을 자세히 다룬다.

애자일 — 칸반(Kanban)

스프린트 같은 고정된 주기 없이, 작업이 "할 일 → 진행 중 → 테스트 중 → 완료"라는 보드를 흐르며 하나씩 끝나는 대로 배포될 수 있다. QA는 특정 주기에 몰아서 테스트하는 게 아니라, 보드 위에 새 카드가 "테스트 중" 열로 들어올 때마다 지속적으로 테스트한다.

칸반의 핵심 장치가 WIP 제한(동시 진행 개수 제한)이다. 각 열에 들어갈 수 있는 카드 수를 정해 두는 것인데, QA에게 이것이 왜 중요한지가 분명하다.

할 일        진행 중(3)      테스트 중(2)     완료
┌────┐      ┌────┐          ┌────┐          ┌────┐
│    │      │ ■■ │          │ ■■ │  ← 꽉 참  │    │
└────┘      └────┘          └────┘          └────┘
                               ↑
              여기가 꽉 차면 개발이 새 카드를 못 당긴다

"테스트 중" 이 꽉 차면 개발이 멈춘다. 이것이 벌이 아니라 설계다. 멈춘 개발자가 테스트를 도우러 오게 만드는 것이 WIP 제한의 목적이다.

WIP 제한이 없으면 반대가 된다 — 개발은 계속 카드를 밀어 넣고, "테스트 중" 열에 20장이 쌓이고, QA가 영구적인 병목이 된다. 그리고 그 상태는 보드만 봐도 보인다.

칸반에서 QA가 봐야 할 숫자가 둘 있다.

"테스트 중" 체류 시간이 길면 원인은 셋 중 하나다 — QA 인원 부족, 스토리가 너무 큼, 또는 결함 재작업이 많음. 숫자를 보면 어느 쪽인지 말할 수 있다(모듈 6 레슨 5의 과정 지표와 같은 접근).

방법론별 QA 역할 비교

비교를 조금 더 넓히면

표를 세 축 더 넓혀 두면 새 팀에서 무엇이 달라지는지 예상할 수 있다.

두 번째 줄이 QA가 가장 체감하는 축이다. 워터폴에서는 "늦게 알았다" 가 사고로 이어지고, 애자일에서는 "QA가 못 따라간다" 가 병목으로 이어진다. 같은 사람이 다른 팀에서 전혀 다른 문제로 고생하는 이유다.

현실은 대개 섞여 있다

교과서적인 방법론을 그대로 쓰는 팀은 드물다. 국내에서 자주 보는 조합이 있다.

첫 줄이 가장 많고 QA에게 가장 번거롭다. 안에서는 애자일로 일하면서 밖에는 워터폴 산출물을 내야 하므로 문서 작업이 두 배가 된다. 이때 현실적인 해법은 도구에서 자동으로 뽑는 것이다 — 레슨 1의 테스트 관리 도구와 모듈 6 레슨 5의 지표가 쌓여 있으면, 보고서가 수작업이 아니게 된다.

두 번째 줄도 함정이 있다. 2주마다 "완료" 라고 선언했는데 실제로 내보내는 것은 석 달 뒤라면, 그 사이에 쌓인 변경을 한꺼번에 회귀 테스트해야 한다. 스크럼의 형식은 있지만 회귀 부담은 워터폴인 상태다.

방법론이 바뀔 때

조직이 방법론을 바꾸면 QA가 가장 먼저 흔들린다. 전환기에 생기는 일이 정해져 있다.

• 역할이 애매해진다 — "별도 테스트 단계" 가 없어지면 QA의 자리가 어디인지 다시 정의해야 한다
• 문서를 버리라고 한다 — 애자일이 "문서 없음" 으로 오해되면 추적성이 사라진다. 줄일 문서와 지킬 문서를 구분해야 한다
• 회귀 부담이 먼저 온다 — 자동화가 준비되기 전에 주기가 짧아지면 QA가 무너진다

세 번째가 전환 실패의 가장 흔한 원인이다. 배포 주기를 2주로 줄이면서 회귀 자동화를 같이 준비하지 않으면, QA는 매 2주마다 같은 수동 테스트를 반복하게 된다. 전환을 논의할 때 QA가 반드시 꺼내야 할 조건이 이것이다.

방법론과 무관하게 변하지 않는 것

방법론 공부가 산만해지기 쉬운데, 안 바뀌는 것을 알아 두면 중심이 잡힌다.

오른쪽 칸이 QA의 실력이다. 방법론은 팀에 따라 바뀌고 몇 년마다 유행이 바뀌지만, 오른쪽은 어디서나 그대로 쓰인다. 방법론을 묻는 면접 질문의 진짜 의도도 "이 사람이 리듬을 맞출 수 있나" 이지, 용어 암기가 아니다.

새 팀에 합류했을 때 파악하는 순서

방법론 이름을 듣는 것보다 실제 리듬을 확인하는 것이 빠르다. 다섯 가지만 물으면 된다.

1. 배포 주기가 얼마인가 — 모든 것이 여기서 따라온다
2. 완료의 정의에 테스트가 들어 있나 — 안 들어 있으면 QA가 밀린다
3. 회귀를 어떻게 하나 — 수동이면 주기가 짧을 때 무너진다
4. QA가 어느 회의에 들어가나 — 앞에서 참여하나 뒤에서 받나
5. 릴리즈 판단을 누가 하나 — QA의 보고가 어디로 가나

두 번째가 가장 많은 것을 알려 준다. 완료의 정의에 "QA 통과" 가 없으면, 이름이 무엇이든 그 팀은 미니 워터폴로 돌고 있다.

사례 — 2주 주기로 바꾸고 QA가 무너진 3개월

월 1회 배포하던 팀이 2주 주기 스크럼으로 전환했다. 테스트 케이스는 전부 수동이었고 회귀에 5일이 걸렸다.

새 기능을 볼 시간이 절반으로 줄었고, 석 달 동안 운영 결함이 2배로 늘었다. 원인은 역량이 아니라 산수였다.

고친 순서가 중요하다.

1. 회귀 범위를 리스크로 줄였다(모듈 4) — 5일 → 2일. 비용 0
2. 스모크 24건을 자동화했다(레슨 1) — 2일 → 1일
3. 완료의 정의에 "QA 통과" 를 넣어 미니 워터폴을 깼다
4. 자동화 범위를 분기마다 늘렸다

1번을 먼저 한 것이 핵심이다. 자동화는 몇 달이 걸리지만, "매번 전부 돌리던 회귀를 리스크 기준으로 줄이는 것" 은 그 주에 할 수 있다. 전환기의 QA에게 가장 먼저 필요한 것은 도구가 아니라 범위를 줄일 권한이다.

어느 방법론이 "정답"은 아니다

규제가 엄격한 의료기기 소프트웨어(스테이지 6 부록에서 다룬다)는 문서화 요구 때문에 워터폴적 요소가 강하게 남아있는 경우가 많고, 빠른 시장 대응이 중요한 스타트업은 칸반이나 스크럼을 선호한다. QA는 "어느 게 더 좋은 방법론인가"가 아니라, 지금 팀이 어떤 방법론을 쓰고 있고, 그 안에서 테스트 활동을 어떻게 맞춰 넣어야 하는지를 판단해야 한다.

그중 실무에서 가장 자주 만나는 스크럼 안에서 QA가 이벤트마다 실제로 무엇을 하는지 — 리파인먼트에서 던질 질문, 스토리 추정에 테스트 공수 넣기, 인수기준과 완료의 정의(DoD)의 차이, 회고에 가져갈 데이터 — 는 레슨 8 에서 이어 받는다.

실무에서 왜 필요한가

채용공고의 "애자일 환경에서의 QA 경험"이라는 문구는, 방법론 자체를 아는 것보다 테스트가 개발과 동시에 진행되는 빠른 리듬에 적응할 수 있는지를 묻는 것이다. 워터폴 경험만 있는 QA가 스크럼 팀에 들어가 "테스트 단계가 끝나야 다음으로 넘어간다"는 사고방식을 그대로 적용하면 팀 전체의 속도를 늦추게 된다. 방법론별 차이를 이해하면 새로운 팀에 합류했을 때 그 팀의 리듬에 맞춰 빠르게 적응할 수 있다.

리듬을 모르면 좋은 일을 해도 병목이 된다

QA가 꼼꼼한 것은 미덕인데, 리듬과 맞지 않으면 팀이 그것을 문제로 느낀다.

세 줄 모두 QA가 틀린 것은 아니다. 다만 리듬에 맞는 방식이 따로 있다 — 짧은 주기에서는 리스크로 범위를 줄이고, 칸반에서는 완벽보다 흐름을 택하고, 워터폴에서는 단계 기준에 맞춰 올린다.

방법론 전환을 요구할 조건을 말할 수 있게 된다

주기를 줄이자는 결정은 대개 QA 없이 내려진다. 그때 QA가 조건을 제시할 수 있어야 한다 — "주기를 절반으로 줄이면 회귀 시간이 가용 시간의 절반이 됩니다. 범위를 리스크로 줄이거나 스모크를 자동화하는 것이 선행 조건입니다."

이것은 반대가 아니라 조건 제시다. 거절당하더라도 기록이 남고, 석 달 뒤 결함이 늘었을 때 그 기록이 근거가 된다(모듈 6 레슨 3의 릴리즈 판단과 같은 태도).

채용시장에서의 위치

공고에 "애자일 환경 QA 경험" 이 거의 항상 적힌다. 그런데 면접에서 묻는 것은 용어가 아니라 리듬을 다뤄 본 경험이다.

세 번째가 워터폴 경력자에게 중요한 답이다. "배우겠다" 는 수동적으로 들리고, 무엇이 그대로 쓰이는지 말하는 것은 본질을 안다는 증거다. 실제로 테스트 기법·리스크·결함 관리는 방법론과 무관하다.

네 번째는 리드급 질문이다. 병목을 개인의 속도 문제로 보는 사람과 흐름의 문제로 보는 사람이 여기서 갈린다.

공고 표현으로는 "애자일 QA", "스크럼 환경", "CI/CD 환경 QA" 가 이 레슨에 걸린다. 스크럼 안에서의 구체적인 활동은 레슨 8, 조직과 역할 설계는 레슨 9 에서 이어 받는다.

실습 과제

과제 1 — 방법론 비교표 채우기 (10분)

"신규 기능 요구사항이 개발 중간에 바뀌었다"는 상황이 워터폴 팀과 스크럼 팀에서 각각 어떻게 다르게 처리될지 비교해서 적는다.

과제 2 — 내 상황에 맞는 QA 역할 설계 (10분)

칸반 보드로 작업하는 팀에 QA로 합류했다고 가정하고, "테스트 중" 열에 카드가 몰려 병목이 생기지 않으려면 QA가 어떤 습관을 가져야 할지 2가지를 적는다.

과제 3 — 새 팀 리듬 파악하기 (12분)

아래 팀에 QA로 합류했다. 다섯 질문의 답을 보고 이 팀이 실제로 어떤 리듬인지 판정하고, 가장 먼저 제안할 것 한 가지를 적는다.

• 배포 주기: 2주 (스크럼이라고 부른다)
• 완료의 정의: "개발 완료 + 코드 리뷰 통과"
• 회귀: 매 배포 전 전체 수동 4일
• QA 참여 회의: 스프린트 리뷰(마지막 날)만
• 릴리즈 판단: 개발 리드가 단독으로

자가 체크리스트

• 워터폴에서 테스트가 별도 단계로 진행되는 이유를 설명할 수 있다
• 스크럼에서 회귀 테스트 비중이 커지는 이유를 설명할 수 있다
• 칸반에서 QA가 어떻게 지속적으로 테스트에 참여하는지 설명할 수 있다
• 방법론에 정답이 없고, 팀의 맥락에 맞춰 QA 역할을 조정해야 한다는 것을 설명할 수 있다
• 방법론에 따라 바뀌는 네 가지(시점·단위·문서량·회귀 부담)를 말할 수 있다
• V-모델을 그리고, "테스트 설계는 앞에서 한다"는 뜻을 설명할 수 있다
• 워터폴이 합리적인 선택인 영역을 들 수 있다
• 미니 워터폴의 증상 셋과 그 해결(일의 단위 쪼개기)을 말할 수 있다
• 스프린트 앞부분에 QA가 할 일이 무엇인지 말할 수 있다
• WIP 제한이 왜 벌이 아니라 설계인지 설명할 수 있다
• 열별 체류 시간으로 병목의 원인을 가르는 방법을 안다
• 하이브리드 조합에서 생기는 문제(문서 이중 작업, 회귀 몰림)를 안다
• 주기를 줄일 때 QA가 선행 조건으로 제시할 것을 말할 수 있다
• 방법론과 무관하게 변하지 않는 QA 역량 네 가지를 들 수 있다
• 새 팀의 리듬을 파악하는 다섯 질문을 말할 수 있다

흔한 실수

• 워터폴 사고방식("테스트는 개발이 다 끝난 뒤")을 애자일 팀에 그대로 적용한다. 팀의 속도를 늦추는 병목이 된다.
• 애자일이 무조건 테스트를 덜 꼼꼼히 해도 된다는 뜻이라고 착각한다. 오히려 반복 주기가 짧아서 회귀 테스트 부담이 늘어난다.
• 방법론 이름만 외우고 그 방법론이 QA 역할에 실제로 어떤 변화를 주는지는 모른다. 면접에서 "애자일에서 QA는 뭐가 다른가요?"라는 질문에 구체적으로 답하지 못하게 된다.
• 스프린트 안에서 미니 워터폴을 돌린다. 이름만 스크럼이고 QA는 뒤 3일에 몰린다. 완료의 정의에 "QA 통과"를 넣는 것부터 시작한다.
• 스프린트 앞부분에 할 일이 없다고 생각한다. 인수기준 작성과 테스트 설계는 개발보다 먼저 하는 일이다.
• 주기를 줄이면서 회귀 대책을 세우지 않는다. 전환 실패의 가장 흔한 원인이고, QA가 조건으로 제시해야 할 가장 중요한 항목이다.
• 칸반에서 WIP 제한 없이 일한다. 들어오는 속도가 처리 속도보다 빠르면 쌓이는 것은 수학적으로 정해져 있다.
• 병목을 개인의 속도 문제로 본다. 더 빨리 하는 것으로는 해결되지 않는다. 열별 체류 시간으로 원인을 가린다.
• 애자일을 "문서 없음"으로 이해한다. 줄일 문서와 지킬 문서를 구분해야 추적성이 남는다.
• "2주마다 완료"라고 선언하고 석 달 뒤에 내보낸다. 형식은 스크럼이고 회귀 부담은 워터폴인 상태가 된다.
• 방법론 이름으로 팀을 판단한다. 완료의 정의에 테스트가 있는지만 보면 실제 리듬이 바로 드러난다.

참고 자료

• Lisa Crispin & Janet Gregory, Agile Testing — 애자일 환경에서의 QA 역할을 다룬 대표 저서
• ISTQB Glossary — Agile Testing — 애자일 테스트의 공식 용어 정의
• Scrum Guide (한국어) — 스크럼의 공식 정의. 완료의 정의(DoD)가 어떻게 규정되는지
• Atlassian — Kanban WIP 제한 — WIP 제한의 목적과 설정 방법

이 커리큘럼 안에서

• 모듈 7 레슨 8 — 스크럼 안에서 QA가 이벤트마다 하는 일. 이 레슨의 실전편
• 모듈 7 레슨 9 — 테스트 조직과 역할 설계
• 모듈 7 레슨 1 — 테스트 관리 도구. 하이브리드에서 보고서를 자동으로 뽑는 수단
• 모듈 2 레슨 6 — 요구사항 리뷰 참여. V-모델에서는 구조적 활동
• 모듈 3 — 테스트 설계 기법. 방법론과 무관하게 그대로 쓰인다
• 모듈 4 — 리스크 기반. 주기가 짧아질 때 범위를 줄이는 근거
• 모듈 6 레슨 5 — 과정 지표. 칸반의 체류 시간과 같은 접근
• 모듈 8 — 회귀 테스트. 주기 단축의 직접적인 부담
• 스테이지 4 — 자동화. 짧은 주기를 버티게 하는 수단

한 줄 정리 — 방법론은 테스트의 리듬을 정한다. 주기가 짧아지면 회귀 부담이 주기마다 반복되므로, 범위를 리스크로 줄이거나 자동화해야 한다. 이름이 스크럼이어도 완료의 정의에 QA가 없으면 미니 워터폴이고, 칸반의 병목은 개인의 속도가 아니라 WIP 제한으로 다룬다. 그리고 테스트 설계·리스크 판단·결함 품질은 어느 방법론에서나 같다.