과거 Psono.com은 Odoo v11에서 구동되었습니다. Odoo는 훌륭한 CMS이지만, 업데이트는 매우 어려웠습니다. 특히, 그들의 웹사이트 모듈은 테스트 중 많은 문제를 일으켰습니다. Odoo v11은 2020년 말에 수명이 끝날 예정이어서 해결책을 찾아야 했습니다.
우리는 여러 가지 옵션을 고려했습니다. Odoo v13으로 업데이트하고 모든 콘텐츠와 커스터마이징을 수동으로 이전하거나, 누군가에게 이전 작업을 맡기거나, 또는 완전히 새로운 CMS로 이전하는 것이었습니다. 우리는 Psono.com을 완전히 다른 CMS로 이전하기로 결정했으며 v11을 방화벽 뒤에서 계속 사용하고 나중에 이관하기로(아직 결정하지 않음) 했습니다.
그 결정의 이유는 다음과 같습니다:
- Psono.com에 이관할 콘텐츠가 극히 적습니다. 주로 몇 가지 블로그 게시물입니다.
- Odoo v13으로의 이전은 v13이 수명을 다할 때인 2년 후에 동일한 문제를 재현할 수 있으며, 이 시점에는 더 많은 데이터를 이전해야 할 수 있습니다.
- Odoo v11 웹사이트의 커스터마이징 기능에 만족하지 못했습니다. 모든 것이 매우 복잡하고 템플릿이 데이터베이스에 저장됩니다.
- 비용. 누군가에게 이전 작업을 맡기는 데 적어도 5000 USD, 어쩌면 그 이상이 들 것입니다.
- Odoo 커뮤니티는 매우 활발했지만, 최근 몇 년간 라이선스 전환과 플러그인기능을 유료 솔루션으로 이전하고 모든 것을 유료 벽 뒤에 놓으면서 커뮤니티는 사라졌습니다.
- Psono.com은 주로 정적 웹사이트입니다. 동적 콘텐츠가 필요하다면 API를 통해 가져올 수 있습니다.
여정
이전 결정을 내린 후 어떤 프레임워크를 사용할지 결정해야 했습니다. 예를 들어, 우리가 사용했던 고전적인 프레임워크 hugo는 기능이 제한적입니다. 대안을 찾는 동안 우리는 노드/리액트 세계에서 몇 가지 솔루션을 발견했습니다.
이 글을 쓰면서 "훌륭한 솔루션"이라고 쓰고 싶었지만, 현재의 프론트엔드 개발 상태에서는 그 칭호를 받을 만한 것이 없다고 생각합니다. 부서진 상태라고요? 과거에 개발자가 index.html과 jquery를 로드하는 스크립트 태그로 웹사이트를 만들고 개발을 시작할 수 있었던 때를 기억하시나요? 이제는 npm이나 yarn이 필요하고 package.json, webpack 스크립트, Angular나 React 같은 현대식 프레임워크를 이해해야 합니다. JSX나 TypeScript 등도 필요합니다. 핫 리로딩 같은 기능은 신뢰할 수 없이 작동합니다(파일이 모니터링되지 않거나, 일부 수정 사항이 전체 재시작이 필요하거나, 핫 리로딩이 너무 일찍 트리거되어 수동으로 새로 고침해야 함). 그래서 개발 서버를 종료하고 다시 시작하는 데 몇 분을 기다려야 합니다(특히 큰 프로젝트에서). (F5를 눌러서 모든 것이 문제 없이 바로 표시되던 시절이 그립습니다!). 여기에 매년 반 년마다 새로운 프레임워크나 도구가 생기는 것까지... 현재 프론트엔드 개발 상태에 대해 불평하려면 쉽게 페이지를 채울 수 있습니다. 어쨌든, 실제 주제로 돌아가죠.
현명한 대안이 없는 상황에서 (제가 이 글을 쓰는 시점에서) 최고의 옵션은 next.js와 Gatsby였습니다. 몇몇 기사에서 그렇게 홍보하고 있습니다. 두 가지 모두 GitHub 별표나 커밋 수를 비교해보면 똑같이 인기가 있습니다. 초기 평가에서 유일한 차이점은 next.js는 서버 구성 요소가 필요하지만, Gatsby는 정적 사이트를 생성한다는 것입니다 (next.js를 활성 서버 없이 실행할 옵션이 있다면 말하지 않겠습니다! :D)
그래서 우리는 Gatsby를 조금 사용해 보았고 괜찮아 보였습니다. 다음 단계로 우리는 테마를 찾기 시작했습니다. Gatsby는 "새로운" 유틸리티로, 우리가 찾을 수 있는 모든 테마가 아직 기본 상태였습니다. 30분과 30달러 후에 시각적으로 매력적인 테마를 발견하여 몇 가지 필수 구성 요소를 다루고 이를 수정하기 시작했습니다.
호스팅 옵션으로는 현재 Firebase, Netlify, Cloudflare, Vercel, 간단한 GCP 클라우드 스토리지 또는 AWS Cloudfront, 자체 서버, Kubernetes에서 실행되는 Docker 컨테이너 등 여러 제공업체 중에서 선택할 수 있습니다. (한 달에 PHP와 MySQL DB가 포함된 웹 공간을 $5에 제공하는 옛 시절을 기억하시나요? :D ... 하지만 그것은 다른 기사에서 다루겠습니다...)
이들을 비교하고, 리뷰를 읽고, 가능한 조합(예: Firebase 앞의 Cloudflare)을 확인한 후 Cloudflare을 처음 시도했습니다. 그들의 서비스를 좋아하는 팬으로서 자연스러운 선택이었지만, 그들의 wrangler 유틸리티에 문제가 있었습니다. 처음에는 항상 오류를 일으켰고, 인증을 할 수 없었습니다 ... 초기 오류는 다음 날 사라졌지만(아마 새로운 셸이 해결책이었을 것입니다), 인증 문제는 여전히 지속되었습니다. 여러 시간 동안 문서를 읽고 다른 해결책을 시도해 본 후 드디어 포기했습니다.
Netlify도 또 다른 후보였지만, git 제공자로 연결하여 빌드를 하거나(우리는 GitLab CI를 사용하고 싶었습니다) 빌드 출력을 수동으로 업로드해야 했습니다. 어딘가에 빌드 출력을 API를 통해 업로드할 수 있는 옵션이 있을 수도 있지만, 찾을 수 없었습니다. 빌드 출력을 푸시하는 저장소를 사용할 수도 있었지만, 그것은 불필요하게 복잡해 보였습니다 ... 또 다른 문제는 그들의 가격 모델입니다. 그들은 구성원당 상당한 금액을 청구합니다(!!!). 이것은 정적 웹사이트를 위한 것입니다. "4× 대역폭"과 같은 문구는 "공정 사용 웹 호스팅"-시절의 나쁜 기억을 떠올리게 하며, 너무 많이 사용하면 강제 종료당할 수 있습니다...
네 번째로 Firebase를 시도했는데(우리 목표 대역폭과 요청에 대해 무료입니다), 모든 것이 바로 작동했습니다. 경로 재지정 기능은 제한적이어서 오래된 URL을 더 아름다운 URL로 매핑하는 것이 다소 번거로웠지만, 몇 가지 재지정 규칙을 작성한 후 모든 것이 작동했습니다. 그들의 가격은 합리적으로 보이며, 서버 리소스에 대해 청구됩니다. 추가 서비스를 모두 피하여 공급업체 잠금 상태를 피하는 것이 좋지만, 우리는 호스팅만 필요했습니다.
Vercel도 잠깐 확인했지만, Github 계정으로 로그인하고 "내 대신 행동"이라는 권한 요청이 가입하기 전부터 방해가 되었습니다.
가장 어려운 것은 블로그 이전이었습니다. 우리는 모든 콘텐츠를 수동으로 복사했습니다. 이는 더 큰 블로그에서는 하지 말아야 할 일이지만, 우리의 블로그는 15개의 게시물만 있었습니다. Gatsby는 다양한 메커니즘을 지원하지만, 우리는 기술적 배경이 없는 사람도 새 블로그 게시물을 작성할 수 있는 간단한 것을 원했습니다. 마크다운을 사용하기로 결정했고, Gatsby에 마크다운 페이지를 읽는 방법을 배우는 데 반나절이 걸렸습니다. 멋진 블로그 테마와 이미지는 또 반나절 걸렸습니다.
모든 콘텐츠를 이전하고 테마를 더 많이 수정한 후 GitLab CI를 사용하여 배포를 자동화했습니다. 간단히 푸시만 하면 빌드 파이프라인이 트리거되고 모든 것이 Firebase에 배포됩니다.
왜 GitLab을 사용했을까요? 역사적인 이유로 Github가 우위를 점하고 있습니다. 현재 Github는 최소 80%의 개발자와 프로젝트를 보유하고 있습니다. 반면 GitLab은 기능을 제공합니다. 그래서 과거에는 Github가 몇 년 동안 기능 개발이 없었기에 GitLab을 선택했습니다. Microsoft가 Github를 인수한 이후 극적으로 상황이 변했으며, Github Actions는 이정표입니다. 하지만 Github가 GitLab과 경쟁하려면 아직 먼 길이 있습니다. 그래서 모든 프로젝트를 GitLab에 호스팅하는 우리는 이 프로젝트에도 자연스럽게 GitLab을 사용했습니다.
결론
그리고 이제 여기까지 왔습니다:
- CMS로 Gatsby
- 상업적 테마
- 마크다운 기반 블로그
- Gitlab CI로 자동 배포
- Firebase 호스팅
우리는 이 결과에 매우 만족하며, 새로운 웹사이트는 훨씬 더 좋아 보입니다!
