개념
"다 봤습니다"를 무엇으로 증명하나
새 서비스나 큰 기능을 맡으면 QA에게 같은 질문이 온다.
"다 보신 거죠?"
이때 "네, 다 봤습니다"라고 답하는 것과 "L1부터 L5까지 완료했고, L6은 성능만, L7은 이번 범위에서 제외했습니다" 라고 답하는 것은 완전히 다르다. 후자는 무엇을 안 봤는지까지 말한다. 모듈 4(레슨 5)에서 배운 "QA는 안전하다를 말하는 사람이 아니라 무엇을 알고 무엇을 모르는지 말하는 사람"이 여기서 구체적인 형태를 갖는다.
문제는 점검 항목이 커리큘럼 곳곳에 흩어져 있다는 것이다. 설계 기법은 모듈 3, 접근성은 모듈 16, 보안은 모듈 16, 데이터는 모듈 5. 각각은 배웠는데 하나의 서비스를 앞에 두고 순서대로 훑는 체계 가 없다.
이 레슨은 그 체계를 세운다. 실무에서 쓰이는 형태로 정리하면 7개 계층 이 된다.
7계층 지도
L1 UI 탐색 모든 버튼·메뉴·링크·폼이 동작하는가
↓ (되긴 되는가)
L2 정답 검증 CRUD 정확성, 계산 로직, 표시 값
↓ (맞게 되는가)
L3 권한 검증 비로그인·일반·관리자별 접근 제어
↓ (아무나 되면 안 되는 것이 막히는가)
L4 접근성 키보드 내비게이션, 스크린리더, 색상 대비
↓ (모두가 쓸 수 있는가)
L5 데이터 정합성 DB 반영, 동시 수정, 정렬·필터·페이지네이션
↓ (여러 번·여럿이 써도 맞는가)
L6 비기능 성능(LCP·CLS), 반응형, 다국어, 에러 처리
↓ (조건이 나빠져도 쓸 만한가)
L7 보안 XSS·CSRF·인젝션, 토큰 노출, 세션 관리
(악의를 가진 사람 앞에서도 버티는가)순서에 의미가 있다. 위에서 아래로 갈수록 (1) 발견 비용이 커지고, (2) 앞 계층이 깨져 있으면 뒤 계층을 볼 수 없다.
버튼이 눌리지 않으면(L1) 계산이 맞는지(L2) 확인할 방법이 없다. 계산이 틀렸다면(L2) 동시 수정 시 정합성(L5)을 논하는 것이 무의미하다.
이 구조는 모듈 18b(레슨 8)의 검증 파이프라인, 모듈 18c(레슨 6)의 품질 게이트와 같은 발상이다 — 값싼 검증을 앞에 두고, 통과한 것만 뒤로 보낸다.
L1 — UI 탐색: 되긴 되는가
가장 얕고 가장 먼저 한다. 목표는 "막히는 곳이 없는지" 확인하는 것이다.
| 점검 항목 | 흔한 결함 |
|---|---|
| 모든 버튼·링크가 반응하는가 | 죽은 링크, 이벤트 미연결 |
| 메뉴·탭 이동이 되는가 | 잘못된 경로, 뒤로가기 깨짐 |
| 폼 제출·취소가 되는가 | 제출 후 화면 미갱신 |
| 모달·드롭다운이 열리고 닫히는가 | ESC·바깥 클릭으로 안 닫힘 |
| 빈 상태·로딩 상태가 있는가 | 데이터 없을 때 빈 화면 |
L1의 함정은 여기서 멈추는 것이다. 클릭이 되면 통과로 표시하고 넘어가는 팀이 많은데, 그건 "동작한다"이지 "맞다"가 아니다. 그래서 L2가 있다.
L1은 자동화하기 좋은 계층이기도 하다. 스모크 테스트(모듈 11 레슨 2)가 대체로 이 계층이다.
L2 — 정답 검증: 맞게 되는가
여기부터가 QA의 본령이다. 모듈 3에서 배운 설계 기법이 전부 여기에 쓰인다.
| 점검 항목 | 적용할 기법 |
|---|---|
| 생성·조회·수정·삭제가 정확한가 | 상태 전이(모듈 3 레슨 3) |
| 계산 결과가 맞는가 | 경계값 분석(레슨 1), 결정 테이블(레슨 3) |
| 표시 값이 저장 값과 같은가 | 단위·형식·반올림 확인 |
| 필수·선택 입력 검증이 맞는가 | 동등분할(레슨 1) |
| 조합 규칙이 맞는가 | 페어와이즈(레슨 5) |
계산 로직에서 자주 나오는 결함 유형 을 기억해두면 좋다.
- 반올림 방향과 자릿수 (할인 금액 1원 차이)
- 순서 의존 (할인 먼저인가 세금 먼저인가)
- 0과 음수 (수량 0, 할인율 100%)
- 통화·단위 혼용
- 시간대와 날짜 경계 (자정, 월말, 윤년)
마지막 항목이 특히 자주 묻힌다. "어제 주문"의 기준 시각이 서버 시간인지 사용자 시간인지 를 확인하지 않으면 특정 시간대 사용자에게만 틀린다.
L3 — 권한 검증: 아무나 되면 안 되는 것
QA가 가장 자주 빠뜨리는 계층 이다. 화면에서 안 보이면 테스트하지 않게 되기 때문이다.
기본 매트릭스를 만들어두면 놓치지 않는다.
비로그인 일반 사용자 타인 소유 관리자
목록 조회 ✕ ○ — ○
상세 조회 ✕ ○ ✕ ○
생성 ✕ ○ — ○
수정 ✕ ○ ✕ ○
삭제 ✕ ✕ ✕ ○
관리 기능 ✕ ✕ ✕ ○'타인 소유' 열이 핵심이다. 내 주문은 볼 수 있지만 남의 주문은 안 돼야 한다. 그런데 화면에는 남의 주문으로 가는 링크가 없으니 테스트하지 않게 된다.
확인 방법은 모듈 9(레슨 12)와 모듈 19(레슨 4)에서 배운 도구다.
- URL의 ID를 바꿔본다 (
/orders/1234→/orders/1235) - API를 직접 호출한다 (DevTools에서 복사한 cURL의 ID만 변경)
- 프록시 브레이크포인트로 요청 본문의 ID를 바꾼다
기대 결과는 403이지 404가 아니다 — 다만 존재 여부를 숨겨야 하는 경우에는 404가 정책일 수 있다. 정책을 먼저 확인하고 테스트한다.
권한이 화면에서만 막혀 있고 API는 열려 있는 경우가 실제로 흔하다. "버튼을 안 보이게 했으니 됐다"는 방어가 아니다.
L4 — 접근성: 모두가 쓸 수 있는가
모듈 16(레슨 7)에서 다룬 내용이 여기에 배치된다. 최소 점검은 셋이다.
| 항목 | 확인 방법 |
|---|---|
| 키보드만으로 조작 가능한가 | 마우스를 치우고 Tab·Enter·ESC로 전 과정 수행 |
| 포커스가 보이는가 | Tab 이동 시 현재 위치가 시각적으로 표시되는가 |
| 스크린리더가 읽는가 | 이미지 대체 텍스트, 버튼 이름, 폼 라벨 |
| 색상 대비가 충분한가 | DevTools Elements 패널에서 대비 확인(모듈 9 레슨 12) |
| 색만으로 정보를 전달하지 않는가 | 오류를 빨간색으로만 표시하고 있지 않은가 |
키보드 테스트가 가장 값싸고 효과가 크다. 마우스를 옆으로 치우고 주요 흐름을 한 번 수행해보면, 모달에 갇히거나(포커스 트랩) 포커스가 사라지는 문제가 금방 드러난다.
마지막 항목은 모듈 22(레슨 10)에서 다이어그램을 그릴 때도 나온 원칙이다 — 색은 보조 수단이고, 텍스트나 아이콘으로 한 번 더 말해야 한다.
L5 — 데이터 정합성: 여러 번·여럿이 써도 맞는가
L2가 한 번의 정확성을 봤다면, L5는 반복과 동시성 을 본다.
| 항목 | 확인할 것 |
|---|---|
| 화면 값과 DB 값이 같은가 | 저장 후 DB에서 직접 조회(모듈 9 레슨 5의 SQL) |
| 새로고침 후에도 유지되는가 | 캐시된 화면과 실제 상태의 불일치 |
| 동시 수정 | 두 탭에서 같은 항목을 수정하면? 나중 것이 앞 것을 덮는가 |
| 정렬 | 동점일 때 순서가 안정적인가, null은 어디로 가는가 |
| 필터 조합 | 필터 2개를 걸면 AND인가 OR인가, 초기화가 되는가 |
| 페이지네이션 | 0건, 1건, 마지막 페이지, 범위 밖 페이지 |
| 페이지 이동 중 데이터 변경 | 2페이지 보는 중 1페이지에 항목이 추가되면 중복·누락이 생기는가 |
마지막 두 줄이 실무에서 자주 터지는데 거의 테스트되지 않는다. 정렬 기준이 불안정하면 페이지를 넘길 때 같은 항목이 두 번 보이거나 아예 안 보인다. 모듈 12(레슨 8)에서 API 커버리지의 페이지네이션 경계를 다룬 것과 같은 문제가 화면에서 나타나는 형태다.
동시 수정은 모듈 19(레슨 4)의 프록시 Repeat Advanced로 재현할 수 있다.
L6 — 비기능: 조건이 나빠져도 쓸 만한가
모듈 16 전체가 이 계층이다. 여기서는 최소 점검 세트 만 정리한다.
| 영역 | 최소 점검 |
|---|---|
| 성능 | LCP·CLS 등 Core Web Vitals(모듈 16 레슨 4), 느린 네트워크 재현(모듈 9 레슨 12) |
| 반응형 | 모바일·태블릿·데스크톱 폭에서 깨지지 않는가, 가로 스크롤이 생기지 않는가 |
| 다국어 | 긴 번역문에서 레이아웃이 깨지는가, 미번역 문구가 남았는가, 날짜·통화·숫자 형식 |
| 에러 처리 | 서버 오류·네트워크 끊김 시 안내가 뜨는가, 복구 경로가 있는가 |
다국어는 QA가 놓치기 쉬운 영역이다. 한국어 기준으로 만든 화면에 독일어를 넣으면 버튼 텍스트가 두 배로 길어져 레이아웃이 깨진다. 그리고 미번역 문구는 개발자가 절대 못 찾는다 — 그 언어를 모르기 때문이다.
에러 처리도 마찬가지다. 모듈 19(레슨 4)의 Map Local이나 브레이크포인트로 500 응답을 만들어보면, 화면이 아무 반응 없이 멈추는 경우가 흔하다.
L7 — 보안: 악의를 가진 사람 앞에서
모듈 16(레슨 5·10)에서 다룬 내용이다. QA가 직접 할 수 있는 최소 점검은 이렇다.
| 항목 | 확인 방법 |
|---|---|
| XSS | 입력란에 스크립트 문자열을 넣고 저장 후 표시되는 곳을 본다 |
| CSRF | 상태 변경 요청에 토큰이 있는가, 없이 보내면 거부되는가 |
| 인젝션 | 특수문자 입력 시 오류 메시지에 쿼리가 노출되는가 |
| 토큰 노출 | 로컬스토리지·URL·로그에 토큰이 있는가(모듈 9 레슨 12) |
| 세션 관리 | 로그아웃 후 뒤로가기, 만료 처리, 다른 기기 로그인 |
| 오류 메시지 | 스택 트레이스·내부 경로·버전 정보가 노출되는가 |
"QA가 침투 테스트를 하라"는 뜻이 아니다. 이 목록은 전문가가 아니어도 발견할 수 있는 것들 이고, 여기서 걸리면 더 깊은 문제가 있을 가능성이 높다는 신호다. 깊은 진단은 전문 도구와 전문가의 몫이다(모듈 23).
⚠️ 보안 점검은 허가된 환경에서만 한다. 대상과 범위를 문서로 확인하고 시작한다. 모듈 16 전체를 관통하는 원칙이다.
어디까지 내려갈 것인가 — 변경 규모로 판단
7계층을 매번 전부 도는 것은 불가능하다. 모듈 4(레슨 3)에서 배운 변경 규모별 커버리지 계획 을 여기에 적용한다.
| 변경 유형 | 도는 계층 | 근거 |
|---|---|---|
| 문구·색상 수정 | L1 + L4(대비) | 로직이 안 바뀐다 |
| 화면 레이아웃 변경 | L1, L4, L6(반응형) | 표시 계층만 |
| 기능 로직 수정 | L1~L3, L5 | 계산·권한·데이터가 영향 |
| 신규 기능 | L1~L7 전부 | 기준선이 없다 |
| 권한 구조 변경 | L3 집중 + L1, L2 | 매트릭스 전면 재점검 |
| DB 스키마 변경 | L2, L5 집중 + 마이그레이션 검증(레슨 6) | 데이터가 핵심 |
| 인증·결제 관련 | L1~L7 + 전문 진단 | 사고 비용이 크다 |
| 라이브러리 업그레이드 | L1 + L6 + L7(취약점) | 광범위·간접 영향 |
"신규 기능은 전부"와 "인증·결제는 전문 진단까지" 두 줄만 지켜도 큰 사고의 상당수를 막는다. 나머지는 리스크(모듈 4 레슨 2)로 조정한다.
계층별 배분의 함정
함정 1 — L1에서 멈춘다. 시간이 부족하면 L1만 반복하게 된다. 그런데 L1은 자동화하기 가장 쉬운 계층이다. 자동화로 L1을 덮고 사람은 L2 아래로 내려가는 것 이 올바른 방향이다.
함정 2 — L3을 건너뛴다. 화면에 없으면 테스트하지 않게 된다. 권한 매트릭스를 문서로 만들어두는 것이 유일한 방어다.
함정 3 — L4·L6을 "여유 있으면"으로 미룬다. 그리고 여유는 오지 않는다. 접근성은 법적 요구가 되어가고(모듈 25), 성능은 이탈률과 직결된다. 최소 점검만이라도 매번 넣는다.
함정 4 — L7을 외부에만 맡긴다. 연 1회 침투 테스트로는 매 릴리즈의 변경을 못 따라간다. QA의 최소 점검이 그 사이를 메운다.
함정 5 — 계층을 순서대로만 본다. 순서는 게이트이지 일정이 아니다. L7의 토큰 노출 같은 항목은 개발 초기에 확인하는 편이 훨씬 싸다.
체크리스트로 만들어 쓰기
이 체계의 값어치는 매번 같은 순서로 훑는다 는 데 있다. 기능마다 표를 하나 만들어두면 인수인계와 리포트가 함께 해결된다.
기능: 쿠폰 적용 릴리즈: v2.4.0 점검자: OOO
L1 UI 탐색 ✅ 완료 (자동화 스모크 통과)
L2 정답 검증 ✅ 완료 경계값 12건, 결함 2건 등록
L3 권한 검증 ⚠️ 부분 타인 쿠폰 조회 미확인 — 환경 제약
L4 접근성 ✅ 완료 키보드 전 과정 통과, 대비 1건 지적
L5 데이터 정합성 ✅ 완료 동시 적용 테스트 포함
L6 비기능 ⚠️ 부분 성능만, 다국어 미확인(이번 범위 아님)
L7 보안 ✅ 완료 XSS·토큰 노출 최소 점검 통과
미확인 항목과 사유가 위에 명시됨 → Go/No-Go 자료로 그대로 사용⚠️ 표시와 사유가 이 표의 핵심이다. 전부 ✅인 표는 의심스럽고, 미확인 항목이 사유와 함께 적힌 표는 신뢰할 수 있다. 모듈 4(레슨 5)의 Go/No-Go 회의에 이 표 한 장을 가져가면 논의가 정리된다.
실무에서 왜 필요한가
QA 경력이 쌓여도 "무엇을 봐야 하는지"를 매번 새로 떠올리는 사람이 많다. 그러면 컨디션과 시간에 따라 점검 범위가 흔들리고, 놓친 영역이 매번 달라진다. 체계가 있으면 최소한 같은 것을 놓치지는 않는다.
신규 입사자나 주니어에게 넘길 때도 값이 크다. "잘 봐주세요"가 아니라 7계층 표를 주면, 무엇을 어디까지 해야 하는지가 명확해진다. 모듈 7 (레슨 9)에서 다룬 팀 역량 관리와도 이어진다 — 개인의 감각을 팀의 절차로 옮기는 방법 이다.
그리고 이 표는 QA의 일을 보이게 만든다. "테스트했습니다"가 아니라 "7개 계층 중 5개 완료, 2개는 이런 사유로 부분 완료"라고 말할 수 있으면 작업량과 판단 근거가 함께 전달된다.
채용시장에서의 위치
면접에서 "테스트 범위를 어떻게 정하세요" 는 거의 반드시 나온다. 이 질문에 계층 이름으로 답할 수 있는 사람과 "중요한 것부터 봅니다" 로 답하는 사람의 차이가 크다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "테스트 범위를 어떻게 정하세요?" | "중요한 것부터요" | "7계층으로 세우고, 변경 규모에 따라 어디까지 내려갈지 정합니다" |
| "다 봤다는 걸 어떻게 보고하세요?" | "테스트 완료로 올립니다" | "7계층 중 5개 완료, 2개는 사유와 함께 부분 완료로 적습니다" |
| "주니어에게 어떻게 넘기세요?" | "같이 보면서 알려줍니다" | "계층표를 주고 L1~L3을 맡깁니다. 기준이 문서에 있으니 편차가 줄어듭니다" |
| "권한 테스트는 하세요?" | "역할별로 들어가 봅니다" | "권한 매트릭스를 만들고 URL 직접 호출·API 직접 호출까지 뚫어 봅니다" |
두 번째가 실무자와 리드를 가르는 답이다. "완료" 는 정보가 없고, "못 한 것을 사유와 함께 적은 보고" 는 판단 근거가 된다. 레슨 6의 전환 검증 보고와 같은 태도다.
네 번째는 의외로 변별력이 크다. 화면에서 메뉴가 안 보이는 것을 권한 테스트로 아는 경우가 많은데, 실제 사고는 URL과 API를 직접 두드릴 때 난다. 이 차이를 말할 수 있으면 L3을 제대로 해 본 사람으로 읽힌다.
공고 표현으로는 "테스트 설계", "테스트 범위 산정", "품질 기준 수립" 이 이 레슨에 걸린다. 그리고 계층표를 팀에 도입해 운영한 경험은 리드· 매니저 지원에서 바로 쓸 수 있는 이야기다 — 개인의 감각을 팀의 절차로 옮긴 사례이기 때문이다.