새로운 AI SDLC에서 QA의 역할

새로운 AI SDLC (Software Development Life Cycle)에서 QA (Quality Assurance)의 역할은 더 이상 단순히 **“완성된 애플리케이션을 테스트하는 것”**에 그치지 않습니다.

이제 QA는 **전체 생애주기에 걸친 품질 엔지니어링 (Quality Engineering)**으로 진화하고 있습니다:

요구사항 (Requirements)
프롬프트 (Prompts)
데이터 (Data)
모델 (Models)
생성된 코드 (Generated code)
자동화 (Automation)
배포 (Deployment)
모니터링 (Monitoring)
거버넌스 (Governance)
프로덕션 피드백 (Production feedback)

가장 큰 변화는 다음과 같습니다:

기존 SDLC QA: 소프트웨어가 요구사항을 충족하는가?

새로운 AI SDLC QA: 시스템, AI가 생성한 작업물, 데이터, 모델의 동작, 그리고 전달 프로세스를 반복 가능하고, 안전하며, 측정 가능한 방식으로 신뢰할 수 있는가?

AI는 QA를 없애지 않습니다.

오히려 강력한 QA 리더십을 더욱 중요하게 만듭니다.

AI SDLC 품질 루프 (The AI SDLC Quality Loop)

dev.to에 처음 게시할 때는 Mermaid 대신 간단한 텍스트 다이어그램을 사용하는 것이 좋습니다. 이는 dev.to/new 에디터에 복사하여 붙여넣기에 더 안전하며, 렌더러(renderer)의 예기치 않은 오류를 방지할 수 있습니다.

비즈니스 니즈 / 제품 아이디어 (Business Need / Product Idea)
        ↓
요구사항 + 리스크 정의 (Requirements + Risk Definition)
...

QA는 이 흐름의 끝에 앉아 있는 것이 아닙니다.

QA는 전체 루프에 영향을 미칩니다:

QA / 품질 엔지니어링 (QA / Quality Engineering)
        ↳ 요구사항 (Requirements)
        ↳ 사양 (Specs)
...

1. 요구사항 및 리스크 정의 (Requirements and Risk Definition)

QA는 코드가 존재하기 전부터 참여해야 합니다.

AI 기반 시스템의 경우, 요구사항에는 기능적 동작뿐만 아니라 리스크, 신뢰성, 그리고 가드레일 (guardrails)이 포함되어야 합니다.

QA는 다음을 정의하는 데 도움을 줍니다:

“좋은” 출력물이 어떤 모습인지
“나쁜” 출력물이 어떤 모습인지
AI가 절대로 해서는 안 되는 행동
인간의 승인이 필요한 사항
자동화된 검증 (automated validation)이 필요한 사항
완화 (mitigation)가 필요한 리스크
해결해야 할 보안, 개인정보 보호, 컴플라이언스 (compliance), 편향성 (bias), 환각 (hallucination), 그리고 설명 가능성 (explainability) 문제

이것은 AI SDLC에서 가장 중요한 변화 중 하나입니다.

QA는 프로세스의 끝까지 기다렸다가 시스템에 품질을 주입하려고 시도해서는 안 됩니다. 품질 전략은 시작 단계부터 수립되어야 합니다.

2. 사양 기반 개발 및 테스트 가능한 의도 (Spec-Driven Development and Testable Intent)

AI SDLC에서 사양 (specification)은 덜 중요해지는 것이 아니라, 더욱 중요해집니다.

만약 AI 에이전트(AI agents)나 코파일럿(copilots)이 코드, 테스트, 문서 또는 워크플로(workflows)를 생성한다면, QA는 AI가 유용한 결과물을 생성할 수 있도록 사양(specification)을 충분히 정밀하게 만드는 데 도움을 주어야 합니다.

QA는 다음 사항들을 추진해야 합니다:

명확한 비즈니스 규칙 (business rules)
예시 (Examples)
반례 (Counterexamples)
엣지 케이스 (Edge cases)
부정적 시나리오 (Negative scenarios)
테스트 데이터 가정 (Test data assumptions)
명시적인 품질 게이트 (Explicit quality gates)
요구사항부터 증거까지의 추적성 (Traceability from requirement to evidence)

유용한 추적성 체인(traceability chain)은 다음과 같습니다:

요구사항 (Requirement) → 프롬프트/사양 (Prompt/Spec) → 생성된 코드 (Generated Code) → 테스트 (Tests) → 증거 (Evidence)

이 지점이 바로 QA가 단순한 결함 발견자(defect finder)를 넘어, **정확성의 시스템 설계자 (system designer of correctness)**가 되는 지점입니다.

3. 프롬프트, 에이전트 및 워크플로 검증 (Prompt, Agent, and Workflow Validation)

현재 많은 엔지니어링 팀들이 Claude Code, GitHub Copilot, Cursor, ChatGPT 및 내부 AI 에이전트(internal AI agents)와 같은 도구들을 사용하여 소프트웨어 산출물(artifacts)을 생성하거나 수정하고 있습니다.

이는 QA 또한 프롬프트(prompts), 기술(skills), 컨벤션(conventions) 및 워크플로(workflows) 자체를 테스트하는 데 도움을 주어야 함을 의미합니다.

QA는 AI 워크플로가 다음을 준수하는지 검증해야 합니다:

일관된 결과 생성
아키텍처 표준 준수
유용하고 유지보수 가능한 테스트 생성
환각된 API (hallucinated APIs) 또는 잘못된 가정 방지
보안 및 데이터 처리 규칙 준수
엣지 케이스 (edge cases) 처리
리포지토리 컨벤션 (repository conventions) 준수
컴파일되고, 실행되며, 올바르게 동작하는 코드 생성

AI QE 아키텍트(AI QE Architects)들에게 이는 중대한 기회입니다.

강력한 QA 기능은 재사용 가능한 프롬프트, 기술, 컨벤션, 문서 및 평가 체크 항목을 생성하여, 팀이 지속적으로 더 나은 소프트웨어와 더 나은 테스트를 생성할 수 있도록 할 수 있습니다.

4. AI 지원 테스트 생성, 그러나 검토를 동반할 것 (AI-Assisted Test Generation, But With Review)

AI는 많은 양의 테스트를 빠르게 생성할 수 있습니다.

이는 유용합니다.

하지만 그 테스트들이 의미가 있는지 아무도 확인하지 않는다면 위험하기도 합니다.

QA의 역할은 AI가 생성한 테스트가 다음을 충족하도록 보장하는 것입니다:

관련성 (Relevant)
가능한 경우 결정론적 (Deterministic)
유지보수 가능성 (Maintainable)
적절한 범위 설정 (Properly scoped)
단순한 해피 패스(happy-path) 커버리지에 그치지 않음
실제 비즈니스 리스크와 연결됨
CI/CD에서 안정적으로 실행됨
인간이 신뢰할 수 있는 증거를 생성함

함정은 다음과 같은 믿음입니다:

테스트가 자동으로 많아진다는 것이 더 나은 품질을 의미하지는 않습니다.

그렇지 않습니다.

QA는 AI가 생성한 테스트가 피상적(shallow), 중복적(duplicated), 취약적(brittle)이거나 오해의 소지가 있는(misleading) 경우가 없도록 경계해야 합니다.

목표는 단순히 양을 늘리는 것이 아닙니다. 목표는 유용한 커버리지(coverage), 의미 있는 검증(validation), 그리고 신뢰할 수 있는 출시 증거(release evidence)를 확보하는 것입니다.

5. 데이터 품질 및 모델 동작 (Data Quality and Model Behavior)

머신러닝 (Machine Learning), 대규모 언어 모델 (LLM), 추천 (recommendations), 분류 (classification), 점수 산정 (scoring), 요약 (summarization) 또는 예측 (prediction)을 사용하는 시스템의 경우, 이제 QA는 데이터와 모델의 동작 (model behavior)도 신경 써야 합니다.

여기에는 다음 사항이 포함됩니다:

테스트 데이터 품질 (Test data quality)
학습 및 평가 데이터 가정 (Training and evaluation data assumptions)
편향 및 대표성 (Bias and representativeness)
모델 동작을 위한 회귀 세트 (Regression sets for model behavior)
프롬프트-응답 평가 (Prompt-response evaluation)
골든 데이터셋 (Golden datasets)
드리프트 탐지 (Drift detection)
정확도 (Accuracy)
정밀도 (Precision)
재현율 (Recall)
거짓 양성 (False positives)
거짓 음성 (False negatives)
작업별 점수 산정 (Task-specific scoring)
인간 검토 워크플로우 (Human review workflows)

전통적인 소프트웨어 테스트는 보통 코드가 결정론적 규칙 (deterministic rules)을 따르는지 묻습니다.

AI 시스템은 종종 더 넓은 질문을 요구합니다:

시스템이 받게 될 실제 세계의 입력값들에 대해 동작이 수용 가능하고, 안전하며, 신뢰할 수 있는가?

이를 위해서는 평가 전략 (evaluation strategy), 모니터링 (monitoring), 그리고 인간의 판단 (human judgment)이 필요합니다.

6. CI/CD 품질 게이트 (CI/CD Quality Gates)

QA는 품질이 낮은 AI 생성 또는 AI 지원 변경 사항이 프로덕션 (production)에 도달하는 것을 방지하는 자동화된 게이트 (automated gates)를 정의하는 데 도움을 주어야 합니다.

예시로는 다음이 있습니다:

단위 테스트 (Unit tests)
API 테스트 (API tests)
UI 테스트 (UI tests)
통합 테스트 (Integration tests)
계약 테스트 (Contract tests)
엔드 투 엔드 테스트 (End-to-end tests)
정적 분석 (Static analysis)
의존성 스캔 (Dependency scans)
보안 스캔 (Security scans)
프롬프트 평가 스위트 (Prompt evaluation suites)
LLM 응답 회귀 체크 (LLM response regression checks)
접근성 체크 (Accessibility checks)
성능 체크 (Performance checks)
합성 프로덕션 체크 (Synthetic production checks)
테스트 커버리지 임계값 (Test coverage thresholds)
AI 생성 코드에 대한 코드 리뷰 규칙 (Code review rules for AI-generated code)
배포 전 필수 출시 증거 (Required release evidence before deployment)

목표는 모든 사람의 속도를 늦추는 것이 아닙니다.

목표는 빠른 전달 (fast delivery)을 안전하게 만드는 것입니다.

이는 AI가 팀의 코드 생성 속도를 높일 때 특히 중요합니다.

더 강력한 품질 게이트 (quality gates) 없이 생성 속도만 빨라지는 것은 단순히 리스크를 가속화할 뿐입니다.

7. 프로덕션 모니터링 및 피드백 루프 (Production Monitoring and Feedback Loops)

AI 시스템은 주변 환경이 변화함에 따라 출시 후 성능이 저하될 수 있습니다.

변화할 수 있는 요소들은 다음과 같습니다:

데이터 (Data)
사용자 행동 (User behavior)
프롬프트 (Prompts)
모델 (Models)
제3자 API (Third-party APIs)
비즈니스 기대치 (Business expectations)
보안 위협 (Security threats)
규제 요구사항 (Regulatory expectations)

따라서 QA는 다음과 같은 활동을 통해 출시 후에도 계속 관여해야 합니다:

관찰 가능성 (Observability)
결함 트렌드 분석 (Defect trend analysis)
모델 및 프롬프트 성능 모니터링 (Model and prompt performance monitoring)
데이터 드리프트 체크 (Data drift checks)
행동 드리프트 체크 (Behavior drift checks)
사용자 피드백 검토 (User feedback review)
인시던트 분석 (Incident analysis)
테스트 스위트의 지속적 개선 (Continuous improvement of test suites)
출시 품질 지표 (Release quality metrics)

이는 가장 큰 사고방식의 전환 중 하나입니다:

프로덕션 (Production)이 테스트 전략의 일부가 됩니다.

AI SDLC에서 테스트는 배포(deployment) 시점에 멈추지 않습니다.

프로덕션에서의 동작은 요구사항, 사양(specs), 테스트, 프롬프트, 그리고 거버넌스(governance)로 다시 피드백되는 품질 정보의 원천이 됩니다.

8. 거버넌스 및 감사 가능성 (Governance and Auditability)

AI는 증거에 대한 새로운 필요성을 창출합니다.

QA는 증거 추적(evidence trail)을 소유하거나 강력하게 영향을 미칠 수 있습니다.

이는 다음 사항들을 문서화하는 것을 의미합니다:

무엇을 테스트했는가
어떤 모델, 프롬프트, 또는 버전이 사용되었는가
어떤 데이터가 사용되었는가
어떤 리스크가 고려되었는가
어떤 인간의 승인(human approvals)이 이루어졌는가
알려진 제한 사항 중 무엇이 남아있는가
어떤 모니터링이 구축되어 있는가
왜 해당 출시가 수용 가능한 것으로 간주되었는가

이는 규제 환경에서 중요하지만, AI를 책임감 있게 사용하려는 모든 기업에게도 중요합니다.

거버넌스는 단순한 서류 작업이 아닙니다.

훌륭한 거버넌스는 팀이 리스크를 이해했고, 올바른 항목을 테스트했으며, 정보에 기반한 출시 결정을 내렸음을 증명할 수 있도록 돕습니다.

새로운 QA의 직함은 “품질 아키텍트 (Quality Architect)”에 더 가깝습니다

AI SDLC에서 QA는 마지막 단계의 수동 검증(manual validation)보다는 신뢰할 수 있는 전달 시스템을 설계하는 역할에 더 가까워집니다.

영역	QA / QE 책임 범위
제품 아이디어	초기 단계에서 품질 리스크 식별
...

전통적인 QA vs. AI SDLC QA

전통적인 QA (Traditional QA)

요구사항 (Requirements) → 코드 (Code) → 테스트 (Test) → 출시 (Release)

전통적인 QA는 종종 프로세스 후반부에 투입되어 다음과 같이 질문합니다:

소프트웨어가 요구사항을 충족하는가?

AI SDLC QA

리스크 (Risk) → 명세 (Spec) → 프롬프트 (Prompt) → 생성된 코드 (Generated Code) → 테스트 (Test) → 게이트 (Gate) → 모니터링 (Monitor) → 개선 (Improve)

AI SDLC QA는 초기 단계부터 투입되어 지속적으로 다음과 같이 질문합니다:

이것이 정확하고, 안전하며, 유지보수 가능하고, 관찰 가능하며, 목적에 적합하다는 것을 어떻게 알 수 있는가?

쉬운 설명 버전

QA는 다음과 같은 질문에 답하는 그룹이 되어가고 있습니다:

이 AI 보조 시스템이 정확하고, 안전하며, 유지보수 가능하고, 관찰 가능하며, 목적에 적합하다는 것을 어떻게 알 수 있는가?

이는 전통적인 테스트보다 훨씬 더 큰 역할입니다.

또한 이는 숙련된 QA 아키텍트(Architect)들에게 거대한 기회이기도 합니다. 왜냐하면 AI는 취약한 엔지니어링 프로세스를 더 악화시키고, 강력한 엔지니어링 프로세스를 더 빠르게 만들기 때문입니다.

QA의 역할은 조직이 첫 번째 결과가 아닌, 두 번째 결과(강력한 프로세스)를 얻을 수 있도록 보장하는 것입니다.

결론 (Bottom Line)

새로운 AI SDLC에서 QA는 단순히 소프트웨어를 테스트하는 것이 아닙니다.

QA는 조직이 다음과 같은 시스템을 구축하도록 돕는 것입니다:

정확한 (Correct)
안전한 (Safe)
신뢰할 수 있는 (Trustworthy)
유지보수 가능한 (Maintainable)
관찰 가능한 (Observable)
거버넌스가 적용된 (Governed)
측정 가능한 (Measurable)
프로덕션 준비가 된 (Ready for production)
지속적으로 개선되는 (Continuously improving)

AI는 QA를 대체하지 않습니다. AI는 강력한 QA 리더십을 더욱 중요하게 만듭니다.

참고 문헌 (References)

다음 참고 문헌들은 AI SDLC 내에서의 QA 모델을 정립하는 데 유용합니다.

NIST AI Risk Management Framework 1.0

NIST는 거버넌스(Governance), 매핑(Mapping), 측정(Measurement), 관리를 통해 AI 리스크를 생각할 수 있는 실질적인 프레임워크를 제공합니다.

리스크 정의, 측정, 모니터링, 거버넌스 및 라이프사이클 책임(Lifecycle accountability) 측면에서 QA의 역할을 뒷받침하는 데 유용합니다.

https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf

Google Cloud: MLOps Continuous Delivery and Automation Pipelines in Machine Learning

Google Cloud의 MLOps 가이드는 왜 머신러닝(Machine Learning) 시스템에 CI/CD, 지속적 학습(Continuous Training), 자동화, 모니터링 및 프로덕션 피드백 루프가 필요한지 설명합니다.

AI 품질이 일회성 테스트 이벤트가 아니라는 아이디어를 뒷받침하는 데 유용합니다.

https://docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

Google Cloud: MLOps 실무자 가이드 (Practitioners Guide to MLOps)

이 가이드는 라이프사이클(Lifecycle) 관행, 자동화, 모니터링 및 프로덕션 준비 상태를 포함하여 ML 시스템을 운영화하는 것에 대한 더 넓은 관점을 제공합니다.

엔드 투 엔드(End-to-end) ML 시스템 품질 측면에서 QA의 역할을 근거화하는 데 유용합니다.

https://services.google.com/fh/files/misc/practitioners_guide_to_mlops_whitepaper.pdf

Microsoft 책임감 있는 AI 표준 (Microsoft Responsible AI Standard)

Microsoft의 책임감 있는 AI 표준은 AI 시스템을 책임감 있게 구축하기 위한 구체적인 요구사항을 제공합니다.

거버넌스(Governance), 책임성(Accountability), 투명성(Transparency), 신뢰성(Reliability), 안전성(Safety), 공정성(Fairness), 개인정보 보호(Privacy) 및 포용적 설계(Inclusive design) 고려 사항을 뒷받침하는 데 유용합니다.

https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/Microsoft-Responsible-AI-Standard-General-Requirements.pdf

LLM 애플리케이션을 위한 OWASP Top 10

OWASP는 프롬프트 인젝션(Prompt injection), 안전하지 않은 출력 처리(Insecure output handling), 학습 데이터 오염(Training data poisoning), 민감 정보 노출(Sensitive information disclosure) 및 공급망 취약점(Supply-chain vulnerabilities)을 포함하여 LLM 애플리케이션의 주요 보안 위험을 식별합니다.

LLM 특화 보안 및 품질 위험에 대한 QA의 참여를 뒷받침하는 데 유용합니다.

https://genai.owasp.org/llm-top-10/

ISO/IEC 42001:2023 AI 경영 시스템 (AI Management System)

ISO/IEC 42001은 AI 시스템을 개발, 제공 또는 사용하는 조직을 위한 AI 경영 시스템 표준을 정의합니다.

감사 가능성 (Auditability), 거버넌스 (Governance), 책임성 (Accountability), 라이프사이클 관리 (Lifecycle Management) 및 지속적 개선 (Continuous Improvement)을 지원하는 데 유용합니다.

https://www.iso.org/standard/42001