[우아한 테크코스 3기] LEVEL 3 회고 (155일차)

안녕하세요? 제이온입니다.

 

그동안 참 많은 일이 있었습니다. 그리고 그러한 일들을 감당하느라 굉장히 하루 하루가 피곤해서 부득이하게 장기적으로 포스팅을 작성하지 못했습니다. 오늘부터는 다시 1일 1회고를 최대한 지키려고 합니다.

 

 

면접의 연속

첫 면접은 포비와의 레벨 3 모의 면접이었습니다. 레벨 2 기간동안 배웠던 스프링, 인프라, JWT 등과 관련된 질문이 오갔고 전반적으로 답변을 잘 하지 못했다는 생각이 듭니다. 특히 포비께서는 제가 이론을 암기해서 답변하는 느낌이었고, 그로 인해서 얕은 개념에 꼬리 질문이 들어가서 답변하기 어려웠을 것이라고 말씀해 주셨습니다. 따라서 답변을 최대한 경험 기반으로 작성할 것을 피드백해 주셨습니다. 면접 이후 이력서 쪽에는 제가 경험해서 알게된 지식을 바탕으로 예상 답변을 달아 보았고, 기본적인 CS 지식은 경험이 없어서 어쩔 수 없이 암기 기반으로 예상 답변을 달았습니다.

 

그리고 포비와의 면접으로부터 다음 주에는 실제 기업 면접을 치루었습니다. 이전에 말씀드렸던 S사였고, 기술 면접 1시간 30분, 라이브 코딩 1시간, 팀 면접 1시간으로 진행되었습니다. 저는 최대한 알고 있는 것만 잘 말하자고 다짐은 하였으나, 아무래도 첫 면접이었던만큼 긴장도 많이 했고 제가 굉장히 부족한 점이 많다는 것을 깨달았습니다.

 

특히 도커 쪽이 경험이 적은 건 사실이지만, 제가 어떻게 구현했는지 그 당시 갑자기 머리가 하얘지면서 대답을 제대로 못한 것이 참 아쉬웠습니다. 그 외에 IoC와 DI를 혼합해서 이해를 하고 있었고 CS 쪽은 꼬리 질문에 대해서 거의 답변을 못 했습니다. 이렇게 기술 면접에서 한 바탕 멘탈이 흔들리고 긴장도 많이 해서 그런지 라이브 코딩에서도 제대로 된 성과를 내지 못하였습니다. 지금 생각하면 구현 난이도가 어려워 보이지 않은데, 면접관 분이 실시간으로 제가 코딩하는 것을 보시고 시간 제한이 빡빡하다는 점때문에 부담이 많이 되었던 듯합니다.

 

이렇게 기술 면접과 라이브 코딩이 끝나고 넋이 나가있는 상태에서 팀 면접이 진행되었습니다. 비개발직군 직원 두 분이 들어오셨고 전반적으로 편안하게 진행되었습니다. 제가 어떠한 사람인지에 대해 순수 경험 기반으로 진행되었기 때문에 답변하기도 어려움이 별로 없었고 굉장히 재미도 있었습니다. 그래서 더욱 해당 팀에 합류하고 싶다는 생각이 들었고, 이 때문에 기술 면접과 라이브 코딩에서 미흡했던 것이 많이 아쉬웠습니다.

 

전체적으로 첫 면접은 만족스럽지 않았으나 강도 높은 면접을 통해 많이 성장할 수 있었다고 생각합니다.

 

 

다음 면접은 E사의 1차 면접이었습니다. 인성 면접과 기술 면접을 함께 보았는데, 분위기가 편안했고 질문 자체도 제가 졸업생이 아니었기에 평이한 질문이 많이 나왔습니다. 오히려 기술보다는 인성 면접이라고 보는 것이 더 적합해 보였고, 대답을 어느 정도 수훨하게 할 수 있었습니다. 다만, 제가 JCF에 대해서 어필을 제대로 했어야 하는데 답변이 만족스럽지는 않았습니다. 2차 면접은 난이도 있는 기술 면접으로 알고 있는데, 1차 면접에 합격한다면 준비를 더욱 잘해봐야겠습니다.

 

 

레벨 3 프로젝트 팀 결성

저번 주 레벨 3 프로젝트 주제를 정했고, 그 주제에 맞는 팀원이 정해졌습니다. 저는 댓글 모듈을 개발하는 기획에 관심이 있었고, 미리 해당 주제를 같이할 백엔드 팀원을 구했습니다. 다행히 해당 팀원들인 제리, 우기, 아론과 함께 할 수 있었습니다. 그리고 프론트엔드 팀원은 도비와 곤이로 정해졌는데, 굉장히 잘하시는 분들로 소문이 나서 많이 기대가 되는 상태입니다 ㅎㅎ

 

팀 결성이후 회의를 진행했는데, 다들 애자일스러운 개발을 선호하였고 우선 핵심 기능부터 빠르게 구현하는 것으로 잘 합의가 되었습니다. 팀 문화나 스케줄들을 정하고, 백엔드와 프론트끼리 각자 개발 컨벤션도 만들었습니다. 전반적으로 어제까지는 구현할 기능 목록을 정하고, 팀끼리 친해지는 시간을 갖고, 컨벤션을 정하는 등 개발을 위한 기본적인 일들을 수행했습니다.

 

 

오늘 배운 내용

이제 오늘로 돌아오겠습니다. 오늘은 정말 중요한 내용을 많이 배웠습니다. 그 중에서도 가장 시간 투자를 많이 한 부분은 Git Flow 전략입니다. 쉽게 이야기해서 여러 명이 협업을 진행할 때 브랜치를 적절하게 잘 나누어서 PR과 merge를 하는 과정이라고 보면 됩니다. 우선 우리 팀은 하나의 저장소 안에서 'main - develop/be & develop/fe'으로 나누었습니다. 그리고 develop 단에서 기능을 구현할 때는 'feature/{be or fe}/{기능 이름}/{이슈 번호}' 브랜치를 생성하여 저장소에 push한 다음 develop 단으로 pr을 하는 방식입니다. 해당 pr에서는 팀원이 코드 리뷰를 한 다음 문제가 없다면 merge를 합니다. 비슷한 방식으로 develop 단은 백엔드와 프론트엔드 디렉토리가 분리되어 있으므로 배포하기 전에 release 브랜치를 임시로 만들어서 두 디렉토리를 합치고 main 브랜치로 최종적으로 pr을 날려서 merge를 합니다.

 

이때 merge 하는 방식이 총 3가지가 있었습니다. 각각 merge, squash and merge, rebase and merge가 있었습니다. 세 가지 모두 두 브랜치의 커밋을 합친다는 느낌이 있지만 각각 결과가 다릅니다.

 

 

먼저, merge부터 보겠습니다.

 

 

 

 

merge는 합치기 전 브랜치에서 작업했던 커밋 히스토리를 모두 가져 오고, 최종적으로 merge가 되었다는 커밋을 추가로 남깁니다.

 

 

 

 

이런 식으로 'feature/fe/add/3' 브랜치에서 작성한 커밋들을 모두 가져 오고 마지막에 'Merge pull ~' 내용이 있는 커밋이 생깁니다.

 

 

 

 

squash and merge는 합치기 전 브랜치에서 작업했던 히스토리를 하나의 커밋으로 퉁칩니다.

 

 

 

 

이런 식으로 'feature/be/add/5' 브랜치에 있던 커밋들이 하나의 커밋으로 묶여서 생깁니다. 개인적으로 feature 브랜치에서 develop 브랜치로 merge를 해야할 때는 squash and merge 방식이 적합하다고 생각합니다. 왜냐하면 develop 브랜치는 기능 단위 커밋이 필요한 것이지, 하나의 기능을 구현하기 위한 세부 커밋들까지 모두 가지고 있을 필요는 없다고 생각하기 때문입니다.

 

 

 

 

rebase and merge는 합치려는 브랜치에 있던 커밋을 가져와서 하나의 소스 트리로 합쳐 줍니다. 기존 브랜치에 커밋이 d와 e가 있었고 a, b, c와는 별 영향이 없다면 그대로 a, b, c 커밋들이 추가됩니다. rebase 개념 자체가 아직은 좀 부실한 상태라서 자세히는 모르겠으나, merge와 다르게 끝 커밋만 비교하는 것이 아니라 모든 커밋들을 다 비교하는 것 정도로 이해하고 있습니다.

 

 

 

 

예를 들어 이미 develop/fe 브랜치에는 1.txt, ... , 5.txt까지 파일을 생성하는 커밋이 있었고, 'feature/be/add/5' 브랜치에는 1.txt, ... , 7.txt까지 파일을 생성하는 커밋이 있었다고 가정해 봅시다. 그렇다면, 'feature/be/add/5' 브랜치에서 develop/fe로 rebase 할 때는 기존 커밋들을 살펴보면서 기존 상태와 'feature/be/add/5' 브랜치에서의 상태를 비교하면서 변화가 있는 커밋들만 추가가 됩니다. develop/fe 브랜치와는 달리 'feature/be/add/5' 브랜치는 6.txt와 7.txt 관련 커밋이 있으므로 이것들만 develop/fe 브랜치에 추가되는 것입니다.

 

rebase는 계속 학습해 보겠습니다.

 

 

정리

이후에는 카카오 소셜 로그인을 하는 과정에 대해 학습하였습니다. 팀원들의 도움을 받아 어떤 식으로 흐름을 잡아야할 지 이해할 수 있었으나, 제가 oauth2 관련 지식이 없어서 해당 지식을 관련 강의로 익힌 뒤 내일 구현해 보려고 합니다. 소셜 로그인과 관련된 내용은 내일 구현하고 난뒤 포스팅으로 작성해 보겠습니다.