[사전캠프 9일차] 아티클 스터디⑦, 파이썬 공부, SQLD 공부

오늘도 또 하루가 밝았다. 얼른 공부 하고서 책 읽고 싶다. 읽어야 할 책이 쌓여있거늘 아직도 수요일이라니. 그래, 평일 동안 할 공부 부지런히 해놓으면 주말에 더 많이 읽어야지. 우선 오늘도 할 일을 하자.

 

오늘은,

• 일곱 번째 아티클 스터디 진행하기
• 파이썬 공부
  • 개인 퀘스트(달리기반) - [Python 응용하기] Lv1. 랜덤 닉네임 생성기
• SQLD 공부
  • [SQLD 자격증 챌린지] 2주차 2-3~2-4, 3주차

 

---

 

아티클 스터디 ⑦: 마케터에게 데이터 분석이란?

오늘 읽은 아티클: 

마케터에게 데이터분석이란? 꼭 필요할까?

 

아 드디어 왔다, 이 아티클을 읽는 날이.

아티클 스터디를 위해 함께 공부할 아티클 목록으로 제목을 훑어봤을 때 재밌을 것 같은 글이 2개 있었는데 그 중 하나가 이 글이다. (다른 하나는 아직 안 했다 후후)

 

나는 현재 내일배움캠프 데이터 분석 코스를 수강하는 건 마케터로서 취업하는 데 내세울 수 있는 강점이 되지 않을까 하는 기대 때문이다. 그래서 마케터 관점에서 데이터 분석을 다루는 이 글에 관심이 갔다.

 

250205 아티클 스터디를 하며 개인 요약 한 일부.

아무래도 가장 인상적인 부분은 마케터로서 데이터 분석 능력을 키우는 방법이었다("실무 경험이 없어 고민만 하는 것보다 이런 식으로 구조화 해보는 것은 어떨까요?"라는 말에서 내가 할 수 있는 건 오로지 YES). 그 방법으로 제시한 것이,

실생활이나 프로젝트를 할 때 문제 인식 → 가설 수립 → 검증(with 데이터) → 개선 프로세스를 적용하고
이 일련의 과정을 기록하기

이 과정에서 중요한 건 기록이라고 생각한다.

 

기록을 하게 되면 3가지 일이 일어난다.

우선 기록하기 위해 이 과정을 세부적으로 뜯어보게 된다. 내가 인식한 문제란 이 상황에서 발생하는 무엇인지, 문제의 원인이 무엇인지, 이를 해결하려면 취할 수 있는 조치는 무엇인지, 그래서 그 조치를 시행했을 때 어떤 일이 벌어졌는지 등 기록이란 행위를 위한 것이 아니었다면 이 모든 과정을 거쳐서 의사결정을 하더라도 내가 의식하지 못한 채로 이뤄졌을 가능성이 크다.

또 기록은 메타인지를 가능케 한다. 즉, 내가 했던 일들을 한 발짝 떨어져 회고하게 한다. 분명히 내가 생각하고 내가 행한 일임에도 '내가 왜 그랬더라' 하는 순간들이, 그 결정의 이유를 알 수 없는 때가 있다. 나는 그게 별생각 없이 했다기보다 내가 나에게 너무 가까워서 보이지 않기 때문이라고 생각한다. 나로부터 거리를 두고 내가 한 일을 돌아볼 수 있어야 나 역시 내 결정에 대해 잘 알 수 있고 그를 바탕으로 개선할 수 있다.

그리고 또 기록은 무형의 경험을 언어로 붙잡을 수 있게 된다. 조직 내 합리적인 의사결정은 당연하지만 언어로 소통한다. 나의 사고 흐름과 그에 따른 결과까지가 합리적이라 할지라도 '왜 이렇게 했어요?'라는 동료나 상사의 말에 분명한 언어를 갖춰 대답할 수 없다면 의미가 없다. 나는 내 생각을 나의 말로써 소통하는 일은 연습이 필요하다고 생각한다. 마치 한국인이면 한국어를 할 줄이야 알겠지만 한국어를 잘한다고는 말할 수 없는 것처럼. 그래서 글로 기록하는 일은 나의 경험을 언어로 붙잡아두는 연습을 해야 한다. 언어가 진정으로 소통을 위한 도구라면 그렇게 사용할 줄 알아야 한다.

 

아무튼 말이 길어졌지만, 저자가 글에서 '감으로 어떤 조치를 선택하는 것보다 특정 지표들에 근거해 어떤 조치를 선택하는 것이 성공률을 높여주기에 데이터 분석 능력이 필요하다'고 했다(물론 이에 덧붙여 모든 의사결정이 데이터 기반의 의사결정이 적절하진 않다고 덧붙이면서). 나는 감도 합리적일 수 있다고 생각한다. 감은 직·간접적 경험이란 데이터의 누적으로 형성되기에 감에 따른 결과 역시 합리적일 수 있다. 그러나 '감'이라는 뭉뚱그린 언어로는 회사라는 조직 내에서 소통할 수 없다. 그래서 데이터를 비롯한 다양한 도구들을 통해 분명한 언어로 소통한다. '감'이라는 짧고 가벼운 근거를, 상세하고 세부적인 사고 흐름을 근거로 대신해 내세울 때에야 동료들의 동의를 얻을 수 있는 합당한 논리적 결과를 도출할 수 있다는 점을 이번에 스터디를 하며 느꼈다.

 

그리고 "본인이 준비하고 있는 산업군과 지구를 연결짓고, 어떤 부분에서 데이터 기반의 의사결정이 필요할지 고민해보세요."라는 말에서 도서 출판 시장에선 어떤 식으로 마케터들이 일하고 있는지를 담은 책이 있는지 찾아봐야겠다.

 

---

 

파이썬 공부: 개인퀘스트(달리기반) - [Python 응용하기]

Lv1. 랜덤 닉네임 생성기

Q. 사용자가 최소 27가지 이상의 닉네임 중 하나를 무작위로 생성하는 파이썬 코드 작성하기
     (사용할 키워드: 기절초풍, 멋있는, 재미있는 / 도전적인, 노란색의, 바보같은 / 돌고래, 개발자, 오랑우탄)

nick1 = ['기절초풍', '멋있는', '재미있는']
nick2 = ['도전적인', '노란색의', '바보같은']
nick3 = ['돌고래', '개발자', '오랑우탄']

print(nick1+nick2+nick3)

우선 리스트들을 만들었다. 이런 상태에서는,

당연히 리스트 안의 내용을 전부 불러온다.

각 리스트 중 하나만 무작위로 선택하기, 그걸 구현해야 하는데 모르니까 구글에서 찾아본다.

 

[참고] https://product-lab21.tistory.com/entry/%ED%8C%8C%EC%9D%B4%EC%8D%AC-%EB%A6%AC%EC%8A%A4%ED%8A%B8-%EB%9E%9C%EB%8D%A4-%EC%B6%94%EC%B6%9C-python-list-random

찾아보니 파이썬 내장 함수인 random 함수를 이용하면 될 것 같다.

• random 함수
  • 우선 사용하기 전에 import random으로 랜덤함수를 호출
  • random.choice(리스트 명) : 리스트 중 하나를 무작위로 추출
  • random.sample(리스트 명, n) : 리스트 중 n개를 무작위로 추출 (단, 중복하지 않음)
  • random.choice(리스트 명) for 변수 명 in range(n) : 리스트 중 n개를 무작위로 추출 (단, 중복을 허용)

나는 하나만 뽑으면 되니까 choice를 활용한다.

import random

nick1 = ['기절초풍', '멋있는', '재미있는']
nick2 = ['도전적인', '노란색의', '바보같은']
nick3 = ['돌고래', '개발자', '오랑우탄']

random_n1 = random.choice(nick1)
random_n2 = random.choice(nick2)
random_n3 = random.choice(nick3)

print(random_n1+random_n2+random_n3)

그러면 이렇게 실행할 때마다 다른 조합으로 닉네임이 출력된다.

 

그런데 출력되는 문구를 좀 더 보기 좋은 방식으로 수정하기 위해 f-string을 통해 다듬었다.

import random

nick1 = ['기절초풍', '멋있는', '재미있는']
nick2 = ['도전적인', '노란색의', '바보같은']
nick3 = ['돌고래', '개발자', '오랑우탄']

random_n1 = random.choice(nick1)
random_n2 = random.choice(nick2)
random_n3 = random.choice(nick3)

print(f'당신은 [{random_n1} {random_n2} {random_n3}]입니다!!')

 

이제 됐다! 하고 힌트로 맞게 작성했는지 확인했다.

그런데 힌트에 주어진 구조가 더 깔끔해보여서 그를 반영해 마지막으로 코드를 더 다음었다.

import random

nick1 = ['기절초풍', '멋있는', '재미있는']
nick2 = ['도전적인', '노란색의', '바보같은']
nick3 = ['돌고래', '개발자', '오랑우탄']

def creat_random_nickname():
        random_n1 = random.choice(nick1)
        random_n2 = random.choice(nick2)
        random_n3 = random.choice(nick3)
        return f'{random_n1} {random_n2} {random_n3}'

my_nickname = creat_random_nickname()
print(f'당신은 [{my_nickname}]입니다!!')

보다시피 이렇게 코드를 수정해도 출력되는 결과값은 달라지지 않았다.

단, 이렇게 중간에 함수를 정의해 한 번 묶어줌으로써 코드 가독성이 개선되었다. 앞으로도 파이썬을 공부하며 더 나은 방식으로 코드를 작성하는 법을 염두에 두고 배워야겠다. 아 실습은 역시 재밌어 룰루~

 

---

 

SQLD 공부: [SQLD 자격증 챌린지] 수강하기

…이제 이론 공부.

 

원래 이런 시험 공부할 때는 온라인 강의 안 듣고 문제집으로 문제 풀고 → 채점하고 → 틀린 문제 근거 찾고 → 다시 문제 풀고… 이런 무한 반복으로 오로지 나와 문제집 둘이서(?) 열심히 며칠 만 공부해서 익히는 편이라 지금의 이 시간이 조금 고통.. 
흐아 그치만 어차피 들어야 하는 상황이라면 차라리 얼른 이론 끝내고 넘어가게 빨리빨리 다 듣는 게 상책이다.

 

대충 강의 목록을 훑어보니 6주차부터 실습에 들어가는 것 같아서 이번 주 안으로 5주차까지 다 들을 계획이다. 아무튼, 오늘은 어제 공부하다 만 3층 스키마부터.

 

3층 스키마

데이터 독립성의 필요성

• 데이터 모델링의 과정에서 중요한 것 = "데이터의 일체적 구성"
  • 데이터의 일체적 구성 = 데이터를 일관된 형태로 수집하는 것
                                    = 데이터의 독립적 구성
• 데이터 독립성의 필요 데이터 독립성이 왜 필요한가, 데이터 독립성이 등장하게 된 배경
  • 유지보수 비용 증가
  • 유지보수 중복성 증가
  • 데이터 복잡도 증가
  • 요구사항 대응 저하
• 데이터 독립성의 확보에 따른 기대효과
  • 각 View의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경이 가능함
  • 단계별 Schema에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다르게 제공됨

3층 스키마

• 3층 스키마 : 사용자, 설계자, 개발자가 데이터베이스를 보는 관점에 따라 데이터베이스를 기술하고 이들 간의 관계를 정의한 표준
• 구조
  • 유저 어플리케이션(≒프로그램)은 데이터베이스 시스템의 최상위 단계에 놓고,
    물리적 데이터베이스는 최하위 단계에 둔 뒤,
    이 사이를 3개의 단계(=스키마)로 나눠보자는 것 = 데이터베이스를 3가지의 큰 범주로 분리해보자
  • 📃외부 스키마
    • 개별 사용자가 보는 DB 스키마
    • 실제로 관심 있는 데이터베이스 부분을 설명하고 나머지는 감춤 ← 상층 레이어를 구성하는 이유
    • 우리 같은 유저들이 사용하는 프로그램들이 위치한 단계
    • 사용자 관점
    • 접근하는 특성에 따른 스키마를 구성 =접근하는 특성에 따라 다른 외부 스키마를 보여줌
  • 📃개념 스키마
    • 데이터 베이스의 물리적인 저장 구조에 대한 부분은 숨기고(=내부 스키마에 대한 부분은 숨김) 데이터의 전체적인 구조와 관계에 대해 집중
    • 모든 사용자 관점을 통합한(=모든 외부 스키마를 통합한) 조직 전체의 DB를 기술함
    • 내부 스키마에 저장된 데이터베이스들을 조금 추상화한 단계
    • 저장된 데이터가 어떻게 구성되어 있는지를 보는 게 개념 스키마
    • 설계자 관점
    • 통합 데이터베이스 구조
  • 📃내부 스키마
    • 물리적 장치에서 데이터가 실제적으로 저장되는 완전히 구체적인 방법을 표현하는 스키마 실제로 데이터가 저장되는 건 여기
    • 개발자 관점
    • 물리적 저장 구조
• 사상 = 각 범주 간 요청/응답을 전송하는 것
  • 외부 스키마에서 요청이 들어오면 DBMS에 의해 개념 스키마 - 내부 스키마로 전달됨.
    여기에서 요청과 응답을 변환하는 프로세스를 사상(mapping)이라고 함
• 이렇게 데이터베이스를 3층 구조로 나누는 이유 = 데이터 독립성을 확보하기 위함!

데이터 독립성

• 데이터 독립성 = 상위 스키마를 변경하지 않고 하나의 계층에서 스키마를 변경할 수 있는 능력
• 3층 스키마의 독립성 = 각 스키마는 논리적으로, 물리적으로 독립적이면 좋다
                                   (외부스키마-개념스키마: 논리적 독립성 / 개념스키마-외부스키마: 물리적 독립성)
  
  • 🔁논리적 독립성
    • 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원함
    • 논리적 구조가 변경되어도 응용 프로그램에 영향이 없음 응용 프로그램 = 유저 입장
  • 🔁물리적 독립성
    • 내부 스키마가 변경되어도 개념 스키마는 영향을 받지 않도록 지원함
    • 저장 장치의 구조 변경은 응용프로그램과 개념 스키마에 영향을 주지 않음
      저장 장치의 구조 변경 = 물리적 구조 변경, 데이터베이스의 구조 변경

데이터 모델링 요소

데이터 모델링의 구성 요소 중 중요 개념 3가지

• 🔎엔터티(Entity) 
  • = 어떤 것
  • 사물이나 사건 등을 바라볼 때 전체를 하나로 지칭하는 용어
  • 업무가 어떤 부분을 중심으로 벌어지고 초점이 맞춰져있는지를 확인할 수 있음
  • 데이터 모델링에서 사용되는 하나의 대상, 객체
• 🔎속성(Attribute)
  • Entity가 지닐 수 있는 여러 특징
• 🔎 관계(Relationship)
  • Entity와 Entity가 서로 간의 관계

ERD(Entity Relationship Diagram, 엔터티 간 관계를 나타낸 그림)

ERD 작성법

• ①엔터티를 정의하고 그림
• ②엔터티를 적절하게 배치
  • 가장 중요한 엔터티를 좌측 상단에 배치 후 이를 중심으로 다른 엔터티들을 나열 (왼쪽에서 오른쪽, 위에서 아래로)
• ③엔터티 간 관계를 설정
• ④관계에 이름을 붙임
• ⑤관계의 참여도 기술
• ⑥관계의 필수 여부를 기술

데이터 모델 표기법

• 대표적으로 IE/Crow's Foot 표기법과 Barker/Case*Method 표기법
  • IE, Barker = 엔터티를 그리는 표기하는 법
    Crow's Foot, Case*Method = 관계를 표현하는 법
  • • [참고] Barker 표기법 참고사항
                # : 식별자 속성 (사람으로 치면 주민등록번호 같은 고유한 속성
                * : 필수 속성
                o : 선택 속성

그림으로 둘의 차이를 알아둬야 함.

 

좋은 데이터 모델의 요소

절대적 기준은 존재하진 않는다. 그래도 대체로 이런 요소들을 갖추면 좋다는 의미.

• ✔ 완전성: 모든 데이터가 모델에 정의돼 있어야 함
• ✔ 중복 제재: 동일한 사실은 한 번만 기록해야 함
• ✔ 업무 규칙: 내/우리가 하고 싶은 이 서비스가 어떻게 비즈니스가 구성돼야 하는지에 관한 규칙이 데이터 구조에서 드러나야 함
• ✔ 데이터 재사용: 데이터가 언제든 다시 사용할 수 있는 형태로 가공되고 보관돼야 함
• ✔ 의사소통: 의사소통의 도구로서 역할 해야 함
• ✔ 통합성: 조직 전체에서 한 번만 정의돼야 함

 

---

아.. 이론 강의를 듣고 TIL을 작성하는 일은 시간 소요 2배 이벤트(?)구나....

전에 수강했던 실습 위주의 수업들을 강의 들으면서 슉슉- 넘어가기도 하고 또 문제를 주로 풀어서 적을 내용이 적었다. 실습이야 해도 왜 이런 코드를, 쿼리를 작성했는지를 적어가는 방식으로. 근데 이론 수업을 들을 때도 적지 않은 시간이 걸리는데 또 그 내용을 TIL로 적기 위해 정리하는 과정이 시간이 생각보다 많이 소요된다. 그래서 생각만큼 진도가 쑥쑥 나가질 않는다. 에고.

 

그치만 어쩌겠나, 내일 들어야지.

아무튼 3주차 강의는 내일 듣기로! 아티클 스터디도 없는 날이니 열심히 SQLD 강의 진도나 나가야겠다. 아자~~