# Git Page & Next.Js 블로그 개발 프로젝트 ## 기술 스택 * Next.js 14 * Node * Typescript * Git Page * GitHub Actions * MDX # 개발 동기 벨로그와 티스토리를 번갈아 사용하면서 여러 가지 불편함을 느꼈습니다. 이들 플랫폼은 기본적인 틀이 잡혀 있었지만, 커스터마이징의 자유도가 낮아 원하는 대로 확장하기 어려웠습니다. 그래서 제가 원하는 형식으로 글을 자유롭게 다룰 수 있는 GitHub Pages를 활용한 호스팅 시스템을 만들기로 결정했습니다. ## 왜 Git Page로 라우팅 했는가? 정적 페이지를 사용할 경우 React의 상태 변화에 따른 매끄러운 전환 혜택을 누리지 못한다는 점을 이해하고 있었습니다. AWS와 같은 웹 컴퓨팅 서비스를 통해 이러한 문제를 해결할 수 있지만, AWS의 프리 티어는 제한된 기간 동안만 무료로 제공된다는 점이 마음에 걸렸습니다. 비용 초과가 발생할 수도 있고, 이를 지속적으로 관리하는 것이 번거로울 것이라는 우려도 있었습니다. 따라서 GitHub Pages를 이용하여 이러한 걱정 없이 무료로 계속 사용할 수 있는 시스템을 설계하고자 했습니다. # 힘들었던점들 ## 1. Next.js App Router 자료 부족인한 개발 속도 저하 우선 next 14로 개발을 진행하다보니 자료들이 많이 부족했습니다. App Router가 도입된 next 13 의 출시일이 22년 10월 26일였고 이 블로그를 개발했을때 당시에는 24년 11월이였죠. 2년 정도로는 한국어로된 자료들이 많이 부족하여 개발하면서 공식 문서를 하나하나 파헤치면서 오류를 잡아나가야 했었습니다. 이 블로그는 next에서 추천하는 방식인 App Router 방식으로 개발을 진행하고자 했고, GitHub Pages에서 배포를 진행하면서 모든 것을 정적 사이트에 맞춰 개발해야 했기 때문에 검색하는 데 어려움이 많았습니다. 검색을 해도 Pages Router 방식의 자료들이 많이 나와서 참고를 하기가 어려웠습니다. *각 라우터별 함수 정의 방식* Pages Router는 3단계로 나뉘어 경로 생성, 데이터 생성, 페이지 생성으로 구성되어 있는 반면, App Router는 2단계로 경로 생성과 데이터 생성을 통해 페이지를 생성하는 방식입니다. 이러한 차이로 인해 사용해야 하는 함수명과 생성 방식이 달라, 기존 Pages 방식의 자료를 참고할 수 없었습니다. 기존에 쌓여온 자료들이 많았지만, 이를 활용할 수 없었기 때문에 공식 문서를 하나하나 읽으며 상세한 개념을 이해해야 했습니다. 이러한 과정은 개발 속도를 늦추는 큰 요인이 되었습니다. ## 3. MDX 지원 라이브러리 수가 적음 *24-11-04 기준 MDX 라이브러리 수* MDX라는 마크다운 문서는 사용된 지 오래되지 않았기 때문에 전체적으로 지원하는 라이브러리 수가 적은 것은 큰 흠이 아닙니다. 하지만 빠르게 개발해야 하는 입장에서 보면, 지원하는 라이브러리 수가 적다는 것은 그만큼 많은 사소한 기능들을 **개발자가 직접 구현**해야 한다는 의미입니다. 이로 인해 개발 속도가 저하되고 관리해야 할 요소의 수가 늘어나면서, 개발자의 피로도 또한 증가하게 됩니다. MDX를 잘 활용하면 커스텀 JSX 엘리먼트(컴포넌트)를 그대로 지원할 수 있는 장점이 있지만, 이러한 장점이 부족한 라이브러리 수로 인해 상쇄될 정도의 단점이 되기도 했습니다. # 긍정적인점들 이러한 단점들을 하나하나 극복해 나가면서 다양한 경험을 쌓을 수 있었습니다. 우선, GitHub Pages에서 요구하는 정적 페이지 방식과 Next.js에서 생성하는 정적 페이지의 개념을 맞춰 나가면서 각 기술의 작동 방식에 대해 상세하게 이해하게 되었습니다. 또한, 자료가 부족한 상황 속에서 공식 문서를 하나하나 살펴보며 기술에 대한 이해도를 높일 수 있었습니다. 문서를 통해 개념을 명확히 하고, 실제로 코드를 작성해 보는 경험은 매우 유익했습니다. 이와 함께 오픈소스 프로젝트의 코드를 분석하면서 다른 개발자들이 어떻게 문제를 해결하고 있는지, 다양한 관점을 경험 할수 있었습니다. # 개선할점 ## Code Byte 계산 수정 현재 메인 페이지의 GIT CodeByte 계산식은 개인 레파지토리를 제외하고는 모두 Main 브랜치에 한해서만 계산하고 있습니다. 하지만 개인 레파지토리는 브랜치 상관없이 계산을 진행하고 있기에 이를 Main 브랜치에 한해서만 계산 하도록 개선해야합니다. Main 브랜치에서만 계산이 가능하게 만들어야 하는 이유는 Main 브랜치가 아닌 타 브랜치도 계산을 하면은 Main 브랜치 +a 의 CodeByte를 계산하게 된다는것과 같습니다. 그렇기 때문에 복붙해서 크기를 늘리는것과 동일합니다. ## MDX 데이터 가공 최적화 현재 각 MDX 데이터를 가공할때 MDX-Remote 라이브러리의 데이터 랜더링을 의존해서 사용하고 있습니다. ```tsx export async function getCompileMDX(...readPath: string[]): Promise<{ content: React.ReactElement>, frontmatter: Record }> { const join = path.join(...readPath); const source = fs.readFileSync(join, 'utf8'); const compiled = await compileMDX({ source: source, options: {parseFrontmatter: true}, components: userMDXComponents() }) const content = compiled.content; const frontmatter = compiled.frontmatter; return {content, frontmatter} } ``` 해당 코드를 다음과 같은곳에서 사용하고 있죠. 1. 메인 화면의 총 태그 사용 수 2. 메인 화면의 최신 포스트 뷰 3. 포스트 리스트 뷰 4. 포스트 뷰 5. 프로젝트 리스트 뷰 6. 프로젝트 뷰 이중 태그 계산, 리스트 뷰에서는 모든 데이터가 필요없습니다. 즉 총 4가지에서 불필요한 데이터를 가져와서 이를 다시 재가공해서 사용하고 있다는거죠. 현재로써는 포스터의 수가 적으니 그렇게 큰 문제점은 아니지만 추후에 많은양의 포스터가 쌓일시에 빌드시간이 기존의 포스터를 빌드하는데에도 소모시간 + 불필요한 데이터 불러옴으로 인해 점진적으로 더 늘어날것이라는것은 명확합니다.