부스트캠프 웹·모바일 8기 그룹프로젝트 4주차 회고

점점 깊어져가는 뷰들

RIBs 아키텍처를 사용하다 보니 뷰를 각각의 리블렛으로 나누게 되었는데 이러다 보니 뷰의 깊이가 점점 깊어지는 문제가 생겼다. 깊이가 깊어지니 하위 리블렛에서 발생한 이벤트를 상위 리블렛으로 보내고 그 상위 리블렛에서 또 상위로 보내는 식으로 이벤트를 계속 타고 올려보내야 했다.

이 부분을 stream을 따로 두어서 해결할까도 고민했지만 데이터 전달이 stream을 둘 만큼 자주 일어나지는 않아서 우선은 지금처럼 타고타고 올라가는 방식으로 두는 것이 최선이라고 판단했다.

다만 이렇게 이벤트가 여러 리블렛을 거쳐서 올라가다 보니 내가 작성한 코드는 흐름을 알 수 있어도 남이 작성한 코드를 보면 이벤트가 어디서 시작해서 어디로 흘러가는지 한눈에 파악하기가 힘들었다. RIBs로 책임을 잘게 나눈 대신 전체 흐름을 읽는 비용이 늘어난 셈이라 이 트레이드오프를 어떻게 다뤄야 할지 계속 고민하게 되었다.

옳바르지 않은 유저 ?? 원인은 http였다

이번 주에는 정말 골치 아픈 버그를 만났다. 그동안 서버와의 통신이 잘 되다가 토큰 만료 로직을 추가한 뒤부터 옳바르지 않은 유저라는 에러가 발생하기 시작했다.

문제는 이 에러가 일관적이지 않다는 것이었다. 잘 동작하는 팀원도 있고 나처럼 아예 동작하지 않거나 잘 될 때도 있고 안 될 때도 있어서 도대체 왜 발생하는지 찾기가 너무 힘들었다.

전날 secret 파일에서 key값을 수정한 것이 있어서 그게 원인인 줄 알고 팀원끼리 secret을 교환해보았다. 그런데 교환하고 난 뒤에도 잘 동작하는 팀원이 있고 동작하지 않는 팀원이 있어서 도무지 원인을 찾을 수가 없었다. 팀원들이 다 모여서 서버와 클라이언트를 전부 체크해보았지만 어디서 에러가 발생하는지를 쉽게 찾지 못했다.

한참을 헤매다가 알고 보니 key값이 문제가 아니라 서버 url이 https여야 하는데 http로 되어있어서 발생하는 문제였다. 서버 url을 http에서 https로 바꿔주니 그동안 나를 괴롭히던 에러가 거짓말처럼 사라지고 아주 잘 동작했다.

에러가 이렇게 일관되지 않게 발생할 때는 gitignore한 파일들을 잘 확인해보는 것이 중요하다는 것을 이번 기회에 확실히 알게 되었다. 정작 토큰 만료 로직 자체는 멀쩡했는데 엉뚱한 곳에서 원인을 찾느라 시간을 많이 썼던 것이 아쉬우면서도 기억에 오래 남을 것 같다.