블로그 리뉴얼, 그리고 기술 이야기(with. NextJS)

By John

·
/images/post/thumbnail/john_home_cherry_blossom.jpeg

Table of Contents

글을 시작하며

안녕하세요! 얼마전 제가 블로그를 리뉴얼 하게 되었습니다.
아직 추가로 해야하는 작업들이 좀 남아있지만, 리뉴얼로 인해 생긴 변경사항들을 미리 말씀드릴까 합니다. 이 블로그로 인해 강의 제안도 받고, 이직 제안도 받고 참 나름? 재미있는 일들이 생겼었는데요. 블로그를 더욱 잘 운영하기 위해, 그리고 도움을 더 잘 드리기 위해 개발을 새로 하게 되었습니다. 아울러 블로그를 만들며 생각한 기술적 이야기와 몇몇가지 팁들을 이야기 해 보겠습니다.

그동안 제 메마른 블로그에 남겨주신 댓글들, 그리고 개인적으로 주신 email 모두 참 감사합니다.
댓글들은 모두 정리하여 글 하단에 남겨두었습니다. 다시한번 감사드립니다.

블로그 개편

제가 블로그를 새로 개편한 표면적인 이유는 단순합니다. 글을 조금더 자주 쓰고 싶고, 블로그를 운영하는데 신경쓸일이 적었으면 좋겠다 란 니즈에서 시작한 생각인데요. 제가 이전(v1, v2) 버전에서 관리하던 블로그는 어려운 기술이 들어가진 않았습니다. 다만 의도하에 오버엔지니어링 을 한 부분도 있고, Admin 까지 만들어 놓은지라 Backend 서버, SSR 용 서버두 종류의 클라이언트 를 운영중 이었습니다. 아울러 DB 는 아직 RDS 를 쓸 단계는 아닌지라 직접 EC2Docker 로 에 말아 올려 Private Subnet 안에 넣고, NAT 도 돈아낀답시고 EC2 로 직접 돌리는등의 작업을 해 두었었는데요. 그래도 Lambda 기반의 Serverless 로 서버를 돌린게 편리함에 참 큰 역할을 했네요(사실 EC2 나 ECS 를 써도, 이정도 트래픽이면 운영시 트래픽 문제로 신경쓸 일은 없었을겁니다 ㅋㅋㅋ).

이때 이렇게 보안이며 뭐며 나름 신경을 쓴데에는 이유가 있었습니다. 이유는 공부입니다. cloud 에 익숙해질겸 VPC 내부 설정도 직접 해보고, Subnet 쪼개서 보안도 챙기고, 아무리 작아도 일단 라이브하는 서비스 바닥부터 다 만들어 봐야지? 란 생각이 컸죠. 이때 아직도 살아있는 어드민에는 Markdown Editor 까지 직접 구현을 해 두었습니다(잘가라). 뭐 어찌되었든 사이즈가 너무 크단 생각이 들었습니다.
상세 구조를 자세히 그리자면 너무 복잡해질것 같아, 러프한 구조를 그린 이미지를 첨부합니다.

/images/post/2022/11/devlog_prev_architecture.png

특히나 DB 를 직접 띄우다 보니 글을쓰고 댓글을 쓰는 일이야 크게 없지만서도 지금 남은 용량이 얼마나 되고, EBS 볼륨은 언제쯤 늘려야 하나. 메모리는 언제쯤 올려야 하나. 를 신경쓰기가 참 귀찮더군요. 만약 제가 이 블로그로 사이드 프로젝트를 끝낼거라면 모르겠습니다. 허나 저는 진행중인 개인 프로젝트의 서버에 K8S 더나아가 EKS 를 써볼 생각입니다. 초기엔 모르겠지만 RDS 를 써야 하는 때가 올때까지 서비스를 키워보겠다는 목표를 갖고 개발중 인데요. 그럼 이 블로그는 진짜 나만 쓰는 블로그이니, 최대한 편하게 관리하도록 만들어 놓는게 내가 유지하는데 현실성이 있는 선택이겠다 싶더군요.

다시 NextJS

저는 리액트를 참 좋아합니다. 이 블로그 역시 Next.js 로 만들어서 배포했다가, 에이 직접하자 란 생각에 React.js + Node.js 로 직접 SSR 서버를 돌리고 있었습니다. 허나 다시 Next.js 로 돌아가게 되었는데요. 그이유는 생각보다 단순합니다. 아니 React18 이 나왔는데 사용중이던 lodable-components 가 이걸 지원을 제대로 안해주는 겁니다. 혹시 모르니 기다리자란 생각에 조금 여유를 두고 지켜보았으나, 빠른 시일 내엔 불가능 할 것 같다는 생각이 들더군요. 아울러 Next 진영의 빵빵한 후원 역시 참 매력적이란 생각은 꽤 오래전부터 해왔었습니다. SSG 의 편리함을 생각한 부분이 아예 없진 않지만, 사실 저게 가장 컸습니다. 만약 React18 대응이 빨랐다면 저는 그냥 SSR 서버를 운영하고 있었을 것 같네요. 그런데 말입니다. 얼마전 Next.js 13 버전의 발표가 있었죠. 저는 이걸 보고 참 잘 선택했다 란 생각과 동시에 이래서 어느정도 서포트를 잘 해주는 기술을 쓰는게 답인가? 란 생각을 했습니다.

일단 이 글은 Next.js 13 에 대한 내용을 다루는 글은 아님에도 개인적인 소감을 말하자면, 괜히 React 팀과 협업을 하는게 아니구나 라는 생각을 지울수 없는 발표였습니다. 이 블로그도 테스트를 조금만 더 해보고 13으로 버전을 올려야겠어요.
어찌 되었든, 저는 이번에 Next.js 로 스택을 변경하며 가장 크게 가져간 이득은 두가지란 생각입니다.

서버가 사라졌다

서버가 사라지고, Static Site 제공이 굉장히 편리해 졌습니다. next export 명령어만 입력해주면 알아서 정적 파일을 만들어주는 덕에 개발자인 제가 따로 관리하고 신경써야 할 부분이 굉장히 줄었습니다. 만들어준 정적 파일을 S3 에 올리고 이걸 Cloudfront 와 연결해 주기만 하면 되니 이 얼마나 편한지요. 하지만 여기서 AWS 에 작은 불만이 있긴한데요, 정적 페이지에 대한 다이나믹 라우팅을 언제쯤 편하게 할 수 있도록 지원 해주려나요. Lambda@Edge 로 처리를 하긴 했으나, 그냥은 안되나? 싶은 생각을 지우지 못했습니다. 그래서 잠시 Netlify, Vercel, Cloudflare 등을 알아보았으나 역시나 혼자 관리하는 만큼 관리해야 하는 환경을 분산시키기가 싫어 그냥 AWS 상에 구축을 선택했습니다. 구글링을 하다보니, 지원을 기다리며 Serverless Framework 등을 쓰고 버티다 결국에 나도 넘어갔다란 글이 보이던데, 이걸 개선 해준다면 저로선 참 감사한 일이 아닐까 싶네요.

현재는 서버가 없어진 대신 getStaticProps, getStaticPaths 등의 함수를 이용하고 있고, 빌드시 markdown 으로 작성된 파일을 읽어와 바로 데이터를 주입해 주고 있는데요. 생각보다 그리 어렵지도 않았고 큰 이슈도 없어, 개발하는데 크게 어려움을 느낀적이 없었습니다.

빵빵한 지원

이부분은 사실 느낀지 시간이 좀 된 부분입니다. 여태 Next.js 에 릴리즈 노트를 접해오며, 비교적 다른 React.js 관련 기술들에 비해 확실히 지원이 빠르다란 느낌도 지울수가 없었구요. 아울러 github 에 나와있는 공식적인 예시들이나 풍푸한 레퍼런스로 인해 개발시 발생하는 트러블슈팅을 하기가 참 수월하단 생각입니다. Remix 도 참 좋지만, 아직까진 Next.js 가 가장 좋아보이는 이 느낌은 지울 수가 없네요. 13을 어서 적용해 보고 싶은데 Layout 등의 새로운 기능이 아직 beta 인지라 테스트를 좀더 해보거나, 혹은 기간의 여유를 좀 두었다가 Migration 을 진행할 생각입니다.

작은 팁(Safari hover + border-radius 문제 해결)

제 블로그는 1024px 이상부터 포스트에 hover 를 하면 Thumbnail확대 가 되는 효과를 주었습니다. 테스트를 해보던중 히안한 현상을 발견했는데요. safari 에서 border-radius 효과가 사라지며 잠시 각진 외곽선이 드러났다가, 다시 border-radius 가 정상적으로 작동이 되는것 입니다. 말인즉슨 아래와 같은 현상이 일어났습니다.

  1. border-radius 가 먹혀있는 포스트 카드들
  2. hover 하니 이미지가 확대
  3. 확대되는 과정에서 border-radius 효과가 사라짐
  4. 그로인해 radius 영역의 가리워진 부분이 잠시 드러났다가
  5. 다시 사라지며 정상 작동

결론적으로 Safari 렌더링엔진 Webkit 의 버그라고 하는데요. 우선적으론 safari 에서 layer 속성을 살펴 보았고, 이후 관련 글들을 읽어보니 결국엔 쌓임 맥락이란 부분과 연관지어 발생한 이슈 라는것을 알 수 있었습니다. 저는 아래와 같은 CSS 속성을 추가해 해결하였고, 이때 참고한 글들을 첨부합니다. 이 레이어에 대한 부분도 참 재미있는 요소가 많네요.

isolation: 'isolate';

블로그 변경사항

블로그에 작은 변경사항들이 몇가지 생겼습니다. 디자인과 기타 look and feel 등을 제외하면 사실 말씀드릴 부분은 간단하게 세가지 정도 일 것 같은데요. 다음과 같습니다.

댓글 기능 이 사라졌습니다. 댓글을 놔둘까 말까 고민을 조금 했는데요. 블로그를 방문해 주시는 숫자 대비 댓글의 수가 미미한데다, 조금 상세한 질문은 대부분 email 로 주시는 경우가 더 많았기 때문입니다. 이 부분은 후에 고민해보고 추가한다 싶으면 github issue 등의 기능을 좀 알아볼까 생각중 입니다.

2022.12.30 기준 https://utteranc.es/ 기반의 댓글기능을 추가했습니다.

공유하기 기능을 추가했습니다. 사실 상세페이지에 들어가면 얼마든지 공유가 가능하지만, 공유하기 버튼이 있는경우 모바일 대응이 잘 되어있다면 참 편하다고 느껴 추가했습니다. 많이 사용하실지는 모르지만 일단 예쁘니 맘에듭니다.

소개 페이지에 간략한 커리어 관련사항을 기재 했습니다. 수가 많은것은 아니나, 이 블로그를 통해 연락을 받은경우 제 커리어나 회사에 대해 궁금해 하시는 분들이 종종 계셨습니다. 커리어야 뭐 특별할것도 없고, 숨길것도 없는지라 그냥 보실수 있게 해 보았습니다.

마치며

조금더 좋은, 양질의 글을 공유하기 위한 노력을 꾸준히 하겠단 말을 마지막으로, 이 삭막한 블로그에 남겨주셨던 감사한 댓글을 아래 첨부합니다. 글 읽어주셔서 감사합니다.

그간 남겨주신 댓글들

# WebServer 와 Application Layer(with. golang)
  ㄴ dongko	너무 좋은 내용입니다! 좋은 생각거리를 주셔서 감사합니다 :)
      ㄴ John	좋게 읽으셨다니 저야말로 감사합니다. 여력이 난다면 실습편으로 찾아뵙겠습니다:)
# 개발 중 조심해야 할 것들(2)
  ㄴ 고헤일리 때론 단순함에 집중하자.. 새겨듣겠습니다.
      ㄴ John	아 헤일리ㅋㅋㅋㅋㅋㅋㅋㅋ

  ㄴ 뉴비 좋은 글 감사합니다! 라이브러리에 대해서 다시 생각하게 되는 계기가 되었네요 😊
      ㄴ John	좋게 읽어 주셔서 읽어주셔서 감사합니다 🙂
# 개발 중 조심해야 할 것들(1)
  ㄴ ㅇㅇ
      블로그 정말 잘 구성하셨네요. 저는 프론트 React Typescript + 백엔드 Go로 블로그 만들려다가
      이것저것 기능 구현하는데 시간이 많이 걸림을 깨닫고 현재 파이어베이스의 힘을 조금 빌려서 개발하고 있습니다 ㅎㅎ
      현업에서는 수천 개의 상태를 다룰 수 있어야 하는군요.
          ㄴ John
              요세 정신이 없어서 글을 너무 늦게 봤군요.
              저도 Typescript 와 golang 을 참좋아하는데 좋은 결과물이 나오시길 바랍니다.
              바쁜 시기만 지나면 글을 조금더 자주 써볼게요.
              감사합니다.

  ㄴ ss
      이제막 1년 되어가는 프론트,백엔드 개발자입니다
      처음 입사했을때 꽤나 규모있는 프로젝트를 혼자 맡았는데 시간은 급하고해서
      계속해서 일단 기간에만 맞춘다고 아무렇게나 동작만하면 되는식으로 짜게 되더라고요
      아직 갈 길이멀지만 언젠가 저도 실력있는 개발자가 되고싶네요
          ㄴ John
            저도 늘 노력중이랍니다.
            저도 일정이 빠듯할땐 쉽지 않은경우를 종종 겪었어요 ㅎㅎ
            같이 화이팅 하시죠. 글 읽어주셔서 감사합니다.
# Goodbye Next.js, Hello React.js
  ㄴ 나그네
      말씀처럼 개인프로젝트나 공부 목적이라면 직접 다 하나하나 만들면 좋지만
      많은 사람과 협업을 위해서는 통일성과 제약성 그리고 빠른 개발을 위해 많이 쓰는 프레임워크를 쓰는 게 낫지요..
        ㄴ John
            우선 글을 읽어주셔서 감사합니다!! :)
            네 저 역시 일정 부분은 같은 생각입니다. 위 글에서도 언급했지만, React.js 를 이용한 SSR 을 구현시
            저는 주위 사람들에게 우선적으로 Next.js 를 권합니다. 아울러 제가 팀 내에서 SSR 을 구현해야 한다면 Next.js 를 우선적으로
            고려해 볼 것입니다. 다만 개인적으론 위 과정들에 익숙하기 때문에 직접 ssr 을 구현하는 것을 선호하는 편이고,
            개발 속도에서도 별 차이가 나지 않습니다.

            통일성과 제약성, 빠른 개발이란 사항은 각 기술의 특성과 팀원들,
            혹은 팀별로 모두가 익숙한 부분이 다를 수 밖에 없는 경우가 많습니다.
            때문에 저희 팀의 경우 새로운 기술을 도입하거나 결정을 해야할 때,
            특별한 문제가 있지 않은 이상 무엇보다 팀원들의 의사를 가장 중요히 반영해 각 사항들을 결정합니다.
            (물론 해당 기술의 생태계나, 대중적인 개발자들의 선호도는 고려합니다.)

            추가로 이번에 업데이트 예정인 react v18 의 발표사항과 이전 발표등에서 보여준 변화의 방향성 등을
            개인적으로 판단했을때, 직접 SSR을 구현하는 방향을 선택하게 되었습니다.
            하지만 앞으로 제 생각이 어떻게 변경될지는 모르겠네요. loadable 이 React 의 업데이트를 따라가지 못한다면 다시 이동할지도요 ㅎㅎ
            글 읽어주셔서 감사합니다 :)

  ㄴ ㅇㅇ	글 잘보았습니다~
      ㄴ John	감사합니다 :)
# 블로그 개발 후기 3 - Next.js
  ㄴ Websterking 좋은 글 잘보았습니다 ~ z
        ㄴ John	감사합니다~

  ㄴ cam Nextjs로 블로그 개발하는데 많은 도움이 되었습니다 감사합니당 !
        ㄴ John	도움이 되었다니 기쁘네요. 읽어주셔서 감사합니다 :)

  ㄴ gamguma 좋은 내용 정말 감사합니다!! 행복한 연말 보내시길 바랍니다 :)
        ㄴ John	읽어주셔서 감사합니다. 이제 곧 새해에요. 복 많이 받으세요 :)

  ㄴ Teddy
      안녕하세요 글 잘봤습니다. 혹시 serverless-nextjs를 통해 배포를 하시면 SEO가 잘 잡히나요??
      저도 패키지(정확히는 serverless-nextjs-plugin 말고 serverless-nextjs 컴포넌트)를 이용해서
      Lambda@edge를 이용하고 있는데 cold start 때문에 크롤러가 데이터를 잘 받아가지 못할 수 있다는 몇몇 글들을 보게 됐어요.
      가령 이런 링크들 입니다.
      https://stackoverflow.com/questions/61433306/cheapest-way-to-deploy-a-react-app-using-nextjs-ssr-on-aws
      https://github.com/serverless-nextjs/serverless-next.js/issues/1388
      크롤러가 다녀가는데 보통은 며칠이 걸리는건지.. 혹은 해당 이슈 때문인지 최초 페이지를 제외하곤 검색 결과 노출이 안되고 있습니다.
      혹시 이부분 해결하셨다면 어떤 접근을 하셨는지 여쭤봐도 될까요?"
        ㄴ John
            1. 일단 cold start 문제를 해결하기 위한 방법은 여러가지가 있지만 저는 적용해두지 않은 상태입니다. 크롤러가 다녀가는데 수일이 걸릴수 있는건 사실이 맞구요.
            2. 저는 현재 rss 나 sitemap 등을 제공하기 때문에 해당 자료역시 등록을 해둔상태인데, 크롤러가 데이터를 긁어가는데 도움이 됩니다.
            3. nextjs 의 방식을 그대로 사용하셔서 개발을 진행하셨다면 페이지당 ssr 이 적용될테니 각 페이지별로 seo 가 적용될겁니다.
            4. 검색엔진에 노출빈도는 사실 굉장히 여러가지의 요소가 적용되기 때문에  ssr 하나의 요소만으로 판단하기는 어렵습니다. 다만 시간이 지나면 검색엔진에 노출이 될것 같다는 생각이 드네요.
               글에 관심을 갖아주셔서 감사합니다^^ 더 궁금하신 부분이 있다면 메일이나 댓글 부탁드려요:)"
        ㄴ John
            아울러 당연히 작업해두셨을것 같긴한데..
            header 부분에 meta tag 작업을 조금 꼼꼼히 해두셔도 도움이 많이 된답니다! 도움이 되셨으면 좋겠네요~
              ㄴ Teddy
                  답변 정말 감사드립니다. 리전별로 배포가 되어있어 latency에 따라 국가별 크롤러가
                  타임아웃될 수 있다는 점이 좀 걸리지만 적어도 국내 서비스는 국내 검색 결과로 잘 SEO되는걸로 확인이 되네요.
                  serverless-nextjs 저렴하면서도 정말 괜찮은것 같습니다. 다시한번 좋은글 감사드립니다!

  ㄴ 김용희
      안녕하세요 웹팩을 도입하려는 초보 개발자입니다.
      Next.js 와 react 가 초기 셋업 부분이 다른점이 있을까요? 처음이라 너무 감이 안잡히네요..ㅜ
        ㄴ John
            일단 어떤 방식으로 어떤 부분을 설정 하시려는지 알아야 도움을 드릴 수 있을것 같습니다.
            react 프로젝트를 webpack 과 함께 구성하는 방식은 너무나 여러가지 이기때문입니다.
            개인적으로 Next.js 프로젝트 초기 구성시 저는 공식홈페이지에 있는 예시의 방법을 사용합니다.
            추가로 궁금하신 부분이 있다면 댓글이나 메일 남겨주세요! 답변 드릴수 있는 부분이라면 최대한 답변 드리겠습니다.
# 블로그 개발 후기 2 - GraphQL(with. REST API)
  ㄴ hi graphql은 전혀 모르고 본 글인데 어떤 개념인지 이해하기 쉽네요. 잘 봤습니다 :)
        ㄴ John	감사합니다!
# 블로그 개발 후기 1 - Typescript
  ㄴ Tei 전설의 시작...
        ㄴ Fsd 고마워요 ㅋㅋ

  ㄴ roach Typescript 전설의 개발자..
        ㄴ John	고마워요 로치 ㅋㅋ 태의를 닮아가는군요

  ㄴ 댓글	혹시 댓글 구현은 어떻게 하셧나요?
        ㄴ John	정확히 댓글의 어느부분을 질문 주신지 모르겠어서 답변을 드리기가 어렵네요ㅜㅜㅜ
          우선 소개 페이지 github 에 코드가 모두 공개되어 있습니다.
          참고해보시고 궁금한게 또 있으시다면 메일이나 댓글 남겨주세요! 감사합니다.
Juntae(john) Kim · © 2020 · DevLog