2022.01.26 Final Project 회고

문제점

---

1. SR단계에서 혼자 백엔드를 맡았다는 부담감에 프로젝트의 볼륨을 작게 잡았던 점

2. SR단계에서 api에서 반복되는 코드(jwt 유효성 검사)를 별로도 구현하지 못한 점.

3. AWS 배포 시 에러에 대해서 정확하게 파악하고 해결하지 못한 점.

4. 유저의 이미지를 s3에 저장하는 방법에 대해서 제대로 학습하지 못해 구현에 실패한 점.

5. DB에 유저 jwt를 담아서 유저를 검증하는 방안을 마련하지 못한 점.

6. Access 토큰만 활용하고 Refresh 토큰은 도입하지 못한 점.

7. Bcrypt의 비동기적인 방법이 권고되는 이유에 대해서 직접 검증해보지 못한 점.

8. 학습했던 TDD를 반영하지 못한 점. 

9. RESTFul한 api를 구현하지 못한 점.

10. 예외처리를 미숙하게 한 점.

느낀점 & 개선방안

---

1. 퍼스트 프로젝트를 완성하지 못해 자신감이 떨어졌었습니다. 파이널 프로젝트에서는 볼륨이 작았던 아쉬움이 있지만 배포까지 혼자 진행하면서 자신감이 생겼습니다. 기간을 정해 북담 프로젝트에 좋아요, 댓글 기능을 구현해볼 것이며, 자신감을 가지되 자만하지 않고 저의 실력에 의문과 확신을 같이 가지는 마음가짐으로 나아가겠습니다.

 

2. 코드 리뷰할 때 '쿠키에 담긴 jwt 토큰 유효성 검사 및 올바른 접근인지 판단하는 코드입니다.'라는 말을 대다수의 api에서 했는데 뒤늦게 분리하지 못해 코드가 반복된다는 것을 깨달았습니다. 코스 수료 이후, 모듈로 만들어서 반영할 수 있도록 리팩토링할 예정입니다.

 

3. AWS 배포 시 502 Bad Gateway,  배포 자동화 실패, cloudFront 쿠키 등 다양한 에러를 경험했는데 급한 마음에 기록하며 에러를 해결하지 못했고 에러가 해결되었을 때 에러 핸들링을 자세하게 작성하지 못한 아쉬움이 큽니다. 배포 뿐만 아니라 코드 구현 단계에서 나는 에러도 Before & After와 에러해결을 위해 시도했던 방법들을 기록해서 에러 핸들링을 구체적으로 작성할 수 있도록 노력하겠습니다.

 

4. s3에 이미지를 저장하고 url을 받는 코드를 구현할 때 학습과 구현이 동시에 진행되었습니다. 조급함을 가지지 않고 SR단게에서부터 학습 시간을 충분히 가지고 이해를 바탕으로 코드를 구현하지 못한 아쉬움이 있습니다. 새로운 기술 구현이 필요하다면 이해를 하고 코드를 구현할 수 있도록 충분한 학습 시간을 가지겠습니다.

 

5, 6 SR단계에서 유저가 장시간 로그인해서 북담을 이용하지는 않겠다고 판단해 Access 토큰만 기획하고 구현했습니다. 코드 구현 단계에서 프론트 엔드의 SessionStorage는 유효한데 토큰 만료 시 처리 방안에 대한 이슈가 발생했습니다. 배포 단계 직전이여서 Refresh 토큰으로 Access 토큰을 요청하는 기능을 넣기에는 프론트 엔드 팀에서 다량의 코드 수정이 필요했기에 구현을 포기했습니다. 더불어서 Refresh 토큰과 Access 토큰을 DB에 저장하고 Access 토큰이 유효하지만 Refresh 토큰이 변조되어서 Access 토큰 요청이 올 경우, 비교해서 공격에 대비할 수 있을 것이라 생각했지만 시간이 부족해 구현하지 못했습니다. 리팩토링을 통해서 해당 기능들을 구현하여 북담의 보안을 한층 더 높이겠습니다.

 

7. Bcrypt는 동기적인 방법이 CPU 집약적이며 이벤트 루프를 차단하기에 비동기적인 방법을 권고됩니다. 해당 이슈를 인지했을 때 비동기적, 동기적인 방법을 둘 다 구현했지만 북담 프로젝트에 미치는 영향을 확인하지 못했고, 코드의 간결성 때문에 동기적인 방법을 유지했습니다. 아직 CS에 대한 학습이 부족하고 직접 기능을 확인하는 방법이 미숙합니다. 코드의 시간복잡도와 효율적인지 여부를 판단할 수 있도록 지속적 학습하겠습니다.

 

8. 퍼스트 프로젝트는 기간이 짧다는 이유로, 파이널 프로젝트는 조급함으로 인해 Test 코드를 구현하지 못했습니다. 다음 프로젝트에는 TDD를 적용할 수 있도록 지속적으로 학습하겠습니다.

 

9. 파이널 프로젝트에서는 꼭 RESTFul한 api를 구현하겠다고 다짐했지만 최종 api가 RESTFul하지 못한 것 같아 아쉽습니다. response에 location이나 url 보내는 것을 SR단계에서 언급하고 반영했어야 했는데 그러질 못해습니다. res.location을 활용했다면 클라이언트 단에서 코드 구현이 더 쉬울 수 있었을 것이고, 모달이 아닌 페이지로 구현했다면 url도 활용할 수 있었을텐데 안일하게 생각했습니다. 리팩토링을 통해서 RESTFul한 api를 구현해보겠습니다.

 

10. api 상에서 try & catch나 then & catch 를 적절하게 사용하지 못했습니다. 빠르게 코드를 구현하고 안정화를 해야 배포까지 할 수 있다고 성급하게 코드를 구현했던 거 같습니다. 리팩토링을 통해서 적절한 예외처리를 구현해보겠습니다.

---

이번 파이널 프로젝트에서는 코드 실행 환경과 보안, 데이터 가공에 대한 고민을 많이 했습니다.

 

내가 작성한 코드가 효율적일까?

보안은 이정도면 괜찮을까?

백엔드에서 DB정보를 넘겨줄 때 해당하는 데이터가 없다면 true, false 여부를 임의로 추가해서 넘겨줘도 괜찮을까?

 

사실 구글링을 할 때 어떻게 검색을 해야될지도 잘 모르겠고, 어떤 곳에서 정보를 찾을 수 있을지도 아직도 잘 모르겠습니다. 섹션 3를 통과하면서 구글링 하는 법과 CS에 대해서 많이 배웠다고 생각했는데 프로젝트를 하면서 부족함을 많이 느꼈습니다.

 

수료 이후 지속적으로 고민하고 학습해 스스로의 의문을 해소하는 것을 가장 큰 목표로 뒀습니다. 의문을 해소하고 저만의 방법을 찾는다면 블로그에 꼭 추가하겠습니다.