SDLC(Software Development Life Cycle), 즉 개발 방법론에서 QA의 역할을 공부해 보다가 정리해 볼 겸 작성하는 포스팅입니다 :)
포스팅에서 나오는 자료는 Simplilearn 자료를 참고하여 작성하였습니다. (https://www.simplilearn.com/)
SDLC를 간단하게 알아본다면...?
새로운 가게 창업을 하고 싶을 때 어떤 방식으로 진행할까요 ?
창업 박람회나 다방면으로 자료 조사를 하며 하고 싶은 업종을 찾고, 어디서 매장을 오픈할지 고민하며 임대 계약을 하고, 어떤 식으로 영업할지를 고민하며 매장을 꾸미고, 매출을 올릴지 생각해 보며 창업 과정을 진행할 것 같습니다.
새로운 창업에도 어떤 것을 할지 설계하고, 관련 업종을 분석하여 매장을 구축하고 고객 유지를 하는 것처럼 개발 과정에도 체계적인 방식이 있습니다.
새로운 프로젝트나 제품을 만들기 위해서는 어떤 과정을 거쳐야 할까요?

새로운 소프트웨어를 개발할 때 "계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 배포" 과정을 거쳐 개발하는 방식을 주로 사용하고 있습니다.
이것을 Software Development Life Cycle, 줄여서 SDLC라고 부르고 업무에 활용하고 있습니다.
한 단계씩 가볍게 알아볼까요?
단계를 설명하면서 QA의 역할도 하나씩 연결해 보겠습니다.

계획 단계에서는 제품을 사용하는 클라이언트가 있다면 함께, 없다면 제품을 사용할 고객을 예상해서 계획 단계를 진행합니다.
제품의 목적을 확인하고 어떤 사용자가 어떤 방식으로 제품을 사용할지를 생각하며 제품 전체를 계획하게 됩니다.
계획 단계에서의 QA 역할은 사용자가 원하는 기능이 무엇일지, 불필요한 기능은 아닐지 PM, 개발자와 같이 고민해 보며 어떤 식으로 사용자가 사용할지 시나리오도 구상해 볼 수 있는 단계입니다.

요구사항 분석 단계에서는 구상된 기획안을 바탕으로 기능은 어떻게 제공하며 부족한 기능은 어떤 것이 있을지, 계획 단계에서 놓친 기능은 없는지, 위험적인 요소는 없는지 확인하는 작업을 거치게 됩니다.
요구사항 분석 회의, 워크샵, 킥오프 등 개발, 기획, 품질팀 다 함께 제품 개발에 대한 방향을 확인하는 회의를 거친 후 다음 설계 작업을 진행하게 됩니다.
요구사항 분석 단계에서 QA의 역할은 제품의 위험적인 요소는 없는지, 개선할 부분이 있으면 의견을 공유하는 역할을 수행합니다. 단순 개선 의견을 주는 것 이상으로, 개발이 된 후 수정된다면 비용이 매우 증가하기 때문에 리스크를 사전에 파악해서 공유하는 역할을 수행하는 것이 QA의 중요한 역할이라고 생각됩니다 🤔
설계 단계에서는 PC, Mobile 등 다양한 환경에서 어떻게 제공할지 검토하고 계획된 기능들을 구현할 수 있는지, 어떤 기술을 사용할지 고민해서 아키텍처를 구성하고 어떻게 개발을 진행할지 설계합니다.
설계 단계에서의 QA의 역할은 기능을 어떻게 테스트할지 생각해 보며 필요한 환경, 인력 자원, 일정을 확인하며 검증 방식에 대한 설계를 진행하게 됩니다.
이 과정에서 사용할 수 있는 자원을 확인하고 예상되는 테스트 기간을 확인하며, 일정이 부족하다면 개발 과정 중에 어떤 식으로 테스트를 진행하여 효율적인 일정 관리를 할 수 있을지 고민하게 됩니다.
그리고 테스트 종료 기준(Sign-Off)을 수립합니다. 예를 들면 선정된 TC를 100% 수행하고, 발생한 결함의 우선순위 중 중결함 이상 건은 0건이어야 한다, 사전에 협의된 성능 기준을 통과해야 한다 등 종료 기준을 수립하기도 합니다.
품질 팀의 규모가 크고 힘이 강한 곳이라면 더더욱 체계적으로 수립할 수 있을 것 같습니다.

구현 단계에서는 말 그대로 제품에 대한 개발을 시작합니다. 앞선 설계 과정에서 작성된 설계 문서를 기반으로 개발이 진행됩니다.
구현 단계에서 QA의 역할은 역시 Test Case 작성이나 자동화 스크립트 작성이겠죠?
그러나 개인적인 의견이지만, 저는 구현 단계에서 가장 중요한 부분은 소통이라고 생각합니다.
사전에 계획된 대로 설계되며 안정적으로 개발된다. 정말 이상적인 얘기라고 생각되는 부분이지만 현실은 조금 다를 수 있습니다.
구현 과정에서 이슈는 항상 발생하고, 이때 일정이나 기능에 대한 변경 사항이 발생할 수 있으니까요 😢
이런 상황에서 기획서를 기반으로 TC 작성만 하게 된다면 테스트할 때 변경된 기능을 파악하지 못해서 거짓양성 이슈를 유발할 수 있습니다
이는 곧 전체적인 일정 증가 효과로... 😵💫 😵💫
그래서 구현은 설계대로 진행되고 있는 것인지, 변동사항은 없는지 항시 확인하고 소통하며 구현 단계를 진행하는 것을 추천드립니다. 개발 회의 때 QA가 참여하거나 회의록이 있다면 내용을 검토하면서 변동사항을 따라가는 것이 좋겠죠!
테스트 단계에서는 QA 및 테스터가 가장 일을 열심히 해야 하는 단계!
요구사항대로 기능이 구현되어있는지 확인하고, 작성한 TC를 수행하며 결함을 확인하고 BTS 도구를 통해 결함을 제공합니다.
필요시 성능 테스트, 보안 테스트 등 비기능 테스트도 함께 진행하며 품질 지표를 제공하기 위한 작업을 진행합니다.

배포 단계에서는 테스트가 완료된 제품을 고객사에 납품, 앱스토어에 등록 등 사용자에게 제공하기 위한 과정을 진행합니다.
개발서버와 라이브 서버에서 발생할 수 있는 부분은 다를 수 있기 때문에 배포 후 모니터링도 중요한 단계입니다.
배포 단계에서 QA의 역할은 라이브 서버에서 제품 이상이 없는지 확인하고, 이후 사용자의 제품 사용 의견을 검토하여 사용자의 다양한 관점을 확인해 볼 수 있고, 테스트 단계에서 결함 수정이 덜 된 부분에 대한 패치 일정을 확인하고 후처리 작업도 계획할 수 있을 것 같습니다.
분명 간단하게 정리한다고 글을 썼는데 왜 이리 길어졌을까...?
SDLC를 사용하는 모델은?
SDLC의 과정을 활용하는 모델은 정말 다양합니다.

폭포수 모델(Waterfall Model), 나선형 모델(Spiral Model), V 모델(V-Model), 애자일 모델(Agile Model) 등 체계적인 과정을 구성하기 위한 다양한 모델들이 있지만, 이번 포스팅에서는 제가 경험해 본 폭포수 모델과 애자일 모델에 대해 간단하게 알아보겠습니다.
폭포수 모델(Waterfall Model)

폭포수 모델은 이름처럼 SDLC의 각 단계를 폭포처럼 하나씩 진행한다는 의미입니다.
각 단계가 구분되어 있어서 순차적으로 진행될 수 있고, 체계적인 문서화로 프로젝트의 진행 상황을 명확하게 확인할 수 있다는 장점이 있기 때문에, 요구사항이 명확한 프로젝트에서 적합하게 활용할 수 있는 모델입니다.
그러나, 떨어진 물이 다시 올라오지 않는 것처럼 앞 단계에서 구성된 방식을 변경하지 않고 진행하기 때문에 리스크가 큰 모델이기도 합니다.
진행 과정은 명확하나 개발건의 수정이 필요하다면 큰 비용이 발생할 수 있습니다.
폭포수 모델에서 QA는 각 단계가 구분되어 있는 만큼 단계마다 확실하게 검토해야 하며, 테스트 단계에서만 작업하는 것이 아닌 전체적인 부분에서 참여하는 Shift-left 방식을 적극 활용하여 업무를 진행해야 합니다.
애자일 모델(Agile Model)

Agile의 뜻처럼 신속하게 업무를 처리하는 방식으로 적게는 2주 단위로 SDLC의 전체 과정을 진행합니다.
기능을 작은 단위로 나누어 빠르게 처리하고 사용자에게 신규 기능을 빠르게 제공할 수 있는 방식입니다.
팀 간 지속적인 소통을 통해 피드백을 수용하기 때문에 요구사항 변경이 발생할 수 있으며, 작은 단위로 구성하기 때문에 유연한 대처가 가능하다는 장점이 있습니다.
애자일 모델에서 QA는 스프린트 범위 내에 수행할 테스트 계획, 테스트 수행도 중요하지만, 소통이 가장 중요하다고 생각됩니다.
기획 변경사항에 대해 항시 숙지하고 있어야 하며, 변경된 기능에 대한 TC 유지보수, E2E 테스트 스크립트 변경도 자주 발생할 수 있기 때문에 항상 귀를 열어두고 업무를 진행해야 합니다.
짧은 주기로 반복되어 작업이 진행되기 때문에 쉴 틈 없이 새로운 기능을 확인하고 검증해야 하는 과정이 업무적으로 힘들긴 했었습니다. 😂
SDLC를 알고 있었지만, 체계적으로 정리해보진 않았어서 정리할 겸 포스팅을 하게 되었고, 각 모델에서 QA의 역할을 다시 한번 생각해 보기 위해 작성해 봤습니다.
내용 자체는 SDLC에 대한 설명이 길어지긴 했지만... 결과적으로 QA로 업무를 진행하면서 중요한 것은 소통이라고 생각하고, 이 스킬을 어떻게 향상할 수 있을지는 계속 고민해 봐야겠습니다 🤔
다음엔 SDLC 과정에서 QA의 역할을 더 상세하게 분석할 수 있는 STLC에 대한 포스팅을 작성해 보겠습니다 :)
STLC 관련 내용은 아래 포스팅을 참고해주세요!
2025.10.20 - [QA/업무 방식] - 테스트? 그냥 하면 되는거 아니야? STLC란? 무엇...?
테스트? 그냥 하면 되는거 아니야? STLC란? 무엇...?
테스트라는 단계를 가볍게 생각할수록 개발이 중요한 거지, 테스트? 그냥 오류 없는지 확인하면 되는 거 아닌가?라고 생각될 수 있습니다. 하지만, 테스트..? 어떤 테스트를 어떻게 할건데? 우린
qa-subi.tistory.com
참고자료
https://youtu.be/Fi3_BjVzpqk?si=XLUEygT4eNE6L92d
https://www.geeksforgeeks.org/software-engineering/sdlc-models-types-phases-use/
A Complete Guide to SDLC Models | Types, Phases, When to use - GeeksforGeeks
Your All-in-One Learning Portal: GeeksforGeeks is a comprehensive educational platform that empowers learners across domains-spanning computer science and programming, school education, upskilling, commerce, software tools, competitive exams, and more.
www.geeksforgeeks.org
'QA > 업무 방식' 카테고리의 다른 글
| 테스트? 그냥 하면 되는거 아니야? STLC란? 무엇...? (2) | 2025.10.20 |
|---|---|
| QA 업무를 진행하면서 AI를 활용한 방법 (0) | 2025.09.30 |
| 테스트 레벨 별 비정상 테스트 케이스 작성 방식 (매뉴얼 TC) (3) | 2025.08.24 |
| 테스트 레벨 별 네거티브 테스트케이스 작성 방식 (API TC) (3) | 2025.08.16 |
| TC(Test Case)는 어떤 기준으로 작성하나요? (4) | 2024.12.09 |