StoryTime Angular: 내 블로그, SEO와 SSR의 충격
Source: Dev.to
프로젝트 배경
내 첫 번째 대형 Angular 프로젝트는 기업용 애플리케이션도 아니고, 반쯤 끝난 사이드 프로젝트도 아니다: 바로 내 수면에 관한 블로그다.
그때 나는 실제 운영 사이트를 만들고 싶었고, 콘텐츠, SEO, 성능, 배포 등 실제 제약 조건들을 가지고 싶었다… 그리고 무엇보다 Angular를 사용해 실력을 키우고 싶었다.
기술 선택
백엔드
매우 실용적인 백엔드로 순수 PHP를 선택했다.
- 이전에 사용해 본 적이 있었다.
- 호스팅이 매우 간단하다.
- 블로그 정도라 복잡한 인프라가 필요 없었다.
백엔드는 주로 게시글을 관리하기 위한 기본 API 역할을 했으며, 화려하진 않지만 충분히 효율적이었다.
프론트엔드
Angular를 선택한 이유는 두 가지다:
- 이미 조금 알고 있었다.
- 정말로 실력을 올리고 싶었다.
글쓰기 워크플로우
- 작성: Google Docs에서 글을 썼다.
- 임포트: Angular 도구에 글을 가져왔다. 초기에는 반자동으로 임포트했다.
HTML 정리
Google Docs는 엄청난 양의 태그, 스타일, 불필요한 HTML을 추가한다.
이를 정리하기 위해 나는 몇 시간을 투자했다:
- 정규표현식을 이해하고,
- 테스트하고, 부수고, 개선하면서.
바로 그때 정규표현식에 익숙해졌다.
SEO와 SSR 문제
블로그를 공개했을 때 큰 실망이 있었다: 페이지가 제대로 색인되지 않거나 구글에 전혀 보이지 않았다.
그때 나는 구글이 클라이언트 사이드 렌더링(CSR) 사이트를 SEO 관점에서 좋아하지 않거나 권장하지 않는다는 것을 알게 되었다.
Angular Universal로 전환
해결책은 명확했다: Angular Universal(SSR).
실제로는:
- 문서가 거의 없고 명확한 튜토리얼도 거의 없었다.
- 경험을 공유할 사람도, 주변에 같은 일을 하는 사람도 없었다.
배포
나는 한 번도 해본 적이 없었다:
- 서버 설정,
- 포트 관리,
- 기존 사이트 뒤에서 Node 서버를 구동하는 것.
그래서 현장에서 배워야 했다:
- Angular Universal을 어떻게 노출할지,
- PHP와 Node를 어떻게 함께 운영할지,
- 프로덕션에서 전체를 망가뜨리지 않는 방법.
동적 메타 태그
당시에는 페이지별 동적 메타 태그에 대한 문서나 실제 예제가 거의 없었다.
오랜 검색 끝에 Renderer2를 발견했고, 이를 통해 서버 측에서도 DOM을 올바르게 조작할 수 있게 되었다.
Angular의 발전과 배운 교훈
- Angular는 크게 발전했으며, SSR이 훨씬 접근하기 쉬워졌다.
- 도구들이 더 성숙해지고 문서도 훨씬 좋아졌다.
- 오늘날 SSR 프로젝트를 설정하는 것은 예전보다 훨씬 간단하다.
이 경험은 가장 교육적인 프로젝트 중 하나였다:
- Angular를 깊게 파고들기,
- 이론이 아닌 실제 SEO,
- 서버 배포,
- 프로덕션 제약 조건.
결론
완벽하지 않은 프로젝트였지만, 프론트엔드 개발자로서 내 여정에 큰 발걸음이 되었다.
조금 오래됐지만 방문자들에게는 여전히 유용하다.
블로그 링크: