서비스 플랫폼들의 블로그를 사용하지 않는 이유?
나도 처음엔 Tistory를 이용했다. 너무 편하고 일부 커스터마이즈가 가능하다. 하지만 공부를 하면 할 수록 뭔가 아쉽다는 생각이 들어왔다.
요약하자면 내 블로그를 관리해보면서 아 이런것도 있구나 하고 좀 살펴볼 수 있는 하나의 관심영역에 포함시켜 두고자 개인 블로그를 선택한 목적이 있다.
특히 너무 관리가 잘되고 있는 Tistory, Velog, Medium등 블로그 플랫폼은 그 인프라 안에서 말 그대로 사용자의 입장으로만 이용하기 때문에 어떠한 문제점도 느낄 수 없었다. 왜냐하면 그 트러블 슈팅은 플랫폼 주체가 관리해야할 문제기 때문이다.
나는 현재 저런 플랫폼을 이용하지 않고 나 스스로 블로그를 배포하고있다. 매일 DB에 글을 쓰고, 정적 페이지를 배포해야하고, 또 다른 서버에서 DB를 페이징 처리하며 정적 페이지에 붙이는 배포과정이 반복되고 있다.
당연히 불편하다. 하지만 나는 이런 서비스의 관리적 측면의 어려움, 그 연관 관계 등을 내가 직격으로 맞아보고 싶었다. 어떤 문제들이 발생 할 지, 고려해봐야 할지 고민할 거리가 항상 나타난다. 하지만 불편함에서 오는 해결책을 항상 고민하는 생산적인 생각을 항상 하게 한다.
프로그래밍 언어 학습의 유연성을 생각
다른 사람의 코드를 보고, 커스터마이즈해보는 것도 큰 목적 중 하나다. 누구도 시키지 않았지만, 뭔가 관심이라고 할까 그냥? 그냥 궁금했다 이 과정들이. 또한 개발자로 성장하면서 이런 경험들도 꽤 좋은 경험이지 않을까라는 막연한 욕심이기도 했다.
나는 Next.js라는 Typescript가 가진 매력을 간접적으로 느낄 수 있었다. 아직 저 언어에 대해 어떠한 이해도도 없지만 지인과의 이야기를 통해 우선 열심히 Java 공부하고 나중에 Next.js도 공부해보라는 조언을 듣기도 했다.
특히 프로그래밍을 공부하는 입장에서 Typescript가 현재 JavaScript의 생태계를 연장시켜내고 있는 현재 트렌드를 이해하고 싶었다. 이 언어를 무조건 배워야겠다! 라는 사고방식이 아니라, 어떤 문제가 있길레 저런게 유행이지? 라는 관심의 하나이다. 프로젝트 내부 소스파일들을 이것저것 살펴보다가 전반적으로 뭔가 다가가기 편할 것 같은 느낌은 있었다. 오히려 입문하기 쉽다는 그 Python보다 뭔가 이렇지 않을까 추측이 가능한 프로젝트 구조라던지 문법들이 보여진다.
당장 Next.js를 공부하지는 않을 것이지만 우선 친해지자고 보는 것이다. 그저 플랫폼만을 이용하면서 느끼지 못했던 감정들이 있다. 또한 오픈소스에 대한 흥미?가 시작되었다. 누군가 개발해주겠지~ 라는 어떤 이슈들을 이들은 만들어내고 제공한다. 대충 만들지 않는다. 공유하기 위해 보다 많은 확장성을 고려하고, 친절한 안내를 포함시킨다. 나는 이런 현재 개발자들의 모습들을 간접적으로 느낄 수 있었다.
이 블로그에 대한 현 상황
해당 블로그는 Github를 통해 정적 페이지 배포(홈페이지의 프레임)가 기본적으로 진행 된다.
하지만 게시글은 Database가 별도로 있으며 Vercel이 Github 정적 페이지 배포를 끌어오고, 거기에 Database의 글을 가져와서 붙여주는 방식의 배포라고 볼 수 있다.(내가 이해한 정도로는 그렇다!)
•
따라서 Github 배포단계의 정적 페이지는 모든 페이지가 없는 텅 빈 홈페이지이며
•
DB에서 /{세부URL}을 설정해주면서 작성을 하게 되고
•
Vercel은 배포 시작 시 Github으로부터 정적 페이지 프레임을 1차 배포하고, 2차로 페이지 로딩(변환)들을 시작한 후
•
이 두개를 합쳐서 Vercel이 완성된 Blog형태를 보여준다 생각하면 된다.
결국 Github도 배포된 url을, Vercel도 url을 제공해주며 특히 Vercel측의 URL은 홈페이지가 완성된 형태의 최종 URL이다.
여기서 나는 Cafe24를 통해 구매한 개인 도메인이 있는 상황이고, 네임 서버(cafe24측 DNS가 도메인으로 포워딩해줌<루트는 더깊다 대륙단위) 제공받은 개인 도메인에서 서브 도메인(CNAME추가)을 추가하여 블로그 전용으로 설정해두었다. 이후 해당 블로그 전용 서브 도메인과 Vercel의 URL를 연결 시켜준 상황이다. 메일서버 MX또한 타 플랫폼과 연결해서 사용하고 있어서 Gmail외의 별도의 기업 메일 서비스를 이용하고 있다.
Vercel의 한계에 도달해버린 배포상황
현재 이 블로그에 글이 230개가량 되는데 특히 이미지도 상당히 많다.
내가 글을 작성하는 데이터베이스 해당 프로젝트를 Github을 통해 정적페이지로 변경하고 각 slug마다 페이지로 변환하는 배포하는 과정에서 페이지들을 읽어오는 시간이 점점 늘어나고있고, 이미 포화상태가 되어 빌딩타임이 44분에 육박하고 있다.
참고로 Vercel에서 배포를 45분이 초과하게 되면 Timeout으로 해당 버전의 배포가 취소된다. 이 부분을 직접 config를 통해서 6000ms으로 바꿔보았지만, 해당 권한이 없는 것인지 Vercel측에서 설정을 못하도록 막은것인지 Timeout 시간을 조절 할 수는 없었다.
결국 내 콘텐츠의 용량 자체를 다이어트하거나, 글을 지워야하거나, 최대 목표는 내 NAS를 통해 배포하면 용량에대한 걱정이 줄어들게 된다. 하지만, 당장 Spring 공부에 집중해야 하기때문에 이러한 과정은 휴식시간에 조금씩 관심을 가지면서 만져보려고 한다. 당장! TIL를 계속 올려야 하는데 용량의 문제가 발생하기 전에 우선 기존 DB의 사진들을 최적화 하여 빌딩 타임을 최소화 하고자 한다.
이미지 최적화 필요
나는 우선 내가 할 수 있는 최적화 방안을 생각했다. Next.js에 대한 이해도가 높지 않기 때문에 블로그 자체 프레임을 건들이는 것은 위험한 선택이다. 물론 나중에 GA를 이용한 통계 기능들을 추가하려면 필연적으로 도전해야 하지만, 당장 스터디를 포스팅 하는데 문제가 발생하면 안된다. 나는 그럼 웹 서비스 배포에서 최적화하는 가장 기본적인 단계인 이미지 최적화를 진행하고자 한다. 찾아보니 다양한 이미지 포맷들이 있는데, 음 내 블로그에 대해 더 공부해봐야될 것 같기도 하다.
우선 당장에 모든 DB의 사진(게시글들의 사진)을 추출하니 약 600개 가량된다. 이 사진들을 Optim을 통해 최대압축을 진행했고, 거의 84%의 용량을 세이브 할 수 있었다. 천천히 사진들을 교체해나갈 생각이다. 지금 올린 윗 사진도 마찬가지로 해당 최적화를 진행한 사진이다.
다른 방안 생각. 이미지를 서버에 넣고, 배포하고 링크를 임베디드하면?
이미지를 임베디드하면 그게 배포에 효과가 있을지 아직 모르겠다. 임베디드의 의미가 박아버리는 의미라서 게시글을 Vercel이 만들어 낼 때, 그것을 결국 이미지 형태로 나타내기 위해서는 임베디드 링크 또한 결국 원본의 이미지만큼 데이터가 필요해보인다. 이런 부분들을 어떻게 해결해야 할 지 사례들을 찾아봐야겠다.
추후 해야할 것
•
개발 블로그를 떠나서 내가 이 블로그를 쓰는 것 자체는 정보의 공유이다.
◦
공유가 되려면 노출되어야 한다.
◦
Google Analytics Api를 이용해서 트래픽 통계 확보 및 Keyword 노출에 대해 공부하고 적용해야 한다.
•
커스터마이즈에 대한 생각.
◦
프레임 자체가 마음에 들긴 하지만, 원하는 필드명이나 프로젝트 구조 자체를 뜯어보고 변경해보고 싶다.
▪
이것을 하려면 기본적으로 해당 Next.js 프레임워크에 대한 이해가 필요하고
•
일단 지식의 깊이(depth)가 필요하다
◦
일단 내가 당장 배우는 Spring Framework에 대한 깊은 이해가 필요하다.
•
그 이후 지식의 폭(width)를 확장시켜야 한다.
◦
기반 지식을 이용하여 주변 지식을 보다 쉽게 다가갈 수 있다.
따라서, 나는 우선 Java, Spring Framework, Boot까지 깊게 공부할 필요가 있다.
이미지 최적화 결과
일단 이미 빌드 타임은 45분을 초과하고 있어서 더이상 빌드 자체가 안되는 문제가 생겼다. 더 이상 블로그 포스팅이 어려운 상황이었다.
최대 압축률 95%까지 이미지 용량을 낮출 수 있었고, 순차적으로 이미지를 대체하고 있는 중이다. 막무가내로 인터넷에서 이미지 복사하기 붙여넣기를 했던 사진들은 용량이 어마어마했다. 이것이 실질적인 효과가 있는지 보고 싶었다. 우선 수작업으로 가장 큰 용량 순서대로 600개가량 되는 사진 중에 50개정도만 교체를 해보았다. 그리고 다시 배포.
45분을 초과해서 Timeout으로 실질적으로 1시간 정도 필요했던 빌드타임이, 40분으로 축소되었다. 아직 사진들의 10%정도만 바꿨다는 점에서 계속해서 글을 올리는것과 동시에 기존 이미지들을 최적화해서 빈 용량을 만들어 낸다면, 일정 기간 동안 포스팅을 하는 것을 유지 할 수 있다. 하지만 장기적으로 이미지 최적화 이후로 진행 할 수 있는 방안도 마련해야 한다. 당장 급한불을 껏기 때문에 우선 공부에 집중하고 이 부분은 차근차근 해결해보고자 한다.