포트폴리오 겸 기술블로그를 구축하면서 고려했던 사항들을 정리해본 글입니다.

자유도 (기능, 디자인 모두)

🧐 커스텀을 자유롭게 하고 싶었고, 디자인과 UI/UX 편의성으로 승부를 두고 싶었다.

왜 기존 플랫폼을 선택하지 않고, 직접 짰는가?

이미 블로그 플랫폼은 매우 많지만, 커스텀의 자유도가 직접 만든 블로그보다 떨어진다는 것이 아쉬웠다.

고민했던 플랫폼은 Velog, Medium, Tistory였는데, Tistory는 광고가 많이 달려있거나 커스텀을 해도 디자인이 내 기준에는 예쁘지않았다. 그리고 Velog, Medium은 개발자들이 많이 사용해서 연관글로 노출되거나 구글에서 검색이 꽤 잘되는 것이 장점이었지만, 폰트나 커스터마이징이 어렵다는 점이 아쉬웠다. 또 네이버 블로그는 검색엔진, 누락, 최적화 이슈, 마크다운 및 코드블럭 미지원으로 개발자 블로그로 사용하기에는 부적합하다고 생각이 들었다.

검색엔진의 노출

SEO 작업은 내 콘텐츠를 잘 노출시키기 위해서는 꼭 필요하다고 생각했다.

정적 사이트 생성기 Gatsby는 빌드 시점에 데이터를 가져와 사전에 렌더링을 해서 성능을 최적화하여 페이지 로딩속도를 빠르게 한다. SPA페이지는 사이트를 방문할 때마다 HTML파일을 생성하는데, Gatsby는 빌드 시점에서 모든 콘텐츠를 생성하여 페이지와 이미지를 최적화하기 때문에 검색엔진에서 노출될 가능성이 더 높아진다.

React로 만든 SPA페이지와 Gatsby로 만든 Static(정적)페이지를 비교해보다면 그 차이를 알 수 있다.

React 기반 프레임워크

이 블로그를 처음 만들었을 때는 내가 퍼블리셔에서 개발자로 넘어가던 시점이었기에, 아직 개발 지식이 부족한 상태로 만들어서 문서들이 잘되어있거나 레퍼런스가 많은 프레임워크로 선택하였다.

그 중 React에 익숙한 나에게 Gatsby는 최적의 프레임워크였다.

Gatsby에서는 GraphQL를 사용하여 API, 데이터베이스, CMS 등 여러 소스에서 데이터를 손쉽게 가져올 수 있다. 즉 콘텐츠를 외부 CMS, 다른 데이터베이스 서버 등 여러군데 저장해둬도 블로그로 쉽게 끌어올 수 있다는 것이다. 물론 GraphQL을 몰랐을 때는 어려웠지만 사용하다보니 어느정도 익숙해졌다.

그리고 다양한 플러그인이 지원되고 정보들도 많아서 제작하기 쉬웠다.

그 밖의 이유

나의 아이덴디디티를 표현하고 싶었다

가끔 정보를 찾다가 유난히 기억에 남는 블로그들이 있었는데, 개츠비로 작업된 블로그들이 많았다. 그래서 자연스럽게 Gatsby 프레임워크에 관심을 갖게되었고, 나도 그 중 하나가 되고 싶었다. 아직은 부족한 점이 많은 블로그지만, 가독성도 계속 높이고 사용자들이 글을 더 편하게 읽을 수 있도록 리뉴얼해갈 예정이다.

수익도 함께 얻고 싶었다.

사실 개발 블로그는 돈이 안되기에 수익이 목적이라면 API 또는 애플리케이션을 만들어서 판매하는게 나을 것이다. 몇년 후 시니어개발자로 성장하고 이름 있는 IT 대기업에 근무하고 있다면, 책을 쓰거나 강의하는게 훨씬 나을 것이다.

그래도 아주 약간의 수익이라도 얻을 수 있지만 심미성을 위해 구글애드 하단에 한 개, 쿠팡 파트너스 광고 하나 정도를 추가할까 싶다.

정리를 하면서 좀 더 완벽하게 이해하기 위해서

작업 혹은 공부하고 정리하지 않으면, 금새 또 까먹는다. 인간은 같은 실수를 반복하니 머리 속에 흩어져있는 정보들을 정리하며 기록해둬야겠다는 생각이 들었다.

블로그에 글을 정리하는 습관을 들이고, 나만 이해할 수 있는 언어로 작성된 것이 아니라 다른 사람들도 이해할 수 있는 글로 작성하면서 보다 완벽하게 이해하고 싶었다. 일을 할 때도 커뮤니케이션은 너무나도 중요한데, 내가 제대로 남에게 설명을 할 수 없다면 내가 한 노력은 인정받지 못할 것이다.

아무튼 블로그 포스팅을 위한 글을 작성하면서, 나도 공부가 많이 된다. 정리라는 것은 일상생활 어디서든 매우 중요하다고 생각한다. 이는 지식을 정리하는데 있어서도 마찬가지라고 생각한다.

배울 것들이 많았던 작업

직접 블로그를 구축하다보니 배우게 된 것들이 많았다.

• React 경험
• 정적 블로그에 대한 이해
• GraphQL 연동
• Netlify를 통한 실 서비스 배포
• 컴퍼넌트 기반 작업에 익숙해짐.
• 마크다운 문법이 편해짐.

삽질도 많이 했지만, 많이 성장했던 작업이었다.
그럼 다음 글에서는 작업과정에 대해 이야기해보겠다.