개요

드디어 오늘 First Project가 끝났다 2주라는 기간이 어쩌면 길고 어쩌면 짧은 기간속에 힘들고 포기하고 싶은적도 있었고 개발이 진행이 잘되어 기분이 날라갈 것 같을 때도 있었다 이런 짧은 시간동안 여러가지 감정을 느끼게 된 것은 오래간만이라는 생각이 들었고 내가 이 일을 재밌어 한다는 것을 몸소 느끼기도 했다 계속 방에서 기능 구현에 목메달고 있었지만 그 과정이 마냥 힘들지 않아고 구현된는 것을 보면 뿌듯함을 느꼈고 팀원들과 커뮤니케이션이 잘되어서 결과물이 잘나왔을 때 역시 매우 뿌듯하였다 지금 2주짜리 프로젝트를 마치고 드는 생각은 4주 프로젝트를 빨리 하고싶다는 것이다 또 어떤 아이디어를 구현하게 될지 기대가 된다.

리액트

이번 프로젝트에서 리액틀를 잡게된 순간은 내가 백엔드의 작업을 얼추 마무리하고 소셜 로그인의 기능을 프론트에 추가하기 위해서 작업을 시작하게 되었다 처음 프론트엔드 분들의 코드를 보고 구조를 파악하는데 그렇게 어렵지는 않았다 이번 프로젝트 자체가 창을 많이 만들지 않고 지도의 구현의 집중하는 것이기 때문이었다. 살짝 헷갈렸던게 프론트엔드분들도 이번 프로젝트가 처음이었기 때문에 어떤 것은 함수형 컴포넌트고 어떤 것은 클래스형 컴포넌트였다 이런 구조를 효율성을 생각해서 놔눠놨을 수 도 있지만 처음 보면서 적응하기에 오래 걸렸다 함수형 컴포넌트로 모두 리팩토링하거나 클래스 컴포넌트로 모두 리팩토링하는 것도 첼린지 하다고 생각했지만 선뜻 제안하지 못했다 당시 프론트엔드 진행하는 분들의 작업량 또한 부담이라 생각했기 때문이다 그리고 리액트의 구조를 보면서 프론트엔드 역시 디렉토리의 구조화 코드의 모듈화 작업을 제대로 신경쓰지못하면 리펙토링과 유지보수에 힘들다는 것을 느끼게 되었다

상태 관리의 중요성

프론트엔드에서 작업을 같이하다 보니 현재 유저의 상태와 해당 상태를 화면에 뿌려줘야하는 경우가 종종 있었다 어떤 버튼을 눌렀는지 기억하거나 로그인상태를 기억하거나 등등 이런 상태관리를 하기위해 이용하는 라이브러리인 리덕스의 필요성을 절실하게 느끼게 되었다 리덕스를 사용하지 않으니 헨들러가 이 컴포넌트 저 컴포넌트의 모두 쓰이면서 어떤 컴포넌트에 어떤 리스너를 받고 있는지 조차 헷갈릴 때가 많았다 이런 문제를 느낀건 구글로그인의 구현과 리뷰창,필터링 검색 기능을 구현했을 때 크게 느끼게 되었다 구글로 로그인했는지,필터링 검색에서 어떤 버튼을 눌렀는지를 기억하기 위해서 리스너가 흘러내리는 모습을 보게 되었다 이런 모습을 보고 리덕스나 어떤것이는 상태관리의 필요성을 느끼게 되었다

구글 인증

백엔드에서 소셜로그인의 기능을 전담받고 이를 구현하기 위해서 여러가지 방법을 찾아보다가 passport 라이브러리를 이용하는 방법과 좀 더 세부적인 구현이 필요한 OAuth를 이용한 방법이있었다 어떤 것을 선택할지 코드스테이츠 엔지니어에게 물어보니 현재 내가 구현하고자 하는 시스템의 구조의 특징상 프론트엔드와 백엔드가 분리된 작업을 하게 되는데 passport의 경우 작동하는 방식이 프론트엔드에 종속적인 부분이라 구현이 되도 이상적이라 하지 않다고 의견을 말해줬다 그래서 OAuth를 이용해서 기능을 구현하기로 하고 OAuth의 작동방식을 공부하였다 이 인증 절차는 3자간의 인증 절차로써 서버에서 원하는 정보를 구글에게 요청하고 구글은 사용자에게 이를 사용해도된다는 승인을 얻으면 토큰을 발행해준다 이제 이 토큰을 이용해서 서버에서 사용하는 구조였다 이러한 구조를 공부하고 구현하고자 할 때 조금 애를 먹긴했지만 내가 필요한 정보는 단순히 로그인 정보기 때문에 프론트에서 토큰을 받아 다행이 잘 전달해 줄 수 있었다.

백엔드의 효율성과 유지성

백엔드가 기본적인 기능을 구현하고 나서 프론트엔드로 넘어와서 작업을 할 때 백엔드에서 서버가 계속 응답을 제대로 보내지 못하는 문제를 몇번 보게 되었다 프론트엔드에서 작업이 많아서 이를 바로바로 수정하지 못하였는데 대표적인 문제로 예외처리를 제대로 하지 못해 일어난 것이었다 api문서에 작성한대로 상황이 일어나면 베스트지만 프론트엔드에서 보내는 요청에는 예상하지 못하는 경우가 있기 때문에 이를 대비하기 위해 서버는 예외처리를 해서 알 수 없는 사용자의 요청에 대해서 대비를 해야한다 프론트엔드에 작업이 얼추 마무리 되고 백엔드를 리팩토링하러 갔을 때 우선 사용자가 보내온 결과가 존재하는지 확인하는 부분을 추가하였다 사용자가 보내온 요청이 먼저 내가 원하는 요청이 맞는 지 확인하는 것이 예외처리의 첫번째라 생각했기 때문이다 그렇게 예외처리를 하고 try catch로 예외처리를 하지 않은 것을 예외처리 해주었다.

HTTP의 좌표 문제

이번 프로젝트가 사용자의 위치를 받아와서 지역화폐의 가맹점을 찾아주는 것이 주된 기능이었는데 중간에 프론트엔드를 s3에 배포해보는 과정을 제대로 해보지 못해서 프로젝트 발표 전날에 사용자 좌표를 받아오려면 HTTPS로 구성을 해야한다는 것을 알게되었다 이렇게 된것을 인지 하고 급하게 HTTPS를 구성하기 위해 AWS Cloudfront, AWS Route53, AWS certificate manager 를 이용해서 ssl인증서을 받고 HTTPS를 구성하면 되는 거였지만 내가 처음에 도메인을 사야되는 것을 모르고 ssl신청을 해놓고 인증이 될 때까지 기다렸던 불상사가 일어나서 계속 인증을 하지 못해서 결국 배포과정을 해결하지 못한채 발표를 하게되었다 이 사건을 통해서 어떤 서비스의 필요한 기능이 배포과정에서도 잘 이루어 질 수 있는지는 프로젝트 초기에 해결해놓고 가는 것이 좋겠다는 결론이 들었다.