[First Project] 개발 회고록_3

First 프로젝트 개발 회고록을 2번 올렸는데 이후에 정신이 없어 차마 쓸 생각이 들지 않았다.

진짜 무슨 타임머신을 탄 것 마냥 정신을 차리고보니 2주가 순식간에 지나갔고 금요일에 발표를 하고 프로젝트가 끝났다.

이 3번째 회고록이 First Project의 마지막 회고록이다.

 

진행하면서 에러가 몇몇 있었지만 주요 에러들에 대해서 간단히 이야기 해보고 그래도 어떻게 무사히 프로젝트를 마무리 할 수 있었던 건지 팀 운영적인 측면에서의 평가를 개인적으로 해보고자 한다.

 

팀장 추첨 : 투표 x

처음 팀에 4명이 배정되고 팀장을 선정해야하는 과정에서 팀장 지원자가 없어서 모두의 합의 하에 룰렛을 돌렸다.

그러다가 당첨된 것이 나였다... 솔직히 말해서 팀장 같은 거 정말 하기 싫은 것이 솔직한 마음이었다.

팀장은 따로 회고록을 지정된 아침마다 제출해야 되는 등 추가적으로 해야되는 부분들이 많았다.

 

그리고 부담감을 심하게 가지는 스타일이라서 프로젝트를 진행하는 동안 계속해서 스트레스를 좀 많이 받고 살얼음판을 걷는 느낌이었던 것 같다.

 

 

전략적인 선택들

개인적인 의지와 상관없이 팀장이 되긴 했지만 그래도 프로젝트를 망칠 수 없으니 평소에 어떻게 프로젝트를 굴릴 지에 대해 고민을 많이 했다. 그 중에서도 조금 긍정적인 방향으로 영향을 가져왔던 선택들을 꼽아서 회고해본다.

 

1. 회의 시간 조정

기존에 코드스테이츠에서 매일 팀 회의시간으로 따로 지정된 시간이 아니라 팀 성격에 맞게 회의 시간을 조정했다. (아침 회의 폐지)

그리고 기본 1시간이 아니라 30분으로 잡았다. 생각보다 회의에 가져온 이야기가 없으면 1시간 회의는 의미가 없는 것 같아서 시간을 대폭 줄였다.

 

개인적인 생각으론 그렇게 했더니 30분이라는 제한된 시간 안에 최대한 효율적으로 회의가 진행되는 것을 느꼈다. 물론 시간을 길게 잡고서라도 진행되어야 하는 회의라면 30분 이상을 사용했지만 모든 것은 디폴트를 어떻게 잡느냐에 따라서 다르다고 생각된다.

 

2. 핵심을 무조건 우선으로

프로젝트를 들어오기 전 가장 많이 들었던 이야기로 욕심을 많이 부릴 수록 프로젝트가 망가질 확률이 높다는 것이었다. 이러한 사실을 계속해서 인지하지 않으면 나도 사람인지라 프로젝트에 다양한 기능을 넣으면 좋겠다는 생각이 많이 생겼었다. 그렇지만 퍼스트 프로젝트의 목표와 크게 맞지 않는다면 쳐내는 것이 팀장의 역할이라는 생각이 많이 들어서 정말 서비스의 핵심이 아니라면 과감하게 쳐냈다. 핵심에서 조금 더 기능을 보태는 내용이라면 어드밴스드로 분류해서 "시간이 남으면 한다"를 절대적인 전제로 잡았다.

 

그리고 핵심인 Bare를 할 때는 어드밴스드를 아무리 구현해도 Bare가 구현되지 않으면 이 서비스는 실패한 서비스라는 인식을 전제로 가져야 했다. 그래서 절대적 목표는 핵심 기능 구현이었다. 그것만 구현해도 완료되는 느낌인 것처럼 말이다. 이렇게 했더니 어쩐지 포커싱이 더 잘되고 핵심 기능 기반이 탄탄해지는 느낌을 받을 수 있었던 것 같다.

 

3. 배포 먼저 해버리기

보통 일반적인 개발 진행이라면 배포를 가장 마지막에 하기 마련이다. 하지만 2주 프로젝트는 아무리 생각해도 기간 압박이 상당했다. 그래서 개발에서 기간을 단축할 수 있는 좋은 방법이 무엇이 있을까 생각했다. 그 결과 떠오른 것이 코드 파이프라인을 활용해서 서버를 먼저 자동배포 해버리는 것이었다. REST 서버에서의 코드는 각 API 별로 기능함수를 구현하고 DB와 소통하는 ORM을 작성하는 것이 전부이다. 하지만 클라이언트는 HTML, CSS을 작성하고 API 함수 작성을 시작하게 된다. 그래서 일단 프론트에서 프로그래밍 언어 작성을 하지 않고 HTML, CSS를 먼저 작성한다면 백에서는 기본 서버 코드와 sequelize model만 작성해서 AWS의 코드 파이프라인으로 EC2에 배포 시켰다. 그리고 매번 코드 파이프라인을 통해섯 서버 API가 갱신될 때마다, 클라이언트 측에서 이를 활용해 테스팅을 했다.

 

발표 당시에 알고보니 배포를 못한 팀들이 꽤 되는 것으로 보였다. 나도 코드 파이프라인을 하면서 에러를 좀 많났는데 에러 핸들링을 하느라시간을 좀 뺏겼던 기억이 있다. 아마 코드를 다 작성하고 배포를 하던 단계에서 이러한 에러가 터지면 시간이 없어 멘탈부터 나갔을 것 같다. 결론적으로 배포를 빠르게 함으로써 클라이언트에서는 실제 배포 환경에서 서버와 통신하는 것과 동일하게 코드를 작성했고 단계별로 테스팅을 진행해 시간을 단축할 수 있었던 것 같다. 2주간 기간 중 우리팀은 1주차 금요일부터 배포를 준비하여 다음주 월요일에 서버 배포를 완료했었다.

 

 

에러 핸들링

ubuntu 18. EC2에서의 PM2 에러

MacOS나 Linux에서나 관리자 계정이 존재한다. 나는 평소에 MacOS를 사용하는데 리눅스에서는 맥에 비해서 sudo 명령어를 사용해야되는 부분이 좀 더 많은 것 같다. 그런데 우분투 EC2 인스턴스에서 PM2를 굴리던 와중에 계속해서 에러가 생기는 이슈가 있었다. 서버를 백그라운드 프로세스로 돌려야하기에 PM2에 관리자 권한을 서버 파일을 구동했다. 하지만 에러가 있었는데 처음에 PM2 이슈로 생각했지만 알고보니 npm문제였다. 

 

EC2에 처음 들어가면 인스턴스 계정 명은 ubuntu로 되어있다. 그리고 ubuntu에서 npm과 node를 설치한다. 그런데 여기서 설치된 버전이 root(관리자) 계정과 차이가 존재했다. 그래서 sudo -i를 통해서 root 계정에서도 npm, node 버전을 업데이트 해야 했다. PM2 실행마다 로그에 npm version과 관련된 에러 내용이 표기되었었다. 백그라운드 프로세스를 위해 관리자로 PM2를 실행하는데 관리자 계정의 npm과 node는 구버전이어서 제대로 적용이 안되던 것이었다.

 

이 후 직접 버전을 맞춘 다음에는 정상적으로 PM2가 작동하는 것을 확인 했었다.

 

 

환경변수 : parameter store

서버를 올리고 여러가지로 확인을 하던 와중에 DB 상태가 무언가 이상함을 깨닫게 되었다. 그래서 확인해보니 EC2에서 돌아가고 있는 서버가 RDS와 정상적으로 통신하지 않는 것을 확인했다. 이와 관련해 ORM 코드를 잘못 작성했는가 확인해봤지만 그렇진 않았다.

 

몇시간동안 알아보다가 찾은 이유는 AWS parameter store의 이름과 코드 내에서 활용하는 환경변수 이름이 상이하다는 이슈였다. 로컬에서 환경변수를 설정했던 것과 별개로 파라미터 스토어에 오기입을 해서 벌어진 일이었다.

 

환경변수는 보통 값을 확인하는 것이 직접 원본작성 파일을 보는 것 외에 확인 어렵기 때문에 이런 실수가 발생하더라도 인지하기가 어렵다. 그래서 앞으로는 환경변수를 로컬과 배포환경에서 적용될 때, 여러번 체크해야함을 깨달았다

 

 

 

구글 Oauth 에러

프로젝트 서비스 로그인에 구글 Oauth 기능을 추가하려고 했는데 구글을 한번 거쳤다가 리디렉션 되는 형태였다. 원래는 기존에 클라이언트로 메시지 바디에 토큰을 넣어서 인증을 진행했는데 이 경우에는 리디렉션이므로 바디에 토큰을 넣어서 전달하는 것이 원활하지 않았다.

 

요약하면 다음과 같은 방식으로 요청이 진행된다.

클라이언트 ⇒ 구글 ⇒ 서버 ⇒ 리디렉션(클라이언트)

 

그래서 마지막 클라이언트로 리디렉션하는 경우에 인증토큰을 쿠키에 담아서 전달하는데 이 쿠키에 문제가 좀 있었다. 서버에서 쿠키를 클라이언트에 전달해주는 것이 맞지만 쿠키가 filtered out 되는 현상이었다. 이 때, 찾아낸 문제점이 domain 설정이 클라이언트의 도메인으로 잡아줘야 쿠키가 잔류된다는 것을 파악하게 되었다. 쿠키와 관련해서는 기존에 많이 활용해본 이력이 없어서 이번 에러를 통해서 쿠키에 도메인을 설정을 거의 필수로 잡아줘야 한다는 것을 이해하게 되었따.