본문으로 건너뛰기

버그 해결 회고::명확한 근거와 코드의 흐름

· 약 9분

커뮤니티 기능을 개발하는 첫 프로젝트에서 댓글 수가 제대로 표기되지 않는 버그가 발생했다. 간단한 동기 비동기 문제였지만, 문제를 해결하면서 배운 점이 많아 남기는 회고

문제점​

API 호출과 결과는 제대로 받아왔으나, DQ에 있는 모든 상태값이 렌더링이 되지 않은 상황. storage에 token값이 존재하지 않을 때 auth.api.ts에서 token을 불러오기 때문에 상황으로, 2가지 문제점이 존재한다.

먼저, initInvokeInterface()와 isLoading을 끝내는 getInitialData()가 비동기적으로 실행되어 initInvokeInterface()으로 토큰을 받아오기 전. getInitialData()가 먼저 실행되어 loading이 끝난 후 토큰을 불러오게 되는 것이다.

두번째 문제점은 getItem("token") === "undefined"일 때 에러를 반환하는 것이 동작하지 않는 것인데, getMyInfo()는 API가 아님에도 auth.api.ts 파일에 존재하여 혼란을 야기하고, 불필요한 API 에러처리를 받고 있는 것이다.

수정사항​

getInitialData() 내부에 initInvokeInterface()을 넣고, 동기적으로 동작하게 하여 initInvokeInterface()이 끝나야만 setIsLoading(false);가 실행되도록 수정하였다.

또, getMyInfo()를 auth.api.ts가 아닌 utils 폴더의 getAuthData.ts로 분류하여 api와 혼동되지 않게 수정하였다.

버그 해결 일지​

  • 댓글 수가 제대로 표기되지 않는 버그 수정 0으로 표시되며, 댓글 작성 혹은 삭제 시 +1, -1 적용되는 중.댓글이 안보이던 버그가 이곳에서 나타나는 것으로 추정..Recoil 값으로 나타내는 것인데, setCommentsNumberInfo이 적용되지 않아 생기는 문제로 추정.
    • useEffect시 setCommentsNumberInfo이 되지 않는 것으로 추정
    • useEffect
      1. CommentsNumberInfo에 주어지는 값을 useState로 설정하고, useEffect를 사용하여 state가 바뀔 때 CommentsNumberInfo를 바꾸도록 변경하였다.=> 해결되지 않음
      2. 댓글 API 사용을 최소화하기 위해 CommentsContainer에서 사용한 댓글 API를 recoil 전역상태값으로 저장하여 DqConetents에서 댓글api 대신 전역 상태를 사용하도록 변경하였다.=> 약 5분간 계속해서 테스트했으나 현재까지 이상없음 해결되지 않음
    • initInvokeInterface 가 수행되기 전 DqContents이 먼저 렌더링되어 생기는 문제로 추정
      1. initInvokeInterface 이후 getInitialData를 호출하도록 수정. => 20분 테스트한 결과, 댓글 수를 불러오지 못하는 에러는 발생하지 않았으나 흰화면이 나타나는 버그가 17분 쯤 발생
  • 흰 화면만 나타나는 버그 수정현재까지는 아이폰에서만 발생하고 있고, 데이터 사용시 더 자주 발생하는 오류로 추정되며, POST 정보까지는 불러오지만 댓글 갯수를 불러오는 시점에서 흰화면이 생긴다.
    • 댓글 API를 호출하다가 에러가 발생하여 생기는 문제로 추정
    • DailyQeustion에서 isLoading이 끝나지 않아
      만 보여지는 것으로 추정getInitialData 실패시 재시도하고, 3번 실패시 에러페이지 띄우도록 구현 해결되지 않음isLoading의 문제인지 확인하기 위해 로딩 이미지 임시구현 및 getInitialData에 try-catch 추가=> 여전히 해결되고있지 않으며, 로딩이미지가 보여지지 않음

회고​

위 개발일지는 문제를 해결하면서 혼자 작성했던 기록이다. “추정” → 테스트 → 해결안됨 이 반복되고 있는데, 여기서 추정은 논리적인 근거를 갖고 한 것이 아닌, 문제가 생기는 부분을 보고 이것이 문제일 것이다! 라고 추정한 것이다.

부끄럽게도 내겐 익숙한 문제해결방법이었고, 이것이 잘못된 것인지 몰랐다. 하지만 이 방법에는 맹점이 아주 많은데, 일단 짚이는 것을 문제라고 확정짓고 해결하기 때문에 왜 그런 일이 발생한지를 명확히 알지못하고, 문제를 찾을 수 있다고 확신할 수 없다. 그냥 이리저리 시도해보며 운좋게 문제가 해결되기를 바랄 뿐이다.


위의 경우에도 API를 호출할 때 문제가 발생하고, 네트워크가 느렸을 때 문제가 더 자주 발생한다는 점 때문에 계속해서 API에 문제가 있을거라 추측한다. 그러나 이는 API를 호출하는 과정에서 문제가 있었던 것을 알고 보면 아주 말도안되는 추측인 것이다.

파트장님은 계속해서 이러한 해결방법이 잘못되었다고 강조하셨으며 내가 쓴 코드에 명확한 근거가 있어야하고, 코드의 흐름을 보면서 근거를 찾아야 한다고 하였다. 때문에 브레이크포인트와 로그를 찍어보며 어디서 문제가 발생하는지, 그리고 문제가 발생한 원인과 흐름을 찾아 해결해야한다고 하였다. 눈에 보이는 문제가 나타나는 API 혹은 라이브러리보며 '이게 왜안돼?' 하며 짜증내는 것이 아니라 논리적, 그리고 객관적으로 문제가 생길 수 있는 곳을 찾아 해결해야 한다는 것이다.


누군가 좋은 디버깅이 무엇이냐 하면 말할만큼 누구나 말하는 좋은 디버깅이고 개발방법이지만, 나는 전혀 지키고 있지 않았다. 하지만 확신을 갖고 차분히 문제를 파악하고 해결해나가는 과정이 개발 실력이자 개발 철학이 아닐까 싶다. 그리고 파트장님은 이런 개발 방법을 내게 심어주기 위해 API, 리코일 탓이라고 헛짚는 나에게 계속해서 왜 이것이 문제라고 생각하는지 명확한 근거를 가지고 자신을 설득시켜보라고 했던 것이다.

그리고 문제가 해결되었을 때, 다시 한번 자신의 코드에 명확한 근거를 가지고 개발하는 것이 중요하다는 것과, 쉽게 읽을 수 있는 플로우를 가진 개발을 할 수 있도록 노력해야 한다고 하셨다. 내가 하루아침에 완벽한 흐름을 갖는 코드를 짜고 디버깅을 할수는 없겠지만 그렇게 할 수 있도록 계속해서 노력하려한다. 많은 기술을 알고 쓰는 것보다 이런 개발철학을 확고히 한 사람이 잘하는 개발자가 아닐까? 그리고 이런 개발철학을 남에게 알려줄 수 있는 사람이면 더더욱.