이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
SQL 가독성을 높이기 위해 가장 먼저 신경 쓰는 것은 별칭(alias)을 의미 있게 짓는 것입니다. a, b 같은 단일 문자 대신 user_orders, product_info처럼 이름만 봐도 알 수 있게 합니다. 복잡한 쿼리는 `CTE`(Common Table Expression)로 단계를 나눠 읽기 쉽게 구조화합니다. 중첩 서브쿼리는 한눈에 파악하기 어렵기 때문에, WITH절로 단계를 분리하면 각 블록의 의도가 명확해집니다. 팀 프로젝트에서 서브쿼리를 여러 겹으로 쌓은 쿼리를 공유했는데, 팀원이 "이게 무슨 데이터를 뽑는 건지 모르겠다"는 피드백을 줬습니다.
CTE로 바꾸고 각 블록에 목적을 한 줄 주석으로 달았더니 리뷰 시간이 눈에 띄게 줄었습니다. 쿼리는 실행만 되면 되는 게 아니라 다음에 볼 사람이 이해할 수 있게 짜야 한다는 것을 배웠습니다.
SQL 쿼리를 작성할 때 인덴테이션과 키워드 대소문자를 일관되게 유지하는 것을 먼저 신경 씁니다. SELECT, FROM, WHERE 같은 예약어는 대문자로, 컬럼과 테이블명은 스네이크케이스로 통일하면 구조만 봐도 쿼리의 흐름이 읽힙니다. 학교 데이터 분석 수업에서 팀원 세 명이 각자 다른 스타일로 쿼리를 작성했더니, 합칠 때마다 어디가 WHERE이고 어디가 HAVING인지 헷갈렸습니다. 그때부터 팀 공통 포맷 가이드를 한 페이지로 만들어 공유했고, 이후 코드 리뷰 시간이 줄었습니다. 또한 SELECT * 대신 필요한 컬럼만 명시하면 의도가 명확해지고 불필요한 데이터 이동도 줄어든다는 것을 실험으로 확인했습니다.
복잡한 조건은 괄호로 묶어 우선순위를 명시하는 습관도 오독을 줄이는 데 효과가 있었습니다. 읽는 사람을 위한 쿼리를 쓴다는 기준 하나로 대부분의 가독성 선택이 정리됩니다.
반복적으로 쓰이는 복잡한 로직은 뷰(View)로 분리해두는 방식을 자주 씁니다. 같은 집계 로직을 여러 쿼리에 복사하면 수정이 생길 때 모든 곳을 찾아야 하는데, 뷰로 만들어두면 한 곳만 수정해도 참조하는 모든 쿼리에 반영됩니다. 데이터 정리 과정에서는 CASE WHEN을 활용해 컬럼 안에 숨은 분기 조건을 명시적으로 드러내는 것이 중요하다고 느꼈습니다. 쿼리를 검증할 때는 `LIMIT`을 먼저 걸고 점진적으로 범위를 넓히는 방식으로 중간 결과를 확인합니다. 프로젝트에서 수십만 건 데이터를 집계하는 쿼리를 작성하면서, 단계별로 중간 결과를 확인하는 습관이 오류를 조기에 잡는 데 결정적이었습니다. 효율성은 실행 속도뿐 아니라 수정할 때 얼마나 빠르게 의도를 파악할 수 있는가로도 측정된다고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 데이터 분석가 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.