두번째 회고록(쇼핑몰 프로젝트)

들어가며

우여곡절 2차 프로젝트가 끝났다!
이번에도 어김 없이 많은 후회와 고통 속에 살았다..ㅜ
매번 욕심이 많아서 많은 것을 해보려다 보니 일을 그르치는 경우가 생긴다
이번에도 반성을 하고 다음엔 또 새로이 잘해봐야지!

사용한 기술

• javascript
• mysql
• nodejs
• expressjs
• typeorm
• dotenv
• bcrypt
• jwt
• aws ec2
• aws rds

구현한 기능 및 성과

• 데이터 베이스 설계
• 유저 기능 1(회원가입, 로그인, 로그아웃, 회원 정보 조회 / 수정)
• 유저 기능 2(ID 찾기, 비밀번호 분실 및 생성)
• 유저 기능 3(토큰 생성 / 검증, 비밀번호 암호화 / 검증)
• 유저 기능 4(닉네임 미 입력시 랜덤 닉네임 생성)
• 서버 배포(백엔드 서버 및 데이터 베이스 배포)
• 에러 핸들링 미들웨어(에러 던지기 함수, DB에러 생성기)

개선해야 될 부분이나 느낌

• 효율적인 코드 작성 및 분리
• 에러 핸들링(try / catch는 컨트롤러 단에 생성 후 나머지 단에서 에러 던지기)
• 패스파라미터와 쿼리스트링의 용도를 확실히 구별하기
• 배포가 조금 불안했었음(계속 터졌었는데, 한번 더 해보고 문제점 찾기)

데이터 베이스 설계

• 잦은 설계 변경(상품관련)
  베이스로 삼을 홈페이지는 정했지만(우리 팀의 경우 KREAM)
  거기에 쓰일 데이터를 확실히 정하지 못해서 몇번이고 엎었던 것 같다
  지금 떠오르는 것만으로도 13번 정도..(미치는 줄 알았다ㅜㅜ)
  특히 결제 방식과 관련해서 수정이 엄청나게 많았는데
  장바구니 단계에 있는 상품과 결제된 상품에 대해서
  상태를 데이터로 어떻게 잡을지에 대해서 엄청나게 고민을 많이 했다
  (결국 구매 이전과 구매 이후의 상태값을 두고 2개의 테이블로 해결!)
• 잦은 설계 변경(유저 관련)
  그리고 관리자 계정의 필요성이 생겨 테이블을 바꿀지 칼럼을 추가할지를
  엄청나게 고민을 했었다
  이부분은 특히나 직접 써봐야 알 것 같은 생각이 크게 들었는데
  결국엔 아주 작은 쁘띠 프로젝트로 경험을 해본 뒤에 결정을 내릴 수 있었다!
  (이럴때마다 해봐야 이해가 되는 바보 같은 내가 한탄스럽다ㅜ)

미들웨어와 유틸리티의 차이

• 미들웨어
  이번에 처음으로 코드 디자인 패턴에 대해서 알게되어
  레이어드 패턴 형식으로 코드를 짜게 되었는데 이 부분에서
  각 단의 중간에 개입하여 필요한 기능 및 시간을 간편하게 단축시키는 기능을
  미들웨어로 결론 짓기로 했다!(다행히 강사님께서도 맞다고 해주셨고!)
• 유틸리티
  그 외 모든 함수들은 유틸리티라는 폴더에 담기로 했다!
• 간단하게 구별해보자면
  토큰생성, 검증, 비밀번호 암호화 등은 미들웨어이고
  에러 던지는 함수, 오류 검증 함수, 닉네임 생성기 등은 유틸리티라고 생각하면 되겠다!
  (정말 정말 간단하게 있던 기능을 간단하게 하면 미들웨어, 없어도 되는 함순데 있으면 편해지는 함수들은 유틸!)

패스 파라미터 VS 쿼리스트링

• GET메서드와 관련된 body없는 메서드
  정말 어이없는 경우에 의해서 이 오류가 발견되었는데
  포스트맨에는 GET메서드로 body를 보낼 수가 있다!
  (그리고 실제로도 가능하긴 한데 그러면 안된다!)
  그래서 GET메서드로 body로 데이터를 받는 식으로 코딩을 해버려서 대거 수정을 했었다!
  여러모로 기초가 항상 중요한 것 같다!(기술 위주 강의 방식의 맹점)
• 패스파라미터와 쿼리스트링의 구별
  둘 다 URI를 통해서 데이터를 받는 다는 공통점이 있는데
  이 두 기능의 구별은 생각보다 어렵지는 않았다!
  가능하면 패스파라미터는 1~2개의 값이 필요 할때 쓰고
  3개 이상의 데이터(구별이 확실한)가 필요할 때는 쿼리스트링을 쓰는 것이 맞다!
  정말 초 간단하게는 1개까지만 패스파라미터를 쓰고 이를 초과하면 쿼리스트링!
  (그래서 한명의 회원 정보나 게시글 등은 패스파라미터 특정 회원의 특정 일자의 게시글 등은 쿼리스트링!으로 구별이 된다)

기능요구 정의서

• 보통은 클라이언트의 역할
  사실 정의서는 클라이언트가 해달라는 대로 다 해줘야 하는(?) 부분이지만
  우리 프로젝트기 때문에 우리가 기능을 정하고 거기에 맞춰서 넉넉하게 개발한 느낌이 없지 않아 있기는 하다
  (우리는 구글 독스를 이용해서 워드 문서로 남겼다! 이후에는 포스트맨에서 추출)
  하지만 이전과는 다르게 이 부분을 특히나 상세하게 썼는데
  그래서인지 프론트 개발자들에게서 받는 질문이 엄청나게 줄었다!!
  그리고 프로젝트가 끝날 즈음해서 스웨거라는 요구 정의서 라이브러리가 있다는 걸 알게 되었는데 이부분은 또 조금 더 공부해서 다음 프젝이 적용시켜봐야겠다!
• 개래겍겍?
  정의서에 쓰인 것과는 다르게 역시나
  프론트가 원하는 바에 수정되는 경우도 있었는데
  객체 안에 객체 안에 객체가 아닌
  배열 안에 객체 안에 객체로 달라는 등의 주문이었다
  무슨 소리인가 싶을 수 있지만 사실 이게 엄청나게 중요한 부분이었다
  키값으로 찾냐 인덱스로 찾냐가 프론트에겐 꽤나 어려운 부분인듯 하다
  이 부분에 대해서는 기획회의때 바로 물어봐야 할 필요성을 느꼈다
  (이 부분은 스웨거를 쓰게 된다면 금방 해결 되는 부분인 듯 하다!)

배포

• aws ec2
  돈이 별로 없는 나로서는 아주 구세주인 부분인데
  프리티어로 왠만한 소형급 프로젝트는 공짜로 배포를 할 수가 있다!
  하지만 나처럼 인스턴스를 몇번이고 밀고 세팅을 잘못하면 그때마다 스냅샷이 찍히는데 이부분만 조심한다면
  이후 배포는 돈이 없어도 가능할 것 같다!(이번엔 결제 당함ㅜㅜ)
• 데이터베이스 배포
  이 경우에는 로컬의 MySQL을 쓰다가 나중에 데이터를 옮기기로 결정했었는데
  어쩐지 백업 및 덤프가 되지 않았다..
  로컬 데이터베이스의 백업은 어렵지 않았는데 인스턴스 접속 후
  온라인 상의 데이터베이스(RDS)에서 덤프가 계속 되지 않아서
  결국 수작업으로 작업을 했다..
  이후 dbmate라는 데이터 이사 라이브러리(?)를 알게 되었는데
  다음 프로젝트에서 사용해 볼 생각
• 코드 배포
  파일을 직접 옮기거나 하는 등의 나름대로 무식하지만 쉬운 방법이 있었는데
  이것 역시나 프리티어의 성능이 낮아서 계속해서 튕기는 현상이 있었다
  그래서 git을 인스턴스에 설치 후 git clone이나 git pull을 받는 식으로
  코드를 받아서 배포하는 방식을 썼는데 이 부분도 개선을 해야 할 여지가 있다
  이번에 내가 알아낸 방법은 remote / git / docker가 있는데
  세 가지는 다 경험해본 후 이후에는 docker로 쓸 생각을 하고 있다
• aws가 유일한 방법은 아니다
  aws가 제일 대중적이긴 하지만 구글의 서비스도 있고 헤로쿠?라는 것도 있기 때문에 무작정 aws만 쫓을 필요는 없다고 한다 이부분에 대해서도 알아본 뒤에 포스팅을 해봐야 겠다
• 이미지 및 동영상 관련된 파일 배포
  근데 이부분은 aws s3를 이용한 방법이 제일 낫다고 한다
  무료 호스팅 사이트를 찾아 이미지를 일일히 주소화 한 후 그 주소만 데이터베이스에 저장하는 방식을 떠올렸는데 역시나 직접 저장이 낫다고 하니 이 부분도 조금 더 알아봐야겠다

효율적인 코드 관리

• 다행이 이번에는 이전보다 훨씬 더 짧고 간결하게 쓰기 시작해서
  엄청나게 짧은 코드로 가독성도 높일수가 있었는데
  여전히 내 성에는 차지 않고 있다 그래서 주변에 물어보다가 얻어낸 방법이
  바로 GPT에게 물어보는 방법이다!
  답만 그때 그때 쏙쏙 꺼내주는 방법 같아서 나는 아직은 구글링이나 스택오버플로우를 찾아보는 편인데 코드를 줄이는 방법은 오히려 이 방법이 더 나은 것 같다!
  방법은 간단하다!
  내 방식으로 작성한 코드를 GPT에게 주고 코드를 줄일 수 있는 방법은 없는지
  있으면 주석과 같이 상세한 설명을 달아달라고 하면
  왜 줄였는지 어떤 함수로 바뀌었는지 설명을 잘해준다!
  이렇게 하면 답은 금방 나와도 배우고 넘어갈 수 있으니 괜찮은 방법 같다!

마무리

매일을 자괴감 속에 살았지만
(이 것도 모르는 나 같은 놈이 개발자가 될 수 있을까?)
덕분에 매일 매일 성장하는 느낌이 들어서 아주 뿌듯하기도 한 프로젝트였다
후회도 많이 남아서 빨리 다음 프로젝트가 기다려지기도 한다
(나쁜 의미가 아닌 좋은 의미로서? 빨리 이번에 배운걸 다시 쓰고 싶다)
이번에는 시연을 위한 배포 정도로만 그쳤는데
다음엔 정말 실제 유저를 모을만한 아이템이 되게끔 배포에 힘을 써봐야겠다!