개념
화면 값이 이상하면 데이터부터 확인한다
모듈 5(레슨 7)에서 배운 "데이터 따라가기"를 떠올려보자 — 화면에 표시된 값이 실제로 데이터베이스에 저장된 값과 같은지 확인하려면, 데이터베이스를 직접 조회할 수 있어야 한다. SQL(Structured Query Language)은 이 조회를 위한 언어다.
SELECT — 데이터 조회하기
SELECT name, email FROM users;users 테이블에서 name과 email 컬럼(열)을 전부 가져온다. 테이블은
스프레드시트와 비슷하다 — 행(row)이 하나의 데이터(예: 사용자 한
명), 열(column)이 그 데이터의 속성(이름, 이메일)이다.
WHERE — 조건으로 걸러내기
SELECT name, email FROM users WHERE membership_level = 'VIP';"VIP 등급인 사용자만" 걸러서 가져온다. 레슨 1에서 배운 조건문 개념과 정확히 같은 역할이다.
SELECT * FROM orders WHERE created_at >= '2026-08-01' AND status = 'cancelled';"8월 1일 이후 생성됐고 취소된 주문"처럼 조건을 여러 개 조합할 수도 있다.
JOIN — 여러 테이블 연결하기
실무 데이터베이스는 정보가 여러 테이블에 나뉘어 저장된다. 예를 들어
users(사용자)와 orders(주문)가 따로 있고, 주문에는 "이 주문을
한 사용자의 id"만 저장되어 있다. JOIN은 이 두 테이블을 연결해서
같이 조회하는 방법이다.
SELECT users.name, orders.total_price
FROM orders
JOIN users ON orders.user_id = users.id
WHERE orders.status = 'cancelled';"취소된 주문을 한 사용자의 이름과 주문 금액"을 두 테이블을 이어서 가져온다. 모듈 5(레슨 7)에서 배운 개체 간 관계(사용자 ↔ 주문)가 바로 이 JOIN으로 실제 구현되어 있는 것이다.
자주 쓰는 조합 패턴
-- 개수 세기
SELECT COUNT(*) FROM orders WHERE status = 'cancelled';
-- 정렬해서 최근 것부터 보기
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10;이 두 패턴만 알아도, "취소된 주문이 몇 건이나 되는지", "가장 최근 주문 10건이 뭔지"를 화면 없이 직접 확인할 수 있다.
읽기 전용으로 접근하는 것이 원칙
QA가 데이터베이스에 직접 접근할 때는, 원칙적으로 조회(SELECT)만 하고 데이터를 수정·삭제하는 쿼리는 실행하지 않는다 — 잘못된 UPDATE나 DELETE 한 번이 운영 데이터를 망가뜨릴 수 있다. 데이터를 바꿔야 할 필요가 있으면 반드시 승인된 절차와 스테이징 환경(모듈 7 레슨 3)에서 진행한다.
실무에서 왜 필요한가
"할인이 적용 안 됐다는데, 실제로 DB에 쿠폰 사용 이력이 남았는지 확인해볼게요"라고 QA가 직접 확인할 수 있으면, 화면 재현만으로는 안 보이는 문제(예: 화면은 정상인데 저장이 잘못된 경우)를 훨씬 빠르게 짚어낼 수 있다. 결함 리포트(모듈 6 레슨 2)에 "DB 조회 결과 이 값이 null로 저장되어 있음"처럼 증거를 남길 수 있으면 신뢰도가 크게 올라간다.