사실 우리사이트 정말 버그가 많이 보였다. 그래서 이번에는 총 2가지 굵직한 버그들을 리팩토링 및 디버깅하면서 마무리하려고 한다.
일단, 이번 버그는 단순히 필자의 프론트적인 부분만이 아닌, 백엔드와의 공조가 필요했.
1.카카오 로그인 후 마이페이지 정보 리로딩 실패.
1) 사건의 발단.
일단, 다음화면을 보시면 어떤 부분이 문제인 지 알아채신 분들도 있을 것이다.
간단히 설명을 드리자면, 카카오 로그인 사용자가 사이트 로그인 후, 메인 페이지에서 자신의 마이페이지로 들어갔을 때 다음처럼 사용자 정보를 받아오지 못하는 경우였다.
2) 원인 분석.
먼저, 문제의 원인에 대해 한 번 곰곰이 생각해 봤다.
1. 백엔드 서버에 찍히는 에러 코드.
백엔드 서버를 열어보니 역시나 다음과 같이 앱 크래쉬가 난 상태였다. 그렇다면, 결국 왜 크래쉬를 만드는 지를 파악하는 것이 선결 과제였다.
그래서 코드를 살펴보면서, 이 부분에 대해 백엔드 팀원 분에게 한 번 점검 요청을 드렸다. 사실 처음에는 앱 크래쉬가 나서, 당연히 백단의 문제라고 생각했다. 그러나, 백엔드에도 콘솔을 서비스, 컨트롤러 등 다양한 곳에 찍었지만, 문제는 없었다.
2. undefined?
그랬다. 역시 프론트에서 코드가 문제라는 생각이 다시 들었다. 필자의 안일한 생각이 다시 또 문제를 만든 것이다.
처음에는 네브바 메인이라는 컴포넌트에서 마이페이지로 기본적인 네비게이트만 하는 데... 뭐가 문제가 될까였다...
그런데 다음 사진을 보자.
저 창위에 패스 파라미터 안에 보이는 undefined를 보신 분들은 느끼셨을 것이다. 저 언디파인드가 결국 문제라는 것을... 원래는 저 자리가 userNumber가 들어오는 자리다.
그런데 저게 안 들어온다는 말은... 결국 저 부분을 프론트 단에서 받아오지 못 하고 있다는 의미였다.
3. 안되면 될 때까지 console.log 천국.
그래서 결국 필자는 동료들과 함께 논의하면서 의심이 가는 곳에 콘솔을 찍어보기로 했다.
우리는, 크게 두 가지를 의심해 봤다.
하나는 카카오 서버 자체에서 요청한 카카오 토큰을 백단에 제대로 전달하지 못하는 문제.
또 다른 하나는 받아는 오지만, 처리가 되는 순서의 문제.
역시 답은 콘솔에서 보여주고 있었다.
카카오에서 받은 액세스 토큰은 잘 찍혔으나, 이후에 백단으로 부터 받아온 우리 사이트의 토큰이 안 찍히는 것이 문제였다. 또한, 콘솔 창에서 결국 이건, 후자에 가까운 문제라고 확실하게 판단할 수 있었다.
하지만 이 부분의 근본적인 문제는 무엇일까에 대한 고민이 더 커졌다. 그렇게 풀지 못한 채로, 필자와 팀원들은 멘토 코드 리뷰를 받았다. 그러다 문득, 필자는 이 문제에 대해 한 번 멘토 재준님께 질문을 드렸다.
4. 실행 순서의 문제?
"이거 혹시 콘솔을 통해서 실행 순서에 대해서는 한 번 확인해 보신건가요?"
넵! 이거 이상한 게 저희가 유저 넘버가 언디파인드로 먼저 뜨고 나서, 카카오 액세스 토큰이 들어오 더군요...
그러자, 그는 우리에게 이런 답을 남겨줬다.
그렇다면, 이 문제는 아마도 실행 순서의 문제일 수 있어요. 한 번 다시 코드를 살펴볼까요~
3) 문제 해결.
1. 결국에는 역시 코드 속에 답이 있다.
그에게 카카오의 리다이렉트 uri 컴포넌트와 더불어 네브바 메인 페이지의 코드를 보여드렸다.
그러자, 그는 2가지의 방법을 제시했다.
일단, 리다이렉트 화면 상에서 then을 프로미스로 생각하고 짜신 것 같은데.... 저건 사실 프로미스 개념이 아니라고 생각하셔야 합니다. 따라서 이 부분을 바꾸시던지, 아니면, 네브바 메인에 저렇게 유즈 이펙트 상으로 따로 빼놓고 처리를 하는 것보다는 눌렀을 때 패치가 되도록 처리를 하는 것이 더 나을 것 같습니다.
그에게 답을 듣자마자, 아... 뭔가 역시 아직 유즈 이펙트를 사용하는 방법이 미숙하다는 것을 크게 깨달았다.
2. 코드를 다시 짜보자.
일단 우리 팀은 다시 코드를 수정하기로 했다. 재준님의 말씀중, 한 방법인 네브바의 유즈 이펙트를 수정해 보는 쪽으로 코드를 새롭게 짜 봤다.
다음과 같이 기존의 코드와달리, 핸들클릭 함수 안에패치를 넣었고, 그에 따라 네비게이트를 바로 data.userNumber를 받아서 처리했다.
4) 결과물.
이렇게 짜고나서 다시 한번 웹 페이지로 돌아가 테스트를 해 봤다.
일단, 토큰이 잘 들어왔고, 그 다음에는 바로 마이페이지로 들어가 봤다.
휴~ 드디어 해결했다. 정보도 잘 들어왔고, 성공적인 디버깅이 되었다.
5) 느낀 점.
이번 카카오 로그인 디버깅을 통해, 크게 2가지를 느꼈다.
- 내 코드를 무조건 의심하고 또 의심하라! 완벽해 보일지언정. 문제는 발생하기 마련이다.
- 무지성적인 유즈 이펙트의 남발은 생각보다 파장이 크다. 따라서 패치를 불러온다고 유즈 이펙트를 쓰는 것이 아니라, 유즈 이펙트가 꼭 필요한 순간에만 적절하게 쓸 줄아는 것이 실력있는 개발자다.
이를 통해 앞으로 유즈 이펙트와 같이 돔을 조작하고 관리하는 부분들에 대해 더 공부해 볼 생각이 들었다. 또, 필자 혼자만 이 문제를 풀었다면 절대 못 풀었을 것이다. 같이 함께한 팀원들 그리고 아낌없는 조언을 주신 멘토 재준님이 있었기에 가능했다. 모두 감사드린다.
2) 디테일 페이지 좋아요 클릭 후 뒤로 가기 후 풀림 이슈.
다음 두 번째 이슈는 제목 그대로다. 사실 이 부분은 필자가 지난 위얼네버댓 프로젝트 당시 구현해 본 ui및 기능이어서 크게 어렵지 않게 생각했었다. 하지만, 뭔가 이상하게 잘 되지 않았다. 다음 화면 처럼 디테일 페이지 하트가 제대로 데이터 연동이 되지 않았다.
1) 사건의 발단.
단지, 처음에는 아래와 같이 디테일 라이크 버튼을 조작만 하면된다고 생각했었다.
그래서 하트 버튼을 눌렀을 때, 좋아요 갯수의 변호와 하트의 색상 채워짐 정도만 고려해서 코드를 짰다. 그렇게 별 생각 없이, 넘겼다.
그러던 어느 날.
응? 이거 왜? 뭔가 이상해 보이지?
그랬다. 갑자기 필자의 눈에 하트가 제대로 연동되지 않는 것이 보였다. 즉, 디테일 페이지로 들어갔을 때, 자신이 좋아요를 누른 것인지 아닌지 알 수가 없었다. 이건 치명적인 오류라고 판단되었다. 왜냐면, sns 기반 사이트에서 유저는 자신이 좋아요를 눌렀는 지 직관적으로 판단할 수 없다.
그래서 그걸 알려주기 위한 장치인데. 막상 다른 페이지를 넘어갔다가 다시 해당 디테일 페이지로 돌아오면 하트가 비워있는 채로 남아있기에... 이게 본인이 누른 것인지 아닌 지 알 수 없다. 결국 필자는 이 부분을 즉각 고치기로 마음 먹었다.
2) 문제의 원인.
1) 무지성적인 실수.
필자는 다시 과거 위얼네버댓 프로젝트에 대한 코드를 살펴봤다. 당시 디테일 페이지는 다른 팀원이 담당했기에. 아이디어는 가져올 수 있었지만, 뭔가 제대로 된 동작 원리를 알지 못하고 무지성적으로 가져왔다는 생각이 들었다. 그래서 다시 한 번 살펴보니, 역시나 빠뜨린 부분이 딱 보였다.
그때는 너무 성급하게 하다보니, 못 본 부분이....
바로 이부분이다. 웬 유즈 이펙트 문제냐고 볼 수 있겠지만, 사실 저 부분이 디테일에 있어야만 했다. 결국 버튼에서 포스트 보내는 것과 별개로, 하트의 불리안을 정해 주는 데이터를 백엔드와의 통신을 통해 받아온 뒤에, 그것을 다시 버튼에 프롭스로 내려줘야 하는 구조다. 혹시 싶어 해당 부분을 주석 처리하고 코드를 돌려보니, 우리 사이트와 똑같은 문제가 발생했다. 그래서 이 문제가 확실하다고 판단했다.
다시 정리해 보자면, 디테일 페이지에서 유저가 개별 윈(카드)에 대해 하트를 눌렀는 지에 대한 정보가 버튼 내부에 담겼다. 지금은 저 위에 보이시는 유즈 이펙트 구조가 없기에, 당연히 버튼까지 유저가 좋아요를 눌렀는 지에 대한 정보가 안 들어갔던 것이다. 이것만 추가해 주면 되겠다는 판단이 섰다.
2) 또 뭔가 문제?
문제 파악 후, 이 부분에 대해 백엔드 종민님께 백단에서 보내주는 데이터 구조 수정을 요청드렸다. 왜냐하면, 현재 데이터 구조상에서는 유저가 하트를 눌렀는 지에 대한 정보가 없기때문이었다. 그래서 종민님께 말씀 드리니, 그는 내게
아... 그러면 혹시 하트 버튼의 총 갯수를 통해서 구분하면 되지 않을까요?
필자는 사실 그 부분에 대해 좀 이해가 되지 않았다. 왜냐면, 총 갯수는 유저 개개인이 누른 부분이 아니라, 총 유저의 데이터가 담긴 부분이기 때문이었다. 그렇지만, 종민님의 의견도 수용해 보고 혹시 필자가 잘못 생각한 부분일 수도 있으니, 코드를 말씀대로 총 갯수에 따라 불리안 값을 주는 삼항 연산자로 다음과 같이 짜 봤다.
하지만, 이렇게 해도 결국에는 문제는 해결되지 않았다.
3) 해결책.
1) 데이터 수정 요청.
일단, 종민님 말씀대로 해 봤지만, 되지 않는 것이 확인 되자, 그 역시 필자의 의견을 적극 수용해 주셨다. 계속 코드 수정 요청을 드려 죄송했지만, 서로 배울 수 있는 좋은 기회였다고 너그럽게 이해해 주셨다. 그리고 백엔드에서 새롭게 수정해서 필자의 기존 요청대로 하트 버튼의 불리안이 담긴 값을 보내주셨다.
2) 코드 재 수정.
필자 역시 당연히 데이터 값에 따라 코드를 재 수정했다. 이버에는 api 주소 역시 따로 해서 보내주셔서 그것 역시 수정했다. 코드는 다음과 같다.
이렇게 수정후에 다시 한 번 테스트를 해 봤다.
4) 결과물
보시는 것처럼, 이제 디테이 페이지에서 하트의 클릭 여부가 잘 반영되고 있고, 또한 데이터 연동까지 잘 되는 것을 볼 수 있다.
5) 느낀 점.
이번에는 크게 디버깅을 하면서 2가지 점을 느겼다.
- 기술을 가져다 쓴다고 해서 그 원리 동작을 제대로 이해하지 못하고 쓴다면, 역시 완벽하게 적용할 수 없다.
이번에 무지성은 역시 필패의 지름길이구나라는 생각을 다시하게 되었다. 그냥 막 가져다 쓰는 것이 아닌 온전히 내것으로 이해하고 써야만 되겠다는 다짐을 다시 한 것 같다.
- 프론트와 백엔드 간의 데이터 요청을 할 때 분명한 소통이 필요하다.
이번에 종민님과 필자처럼 어느 한 쪽이 잘못 생각하거나 실수할 수도 있는 부분은 언제나 존재한다. 그래서 이 간극은 각자의 입장이 다르기에, 필연적이다. 하지만, 그것을 타당성이 있게 맞춰 보면서 줄여나가는 것이 또 중요한 개발자 간의 소통이라는 것을 다시 새삼 느꼈다.
ps. 끝으로 이번 프로젝트에 대한 리팩토링 및 버그 체크는 끝나지 않았다. 그말인 즉슨.... 앞으로 돌발적인 버그들이 나올 수도 있다는 의미다. 물론 그에 따라 다시 버그 천국 포스팅은 열릴ㄹ 것이다. ㅎㅎ 긴 글 읽어주시느라 고생하셨고, 또 감사드린다.
