카테고리 없음

데이터 직무 면접 질문: SQL/지표/가설 검증 질문 모음

myinfo5886 2026. 3. 27.

데이터 직무 면접 질문: SQL/지표/가설 검증 질문 모음

데이터 직무 면접을 준비하다 보면 생각보다 막막해지는 순간이 있습니다.
분명 SQL도 공부했고, 지표도 어느 정도 아는데 막상 면접 질문 앞에 서면 머리가 하얘지죠. 특히 “이 쿼리 왜 이렇게 짰나요?”, “좋은 지표란 뭐라고 생각하나요?”, “이 결과가 유의미하다고 어떻게 판단하죠?” 같은 질문은 단순 암기만으로는 답하기 어렵습니다.

저도 많은 지원자들이 준비하는 과정을 보면 비슷한 패턴을 자주 봤습니다.
SELECT, JOIN, GROUP BY는 익숙한데, 실제 면접에서는 그것만 묻지 않습니다. 면접관은 결국 이 사람이 데이터를 통해 문제를 정의하고, 정확하게 해석하고, 실무적으로 판단할 수 있는 사람인가를 확인하고 싶어합니다.

그래서 이번 글은 단순한 sql 면접 질문 모음에서 끝나지 않도록 구성했습니다.
SQL 면접 질문 + 데이터베이스 질문 + 데이터베이스 면접질문 + 데이터 직무 면접 흐름을 하나로 묶어서, 실제 면접에서 자주 나오는 질문과 답변 방향, 그리고 말하는 방식까지 정리해보겠습니다.

먼저 알아두면 좋은 점: 데이터 면접은 “코딩 테스트”가 아니라 “사고력 테스트”에 가깝다

많은 분들이 데이터 직무 면접을 준비하면서 SQL 문제집부터 펼칩니다. 물론 맞는 접근입니다. 하지만 면접 현장에서는 문제를 푸는 속도보다 더 중요한 것이 있습니다.

바로 아래 3가지입니다.

1. 데이터를 어떻게 정의하는가
2. 지표를 어떻게 해석하는가
3. 결과를 얼마나 조심스럽고 논리적으로 검증하는가

예를 들어 면접관이 “구매 전환율이 떨어졌습니다. 어떻게 보시겠어요?”라고 물으면,
좋은 답변은 단순히 “쿼리로 봐야 합니다”가 아닙니다.

조금 더 좋은 답변은 이런 식입니다.

“먼저 구매 전환율의 정의를 확인하겠습니다. 방문 대비 구매인지, 장바구니 진입 대비 구매인지에 따라 해석이 달라질 수 있습니다. 이후 유입 채널, 디바이스, 신규/기존 사용자별로 세분화해서 어디에서 하락했는지 보겠습니다. 그 다음 변경된 기능, 마케팅 집행, 트래픽 품질 변화 같은 원인을 가설로 두고 검증하겠습니다.”

이 답변에는 SQL도 들어 있고, 지표 이해도도 있고, 가설 검증 관점도 들어 있습니다.
즉, 데이터 직무 면접은 도구보다 사고의 구조를 본다는 점을 기억해두면 좋습니다.

데이터 직무 면접에서 자주 나오는 질문 유형

면접 질문은 대체로 아래 네 갈래로 나뉩니다.

구분	면접관이 보고 싶은 것	자주 나오는 질문
SQL	데이터 추출 및 가공 능력	JOIN, GROUP BY, 서브쿼리, 윈도우 함수
데이터베이스	데이터 구조 이해	정규화, 인덱스, PK/FK, 트랜잭션
지표 설계/해석	비즈니스 감각	핵심 KPI, 퍼널, 리텐션, 코호트
가설 검증	분석적 사고	A/B 테스트, 유의성, 편향, 인과 해석

이 네 가지는 따로 떨어져 있지 않습니다.
실무에서는 보통 이런 흐름으로 이어집니다.

데이터베이스 구조 이해 → SQL로 추출 → 지표 계산 → 이상 징후 발견 → 가설 수립 → 검증

그래서 면접 준비도 따로따로 하지 말고, 이 흐름으로 묶어서 준비하는 게 훨씬 효율적입니다.

SQL 면접 질문에서 가장 자주 나오는 핵심 주제

SQL 질문은 거의 모든 데이터 직무 면접에서 등장합니다.
다만 수준은 조금씩 다릅니다.

데이터 분석가: 집계, 퍼널, 리텐션, 조건 분기, 윈도우 함수 비중이 큼
BI/데이터 애널리스트: 지표 산출 정확도와 쿼리 가독성 비중이 큼
데이터 엔지니어: 성능, 파이프라인, 데이터 모델링 연계 질문이 많음
프로덕트 분석가: 이벤트 로그 기반 지표 계산, 실험 분석이 자주 나옴

아래부터는 실제로 많이 나오는 sql 면접 질문을 주제별로 정리해보겠습니다.

SQL 면접 질문 1: JOIN을 설명해보세요

이 질문은 너무 기본 같지만, 의외로 여기서 실력이 갈립니다.

면접관이 확인하는 포인트

JOIN 종류를 아는가
어떤 상황에서 어떤 JOIN을 쓰는가
중복 행이 왜 생기는지 이해하는가
데이터 누락 가능성을 고려하는가

자주 나오는 꼬리 질문

INNER JOIN과 LEFT JOIN 차이는?
1:N 관계에서 JOIN 시 row가 늘어나는 이유는?
JOIN 후 집계값이 이상하게 커졌다면 어디를 의심할 건가요?
여러 테이블을 JOIN할 때 주의할 점은?

답변 예시

INNER JOIN은 양쪽 테이블에 모두 매칭되는 행만 남기고, LEFT JOIN은 왼쪽 테이블 기준으로 모든 행을 유지하면서 오른쪽 매칭값이 없으면 NULL로 채웁니다.
실무에서는 누락 없이 기준 모수를 유지해야 할 때 LEFT JOIN을 자주 사용합니다.
특히 1:N 관계에서 JOIN하면 중복으로 인해 집계값이 부풀 수 있기 때문에, JOIN 전에 grain을 맞추거나 사전 집계를 고려합니다.

여기서 중요한 건 단순 정의가 아니라 grain(행의 단위) 개념을 함께 말하는 것입니다.
이 한마디가 들어가면 훨씬 실무형 답변처럼 보입니다.

SQL 면접 질문 2: GROUP BY와 집계 함수 사용 시 주의점은 무엇인가요?

이 질문은 기초처럼 보이지만 실제 면접에서는 아주 자주 등장합니다.

핵심 포인트

SELECT에 집계되지 않은 컬럼은 GROUP BY에 포함되어야 함
집계 전/후 필터링 차이를 알아야 함
COUNT(*)와 COUNT(column)의 차이를 알아야 함
DISTINCT의 의미를 정확히 이해해야 함

많이 나오는 질문

WHERE와 HAVING 차이는?
COUNT(*)와 COUNT(1)은 차이가 있나요?
COUNT(column)은 언제 다르게 동작하나요?
중복 사용자를 세려면 COUNT(*)로 하면 되나요?

답변 예시

WHERE는 집계 전에 행을 필터링하고, HAVING은 GROUP BY 이후 집계 결과를 필터링합니다.
예를 들어 사용자별 구매 건수를 계산한 뒤 구매 2건 이상 사용자만 보고 싶다면 HAVING을 써야 합니다.
또 COUNT(column)은 NULL을 제외하기 때문에 데이터 누락 여부를 판단할 때 COUNT(*)와 결과가 달라질 수 있습니다.

이 부분은 면접관이 정확성에 민감한 사람인지를 보는 포인트이기도 합니다.

SQL 면접 질문 3: 서브쿼리와 CTE는 어떻게 다르게 쓰나요?

실무에서는 CTE(Common Table Expression)를 많이 쓰기 때문에 자주 묻습니다.

답변 방향

둘 다 중간 결과를 만들 수 있음
CTE는 가독성이 좋고 단계별 로직 설명에 유리함
성능은 DBMS마다 다를 수 있으므로 절대적으로 말하면 위험함
복잡한 분석 로직은 CTE로 나누면 유지보수성이 좋아짐

답변 예시

서브쿼리는 한 번에 로직을 넣을 수 있지만 중첩이 많아지면 읽기 어려워질 수 있습니다.
CTE는 분석 과정을 단계별로 나눌 수 있어 가독성과 디버깅에 유리합니다.
다만 성능은 엔진 최적화 방식에 따라 다를 수 있어서, 무조건 CTE가 빠르다거나 느리다고 단정하진 않습니다.

이런 답변은 현실적인 태도가 보여서 좋습니다.
실무자는 보통 “무조건”이라는 표현을 조심하거든요.

SQL 면접 질문 4: 윈도우 함수는 언제 사용하나요?

이 질문은 데이터 분석가 면접에서 꽤 자주 나옵니다.

자주 언급되는 함수

ROW_NUMBER()
RANK(), DENSE_RANK()
SUM() OVER()
AVG() OVER()
LAG(), LEAD()

대표적인 활용 예시

사용자별 첫 구매 찾기
날짜 순서로 이전 행동과 비교
누적합 계산
카테고리별 순위 산정
세션 흐름 분석

답변 예시

윈도우 함수는 행을 유지한 채로 집계나 순위를 계산할 수 있다는 점이 장점입니다.
예를 들어 사용자별 첫 구매일을 찾을 때 ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY order_date)를 사용하면 각 사용자 내 첫 행을 쉽게 식별할 수 있습니다.
단순 GROUP BY와 달리 원본 행을 유지하면서 비교가 가능해서 퍼널 분석이나 리텐션 분석에서도 유용합니다.

면접에서 윈도우 함수를 설명할 때는 “행을 유지한다”는 표현을 꼭 넣어보세요.
이 문장 하나가 개념 이해도를 또렷하게 보여줍니다.

SQL 면접 질문 5: 중복 데이터가 있을 때 어떻게 처리하겠습니까?

실무형 질문으로 자주 나옵니다.

면접관이 보고 싶은 것

중복의 정의를 먼저 확인하는가
진짜 중복인지, 여러 이벤트가 정상적으로 쌓인 건지 구분하는가
비즈니스 로직에 맞게 제거 기준을 세우는가

좋은 답변의 구조

중복 기준 정의
발생 원인 파악
제거 또는 보정 전략 설계
영향도 확인

답변 예시

중복 여부는 우선 키 기준으로 정의해야 합니다.
예를 들어 user_id + event_time + event_type가 같은 것이 중복인지, 혹은 주문번호 단위로 봐야 하는지 먼저 확인하겠습니다.
이후 로그 수집 지연, 재전송, JOIN 중복 같은 원인을 나눠서 보고, 제거 시에는 최신값 유지 또는 최초값 유지 같은 정책을 명확히 두겠습니다.
마지막으로 중복 제거 전후 지표 차이를 확인해 영향도를 보겠습니다.

이 답변은 단순 기술 문제를 넘어서 데이터 품질 관점이 있다는 인상을 줍니다.

실무형 SQL 질문 예시 모음

아래 질문들은 실제 면접 과제나 라이브 코딩, 구두 면접에서 모두 자주 나옵니다.

자주 나오는 SQL 문제 유형

유형	질문 예시	확인 포인트
기초 집계	일자별 가입자 수를 구하세요	날짜 처리, GROUP BY
조건 집계	결제 사용자 수와 비결제 사용자 수를 나누어 구하세요	CASE WHEN
퍼널 분석	방문→장바구니→결제 전환율을 구하세요	이벤트 정의, 중복 제거
리텐션	가입 주차 기준 2주차 리텐션을 계산하세요	코호트 개념
첫 행동 분석	사용자별 첫 구매 카테고리를 구하세요	윈도우 함수
Top N	카테고리별 매출 상위 3개 상품을 구하세요	RANK/DENSE_RANK
이상 탐지	전주 대비 급감한 상품군을 찾으세요	비교 집계, 시계열

면접에서 자주 쓰이는 말하기 패턴

문제를 듣자마자 바로 쿼리를 말하는 것보다, 먼저 이런 식으로 정리하면 좋습니다.

“먼저 결과 테이블의 단위를 사용자 기준으로 볼지, 주문 기준으로 볼지 확인하겠습니다.”
“이 문제는 이벤트 로그 기반이라 중복 이벤트 제거 기준을 먼저 잡겠습니다.”
“지표 정의를 고정한 뒤 CTE로 단계별 집계하겠습니다.”

이런 표현은 쿼리 실력뿐 아니라 문제 정의 능력도 함께 보여줍니다.

데이터베이스 질문에서 자주 나오는 주제

데이터베이스 질문, 데이터베이스 면접질문은 SQL과 달리 조금 덜 익숙하게 느껴질 수 있습니다.
하지만 데이터 직무 면접에서는 꽤 중요합니다. 이유는 간단합니다. 데이터를 추출하는 사람이라면 데이터가 어떻게 저장되고 연결되는지도 이해해야 하기 때문입니다.

데이터베이스 면접질문 1: 정규화란 무엇인가요?

핵심 요약

정규화는 데이터 중복을 줄이고 이상 현상을 방지하기 위해 테이블 구조를 체계화하는 과정입니다.

면접에서 말하면 좋은 포인트

삽입 이상, 수정 이상, 삭제 이상을 줄이기 위함
보통 실무에서는 정규화와 성능 사이 균형을 잡음
분석용 환경에서는 경우에 따라 비정규화도 많이 사용

답변 예시

정규화는 중복 데이터를 최소화하고 데이터 일관성을 유지하기 위한 설계 방식입니다.
다만 실무에서는 조회 성능이나 분석 편의성을 위해 일부 비정규화를 선택하기도 합니다.
예를 들어 운영계 DB는 정규화가 중요하지만, 분석용 데이터마트는 조인 비용을 줄이기 위해 비정규화된 형태를 사용할 수 있습니다.

이런 식으로 말하면 단순 이론 암기가 아니라 실무 적용 감각이 보입니다.

데이터베이스 면접질문 2: 인덱스란 무엇이고 왜 필요한가요?

이 질문은 데이터베이스 이해도를 묻는 대표 질문입니다.

핵심 포인트

조회 성능 향상을 위한 자료 구조
테이블 전체 스캔을 줄여줌
하지만 인덱스가 많으면 쓰기 성능 저하 가능
어떤 컬럼에 걸어야 하는지 판단이 중요

답변 예시

인덱스는 특정 컬럼을 기준으로 데이터를 빠르게 찾도록 도와주는 구조입니다.
조회 성능에는 유리하지만 인덱스를 유지해야 하므로 INSERT, UPDATE, DELETE 비용이 커질 수 있습니다.
따라서 자주 조회 조건에 사용되거나 조인 키로 많이 쓰이는 컬럼에 우선적으로 고려합니다.

추가로 면접에서 여유가 있으면 이런 말도 좋습니다.

“선택도가 높은 컬럼인지도 함께 보겠습니다.”

이 표현은 꽤 인상적입니다.

데이터베이스 면접질문 3: PK와 FK를 설명해보세요

이건 기본이지만 결코 가볍지 않습니다.

답변 포인트

PK: 각 행을 유일하게 식별
FK: 다른 테이블의 PK를 참조
테이블 간 관계와 무결성 유지에 중요

답변 예시

Primary Key는 테이블 내 각 레코드를 유일하게 식별하는 키이고, Foreign Key는 다른 테이블의 키를 참조해 관계를 연결합니다.
이를 통해 데이터 무결성을 유지할 수 있고, 분석 시에도 어떤 테이블이 기준 테이블인지 파악하는 데 도움이 됩니다.

여기서 끝내지 말고, 분석 직무답게 한 문장 더 붙이면 좋습니다.

“다만 로그성 테이블은 완전한 FK 제약 대신 애플리케이션 레벨에서 관리되는 경우도 있어서, 실제 스키마를 보고 판단하겠습니다.”

이 한마디가 참 실무적입니다.

데이터베이스 면접질문 4: 트랜잭션과 ACID를 설명해보세요

분석 직무에서도 간혹 나옵니다. 특히 결제, 주문, 정산 데이터가 있는 서비스라면 더 자주 묻습니다.

핵심 정리

트랜잭션: 하나의 논리적 작업 단위
ACID:
- Atomicity(원자성)
- Consistency(일관성)
- Isolation(격리성)
- Durability(지속성)

답변 예시

트랜잭션은 여러 작업이 하나의 단위로 처리되는 개념입니다.
예를 들어 주문 생성과 결제 내역 저장이 함께 성공하거나 함께 실패해야 할 때 사용합니다.
ACID는 이런 트랜잭션이 신뢰성 있게 동작하도록 보장하는 특성입니다.

이 질문은 아주 깊게 들어가지 않더라도, 데이터가 왜 틀어질 수 있는지 이해하고 있는가를 보는 경우가 많습니다.

데이터 직무 면접에서 꼭 나오는 지표 질문

이제부터가 많은 지원자들이 가장 어려워하는 파트입니다.
SQL은 손으로 익히면 늘지만, 지표는 정의와 해석의 감각이 필요합니다.

면접관이 지표 질문을 하는 이유는 단순합니다.

“이 사람이 숫자를 계산할 줄만 아는가, 아니면 숫자가 무엇을 의미하는지까지 이해하는가?”

지표 질문 1: 좋은 지표란 무엇인가요?

정말 자주 나오는 질문입니다.
겉보기에 추상적이지만, 제대로 답하면 꽤 좋은 인상을 남길 수 있습니다.

좋은 답변의 핵심 요소

비즈니스 목표와 연결되어야 함
행동 변화나 성과를 반영해야 함
정의가 명확해야 함
측정 가능하고 반복 가능해야 함
허무지표(vanity metric)가 아니어야 함

답변 예시

좋은 지표는 단순히 숫자가 잘 나오는 지표가 아니라, 비즈니스 목표와 연결되고 의사결정에 도움이 되는 지표라고 생각합니다.
또 정의가 명확해서 누구나 같은 방식으로 계산할 수 있어야 하고, 시간에 따라 비교 가능해야 합니다.
예를 들어 앱 다운로드 수는 커 보일 수 있지만 실제 활성 사용자 증가와 연결되지 않으면 허무지표가 될 수 있습니다.

면접에서 이 질문이 나오면 “지표는 의사결정을 위한 도구”라는 관점을 꼭 담아보세요.

지표 질문 2: DAU, MAU, 리텐션 중 어떤 지표가 더 중요할까요?

정답은 없습니다.
그래서 더 좋은 질문입니다.

좋은 답변 방향

서비스 특성에 따라 다름
핵심은 현재 비즈니스 단계와 문제 정의
성장 단계면 유입/활성화, 성숙 단계면 리텐션/수익성이 중요할 수 있음

답변 예시

어떤 지표가 더 중요하다고 단정하긴 어렵고, 서비스 특성과 현재 단계에 따라 달라진다고 생각합니다.
예를 들어 초기 서비스라면 신규 유입과 활성화 지표가 중요할 수 있고, 어느 정도 사용자 풀이 확보된 서비스라면 리텐션이 더 핵심일 수 있습니다.
개인적으로는 단기 활성보다 반복 사용을 보여주는 리텐션이 서비스 건강도를 더 잘 설명하는 경우가 많다고 봅니다.

이런 유형의 질문은 균형감이 중요합니다.
하나만 맞다고 우기기보다 조건부로 설명하는 답변이 좋습니다.

지표 질문 3: 전환율이 떨어졌다면 어떻게 분석하겠습니까?

이건 거의 단골 질문입니다.

좋은 답변 구조

지표 정의 확인
분모/분자 변화 확인
세그먼트 분해
시점별 이슈 확인
원인 가설 수립
추가 데이터 검증

답변 예시

우선 전환율의 정의와 집계 단위를 확인하겠습니다. 방문 대비 구매인지, 상품 상세 진입 대비 구매인지에 따라 의미가 다르기 때문입니다.
다음으로 분모가 늘었는지, 분자가 줄었는지 나눠 보겠습니다.
이후 채널, 디바이스, 신규/기존 사용자, 카테고리 단위로 세분화해서 특정 구간에서만 하락이 있었는지 확인하겠습니다.
마지막으로 최근 기능 변경, 가격 정책, 마케팅 유입 품질 변화 등을 가설로 두고 검증하겠습니다.

이런 대답은 거의 모든 데이터 직무 면접에서 좋은 평가를 받을 가능성이 높습니다.
왜냐하면 지표 해석, 분해 능력, 문제 해결 흐름이 모두 담겨 있기 때문입니다.

지표 질문 4: 리텐션은 어떻게 계산하나요?

분석 직무라면 꼭 준비해야 하는 질문입니다.

핵심 개념

특정 기준 시점에 유입된 사용자 집단을 추적
이후 특정 시점에 다시 활동한 비율을 계산
N일 리텐션, 주차 리텐션, 월 리텐션 등으로 구분

자주 헷갈리는 포인트

가입일 기준인지 첫 구매일 기준인지
활동의 정의가 무엇인지
같은 날 재방문을 포함하는지
롤링 리텐션인지 클래식 리텐션인지

답변 예시

리텐션은 특정 코호트가 이후 시점에도 다시 활동했는지를 보는 지표입니다.
예를 들어 1월 1일 가입자 코호트 중 7일 뒤 다시 방문한 사용자의 비율을 D7 리텐션으로 계산할 수 있습니다.
다만 활동의 정의가 앱 실행인지, 핵심 행동 수행인지에 따라 값이 크게 달라지므로 먼저 이벤트 기준을 명확히 해야 합니다.

이 질문에서는 계산식보다도 정의의 엄밀함이 중요합니다.

지표 질문 5: 퍼널 분석은 어떻게 하나요?

퍼널 분석은 프로덕트 분석, 이커머스 분석에서 매우 자주 등장합니다.

예시 퍼널

방문 → 회원가입
상품조회 → 장바구니 → 결제
광고노출 → 클릭 → 랜딩 → 구매

면접관이 보는 것

각 단계의 정의가 명확한가
유저 단위인지 이벤트 단위인지 구분하는가
중복 제거를 고려하는가
단계 순서를 반영하는가

답변 예시

퍼널 분석은 사용자가 목표 행동에 이르기까지 단계별 이탈을 보는 방식입니다.
이때 중요한 것은 각 단계의 이벤트 정의와 사용자 단위 기준을 명확히 하는 것입니다.
예를 들어 장바구니 클릭 수가 아니라 장바구니에 진입한 고유 사용자 수로 계산해야 실제 전환 흐름을 더 잘 볼 수 있습니다.
또 이벤트 발생 순서를 고려하지 않으면 퍼널이 왜곡될 수 있어 세션이나 타임스탬프를 함께 확인하겠습니다.

퍼널 분석을 말할 때 이벤트 수 vs 사용자 수 구분은 꼭 챙기세요.

가설 검증 질문은 왜 어려울까

많은 지원자들이 SQL보다 가설 검증 질문을 더 어렵게 느낍니다.
그 이유는 정답이 딱 하나로 떨어지지 않기 때문입니다.

면접관이 여기서 보고 싶은 건 통계 공식 암기보다 아래와 같습니다.

문제를 가설 형태로 바꿀 수 있는가
비교군과 실험군을 적절히 구분하는가
편향 가능성을 인지하는가
결과를 과장하지 않는가

즉, 똑똑한 사람보다 신중하게 판단하는 사람을 찾는 질문에 가깝습니다.

가설 검증 질문 1: A/B 테스트를 설명해보세요

핵심 답변 포인트

두 개 이상의 그룹에 서로 다른 조건을 적용
결과 지표 차이를 비교
랜덤 배정이 중요
통계적 유의성과 실무적 의미는 다를 수 있음

답변 예시

A/B 테스트는 사용자 집단을 무작위로 나누어 서로 다른 버전을 노출하고, 핵심 지표 차이를 비교해 어떤 변경이 더 나은지 판단하는 방법입니다.
이때 랜덤 배정이 중요하고, 단순 평균 차이뿐 아니라 통계적 유의성과 효과 크기를 함께 봐야 합니다.
또한 유의미한 차이가 있더라도 실제 비즈니스 임팩트가 충분한지는 별도로 판단해야 합니다.

여기서 통계적 유의성 ≠ 비즈니스 중요성을 말해주면 훨씬 좋습니다.

가설 검증 질문 2: p-value가 무엇인가요?

이 질문은 자주 나오지만 지나치게 어렵게 설명할 필요는 없습니다.

답변 예시

p-value는 귀무가설이 참이라고 가정했을 때, 지금처럼 극단적이거나 더 극단적인 결과가 나올 확률을 의미합니다.
보통 작을수록 관측된 차이가 우연만으로 발생했을 가능성이 낮다고 해석합니다.
다만 p-value 하나만으로 모든 결론을 내리기보다 표본 수, 효과 크기, 실험 설계의 타당성도 함께 보겠습니다.

이렇게 답하면 충분히 좋습니다.
너무 수학적으로 들어가다가 오히려 꼬일 필요는 없습니다.

가설 검증 질문 3: 유의미한 차이가 없으면 실패한 실험인가요?

정말 좋은 질문입니다.

답변 방향

반드시 실패라고 볼 수 없음
효과가 정말 없을 수 있음
표본 수가 부족했을 수 있음
측정 지표가 부적절했을 수 있음
특정 세그먼트에서만 효과가 있을 수도 있음

답변 예시

유의미한 차이가 없다고 해서 반드시 실패한 실험이라고 보진 않습니다.
실제로 효과가 없을 수도 있지만, 표본이 부족했거나 관찰 기간이 짧았거나 핵심 지표가 적절하지 않았을 수도 있습니다.
따라서 실험 설계, 파워, 세그먼트별 반응을 함께 검토한 뒤 다음 액션을 정하는 것이 중요하다고 생각합니다.

이 질문은 결과를 단정하지 않는 태도가 중요합니다.

가설 검증 질문 4: 상관관계와 인과관계의 차이는 무엇인가요?

데이터 면접 단골 질문입니다.

답변 예시

상관관계는 두 변수 간 함께 움직이는 패턴이 있다는 의미이고, 인과관계는 한 변수가 다른 변수에 직접 영향을 준다는 의미입니다.
상관관계만으로 원인을 단정하면 위험합니다.
예를 들어 구매자들이 쿠폰을 많이 사용했다고 해서 쿠폰이 구매를 만들었다고 바로 결론 내리기 어렵고, 원래 구매 의향이 높은 사용자가 쿠폰도 적극적으로 사용했을 수 있습니다.
그래서 가능하면 실험 설계나 추가 통제를 통해 인과를 더 신중히 판단해야 합니다.

이 답변에서 예시를 넣으면 훨씬 자연스럽습니다.

가설 검증 질문 5: 실험 결과 해석 시 주의할 점은 무엇인가요?

체크해야 할 포인트

랜덤 배정이 잘 되었는가
표본 수가 충분한가
실험 기간이 적절한가
외부 요인이 있었는가
다중 검정 이슈는 없는가
세그먼트별 편차가 큰가
가드레일 지표는 괜찮은가

답변 예시

실험 결과는 메인 지표만 보고 판단하면 위험하다고 생각합니다.
우선 샘플 불균형, 실험 기간, 시즌성, 외부 마케팅 영향 등을 확인해야 하고, 메인 지표가 좋아졌더라도 이탈률이나 CS 증가 같은 가드레일 지표가 악화되지는 않았는지 함께 봐야 합니다.
특히 여러 지표를 동시에 보면 우연히 하나가 유의해 보일 수 있어서 해석에 주의하겠습니다.

가드레일 지표를 언급하면 실무 감각이 확 살아납니다.

실제 면접에서 자주 나오는 통합형 질문

데이터 직무 면접은 이제 단순 지식 질문보다 통합형 질문이 많아지고 있습니다.
즉 SQL, 데이터베이스, 지표, 가설 검증을 한 번에 묻습니다.

아래 질문들은 꼭 연습해보세요.

통합 질문 1: 구매 전환율이 지난주 대비 20% 하락했습니다. 어떻게 분석하시겠어요?

좋은 답변 구조

전환율 정의 확인
데이터 소스 및 집계 로직 확인
분모/분자 변화 확인
세그먼트 분석
이벤트 누락/로깅 이슈 확인
변경사항과 연계한 가설 수립
추가 검증 또는 실험 제안

답변 예시

먼저 전환율 정의와 SQL 집계 로직부터 확인하겠습니다. 종종 이벤트 누락이나 JOIN 중복으로 지표가 왜곡될 수 있기 때문입니다.
이후 분모와 분자를 나누어 보고, 유입 채널·디바이스·신규/기존 사용자·카테고리 단위로 세분화하겠습니다.
특정 구간에서만 하락했다면 최근 UI 변경, 결제 오류, 가격 변화, 마케팅 유입 품질 저하 같은 가설을 세우고 로그와 운영 이슈를 함께 확인하겠습니다.
필요하다면 개선안에 대해 A/B 테스트로 효과를 검증하겠습니다.

이 답변 하나에 거의 모든 역량이 들어 있습니다.

통합 질문 2: 신규 기능 출시 후 DAU는 늘었는데 매출은 줄었습니다. 어떻게 해석할 건가요?

이건 정말 실무형 질문입니다.

생각해볼 포인트

저품질 유입이 늘었는가
무료 기능이 유료 행동을 대체했는가
사용자 구성 변화가 있었는가
단기 DAU와 장기 LTV의 방향이 다른가
기능 출시로 구매 동선이 복잡해졌는가

답변 예시

DAU 증가만으로 긍정적이라고 보기보다는 어떤 사용자가 늘었는지 먼저 보겠습니다.
신규 기능이 탐색형 사용자를 늘렸지만 실제 구매 의도가 낮은 트래픽이 늘었을 수도 있고, 기존 유료 행동을 무료 기능이 대체했을 가능성도 있습니다.
따라서 사용자 세그먼트별 매출, ARPU, 전환율, 구매까지 걸리는 시간 변화를 함께 보면서 기능의 순효과를 평가하겠습니다.

이런 질문은 숫자 하나로 결론 내리지 않는 태도가 중요합니다.

통합 질문 3: 로그 테이블을 믿을 수 없을 때 어떻게 하시겠어요?

의외로 자주 나오는 질문입니다.

답변 포인트

로그 정의서 확인
수집 구조 확인
중복/누락 점검
운영 데이터와 교차 검증
이상치 탐지
데이터 품질 모니터링 필요성 제안

답변 예시

로그 데이터는 그대로 믿기보다 먼저 이벤트 정의와 수집 구조를 확인하겠습니다.
이후 중복 이벤트, 누락 구간, 타임존 문제, 앱 버전별 수집 차이를 점검하고, 가능하면 주문 DB나 백오피스 수치와 교차 검증하겠습니다.
반복적으로 사용하는 핵심 로그라면 데이터 품질 모니터링 지표를 따로 두는 것도 필요하다고 생각합니다.

이런 답변은 꽤 강합니다.
실무에서는 “분석 잘하는 사람”보다 “잘못된 데이터를 의심할 줄 아는 사람”이 더 귀할 때가 많기 때문입니다.

면접 답변을 더 좋아 보이게 만드는 말하기 방식

같은 내용을 알고 있어도 말하는 방식에 따라 훨씬 더 탄탄해 보일 수 있습니다.

좋은 답변의 기본 구조

정의 확인 → 단위 확인 → 분해 분석 → 가설 수립 → 검증 계획

예를 들어 이런 패턴이 좋습니다.

“우선 지표 정의를 확인하겠습니다.”
“그다음 사용자 단위인지 주문 단위인지 grain을 맞추겠습니다.”
“세그먼트별로 분해해 어디서 차이가 발생했는지 보겠습니다.”
“그 결과를 바탕으로 가능한 원인을 가설로 세우고 검증하겠습니다.”

이 구조를 몸에 익혀두면, 낯선 질문이 나와도 쉽게 무너지지 않습니다.

면접에서 자주 하는 실수

데이터 직무 지원자들이 자주 하는 실수를 정리해보면 아래와 같습니다.

1) SQL만 잘하면 된다고 생각하는 것

면접은 쿼리 대회가 아닙니다.
쿼리는 도구일 뿐이고, 결국 중요한 건 문제를 어떻게 정의하고 해석하는가입니다.

2) 지표를 너무 빨리 단정하는 것

“전환율이 떨어졌으니 UX 문제입니다” 같은 답변은 위험합니다.
좋은 면접 답변은 항상 확인해야 할 전제를 먼저 말합니다.

3) 통계 용어를 과장해서 쓰는 것

p-value, 유의수준, 검정력 같은 말을 많이 넣는다고 답변이 좋아지지 않습니다.
오히려 정확하지 않으면 역효과가 납니다.

4) 비즈니스 맥락이 없는 것

DAU, MAU, 리텐션을 줄줄 외워도 서비스 특성과 연결하지 못하면 답변이 얇아 보입니다.

5) 데이터 품질을 전혀 의심하지 않는 것

실무 데이터는 생각보다 자주 틀어집니다.
그래서 “집계 로직과 로그 품질도 확인하겠습니다”라는 한 문장이 큰 차이를 만듭니다.

면접 직전 체크리스트

아래 항목은 정말 마지막에 점검해보면 좋습니다.

영역	꼭 점검할 것
SQL	JOIN, GROUP BY, CASE WHEN, 윈도우 함수, 리텐션/퍼널 쿼리
데이터베이스	PK/FK, 인덱스, 정규화, 트랜잭션 개념
지표	전환율, 리텐션, 코호트, ARPU/ARPPU, 퍼널 정의
가설 검증	A/B 테스트, p-value, 상관/인과, 편향, 가드레일 지표
말하기	정의 확인 → 단위 확인 → 분해 → 가설 → 검증 구조

바로 써먹기 좋은 예상 면접 질문 20선

아래 질문들은 실제로 연습해두면 도움이 많이 됩니다.

SQL/데이터베이스 면접질문

INNER JOIN과 LEFT JOIN의 차이를 설명해주세요.
JOIN 후 row 수가 예상보다 많아졌다면 무엇을 의심하시겠어요?
WHERE와 HAVING의 차이는 무엇인가요?
COUNT(*)와 COUNT(column)의 차이는 무엇인가요?
윈도우 함수는 어떤 상황에서 쓰나요?
사용자별 첫 구매를 SQL로 어떻게 구하시겠어요?
카테고리별 매출 상위 3개 상품을 어떻게 구할 건가요?
인덱스는 왜 필요하고 어떤 단점이 있나요?
정규화와 비정규화의 차이는 무엇인가요?
PK와 FK를 설명해주세요.

지표/분석 질문

좋은 지표란 무엇이라고 생각하나요?
전환율이 떨어졌을 때 어떻게 접근하시겠어요?
DAU와 리텐션 중 어떤 지표가 더 중요하다고 보나요?
퍼널 분석 시 주의할 점은 무엇인가요?
리텐션은 어떻게 계산하나요?

가설 검증 질문

A/B 테스트를 설명해주세요.
p-value를 쉽게 설명해보세요.
유의미한 차이가 없으면 실험은 실패인가요?
상관관계와 인과관계의 차이는 무엇인가요?
실험 결과 해석 시 가장 조심해야 할 점은 무엇인가요?

이 20개는 꼭 소리 내서 답해보세요.
머리로 아는 것과 말로 설명하는 건 전혀 다릅니다.

답변 예시를 더 탄탄하게 만드는 팁

면접 답변은 “아는 내용”보다 “정리해서 말하는 방식”이 중요합니다.
아래 표현은 실제로 활용도가 높습니다.

자주 쓰면 좋은 표현

“먼저 정의를 확인하겠습니다.”
“집계 단위를 맞추는 것이 중요합니다.”
“분모와 분자를 나눠서 보겠습니다.”
“세그먼트별로 분해해보겠습니다.”
“로그 누락이나 중복 가능성도 점검하겠습니다.”
“상관관계만으로 단정하지 않겠습니다.”
“통계적 유의성과 비즈니스 임팩트를 함께 보겠습니다.”

이런 표현은 면접관 입장에서 듣기 편합니다.
정리된 사고를 하는 사람처럼 보이기 때문입니다.

실전용 요약 카드

데이터 직무 면접 핵심 공식
SQL은 데이터를 꺼내는 도구
데이터베이스 이해는 데이터 구조를 읽는 힘
지표 해석은 비즈니스 문제를 보는 눈
가설 검증은 결과를 성급히 단정하지 않는 태도

그리고 답변할 때는 늘 이 흐름을 기억하면 됩니다.

정의 확인 → 단위 확인 → 세분화 분석 → 가설 수립 → 검증 계획

이 구조만 몸에 익어도 면접 답변이 훨씬 안정적이 됩니다.

Q&A

Q1. SQL을 잘하면 데이터 직무 면접은 충분한가요?

충분하지는 않습니다.
SQL은 기본 체력에 가깝습니다. 실제 면접에서는 그 SQL로 어떤 지표를 만들고, 그 결과를 어떻게 해석하며, 어떤 의사결정을 내릴 수 있는지까지 함께 봅니다. 그래서 SQL만 준비하기보다 지표와 가설 검증을 꼭 같이 준비하는 것이 좋습니다.

Q2. 통계 전공이 아니어도 가설 검증 질문에 답할 수 있나요?

그렇습니다.
오히려 면접에서는 복잡한 수식보다 실험의 목적, 비교 방식, 편향 가능성, 해석의 주의점을 더 중요하게 보는 경우가 많습니다. p-value를 외우는 것보다 “유의미하다고 해서 무조건 중요한 건 아니다”를 이해하고 말할 수 있는 편이 더 좋습니다.

Q3. 데이터베이스 면접질문은 어느 정도까지 준비해야 하나요?

분석 직무 기준으로는 너무 깊은 내부 구현까지 들어가기보다, 정규화, 인덱스, PK/FK, 트랜잭션의 기본 개념과 실무적 의미 정도는 정리해두는 것이 좋습니다. 특히 조인 구조, 키 개념, 인덱스의 역할은 SQL 성능과도 연결되기 때문에 기본 이상은 꼭 챙겨두는 편이 좋습니다.

마무리

데이터 직무 면접은 결국 한 가지를 묻고 있습니다.

“이 사람은 데이터를 숫자 덩어리가 아니라, 문제를 해결하는 근거로 다룰 수 있는가?”

그래서 준비할 때도 따로 떼어 외우기보다 연결해서 공부하는 것이 좋습니다.

sql 면접 질문으로 데이터 추출 능력을 다지고
데이터베이스 질문으로 구조를 이해하고
지표 질문으로 비즈니스 해석력을 키우고
가설 검증 질문으로 판단의 신중함을 보여주는 것

이 네 가지가 함께 가야 면접에서 훨씬 강해집니다.

면접장에서는 완벽한 정답보다 차분하게 정의를 확인하고, 논리적으로 좁혀가며, 섣불리 단정하지 않는 태도가 더 좋은 평가로 이어지는 경우가 많습니다.
마치 복잡한 데이터를 한 번에 꿰뚫어보는 사람보다, 작은 이상 신호를 놓치지 않고 차근차근 확인하는 사람이 결국 더 믿음직한 것처럼요.

오늘 정리한 질문들을 기준으로 한 번씩 직접 말해보면, 실제 면접에서 확실히 덜 흔들릴 겁니다.
특히 SQL, 지표, 가설 검증은 각각 따로 준비하지 말고 하나의 문제 해결 흐름으로 연결해서 연습해보세요. 그 차이가 생각보다 큽니다.

저작자표시 비영리 변경금지 (새창열림)