리스트에 가상화는 필요하지 않을 수도

제품을 만들기 전 또는 새로운 기능을 개발하기 전에 고민하는 것이 있다. ‘최적화라고 불리는 엔지니어링을 얼마나 해야 할까?’ 이런 작업을 많이 할수록 그만큼 시간과 노력을 쏟아야 한다.

사이드 프로젝트 또는 회사에서 일을 할 때, 빠른 배포를 통해 유저 피드백을 보고 싶은 경우가 많은데, 이런 경우엔 항상 최적화를 해야 할지 말지 고민이 된다. 원하는 기능을 다 만들고도 추가적으로 많은 시간이 필요할 뿐만 아니라 자칫 잘못하면 아키텍처를 다 갈아엎어야 하는 일도 생기기 때문이다.

올해, 회사에서 커뮤니티 서비스를 개발하고 런칭했다. 1분에 하나씩 글이 생성되고 댓글이 100개씩 달리는 활발한 커뮤니티를 생각하면 들뜰 수밖에 없었다.

이렇게 많은 유저가 쓰는데 혹시 서비스가 느리거나 버그가 많으면, 만든 개발자로서 얼마나 찝찝하고 기분이 안 좋을까…

보통 네이티브 앱 같은 경우는 개발자가 크게 신경 쓰지 않아도 자동으로 리스트를 최적화해주지만, 웹은 아직 개발자가 직접 화면에 보이는 리스트만 렌더링하는 식으로 최적화를 해줘야 한다. 그래서 이를 위한 여러 가지 오픈소스 라이브러리가 있고, 보통은 GitHub Star 수가 적당히 1k가 넘는 너도나도 쓰는 라이브러리를 가져다가 리스트 UI를 구성하곤 한다. 나는 react-virtuoso라는 리스트 가상화 라이브러리를 가져다 썼는데, 우리 팀이 원하는 기능을 다 구현하기 위해서는 라이브러리에서 제공해주는 기능을 거의 제어해야 할 정도로 손이 많이 갔고, 또 React 코드와 HTML을 거의 마개조하다시피 하여 원하는 기능을 구현해야 했다. 리스트 가상화만 아니었다면 금방 끝날 일이었을 뿐만 아니라, 아무래도 보지 않은 리스트를 렌더링하지 않으니 조금 더 부자연스러운 면이 있었다. 약 300개의 많은 리스트가 쌓인다고 가정했을 때 확실히 속도는 더 빨랐다.

서비스를 런칭하고 1~2달 후, 커뮤니티의 글은 평균 2시간마다 하나씩 생성됐고, 유저도 생각만큼 스크롤을 많이 내리지 않는다는 것을 알게 되었다. (리스트는 무한 스크롤 방식으로 한 번에 20개씩 불러왔다.) 테스트를 할 때는 300개가 넘는 아이템을 그렸었는데, 그럴 필요가 전혀 없었던 것이다. 이후 우리는 사용자가 스크롤을 생각보다 많이 하지 않는다는 것을 알고 인기 글 탭을 새로 만들고 검색 기능을 더 개발했다. 리스트 가상화를 위해 노력한 시간은 아깝게 느껴졌다.

개발자가 힘들수록 유저들은 제품을 편하고 쉽게 사용할 수 있다. 그것이 엔지니어링의 영역인지도 모르게끔 편하게 사용할 수 있는 제품을 만들고 싶다. 하지만 돈을 벌지 못하는 서비스에 엔지니어링이 무슨 의미가 있을까?

구글/네이버 같은 정말 큰 회사에 다녀보지 못해 잘 모르겠다. 하지만 내가 지금까지 다녀 본 회사에서는, 적어도 개발자의 역할은 제품을 만드는 것뿐만 아니라, 우리의 서비스가 시장에서 성공하기 위해, 나아가 회사가 살아남기 위해 고민해야 하는 직업이었다.

지금까지 7년 차 프론트엔드 개발자의 생각이다.