데이터 협업이 느린 진짜 이유: 질문과 소통의 구조

🤖 이 글에서 다루는 내용

• 데이터 요청이 길어지는 과정에서 우리가 놓치고 있는 커뮤니케이션의 구조
• 협업을 빠르게 만드는 ‘명확한 질문’의 공통 요소 5가지
• SQL을 몰라도 협업이 개선되는 이유와, SQL을 쓸 때 가독성이 중요한 이유

---

1. 이 글을 쓰게 된 이유

데이터 팀에서 일하면서 느낀 점은, 데이터 요청의 대부분은 기술 문제가 아니라 질문을 정리하는 문제라는 것이었다.

 

"지난주 거래액 데이터 좀 뽑아주실 수 있나요?"

 

일하다 보면 이런 요청을 자주 받는다. 그리고 이어지는 질의응답:

"어떤 거래액 말씀이신가요? 수수료 부과대상인 거래액(Comm.GMV)인가요, 고객 결제 거래액(Net.GMV) 인가요?"
"음... 수수료 부과대상이요. 아 그리고 지역별로 보고 싶어요."
"지역은 광역시/도 단위인가요, 시/군/구 단위인가요?"
"아, 광역시/도요. 그리고 전주 대비 증감률도 같이요."

 

단순해 보이는 데이터 요청 하나에 5분간 질의응답이 오간다. 슬랙으로 주고받으면 30분이 걸리기도 한다. 이런 상황이 반복되다 보니, 문제의 원인을 SQL 실력에서 찾는 질문을 종종 받는다. "PO나 기획자가 SQL을 할 줄 알아야 하나요?"

개인적으로는 할 줄 알면 좋지만, 더 중요한 건 무엇을 알고 싶은지를 명확히 정리하는 게 훨씬 중요하다고 생각한다.

 

이 글에서는 데이터 협업에서 왜 명확한 질문이 중요한지, 그리고 SQL을 안다면 어떻게 더 나은 협업이 가능한지를 다루려고 한다.

---

2. 데이터 요청의 긴 여정

현재 대부분의 데이터 요청 프로세스는 다음과 같다:

(이 글에서는 편의상 데이터 요청을 하는 모든 역할을 ‘협업 동료’로 표현한다.)

협업 동료: 데이터 필요 발생
↓
슬랙으로 요청 (5분)
↓
분석가: 요구사항 파악 질문 (10분)
↓
협업 동료: 답변 (5분)
↓
분석가: 추가 확인 질문 (5분)
↓
협업 동료: 재답변 (5분)
↓
분석가: 쿼리 작성 및 전달 (10분)
↓
협업 동료: "아 이게 아닌데..." 피드백
↓
분석가: 수정 후 재전달 (10분)
↓
총 소요 시간: 50분

실제 쿼리 작성 시간은 10분이다. 나머지 40분은 "무엇을 원하는지" 파악하는 시간이다. 

 

이 40분은 보통 질문을 명확히 준비하지 못한 요청과, 그 질문을 구조화하지 못한 채 수동적으로 주고받는 커뮤니케이션에서 발생한다. 이 조합이 반복될수록, 데이터 요청은 점점 느려지고 서로의 피로도만 쌓인다.

---

3. SQL은 질문이다, 코딩이 아니다

3.1. SQL = 번역 작업

많은 사람들이 SQL을 Python이나 JavaScript처럼 "프로그래밍"으로 생각한다. 하지만 SQL의 정식 명칭은 Structured Query Language - 구조화된 질의 언어이다. 여기서 Query는 질문이며 SQL은 데이터베이스에 질문을 던지는 언어다.

 

즉, SQL을 한다는 것 = 자연어를 DB가 이해하는 형태로 번역하는 것이다. 여기서 종종 오해가 하나 생긴다. SQL을 잘 쓰면, 질문이 애매해도 답이 나올 거라고 생각하는 것이다. SQL은 질문을 대신 만들어주지 않는다. 이미 정리된 질문을 구조적으로 표현할 뿐이다.

 

그래서 데이터 팀이 잘못된 데이터를 전달하는 이유는 크게 두 가지다:

1. 의미 전달의 실패 (질문과 해석 사이에서 맥락이 충분히 공유되지 않은 경우)
→ 질문을 던지는 쪽의 표현 문제일 수도 있고, 질문을 해석하는 분석가가 도메인에 충분히 익숙하지 않은 경우일 수도 있다.
    

• 12월 GMV가 높은 가게 → Comm.GMV? Net.GMV?
• 성공한 가게 → 계약 성공? 플랫폼 노출 시작?
• 최근 데이터 → 어제? 지난주? 지난달?

2. 타이핑 실수 (물리적 오류)

• JOIN 키 오류
• GROUP BY 컬럼 누락
• 날짜 범위 오타

현업에서는 1번이 압도적으로 많이 발생한다. SQL 실력 이전에 협업 과정에서의 소통이 매끄럽지 않아 질문을 명확하게 정의하지 못했다는 의미이다. 

3.2. 그럼 SQL을 꼭 배워야 하나?

정답: (미래에는 어찌될지 모르겠지만..) 꼭 그럴 필요는 없다. SQL을 모르면 데이터를 못 받는 게 아니다. 그것을 위해 데이터 팀이 존재한다. 생성형 모델이 SQL 작성을 도와줄 수는 있다. 하지만 무엇을 질문할지 대신 고민해주지는 않는다.

 

하지만 SQL을 알면 달라지는 것들:

• 내 질문이 얼마나 명확한지/불명확한지 스스로 판단 가능
• 데이터 팀에게 요청할 때 훨씬 구체적으로 설명 가능
• "이 데이터가 왜 이렇게 나왔지?" 이해 가능
• 간단한 수정은 직접 처리 (요청→대기 시간 단축)

즉, SQL은 선택이지만, 명확한 질문은 필수다.

---

4. 명확한 질문의 5가지 요소

4.1. 체크리스트

좋은 질문은 이 5가지 요소를 포함한다:

[기간] + [대상] + [조건] + [측정 지표] + [출력 형태]

 

이 다섯 가지가 정리되지 않으면, SQL이 아니라 대화가 길어진다. 실무에서 자주 헷갈리는 예시를 기준으로 살펴보자.

4.2. 기간 (WHEN)

언제의 데이터인가?

 

불명확한 표현:

• 최근, 요즘, 작년

명확한 표현:

• 2025년 1월 1일 ~ 1월 15일
• 2024년 12월 전체
• 2025-W10 ~ 2025-W14

4.3. 대상 (WHO/WHAT)

누구의 / 무엇을 기준으로 데이터를 볼 것인가?
(분석의 기본 단위)

불명확한 표현:

• 가게, 주문, 유저 

명확한 표현:

• 앱 내 노출중인 가게 
• 주문이 발생한 가게
• 특정 프로덕트에서 발생한 주문

4.4. 조건 (FILTER)

그 대상 중에서 어떤 것만 남길 것인가?

(포함/제외 기준)

 

불명확한 표현:

• 정상적인 주문만, 활성 가게

명확한 표현:

• 성공 주문수만
• 지역별 상위 10% 이상 주문 수만 
• 신규입점 가게의 주문만

4.5. 측정 지표 (WHAT TO MEASURE)

"정확히 무엇을 측정할 것인가?"

불명확한 표현:

• GMV, 매출 , 주문수

명확한 표현:

• 실결제금액 합계 (쿠폰 할인 제외)
• 자사 부담 할인 금액
• 구독 할인 주문 수

4.6. 출력 형태 (HOW TO SHOW)

어떻게 보여줄 것인가?

불명확한 표현:

• 리스트로, 많은 순서로

명확한 표현:

• 가게별로 1줄씩, GMV 높은 순서, 상위 100개
• 날짜별로 집계, 최근 날짜가 위로
• 지역-카테고리 조합으로 그룹화
• 운영성 리스트로 스프레드시트(or redash/ Looker)와 연결해 매일 오전 10시 업데이트 되도록
  → 즉, 보고서/대시보드 자동화 시나리오까지 고려한 요구

 

모든 요청을 이렇게까지 자세히 써야 한다는 의미는 아니다.

이미 조직 내에서 합의된 표현들이 있다면 굳이 다시 풀어서 설명하지 않아도 된다.
하지만 새로운 사람, 새로운 지표, 새로운 맥락이라면 이 정도의 명확함은 반드시 필요하다.
명확한 질문은 서로의 시간을 아끼는 가장 쉬운 방법이다.

---

5. Before & After

5.1. Before (불명확한 요청)

"지난달 주문 많은 가게 리스트 좀 뽑아주세요"

분석가가 추가로 물어야 하는 것:

1. 지난달 = 12월 전체? 직전 30일? 
2. 주문 = 완료된 주문? 접수된 주문?
3. 가게 = 전체 가게? 영업 중인 가게만?
4. 많은 = 상위 몇 개? 기준이 뭐죠?
5. 리스트 = 어떤 정보 포함? (가게명, 지역, 주문수, GMV...?)

예상 소요 시간: 슬랙 3~4회 왕복 (30분)

5.2. After (명확한 요청)

"2024년 12월 1일~31일 기준,
영업 중인 가게 중 완료된 주문 건수 기준 상위 100개 가게의
가게ID, 가게명, 지역, 주문 건수, Net.GMV를
주문 건수 많은 순서대로 리스트업 해주세요"

5가지 요소 체크:

• ✅ 기간: 2024년 12월 1일~31일
• ✅ 대상: 영업 중인 가게
• ✅ 조건: 완료된 주문만
• ✅ 측정 지표: 주문 건수, Net.GMV
• ✅ 출력 형태: 가게별 1줄, 주문수 많은 순, 상위 100개

예상 소요 시간: 추가 질문 없이 바로 작업 (10분)

시간 절감: 불필요한 질문 왕복 제거 → 작업 흐름이 한 번에 끝남

---

6. SQL을 직접 작성한다면

6.1. 가독성이 협업의 핵심

SQL을 배워서 직접 쿼리를 작성하기로 했다면, 이제 중요한 건 "돌아가는 코드"가 아니라 "읽히는 코드"다. PO나 기획자가 직접 작성한 쿼리를 정합성 검토를 위해 분석가에게 리뷰 요청하는 경우가 많다. 이때 가독성이 떨어지는 쿼리는 분석가에게 큰 리소스를 요구한다.

왜냐하면:

• 각 쿼리가 어떤 질문에 대한 답인지 추론해야 하고
• t1, t2, t3... 각 테이블이 무엇을 의미하는지 추적해야 하고
• 중첩된 서브쿼리를 괄호 세면서 분해해야 하기 때문이다

6.2. 실제 리뷰 시간 비교

가독성 낮은 쿼리:

 

select t1.a, t2.b, t3.c 
from (select * from orders where date > '2024-01-01') t1
left join (select vendor_id, sum(amt) from payments group by 1) t2 
  on t1.vendor_id=t2.vendor_id
left join vendors t3 on t1.vendor_id=t3.vendor_id
where t2.b > 100000 order by 1

분석가가 하는 일:

1. t1이 뭐지? → 괄호 안 확인 → 2024년 이후 주문 (1분)
2. t2가 뭐지? → 또 괄호 확인 → 결제금액 합계 (1분)
3. a, b, c가 뭐지? → 역추적 (2분)
4. order by 1이 뭘 기준으로? → SELECT 첫 번째 컬럼 확인 (30초)
5. 전체 로직 이해 (3분)

총 리뷰 시간: 7~8분

---

가독성 높은 쿼리:

WITH recent_orders AS (
  -- 2024년 이후 주문 데이터
  SELECT vendor_id,
                 order_id,
                 order_date
  FROM orders
  WHERE order_date > '2024-01-01'
),
high_value_vendors AS (
  -- 결제액 10만원 이상 가게
  SELECT  vendor_id,
                  SUM(amount) AS total_payment
  FROM payments
  GROUP BY vendor_id
  HAVING SUM(amount) > 100000
)
SELECT  v.vendor_name,
               hvv.total_payment,
               COUNT(ro.order_id) AS order_count
FROM recent_orders ro
LEFT JOIN high_value_vendors hvv 
    ON ro.vendor_id = hvv.vendor_id
LEFT JOIN vendors v 
    ON ro.vendor_id = v.vendor_id
WHERE hvv.total_payment IS NOT NULL
ORDER BY hvv.total_payment DESC

 

분석가가 하는 일:

1. CTE 이름 읽기: "2024년 이후 주문이구나" (10초)
2. 두 번째 CTE: "10만원 이상 가게구나" (10초)
3. SELECT 절: "가게명, 결제액, 주문수 보는구나" (10초)
4. 빠르게 로직 검토 (1분)

총 리뷰 시간: 2분

시간 절감: 5~6분 (리뷰어 3명이라면 15~18분)

---

7. 가독성을 높이는 3가지 원칙

7.1. 의미 있는 이름 사용

피해야 할 것:

• 테이블 별칭: t1, t2, t3, a, b, tmp
• 컬럼 별칭: col1, val, x, y

권장하는 것:

• 테이블 별칭: orders → o, vendors → v, payments → p
• 컬럼 별칭: total_gmv, avg_order_amount, completed_count

7.2. CTE로 논리 단계 분리

서브쿼리 중첩 (나쁜 예):

SELECT *
FROM (
  SELECT *
  FROM (
    SELECT * FROM orders WHERE ...
  ) WHERE ...
) WHERE ...

 

 

CTE로 단계별 분리 (좋은 예):

WITH step1_filter AS (
  -- 1단계: 기간 필터
  SELECT * FROM orders 
  WHERE order_date >= '2025-01-01'
),
step2_aggregate AS (
  -- 2단계: 가게별 집계
  SELECT 
      vendor_id,
      COUNT(*) AS order_count
  FROM step1_filter
  GROUP BY vendor_id
)
-- 3단계: 최종 필터 및 정렬
SELECT *
FROM step2_aggregate
WHERE order_count >= 10
ORDER BY order_count DESC

 

장점:

• 각 단계를 독립적으로 실행해서 검증 가능
• 중간 단계에 문제가 있으면 바로 파악
• 수정 요청 시 해당 CTE만 수정

7.3. 명시적으로 작성

암묵적 표현 (나쁜 예):

GROUP BY 1, 2, 3
ORDER BY 1 DESC
SELECT *  -- 어떤 컬럼이 나올지 모름

명시적 표현 (좋은 예):

GROUP BY vendor_id, region, category
ORDER BY total_gmv DESC
SELECT vendor_id, vendor_name, total_gmv  -- 필요한 컬럼만

 

이유:

• SELECT 절 컬럼 순서가 바뀌면 정렬/그룹화 기준도 바뀜
• 코드 리뷰 시 일일이 숫자 세어야 함
• 6개월 후 본인도 무슨 의미인지 모름

 

하지만 언제나 암묵적인 표현이 나쁜 것은 아니다. 예를 들어 날짜를 가공하여 집계할 경우 GROUP BY에 동일한 표현을 쓰는 것보다 암묵적인 표현을 쓰는 것이 이해하기 편할 수 있다. (다만 group by 1 과 같은 숫자 인덱스 기반 표현은 의미를 코드에서 숨기기에 가독성과 리뷰 측면에서는 주의가 필요하다.) 

select format_date('%Y-%m',base_date) as year_month ,   
          sum(total_gmv) as total_gmv 
from order_summary 
group by year_month

---

8. 실천 가이드

8.1. SQL을 모르는 경우

데이터 요청 전 2분만 투자:

1. 체크리스트 5가지 요소 채우기
2. 슬랙 메시지에 포함해서 보내기

예시:

[데이터 요청]
- 기간: 2025-01-01 ~ 2025-01-15
- 대상: 영업 중인 OD 가게
- 조건: 완료 주문만, 테스트 제외
- 지표: 주문 건수, Net.GMV
- 출력: 가게별 집계, 주문수 많은 순, 상위 100개 , 스프레드시트

 

효과:

• 추가 질문 왕복 시간 30분 → 0분
• 잘못된 데이터 받을 확률 감소
• 분석가의 신뢰 확보

8.2. SQL을 작성하는 경우

작성 전:

1. 5가지 요소 체크리스트 먼저 채우기
2. 단계가 2개 이상이면 CTE 사용하기
3. 테이블/컬럼에 의미 있는 이름 붙이기

리뷰 요청 시:

"이 쿼리 리뷰 부탁드립니다"
→

"12월 OD 주문수 상위 50개 가게를 뽑는 쿼리입니다.
- recent_od_orders: 12월 OD 완료 주문
- vendor_summary: 가게별 주문수 집계
- 최종: 상위 50개 추출
리뷰 부탁드립니다."

 

효과:

• 리뷰 시간 30분 → 3분
• 수정 요청 횟수 감소
• 본인의 디버깅 시간 단축

---

9. 마치며

데이터 협업에서 가장 중요한 건 SQL 문법이 아니다. "내가 정확히 무엇을 알고 싶은지"를 명확하게 표현하는 능력이다.

핵심 정리:

- SQL을 몰라도 괜찮다. 하지만 명확한 질문은 필수다.
- 다섯 가지 요소만 정리해도 요청과 협업 속도는 크게 줄어든다.
- SQL을 쓴다면, 성능보다 가독성이 협업 효율을 좌우한다.
- 결국 데이터 협업의 핵심은 기술이 아니라 커뮤니케이션이다.

---

실무에서 데이터 팀으로서 협업하면서 느낀 점은, 기술적 역량보다 커뮤니케이션 역량이 훨씬 중요하다는 것이다. SQL은 그 커뮤니케이션을 더 원활하게 만들어주는 도구일 뿐이다. 명확한 질문만 해도, 당신과 협업하는 모든 사람의 시간이 절약된다.