1월부터 4월까지 한 시즌에 걸쳐 트레바리 홈페이지를 다시 구현하였다. 겉으로 보이는 UI/UX 디자인 개편을 넘어, DB 설계와 서버 및 웹 페이지 개발까지 새롭게 진행했다. 기존의 홈페이지를 완전히 버리고, 새로운 아키텍처를 가진 홈페이지를 구현하여 데이터를 이전하는 일이었다.

지난 시즌 동안 홈페이지의 여러 기능들을 개선하면서 변화가 필요하다고 생각했다. 단순히 '남이 짜둔 코드가 별로예요'에서 나온 불편 때문만은 아니었다. 회사가 겪는 빠른 성장에 발맞춰 시스템이 뒷받침이 되어줘야 하는데 기존의 아키텍처로는 그러기가 어려웠다. 적은 트래픽에도 툭하면 죽는 서버 덕에 접속이 몰리는 멤버십 신청 기간 동안에는 서버 비용을 배로 늘려야 했고, 푸시 알림의 필요성으로 모바일 앱을 구현하고 싶어도 별도의 API 서버가 존재하지 않아서 시도하기 힘들었다. 결국 지난 시즌 말, 홈페이지를 새로운 아키텍처에서 다시 구현하겠다는 호기로운 결정을 내렸다.

처음 시작할 때만 해도 아주 큰 어려움은 없겠거니 했다. 트레바리 입사 이전에 여러 프로젝트를 턴키로 수주받아 진행했던 경험이 있었기 때문이었다. 그러나 몇천 명, 많게는 몇만 명이 접속하는 운영 중인 서비스를 만들어 이전하는 일은 새 서비스를 만드는 일과는 또 다른 일이었다.

게다가 이전 글에서 이야기했던 것처럼 트레바리에는 풀타임으로 일하는 개발자나 디자이너가 나 혼자이기 때문에 해야 하는 일이 절대적으로 많았다. 개발 맨 아랫단부터 웹 페이지의 디자인까지 기간 내에 해내는 것은 쉽지 않은 일이었다. 덕분에 매일이 도전이었던 4개월을 보냈고, 런칭 3주 전쯤에는 잠시 슬럼프를 겪기도 했다. 하지만 트레바리가 한 번은 꼭 겪어야 하는 과제였기에 꾸역꾸역 해내면서 런칭까지 왔다. 오늘은 그 이야기를 정리해보려고 한다.

리라이팅: 왜, 무엇을 했나요?

1. 과도한 서버 비용과 느린 속도

홈페이지를 다시 만들어야겠다는 생각을 가장 많이 하게 된 이유는 비용과 속도였다. 동시 접속 유저 수가 천 명이 안 되는 서비스에서 월 100만 원가량의 서버 비용이 나왔고, 평균 페이지 로딩 속도가 3초를 넘어갔다.

그동안 트레바리 홈페이지는 여러 프리랜서 개발자들이 거쳐가며 유지되느라 DB나 쿼리 구조에 대한 고민을 장기적으로 해볼 기회가 없었다. 요청받은 기능을 구현하기 위해 필요한 테이블을 그때그때 만들고, 활용할 데이터가 다른 테이블에 있다면 조인을 해서 불러왔다. 그 결과 대부분의 데이터 요청에 n+1 쿼리가 존재했고, 한 명의 유저가 한 번의 접속만으로도 수많은 쿼리 요청을 하는 상황이었다.

최대한 기존의 홈페이지에서 이를 해결해보려고 노력했다. 처음 입사했을 때만 해도 10초 이상의 시간이 들었던 독서모임의 리스트 요청을 3초까지 줄이고, 접속자 수가 40%가 늘어났어도 서버 비용을 늘리지 않을 수 있었다. 그러나 상대적으로 빨라졌을 뿐 느린 편이라는 점은 변함이 없었다. 매 시즌 멤버 수가 30~40% 씩 증가하는 추세대로라면 다음 시즌에도 비슷한 비용을 유지할 수 있을 거란 보장 또한 없었다.

여기서 더 개선하려면 DB 구조를 변경하고, 수많은 코드를 갈아엎어야 했다. 필요하다면 하면 되는 일이었지만 기존의 아키텍처인 레일즈 웹 애플리케이션을 유지한다면 당장의 퍼포먼스를 개선하더라도 언제까지 높은 퍼포먼스를 유지할 수 있을지 의문이었다. 성장에 따라 요구되는 시스템들을 다 지원해줄 수 있을지도 미지수였다. 언젠가 아키텍처를 변경해야 한다면 최대한 빠른 시일인 지금 하는 것이 효율적이라 판단했다.

Heroku에서 관리하던 서버를 AWS의 EC2로 변경하면서 DB 또한 PostgresSQL에서 AWS의 DynamoDB로 이전했다. RubyOnRails를 사용하여 단일 웹 애플리케이션으로 구현 했던 홈페이지를 Typescript를 기반으로 프론트엔드와 백엔드를 나눴다. React로 사용하여 웹사이트를 구현하였고, Node.js로 GraphQL을 적용하여 서버를 구현하였다.

덕분에 월 100만 원가량이 들던 비용을 월 30만 원까지 낮출 수 있었다. 속도는 이전보다는 빨라졌으나 기대만큼 빨라지지는 않아 캐싱 등을 적용하여 차츰 줄여나가고 있다. 변경한 현재 아키텍처로는 트래픽이 늘어나더라도 이전처럼 비용을 배로 늘리지 않아도 되었으며, 다양한 방법으로 속도를 개선하는 작업도 시도해 볼 수 있게 되었다.

2. 기술 부채

앞서 말했던 것처럼 기존 홈페이지는 여러 프리랜서 개발자들이 거쳐간 터라 뻔하게도 기술 부채가 쌓였다. 홈페이지와 관련된 문서는 없고, 크루들은 사용하는 기능들을 부분적으로만 알고 있었다. 그런 상황에서 몇 명의 크루들이 퇴사와 입사를 거치니 그나마 구전으로라도 유지되던 홈페이지 정보가 점점 사라졌다.

홈페이지에 대해 궁금한 점이 생기면 직접 코드를 뒤적이며 파악해보는 수밖에 없었다. 그래서 모든 크루들이 유일한 개발자인 나에게 물어보는 것 말고는 홈페이지에 대해 알 수 있는 다른 방도가 없었다. 이 외에도 새로운 기능을 구현했더니 미처 파악하지 못한 곳에서 버그가 터진다거나, 안 쓰는 줄 알고 삭제한 코드가 사실 어디선가 제기능을 하고 있거나 하는 때도 잦았다.

이런 기술 부채를 청산하려면 1) 대부분의 기능들을 파악하고 있는 담당자가 있고 2) 지원하는 기능들을 잘 정리한 문서가 필요했다. 1번은 직접 처음부터 리라이팅을 진행했으니 자연스레 해결되었으나, 다른 크루들도 많은 기능들에 대해 파악하고 있으면 더 효율적일 거라 생각했다. 그래서 새로 구현되는 기능이나 변경 사항에 대해서 매주 주간 회의 때 공유를 하고 있으며, 배포를 할 때마다 실시간으로 에버노트와 슬랙의 배포 노트 채널을 통해 배포 내용을 공유하고 있다. 이전에도 하고 있었으나 더 잘, 자주, 자세히 해야겠다고 새삼 깨달았고 노력 중에 있다.

2번을 위해서는 홈페이지 기능 설명에 대한 문서를 작성하기 시작했다. 아직 가장 효율적인 포맷이 무엇인지는 찾지 못해서 방황하고 있지만 최대한 쉽고 자세하게 쓰는 방향으로 진행 중이다.

3. 복잡하고 이유 없는 UI

기존의 홈페이지는 의외로(?) 다양한 기능들이 있었지만 유저들이 모르거나 사용하지 않는 경우가 많았다. 대부분의 기능들과 인터페이스들이 중요도에 대한 고민 없이 '있으면 좋을 것 같다'는 이유로 덕지덕지 추가되었다. 게시판이나 다이어리 같은 메뉴들은 사용률이 채 5%가 안되지만 상단 메뉴에 자리 잡고 있었고, 북클럽 리스트의 페이지에는 딱 한 번만 읽으면 되는 설명글이 화면의 반을 차지하고 있었다.

멤버들이 트레바리에서 가장 활발하게 누려줬으면 좋겠다고 생각하는 활동은 독서모임과 이벤트다. 내 클럽이 아닌 다른 다양한 클럽에도 참여해보고, 살면서 해보지 못한 경험들을 이벤트를 통해 체험해봤으면 좋겠다. 그런 고민으로 상단 메뉴에는 독서모임과 이벤트, 내 활동 정보를 볼 수 있는 마이페이지만 배치하였고 FAQ나 공지사항과 같은 자잘한 것들은 하단의 footer로 내리거나 일부 기능들을 임시적으로 지원하지 않기로 했다.

직관적인 UI는 파트너 어드민에서도 절실하게 필요했다. 기존의 어드민 UI는 따로 교육이 필요할 정도로 복잡했기 때문이었다. 한 명의 파트너에게 자신이 관리하는 클럽 외의 모든 클럽 정보가 노출되었다. 클럽 정보에서도 봐야 할 정보와 보지 않아도 될 정보가 혼재되어 보이고 있었다. 파트너의 수는 점점 늘어나는데 그때마다 홈페이지까지 교육까지 따로 해야 하는 것은 리소스가 많이 드는 일이었다.

파트너가 자신의 모임을 이끌기 위해 정말 필요한 일에만 집중할 수 있도록 신경 써서 구현했다. 모임에 참석하는 멤버 리스트, 모임에서 읽을 책과 발제문 등을 등록하고 수정하는 페이지, 출석 체크를 할 수 있는 기능만으로 구성했다. 항시 봐야 하는 매뉴얼과 FAQ는 따로 메뉴로 빼두었다.

4. 데이터로 소통하는 회사

트레바리는 점점 데이터로 소통하는 회사가 되고 싶다. 어떤 유저가 어디에서 불편을 겪고, 어떤 부분을 좋아하는지 알고 싶다. 사람들이 독서모임에 만족하면 홈페이지에서 어떻게 활동하는지, 혹여 만족하지 않았다면 그때는 또 어떻게 활동하는지 궁금하다. GA와 A/B 테스트 등의 방법들을 통해 데이터를 보며 이를 파악하고 싶다.

기존 홈페이지는 전통적인 페이지 단위로 돌아가는 레일즈 웹 애플리케이션이었으므로 따로 제이쿼리 등을 사용해야지만 이를 구현할 수 있었다. 그래서 페이지 단위의 웹을 벗어나 React를 활용한 컴포넌트 단위의 웹 사이트를 구축했다. 장기적으로 계획적이고 세밀한 트래킹이 가능하도록 기반을 닦았다.

또 기존의 홈페이지에서는 유저에게 오류 제보를 받아도 이를 확인해보는 것이 어려웠다. 그래서 지금의 시스템에는 Apollo engine과 Cloud watch를 이용하여 여러 로그들을 트래킹 하기 시작했다.

리라이팅 런칭 2주 차, 아쉬웠던 점들

리라이팅 한 홈페이지를 런칭한 지 2주일이 지났다. 런칭 후에 한참을 정신없이 보내다가 이제야 조금 숨을 돌릴 수 있게 되어 이 글도 쓰기 시작했다. 런칭만 하면 마음이 편해질 거라 예상했는데 막상 다가오니 그렇지도 않았다. 더 바쁘고 정신없던 것은 물론이요, 아쉬운 점들만 눈에 밟혀서 마음이 무거웠다. 잘한 것보다 아쉬웠던 점들이 나를 더 성장하게 만들어 줄 것이라는 생각으로 스스로를 위로하여 어떤 것들이 아쉬운지도 정리해보았다.

1. 트래픽이 몰리는 피크타임에 대한 대비 미흡

배달의 민족이 식사 시간마다 트래픽이 몰리는 피크타임이 존재하듯, 트레바리도 독후감 마감 시간이라는 피크타임이 존재했다. 유저들이 모든 시간 대에 일정하게 접속하는 하는 것이 아닌 특정 시간에 몰아서 접속하는 것을 고려하여 그때의 속도를 잘 잡았어야 했다. 이를 미리 고려하여 캐시와 같은 여러 대비책들을 세워두었다면 유저들이 느린 홈페이지가 주는 불편을 덜 겪었을 거라고 생각한다.

2. 치밀하지 못한 안내

런칭 직후 오는 많은 문의들이 실제 오류가 아닌 제대로 된 안내가 없어 오류로 인지하는 경우였다. 예를 들어 기존에는 있었으나 사라진 주소와 같은 404 페이지 접근 시에는 안내 후 메인 페이지로 보내버리거나 하는 안내가 있었으면 많은 문의들을 대응하지 않아도 됐을 것이다.

3. 운영 크루 업무 이해도 낮음

리라이팅을 할 때 다른 크루들과 커뮤니케이션을 하는 일에 많은 리소스를 쏟지 않았었다. 다른 크루들의 업무에 대해 꽤 잘 이해하고 있다고 생각했기 때문이었다. 내가 생각하기에 필요할 것 같은 기능들만 어드민에 담았고, 그 결과로 크루들이 런칭 직후에 엄청난 불편과 수고로움을 겪게 만들었다.

4. 조급함

리라이팅을 진행하는 기간 동안 마음이 급해서 눈앞에 보이는 기능들을 빨리 쳐내는 것에 급급했다. 그러다 보니 각 기술에 대한 문서들을 꼼꼼하게 읽어내지 못해 놓친 부분이 많았다. 특히 한 번도 경험해본 적 없는 각종 브라우저와 브라우저 버전, PC와 모바일 대응 등에서 많이 놓쳤다. 평소 웹 표준 관련 문서를 잘 읽어두었다면 이런 실수는 덜하지 않았을까 생각했다. 또 틈틈이 작성했던 코드를 되돌아보고 개선하는 시간도 가졌어야 했는데 조급함 때문에 그러지 못했다. 이런 부분들은 개발자가 평소에 항시 주의해야 할 모습이라 생각했다.

이번 리라이팅을 시작으로 트레바리가 온라인의 경험까지 멋진 서비스가 될 수 있기를 희망한다. 아직은 부족한 점이 많지만 사람들이 독서모임에 참석하기까지 겪는 온라인에서의 경험을 멋지게 만들고 싶다. 필요한 기능들을 적재적소에 구현하고, 말보다는 UI로 커뮤니케이션을 잘하는 개발자가 되기 위해 계속 노력할 것이다.

지난 4개월 동안 참 힘든 시간도 많았다. 그럼에도 불구하고 크루들과 주변의 개발자분들에게 여러 도움을 받으면서 어려운 난관들을 헤쳐나갈 수 있었다. 홈페이지 변경이 아니어도 바쁜 일이 많은 시즌 시작 시기에 홈페이지 관련 문의가 쏟아졌다. 그런 상황에서 나를 탓하기보다는 오히려 걱정해주고 격려해주는 동료들이 있었다. 새삼스레 좋은 사람들과 함께하고 있다는 생각을 하며 일을 더 열심히, 잘 하는 것으로 보답하고 싶다고 생각했다.

만약, 제 글을 보고 트레바리에서 개발자로 일하는 것에 대해 조금이라도 관심이 생기셨다면? > https://brunch.co.kr/@getipower/48