CS🖥️/기타🤖

GPT랑 같이 QA 직무테스트 준비하기

제가 보려고 만들었습니다. 계속 내용이 추가될 예정입니다

1. 소프트웨어 테스트 기초

테스트 목적: 소프트웨어의 결함을 찾아내고 품질을 향상시키기 위함.
테스트 원칙
- 결함이 존재함을 증명할 수는 있어도, 결함이 없음을 증명할 수는 없음
- 조기 테스팅이 중요함
- 결함 집중(파레토 법칙: 80%의 결함이 20%의 모듈에서 발견됨)
- 살충제 패러독스(동일한 테스트를 반복하면 더 이상 새로운 결함을 찾기 어려움)

2. 테스트 유형 및 기법

(1) 테스트 수준

단위 테스트 (Unit Test): 개별 모듈이나 함수의 동작을 확인 (JUnit, Mockito)
통합 테스트 (Integration Test): 여러 모듈이 올바르게 연동되는지 확인
시스템 테스트 (System Test): 전체 시스템이 요구사항을 만족하는지 검증
인수 테스트 (Acceptance Test): 실제 사용자가 요구사항에 맞게 동작하는지 확인

(2) 테스트 종류

기능 테스트: 요구사항에 따라 기능이 정상적으로 동작하는지 확인
비기능 테스트: 성능, 보안, 접근성 등 기능 이외의 요소 검증
회귀 테스트 (Regression Test): 변경 사항이 기존 기능에 영향을 미치는지 확인
부하 테스트 (Load Test): 일정 수준의 트래픽에서 시스템이 정상 동작하는지 확인
스트레스 테스트 (Stress Test): 최대 부하 상황에서 성능 저하 여부 확인
보안 테스트 (Security Test): SQL Injection, XSS 등 보안 취약점 테스트

(3) 테스트 기법

화이트박스 테스트: 내부 코드 구조를 분석하여 테스트 (구현 로직 기반)
블랙박스 테스트: 입력과 출력만 보고 기능을 테스트 (사용자 관점)
동치 분할 (Equivalence Partitioning): 입력값을 그룹으로 나누어 테스트
경계값 분석 (Boundary Value Analysis): 경계값(최대/최소값) 중심으로 테스트
결정 테이블 (Decision Table): 다양한 조합의 입력값에 따른 결과 분석

3. 테스트 자동화와 도구

테스트 자동화 필요성: 반복적인 테스트를 효율적으로 수행하고 인적 오류를 줄이기 위함
테스트 프레임워크
- 단위 테스트: JUnit, TestNG, PyTest
- UI 테스트: Selenium, Appium
- API 테스트: Postman, RestAssured
- 부하 테스트: JMeter, Locust

4. 결함 관리 및 QA 프로세스

결함(버그) 관리 프로세스
1. 결함 발견 (Defect Detection)
2. 결함 등록 (Defect Logging) – Jira, Redmine 등의 도구 사용
3. 결함 분석 (Defect Analysis) – 심각도(Severity) 및 우선순위(Priority) 설정
4. 결함 수정 (Defect Fixing)
5. 결함 재테스트 (Retesting)
6. 회귀 테스트 (Regression Testing)
7. 결함 종료 (Defect Closure)
테스트 문서 작성
- 테스트 계획서 (Test Plan)
- 테스트 케이스 (Test Case)
- 테스트 결과 보고서 (Test Report)

5. 애자일(Agile)과 QA

애자일 개발과 테스트: 스크럼(Scrum), 칸반(Kanban) 등
테스트 주도 개발 (TDD: Test-Driven Development)
- 테스트 케이스를 먼저 작성한 후 코드 개발
행동 주도 개발 (BDD: Behavior-Driven Development)
- 사용자 관점에서 테스트 시나리오 작성 (Cucumber, Gherkin 사용)

6. 기본적인 SQL 및 API 테스트

SQL 기초
- SELECT, JOIN, GROUP BY, WHERE, ORDER BY 등
- 데이터 검증을 위해 SQL 쿼리 활용
API 테스트
- HTTP 요청(GET, POST, PUT, DELETE) 이해
- JSON, XML 형식 파악
- Postman을 이용한 API 테스트

7. CI/CD 및 DevOps 개념

CI/CD (Continuous Integration/Continuous Deployment)
- Jenkins, GitHub Actions, GitLab CI/CD 활용
DevOps와 QA
- QA가 지속적인 테스트 및 배포 자동화에 기여해야 함

1. 소프트웨어 테스트의 개념

(1) 소프트웨어 테스트란?

소프트웨어가 요구사항에 따라 올바르게 동작하는지 검증하는 과정.
결함(Bug)을 발견하고, 품질을 보장하기 위한 활동.
개발 단계에서 발생하는 오류를 줄이고, 유지보수 비용을 절감하는 목적.

(2) 테스트의 기본 원칙 (ISTQB 기준)

테스팅은 결함이 존재함을 밝힐 수는 있지만, 결함이 없음을 증명할 수는 없음.
완벽한 테스팅은 불가능함.
초기 테스팅이 중요함. (SDLC 초기 단계에서 테스트가 진행될수록 비용이 절감됨)
결함 집중의 법칙 (Pareto Principle). (80%의 결함은 20%의 모듈에서 발견됨)
살충제 패러독스 (Pesticide Paradox). (동일한 테스트 반복 시 새로운 결함을 찾기 어려움)
테스팅은 정황(Context) 의존적임. (도메인별로 테스트 전략이 다름)
오류 부재의 궤변 (Absence-of-Errors Fallacy). (사용자 요구사항과 맞지 않으면 결함이 없어도 품질이 낮음)

2. 소프트웨어 개발 생명주기(SDLC)와 QA의 역할

(1) SDLC(Software Development Life Cycle) 단계

요구사항 분석 (Requirements Analysis)
설계 (Design)
구현 (Development)
테스트 (Testing)
배포 (Deployment)
유지보수 (Maintenance)

(2) V-모델과 QA

V-모델은 SDLC 단계별로 대응하는 테스트 활동이 존재함.
좌측(개발)과 우측(테스트)이 대응됨.
- 요구사항 분석 → 인수 테스트
- 시스템 설계 → 시스템 테스트
- 상세 설계 → 통합 테스트
- 구현 → 단위 테스트

3. 테스트 수준(Test Levels)

소프트웨어 개발에서 테스트는 계층적으로 수행되며, 일반적으로 4가지 주요 수준이 있음.

(1) 단위 테스트 (Unit Test)

가장 작은 단위(함수, 모듈)를 개별적으로 테스트.
개발자가 직접 수행하며, 화이트박스 테스트 방식 사용.
자동화 테스트(JUnit, PyTest 등) 활용 가능.

(2) 통합 테스트 (Integration Test)

여러 모듈이 결합될 때 정상적으로 작동하는지 확인.
Big Bang, Top-Down, Bottom-Up 등의 방식이 있음.
Stub, Driver 등을 사용하여 테스트 환경을 모사함.

(3) 시스템 테스트 (System Test)

전체 시스템이 요구사항을 충족하는지 검증.
블랙박스 테스트 중심.
기능, 성능, 보안 등 여러 측면을 테스트함.

(4) 인수 테스트 (Acceptance Test)

실제 사용자 관점에서 시스템이 기대대로 동작하는지 확인.
알파 테스트 (내부 사용자 테스트), 베타 테스트 (외부 사용자 테스트).

4. 테스트 유형(Test Types)

테스트는 목적에 따라 기능적 테스트와 비기능적 테스트로 나뉨.

(1) 기능 테스트 (Functional Testing)

요구사항 명세서를 기반으로 동작을 검증하는 테스트.
블랙박스 테스트 기법 사용.
예: 유효성 검사, 로그인 기능 확인 등.

(2) 비기능 테스트 (Non-Functional Testing)

성능, 보안, 사용성 등 기능 이외의 요소를 검증.
주요 유형:
- 성능 테스트 (Performance Test): 응답 시간, 처리량 테스트
- 부하 테스트 (Load Test): 다수의 사용자가 동시에 접근할 때 성능 확인
- 스트레스 테스트 (Stress Test): 시스템이 한계를 초과했을 때의 반응 확인
- 보안 테스트 (Security Test): SQL Injection, XSS 등 보안 취약점 검증

(3) 회귀 테스트 (Regression Testing)

코드 수정 이후 기존 기능이 정상 동작하는지 확인.
자동화 테스트 도구(JUnit, Selenium 등)를 활용하여 반복 수행.

5. 테스트 기법 (Testing Techniques)

테스트 기법은 크게 화이트박스 테스트(White-box Testing) 와 블랙박스 테스트(Black-box Testing) 로 구분됨.

(1) 화이트박스 테스트

내부 코드 구조를 분석하여 테스트 수행.
제어 흐름(Flow Control), 조건문, 루프 검사 등을 포함.
기법: 문장(Statement) 커버리지, 분기(Branch) 커버리지, 조건 커버리지.

(2) 블랙박스 테스트

내부 코드가 아닌 입력과 출력값을 기준으로 테스트 수행.
기법:
- 동치 분할 (Equivalence Partitioning): 유사한 입력값을 그룹화하여 테스트.
- 경계값 분석 (Boundary Value Analysis): 최소/최대값을 기준으로 테스트.
- 결정 테이블 (Decision Table Testing): 여러 조건 조합을 분석하여 테스트.
- 상태 전이(State Transition Testing): 상태 변화에 따라 테스트.

6. 결함 관리와 QA 프로세스

(1) 결함(버그) 관리 프로세스

결함 발견 (Defect Detection)
결함 등록 (Defect Logging) - Jira, Redmine 등의 도구 활용
결함 분석 (Defect Analysis) - 심각도(Severity) 및 우선순위(Priority) 설정
결함 수정 (Defect Fixing)
결함 재테스트 (Retesting)
회귀 테스트 (Regression Testing)
결함 종료 (Defect Closure)

(2) 테스트 문서

테스트 계획서(Test Plan): 테스트 범위, 전략, 일정 등을 정의.
테스트 케이스(Test Case): 입력값, 예상 결과, 수행 절차 등을 정의.
테스트 결과 보고서(Test Report): 테스트 수행 결과 요약.

7. 애자일(Agile) 개발과 QA

애자일(Agile) 방법론에서는 짧은 주기의 개발과 지속적인 테스트가 중요함.
스크럼(Scrum)
- 스프린트 단위로 개발 & 테스트 반복.
- QA는 개발팀과 협력하여 지속적인 품질 보장.
TDD (Test-Driven Development, 테스트 주도 개발)
- 개발자가 먼저 테스트 코드를 작성하고 이를 통과하는 방식으로 개발 진행.
BDD (Behavior-Driven Development, 행동 주도 개발)
- 사용자의 행동을 기반으로 테스트 작성 (Gherkin 언어, Cucumber 사용).

8. 정적 테스트(Static Testing)와 동적 테스트(Dynamic Testing)

소프트웨어 테스트는 실행 여부에 따라 정적 테스트와 동적 테스트로 구분됨.

(1) 정적 테스트 (Static Testing)

소프트웨어 실행 없이 결함을 찾는 방법.
주로 문서, 코드, 아키텍처 리뷰 등을 통해 결함을 식별.
대표적인 기법
- 리뷰(Review): 요구사항, 코드, 테스트 케이스 등을 검토.
- 워크스루(Walkthrough): 문서를 작성자가 설명하고 동료들이 피드백 제공.
- 인스펙션(Inspection): 공식적인 절차에 따라 결함을 발견하고 기록.
- 정적 분석(Static Analysis): 자동화 도구(SonarQube, PMD)를 이용해 코드 품질 분석.

(2) 동적 테스트 (Dynamic Testing)

소프트웨어를 실행하여 테스트하는 방법.
블랙박스 테스트와 화이트박스 테스트를 포함.
단위 테스트, 통합 테스트, 시스템 테스트 등이 모두 동적 테스트에 해당.

9. 테스트 커버리지 (Test Coverage)

테스트의 완전성을 측정하는 지표.
얼마나 많은 코드가 테스트되었는지 판단하는 기준.
일반적인 코드 커버리지 유형
1. 문장 커버리지(Statement Coverage): 실행된 코드 라인의 비율.
2. 분기 커버리지(Branch Coverage): if, switch 등의 분기가 테스트된 비율.
3. 조건 커버리지(Condition Coverage): 개별 조건식이 참/거짓으로 실행된 비율.
4. MC/DC (Modified Condition/Decision Coverage): 모든 개별 조건이 독립적으로 테스트되는지 확인.
5. 경로 커버리지(Path Coverage): 프로그램의 모든 실행 경로를 테스트.

10. 리스크 기반 테스트 (Risk-Based Testing)

소프트웨어의 위험도를 고려하여 테스트 우선순위를 결정하는 방법.
모든 테스트를 수행할 수 없는 경우, 비즈니스 영향도 및 결함 발생 가능성을 기준으로 테스트를 수행.
리스크 분석 요소
1. 결함 발생 가능성(Probability)
2. 결함이 미치는 영향(Impact)
3. 회복 가능성(Recoverability)

11. 테스트 오라클 (Test Oracle)

테스트 결과가 올바른지 판단하는 기준.
테스트를 자동화할 때 많이 사용됨.
대표적인 오라클 유형
1. 참 오라클(True Oracle): 모든 입력값에 대해 정확한 예상 결과를 제공.
2. 샘플링 오라클(Sampling Oracle): 일부 입력값에 대해서만 예상 결과 제공.
3. 휴리스틱 오라클(Heuristic Oracle): 기존 동작과 비교하여 결함 여부 판단.
4. 일관성 검사 오라클(Consistency Oracle): 동일한 입력에 대해 일관된 결과가 나오는지 확인.

12. 탐색적 테스트 (Exploratory Testing)

사전에 정해진 테스트 케이스 없이, 테스터의 경험과 직관을 바탕으로 수행하는 테스트.
요구사항이 불명확하거나 초기 단계에서 효과적.
장점: 유연성, 새로운 결함 발견 가능성 증가.
단점: 테스트 결과 재현이 어려울 수 있음.

13. 회귀 테스트 (Regression Testing) 전략

기존 기능이 변경 없이 정상적으로 동작하는지 검증하는 테스트.
회귀 테스트 범위를 결정하는 전략
1. 완전 회귀 테스트(Complete Regression Testing): 모든 테스트를 다시 수행.
2. 선택적 회귀 테스트(Selective Regression Testing): 변경된 부분과 영향을 받는 부분만 테스트.
3. 테스트 스위트 재사용(Test Suite Reuse): 기존 테스트 케이스를 자동화하여 재사용.

14. 테스팅 성숙도 모델 (Testing Maturity Models, TMMi)

조직의 테스트 프로세스 성숙도를 평가하는 모델.
CMMI(Capability Maturity Model Integration)와 유사한 개념.
TMMi의 5단계
1. 초기(Initial): 테스트 프로세스가 체계화되지 않음.
2. 관리(Managed): 기본적인 테스트 프로세스 구축.
3. 정의(Defined): 표준화된 테스트 프로세스 적용.
4. 측정(Measured): 테스트 성과를 측정하고 분석.
5. 최적화(Optimized): 지속적인 개선 및 자동화 도입.

15. 소프트웨어 품질 속성 (Software Quality Attributes)

소프트웨어 품질을 평가하는 기준.
ISO/IEC 25010 기준 주요 품질 속성
1. 기능성(Functionality): 소프트웨어가 요구사항을 충족하는지 여부.
2. 신뢰성(Reliability): 시스템이 오류 없이 지속적으로 동작하는 능력.
3. 성능 효율성(Performance Efficiency): 응답 시간, 처리량, 리소스 사용량.
4. 사용성(Usability): 사용자 친화적인 UI/UX.
5. 보안(Security): 데이터 보호 및 접근 제어.
6. 호환성(Compatibility): 다른 시스템과의 연동성.
7. 유지보수성(Maintainability): 코드 수정 및 개선 용이성.
8. 이식성(Portability): 다른 환경에서도 실행 가능 여부.

16. 결함의 심각도(Severity)와 우선순위(Priority)

심각도(Severity): 결함이 시스템에 미치는 영향의 정도.
- Critical (치명적): 시스템 다운, 데이터 손실.
- Major (중대함): 주요 기능이 정상적으로 동작하지 않음.
- Minor (경미함): 일부 기능이 비정상적이나, 대체 가능.
- Trivial (사소함): UI 오류, 오타 등.
우선순위(Priority): 해결해야 할 시급성.
- High (높음): 즉시 수정 필요.
- Medium (보통): 다음 릴리스까지 해결 필요.
- Low (낮음): 장기적으로 해결 가능.

17. 페이즈 컨테인먼트 (Phase Containment)

소프트웨어 개발의 각 단계에서 결함을 조기에 발견하고 해결하는 개념.
결함 수정 비용은 늦을수록 증가하기 때문에, 초기 단계에서 오류를 발견하는 것이 중요함.
"초기 테스트(Early Testing)" 원칙과 연결됨

18. 소프트웨어 테스트 모델

테스트 프로세스를 구조적으로 정의한 여러 모델이 있음.

(1) V-모델 (V-Model)

SDLC와 테스트 활동을 병렬적으로 수행하는 모델.
개발 단계마다 대응하는 테스트 단계가 존재.
단점: 초기 설계 오류가 발견되면 비용이 큼.

개발 단계대응하는 테스트 단계

요구사항 분석	인수 테스트 (Acceptance Testing)
시스템 설계	시스템 테스트 (System Testing)
아키텍처 설계	통합 테스트 (Integration Testing)
모듈 설계	단위 테스트 (Unit Testing)

(2) 애자일 테스팅 (Agile Testing)

애자일 개발 방식(Scrum, Kanban 등)과 함께 수행되는 테스트 방식.
짧은 개발 주기(Sprint)마다 반복적으로 테스트 수행.
TDD (Test-Driven Development), BDD (Behavior-Driven Development) 기법과 밀접한 관련.

(3) 스파이럴 모델 (Spiral Model)

위험 분석을 기반으로 개발과 테스트를 반복하는 모델.
점진적으로 시스템을 확장하면서 테스트를 진행.

19. 테스트 자동화 (Test Automation)

반복적인 테스트를 자동으로 수행하여 QA 프로세스를 최적화하는 개념.

(1) 자동화 테스트의 장점

테스트 속도 향상 (수동 테스트 대비 빠름).
회귀 테스트(Regression Test)에 용이.
일관된 테스트 수행 가능 (사람의 실수 방지).

(2) 자동화 테스트 도구

테스트 영역대표적인 도구

단위 테스트	JUnit (Java), PyTest (Python), NUnit (C#)
UI 테스트	Selenium, Cypress, Appium
API 테스트	Postman, RestAssured
성능 테스트	JMeter, Gatling, Locust
보안 테스트	OWASP ZAP, Burp Suite

(3) 테스트 자동화 프레임워크

키워드 기반 테스트 (Keyword-Driven Testing): 테스트 스크립트 없이 키워드 기반으로 테스트 수행 (e.g., Robot Framework).
데이터 기반 테스트 (Data-Driven Testing): 다양한 입력값을 이용해 동일한 테스트 케이스 실행.
모델 기반 테스트 (Model-Based Testing): 시스템 모델을 기반으로 테스트 자동 생성.

20. 소프트웨어 결함 유형 (Types of Software Defects)

소프트웨어에서 발생할 수 있는 결함 유형을 정리해보면 다음과 같아.

결함 유형설명

기능 결함 (Functional Defect)	요구사항에 맞지 않는 동작 발생
성능 결함 (Performance Defect)	속도, 응답 시간 등의 성능 문제
보안 결함 (Security Defect)	데이터 노출, 취약점 공격 가능성
UI/UX 결함 (UI/UX Defect)	UI 요소 정렬 오류, 접근성 문제
논리 결함 (Logical Defect)	잘못된 알고리즘 또는 계산 오류
호환성 결함 (Compatibility Defect)	OS, 브라우저, 디바이스 간 호환성 문제
다국어 결함 (Localization Defect)	언어별 UI 깨짐, 번역 오류

21. 결함 추적 (Defect Tracking) 및 버그 라이프사이클

테스트 중 발견된 결함은 특정한 흐름을 따라 추적됨.

(1) 결함 라이프사이클 (Bug Lifecycle)

New (신규): 결함이 발견되어 등록됨.
Assigned (할당됨): 개발자가 수정할 담당자로 지정됨.
In Progress (수정 중): 개발자가 결함을 수정하는 단계.
Fixed (수정 완료): 결함이 해결됨.
Retest (재테스트): QA가 수정된 코드 테스트.
Closed (종료됨): 결함이 해결되었고, 다시 발생하지 않음.
Reopen (재오픈됨): 수정이 불완전하여 다시 해결해야 할 경우.

(2) 결함 심각도(Severity)와 우선순위(Priority)

심각도(Severity): 시스템에 미치는 영향.
우선순위(Priority): 해결 시급성.

22. 테스트 환경 관리 (Test Environment Management)

테스트가 원활하게 진행되려면 적절한 테스트 환경이 필요함.

(1) 테스트 환경의 요소

하드웨어 (서버, 네트워크)
소프트웨어 (OS, DB, API)
테스트 데이터 (실제 데이터와 유사한 테스트용 데이터)
모의 시스템 (Stub, Mock, Virtualization 사용)

(2) 가상화 테스트 환경

Docker: 컨테이너 기반 테스트 환경 구축.
VMware: 가상 머신을 활용한 테스트 환경.
Cloud-based Testing: AWS, Google Cloud 등을 활용한 원격 테스트.

23. 지속적 통합 및 배포 (CI/CD)와 QA

QA는 DevOps와 긴밀하게 연관됨.

(1) 지속적 통합 (CI - Continuous Integration)

코드 변경 사항이 발생할 때마다 자동으로 빌드 및 테스트 수행.
대표적인 도구: Jenkins, GitHub Actions, GitLab CI/CD

(2) 지속적 배포 (CD - Continuous Deployment)

코드가 자동으로 배포되는 프로세스.
자동화된 테스트가 필수적.

(3) QA 역할

CI/CD 환경에서 자동화 테스트 수행.
배포 전후 품질 검증.

24. 테스트 데이터 관리 (Test Data Management, TDM)

테스트를 효과적으로 수행하려면 적절한 테스트 데이터가 필요함.

(1) 테스트 데이터 유형

실제 데이터 (Production Data): 실환경 데이터를 익명화하여 사용.
샘플 데이터 (Sample Data): 소규모 테스트용 가공 데이터.
모의 데이터 (Synthetic Data): 실제 데이터를 기반으로 생성한 가짜 데이터.

(2) 테스트 데이터 익명화 기법

마스킹(Masking): 일부 데이터를 가려서 사용 (e.g., 123-45-6789 → 123-XX-XXXX).
암호화(Encryption): 데이터 암호화 후 테스트.
랜덤화(Randomization): 데이터를 무작위로 변경.

25. AI 기반 테스트 및 최신 트렌드

AI 기술이 QA에 접목되면서 지능형 테스트 자동화가 발전하고 있음.

(1) AI 기반 테스트 자동화

머신러닝을 활용한 자동 결함 탐지.
스마트 테스트 케이스 생성.
자율적인 UI 테스트 수행.

(2) 주요 AI 테스트 도구

Applitools: 시각적 UI 테스트 자동화.
Testim: AI 기반 테스트 자동화 도구.
Mabl: 머신러닝 기반 UI 테스트.

26. 결함 예방 기법 (Defect Prevention Techniques)

QA의 핵심 목표 중 하나는 결함을 사전에 예방하는 것임.

(1) 결함 예방이 중요한 이유

초기 단계에서 결함을 방지하면 비용이 절감됨 (나중에 수정할수록 비용 증가).
테스트 단계에서 결함이 줄어들면 제품 품질이 높아짐.
지속적인 개선(CQI, Continuous Quality Improvement)에 도움.

(2) 결함 예방 방법

코딩 표준 준수
- 일관된 코딩 스타일 유지 (Lint, Checkstyle 같은 도구 활용).
정적 분석 도구 활용
- SonarQube, PMD, FindBugs 같은 정적 코드 분석 도구로 코드 품질을 자동 점검.
리뷰 및 페어 프로그래밍
- 코드 리뷰(Code Review), 워크스루(Walkthrough), 인스펙션(Inspection)을 통해 오류 사전 발견.
테스트 주도 개발 (TDD, Test-Driven Development)
- 테스트 코드를 먼저 작성하고, 그 테스트를 통과하는 코드를 개발.
자동화된 빌드 및 통합 테스트 (CI/CD 적용)
- 지속적 통합(CI) 과정에서 자동으로 테스트를 수행하여 결함을 조기에 감지.

27. 테스트 설계 기법 (Test Design Techniques)

테스트 케이스를 효율적으로 작성하는 방법.

(1) 명세 기반 테스트 기법 (Specification-Based Testing)

소프트웨어의 요구사항(스펙)에 기반하여 테스트 케이스를 설계.
대표적인 기법:
1. 동치 분할 (Equivalence Partitioning)
  - 입력값을 여러 범위로 나누고, 각 범위에서 하나의 값만 테스트.
  - 예: 1~100까지 숫자를 입력할 수 있다면, 0(잘못된 값), 50(정상 값), 101(잘못된 값)만 테스트하면 됨.
2. 경계값 분석 (Boundary Value Analysis)
  - 가장 오류가 많이 발생하는 **경계 값(최소, 최대)**을 집중적으로 테스트.
  - 예: 1~100까지 입력 가능 → 0, 1, 100, 101을 테스트.
3. 결정 테이블 테스트 (Decision Table Testing)
  - 여러 조건 조합에 따른 결과를 체계적으로 분석.
  - 예: 로그인 시 "아이디 + 비밀번호"가 일치하는 경우만 성공 → 4가지 경우의 수 테스트.
4. 상태 전이 테스트 (State Transition Testing)
  - 시스템이 상태를 변경할 때 올바르게 동작하는지 확인.
  - 예: ATM에서 "카드 삽입 → PIN 입력 → 출금 요청 → 출금 완료" 흐름 테스트.

(2) 경험 기반 테스트 기법 (Experience-Based Testing)

테스터의 경험과 직관을 활용한 테스트.
대표적인 방법:
1. 탐색적 테스트 (Exploratory Testing): 즉흥적으로 시스템을 탐색하며 결함을 발견.
2. 에러 추정 기법 (Error Guessing): 자주 발생하는 결함 유형을 예상하여 테스트.
3. 체크리스트 기반 테스트: 과거의 결함 패턴을 바탕으로 테스트.

28. QA Metrics (소프트웨어 품질 지표)

QA에서 테스트의 효과를 측정하는 지표.

(1) 테스트 커버리지 (Test Coverage)

소프트웨어 코드 중 몇 %가 테스트되었는지를 측정.
코드의 실행 빈도를 기준으로 함.
주요 커버리지 유형:
1. 문장 커버리지 (Statement Coverage): 전체 코드 중 실행된 코드 라인의 비율.
2. 분기 커버리지 (Branch Coverage): 모든 if-else 분기가 테스트되었는지 확인.
3. 조건 커버리지 (Condition Coverage): 개별 조건이 참/거짓으로 실행되었는지 확인.

(2) 결함 밀도 (Defect Density)

코드 1,000라인(LOC)당 결함의 개수를 측정.
공식: 결함밀도=발견된결함수코드라인수×1000결함 밀도 = \frac{발견된 결함 수}{코드 라인 수} \times 1000
결함 밀도가 높은 모듈은 집중 테스트 대상.

(3) 테스트 효과성 (Test Effectiveness)

테스트가 얼마나 효과적으로 결함을 찾았는지 평가.
공식: 테스트효과성=발견된결함수총결함수×100%테스트 효과성 = \frac{발견된 결함 수}{총 결함 수} \times 100\%

29. 테스트 환경 격리 (Test Environment Isolation)

QA 테스트 환경이 운영 환경과 충돌하지 않도록 설정하는 방법.

(1) 테스트 환경 격리의 필요성

테스트 중 데이터가 변조되지 않도록 방지.
운영 시스템과 분리된 테스트 환경을 유지하여 안정성 확보.

(2) 격리 방법

가상화 환경 사용 (Virtual Machines, Docker)
- Docker 컨테이너로 테스트 환경 구축.
테스트 데이터 격리
- 운영 데이터와 다른 테스트 데이터를 사용.
Mocking & Stubbing 활용
- 실제 시스템을 호출하지 않고, 가짜(Mock) 응답을 사용.

30. 성능 테스트 (Performance Testing)

소프트웨어의 성능을 측정하는 테스트.

(1) 성능 테스트 유형

유형설명

부하 테스트 (Load Testing)	다수의 사용자가 접속할 때 성능 측정
스트레스 테스트 (Stress Testing)	시스템의 최대 한계를 테스트
내구성 테스트 (Endurance Testing)	장기간 사용 시 성능 유지 여부 테스트
스파이크 테스트 (Spike Testing)	갑작스러운 트래픽 증가에 대한 반응 확인
확장성 테스트 (Scalability Testing)	시스템이 확장될 때 성능 유지 여부 확인

(2) 주요 성능 지표

응답 시간 (Response Time): 요청을 처리하는 데 걸리는 시간.
처리량 (Throughput): 초당 처리 가능한 요청 수.
CPU/메모리 사용량: 시스템의 리소스 소비량.

(3) 성능 테스트 도구

JMeter: 부하 및 성능 테스트 자동화.
Gatling: 실시간 성능 모니터링 제공.
Locust: Python 기반 성능 테스트 도구.

31. 보안 테스트 (Security Testing)

소프트웨어의 보안 취약점을 탐지하는 테스트.

(1) 보안 테스트 유형

유형설명

침투 테스트 (Penetration Testing)	해커처럼 시스템을 공격하여 취약점 발견
취약점 검사 (Vulnerability Scanning)	OWASP Top 10 기반 자동화 보안 스캔
권한 테스트 (Access Control Testing)	사용자 권한 및 접근 제어 테스트
데이터 암호화 테스트	데이터 저장 및 전송 과정에서 암호화 확인

(2) 보안 테스트 도구

OWASP ZAP: 웹 애플리케이션 보안 테스트 도구.
Burp Suite: 네트워크 및 API 취약점 분석.
SQLMap: SQL Injection 자동화 도구.

32. QA와 SQA (Software Quality Assurance)의 차이

QA와 SQA는 비슷한 개념으로 보이지만, 포괄적인 범위와 역할이 다름.

(1) QA (Quality Assurance, 품질 보증)

소프트웨어가 일정한 품질 기준을 충족하도록 보장하는 활동.
테스트뿐만 아니라 프로세스 개선, 결함 예방, 품질 향상을 위한 전반적인 전략 포함.
예: 테스트 계획 수립, 결함 관리, 품질 프로세스 개선.

(2) SQA (Software Quality Assurance, 소프트웨어 품질 보증)

소프트웨어 개발 전체 과정에서 품질을 보장하기 위한 활동.
QA보다 더 넓은 개념으로, 테스트뿐만 아니라 코드 리뷰, 프로세스 개선, 보안 테스트 등 포함.
예: 코드 품질 측정, 개발 표준 수립, 프로세스 모니터링.

💡 QA는 주로 테스트를 포함한 품질 검증 역할을 하고, SQA는 품질을 보장하는 전반적인 체계를 수립하는 역할을 한다.

33. Shift-Left Testing (시프트 레프트 테스팅)

(1) 개념

테스트를 개발 라이프사이클의 초기 단계(Left)에 집중하는 개념.
과거에는 개발 완료 후 테스트를 수행했지만, 초기에 테스트를 수행하면 결함을 조기에 발견하여 수정 비용을 줄일 수 있음.

(2) Shift-Left Testing의 주요 전략

TDD (Test-Driven Development, 테스트 주도 개발)
- 테스트 코드를 먼저 작성하고, 그 테스트를 통과하는 코드를 구현하는 방식.
- 테스트 커버리지를 극대화하여 결함을 사전에 방지.
정적 분석 (Static Code Analysis)
- SonarQube, ESLint 같은 정적 분석 도구로 코드를 검토하여 조기에 결함을 발견.
CI/CD 파이프라인에서 자동화된 테스트 수행
- 지속적 통합(CI) 과정에서 유닛 테스트(Unit Test)와 정적 코드 분석을 자동으로 실행.

💡 Shift-Left Testing을 적용하면 결함 수정 비용을 30~50% 줄일 수 있으며, 소프트웨어 품질이 향상됨.

34. QA에서 활용되는 AI 및 머신러닝

최근 QA에서도 AI 기반의 자동화 테스트 및 품질 분석이 활발하게 이루어지고 있음.

(1) AI 기반 테스트 자동화 기법

Self-healing 테스트
- AI가 UI 변경 사항을 자동으로 감지하고 테스트 코드를 업데이트함.
- Selenium, Testim 같은 도구에서 사용.
예측 분석 (Predictive Analytics)
- 머신러닝을 활용해 테스트 케이스 우선순위 자동 선정.
- 과거 결함 데이터를 학습하여 결함 발생 가능성이 높은 코드 부분 예측.
Visual Testing (시각적 테스트)
- AI가 UI의 시각적 변화를 감지하여 UI 오류를 자동으로 찾음.
- Applitools 같은 도구에서 제공.

💡 AI 기반 테스트 자동화는 QA의 효율성을 높이고, 유지보수 비용을 절감하는 핵심 기술로 떠오르고 있음.

35. QA에서 데이터베이스 테스트 (Database Testing)

소프트웨어의 데이터 저장 및 관리 기능이 올바르게 동작하는지 검증하는 테스트.

(1) 주요 테스트 항목

데이터 무결성 테스트
- ACID (Atomicity, Consistency, Isolation, Durability) 원칙이 잘 지켜지는지 확인.
- 트랜잭션 처리 중 데이터 손실이 없는지 검증.
SQL 성능 테스트
- 쿼리 최적화를 통해 DB 응답 시간이 적절한지 확인.
- Index, Query Plan 분석 등을 활용.
데이터 마이그레이션 테스트
- 새로운 DB로 데이터 이전 시, 손실 없이 정확하게 이동했는지 확인.

(2) 데이터베이스 테스트 도구

SQLUnit: SQL 테스트 자동화 도구.
DbFit: 데이터베이스 테스트를 위한 BDD 프레임워크.
JDBCUnit: Java 기반의 DB 테스트 도구.

💡 데이터베이스 테스트는 특히 금융, 의료 등 데이터 정확성이 중요한 시스템에서 필수적인 QA 활동임.

36. QA에서 A/B 테스트 (A/B Testing)

A/B 테스트는 두 개 이상의 버전을 비교하여 더 나은 사용자 경험을 찾는 실험적 테스트 방법.

(1) A/B 테스트 과정

가설 설정
- 예: "버튼 색상을 파란색에서 초록색으로 변경하면 클릭률이 증가할 것이다."
그룹 분할
- A 그룹(기존 UI), B 그룹(변경된 UI)으로 나누어 트래픽을 배분.
테스트 실행 및 데이터 수집
- 사용자 행동 데이터를 분석.
결과 분석
- 클릭률(CTR), 전환율(Conversion Rate) 등을 측정하여 최적의 UI 선택.

💡 A/B 테스트는 웹사이트, 모바일 앱의 UX 개선 및 비즈니스 성과 최적화에 매우 중요한 기법.

37. QA에서 로그 분석 (Log Analysis)

소프트웨어가 실행 중 발생하는 로그 데이터를 분석하여 시스템의 상태 및 오류를 추적하는 QA 기법.

(1) 로그 분석의 필요성

테스트 환경에서 발견하지 못한 결함을 운영 환경에서 실시간으로 모니터링 가능.
예기치 않은 예외(Exception), 성능 저하 문제를 사전에 감지.

(2) 로그 분석 도구

ELK Stack (Elasticsearch, Logstash, Kibana): 로그 수집, 검색, 시각화 도구.
Splunk: 머신러닝을 활용한 로그 분석 및 보안 모니터링.
Graylog: 실시간 로그 모니터링 및 알림 기능 제공.

💡 로그 분석을 QA 프로세스에 포함하면 시스템 안정성이 대폭 향상됨.

38. QA에서의 애플리케이션 모니터링 (Application Monitoring)

운영 환경에서 애플리케이션의 성능 및 오류를 실시간으로 감시하는 활동.

(1) 주요 모니터링 지표

응답 시간(Response Time)
- API, DB 쿼리, UI 반응 속도를 측정.
CPU/메모리 사용량
- 시스템 과부하 여부를 실시간 모니터링.
오류 발생률 (Error Rate)
- HTTP 500, 404 등 오류 비율을 측정.

(2) 대표적인 모니터링 도구

New Relic: 실시간 애플리케이션 성능 모니터링.
AppDynamics: 비즈니스 트랜잭션 추적 및 오류 감지.
Datadog: 클라우드 기반 애플리케이션 모니터링.

💡 애플리케이션 모니터링을 통해 운영 환경에서도 지속적인 품질 관리 가능.

1. Shift-Left Testing (시프트 레프트 테스팅) - 왜 중요한가?

Shift-Left Testing은 소프트웨어 개발 초기 단계에서 테스트를 수행하는 전략이다.
과거에는 개발이 완료된 후 QA 테스트를 진행했지만, 이 방법은 결함 수정 비용이 많이 들고, 일정이 지연되는 문제가 있었다.
Shift-Left Testing을 적용하면 테스트를 조기에 수행하여 결함을 빠르게 발견하고 수정 비용을 절감할 수 있음.

(1) 왜 Shift-Left Testing이 중요한가?

초기 결함 발견 → 수정 비용 절감
- 개발이 완료된 후 발견된 결함을 수정하는 비용은 초기 개발 단계에서 수정하는 것보다 5~10배 비싸다.
- 따라서 개발 초기에 결함을 발견하는 것이 가장 비용 효율적이다.
개발 주기의 안정성 향상
- Shift-Left Testing을 적용하면, 기능이 구현될 때마다 테스트가 진행되므로 나중에 전체 기능을 테스트할 때 큰 문제가 발생하지 않는다.
자동화 테스트 도입과 시너지 효과
- TDD (테스트 주도 개발), CI/CD 등과 결합하여 자동화된 테스트 환경을 구축하면 더 효율적인 품질 보장이 가능하다.

(2) Shift-Left Testing의 주요 기법

① TDD (Test-Driven Development, 테스트 주도 개발)

테스트 코드를 먼저 작성하고, 이를 통과하는 기능을 개발하는 방식.
개발자가 기능을 구현하기 전에 먼저 테스트 케이스를 작성하므로, 자연스럽게 결함이 줄어들고, 코드 품질이 향상된다.
TDD의 단계:
1. 테스트 작성: 실패할 수밖에 없는 테스트 코드 작성.
2. 테스트 실행: 당연히 실패함.
3. 코드 작성: 테스트를 통과하도록 최소한의 코드 작성.
4. 리팩토링: 중복 코드 제거 및 최적화.
5. 반복.

② 정적 코드 분석 (Static Code Analysis)

소프트웨어를 실행하지 않고 코드 자체를 분석하여 잠재적인 결함을 탐지하는 방법.
대표적인 정적 분석 도구:
- SonarQube: 코드 품질 및 보안 점검.
- Checkstyle, PMD: Java 코드 스타일 검사.
- ESLint: JavaScript 코드 스타일 및 오류 분석.

③ CI/CD 파이프라인에서의 자동화 테스트

코드가 빌드될 때마다 자동으로 테스트를 실행하는 방식.
주요 CI/CD 도구:
- Jenkins
- GitHub Actions
- GitLab CI/CD
- Azure DevOps

💡 결론: Shift-Left Testing을 적용하면 초기 단계에서 결함을 찾아내고, 개발 비용을 절감할 수 있으며, 자동화 테스트와 결합하면 품질이 대폭 향상된다.

2. 테스트 자동화 (Test Automation) - 실무에서 어떻게 적용하는가?

테스트 자동화는 반복적인 테스트를 자동으로 수행하여 QA 프로세스를 최적화하는 방법이다.

(1) 테스트 자동화가 중요한 이유

QA 생산성 향상
- 반복적인 테스트를 자동화하면 테스트 수행 시간을 줄일 수 있고, QA 팀은 더 중요한 테스트(탐색적 테스트 등)에 집중할 수 있다.
회귀 테스트 효율성 증가
- 소프트웨어가 업데이트될 때마다 기존 기능이 정상적으로 동작하는지 확인해야 하는데, 이를 회귀 테스트(Regression Test) 라고 한다.
- 자동화된 회귀 테스트를 사용하면 수백 개의 테스트를 몇 분 안에 실행 가능.
테스트 일관성 유지
- 수동 테스트는 사람의 실수(오타, 실수로 테스트 스텝 건너뛰기 등) 가 발생할 가능성이 높다.
- 자동화 테스트는 항상 동일한 방식으로 테스트를 수행하므로 신뢰성이 높다.

(2) 테스트 자동화 도구와 사용 사례

① 유닛 테스트 (Unit Testing)

개별 모듈이 올바르게 동작하는지 확인하는 테스트.
주요 도구:
- Java → JUnit, TestNG
- Python → PyTest, unittest
- JavaScript → Jest, Mocha

② UI 테스트 (End-to-End Test)

웹/모바일 UI 테스트 자동화.
주요 도구:
- Selenium (웹 UI 자동화)
- Cypress (웹 프레임워크와 통합이 쉬운 UI 자동화 도구)
- Appium (모바일 앱 테스트)

③ API 테스트 (API Testing)

REST API 및 GraphQL API를 자동화 테스트하는 도구.
주요 도구:
- Postman (API 요청 자동화 및 스크립팅 가능)
- RestAssured (Java 기반 API 테스트)
- SoapUI (SOAP, REST API 테스트)

💡 결론: 실무에서 테스트 자동화를 적용하면 반복적인 테스트를 빠르게 실행하고, 회귀 테스트를 더욱 효율적으로 수행할 수 있다.

3. 성능 테스트 (Performance Testing) - 실제로 어떻게 하는가?

성능 테스트는 시스템이 특정한 부하(트래픽, 사용량)에서도 안정적으로 동작하는지 확인하는 테스트이다.

(1) 성능 테스트가 중요한 이유

사용자가 많아지면 시스템이 어떻게 반응하는지 확인 필요.
트래픽이 급증하면 응답 속도가 느려지거나 시스템이 다운될 위험이 있음.
성능 이슈는 운영 환경에서 발견되면 해결하는 데 많은 비용과 시간이 소요됨.

(2) 성능 테스트 유형

테스트 유형설명

부하 테스트 (Load Testing)	정상적인 사용량에서의 성능 측정
스트레스 테스트 (Stress Testing)	최대 부하를 초과했을 때 시스템 반응 확인
내구성 테스트 (Endurance Testing)	장시간 동안 시스템이 안정적으로 동작하는지 테스트
스파이크 테스트 (Spike Testing)	갑작스러운 트래픽 증가 시 시스템 반응 테스트

(3) 성능 테스트 도구

JMeter → 부하 및 스트레스 테스트 자동화.
Gatling → 실시간 성능 모니터링 및 분석.
Locust → Python 기반 성능 테스트 도구.

(4) 성능 테스트 수행 절차

테스트 목표 정의
- "최대 10,000명의 동시 접속자를 처리할 수 있는가?"
테스트 환경 준비
- 실제 운영 환경과 유사한 환경을 구성.
부하 시나리오 작성
- 사용자 수를 증가시키면서 부하 테스트 진행.
결과 분석
- 평균 응답 시간, CPU 사용량, 에러율 분석.

💡 결론: 성능 테스트를 제대로 수행하면 시스템이 트래픽 증가에도 안정적으로 동작할 수 있도록 대비 가능.

✅ 정리: 반드시 알아야 할 QA 개념

Shift-Left Testing → 개발 초기부터 테스트를 수행하여 비용 절감.
테스트 자동화 → 수작업 테스트를 줄이고, 빠르고 신뢰성 있는 QA 수행.
성능 테스트 → 시스템이 부하에도 안정적으로 동작하는지 검증.

4. 회귀 테스트 (Regression Testing)

회귀 테스트는 코드 변경 후 기존 기능이 예상대로 동작하는지 확인하는 테스트이다. 소프트웨어는 지속적으로 업데이트되며, 새로운 기능 추가, 버그 수정, 성능 개선 등이 이루어지기 때문에, 이 과정에서 기존 기능이 의도치 않게 손상될 수 있다.

(1) 회귀 테스트가 중요한 이유

코드 변경의 영향 검증: 소프트웨어는 끊임없이 진화하며, 그 과정에서 기존 기능이 제대로 동작하지 않을 가능성이 있음.
결함 방지: 새로운 코드가 기존 코드와 충돌하여 새로운 결함을 발생시키는 것을 방지.
고객 만족도 향상: 안정적인 소프트웨어 제공을 통해 사용자 경험 개선.

(2) 회귀 테스트 전략

선택적 회귀 테스트 (Selective Regression Testing)
- 변경된 부분과 그와 직접적으로 연관된 부분만을 집중적으로 테스트.
완전 회귀 테스트 (Complete Regression Testing)
- 전체 시스템을 테스트. 시간이 많이 소요되므로 중요 릴리스 시 주로 사용.
자동화된 회귀 테스트
- 자동화 도구를 활용해 정기적으로 회귀 테스트를 수행.
- 주기적으로 테스트 케이스를 업데이트하여 유지.

(3) 회귀 테스트 도구

Selenium: 웹 애플리케이션의 UI 테스트 자동화에 적합.
TestNG, JUnit: 단위 테스트 및 회귀 테스트 자동화에 사용.
Cypress: 최신 프런트엔드 기술과의 호환성이 좋은 도구.

💡 결론: 회귀 테스트를 적절히 수행하면 코드 변경으로 인한 불안정성을 최소화할 수 있다. 특히, 자동화를 통해 반복적인 회귀 테스트를 효율적으로 관리하는 것이 중요하다.

5. QA에서의 결함 관리 (Defect Management)

결함 관리 프로세스는 테스트 중 발견된 결함(버그)을 체계적으로 기록, 추적, 수정하는 일련의 절차를 말한다.

(1) 결함 관리의 중요성

결함 추적 및 수정: 모든 결함을 추적하여 해당 결함이 해결될 때까지 관리.
품질 개선: 결함 데이터를 분석하여 결함 발생 원인을 파악하고, 재발 방지 전략을 수립.
개발과 테스트 간의 원활한 커뮤니케이션: QA와 개발팀 간에 명확한 결함 정보를 공유하여 신속한 수정이 이루어지도록 함.

(2) 결함 라이프사이클 (Bug Lifecycle)

결함 발견 (New): 테스트 중 결함이 발견되어 등록.
할당 (Assigned): 개발자에게 결함이 할당.
수정 중 (In Progress): 개발자가 결함을 수정.
수정 완료 (Fixed): 수정이 완료된 상태.
재테스트 (Retesting): QA가 수정된 결함을 다시 테스트.
종료 (Closed): 결함이 해결되었고, 문제가 재발하지 않음.
재오픈 (Reopened): 결함이 완전히 해결되지 않아 다시 테스트를 요구.

(3) 결함 관리 도구

Jira: 결함 관리 및 프로젝트 관리 도구. 이슈를 체계적으로 관리할 수 있음.
Bugzilla: 결함 추적에 특화된 도구로, 결함 상태와 관련 데이터를 상세히 기록 가능.
Redmine: 프로젝트 관리 및 결함 추적 기능을 동시에 제공.

💡 결론: 결함 관리는 효율적인 QA 프로세스의 핵심이다. 결함을 체계적으로 관리하고 추적함으로써, 소프트웨어 품질을 높이고, 출시 후 오류를 최소화할 수 있다.

6. API 테스트 (API Testing)

API 테스트는 서버와 클라이언트 간의 데이터 전송 및 상호작용이 올바르게 이루어지는지 검증하는 테스트이다. 현대 소프트웨어는 대부분 REST API, GraphQL API 등을 통해 여러 서비스와 상호작용하므로, API 테스트는 매우 중요하다.

(1) API 테스트가 중요한 이유

백엔드 기능 검증: UI가 변경되어도 백엔드의 기능이 정상적으로 동작하는지 확인 가능.
독립적인 테스트 가능: UI 개발이 완료되지 않은 상태에서도 백엔드 기능을 테스트할 수 있음.
데이터 무결성 보장: API를 통해 전송되는 데이터의 정확성과 일관성을 검증.

(2) 주요 테스트 항목

기능 테스트: API가 요구사항에 맞게 동작하는지 확인.
보안 테스트: 인증, 권한 부여, 데이터 암호화 등이 올바르게 이루어지는지 확인.
성능 테스트: API의 응답 시간, 처리량을 측정.
에러 처리 테스트: 잘못된 입력에 대해 적절한 에러 메시지를 반환하는지 확인.

(3) API 테스트 도구

Postman: HTTP 요청을 쉽게 테스트하고, 테스트 스크립트를 작성할 수 있음.
RestAssured: Java 기반의 REST API 자동화 테스트 도구.
SoapUI: SOAP 및 REST API의 기능 테스트와 보안 테스트에 사용.

💡 결론: API 테스트를 통해 백엔드와 프런트엔드 간의 데이터 전송이 정확하게 이루어지는지 확인하고, 보안 및 성능 문제를 조기에 발견할 수 있다.

7. 보안 테스트 (Security Testing)

보안 테스트는 소프트웨어가 보안 취약점으로부터 안전한지 검증하는 테스트이다. 특히, 사용자 데이터를 다루는 소프트웨어에서는 보안이 매우 중요한 이슈이다.

(1) 보안 테스트가 중요한 이유

데이터 보호: 개인정보나 기밀 정보가 외부에 노출되지 않도록 보호.
취약점 탐지: 시스템이 공격에 취약하지 않은지 확인.
규제 준수: GDPR, HIPAA 등 법적 규제에 따른 보안 요건 충족.

(2) 보안 테스트 유형

침투 테스트 (Penetration Testing): 실제 해커처럼 시스템을 공격하여 보안 취약점 발견.
취약점 스캐닝 (Vulnerability Scanning): 자동화 도구를 사용해 시스템의 취약점을 스캔.
SQL Injection 테스트: 데이터베이스에 불법적인 접근이 가능한지 확인.
XSS (Cross-Site Scripting) 테스트: 웹 페이지에 악성 스크립트를 삽입할 수 있는지 확인.

(3) 보안 테스트 도구

OWASP ZAP: 웹 애플리케이션의 취약점을 분석하고 테스트.
Burp Suite: 웹 보안 테스트에 특화된 도구로, 다양한 공격 시나리오를 지원.
Nmap: 네트워크 보안 스캐닝 도구.

💡 결론: 보안 테스트는 사용자 데이터를 보호하고 시스템의 안전성을 유지하기 위해 필수적이다. 이를 통해 외부 공격에 대한 대응력을 높이고, 법적 규제를 준수할 수 있다.

8. 테스트 전략 (Test Strategy)

테스트 전략(Test Strategy)은 프로젝트 전반에서 어떻게 테스트를 수행할 것인지에 대한 고수준의 계획이다.
일반적인 테스트 계획(Test Plan)보다 더 포괄적인 개념으로, 조직 전체 또는 특정 프로젝트의 테스트 방향성을 정의하는 역할을 한다.

(1) 테스트 전략을 수립하는 이유

테스트 목표를 명확하게 정의하고, 비즈니스 요구사항에 맞춘 테스트 방향성을 설정.
프로젝트의 품질 목표를 효과적으로 달성할 수 있도록 적절한 테스트 기법을 선정.
제한된 자원(시간, 인력, 예산) 내에서 최적의 테스트 실행 방법을 결정.

(2) 테스트 전략의 주요 요소

테스트 범위 (Scope of Testing)
- 어떤 기능을 테스트할 것인가?
- 주요 테스트 유형(기능 테스트, 성능 테스트, 보안 테스트 등)을 정의.
테스트 접근 방식 (Testing Approach)
- 블랙박스 테스트 vs 화이트박스 테스트.
- 수동 테스트 vs 자동화 테스트.
- 기능 기반 테스트 vs 리스크 기반 테스트.
테스트 환경 (Test Environment)
- 실제 운영 환경과 유사한 테스트 환경을 구축하는 방법.
- 가상화, 클라우드 환경 사용 여부.
테스트 도구 및 프레임워크
- Selenium, JUnit, Postman 등 사용할 도구를 미리 정의.
테스트 종료 기준 (Exit Criteria)
- "버그가 X개 이하일 때 테스트 완료"와 같은 기준을 설정.

💡 결론: 테스트 전략을 수립하면 비효율적인 테스트를 줄이고, 프로젝트 일정 내에서 최상의 품질을 보장할 수 있다.

9. 리스크 기반 테스트 (Risk-Based Testing)

리스크 기반 테스트는 시스템에서 가장 중요한 부분과 결함 가능성이 높은 부분을 우선적으로 테스트하는 전략이다.

(1) 리스크 기반 테스트가 중요한 이유

모든 기능을 100% 테스트하는 것은 불가능함 → 우선순위를 정해야 함.
프로젝트 일정이 촉박할 때, 중요한 기능에 집중하여 품질을 확보할 수 있음.

(2) 리스크 분석 방법

비즈니스 중요도(Business Impact) 평가
- 특정 기능이 비즈니스에 미치는 영향이 얼마나 큰지 평가.
- 예: 결제 시스템, 사용자 로그인 기능은 매우 중요함.
결함 발생 가능성(Bug Likelihood) 평가
- 과거 데이터를 바탕으로 어떤 기능에서 결함이 자주 발생하는지 분석.
- 신규 개발된 기능은 버그 발생 가능성이 높음.
우선순위 매기기
- 비즈니스 중요도 X 결함 발생 가능성 = 테스트 우선순위 결정.
- 가장 중요한 기능을 먼저 테스트하고, 덜 중요한 기능은 이후에 진행.

💡 결론: 리스크 기반 테스트를 활용하면 제한된 리소스(시간, 인력) 내에서도 효과적인 테스트를 수행할 수 있음.

10. 데이터베이스 테스트 (Database Testing)

데이터베이스 테스트는 애플리케이션이 올바른 데이터를 저장하고 검색하는지 검증하는 과정이다.

(1) 데이터베이스 테스트의 주요 항목

데이터 무결성 검사 (Data Integrity Testing)
- ACID 원칙(원자성, 일관성, 고립성, 지속성)이 잘 지켜지는지 확인.
- 트랜잭션이 실패해도 데이터가 손상되지 않는지 검증.
데이터베이스 성능 테스트
- SQL 쿼리 실행 속도를 측정하고, 인덱싱, 쿼리 최적화 수행.
- EXPLAIN PLAN을 사용하여 SQL 실행 계획 분석.
데이터 보안 테스트
- 데이터가 암호화되어 저장되는지 확인.
- SQL Injection 공격이 가능한지 테스트.
데이터 마이그레이션 테스트
- DB를 업그레이드하거나 변경할 때 데이터가 손실 없이 정상적으로 이동하는지 확인.

(2) 데이터베이스 테스트 도구

SQLUnit: 유닛 테스트용 SQL 테스트 프레임워크.
DbFit: 데이터베이스 테스트 자동화 도구.
PostgreSQL Explain Analyze: SQL 실행 계획 분석 도구.

💡 결론: 데이터베이스 테스트를 수행하면 데이터 손실, 무결성 문제, 성능 저하를 사전에 방지할 수 있음.

11. A/B 테스트 (A/B Testing)

A/B 테스트는 두 개 이상의 버전을 실험하여 더 나은 사용자 경험을 찾는 테스트 기법이다.

(1) A/B 테스트의 목적

사용자의 행동 데이터를 기반으로 최적의 UI/UX를 찾음.
비즈니스 목표(전환율 증가, 클릭률 향상 등)를 최적화.
데이터 기반 의사 결정 → 감이 아니라 실험 결과를 바탕으로 기능 개선.

(2) A/B 테스트 실행 절차

가설 수립
- "초록색 버튼이 파란색 버튼보다 클릭률이 더 높을 것이다."
A/B 그룹 분할
- 사용자 절반(A그룹) → 기존 UI 사용.
- 나머지 절반(B그룹) → 새로운 UI 사용.
데이터 수집 및 분석
- 클릭률, 전환율(Conversion Rate) 등의 데이터를 측정.
- 통계적으로 유의미한 차이가 있는지 분석.
결론 도출 및 반영
- B그룹의 클릭률이 높으면, 새로운 UI를 적용.

(3) A/B 테스트 도구

Google Optimize: 구글이 제공하는 A/B 테스트 도구.
Optimizely: UI 실험 및 테스트 도구.
VWO (Visual Website Optimizer): 웹사이트 UX 최적화 도구.

💡 결론: A/B 테스트를 활용하면 실험을 통해 사용자 경험을 최적화하고, 제품 개선 방향을 데이터 기반으로 결정할 수 있음.

12. 탐색적 테스트 (Exploratory Testing)

탐색적 테스트는 사전에 정의된 테스트 케이스 없이, 테스터의 경험과 직관을 바탕으로 결함을 찾아내는 방법이다.

(1) 탐색적 테스트가 중요한 이유

정형화된 테스트 케이스로는 찾기 어려운 버그를 발견 가능.
예측할 수 없는 사용자 행동을 시뮬레이션할 수 있음.
새로운 기능이나 초기 개발된 제품에서 특히 효과적.

(2) 탐색적 테스트 방법론

차터(테스트 목표) 설정
- 특정 기능이나 시나리오를 중심으로 테스트를 수행.
테스트 수행
- 예상치 못한 입력을 시도하고, 엣지 케이스를 테스트.
버그 분석 및 문서화
- 발견된 버그를 기록하고 재현 방법을 문서화.

💡 결론: 탐색적 테스트는 정형화된 테스트의 한계를 보완하고, 실사용자 관점에서 결함을 발견하는 데 효과적이다.

1. 소프트웨어 테스트 원칙 (Fundamental Principles of Testing)

Pretest에서는 테스트의 기본 원칙을 이해하고 있는지 평가할 가능성이 높음.

(1) 주요 원칙과 설명

원칙설명근거

테스트는 결함이 존재함을 증명할 수 있지만, 결함이 없음을 증명할 수 없다	모든 소프트웨어에는 결함이 있을 가능성이 있으므로, 완벽한 테스트는 불가능함	결함이 없다고 하더라도 모든 가능성을 테스트할 수는 없음
완벽한 테스트는 불가능하다	모든 입력 조합을 테스트하는 것은 현실적으로 불가능함	예를 들어, 비밀번호 입력 필드에서 모든 가능성을 테스트하는 것은 비효율적
조기 테스팅이 중요하다 (Shift-Left Testing)	개발 초기에 테스트할수록 비용 절감 가능	결함 수정 비용은 개발 후반으로 갈수록 증가 (Shift-Left Testing 개념)
결함 집중의 법칙 (80/20 법칙)	전체 코드의 20%가 80%의 결함을 포함함	과거 결함 데이터를 분석하면 특정 모듈에서 많은 버그가 발생하는 경향
살충제 패러독스	동일한 테스트를 반복하면 새로운 결함을 찾기 어려움	테스트 케이스를 주기적으로 변경하여 새로운 결함을 발견해야 함
테스트는 정황(Context)에 따라 달라진다	소프트웨어의 특성에 따라 테스트 방법이 다름	예: 금융 시스템은 보안 테스트가 중요, 게임은 성능 테스트가 중요
오류 부재의 궤변	결함이 없다고 해서 반드시 품질이 높다고 할 수 없음	사용자의 요구사항을 충족하지 못하면 품질이 낮은 소프트웨어

(2) Pretest에서 출제 가능성

✅ 테스트 원칙 중 하나를 제시하고, 그 원칙이 의미하는 바를 선택하라는 문제
✅ "살충제 패러독스를 방지하려면 어떤 접근 방식이 필요한가?" 같은 응용형 문제

2. 테스트 유형 (Types of Testing)

Pretest에서는 각 테스트 유형의 목적과 차이점을 구별할 수 있는지 평가할 가능성이 높음.

(1) 주요 테스트 유형

테스트 유형목적예시

단위 테스트 (Unit Test)	개별 모듈/함수의 동작 검증	JUnit, PyTest 사용
통합 테스트 (Integration Test)	모듈 간의 상호작용 확인	API 호출 검증
시스템 테스트 (System Test)	전체 시스템이 요구사항을 충족하는지 검증	기능 및 비기능 테스트 수행
인수 테스트 (Acceptance Test)	최종 사용자의 요구사항 충족 여부 검증	실제 사용자 또는 QA 팀이 수행
회귀 테스트 (Regression Test)	기존 기능이 변경 없이 동작하는지 확인	소프트웨어 업데이트 후 기존 테스트 실행
성능 테스트 (Performance Test)	시스템의 속도, 안정성 검증	JMeter, LoadRunner 사용
보안 테스트 (Security Test)	시스템이 보안 위협에 안전한지 검증	OWASP ZAP 사용
탐색적 테스트 (Exploratory Test)	정해진 테스트 케이스 없이 결함 발견	경험 기반 테스트

(2) Pretest에서 출제 가능성

✅ "통합 테스트와 시스템 테스트의 차이점은?" 같은 개념 비교 문제
✅ "성능 테스트에서 측정해야 하는 주요 지표는?" 같은 실무적 응용 문제

3. 테스트 설계 기법 (Test Design Techniques)

테스트 케이스를 효과적으로 설계할 수 있는지 평가하는 문제 출제 가능.

(1) 주요 테스트 기법

기법설명예시

동치 분할 (Equivalence Partitioning)	입력값을 여러 그룹(유효/무효)으로 나누어 대표값을 테스트	1~100 유효 → 50 테스트, 0/101 무효
경계값 분석 (Boundary Value Analysis)	최소/최대 경계를 중심으로 테스트	1~100 유효 → 0, 1, 100, 101 테스트
결정 테이블 테스트 (Decision Table Testing)	여러 조건 조합을 분석하여 테스트	회원가입 시 "이메일 인증 + 약관 동의" 조합 테스트
상태 전이 테스트 (State Transition Testing)	상태 변화에 따라 테스트	ATM: "카드 삽입 → PIN 입력 → 출금 요청" 상태 전이
오류 추정 (Error Guessing)	경험을 바탕으로 오류 가능성이 높은 부분 테스트	로그인 시 "빈 값 입력", "특수 문자 입력" 등 시도

(2) Pretest에서 출제 가능성

✅ "경계값 분석 기법을 적용한 테스트 케이스를 선택하시오" 같은 문제
✅ "동치 분할을 적용하면 테스트 케이스가 몇 개로 줄어드는가?" 같은 문제

4. 결함 관리 (Defect Management)

Pretest에서는 결함 관리 프로세스를 이해하고 있는지 평가할 가능성이 높음.

(1) 결함 라이프사이클 (Bug Lifecycle)

New (신규) → 결함 발견 후 등록됨.
Assigned (할당됨) → 개발자에게 배정됨.
In Progress (수정 중) → 결함 수정 진행 중.
Fixed (수정 완료) → 개발자가 수정 완료.
Retest (재테스트) → QA가 다시 테스트.
Closed (종료됨) → 결함이 해결됨.
Reopened (재오픈됨) → 결함이 완전히 해결되지 않아 다시 오픈됨.

(2) 결함 심각도(Severity) vs 우선순위(Priority)

구분설명예시

심각도 (Severity)	결함이 시스템에 미치는 영향	Critical (시스템 다운) / Minor (UI 오타)
우선순위 (Priority)	수정 시급성	High (즉시 수정 필요) / Low (향후 수정 가능)

(3) Pretest에서 출제 가능성

✅ "다음 중 결함 관리 프로세스의 올바른 순서는?" 같은 문제
✅ "Critical이지만 Low Priority인 버그의 예시는?" 같은 응용 문제

5. 자동화 테스트 (Test Automation)

Pretest에서는 자동화 테스트의 필요성과 주요 도구에 대한 이해도를 평가할 가능성이 높음.

(1) 자동화 테스트의 필요성

반복적인 테스트를 자동으로 수행하여 생산성 향상.
회귀 테스트에 적합 → 코드 변경 후 자동으로 기존 기능을 검증.
테스트 실행 속도 증가 → 수동 테스트 대비 효율적.

(2) 주요 자동화 테스트 도구

테스트 유형도구설명

유닛 테스트	JUnit, PyTest	코드 단위 테스트
UI 테스트	Selenium, Cypress	브라우저 UI 테스트
API 테스트	Postman, RestAssured	REST API 테스트
성능 테스트	JMeter, Locust	부하/성능 테스트

(3) Pretest에서 출제 가능성

✅ "Selenium은 어떤 유형의 테스트에 사용되는가?" 같은 개념 문제
✅ "자동화 테스트의 장점은?" 같은 서술형 문제

🔥 결론: 온라인 Pretest에 출제될 가능성이 높은 개념들

✅ 소프트웨어 테스트 원칙
✅ 테스트 유형과 차이점
✅ 테스트 설계 기법 (동치 분할, 경계값 분석 등)
✅ 결함 관리 프로세스 (Bug Lifecycle, Severity vs Priority)
✅ 자동화 테스트 및 주요 도구

1. 소프트웨어 테스트 원칙 문제

문제 1. 다음 중 소프트웨어 테스트 원칙에 대한 설명으로 올바른 것은?

테스트를 수행하면 모든 결함을 발견할 수 있다.
동일한 테스트 케이스를 반복해서 실행하면 새로운 결함을 계속 발견할 수 있다.
소프트웨어에 결함이 없다고 하더라도 품질이 높다고 단정할 수 없다.
테스트는 소프트웨어 개발이 완료된 후에만 수행해야 한다.

✅ 정답: ③ 소프트웨어에 결함이 없다고 하더라도 품질이 높다고 단정할 수 없다.

🔍 해설:

① 틀림: 테스트는 모든 결함을 찾을 수 없으며, 완벽한 테스트는 불가능하다.
② 틀림: 동일한 테스트를 반복하면 더 이상 새로운 결함을 찾기 어려운 살충제 패러독스가 발생할 수 있다.
④ 틀림: 테스트는 개발 완료 후뿐만 아니라 초기 단계에서도 수행하는 것이 중요하다 (Shift-Left Testing 개념).
③ 정답: 사용자의 요구사항을 충족하지 않는다면 결함이 없어도 품질이 낮은 소프트웨어가 될 수 있다.

2. 테스트 유형 문제

문제 2. 다음 중 시스템이 예상된 성능을 유지하는지 검증하는 테스트는?

단위 테스트 (Unit Test)
통합 테스트 (Integration Test)
성능 테스트 (Performance Test)
탐색적 테스트 (Exploratory Test)

✅ 정답: ③ 성능 테스트 (Performance Test)

🔍 해설:

① 단위 테스트: 개별 모듈/함수가 올바르게 동작하는지 검증.
② 통합 테스트: 여러 모듈이 정상적으로 연동되는지 확인.
③ 성능 테스트: 시스템의 속도, 응답 시간, 처리량 등을 평가하여 예상된 성능을 유지하는지 검증 (정답!).
④ 탐색적 테스트: 사전에 정해진 테스트 케이스 없이 테스터의 직관과 경험을 활용하여 테스트.

3. 테스트 설계 기법 문제

문제 3. "회원 가입 시 나이 입력 필드는 1~100까지 입력할 수 있다." 이 경우, 경계값 분석 기법을 적용한 테스트 케이스로 가장 적절한 것은?

0, 50, 100, 101
1, 50, 100
-1, 0, 1, 99, 100, 101
10, 20, 30, 40

✅ 정답: ③ -1, 0, 1, 99, 100, 101

🔍 해설:

경계값 분석 (Boundary Value Analysis) 는 최소값과 최대값 근처에서 오류가 많이 발생한다는 원칙에 따라 경계를 중심으로 테스트를 수행해야 한다.
①, ② 틀림: 0, 50, 100은 포함되었지만, 경계 테스트의 핵심인 최소/최대값 바로 바깥쪽(-1, 101) 이 포함되지 않음.
④ 틀림: 무작위 숫자로 테스트하여 경계값 검증을 제대로 수행하지 않음.
③ 정답: 최소값(1), 최대값(100), 최소값의 직전(-1, 0), 최대값의 직후(101)를 포함하여 가장 완벽한 경계값 테스트를 수행할 수 있음.

4. 결함 관리 문제

문제 4. 다음 중 결함의 심각도(Severity)와 우선순위(Priority)에 대한 설명으로 적절하지 않은 것은?

심각도가 높아도 우선순위가 낮을 수 있다.
심각도가 낮아도 우선순위가 높을 수 있다.
심각도는 주로 QA 팀이 결정하고, 우선순위는 비즈니스 팀과 개발팀이 결정할 수 있다.
심각도가 높은 결함은 항상 우선순위가 높다.

✅ 정답: ④ 심각도가 높은 결함은 항상 우선순위가 높다.

🔍 해설:

① 정답: 예를 들어, 치명적인 오류(Critical Bug)가 발생했지만, 해당 기능이 잘 사용되지 않는다면 우선순위가 낮을 수도 있음.
② 정답: UI 오타 같은 경미한 오류(Minor Bug) 이더라도, 마케팅 캠페인 전에 긴급 수정이 필요하다면 우선순위가 높을 수 있음.
③ 정답: 심각도(Severity)는 보통 QA 팀이 결정하고, 우선순위(Priority)는 비즈니스적인 판단이 포함될 수 있음.
④ 틀림: 심각도가 높아도 비즈니스적으로 중요하지 않다면 우선순위가 낮아질 수 있음.

5. 자동화 테스트 문제

문제 5. 자동화 테스트의 주요 장점으로 적절하지 않은 것은?

테스트 실행 속도를 향상시킨다.
회귀 테스트(Regression Test)를 자동으로 수행할 수 있다.
모든 유형의 테스트를 완전히 자동화할 수 있다.
테스트의 일관성을 유지할 수 있다.

✅ 정답: ③ 모든 유형의 테스트를 완전히 자동화할 수 있다.

🔍 해설:

① 정답: 자동화 테스트는 반복적인 테스트를 빠르게 수행하여 속도를 향상시킴.
② 정답: 코드가 변경될 때마다 자동으로 회귀 테스트를 수행하여 기존 기능이 정상적으로 동작하는지 확인 가능.
③ 틀림: 탐색적 테스트, UX 테스트, 직관이 필요한 테스트는 자동화하기 어려움.
④ 정답: 자동화 테스트는 항상 동일한 방식으로 테스트를 수행하여 테스트 결과의 일관성을 유지할 수 있음.

6. API 테스트 문제

문제 6. API 테스트에서 HTTP 상태 코드 500이 반환되었다면, 이를 의미하는 것은?

요청이 성공적으로 처리되었음을 의미한다.
인증이 실패했음을 의미한다.
클라이언트 요청이 잘못되었음을 의미한다.
서버 내부 오류가 발생했음을 의미한다.

✅ 정답: ④ 서버 내부 오류가 발생했음을 의미한다.

🔍 해설:

① 틀림: 요청이 성공적으로 처리되면 200 OK가 반환됨.
② 틀림: 인증 실패는 401 Unauthorized 코드가 반환됨.
③ 틀림: 클라이언트 요청 오류는 400 Bad Request 코드가 반환됨.
④ 정답: 500 Internal Server Error는 서버 내부에서 예기치 않은 오류가 발생했을 때 반환되는 상태 코드.

🔥 결론: Pretest 대비를 위한 핵심 정리

✅ 소프트웨어 테스트 원칙 – Shift-Left Testing, 살충제 패러독스 이해
✅ 테스트 유형 – 단위 테스트, 통합 테스트, 성능 테스트 차이점 숙지
✅ 테스트 설계 기법 – 동치 분할, 경계값 분석 실무 적용 능력 필요
✅ 결함 관리 – Bug Lifecycle과 Severity vs Priority 차이점 이해
✅ 자동화 테스트 – Selenium, JUnit 등 자동화 테스트의 장점 및 한계 이해
✅ API 테스트 – HTTP 상태 코드와 API 테스트 도구 (Postman, RestAssured) 숙지

7. 블랙박스 테스트 기법 문제

문제 7. 다음 중 블랙박스 테스트 기법에 해당하는 것은?

문장(Statement) 커버리지
동치 분할(Equivalence Partitioning)
분기(Branch) 커버리지
조건 커버리지 (Condition Coverage)

✅ 정답: ② 동치 분할(Equivalence Partitioning)

🔍 해설:

블랙박스 테스트는 내부 코드 구조를 모르는 상태에서, 입력과 출력 값만을 기준으로 테스트하는 기법이야.
①, ③, ④ 틀림: 문장 커버리지, 분기 커버리지, 조건 커버리지는 화이트박스 테스트 기법에 속함.
② 정답: 동치 분할은 입력값을 여러 그룹으로 나누고, 그룹 내 대표 값을 테스트하는 기법으로, 블랙박스 테스트에 해당함.

8. 회귀 테스트 문제

문제 8. 소프트웨어 업데이트 후, 기존 기능이 정상적으로 작동하는지 검증하는 테스트는?

탐색적 테스트
단위 테스트
회귀 테스트
인수 테스트

✅ 정답: ③ 회귀 테스트 (Regression Testing)

🔍 해설:

① 틀림: 탐색적 테스트는 테스터가 직관적으로 결함을 찾는 테스트 방법.
② 틀림: 단위 테스트는 개별 코드 모듈을 독립적으로 검증하는 테스트.
③ 정답: 회귀 테스트는 기존 기능이 코드 변경 후에도 정상적으로 동작하는지 확인하는 테스트.
④ 틀림: 인수 테스트는 사용자 요구사항이 충족되었는지를 검증하는 테스트.

9. 성능 테스트 문제

문제 9. 다음 중 성능 테스트에서 측정해야 할 핵심 지표가 아닌 것은?

응답 시간 (Response Time)
처리량 (Throughput)
코드 커버리지 (Code Coverage)
CPU 사용률 (CPU Utilization)

✅ 정답: ③ 코드 커버리지 (Code Coverage)

🔍 해설:

① 정답: 응답 시간은 사용자가 요청을 보낸 후 서버가 응답하는 데 걸리는 시간.
② 정답: 처리량은 단위 시간당 처리되는 요청 수.
③ 틀림: 코드 커버리지는 화이트박스 테스트의 측정 지표로, 성능 테스트와 관련 없음.
④ 정답: CPU 사용률은 서버의 자원 소비량을 측정하는 중요한 성능 지표.

10. SQL Injection 보안 테스트 문제

문제 10. 웹 애플리케이션이 SQL Injection 공격에 취약한지 테스트할 때 가장 적절한 입력값은?

SELECT * FROM users WHERE username = 'admin' AND password = 'password123';
' OR '1'='1' --
INSERT INTO users (username, password) VALUES ('hacker', 'hack123');
DELETE FROM users WHERE username = 'admin';

✅ 정답: ② ' OR '1'='1' --

🔍 해설:

SQL Injection 공격은 악의적인 SQL 문을 주입하여 데이터베이스를 조작하는 공격 기법이야.
① 틀림: 일반적인 SQL 쿼리일 뿐, 공격 패턴이 아님.
② 정답: ' OR '1'='1' -- 패턴은 항상 참이 되는 조건을 삽입하여 무단 로그인 가능하게 만드는 대표적인 SQL Injection 공격 방식.
③, ④ 틀림: 단순 SQL 문으로, 직접적인 SQL Injection 공격이 아님.

11. 테스트 환경 격리 문제

문제 11. 테스트를 운영 환경과 분리하여 수행하는 주요 목적은?

운영 데이터를 변경하여 결함을 빠르게 찾기 위해서
운영 환경에서 사용자의 실제 요청을 기반으로 테스트하기 위해서
테스트로 인해 운영 서비스에 영향을 주지 않도록 하기 위해서
개발자와 QA가 같은 환경에서 테스트를 진행하기 위해서

✅ 정답: ③ 테스트로 인해 운영 서비스에 영향을 주지 않도록 하기 위해서

🔍 해설:

① 틀림: 운영 데이터를 직접 변경하면 보안 및 데이터 손상 문제가 발생할 수 있음.
② 틀림: 테스트는 운영 환경에서 직접 수행하면 안 되며, 별도의 테스트 환경에서 수행해야 함.
③ 정답: 테스트 환경을 운영 환경과 분리하면, 테스트 과정에서 발생할 수 있는 문제가 실제 서비스에 영향을 미치는 것을 방지할 수 있음.
④ 틀림: 개발자와 QA는 테스트 환경에서 협력할 수 있지만, 운영 환경과의 격리가 더 중요한 이유임.

12. 테스트 자동화 전략 문제

문제 12. 다음 중 테스트 자동화 도입 시 고려해야 할 가장 중요한 요소는?

모든 테스트를 100% 자동화하는 것이 목표이다.
자주 반복되는 테스트를 우선적으로 자동화해야 한다.
자동화된 테스트는 한 번 작성하면 수정할 필요가 없다.
자동화 테스트는 수동 테스트보다 항상 더 효과적이다.

✅ 정답: ② 자주 반복되는 테스트를 우선적으로 자동화해야 한다.

🔍 해설:

① 틀림: 100% 자동화는 현실적으로 불가능함. UX 테스트나 탐색적 테스트는 여전히 수동으로 수행해야 함.
② 정답: 자동화 테스트는 회귀 테스트, API 테스트 등 자주 반복되는 테스트부터 도입하는 것이 효과적.
③ 틀림: 코드 변경이 있을 경우 자동화 테스트 스크립트도 업데이트해야 함.
④ 틀림: 자동화 테스트가 항상 더 효과적인 것은 아님. 탐색적 테스트, UI 테스트는 수동 테스트가 더 효과적일 수 있음.

13. 결함 재현성 문제

문제 13. QA가 결함을 발견했을 때, 결함이 다시 발생하도록 하는 과정을 무엇이라고 하는가?

결함 보고 (Defect Reporting)
결함 추적 (Defect Tracking)
결함 재현 (Defect Reproduction)
결함 종료 (Defect Closure)

✅ 정답: ③ 결함 재현 (Defect Reproduction)

🔍 해설:

① 틀림: 결함 보고는 결함을 발견한 후 문서화하는 과정.
② 틀림: 결함 추적은 결함이 해결될 때까지 관리하는 과정.
③ 정답: 결함 재현은 발견된 결함을 다시 실행하여 동일한 문제가 발생하는지 확인하는 과정.
④ 틀림: 결함 종료는 결함이 해결되었을 때 최종적으로 마무리하는 단계.

🔥 온라인 Pretest 대비 핵심 정리

✅ 블랙박스 테스트 vs 화이트박스 테스트 차이 이해하기
✅ 회귀 테스트, 성능 테스트, SQL Injection 보안 테스트 개념 숙지
✅ 테스트 환경 격리의 중요성과 운영 환경 분리 이유 이해하기
✅ 테스트 자동화 전략 – 100% 자동화는 불가능하며 반복적인 테스트부터 적용
✅ 결함 재현이 무엇인지 명확히 이해하고, 결함 추적 프로세스 익히기

14. 소프트웨어 개발 생명주기(SDLC) 문제

문제 14. 소프트웨어 개발 생명주기(SDLC)에서 테스트를 가장 빠르게 시작하는 개발 모델은?

V-모델 (V-Model)
폭포수 모델 (Waterfall Model)
애자일 모델 (Agile Model)
나선형 모델 (Spiral Model)

✅ 정답: ③ 애자일 모델 (Agile Model)

🔍 해설:

① V-모델: 개발 단계마다 대응하는 테스트 단계가 존재하지만, 기본적으로 설계가 완료된 후 테스트가 시작됨.
② 폭포수 모델: 한 단계가 끝나야 다음 단계가 진행되므로 테스트는 개발이 완료된 후 시작됨.
③ 정답 – 애자일 모델: 애자일 개발에서는 "Shift-Left Testing" 개념을 적용하여 개발 초기부터 지속적으로 테스트가 수행됨.
④ 나선형 모델: 리스크 분석을 기반으로 개발과 테스트가 반복되지만, 테스트가 개발 초기에 포함되지는 않음.

15. 결함 심각도 & 우선순위 문제

문제 15. 다음 중 "심각도(Severity)는 높지만, 우선순위(Priority)는 낮은" 결함 사례로 적절한 것은?

로그인 기능이 동작하지 않아 모든 사용자가 로그인을 할 수 없음.
특정 브라우저(예: Internet Explorer)에서 UI가 깨지지만, 서비스 사용에는 문제가 없음.
사용자가 결제 시 카드 정보를 입력하면 앱이 강제 종료됨.
비밀번호 변경 시, 확인 메시지가 표시되지 않음.

✅ 정답: ② 특정 브라우저(예: Internet Explorer)에서 UI가 깨지지만, 서비스 사용에는 문제가 없음.

🔍 해설:

① 틀림: 로그인 불가능 → 사용자가 시스템을 사용할 수 없으므로 심각도(Severity) 높고, 우선순위(Priority)도 높음.
② 정답: UI가 깨지는 문제는 시각적인 영향만 있을 뿐, 기능적으로는 문제가 없으므로 우선순위가 낮을 수 있음.
③ 틀림: 결제 시 앱이 종료되는 문제 → 비즈니스적으로 중요한 기능이므로 우선순위가 높음.
④ 틀림: 비밀번호 변경 후 확인 메시지가 없으면 UX에 영향은 주지만, 긴급 수정이 필요하지는 않음 (중간 우선순위 가능).

16. API 테스트 문제

문제 16. REST API에서 HTTP 상태 코드 404 Not Found가 의미하는 것은?

서버가 클라이언트 요청을 이해할 수 없음.
요청한 리소스(예: URL)가 존재하지 않음.
클라이언트의 요청이 성공적으로 처리됨.
서버 내부에서 오류가 발생함.

✅ 정답: ② 요청한 리소스(예: URL)가 존재하지 않음.

🔍 해설:

① 틀림: 서버가 클라이언트 요청을 이해할 수 없는 경우 400 Bad Request 반환.
② 정답: 404 Not Found는 요청한 리소스(파일, 페이지 등)가 존재하지 않는 경우 반환됨.
③ 틀림: 요청이 정상적으로 처리되었으면 200 OK 반환.
④ 틀림: 서버 내부 오류는 500 Internal Server Error 반환.

17. 탐색적 테스트 문제

문제 17. 탐색적 테스트(Exploratory Testing)의 가장 큰 장점은?

테스트 케이스가 명확하게 정의되어 있어 실행하기 쉽다.
예상치 못한 결함을 발견할 가능성이 높다.
자동화하기 쉬워 테스트 비용을 절감할 수 있다.
모든 입력값 조합을 테스트할 수 있다.

✅ 정답: ② 예상치 못한 결함을 발견할 가능성이 높다.

🔍 해설:

① 틀림: 탐색적 테스트는 사전에 정해진 테스트 케이스 없이 테스터의 경험과 직관을 바탕으로 수행하는 테스트.
② 정답: 예측하지 못한 사용자 행동을 시뮬레이션할 수 있으므로, 예상치 못한 결함을 발견하는 데 효과적.
③ 틀림: 탐색적 테스트는 자동화하기 어려움.
④ 틀림: 모든 입력값 조합을 테스트하는 것은 불가능하며, 특정 시나리오에서만 수행 가능.

18. CI/CD 파이프라인 문제

문제 18. 지속적 통합(Continuous Integration, CI)에서 테스트 자동화가 중요한 이유는?

코드 변경 사항이 운영 환경에 즉시 배포되도록 하기 위해서.
개발자 간 코드 충돌을 방지하기 위해서.
코드 변경이 기존 기능에 영향을 주는지 빠르게 검증하기 위해서.
테스트를 수행할 필요 없이 배포할 수 있도록 하기 위해서.

✅ 정답: ③ 코드 변경이 기존 기능에 영향을 주는지 빠르게 검증하기 위해서.

🔍 해설:

① 틀림: CI/CD에서는 운영 배포 이전에 검증 과정을 거치며, CI는 배포보다는 자동 테스트 및 코드 통합에 집중됨.
② 틀림: 코드 충돌 방지는 버전 관리 시스템(Git)이 담당하며, CI의 주요 목적은 아님.
③ 정답: CI에서는 새로운 코드가 기존 기능에 영향을 주지 않는지 확인하기 위해 자동화된 테스트가 필수적.
④ 틀림: CI는 테스트를 자동화하여 문제를 조기에 발견하지만, 테스트를 수행하지 않고 배포하는 것은 위험함.

19. 테스트 환경 문제

문제 19. 운영 환경과 동일한 테스트 환경을 구축하는 가장 큰 이유는?

개발자와 QA가 동일한 환경에서 작업할 수 있도록 하기 위해.
테스트 환경에서 발생한 문제가 운영 환경에서도 동일하게 재현되도록 하기 위해.
테스트 비용을 절감하기 위해.
운영 데이터베이스를 직접 사용할 수 있도록 하기 위해.

✅ 정답: ② 테스트 환경에서 발생한 문제가 운영 환경에서도 동일하게 재현되도록 하기 위해.

🔍 해설:

① 틀림: 개발자와 QA가 동일한 환경을 사용하는 것이 목적은 아니며, 운영 환경과 동일하게 테스트하는 것이 중요함.
② 정답: 운영 환경과 동일한 환경을 구축하면 테스트 시 발견된 결함이 운영에서도 동일하게 발생할 가능성이 높아짐.
③ 틀림: 오히려 테스트 환경을 운영 환경과 유사하게 만들면 비용이 증가할 수 있음.
④ 틀림: 운영 데이터베이스를 직접 사용하는 것은 보안 및 데이터 무결성 문제를 초래할 수 있음.

🔥 온라인 Pretest 대비 핵심 정리 (추가)

✅ SDLC에서 테스트를 가장 빠르게 시작하는 개발 모델은 애자일 모델
✅ 심각도(Severity) vs 우선순위(Priority) 차이 및 사례 분석
✅ REST API 상태 코드 (404 Not Found, 500 Internal Server Error 등) 이해
✅ 탐색적 테스트는 예상치 못한 결함을 발견하는 데 효과적
✅ CI/CD에서 테스트 자동화가 중요한 이유 – 빠른 회귀 테스트 가능
✅ 운영 환경과 동일한 테스트 환경 구축의 이유 – 문제 재현성 확보

20. 화이트박스 테스트 문제

문제 20. 다음 중 화이트박스 테스트 기법에 해당하는 것은?

동치 분할 (Equivalence Partitioning)
문장 커버리지 (Statement Coverage)
경계값 분석 (Boundary Value Analysis)
탐색적 테스트 (Exploratory Testing)

✅ 정답: ② 문장 커버리지 (Statement Coverage)

🔍 해설:

화이트박스 테스트는 코드 내부 로직을 분석하여 테스트하는 기법이야.
①, ③, ④ 틀림: 동치 분할, 경계값 분석, 탐색적 테스트는 블랙박스 테스트 기법에 해당.
② 정답: 문장 커버리지는 코드의 모든 문장이 최소한 한 번은 실행되도록 보장하는 화이트박스 테스트 기법.

21. 애자일 테스트 문제

문제 21. 애자일(Agile) 환경에서 테스트를 수행할 때 가장 중요한 원칙은?

개발이 끝난 후 최종적으로 테스트를 수행한다.
테스트는 개발팀과 QA팀이 완전히 분리된 상태에서 수행해야 한다.
자동화 테스트는 애자일 개발에서는 필요하지 않다.
짧은 개발 주기(Sprint)마다 지속적으로 테스트를 수행한다.

✅ 정답: ④ 짧은 개발 주기(Sprint)마다 지속적으로 테스트를 수행한다.

🔍 해설:

① 틀림: 애자일에서는 개발과 테스트가 동시에 진행됨 (Shift-Left Testing).
② 틀림: 애자일에서는 개발팀과 QA팀이 긴밀하게 협업해야 함.
③ 틀림: 자동화 테스트는 애자일 개발에서 반드시 필요함 (회귀 테스트를 자동화해야 빠른 배포 가능).
④ 정답: 애자일에서는 반복적인 개발 주기(Sprint)마다 지속적으로 테스트를 수행하는 것이 핵심 원칙.

22. 결함 추적 도구 문제

문제 22. 다음 중 소프트웨어 결함을 관리하는 데 가장 적합한 도구는?

Jenkins
Postman
Jira
Selenium

✅ 정답: ③ Jira

🔍 해설:

① 틀림: Jenkins는 CI/CD 자동화 도구.
② 틀림: Postman은 API 테스트 도구.
③ 정답: Jira는 소프트웨어 결함을 추적하고 관리하는 데 널리 사용되는 도구.
④ 틀림: Selenium은 UI 자동화 테스트 도구.

23. 데이터베이스 무결성 문제

문제 23. 데이터베이스의 트랜잭션이 ACID 원칙을 준수해야 하는 이유는?

SQL Injection 공격을 방어하기 위해서
데이터가 손실되지 않고 일관성을 유지하기 위해서
쿼리 실행 속도를 빠르게 하기 위해서
데이터베이스의 크기를 줄이기 위해서

✅ 정답: ② 데이터가 손실되지 않고 일관성을 유지하기 위해서

🔍 해설:

ACID 원칙이란?
1. Atomicity (원자성): 트랜잭션이 완전히 수행되거나 전혀 수행되지 않아야 함.
2. Consistency (일관성): 트랜잭션이 실행된 후에도 데이터베이스의 상태가 유지되어야 함.
3. Isolation (고립성): 트랜잭션이 동시에 실행될 때 서로 간섭하지 않도록 보장.
4. Durability (지속성): 트랜잭션이 완료되면 결과가 영구적으로 저장.
① 틀림: SQL Injection 방지는 별도의 보안 기법이 필요함.
③ 틀림: ACID 원칙은 성능이 아닌 데이터 무결성을 보장하는 역할.
④ 틀림: 데이터베이스 크기와는 관련이 없음.

24. UI 테스트 문제

문제 24. UI 테스트를 자동화하는 가장 적절한 도구는?

JMeter
Selenium
SonarQube
Burp Suite

✅ 정답: ② Selenium

🔍 해설:

① 틀림: JMeter는 성능 테스트 도구.
② 정답: Selenium은 웹 UI 자동화 테스트 도구로, 버튼 클릭, 폼 입력 등을 자동화할 수 있음.
③ 틀림: SonarQube는 정적 코드 분석 도구.
④ 틀림: Burp Suite는 보안 테스트 도구.

25. 보안 테스트 문제

문제 25. OWASP Top 10에서 가장 중요한 보안 취약점 중 하나인 "XSS(Cross-Site Scripting)"의 주요 공격 방법은?

SQL Injection을 이용해 데이터베이스에서 정보를 빼내는 공격
사용자 입력을 검증하지 않고 웹 페이지에 악성 스크립트를 삽입하는 공격
암호화되지 않은 네트워크를 통해 데이터를 탈취하는 공격
관리자의 비밀번호를 무차별 대입(Brute Force)하여 로그인하는 공격

✅ 정답: ② 사용자 입력을 검증하지 않고 웹 페이지에 악성 스크립트를 삽입하는 공격

🔍 해설:

① 틀림: SQL Injection은 데이터베이스 조작 공격.
② 정답: XSS(Cross-Site Scripting)는 사용자가 입력한 데이터를 적절히 필터링하지 않아 악성 스크립트가 실행되는 공격 기법.
③ 틀림: 암호화되지 않은 네트워크에서 데이터를 탈취하는 것은 스니핑 공격.
④ 틀림: 비밀번호를 무차별 대입하는 공격은 Brute Force 공격.

26. 테스트 종료 기준 문제

문제 26. 다음 중 테스트 종료 기준(Exit Criteria)에 해당하지 않는 것은?

테스트 케이스의 100%가 실행되었는가?
주요 결함이 모두 해결되었는가?
프로젝트 일정이 종료되었는가?
테스트 환경이 운영 환경과 동일한가?

✅ 정답: ④ 테스트 환경이 운영 환경과 동일한가?

🔍 해설:

테스트 종료 기준(Exit Criteria) 은 테스트를 완료할 수 있는 조건을 정의하는 것.
① 정답: 모든 테스트 케이스가 실행되었는지 확인해야 함.
② 정답: 주요 결함이 해결되었는지도 테스트 종료 기준 중 하나.
③ 정답: 프로젝트 일정에 맞춰 테스트가 종료되는 경우도 있음.
④ 틀림: 테스트 환경과 운영 환경이 반드시 동일해야 하는 것은 아님.

🔥 Pretest 대비 추가 정리

✅ 화이트박스 테스트 vs 블랙박스 테스트 차이 이해
✅ 애자일 모델에서는 지속적인 테스트가 핵심 원칙
✅ 결함 추적 도구 (Jira 등)의 역할 숙지
✅ 데이터베이스 트랜잭션의 ACID 원칙 이해
✅ UI 테스트 자동화 도구 (Selenium) 이해
✅ 보안 테스트에서 XSS(Cross-Site Scripting) 개념 숙지
✅ 테스트 종료 기준(Exit Criteria) 명확히 이해

27. 정적 테스트 vs 동적 테스트 문제

문제 27. 다음 중 정적 테스트(Static Testing) 기법에 해당하는 것은?

탐색적 테스트 (Exploratory Testing)
코드 리뷰 (Code Review)
성능 테스트 (Performance Testing)
UI 테스트 (UI Testing)

✅ 정답: ② 코드 리뷰 (Code Review)

🔍 해설:

정적 테스트(Static Testing): 코드를 실행하지 않고 결함을 발견하는 테스트 기법.
①, ③, ④ 틀림: 탐색적 테스트, 성능 테스트, UI 테스트는 동적 테스트(Dynamic Testing) 에 속함.
② 정답: 코드 리뷰는 소스 코드를 실행하지 않고 개발자가 검토하는 과정이므로 정적 테스트에 해당.

28. 테스트 케이스와 테스트 시나리오 문제

문제 28. 테스트 시나리오(Test Scenario)와 테스트 케이스(Test Case)의 차이로 적절한 것은?

테스트 케이스는 테스트 시나리오보다 더 포괄적인 개념이다.
테스트 시나리오는 여러 개의 테스트 케이스를 포함할 수 있다.
테스트 시나리오는 테스트 케이스보다 더 구체적이다.
테스트 케이스는 기능 테스트에만 사용되며, 테스트 시나리오는 성능 테스트에 사용된다.

✅ 정답: ② 테스트 시나리오는 여러 개의 테스트 케이스를 포함할 수 있다.

🔍 해설:

테스트 시나리오(Test Scenario): 소프트웨어를 테스트할 전체적인 흐름을 정의하는 포괄적인 개념.
테스트 케이스(Test Case): 테스트 시나리오를 수행하기 위한 구체적인 입력값, 예상 결과, 실행 절차 등을 포함.
① 틀림: 테스트 시나리오가 테스트 케이스보다 더 포괄적인 개념임.
③ 틀림: 테스트 케이스가 더 구체적이며, 시나리오는 전체적인 흐름을 정의함.
④ 틀림: 테스트 케이스는 모든 유형의 테스트에서 사용될 수 있음.

29. 비기능 테스트 vs 기능 테스트 문제

문제 29. 다음 중 비기능 테스트(Non-Functional Testing)에 해당하는 것은?

로그인 기능이 정상적으로 동작하는지 확인하는 테스트
결제 시스템에서 카드 번호 유효성을 검증하는 테스트
시스템이 1,000명의 동시 사용자를 처리할 수 있는지 확인하는 테스트
회원가입 시 필수 입력값을 체크하는 테스트

✅ 정답: ③ 시스템이 1,000명의 동시 사용자를 처리할 수 있는지 확인하는 테스트

🔍 해설:

기능 테스트(Functional Testing): 소프트웨어가 기능 요구사항을 충족하는지 확인하는 테스트.
비기능 테스트(Non-Functional Testing): 성능, 보안, 안정성 등 기능 이외의 요소를 검증하는 테스트.
①, ②, ④ 틀림: 모두 기능 테스트에 해당.
③ 정답: 부하 테스트(Load Testing)의 일종으로, 비기능 테스트에 해당함.

30. 회귀 테스트 vs 재테스트 문제

문제 30. 다음 중 회귀 테스트(Regression Testing)와 재테스트(Retesting)의 차이에 대한 설명으로 적절한 것은?

회귀 테스트는 새로운 기능을 테스트하는 것이고, 재테스트는 기존 기능을 다시 테스트하는 것이다.
회귀 테스트는 변경된 코드가 기존 기능에 영향을 주지 않았는지 확인하는 것이고, 재테스트는 특정 결함이 수정되었는지 확인하는 것이다.
회귀 테스트는 기능 테스트의 일부이며, 재테스트는 성능 테스트의 일부이다.
회귀 테스트와 재테스트는 같은 의미이며, 용어만 다를 뿐이다.

✅ 정답: ② 회귀 테스트는 변경된 코드가 기존 기능에 영향을 주지 않았는지 확인하는 것이고, 재테스트는 특정 결함이 수정되었는지 확인하는 것이다.

🔍 해설:

회귀 테스트(Regression Testing): 코드 변경 후 기존 기능이 정상적으로 동작하는지 확인.
재테스트(Retesting): 특정 결함(Bug)이 수정된 후, 해당 결함이 해결되었는지 확인.
①, ③, ④ 틀림: 회귀 테스트는 기존 기능이 깨지지 않았는지 확인하는 것이고, 재테스트는 특정 버그 수정 여부를 확인하는 것이므로 다름.

31. API GET vs POST 문제

문제 31. 다음 중 HTTP GET과 POST 요청의 차이에 대한 설명으로 올바른 것은?

GET 요청은 데이터를 서버에 저장하고, POST 요청은 데이터를 조회하는 데 사용된다.
GET 요청은 데이터를 URL에 포함하여 보내고, POST 요청은 요청 본문(Body)에 데이터를 포함하여 보낸다.
GET 요청은 보안성이 높고, POST 요청은 보안성이 낮다.
GET 요청은 서버의 데이터를 수정할 수 있지만, POST 요청은 데이터를 조회하는 데 사용된다.

✅ 정답: ② GET 요청은 데이터를 URL에 포함하여 보내고, POST 요청은 요청 본문(Body)에 데이터를 포함하여 보낸다.

🔍 해설:

① 틀림: GET 요청은 데이터를 조회하는 데 사용되고, POST 요청은 데이터를 서버에 저장하는 데 사용됨.
② 정답: GET 요청은 데이터를 URL에 포함하여 전송하고, POST 요청은 Body에 데이터를 담아 전송함.
③ 틀림: GET 요청은 URL에 데이터가 포함되므로 보안성이 낮음. POST 요청은 Body에 데이터를 담기 때문에 상대적으로 보안성이 높음.
④ 틀림: GET 요청은 데이터를 수정하지 않고 조회하는 데 사용되며, POST 요청은 데이터를 서버에 전송하는 데 사용됨.

32. TDD vs BDD 문제

문제 32. TDD(Test-Driven Development)와 BDD(Behavior-Driven Development)의 차이에 대한 설명으로 올바른 것은?

TDD는 코드 구현을 먼저 하고 테스트를 나중에 작성하는 방식이며, BDD는 테스트를 먼저 작성하는 방식이다.
TDD는 코드 레벨에서 테스트를 먼저 작성하는 방식이고, BDD는 사용자 행동(Behavior) 중심으로 테스트를 설계하는 방식이다.
TDD는 기능 테스트를 수행하는 것이고, BDD는 성능 테스트를 수행하는 것이다.
TDD와 BDD는 같은 개념이며, 용어만 다를 뿐이다.

✅ 정답: ② TDD는 코드 레벨에서 테스트를 먼저 작성하는 방식이고, BDD는 사용자 행동(Behavior) 중심으로 테스트를 설계하는 방식이다.

🔍 해설:

① 틀림: TDD는 테스트를 먼저 작성한 후, 해당 테스트를 통과하는 코드를 개발하는 방식.
② 정답: TDD는 코드 단위 테스트(Unit Test) 위주로 진행되며, BDD는 사용자의 행동 기반으로 테스트 시나리오를 작성하는 방식(Gherkin, Cucumber 등 활용).
③ 틀림: BDD는 성능 테스트와 관련이 없음.
④ 틀림: TDD와 BDD는 테스트 접근 방식이 다름.

🔥 Pretest 대비 헷갈리기 쉬운 개념 정리

✅ 정적 테스트 vs 동적 테스트 차이 이해
✅ 테스트 시나리오 vs 테스트 케이스 차이 숙지
✅ 기능 테스트 vs 비기능 테스트 구별
✅ 회귀 테스트 vs 재테스트 차이 이해
✅ GET vs POST 차이 및 보안 이슈 정리
✅ TDD vs BDD 차이 이해 및 활용 사례 숙지

33. 화이트박스 테스트 vs 블랙박스 테스트 문제

문제 33. 다음 중 화이트박스 테스트 기법에 해당하는 것은?

경계값 분석 (Boundary Value Analysis)
동치 분할 (Equivalence Partitioning)
조건 커버리지 (Condition Coverage)
탐색적 테스트 (Exploratory Testing)

✅ 정답: ③ 조건 커버리지 (Condition Coverage)

🔍 해설:

화이트박스 테스트(White-box Testing): 소스 코드 내부 구조를 분석하여 테스트하는 기법.
블랙박스 테스트(Black-box Testing): 내부 코드가 아닌 입력과 출력만을 기준으로 테스트하는 기법.
①, ②, ④ 틀림: 경계값 분석, 동치 분할, 탐색적 테스트는 모두 블랙박스 테스트 기법.
③ 정답: 조건 커버리지는 코드 내 조건문(If, Switch 등)이 참/거짓을 모두 실행하는지 검증하는 화이트박스 테스트 기법.

34. Smoke Test vs Sanity Test 문제

문제 34. Smoke Test와 Sanity Test의 차이에 대한 설명으로 올바른 것은?

Smoke Test는 세부적인 기능 테스트를 수행하고, Sanity Test는 주요 기능만 확인한다.
Smoke Test는 새로운 기능이 추가될 때 수행하고, Sanity Test는 버그 수정 후 수행한다.
Smoke Test는 특정 기능만 테스트하고, Sanity Test는 전체 시스템을 테스트한다.
Smoke Test와 Sanity Test는 같은 의미이며, 용어만 다를 뿐이다.

✅ 정답: ② Smoke Test는 새로운 기능이 추가될 때 수행하고, Sanity Test는 버그 수정 후 수행한다.

🔍 해설:

Smoke Test: 소프트웨어의 빌드(Build)가 정상적으로 이루어졌는지 확인하는 초기 테스트.
Sanity Test: 버그 수정 후 기본적인 기능이 정상적으로 동작하는지 확인하는 테스트.
① 틀림: Smoke Test는 주요 기능을 빠르게 검증하는 것이 목적이며, 세부적인 기능 테스트는 아님.
③ 틀림: Smoke Test는 전체적인 동작을 확인하고, Sanity Test는 특정 기능에 집중함.
④ 틀림: 둘은 목적이 다름!

35. 테스트 데이터 유형 문제

문제 35. 다음 중 테스트 데이터 유형 중 "실제 운영 데이터를 기반으로 익명화하여 사용하는 데이터"는?

샘플 데이터 (Sample Data)
모의 데이터 (Synthetic Data)
익명화된 데이터 (Anonymized Data)
더미 데이터 (Dummy Data)

✅ 정답: ③ 익명화된 데이터 (Anonymized Data)

🔍 해설:

① 샘플 데이터: 운영 데이터에서 일부만 추출하여 사용한 데이터.
② 모의 데이터: 운영 데이터와 비슷하게 인위적으로 생성된 데이터.
③ 정답: 익명화된 데이터는 운영 데이터를 기반으로 개인정보를 제거하여 테스트용으로 변환한 데이터.
④ 더미 데이터: 의미 없는 값(예: XXX, 1234 등)으로 채운 가짜 데이터.

36. RESTful API와 SOAP API 문제

문제 36. RESTful API와 SOAP API의 차이에 대한 설명으로 올바른 것은?

RESTful API는 상태 정보를 유지하고, SOAP API는 상태 정보를 유지하지 않는다.
RESTful API는 XML만 지원하고, SOAP API는 JSON과 XML을 모두 지원한다.
RESTful API는 경량(Lightweight)하며, SOAP API는 보안성이 높지만 무겁다.
RESTful API는 트랜잭션을 지원하지만, SOAP API는 트랜잭션을 지원하지 않는다.

✅ 정답: ③ RESTful API는 경량(Lightweight)하며, SOAP API는 보안성이 높지만 무겁다.

🔍 해설:

① 틀림: RESTful API는 상태 정보를 유지하지 않음(Stateless), SOAP API는 일부 상태 정보를 유지할 수 있음.
② 틀림: RESTful API는 JSON, XML 등 다양한 포맷을 지원하지만, SOAP API는 XML만 지원.
③ 정답: RESTful API는 가볍고 빠르며(경량), SOAP API는 보안 기능이 많지만 상대적으로 무거움.
④ 틀림: SOAP API는 트랜잭션을 지원하며, RESTful API는 기본적으로 트랜잭션을 고려하지 않음.

37. DevOps와 QA의 역할 문제

문제 37. DevOps 환경에서 QA가 수행해야 하는 역할로 적절하지 않은 것은?

CI/CD 파이프라인에서 자동화 테스트를 수행하는 것.
테스트 결과를 기반으로 빠른 피드백을 제공하는 것.
운영 환경에서 직접 실시간 버그를 수정하는 것.
코드 변경 사항이 기존 기능에 영향을 주지 않는지 검증하는 것.

✅ 정답: ③ 운영 환경에서 직접 실시간 버그를 수정하는 것.

🔍 해설:

DevOps 환경에서 QA의 역할:
- 자동화 테스트 수행 및 유지보수 (CI/CD)
- 빠른 피드백 제공
- 코드 변경의 영향 분석 및 품질 검증
③ 틀림: 운영 환경에서 버그를 직접 수정하는 것은 개발자의 역할이며, QA는 문제를 발견하고 보고하는 역할.

38. 클라우드 기반 테스트 문제

문제 38. 클라우드 환경에서 테스트를 수행할 때 장점으로 적절하지 않은 것은?

테스트 환경을 빠르게 확장할 수 있다.
비용을 절감할 수 있다.
물리적인 테스트 장비가 필요하지 않다.
보안성이 온프레미스(On-Premise) 환경보다 항상 높다.

✅ 정답: ④ 보안성이 온프레미스(On-Premise) 환경보다 항상 높다.

🔍 해설:

클라우드 테스트의 장점:
- 환경 확장 가능 (Scalability)
- 비용 절감 (Pay-as-you-go 모델)
- 물리적 장비 없이 테스트 가능
④ 틀림: 클라우드 환경의 보안성은 설정과 운영 방식에 따라 달라지며, 온프레미스 환경보다 반드시 높다고 할 수 없음.

🔥 Pretest 대비 헷갈리기 쉬운 개념 정리 (추가)

✅ 화이트박스 vs 블랙박스 테스트 개념 정리
✅ Smoke Test vs Sanity Test 차이 숙지
✅ 테스트 데이터 유형(익명화 데이터, 더미 데이터 등) 이해
✅ RESTful API vs SOAP API 차이점 정리
✅ DevOps 환경에서 QA의 역할 명확히 구분
✅ 클라우드 기반 테스트의 장점과 보안성 문제 이해

✅ 39. 정적 분석 vs 동적 분석 문제

문제 39. 다음 중 정적 분석(Static Analysis)과 동적 분석(Dynamic Analysis)에 대한 설명으로 올바른 것은?

정적 분석은 프로그램을 실행하지 않고 소스 코드를 검사하는 방식이다.
동적 분석은 소스 코드 검토를 통해 결함을 찾는 방식이다.
정적 분석은 실행 중 발생하는 성능 문제를 감지하는 데 사용된다.
동적 분석은 테스트 환경을 설정하지 않고 소스 코드만으로 보안 취약점을 분석하는 기법이다.

✅ 정답: ① 정적 분석은 프로그램을 실행하지 않고 소스 코드를 검사하는 방식이다.

🔍 해설:

정적 분석 (Static Analysis): 프로그램을 실행하지 않고 소스 코드 수준에서 결함을 분석하는 기법.
- 예: 코드 리뷰, 정적 분석 도구(SonarQube, ESLint).
동적 분석 (Dynamic Analysis): 프로그램을 실행한 상태에서 결함을 분석하는 기법.
- 예: 성능 테스트, 메모리 누수 분석.
②, ④ 틀림: 동적 분석은 실제 프로그램을 실행해야 가능.
③ 틀림: 성능 문제 분석은 동적 분석에서 수행.

✅ 40. 애자일 테스트 문제

문제 40. 애자일 환경에서 QA가 수행해야 하는 역할로 적절하지 않은 것은?

개발자가 코드를 수정하면 빠르게 회귀 테스트를 실행한다.
테스트 케이스를 미리 작성하지 않고, 개발이 완료된 후 테스트를 수행한다.
CI/CD 환경에서 자동화된 테스트를 수행한다.
개발 팀과 긴밀히 협력하여 품질을 보장한다.

✅ 정답: ② 테스트 케이스를 미리 작성하지 않고, 개발이 완료된 후 테스트를 수행한다.

🔍 해설:

애자일 테스트의 핵심 원칙:
- Shift-Left Testing: 개발 초기부터 테스트 수행.
- TDD (Test-Driven Development): 테스트 케이스를 먼저 작성 후 코드 구현.
- CI/CD 테스트 자동화: 지속적인 배포 환경에서 자동 테스트 실행.
② 틀림: 애자일에서는 개발과 테스트가 병행되므로, 테스트 케이스를 미리 작성하는 것이 중요.

✅ 41. 정규 표현식(Regex) 문제

문제 41. 다음 정규 표현식 ^\d{3}-\d{2}-\d{4}$이 의미하는 것은?

이메일 주소 형식을 검증한다.
전화번호 형식을 검증한다.
소셜 시큐리티 넘버(SSN) 형식을 검증한다.
IPv4 주소 형식을 검증한다.

✅ 정답: ③ 소셜 시큐리티 넘버(SSN) 형식을 검증한다.

🔍 해설:

정규 표현식(Regex) 분석:
- ^ → 문자열 시작.
- \d{3} → 숫자 3자리.
- - → 하이픈(-).
- \d{2} → 숫자 2자리.
- - → 하이픈(-).
- \d{4} → 숫자 4자리.
- $ → 문자열 종료.
①, ②, ④ 틀림: 이메일, 전화번호, IP 주소 형식과 일치하지 않음.

✅ 42. SQL Injection 취약점 문제

문제 42. 다음 중 SQL Injection을 방지하기 위한 올바른 방법은?

사용자 입력을 직접 SQL 쿼리에 포함한다.
Prepared Statements(프리페어드 스테이트먼트)를 사용한다.
SQL 쿼리를 실행하기 전에 사용자 입력을 모두 대문자로 변환한다.
SQL 쿼리를 실행하기 전에 모든 공백을 제거한다.

✅ 정답: ② Prepared Statements(프리페어드 스테이트먼트)를 사용한다.

🔍 해설:

SQL Injection 방지 방법:
- Prepared Statements 사용 → SQL 실행 시 입력값을 안전하게 처리.
- 입력값 검증 및 필터링 → 특정 문자 (', ", --) 제거.
- 최소 권한 원칙 적용 → 데이터베이스 계정에 최소 권한만 부여.
①, ③, ④ 틀림: 보안 취약점을 해결하지 못함.

✅ 43. CI/CD에서 QA의 역할 문제

문제 43. CI/CD 파이프라인에서 QA가 수행해야 하는 역할로 적절하지 않은 것은?

코드가 변경될 때마다 자동화된 테스트를 실행한다.
코드 배포 후 운영 환경에서 직접 수동 테스트를 수행한다.
테스트 실패 시 개발 팀에 피드백을 제공한다.
성능 테스트를 CI/CD 파이프라인에 통합할 수 있다.

✅ 정답: ② 코드 배포 후 운영 환경에서 직접 수동 테스트를 수행한다.

🔍 해설:

CI/CD에서 QA의 주요 역할:
- 자동화 테스트 수행.
- 테스트 실패 시 빠른 피드백 제공.
- 성능 테스트, 보안 테스트 자동화.
② 틀림: 운영 환경에서 직접 수동 테스트를 수행하는 것은 일반적인 CI/CD QA 업무가 아님.

✅ 44. 보안 테스트 문제

문제 44. OWASP Top 10에서 가장 위험한 취약점 중 하나인 "CSRF(Cross-Site Request Forgery)" 공격을 방지하는 방법으로 가장 적절한 것은?

비밀번호를 복잡하게 설정한다.
HTTP 요청에 CSRF 토큰을 포함한다.
HTTPS 프로토콜을 사용한다.
SQL Injection을 방지하기 위해 Prepared Statements를 사용한다.

✅ 정답: ② HTTP 요청에 CSRF 토큰을 포함한다.

🔍 해설:

CSRF 공격:
- 사용자가 인증된 세션에서 악성 요청이 실행되도록 유도하는 공격.
방지 방법:
- CSRF 토큰 사용 → 요청마다 고유한 토큰을 포함하여 검증.
- SameSite 쿠키 정책 설정 → 다른 사이트에서 인증된 요청을 차단.
- Referrer 검증 → 요청 출처 확인.

✅ 추가 심화 개념 정리

📌 시험에서 자주 출제되는 헷갈리는 개념들

✅ 정적 분석(Static Analysis) vs 동적 분석(Dynamic Analysis) 차이
✅ CI/CD에서 QA 역할 & 자동화 테스트 필요성
✅ SQL Injection, CSRF 등 보안 취약점 및 방지 방법
✅ 애자일 환경에서 테스트 자동화의 중요성
✅ RESTful API & 정규 표현식(Regex) 실무 활용법

✅ 45. 테스트 커버리지 문제

문제 45. 다음 중 테스트 커버리지(Test Coverage)를 측정하는 주요 기준이 아닌 것은?

문장 커버리지 (Statement Coverage)
분기 커버리지 (Branch Coverage)
상태 커버리지 (State Coverage)
UI 디자인 커버리지 (UI Design Coverage)

✅ 정답: ④ UI 디자인 커버리지 (UI Design Coverage)

🔍 해설:

테스트 커버리지(Test Coverage): 코드의 어느 부분이 테스트되었는지 측정하는 지표.
주요 테스트 커버리지 유형:
1. 문장 커버리지 (Statement Coverage): 코드의 모든 문장이 실행되었는지 확인.
2. 분기 커버리지 (Branch Coverage): if 또는 switch 문에서 모든 분기 조건이 실행되었는지 확인.
3. 조건 커버리지 (Condition Coverage): 논리 조건이 true와 false를 모두 실행했는지 확인.
4. MC/DC (Modified Condition/Decision Coverage): 모든 개별 조건이 독립적으로 결과에 영향을 주는지 확인.
5. 경로 커버리지 (Path Coverage): 코드의 모든 실행 경로를 테스트.
④ 틀림: UI 디자인 커버리지는 코드 테스트 커버리지와 관련이 없음.

✅ 46. 로드 테스트 vs 스트레스 테스트 문제

문제 46. 다음 중 로드 테스트(Load Testing)와 스트레스 테스트(Stress Testing)의 차이에 대한 설명으로 올바른 것은?

로드 테스트는 최대 부하 상태에서 시스템이 어떻게 반응하는지 확인하는 것이고, 스트레스 테스트는 정상적인 트래픽을 처리하는 성능을 확인하는 것이다.
로드 테스트는 사용량이 증가하는 상황에서의 성능을 평가하는 것이고, 스트레스 테스트는 시스템이 한계치를 초과할 때 얼마나 잘 버티는지를 평가하는 것이다.
로드 테스트는 특정 기능의 동작을 테스트하는 것이고, 스트레스 테스트는 전체 시스템의 기능을 테스트하는 것이다.
로드 테스트와 스트레스 테스트는 동일한 개념이며, 용어만 다를 뿐이다.

✅ 정답: ② 로드 테스트는 사용량이 증가하는 상황에서의 성능을 평가하는 것이고, 스트레스 테스트는 시스템이 한계치를 초과할 때 얼마나 잘 버티는지를 평가하는 것이다.

🔍 해설:

로드 테스트 (Load Testing): 정상적인 트래픽 증가 상황에서 시스템 성능을 평가.
- 예: 웹사이트가 1,000명의 동시 접속자를 처리할 수 있는지 테스트.
스트레스 테스트 (Stress Testing): 시스템이 한계점을 초과했을 때 어디까지 버틸 수 있는지 테스트.
- 예: 10만 명의 동시 접속자가 발생했을 때 서버가 다운되는지 확인.
① 틀림: 로드 테스트는 정상적인 증가를, 스트레스 테스트는 한계를 초과한 상황을 테스트.
③ 틀림: 둘 다 특정 기능이 아니라 시스템 전체의 성능을 평가함.
④ 틀림: 개념이 다름! 스트레스 테스트는 시스템이 다운될 때 어떻게 복구하는지도 평가함.

✅ 47. 탐색적 테스트 전략 문제

문제 47. 탐색적 테스트(Exploratory Testing)를 효과적으로 수행하는 방법으로 가장 적절한 것은?

사전에 모든 테스트 케이스를 문서화한 후 실행한다.
예상된 결과만 확인하며 테스트를 수행한다.
테스터의 경험과 직관을 기반으로, 예상치 못한 결함을 찾는 데 집중한다.
오직 기능 테스트에만 사용되며, 보안 테스트에는 적용할 수 없다.

✅ 정답: ③ 테스터의 경험과 직관을 기반으로, 예상치 못한 결함을 찾는 데 집중한다.

🔍 해설:

탐색적 테스트(Exploratory Testing):
- 정형화된 테스트 케이스 없이, 테스터의 경험과 직관을 활용하여 결함을 찾는 기법.
- UI 테스트, 보안 테스트, 성능 테스트에서도 활용 가능.
① 틀림: 탐색적 테스트는 사전 테스트 케이스 없이 진행됨.
② 틀림: 예상된 결과뿐만 아니라 예상치 못한 동작도 확인해야 함.
④ 틀림: 보안 테스트에서도 효과적으로 사용될 수 있음.

✅ 48. 모바일 테스트 문제

문제 48. 모바일 애플리케이션 테스트를 수행할 때 고려해야 할 사항으로 적절하지 않은 것은?

다양한 운영 체제(iOS, Android)와 디바이스에서 테스트해야 한다.
배터리 사용량 및 네트워크 연결 상태에 따른 성능을 검토해야 한다.
웹 애플리케이션과 동일한 방식으로만 테스트하면 된다.
앱이 백그라운드에서 실행될 때의 동작을 확인해야 한다.

✅ 정답: ③ 웹 애플리케이션과 동일한 방식으로만 테스트하면 된다.

🔍 해설:

모바일 테스트 주요 고려사항:
- 다양한 디바이스 및 OS 테스트: 해상도, CPU 성능 차이 확인.
- 배터리 및 네트워크 영향 테스트: Wi-Fi vs LTE 환경에서 성능 차이 분석.
- 앱의 백그라운드 동작 테스트: 전화 수신, 푸시 알림 수신 시 앱의 반응 확인.
③ 틀림: 모바일 테스트는 웹 애플리케이션과 다르게 디바이스 특성(센서, GPS, 네트워크 속도 등)도 고려해야 함.

✅ 49. A/B 테스트 문제

문제 49. A/B 테스트(A/B Testing)의 주요 목적은?

웹사이트의 모든 기능이 정상적으로 동작하는지 확인하는 것.
두 가지 이상의 UI/UX 디자인 중 어떤 것이 더 효과적인지 데이터 기반으로 결정하는 것.
모든 기능을 자동화 테스트하는 것.
소프트웨어 코드의 품질을 정적 분석하는 것.

✅ 정답: ② 두 가지 이상의 UI/UX 디자인 중 어떤 것이 더 효과적인지 데이터 기반으로 결정하는 것.

🔍 해설:

A/B 테스트(A/B Testing):
- 두 개 이상의 UI/UX 디자인을 테스트하여 사용자 반응 데이터를 기반으로 최적의 디자인을 결정하는 방법.
- 예: 빨간색 버튼 vs 파란색 버튼 중 어떤 것이 클릭률(CTR)이 높은지 분석.
①, ③, ④ 틀림: 기능 테스트, 자동화 테스트, 정적 분석과 관련 없음.

✅ 추가 정리 & 마무리

📌 시험에서 자주 출제되는 헷갈리는 개념들 (심화)

✅ 테스트 커버리지 (Statement, Branch, MC/DC 등) 깊이 이해
✅ 로드 테스트 vs 스트레스 테스트 차이 명확히 구분
✅ 탐색적 테스트가 필요한 이유 & 효과적인 수행 방법 이해
✅ 모바일 테스트 고려사항 (배터리, 네트워크, 백그라운드 동작 등)
✅ A/B 테스트가 어떻게 UX/UI 최적화에 활용되는지 이해

✅ 50. 모바일 앱 테스트 전략 문제

문제 50. 모바일 애플리케이션을 테스트할 때 고려해야 할 가장 중요한 요소는?

다양한 네트워크 환경(Wi-Fi, 4G, 5G)에서의 동작
웹 애플리케이션과 동일한 방식으로만 테스트
데스크톱 환경에서 실행되는지 여부
브라우저의 렌더링 속도

✅ 정답: ① 다양한 네트워크 환경(Wi-Fi, 4G, 5G)에서의 동작

🔍 해설:

모바일 앱 테스트는 웹 앱과 다름!
1. 다양한 네트워크 환경(Wi-Fi, 4G, 5G, 오프라인)에서 앱이 정상 동작하는지 확인해야 함.
2. 다양한 화면 크기와 해상도에 대한 반응형 디자인 테스트 필요.
3. 배터리 소모, CPU 사용량, 백그라운드 실행 여부도 테스트 대상.
②, ③, ④ 틀림: 웹 테스트와 모바일 테스트는 다르며, 모바일 앱은 브라우저 렌더링보다는 네트워크, 디바이스 리소스 사용량, 터치 인터페이스 테스트가 더 중요.

✅ 51. 안드로이드 앱 UI 테스트 문제

문제 51. 안드로이드 애플리케이션의 UI를 자동으로 테스트하는 도구로 가장 적절한 것은?

Espresso
JUnit
Postman
Burp Suite

✅ 정답: ① Espresso

🔍 해설:

Espresso: 안드로이드 앱의 UI 테스트를 자동화하는 공식 프레임워크.
- 화면 이동, 버튼 클릭, 텍스트 입력 등의 UI 동작을 자동으로 실행하여 테스트.
② 틀림: JUnit은 유닛 테스트(Unit Test)용으로 UI 테스트에는 적합하지 않음.
③ 틀림: Postman은 API 테스트 도구.
④ 틀림: Burp Suite는 보안 테스트 도구.

✅ 52. 모바일 앱 네트워크 테스트 문제

문제 52. 안드로이드 앱이 오프라인 상태에서 정상적으로 동작하는지 테스트하려면 어떤 방법을 사용해야 하는가?

모든 테스트를 Wi-Fi 환경에서만 실행한다.
앱이 네트워크에 연결되지 않은 상태에서 기능이 정상적으로 동작하는지 확인한다.
API 요청을 수동으로 조작하여 네트워크 응답을 변형한다.
모바일 데이터가 항상 켜져 있는 상태에서만 테스트한다.

✅ 정답: ② 앱이 네트워크에 연결되지 않은 상태에서 기능이 정상적으로 동작하는지 확인한다.

🔍 해설:

오프라인 모드 테스트:
- 앱이 네트워크 없이 실행될 때 캐시 데이터를 유지하고 오류 없이 동작하는지 확인.
- 비행기 모드에서 앱을 실행하여 테스트 가능.
- 네트워크 연결이 다시 활성화될 때 데이터가 정상적으로 동기화되는지 확인 필요.
①, ④ 틀림: Wi-Fi 환경 또는 모바일 데이터만으로 테스트하면 오프라인 동작을 확인할 수 없음.
③ 틀림: API 요청을 변형하는 것은 네트워크 보안 테스트에는 유용하지만, 오프라인 테스트 방법은 아님.

✅ 53. 모바일 앱 성능 테스트 문제

문제 53. 안드로이드 앱의 성능 테스트에서 가장 중요하게 고려해야 할 요소는?

배터리 사용량, CPU 및 메모리 사용률
웹 브라우저의 페이지 로딩 속도
앱 설치 후 APK 파일의 크기만 확인
앱 내 광고의 노출 빈도

✅ 정답: ① 배터리 사용량, CPU 및 메모리 사용률

🔍 해설:

모바일 앱 성능 테스트 주요 요소:
1. 배터리 소모량: 특정 기능 사용 시 배터리 소비량이 급격히 증가하는지 확인.
2. CPU 및 메모리 사용량: 앱 실행 중 CPU와 RAM을 과도하게 사용하는지 분석.
3. 앱 시작 시간: 첫 실행 시 로딩 시간이 너무 긴 경우 최적화 필요.
4. 스크롤 성능: 리스트 뷰, 이미지 로딩이 원활한지 체크.
②, ③, ④ 틀림: 성능 테스트는 단순한 로딩 속도나 APK 파일 크기가 아닌, 실제 기기에서의 자원 사용량과 실행 속도를 측정하는 것이 핵심.

✅ 54. 모바일 앱 보안 테스트 문제

문제 54. 안드로이드 앱의 보안을 강화하기 위해 반드시 고려해야 할 사항은?

앱의 소스 코드를 난독화하여 리버스 엔지니어링을 방지한다.
모든 사용자 데이터를 로컬에 평문으로 저장한다.
네트워크 트래픽을 HTTP 프로토콜로 전송한다.
앱이 루팅된 디바이스에서도 정상적으로 동작하도록 한다.

✅ 정답: ① 앱의 소스 코드를 난독화하여 리버스 엔지니어링을 방지한다.

🔍 해설:

안드로이드 앱 보안 강화 방법:
- ProGuard, R8을 사용하여 소스 코드 난독화.
- HTTPS를 사용하여 데이터 암호화 및 전송 보안 강화.
- 앱이 루팅된 기기에서 동작하지 않도록 보안 정책 적용.
②, ③, ④ 틀림:
- 데이터를 평문(Plain Text)으로 저장하면 보안 취약점 발생 가능.
- HTTP 대신 반드시 HTTPS를 사용해야 함.
- 루팅된 기기에서는 해킹 가능성이 높으므로 앱 실행을 제한하는 것이 바람직함.

✅ 55. 안드로이드 앱 테스트 자동화 문제

문제 55. 안드로이드 UI 테스트 자동화 시 가장 많이 사용되는 프레임워크는?

Selenium
Espresso
JMeter
OWASP ZAP

✅ 정답: ② Espresso

🔍 해설:

Espresso:
- 안드로이드 UI 테스트 자동화를 위한 공식 프레임워크.
- 사용자가 직접 앱을 사용하는 것처럼 UI 동작을 자동으로 실행하고 검증.
① 틀림: Selenium은 웹 UI 테스트 자동화 도구로, 안드로이드 네이티브 앱 테스트에는 적합하지 않음.
③ 틀림: JMeter는 성능 테스트 도구로, UI 테스트와 무관.
④ 틀림: OWASP ZAP은 보안 테스트 도구.

✅ 모바일 앱 테스트 심화 개념 정리

📌 모바일 안드로이드 앱 테스트의 핵심 요소

✅ 다양한 네트워크 환경(Wi-Fi, 4G, 5G, 오프라인)에서 앱이 정상적으로 동작하는지 확인
✅ Espresso를 활용한 UI 테스트 자동화 적용
✅ 앱의 배터리 사용량, CPU/메모리 소비율을 성능 테스트에서 측정
✅ HTTPS 적용 및 난독화를 통해 앱 보안을 강화
✅ 루팅된 기기에서의 동작 여부 확인 및 보안 조치 적용

✅ 56. 모바일 앱 크로스 디바이스 테스트 문제

문제 56. 모바일 애플리케이션 테스트 시 다양한 디바이스에서 테스트하는 주요 목적은?

앱이 특정 기기에서만 정상적으로 동작하는지 확인하기 위해
다양한 화면 크기와 해상도에서 UI가 올바르게 표시되는지 확인하기 위해
앱의 코드 품질을 높이기 위해
애플리케이션의 보안 취약점을 확인하기 위해

✅ 정답: ② 다양한 화면 크기와 해상도에서 UI가 올바르게 표시되는지 확인하기 위해

🔍 해설:

크로스 디바이스 테스트(Cross Device Testing):
- 안드로이드 앱은 다양한 기기(스마트폰, 태블릿)에서 실행될 수 있기 때문에, 각 기기에서 UI가 깨지거나 기능이 정상적으로 작동하지 않는 문제가 발생할 가능성이 높음.
- 다양한 해상도, 화면 비율, 성능 차이를 고려하여 테스트해야 함.
①, ③, ④ 틀림:
- 특정 기기에서만 정상적으로 동작하는지 확인하는 것이 아니라, 모든 기기에서 일관된 동작을 보장하는 것이 목표.
- 코드 품질 향상은 코드 리뷰, 정적 분석 등을 통해 수행하는 것이며, 보안 취약점 확인은 보안 테스트에서 다룸.

✅ 57. 모바일 네트워크 테스트 문제

문제 57. 모바일 앱이 불안정한 네트워크 환경에서도 정상적으로 동작하는지 확인하기 위한 가장 적절한 방법은?

앱을 Wi-Fi 환경에서만 테스트한다.
네트워크 연결을 끊었다가 다시 연결하는 테스트를 수행한다.
클라우드 서버의 응답 시간을 수동으로 설정하여 테스트한다.
모든 API 요청이 성공적으로 수행되는지만 확인한다.

✅ 정답: ② 네트워크 연결을 끊었다가 다시 연결하는 테스트를 수행한다.

🔍 해설:

네트워크 상태 변화 테스트:
- Wi-Fi → LTE → 5G 변경 시 앱이 정상 동작하는지 확인.
- 네트워크 끊김(오프라인 상태) 후 재연결 시 데이터 동기화가 올바르게 이루어지는지 검증.
- 실제 이동 중(터널, 엘리베이터)에서 네트워크가 단절되었을 때의 동작 확인.
①, ③, ④ 틀림:
- Wi-Fi 환경에서만 테스트하면 실사용 환경을 반영할 수 없음.
- 클라우드 응답 시간 설정도 중요하지만, 실제 네트워크 환경에서의 변화가 더 중요한 테스트 포인트.

✅ 58. 모바일 접근성 테스트 문제

문제 58. 모바일 앱 접근성(Accessibility)을 테스트할 때 가장 중요한 요소는?

색맹 모드에서 UI가 올바르게 표시되는지 확인하는 것
앱의 성능이 빠른지 측정하는 것
앱의 UI가 고해상도에서 선명하게 보이는지 확인하는 것
앱이 최신 안드로이드 버전에서만 동작하는지 확인하는 것

✅ 정답: ① 색맹 모드에서 UI가 올바르게 표시되는지 확인하는 것

🔍 해설:

모바일 접근성 테스트(Accessibility Testing):
- 시각 장애인을 위한 "음성 피드백(TalkBack)" 기능이 정상 동작하는지 확인.
- 색맹 모드(색상 대비 확인)에서 UI 요소가 구분 가능해야 함.
- 텍스트 크기 조정 시 레이아웃이 깨지지 않는지 테스트.
②, ③, ④ 틀림:
- 접근성 테스트는 성능, 고해상도 테스트가 아니라 장애가 있는 사용자도 원활하게 앱을 사용할 수 있도록 검증하는 것이 핵심.

✅ 59. 모바일 보안 테스트 문제

문제 59. 모바일 앱의 데이터 보안을 강화하기 위해 반드시 고려해야 할 사항은?

모든 데이터를 로컬 파일에 저장한다.
사용자 로그인 정보를 로컬 DB에 암호화 없이 저장한다.
앱이 HTTPS 프로토콜을 사용하여 데이터를 암호화하여 전송하는지 확인한다.
사용자 비밀번호를 앱 내 하드코딩하여 보관한다.

✅ 정답: ③ 앱이 HTTPS 프로토콜을 사용하여 데이터를 암호화하여 전송하는지 확인한다.

🔍 해설:

모바일 보안 테스트의 핵심:
- HTTPS(SSL/TLS) 적용: 네트워크 트래픽을 암호화하여 데이터 탈취 방지.
- 민감한 정보(비밀번호, 카드 정보)를 암호화하여 저장.
- Secure SharedPreferences 또는 Android Keystore System 사용.
①, ②, ④ 틀림:
- 로컬 파일에 저장된 데이터는 보안 취약점이 많음.
- 비밀번호를 암호화 없이 저장하면 해킹 위험이 있음.
- 앱 내 하드코딩된 비밀번호는 리버스 엔지니어링으로 쉽게 유출됨.

✅ 60. 모바일 앱 테스트 자동화 문제

문제 60. 모바일 UI 테스트 자동화를 위해 가장 적절한 방법은?

Espresso와 UI Automator를 사용하여 UI 동작을 자동화한다.
수동 테스트만 수행하고 자동화는 필요하지 않다.
네트워크 로그만 분석하여 UI 동작을 검증한다.
Selenium을 사용하여 안드로이드 앱을 자동화한다.

✅ 정답: ① Espresso와 UI Automator를 사용하여 UI 동작을 자동화한다.

🔍 해설:

모바일 UI 테스트 자동화 방법:
- Espresso: 단일 앱 내 UI 테스트 자동화 (Google 공식 지원).
- UI Automator: 여러 앱 간 UI 테스트 가능 (예: 설정 앱과 상호작용).
② 틀림: 수동 테스트도 중요하지만, 자동화 테스트를 활용하면 반복적인 UI 테스트를 효율적으로 수행 가능.
③ 틀림: 네트워크 로그만 분석해서는 UI 동작을 검증할 수 없음.
④ 틀림: Selenium은 웹 UI 자동화 도구로, 네이티브 모바일 앱 테스트에는 적합하지 않음.

✅ 모바일 안드로이드 앱 테스트 심화 개념 정리

📌 모바일 앱 테스트의 주요 고려사항

✅ 다양한 기기와 해상도에서의 UI 테스트(Cross Device Testing)
✅ Wi-Fi, 4G, 5G, 네트워크 끊김 후 재연결 테스트(Network Resilience Testing)
✅ 배터리 사용량, CPU/메모리 소비 분석을 통한 성능 테스트(Performance Testing)
✅ Espresso, UI Automator를 활용한 UI 테스트 자동화(UI Test Automation)
✅ TalkBack, 색상 대비 검토를 포함한 접근성 테스트(Accessibility Testing)
✅ HTTPS 적용 및 민감 데이터 암호화를 통한 보안 테스트(Security Testing)

✅ 61. API 테스트와 계약 테스트 문제

문제 61. API 테스트에서 "계약 테스트(Contract Testing)"의 주요 목적은?

API의 요청과 응답이 예상된 스펙을 준수하는지 확인하는 것
데이터베이스 트랜잭션이 올바르게 수행되는지 확인하는 것
API가 스트레스 테스트에서 높은 트래픽을 견딜 수 있는지 확인하는 것
API의 보안 취약점을 분석하는 것

✅ 정답: ① API의 요청과 응답이 예상된 스펙을 준수하는지 확인하는 것

🔍 해설:

계약 테스트(Contract Testing):
- API의 요청(Request)과 응답(Response)이 문서화된 스펙(OpenAPI, Swagger) 과 일치하는지 검증하는 테스트.
- 마이크로서비스 환경에서 서비스 간 API 변경이 기존 서비스에 영향을 주지 않는지 확인하는 데 필수적.
- 예: API 응답의 JSON 필드 구조가 변경되었을 때, 클라이언트가 이를 정상적으로 처리할 수 있는지 검증.
②, ③, ④ 틀림:
- 데이터베이스 트랜잭션 테스트는 DB 테스트 영역,
- 스트레스 테스트는 성능 테스트 영역,
- 보안 테스트는 API 보안 영역에서 다루어야 함.

✅ 62. 성능 테스트에서 TPS와 응답 시간 문제

문제 62. 성능 테스트에서 TPS(Transactions Per Second)와 응답 시간(Response Time)의 관계에 대한 설명으로 올바른 것은?

TPS가 증가하면 응답 시간도 항상 증가한다.
TPS가 증가해도 응답 시간은 영향을 받지 않는다.
TPS가 지나치게 증가하면 응답 시간이 증가할 수 있다.
응답 시간은 TPS와 관계없이 항상 일정하다.

✅ 정답: ③ TPS가 지나치게 증가하면 응답 시간이 증가할 수 있다.

🔍 해설:

TPS (Transactions Per Second): 시스템이 1초 동안 처리할 수 있는 트랜잭션 수.
응답 시간 (Response Time): 사용자의 요청이 서버에서 처리되어 응답이 반환될 때까지 걸리는 시간.
③ 정답:
- TPS가 증가하면 서버의 부하가 커지고, 특정 임계점을 넘으면 응답 시간이 증가할 수 있음.
- 예: TPS 1,000일 때 응답 시간이 100ms였다가, TPS 5,000이 되면 응답 시간이 500ms까지 증가할 수 있음.
①, ②, ④ 틀림:
- TPS와 응답 시간은 항상 동일한 비율로 변하지 않으며, 시스템의 부하와 인프라 성능에 따라 다름.

✅ 63. 정적 테스트 vs 동적 테스트 문제

문제 63. 다음 중 정적 테스트(Static Testing) 기법에 해당하는 것은?

정적 코드 분석 (Static Code Analysis)
로드 테스트 (Load Testing)
UI 자동화 테스트 (UI Automation Testing)
보안 취약점 탐지 테스트 (Penetration Testing)

✅ 정답: ① 정적 코드 분석 (Static Code Analysis)

🔍 해설:

정적 테스트 (Static Testing): 코드를 실행하지 않고 결함을 찾는 기법.
- 예: 코드 리뷰(Code Review), 정적 코드 분석(SonarQube, ESLint), 요구사항 리뷰.
동적 테스트 (Dynamic Testing): 실제 소프트웨어를 실행하면서 결함을 찾는 기법.
- 예: 로드 테스트, UI 자동화 테스트, 보안 취약점 탐지 테스트.
②, ③, ④ 틀림:
- 로드 테스트, UI 자동화 테스트, 보안 테스트는 동적 테스트에 속함.

✅ 64. 데이터베이스 테스트 문제

문제 64. 데이터베이스 테스트에서 "데이터 무결성(Integrity)"을 검증하는 가장 중요한 방법은?

모든 데이터를 로컬 파일로 백업한다.
ACID 원칙을 적용하여 트랜잭션이 올바르게 수행되는지 검증한다.
SQL Injection 공격이 가능한지 테스트한다.
데이터베이스가 여러 개의 서버에서 동일한 데이터 상태를 유지하는지 확인한다.

✅ 정답: ② ACID 원칙을 적용하여 트랜잭션이 올바르게 수행되는지 검증한다.

🔍 해설:

데이터 무결성(Integrity) 보장을 위한 핵심 요소:
- ACID 원칙:
  - Atomicity(원자성): 트랜잭션이 "완전히 실행되거나, 전혀 실행되지 않아야 함".
  - Consistency(일관성): 데이터가 항상 일관된 상태를 유지해야 함.
  - Isolation(고립성): 트랜잭션이 다른 트랜잭션과 독립적으로 실행되어야 함.
  - Durability(지속성): 트랜잭션이 완료된 후에도 데이터가 손실되지 않아야 함.
①, ③, ④ 틀림:
- 백업은 무결성과 관련 없음.
- SQL Injection 테스트는 보안 테스트 영역.
- 데이터 동기화는 분산 데이터베이스 검증에서 중요하지만, 데이터 무결성과는 직접적인 관련이 없음.

✅ 65. 보안 테스트에서 OWASP Top 10 문제

문제 65. OWASP Top 10에서 "Broken Authentication" 취약점에 대한 설명으로 올바른 것은?

API가 비정상적인 트래픽을 감지하지 못하는 문제
사용자 로그인 과정에서 인증이 취약하여 공격자가 계정을 탈취할 수 있는 문제
웹 애플리케이션에서 입력 값을 검증하지 않아 악성 스크립트가 실행되는 문제
데이터베이스에서 SQL Injection이 발생하는 문제

✅ 정답: ② 사용자 로그인 과정에서 인증이 취약하여 공격자가 계정을 탈취할 수 있는 문제

🔍 해설:

Broken Authentication(취약한 인증):
- 공격자가 약한 패스워드, 세션 탈취, 자동 로그인 문제 등을 악용하여 계정을 탈취하는 공격.
- 예:
  - "admin/admin123" 같은 취약한 비밀번호 사용.
  - 쿠키에서 세션 ID를 탈취하여 로그인 유지.
  - 다중 인증(MFA)을 적용하지 않아 계정이 쉽게 탈취되는 문제 발생.
①, ③, ④ 틀림:
- 비정상 트래픽 감지는 DDoS 공격 대응 영역.
- 입력 값 검증 문제는 XSS(Cross-Site Scripting) 공격과 관련.
- SQL Injection은 데이터베이스 보안 취약점.

✅ 추가 심화 개념 정리

📌 시험에서 자주 출제되는 헷갈리는 개념들

✅ API 테스트에서 계약 테스트(Contract Testing)의 필요성 이해
✅ 성능 테스트에서 TPS(Transactions Per Second)와 응답 시간 관계 분석
✅ 정적 테스트 vs 동적 테스트 차이 및 주요 기법 숙지
✅ 데이터베이스 테스트에서 ACID 원칙이 중요한 이유 이해
✅ 보안 테스트에서 OWASP Top 10(Broken Authentication, SQL Injection 등) 개념 숙지

✅ 66. 테스트 자동화 전략 문제

문제 66. 테스트 자동화를 도입할 때 가장 먼저 고려해야 할 사항은?

모든 테스트를 100% 자동화할 수 있는지 검토한다.
자동화할 테스트 케이스의 우선순위를 정한다.
테스트 자동화 도구를 먼저 선정한 후, 자동화 범위를 결정한다.
개발자가 모든 테스트 자동화를 직접 수행하도록 한다.

✅ 정답: ② 자동화할 테스트 케이스의 우선순위를 정한다.

🔍 해설:

테스트 자동화 전략의 핵심:
- 자동화할 테스트를 선정하는 것이 가장 중요함.
- 반복적이고 실행 빈도가 높은 테스트를 우선적으로 자동화해야 함.
- 예: 회귀 테스트(Regression Testing), API 테스트, 로그인/회원가입 테스트 등.
①, ③, ④ 틀림:
- 100% 자동화는 현실적으로 불가능함.
- 도구 선정보다 무엇을 자동화할지 정하는 것이 우선.
- 개발자가 자동화를 수행하는 것도 가능하지만, QA 팀과 협업이 필요함.

✅ 67. API 테스트에서 상태 코드 문제

문제 67. API 테스트에서 HTTP 429 Too Many Requests 응답이 의미하는 것은?

클라이언트 요청이 올바르지 않음을 의미한다.
서버 내부 오류로 인해 요청을 처리할 수 없음을 의미한다.
사용자가 너무 많은 요청을 보냈기 때문에 제한이 걸렸음을 의미한다.
클라이언트가 인증되지 않았음을 의미한다.

✅ 정답: ③ 사용자가 너무 많은 요청을 보냈기 때문에 제한이 걸렸음을 의미한다.

🔍 해설:

HTTP 상태 코드:
- 400 Bad Request → 클라이언트 요청이 잘못됨.
- 500 Internal Server Error → 서버 내부 오류.
- 429 Too Many Requests → API 요청이 너무 많아 서버에서 요청을 제한함.
- 401 Unauthorized → 클라이언트가 인증되지 않음.
③ 정답:
- API 서버에서 Rate Limiting(요청 제한) 을 설정한 경우 발생하는 응답 코드.
- 예: 초당 100개의 요청만 허용하는 API에서 101번째 요청을 보내면 429 Too Many Requests 응답을 받음.

✅ 68. 보안 테스트에서 CSRF 문제

문제 68. CSRF(Cross-Site Request Forgery) 공격을 방지하는 가장 효과적인 방법은?

사용자 입력값을 검증하고 필터링한다.
HTTP 요청에 CSRF 토큰을 추가하고 검증한다.
모든 사용자 요청을 HTTPS로 암호화한다.
서버가 요청을 받을 때 IP 주소를 검사한다.

✅ 정답: ② HTTP 요청에 CSRF 토큰을 추가하고 검증한다.

🔍 해설:

CSRF (Cross-Site Request Forgery):
- 공격자가 사용자의 세션을 이용하여 원치 않는 요청을 서버에 보낼 수 있도록 유도하는 공격 기법.
- 예: 사용자가 로그인한 상태에서 악성 링크를 클릭하면 공격자가 사용자의 계정으로 요청을 보낼 수 있음.
방지 방법:
- CSRF 토큰 사용: 모든 요청에 고유한 CSRF 토큰을 포함하여 서버에서 이를 검증.
- SameSite 쿠키 설정: CSRF 공격을 방지하기 위해 쿠키 정책을 설정.
- Referrer 검증: 요청의 출처를 확인하여 신뢰할 수 있는 도메인인지 검증.
①, ③, ④ 틀림:
- 입력값 검증(XSS 방지), HTTPS 사용(데이터 암호화), IP 검사(보안 강화)는 중요하지만 CSRF를 완벽하게 방지하지 못함.

✅ 69. 성능 테스트에서 부하 테스트 문제

문제 69. 부하 테스트(Load Testing)의 주요 목적은?

서버가 과부하 상태에서 어떻게 복구되는지 확인하는 것.
정상적인 사용량에서 시스템의 성능을 측정하는 것.
해킹 시도가 있을 경우 시스템이 어떻게 반응하는지 확인하는 것.
사용자의 요청을 분석하여 애플리케이션을 최적화하는 것.

✅ 정답: ② 정상적인 사용량에서 시스템의 성능을 측정하는 것.

🔍 해설:

부하 테스트(Load Testing):
- 시스템이 정상적인 트래픽에서 얼마나 안정적으로 동작하는지 평가하는 테스트.
- 예: 하루 평균 1만 명이 접속하는 웹사이트가 문제없이 동작하는지 확인.
①, ③, ④ 틀림:
- 과부하 상태에서의 복구는 스트레스 테스트(Stress Testing) 영역.
- 해킹 시도에 대한 반응은 보안 테스트(Security Testing) 영역.
- 애플리케이션 최적화는 성능 분석의 일부지만, 부하 테스트의 직접적인 목적은 아님.

✅ 70. 모바일 앱 배터리 사용량 테스트 문제

문제 70. 모바일 앱의 배터리 소모량을 테스트할 때 고려해야 할 가장 중요한 요소는?

앱이 다양한 네트워크 환경에서 어떻게 동작하는지 확인하는 것.
앱이 백그라운드에서 실행될 때 배터리 사용량을 측정하는 것.
앱이 최신 버전의 안드로이드에서만 실행되는지 확인하는 것.
앱의 설치 파일(APK)의 크기를 최소화하는 것.

✅ 정답: ② 앱이 백그라운드에서 실행될 때 배터리 사용량을 측정하는 것.

🔍 해설:

모바일 배터리 소모 테스트:
- 앱이 백그라운드에서 실행될 때 CPU, 네트워크, GPS 사용량이 많으면 배터리 소모가 심할 수 있음.
- 배터리 프로파일링 도구:
  - Android Profiler
  - Battery Historian
①, ③, ④ 틀림:
- 네트워크 환경 테스트는 중요하지만, 배터리 테스트의 핵심은 아님.
- 최신 버전에서만 실행되는 것이 아니라 다양한 OS 버전에서 테스트해야 함.
- APK 크기가 작다고 배터리 소모가 줄어드는 것은 아님.

✅ 추가 심화 개념 정리

📌 시험에서 자주 출제되는 헷갈리는 개념들

✅ 테스트 자동화 전략 - 무엇을 자동화해야 하는지 먼저 결정하는 것이 중요
✅ API 테스트에서 429 Too Many Requests 의미 및 Rate Limiting 개념 숙지
✅ 보안 테스트에서 CSRF 방지 방법(CSRF 토큰 활용)
✅ 성능 테스트에서 부하 테스트(Load Testing)와 스트레스 테스트 차이 이해
✅ 모바일 앱 배터리 사용량 테스트 - 백그라운드에서 배터리 소모 분석 필수

✅ 71. 자동화 테스트 유지보수 문제

문제 71. 자동화 테스트의 유지보수가 어려워지는 가장 주요한 원인은?

모든 테스트를 매일 실행하지 않기 때문이다.
애플리케이션 UI가 자주 변경되기 때문이다.
개발자가 직접 테스트를 수행하지 않기 때문이다.
자동화 테스트가 수동 테스트보다 느리기 때문이다.

✅ 정답: ② 애플리케이션 UI가 자주 변경되기 때문이다.

🔍 해설:

자동화 테스트의 유지보수 문제:
- UI가 자주 변경되면, 기존의 테스트 스크립트가 실패할 가능성이 높음.
- 해결 방법:
  - 페이지 객체 모델 (Page Object Model, POM) 적용 → UI 변경 시 영향 최소화.
  - CSS/XPath 대신 안정적인 요소 선택자 활용.
  - API 테스트와 결합하여 프런트엔드 변화에 덜 의존하는 자동화 구축.
①, ③, ④ 틀림:
- 매일 실행하지 않는 것이 유지보수를 어렵게 만들진 않음.
- 개발자가 직접 테스트를 수행하는 것과 유지보수 난이도는 별개.
- 자동화 테스트가 수동 테스트보다 느리진 않음.

✅ 72. API 테스트에서 응답 시간 문제

문제 72. API 테스트에서 응답 시간이 비정상적으로 길어질 경우, 가장 먼저 확인해야 할 요소는?

API의 HTTP 상태 코드
API의 데이터 응답 크기
클라이언트의 화면 해상도
네트워크의 IP 주소

✅ 정답: ② API의 데이터 응답 크기

🔍 해설:

API 응답 시간이 길어지는 주요 원인:
- 데이터 응답 크기: 너무 많은 데이터를 반환하면 네트워크 전송 시간이 길어짐.
- 불필요한 API 호출: 같은 데이터를 여러 번 요청하면 성능 저하.
- 서버 부하 증가: 동시에 너무 많은 요청을 처리하는 경우.
- 해결 방법:
  - Pagination (페이징) 적용: 한 번에 반환하는 데이터 양을 줄임.
  - Compression (압축): gzip 적용하여 응답 크기 줄이기.
  - API 캐싱: 자주 요청되는 데이터는 캐시 활용.
①, ③, ④ 틀림:
- HTTP 상태 코드는 요청 성공 여부만 판단할 수 있음.
- 화면 해상도는 API 응답 속도와 무관.
- 네트워크 IP 주소는 API 속도 문제 해결에 직접적인 영향을 주지 않음.

✅ 73. 성능 테스트에서 메모리 누수 문제

문제 73. 애플리케이션의 메모리 누수(Memory Leak)를 탐지하는 가장 효과적인 방법은?

애플리케이션을 여러 번 실행하여 속도가 느려지는지 확인한다.
장시간 실행 후 메모리 사용량을 지속적으로 모니터링한다.
소스 코드를 정적 분석하여 오류를 찾는다.
API 응답 속도를 측정한다.

✅ 정답: ② 장시간 실행 후 메모리 사용량을 지속적으로 모니터링한다.

🔍 해설:

메모리 누수(Memory Leak):
- 프로그램이 사용한 메모리를 해제하지 않아 점점 더 많은 메모리를 차지하게 되는 현상.
- 장시간 실행 시 메모리 사용량이 지속적으로 증가하는지를 모니터링해야 함.
- Heap Dump 분석, LeakCanary(Android), VisualVM(Java) 등을 활용.
①, ③, ④ 틀림:
- 단순 실행으로는 메모리 누수를 감지하기 어려움.
- 정적 분석은 일부 오류는 발견 가능하지만 동적 분석이 필요함.
- API 응답 속도와 메모리 누수는 무관.

✅ 74. 애자일 QA에서 테스트 전략 문제

문제 74. 애자일(Agile) 개발 환경에서 QA의 역할로 가장 적절한 것은?

개발이 완료된 후 테스트를 수행한다.
개발 단계마다 자동화 테스트를 실행하고 피드백을 제공한다.
모든 기능을 수동 테스트로 검증한다.
개발과 QA는 별도로 작업해야 한다.

✅ 정답: ② 개발 단계마다 자동화 테스트를 실행하고 피드백을 제공한다.

🔍 해설:

애자일에서 QA의 역할:
- Shift-Left Testing: 개발 초기에 테스트를 수행하여 결함을 빠르게 발견.
- TDD(Test-Driven Development): 개발자가 코드 작성 전에 테스트 케이스를 먼저 작성.
- CI/CD 환경에서 자동화 테스트 실행: 지속적인 테스트와 피드백 제공.
①, ③, ④ 틀림:
- 개발 후 테스트를 수행하면 결함 수정 비용이 증가함.
- 모든 기능을 수동으로 테스트하는 것은 비효율적.
- 애자일 환경에서는 개발과 QA가 긴밀하게 협업해야 함.

✅ 75. 접근성 테스트에서 스크린 리더 문제

문제 75. 접근성 테스트(Accessibility Testing)에서 스크린 리더(Screen Reader)가 중요한 이유는?

비시각적 사용자(시각 장애인)도 애플리케이션을 사용할 수 있도록 돕기 때문이다.
모든 웹사이트에서 필수로 적용해야 하는 요소이기 때문이다.
보안 취약점을 찾는 데 도움을 주기 때문이다.
애플리케이션의 성능을 측정하는 기준이기 때문이다.

✅ 정답: ① 비시각적 사용자(시각 장애인)도 애플리케이션을 사용할 수 있도록 돕기 때문이다.

🔍 해설:

스크린 리더(Screen Reader):
- 시각 장애인도 웹사이트 및 모바일 앱을 이용할 수 있도록 돕는 필수적인 접근성 도구.
- Windows: NVDA, JAWS / Mac: VoiceOver / Android: TalkBack.
- 웹 요소(버튼, 링크, 입력 필드 등)가 적절하게 읽히는지 테스트 필요.
②, ③, ④ 틀림:
- 모든 웹사이트에서 필수는 아니지만, 접근성 표준(WCAG)을 준수해야 함.
- 보안 취약점과는 관련이 없음.
- 성능 테스트의 기준이 아님.

✅ 추가 심화 개념 정리

📌 Pretest 대비 중요 개념

✅ 테스트 자동화 유지보수 - UI 변경에 대비한 안정적인 자동화 전략 필요
✅ API 테스트에서 응답 속도 개선을 위한 데이터 최적화(Pagination, Compression)
✅ 성능 테스트에서 메모리 누수 탐지(Heap Dump, LeakCanary 활용)
✅ 애자일 QA - Shift-Left Testing, CI/CD 자동화 테스트의 역할 이해
✅ 접근성 테스트 - 스크린 리더를 활용한 UI 음성 안내 검증 필요

✅ 76. 테스트 자동화 유지보수 최적화 문제

문제 76. 테스트 자동화 코드의 유지보수를 최적화하는 가장 효과적인 방법은?

모든 테스트 케이스를 개별적으로 관리하고 실행한다.
단순한 UI 변경에도 테스트 코드가 변경되지 않도록 설계한다.
수동 테스트를 최소화하고 모든 기능을 자동화한다.
모든 UI 요소를 XPath로 식별하여 테스트 코드를 작성한다.

✅ 정답: ② 단순한 UI 변경에도 테스트 코드가 변경되지 않도록 설계한다.

🔍 해설:

테스트 자동화의 유지보수성을 높이는 핵심 전략:
- 페이지 객체 모델 (Page Object Model, POM) 적용 → UI 변경 시 코드 수정 최소화.
- CSS Selector, ID를 활용한 요소 식별 → XPath는 유지보수성이 떨어짐.
- API 레이어에서 테스트 실행 → UI 의존성을 줄여 자동화 테스트 속도 개선.
①, ③, ④ 틀림:
- 모든 테스트를 개별적으로 실행하면 중복 코드가 많아지고 관리가 어려움.
- 수동 테스트는 여전히 필요하며 100% 자동화는 현실적으로 불가능함.
- XPath는 UI 변경 시 깨지기 쉽기 때문에 유지보수성이 낮음.

✅ 77. API 성능 테스트에서 Rate Limiting 문제

문제 77. API 서버가 초당 최대 1,000개의 요청을 처리할 수 있도록 설계되었을 때, Rate Limiting을 적절히 적용하기 위한 방법은?

API 요청을 무조건 차단하고 일정 시간이 지난 후 다시 허용한다.
클라이언트가 요청을 보낼 때마다 랜덤 대기 시간을 추가한다.
특정 시간 동안 허용된 요청 수를 초과하면 429 응답을 반환하고 재시도 지연을 유도한다.
요청이 많아지면 자동으로 서버를 확장하여 처리하도록 한다.

✅ 정답: ③ 특정 시간 동안 허용된 요청 수를 초과하면 429 응답을 반환하고 재시도 지연을 유도한다.

🔍 해설:

Rate Limiting (요청 제한):
- 특정 시간 내에 요청 횟수를 제한하여 서버 부하를 방지하고 공정한 사용을 보장하는 기법.
- 429 Too Many Requests 응답을 반환하고, Retry-After 헤더를 포함하여 클라이언트가 재시도 가능 시간을 알 수 있도록 해야 함.
①, ②, ④ 틀림:
- 무조건 차단하면 사용자 경험이 나빠짐.
- 랜덤 대기 시간은 예측 가능성을 낮추어 비효율적.
- 자동 서버 확장은 비용이 높고, Rate Limiting의 목적과 다름.

✅ 78. 데이터베이스 인덱스 최적화 문제

문제 78. 데이터베이스 쿼리의 실행 속도를 최적화하기 위해 인덱스를 생성할 때 가장 중요한 고려사항은?

모든 컬럼에 대해 인덱스를 생성한다.
자주 사용되는 검색 조건(WHERE 절)에 포함된 컬럼에 인덱스를 추가한다.
테이블의 전체 데이터를 메모리에 로드하여 처리 속도를 높인다.
인덱스는 항상 단일 컬럼으로만 생성해야 한다.

✅ 정답: ② 자주 사용되는 검색 조건(WHERE 절)에 포함된 컬럼에 인덱스를 추가한다.

🔍 해설:

데이터베이스 인덱스 최적화:
- WHERE, JOIN, ORDER BY, GROUP BY 절에서 자주 사용되는 컬럼에 인덱스를 추가하면 쿼리 실행 속도를 획기적으로 개선할 수 있음.
- 예:
  
  sql
  
  복사편집
  
  CREATE INDEX idx_user_email ON users(email); SELECT * FROM users WHERE email = 'test@example.com';
①, ③, ④ 틀림:
- 모든 컬럼에 인덱스를 생성하면 쓰기 성능이 저하되고, 저장 공간이 낭비됨.
- 전체 데이터를 메모리에 로드하는 것은 비효율적.
- 복합 인덱스(Multi-Column Index)도 활용 가능함.

✅ 79. 컨테이너 기반 애플리케이션 테스트 문제

문제 79. 컨테이너 기반 애플리케이션의 테스트를 효과적으로 수행하기 위한 방법은?

컨테이너 내부에서만 테스트를 실행하고 외부 환경과의 연결은 고려하지 않는다.
컨테이너 시작 시 테스트 데이터를 자동으로 로드하도록 구성한다.
컨테이너별로 서로 다른 네트워크를 사용하여 테스트 환경을 격리한다.
컨테이너 내부에서만 로깅을 수행하여 로그를 저장한다.

✅ 정답: ② 컨테이너 시작 시 테스트 데이터를 자동으로 로드하도록 구성한다.

🔍 해설:

컨테이너 기반 애플리케이션 테스트의 핵심:
- 테스트 데이터 자동 로딩:
  - 컨테이너가 시작될 때 초기 데이터를 설정하여 테스트 환경을 빠르게 구성 가능.
  - docker-compose.yml에서 볼륨을 활용하거나, entrypoint.sh 스크립트로 데이터를 로드하는 방식 사용.
①, ③, ④ 틀림:
- 컨테이너 내부에서만 테스트하면 실제 운영 환경과의 통합 테스트를 수행할 수 없음.
- 네트워크를 무조건 격리하면 API 또는 DB 연결 테스트가 어려움.
- 로그는 중앙화된 로깅 시스템(예: ELK, Loki)으로 저장해야 함.

✅ 80. AI/ML 시스템의 테스트 문제

문제 80. AI/ML 모델의 품질을 평가하는 가장 중요한 테스트 방법은?

모델이 모든 입력값에서 항상 동일한 출력을 반환하는지 확인한다.
모델의 예측 결과를 검증하고 정밀도(Precision)와 재현율(Recall)을 측정한다.
소스 코드의 가독성을 분석하여 모델이 논리적으로 올바르게 동작하는지 확인한다.
모델의 실행 속도가 동일한지 반복적으로 측정한다.

✅ 정답: ② 모델의 예측 결과를 검증하고 정밀도(Precision)와 재현율(Recall)을 측정한다.

🔍 해설:

AI/ML 모델 테스트의 핵심:
- 모델의 품질을 평가하는 대표적인 지표:
  - 정밀도(Precision): 모델이 긍정적으로 예측한 것 중 실제로 맞은 비율.
  - 재현율(Recall): 실제 정답 중에서 모델이 맞힌 비율.
  - F1 Score: Precision과 Recall의 조화 평균.
①, ③, ④ 틀림:
- AI 모델은 입력에 따라 다르게 동작해야 함.
- 소스 코드 가독성은 모델 품질 평가와 무관함.
- 실행 속도보다는 예측 정확도가 더 중요한 요소.

✅ 고급 QA 개념 정리

📌 Pretest에서 심화 개념 대비

✅ 테스트 자동화 최적화 - 유지보수성 높은 자동화 코드 설계 (POM, API 기반 테스트 적용)
✅ API Rate Limiting - 429 Too Many Requests 응답 처리 및 요청 재시도 전략
✅ 데이터베이스 성능 테스트 - WHERE 절 최적화를 위한 인덱스 적용 전략
✅ 컨테이너 기반 테스트 - 테스트 데이터 자동 로드 및 로깅 전략 이해
✅ AI/ML 테스트 - 정밀도(Precision) & 재현율(Recall) 평가 방식 숙지

✅ 81. 테스트 자동화에서 플러팅 문제(Flaky Test) 해결

문제 81. 테스트 자동화에서 "플러팅 테스트(Flaky Test)"가 발생하는 주요 원인은 무엇인가?

모든 테스트가 병렬로 실행되기 때문이다.
테스트 실행 결과가 항상 일관되게 나오지 않기 때문이다.
자동화된 UI 테스트가 너무 빠르게 실행되기 때문이다.
모든 테스트가 동기적으로 실행되기 때문이다.

✅ 정답: ② 테스트 실행 결과가 항상 일관되게 나오지 않기 때문이다.

🔍 해설:

플러팅 테스트(Flaky Test)란?
- 동일한 테스트를 반복 실행할 때 결과가 일관되지 않게 변하는 테스트.
- 한 번은 통과하지만, 다른 실행에서는 실패하는 문제 발생.
주요 원인:
1. 비동기 처리 문제: UI 요소가 로딩되기 전에 테스트가 실행됨.
2. 테스트 환경 차이: 로컬과 CI/CD 환경에서 결과가 다름.
3. 서버 응답 지연: 네트워크 요청 속도가 일정하지 않음.
4. 테스트 간 종속성: 하나의 테스트가 다른 테스트의 결과에 영향을 줌.
해결 방법:
- 테스트 안정화: 테스트 실행 전에 Explicit Wait (명시적 대기) 적용.
- 독립적인 테스트 설계: 테스트가 서로 영향을 주지 않도록 개선.
- 네트워크 요청 Mocking: 서버 응답을 안정적으로 제어.

✅ 82. API 부하 테스트에서 병목 현상 탐지

문제 82. API 부하 테스트(Load Testing)에서 서버의 병목 현상을 감지하기 위한 가장 효과적인 방법은?

초당 처리 요청 수(TPS)와 응답 시간을 모니터링한다.
클라이언트 측에서 API 요청을 무작위로 생성하여 부하를 준다.
모든 API 요청을 데이터베이스에서 직접 실행한다.
테스트 실행 후 로그 파일만 분석한다.

✅ 정답: ① 초당 처리 요청 수(TPS)와 응답 시간을 모니터링한다.

🔍 해설:

API 부하 테스트의 핵심 지표:
1. TPS(Transactions Per Second): 초당 몇 개의 요청을 처리할 수 있는지 측정.
2. 응답 시간(Response Time): 요청이 처리되는 데 걸리는 시간.
3. CPU & 메모리 사용량: 서버 부하가 어느 정도인지 파악.
4. DB 쿼리 실행 시간: 데이터베이스가 응답 속도를 저하시키는지 분석.
병목 현상 탐지 방법:
- TPS는 일정한데 응답 시간이 급격히 증가하면 서버 부하 증가로 인한 병목 발생 가능.
- 특정 API 호출이 응답 시간이 길다면, 쿼리 최적화 또는 캐싱 적용 필요.
②, ③, ④ 틀림:
- 무작위 요청은 테스트의 일관성을 보장하지 않음.
- 모든 API 요청을 DB에서 직접 실행하면 실제 부하 환경과 다름.
- 로그 분석만으로 실시간 병목 탐지는 어려움.

✅ 83. 데이터베이스 트랜잭션 격리 수준 문제

문제 83. 데이터베이스 트랜잭션의 "격리 수준(Isolation Level)"을 조정하는 주된 이유는?

트랜잭션을 최대한 빠르게 실행하기 위해서
동시 실행되는 트랜잭션 간의 충돌을 방지하고 데이터 일관성을 유지하기 위해서
데이터베이스에서 모든 쿼리를 즉시 반영하기 위해서
데이터베이스의 크기를 줄이기 위해서

✅ 정답: ② 동시 실행되는 트랜잭션 간의 충돌을 방지하고 데이터 일관성을 유지하기 위해서.

🔍 해설:

트랜잭션 격리 수준(Isolation Level)이란?
- 다중 트랜잭션이 동시에 실행될 때 데이터 일관성을 보장하기 위한 설정.
주요 격리 수준:
1. READ UNCOMMITTED: 트랜잭션이 커밋되지 않은 데이터도 읽을 수 있음 → Dirty Read 발생 가능.
2. READ COMMITTED: 커밋된 데이터만 읽을 수 있음 → Dirty Read 방지.
3. REPEATABLE READ: 동일 트랜잭션 내에서는 같은 데이터를 읽을 때 항상 동일한 결과 유지 → Phantom Read 발생 가능.
4. SERIALIZABLE: 트랜잭션을 직렬화하여 실행 → 가장 높은 일관성 보장, 그러나 성능 저하.
③, ④ 틀림:
- 트랜잭션이 즉시 반영되는 것은 ACID 원칙의 일부지만, 격리 수준과는 다름.
- 데이터베이스 크기와는 직접적인 관련이 없음.

✅ 84. 컨테이너 기반 애플리케이션 성능 테스트

문제 84. 컨테이너 기반 애플리케이션에서 성능 테스트를 수행할 때 가장 중요한 고려사항은?

컨테이너가 실행 중인지 여부만 확인한다.
컨테이너 내부의 CPU 및 메모리 사용량을 모니터링한다.
애플리케이션이 항상 단일 노드에서 실행되는지 확인한다.
네트워크 요청을 최대한 줄여 컨테이너 간 통신을 차단한다.

✅ 정답: ② 컨테이너 내부의 CPU 및 메모리 사용량을 모니터링한다.

🔍 해설:

컨테이너 기반 애플리케이션의 성능 테스트 핵심:
1. CPU 및 메모리 사용량: 특정 컨테이너가 과부하 상태인지 확인.
2. 네트워크 트래픽: 마이크로서비스 간 통신이 병목을 일으키는지 분석.
3. 스토리지 I/O 성능: 볼륨 마운트가 성능 저하를 유발하는지 검토.
테스트 도구:
- Prometheus + Grafana: 실시간 모니터링
- K6, JMeter: 부하 테스트 수행
①, ③, ④ 틀림:
- 컨테이너 실행 여부만 확인하는 것은 성능 테스트가 아님.
- 컨테이너는 단일 노드에서만 실행되지 않음 → 클러스터 환경에서 테스트해야 함.
- 네트워크 요청을 무조건 줄이는 것이 아니라 최적화하는 것이 중요.

✅ 85. AI/ML 모델의 테스트 최적화

문제 85. AI/ML 시스템에서 "편향(Bias)"을 검출하고 해결하는 가장 적절한 방법은?

AI 모델이 항상 같은 출력을 반환하는지 확인한다.
모델이 특정 그룹을 차별적으로 예측하는지 검토하고 공정성 지표(Fairness Metric)를 적용한다.
AI 모델을 여러 번 실행하여 평균값을 계산한다.
모델의 예측 속도를 반복 측정하여 동일한 시간 내에 동작하는지 확인한다.

✅ 정답: ② 모델이 특정 그룹을 차별적으로 예측하는지 검토하고 공정성 지표(Fairness Metric)를 적용한다.

🔍 해설:

AI 모델의 편향(Bias) 검출 방법:
- 특정 성별, 인종, 연령대가 모델 예측에서 차별적으로 다뤄지는지 분석.
- 공정성 지표(Fairness Metric): Equalized Odds, Demographic Parity, Disparate Impact 등.
- 해결 방법:
  - 데이터셋 재조정 및 균형 조정 (Rebalancing).
  - 편향 보정 알고리즘 적용.

✅ 고급 QA 개념 정리

📌 Pretest에서 심화 개념 대비

✅ Flaky Test 해결 - 테스트 대기 적용 & 독립적 테스트 설계
✅ API 부하 테스트 - TPS & 응답 시간 분석을 통한 병목 해결
✅ DB 트랜잭션 격리 수준 - 동시 실행 시 데이터 일관성 유지 전략
✅ 컨테이너 성능 테스트 - CPU/메모리 사용량 실시간 모니터링 필수
✅ AI 모델 테스트 - 편향(Bias) 검출 및 공정성 개선 전략

✅ 86. 테스트 자동화 최적화 문제

문제 86. 대규모 소프트웨어 프로젝트에서 테스트 자동화를 효과적으로 관리하기 위한 가장 중요한 전략은?

모든 테스트를 한 번에 실행하여 테스트 속도를 높인다.
지속적 통합(CI) 파이프라인에서 실행할 테스트를 계층화하고 병렬로 실행한다.
자동화 테스트보다 수동 테스트를 우선적으로 수행한다.
테스트 스크립트를 최대한 길게 작성하여 테스트 범위를 넓힌다.

✅ 정답: ② 지속적 통합(CI) 파이프라인에서 실행할 테스트를 계층화하고 병렬로 실행한다.

🔍 해설:

대규모 프로젝트에서 테스트 자동화를 최적화하는 전략:
1. 테스트 계층화(Test Pyramid) 적용:
  - 단위 테스트(Unit Test) → 빠르고 빈번하게 실행.
  - API 테스트(Integration Test) → 서비스 간 연동 검증.
  - UI 테스트(E2E Test) → 최소한의 테스트만 유지.
2. 병렬 실행(Parallel Execution) 활용:
  - CI/CD 파이프라인에서 테스트를 병렬로 실행하여 속도 최적화.
3. 테스트 데이터 관리:
  - Mocking & Stubbing을 통해 테스트 환경에서 불필요한 외부 의존성을 제거.
①, ③, ④ 틀림:
- 모든 테스트를 한 번에 실행하면 CI/CD 속도가 저하됨.
- 자동화 테스트는 수동 테스트보다 우선적으로 실행해야 함.
- 긴 테스트 스크립트보다 짧고 유지보수하기 쉬운 테스트 코드가 중요.

✅ 87. API 테스트에서 JWT 보안 문제

문제 87. API에서 JWT(JSON Web Token) 인증을 사용할 때 발생할 수 있는 보안 취약점은?

JWT를 Base64로 인코딩하므로 공격자가 쉽게 해독할 수 있다.
JWT는 인증이 필요 없기 때문에 보안성이 낮다.
JWT의 서명(Signature)을 검증하지 않으면 토큰 위변조 공격을 당할 수 있다.
JWT는 한 번 생성되면 절대 만료되지 않는다.

✅ 정답: ③ JWT의 서명(Signature)을 검증하지 않으면 토큰 위변조 공격을 당할 수 있다.

🔍 해설:

JWT(JSON Web Token) 보안에서 가장 중요한 점:
- 서명(Signature) 검증: JWT는 Header.Payload.Signature 구조로 이루어짐.
- 공격자가 JWT를 위변조하는 경우, 서명을 검증하지 않으면 위조된 토큰을 신뢰하는 보안 문제 발생.
- 예:
  
  python
  
  복사편집
  
  import jwt token = jwt.encode({'user_id': 123}, "secret", algorithm="HS256")
- 해결책:
  - JWT 서명을 항상 검증하고, 신뢰할 수 있는 키(Key)로 검증할 것.
  - 짧은 만료 시간 설정 및 Refresh Token 활용.
①, ②, ④ 틀림:
- Base64 인코딩은 암호화가 아니라 단순한 변환이지만, JWT 자체는 서명을 포함하므로 보호됨.
- JWT는 인증이 필요하며, 세션 기반 인증보다 보안성이 더 높은 경우가 많음.
- JWT는 만료 시간이 설정될 수 있으며, Refresh Token을 통해 갱신 가능.

✅ 88. 데이터베이스 인덱스 튜닝 문제

문제 88. 데이터베이스에서 인덱스를 잘못 생성했을 때 발생할 수 있는 문제는?

인덱스가 많을수록 쿼리 성능이 항상 향상된다.
데이터 변경(INSERT, UPDATE, DELETE) 성능이 저하될 수 있다.
모든 테이블에 기본적으로 인덱스를 적용해야 한다.
인덱스가 많으면 데이터 저장 공간이 줄어든다.

✅ 정답: ② 데이터 변경(INSERT, UPDATE, DELETE) 성능이 저하될 수 있다.

🔍 해설:

인덱스(Index) 문제점:
- 읽기(SELECT) 속도는 향상되지만, 쓰기(INSERT, UPDATE, DELETE) 성능이 저하될 수 있음.
- 인덱스가 많아질수록 쓰기 작업 시 모든 인덱스를 갱신해야 하므로 성능 저하 발생.
해결 방법:
- 자주 사용되는 쿼리에서 WHERE 조건이 적용되는 컬럼에만 인덱스를 생성.
- 읽기(Read-heavy) vs 쓰기(Write-heavy) 데이터베이스에 맞춰 인덱스 전략을 조정.
①, ③, ④ 틀림:
- 인덱스가 많다고 항상 성능이 향상되지는 않음.
- 모든 테이블에 인덱스를 적용하는 것은 비효율적.
- 인덱스는 추가적인 저장 공간을 사용하기 때문에 데이터 크기가 증가할 수 있음.

✅ 89. 컨테이너 기반 애플리케이션 테스트 문제

문제 89. 컨테이너 기반 애플리케이션을 테스트할 때 가장 중요한 요소는?

컨테이너가 실행 중인지 여부만 확인한다.
컨테이너 간 네트워크 통신이 원활한지 검증한다.
모든 컨테이너를 동일한 환경에서 실행해야 한다.
컨테이너 로그를 수동으로 분석하여 오류를 확인한다.

✅ 정답: ② 컨테이너 간 네트워크 통신이 원활한지 검증한다.

🔍 해설:

컨테이너 기반 애플리케이션의 테스트 핵심:
- 컨테이너 간 네트워크 통신을 검증하는 것이 중요함.
- 마이크로서비스 아키텍처에서는 여러 개의 컨테이너가 서로 통신해야 하므로, 네트워크 장애가 발생하면 전체 서비스에 영향을 미침.
테스트 방법:
- curl 또는 nc(netcat)를 사용하여 컨테이너 간 통신 테스트.
- Kubernetes 환경에서는 kubectl exec을 활용하여 네트워크 상태 확인.
①, ③, ④ 틀림:
- 컨테이너 실행 여부만 확인하는 것은 충분한 테스트가 아님.
- 동일한 환경에서 실행하더라도 네트워크 문제는 발생할 수 있음.
- 로그 분석도 중요하지만, 자동화된 네트워크 테스트가 필요함.

✅ 90. 네트워크 보안 테스트에서 Man-in-the-Middle 공격 문제

문제 90. 네트워크 보안 테스트에서 Man-in-the-Middle(MITM) 공격을 방지하기 위한 가장 효과적인 방법은?

모든 요청을 암호화하지 않고 일반 HTTP를 사용한다.
TLS/SSL을 적용하고 인증서 검증을 수행한다.
네트워크 패킷을 로그 파일에 저장하여 분석한다.
동일한 네트워크에서만 모든 클라이언트가 접속하도록 제한한다.

✅ 정답: ② TLS/SSL을 적용하고 인증서 검증을 수행한다.

🔍 해설:

MITM(Man-in-the-Middle) 공격 방지 방법:
- TLS/SSL을 적용하여 데이터 암호화.
- 클라이언트가 서버의 인증서를 검증(Certificate Pinning)하도록 설정.
- HTTPS가 적용되었는지 확인하고, Strict-Transport-Security (HSTS) 설정.

✅ 심화 개념 정리

✅ 테스트 자동화 최적화 - 테스트 계층화(Test Pyramid) 및 병렬 실행 전략
✅ API 보안 - JWT 서명 검증 필수 및 만료 시간 관리
✅ DB 성능 - 인덱스 과다 사용 시 쓰기 성능 저하 가능성 고려
✅ 컨테이너 테스트 - 네트워크 연결 및 통신 검증이 핵심
✅ 네트워크 보안 - MITM 공격 방지를 위한 TLS/SSL 적용

✅ 1. 플러팅 테스트(Flaky Test) 문제

문제 1. 플러팅 테스트(Flaky Test)의 주요 원인은 무엇인가?

모든 테스트가 병렬로 실행되기 때문이다.
테스트 실행 결과가 항상 일관되게 나오지 않기 때문이다.
자동화된 UI 테스트가 너무 빠르게 실행되기 때문이다.
모든 테스트가 동기적으로 실행되기 때문이다.

✅ 정답: ② 테스트 실행 결과가 항상 일관되게 나오지 않기 때문이다.

🔍 해설:

Flaky Test란?
- 같은 테스트를 실행할 때 결과가 일관되지 않고 성공/실패가 반복되는 테스트.
발생 원인:
- 비동기 처리 문제: UI 요소가 로딩되기 전에 테스트 실행.
- 환경 차이: 로컬과 CI/CD에서 실행 결과가 다름.
- 서버 응답 지연: 네트워크 요청 속도 불안정.
- 테스트 간 종속성: 하나의 테스트가 다른 테스트 결과에 영향을 줌.
해결 방법:
- Explicit Wait (명시적 대기) 적용.
- 테스트 간 독립성 확보.
- Mocking 및 Stubbing을 활용하여 외부 의존성 제거.

📌 반드시 알아야 할 개념:
✅ 플러팅 테스트의 정의
✅ 테스트 독립성 확보 방법
✅ Mocking과 Stubbing의 차이

✅ 2. API Rate Limiting 문제

문제 2. API 서버가 초당 1,000개의 요청을 처리할 수 있도록 설계되었을 때, 적절한 Rate Limiting 적용 방법은?

모든 초과 요청을 무조건 차단한다.
클라이언트가 요청을 보낼 때 랜덤 대기 시간을 추가한다.
초과 요청 시 429 Too Many Requests 응답을 반환하고 Retry-After 헤더를 설정한다.
API 요청이 많아지면 자동으로 서버를 확장하여 처리하도록 한다.

✅ 정답: ③ 초과 요청 시 429 Too Many Requests 응답을 반환하고 Retry-After 헤더를 설정한다.

🔍 해설:

Rate Limiting(요청 제한)이란?
- 특정 시간 내에 허용된 요청 수를 초과하면 추가 요청을 제한하는 기술.
적절한 처리 방법:
- 429 Too Many Requests 응답을 반환.
- Retry-After 헤더를 포함하여 클라이언트가 재시도할 시간을 알림.
- 토큰 버킷(Token Bucket), 슬라이딩 윈도우(Sliding Window) 알고리즘 활용 가능.

📌 반드시 알아야 할 개념:
✅ API Rate Limiting 개념
✅ 429 Too Many Requests 응답 코드 의미
✅ Rate Limiting 알고리즘 종류 (Token Bucket, Sliding Window)

✅ 3. 데이터베이스 인덱스 최적화 문제

문제 3. 데이터베이스에서 인덱스를 과도하게 생성했을 때 발생할 수 있는 문제는?

모든 쿼리의 실행 속도가 향상된다.
데이터 변경(INSERT, UPDATE, DELETE) 성능이 저하될 수 있다.
인덱스가 많을수록 데이터베이스 크기가 줄어든다.
모든 테이블에 기본적으로 인덱스를 적용해야 한다.

✅ 정답: ② 데이터 변경(INSERT, UPDATE, DELETE) 성능이 저하될 수 있다.

🔍 해설:

인덱스(Index)의 역할:
- SELECT 성능을 높이지만, 쓰기 성능(INSERT, UPDATE, DELETE)은 낮출 수 있음.
적절한 인덱스 적용 전략:
- 자주 사용되는 검색 컬럼(WHERE 절 포함)에만 인덱스를 적용.
- 읽기(SELECT) 중심 시스템에서는 인덱스를 적극 활용하지만, 쓰기(INSERT) 중심 시스템에서는 최소화해야 함.

📌 반드시 알아야 할 개념:
✅ 인덱스의 장점과 단점
✅ SELECT vs INSERT/UPDATE 성능 차이
✅ 적절한 인덱스 적용 전략

✅ 4. JWT 보안 문제

문제 4. JWT(JSON Web Token)를 사용할 때 반드시 고려해야 할 보안 조치는?

JWT를 Base64로 인코딩하면 안전하다.
JWT의 서명을 검증하지 않으면 위변조 공격을 당할 수 있다.
JWT는 만료 시간이 필요 없으며, 무제한으로 사용할 수 있다.
JWT는 세션 기반 인증보다 항상 보안성이 높다.

✅ 정답: ② JWT의 서명을 검증하지 않으면 위변조 공격을 당할 수 있다.

🔍 해설:

JWT 보안 취약점:
- 서명을 검증하지 않으면 공격자가 위변조된 토큰을 사용할 수 있음.
- 예제 코드:
  
  python
  
  복사편집
  
  import jwt token = jwt.encode({'user_id': 123}, "secret", algorithm="HS256")
보안 강화 방법:
- JWT 서명을 반드시 검증할 것.
- 만료 시간(Expiration Time, exp) 설정 필수.
- Refresh Token을 활용하여 보안 강화.

📌 반드시 알아야 할 개념:
✅ JWT 구조 (Header, Payload, Signature)
✅ JWT 서명(Signature) 검증 원리
✅ JWT vs 세션 기반 인증 비교

✅ 5. AI/ML 테스트 문제

문제 5. AI/ML 모델의 성능을 검증할 때 가장 중요한 평가 지표는?

모델이 항상 같은 출력을 반환하는지 확인한다.
모델의 정밀도(Precision)와 재현율(Recall)을 측정한다.
AI 모델의 실행 속도를 평가한다.
입력 데이터가 항상 동일한지를 확인한다.

✅ 정답: ② 모델의 정밀도(Precision)와 재현율(Recall)을 측정한다.

🔍 해설:

AI/ML 모델 평가 지표:
- 정밀도(Precision): 모델이 긍정 예측한 것 중에서 실제로 맞은 비율.
- 재현율(Recall): 실제 정답 중에서 모델이 맞힌 비율.
- F1 Score: Precision과 Recall의 조화 평균.

📌 반드시 알아야 할 개념:
✅ Precision, Recall, F1 Score 개념
✅ AI 모델 평가 방법 (Confusion Matrix)
✅ 모델의 과적합(Overfitting) 문제

✅ 6. 컨테이너 기반 애플리케이션 테스트 문제

문제 6. 컨테이너 기반 애플리케이션에서 성능 테스트를 수행할 때 가장 중요한 고려사항은?

컨테이너가 실행 중인지 여부만 확인한다.
컨테이너 내부의 CPU 및 메모리 사용량을 실시간으로 모니터링한다.
애플리케이션이 항상 단일 노드에서 실행되는지 확인한다.
네트워크 요청을 줄이기 위해 컨테이너 간 통신을 차단한다.

✅ 정답: ② 컨테이너 내부의 CPU 및 메모리 사용량을 실시간으로 모니터링한다.

🔍 해설:

컨테이너 기반 애플리케이션의 성능 테스트 핵심:
1. CPU 및 메모리 사용량 모니터링:
  - 특정 컨테이너가 과부하 상태인지 확인.
  - docker stats, kubectl top pod 활용.
2. 네트워크 트래픽 분석:
  - 마이크로서비스 간 통신이 병목을 일으키는지 평가.
3. 스토리지 I/O 성능:
  - 볼륨 마운트가 성능 저하를 유발하는지 검토.

📌 반드시 알아야 할 개념:
✅ 컨테이너 성능 테스트 도구 (Prometheus, Grafana, K6)
✅ CPU & 메모리 모니터링 명령어 (docker stats, kubectl top pod)
✅ 컨테이너 간 네트워크 병목 원인 및 해결 방법

✅ 7. 네트워크 보안 테스트에서 MITM 공격 문제

문제 7. 네트워크 보안 테스트에서 Man-in-the-Middle(MITM) 공격을 방지하기 위한 가장 효과적인 방법은?

모든 요청을 일반 HTTP로 처리한다.
TLS/SSL을 적용하고 인증서 검증을 수행한다.
네트워크 패킷을 로그 파일에 저장하여 분석한다.
동일한 네트워크에서만 모든 클라이언트가 접속하도록 제한한다.

✅ 정답: ② TLS/SSL을 적용하고 인증서 검증을 수행한다.

🔍 해설:

MITM(Man-in-the-Middle) 공격이란?
- 공격자가 클라이언트와 서버 간의 통신을 가로채어 데이터를 조작하거나 탈취하는 공격.
방지 방법:
- TLS/SSL 적용: HTTPS 프로토콜을 사용하여 통신을 암호화.
- 인증서 검증: Certificate Pinning 적용하여 신뢰할 수 있는 인증서만 허용.
- HSTS(Strict-Transport-Security) 활성화: 클라이언트가 HTTPS를 강제 사용하도록 설정.

📌 반드시 알아야 할 개념:
✅ MITM 공격 개념 및 사례
✅ TLS/SSL 인증서 검증 방법
✅ Certificate Pinning 및 HSTS의 역할

✅ 8. 성능 테스트에서 TPS와 응답 시간 관계 문제

문제 8. 성능 테스트에서 초당 트랜잭션 수(TPS)와 응답 시간(Response Time)의 관계에 대한 설명으로 올바른 것은?

TPS가 증가하면 응답 시간도 항상 증가한다.
TPS가 증가해도 응답 시간에는 영향을 주지 않는다.
TPS가 지나치게 증가하면 응답 시간이 증가할 수 있다.
응답 시간은 TPS와 관계없이 항상 일정하다.

✅ 정답: ③ TPS가 지나치게 증가하면 응답 시간이 증가할 수 있다.

🔍 해설:

TPS(Transactions Per Second)란?
- 시스템이 1초 동안 처리할 수 있는 트랜잭션의 수.
TPS와 응답 시간 관계:
- 초당 요청이 많아질수록 서버 부하가 증가하여 응답 시간이 길어질 가능성이 있음.
- 예:
  - TPS가 1,000일 때 응답 시간이 100ms였지만,
  - TPS가 5,000이 되면 응답 시간이 500ms로 증가할 수 있음.
성능 최적화 방법:
- 부하 분산(Load Balancing) 적용.
- 데이터베이스 쿼리 최적화 및 캐싱(Cache) 활용.

📌 반드시 알아야 할 개념:
✅ TPS, 응답 시간, 처리량 관계 이해
✅ 부하 테스트(Load Testing) 개념
✅ 성능 최적화를 위한 로드 밸런싱 및 캐싱 전략

✅ 9. 접근성 테스트에서 스크린 리더 문제

문제 9. 접근성 테스트(Accessibility Testing)에서 스크린 리더(Screen Reader)가 중요한 이유는?

비시각적 사용자(시각 장애인)도 애플리케이션을 사용할 수 있도록 돕기 때문이다.
모든 웹사이트에서 필수로 적용해야 하는 요소이기 때문이다.
보안 취약점을 찾는 데 도움을 주기 때문이다.
애플리케이션의 성능을 측정하는 기준이기 때문이다.

✅ 정답: ① 비시각적 사용자(시각 장애인)도 애플리케이션을 사용할 수 있도록 돕기 때문이다.

🔍 해설:

스크린 리더(Screen Reader)란?
- 시각 장애인이 웹사이트 및 모바일 앱을 사용할 수 있도록 UI 요소를 음성으로 안내하는 소프트웨어.
주요 스크린 리더:
- Windows: NVDA, JAWS
- Mac: VoiceOver
- Android: TalkBack
테스트 방법:
- 웹 페이지의 aria-label, alt 속성이 올바르게 설정되었는지 확인.
- 키보드만으로 모든 기능을 수행할 수 있는지 테스트.

📌 반드시 알아야 할 개념:
✅ 접근성 테스트의 중요성
✅ 주요 스크린 리더 도구 및 테스트 방법
✅ WCAG(Web Content Accessibility Guidelines) 표준

✅ 10. AI/ML 모델의 편향(Bias) 문제

문제 10. AI/ML 모델에서 편향(Bias)을 줄이기 위한 가장 적절한 방법은?

모델이 항상 같은 출력을 반환하는지 확인한다.
데이터셋을 다양화하고 공정성 지표(Fairness Metric)를 적용한다.
AI 모델을 여러 번 실행하여 평균값을 계산한다.
모델의 실행 속도를 반복 측정하여 동일한 시간 내에 동작하는지 확인한다.

✅ 정답: ② 데이터셋을 다양화하고 공정성 지표(Fairness Metric)를 적용한다.

🔍 해설:

AI 모델의 편향(Bias)이란?
- 특정 성별, 인종, 연령대가 모델 예측에서 차별적으로 다뤄지는 문제.
해결 방법:
- 데이터셋 다양화: 여러 그룹이 공평하게 포함되도록 데이터셋을 구성.
- 공정성 지표(Fairness Metric) 적용: Equalized Odds, Demographic Parity 등 활용.
- 편향 제거 알고리즘 적용: 모델 훈련 시 데이터 균형을 맞추는 기법 활용.

📌 반드시 알아야 할 개념:
✅ AI 모델의 편향(Bias) 개념
✅ 데이터셋 다양성 확보 방법
✅ Fairness Metric (Equalized Odds, Demographic Parity

✅ 11. 테스트 자동화에서 병렬 실행 문제

문제 11. 테스트 자동화에서 병렬 실행(Parallel Execution)을 적용할 때 발생할 수 있는 주요 문제는?

테스트 실행 속도가 느려진다.
서로 다른 테스트가 동일한 리소스를 동시에 사용하여 충돌이 발생할 수 있다.
병렬 실행을 적용하면 테스트 결과가 항상 일관되게 나온다.
테스트 실행 순서를 고정해야 한다.

✅ 정답: ② 서로 다른 테스트가 동일한 리소스를 동시에 사용하여 충돌이 발생할 수 있다.

🔍 해설:

병렬 실행(Parallel Execution)의 장점:
- 테스트 실행 속도를 대폭 단축하여 CI/CD 파이프라인을 빠르게 실행할 수 있음.
발생할 수 있는 문제:
- 공유 리소스 충돌: 테스트가 같은 데이터베이스 또는 API를 동시에 호출하면 오류 발생 가능.
- 동기화 문제: 특정 테스트가 완료되지 않았는데 다른 테스트가 실행되면 예기치 않은 결과가 발생.
- 해결 방법:
  - 테스트 간 데이터 격리 (Test Data Isolation).
  - Mocking을 활용하여 외부 의존성을 줄임.
  - Thread-safe한 테스트 코드 작성.

📌 반드시 알아야 할 개념:
✅ 병렬 실행(Parallel Execution) 개념과 장점
✅ 공유 리소스 충돌 문제와 해결 방법
✅ Mocking과 데이터 격리를 활용한 최적화 전략

✅ 12. API 보안 테스트에서 CSRF 문제

문제 12. CSRF(Cross-Site Request Forgery) 공격을 방지하는 가장 효과적인 방법은?

사용자 입력값을 필터링하고 검증한다.
모든 요청을 HTTPS로 암호화한다.
HTTP 요청에 CSRF 토큰을 추가하고 서버에서 이를 검증한다.
서버가 요청을 받을 때 IP 주소를 검사한다.

✅ 정답: ③ HTTP 요청에 CSRF 토큰을 추가하고 서버에서 이를 검증한다.

🔍 해설:

CSRF(Cross-Site Request Forgery)란?
- 공격자가 사용자의 인증된 세션을 악용하여 원하지 않는 요청을 서버에 보낼 수 있도록 유도하는 공격.
방지 방법:
- CSRF 토큰 사용:
  - 서버가 요청마다 고유한 CSRF 토큰을 발급하고, 클라이언트가 이를 함께 전송하도록 요구.
- SameSite 쿠키 설정:
  - SameSite=Strict 또는 SameSite=Lax를 설정하여 다른 사이트에서 요청을 보내지 못하도록 제한.
- Referrer 검증:
  - 요청 출처(Referrer)를 확인하여 신뢰할 수 있는 도메인인지 검증.

📌 반드시 알아야 할 개념:
✅ CSRF 공격 개념과 실제 사례
✅ CSRF 토큰의 역할과 적용 방법
✅ SameSite 쿠키 설정의 중요성

✅ 13. 데이터베이스 성능 튜닝 문제

문제 13. 데이터베이스에서 성능을 최적화하기 위해 가장 효과적인 방법은?

모든 테이블에 인덱스를 추가한다.
자주 사용되는 쿼리에 대한 실행 계획(Execution Plan)을 분석하고 적절한 인덱스를 추가한다.
데이터 정렬을 위해 항상 ORDER BY를 사용한다.
모든 데이터를 한 번에 가져와 애플리케이션에서 필터링한다.

✅ 정답: ② 자주 사용되는 쿼리에 대한 실행 계획(Execution Plan)을 분석하고 적절한 인덱스를 추가한다.

🔍 해설:

데이터베이스 성능 튜닝 핵심:
- 실행 계획(Execution Plan) 분석:
  - 쿼리가 실행될 때 어떤 인덱스를 사용하는지 확인하고 최적화.
- 인덱스 최적화:
  - WHERE, JOIN, GROUP BY 절에서 자주 사용되는 컬럼에 인덱스를 추가하여 성능 개선.
- 캐싱 활용:
  - Redis 또는 Memcached를 사용하여 반복적인 쿼리 실행을 줄임.

📌 반드시 알아야 할 개념:
✅ 데이터베이스 실행 계획(Execution Plan) 분석 방법
✅ 인덱스 튜닝 전략 (Clustered Index vs. Non-Clustered Index)
✅ 캐싱(Cache) 활용 방법

✅ 14. 네트워크 부하 테스트 문제

문제 14. 네트워크 부하 테스트(Network Load Testing)에서 측정해야 할 주요 지표는?

클라이언트의 CPU 사용량
서버의 IP 주소
요청 지연 시간(Latency)과 처리량(Throughput)
응답 데이터 크기만 측정한다.

✅ 정답: ③ 요청 지연 시간(Latency)과 처리량(Throughput)

🔍 해설:

네트워크 부하 테스트 핵심 지표:
1. 지연 시간(Latency): 요청을 보낸 후 응답을 받기까지의 시간.
2. 처리량(Throughput): 초당 처리할 수 있는 요청 수(TPS).
3. 에러율(Error Rate): 요청 중 실패한 요청의 비율.
부하 테스트 도구:
- JMeter, Gatling, K6 등 사용.

📌 반드시 알아야 할 개념:
✅ 네트워크 부하 테스트 개념과 지표
✅ Latency vs. Throughput 차이
✅ 부하 테스트 도구 (JMeter, K6, Gatling)

✅ 15. AI/ML 모델의 과적합 문제

문제 15. AI/ML 모델에서 과적합(Overfitting)을 방지하기 위한 방법으로 가장 적절한 것은?

훈련 데이터와 테스트 데이터를 동일하게 설정한다.
데이터셋의 크기를 줄여 모델을 빠르게 학습시킨다.
정규화(Regularization) 기법을 적용하고 교차 검증(Cross Validation)을 수행한다.
모델이 훈련 데이터를 완벽하게 예측하도록 조정한다.

✅ 정답: ③ 정규화(Regularization) 기법을 적용하고 교차 검증(Cross Validation)을 수행한다.

🔍 해설:

과적합(Overfitting)이란?
- 모델이 훈련 데이터에는 정확하지만 새로운 데이터에는 일반화되지 못하는 문제.
해결 방법:
- 정규화(Regularization): L1, L2 정규화 적용하여 모델이 특정 패턴에 과적합되지 않도록 조정.
- 교차 검증(Cross Validation): 데이터를 여러 개의 Fold로 나누어 학습 및 평가를 반복.
- Dropout 적용: 뉴럴 네트워크에서 일부 노드를 무작위로 비활성화하여 일반화 성능 향상.

📌 반드시 알아야 할 개념:
✅ AI/ML 모델의 과적합(Overfitting) 개념
✅ 정규화(Regularization) 및 교차 검증(Cross Validation) 기법
✅ Dropout과 데이터 증강(Data Augmentation) 방법

✅ 16. 테스트 자동화에서 CI/CD 파이프라인 문제

문제 16. CI/CD 파이프라인에서 자동화 테스트를 효율적으로 실행하는 가장 좋은 방법은?

모든 테스트를 한 번에 실행하여 속도를 높인다.
테스트 유형을 계층화하고(단위 테스트 → 통합 테스트 → UI 테스트) 병렬로 실행한다.
자동화 테스트보다 수동 테스트를 우선적으로 수행한다.
모든 테스트를 개발 단계가 끝난 후 한 번만 실행한다.

✅ 정답: ② 테스트 유형을 계층화하고(단위 테스트 → 통합 테스트 → UI 테스트) 병렬로 실행한다.

🔍 해설:

CI/CD에서 테스트 실행 최적화:
- 테스트 피라미드(Test Pyramid) 적용:
  - 단위 테스트(Unit Test) → 통합 테스트(Integration Test) → UI 테스트(End-to-End Test) 순으로 실행.
- 병렬 실행(Parallel Execution) 활용:
  - 빠른 피드백을 위해 가능한 테스트를 병렬 실행.
- 테스트 실패 시 빠른 피드백 제공:
  - 실패한 테스트를 우선적으로 수정하여 전체 배포 지연 방지.

📌 반드시 알아야 할 개념:
✅ 테스트 피라미드(Test Pyramid) 개념
✅ CI/CD에서 자동화 테스트 최적화 방법
✅ 병렬 실행(Parallel Execution)의 장점과 고려 사항

✅ 17. API 인증 및 보안 테스트 문제

문제 17. API 인증에서 OAuth 2.0을 사용할 때 가장 중요한 보안 고려 사항은?

Access Token을 만료 없이 유지하여 성능을 높인다.
Refresh Token을 사용하여 Access Token을 주기적으로 갱신한다.
API 키를 URL 파라미터로 전달한다.
클라이언트가 직접 Access Token을 생성하도록 한다.

✅ 정답: ② Refresh Token을 사용하여 Access Token을 주기적으로 갱신한다.

🔍 해설:

OAuth 2.0 보안 고려 사항:
- Access Token은 만료 시간이 있어야 함.
- Refresh Token을 사용하여 Access Token을 갱신해야 함.
- API 키를 URL에 직접 포함하면 보안 위험이 있음 → HTTP 헤더 또는 Body에 포함해야 함.

📌 반드시 알아야 할 개념:
✅ OAuth 2.0의 Access Token과 Refresh Token 차이
✅ API 키를 안전하게 전달하는 방법
✅ OAuth 2.0 보안 모범 사례

✅ 18. 데이터베이스 트랜잭션 문제

문제 18. 데이터베이스 트랜잭션에서 "더티 리드(Dirty Read)"가 발생할 수 있는 격리 수준은?

Read Uncommitted
Read Committed
Repeatable Read
Serializable

✅ 정답: ① Read Uncommitted

🔍 해설:

더티 리드(Dirty Read)란?
- 하나의 트랜잭션이 커밋되지 않은 데이터를 다른 트랜잭션에서 읽을 수 있는 문제.
격리 수준별 Dirty Read 발생 여부:
- Read Uncommitted: Dirty Read 발생 가능 ✅
- Read Committed: Dirty Read 방지 ❌
- Repeatable Read: Dirty Read 방지 + 동일한 데이터 읽기 유지 ❌
- Serializable: 가장 높은 격리 수준, Dirty Read 완벽 방지 ❌

📌 반드시 알아야 할 개념:
✅ 데이터베이스 트랜잭션 격리 수준 개념
✅ Dirty Read, Non-Repeatable Read, Phantom Read 차이
✅ 트랜잭션 ACID 원칙

✅ 19. 네트워크 성능 테스트에서 Latency와 Throughput 문제

문제 19. 네트워크 성능 테스트에서 "Latency"와 "Throughput"의 차이에 대한 설명으로 올바른 것은?

Latency는 초당 처리할 수 있는 요청 수이며, Throughput은 응답 속도를 의미한다.
Latency가 낮을수록 응답 속도가 빠르며, Throughput이 높을수록 많은 요청을 처리할 수 있다.
Throughput이 증가하면 항상 Latency도 증가한다.
Latency와 Throughput은 동일한 개념이다.

✅ 정답: ② Latency가 낮을수록 응답 속도가 빠르며, Throughput이 높을수록 많은 요청을 처리할 수 있다.

🔍 해설:

Latency(지연 시간):
- 요청이 전송된 후 응답을 받을 때까지 걸리는 시간.
- 단위: 밀리초(ms).
Throughput(처리량):
- 초당 처리할 수 있는 요청 수(TPS, RPS).
- 단위: 요청/초(Requests Per Second).

📌 반드시 알아야 할 개념:
✅ Latency와 Throughput의 차이
✅ 성능 테스트 지표 (TPS, RPS, P99 Latency)
✅ 부하 테스트(Load Testing) 방법

✅ 20. 컨테이너 환경에서 로깅 및 모니터링 문제

문제 20. 컨테이너 기반 애플리케이션에서 효과적인 로깅 및 모니터링 방법은?

각 컨테이너 내부에서 개별적으로 로그를 저장한다.
중앙 집중형 로깅 시스템을 사용하여 모든 컨테이너의 로그를 수집한다.
컨테이너가 종료되면 로그를 자동으로 삭제한다.
네트워크 트래픽을 분석하지 않고 애플리케이션 로그만 확인한다.

✅ 정답: ② 중앙 집중형 로깅 시스템을 사용하여 모든 컨테이너의 로그를 수집한다.

🔍 해설:

컨테이너 환경에서 로깅 및 모니터링 핵심:
- 로깅:
  - 개별 컨테이너가 아닌 중앙 집중형 로깅 시스템(ELK Stack, Loki, Fluentd) 활용.
- 모니터링:
  - Prometheus, Grafana를 사용하여 리소스 사용량(CPU, Memory, Network)을 실시간 모니터링.

📌 반드시 알아야 할 개념:
✅ 컨테이너 로깅 시스템 (ELK Stack, Loki)
✅ Prometheus & Grafana를 활용한 모니터링
✅ 컨테이너 로그 수집 방식 (Stdout vs. Sidecar)

🔥 고급 QA 개념 요약

📌 이번에 다룬 5가지 핵심 개념

✅ CI/CD에서 자동화 테스트 최적화 (Test Pyramid, 병렬 실행 활용)
✅ OAuth 2.0 보안 (Access Token과 Refresh Token 차이점)
✅ 데이터베이스 트랜잭션 격리 수준 (Read Uncommitted → Dirty Read 가능)
✅ 네트워크 성능 지표 (Latency vs. Throughput 개념 및 차이점)
✅ 컨테이너 환경의 로깅 및 모니터링 전략 (ELK, Prometheus, Grafana 활용)

✅ 21. 테스트 자동화에서 동적 테스트 데이터 문제

문제 21. 자동화 테스트에서 동적 테스트 데이터를 사용하는 가장 효과적인 방법은?

모든 테스트에서 동일한 하드코딩된 데이터를 사용한다.
테스트 실행마다 새로운 데이터를 생성하고 정리하는 방법을 사용한다.
데이터베이스에서 테스트 데이터를 미리 생성한 후 삭제하지 않는다.
사용자 입력 값을 테스트 코드 내에 직접 작성한다.

✅ 정답: ② 테스트 실행마다 새로운 데이터를 생성하고 정리하는 방법을 사용한다.

🔍 해설:

테스트 데이터 관리의 중요성:
- 테스트 실행 간 일관성을 유지하면서 독립적인 테스트 환경을 유지해야 함.
동적 테스트 데이터 관리 방법:
- Setup & Teardown 패턴 적용:
  - 테스트 실행 전(setUp()) 새로운 데이터를 생성.
  - 테스트 실행 후(tearDown()) 데이터를 삭제하여 정리.
- Mocking & Stubbing 활용:
  - 외부 시스템이나 DB에 직접 접근하지 않고, 가상의 데이터를 사용.

📌 반드시 알아야 할 개념:
✅ 동적 테스트 데이터 관리 방법 (Setup & Teardown)
✅ Mocking & Stubbing 개념과 활용 방법
✅ 하드코딩된 테스트 데이터의 문제점

✅ 22. API Rate Limiting에서 Sliding Window 기법 문제

문제 22. API Rate Limiting을 적용할 때 "Sliding Window" 기법의 주요 특징은?

특정 시간 동안 허용된 요청 수를 초과하면 모든 요청을 차단한다.
과거 일정 시간 내 요청 개수를 실시간으로 계산하여 제한을 적용한다.
요청을 받은 순서대로 일정 시간 동안 지연시킨 후 처리한다.
요청이 많아지면 자동으로 서버를 확장하여 처리한다.

✅ 정답: ② 과거 일정 시간 내 요청 개수를 실시간으로 계산하여 제한을 적용한다.

🔍 해설:

Sliding Window 기법의 특징:
- 특정 시간 간격(예: 1분) 동안 허용된 요청 수를 실시간으로 업데이트하여 API 요청을 제한.
- 요청이 일정 간격으로 분포되도록 유도하여 서버 부하를 균등하게 분산.
기존 방법과의 차이:
- Fixed Window: 특정 시간(예: 1분) 동안 요청 개수를 제한 (한계: 윈도우가 갱신될 때 급격한 요청 증가 가능).
- Token Bucket: 일정 속도로 요청을 처리할 수 있도록 제한.

📌 반드시 알아야 할 개념:
✅ API Rate Limiting 기법 (Fixed Window vs. Sliding Window vs. Token Bucket)
✅ Sliding Window의 실무 적용 방식
✅ Rate Limiting이 필요한 이유

✅ 23. 데이터베이스 데드락 문제

문제 23. 데이터베이스에서 데드락(Deadlock)이 발생할 가능성이 높은 상황은?

두 개의 트랜잭션이 동일한 순서로 동일한 리소스를 잠그고 사용한다.
하나의 트랜잭션이 실행 중일 때, 다른 트랜잭션이 기다리지 않고 실행된다.
데이터베이스에서 모든 쿼리를 READ ONLY로 실행한다.
인덱스를 추가하면 데드락이 발생한다.

✅ 정답: ① 두 개의 트랜잭션이 동일한 순서로 동일한 리소스를 잠그고 사용한다.

🔍 해설:

데드락(Deadlock)이란?
- 두 개 이상의 트랜잭션이 서로가 보유한 리소스를 기다리면서 무한정 대기하는 상태.
발생 원인:
- 트랜잭션 A가 리소스 X를 잠근 후, 리소스 Y를 요청.
- 트랜잭션 B가 리소스 Y를 잠근 후, 리소스 X를 요청 → 교착 상태 발생.
해결 방법:
- 트랜잭션이 항상 동일한 순서로 리소스를 잠그도록 강제.
- 트랜잭션 타임아웃을 설정하여 일정 시간이 지나면 강제 해제.

📌 반드시 알아야 할 개념:
✅ 데드락(Deadlock)의 정의와 발생 조건
✅ 데드락 방지 방법 (Lock Ordering, Timeout 설정)
✅ 데이터베이스 트랜잭션 격리 수준과의 관계

✅ 24. 네트워크 성능 테스트에서 P99 Latency 문제

문제 24. 네트워크 성능 테스트에서 "P99 Latency"가 의미하는 것은?

99%의 요청이 특정 응답 시간 내에 처리되는 것을 의미한다.
평균 응답 시간을 의미한다.
최소 응답 시간을 의미한다.
초당 처리할 수 있는 요청 수(TPS)를 의미한다.

✅ 정답: ① 99%의 요청이 특정 응답 시간 내에 처리되는 것을 의미한다.

🔍 해설:

P99 Latency란?
- 99번째 백분위수(Percentile 99) 응답 시간.
- 99%의 요청이 P99 값 이하의 응답 시간 내에 처리되었음을 의미.
성능 평가 시 중요성:
- 평균 응답 시간(Mean Latency)보다 P99 Latency가 실제 사용자 경험을 더 정확하게 반영.
- 예:
  - P50 Latency = 50%의 요청이 이 시간보다 빠르게 처리됨.
  - P99 Latency = 99%의 요청이 이 시간보다 빠르게 처리됨.

📌 반드시 알아야 할 개념:
✅ P50, P90, P99 Latency 개념
✅ 평균 응답 시간 vs. 백분위 응답 시간의 차이
✅ 성능 최적화 시 P99 Latency 고려 방법

✅ 25. 컨테이너 네트워크 모델 문제

문제 25. 컨테이너 기반 애플리케이션에서 "Bridge Network" 모델을 사용하는 이유는?

모든 컨테이너가 같은 네트워크 인터페이스를 공유하도록 설정하기 위해서.
컨테이너 간 격리된 네트워크를 제공하면서도 내부 통신을 가능하게 하기 위해서.
컨테이너가 호스트의 네트워크를 직접 사용하도록 하기 위해서.
컨테이너 간 네트워크 통신을 차단하기 위해서.

✅ 정답: ② 컨테이너 간 격리된 네트워크를 제공하면서도 내부 통신을 가능하게 하기 위해서.

🔍 해설:

Bridge Network란?
- Docker에서 기본적으로 제공하는 컨테이너 간 네트워크 격리 및 내부 통신을 위한 네트워크 모델.
주요 특징:
- 같은 네트워크 내 컨테이너끼리는 통신 가능.
- 외부 네트워크 연결을 원하면 포트 매핑(port mapping) 필요.
다른 네트워크 모델과의 비교:
- Host Network: 컨테이너가 호스트의 네트워크 인터페이스를 직접 사용.
- Overlay Network: 여러 노드(cluster)에서 실행되는 컨테이너 간 통신 지원.

📌 반드시 알아야 할 개념:
✅ Bridge Network, Host Network, Overlay Network 차이
✅ 컨테이너 간 네트워크 통신 방식
✅ 포트 매핑(Port Mapping)과 네트워크 보안 고려 사항

# 추가 CS 지식

🔵 1xx (정보 응답, Informational)

요청이 수락되었으며 처리가 계속 진행 중일 때 사용돼.

100 Continue
클라이언트가 요청 헤더를 전송했고, 서버가 이를 받아들여 본문을 계속 전송하라고 알려줌.
101 Switching Protocols
클라이언트가 프로토콜 변경을 요청했고, 서버가 이를 승인함. (예: HTTP → WebSocket)
102 Processing (WebDAV)
서버가 요청을 처리 중이며 아직 응답을 줄 수 없음을 알림.
103 Early Hints
클라이언트가 캐시된 리소스를 미리 가져오도록 유도하는 상태 코드.

🟢 2xx (성공, Success)

요청이 정상적으로 처리되었음을 의미해.

200 OK
요청이 성공적으로 처리됨. (GET: 데이터 반환, POST: 리소스 생성됨)
201 Created
요청이 성공적으로 처리되었으며, 새로운 리소스가 생성됨.
202 Accepted
요청이 수락되었지만, 처리가 완료되지 않음. (비동기 처리 등)
203 Non-Authoritative Information
요청은 성공했지만, 응답이 원본 서버가 아닌 다른 소스에서 제공됨.
204 No Content
요청은 성공했지만, 응답 본문이 없음. (예: DELETE 요청)
205 Reset Content
클라이언트가 입력 양식을 초기화하도록 지시하는 응답.
206 Partial Content
일부 범위만 반환됨. (예: 파일 다운로드 중 일부만 가져오는 경우)
207 Multi-Status (WebDAV)
여러 개의 상태 코드가 포함될 수 있는 응답.

🟡 3xx (리다이렉션, Redirection)

요청한 리소스가 이동되었거나, 클라이언트가 다른 URL로 이동해야 할 때 사용돼.

300 Multiple Choices
요청에 대해 여러 개의 응답이 가능하며, 클라이언트가 선택해야 함.
301 Moved Permanently
리소스가 영구적으로 이동됨. (SEO에서 중요, 자동 리다이렉션 가능)
302 Found (Temporary Redirect)
리소스가 일시적으로 이동됨. (기존에는 임시 리다이렉션으로 사용되었음)
303 See Other
클라이언트가 다른 URL로 요청해야 함. (예: POST 후 GET으로 이동)
304 Not Modified
클라이언트가 캐시된 버전을 사용할 수 있음.
307 Temporary Redirect
302와 유사하지만, 요청 메서드를 유지해야 함.
308 Permanent Redirect
301과 유사하지만, 요청 메서드를 유지해야 함.

🔴 4xx (클라이언트 오류, Client Error)

클라이언트의 요청이 잘못되었거나 권한이 없을 때 사용돼.

400 Bad Request
요청이 잘못되었거나 서버가 이해할 수 없음.
401 Unauthorized
인증이 필요하지만 제공되지 않음.
402 Payment Required (거의 사용되지 않음)
결제가 필요함.
403 Forbidden
인증은 되었지만, 접근 권한이 없음.
404 Not Found
요청한 리소스를 찾을 수 없음.
405 Method Not Allowed
요청한 HTTP 메서드가 허용되지 않음. (예: GET만 가능한데 POST 요청한 경우)
406 Not Acceptable
클라이언트가 요청한 형식이 지원되지 않음.
407 Proxy Authentication Required
프록시 인증이 필요함.
408 Request Timeout
요청 시간이 초과됨.
409 Conflict
요청이 현재 리소스 상태와 충돌함. (예: 데이터 중복, 동시 수정 충돌)
410 Gone
리소스가 영구적으로 삭제됨. (404와 유사하지만, 삭제된 것이 확실한 경우)
411 Length Required
Content-Length 헤더가 필요함.
412 Precondition Failed
요청이 지정된 조건을 충족하지 못함.
413 Payload Too Large
요청 본문이 서버가 처리하기에는 너무 큼.
414 URI Too Long
요청 URL이 너무 김.
415 Unsupported Media Type
서버가 요청한 콘텐츠 타입을 지원하지 않음.
416 Range Not Satisfiable
요청한 범위가 유효하지 않음.
417 Expectation Failed
Expect 헤더의 요구 조건을 충족할 수 없음.
418 I'm a teapot (농담 코드, RFC 2324)
서버가 찻주전자라서 커피를 끓일 수 없음.
421 Misdirected Request
서버가 해당 요청을 처리할 수 없음.
425 Too Early
서버가 재요청을 받기 전에 응답을 보내기에는 이름.
426 Upgrade Required
클라이언트가 프로토콜을 업그레이드해야 함.
428 Precondition Required
요청에 선행 조건이 필요함.
429 Too Many Requests
클라이언트가 너무 많은 요청을 보냄. (Rate Limiting)
431 Request Header Fields Too Large
요청 헤더가 너무 큼.
451 Unavailable For Legal Reasons
법적 이유로 인해 접근이 제한됨.

⚫ 5xx (서버 오류, Server Error)

서버가 요청을 처리하는 중 오류가 발생했을 때 사용돼.

500 Internal Server Error
서버 내부 오류. (일반적인 서버 에러)
501 Not Implemented
서버가 요청된 기능을 지원하지 않음.
502 Bad Gateway
서버가 다른 서버로부터 잘못된 응답을 받음.
503 Service Unavailable
서버가 과부하 상태이거나 유지보수 중이라 사용 불가능함.
504 Gateway Timeout
서버가 다른 서버로부터 응답을 받지 못함.
505 HTTP Version Not Supported
서버가 요청된 HTTP 버전을 지원하지 않음.
506 Variant Also Negotiates
요청된 콘텐츠 협상이 무한 루프에 빠짐.
507 Insufficient Storage (WebDAV)
서버의 저장 공간이 부족함.
508 Loop Detected (WebDAV)
요청이 무한 루프를 감지함.
510 Not Extended
추가 확장이 필요함.
511 Network Authentication Required
네트워크 인증이 필요함.

# SOAP API

SOAP API는 Simple Object Access Protocol의 약자로, 주로 웹 서비스 간 통신을 위해 사용되는 프로토콜이야. SOAP는 메시지 형식과 통신 규약을 엄격하게 정의하는 구조를 가지고 있어, 보안성과 표준화가 중요한 기업 시스템이나 정부 시스템에서 많이 사용돼.

이제 좀 더 깊이 이해할 수 있도록 하나씩 설명해 줄게.

📌 SOAP API의 특징

XML 기반
- SOAP는 **XML (Extensible Markup Language)**을 사용해 데이터를 전송하고, 구조와 내용을 설명해.
- 모든 데이터가 XML 형식으로 직렬화되기 때문에 다른 플랫폼과 언어 간 호환이 쉬워.
HTTP 또는 다른 전송 프로토콜 사용 가능
- 대부분 HTTP나 HTTPS를 사용하지만, FTP나 SMTP 같은 다른 프로토콜도 사용할 수 있어.
엄격한 표준 및 구조
- SOAP은 W3C (World Wide Web Consortium)에서 표준으로 정의된 프로토콜로, 명확한 메시지 구조가 있어.
- 메시지는 항상 특정한 XML 포맷을 따르며, 잘못된 구조라면 오류가 발생해.
WSDL (Web Service Description Language) 지원
- SOAP은 서비스의 인터페이스를 정의하는 WSDL 파일과 함께 제공돼.
- WSDL은 어떤 기능(메서드)들이 있는지, 어떤 형식의 요청과 응답을 주고받는지 명시하는 역할을 해.

📋 SOAP 메시지 구조

SOAP 메시지는 보통 XML로 작성되고, 네 가지 주요 요소로 구성돼.

xml

복사편집

<soap:Envelope> <soap:Header>   </soap:Header> <soap:Body>  </soap:Body> <soap:Fault>   </soap:Fault> </soap:Envelope>

Envelope: 전체 메시지를 감싸는 루트 요소
Header: 추가 정보(메타데이터, 인증 등)를 포함 (선택적 요소)
Body: 요청 또는 응답 내용을 포함
Fault: 오류나 예외가 발생한 경우 반환되는 오류 정보

✨ SOAP API 예시

🚀 SOAP vs REST 비교

특징SOAPREST

프로토콜	프로토콜 (W3C 표준)	아키텍처 스타일
메시지 형식	XML	JSON, XML, 텍스트 등
전송 프로토콜	HTTP, SMTP, FTP 등 다양	HTTP (GET, POST, PUT, DELETE 등)
보안	높은 보안 (WS-Security 등 지원)	HTTPS 기반 보안
상태 유지	상태 비저장 (Stateless)	상태 유지 및 상태 비저장 모두 가능
속도	상대적으로 느림 (XML 변환으로 인한 오버헤드)	가볍고 빠름
유연성	낮음 (엄격한 구조)	높음 (다양한 데이터 형식 지원)
적용 분야	기업/금융/정부 시스템 등 보안이 중요한 곳	웹 애플리케이션 API
계약(WSDL)	WSDL 파일 필수	계약 없이 자유롭게 사용 가능

📚 SOAP API가 사용되는 곳

은행, 금융 서비스
- 보안이 매우 중요한 곳에서 SOAP은 주로 사용돼.
- WS-Security나 SSL 같은 추가 보안 기능들을 활용할 수 있기 때문이야.
기업 내부 시스템 통합 (Enterprise Application Integration)
- SAP, Oracle 같은 엔터프라이즈 애플리케이션에서는 여전히 SOAP 기반 통신을 많이 사용해.
정부 또는 공공 서비스 API
- 공공 서비스에서는 표준화된 통신 방식이 중요한데, SOAP이 WSDL로 명확히 구조를 정의하기 때문에 사용돼.
레거시 시스템
- 오래된 시스템은 여전히 SOAP 기반으로 동작하는 경우가 많아.

🔍 SOAP의 장점

엄격한 표준으로 인해 안정성과 보안이 높음.
다양한 전송 프로토콜을 지원 (HTTP, SMTP, FTP 등)
WSDL로 인터페이스를 문서화하여 자동화된 클라이언트 생성이 가능
XML 기반으로 플랫폼 독립적으로 동작

⚠️ SOAP의 단점

XML 기반이라 데이터 크기가 커지고 처리 속도가 느림.
REST API에 비해 구현이 복잡하고 유지보수가 어려움.
HTTP 기반 요청에서 메서드(GET, POST 등)를 활용하기 어렵고 비효율적.

💡 정리

SOAP은 엄격한 표준과 보안 요구사항이 중요한 엔터프라이즈 환경에서 여전히 많이 사용돼.
하지만 최근에는 REST API나 GraphQL처럼 더 가볍고 빠른 API 방식이 등장하면서 상대적으로 덜 사용되고 있어.

그래도 금융, 정부 시스템 등에서는 보안과 데이터 무결성이 중요하기 때문에 SOAP이 여전히 강력한 선택이야! 😎
혹시 더 궁금한 점 있으면 물어봐!

데이터베이스 인덱스(Index)란?

**인덱스(Index)**는 데이터베이스에서 검색 속도를 향상시키기 위해 사용되는 자료구조야.
마치 책의 **색인(Index)**처럼, 특정 데이터를 빠르게 찾을 수 있도록 미리 정리된 정보를 저장하는 역할을 해.

📌 인덱스의 핵심 개념

1️⃣ 인덱스 없이 데이터를 검색하는 방법 (Full Table Scan)

일반적으로 데이터베이스에서 특정 데이터를 찾을 때, 모든 데이터를 처음부터 끝까지 검색하는 **"Full Table Scan"**을 수행해.
테이블의 크기가 작을 땐 괜찮지만, 데이터가 많아지면 검색 속도가 느려지는 문제가 발생해.

예시
👉 직원 테이블에서 employee_id = 1004인 데이터를 찾는 경우

`SELECT * FROM employees WHERE employee_id = 1004;`

🔴 (인덱스가 없는 경우)

DB는 employees 테이블의 모든 행을 처음부터 끝까지 검사 (Full Table Scan)
데이터가 많을수록 검색 시간이 오래 걸림

2️⃣ 인덱스를 사용한 검색 방식

인덱스는 데이터의 위치를 미리 정리하여 빠르게 접근할 수 있도록 해주는 자료구조야.
마치 **책의 목차(색인)**처럼, 원하는 페이지(데이터)의 위치를 바로 찾을 수 있어.

예시
📚 책을 읽을 때 인덱스를 사용하면?

"데이터베이스" 관련 내용을 찾을 때, 처음부터 모든 페이지를 읽는 게 아니라 색인에서 "데이터베이스"의 위치를 확인한 후 바로 찾아감.

📌 데이터베이스에서도 비슷한 개념!

특정 컬럼에 인덱스를 생성하면, 해당 컬럼을 검색할 때 Full Table Scan을 피하고, 인덱스를 이용하여 더 빠르게 찾을 수 있어.

`CREATE INDEX idx_employee_id ON employees(employee_id);`

위와 같이 인덱스를 생성하면, employee_id 컬럼을 검색할 때 검색 속도가 훨씬 빨라짐.

🔍 인덱스의 자료구조

데이터베이스 인덱스는 주로 다음과 같은 자료구조를 사용해.

1️⃣ B-Tree (Balanced Tree)

📌 가장 많이 사용하는 인덱스 구조 (MySQL, PostgreSQL, Oracle 등에서 기본적으로 사용)

B-Tree는 균형 트리 구조로 되어 있어, 검색, 삽입, 삭제가 모두 **O(log n)**의 시간 복잡도를 가짐.
루트 노드에서 시작하여 리프 노드까지 내려가면서 데이터를 찾음.

✔ 특징

정렬된 구조라서 범위 검색(RANGE QUERY) 도 빠르게 수행 가능
데이터 삽입/삭제 시 자동으로 균형을 유지
대부분의 관계형 데이터베이스에서 기본 인덱스로 사용됨

✔ 적합한 경우

WHERE 조건에서 특정 값을 검색할 때
ORDER BY, GROUP BY 연산이 많을 때
범위 검색 (BETWEEN, >, < 등)을 수행할 때

2️⃣ Hash Index

📌 해시(Hash) 함수를 이용해 데이터를 빠르게 찾는 방식

검색 속도가 매우 빠르지만, = (같음) 연산에서만 사용 가능
BETWEEN, LIKE 같은 범위 검색에는 적합하지 않음

✔ 적합한 경우

WHERE email = 'test@example.com' 같은 정확한 값 조회
데이터의 범위 검색이 필요하지 않은 경우
MEMORY 엔진에서 사용되는 경우 (MySQL InnoDB는 Hash Index를 지원하지 않음)

❌ 부적합한 경우

BETWEEN, LIKE, ORDER BY 등을 사용할 경우
데이터가 균일하게 분포되지 않으면 성능이 저하됨

🛠 인덱스의 종류

1️⃣ 기본 인덱스 (Primary Index)

기본 키(PRIMARY KEY) 컬럼에 자동으로 생성되는 인덱스
중복을 허용하지 않고, NULL 값을 가질 수 없음

`CREATE TABLE employees ( employee_id INT PRIMARY KEY, name VARCHAR(50) );`

2️⃣ 고유 인덱스 (Unique Index)

특정 컬럼의 값이 중복되지 않도록 보장하는 인덱스

`CREATE UNIQUE INDEX idx_email ON users(email);`

3️⃣ 복합(다중) 인덱스 (Composite Index)

여러 개의 컬럼을 묶어서 하나의 인덱스로 생성

`CREATE INDEX idx_name_age ON employees(name, age);`

WHERE name = 'John' AND age = 30 같은 검색에 최적화됨

4️⃣ 전체 텍스트 인덱스 (Full-Text Index)

대량의 텍스트 데이터를 검색할 때 사용하는 인덱스
MySQL의 FULLTEXT, Elasticsearch 같은 검색 엔진에서 사용됨

`CREATE FULLTEXT INDEX idx_description ON products(description);`

5️⃣ 공간(Spatial) 인덱스

좌표 데이터를 빠르게 검색할 때 사용 (GIS 데이터 처리)

`CREATE SPATIAL INDEX idx_location ON places(location);`

⚠️ 인덱스의 단점

1️⃣ 추가적인 저장 공간 필요

인덱스가 많아질수록 디스크 공간을 많이 차지하게 됨.
특히, 대용량 테이블에서는 인덱스를 신중하게 관리해야 함.

2️⃣ INSERT, UPDATE, DELETE 성능 저하

새로운 데이터를 삽입(INSERT)하거나 수정(UPDATE)하면, 인덱스도 함께 갱신해야 하기 때문에 오버헤드가 발생할 수 있음.
인덱스가 많을수록 쓰기 성능이 저하됨.

3️⃣ 너무 많은 인덱스는 오히려 성능을 저하시킴

모든 컬럼에 인덱스를 생성하면 검색 속도는 빨라질 수 있지만, 데이터 삽입/수정 시 성능이 느려질 수 있음.
자주 조회하는 컬럼에만 인덱스를 설정하는 것이 중요함.

✅ 결론: 언제 인덱스를 사용해야 할까?

✅ 인덱스를 추가하면 좋은 경우

WHERE 조건에서 자주 검색하는 컬럼
ORDER BY, GROUP BY를 자주 사용하는 컬럼
JOIN 연산 시 연결하는 컬럼 (Foreign Key)
BETWEEN, IN 같은 범위 검색을 수행하는 컬럼

❌ 인덱스를 남발하면 안 되는 경우

자주 변경(INSERT/UPDATE/DELETE)되는 컬럼
LOW SELECTIVITY (중복 값이 많은 컬럼, 예: 성별, 국가 코드)
너무 많은 인덱스를 만들면 성능이 오히려 저하될 수 있음

::출처::

https://github.com/VSFe/Tech-Interview?tab=readme-ov-file

https://github.com/WooVictory/Ready-For-Tech-Interview

https://github.com/gyoogle/tech-interview-for-developer

https://github.com/JaeYeopHan/Interview_Question_for_Beginner

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^

COMMENT

« 2025/02 »
일	월	화	수	목	금	토
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28