이번 2탄에서는 윈터레스트 프로젝트 상에서 masonry에서 발견한 버그에 대해 논의해 보고, 원인분석, 해결 방안 순으로 글을 적어보겠다.
1. 우연히 발견한 그 이름 b.u.g.
사실 리팩토링 기간이 많은 것을 의미한다고 볼 수 있지만, 필자는 다시 한 번 우리가 짠 코드에 틈이 없나 살펴보는 시간이라고도 생각한다.
사실 이 masonry는 거의 완벽에 가깝게 구현했다고 나름 좋아했었다. 하지만, 내게 보이지 않았던 버그를 누군가는 본다. 무한스크롤 디버깅을 하던 중, 내 모니터를 보던 동기 영욱님께서 이렇게 물었다.
어? 이거 그런데 왜 뭔가 위에가 고정이 안 되고 계속 움직이죠?
그 말이 처음에는 이해가 안 갔다. 이게 뭔 소리인가 싶어 다시 봤다. 문제는 다음과 같았다.
자~ 눈치 빠른 분들은 벌써 아셨을 것이다. 그렇다. 지금 아이유 이미지를 기준으로 설명하겠다. 위의 파란 배경의 아이유 이미지가 원래는 최상단이었는데, 스크롤을 내려 데이터를 불러오니 위치가 아래로 내려갔다.
반면, 밑에 있던 안경 낀 아이유 사진은 위로 올라가서 최상단에 위치한다.
이렇게 필자는 masonry의 위치 변경이 이 레이 아웃의 원래 구조적 특징인지 다시 알아볼 필요가 있었다.
2. 원인파악.
1) stack over flow.
역시 믿고 보는 스택오버 플로우였다. 필자와 비슷한 문제를 겪은 개발자가 분명히 존재했다. 그가 남긴 글을 읽고, 다른 여러 해외 개발자들이 남긴 답글을 읽으면서 문제가 점점 명확해 지기 시작했다.
그 중에 대표적으로 가장 많은 공감과 더불어 이해가 잘 되었던 답변을 공유한다.
답변자의 말을 대략적으로 요약하자면, 이는 칼럼 카운트의 특성상 어쩔 수가 없는 부분이었다. 혹여 할 수 있다고 해도 비효율적이라는 의견이 지배적이었다. 따라서 만약 당신의 아이템이 배치되는 것이 수직적이 아니라 수평적으로 원한다면, 아이템 전체를 감싸는 컨테이너의 높이가 픽스 값을 가져야만 한다고 했다. 하지만, 이 역시도 위의 결과 처럼 아이템 간의 갭이 존재한다고 했다.
따라서 필자는 여기서 직감했다. 다른 사이트 들이 그리드로 한 이유가 분명히 있었구나.... 이게 내가 기술의 특성을 제대로 알지 못한 채로 썼구나...
이런 반성을 다시 하게 되면서, 그렇다면 어떻게 해야 좋을 지에 대한 고민이 시작되었다.
3. 해결 방안에 대한 고민.
1) 해외 매거진.
구글링을 하다보니, 결국 마주하게 된 하나의 기사가 내 눈길을 끌었다. 사실 이분도 소개를 보면 알겠지만, 굉장히 권위가 있는 프론트 개발자 이신 것 같았다. 특히 내용이 너무 좋았다. 앞선 스택 오버 플로우는 다양한 의견들이 난무해서 좀 정리가 어려웠다면, 이글을 보면서 필자가 앞으로 이런 masonry layout에 대한 고민과 방향성에 대해 한 번 되짚을 수 있는 좋은 자료였다.
혹시 시간 되시는 분은 아래 주소를 참조해 보시는 것도 좋겠다.
https://www.smashingmagazine.com/native-css-masonry-layout-css-grid/
1. 간략한 요약.
이 부분은 필자의 이해를 바탕으로 한 해당 기사의 요약본이다.
1) Can’t We Already Do This In CSS?
이분도 지적하시기를 필자와 같이 다중 칼럼을 적용하는 방식이 masonry layout에 시각적으로 접근하기에 가장 편한 방법이라고 하셨다. 하지만, 이 기술의 단점은 상술한 바와 같이, 배치가 수직으로만 된다는 단점이 있다. 그래서 결론적으로 여전히 자바스크립트를 이용한 방식을 추천한다고 하셨다. 결국 grid 방식인 것이다.
2)but, it isn't ideal.
하지만, 그녀는 다시 이런 말을 던졌다.
Therefore, in order to achieve masonry, it still requires JavaScript. Doing layout with JavaScript — in particular with the large number of items that often benefit from this type of layout — is never going to perform well. I initially noted that web developers were asking for the feature back in January 2017, and while I have some concerns as to whether this really is a grid thing (and also the potential for accessibility problems due to content reordering), I am glad it is moving forward.
요약하자면, 자바스크립트를 현재 쓰고는 있으나 이것 역시 완전히 이상적인 방법은 아니다. 특히 다수의 아이템을 가지고 있는 경우에는 퍼포먼스 적으로 좋지 못 하다.
3) New feature. but....
그래서 이런 기술적 보완을 위해 현재 파이어 폭스 브라우저에는 아예 masonry 기능을 지원하기 시작했다고 한다. 즉, 이제 우리가 그동안 자바스크립트 파일을 또 만들어서 제어하던 것을 아예 기능화 시켜서 개발자가 편하게 쓸 수 있도록 한 것이다. 하지만, 아직 베타 테스트 정도라서... 크롬이나 엣지 등의 브라우저에는 적용이 안 된 상태다. 따라서 이후에는 안정화가 된다면 우리는 이제 아마도 css 상에서도 완벽한 masonry를 좀 더 손 쉽게 구현할 수 있을 것이다.
4. 해결방안.
그래서 필자는 이런 결과물을 토대로, 이제 어떻게 버그를 해결할 것인가에 대해 다시 생각했다.
당연히 기존 multi 칼럼 방식으로는 안되겠기에... 변경은 필연적이었다. 구글링을 하던 중, 결국 그리드 방식을 해야겠다고 생각했다.
하지만, 바로 해당 방식을 적용하기에는 아직 필자의 역량이 부족하다는 생각을 가지게 되었다.
1) 처음 마주한 라이브러리.
그래서 구글링을 하던 중, 해당 글을 우연히 발견했다.
사실 필자는 라이브러리에 대해서 굉장히 좀 기피하는 타입이었다. 하지만, 이번에 처음 써 보면서 그것도 편견이라는 생각이 들었다.
2) 다시 보게 된 라이브러리.
프론트엔드는 특히 수많은 라이브러리가 하루도 멀다하게 생겨난다. 물론 라이브러리에만 전적으로 의존하는 것은 좋지 않다. 하지만, 필자가 생각하기에는 어떤 라이브러리의 기능을 이용해서 시간을 단축하고 잘만 활용한다면 좋은 자료라고 생각이 들었다. 다만, 그 활용에 있어서 개발자의 역량이 들어간다고 생각한다.
일단, 라이브러리는 특정 개인들이 만드는 경우도 많기에, 충분히 검증되고 잘 알려진 것이 좋다. 왜냐하면, 수많은 사용자를 통해 입증된 것이라면 안정성 측면에서는 문제가 없을 것이기때문이다.
하지만, 그것도 100% 정답은 아니다. 분명 자신의 프로젝트 환경이나 세부 설정에 따라서 적용이 안 될 수도 있다. 따라서 개발자 스스로 라이브러리를 선택하고 활용하는 데에 있어 안목과 기준이 필요하다.
3) 라이브러리를 무작정 다운 받아서 쓴다고 되는 것이 아니다.
앞선 내용의 연장인데, 결국 설치하고 나서 어떻게 활용해서 내 프로젝트에 잘 적용시킬 수 있는 것인지가 중요하다. 그래서 필자 역시 이번 프로젝트에서 이 react- masonry- css 라이브러리를 한 번 적용해 봤다.
주간 다운 횟수가 7만이 넘을 만큼. 알고보니 굉장히 상용화가 된 라이브러리였다.
4) 적용방법
사실 이부분을 이해하는 것도 그렇게 크게 어렵지는 않았다. 왜냐면, npm 자체에 이미 개발자가 문서로서 사용 메뉴얼을 잘 알려주고 있기 때문이다.
설치부터 리액트에서 어떻게 적용하는 것이며, 심지어 반응형까지 고려할 때 어떻게 변수 설정을 해 주는 것인지까지... 매우 잘 이해하고 적용할 수 있었다.
5) 코드에 적용해 보자.
바로 우리 사이트 코드에 적용해 봤다. 사용 메뉴얼대로 다음과 같이 적용시켜줬다.
1) 임포트 및 반응형 변수 list 파일에 적용.
2) 리턴 값 안에 Masonry 컴포넌트로 카드 컴포넌트 감싸기.
3) masonry css 추가.
이렇게 3가지를 적용해 주면, 이제 끝이 난다. 다만, 여기서 필자가 손을 댄 부분은 반응형 변수를 세부 조정해 줬고, 이후 마진 값이 좀 잘 안 맞아서 전체 카드 리스트의 마진을 조절했다. 이렇게 하니 생각보다 간단하게 라이브러리가 적용되었다. 그렇다면, 이 라이브러리는 과연 필자의 의도대로 잘적용 되었을까?
5. 결과물.
다음과 같이 이제는 최상단의 이미지들이 그대로 고정되어 있고, 밑으로만 카드들이 추가되는 것을 바로 확인하실 수 있다.
6. 느낀점 및 소감.
이번 디버깅을 통해. 사실 많은 것을 또 배울 수 있었다.
- 각 기술마다 전부 장단점이 있고, 이를 알고 써야만 올바르게 의도한 대로 개발을 진행할 수 있다.
- 라이브러리 역시 이와 마찬가지로 개발자가 적절히 잘 활용만 한다면, 무엇보다 굉장히 유용한 개발도구가 될 수 있다. 따라서 라이브러리를 많이 알아두고 사용할 때와 시점에 맞게 적절히 사용할 수 있는 개발자가 되야겠다.
- 영문 구글링을 통해 학습을 하는 것이 얼마나 중요한 지에 대해 다시 한 번 체감해 볼 수 있었다. 앞으로는 공식문서 이후에 영문 검색을 적극 활용해서 질적인 자료들을 읽고 공부해 봐야겠다.
- 이후에 masonry의 js 방식도 더 공부해서 보다 다양한 방식에서 적용할 수 있는 방법들을 구현해보고 익혀야겠다.
개발 당시에는 보지 못한 이런 점들을 다시 한 번 코드를 보면서 익힐 수 있는 좋은 시간이었다.
