컴퓨터가 연결된 네트워크 끝단의 주소

기기가 인터넷에 접속한 곳의 네트워크상 위치

IP는 변할 수 있음!

ex) 노트북을 집 와이파이로 할때와 카페에서 할 때, but ! 위치가 안바뀌어도 변할 수 있음

IP는 IPv4규약을 따르고 있음

IPv4는 0~255까지의 숫자 4개가 이어진 256의 4제곱의 갯수만큼 IP를 가질 수 있음

그러면 4,294,967,296개의 IP가 IPv4 에서 나오는데,

약 43억개

전세계 인구가... 60억이 넘고 1인 컴퓨터,노트북,휴대폰 만 해도 최소3개라

IP가 부족함!

그래서 이걸 해결하기위하여!!!!

공인 IP 와 사설 IP 가 있는데

주소로 비유를 들어주자면

서울특별시 개발구 코딩로 구로아파트 101동 202호

라는 주소가 있다면

"서울특별시 개발구 코딩로 구로아파트" 까지가 공인IP 부분

"101동 202호" 부분이 사설IP 라고 볼 수 있음

이렇게 비유해주니까 이해가 확 되어서 좋은거 같음!

한 집에서 4인가족이 총 10대의 IP를 받는 기기를 이용한다고 할 때,

공인IP 1개를 이용하여 그 1개로 사설IP를 만들어 한 집안에서 사용하는 IP를 1개로 줄이는 거임

IP주소가 이 숫자 범위에 있다면 그건 사설IP를 사용하고 있는거임

알아둬야 할건 사설IP를 사용하는 컴퓨터나 핸드폰으로 공인IP를 사용하는 서버 등의 다른 컴퓨터 로는 접근 가능하지만, 다른 컴퓨터에서는 사설IP로 접속 할 수 없음!

사설 IP에서 웹사이트 같은걸 돌릴려고 할 때,

원하는 기기에다 포트를 하나씩 주면은 포트포워딩!

모든 포트를 싸그리 한 군데 몰아주면 DMZ

고정 IP 와 유동 IP

한국에는 1억개정도의 고정IP주소가 할당되어있는데,

이걸 ISP(internet service provider)제공업체들이 나눠주는건데

서버의 경우 IP가 계속 바뀌면 곤란하기 때문에 고정IP를 사용하고(비쌈)

일반 가정이나 기기들은, 주기적으로 IP를 회수해서 인터넷을 사용중인 곳에만 나눠주는

유동 IP방식을 사용 한다고 함

유동IP는 바뀌니까 오히려 고정IP보다 보안쪽으로는 안전할 수 있음!

오 그래서 결국 유동IP로 가정에서 웹서버를 운영하면 바뀔 수 있기 때문에

웹사이트나 NAS 등을 운영하려면 여기에 추가적인 조치를 취하게 되는데

DDNS (Dynamic DNS) 를 이용하여

유동 IP 변경을 감지하여 연결 시켜주는 기능?

공유기 설정에서 할 수 있다고 함

그래서 포트포워딩과 DDNS를 이용하면 가정 이나 개인이 가벼운 웹사이트나 NAS는 운영이 가능

그리고 IPv4는 갯수가 곧 바닥 나기에, 현재 점점 규모를 늘려가고있는 IPv6

16진수 4자리가 8개 이어진 형태

와 근데 얄코 설명 개 쉽게해줘서 기분좋아짐

출저 얄코유튜브 : https://www.youtube.com/watch?v=GK3h936Co-k

오자마자 아이스아메리카노 커피 투샷 고고

주간회의와 직장내교육받으니까 11시30분 두둥 두둥 시간이 녹아버림

담배한대피고

저번주에 오류났었부분 띄워놓고 째려보기 시전

로그창에 어떻게 뜨는지 확인하기 위해

settings.py 에서 DEBUG = True 로 수정한 후,

cmd창에서 진행

오류가 Write 할수없다고 함!

오우예예에에에에 이것은..!

일단 이 오류면 폴더나 파일에 권한이 안되는거라고 추측!

그래서 폴더에 권한을 마구마구 전부허용함

C:\ 에다가 바로 풀어둔 파일이라 그런거라 생각했고,

이권한 저권한 다 줬지만, 오류가 계속 똑같음...

그렇게 오후 3시까지 삽질하다가 사수한테 연락이 와서 잽싸게 물어봄

사수 : 음.... 처음보는 오류인데, 지금 거기서 오류는 대부분 경로쪽이었다.

왓!!!?????????? 경로는 진짜 엄청 확인했는데,,,,,,, 그래도.. 나는 모종삽으로 삽질하는 코린이기 때문에 다시한번 경로 확인

대충 슥 안보고 잘되는 코드와 비교해서 확인해보니...

경로부분에 6개가 있었는데

4개는 똑같은데, 아래 2개가 = 이 == 2개가 표시된게 있었음....

호고고고고고고곡 혹시나 제발이거였으면! 하면서 수정하고 실행해보니

!!!!!!!!!!!!!!!!!!!!!!!!!

헤헤헤헤헿헤헤헿 된다 된다~

이제 마저하기로 한걸 열심히해보자.... 으어어어어어억!!

일단 퇴근!!!!!!!

제한사항 0 < rsp의 길이 ≤ 100 rsp와 길이가 같은 문자열을 return 합니다. rsp는 숫자 0, 2, 5로 이루어져 있습니다

# 문제 설명
# 가위는 2 바위는 0 보는 5로 표현합니다. 가위 바위 보를 내는 순서대로 나타낸 문자열 rsp가 매개변수로 주어질 때, rsp에 저장된 가위 바위 보를 모두 이기는 경우를 순서대로 나타낸 문자열을 return하도록 solution 함수를 완성해보세요.
#
# 제한사항
# 0 < rsp의 길이 ≤ 100
# rsp와 길이가 같은 문자열을 return 합니다.
# rsp는 숫자 0, 2, 5로 이루어져 있습니다

def solution(rsp):
    answer = ''
    for i in rsp:
        if i == '2':
            answer += '0'
        elif i == '0':
            answer += '5'
        else:
            answer += '2'
    return answer

.... 사람들은 어떻게 1줄로 푸는거야아~

제한사항 2 ≤ numbers의 길이 ≤ 30 0 ≤ numbers의 원소 ≤ 1,000 0 ≤num1 < num2 < numbers의 길이

def solution(numbers, num1, num2):
    answer = numbers[num1:num2+1]
    return answer

아싸 오늘은 사람들이랑 비슷하게 풀었당!

10년전에 만든 웹사이트들을 로컬로 돌리는데,

apache를 이용해서 돌리고 있는것도 있어서,

어떤일이 발생할 지 몰라서 이것도 익혀두려고 오늘 로컬로 구동하고 아파치로 연동하려했는데..!

오전 11시부터 시작해서 오후 5시까지 혼자 모종삽으로 열심히 삽질을 진행했다.

첫번째로는 그냥 파일들을 가져와서 경로수정된 부분들 수정해주고

두번째로 postgres를 이용해서 덤프파일을 데이터베이스에 가져와서 데이터들을 연동해주고

장고 로컬에서 동작하는것을 확인하 후에 아파치로 진행하려했는데...

아파치에서 계속 에러가 발생함..

자꾸 파이썬 모듈중에 뭐시기가 설치가 안됐다고....하..

가상환경에 pip install 하려니 버전 아파치를 찾을 수 없다고 또 난리..

python은 2.7버전

django는 1.4버전

postgres는 9.4버전

apache는 2.2버전

10년전으로 회귀한 기분이랄까..?

지피티에게 물어도 버전 너무낮다고 올리라고 답변만 날라오고

인터넷쳐도 파이썬2버전 너무 스레기다 3버전으로 해라! 이런 글 천지 후욱후욱....

모종삽으로 얼마나 파냈을까..

문제는 결국... "경로" 였다. wsgi.py 에 아파치랑 연결하는 부분의 경로가 축약식으로 되어있었는데

이 부분에서 에러가 지속적으로 발생한거였음.

기존에 실행되고있는 아파치서버 파일 그대로 가져와서 경로수정해준거여서

당연히 경로는 문제없을 줄 알았음...

사실 계속 찾아가면서 못 할줄 알았음.. 내일 마저 해야겠다 생각하면서

뚜당뚜당했는데,,, 해결되어버림!

또 다시 밀고해보라고하면 좀 버벅거릴거 같긴한데, 일단 해결했다!!!! 으악!!!!!!!!!

거의 처음으로 느껴보는 기분임 으아아악!!!

기부니 좋다!!!!

악!! 나도 1줄 2줄로 깔끔하게 하고싶다!!!

2021년 코로나 시대에 프론트를 시작으로 약 3년이나 걸린 공부안하는 코린이...

2021년 12월에 학원연계로 소프트웨어QA 직무로 입사 앗.. 근데 코딩은 무엇 그냥 어플 클릭클릭 오류오류 찾아찾아 업무하다가 7개월 근무 후 퇴사

세금 잘 타먹는 나란 놈 실업급여를 받기위해 계약만료의 조건이 필요했다!

2022년 12월 2개월 계약직 콜센터 입사!

2023년 4월부터 5개월 간 실업급여 받으면서 백엔드 교육과정 듣기!

2023년 10월에 교육과정이 종료되고 입사지원을 하려했으나

열심히 안 한 나란녀석... 제대로 된 포폴이 존재할리 없었고,

같이 교육을 들은 마음맞는 친구들과 스터디를 진행

스터디 11월 종료

운좋게 정보처리기사 자격증도 합격완료

자! 이제 제대로 해볼까!!?

했지만, 악마의 추억게임 메이플랜드 두등등장 2개월동안 랭커권 진입 및 손목갈림

눈 떠보니 2024년 1월?

이머전시 상황.

진짜 큰일났다 이제서야 다시 포폴 준비하고

3월부터 이력서 넣기 시작

오 10곳 정도 넣었을 때 쯤, 한 곳에서 불러줌

면접에서 탈탈 털림

면접관 : "코딩에서 파이썬을 쓴다는 건 어떤것을 의미할까요?"

나 : ???????(잘 못들었나?)

그렇게 광탈

면접 한 번보고 멘탈 바사삭 쿠쿠다스 냠냠 다시 포폴 다듬 다듬 이거했다가 끝마치지못하고 저거했다가 혼자 동분서주 함

국민취업지원제도 신청해서 상담하고 이력서 첨삭좀 받고 이력서 넣기시작 40군데 정도 넣고 총 4군데 면접 연락 옴

maybe... 나를 부른 이유는 4년제 + 정보처리기사 자격증 때문이지 않을까..? 포트폴리오는 너무나 보잘것 없는걸..?

7~8월까지 걸릴거라 예상하고 시작했는데, 운 좋게 한 곳에서 합격연락을 받음.

SI개발 업무를 가고싶었지만, Python 과 Django 스택을 사용하고 싶었고,

Python과 Django를 사용하는 회사에서 날 뽑기엔 역량이 너무 낮았음

SM유지보수 업무파트에 합격됐고, 개발과는 조금 동떨어진 회사임

Python2 버전과 Django1 버전을 쓰는 거진 10년전에 개발한 프로그램! 핳핳핳

하지만,,, 건방지고 나태한 나란 놈 뽑아주셨으니 감사합니다 절하면서 들어감

현재 근무 2주 차, 5월에 휴일많아서 기분이 좋은 상황

사수가 급하게 퇴사하게되어 빈 자리를 메꾸러 내가 뽑힘

사수는 이제 나감 ㅠㅠㅠㅠ 이머전시.. 이머전시...

열심히하자 고니야...

Redis 서버 구동 및 접속

Redis ( Remote Dictionary Server )

• 고성능 오픈소스 메모리 Key/Value NoSQL 데이터베이스
• 주요 사용 사례 : 캐싱, 세션 저장, Pub/Sub, 랭킹서버 등, 그리고 Channels의 ChannelLayer 백엔드
• 다양한 자료구조를 지원
  • Strings, Bitmaps, Hashes, Lists, Sets, Sorted Sets, Geospatial Indexes 등

레디스는 고성능 오픈소스 메모리 Key/Value NoSQL 데이터베이스

Redis 서버 구동 방법

• 외부 서비스를 활용
  • Redis Enterprise Cloud의 Free Plan (무료/유료)
  • 다양한 클라우드 벤더의 Redis as a Service 활용 (무료/유료)
• 로컬에 직접 설치
  • 도커 활용 (추천)
  • OS용 배포판 설치 (윈도우는 미지원이기에 WSL 활용)

개발용으로는 로컬에 직접 설치/구동하는 것이 속도면이나 비용면에서 유리

Redis Enterprise Cloud의 관리형 Redis 서비스는 신용카드 등록없이도 Free Plan을 이용할 수 있기에 로컬 설치가 어려운사람은 개발용으로 사용해도 됨!

Redis Enterprise Cloud 의 Free Plan으로 가입하겠음

한국이 없음..! 그러면 일본해야지... 30MB는 무료니까 이걸로 합시다

Public endpoint와 secret password 에 있는 호스트, 포트, 패스워드 는 임시로 복사해두고

이제 이걸 이용해서 프로젝트 폴더 바로아래에 .env 파일을 만들어주고

CHANNEL_LAYER_REDIS_URL=redis://:[패스워드]@[호스트]:[포트]

를 작성

대괄호는 빼고 @, : 는 살리면 됨

그리고 settings 로 이동해서

BASE_DIR = Path(__file__).resolve().parent.parent


env = Env()
env_path = BASE_DIR / ".env"
if env_path.exists():
    with env_path.open(encoding="utf8") as f:
        env.read_env(f, overwrite=True)

BASE_DIR 정의 아래에서 env_path를 계산하고, .env내역을 환경변수로서 로딩

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

# django channels layer
if "CHANNEL_LAYER_REDIS_URL" in env:
    channel_layer_redis = env.db_url("CHANNEL_LAYER_REDIS_URL")
    CHANNEL_LAYERS = {
        "default": {
            "BACKEND": "channels_redis.core.RedisChannelLayer",
            "CONFIG": {
                "hosts": [
                    {
                        "host": channel_layer_redis["HOST"],
                        "port": channel_layer_redis.get["PORT"] or 6379,
                        "password": channel_layer_redis["PASSWORD"],
                    }
                ]
            }
        }
    }

DATABASES 설정 아래에 CHANNEL_LAYERS 설정을 추가 CHANNELS_LAYER_REDIS_URL 환경변수가 로딩된 상황에서만 이를 파싱하여 CHANNEL_LAYERS 설정

python manage.py shell 을 구동하여

from django.conf import settings

settings.CHANNEL_LAYERS

를 통해 로딩이 되어있는지 확인!

마저 가봅쉬다 쉬다

Channels를 구성하는 패키지

• channels : (필수) 장고 통합 레이어

• daphne : (필수) ASGI 서버

  • 채널스 4.0부터 장고/채널스 개발서버로서 사용됩니다.
    • 실서비스에서는 daphne 명령이나 gunicorn/uvicorn 명령을 사용하여, 장고 서버를 구동합니다

• channels_redis : (옵션) Redis 채널 레이어

  • Channels 구동에 필수는 아니지만, 채팅 서비스에서는 프로세스간 통신이 필요하기에 필수

scope - 현재 요청의 세부 내역이 담긴 dict(사전)

scope은 dict 타입. channels middleware에 의해 새로운 key/value가 설정

• Django 기본에서는 HTTP 요청을 처리하는 주체는 View였으며, 함수와 클래스 형태로 구현

• Channels에서는 HTTP와 웹소켓 요청을 처리하는 주체가 Consumer 클래스

  • 함수 구현은 지원되지 않으며, 클래스로만 구현할 수 있음

View에서는 HttpRequest 객체를 통해서 유저/세션/쿠키/헤더 등의 현재 요청의 모든 내역을 조회할 수 있음

Consumer Instance에서는 self.scope 사전을 통해 현재 요청의 모든 내역을 조회할 수 있음

Channels 주요 구성요소

Consumer 클래스는 channels에서 요청을 처리하는 주체로서 일관된 처리방법을 제시 웹소켓/HTTP 프로토콜을 처리하는 기능 채널레이어를 통해 메세지를 보내고 받는 부분까지 모두 지원

반복을 줄이고, 최소한의 코드로 비즈니스 로직에 집중할 수 있음

View 함수/클래스도 요청 URL에 따라 그 요청을 처리할 View 함수를 결정할 수 있듯이 채널스에서는 3가지 기준으로 현재 요청을 처리할 Consumer Instance를 결정할 수 있습니다.

기준

1. HTTP 프로토콜 요청과 WebSocket 프로토콜 요청을 구별

   • 이때 ProtocolTypeRouter를 활용

2. 요청URL 문자열로 분기 URLRouter를 활용

   • 구현하는 대다수의 Consumer 클래스는 개별URL을 가지고, URLRouter에 등록

3. 채널명에 의한 라우팅

   • channels worker에서 사용하지만 여기선 사용X
   • 채널스에서도 쿠키/세션/인증 기능 활용가능
   • 장고 웹페이지에서의 쿠키/세션을 그대로 Consumer Instance에서도 활용할 수 있는 것

채널스는 ASGI application을 층층이 쌓는 방식으로 구현 - 래핑(Wrapping) 방식으로 동작

싹 다 ASGI application 이라 함!!!

악!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

사실 JWT가 그냥 좋다~ 하니까 그런갑다~ 했는데 나중에 면접에서

** "JWT말고 다른거 쓸 생각은 안해봤어요?" **

라고 물어보면

" 어.. 음... 오 아 예....

라고 대답할거 같아서 슥 봐보기로함

JWT(JSON WEB TOKEN) 란?

JSON 웹 토큰은 두 당사자 간의 청구를 안전하게 표현하기 위한 개방형 업계 표준 RFC 7519 방법이라고 하는데, 음... 안전하다는데 그냥 쓰면 안되나 무튼...

강의에서는 보안상의 헛점이 있어서 위험하다고 함

배경지식 : 회원기능 구현하는법

어떤 사이트(ex 드라마시청사이트) 에서 로그인한 사람만 해당 드라마를 보여주고 싶은거임 그럼 회원기능에는 2가지 방식을 사용하는데 동작방식은 둘다 비슷

입장권에 쓰여있는 정보만 다름

1. session 서버한테 입장권 제시 -> 입장권 확인 (문제없음) -> 입장 ㄱㄱ

세션에는 간단한 정보만 들어가있음 세션스코어?

2. token 얘는 입장권에 써있는 정보가 많음 유효기간만 확인하고 안지났으면 입장

그럼 왜 JWT방식을 사용하냐?

장점 : stateless 함 ( 회원이 많아질수록 부담이 적어짐 )

무슨 말이냐면 세션방식은 입장권을 하나하나 다까보면서 확인하는데
JWT는 그냥 입장권을 안까고 지나간다고 해석했음

이것은 마치 롯데월드 자유이용권이나
클럽에 가본적은 없지만 클럽팔찌, 클럽도장을 슥 보여주면 바로 통과하는게 JWT방식

입장할 때마다 지갑에서 신분증(주민등록증, 운전면허증, 여권 등등)을
꺼내서 직원이 확인하는게 세션방식

그러면 이제 JWT방식은 아주 빠른처리와 줄도 안밀리겠지만
세션방식은 일본처럼 아주 정석아날로그 거북이처럼 느리고 줄도 엄청 밀릴거임!

........이렇게 이해하는게 맞겠지?

그래서 JWT를 쓴다고 함

와 이해미쳤따 스스로 감탄중

하지만 여기서 대충쓰면 보안이슈 4개정도 생긴다함

https://jwt.io/

사이트에 들어가보게되면 JWT입장권을 받을 수 있는데

문제1 : "alg" 부분을 none 공격

간혹 입장되는 서버들이 있다고 함 하지맍, 최신라이브러리 잘 쓰면 걱정할필요까진 없다고 함

문제2 : JWT는 변환이 쉬움

민감한 내용을 넣으면 안됨 예를들면 나의 몸무게(?) 같은 거말고 주민등록번호 그런거? why? 디코딩하기 굉장히 쉽기때문

문제3 : 시크릿키 문제

대충적는사람이 너무 많음 유튜브강의들 그대로 베끼면 인생 쫑난다고함 으어어억..... 해결 방법은

1. 키를 매우 어렵고길게
2. 공유금지
3. 생성용키/검증용키 2개 사용

문제4 : jwt 탈취

이건 깊게 생각할 필요없이 헬스입장권 생각하면 됨 이건 본인잘못임!

해결

1. 훔치기 어렵게(HttpOnly cookie)
2. jwt 블랙리스트 (특정입장권 입장금지) 하지만 이렇게짜면 세션이랑 다를게 없음
3. jwt 유효기간 짧게 (5분) - 이거쓰려면 refresh token (유효기간 1년 ) 사용하면됨 근데 Refresh token도 탈취당할 수 있으니 Refresh token rotation 이 필요하다함

아니 이건 뭐 계왕권 2배에서 4배 8배 가는거 같냐... 무튼 refresh token은 언제나 1회용으로 사용해야 안전하다함!

결론

사용자가 엄청많지않다면 옛날 session 방식쓰자

그래도 JWT쓴다면 그냥 다른업체 인증서 같이 잘 쓰도록하자

일단 Django서비스 회원기능구현은 어떻게할지 고민좀 해봐야할듯 크흠흠...

출저 : 코딩애플 (유튜브)

일단 파이참으로 프로젝트 폴더 생성 후, python -m venv venv 로 가상환경 먼저 넣어주고 그리고 python -m pip install "django~=4.1.0" 통해서 django 4.1.0 버전 설치 startapp 생성 mysite로 생성해줬음

설마 Django 제일 기본적인 프로젝트 시작할줄 모르는 사람은 없겠지...

이건 마치 음.. 음... 무튼 젤 처음 쉬운거임

그래도 순서를 대략 적어보자면

작업폴더로 가서

python -m pip install "django~=4.1.0" 장고 4.1.0 버전 설치

python -m django startproject mysite . 장고 프로젝트 생성

python manage.py migrate 장고 기본 앱 상의 마이그레이션, DB스키마 생성

python manage.py runserver 장고 개발서버 구동

이렇게 하면

요렇게 서버가 실행됨

그 다음으로는

python -m pip install "channels[daphne]~=4.0.0" - channels daphne 라이브러리 설치

mysite/settings.py 에다가
"channels",
"daphne",
추가 가장 위쪽에 넣어주자 ( 왜 why? 다른 앱에비해 우선순위를 갖기 위함)

ASGI_APPLICATION = "mysite.asgi.application"

까지 작성해주고

mysite/asgi.py 에 가서

import os
from channels.routing import ProtocolTypeRouter
from django.core.asgi import get_asgi_application

os.environ.setdefault('DJANGO_SETTING_MODULE', 'mysite.setting')

django_asgi_app = get_asgi_application()

application = ProtocolTypeRouter({
    "http": django_asgi_app,
})

이렇게 하고 runserver를 작동하면!! 오류가 뜸

뭐... 너 ASGI_APPLICATION 설정안했다. 서버돌리는데 필요하다 라는 말인거 같음

... 아니 강의에 이런내용이 없는데 쮸밤.....

그래서 바로 google의 고수님들을 찾아나섰음

어떤 사람이 같은오류가 났는데 Redis 사용하려하는데 같은 오류가 났지만, 같은 오류니까 해결법도 같겠거니 하고 답변을 살펴봤음

WebSocket 서버에 대해 라우팅 구성을 작성해야한다고 함! 신기하게 여기도 폴더이름이 똑같음 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 개웃김 그래서 답변대로 routing.py 생성하고 settings.py 파일 수정하니까!

뭐야.. 왜 되는데.. 나도 몰라...ㅠㅠ 뭐 일단 라우팅 구성 하니 해결됐다!로...? 자세히 보면 ASGI/Daphne 버전으로 구동이되었다고 나옴! 참고할 내용은

- (중요) 이는 개발서버일 뿐, 실제 운영에서는 daphne 나 gunicorn 등을 통해 장고 애플리케이션 구동

- 여기에서 사용되는 runserver 명령은 장고 기본의 runserver 명령이 아님

- daphne 장고앱에서 오버라이딩한 runserver 명령

이부분을 짚고 넘어가야함

이렇게 까지하면 기본적인 channels 세팅 완료!! 와 사실 진짜 두드린건 5분~10분내지인데, 2시간 한거같음 호로로롤로롤 .... 무튼 마저 가보겠음 심심하니까 파이썬 버전한번 체크해보자

python --version 음.. 버전체크완료

프로젝트 폴더아래 mysite/requirements.txt 파일을 만들고

# coding: utf-8

# 장고 프레임워크
django~=4.1.0

# 채널스 기본 라이브러리 + daphne
channels[daphne]~=4.0.0

# 채널스, 채널 레이어 Redis 백엔드 라이브러리
channels_redis~=4.0.0

# 레디스 라이브러리 (4.4.0은 2022년 12월 기준 최신이지만, 종종 Redis ZREMRANGEBYSCORE 명령에 대한 응답이 None으로 처리되어 TypeError가 발생하는 버그가 있어서 skip)
redis!=4.4.0

# 환경변수의 손쉬운 settings 적용
django-environ

# 장고 내에서 손쉬운 bootstrap5 사용

# 가벼운 HTTP 클라이언트 라이브러리
requests

# HTML 파싱 라이브러리
beautifulsoup4

# 테스트
pytest
pytest-django
pytest-testdox
pytest-asyncio

필요한 라이브러리를 작성하고 한번에 다운로드하겠음 후에 다른 프로젝트를 할때에도 이렇게 requirements.txt 파일을 만들어서 한번에 모아두면 댕꿀임!

pip install -r requirements 명령을 통해서 한번에 설치 고우!

일단은 여기까지!!!!!!!!!!!!! 안뇽!

SQLD는 이번에 범위가 달라지고 재시험이었는데, 주관식이 사라지고 다 4지선다형으로 바뀌었음!

긴 SQL문 JOIN 와구와구 들어가있는거 해석 잘하면 쉽게 붙을 수 있을듯

물론 그게 내가 아니라는게 함정.

리눅스마스터 2급은 최근 2~3개년 정도만 풀고들어갔는데, 비스무리한 문제 많이 나온거같음

아리까리한게 있어서 이것도 좀 결과나와봐야 알거같음

사람들은 가답안같은거 많이보던데, 그냥 진득히 기다려보겠음.

그럼 이제 포폴을 마저 진행해보려고 파이참을 딱 켰는데!!!

아니 이게 뭐람

터미널창이 안켜짐 돌았나봄!

나 뭐 건드린거 없는데 슈밤......

구글 선생님께 검색을 해보니 Ctrl + Alt + S 를 눌러 Settings 를 키고

Tools -> Terminal 을 간다

여기서 Shell Path 부분을 화살표 내려서 다른 Shell Path 로 변경해주면됨

요렇게 요렇게

해결했으니... 잠깐 누우러가봄

Django야 미안해 자격증시험 하고 다시찾을게 가주악ㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱ

채팅 서비스의 핵심은 뭐다? 실시간 메세징이다

서버에서 웹 클라이언트로 메세지를 전달하려는 방법은 크게 4가지 (HTTP 1.1 기준) 웹 프로토콜인 HTTP는 항상 클라이언트로부터의 요청에 서버가 응답하는 구조

• HTTP Polling (실시간 X)
• HTTP Long Polling
• HTTP Streaming
• Web Socket (실시간 O)

Django Channels 에서 기본적으로 제공하고 실시간 메세징이 가능한 Web Socket을 이용할거임

그럼 이 Web Socket이 어디에 쓰였냐 아 아 아 아 아 아

배민쇼핑라이브 채팅 : 웹소켓 + Redis PubSub 에 사용됐다 이 말 말 말!

그러니 나도 한 번 배민쇼핑라이브 기술 써보자아가주악악!!!!!!!

Redis Pub/Sub 서버 단에서 채팅방의 다른 유저에게 메세지를 뿌리는 역할 유저로의 전달은 웹소켓이 담당

• 레디스 특정 채널에 구독신청을 하면 구독자(Subscriber)가 됨. 레디스 특정 채널에 메세지를 발행(Publish)하면, 구독 중인 구독자에게 메세지가 전달됩니다. ex) 유튜브 구독

• 레디스의 Pub/Sub는 메세지를 "전달하는" 시스템이기에 메세지를 보관안함!! 안함 안함!! 지난 채팅 메세지 조회가 필요하다면, 메세지를 DB에 넣어두고 필요할 때 조회

• 서버 대수를 늘려 Horizontal로 손쉬운 Scale out을 지원

1. 유저가 웹소켓을 통해 메세지를 송신하면
2. Consumer Instance에서 Pulish하여 Redis Pub/Sub 보내고
3. 다시 Consumer Instance 를 거쳐서
4. 다른유저에게 웹소켓을 통해 실시간으로 메세지를 수신

ASGI (비동기 서버 게이트웨이 인터페이스)

• 파이썬 웹 프레임워크의 새로운 프로토콜

• ASGI는 파이썬 비동기 웹의 표준이기에 모든 비동기 파이썬 웹프러임워크의 기반

• 장고 Channels는 웹을 넘어, 모든 통신 프로토콜을 지원할 수 있습니다

• Channels 기본에서 HTTP와 WebSocket을 지원합니다.

• 장고는 wsgi / asgi 모두를 기본에서 잘 지원하며, 원하는 방식으로 구동 가능

• 장고의 일반적인 뷰 처리는 (django, djangorestframework 등) WSGI 방식이 성능이 더 잘나올 수도 있다고 함!

이번 채팅에 사용 할 Channels 는

• ASGI 기반의 라이브러리로서, HTTP/웹소켓 프로토콜을 손쉽게 처리할 수 있도록 기능 지원
• 장고 네이티브한 방법으로 웹소켓 지원
• 2022년 10월에 버전 4.0.0 릴리즈
• 장고 버전에 맞춰 릴리즈되었을 뿐, 버전 3.x와 기능은 거의 유사
• 파이썬 3.7 이상, 장고 2.2 이상을 지원 (가급적 최신버전 추천)

사용할 라이브러리

# 장고 프레임워크
django~=4.1.0

# 채널스 기본 라이브러리 + daphne
channels[daphne]~=4.0.0

# 채널스, 채널 레이어 Redis 백엔드 라이브러리
channels_redis~=4.0.0

# 환경변수의 손쉬운 settings 적용
django-environ

# 장고 내에서 손쉬운 bootstrap5 사용
django-bootstrap5

# 가벼운 HTTP 클라이언트 라이브러리
requests

# HTML 파싱 라이브러리
beautifulsoup4

# 테스트
pytest
pytest-django
pytest-testdox
pytest-asyncio

자 그럼 다음 시간부터 가보자 gogogogogogogogogogo곡!

이를 파악하기 위해 enum의 특징에 대해 알아보자

//static final 상수 선언
class Days {
    static final int MONDAY = 1;
    static final int TUESDAY = 2;
...
}

//enum 사용
enum Days {
    MONDAY(1),
    TUESDAY(2),
    ...

    private final int index;
    ...
}

사실 static final이 상수를 관리하는 건 처음 알았음 크흠... enum은 파이썬에서 봤던 기억이 있는데, 순서를 지정해주는 걸로 봤는데 상수의 집합이라 흠..

좀 찾아보겠음

enum이란? 비단 자바에만 있는 개념은 아니고 다른 언어에서도 볼 수 있는 형식이다. 열거형이라 불리며 요소, 멤버라 명명된 값의 집합을 이루는 자료형으로 열거자 이름들은 해당언어의 상수 역할을 하는 식별자이다. (출처 : 위키백과)

. . .

음 일단 파이썬에서도 봤었는데, 기능적으로는 큰 차이는 없는거 같음!

그럼 static final 과 enum의 차이점은 뭐임 흠..? 나와라 지피티!

먼저, static final 변수와 enum 모두 상수를 표현하는 방법이지만, 그들 사이에는 중요한 차이점들이 존재합니다.

1. 타입 안전(Type Safety): enum은 type-safe입니다. 즉, 컴파일 타임에 오류를 잡아낼 수 있습니다. 반면, static final 상수는 이런 보장을 할 수 없습니다. 예를 들어, 요일을 표현하는 데 1~7 이외의 숫자를 사용하면, static final 상수를 사용할 때는 컴파일러가 이를 잡아내지 못합니다. 하지만 enum을 사용하면 컴파일 타임에 이런 오류를 잡아낼 수 있습니다.

2. 메서드와 필드: enum은 메서드와 필드를 가질 수 있습니다. 이는 enum이 클래스와 같은 방식으로 동작하기 때문입니다. 반면, static final 상수는 이런 기능을 제공하지 않습니다.

3. enum 상수는 싱글턴입니다. 이는 각 enum 상수가 해당 enum 타입의 정확히 하나의 인스턴스임을 의미합니다. 이것은 enum 상수가 전역적으로 접근 가능한 상태를 안전하게 공유할 수 있음을 의미합니다.

4. switch 문에서: enum은 switch 문에서 사용할 수 있습니다. 이는 각각의 enum 상수가 유일하게 구분되기 때문입니다. 하지만 static final 상수는 여러 변수가 같은 값을 가질 수 있어서 이런 보장을 할 수 없습니다.

5. 자체적인 네임스페이스: enum은 자체적인 네임스페이스를 가집니다. 즉, 같은 이름의 상수를 갖는 서로 다른 두 enum이 있어도, 그들은 서로 다른 타입으로 취급됩니다. 이는 상수 간의 이름 충돌을 방지합니다.

따라서, static final 상수와 enum 사이에서 선택할 때는, 이러한 차이점들을 고려해야 합니다. 어떤 경우에는 static final 상수가 적합할 수 있지만, 보다 풍부한 기능성과 타입 안전성 등을 원한다면 enum을 사용하는 것이 좋습니다. 이러한 선택은 항상 문제의 맥락과 요구 사항에 따라 달라집니다.

음... 설명만 봐서는 그냥 enum이 짱인거 같음 글로만 봐서는 이해하기 어려워서 간단한 예시를 가지고 왔음 요일에 대해서 볼건데

// static final 사용
public class Week {
    public static final int MONDAY = 1;
    public static final int TUESDAY = 2;
    // ...
}

이 경우, 우리는 요일을 숫자로 표현 함. 그런데 문제는, 이렇게 하면 우리가 실수로 요일에 8이라는 값을 넣는다던가, 또는 0이라는 값을 넣는다던가 하는 실수를 해도, 컴퓨터는 이를 막을 방법이 없음

하지만!! enum을 사용하면 이런 문제를 해결할 수 있음!

// enum 사용
public enum Week {
    MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY
}

이렇게 enum을 사용하면, "요일"이라는 것을 숫자가 아니라 '월요일', '화요일', '수요일' 등으로 표현할 수 있음. 그리고 이렇게 해놓으면, 우리가 실수로 '팔요일'이라는 것을 넣으려고 하면, 컴퓨터가 이를 막아줌. 왜 why?, 컴퓨터는 '월요일'부터 '일요일'까지밖에 모르기 때문

또한, enum에는 메서드를 추가할 수 있음. 폴 이그잼폴, 각 요일이 주말인지 아닌지를 확인하는 메서드를 추가가능

public enum Week {
    MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY;

    public boolean isWeekend() {
        return (this == SATURDAY || this == SUNDAY);
    }
}

이렇게 하면, 우리는 '오늘은 주말인가요?'라는 질문에 대답할 수 있음

요약!! enum을 사용하면

• 우리는 코드를 더 안전하게 만들 수 있고
• 더욱 명확하게 표현할 수 있으며
• 메서드를 추가함으로써 더 많은 기능을 제공할 수 있음.

이러한 이유로, enum은 static final 상수보다 훨씬 강력하고 유연한 도구다!

그래도 혹시나 해서 static final 을 사용하는 경우는 뭐냐 확인해봤음 지피티 대답

enum 대신 static final 변수를 사용하는 경우, 몇 가지 장점이 있을 수 있습니다:

1. 단순성: static final 변수는 간단하고 기본적인 자료형을 사용하므로, 코드를 단순하게 유지하는 데 도움이 될 수 있습니다. 이는 특히 복잡한 로직이나 추가적인 메서드 없이 단순한 상수 값을 사용해야 하는 경우에 유용합니다.

2. 메모리 사용량: enum은 내부적으로 클래스로 처리되므로, static final 변수에 비해 더 많은 메모리를 사용할 수 있습니다. 따라서, 메모리 사용량이 중요한 경우에는 static final 변수를 사용하는 것이 더 효율적일 수 있습니다. 하지만, 이는 대부분의 경우에서는 큰 차이를 만들지 않습니다.

3. 호환성: static final 변수는 모든 Java 버전에서 사용할 수 있습니다. 반면, enum은 Java 5 이상에서만 사용할 수 있습니다. 따라서, 레거시 시스템과의 호환성이 중요한 경우에는 static final 변수를 사용하는 것이 더 적합할 수 있습니다.

하지만 이러한 장점들은 대부분의 경우에서는 enum의 장점에 비해 상대적으로 작습니다. 따라서, 가능한 경우에는 enum을 사용하는 것이 더 좋습니다. 그러나 이러한 장점들을 고려하여 개발 상황에 따라 적절한 선택을 하는 것이 중요합니다.

오늘의 결론

static final 보단 enum을 쓰도록 하자 땅땅땅!

• getter와 setter 를 쓰지 말라는 글은 심심찮게 볼 수 있다. 왜 이 둘을 쓰지 말라는 걸까? 그럼 어떻게 클래스의 상태(멤버 변수)를 변경할 수 있을까?

위가 질문인데 get 과 set의 단어들과 관련이 있을거 같음!

자바와 같은 객체 지향 프로그래밍 언어에서, 객체의 상태는 그 객체의 필드(또는 멤버 변수)로 표현 된다는데, 이 필드는 객체의 내부 상태를 나타내며, 대부분 private 접근 제어자를 사용하여 외부에서 직접 접근할 수 없도록 한다고 함. 이는 객체의 상태를 보호하고, 잘못된 상태 변경을 방지하는데 중요한 역할!

근데 이 필드의 값을 외부에서 읽거나 변경해야 할 필요가 있을 수 있음. 이럴 때 사용하는 것이 getter와 setter 메서드다 땅땅!

오호 그렇구만..! 더 봐보겠음

Getter는 필드의 값을 반환하는 메서드로, 필드의 값을 읽을 수 있게 해줌. 이 메서드는 보통 'get'이라는 단어로 시작하고, 필드의 이름을 따라서 이름이 지어진다. 예를 들어, 필드의 이름이 'name'이라면, 그에 대한 getter 메서드의 이름은 'getName'이 될 것입니다.

오 어쩐지 뭔가 Java 맨날 같은거 붙어있는거 같던데 이게 그건가 봄!

Setter는 필드의 값을 변경하는 메서드로, 필드의 값을 설정할 수 있게 해줌. 이 메서드는 보통 'set'이라는 단어로 시작하고, 필드의 이름을 따라서 이름이 지어진다. 예를 들어, 필드의 이름이 'name'이라면, 그에 대한 setter 메서드의 이름은 'setName'이 될 것입니다.

오... 얘네가 이런애들 이었구나 지식 + 1

그러나 getter와 setter를 과도하게 사용하는 것은 객체 지향 설계 원칙에 위배될 수 있음!!! 객체는 자신의 상태를 스스로 관리해야 하며, 그 상태를 외부에서 자유롭게 접근하거나 변경하는 것을 허용하면 객체의 캡슐화 원칙이 깨질 수 있음!

따라서, getter와 setter는 필요한 경우에만 제한적으로 사용해야 하며, 가능한 한 객체의 메서드를 통해 객체의 상태를 변경하고 조회하는 것이 바람직함! 이렇게 하면 객체의 상태를 보호하고, 객체의 책임을 유지할 수 있습니다.

포인트가 이거구나

상태를 외부에서 자유롭게 접근하거나 변경하는 것을 허용하면 객체의 캡슐화 원칙이 깨질 수 있음!

필요한 경우에만 제한적으로 사용해야 하며, 가능한 한 객체의 메서드를 통해 객체의 상태를 변경하고 조회하는 것이 바람직함!

좀 더 검색해보니 캡슐화 뿐만아니라 몇가지 이유가 더 있었음!

1. 캡슐화 위반: 객체의 상태는 해당 객체만이 관리해야 합니다. getter와 setter를 통해 외부에서 객체의 상태를 자유롭게 변경하거나 조회하게 하면 객체의 내부 구현이 외부에 노출되고, 이는 캡슐화 원칙에 위배될 수 있음

2. 객체의 책임 무시: 객체 지향 프로그래밍에서 각 객체는 자신만의 책임을 가지고 있습니다. 그러나 getter와 setter를 사용하면 객체의 상태를 외부에서 변경하거나 조회하게 되므로 객체의 책임이 무시될 수 있음

3. 데이터 중심 설계: getter와 setter를 과도하게 사용하면 데이터 중심의 설계로 이어질 수 있습니다. 이는 객체가 데이터의 저장소로 여겨지고, 비즈니스 로직이 외부에 분산될 수 있음

해결방법 - 객체의 상태를 변경하거나 조회할 때는 해당 객체의 메서드를 통해 이를 수행 메서드들은 객체의 상태를 적절히 관리하며, 객체의 책임과 캡슐화 원칙을 유지 이렇게 하면 객체의 내부 구현이 외부에 노출되지 않고, 객체 지향 설계 원칙을 더 잘 준수할 수 있다고 함!

구글링을 해본 결과

컬렉션 프레임워크(collection framework)란?

자바에서 컬렉션 프레임워크(collection framework)란 다수의 데이터를 쉽고 효과적으로 처리할 수 있는 표준화된 방법을 제공하는 클래스의 집합을 의미한다고 함!

즉! 데이터를 저장하는 자료 구조와 데이터를 처리하는 알고리즘을 구조화하여 클래스로 구현해 놓은 것!

이렇게 구현해 놓은 컬렉션 프레임워크는 자바의 인터페이스(interface)를 사용하여 구현된다고 한다!

여기서 의문을 가져야 할 부분이 있다고 함!

// 배열
int[] scores = new int[30];

//List
ArrayList<Integer> scores = new Arraylist<>();

데이터를 담고 처리하는 방법에는 배열(Array)이 있는데 왜 Collection을 사용하냐!!

배열(Array)와 차이점은 정적메모리할당이 아닌 동적메모리할당을 하게 됨! 배열은 new int[4]를 하면 4개 공간밖에 못쓰고 미리 선언을 통해 4개의 공간을 만들어야 하지만(정적 메모리), collection은 공간이 계속 필요한 만큼 추가할 수 있다(동적 메모리).

결론적 으로는

배열은 정적메모리고 정해둔 공간밖에 못씀! 크기가 정해져있다! 컬렉션은 동적메모리고 필요할 때 추가할 수 있다!

뭐... 가변성이 있다라고 해석해도 될지..!?

Array와 AraayList의 차이를 좀 찾아봤음

예제코드들을 봐보겠음

import java.util.ArrayList
import java.util.List;

public class Main {
    public static void main(String[] args) {
        String[] array = new String[10];
        List<String> list = new ArrayList<>();

        System.out.println("저장 전 length : "+array.length);
        System.out.println("저장 전 size : "+list.size());

        array[0] = "홍길동";
        array[1] = "이순신";
        array[2] = "강감찬";

        list.add("홍길동");
        list.add("이순신");
        list.add("강감찬");

        System.out.println("저장 후 length : "+array.length);
        System.out.println("저장 후 size : "+list.size());
    }
}

결과

1. Array 저장 전 length : 10

2. List 저장 전 size : 0

3. Array 저장 후 length : 10

4. List 저장 후 size : 3

5. 배열의 length를 10으로 선언했기 때문에 10출력

6. ArrayList에 값이 저장되지 않았기 때문에 size 0출력

7. 값이 3개만 저장되어도 length는 10으로 고정되기 때문에 10 출력

8. 값이 3개가 저장되었기 때문에 size 3 출력

아 이거 Array가 그냥 배열이고 List가 ArrayList 인건가 괜히 헷갈리네 결과를 보니까 결국 1, 3 번의 Array는 배열의 크기를 바로 선언하는거니까 고정적으로 값이 변하지 않는거고

2, 4 번의 ArrayList는 배열의 크기가 유동적으로 변할 수 있어서 처음에 따로 크기 선언없이 추가된 부분이 생성되어 size가 3으로 나오는 듯!?

오케이 이해해부러쓰!

참고블로그 https://www.icia.co.kr/community/board/view/2/1/117 https://choicode.tistory.com/25

인생 처음 서류 넣고 면접 오라고 해서 면접 갔다 왔음

생각보다 회사 규모가 있어서 도착해서 놀람

대기실에서 먼저 대기했는데, 프론트, 안드로이드, 백엔드 골고루 있었음!

면접 시간은 사람마다 10분 ~ 15분 정도로 짧게 진행하는 거 같음

인터넷으로 백엔드 면접 질문들 좀 보고 갔는데

뭐 리스트랑 튜플의 차이 요런 거나 스택과 큐의 차이 보다가

잡플래닛 면접 후기에 가벼운 분위기로 진행되고 일상적인 얘기 했다길래

그렇다고 하고 자기소개 정도만 준비하고 감

기억나는 질문

1. 백엔드에서 파이썬을 사용한다는 건 어떤 의미라고 생각하나요?

... 아니 ㅆ...ㅣ.. 이게 뭔소리야 파이썬이 프로그래밍 언어니까 백엔드에 사용하지... 뭐지 이 말장난은...

사실 이렇게 심도 있게 파이썬이라는 언어에 대해서 생각해 본 적이 없는 나 자신을 깨달았음.

그저 코드가 보기 편하고 직관적이어서 좋다!

이게 끝이었는데, 저런 질문을 말문이 턱 막히는 기분..

2. 전공과 다른데 백엔드를 선택한 이유

그냥 성격과 성향상 새로운 변화를 좋아하는데, 항상 변화하고 발전하는 IT분야가 매력적이었다 라는 식으로 얘기했음.

3. 전 직장 퇴사 사유

퇴사 사유 말함

4. 파이썬으로 할 줄 아는 게 뭐냐? .... 파이썬으로 할 줄아는거..? 조건문쓰기 반복문 쓰기...? 는 아니고 크롤링 해봤다고 하니까 크롤링할 때 어떤 모듈을 사용했는지 물어봤음, 대답 못 함

5. 파이썬도 잘 모르는 거 같은데 우리가 너를 뽑아야 하는 이유는? 지금 답변하는 거만 봐선 뽑아야 하는 이유는 없지만, 실무에서 빠르게 적응하고 배우는 유형이라고 답했음

6. Django 는 백엔드라고 생각하는지? Python의 웹 프레임워크인 Django 을 이용해 프론트도 만들고 백엔드의 기능구현들도 하기 때문에 백으로도 볼 수 있다고 답함 근데 프론트아니냐고 하는데, 옆에 다른 면접관이 백도 될 수 있다. 굳이 말하자면 서로 얘기함

7. 출근 시간 얼마나 걸림? 30분

순서는 좀 뒤죽박죽이긴 한데, 대략 이 정도의 질문들이었음

사실 파이썬으로 뭐 할 줄 아냐고 물었을 때, 아차! 싶긴 했음 그냥 두루뭉술하게 다 겉핥기로만 진행했었는데, 이런 질문을 할 줄이야...

개발이라는 직무에대한 고찰을 해본 적이 없다는 걸 스스로 느끼게 된 면접이었음

개발이 왜 하고 싶어? 묻는다면

" 막연히 멋있잖아! 어디서든 할 수 있잖아! "

이런 뇌에 우동 사리만 가득한 답변들로 가득 차 있었는데

진지하게 생각해야 할 필요가 있다는 걸 느꼈음.

이번 주 정도까지는 내가 왜 이 개발 백엔드 직군에서 일을 하고 싶은지에 대한 심도 있는 고찰을 스스로에게 물어보려고 함.

막연하게 살아온 나에게 있어서는 굉장히 좋은 면접이었던 거 같음

대답을 제대로 하지 못해 아쉬움도 남는 걸 보니 내가 병신같고 그럼

국비 과정이 끝나고 사람들하고 Java 스터디를 했는데, 파이썬으로 뭐 쥐뿔도 할 줄 모르는 새끼가 Java스터디는 뭐하러하는지........

아는 지인은 파이썬 하나로 대기업 취업해서 잘하는데, 건방지게 백수인 상태로 다른 언어들을 맛보려 했었다니...

어리석다 어리석어...

앞으로의 계획은 파이썬으로 할 수 있는 개인 토이프로젝트들을 진행하려고 함

그래서 파이썬으로 뭐 할 줄 아니라는 질문을 받았을 때,

• 파이썬을 이용한 웹 크롤링
• 파이썬을 이용한 데이터 시각화
• 파이썬을 이용한 데이터 분석

이 정도는 어떤 모듈을 사용하고 진행하는지 정도는 술술 대답할 정도까지 성장해 볼 예정

파이썬 부터 파겠음 Java는 너무 어리석었음.

GIT 브랜치 전략

브랜치 전략이란?

• 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용 하기 위한 work-flow

• 브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 한다.

• 즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말한다.

브랜치 전략이 없다면?

깃을 사용한지 얼마 안된 개발자가 겪는 상황

• 어떤 브랜치가 최신브랜치?
• 어떤 브랜치를 끌어와서 개발을 시작해야함?
• 어디에 Push보내야함..?
• 핫픽스 해야하는데 어떤 브랜치를 기준으로 수정?
• 배포 버전은 어떤 거 골랄야함?

널리 사용되는 2가지 브랜치 전략

git-flow, github-flow 전략

먼저 git-flow

• 기본적인 가치의 이름은 아래의 5가지로 구분하곤 한다.
• feature > develop > release > hotfix > master
• 위 순서들은 왼쪽으로 갈수록 포괄적인 가지이며 master branch를 병합할 경우 그 왼쪽에 있는 hotfix 등 모든 가지들에 있는 커밋들도 병합하도록 구성하게 된다.
• 5가지 중, 항시 유지되는 메인 브랜치 master, develop 2가지와 merge 되면 사라지는 보조 브랜치 feature, release, hotfix 3가지로 구성된다.

Git-flow 브랜치 구조

• master : 라이브 서버에 제품으로 출시되는 브랜치.
• develop : 다음 출시 버전을 대비하여 개발하는 브랜치.
• feature : 추가 기능 개발 브랜치. develop 브랜치에 들어간다.
• release : 다음 버전 출시를 준비하는 브랜치, develop 브랜치를 release 브랜치로 옮긴 후, QA, 테스트를 진행하고 master 브랜치로 합친다.
• hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치.

메인 브랜치

메인 브랜치는 master 브랜치와 develop 브랜치 두 종류를 말한다.

master 브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며, develop 브랜치는 다음에 배포할 것을 개발하는 브랜치이다. 즉 develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.

보조 브랜치

보조 브랜치는 피처 브랜치(feature branch) 또는 토픽 브랜치(topic branch)를 말한다.

• 가지가 뻗어나오는 곳 : develop
• 뻗어나갔던 가지가 다시 합쳐지는 곳 : develop
• 이름 설정 : master, develop, release-* , hotfix-* , 를 제외하기만 하면 자유롭게 이름 설정이 가능하다.
• 새로운 기능을 추가할 때 주로 사용하는 가지이다.

master 브랜치에서 develop 브랜치를 만들었고, develop 브랜치에서 다시 feature 브랜치를 나눠 작업을 하고 있는 것을 그림을 통해 알 수 있다.

develop 브랜치에는 기존에 잘 작동하는 개발코드가 담겨있으며, 보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 한다.

즉, 보조 브랜치는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge하고 결과가 좋지 못하면 버리는 방향을 취한다.

보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin에는 push하지 않는다.

릴리즈 브랜치(release branch)

릴리즈 브랜치는 배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말한다.

• 가지가 뻗어나오는 곳 : develop
• 뻗어나갔던 가지가 다시 합쳐지는 곳 : develop, master
• 이름 설정 : release-*
• 새로운 제품을 배포하고자 할 때 사용하는 가지이다.

develop 브랜치에 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성한다.

배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그(ex, v1.0, v0.2)를 추가한다.

release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop 브랜치에도 적용해줘야 한다.

그러므로 배포 완료 후 develop 브랜치에 대해서도 merge작업을 수행해야 한다.

핫픽스 브랜치(hotfix branch)

핫픽스 브랜치는 배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말한다.

• 가지가 뻗어나오는 곳 : master
• 뻗어나갔던 가지가 다시 합쳐지는 곳 : develop, master
• 이름 설정: hotfix-*
• 제품에서 버그가 발생했을 경우에는 처리를 위해 이 가지로 해당 정보들을 모아준다. 버그에 대한 수정이 완료된 후에는 develop, master에 곧장 반영해주며 tag를 통해 관련 정보를 기록해둔다.

버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속 할 수 있다.

이 때 만든 hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge하여 문제가 되는 부분을 처리해줘야 한다.

release 가지가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다.

Hotfix는 보통 다급하게 버그를 고치기 위해 생성되는 가지이기 때문에 버그를 해결하면 보통 제거하는 일회성 가지다.

Git flow 흐름

• 앞에서 적었던 기본 구조 5개 중 가장 많이 사용되는 가지는 master와 develop가 되며 정상적인 프로젝트를 진행하기 위해서는 둘 모두를 운용해야 한다.
• 나머지 feature, release, hotfix branch는 사용하지 않는다면 지우더라도 오류가 발생하지 않기 때문에 깔끔한 프로젝트 진행을 원한다면 지워뒀다가 해당 가지를 활용해야 할 상황이 왔을 때 만들어줘도 괜찮다.
• 대부분의 작업은 develop에서 취합한다 생각하면 되며 테스트를 통해 정말 확실하게 더 이상 변동사항이 없다 싶을 때 master로의 병합을 진행하게 된다.
• master가 아닌 가지들은 master의 변동사항을 꾸준히 주시해야 한다.

1. 신규기능 개발

• 개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 feature 브랜치를 생성한다.
• freature 브랜치에서 기능을 완성하면 develop 브랜치에 merge를 진행하게 된다.

2. 라이브 서버로 배포

• feature브랜치들이 모두 develop브랜치에 merge 되었다면 QA를 위해 release브랜치를 생성한다.
• release 브랜치를 통해 오류가 확인된다면 release 브랜치 내에서 수정을 진행한다.
• QA와 테스트를 모두 통과했다면, 배포를 위해 release 브랜치를 master 브랜치 쪽으로 merge하며,
• 만일 release 브랜치 내부에서 오류 수정이 진행되었을 경우 동기화를 위해 develop 브랜치 쪽에도 merge를 진행한다

3. 배포 후 관리

• 만일 배포된 라이브 서버(master)에서 버그가 발생된다면, hotfix 브랜치를 생성ㅇ하여 버그 픽스를 진행한다.
• 그리고 종료된 버그 픽스를 master와 develop 양 쪽에 merge하여 동기화 시킨다.

GITHUB-FLOW 전략

• Git fow가 좋은 방식이지만 GitHub에 적용하기에는 복잡하다는 Scott Chacon의 판단에 따라 만들어진 새로운 깃 관리 방식이다.
• 자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 된다.
• Git flow에 비해 흐름이 단순해짐에 따라 그 규칙도 단순해졌다.
• 기본적으로 master branch에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request기능을 사용하도록 권장한다.

GitHub-Flow 특징

• release branch가 명확하게 구분되지 않은 시스템서의 사용이 유용하다.
• GitHub 자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용하다.
• 웹 서비스들에 배포의 개념이 없어지고 있는 추세이기 때문에 앞으로도 Git flow에 비해 사용하기에 더 수월할 것이다.
• hotfix와 가장 작은 기능을 구분하지 않는다. 모든 구분사항들도 결국 개발자가 전부 수정하는 일들 중 하나이기 때문이다. 이 대신 구분하는 것은 우선ㅅ눈위가 어떤 것이 더 높은지에 대한 것이다.

Github-Flow 흐름

1. 브랜치 생성

Github-flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작된다.

단, 이때 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요하다.

• master브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치다. 이 브랜치에 대해서는 엄격한 role과 함께 사용한다.
• 새로운 브랜치는 항상 master 브랜치에서 만든다
• Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않는다.
• 그렇지만, 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자

2. 개발 & 커밋 & 푸쉬

개발을 진행하면서 커밋을 남긴다. 이때도 브랜치와 같이 커밋 메세지에 의존해야 하기 때문에, 커밋 메세지를 최대한 상세하게 적어주는 것이 중요하다.

• 커밋메시지를 명확하게 작성하자
• 원격지 브랜치로 수시로 push 하자
• Git-flow와 상반되는 방식
• 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
• 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다.

3. PR(Pull Request) 생성

피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다

• pull request는 코드 리뷰를 도와주는 시스템
• 이것을 이용해 자신의 코드를 공유하고, 리뷰받는다.
• merge 준비가 완료되었다면 master 브랜치로 반영을 요구한다.

4. 리뷰 & 토의

Pull-Request가 master 브랜치 쪽에 합쳐진다면 곧장 라이브 서버에 배포되는 것과 다름 없으므로, 상세하 리뷰와 토의가 이루어져야 한다.

5. 테스트

리뷰와 토의가 끝났다면 해당 내용을 라이브 서버(혹은 테스트 환경)에 배포해본다. 배포시 문제가 발생한다면 곧장 master브랜치의 내용을 다시 배포하여 초기화 시킨다.

6. 최종 Merge

라이브서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않았다면 그대로 master브랜치에 푸시를 하고, 즉시 배포를 진행한다.

대부분의 Github-flow 에선 master브랜치를 최신 브랜치라고 가정하기 때문에 배포 자동화 도구를 이용해서 Merge 즉시 배포를 시킨다.

master로 merge되고 push 되었을 때는, 즉시 배포되어야한다

• GitHub-flow의 핵심
• master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다. (CI / CD)

GITHUB FLOW vs GIT FLOW

• 1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 git-flow가 적합하다
• 수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면 github-flow와 같은 간단한 work-flow가 적합하다.

출처 : https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5

그냥 복습한다는 느낌으로 적으면서 상기시켰음! 똑같이 적었으니 더 많은 정보는 출처링크 참고!