0. 오프닝

2주가 지난 시점에서 쓰는 2차 프로젝트 회고록이다. 원래는 끝난 직후에 바로 쓰는게 생생하지만, 그 주 주말은 4주간 진행됐던 프로젝트 때문에 피곤해서 도저히 불가능했고, 저번 주는 협업 시작을 하고 아직 정신이 없었다.

1차 확실히 느낌이 달랐던게, 코로나로 인해서 2주 전부 온라인으로 진행됐다. 스크럼 미팅을 해야 하는데, 매일 구글밋으로 모여서 얘기하는게 좀 색달랐다. 두 번의 1주 스프린트 동안 그래도 매일의 스탠드업 미팅은 잘 진행됐다. 하지만 실시간으로 무언가를 물어보는게 어렵기는 했던게, 내가 만들어진 부분을 프론트와 빨리 맞춰볼 수 있었으면 서로 건강한 텐션이 유지되고 기능구현도 더 원활하고 빠르게 됐을 것 같은 느낌을 받기는 했다.

1. 프로젝트 소개

이번 프로젝틑 투표했던 프로젝트 중 하나였는데, 스타트업 기업들의 채용공고로 유명한 '원티드' 백엔드를 클론하게 됐다. 원티드를 하고 싶었던 가장 크 이유는 프로젝트를 하면서 다양한 스타트업의 공고들을 보면서 추후에 있을 취업준비에 도움이 될거 같다는 생각도 있었다. 위코들 오기전에 개발관련 회사들은 어떤 기준으로 사람들을 뽑나 너무 궁금해서 일일히 공고에 들어가서 원하는 스택들을 정리해서 개인 노션에 정리해 놓기도 했는데, 이 참에 크롤링으로 해보자는 생각도 있었다.

2. 사용된 기술

전체적인 스택은 1차 때와 비슷하지만, 추가적으로 들어간 부분들이 있다.
초록색은 개인적으로 적용한 툴들이다.
Scrapy
Selenium
Beautiful Soup
Python
Django
CORS Headers
JWT, Bcrypt
Git, Github
AWS EC2, RDS, Elasticache
Docker
Redis

3. 내가 맡은 역할/부분

사이트의 어떤 기능들을 클론할 건지 전체 팀미팅을 하면서 모델링은 크게 두 부분으로 나뉘었는데,
1) 채용, 2)개인 이력서 관리이다.
아무래도 채용이 메인인 사이트이고, 그 채용을 지원하기 위해서는 회원이 필요하기 때문인데,
나는 채용 부분을 맡게 됐고 - 따라서 필요한 채용공고들 크롤링과 관련된 모든 엔드포인트들을 작성했다.

워낙 1차 프로젝트 때 상품 관련 모델링&엔드포인트 작성을 해봐서 인지 크롤링이 되고난 이후에 일들은 굉장히 순조롭게 진행이 됐다. 1주차에 대부분이 완성이된 상태였고, 심지어 1차 프로젝트 때는 거의 매일 10시에 위코드에서 집에 가곤 했는데, 2차 때는 건강을 좀 챙기는게 좋을거 같아서 저녁 6-7시까지만 하고 쉬었는데도 불구하고 확실히 한번 해봤던 부분들을 금방금방 진행이 돼서 좀 신기했다.

2주차는 리팩토링및 프론트와 붙여보는 작업을 했고, 발표 전날에는 도커 세션을 듣고 도커로 이미지를 만들어 컨테이너로 띄우고 1차때 못해봤던 EC2에 배포및 RDS연결을 경험해 봤다. 여기서 살짝 복잡했던건, 2차 때 무조건 적용해 봐야겠던 Redis를 어떻게 연결시킬건지 였다.

CS 기초지식이 부족해서 그런지 포트를 연결 시키는거에 대한 이해 안됨과 복잡함이 있었다. 처음에는 막연하게 "아 스택오버플로우에 보면 누군가가 레디스를 도커로 연결시켜서 올려봤겠지"라고 생각했는데, 내가 너무 내가 그린 코드에 대한 고집이 있어서 그런지 원했던 결과는 찾지 못했다. 그러다 생각이 난게, MySQL도 도커로 안하고 AWS로 연결시키는데, Redis도 그렇게 하는게 맞지 않을까 싶어서 AWS를 찾아봤더니 그런 서비스가 있었고, AWS로 연결시키는 방법은 그냥 혼자서 공식문서보고 했다.

4. 잘한점 & 아쉬운 점 & 해결/개선 방법

잘한 점은 세션 때 배우지 않은, 혼자서 또다른 AWS 서비스를 써본 것이다. 이게 시간이 지나고 생각해 보니 굉장히 큰 자산인게, AWS에는 백개가 넘는 서비스가 있고 회사를 가게 되면 무조건 내가 배워보지 못한 서비스를 사용하게 된다. 하지만 이걸 누군가의 도움을 받지 않고 혼자한게(사실 그렇게 어려운 것도 아니였지만) 자신감을 많이 주는거 같다.

그리고 또 하나는 파이썬의 Descriptor 사용이다. 파이썬은 결국 '객체지향언어'이다. 모든 것이 객체로 표현이 되기 때문에, 결국 기존에 생성된 객체의 함수를 override하거나 새로 추가하게 된다. 나도 이번에 코드 하나를 짰는데 짜보니 너무 지저분하고 너무 길어서, 예전에 얼핏 봤던 모델에 함수추가 기능을 해봐야겠다 싶어서 사용하게 된 결과는,

class MainCategory(models.Model):
    name = models.CharField(max_length = 100)
    @classmethod
    def salary_average(cls, id, year):
        average = cls.objects.get(id= id).subcategory_set.filter(salary__year = year).aggregate(Avg('salary__payroll')).get('salary__payroll__avg')
        return average

자세히 보면, MainCategory 안에 있는 하나의 SubCategory의 특정 년도의 연봉 총합을 가져와야 한다. 예를 들면, 메인 카테고리에는 개발, 디자인, 마케팅, 등등이 있고, 개발 안에는 프론트개발, 백엔드 개발, 파이썬 개발, 등등 여러 서브 카테고리들이 있다. 이 서브 카테고리들은 M2M으로 Salary가 있다.

간단하게 관계를 설명해 보자면,
Main Category <-(OTM) - SubCategory <-(M2M) -> Salary
이런 형태이다. M2M은 또 새로운 테이블을 만들었다. Salary는 총 신입부터 10년차까지 연봉에 대한 숫자가 있는데,
내가 필요했던 데이터는 유저가 개발(메인)을 눌렀을 때, 개발과 관련된 모든 서브카테고리들(프론트, 백엔드, 파이썬..등등)의 신입부터 10년차까지의 연봉 평균이다. 각 서브마다 연봉이 다르기 때문에 그것들을 총합해서 평균내는게 필요했고, 그래서 처음에는 클래스메서드없이 접근해서 가져오기는 했는데, PEP8의 1줄 제한을 넘어섰는데, 클래스메서드를 통해서는 아주 간단하게 가져올 수 있게 됐다.

class AverageSalaryView(View):
    def get(self, request, id):
        if MainCategory.objects.filter(id = id).exists():
            average = {
                'junior'  : MainCategory.salary_average(id, 0),
                ...

물론 다해놓고도 살짝 아쉬운 마음이 있었지만 일단 구현했다는게 자랑스러운 이유는,
사실 처음 파이썬 공부했을 때가 생각이 났다. 불과 한달 전만 하더라도 Codeacademy에서 Class를 배울 때,
도대체 이게 왜 쓰는거고 어떻게 쓰는건지 봐도 몰라서 머리 아팠던 생각이 났다. 하지만 그 동안에 파이썬 언어 자체에 대해서 더 알게 되고, 숙련도가 조금 높아지고 클래스메서드도 써보게 된게 너무 신기하다.

반면에 아쉬웠던건 Redis에 대해 더 깊게 들어가지 못했던 것이다. 웹개발에서 가장 어려운게 작명이랑 Cache Validation이라고 하는데, 작명은 농담반 진담반이라면 캐시 유효성 검사는 실제 서비스에 굉장히 중요한 요소이고, 저장만 해서 되는게 아니라 바뀌었을시 같이 바뀌게 만들어 놓는게 필요하다. 물론 우리는 서버가 하나밖에 없고 내용도 바뀌지 않기 때문에 그렇게까지 구현은 안했겠지만, 그래서 전체적인 개념을 공부못한게 좀 아쉽긴 하다.

그렇게 또 이어지는게, 전체 네트워크에 대한 부족함을 많이 느꼈다. 사실 2차 끝난 시점에는 프론트에서 요청이 들어오면 View로 통해서 내 DB에서 가져와서 응답을 보내는 아주 단순한 플로우 밖에 알지 못하 상태이다. 많은 요청들의 로드 밸런스를 어떻게 할지에 대한 이해가 더 필요하다고 느꼈다. 개선 방법을 지금 찾아보자면, 이제 곧 현재 하고 있는 기업협업에서 실제 배포 경험을 해보게 될텐데, 디비와 네트워크에 대해 더 공부해서 어떻게 하면 효율적으로 전체적인 프로세스를 운용할 수 있는지 공부가 필요하다.

5. 기록하고 싶은 코드/로직/함수

(4번에서 이미 기록했고 너무 길어지는건 싫기 때문에...)

6. 엔딩

이제 위워크에서 진행되는 위코드의 프로그램은 거의 끝이났다. 2차 후 바로 기업협업을 나가기 때문에, 매일 아침에 일찍와서 아무도 없는 8층 라운지에서 하루를 준비했던 시간(뭔가 큰 방을 나 혼자 사용하는 기분), 그리고 저녁까지 편하게 공부하다 가는 시간이 없어지는건 좀 아쉽다. 협업을 하남으로 가게 되서 빨리 갔다 늦게오는게 시간적인 제약이 생기고, 또 이제는 실제 서비스를 진행해야 하기 때문에 내가 하고 싶은 공부를 하는건 어렵다. 그래서 위워크에서의 위코드를 정리해 보면,

"어떻게 공부를 할 것인가"가 정말 중요한거 같다. 사람에게는 각자만의 공부방식과 루틴이 있다. 루틴을 짜는건 나름 쉬운데, 방식은 조금 어려웠던거 같다. 나름대로 빠르게 적응하는 사람이라고 생각했는데, 소프트웨어라는 분야를 어떻게 가장 효율적으로 공부할지는 좀 시간투자가 필요했다. 예를 들어 대학에서 영문과 공부를 할 때는, 시험을 잘보기 위해서는 책을 다 읽고 내가 시험에서 어느 부분에 집중적으로 내 이야기를 담아낼지에 대한 준비가 필요했고, 문학을 더 깊게 이해하기 위해서는 선생님의 강의나 학생들의 발표에 집중을 했다. 위코드의 교육 프로그램도 비슷하다 - 학생들을 어떻게 job-ready로 만들것이냐에 위코드는 '클론'을 선택한거 같다. 실제로 클론을 하면서 전체적인 개발 플로우를 익히게 되기 때문에 아주 알맞은 프로그램이다.

그렇다면 앞으로 개발자, 소프웨어 엔지니어가 되기 위해서 어떤 방식을 택해야 할까? 책을 많이 읽어야 하는지, 강의를 많이 들어야 하는지를 넘어서서 - 어떻게 내 것으로 만들지에 대해서 생각을 더 많이 하게 된거 같다. 조금 더 본질적인 질문을 하고 나에게 맞는지를 고민하고 실행에 옮기는 것이다.

예를 들어 지금 협업사에서는 플라스크를 메인 백엔드로 쓴다. 그러면 그냥 "아 여기서 플라스크 쓰니까 나도 배워야겠네" 이런 마인드로는 개인적으로 무언가를 하기 어렵다. 나한테는 동기부여가 굉장히 중요해서, 물론 밍기적밍기적 출근해서 좀 써보고 동영상 몇개 보다보면 조금씩 익숙해 질 수는 있다. 누구든지 엄청난 시간을 부으면 언젠가는 할 수 있게된다. 하지만 빠르게 흡수하기 위해서는 나는 동기부여가 필요하다는걸 알고, 어떻게 하면 플라스크 공부가 나에게 동기부여가 될 수 있을까 찾아보다 보니, 비단 플라스크를 배우는게 중요한게 아니라 현재 백엔드 생태계(?)에 대해서 더 알게 됐다. 모든 회사들이 장고를 쓰는게 아니고, 플라스크와 같은 마이크로프레임워크를 쓰는 회사도 많고 심지어 본인들만의 프레임워크를 만드는 회사들도 있다. 특히 관심있게 봤던 회사들이 마이크로프레임워크를 사용한다는걸 알게 되고(플라스크는 아니지만), 내가 백엔드/서버 개발자로서 성장하기 위해서는 회사에서 쓰는 플라스크를 할 줄 아는게 중요하다는 판단이 됐다. 이런 생각의 흐름이 내가 위코드에서 얻은 가장 큰 배움이 아닐가 싶다.

어떻게 내 자신을 동기부여 시킬건지,
그리고 그 일을 어떻게 가장 빠르게 흡수할 건지 - 구체적으로,
어떤 질문을 던져서 어떻게 대답을 얻을건지.

로컬에 남겨진 레거시 코드는 리팩토링이 되기도 한다. 코딩 실력과 CS지식은 앞으로 리팩토링 되면서 당연히 성장해야 할 부분이겠지만, 마인드는 바뀌지 않고 계속 공부하는 마음으로 성장했으면 좋겠다 :)