# Table of Contents

# 글을 시작하며

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

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

# 블로그 개편

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

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

![devlog_prev_architecture](/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 속성을 추가해 해결하였고, 이때 참고한 글들을 첨부합니다. 이 레이어에 대한 부분도 참 재미있는 요소가 많네요.

```css
isolation: 'isolate';
```

- [ToastUI 디버깅 도구 관련 글](https://ui.toast.com/weekly-pick/ko_20211027)
- [Sungik Choi 님의 트러블 슈팅 글](https://www.sungikchoi.com/blog/safari-overflow-border-radius/)

# 블로그 변경사항

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

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

**2022.12.30** 기준 [https://utteranc.es/](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 에 코드가 모두 공개되어 있습니다.
          참고해보시고 궁금한게 또 있으시다면 메일이나 댓글 남겨주세요! 감사합니다.
```


블로그를 새로 만든 이유와 관련 기술에 대해 이야기 합니다(이전 댓글들은 여기 기록해 두었습니다)

DevLog

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