폭포수 vs 반복적·점진적 개발 모델, 테스팅 전략은 어떻게 달라질까

폭포수, vs, 반복적, 점진적, 개발, 모델, 테스팅을 함께 이해해야 하는 이유는 단순합니다. 개발 방식이 달라지면 테스트를 언제 시작할지, 무엇을 증거로 남길지, 자동화를 어디에 먼저 붙일지까지 전부 달라지기 때문입니다. ISTQB 관점에서도 테스트는 개발 생명주기와 분리해서 볼 수 없고, 어떤 개발 모델을 쓰는지에 따라 테스트 활동의 시점과 강조점이 달라집니다. 현업이나 수업에서 이 주제를 설명할 때도, 모델 이름을 외우는 것보다 “품질 피드백이 언제 만들어지는가”를 먼저 보라고 안내하는 편이 이해가 빠릅니다.

같은 기능을 만들어도 왜 테스트 계획이 달라지는가

요구사항이 비교적 고정되어 있고 승인 절차가 강한 프로젝트라면, 테스트는 문서와 추적성을 중심으로 설계되는 경우가 많습니다. 반대로 기능이 자주 바뀌고 사용자 반응을 빠르게 확인해야 하는 서비스라면, 테스트는 짧은 주기 안에서 빠르게 판단하고 반복 확인하는 구조가 필요합니다.

이 차이를 가장 잘 보여주는 비교가 폭포수 모델과 반복적·점진적 개발 모델입니다. 둘 중 어느 하나가 절대적으로 우월하다고 말하기는 어렵습니다. 다만 결함이 드러나는 시점, 변경을 받아들이는 방식, 회귀 테스트의 부담이 다르므로 QA의 준비 방식도 달라져야 합니다.

폭포수 모델에서는 “나중에 테스트한다”는 오해부터 바로잡아야 한다

폭포수 모델은 요구사항 분석, 설계, 구현, 테스트, 배포처럼 단계가 순차적으로 이어지는 구조로 이해하면 됩니다. 문서가 명확하고 승인 절차가 정돈된 환경에서는 일정과 책임을 관리하기 쉽다는 장점이 있습니다. 규제 산업, 공공 영역, 계약 조건이 엄격한 프로젝트에서 아직도 이 접근이 사용되는 이유도 여기에 있습니다.

하지만 실무에서 문제는 “테스트 단계가 뒤에 있으니 QA도 뒤에 들어오면 된다”는 식의 해석입니다. 이때 결함은 늦게 발견되고, 수정 비용은 커집니다. 요구사항 문장 하나가 모호했는데 그것이 설계와 구현까지 굳어버리면, 테스트 실행 시점에는 이미 영향 범위가 커져 있는 경우가 많습니다.

그래서 폭포수 환경일수록 정적 테스팅이 중요합니다. 요구사항 리뷰, 설계 리뷰, 인수 기준 확인, 용어 일관성 검토가 초기에 이뤄져야 합니다. ISTQB에서도 조기 테스팅의 가치를 강조하는데, 폭포수 모델은 그 필요성이 더 선명하게 드러나는 구조라고 볼 수 있습니다.

특히 QA가 먼저 확인하면 좋은 질문은 다음과 같습니다.

• 요구사항이 테스트 가능한 문장으로 작성되어 있는가
• 승인 기준이 문서 안에 분명히 드러나는가
• 변경 요청이 생기면 어떤 절차로 반영되는가
• 요구사항과 테스트 케이스를 연결할 추적 기준이 있는가

이 네 가지가 불분명하면, 테스트 단계에서 발견되는 문제 중 상당수는 실행 문제가 아니라 해석 문제일 가능성이 높습니다.

반복적·점진적 개발 모델은 빠르지만, 테스트가 저절로 좋아지지는 않는다

반복적 개발은 같은 기능이나 제품을 여러 차례 다듬어 가는 접근에 가깝고, 점진적 개발은 기능 범위를 조금씩 늘려 가는 방식에 가깝습니다. 실제 현장에서는 둘이 함께 섞여 쓰이는 경우가 많습니다. 먼저 작은 증분을 만들고, 그 증분을 다음 반복에서 개선하는 식입니다.

이 방식의 강점은 피드백을 빨리 받는 데 있습니다. 짧은 주기마다 동작하는 결과물을 보고 문제를 확인할 수 있으니, 결함이 숨어 있는 기간이 상대적으로 짧아집니다. 다만 테스트 관점에서는 생각보다 만만하지 않습니다. 반복 주기가 짧으면 모든 것을 문서로 정리하고 난 뒤 테스트를 시작할 시간이 부족합니다. 무엇을 자동화할지, 무엇을 탐색적으로 볼지, 어디까지를 이번 반복의 품질 기준으로 삼을지를 빨리 결정해야 합니다.

이때 중요한 것은 “반복적이니 유연하다”는 말만 믿고 기록을 포기하지 않는 것입니다. 사용자 스토리, 인수 기준, 변경 이력, 회귀 범위는 최소한 남아야 합니다. 그래야 다음 반복에서 왜 테스트를 다시 해야 하는지 설명할 수 있고, 릴리스 직전에도 품질 상태를 근거 있게 말할 수 있습니다.

두 모델의 차이는 일정 방식보다 결함 발견 구조에서 더 분명하다

표면적으로 보면 폭포수는 순차적이고, 반복적·점진적 모델은 짧은 사이클을 반복합니다. 하지만 테스팅에서는 일정 형식보다 결함을 언제 어떻게 발견하는지가 더 중요합니다.

폭포수 모델에서는 후반 테스트의 비중이 커지기 쉬워서, 초기에 놓친 문제의 비용이 커집니다. 따라서 리뷰, 분석, 추적성 관리가 강한 전략이 잘 맞습니다. 반면 반복적·점진적 개발에서는 각 반복마다 테스트가 계속 수행되므로, 빠른 회귀 확인과 변경 영향 분석이 중요해집니다. 같은 결함 관리라도 폭포수에서는 누락 없는 문서화가 더 중요해질 수 있고, 반복적 환경에서는 수정 이후의 영향 범위를 짧은 시간 안에 판단하는 역량이 더 중요해집니다.

예를 들어 로그인 기능 하나가 바뀌었다고 해보면, 폭포수에서는 관련 요구사항과 설계 문서가 정확히 반영됐는지 먼저 따져보게 됩니다. 반복적·점진적 환경에서는 이번 변경이 인증, 세션, 권한, 비밀번호 정책, 기존 자동화 스위트에 어떤 영향을 주는지부터 빠르게 보게 됩니다. 같은 기능을 테스트해도 접근 순서가 다릅니다.

수업에서 학생들이 가장 많이 실수하는 부분은 모델 이름과 테스트 시점을 동일시하는 점이다

이 주제를 강의나 스터디에서 다룰 때 자주 보이는 실수가 있습니다. 폭포수 모델이면 테스트는 맨 마지막, 반복적 모델이면 테스트는 항상 잘 되고 자동화도 자연스럽게 붙는다고 이해하는 경우입니다. 직접 정리해 보니 초보자가 헷갈리는 지점은 개발 모델 자체보다 “QA가 언제 개입해야 하는가”였습니다.

폭포수에서도 QA는 초기에 들어가야 합니다. 요구사항이 모호하면 뒤에서 아무리 열심히 실행 테스트를 해도 기준이 흔들립니다. 반대로 반복적·점진적 개발에서도 테스트는 자동으로 민첩해지지 않습니다. 짧은 주기일수록 오히려 테스트 범위를 줄이고 우선순위를 정해야 하므로, 더 높은 판단력이 필요합니다.

실습 과제를 검토할 때도 비슷했습니다. 학생들은 반복 주기라는 말에 집중한 나머지 회귀 테스트 부담을 과소평가하는 경향이 있었습니다. 그런데 실제로는 기능이 조금씩 늘어날수록 “이전 기능이 아직 살아 있는가”를 확인하는 비용이 커집니다. 그래서 반복적·점진적 개발 모델에서는 자동화 전략을 늦게 세우면 나중에 훨씬 더 힘들어집니다.

자동화는 어느 쪽이 더 절실한가

두 모델 모두 테스트자동화의 가치는 있습니다. 다만 목적이 조금 다릅니다.

폭포수 모델에서는 대규모 통합 이후 최종 회귀 테스트를 효율적으로 돌리기 위해 자동화가 도움이 됩니다. 릴리스 직전 동일한 확인을 반복해야 할 때 수동 테스트만으로는 시간이 빠듯할 수 있기 때문입니다.

반복적·점진적 개발 모델에서는 자동화의 필요성이 더 자주, 더 일찍 드러납니다. 변경이 계속 발생하고 배포 주기가 짧으면, 기존 기능이 깨지지 않았는지 매번 확인해야 합니다. 여기서 자동화는 선택 사항이 아니라 피드백 속도를 유지하는 장치에 가깝습니다.

다만 아무 기능이나 먼저 자동화하는 것은 좋은 전략이 아닙니다. 실무에서는 보통 다음 순서로 우선순위를 봅니다.

• 로그인, 결제, 권한 같은 핵심 업무 흐름인지
• 실행 빈도가 높고 반복 가치가 큰지
• 기대 결과가 명확해 자동화 판정이 쉬운지
• UI보다 API나 서비스 계층에서 더 안정적으로 검증할 수 있는지
• 실패했을 때 원인 분석 로그를 남기기 쉬운지

직접 테스트 설계를 검토할 때도, 화면이 자주 바뀌는 초기 기능에 UI 자동화를 성급하게 붙였다가 유지보수 비용만 커지는 경우를 자주 봤습니다. 반복적 개발이라고 해서 UI 자동화를 무조건 먼저 넣는 것은 위험할 수 있습니다.

프로젝트 초기에 무엇을 확인하면 모델 선택과 무관하게 도움이 되는가

개발 모델이 무엇이든, QA가 초기에 점검해야 할 기준은 비교적 공통적입니다. 다만 보는 이유가 모델마다 다릅니다.

폭포수라면 문서 품질과 승인 체계를 통해 후반 리스크를 줄여야 하고, 반복적·점진적 개발이라면 짧은 주기 안에서 빠르게 판단할 근거를 확보해야 합니다. 그래서 다음 항목은 초반 점검 대상으로 두기 좋습니다.

• 요구사항이 검증 가능한 표현으로 작성되어 있는지
• 기능별 인수 기준이 합의되었는지
• 테스트 환경과 운영 환경의 차이를 알고 있는지
• 변경 발생 시 영향 분석과 반영 절차가 있는지
• 회귀 테스트 범위를 어떤 기준으로 정하는지
• 자동화 후보를 업무 중요도와 안정성 기준으로 선별했는지
• 결함의 심각도와 우선순위를 팀이 같은 의미로 쓰는지
• 릴리스 전 통과해야 할 품질 게이트가 무엇인지

이 기준은 단순 체크리스트라기보다, 테스트 전략을 실제 프로젝트에 맞게 조정하기 위한 질문에 가깝습니다. 문서가 많은 프로젝트에서는 추적성이 더 중요해지고, 배포가 잦은 프로젝트에서는 회귀 속도와 자동화 범위가 더 중요해집니다.

어떤 모델이 더 낫다고 묻기보다, 어떤 리스크를 더 잘 다룰 수 있는지 봐야 한다

현장에서 정말 필요한 판단은 “무조건 애자일이 좋다” 또는 “문서가 많아야 안전하다” 같은 구호가 아닙니다. 요구사항 변동성이 큰지, 규제와 승인 증적이 중요한지, 사용자 피드백을 빨리 반영해야 하는지, 팀이 자동화와 지속적 통합을 감당할 수 있는지를 같이 봐야 합니다.

폭포수 모델은 명확한 승인 체계와 문서 증거가 필요한 환경에서 강점이 있습니다. 대신 조기 리뷰가 약하면 후반 결함 비용이 커집니다. 반복적·점진적 개발 모델은 변화 대응과 빠른 학습에 강하지만, 회귀 관리와 자동화 기반이 약하면 품질이 쉽게 흔들릴 수 있습니다.

테스팅 관점에서 정리하면 결국 질문은 하나로 모입니다. 지금 우리 팀은 어떤 방식으로 가장 빠르고 신뢰할 수 있는 품질 피드백을 만들 수 있는가. 개발 모델 비교는 그 질문에 답하기 위한 출발점입니다.

참고 자료

• [ISTQB Certified Tester Foundation Level](https://www.istqb.org/certifications/certified-tester-foundation-level)
• [ISTQB Glossary](https://glossary.istqb.org/)