SQL의 기본 구조

select
from
where
group by
order by

3주차 SQL 학습 내용

지난 시간까지는 SQL의 기본 구조를 학습하였다.
새로운 문법: GROUP BY, IF-ELSE-END, CASEM WHEN-THEN
어려웠던 점:
조건문의 적용 부분에서 어려움을 겪었다.

select restaurantname,
order_id,
delivery_time,
price,
addr,
case when delivery_time>25 and delivery_time<=30 then price0.05(_if(addr like '%서울%', 1.1, 1))
when delivery_time>30 then price1.1(if(addr like '%서울%', 1.1, 1))
else 0 end "수수료"
from food_orders

if(addr like '%서울%', 1.1, 1) 부분에서, 이전 실습까지 if문은 별개의 줄로 if~else~end로 작성했는데, 여기서는 case 안에 삽입되며 'addr 안에 '서울'이 포함되어 있으면 1.1, 그렇지 않으면 1'이라는 해석이 도출되었다. 이렇게 괄호로 if문을 표현하는 것은 또다른 명령어 안에 포함되어 있을 때만 적용이 되는 것일까? 코드를 간결하게 만들기 위한 것일까?
학습을 완료했지만, 이번 주차는 쿼리문의 길이가 급격하게 길어진 만큼 순서나 괄호, 따옴표 등 작은 요소에서 오류가 나지 않는지를 주의할 필요가 있겠다. 또한, 전체적인 플로우를 먼저 파악하고 어떠한 문법이 적용되는지를 먼저 구조화하는 것이 무엇보다 중요할 것 같다.

아티클 스터디: 데이터 리터러시

아티클 1: 데이터 리터러시(Data Literacy)를 올리는 방법
아티클 2: 그 데이터는 잘못 해석되었습니다

[주제]

• 아티클 1> 데이터 리터러시를 올리는 방법
• 아티클 2> 데이터를 잘못 해석하는 상황별 유형과 제대로 해석할 수 있는 방법

[아티클 요약]

• 아티클 1> 데이터 리터러시는 ‘데이터를 활용해 문제를 해결할 수 있는 능력’이다. 해결하려는 문제와 관련 없는 데이터를 요청하는, 즉 데이터 활용 역량이 부족한 경우도 비일비재하다. 예를 들어, 대개 ‘신규 기능 관련 이벤트 성과 측정’에 전면팝업 데이터, 노출, 클릭, 참여자수 등의 데이터를 활용하고자 하는데, 이는 관련이 매우 적은 데이터다.
  데이터를 볼 때는 문제 정의-솔루션 설정-측정 지표 설정의 단계를 거쳐야 한다. 이때 데이터를 ‘잘’ 활용하려면 1) 데이터/실험 기반 사고방식, 2) 분석 흐름대로 데이터를 탐색할 수 있는 환경, 3) 이 과정을 도와주는 분석가들이 필요하다.
  1) 데이터/실험 기반 사고방식이 만들어지려면 모든 업무가 데이터와 실험 기반으로 이루어지게끔 해야 한다. 실험 프로세스를 도입해 이 방식을 유도할 수 있는데, [해결하려는 문제, 관련 OKR, 측정 지표, 가설 검증 기준, 검증 후 변화될 액션, 결과, 학습한 점]과 같은 내용을 작성하여 데이터 기반의 사고 방식을 유도하고, 실험 내용과 과정, 결과는 노션 실험보드에 등록하여 가시화할 수 있다. 이렇게 업무를 점진적으로 데이터 기반 문제 해결 중심으로 치환하는 과정을 거치면, 구성원들이 문제 정의-솔루션-측정 지표를 만들어내는 데 익숙해진다.
  2) 분석 흐름대로 데이터를 탐색할 수 있는 환경을 만들면, 구성원들이 분석가 없이도 가장 중요한 지표에 집중할 수 있다. 이를 위해 중요한 인풋 지표와 아웃풋 지표 간의 관계를 표현한 관계도, ‘데이터맵’을 제작 및 공유하는 것이 중요하다. 이때 인풋 지표 설정의 중요한 원칙은 1)측정 가능하고, 2)직접적으로 control 가능해야 한다는 것이다. 데이터맵에 따라 지표의 현재 수준을 확인할 수 있는 환경을 마련하는 데에는 대시보드를 사용할 수 있다. KPI 대시보드에서 중요한 지표 변동을 알 수 있고, 지표 간의 관계를 통해 문제의 원인을 파악할 수 있다.
  3) 이 과정을 도와주는 데이터 분석가의 역할은 단순히 데이터를 추출하고 분석 내용을 리포팅하는 것에만 그쳐서는 안 된다. 문제 정의, 원인 분석을 거쳐 액션 아이템을 도출해 협업팀이 성공을 위해 움직일 수 있도록 해야 한다.
  또한 분석가와 구성원 모두 데이터를 빠르게 준비해 사용할 수 있는 데이터 플랫폼이 필요하다. 핵심은 모든 원천데이터가 적재되어있는 ‘데이터 레이크’, 신속하게 정확한 데이터를 추출할 수 있도록 구조화된 ‘데이터 웨어하우스’, 데이터 레이크/웨어하우스 내에 어떤 데이터가 있는지 쉽게 확인할 수 있도록 만들어주는 ‘데이터 카탈로그’ 이렇게 3가지이다.
  데이터 리터러시를 키우기 위해서는 위와 같은 과정을 통해 구성원들이 데이터를 바라보는 올바른 관점을 만드는 것, 그 관점을 유지-강화할 수 있는 환경을 갖추는 것이 중요하다.

• 아티클 2> 데이터가 있다고 해도 잘못 해석하여 잘못된 결론으로 갈 위험이 있다. 이 상황별 유형으로 4가지를 소개한다.
  1) 생존자 편향의 오류: 고객 이탈 데이터를 예시로 들어보자. 서비스 장기간 이용 고객의 이탈률이 높아진다면 서비스를 수정해야 한다. 이를 ‘매주 이탈 고객 중 서비스를 장기간 이용한 고객의 비율’로 설정한다면, 이 지표의 상승을 통해 고객들의 불만도가 높아졌다고 해석할 수 있다. 그러나 서비스 특성상, 원래 대부분의 사용자가 장기간 서비스를 이용하는 경우 이 지표에 대한 해석은 정확하지 않을 수 있다. 따라서 이탈한 유저 대신 전체 활성화된 유저를 기준으로 해석을 시도하면 올바른 해석이 가능할 것이다.
  2) 심슨의 역설: 전체 지표와 그룹을 나눈 지표의 방향성이 다르게 나타나는 상황이다. 예를 들어, A 서비스에 대해 전체 만족도는 B가 높지만 성별 만족도에서는 A가 더 높을 수 있다. 이는 남녀 사용자 수의 비율의 차이로 인해 발생할 수 있다. 심슨의 역설을 방지하기 위해서는 전체 집단의 지표뿐만 아니라 집단을 나누어 지표를 확인하는 과정이 필요하다.
  3) 상관관계를 통한 성급한 일반화: 사람의 특성상, 비슷해 보이는 패턴의 연관성을 찾고 연결하는 데 강점이 있기 때문에 성급한 일반화의 오류가 발생할 수 있다. 경향성이 비슷하다, 즉 상관성이 있다고 해서 인과성이 반드시 있는 것은 아니다. 상관성은 없으나 인과성이 없는 경우, 제3의 공통 원인이 존재할 수 있으므로 이를 고려해야 한다.
  4) 목적에 맞지 않는 지표 선택: 예를 들어, CTA(Call To Action) 버튼을 개선하는 프로젝트를 진행할 때, 정확히 어떤 관점에서 버튼을 개선할지 목적을 명확히 해야 올바른 지표를 선택할 수 있고, 제대로 된 의사 결정을 할 수 있다.
  이렇듯 데이터는 가공하는 기준과 방법에 따라 바뀔 수 있고, 해석하는 사람의 주관이 반영될 수 있다. 데이터를 잘못 해석하지 않기 위한 방지책으로, 칼 세이건의 ‘세이건 표준’을 참고하는 방법이 있다. “특별한 주장에는 특별한 근거가 필요하다” 즉 데이터를 특별한 주장으로 연결시키기 전에 충분한 근거를 확보했는지, 데이터를 잘못 해석했을 가능성은 없는지 꼼꼼하게 체크해야 할 것이다.

[인사이트]

데이터 리터러시 역량은 구성원 모두에게 필요하다. 그러면 데이터 분석가는 단순 분석이 아니라 심화된 역량이 필수적이다. 데이터 분석가에게 가장 중요한 역량은 무엇일까?
문제 정의-솔루션-측정 지표를 설득력있게 만들어야 할 것이다. 지표 간의 관계를 파악하여 실제로 어떤 액션을 취해야 할지를 결정하는 데에는 섬세한 검증 작업이 필요하다. 특히 사람 두뇌의 특성상 데이터를 연관지으려고 한다는 것을 깨달았는데, 데이터 분석가는 냉철한 눈으로 연관이 없는 데이터를 걸러낼 필요가 있을 것이다.
그렇다면 결국, 데이터 분석가는 다양한 구성원들과 소통이 필수적이지 않을까? 프로그래밍 언어와 실제 사람의 언어 모두 잘 해야 하는 일이 아닐까 생각하게 되었다.