Next.js로 다시 인사드려요.

제가 사용하던 블로그 스타터 (탬플릿)인 Semantic의 기반이 되는 기술이 Gatsby.js 에서 Next.js로 바뀌게 되었습니다.

그래서 혹시 제 블로그에 오랜만에 들어오셨다면 무언가 변화를 느끼셨을수도 있습니다. 느끼셨다면 프론트엔드에 상당히 조예가 깊다는 뜻이 되겠네요.

바꾸게 된 이유로는 Gatsby.js로 버틸 수는 있지만 사후지원도 더이상 어려워지고 Semantic이 여러 업데이트 계획을 가지고 있기에 옮길 필요가 있었습니다. 그리고 옮기는데 글도 많지 않고 기술적 기반이 바뀌는 것이지 인터페이스가 바뀌는것도 아니라서 사용자 경험적 측면에서의 리스크도 없습니다.

슬슬 포스팅을 3개나 썼으니 템플릿을 바꿀 때가 되기는 하였네요.

Next.js의 장점

그전에 Next.js는 무엇일까에 대해 개발을 하지 않는 사람으로써 가볍게 넘어가자면

우선 기존에 사용하던 Gatsby.js와 같이 React 기반입니다. 스테틱 웹사이트와 요즘 기술적 트랜드인 서버 사이드 랜더링이 특징이라고 합니다.

블로그는 글 그 자체니깐 한번 글을 받아보면 그만인 부분이라 스테틱 인것이 오히려 더 유리하다 판단했고요. 서버 사이드 랜더링 또한 클라이언트에서 굳이 랜더링을 해야할 요소가 많다고 생각하지 않았습니다. 블로그라는 매체가 사진하고 글을 받아보기만 하면 끝인데 리스크는 크지 않다고 생각했습니다.

그리고 로컬이라는 동일 조건에서 Gatsby와 비교하여 돌려보았을때도 더 빨랐습니다.

이전 시작하기

기존에도 mdx를 사용해온 만큼 크게 어렵지는 않습니다. 글이 아주 많았다면 자동화를 검토했어야 했겠지만 수동으로 이전하였습니다. 사실 기존 레포지트리에서 포크해온걸 그대로 동기화 하듯 가져올수도 있는데요 기존에 포스팅한 파일을 남겨두는 방법을 익히는것이 조금 더 어려운 상황이고 글 개수 자체도 많지 않아 새롭게 fork를 하기로 하였습니다.

대략 프로세스는 다음과 같이 진행하게 됩니다.

기존 posts 폴더 복사 -> 새로운 semantic의 frontmatter 변경사항 확인 및 수정 -> 새로운 semantic을 GitHub에서 fork 하고 로컬에 clone -> 수정된 frontmatter를 가진 posts 폴더를 동일한 위치에 붙여넣기 -> 로컬에서 Next.js 실행 후 문제가 없는지 확인 -> Commit & Push -> gh-pages가 정상적으로 작동하는지 확인 -> 도메인 DNS 변경

정말 1시간도 안걸릴줄 알았는데 며칠이 걸렸습니다. 아래에서 부터 문제를 하나씩 해결한 방법들을 이야기하도록 하겠습니다.

frontmatter을 잘 보았다면.

저는 frontmatter가 바뀌었다는 생각을 하지 못했습니다. 멀쩡하게 posts 파일을 이동시키고 왜 로컬에서 블로그 포스팅이 하나도 뜨지 않을까? 하고 고민을 했었습니다.

modifiedAt: "2025-02-28T00:00:00.000Z"

frontmatter를 살펴보니, modifiedAt 이라는 것이 생겼다는 사실을 모른 채 열심히 로컬 Next.js 서버를 껐다 켰다 했습니다. 기존 것이 잘 돌아간다면 꼭 제가 무언가를 놓쳤는지 확인해봐야 한다는 사실을 다시금 배우고 갑니다.

두개의 fork는 있을 수 없다.

저는 한번 fork 한 레포지트리를 또 한번 fork 하는 것에 문제가 없다고 생각했습니다. 같은 개인 혹은 조직에 한번 fork를 했던 레포지트리가 존재한다면 할 수 없습니다.

일단 Fork Network에 연결된 레포지트리와 연결을 끊는다면, 더이상 fork를 뜬 레포지트리와는 관계가 없어지기 때문에 연결 관계에서 벗어난다면 다시 fork를 뜰 수 있습니다.

하지만 semantic 자체도 업데이트가 진행중이라 일부 파일은 받아들여야하지만 전부 받아들이면 제 포스팅이 사라지는 문제가 있을 수 있는데 이 문제를 어떻게 해결해야 할지는 숙제로 남아있습니다.

토큰을 집어넣고 Push를 시도하다.

기존 블로그는 Vercel로 돌아가고 있었는데, GitHub Pages로 이사를 가게 되면서 Vercel처럼 레포지트리에 Push하면 자동으로 배포되도록 하려면 토큰 관련 정보를 확인할 필요가 있었습니다.

관련 공식 포스팅 | Automating Deployment with GitHub Actions

저는 토큰을 발급받는 것 까지는 완료 하였는데

        with:
          publish_dir: ./out
          publish_branch: deploy
          github_token: ${{ secrets.GITHUB_TOKEN }}

저기 secrets.GITHUB_TOKEN 라는 해당 자리에 제 토큰을 넣어야 하는거 아닌가 라는 오판을 하게 됩니다.

그리고 제 토큰을 어디다 함부로 올리면 안된다는건 정말 상식인데요. 제 나름대로 "Private 레포지트리에는 토큰을 올릴 상황이 있을 수 있으니깐 토큰을 올려도 문제가 없지 않을까?" 라는 오판 중의 오판을 하였던 것입니다. 나름 토큰이 중요한걸 알아서 레포지트리 공개 여부를 나름 철저하게 확인하고 괜찮겠지 하고 올릴 시도를 하였습니다.

그리고 이것을 시도하면 GitHub 차원에서 막습니다. 깃허브를 제외하고도 토큰은 정말 비밀번호 같은 것이기에 AWS의 권한이 탈취뒤어서 보지도 못한 스팟 인스턴스가 무수히 생기고 코인을 채굴하는 피해가 생기는 등... 수많은 사람들이 토큰을 올리다 흘린 눈물이 저를 살리게 된것입니다. 전세계 개발자분들께 감사 드립니다.

끝나지 않는 배포의 문제

로컬에서 문제없이 다 돌아가고 정말 배포만 하면 끝날 줄 알았는데 계속 README.md 만 뜨는 문제가 발생하고 있습니다.

semantic을 개발한 지인이 살펴본 결과 본 레포지트리에서는 Token에 접근할 수 있지만, fork해서 가져온 레포지트리에서는 Token에 접근할 수 없는 문제가 있었습니다. 해당 Commit에서 이 문제에 대응한 방법이 있으니 참고해보시면 도움이 될 것 같습니다.

그리고 main 브렌치에 push 하면 자동으로 depoly에 넘어가는데 deploy에 쑤셔넣어서 왜 안되는지 사투를 벌이기도 헀습니다. 이후 GitHub Pages에 별도의 도메인을 연결 하려면, public 디렉토리에 확장자가 없는 파일로 cname을 생성하여 도메인을 넣어주면 됩니다.

마치며

퍼포먼스가 정말 좋아졌나 궁금해서 PageSpeed Insights를 돌려봤습니다. 퍼포먼스 속도가 9점 상승했습니다. 드라마틱한지는 모르겠으나 적어도 나름 유의미한 상승이라 생각하네요.

그리고 블로그 파비콘, 이름, 메인의 소개 등등 바꿔야 할것이 많습니다. 천천히 바뀔 듯 합니다.

이번 포스팅은 저번보다 조금 가볍게 썼습니다. 사실 하는 방법을 캡처 따가며 처음부터 적어볼까 했는데, 그렇게 하다가는 포스팅하는데 시간을 무지막지 잡아먹어 블로깅 행위 자체에 학을 뗄 것 같았습니다.

가벼운 포스팅을 한번 해보고 어떤 식으로 경험을 앞으로 전달할 수 있게 될 것인가 그리고 방향성을 어떻게 들고 갈 것인가에 대한 고민을 해볼 수 있을 것 같네요.

그리고 상용 플랫폼을 쓰면 되는데 왜 블로그를 잘 모르는 여러 프론트엔드 기술을 찾아가며 하냐 라고 할 수 있는데, 한 때 개발자를 하려고 했었고 개발과 관련된 기술과 거리를 계속 가깝게 가지고 싶다는 개인적인 욕구에 의한 것입니다.

Photo by todd kent on Unsplash

디지털 세계에서 직접 블로그를 만들어 쓴다는것은 마치 미국에서 차고지에서 직접 기계들을 고쳐쓰는 풍경처럼 약간 낭만이 있는 것 같다고 생각합니다. 낭만은 자고로 비효율을 추구하기에 낭만인거죠.

그리고 어떻게 보면 Next.js면 Vercel과 한몸인데 gh-pages로 또 굳이 넘어왔습니다. 장기적으로 vercel에 있는 제 메인 페이지인 stile.im을 블로그와 통합해야합니다. 과연 할 수 있을까요? 빨리빨리 자바스크립트를 배워야겠습니다. React도 해야하고 Next.js도 해야하고 벅차네요.

이무튼 봐주셔서 감사합니다.