여행스케줄 기록&공유 서비스, 나간다

Park db·2021년 3월 31일
프로젝트회고
0
post-thumbnail

당신의 하루를 정리해 보세요!

나간다 는 계획된 일정을 공유하고 정리할수 있는 서비스 입니다.
여행, 데이트 등 많은 검색을 하고 일정을 준비하셨나요?
파트너와 나간다 를 공유하고 의견을 나눠 보세요!

나간다 motive

나간다는 트렐로를 모티브로 아이디어를 구상한 서비스 입니다. 칸반보드를 이용해 오전, 오후, 저녁 스케줄을 시간순서 & 중요도에 따라서 배치하고 지도api를 연결하여 파트너에게 위치까지 편리하게 공유할 수 있도록 하였습니다.

아이디어 회의를 하면서 최대한 많은 아이디어를 모아놓고 4주 프로젝트에 맞는 사이즈인지 먼저 확인 한 후 각 아이디어의 단점을 생각해 보면서 갯수를 줄여 나갔고 최종 다수결로 선택된 것이 나간다 입니다. 중요 포인트로 잡았던 기능이 칸반보드 + 지도 기반 애플리케이션 이며, 젊은 세대층을 겨냥하여 둥글둥글 한 디자인으로 결정하였습니다.

Workflow

와이어프레임 작업이 마무리가 되어갈 쯤 Miro를 사용하여 워크플로우를 제작하였고 전체적인 흐름 이해에 도움이 되었습니다. 4주 프로젝트인 만큼 생각하던 기능이 많았는데, 서브 기능보다 기본적인 기능에 대해서 더 생각할 수 있었던 시간이였습니다.

Schema

데이터베이스 스키마는 nosql 인 mongodb를 사용했기 때문에 아래와 같이 나오게 되었는데, 처음 써보는 스택이라 스키마 구조를 정하는데 굉장히 많은 시간과 노력이 들어갔습니다. 페어와 계속 의견을 나눴고, 기능 구현을 하면서도 스키마 구조가 조금씩 수정되었습니다.

API

기능구현시 어떤 방식으로 데이터를 보낼지, 어떤 형태로 보낼지 등등 구현 전 선행되어야할 중요한 작업입니다. 효율성을 위해 백엔드에서 최대한 프론트 입장을 고려하여 초안을 작성하였고 이후 팀 회의 및 기능 테스트를 진행하면서 효율적인 api가 되도록 리팩토링 하였습니다.

Stack

저는 백엔드 포지션을 맡았고, 4주 프로젝트인 만큼 사이즈가 큰 서비스를 기획했기 때문에 새로운 스택을 가져가고 싶지만 도박은 하고싶지 않았습니다. 그래서 상대적으로 익숙한 node와 express를 사용하고, 데이터베이스를 SQL이 아닌 새로운 스택인 NoSQL을 사용하고자 했습니다. NoSQL 을 사용한 또다른 이유는 '나간다'는 많은 데이터를 읽어와야 하기때문에 속도 측면에서 빨라야 했고, 수직 확장이 아닌 수평확장을 해야 한다고 생각했기 때문입니다.

아래는 서비스를 만들기 위해 사용한 스택입니다!
cloudcraft 이용하여 제작하였습니다

Process

1. 초기배포(http)

  • 첫 프로젝트때는 기능 구현을 먼저 완료 하고 배포를 진행했었는데 시간이 부족해 배포를 하지 못했기 때문에 이번엔 'Hello World' 를 먼저 띄워 놓고 시작하였습니다.

2. DB 및 스키마 생성

  • mongodb & mongoose를 사용하기 전 페어와 간단하게 공부할 시간을 가지고 함께 CRUD를 실습하고, 공유하는 시간을 가져었는데, 이 시간이 차후 기능 구현을 할때에도 매우 도움이 됐던 유익한 시간이였습니다.

    아래의 코드처럼 DB를 연결하는데, 굉장히 편했던 점은 연결할 DB가 없을경우 자동으로 생성을 하여 연결해준다는 점입니다.
    mongoose.connect("mongodb://localhost:27017/naganda", {
	useNewUrlParser: true,
	useUnifiedTopology: true,
    });

3. 로직 구현

  • api 문서를 기반으로 로직을 구현하였습니다.
  • kakao 소셜로그인, multer, JWT 등 새로 사용하거나 중요하게 생각한 로직들은 페어와 함께 진행하여 함께 성장할 수 있게 진행을 하였습니다.
  • mongodb에서 데이터를 검색하는 방법이 mysql에서 검색하는 방법과 달라 매우 흥미롭게 공부하며 적용했었습니다.

4. AWS 배포

  • 무료 도메인을 이용해 https 를 적용하기 위해 하루종일 구글과 함께 하였는데, 서버 배포시 도메인 이름으로 진행해야 한다는 점, http로 통신하는 걸 https로 변환하고 캐싱 기능을 지원했던 cloudfront 등 페어와 많은 고생을 한 만큼 보람찼고 aws를 조금 더 이해할수 있었던 시간이였습니다.

Arduous event

  1. 좋아요 싫어요 api

    • 단순히 "숫자만 넣어주면 되겠지!" 라고 생각한 나를 때려주고싶었다..
      유저가 좋아요/싫어요를 눌렀다면 중복으로 들어가면 안되기 때문에 유저 정보도 필요했고, 한가지만 선택할수 있기에 유저가 좋아요를 눌렀다가 싫어요를 눌렀다면 데이터가 업데이트 되어야 했다 또한 유저가 좋아요/싫어요를 선택했다가 취소 했을때 해당 데이터를 없애줘야 했는데 새로운 스택으로 구현한다는게 어려운 문제였다. 페어분이 많이 도와주셔서 시간이 좀 걸리긴 했지만 성공적으로 해결할 수 있었다.

  2. 카카오 소셜로그인

    • OAuth 의 기본 흐름을 생각하지 못하고 서버에서 몽땅 처리하려고 했던걸 반성한다.
      클라이언트에서 인가코드를 받고 서버에서 토큰을 받아 데이터를 요청하는 흐름을 기억하고 있었다면 삽질하는 시간이 줄었을꺼 같아서 아쉬운 시간이였다.

  3. s3 업로드 에러

    • 프론트엔드 코드를 빌드 하여 배포를 했고, ERR_ABORTED 404 / NoSuchKey 가 예쁜 빨간색으로 떴을때 페어와 나는 많은 당황과 함께 폭풍 검색을 해보았는데 해결이 안되었다. 코드를 새로 빌드하고 프론트엔드 코드를 아무리 봐도 잘못된 부분을 찾지 못하여 엔지니어분께 도움을 요청드렸고 해답은 생각보다 간단했다!

** 님 안녕하세요 :)
코드스테이츠 교육엔지니어 ***입니다.
프로젝트 배포가 잘 안되서 걱정하셨을 것으로 보여집니다.

.env 파일 안에
PUBLIC_URL = ./src/assets/images를 따로 설정하신 이유가 있으실까요??

현재 보여지는 문제로는 .env안에 설정된 경로로 인해 build시에 경로가 잘못 지정되는 현상으로 보여집니다.
build전에 .env파일내의 PUBLIC_URL = ./src/assets/images코드를 지우고 빌드해보실 수 있으실까요??

.env가 말썽일 줄은 상상도 못했는데.. 이후 배포시 .env 파일도 살펴봐야 한다는걸 알게되었다.

  1. https 배포 에러
    • http 배포를 먼저 진행하였는데, 무료 도메인(Freenom) 을 사용하여 배포를 진행하였다. AWS Certificate Manager 에서 SSL 인증서가 필요하며 Route53에 무료 도메인을 등록시켜주었다. http는 성공적이였으나 https 연결이 너무나 힘들었다..ㅠㅠ 로드밸런서, 보안그룹 등등 시도할수 있는 방법은 모두 사용했으나 성공하지 못했고 엔지니어분께 도움을 요청드렸다.
  • 로드밸런서 502 상태코드를 받았습니다.

로드밸런서가 에러가 나는 이유는 주로 보안그룹입니다.
로드밸런서 및 EC2 인스턴스의 보안그룹을 확인해 보세요

  • s3 웹사이트 엔드포인트 로 적용할 시엔 http 만 연결 됩니다

정적 웹호스팅은 http 프로토콜만 지원합니다.
https 프로토콜을 사용하기 위해서는 프록시 혹은 AWS 클라우드 프론트를 이용해 보시는걸 추천드립니다.
인증서가 버지니아 북부리전에서 생성했다면, 도메인주소를 이용한 요청을 클라우드 프론트로 라우팅 할 수 있습니다.

s3 엔드포인트로 별칭 설정을 하면 https 연결이 안된다는 사실과 CloudFront를 이용해야 한다는것도 알게되었다.

CloudFront를 사용하는것 조차 쉽지 않았는데..
이때 알게 된 것을 간략히 소개하자면

  • 도메인 등록시 ssl 리전을 버지니아 북부로 발급받자! CloudFront와 정상적으로 연결을 하려면 꼭 버지니아 북부로 해야 한다는 것.
  • S3 버킷 이름을 도메인 이름으로 생성하자.
  • Route53에서 CloudFront 연결을 해주자.
  • CloudFront는 캐싱기능이 있다. 이걸 꼭 생각하고 있자!
    - s3에 새로 배포해야할 일이 생겼는데 NoSuchKey 에러가 뜨는 바람에 멘붕이.. 원인을 계속 찾아봤더니 이전 청크파일이 남아있었고 빌드한 파일엔 이전 청크파일이 없었다. 검색을 해보니 CloudFront는 캐싱 기본값이 24시간으로 설정되어있었고, 캐시 만료전 파일을 갱신하고 싶다면 무효화 기능을 이용해야 한다. (일정 개수 이상은 유료) CloudFront는 에지 로케이션에 파일의 캐시가 없을 때 오리진에서 파일을 새로 가져온다는 특성이 있는데, 디렉터리 경로나 파일명을 바꾸는 방식으로 빠른 적용도 가능하다.

Detail

메인페이지

마이페이지

검색 페이지

스케줄러 페이지

스케줄러 칸반보드 디테일

Look back on Project

4주 프로젝트가 끝나고 회고를 쓰는 이 시점에도 프로젝트 리팩토링과 마무리를 하는 팀원들에게 고맙다는 말을 전해주고싶다🌼

프로젝트를 진행하는 동안 성장했나? 라는 물음을 한다면, YES!!! 라고 대답할것이다. 기술적인 성장 외에 팀장을 맡으며 주도적으로 프로젝트를 컨트롤 하면서 약간의 느낀점이 있기 때문이다. 또한 부트캠프 초반에 클로저도 모른다고 페어한테 혼나고, 영알못이 공식문서 읽는다고 부담감을 견딘시간.. 그리고 울면서 테스트시험을 보던 내가 프로젝트를 무사히 끝내고 한사람의 개발자로서 사회에 나갈 준비가 되었다는게 뿌듯하다.

즐거움

우리팀을 표현하는 단어가 있다면 "찰떡궁합" 일것이다. 부족한 팀장을 뒷받침 해주고 프로젝트가 잘 마무리 된 일등공신은 각각의 팀원들 때문이라고 할 수 있다. 팀 작업을 하면서 시너지 효과가 나는것이 이런걸까 라는 생각이 들 정도로 하루하루가 너무 즐거웠고, 이후 취업을 하더라도 이런 팀 분위기를 만들어가면 좋겠다 라고 생각이 들 정도였다.

아쉬움

제일 아쉽다고 생각한건 팀장으로써 마감일에 맞춰 작업 진행사항을 체크 하고 관리를 해야 하는데 이 부분을 제대로 하지 못한 것이 아쉽다. 또한 팀원들을 보면서 내가 부족한 사람이라는 걸 많이 깨달았는데 각각의 팀원들의 장점을 보면서 어떻게 나에게 적용할 수 있을지 고민을 했던 것 같다.

profile
Park db
나를 뛰어넘자!
이전 포스트

영화 커뮤니티 서비스, 위키무비

다음 포스트

[환급 원정대] 미니 학습지 영어 언박싱

0개의 댓글