QA, 테스트와 코드 감사
실패를 배포 전에 발견하고 재발을 막는 증거를 어떻게 만드는가? 핵심 이론부터 사례 분석, 단계별 실습, 품질 검수, 종합 문제까지 혼자 학습할 수 있도록 구성한 전공 실습 교재입니다.
오늘의 질문과 학습목표
실패를 배포 전에 발견하고 재발을 막는 증거를 어떻게 만드는가? 이 질문에 자신의 말로 답할 수 있고, 설계 결과물을 직접 만들고 검수하는 것이 오늘의 완료 기준입니다.
테스트 피라미드와 각 계층의 목적을 설명한다.
요구사항을 테스트 케이스로 변환한다.
경계값과 동등 분할을 적용한다.
회귀 테스트와 탐색적 테스트를 구분한다.
OWASP 관점의 기본 보안 점검을 수행한다.
결함을 재현 가능한 형식으로 보고한다.
혼자 공부하는 순서
- 용어를 암기하기 전에 사례에서 문제가 생기는 이유를 설명합니다.
- 좋은 예와 나쁜 예의 차이를 관찰 가능한 기준으로 적습니다.
- 예시를 보지 않고 종합 실습을 먼저 해결합니다.
- 모범답안과 비교한 뒤 빠진 조건을 다른 색으로 보완합니다.
교재 목차
- 학습 안내와 학습목표Page 02
- 제1장. 핵심 이론과 설계 원칙Page 04
- 제2장. 단계별 설계 실습Page 05
- 제3장. 사례 분석과 품질 검수Page 06
- 제4장. 종합 실습과 모범답안Page 07
- 핵심 용어와 최종 점검Page 08
- 자기주도 심화학습과 안내형 실습Pages 09–11
종합 실습 결과물, 자가진단 80점 이상, 핵심 질문 4개에 대한 자신의 답을 남기면 Day 8 학습을 완료한 것입니다.
QA, 테스트와 코드 감사 핵심 이론
전문 용어는 복잡해 보이지만, 각 용어는 설계에서 반복되는 한 가지 문제를 해결하기 위해 존재합니다. 아래 표에서 “무엇을 뜻하는가”보다 “언제 필요한가”를 중심으로 학습하세요.
| 핵심 개념 | 설명 |
|---|---|
| Unit Test | 작은 로직 단위를 빠르고 격리해서 검증합니다. |
| Integration Test | DB·API 등 여러 구성요소의 연결을 검증합니다. |
| E2E Test | 사용자 관점에서 전체 핵심 흐름을 검증합니다. |
| Boundary Value | 오류가 자주 발생하는 최소·최대 경계 주변 값입니다. |
| Regression Test | 수정한 결함이 다시 발생하지 않도록 고정하는 테스트입니다. |
| Threat Modeling | 공격자, 자산, 진입점, 완화책을 미리 분석합니다. |
좋은 설계와 나쁜 설계의 차이
피해야 할 접근
버튼을 한 번 눌러 보고 “정상 동작”이라고 기록한다.
권장 접근
사전 조건, 입력, 실행 단계, 기대 결과를 기록하고 정상·경계·권한·장애 조건을 반복 실행한다.
[요구사항 ID] + [사전 조건] + [입력] + [실행 단계] + [기대 결과] + [증거]
단계별 설계 절차
문제 정의
위험도와 사용자 영향으로 테스트 우선순위를 정한다.
구조 추출
요구사항마다 정상·경계·오류·권한 케이스를 만든다.
핵심 설계
작은 로직은 단위, 연결은 통합, 핵심 여정은 E2E로 배치한다.
실패 조건
실패 테스트를 재현하고 원인을 수정한 뒤 회귀 테스트를 남긴다.
정책 연결
인증·인가·입력 검증·비밀정보 노출을 보안 관점에서 점검한다.
검증과 추적
환경, 단계, 기대·실제 결과, 스크린샷과 로그로 결함을 보고한다.
작동하는 예시
예시를 읽을 때 확인할 것
- 입력과 시작 조건이 명확한가?
- 정상 결과뿐 아니라 실패 결과도 관찰 가능한가?
- 중복·권한·동시성·외부 장애가 필요한 수준으로 다뤄졌는가?
- 요구사항과 구현 결과를 서로 추적할 수 있는가?
사례 분석과 품질 검수
스스로 설명해 보기
- 100% 코드 커버리지가 무결함을 뜻하지 않는 이유는?
- flaky test가 팀에 주는 비용은?
- 인증과 인가 테스트는 어떻게 다른가?
- 결함 보고서에 환경 정보가 필요한 이유는?
각 질문에 2~3문장으로 답하고, 답을 뒷받침하는 사례를 하나씩 적으세요.
품질 자가진단 · 100점
| 영역 | 판단 기준 | 점수 |
|---|---|---|
| 정확성 | 개념과 기술 선택이 요구사항 및 사실에 맞는다. | 25 |
| 완전성 | 정상 흐름, 경계 조건, 실패와 복구를 함께 다룬다. | 25 |
| 일관성 | 용어, ID, 상태, 인터페이스가 산출물 사이에서 일치한다. | 20 |
| 검증 가능성 | 관찰 가능한 결과와 완료 기준을 제시한다. | 20 |
| 설명력 | 선택한 방법과 대안의 차이를 자신의 말로 설명한다. | 10 |
틀린 결과만 고치지 말고, 빠진 질문이 무엇이었는지 기록하세요. 좋은 엔지니어는 정답을 외우기보다 다음 설계에서 같은 누락을 막는 점검 기준을 만듭니다.
종합 실습과 모범답안
로그인 API의 테스트 매트릭스를 작성하세요. 정상, 비밀번호 오류, 존재하지 않는 사용자, 반복 실패, SQL 삽입 형태 입력을 포함하세요.
- 핵심 가정과 미결정 사항을 먼저 적습니다.
- 주요 설계 결과물을 표, 코드 또는 다이어그램으로 작성합니다.
- 정상 흐름과 최소 3개의 실패·경계 조건을 포함합니다.
- 자가진단표로 채점하고 개선 전후를 비교합니다.
모범답안의 핵심 방향 보기
응답 코드와 메시지는 계정 존재 여부를 과도하게 노출하지 않아야 합니다. 반복 실패에는 속도 제한 또는 잠금 정책을 확인하고, SQL 형태 문자열은 단순 문자열로 안전하게 처리되어야 합니다. 성공 시 토큰 속성과 로그의 비밀번호 비노출도 점검합니다.
답안 사용법
모범답안은 유일한 정답이 아닙니다. 자신의 설계가 다른 경우에는 요구사항, 비용, 복잡도, 위험 중 어떤 근거로 다른 선택을 했는지 설명할 수 있어야 합니다.
핵심 용어와 최종 점검
| 용어 | 쉽게 말하면 |
|---|---|
| Test Oracle | 기대 결과가 맞는지 판단하는 기준 |
| Equivalence Partition | 같게 동작할 입력을 묶는 기법 |
| Flaky Test | 코드 변경 없이도 간헐적으로 실패하는 테스트 |
| Regression | 기존 기능이 다시 깨지는 현상 |
| OWASP | 웹 보안 위험과 대응 지침을 제공하는 단체 |
| Severity | 결함이 시스템에 미치는 영향도 |
제출 전 8문항
- 오늘의 핵심 질문에 자신의 말로 답할 수 있는가?
- 설계의 입력, 조건, 결과가 명확한가?
- 정상 흐름뿐 아니라 실패와 복구를 포함했는가?
- 동시성, 중복 요청, 권한 문제를 검토했는가?
- 외부 시스템 장애와 타임아웃을 고려했는가?
- 선택한 방법의 단점과 대안을 설명할 수 있는가?
- 산출물 사이의 용어와 상태가 일치하는가?
- 테스트하거나 관찰할 수 있는 완료 기준이 있는가?
실패를 배포 전에 발견하고 재발을 막는 증거를 어떻게 만드는가? 오늘 만든 결과물을 근거로 이 질문에 답해 보세요.
맥락으로 이해하는 핵심 용어
용어를 정의만 외우지 말고 판단 도구로 익히세요. 각 행을 정의→필요한 이유→예시 또는 주의점 순서로 읽습니다.
| 용어 | 쉬운 정의 | 왜 중요한가 | 예시 또는 주의점 |
|---|---|---|---|
| 단위 테스트 | 함수·클래스 같은 작은 단위를 격리해 검증 | 빠르고 정확하게 로직 회귀를 찾음 | 외부 의존성은 대역으로 통제한다. |
| 통합 테스트 | DB·API·서비스가 함께 작동하는지 검증 | 경계 사이 계약 오류를 발견 | 실제와 가까운 스키마와 설정을 사용한다. |
| E2E 테스트 | 사용자 관점에서 전체 흐름을 브라우저 등으로 검증 | 핵심 업무가 실제 환경에서 되는지 확인 | 많으면 느리고 불안정하므로 핵심 경로에 집중한다. |
| 회귀 | 변경 때문에 이전에 되던 기능이 깨지는 현상 | 자동 테스트가 막아야 할 대표 위험 | 버그 수정 때 재현 테스트를 함께 추가한다. |
| 테스트 더블 | 실제 의존성을 대신하는 stub·fake·mock 등의 객체 | 실패·경계 상황을 통제해 재현 | 구현 세부사항을 과도하게 검증하지 않는다. |
| 정적 분석 | 실행하지 않고 코드의 타입·규칙·취약 패턴을 검사 | 초기 단계에 저비용으로 결함 발견 | 동적 테스트를 대체하지 않고 보완한다. |
회원가입 기능에 이메일 중복, 약한 비밀번호, 네트워크 재시도, 권한 오류가 발생할 수 있다.
안내형 실습과 문제 해결
실습 상황
회원가입 기능에 이메일 중복, 약한 비밀번호, 네트워크 재시도, 권한 오류가 발생할 수 있다.
순서대로 수행하기
- 요구사항을 Given-When-Then 형태의 테스트 조건으로 바꾼다.
- 정상·경계·오류·권한 사례를 위험도 순으로 배치한다.
- 단위→통합→E2E 순으로 가장 싼 층에서 결함을 잡는다.
- 실패 테스트를 재현하고 수정 뒤 전체 회귀 테스트를 실행한다.
산출물 1개, 핵심 가정 3개, 실패 사례 3개 이상을 저장하세요. 다른 학습자가 추가 질문 없이 판단 과정을 재현할 수 있어야 합니다.
결과가 다를 때 진단하기
| 관찰한 증상 | 가능한 원인 | 다음 조치 |
|---|---|---|
| 테스트가 가끔 실패 | 시간·네트워크·공유 상태 의존 | 고정 시계와 격리된 테스트 데이터 |
| 코드 변경마다 테스트 대량 수정 | 구현 세부 결합 | 공개 동작과 결과 중심 검증 |
| 테스트는 통과하지만 운영 장애 | 실제 경계 통합 부족 | 대표 환경의 통합·E2E 보강 |
스스로 이해도 확인하기
인출 연습 — 펼치기 전에 답하기
테스트 피라미드는 무엇인가?
빠른 단위 테스트를 많이, 통합 테스트를 적당히, 느린 E2E를 핵심 경로에 적게 두는 전략입니다.
커버리지 100%면 충분한가?
아닙니다. 실행된 줄의 비율일 뿐 중요한 주장과 경계를 검증했는지는 별개입니다.
QA 완료 기준은?
주요 위험이 재현 가능한 테스트와 명확한 기대 결과로 덮여 있어야 합니다.
페이지를 보지 않고 오늘의 핵심 판단, 대표 실패 원인, 검증 방법을 연결해 설명하세요. 세 가지가 이어지지 않으면 놓친 용어나 진단 사례로 돌아갑니다.