• API키를 받을때는 인코딩된 키를 써야한다~

1. 단기 예보 조회서비스

getUltraSrtNcst 초단기실황조회 (아래 항목명을 &로 이어서 써주면 됨)

예시 url

http://apis.data.go.kr/1360000/VilageFcstInfoService_2.0/
getUltraSrtNcst?
serviceKey=인증키&numOfRows=한페이지에 몇열 보여줄건지&pageNo=1&dataType=json
&base_date=00000000&base_time=0600&nx=격자x&ny=격자y (위도 경도 아님.)

예시 데이터

{
  "response": {
    "header": {
      "resultCode": "00",
      "resultMsg": "NORMAL_SERVICE"
    },
    "body": {
      "dataType": "JSON",
      "items": {
        "item": [
          {
            "baseDate": "20240715",
            "baseTime": "0600",
            "category": "PTY",
            "nx": 60,
            "ny": 127,
            "obsrValue": "0"
          },
          {
            "baseDate": "20240715",
            "baseTime": "0600",
            "category": "REH",
            "nx": 60,
            "ny": 127,
            "obsrValue": "71"
          },
          {
            "baseDate": "20240715",
            "baseTime": "0600",
            "category": "RN1",
            "nx": 60,
            "ny": 127,
            "obsrValue": "0"
          },
          {
            "baseDate": "20240715",
            "baseTime": "0600",
            "category": "T1H",
            "nx": 60,
            "ny": 127,
            "obsrValue": "25"
          },
          {
            "baseDate": "20240715",
            "baseTime": "0600",
            "category": "UUU",
            "nx": 60,
            "ny": 127,
            "obsrValue": "-2.4"
          },
          {
            "baseDate": "20240715",
            "baseTime": "0600",
            "category": "VEC",
            "nx": 60,
            "ny": 127,
            "obsrValue": "70"
          },
          {
            "baseDate": "20240715",
            "baseTime": "0600",
            "category": "VVV",
            "nx": 60,
            "ny": 127,
            "obsrValue": "-0.8"
          },
          {
            "baseDate": "20240715",
            "baseTime": "0600",
            "category": "WSD",
            "nx": 60,
            "ny": 127,
            "obsrValue": "2.7"
          }
        ]
      },
      "pageNo": 1,
      "numOfRows": 30,
      "totalCount": 8
    }
  }
}

getUltraSrtFcst 초단기예보조회

getVilageFcst 단기예보조회

getFcstVersion 예보버전조회

백필할떄 중요. 만약 이전 데이터에 문제가 생겨서 1년치의 데이터를 백필해야된다 근데 만약 이게 1로 설정되어있다면 한번에 1개의 dag만 돌아가서 매우 오래걸림 but 한번에 30개로 해놓으면 훨씬 금방됨

max active tasks

~~~ >> ~~~ >> ~~~>> 이런식으로 되어있으면 어차피 하나 실행되고 다음 태스크 실행되고 하니까 상관없음 근데 만약 동시에 실행되는 태스크가 있다면 설정해 주는 파라미터

full refresh vs incremental update

full refresh : 백필 상관없음. 왜냐하면 할때마다 다 다시불러오기 때문 incremental update : 반대

catch up 참고 https://magpienote.tistory.com/236

autocommit 참고 https://velog.io/@seovalue/autocommit%EC%9D%B4-%EB%8F%84%EB%8C%80%EC%B2%B4-%EB%AD%94%EB%8D%B0

비긴 ~ 커밋 사이에 에러가 발생하면 try except 구문이므로 except로 가서 에러를 출력한 뒤, 롤백 (비긴 전 상태) 해주는 코드 = 데이터 정합성 보장

https://stricky.tistory.com/133

프린터 추가 누르기

https://m.blog.naver.com/bgfkjy1000/221990103554

이분 블로그에 나온대로 하면됨

docker image의 구성요소 from - 기본 os, 환경 run - 설치 환경설정변수 - env, arg 이 이미지의 버전이 뭐고 작성자가 누군지,,,등등 메타 데이터 docker image ls로 볼 수 이씀

docker image를 registry 에서 다운받는다 = docker pull 내가 업로드 = doker push (깃헙이랑 비슷)

docker hub.com에 회원가입 하기! 여기에 ~~리포지토리 만들고, 그 밑에 이미지를 저장하는 것.

사람들이 많이 사용하는 소프트웨어는 official image가 있음.

도커의 목표 : 소프트웨어를 일관되게 빌드하고 실행하고 배포

Docker Image : 이렇게 독립적으로 완전하게 만들어진 패키지 Docker Container : 이 도커 이미지를 독립된 환경에서 실행한 것 도커 이미지를 빌드한다고 많이 얘기함 보통 도커 레지스트리에 도커 이미지를 올려서 다른사람들이 그걸 다운받아서 씀

VM보다는 light weight함. VM은 각각의 Operating System을 갖고 있기 때문 ex) EC2 도커가 나온이후로 VM사용이 많이 줄었음

리눅스 기반은 다 돌아감 컨테이너의 장단점

많은 수의 도커 컨테이너를 관리하는것이 쿠버네티스

Task는 Bash, Python을 포함해서 다양한 작업을 수행할 수 있다. 이 사이트를 참고한다.

또한 잘 알려진 서비스나 오픈소스 백엔드에 대한 작업을 수행할 수 있도록 다양한 Providers Package를 제공한다. 이 사이트를 참고한다.

Providers Package의 경우 pip를 사용해서 설치 가능하다. 이 기술 문서를 참고한다.

Operator Operator는 task를 어떻게 실행시킬지를 나타낸다. 하나의 워크플로우 안에서 하나의 테스크를 나타낸다. Sensor와 Hook도 있지만 일반적으로 Operator를 대부분 사용한다.

Operator는 Action Operator와 Transfer Operator로 구분된다. Action Operator는 작업을 수행하거나 다른 시스템에 작업을 수행하도록 지시한다. Transfer Operator는 특정 시스템에서 다른 시스템으로 데이터를 이동시킨다.

AirFlow에서 제공하는 기본 Operator의 종류는 Bash와 Python을 포함해서 상당히 많다.

Submodules
airflow.operators.bash
airflow.operators.bash_operator
airflow.operators.branch
airflow.operators.branch_operator
airflow.operators.check_operator
airflow.operators.dagrun_operator
airflow.operators.datetime
airflow.operators.docker_operator
airflow.operators.druid_check_operator
airflow.operators.dummy
airflow.operators.dummy_operator
airflow.operators.email
airflow.operators.email_operator
airflow.operators.gcs_to_s3
airflow.operators.generic_transfer
airflow.operators.google_api_to_s3_transfer
airflow.operators.hive_operator
airflow.operators.hive_stats_operator
airflow.operators.hive_to_druid
airflow.operators.hive_to_mysql
airflow.operators.hive_to_samba_operator
airflow.operators.http_operator
airflow.operators.jdbc_operator
airflow.operators.latest_only
airflow.operators.latest_only_operator
airflow.operators.mssql_operator
airflow.operators.mssql_to_hive
airflow.operators.mysql_operator
airflow.operators.mysql_to_hive
airflow.operators.oracle_operator
airflow.operators.papermill_operator
airflow.operators.pig_operator
airflow.operators.postgres_operator
airflow.operators.presto_check_operator
airflow.operators.presto_to_mysql
airflow.operators.python
airflow.operators.python_operator
airflow.operators.redshift_to_s3_operator
airflow.operators.s3_file_transform_operator
airflow.operators.s3_to_hive_operator
airflow.operators.s3_to_redshift_operator
airflow.operators.slack_operator
airflow.operators.sql
airflow.operators.sql_branch_operator
airflow.operators.sqlite_operator
airflow.operators.subdag
airflow.operators.subdag_operator
airflow.operators.trigger_dagrun
airflow.operators.weekday

참고로 _operator로 끝나는 Operator들은 대부분 Defrecated 되었다. 대신 이름에서 _operator를 제외한 Operator를 사용하면 된다.

Operator에 공통적으로 kwargs라는 Keyword Arguments 를 전달하는 부분이 있다. 해당 부분은 DAG을 정의할 때 정의했던 default_args가 전달된다고 이해하면 된다.

자세한 내용은 아래 포스팅을 참고한다.

managed airflow

• MWAA : aws가 관리해줄게- 관리비쌈 : 한달 50만원
• GCP - 구글이 관리해줄게

데이터 인프라 RDS - raw data: 데이터레이크 - 복제 - 가공 - 데이터웨어하우스에 저장 - 레드시프트 airflow 를 이용해 db를 클론하고 스파크를 통해 production DB의 데이터를 DL로 복제한다 production db는 S3

airflow를 써보기만 했구나... 라고만 생각이 들지 않도록

airflow를 써봤다 = 공식문서를 봤다. airflow의 흐름을 알고 있다 = 오픈소스를 보고 어떤 흐름으로 흘러가는지 안다. airflow 공식문서를 정리해서 책을 내면 잘 팔릴듯 ㅋㅋ

serialize 모델 데이터를 jason으로 바꾸는거.

deserialize 그 반대

extract transform (너무 크면 spark같은 빅데이터 프레임워크를 쓰기도 함) load

묶어서 하나의 task가 되기도, 각각이 하나의 task가 되기도 함.

웹상에 존재하는 이름 성별 csv파일을 redshift에 있는 테이블로 복사하는데, name열을 pirmary key로 지정할 것임. 하지만 데이터 웨어하우스에서는 primary key 로 지정한다고 해서 uniqeness가 지켜지는 것이 아님. 따라서 그것을 데이터 엔지니어가 책임져야 함.

파이썬으로 extract, transform, load 함수를 구성할 것

만약 roll back - 비긴 이전으로 돌아감 이건 개인 선호도 차이
try execpt 할 때 except 뒤에 슬랙으로 알리든 하는 기능을 넣어야 함. 아니면 계속 모르고 넘어가게 됨. 따라서 raise를 써주면 fail하기 때문에 airflow가 알 수 있게됨. fail했을때 이메일을 보낸다거나 슬랙으로 알린다거나 하도록 하게 하면 됨.

에어플로 설치

가장 좋은 방법 : 사양이 좋은 EC2서버를 만들고 그안에 다커 엔진을 설치한 다음에 다커 컨테이너 형태로 에어플로를 실행하는게 가장 좋은 방법(팀프로젝트 할 땐 이렇게 해야 할 것)

리눅스 이해하기 ● 우분투 (ubuntu): 리눅스 타입 중의 하나. 다른 타입은 데비안, 레드햇, 페도라, ... ● ssh: 리눅스 혹은 유닉스 서버에 로그인해주는 프로그램 (터미널) ○ private key와 public key를 사용 ● sudo: 보통 슈퍼유저로서 프로그램을 구동할 수 있도록 하는 프로그램이다. ● apt-get: 우분투/데비안 계열의 리눅스에서 프로그램 설치/삭제를 관리해주는 프로그램 ○ apt-get update, apt-get install ● su: substitue user의 약자로 현재 사용 중인 사용자 계정을 로그아웃하지 않고 다른 사용자의 권한을 얻을 때 사용한다 ● vi: 텍스트 에디터. https://withcoding.com/112

1. 도커 엔진 맥북에 설치 : 맥에서는 4GB가 필요

2. airflow 도커 이미지 다운 ●먼저 터미널 프로그램을 실행하고 적당한 폴더로 이동 ●airflow-setup Github repo를 클론 ○ git clone https://github.com/keeyong/airflow-setup.git ● airflow-setup 폴더로 이동하고 ○ cd airflow-setup ●2.5.1 이미지 관련 yml 파일 다운로드 ○ curl -LfO 'https://airflow.apache.org/docs/apache-airflow/2.5.1/docker-compose.yaml' ● 이미지 다운로드 ○docker-compose -f docker-compose.yaml pull

3. 그 이미지를 도커 컨테이너 안으로 실행을 시킨 다음 ● 컨테이너 실행 ○ docker-compose -f docker-compose.yaml up

4. 그게 다 잘되면 airflow 웹서버가 뜰거고, 그거를 웹 브라우저를 통해 access 해보는 형태로 데모를 실행해 볼것. ● http://localhost:8080으로 웹 UI 로그인 ○airflow:airflow 사용

아래는 DAG객체 만든 예시 (한기용)

from airflow import DAG
dag = DAG(
"dag_v1", #DAG이름
start_date = datetime(2020,8,7,hour = 0 ,minute = 00),
schedule = "0****", #얘도 한시간에 한번임.모든 0분마다 한번씩 시작이 됨.
tags = ["example"],
catchup = False ,
#아까 공통 세팅 정해준거 넣기
defalut_args = defalut_args
)

(다른 블로그)

def task_failure_alert(context):
    print(f"Task has failed, task_instance_key_str: {context['task_instance_key_str']}")

def dag_success_alert(context):
    print(f"DAG has succeeded, run_id: {context['run_id']}")

with DAG(
    dag_id="example_callback",
    schedule=None,
    start_date=pendulum.datetime(2021, 1, 1, tz="UTC"), #시작날짜
    dagrun_timeout=datetime.timedelta(minutes=60),
    catchup=False,
    on_success_callback=dag_success_alert, #성공했을 때
    on_failure_callback=task_failure_alert, #실패했을 때
    tags=["example"],
)

schedule = None : 나는 주기적으로 실행 안할겨. 다른 DAG가 끝났을 때 trigger 할겨 schedule = @once : 나는 주기적으로 실행 안할겨. 다른 DAG가 끝났을 때 trigger 할거 schedule = @hourly : 매 시 0분 schedule = @daily : 매일 0시 0분 schedule = @weekly : 매 주 ... schedule = @monthly schedule = @yearly

catchup 실행 안된 날짜에 대해서 매 시간마다 이 dag를 실행하려고 함. catchup=False 하면 start date과 지금 날짜의 갭에 대해서 아무런 행동을 하지 않음 특히 dag가 Full refresh라면 과거 2년치에 대해 실행하나 지금 한번 실행하나 그 결과가 똑같기 때문에 꼭 False로 설정해줘야 함 incremental한거 아니면 다 False로 설정 할 것.

• 내가 만든 데이터 파이라인은 문제없이 동작할 것이고, 관리하는 것은 어렵지 않을 것이다.

현실 : 버그 , 데이터 소스 상의 이유 What if data sources are not available or change its data format, 데이터 파이프라인들 간의 의존도에 이해도 부족

만약에 어떤 테이블의 열을 업데이트하거나 이름을 바꿨다면 그 뒷단의 파이프라인이 모두 변경되어야 하기 때문에 문제가 생김...(장고 하면서 경험해봤다ㅠㅠ)

Best practices

1. 가능하면 데이터를 통채로 복사해서 테이블 만들기 (Full refresh) 문제가 생겨도 해결 방법이 간단. 이게 어느시점부터는 불가능할텐데, 그럼 incremental update를 해야함
   소스를 봤을 떄 하루에 한번 업데이트를 하는 파이프라인이라면, 어제 하루 업데이트 된것만 DW에 저장 효율성은 올라가지만, operation이 복잡해짐 만약 하루씩 데이터가 올라가는데, 어떤날 데이터가 안올라갔다 = 빵꾸생김 과거 데이터가 바꼈다 = 다 다시 읽어와야 함. 코드를 바꿔야 함 이런 복잡도가 생김.따라서 가능하면 full refresh를 해라. 언제 그럼? - 이 데이터를 하루에 한번 업데이트를 해야한다? - full refresh를 하는데 12시간이 걸린다면 대략 정오쯤 데이터가 다 카피됨. 그래도 문제 없으면 full 쓰고, 적어도 오전 9시부터는 해야한다 = incremental refresh해야함.

2. 멱등성을 보장해야함. Idempotency 몇번을 실행하나 결과가 동일해야함. 내가10번 실행하면 10번 중복이 된다 ? = 멱등성이 깨진 것.

3. 백필이 쉬워야 함. 실패한걸 다시 채우는게 쉬워야 함.

4. 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화 비즈니스 오너 명시 - 누가 요청했는지 (필요 없으면 지우고 해야하니까) 데이터 리니지 (A라는 테이블이 뒷단에서 어떻게 소비되는지) 명확히 있어야 스키마를 바꾸면 누가 영향을 받는지 알게 됨. 이걸 이해하지 못하면 온갖 종류의 사고 발생

5. 주기적으로 쓸모 없는 데이터들을 삭제 지난 90일동안 사용되지 않은것 등등.. 유데미에서는 쿼터에 한번정도 주기적으로 했다고 함.

6. 데이터 파이프라인의 실패는 당연시 여기고, 그 사고 보고서를 잘 써야함. 사고 원인을 이해하고, 이를 방지하기 위한 액션 아이템들의 실행이 중요해짐. 사고의 정도를 보고 기술부채를 갚아야 할지..말지..

7. 중요 데이터 파이프라인의 입력과 출력을 체크하기 입력 레코드 수와 출력 레코드 수가 몇개인지 체크하는 것부터 시작됨. 써머리 테이블을 만들어내고 primary key 가 존재한다면 primary key uniqueness가 보장되는지 체크하는 것이 필요함. 중복 레코드 체크

장고 업데이트 사항 - 1. full refresh를 페이지 누를때마다 하지 말것.

ETL 데이터 카피해서 데이터 웨어하우스로 집어넣기 (데이터 엔지니어가 수행) : 누군가 요청해서 하는것 ex) " 페이스북 광고 데이터를 갖고와주세요 "라는 요청을 수행. ( 보통 데엔은 어떻게 사용해야 되는지 모름)

ELT 그걸 갖고 분석하기 쉽게 요약(조금 더 추상화되고 요약된 - 데이터 분석가가 수행) 데이터 크기에 따라 DW보다 DL의 정보를 바탕으로 하는 경우가 더 많음.

*데이터 웨어하우스와 데이터 레이크의 차이는..? *

데이터 레이크는 훨씬 몇배는 더 스케일이 큰 데이터 웨어하우스라고 보면 됨. 딱히 큰 기능 없어도 되고, 로그파일처럼 비구조화 된 데이터를 저장하는 데도 별 부담이 없음 원본 데이터를 건들지 않고 원본 그대로 복제 해놓는 경우가 많음.

데이터 웨어하우스는 관계형 데이터베이스이기 때문에 비구조화된건 어려움 보존기한이 있는 구조화된 데이터를 저장하고 "처리"하는 스토리지. 보통 BI툴들(룩커, 태블로, 수퍼셋)은 데이터 웨어하우스를 백엔드로 사용함. 실제로는 DL중 의미있는거만 가공해서 DW로 옮김

EX) 넷플리스 굉장히 많은 데이타 소스가 있음 (사용자 access 로그 같은 정보들 - 중요하지만 비구조화되어있음) S3같은 data lake에 저장함 이걸 Spark, Athena같은 빅데이터 프로세싱 프레임워크를 사용해서 sql기반으로 프로세싱해서 정제해서 의미있는경우만 DataWarehouse 에 저장

데이터 파이프라인의 정의: 데이터를 소스로부터 목적지로 복사하는 작업 보통 python or 스칼라 or SQL을 통해 이루어짐 대부분 목적지가 데이터 웨어하우스.

데이터 파이프라인 종류 1 - 보통 데이터 엔지니어가 함

외부나 내부 데이터 소스에서 데이터를 읽어서(보통 api를 통하게 됨) 적당한 데이터 포맷 변환 후 (데이터 크기가 커지면 파이썬으로 불가. Spark 등이 필요해짐) 데이터 웨어하우스에 로드

데이터 파이프라인 종류 2 - 데이터 분석가가 함 + 애널리틱 엔지니어(DBT)데이터 빌드 툴

• DW또는 DL에서 읽어서 다시 DW에 쓰는 ETL
• raw data를 읽어서 리포트 형태나 써머리 형태의 테이블을 다시 만드는 용도
• ab테스트 결과 분석

데이터 엔지니어 관점에서는 어떻게 데이터 분석가들이 편하게 할 수 있는 환경을 만들어주느냐가 관건

데이터 파이프라인 종류 3

DW로부터 데이터를 읽어 다른 스토리지(많은 경우 프로덕션 환경)으로 쓰는 ETL

• 써머리 정보가 프로덕션 환경에서 성능 이유로 필요한 경우
• 혹은 머신러닝 모델에서 필요한 피쳐들을 미리 계산해두는 경우

예를 들어서 너무 많은 사용자가 몰려서 좋아요를 누른다 - 하나하나 몰릴때마다 계산하면 부하가 심해져 문제가 생김 이때 유데미는 Mysql 이용 참고 https://devlog-wjdrbs96.tistory.com/374 https://youtu.be/brYCFFWA_6M?si=3eH3JGyJ1vgJNUsA - 중학생도 k 학교대전에서 이용! 클라이언트가 몇 초 간격으로 유저가 클릭한 횟수를 카운팅해서 서버에게 전송하고 서버에서 매크로인지 확인하고, 정상 범위 내에 있으면 redis에 업데이트 redis에서 몇 시간당으로 DB에 업데이트 하는 구조

import requests
import pandas as pd
from datetime import datetime, timedelta
import json


api_code ='발급받은 코드를 쓰세요'
c = '731Y001' #통계코드 확인 (나는 환율코드)

#먼저 list를 확인해준다.
response_list = requests.get(f'http://ecos.bok.or.kr/api/StatisticItemList/{api_code}/json/kr/1/100/{c}/')

저장 함수를 짜줬다.

def save1(response,start_day,end_day):
    if response.status_code == 200:
        data = response.json()
        df = pd.json_normalize(data['StatisticSearch']['row'])
        it = data['StatisticSearch']['row'][0]['ITEM_NAME1'][2:]
        df.to_csv( it + start_day + end_day + '.csv', index=False)
    else:    
        print('error:', response.status_code)

각각 따로따로 있는 나라들을 하나씩 저장해줬다.

#52개국
for i in range(0,52):
    codd = ''
    if i < 9:
        codd = '000000' + str(i+1)
    else :
        codd = '00000' + str(i+1)

    if response_list.status_code == 200:
        data = response_list.json()
        sorted_list = sorted(data['StatisticItemList']['row'], key=lambda x: int(x["ITEM_CODE"])) #나라 코드 오름차순으로 정렬
        file_name = sorted_list[i]['ITEM_NAME']
        cycle = sorted_list[i]['CYCLE']
        end_day = sorted_list[i]['END_TIME']
        end_day_int = datetime(int(end_day[:4]), int(end_day[4:6]), int(end_day[6:]))
        start_day_int = end_day_int - timedelta(days=0)
        start_day = start_day_int.strftime('%Y%m%d')
        print(sorted_list[i]['ITEM_CODE'])
        print(file_name)
        print(cycle)
        print(end_day)
        print(start_day) #오류 확인용 프린트
        response = requests.get(f'http://ecos.bok.or.kr/api/StatisticSearch/{api_code}/json/kr/1/100/{c}/{cycle}/{start_day}/{end_day}/{codd}/?/?/?')#물음표는 채우니까 오류나서 그냥 그대로 냅둠
        data = response.json()
        print(json.dumps(data, indent=4, ensure_ascii=False)) #그냥 json으로 보니까 눈아파서 ..ㅎㅎ
        save1(response,start_day,end_day)

    else:
        print('error:', response_list.status_code)

그렇게 52개의 csv파일이 생성되었다. 원래는 한 나라당 날짜별로 2024-05-01 , 1000원, 2024-05-02, 2000원 ,,,이런식으로 저장이 되어있다. 근데 나는 한 나라당 딱 한개씩만 필요했다.. 그리고 모든 나라가 다 필요했다.....(superset에서 map을 그리고 싶었기 때문)

그래서 이 52개 파일을 S3에 올리고, redshift에서 한 테이블(country_exchange_rate)에 다 저장할거다 그럼 52개의 레코드(행)이 생긴다.

그 전에 각 나라별 ISO코드를 다른 csv파일로 저장했다.( gpt로 찾아서 저장함 .) 그리고 나라별로 붙여진 숫자코드를 붙여줬고 얘는 다른 테이블로 저장 (country_code)

그리고 나라별 숫자코드 열로 country_code테이블과 country_exchange_rate테이블을 조인할것임..

--코랩에서 진행.
%load_ext sql
!pip install ipython-sql==0.4.1
!pip install SQLAlchemy==1.4.47

--연결
%sql postgresql://{id}:{pw}@{~~~redshift-serverless.amazonaws.com}:5439/데이터베이스이름

%%sql
CREATE SCHEMA raw_data;

52개 데이터의 모든 열이 똑같았기 때문에, 버킷에 폴더를 만들어줘서 그 폴더 내부의 모든 파일을 모두 한 테이블에 저장하는 sql문을 짠 것.

%%sql

DROP TABLE IF EXISTS country_exchange_rate;
DROP TABLE IF EXISTS raw_data.country_exchange_rate;

CREATE TABLE raw_data.country_exchange_rate (
    STAT_CODE varchar(256),
    STAT_NAME varchar(256),
    ITEM_CODE1 float,
    ITEM_NAME1 varchar(256),
    ITEM_CODE2 float,
    ITEM_NAME2 varchar(256),
    ITEM_CODE3 float,
    ITEM_NAME3 varchar(256),
    ITEM_CODE4 float,
    ITEM_NAME4 varchar(256),
    UNIT_NAME varchar(256),
    WGT float,
    TIME DATE,
    DATA_VALUE float
);

COPY raw_data.country_exchange_rate
FROM 's3://kor-financial-market/exchange_rate/pythontest/'
IAM_ROLE '~~~~~~~~~~'
CSV
IGNOREHEADER 1
DATEFORMAT 'auto';

근데 2001년도 이런식으로 가장 최신 데이터가 한참 전 데이터라면, 그 나라는 이제 그 돈을 안 쓰고 있는것이다. 처음엔 NULL값이 들어있어서 UPDATE함수로 채워줬지만, 다시 확인해보니 그러면 중복 값이 되어버리는 것이다. 그래서 DELETE로 그 국가들은 없애주었다.(대부분 본인 나라 돈 쓰다가 유로로 바뀐 케이스+중국,홍콩)

이후 iso를 담은 테이블 하나 더 생성

%%sql 
CREATE TABLE raw_data.country_code (
  code_name varchar(256),
  code_num float,
  country_name varchar(256),
  ISO varchar(256)
);

COPY raw_data.country_code
FROM 's3://kor-financial-market/exchange_rate/exchange_rate_code.csv'
credentials '~~~~~~~~~~~'
delimiter ',' dateformat 'auto' timeformat 'auto' IGNOREHEADER 1 removequotes;

이제 preset에서 sql lab에 들어간다..

SELECT
  b.code_num,
  b.country_name,
  b.iso,
  a.time,
  a.data_value
FROM
  raw_data.country_exchange_rate AS a
JOIN
  raw_data.country_code AS b ON a.item_code1 = b.code_num

이렇게 간단하게 조인완성! 그럼 이 테이블로 지도를 만들면!!! 동그라미가 클 수록 비싼 나라다 ㅋㅋㅋ

한국은행에서 주요 나라 데이터들만 제공해줬기 때문에, 모든 나라의 데이터가 없다. 따라서 내일은 크롤링을 통해 모든 나라의 데이터를 긁어와서 채우는 것이 목표!

말그대로 우리 현대사회에서 부모가 가진 부동산 재화(변수) 그리고 권력(메소드)
이렇게 우리는 반복되는 코드는 그냥 부모의 것을 상속받아서 쓸 경우 편하게 사용 가능하다.

여기서 생각해야하는 점은 부모에게 상속 받은 메소드들 중에서 3가지가 있다면 한가지 Method는 내맘에 들지않는다.

즉 코드가 다르다는 뜻이다.

이럴때 @Override 한다고 즉 재정의해서

내가 원하는대로 코딩을 가능하게 만드는 것이다.

즉 비유적으로 표현하면 아버지의 물건을 그대로 쓰지 않고 자기입맛에 맞게 고치기위해서 먼저 나이거 고칠게

라고 Java에게 가르쳐주는 것이다.

크게 문제는 없지만 이 둘의 차이점이 존재합니다.

사진을 통해 간단히 보자면 URI가 가장 큰 개념으로 URI의 하위 개념으로 URL과 URN을 포함하고있습니다.

이번 포스팅에선 URI와 URL,URN 각 개념과 차이점에 대해 알아보려합니다.

먼저 URL의 구조 부터 알아야 하기 때문에 URL 부터 설명해보겠습니다.

URL ( Uniform Resource Locator ) - 통합 자원 지시자 URL은 우리가 가장 흔히 보는 것으로

URL은 Resource의 정확한 위치 정보(파일의 위치)를 나타냅니다.

URL을 통해 Resource가 어디에 있는지 어떻게 접근할 수 있는 지 알 수 있습니다.

URL 예시 https://www.naver.com/ - 네이버의 URL

https://search.shopping.naver.com/best/today?rankedDate=20220922 - 네이버 쇼핑의 오늘의 베스트 카테고리 URL

https://www.youtube.com/feed/subscriptions - 유튜브의 구독한 목록 URL

URL의 구조

다음과 같은 URL이 있다하고 이 URL을 부분별로 나누어 하나씩 살펴보겠습니다.

https://hstory0208.tistory:3000/category?category=network&page=5#url차이

URN ( Uniform Resource Name ) - 통합 자원 이름 Resource의 위치와 상관없이 식별 가능한 고유한 이름 역할을 합니다.

URN은 이름이 변하지 않는한, 리소스 위치가 변경되더라도 문제없이 동작합니다.

즉, 리소스 위치와 상관없이 이름만으로 식별할 수 있다는 개념입니다.

URN은 URL의 한계로 인해 생긴 것으로 아직까진 URL이 대중화가 되어 채택되지 못했습니다.

URL의 한계란 ?

리소스의 위치를 옮기면 해당 URL을 더 이상 사용할 수 없는것.

만약, 구글 검색에 노출된 hstory0208.tistory.com/10 이라는 링크가 있다고 가정해봅시다. 이 주소를 바꾸고 싶어 hstory0208.tistory.com/network/10 으로 주소를 바꾼다면 다른 사람이 기존에 노출된 링크(hstory0208.tistory.com/10)에 접속 시 주소가 바뀌었기 때문에 해당 페이지는 찾을 수가 없게되는것입니다. 이게 바로 URL의 한계 입니다.

URI ( Uniform Resource Identifier ) - 통합 자원 식별자 자원의 위치뿐만 아니라 자원에 대한 고유 식별자로서 URL을 의미를 포함합니다.

URI의 존재는 인터넷에서 요구되는 기본조건으로써 인터넷 프로토콜에 항상 붙어다니며,

URI의 하위 개념으로 URL,과 URN이 있습니다.

URI와 URL 구분하기

URI와 URL를 쉽게 구분하는 방법은

URI 는 통합 자원 식별자로 주소에 식별자가 있으면 URI

URL은 리소스 주소를 나타내므로 리소스 위치까지만 나타내면 URL 입니다.

다음 예시를 통해 비교하며 이해해봅시다.

https://hstory0208.tistory.com/category hstory0208.tistory.com 에서 category 라는 경로를 나타냅니다.

category는 리소스의 실제 위치이므로 이 주소는 URL 입니다.

https://hstory0208.tistory.com/category/12 hstory0208.tistory.com 에서 category 라는 자원의 경로를 나타내는 부분까진 URL 이지만

/12 는 식별자 이므로 https://hstory0208.tistory.com/category URL을 포함한 URI라고 할 수 있습니다.

https://hstory0208.tistory.com/category?page=12 위와 마찬가지로 https://hstory0208.tistory.com/category 까지는 자원의 실제 위치를 나타내기 때문에 URL이고,

뒤의 query ( ?page=12 ) 가 붙었으므로 https://hstory0208.tistory.com/category URL을 포함한 URI 입니다.

API 와 Endpoint의 차이 한 줄 정리

​

API가 두 시스템(어플리케이션)이 상호작용할 수 있게 하는 프로토콜의 총집합이라면,

ENDPOINT는 API가 서버에서 리소스에 접근할 수 있도록 가능하게 하는 URL이라 할 수 있겠다.

1. Endpoint, 엔드포인트

An endpoint is simply one end of a communication channel.

(stackoverflow)

​

​

커뮤니케이션 채널의 한 쪽 끝.

서비스를 이용할 때 사용하는 커뮤니케이션 채널의 한쪽 끝에 해당하는 URI.

이번에 api를 활용 할 때 , end point라고 적혀있고 url이 적혀있어서 뭔가 궁금했었다.

API는 Application Programming Interface의 약자로, 응용 프로그램 프로그래밍 인터페이스. 프로그램 혹은 시스템 간의 통신하는 창구, 즉

프로그램들이 서로 상호작용하는 것을 도와주는 매개체라 할 수 있다.

점원은 손님에게 메뉴를 알려주고, 주방에 주문받은 요리를 요청하고, 그다음 주방에서 완성된 요리를 손님께 다시 전달. API는 여기서 점원과 같은 역할을 한다.

​

API는 손님(프로그램)이 주문할 수 있게 메뉴(명령 목록)를 정리하고,

주문(명령)을 받으면 요리사(응용프로그램)와 상호작용하여 요청된 메뉴(명령에 대한 값)를 전달한다.

​

API는 프로그램들이 서로 상호작용하는 것을 도와주는 매개체로 볼 수 있겠다.

​

이제.. API가 뭔지 대충은 감이 오니까 더 자세히 알아보자!

1. API는 서버와 데이터베이스에 대한 출입구 역할을 한다.

: 데이터베이스에는 소중한 정보들이 저장된다. 그렇기에 모든 사람들이 이 데이터베이스에 접근할 수 있어서는 안 된다. API는 이를 방지하기 위해 사람들이 가진 서버와 데이터베이스에 대한 출입구 역할을 하며, 허용된 사람들에게만 접근성을 부여해 준다.

​

2. API는 애플리케이션과 기기가 원활하게 통신할 수 있도록 한다.

: 여기서 애플리케이션이란 우리가 흔히 알고 있는 스마트폰 앱이나 프로그램을 말한다.

API는 애플리케이션과 기기가 데이터를 원활히 주고받을 수 있도록 돕는 역할을 한다.

​

3. API는 모든 접속을 표준화한다.

API는 모든 접속을 표준화하기 때문에 기계/ 운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있다. 쉽게 말해, API는 범용 플러그처럼 작동한다고 볼 수 있겠다.

API는 작은 단위로 응용프로그램에서 사용할 수 있도록

OS나 프로그래밍 언어가 제공하는 기능을 사용/제어할 수 있게 하는 인터페이스를 의미하기도 한다. (날씨 api는 이건 아니다)

​

자바를 예로 들자면 JDK 1.8에서 추가된 Stream API 가 있다.

여기서의 스트림은 파일 I/O에서 사용되는 스트림과는 다르다. 스트림은 데이터 소스를 추상화하고, 데이터를 다루는데 자주 사용되는 메서드들을 정의해 놓았다. 데이터 소스를 추상화하였다는 것은 데이터 소스가 무엇이든 같은 방식으로 다룰 수 있게 되었다는 것과, 코드의 재사용성이 높아진다는 것을 의미한다.

​

여기서 Stream이라는 기능을 사용하기 위해 제공된 명세를, API라고 할 수 있다.

(명세에 대해서 이해가 잘되지 않는다면, 자바의 Interface 개념을 생각해 보면 좋을 듯하다)

​

API에 대한 간단한 설명을 뒤로하고, 이번 글의 주제인 엔드포인트를 이해하기 위해 웹에서 사용하는 API에 대해 알아보자.

​

​ 3. 웹 API

웹 API는 웹 애플리케이션 개발에서 다른 서비스에 요청을 보내고 응답을 받기 위해 정의된 명세를 일컫는다.

예를 들어 블로그 API를 이용하면, 블로그에 접속하지 않고도 다른 방법으로 글을 올릴 수 있다.

그 외에 우체국의 우편번호 API, 구글과 네이버의 지도 API 등 유용한 API들이 많으므로, 요즘은 홈페이지 구축이나 추가 개편 시 따로 추가로 개발하지 않고 이런 오픈 API를 가져와 사용하는 추세다.

​

한마디로 서비스 간의 요청과 응답을 위한 명세로 정리할 수 있겠는데,

글 초반부에서 참고한 stackoverflow의 내용과 연결점이 있다.

엔드포인트는 서비스를 사용 가능하도록 하는 서비스에서 제공하는 커뮤니케이션 채널의 한쪽 끝.

즉 요청을 받아 응답을 제공하는 서비스를 사용할 수 있는 지점을 의미한다.

​

예를 들어 지하철 최단 거리 경로를 제공하는 웹 서비스가 있다고 하자.

이 서비스를 이용하는 사용자는 출발역과 도착역을 설정하고 최단 경로를 찾는 버튼을 누른다.

이때 최단 거리 경로를 구하는 서비스를 이용하기 위한 요청이 향하는 URI가, 엔드포인트이다.

​

이 웹 서비스는 유효한 형태로 엔드포인트에 요청이 전달되었을 경우 사용자가 알 필요 없는 서비스 내부 로직을 실행하고 응답을 반환한다.

​

​ 3. API vs Endpoint

결국 API가 두 시스템(어플리케이션)이 상호작용(소통) 할 수 있게 하는 프로토콜의 총집합이라면,

ENDPOINT는 API가 서버에서 리소스에 접근할 수 있도록 가능하게 하는 URL이라 할 수 있겠다.

1. 장고 사용법에 익숙해 졌다.

1) 모델 처음에 model.py를 잘못 만졌다가, 계속 오류가 났었다. 이제 모델을 건들기 전에 마이그레이션 기록들을 살펴 본 뒤, 테이블까지 살펴보고, 테이블 내부 형태까지 살펴본 뒤에 삭제, 추가 하는 습관이 생겼다. 근데 아직도 이름바꾸기는 조금 어렵다..ㅎ 그 사이에 sqlite3의 사용법도 익히게 되었다. 그리고 오류가 생기면 대체로 테이블이 없다, 테이블이 없다... 테이블이 이미 있다... 이런 오류였기 때문에 sqlite로 바로 테이블 생성하고 삭제하고 하는것 까지 익숙해졌다. 새로운 필드를 만들 땐, 이전 데이터들에 없는 값을 채워주기 위해 디폴트 값을 정의해야한다.
2) 장고의 구조 이해 장고는 프로젝트 라는 거대한 틀이 있고, 그 내부에 여러 앱들을 추가하는 구조로 이루어진다. 한 앱은 한 폴더로 이루어져있고, 그 폴더 내부에는 여러가지 파이썬 파일들이 구성되어 있다. 만약에 필요한 함수가 크다면 새로운 파일을 만들어서 함수를 저장한 뒤, 다른곳에서 그 함수를 쓰면(from .파일이름 import 함수이름들 해야 쓸 수 있음) 함수가 그대로 작동한다! 그리고 뷰가 가장 중요하다고 느꼈던게, url.py에서 path를 작성 할 때, 뷰에서 어떤 함수를 작동하도록 해라~하고 쓰기 때문이다!그럼 그 path로 이동했을 때, 그 작동한 화면을 볼 수 있다

2. CLI 사용법에 익숙해졌다.

1) 가상환경 설치 가상환경이 뭔지부터 몰라서 찾아보니 굉장히 쉽게 설명해주신분이 계셨다.. 가상환경이라는게 애초에 다른 버전의 프로그램을 돌리기 위해 있는 것이였다! 마침 나는 파이썬3 .12가 안되고 3.11에서만 무언가가 되기때문에 이걸 3.11로 설치했어야 됐고 이 설명을 보며 아 ~~그래서 그렇구나 라고 잘 이해하게 되었다. 문제는 가상환경을 설치하면서 이게 어디에 설치되고, 어디에 설치해야하고, 어느 폴더로 가야하며 설치된건 어디에있고 삭제는 왜 또 맘대로 안되며...ㅋㅋㅋ :wq 이거부터 ㅜㅜ 아직 배워야 할 게 많지만 이제 무섭지는 않다! (처음엔 진짜 뭔지 몰라서 인터넷에 나와있는 $표시부터 다 따라 쳤었다..)
2) 파일이동
3) 폴더 위치 찾기 cmd option c 하면 파일 위치가 복사된다.
4) 환경변수 이해 python3 -> python 만 쳐도 나오도록 함

3. 오류 읽는 법에 익숙해졌다.

이번에 우리는 완전 생 초보들만 모여서 진행한 조였다. 그래서 좋았던 점도, 단점도 있었지만 그래서 바닥부터 크게 된 것같다..(feat 오류지옥)

4. 인공지능 활용에 익숙해 졌다.

이번에 우리가 한 것은 과거 데이터와, 오늘 데이터를 비교하는 프로젝트였다. 그런데, 과거 데이터와 오늘의 데이터 저장 형식이 다르게 되어 있다는 것이 굉장한 골칫덩이였다. 근데 그거보다 더 큰 골치는 시간을 제대로 입력해 주지 않으면 데이터를 받아오지 못한다는 사실이였다(데이터가 계속 업데이트 되기 때문) 또한 데이터를 받아와서 저장하는 것도 문제고, 이 데이터를 어떤 방식으로 저장해야될지도 사실 엄청 고민했었다. 다들 초보이기 때문에 쉽게 꺼내 쓸 수 있는 데이터 형식이 되었으면 좋겠다고 생각했기 때문이다.

여기서 url을 업데이트 시간을 반영해서 조정하는 것도 할 줄 알게 되었고,

데이터를 받아서 데이터베이스에 저장하는것도 굉장히 어려웠고... 흐엉 ㅜㅜ 정말 아침에 일어나자마자부터 딱 자기전까지 코딩생각만 머릿속에 뺑글뺑글 돌아갔다. 왜냐하면 내가 제시한 아이디어였고, 데이터가 저장되지 않으면 절대 이 프로젝트는 완성될 수 없기 때문에 내 역할이 가장 초반에 탄탄히 다져져야 했기 때문이다. 그래서 부담감도 엄청났다.. 그와중에 아침에 일어나서 매일 아침운동도 했다 ㅋㅋㅋㅋㅋ 아침운동이 하루종일 집중할 수 있게 해주는 키포인트이기도 했기 때문이다.

그리고 처음에는 인코딩 키, 디코딩 키도 어떻게 해야할 지 몰라 엄청 버벅였다 심지어 둘 다 나와있는데도 뭔가 다를 줄 알고 인코딩키를 디코딩하는 프로그램을 돌려 디코딩했더니 엥? 똑같이 나오네 ? 하면서 익혀갔다 ㅋㅋㅋㅋ 사람들도 날씨를 과거 데이터를 받아와서 비교하는 프로젝트는 잘 하지 않는다는 것을 알았다.. 그런 자료가 별로 없어서 나는 과거 데이터를 비교하는 프로젝트를 해보고 싶었는데, 그게 오히려 독이 된 것이다..(왜냠 나는 초보초보초보니깐 ..흑)

그래도 어찌저찌 구조를 잘 공부했는데(오류지옥에서 살아남으며 저절로 공부함..ㅎㅎ) 이 오류를 분석 할 때 인공지능이 큰 도움이 되었다. 오류를 입력하면 오류를 해석해 주는 것 뿐만 아니라 어떤 문제인지 설명도 해주기 때문이다. 대신 그것을 알아먹는 것은 그 사람 몫이고, 인공지능이 코드를 잘 짜주진 못한다.(질문이나 짤 구조같은것을 잘 적어주면 될지도..근데 나는 지금은 내가 짜는게 편하다..)

하지만 ;같은걸 잘 못 친 사소한 오류나 source venv/bin/activate라고 쳐야하는데 python3 venv/bin/activate라고 쳤거나 하는 것을 잘 잡아주어서, 이제 진짜 코드를 잘 짜는 것이 중요하게 됐고 쓸데없는 곳에서 하는 시간낭비가 매우매우매우 줄어들었다는 것을 체감하게 되었다.

필자는 코파일럿과, gpt4(남친찬스~><) 를 둘 다 쓰는데, 아무래도 둘 다 있는게 좋은 것 같다.ㅋㅋㅋㅋㅋㅋㅋㅋ

그 차이는 써본 사람만이 알 것이다 ㅋㅋㅋ

5. HTML , Javascript 사용법을 어느정도 알게 되었다.

근데 정말 어느 정도이지, 막 잘 하고 그런건 아니다.

6. 깃허브의 브랜치, 포크, 충돌해결에 익숙해졌다.

7. 팀 프로젝트의 전체 그림이 머릿속에 있냐 없냐가 얼마나 큰 차이를 불러오는 지 알게 되었다.

월요일 화요일은 다들 깃에 익숙해지고, 장고에 익숙해 지는 시간이였던 것같다. 그리고 화요일 저녁때 만나보니 다들 어느정도 기능을 완성 하신 것 같아 다음날 작업 하다가 전체적으로 어떤 기능을 구현해야 하는지 알려드렸다. (아무래도 내가 낸 주제로 작업하다보니 내가 확실하게 말씀드려야 다들 진행하기 쉬울 것 같았다) (저 스프레드 시트 정리는 또 인공지능의 힘을 빌렸따! 받아오는 API가 두 곳에서 받아오는데, 지역 저장 형태가 하나는 위도 경도로 되어있고, 하나는 지역번호로 되어있어서, 지역 번호별로 위도 경도를 구분해내는데 gpt를 썼다 ㅎㅎ 노가다로 할뻔) 이런식으로 전체적으로 구성을 짜드렸고 그리고나서 저녁에 만나서 얘기해보니 훨씬 효율이 올라간 게 느껴졌고 연결할 부분들이 보였다. 심지어 그 자리에서 연결 부분을 해결 하기도 했다.

8. 팀회의의 중요성을 느꼈다.

우리팀은 매일 5시에 회의를 한다. 그러면 다들 어느정도 완성했는지 보이기 시작하는데, 이 완성한 부분을 깃허브에 올린 버전들을 살펴보면서 아 이걸 어디다 어떻게 써야되는구나가 보이고 그러면 내 부분도 완성하기 쉬워진다! 팀원들이 어디까지 완성했는지가 보이면 나도 속도를 내야 한다는 생각이 들게 되고 밤을 새더라도 완성시켜서 어느정도 합을 맞출 수 있게 된다.

9. 협업의 힘을 느꼈다.

나랑 같이 백엔드를 맡은 팀원이 계셨는데, 그분이 내가 고민하면서 엄청 길게 짤 뻔했던 코드를 if continue 를 이용해서 짧게 짜주셨다! 보면서 '아 내가 생각하지 못했던 부분을 다른사람이 볼 수 있고 이래서 협업을 하는구나.' 라고 크게 느꼈다!! 그분은 내가 코드를 이미 잘 짜놔서 자기는 숟가락 얹은 것 밖에 없다고 했지만 진짜 나는 저런 한 줄이 너무너무 크게 느껴졌다! 아직 프론트랑 백이 이어지는 작업을 하지 못했지만, 그건 다른 팀원이 맡아주셨고, 이제 데이터 쌓는 것은 잘 되기 때문에 그부분을 나도 맡아서 도와드릴 것 같다.

그리고 팀장님께서는 깃허브 관리를 맡아주셨는데 굉장히 잘 해주시고, 다들 첨 하다보니 깃허브를 다루지 못하는 팀원들이 많았는데 굉장히 친절하게 잘 알려주신것 같아 보였다. 그리고 각자가 한 프로젝트가 잘 굴러가는지 계속 확인해주신 덕분에 뭔가 순조롭게 굴러갈 수 있었던 것 같다.

10. 각자 맡은 역할을 열심히 해준 팀원들께 고마움을 느꼈다.

다들 어렵고 포기하고 싶은 순간도 있었을 텐데 포기하지 않고 계속 하고있는 팀원들을 보면서 나도 포기하고싶은 순간에 포기하지 않고 내가 맡은 기능을 구현해 낼 수 있었던 것같다.

하고싶은 것

1. 테이블끼리 연결 관계를 만들고 싶다.

1) 참조 이번 프로젝트에서는 테이블끼리 서로 참조하도록 만들지 못했다. 다음번엔 이 참조 부분을 제대로 공부해서 연결관계를 만들고 싶다. 목 금 이렇게 이틀 기간이 남은 상태에서 테이블을 또 잘못 건드렸다가 프로젝트를 망치고 싶지 않아서,

2. 프론트를 꾸며보고 싶다.

• 4번과 이어진다. 4/24 - 프론트를 꾸몄다! 프론트 구조에 대해 알게되었다.

  3. 다른 많은 기능들도 써보고 싶다.

나는 이렇게 하기 위해선 잘 만든 다른 프로젝트를 한번 면밀히 분석해 봐야 할 필요가 있다고 생각한다. 그래서 이번 프로젝트를 끝내고 , 다른 프로젝트를 살펴 본 뒤, 한번 테이블 관계같은 것을 수정해서 보완해 볼 생각이다.

4. 자바 스크립트랑 HTML을 더 공부해보고 싶다.

아무래도 이번이 첫 프로젝트고 다음 프로젝트 때는 더 많은 기능을 구현한 결과물을 내보고 싶기 때문에 JS와HTML에 대해 더 깊게 공부하고 다음 프로젝트 전까지 혼자 토이프로젝트를 진행해보면서 공부해 볼 것 같다. 아무래도 코딩을 공부하는 것에는 프로젝트를 직접 해보는 것 만큼 크게 공부되는게 없는 것 같다.

1) 초대 - 이메일로 들어가서 확인 눌러야 오류가 안남 2) 포크 - 포크 후 풀 리퀘스트 까지 확인

2. 브랜치 만들어서 올리기(안그러면 충돌생김)

3. 장고의 이해, view와 url model의 관계 ,api 이해

4. table의 삭제, table 있는지 확인(sqlite3로 오류 잡아내기)

4/16 화

5. table 이름 바꾸기
6. api 불러와서 table에 저장하기

오늘 할일 - 다대다 관계 정리 url 두개에서 받아온 정보를 한 테이블에 저장하기

1. 구글 스프레드 시트를 활용해서 회의 일정을 잡음
2. 다음날 저녁 8시 회의 시작

회의

1. 주제 정하기 (투표)
2. 팀장 정하기 (사다리 타기)
3. 대략적인 역할 정하기

예를 들어, 공격자가 사이트의 게시물에 어떤 사이트의 API를 이용하여 조작된 HTML을 만들면, 인증된 사용자가 그것을 사용하여 자신은 의도치 않았던 행위를 하는 것이다.

CSRF Token django는 csrf 공격을 막기 위해 csrf token을 사용한다. 사용자가 post 요청이 있는 template을 요청하면, 장고는 cookie에 secret을 보내고, hidden form의 필드 'csrfmiddlewaretoken'에는 serect + mask 한 정보를 랜더링한다.

사용자가 post를 하면, 쿠키와 함께 csrfmiddlewaretoken이 함께 날아간다. django는 이것을 프로세싱하여 쿠키의 serect과 csrfmiddlewaretoken의 프로세싱된 값이 같은지 확인하는 것이다.

같다면 다음 middleware로 진행하고 그렇지 않다면 403에러를 띄우게 된다.

csrf_token이 post의 data 필드값에 필요하기 때문에 django의 서버가 직접 랜더링한 html만이 유효하게 되어 csrf 공격을 막을 수 있게된다.