프로젝트 회고 글타래

1. 개발 동기

2~3달 가량 전에, DSC 삼육 친구들과 정원사 프로젝트라는 스터디 겸 활동을 진행해봤다. 정해진 기간 동안 매일 매일 깃허브에 하나 이상의 커밋을 남기며 하루에 짧게라도 코딩을 하는 습관을 기르자는 스터디 였다. 당시에는 베타 수준으로 진행했기에 체계가 잡히거나 하지는 않았고 기능이 잘 동작하는지, 매일 코딩하는게 할만한지 참여해봤던 것 같다.

정원사 프로젝트를 하면서 느낀점은 생각보다 매일 코딩하거나 공부하는게 쉽지 않아서, 이런 프로젝트를 통해서라도 컴퓨터 앞에 앉아 있는게 생각보다 도움이 된다는 것이었다. 헬스장처럼 집밖을 나서는게 어려울 뿐 막상 도착하고나면 뭐라도 하게되는 원리 같달까. 그래서 이후에 진행할 프로젝트에도 계속 관심을 갖고 있었는데, 구조적으로 몇가지 걸리는 부분이 있었다.

이 프로젝트를 기록하기 위해 제공된 플랫폼은 기존에 다른 개발자님이 개발한 오픈 소스로 구성이 되어 있었다. 이 프로젝트에 참여하기 위해서 필요한 스텝은 다음과 같았다.

슬랙 특정 채널에 github 계정을 연결하기
참여자가 슬랙 해당 채널에 가입하기
참여자가 github 봇에게 본인의 푸시 이벤트를 읽도록 설정하기

슬랙이 아직 낯설어서 그런지 처음 적용하면서 약간 헤맸던 기억이 난다. 저렇게 설정하면 한 시간에 한번씩 슬랙 내용을 크롤링해서 파싱 후 그날 커밋을 했는지 확인하는 과정을 거치게 됐었다. 굉장히 편리한 시스템이라고 생각했지만, 생각보다 동아리 내 슬랙의 이용량이 낮고, 슬랙의 설정법이 약간 까다롭다보니 조금 더 쉬운 방법으로 구현할 수 없을지 고민하게 됐다.

그래서 개인적인 프로젝트로 정원사 프로젝트를 새로 꾸며보기로 했고 목표로하는 부분은 다음과 같았다.

깃허브 계정만 있으면 쉽게 홈페이지에 등록할 수 있을 것
다양한 프로젝트를 진행하고 정보를 쌓아둘 수 있을 것
깃허브 정보외에 다양한 정보를 통해 다양한 통계를 낼 수 있을 것 (선택)

프로젝트를 실행하게된 가장 큰 이유는 첫번째 항목인 깃허브 계정만 있으면 쉽게 홈페이지에 등록할 수 있을 것이었다. 슬랙에서 등록이 조금 어려웠던 탓에 모두가 조금 더 쉽게 할 수 있었으면 했다.

그리고 2번째 목표는 정원사 프로젝트가 생각보다 1회성으로 끝날 것처럼 보이지 않았기에, 본인이 계속 참석한 프로젝트를 쌓아두고 기록해둘 수 있었으면 했다. 1회 참여한 것도 큰 보람이 있겠지만, 계속 참여해 참여 기록이 쌓인다면 더 뿌듯할 것으로 보였다.

3 번째 목표는 개인적인 바람으로, 참여자의 행동을 좀 더 수치적인 모습으로 보여줄 수 있었으면 했다. 누가 순위가 높은지는 기존에 제공하고 있었지만, 하루에 얼마나 커밋을 했는지, 어떤 커밋을 했는지, 어떤 언어를 사용하는지 같은 다양한 분석들을 내놓을 수 있으면 조금 더 동기부여에 도움이 되지 않겠나 하는 생각에서였다.

2. 기술 정하기

주변에는 별다른 얘기는 하지 않았고 혼자 한번 개발을 진행해보고 싶었다. 최근에 많은 일을 해왔지만 홈페이지를 만드는 일, 특히 새로운 기술을 다루는 일을 많이 하지 않은 것 같다는게 이유였다. 다만, 너무 동떨어진 기술로 하기엔 기간이 너무 늘어질 것으로 보였기 때문에, 공부해보거나 한번쯤 가볍게 사용해본 적은 있지만 제대로 파고들어 본 적은 없는 기술들로 구성해보기로 했다.

2.1. Infrastructure & DB

프로젝트에 들어갈 때에는 항상 그럴싸한 인프라를 갖춰서 체험해보고 싶었다. 최근에 큰 규모의 팀이나 최신 기술을 실 사용중인 팀에서 일해본 경험이 적다는게 이유였다. 그래서 최대한 들어본 것들은 다 사용해보고 싶었지만 혼자 빨리 진행하는데에는 어느정도 한계가 있었기 때문에, 다뤄는 봤으나 실제로 사용될지는 모르겠고 아무튼 최신 기술스러운 것들을 다 모아보기로 했다.

2.1.1. Infrastructure

Google Cloud Platform : Compute Engine
Docker

생각보다 인프라 쪽에는 적을 것이 적다. 서버는 GCP에 게시하기로 했다. AWS는 작년에 몇번 사용해본 경험이 있고하니 이번엔 구글의 클라우드 서버를 실사용해보고 싶은 이유에서 였다. 현재 회사 홈페이지를 돌리고 있긴하지만 App Engine, Cloud SQL, Storage만 사용했고, 그 외에는 사용해보지 않았기 때문이다. 설정도 복잡하게 하기 싫었기에 Docker를 사용하기로 했고 최종 목표는 Kubernates로 배포하는 것이 목표였다.

다만 Kubernates로 배포를 하려니 생각보다 준비해야 되는 것이 많았고 생각보다 어려웠기 때문에(…) 빠르게 포기하고 Compute Engine에서 Docker로 웹서버와 데이터베이스 서버를 한번에 실행하기로 했다. 굳이 웹 서버와 데이터베이스 서버를 나누지 않고 한 서버에서 실행하는 것은 꺼림직하였으나 무료 크레딧으로 배포하고 크레딧이 다 하면 바로 게재를 중단할 계획이었기에 일을 크게 벌리고 싶지 않았던 이유도 있다.

2.1.2. DB

mongodb

데이터베이스는 기존에는 MySQL을 써왔지만, 이번에는 Mongo DB를 사용해보기로 했다. 졸업전에 이걸 다루는 수업을 짧게 들어본게 동기 부여가 좀 되었던 것 같다. 서버 개발이나, 인프라, 프론트엔드 기술은 다양하게 써보려고 했지만 생각보다 데이터베이스는 새로운 기술을 써본 경험이 전무했기 때문에, 이번에 써보기로 결정했다. 가장 어려워하는 부분이다 보니 새로운 기술을 써보기까지 좀 오랜 시간이 걸린듯 하다.

2.1.3. Source Control

git
github

너무 당연한 부분이라 적지 않을까 싶었지만, 역시 이번에도 git을 사용해보기로 했다. 프로젝트가 github정보를 크롤링하는 것이기도 하다보니, 더 익숙해질 필요가 있었다.

2.2. Backend & Frontend

2.2.1. Backend

nodejs
express
babel

백엔드는 몇번 사용해봤지만, 아직 서비스로 내본 경험은 없는 nodejs로 하기로 결정했다. 정말 오래전에 공부를 시작했지만, 백엔드 기술을 새로운 기술로 정해서 실사용하는 일은 정말 쉬운 결정이 아니다보니 내가 다니던 회사들에서는 적용해본 적이 없었다. 그래서 공부로만 미뤄두다가 최근들어 많이 사용해보고 있는 중이다. MEAN 스택이 유행하던 몇 년 전에도 Mongo DB와의 같이 쓰면 꽤 좋다는 이야기를 자주 들었기 때문이라는 이유도 있다. 라우팅 같은 기본 기능을 구현하는 건 아직도 조금 어려운 일이기에 express를 쓰기로 했다. 다만 그냥 nodejs와 express를 쓰려면 async/await나 import키워드를 사용할 수 없었기 때문에, babel을 이용해 최신 표준도 사용할 수 있도록 했다.

2.2.1. Frontend

reactjs
redux
typescript
scss

프론트엔드 기술을 결정하는데에는 큰 고민은 없었다. 회사 어플리케이션을 react-native로 제작했었던 경험이 생겨 reactjs 자체를 다뤄보고 싶은 욕심이 생겼던 이유가 크다. 크게 다르지 않다는 이야기를 몇번 들어봤기에 그럼 얼마나 다르지 않은지 직접 써보고 싶었다. 그리고 redux는 놀랍게도 아직 안써봤기 때문에, 공부가 아니라 이번 기회에 꼭 써보고 싶은 욕심이 컸다. 그리고 프론트엔드 개발을 하면서 타입 때문에 쓸데없는 유효성 검사 코드가 늘어나는 일이 많았기 때문에 typescript를 써보기로 했다. reactjs와 효율이 굉장히 좋다는 이야기도 들어봤기 때문에 한번 체험해보고 싶은 마음도 있었다. 개발 당시에는 module css는 모르고 있었기 때문에, 이왕이면 기존에 사용해봤지만 깊게 사용해본적은 없는 scss로 하기로 했다. styled component는 애니메이션을 다루는 방법같은 것들이 (내 기준에) 좀 까다로웠기에 제외했었다.

3. 그 밖에

기술 스택을 정하고 난뒤에는 구체적인 개발 청사진이 필요했다. 우선 처음 목표였던 쉽게 등록하기를 이루려면 github계정을 입력만 하면 알아서 사용자의 정보를 크롤링해야겠다고 생각했다. 그래서 github REST API를 조금 더 깊이 공부하기로 했고 몇가지 문제점을 발견할 수 있었다.

비인가 요청은 시간당 요청이 60건이 한계
인가 요청은 시간당 5000건

요청 건수에 제약이 있다는게 가장 큰 문제였다. 토이 프로젝트인 만큼, 많은 요청이 필요할 것이라 생각하지는 않았지만 시간 당 60건은 너무 적었다. 그래서 내 계정정보로 시간당 5000건까지로 변경하기로 했다. 제한된 요청 건수를 효율적으로 사용하도록 설계되어야 한다는 생각이 먼저 들었다. 그 이후에는 요청 건수를 초과할 경우 자동으로 다른 계정의 token을 사용해 요청하는 방법으로 구현할 계획을 갖고있었으나.. 일단은 하나의 계정으로 조회하는 것을 목표로 제작하게 됐다.

4. 정리하며

프로젝트를 시작하기 전에 알아보고 결정할 사항들은 이정도였다. 최대한 손에 쉽게 닿는 기술들을 찾아서 사용하기로 했고, 핵심적으로 필요한 API 같은 것들에 대해서 알아보는 것이 필요했다. 그 과정에서 정말 모르는 것도 많다 싶어 공부해야될 것이 많이 생겼다고 생각하는데, 이런 생각이 꼬리를 물어 이것 저것 집어 넣다가 유야무야된 경험이 많아서 그런지 이번엔 일단 시작하는 것을 목표로 두었었다. 매번 생각하지만 이 단계가 제일 의욕이 넘치지만, 항상 어렵다고 생각한다. 넘나 어려운 개발의 세계..

[정원사 프로젝트] 1. 토이 프로젝트 기획과 기술 정하기

정원사 프로젝트 회고, 기획과 기술 정하기