Codelog 제작기

1. 개요

나는 시간이 날 때 마다 개발 관련 웹서핑을 한다. 이렇게 간간히 지식을 쌓는 것은 나름 좋은 습관이었는데, 몇가지 문제가 있었다. 각잡고 보는게 아닌  이상 하나의 글을 끝까지 보기가 힘들다는 것이다. 그래서 내 휴대폰 브라우저에는 항상 100개가 넘는 창이 열려있었다. 물론 끝까지 읽은 글들은 절반정도밖에 되지 않는다. 그래서 막연히 생각만 했었다. URL을 모아두는 Repository Site를 하나 만들면 참 좋을 것 같다고. 마침 어떤 토이 프로젝트를 해볼까 고민하던차였고 이번에 만들어보기로 했다. 원래 계획했던 기간은 2일이었는데 역시나 작업을 진행하면서 여러가지 트러블 슈팅을 직면하였고 결과적으로 4일 조금 넘게 걸려 현재는 성공적으로 배포를 완료한 상태이다. 위와 같은 생각의 흐름을 통해 만들어진 결과물,  Codelog(http://codelog.kr) 서비스의 제작 후기를 포스팅으로 한번 남겨본다.

 

2. 기술 스택

백엔드는 당연히 파이썬으로 하기로 했다. 최근에 Golang에도 관심이 있었지만 빠르게 제작하기엔 아직 미숙한 부분이 많았다. 이전 토이 프로젝트는 Sanic Framework를 통해 제작했었는데 이번에는 그냥 Flask를 사용하기로 했다. 비동기적으로 동작할 필요가 큰 사이트가 아니었기 때문이다. 그리고 Django를 붙일만큼 많은 기능이 필요하지도 않았고, 라이브러리를 가져다가 붙여서 쓰기보단 직접 밑바닥부터 만들어보고 싶었다.

프론트엔드는 조금 고민을 많이 했다. 예전에 작업할 때 React.js를 사용했었는데 이번에도 리액트로 갈까, 아니면 뷰로 한번해볼까. 결과적으로 Vue.js를 사용하기로 했다. 사실 나는 프론트를 작업할 때 라이브러리를 많이 사용하지 않는다. 내가 느끼기에 요즘의 프론트엔드 진영은 대격변의 시대이기에 Deprecated되는 기능들이 너무나 많고 그만큼 유지보수가 제대로 되지 않는 라이브러리가 넘쳐나기 때문이다. 또한 기존에 CSS로 레이아웃을 잡을 때 Flexbox를 사용했었는데, 이에 대해 여러가지 한계점을 느꼈었다. 그래서 Grid System을 한번 사용해보고 싶었다. 이렇게 써놓고 생각해보니 프론트는 어떠한 프레임워크/라이브러리를 사용해도 큰 문제가 없었다라는 생각이 든다.

 

3. 인프라

퇴사하기 이전 회사에서 AWS를 사용했었다. 그렇기에 가장 익숙한 것을 사용하기로 했다. CI는 Bitbucket Pipeline을 사용했었는데, 이번에는 Github Actions(https://hides.tistory.com/1050)를 사용하기로 했다. 저장소를 Github를 사용하기 때문이다. CD는 AWS의 Codedeploy를 사용하려다가 프리티어는 지원하지 않는다는 이야기를 들어서 그냥 CI가 끝난 후 ecs-cli를 통해 트리거하기로 했다. 따라서 CI/CD는 아래와 같은 흐름을 가진다.

 

1. Github master 브랜치에 push

2. 테스트 코드 실행

3. Docker image 빌드 후 ECR에 푸시

4. ecs-cli를 통해 배포 진행

 

다음으로 전체적인 인프라 구조를 살펴보자. 일단 백엔드 서버쪽은 Elasticbeanstalk이나 기본 EC2를 사용하지 않고 ECS(Elastic Container Service)를 이용했다. 로컬에서도 도커를 사용하여 개발 및 테스트를 진행하기 때문에 코드로 쉽게 일관성을 유지하기 위함이다. 또한 데이터베이스로는 RDS를 사용하였고 로그를 남기기 위해 CloudWatch를, 캐시를 위해 Elasticache(Redis)를 사용했다. 마지막으로 도커 이미지를 저장하기 위해 ECR을 사용하였다. 사실 이렇게까지 해야하나 싶기도 한데, 어차피 프리티어에서 커버할 수 있는 범위이므로 실제 프로덕션 서버와 비슷하게 구성했다.

프론트엔드는 Route53을 통해 구입한 도메인을 연결시켜줬고, 실제 Vue.js 코드는 빌드하여 S3에 배포했다. 이번에 S3배포를 처음 사용해봤는데 정말 간단해서 조금 놀랐다.

기존에 이미 작업해봤던 내용이기 때문에 크게 어려웠던 점은 없었고, 위 내용들을 토대로 전체적인 인프라 구조를 그려보자면 다음과 같다.

 

간단하게 설명하자면, 유저가 http://codelog.kr 를 주소창에 입력하고 들어오면 먼저 Route53으로 들어온다. 그리고 Route53을 통해 정적 웹사이트인 S3을 만난다. S3에서는 API서버에 접속할 때 ALB(Application Load Balancer)를 통하고 해당 로드 밸런서에서 ECS로 알아서 라우팅해준다. ECS에서는 CloudWatch, RDS, Elasticache를 통해 적절하게 작업을 진행한 후 결과를 S3로 넘겨주고 S3에서는 해당 Response를 통해 유저에게 랜더링해준다.

 

4. 회고

1. 이번 기회를 통해 Vue.js도 사용해보고 Grid System도 사용해봤다. 그리고 시간이 지나서 조금 가물가물했던 전체적인 인프라를 구축하는 방법도 다시 한번 기억속에 각인시킬 수 있었다. 확실히 얻은 것이 많은 작업이었다.

2. React, Vue등 SPA의 가장 큰 문제점(혹은 어려운점)은 상태관리이다. React는 보통 Redux또는 Mobx를 통해 상태관리를 하는데 나는 리덕스를 사용했었다. Mobx는 안써봐서 모르겠고 리덕스는 Flux pattern을 사용하는데, 처음 접했을 때 개념을 정확하게 이해하기 쉽지 않았다. (물론 지금도 완벽하게 이해한건 아니지만) Vue.js는 Vuex라는 것을 통해 상태관리를 하는데 개인적으로 Vuex가 더 쉬웠던 것으로 기억된다. 중요한점은, 이렇게 여러가지 프레임워크를 사용해보면서 추후 작업을 진행할 때 어떠한 기준으로 스택을 결정할 지 판단의 척도를 수립할 수 있었다는 점이다.

3. 아직 많은 사람들이 사용하고 있진 않지만 타인이 내 서비스를 사용해주는 건 정말 즐거운 일이다. 금전적인 이익을 바라보는게 아닌 순수한 동기만으로 나를 움직이게 만들기 때문이다. 이러한 현상은 겪어보지 않은 자는 결코 이해할 수 없을 것이다. 개발자들은 이런 마인드를 토대로 인생을 살아가야 좀 더 행복할 수 있지 않을까?

4. 역시 코딩은 재밌다. 정말 재밌다.

5. 생각해보니 Redis 연동과 CD쪽 ecs-cli 트리거는 아직 작업을 안했다. 이제 슬슬 하러 가봐야겠다.

 

Codelog: http://codelog.kr

백엔드: https://github.com/teamhide/codelog_backend

프론트엔드: https://github.com/teamhide/codelog_frontend