백엔드 문제점과 이슈 질문에 대해-1

팀 크레이자알파카에서 올린 채용공고 속엔  아래와 같은 질문을 이력서에 포함하게 되어있었다.

1. A, B 두 사람이 각각의 Feature를 개발해서 develop branch에 병합을 한 상황입니다. 그런데 A가 작업한 Feature만 배포를 하기로 했습니다. 이 때 올바른 Git 사용방식은 무엇인가요?

 

2. RDB 또는 NoSQL을 사용하던 도중 불편함을 느꼈던 경험과 개선 방안에 대해 알려주세요.

3. ALB+Auto Scaling Group+EC2+Fastapi 로 구성된 서버를 Serverless로 전환할 때의 고려사항이 무엇인가요?︎

보자마자 엥 이게먼데… 난 이제 이유식먹는 개발자였음을 다시한번 깨달았구,,,
찾아보면서 생각해보기로 했다.

 

1번질문

-----------------------------------

우선, 질문을 보고 처음 든 생각은 feature가 뭔데... 였다.

feature가 자기가 개발한 브랜치라면, 병합한 걸 돌려서 A가 작업한 것 만 하거나 git cherry 쓰기? 라고 생각함.

한편으론 그냥 A가 브랜치 메인으로 새로 파서 그거 걍 올리면 안됨...? 싶음.

 

우선 Git Branch 종류가 있다고 한다. 5가지로 메인브랜치 (master , develop) 와 보조 브랜치 (feature , release , hotfix ) 라고함.https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html

[GitHub] Git 브랜치의 종류 및 사용법 (5가지) - Heee's Development Blog

이 문서를 보면 확실히 이해할 수 있다.

 

master branch가 현재 배포 버전 ( 과거 배포 이력을 볼 수 있음 )

 

develop branch가 다음 출시 배포 버전을 개발함 ( 안정버젼임을 확인하면 master branch와 merge )

feature branch가 기능을 개발하는 브랜치 ( 수정점이 있다면 develop을 git pull받고 개발이 완료되면 develop으로 merge )

(1. develop의 수정해야할 부분을 받아옴  / 2. 수정하기 / 3. feature branch에서 수정이 끝나면 develop과 merge / 4. feature브랜치 삭제하기)

 

release가 이번 출시 버전을 준비하는 브랜치 ( develop에서 일정 수준이 모이면 release로 모임. 배포가능 상태라면 마스터에  병합. 배포완료 후  디벨롭 브랜치에도 병합 )

( 1. develop에서 배포할 수준의 기능이 모이면 release 브랜치로 분기 (release에선 버그수정, 문서추가 등 기능은 건드리지 않음 ) / 2. release에서 배포 가능하게 바꾸면 master로 merge )

고로 develope(기능모음) > release(문서작업 , 추가 버그 수정) > master( 최종 배포)

 

hotfit branch는 출시 중 버그 긴급수정 브랜치

(1. 버그발생 > 2. master에서 hotfix 브랜치 새로 분기 > 3. 버그 수정 > 4. 다시 master에 merge  , develope에도 merge)

 

아래 코드는 내가 나중에 보기 위한... 브랜치 생성 및 종료 명령어

 

feature branch 과정

// feature브랜치 새로 파는데 master가 아니라 develope에서 따와야함, 아래 예시는 로그인 피쳐만들기
git checkout -b feature/login develop


// 새로운 기능 작업 수행

// develope브랜치로 이동
git checkout develop

// develope브랜치에 feature/login브랜치 내용 merge
// --no--ff는 새로운 커밋 객체를 만들어 develop에 merge하는데 feature브랜치에 존재하는 커밋이력을 모두 합쳐 새로운 커밋 객체를 만드는것이라 함.
git merge --no--ff feature/login

//피쳐 삭제
git branch -d feature/login

//디벨롭 브랜치 원격 저장소에 올리기
git push origin develop

// 사실 --no-ff는 왜 쓰는 지 모르겠음. 커밋이력을 모두 합친다는 말이... 

// 내가 feature/login에 수정한 기능은 내 의도대로 수정할 점을 완벽하게 고쳤는데 커밋이력을 모두합쳐야하나...?

 

release branch 과정

//마찬가지 develop에서 따옴. master아님
//release이름 국룰은 release-x.x.xx이런 느낌이래요
git checkout -b release-1.2 develop

//배포 사이클 시작

//release에서 배포 가능한 상태가 됨 > 마스터로 이동
git checkout master

//master브랜치에 release-1.2 branch merge
git merge --no-ff release-1.2

//병합한 커밋에 release버전 태그 부여
git tag -a 1.2

//develop에도 마스터 버젼 따오기
git checkout develop
git merge --no-ff release-1.2
git branch -d release-1.2

// 태그를 붙이는 이유는 커밋을 참조하기 쉽도록하려고...단순..

 

hotfix branch 과정

//유일하게 마스터에서 가져올 수 있다
git checkout -b hotfix-1.2.1 master

//수정

git checkout master

git merge --no-ff hotfix-1.2.1

git tag -a 1.2.1




//develop에도 적용
git checkout develop
git merge --no-ff hotifx-1.2.1

 

 

보아하니 hotfix말고는

develop에서 가져오기 > 기능추가와 수정 > develop에 합치기 > 어느정도의 기능이 develop에 모임 >

develop에서 가져오기 release생성 > release에선 버그와 문서정도의 간단작업 > master에 병합 > 배포

hotfix는 master에서 hotfix-x.x.x.. 로 분기 > 버그 고치기 > master와 merge

정도인 듯 

 

근데 위의 과정은... git-flow이고 간단한 fithub-flow가 있는데 이건 걍 master언제나 배포가능 > 새로운 프로젝트는 master 기반으로 별도의 브랜치에서 작업 > 로컬에서 커밋, 원격에 push. > 승인받으면 master에 병합ㅇㅇ

 

 

정도가 git branch의 정석...? 인 듯. 암튼 feature브랜치가 알았으니 다시 문제로 돌아오자면,

1. A, B 두 사람이 각각의 Feature를 개발해서 develop branch에 병합을 한 상황입니다. 그런데 A가 작업한 Feature만 배포를 하기로 했습니다. 이 때 올바른 Git 사용방식은 무엇인가요?

 

열심히 머리를 굴려봤지만,,, 그냥 머지기록 확인해서 b가 병합하기 전으로 돌아감>a가 먼저 병합했으면 그대로 배포하고 아니면 다시 a가 develop에 push함... 밖에 떠오르지 않음...

gpt에게 물어보니, tag를 사용하라고 한다.

a작업 feature branch로 이동 > 여기서 tag 생성(git tag v1.0.0) > 태그 푸쉬 > 디벨롭에서 머지 하라고 함

 

아니면 내 생각과 비슷하게 log확인 > b전으로 옮기기...라네요

 

더 좋은 수가있으면 추가하겠지만...이거로 해도 상관은 없지않나...싶다...

 

 

2번질문

-----------------------------------

2. RDB 또는 NoSQL을 사용하던 도중 불편함을 느꼈던 경험과 개선 방안에 대해 알려주세요.

 

RDB라는게 그..relation data base? 맞겠죠? 이거랑 noSQL은 더 써보고 추가해봄.

 

우선 RDB = Relational DataBaseㅇㅇ 디게 많이 본 개념임

 

각 테이블마다 pk가 있고 fk를 통해 테이블 간 관계를 볼 수 있음.

 

wwg할 때 erd를 한 번 짜보긴 했음.

첨엔 저렇게 하나하나 나누어서 나중에 쓰기 쉽게 해야지! 하면서 하나하나...~ 나눴다.

근데, start_location이니.. TIME이니... 다 기억하기도 쉽지 않았고, 막~ 코드를 짜다보니 우째 나누는게 더 어려워서

근데, start_location이니.. TIME이니... 다 기억하기도 쉽지 않았고, 막~ 코드를 짜다보니 우째 나누는게 더 어려워서

간단하게 바뀌었음. 막 하다보니 < 이부분이, 데이터를 받아오는 과정이 다 ~ JSON으로 되어있어서 세세하게 나눌 필요가 없었으며, JSON을 JS객체로 바꾸어서 JSON내부의 객체들도 접근이 가능하니 필요가 없었음!!!

 

암튼 진짜 쪼금 ~~ 바다가 있다면 나뭇잎에 고인 이슬만큼 써본 경험으로썬... 데이터 접근이 느렸다 ?정도 ㅇㅇ, 그리고 하나하나 정의를 해야한 다는 점, 마이그레이션을(구조변경시에) 맨~날 해줘야한다는 점에서 구렸음. noSQL방식( noSQL db를 쓴 게 아님 ) 을 사용했을 땐, 만든 서비스에선 불편한 점 없었음. 근데 중복값들어가면 알지못하기 때문에... 구릴듯...?

 

질문의도가 먼지 모르겠음 아직은... RDB = 관계형 , noSQL = 비 관계형 데이터베이스 ... 그럼 두개 개념이 이분법으로 딱! 나뉘는데, 그냥 db를 사용하던 중 어려운걸 물어본건가...싶?음

 

오 찾아보니까 비슷한 거 ? 같음 !! 키벨류없이 .... JSON비슷하게...... 개인적으로 noSQL를 더 좋아지려고 합니다.

 

3번질문

------------------------------------

3. ALB+Auto Scaling Group+EC2+Fastapi 로 구성된 서버를 Serverless로 전환할 때의 고려사항이 무엇인가요?︎

 

이것두 더 알아보고 추가해봄. 일단 아는건 EC2 ㅋㅋ 나머진 암것도 모름

 

우선 ALB....다음주에 추가하겠삼.............ㅎ 우째 AWS비기너 자격증딴다는 애가 아무것도 모르노....내다버린 세달이다.