리뉴얼된 동닷에 대한 개발적인 부분 설명드립니다.

현 사이트에 대해 운영자인 제가 설명드리는 것 보다 개발사측에서 직접 개발스택 선택이유, 현 서버 선택 이유 등을 설명해 주시는 것이 좋을 것 같아 아래와 같이 정리해 주셨습니다.

내용 전달 드립니다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡ

안녕하세요 동사로마 닷컴 리뉴얼 개발사입니다.

로딩 속도, 개발 스택 등 이야기가 많이 나오는 거 같아 최대한 자세히 설명드리도록 하겠습니다. 또 동사로마 이용자분들 중 개발자분들도 꽤 계신 것 같고 해서 개발 용어들도 넣어서 설명드리고자 합니다.

가. 개발 스택

동사로마는 기존에 php 언어의 그누보드 스택을 이용하여 개발이되었습니다. 같은 언어나 스택을 사용한 커뮤니티도 많은 것으로 확인을 했으나 기존 사이트는 db 설계, 쿼리 설계부터 잘못된 부분이 너무 많았습니다. 단적인 예로 모든 table에서 relation연결이 전혀되어 있지 않았습니다. 게시글과 댓글을 하나의 table에서 관리하고 있었으며 게시글을 쓴 유저는 id 등의 primary key가 name, 심지어는 변경 가능한 nickname, email 등과 연결되어있었습니다. 나아가 그누보드가 역사가 깊은 만큼, 이러저러한 보안 이슈들도 많았는데 너무 주먹구구식으로 개발이 되어있는 형태였습니다.

현재의 동사로마는 typescript 언어로 nextJS 프레임워크를 이용, prisma 등의 라이브러리를 사용했습니다. 저희가 스타트업 위주 개발사이기도 해서 가지고 있던 내부 스택으로 개발을 하였습니다. (현재 스타트업씬에서 가장 많이 이용되는 웹 스택) NextJS로 개발한 웹 중 아실만한 웹은 넷플릭스가 있습니다. 스택이나 언어에 대한 안정성은 보장이 되었다고 생각합니다. 필연적으로 php 개발 스택보다 느릴 수 밖에 없으나, 최적화나 스켈레톤 로딩등의 다른 장치들로 많이 우회할 수 있으며 최신 스택인 만큼 보안, 다양한 기능 개발 가능 등의 이점이 더 크기 때문에 해당 스택 선택에 대해서는 후회하지 않습니다. 온에어와 같은 기능은 php로는 거의 개발이 불가했을 것으로 생각합니다.

나. 배포 구조

기존 동사로마는 cafe24에서 서버를 대여해서 사용하고 있었습니다. 현재는 트래픽에 대해서는 더 관리가 용이한 serverless 방식으로, vercel에 배포되어있습니다. 백엔드는 supabase를 사용했으며 firebase의 대항마로 나온 서비스이며 nosql 기반의 firebase와 비교하여 rdbms를 지원합니다. 물론 AWS의 EC2와 RDS를 이용할 수도 있고 현재 그러한 서버로 이전하는 건 그렇게 큰 공수가 드는 일은 아니지만 같은 조건에서 서버만 이전했을 때 서버비가 최소 1.5배는 나올 것으로 예상되어 그렇게 하지 않고 있습니다. supabase에서도 더 높은 서버를 선택할 수 있으며 현재에도 트래픽이 몰리면 잠깐씩 한단계 높은 서버로 이전하여 하고 있습니다. (이전이라기보단 컴퓨팅 리소스를 쉽게 변경할 수 있어 선택적으로 이용하고 있습니다.)

현재 문제가 되고 있는 서버는 Vercel이 아니라 supabase입니다. 수많은 쿼리들을 감당하지 못하고 있습니다. 후술하겠지만 csr, ssr을 선택적으로 이용하더라도 결과적으로 db에서 받아오는 시간 자체가 현재 가장 크리티컬하기 때문에 그리 큰 차이는 없을 것으로 판단했습니다.

다. 로딩 속도

로딩 속도 문제는 초기에 서버 터진 현상과 해결 과정, 또 앞으로 최적화해나갈 지점에 대해 설명드리는 게 좋을 것 같아 말씀드리려 합니다.

우선 동사로마는 현재 절대적인 규모가 아주크지는 않은 웹 사이트 입니다. 다만 이용자 분들 한 분 한 분이 사용을 많이 해주심에 따라 pv(페이지뷰) 수는 저희가 경험해온 다른 곳보다 큽니다. 월 평균 pv수는 300만인데요, 규모에 비해 페이지 뷰가 압도적으로 굉장히 큽니다. 이 지점에서 기존 웹에 GA가 잘못 설치되어 pv수가 잘못 산출되고 있을거라고 넘겨짚었으며 그게 가장 큰 문제였습니다. 우선 해당 문제를 해결하기 위해 아래와 같은 최적화를 진행했으며, 또한 진행할 예정입니다.

1. 쿼리 최적화

2. 서버 업그레이드

3. revalidation 최적화

4. db pooler connection 제한 수정

5. prisma singleton 패턴 적용 확인

6. csr, ssr 분리

7. waterfall 방식 수정

1의 경우 불필요한 필드는 받아오지 않는 형식, 쿼리를 합칠 수 있는 건 합치는 형식으로 진행했습니다. 모든 쿼리에 대해 진행하였으며, 쿼리 대신 DB Trigger로 우회할 수 있는 기능에 대해서는 그렇게 진행하는 중에 있습니다.

2의 경우 Supabase의 컴퓨팅 리소스를 두단계 업그레이드 했다가 안정화가 된 이후 1단계를 줄였습니다.

3의 경우 아직 불편함을 느끼시는 지점일 것 같은데 NextJS에서 새로 Data fetching을 실행하기 위해 revalidate 하는 쪽에 비효율적인 코드가 있었어서 data-fetching이 의도보다 많이 이루어지고 있었음을 확인했으며 이는 supabase쪽에 무리가 갔을 것으로 판단하여 현재 꺼두었습니다. 댓글 새로고침이나 글 새로고침 기능이 잘 동작하지 않는 것은 이 때문입니다. 현재 최적화해두어 코드를 적용 할 수는 있지만 이 부분에서 잘못 반영하게 되면 서버가 다시 터질 가능성이 있을 것 같아서 두 번 세 번 확인해보며 고치고 있습니다.

4의 경우 현재 serverless 환경에서 postgresql에 연결하기 위한 방식으로 db pooler를 이용하고 있습니다. 사실상 serverless 환경에서는 필수적이라고 보여집니다만, 서버 업그레이드 이후에도 max connection 수를 잡아두지 않았던 이슈 때문에 (기본 커넥션 수로 많이 부족했었습니다.) 현재 커넥션 수나 pooler 쪽 이슈는 모두 잡혔습니다.

5의 경우 내부 레포지토리 패턴 이용시 Prisma singleton instance가 제대로 동작하지 않던 경우가 있었던 것으로 확인하였습니다. 같은 세션에서 여러개의 인스턴스가 생성되어 db connection이 중복으로 잡혔던 경우가 조금 있었는데 해결해두었습니다.

6의 경우 한 유저분께서도 말씀해주신 글을 봤습니다. 우선 개발 과정중에 스켈레톤 로딩을 활용하여 작업을 해놨었으나 그 당시에는 저희만 접속을했었기 때문에 오히려 없는 게 낫다는 의견이 중론이었습니다. 다만 서버가 몰리고 다시 부활시키고자 했을 때 현재 페이지 로드 속도는 2~3초인데 해당 기능으로의 롤백시 5초 이상 길어졌습니다. 아마 임베드 기능 때문에 html 렌더링 로직에서도 서버를 호출해야하는데 이게 csr이라고 하더라도 서버 액션을 호출하다보니 더 시간이 오래걸리는 것 같습니다. (ssr시 한번에 처리하는 게 더 빠릅니다.) 다만, 임베드 로직을 아예 글 발행 시 처리할 수도 있을 것 같습니다. (그럼 기존 글들은 임베드가 안될겁니다 ㅠ) 레거시 글들에서까지 임베드 기능이 붙기를 바랐던 건데 저희 쪽에서도 일정부분 설계가 아쉬웠다고 느끼고 있습니다. 물론, 해당 로직에서 생기는 딜레이가 유의미하지는 않습니다.

어차피 현재 문제가 db query속도가 느린게 가장 크기 때문에 이걸 잡는 게 우선으로 보여집니다. data fetching은 서버 컴포넌트에서 하는 게 컨벤션이며 렌더링 속도를 클라이언트와 분리하더라도 그렇게 유의미한 속도차이가 있을 것 같지는 않습니다. 그럼에도 스켈레톤 로딩 등으로의 변경은 사용자 경험에서 큰 차이가 있을 것으로 생각하여 최적화하면서 도입할 가능성이 높습니다.

7의 경우 이전에 async / await 함수들을 하나하나 실행하는 waterfall 방식으로 설계되어 Promise.all 등의 메소드로 실행 순서가 중요치 않은 서버 함수들을 다 묶어서 실행했습니다. 그 결과 vercel 쪽 serverless edge function 쪽 최적화는 많이 이루어졌습니다.

라. UI 적인 측면

프로젝트 시작부터 디자인 시스템, 컬러스킴을 잡고 시작했습니다. 패딩과 마진 폰트사이즈 등 기준을 다 잡고 시작했으나 프로젝트 중 잦은 디자인 수정, 배포 후 다양한 피드백들을 수용하려 하다 기준이 모호해진 것 같습니다. 이런 지점까지 고려했어야 하는데 이 부분에서의 부족함은 깊게 느끼고 있으며 그렇기 때문에 추가적인 디자인 수정도 진행하였습니다. 죄송합니다.

말씀드린 이유들 이외에도 다각도로 최적화 방식을 강구하고 반영하고 있습니다.

혹시 동사로마 이용자분들 중 개발자 분이 계시어 최적화에 있어 도움주실 수 있는 분이 계시다면 동사로마 메일로 말씀주셔도 정말 감사하겠습니다.

ㅡㅡㅡㅡㅡㅡ

위 내용은 금주내로 마무리 지으시려고 한다고 전해달라고 하셨습니다. 여러가지로 부족한 부분을 보여드려 운영자인 저 또한 죄송한 마음을 거듭 전합니다.

다만, 개발사 측에서는 밤낮없이 문제 해결을 위해 힘써주시고 계시며 개발에 대해 지식이 없는 운영자에게 매우 적극적인 커뮤니케이션으로 애써 도와주셨습니다.

여러가지로 화나시는 마음은 충분히 이해하지만 밤낮없이 노력해주신 개발사보다는 책임자인 저를 탓해주시면 감사하겠습니다.

개발사 측에서 전해주신 내용들이 충분히 설명이 되었으면 좋겠습니다. (필연적으로 느릴 수 밖에 없는 부분 등..)

감사합니다.

동사로마닷컴 드림