바로 답부터 말하면, 구글 스프레드시트 QUERY 함수는 반복해서 복사·필터·정렬하던 업무 표를 하나의 수식으로 다시 만드는 방법입니다. 원본 표를 그대로 두고 별도 시트에서 필요한 열만 고르거나, 조건에 맞는 행만 모으거나, 월별·담당자별 합계를 자동으로 갱신할 수 있습니다. 처음부터 복잡한 SQL처럼 접근하기보다 “원본 범위 고정 → 필요한 열 선택 → 조건 한 줄 추가 → 정렬과 집계 분리” 순서로 만들면 실무 보고서 자동화에 바로 적용하기 쉽습니다.
요약: QUERY 함수는 공유 스프레드시트에서 반복 집계를 줄이는 데 유용합니다. 원본 데이터는 입력 전용으로 보호하고, QUERY 결과 시트는 보고용으로 분리하며, 함수 문법·화면 이름·Google Workspace 기능은 업데이트로 바뀔 수 있으니 실제 작성 전 Google 고객센터와 현재 스프레드시트 화면을 함께 확인하세요.
1. QUERY 함수가 어울리는 업무부터 고릅니다
QUERY 함수는 모든 표 작업을 대신하는 만능 도구라기보다, 같은 기준으로 계속 걸러 보고서를 만드는 업무에 잘 맞습니다. 예를 들어 주문 목록에서 이번 달 처리 완료 건만 보기, 문의 접수 표에서 담당자별 건수를 모으기, 콘텐츠 캘린더에서 상태가 “검수 대기”인 행만 따로 뽑기 같은 작업입니다. 매번 필터를 켜고, 복사하고, 다른 시트에 붙여 넣는 과정이 반복된다면 QUERY 수식 하나로 바꿀 후보입니다. 반대로 한두 번만 확인하고 끝나는 임시 표라면 기본 필터나 피벗 테이블이 더 빠를 수 있습니다. 자동화할 업무를 고를 때는 “같은 원본, 같은 조건, 같은 출력 형식이 반복되는가”만 먼저 확인하면 됩니다.
2. 원본 표는 입력 전용, 결과 표는 보고 전용으로 분리합니다
실무에서 QUERY 수식이 망가지는 가장 흔한 이유는 원본 표와 결과 표를 같은 공간에서 수정하기 때문입니다. 원본 시트에는 날짜, 담당자, 상태, 금액이 아닌 수량, 메모처럼 입력 항목을 열 단위로 정리하고, 결과 시트에는 QUERY 함수만 둡니다. 이때 첫 행은 헤더로 고정하고, 중간에 병합 셀이나 빈 제목을 넣지 않는 것이 좋습니다. 공유 문서라면 원본 시트의 헤더 행과 주요 열을 보호해 두면 동료가 열 이름을 바꾸거나 열을 삭제해 수식이 깨지는 일을 줄일 수 있습니다. 결과 시트는 보고서처럼 보이게 서식만 다듬고, 데이터 자체는 수식이 만들도록 두는 방식이 관리가 쉽습니다.
3. 기본 문법은 세 부분만 기억하면 됩니다
QUERY 함수의 기본 형태는 범위, 쿼리 문장, 헤더 행 수입니다. 예시는 =QUERY(A1:F, "select A, B, D where C = '완료'", 1)처럼 작성할 수 있습니다. 여기서 A1:F는 원본 범위, select는 가져올 열, where는 조건, 마지막 1은 첫 행이 헤더라는 뜻입니다. 처음에는 select와 where만 사용해도 충분합니다. 중요한 점은 스프레드시트의 열 이름이 아니라 A, B, C 같은 열 문자를 기준으로 쿼리한다는 것입니다. 따라서 원본 표 중간에 새 열을 끼워 넣으면 기존 수식의 의미가 바뀔 수 있습니다. 새 열이 필요할 때는 오른쪽 끝에 추가하고, 결과 시트의 수식을 다시 점검하는 습관을 들이는 것이 안전합니다.
4. 실무용 QUERY 설계 체크리스트
처음 만드는 자동 집계 시트라면 아래 체크리스트를 순서대로 확인하세요. 이 목록은 작은 팀의 주간 보고서, 광고 소재 관리표, 고객 문의 처리표, 재고 수량 점검표처럼 행이 계속 추가되는 업무에 공통으로 적용할 수 있습니다.
- 원본 시트 첫 행에 빈 헤더가 없는지 확인합니다.
- 날짜 열은 텍스트가 아니라 날짜 형식으로 입력합니다.
- 상태 값은 드롭다운으로 통일해 오타를 줄입니다.
- QUERY 결과 시트에는 직접 입력 칸을 섞지 않습니다.
- 조건이 늘어나면 수식 한 줄에 모두 넣기보다 보조 셀을 활용합니다.
- 공유 전에는 보기 권한과 편집 권한을 따로 확인합니다.
5. 자주 쓰는 업무 자동화 패턴 표
| 업무 상황 | QUERY에서 쓰는 기준 | 운영 팁 |
|---|---|---|
| 이번 달 처리 건만 보기 | where 날짜 열이 기간 안에 있음 | 시작일과 종료일을 별도 셀에 두면 매달 수정이 쉽습니다. |
| 담당자별 업무 목록 만들기 | where 담당자 열 = 특정 이름 | 담당자 이름은 드롭다운으로 통일합니다. |
| 상태별 검수 대기 목록 | where 상태 열 = ‘검수 대기’ | 상태 문구가 바뀌면 결과가 비므로 기준값을 표준화합니다. |
| 상위 금액 또는 수량 정렬 | order by 수량 열 desc | 숫자가 텍스트로 들어가면 정렬이 틀어질 수 있습니다. |
| 월별 간단 집계 | group by와 sum 조합 | 처음에는 피벗 테이블로 검산한 뒤 QUERY로 고정합니다. |
6. 조건을 셀로 빼면 비개발자도 관리할 수 있습니다
쿼리 문장 안에 담당자명이나 상태명을 직접 적으면 빠르게 만들 수 있지만, 운영자가 바뀌었을 때 수정 위치를 찾기 어렵습니다. 실무에서는 B1 셀에 담당자, B2 셀에 상태, B3 셀에 시작일처럼 조건을 따로 두고 QUERY 수식이 그 셀을 참조하게 만들면 관리가 쉬워집니다. 예를 들어 보고서 상단에 조건 입력 영역을 만들고, 그 아래에 결과 표를 배치하는 식입니다. 이렇게 구성하면 수식을 모르는 동료도 조건 셀만 바꿔 원하는 결과를 볼 수 있습니다. 단, 날짜를 문자열로 합칠 때는 형식이 틀어질 수 있으므로 테스트용 행을 몇 개 만들어 결과가 예상과 같은지 확인해야 합니다.
7. 피벗 테이블과 함께 쓰면 검산이 쉬워집니다
Google 고객센터에서도 피벗 테이블은 데이터를 요약하고 패턴을 확인하는 기능으로 안내됩니다. QUERY 함수로 최종 보고 시트를 만들더라도, 처음 설계할 때는 피벗 테이블을 한 번 만들어 같은 결과가 나오는지 비교하면 좋습니다. 피벗 테이블은 마우스로 항목을 끌어다 놓으며 구조를 빠르게 확인하기 좋고, QUERY 함수는 결과를 고정된 양식으로 자동 갱신하기 좋습니다. 두 기능을 경쟁 관계로 보지 말고, 피벗 테이블은 설계와 검산, QUERY는 반복 배포와 공유 보고에 쓰는 방식이 실무적으로 안정적입니다. 특히 숫자 합계가 중요한 보고서라면 첫 주에는 두 결과를 나란히 두고 차이를 확인하는 것이 좋습니다.
8. 오류가 나면 문법보다 데이터 형식을 먼저 봅니다
QUERY 오류가 보일 때 바로 수식을 고치기보다 원본 데이터 형식을 먼저 점검하세요. 날짜 열에 텍스트가 섞여 있거나, 숫자 열에 쉼표가 포함된 문자열이 들어가거나, 상태 값에 공백이 붙어 있으면 조건이 맞아도 결과가 비어 보일 수 있습니다. 또한 쿼리 문장 안의 작은따옴표, 큰따옴표, 열 문자 오타도 자주 발생합니다. 오류를 줄이려면 원본 표 상단에 테스트 행을 두고, QUERY 결과에 반드시 나와야 할 샘플을 정해 둡니다. 그 샘플이 빠지면 조건이나 형식이 어긋난 것입니다. 자동화는 한 번의 멋진 수식보다 매주 같은 결과를 안정적으로 내는 구조가 중요합니다.
9. 공유 문서에서는 권한과 변경 이력을 같이 봅니다
스프레드시트 자동화는 개인 파일보다 공유 파일에서 더 큰 효과를 냅니다. 하지만 공유 문서에서는 누가 열을 추가했는지, 누가 상태 값을 바꿨는지, 어떤 필터가 남아 있는지에 따라 결과가 달라질 수 있습니다. 편집자는 원본 입력 담당자로 제한하고, 결과 보고서만 보는 사람은 보기 권한으로 두는 편이 안전합니다. 변경 이력은 문제가 생겼을 때 원인을 찾는 단서가 되므로, 중요한 보고서라면 마감 전 복사본을 만들어 두거나 버전 이름을 남겨 두세요. 이 글은 일반 업무 문서 자동화 방법을 다루며, 조직 내부 보안 규정과 문서 관리 기준이 있다면 해당 기준을 우선 확인해야 합니다.
10. 최신 화면과 요금, 기능 이름은 마지막에 다시 확인합니다
Google Sheets와 Google Workspace는 메뉴 위치, 함수 도움말 문구, 공유 화면, 유료 플랜별 기능 표시가 바뀔 수 있습니다. 따라서 글이나 내부 매뉴얼을 따라 하기 전에 현재 화면에서 함수 자동완성 설명, 공유 버튼 위치, 피벗 테이블 메뉴명을 직접 확인하는 것이 좋습니다. 또한 부가 기능이나 외부 자동화 도구를 연결한다면 무료 제공량, 저장 한도, 권한 요청 범위가 달라질 수 있습니다. 팀 문서에는 “확인일”을 적고, 분기마다 한 번씩 주요 화면을 다시 점검하는 규칙을 두면 오래된 캡처 때문에 실수가 나는 일을 줄일 수 있습니다. QUERY 함수 자체는 강력하지만, 운영 문서는 언제나 현재 도구 화면을 기준으로 업데이트되어야 합니다.
FAQ
Q1. QUERY 함수가 어려우면 무엇부터 시작하면 되나요?
처음에는 select와 where만 사용하세요. 필요한 열만 가져오고, 상태 값 하나로 걸러 보는 예제를 만든 뒤 정렬과 집계를 추가하면 부담이 줄어듭니다.
Q2. 피벗 테이블 대신 QUERY만 쓰면 되나요?
둘 다 쓰는 편이 좋습니다. 피벗 테이블은 빠른 탐색과 검산에 좋고, QUERY는 정해진 보고서 양식을 자동 갱신하는 데 좋습니다.
Q3. 원본 표에 새 열을 추가해도 괜찮나요?
가능하면 오른쪽 끝에 추가하세요. 중간에 열을 삽입하면 A, B, C 기준으로 작성한 쿼리의 의미가 바뀔 수 있어 결과 검수가 필요합니다.
Q4. 공유 문서에서 수식이 자주 깨지면 어떻게 하나요?
원본 헤더 행과 주요 열을 보호하고, 조건 입력 셀만 수정 가능하게 분리하세요. 변경 이력과 버전 이름을 남기면 원인 추적도 쉬워집니다.
Q5. Apps Script 없이도 자동화 효과가 있나요?
있습니다. QUERY, 드롭다운, 보호 범위, 피벗 테이블만 조합해도 반복 필터링과 복사 작업을 크게 줄일 수 있습니다. 스크립트는 알림이나 외부 연동이 필요할 때 나중에 붙이면 됩니다.
